[12:02] <sistpoty> cya ajmitch
[12:03] <LaserJock> so sistpoty should we remove the k* packages from "new" so people won't try to merge them?
[12:04] <sistpoty> LaserJock: yes
[12:04] <sistpoty> LaserJock: I will do that
[12:05] <LaserJock> sistpoty: cool
[12:05] <Riddell> LaserJock: out of http://revu.tauware.de/~sistpoty/MoM/index.py?state=new though only kdeaccessiblity is part of KDE
[12:06] <Riddell> the rest are independent and won't be updated with a KDE release
[12:06] <Riddell> sorry, I only just looked at that URL
[12:06] <sistpoty> Riddell: phew... I only deleted kdeaccessibility right now *g*
[12:06] <LaserJock> oh, ok. that is what I thought I asked you but I guess you misunderstood
[12:07] <LaserJock> or I guess I didn't ask the question very well :(
[12:08] <LaserJock> so kguitar kmatplot kmess and knetfilter will need to be synced/merged, correct?
[12:08] <Riddell> my fault I'm sure :)
[12:08] <Riddell> yes
[12:09] <LaserJock> whew, glad we caught that one :-)
[12:25] <womble> Note for anyone interested: remove the 'irm' package from Dapper.  It's not release-ready, and I won't have time to make it so before UVF.
[12:27] <crimsun> womble: if you can fix it, please do. We do have exceptions to UVF.
[12:28] <womble> crimsun: If I could fix it in time, I would.
[12:28] <crimsun> womble: not within the next two months?
[12:29] <womble> You think I'd be saying "rip it out" if I had a real expectation of getting it done in time?
[12:29] <crimsun> well, it's your call.
[12:30] <crimsun> your package, you know best.
[12:30] <womble> If I get laid off or something, and I suddenly get time, you can use the exceptions to put it back in.  As it stands, I do not have the slightest expectation of having the time required to make IRM release worthy in the next couple of months.
[12:32] <crimsun> fair enough
[01:02] <sistpoty> oh, come on... there is s.th. wrong again with mails for merge list :(
[01:08] <sistpoty> hm... seems fixed now :)
[01:17] <sistpoty> gn8 everyone
[01:48] <psusi> woohoo!  new dvd/cd-rw drive arrived today!
[02:28] <psusi> anyone else notice the last day or two's updates broke bash tab completion?
[02:29] <psusi> it allways adds a / as if everything is a directory ( it's a normal file though )
[04:07] <\sh> moins
[04:10] <crimsun> moins
[06:07] <LaserJock> ajmitch: do you have a minute or are you already gone for the weekend?
[06:09] <LaserJock> anybody smarter than me around? :-)
[06:16] <LaserJock> hmm, this can't be good.
[06:20] <minghua> LaserJock: why is that?  it's bad to be the smartest man in the channel? ;-)
[06:20] <LaserJock> yeah, when I need help :-)
[06:21] <LaserJock> I'm trying to get octave2.9 in Ubuntu
[06:23] <minghua> Hmm, I am interested in that
[06:23] <minghua> (being the merger of octave2.1 myself)
[06:24] <LaserJock> yeah, I just remembered that
[06:25] <LaserJock> elmo's problem was that the octave virtual package in 2.9 clobbers octave2.1
[06:25] <LaserJock> or something like that
[06:25] <LaserJock> here is his error:
[06:25] <LaserJock> [Updating]   octave2.9 (0 [Ubuntu]   < 2.9.4-8 [Debian]  )
[06:25] <LaserJock> E: octave2.9 is trying to override octave_2.1.71-2ubuntu3 without -f/--force.
[06:26] <LaserJock> and then the Debian changelog says:
[06:26] <LaserJock>   * debian/in/control: The octave virtual package is now only generated
[06:26] <LaserJock>     for the 2.9 branch, but depends on octave2.1, which is the recommended
[06:26] <LaserJock>     version for end-users.  This is counter-intuitive, but is necessary
[06:26] <LaserJock>     due to a mistake in uploading the octave virtual package with version
[06:26] <LaserJock>     2.9.4-1, which is still stuck in unstable.
[06:27] <LaserJock> so I'm not sure what exactly is going on
[06:32] <minghua> LaserJock: I think he needs to sync octave2.1 first
[06:33] <minghua> no, that won't work...  octave2.1 2.1.72-6 still builds octave
[06:33] <minghua> I probably can patch that
[06:34] <minghua> but I don't know why octave2.1 is still not sync'ed yet
[06:34] <LaserJock> hmm, then how does it work in Debian?
[06:35] <LaserJock> minghua: the changelog indicates that 2.1 should no longer build octave
[06:35] <LaserJock> or am I reading that wrong
[06:35] <minghua> LaserJock: let me check
[06:37] <minghua> LaserJock: the most recent version in sid, octave2.1 2.1.72-8, still builds a arch:all octave binary package
[06:37] <minghua> LaserJock: I don't know how that's supposed to work either
[06:38] <minghua> well, if octave2.1 got sync'ed, I'll have more motivation to work on it
[06:38] <minghua> now I am afraid there is something wrong
[06:38] <minghua> s/am afraid/worry/
[06:39] <LaserJock> well, would the sync of octave2.1 take care of it
[06:39] <minghua> no, it won't
[06:39] <minghua> but now it doesn't get sync'ed even two MOTUs have requested it, I don't know what I should do
[06:40] <minghua> maybe I can ask elmo myself, but I don't care octave enough
[06:40] <LaserJock> when did the MOTUs request the sync?
[06:44] <LaserJock> ok so here is the octave2.1 changelog entry:
[06:44] <LaserJock> octave2.1 (1:2.1.72-7) unstable; urgency=low
[06:44] <LaserJock>    +++ Changes by Rafael Laboissiere
[06:44] <LaserJock>   * This version use an epoch in his number.  This is necessary due to the
[06:44] <LaserJock>     mistake I did in uploading the octave_2.9.4-1 virtual package to
[06:44] <LaserJock>     unstable.  The 2.9.4-1 version replaced the 2.1.72-* version and this
[06:44] <LaserJock>     is wrong because the 2.1 (testing) branch should take precedence over
[06:44] <LaserJock>     the 2.9 (unstable) branch.
[06:45] <LaserJock> I don't quite now what ^^ means
[06:46] <LaserJock> minghua: maybe we should consult the debian octave group?
[07:00] <minghua> LaserJock: there?
[07:01] <LaserJock> yeah
[07:01] <minghua> I think I'm hit by the server rotation
[07:01] <minghua> the last thing I see is <LaserJock> minghua: maybe we should consult the debian octave group?
[07:01] <LaserJock> that's the last I said
[07:01] <LaserJock> you didn't miss anything ;-)
[07:02] <minghua> okay, now reading the octave2.1 changelog, it seems octave2.9 should drop the octave binary package
[07:03] <LaserJock> so maybe we should sync octave2.1 and merge 2.9 taking out the building of octave virtual package?
[07:05] <minghua> I'm completed confused.  octave2.9 2.9.4-8 still builds octave binary package, but it's not in debian archive
[07:05] <minghua> I think there is a RC bug here
[07:06] <LaserJock> yeah, that is what I'm trying to figure out. It seems as if we aren't using the same source or something
[07:07] <minghua> LaserJock: I _think_ what happened is that octave2.1 and octave2.9 was having a war with the octave binary package
[07:07] <minghua> first octave2.9 2.9.4-8 was uploaded building octave 2.9.4-8
[07:07] <LaserJock> and they just let octave2.1 win :-)
[07:08] <minghua> then octave2.1 2.1.72-7/8 is uploaded building octave 2:2.1.72-7/8
[07:09] <minghua> LaserJock: exactly.  and with the epoch octave2.1's package win, since binary package must belong to a single source package (this is the part I am not sure), octave 2.9.4-8 is removed
[07:09] <LaserJock> ahh, I am starting to see
[07:09] <minghua> someone know how Debian archive works need to confirm this :-)
[07:10] <Yagisan> G'day All
[07:10] <minghua> LaserJock: so I think the right way is stop building octave in octave2.9, which we can fix in universe
[07:10] <minghua> hello Yagisan
[07:11] <LaserJock> minghua: right
[07:11] <Yagisan> ajmitch: thanks for the help last night. Now all I need to do is figure out how to replace my apache server with that, and not break my ubuntu/debian repos at the same time.
[07:12] <minghua> LaserJock: but a debian bug should be filed even we fix them ourselves
[07:12] <Yagisan> minghua: so how are things going ?
[07:12] <minghua> Yagisan: quite good, busy though
[07:12] <minghua> trying to squeeze some time for the new scim packages
[07:12] <minghua> s/packages/releases/
[07:13] <LaserJock> minghua: ok, so report a bug that octave2.9 builds octave but only octave2.1 should be doing that ?
[07:13] <Yagisan> minghua: I understand - I have  a time squeeze myself. I don't have any free time left atm to work on my wine for amd64 patches.
[07:13] <Yagisan> minghua: looking forward to your new scim stuff though
[07:13] <minghua> LaserJock: yeah, something like "octave2.9 should stop building octave binary package now that octave2.1 is building it instead"
[07:14] <LaserJock> ok, and we should merge it in the meantime?
[07:14] <minghua> Yagisan: freeflying uploaded 1.4.4-0ubuntu1 in dapper, so the code is there, I am mainly working on documentations
[07:14] <minghua> LaserJock: I would like to see octave2.1 sync'ed first
[07:15] <minghua> LaserJock: but if we remove octave from octave2.9, it's probably safe
[07:16] <LaserJock> I'm just thinking about UVF, would octave2.9 be effected?
[07:17] <minghua> LaserJock: I think so.  But octave2.1 needs to go before UVF too IMO
[07:17] <minghua> and octave stuff isn't really my priority
[07:18] <LaserJock> no, I don't know what more we can do with 2.1, I mean you ask elmo and wait
[07:18] <LaserJock> in the mean time perhaps I will merge 2.9 to take out the building of the virtual package
[07:20] <minghua> LaserJock: If you really want to do it, merge octave2.9 and drop octave from octave2.9's debian/control, make sure it can coexist with the current octave2.1 in dapper
[07:20] <minghua> then I think it's safe to upload
[07:21] <LaserJock> minghua: I already built it in a pbuilder and installed it on my machine
[07:21] <LaserJock> everything was good
[07:22] <minghua> LaserJock: without octave binary package?
[07:22] <LaserJock> but I don't know that I had octave already installed
[07:22] <LaserJock> but right now I have octave from 2.9
[07:22] <LaserJock> so I think if I take it out of 2.9 we will be in business
[07:23] <minghua> install everything from octave2.1 and everything from octave2.9, if nothing bad happens, it's safe enough for me
[07:24] <LaserJock> hmm, if I go to install something from 2.1 it wants to remove the corresponding 2.9 package
[07:25] <minghua> (making sure there are no packages with same name, of course)
[07:25] <LaserJock> in all reality if the DDs don't think 2.9 should be used by users then maybe we shouldn't worry about it for now
[07:25] <LaserJock> until Debian gets things straightened out
[07:26] <minghua> yeah, I would think octave2.1 is more important then octave2.9 too
[07:26] <minghua> s/then/than/
[07:27] <LaserJock> ok, I am comfortable with just letting Debian sort it out and getting on to other, more important things
[07:27] <LaserJock> just so I know what is going on though
[08:20] <persia> I'm bored and would like to post some useful patches to Malone, rather than just comments suggesting the packages.  Could someone point me a to a good resource for instructions?
[08:23] <\sh> for attaching bugs, or how to patch sources?
[08:24] <persia> Specifically, I have a few local compiles for uninstallable packages, and there are clear descriptions to make a patch for bugs #3650 and #3663 (I'm sure I could find more).  I'd like to make a package patch so that the appropriate MOTU would have an easier time making a package for upload.
[08:26] <\sh> persia: is this issue still there?
[08:27] <\sh> persia: in dapper i mean
[08:27] <persia> I've not investigated the bugs I listed yet, but libjackasyn0, brutefir, freewheeling, iripdb, jackeq, kluppe, and seq24 are all unionstallable, although I have local working packages.
[08:27] <persia> Yes, all in dapper.
[08:28] <\sh> give me a sec...I need to finish some stuff
[08:28] <persia> No worries.
[08:29] <minghua> persia: when you say locak working packages, you mean .deb packages built from dpkg-buildpackage, debuild etc.?
[08:30] <minghua> persia: in that case debdiff is probably all you need to know
[08:30] <persia> minghua: Yes.  I just don't know what diff to run before posting a patch to Malone.
[08:31] <persia> minghua: So, just debdiff repository-package mypackage, and upload that?
[08:31] <minghua> persia: something like "debdiff <package_old-version.dsc> <package_new-version.dsc>" should be good
[08:31] <persia> minghua: Thanks.  That sorts it.
[08:31] <minghua> persia: yes, paste the debdiff to malone
[08:31] <minghua> handy, huh? :-)
[08:32] <persia> minghua: Absolutely.  Thanks again.
[08:33] <\sh> the problem is...with this, there is a conflict
[08:33] <\sh> with python-elementree...which should be only a meta package with a depends on python2.4-elementtree
[08:33] <\sh> strange that this happens
[08:35] <persia> \sh: I'm guessing that there was a transition between a single package and versioned packages, although I've not looked at the history yet.  Are you looking at this now?  Shall I skip it?
[08:35] <\sh> persia: no..please have a look :)
[08:35] <\sh> persia: if you need some help, please jell :)
[08:35] <\sh> yell even
[08:36] <persia> \sh: OK.  If I fix it today, I'll post a patch.  Thanks.
[08:37] <\sh> persia: thx...i subscribed to this bug now...so I receive it directly in my inbox instead of my malone bugs folder :)
[08:37] <\sh> persia: and thx for working on it :) your work is appreciated :)
[08:39] <minghua> persia: you are very welcome.  as \sh said, thanks for helping :-)
[08:40] <\sh> trying to solve the qt bugs now'
[08:40] <\sh> the last comment is quite right :)
[08:40] <\sh> minghua: you saw the last comment of malone #6606
[08:40] <Ubugtu> Malone bug 6606: "x11-free (Ubuntu) - qt-x11-free 3:3.3.5-1ubuntu11 causes xim failure" Fix req. for: qt-x11-free (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6606
[08:41] <minghua> \sh: just saw it.  It makes so much sense now.
[08:42] <\sh> just fakeroot make -f debian/rules build it now :) to see what is really installed
[08:42] <minghua> \sh: in GTK the XIM mode is provided by /usr/lib/gtk-2.0/2.4.0/immodules/im-xim.so, so that's very likely the source of the problem
[08:43] <\sh> minghua: looks like, because I don't have any inputmethod plugins at all installed
[08:43] <\sh> just libqscim.so
[08:43] <minghua> \sh: that should belong to scim-qtimm, I suppose?
[08:43] <\sh> just searching for it...but seems so
[08:44] <\sh> if this is the case, that files are missing, this should be easily resolvable
[08:44] <minghua> somebody need to look at what patch SuSE is using, it seems :-)
[08:45] <\sh> minghua: they are using the same...but installation is included..looks like that we are missing that :)
[08:45] <minghua> weird.  let me read some build log, then
[08:50] <\sh> they are not installed when I'm searching for usr/lib/qt3/plugins/inputmethods
[08:51] <minghua> \sh are they built at all?
[08:51] <\sh> yes
[08:51] <\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-multi/imsw-multi.pro (fast)
[08:51] <\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-none/imsw-none.pro (fast)
[08:51] <\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/simple/simple.pro (fast)
[08:51] <\sh>   for /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/xim/xim.pro (fast)
[08:52] <\sh> oh no
[08:52] <\sh> the makefiles are generated
[08:52] <\sh> but looks like that building is complety missing
[08:52] <minghua> I saw those too, with "mv -f libqxim.so ../../../inputmethods/" later
[08:53] <\sh> cd imsw-none && make -f Makefile
[08:53] <\sh> make[4] : Entering directory `/build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-none'
[08:53] <\sh> /build/buildd/qt-x11-free-3.3.5/bin/qmake  -spec /build/buildd/qt-x11-free-3.3.5/mkspecs/linux-g++ -o /build/buildd/qt-x11-free-3.3.5/./plugins/src/inputmethods/imsw-none /build/buildd/qt-x11-free-3.3.5/plugins/src/inputmethods/imsw-none/imsw-none.pro
[08:53] <\sh> cd /build/buildd/qt-x11-free-3.3.5/./plugins/src/inputmethods/imsw-none
[08:53] <\sh> oh it's build ... bah..I hate this build system of qt
[08:54] <\sh> cp -f "../../../inputmethods/libqimsw-multi.so" "/build/buildd/qt-x11-free-3.3.5/debian/tmp-install/usr/lib/qt3/plugins/inputmethods/libqimsw-multi.so"
[08:54] <minghua> I saw two identical lines of this cp thing
[08:54] <\sh> and there it's going to be installed into the correct directory...but there is no such directory for including it into the package
[08:55] <minghua> so we are just missing a .dirs or mkdir in debian/rules?
[08:55] <\sh> I think we should create a libqt3-inputmethods package
[08:56] <minghua> why do they use "cp -f"?  why?
[08:56] <\sh> to move it from the source dir into the install dir
[08:57] <\sh> which means: debian/tmp-install/usr/lib/qt3/plugins/inputmethods/* but to package it, it needs a line in one of the .install files in debian/dir but I think it's much better to have a separate package
[08:57] <minghua> hmm, "cp -f" does give a error message if the target doesn't exist
[08:57] <minghua> so it's not "cp -f"'s fault, sorry :-P
[08:58] <minghua> \sh: if separate package, is libqt3-mt going to depend on it?
[08:58] <\sh> minghua: that's what I have to find out with riddell
[08:59] <minghua> \sh: at least the problem is clear now, good
[08:59] <\sh> rational: libqt3-mt doesn't need the plugins to be running and working properly.
[08:59] <\sh> solution: it could be a recommend or suggest
[09:00] <\sh> finally fixing it would be: any installation locale != latin must install it
[09:00] <minghua> with out this qt-immodule patch, XIM mode works fine in KDE;  now with this patch, XIM users need to install an extra package manually
[09:00] <\sh> minghua: i don't want to decide it :) I'm fixing somehow now the problem with installing and then we need to find a way to install it directly as dependency of libqt3-mt or something else
[09:01] <minghua> \sh: no problem, I'm just expressing my concerns
[09:01] <\sh> is xim installed by default, btw
[09:01] <\sh> ?
[09:02] <minghua> well, the protocol is, but you need specific XIM servers to really use it
[09:02] <minghua> XIM protocol comes with X
[09:02] <\sh> yes, but scim e.g. is this installed by default?
[09:03] <minghua> different servers are provided by other programs
[09:03] <\sh> if not, then the user need to install it somehow manually to get it to work...
[09:03] <minghua> \sh: not in breezy, and I don't think it's going to be in dapper either
[09:03] <minghua> \sh: my point is, this works different than Debian (and probably every other distros)
[09:03] <\sh> ok...so manual intervention of the user is necessary
[09:04] <minghua> \sh: users don't expect to install extra packges besides XIM servers to get XIM work
[09:04] <\sh> to be honest, I think it's not installed by default for suse or redhat...they think first, that everybody is using latin inputs
[09:04] <minghua> and in GTK such stuff comes with libgtk2.0-0
[09:05] <\sh> ok..so let me discuss this issue with riddell..he is responsible for this ;)
[09:05] <minghua> libqxim.so is in qt3-3.3.4-28.i586.rpm just for the reference
[09:05] <\sh> or actually I'll make him responsible :)
[09:05] <\sh> mandriva?
[09:05] <minghua> suse
[09:06] <Gloubiboulga> hello
[09:06] <persia> A question about debdiff: it there a handy way to exclude config.sub, config.guess, and config.log?  Otherwise the changes are fairly difficult to see [I only intentionally modified the changelog and control file - dpkg-buildpackage did the rest] .
[09:06] <minghua> in suse linux 10.0, according to http://www.novell.com/products/linuxpackages/professional/qt3.html
[09:06] <\sh> persia: well..depends how the debian/rules file replaced those files
[09:07] <\sh> persia: config.{guess,sub} are normally copied during clean target, which is somehow a bit bad :)
[09:07] <\sh> moins StevenK
[09:08] <persia> \sh: Yes, these are copied (from /usr/share/misc)  Is there a better way?
[09:09] <\sh> persia: somehow I'm moving this piece of code ( I think it's starting with if in the rules file, as shell if) into the configure target
[09:09] <minghua> persia: I think the preferred way is to rm them in clean target, and copy them in configure/build target
[09:09] <\sh> and removing it in the clean target
[09:10] <\sh> persia: the default dh_make behaviour is somehow outdated (IMPOV)
[09:11] <\sh> minghua: ok...the inputmethods are installed in the tmp-install dir...so it's a matter of including them in the package itself...
[09:11] <\sh> fixing it now
[09:11] <persia> grumble.  Perhaps I'll go back to posting solutions, as I doubt anyone wants to read these (last update of the package I was looking at was October).
[09:12] <\sh> persia: I fix libqt3 :) not this elementtree :)
[09:12] <minghua> so qt-x11-free doesn't use dh_install --sourcedir= ?
[09:13] <\sh> minghua: to be honest..I don't know..I'll have a look now..it uses .install files
[09:13] <\sh> to move it into the correct position
[09:13] <minghua> \sh: add --list-missing if it uses that :-)
[09:13] <\sh> it uses it..but I'll do it now in the libqt3 package :)
[09:14] <persia> \sh: Actually, I'm currently working on libjackasyn (for which you happen to have been the last uploader) :).  No worries, I'll just post some bugs with comments about fixes.  Thanks for the advice anyway.
[09:16] <\sh> persia: oops...what's wrong with this package?
[09:17] <persia> \sh: Still depends on libjack0.80.0.  debian/control should have build-dep adjusted to libjack-dev instead of a versioned value, as multiple jack libraries won't work on a system.  Don't worry about it now: I'm creating a bug for your later enjoyment.
[09:17] <\sh> persia: oh...was it for dapper, or breezy?
[09:18] <\sh> I think we changed this package in dapper or breezy, when libhack0.100.0 wasn't available for ubuntu
[09:18] <persia> \sh: Dapper.  BTW, thanks for the cleaner patch for solfege earlier.
[09:19] <persia> \sh:  Yes, at last change, 0.100 wasn't available yet.  Given the extremely large number of vocal users of the package, I doubt anyone but me noticed.
[09:19] <\sh> persia: well...I don't know if it's cleaner, but doesn't implement new bugs in a not written python script :) and avoids the awk sed dep
[09:20] <\sh> minghua: i included now the inputmethods in the libqt3-mt package...just building it and checking if the files are in the package...if yes, could you test it when it hits the archive?
[09:22] <minghua> \sh: Sure, would love to
[09:24] <minghua> wonder when it would hit archive though, hopefull before I go to sleep
[09:24] <\sh> minghua: I would say, let it be 2-3 hours :) so when you wake up, and do a dist-upgrade you will have it :)
[09:26] <minghua> \sh: will test it tomorrow morning then :-)
[09:26] <\sh> minghua: cool:)
[09:27] <minghua> it's lucky tomorrow is Saturday
[09:27] <\sh> no today is saturday ;)
[09:36] <minghua> \sh: since Riddell is not around - does the qt-immodule patch change the ABI?
[09:37] <\sh> minghua: it shouldn't and it's written on the homepage for this patch
[09:37] <minghua> \sh: I am asking because someone in Chinese channel mentioned that he tried using the scim-qtimm ubuntu package in debian, and it "behaves strangely" (his words), so I am curious
[09:38] <\sh> minghua: well...without the patches in debian, it should not work as expected..
[09:38] <\sh> minghua: but abi should not be changed
[09:38] <minghua> \sh: oh good then, I know scim-qtimm is not supposed to work without this patch for qt, so that guy perhaps was just not clear
[09:40] <\sh> well..mixing binary packages between debian and ubuntu is not good at all :)
[09:41] <minghua> \sh: where does it say ABI is not changed on the homepage?  I only found "binary compatible"
[09:41] <minghua> \sh: I was on your side in that thread ;-)
[09:42] <\sh> minghua: that is "binary compatible"...API is changed yes, but not abi...
[09:42] <\sh> well..actually you would see abi breackage of kde or something else:)
[09:43] <minghua> \sh: so no new functions added?  I am talking about shlib bump
[09:43] <\sh> minghua: no
[09:43] <minghua> \sh: KDE won't break in such case
[09:43] <minghua> \sh: okay good, I know nothing about Qt/KDE so I'll trust you guys
[09:44] <\sh> minghua: if shlibs would be bumped even kde is crashing..because ABI is quite important for the shared linking :)
[09:45] <minghua> \sh: even if only new functions are added?  that's not how I heard (although I admit I don't really know such stuff)
[09:46] <minghua> \sh: at least for C ABIs, you can add new functions without breaking old packages, no?
[09:47] <minghua> otherwise for each shlib bump there need to be mass rebuildings
[09:47] <\sh> minghua: that is always the case for new functions...but shlibs bump means really: that I increase e.g. for qt the libqt-mt 3 libqt3-mt to libqt-mt 4 libqt3-mt
[09:48] <\sh> minghua: therefore all dependencies are stalled and we have to rebuild...for abi changes it means (library vise) that all addresses and symbols are somehow relocated, which makes each app which links against this lib going mad :)
[09:49] <\sh> and uploaded the new version :)
[09:49] <minghua> \sh: but you still need to change the shlib version if new functions are added, right?
[09:50] <minghua> like from libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.6.0) to libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.8.0)
[09:50] <\sh> minghua: yes, but not for this patch, because it's not "adding functions to the core lib" it's adding new "plugins" :)
[09:50] <minghua> \sh: and I don't really understand your example of "libqt-mt 3 libqt3-mt" to "libqt-mt 4 libqt3-mt"
[09:50] <\sh> minghua: no....the major version didn't change of the lib
[09:51] <\sh> well...if the source of qt3 is building libqt-mt.so.4 then shlibs have to be changed. so long as libqt-mt.so.3 is actual, no shlibs bump
[09:51] <\sh> (that's for debian)
[09:51] <minghua> \sh: great, that's all I want to know ("only adding new plugins")
[09:52] <minghua> \sh: well that's going to be a SONAME change and library package renaming, not just a shlibs bump, I suppose
[09:53] <minghua> unless libqt-mt.so.4 is binary backward compatible with libqt-mt.so.3, in which case they should just keep calling it .3
[09:55] <\sh> minghua: not at all :) .4 is a new lib, which means the abi is different, but the API can still be compatible
[09:55] <josesanch> Hello
[09:56] <\sh> minghua: so to let old packages which are linked against .3 run, it has to be recompiled with the new lib..but it would work
[09:56] <\sh> but not without recompiling :)
[09:56] <josesanch> what can i do to include a package in universe?
[09:56] <minghua> \sh: that part I understand, I don't understand the part of "but shlibs bump means really: that I increase e.g. for qt the libqt-mt 3 libqt3-mt to libqt-mt 4 libqt3-mt"
[09:57] <josesanch> i have packages of the software.
[09:57] <\sh> josesanch: first you can upload it to revu
[09:57] <\sh> a how to is on wiki.ubuntu.com/REVU
[09:58] <minghua> \sh: shouldn't that be "libqt-mt 4 libqt4-mt" (library renaming) if the ABI is different?
[09:58] <josesanch> Ok i'm going to read it
[09:58] <\sh> josesanch: or if there is no debian package you can put it on wiki.ubuntu.com/UniverseCandidates
[09:58] <\sh> minghua: in this very special case, yes :)
[09:58] <minghua> \sh: I always assumed that a shlibs bump means you don't have to rebuild binary packages
[09:59] <josesanch> It's a software that i have develop. http://gnomecatalog.sf.net
[09:59] <minghua> s/binary packages/packages that are linked to this library/
[10:00] <josesanch> There is only the packages that i do. It's not included in debian. I had put in universecandidades
[10:00] <\sh> josesanch: well...If I take a guess, you included the debian/dir into your upstream source, right?
[10:01] <\sh> minghua: if the major lib version changes, you normally have to
[10:01] <josesanch> yes
[10:02] <minghua> \sh: now I am all clear.  I'll talk about "shlib bump without SONAME change" next time.  :-)
[10:02] <\sh> josesanch: ok..one advice: 1. never include debian/ dir in your upstream source... 2. if you want to be the packager of this software, please put the debian dir separated from the upstream source
[10:03] <josesanch> Ok i'll do it
[10:03] <josesanch> how a patch. it isnt?
[10:03] <\sh> josesanch: no...you have to repackage your upstream tarball..
[10:04] <josesanch> ok
[10:04] <\sh> josesanch: remove the debian dir completly from the tarball...and this tarball u will use as orig.tar.gz, and you debianize the source afterwards..so you have always a clean tarball without any distro specific changes
[10:05] <josesanch> aha.. ok
[10:05] <\sh> josesanch: which is good for distros like redhat or suse or mandriva
[10:09] <\sh> persia: fixing this elementtree thing
[10:09] <josesanch> \sh: Thanks. I'll clean debian dir and will upload the package to revu
[10:10] <\sh> josesanch: you have to do a source package upload :) so you have to prepare a debian package at all :) but with a orig.tar.gz (without debian/ dir) and a debianzied source tree, which will give you a .dsc, a .diff.gz and an .orig.tar.gz
[10:11] <\sh> josesanch: a source upload you can prepare with debuild -S -sa e.g.
[10:11] <persia> \sh: OK.  I'm just cruising through Malone looking for things that need a little investigation.  Any suggestions?  (BTW, I have never used python-elementtree).
[10:11] <\sh> persia: but you were right :)
[10:11] <\sh> persia: the bug was invented by ogra in breezy :)
[10:12] <persia> \sh: Changelogs are a wonderful thing ;)
[10:13] <\sh> buxy: it's not worth it to fight windmills :)
[10:19] <Yagisan> re
[10:24] <StevenK> \sh: You said orig tarball twice. :-P
[10:25] <\sh> StevenK: damn :)
[10:28] <minghua> StevenK: but xfonts-cjk doesn't really exist in Debian either?
[10:35] <josesanch> \sh: i do a debuild -S -sa and i get a gpg: skipped "Jose Sanchez Moreno <jose@oxigenow.com>": secret key not available, fatal error
[10:36] <\sh> josesanch: do you have a gpg key ?
[10:36] <josesanch> i had generated
[10:36] <josesanch> \sh: gpg --gen-key
[10:36] <\sh> without it's not possible to upload :) we are allowing signed packages
[10:36] <\sh> josesanch: and the real name and your email address is the same as in the key?>
[10:37] <josesanch> ummm..
[10:37] <josesanch> well. the problem is "'"  jos snchez
[10:37] <josesanch> i'm going  to check it
[10:38] <buxy> \sh: I won't loose X days fighting, but it's certainly worth saying that many people are trying to collaborate between Ubuntu and Debian
[10:38] <StevenK> minghua: I noticed. I'd just to know *what* to use instead of xfonts-cjk
[10:39] <\sh> buxy: well...so I give them what they (some DDs/PMs) want :) I will just file any changes towards the BTS...even it's not possible for debian yet, to use those changes...well...I wonder when I'm catched in their spam filters :)
[10:40] <StevenK> -r--r--r--  14 root root 2.2M 2000-07-06 01:39 /media/cdrom/dists/potato/main/binary-all/x11/xfonts-cjk_3.3.6-2.deb
[10:40] <\sh> buxy: seeing that some troublesome bug reports were never touched by some maintainers..I'm just curious what will happen to them
[10:40] <StevenK> Whee
[10:41] <minghua> StevenK: xfonts-base since it provides xfonts-cjk?
[10:43] <buxy> \sh: please don't play their stupid game, send only changes worth integration into Debian, or inform about a patch that may be useful in the future but try to be smarter than the dumbass who are flaming on the d-d list
[10:44] <StevenK> minghua: xfonts-base doesn't mention CJK
[10:44] <Yagisan> \sh: buxy: I just read the list, but to me it seems that those that want to help already do, the others seem to have a bug up their arse, possibly because they didn't get a job at canonical.
[10:44] <\sh> buxy: if you query my submitter email address (sh@sourcecode.de) you'll see most of the time sourcecode patches..which are as well interesting for debian. How many do you see fixed?
[10:45] <Yagisan> \sh: buxy: why waste time on them ?
[10:46] <josesanch> \sh: i had do it a debuild -S -sa.  generates a tar.gz, but debian dir is included.
[10:46] <\sh> josesanch: well..then is something wrong
[10:46] <minghua> StevenK: I know for sure three chinese fonts are there, try "xfd -fn hanzigb16fs" for example
[10:46] <\sh> josesanch: ok..your source dir is app-0.2 as an example
[10:46] <josesanch> debian dir is still in the gnomecatalog dir.
[10:46] <StevenK> josesanch: You don't have a .orig.tar.gz or a .orig in ..
[10:46] <minghua> StevenK: that's actually a very nice font
[10:47] <\sh> so your contents of the orig.tar.gz (upstream tarball without debian/ dir) should include app-0.2/ directory
[10:47] <StevenK> minghua: Doesn't look so good for me on Breezy.
[10:47] <josesanch> no
[10:48] <\sh> josesanch: no?
[10:48] <josesanch> i have a gnomecatalog dir i have gnomecatalog/debian . In gnomecatalog/ i do a debuild -S -sa. I only get a tar.gz with de debian dir included
[10:49] <minghua> StevenK: why?  the latin letters may be not so good, but did you look at the Chinese chars?
[10:49] <StevenK> minghua: I didn't see any Chinese chars.
[10:49] <minghua> StevenK: press the "Next" button several times, please (or the "+16" button)
[10:50] <StevenK> Ah.
[10:50] <\sh> josesanch: wrong
[10:50] <StevenK> So I should just depend on xfonts-base instead of xfonts-cjk? (Since I can't see the Provides)
[10:51] <\sh> josesanch: your package has a version..so if your tarball is named gnomecatalog-0.2.tar.gz you should have a gnomecatalog-0.2 directory created after unpacking
[10:51] <StevenK> \sh: He can just cp the tarball to be an orig
[10:51] <minghua> StevenK: I suppose so (as xfonts-base conflicts, replaces, and provides xfonts-cjk), but I wonder which package is this?
[10:52] <\sh> StevenK: well...let's make it clean :)
[10:52] <StevenK> root@broken:/# apt-cache show xfonts-base | grep '(Prov|Conf|Repl)'
[10:52] <StevenK> root@broken:/#
[10:52] <minghua> I mean on debian
[10:53] <\sh> josesanch: now you insert your debian/ dir in the created directory, edit changelog e.g. like this: gnomecatalog (0.2-0ubuntu1) dapper; urgency=low
[10:53] <\sh> josesanch: you can do this with the "dch" util
[10:53] <StevenK> minghua: Ah. Now I see.
[10:56] <josesanch> ok
[10:56] <josesanch> \sh: ready
[10:57] <josesanch> and now?
[10:57] <\sh> josesanch: make a ln -s gnomecatalog-0.2.tar.gz to gnomecatalog_0.2.orig.tar.fz
[10:57] <\sh> josesanch: make a ln -s gnomecatalog-0.2.tar.gz to gnomecatalog_0.2.orig.tar.gz
[10:57] <\sh> cd into gnomecatalog-0.2
[10:57] <\sh> debuild -S -sa
[10:57] <\sh> it should not change the orig.tar.gz or repackage it somehow
[10:58] <StevenK> \sh: Bah! cp!
[10:58] <\sh> josesanch: did you read the debian new maintainers guide?
[10:58] <minghua> StevenK: why ln -s is not good?
[10:58] <josesanch> not complete.
[10:58] <\sh> StevenK: Buh! mv! :)
[10:58] <StevenK> I prefer cp or mv
[10:59] <\sh> hehe..choice is what we want :) choice is what we get :)
[11:13] <josesanch> \sh: I going to read debian new mantainer guide. I'll be back later.
[11:14] <josesanch> bye.. thanks a lot
[11:14] <siretart> morning
[11:14] <siretart> wow. lots of discussion about debian<->ubuntu taking on the last days.. I love it! :)
[11:14] <Burgundavia> siretart, indeed
[11:16] <Gloubiboulga> \sh, do you have time to look at libtranslate ? http://revu.tauware.de/details.py?upid=1473
[11:23] <\sh> Gloubiboulga: just looking
[11:23] <Gloubiboulga> \sh, thanks :)
[11:26] <\sh> Gloubiboulga: why is the tarball different from upstream?
[11:27] <Gloubiboulga> good question...
[11:28] <\sh> -rw-r--r--  1 shermann shermann 542705 2006-01-12 08:16 libtranslate_0.99.orig.tar.gz
[11:28] <\sh> -rw-r--r--  1 shermann shermann 532516 2005-01-28 15:55 libtranslate-0.99.tar.gz
[11:28] <\sh> and the md5sums are different :)
[11:28] <Gloubiboulga> \sh, I had trouble with config.{sub,guess}
[11:28] <Gloubiboulga> maybe I didn't do things the right way
[11:29] <\sh> Gloubiboulga: copy config.{sub,guess} from /usr/share/misc (build-dep on autotools-dev) in the configure target
[11:29] <\sh> and remove them in clean target
[11:29] <Gloubiboulga> ok
[11:29] <\sh> Gloubiboulga: you can use the skeleton provided by dh_make but move it away from clean :)
[11:29] <minghua> yay, new libqt3-mt is in archive now, let me test before going to sleep
[11:30] <Gloubiboulga> \sh, ok, i can do that :)
[11:30] <\sh> minghua: cool :)
[11:31] <Gloubiboulga> \sh, iirc upstream tarball provides this 2 files
[11:31] <Gloubiboulga> remove them will produce a big diff.gz, is this ok ?
[11:31] <\sh> Gloubiboulga: yes can be, but it won't change the upstream tarball :)
[11:31] <Gloubiboulga> ok :)
[11:32] <\sh> Gloubiboulga: if it's provided, leave them untouched
[11:32] <\sh> Gloubiboulga: or copy the ones from the buildsystem in configure target
[11:38] <Gloubiboulga> \sh, is it the only problem with the package?
[11:38] <\sh> yes
[11:38] <Gloubiboulga> ok
[11:54] <\sh> minghua: any result?
[11:54] <Gloubiboulga> \sh, the new package is on review: http://revu.tauware.de/details.py?upid=1493
[11:54] <Gloubiboulga> the debdiff is empty... but the orig.tar.gz is correct :)
[11:55] <minghua> \sh: just finished upgrading, now my aptitude in gnome-terminal freezes :-(
[11:55] <minghua> trying to figure out a non-violent way to exit
[11:55] <\sh> kill -9 ?
[11:58] <minghua> ok, killed
[12:02] <minghua> \sh: okay, I have XIM mode working
[12:02] <minghua> \sh: although scim doesn't work well in XIM mode
[12:02] <minghua> \sh: but that's a different issue and it's not specific to KDE (I've seen it in GNOME too)
[12:03] <minghua> \sh: so your fix to libqt3 works
[12:04] <\sh> minghua: thx :)
[12:04] <minghua> \sh: I'll follow the malone bug, then go to sleep
[12:04] <minghua> \sh: thanks for the quick fix
[12:04] <\sh> minghua: thanks for testing it :)
[12:06] <Gloubiboulga> \sh, thanks again :)
[12:12] <minghua> Qt's IM module is really chatty, no wonder \sh prepared a patch to silent it :-)
[12:12] <\sh> minghua: it wasn't me, it was redhat :) i just stole it from them :)
[12:13] <minghua> \sh: ah.  then you are really good at stealing patches :-P
[12:13] <\sh> minghua: sometimes :)
[12:14] <\sh> minghua: actually I know how to read the different source package systems :)
[12:14] <\sh> .oO(and I'm not "lazy" to do so :))
[12:22] <\sh> oh I wrote your name wrong...missed on character :*(
[12:22] <\sh> sorry
[12:26] <minghua> \sh: oh I didn't even notice that, no problem at all
[12:32] <minghua> see you all
[01:46] <StevenK> grep -E '(Prov|Conf|Repl)'
[01:46] <StevenK> Oops.
[02:18] <Yagisan> ajmitch: ping
[02:28] <Yagisan> ajmitch: depending on what order you install the plone packages in on breezy, and if you run a certain command between them, plone + addons work out of the box in breezy
[02:32] <xerxas> Hi
[02:32] <xerxas> I'm trying to fix a bug
[02:32] <xerxas> to add some comments
[02:36] <xerxas> can someone help me ?
[02:36] <xerxas> the bug is sound-juicer doesn't re-read cd
[02:36] <xerxas> when cd is inserted
[02:36] <xerxas> is this a sound-juicer thing ?
[02:36] <xerxas> or gnome-volume-manager ?
[02:37] <crimsun> sound-juicer is a main package, no/
[02:42] <xerxas> sorry  ?
[02:42] <xerxas> is sound-juicer hal aware ?
[02:47] <crimsun> seems so
[04:06] <siretart> buxy: I just wanted to tell you that I found your message to d-d-a very appropriate. really!
[04:08] <\sh> siretart: link?
[04:10] <siretart> \sh: http://lists.debian.org/debian-devel-announce/2006/01/msg00008.html
[04:12] <\sh> is nice
[04:15] <\sh> phew..I think I only have two or three packages left for cleaning up the libXft.la mess in kdes .la files
[04:25] <Kyral> Morning
[04:25] <\sh> hey kyral
[05:02] <Kyral> `/away Breakfast!
[05:02] <Kyral> ..oops
[05:04] <siretart> Kyral: morning :)
[05:05] <\sh> siretart: who can I generate a list of packages, which I don't have installed, but to find out what the contents of a special, let's say .la file is
[05:06] <siretart> \sh: apt-file?
[05:06] <\sh> no
[05:06] <\sh> i can see only via apt-file which package has a .la file
[05:06] <\sh> but I need to check as well the contents of this .la file :)
[05:06] <siretart> ah, you need the contents of the .la file, no?
[05:06] <siretart> ok
[05:06] <\sh> siretart: correct :)
[05:07] <siretart> \sh: I think you would have to make first a list of packages containing the files and their position, and then download all of those packages to extract and grep the affected files
[05:08] <\sh> siretart: ok...need to think about something like this...
[05:23] <buxy> siretart: but I started yet another flame war apparently and assufield should be killed really (if you was his mail as well)
[05:24] <crimsun> the lesbians one?
[05:24] <buxy> yeah
[05:24] <crimsun> I was wondering where that originated
[05:24] <\sh> well...as I said, it isn't worth fighting windmills.
[05:25] <\sh> and those people are chasing away the people who wants to help in some areas...
[05:26] <crimsun> eh, I wouldn't really worry about him. He has always been brusque, so I generally ignore his pendantry if it's not code-related.
[05:29] <siretart> buxy: thats sad. :(
[05:30] <buxy> crimsun: yeah that's the only way to handle assufield
[05:31] <buxy> siretart: yeah but it's difficult to avoid when you have the size that Debian has
[05:32] <siretart> buxy: I'm following debian-devel a really long time now. This was one of the reason why I only recently applied for NM
[05:33] <siretart> buxy: btw, what I wanted to ask you: what is the correct maintainer field for ext-maintained packages in the collab-maint svn?
[05:33] <siretart> buxy: and how do you intend to coordinate the sponsoring itself?
[05:39] <buxy> siretart: if the Debian packages already exists, there's a name in the maintainer field, why can't you keep it ? :)
[05:40] <siretart> buxy: I'm talking currently about wifi-radar
[05:40] <buxy> siretart: for the coordination part of the uploads, that was the role of the web interface vaguely specified in the wiki page
[05:40] <buxy> but obviously this page doesn't exist yet
[05:41] <siretart> buxy: the package does not exist in debian yet (as well as min12xxw from sistpoty), but I think it is a worthwile addition to debian
[05:41] <siretart> buxy: I see. So I (we) have to search for sponsors ourselves for now, right?
[05:42] <buxy> mostly yes, but I can start the sponsoring process and I should really ask utnubu people to help in this area
[05:43] <siretart> ok
[05:43] <buxy> siretart: who is Ante Karamatic ? he's he interested in maintaining the package or what that a one shot work ?
[05:43] <\sh> buxy: Ante aka ivoks :)
[05:43] <siretart> buxy: thats ivoks. He made wifi-radar for ubuntu initially. he used to be quite active in this channel, but I havn't seen him for quite a long time
[05:44] <\sh> siretart: he is busy with his real life work I think
[05:44] <buxy> siretart: should I create a mailing list in the collab-maint project coordinating the work ?
[05:44] <siretart> buxy: I think that would be the right place for questions like I just made
[05:45] <siretart> buxy: so, yes, IMO a good idea
[05:45] <buxy> siretart: unless we use the utnubu list ... I'll ask opinions on the utnubu list.
[05:47] <siretart> ok
[06:05] <siretart> boah, boson-base takes fucking much time to get compiled
[06:05] <\sh> siretart: hehe....
[06:07] <\sh> StevenK: well...Gustavo wrote me a mail today...that he is going the MOTU way as well...
[06:08] <jsgotangco> planet jdub heh
[06:09] <\sh> hehehe this time it's not me :) so now you can believe me when I'm telling you all: Planet is broken, not my blog :)
[06:27] <sivang> jsgotangco: LOL
[06:27] <\sh> damn...I have to write the motu meeting minutes..well..tomorrow is time enough
[06:41] <Kyral> Anyone know what the "suite" is for setting up a breezy repo
[07:51] <Gloubiboulga> \sh, do you know how I can my email adress white-listed?
[07:51] <Gloubiboulga> pef has uploaded my package, but Katie doesn't want to email me
[07:52] <\sh> Gloubiboulga: write email a mail to upload@ubuntu.com or use the ubuntu.com mail address when you have one
[07:52] <Gloubiboulga> and elmo doesn't answer me...
[07:52] <\sh> oh my...my sentence
[07:52] <Gloubiboulga> \sh, ok
[07:52] <\sh> Gloubiboulga: write an email to upload@ubuntu.com or use the ubuntu.com mail address when you have one...or try to put your email address into your launchpad account
[07:54] <pef> \sh: can you try to run ida or motv (on Dapper, of course :)
[07:54] <\sh> what is it?
[07:55] <pef> \sh: programs not finding libXm.so.3 (openmotif), and openmotif FTBFS
[07:55] <pef> ida: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
[07:56] <\sh> tried to build it with lesstif?
[07:56] <pef> \sh: it's another implementation of motif, am I right ?
[07:56] <\sh> pef: yepp
[07:56] <\sh> why is openmotif ftbfsing?
[07:57] <pef> \sh: http://pastebin.com/505668
[07:58] <pef> but that's seems to be another problem, I can't find libXm.so in libmotif3.deb
[07:58] <\sh> hmmm..I would say there is a build dep missing
[07:59] <\sh> but I can be wrong without looking at the source code
[08:00] <pef> \sh: it's worse than missing bdeps :/ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194466
[08:00] <Ubugtu> Debian bug 194466: "uses Xlib private functions" Package: openmotif, Severity: important, Maintainer: Gerd Knorr
[08:00] <Kyral> Okay..I have a problem..
[08:01] <Kyral> I made this metapack for my labbuild...I have a load of depends in Depends...but when I go to apt-cache depends in a local repo...its showing no deps
[08:02] <pef> \sh: seems to be fixed in Debian http://packages.qa.debian.org/o/openmotif/news/2.html
[08:02] <pef> \sh: should we ask for a sync ?
[08:02] <pef> or just get the patch ?
[08:03] <\sh> pef: you can rebuild ida with lesstif2-dev :)
[08:03] <\sh> let me rebuild it on i386 and let me test it :
[08:03] <\sh> )
[08:03] <pef> \sh: there are no side effects, like something not implemented in lesstiff ?
[08:03] <\sh> pef: it compiled like a charm :)
[08:04] <\sh> but I didn't test it for running...give me 5 mins :)
[08:04] <pef> \sh: latest libmotif's version also correct a FTBFS on sparc
[08:04] <pef> mm
[08:04] <\sh> well...check it :) and request a sync
[08:05] <\sh> I'm testing with lesstif2 meanwhile :)
[08:06] <pef> oops
[08:06] <pef> we already have latest version
[08:06] <pef> with the patch
[08:06] <pef> hum
[08:07] <\sh> moment...
[08:08] <\sh> well..it's running
[08:08] <\sh> but I can't see any text :)
[08:08] <\sh> but picture rotating is working :)
[08:09] <\sh> but what you can do is to rewrite the broken source code and use public functions and not private ones
[08:36] <Kyral> what call is responsible for generating the Control file for the binary deb?
[08:39] <crimsun> Kyral: dh_gencontrol
[08:39] <Kyral> thanks
[08:40] <Kyral> I'm wondering why the heck this Meta isn't passing its Depends to the Binary
[08:40] <Kyral> I made a typo... a . instead of a ,
[09:40] <josesanch> \sh: Are you there?
[09:48] <tommy_> good evening, all
[09:49] <tommy_> or hi for some far away
[09:51] <stratus> hi, i maintain a package in debian that is outdated in ubuntu; i can prepare the package for merge...
[09:51] <stratus> it's just strange that it wasn't merged automagically
[09:52] <crimsun> stratus: which?
[09:53] <stratus> crimsun: gnome-sudoku
[09:54] <crimsun> stratus: it has synced.
[09:54] <crimsun> it ftbfs
[09:55] <stratus> weird
[09:55] <stratus> url?
[09:55] <crimsun> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-sudoku/0.4.0-1/gnome-sudoku_0.4.0-1_20060104-1738-i386-failed.gz  for example
[09:56] <crimsun> it's a pretty simple failure
[09:56] <stratus> *sigh*
[09:56] <stratus> python2.4-dev(inst 2.4.2-1ubuntu1 ! >= wanted 2.4.2-2)
[09:56] <crimsun> yep, I can merge it easily
[09:57] <stratus> it's up to you, i can downgrade it on Debian package and wait MoM
[09:57] <crimsun> granted I don't know if doko_ is going to merge python2.4 2.4.2-2
[09:58] <stratus> oh, i prefer change it in Debian so you won't need a ubuntu revision, ok?
[09:58] <crimsun> stratus: whatever works best for you as the maintainer
[09:59] <stratus> crimsun: good, i'll take care of that thanks
[09:59] <stratus> let me ask some more things...
[09:59] <stratus> i see some merge related bugs in malone, what's up there? e.g: 4393
[09:59] <stratus> err 4394
[10:00] <crimsun> stratus: that's part of our merge management
[10:01] <crimsun> stratus: up until upstream version freeze (UVF, which is on Jan 19th), MoM runs, and we file bugs to track who's doing what
[10:01] <stratus> MoM see a failure and open a bug to Motu for manual merge?
[10:01] <crimsun> stratus: no, we open/close them manually
[10:01] <stratus> oh, ok
[10:02] <stratus> i'm really interested in universe QA, so i'm asking
[10:02] <crimsun> for #4394 in particular, we can drop Ubuntu changes, so we ask elmo for a sync
[10:03] <crimsun> (hence why I've left it in Confirmed state)
[10:03] <crimsun> (waiting for elmo to sync from Sid)
[10:03] <stratus> what's the procedure to ask elmo for a sync? sometimes i see people just writing a request at #ubuntu-devel
[10:04] <crimsun> stratus: generally MOTUs ask elmo for syncs, but of course if he knows who you are in Debian, then he'll sync them
[10:04] <crimsun> case in point being StevenK, who isn't a MOTU but is a DD
[10:05] <stratus> crimsun: np, but i think i'm a MOTU hopeful already :)
[10:06] <crimsun> we either e-mail him or just accumulate them in his away log :)
[10:06] <crimsun> stratus: great :)
[10:06] <stratus> crimsun: yes
[10:06] <stratus> rebuilding gnome-sudoku...
[10:09] <LaserJock> hmm, I wonder how hard (or if it would be even possible) to file ITPs and RFPs in Malone and then make a list like the merge list on tiber. It seems like UniverseCandidates is a little unwieldy
[10:09] <crimsun> I think that's part of the plan for Malone, yes
[10:10] <LaserJock> k
[10:11] <crimsun> you'll probably get a more concrete answer in #launchpad
[10:11] <LaserJock> oh, ok. I'll see what's going on over there
[10:40] <Gloubiboulga> evening LaserJock
[10:43] <LaserJock> hi Gloubiboulga
[10:43] <raphink> hi LaserJock
[10:43] <LaserJock> hi raphink
[10:43] <raphink> :)
[10:43] <raphink> just here for a short time
[10:43] <raphink> I'm not home but I'll try to have a dapper chroot running soon enough to help with the merges
[10:43] <raphink> :)
[10:43] <Gloubiboulga> salut raphink :)
[10:43] <raphink> salut Gloubiboulga
[10:44] <LaserJock> chroots are a wonderful thing
[10:44] <raphink> yes
[10:44] <LaserJock> I used to just have partitions for each distro
[10:44] <raphink> i'm gonna switch somes comps to ubuntu here
[10:45] <raphink> and then make myself a dapper chroot
[10:45] <raphink> if I can't do it, then I'll just use my own box with ssh ;)
[11:12] <Mithrandir> attroja: please turn off public away
[11:27] <LaserJock> hi Hobbsee
[11:28] <Hobbsee> morning LaserJock
[11:41] <lfittl> Everybody who has time: Please comment on my layout change for http://wiki.ubuntu.com/UniverseCandidates
[11:43] <LaserJock> lfittl: I like it, but at the top MOTUNewPackage doesn't exist
[11:43] <lfittl> LaserJock: I did not change that
[11:44] <LaserJock> lfittl: I know, but could you?
[11:44] <lfittl> sure, what should be written on the top? :)
[11:45] <LaserJock> I don't know
[11:45] <Hobbsee> lfittl: looks much more readable
[11:45] <LaserJock> I'm not sure quite what was intended
[11:45] <lfittl> LaserJock: I will try to find out who changed that
[11:46] <LaserJock> lfittl: it could be HowtoCreateNewPackages or MOTUNewPackagesPolicy
[11:48] <lfittl> LaserJock: that change has been done by lucas, I could simple revert it
[11:48] <LaserJock> lfittl: oh, he might of had a plan for that, just a sec
[11:49] <LaserJock> I think perhaps MOTUNewSoftware is what should be there
[11:51] <lfittl> I will change it to MOTUNewSoftware and ask lucas what he intended to do