[12:32] <coNP> The question is if want to empty the REVU queue or have 3 perfect pacakges... :)
[12:33] <norsetto> coNP: 3 perfect packages! nothing but perfection
[12:33] <norsetto> coNP: and you know you can do both :-)
[12:42] <norsetto> coNP: treat it well, that was my first package (ah, the memories ....)
[12:42] <coNP> norsetto: which one?
[12:44] <norsetto> coNP: telepathy-sofiasip (https://bugs.launchpad.net/ubuntu/+bug/111728)
[12:44] <ubotu> Launchpad bug 111728 in ubuntu "[needs-packaging]  Please package telepathy-sofiasip" [Wishlist,Fix released]
[12:44] <coNP> Oh. These are telepathy-{haze,mission-control,salut}
[12:46] <norsetto> coNP: yeah, I remember I did something on libmissioncontrol (thats how it was called then)
[12:46] <coNP> Sure. I guess these are package updates
[12:47] <norsetto> coNP: I guess, everything was passed over to Debian
[12:47] <cbx33> ping TheMuso
[12:48] <coNP> norsetto: I don't know
[12:48] <norsetto> coNP: me too, way too many things I don't know and I might never know
[12:48] <TheMuso> cbx33: Yeah
[12:49] <TheMuso> norsetto, coNP, any packages you have looked at need a second advocate?
[12:49] <cbx33> TheMuso, got a sec for a pm?
[12:49] <coNP> TheMuso: : boswars
[12:49] <TheMuso> Sure.
[12:49] <TheMuso> Ok
[12:49] <coNP> and two others
[12:49] <coNP> check REVU please :)
[12:49] <TheMuso> Sure
[12:49] <ScottK> coNP: You are doing a great job.  Keep it up.
[12:50] <superm1> TheMuso, i need one on mythbuntu-control-centre if you can
[12:50] <coNP> bigon: what is the difference between hase and your telepathy-hase package?
[12:50] <coNP> !info hase gutsy
[12:50] <ubotu> Package hase does not exist in gutsy
[12:50] <coNP> !info telepathy-hase gutsy
[12:50] <ubotu> Package telepathy-hase does not exist in gutsy
[12:51] <coNP> !info telepathy-haze gutsy
[12:51] <ubotu> Package telepathy-haze does not exist in gutsy
[12:51] <coNP> !info haze gutsy
[12:51] <ubotu> Package haze does not exist in gutsy
[12:51] <norsetto> no difference :-)
[12:51] <TheMuso> superm1: Sure.
[12:51] <bigon> coNP: haze has been packages without the help of the debian tp ream
[12:51] <bigon> team
[12:51] <coNP> bigon: okay. I just checked and got haze 0.1.1-0ubuntu1 from the archives.
[12:51] <coNP> REVU has also 0.1.1-0ubuntu1
[12:52] <bigon> tp-haze still sit in the debian new queue
[12:52] <bigon> coNP: yes I think my pkg should be dropped for now
[12:52] <coNP> I still don't understand why to package / review the same version again...
[12:53] <coNP> For Ubuntu. Debian has its own queue :)
[12:53] <bigon> coNP: both pkg have been at the same time by different persons
[12:53] <coNP> bigon: so you think I can archive your telepathy-haze package?
[12:53] <bigon> coNP: yep
[12:55] <coNP> bigon: but you say once debian includes telepathy-haze, we can sync / merge and drop haze?
[12:56] <bigon> coNP: yep
[12:57] <coNP> Okay. For an update package do I need a second ack?
[12:57] <coNP> I guess only an UVFe.
[01:08] <coNP> bigon: can you please file UVFe requests for your update packages?
[01:09] <norsetto> ok, thats it, I'm heading to bed....
[01:09] <norsetto> night all!
[01:11] <TheMuso> Does anybody know any other gimpnet servers appart from irc.gnome.org?
[01:11] <coNP> bigon: Perhaps you might ask as well if they would be permitted (from ScottK, soren, StevenK, zul, Hobbsee). I am glad to review / sponsor you the uploads once done with the UVF part
[01:12] <bigon> coNP: ? which package? tp-haze?
[01:12] <coNP> No. telepathy-mission-control, telepathy-salut and empathy
[01:12] <coNP> Haze has the proper version.
[01:13] <bigon> coNP: uvfe has been already filled :o
[01:13] <coNP> bigon: then I am sorry.
[01:14] <coNP> BTW next time you can adds comment for this on REVU
[01:15] <coNP> To give poor reviewers a chance to notice the fact :)
[01:16] <coNP> In fact there is no real need to review these packages any more.
[01:16] <coNP> If two MOTU acks them
[01:30] <superm1> thx for looking that over TheMuso.  I've never used desktop-file-validate before, but the desktop file works as is.  Did you run it on the resultant .desktop, or the .in?  The warnings that come up may only have been from the .in since several things can still be translated at that point
[01:32] <TheMuso> superm1: On the desktop itself.
[01:32] <TheMuso> I am well aware of the .in file having bits that wouldn't be recognised.
[01:33] <superm1> TheMuso, okay.  Well i'll be sure to fix that in a future upload then.
[01:36] <TheMuso> superm1: Glad to be of help.
[01:37] <TheMuso> Ouch! Boswars is big!
[01:44] <coNP> TheMuso: yep.
[01:44] <ajmitch> hi
[01:45] <superm1> TheMuso, can you archive the control centre revu item, i still dont have my revu permissions
[01:47] <ajmitch> superm1: what permissions would you like on revu? :)
[01:47] <superm1> ajmitch, permissions to do revu'ing :)
[01:47] <superm1> i'm still marked as a contributor
[01:48] <ajmitch> not any more
[01:48] <ajmitch> logout & log back in
[01:48] <superm1> okay sweet thanks
[01:51] <TheMuso> superm1: Did that as soon as I acked.
[01:52] <superm1> TheMuso, wasn't sure, and my DNS is a bit finicky right now to resolving, so i couldnt get to the revu site
[02:02] <TheMuso> ajmitch: Wouldn't we all like to know.
[02:02] <ajmitch> it was more than a bit over the top
[02:03] <kompozer> tonyyarusso: ping
[02:29] <superm1> coNP, on gtkglextmm, i ended up with a FTBFS, did you build it in pbuilder?
[02:29] <superm1> or sbuild?
[02:30] <TheMuso> superm1: What sort of FTBFS?
[02:30] <superm1> TheMuso, make[1] : *** No rule to make target `distclean'.  Stop.
[02:30] <TheMuso> ah
[02:33] <RAOF> In case you've never fixed something like that before, StevenK pointed me at "if [ -f Makefile ]  ; then $(MAKE) distclean ; fi"
[02:34] <superm1> I have never had to fix something like that before.  I'll add that as a comment though.  thanks RAOF
[02:35] <RAOF> Another, less lintian-clean solution is to add a "-" before the start of the line, to make it ignore errors.
[02:35] <superm1> surprisingly, actually there already is a - at the start of the line
[02:35] <RAOF> Oh, really?  Hm.  I thought that should ignore errors, it has for me in the past.
[02:39] <xtknight> !revu
[02:39] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[02:41] <xtknight> anyone have an idea if or when qtpfsgui would hit universe for gutsy?  would this be gutsy+1 only?  http://revu.tauware.de/details.py?upid=7
[02:44] <superm1> xtknight, assuming it gets accepted to the archive before Aug 30th, it will be in gutsy
[02:45] <xtknight> ahh
[02:45] <superm1> xtknight, i'll look it over right now
[02:45] <mohammad> ScottK: are you here?
[02:45] <xtknight> eh?  you dont have to.  i found his debs here meanwhile http://ubuntu.davromaniak.eu/dists/gutsy-depomaniak/all/
[02:46] <xtknight> it would be nice if it were in gutsy universe but no hurry
[02:47] <xtknight> i know this is an odd question but is there a way to install a downloaded deb where it will install the Depends from the repositories?  (understanded that this is poor practice)
[02:50] <mohammad> I was told by vil that http://revu.tauware.de/details.py?upid=75 needs to be reviewed by someone knowledgeable in licensing issues. would someone please take a look?
[02:55] <tedp> i have a new version of ccontrol ready for upload to debian, awaiting sponsorship. i know it's getting late in the gutsy release cycle, would anyone be interested in grabbing the package now for ubuntu? It fixes a "fails to run at all" bug, bug #109157. Source is at http://lazypants.org/~ted/debian/pool/main/c/ccontrol/ccontrol_0.9.1+20060806-4.dsc
[02:55] <ubotu> Launchpad bug 109157 in ccontrol "ccontrol SEGVs on startup" [Undecided,Fix committed]  https://launchpad.net/bugs/109157
[02:56] <xtknight> superm1, well i d/l his dsc, dpkg-source -x/debuild -us -uc and i can confirm the program runs fine on amd64.  so that's good news.  am i qualified to comment on his revu?
[02:56] <TheMuso> xtknight: If on the console, you could install the deb with sudo dpkg -i, and then run sudo apt-get -f install to install its deps.
[02:56] <xtknight> TheMuso,  ahh that's a good idea
[02:57] <superm1> xtknight, only MOTU can comment on revu, and i just tested it pbuilder, and found some problems, but it should build as is currently
[02:57] <xtknight> actually i am having some issues with the program now (some dependencies like hugin's image stack are not satisfied)
[02:58] <xtknight> what should the avg user do if he finds a problem with a REVU pkg?  just email the author?
[02:58] <xtknight> im adventurous just not motu yet :)
[03:00] <StevenK> RAOF: My if line won't help with "make[1] : *** No rule to make target `distclean'. Stop."
[03:02] <RAOF> StevenK: Hm.  Doesn't that error get spat out if Makefile doesn't exist, as well as if there's no distclean target?
[03:02] <RAOF> Or is it a slightly different error in that case :/
[03:03] <StevenK> Hrm, maybe you're right.
[03:03] <superm1> i would think it to still work
[03:04] <superm1> xtknight, if you see an issue with the package, if the author is on IRC, go ahead and let them know here.
[03:05] <TheMuso> superm1: Let me grab gtkglextmm and I'll see what I get in my sbuild setup.
[03:13] <sn9> TheMuso: i always thought it was irc.gimp.net
[03:13] <TheMuso> RAOF: Well never mind, I am back on.
[03:15] <RAOF> TheMuso: Um, what was that in reference to?
[03:15] <TheMuso> RAOF: I couldn't connect for a while. I got dumped off.
[03:21] <TheMuso> superm1: Its building for me.
[03:21] <superm1> TheMuso, so pbuilder only issue then?
[03:21] <TheMuso> superm1: Dunno. I guess it failed right at the start for you?
[03:21] <superm1> TheMuso, yes
[03:21] <TheMuso> as in, didn't configure, and build?
[03:21] <superm1> not at all
[03:22] <TheMuso> hmm well I dunno.
[03:22] <TheMuso> I could set up pbuilder and have a look.
[03:25] <TheMuso> superm1: Successfully built.
[03:25] <superm1> TheMuso, hm what to make of that i wonder.
[03:26] <TheMuso> ...and this on an arch thats not officially supported any more.
[03:26] <StevenK> TheMuso: Under pbuilder, or sbuild?
[03:26] <TheMuso> StevenK: sbuild
[03:32] <superm1> TheMuso, after adding that if block to check for the Makefile, it works in pbuilder
[03:32] <superm1> so i would say the poster just needs to make that change and things will be fine
[03:36] <TheMuso> Right.
[04:06] <imbrandon> ./` ... and I hate every thing about you ... ./`
[04:06] <imbrandon> ajmitch: get some work done :) /me ducks
[04:12] <ScottK> I am here (sort of) while doing $WORK.  If I can answer questions, feel free to ping me.  I'll answer if I can.
[04:12] <ScottK> Also, if some MOTU could look into "[20:50]  <mohammad> I was told by vil that http://revu.tauware.de/details.py?upid=75 needs to be reviewed by someone knowledgeable in licensing issues. would someone please take a look?", I'd appreciate it.
[04:13] <ajmitch> imbrandon: ?
[04:13] <ScottK> I'll probably look it over later if I don't pass out before the work is done.
[04:13] <superm1> imbrandon, ?
[04:13] <imbrandon> ajmitch: nothing was just looking at lastfm rss's
[04:13] <imbrandon> superm1: ?
[04:14] <superm1> imbrandon, what happened a week ago?
[04:14] <ajmitch> imbrandon: that's what I suspected, but the "14:06 < imbrandon> ajmitch: get some work done :) /me ducks" was puzzling :)
[04:14] <imbrandon> bad joke after long hours at the keyboard ;)
[04:15] <ajmitch> you need mt dew
[04:15] <imbrandon> yes, yes i do
[04:32] <tonyyarusso> What does debian/compat refer to again?  (/me is wondering why a newer version of something is using a lower number)
[04:34] <tonyyarusso> Also need to know or look up the Standards-Version field.
[04:35] <ScottK> debian/compat is the debhelper version you are using.
[04:36] <ScottK> Currently is should be 5 and your package should build-dep on dephelper 5 or higher.
[04:36] <ScottK> Current standards version is 3.7.2.
[04:36] <tonyyarusso> Hmm.  I wonder why he built with debhelper 4.
[04:36] <tonyyarusso> Oh - I know.  He's using Dapper.  :P
[04:43] <tonyyarusso> ScottK: In copyright, I had used Upstream Author:, while the guy I'm working with's file has Copyright Holder: - which is more appropriate, or does it matter?
[04:44] <ScottK> tonyyarusso: I'd look in the Debian New Maintainer's Guide and see which they have.  I'd guess Copyright holder, but I'm not certain.
[04:47] <tonyyarusso> ScottK: Ah, both, apparently, in the form Upstream Author: name <email>, Copyright $year name
[04:48] <tonyyarusso> ScottK: However, as is the case with a lot of free software, there are components written by dozens of people.  Do you only cite the primary copyright holder of the most recent additions?
[04:48] <ScottK> It depends.
[04:49] <ScottK> I do is grep -ir copyright * and include anyone except for makefiles and translations.
[04:49] <tonyyarusso> I went through and made a full list at one point, it's it's about half a screen long.
[04:50] <tonyyarusso> (with commas, not a separate line for each even)
[04:52] <tonyyarusso> Additionally, the package in question is tri-licensed.  I assume I should have preambles for GPL and LGPL, and full text for Mozilla, not just one?
[04:55] <sn9> choice of "GPL or LGPL" is a no-op, anyway
[04:55] <sn9> just leave out the GPL
[04:55] <tonyyarusso> ah, lol
[04:55] <tonyyarusso> I think he was redoing it as Mozilla anyway, but was listed tri for some crazy reason.
[04:56] <sn9> the text of the LGPL specifies that one has the option of upgrading to GPL, anyway
[04:56] <DARKGuy> Hey guys, if I register and all and submit a package for Gutsy's Universe, will I be able to update it later throughough time, or only bugfixes ?
[04:56] <sn9> so GPL has no force on anything with LGPL attached
[05:00] <DARKGuy> anybody?
[05:00] <tonyyarusso> DARKGuy: generally bugfixes afaik, but IANAMOTU
[05:02] <DARKGuy> tonyyarusso: Hm... I see, it's that I'm making a game with a team and we're hopefully gonna submit it to MOTU soon... but if we go from Alpha to Beta and then Final, and only bugfixes are allowed I don't think we'll stand a chance... right?
[05:03] <tonyyarusso> DARKGuy: Doubt it.  You'll probably want to post the revisions in a PPA and get on gutsy+1 for that.
[05:03] <DARKGuy> tonyyarusso: forgive my ignorance, what's a PPA?
[05:04] <tonyyarusso> DARKGuy: Personal Package Archive.  New Launchpad feature.
[05:04] <tonyyarusso> (lets you do a repo for your stuff through LP)
[05:05] <DARKGuy> I see, thanks a lot :)
[05:06] <ScottK> sn9: The point of tri licensing is that someone who chooses to distribute it under any or all of the licenses, so it's important to presever all the licenses unless there is a reason to drop one.
[05:06] <sn9> "all of the licenses" cannot apply when MPL is involved
[05:07] <sn9> "any of the licenses" is meaningless when LGPL is with GPL
[05:07] <sn9> so, it's not even tri-licensing in this case
[05:07] <ScottK> Sure it can.
[05:07] <ScottK> If you fork the code, you can license your fork GPL only.
[05:08] <sn9> GPL and MPL are mutually exclusive; they cannot apply at the same time
[05:08] <ScottK> Why not?
[05:09] <ScottK> Acutally, yes.
[05:09] <ScottK> They cannot apply at the same time, but you can choose which one you want to use in a given circumstance.
[05:09] <sn9> right
[05:09] <sn9> that's "any" not "all"
[05:09] <ScottK> OK.
[05:10] <sn9> in which case, LGPL renders GPL meaningless
[05:10] <ScottK> So by carrying forward the tri license, you preserve what the author wanted .
[05:10] <sn9> you still preserve that by dropping GPL
[05:10] <ScottK> Yes, but by leaving them in, if someone wanted to do a GPL only fork, they could.
[05:11] <sn9> the terms of the LGPL alreafy guarantee that
[05:11] <sn9> *already
[05:20] <tonyyarusso> Is REVU at the same URL with the new machine and all, or something different?
[05:21] <ajmitch> same url, different machine
[05:21] <ajmitch> not in the canonical DC
[05:22] <tonyyarusso> kk
[06:26] <mohammad> I was told by vil (Vladimr) that http://revu.tauware.de/details.py?upid=75 needs to be reviewed by someone knowledgeable in licensing issues. would someone please take a look?
[06:27] <ScottK> Hello mohammad.
[06:27] <ScottK> I'm here now.
[06:27] <mohammad> Hello ScottK
[06:27] <ScottK> I'm not reviewing right now.  Doing $WORK, but hope to be able to look at it soon.
[06:30] <mohammad> ScottK: OK thank you. vil told me that he is fine with the package. But he is not sure about the licensing (whether it is possible to put the translations in multiverse).
[06:32] <ScottK> Well zekr is in multiverse because of one of the dependencies.  I will try to look at it soon.  I'm reasonably knowlegeable on the licensing stuff.
[06:35] <sn9> this is why debian came up with "contrib"
[06:36] <ScottK> sn9: What do you mean?
[06:37] <sn9> "Well zekr is in multiverse because of one of the dependencies."
[06:39] <mohammad> sn9: you mean Zekr also can be put in contrib for Debian?
[06:39] <ScottK> Not sure how that relates to contrib.  I think in Debian it would have to go in non-free.
[06:40] <sn9> non-free is only for stuff that does not meet dfsg
[06:40] <sn9> if it meets dfsg, but a dependency doesn't, it goes in contrib
[06:40] <ScottK> sn9: What about stuff that meets dfsg, but depends on non-dfsg packages?
[06:40] <ScottK> Ah.
[06:40] <sn9> also applies to build-dep's
[06:41] <ScottK> In that case, then zekr probably could go in contrib.
[06:41] <sn9> that's what contrib is all about
[06:41] <ScottK> As originally distributed, it wasn't free, but mohammad got the upstream to change stuff and do a new release.
[06:55] <mohammad> ok thank you, see you later.
[06:55] <tonyyarusso> Could someone explain the following lintian error to me?  "E: kompozer source: outdated-autotools-helper-file mozilla/build/autoconf/config.guess 2003-02-22"
[06:55] <tonyyarusso> Additionally, I have a few like "W: kompozer source: configure-generated-file-in-source mozilla/nsprpub/config.status" - would I be correct in thinking these just need some sort of removal line in 'rules'?
[06:59] <ScottK> StevenK: Since python-central is a Debian native package (and Debian revisions don't need an exception), does it really need a UVFe?
[07:02] <tonyyarusso> (but needs teensy bits of help yet :P )
[07:04] <Hobbsee> woo!
[07:04] <ajmitch> hello Hobbsee
[07:05] <tonyyarusso> Hobbsee: Can you explain the following lintian error to me by any chance?  "E: kompozer source: outdated-autotools-helper-file mozilla/build/autoconf/config.guess 2003-02-22"
[07:06] <Hobbsee> hi ajmitch
[07:06] <Hobbsee> mmm...autohell
[07:06] <Hobbsee> ajmitch: can explain that one
[07:07] <TheMuso> tonyyarusso: YOu need to use the config.{guess,sub} files from the autotools-dev package
[07:08] <Hobbsee> or just rerun autohell, presumably
[07:08] <TheMuso> Basically to ensure these files are current.
[07:08] <TheMuso> Many packages in the archive do this.
[07:08] <TheMuso> If a package depends on autotools-dev, chances are thats what its for.
[07:09] <tonyyarusso> TheMuso: I'm not sure I really understand (I'm doing the debian/ dir, but didn't write any of the mozilla/ stuff)
[07:09] <ajmitch> :)
[07:09] <Hobbsee> ajmitch: lying.  *gives penalty card*
[07:10] <tonyyarusso> lol
[07:10] <Hobbsee> *gives penalty card for muttering*
[07:12] <TheMuso> tonyyarusso: As I said, many packages replace configure.sub and configure.guess with ones from autotools-dev. I can't think of any from the top of my head now, but have a look around to see what they do
[07:12] <TheMuso> thats what the lintian warning sounds like to me anywa
[07:12] <RAOF> Hm.  For fakesyncs is it OK for a 4.35-0ubuntu1 changelog entry to be above a 4.35-1 entry?
[07:12] <tonyyarusso> TheMuso: I don't even know what those two files are for or from at this point
[07:13] <TheMuso> tonyyarusso: They are for use with the configure script.
[07:13] <tonyyarusso> hmm, that might make sense
[07:13] <TheMuso> Hobbsee: hehe I like your response to RAOF's application.
[07:14] <Hobbsee> TheMuso: :D
[07:15] <Hobbsee> RAOF: i doubt it matters.  i usually use 4.35-1ubuntu1 for the fakesync'd version
[07:15] <tonyyarusso> TheMuso: Presumably autotools-dev would just be in the build-depends, not regular?  Or should it be the depends of the associated -dev package?
[07:15] <TheMuso> tonyyarusso: build-deps.
[07:16] <tonyyarusso> kk
[07:16] <TheMuso> As the files you are copying are only ever used for building the package.
[07:16] <tonyyarusso> And as far as what portions of the code would need to be modified to use that, is it debian/rules, configure scripts, both, or anything else, so I can point Kaze in the right direction?
[07:17] <RAOF> Hobbsee: Ta.
[07:19] <Hobbsee> StevenK: make sure you -25.
[07:19] <StevenK> Heh
[07:20] <StevenK> I didn't. :-)
[07:22] <Hobbsee> for lateness, of course
[07:23] <TheMuso> tonyyarusso: debian/rules needs to have code in it to take copies of the files from autotools-dev during the clean target, I think thats when its done.
[07:23] <TheMuso> Haven't done it for a while.
[07:23] <tonyyarusso> TheMuso: That's a start anyway, thanks.
[07:45] <tonyyarusso> Is there any reason to give preference to one or the other naming scheme in debian/kompozer.dirs vs just debian/dirs, and other like files, or should it merely be consistent?  (or not matter at all)
[07:46] <Hobbsee> oh wow, that soon.
[07:46] <tonyyarusso> Hobbsee: Hence me staying up late trying to poke knowledgable folks ;)
[07:47] <tonyyarusso> That way I can shoot off an e-mail to Kaze with the remaining changes tonight, have him implement them in SVN in a few hours, review, rebuild, and get something on REVU before tomorrow night.
[07:48] <ScottK> tonyyarusso: How many binary packages does your source package make?
[07:48] <tonyyarusso> ScottK: 2.  kompozer and kompozer-dev.
[07:49] <ScottK> Then I believe you want kompozer.dirs for dirs needed in the kompozer package and kompozer-dev.dirs for the other (Although I'm not 100% sure on that).
[07:50] <Hobbsee> .dirs, or .install's?
[07:50] <tonyyarusso> ScottK: That sounds right to me.  Although, I find it curious that currently the file only includes /usr/bin...
[07:50] <tonyyarusso> Hobbsee: .dirs
[07:50] <Hobbsee> hmmm
[07:51] <StevenK> Does anything get installed to /usr/bin?
[07:51] <tonyyarusso> Of course, the /usr/bin/kompozer binary.
[07:51] <StevenK> I wonder if the upstream Makefile would mkdir it.
[07:52] <tonyyarusso> I thought there would be more in there though, but perhaps that's what .install means (I'm not entirely clear on these two files)
[07:52] <StevenK> .dirs is read by dh_installdirs and makes directories, .install is read by dh_install and copies stuff around.
[07:53] <tonyyarusso> But, /usr/bin of course is going to exist, so why must it be made?
[07:54] <Hobbsee> StevenK: oh, point
[07:54] <tonyyarusso> At least someone understood that :S
[07:55] <StevenK> tonyyarusso: Makes directories underneath the package install directory.
[07:56] <tonyyarusso> StevenK: ooh.
[07:56] <StevenK> tonyyarusso: So $(CURDIR)/debian/kompozer/usr/bin
[07:56] <tonyyarusso> like a chroot kind of thing
[07:57] <jussi01> Hmmm, anyone seen persia lately??
[07:58] <ScottK> jussi01: He's been busy with $WORK recently.  He responds to e-mail althougth not always immediately.
[07:58] <Hobbsee> he got stuck with $realwork
[07:58] <jussi01> hehe, ok then
[07:58] <minghua> I don't think you need .dir files if you use debhelper and have .install files.
[07:59] <minghua> For packages using debhelper, .dir is only necessary if you want to install an empty directory.
[07:59] <tonyyarusso> ok
[08:00] <tonyyarusso> That sounds right for the way it is then.
[08:07] <ScottK> man-di: If you are around, http://revu.tauware.de/details.py?upid=75 has a Java related question it'd be nice if you could have a look at.  Thanks.
[08:08] <RAOF> First mock-review done: telepathy-mission-control.
[08:08] <Hobbsee> StevenK: :D @ the mail
[08:10] <Hobbsee> sure sure
[08:10] <Hobbsee> it's shiny
[08:10] <RAOF> And clean, and new!
[08:10] <RAOF> and is a git snapshot : (
[08:11] <StevenK> Hobbsee: :-D
[08:12] <RAOF> Wow.  Revu comments get added to the URL.  Crazy.
[08:13] <Amaranth> what are you guys talking about?
[08:13] <RAOF> git-snapshot-xgl?  My MOTU application?  telepathy-mission-control?
[08:14] <RAOF> The fact that nvidia-glx-new kills WoW?
[08:14] <StevenK> How does nvidia-glx-new kill WoW?
[08:15] <RAOF> Wow segfaults on startup for me, with nvidia-glx-new.
[08:15] <RAOF> nvidia-glx works fine.  Huzzah for new-legacy!
[08:15] <tonyyarusso> What's the name of the tool for giving a timestamp in the format needed for debian/changelog?
[08:15] <RAOF> dch?
[08:16] <tonyyarusso> erm, no - just the one that prints a date string
[08:16] <tonyyarusso> Ah - 822-date.
[08:20] <Hobbsee> Amaranth: someone's emailing the MOTU ML about your crack, please deal with it.
[08:21] <Hobbsee> Amaranth: heh
[08:22] <Amaranth> ah, that
[08:22] <Amaranth> hello PPA bugs
[08:22] <Hobbsee> yeah
[08:26] <Amaranth> _something_ is different between what PPA says it has and what dpkg says it has so apt wants to get the PPA version
[08:26] <atnan> Howdy folks. Is this the right place to ask a quick question about dpkg-buildpackage?
[08:26] <Amaranth> then dpkg 'fixes' it
[08:27] <Amaranth> and we start all over
[08:27] <Amaranth> been looking for mvo so me, him, and cprov can point fingers at each other until someone figures out what the problem is :)
[08:27] <Hobbsee> Amaranth: i'd suggest an epoch, but i wouldnt like to be shot.
[08:27] <pygi> Amaranth, mvo was on vacation
[08:27] <Amaranth> oh, mvo just got on
[08:27] <Hobbsee> Amaranth: as in, yours would always overrule the ones in the repository
[08:27] <Amaranth> Hobbsee: eh?
[08:27] <Hobbsee> but it wouldnt be wise
[08:27] <Amaranth> no no
[08:28] <Hobbsee> Amaranth: oh, wait, i see now.
[08:28] <Amaranth> Hobbsee: you get the version from the PPA and dpkg changes the broken bit so they're different again
[08:28] <Hobbsee> yep
[08:28] <Amaranth> the original problem was the index saying Priority: Optional
[08:28] <Amaranth> that's fixed, now something else is broken
[08:30] <Hobbsee> minghua: ...what???
[08:31] <Hobbsee> way cool!
[08:32] <minghua> Hobbsee: A Chinese Ubuntu user reported a bug, you closed it as "Won't Fix", he wrote a blog post about the experience.
[08:32] <minghua> Hobbsee: http://c9s.blogspot.com/2007/08/firebug.html # if you are really curious
[08:32] <Hobbsee> minghua: as in, happy about it, or not happy about it?
[08:32] <Hobbsee> oh, that bug.
[08:33] <minghua> Hobbsee: Happy about the quick response, but still confused about where the problem exactly is, yet content with the workaround you recommended.
[08:33] <Hobbsee> minghua: right.
[08:34] <Hobbsee> minghua: well, based on the fact that it happens in all linux applications without using something like klipper or glipper, and all windows applications, (unsure about mac)...
[08:35] <Hobbsee> minghua: does it say which bug number?
[08:35] <minghua> Hobbsee: No.
[08:35] <Hobbsee> ah ok
[08:35] <Hobbsee> oh, found it
[08:36] <Hobbsee> jussi01: it's the equivalent of asking "why do right click and middle click do different things on linux" or something
[08:37] <Hobbsee> jussi01: all the time?
[08:37] <Hobbsee> or just between ubuntu and debian?
[08:38] <Hobbsee> er, raf
[08:38] <Hobbsee> er, RAOF
[08:38] <jussi01> lol
[08:41] <RAOF> Hobbsee: Uuuuum.  You mean... what exactly? :)
[08:41] <Hobbsee> RAOF: the md5sum
[08:42] <RAOF> Ah.  No.  Package on revu, grabbing the orig.tar.gz from debian/watch, there's an md5 sum mismatch between that recorded in the .dsc and upstream's tarball.
[08:43] <Hobbsee> ...interesting
[08:45] <RAOF> Hobbsee: Yeah, indeed.  bigiron, I think is the guy's irc nick.  I'll ping him next time I see him.
[08:45] <Hobbsee> RAOF: it's a .tar.gz presumably?
[08:45] <ScottK> Good night all.
[08:45] <RAOF> Hobbsee: Yes
[08:45] <RAOF> ScottK: Night
[08:45] <Hobbsee> night ScottK
[08:50] <tonyyarusso> Anybody have access to an amd64 box to test-build a package for me?
[08:50] <pygi> tonyyarusso, why dont you use qemu-pbuilder?
[08:50] <StevenK> % uname -m
[08:50] <StevenK> x86_64
[08:50] <StevenK> tonyyarusso: ^
[08:50] <tonyyarusso> pygi: Err, a) it's late and I've never tried it, b) seems resource-intensive
[08:50] <tonyyarusso> StevenK: Great - a sec while I upload it for you.
[08:52] <tonyyarusso> StevenK: How much do you need again?  The orig.tar.gz, dsc, diff.gz, and changes?
[08:53] <StevenK> tonyyarusso: Only the first three
[08:53] <tonyyarusso> kk
[08:53] <pygi> I was right, whee :)
[08:56] <tonyyarusso> StevenK: If it builds successfully, I have two other things I would also like you to check if you have a GUI:  a) Does it run?, b) Under Help > {Forums, Bug reports and suggestions, Support KompoZer, KompoZer's web site}, do any of those menu options successfully open the mentioned links in an external application?
[08:57] <RAOF> tonyyarusso: You *still* have the option of a shell account on an AMD64 box :)
[08:57] <tonyyarusso> RAOF: Yes, and thank you - but I may have to go to sleep rather than actually babysit it tonight.
[08:58] <RAOF> Heh.
[08:59] <tonyyarusso> (2AM, school in the morning)
[09:01] <StevenK> tonyyarusso: I shall do so when I get home, which will be in about hour.
[09:01] <StevenK> tonyyarusso: And where is the link to the .dsc? :-)
[09:02] <tonyyarusso> StevenK: Fantastic.
[09:02] <tonyyarusso> (uploading...)
[09:02] <StevenK> Ah, okay. :-)
[09:02] <coNP> lazly hmmm
[09:02] <coNP> Good morning
[09:02] <coNP> Sory
[09:02] <coNP> (for the first one)
[09:03] <TheMuso> Hey coNP.
[09:03] <tonyyarusso> StevenK: I'll be going to bed here, but you can leave any results/notes a) here with my nick for the awaylog, b) in ##tonyyarusso, c) in PM, or d) [esp if I get disconnected - power may go out in storm]  $thisnick @ ubuntu.com
[09:03] <tonyyarusso> However you prefer :P
[09:04] <StevenK> tonyyarusso: I shall pick one of them.
[09:05] <coNP> e.g. where to find GPL if the location of GPL-2 is shown is not a problem for me.
[09:06] <tonyyarusso> StevenK: http://www.tonyyarusso.com/kompozer_0.7.10.orig.tar.gz, http://www.tonyyarusso.com/kompozer_0.7.10-0ubuntu1.diff.gz, http://www.tonyyarusso.com/kompozer_0.7.10-0ubuntu1.dsc
[09:12] <StevenK> Ouch. A 37Mb orig.
[09:13] <RAOF> Woooo!
[09:14] <coNP> boswars has 47M :)
[09:14] <StevenK> Yeah, but I wasn't asked to test build boswars.
[09:17] <StevenK> It Build-Depends on zip? What the ....
[09:33] <superm1> i just advocated scolily after its update if someone else wants to look it over: http://revu.tauware.de/details.py?upid=99
[09:36] <coNP> I guess this means I can upload it.
[09:36] <LaserJock> hi all, I'm looking for a reference on package versioning
[09:37] <LaserJock> in particular I'm wondering about the use of ~
[09:37] <superm1> LaserJock, it means that it is less than a current version doesn't it?
[09:37] <coNP> superm1: so can I upload? :)
[09:37] <LaserJock> as in the Debian Policy it says that on alphanumeric numbers and + . are allowed
[09:37] <superm1> so if you do 0ubuntu1~ppa1, it will be less than 0ubuntu1
[09:37] <Amaranth> -0ubuntu1 > -0ubuntu1~foo
[09:37] <superm1> coNP, yup :)
[09:37] <Amaranth> that's what it's for
[09:37] <superm1> it uses commonly when you have a third party repo you want to be of lower priority
[09:37] <superm1> or a backport
[09:37] <LaserJock> Amaranth: yes, but I can't find a reference for that anywhere
[09:38] <LaserJock> I know what it does
[09:38] <Amaranth> LaserJock: it's one of those things everyone learns and so no one bothers to document :P
[09:38] <coNP> Is there an easier way to upload than with dget && dput?
[09:38] <LaserJock> I'm trying to figure out *why* it does that
[09:38] <coNP> I mean some script that puts REVU upload #N to the Ubuntu archives.
[09:38] <LaserJock> coNP: easier?
[09:38] <LaserJock> no
[09:38] <Amaranth> LaserJock: i believe it's by design
[09:38] <coNP> e.g., $ revu-upload 99
[09:39] <LaserJock> and I don't think that should be automated
[09:39] <siretart> coNP: I have something like that in mind for revu2
[09:39] <LaserJock> we should be quite careful about what we upload to NEW
[09:39] <siretart> btw, I actually started to code on the first unit tests for revu2 yesterday :)
[09:39] <coNP> I guess it were to easy to hit the "upload" instead of "advocate"...
[09:39] <LaserJock> siretart: \o/
[09:39] <LaserJock> coNP: you still have to sign the package to upload
[09:40] <coNP> Is that automatic?
[09:40] <LaserJock> so the script would have to sign it for you
[09:40] <LaserJock> no
[09:40] <siretart> well, you can automate that using an gpg agent
[09:40] <coNP> So how do I upload from REVU? I dget
[09:40] <coNP> and then dput?
[09:40] <TheMuso> debsign<EMAIL_ADDRESS>changesfile
[09:40] <RAOF> Has anyone thought of using revu's PPA to do automated builds of everything on REVU?
[09:40] <siretart> RAOF: yes
[09:40] <LaserJock> I use dget, then rebuild using debuild -S -k<keyid>
[09:40] <LaserJock> then dput
[09:41] <RAOF> Thought so, it's an obvious option :)
[09:41] <siretart> RAOF: that's the plan for revu2. no more uploading, but fetching from e.g. PPA archives
[09:41] <RAOF> Ah, slightly different.  Still good.
[09:41] <LaserJock> well
[09:42] <LaserJock> you should *always* download the package to be reviewed
[09:42] <LaserJock> and look at it, build it, test it
[09:42] <LaserJock> I don't think you can automate that
[09:42] <coNP> LaserJock: I should debuild -S -sa -k<keyid>, right? Since it is a new package.
[09:42] <LaserJock> yes
[09:43] <LaserJock> I was shorthanding it ;-)
[09:43] <coNP> Okay. Just to make sure I don't make _that_ mistake :)
[09:43] <LaserJock> so dput is the fastest thing I do when I'm reviewing
[09:43] <\sh> Well, I see a problem with PPAs, regarding the "You have to become an ubuntero for using it"
[09:43] <superm1> well also, you can't upload the same revision over and over like on REVU
[09:43] <\sh> not everone wants to sign the CoC...
[09:43] <siretart> \sh: what's the problem with that?
[09:44] <LaserJock> \sh: I think being an "ubuntero" is required to for most things
[09:44] <siretart> if you don't like it, don't use it
[09:44] <superm1> you'll have to bump ubuntuX, or add a ~extrainfoX
[09:44] <LaserJock> although probably not strictly enforced
[09:44] <LaserJock> superm1: I think we were wanting to us ~ppa for the PPA packages
[09:44] <LaserJock> to keep things separate
[09:45] <\sh> LaserJock, regarding the ubuntu project, yes, regarding just to fire a package into a repository, no. When upstream decides e.g. to just push a package of source to ubuntu, someone else has to upload it anyways...for what do I need to be an ubuntero to upload a testpackage in my personal PPA?
[09:45] <LaserJock> so ~ppa1 ~ppa2 etc.
[09:45] <RAOF> All my ppa packages have a ~ppax suffix
[09:45] <\sh> siretart, that wasn't the intention :)
[09:45] <superm1> right, well i was thinking revu ppa packages might make sense to have ~revuX
[09:45] <siretart> \sh: but what then?
[09:45] <superm1> and then perhaps the MOTU who finally grabs it to upload it has to modify that last version number
[09:45] <LaserJock> \sh: well, as a long term thing I'm sure it won't be a requirement as LP isn't Ubuntu-specific
[09:45] <\sh> LaserJock, that's the intention ;)
[09:46] <LaserJock> \sh: but they want some recognition that you are going to "play by the words"
[09:46] <LaserJock> "play by the rules" rather
[09:46] <LaserJock> there is a "Terms of Service" after all
[09:46] <RAOF> Possibly play by the spirit :)
[09:46] <superm1> LaserJock, http://lwn.net/Articles/194664/
[09:46] <superm1> that is the only thing i've found thus far
[09:47] <LaserJock> signing the CoC is pretty trivial and unlikely to upset that many people
[09:47] <\sh> but as a dependency to use PPAs, I find it useless and pushing people away... a signature to the "terms of service" that's ok
[09:47] <LaserJock> what's the difference?
[09:47] <siretart> \sh: what depends on using PPAs?
[09:47] <LaserJock> I think you need a gpg key anyway
[09:47] <\sh> siretart, signing the CoC
[09:47] <LaserJock> you might as well do something with it ;-)
[09:48] <\sh> LaserJock, the gpg key is for checking if your signed package is signed by you...no need to sign something else then the .dsc / changes file
[09:48] <superm1> i'm imagining once they implement Release file signing, it will be used in some fashion with that too
[09:48] <LaserJock> \sh: meh, there's bigger issues, but I can kinda see your point
[09:49] <LaserJock> \sh: I think there's more to turn off people
[09:49] <LaserJock> like oh, it being proprietary ;-)
[09:49] <\sh> LaserJock, for example, yes
[09:49] <coNP> \sh: but you don't have changes file if you don't rebuild the package. Am I wrong?
[09:50] <LaserJock> I think they need to at least make it more general than Ubuntu's CoC
[09:50] <LaserJock> but right now you can only make Ubuntu packages
[09:50] <LaserJock> so it's not a big deal
[09:50] <\sh> coNP, if you do a debuild -S [ -sa -k<your key>]  you have always a changes file, that's the purpose ;)
[09:50] <coNP> sure
[09:50] <\sh> coNP, PPAs are not for binary uploads
[09:51] <coNP> Oh, not regarding PPAs, only in general
[09:52] <LaserJock> heh
[09:52] <LaserJock> coNP: thanks for that link, that's pretty much exactly the kind of thing I was looking for
[09:52] <LaserJock> coNP: but it's odd that it's not in the Debian Policy that I can see
[09:52] <superm1> LaserJock, that was me, not coNP :)
[09:52] <LaserJock> pfft
[09:52] <LaserJock> sorry
[09:52] <coNP> Yeah.
[09:53] <LaserJock> no ponies for coNP
[09:53] <coNP> superm1 is not even as MOTU-old as I am
[09:53] <superm1> haha.... by like one day
[09:53] <coNP> out of 4... :)
[09:53] <LaserJock> shesh, youngin's
[09:54] <superm1> LaserJock, i swear i saw it somewhere else when i first read about it.  i need to start tagging my things on del.icio.us better
[09:54] <superm1> something more debian officially
[09:54] <LaserJock> let's see I've been a MOTU for around 1.5 years
[09:54] <LaserJock> \sh is even more MOTU-old than me
[09:55] <coNP> Let us define a (partial) order relation MOTU-old
[09:56] <RAOF> coNP: Isn't that going to be a total ordering?
[09:56] <coNP> Depends on.
[09:56] <coNP> In theory TB can approve more then one MOTU in an email.
[09:56] <coNP> OTOH there is no LP batch activation
[09:58] <RAOF> Hm.  So it depends on the particular definition of motu-old
[09:58] <LaserJock> what about the MOTUs before LP? :-)
[09:58] <LaserJock> there might even be MOTUs from before TB but I'm not sure
[09:58] <coNP> LaserJock: that is history, not mathematics...
[09:59] <LaserJock> lol
[09:59] <superm1> wow.  that feels like such a long time ago, before LP :)
[09:59] <coNP> Yeah. That is the point.
[09:59] <LaserJock> I remember when MOTU was the only people using LP
[09:59] <coNP> (if it really FTBFS, since I remember checking that)
[09:59] <superm1> coNP, it only FTBFS on pbuilder
[10:00] <superm1> sbuild misses it
[10:00] <coNP> that is the point that worries me
[10:03] <coNP> In fact I did a "revu-review gtkglextmm__1.2.0-0ubuntu1.dsc"
[10:05] <LaserJock> why?
[10:06] <coNP> esp. the term Laser refers to the stone age
[10:06] <LaserJock> not sure why, I guess I'm not smart enough to script everything ;-)
[10:06] <superm1> because they are shiny, and untried for me yet.
[10:06] <superm1> and i like shiny things
[10:06] <coNP> They are not shiny IMHO
[10:06] <LaserJock> coNP: heh
[10:06] <LaserJock> shiny things can often get you into trouble
[10:07] <\sh> LaserJock, /me is not an motu anymore...just a random ranter I am ,-)
[10:07] <coNP> It says: The debuild test (debuild && debuild -S) didn't generate files outside of debian/
[10:07] <coNP> That is not true since it FTBFS...
[10:07] <coNP> At least superm1 says so :)
[10:08] <coNP> Okay, that might be true. But should not say "did not generate files" but "failed"
[10:08] <coNP> (since exit 1 does not generate any files)
[10:08] <superm1> coNP, well i look a little closer, and i think i see why it is FTBFS in pbuilder.  its not the Makefile thing, (but that is troublesome), it is the second thing i commented on about not having the ubuntu maintainer
[10:08] <LaserJock> \sh: emeritus MOTU ?
[10:09] <\sh> LaserJock, !translate emeritus ,-)
[10:10] <LaserJock> \sh: that's what we do to university professors who retire, but don't really retire
[10:10] <LaserJock> we give them emeritus professor status
[10:10] <LaserJock> which means they get a little office, but don't have any work to do
[10:11] <coNP> Hey ThibG! Congratulations :)
[10:11] <ThibG> Hi coNP, thanks :)
[10:11] <\sh> LaserJock, well, I'm on a higher level then emeritus then ;-)...I'm looking over several distro projects ,-)
[10:11] <coNP> ThibG: thank to superm1 :)
[10:11] <ThibG> Though I have to fix some bugs
[10:11] <\sh> hey neversfelde|mobi
[10:11] <coNP> ThibG: upstream or packaging bugs?
[10:11] <ThibG> cdbs-edit-patch 01-<patch name>?
[10:11] <ThibG> upstream
[10:12] <superm1> ThibG, well its good you got it in by Aug30, still can fix upstream bugs this next month :)
[10:12] <coNP> In fact you can fix bugs in the upstream tar.gz as well till tomorrow :)
[10:13] <ThibG> yeah coNP, but I've already released a few weeks ago
[10:13] <neversfelde|mobi> hello \sh
[10:15] <ThibG> I think the best way is to make some cdbs patches for the major bugs, until I release a new upstream version
[10:15] <coNP> Sure. But it is always better if you have fixes in the .orig.tar.gz
[10:16] <ThibG> hm yes
[10:18] <ThibG> ok, coNP, I'm going to make a minor upstream release
[10:25] <coNP> ThibG: I think bugfix releases are not term of the UVF anyway.
[10:27] <ThibG> UVF?
[10:27] <superm1> coNP, if that's the case there is a flaw in that explanation.  A "bug" can be termed, add feature X to program Y :)
[10:27] <coNP> ? UVF
[10:27] <coNP> !UVF
[10:27] <ubotu> uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[10:28] <ThibG> ok
[10:46] <ThibG> coNP, I'm going to upload a new package ( no modification to debian/ except the version in the changelog ) with the new upstream bugfix release
[10:46] <coNP> ThibG: feel free to ping me if you want to get it reviewed
[10:47] <ThibG> coNP, that's uploaded
[11:00] <bmm> Any MOTU: I'm looking for advocates for boswars and (almost had two): http://revu.tauware.de/details.py?upid=101
[11:00] <coNP> Hey bmm.
[11:00] <bmm> coNP: hey
[11:00] <coNP> If you fix the latest copyright issue I guess you can find us again :)
[11:01] <bmm> coNP: that's why I'm here ;-)
[11:01] <Bixente> hi
[11:01] <bmm> But I can't stay, got to go. I'll be back in a few hours but have to attend a meeting. Laters all and thanks for the reviews!
[11:02] <Bixente> I'm looking for someone to review this package : http://revu.tauware.de/details.py?upid=103 thanks
[11:08] <coNP> bug 134623, bug 134624, bug 134625
[11:08] <ubotu> Launchpad bug 134623 in telepathy-salut "[UVFe]  Please update telepathy-salut to version 0.1.4" [Undecided,New]  https://launchpad.net/bugs/134623
[11:08] <ubotu> Launchpad bug 134624 in telepathy-mission-control "[UVFe]  Please update telepathy-mission-control to version 4.35" [Undecided,New]  https://launchpad.net/bugs/134624
[11:08] <ubotu> Launchpad bug 134625 in empathy "[UVFe]  Please update empathy to version 0.12" [Undecided,New]  https://launchpad.net/bugs/134625
[11:08] <coNP> Any nice MOTU UVF member would be so kind to check these? :)
[11:10] <coNP> e.g., soren or StevenK or LongPointyStick :)
[11:12] <lucas> what's the current state of universe/multiverse rebuilds?
[11:12] <lucas> is universe/multiverse included in the "normal" archive rebuilds?
[11:12] <siretart> lucas: I don't think so
[11:12] <siretart> lucas: but you would have to ask I think infinity or doko for that
[11:13] <lucas> so a rebuild would be useful?
[11:13] <siretart> I think so!
[11:13] <ThibG> coNP, oh, it appears scolily has been archived :s
[11:14] <coNP> Gnight, superm1
[11:16] <ThibG> yeah, coNP, but I've dput a new version... What am I supposed to do?
[11:16] <coNP> ThibG: I archived the new one, you mean?
[11:17] <ThibG> no
[11:17] <ThibG> ok
[11:17] <ThibG> thanks
[11:46] <coNP> ThibG: the dice is cast. You cannot make another initial release of scolily.
[11:47] <coNP> Actually you should have not uploaded 0.4.0 if you knew that you still has to fix bugs.
[11:47] <coNP> But since you uploaded and let it reviewed and uploaded, all you can do is to make a bugfix update
[11:50] <ThibG> coNP, ok
[11:53] <ThibG> so, I revert debian/changelog and add a new entry, with the new version?
[11:54] <coNP> You make a package update.
[11:54] <coNP> However 0.4.0 has not appeared in the archives.
[11:54] <coNP> Some more experienced MOTU might have another advice
[11:55] <ThibG> ok
[11:55] <geser> coNP: it's in the NEW queue now (https://launchpad.net/ubuntu/gutsy/+queue)
[11:55] <coNP> geser: yes, I know.
[11:55] <coNP> But I think it cannot be updated while it is there.
[11:58] <geser> coNP: ask an archive admin, they should know it
[11:58] <coNP> okay, thanks
[12:37] <andrea-bs> I want to debianize a python module, but I want to know how to generate bytecodes, because the policy doesn't permitt to add pyc in the deb package. Does anybody can help me, please?
[12:38] <POX_> andrea-bs: use python-support or python-central, it will handle pyc files
[12:38] <RAOF> andrea-bs: There are two tools to automate that process
[12:38] <warp10> Hi all
[12:38] <RAOF> andrea-bs: And POX_ has just named them :)
[12:39] <RAOF> POX_: Hey :)
[12:39] <POX_> hi :)
[12:39] <andrea-bs> yes, but there are no pyc in pycentral/python-support directories
[12:39] <POX_> andrea-bs: http://python-modules.alioth.debian.org/python-central_howto.txt
[12:40] <POX_> pyc files will be compiled on clients machine
[12:41] <andrea-bs> andrea@andrea-desktop:/usr/share/python-support$ ls -aAR | grep pyc
[12:41] <andrea-bs> pychecker
[12:41] <andrea-bs> ./pychecker:
[12:41] <andrea-bs> pychecker
[12:41] <andrea-bs> ./pychecker/pychecker:
[12:41] <andrea-bs> GnuPGInterface.pyc
[12:42] <andrea-bs> the only bytecode is GnuPGInterface.pyc
[12:42] <POX_> andrea-bs: /var/lib/python-support/python2.5/
[12:43] <andrea-bs> oh, thanks
[12:43] <POX_> python central uses /usr/lib/python2.5/
[12:44] <andrea-bs> POX_, thank you very much
[12:44] <andrea-bs> I've never seen this folder
[12:45] <POX_> you don't have to, dh_pycentral/dh_pysupports handles all
[12:45] <POX_> all you need to do is call it in debian/rules
[12:45] <andrea-bs> yes, tnx
[12:54] <simu> hi, how to a package non binary stuff like perl tools
[01:10] <coNP> mok0: we added some comments to your upload on REVU
[01:11] <mok0> coNP: Yes thx, I am working on it
[01:11] <mok0> Another upload is ready soon :-)
[01:11] <mok0> coNP: Thanks!
[01:12] <mok0> I have a q concerning the GPL issue you raised
[01:12] <mok0> I don't know what you mean
[01:14] <mok0> coNP: what do you mean I should specify in the GPL2/GPL3 q?
[01:22] <Kamping_Kaiser> are there scripts that run as part of removing a package?
[01:22] <mok0> Kamping_Kaiser: yes, prerm and postrm
[01:22] <Kamping_Kaiser> mok0, thanks
[01:25] <DktrKranz> geser, are you going to look after drupal5 merge? debian provided a patch for a security fix, so it could be worth manage it
[01:27] <Kamping_Kaiser> should i take # dh_installdeb will replace this with shell code automatically
[01:27] <Kamping_Kaiser> # generated by other debhelper scripts.
[01:27] <Kamping_Kaiser> to mean that all shell in the file is autogenerated somewhere/how?
[01:28] <ThibG> coNP, I uploaded scolily once again, as a package update, and not a new initial release
[01:28] <geser> DktrKranz: which security patch? the changelog for drupal5 5.2-2 doesn't mention a security patch
[01:29] <DktrKranz> geser, in debian 435433 user pointed to http://drupal.org/drupal-5.2
[01:30] <ubotu> Debian bug 435433 in drupal5 "drupal5: settings.php not upgraded with 5.2" [Grave,Fixed]  http://bugs.debian.org/435433
[01:30] <DktrKranz> especially the note at the bottom part of the page
[01:32] <geser> the changelog entry is really bad written for containing a security fix :(
[01:33] <geser> DktrKranz, thanks for noticing it
[01:33] <DktrKranz> np, thanks for confirming
[01:34] <geser> DktrKranz: if you have time you can go and merge drupal5, I won't find time before thursday or friday for merging
[01:34] <DktrKranz> ok, I'll do later this evening
[01:34] <DktrKranz> or at least tomorrow
[01:34] <DktrKranz> *last
[01:40] <Kamping_Kaiser> can someone look at the patch i just attached to bug 84487 ? i dont run gutsy, so i cant test it.
[01:40] <ubotu> Launchpad bug 84487 in backuppc "removing deb leaves symlink which causes apache to fail starting" [Undecided,New]  https://launchpad.net/bugs/84487
[01:43] <DktrKranz> Kamping_Kaiser, do you know if that symlink is created by backuppc package during its installation=
[01:45] <Kamping_Kaiser> DktrKranz, it seems to be make by the postinst file : ln -s /etc/backuppc/apache.conf /etc/$webserver/conf.d/backuppc.conf
[01:46] <DktrKranz> Kamping_Kaiser, thanks. I will try to reproduce that bug later this evening. will you be around?
[01:47] <Kamping_Kaiser> DktrKranz, i can be around for a few hours
[01:49] <DktrKranz> ok, I'll post some results as a comment, then
[01:49] <Kamping_Kaiser> thanks.
[01:49] <DktrKranz> thanks to you :)
[01:49] <Kamping_Kaiser> hehe. np. if it works, its one of those silly fixes
[01:50] <DktrKranz> if you want, you can prepare a debdiff in order to get your fix uploaded if it is ok
[01:51] <Kamping_Kaiser> i'd have to build it wouldnt i?
[01:53] <DktrKranz> you should
[01:54] <DktrKranz> if you ever need some hints, you may look at https://wiki.ubuntu.com/MOTU/Recipes/Debdiff
[01:54] <Kamping_Kaiser> hehe. probably . i should probalby also relearn docbook, switch to emacs and still find room to get a life ;)
[01:55] <DktrKranz> in order of difficulty? :)
[01:56] <Kamping_Kaiser> i was actually thinking reverse order *grin*
[01:56] <Kamping_Kaiser> thanks for the link, dont think it existed last time i tried a debdiff
[01:56] <DktrKranz> no, it has recently added to ubuntu wiki
[01:57] <DktrKranz> gotta go now, see you
[01:57] <Kamping_Kaiser> hm... thats a lot of work for an 8 character patch.
[02:02] <tsmithe> man-di, have you had a chance to look at wired yet?
[02:03] <man-di> nope, I was away on the weekend
[02:03] <man-di> tsmithe: can you please tell me why it was rejected last time from ftp-master?
[02:03] <man-di> tsmithe: I dont remember anymore
[02:03] <tsmithe> ok hang on
[02:04] <tsmithe> resource/alba_font wasnt dfsg-free
[02:04] <tsmithe> i've since fixed that :)
[02:05] <man-di> ah, right
[02:05] <sacater> guys, my gutsty lappy cant get kde of of the repos
[02:05] <sacater> whatsa goin ona
[02:05] <tsmithe> hehe
[02:06] <man-di> grrrrrrr, my machine is home rejects to boot on WOL
[02:06] <man-di> s/is/at/
[02:06] <sacater> can someone check the gutsy repo for me
[02:06] <sacater> checking that kde is there
[02:07] <zul> im pretty sure its there
[02:07] <sacater> kdepim
[02:07] <sacater> and some othe libs
[02:07] <tsmithe> yes there for me
[02:07] <sacater> hmm
[02:07] <sacater> let me do a nopaste of the error synaptic gives me
[02:08] <sacater> http://nopaste.com/p/aF6n5CFx1
[02:08] <sacater> enjoy
[02:09] <geser> when did you last update the package lists?
[02:10] <sacater> no idea
[02:10] <sacater> the lappy is not using online
[02:10] <geser> update the package lists (sudo apt-get update) and try again
[02:10] <sacater> k
[02:10] <sacater> one sec
[02:10] <harrisony> sacater, do what geser says :)
[02:12] <sacater> k
[02:15] <sacater> trying now
[02:21] <geser> Hi Hobbsee
[02:22] <zul> hey Hobbsee
[02:22] <Hobbsee> hi geser
[02:23] <Hobbsee> hiya zul
[02:27] <ScottK> Good morning all.
[02:27] <StevenK> Morning ScottK
[02:27] <kompozer> morning :)
[02:27] <geser> Hi ScottK
[02:28] <ScottK> Hello StevenK, kompozer, and geser.
[02:29] <Kamping_Kaiser> fyi, i attached a debdiff to the bug as DktrKranz suggested... not knowing if it works it seems overkill though
[02:30] <ScottK> BTW, http://revu.tauware.de/details.py?upid=105 is finally ready for a real "I'm think this should be uploaded" look by another MOTU.  It's a Python extension package.
[02:34] <mok0> is there any way I can see what dpkg -i is doing in details?
[02:34] <mok0> I am mysteriously missing a file which is _present_ in the deb
[02:35] <Hobbsee> actually, apt has a debug mode, but i dont remember how to call it
[02:35] <StevenK> dpkg -c to see if the .deb has the file.
[02:36] <mok0> StevenK: I does
[02:36] <mok0> s/I/it
[02:36] <StevenK> And it doesn't get installed?
[02:36] <mok0> StevenK: Hmm. It ought to be,
[02:37] <POX_> ScottK: looks ok to me
[02:37] <mok0> StevenK: Could it be removed by the postrm script?
[02:37] <ScottK> POX_: Thanks.  I do intend to bring this one to the DPMT team in a bit.
[02:37] <broonie> You can add -x to the maintainer script #! lines to get trace from the maintainer scripts.
[02:38] <StevenK> Or any of the scripts.
[02:38] <broonie> (a log of all the commands run)
[02:38] <mok0> broonie: good idea
[02:46] <geser> ScottK: I've two exams in the next two days, so I've currently no time for MOTU work
[02:47] <ScottK> geser: OK.  Undertand.
[02:47] <ScottK> Understand even.
[02:47] <xxxxx1> mornin' all
[02:48] <ScottK> Morning xxxxx1.
[02:48] <ScottK> Hobbsee: You told me to remind you about this: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/134625/comments/6 on Monday.
[02:48] <ubotu> Launchpad bug 134625 in empathy "[UVFe]  Please update empathy to version 0.12" [Undecided,New]
[02:50] <xxxxx1> hey ScottK
[02:51] <norsetto> afternoon everybody
[02:51] <geser> Hi norsetto
[02:52] <Bixente> hi
[02:52] <norsetto> geser: hiya
[02:52] <Bixente> I'm looking for someone to review this package : http://revu.tauware.de/details.py?upid=103 thanks
[02:52] <ScottK> Heya norsetto.  Thank you very much for the patch.  It was just what the doctor ordered.  I immortalized your contribution in debian/changelog.
[02:52] <norsetto> ScottK: don't even mention it
[02:52] <ScottK> norsetto: To late, already did.
[02:54] <siretart> wow!
[02:54] <Hobbsee> good evening, siretart
[02:54] <RAOF> Bixente: I'm reviewing it righ now, actually.
[02:55] <Bixente> RAOF: thanks
[02:57] <siretart> hi Hobbsee
[02:57] <Hobbsee> ScottK: *mumble*.  thanks
[02:57] <ScottK> Hobbsee: No problem ;-)
[02:57] <Hobbsee> ScottK: i should have requested an email or something
[03:12] <RAOF> Bixente: Reviewed.  There are some problems, most of which should be easy to fix, the biggest of which being that nothing actually calls dh_pycentral.
[03:13] <tonyyarusso> Is there a REVU admin in the house?
[03:13] <RAOF> Bixente: I'm off to bed now, but if you want that reviewed again later, I should be able to get to it tomorrow.
[03:13] <Hobbsee> tonyyarusso: yes
[03:13] <Bixente> RAOF: thanks for your review :)
[03:14] <tonyyarusso> Hobbsee: I am already in the contributors group and such, but I had to create a new key (5E1E6F1A) so I would like a key re-sync done.
[03:14] <Hobbsee> tonyyarusso: the new key is with your LP id in the revu group?
[03:14] <tonyyarusso> (may have already happened via cron - I'm not sure)
[03:15] <RAOF> bigon: Ooh, your on.  Sadly, I'm off to bed, but I looked at reviewing telepathy-mission-control.
[03:15] <Hobbsee> tonyyarusso: cron isnt happening atm
[03:15] <tonyyarusso> Hobbsee: It is the default for me on LP now, yes.
[03:16] <RAOF> bigon: There are a couple of little niggles there, and one big one (the silent dropping of a patch from previous versions).
[03:17] <Hobbsee> siretart: keys are buggered again.
[03:17] <Hobbsee> oh, wait
[03:19] <Hobbsee> siretart: hooray, working.
[03:20] <Hobbsee> tonyyarusso: it's probably going to take an hour or so
[03:22] <tonyyarusso> Hobbsee: That's fine - I won't actually need it for a few yet, but wanted to make sure it was ready.  Thank you.
[03:22] <siretart> Hobbsee: :)
[03:22] <Hobbsee> :)
[03:28] <zul> do do do
[03:35] <bigon> RAOF: are you still there?
[03:44] <dhdfoo> hi, I accidentally uploaded binary packages to REVU - can I use dcut to remove the upload?
[03:44] <Hobbsee> dhdfoo: no
[03:44] <dhdfoo> hmm :(
[03:44] <dhdfoo> is there someone here who could remove it for me?
[03:45] <Hobbsee> yeah
[03:45] <dhdfoo> it is the sphinxbase upload ...
[03:45] <dhdfoo> thanks!
[03:45] <Hobbsee> who's dhuggins ?
[03:45] <dhdfoo> that is me
[03:45] <Hobbsee> oh, it is yuo
[03:46] <Hobbsee> dhdfoo: why were you asking if dcut worked, when you'd already tried it?
[03:46] <dhdfoo> well, I was just wondering if it would really remove the upload
[03:46] <Hobbsee> dhdfoo: it doesnt
[03:46] <dhdfoo> I figured I might as well try it
[03:46] <dhdfoo> ok
[03:46] <dhdfoo> thanks for the info
[03:46] <Hobbsee> dhdfoo: you should be able to reupload
[03:46] <dhdfoo> I'm uploading source packages now
[03:46] <dhdfoo> yeah
[03:59] <sacater> hey all, the kde thing was fixed
[03:59] <sacater> apt-get update needed to be run
[04:00] <Hobbsee> what kde thing/
[04:00] <sacater> oh something earlier
[04:00] <sacater> my gutsy couldnt find some kde packages
[04:00] <sacater> in the repos
[04:00] <Hobbsee> ah
[04:00] <sacater> apt-get update cured it
[04:03] <sacater> geser: ty
[04:03] <AndyP> woo more team maintainership in debian
[04:03] <AndyP> (re: python apps team)
[04:06] <jeromeg> Anyone from motu-uvf to tel me if my UVFe request at bug 134730 is ok now ?
[04:06] <ubotu> Launchpad bug 134730 in dvgrab "[UVFe] Please sync dvgrab 3.0-1 (universe) from debian (unstable)" [Wishlist,New]  https://launchpad.net/bugs/134730
[04:12] <ScottK> jeromeg: It looks reasonably good, but since the firewire interface is completely redone, I don't feel comfortable approving it without that tested (others may feel differently).
[04:13] <jeromeg> ScottK: well I've been waiting for 15 days (at least) to have a tester to test my upgrade -> without success, then it got into debian so I asked for the sync
[04:14] <jeromeg> ScottK: so I doubt we'll have a tester before string freeze
[04:14] <ScottK> Anyone here have a firewire DV camera and a fireware interface on their PC?
[04:15] <ScottK> jeromeg: Are you the upstream for this?
[04:15] <jeromeg> ScottK: no
[04:15] <xtknight> ScottK, i have a firewire DVR (digital video recorder) but not camcorder
[04:15] <xtknight> i have transferred video off of it to linux
[04:16] <ScottK> xtknight: That might work.
[04:16] <xtknight> what's the deal?
[04:16] <ScottK> jeromeg: You know the package better, would that work?
[04:16] <geser> ScottK: I could test end of the week
[04:16] <ScottK> xtknight: Bug 134730 is the deal.
[04:16] <ubotu> Launchpad bug 134730 in dvgrab "[UVFe] Please sync dvgrab 3.0-1 (universe) from debian (unstable)" [Wishlist,New]  https://launchpad.net/bugs/134730
[04:16] <xtknight> ahh
[04:16] <ScottK> geser: That'd be great if no one else can.
[04:17] <jeromeg> xtknight, geser : bug 134730 , it should detect your camera automatically
[04:17] <xtknight> unfortunately my DVR only works with a hack (e.g. http://www.avsforum.com/avs-vb/showthread.php?s=26b61f1a33b8e11ff2bec293427e9888&p=11328305#post11328305 )
[04:17] <xtknight> i dont believe it ever worked with dvgrab, but i can see
[04:18] <jeromeg> xtknight: well it's a brand new version so it might work
[04:18] <geser> jeromeg: I've added it to my TODO list
[04:18] <jeromeg> geser : thanks a lot !
[04:19] <jeromeg> ScottK: thx for your review
[04:20] <xtknight> trying it as we speak
[04:20] <ScottK> jeromeg: No problem.
[04:20] <xtknight> i would like this to work too, all the hacks really are a pain
[04:24] <xtknight> jeromeg, which deb package should i be trying?  or *.dsc,*.diff.gz,*.orig* are fine too
[04:24] <jeromeg> xtknight: I can give you a build deb package if you want
[04:25] <norsetto> any kind soul can paste some comments I have on a package which is in REVU?
[04:25] <xtknight> jeromeg,  if no deb is ready compiling from source isn't a problem.
[04:25] <jeromeg> xtknight: i think i have one on my ftp, just a second
[04:26] <jeromeg> xtknight: http://vv.guelf.free.fr/ubuntu/firefox/ -> first package of the list, it's a gutsy package
[04:26] <coNP> Hey norsetto. I can
[04:26] <norsetto> coNP: thx, pastebin or email?
[04:27] <coNP> norsetto: whichever you prefer
[04:27] <norsetto> coNP: ok, email is on its way: thx :-)
[04:27] <coNP> thank *you*, No1Viking
[04:27] <xtknight> jeromeg, thanks
[04:27] <coNP> norsetto even :)
[04:27] <jeromeg> xtknight: np
[04:28] <xtknight> jeromeg, should i just force-arch for amd64?
[04:28] <xtknight> or rebuild :p
[04:28] <norsetto> coNP: I would also appreciate if you give them a quick look, you know, just in case .....
[04:28] <coNP> norsetto: which package?
[04:28] <norsetto> coNP: sdlmame (my nemesis!)
[04:29] <jeromeg> xtknight: mmm i don't know :) , maybe rebuild is better :)
[04:30] <xtknight> jeromeg, alright.  i'm going to use the dsc and tars here, for reference.  http://packages.debian.org/unstable/graphics/dvgrab
[04:30] <coNP> Any MOTU-UVF can please have a a look at bug 134623, bug 134624
[04:30] <ubotu> Launchpad bug 134623 in telepathy-salut "[UVFe]  Please update telepathy-salut to version 0.1.4" [Undecided,New]  https://launchpad.net/bugs/134623
[04:30] <ubotu> Launchpad bug 134624 in telepathy-mission-control "[UVFe]  Please update telepathy-mission-control to version 4.35" [Undecided,New]  https://launchpad.net/bugs/134624
[04:30] <ScottK> coNP: Got a minute for a review?
[04:30] <coNP> ScottK: yes.
[04:30] <ScottK> coNP: It works now... http://revu.tauware.de/details.py?upid=105
[04:30] <ScottK> coNP: Looking
[04:31] <coNP> ScottK: you did approve
[04:31] <jeromeg> xtknight: ok thank you
[04:31] <coNP> ScottK: I mean Hobbsee, soren, StevenK or zul is missing to get 2 out of 5
[04:31] <ScottK> Ah.  Then I don't need to look again.  IIRC Hobbsee said she'd ack those.
[04:31] <Hobbsee> i said i'd look at those.  at some point
[04:32] <Hobbsee> when i'm not bashing people with large piles of concrete
[04:32] <coNP> Okay. No push. No rush. Just a bit of those :)
[04:32] <Hobbsee> feel free to hijack.
[04:32] <StevenK> As in, they may have gotten their second ACK before Hobbsee looks. :-P
[04:32] <coNP> Go StevenK!
[04:32] <StevenK> Ehhh, later.
[04:32] <Hobbsee> StevenK: indeed :P
[04:34] <ScottK> coNP: Soren just said he'd look at it, so feel free to move on to something else.
[04:34] <coNP> ScottK: okay.
[04:34] <coNP> Then I review scolily as promised earlier to ThibG
[04:34] <coNP> Then have a look at norsetto 's mail
[04:35] <xtknight> jeromeg, great news.  it seems to work with my AV/C dvr, unlike the old version.
[04:36] <jeromeg> xtknight: cool !
[04:36] <jeromeg> xtknight: without doing anything ?
[04:37] <No1Viking> coNP: You're welcome!  :)
[04:37] <xtknight> jeromeg, as far as i know.  i'll try a clean plug-in of the firewire.  i had to learn how to use dvgrab though so i executed it a few times
[04:38] <jeromeg> xtknight: ok thanks
[04:39] <xtknight> jeromeg, i do have to specify GUID
[04:39] <xtknight> jeromeg, e.g.  sudo dvgrab -g 0x00159afffe1c92d1 -f mpeg2
[04:39] <xtknight> but "sudo dvgrab" tells me "Found AV/C device with GUID 0x00159afffe1c92d1"
[04:39] <coNP> Any MOTU up to give a second ACK to boswars (http://revu.tauware.de/details.py?upid=101)?
[04:39] <jeromeg> xtknight: ok, i think it's normal
[04:43] <xtknight> jeromeg, it seems to work only every other time but this may be an issue with my dvr
[04:43] <xtknight> it never worked better with the hack method
[04:44] <jeromeg> xtknight: mmm, ok. you mean that it doesn't get all images ?
[04:44] <xtknight> jeromeg, well it will either be able to capture a full stream, or be able to capture no stream at all (0 MB)
[04:44] <xtknight> jeromeg, i'll pastebin
[04:44] <jeromeg> ok
[04:46] <xtknight> jeromeg, http://rafb.net/p/inrPjg32.html
[04:47] <xtknight> jeromeg, this is with playing back a recorded show on the DVR, and trying to record that to my pc using dvgrab.  however i think my dvr only works this way (it can't record live because of copy protections?)
[04:48] <jeromeg> xtknight: yes it's stange
[04:48] <jeromeg> xtknight: but if it always worked like that... we'll wait until geser confirms he had it work
[04:49] <xtknight> jeromeg, k
[04:49] <jeromeg> xtknight: thx very much for your help
[04:49] <xtknight> np
[04:49] <xtknight> it even says this "Error: no HDV. Try again before giving up." which i find interesting
[04:51] <jeromeg> yeah, maybe your problem is common
[04:59] <xtknight> what's the status of this bug?  Bug 42321
[04:59] <ubotu> Launchpad bug 42321 in xrandr "xrandr reports invalid refresh rates for MergedFB setup" [Medium,Confirmed]  https://launchpad.net/bugs/42321
[05:01] <Hobbsee> xtknight: confirmed. looking at that...
[05:01] <coNP> Do I need anyone for a bugfix update?
[05:02] <coNP> I mean as a MOTU I can upload it after I have reviewed, right?
[05:02] <Hobbsee> new upstream?
[05:02] <coNP> New upstream tarball with bug fixes.
[05:03] <Hobbsee> coNP: you'll need a UVFe, then you can upload if that gets accepted
[05:03] <xtknight> Hobbsee, but what would be the next step getting this upstream patch described there into ubuntu?
[05:06] <Hobbsee> xtknight: looking at the upstream bug - is that patch already in ubuntu?
[05:06] <Hobbsee> that was committed 10 months ago
[05:07] <xtknight> i would assume the bug status should be "fix released", then?
[05:07] <xtknight> i'm going to check the source code and see if that patch is in
[05:07] <Hobbsee> good idea
[05:07] <Hobbsee> and hten mark it as fix released.
[05:10] <DktrKranz> xtknight: are you sure that bug is for xrandr? I can't find radeon_mergedfb.c
[05:10] <xtknight> DktrKranz, not sure if this either.  it looks like it's in xserver-xorg-video-ati, but i'm trying to find the source code for that
[05:10] <xtknight> of this*
[05:11] <DktrKranz> ok, I'm looking at xserver-xorg-video-ati too
[05:14] <xtknight> DktrKranz, what package contains radeon_mergedfb.c?  I dont see it, using the packages.ubuntu.com search
[05:15] <DktrKranz> it should be xserver-xorg-video-ati,
[05:15] <xtknight> ahh
[05:15] <DktrKranz> AFAIK, patch submitted in your bug has not been applied
[05:15] <xtknight> i was doing -drivers that was why
[05:16] <soren> I should totally know this, but what does "triaged" status mean for a UVFe bug?
[05:17] <xtknight> it doens't look like it to me either.
[05:17] <soren> Hobbsee: Ah, you should be able to answer that..
[05:17] <xtknight> DktrKranz, what should be done for this bug?  should i apply the patch and post a debdiff?
[05:17] <soren> Hobbsee: ...since you set https://bugs.launchpad.net/ubuntu/+source/rawstudio/+bug/133879/+activity to triaged.
[05:17] <ubotu> Launchpad bug 133879 in rawstudio "Please sync rawstudio 0.6-1 from Debian unstable" [Wishlist,Triaged]
[05:17] <Hobbsee> soren: means that it's dealt with.  also means it should have motu-uvf unsubscribed, but my script buggered up, as i iddnt realise it was assigned, not subscribed.
[05:18] <soren> Hobbsee: "Dealt with" as in "approved and ready to be executed"?
[05:18] <soren> Hobbsee: If so, what does "confirmed" mean?
[05:18] <DktrKranz> xtknight: I would look at upstream bug in order to discover why it has been committed another one
[05:19] <Hobbsee> soren: yes
[05:19] <Hobbsee> soren: it's the difference between me doing the first and last ack, basically
[05:19] <Hobbsee> soren: if i do the last ack, i do it by email, where i've been using triaged for syncs for the u-u-s queue
[05:19] <Hobbsee> soren: and sub/unsub/change status all in one hit, for multiple bugs at once.
[05:19] <soren> Hobbsee: Ah, triaged = one ack, confirmed = two acks?
[05:20] <soren> Hobbsee: ...or the other way around?
[05:20] <DktrKranz> xtknight: and if you verified that patch solves that problem, you should prepare a debdiff
[05:20] <Hobbsee> soren: no, confirmed == first or second done by someone else.  triaged == second done by me.
[05:20] <Hobbsee> actually, it should be sitll at new for the first ack, and only change on the second.
[05:20] <Hobbsee> soren: you appear to be attempting to make me stop being lazy.
[05:20] <xtknight> DktrKranz, i will probably just ask the bug report creator to reconfirm this in gutsy.  supposedly randr 1.2 should fix this and that's in gutsy.
[05:21] <soren> Hobbsee: Not at all. :)
[05:21] <Hobbsee> soren: in truth though, we had some certain people who were using confirmed on their sync requests already
[05:21] <soren> Hobbsee: I'm just trying to determine if that particular bug actually was in a state where the archive admins would handle it.
[05:21] <Hobbsee> who, fortunately, werent in qa, and so i started setting all the stuff that was done, which i tocuhed, to triaged.
[05:21] <Hobbsee> they'll touch anything confirmed and above
[05:22] <Hobbsee> just to differentiate it
[05:22] <Hobbsee> soren: they should do
[05:25] <soren> Hobbsee: Oh, right, triaged > confirmed. I forget.
[05:25] <Hobbsee> hehe
[05:31] <mok0> coNP: ping
[05:31] <coNP> mok0: pong
[05:31] <mok0> coNP: I've just uploaded a fresh version of wulfware, for you to review at your leisure :-)
[06:24] <xtknight> what does "fix committed" actually mean, vs "fix released"?
[06:25] <DktrKranz> xtknight: fix released occours when a bug has been solved in a package already in ubuntu archives
[06:26] <xtknight> DktrKranz,  and fix committed means it has been fixed upstream or there is some type of patch available?
[06:26] <norsetto> xtknight: in general, fix release means that the fix for the bug is now in the repositories, commited that it is in the process of being released
[06:26] <DktrKranz> fix committed occours when a fix has been released elsewhere (upstream cvs, debian, and so on)
[06:26] <xtknight> ah
[06:26] <DktrKranz> if you prepare a patch for a bug, it should be "Confirmed"
[06:26] <xtknight> norsetto,  when you say "in the process of being released" what exactly does this mean?
[06:27] <xtknight> is there anything a user could do to accelerate the process of getting it to the pkg?
[06:27] <xtknight> or getting it to release, other words
[06:28] <DktrKranz> you can ask previous uploader, if he has upload rights he can sponsor it for you
[06:28] <DktrKranz> or you can ask here
[06:28] <DktrKranz> or subscribing ubuntu-universe-sponsors on Launchpad
[06:29] <xtknight> so the appropriate course of action, for say, Bug 8422 , would be to subscribe the proper sponsors?
[06:29] <ubotu> Launchpad bug 8422 in tsclient "Error message on ending VNC session" [Medium,Fix committed]  https://launchpad.net/bugs/8422
[06:30] <xtknight> it has already been assigned to bacher though
[06:30] <DktrKranz> this way, you should ask him directly
[06:30] <xtknight> k
[06:30] <norsetto> xtknight: it means that a fix has been found, which is now applied to a local copy somewhere, not yet public.
[06:31] <norsetto> xtknight: look at as: fix committed=private while fix released=public
[06:31] <xtknight> norsetto, gotcha
[06:43] <goedson> Hi. Should I assign bugs in a package that have already been fixed in Debian but not synced to universe to MOTU?
[06:43] <goedson> Or, what's the right procedure to trigger the synchronization?
[06:57] <Shoragan> the pida package in gutsy is pretty old, could someone trigger a pull from debian?
[07:01] <Jazzva> If a package build-depends on debhelper, does it have to be set at debhelper >= 5, or is version 4 ok?
[07:04] <pochu> Hello folks ^_^
[07:05] <superm1> Jazzva, is this a NEW package?
[07:05] <superm1> as in not ubuntu currently
[07:05] <Jazzva> superm1: Yes...
[07:06] <superm1> Jazzva, then you will want to set it to 5, unless you have some arguable reason to use 4.
[07:06] <superm1> also debian/compat will need to be set appropriately
[07:07] <Jazzva> superm1: Well, I'm not the actual packager... The upstream took the maintainer's part as well... I'm just trying to help him as much as I can, and to make it easier for a review :).
[07:07] <superm1> Shoragan, a UVFe will need to be filed for pida, since its a new upstream version.
[07:07] <Jazzva> superm1: Thanks for the help :)
[07:08] <superm1> Shoragan, do you have a reason other than the fact that 'its pretty old'?  If so, go ahead and file a UVFe.
[07:08] <superm1> Jazzva, ah wonderful.  Make sure that he doesn't keep the debian/ directory in the .orig.tar.gz then ok?
[07:08] <Shoragan> i'm just pida's maintainer in debian and people asked for a new ubuntu version in #pida
[07:09] <Jazzva> superm1: Ok :)...
[07:10] <superm1> Shoragan, in Ubuntu our upstream version freeze was a few weeks ago for existing packages.  It's not to say the new version can't make it in, just the UVF policy will need to be followed, and there has to be a justifiable reason as described here:
[07:10] <superm1> !uvf | Shoragan
[07:10] <ubotu> Shoragan: uvf is Upstream Version Freeze.  For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[07:12] <Shoragan> and new packages can still go in?
[07:13] <xtknight> what should i do if i want to get a newer version of a package into gutsy but the latest version is not in debian unstable/testing/experimental and not on revu (and i'm not a motu)?
[07:13] <superm1> Shoragan, it's up to the motu-uvf team to decide what will make it in.  So in a sense 'yes'.
[07:13] <Shoragan> ok, thanks :)
[07:13] <superm1> xtknight, we can divert from debian should we need to.
[07:14] <xtknight> superm1,  it is a package that is more or less required for general function by something on revu right now (qtpfsgui).  (pkg "hugin")
[07:14] <superm1> xtknight, but again same uvf process applies
[07:15] <superm1> xtknight, I see hugin available in gutsy
[07:15] <superm1> xtknight, is the newest version needed for qtpfsgui?
[07:15] <xtknight> superm1, ya a newer one that contains align_image_stack
[07:16] <superm1> xtknight, file a UVFe for it explaining why it's needed.  Unfortunately since we're past version freeze, can't just package the newer version of it.
[07:17] <xtknight> superm1, ok
[07:18] <xtknight> superm1, what version would end up being used?  an svn?  a latest 'stable' snapshot of hugin?
[07:18] <xtknight> actually i need to make sure it's the hugin package first
[07:20] <superm1> xtknight, davromaniak is the one that submitted the package to revu.  You can check with him.  Looking over debian/control, i don't even see hugin as a dependency though.
[07:21] <xtknight> superm1, the latest beta4 on hugin website doesnt seem to have align_image_stack.  however, hugin svn does ( http://qtpfsgui.wiki.sourceforge.net/align_image_stack )
[07:21] <xtknight> bah
[07:22] <xtknight> still here :)
[07:22] <xtknight> "As of today (10 Aug 2007) the hugin project has not published a release with align_image_stack in it yet (they are working hard for their next release)"
[07:22] <superm1> davromaniak, you here?
[07:23] <superm1> Any comments on this, about hugin?  It's not listed in debian/control at all.
[07:24] <xtknight> it's ok to have a SVN package in the repositories isn't it?  (if only svn has what we need).  the thing is, qtpfsgui technically does not need this program, but it's something that would be used very often for pre-processing HDR images and it's executed from qtpfsgui if the user chooses.  in this case the user has no choice since the program is not in ubuntu.
[07:34] <superm1> xtknight, its okay to have the SVN package in the repositories.  Just need to have it cleared with the uvf team before it can get in.  Perhaps hugin should be made a Recommend for qtpsfgui as well, davromaniak .
[07:34] <davromaniak> superm1 and xtknight, hugin is a problem because ubuntu version is too old
[07:34] <xtknight> i have compiled hugin svn on Gutsy and all build depedencies are met, the program also works
[07:34] <xtknight> is this what you mean?
[07:35] <davromaniak> yes
[07:35] <superm1> getting a new version of hugin likely shouldn't be too much trouble.  It isn't depended on by anything but ubuntustudio-graphics
[07:35] <xtknight> yea i agree hugin svn is needed, this should fix it
[07:35] <superm1> xtknight, can you file a UVFe for getting the newer hugin in then?
[07:35] <xtknight> im looking at this page https://wiki.ubuntu.com/FreezeExceptionProcess#head-9523bc4076ff011324d67cddc97969ec609618d6
[07:35] <xtknight> Bug 135111
[07:35] <ubotu> Launchpad bug 135111 in ubuntu "[UVFe]  hugin svn needs packaged for qtpfsgui" [Undecided,New]  https://launchpad.net/bugs/135111
[07:36] <superm1> xtknight, okay good.  Subscribe motu-uvf
[07:36] <xtknight> on that page should i be following New packages or Upstream?
[07:36] <xtknight> Upstream right?  its' not in debian but it is "upstream" on hugin, i guess.  should i be checking if hugin svn has a debian dir and do something there?
[07:36] <superm1> Also mention on that bug the rdepends for hugin don't break anything in the archive
[07:37] <davromaniak> so now I have 2 packages ?
[07:37] <davromaniak> qtpfsgui and hugin
[07:37] <superm1> xtknight, at this point we'd probably just update the debian/ directory that we already have for hugin in universe
[07:37] <superm1> to match the newer version
[07:37] <xtknight> davromaniak,  maybe i can probably help handle hugin.  im not a MOTU though
[07:38] <davromaniak> I don't have a big amount of spare time, and I spent most of this in qtpfsgui packaging, so
[07:38] <superm1> i'll be glad to help mentor either of you guys on packaging the newer hugin should the UVFe get approved
[07:38] <xtknight> i'll do it
[07:38] <xtknight> i'm sure i have the most free time here
[07:39] <xtknight> superm1, what do you mean by the rdepends thing?  should i post a cmd of rdepends?
[07:39] <xtknight> i have heard of this (reverse depends) just have never used it
[07:39] <superm1> xtknight, i did an 'apt-cache rdepends hugin' to determine what apps depend upon hugin
[07:39] <xtknight> ahh
[07:39] <superm1> to see how much would be affected by a newer version
[07:39] <xtknight> yes only hugin-* pkgs and ubuntustudio-graphics
[07:39] <xtknight> all meta or hugin so nothing riht?
[07:40] <superm1> That's what it looks like to me
[07:41] <xtknight> ok so someone will have to approve the UVFe bug#?
[07:41] <superm1> xtknight, i listed my offer for mentorship on the bug.  Can qtpfsgui make it in without hugin in case the time doesn't work out right?
[07:41] <xtknight> superm1, yes it's not needed.  the program works and runs fine and this program is not needed unless the user specifically uses it.
[07:41] <superm1> xtknight, the motu-uvf team will need two people to ack it and mark it confirmed
[07:42] <superm1> okay great.  Then davromaniak once you've got things resolved in qtpfsgui, we can get that in, and if time doesn't work out right here with hugin, it won't hurt qtpfsgui
[07:42] <xtknight> align_image_stack is called from the Wizard of qtpfsgui and while it is very nice to have and rather vital it's not needed.  the user can always get align_image_stack himself because the error msg tells him how to do s
[07:42] <xtknight> so*
[07:43] <xtknight> superm1, should it be a Depends or Recommended/Suggested of qtpfsgui?
[07:43] <superm1> Recommends i'd say
[07:44] <xtknight> what should be done about the error message telling the user to grab it from SVN?  if it's not in Depends, maybe a future patch should tell the user to get it from repositories instead (assuming hugin svn makes it in)?
[07:44] <xtknight> i think only a future patch for that is necessary, qtpfsgui is fine as-is and most people will be glad there's a deb of it at all
[07:45] <superm1> yea a future patch can change the behavior
[07:45] <superm1> we still have another month or so to get such patches in
[07:45] <xtknight> i would also handle that after hugin-svn gets in
[07:45] <xtknight> should be an easy patch
[07:46] <xtknight> shall we get started updating this package? :)  or wait until it is approved
[07:46] <davromaniak> superm1, for the patches, I only patch COPYING, because the modified qtpfsgui.desktop has the same contents as the original, so I overwritten it with the original
[07:46] <superm1> well that's up to you, if it doesn't get approved, your work will be in vain until next release cycle :)
[07:46] <superm1> davromaniak, Ok.
[07:47] <eagles0513875> !aptfix
[07:47] <xtknight> davromaniak, i'm not sure if this is critical but it would also be nice if the menu item for Qtpfsgui was something more than "Qtpfsgui".  a future patch could fix this as well, it's not terribly descriptive though
[07:47] <ubotu> If Adept crashed on you and your database is locked, try this in konsole:  sudo fuser -vki /var/lib/dpkg/lock;sudo dpkg --configure -a
[07:48] <goedson> Can anyone trigger a pull of gnotime 2.2.2-11 from Debian?
[07:48] <superm1> xtknight, if you want to see an example of how I've built the .org.tar.gz from svn, you can look at debian/rules for mythplugins or mythtv
[07:48] <xtknight> superm1, i dont mind wasting work right now, so i will start.
[07:49] <davromaniak> xtknight, the desktop file is not critical, so I will work at it later
[07:49] <xtknight> davromaniak, ok, and thanks again for doing the bulk of the work for qtpfsgui
[07:50] <davromaniak> it's strange, qtpfsgui is on my own repo since March, and nobody sent me any bug, so I'm surprised of the errors in the package
[07:50] <superm1> goedson, can you file a sync request for it and subscribe ubuntu-universe-sponsors?
[07:51] <xtknight> superm1, is there something specific i should be looking for in orig.tar.gz?
[07:51] <xtknight> or a guide on how to create an "orig" from hugin?
[07:51] <davromaniak> for now, the most important is to make a qtpfsgui package clean (with patchs, and others things), and usable
[07:51] <superm1> xtknight, i'd like to eventually author a MOTU recipe explaining how to make .orig.tar.gz from svn and bzr, but the debian/rules in mythtv and mythplugins both "Make" the .orig.tar.gz from svn
[07:51] <goedson> superm1, file a sync request against the Gutsy distribution?
[07:51] <davromaniak> I hope my patch is working
[07:52] <davromaniak> because it's the first one I made
[07:53] <superm1> goedson, give me one moment.  I just want to double check something
[07:53] <xtknight> superm1, ok.  hugin svn ( http://qtpfsgui.wiki.sourceforge.net/align_image_stack )  has no debian dir.
[07:53] <xtknight> maybe i should do something with the hugin package already in Ubuntu?
[07:56] <davromaniak> superm1, I've just dput a new version, with dpatch, but I don't know is the patch worked or not
[07:57] <superm1> goedson, i filed the sync request for it.  thanks.
[07:57] <superm1> davromaniak, okay i'll look in a few moments
[07:57] <davromaniak> ok, thx
[07:58] <davromaniak> I took example on lirc source package
[08:01] <goedson> superm1, thank you.
[08:01] <goedson> superm1, Can you give me a link to the request you filed? I'll need to do the same for gnomebaker soon.
[08:01] <fernando> libtool: install: error: cannot install `gtkvnc.la' to a directory not ending in /usr/lib/python2.5/site-packages
[08:02] <fernando> how to fix this?
[08:02] <superm1> goedson, i used the requestsync tool
[08:02] <superm1> in devscripts package
[08:02] <goedson> superm1, and if I'm not using Ubuntu?
[08:04] <superm1> goedson, You can file a bug to request a sync, and subscribe ubuntu-universe-sponsors
[08:06] <goedson> superm1, thank you.
[08:08] <tonyyarusso> What's the easiest way to produce a template man page?  (We'd like to have one, to be "proper" and such, but there is very little that will need to go in it)
[08:16] <davromaniak> good version dputed, so superm1 when you will have time, you can look
[08:28] <keescook> is a motu team supposed to be sub'd to an SRU bug?  Or how does that work?
[08:31] <superm1> keescook, somehow or another they are already subscribed
[08:32] <keescook> superm1: I just found the team name and added them.  :)
[08:32] <keescook> yeah...
[08:32] <superm1> yea that link doesn't discuss them at all
[08:32] <superm1> in the procedures
[08:32] <AndyP> i noticed
[08:34] <tonyyarusso> For the debian/copyright file, I know common licenses like the GPL shouldn't be quoted in full, but should refer to the file on the system, but I've read sometimes that the Preamble should be included, while other things seem not to mention it.  Does anyone know about this?
[08:35] <ScottK> Preamble should be included.
[08:35] <tonyyarusso> Ok
[08:37] <tonyyarusso> Now, where does the generic license statement (the "AS IS Without warranty, no fitness for a particular purpose, etc" part) go?
[08:40] <keescook> ScottK: you're part of the motu SRU team... do we need one of you to ACK bugs 134726 and 134801?
[08:40] <ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134726
[08:41] <ubotu> Launchpad bug 134801 in mythplugins "Mythplugins 0.20.2 SRU " [High,New]  https://launchpad.net/bugs/134801
[08:41] <ScottK> No, I'm motu-uvf.
[08:42] <ScottK> Any motu can upload an SRU.
[08:42] <ScottK> Gotta run.  Late for a plane.  Bye all.
[08:42] <superm1> cya ScottK
[08:44] <tonyyarusso> ScottK: Do you know much about using autotools-dev to replace outdated-autotools stuff?  (dealing with a lintian error)
[08:48] <broonie> It's fairly straightforward - there's some recipies in autotools-dev (though I don't like those since they clutter the diff)
[08:49] <dhdfoo> hey ... if I have uploaded a package to REVU, and I want to upload an improved version of it, should I just re-upload it?
[08:49] <tonyyarusso> broonie: Can you point to a decent HowTo?
[08:49] <dhdfoo> and do I need to update the changelog or anything?
[08:49] <broonie> Like I say, there are recipies in the autotools-dev pacakge.
[08:49] <tonyyarusso> broonie: but you don't like them, so where can I read about how you like to do it?
[08:49] <broonie> /usr/share/doc/autotools-dev/README.Debian.gz
[08:50] <ThibG> I've a package in the gutsy queue, but I've to do an update... I can't file a bug against my package, it says it's not uploaded yet
[08:51] <broonie> apt-get source mm and search for config.{sub,guess}
[08:53] <tonyyarusso> broonie: What's the mm ?
[08:56] <ThibG> Am I supposed to select "I don't know" ?
[09:00] <POX_> AndyP: I've made some tiny changes in pybackpack packages, say "ok" and I'll upload it to unstable
[09:01] <nekohayo> hello folks, I noticed the Transmission packages in gutsy's universe are pretty outdated (0.72 version, while 0.81 is out with lots of bug fixes and interesting features)
[09:01] <nekohayo> the package maintainer is marked as<EMAIL_ADDRESS>so I have no idea who to poke for an updated package?
[09:02] <POX_> AndyP: http://svn.debian.org/wsvn/python-apps/?rev=16&sc=1
[09:02] <POX_> and rev. 17
[09:02] <tonyyarusso> nekohayo: #1, when did 0.81 come out?  #2, what sorts of changes does it include?  (major bugfixes and security stuff, or minor bugs and features?)
[09:03] <nekohayo> tonyyarusso: 0.80 came out a few weeks/a month or two ago, 0.81 came out 3 days ago
[09:04] <nekohayo> tonyyarusso: they have performance enhancements, new translations, memory leaks fixed, torrent creation features, better upnp/peer exchange, selective downloading, etc
[09:04] <nekohayo> (to be very general)
[09:05] <nekohayo> not sure if it also fixes compatibility with trackers
[09:05] <tonyyarusso> nekohayo: Ok.  However, Upstream Version Freeze was on the 16th (see https://wiki.ubuntu.com/GutsyReleaseSchedule), and none of those are major reasons for an exemption (usually security-related or large bugs), so while I'm not the one in charge of such things, I'm doubtful that you could get an exception at this point.
[09:06] <tonyyarusso> nekohayo: Likely we'll just have to wait for Gutsy+1 for it instead, I'd think.
[09:06] <nekohayo> tonyyarusso: oh, I thought it was in 3 days
[09:06] <tonyyarusso> nekohayo: That's for new packages, ie, ones that have never been included before.  If it falls in that catagory, you still have time.
[09:06] <nekohayo> nah it is not new
[09:07] <tonyyarusso> :(
[09:07] <nekohayo> don't quite understand why new packages can bypass "package updates" deadlines though :)
[09:08] <nekohayo> bwah, if that maintainer used specto he would have been notified of the 0.80 release on the 7th ;P
[09:09] <tonyyarusso> nekohayo: If you'd like to ask for the authoritative answer, follow the instructions on https://wiki.ubuntu.com/FreezeExceptionProcess.
[09:10] <xxxxx1> nekohayo, did you create an entry on lp.net?
[09:11] <nekohayo> xxxxx1: nope, but I just saw someone did https://bugs.launchpad.net/ubuntu/+bug/134361
[09:11] <ubotu> Launchpad bug 134361 in ubuntu "Could you update Transmission please?" [Wishlist,New]
[09:12] <xxxxx1> ok
[09:18] <AndyP> POX_: looks good to me, thanks!
[09:22] <broonie> tonyyarusso: A literal mm (it's the first of the packages I maintain in Debian I thought of which does this).
[09:22] <tonyyarusso> broonie: Aaah, that makes sense.
[09:28] <nekohayo> thanks!
[09:35] <lousygarua> i need the maintainer of 'xorg-driver-synaptics', yet the maintainer appearing on launchpad is not the maintainer for ubuntu (i contacted him)
[09:35] <lousygarua> what do i do (there's a bug that no one seem to be resolving)
[09:36] <sn9> that's not me, but i'm curious as to what the bug is
[09:38] <keescook> crimsun, siretart, StevenK: you're on the motu-sru team, it sounds like anyone can upload an SRU?  Do you need to ACK first?  The instructions aren't entirely clear.
[09:39] <lousygarua> sn9: https://bugs.launchpad.net/ubuntu/+source/xorg-driver-synaptics/+bug/125670
[09:39] <ubotu> Launchpad bug 125670 in xorg-driver-synaptics "Scroll of synaptics touchpad stop working suddenly" [Undecided,Confirmed]
[09:41] <sn9> odd, i use the synaptics driver on several machines and have never run into that
[09:42] <bmm> Any MOTU: I'm looking for the second advocate of boswars: http://revu.tauware.de/details.py?upid=101
[09:42] <sn9> hmm, lemme see how ubotu does that
[09:42] <sn9> bryce: https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/78426
[09:42] <ubotu> Launchpad bug 78426 in mplayer "mplayer crash with "illegal instruction" on PPC (dup-of: 74282)" [Undecided,New]
[09:42] <ubotu> Launchpad bug 74282 in mplayer "Altivec detection broken on G3 (multiple packages)" [Undecided,Confirmed]
[09:43] <sn9> wow
[09:49] <geser> keescook: iirc is the motu-sru team out of service
[09:49] <superm1> geser, so who makes the calls upon approving sru's then for universe?
[09:50] <geser> the motu uploading to -proposed
[09:50] <keescook> well that makes it easy
[09:50] <geser> the hard part is to get the necessary testing done
[09:50] <superm1> Riddell, ^
[09:52] <ThibG> superm1, thanks for advocating the initial release of scolily :)
[09:52] <superm1> np ThibG
[09:54] <Riddell> superm1: ok
[09:55] <Riddell> superm1: accepted
[09:55] <ThibG> one other thing... I've done a new release ( I'm the upstream, yeah ), and packed it... I have done a bug report ( bug #135129 ) against scolily to explain there is a new upstream version ?
[09:55] <ubotu> Launchpad bug 135129 in scolily "New scolily upstream bugfix release" [Undecided,New]  https://launchpad.net/bugs/135129
[09:55] <superm1> Riddell, both feisty and edgy?
[09:55] <ThibG> Is that correct?
[09:57] <Riddell> superm1: yes
[09:57] <superm1> okay thanks Riddell
[09:59] <geser> superm1: I'm just looking over the debdiffs for the SRUs for mythplugins
[10:00] <geser> superm1: as the packages get copy (not uploaded) from -proposed to -updates the version should be correct for -updates (but you still upload to -proposed)
[10:01] <LaserJock> siretart: ping
[10:01] <superm1> geser, so it shouldn't have had a ~proposed1 on the version number then?
[10:01] <geser> superm1: exactly
[10:02] <geser> superm1: and don't change the maintainer for egdy (and before) as it's not tested well enough if the tools in edgy can handle that
[10:02] <geser> it's ok to change the maintainer for feisty
[10:04] <superm1> geser, would a more appropriate version have been say 0.20.2-0ubuntu0~edgy1 then? and 0.20.2-0ubuntu0~feisty1
[10:06] <geser> superm1: 0.20.2-0ubuntu0.6.10 for edgy and 0.20.2-0ubuntu0.7.04 for feisty (see https://wiki.ubuntu.com/SecurityUpdateProcedures for the versioning)
[10:07] <superm1> geser, ok.  after i see results from people with these packages this week (And if there was any breakage), i'll upload a new version into -proposed for the plugins
[10:14] <superm1> geser, when its copied over to -updates, archive admins wouldn't modify the version (to drop the ~proposed1) at the same time they modified edgy-proposed to edgy-updates?
[10:18] <geser> superm1: I don't know the details, but I guess all files (.dsc, .diff.gz, .deb) are simply copied from one pocket to an other
[10:19] <superm1> geser, okay well in my local version i updated it, in case it will be needed to be changed.  We'll see
[10:20] <geser> modifing the version would either need a rebuild of the whole package or the changeing of all control data inside the debs
[10:22] <LaserJock> what does the SRU page say
[10:23] <LaserJock> it used to be that the version was changed and it was reuploaded to -updates
[10:24] <LaserJock> hmm, seems like that's not the case anymore
[10:25] <superm1> well the version number won't clash with anything as is, so no worry there.
[10:25] <LaserJock> well, but it shouldn't have ~proposed if it's not going to be changed before going to -updates
[10:27] <superm1> well i'll upload a change before the 7 days are up before it is copied to -updates then
[10:31] <xtknight> superm1, what time would be best for you to help me with packaging hugin svn?
[10:31] <superm1> xtknight, i'll be on and off throughout the day
[10:31] <Jazzva> Hello... If someone could take a look at two packages, sphinxbase http://revu.tauware.de/details.py?upid=118 and pocketsphinx http://revu.tauware.de/details.py?upid=120 . I would like to mention that pocketsphinx build-depends on libsphinxbase0-dev, which is provided in sphinxbase package. Thanks :)...
[10:31] <superm1> start with the packaging in gutsy as a base
[10:31] <superm1> hopefully shouldn't need many changes
[10:32] <xtknight> superm1,  ok.  thanks.  i'll see what i can come up with and let you know.
[10:32] <Jazzva> *I would appreciate if someone could take a look... [the rest of the sentence]  :)
[10:33] <geser> Jazzva: there is no need to include the soname in the -dev package name unless you need to have different versions of the -dev package co-installable => libsphinxbase-dev is enough (you normally want to build against the recent lib version)
[10:35] <Jazzva> geser: I didn't make the package... I just helped to the maintainer (who is also the author) as far as I could before the release. Could you leave that as a comment, so he could read it? :)
[10:36] <geser> ok, will do
[10:36] <Jazzva> geser: Thanks a lot :)...
[11:12] <siretart> LaserJock: pong
[11:23] <LaserJock> siretart: hitting reload after submitting a comment leads to fun
[11:23] <LaserJock> http://revu.tauware.de/details.py?upid=26
[11:28] <siretart> LaserJock: I'm working on that here: https://code.launchpad.net/~siretart/revu/revu2 ;)
[11:30] <ajmitch> siretart: do you have anything apart from the code there for us to look at & help with?
[11:30] <ajmitch> like a design? :)
[11:32] <siretart> ajmitch: look at the comments in PackageCache.py
[11:32] <siretart> ajmitch: unittests for PackageFetcherDget would be great :)
[11:35] <siretart> right :)
[11:35] <siretart> that's Test Driven Development :)
[11:35] <LaserJock> siretart: so are you currently looking at using PPAs or sticking with the original design
[11:35] <ajmitch> heh
[11:36] <siretart> LaserJock: I'm looking at combining them
[11:42] <LaserJock> siretart: hmm, interesting
[11:43] <superm1> I just added some comments and an advocation to qtpfsgui if another MOTU would like to look it over now: http://revu.tauware.de/details.py?upid=122
[11:47] <LaserJock> boy, REVU got really full :(
[11:49] <LaserJock> and man, I hate it when people hack into computers at work
[11:49] <LaserJock> now I've got to go through all the computers in the lab and see if any damage got done
[11:53] <nixternal> that sucks
[11:54] <nixternal> I wish people would upload fixes to revu's, or at least comment that they are...
[11:54] <superm1> hi nixternal
[11:54] <LaserJock> a computer across the hall decided to attempt to ssh in to my mac 8,000+ times
[11:55] <nixternal> howdy superm1
[11:55] <superm1> here to join in some revu'in fun?
[11:56] <nixternal> nah, building out KDE 4 to do some work tonight, but pimlibs is broke and I am trying to patch it
[12:00] <LaserJock> geeze, what is UPS Express Plus shipping? this company would charge $1341 for it
[12:01] <TheMuso> Hey folks.
[12:02] <superm1> hey TheMuso
[12:02] <jrib> hi
[12:07] <ajmitch> LaserJock: it gets there yesterday?
[12:08] <Bixente> RAOF: I made some changes, if you can have a look please http://revu.tauware.de/details.py?upid=125
[12:09] <TheMuso> norsetto: You may rise. :p
[12:10] <TheMuso> haha
[12:17] <geser> TheMuso: you got promoted?
[12:17] <geser> norsetto: Hobbsee is our MOTU queen
[12:18] <norsetto> geser: yes, that why I said HIS Motuness (ok, I forgot the capital h)
[12:18] <TheMuso> geser: Not that I know of.
[12:18] <geser> norsetto: and dholbach has the secret name "Prince Adam"
[12:19] <norsetto> geser: ahAH!
[12:19] <norsetto> geser: so he is the illegittimate son of TheMyso and Hobbsee!?
[12:19] <norsetto> TheMyso? oh well....
[12:20] <TheMuso> heh
[12:22] <LaserJock> hmm
[12:22] <LaserJock> and the MOTU trinity just watches from  afar ...
[12:22] <ajmitch> shocked & appalled
[12:22] <nixternal> ahh, you finally admit to it!
[12:23] <LaserJock> speaking of, where are imbrandon and bddebian these days
[12:23] <nixternal> gone?
[12:23] <nixternal> actually, I have seen them both recently, but I do believe they are both doing personal work
[12:24] <azeem> LaserJock: bddebian is apparently on some work-related business trip in California these days/week, i.e. really busy IRL
[12:24] <LaserJock> hmm, so it's some form of deism
[12:24] <LaserJock> the Trinity exists, but is far removed and no longer interacts with it's creation
[12:24] <azeem> though he wasn't on some business trip when he wasn't around the last couple of months (but he infrequently said "hi" I gather)
[12:24] <ajmitch> LaserJock: but you're here
[12:25] <LaserJock> in spirit .... ;-)
[12:25] <nixternal> ya, you can fulfill the trinity on your own!
[12:25] <LaserJock> pffft
[12:25] <nixternal> haha
[12:25] <norsetto> this reminds me of a spaghetti western
[12:26] <LaserJock> the good, the bad, and the ugly ?
[12:26] <norsetto> :-)
[12:26] <norsetto> the god, the bad and the ugly :-)
[12:27] <ajmitch> morning jml
[12:27] <norsetto> and as you all know, for the god I think we have a good candidate: https://wiki.ubuntu.com/BddebianIsAGod
[12:28] <nixternal> if ajmitch has the ugly, I guess I can do the bad...that would be an improvement though for me :)
[12:28] <LaserJock> heh
[12:29] <luisbg> LaserJock, :P
[12:29] <LaserJock> I guess I can be a sidekick
[12:29] <LaserJock> one of the little guys in the background that gets shot in the first half hour
[12:29] <ajmitch> a red shirt
[12:30] <LaserJock>  "no, don't go LaserJock. Just hang on!"
[12:30] <LaserJock> "MEDIC!"
[12:30] <LaserJock> hehe, slipped into a John Wayne WWII movie there
[12:30] <nixternal> LaserJock: you know it is bad when nobody else scream that, and leaves it up to you to talk to yourself for comfort :D
[12:30] <LaserJock> lol
[12:31] <nixternal> we couldn't afford that other guy to do that part of the acting I guess
[12:31] <LaserJock> "He's gone to be with the core-devs now"
[12:31] <nixternal> file a bug in LP
[12:31] <nixternal> set it as wishlist
[12:31] <jml> ajmitch: jello
[12:31] <jml> ajmitch: hello, even
[12:31] <nixternal> jello works