[00:00] <up_the_irons> in my debian/rules, i have: http://p.caboo.se/151263, but when i run debian/rules build, I get this error: http://p.caboo.se/151269.  I think it's simple, but i'm new to this.  anyone can point me in the right direction?
[00:00] <superm1> Riddell, licensing
[00:00] <superm1> Riddell, its not an entirely free license on it
[00:02] <blueyed> up_the_irons: that's bash code.
[00:02] <RAOF> up_the_irons: That's quite crazy.
[00:02] <up_the_irons> blueyed: i've seen bash code in other debian/rules files
[00:02]  * StevenK tries to stop his eyes bleeding
[00:03] <RAOF> up_the_irons: The main problem is that you don't have enough ';'s, I think.
[00:03] <RAOF> up_the_irons: And I don't believe you can use fi there.  Because this is a *single* line being run by sh.
[00:03] <up_the_irons> RAOF: thanks, yeah, someone in #debian just pointed that out
[00:04] <up_the_irons> RAOF: i'm looking at the debian/rules for xen-linux-system-2.6.18-4-xen-686, and it indeed uses 'fi'
[00:04] <up_the_irons> RAOF: as an example
[00:04] <RAOF> Fair enough.  I'm not a sh fiend by any means.
[00:04] <up_the_irons> nor am i, but seems i keep running into it
[00:05] <blueyed> up_the_irons: you need additional semicolons.. after commands, and before fi probably.
[00:05] <StevenK> You certainly can use 'fi' in one-liners, you just need to be mindful of where you put your semicolons
[00:05] <RAOF> Also, you should spell confirm CONFIRM, not ONFIRM :)
[00:06] <up_the_irons> RAOF: yeah, it *is* $CONFIRM, but somewhere it got lost in the paste ;)
[00:06] <up_the_irons> blueyed: thanks
[00:07] <RAOF> up_the_irons: Oh, yeah.  You actually want $$CONFIRM, otherwise make thinks you're referencing the variable $C
[00:07] <up_the_irons> RAOF: aah
[00:07] <up_the_irons> RAOF: good catch
[00:08] <up_the_irons> oh man, maybe i should just make a shell script
[00:09] <up_the_irons> this is getting weird
[00:09] <up_the_irons> i guess in the packages i'm looking at, the if's are indeed oneliner's
[00:09] <RAOF> up_the_irons: Your problem is that you're trying to write a shell script inside a make file.  So you're fighting your tools, which is never fun.
[00:09] <up_the_irons> yup, that was it
[00:10] <up_the_irons> RAOF: i know, i know...  i'm just not very good at makefiles; and i'm trying to learn the packaging thing at the same time.  so i'm tripping over myself
[00:11] <RAOF> For example, it looks like you could make a linux-2.6.18-xen.hg target, and make build-stamp depend on that.
[00:11] <up_the_irons> RAOF: yup that's exactly what i'm typing right now ;)
[00:12] <up_the_irons> i saw shell in other debian/rules files and i figured "yay, i can use shell in makefiles".  i was wrong
[00:12] <up_the_irons> just simple 1-liner shell
[00:18] <up_the_irons> now *that's* better:
[00:18] <up_the_irons> http://p.caboo.se/151279
[00:21] <up_the_irons> so question
[00:22] <up_the_irons> when i run dpkg-buildpackage, and it does its thing, is that when any changes I made into the source tree get reflected in the diff.gz ?
[00:22] <azeem> depends on the option
[00:22] <RAOF> I don't *think* you have to even have those shell ifs there.  You should be able to declare a linux-2.6.18-xen.hg target.
[00:22] <blueyed> up_the_irons: now you could depend on the file, instead of the if.. :)
[00:22] <up_the_irons> blueyed: dood, i tried that
[00:22] <up_the_irons> blueyed: it said unknown target
[00:23] <up_the_irons> RAOF: yeah, i figured the same, but it said unknown target
[00:23] <RAOF> up_the_irons: You'd need to have a "linux-2.6.18-xen.hg:" line, containing the hg clone command.
[00:23] <up_the_irons> so I can merrily make changes in the source tree, and it'll automatically become part of the diff?
[00:23] <up_the_irons> RAOF: oh
[00:23] <up_the_irons> RAOF: ok
[00:23] <RAOF> blueyed: Are you still looking at gnome-do?
[00:24] <up_the_irons> RAOF: the last time I wrote my own makefiles from scratch was in the Turbo C++ 3.0 for DOS days ;)
[00:26] <blueyed> RAOF: in my free time during fixing my own package, I'll try a build now and then probably advocate, looks good!
[00:27] <RAOF> blueyed: I can upload a new candidate with the changes you've requested if you like.
[00:27] <RAOF> But they won't affect the build, so if you just want to advocate I'll upload the changed package to universe :)
[00:28] <blueyed> RAOF: sounds good :)
[00:28] <up_the_irons> RAOF: that worked, now I have a much cleaner: http://p.caboo.se/151282
[00:28] <RAOF> blueyed: To the new revu upload, or the advocate-and-me-upload approach? :)
[00:29] <RAOF> up_the_irons: Things look *much* cleaner when you don't fight your tools :)
[00:30] <blueyed> both indeed.. but persia has also looked at my package. you might want to check out debian/copyright, but I'll have to add more headers and preambles there.
[00:30] <blueyed> The package is jedit.
[00:30] <up_the_irons> RAOF: indeed :)
[00:31] <RAOF> blueyed: Ok.  The new candidate should show on revu shortly.  I'll check out jedit.
[00:41] <RAOF> blueyed: I see why persia suggests using make variables for your get-orig-source target.  It seems you could define version & uversion as make variables, and possibly split get-orig-source into get-upstream-source & repack-upstream-source targets.
[00:42] <RAOF> Something like "version=$(shell dh_testdir && uscan --dehs | sed ..etc)"
[00:43] <RAOF> I'm also not a big fan of the side-effect of setting version being that the tarball is downloaded.
[00:46] <blueyed> that from the tarball? it's a check only there.
[00:47] <RAOF> blueyed: "version=$$(uscan --force-download ...)"
[00:47] <blueyed> RAOF: would it be ok to be called from "anywhere" then?
[00:48] <RAOF> blueyed: With the make variables?  You'd still need to cd ${DEBIAN_DIR}/.. first, yes.
[00:49] <RAOF> I haven't worked it through, but I believe it'd end up looking cleaner.
[00:49] <blueyed> RAOF: but still shell like? with && and on the same line? (because of e.g. the "cd")
[00:50] <RAOF> Yeah.  You'd need to have it shell-like.  The difference would be that you would have a bunch of smaller, split up shell lines.
[00:51] <RAOF> blueyed: Oh, actually, no!  "version=$(shell cd ${DEBIAN_DIR}/.. & uscan --dehs | ...)" would be callable from anywhere.
[00:51] <blueyed> wow.. there's even a version hardcoded currently.
[00:51] <blueyed> With a single "&"?
[00:51] <RAOF> Ahem.  && :)
[00:53] <blueyed> should I not get the version/uversion from the sourceball? Just define them at the top of the rules?
[00:54] <RAOF> That *will* get the version/uversion from the sourceball.  Make variables defined with "=" are pretty much recursive text-substitution (IIUC), so it's evaluated only where you dereference it.
[00:55] <RAOF> IE: when you go "$(version)", make will replace that with "$(shell foo)", then evaluate $(shell foo).
[00:55] <blueyed> in contrast to ":="?
[00:56] <RAOF> Yes.  ":=" means "evaluate right now".
[00:58] <emgent> heya people
...  the package finally built, now to see what are conffiles
[01:01] <blueyed> RAOF: better? http://pastebin.com/m2c01a479
[01:02] <blueyed> up_the_irons: you define them in "conffiles", that are those where you're asked during upgrade when you have changed them yourself, and the maintainer, too.
[01:03] <up_the_irons> blueyed: ok thanks.  what do you mean by "and the maintainer, too" ?
[01:04] <blueyed> the package maintainer: you're only asked, if the maintainer changed the default conffile, to merge your changes or take his (or keep yours).
[01:04] <RAOF> blueyed: That doesn't actually work, does it?  Sorry, I've been unclear.  I was thinking of defining version=$(shell foo) just above (and outside of) the get-orig-source target, or even at the top of the file.
[01:06] <RAOF> And you won't need to cd ${DEBIAN_DIR} in your get-orig-source; the only reason you needed to do that is to make uscan work, yes?
[01:07] <up_the_irons> blueyed: ok thanks for the info
[01:10] <up_the_irons> regarding the generated diff.gz, that is the difference between the <package>-orig.tar.gz and the build directory?
[01:11] <up_the_irons> actually, looks like there is a directory that should not be represented in the diff (b/c it is downloaded by hg), is there a way to ignore it, or should that in fact remain in the diff?
[01:12]  * StevenK gets confused. I build gnome-games, and it has undefined references to things that are defined in the same file
[01:13] <up_the_irons> mm.. and why is it trying to diff build files (like *.o)..
[01:13] <up_the_irons> crap "dpkg-source: unrepresentable changes to source"
[01:14] <blueyed> up_the_irons: clean them in your clean target.
[01:14] <up_the_irons> blueyed: ok
[01:14] <blueyed> RAOF: yes, it totally not works currently. and ${DEBIAN_DIR} does not seem to work for ./rules binary anyway?!
[01:15] <up_the_irons> blueyed: but is there a way to just ignore certain directories?  b/c if i clean them, the next time i build this package, say to add a single kernel module, it will want to rebuild the entire kernel
[01:15] <up_the_irons> blueyed: what is the way to do this so i don't fight my tools? :)
[01:17] <RAOF> up_the_irons: Those are restrictions of the debian-source-package format.  You can use dpkg-buildpackage -nc to try to build without cleaning first, but debian/rules clean should take you back to a pristine build directory.
[01:17] <up_the_irons> maybe i should just cp -a them out of the tree, and put them back when i need them. ghetto style ;)
[01:17] <up_the_irons> RAOF: ok, i kinda thought so
[01:18] <up_the_irons> RAOF: i could just save the build directories somewhere, and copy them back when i need them, as if they were always there.  this package is for my use only, not gonna distribute it
[01:18] <up_the_irons> RAOF: i just really hate to recompile the whole kernel just for a simple change
[01:19] <up_the_irons> RAOF: if I *didn't* use a package syste, i could do it no problem.  So I want to stay package friendly, but hopefully not lose the benefits of a build system (that only builds stuff that has changed)
[01:19] <up_the_irons> *system
[01:19] <RAOF> up_the_irons: Have you checked out the ubuntu-kernel buildy thing?  That might be what you're after.
[01:19] <up_the_irons> brb
[01:19] <up_the_irons> RAOF: you mean build-kpkg, or something
[01:19] <up_the_irons> *make-kpkg
[01:20] <RAOF> No; there's some new infrastructure in the Ubuntu kernel source pacakages.
[01:20] <up_the_irons> no i haven't tried that
[01:20] <up_the_irons> but this package is from xen-3.2.0 tarball
[01:20] <up_the_irons> i have a feeling it will be hard to integrate
[01:20] <up_the_irons> not a vanilla kernel
[01:20] <up_the_irons> what I'm aiming for is, a single .deb that contains everything I get when I do 'make install' from the Xen tarball
[01:21] <up_the_irons> so far, I've gotten close
[01:21] <up_the_irons> in fact, debian/xen does contain the entire built tree
[01:21] <up_the_irons> now it's just a matter of packaging it
[01:22] <up_the_irons> ok, been sitting down too long, brb in 10 mins
[01:24] <RAOF> Aw, man.  What with the nouveau testing I'd forgotten how awesome compiz is.
[01:26] <StevenK> RAOF: What the?
[01:27] <StevenK> I find I can't drag windows between viewports anymore, which is irritating me.
[01:27] <RAOF> I've been using metacity's compositor.  Changing workspaces is supremely ugly, compared to cube.
[01:28] <RAOF> WorksForMe(tm)
[01:29] <StevenK> I have to expose out using Super-e, drag and them go back in
[01:30] <RAOF> Hm.  You're using wall or cube?
[01:30] <pochu> persia: I'm fine with the watch file
[01:31] <RAOF> StevenK: You might want to check out the various "edge flip" options in ccsm?
[01:32] <blueyed> RAOF: gnome-do is similar to katapult, isn't it? It also does not support "f1" for help at least.. ;)
[01:33] <blueyed> RAOF: advocated.
[01:34] <RAOF> blueyed: I don't know, I've never used katapault.  Also, correct.  No f1-is-help yet :)
[01:34] <RAOF> blueyed: Thanks.  Yay!
[01:35] <jdong> what is the "this is a merge" heuristic
[01:35] <blueyed> when activating it again here on kde4, it does not display, but grabs input..
[01:35] <jdong> it seems like if I say the D word anywhere in the changelog it's officially a merge :)
[01:35] <RAOF> blueyed: Don't tell me that kde4's compositor is broken, too?
[01:36] <blueyed> RAOF: I've no desktop effects enabled..
[01:36] <RAOF> blueyed: I saw that behaviour on Metacity, but it's been partially fixed.  It should work fine without a compositor or with xcompmgr or compiz.
[01:36] <RAOF> blueyed: Really?  Hm.
[01:37] <blueyed> it's the same with desktop effects..
[01:37] <RAOF> up_the_irons: Have you checked out the ubuntu-kernel buildy thing?  That might be what you're after.  February 13 01:44	 MOTU chalserogers@gmail.com  	  Addressed comments from blueyed in #motu   	 Yes  	 [del] [remove advocating]
[01:37] <RAOF> Frikkin touchpad!
[01:37] <blueyed> i have to click somewhere around to get the input back.. it actually starts programs, but I can't see it before..
[01:38] <RAOF> blueyed: I've only seen that with broken compositors, but I haven't tried it in KDE, either.
[01:38] <StevenK> RAOF: I know that as slammermaus, based on when I first starting using IRC. A guy was nicknamed slammer (not his actual nick), and he kept blaming his mouse for pasting large gobs of text into the channel.
[01:39] <RAOF> I should find the irssi knob that disables pasting.  It already saves me from accidentally pasting in *huge* ammounts of text..
[01:49] <RAOF> For those in the audience, paste_verify_line_count is the irssi variable I'm looking for.
[01:52] <ember> paste_detect_keycount
[01:53] <StevenK> RAOF: You set that to one, and it asks you for even one line?
[01:56] <blueyed> RAOF: re-uploaded jedit (a new upload with only minor licensing indenting and re-order ("*" to top), uploaded afterwards (should appear at 2utc then)
[01:56] <RAOF> StevenK: Yup.  Just checked.
[02:01] <RAOF> blueyed: Ok.  I'll keep looking.
[02:06] <up_the_irons> in the clean: target, what is the minus sign before "-$(MAKE) clean" for?
[02:07] <up_the_irons> (this is in the generated template)
[02:07] <slangasek> for generating a lintian error
[02:08] <up_the_irons> slangasek: ok
[02:08] <RAOF> up_the_irons: It means "ignore errors from this command", and what you actually *want* is [ ! -f Makefile ] || $(MAKE) clean
[02:09] <RAOF> Which translates to "If the makefile doesn't exist, do nothing.  If it does exist, run make clean"
[02:13]  * asantoni looks for advocate for LP #190589.... :) (any MOTU with a few spare moments?)
[02:13] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Wishlist,New] https://launchpad.net/bugs/190589
[02:14] <up_the_irons> RAOF: ah ok
[03:10] <RAOF> ls
[03:11] <RAOF> What, you mean that won't list all the files in #ubuntu-motu?  Soft!
[03:11] <RAOF> blueyed: jedit fails to build a source package for me - is this likely to be a build-dep lack on my part?
[03:12] <blueyed> RAOF: do you have ant installed?
[03:12] <RAOF> It would seem the answer is "no".
[03:12] <blueyed> RAOF: I've just uploaded a new version (and messed around quite a bit in the meantime)
[03:13] <RAOF> blueyed: Ok.  Does it really depend on java5-runtime?
[03:13] <blueyed> RAOF: icedtea-java7-jdk, ant, ant-optional
[03:14] <RAOF> blueyed: I mean, debian/control lists java5-runtime as a dependency of the binary package.  Did you mean icedtea | java-v-m | java5-runtime?
[03:15] <RAOF> Right.  I'll check out the new, new package then :)
[03:15] <blueyed> RAOF: yes, indeed. Should I put j-v-m last even?
[03:16] <superm1> isn't there a nice way to say use a virtualpackage that represents a jre?
[03:16] <RAOF> That should surely be java-virtual-machine, no?
[03:16] <RAOF> Or is it java-runtime?
[03:17] <RAOF> There was a page somewhere with a non-exhaustive list of virtual packages, but I can't remember where.
[03:17] <superm1> i think its java-virtual-machine
[03:17] <superm1> yeah it is, but it doesnt list icedtea yet
[03:17] <jdong> unless he has a specific list of VM's he wants to try in order of preference...
[03:17] <superm1> it lists sun-java6, sun-java5, sun java 1.4, etc
[03:18] <superm1> so icedtea | java-virtual-machine should do it
[03:18] <blueyed> superm1: but it's not really versioned, is it? Will take it as such though.
[03:19] <superm1> well icedtea is the only one that doesn't provide java-virtual-machine it looks like
[03:19] <blueyed> I'm also removing the ${shlibs:Depends} which is not needed for java packages, correct?
[03:19] <superm1> so it should cover your bases
[03:20] <RAOF> blueyed: If you'd like this to be backportable, you might want to drop the debhelper dependency (and compat) down to 5, unless you use any of the new behaviour.
[03:20] <blueyed> well, e.g. ant has java-gcj-compat-dev | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime - so it's something different?!
[03:20] <blueyed> RAOF: yes, thanks, forgot about that..
[03:20] <ScottK> Fujitsu: Thanks.
[03:21] <Fujitsu> ScottK: No problem.
[03:21] <ScottK> I figured I was doing enough security work I might as well sign up for the official club.
[03:21] <Fujitsu> Heh.
[03:22] <ScottK> Which reminds me ...
[03:22] <ScottK> jdstrand: How clamav going ...
[03:23] <blueyed> RAOF, superm1: therefore it was correct already I think.. (icedtea-java7-jre | java-virtual-machine, java5-runtime)
[03:23] <superm1> yeah :)
[03:25] <RAOF> Yeah, fair enough.  All the *jre packages provide java5-runtime.
[03:27] <blueyed> icedtea-java7-jre should provide java-virtual-machine though.. this is probably the reasond why gcj gets pulled in for the build..
[03:29] <RAOF> Oh, dear lord licensing sucks.
[03:29] <RAOF> Cosmetic: you may want to put each file on a separate line, and they should be comma-delimited.
[03:30] <blueyed> RAOF: that would make it much longer.. I've probably missed something minor, but heard that it would be ok. Only that all different licenses are important.
[03:30] <RAOF> Also, if the files are uniquely named you don't *have* to use the full path, */name is implied.
[03:31] <blueyed> Yes, I've copied and pasted them.. I should it could not hurt to be explicit there.
[03:32] <RAOF> Yeah.  It's really cosmetic.
[03:32] <LaserJock> RAOF: did you file that licensing bug on tomboy?
[03:33] <RAOF> LaserJock: Yes.
[03:33] <blueyed> bug 189953
[03:33] <ubotu> Launchpad bug 189953 in icedtea-java7 "Inconsistent 'Provides' for different java compilers/runtimes" [Wishlist,Triaged] https://launchpad.net/bugs/189953
[03:33] <LaserJock> RAOF: did you happen to see mjg59's comment in -devel about it?
[03:34] <RAOF> blueyed: But, as I understand it, it's not properly conformant to the proposed machine-readable format unless the lists are comma-delimited.  That's not going to block my advocation at all though.
[03:34] <blueyed> RAOF: I'll check that in the next round of changes.
[03:36] <blueyed> Re-uploaded with compat and shlibs:Depends minor change. I'll have to catch some sleep now..
[03:37] <LaserJock> dang, I may end up with way more Multiverse uploads than anything else for Hardy :/
[03:37] <RAOF_> LaserJock: Sorry, my buildbox is thrashing thanks to jEdit.
[03:38] <jdong> anyone here into blog-ranting about usability related issues?
[03:38] <jdong> I found an amusing one from Leopard's recent update
[03:38] <RAOF_> LaserJock: No, I didn't see the comments, should I?
[03:38] <jdong> http://www.dslreports.com/r0/download/1274378~d987d620159d1c354525056af832b2b1/Picture%201.jpg
[03:38] <jdong> prizes go out to those who explain what that charge status actually means....
[03:38] <RAOF_> jdong: That's *awesome*.
[03:39] <jdong> lol
[03:39] <LaserJock> RAOF_: he just basically said that in his opinion a blanket license is sufficient when it's clear, like there aren't inconsistent licenses
[03:40] <RAOF_> LaserJock: So the licensing is OK, how about copyright holders?  That makes things easier, though.
[03:40] <LaserJock> not sure
[03:41] <LaserJock> but you tend to get different answers depending on which archive admin you talk to ;-)
[03:41] <LaserJock> just thought you might be interested
[03:41] <RAOF_> Oh, certainly.
[03:41] <RAOF_> It seems there's no end to the things you can learn about licensing :)
[03:42] <LaserJock> s/learn/get incredibly, horribly confused/
[03:42] <bddebian> Heh, amen to that
[03:49] <RAOF_> Damn you bugzilla.  Why must you make me work so hard to file bugs?
[03:59] <joejaxx> has anyone here tried using minicom in Gutsy?
[04:01] <superm1> i did
[04:01] <superm1> but i didn't have luck with it when i tried
[04:03] <joejaxx> yeah i had to run minicom -s
[04:03] <joejaxx> and had to change the defaults
[04:03] <dendrobates> joejaxx: I used it sucessfully to connect to a serial console interface on a Sun T2000
[04:06] <tonyyarusso> Thanks to whoever uploaded my kompozer diff - the new version just hit my mirror.  (Meanwhile, I found a LP bug...)
[04:06] <joejaxx> dendrobates: NICE :D
[04:06] <joejaxx> i am trying to reset the password on a Cisco Router :P
[04:06] <joejaxx> with minicom
[04:06] <joejaxx> :P
[04:07] <joejaxx> but i got it to connect now
[05:24] <superm1> hey if another motu wouldn't mind giving this a quick once over: http://revu.tauware.de/details.py?package=libnet-upnp-perl
[06:10] <warp10> Good morning
[06:54] <rhpot1991> revu down for everyone else?
[07:27] <vemon> if motus still have access to revu then could someone check the latest version of whysynth. it's already been advocated a few timces but i've needed to adjust the package due to licensing issues
[07:27] <vemon> the latest version is done according to sistypotys comments
[07:27] <Fujitsu> The machine is alive, but it appears fairly sick.
[07:27]  * Fujitsu wonders if it's out of disk space again.
[07:31]  * RAOF finishes his 2 hour update-miro's-copyright stint.
[07:34] <RAOF> Ha!  I speak too soon :(
[07:42] <LucidFox> slomo, could you please comment on bug #191307?
[07:42] <ubotu> Launchpad bug 191307 in f-spot "f-spot man page missing mono warning" [Undecided,New] https://launchpad.net/bugs/191307
[07:42] <LucidFox> I think it's not a bug, but the submitter sternly disagrees
[07:43] <slomo> LucidFox: it's just that the reporter doesn't like mono?
[07:43] <slomo> or do i miss anything
[07:44] <LucidFox> seems so
[07:44] <slomo> close please
[07:45] <LucidFox> closed
[07:46] <slomo> thanks
[08:01] <dholbach> good morning
[08:56] <gpocentek> Riddell: I've reuploaded wzdftpd, the diff is cleaner
[09:10] <tbutter> revu seems to be broken (timeout)
[09:12] <\sh> yepp
[09:12] <ScottK> slangasek: Are you still up and about perhaps?
[09:12] <ScottK> \sh: Did you see my IRC comment on your Perl packages?
[09:13] <\sh> ScottK, nope...revu is down somehow
[09:13] <ScottK> OK.
[09:13] <ScottK> \sh: It was about debian/copyright.  I think it's better to redistribute on as generous of terms as possible.
[09:14] <norsetto> morning folks and folkettes
[09:14] <\sh> ScottK, you mean that I should explicitly write in debian/copyright that the upstream source could be licensed as GPL or artistic as perl does?
[09:15] <ScottK> \sh: That's what I think would be better.
[09:15] <DktrKranz> norsetto: folkettes? are you hungry? :)
[09:15] <\sh> ScottK, ok...changing it...anything else? I think packaging wise is everything in order
[09:15] <ScottK> \sh: https://launchpad.net/ubuntu/+source/libtree-perl has what I'd consider to be a good example.
[09:15] <norsetto> DktrKranz: neah, just being politically correct (its the gender equality era....)
[09:16] <ScottK> \sh: I only had to to review the diff, not test build so far.  If you can stuff the packages somewhere and give me a .dsc link, I'll give them a final review.
[09:16] <DktrKranz> norsetto: so it's better saying "morning folkettes and folks"
[09:16] <ScottK> \sh: The debian/copyright thing we all that stood out from reviewing the diffs.
[09:16] <ScottK> Good morning norsetto.
[09:17] <DktrKranz> ScottK: congrats!
[09:17] <\sh> ScottK, ok...I'll change the debian/copyright and push some packages on my webserver ...
[09:17] <ScottK> \sh: Thanks.
[09:17] <ScottK> DktrKranz: Thanks
[09:17] <norsetto> ScottK: heck, what do you do here? Don't you have a bed somewhere!?
[09:17] <\sh> ScottK, no thank you :)
[09:18] <ScottK> norsetto: We're having an ice storm here and about 45 minutes ago one of our dogs was stuck out in the back yard (couldn't get up the steps to get back in) and so after a trip out in the cold rain to rescue her, I'm not able to get back to sleep.
[09:19] <norsetto> ScottK: oh, do you know by any chance if it is so bad in minnenapolis too?
[09:19] <ScottK> norsetto: It's February.  You can generally figure it's very cold there. ;-)
[09:20] <ScottK> norsetto: We're far enough away that it's a different weather pattern.  They probably had this precipitation in the form of snow two days ago.
[09:20] <ScottK> norsetto: You aren't coming this way to visit are you?
[09:20] <norsetto> ScottK: My wife is headed there right now
[09:21] <ScottK> norsetto: Ah.  Excellent reason to worry.
[09:21]  * ScottK checks the weather.
[09:24] <ScottK> norsetto: It's cold and snowy, but nothing unusual for Minneapolis.  No severe storms.
[09:24] <norsetto> scottk: ok, thanks, I was hoping to hear that
[09:25] <ScottK> norsetto: What's in Minneapolis?
[09:25] <norsetto> ScottK: a friend of her
[09:26] <ScottK> Ah.  Well they get lots of snow this time of year (I was there last December) and they generally know how to deal with it.
[09:27] <\sh> scottK, please check out http://buildserver.homelinux.net/src/ there are both packages
[09:27] <norsetto> scottk: yeah, they might, I'm not so sure about my wife though, she can hardly drive here and she absolutely wanted to rent a car, oh well....
[09:28] <ScottK> norsetto: One thing they are good at is plowing and salting the streets.
[09:28] <ScottK> \sh: Will do.
[09:29] <ScottK> \sh: If I'm satisfied with them do you want me to just upload them or do you want the pleasure?
[09:29] <\sh> SCottK: well, if you are satisfied, just upload straight away :)
[09:31] <ScottK> Will do.
[09:32] <\sh> and dpkg is fixed, too ... wow
[09:35] <TheMuso> Congrats other -release members.
[09:40]  * ScottK looks to see if that applies to him ..
[09:40] <dholbach> scottK, TheMuso, norsetto, hobbsee (absent), sistpoty (absent): congratulations!
[09:40] <ScottK> dholbach: Thanks.
[09:40] <dholbach> I'll set up the team and send out the mail in a bit
[09:40] <dholbach> need to fix up something else before
[09:41] <norsetto> dholbach: what for? We haven't started already :-)
[09:41] <TheMuso> norsetto: Better to be ready when the flood gates open. :p
[09:41] <ScottK> TheMuso and norsetto: we should probably find a time to conspire on rules.
[09:41] <TheMuso> ScottK: Sounds like a plan.
[09:42]  * norsetto wears his frost-proof hat
[09:42] <TheMuso> ScottK: I'm surprised you are awake actually.
[09:42] <norsetto> errr, where is that link btw?
[09:42] <ScottK> TheMuso: Scroll back about 25 minutes for an explanation.
[09:44] <TheMuso> ScottK: Ah, that sucks.
[09:59] <ScottK> Any MOTU hopeful want to work on a bug fix (I'll provide guidance).  There's a patch, it just needs to be packaged.
[10:00] <isaac> ScottK: what's the package?
[10:00] <ScottK> isaac: https://bugs.launchpad.net/debian/+source/pdns/+bug/191506
[10:00] <ubotu> Launchpad bug 191506 in pdns "TXT records truncated" [Low,In progress]
[10:00] <isaac> not interested :P
[10:00] <ScottK> Feel free to assign it to yourself instead of me if you want to try it.
[10:01] <ScottK> OK
[10:01] <dholbach> bug 125658 might be interesting to work on too - it seems to block the blender folks
[10:01] <ubotu> Launchpad bug 125658 in openexr "please update openexr version" [Wishlist,Triaged] https://launchpad.net/bugs/125658
[10:01] <dholbach> (I realise that openexr is in main, but most of the rdepends that would need to go through a small transition are in universe)
[10:04] <AnAnt> hello
[10:04] <AnAnt> is there something wrong with REVU's website ?
[10:07] <ScottK2> AnAnt: Yes
[10:08] <AnAnt> ScottK2: ok
[10:08] <AnAnt> thanks
[10:08] <AnAnt> I thought something wrong with my connection
[10:09] <\sh> scottK: you mean http://wiki.powerdns.com/cgi-bin/trac.fcgi/changeset?old_path=trunk%2Fpdns%2Fpdns&old=996&new_path=trunk%2Fpdns%2Fpdns&new=996 ?
[10:09] <gaspa> there was been some discussion about sudo policies? ( i'm lookin at bug #191210)
[10:09] <ubotu> Launchpad bug 191210 in sudo "[hardy] exit out of sudo -i doesnt really exit" [Undecided,New] https://launchpad.net/bugs/191210
[10:09] <ScottK> \sh: Yes.  I haven't checked to see if it applies to our current version directly or needs a bit of work.
[10:10] <\sh> scottK: I set it on my todo
[10:10] <ScottK> \sh: Great.  Thanks.
[10:10]  * ScottK is looking at your packages now.
[10:10] <geser> good morning
[10:11] <ScottK2> Good morning geser.
[10:11] <\sh> ScottK, reassigned the bug
[10:11] <ScottK> OK.  Thanks.  \sh: I have someone who runs pdns who will test the package when it's done (if you don't).
[10:12] <AnAnt> hmmm, can anyone tell me where I can get help about makefiles ?
[10:12] <TheMuso> ScottK: Just got my first uplaods to main in, due to a spec I was working on. I felt rather nervous. :)
[10:13] <\sh> scottk: cool :) I think the bug is also annoying pdns users in dapper/edgy/feisty/gutsy...
[10:13] <ScottK> TheMuso: Congratulations.  I haven't done it yet.
[10:13] <ScottK> \sh: I'm not sure if it's SRU worthy or not, but since I'm not in motu-sru, I guess I don't need to have an opinion.
[10:13] <TheMuso> ScottK: We'll see if everybody's boot succeeds first, then congratulations are likely in order. :p
[10:14] <TheMuso> In all seriousness, I tested and re-tested my changes, so there shouldn't be a problem.
[10:14] <\sh> scottk: well, backporting is always an alternative
[10:15] <ScottK> Sure
[10:17] <DktrKranz> \sh, which one?
[10:18] <\sh> DktrKranz, pdns
[10:19] <HighNo> hm, revu is down?
[10:19] <ScottK2> Yes
[10:20] <HighNo> ff tore it apart or is it just 'closed' because of ff?
[10:22] <DktrKranz> \sh, if you mean bug 191506, when you have a patch, we can discuss at it briefly, but it looks a good candidate.
[10:22] <ubotu> Launchpad bug 191506 in pdns "TXT records truncated" [Low,In progress] https://launchpad.net/bugs/191506
[10:22] <ScottK> It was having hard drive troubles yesterday.
[10:23] <HighNo> ouch
[10:24] <Tonio_> dholbach: ping ?
[10:25] <dholbach> Tonio_: pong
[10:26] <Tonio_> dholbach: hey ;) I hope you're doing well
[10:27] <dholbach> Tonio_: thanks, yes I am - how are you?
[10:27] <Tonio_> dholbach: my team membership for ubuntu developpers is expiring in a few days, I'm supposed to ping you to get it renewed :)
[10:27] <Tonio_> dholbach: very well :) currently working on the kde implementation of sudo for kde4, good progress so I'm a happy guy :)
[10:28] <dholbach> Tonio_: let it expire, as long as you're in ubuntu-core-dev and/or motu all is good
[10:28] <dholbach> Tonio_: in the end ubuntu-dev will only consist of ubuntu-core-dev and motu
[10:29] <Tonio_> dholbach: oki ;)
[10:29] <Tonio_> dholbach: true that core-dev is sufficient for everything ;)
[10:40] <TheMuso> /c/c
[10:46]  * pochu waves
[10:47] <Ng> hey pochu :)
[10:47] <Ng> thanks for your msg :)
[10:48] <pochu> Ng: anytime, thanks for the fix!
[10:48]  * pochu hugs Ng 
[10:49] <Ng> I'm going to risk flames from my gf tonight and cut a release. I've fixed all the bugs I can in time, and FF is tomorrow ;)
[10:51] <tjaalton> Ng: I do it all the time ;)
[10:51] <Ng> hehe
[10:52] <tjaalton> speaking of which, I'd like to let the MOTU Release Team to know that I'm about to upload a new version of vdr (1.4.7 -> 1.5.13) soon
[10:52] <tjaalton> and some new plugins too
[10:53] <tjaalton> upstream decided to do a stable release before plunging in the HDTV world, so 1.6.0 should be out in a couple of weeks
[10:53] <theseinfeld> dholbach i think the libdc1394 should be ready for inclussion? what do you think?
[10:53] <tjaalton> and I have upgraded my box with the new packages, works like a charm
[10:53] <theseinfeld> dholbach check it here: http://revu.tauware.de/details.py?package=libdc1394-22 and the compiled PPA here: https://launchpad.net/~libdc1394-dev/+archive
[10:55] <Ng> tjaalton: ace :)
[10:55] <tjaalton> Ng: I should update the spec too
[10:55] <Ng> ugh, and I should apologise for not having been near the spec since UDS :/
[10:56] <tjaalton> me neither, until last week ;)
[10:56] <tjaalton> we should decide the name for the meta-package :)
[10:58] <ScottK2> tjaalton: Do it before Feature Freeze and we don't need to know ;-)
[10:59] <tjaalton> ScottK2: that's what I'm aiming for ;)
[11:00] <theseinfeld> so anybody on MOTU that could advocate the libdc1394-22 package inclussion?
[11:00] <theseinfeld> it is ready, just needs someone to advocate it...
[11:01] <geser> theseinfeld: it is a different package than in Debian unstable?
[11:01] <theseinfeld> yes
[11:01] <theseinfeld> as I am one of the developers, I am closer to the truth
[11:01] <theseinfeld> :D
[11:01] <geser> any reason for being different?
[11:01] <theseinfeld> I have been working with the Debian people
[11:02] <theseinfeld> Stubborness of Debian?
[11:02] <theseinfeld> :D
[11:02] <geser> can't we sync the package from Debian?
[11:02] <theseinfeld> No
[11:02] <theseinfeld> you do that and you get crap
[11:02] <theseinfeld> it is missing things
[11:02] <theseinfeld> it has some problems with the naming
[11:03] <theseinfeld> the debian was lagging alot behind with this library
[11:03] <theseinfeld> i have been trying for one year with them to get them involved and when I got their attention they wanted just to have minor changes and still using the old framework
[11:04] <theseinfeld> you can sync, but you will lose some of the added features
[11:05] <theseinfeld> so, geser, what shall it be
[11:06] <geser> theseinfeld: I was just asking as I've seen it in Debian and we usually take packages directly from them
[11:06] <theseinfeld> I know
[11:06] <pochu> superm1: around?
[11:06] <pochu> superm1: 11:48 <     slomo> pochu: any other changes for -bad? btw, you could tell superm1 that the gst-plugins-bad gmyth plugin doesn't support gmyth 0.7
[11:06] <pochu> superm1: 12:00 <     slomo> pochu: ok, so still... you have 0.7 in hardy and upstream gmyth only works with gmyth >= 0.4 gmyth <= 0.4.99
[11:06] <pochu> superm1: 12:00 <     slomo> pochu: if there's a fix to work with the new version i'll be happy to get it upstream ;)
[11:06] <pochu> superm1: have it worked for you? :)
[11:07] <theseinfeld> geser, the thing with them is that they made clear that us, the developers, should not interfere with the packaging. Something that I find outrageous
[11:07] <slomo> superm1: if it did work with 0.7 for you without any additional changes to what is in cvs that would be great news ;)
[11:07] <theseinfeld> geser they are not on the dev lists and they don't know many of the things that should be included. Now they know, after my lobby, but still insist on some of the things that we didn't agree (like the use of both old API and new one)
[11:08] <theseinfeld> geser we spent quite much effort to make this happen, and the debian just don't want to remove one damn line (conflict: libdc1394-13) :))
[11:08] <pochu> superm1: oh and: 11:45 <     slomo> pochu: iirc the mythtv stuff is not acceptable in Debian (license, patents, no idea)
[11:08] <pochu> superm1: that's bad news :(
[11:08] <theseinfeld> geser, you must agree that i needed a more friendlier environment :)
[11:08] <slomo> pochu, superm1: ok, i tested it with 0.7 now and i get unresolved symbols
[11:09] <theseinfeld> geser so, using ppa and revu was the way to put our dev ideas into packages
[11:10] <geser> theseinfeld: I can understand your pain
[11:10] <geser> theseinfeld: are there any packages in hardy which could use the new lib already?
[11:12] <theseinfeld> geser, not yet. There is coriander, that will come soon...
[11:12] <theseinfeld> thanks geser :)
[11:12] <theseinfeld> I was already comforted by cprov for this :)
[11:13] <slomo> superm1, pochu: nevermind... builds and does not have unresolved symbols if done properly ;)
[11:13] <theseinfeld> so, geser, the coriander is dependent of libdc1394-22 and once it is stable enough for a new release (couple of weeks) I will let you know
[11:13] <geser> theseinfeld: as feature freeze is tomorrow (which includes also no new packages anymore) perhaps also talk to the motu-release team if they give you an exception
[11:13] <theseinfeld> maybe I will do the packaging for them too
[11:14] <slomo> superm1, pochu: OTOH libgmyth-dev or whatever should depend on libmysqlclient-dev stuff (and gst-plugins-bad should not directly build depend on it)
[11:14] <geser> theseinfeld: feature freeze also include new upstream version freeze so it would also need an exception if the new version should get included in hardy
[11:14] <enyc> Hrrm I would like to know why  ZoneMinder package in Ubuntu is 1.22.3 (2006 release) and not 1.23.1 (2008 release) --  I suspcet I need to be asking the question in debian ......
[11:15] <theseinfeld> geser yes, but how can I ask them if so far, this package has not been revu-ed by anybody?
[11:16] <promag> anyone can help me using cbds?
[11:16] <promag> I did make dist on my source package
[11:16] <theseinfeld> promag, what is the problem?
[11:16] <promag> then I extracted it
[11:16] <promag> is this the correct way?
[11:17] <theseinfeld> ye
[11:17] <promag> after extraction I did dh_make -b -createorig
[11:17] <promag> correct again?
[11:18] <theseinfeld> what are you trying to do promag?
[11:18] <theseinfeld> you make dist, get the tar.gz, and then what?
[11:18] <promag> well this is not relative to ubuntu packaging
[11:18] <promag> because the it's a software I'm making
[11:18] <promag> anyway
[11:19] <geser> theseinfeld: try getting the package revued and a FF exception in parallel.
[11:19] <promag> my project is using autotools
[11:19] <promag> after tar zxvf I do dh_make --createorig -b
[11:19] <theseinfeld> cdbs is basically a wrapper for debhelper
[11:19] <promag> then I don't know what to do
[11:19] <theseinfeld> geser how do you get the package reviewed?
[11:20] <geser> theseinfeld: so you don't get dissappointed if you don't get an exception after putting much work into this package and people revuing know it will make it in (normally revuing slows down massively after FF).
[11:20] <geser> theseinfeld: first wait till REVU is up again :)
[11:20] <slomo> pochu, superm1: ok, configure in gst-plugins-bad cvs is adjusted to also work with gmyth 0.7, nevermind ;)
[11:21] <promag> theseinfeld: so what's next dh_make?
[11:21] <pochu> slomo: cool :)
[11:22] <pochu> slomo, superm1: would be cool to get this in Debian too :)
[11:22] <slomo> pochu: if gmyth is in debian i see no problem with adding it to gst-plugins-bad
[11:23] <geser> norsetto, TheMuso, ScottK: First congrats for motu-release and second what's the process to get an FF exception to complete the ongoing ghc6 transition?
[11:23] <slomo> pochu, superm1: it seems to be possible to get it into debian... it's only mythtv that had (has) problems
[11:24] <pochu> slomo: that's great news
[11:24] <ScottK> geser: Thanks.  How about finish by tomorrow?
[11:25] <ScottK> geser: I'd suggest ask for a general FF exception and list the affected packages, but of course the team hasn't had a chance to meet and discuss process yet.
[11:26] <geser> ScottK: till now I've synced the packages in the correct order so they build successfully
[11:27] <geser> ScottK: I could request synced the remaining packages and clear the FTBFS later but this doesn't look clean to me
[11:27] <ScottK> geser: I'd say file one bug with the exception request that also affects the relevant packages and then ask us to look it over.  I'm assuming we'll say yes, but ..
[11:27] <ScottK> Agreed.
[11:28] <ScottK> I was kidding about the finish by tomorrow.
[11:29] <theseinfeld> promag why would you use cdbs if you just want to make dist?
[11:29] <persia> Anyone feel like looking at last-minute merges?  There are currently 17 universe packages with a newer upstream version listed on merges.ubuntu.com that might benefit from attention.
[11:29] <theseinfeld> geser how do I contact the motu-release team? launchpad?
[11:29] <geser> ScottK: what's your opinion for the clamav-data package after FF: should I ask for a general FF exception for it, ask everytime for a new exception, ask for removal from hardy or ignore it?
[11:30] <persia> DktrKranz: Do you have an opinion about aolserver?  I'm tempted to sync all the latest Debian updates and hope we can forget about it, but wouldn't mind your opinion on the matter.
[11:30] <theseinfeld> geser qa.?
[11:30] <ScottK> geser: Ask for a general exception.
[11:30] <cody-somerville> Can someone please review http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin ?
[11:30] <geser> ScottK: last question: should the bug be subscribed or assigned to motu-release?
[11:30] <ScottK> geser: I think clamav-data we should take up until the final freeze.
[11:31] <promag> theseinfeld: well I thought I would need to make dist because dh_make says "The directory name must be <package>-<version> for dh_make to work" in the original source directory
[11:31] <persia> cody-somerville: That URL doesn't load for me.  Have you tried it recently?
[11:31] <ScottK> geser: Last time it was subscribed.  I assume it'll be the same this time.
[11:31] <cody-somerville> hrmph...
[11:31] <geser> theseinfeld: file a bug and subscribe the motu-release team
[11:31] <theseinfeld> ScottK geser so, I submit a bug to motu-release
[11:31] <theseinfeld> geser ok
[11:31] <ScottK> theseinfeld: Why?
[11:31] <cody-somerville> persia: Revu is down the day before FF?
[11:32] <theseinfeld> geser when does revu go up?
[11:32] <theseinfeld> :D
[11:32] <persia> cody-somerville: Last REVU day was 4th February, but this is a coincidental outage.
[11:32] <promag> theseinfeld: for instance https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS explains how to setup the configuration/build files but doesn't mention the required steps t actually build the package
[11:32] <geser> theseinfeld: it depends when the REVU admins fix it (I'm not a REVU admin)
[11:32] <promag> or maybe just maybe I'm dumb
[11:33] <persia> Anyone who can upload: please take a look at the sponsors queues.  There are 24 bugs in the UUS queue that look like package updates: it would be good to accept or reject these today, rather than pushing for Freeze Exceptions.
[11:33] <promag> I would go for the second.. :) so please give me an hint
[11:33] <theseinfeld> promag you just make the debian things ok, then use dpkg-buildpackage
[11:33] <persia> geser: Even REVU Admins can't fix it: needs a local admin at the hosting site :(
[11:34] <sistpoty|work> hi folks
[11:34] <theseinfeld> promag use your Launchpad PPA to submit the source changes
[11:34] <theseinfeld> like  dpkg-buildpackage -S -rfakeroot -sa
[11:34]  * ScottK cheers the arrival of sistpoty|work.
[11:34] <sistpoty|work> ScottK: thanks for sending the note... /me takes a look
[11:34] <norsetto> hi geser
[11:36] <geser> Hi norsetto
[11:37] <promag> theseinfeld: it's a package for course work (we thought giving a package to the teacher would be cool)
[11:37] <theseinfeld> geser persia ScottK how do I submit the bug to go to MOTU-revlease team?
[11:37] <promag> theseinfeld: thank you!
[11:37] <persia> theseinfeld: subscription
[11:37] <promag> I'll try that
[11:38] <theseinfeld> persia: so, Distribution: Ubuntu, Package: my package, where does it go the motu-release team :))?
[11:38] <ScottK> theseinfeld: For a new package it'll need to have significant justification why it can't wait for Hardy +1
[11:39] <tjaalton> sistpoty|work: argh, I found out that the nvidia-settings that the drivers ship write all sort of crap on the xorg.conf.. so, it might be worth it bring back the old version and patch the sources to do the right thing :/
[11:39] <tjaalton> goes around comes around
[11:40] <persia> theseinfeld: Do you not have a needs-packaging bug?  You'd need to follow the freeze-exception process and justify the need for your update in hardy.  If it were a compatible replacement, it would be easy.  As it isn't, the value is somewhat arguable.
[11:40] <sistpoty|work> tjaalton: with my upload (which I guess is still in new), I only disabled the nvidia-settings binary, so I guess you could simply uncomment the binary package in debian/control and have it back
[11:40] <persia> tjaalton: Also, I've now two different launchers without icons :(
[11:40] <tjaalton> persia: two? how's that possible?
[11:41] <tjaalton> persia: the icon thing will be fixed.. the drivers could just ship that and Suggest nvidia-settings..
[11:41] <tjaalton> ..which would ship the desktop file
[11:41] <theseinfeld> hmm
[11:41] <persia> tjaalton: nvidia-settings.desktop + NVIDIA-Settings.desktop (and no, I haven't had nvidia-settings installed for a couple releases now, and neither is a local .desktop, or I'd have an icon)
[11:42] <theseinfeld> https://bugs.edge.launchpad.net/ubuntu/+bug/184834
[11:42] <ubotu> Launchpad bug 184834 in ubuntu "libdc1394 version 2.0.1 (new API version 2)" [Undecided,Fix committed]
[11:42] <theseinfeld> persia: can you call this request for packaging?
[11:42] <tjaalton> sistpoty|work: ok, I can fix that
[11:43] <persia> tjaalton: The icon can be shipped from restricted, but not from universe.  nvidia-settings would need to be repromoted to use the icon (see nvidia's art licensing)
[11:43] <sistpoty|work> tjaalton: excellent, thanks!
[11:43] <tjaalton> persia: right, the drivers would ship it so it shouldn't be a problem
[11:43] <persia> theseinfeld: I'm unable to parse the question.
[11:44] <persia> tjaalton: I'm confused then.  I thought you were going back to the independent nvidia-settings.
[11:44] <tjaalton> persia: the drivers should only ship the .png :)
[11:45] <persia> tjaalton: Ahhhh...  I believe that's a violation of some part of debian policy about icons and menu items, but it has the vast benefit of being legal :)
[11:45] <tjaalton> screw the policy then ;)
[11:45] <theseinfeld> persia, the question was if 184834 bug can be called as "request for packaging"
[11:45] <persia> bug #184834
[11:45] <ubotu> Launchpad bug 184834 in ubuntu "libdc1394 version 2.0.1 (new API version 2)" [Undecided,Fix committed] https://launchpad.net/bugs/184834
[11:46] <TheMuso> persia: What does that break?
[11:46] <persia> theseinfeld: Well, it's certainly not fix committed, or we wouldn't be having the conversation.  Aside from that, you could either tag it "upgrade" in which case it should replace the existing library, or tag it "needs-packaging" in which case it would be a new package (with a correspondingly higher barrier to entry)
[11:47] <persia> TheMuso: Something about menu policy.  I forget exactly, and am too tired to hunt google well (too many leftovers for feature freeze, and no mdt all weekend)
[11:47] <TheMuso> persia: Oh I meant API wise. Never mind, unfortunately my hands are rather full atm.
[11:47] <theseinfeld> persia god dammit is both :)
[11:48] <persia> TheMuso: Wait, are you talking about lib1394 or nvidia-settings?
[11:48] <sistpoty|work> persia, TheMuso: imo it doesn't break anything (for a desktop-file). Menu policy iirc has the requirement of a xpm icon (which we don't really need to care about in Ubuntu, if we've got a desktop file)
[11:48] <persia> theseinfeld: Either you want to replace the existing library, or you want to create a new package.  Both is not usefully feasible.
[11:48] <theseinfeld> persia i changed the status in progress
[11:49] <theseinfeld> I'll go with the new package
[11:49] <TheMuso> persia: No that bug you referred to above, it said it had a new API or some such.
[11:49] <theseinfeld> as it should be new from now
[11:49] <persia> TheMuso: No idea.
[11:49] <persia> theseinfeld: TheMuso may be well qualified to have an opinion.  Please explain.
[11:50] <theseinfeld> TheMuso, basically it is libdc1394 with a new API. The old one can work in parallel with the new one, as there are some packages depending on it, until we get people to move to the new one
[11:50] <\sh> scottK: libfile-flock-perl is updated: http://buildserver.homelinux.net/src/libfile-flock-perl/
[11:50]  * ScottK looks
[11:50] <TheMuso> theseinfeld: What packages does it break?
[11:51] <theseinfeld> TheMuso so we have libdc1394-13 and now libdc1394-22
[11:51] <\sh> scottK: thx
[11:51] <TheMuso> theseinfeld: Whats the source package name?
[11:51] <theseinfeld> TheMuso, don't remember exactly, but ones that have to deal with Firewire camera - like Coriander, libav, etc.
[11:52] <theseinfeld> TheMuso the old one is libdc1394...wait
[11:52] <theseinfeld> let me check
[11:52] <jdstrand> ScottK: clamav is still stuck on dapper (I ask someone about it again)
[11:52] <theseinfeld> old one: Source: libdc1394 TheMuso
[11:52] <TheMuso> theseinfeld: And the new one?
[11:53] <theseinfeld> the new one is libdc1394-22 after a long discussion with Debian guys and agreeing on this convention TheMuso
[11:54] <theseinfeld> TheMuso you can get the new package from the ppa (https://launchpad.net/~libdc1394-dev/+archive)
[11:54] <ScottK> jdstrand: Thanks.
[11:55] <TheMuso> theseinfeld: I don't have an opinion either way.
[11:55] <theseinfeld> TheMuso, I have to go to a meeting now :( sorry... I will get back
[11:55] <theseinfeld> TheMuso, I should be back in 1-1
[12:03] <slytherin> Now that lucene2 builds with icedtea, should I log a bug for moving it to universe?
[12:04] <persia> slytherin: Please do so.
[12:05] <slytherin> persia: Have you finished your review work on netbeans6?
[12:07] <persia> slytherin: We decided to just have "netbeans", and not bother with all the silly version-in-name hassles.  It's in source NEW now (http://launchpadlibrarian.net/11904872/netbeans_6.0.1-0ubuntu1.dsc)
[12:07] <slytherin> persia: Cool. :-)
[12:07] <persia> Once it gets accepted, I'll be filing a removal request for the netbeans5.5 multiverse package.
[12:08] <persia> I haven't looked recently, but I think lucene is one of the last pieces that would keep netbeans in multiverse, so I'd be happy to see it move to universe.
[12:12] <\sh> guys, what to do with this bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428760 when the package is not found in debian until today?
[12:12] <ubotu> Debian bug 428760 in wnpp "ITP: zend-framework -- High quality framework for Web Development" [Wishlist,Open]
[12:13] <persia> \sh: You could file a sync request, but you may well need a freeze exception.  How badly do you want it?
[12:14] <\sh> persia, the package is not even packaged by this guy
[12:14] <\sh> persia, and it's still 13th ;)
[12:14] <\sh> persia, and I have it finished right now :) wanted to upload this to ubuntu
[12:14] <persia> \sh: Not everywhere.
[12:15] <slytherin> persia: done, bug 191536
[12:15] <ubotu> Launchpad bug 191536 in lucene2 "Please move package to universe" [Undecided,New] https://launchpad.net/bugs/191536
[12:15] <persia> \sh: Then upload it.
[12:15] <\sh> persia, well, all timezones I think that means 13th 23:59:59 UTC and yeah, it's badly needed :)
[12:16] <persia> \sh: No, all timezones means UTC+14 through UTC-11.
[12:18] <\sh> yack...
[12:18] <\sh> I think I need to add an lintian.override for this?
[12:18] <\sh> W: zend-framework: executable-not-elf-or-script ./usr/share/php/zend-framework/library/Zend/View/Helper/FormCheckbox.php
[12:20] <bddebian> Heya gang
[12:21] <geser> Hi bddebian
[12:21] <bddebian> Hi geser
[12:22] <persia> bddebian: I've been trying to keep up, but I don't have changelogs handy for any of etw, qonk, or dd2.  I don't suppose you'd be up for filing some more sync requests...
[12:23] <sistpoty|work> hi bddebian
[12:24] <geser> \sh: why is this file executable at all?
[12:25] <bddebian> Hi persia, sistpoty|work
[12:25] <bddebian> persia: Sure
[12:25] <sistpoty|work> REVU is back online
[12:26] <persia> bddebian: Thanks :)  Also, the mdt I was using last night for my catch-up run didn't show NEW packages.  If you know of anything recently uploaded that isn't in Ubuntu yet, syncing those might be good as well.
[12:27] <bddebian> persia: Games wise, or in general?  I've been doing a "few" QA uploads and NMUs these days ;-)
[12:27] <persia> bddebian: Yes.
[12:28] <slytherin> man-di: Just FYI ... I have fixed w3c-dtd-xhtml and lucene2 build in Ubuntu. I believe all the changes except icedtea build dependency are suitable for adoption in Debian.
[12:28] <persia> bddebian: Actually, only "New Feature", "New Upstream", and "New Package" stop tomorrow.  Most of the QA stuff can be pulled a little later.
[12:29] <persia> I just saw your name on three .changes in my mail queue today, and you appeared before I got around to digging up the changelogs to request syncs.
[12:29] <geser> has somebody what to do with ingimp? it has currently unmetdeps and a sync could fix it but I found now Debian bug #432765. ingimp includes a whole copy of gimp :(
[12:29] <ubotu> Debian bug 432765 in ingimp "ingimp: Cannot be included in Lenny" [Serious,Open] http://bugs.debian.org/432765
[12:30] <bddebian> Ugh, that's hideous
[12:30] <persia> Erm.  Hacksaw patch time?
[12:30] <bddebian> persia: OK.  Well I hope to have a new upstream of lordsawar today ;-)
[12:30] <man-di> slytherin: in debian it builds fine also
[12:30] <jdstrand> ScottK: something goofy is happening on the security buildd, so I just pushed out clamav for feisty and gutsy since they were done
[12:31] <jdstrand> it'll hit the mirrors in a couple hours
[12:33] <sistpoty|work> jdstrand: out of interest, do the security buildds have the new kernel installed, but not yet rebooted? (s.th. goofy happened to sparky under that situation, but it might as well be a hw failure)
[12:33] <sistpoty|work> (as in kernel w. the vm_splice thingy)
[12:34]  * persia cheers bddebian's ceaseless energy and massive improvements to the distribution
[12:41] <slytherin> man-di: Yes, they have disabled the unit tests that was causing problem. :-)
[12:41] <tbutter> anyone would like to give http://revu.tauware.de/details.py?package=jodviewer a review?
[12:44] <promag> theseinfeld: great it works!
[12:44] <bddebian> persia: Heh, thanks but I've felt soo disconnected from Ubuntu lately :-(
[12:45] <persia> bddebian: You've been doing wonderful things.  That others have been playing "chase the merge" to keep up only indicates how much :)
[12:46] <vemon> persia, hi! i uploaded yet a new version of whysynth
[12:47] <vemon> persia, it's modified according to sistpoty's comments about the licensing
[12:47] <vemon> http://revu.tauware.de/details.py?package=whysynth
[12:47] <persia> vemon: Excellent.  I'm not going to have time to look at it again before feature-freeze, but maybe you can find some other advocates?
[12:47] <vemon> i'd be grateful if other motu's would care to take alook at it also
[12:47] <jdstrand> sistpoty|work: not goofy in the sense you are thinking.  it seems it isn't handling updated translations introduced in the dapper clamav update quite right
[12:48] <sistpoty|work> jdstrand: ah, thanks.. then sparky must have been bitten by a HW failure ;)
[12:48] <persia> sistpoty|work: I'm also curious why adjusting an orig.tar.gz as directed by upstream with a get-orig-source rule is considered inappropriate.  I would have thought that putting the relevant documentation for the repack in README.Debian-source was sufficient.
[12:49] <sistpoty|work> persia: because you cannot change licensing as maintainer, or at least shouldn't do this under any circumstances.
[12:50] <persia> sistpoty|work: Even when upstream specifically instructs you to do so, and provides a patch?  Hmm.  OK.
[12:50] <sistpoty|work> persia: then upstream could easily produce a new release
[12:51] <persia> sistpoty|work: I'd agree with that, but upstream didn't feel like it.
[12:51]  * persia points at http://revu.ubuntuwire.com/revu1-incoming/whysynth-0802122140/whysynth-20070418/debian/README.Debian-source
[12:52] <bddebian> persia: Do you happen to know if stormbaancoureur already got synced?
[12:52] <persia> bddebian: Yep.  Just pushed it last night.
[12:52] <bddebian> Ah excellent, thanks
[12:53] <geser> bddebian: Published in hardy-release 1 hour ago
[12:53] <bddebian> Damn you guys are goood :-)
[12:53] <persia> bddebian: You can see my sync list from the top of https://launchpad.net/~persia/+packages.  Please hit anything I missed :)
[12:54] <persia> Also, did you ever find a good solution for newpki-client?  That didn't seem to be an available sync candidate, and still needs a rebuild or a drop.
[12:55] <bddebian> persia: I have a patch on BTS and the maintainer mailed me saying he couldn't apply it but I told him it was probably a cr/lf issue and I never heard back from him :-(
[12:56] <persia> bddebian: OK.  I suspect we can get a FF exception to remove cruft, so I'll chase that next week.  Thanks.
[13:00] <persia> jdong: Have you looked at the new Debian azureus?  Should it be updated?
[13:00] <persia> Anybody use wifi-radar, and want to look at the new upstream in Debian?
[13:01] <rexbron> persia, the only thing I can think of is that we would need to transition the libraries for anything that depends on libopenexr
[13:01] <persia> rexbron: That might be a big transition.  Have you investigated it, and done test builds with the rdepends?
[13:02] <rexbron> persia, not as of yet
[13:03] <persia> rexbron: That ought be a first step before considering an update of a library at this point.  If you can test everything in the next few hours, it might be worth looking at a sync.  Otherwise, it might not be appropriate for hardy inclusion.
[13:03] <rexbron> persia, hmm.... kdelibs depends on openexr
[13:04] <persia> That makes it even more unlikely.  Sounds like a hardy+1 feature.
[13:04] <jdong> persia: it can't be updated, swt-gtk 3.3 is needed, which we pull from eclipse (>= 3.3) while Debian pulls from a separate swt-gtk package
[13:04] <persia> jdong: Ah.  As long as you've looked, I'll drop it from my list :)
[13:04] <jdong> ok :)
[13:05] <jdong> I mean, I'd LOVE to have Azureus updated, but Eclipse 3.3 just isn't happening
[13:05]  * persia declares grab-merge to be pointlessly slow and goes back to the nice fast manual process.
[13:09] <LucidFox> jdong, could you please re-advocate tovid?
[13:09] <slytherin> is anyone getting crashes in javaws binaries from Sun JDK? I am getting this error - java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
[13:12] <dcordero> hi
[13:13] <persia> slytherin: That's a known bug in Sun Java.
[13:14] <persia> There is an environment variable that is supposed to help, and there is a sed script which when run against the binaries is supposed to help.
[13:14] <slytherin> persia: any links?
[13:14] <slytherin> I am unable to launch any JNLP based applications
[13:15] <persia> slytherin: bug #87947
[13:15] <ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
[13:24] <slytherin> persia: thanks. I am using the environment variable workaround.
[13:25] <jdong> LucidFox: looking
[13:27] <nixternal> mornin'
[13:28] <frafu> Hello, mousetweaks for the hppa architecture is given as pending in the hardy heron build: https://edge.launchpad.net/ubuntu/hardy/+builds?build_text=mousetweaks&build_state=all  Does that mean that it is waiting to be built?
[13:29] <nixternal> frafu: that's correct
[13:29] <geser> frafu: yes, it's in the build queue and waiting for it's turn
[13:29] <geser> hi nixternal
[13:29] <nixternal> howdy geser
[13:31] <jdong> LucidFox: tovid advocated
[13:31] <LucidFox> Thanks!
[13:31] <jdong> :)
[13:31] <jdong> go tovid :D
[13:32] <jdong> LucidFox: have you told upstream about it yet? They'd be quite happy
[13:32] <jdong> they came here two release cycles or so ago wondering how to package for Ubuntu
[13:32] <LucidFox> Ah.
[13:32] <LucidFox> Okay, I'll tell upstream.
[13:33] <LucidFox> As well as suggest to them some of my patches.
[13:33] <rexbron> hey, I have subscribed u-u-s to a bugreport with a debdiff attached, is there anything more to do? bug 191546
[13:33] <ubotu> Launchpad bug 191546 in ilmbase "libilmbase-dev should conflict with libopenexr-dev (<< 1.6.1)" [Undecided,In progress] https://launchpad.net/bugs/191546
[13:33] <frafu> And what does "Build for superseded Source" mean? That night a more recent version is also in the build queue?
[13:35] <frafu> s/night/
[13:35] <jdong> frafu: correct
[13:35] <geser> rexbron: why did you change the standards-version and why didn't you mention it in the changelog?
[13:36] <frafu> Thanks to all for the confirmations
[13:36] <jdong> lifeless: poke; why isn't bzr 1.1 in Hardy?
[13:36] <rexbron> geser, sorry, forgot to mention that. I did it as the debian maintainer had added Homepage: and Vcs-Bzr: which iirc were introduced in 7.2.3
[13:37] <rexbron> (or have I got the verson numbers wrong?)
[13:38] <rexbron> 3.7.3 rather
[13:38] <geser> rexbron: the debdiff has it right, could you a comment that you changed it any why to the changelog (the reason will be helpful to understand the change in the next merge)?
[13:38] <rexbron> geser, sure
[13:43] <rexbron> geser, fixed
[13:47] <bddebian> persia: OK, sync requests in for etw, qonk, and dd2.  I'll do another lordsawar one shortly
[13:51] <persia> bddebian: Excellent.  Thanks.
[13:54] <\sh> guys, does anyone know a tool (not ooffice impress) which could convert powerpoint files into flv/swf? (good if this doesn't need wine and it should run on the cli)
[13:57] <\sh> scottK: still not sleeping? :)
[13:58] <jdong> \sh: why, out of curiousity, not ooimpress?
[13:58] <\sh> jdong, because I don't want to have a Xnest or Xlibs at all on a server
[13:59] <jdong> \sh: ah, ok :)
[13:59] <jdong> \sh: so you're trying to make a clone of http://www.fileformat.info/convert/doc/ppt2swf.htm
[13:59] <rexbron> Ok, updated the debdiff on ilmbase. bug 191546
[13:59] <ubotu> Launchpad bug 191546 in ilmbase "libilmbase-dev should conflict with libopenexr-dev (<< 1.6.1)" [Undecided,In progress] https://launchpad.net/bugs/191546
[13:59] <\sh> jdong, and because ooimpress converts the ppt to swf with keystrokes..so nothing for having it in a video presentation
[14:00] <jdong> \sh: maybe take a closer look at http://www.artofsolving.com/opensource/jodconverter?
[14:00] <jdong> though I have a feeling it's using the Java API for OOo
[14:00] <jdong> and hence useless
[14:01] <\sh> well...nothing really useful I think...
[14:02] <\sh> the other alternative is to present a customer with a commercial plugin for powerpoint...
[14:03] <persia> so...  the sponsors queue has a bunch of stuff that needs to get accepted or rejected before feature-freeze.  Please take a look at http://launchpad.net/~ubuntu-universe-sponsors/+bugs
[14:03] <asantoni> :)
[14:04]  * jpatrick wishs he had more time
[14:04] <CarlFK> shouldn't there be a libusb meta package that points to the current version of  http://packages.ubuntu.com/hardy/libs/libusb-0.1-4
[14:04] <mruiz> morning all
[14:05] <tbutter> \sh: keynote on the mac
[14:05] <tbutter> \sh: or use a java applet to present an odp ;)
[14:06] <mruiz> \sh, lintian & linda without errors ... thanks ;-)
[14:06] <\sh> tbutter, nothing really useful for webtv ;)
[14:06] <\sh> mruiz, :)
[14:07] <tbutter> does webtv support MHP?
[14:08] <rexbron> CarlFK, it would be better to do it via a Provides: field in debian/controls
[14:09] <_MMA_> siretart: PM when you are around.
[14:10] <CarlFK> rexbron: should I put that in a launchpad ticket?
[14:10] <rexbron> CarlFK, filing bugs is always a good way of keeping track of problems
[14:11] <\sh> sistpoty|work, i found a bug in revu , while recovering passwords ;)
[14:11] <sistpoty|work> \sh: what's the problem?
[14:11] <\sh> sistpoty|work, the recover source doesn't use the main key, but the signature key, which is wrong ;)
[14:11] <\sh> s/signature key/subkey for signing/
[14:11] <\sh> gpg: encrypted with 1024-bit RSA key, ID E4967E90, created 2007-10-14
[14:11] <\sh>       "Stephan Hermann <sh@sourcecode.de>"
[14:12] <sistpoty|work> \sh: ugh... never touched that one yet... can you file a bug please?
[14:12] <\sh> sistpoty|work, which is my subkey for signing
[14:12] <\sh> sistpoty|work, yepp
[14:12] <sistpoty|work> thanks!
[14:12] <vemon> sistypoty|work, could it be possible for you to re-ckec whysynth with the new debian/copyright?
[14:13] <vemon> i modified the package according to your comments
[14:13] <vemon> re-check
[14:15] <sistpoty|work> vemon: sorry, not from work (though the copyright file looks great now, thanks!)
[14:17] <\sh> sistpoty|work, oh well...
[14:18] <\sh> pub  1024D/C098EFA8  created: 2005-03-20  expires: never       usage: SC
[14:18] <\sh>                      trust: ultimate      validity: ultimate
[14:18] <\sh> sub  1024g/31A7EF3B  created: 2005-03-20  expires: never       usage: E
[14:18] <\sh> sub  1024R/5D12B6BA  created: 2007-10-14  expires: never       usage: S
[14:18] <\sh> sub  1024R/E4967E90  created: 2007-10-14  expires: never       usage: E
[14:19] <theseinfeld> promag glad to help
[14:21] <promag> theseinfeld: thanks! do know a good place to learn more? for newbies like me...
[14:22] <promag> theseinfeld: also, it's normal to add debian/* to EXTRA_DIST?
[14:22] <promag> or atleast some of them?
[14:22] <theseinfeld> promag don't add that to EXTRA_DIST
[14:22] <promag> don't add at all?
[14:23] <\sh> sistpoty|work, it's not actually wrong...
[14:24] <sistpoty|work> \sh: heh, actually I wouldn't also know which of the two elgamal keys should get selected then
[14:25] <promag> theseinfeld: so I always need to update the debian/* files?
[14:26] <dendrobates> anyone that would like to take a look at likewise-open it is in my ppa https://launchpad.net/~dendrobates/+archive
[14:26] <dendrobates> You need an AD server for it ot be of any use, of course.
[14:26] <dendrobates> It's also currently in the queue waiting for an AA to approve it.
[14:30] <\sh> sistpoty|work, the problem is just that, that working on remote, having the smartcard reader here at my company...is worse for decrypting then :)
[14:30] <\sh> zend-framework uploaded...
[14:30] <\sh> send mail to this debian guy
[14:30] <theseinfeld> promag debian folder is for packaging, the rest of the project is another thing
[14:30] <sistpoty|work> \sh: seems like you've got a typo on your from field in the mail
[14:30] <theseinfeld> if you do the packaging, you add the debian thing
[14:31] <theseinfeld> if you do the real code, you use autotools promag
[14:31] <theseinfeld> quite straight forward
[14:31] <\sh> sistpoty|work, yes ;)
[14:31] <\sh> sistpoty|work, I saw that now too :(
[14:31] <sistpoty|work> \sh: sure... but I don't really see a solution to that problem... however I'm absolutely no gpg expert :(
[14:31]  * \sh is old, can't even write his own name
[14:31] <sistpoty|work> heh
[14:32] <theseinfeld> TheMuso, me is back :)
[14:32] <promag> theseinfeld: so cdbs will determine dependencies, changelog, etc etc from autotools project files?
[14:32] <TheMuso> theseinfeld: Well I'm about to go to bed I'm sorry.
[14:32] <theseinfeld> TheMuso see you tomorrow...
[14:32] <theseinfeld> promag no
[14:33] <theseinfeld> promag debian folder contains the way you do the packaging that include the cdbs scripts that are aiding you in making clearer debhelper calls
[14:33] <theseinfeld> promag and you don't need to use debian to install the thing
[14:36] <promag> theseinfeld: but I want to provide a package, not the source for other to build it
[14:37] <promag> theseinfeld: I don't want to provide a source package
[14:37] <theseinfeld> promag, then you just build the packages with dpkg-buildpackage and give them the binaries
[14:38] <theseinfeld> so, you don't need to do make dist in source
[14:38] <theseinfeld> you just add the debian folder with the proper files
[14:39] <theseinfeld> you need dh-make lintian linda pbuilder cdbs devscripts ubuntu-dev-tools, promag
[14:39] <promag> and these files can be versioned with svn?
[14:39] <theseinfeld> promag you can use pbuilder
[14:41] <theseinfeld> promag have to go now
[14:41] <theseinfeld> promag cheers
[14:47] <durapraxis> Hi, everyone. Can anyone point me on a clear howto for signing a package of my own to put on an internal repository and have other machines doing apt-get from it without having authentication warnings (i.e. doing the authentication correctly)
[14:49] <sistpoty|work> durapraxis: not too sure... maybe the docs of mini-dinstall might contain a howto
[14:52] <dholbach> congratulations LucidFox :-)
[14:52] <LucidFox> dholbach> heh, thanks!
[14:53] <dendrobates> dholbach: I would be honored if you would take a look at likewise-open.  Soren, mathiaz and zul have already looked at it, but it is a hairy package, so the more eyes the better.
[14:54] <dendrobates> dholbach: https://launchpad.net/~dendrobates/+archive
[14:54] <dholbach> dendrobates: I'm a bit busy right now, I'll add it to my TODO list but wouldn't mind if somebody else checked it out in the meantime
[14:57] <dholbach> LucidFox: welcome - you're member of the team now :)
[14:58] <LucidFox> Sweet!
[14:58] <mruiz> congrats LucidFox !
[14:58] <LucidFox> May I join u-u-s right away, or do I need a separate approval for that?
[14:59] <persia> LucidFox: You need a second approval, but it's typically easily granted.
[14:59] <dholbach> I'm very happy with that
[15:02] <nixternal> LucidFox: congrats! sorry I didn't respond sooner, but I was totally used to only responding if I was included :)  getting used to the new job still :)
[15:07] <mruiz> hi DktrKranz ... I uploaded a new revision ;-) . Thanks for your comments
[15:07] <DktrKranz> mruiz: nice!
[15:08] <DktrKranz> mruiz: it should be ok, now
[15:08] <mruiz> DktrKranz, I hope so ...
[15:15] <\sh> bah
[15:15] <\sh> mssql db backup is fcking broken
[15:19] <soren> \sh: I'm shocked!
[15:20] <\sh> soren, just for the record...I'm switching to ubuntu, and I need the data from old mssqls :(
[15:21] <soren> \sh: Oh.
[15:22] <\sh> soren, again thx for the dpkg upload :)
[15:22] <soren> No worries :)
[15:26] <homer> is there any way to sense a user's locale?
[15:26] <homer> eg en-US
[15:27] <geser> homer: what are you trying to do?
[15:28] <homer> I need to know a user's locale in order to download locale specific files from the net
[15:28] <persia> homer: Often you can collect it from the user's environment variables.
[15:28] <geser> homer: see the locale output
[15:29] <homer> awesome, thanks
[15:29] <LucidFox> Hmm. I recently filed a sync request for subtitleeditor, after which it FTBFS, despite building successfully in Hardy PPA
[15:30] <geser> homer: pick the correct env variable you need
[15:30] <slytherin> LucidFox: What is build error?
[15:30] <LucidFox> oh, wait... the build process seems to have been rerun, and now it did build
[15:31] <persia> LucidFox: The PPAs don't quite match the production archives, although they are very, very close.
[15:31] <geser> LucidFox: that happens sometime when hardy changes between filing the sync request and the sync itself
[15:31] <LucidFox> the original error was something like: dpkg-gencontrol: cannot parse '-'
[15:31] <LucidFox> but as I mentioned, now it's been resolved
[15:32] <geser> LucidFox: transient error in dpkg breaking pkg-create-dbgsym, already fixed
[15:32] <persia> LucidFox: That might have been timing: there was a dpkg oddity recently.
[15:33] <homer>  locale | grep LANG= | sed s/^LANG=//g | sed s/.UTF-8$//g
[15:33] <geser> LucidFox: and subtitleeditor build successfully now
[15:33] <slytherin> I was just wondering that when new release of gstreamer0.10-plugins-bad comes out will it need FFE. It will contain the VCD plugin which was not ported until now to GST 0.10
[15:33] <homer> that works :)
[15:33] <LucidFox> yes, it did
[15:33] <persia> slytherin: Any new upstream requires FFE.
[15:34] <persia> superm1: I'm reminded: did you have any luck getting gst-plugins-bad to build the wildmidi plugin, or should I be chasing that if I want it?
[15:34] <LucidFox> just performed my first sponsor upload, by the way
[15:35] <geser> homer: echo ${LANG%.UTF-8} is shorter
[15:36] <homer> damn I got rid of one of my sed's and you go and get rid of the whole statement :o
[15:36] <homer> thanks geser
[15:36] <geser> homer: another hint: some people might still be using something like de_DE.ISO-8859-15
[15:36] <homer> true
[15:36] <homer> I am no good at regular expressions though, I am trying to figure out which one will match anything after the period
[15:42] <slytherin> Is anyone interested in bringing thoggen latest version in Ubuntu real fast? If so then I will file a needs-packaging bug. Else I will wait for Debian to package it and file a FFE
[15:44] <jdong> slytherin: real fast as in within 15 hours? :D
[15:45] <Kano> hi, could somebody update em8300 package? current version from sid will do
[15:45] <jdong> is there a sync request on launchpad yet?
[15:46] <Kano> only .4 compiles with 2.6.24, so .3 is useless
[15:46] <persia> Kano, it needs a sync request with the updated changelog from Debian and a bit of testing.  Unfortunately, my card is not in my current workstation, so I couldn't do the second part.  Would you mind filing the bug?
[15:47] <Kano> persia: please test it yourself.i do not own the card myself anymore.
[15:47] <sistpoty|work> slomo: did you have a chance to look at the sync request for boo yet (bug #191394)?
[15:47] <ubotu> Launchpad bug 191394 in boo "please sync boo (0.8.0.2730-5) from unstable to universe" [Wishlist,Incomplete] https://launchpad.net/bugs/191394
[15:47] <persia> Kano: I won't have time before the new upstream deadline :(
[15:47] <homer> geser, hah! found one that works :)  echo ${LANG%%.*}
[15:48] <Kano> persia: update it now before you forget it...
[15:48] <persia> Anyone have an em8300 card to test the new upstream?  The current version is apparently useless for us.
[15:48] <slomo> sistpoty|work: let's get it ;)
[15:48] <sistpoty|work> slomo: :)
[15:49] <sistpoty|work> slomo: can you subscribe ubuntu-archive and set it to confirmed (don't have credentials here right now... otherwise I'll do it once I'm home)
[15:49] <jdong> persia: if it's useless then I dont think much testing is required other than install the module doesn't explode your computer
[15:49] <slomo> sistpoty|work: already done
[15:49] <persia> pochu: You beat me by seconds: remember to unsubscribe UUS before the ACK to avoid collisions :)
[15:49] <sistpoty|work> slomo: thanks!
[15:49] <pochu> persia: ah, I'm the fastest! ;-)
[15:50]  * pochu wins
[15:50] <Kano> persia: i tested that it compiles fine
[15:50] <jdong> pochu: you know, from my personal experience, that's not ALWAYS a good thing ;-)
[15:50] <jdong> (kidding)
[15:50] <persia> jdong: Sure, but if .4 doesn't work with our kernel, it's better to fix it and get an FFe later, rather than doing a sync now and forgetting about it.  That's why I won't sync untested.  Maybe you have different guidelines?
[15:51] <jdong> persia: I thought it would be easier to get fixes to .4 to make it work after FFe than to realize we need .4 after the fact and go through a FFe
[15:52] <persia> jdong: I've never had an issue with an FFe that would otherwise qualify for a UVF.  Feel free to sync if you like :)
[15:52] <jdong> persia: haha with that said I'm scared to be on the blame trail ;-)
[15:52] <persia> !jdong
 jdong: yes, but you're FULL OF CRACK!
[15:53] <persia> See, no change involved :)
[15:55] <Kano> ntfs-3g is still outdated btw..
[15:56] <Kano> even sid has the new version
[15:56] <pochu> woha 5/5 in the MC call
[15:57]  * pochu hugs *his* MC ;)
[15:57] <\sh> siretart, ping mplayer...would you kill me if I say, that mplayer-skins should be moved from Depends to Suggests?
[15:57] <\sh> siretart, just because on a server, you can use mplayer to generate small thumbnails from videos and you don't need mplayer-skins at all ;)
[15:57] <DktrKranz> mruiz: mnemosyne is on its way to the archives :)
[15:58] <mruiz> thanks DktrKranz ... I learned many things during your sponsoring :-)
[15:58] <DktrKranz> mruiz: now it's time to learn quilt, then!
[15:59] <mruiz> DktrKranz, I'll do
[16:01]  * DktrKranz used to hate quilt, but he quicly changed his mind when he really used it
[16:02] <persia> quilt is very powerful, but awkwardly documented
[16:03] <nixternal> very awkwardly I might add
[16:03]  * bddebian thirds that
[16:03] <DktrKranz> persia: that's why I like it, you have to fight against it, and when you win, you rule the world! :)
[16:03] <nixternal> we are using it for the kde 4 apps, and it tends to confuse the hell out of me at times, causing me to go old school on it :)
[16:03] <nixternal> hahaha, I guess I just give up easily on it...god I am a loser :p
[16:04] <DktrKranz> nixternal: I always forget to export QUILT_PATCHES=debian/patches, *always*
[16:05] <nixternal> I believe we have that set in our cdbs file we use for kde4 apps, so I get lucky there :)
[16:05] <DktrKranz> rexbron: oh, you beat me!
[16:06] <DktrKranz> rexbron: erm... sorry.
[16:06] <rexbron> DktrKranz, :P
[16:06] <DktrKranz> nixternal: it was you to beat me :)
[16:07] <DktrKranz> rexbron: the real issue was related to bug 191546, does it happens during gutsy -> hardy upgrade?
[16:07] <ubotu> Launchpad bug 191546 in ilmbase "libilmbase-dev should conflict with libopenexr-dev (<< 1.6.1)" [Undecided,In progress] https://launchpad.net/bugs/191546
[16:07]  * persia likes seeing race conditions in sponsoring, and encourages more.  First person to get 50 sponsored bugs between now and FeatureFreeze wins.
[16:08] <DktrKranz> persia: do SRUs count?
[16:08] <persia> DktrKranz: If they are sponsored :)
[16:09] <rexbron> DktrKranz, That will fix a potential upgrade breakage when we transition to openEXR 1.6.1. It is too late in the cycle to make such a disruptive change.
[16:10] <Kano> persia: did you add em8300-headers to mplayer to use it with it?
[16:11] <rhpot1991_laptop> is revu still broken?
[16:11] <persia> Kano: Nope.  I'm not an mplayer person.
[16:11] <Kano> persia: without it is hard to test em8300...
[16:11] <sistpoty|work> rhpot1991_laptop: no, it's broken *again*... (and my guess is that sparky's hardware starts to die of age :/)
[16:11] <persia> Kano: Depends on how you use the card...  Anyway, it's not in my current workstation, and I'm doing other things.  Better to ask someone else.
[16:12] <rhpot1991_laptop> sistpoty|work: what do I do about getting my changes up there and reviewed then, just wait?
[16:12] <slytherin> jdong: yes, by 'real fast' I meant before FF. :-D
[16:12] <Kano> well: minimally update the package
[16:12] <DktrKranz> rexbron: potential? Do you mean Hardy is not affected at the moment, but Hardy + 1 will?
[16:12] <rhpot1991_laptop> sistpoty|work: it starting failing while I was uploading a change last night and I haven't seen it back since
[16:12] <Kano> nobody can even try to use it that way
[16:13] <sistpoty|work> rhpot1991_laptop: I'll walk down to the server room in a few minutes and reboot that thing... So I guess you just cross fingers that it will stay up alive longer then ;)
[16:13] <rhpot1991_laptop> heh, ok
[16:13] <rhpot1991_laptop> thanks :)
[16:13] <rexbron> DktrKranz, it affects hardy but only if one tries to install libilmbase-dev . What has happened with openEXR is the latest upstream source has moved from one tarball to several tarballs
[16:14] <rexbron> ilmbase has been synced from debian unstable, but only the new openEXR needs it. openEXR 1.6.1 has not been synced from debian experimental for the reason above
[16:16] <slytherin> jdong: FYI ... It was updated in Debian by slomo, so you will have to wait only few hours. :-)
[16:17] <geser> persia: I've updated http://members.ping.de/~mb/universe-versionslist.html in case you want to overflow the archive-admin queue :)
[16:17] <persia> Could someone else please look at the drupal5 merge?  I'm not sure I understand the new upstream well enough to be sure if we still want those changes.  (emgent)
[16:18] <persia> geser: I'm planning to sleep tonight.  I'm chasing a few more merges, but I'm not sure how much more I'll get done.
[16:18] <jdong> slytherin: what luck :)
[16:18] <DktrKranz> rexbron: I see now. My main doubt is if a universe package can Conflict/Replace a main one
[16:18] <persia> geser: I don't suppose you could populate http://members.ping.de/~mb/universe-versionslist.html#notinB: that's probably one of the more interesting targets.
[16:19] <emgent> persia, ok just a moment :)
[16:19]  * persia encourages people to check http://members.ping.de/~mb/universe-versionslist.html#outdatedinB and review anything that has a new upstream.
[16:19] <geser> persia: I'll try
[16:19] <persia> geser: Thanks.
[16:19] <persia> emgent: Great!
[16:19] <geser> persia: how much night it left for you before the morning comes?
[16:20] <rexbron> DktrKranz, I don't see why not. As it stands right now, it is broken. You must uninstall libopenexr-dev before you can install libilmbase-dev
[16:20] <persia> geser: My alarm goes off in 4 hours, and I skipped last night.  I'm not around much longer.
[16:20] <geser> ouch
[16:20] <emgent> debian #464876
[16:20] <ubotu> Debian bug 464876 in drupal5 "drupal5: New upstream version 5.7 available, fixes several bugs" [Normal,Fixed] http://bugs.debian.org/464876
[16:20] <persia> If you get a solution, I'll see it in backscroll, and submit inclusion requests.  If you get a solution and want to file inclusion requests for useful things not previously removed from Ubuntu, that'd be even better.
[16:21] <persia> emgent: Exactly.  We want that, but it needs to get merged in the next few hours.
[16:21] <emgent> persia, for me in hardy we can sync
[16:21]  * slytherin suggests geser to add persia's location in the new shiny clock applet to track his time zone. :-)
[16:21] <persia> emgent: If you're sure, please file the sync request (it's your merge).
[16:22] <emgent> wait i'm re-see debian patch :)
[16:23] <persia> emgent: If it's not a clean sync, please file the merge bug and subscribe the sponsors.  There are extra sponsors helping to get new upstreams in right now.
[16:23] <emgent> persia, sure thanks
[16:24] <soren> persia: The kvm bits of https://bugs.edge.launchpad.net/ubuntu/+source/qemu/+bug/156085 are assigned to you... Not sure how to interpret that.
[16:24] <ubotu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed]
[16:24] <Kano> well isomaster should be updated too
[16:25] <Kano> iceape
[16:26] <persia> soren: Note that the bits assigned to me a supposedly "Fix Released".  That's the result of me sponsoring TJ's work so that you can ask me about it rather than hunting TJ.
[16:27] <persia> soren: If I remember correctly, https://bugs.edge.launchpad.net/ubuntu/+source/qemu/+bug/156085/comments/10 was the debdiff I uploaded (which apparently didn't fix it hard enough).
[16:27] <ubotu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed]
[16:28] <persia> Err.  https://bugs.edge.launchpad.net/ubuntu/+source/qemu/+bug/156085/comments/8 rather (same patch, different package).
[16:31] <soren> persia: Ok. Thanks.
[16:31] <persia> soren: From you asking, I'm assuming it shouldn't be "Fix Released"?
[16:31] <soren> persia: Right.
[16:32] <sistpoty|work> rhpot1991_laptop: revu is back
[16:32]  * persia updates, and unassigns to reflect reality
[16:32] <soren> persia: Lovely. Thanks.
[16:32] <rhpot1991_laptop> thanks sistpoty|work
[16:32] <sistpoty|work> sorry for the inconvenience
[16:33] <persia> soren: https://bugs.launchpad.net/ubuntu/hardy/+source/kvm/+bug/156085 is open for your assault :)
[16:33] <ubotu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed]
[16:33] <soren> "Yay"
[16:34] <pochu> Does anyone know of a good application to screencast your own desktop?
[16:34] <mgunes> hi all, anyone know why freeloader was removed from Hardy? the changelog and Soyuz page do not indicate any reason, and I can't find a relevant bug to the removal.
[16:36] <\sh> pochu: ask MacSlow (Mirko Mueller)
[16:36] <pochu> istanbul - Desktop session recorder producing Ogg Theora video
[16:36] <pochu> \sh: that looks good, will try it :)
[16:37] <pochu> mgunes: maybe it was removed from Debian?
[16:37] <\sh> pochu: hmm...:)
[16:37] <pochu> \sh: I was using deskscribe and when I finished I realized it just recorded the mouse movements o.O
[16:38] <pochu> \sh: well I think it did that. I'm not sure as when I tried ot open the log (4kB) it crashed :P
[16:39] <mgunes> pochu, it wasn't in the list of orphaned packages but indeed seems gone from Sid, with no indication why
[16:39] <mruiz> hey LucidFox ... I have uploaded the diff.gz to the bug 186397. I attached the interdiff only
[16:39] <ubotu> Launchpad bug 186397 in gpredict "Please add Gpredict 0.9 to Hardy" [Wishlist,In progress] https://launchpad.net/bugs/186397
[16:40] <LucidFox> mruiz> I've already reconstructed it from the interdiff :)
[16:41] <mruiz> LucidFox, thanks for review it
[16:41] <LucidFox> mruiz> the orig.tar.gz doesn't need repackaging, I assume? (It was better to include get-orig-source even if it doesn't)
[16:41] <mruiz> LucidFox, I'm not familiar with get-orig-source
[16:42] <sistpoty|work> mgunes: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454907
[16:42] <ubotu> Debian bug 454907 in ftp.debian.org "RM: freeloader -- ROM; obsolete; abandoned upstream; few users" [Normal,Open]
[16:42] <mgunes> sistpoty|work, just found it, thanks.
[16:45] <LucidFox> Could a REVU admin please archive tovid, or give me REVU access so I can archive it myself? :)
[16:45]  * persia hopes someone will look at the libaudio-flac-header-perl merge.  The new upstream fixes a lot of bugs, but it needs re-insertion of the conflicts/provides/replaces stuff to handle upgrades from Dapper.
[16:46] <persia> LucidFox: Granting you reviewer rights...
[16:47] <persia> LucidFox: Try reloading the page
[16:47] <LucidFox> Yes, I see the new buttons now, thanks. Archived.
[16:49] <persia> Nobody wants libaudio-flac-header-perl?  Easy merge?
[16:49] <mruiz> persia, I can do it :-)
[16:50] <persia> mruiz: Great.  Just check to make sure you preserve the transition handling for Dapper, as it looks like a sync at first glance.
[16:53] <persia> \sh: gfpoken baffles me, but I think Bas integrated equivalent changes.  When you have a moment, could you take a closer look, and maybe sync?
[16:54] <jdong> ugh looks like I broke apt
[16:54] <jdong> fortunately unofficially to a small user base
[16:54] <jdong> so none of you guys have to sweat. just point and laugh at me
[16:56] <persia> Anyone around know the piuparts codebase?  There's a huge patch for Ubuntu, and we're 9 releases behind, with what looks like good work by the Debian QA team.
[16:57] <linux__alien> Hi LucidFox
[16:57] <LucidFox> linux__alien> I've uploaded your avidemux debdiff, thanks for your work!
[16:58] <linux__alien> is it great thanks :) and i should thank you for your help and co-operation and i am looking forward for more
[16:58] <sistpoty|work> persia: Lars Wirzenius (liw?) should know
[16:58] <linux__alien> LucidFox, i ve a doubt i read through today's motu mailing list and found that they used the word REVU
[16:58] <linux__alien> whats that
[16:59] <linux__alien> i found something like that what does that mean?
[16:59] <LucidFox> !revu | linux__alien
[16:59] <ubotu> linux__alien: 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
[16:59] <persia> sistpoty|work: Doesn't seem to be about, and I'm not sure it would merit FFe, but I'd like to see the newer one available for testing hardy archive stability later in the cycle.
[16:59] <linux__alien> so when i create a new package i will have to upload it there is it?
[17:02] <LucidFox> linux__alien> yes, REVU is a place where packages for software not currently in Ubuntu are uploaded for review
[17:08] <paas> Hi Guys, I know everybody is terribly busy right now but I just need one more advocate http://revu.tauware.de/details.py?package=libtuxcap, thanks
[17:11] <linux__alien> LucidFox, ok thanks so now is there any bug that i could work on ?
[17:12] <linux__alien> i ve just started to try porting kchmviewer to Gnome :) and package it and give it to Ubuntu :)
[17:12] <LucidFox> linux__alien> I don't have any for you at the moment, but you can look for them yourself
[17:12] <LucidFox> linux__alien> it's too late for new packages, really
[17:13] <LucidFox> we've almost hit feature freeze
[17:13] <linux__alien> ya i understand but i can add it later even after the Hardy release
[17:13] <linux__alien> right ?
[17:13] <linux__alien> can it be done
[17:13] <RainCT> Hi
[17:13] <linux__alien> Hi RainCT
[17:15] <rexbron> linux__alien: it can be, but you must file an upstream freeze exception
[17:15] <linux__alien> rexbron, what does that mean ?
[17:16] <rexbron> linux__alien: read the MOTU page on wiki.ubuntu.com
[17:18] <persia> linux__alien: You can add them to the next release after hardy freeze is complete.
[17:18] <linux__alien> ok
[17:18] <linux__alien> and i want the bug list in Ubuntu where could i find it
[17:18] <linux__alien> i mean the list where i can filter those are opened , closed etc
[17:19] <persia> So, my last outstanding merge help request is for someone to look at crystalspace to see if we can pull from Debian.  Any volunteers?
[17:19] <linux__alien> persia, i am ready
[17:19] <linux__alien> persia, if someone can guide me i am ready to do it
[17:20] <persia> Anyone want to help linux__alien for this?
[17:20] <linux__alien> as you might know or might now i am new just fixed couple of bugs in Ubuntu :) with LucidFox 's help
[17:21] <mruiz> persia, talking about libaudio-flac-header-perl, the main difference in debian/control is Conflicts and Provides fields. Debian version doesn't include them
[17:22] <persia> mruiz: Right.  It would be a sync, except we might still need them for Dapper upgrades.  Your job is to investigate Dapper to see whether we need them, and either add them back, or request a sync.
[17:22] <mruiz> persia: thanks
[17:24] <linux__alien> persia, anything i could do for this ?
[17:24] <jdong> quick poll: is bug 190461 considered a new feature requiring a FFe or not?
[17:24] <ubotu> Launchpad bug 190461 in clutch "Lighttpd support" [Wishlist,Confirmed] https://launchpad.net/bugs/190461
[17:24] <persia> linux__alien: I'm too tired to help in detail.  Sorry.
[17:24] <linux__alien> ok
[17:25] <RainCT> LucidFox: congrats!
[17:25] <linux__alien> fine
[17:25] <linux__alien> congrats for ?
[17:25] <LucidFox> for joining MOTU, presumably :)
[17:25] <persia> RainCT: Any luck with the diff.gz -> .dsc script, or will it be a hardy+1 feature?
[17:25] <slytherin> linux__alien: That will just need the adjustment to 'Depends' right?
[17:25] <linux__alien> Oh Great LucidFox
[17:25] <linux__alien> Congrats
[17:26] <mruiz> persia, Dapper uses 1.4-1. 1.9-1  removed all control references (Provides, Conflicts, Replaces) to the old libaudio-flac-perl package, as that was not included in the last stable Debian release anymore. (from the changelog)
[17:26] <emgent> one problem to merge drupal5
[17:26] <emgent> http://rafb.net/p/VOFcC067.html
[17:26] <linux__alien> slytherin, i am new to packaging so if someone could just guide me i could work on it
[17:26] <emgent> patch dont work, and i dont work in this
[17:26] <emgent> some idea?
[17:26] <persia> emgent: Are you the wrong person?  My apologies, I thought you had the last upload.
[17:27] <emgent> i should remove this and re-apply with systempatch?
[17:27] <slytherin> linux__alien: wait, does clutch needs php?
[17:27] <emgent> persia, yep, i was upload this, but in this merge there is a problem
[17:27] <linux__alien> slytherin, i dont know whats clutch
[17:28] <persia> emgent: OK.  It is your merge then.  If you can do it now, great (and ask for help).  If not, the variance gets larger, and you'll have a bigger job for hardy+1.
[17:28] <slytherin> linux__alien: It is a web interface to transmission bittorrent client. I believe it needs php, at least the dependencies specify so. So I am not sure if you will be able to run with lighttpd
[17:28] <persia> mruiz: I haven't investigated in detail.  Check the upgrade path.  Maybe they are requried, maybe it's a sync.
[17:29] <RainCT> persia: (yesterday 18:41:54) RainCT: persia: I don't think I can be of much help with that (I never used many of those commands you listed), sorry :(
[17:29] <emgent> ok persia i will apply with other metod thanks persia
[17:30] <persia> RainCT: Sorry.  I missed that.  Thanks anyway.  I'll put something together for hardy+1 then (I'm not expecting many more new upstreams for hardy :) ).
[17:31] <linux__alien> slytherin, ok thanks
[17:31] <linux__alien> slytherin, can you help me on this ?
[17:31] <linux__alien> on that packaging
[17:32] <slytherin> linux__alien: It is trivial provided you verify clutch runs on lighttpd
[17:33] <linux__alien> slytherin, oh i thought you were talking about crystalspace :)
[17:33] <linux__alien> slytherin, i am sorry was out of context
[17:33] <linux__alien> whats that i ve to do for this
[17:33] <jdong> Does anyone know where bluekuja is?
[17:34] <jdong> I haven't seen him for weeks and motu-p2p is kind of his thing
[17:34] <LucidFox> mruiz> gpredict uploaded
[17:34] <mruiz> thanks LucidFox :)
[17:35] <persia> jdong: He's been on-and-off jabber (although I haven't chatted)
[17:35] <linux__alien> LucidFox, i want the link to the bugs in Ubuntu
[17:35] <linux__alien> LucidFox, so that i could look into whatever i can
[17:35] <LucidFox> linux__alien> http://bugs.launchpad.net/ubuntu
[17:35] <linux__alien> Oh Thanks
[17:40] <emgent> persia, merge is ready, i go to open bug.
[17:41] <LucidFox> the entire content of the orig.tar.gz for vips consists of a single tar.gz, what kind of borked upstream release is that? :/
[17:41] <persia> emgent: Great.
[17:41] <persia> LucidFox: tarball-in-tarball was popular for a while.
[17:43]  * persia has completed personal FeatureFreeze preparation, and wishes others luck: please try to hit all the FF critical bugs in https://launchpad.net/~ubuntu-universe-sponsors/+bugs , and review http://members.ping.de/~mb/universe-versionslist.html#outdatedinB for any new upstreams that have hardy-worthy features.
[17:44] <emgent> done, subscribed u-u-s too.
[18:01] <linux__alien> arent there any open bugs in Gutsy
[18:02] <linux__alien> all bugs i see in LP are more for Feisty and the older releases?
[18:02] <linux__alien> or am i looking at the wrong place /
[18:02] <linux__alien> ?
[18:05] <geser> linux__alien: where are you looking?
[18:05] <tsmithe> hi, my alsa-firmware package was uploaded from revu just over a week ago. i have since received a rejection notice, as there were a couple of issues with copyright and distributability. i have now uploaded to revu a fixed version, and am consequently looking for a motu to sponsor it. presumably i only need one motu this time? the url is http://revu.tauware.de/details.py?package=alsa-firmware
[18:06] <RainCT> apachelogger_: you might be interested in advocating http://revu.tauware.de/details.py?package=oxygen-cursor-theme
[18:06] <geser> bddebian: stormbaancoureur has already the first bug :)
[18:07] <linux__alien> https://bugs.launchpad.net/ubuntu/+bugs?start=225
[18:08] <bddebian> geser: The endianness one?
[18:09] <geser> linux__alien: it's due to the sorting, I usually use "newest first" to see new bugs at the top
[18:09] <tsmithe> RainCT, geser, bddebian, can i pester you, wrt the above?
[18:10] <geser> bddebian: bug #191620, I didn't check further
[18:10] <ubotu> Launchpad bug 191620 in stormbaancoureur "stormbaancoureur segfaults" [Undecided,New] https://launchpad.net/bugs/191620
[18:12] <LucidFox> tsmithe> well, superm1 is here, you can ask him to readvocate him
[18:13] <LucidFox> given how he was one of the original advocates
[18:13] <tsmithe> ah yes, superm1, can you?
[18:15] <linux__alien> LucidFox, there are lot of crash kind of bugs in the bug list which i cannot reproduce coz i dont have the same environment in these cases what do i do
[18:16] <linux__alien> LucidFox, there are few bugs which i could work on or even try to reproduce coz i run Gutsy
[18:16] <LucidFox> then don't touch them :)
[18:16] <LucidFox> simple as that
[18:16] <linux__alien> how do you people generally manage to simulate and fix bugs . Do you all run those many versions of Ubuntu in you comp or you have an other comp to be used as secondary for all these purposes ?
[18:19]  * sistpoty|work heads home now
[18:19] <sistpoty|work> cya
[18:19] <durapraxis> Hi. Is there a possibility to have an apt repository password-protected e.g. via .htaccess? Can apt be configured to provide this type of authentication?
[18:19] <pochu> dfiloni: FF is tomorrow, in case you want to get wx2.8.7 in ;)
[18:20] <dfiloni> pochu: what?
[18:20] <dfiloni> pochu: FF?
[18:20] <pochu> dfiloni: Feature Freeze
[18:20] <\sh> re
[18:20] <tsmithe> (hence my hurry :p)
[18:21] <dfiloni> pochu: oh damn, I think it's impossible to fix all wxwidgets2.8 bugs for tomorrow
[18:22] <\sh> dear Ubuntu Release Team :) Do we get a blank UVF exception for wine? :)
[18:23] <mruiz> persia, libaudio-flac-perl only exists on dapper, edgy and oldstable  in Debian. For me is a sync
[18:23] <dfiloni> pochu: I had fix only a little number of bugs, however I will post it this night
[18:23] <pochu> dfiloni: well you don't need to fix bugs for tomorrow, just get the new stuff. Bugs can be fixed in the next month ;)
[18:23] <ScottK> Dear \sh: One has to ask first.
[18:24] <ScottK> ;-)
[18:24] <dfiloni> pochu: yes, I know, for this reason I will upload in revu this night
[18:24] <pochu> dfiloni: alright, ping me when you are done.
[18:25] <dfiloni> pochu: ok
[18:26] <\sh> ScottK: *g* I don't think that we get a 0.9.55 from YokoZar and I'm asking myself, if I push a 0.9.55 this evening to ubuntu but then I'm feeling bad for YokoZar
[18:26] <ScottK> \sh: I'm fairly certain you get it for the usual reasons. but just file a bug and subscribe the team so we have it all documented.
[18:27] <\sh> ScottK: for sure...nothing without paper
[18:28] <durapraxis> Hi. Is there a possibility to have an apt repository password-protected e.g. via .htaccess? Can apt be configured to provide this type of authentication?
[18:32] <\sh> emgent: how far did you get with the drupal 5.7 merge?
[18:35] <LucidFox> How many hours remain before FF?
[18:37] <blueyed> LucidFox: ~29 as far as I understood it.
[18:38] <linux__alien> LucidFox, i am upset that i am not able to find anything with the resources that i ve :(
[18:38] <linux__alien> any help on this regard would be very much helpful
[18:39] <linux__alien> i really like contributing here and staying here but my resources are a stopping factor :(
[18:40] <Moniker42> linux__alien, what kind of resources do you mean?
[18:40] <promag> durapraxis: nobody cares about you :D
[18:41] <linux__alien> Moniker42, i ve only one laptop where i ve installed 7.10 and want to contribute to Ubuntu but am not able to fix or look into issues as i dont have an other system to play with . This is my only sytem that i ve got
[18:41] <linux__alien> Moniker42, how do i go about doing it
[18:41] <Moniker42> linux__alien, dual-boot?
[18:41] <Moniker42> or get a job
[18:42] <LucidFox> o_O
[18:42] <Moniker42> :)
[18:42] <linux__alien> Moniker42, i thought i could fix some small application issues like something not working stuff like that
[18:43] <linux__alien> Moniker42, please
[18:43] <Moniker42> linux__alien, what is it that you want?
[18:44] <linux__alien> really curious to know this. there would be many people in the same situation that i am in . Having one system and not enough resources. so those people are not encouraged to contribute to Ubuntu ?
[18:45] <\sh> durapraxis: did you try deb http://<user>:<password@<host> in sources.list?
[18:47] <apachelogger_> RainCT: please archive the upload, this package is already in debian, and I merged it with the one on revu
[18:48] <tsmithe> apachelogger_, are you able to check out a new revision of a recently rejected package?
[18:48] <tsmithe> (for me)
[18:48] <RainCT> apachelogger_: ok, done
[18:48] <apachelogger_> tsmithe: just toss it over
[18:49] <linux__alien> Hey Ok guys got to go now cya tomorrow
[18:49] <apachelogger_> I'll be out for the next couple of hours though
[18:49] <tsmithe> apachelogger_, http://revu.tauware.de/details.py?package=alsa-firmware
[18:49] <linux__alien> thanks LucidFox for uploading the package
[18:49] <slangasek> linux__alien: I think the vast majority of Open Source contributions come from people with more than one computer, particularly for distributions like Ubuntu.  I don't mean to discourage you from contributing, but you're certainly working with a handicap
[18:49] <apachelogger_> tsmithe: please mention in a comment why it got rejected
[18:49] <linux__alien> slangasek, so i need an other system is it
[18:49] <linux__alien> any other alternative ?
[18:49] <tsmithe> ok
[18:49] <apachelogger_> afk
[18:50] <RainCT> linux__alien: I also have only 1 PC but this is no problem for contributing to Ubuntu
[18:50] <linux__alien> slangasek, why do you say particulary for distributions like Ubuntu
[18:50] <linux__alien> RainCT, how do you do it
[18:50]  * linux__alien listens 
[18:50] <slangasek> linux__alien: I don't say "need" - but having a dedicated development system makes a big difference in not having your life disrupted when you break your development environment :-)
[18:51] <linux__alien> ok but how does RainCT do it :)
[18:51] <slangasek> linux__alien: I say "particularly for distributions" because when the *distribution* breaks while you're doing development, and it's your primary system, rebootstrapping yourself can be painful
[18:52] <RainCT> linux__alien: what are you having problems with?
[18:52] <linux__alien> slangasek, so it applies to all the distros then
[18:52] <slangasek> linux__alien: yes
[18:52] <linux__alien> RainCT, i ve only one laptop where i ve installed 7.10 and i just want to know how to fix bugs with this system alone ie for hardy how do you do it
[18:52] <linux__alien> i ve 7.10 installed
[18:53] <tsmithe> apachelogger_, done
[18:53] <linux__alien> now its hardy which is gonna be released so how do you contribute with just one system
[18:53] <Moniker42> linux__alien, why would you need two systems in the first place?
[18:53] <linux__alien> so that if i break one i would still have an other to connect to the internet and the normal routine does not get affected
[18:53] <LucidFox> Hmm, my @ubuntu.com address doesn't seem to work
[18:54] <LucidFox> or do I have to do something explicitly to enable it?
[18:54] <geser> LucidFox: it takes some time till it gets activated
[18:54] <RainCT> linux__alien: well, just choose bugs in programs that have still the same version in gutsy as in hardy or are easy to upgrade to (eg, don't need lots of dependency upgrades and such)
[18:54] <ScottK> jdong: It is fitting that my first 'core-dev' upload would be a clamav source backport ...
[18:54] <\sh> ScottK: pdns bug #191506 is already fixed in hardy...
[18:54] <ubotu> Launchpad bug 191506 in pdns "TXT records truncated" [Low,In progress] https://launchpad.net/bugs/191506
[18:55] <ScottK> \sh: Thanks.
[18:55] <linux__alien> RainCT, thats how you do it is it
[18:55] <\sh> ScottK: I checked our source and the changeset is longtime applied
[18:55] <\sh> ScottK: so, question is, worth an SRU?
[18:55] <RainCT> linux__alien: for stuff that needs testing, yes
[18:56] <linux__alien> ok for other stuff like fixing ?
[18:56] <linux__alien> i mean testing after fixing
[18:56] <linux__alien> you would use the same machine to do it which might not produce the actual results sometimes right?
[18:56] <RainCT> linux__alien: then there is also other stuff you can do (fixing / adding .desktop files, manpages, etc. for example) that doesn't necessary need the resulting package to be installed for testing
[18:57] <linux__alien> hmm thats there true
[18:57] <ScottK> \sh: Then I think that's not the right change set as the person who had that bug is running the current version.
[18:57] <ScottK> Argh.
[18:58] <linux__alien> Ok RainCT Thanks for the info
[18:58] <RainCT> linux__alien: and as someone already said above you also have the dual-boot option
[18:58] <linux__alien> RainCT, like downloading hardy and using it
[18:58] <linux__alien> is it
[18:58] <linux__alien> right?
[18:58] <\sh> ScottK: regarding http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/112 the revision is 996 and this is applied
[18:59] <RainCT> linux__alien: yes, having Gutsy and Hardy installed at the same time (in different partitions) so that you can use Hardy for development but have Gutsy as a backup if you need it
[18:59] <ScottK> \sh: I'm verifying the version now to make sure.
[18:59] <linux__alien> RainCT, how about VMWare or something like that ?
[18:59] <linux__alien> RainCT, do you have it in that way ?
[18:59] <\sh> ScottK: and browsing svn there is nothing to see more about TXT records
[19:01] <ScottK> \sh: Thanks.  I'm checking.
[19:02] <LucidFox> hellboy195> I had a lame start, really :)
[19:02] <hellboy195> grml
[19:03] <hellboy195> everybody give it up for LucidFox the newest MOTU (since 4 hours) :D
[19:03] <LucidFox> I learned about REVU, read the packaging guide and uploaded 3 packages, one of them (psi) really badly done
[19:03] <LucidFox> (and not even based on the Debian one)
[19:04] <pochu> LucidFox: I didn't know you were Sikon. Congrats :-)
[19:05] <hellboy195> LucidFox: ^^. and next steps? I supposed it took 8 months until now
[19:06] <LucidFox> I didn't do much for Gutsy, admittedly
[19:06] <LucidFox> Packaged videotrans from scratch
[19:06] <\sh> ScottK: and it looks like that the bugger is in pdns-recursor, reading the debian bug
[19:06] <ScottK> \sh: Yes.  That's what I'm discovering too talking with the person that had the bug.
[19:07] <LucidFox> Also packaged kink, but then I realized upstream was dead - so I forked it and became upstream, and another person packaged the fork for Debian faster than I did for Ubuntu :)
[19:07] <\sh> ScottK: I pinged pkern...:)
[19:07] <tsmithe> LucidFox, hey, as new motu induction, you could upload alsa-firmware for me?
[19:08] <LucidFox> tsmithe> well, you need two advocates first
[19:09] <tsmithe> even if it has already had two advocates?
[19:09] <LucidFox> I don't know, really
[19:09] <hellboy195> LucidFox: nice
[19:09] <hellboy195> LucidFox: so you did ~30 packagings?
[19:10] <RainCT> tsmithe: http://revu.tauware.de/diff.py?upid1=1715&upid2=2006 I guess changes in makefile, autom4te.cache/output.0 and such are just a side effect of re-building?
[19:10] <LucidFox> no, far fewer than that
[19:10] <hellboy195> LucidFox: but other things like ... ?
[19:10] <tsmithe> RainCT, oh crap. is that in there? i had to rebuild configure, but forgot to remove that. hang on
[19:11] <LucidFox> hellboy195> some packages listed on my +packages page are Debian syncs
[19:11] <LucidFox> others are minor modifications
[19:12] <hellboy195> LucidFox: so what and how ~ many contributions did you in generel to become a motu?
[19:12] <LucidFox> there are only four packages I packaged for Ubuntu from scratch: videotrans, inkblot, smplayer-themes, and tovid
[19:12] <LucidFox> however, I did quite a few Debian merges
[19:13] <ScottK> \sh: Here's another clue http://mailman.powerdns.com/pipermail/pdns-users/2008-February/005130.html
[19:13] <hellboy195> LucidFox: I have now 22 merges and 3 sync requests ^^
[19:14] <ScottK> \sh: None of those files happen to appear in pdns-recursor they (it references the same commit)?
[19:14] <RainCT> tsmithe: I'm away for ~1 hour. If LucidFox doesn't upload it ping me later
[19:15] <LucidFox> RainCT> so, readvocation isn't needed for reuploaded NEW rejections?
[19:16] <\sh> ScottK: right, the changeset is in pdns itself...and this is already applied
[19:16] <\sh> ScottK: so pdns is correct...
[19:17] <ScottK> \sh: It appears and the problem is just in the recursor
[19:17] <mruiz> bye all
[19:17] <\sh> ScottK: and we don't find any fix in recursor :(
[19:18] <\sh> ScottK: I'm downloading the 3.1.5 preview and check what's changed against 3.1.4
[19:18] <ScottK> Yes.  The guy that's having the problem is asking on #powerdns.
[19:18] <ScottK> \sh: Sounds good.
[19:19] <\sh> ay
[19:19] <\sh> ScottK: now I understand the system ;)
[19:19] <rhpot1991_laptop> if anyone has any time I could use a revu on: http://revu.tauware.de/details.py?package=mythexport
[19:19] <\sh> ScottK: pdns-recursor is sharing some code with pdns itself...and funny that are the same filenames
[19:19] <\sh> ScottK: fixing
[19:19] <ScottK> \sh: Great.
[19:20] <\sh> ScottK: I can fix the 4.3 stuff too ;)
[19:21] <ScottK> \sh: I'd say just fix this one bug and then we consider updating to the snapshot after.
[19:22] <tsmithe> LucidFox, well, i guess RainCT meant just that, soo... (now i've uploaded a new revision cleaning up the patches)
[19:23] <hellboy195> LucidFox: btw, nice post on ubuntu planet ^^
[19:23] <\sh> ScottK: yepp
[19:24] <AnAnt> persia: hello, I don't understand why ubuntume-themes didn't build for you
[19:25] <AnAnt> persia: in Build-Depends it has: xcursorgen | x11-apps
[19:27] <LucidFox> tsmithe> uploaded
[19:27] <tsmithe> LucidFox, excellent :D
[19:27] <tsmithe> apachelogger_, looks like you're off the hook :)
[19:31] <norsetto> congrats lucidfox!
[19:31] <tsmithe> oh, yes, and of course, congratulations :)
[19:32] <rhpot1991_laptop> RainCT: Thanks for doing the revu for me yesterday, I got another one ready to go if you have time later
[19:34] <AnAnt> how do I submit a debdiff to the "sponsors queue" ?
[19:36] <\sh> ScottK: what arch do your friend need for testing?
[19:36] <ScottK> i386
[19:37] <AnAnt> hello?
[19:37] <\sh> ScottK: ok...I'll compile one package for i386 and where do I send it?
[19:37] <ScottK> \sh: Actuall it's i386 Sid.
[19:37] <AnAnt> ok, where/what is the sponsors queue ?
[19:37] <\sh> ScottK: grmpf
[19:37] <ScottK> \sh: You want to just give me a link to it?  Or join #spf on irc.perl.org and we can chat directly.
[19:38] <ScottK> \sh: I've got a sid pbuilder set up if you want to link me the .dsc
[19:38] <\sh> ScottK: ok...give me a sec...put it on my webserver :)
[19:38] <ScottK> K
[19:38] <\sh> ScottK: just doing a testbuild...
[19:39] <ScottK> OK.
[19:42] <vemon> does anyone have a moment to spare for a great softsynth ready for advocation? :) http://revu.tauware.de/details.py?package=whysynth
[19:43] <ScottK> \sh That was close.  You do want #spf and Julian is the individual in question.
[19:46] <\sh> ScottK, what is SPF actually? ;)
[19:47] <\sh> ScottK, don't answer :) I know what it is ;)
[19:48] <cody-somerville> Can someone please review http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin?
[19:48] <cody-somerville>  It requires one more advocation :)
[19:48] <ScottK> \sh: Then you know why someone involved in that project would find obscure TXT record bugs.
[19:49] <ScottK> BTW, Julian is in Germany too.
[19:49] <\sh> ScottK, yeah :)
[19:49] <LucidFox> Hmm. It seems that some archive admins have tendency to ascribe synced packages to the ACKer of the sync request and not to the original requester
[19:50] <asantoni> persia: What do you think the odds are that LP #190589 will get in before the freeze?
[19:50] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Wishlist,New] https://launchpad.net/bugs/190589
[19:53] <LucidFox> Roll back to old upstream versions? Is that even possible?
[19:55] <Moniker42> LucidFox, anything's possible - if only you believe in it!
[19:57]  * LucidFox believes that it's possible that Microsoft and Apple will simultaneously go bankrupt today
[19:57] <zul> only if i crush tehm
[19:59] <hellboy195> LucidFox: dreamer :P
[19:59] <ScottK> LucidFox: The reason they do that (with sync's) is they want to tag them to someone who's more likely to care/know what to do if it goes bad.
[20:00] <AnAnt> Hello, I am submitted a debdiff to a package that is currently in Queue for Hardy, should the Status of LP be New or Confirmed ?
[20:01] <hellboy195> AnAnt: confirmed and subscribe u-u-s
[20:02] <AnAnt> hellboy195: thanks
[20:02] <hellboy195> np
[20:02] <LucidFox> Great. My blog post has been on Planet Ubuntu for an hour and already I got porn spam.
[20:03] <hellboy195> rofl
[20:03] <hellboy195> LucidFox: yeah I heard that many people with @ubuntu mail adresses are suffering from a lot of spam
[20:03] <ScottK> LucidFox: Is this good news or bad?
[20:04] <\sh> LucidFox, you mean trackback and comment spam?
[20:06] <LucidFox> comment spam in blog
[20:06] <cody-somerville> I get lots of spam on my blogs :)
[20:07] <LucidFox> hellboy195> my @ubuntu.com email doesn't even work
[20:07] <LucidFox> no idea why
[20:07] <hellboy195> LucidFox: hmm. just wait until tomorrow?
[20:07] <LucidFox> maybe
[20:08] <geser> LucidFox: you could ask in #launchpad how often new @ubuntu.com addresses are generated
[20:10] <LucidFox> I'll try after I get some sleep first
[20:10] <LucidFox> night all
[20:11] <jpatrick> geser: after a week at least I believe
[20:21] <\sh> ScottK, did you see http://www.securityfocus.com/bid/27751 ? :)
[20:22] <ScottK> Looking
[20:22] <ScottK> \sh: Fixed in all supported Ubuntu releases (except the package for feisty-backports is waiting to build).
[20:22] <ScottK> So, yes.
[20:23] <\sh> ScottK, you are fast :)
[20:23] <ScottK> It helps to have help.  leonel did Gutsy/Dapper and I did Hardy (grabbed the new upstream out of Debian incoming) and Feisty (stole Debian's patch for Etch).
[20:24] <ScottK> That and now that I can upload source backports myself, that part's faster too.
[20:25] <\sh> ScottK, your core application was overdue...
[20:25] <cody-somerville> ScottK: Would you be able to review thunar-svn-plugin on revu?
[20:25] <cody-somerville> http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin ? :)
[20:25] <ScottK> cody-somerville: Perhaps later.
[20:25] <ScottK> \sh: Thanks.
[20:26] <\sh> siretart, did you get my ping from this afternoon? regarding mplayer and moving mplayer-skins to suggests ?
[20:27] <siretart> \sh: I didn't read the context yet, but from the line, Recommends seems appropriate
[20:27] <\sh> siretart, yepp..that would be also possible..and telling apt not to install Recommends in the first place...
[20:28] <\sh> siretart, the thing is you can use mplayer in a server environment to extract thumbnails of videos..therefore mplayer-skins pulls in a lot of not used and not needed x stuff
[20:30] <siretart> \sh: either that, or blacklisting xserver related packages
[20:30] <\sh> siretart, well, actually you don't need the skins to start mplayer...so I think Recommends: is a better solution
[20:31] <\sh> siretart, but you are the right person to answer this question :)
[20:32] <siretart> you proposed suggest at first ;)
[20:33] <siretart> \sh: btw, did you do something with fai on hardy?
[20:33] <\sh> siretart, not right now...neither used nor put my hands on the source
[20:34] <siretart> \sh: I'm currently considering pushing my merge to hardy right now, and fix broken things after FF
[20:34] <\sh> siretart, please do..I think there are some bugs with the old version in hardy because of the new kernel world order
[20:35] <siretart> allee: do you agree? (pushing fai into hardy right now)?
[20:35] <\sh> siretart, and yes, I said suggests, because I know that this won't be installed by default...I forgot that you can train apt to not install recommends..so recommends is the better solution
[20:37] <siretart> \sh: you could even pin down individual packages
[20:38] <\sh> siretart, I did rebuild the ubuntu package for etch and fixed it in our local repo ;)
[20:38] <\sh> but pinning down because of this doesn't make sense, and moving it to recommends is more logical, because you can use mplayer without it
[20:39] <siretart> I mean moving the skins to recommends, and pin down the xserver. this way you don't need to turn of recommends
[20:40] <\sh> siretart, sure...but disabling installing recommends is a good think so you know much better what's on your server, when apt is following only the main dependencies...well I'm lazy that's all ;)
[20:42] <siretart> indeed
[20:43] <dfiloni> pochu: done, wxwidgets2.8 2.8.7.1 is in revu
[20:45] <pochu> dfiloni: cool. I'll have a look at it later.
[20:46] <pochu> persia, DktrKranz ^ perhaps you can have a look at it too and with all our eyes we can get it in tomorrow.
[20:46] <dfiloni> pochu: I don't know if it works, I didn't test it, my pc wan't to kill me :)
[20:47] <pochu> dfiloni: I'll do that for you ;)
[20:47] <DktrKranz> pochu, sure. Last upload went good (at least they didn't shoot at me or dfiloni)
[20:47] <pochu> dfiloni: thanks for the good work
[20:47] <dfiloni> pochu: great! thanks!
[20:47]  * pochu hugs dfiloni :)
[20:47] <pochu> DktrKranz: cool. I have to leave soon. I'll leave wx building...
[20:54] <afflux> Should I provide a rule for get-orig-source if the source can be obtained with uscan?
[20:56] <RainCT> afflux: it isn't necessary if upstream's tarball is ok
[20:58] <afflux> RainCT: the reason why I'm asking is lucidfox' comments on bug 190671
[20:58] <ubotu> Launchpad bug 190671 in gdecrypt "new upstream version available (0.7.1)" [Wishlist,Fix released] https://launchpad.net/bugs/190671
[21:00] <crimsun> hmph, my irc server is sinking.
[21:14] <hendrixski> Anybody know a good resource on how to make apt.conf files?
[21:21] <james_w> hendrixski: is "man apt.conf" not sufficient?
[21:24] <hendrixski> james_w, nope
[21:25] <hendrixski> james_w, I'm trying to get apt-ftparchive to make a packages.gz file of the .ddeb files in a directory (normally it only picks up debs)... and you need to pass it a conf file to do that... the only examples i've found are confusing, and I'm looking for a manual
[21:25] <hendrixski> and the man page doesn't have a lot of the key things that are in the example
[21:26] <\sh> hendrixski, apt-ftparchive has a good docu..but man apt.conf is the wrong help ;)
[21:28] <\sh> hendrixski, http://cihar.com/publications/misc/debian-repository-howto/ as one pointer with examples
[21:28] <hendrixski> nice
[21:29] <hendrixski> ah, I guess I googled the wrong things
[21:30] <hendrixski> \sh, thanks :-)
[21:30] <\sh> hendrixski, another pointer where apt-ftparchive is used you'll find here: https://help.ubuntu.com/community/InstallCDCustomization?action=show&redirect=InstallCDCustomizationHowTo
[21:34] <hendrixski> \sh, nice.  I'll read through more of that stuff. .. I thought those conf files being passed were in the style of apt.conf files so I was kind of scratching my head
[21:35] <\sh> hendrixski, nope
[21:35] <\sh> hendrixski, but the mentioning of apt.conf(5) looks like a bug to me
[22:16] <csomerville> Is ubuntuwire down?
[22:27] <blueyed> RAOF: I've re-uploaded jedit on revu.
[22:35] <RainCT> csomerville: seems so
[22:35] <RainCT> well, good night
[22:38] <blueyed> csomerville: http://revu.ubuntuwire.com/ works..
[22:39] <csomerville> yes
[23:05] <emgent> lastfm   	 Ubuntu Hardy   	 1:1.4.2.58240.dfsg-1ubuntu1   	2008-02-12  	 Not yet built
[23:05] <emgent> uhm.. some idea?
[23:06] <emgent> xsupplicant   	 Ubuntu Hardy   	 1.2.4.dfsg.1-5   	4 hours ago  	 Not yet built  	
[23:06] <emgent> problem with buildt ?
[23:16] <geser> emgent: lastfm build successfully
[23:16] <emgent> ok
[23:16] <emgent> my launchpad have some problem
[23:16] <emgent> https://edge.launchpad.net/~emgent/+packages
[23:17] <geser> emgent: https://edge.launchpad.net/ubuntu/hardy/+source/xsupplicant/+builds and https://edge.launchpad.net/ubuntu/hardy/+source/lastfm/+builds
[23:17] <rhpot1991> anyone available for a revu?
[23:18] <geser> emgent: probably because some arch are still pending
[23:18] <emgent> ok cool.
[23:18] <emgent> thanks geser
[23:32] <jumpkick> Hello all
[23:34] <jumpkick> asantoni and I (original authors of Mixxx) are trying to get our package in before the freeze, we are facing from resistance from the fact that a old version was synced from Debian into Universe...
[23:35] <jumpkick> the debian package was authored by a 3rd party
[23:35] <jumpkick> and there is now some problem with change-logs being divergent
[23:36] <pwnguin> when you say 3rd party, do you mean a DD, or an NMU?
[23:36] <jumpkick> we could use the MOTU mojo in resolving this issue
[23:36] <jumpkick> https://bugs.launchpad.net/ubuntu/+source/mixxx/+bug/190589
[23:36] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Wishlist,New]
[23:37] <jumpkick> pwnguin: there are debian maintainers who ported the ubuntu package to Debian Sid
[23:38] <jumpkick> http://packages.debian.org/sid/mixxx
[23:38] <jumpkick> when universe was synced from Debian it pulled their version of our ported package
[23:39] <jumpkick> I should say ported and updated from trunk
[23:39] <jumpkick> beta 2 has since been released and is quite a bit more stable and feature complete
[23:40] <jumpkick> http://mixxxblog.blogspot.com/2008/02/mixxx-160-beta2-released.html
[23:40] <jumpkick> but we the original authors of the package are shut out of the loop
[23:40] <jumpkick> so we are unable to get it updated
[23:42] <steveire> Hi I'm still confused about version numbering in my ppa. I've named the package 1.1.10-1ubuntu1~ppa1. That should be upgraded if a new version of libxine appears in -backports. Is that what will happen with the current version name
[23:42] <steveire> ?
[23:45] <jumpkick> so can someone do whatever MOTUs do and advocate the acceptance of our beta2 package plz
[23:45] <jumpkick> http://revu.tauware.de/details.py?package=mixxx
[23:45] <_MMA_> jumpkick: I think the possibility of getting it into Debian and then syncing to Ubuntu are slim. But I might be able to get someone to do a package you can host for users if nobody has the time to do something in Ubuntu.
[23:46] <pwnguin> _MMA_: but the situation is a bit strange, in that upstream to debian is/was ubuntu
[23:46] <jumpkick> _MMA_: no, no, no...  someone (not us) took the Ubuntu package for 1.5.2 and updated it against trunk to 1.6.0b1 and put into Debian
[23:47] <jumpkick> Ubuntu synced against debian
[23:47] <_MMA_> Ok. I see. You have a package in REVU. Ill poke around to see if I can get it attention.
[23:47] <jumpkick> and now we are pooched
[23:47] <jumpkick> thanks
[23:47] <jumpkick> _MMA_: help is much appriecated...
[23:47] <pwnguin> i thought there was a list of software not to import from debian
[23:47] <pwnguin> for situations like this
[23:47] <jumpkick> Debian never had the package before
[23:48] <nityad> Hello, I am planning to upload new packages for GlassFish V2 UR1 (multiverse) to the REVU queue later today. LP: # 191658 . Is there any other process that I should be aware of other than following the instructions on uploading to REVU - Thanks
[23:48] <jumpkick> poor asantoni has been trying to get the package in for feature freeze since last week
[23:48] <_MMA_> jumpkick: Still too late in my experience. :P
[23:48] <TheMuso> jumpkick: I know what the portaudio problem is, and it has to do with the fact that portaudio v19 used to be in main, which is where all the core Ubuntu softwrae is. However, jack is still in universe.
[23:49] <TheMuso> So portaudio is not currently built against jack.
[23:49] <persia> nityad: That the deadline for new source packages (and hence REVU) is today, and that glassfish is already in the repository.  You'd do better to submit the diff.gz to the sponsors queue in an upgrade bug.
[23:50] <jumpkick> We can probably live without jack if we have to...  We also support ALSA and OSS
[23:50] <TheMuso> Right.
[23:50] <jumpkick> or package up unofficial bins to support jack for the hardcore folks who want it
[23:50] <TheMuso> I'm surprised you use jack via portaudio.
[23:50] <TheMuso> Thats... um... somewhat messy
[23:50] <TheMuso> IMO
[23:51] <jumpkick> TheMuso: I thought the point of using portaudio was to not care what the underlying api is for sound
[23:51] <TheMuso> Yes, but that introduces latency.
[23:51] <jumpkick> I'm not down at that level of dev, so perhaps I have it wrong
[23:51] <jumpkick> TheMuso: yeah, there's a trade off there
[23:52] <jumpkick> we already compensate for latency to some extent as it is
[23:52] <TheMuso> fair enough
[23:52] <TheMuso> I'm seeing what I can do to squeeze it in now.
[23:52] <jumpkick> TheMuso: thanks
[23:53] <jdstrand> ScottK: dapper clamav pushed.  should hit mirrors in a couple hours
[23:53] <cody-somerville> Can someone please review http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin ?
[23:53] <steveire> Is there anywhere else I can ask my version question? Launchpad is silent.
[23:54] <jumpkick> pwnguin: where can I find info about this don't-sync-from-Debian list of packages?
[23:54] <jumpkick> is there a keyword or something I can google
[23:55] <nityad> persia: GlassFish V1 relase is in the repository. This is going to be a completely separate package glassfishv2ur1 (and its dependencies) so that both versions are installable in parallel.
[23:55] <steveire> Hi I'm still confused about version numbering in my ppa. I've named the package 1.1.10-1ubuntu1~ppa1. That should be upgraded if a new version of libxine appears in -backports. Is that what will happen with the current version name
[23:57] <rhpot1991> Can I get a review on this (http://revu.tauware.de/details.py?package=mythexport), been looked at a few times, should be pretty good by now
[23:58] <persia> nityad: In that case, your chances of getting it into hardy are slim to nil.