Bug#458375: Sponsorship for xdotool
Hi Decklin-- On Tue 2008-05-20 23:09:02 -0400, Daniel Kahn Gillmor wrote: OK, after a bunch of fumbling around, i seem to have gotten the repo i'm using in shape to where i can use svn-buildpackage to create the .deb. Could you update to it and see if it works for you? So i talked with Jordan a bit, and he made several more changes to xdotool which look really nice. The compilation warning messages are cleaned up upstream now, there are better failure checks within xdotool itself, a stronger testsuite, and Jordan adopted the man page, which is pretty great. I added perl as a build-dep for pod2man, since Jordan prefers to maintain the man page in pod format. And i made a couple minor adjustments to the upstream Makefile (to avoid installing into /usr/local), but otherwise the package is built from the raw upstream source. My packaging is available from the cmrg apt repo: deb http://cmrg.fifthhorseman.net/debian unstable xdotool deb-src http://cmrg.fifthhorseman.net/debian unstable xdotool And it should be cleanly buildable with svn-buildpackage if you have the upstream source already: svn co http://cmrg.fifthhorseman.net/svn/tags/xdotool/20080606-1 xdotool-20080606-1 cd xdotool-20080606-1 svn-buildpackage Please let me know if you have any suggestions or changes. Thanks for considering sponsorship for this package. --dkg pgp2Cyyfmlbbf.pgp Description: PGP signature
Bug#458375: Sponsorship
Hi Decklin-- On Tue 2008-05-20 00:16:51 -0400, Decklin Foster wrote: I'd like to sponsor this package. Daniel, Thanks! I'd be happy to have you sponsor it. have you looked at any of Jörg's suggestions? I addressed several of the issues with debian/rules, but my latest efforts at packaging it rely instead on the new debian/rules minimization that's possible with debhelper 7, which addresses many of the concerns (and more) in a standardized way. The main outstanding issue that i haven't dealt with is the set of warnings that come up when compiling with -Wall -- i'll work on that when i get a bit more free time, since i'd like to be able to offer a changeset upstream instead of just a nag. It's not lintian-clean at the moment, but that should be fixed once #477628 gets resolved for lintian. The latest version is 20071230-2, published in the usual place: deb http://cmrg.fifthhorseman.net/debian unstable xdotool deb-src http://cmrg.fifthhorseman.net/debian unstable xdotool I'm happy to address other concerns if you've got them. Just let me know. Regards, --dkg pgpky1bv15pb8.pgp Description: PGP signature
Bug#458375: Sponsorship
Daniel Kahn Gillmor writes: my latest efforts at packaging it rely instead on the new debian/rules minimization that's possible with debhelper 7, which addresses many of the concerns (and more) in a standardized way. Great; that's what I was going to suggest. (Gotta love that rules file...) The main outstanding issue that i haven't dealt with is the set of warnings that come up when compiling with -Wall -- i'll work on that when i get a bit more free time, since i'd like to be able to offer a changeset upstream instead of just a nag. How do you plan on managing patches, and the packaging in general? I could help with this particular issue, but it'd be more convenient if your SVN repo looked like a standard svn-buildpackage layout (with upstream on a branch). The latest version is 20071230-2, published in the usual place: Have you asked upstream if they plan to do a real version number? My personal preference is to do something ugly like 0~20071230 now rather than be stuck with 1:1.0 and so on later. (This is opinion, you can ignore it :)) -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458375: Sponsorship
On Tue 2008-05-20 14:28:18 -0400, Decklin Foster wrote: (Gotta love that rules file...) Amen! How do you plan on managing patches, and the packaging in general? I could help with this particular issue, but it'd be more convenient if your SVN repo looked like a standard svn-buildpackage layout (with upstream on a branch). I'll have to look into the svn-buildpackage layout: i'm not familiar with it, but it sounds like a fine idea. i was actually planning on just submitting my patches for cleaning up warnings upstream and *not* including them in the debian packages at the moment. i'm a little gun-shy about patching for the sake of quieting warnings without upstream's approval given the events of the last couple weeks ;) In the event that i find patches that actually do need to be applied, i'll probably use dpatch or quilt to manage them. I don't have much of a preference (well, other than avoiding patches to upstream entirely). FWIW, i'm down to only 4 errors (all different width due to prototype) using the warning flags Jörg suggested, so i'm relatively close to a cleanup patch i can send upstream. Have you asked upstream if they plan to do a real version number? My personal preference is to do something ugly like 0~20071230 now rather than be stuck with 1:1.0 and so on later. (This is opinion, you can ignore it :)) My impression from Jordan (which could be wrong) is that this *is* the real version number -- i don't think there's going to be a 1.0. So i think i'll ignore it for now. Adding an epoch number isn't the end of the world if the versioning scheme does change. Thanks for your feedback, --dkg pgpRkMciGYc11.pgp Description: PGP signature
Bug#458375: Sponsorship
On Tue 2008-05-20 15:32:38 -0400, Daniel Kahn Gillmor wrote: I'll have to look into the svn-buildpackage layout: i'm not familiar with it, but it sounds like a fine idea. OK, after a bunch of fumbling around, i seem to have gotten the repo i'm using in shape to where i can use svn-buildpackage to create the .deb. Could you update to it and see if it works for you? FWIW, i'm down to only 4 errors (all different width due to prototype) using the warning flags Jörg suggested, so i'm relatively close to a cleanup patch i can send upstream. I've also committed the changes that leave me with only 4 build warnings (these would go upstream, hopefully, but could also be released with a new debian revision if you think that's preferable). It's not clear to me if there's a nifty way to coax a package maintained with svn-buildpackage into using dpatch or quilt -- It always feels wrong to commit raw diffs to a revision control system (though i've done it before), and it seems like a tool like svn-buildpackage could manipulate its internal diffs to produce something reasonable somehow. Maybe that's asking too much, though. I'm open to suggestions and pointers, as usual. Regards, --dkg pgpIqpA0DpTfc.pgp Description: PGP signature
Bug#458375: Sponsorship
On Tue 2008-05-20 23:09:02 -0400, Daniel Kahn Gillmor wrote: On Tue 2008-05-20 15:32:38 -0400, Daniel Kahn Gillmor wrote: FWIW, i'm down to only 4 errors (all different width due to prototype) using the warning flags Jörg suggested, so i'm relatively close to a cleanup patch i can send upstream. I've also committed the changes that leave me with only 4 build warnings (these would go upstream, hopefully, but could also be released with a new debian revision if you think that's preferable). After banging my head against these last 4 errors for a while, i researched the warning i was seeing itself. The warnings were: gcc -g -O2 -Wformat=2 -Wunused -Wundef -Wextra -Wswitch-enum -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wbad-function-cast -Wnested-externs -Wall `pkg-config --cflags x11 xtst 2 /dev/null || echo -I/usr/X11R6/include -I/usr/local/include` -c xdo.c xdo.c: In function ‘xdo_type’: xdo.c:276: warning: passing argument 2 of ‘_xdo_keycode_from_char’ with different width due to prototype xdo.c:277: warning: passing argument 2 of ‘_xdo_get_shiftcode_if_needed’ with different width due to prototype xdo.c: In function ‘_xdo_populate_charcode_map’: xdo.c:394: warning: passing argument 2 of ‘XKeycodeToKeysym’ with different width due to prototype xdo.c: In function ‘_xdo_keysequence_to_keycode_list’: xdo.c:476: warning: passing argument 2 of ‘__strtok_r_1c’ with different width due to prototype After reading a recent post on cocoa-dev [0], i no longer think these warnings are relevant. In fact, i think that -Wconversion is basically a lot of false positives: the compilers in debian (and every other OS i've used in the last decade) can all handle function prototypes just fine, thanks. Without -Wconversion, my current svn HEAD builds with no errors, so i'm going to ship the cleanup diff upstream to see if Jordan's interested. --dkg [0] http://lists.apple.com/archives/cocoa-dev/2008/May/msg00923.html pgp35HqqTg2tk.pgp Description: PGP signature
Bug#458375: Sponsorship
I'd like to sponsor this package. Daniel, have you looked at any of Jörg's suggestions? -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
