[00:32] <imbrandon> yea [00:32] <LaserJock> surely I'm not the only one [00:33] <LaserJock> is jdub still doing Planet? [00:33] <imbrandon> iirc jdub is one of the devs of planetplanet upstream [00:33] <LaserJock> yeah [00:33] <imbrandon> not sure, havent been on that list in quite a while [00:33] <imbrandon> and on the other side i'm not sure how old of an instance we run [00:34] <imbrandon> where debians is all in svn we only have the configs in bzr iirc [00:34] <LaserJock> but is it a config problem, a Wordpress problem, or a PlanetPlanet problem? [00:35] <imbrandon> looks like planetplanet problem [00:35] <Fujitsu> LaserJock: It's not a WordPress problem [00:35] <Fujitsu> (although the number of other problems that WordPress has is absolutely incredible) [00:38] <TheMuso> I'm wondering whether my feed is not being picked up properly any more since I made a post during LP downtime. === gouki_ is now known as gouki [00:39] <Fujitsu> TheMuso: Planet is independent from LP, other than the config branch being hosted there, as far as I know. [00:40] * minghua finds it quite ironic that translation on LP is completely broken after upgrade while one main feature of this upgrade is "Rosetta improved". [00:41] <LaserJock> it's broken? [00:41] <Fujitsu> LaserJock: Yep. [00:41] <Fujitsu> They are experiencing enormous performance issues with the new code. [00:41] <imbrandon> ironic [00:42] <Fujitsu> Such that it doesn't work *at all*. [00:42] <Fujitsu> The 8 hour migration broke more than it solved. I am impressed. [00:42] <LaserJock> freaking heck [00:42] <LaserJock> after 8 hrs downtime? [00:43] <Fujitsu> Some of the other changes (a security fix in particular) leave a bit to be desired, too. [00:44] <TheMuso> If this is the trend for LP, I start to worry about its long term usefulness. [00:44] <Fujitsu> But the Rosetta one is the most worrisome of the lot, right. [00:48] <Fujitsu> `The speed and reliability of Launchpad Translations should now be significantly improved following a major refactoring.' [00:48] <Fujitsu> Sure, it's reliably down. [00:49] <RoAkSoAx> haha speed impreved on showing error messages xDD [00:50] * TheMuso looks at planet config, and doesn't notice any syntax errors... [00:55] <LaserJock> well, I'm sure 404s would speed Rosetta up a lot :-) [00:57] <imbrandon> bbiab [00:57] <nxvl> anyone know someway to execute a sh script step by step as in debbuging? [00:57] <nxvl> cause 'sh -x' isn't showing me nothing [00:58] <TheMuso> nxvl: What do you mean its not showing you anything? [00:59] <nxvl> TheMuso: it only shows me the error, but the lines it executes doesn't show the error [01:00] <TheMuso> nxvl: hmm. Thought of doing something like this? sh -x scriptname 2:&1 | less [01:00] <nxvl> http://pastebin.com/d16b8f83f [01:00] <nxvl> shows this [01:00] <TheMuso> Piping all output, whether from the script or otherwise, through less, to review line by line. [01:00] <nxvl> TheMuso: isn't a big output, i can read it on my terminal without a problem [01:01] <TheMuso> nxvl: Ah ok. [01:01] <TheMuso> nxvl: I still don't understand the problem. [01:02] <nxvl> TheMuso: that's the output, and there i can't see the error, it says that a )) is missing, but i don't find why [01:02] <LaserJock> nixternal: around? [01:02] <RoAkSoAx> TheMuso, he want's to debug his script step by step and he wants to know if there is a way to do it [01:02] <nxvl> so i'm asking for any way to execute all step by step to find where exactly this )) are missing [01:02] <nxvl> RoAkSoAx: exactly [01:03] <minghua> nxvl: It says it's missing on line #807. [01:03] <nxvl> minghua: well, it isn't [01:04] <nxvl> minghua: so i want to check what is it executing to check if maybe there is a malformed variable that is making the need of those )) [01:05] <minghua> I am not a shell expert, but I don't see how line-by-line execution will help you. It's a parsing error, not an execution error. [01:07] <TheMuso> RoAkSoAx: I know that. I couldn't work out what the problem was from the output. [01:07] <nxvl> minghua: yes, but i have already check all the source and there are no unclosed '(' so i think maybe a variable contains it [01:07] <TheMuso> nxvl: What is set -u for? [01:07] <minghua> -u Treat unset variables as an error when substituting. [01:07] <nxvl> TheMuso: i don't what you to work on it, only to point me to a way to execute it line by line so i can work on it :D [01:08] <nxvl> TheMuso: dunno, it's a FTBFS bug on bootcd [01:08] <nxvl> LP: #165030 [01:08] <minghua> nxvl: Have you tried to run it through bash? [01:08] <TheMuso> nxvl: Well the bash manpage may give you some pointers. [01:09] <nxvl> minghua: that solves the problem [01:09] <nxvl> why haven't i think it before [01:09] <nxvl> minghua: thnx [01:09] * nxvl hugs minghua [01:10] <minghua> nxvl: No problem. (Although I wouldn't call it "solving" the problem.) [01:10] <minghua> bug 165030 [01:10] <ubotu> Launchpad bug 165030 in bootcd "bootcd FTBFS on hardy" [Undecided,Confirmed] https://launchpad.net/bugs/165030 [01:11] <nxvl> minghua: in some way it is, because the script is running with sh, and it should run with bash [01:13] <RoAkSoAx> nxvl, but /bin/sh is just a logical link to bash or dash [01:13] <imbrandon> sh links to dash [01:14] <RoAkSoAx> yep by default to dash [01:14] <nixternal> LaserJock: yo yo [01:15] <nxvl> i use "bash +x script" and it runs fine without errors [01:16] * RoAkSoAx still cant access to rossetta translations :S [01:20] <zul> helloooo [01:21] * TheMuso wonders whether planet is ignoring his entries, due to the title of his most recent posts being too long... [01:22] <persia> TheMuso: I don't understand why, but I can reproduce the hunking issue with easycrypt. I'll dig into it to try to figure out why, and post a correction to the wiki page. [01:23] <RoAkSoAx> hey does anyone of you know why rossetta still not working? [01:24] <nxvl> is there any recipe about dpatch? i don't find very usefull the packaging guide of dpatch [01:24] <LaserJock> nxvl: it's in the packaging guide [01:24] <LaserJock> where are you looking? [01:26] <nxvl> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#head-5f4642a5564760bd8aae0fd2cbd70e6cd78c1260 [01:27] <minghua> RoAkSoAx: It has been down since the upgrade. Any reason you believe it's going to work soon? [01:29] <bddebian> Heya gang === ^4nDr3s is now known as RoAkSoAx [02:04] <TheMuso> c [02:04] <TheMuso> wrong tab... [02:06] <Fujitsu> LaserJock: Why is it that you bring a high importance to most bugs that you touch? [02:06] <Fujitsu> (LP bugs, that is) [02:08] <bddebian> Heya Hobbsee [02:10] <Hobbsee> heya [02:10] <TheMuso> Hey Hobbsee. Glad exams are over? [02:13] <LaserJock> Fujitsu: magic touch I guess [02:14] <bddebian> heh [02:14] <LaserJock> generally I don't complain much [02:14] <LaserJock> but when I do I expect to be heard ;-) [02:18] <Fujitsu> LaserJock: Heh. [02:19] <Fujitsu> Good to see that nomination bug marked High. [02:21] <Hobbsee> TheMuso: yeah, but i've still got lab reports to hand in [02:21] <TheMuso> Hobbsee: I guess thats not too bad. [02:28] <ajmitch> hi Hobbsee [02:28] <Hobbsee> hey ajmitch [02:28] <ajmitch> how's it going? [02:28] <Hobbsee> uh oh, lab people are getting annoyed about the late lab reports [02:28] <Hobbsee> ajmitch: done the last exam, random_crap_to_do--. [02:29] <nxvl> isn't there any "dpatch for dummies" or something like that [02:30] <LaserJock> nxvl: what are you having a problem with? there isn't much to it [02:30] <nxvl> i don't know if it is cause i'm tired, but i don't undesrtand anything [02:30] <nxvl> LaserJock: on putting dpatch on debian/rules [02:30] <LaserJock> oh [02:30] <nxvl> i have do it [02:30] <nxvl> but i'm getting a weird error [02:31] <LaserJock> did you add the following to the top of debian/rules: [02:31] <LaserJock> include /usr/share/dpatch/dpatch.make [02:34] <nxvl> LaserJock: http://pastebin.com/d5a705ca6 <- i have this [02:35] <nxvl> i'm calling dpatch directly instead of using dpatch.make [02:36] <minghua> Apparently, LaserJock needs to consider writing "Ubuntu packaging for dummies". :-) [02:37] <LaserJock> nxvl: ok, you can get rid of the patch-stamp: and dpatch: rules [02:38] <LaserJock> nxvl: read man dpatch.make [02:40] * minghua didn't know dpatch.make has a man page. [02:40] <ajmitch> Hobbsee: that's good :) [02:40] <LaserJock> minghua: yep [02:42] <LaserJock> nxvl: the Examples section of the dpatch.make man page has the right rules === LaserJock is now known as LaserRock [02:47] * LaserRock out [02:48] <bddebian> heh [02:48] <Hobbsee> LaserRock: ponies! [02:49] <ScottK> Good $TIMEOFDAY all. [02:49] <Hobbsee> hi ScottK [02:49] <bddebian> Heya ScottK [02:50] <ScottK> heya Hobbsee and bddebian (or are you really bdefreese?) [02:50] <StevenK> Muahah [02:50] <StevenK> LaserRock: Ponies! Ponies! Ponies! Ponies! Ponies! [02:50] <bddebian> ScottK: I'm not sure anymore ;-P [02:51] <minghua> hello ScottK. [02:56] <ajmitch> [02:57] <imbrandon> [03:00] <Hobbsee> [03:00] <TheMuso> [03:01] <nxvl> [03:02] * Fujitsu [03:03] * ajmitch was just having ssh issues thanks [03:03] * TheMuso [03:03] <TheMuso> :p [03:03] * ajmitch gives up & leaves [03:04] * Fujitsu staples ajmitch to the channel. [03:05] * Fujitsu likes stapling people to things that lack a physical manifestation. [03:06] * Hobbsee staples Fujitsu to kmos [03:06] <Fujitsu> It burns! [03:07] <StevenK> Careful, you don't know how cluelessness is contracted. [03:07] <StevenK> Hrm. Did I say that out loud? [03:07] <TheMuso> lol [03:07] <Fujitsu> Haha. [04:58] <TheMuso> /c/c [04:58] <TheMuso> argh [04:58] <RAOF_> Hey TheMuso :) [04:58] <TheMuso> Hey RAOF_. [04:59] * StevenK ponders writing an #ubuntu-motu drinking game === RAOF_ is now known as RAOF [04:59] <Burgundavia> StevenK: we don't need a game to get people drinking [04:59] <RAOF> StevenK: Based upon the incedence of "Ponies!"? [04:59] <Burgundavia> they already do that on their own [04:59] <StevenK> "Everytime TheMuso writes 'c', '/c' or any variation thereof, followed by 'argh' or 'wrong tab', take a drink." [05:00] <TheMuso> StevenK: heh [05:00] <StevenK> "Everytime someone asks LaserRock about ponies, or golden ponies, take a drink." [05:00] <Hobbsee> Burgundavia: :P [05:01] <StevenK> "Everytime Hobbsee pokes someone with her Long Pointy Stick, take a drink, unless it is you getting lambasted." [05:01] <Hobbsee> hahaha [05:01] <StevenK> This is kind of fun. [05:01] * TheMuso wonders whether bugs can be filed against planet ubuntu anywhere... [05:02] <StevenK> "Everytime RAOF complains about marking, first years or both, take a drink." [05:02] <Fujitsu> Haha. [05:02] <RAOF> That's something I could get behind! [05:03] <ajmitch> "Everytime someone criticises Launchpad, take a drink" [05:03] <TheMuso> We'd be drunk. [05:03] <Fujitsu> That's what I thought. [05:03] <ajmitch> well & truly [05:03] <StevenK> I like what WoW does when you're drunk, I saw that first hand yesterday when a friend dropped a Brewfest Pony Keg [05:03] <ajmitch> hehe [05:03] <ajmitch> the brewfest event was great for that [05:03] <StevenK> I came out with "I wonder if I'm shober.", followed by "Haha ... hic!" [05:04] <ajmitch> did you get the awesome visual effects? :) [05:04] * ajmitch started raiding last week [05:04] <StevenK> I didn't, no. [05:04] <StevenK> I got completly smashed, but no visual effects [05:05] <ajmitch> once you're well & truly gone, the screen is all blurred, you can't walk straight, and it's like tunnel vision [05:05] <StevenK> Bwahaha [05:05] <TheMuso> lol [05:05] <StevenK> So I needed to drink more [05:05] <ajmitch> yep [05:05] <ajmitch> it progressively gets worse [05:05] <StevenK> I wonder if it takes more for you to get drunk the higher level you are [05:06] * TheMuso wonders whether you end up not being able to see anything if you get blind drunk. :p [05:06] <ajmitch> no idea, I was doing it at level 70 [05:06] <StevenK> It took about 5 Brewfest Brews to get tipsy [05:06] <StevenK> I should compare my level 21 and level 44 warlocks [05:07] <Hobbsee> you all forgot about the "when someone is found to be committing crack, take a drink" [05:07] <Fujitsu> Hobbsee: That sounds dangerous. [05:08] <ajmitch> when kmos files a bug, take a drink [05:08] <StevenK> Hahah [05:08] <Fujitsu> ajmitch: Has the right idea. [05:08] * ajmitch should behave now [05:08] <Hobbsee> ajmitch: shudder. [05:08] <StevenK> "When kmos files more than ten sync requests, take that number of drinks." [05:08] <Fujitsu> Haha./ [05:09] <ScottK> minghua: Hello back (much later). [05:10] <TheMuso> When kmos applise to become MOTU, skull ${Biggeest_Beer_Serving}. [05:10] <TheMuso> biggest [05:10] <TheMuso> s/Beer/Drink/ [05:10] <Hobbsee> TheMuso: now you really need to put down the crack pipe. [05:10] <Fujitsu> And the MC doesn't have the best track record of rejecting people.. [05:10] <ScottK> This is true. [05:10] <Hobbsee> oh, *applies* to become a MOTU. not actually gets it. [05:11] <StevenK> No, no. "If Kmos applies to become an MOTU, sober up immeadiately and smack him down." [05:11] <Fujitsu> Hobbsee: Aren't they the same thing? [05:11] <Fujitsu> StevenK: Heh. [05:11] <Hobbsee> Fujitsu: no. [05:11] <TheMuso> StevenK: haha [05:14] <TheMuso> Ouch. Planet is really screwing up. [05:14] * ScottK ponders something involving lots of fire or explosives. [05:15] <Fujitsu> TheMuso: How? [05:15] <Fujitsu> ScottK: Sounds good. [05:15] <TheMuso> Fujitsu: See latest planet post. [05:16] <Fujitsu> Is that particularly broken? [05:16] <TheMuso> DId you follow the link to the actual post from his blog? [05:16] <Fujitsu> I did. [05:17] <StevenK> Clicking the link for Daniel Robitaille's latest post, it works for me. [05:17] <TheMuso> Well the title for the post on planet and the actual blog don't match. [05:17] <Fujitsu> Have his ever? [05:17] <TheMuso> The links aren't broken up, just the titles. [05:17] <TheMuso> dunno [05:19] <StevenK> A common theme is they're all wordpress.com blogs [05:20] <StevenK> (all two of them) [05:20] * ScottK tries to understand how launchpad release notes qualify for planet Ubuntu??? [05:22] <Hobbsee> because ubuntu uses launchpad? [05:22] <Hobbsee> anyway, where's that drink? [05:22] <TheMuso> heh [05:23] <ScottK> Hobbsee: Do Ubuntu release notes go on planet? [05:24] <Fujitsu> Haha: [05:24] <Fujitsu> 16:23:43 < lee_> cab: they are permanent drives they only started doing this since I installed gibson [05:24] <Hobbsee> ScottK: usually someone copies them there, yes [05:24] <Fujitsu> That's a new one. [05:24] <StevenK> The Gutsy Gibson. Hum. I always knew Mel was an animal. [05:29] <pwnguin> ScottK: do we want them to? [05:30] <Hobbsee> ScottK: usually multiple people, actually [05:30] <ScottK> I dunno. It seems about the that planet is supposed to be ABOUT Ubuntu and while Ubuntu uses LP, it's a separate thing. [05:30] <StevenK> I just think ScottK doesn't want to see the L word more than he needs to ... [05:30] <Hobbsee> yet the offtopic posts on launchpad don't concern you? [05:30] <pwnguin> well he can keep pretending that canonical and ubuntu aren't joined at the hip [05:31] <ScottK> pwnguin: It's Canonical that claims they are separate things. [05:31] <ScottK> Hobbsee: Was that directed at me? [05:32] * ScottK got a head start on the drinking game tonight. [05:32] <StevenK> Hah [05:32] <Hobbsee> ScottK: yeah [05:32] <StevenK> Why, did you look at Kmos' bug page? [05:32] * StevenK ducks [05:32] <Hobbsee> didnt' realise that you didn't say both lines when i was first typing [05:32] * Hobbsee beats StevenK [05:32] <StevenK> Ouch! [05:32] <ajmitch> duck quicker next time [05:32] <StevenK> That was directed at ScottK, though [05:32] <ScottK> No, the drinking is unrelated to Ubuntu. [05:33] <Hobbsee> ScottK: the offtopic posts on planet ubuntu are far greater in number than the LP ones - yet i havent seen you comment on them yet. [05:33] <StevenK> ScottK: Oh, so it's Launchpad. [05:33] * StevenK chuckles [05:33] <ScottK> Hobbsee: Ah. Well at least those are by people who are involved in Ubuntu. [05:33] <ScottK> But yeah. It's Launchpad. [05:33] <StevenK> So are Launchpad people, by that extension. [05:33] <Hobbsee> and launchpad are not? [05:34] <ScottK> StevenK: No, they are developers of a system we happen to use. === doko__ is now known as doko [05:34] * Hobbsee suspects he's just ranting about anythign LP, just because he can... [05:35] * pwnguin wonders if automatix deserves the kind of consideration LP gets [05:35] <ajmitch> Hobbsee: he wouldn't do that [05:35] <Hobbsee> pwnguin: definetly not. [05:35] <StevenK> ScottK: Okay, and when cprov spends an hour fixing a buildd, that doesn't relate at all? [05:35] <ScottK> StevenK: That's him fixing his proprietary service. [05:35] <pwnguin> Hobbsee: how about medibuntu? [05:35] * ScottK rants about Automatix too. [05:35] <Hobbsee> pwnguin: probably OK. ubuntu studio, etc, also go to there with their release notes [05:36] <StevenK> And Mythbuntu [05:36] <Hobbsee> yaeh, that too [05:36] * Hobbsee giggles, remembering the planet editorial spec [05:36] * StevenK wants a machine with a DVB card so he can try it [05:40] <pwnguin> ScottK: so what do you think about the affero PL? [05:40] <ScottK> pwnguin: You didn't happen to see me discuss that on #debian-devel and you're trying to get me started again? [05:41] <pwnguin> i dont watch debian-devel [05:42] <pwnguin> but maybe i'll hound up a log === Igorots is now known as Knightlust [05:43] <Amaranth> automatix people are on planet [05:43] <Amaranth> jdong is on there, isn't he? [05:43] <ScottK> pwnguin: Short version is I don't think it's DFSG free. [05:43] <ScottK> jdong is not an Automatix guy. [05:44] <Amaranth> he used to be [05:44] <ScottK> jdong runs *-backports which is an official Tech Board blessed part of the Ubuntu project. [05:44] <Amaranth> no one is an automatix guy anymore, automatix is gone [05:44] <ScottK> Three cheers for that. [05:44] <Amaranth> and i know what jdong does :P [05:46] <pwnguin> there's automatix2 [05:46] <Amaranth> there won't be for hardy [05:47] <pwnguin> how'd that happen? [05:47] <Amaranth> i hang out with the main dev a couple times a week :P [05:48] <Amaranth> and he was at uds [05:48] <pwnguin> i see [05:48] <Amaranth> we went through the list of what automatix is good for that _isn't_ easy to do with stock ubuntu [05:48] <Amaranth> it came down to adding a couple things to ubuntu-restricted-extras and some x86 on x86-64 stuff [05:49] <ScottK> Cool. [05:49] <Amaranth> which afaik is just skype and flash [05:50] * ScottK will grumble about Envy posts on planet, just to be fair. [05:50] <Amaranth> envy apparently got a lot saner too [05:50] <Amaranth> i think mvo helped the guy out [05:50] <pwnguin> there has got to be a better way than how envy works [05:51] <pwnguin> good [05:51] <Hobbsee> Amaranth: why didn't i hear about the extra stuff added to u-r-e then? [05:51] <Hobbsee> or have i, and not responded? [05:51] <Amaranth> Hobbsee: because nothing has been added [05:52] <Amaranth> and i think it was more a matter of opinion on whether or not things should be added to it [05:52] <Hobbsee> Amaranth: no bug has been filed, either. [05:52] <ScottK> So I'm reading about PackageKit on planet. Does this mean we're giving up on Debian package management in the long run? [05:52] <Hobbsee> yeah, true [05:52] <Amaranth> ScottK: PackageKit is just a frontend [05:52] <ScottK> Amaranth: For what? [05:52] <Amaranth> apt/dpkg [05:52] * pwnguin would rather hear more about policyKit on the planet. that stuff's scary [05:53] <StevenK> I'm guessing it's backend-agostic, and deals with both rpm/yum and apt/dpkg [05:53] <Amaranth> right [05:53] <StevenK> Like SMART [05:53] <Amaranth> no [05:53] <StevenK> Except SMART is dumb [05:53] <ScottK> So it's more of an Adept/whatever Gnome uses replacement? [05:53] <Amaranth> it's actually a gnome-app-install/update-notifier replacement [05:53] <pwnguin> synaptic? [05:54] <ScottK> Dunno. Never used Gnome, but that sounds right. [05:54] <ScottK> OK, so we're going to make it easy to mix RPM and Debian packages? [05:54] <Amaranth> no [05:54] <ScottK> Good. [05:54] <pwnguin> i think we're making it easier to integrate package management with gnome [05:54] <ScottK> Great. [05:54] <Amaranth> it's just a distro-agnostic way for things to install packages [05:55] <pwnguin> wouldn't that need namespaces to be identical? [05:55] <slangasek> and why is that valuable? :) [05:55] <ScottK> OK. I'm having a hard time reconciling distro-agnostic and not packaging system agnostic. [05:55] <Amaranth> slangasek: consistent GUI [05:55] <minghua> Making it easier for users to switch distros, I suppose. [05:55] <ScottK> Amaranth: So it's a consistent gui for different things? [05:56] <Amaranth> ScottK: right [05:56] <pwnguin> the backend is probably not distro-agnostic then ;) [05:56] * slangasek is not a distro agnostic, he knows which packaging system he prays to [05:56] <ScottK> And this is a good thing? [05:56] <minghua> ScottK: Yes, it has different backends for APT/RPM/etc. [05:56] <Amaranth> it's basically a way for everyone else to get gnome-app-install instead of just ubuntu :P [05:56] <slangasek> yeah, who cares about them? :) [05:57] <pwnguin> psh [05:57] <Amaranth> but it does the policykit thing too so that's useful [05:57] <pwnguin> they can learn to compete ;) [05:58] <Hobbsee> interesting. video's dont owrk onw [05:58] <slangasek> here, let me fix that for you with VideoKit [05:58] <Amaranth> slangasek: that's called gstreamer [05:58] <ScottK> Amaranth: What is the "poicy kit thing"? [05:58] <StevenK> And then you'll need to manage all of your kits with KitKit [05:58] <slangasek> it's called that /today/ [05:59] <Amaranth> as used by DesktopKit [05:59] <Amaranth> aka GNOME [05:59] <slangasek> I manage mine with KitKat [05:59] <TheMuso> heh [05:59] <StevenK> slangasek: Just for that, I'm breaking your fingers [05:59] <StevenK> :-P [05:59] <Amaranth> ScottK: basically instead of running the whole app as root you have a daemon that speaks dbus [05:59] <Amaranth> and dbus system activation starts it on demand [05:59] <minghua> Oh, are we talking about PackageKit or PolicyKit? Because they are completely different things. [05:59] <Hobbsee> StevenK: you might have to coordinate alpha 1, if you do... [06:00] <Amaranth> i said PackageKit was useful because it used PolicyKit [06:00] <StevenK> I didn't say I'd break all of them. [06:00] <ScottK> Amaranth: When it starts it, what user does it start it as? [06:01] <Amaranth> ScottK: not sure [06:01] <Amaranth> probably root? [06:01] <ScottK> I'm still not getting the benifit then. [06:01] <Amaranth> less code running as root [06:01] <Amaranth> and no GUI code [06:02] <minghua> ScottK: Probably one backend and one front end. [06:02] <minghua> Backend runs as root and frontend runs as ordinary user. [06:02] <pwnguin> policyKit itself is about not running gtk as root [06:02] <pwnguin> etc [06:02] <minghua> I don't claim I know PackageKit though. [06:02] <StevenK> ScottK: The whole point is to minimise down as much as possible the code that runs as root. [06:03] <pwnguin> its still a massive transition that's going to be painful, i think a few people already found that out ;) [06:03] * TheMuso hopes the policykit stuff happens. It will also mean admin tools are accessible to users using assistive tech. [06:03] <ScottK> StevenK: Well that makes sense. I got confused when he said it ran as root anyway. [06:03] <StevenK> ScottK: PolicyKit is a very small helper running as root which the GUIs talk to using dbus [06:04] <pwnguin> policy-kit is going to make an already confusing time with thinkfinger more confusing =( [06:04] <ScottK> I think I'm just going to say it's Gnome and I don't need to understand it. [06:04] <pwnguin> heh [06:05] <Hobbsee> ScottK: but you might end up switching to gnome :P [06:05] <ScottK> Hobbsee: I might. I might alswo switch back to Windows. I don't worry to much about either of those eventualities. [06:07] <Hobbsee> ScottK: then how would you yell at redmond? go over there? [06:08] <ScottK> I'm not saying there's any real risk of that, just saying the risks are roughly equivalent. [06:08] * StevenK is of the opinion that Gnome looks .... I don't know, prettier and shinier than KDE. [06:09] * ScottK finds KDE more comfortable. [06:10] <pwnguin> GNOME has a lot of gray for a "prettier and shinier" than KDE [06:11] * Hobbsee killed a whole lot of the grey from gnome [06:11] * StevenK quite likes grey. [06:13] <pwnguin> Is the double panel a proven usability thing, or just an artifact of history? [06:21] * ScottK discovers hardy no longer has libmilter0, just libmilter1 and gives up and goes to bed. [06:21] <ScottK> Good night all. [06:23] <LaserRock> we've really added 18 new MOTUs since May? [06:31] <Hobbsee> pwnguin: you can certainly fit more stuff on there [06:31] <Hobbsee> LaserRock: ponies! [06:31] <Fujitsu> Hobbsee: That's another reason for the switch to EXA. Video overlays work. [06:32] <Hobbsee> Fujitsu: ahhh. my videos just crash now :) [06:32] <pwnguin> Hobbsee: on the contrary I can fit more programs without gnome panel getting in my way at the bottom ;) [06:32] <Fujitsu> Hobbsee: Hah. [06:32] <Hobbsee> Fujitsu: interesting. [06:33] <Hobbsee> The program 'totem' received an X Window System error. [06:33] <Hobbsee> This probably reflects a bug in the program. [06:33] <Hobbsee> The error was 'BadAlloc (insufficient resources for operation)'. [06:33] <Hobbsee> (Details: serial 99 error_code 11 request_code 140 minor_code 19) [06:33] <Fujitsu> That sounds right [06:34] <Hobbsee> then again, this is xaa still. [06:34] <Fujitsu> Right. [06:47] <dholbach> good morning [07:07] <dholbach> Happy REVU Day! === doko_ is now known as doko === LucidFox is now known as Sikon_Stargate === \sh_away is now known as \sh [08:39] <\sh> moins [08:41] <pwnguin> wow, ipkg is really based on dpkg, huh [08:43] <\sh> pwnguin, ipkg as in linux for routers? ,-) [08:43] <pwnguin> yea [08:44] <pwnguin> well, i think it started out for ipaq [08:44] <pwnguin> but i just got ahold of a spare router [08:44] <dholbach> so how's the REVU day coming along? [08:45] * dholbach looked at a bunch of 'in progress' needs-packaging bugs already and the revu uploads connected to them [08:51] <Sikon_Stargate> I'd like to request review of two updated packages: http://revu.tauware.de/details.py?package=qdvdauthor http://revu.tauware.de/details.py?package=avidemux [08:52] <dholbach> Sikon_Stargate: looking at qdvdauthor [08:52] <TheMuso> Sikon_Stargate: Looking at avidemux. [08:53] <dholbach> Sikon_Stargate: did you rebase on the marillat package? [08:58] <dholbach> Sikon_Stargate: I'm just diffing the latest debian-multimedia upload and yours: why the -dbg package? why the dropped patch? why dvdauthor/dvd-slideshow/mjpegtools as Build-Depends? [08:58] <nand`> hi MOTUs! I'd like a review of the package ike please! (one advocate already). Thanks! http://revu.ubuntuwire.com/details.py?package=ike [09:00] <dholbach> Sikon_Stargate: added comments to qdvdauthor page [09:01] <Sikon_Stargate> dholbach> I merged the Ubuntu version [09:01] <Sikon_Stargate> Ubuntu has 1.0.0~rc1, debian-multimedia.org has 1.0.0~rc2, and this is 1.0.0~rc3 [09:02] <dholbach> debian-multimedia has 1.0.0~rc3 too [09:02] <dholbach> http://www.debian-multimedia.org/pool/main/q/qdvdauthor/ [09:02] <dholbach> I understand the need for the desktop file changes and they are mentioned in a former revu upload [09:03] <dholbach> the other changes I don't understand :) [09:03] <TheMuso> Sikon_Stargate: With avidemux, why did you migrate to cmake? Or is that an upstraem change? [09:04] <Sikon_Stargate> Upstream only had autotools for 2.3. With 2.4, they offer a choice between autotools and cmake. === Sikon_Stargate is now known as LucidFox [09:04] <TheMuso> Sikon_Stargate: Right. So why change? [09:04] <LucidFox> Personal preference, I guess. [09:05] <LucidFox> If autotools is preferable, I can change to that. [09:06] <\sh> LucidFox, is upstream going the cmake way now, and offering this as a transitional change? [09:06] <dholbach> nand`: can you change the entry in debian/changelog to (LP: #148103)? [09:06] <dholbach> nand`: or if you agree I do it on my own and upload right away [09:06] <LucidFox> Upstream has no preference for a specific build system, as far as I can tell. [09:06] <nand`> dholbach: If it's okey with you, no pb, thanks! [09:07] <dholbach> nand`: ok, uploading it! congratulations! [09:07] <LucidFox> Both will be supported at least in the near future. [09:07] <TheMuso> LucidFox: Ok thats fine then. [09:07] <nand`> dholbach: yay! [09:08] <\sh> wow...I found a way to gpg sign stuff without having my gpgcard with me :) [09:09] <soren> \sh: ? [09:09] <\sh> debuild -S -k'<your key id>!' <-- the exclamation mark is important...fyi [09:09] <LucidFox> dholbach> For qdvdauthor, I dropped the patch because it results in qplayer and qslideshow not building, and the Ubuntu version builds them. [09:09] <LucidFox> (the "make" lines are commented out in the patch) [09:10] <\sh> soren, I have a signing subkey on a gpg card...but if you don't have it handy..you are fcked, if you don't have this trick handy with the exclamation mark ,-) [09:10] <TheMuso> LucidFox: Why did you remove the Bugs field in debian/control: [09:10] <LucidFox> TheMuso> for avidemux? [09:10] <TheMuso> LucidFox: Yes. [09:11] <LucidFox> Oversight. I'll re-add it. [09:11] <Fujitsu> \sh: Can't you only use subkeys for encryption? [09:12] <\sh> Fujitsu, no...you can use subkeys for encryption, signing and authentication :) [09:12] <dholbach> LucidFox: this is the current debdiff between debian-multimedia and your proposed version: http://daniel.holba.ch/temp/qdvdauthor.debdiff [09:13] <\sh> phew../me has a headache...clean restart yesterday evening ...:( [09:13] <TheMuso> LucidFox: If the avidemux binary package is transitional, why is it architecture any? [09:14] <dholbach> LucidFox: desktop changes are fine, if you want to drop the patch, that's fine, but please document the change in debian/changelog and don't change debian/rules and debian/control for that, let's try to keep the diff small, also: I understand the added Depends (could some of them be recommends?), but why do you add them as Build-Depends? are they needed on the build machine to build the package? [09:15] <TheMuso> LucidFox: And, if Christian Marillat made this package prior to Nicolai Spohrer, there is no reason to change who debianised it at the top of the copyright file. [09:16] <TheMuso> LucidFox: According to the diff, yes this package was originally debianised in 2002, so that should certainly be left as it is IMO. [09:17] <TheMuso> LucidFox: You also changed the copyright authors/upstream authors. You haven't listed the years of copyright for these author's code contribution. [09:18] <LucidFox> dholbach> So I should leave dpatch support in debian/rules even though there are no patches? [09:19] <dholbach> LucidFox: yes, else you divert from the debian packaging just for the sake of a dropped patch [09:19] <dholbach> nand`: are you sure that bug 148103 is the bug you want to close with the ike upload? [09:19] <ubotu> Launchpad bug 148103 in ubuntu "[needs-packaging] Request for packaging, VPN client" [Wishlist,Triaged] https://launchpad.net/bugs/148103 [09:19] <nand`> dholbach: Yes, this is this one. [09:20] <TheMuso> LucidFox: I also don't see what changes Nicolai Spohrer made mentioned in the changelog at all. [09:20] <nand`> dholbach: the name is not explicitely mentioned, but this is it [09:20] <LucidFox> All right. I will also leave the patches in debian/patches and only remove them from 00list. [09:20] <dholbach> nand`: thanks a lot for that [09:21] <dholbach> LucidFox: great, that change is easy to merge :-) [09:21] * dholbach hugs LucidFox [09:21] <TheMuso> LucidFox: And, the only thing I have against cmake, is that vast quantities of debian/rules are altered by this update. Like dholbach has said for your other package, this diverges from Debian Multimedia a lot, which means more merging work in the future. [09:21] <dholbach> also it helps if you document every bit you change in the changelog [09:22] <TheMuso> At this point, I do not feel comfortable giving this an ack. [09:22] <LucidFox> debian-multimedia.org won't package avidemux until it reaches 2.4 final - Marillat said so [09:22] <dholbach> Somehow I knew that it was persia who added "It's REVU Day! Packagers; announce your packages, Reviewers: Add as many hammers as you can." to the topic :-) [09:22] <pwnguin> what's the process to get a package sync'd from experimental? [09:22] <TheMuso> Nevertheless, any packaging differences means more merging work. [09:23] <dholbach> pwnguin: file a sync request and just mention that it's experimental instead of unstable [09:23] <dholbach> LucidFox: if we decide to ship an unstable avidemux that's our decision [09:23] <dholbach> LucidFox: still we can try to keep the packaging delta small [09:25] <TheMuso> dholbach: The diff as it stands between both debian/ dirs is 19K. [09:25] <dholbach> right [09:26] <pwnguin> dholbach: ok, i guess the terminology is a New, not a Sync [09:26] <dholbach> pwnguin: is it a new package that has never been in ubuntu before? [09:26] <pwnguin> correct [09:26] <dholbach> then it's still a sync :) [09:26] <pwnguin> ok [09:27] <dholbach> but right, best ask in #ubuntu-devel - I'm not sure that experimental is automatically synced [09:28] <pwnguin> im pretty sure its not [09:28] <pwnguin> i figured there'd be some method of triggering a discussion on inclusion from experimental [09:29] <dholbach> either ask for it in #ubuntu-devel or file a normal sync bug, just stating that it's experimental you're talking about [09:32] <mok0> I was asked to make an icon for xtide for the merge. Now I've done it, I have png files in sizes 128 -> 16 pixels. Now I need to know how to add them to the package, and where to install them. [09:34] <minghua> mok0: I think the place to install them is /usr/share/icons/hicolor/*/, but adding them to the package would be a challenge if you don't repack upstream tarball. [09:34] <mok0> minghua: I don't want to do that [09:35] <mok0> repack tarball I mean [09:35] <minghua> mok0: BTW is there any definitive conclusion about Torque's licensing? [09:36] <dholbach> mok0: check out ekiga to find out how you can add icons without changing the tarball [09:36] <LucidFox> dholbach> https://bugs.launchpad.net/ubuntu/+source/qdvdauthor/+bug/164815 - I have attached a new debdiff. [09:36] <ubotu> Launchpad bug 164815 in qdvdauthor "qdvdauthor 1.0.0~rc3" [Undecided,In progress] [09:36] <minghua> mok0: You can apply some uuencode/uudecode magic then. [09:36] <mok0> No I don't think so. Didn't we agree that the package could go into universe? [09:36] <mok0> uuencode, yes I can try that [09:36] <minghua> mok0: I didn't read the IRC log, I only read the mail to motu-science. [09:36] <mok0> I can also send the icons upstream [09:36] <LucidFox> (also uploading the new version to REVU at the moment) [09:37] <dholbach> LucidFox: does it still build? [09:37] <mok0> minghua: Is there a formal body within ubuntu to clarify license matters? [09:37] <dholbach> LucidFox: you remove the dpatch build-dep [09:38] <LucidFox> oops! [09:38] <dholbach> you might also want to remove "+ * Dropped dpatch support from debian/rules, no patches left." [09:38] <minghua> mok0: There should be, I'm not sure which though. Maybe archive admins. [09:38] <dholbach> LucidFox: I'll review the patch in a bit again, please add the link to the debian-multimedia source package again in the bug [09:38] <mok0> minghua: so the package needs to go through ordinary review, then [09:39] <mok0> ... perhaps it can go into multiverse [09:40] <minghua> mok0: I don't quite understand what you mean. It always needs to go through review, whether for universe or multiverse. [09:40] <mok0> minghua: I was thinking that a license clarification could be made before people started wasting time on the package [09:41] <mok0> minghua: It would be really useful to get torque into ubuntu, though [09:41] <minghua> mok0: Let me have a look at the license. [09:41] <minghua> mok0: Yeah, I'm really insterested in Torque. [09:41] <mok0> minghua: you want me to pastebin the license? [09:42] <LucidFox> Building qdvdauthor now, also reuploaded the debdiff [09:44] <mok0> minghua: http://paste.ubuntu-nl.org/45898/ [09:46] <minghua> mok0: I was reading it on REVU, but thanks anyway. [09:46] <minghua> mok0: Looks pretty free to me. The only problem would be the advertise clause. [09:47] <mok0> minghua: yes [09:47] <seb128> hi [09:47] <mok0> minghua: do you know what the policy is on that? [09:47] <dholbach> hey seb128 [09:47] * dholbach hugs seb128 [09:47] <seb128> is "Luca Falavigna <dktrkranz@ubuntu.com>" connected on IRC? [09:47] <dholbach> happy REVU day! [09:47] <seb128> dholbach: thanks ;-) [09:47] <dholbach> seb128: it's dktrkranz on IRC too [09:47] <minghua> mok0: I'd say go ahead and prepare for universe upload, I may look at it when I have time. [09:47] <seb128> dholbach: ok, so he's not around [09:48] <seb128> thanks [09:48] <dholbach> doesn't look like it [09:48] <minghua> mok0: No idea about the advertisement clause. It may be indeed not DFSG-free. Ubuntu probably don't care, though. [09:49] <seb128> his tora upload looks like typically something that should be on sync with Debian, changes are a call to dh_icons and a builddep change [09:49] <seb128> and he didn't send the changes to debian [09:49] <mok0> minghua: ... isn't multiverse meant for weird license issues like that? [09:50] <minghua> mok0: To be honest with you, I don't know exactly what is "free" in Ubuntu's terms. I know there are differences with DFSG, though. [09:50] <minghua> mok0: For example, IIRC, CC-BY-SA is free for main/universe in Ubuntu, but not DFSG-free for Debian. [09:50] <LucidFox> o_O why? [09:51] <mok0> minghua: ok [09:51] <mok0> minghua: you feel like reviewing it ;-) [09:52] <minghua> mok0: The problem is that nobody else seems interested in cluster computation stuff. :-( [09:52] <minghua> And I'm busy. [09:52] <mok0> minghua: I might lure someone else into reviewing it [09:52] <LucidFox> TheMuso> Regarding the transitional package, I listed the architecture as "all" because it contains no architecture-dependent files. Is this incorrect? [09:53] <mok0> minghua: perhaps we should form a cluster computing interest group [09:53] <TheMuso> LucidFox: Um... Let me check. I thought you set the transitional package to architecture any. [09:53] <LucidFox> wait, I did. [09:53] <slangasek> minghua: CC-BY-SA 2.0 (if I remember the version number right) appears to be acceptable for main, since they fixed the key bugs in version 1 [09:53] <LucidFox> It's any. [09:53] <LucidFox> So it should be all? [09:54] <TheMuso> Yes if it doesn't contain any architecture dependent files, which being a transitional package, it shouldn't. [09:54] <LucidFox> Thanks. [09:55] <LucidFox> Is it okay for the transitional package to contain a symlink /usr/bin/avidemux -> avidemux2_gtk? [09:55] <minghua> slangasek: Thanks for the clarification. [09:55] <minghua> slangasek: tango-icon-theme is still in non-free, though. [09:56] <TheMuso> LucidFox: If the package depends on another that contains that file, and the dependency is strictly versioned, yes it should be ok. As it is, theres no point, since a transitional package is only to pull in dependencies that replace it, and nothing else. [09:57] <slangasek> minghua: sorry, I just checked and I had the version number wrong; it's CC-BY-SA 3.0 that has the bugfixes [09:57] <slangasek> and tango-icon-theme lists 2.5 [09:57] <LucidFox> avidemux (transitional) depends on avidemux-gtk (= ${binary:Version}) [09:57] <minghua> slangasek: Ah, that makes more sense. [09:57] <LucidFox> as for the symlink, I don't think there's any point in having it in avidemux-gtk [09:57] <TheMuso> LucidFox: Yes, but as I said, a transitional package doesn't contain anything. [09:58] <mok0> minghua: re: clustercomputing, I got wulfware in gutsy, which is pretty nifty [09:58] <Riddell> siretart: how come vdr-plugin-xineliboutput had to be backported manually? [09:58] <dholbach> LucidFox: commented on it again [09:59] <minghua> mok0: We can talk about torque and cluster computing stuff later on -science list. [10:03] <mok0> minghua: sure [10:03] <mok0> norsetto: re xtide, I've made some icons myself [10:05] <norsetto> mok0: cool. Don't forget to license them. [10:05] <mok0> norsetto: How do I add them to the package? [10:06] <mok0> norsetto: I have never dealt with icons before [10:06] <norsetto> moko0: you have two ways: either you add them as .xpm in /debian [10:06] <norsetto> mok0: you have two ways: either you add them as .xpm in /debian (soory for the mispell) [10:07] <norsetto> mok0: or you uuencode them and add them in /debian. In this latter casse, you need to do on-the-fly decoding during build [10:07] <mok0> norsetto: and where are they to be installed? [10:08] <norsetto> mok0: they are for the .desktop file, right? In this case they go to /usr/share/pixmaps [10:09] <mok0> norsetto: I have several sizes, from 128 -> 16 pixels [10:09] <norsetto> mok0: you need to provide at least a 48x48 pixels one in there. You can also provide different sizes and install them in /usr/share/icons/hicolor and this also requires registration in gnome (using dh_icons) [10:10] <norsetto> for the .desktop file one 48x48 should be sufficient though [10:10] <mok0> norsetto: ok. What about KDE, then? [10:11] <norsetto> mok0: in 3.5 there is no icon cache, but it is foressen in 4, for which most probably we need to expand the debhelper script [10:12] <mok0> norsetto: ok, let's worry about that later, then [10:12] <norsetto> mok0: this link: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is useful for icons [10:12] * mok0 looks [10:13] <mok0> norsetto: thx, I'll read it carefully [10:13] <norsetto> mok0: np, hope it helps [10:14] <mok0> norsetto: hopefully I can get it done by today [10:15] <norsetto> mok0: take your time, there is no rush [10:16] <mok0> norsetto: I'm at home with a cold, so it can keep me from feeling sorry for myself :-) [10:16] <minghua> mok0: If you can send the icons to upstream and they release regularly, it may be smart just to include one 48x48 XPM icon in the Ubuntu upload. [10:16] <minghua> mok0: Then you don't need to play with uuencode/uudecode. [10:17] <mok0> minghua: It's an idea, I'll think about it [10:18] <minghua> mok0: Although OTOH, upstream needs to figure out where/how to install the icons as well. [10:19] <mok0> minghua: I will contact upstream and ask if he wants the icons. I guess he should also put the .desktop entry in there [10:20] <mok0> minghua: If he would just put the files in a directory, that would be fine I think [10:20] <minghua> mok0: Yeah, doing these things with upstream is always a good idea. [10:24] <mok0> What license should I use for the icons? GPL? [10:26] <LucidFox> dholbach> reuploaded [10:26] <norsetto> mok0: if the package is licensed with a GPL seems a good idea [10:26] <mok0> norsetto: I'll check [10:27] <LucidFox> norsetto> I have attached debdiffs for higlayout, woodstox and freecol. All of them build, and freecol runs. [10:27] <norsetto> mok0: don't use the SA-BY-CC 2.5 or debian will not add them though ..... [10:29] <norsetto> LucidFox: ok, looks good. For the time being we should limit to sync though. I wonder why debian did not consider using the free java, perhaps it is worth asking them? [10:29] <LucidFox> I already filed a debian bug for free-java-sdk in higlayout. [10:30] <LucidFox> However, it's not possible for woodstox and freecol. I modified them to build with icedtea, which is not in Debian. [10:30] <mok0> norsetto: xtide is GPL v. 2 [10:30] <LucidFox> (Specifically, they depend on classes only in Java 6, and not in Classpath yet.) [10:31] <norsetto> LucidFox: ah! ok [10:34] <norsetto> proppy: morning [10:35] <proppy> hi ! [10:37] <norsetto> proppy: how is your miserable monday? [10:37] <proppy> norsetto: nice [10:37] <proppy> I've just been playing with soya3d examples [10:37] <proppy> and will report a bug against its debian packaging [10:37] <proppy> very interesting [10:37] <proppy> :) [10:37] <proppy> (apt-cache show python-soya3d) [10:38] <proppy> norsetto: and yours ? [10:38] <norsetto> !info python-soya3d [10:38] <ubotu> Package python-soya3d does not exist in gutsy [10:38] <proppy> :( [10:38] <norsetto> !info python-soya3d hardy [10:38] <ubotu> Package python-soya3d does not exist in hardy [10:38] <norsetto> proppy: there you are :-) [10:38] <proppy> !info python-soya [10:38] <ubotu> python-soya: high level 3D engine for Python. In component universe, is optional. Version 0.13.2-3ubuntu2 (gutsy), package size 1073 kB, installed size 3924 kB [10:39] <proppy> !info python-soya-doc [10:39] <ubotu> python-soya-doc: high level 3D engine for Python. In component universe, is optional. Version 0.11.1-1 (gutsy), package size 1739 kB, installed size 2368 kB [10:39] <proppy> all the .py files in the tutorial are gzip by default [10:39] <proppy> and the data too [10:39] <proppy> you have to run something like find . | grep gz$ | gunzip [10:39] <norsetto> proppy: yes, thats debian policy if the size is above a certain limit (don't remember which one) [10:40] <proppy> tu be able to run them [10:40] <proppy> let me check [10:40] <proppy> (the size of the example against the limit of the policy) [10:40] <proppy> norsetto: and you how are you ? [10:40] <norsetto> proppy: they are in /usr/share/ right? [10:40] <proppy> on this bloody money [10:41] <proppy> yep [10:41] <proppy> /usr/share/doc/python-soya-doc/tutorial/game_skel-3.py.gz [10:41] <norsetto> proppy: money is all bloody ;-) [10:41] <proppy> /usr/share/doc/python-soya-doc/tutorial/data/blender/knife.blend.gz [10:41] <proppy> s/money/monday :) [10:41] <proppy> /usr/share/doc/python-soya-doc/tutorial/data/worlds/ferme.data.gz [10:43] <proppy> norsetto: is this the correct reference for the doc policy http://www.debian.org/doc/debian-policy/ch-docs.html ? [10:44] <norsetto> proppy: yes, I would think so [10:44] <proppy> cause they don't say that examples should be compressed [10:45] <imbrandon> moins [10:45] <proppy> imbrandon: hi [10:45] <imbrandon> heya proppy how goes it [10:45] <norsetto> proppy: well, the size limit is 4k [10:46] <imbrandon> proppy: anything more than 4k [10:46] <proppy> imbrandon: nice, I had steack and eggs for breakfast ! [10:46] <norsetto> proppy: just checked in dh_compress [10:46] <norsetto> proppy: swine :-) [10:46] <imbrandon> hehe :) [10:46] <imbrandon> ok opinions , how evil is this [10:46] <imbrandon> +builddist = $(shell lsb_release -si) install -g root -o root -m 644 \ [10:46] <imbrandon> - mirror.list debian/apt-mirror/etc/apt/mirror.list [10:46] <imbrandon> + debian/${builddist}-mirror.list debian/apt-mirror/etc/apt/mirror.list [10:47] <proppy> norsetto: dhcompress --exclude tutorial ? [10:47] <imbrandon> based on if its built for debian or ubuntu === cprov-away is now known as cprov [10:48] <proppy> hi [10:48] <proppy> oups :) [10:52] <proppy> maybe these files are to be put somewhere else for not to be compressed [10:54] * dholbach hugs proppy, Czessi, imbrandon and norsetto [10:54] <dholbach> how's it going guys? [10:54] <huats> morning proppy [10:54] <norsetto> proppy: the policy dictates that examples should be in /usr/share/doc [10:54] <LucidFox> norsetto> Incidentally, what do you mean by "we should limit to sync"? Limit to unmodified packages? [10:54] <huats> hey dholbach [10:54] <imbrandon> moins dholbach , good, just wakin up [10:54] <Czessi> Morning [10:54] <dholbach> hey huats [10:54] <norsetto> hiya dholbach! [10:54] <huats> proppy: apparently you did something this morning [10:55] <proppy> huats: ? [10:56] * proppy hugs dholbach [10:56] <proppy> norsetto: I get another package in debian : http://qa.debian.org/developer.php?login=proppy@aminche.com :) [10:56] <norsetto> LucidFox: I've never done this, but I assume that we should first sync as is from debian, and then patch it; I wouldn't know how to patch it first and then ask for it to be archived!? [10:57] <huats> proppy: apparently you did something that norsetto think might interest me... [10:57] <norsetto> proppy: so there: http://qa.debian.org/developer.php?login=norsetto@ubuntu.com [10:58] <proppy> norsetto: I beat you :) [10:58] <LucidFox> Hmm. If I ask the Debian developer to build-depend on icedtea-java7-jdk | sun-java6-jdk, which one is the LP build system going to pick? [10:58] <proppy> huats: I'll be glad to share, do you want me to guess ? [10:59] <norsetto> proppy: ok, I surrender :-) [10:59] <imbrandon> proppy / norsetto : http://qa.debian.org/developer.php?login=brandon@imbrandon.com ( ~50k popcon ) [10:59] <imbrandon> :) [10:59] <proppy> huats: are you interested in juce packaging ? [10:59] <proppy> huats: are you interesting in a swf backend for cairo ? [10:59] <norsetto> imbrandon: we hate you with all our gutsy :-) [10:59] <imbrandon> hehe [10:59] <proppy> huats: are you interested in versioning tiddlywiki with mercurial ? [11:00] <proppy> huats: are you interested in freesoftware poker ? [11:00] <imbrandon> swf backend for cairo ? [11:00] <huats> proppy: honnestly I am not sure :D [11:00] <norsetto> LucidFox: the selection is from left to right [11:00] <proppy> you beat me imbrandon :( [11:00] <huats> proppy: well poker, might be interested [11:00] <huats> :)à [11:00] <proppy> huats: are you interested in python ? [11:00] <proppy> huats: apt-get install python-poker2d [11:00] <LucidFox> Ah, then it should build. I'll ask him to merge the necessary changes. [11:00] <proppy> huats: apt-get source and improve please ! [11:00] <huats> proppy: I tend to be more and more interested in python actually [11:01] <proppy> huats: go so that the thing norsetto told you about me ? :) [11:02] <huats> proppy: the thing is I don't know... only norsetto knows it :) [11:03] <proppy> huats: norsetto seems to like introduce people to each others :) [11:04] <proppy> maybe he will upload some kind of dating site for ubuntu developers and mentors [11:04] <huats> proppy: oh, apparently it is related to your breakfast [11:04] <norsetto> proppy: I'm a pairing specialist ..... [11:05] <imbrandon> LucidFox: iirc it should pickup the first one listed first, but i would try it on a PPA first ( buildd simulation ) [11:05] <proppy> huats: steak and eggs ? [11:06] * imbrandon looks arround for some Mt. Dew [11:06] <proppy> imbrandon: want to help in the swf backend for cairo /join #osflash [11:06] <imbrandon> proppy: i really dont have the time to take on something new atm, but i think its interesting [11:06] <proppy> !info lib-visual [11:06] <ubotu> Package lib-visual does not exist in gutsy [11:06] <proppy> !info libvisual [11:06] <ubotu> Package libvisual does not exist in gutsy [11:07] <imbrandon> !info libvisual-0.4-0 [11:07] <ubotu> libvisual-0.4-0: Audio visualization framework. In component main, is optional. Version 0.4.0-1.1 (gutsy), package size 128 kB, installed size 400 kB [11:07] <imbrandon> :) [11:07] <proppy> imbrandon: I only hacked the curve_to in a couple of hour session, but it's definitly something achievable and interesting [11:07] <imbrandon> libvisual is the source package, the bot looks at binary packages [11:07] <proppy> imbrandon: how ok [11:07] <norsetto> proppy: you can't win with imbrandon [11:08] <norsetto> proppy: heisbrandon you know [11:08] <proppy> imbrandon: audio visualization framework, I'm not sure I get it :) [11:08] <imbrandon> proppy: when you play music in xmms or amarok it makes pretty stuff on your screen === proppy is now known as imwithbrandon [11:08] <imwithbrandon> imbrandon: nice [11:08] <imbrandon> lol [11:09] <imwithbrandon> imbrandon: in opengl ? [11:09] <imwithbrandon> imbrandon: where ? [11:09] <imbrandon> yes [11:09] <imbrandon> where what ? [11:09] <norsetto> imwithbrandon: if you can't win, join them (definetively good tactic :-)) [11:09] <imwithbrandon> imbrandon: in a new window ? [11:09] <imbrandon> yea in its own window most of the time, its plugin based, e.g. just a framework for any player to use [11:10] <imbrandon> and sometimes full screen like a screensaver [11:10] <imwithbrandon> imwithbrandon: rdepends ? [11:10] <imwithbrandon> imbrandon: nice [11:10] <imbrandon> depends on how its implmented [11:10] <imwithbrandon> imbrandon: I will look at the rdepends to get a sample [11:10] <imbrandon> :) [11:10] <imbrandon> i know amarok,i think xmms , and i think some others [11:10] <LucidFox> I also uploaded the libraries to REVU, if this will help matters anyhow. http://revu.tauware.de/details.py?package=libhiglayout-java http://revu.tauware.de/details.py?package=libwoodstox-java [11:11] <imwithbrandon> norsetto: you're the one who teach me this one :) [11:11] <imwithbrandon> imbrandon: ah totem thing is based on it [11:12] <norsetto> imwithbrandon: I plead guilty [11:12] <imwithbrandon> imbrandon: is there a way to hook it on any data flow ? (to display nice thing from the wiimote motion for example ?) [11:13] <imbrandon> hrm , never thought about it, i'm sure it wqould be POSSIBLE [11:14] <imwithbrandon> imbrandon: I will keep that in mind the next time I get a wiimote next to me :) === imwithbrandon is now known as proppy [11:14] <imbrandon> yea lots of things depend on it, [11:14] <imbrandon> imbrandon@hood:~$ apt-rdepends -r libvisual-0.4-0|wc -l [11:14] <imbrandon> 139 [11:14] <proppy> yep [11:19] <imbrandon> any DD's awake :) /me needs a sid upload [11:21] <LucidFox> dholbach> replied in the bug thread === LucidFox is now known as LucidFox_away [11:22] <proppy> huats: seriously is there some python thing you want to talk ? [11:28] <proppy> yeepee someone is packaging fluxus === dholbach_ is now known as dholbach [11:54] <persia> As I'm backscroll-lazy today, is anyone waiting for a REVU? === _czessi is now known as Czessi [11:56] <proppy> hi persia [11:56] <imbrandon> heya persia , not that i have noticed in the last bit [11:56] <persia> hi proppy [11:57] <proppy> persia: finally I'm not going to japan (this year) [11:57] <persia> imbrandon: Thanks. I'll just chase old ones then :) [11:57] <persia> proppy: You're not? Why not? [11:57] <persia> Oh, right, I remember. This is a good thing :) Congrats! [11:59] <proppy> persia: thanks :) [12:00] <persia> Does anyone know if 4-clause BSD is DFSG-free? [12:00] <persia> (+ advertising) [12:10] <seb128> DktrKranz: hi [12:11] <DktrKranz> hi seb128 [12:11] <seb128> DktrKranz: any reason you didn't send the tora changes to Debian? [12:12] <DktrKranz> seb128, IIRC, it was already reported. Anyway, I'm checking [12:14] <DktrKranz> seb128, you're right... it was a different issue. I'll do it right now. thanks. [12:15] <seb128> DktrKranz: no problem, thank you for sending the change to Debian, so maybe next time we can sync directly ;-) [12:22] <frenchy> Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV. I'm still awaiting my first advocate. See http://revu.tauware.de/details.py?package=me-tv. [12:24] <frenchy> I've run out of things to do so I invite you to "let me have it". [12:26] <frenchy> persia: linda/lintian complete. No errors except for the menu file which has section="Applications/Viewers" which is now the new place for "Apps/Viewers". [12:26] <frenchy> persia: Apparently, the rules haven't caught up. [12:27] <persia> frenchy: Try the hardy lintian & linda. They understand. [12:27] <frenchy> persia: Will do, thanks. [12:28] <frenchy> persia: Obviously REVU is using the hardy ones because there are no errors/warnings on REVU. [12:29] <persia> frenchy: Yep. We try to reduce confusion :) [12:40] <ciphergoth> Just having a discussion in #ubuntu-devel, and asked a question which persia recommended I take here to get the right expertise: [12:40] <ciphergoth> Those of you who maintain both upstream and the Debian/Ubuntu package - what do you do in your source control? [12:40] <imbrandon> ciphergoth: what do you mean? [12:41] * persia looks at frenchy and StevenHarperUK as people currently working on that [12:41] <siretart> Riddell: because it provides a xine plugin for a new xine upstream version, which gets installed to a different directory [12:41] <ciphergoth> imbrandon: do you have one repository from which you build both the orig.tar.gz and the diff.gz? [12:42] <siretart> Riddell: it really needed manual changes to the source dependencies in order to get built against the correct (new) version of xine [12:42] <ciphergoth> or two repositories, one for the package and one for the Debian stuff? [12:42] <broonie> ciphergoth: A lot of that will depend on the particular VCS in use. [12:42] <siretart> I thought the changelog was declarative enough, obviously it wasn't.. [12:42] <ciphergoth> Is building the .orig.tar.gz and the diff.gz part of your build process? [12:42] <ciphergoth> broonie: darcs in our case [12:43] <broonie> I'd be surprised if there were many people building the orig.tar.gz by default; it's more trouble than it's worth to reproduce a bit for bit identical one. [12:43] <imbrandon> ciphergoth: if you mean keeping debian/ in RCS ? sure, but keep it seperate from the release tar [12:44] <imbrandon> ciphergoth: two branches is often enough [12:44] <Amaranth> right, just make sure your debian dir doesn't end up in your tarball and that should be enough [12:44] <broonie> ciphergoth: You might want to take a look at darcs-buildpackage [12:45] <imbrandon> ciphergoth: no one RCS branch holds the main code, the other holds debian/ , youy might peek at the way beryl/compiz* does it [12:45] <ciphergoth> my mistake - we use darcs for some stuff, but the package itself is just CVS. Currently we have one repository that contains both the main sources and the debian directory [12:46] <imbrandon> ciphergoth: then it would just be a simple matter of splitting that into two branches, so you can produce a orig.tar without the debian/ in ti [12:46] <imbrandon> s/ti/it [12:47] <ciphergoth> imbrandon - I'd be more inclined to produce the orig.tar.gz with a script that explicitly deleted the debian/ after checking out the sources [12:47] <imbrandon> ciphergoth: that would work too [12:47] <ciphergoth> maintaining branches in CVS is so painful [12:47] <Amaranth> imbrandon: not anymore :P [12:48] <Amaranth> imbrandon: distros do packaging, not upstream :) [12:48] <imbrandon> Amaranth: ahh well .... :) [12:48] <ciphergoth> Amaranth - we are upstream [12:48] <imbrandon> Amaranth: thats a good thing(tm) [12:48] <broonie> ciphergoth: There is cvs-buildpackage too. Dunno how it wants the repo but it's been well used [12:48] <imbrandon> ciphergoth: yea he was tlaking about my example of beryl/compiz* [12:48] <ciphergoth> imbrandon: ah, I see [12:49] <ciphergoth> we've written this package and packaged it for Debian/Ubuntu, and so we'd like to get it into Hardy Heron if poss [12:49] <imbrandon> they used to host debian/ too but now they just let the distros handle it [12:49] <ciphergoth> should we file a bug as usual, and just mention that we've done the technical work as far as we know? [12:49] <imbrandon> the most policticly correct way ( and better long term ) is to package it for debian and let it trickle down [12:50] <imbrandon> but you can also upload it to REVU for inclusion to ubuntu only atm [12:50] <ciphergoth> OK [12:50] <imbrandon> !REVU [12:50] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [12:51] <broonie> For Debian you can ask for package uploads to be sponsored on debian-mentors@lists.debian.org (or by finding a DD willing to do it otherwise) [12:51] <ciphergoth> I like the politically correct way, but we'll miss Hardy Heron that way won't we? It'll be a little while before our package hits unstable, and the Heron package list will be frozen soon, no? [12:51] <ciphergoth> We have a sponsor for the Debian side [12:51] <imbrandon> if it gets in unstable past NEW in debian soon , it will make it [12:51] <persia> ciphergoth: The cutoff requiring manual intervention is December 14th (to get through Debian NEW). [12:52] <imbrandon> if it gets close to the deadline you can always have a MOTU sponsor it via REVU [12:52] <ciphergoth> this is all amazingly helpful - thank you so much people [12:52] <imbrandon> we try to be :) [12:52] <persia> ciphergoth: You might also want to look at the pristine-source package, which is intended to generate a reliable orig.tar.gz from a VCS, although I don't know if it works with CVS or if it is useful for upstreams. [12:53] <frenchy> ciphergoth: Not sure what you mean. === LucidFox_away is now known as Sikon_Nausicaa [12:54] <frenchy> ciphergoth: Ohhh ... sorry I just caught up. [12:56] <ciphergoth> I take it we need to get as far as Debian sid before we can point at Debian as the upstream for Ubuntu? So if we hit Sid before the 14th, no need for REVU, but if not we should try and get it approved via REVU before then? [12:57] <imbrandon> yea [12:57] <imbrandon> exactly [12:58] <imbrandon> REVU can noramly be pushed in as little as 48 hours if everything falls into place, so if its not going to look like it will hit SID before say dec 10th you might start looking at MOTU review via REVU [12:58] <imbrandon> but untill then i would push to get it in debian [13:00] <persia> ciphergoth: If you're really close to NEW, there's also a manual process to sync if you miss the 14th, but there needs to be a good reason (like: your software is really cool and integrates perfectly) [13:00] <Riddell> siretart: ok, accepted [13:01] <imbrandon> heya Riddell :) [13:01] <siretart> Riddell: thanks! [13:02] <geser> StevenK: do you mind if I merge libglade? === ogra1 is now known as ogra [13:03] <StevenK> geser: Not particularly [13:06] <Riddell> hi imbrandon === ScottK2 is now known as ScottK === cprov is now known as cprov-lunch [13:28] <effie_jayx> One question [13:29] <persia> effie_jayx: Just ask [13:33] <effie_jayx> I updated my pbuilder to hardy... is that all I need for packaging stuff for hardy?, I remember downloading some script before... [13:34] <persia> That's all you need. You might want to grab lintian and linda from backports (or maybe even linda from hardy if the backport isn't complete yet). [13:39] <dholbach> frenchy: checking out me-tv [13:42] <persia> frenchy: me-tv commented [13:42] <persia> dholbach: I'm sure you'll catch more, but you might want to refresh so as not to dup too much :) [13:43] <dholbach> persia: thanks [13:43] * persia goes on to xca, unless anyone has any requests [13:46] * dholbach hugs persia [13:46] * persia peers about suspiciously, claiming innocence [13:46] <dholbach> can we use a fixed font in REVU comments? [13:46] <siretart> dholbach: sure [13:46] <dholbach> that'd be great :) [13:47] * dholbach hugs siretart [13:47] <siretart> hm. only where to set that? [13:47] <persia> siretart: You'd want to do it in the CSS, and set a class for the comment boxes [13:48] <ScottK> dholbach: Why do you want fixed fonts? [13:48] <siretart> persia: puh, I don't really have a clue about css. if someone could send me a patch to the existing css, I'd gladly commit it [13:48] <\sh> did I say that I hate php projects like tikiwiki? ,-) [13:48] <dholbach> ScottK: sometime I paste something from the commandline and it'd look better with fixed fonts [13:48] <dholbach> look at the last comment on the me-tv package [13:49] <geser> \sh: php projects in general or only those with open CVEs? [13:49] <persia> siretart: I'd be happy to prep a CSS patch (assuming I can remember the syntax), but I'll need the name of the class you're planning to apply for comments. [13:49] <\sh> siretart, <span class="comments"> blabla </span> and the css for comments is: comments { font-family: Courier } [13:49] <\sh> geser, those projects who are not fixing bugs and documenting it properly [13:49] <ScottK> \sh: Is everyone going to have that font installed? [13:49] * persia thinks \sh already provided everything required [13:50] <\sh> ScottK, I think Courier is a standard font-family, which matches as well monospace or something like that [13:50] <\sh> ScottK, but to be sure, please ask a expert for css rules ,-) [13:51] * persia checks the spec [13:51] <soren> \sh: "font-family: monospace" is much better. [13:51] <soren> \sh: It's the one from the css2 spec. [13:51] <persia> Should be "font-family: monospace" [13:51] <\sh> siretart, s/Courier/monospace/ [13:51] <\sh> thx soren :) [13:51] <\sh> thx persia [13:52] <frenchy> dholbach: persia: Thanks muchly. persia, are you emmet? [13:52] <persia> frenchy: Yes. Has my client eaten my /whois again? [13:52] <siretart> \sh: ok. but only where in the revu code? :) [13:53] <frenchy> persia: I'm new to IRC. [13:53] <\sh> siretart, where you print the comments :) [13:53] <persia> frenchy: No worries. it's just that about a month ago I was named "purple" on one network and "nobody" on another, for reasons I don't understand. [13:54] <siretart> \sh: somewhere in http://codebrowse.launchpad.net/~revu-hackers/revu/trunk/annotate/ajmitch%40ubuntu.com-20071113114707-9fcge2nn3arawg93?file_id=details.py-20060622101805-5b61dbbdd21644df, probably [13:54] <\sh> siretart, so something like print STDOUT "<span class=\"comments\">"+dbfield->comments+"</span>" and add the css stuff to your css file...or <span style="font-family: monospace">comments<span> === apachelogger_ is now known as apachelogger [13:55] <\sh> siretart, in <table> [13:55] <\sh> 88 <tr> <th>Date</th><th>Reviewer</th><th>Comment</th> <th>Advocating</th><th>Actions</th></tr> [13:55] <\sh> 89 %s [13:55] <\sh> 90 </table> [13:55] <\sh> 91 132.1.2 """ % (comments)) [13:56] <\sh> siretart, oh you add the <tr> stuff to (comments) [13:56] <\sh> siretart, I think then in getcomments method [13:56] <siretart> \sh: indeed [13:57] <frenchy> dholbach: A question about "No download files exist for this project." at URL you specified". Are you referring to the watch file. [13:57] <frenchy> ? [13:57] <siretart> \sh: let's try that with span and the css [13:57] <\sh> siretart, in getcomments function then... [13:57] <dholbach> frenchy: I clicked on the link in the debian/copyright file === Sikon_Nausicaa is now known as LucidFox [14:00] <frenchy> dholbach: I just removed the download files form the project site yesterday because people can get hem from the PPA now. What If I told you that it was downloaded from there ... then removed .. yes ... I am a smart-ass. [14:00] <\sh> oh I hate tikiwiki....this is so evil..why don't they add the CVE number for their sec fixes [14:00] <dholbach> ah ok [14:00] <ScottK> frenchy: If I was reviewing your package I'd not advocate it based on the source is missing. [14:02] <frenchy> ScottK: sorry, I don't understand. [14:03] <ScottK> Well if you put in Debian copyright that the source was gotten from a location and it's not there, how can I tell if I've got the correct upstream tarball or not? [14:03] <frenchy> ScottK: Ohhhh ... the doanload source. [14:03] <frenchy> ScottK: Yep, yep, yep ... Sorry it's 01:02 here. [14:03] <ScottK> No problem. [14:04] <frenchy> Do I need a man page for a GTK app anyway? [14:04] <frenchy> I actually have GNOME help. [14:04] <ScottK> That doesn't obviate the man page requirement. [14:05] <frenchy> ScottK: Is there a requirement for a man page? [14:05] <ScottK> frenchy: Generally Linitian will complain at you if it's needed. [14:06] * ScottK is still waking up, so I don't recall the exact rule. [14:08] <persia> There's not a requirement, but almost no REVU reviewers will advocate without one. If nothing else, it's a good way to get into the whatis and apropos databases. [14:10] <frenchy> Can I use my PPA as a download location? [14:10] <persia> frenchy: No. You need to have an upstream tar.gz. This is important to 1) allow other distributions to package the software, and 2) allow paranoid users to download the official original sources. [14:11] <persia> (that's what the /+downloads area is designed for: use it and enjoy) [14:13] * persia solicits nominations for the final review in this session [14:13] <frenchy> persia: But the PPA has that. [14:14] <frenchy> persia: I mean orig.tar.gz is the upstream right? [14:14] <persia> frenchy: No, the PPA has an orig.tar.gz that the PPA owner claims is the official version. [14:14] <frenchy> persia: ok ... yeah ... [14:14] <siretart> voilà! comments monospaced now! [14:14] <persia> frenchy: Technically, you're right. Further, in practice you're right. Even more, because you're the same person, you're right. On the other hand, the policy is there to cover the cases where this might not be true. [14:15] <frenchy> persia: Exactly the argument I was about to make. But ok ... rules is rules ... I'll just put the files back. [14:16] <frenchy> persia: Atleast that'll ge thte watch file working again. [14:16] <ScottK> dholbach: Are you keeping the list if MOTU Launchpad bugs now? [14:16] <persia> frenchy: Thanks. Sorry for the confusion, but the policy isn't really designed for upstreams packaging their own software :) [14:16] <persia> There is an official list? How should I submit my bugs there. [14:16] <persia> Also, isn't LaserRock still the LP liaison? [14:17] <dholbach> ScottK: no [14:17] <ScottK> dholbach: OK. [14:17] <ScottK> persia: I think you're right. I guess he still does it. [14:18] <ScottK> LaserRock: I think Bug #157064 is already on your list. It just got pushed from 1.1.11 to 1.2.1. It's a regression for goodness sake. I really wish LP developers would quit breaking stuff by accident. [14:18] <ubotu> Launchpad bug 157064 in soyuz "New release renders publishing history page unuseable" [Medium,Confirmed] https://launchpad.net/bugs/157064 [14:18] <frenchy> persia: Yeah, it seems strange to me that Canonical has put so much effort into LP to make it easy for people to develop for Ubuntu but there aren't a lot of developer/maintainers around. [14:18] <frenchy> persia: Ubuntu is new I guess. [14:19] <frenchy> persia: newish. [14:19] <ScottK> Personally, I see them putting a lot of effort into stuff that actually makes it harder, but that's just me. [14:19] <persia> frenchy: New, but also LP makes it easy to develop free software, and to develop Ubuntu. I don't think there is any special effort to develop free software on Ubuntu (although now that PPAs are released, this is less strictly true). [14:20] <dholbach> does somebody know if there was a 'motu' tag or something for those bugs? [14:20] <persia> dholbach: There's not a "motu" tag on most of the motu-interesting bugs to which I'm subscribed. [14:20] <frenchy> persia: Honestly, do you think that I'm doing this the wrong way around. Should I focus on developing a "kick-ass" application, gain popularity then let one of the pros package it? [14:20] <ScottK> dholbach: I think there was a tag, but I don't recall what it was. [14:20] <dholbach> hm ok [14:21] <frenchy> persia: Exactly what I was referring to .. someone pointed that out to me only today ... that LP is becoming great for developing for Ubuntu. [14:21] <persia> frenchy: Doesn't really matter. I'd focus on developing a "kick-ass" application, but it doesn't hurt to take a short detour to package it, and then just push it into the archives when you have a new release. if the application is interesting enough, a team may adopt it. [14:22] <geser> dholbach: https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=motu [14:22] <dholbach> "karma for uploads!" [14:22] <frenchy> persia: But I doubt that I'm going to get it done for hardy. It hasn't been a waste though ... now that it's packaged properly, I'm able to use the PPA and distribute the application that way. It's great. [14:22] <persia> There used to be karma for uploads, then it went away. Is it coming back? [14:23] <siretart> \sh: thanks for the hint with the css, applied and pushed to bzr [14:23] <persia> frenchy: You're really close. There's only a couple little things (other than the missing download link). [14:23] <dholbach> persia: I'm not sure there ever was [14:23] <\sh> siretart, cool :) [14:24] <persia> dholbach: back in Dapper I used to get a karma bump for uploads (and used to care enough to watch for that). [14:24] <dholbach> I can't remember that [14:25] <persia> It was right before the infinite karma issue began :) [14:25] <frenchy> persia: Thanks for the encouragement but I still then have to get someone to advocate it. I imagine that on;y people with a DVB card that use GNOME are going to be interested. [14:25] <frenchy> persia: Sorry, 2 people to advocate it. [14:25] <persia> frenchy: There are quite a few: once the packaging is clean, ping the mythbuntu team, who probably have a set of DVB testers somewhere. [14:27] <persia> If the app is good, and useful, they'll likely be happy to advocate it. [14:27] <ian_brasil> hey...i submitted a package to revu (mobileguide)...if someone has time i would really appreciate some feedback on it...thx [14:28] <frenchy> persia: Hmmm ... ok ... I'll bash it out tonight. [14:29] <persia> frenchy: Thanks [14:31] <frenchy> Ohh ... with the exception of the man page. That'll take time. [14:31] <frenchy> We've used the groff standard. [14:31] <\sh> finally, tikiwiki in gutsy fixed [14:33] <proppy> persia: do you know how to show the panel for asia langage input, I can't get my hands on it [14:36] <persia> proppy: Install SCIM, select a SCIM input method, and away you go. [14:37] <norsetto> proppy: 素晴らしい食事を有したか。 [14:37] <norsetto> proppy: does it make any sense :-) ? [14:38] <proppy> norsetto: I don't know kanji yet :) [14:38] <proppy> persia: thanks It was already installed I was just not remembering the command to launch :) [14:38] <geser> norsetto: ツ [14:39] <frenchy> persia: "No upstream changelog is installled in the package" ... There's a ChangeLog (I believe this to be the standard) in the top. [14:39] <norsetto> geser: ok, that looks like an y, so it must be "yes".... [14:39] <frenchy> persia: Did I mess something? [14:39] <frenchy> s/mess/miss/ [14:39] <frenchy> Actually, scratch that ... I like mess. [14:39] <geser> norsetto: more like a :) [14:40] <norsetto> geser: lol [14:40] <persia> このチャネルで英語だけお願いします [14:40] <norsetto> Just English we ask with this channel :-) [14:40] <persia> frenchy: It's not getting caught by dh_changelogs, and is not appearing in the binary packages. [14:41] <frenchy> persia: Oh ... I must have to add it as an EXTRA_DIST I think. [14:41] <frenchy> persia: Makefile.am [14:42] <persia> frenchy: No, it's a packaging thing. As upstream, you've done it perfectly. As the packager, you're just not installing the upstream file. [14:42] <geser> can we get a list similar to http://qa.ubuntuwire.com/ftbfs also for builds in DEPWAIT state? [14:43] <effie_jayx> ok.. I just devored the wiki and I need more info on lintian and linda... I know they are "static checkers, meaning they check the package without running any files, which is fast and secure" quoting a talk... but any use examples ? [14:43] <norsetto> persia: is it normal practice to upload new upstream versions every 5 days? [14:44] <geser> effie_jayx: linda package.dsc or lintian package.dsc [14:44] <persia> geser: That's a great idea. Are you up for porting the code, or do you need a hand? [14:44] <geser> effie_jayx: or on the binary .changes file if you've build the package [14:44] <persia> norsetto: Depends how closely upstream takes "release early, release often" to heart :) [14:45] <geser> persia: where can I see the code for it? [14:45] <persia> geser: http://people.ubuntuwire.com/~dktrkranz/ftbfs/ftbfs.py [14:46] <persia> dktrkranz: Please add a source link on the ftbfs page [14:47] <\sh> dholbach, from whom do we sync tikiwiki, if not from debian? [14:47] <frenchy> persia: I don't have a dh_changelogs installed and googling bought back 2 results. [14:48] <persia> frenchy: That's because I'm an idiot. "dh_installchangelogs" [14:48] <frenchy> persia: Sorry, Der ... I should've seen that. [14:48] <jdong> Amaranth / ScottK: I think there's a fundamental difference with Envy in that the author genuinely has Ubuntu's best interests in mind and takes in our advice without any resistance... [14:49] <dholbach> \sh: no idea - was it removed from debian? [14:49] <dholbach> *shrug* [14:49] <jdong> and what Envy tries to do is inherently prone to breakage to begin with, and probably isn't much safer if done by hand [14:49] <ScottK> OK. [14:49] <persia> Did Envy get on the "evil scripts" list? Why? [14:49] <effie_jayx> geser, thanks ... do I have to install linda and linthia... are they parto of some dev package? [14:49] <persia> effie_jayx: They are package names [14:49] <\sh> dholbach, looks like that...it's not findable via p.d.o [14:50] <geser> effie_jayx: linda and lintian are packages of their own [14:50] <\sh> dholbach, I'm just asking on debian-security [14:50] <persia> \sh: Ask p.qa.d.o, which also lists removed pacakges [14:50] <effie_jayx> ok [14:50] <jdong> persia: apparently it did.... [14:50] <jdong> !envy [14:50] <ubotu> envy is not needed or supported. Use the Resticted Manager to install binary drivers and see « /msg ubotu binarydriver » [14:51] <persia> jdong: I'd argue that's the appropriate response for ubotu, but am just surprised, as Envy seems to be as clean as is possible for what it does. On the other hand, it is completely unsupportable. [14:51] <geser> \sh: Debian bug #427655 [14:51] <ubotu> Debian bug 427655 in ftp.debian.org "RM: tikiwiki -- RoM, license issues, bad security history" [Normal,Open] http://bugs.debian.org/427655 [14:51] <jdong> persia: the old factoid was much harsher [14:51] * persia encourages the filing of a removal bug [14:51] <jdong> persia: but yeah, I agree with your evaluation -- it does what it does "the right way" but what it tries to do is inherently unsupportable [14:52] <\sh> geser, yeah...just reading the followeup [14:54] <\sh> damn [14:54] <\sh> work done for nothing [14:54] * jdong looks at the motumedia PPA build of mpeg4ip and wonders why it's been building for 24 hours [14:54] <soren> jdong: Stuff takes time :) [14:54] <jdong> util/testnasm.sh: line 8: test: =: unary operator expected [14:54] <jdong> uh oh bashismville [14:55] <jdong> what's our policy on disabling test suites? ;-) [14:55] <soren> jdong: Just make it use bash if that's the problem? [14:55] <jdong> it's rather unpleasant to have to run a 23 hour test suite on a 5 minute build. [14:56] <jdong> soren: yeah definitely will do [14:56] <soren> jdong: Look like an infinite loop to me.. [14:56] <jdong> soren: yeah, is there any way to interrupt the build? [14:56] <persia> jdong: Ask a buildd admin very nicely? [14:56] <soren> jdong: Ask in #launchpad [14:56] <jdong> I feel bad for plugging up an entire PPA builder for a day [14:58] <frenchy> persia: So I can't call it orig.tar.gz even on the download site? Is that what you mean? I have to manually rename it? [15:00] <persia> frenchy: It's best practice. Distributions that don't use debian-style packaging don't use orig.tar.gz. The rename is easy, and uscan will do it automatically if your watch file works. [15:01] <\sh> persia, please add +1 to bug #165187 [15:01] <ubotu> Launchpad bug 165187 in tikiwiki "Please remove tikiwiki from ubuntu archives" [Undecided,New] https://launchpad.net/bugs/165187 [15:01] <\sh> thx :) [15:01] * persia was waiting for ubotu to tell #ubuntu-bugs [15:03] <\sh> oh wow...jamendo has really good music [15:10] <persia> OK. REVU backlog down to 1 month. [15:13] <bddebian> Heya gang [15:13] * persia passes the reviewing torch to bddebian, and wanders off for a bit [15:13] <bddebian> Doh, hi persia [15:14] <persia> bddebian: Hey. Did you ever get scorched3d sorted, or do you still need someone to look at the 64-bit stuff? [15:14] <bddebian> persia: I'm not sure where Fuddl is at, I'll ask, thanks [15:15] <persia> Also, there's a darkplaces on REVU that looked interesting: still needs some work, but maybe worth watching. [15:15] <persia> bddebian: OK. I somehow passed that in my queue, so you've a priority bump if it's still not sorted :) [15:17] <frenchy> persia: Re: license missing in Glade file. The license is definitely in the about dialog. [15:17] <bddebian> persia: heh, OK [15:17] <frenchy> persia: Not sure that you mean. [15:18] <persia> frenchy: Right, the license for the program is displayed, but the glade source itself doesn't have a license header as an XML comment (I'm a stickler for these things: they may not matter to everyone). [15:19] <norsetto> I didn't know Linda had a sense of humour: http://revu.tauware.de/revu1-incoming/easycrypt-0711251540/linda [15:20] <persia> norsetto: You just have to catch her on the right day [15:20] <norsetto> persia: yes, pretty funky [15:20] <persia> Also, isn't that already in the archives? I don't understand why it appears in that section. [15:21] <frenchy> persia: And I like a stickler. Sorry, but I've been googling and dl'ing packages ... none of which have lead me to a find on how to do this. Do I just do it as a massive comment block? The issue is .. will glade clobber it? [15:21] <norsetto> persia: well, talking about uploading new upstreams every 5 days .... [15:21] <persia> frenchy: Yes, a massive comment block would keep me from saying anything. I don't know if glade preserves comments. [15:22] <persia> norsetto: There's an interdiff for that version that went through the queue recently as well. [15:22] <norsetto> persia: yes, one day after I uploaded the previous version [15:22] <persia> norsetto: No, .12 was one day after you uploaded the previous version :) The interdiff was for .15. Which version is up now? [15:23] <norsetto> persia: oh $deity, I lost the count [15:23] <persia> heh [15:24] <frenchy> persia: I'll do that then. I haven't touched development in weeks anyway. [15:25] <persia> frenchy: Thanks. Here's hoping you'll have no more Ubuntu-related excuse to defer development soon :) [15:26] <bddebian> heh [15:27] <geser> Hi bddebian === cprov-lunch is now known as cprov [15:31] <bddebian> Heya geser [15:47] * persia grumbles at `baz`, claiming that metasyntactic variables make poor command names. [15:50] <AuntyProton> Is this the place to ask for a package update? [15:50] <persia> AuntyProton: Only if you're proposing to do the work, and need some help [15:50] <dholbach> AuntyProton: best to file a bug on the package and tag it as 'upgrade' [15:50] <dholbach> .... or ask for help to do it yourself :-) [15:50] * dholbach hugs persia [15:51] <AuntyProton> <-- recoils in shock. [15:51] <AuntyProton> I'm not a programmer, I'm a science-fiction writer. [15:51] <persia> AuntyProton: Why in shock? A package update isn't too hard, and we're more than happy to help: we're just usually busy, and have a hard time getting to everything. [15:51] <dholbach> that'll give your share of science-fiction for the day :-) [15:52] <persia> AuntyProton: An update doesn't usually involve programming: it's mostly testing to make sure that the packaging for the old version still works with the new version. If you're an active user, and have a technical mind, you're all set. [15:52] <AuntyProton> I e-mailed the programmers of the package in question and they said they're not in charge of when their packages get updated. [15:52] <dholbach> persia is right, package upgrades are straight-forward in most cases [15:53] <persia> AuntyProton: On the other hand, if you're also busy, we understand. In that case, your best bet is to file a bug, and add the "upgrade" tag, as dholbach suggested. [15:53] <AuntyProton> Wait, you guys may not have understood. The programmers are currently distributing their newest version, but for some reason it's not on the Synaptic or Add/Remove lists. [15:53] <persia> The package is missing entirely, or an old version appears in Synaptic? [15:54] <AuntyProton> The old version is still in Synaptic and Add/Remove. [15:54] <persia> Ah. Which package? [15:54] <AuntyProton> Zim. It's a desktop wiki package. [15:54] <RainCT> Hi [15:55] <persia> We're planning on shipping 0.20 in hardy, but zim is likely one of our least well-maintained packages: I'm surprised it works for anyone at all. [15:55] * persia was looking at the bug reports last week [15:55] <AuntyProton> Hmm.... well, I use it. And the bug I found isn't life-threatening, just annoying. [15:56] <persia> AuntyProton: And it's fixed in 0.20? [15:56] <AuntyProton> Yeah. Or so the programmers claim. [15:56] <RainCT> what should I do if a tarball has capital letter in the name of the directory inside it? (dh_make complains about this) [15:57] <persia> AuntyProton: In that case, the best thing to do is either wait for hardy, or file a backports request. Given the poor maintenance record, I think someone needs to test and clean up the old bug reports before we can do a backport. [15:57] <AuntyProton> Okay, I can wait. Just wanted you guys to know there was a problem. [15:58] <persia> AuntyProton: Looking briefly at the package, I believe it should compile cleanly on gutsy: I just think we need to clean it up a bit before it gets a backport. Would you mind filing a bug from https://launchpad.net/gutsy-backports/+filebug, and subscribing me (LP name is "persia")? [15:59] * persia was planning to look at zim anyway, but this will be an incentive [15:59] <persia> Ah. I'm slow, as usual. Too bad. [16:03] <persia> RainCT: untar it, move the directory to the preferred "packagename-version" format (all lowercase), do your packaging (do you really want dh_make? It's just 4 files). Then when you build your package, the tools will be smart enough to ignore the capital letters in the upstream tarball. [16:04] <RainCT> persia: great, thanks [16:05] <persia> dholbach: Is there by any chance a more general documentation link? I'd like to encourage people to read packaging stuff, but also process & policy stuff. [16:06] <dholbach> process + policy stuff is http://wiki.ubuntu.com/UbuntuDevelopment [16:06] <dholbach> everything necessary should be linked from there [16:06] <persia> Right. MOTU/Documentation used to have a mix. Maybe we need two links. I'll go look at MOTU/Contributing again. [16:07] <dholbach> the packaging guide had its own list of documentation resources in the appendix [16:07] <persia> dholbach: Nevermind. The new list is incredibly nice, clean, and comprehensive. Beautiful work! [16:07] <dholbach> i just merged the two [16:08] <dholbach> and [[Include(...)]] it in the packaging guide [16:10] <frenchy> Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV. I'm still awaiting my first advocate. See http://revu.tauware.de/details.py?package=me-tv [16:12] <persia> dholbach: What do you have against inline patches? (not that I don't agree that those belonged upstream) [16:12] <frenchy> persia: Thanks for all your help. I look forward to hearing your comments. [16:12] <frenchy> dholbach: Sorry, my thanks to you to. I think that you raised some very good points. [16:13] <frenchy> dholbach: The diff is now pretty clean. === \sh is now known as \sh_away [16:13] <dholbach> I personally think it's cleaner and patches are easier to drop, etc - but that's the decision of each and every maintainer [16:13] <dholbach> persia: sorry ^ [16:14] <dholbach> persia: so I don't have anything against them, I just prefer to have them in a patch system - if somebody is convinced to have them inline, that's ok with me [16:14] <persia> dholbach: Ah. Makes sense. Just seeing your other comment I thought you had a negative view of one, as opposed to a positive preference for the other. No worries. [16:15] <dholbach> sorry, I should have put this more positively [16:15] <dholbach> frenchy: anytime :) [16:16] <frenchy> Gotta go to work in a few hours so ... goodnight ... french, out. [16:17] <dholbach> frenchy: take care [16:17] <persia> frenchy: Minor point (and not enough to reject): dh_installman is handy for pushing your manpages in the right place. I can't test, so I won't advocate. Nice job. [16:19] <frenchy> persia: got it. Bed, now, sleep. [16:19] <nxvl_work> persia: did you remember the FTBFS wich i was fixing yesterday? [16:20] <nxvl_work> persia: i've e-mail the DM and he said that he will fix this on next release, should i fix it anyway or wait? [16:24] <persia> nxvl_work: Your call. Generally I tend to push an Ubuntu upload if the package appears in one of the NBS lists, or I just feel like it (e.g. I use the package and am annoyed by it being broken, or I am supporting someone specifically). If there's no good reason to do Ubuntu faster, waiting for Debian is OK, but if that doesn't happen by 14th December, best to upload to Ubuntu anyway. [16:25] <nxvl_work> persia: so, wait until it's released, but on 14 December if it isn't, patch it? [16:26] <persia> nxvl_work: Unless it appears in the NBS lists, or there's another good reason to upload sooner, yes. [16:27] <nxvl_work> !NBS [16:27] <ubotu> Sorry, I don't know anything about nbs - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [16:27] <persia> nxvl_work: http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:27] <imbrandon> nxvl_work: the link os on http://qa.ubuntuwire.com [16:27] <imbrandon> s/os/is [16:28] <persia> ubotu: NBS is Some packages are no longer built from source as a result of various transitions. The reverse dependencies of these packages require an update. The current tracking list is available from http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:28] <nxvl_work> it isn't there, so lets wait, moving to next FTBFS [16:29] <persia> nxvl_work: By "isn't there", do you mean, "Doesn't appear in the directory listing" or do you mean "doesn't appear in any of the files"? [16:29] <nxvl_work> doesn't apear on http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:30] <persia> nxvl_work: That's just the list of package. Click on the links where the size > 0 to get a list of the packages that should be updated sooner. [16:30] <persia> Err.. The list of packages no longer built from source. [16:31] <Pici> !nbs [16:31] <ubotu> Some packages are no longer built from source as a result of various transitions. The reverse dependencies of these packages require an update. The current tracking list is available from http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:31] <persia> Pici: Thank you [16:31] <Pici> persia: no problem :) [16:31] <nxvl_work> persia: oh! that list show the packages doesn't build because of other packages? [16:32] <persia> nxvl_work: Sort of. That list shows the packages that won't exist soon, and for each, there is a list of packages that need to be updated so they won't break when the NBS packages are removed. [16:35] <persia> nxvl_work: As an example, there's been a transition of the libxmp library, so some packages need to be rebuilt or ported to the new API. The list of affected packages is available from http://people.ubuntu.com/~ubuntu-archive/NBS/libxmp2 [16:35] <nxvl_work> oh! ok ok [16:35] <nxvl_work> :D === cassidy_ is now known as cassidy === cassidy_ is now known as cassidy [16:57] <nxvl_work> why is there some packages on http://qa.ubuntuwire.com/ftbfs/#universe which i can't find on packages.ubuntu.com?? === rquinones is now known as xzased [17:02] <xzased> hiya all [17:02] <xzased> anybody knows how to unblock video ports? [17:04] <jpatrick> xzased: support in #ubuntu [17:05] <xzased> woops === asac_ is now known as asac [17:16] <LucidFox> What is the xine-lib transition mentioned in Bug #159338? [17:16] <ubotu> Launchpad bug 159338 in oxine "Re: Heads-up: small xine-lib transition in hardy" [Undecided,In progress] https://launchpad.net/bugs/159338 [17:20] <persia> LucidFox: https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002617.html [17:24] <LucidFox> If a package doesn't explicitly depend on libxine1, will rebuilding it fix the problem? [17:26] <persia> LucidFox: It's not a rebuild issue, it's that packages need to explicity depend on a front-end package, or they won't get one. [17:27] <persia> (well, it's a rebuild too, but that's not the important bit) [17:28] <LucidFox> Ah. [17:37] <nxvl_work> does install accepts list arguments like {item1,item2}? [17:40] <gpocentek> nxvl_work: {item1,item2} is a bashism if I'm not wrong [17:41] <nxvl_work> gpocentek: so it won't? [17:42] <gpocentek> nxvl_work: install can use this, but if you use it for a package, the build will fail [17:43] <nxvl_work> so instead of it i need to use a for [17:43] <gpocentek> I think so [17:44] <persia> nxvl_work: Which are you trying to do? There's a few make constructions which integrate batter in debian/rules than a for statement [17:46] <nxvl_work> persia: cereal, on the Makefile [17:46] * persia points at sections 4.5, 8.5, and 6 of the make manual for reference [17:46] <persia> nxvl_work: More context please [17:46] <nxvl_work> persia: on cereal package [17:47] <cprov> ScottK: ping, wonna talk about bug #157064 ? [17:47] <ubotu> Launchpad bug 157064 in soyuz "New release renders publishing history page unuseable" [Medium,Confirmed] https://launchpad.net/bugs/157064 [17:47] <nxvl_work> on it's Makefile it says "install fs/usr/share/cereal/{log,main}run $(PREFIX)/share/cereal/" [17:47] <ScottK> Yes? [17:47] <ScottK> cprov: ? [17:47] <nxvl_work> and the build error is that it doesn't fin file "}fs/usr/share/cereal/{log,main}run" [17:48] <ScottK> cprov: I'll discuss it if needed, but I just want it back like it was. [17:48] <geser> nxvl_work: looks like bashism [17:48] * ScottK isn't sure what's unclear about that. [17:48] <nxvl_work> so i think it's because isn't accepting the {} list format [17:48] <nxvl_work> geser: yep, it looks like it for me too [17:48] <persia> nxvl_work: Ah. If it's that small, it's probably best to just make it two lines, rather than either a for statement or nifty make recursion [17:48] <cprov> ScottK: it's impossible to revert the layout change and continue to present removal details. [17:49] <ScottK> Did someone ask for removal details? [17:49] <cprov> ScottK: so, you have to describe what you are missing from the table layout. [17:50] <ScottK> cprov: What I'm missing is the ability to figure out if a second or two what relates to what release. [17:50] <cprov> ScottK: distro-team, otherwise they can't track package deletions. [17:50] <ScottK> cprov: It takes an order of magnitude longer to orient and read through the narrative text. [17:50] <ScottK> cprov: Then why not just add another column to the table? [17:51] <persia> cprov: The issue is that it is long. I don't think +publishinghistory is bad, but if we could have another page with a quick table that listed all the published / superseded / removed entries, it would be a lot easier to check. [17:51] <cprov> ScottK: it's not just another column, at least more 3 and it will start scrolling horizontally [17:51] <ScottK> persia: The table already got pushed off the source package page. [17:51] * persia notes that it already scrolls horizontally for some screens [17:52] <cprov> persia: not in 1024x768, does it ? [17:52] <ScottK> cprov: OK. How about the old table at the top of the page and the new narrative flow underneath? [17:52] <persia> cprov: I don't have any devices at 1024x768, so I can't say [17:53] <ScottK> cprov: This is a sufficient barrier to work for me that I've decided not to volunteer for the revived motu-sru team because LP is too painful to use. [17:53] <ScottK> cprov: You may think I'm exaggerating, but I'm not. [17:53] <cprov> ScottK: sounds feasible, a short table as summary (version, series, status) each row linking to the corresponding noisy box below [17:53] <persia> cprov: That would be useful [17:53] <ScottK> cprov: Yes. All the stuff that was in the old table. [17:55] <cprov> ScottK: ta, comment the bug and I will arrange the things to get it fixed in 1.1.12 for you. [17:55] <persia> Does 1.1.12 mean December and 1.2.1 January (roughly)? [17:55] <ScottK> cprov: OK. [17:56] <cprov> persia: yes, 1.1.12 is the current milestone, that will be out around 20th Dec [17:56] <ScottK> cprov: Commented. [17:56] <cprov> ScottK: thanks [17:56] <persia> cprov: Thanks. [17:58] <ScottK> cprov: Next time could we arrange a) not to totally change pages on a release without publishing them to edge first and b) not wait until after a release to un-milestone something that isn't going to get fixed (I expected this fixed in 1.1.11 based on the bug status and had no chance to argue for it not getting dropped, so now I'm stuck for another month). [17:59] <cprov> ScottK: sure, i apologize for the mass-deferred bugs from soyuz 1.1.11, it shouldn't happen again. [18:00] <imbrandon> hrm [18:01] <cprov> ScottK: hopefully I can get this fix cherrypicked with other urgent UI fix. So, you can have it before xmas, take it easier. [18:01] <imbrandon> any python gurus got a sec or two to help me with some string manipulation [18:01] <ScottK> cprov: Thanks. [18:01] <ScottK> imbrandon: What is it? [18:02] <imbrandon> i'm wanting to strip a filename if it exists from a string ( url ) like blah.com/index.php would become blah.com/ [18:03] <imbrandon> i'm already stripping the http:// via [18:03] <imbrandon> url.content = url.content[7:len(url.content)] [18:03] <ScottK> If I was doing that, I'd split on '/' and take string[0] [18:04] <somerville32> Explode based on / and take the appropriate index? [18:04] <ScottK> Explode = split [18:04] <imbrandon> well some have paths too but i guess that would work [18:04] <imbrandon> and i could just cycle through them if they are not a file [18:04] <imbrandon> and rejoin [18:04] <ScottK> imbrandon: OK. Then split on '/' and take all but the last and put them back together. [18:05] <imbrandon> yup [18:05] <ScottK> Yeah. [18:05] <imbrandon> cool thanks, i'm a bit braindead sometimes [18:05] <ScottK> No problem. We all are. [18:05] <ScottK> It feels a lot better to help someone out than whine about LP. [18:06] * persia likes s/$.*$/[^/]*/\1/, but doubts it works in your program [18:09] <somerville32> find_user("persia")->terminate(); [18:13] <zul> hey [18:14] <RainCT> heh [18:21] <afflux> Can anyone please explain what "6. Package should not be native without an approved spec" in the "Guideline Criteria for New Package Inclusion" (https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage) means? Is it correct that a upstream package shouldn't contain any debian packaging? [18:23] <azeem> sort of [18:23] <azeem> however, you can just repack the upstream tarball to make it non-native, or (clunkier) still have it non-native, by just having the diff to the upstream debian packaging [18:26] <afflux> well, if I'm the upstream and I'm going to package my package for ubuntu, I'll need to have non-native upstream sources in the orig.tar.gz and my debian packaging seperated to them? [18:27] <ScottK> afflux: That's the best way to do it. [18:27] <ScottK> afflux: That's what I do where I'm also upstream. [18:28] <afflux> ScottK: hm, okay. [18:28] <afflux> ScottK, azeem: thanks for clarifying [18:28] <azeem> afflux: right, there's no need to include the debian/ directory in the upstream tarballs [18:29] <azeem> afflux: if you must, I suggest to call it otherwise, and advise your users to rename it to debian [18:29] <afflux> azeem: I guess that is quite useless when packaging for ubuntu ;) [18:29] <azeem> what is "that"? [18:30] <afflux> azeem: the renaming solution [18:30] <azeem> why? [18:30] <azeem> I'm saying if you *must* ship the debian/ directory in your upstream tarball for some reason (you really shouldn't), it's still better to ship it as "debian-upstream" or something [18:30] <azeem> not "debian" [18:31] <ScottK> azeem: I don't think that helps. [18:31] <azeem> why not? [18:31] <ScottK> That just doubles the size of the diff.gz. [18:31] <azeem> the Debian packaging would just ignore debian-upstream [18:31] <afflux> azeem: ah, didn't get the "must". But since that's not the case, i'll just split it. [18:32] <ScottK> azeem: You'd end up having to repack the tarball to remove it. [18:32] <azeem> remove what? [18:32] <ScottK> azeem: The not-a-debian dir. [18:32] <ScottK> You can't patch a file out completely. [18:32] <azeem> yeah, but you could just ignore it as well [18:32] <ScottK> azeem: That would be wrong. [18:32] <azeem> it's more of a PITA if it's actually called "debian" [18:32] <azeem> because then, you really cannot patch out files [18:33] <azeem> and you have to repack [18:36] <pochu> ScottK: why would it be wrong to ignore a 'debian-upstream/' dir in orig.tar.gz ? [18:37] <pochu> we repack to rename debian/ to debian-upstream/ when upstream package contains a debian/ dir, so I can't see why debian-upstream/ is bad for upstream. [18:37] <ScottK> Personally, I think it'd be wrong to ship a directory of stuff that is like debian packaging, but not what's used. [18:37] <ScottK> pochu: Where is renaming debian-upstream documented? [18:37] <azeem> ScottK: I assume the "debian-upstream" is to be used by the users of the upstream package who desperately want and need to build .debs [18:38] <azeem> ScottK: though I agree that this shouldn't be needed [18:38] <azeem> but some upsreams seem to be very firm with this opinion [18:38] <pochu> Not documented, but it's done in wxwidgets. [18:38] <ScottK> pochu: Doesn't make it right. [18:38] <ScottK> azeem: What I do where I'm upstream is keep the Debian packaging in the VCS, but exclude it when I roll the tarball for a release. [18:39] <pochu> I agree it's better for upstream not to have a debian dir in the source tree at all, but if they are going to have one, better not to call it debian/ ... [18:39] <azeem> ScottK: sure, that's the right solution [18:39] <ScottK> Then I point to the VCS if someone really wants it. [18:40] <pochu> That makes sense. [18:40] <pochu> Or have it one dir above in the VCS. === x-spec-t is now known as Spec [18:46] <afflux> another question: Where I'm upstream, I have now two VCS branches: one called debian, containing *only* the debian packaging that is supposed to be distributed with ubuntu, and one called trunk, containing *only* my upstream sources. Now, should I point XS-Vcs-* to the debian or to the trunk branch? And should the debian branch contain the upstream sources too (so it's packaging + sources, not only packaging)? [18:47] <afflux> (checking for example cryptsetup looks like "debian" should contain packaging + sources, with Vcs-Bzr linking to "debian") [18:48] <azeem> for the latter, there's arguments towards both ways [18:48] <azeem> so it depends on your personal preference I guess [18:48] <azeem> (though maybe there is some Ubuntu policy I don't know of) [18:49] <ScottK> There's no specific policy, but mostly the spot where the debian dir can be found is referenced. [18:49] <pochu> afflux: Vcs-* should point to the "official" debian/ dir, not upstream's [18:50] <ScottK> pochu: For afflux since he's doing both, I think it's a distinction without difference. [18:52] <StevenHarperUK> in my debian/app.install I want to replace multiple lines like this > locale/en/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/en/LC_MESSAGES with 1 line like this > locale/*/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/*/LC_MESSAGES is it possible? [18:52] <pochu> ScottK: if it's for Debian I'd say it's ok, but if it's for Ubuntu, as it's team maintained, then having it in his project doesn't look like the best place? [18:53] <afflux> pochu, right. I'll drop the debian branch ;) [18:53] <pochu> (I'm not sure how bzr permissions work in launchpad for projects and teams though) [18:53] <ScottK> pochu: I disagree. The version in the repo is the real canonical source, but the VCS reference is fine. [18:56] <StevenHarperUK> persia: do you know ? ^^ see last post [19:11] <cprov> ScottK: hey, what about this page https://dogfood.launchpad.net/ubuntu/+source/dkim-milter/+publishinghistory [19:11] <ScottK> cprov: looking [19:12] <ScottK> cprov: The only thing that I think that lacks is if the version column has links to the appropriate page for that version. [19:13] <ScottK> cprov: i.e.2.3.2.dfsg-1ubuntu1 links to https://dogfood.launchpad.net/ubuntu/hardy/+source/dkim-milter/2.3.2.dfsg-1ubuntu1 as it is below. === LaserRock is now known as LaserJock [19:13] <ScottK> persia and LaserJock: What do you think ^^^ [19:14] <cprov> ScottK: it's in the corresponding 'detailed' section, but I can easily add the link in the table too. [19:14] <ScottK> cprov: I noticed that, but that's usually where I would go off that page and so it's very good to have it one click away and not two. [19:15] <cprov> ScottK: the point is, maybe you prefer the hidden box below the row as we do in PPA page. [19:15] <ScottK> cprov: Do you have an example? [19:16] <cprov> ScottK: not yet, but check the navigation in any PPA page. The publishing details would be presented as we present the archive files for each published source in the PPA page. [19:16] <ScottK> cprov: OK. Give me a minute to look around for one. [19:17] <cprov> ScottK: by clicking in a arrow you could display/hide the 'publishing details' for each record/row === davro is now known as davromaniak [19:18] <LaserJock> ScottK: gotta read backlog [19:18] <ScottK> cprov: No. I prefer the link off of the table directly. Open the arrow and then click on where I want to go is still two clicks. [19:20] <cprov> ScottK: wait, consider the version-link done. What I asked is if you prefer the anchor to the 'detailed' section in the page (current solution) or the hidden-box mechanism used in PPA page. [19:21] <cprov> ScottK: the hidden boxex seems to be more appropriate, otherwise I have to add a link 'back to summary' on the end of each detailed section. [19:21] <LaserJock> cprov: hmm, shouldn't those Target links maybe go to /ubuntu/<release>/+source/<package> instead of just /ubuntu/<release> ? [19:22] <cprov> LaserJock: could be, like 'foobar in gutsy' and not only "gutsy", fine [19:22] <LaserJock> cprov: one of the hardest things for me to find are translations [19:23] <LaserJock> and I need to get to the /ubuntu/<release>/+source/<package> page [19:23] <LaserJock> it's not really very interesting to just link to the release itself, IMO, from a source package page [19:26] <cprov> LaserJock: right, I see you point. [19:27] <LaserJock> other than that I quite like that page [19:27] <ScottK> cprov: I see. [19:27] <ScottK> cprov: I can see advantages to the way you are proposing. [19:28] <ScottK> cprov: I'd ask the archive admin people that asked for the additional information as I expect it'd be more important to them. [19:28] <LaserJock> cprov: you sure we can't have that first table on the main source package page? :-) [19:29] <ScottK> LaserJock: I argued that and lost with sabdfl, so I suspect not. [19:29] <LaserJock> hehe [19:29] <LaserJock> cprov: oh, and with the release links, can we do the same for the main source page? [19:30] <cprov> LaserJock: give me a example [19:30] <LaserJock> it's kinda annoying to have to dig down into the version history to find a link to the /ubuntu/<release>/+source/<package> page [19:31] <LaserJock> in the "Published versions and upstream associations" table you list the release, but there's no links [19:31] <LaserJock> basically, no matter what else is on the main source page, I want to see links to specific versions and links to the release source page [19:32] <cprov> LaserJock: check the +publishinghistory page in dogfood again, links added [19:32] <LaserJock> cprov: great! [19:33] <cprov> LaserJock: now the question remains, anchors back and forth for detailed sections or hidden-boxes below the rows (as PPA page). [19:33] <Ubulette> hi [19:33] <Ubulette> persia, are you there ? [19:34] <LaserJock> cprov: k, let me pull up a PPA page [19:35] <ScottK> LaserJock: https://dogfood.launchpad.net/~cprov/+archive [19:36] <LaserJock> cprov: this is for the +publishinghistory? [19:37] <cprov> LaserJock: yes, I have the impression that if we use hidden-boxes we could easily compare multiple records in the table instead of clicking-around thing [19:38] <LaserJock> cprov: so is the anchors what you have now? [19:38] <cprov> LaserJock: yes [19:39] <LaserJock> cprov: and are you going to put in any more information? [19:40] <LaserJock> from what I see know I would think that the hidden-boxes would be better [19:40] <cprov> LaserJock: not really, I think we are done with the publishing-system redesign, removal information is already complete now [19:40] <LaserJock> much of the information in the complete history is already in the summary [19:41] <LaserJock> so just being able to drop down the box that you need for the additional details seems easier to me [19:41] <cprov> LaserJock: yup, we can cut some lines from the detailed section. [19:41] <cprov> LaserJock: exactly. [19:41] <cprov> ScottK: what do you think ? [19:41] <LaserJock> and I think it would, as you say, be easier to compare different version details, especially if they are far apart [19:42] <ScottK> cprov: I think the drop down is better, but as I said earlier I'd suggest asking the archive admins that asked for the removal information as that's the major piece of data that isn't displayed in the table to some degree. [19:43] <LaserJock> yeah, I agree [19:43] <LaserJock> I think the archive admins would be the main users of that data [19:43] <nxvl_work> i'm trying to dpatch a package, but i'm always getting: [19:43] <LaserJock> most devs will just look at the summary I think [19:43] <nxvl_work> dpatch deapply-all [19:43] <nxvl_work> 01_Makefile not applied to ./ . [19:43] <nxvl_work> on build [19:43] <cprov> ScottK: right, i will cook another prototype and come back in a bit. Thank you guys ! [19:44] <LaserJock> nxvl_work: did you add it to debian/patches/01list ? [19:44] <nxvl_work> LaserJock: yep [19:44] <LaserJock> nxvl_work: pastebin your rules? [19:45] <nxvl_work> http://pastebin.com/m7b7c79a [19:46] <nxvl_work> that is what i don't understand well [19:46] <nxvl_work> and i haven't find any clear documentation about [19:51] <LaserJock> nxvl_work: I don't see any dep on a patch rule [19:51] <nxvl_work> !? [19:51] <LaserJock> nxvl_work: and you're not actually building anything [19:52] <nxvl_work> mmm, i really don't understand well the debian/rules [19:52] <LaserJock> you're doing a make install [19:52] <LaserJock> but no make [19:52] <nxvl_work> i think that's why my mentor make me start with FTBFS [19:52] <LaserJock> :-) [19:52] <nxvl_work> oh ok [19:53] <nxvl_work> and a make, is done with dh_testdirs? [19:53] <LaserJock> ok, gimme a sec and I'll give you a bit cleaner debian/rules [19:53] <LaserJock> no [19:53] <LaserJock> it's done with ... make or $(MAKE) [19:54] <LaserJock> nxvl_work: this is a new package right, you're doing it from the beginning? [19:54] <nxvl_work> nop [19:54] <nxvl_work> i'm fixing a FTBFS [19:54] <LaserJock> ah [19:54] <LaserJock> ok [19:54] <geser> persia: I've a very first version of the list with packages in depwait ready: http://members.ping.de/~mb/depwait/out.html [19:54] <nxvl_work> but i think it have been uploaded not the right way [19:54] <LaserJock> so can you paste the original debian/rules? [19:54] <geser> persia: it's not running on the complete data set yet and the colouring needs improvement [19:54] <nxvl_work> is the very first version on ubuntu mirrors [19:55] <nxvl_work> let me look for them [19:55] <nxvl_work> LaserJock: https://edge.launchpad.net/ubuntu/hardy/+source/cereal/0.15-1 [19:56] <nxvl_work> LaserJock: this is the package [19:56] <nxvl_work> i'm downloading it again [19:56] <LaserJock> nxvl_work: you do need to keep a clean version of the current package around :-) [19:56] <LaserJock> when you go to do a debdiff to get it sponsored you'll want it [19:58] <LaserJock> PriceChild: ping [19:58] <nxvl_work> http://pastebin.com/m4299a76 [19:58] <nxvl_work> i will keep that in mind [19:58] <nxvl_work> :D [19:59] <LaserJock> nxvl_work: ok, so that's quite clean [19:59] <LaserJock> nxvl_work: so do you know why it is FTBFS [19:59] <LaserJock> ? [20:00] <nxvl_work> LaserJock: it shows me a message (from the makefile) with a bashism [20:00] <LaserJock> ah, ok [20:00] <proppy> hi [20:02] <LaserJock> nxvl_work: well, to be honest wth you, I don't think I would have used dpatch for this [20:02] <nxvl_work> why?= [20:02] <nxvl_work> isn't it the best practice? [20:02] <LaserJock> well [20:03] <LaserJock> you're only making, I'm guessing, a small change to the makefile [20:03] <LaserJock> and there is no existing patch system [20:03] <nxvl_work> yep [20:03] <nxvl_work> you are right [20:03] <LaserJock> in this case it's maybe just easier to not create a new patch system for this small thing [20:04] <nxvl_work> mmm maybe, but if make it so norsetto will be mad [20:04] <nxvl_work> :D [20:05] <LaserJock> nxvl_work: norsetto can talk to me about it ;-) [20:05] <nxvl_work> ok, then i will [20:05] <LaserJock> in general dpatch is a good way to go [20:05] <norsetto> mmm? [20:05] <nxvl_work> BUT [20:05] <LaserJock> especially if upstream is already using it [20:05] <nxvl_work> i prefer to use dpatch, so i can learn about it also [20:06] <LaserJock> the BUT here is that upstream is not using a patch system so you're creating a much larger difference between Ubuntu and Debian than you need to [20:06] <nxvl_work> heh [20:06] <LaserJock> ideally the change you are making now should go away [20:06] <norsetto> laserjock, nxvl_work: what are you two concocting? World revolution again? [20:06] <LaserJock> because the bashism should be reported to Debian and fixed [20:07] <nxvl_work> norsetto: nop, just patching a FTBFS [20:07] <LaserJock> and once that's done we could be able to drop the Ubuntu changes and sync again [20:07] <nxvl_work> mm [20:07] <nxvl_work> you are right [20:07] <nxvl_work> i will contact the DD [20:07] <LaserJock> so, the idea is you can fix it for now in Ubuntu, and report it to Debian [20:07] <nxvl_work> (this is my 5th FTBFS resolved without a line of code) [20:07] <cprov> LaserJock: ScottK: there we go, https://dogfood.launchpad.net/ubuntu/+source/dkim-milter/+publishinghistory & https://dogfood.launchpad.net/ubuntu/hardy/i386/dkim-filter [20:08] <norsetto> laserjock: what should we talk about? [20:09] <LaserJock> norsetto: nxvl_work was fixing a bashim causing a FTBFS. He was going to add in dpatch to the packaging to do it [20:09] <LaserJock> norsetto: I think that's a lot of delta for a minor change in a single file [20:10] <norsetto> laserjock: yes, on the other side sloppy habits are sloppy habits (even if it is the last cigarette). [20:10] <LaserJock> cprov: I like that [20:10] <nxvl_work> norsetto: and i was saying that if i don't use dpatch you will be mad [20:10] <ScottK> cprov: I like that, but I'll say again I'd run it by pitti at the very least. [20:10] <ScottK> cprov: One minor point I'm not sure about ... [20:10] <LaserJock> norsetto: hmm? [20:10] <norsetto> nxvl_work: oh right, hyper mad :-) [20:10] <LaserJock> norsetto: why is that a sloppy habit? [20:11] <ScottK> cprov: The table has newest at the top, so it runs newest to oldest (this is good), but the status when you open the details is oldest to newest. It's a bit jarring. === apachelogger_ is now known as apachelogger [20:11] <ScottK> cprov: I'd put that most recent at the top too. [20:11] <norsetto> laserjock: do you know the meaning of maintenability and traceability? [20:11] <nxvl_work> norsetto: so will be debating about using dpatch or not, and he has a good point, which is that it is a bug that should be fix in debian [20:12] <LaserJock> norsetto: yes, and do you know the meaning of bloat? ;-) [20:12] <LaserJock> norsetto: the package is not using a patch system, adding one for just a one-liner in a single file is just overkill [20:12] <norsetto> nxvl_work: twell, all packaging bugs should be fixed in debian [20:12] <cprov> ScottK: good point, I can fix that, thanks [20:12] <cprov> LaserJock: thanks [20:12] <norsetto> LaserJock: thats not the point, the point is doing a sloppy thing because its easier [20:12] <LaserJock> no it's not [20:12] <joejaxx> LaserJock: hello :D [20:13] <LaserJock> it's the *correct* thing to do IMO [20:13] <LaserJock> joejaxx: hi [20:13] <LaserJock> norsetto: not using a patch system is not sloppy [20:13] * nxvl_work has the idea he has read this conversation before [20:13] <norsetto> LaserJock: oh right, so, Iḿ wrong and you are right type of argument [20:13] <LaserJock> norsetto: exactly ;-) [20:13] <joejaxx> lol [20:14] <norsetto> LaserJock: well, let me tell you that multi-million dollar projects are all wrong [20:14] <joejaxx> norsetto: they can be ;) [20:14] <LaserJock> what I'm saying is that I don't think this should add a patch system, not because I'm lazy or sloppy, but because it is uneccesary [20:14] <norsetto> LaserJock: and when they did as you suggest, take the easy way because is such a small change, than catastrophe arrived [20:15] * nxvl_work uses dpatch and stop reading the discussion [20:15] <LaserJock> there's several reasons why I'm against adding a patch system in this instance: [20:15] <nxvl_work> norsetto: is the 2nd time i make you fall into this conversation :D [20:15] <LaserJock> 1) it's added delta for us to carry [20:15] <LaserJock> 2) this change *should* go away, and is therefore temporary [20:16] <LaserJock> 3) the Debian maintainer is more likely to take the diff as it's not telling him how to run his patches [20:16] <norsetto> nxvl_work: well, you can't change the world but some battles are worth fighting :-) [20:16] <LaserJock> so I think doing dpatch for this would be overkill, that's my opinion [20:16] <norsetto> laserjock: so, is there a patching system already? [20:17] <LaserJock> no [20:17] <LaserJock> there is nothing patched yet in that package [20:17] <ScottK> At the very least just send the patch for the bug to Debian BTS. Don't tell the maintainer how to suck eggs too. [20:17] <norsetto> LaserJock: well, so why should the DD complain if we do it in Ubuntu? [20:18] <norsetto> LaserJock: send him the fix and fix it in Ubuntu the way we want [20:18] <LaserJock> norsetto: because if I was the DD I wouldn't want to add dpatch as I would think it would be overkill ;-) [20:18] <LaserJock> norsetto: right, we could do that [20:18] <LaserJock> but that's added work for us [20:18] <norsetto> LaserJock: who is asking teh DD to add dpatch? [20:18] <LaserJock> why make it *more* difficult than it needs to be [20:18] <norsetto> LaserJock: again, taking the easy way out [20:18] <LaserJock> norsetto: because our diff will show up in PTS, and he'll go "what the heck are they doing to my package?" :-) [20:19] <LaserJock> norsetto: *no* [20:19] <LaserJock> it's not the easy way out [20:19] <norsetto> LaserJock: oh my god, they touched my package! [20:19] <norsetto> ahahah [20:19] <nxvl_work> norsetto: well, i think we always need to report the DD about the problem, to check if they have it also [20:19] <LaserJock> it's *not* doing uncessary work [20:19] <ScottK> LaserJock: In Debian you'd have to (to not be wrong) use a patching system. [20:19] <LaserJock> no [20:19] <LaserJock> a patch system is not required [20:19] <ScottK> nxvl_work: I'd say don't report it unless you know they have the problem too. [20:20] * ScottK tries to decide if he cares enough to look it up. [20:20] <broonie> norsetto: Speaking as someone who periodically reviews the Ubuntu changes in my packages I do find it helpful if the changes carried are minimised. [20:20] <nxvl_work> ScottK: isn't a good think to email de DM saying "i have had this problem, did you?" [20:20] <cprov> ScottK: the ordering issue you pointed is fixed. Let me run this over archive-admins. [20:20] <norsetto> broonie: I sure appreciate that broonie, but some DD really needs to be prodded and even then [20:21] <broonie> nxvl_work: I'd say so (at least so they know what the change is). [20:21] <nxvl_work> ScottK: you don't care enough, believe me [20:21] <ScottK> nxvl_work: I would say no. I'd research if first and see if it affected Debian or was something Ubuntu unique. As a maintainer in Debian, downstream's unique problems are theirs, not mine. [20:21] <nxvl_work> broonie: that's what i mean [20:21] <TheMuso> c [20:21] <TheMuso> wrong tab [20:21] <ScottK> nxvl_work: I was pretty sure that was the case. [20:21] <ScottK> TheMuso: Your line there was ugh. [20:22] <LaserJock> norsetto: but what is wrong with not using a patch system in this case? Don't we want to minimize delta and work for ourselves? [20:22] <broonie> norsetto: Oh, lots of people would never look at the Ubuntu packages - I do so for the same reason I also peer at the Fedora, SuSE, Gentoo and so on from time to time. [20:22] <nxvl_work> ScottK: but there are some OBVIOUSLY thinks like the one we are talking about [20:22] <ScottK> TheMuso: Please stay on the scropt. [20:23] <bmk789> what java package is the new azureus fixed with? because im still getting the same error as before [20:23] <norsetto> LaserJock: not using a patch system is always wrong, not just in this case [20:23] <slangasek> ScottK: even if the changes aren't relevant to Debian, if they can be merged into the Debian package without negatively impacting the Debian experience I'm interested in that to help free up people's time to work on improving code instead of constantly re-merging [20:23] <LaserJock> norsetto: I would have to say that that is just categorically wrong === nixternal_ is now known as nixternal [20:24] <norsetto> LaserJock: yes, I'm wrong and you are right again [20:24] <LaserJock> norsetto: there are plenty of times when not using a patch system is appropriate [20:24] <ScottK> slangasek: I think that makes you substantially more open minded then most Debian maintainers. [20:24] <norsetto> LaserJock: spare the effort of spending 5 minutes [20:24] * nxvl_work *HUGS* norsetto to calm him :D [20:24] * ScottK is intensely sick of reading about Baltix problems that don't affect Ubuntu at all. [20:25] * norsetto hugs nxvl and laserjock too [20:25] <LaserJock> norsetto: nxvl_work has been banging his head against dpatch for a while when he could have had this FTBFS fixed an uploaded [20:25] <huats> asac: Hey... when you told me to add a comment about my network-manager experience... You mentioned a bug number. Do you recall which one it was ? [20:25] <norsetto> nxvl_work: I'm not angry at all, we are having a very interesting discussion I think [20:25] <norsetto> LaserJock: yes, thats good! [20:25] <nxvl_work> LaserJock: but a point for norsetto is that this is a good opportunity for me to learn dpatch also [20:26] <LaserJock> yeah, but it's not [20:26] <asac> huats: let me look ... did it help? [20:26] <slangasek> ScottK: well, doing so has also moved up my priority list now that I'm in a position to be affected by it on both sides ;) [20:26] <huats> asac: YES [20:26] <LaserJock> there are many good oppritunities to learn daptch [20:26] <nxvl_work> huats: once again, you came when i was looking for you :D [20:26] <huats> asac: it works great... [20:26] <norsetto> nxvl_work: I would even as far as tell you, next time try out quilt [20:26] <LaserJock> this one just seems very uncessisary [20:26] <huats> nxvl_work: I am here [20:26] <nxvl_work> huats: PM [20:26] <nxvl_work> norsetto: is quilt easier? [20:26] <asac> huats: its bug 145683 [20:26] <ubotu> Launchpad bug 145683 in network-manager "Network manager crash with WPA" [Undecided,Fix committed] https://launchpad.net/bugs/145683 [20:27] <norsetto> nxvl_work: not to learn, but its much more powerful to use than dpatch [20:27] <joejaxx> oh fun with quilt [20:27] <joejaxx> i had to learn that for openmosix [20:27] <huats> asac: ok, so I was looking at the right one .... [20:27] <huats> asac: great works really... [20:27] * nxvl_work reads quilt [20:28] <asac> huats: yes ... its 83623 as well ... but the one above tracks them all [20:29] <zul> a patch system is not always necessay and not always used [20:29] <norsetto> asac: have you had the chance to look at my email? [20:32] <asac> norsetto: about? [20:35] <persia> norsetto: In all your effort to add patch systems, please make absolutely 100% sure that there is never a package admitted to the archive that mixes raw patches in the diff.gz with a patch system. [20:35] <norsetto> persia: yes sir. will do sir. [20:36] <norsetto> persia: btw, any news on lash? I tested and seems good but I'd really appreciate your opinion on that [20:36] <persia> norsetto: Thank you. While I don't agree entirely that everything needs a patch system, I do really appreciate your efforts to teach people to use them. [20:37] <persia> norsetto: I ran into an annoying issue with jack, and haven't tracked that down yet. This annoys me, as there are currently lash patches available for 3 different packages that I want to integrate with your package :) [20:38] <norsetto> persia: ok, I'm waiting for your ok to upload in any case [20:39] <nxvl_work> quilt is fun [20:39] <nxvl_work> :D [20:40] <nxvl_work> but one cuestion, do i need to add anything to debian/rules? [20:40] <persia> norsetto: Thanks for your patience :) [20:40] <nxvl_work> i don't find anything about it [20:40] <norsetto> nxvl_work: (I also find it fun but don't tell anyone ....) [20:40] <LaserJock> norsetto: I agree with persia, btw. Patch systems are in the majority of the cases a good thing, and it's important to teach people to use them. Thanks for helping people with that. [20:40] <persia> nxvl_work: Yes. I think there is a quilt.mk floating about, but I don't remember where. [20:40] * nxvl_work smells comunitary HUG??? [20:41] <nxvl_work> persia: thnx [20:41] <nxvl_work> checking [20:41] <norsetto> nxvl_work: include /usr/share/quilt/quilt.make [20:42] * LaserJock hugs #ubuntu-motu [20:42] <nxvl_work> norsetto: and nothing else? [20:42] <norsetto> nxvl_work: yes, the usual targets [20:43] <norsetto> nxvl_work: unpatch for clean and patch-stamp for the appropriate configure/build [20:43] <nxvl_work> norsetto: the "usual targets" are the ones i'm having trouble with, is it documentation about it around? [20:43] <LaserJock> nxvl_work: read man dpatch.make for instace [20:43] <norsetto> nxvl_work: ok, what problem are you having? [20:44] <nxvl_work> norsetto: i don't know well how to manipulate debian/rules [20:44] <norsetto> nxvl_work: ok, you know more or less what a makefile is? [20:44] <nxvl_work> norsetto: and packaging guide is a little superficial [20:44] <LaserJock> nxvl_work: the example in dpatch.make is pretty good [20:44] <nxvl_work> yes, i know, what it makes, and what it works, but i don't feel i can write one [20:45] <norsetto> nxvl_work: well, very very superficially speaking, a makefile is a series of targets and pre-requisites; pre-requisite must be satisfied to achieve the given target [20:46] <norsetto> nxvl_work: are you with me so far? [20:48] <norsetto> nxvl_work: either I killed you with my pathetic makefile 101 or you are busy reading the dpatch.make example :-) [20:49] <nxvl_work> i'm back [20:49] <nxvl_work> norsetto: yes, that i already know :D [20:50] <persia> geser: That looks great. Thanks. [20:50] <norsetto> nxvl_work: ok, so lets skip the 101, why are you having a problem finding the right target for your stamp requisite? [20:51] <nxvl_work> yup [20:51] <norsetto> nxvl_work: what targets you have in your rules? and what are you patching? [20:52] <nxvl_work> cereal [20:52] <persia> geser: One wishlist request would be to have the version number link to the versioned LP page (e.g. https://launchpad.net/ubuntu/hardy/+source/usermode/1.81-3.1), while keeping the package name linking to the main LP page. [20:53] <norsetto> nxvl_work: I mean, what file? Its an autoconf file, a configure, a make, a source? [20:53] <nxvl_work> http://pastebin.com/m4299a76 [20:53] <nxvl_work> this is the clean rules [20:54] <geser> persia: I'm currently running it for: failed to build, chrootwait, depwait, failed to upload [20:54] <norsetto> nxvl_work: ok, looks liek a rules for something simple, like docs or scripts [20:55] <nxvl_work> yep [20:55] <persia> geser: Does it require a separate loop for each, or does it collect all that in a single run? Also, how long does it take? (I'm assuming it's LP-bound) [20:55] <norsetto> nxvl_work: and what is it that you are patching? [20:55] <nxvl_work> The Makefile [20:56] <geser> persia: the script and the template are at http://members.ping.de/~mb/depwait/ [20:56] <norsetto> nxvl_work: ok, check in which target is the makefile used [20:56] <geser> persia: 13 min for a run [20:56] <nxvl_work> norsetto: install i think [20:57] <norsetto> nxvl_work: right, so you have to patch before install [20:57] <norsetto> nxvl_work: in other words, you have to make patching a pre-requisite of the install target [20:57] <nxvl_work> and that's what i don't know, what runs first [20:57] <persia> geser: I'm tempted to wait for dktrkranz to discuss coordination, but based on quick oversight, I think I'd prefer that to be the "official" build status report, as it's a bit more informative. [20:58] <nxvl_work> it runs on the order it's readed or it has a order [20:58] <geser> persia: I've just uploaded the output from the last run [20:58] <norsetto> nxvl_work: thats what you decide, if patching is a pre-requisite for the install target, than the patchin target is run before the install one [20:58] <persia> WIth lots more colors! [20:59] <norsetto> nxvl_work: the order they are written is totally not influencing, what is important is target: requisite [20:59] <geser> persia: the colouring needs some improvement [20:59] <persia> geser: Actually, would you mind differentiating the FTBFS and chroot failure colours a little more? I can't see the difference easily when they aren't close to each other. [21:00] <nxvl_work> http://pastebin.com/d1e32f47c [21:00] <nxvl_work> norsetto: so it can look like this? [21:00] <persia> Is anyone here good with color palettes? [21:00] <geser> persia: sure, if you can tell me some good colors [21:01] <norsetto> nxvl_work: the unpatch in clean is ok, the include is ok, but why you add make in build? [21:01] <persia> geser: That's exactly what I'm hoping to elicit. I'm lousy with colors, but getting four non-green colors that look OK on a blue/white background and allow black overprinting would be ideal. [21:01] <cyberix> I'm looking for first sponsor for my package pq. I have posted the package to REVU, fixed all problems that have been raised, asked TB to confirm Multiverse inclusion and received approvals for inclusion from Shuttleworth, Zimmerman and Troup. I've also contacted the upstream developer and he said he will subscribe for pq bugs in Launchpad once it gets included in Ubuntu. http://revu.tauware.de/details.py?package=pq [21:01] <nxvl_work> norsetto: for the file to be patched? [21:01] <persia> cyberix: That's a very well-formed and informative advertisement. Thanks. [21:02] <norsetto> nxvl_work: what that would do, it would just call the makefile with no arguments [21:02] <norsetto> nxvl_work: you want to patch, not call make [21:02] <nxvl_work> and that wont work [21:02] <nxvl_work> mm [21:03] <cyberix> (...and I'm starting to sound like "The Twelve Days of Christmas") [21:05] <norsetto> nxvl_work: what is the target to patch? You can also look in /usr/share/quilt/quilt.make if you don't remember [21:06] <persia> LaserJock: re: "patch" tag: I was thinking of the tag as a sort of "confirmed & ready for review", whereas the other was a flag to encourage looking, but I'm not convinced enough of that to argue for it. [21:06] <norsetto> nxvl_work: do you see the patch: target in there? [21:07] <nxvl_work> it works [21:07] <nxvl_work> :D [21:07] <nxvl_work> norsetto: thnx [21:07] <nxvl_work> :D [21:07] <LaserJock> persia: ok, I'm currently chatting with kiko about it [21:07] <persia> LaserJock: Excellent. Thanks. [21:07] <norsetto> nxvl_work: :-D [21:07] * Fujitsu celebrates https://dogfood.launchpad.net/ubuntu/+source/dkim-milter/+publishinghistory [21:08] <nxvl_work> norsetto: one more thing, i read that i need to link patches to debian/patches, but on the make file it points to debian/patches, can i remove the patches link? [21:08] <persia> LaserJock: Also, if there's a way to mark a non-attachment comment a patch, I'd find that handy. [21:09] <norsetto> nxvl_work: I must admit I never used the link to debian/patches [21:09] <nxvl_work> removing and testing [21:09] <nxvl_work> it works [21:09] <nxvl_work> the wiki is wrong [21:09] * nxvl_work fixes [21:16] <persia> DktrKranz: geser was hacking the FTBFS script, and developed http://members.ping.de/~mb/depwait/out.html. What do you think? [21:17] <DktrKranz> GREAT! [21:17] <geser> persia: I've tried to improve the colour a little bit. Are they better now? [21:17] <Fujitsu> Oooh, colourful. [21:17] <Fujitsu> Soyuz is rather borked in some places. All binaries for some packages failed to upload... [21:17] <nxvl_work> i find really nice that the packaging guide is on the wiki, so we can correct it on any moment [21:17] <nxvl_work> :D [21:18] <persia> geser: I'm a little colour-blind, and can't tell the difference between the first two. Also, I'm not sure "green" is ever appropriate. [21:18] <LaserJock> persia: can you tell me anything about why the patch flag on has a 50% hit rate? [21:19] <DktrKranz> Yes, maybe base colour should be of higher contrast, but I'm not good in graphics [21:19] <Fujitsu> persia: green means that it's SEP, I guess. [21:20] <geser> persia: http://de.selfhtml.org/diverses/anzeige/farbnamen_netscape.htm and http://de.selfhtml.org/diverses/anzeige/farbpalette_216.htm have some colours, pick four [21:20] <persia> LaserJock: Lots of random things get labeled "patch" by commenters. This can be unlabeled in the interface (no idea of the ACL). Just fixing this covers the attachment case, but doesn't cover the patch-in-comment case (e.g. 2-line change) [21:20] <Fujitsu> geser: Can you please mark builds that are pending (ie. needs-build) if there are other FTBFSes? [21:21] <Fujitsu> As at the moment, hppa looks to be very successful. [21:22] <geser> Fujitsu: will try [21:22] <LaserJock> persia: are you counting debdiffs as a patch? [21:23] <LaserJock> persia: and is it possible to classify what most often get's misslabeled a patch [21:23] <geser> Fujitsu: have you a suggestion for the colour for it? [21:23] <persia> LaserJock: Sometimes: I only think debdiffs are interesting if the debdiff was rejected by the sponsors and not resubmitted for a couple months, but the problem was with the wrapping, and not with the patch. [21:23] <Ubulette> persia, hi. thanks for your answer. I'll work on that asap [21:23] <LaserJock> for sure you could probably make it so .pngs are not allowed as patches for instance [21:23] <LaserJock> ;-) [21:24] <Fujitsu> geser: Perhaps a different gray, as we don't really have a status. I'm not sure. [21:24] <persia> LaserJock: Generally self-uploaded crash reports, once a screenshot, and several times various logs. I'm not sure everyone understands "patch" [21:24] <LaserJock> yep [21:25] <Ubulette> persia, do you prefer that form ? http://paste.ubuntu.com/2265/ [21:25] <persia> geser: I can't find 4 easily distinguishable colors in the 216 palette, but maybe #FFFF66, #FF7F50, #FFD700, #FFDAB9 (and yes, it might be ugly) [21:26] <Ubulette> oops, obviously with get and new swapped [21:27] <geser> persia: updated, there is no much difference between #1 and #3 [21:27] <persia> Ubulette: That's much nicer looking in my opinion, but I think the sense of get-orig-source and new-orig-source is swapped (i.e. it looks to me like new-orig-source is grabbing the current source, and get-orig-source is grabbing new source) [21:28] <Ubulette> persia, yep, see 2 lines above ;) [21:28] <persia> Ubulette: Right :) [21:29] <persia> geser: Hmm. Looks different here, but maybe s/#FFFF66/#FFFF00/ to make it even more distinct? === _czessi is now known as Czessi [21:31] <persia> Does anyone else have any color suggestions, or do they find those colours bad? [21:32] * Fujitsu thinks the failed uploads should be blinking and say `complain to cprov', but that's probably not a good idea. [21:32] <DktrKranz> :) [21:33] <DktrKranz> what about having "Package failed to build" red? [21:34] <cprov> Fujitsu: I guess that's a superior message to me "stop now and go look for some food" :) [21:34] <DktrKranz> it should be distinct from MANUALDEPWAIT [21:34] <norsetto> cprov: stop now and go look for some food [21:34] <Fujitsu> cprov: Heh. [21:34] <StevenHarperUK> hi, in my debain/app.install file I want to replace lots of entries that look like this - locale/en/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/en/LC_MESSAGES - with one that looks like this - locale/*/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/*/LC_MESSAGES - is that possible - or is there something like it - I dont want to have to add a new line for each language. [21:36] <persia> Isn't there some translations helper tool that does that properly? [21:36] <norsetto> persia: he is not generating on the fly, the *.mo are in the source package together with *.po and the rest [21:37] <StevenHarperUK> I can do on the fly generation, but it seems like something else to go wrong [21:37] <persia> StevenHarperUK: Worst case, you could collect the names of usr/share/easycrypt/locale/* into a list in make, and then create a rule on the entries. [21:37] <slangasek> StevenHarperUK: can't you list entire subdirectory trees in app.install, or do you really have different filenames that go to different packages? [21:37] <Fujitsu> Can't dh_install do wildcards? [21:37] <slangasek> i.e., do locale/ usr/share/easycrypt/locale [21:37] <StevenHarperUK> It can do wildcards but not in the middle [21:37] <persia> StevenHarperUK: You really want to do on-the-fly generation, or you'll kick yourself when you forget the generation step once. [21:37] <slangasek> Fujitsu: yes, but you can't do backreferences [21:37] <StevenHarperUK> and it doesnt seem to do recurive directories [21:37] <Fujitsu> slangasek: Bah. [21:38] <persia> slangasek: Won't that toss in the .po files & the like? === cprov is now known as cprov-out [21:38] <slangasek> persia: if present, yes, that's why I asked :) [21:39] <StevenHarperUK> slagasek: a wildcard like locale/* just does that level [21:40] <persia> StevenHarperUK: I'd create a locale/$(LANG)/LC_MESSAGES/easycrypt.mo: rule in MAKE, with $(LANG) being a list (although I may not remember the syntax perfectly) [21:40] <StevenHarperUK> persia: I dont have a Make [21:40] <slangasek> persia: the problem isn't creating them, though, it's installing them to the package? [21:41] <persia> StevenHarperUK: debian/rules is a makefile [21:41] <Fujitsu> LaserJock: It does look like LP will be an OpenID provider from 1.1.12, not so much a consumer. [21:41] <StevenHarperUK> persia: ah I half knew that [21:41] <persia> slangasek: right. As I said, my syntax is rough: likely needs extra bits to put it in the right place. [21:41] <StevenHarperUK> persia: so I need a sample make file with that in [21:42] <LaserJock> Fujitsu: interesting [21:42] <LaserJock> Fujitsu: that makes it much less interesting sadly [21:42] <Fujitsu> Ooh, ssov2-open-op looks good. We can finally authenticate against LP externally! [21:43] <Fujitsu> Although that's 4 releases away. [21:43] <persia> StevenHarperUK: http://www.gnu.org/software/make/manual/make.html#Static-Usage describes the trick for one rule with lots of different targets [21:45] <LaserJock> Fujitsu: which means at least 8, right? they gotta push a few ;-) [21:47] <Fujitsu> LaserJock: Right, I've got some stuff that has been pushed back from 1.1.6 or so, and was just deferred again to 1.1.[12], I forget which. [21:53] * jdong installs new fglrx foolishly hoping it might improve performance/quirkiness [21:54] <Ademan> hey is there anything like xxgamma http://xxgamma.berlios.de/ in the repositories? or something covering that functionality? [21:55] <norsetto> nxvl_work: now you can simply send the Makefile.diff patch to the DD. Please link the bug from the BTS to LP. [21:56] <nxvl_work> why is BTS so unfriendly? [21:57] <norsetto> nxvl_work: why? [21:59] <nxvl_work> norsetto: i think LP has (i don't know the work in english) [21:59] <ScottK> nxvl_work: I have the same question about Launchpad. [21:59] <norsetto> nxvl_work: in spanish? [21:59] <nxvl_work> ScottK: LP is friendlier than LP [21:59] <nxvl_work> norsetto: mal acostrumbrado [21:59] <ScottK> No. I like BTS better as a bug tracker in many ways than LP. [22:00] <norsetto> nxvl_work: well, thats the bts I guess :-) [22:00] <nxvl_work> ScottK: it's a matter of work most with one [22:01] <ScottK> For me it's more a matter of BTS works the same way it did 6 months ago so I'm not constantly re-figuring out how to use it. [22:01] <nxvl_work> (at this time of the day my brain doesn't want to work i have forgot all my english, damn Kelly Boundy) [22:03] <nxvl_work> ScottK: i like the way it hangs with e-mail, but to search a bug using the web interface is what i dislike [22:04] <ScottK> Along those lines (LP is GUI and BTS is command line here): http://penguinpetes.com/b2evo/index.php?title=10_reasons_why_the_command_line_is_more_&more=1&c=1&tb=1&pb=1 [22:05] <LaserJock> I just had bad experiences with BTS to start with [22:05] * LaserJock is scarred for life === cassidy__ is now known as cassidy [22:06] <LaserJock> I tried using reportbug [22:07] <LaserJock> which is generally a nice app, except I use webmail [22:07] <geser> DktrKranz: how long does your ftbfs.py script usually run? [22:07] <LaserJock> so I ended up setting up some smtp app to send out the bug [22:07] <DktrKranz> geser, about 30 min [22:07] <LaserJock> and then it never responeded so I thought something was wrong and sent it again [22:07] <LaserJock> and ended up filing two bugs [22:07] <LaserJock> :-) [22:07] <nxvl_work> i have been scared by BTS before the time i try to became a DD [22:08] <LaserJock> I don't think bug trackers should make me feel as dumb as I am ;-) [22:08] <geser> DktrKranz: ok, then I didn't do something wrong, as mine takes about 20 minutes [22:08] <nxvl_work> (and then finally scared by the brainwash part of the NM process :P) [22:09] <DktrKranz> geser, Launchpad could be a huge bottleneck :) [22:09] <geser> DktrKranz: probably, or in mine case rmadison [22:09] * slangasek slips a little something into nxvl_work's lemonade [22:09] <LaserJock> hehe [22:10] <geser> DktrKranz: my last version is at http://members.ping.de/~mb/depwait/ if you want to look [22:10] <nxvl_work> but, maybe i dislike BTS because i don't know how to use, maybe working with it makes me more comfortable with it and makes me love it [22:10] <LaserJock> nxvl_work: I agree [22:10] <DktrKranz> geser, looks really good. [22:10] <LaserJock> for me, it was much more difficult to get going with BTS, but once you figure it out it's really nice [22:10] <jdong> does anyone love the SourceForge BTS? :D [22:10] <LaserJock> arggggg [22:11] <LaserJock> SourceForges bug and mailing list handling are from the devil himself [22:11] <ScottK> jdong: Not me. [22:11] * jdong peeks at the new mpeg4ip PPA build he uploaded, hoping that didn't infinite loop either [22:12] <jdong> OH CRAP [22:12] <alvinc> ? [22:12] <DktrKranz> geser, when you asked pitti about mass-rebuilds of FTBFS packages, he told you they won't be scheduled. Is there anything better we can do to file a list and pass it to a buildd-admin? [22:13] <jdong> alvinc: I got the build in infinite loop again [22:13] <jdong> isn't this a slight denial of service vulnerability with PPA's? [22:13] <alvinc> *chuckle* [22:13] <alvinc> h8 loops [22:16] <geser> DktrKranz: afaik no, but one could ask the build-admins if there is a better solution [22:17] <persia> DktrKranz: When you're happy with the code, could you push it to qa.ubuntuwire.com? (assuming geser doesn't mind) [22:18] <DktrKranz> We should really do so. When looking at FTBFS list, almost half of the failures should be solved with a give-back [22:18] <geser> persia: I don't mind but let me add a license text first [22:20] <ScottK> DktrKranz: If it's HPPA stuff you can ask Lamont. He fixed one for me today. === Spec is now known as x-spec-t [22:21] <DktrKranz> ScottK, several ports. Mainly tex-*, gnustep and libglib1 [22:21] <ScottK> OK. [22:22] <DktrKranz> which should be already OK (at least for i386, where I checked) [22:22] <LaserJock> DktrKranz: what tex-* ? [22:23] <DktrKranz> LaserJock, FTBFS due to an early texlive uninstallable package [22:24] <LaserJock> DktrKranz: which package, do you know? [22:25] <DktrKranz> LaserJock, let me check... [22:29] <DktrKranz> LaserJock, something like http://launchpadlibrarian.net/10179662/buildlog_ubuntu-hardy-i386.bibtex2html_1.87-2_FAILEDTOBUILD.txt.gz and http://launchpadlibrarian.net/10250408/buildlog_ubuntu-hardy-i386.xsu_0.2.3-2_FAILEDTOBUILD.txt.gz [22:47] <LaserJock> dang, I hate it when I lose my Firefox profile [22:47] <persia> StevenHarperUK: I know you want the latest version in Ubuntu, but would you mind batching fixes upstream, and pushing a new revision once every couple weeks (unless there's a showstopper bug)? More frequent updates just use sponsor time, with not so much benefit to either users or your LP pages. [22:48] * LaserJock kicks OS X [22:48] <persia> LaserJock: Stop using FireFox :) [22:48] <LaserJock> persia: hehe, like that's gonna happen [22:49] <persia> LaserJock: Why? Are you that unhappy with the alternatives? I've not lost a session once since I decided that Firefox wasn't capable. [22:49] * persia tends to use epiphany & safari, depending on the window manager in use [22:50] <LaserJock> I am unhappy with the alternatives [22:50] <LaserJock> all browsers (and email apps for that matter) suck, Firefox sucks less [22:50] <jpatrick> I just use Konqueror [22:50] <LaserJock> epiphany has some strange things that I don't like [22:51] <LaserJock> safari is sort of ok [22:51] <geser> DktrKranz: the last version of my script (and the last output) is at http://members.ping.de/~mb/depwait/ [22:51] * ScottK uses Konqueror on the laptop and Firefox on the desktop. No idea why. [22:51] <LaserJock> but I do like a few extentions like Greasemonkey that are somewhat hard to live without [22:51] <LaserJock> ScottK: weird. [22:51] <ScottK> Yeah. That's me. [22:51] <DktrKranz> geser, is it ok for you to put it on qa.ubuntuwire.com/ftbfs/ ? [22:52] <StevenHarperUK> perisa; are you asking me to do less releases? [22:52] <jpatrick> geser: could you please approve my mail to -council@? [22:52] <geser> DktrKranz: I've added Fujitsu wish to also list "needs building" but I'm not sure if it works (nothing is listed as "needs building" in the table) [22:52] <geser> DktrKranz: sure [22:53] <DktrKranz> geser, I'll give it a look, then [22:53] <geser> jpatrick: I could but I'd need to look how to do it as dholbach usually does it [22:53] <jpatrick> geser: ah, okay [22:53] <DktrKranz> geser, any requirements? bash scripts or similar? [22:53] <StevenHarperUK> persia: 0.2.1.6 has all the feature I have planned for easycrypt [22:53] <geser> DktrKranz: rmadison (devscipts) and python-genshi [22:53] <StevenHarperUK> persia: 0.2.1.16 i mean [22:54] <StevenHarperUK> persia: New releases will be less requent [22:54] <StevenHarperUK> persia: *frequent - I expect a few new languages in 1-2 weeks time [22:54] <persia> StevenHarperUK: OK. You just seem to be of the "release early, release often" school, which I think is good, but from a distribution management point of view, it's not usually that all "release early, release often" upstream releases get packaged. [22:55] <geser> DktrKranz: and colouring could still be improved (and still be distinguishable for persia) [22:55] <persia> Now that the package is in, I'd recommend targeting your next package upload for around mid-december. [22:55] <StevenHarperUK> persia: As i am the Packager and upstream I tent to notify myself that it need packaging :P [22:56] <persia> StevenHarperUK: Sure, it's just not worth making all the buildds work so hard when users can't tell the difference :) [22:56] <StevenHarperUK> persia: I am learning all this I didn't even know Python 6 weeks ago - I want to practice a bit [22:56] <persia> (as hardy has very few users today) [22:56] <persia> StevenHarperUK: Understood. That's why I didn't say all this for the .15 release. [22:56] <StevenHarperUK> persia: I am a developer for a job - I have automated all the builds - its not too much effort , but I do understand [22:57] <StevenHarperUK> persia: Maybe I should try to package TrueCrypt next [22:57] <persia> StevenHarperUK: Excellent, and thanks again for packaging your software for Ubuntu. [22:58] <persia> Sure. More packages aren't bad, especially if there's someone motivated to keep them relatively up-to-date and clean. [22:59] <geser> DktrKranz: I found an error in my script: in line 107 there is () missing after entry.empty (I've updated the script at my webspace) [22:59] <DktrKranz> geser, I'm pushing it right now [23:00] <Ubulette> persia, even i use dh_install like you propose, i still have to keep a lot of install as i rename a lot of files [23:01] <persia> Ubulette: Do all the files need to be renamed? Is upstream truly braindead when it comes to nomenclature? I'm willing to believe this, but just want to check (as we like to have the upstream docs match Ubuntu installations, if possible) [23:02] <geser> DktrKranz: thanks, I'm going to bed now, let me know if you find any bugs or have any issues with the script [23:03] <DktrKranz> Sure. Thanks for this, mine was dreadful :D [23:03] <Ubulette> persia, no, it's just that i'm picking up some icons from upstream to use for our desktop and mime files [23:03] <persia> Ubulette: Ah. You'll need some rules then. Hmm. I'm a big fan of clean debian/rules, and don't know the best way. You might ask someone else for their opinion as well. [23:04] <RainCT> hi [23:05] <RainCT> anyone here uses launchpadbugs (Python module)? [23:05] <persia> RainCT: You might also try in #ubuntu-bugs: I think it's more popular for them (and the right people appear to be off holiday) [23:06] <persia> (of course, timezones may still mean little to no response :) ) [23:06] <RainCT> persia: right, thanks [23:06] <RainCT> :) [23:07] <LaserJock> Ubulette: you're trying to install icons? [23:09] <Ubulette> LaserJock, well, no. it worked well before. now, i'm trying to achieve the very last change that persia proposed and i'm just destroying the thing [23:15] <StevenHarperUK> Hi - I want to package up Truecrypt - I haven't done someone else's source before, can anyone help me gest started? [23:17] <RainCT> good night [23:18] <ScottK> StevenHarperUK: It's pretty much like what you have done already, just less talking to yourself. [23:19] <StevenHarperUK> Scottk: Truecrypt have a build.sh and an install.sh, they also have a DEB so I can see where things should end up [23:19] <ScottK> In most cases you won't even need to talk to upstream either, usually just if there's a problem with package you want them to fix. [23:20] <jpatrick> my upstream's usually turn out to be quite nice [23:21] <StevenHarperUK> Scottk: I know this is a basic question, but are the stages: get debain/rules to build from source -> get rules to install compiled [23:21] <persia> StevenHarperUK: just as an example of a normal release often upstream request, see bug #165285. (Of course, interdiff is much preferred :) Thank you.) [23:21] <ubotu> Launchpad bug 165285 in zim "New upstream version: 0.23" [Undecided,New] https://launchpad.net/bugs/165285 [23:22] <ScottK> StevenHarperUK: Usually I find getting copyright and all the other bits correct is more trouble than debian/rules. [23:22] <StevenHarperUK> Scottk: The problem I have is that docs of truecrypt state that the build requires ALL kernel source, not just headers : that sounds bad to me [23:23] <ScottK> StevenHarperUK: That sounds like not a beginner's project to me. [23:23] <slangasek> that sounds like a project that a non-beginner would reject as broken upstream ;) [23:23] <jdong> StevenHarperUK: yeah that sounds like a complicated package to deal with unless the kernel module portion is already a part of Ubuntu [23:23] <jdong> otherwise you're doing module-assistant territory work [23:24] <StevenHarperUK> ScottK: Yeh I did guess that, I think the bits are already in Ubuntu [23:24] <StevenHarperUK> one of them is modprobe [23:25] <ScottK> StevenHarperUK: If you want something new to work on, why don't you get your package into Debian? Since (IIRC), it's a Python app, you can join the Debian Python Application Packaging Team and it's pretty easy to get sponsored. [23:25] <StevenHarperUK> Scottk: I know its a fairly big job, but I have learned Python and debian packaging and po translations and the ubuntu process in the last 6 weeks to get my current project done [23:26] <ScottK> Sounds like working into Debian next is a good next step then. [23:26] <StevenHarperUK> ScottKk: the problem there is that I dont have a Debain test machine [23:26] * slangasek waves a wand called debootstrap [23:26] <ScottK> StevenHarperUK: You can make a Debian chroot and that's likely good enough. [23:26] <StevenHarperUK> ScottK: is there a Quick overview of Submitting to Debian? [23:26] <ScottK> StevenHarperUK: I maintain ~ half a dozen packages in Debian also without a Debian test machine. [23:27] <LaserJock> ScottK: shhhh, are you supposed to say that with slangasek around? ;-) [23:27] <norsetto> g'night all [23:27] <jdong> lol [23:27] <StevenHarperUK> Scottk: another problem Truecrypt don't make a Debain DEB [23:28] <slangasek> LaserJock: it's ok, I don't have a Debian test machine either, I run all my packages on simulations in my head ;P [23:28] <LaserJock> slangasek: haha [23:28] <LaserJock> I would wonder more if you had an Ubuntu test machine [23:28] <LaserJock> but I suspect Mark makes you have at least one [23:30] <slangasek> not Mark, that enforcement is delegated :) [23:32] <LaserJock> of course [23:33] <ScottK> So he left. Urgh. [23:35] <ScottK> On the off chance StevenHarperUK returns while I'm out, would someone please point him at https://lists.ubuntu.com/archives/ubuntu-devel/2007-August/024161.html and https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam [23:37] <badarts> what is the official repo for w32codecs and similar stuff? [23:37] <jdong> !medibuntu [23:37] <ubotu> medibuntu is a repository of packages that cannot be included into the Ubuntu distribution for legal reasons - See http://www.medibuntu.org [23:38] <jdong> and it is not official, though "as close as it gets" [23:38] <jdong> report problems with medibuntu to their launchpad product, not against the Ubuntu distribution [23:38] <jdong> oh yeah this isn't a support channel [23:39] <Ubulette> persia, http://paste.ubuntu.com/2274/ better ? same ? worse ? [23:39] <badarts> thanks :) [23:39] <LaserJock> jdong: ;-) [23:40] <StevenK> LaserJock: Ponies! [23:41] <badarts> jdong: well, not even the universe is really official, but only "as close as it gets" ;) [23:41] <ScottK> badarts: Universe is official, but unsupported. [23:42] <jdong> what ScottK said. [23:42] <jdong> medibuntu is neither official nor supported [23:42] <ScottK> By Canonical that is. The community supports it moderately well. [23:42] <jdong> though it is run by (mostly? all?) MOTU's [23:42] <Sp4rKy> mostly [23:43] <jdong> Well regardless of the badges on their maintainers, I've not seen a single thing in medibuntu that I wouldn't feel comfortable putting on my primary computer [23:45] <persia> LaserJock: Just thought of a counter-case: a .png file could be considered a patch for a "broken icon" issue. [23:45] <TheMuso> How does one force a package into a particular section, i.e universe for PPAs now? [23:46] <persia> Ubulette: I guess that's about as clean as it gets :( Thanks for trying. [23:46] <LaserJock> persia: I can't help but think that that would be a corner case. It can still be an attachment, just not listed as a patch [23:47] <LaserJock> TheMuso: how do you mean? [23:47] <persia> LaserJock: Right, but it's an example why blocking on MIME type doesn't help. The idea is to have a nice set of bugs that have been triaged to determine that they are good candidates for someone to do some testing and packaging. [23:48] <Ubulette> persia, i really tried to reduce install using dh_install and dirs but i gained only 3 lines and it made things difficult in the other *.install files [23:48] <Fujitsu> TheMuso: PPAs don't have components any more. [23:48] <TheMuso> Fujitsu: Oh. [23:48] <persia> Ubulette: I understand. When it's not a help, it's not a help. Thanks for trying :) [23:48] <TheMuso> LaserJock: ^^ [23:49] <StevenK> Mainly because components for a PPA doesn't make sense [23:49] <LaserJock> persia: well, I'm filing bugs for getting an idication in the comments that an attachment is a patch, and also a link to "depatch" it [23:49] <Fujitsu> StevenK: I would personally like PPA components to be customisable, but all ogre against multiverse. [23:49] <TheMuso> StevenK: On one hand I agree, but on the other, I don't. [23:50] <Ubulette> persia, so, what's next now? I guess I need to push an update to REVU [23:50] <persia> LaserJock: We already have that. It's currently abused (but can be fixed), and there's not currently any way to track textual patches that are not attachments. [23:50] <persia> Ubulette: Exactly. [23:50] <StevenK> TheMuso: Wha, huh? Either you agree or you disagree. :-) [23:50] <Ubulette> persia, on top of the last (uncommented) one ? [23:51] * persia seeks extended commentary from TheMuso explaining the dichotomy [23:51] <LaserJock> persia: how do you mean we already have that? [23:51] <persia> Ubulette: Yep. Same version, etc. [23:51] <Ubulette> ok [23:51] <persia> LaserJock: There's a searchable flag on attachments, and members of some ACL can set or remove the flag for any attachment to any bug. [23:51] <TheMuso> StevenK: I agree that it doesn't make sense, but I disagree in that if components were customizable, it would allow you to keep groups of packages together. [23:53] <Fujitsu> TheMuso: That's my thinking too. [23:53] <LaserJock> persia: yeah, you can get at it eventually. I'm thinking quick-n-easy triage would help get the patch flag more usable [23:53] <Fujitsu> Since they removed the multiple PPAs per user feature. [23:54] <mok0> Is there a website with the popularity of Ubuntu packages? [23:54] <persia> LaserJock: Nah: the interface is pretty easy. The problems are 1) that it is abused, so it's not inviting for Contributors to search those, and 2) it doesn't support non-attachment patches. [23:54] <LaserJock> popcon.ubuntu.com I think [23:54] <LaserJock> mok0: ^^ [23:55] <mok0> duh [23:55] <LaserJock> persia: how is it being abused? [23:55] * persia notes that popcon is voluntary, and therefore under-represents most users [23:55] <persia> LaserJock: being applied to non-patches [23:55] <LaserJock> persia: right, I'm just trying to think of ways we can make it better [23:55] <LaserJock> marking non-attachments as patches is no go [23:56] <LaserJock> but kiko said they could probably have a thing to conver a comment into an attachement [23:56] <LaserJock> *convert [23:56] <persia> Right. More ideas is great. Non-attachments as patches was a non-starter. I was using a tag, but if you've another solution that isn't just "put a new interface to existing functions", I'd be happy to hear it. [23:57] <persia> converting the comment into an attachment doesn't help. They tend to be 2 or 3 line diffs with commentary above or below. [23:57] <LaserJock> persia: well, my main concern is that we already have the patch flag, if it's broken or not working we need to get it fixed I think [23:58] <LaserJock> not that we can't use tags as well [23:58] <LaserJock> I was thinking if we can get the patch flag working better and then have a good-patch or similar tag to say the patch is verified/triaged [23:58] <LaserJock> then we have a good system for dealing with patche [23:58] <persia> I don't think it's broken, I just don't think it's a good target to point Contributors at when asking for patch review efforts. [23:59] <LaserJock> true [23:59] <LaserJock> but %50 is pretty low [23:59] <mok0> Hmm popcon doesn't seem to work properly :( [23:59] <persia> Also, my definition of "triaged" is "This is a real patch, and nobody hates it", rather than "This is a good patch"

[00:16] imbrandon: man, Planet Debian must have the lowest barrier to entry ever ;-) [00:16] LaserJock: hahaha :) [00:17] Mako needs some sort of policy on that [00:17] Hmmm. The interdiff procedure for reviewing interdiffs is not working for me here. When I get to the step of producing review.interdiff, I get the following: [00:17] interdiff: hunk-splitting is required in this case, but is not yet implemented [00:17] can't just let any riffraff on there [00:17] interdiff: use the -U option to work around this [00:17] :) [00:17] Review.interdiff has this: [00:17] diff -u easycrypt-0.2.1.14/debian/changelog easycrypt-0.2.1.14/debian/changelog [00:17] --- easycrypt-0.2.1.14/debian/changelog [00:18] +++ easycrypt-0.2.1.14/debian/changelog [00:18] hmm [00:19] TheMuso: I've not really used interdiff much [00:20] i've not used interdiff at all [00:20] persia seems to be the resident interdiff expert [00:20] * TheMuso is reading https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff#head-5faad1820a5ec43b0ba3c9186795dd8a0bfdab25 [00:21] I used once or twice I think [00:21] * ajmitch sees that the PPA floodgates are open to the masses now [00:21] yep [00:22] i wish they would just delete my /pool, the packages are merked as such for a few days now [00:22] marked* [00:22] it'll happen sometime [00:23] StevenK: btw i got a reply from 1 fo 2 of the DD's i emailed, he said he no longer has access to his debian key, and 2 of 2 bounced , lol [00:25] ok, guys [00:25] can you check Planet and see what the title on my blog post is? [00:25] Oh dear. [00:25] soren's desk [00:25] looks to be [00:26] dang it [00:26] * LaserJock kicks planet [00:26] * TheMuso also kicks planet. [00:26] For some reason, its stopped picking up my feed... [00:27] LaserJock: I don't see any recent ones from you, even directly on your blog.. [00:27] Fujitsu: Behind MOTU [00:27] Ahh. [00:27] this is the second time it's done this [00:27] Planet is getting a wrong title [00:28] my RSS feed says "Soren Hansen" [00:29] heh [00:29] LaserJock: Right, it's picking up the title from one of the tags. That's braindead. [00:29] * ajmitch sees a surprising lack of ponies on planet [00:29] Has planet been inducted into LP? [00:29] enough of the bitterness, thanks [00:29] ajmitch: getting there [00:29] Fujitsu: as in the code? [00:29] Planet is screwed. [00:30] imbrandon: Well, it seems broken. [00:30] Just a bit. [00:30] imbrandon: I think Fujitsu is just commenting on the perceived reliability of LP [00:30] ahh [00:30] ajmitch: Right. [00:31] I don't understand why this is getting messed up [00:31] oh, hmm [00:31] soem feed parsing error, I guess [00:32] s/soem/some/ [00:32] * ajmitch cannot type [00:32] it's taking the title from a pic [00:32] looks like planetplanet feed parsing error [00:32] it must find the last "title" or something [00:32] Soren’s Desk instead of [00:32] <imbrandon> yea [00:32] <LaserJock> surely I'm not the only one [00:33] <LaserJock> is jdub still doing Planet? [00:33] <imbrandon> iirc jdub is one of the devs of planetplanet upstream [00:33] <LaserJock> yeah [00:33] <imbrandon> not sure, havent been on that list in quite a while [00:33] <imbrandon> and on the other side i'm not sure how old of an instance we run [00:34] <imbrandon> where debians is all in svn we only have the configs in bzr iirc [00:34] <LaserJock> but is it a config problem, a Wordpress problem, or a PlanetPlanet problem? [00:35] <imbrandon> looks like planetplanet problem [00:35] <Fujitsu> LaserJock: It's not a WordPress problem [00:35] <Fujitsu> (although the number of other problems that WordPress has is absolutely incredible) [00:38] <TheMuso> I'm wondering whether my feed is not being picked up properly any more since I made a post during LP downtime. === gouki_ is now known as gouki [00:39] <Fujitsu> TheMuso: Planet is independent from LP, other than the config branch being hosted there, as far as I know. [00:40] * minghua finds it quite ironic that translation on LP is completely broken after upgrade while one main feature of this upgrade is "Rosetta improved". [00:41] <LaserJock> it's broken? [00:41] <Fujitsu> LaserJock: Yep. [00:41] <Fujitsu> They are experiencing enormous performance issues with the new code. [00:41] <imbrandon> ironic [00:42] <Fujitsu> Such that it doesn't work *at all*. [00:42] <Fujitsu> The 8 hour migration broke more than it solved. I am impressed. [00:42] <LaserJock> freaking heck [00:42] <LaserJock> after 8 hrs downtime? [00:43] <Fujitsu> Some of the other changes (a security fix in particular) leave a bit to be desired, too. [00:44] <TheMuso> If this is the trend for LP, I start to worry about its long term usefulness. [00:44] <Fujitsu> But the Rosetta one is the most worrisome of the lot, right. [00:48] <Fujitsu> `The speed and reliability of Launchpad Translations should now be significantly improved following a major refactoring.' [00:48] <Fujitsu> Sure, it's reliably down. [00:49] <RoAkSoAx> haha speed impreved on showing error messages xDD [00:50] * TheMuso looks at planet config, and doesn't notice any syntax errors... [00:55] <LaserJock> well, I'm sure 404s would speed Rosetta up a lot :-) [00:57] <imbrandon> bbiab [00:57] <nxvl> anyone know someway to execute a sh script step by step as in debbuging? [00:57] <nxvl> cause 'sh -x' isn't showing me nothing [00:58] <TheMuso> nxvl: What do you mean its not showing you anything? [00:59] <nxvl> TheMuso: it only shows me the error, but the lines it executes doesn't show the error [01:00] <TheMuso> nxvl: hmm. Thought of doing something like this? sh -x scriptname 2:&1 | less [01:00] <nxvl> http://pastebin.com/d16b8f83f [01:00] <nxvl> shows this [01:00] <TheMuso> Piping all output, whether from the script or otherwise, through less, to review line by line. [01:00] <nxvl> TheMuso: isn't a big output, i can read it on my terminal without a problem [01:01] <TheMuso> nxvl: Ah ok. [01:01] <TheMuso> nxvl: I still don't understand the problem. [01:02] <nxvl> TheMuso: that's the output, and there i can't see the error, it says that a )) is missing, but i don't find why [01:02] <LaserJock> nixternal: around? [01:02] <RoAkSoAx> TheMuso, he want's to debug his script step by step and he wants to know if there is a way to do it [01:02] <nxvl> so i'm asking for any way to execute all step by step to find where exactly this )) are missing [01:02] <nxvl> RoAkSoAx: exactly [01:03] <minghua> nxvl: It says it's missing on line #807. [01:03] <nxvl> minghua: well, it isn't [01:04] <nxvl> minghua: so i want to check what is it executing to check if maybe there is a malformed variable that is making the need of those )) [01:05] <minghua> I am not a shell expert, but I don't see how line-by-line execution will help you. It's a parsing error, not an execution error. [01:07] <TheMuso> RoAkSoAx: I know that. I couldn't work out what the problem was from the output. [01:07] <nxvl> minghua: yes, but i have already check all the source and there are no unclosed '(' so i think maybe a variable contains it [01:07] <TheMuso> nxvl: What is set -u for? [01:07] <minghua> -u Treat unset variables as an error when substituting. [01:07] <nxvl> TheMuso: i don't what you to work on it, only to point me to a way to execute it line by line so i can work on it :D [01:08] <nxvl> TheMuso: dunno, it's a FTBFS bug on bootcd [01:08] <nxvl> LP: #165030 [01:08] <minghua> nxvl: Have you tried to run it through bash? [01:08] <TheMuso> nxvl: Well the bash manpage may give you some pointers. [01:09] <nxvl> minghua: that solves the problem [01:09] <nxvl> why haven't i think it before [01:09] <nxvl> minghua: thnx [01:09] * nxvl hugs minghua [01:10] <minghua> nxvl: No problem. (Although I wouldn't call it "solving" the problem.) [01:10] <minghua> bug 165030 [01:10] <ubotu> Launchpad bug 165030 in bootcd "bootcd FTBFS on hardy" [Undecided,Confirmed] https://launchpad.net/bugs/165030 [01:11] <nxvl> minghua: in some way it is, because the script is running with sh, and it should run with bash [01:13] <RoAkSoAx> nxvl, but /bin/sh is just a logical link to bash or dash [01:13] <imbrandon> sh links to dash [01:14] <RoAkSoAx> yep by default to dash [01:14] <nixternal> LaserJock: yo yo [01:15] <nxvl> i use "bash +x script" and it runs fine without errors [01:16] * RoAkSoAx still cant access to rossetta translations :S [01:20] <zul> helloooo [01:21] * TheMuso wonders whether planet is ignoring his entries, due to the title of his most recent posts being too long... [01:22] <persia> TheMuso: I don't understand why, but I can reproduce the hunking issue with easycrypt. I'll dig into it to try to figure out why, and post a correction to the wiki page. [01:23] <RoAkSoAx> hey does anyone of you know why rossetta still not working? [01:24] <nxvl> is there any recipe about dpatch? i don't find very usefull the packaging guide of dpatch [01:24] <LaserJock> nxvl: it's in the packaging guide [01:24] <LaserJock> where are you looking? [01:26] <nxvl> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#head-5f4642a5564760bd8aae0fd2cbd70e6cd78c1260 [01:27] <minghua> RoAkSoAx: It has been down since the upgrade. Any reason you believe it's going to work soon? [01:29] <bddebian> Heya gang === ^4nDr3s is now known as RoAkSoAx [02:04] <TheMuso> c [02:04] <TheMuso> wrong tab... [02:06] <Fujitsu> LaserJock: Why is it that you bring a high importance to most bugs that you touch? [02:06] <Fujitsu> (LP bugs, that is) [02:08] <bddebian> Heya Hobbsee [02:10] <Hobbsee> heya [02:10] <TheMuso> Hey Hobbsee. Glad exams are over? [02:13] <LaserJock> Fujitsu: magic touch I guess [02:14] <bddebian> heh [02:14] <LaserJock> generally I don't complain much [02:14] <LaserJock> but when I do I expect to be heard ;-) [02:18] <Fujitsu> LaserJock: Heh. [02:19] <Fujitsu> Good to see that nomination bug marked High. [02:21] <Hobbsee> TheMuso: yeah, but i've still got lab reports to hand in [02:21] <TheMuso> Hobbsee: I guess thats not too bad. [02:28] <ajmitch> hi Hobbsee [02:28] <Hobbsee> hey ajmitch [02:28] <ajmitch> how's it going? [02:28] <Hobbsee> uh oh, lab people are getting annoyed about the late lab reports [02:28] <Hobbsee> ajmitch: done the last exam, random_crap_to_do--. [02:29] <nxvl> isn't there any "dpatch for dummies" or something like that [02:30] <LaserJock> nxvl: what are you having a problem with? there isn't much to it [02:30] <nxvl> i don't know if it is cause i'm tired, but i don't undesrtand anything [02:30] <nxvl> LaserJock: on putting dpatch on debian/rules [02:30] <LaserJock> oh [02:30] <nxvl> i have do it [02:30] <nxvl> but i'm getting a weird error [02:31] <LaserJock> did you add the following to the top of debian/rules: [02:31] <LaserJock> include /usr/share/dpatch/dpatch.make [02:34] <nxvl> LaserJock: http://pastebin.com/d5a705ca6 <- i have this [02:35] <nxvl> i'm calling dpatch directly instead of using dpatch.make [02:36] <minghua> Apparently, LaserJock needs to consider writing "Ubuntu packaging for dummies". :-) [02:37] <LaserJock> nxvl: ok, you can get rid of the patch-stamp: and dpatch: rules [02:38] <LaserJock> nxvl: read man dpatch.make [02:40] * minghua didn't know dpatch.make has a man page. [02:40] <ajmitch> Hobbsee: that's good :) [02:40] <LaserJock> minghua: yep [02:42] <LaserJock> nxvl: the Examples section of the dpatch.make man page has the right rules === LaserJock is now known as LaserRock [02:47] * LaserRock out [02:48] <bddebian> heh [02:48] <Hobbsee> LaserRock: ponies! [02:49] <ScottK> Good $TIMEOFDAY all. [02:49] <Hobbsee> hi ScottK [02:49] <bddebian> Heya ScottK [02:50] <ScottK> heya Hobbsee and bddebian (or are you really bdefreese?) [02:50] <StevenK> Muahah [02:50] <StevenK> LaserRock: Ponies! Ponies! Ponies! Ponies! Ponies! [02:50] <bddebian> ScottK: I'm not sure anymore ;-P [02:51] <minghua> hello ScottK. [02:56] <ajmitch> [02:57] <imbrandon> [03:00] <Hobbsee> [03:00] <TheMuso> [03:01] <nxvl> [03:02] * Fujitsu [03:03] * ajmitch was just having ssh issues thanks [03:03] * TheMuso [03:03] <TheMuso> :p [03:03] * ajmitch gives up & leaves [03:04] * Fujitsu staples ajmitch to the channel. [03:05] * Fujitsu likes stapling people to things that lack a physical manifestation. [03:06] * Hobbsee staples Fujitsu to kmos [03:06] <Fujitsu> It burns! [03:07] <StevenK> Careful, you don't know how cluelessness is contracted. [03:07] <StevenK> Hrm. Did I say that out loud? [03:07] <TheMuso> lol [03:07] <Fujitsu> Haha. [04:58] <TheMuso> /c/c [04:58] <TheMuso> argh [04:58] <RAOF_> Hey TheMuso :) [04:58] <TheMuso> Hey RAOF_. [04:59] * StevenK ponders writing an #ubuntu-motu drinking game === RAOF_ is now known as RAOF [04:59] <Burgundavia> StevenK: we don't need a game to get people drinking [04:59] <RAOF> StevenK: Based upon the incedence of "Ponies!"? [04:59] <Burgundavia> they already do that on their own [04:59] <StevenK> "Everytime TheMuso writes 'c', '/c' or any variation thereof, followed by 'argh' or 'wrong tab', take a drink." [05:00] <TheMuso> StevenK: heh [05:00] <StevenK> "Everytime someone asks LaserRock about ponies, or golden ponies, take a drink." [05:00] <Hobbsee> Burgundavia: :P [05:01] <StevenK> "Everytime Hobbsee pokes someone with her Long Pointy Stick, take a drink, unless it is you getting lambasted." [05:01] <Hobbsee> hahaha [05:01] <StevenK> This is kind of fun. [05:01] * TheMuso wonders whether bugs can be filed against planet ubuntu anywhere... [05:02] <StevenK> "Everytime RAOF complains about marking, first years or both, take a drink." [05:02] <Fujitsu> Haha. [05:02] <RAOF> That's something I could get behind! [05:03] <ajmitch> "Everytime someone criticises Launchpad, take a drink" [05:03] <TheMuso> We'd be drunk. [05:03] <Fujitsu> That's what I thought. [05:03] <ajmitch> well & truly [05:03] <StevenK> I like what WoW does when you're drunk, I saw that first hand yesterday when a friend dropped a Brewfest Pony Keg [05:03] <ajmitch> hehe [05:03] <ajmitch> the brewfest event was great for that [05:03] <StevenK> I came out with "I wonder if I'm shober.", followed by "Haha ... hic!" [05:04] <ajmitch> did you get the awesome visual effects? :) [05:04] * ajmitch started raiding last week [05:04] <StevenK> I didn't, no. [05:04] <StevenK> I got completly smashed, but no visual effects [05:05] <ajmitch> once you're well & truly gone, the screen is all blurred, you can't walk straight, and it's like tunnel vision [05:05] <StevenK> Bwahaha [05:05] <TheMuso> lol [05:05] <StevenK> So I needed to drink more [05:05] <ajmitch> yep [05:05] <ajmitch> it progressively gets worse [05:05] <StevenK> I wonder if it takes more for you to get drunk the higher level you are [05:06] * TheMuso wonders whether you end up not being able to see anything if you get blind drunk. :p [05:06] <ajmitch> no idea, I was doing it at level 70 [05:06] <StevenK> It took about 5 Brewfest Brews to get tipsy [05:06] <StevenK> I should compare my level 21 and level 44 warlocks [05:07] <Hobbsee> you all forgot about the "when someone is found to be committing crack, take a drink" [05:07] <Fujitsu> Hobbsee: That sounds dangerous. [05:08] <ajmitch> when kmos files a bug, take a drink [05:08] <StevenK> Hahah [05:08] <Fujitsu> ajmitch: Has the right idea. [05:08] * ajmitch should behave now [05:08] <Hobbsee> ajmitch: shudder. [05:08] <StevenK> "When kmos files more than ten sync requests, take that number of drinks." [05:08] <Fujitsu> Haha./ [05:09] <ScottK> minghua: Hello back (much later). [05:10] <TheMuso> When kmos applise to become MOTU, skull ${Biggeest_Beer_Serving}. [05:10] <TheMuso> biggest [05:10] <TheMuso> s/Beer/Drink/ [05:10] <Hobbsee> TheMuso: now you really need to put down the crack pipe. [05:10] <Fujitsu> And the MC doesn't have the best track record of rejecting people.. [05:10] <ScottK> This is true. [05:10] <Hobbsee> oh, *applies* to become a MOTU. not actually gets it. [05:11] <StevenK> No, no. "If Kmos applies to become an MOTU, sober up immeadiately and smack him down." [05:11] <Fujitsu> Hobbsee: Aren't they the same thing? [05:11] <Fujitsu> StevenK: Heh. [05:11] <Hobbsee> Fujitsu: no. [05:11] <TheMuso> StevenK: haha [05:14] <TheMuso> Ouch. Planet is really screwing up. [05:14] * ScottK ponders something involving lots of fire or explosives. [05:15] <Fujitsu> TheMuso: How? [05:15] <Fujitsu> ScottK: Sounds good. [05:15] <TheMuso> Fujitsu: See latest planet post. [05:16] <Fujitsu> Is that particularly broken? [05:16] <TheMuso> DId you follow the link to the actual post from his blog? [05:16] <Fujitsu> I did. [05:17] <StevenK> Clicking the link for Daniel Robitaille's latest post, it works for me. [05:17] <TheMuso> Well the title for the post on planet and the actual blog don't match. [05:17] <Fujitsu> Have his ever? [05:17] <TheMuso> The links aren't broken up, just the titles. [05:17] <TheMuso> dunno [05:19] <StevenK> A common theme is they're all wordpress.com blogs [05:20] <StevenK> (all two of them) [05:20] * ScottK tries to understand how launchpad release notes qualify for planet Ubuntu??? [05:22] <Hobbsee> because ubuntu uses launchpad? [05:22] <Hobbsee> anyway, where's that drink? [05:22] <TheMuso> heh [05:23] <ScottK> Hobbsee: Do Ubuntu release notes go on planet? [05:24] <Fujitsu> Haha: [05:24] <Fujitsu> 16:23:43 < lee_> cab: they are permanent drives they only started doing this since I installed gibson [05:24] <Hobbsee> ScottK: usually someone copies them there, yes [05:24] <Fujitsu> That's a new one. [05:24] <StevenK> The Gutsy Gibson. Hum. I always knew Mel was an animal. [05:29] <pwnguin> ScottK: do we want them to? [05:30] <Hobbsee> ScottK: usually multiple people, actually [05:30] <ScottK> I dunno. It seems about the that planet is supposed to be ABOUT Ubuntu and while Ubuntu uses LP, it's a separate thing. [05:30] <StevenK> I just think ScottK doesn't want to see the L word more than he needs to ... [05:30] <Hobbsee> yet the offtopic posts on launchpad don't concern you? [05:30] <pwnguin> well he can keep pretending that canonical and ubuntu aren't joined at the hip [05:31] <ScottK> pwnguin: It's Canonical that claims they are separate things. [05:31] <ScottK> Hobbsee: Was that directed at me? [05:32] * ScottK got a head start on the drinking game tonight. [05:32] <StevenK> Hah [05:32] <Hobbsee> ScottK: yeah [05:32] <StevenK> Why, did you look at Kmos' bug page? [05:32] * StevenK ducks [05:32] <Hobbsee> didnt' realise that you didn't say both lines when i was first typing [05:32] * Hobbsee beats StevenK [05:32] <StevenK> Ouch! [05:32] <ajmitch> duck quicker next time [05:32] <StevenK> That was directed at ScottK, though [05:32] <ScottK> No, the drinking is unrelated to Ubuntu. [05:33] <Hobbsee> ScottK: the offtopic posts on planet ubuntu are far greater in number than the LP ones - yet i havent seen you comment on them yet. [05:33] <StevenK> ScottK: Oh, so it's Launchpad. [05:33] * StevenK chuckles [05:33] <ScottK> Hobbsee: Ah. Well at least those are by people who are involved in Ubuntu. [05:33] <ScottK> But yeah. It's Launchpad. [05:33] <StevenK> So are Launchpad people, by that extension. [05:33] <Hobbsee> and launchpad are not? [05:34] <ScottK> StevenK: No, they are developers of a system we happen to use. === doko__ is now known as doko [05:34] * Hobbsee suspects he's just ranting about anythign LP, just because he can... [05:35] * pwnguin wonders if automatix deserves the kind of consideration LP gets [05:35] <ajmitch> Hobbsee: he wouldn't do that [05:35] <Hobbsee> pwnguin: definetly not. [05:35] <StevenK> ScottK: Okay, and when cprov spends an hour fixing a buildd, that doesn't relate at all? [05:35] <ScottK> StevenK: That's him fixing his proprietary service. [05:35] <pwnguin> Hobbsee: how about medibuntu? [05:35] * ScottK rants about Automatix too. [05:35] <Hobbsee> pwnguin: probably OK. ubuntu studio, etc, also go to there with their release notes [05:36] <StevenK> And Mythbuntu [05:36] <Hobbsee> yaeh, that too [05:36] * Hobbsee giggles, remembering the planet editorial spec [05:36] * StevenK wants a machine with a DVB card so he can try it [05:40] <pwnguin> ScottK: so what do you think about the affero PL? [05:40] <ScottK> pwnguin: You didn't happen to see me discuss that on #debian-devel and you're trying to get me started again? [05:41] <pwnguin> i dont watch debian-devel [05:42] <pwnguin> but maybe i'll hound up a log === Igorots is now known as Knightlust [05:43] <Amaranth> automatix people are on planet [05:43] <Amaranth> jdong is on there, isn't he? [05:43] <ScottK> pwnguin: Short version is I don't think it's DFSG free. [05:43] <ScottK> jdong is not an Automatix guy. [05:44] <Amaranth> he used to be [05:44] <ScottK> jdong runs *-backports which is an official Tech Board blessed part of the Ubuntu project. [05:44] <Amaranth> no one is an automatix guy anymore, automatix is gone [05:44] <ScottK> Three cheers for that. [05:44] <Amaranth> and i know what jdong does :P [05:46] <pwnguin> there's automatix2 [05:46] <Amaranth> there won't be for hardy [05:47] <pwnguin> how'd that happen? [05:47] <Amaranth> i hang out with the main dev a couple times a week :P [05:48] <Amaranth> and he was at uds [05:48] <pwnguin> i see [05:48] <Amaranth> we went through the list of what automatix is good for that _isn't_ easy to do with stock ubuntu [05:48] <Amaranth> it came down to adding a couple things to ubuntu-restricted-extras and some x86 on x86-64 stuff [05:49] <ScottK> Cool. [05:49] <Amaranth> which afaik is just skype and flash [05:50] * ScottK will grumble about Envy posts on planet, just to be fair. [05:50] <Amaranth> envy apparently got a lot saner too [05:50] <Amaranth> i think mvo helped the guy out [05:50] <pwnguin> there has got to be a better way than how envy works [05:51] <pwnguin> good [05:51] <Hobbsee> Amaranth: why didn't i hear about the extra stuff added to u-r-e then? [05:51] <Hobbsee> or have i, and not responded? [05:51] <Amaranth> Hobbsee: because nothing has been added [05:52] <Amaranth> and i think it was more a matter of opinion on whether or not things should be added to it [05:52] <Hobbsee> Amaranth: no bug has been filed, either. [05:52] <ScottK> So I'm reading about PackageKit on planet. Does this mean we're giving up on Debian package management in the long run? [05:52] <Hobbsee> yeah, true [05:52] <Amaranth> ScottK: PackageKit is just a frontend [05:52] <ScottK> Amaranth: For what? [05:52] <Amaranth> apt/dpkg [05:52] * pwnguin would rather hear more about policyKit on the planet. that stuff's scary [05:53] <StevenK> I'm guessing it's backend-agostic, and deals with both rpm/yum and apt/dpkg [05:53] <Amaranth> right [05:53] <StevenK> Like SMART [05:53] <Amaranth> no [05:53] <StevenK> Except SMART is dumb [05:53] <ScottK> So it's more of an Adept/whatever Gnome uses replacement? [05:53] <Amaranth> it's actually a gnome-app-install/update-notifier replacement [05:53] <pwnguin> synaptic? [05:54] <ScottK> Dunno. Never used Gnome, but that sounds right. [05:54] <ScottK> OK, so we're going to make it easy to mix RPM and Debian packages? [05:54] <Amaranth> no [05:54] <ScottK> Good. [05:54] <pwnguin> i think we're making it easier to integrate package management with gnome [05:54] <ScottK> Great. [05:54] <Amaranth> it's just a distro-agnostic way for things to install packages [05:55] <pwnguin> wouldn't that need namespaces to be identical? [05:55] <slangasek> and why is that valuable? :) [05:55] <ScottK> OK. I'm having a hard time reconciling distro-agnostic and not packaging system agnostic. [05:55] <Amaranth> slangasek: consistent GUI [05:55] <minghua> Making it easier for users to switch distros, I suppose. [05:55] <ScottK> Amaranth: So it's a consistent gui for different things? [05:56] <Amaranth> ScottK: right [05:56] <pwnguin> the backend is probably not distro-agnostic then ;) [05:56] * slangasek is not a distro agnostic, he knows which packaging system he prays to [05:56] <ScottK> And this is a good thing? [05:56] <minghua> ScottK: Yes, it has different backends for APT/RPM/etc. [05:56] <Amaranth> it's basically a way for everyone else to get gnome-app-install instead of just ubuntu :P [05:56] <slangasek> yeah, who cares about them? :) [05:57] <pwnguin> psh [05:57] <Amaranth> but it does the policykit thing too so that's useful [05:57] <pwnguin> they can learn to compete ;) [05:58] <Hobbsee> interesting. video's dont owrk onw [05:58] <slangasek> here, let me fix that for you with VideoKit [05:58] <Amaranth> slangasek: that's called gstreamer [05:58] <ScottK> Amaranth: What is the "poicy kit thing"? [05:58] <StevenK> And then you'll need to manage all of your kits with KitKit [05:58] <slangasek> it's called that /today/ [05:59] <Amaranth> as used by DesktopKit [05:59] <Amaranth> aka GNOME [05:59] <slangasek> I manage mine with KitKat [05:59] <TheMuso> heh [05:59] <StevenK> slangasek: Just for that, I'm breaking your fingers [05:59] <StevenK> :-P [05:59] <Amaranth> ScottK: basically instead of running the whole app as root you have a daemon that speaks dbus [05:59] <Amaranth> and dbus system activation starts it on demand [05:59] <minghua> Oh, are we talking about PackageKit or PolicyKit? Because they are completely different things. [05:59] <Hobbsee> StevenK: you might have to coordinate alpha 1, if you do... [06:00] <Amaranth> i said PackageKit was useful because it used PolicyKit [06:00] <StevenK> I didn't say I'd break all of them. [06:00] <ScottK> Amaranth: When it starts it, what user does it start it as? [06:01] <Amaranth> ScottK: not sure [06:01] <Amaranth> probably root? [06:01] <ScottK> I'm still not getting the benifit then. [06:01] <Amaranth> less code running as root [06:01] <Amaranth> and no GUI code [06:02] <minghua> ScottK: Probably one backend and one front end. [06:02] <minghua> Backend runs as root and frontend runs as ordinary user. [06:02] <pwnguin> policyKit itself is about not running gtk as root [06:02] <pwnguin> etc [06:02] <minghua> I don't claim I know PackageKit though. [06:02] <StevenK> ScottK: The whole point is to minimise down as much as possible the code that runs as root. [06:03] <pwnguin> its still a massive transition that's going to be painful, i think a few people already found that out ;) [06:03] * TheMuso hopes the policykit stuff happens. It will also mean admin tools are accessible to users using assistive tech. [06:03] <ScottK> StevenK: Well that makes sense. I got confused when he said it ran as root anyway. [06:03] <StevenK> ScottK: PolicyKit is a very small helper running as root which the GUIs talk to using dbus [06:04] <pwnguin> policy-kit is going to make an already confusing time with thinkfinger more confusing =( [06:04] <ScottK> I think I'm just going to say it's Gnome and I don't need to understand it. [06:04] <pwnguin> heh [06:05] <Hobbsee> ScottK: but you might end up switching to gnome :P [06:05] <ScottK> Hobbsee: I might. I might alswo switch back to Windows. I don't worry to much about either of those eventualities. [06:07] <Hobbsee> ScottK: then how would you yell at redmond? go over there? [06:08] <ScottK> I'm not saying there's any real risk of that, just saying the risks are roughly equivalent. [06:08] * StevenK is of the opinion that Gnome looks .... I don't know, prettier and shinier than KDE. [06:09] * ScottK finds KDE more comfortable. [06:10] <pwnguin> GNOME has a lot of gray for a "prettier and shinier" than KDE [06:11] * Hobbsee killed a whole lot of the grey from gnome [06:11] * StevenK quite likes grey. [06:13] <pwnguin> Is the double panel a proven usability thing, or just an artifact of history? [06:21] * ScottK discovers hardy no longer has libmilter0, just libmilter1 and gives up and goes to bed. [06:21] <ScottK> Good night all. [06:23] <LaserRock> we've really added 18 new MOTUs since May? [06:31] <Hobbsee> pwnguin: you can certainly fit more stuff on there [06:31] <Hobbsee> LaserRock: ponies! [06:31] <Fujitsu> Hobbsee: That's another reason for the switch to EXA. Video overlays work. [06:32] <Hobbsee> Fujitsu: ahhh. my videos just crash now :) [06:32] <pwnguin> Hobbsee: on the contrary I can fit more programs without gnome panel getting in my way at the bottom ;) [06:32] <Fujitsu> Hobbsee: Hah. [06:32] <Hobbsee> Fujitsu: interesting. [06:33] <Hobbsee> The program 'totem' received an X Window System error. [06:33] <Hobbsee> This probably reflects a bug in the program. [06:33] <Hobbsee> The error was 'BadAlloc (insufficient resources for operation)'. [06:33] <Hobbsee> (Details: serial 99 error_code 11 request_code 140 minor_code 19) [06:33] <Fujitsu> That sounds right [06:34] <Hobbsee> then again, this is xaa still. [06:34] <Fujitsu> Right. [06:47] <dholbach> good morning [07:07] <dholbach> Happy REVU Day! === doko_ is now known as doko === LucidFox is now known as Sikon_Stargate === \sh_away is now known as \sh [08:39] <\sh> moins [08:41] <pwnguin> wow, ipkg is really based on dpkg, huh [08:43] <\sh> pwnguin, ipkg as in linux for routers? ,-) [08:43] <pwnguin> yea [08:44] <pwnguin> well, i think it started out for ipaq [08:44] <pwnguin> but i just got ahold of a spare router [08:44] <dholbach> so how's the REVU day coming along? [08:45] * dholbach looked at a bunch of 'in progress' needs-packaging bugs already and the revu uploads connected to them [08:51] <Sikon_Stargate> I'd like to request review of two updated packages: http://revu.tauware.de/details.py?package=qdvdauthor http://revu.tauware.de/details.py?package=avidemux [08:52] <dholbach> Sikon_Stargate: looking at qdvdauthor [08:52] <TheMuso> Sikon_Stargate: Looking at avidemux. [08:53] <dholbach> Sikon_Stargate: did you rebase on the marillat package? [08:58] <dholbach> Sikon_Stargate: I'm just diffing the latest debian-multimedia upload and yours: why the -dbg package? why the dropped patch? why dvdauthor/dvd-slideshow/mjpegtools as Build-Depends? [08:58] <nand`> hi MOTUs! I'd like a review of the package ike please! (one advocate already). Thanks! http://revu.ubuntuwire.com/details.py?package=ike [09:00] <dholbach> Sikon_Stargate: added comments to qdvdauthor page [09:01] <Sikon_Stargate> dholbach> I merged the Ubuntu version [09:01] <Sikon_Stargate> Ubuntu has 1.0.0~rc1, debian-multimedia.org has 1.0.0~rc2, and this is 1.0.0~rc3 [09:02] <dholbach> debian-multimedia has 1.0.0~rc3 too [09:02] <dholbach> http://www.debian-multimedia.org/pool/main/q/qdvdauthor/ [09:02] <dholbach> I understand the need for the desktop file changes and they are mentioned in a former revu upload [09:03] <dholbach> the other changes I don't understand :) [09:03] <TheMuso> Sikon_Stargate: With avidemux, why did you migrate to cmake? Or is that an upstraem change? [09:04] <Sikon_Stargate> Upstream only had autotools for 2.3. With 2.4, they offer a choice between autotools and cmake. === Sikon_Stargate is now known as LucidFox [09:04] <TheMuso> Sikon_Stargate: Right. So why change? [09:04] <LucidFox> Personal preference, I guess. [09:05] <LucidFox> If autotools is preferable, I can change to that. [09:06] <\sh> LucidFox, is upstream going the cmake way now, and offering this as a transitional change? [09:06] <dholbach> nand`: can you change the entry in debian/changelog to (LP: #148103)? [09:06] <dholbach> nand`: or if you agree I do it on my own and upload right away [09:06] <LucidFox> Upstream has no preference for a specific build system, as far as I can tell. [09:06] <nand`> dholbach: If it's okey with you, no pb, thanks! [09:07] <dholbach> nand`: ok, uploading it! congratulations! [09:07] <LucidFox> Both will be supported at least in the near future. [09:07] <TheMuso> LucidFox: Ok thats fine then. [09:07] <nand`> dholbach: yay! [09:08] <\sh> wow...I found a way to gpg sign stuff without having my gpgcard with me :) [09:09] <soren> \sh: ? [09:09] <\sh> debuild -S -k'<your key id>!' <-- the exclamation mark is important...fyi [09:09] <LucidFox> dholbach> For qdvdauthor, I dropped the patch because it results in qplayer and qslideshow not building, and the Ubuntu version builds them. [09:09] <LucidFox> (the "make" lines are commented out in the patch) [09:10] <\sh> soren, I have a signing subkey on a gpg card...but if you don't have it handy..you are fcked, if you don't have this trick handy with the exclamation mark ,-) [09:10] <TheMuso> LucidFox: Why did you remove the Bugs field in debian/control: [09:10] <LucidFox> TheMuso> for avidemux? [09:10] <TheMuso> LucidFox: Yes. [09:11] <LucidFox> Oversight. I'll re-add it. [09:11] <Fujitsu> \sh: Can't you only use subkeys for encryption? [09:12] <\sh> Fujitsu, no...you can use subkeys for encryption, signing and authentication :) [09:12] <dholbach> LucidFox: this is the current debdiff between debian-multimedia and your proposed version: http://daniel.holba.ch/temp/qdvdauthor.debdiff [09:13] <\sh> phew../me has a headache...clean restart yesterday evening ...:( [09:13] <TheMuso> LucidFox: If the avidemux binary package is transitional, why is it architecture any? [09:14] <dholbach> LucidFox: desktop changes are fine, if you want to drop the patch, that's fine, but please document the change in debian/changelog and don't change debian/rules and debian/control for that, let's try to keep the diff small, also: I understand the added Depends (could some of them be recommends?), but why do you add them as Build-Depends? are they needed on the build machine to build the package? [09:15] <TheMuso> LucidFox: And, if Christian Marillat made this package prior to Nicolai Spohrer, there is no reason to change who debianised it at the top of the copyright file. [09:16] <TheMuso> LucidFox: According to the diff, yes this package was originally debianised in 2002, so that should certainly be left as it is IMO. [09:17] <TheMuso> LucidFox: You also changed the copyright authors/upstream authors. You haven't listed the years of copyright for these author's code contribution. [09:18] <LucidFox> dholbach> So I should leave dpatch support in debian/rules even though there are no patches? [09:19] <dholbach> LucidFox: yes, else you divert from the debian packaging just for the sake of a dropped patch [09:19] <dholbach> nand`: are you sure that bug 148103 is the bug you want to close with the ike upload? [09:19] <ubotu> Launchpad bug 148103 in ubuntu "[needs-packaging] Request for packaging, VPN client" [Wishlist,Triaged] https://launchpad.net/bugs/148103 [09:19] <nand`> dholbach: Yes, this is this one. [09:20] <TheMuso> LucidFox: I also don't see what changes Nicolai Spohrer made mentioned in the changelog at all. [09:20] <nand`> dholbach: the name is not explicitely mentioned, but this is it [09:20] <LucidFox> All right. I will also leave the patches in debian/patches and only remove them from 00list. [09:20] <dholbach> nand`: thanks a lot for that [09:21] <dholbach> LucidFox: great, that change is easy to merge :-) [09:21] * dholbach hugs LucidFox [09:21] <TheMuso> LucidFox: And, the only thing I have against cmake, is that vast quantities of debian/rules are altered by this update. Like dholbach has said for your other package, this diverges from Debian Multimedia a lot, which means more merging work in the future. [09:21] <dholbach> also it helps if you document every bit you change in the changelog [09:22] <TheMuso> At this point, I do not feel comfortable giving this an ack. [09:22] <LucidFox> debian-multimedia.org won't package avidemux until it reaches 2.4 final - Marillat said so [09:22] <dholbach> Somehow I knew that it was persia who added "It's REVU Day! Packagers; announce your packages, Reviewers: Add as many hammers as you can." to the topic :-) [09:22] <pwnguin> what's the process to get a package sync'd from experimental? [09:22] <TheMuso> Nevertheless, any packaging differences means more merging work. [09:23] <dholbach> pwnguin: file a sync request and just mention that it's experimental instead of unstable [09:23] <dholbach> LucidFox: if we decide to ship an unstable avidemux that's our decision [09:23] <dholbach> LucidFox: still we can try to keep the packaging delta small [09:25] <TheMuso> dholbach: The diff as it stands between both debian/ dirs is 19K. [09:25] <dholbach> right [09:26] <pwnguin> dholbach: ok, i guess the terminology is a New, not a Sync [09:26] <dholbach> pwnguin: is it a new package that has never been in ubuntu before? [09:26] <pwnguin> correct [09:26] <dholbach> then it's still a sync :) [09:26] <pwnguin> ok [09:27] <dholbach> but right, best ask in #ubuntu-devel - I'm not sure that experimental is automatically synced [09:28] <pwnguin> im pretty sure its not [09:28] <pwnguin> i figured there'd be some method of triggering a discussion on inclusion from experimental [09:29] <dholbach> either ask for it in #ubuntu-devel or file a normal sync bug, just stating that it's experimental you're talking about [09:32] <mok0> I was asked to make an icon for xtide for the merge. Now I've done it, I have png files in sizes 128 -> 16 pixels. Now I need to know how to add them to the package, and where to install them. [09:34] <minghua> mok0: I think the place to install them is /usr/share/icons/hicolor/*/, but adding them to the package would be a challenge if you don't repack upstream tarball. [09:34] <mok0> minghua: I don't want to do that [09:35] <mok0> repack tarball I mean [09:35] <minghua> mok0: BTW is there any definitive conclusion about Torque's licensing? [09:36] <dholbach> mok0: check out ekiga to find out how you can add icons without changing the tarball [09:36] <LucidFox> dholbach> https://bugs.launchpad.net/ubuntu/+source/qdvdauthor/+bug/164815 - I have attached a new debdiff. [09:36] <ubotu> Launchpad bug 164815 in qdvdauthor "qdvdauthor 1.0.0~rc3" [Undecided,In progress] [09:36] <minghua> mok0: You can apply some uuencode/uudecode magic then. [09:36] <mok0> No I don't think so. Didn't we agree that the package could go into universe? [09:36] <mok0> uuencode, yes I can try that [09:36] <minghua> mok0: I didn't read the IRC log, I only read the mail to motu-science. [09:36] <mok0> I can also send the icons upstream [09:36] <LucidFox> (also uploading the new version to REVU at the moment) [09:37] <dholbach> LucidFox: does it still build? [09:37] <mok0> minghua: Is there a formal body within ubuntu to clarify license matters? [09:37] <dholbach> LucidFox: you remove the dpatch build-dep [09:38] <LucidFox> oops! [09:38] <dholbach> you might also want to remove "+ * Dropped dpatch support from debian/rules, no patches left." [09:38] <minghua> mok0: There should be, I'm not sure which though. Maybe archive admins. [09:38] <dholbach> LucidFox: I'll review the patch in a bit again, please add the link to the debian-multimedia source package again in the bug [09:38] <mok0> minghua: so the package needs to go through ordinary review, then [09:39] <mok0> ... perhaps it can go into multiverse [09:40] <minghua> mok0: I don't quite understand what you mean. It always needs to go through review, whether for universe or multiverse. [09:40] <mok0> minghua: I was thinking that a license clarification could be made before people started wasting time on the package [09:41] <mok0> minghua: It would be really useful to get torque into ubuntu, though [09:41] <minghua> mok0: Let me have a look at the license. [09:41] <minghua> mok0: Yeah, I'm really insterested in Torque. [09:41] <mok0> minghua: you want me to pastebin the license? [09:42] <LucidFox> Building qdvdauthor now, also reuploaded the debdiff [09:44] <mok0> minghua: http://paste.ubuntu-nl.org/45898/ [09:46] <minghua> mok0: I was reading it on REVU, but thanks anyway. [09:46] <minghua> mok0: Looks pretty free to me. The only problem would be the advertise clause. [09:47] <mok0> minghua: yes [09:47] <seb128> hi [09:47] <mok0> minghua: do you know what the policy is on that? [09:47] <dholbach> hey seb128 [09:47] * dholbach hugs seb128 [09:47] <seb128> is "Luca Falavigna <dktrkranz@ubuntu.com>" connected on IRC? [09:47] <dholbach> happy REVU day! [09:47] <seb128> dholbach: thanks ;-) [09:47] <dholbach> seb128: it's dktrkranz on IRC too [09:47] <minghua> mok0: I'd say go ahead and prepare for universe upload, I may look at it when I have time. [09:47] <seb128> dholbach: ok, so he's not around [09:48] <seb128> thanks [09:48] <dholbach> doesn't look like it [09:48] <minghua> mok0: No idea about the advertisement clause. It may be indeed not DFSG-free. Ubuntu probably don't care, though. [09:49] <seb128> his tora upload looks like typically something that should be on sync with Debian, changes are a call to dh_icons and a builddep change [09:49] <seb128> and he didn't send the changes to debian [09:49] <mok0> minghua: ... isn't multiverse meant for weird license issues like that? [09:50] <minghua> mok0: To be honest with you, I don't know exactly what is "free" in Ubuntu's terms. I know there are differences with DFSG, though. [09:50] <minghua> mok0: For example, IIRC, CC-BY-SA is free for main/universe in Ubuntu, but not DFSG-free for Debian. [09:50] <LucidFox> o_O why? [09:51] <mok0> minghua: ok [09:51] <mok0> minghua: you feel like reviewing it ;-) [09:52] <minghua> mok0: The problem is that nobody else seems interested in cluster computation stuff. :-( [09:52] <minghua> And I'm busy. [09:52] <mok0> minghua: I might lure someone else into reviewing it [09:52] <LucidFox> TheMuso> Regarding the transitional package, I listed the architecture as "all" because it contains no architecture-dependent files. Is this incorrect? [09:53] <mok0> minghua: perhaps we should form a cluster computing interest group [09:53] <TheMuso> LucidFox: Um... Let me check. I thought you set the transitional package to architecture any. [09:53] <LucidFox> wait, I did. [09:53] <slangasek> minghua: CC-BY-SA 2.0 (if I remember the version number right) appears to be acceptable for main, since they fixed the key bugs in version 1 [09:53] <LucidFox> It's any. [09:53] <LucidFox> So it should be all? [09:54] <TheMuso> Yes if it doesn't contain any architecture dependent files, which being a transitional package, it shouldn't. [09:54] <LucidFox> Thanks. [09:55] <LucidFox> Is it okay for the transitional package to contain a symlink /usr/bin/avidemux -> avidemux2_gtk? [09:55] <minghua> slangasek: Thanks for the clarification. [09:55] <minghua> slangasek: tango-icon-theme is still in non-free, though. [09:56] <TheMuso> LucidFox: If the package depends on another that contains that file, and the dependency is strictly versioned, yes it should be ok. As it is, theres no point, since a transitional package is only to pull in dependencies that replace it, and nothing else. [09:57] <slangasek> minghua: sorry, I just checked and I had the version number wrong; it's CC-BY-SA 3.0 that has the bugfixes [09:57] <slangasek> and tango-icon-theme lists 2.5 [09:57] <LucidFox> avidemux (transitional) depends on avidemux-gtk (= ${binary:Version}) [09:57] <minghua> slangasek: Ah, that makes more sense. [09:57] <LucidFox> as for the symlink, I don't think there's any point in having it in avidemux-gtk [09:57] <TheMuso> LucidFox: Yes, but as I said, a transitional package doesn't contain anything. [09:58] <mok0> minghua: re: clustercomputing, I got wulfware in gutsy, which is pretty nifty [09:58] <Riddell> siretart: how come vdr-plugin-xineliboutput had to be backported manually? [09:58] <dholbach> LucidFox: commented on it again [09:59] <minghua> mok0: We can talk about torque and cluster computing stuff later on -science list. [10:03] <mok0> minghua: sure [10:03] <mok0> norsetto: re xtide, I've made some icons myself [10:05] <norsetto> mok0: cool. Don't forget to license them. [10:05] <mok0> norsetto: How do I add them to the package? [10:06] <mok0> norsetto: I have never dealt with icons before [10:06] <norsetto> moko0: you have two ways: either you add them as .xpm in /debian [10:06] <norsetto> mok0: you have two ways: either you add them as .xpm in /debian (soory for the mispell) [10:07] <norsetto> mok0: or you uuencode them and add them in /debian. In this latter casse, you need to do on-the-fly decoding during build [10:07] <mok0> norsetto: and where are they to be installed? [10:08] <norsetto> mok0: they are for the .desktop file, right? In this case they go to /usr/share/pixmaps [10:09] <mok0> norsetto: I have several sizes, from 128 -> 16 pixels [10:09] <norsetto> mok0: you need to provide at least a 48x48 pixels one in there. You can also provide different sizes and install them in /usr/share/icons/hicolor and this also requires registration in gnome (using dh_icons) [10:10] <norsetto> for the .desktop file one 48x48 should be sufficient though [10:10] <mok0> norsetto: ok. What about KDE, then? [10:11] <norsetto> mok0: in 3.5 there is no icon cache, but it is foressen in 4, for which most probably we need to expand the debhelper script [10:12] <mok0> norsetto: ok, let's worry about that later, then [10:12] <norsetto> mok0: this link: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is useful for icons [10:12] * mok0 looks [10:13] <mok0> norsetto: thx, I'll read it carefully [10:13] <norsetto> mok0: np, hope it helps [10:14] <mok0> norsetto: hopefully I can get it done by today [10:15] <norsetto> mok0: take your time, there is no rush [10:16] <mok0> norsetto: I'm at home with a cold, so it can keep me from feeling sorry for myself :-) [10:16] <minghua> mok0: If you can send the icons to upstream and they release regularly, it may be smart just to include one 48x48 XPM icon in the Ubuntu upload. [10:16] <minghua> mok0: Then you don't need to play with uuencode/uudecode. [10:17] <mok0> minghua: It's an idea, I'll think about it [10:18] <minghua> mok0: Although OTOH, upstream needs to figure out where/how to install the icons as well. [10:19] <mok0> minghua: I will contact upstream and ask if he wants the icons. I guess he should also put the .desktop entry in there [10:20] <mok0> minghua: If he would just put the files in a directory, that would be fine I think [10:20] <minghua> mok0: Yeah, doing these things with upstream is always a good idea. [10:24] <mok0> What license should I use for the icons? GPL? [10:26] <LucidFox> dholbach> reuploaded [10:26] <norsetto> mok0: if the package is licensed with a GPL seems a good idea [10:26] <mok0> norsetto: I'll check [10:27] <LucidFox> norsetto> I have attached debdiffs for higlayout, woodstox and freecol. All of them build, and freecol runs. [10:27] <norsetto> mok0: don't use the SA-BY-CC 2.5 or debian will not add them though ..... [10:29] <norsetto> LucidFox: ok, looks good. For the time being we should limit to sync though. I wonder why debian did not consider using the free java, perhaps it is worth asking them? [10:29] <LucidFox> I already filed a debian bug for free-java-sdk in higlayout. [10:30] <LucidFox> However, it's not possible for woodstox and freecol. I modified them to build with icedtea, which is not in Debian. [10:30] <mok0> norsetto: xtide is GPL v. 2 [10:30] <LucidFox> (Specifically, they depend on classes only in Java 6, and not in Classpath yet.) [10:31] <norsetto> LucidFox: ah! ok [10:34] <norsetto> proppy: morning [10:35] <proppy> hi ! [10:37] <norsetto> proppy: how is your miserable monday? [10:37] <proppy> norsetto: nice [10:37] <proppy> I've just been playing with soya3d examples [10:37] <proppy> and will report a bug against its debian packaging [10:37] <proppy> very interesting [10:37] <proppy> :) [10:37] <proppy> (apt-cache show python-soya3d) [10:38] <proppy> norsetto: and yours ? [10:38] <norsetto> !info python-soya3d [10:38] <ubotu> Package python-soya3d does not exist in gutsy [10:38] <proppy> :( [10:38] <norsetto> !info python-soya3d hardy [10:38] <ubotu> Package python-soya3d does not exist in hardy [10:38] <norsetto> proppy: there you are :-) [10:38] <proppy> !info python-soya [10:38] <ubotu> python-soya: high level 3D engine for Python. In component universe, is optional. Version 0.13.2-3ubuntu2 (gutsy), package size 1073 kB, installed size 3924 kB [10:39] <proppy> !info python-soya-doc [10:39] <ubotu> python-soya-doc: high level 3D engine for Python. In component universe, is optional. Version 0.11.1-1 (gutsy), package size 1739 kB, installed size 2368 kB [10:39] <proppy> all the .py files in the tutorial are gzip by default [10:39] <proppy> and the data too [10:39] <proppy> you have to run something like find . | grep gz$ | gunzip [10:39] <norsetto> proppy: yes, thats debian policy if the size is above a certain limit (don't remember which one) [10:40] <proppy> tu be able to run them [10:40] <proppy> let me check [10:40] <proppy> (the size of the example against the limit of the policy) [10:40] <proppy> norsetto: and you how are you ? [10:40] <norsetto> proppy: they are in /usr/share/ right? [10:40] <proppy> on this bloody money [10:41] <proppy> yep [10:41] <proppy> /usr/share/doc/python-soya-doc/tutorial/game_skel-3.py.gz [10:41] <norsetto> proppy: money is all bloody ;-) [10:41] <proppy> /usr/share/doc/python-soya-doc/tutorial/data/blender/knife.blend.gz [10:41] <proppy> s/money/monday :) [10:41] <proppy> /usr/share/doc/python-soya-doc/tutorial/data/worlds/ferme.data.gz [10:43] <proppy> norsetto: is this the correct reference for the doc policy http://www.debian.org/doc/debian-policy/ch-docs.html ? [10:44] <norsetto> proppy: yes, I would think so [10:44] <proppy> cause they don't say that examples should be compressed [10:45] <imbrandon> moins [10:45] <proppy> imbrandon: hi [10:45] <imbrandon> heya proppy how goes it [10:45] <norsetto> proppy: well, the size limit is 4k [10:46] <imbrandon> proppy: anything more than 4k [10:46] <proppy> imbrandon: nice, I had steack and eggs for breakfast ! [10:46] <norsetto> proppy: just checked in dh_compress [10:46] <norsetto> proppy: swine :-) [10:46] <imbrandon> hehe :) [10:46] <imbrandon> ok opinions , how evil is this [10:46] <imbrandon> +builddist = $(shell lsb_release -si) install -g root -o root -m 644 \ [10:46] <imbrandon> - mirror.list debian/apt-mirror/etc/apt/mirror.list [10:46] <imbrandon> + debian/${builddist}-mirror.list debian/apt-mirror/etc/apt/mirror.list [10:47] <proppy> norsetto: dhcompress --exclude tutorial ? [10:47] <imbrandon> based on if its built for debian or ubuntu === cprov-away is now known as cprov [10:48] <proppy> hi [10:48] <proppy> oups :) [10:52] <proppy> maybe these files are to be put somewhere else for not to be compressed [10:54] * dholbach hugs proppy, Czessi, imbrandon and norsetto [10:54] <dholbach> how's it going guys? [10:54] <huats> morning proppy [10:54] <norsetto> proppy: the policy dictates that examples should be in /usr/share/doc [10:54] <LucidFox> norsetto> Incidentally, what do you mean by "we should limit to sync"? Limit to unmodified packages? [10:54] <huats> hey dholbach [10:54] <imbrandon> moins dholbach , good, just wakin up [10:54] <Czessi> Morning [10:54] <dholbach> hey huats [10:54] <norsetto> hiya dholbach! [10:54] <huats> proppy: apparently you did something this morning [10:55] <proppy> huats: ? [10:56] * proppy hugs dholbach [10:56] <proppy> norsetto: I get another package in debian : http://qa.debian.org/developer.php?login=proppy@aminche.com :) [10:56] <norsetto> LucidFox: I've never done this, but I assume that we should first sync as is from debian, and then patch it; I wouldn't know how to patch it first and then ask for it to be archived!? [10:57] <huats> proppy: apparently you did something that norsetto think might interest me... [10:57] <norsetto> proppy: so there: http://qa.debian.org/developer.php?login=norsetto@ubuntu.com [10:58] <proppy> norsetto: I beat you :) [10:58] <LucidFox> Hmm. If I ask the Debian developer to build-depend on icedtea-java7-jdk | sun-java6-jdk, which one is the LP build system going to pick? [10:58] <proppy> huats: I'll be glad to share, do you want me to guess ? [10:59] <norsetto> proppy: ok, I surrender :-) [10:59] <imbrandon> proppy / norsetto : http://qa.debian.org/developer.php?login=brandon@imbrandon.com ( ~50k popcon ) [10:59] <imbrandon> :) [10:59] <proppy> huats: are you interested in juce packaging ? [10:59] <proppy> huats: are you interesting in a swf backend for cairo ? [10:59] <norsetto> imbrandon: we hate you with all our gutsy :-) [10:59] <imbrandon> hehe [10:59] <proppy> huats: are you interested in versioning tiddlywiki with mercurial ? [11:00] <proppy> huats: are you interested in freesoftware poker ? [11:00] <imbrandon> swf backend for cairo ? [11:00] <huats> proppy: honnestly I am not sure :D [11:00] <norsetto> LucidFox: the selection is from left to right [11:00] <proppy> you beat me imbrandon :( [11:00] <huats> proppy: well poker, might be interested [11:00] <huats> :)à [11:00] <proppy> huats: are you interested in python ? [11:00] <proppy> huats: apt-get install python-poker2d [11:00] <LucidFox> Ah, then it should build. I'll ask him to merge the necessary changes. [11:00] <proppy> huats: apt-get source and improve please ! [11:00] <huats> proppy: I tend to be more and more interested in python actually [11:01] <proppy> huats: go so that the thing norsetto told you about me ? :) [11:02] <huats> proppy: the thing is I don't know... only norsetto knows it :) [11:03] <proppy> huats: norsetto seems to like introduce people to each others :) [11:04] <proppy> maybe he will upload some kind of dating site for ubuntu developers and mentors [11:04] <huats> proppy: oh, apparently it is related to your breakfast [11:04] <norsetto> proppy: I'm a pairing specialist ..... [11:05] <imbrandon> LucidFox: iirc it should pickup the first one listed first, but i would try it on a PPA first ( buildd simulation ) [11:05] <proppy> huats: steak and eggs ? [11:06] * imbrandon looks arround for some Mt. Dew [11:06] <proppy> imbrandon: want to help in the swf backend for cairo /join #osflash [11:06] <imbrandon> proppy: i really dont have the time to take on something new atm, but i think its interesting [11:06] <proppy> !info lib-visual [11:06] <ubotu> Package lib-visual does not exist in gutsy [11:06] <proppy> !info libvisual [11:06] <ubotu> Package libvisual does not exist in gutsy [11:07] <imbrandon> !info libvisual-0.4-0 [11:07] <ubotu> libvisual-0.4-0: Audio visualization framework. In component main, is optional. Version 0.4.0-1.1 (gutsy), package size 128 kB, installed size 400 kB [11:07] <imbrandon> :) [11:07] <proppy> imbrandon: I only hacked the curve_to in a couple of hour session, but it's definitly something achievable and interesting [11:07] <imbrandon> libvisual is the source package, the bot looks at binary packages [11:07] <proppy> imbrandon: how ok [11:07] <norsetto> proppy: you can't win with imbrandon [11:08] <norsetto> proppy: heisbrandon you know [11:08] <proppy> imbrandon: audio visualization framework, I'm not sure I get it :) [11:08] <imbrandon> proppy: when you play music in xmms or amarok it makes pretty stuff on your screen === proppy is now known as imwithbrandon [11:08] <imwithbrandon> imbrandon: nice [11:08] <imbrandon> lol [11:09] <imwithbrandon> imbrandon: in opengl ? [11:09] <imwithbrandon> imbrandon: where ? [11:09] <imbrandon> yes [11:09] <imbrandon> where what ? [11:09] <norsetto> imwithbrandon: if you can't win, join them (definetively good tactic :-)) [11:09] <imwithbrandon> imbrandon: in a new window ? [11:09] <imbrandon> yea in its own window most of the time, its plugin based, e.g. just a framework for any player to use [11:10] <imbrandon> and sometimes full screen like a screensaver [11:10] <imwithbrandon> imwithbrandon: rdepends ? [11:10] <imwithbrandon> imbrandon: nice [11:10] <imbrandon> depends on how its implmented [11:10] <imwithbrandon> imbrandon: I will look at the rdepends to get a sample [11:10] <imbrandon> :) [11:10] <imbrandon> i know amarok,i think xmms , and i think some others [11:10] <LucidFox> I also uploaded the libraries to REVU, if this will help matters anyhow. http://revu.tauware.de/details.py?package=libhiglayout-java http://revu.tauware.de/details.py?package=libwoodstox-java [11:11] <imwithbrandon> norsetto: you're the one who teach me this one :) [11:11] <imwithbrandon> imbrandon: ah totem thing is based on it [11:12] <norsetto> imwithbrandon: I plead guilty [11:12] <imwithbrandon> imbrandon: is there a way to hook it on any data flow ? (to display nice thing from the wiimote motion for example ?) [11:13] <imbrandon> hrm , never thought about it, i'm sure it wqould be POSSIBLE [11:14] <imwithbrandon> imbrandon: I will keep that in mind the next time I get a wiimote next to me :) === imwithbrandon is now known as proppy [11:14] <imbrandon> yea lots of things depend on it, [11:14] <imbrandon> imbrandon@hood:~$ apt-rdepends -r libvisual-0.4-0|wc -l [11:14] <imbrandon> 139 [11:14] <proppy> yep [11:19] <imbrandon> any DD's awake :) /me needs a sid upload [11:21] <LucidFox> dholbach> replied in the bug thread === LucidFox is now known as LucidFox_away [11:22] <proppy> huats: seriously is there some python thing you want to talk ? [11:28] <proppy> yeepee someone is packaging fluxus === dholbach_ is now known as dholbach [11:54] <persia> As I'm backscroll-lazy today, is anyone waiting for a REVU? === _czessi is now known as Czessi [11:56] <proppy> hi persia [11:56] <imbrandon> heya persia , not that i have noticed in the last bit [11:56] <persia> hi proppy [11:57] <proppy> persia: finally I'm not going to japan (this year) [11:57] <persia> imbrandon: Thanks. I'll just chase old ones then :) [11:57] <persia> proppy: You're not? Why not? [11:57] <persia> Oh, right, I remember. This is a good thing :) Congrats! [11:59] <proppy> persia: thanks :) [12:00] <persia> Does anyone know if 4-clause BSD is DFSG-free? [12:00] <persia> (+ advertising) [12:10] <seb128> DktrKranz: hi [12:11] <DktrKranz> hi seb128 [12:11] <seb128> DktrKranz: any reason you didn't send the tora changes to Debian? [12:12] <DktrKranz> seb128, IIRC, it was already reported. Anyway, I'm checking [12:14] <DktrKranz> seb128, you're right... it was a different issue. I'll do it right now. thanks. [12:15] <seb128> DktrKranz: no problem, thank you for sending the change to Debian, so maybe next time we can sync directly ;-) [12:22] <frenchy> Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV. I'm still awaiting my first advocate. See http://revu.tauware.de/details.py?package=me-tv. [12:24] <frenchy> I've run out of things to do so I invite you to "let me have it". [12:26] <frenchy> persia: linda/lintian complete. No errors except for the menu file which has section="Applications/Viewers" which is now the new place for "Apps/Viewers". [12:26] <frenchy> persia: Apparently, the rules haven't caught up. [12:27] <persia> frenchy: Try the hardy lintian & linda. They understand. [12:27] <frenchy> persia: Will do, thanks. [12:28] <frenchy> persia: Obviously REVU is using the hardy ones because there are no errors/warnings on REVU. [12:29] <persia> frenchy: Yep. We try to reduce confusion :) [12:40] <ciphergoth> Just having a discussion in #ubuntu-devel, and asked a question which persia recommended I take here to get the right expertise: [12:40] <ciphergoth> Those of you who maintain both upstream and the Debian/Ubuntu package - what do you do in your source control? [12:40] <imbrandon> ciphergoth: what do you mean? [12:41] * persia looks at frenchy and StevenHarperUK as people currently working on that [12:41] <siretart> Riddell: because it provides a xine plugin for a new xine upstream version, which gets installed to a different directory [12:41] <ciphergoth> imbrandon: do you have one repository from which you build both the orig.tar.gz and the diff.gz? [12:42] <siretart> Riddell: it really needed manual changes to the source dependencies in order to get built against the correct (new) version of xine [12:42] <ciphergoth> or two repositories, one for the package and one for the Debian stuff? [12:42] <broonie> ciphergoth: A lot of that will depend on the particular VCS in use. [12:42] <siretart> I thought the changelog was declarative enough, obviously it wasn't.. [12:42] <ciphergoth> Is building the .orig.tar.gz and the diff.gz part of your build process? [12:42] <ciphergoth> broonie: darcs in our case [12:43] <broonie> I'd be surprised if there were many people building the orig.tar.gz by default; it's more trouble than it's worth to reproduce a bit for bit identical one. [12:43] <imbrandon> ciphergoth: if you mean keeping debian/ in RCS ? sure, but keep it seperate from the release tar [12:44] <imbrandon> ciphergoth: two branches is often enough [12:44] <Amaranth> right, just make sure your debian dir doesn't end up in your tarball and that should be enough [12:44] <broonie> ciphergoth: You might want to take a look at darcs-buildpackage [12:45] <imbrandon> ciphergoth: no one RCS branch holds the main code, the other holds debian/ , youy might peek at the way beryl/compiz* does it [12:45] <ciphergoth> my mistake - we use darcs for some stuff, but the package itself is just CVS. Currently we have one repository that contains both the main sources and the debian directory [12:46] <imbrandon> ciphergoth: then it would just be a simple matter of splitting that into two branches, so you can produce a orig.tar without the debian/ in ti [12:46] <imbrandon> s/ti/it [12:47] <ciphergoth> imbrandon - I'd be more inclined to produce the orig.tar.gz with a script that explicitly deleted the debian/ after checking out the sources [12:47] <imbrandon> ciphergoth: that would work too [12:47] <ciphergoth> maintaining branches in CVS is so painful [12:47] <Amaranth> imbrandon: not anymore :P [12:48] <Amaranth> imbrandon: distros do packaging, not upstream :) [12:48] <imbrandon> Amaranth: ahh well .... :) [12:48] <ciphergoth> Amaranth - we are upstream [12:48] <imbrandon> Amaranth: thats a good thing(tm) [12:48] <broonie> ciphergoth: There is cvs-buildpackage too. Dunno how it wants the repo but it's been well used [12:48] <imbrandon> ciphergoth: yea he was tlaking about my example of beryl/compiz* [12:48] <ciphergoth> imbrandon: ah, I see [12:49] <ciphergoth> we've written this package and packaged it for Debian/Ubuntu, and so we'd like to get it into Hardy Heron if poss [12:49] <imbrandon> they used to host debian/ too but now they just let the distros handle it [12:49] <ciphergoth> should we file a bug as usual, and just mention that we've done the technical work as far as we know? [12:49] <imbrandon> the most policticly correct way ( and better long term ) is to package it for debian and let it trickle down [12:50] <imbrandon> but you can also upload it to REVU for inclusion to ubuntu only atm [12:50] <ciphergoth> OK [12:50] <imbrandon> !REVU [12:50] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [12:51] <broonie> For Debian you can ask for package uploads to be sponsored on debian-mentors@lists.debian.org (or by finding a DD willing to do it otherwise) [12:51] <ciphergoth> I like the politically correct way, but we'll miss Hardy Heron that way won't we? It'll be a little while before our package hits unstable, and the Heron package list will be frozen soon, no? [12:51] <ciphergoth> We have a sponsor for the Debian side [12:51] <imbrandon> if it gets in unstable past NEW in debian soon , it will make it [12:51] <persia> ciphergoth: The cutoff requiring manual intervention is December 14th (to get through Debian NEW). [12:52] <imbrandon> if it gets close to the deadline you can always have a MOTU sponsor it via REVU [12:52] <ciphergoth> this is all amazingly helpful - thank you so much people [12:52] <imbrandon> we try to be :) [12:52] <persia> ciphergoth: You might also want to look at the pristine-source package, which is intended to generate a reliable orig.tar.gz from a VCS, although I don't know if it works with CVS or if it is useful for upstreams. [12:53] <frenchy> ciphergoth: Not sure what you mean. === LucidFox_away is now known as Sikon_Nausicaa [12:54] <frenchy> ciphergoth: Ohhh ... sorry I just caught up. [12:56] <ciphergoth> I take it we need to get as far as Debian sid before we can point at Debian as the upstream for Ubuntu? So if we hit Sid before the 14th, no need for REVU, but if not we should try and get it approved via REVU before then? [12:57] <imbrandon> yea [12:57] <imbrandon> exactly [12:58] <imbrandon> REVU can noramly be pushed in as little as 48 hours if everything falls into place, so if its not going to look like it will hit SID before say dec 10th you might start looking at MOTU review via REVU [12:58] <imbrandon> but untill then i would push to get it in debian [13:00] <persia> ciphergoth: If you're really close to NEW, there's also a manual process to sync if you miss the 14th, but there needs to be a good reason (like: your software is really cool and integrates perfectly) [13:00] <Riddell> siretart: ok, accepted [13:01] <imbrandon> heya Riddell :) [13:01] <siretart> Riddell: thanks! [13:02] <geser> StevenK: do you mind if I merge libglade? === ogra1 is now known as ogra [13:03] <StevenK> geser: Not particularly [13:06] <Riddell> hi imbrandon === ScottK2 is now known as ScottK === cprov is now known as cprov-lunch [13:28] <effie_jayx> One question [13:29] <persia> effie_jayx: Just ask [13:33] <effie_jayx> I updated my pbuilder to hardy... is that all I need for packaging stuff for hardy?, I remember downloading some script before... [13:34] <persia> That's all you need. You might want to grab lintian and linda from backports (or maybe even linda from hardy if the backport isn't complete yet). [13:39] <dholbach> frenchy: checking out me-tv [13:42] <persia> frenchy: me-tv commented [13:42] <persia> dholbach: I'm sure you'll catch more, but you might want to refresh so as not to dup too much :) [13:43] <dholbach> persia: thanks [13:43] * persia goes on to xca, unless anyone has any requests [13:46] * dholbach hugs persia [13:46] * persia peers about suspiciously, claiming innocence [13:46] <dholbach> can we use a fixed font in REVU comments? [13:46] <siretart> dholbach: sure [13:46] <dholbach> that'd be great :) [13:47] * dholbach hugs siretart [13:47] <siretart> hm. only where to set that? [13:47] <persia> siretart: You'd want to do it in the CSS, and set a class for the comment boxes [13:48] <ScottK> dholbach: Why do you want fixed fonts? [13:48] <siretart> persia: puh, I don't really have a clue about css. if someone could send me a patch to the existing css, I'd gladly commit it [13:48] <\sh> did I say that I hate php projects like tikiwiki? ,-) [13:48] <dholbach> ScottK: sometime I paste something from the commandline and it'd look better with fixed fonts [13:48] <dholbach> look at the last comment on the me-tv package [13:49] <geser> \sh: php projects in general or only those with open CVEs? [13:49] <persia> siretart: I'd be happy to prep a CSS patch (assuming I can remember the syntax), but I'll need the name of the class you're planning to apply for comments. [13:49] <\sh> siretart, <span class="comments"> blabla </span> and the css for comments is: comments { font-family: Courier } [13:49] <\sh> geser, those projects who are not fixing bugs and documenting it properly [13:49] <ScottK> \sh: Is everyone going to have that font installed? [13:49] * persia thinks \sh already provided everything required [13:50] <\sh> ScottK, I think Courier is a standard font-family, which matches as well monospace or something like that [13:50] <\sh> ScottK, but to be sure, please ask a expert for css rules ,-) [13:51] * persia checks the spec [13:51] <soren> \sh: "font-family: monospace" is much better. [13:51] <soren> \sh: It's the one from the css2 spec. [13:51] <persia> Should be "font-family: monospace" [13:51] <\sh> siretart, s/Courier/monospace/ [13:51] <\sh> thx soren :) [13:51] <\sh> thx persia [13:52] <frenchy> dholbach: persia: Thanks muchly. persia, are you emmet? [13:52] <persia> frenchy: Yes. Has my client eaten my /whois again? [13:52] <siretart> \sh: ok. but only where in the revu code? :) [13:53] <frenchy> persia: I'm new to IRC. [13:53] <\sh> siretart, where you print the comments :) [13:53] <persia> frenchy: No worries. it's just that about a month ago I was named "purple" on one network and "nobody" on another, for reasons I don't understand. [13:54] <siretart> \sh: somewhere in http://codebrowse.launchpad.net/~revu-hackers/revu/trunk/annotate/ajmitch%40ubuntu.com-20071113114707-9fcge2nn3arawg93?file_id=details.py-20060622101805-5b61dbbdd21644df, probably [13:54] <\sh> siretart, so something like print STDOUT "<span class=\"comments\">"+dbfield->comments+"</span>" and add the css stuff to your css file...or <span style="font-family: monospace">comments<span> === apachelogger_ is now known as apachelogger [13:55] <\sh> siretart, in <table> [13:55] <\sh> 88 <tr> <th>Date</th><th>Reviewer</th><th>Comment</th> <th>Advocating</th><th>Actions</th></tr> [13:55] <\sh> 89 %s [13:55] <\sh> 90 </table> [13:55] <\sh> 91 132.1.2 """ % (comments)) [13:56] <\sh> siretart, oh you add the <tr> stuff to (comments) [13:56] <\sh> siretart, I think then in getcomments method [13:56] <siretart> \sh: indeed [13:57] <frenchy> dholbach: A question about "No download files exist for this project." at URL you specified". Are you referring to the watch file. [13:57] <frenchy> ? [13:57] <siretart> \sh: let's try that with span and the css [13:57] <\sh> siretart, in getcomments function then... [13:57] <dholbach> frenchy: I clicked on the link in the debian/copyright file === Sikon_Nausicaa is now known as LucidFox [14:00] <frenchy> dholbach: I just removed the download files form the project site yesterday because people can get hem from the PPA now. What If I told you that it was downloaded from there ... then removed .. yes ... I am a smart-ass. [14:00] <\sh> oh I hate tikiwiki....this is so evil..why don't they add the CVE number for their sec fixes [14:00] <dholbach> ah ok [14:00] <ScottK> frenchy: If I was reviewing your package I'd not advocate it based on the source is missing. [14:02] <frenchy> ScottK: sorry, I don't understand. [14:03] <ScottK> Well if you put in Debian copyright that the source was gotten from a location and it's not there, how can I tell if I've got the correct upstream tarball or not? [14:03] <frenchy> ScottK: Ohhhh ... the doanload source. [14:03] <frenchy> ScottK: Yep, yep, yep ... Sorry it's 01:02 here. [14:03] <ScottK> No problem. [14:04] <frenchy> Do I need a man page for a GTK app anyway? [14:04] <frenchy> I actually have GNOME help. [14:04] <ScottK> That doesn't obviate the man page requirement. [14:05] <frenchy> ScottK: Is there a requirement for a man page? [14:05] <ScottK> frenchy: Generally Linitian will complain at you if it's needed. [14:06] * ScottK is still waking up, so I don't recall the exact rule. [14:08] <persia> There's not a requirement, but almost no REVU reviewers will advocate without one. If nothing else, it's a good way to get into the whatis and apropos databases. [14:10] <frenchy> Can I use my PPA as a download location? [14:10] <persia> frenchy: No. You need to have an upstream tar.gz. This is important to 1) allow other distributions to package the software, and 2) allow paranoid users to download the official original sources. [14:11] <persia> (that's what the /+downloads area is designed for: use it and enjoy) [14:13] * persia solicits nominations for the final review in this session [14:13] <frenchy> persia: But the PPA has that. [14:14] <frenchy> persia: I mean orig.tar.gz is the upstream right? [14:14] <persia> frenchy: No, the PPA has an orig.tar.gz that the PPA owner claims is the official version. [14:14] <frenchy> persia: ok ... yeah ... [14:14] <siretart> voilà! comments monospaced now! [14:14] <persia> frenchy: Technically, you're right. Further, in practice you're right. Even more, because you're the same person, you're right. On the other hand, the policy is there to cover the cases where this might not be true. [14:15] <frenchy> persia: Exactly the argument I was about to make. But ok ... rules is rules ... I'll just put the files back. [14:16] <frenchy> persia: Atleast that'll ge thte watch file working again. [14:16] <ScottK> dholbach: Are you keeping the list if MOTU Launchpad bugs now? [14:16] <persia> frenchy: Thanks. Sorry for the confusion, but the policy isn't really designed for upstreams packaging their own software :) [14:16] <persia> There is an official list? How should I submit my bugs there. [14:16] <persia> Also, isn't LaserRock still the LP liaison? [14:17] <dholbach> ScottK: no [14:17] <ScottK> dholbach: OK. [14:17] <ScottK> persia: I think you're right. I guess he still does it. [14:18] <ScottK> LaserRock: I think Bug #157064 is already on your list. It just got pushed from 1.1.11 to 1.2.1. It's a regression for goodness sake. I really wish LP developers would quit breaking stuff by accident. [14:18] <ubotu> Launchpad bug 157064 in soyuz "New release renders publishing history page unuseable" [Medium,Confirmed] https://launchpad.net/bugs/157064 [14:18] <frenchy> persia: Yeah, it seems strange to me that Canonical has put so much effort into LP to make it easy for people to develop for Ubuntu but there aren't a lot of developer/maintainers around. [14:18] <frenchy> persia: Ubuntu is new I guess. [14:19] <frenchy> persia: newish. [14:19] <ScottK> Personally, I see them putting a lot of effort into stuff that actually makes it harder, but that's just me. [14:19] <persia> frenchy: New, but also LP makes it easy to develop free software, and to develop Ubuntu. I don't think there is any special effort to develop free software on Ubuntu (although now that PPAs are released, this is less strictly true). [14:20] <dholbach> does somebody know if there was a 'motu' tag or something for those bugs? [14:20] <persia> dholbach: There's not a "motu" tag on most of the motu-interesting bugs to which I'm subscribed. [14:20] <frenchy> persia: Honestly, do you think that I'm doing this the wrong way around. Should I focus on developing a "kick-ass" application, gain popularity then let one of the pros package it? [14:20] <ScottK> dholbach: I think there was a tag, but I don't recall what it was. [14:20] <dholbach> hm ok [14:21] <frenchy> persia: Exactly what I was referring to .. someone pointed that out to me only today ... that LP is becoming great for developing for Ubuntu. [14:21] <persia> frenchy: Doesn't really matter. I'd focus on developing a "kick-ass" application, but it doesn't hurt to take a short detour to package it, and then just push it into the archives when you have a new release. if the application is interesting enough, a team may adopt it. [14:22] <geser> dholbach: https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=motu [14:22] <dholbach> "karma for uploads!" [14:22] <frenchy> persia: But I doubt that I'm going to get it done for hardy. It hasn't been a waste though ... now that it's packaged properly, I'm able to use the PPA and distribute the application that way. It's great. [14:22] <persia> There used to be karma for uploads, then it went away. Is it coming back? [14:23] <siretart> \sh: thanks for the hint with the css, applied and pushed to bzr [14:23] <persia> frenchy: You're really close. There's only a couple little things (other than the missing download link). [14:23] <dholbach> persia: I'm not sure there ever was [14:23] <\sh> siretart, cool :) [14:24] <persia> dholbach: back in Dapper I used to get a karma bump for uploads (and used to care enough to watch for that). [14:24] <dholbach> I can't remember that [14:25] <persia> It was right before the infinite karma issue began :) [14:25] <frenchy> persia: Thanks for the encouragement but I still then have to get someone to advocate it. I imagine that on;y people with a DVB card that use GNOME are going to be interested. [14:25] <frenchy> persia: Sorry, 2 people to advocate it. [14:25] <persia> frenchy: There are quite a few: once the packaging is clean, ping the mythbuntu team, who probably have a set of DVB testers somewhere. [14:27] <persia> If the app is good, and useful, they'll likely be happy to advocate it. [14:27] <ian_brasil> hey...i submitted a package to revu (mobileguide)...if someone has time i would really appreciate some feedback on it...thx [14:28] <frenchy> persia: Hmmm ... ok ... I'll bash it out tonight. [14:29] <persia> frenchy: Thanks [14:31] <frenchy> Ohh ... with the exception of the man page. That'll take time. [14:31] <frenchy> We've used the groff standard. [14:31] <\sh> finally, tikiwiki in gutsy fixed [14:33] <proppy> persia: do you know how to show the panel for asia langage input, I can't get my hands on it [14:36] <persia> proppy: Install SCIM, select a SCIM input method, and away you go. [14:37] <norsetto> proppy: 素晴らしい食事を有したか。 [14:37] <norsetto> proppy: does it make any sense :-) ? [14:38] <proppy> norsetto: I don't know kanji yet :) [14:38] <proppy> persia: thanks It was already installed I was just not remembering the command to launch :) [14:38] <geser> norsetto: ツ [14:39] <frenchy> persia: "No upstream changelog is installled in the package" ... There's a ChangeLog (I believe this to be the standard) in the top. [14:39] <norsetto> geser: ok, that looks like an y, so it must be "yes".... [14:39] <frenchy> persia: Did I mess something? [14:39] <frenchy> s/mess/miss/ [14:39] <frenchy> Actually, scratch that ... I like mess. [14:39] <geser> norsetto: more like a :) [14:40] <norsetto> geser: lol [14:40] <persia> このチャネルで英語だけお願いします [14:40] <norsetto> Just English we ask with this channel :-) [14:40] <persia> frenchy: It's not getting caught by dh_changelogs, and is not appearing in the binary packages. [14:41] <frenchy> persia: Oh ... I must have to add it as an EXTRA_DIST I think. [14:41] <frenchy> persia: Makefile.am [14:42] <persia> frenchy: No, it's a packaging thing. As upstream, you've done it perfectly. As the packager, you're just not installing the upstream file. [14:42] <geser> can we get a list similar to http://qa.ubuntuwire.com/ftbfs also for builds in DEPWAIT state? [14:43] <effie_jayx> ok.. I just devored the wiki and I need more info on lintian and linda... I know they are "static checkers, meaning they check the package without running any files, which is fast and secure" quoting a talk... but any use examples ? [14:43] <norsetto> persia: is it normal practice to upload new upstream versions every 5 days? [14:44] <geser> effie_jayx: linda package.dsc or lintian package.dsc [14:44] <persia> geser: That's a great idea. Are you up for porting the code, or do you need a hand? [14:44] <geser> effie_jayx: or on the binary .changes file if you've build the package [14:44] <persia> norsetto: Depends how closely upstream takes "release early, release often" to heart :) [14:45] <geser> persia: where can I see the code for it? [14:45] <persia> geser: http://people.ubuntuwire.com/~dktrkranz/ftbfs/ftbfs.py [14:46] <persia> dktrkranz: Please add a source link on the ftbfs page [14:47] <\sh> dholbach, from whom do we sync tikiwiki, if not from debian? [14:47] <frenchy> persia: I don't have a dh_changelogs installed and googling bought back 2 results. [14:48] <persia> frenchy: That's because I'm an idiot. "dh_installchangelogs" [14:48] <frenchy> persia: Sorry, Der ... I should've seen that. [14:48] <jdong> Amaranth / ScottK: I think there's a fundamental difference with Envy in that the author genuinely has Ubuntu's best interests in mind and takes in our advice without any resistance... [14:49] <dholbach> \sh: no idea - was it removed from debian? [14:49] <dholbach> *shrug* [14:49] <jdong> and what Envy tries to do is inherently prone to breakage to begin with, and probably isn't much safer if done by hand [14:49] <ScottK> OK. [14:49] <persia> Did Envy get on the "evil scripts" list? Why? [14:49] <effie_jayx> geser, thanks ... do I have to install linda and linthia... are they parto of some dev package? [14:49] <persia> effie_jayx: They are package names [14:49] <\sh> dholbach, looks like that...it's not findable via p.d.o [14:50] <geser> effie_jayx: linda and lintian are packages of their own [14:50] <\sh> dholbach, I'm just asking on debian-security [14:50] <persia> \sh: Ask p.qa.d.o, which also lists removed pacakges [14:50] <effie_jayx> ok [14:50] <jdong> persia: apparently it did.... [14:50] <jdong> !envy [14:50] <ubotu> envy is not needed or supported. Use the Resticted Manager to install binary drivers and see « /msg ubotu binarydriver » [14:51] <persia> jdong: I'd argue that's the appropriate response for ubotu, but am just surprised, as Envy seems to be as clean as is possible for what it does. On the other hand, it is completely unsupportable. [14:51] <geser> \sh: Debian bug #427655 [14:51] <ubotu> Debian bug 427655 in ftp.debian.org "RM: tikiwiki -- RoM, license issues, bad security history" [Normal,Open] http://bugs.debian.org/427655 [14:51] <jdong> persia: the old factoid was much harsher [14:51] * persia encourages the filing of a removal bug [14:51] <jdong> persia: but yeah, I agree with your evaluation -- it does what it does "the right way" but what it tries to do is inherently unsupportable [14:52] <\sh> geser, yeah...just reading the followeup [14:54] <\sh> damn [14:54] <\sh> work done for nothing [14:54] * jdong looks at the motumedia PPA build of mpeg4ip and wonders why it's been building for 24 hours [14:54] <soren> jdong: Stuff takes time :) [14:54] <jdong> util/testnasm.sh: line 8: test: =: unary operator expected [14:54] <jdong> uh oh bashismville [14:55] <jdong> what's our policy on disabling test suites? ;-) [14:55] <soren> jdong: Just make it use bash if that's the problem? [14:55] <jdong> it's rather unpleasant to have to run a 23 hour test suite on a 5 minute build. [14:56] <jdong> soren: yeah definitely will do [14:56] <soren> jdong: Look like an infinite loop to me.. [14:56] <jdong> soren: yeah, is there any way to interrupt the build? [14:56] <persia> jdong: Ask a buildd admin very nicely? [14:56] <soren> jdong: Ask in #launchpad [14:56] <jdong> I feel bad for plugging up an entire PPA builder for a day [14:58] <frenchy> persia: So I can't call it orig.tar.gz even on the download site? Is that what you mean? I have to manually rename it? [15:00] <persia> frenchy: It's best practice. Distributions that don't use debian-style packaging don't use orig.tar.gz. The rename is easy, and uscan will do it automatically if your watch file works. [15:01] <\sh> persia, please add +1 to bug #165187 [15:01] <ubotu> Launchpad bug 165187 in tikiwiki "Please remove tikiwiki from ubuntu archives" [Undecided,New] https://launchpad.net/bugs/165187 [15:01] <\sh> thx :) [15:01] * persia was waiting for ubotu to tell #ubuntu-bugs [15:03] <\sh> oh wow...jamendo has really good music [15:10] <persia> OK. REVU backlog down to 1 month. [15:13] <bddebian> Heya gang [15:13] * persia passes the reviewing torch to bddebian, and wanders off for a bit [15:13] <bddebian> Doh, hi persia [15:14] <persia> bddebian: Hey. Did you ever get scorched3d sorted, or do you still need someone to look at the 64-bit stuff? [15:14] <bddebian> persia: I'm not sure where Fuddl is at, I'll ask, thanks [15:15] <persia> Also, there's a darkplaces on REVU that looked interesting: still needs some work, but maybe worth watching. [15:15] <persia> bddebian: OK. I somehow passed that in my queue, so you've a priority bump if it's still not sorted :) [15:17] <frenchy> persia: Re: license missing in Glade file. The license is definitely in the about dialog. [15:17] <bddebian> persia: heh, OK [15:17] <frenchy> persia: Not sure that you mean. [15:18] <persia> frenchy: Right, the license for the program is displayed, but the glade source itself doesn't have a license header as an XML comment (I'm a stickler for these things: they may not matter to everyone). [15:19] <norsetto> I didn't know Linda had a sense of humour: http://revu.tauware.de/revu1-incoming/easycrypt-0711251540/linda [15:20] <persia> norsetto: You just have to catch her on the right day [15:20] <norsetto> persia: yes, pretty funky [15:20] <persia> Also, isn't that already in the archives? I don't understand why it appears in that section. [15:21] <frenchy> persia: And I like a stickler. Sorry, but I've been googling and dl'ing packages ... none of which have lead me to a find on how to do this. Do I just do it as a massive comment block? The issue is .. will glade clobber it? [15:21] <norsetto> persia: well, talking about uploading new upstreams every 5 days .... [15:21] <persia> frenchy: Yes, a massive comment block would keep me from saying anything. I don't know if glade preserves comments. [15:22] <persia> norsetto: There's an interdiff for that version that went through the queue recently as well. [15:22] <norsetto> persia: yes, one day after I uploaded the previous version [15:22] <persia> norsetto: No, .12 was one day after you uploaded the previous version :) The interdiff was for .15. Which version is up now? [15:23] <norsetto> persia: oh $deity, I lost the count [15:23] <persia> heh [15:24] <frenchy> persia: I'll do that then. I haven't touched development in weeks anyway. [15:25] <persia> frenchy: Thanks. Here's hoping you'll have no more Ubuntu-related excuse to defer development soon :) [15:26] <bddebian> heh [15:27] <geser> Hi bddebian === cprov-lunch is now known as cprov [15:31] <bddebian> Heya geser [15:47] * persia grumbles at `baz`, claiming that metasyntactic variables make poor command names. [15:50] <AuntyProton> Is this the place to ask for a package update? [15:50] <persia> AuntyProton: Only if you're proposing to do the work, and need some help [15:50] <dholbach> AuntyProton: best to file a bug on the package and tag it as 'upgrade' [15:50] <dholbach> .... or ask for help to do it yourself :-) [15:50] * dholbach hugs persia [15:51] <AuntyProton> <-- recoils in shock. [15:51] <AuntyProton> I'm not a programmer, I'm a science-fiction writer. [15:51] <persia> AuntyProton: Why in shock? A package update isn't too hard, and we're more than happy to help: we're just usually busy, and have a hard time getting to everything. [15:51] <dholbach> that'll give your share of science-fiction for the day :-) [15:52] <persia> AuntyProton: An update doesn't usually involve programming: it's mostly testing to make sure that the packaging for the old version still works with the new version. If you're an active user, and have a technical mind, you're all set. [15:52] <AuntyProton> I e-mailed the programmers of the package in question and they said they're not in charge of when their packages get updated. [15:52] <dholbach> persia is right, package upgrades are straight-forward in most cases [15:53] <persia> AuntyProton: On the other hand, if you're also busy, we understand. In that case, your best bet is to file a bug, and add the "upgrade" tag, as dholbach suggested. [15:53] <AuntyProton> Wait, you guys may not have understood. The programmers are currently distributing their newest version, but for some reason it's not on the Synaptic or Add/Remove lists. [15:53] <persia> The package is missing entirely, or an old version appears in Synaptic? [15:54] <AuntyProton> The old version is still in Synaptic and Add/Remove. [15:54] <persia> Ah. Which package? [15:54] <AuntyProton> Zim. It's a desktop wiki package. [15:54] <RainCT> Hi [15:55] <persia> We're planning on shipping 0.20 in hardy, but zim is likely one of our least well-maintained packages: I'm surprised it works for anyone at all. [15:55] * persia was looking at the bug reports last week [15:55] <AuntyProton> Hmm.... well, I use it. And the bug I found isn't life-threatening, just annoying. [15:56] <persia> AuntyProton: And it's fixed in 0.20? [15:56] <AuntyProton> Yeah. Or so the programmers claim. [15:56] <RainCT> what should I do if a tarball has capital letter in the name of the directory inside it? (dh_make complains about this) [15:57] <persia> AuntyProton: In that case, the best thing to do is either wait for hardy, or file a backports request. Given the poor maintenance record, I think someone needs to test and clean up the old bug reports before we can do a backport. [15:57] <AuntyProton> Okay, I can wait. Just wanted you guys to know there was a problem. [15:58] <persia> AuntyProton: Looking briefly at the package, I believe it should compile cleanly on gutsy: I just think we need to clean it up a bit before it gets a backport. Would you mind filing a bug from https://launchpad.net/gutsy-backports/+filebug, and subscribing me (LP name is "persia")? [15:59] * persia was planning to look at zim anyway, but this will be an incentive [15:59] <persia> Ah. I'm slow, as usual. Too bad. [16:03] <persia> RainCT: untar it, move the directory to the preferred "packagename-version" format (all lowercase), do your packaging (do you really want dh_make? It's just 4 files). Then when you build your package, the tools will be smart enough to ignore the capital letters in the upstream tarball. [16:04] <RainCT> persia: great, thanks [16:05] <persia> dholbach: Is there by any chance a more general documentation link? I'd like to encourage people to read packaging stuff, but also process & policy stuff. [16:06] <dholbach> process + policy stuff is http://wiki.ubuntu.com/UbuntuDevelopment [16:06] <dholbach> everything necessary should be linked from there [16:06] <persia> Right. MOTU/Documentation used to have a mix. Maybe we need two links. I'll go look at MOTU/Contributing again. [16:07] <dholbach> the packaging guide had its own list of documentation resources in the appendix [16:07] <persia> dholbach: Nevermind. The new list is incredibly nice, clean, and comprehensive. Beautiful work! [16:07] <dholbach> i just merged the two [16:08] <dholbach> and [[Include(...)]] it in the packaging guide [16:10] <frenchy> Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV. I'm still awaiting my first advocate. See http://revu.tauware.de/details.py?package=me-tv [16:12] <persia> dholbach: What do you have against inline patches? (not that I don't agree that those belonged upstream) [16:12] <frenchy> persia: Thanks for all your help. I look forward to hearing your comments. [16:12] <frenchy> dholbach: Sorry, my thanks to you to. I think that you raised some very good points. [16:13] <frenchy> dholbach: The diff is now pretty clean. === \sh is now known as \sh_away [16:13] <dholbach> I personally think it's cleaner and patches are easier to drop, etc - but that's the decision of each and every maintainer [16:13] <dholbach> persia: sorry ^ [16:14] <dholbach> persia: so I don't have anything against them, I just prefer to have them in a patch system - if somebody is convinced to have them inline, that's ok with me [16:14] <persia> dholbach: Ah. Makes sense. Just seeing your other comment I thought you had a negative view of one, as opposed to a positive preference for the other. No worries. [16:15] <dholbach> sorry, I should have put this more positively [16:15] <dholbach> frenchy: anytime :) [16:16] <frenchy> Gotta go to work in a few hours so ... goodnight ... french, out. [16:17] <dholbach> frenchy: take care [16:17] <persia> frenchy: Minor point (and not enough to reject): dh_installman is handy for pushing your manpages in the right place. I can't test, so I won't advocate. Nice job. [16:19] <frenchy> persia: got it. Bed, now, sleep. [16:19] <nxvl_work> persia: did you remember the FTBFS wich i was fixing yesterday? [16:20] <nxvl_work> persia: i've e-mail the DM and he said that he will fix this on next release, should i fix it anyway or wait? [16:24] <persia> nxvl_work: Your call. Generally I tend to push an Ubuntu upload if the package appears in one of the NBS lists, or I just feel like it (e.g. I use the package and am annoyed by it being broken, or I am supporting someone specifically). If there's no good reason to do Ubuntu faster, waiting for Debian is OK, but if that doesn't happen by 14th December, best to upload to Ubuntu anyway. [16:25] <nxvl_work> persia: so, wait until it's released, but on 14 December if it isn't, patch it? [16:26] <persia> nxvl_work: Unless it appears in the NBS lists, or there's another good reason to upload sooner, yes. [16:27] <nxvl_work> !NBS [16:27] <ubotu> Sorry, I don't know anything about nbs - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [16:27] <persia> nxvl_work: http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:27] <imbrandon> nxvl_work: the link os on http://qa.ubuntuwire.com [16:27] <imbrandon> s/os/is [16:28] <persia> ubotu: NBS is Some packages are no longer built from source as a result of various transitions. The reverse dependencies of these packages require an update. The current tracking list is available from http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:28] <nxvl_work> it isn't there, so lets wait, moving to next FTBFS [16:29] <persia> nxvl_work: By "isn't there", do you mean, "Doesn't appear in the directory listing" or do you mean "doesn't appear in any of the files"? [16:29] <nxvl_work> doesn't apear on http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:30] <persia> nxvl_work: That's just the list of package. Click on the links where the size > 0 to get a list of the packages that should be updated sooner. [16:30] <persia> Err.. The list of packages no longer built from source. [16:31] <Pici> !nbs [16:31] <ubotu> Some packages are no longer built from source as a result of various transitions. The reverse dependencies of these packages require an update. The current tracking list is available from http://people.ubuntu.com/~ubuntu-archive/NBS/ [16:31] <persia> Pici: Thank you [16:31] <Pici> persia: no problem :) [16:31] <nxvl_work> persia: oh! that list show the packages doesn't build because of other packages? [16:32] <persia> nxvl_work: Sort of. That list shows the packages that won't exist soon, and for each, there is a list of packages that need to be updated so they won't break when the NBS packages are removed. [16:35] <persia> nxvl_work: As an example, there's been a transition of the libxmp library, so some packages need to be rebuilt or ported to the new API. The list of affected packages is available from http://people.ubuntu.com/~ubuntu-archive/NBS/libxmp2 [16:35] <nxvl_work> oh! ok ok [16:35] <nxvl_work> :D === cassidy_ is now known as cassidy === cassidy_ is now known as cassidy [16:57] <nxvl_work> why is there some packages on http://qa.ubuntuwire.com/ftbfs/#universe which i can't find on packages.ubuntu.com?? === rquinones is now known as xzased [17:02] <xzased> hiya all [17:02] <xzased> anybody knows how to unblock video ports? [17:04] <jpatrick> xzased: support in #ubuntu [17:05] <xzased> woops === asac_ is now known as asac [17:16] <LucidFox> What is the xine-lib transition mentioned in Bug #159338? [17:16] <ubotu> Launchpad bug 159338 in oxine "Re: Heads-up: small xine-lib transition in hardy" [Undecided,In progress] https://launchpad.net/bugs/159338 [17:20] <persia> LucidFox: https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002617.html [17:24] <LucidFox> If a package doesn't explicitly depend on libxine1, will rebuilding it fix the problem? [17:26] <persia> LucidFox: It's not a rebuild issue, it's that packages need to explicity depend on a front-end package, or they won't get one. [17:27] <persia> (well, it's a rebuild too, but that's not the important bit) [17:28] <LucidFox> Ah. [17:37] <nxvl_work> does install accepts list arguments like {item1,item2}? [17:40] <gpocentek> nxvl_work: {item1,item2} is a bashism if I'm not wrong [17:41] <nxvl_work> gpocentek: so it won't? [17:42] <gpocentek> nxvl_work: install can use this, but if you use it for a package, the build will fail [17:43] <nxvl_work> so instead of it i need to use a for [17:43] <gpocentek> I think so [17:44] <persia> nxvl_work: Which are you trying to do? There's a few make constructions which integrate batter in debian/rules than a for statement [17:46] <nxvl_work> persia: cereal, on the Makefile [17:46] * persia points at sections 4.5, 8.5, and 6 of the make manual for reference [17:46] <persia> nxvl_work: More context please [17:46] <nxvl_work> persia: on cereal package [17:47] <cprov> ScottK: ping, wonna talk about bug #157064 ? [17:47] <ubotu> Launchpad bug 157064 in soyuz "New release renders publishing history page unuseable" [Medium,Confirmed] https://launchpad.net/bugs/157064 [17:47] <nxvl_work> on it's Makefile it says "install fs/usr/share/cereal/{log,main}run $(PREFIX)/share/cereal/" [17:47] <ScottK> Yes? [17:47] <ScottK> cprov: ? [17:47] <nxvl_work> and the build error is that it doesn't fin file "}fs/usr/share/cereal/{log,main}run" [17:48] <ScottK> cprov: I'll discuss it if needed, but I just want it back like it was. [17:48] <geser> nxvl_work: looks like bashism [17:48] * ScottK isn't sure what's unclear about that. [17:48] <nxvl_work> so i think it's because isn't accepting the {} list format [17:48] <nxvl_work> geser: yep, it looks like it for me too [17:48] <persia> nxvl_work: Ah. If it's that small, it's probably best to just make it two lines, rather than either a for statement or nifty make recursion [17:48] <cprov> ScottK: it's impossible to revert the layout change and continue to present removal details. [17:49] <ScottK> Did someone ask for removal details? [17:49] <cprov> ScottK: so, you have to describe what you are missing from the table layout. [17:50] <ScottK> cprov: What I'm missing is the ability to figure out if a second or two what relates to what release. [17:50] <cprov> ScottK: distro-team, otherwise they can't track package deletions. [17:50] <ScottK> cprov: It takes an order of magnitude longer to orient and read through the narrative text. [17:50] <ScottK> cprov: Then why not just add another column to the table? [17:51] <persia> cprov: The issue is that it is long. I don't think +publishinghistory is bad, but if we could have another page with a quick table that listed all the published / superseded / removed entries, it would be a lot easier to check. [17:51] <cprov> ScottK: it's not just another column, at least more 3 and it will start scrolling horizontally [17:51] <ScottK> persia: The table already got pushed off the source package page. [17:51] * persia notes that it already scrolls horizontally for some screens [17:52] <cprov> persia: not in 1024x768, does it ? [17:52] <ScottK> cprov: OK. How about the old table at the top of the page and the new narrative flow underneath? [17:52] <persia> cprov: I don't have any devices at 1024x768, so I can't say [17:53] <ScottK> cprov: This is a sufficient barrier to work for me that I've decided not to volunteer for the revived motu-sru team because LP is too painful to use. [17:53] <ScottK> cprov: You may think I'm exaggerating, but I'm not. [17:53] <cprov> ScottK: sounds feasible, a short table as summary (version, series, status) each row linking to the corresponding noisy box below [17:53] <persia> cprov: That would be useful [17:53] <ScottK> cprov: Yes. All the stuff that was in the old table. [17:55] <cprov> ScottK: ta, comment the bug and I will arrange the things to get it fixed in 1.1.12 for you. [17:55] <persia> Does 1.1.12 mean December and 1.2.1 January (roughly)? [17:55] <ScottK> cprov: OK. [17:56] <cprov> persia: yes, 1.1.12 is the current milestone, that will be out around 20th Dec [17:56] <ScottK> cprov: Commented. [17:56] <cprov> ScottK: thanks [17:56] <persia> cprov: Thanks. [17:58] <ScottK> cprov: Next time could we arrange a) not to totally change pages on a release without publishing them to edge first and b) not wait until after a release to un-milestone something that isn't going to get fixed (I expected this fixed in 1.1.11 based on the bug status and had no chance to argue for it not getting dropped, so now I'm stuck for another month). [17:59] <cprov> ScottK: sure, i apologize for the mass-deferred bugs from soyuz 1.1.11, it shouldn't happen again. [18:00] <imbrandon> hrm [18:01] <cprov> ScottK: hopefully I can get this fix cherrypicked with other urgent UI fix. So, you can have it before xmas, take it easier. [18:01] <imbrandon> any python gurus got a sec or two to help me with some string manipulation [18:01] <ScottK> cprov: Thanks. [18:01] <ScottK> imbrandon: What is it? [18:02] <imbrandon> i'm wanting to strip a filename if it exists from a string ( url ) like blah.com/index.php would become blah.com/ [18:03] <imbrandon> i'm already stripping the http:// via [18:03] <imbrandon> url.content = url.content[7:len(url.content)] [18:03] <ScottK> If I was doing that, I'd split on '/' and take string[0] [18:04] <somerville32> Explode based on / and take the appropriate index? [18:04] <ScottK> Explode = split [18:04] <imbrandon> well some have paths too but i guess that would work [18:04] <imbrandon> and i could just cycle through them if they are not a file [18:04] <imbrandon> and rejoin [18:04] <ScottK> imbrandon: OK. Then split on '/' and take all but the last and put them back together. [18:05] <imbrandon> yup [18:05] <ScottK> Yeah. [18:05] <imbrandon> cool thanks, i'm a bit braindead sometimes [18:05] <ScottK> No problem. We all are. [18:05] <ScottK> It feels a lot better to help someone out than whine about LP. [18:06] * persia likes s/$.*$/[^/]*/\1/, but doubts it works in your program [18:09] <somerville32> find_user("persia")->terminate(); [18:13] <zul> hey [18:14] <RainCT> heh [18:21] <afflux> Can anyone please explain what "6. Package should not be native without an approved spec" in the "Guideline Criteria for New Package Inclusion" (https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage) means? Is it correct that a upstream package shouldn't contain any debian packaging? [18:23] <azeem> sort of [18:23] <azeem> however, you can just repack the upstream tarball to make it non-native, or (clunkier) still have it non-native, by just having the diff to the upstream debian packaging [18:26] <afflux> well, if I'm the upstream and I'm going to package my package for ubuntu, I'll need to have non-native upstream sources in the orig.tar.gz and my debian packaging seperated to them? [18:27] <ScottK> afflux: That's the best way to do it. [18:27] <ScottK> afflux: That's what I do where I'm also upstream. [18:28] <afflux> ScottK: hm, okay. [18:28] <afflux> ScottK, azeem: thanks for clarifying [18:28] <azeem> afflux: right, there's no need to include the debian/ directory in the upstream tarballs [18:29] <azeem> afflux: if you must, I suggest to call it otherwise, and advise your users to rename it to debian [18:29] <afflux> azeem: I guess that is quite useless when packaging for ubuntu ;) [18:29] <azeem> what is "that"? [18:30] <afflux> azeem: the renaming solution [18:30] <azeem> why? [18:30] <azeem> I'm saying if you *must* ship the debian/ directory in your upstream tarball for some reason (you really shouldn't), it's still better to ship it as "debian-upstream" or something [18:30] <azeem> not "debian" [18:31] <ScottK> azeem: I don't think that helps. [18:31] <azeem> why not? [18:31] <ScottK> That just doubles the size of the diff.gz. [18:31] <azeem> the Debian packaging would just ignore debian-upstream [18:31] <afflux> azeem: ah, didn't get the "must". But since that's not the case, i'll just split it. [18:32] <ScottK> azeem: You'd end up having to repack the tarball to remove it. [18:32] <azeem> remove what? [18:32] <ScottK> azeem: The not-a-debian dir. [18:32] <ScottK> You can't patch a file out completely. [18:32] <azeem> yeah, but you could just ignore it as well [18:32] <ScottK> azeem: That would be wrong. [18:32] <azeem> it's more of a PITA if it's actually called "debian" [18:32] <azeem> because then, you really cannot patch out files [18:33] <azeem> and you have to repack [18:36] <pochu> ScottK: why would it be wrong to ignore a 'debian-upstream/' dir in orig.tar.gz ? [18:37] <pochu> we repack to rename debian/ to debian-upstream/ when upstream package contains a debian/ dir, so I can't see why debian-upstream/ is bad for upstream. [18:37] <ScottK> Personally, I think it'd be wrong to ship a directory of stuff that is like debian packaging, but not what's used. [18:37] <ScottK> pochu: Where is renaming debian-upstream documented? [18:37] <azeem> ScottK: I assume the "debian-upstream" is to be used by the users of the upstream package who desperately want and need to build .debs [18:38] <azeem> ScottK: though I agree that this shouldn't be needed [18:38] <azeem> but some upsreams seem to be very firm with this opinion [18:38] <pochu> Not documented, but it's done in wxwidgets. [18:38] <ScottK> pochu: Doesn't make it right. [18:38] <ScottK> azeem: What I do where I'm upstream is keep the Debian packaging in the VCS, but exclude it when I roll the tarball for a release. [18:39] <pochu> I agree it's better for upstream not to have a debian dir in the source tree at all, but if they are going to have one, better not to call it debian/ ... [18:39] <azeem> ScottK: sure, that's the right solution [18:39] <ScottK> Then I point to the VCS if someone really wants it. [18:40] <pochu> That makes sense. [18:40] <pochu> Or have it one dir above in the VCS. === x-spec-t is now known as Spec [18:46] <afflux> another question: Where I'm upstream, I have now two VCS branches: one called debian, containing *only* the debian packaging that is supposed to be distributed with ubuntu, and one called trunk, containing *only* my upstream sources. Now, should I point XS-Vcs-* to the debian or to the trunk branch? And should the debian branch contain the upstream sources too (so it's packaging + sources, not only packaging)? [18:47] <afflux> (checking for example cryptsetup looks like "debian" should contain packaging + sources, with Vcs-Bzr linking to "debian") [18:48] <azeem> for the latter, there's arguments towards both ways [18:48] <azeem> so it depends on your personal preference I guess [18:48] <azeem> (though maybe there is some Ubuntu policy I don't know of) [18:49] <ScottK> There's no specific policy, but mostly the spot where the debian dir can be found is referenced. [18:49] <pochu> afflux: Vcs-* should point to the "official" debian/ dir, not upstream's [18:50] <ScottK> pochu: For afflux since he's doing both, I think it's a distinction without difference. [18:52] <StevenHarperUK> in my debian/app.install I want to replace multiple lines like this > locale/en/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/en/LC_MESSAGES with 1 line like this > locale/*/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/*/LC_MESSAGES is it possible? [18:52] <pochu> ScottK: if it's for Debian I'd say it's ok, but if it's for Ubuntu, as it's team maintained, then having it in his project doesn't look like the best place? [18:53] <afflux> pochu, right. I'll drop the debian branch ;) [18:53] <pochu> (I'm not sure how bzr permissions work in launchpad for projects and teams though) [18:53] <ScottK> pochu: I disagree. The version in the repo is the real canonical source, but the VCS reference is fine. [18:56] <StevenHarperUK> persia: do you know ? ^^ see last post [19:11] <cprov> ScottK: hey, what about this page https://dogfood.launchpad.net/ubuntu/+source/dkim-milter/+publishinghistory [19:11] <ScottK> cprov: looking [19:12] <ScottK> cprov: The only thing that I think that lacks is if the version column has links to the appropriate page for that version. [19:13] <ScottK> cprov: i.e.2.3.2.dfsg-1ubuntu1 links to https://dogfood.launchpad.net/ubuntu/hardy/+source/dkim-milter/2.3.2.dfsg-1ubuntu1 as it is below. === LaserRock is now known as LaserJock [19:13] <ScottK> persia and LaserJock: What do you think ^^^ [19:14] <cprov> ScottK: it's in the corresponding 'detailed' section, but I can easily add the link in the table too. [19:14] <ScottK> cprov: I noticed that, but that's usually where I would go off that page and so it's very good to have it one click away and not two. [19:15] <cprov> ScottK: the point is, maybe you prefer the hidden box below the row as we do in PPA page. [19:15] <ScottK> cprov: Do you have an example? [19:16] <cprov> ScottK: not yet, but check the navigation in any PPA page. The publishing details would be presented as we present the archive files for each published source in the PPA page. [19:16] <ScottK> cprov: OK. Give me a minute to look around for one. [19:17] <cprov> ScottK: by clicking in a arrow you could display/hide the 'publishing details' for each record/row === davro is now known as davromaniak [19:18] <LaserJock> ScottK: gotta read backlog [19:18] <ScottK> cprov: No. I prefer the link off of the table directly. Open the arrow and then click on where I want to go is still two clicks. [19:20] <cprov> ScottK: wait, consider the version-link done. What I asked is if you prefer the anchor to the 'detailed' section in the page (current solution) or the hidden-box mechanism used in PPA page. [19:21] <cprov> ScottK: the hidden boxex seems to be more appropriate, otherwise I have to add a link 'back to summary' on the end of each detailed section. [19:21] <LaserJock> cprov: hmm, shouldn't those Target links maybe go to /ubuntu/<release>/+source/<package> instead of just /ubuntu/<release> ? [19:22] <cprov> LaserJock: could be, like 'foobar in gutsy' and not only "gutsy", fine [19:22] <LaserJock> cprov: one of the hardest things for me to find are translations [19:23] <LaserJock> and I need to get to the /ubuntu/<release>/+source/<package> page [19:23] <LaserJock> it's not really very interesting to just link to the release itself, IMO, from a source package page [19:26] <cprov> LaserJock: right, I see you point. [19:27] <LaserJock> other than that I quite like that page [19:27] <ScottK> cprov: I see. [19:27] <ScottK> cprov: I can see advantages to the way you are proposing. [19:28] <ScottK> cprov: I'd ask the archive admin people that asked for the additional information as I expect it'd be more important to them. [19:28] <LaserJock> cprov: you sure we can't have that first table on the main source package page? :-) [19:29] <ScottK> LaserJock: I argued that and lost with sabdfl, so I suspect not. [19:29] <LaserJock> hehe [19:29] <LaserJock> cprov: oh, and with the release links, can we do the same for the main source page? [19:30] <cprov> LaserJock: give me a example [19:30] <LaserJock> it's kinda annoying to have to dig down into the version history to find a link to the /ubuntu/<release>/+source/<package> page [19:31] <LaserJock> in the "Published versions and upstream associations" table you list the release, but there's no links [19:31] <LaserJock> basically, no matter what else is on the main source page, I want to see links to specific versions and links to the release source page [19:32] <cprov> LaserJock: check the +publishinghistory page in dogfood again, links added [19:32] <LaserJock> cprov: great! [19:33] <cprov> LaserJock: now the question remains, anchors back and forth for detailed sections or hidden-boxes below the rows (as PPA page). [19:33] <Ubulette> hi [19:33] <Ubulette> persia, are you there ? [19:34] <LaserJock> cprov: k, let me pull up a PPA page [19:35] <ScottK> LaserJock: https://dogfood.launchpad.net/~cprov/+archive [19:36] <LaserJock> cprov: this is for the +publishinghistory? [19:37] <cprov> LaserJock: yes, I have the impression that if we use hidden-boxes we could easily compare multiple records in the table instead of clicking-around thing [19:38] <LaserJock> cprov: so is the anchors what you have now? [19:38] <cprov> LaserJock: yes [19:39] <LaserJock> cprov: and are you going to put in any more information? [19:40] <LaserJock> from what I see know I would think that the hidden-boxes would be better [19:40] <cprov> LaserJock: not really, I think we are done with the publishing-system redesign, removal information is already complete now [19:40] <LaserJock> much of the information in the complete history is already in the summary [19:41] <LaserJock> so just being able to drop down the box that you need for the additional details seems easier to me [19:41] <cprov> LaserJock: yup, we can cut some lines from the detailed section. [19:41] <cprov> LaserJock: exactly. [19:41] <cprov> ScottK: what do you think ? [19:41] <LaserJock> and I think it would, as you say, be easier to compare different version details, especially if they are far apart [19:42] <ScottK> cprov: I think the drop down is better, but as I said earlier I'd suggest asking the archive admins that asked for the removal information as that's the major piece of data that isn't displayed in the table to some degree. [19:43] <LaserJock> yeah, I agree [19:43] <LaserJock> I think the archive admins would be the main users of that data [19:43] <nxvl_work> i'm trying to dpatch a package, but i'm always getting: [19:43] <LaserJock> most devs will just look at the summary I think [19:43] <nxvl_work> dpatch deapply-all [19:43] <nxvl_work> 01_Makefile not applied to ./ . [19:43] <nxvl_work> on build [19:43] <cprov> ScottK: right, i will cook another prototype and come back in a bit. Thank you guys ! [19:44] <LaserJock> nxvl_work: did you add it to debian/patches/01list ? [19:44] <nxvl_work> LaserJock: yep [19:44] <LaserJock> nxvl_work: pastebin your rules? [19:45] <nxvl_work> http://pastebin.com/m7b7c79a [19:46] <nxvl_work> that is what i don't understand well [19:46] <nxvl_work> and i haven't find any clear documentation about [19:51] <LaserJock> nxvl_work: I don't see any dep on a patch rule [19:51] <nxvl_work> !? [19:51] <LaserJock> nxvl_work: and you're not actually building anything [19:52] <nxvl_work> mmm, i really don't understand well the debian/rules [19:52] <LaserJock> you're doing a make install [19:52] <LaserJock> but no make [19:52] <nxvl_work> i think that's why my mentor make me start with FTBFS [19:52] <LaserJock> :-) [19:52] <nxvl_work> oh ok [19:53] <nxvl_work> and a make, is done with dh_testdirs? [19:53] <LaserJock> ok, gimme a sec and I'll give you a bit cleaner debian/rules [19:53] <LaserJock> no [19:53] <LaserJock> it's done with ... make or $(MAKE) [19:54] <LaserJock> nxvl_work: this is a new package right, you're doing it from the beginning? [19:54] <nxvl_work> nop [19:54] <nxvl_work> i'm fixing a FTBFS [19:54] <LaserJock> ah [19:54] <LaserJock> ok [19:54] <geser> persia: I've a very first version of the list with packages in depwait ready: http://members.ping.de/~mb/depwait/out.html [19:54] <nxvl_work> but i think it have been uploaded not the right way [19:54] <LaserJock> so can you paste the original debian/rules? [19:54] <geser> persia: it's not running on the complete data set yet and the colouring needs improvement [19:54] <nxvl_work> is the very first version on ubuntu mirrors [19:55] <nxvl_work> let me look for them [19:55] <nxvl_work> LaserJock: https://edge.launchpad.net/ubuntu/hardy/+source/cereal/0.15-1 [19:56] <nxvl_work> LaserJock: this is the package [19:56] <nxvl_work> i'm downloading it again [19:56] <LaserJock> nxvl_work: you do need to keep a clean version of the current package around :-) [19:56] <LaserJock> when you go to do a debdiff to get it sponsored you'll want it [19:58] <LaserJock> PriceChild: ping [19:58] <nxvl_work> http://pastebin.com/m4299a76 [19:58] <nxvl_work> i will keep that in mind [19:58] <nxvl_work> :D [19:59] <LaserJock> nxvl_work: ok, so that's quite clean [19:59] <LaserJock> nxvl_work: so do you know why it is FTBFS [19:59] <LaserJock> ? [20:00] <nxvl_work> LaserJock: it shows me a message (from the makefile) with a bashism [20:00] <LaserJock> ah, ok [20:00] <proppy> hi [20:02] <LaserJock> nxvl_work: well, to be honest wth you, I don't think I would have used dpatch for this [20:02] <nxvl_work> why?= [20:02] <nxvl_work> isn't it the best practice? [20:02] <LaserJock> well [20:03] <LaserJock> you're only making, I'm guessing, a small change to the makefile [20:03] <LaserJock> and there is no existing patch system [20:03] <nxvl_work> yep [20:03] <nxvl_work> you are right [20:03] <LaserJock> in this case it's maybe just easier to not create a new patch system for this small thing [20:04] <nxvl_work> mmm maybe, but if make it so norsetto will be mad [20:04] <nxvl_work> :D [20:05] <LaserJock> nxvl_work: norsetto can talk to me about it ;-) [20:05] <nxvl_work> ok, then i will [20:05] <LaserJock> in general dpatch is a good way to go [20:05] <norsetto> mmm? [20:05] <nxvl_work> BUT [20:05] <LaserJock> especially if upstream is already using it [20:05] <nxvl_work> i prefer to use dpatch, so i can learn about it also [20:06] <LaserJock> the BUT here is that upstream is not using a patch system so you're creating a much larger difference between Ubuntu and Debian than you need to [20:06] <nxvl_work> heh [20:06] <LaserJock> ideally the change you are making now should go away [20:06] <norsetto> laserjock, nxvl_work: what are you two concocting? World revolution again? [20:06] <LaserJock> because the bashism should be reported to Debian and fixed [20:07] <nxvl_work> norsetto: nop, just patching a FTBFS [20:07] <LaserJock> and once that's done we could be able to drop the Ubuntu changes and sync again [20:07] <nxvl_work> mm [20:07] <nxvl_work> you are right [20:07] <nxvl_work> i will contact the DD [20:07] <LaserJock> so, the idea is you can fix it for now in Ubuntu, and report it to Debian [20:07] <nxvl_work> (this is my 5th FTBFS resolved without a line of code) [20:07] <cprov> LaserJock: ScottK: there we go, https://dogfood.launchpad.net/ubuntu/+source/dkim-milter/+publishinghistory & https://dogfood.launchpad.net/ubuntu/hardy/i386/dkim-filter [20:08] <norsetto> laserjock: what should we talk about? [20:09] <LaserJock> norsetto: nxvl_work was fixing a bashim causing a FTBFS. He was going to add in dpatch to the packaging to do it [20:09] <LaserJock> norsetto: I think that's a lot of delta for a minor change in a single file [20:10] <norsetto> laserjock: yes, on the other side sloppy habits are sloppy habits (even if it is the last cigarette). [20:10] <LaserJock> cprov: I like that [20:10] <nxvl_work> norsetto: and i was saying that if i don't use dpatch you will be mad [20:10] <ScottK> cprov: I like that, but I'll say again I'd run it by pitti at the very least. [20:10] <ScottK> cprov: One minor point I'm not sure about ... [20:10] <LaserJock> norsetto: hmm? [20:10] <norsetto> nxvl_work: oh right, hyper mad :-) [20:10] <LaserJock> norsetto: why is that a sloppy habit? [20:11] <ScottK> cprov: The table has newest at the top, so it runs newest to oldest (this is good), but the status when you open the details is oldest to newest. It's a bit jarring. === apachelogger_ is now known as apachelogger [20:11] <ScottK> cprov: I'd put that most recent at the top too. [20:11] <norsetto> laserjock: do you know the meaning of maintenability and traceability? [20:11] <nxvl_work> norsetto: so will be debating about using dpatch or not, and he has a good point, which is that it is a bug that should be fix in debian [20:12] <LaserJock> norsetto: yes, and do you know the meaning of bloat? ;-) [20:12] <LaserJock> norsetto: the package is not using a patch system, adding one for just a one-liner in a single file is just overkill [20:12] <norsetto> nxvl_work: twell, all packaging bugs should be fixed in debian [20:12] <cprov> ScottK: good point, I can fix that, thanks [20:12] <cprov> LaserJock: thanks [20:12] <norsetto> LaserJock: thats not the point, the point is doing a sloppy thing because its easier [20:12] <LaserJock> no it's not [20:12] <joejaxx> LaserJock: hello :D [20:13] <LaserJock> it's the *correct* thing to do IMO [20:13] <LaserJock> joejaxx: hi [20:13] <LaserJock> norsetto: not using a patch system is not sloppy [20:13] * nxvl_work has the idea he has read this conversation before [20:13] <norsetto> LaserJock: oh right, so, Iḿ wrong and you are right type of argument [20:13] <LaserJock> norsetto: exactly ;-) [20:13] <joejaxx> lol [20:14] <norsetto> LaserJock: well, let me tell you that multi-million dollar projects are all wrong [20:14] <joejaxx> norsetto: they can be ;) [20:14] <LaserJock> what I'm saying is that I don't think this should add a patch system, not because I'm lazy or sloppy, but because it is uneccesary [20:14] <norsetto> LaserJock: and when they did as you suggest, take the easy way because is such a small change, than catastrophe arrived [20:15] * nxvl_work uses dpatch and stop reading the discussion [20:15] <LaserJock> there's several reasons why I'm against adding a patch system in this instance: [20:15] <nxvl_work> norsetto: is the 2nd time i make you fall into this conversation :D [20:15] <LaserJock> 1) it's added delta for us to carry [20:15] <LaserJock> 2) this change *should* go away, and is therefore temporary [20:16] <LaserJock> 3) the Debian maintainer is more likely to take the diff as it's not telling him how to run his patches [20:16] <norsetto> nxvl_work: well, you can't change the world but some battles are worth fighting :-) [20:16] <LaserJock> so I think doing dpatch for this would be overkill, that's my opinion [20:16] <norsetto> laserjock: so, is there a patching system already? [20:17] <LaserJock> no [20:17] <LaserJock> there is nothing patched yet in that package [20:17] <ScottK> At the very least just send the patch for the bug to Debian BTS. Don't tell the maintainer how to suck eggs too. [20:17] <norsetto> LaserJock: well, so why should the DD complain if we do it in Ubuntu? [20:18] <norsetto> LaserJock: send him the fix and fix it in Ubuntu the way we want [20:18] <LaserJock> norsetto: because if I was the DD I wouldn't want to add dpatch as I would think it would be overkill ;-) [20:18] <LaserJock> norsetto: right, we could do that [20:18] <LaserJock> but that's added work for us [20:18] <norsetto> LaserJock: who is asking teh DD to add dpatch? [20:18] <LaserJock> why make it *more* difficult than it needs to be [20:18] <norsetto> LaserJock: again, taking the easy way out [20:18] <LaserJock> norsetto: because our diff will show up in PTS, and he'll go "what the heck are they doing to my package?" :-) [20:19] <LaserJock> norsetto: *no* [20:19] <LaserJock> it's not the easy way out [20:19] <norsetto> LaserJock: oh my god, they touched my package! [20:19] <norsetto> ahahah [20:19] <nxvl_work> norsetto: well, i think we always need to report the DD about the problem, to check if they have it also [20:19] <LaserJock> it's *not* doing uncessary work [20:19] <ScottK> LaserJock: In Debian you'd have to (to not be wrong) use a patching system. [20:19] <LaserJock> no [20:19] <LaserJock> a patch system is not required [20:19] <ScottK> nxvl_work: I'd say don't report it unless you know they have the problem too. [20:20] * ScottK tries to decide if he cares enough to look it up. [20:20] <broonie> norsetto: Speaking as someone who periodically reviews the Ubuntu changes in my packages I do find it helpful if the changes carried are minimised. [20:20] <nxvl_work> ScottK: isn't a good think to email de DM saying "i have had this problem, did you?" [20:20] <cprov> ScottK: the ordering issue you pointed is fixed. Let me run this over archive-admins. [20:20] <norsetto> broonie: I sure appreciate that broonie, but some DD really needs to be prodded and even then [20:21] <broonie> nxvl_work: I'd say so (at least so they know what the change is). [20:21] <nxvl_work> ScottK: you don't care enough, believe me [20:21] <ScottK> nxvl_work: I would say no. I'd research if first and see if it affected Debian or was something Ubuntu unique. As a maintainer in Debian, downstream's unique problems are theirs, not mine. [20:21] <nxvl_work> broonie: that's what i mean [20:21] <TheMuso> c [20:21] <TheMuso> wrong tab [20:21] <ScottK> nxvl_work: I was pretty sure that was the case. [20:21] <ScottK> TheMuso: Your line there was ugh. [20:22] <LaserJock> norsetto: but what is wrong with not using a patch system in this case? Don't we want to minimize delta and work for ourselves? [20:22] <broonie> norsetto: Oh, lots of people would never look at the Ubuntu packages - I do so for the same reason I also peer at the Fedora, SuSE, Gentoo and so on from time to time. [20:22] <nxvl_work> ScottK: but there are some OBVIOUSLY thinks like the one we are talking about [20:22] <ScottK> TheMuso: Please stay on the scropt. [20:23] <bmk789> what java package is the new azureus fixed with? because im still getting the same error as before [20:23] <norsetto> LaserJock: not using a patch system is always wrong, not just in this case [20:23] <slangasek> ScottK: even if the changes aren't relevant to Debian, if they can be merged into the Debian package without negatively impacting the Debian experience I'm interested in that to help free up people's time to work on improving code instead of constantly re-merging [20:23] <LaserJock> norsetto: I would have to say that that is just categorically wrong === nixternal_ is now known as nixternal [20:24] <norsetto> LaserJock: yes, I'm wrong and you are right again [20:24] <LaserJock> norsetto: there are plenty of times when not using a patch system is appropriate [20:24] <ScottK> slangasek: I think that makes you substantially more open minded then most Debian maintainers. [20:24] <norsetto> LaserJock: spare the effort of spending 5 minutes [20:24] * nxvl_work *HUGS* norsetto to calm him :D [20:24] * ScottK is intensely sick of reading about Baltix problems that don't affect Ubuntu at all. [20:25] * norsetto hugs nxvl and laserjock too [20:25] <LaserJock> norsetto: nxvl_work has been banging his head against dpatch for a while when he could have had this FTBFS fixed an uploaded [20:25] <huats> asac: Hey... when you told me to add a comment about my network-manager experience... You mentioned a bug number. Do you recall which one it was ? [20:25] <norsetto> nxvl_work: I'm not angry at all, we are having a very interesting discussion I think [20:25] <norsetto> LaserJock: yes, thats good! [20:25] <nxvl_work> LaserJock: but a point for norsetto is that this is a good opportunity for me to learn dpatch also [20:26] <LaserJock> yeah, but it's not [20:26] <asac> huats: let me look ... did it help? [20:26] <slangasek> ScottK: well, doing so has also moved up my priority list now that I'm in a position to be affected by it on both sides ;) [20:26] <huats> asac: YES [20:26] <LaserJock> there are many good oppritunities to learn daptch [20:26] <nxvl_work> huats: once again, you came when i was looking for you :D [20:26] <huats> asac: it works great... [20:26] <norsetto> nxvl_work: I would even as far as tell you, next time try out quilt [20:26] <LaserJock> this one just seems very uncessisary [20:26] <huats> nxvl_work: I am here [20:26] <nxvl_work> huats: PM [20:26] <nxvl_work> norsetto: is quilt easier? [20:26] <asac> huats: its bug 145683 [20:26] <ubotu> Launchpad bug 145683 in network-manager "Network manager crash with WPA" [Undecided,Fix committed] https://launchpad.net/bugs/145683 [20:27] <norsetto> nxvl_work: not to learn, but its much more powerful to use than dpatch [20:27] <joejaxx> oh fun with quilt [20:27] <joejaxx> i had to learn that for openmosix [20:27] <huats> asac: ok, so I was looking at the right one .... [20:27] <huats> asac: great works really... [20:27] * nxvl_work reads quilt [20:28] <asac> huats: yes ... its 83623 as well ... but the one above tracks them all [20:29] <zul> a patch system is not always necessay and not always used [20:29] <norsetto> asac: have you had the chance to look at my email? [20:32] <asac> norsetto: about? [20:35] <persia> norsetto: In all your effort to add patch systems, please make absolutely 100% sure that there is never a package admitted to the archive that mixes raw patches in the diff.gz with a patch system. [20:35] <norsetto> persia: yes sir. will do sir. [20:36] <norsetto> persia: btw, any news on lash? I tested and seems good but I'd really appreciate your opinion on that [20:36] <persia> norsetto: Thank you. While I don't agree entirely that everything needs a patch system, I do really appreciate your efforts to teach people to use them. [20:37] <persia> norsetto: I ran into an annoying issue with jack, and haven't tracked that down yet. This annoys me, as there are currently lash patches available for 3 different packages that I want to integrate with your package :) [20:38] <norsetto> persia: ok, I'm waiting for your ok to upload in any case [20:39] <nxvl_work> quilt is fun [20:39] <nxvl_work> :D [20:40] <nxvl_work> but one cuestion, do i need to add anything to debian/rules? [20:40] <persia> norsetto: Thanks for your patience :) [20:40] <nxvl_work> i don't find anything about it [20:40] <norsetto> nxvl_work: (I also find it fun but don't tell anyone ....) [20:40] <LaserJock> norsetto: I agree with persia, btw. Patch systems are in the majority of the cases a good thing, and it's important to teach people to use them. Thanks for helping people with that. [20:40] <persia> nxvl_work: Yes. I think there is a quilt.mk floating about, but I don't remember where. [20:40] * nxvl_work smells comunitary HUG??? [20:41] <nxvl_work> persia: thnx [20:41] <nxvl_work> checking [20:41] <norsetto> nxvl_work: include /usr/share/quilt/quilt.make [20:42] * LaserJock hugs #ubuntu-motu [20:42] <nxvl_work> norsetto: and nothing else? [20:42] <norsetto> nxvl_work: yes, the usual targets [20:43] <norsetto> nxvl_work: unpatch for clean and patch-stamp for the appropriate configure/build [20:43] <nxvl_work> norsetto: the "usual targets" are the ones i'm having trouble with, is it documentation about it around? [20:43] <LaserJock> nxvl_work: read man dpatch.make for instace [20:43] <norsetto> nxvl_work: ok, what problem are you having? [20:44] <nxvl_work> norsetto: i don't know well how to manipulate debian/rules [20:44] <norsetto> nxvl_work: ok, you know more or less what a makefile is? [20:44] <nxvl_work> norsetto: and packaging guide is a little superficial [20:44] <LaserJock> nxvl_work: the example in dpatch.make is pretty good [20:44] <nxvl_work> yes, i know, what it makes, and what it works, but i don't feel i can write one [20:45] <norsetto> nxvl_work: well, very very superficially speaking, a makefile is a series of targets and pre-requisites; pre-requisite must be satisfied to achieve the given target [20:46] <norsetto> nxvl_work: are you with me so far? [20:48] <norsetto> nxvl_work: either I killed you with my pathetic makefile 101 or you are busy reading the dpatch.make example :-) [20:49] <nxvl_work> i'm back [20:49] <nxvl_work> norsetto: yes, that i already know :D [20:50] <persia> geser: That looks great. Thanks. [20:50] <norsetto> nxvl_work: ok, so lets skip the 101, why are you having a problem finding the right target for your stamp requisite? [20:51] <nxvl_work> yup [20:51] <norsetto> nxvl_work: what targets you have in your rules? and what are you patching? [20:52] <nxvl_work> cereal [20:52] <persia> geser: One wishlist request would be to have the version number link to the versioned LP page (e.g. https://launchpad.net/ubuntu/hardy/+source/usermode/1.81-3.1), while keeping the package name linking to the main LP page. [20:53] <norsetto> nxvl_work: I mean, what file? Its an autoconf file, a configure, a make, a source? [20:53] <nxvl_work> http://pastebin.com/m4299a76 [20:53] <nxvl_work> this is the clean rules [20:54] <geser> persia: I'm currently running it for: failed to build, chrootwait, depwait, failed to upload [20:54] <norsetto> nxvl_work: ok, looks liek a rules for something simple, like docs or scripts [20:55] <nxvl_work> yep [20:55] <persia> geser: Does it require a separate loop for each, or does it collect all that in a single run? Also, how long does it take? (I'm assuming it's LP-bound) [20:55] <norsetto> nxvl_work: and what is it that you are patching? [20:55] <nxvl_work> The Makefile [20:56] <geser> persia: the script and the template are at http://members.ping.de/~mb/depwait/ [20:56] <norsetto> nxvl_work: ok, check in which target is the makefile used [20:56] <geser> persia: 13 min for a run [20:56] <nxvl_work> norsetto: install i think [20:57] <norsetto> nxvl_work: right, so you have to patch before install [20:57] <norsetto> nxvl_work: in other words, you have to make patching a pre-requisite of the install target [20:57] <nxvl_work> and that's what i don't know, what runs first [20:57] <persia> geser: I'm tempted to wait for dktrkranz to discuss coordination, but based on quick oversight, I think I'd prefer that to be the "official" build status report, as it's a bit more informative. [20:58] <nxvl_work> it runs on the order it's readed or it has a order [20:58] <geser> persia: I've just uploaded the output from the last run [20:58] <norsetto> nxvl_work: thats what you decide, if patching is a pre-requisite for the install target, than the patchin target is run before the install one [20:58] <persia> WIth lots more colors! [20:59] <norsetto> nxvl_work: the order they are written is totally not influencing, what is important is target: requisite [20:59] <geser> persia: the colouring needs some improvement [20:59] <persia> geser: Actually, would you mind differentiating the FTBFS and chroot failure colours a little more? I can't see the difference easily when they aren't close to each other. [21:00] <nxvl_work> http://pastebin.com/d1e32f47c [21:00] <nxvl_work> norsetto: so it can look like this? [21:00] <persia> Is anyone here good with color palettes? [21:00] <geser> persia: sure, if you can tell me some good colors [21:01] <norsetto> nxvl_work: the unpatch in clean is ok, the include is ok, but why you add make in build? [21:01] <persia> geser: That's exactly what I'm hoping to elicit. I'm lousy with colors, but getting four non-green colors that look OK on a blue/white background and allow black overprinting would be ideal. [21:01] <cyberix> I'm looking for first sponsor for my package pq. I have posted the package to REVU, fixed all problems that have been raised, asked TB to confirm Multiverse inclusion and received approvals for inclusion from Shuttleworth, Zimmerman and Troup. I've also contacted the upstream developer and he said he will subscribe for pq bugs in Launchpad once it gets included in Ubuntu. http://revu.tauware.de/details.py?package=pq [21:01] <nxvl_work> norsetto: for the file to be patched? [21:01] <persia> cyberix: That's a very well-formed and informative advertisement. Thanks. [21:02] <norsetto> nxvl_work: what that would do, it would just call the makefile with no arguments [21:02] <norsetto> nxvl_work: you want to patch, not call make [21:02] <nxvl_work> and that wont work [21:02] <nxvl_work> mm [21:03] <cyberix> (...and I'm starting to sound like "The Twelve Days of Christmas") [21:05] <norsetto> nxvl_work: what is the target to patch? You can also look in /usr/share/quilt/quilt.make if you don't remember [21:06] <persia> LaserJock: re: "patch" tag: I was thinking of the tag as a sort of "confirmed & ready for review", whereas the other was a flag to encourage looking, but I'm not convinced enough of that to argue for it. [21:06] <norsetto> nxvl_work: do you see the patch: target in there? [21:07] <nxvl_work> it works [21:07] <nxvl_work> :D [21:07] <nxvl_work> norsetto: thnx [21:07] <nxvl_work> :D [21:07] <LaserJock> persia: ok, I'm currently chatting with kiko about it [21:07] <persia> LaserJock: Excellent. Thanks. [21:07] <norsetto> nxvl_work: :-D [21:07] * Fujitsu celebrates https://dogfood.launchpad.net/ubuntu/+source/dkim-milter/+publishinghistory [21:08] <nxvl_work> norsetto: one more thing, i read that i need to link patches to debian/patches, but on the make file it points to debian/patches, can i remove the patches link? [21:08] <persia> LaserJock: Also, if there's a way to mark a non-attachment comment a patch, I'd find that handy. [21:09] <norsetto> nxvl_work: I must admit I never used the link to debian/patches [21:09] <nxvl_work> removing and testing [21:09] <nxvl_work> it works [21:09] <nxvl_work> the wiki is wrong [21:09] * nxvl_work fixes [21:16] <persia> DktrKranz: geser was hacking the FTBFS script, and developed http://members.ping.de/~mb/depwait/out.html. What do you think? [21:17] <DktrKranz> GREAT! [21:17] <geser> persia: I've tried to improve the colour a little bit. Are they better now? [21:17] <Fujitsu> Oooh, colourful. [21:17] <Fujitsu> Soyuz is rather borked in some places. All binaries for some packages failed to upload... [21:17] <nxvl_work> i find really nice that the packaging guide is on the wiki, so we can correct it on any moment [21:17] <nxvl_work> :D [21:18] <persia> geser: I'm a little colour-blind, and can't tell the difference between the first two. Also, I'm not sure "green" is ever appropriate. [21:18] <LaserJock> persia: can you tell me anything about why the patch flag on has a 50% hit rate? [21:19] <DktrKranz> Yes, maybe base colour should be of higher contrast, but I'm not good in graphics [21:19] <Fujitsu> persia: green means that it's SEP, I guess. [21:20] <geser> persia: http://de.selfhtml.org/diverses/anzeige/farbnamen_netscape.htm and http://de.selfhtml.org/diverses/anzeige/farbpalette_216.htm have some colours, pick four [21:20] <persia> LaserJock: Lots of random things get labeled "patch" by commenters. This can be unlabeled in the interface (no idea of the ACL). Just fixing this covers the attachment case, but doesn't cover the patch-in-comment case (e.g. 2-line change) [21:20] <Fujitsu> geser: Can you please mark builds that are pending (ie. needs-build) if there are other FTBFSes? [21:21] <Fujitsu> As at the moment, hppa looks to be very successful. [21:22] <geser> Fujitsu: will try [21:22] <LaserJock> persia: are you counting debdiffs as a patch? [21:23] <LaserJock> persia: and is it possible to classify what most often get's misslabeled a patch [21:23] <geser> Fujitsu: have you a suggestion for the colour for it? [21:23] <persia> LaserJock: Sometimes: I only think debdiffs are interesting if the debdiff was rejected by the sponsors and not resubmitted for a couple months, but the problem was with the wrapping, and not with the patch. [21:23] <Ubulette> persia, hi. thanks for your answer. I'll work on that asap [21:23] <LaserJock> for sure you could probably make it so .pngs are not allowed as patches for instance [21:23] <LaserJock> ;-) [21:24] <Fujitsu> geser: Perhaps a different gray, as we don't really have a status. I'm not sure. [21:24] <persia> LaserJock: Generally self-uploaded crash reports, once a screenshot, and several times various logs. I'm not sure everyone understands "patch" [21:24] <LaserJock> yep [21:25] <Ubulette> persia, do you prefer that form ? http://paste.ubuntu.com/2265/ [21:25] <persia> geser: I can't find 4 easily distinguishable colors in the 216 palette, but maybe #FFFF66, #FF7F50, #FFD700, #FFDAB9 (and yes, it might be ugly) [21:26] <Ubulette> oops, obviously with get and new swapped [21:27] <geser> persia: updated, there is no much difference between #1 and #3 [21:27] <persia> Ubulette: That's much nicer looking in my opinion, but I think the sense of get-orig-source and new-orig-source is swapped (i.e. it looks to me like new-orig-source is grabbing the current source, and get-orig-source is grabbing new source) [21:28] <Ubulette> persia, yep, see 2 lines above ;) [21:28] <persia> Ubulette: Right :) [21:29] <persia> geser: Hmm. Looks different here, but maybe s/#FFFF66/#FFFF00/ to make it even more distinct? === _czessi is now known as Czessi [21:31] <persia> Does anyone else have any color suggestions, or do they find those colours bad? [21:32] * Fujitsu thinks the failed uploads should be blinking and say `complain to cprov', but that's probably not a good idea. [21:32] <DktrKranz> :) [21:33] <DktrKranz> what about having "Package failed to build" red? [21:34] <cprov> Fujitsu: I guess that's a superior message to me "stop now and go look for some food" :) [21:34] <DktrKranz> it should be distinct from MANUALDEPWAIT [21:34] <norsetto> cprov: stop now and go look for some food [21:34] <Fujitsu> cprov: Heh. [21:34] <StevenHarperUK> hi, in my debain/app.install file I want to replace lots of entries that look like this - locale/en/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/en/LC_MESSAGES - with one that looks like this - locale/*/LC_MESSAGES/easycrypt.mo usr/share/easycrypt/locale/*/LC_MESSAGES - is that possible - or is there something like it - I dont want to have to add a new line for each language. [21:36] <persia> Isn't there some translations helper tool that does that properly? [21:36] <norsetto> persia: he is not generating on the fly, the *.mo are in the source package together with *.po and the rest [21:37] <StevenHarperUK> I can do on the fly generation, but it seems like something else to go wrong [21:37] <persia> StevenHarperUK: Worst case, you could collect the names of usr/share/easycrypt/locale/* into a list in make, and then create a rule on the entries. [21:37] <slangasek> StevenHarperUK: can't you list entire subdirectory trees in app.install, or do you really have different filenames that go to different packages? [21:37] <Fujitsu> Can't dh_install do wildcards? [21:37] <slangasek> i.e., do locale/ usr/share/easycrypt/locale [21:37] <StevenHarperUK> It can do wildcards but not in the middle [21:37] <persia> StevenHarperUK: You really want to do on-the-fly generation, or you'll kick yourself when you forget the generation step once. [21:37] <slangasek> Fujitsu: yes, but you can't do backreferences [21:37] <StevenHarperUK> and it doesnt seem to do recurive directories [21:37] <Fujitsu> slangasek: Bah. [21:38] <persia> slangasek: Won't that toss in the .po files & the like? === cprov is now known as cprov-out [21:38] <slangasek> persia: if present, yes, that's why I asked :) [21:39] <StevenHarperUK> slagasek: a wildcard like locale/* just does that level [21:40] <persia> StevenHarperUK: I'd create a locale/$(LANG)/LC_MESSAGES/easycrypt.mo: rule in MAKE, with $(LANG) being a list (although I may not remember the syntax perfectly) [21:40] <StevenHarperUK> persia: I dont have a Make [21:40] <slangasek> persia: the problem isn't creating them, though, it's installing them to the package? [21:41] <persia> StevenHarperUK: debian/rules is a makefile [21:41] <Fujitsu> LaserJock: It does look like LP will be an OpenID provider from 1.1.12, not so much a consumer. [21:41] <StevenHarperUK> persia: ah I half knew that [21:41] <persia> slangasek: right. As I said, my syntax is rough: likely needs extra bits to put it in the right place. [21:41] <StevenHarperUK> persia: so I need a sample make file with that in [21:42] <LaserJock> Fujitsu: interesting [21:42] <LaserJock> Fujitsu: that makes it much less interesting sadly [21:42] <Fujitsu> Ooh, ssov2-open-op looks good. We can finally authenticate against LP externally! [21:43] <Fujitsu> Although that's 4 releases away. [21:43] <persia> StevenHarperUK: http://www.gnu.org/software/make/manual/make.html#Static-Usage describes the trick for one rule with lots of different targets [21:45] <LaserJock> Fujitsu: which means at least 8, right? they gotta push a few ;-) [21:47] <Fujitsu> LaserJock: Right, I've got some stuff that has been pushed back from 1.1.6 or so, and was just deferred again to 1.1.[12], I forget which. [21:53] * jdong installs new fglrx foolishly hoping it might improve performance/quirkiness [21:54] <Ademan> hey is there anything like xxgamma http://xxgamma.berlios.de/ in the repositories? or something covering that functionality? [21:55] <norsetto> nxvl_work: now you can simply send the Makefile.diff patch to the DD. Please link the bug from the BTS to LP. [21:56] <nxvl_work> why is BTS so unfriendly? [21:57] <norsetto> nxvl_work: why? [21:59] <nxvl_work> norsetto: i think LP has (i don't know the work in english) [21:59] <ScottK> nxvl_work: I have the same question about Launchpad. [21:59] <norsetto> nxvl_work: in spanish? [21:59] <nxvl_work> ScottK: LP is friendlier than LP [21:59] <nxvl_work> norsetto: mal acostrumbrado [21:59] <ScottK> No. I like BTS better as a bug tracker in many ways than LP. [22:00] <norsetto> nxvl_work: well, thats the bts I guess :-) [22:00] <nxvl_work> ScottK: it's a matter of work most with one [22:01] <ScottK> For me it's more a matter of BTS works the same way it did 6 months ago so I'm not constantly re-figuring out how to use it. [22:01] <nxvl_work> (at this time of the day my brain doesn't want to work i have forgot all my english, damn Kelly Boundy) [22:03] <nxvl_work> ScottK: i like the way it hangs with e-mail, but to search a bug using the web interface is what i dislike [22:04] <ScottK> Along those lines (LP is GUI and BTS is command line here): http://penguinpetes.com/b2evo/index.php?title=10_reasons_why_the_command_line_is_more_&more=1&c=1&tb=1&pb=1 [22:05] <LaserJock> I just had bad experiences with BTS to start with [22:05] * LaserJock is scarred for life === cassidy__ is now known as cassidy [22:06] <LaserJock> I tried using reportbug [22:07] <LaserJock> which is generally a nice app, except I use webmail [22:07] <geser> DktrKranz: how long does your ftbfs.py script usually run? [22:07] <LaserJock> so I ended up setting up some smtp app to send out the bug [22:07] <DktrKranz> geser, about 30 min [22:07] <LaserJock> and then it never responeded so I thought something was wrong and sent it again [22:07] <LaserJock> and ended up filing two bugs [22:07] <LaserJock> :-) [22:07] <nxvl_work> i have been scared by BTS before the time i try to became a DD [22:08] <LaserJock> I don't think bug trackers should make me feel as dumb as I am ;-) [22:08] <geser> DktrKranz: ok, then I didn't do something wrong, as mine takes about 20 minutes [22:08] <nxvl_work> (and then finally scared by the brainwash part of the NM process :P) [22:09] <DktrKranz> geser, Launchpad could be a huge bottleneck :) [22:09] <geser> DktrKranz: probably, or in mine case rmadison [22:09] * slangasek slips a little something into nxvl_work's lemonade [22:09] <LaserJock> hehe [22:10] <geser> DktrKranz: my last version is at http://members.ping.de/~mb/depwait/ if you want to look [22:10] <nxvl_work> but, maybe i dislike BTS because i don't know how to use, maybe working with it makes me more comfortable with it and makes me love it [22:10] <LaserJock> nxvl_work: I agree [22:10] <DktrKranz> geser, looks really good. [22:10] <LaserJock> for me, it was much more difficult to get going with BTS, but once you figure it out it's really nice [22:10] <jdong> does anyone love the SourceForge BTS? :D [22:10] <LaserJock> arggggg [22:11] <LaserJock> SourceForges bug and mailing list handling are from the devil himself [22:11] <ScottK> jdong: Not me. [22:11] * jdong peeks at the new mpeg4ip PPA build he uploaded, hoping that didn't infinite loop either [22:12] <jdong> OH CRAP [22:12] <alvinc> ? [22:12] <DktrKranz> geser, when you asked pitti about mass-rebuilds of FTBFS packages, he told you they won't be scheduled. Is there anything better we can do to file a list and pass it to a buildd-admin? [22:13] <jdong> alvinc: I got the build in infinite loop again [22:13] <jdong> isn't this a slight denial of service vulnerability with PPA's? [22:13] <alvinc> *chuckle* [22:13] <alvinc> h8 loops [22:16] <geser> DktrKranz: afaik no, but one could ask the build-admins if there is a better solution [22:17] <persia> DktrKranz: When you're happy with the code, could you push it to qa.ubuntuwire.com? (assuming geser doesn't mind) [22:18] <DktrKranz> We should really do so. When looking at FTBFS list, almost half of the failures should be solved with a give-back [22:18] <geser> persia: I don't mind but let me add a license text first [22:20] <ScottK> DktrKranz: If it's HPPA stuff you can ask Lamont. He fixed one for me today. === Spec is now known as x-spec-t [22:21] <DktrKranz> ScottK, several ports. Mainly tex-*, gnustep and libglib1 [22:21] <ScottK> OK. [22:22] <DktrKranz> which should be already OK (at least for i386, where I checked) [22:22] <LaserJock> DktrKranz: what tex-* ? [22:23] <DktrKranz> LaserJock, FTBFS due to an early texlive uninstallable package [22:24] <LaserJock> DktrKranz: which package, do you know? [22:25] <DktrKranz> LaserJock, let me check... [22:29] <DktrKranz> LaserJock, something like http://launchpadlibrarian.net/10179662/buildlog_ubuntu-hardy-i386.bibtex2html_1.87-2_FAILEDTOBUILD.txt.gz and http://launchpadlibrarian.net/10250408/buildlog_ubuntu-hardy-i386.xsu_0.2.3-2_FAILEDTOBUILD.txt.gz [22:47] <LaserJock> dang, I hate it when I lose my Firefox profile [22:47] <persia> StevenHarperUK: I know you want the latest version in Ubuntu, but would you mind batching fixes upstream, and pushing a new revision once every couple weeks (unless there's a showstopper bug)? More frequent updates just use sponsor time, with not so much benefit to either users or your LP pages. [22:48] * LaserJock kicks OS X [22:48] <persia> LaserJock: Stop using FireFox :) [22:48] <LaserJock> persia: hehe, like that's gonna happen [22:49] <persia> LaserJock: Why? Are you that unhappy with the alternatives? I've not lost a session once since I decided that Firefox wasn't capable. [22:49] * persia tends to use epiphany & safari, depending on the window manager in use [22:50] <LaserJock> I am unhappy with the alternatives [22:50] <LaserJock> all browsers (and email apps for that matter) suck, Firefox sucks less [22:50] <jpatrick> I just use Konqueror [22:50] <LaserJock> epiphany has some strange things that I don't like [22:51] <LaserJock> safari is sort of ok [22:51] <geser> DktrKranz: the last version of my script (and the last output) is at http://members.ping.de/~mb/depwait/ [22:51] * ScottK uses Konqueror on the laptop and Firefox on the desktop. No idea why. [22:51] <LaserJock> but I do like a few extentions like Greasemonkey that are somewhat hard to live without [22:51] <LaserJock> ScottK: weird. [22:51] <ScottK> Yeah. That's me. [22:51] <DktrKranz> geser, is it ok for you to put it on qa.ubuntuwire.com/ftbfs/ ? [22:52] <StevenHarperUK> perisa; are you asking me to do less releases? [22:52] <jpatrick> geser: could you please approve my mail to -council@? [22:52] <geser> DktrKranz: I've added Fujitsu wish to also list "needs building" but I'm not sure if it works (nothing is listed as "needs building" in the table) [22:52] <geser> DktrKranz: sure [22:53] <DktrKranz> geser, I'll give it a look, then [22:53] <geser> jpatrick: I could but I'd need to look how to do it as dholbach usually does it [22:53] <jpatrick> geser: ah, okay [22:53] <DktrKranz> geser, any requirements? bash scripts or similar? [22:53] <StevenHarperUK> persia: 0.2.1.6 has all the feature I have planned for easycrypt [22:53] <geser> DktrKranz: rmadison (devscipts) and python-genshi [22:53] <StevenHarperUK> persia: 0.2.1.16 i mean [22:54] <StevenHarperUK> persia: New releases will be less requent [22:54] <StevenHarperUK> persia: *frequent - I expect a few new languages in 1-2 weeks time [22:54] <persia> StevenHarperUK: OK. You just seem to be of the "release early, release often" school, which I think is good, but from a distribution management point of view, it's not usually that all "release early, release often" upstream releases get packaged. [22:55] <geser> DktrKranz: and colouring could still be improved (and still be distinguishable for persia) [22:55] <persia> Now that the package is in, I'd recommend targeting your next package upload for around mid-december. [22:55] <StevenHarperUK> persia: As i am the Packager and upstream I tent to notify myself that it need packaging :P [22:56] <persia> StevenHarperUK: Sure, it's just not worth making all the buildds work so hard when users can't tell the difference :) [22:56] <StevenHarperUK> persia: I am learning all this I didn't even know Python 6 weeks ago - I want to practice a bit [22:56] <persia> (as hardy has very few users today) [22:56] <persia> StevenHarperUK: Understood. That's why I didn't say all this for the .15 release. [22:56] <StevenHarperUK> persia: I am a developer for a job - I have automated all the builds - its not too much effort , but I do understand [22:57] <StevenHarperUK> persia: Maybe I should try to package TrueCrypt next [22:57] <persia> StevenHarperUK: Excellent, and thanks again for packaging your software for Ubuntu. [22:58] <persia> Sure. More packages aren't bad, especially if there's someone motivated to keep them relatively up-to-date and clean. [22:59] <geser> DktrKranz: I found an error in my script: in line 107 there is () missing after entry.empty (I've updated the script at my webspace) [22:59] <DktrKranz> geser, I'm pushing it right now [23:00] <Ubulette> persia, even i use dh_install like you propose, i still have to keep a lot of install as i rename a lot of files [23:01] <persia> Ubulette: Do all the files need to be renamed? Is upstream truly braindead when it comes to nomenclature? I'm willing to believe this, but just want to check (as we like to have the upstream docs match Ubuntu installations, if possible) [23:02] <geser> DktrKranz: thanks, I'm going to bed now, let me know if you find any bugs or have any issues with the script [23:03] <DktrKranz> Sure. Thanks for this, mine was dreadful :D [23:03] <Ubulette> persia, no, it's just that i'm picking up some icons from upstream to use for our desktop and mime files [23:03] <persia> Ubulette: Ah. You'll need some rules then. Hmm. I'm a big fan of clean debian/rules, and don't know the best way. You might ask someone else for their opinion as well. [23:04] <RainCT> hi [23:05] <RainCT> anyone here uses launchpadbugs (Python module)? [23:05] <persia> RainCT: You might also try in #ubuntu-bugs: I think it's more popular for them (and the right people appear to be off holiday) [23:06] <persia> (of course, timezones may still mean little to no response :) ) [23:06] <RainCT> persia: right, thanks [23:06] <RainCT> :) [23:07] <LaserJock> Ubulette: you're trying to install icons? [23:09] <Ubulette> LaserJock, well, no. it worked well before. now, i'm trying to achieve the very last change that persia proposed and i'm just destroying the thing [23:15] <StevenHarperUK> Hi - I want to package up Truecrypt - I haven't done someone else's source before, can anyone help me gest started? [23:17] <RainCT> good night [23:18] <ScottK> StevenHarperUK: It's pretty much like what you have done already, just less talking to yourself. [23:19] <StevenHarperUK> Scottk: Truecrypt have a build.sh and an install.sh, they also have a DEB so I can see where things should end up [23:19] <ScottK> In most cases you won't even need to talk to upstream either, usually just if there's a problem with package you want them to fix. [23:20] <jpatrick> my upstream's usually turn out to be quite nice [23:21] <StevenHarperUK> Scottk: I know this is a basic question, but are the stages: get debain/rules to build from source -> get rules to install compiled [23:21] <persia> StevenHarperUK: just as an example of a normal release often upstream request, see bug #165285. (Of course, interdiff is much preferred :) Thank you.) [23:21] <ubotu> Launchpad bug 165285 in zim "New upstream version: 0.23" [Undecided,New] https://launchpad.net/bugs/165285 [23:22] <ScottK> StevenHarperUK: Usually I find getting copyright and all the other bits correct is more trouble than debian/rules. [23:22] <StevenHarperUK> Scottk: The problem I have is that docs of truecrypt state that the build requires ALL kernel source, not just headers : that sounds bad to me [23:23] <ScottK> StevenHarperUK: That sounds like not a beginner's project to me. [23:23] <slangasek> that sounds like a project that a non-beginner would reject as broken upstream ;) [23:23] <jdong> StevenHarperUK: yeah that sounds like a complicated package to deal with unless the kernel module portion is already a part of Ubuntu [23:23] <jdong> otherwise you're doing module-assistant territory work [23:24] <StevenHarperUK> ScottK: Yeh I did guess that, I think the bits are already in Ubuntu [23:24] <StevenHarperUK> one of them is modprobe [23:25] <ScottK> StevenHarperUK: If you want something new to work on, why don't you get your package into Debian? Since (IIRC), it's a Python app, you can join the Debian Python Application Packaging Team and it's pretty easy to get sponsored. [23:25] <StevenHarperUK> Scottk: I know its a fairly big job, but I have learned Python and debian packaging and po translations and the ubuntu process in the last 6 weeks to get my current project done [23:26] <ScottK> Sounds like working into Debian next is a good next step then. [23:26] <StevenHarperUK> ScottKk: the problem there is that I dont have a Debain test machine [23:26] * slangasek waves a wand called debootstrap [23:26] <ScottK> StevenHarperUK: You can make a Debian chroot and that's likely good enough. [23:26] <StevenHarperUK> ScottK: is there a Quick overview of Submitting to Debian? [23:26] <ScottK> StevenHarperUK: I maintain ~ half a dozen packages in Debian also without a Debian test machine. [23:27] <LaserJock> ScottK: shhhh, are you supposed to say that with slangasek around? ;-) [23:27] <norsetto> g'night all [23:27] <jdong> lol [23:27] <StevenHarperUK> Scottk: another problem Truecrypt don't make a Debain DEB [23:28] <slangasek> LaserJock: it's ok, I don't have a Debian test machine either, I run all my packages on simulations in my head ;P [23:28] <LaserJock> slangasek: haha [23:28] <LaserJock> I would wonder more if you had an Ubuntu test machine [23:28] <LaserJock> but I suspect Mark makes you have at least one [23:30] <slangasek> not Mark, that enforcement is delegated :) [23:32] <LaserJock> of course [23:33] <ScottK> So he left. Urgh. [23:35] <ScottK> On the off chance StevenHarperUK returns while I'm out, would someone please point him at https://lists.ubuntu.com/archives/ubuntu-devel/2007-August/024161.html and https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam [23:37] <badarts> what is the official repo for w32codecs and similar stuff? [23:37] <jdong> !medibuntu [23:37] <ubotu> medibuntu is a repository of packages that cannot be included into the Ubuntu distribution for legal reasons - See http://www.medibuntu.org [23:38] <jdong> and it is not official, though "as close as it gets" [23:38] <jdong> report problems with medibuntu to their launchpad product, not against the Ubuntu distribution [23:38] <jdong> oh yeah this isn't a support channel [23:39] <Ubulette> persia, http://paste.ubuntu.com/2274/ better ? same ? worse ? [23:39] <badarts> thanks :) [23:39] <LaserJock> jdong: ;-) [23:40] <StevenK> LaserJock: Ponies! [23:41] <badarts> jdong: well, not even the universe is really official, but only "as close as it gets" ;) [23:41] <ScottK> badarts: Universe is official, but unsupported. [23:42] <jdong> what ScottK said. [23:42] <jdong> medibuntu is neither official nor supported [23:42] <ScottK> By Canonical that is. The community supports it moderately well. [23:42] <jdong> though it is run by (mostly? all?) MOTU's [23:42] <Sp4rKy> mostly [23:43] <jdong> Well regardless of the badges on their maintainers, I've not seen a single thing in medibuntu that I wouldn't feel comfortable putting on my primary computer [23:45] <persia> LaserJock: Just thought of a counter-case: a .png file could be considered a patch for a "broken icon" issue. [23:45] <TheMuso> How does one force a package into a particular section, i.e universe for PPAs now? [23:46] <persia> Ubulette: I guess that's about as clean as it gets :( Thanks for trying. [23:46] <LaserJock> persia: I can't help but think that that would be a corner case. It can still be an attachment, just not listed as a patch [23:47] <LaserJock> TheMuso: how do you mean? [23:47] <persia> LaserJock: Right, but it's an example why blocking on MIME type doesn't help. The idea is to have a nice set of bugs that have been triaged to determine that they are good candidates for someone to do some testing and packaging. [23:48] <Ubulette> persia, i really tried to reduce install using dh_install and dirs but i gained only 3 lines and it made things difficult in the other *.install files [23:48] <Fujitsu> TheMuso: PPAs don't have components any more. [23:48] <TheMuso> Fujitsu: Oh. [23:48] <persia> Ubulette: I understand. When it's not a help, it's not a help. Thanks for trying :) [23:48] <TheMuso> LaserJock: ^^ [23:49] <StevenK> Mainly because components for a PPA doesn't make sense [23:49] <LaserJock> persia: well, I'm filing bugs for getting an idication in the comments that an attachment is a patch, and also a link to "depatch" it [23:49] <Fujitsu> StevenK: I would personally like PPA components to be customisable, but all ogre against multiverse. [23:49] <TheMuso> StevenK: On one hand I agree, but on the other, I don't. [23:50] <Ubulette> persia, so, what's next now? I guess I need to push an update to REVU [23:50] <persia> LaserJock: We already have that. It's currently abused (but can be fixed), and there's not currently any way to track textual patches that are not attachments. [23:50] <persia> Ubulette: Exactly. [23:50] <StevenK> TheMuso: Wha, huh? Either you agree or you disagree. :-) [23:50] <Ubulette> persia, on top of the last (uncommented) one ? [23:51] * persia seeks extended commentary from TheMuso explaining the dichotomy [23:51] <LaserJock> persia: how do you mean we already have that? [23:51] <persia> Ubulette: Yep. Same version, etc. [23:51] <Ubulette> ok [23:51] <persia> LaserJock: There's a searchable flag on attachments, and members of some ACL can set or remove the flag for any attachment to any bug. [23:51] <TheMuso> StevenK: I agree that it doesn't make sense, but I disagree in that if components were customizable, it would allow you to keep groups of packages together. [23:53] <Fujitsu> TheMuso: That's my thinking too. [23:53] <LaserJock> persia: yeah, you can get at it eventually. I'm thinking quick-n-easy triage would help get the patch flag more usable [23:53] <Fujitsu> Since they removed the multiple PPAs per user feature. [23:54] <mok0> Is there a website with the popularity of Ubuntu packages? [23:54] <persia> LaserJock: Nah: the interface is pretty easy. The problems are 1) that it is abused, so it's not inviting for Contributors to search those, and 2) it doesn't support non-attachment patches. [23:54] <LaserJock> popcon.ubuntu.com I think [23:54] <LaserJock> mok0: ^^ [23:55] <mok0> duh [23:55] <LaserJock> persia: how is it being abused? [23:55] * persia notes that popcon is voluntary, and therefore under-represents most users [23:55] <persia> LaserJock: being applied to non-patches [23:55] <LaserJock> persia: right, I'm just trying to think of ways we can make it better [23:55] <LaserJock> marking non-attachments as patches is no go [23:56] <LaserJock> but kiko said they could probably have a thing to conver a comment into an attachement [23:56] <LaserJock> *convert [23:56] <persia> Right. More ideas is great. Non-attachments as patches was a non-starter. I was using a tag, but if you've another solution that isn't just "put a new interface to existing functions", I'd be happy to hear it. [23:57] <persia> converting the comment into an attachment doesn't help. They tend to be 2 or 3 line diffs with commentary above or below. [23:57] <LaserJock> persia: well, my main concern is that we already have the patch flag, if it's broken or not working we need to get it fixed I think [23:58] <LaserJock> not that we can't use tags as well [23:58] <LaserJock> I was thinking if we can get the patch flag working better and then have a good-patch or similar tag to say the patch is verified/triaged [23:58] <LaserJock> then we have a good system for dealing with patche [23:58] <persia> I don't think it's broken, I just don't think it's a good target to point Contributors at when asking for patch review efforts. [23:59] <LaserJock> true [23:59] <LaserJock> but %50 is pretty low [23:59] <mok0> Hmm popcon doesn't seem to work properly :( [23:59] <persia> Also, my definition of "triaged" is "This is a real patch, and nobody hates it", rather than "This is a good patch"