[00:26] <nhandler> I'm trying to build a source package using 'bzr bd -S --split'. The package use dpkg 3.0 (quilt) and has all of its patches applied (push'ed), but bzr bd always fails saying: Reversed (or previously applied) patch detected!  Skipping patch.
[00:26] <nhandler> Any ideas on why/how to fix it?
[08:31] <superm1> didrocks, cool just confirmed that your update work out properly thanks!
[08:31] <didrocks> superm1: great! it was not as easy as planned :)
[08:32] <superm1> didrocks, slight recommendation for the future after seeing how it works out - since there is no window manager available while the dialog is running, maybe run the dialog full screen so it doesnt get stuck up in the corner?
[08:32] <superm1> or set it to always center or similar
[08:33] <didrocks> superm1: not sure how it can behave on big screen. all others are small normally. centered can make sense but I hadn't the time for a proper look to how to do that without WM
[08:33] <didrocks> patches welcomes of course :)
[08:33] <didrocks> welcomed*
[08:34] <superm1> yeah i'm not sure if that's doable without a WM either, which is why I thought fullscreen might be a better alternative
[08:34] <superm1> but this is great for maverick, that can be something to sort out during natty
[08:36] <didrocks> superm1: right
[10:32] <oojah> Is there a recommended naming for packages of python wrappers of C libraries? I've seen both libfoo-python and python-foo.
[10:38] <hrw> does it has any sense to request sync of vim (7.3 instead of 7.2) from Debian as "main" is now frozen?
[10:45] <micahg> stefanlsd: hi, I was wondering what you think of the idea of dropping gears this cycle, Google, doesn't seem to want to update it
[11:02] <persia> hrw, You'd need to review for new features, and potentially file a Feature Freeze request.  We typically avoid things like that at this point in the cycle unless there's some pressing need (current version fails to work at all, etc.)
[11:02] <hrw> micahg: wasn't google gears officially eol?
[11:02] <micahg> hrw: basically
[11:03] <hrw> persia: will wait for natty with it. I have 7.3 rebuilt locally anyway
[11:09] <geser> hrw: a rebuild only or a proper merge which you could get sponsored once natty is open for uploads?
[11:23] <stefanlsd> micahg: yeah. agreed
[11:23] <stefanlsd> micahg: i did get some interest from a dd, but after i pointed out google is dropping it, i think he abandoned that plan also
[11:24] <hrw> geser: once natty will be open getting vim 7.3 will be a matter of requesting sync with debian
[11:25] <geser> hrw: all our changes are merged?
[11:26] <hrw> geser: did not checked yet
[11:29] <geser> hrw: it has to be a merge because of dropping vim-lesstif and enabling the python interpreter on the basic builds (didn't check all changes yet)
[11:32] <hrw> ok
[12:42] <\sh> fbreader ftbfs fixed
[13:09] <hrw> http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi is up-to-date or more or less outdated?
[13:11] <tumbleweed> hrw: lucas just posted a day or so ago, saying he'd updated it
[13:11] <hrw> tumbleweed: ok
[13:14] <\sh> hrw: it's the latest list of ftbfsing packages...I'm working down the list
[13:15] <\sh> if someone is an adventurer, please take a look at enna and the new libecore world order
[13:15] <\sh> it's a mess
[13:15] <hrw> enna... I prefer to keep out of e17 world
[13:18] <geser> \sh: as you fixed ecs, would the same fix work for code-saturne? replacing libhd5-serial-dev with the mpi variant?
[13:19] <\sh> geser: good that you remind me, I wanted to try an rebuild of code-saturne...I think it was ecs which ftbfsed and code-saturne just failed
[13:20] <geser> \sh: code-saturne has a B-D on -serial-dev
[13:20] <\sh> geser: but reading the docs, it should work...there are some discussions on the BTS about that
[13:20] <hrw> hmm.newlib_1.18.0-1ubuntu3_i386 built for me
[13:20] <geser> and ecs pulls now the -mpi variant
[13:21] <geser> \sh: I can test-build with -mpi and close bug 647427 if it works
[13:21] <\sh> geser: that would be great :)
[13:22] <hrw> \sh: seabios bug is known: bug 648895
[13:22] <tumbleweed> geser: I think I tried with -mpi and it built, can't remember...
[13:27] <\sh> hrw: wanna fix? :)
[13:29] <hrw> \sh: have it on a list but not maverick rather
[13:30] <hrw> need to backport few my packages from maverick to lucid and hack a way to get it in ppa
[13:32] <geser> \sh: are you working on the emerald FTBFS on amd64? (probably just a missing #include)
[13:36] <\sh> didn't I upload emerald yesterday?
[13:36] <geser> yes
[13:37] <\sh> geser: the package build without any problems , the problems are in the last lines of the buildlog...I was confused yesterday....
[13:38] <\sh> Function `gdk_gc_new' implicitly converted to pointer at main.c:3029
[13:38] <\sh> oh this is ... so evil
[13:38] <\sh> geser: if you can fix it quickly, go ahead
[13:38] <hrw> \sh: http://pastebin.com/SYZLdT7S is part of cdebconf-terminal fix
[13:39] <geser> \sh: it's just a warning in gcc so the buildd checks the log for it on 64bit
[13:39] <\sh> geser: but it prevents it to be pushed to the archives
[13:40] <geser> yes
[13:44] <hrw> \sh: http://pastebin.com/ZeU02EsB is full patch to make cdebconf-terminal built. not tested does it run
[13:44] <hrw> \sh: code taken from http://code.google.com/p/stjerm-terminal/source/detail?r=284
[13:46] <\sh> geser: hmm...checking the decor_t struct, and the gc member it should be coorect...gdk_gc_new gives back a GdkGC pointer it seems, could be wrong, not that gtk specialist
[13:49] <geser> \sh: gdk_gc_new is guarded by #ifndef GDK_DISABLE_DEPRECATED and emerald sets it
[13:49] <geser> so I try the "usual" fix to not define it
[13:49] <Laney> emerald still exists?
[13:50] <geser> at least in our archive
[13:50] <jpds> Laney: Haha; I asked that same question in -uk about two weeks ago.
[13:51] <\sh> geser: I wonder if this is a good idea with emerald ;) how many more bugs we will find ;)
[13:54] <geser> \sh: luckily emerald doesn't use -Werror
[13:56] <Laney> is it still active upstream?
[13:56] <Laney> I see there's no package in Debian
[13:56] <geser> fixing FTBFS: code-saturne: done; emerald: done
[13:56] <geser> Laney: was emerald ever in Debian?
[13:56] <Laney> dunno
[13:56] <\sh> geser: thx
[13:57] <persia> I think last time we tried to remove emerald we got so many bugs and complaints, we put it back and declared that someone else could make it work.
[13:57] <persia> Trick is "someone else" keeps changing.
[13:57] <wgrant> I did remove emerald three years ago.
[13:58] <wgrant> But it was revived.
[13:58] <wgrant> It appears to have been updated for about six months after that.
[13:58] <wgrant> Then nothing.
[13:59] <geser> Laney: the last emerald release is 0.8.4 from 2009-10-14 (we have 0.7.2 from 2008-03-06)
[13:59] <Laney> geser: Right, so we at least lack someone taking care of it (or alternatively there was a good reason not to update)
[13:59] <Laney> There's a high number of bugs too.
[13:59] <\sh> grmpf.../me needs to kick some devs
[13:59] <Laney> However it does have quite some installs according to popcon
[14:00] <geser> does somebody know takes care of compiz currently?
[14:00] <Laney> #-desktop will
[14:00] <persia> I think it has a lot of dedicated users, but little upstream development.
[14:01] <geser> I could only find emerald at http://releases.compiz-fusion.org/ till 0.8.4
[14:03]  * \sh <- meeting...BBL
[14:09] <hrw> http://people.canonical.com/~hrw/ftfbs/ - can someone review cdebconf-terminal?
[14:11] <persia> hrw, Do you have a diff handy?
[14:12] <persia> hrw, Or are you looking for new-package-review?
[14:12] <geser> hrw: a core-dev is needed for sponsoring, try #ubuntu-devel
[14:14] <hrw> persia: this is on a ftfbs list so I just looked at it and got it built
[14:15] <hrw> persia: http://pastebin.com/ZeU02EsB is full patch (does not include debian/changelog entry)
[14:15] <persia> hrw, My recommendation would be to file a bug, attach a debdiff to the current version, and subscribe ubuntu-sponsors.
[14:15]  * persia can't sponsor it anyway
[14:16] <geser> hrw: does it really need to get linked to all those libraries in $(VTE_LIBS) instead of -lvte?
[14:17] <hrw> geser: good question. probably not, fix on a way
[14:21] <Laney> it probably
[14:21] <Laney> oops
[14:21]  * Laney has been doing that a lot lately
[14:22] <persia> most likely :)
[14:24] <hrw> bug 649810 is ok?
[14:24] <geser> Laney: there doesn't seem to currently be any strong reasons to remove emerald now as long as it still works
[14:25] <Laney> geser: I'm not suggesting any course of action in particular
[14:25] <Laney> just that someone should care for it
[14:26] <geser> Laney: I just wanted to inform you of the "result" of my question in #-desktop
[14:26] <Laney> ok, cheers :)
[14:26] <persia> hrw, Looks about right to me.  Just waits on a sponsor.
[14:27] <persia> hrw, You may have wanted to use a patch system, or if you did, you may have wanted to add a DEP-3 header.
[14:27] <persia> Also, generally we include debian/changelog and debian/control changes in our sponsorship requests.
[14:29] <hrw> persia: will have to learn more first
[14:29] <persia> hrw, Do you want help or guidance doing so?
[14:30] <hrw> persia: after 1.5h from now or tomorrow. conf call time is near
[14:31] <persia> Just ask here.  I won't be around to help then, but lots of other folks will be.
[14:31] <hrw> persia: I know ;) thats why I am here
[14:35] <hrw> persia: by 'to use a patch system' you mean "quilt, stgit, dpatch" like tools - right?
[14:35] <persia> Right, if one exists in that source package.  It may not.
[14:37] <hrw> this is native package without patches
[14:38] <hrw> so I just patched sources directly
[14:38] <hrw> if it would use dpatch or quilt I would use it too
[14:38] <persia> That makes sense then :)
[14:39] <hrw> persia: "generally we include debian/changelog and debian/control changes in our sponsorship requests" - there was no control changes in package and one changelog entry just to bump version
[14:41] <persia> hrw, Right.  I missed the (small) changelog entry.  If I wrote it, I'd probably add "(LP: #649810)" somewhere so that the LP janitor will close the bug with upload.
[14:41] <persia> You will want to change the control file for an -Nubuntu1 upload, because you'll want to adjust the maintainer to be "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" instead of whoever maintains the unpatched version.
[14:43] <persia> I think the `update-maintainer` script in ubuntu-dev-tools does this.
[14:43] <hrw> persia: right. bug was after I created source package
[14:44] <hrw> ok, bb in few
[15:41] <ari-tczew> hey, I added [natty] to bug topic to target fixing, but pedro_ has removed this one. what is right? bug 339169
[15:41] <ari-tczew> Laney: ^^
[15:42] <geser> IIRC it's not very liked to include the release names in bug titles
[15:42] <geser> ari-tczew: have you talked to pedro about it?
[15:43] <ari-tczew> geser: not yet. it's related to last discussion about reviewing main sponsorship by MOTU.
[15:43] <ari-tczew> and I want explain there before talk to pedro.
[15:49] <Laney> ari-tczew: Why don't you explain to him what it was about?
[15:50] <Laney> ari-tczew: I suggest you try and sound a bit more constructive in your comments too. "This patch is obsolete" is a bit abrupt.
[15:50] <ari-tczew> Laney: because I would get sure that right is mine. so I pinged you to my question. IIRC you would use [natty] in bug topic.
[15:51] <Laney> I would thank the submitter for the patch, but sya that it's too late to include for Maverick at this stage, and indicate that I'm adjusting the title so that sponsors know to look in a few weeks.
[15:52] <Laney> Did you check that the patch doesn't apply any more?
[15:53] <ari-tczew> Laney: I've been suggested by karmic target in debdiff.
[15:53] <ari-tczew> btw. pedro on #ubuntu-desktop suggest to use tags instead changing bug topic.
[15:53] <Laney> It's easier for a sponsor to fix that than to bounce it back to the submitter.
[15:53] <Laney> round trips are a large cost
[15:56] <ari-tczew> Laney: well, what's the final of our discussion? tag or bug-title to targeting next release?
[15:57] <Laney> I don't care about that, as long as people know to look at it
[15:57] <Laney> and if you can fix the sponsoring overview to know about it
[15:58] <Laney> I care more about bouncing bugs back to the submitter unnecessarily
[15:59] <ari-tczew> Laney: now in Feature Freeze I'm testing the patch. if it fixes any bug, I'll update debdiff and give to ubuntu-release for review.
[16:00] <ari-tczew> above case is strange, because there are not test-case, so I can't reproduce.
[16:02] <Laney> I would err on the side of assuming correctness until you actually come to upload it
[16:04] <ari-tczew> but I can agree with you Laney, that saying 'patch is obsolete' is a push work to someone else, which could discourage contributor.
[16:05] <ari-tczew> in this case, author of patch is a canonical employee, so I think that he won't be discouraged. :P
[16:05] <Laney> Right. It may be the case that it actually *is* obsolete, but it's still our fault for not reviewing it faster, and you should say what your investigations have revealed
[16:11] <ari-tczew> Laney: btw. I think that adding a target patch should be a minimum, because searching a bugs with tag 'natty' is easier than looking for bugs with '[natty]' in topic. anyway, we should open a discuss about it via list-mail.
[16:11] <ari-tczew> bdrung_: did you it? ^^
[16:12] <Laney> as I said, I don't care, as long as the sponsor overview supports it
[18:07] <ari-tczew> iulian: around?
[18:44] <didrocks> no release in bug title
[18:45] <didrocks> it's breaking thread discussion…
[18:45] <didrocks> and sorting in bug mail
[18:45] <didrocks> so please, tag :-)
[19:03] <micahg> stefanlsd: thanks, I'll file the bug
[19:30] <ari-tczew> I used natty-sponsor tag.