Re: Suggestions on packaging a patched source tarball
On Sun, Sep 23, 2007 at 09:57:36AM +0200, Cesare Falco wrote: > > I'm facing an unusual situation. I'm already packaging sdlmame from > a .zip upstream file. Well, you didn't know? Please review it: > http://revu.tauware.de/details.py?upid=259 > :) > > Now I'm considering to package another Mame derivative, namely WolfMame, > which is distributed as a patch to the baseline code. I wonder what is > the correct way to handle this: > [snipped] > > *or* > 4. I'm waiting for your suggestions, they will be highly welcome ;) Another option, which is used by kernel packages and others, is to build an sdlmame-source binary package from sdlmame, containing the baseline source code of sdlmame. Then only package WolfMame's patch in its source package, and build-depend on sdlmame-source. Ming 2007.09.23 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
gDesklets broken in gutsy
Resending since my email didn't get thru last time = Hi there, I'm one of the maintainer of gdesklets. I just wanted to inform you, that you're shipping a broken version of gdesklets in gutsy. There are also some problems in feisty (amd64 systems). We've already received lots of bug reports. It'd be nice if you could build packages from bzr. gdesklets bzr is very stable and has lots of new features. There'll be a beta in a few days. A final should be out by the time gutsy will be released. To avoid lots of work when it comes to closing bugs due to duplicates I'd be happy if you'll have a look at http://launchpad.net/gdesklets Don't hesitate to ask if you have questions. Regards, Christian -- Christian Meyer GNOME:http://www.gnome.org gDesklets: http://www.gdesklets.org AIM: chrisime ICQ: 72107443 Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: chrisime77 Yahoo: [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Suggestions on packaging a patched source tarball
Hi Cesare, Am Sonntag 23 September 2007 09:57:36 schrieb Cesare Falco: > Hi there, > > I'm facing an unusual situation. I'm already packaging sdlmame from > a .zip upstream file. Well, you didn't know? Please review it: > http://revu.tauware.de/details.py?upid=259 > > :) > > Now I'm considering to package another Mame derivative, namely WolfMame, > which is distributed as a patch to the baseline code. I wonder what is > the correct way to handle this: First off all, a nonnative debian package consists of a .orig.tar.gz, which should contain the upstream sources and of a .diff.gz, which contains the debian/ubuntu modification. The gist of this distinction is to separate cleanly stuff from upstream and the maintainers modifications. > > 1. I should download the sdlmamexxx.zip upstream tarball, uncompress and > patch it with the wolfmamexxx.zip set of patches and finally build a > wolfmame_xxx.orig.tar.gz So this seams to be the right approach, since it will separate upstreams work and debian/ubuntu stuff via .orig.tar.gz and .diff.gz. However to also make it transparent how you built your orig-tarball, you should create the orig-tarball via a script and add it to the debian directory for reference. > > *or* > > 2. use sdlmamexxx.zip upstream tarball to build a > wolfmame_xxx.orig.tar.gz and then patch it during the package build > process (ugly IMHO) This would leave the upstream source being part of the .diff.gz so that's not a good idea. > > *or* > > 3. add a patching system to my existing maintainer scripts in the > sdlmame package and build another binary right from it Likewise, no clear distinction between maintainer patches and upstream work here. > > *or* > 4. I'm waiting for your suggestions, they will be highly welcome ;) Build a tarball containing the sdlmame zip file and the wolfmame zip file (or both converted to tarballs) as an .orig.tar.gz and have the build system mangle both together (the tarball thingy of cdbs might be useful here), though I've never liked packages in this style much, but that's a personal preference. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Ubuntu MOTU Meeting Minutes, for September 21st, 2007, 12:000 UTC.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey folks. Please find below, a copy of the minutes from our MOTU meeting, held this past Friday, September 21st, at 12:00 UTC. You can also find the minutes at the following URL: https://wiki.ubuntu.com/MOTU/Meetings/2007-09-21. If you have any questions, please feel free to contact me. MOTU Meeting Minutes for Friday, September 21st, 2007, 12:00UTC. == Sponsorship process and PPAs == Scott Kitterman (ScottK) wanted the sponsorship process, particularly the alternative process of using a PPA for sponsored uploads clarrified. He felt it was necessary, at least for him, to have a debdiff attached to a sponsorship bug for reviewing of a package, and felt it was more time consuming to have to grab a .dsc file, download the package, and manually create a debdiff. It was decided tht atht ppaput tool, which is part of ubuntu-dev-tools, should have an option to generate a debdiff, and while users could use their ppa, debdiff should still be requested. Daniel Holbach (dholbach) stated that he would work on adding the needed functionality to ppaput. == The TODO == Dholbach pointed out that https://wiki.ubuntu.com/MOTU/TODO has now got additional content to draw attention to bugs needing attention for new contributers. The lists are easy to update, but they require people to tag bugs as packaging or bytesize, if the person reviewing the bug doesn't have time to fix it themselves. Everybody is requested to help with this effort. == Wiki reorganisation == Dholbach has started working on cleaning up the wiki, once and for all, as seen on the MOTU Mailing List. He intends to make lists of pages that need work, through taggint them. They will be then up for comment. Once again, he requests others to help getting the pages sorted, particularly the documentation, which has een known to be confusing or out of date on many occasions. == Next meeting == It was decided that two weeks from this meeting is appropriate, but a time wasn't agree upon. Luke Yelavich (TheMuso) offered to post to the MOTU Mailing List, requesting suggestions on what time the meeting should be held. == Universe Hug Day == Since these tend to not occur, or only a few peope participate, it was decided to role the Universe hug days into the general hug days, that are announced on most mailing lists, and occur regularly. The option is still open in the future for universe hug days to be a separate event. == MOTU Q&A Sessions == dholbach intennds to run a Q&A session on Friday, September 28th, at 12:00UTC, in #ubuntu-motu. All who can help out, or who have questions, are free to come along and participate. - -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG9imBjVefwtBjIM4RAjr9AJ476we5GrNOJXDK+Z36yJT6NNG8UACeNXr9 Si4a0cQRbCxzg4svnfc4G+c= =aps3 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Suggestions on packaging a patched source tarball
Hi there, I'm facing an unusual situation. I'm already packaging sdlmame from a .zip upstream file. Well, you didn't know? Please review it: http://revu.tauware.de/details.py?upid=259 :) Now I'm considering to package another Mame derivative, namely WolfMame, which is distributed as a patch to the baseline code. I wonder what is the correct way to handle this: 1. I should download the sdlmamexxx.zip upstream tarball, uncompress and patch it with the wolfmamexxx.zip set of patches and finally build a wolfmame_xxx.orig.tar.gz *or* 2. use sdlmamexxx.zip upstream tarball to build a wolfmame_xxx.orig.tar.gz and then patch it during the package build process (ugly IMHO) *or* 3. add a patching system to my existing maintainer scripts in the sdlmame package and build another binary right from it *or* 4. I'm waiting for your suggestions, they will be highly welcome ;) Thanks in advance! Cesare. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
