[00:16] <smallfoot-> plz package php-gtk
[01:11] <smallfoot-> plz package php-gtk
[01:16] <kklimonda> smallfoot-: the project is all but dead and with the upcoming gtk+3 release and all the gobject introspection work that goes along with it I fear that uploading the current version right now wouldn't make sense. Not to mention that there is no one who is interested in packaging it.
[01:20] <smallfoot-> kklimonda, but i need php-gtk for running gui of phoronix-test-suite
[01:22] <kklimonda> yes, and that is probably the only realworld application that uses php-gtk bindings. You will have to ask phoronix guys how to install php=gtk (or check its homepage). There may also be some 3rd party ppa with it - have you ckecked?
[01:30] <smallfoot-> there is a ppa but only for karmic, not lucid, maverick
[01:30] <smallfoot-> and i dont want use third-party ppa or install from source, i want it "just work"
[06:39] <Muscovy> Hi, I'm the uploader of http://revu.ubuntuwire.com/p/day-of-ubuntu . Would anyone mind helping me solve the lintian error? I haven't been able to fix this one without creating more.
[06:40] <kklimonda> Muscovy: what errors do you get when you remove NMU?
[06:41] <Muscovy> It's been a while since I tried, so I'll test. I _think_ it mentions it needs NMU.
[06:42] <ebroder> Muscovy: What version of Lintian are you using? It should know not to whine about NMUs if the maintainer is set to ubuntu-devel-discuss
[06:43] <Muscovy> I think I had set it to the development team as the owner.
[06:44] <Muscovy> Also, is there an easy way to download it all from revu? I can't seem to find my local copy anymore.
[06:44] <ebroder> dget <.dsc file>
[06:46] <Muscovy> Thanks, that's handy.
[06:46] <ebroder> (It only works if all the files are in the same, err, URL directory, or whatever)
[06:46] <ebroder> (But that's usually the case)
[06:46] <Muscovy> So is it ubuntu-devel-discuss with no address?
[06:46] <ebroder> Muscovy: Sorry, no - what you've got should be good. Just remove the NMU note from the changelog
[06:47] <Muscovy> Ok.
[06:52] <Muscovy> Ok, it's uploading. It'll take a few minutes.
[06:58] <Muscovy> Here we are, ebroder: http://revu.ubuntuwire.com/revu1-incoming/day-of-ubuntu-1008220757/lintian
[06:58]  * ebroder squints
[06:58] <Muscovy> Two complaints: 3.0 format and no README.
[06:59] <ebroder> I have a theory
[06:59] <ebroder> Muscovy: Are you doing development on a Lucid or Maverick machine/VM/chroot/whatever?
[06:59] <Muscovy> Lucid machine.
[06:59] <ebroder> And do you get those warnings when you run Lintian on your package?
[06:59] <Muscovy> Nope.
[07:00] <Muscovy> I get "W: day-of-ubuntu source: out-of-date-standards-version 3.8.3 (current is 3.8.4)".
[07:00] <ebroder> Ok. In that case, I blame revu for being a really old machine
[07:00] <ebroder> (You should bump the standards version, though)
[07:00] <Muscovy> I tried that before, actually.
[07:00] <Muscovy> Revu said 3.8.4 didn't exist.
[07:01] <ebroder> Yeah. That's because Revu is running Hardy, and it didn't exist then :)
[07:01] <Muscovy> Ah. Why isn't 3.8.4 a lucid update though?
[07:01] <Muscovy> 3.8.3 is still the lucid default.
[07:02] <ebroder> Packages update their standards version when they get around to it. Do you mean that 3.8.3 is what you get from dh_make or something?
[07:02] <Muscovy> Yes.
[07:02] <ebroder> Yeah. It probably just wasn't updated when Lucid was syncing from Debian
[07:06] <kklimonda> the current policy is 3.9.1 so you should update your package to it
[07:07] <kklimonda> (by update I mean actually checking if there were changes affecting your package - there is a nice upgrading-checklist.txt.gz in debian-policy package)
[07:09] <ebroder> Speaking of which, it's *really* silly that REVU is still running on a Hardy sparc box. What are the current hardware requirements for the site (disk, etc)? Surely someone else has some - any - spare capacity...
[07:10] <micahg> ebroder: can't upgrade w/sparc to lucid...
[07:10] <ebroder> micahg: Right. The sparc bit is the bit that's silly
[07:18] <Muscovy> There, it's up: http://revu.ubuntuwire.com/p/day-of-ubuntu
[07:51] <wgrant> ebroder: We can move it elswhere. But there's no really compelling reason to do so yet.
[07:51] <wgrant> But it was discussed last week.
[07:51] <ebroder> wgrant: "Having an ancient version of Lintian that misfires errors at you" doesn't count as a compelling reason? :)
[07:52] <Muscovy> I agree with that.
[07:52] <Muscovy> And it can't use debian 3.0 format.
[07:56] <wgrant> Muscovy: That just requires backporting a new lintian, which we've historically done often.
[07:56] <wgrant> Er, ebroder: ^^
[07:57] <wgrant> Muscovy: And a dpkg backport was in progress last week.
[07:57] <Muscovy> Ah, progress. :D
[07:57] <ebroder> I guess that works then
[07:57] <wgrant> It just requires somebody to care for REVU.
[07:57] <wgrant> I can move it onto different hardware if required, but others need to maintain the service.
[07:58] <Muscovy> Well, if I become a MOTU, I'll certain help if possible.
[07:58] <Muscovy> Revu feels under-utilized.
[07:58] <ebroder> wgrant: Hmm...if you're looking for MOTU volunteers, I might be interested, but I'll have to get back to you once I think about what I'm getting myself into
[08:01] <wgrant> Well, there are others in control of the service.
[08:01] <wgrant> I'm not looking for anyone.
[08:01] <wgrant> I was mainly responding to the questioning of whether there was other hardware.
[08:04]  * micahg prepares an upload to feed the hungry builders
[08:05] <wgrant> ia64 and sparc are going to be eternally hungry soon :(
[08:05] <micahg> wgrant: nah, we just have to start backporting and SRUing more :)
[08:05] <wgrant> Heh.
[08:14] <micahg> should .pc be in the VCS for soruce format 3?
[08:29] <micahg> wgrant: ^^
[08:34] <Zhenech> hyperair, ping
[08:38] <tumbleweed> micahg: I wish it wasn't but the auto-imported packages tend to be stored patches-applied, yes
[08:39] <micahg> tumbleweed: that's what I'm wondering, the Debian version has it, so I should include in Ubuntu version too?
[08:39] <tumbleweed> "the debian version" ?
[08:39] <micahg> lp:debian/sid/foo
[08:39] <tumbleweed> aah
[08:40] <maco> is there any reason why it would be a bad idea for /etc/bashrc to by default have "export QUILT_PATCHES='debian/patches'" to save *headdesks* later for us all on new installs?
[08:40] <micahg> maco: because not all packages work like that
[08:40] <maco> dang
[08:41] <tumbleweed> maco: time to store your .quiltrc in $vcs and write a new install personal-customisation script?
[08:42] <maco> i dont have a .quiltrc...i just put that in my .bashrc and then setup VMs and forget to do it there too and then get confused
[08:43] <maco> i was asking seb128 the other day how he got gnome-control-center to compile when quilt push -a fails... and he reminded me
[08:44] <bilalakhtar> maco: how was it?
[08:44] <maco> bilalakhtar: i forgot to set QUILT_PATCHES
[08:44] <bilalakhtar> ah ok
[08:45] <AnAnt> Hello
[08:45] <micahg> tumbleweed: when merging with VCS, does every merge change need to be a new commit w/source format 3 or all in one?
[08:46] <tumbleweed> micahg: that's up to personal style, I tend to do them in one commit (or a few commits in a branch, merged into one commit in the UDD tree)
[08:46] <tumbleweed> (if I'm understanding you correctly(
[08:47] <micahg> tumbleweed: yeah, the changes should all be present though
[08:47] <micahg> just patches if necessary aren't applied
[08:47] <micahg> in ,oc
[08:48] <micahg> or rather in the code..
[08:49] <tumbleweed> people like patches-applied because you can see the final source in the tree, and $vcs blame it appropriately. I don't like it, because it makes reviewing harder and obfuscates things (often resulting in auto-generated anti-patches, when people are new to quilt)
[08:53] <micahg> tumbleweed: also, should I put the Ubuntu VCS info or leave the Debian VCS info
[08:54] <tumbleweed> only if we maintain our own packaging of this in a VCS somewhere
[08:54] <micahg> tumbleweed: not UDD?
[08:54] <tumbleweed> well, all packages have UDD branches
[08:55] <micahg> tumbleweed: no, most packages have UDD branches
[08:55] <tumbleweed> and few packages are actually maintained in them (you don't see new versions being prepared in them)
[08:55] <tumbleweed> basically, I'd say leave the debian vcs info
[08:55] <micahg> tumbleweed: k
[08:55] <hyperair> Zhenech: pong
[08:56] <Zhenech> hyperair, talked with enrico at froscon yesterday
[08:56] <hyperair> oh cool
[08:56] <Zhenech> hyperair, the safest way to get plugins 0.19 in is not to ship any of the new plugins :)
[08:56] <hyperair> eh?
[08:57] <hyperair> oh, into squeeze?
[08:57] <Zhenech> yepp
[08:57] <hyperair> okay.
[08:57] <Zhenech> dunno how the release team thinks about new binaries
[08:57] <Zhenech> will ask later today
[08:57] <hyperair> okay, thanks.
[08:57] <bilalakhtar> hi hyperair seeing you after so long
[08:57] <Zhenech> have a patch on my hd to do this already :)
[08:58] <hyperair> bilalakhtar: it's only been a week =)
[08:58] <hyperair> Zhenech: a patch to drop the new binaries?
[08:58] <Zhenech> yepp
[08:58] <hyperair> i see.
[08:58] <hyperair> that's nice
[08:59] <hyperair> speaking of which i need to get round to adding --enable/disable flags for each plugin, instead of those with weird dependencies.
[08:59] <Zhenech> yepp! :)
[08:59] <hyperair> wait, you mean the patch does all that?
[09:00] <Zhenech> no
[09:00] <Zhenech> my patch just drops ctpl build dep
[09:00] <Zhenech> and drops the packages from debian/control
[09:00] <Zhenech> so they are built but never installed
[09:02] <bilalakhtar> tumbleweed: As for bug #621065 , seb128 told me that we can go ahead without FFe since its a GNOME package
[09:04] <bilalakhtar> tumbleweed: am I right ?
[09:05] <tumbleweed> sounds fair enough
[09:06] <bilalakhtar> tumbleweed: GNOME packages can be updated until version 2.32 rolls out
[09:06] <bilalakhtar> tumbleweed: Its not fair to freeze on an unstable release like 2.31.* and not upgrade to the stable ones
[09:07] <tumbleweed> yeah, sounds good
[09:10] <bilalakhtar> tumbleweed: And, we are uploading this version even though the package is maintained in Debian, because of the fact that Debian will straightaway upload 2.32 while Ubuntu needs to go in a more progressive way (seb128)
[09:11] <micahg> bilalakhtar: some of the debian maintainers will upload the 2.31.x releases to experimental
[09:21] <hyperair> Zhenech: i see. that sounds feasible.
[09:21] <hyperair> Zhenech: could you pastebin the patch somewhere so i can apply it? =)
[09:33] <bilalakhtar> Thanks tumbleweed for the upload!
[09:58] <tumbleweed> bilalakhtar: any time
[10:01] <micahg> tumbleweed: with MoM down, UDD is a lifeaver
[10:01] <micahg> *lifesaver
[10:01] <tumbleweed> micahg: are you using my merge tool?
[10:02] <micahg> tumbleweed: no
[10:02] <tumbleweed> micahg: :)
[10:03] <micahg> tumbleweed: sorry, this was same upstream revision so it was an easy merge :)
[10:55] <Zhenech> hyperair, i also could just commit myself :)
[10:56] <Zhenech> hyperair, but I mail debian-release first :)
[11:09] <shadeslayer> hi, how do i request a sync from debian experimental?
[11:10] <shadeslayer> i tried : requestsync foo -d experimental  -e
[11:10] <shadeslayer> doesnt work :/
[11:16] <geser> error?
[11:16] <shadeslayer> E: 'kmymoney' doesn't appear to exist in Debian 'experimental'
[11:17] <shadeslayer> http://packages.debian.org/experimental/kmymoney
[11:17] <ajmitch> shadeslayer: possibly because it was uploaded in the last 24h?
[11:17] <geser> it was uploaded today
[11:17] <shadeslayer> oh
[11:17] <shadeslayer> yes i know
[11:17] <shadeslayer> so it doesnt pick it up
[11:17] <shadeslayer> ddidnt know that ^ :P
[11:17] <ajmitch> no, it grabs the info from a mirror that's regularly synced (daily iirc)
[11:17] <shadeslayer> hmm
[11:17] <geser> requestsync only knows what's in LP or reported by rmadison
[11:18] <shadeslayer> rmadison ?
[11:18] <shadeslayer> debian mirror ?
[11:18] <geser> a script from devscripts
[11:18] <shadeslayer> oic
[11:20] <geser> http://qa.debian.org/madison.php?package=kmymoney
[11:20] <geser> hmm, the snapshot seems a little bit out-of-date
[11:22] <micahg> geser: yeah, I"m having that with phpmyadmin also
[11:26] <bilalakhtar> tumbleweed: Hello! Would you recommend me to apply for MOTU now or wait?
[12:02] <tumbleweed> bilalakhtar: drop me a mail with a list of spnsorships I've done for you, and I'll be able to give you an answer (we need a script for this, I tried writing one but can't get the data I need out of lp's API)
[12:27] <persia> tumbleweed, You can parse the data out of the -changes mail
[12:28] <tumbleweed> persia: yeah, I suppose that's the best way
[13:01] <AnAnt> persia: hey, long time !
[16:30] <Rhonda> Is the last change in bug #619650 someone just looking for easy karma? :)
[16:33] <nigelb> Rhonda: Possible. I don't see him/her in bug squad.
[16:34] <nigelb> (the entire thing is not needed I think.  Generally bug squad is encouraged to stay away from workflow bugs)
[17:14] <anoteng> which package am I missing when I get the following error during source package building?
[17:14] <anoteng> dpkg-source: error: source package format `3.0' is not supported (Perl module Dpkg::Source::Package::V3 is required)
[17:17] <Bachstelze> could an SRU person look at #622319 ?
[17:18] <tumbleweed> Bachstelze: subscribe ubuntu-sponsors. It also needs a maverick fix before the SRU can be approved
[17:18] <Flannel> anoteng: dpkg-dev
[17:19] <Bachstelze> tumbleweed: ok, done
[17:20] <tumbleweed> Bachstelze: you also want to Nominate for Lucid
[17:20] <anoteng> Flannel:  I thought so too, but it's allready installed...
[17:21] <Flannel> anoteng: What version of Ubuntu are you running?
[17:21] <Bachstelze> tumbleweed: also Maverick?
[17:21] <tumbleweed> Bachstelze: not necessary
[17:21] <anoteng> 10.04
[17:24] <geser> what the content of debian/source/format?
[17:30] <ari-tczew> Rhonda: I think that it's pedantic.
[17:36] <ari-tczew> nigelb: so upgrade dspam must be gigantic procedure
[17:37] <nigelb> ari-tczew: I dunno.
[17:37] <nigelb> I just looked at the debian ML
[17:37] <ari-tczew> nigelb: IIRC they are upgrading 3 years this package
[17:37] <nigelb> ari-tczew: well, it is in experimental
[17:37] <nigelb> I think it broke some stuff
[17:39] <ari-tczew> nigelb: some time ago I tried to do this, but it's true, it's very hard to do.
[17:40] <nigelb> ari-tczew: In that case, we cannot blame them.  Everyone's a volunteer.
[17:40] <nigelb> I myself was away from cleansweep for some time until I could finally schedule my work around it now.
[17:41] <ari-tczew> yea
[20:12] <funkeyDuder> I am having trouble building a package.  When I change the source I get an error about failing some test (using debuild).  Anyone have any thoughts as to what might be going on?
[20:23] <bilalakhtar> tumbleweed: I mailed you the list of bugs
[21:10] <andrew_708476> IS there anyone that doesn't mind lending a hand with Ubuntu
[21:10] <ari-tczew> funkeyDuder: give a log - use pastebin
[21:11] <ari-tczew> dupondje: ping
[21:12] <dupondje> pong :)
[21:13] <ari-tczew> dupondje: are you still interesed contribute to Ubuntu?
[21:13] <dupondje> sure sure :) but bit less time atm :)
[21:14] <ari-tczew> dupondje: we have to finish patching asterisk, do you remember?
[21:14] <ari-tczew> it's still waiting on my hard disk :)
[21:18] <dupondje> what was not correct with it again ? :)
[21:25] <ari-tczew> dupondje: please tab me if you are writing to me.
[21:25] <ari-tczew> it will easy for me
[21:27] <ari-tczew> dupondje: you have to complete file CVE-2007-6170.dpatch
[21:27] <ari-tczew> there is no DEP3 tags
[21:27] <ari-tczew> there are no *
[22:02] <AnAnt> Hello
[22:16] <ari-tczew> hello AnAnt
[22:23] <micahg> is conflicts appropriate when if one package is installed, the other will not work?
[22:23] <micahg> in that they provide similar functionality
[22:30] <debfx> micahg: yes, if they really don't work when the other is installed
[22:30] <micahg> debfx: k, filing the bug in Debian...