[02:35] <fabbione> papppappapapapa
[02:36] <fabbione> ok everything works
[02:38] <fabbione> Kamion: they just finished
[02:39] <Kamion> yeah
[02:40] <rodarvus> our libxt package has patches applied directly on the source code
[02:40] <rodarvus> (for man page location)
[02:41] <rodarvus> changing things like:
[02:41] <rodarvus> +XtOwnSelection(3Xt)
[02:41] <rodarvus> -XtOwnSelection(__libmansuffix__)
[02:42] <Kamion> (it's pretty common practice to apply patches that way, no matter what some folks will tell you)
[02:42] <rodarvus> (actually, s/3Xt/__libmansuffix__/)
[02:42] <Kamion> although if it's gained quilt or whatever in Debian then the patches should be moved to that
[02:42] <rodarvus> Kamion, but that will get lost on the next upstream release
[02:43] <Mithrandir> no, it won't
[02:43] <fabbione> rodarvus: no the patches are stored in the diff.gz
[02:43] <fabbione> rodarvus: these man pages patches can be left alone for now
[02:43] <fabbione> rodarvus: they are cosmetic and only to avoid one warning on some retarded kubuntu X man app
[02:44] <Mithrandir> fabbione: I'm dropping your man page section fixes for now, we should just get them fixed in Debian.
[02:44] <rodarvus> ok
[02:44] <fabbione> we will do it properly later on...
[02:44] <fabbione> Mithrandir: exactly
[02:44] <fabbione> rodarvus: all that stuff was done one day in a hurry with sed
[02:44] <fabbione> rodarvus: i am not even sure all of it is done as it should be
[02:44] <Kamion> rodarvus: sounds like you've been attacked by the everything-must-have-a-patch-system freaks ;)
[02:45] <rodarvus> Kamion, haha :)
[02:45] <Mithrandir> they're quite common, but they're wrong.  Most packages don't need a patch system.
[02:45] <fabbione> Kamion: the disease affects all developers in the early stage of their life. It can be cured submitting a moderate amount of clubat larting.
[02:45] <fabbione> (from the X maintainer god medical guide)
[02:47] <rodarvus> indeed a patch system is not necessary when applying only small patches such as this one - but is quite helpful when you have more patches, and new upstream versions
[02:48] <Mithrandir> rodarvus: new upstream versions is really irrelevant, and a patch system is a workaround for a real fix which is using an RCS.
[02:51] <rodarvus> agreed - best solution is really a RCS
[02:51] <rodarvus> are we just dropping fabbione's man page section fixes from all packages, then?
[02:51] <rodarvus> (just need a nod to do the same here)
[02:52] <Mithrandir> rodarvus: yes
[02:52] <fabbione> YES JUST DO IT
[02:52] <fabbione> ps
[02:52] <fabbione> sorry for the caps
[03:02] <rodarvus> fabbione, daniels dropped a CFLAGS hack to fix the search path, but Debian still uses it -> "CFLAGS +=  -DXFILESEARCHPATHDEFAULT=\\\"/usr/lib/X11/%L/%T/%N%S:/usr/lib/X11/%l/%T/%N%S:/usr/lib/X11/%T/%N%S:/etc/X11/%L/%T/%N%S:/etc/X11/%l/%T/%N%S:/etc/X11/%T/%N%S\\\" -include X11/XlibConf.h -D_REENTRANT"
[03:02] <rodarvus> sincerely, I don't know X build internals enough to judge if this is necessary
[03:02] <fabbione> rodarvus: in what package is that?
[03:02] <rodarvus> libxt
[03:05] <fabbione>   * Comment out awful CFLAGS hack to fix the search path, and add
[03:05] <fabbione>     --with-appdefaultdir=/etc/X11/app-defaults.
[03:05] <fabbione> the merge would be still in debian/rules
[03:05] <fabbione> so i suggest you drop the hack and add that
[03:05] <rodarvus> fabbione, thing is, debian added that too (later), but didn't dropped the hack
[03:06] <rodarvus> (but it might be only that they just didn't knew if it was still necessary)
[03:07] <fabbione>   * Include customization expansion in the default XFILESEARCHPATH. Thanks to
[03:07] <fabbione>     several people for the report, and to Brendan O'Dea and Ian Wienand for
[03:07] <fabbione>     the diagnosis and fix respectively. (closes: #365612)
[03:08] <fabbione> did you read the bug?
[03:08] <rodarvus> nope, doing that now
[03:09] <fabbione> ok we do have bugs reporting the same issue in dapper
[03:09] <fabbione> so daniels might have done something crappy there
[03:09] <fabbione> i suggest to use what Debian is doing for edgy
[03:09] <rodarvus> *nods*
[03:09] <fabbione> then take dapper install and check got these bugs
[03:10] <fabbione> change libxt to match this new setup and see if it fixes the issue
[03:10] <fabbione> if it does we will consider backporting it to dapper
[03:10] <rodarvus> I will
[03:10] <rodarvus> thanks!
[03:10] <Mithrandir> has the publisher been fixed?
[03:11] <Kamion> Mithrandir: they know the problem now but there's still a bit of faffery to do - it looks like drescher may have been going mad last night in which case we have to be very very careful
[03:11] <Mithrandir> uh, ok.
[03:12] <Kamion> cp -a of dists was taking an hour - now it looks like it put some files in the wrong place too
[03:12] <fabbione> W T F
[03:17] <ogra> Hobbsee, http://people.ubuntu.com/~fabbione/x-pkgs has also some nice trivial apps to merge ... xeyes xclock etc :)
[03:17] <Kamion> not yet
[03:18] <Kamion> leave the apps until the libs are done
[03:18] <ogra> yep
[03:18] <Hobbsee> okay
[03:18] <Mithrandir> also, most of them will just be in one source package in Debian.
[03:21] <fabbione> Kamion: but why do they cp -a the dist in the first place?
[03:23] <Mithrandir> it appears we can't really merge anything usefully until libx11 is done.
[03:23] <Kamion> so that soyuz can publish to dists.new without the mirrors accidentally mirroring it in the middle of publication
[03:23] <fabbione> Mithrandir: x11 is done.. it's just being choaked by soyuz atm
[03:23] <Mithrandir> fabbione: so it's not done.  It's blocked on soyuz.
[03:24] <Mithrandir> Kamion: and cp -al wouldn't work then?
[03:24] <Kamion> *shrug*
[03:24] <fabbione> Mithrandir: well i did my part.. ain't our fault if soyuz did blow up
[03:24] <Mithrandir> at least -l for pool/ should make it quick enough..
[03:24] <Kamion> then you'd have to audit soyuz to ensure it broke hardlinks when it should
[03:24] <Kamion> anyway, that isn't important here
[03:25] <Kamion> it should never have been taking an hour anyway - that was only because the machine was sick
[03:26] <fabbione> rodarvus: can you please update the x-pkgs file with what you are doing?
[03:26] <fabbione> rodarvus: it's a 666 file so you can just edit it yourself
[03:26] <fabbione> otherwise we will end up with a duplicate mess
[03:26] <rodarvus> sure, I'll do that
[03:27] <rodarvus> I'm finishing libxt (in 5 minutes most), btw
[03:28] <rodarvus> fabbione, should I mark packages as "done" even if they are not uploaded yet?
[03:28] <fabbione> rodarvus: no, done is when the package is in the archive
[03:28] <fabbione> otherwise it stays with your name between ()
[03:28] <rodarvus> ok
[03:29] <rodarvus> libxt is ready to be uploaded
[03:29] <rodarvus> LOCK on libxmu
[03:30] <rodarvus> (x-pkgs updated)
[03:30] <fabbione> ehhe
[04:56] <rodarvus> I've just finished libxmu_1.0.1-3ubuntu1
[04:57] <rodarvus> I got a question: this package is version 1.0.1, but we had 1.0.0, before
[04:57] <Kamion> do we need to carry patches forward?
[04:58] <rodarvus> Kamion, only two small changes
[04:58] <rodarvus> (extra requirements to libxmu-dev and libxmuu-dev)
[04:58] <rodarvus> if these can be dropped
[04:58] <rodarvus> we can safely merge from debian
[04:58] <rodarvus> (extra libx11-dev requirements to libxmu-dev and libxmuu-dev)
[05:01] <Kamion> what's the diff?
[05:03] <rodarvus> Kamion, I pasted it on a query window
[05:05] <Kamion> I don't really see a need to carry that diff since libxmu-headers depends on libx11-dev
[05:05] <Kamion> what was your question regarding the new upstream version?
[05:08] <rodarvus> Kamion, its irrelevant now, but I was wondering if it was ok to force the .changes file to carry orig.tar.gz (via -sa build option), or if this would be blocked during upload checs
[05:08] <rodarvus> checks even
[05:08] <Kamion> it's both OK and required
[05:09] <rodarvus> good, thanks :)
[05:09] <Kamion> just make sure the .orig.tar.gz is the same as Debian's when you do so
[05:09] <rodarvus> *nods*
[05:11] <rodarvus> (after talking with Kamion in a /query window) we found out our changes to debian/control are not a strong enough reason to manually merge instead of syncing
[05:11] <rodarvus> so, I'll just ask ubuntu-archive to sync libxmu from debian unstable
[05:11] <rodarvus> anyone feel free to /query me if you have any questions
[05:12] <rodarvus> Kamion, thanks again
[05:19] <rodarvus> libxmu sync requested (bug 52109)
[05:20] <rodarvus> lunch time
[05:21] <rodarvus> i'll be back in 45minutes
[05:46] <Kamion> libfs uploaded
[05:52] <Kamion> rodarvus: in future please wait to request a sync until all the build-dependencies are available
[05:53] <rodarvus> oh, sure
[05:53] <rodarvus> should I note this in the bug?
[05:54] <Kamion> please
[05:56] <Kamion> fabbione: please subscribe ubuntu-archive rather than assigning - it doesn't show up in the list we normally use if you just assign
[05:56] <fabbione> Kamion: whops.. sorry :(
[05:58] <rodarvus> Kamion, done, thanks
[08:15] <rodarvus> x11proto-evie uploaded
[08:35] <rodarvus> LOCK on libdmx
[08:39] <crimsun> libice uploaded
[08:58] <crimsun> LOCK libxkbfile
[09:12] <crimsun> libxkbfile ready to go
[09:27] <rodarvus> libdmx is ready to be uploaded
[09:34] <rodarvus> just for reference: libxdamage & libdmx could be synced from Debian, but as on both cases their orig.tar.gz is different from ours, we'll have to manually merge
[09:34] <rodarvus> btw
[09:34] <rodarvus> LOCK libxdamage
[09:35] <rodarvus> and also libxcomposite
[09:35] <rodarvus> LOCK libxcomposite
[09:36] <rodarvus> x-pkgs is updated
[09:43] <rodarvus> libxdamage is ready to be uploaded
[12:01] <crimsun> LOCK libxrender