debian bug #217571 : mediawiki package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I am a developper for MediaWiki ( http://www.mediawiki.org/ ) the php wiki engine used by the free online encyclopedia Wikipedia. I noticed the package wnpp got a bug against mediawiki ( #217571 ) and that packaging is ongoing for more than 400 days. So this morning I created a package using the lastest beta (1.4beta3). I took the 'gallery' package as an example and by reading the documentation I managed to get a working package. It got tested by other ~ people under apache and apache2. I am now looking for a debian developer to review the package and give me feedback on the installation process. If any developer have some experience with a website package such as gallery / cacti please contact me :o) The first release is actually hosted on my personal computer: ~ http://dyn.twenkill.net/mediawiki_1.4beta3-1_i386.deb Last thing, the software is licensed under GPL version 2. cheers, - -- Ashar Voultoiz co-dev for http://www.mediawiki.org/ pgp keyid: 0x63B820D1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBxCDypmyHQ2O4INERAtwgAKDuwB223H/lAHVnza0ckYTFZ22AzACfSgAd ziFW5zd7D6fNT/5wfrGRaOo= =IxiH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian bug #217571 : mediawiki package
* Ashar Voultoiz [Sat, 18 Dec 2004 13:22:10 +0100]: > Hello, > I am a developper for MediaWiki ( http://www.mediawiki.org/ ) the php > wiki engine used by the free online encyclopedia Wikipedia. > I noticed the package wnpp got a bug against mediawiki ( #217571 ) and > that packaging is ongoing for more than 400 days. So this morning I > created a package using the lastest beta (1.4beta3). hi Ashar, I'm afraid you overlooked the fact that #217571 was merged with #276057. the '400 days' figure is a little misleading, since 400 days passed since the package was *requested*. if you have a look at #276057, you'll see that is much more recent (October 11th). I'm CC'ing #276057 and Evan Prodromou (who filed the ITP), so that he becomes aware of this message and perhaps you can coordinate efforts (or he may even interested in sponsoring if we didn't have time to start packaging). > I took the 'gallery' package as an example and by reading the > documentation I managed to get a working package. It got tested by other > ~ people under apache and apache2. > I am now looking for a debian developer to review the package and give > me feedback on the installation process. If any developer have some > experience with a website package such as gallery / cacti please contact > me :o) > The first release is actually hosted on my personal computer: > ~ http://dyn.twenkill.net/mediawiki_1.4beta3-1_i386.deb > Last thing, the software is licensed under GPL version 2. > cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: María del Monte - Algo de mí Arguing with an engineer is like wrestling with a pig in mud: after a while, you realize the pig is enjoying it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: cpufrequtils -- Shared library and utilities to deal with the CPUFreq Linux kernel feature
Hello, I'm looking for a sponsor[1] for the package cpufrequtils[2], source packages are available here: deb-src http://oioio.altervista.org/debian source/ and i386 binaries here: deb http://oioio.altervista.org/debian binary/ Both are built in a sid environment and lintian clean. thanks a lot to anybody wishing to sponsor this package (cpufreqd will also depend on libcpufreq0 soon). [1]: I've been in the NM queue for so long that I'll hopefully need a sponsor for a short time only :) [2]: some info stolen (and corrected) from my previous ITP: * Package name: cpufrequtils Version : 0.1 Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]> * URL : http://kernel.org/pub/linux/utils/kernel/cpufreq/ * License : GPL v2 Description : Shared library and utilities to deal with the cpufreq linux kernel feature This package will generate 3 packages: * Package name: cpufrequtils This package contains two utilities for inspecting and setting the cpu frequency through both the sysfs and procfs CPUFreq kernel interfaces. * Package name: libcpufreq0 This library provide an unified method to access the CPUFreq kernel interface. * Package name: libcpufreq-dev This package provides everything that is needed for developing own programs using libcpufreq. -- mattia :wq! signature.asc Description: Digital signature
sorting through xlibs-dev dependencies?
Hi, I hope this isn't a too dumb question! I'm the maintainer for xwrits, and partway through the NM process. My application manager (Frank Lichtenheld) has sent me a review of my packages, and I am confused about one of the things he suggested I do. xwrits currently depends on xlibs-dev. Frank suggests that I replace that with only the needed dependencies. What I am confused about is how to tell what it really needs and what it doesn't really need. I don't know that much about X, in general. xlibs-dev seems to be a package that does nothing but depend on a collection of many different X libraries. But I don't know what all those libraries do (and no, I don't want to read the code for all of them!). So, the only thing I thought to do is a) look at every header file that is #included in the xwrits code b) use dlocate or similar to see which packages all those headers are in. c) make xwrits build-depend on those packages. But this will take me quite a long time. I wondered if I am missing something obvious and there is a better way to do it. Or am I on the right track after all. Now, obviously, I don't want someone to actually tell me which things I should be build-depending on. I want to know how to work out such things for myself in the future :) (It would also defy the point of my AM asking me this.) But I would appreciate a hint... Thanks, Helen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sorting through xlibs-dev dependencies?
On Sat, Dec 18, 2004 at 10:39:37PM +, Helen Faulkner wrote: > Hi, Hello. > I hope this isn't a too dumb question! ;) > I'm the maintainer for xwrits, and partway through the NM process. My > application manager (Frank Lichtenheld) has sent me a review of my > packages, and I am confused about one of the things he suggested I do. > > xwrits currently depends on xlibs-dev. Frank suggests that I replace that > with only the needed dependencies. > > What I am confused about is how to tell what it really needs and what it > doesn't really need. I don't know that much about X, in general. > xlibs-dev seems to be a package that does nothing but depend on a > collection of many different X libraries. But I don't know what all those > libraries do (and no, I don't want to read the code for all of them!). > > So, the only thing I thought to do is > a) look at every header file that is #included in the xwrits code > b) use dlocate or similar to see which packages all those headers are in. > c) make xwrits build-depend on those packages. > > But this will take me quite a long time. I wondered if I am missing > something obvious and there is a better way to do it. Or am I on the right > track after all. > > Now, obviously, I don't want someone to actually tell me which things I > should be build-depending on. I want to know how to work out such things > for myself in the future :) (It would also defy the point of my AM asking > me this.) But I would appreciate a hint... Well I would do it this way: ([EMAIL PROTECTED])~$ldd /usr/bin/xwrits | grep X11R6 libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40025000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4002e000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40045000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4010d000) ([EMAIL PROTECTED])~$ Then I would do `dpkg -S libSM.so.6` and similar for every other library. Then just take -dev version of every package. This should be enough. You can always ensure using pbuilder. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: sorting through xlibs-dev dependencies?
El ds 18 de 12 del 2004 a les 22:39 +, en/na Helen Faulkner va escriure: > Hi, > > I hope this isn't a too dumb question! > > I'm the maintainer for xwrits, and partway through the NM process. My > application manager (Frank Lichtenheld) has sent me a review of my packages, > and I am confused about one of the things he suggested I do. > > xwrits currently depends on xlibs-dev. Frank suggests that I replace that > with only the needed dependencies. > > What I am confused about is how to tell what it really needs and what it > doesn't really need. I don't know that much about X, in general. xlibs-dev > seems to be a package that does nothing but depend on a collection of many > different X libraries. But I don't know what all those libraries do (and > no, I don't want to read the code for all of them!). > I use this trick: # Here's a hack you can use to find out which packages your package needs to be built: strace -f -o /tmp/log ./configure # or make instead of ./configure, if the package doesn't use autoconf for x in `dpkg -S $(grep open /tmp/log|perl -pe 's!.* open\(\"([^ \"]*).*!$1!' |grep "^/"| sort | uniq| grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|cut -f1 -d":"| sort | uniq`; do echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; done I think it could help you :) > So, the only thing I thought to do is > a) look at every header file that is #included in the xwrits code > b) use dlocate or similar to see which packages all those headers are in. > c) make xwrits build-depend on those packages. > > But this will take me quite a long time. I wondered if I am missing > something obvious and there is a better way to do it. Or am I on the right > track after all. > > Now, obviously, I don't want someone to actually tell me which things I > should be build-depending on. I want to know how to work out such things > for myself in the future :) (It would also defy the point of my AM asking > me this.) But I would appreciate a hint... > > Thanks, > > Helen > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New upstream packages?
Hi everyone, After checking appropriate docs and asking around and getting different answers, I thought I'd see if there was any consensus on this: How do you deal with new upstream releases? The general answers I'm getting seem to be along the lines of "move the debian/ directory to the new release and tweak it til things work". Is this correct? If so (or if not), shouldn't there be something in devref or policy about it? -- off the chain like a rebellious guanine nucleotide signature.asc Description: Digital signature
Re: sorting through xlibs-dev dependencies?
On Sat, Dec 18, 2004 at 10:39:37PM +, Helen Faulkner wrote: > Hi, > > I hope this isn't a too dumb question! *peeking forward*: no, it isn't. > xwrits currently depends on xlibs-dev. Frank suggests that I replace that > with only the needed dependencies. > > So, the only thing I thought to do is > a) look at every header file that is #included in the xwrits code > b) use dlocate or similar to see which packages all those headers are in. > c) make xwrits build-depend on those packages. > > But this will take me quite a long time. I wondered if I am missing > something obvious and there is a better way to do it. Or am I on the right > track after all. Four possibilities come to mind: a) start out in a clean chroot, and use auto-apt to build your package. auto-apt will ask you to install exactly the x build-depends you need. However, auto-apt is a pain to setup in my experience, plus it probably isn't necessarily correct (depending on the complexitiy of the configure script, it could be just detecting stuff without actually needing it, or the other way around, detecting without auto-apt noticing that some lib is not available, while it would enhance xwrits) Advantage is that it will also catch any library that could maybe enhance xwrits b) start out with xlibs-dev installed, make sure you don't run X at the moment (or in that chroot, if you're doing this in a chroot), build your package, and use find to look for file that were accessed during the build (atime changed). You can run this list through apt-file or though all /var/lib/dpkg/info/*.list An easier alternative that's nearly the same is using dpkg-depcheck, it's slower in execution time, but easier and possibly more correct (as it catches stats too, although I doubt it would make a difference) c) simply build the package, look at the generated shlibdeps, and deduct the -dev packages needed. Test that if you build your package only with those X lib packages installed, the same shlibs will result (I followed this strategy with one of my packages, and this way missed one library, because I didn't check carefully enough. So I ended up unintentionally disabling a feature in my program... d) Tell Frank to not be so annoying, since the advantage (a bit less build-deps needed during build time, but no differences in the resulting .debs) does not outweight the possible issues you're introducing now or in the future by making a mistake here, nor the excessive amount of time it takes doing this right... ;-) Thanks for maintaining this package btw, it's exactly as annoying as it should be --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sorting through xlibs-dev dependencies?
On Sun, 2004-12-19 at 00:04, Bartosz Fenski aka fEnIo wrote: > On Sat, Dec 18, 2004 at 10:39:37PM +, Helen Faulkner wrote: > > Hi, > > Hello. > > > I hope this isn't a too dumb question! > > ;) > > > I'm the maintainer for xwrits, and partway through the NM process. My > > application manager (Frank Lichtenheld) has sent me a review of my > > packages, and I am confused about one of the things he suggested I do. > > > > xwrits currently depends on xlibs-dev. Frank suggests that I replace that > > with only the needed dependencies. > > > > What I am confused about is how to tell what it really needs and what it > > doesn't really need. I don't know that much about X, in general. > > xlibs-dev seems to be a package that does nothing but depend on a > > collection of many different X libraries. But I don't know what all those > > libraries do (and no, I don't want to read the code for all of them!). > > > > So, the only thing I thought to do is > > a) look at every header file that is #included in the xwrits code > > b) use dlocate or similar to see which packages all those headers are in. > > c) make xwrits build-depend on those packages. > > > > But this will take me quite a long time. I wondered if I am missing > > something obvious and there is a better way to do it. Or am I on the right > > track after all. > > > > Now, obviously, I don't want someone to actually tell me which things I > > should be build-depending on. I want to know how to work out such things > > for myself in the future :) (It would also defy the point of my AM asking > > me this.) But I would appreciate a hint... > > Well I would do it this way: > > ([EMAIL PROTECTED])~$ldd /usr/bin/xwrits | grep X11R6 > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40025000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4002e000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40045000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4010d000) > ([EMAIL PROTECTED])~$ > > Then I would do `dpkg -S libSM.so.6` and similar for every other library. > Then just take -dev version of every package. > > This should be enough. You can always ensure using pbuilder. > > regards > fEnIo For another approach, somewhat more automated, have a look at dpkg-depcheck(1) from the devscripts package. Not that I disagree with fenio's method - there's just more than one way to do it :-) Cheers, Til -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New upstream packages?
* Erinn Clark <[EMAIL PROTECTED]> [2004:12:18 18:23 -0500]: Of course, just after sending this mail, I was directed to: http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream ...which I somehow managed to miss. It's still a bit sparse, so any other tips people have for dealing with new upstream releases is very welcome. -- off the chain like a rebellious guanine nucleotide signature.asc Description: Digital signature
Re: sorting through xlibs-dev dependencies?
Thanks Jeroen and all others who have answered :) I'll have a go at the ideas you suggested and see how far I get with it... d) Tell Frank to not be so annoying, since the advantage (a bit less build-deps needed during build time, but no differences in the resulting .debs) does not outweight the possible issues you're introducing now or in the future by making a mistake here, nor the excessive amount of time it takes doing this right... ;-) That suggestion has particular appeal ;) But I guess it would break the "rules" for NM . Better just go do what my AM says to do... Thanks again, Helen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sorting through xlibs-dev dependencies?
In gmane.linux.debian.devel.mentors, you wrote: > So, the only thing I thought to do is > a) look at every header file that is #included in the xwrits code > > But this will take me quite a long time. I wondered if I am missing > something obvious and there is a better way to do it. Or am I on the right > track after all. I once wrote a script for that: http://www.informatik.uni-bremen.de/~jmm/xlibs-split-check-20040331.tar.gz You should double-check in pbuilder though, as there may be some corner cases uncovered. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New upstream packages?
On 20041218T182328-0500, Erinn Clark wrote: > How do you deal with new upstream releases? The general answers I'm getting > seem to be along the lines of "move the debian/ directory to the new > release and tweak it til things work". Is this correct? If so (or if not), > shouldn't there be something in devref or policy about it? Like with many other things in Debian, how you do it doesn't matter as long as you don't break things. Things that should be considered include: - Use a -1 Debian revision number for the new upstream release. - Preserve old changelog entries (sounds obvious, but there have been incidents...) - Add an entry "New upstream release" to the changelog. - Upgrades to the new version should preferably be silent and nonintrusive (existing users should not notice the upgrade except by discovering that old bugs have been fixed and there perhaps are new features) - When an upgrade is necessarily intrusive (eg. it will break existing usage), the upgrade must be noisy (a note in README.Debian or other documentation is generally not enough; NEWS.Debian note may become okay once apt-listchanges with NEWS.Debian support becomes standard operating practice) - Existing Debian changes need to be reevaluated; throw away stuff that upstream has incorporated (in one form or another) and remember to keep stuff that hasn't been incorporated by upstream, unless there is compelling reason not to. I'm probably forgetting something here. It isn't really possible to give comprehensive generally useful procedures - the situation dictates what you need to do. For many packages, for small upstream upgrades, uupdate (from devscripts) can make all necessary changes. Even then, you should be cautious and read upstream release documentation, lurk in upstream user forums and bug tracking systems looking for problem reports, test, test, test and test again. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: sorting through xlibs-dev dependencies?
On Sun, Dec 19, 2004 at 12:04:41AM +0100, Bartosz Fenski aka fEnIo wrote: > > I'm the maintainer for xwrits, and partway through the NM process. My > > application manager (Frank Lichtenheld) has sent me a review of my > > packages, and I am confused about one of the things he suggested I do. > > > > xwrits currently depends on xlibs-dev. Frank suggests that I replace that > > with only the needed dependencies. > > > > What I am confused about is how to tell what it really needs and what it > > doesn't really need. I don't know that much about X, in general. > > xlibs-dev seems to be a package that does nothing but depend on a > > collection of many different X libraries. But I don't know what all those > > libraries do (and no, I don't want to read the code for all of them!). > > > > So, the only thing I thought to do is > > a) look at every header file that is #included in the xwrits code > > b) use dlocate or similar to see which packages all those headers are in. > > c) make xwrits build-depend on those packages. > > > > But this will take me quite a long time. I wondered if I am missing > > something obvious and there is a better way to do it. Or am I on the right > > track after all. > > > > Now, obviously, I don't want someone to actually tell me which things I > > should be build-depending on. I want to know how to work out such things > > for myself in the future :) (It would also defy the point of my AM asking > > me this.) But I would appreciate a hint... > Well I would do it this way: > ([EMAIL PROTECTED])~$ldd /usr/bin/xwrits | grep X11R6 > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40025000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4002e000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40045000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4010d000) > ([EMAIL PROTECTED])~$ > Then I would do `dpkg -S libSM.so.6` and similar for every other library. > Then just take -dev version of every package. Please always use objdump -p /usr/bin/xwrits | grep NEEDED instead. If you use ldd, it will report indirect lib dependencies as well, resulting in the same problem of excessive build deps. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New upstream packages?
On Sun, Dec 19, 2004 at 02:48:02AM +0200, Antti-Juhani Kaijanaho wrote: > Like with many other things in Debian, how you do it doesn't matter as > long as you don't break things. Things that should be considered > include: > - Use a -1 Debian revision number for the new upstream release. > - Preserve old changelog entries (sounds obvious, but there have been >incidents...) > - Add an entry "New upstream release" to the changelog. ... and please note that "New upstream release" is not a change that closes bugs other than wishlist requests *for* the new upstream release; if there are changes *in* the new upstream release that fix reported bugs, please enumerate those changes before closing the bugs in the changelog. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New upstream packages?
On Sat, 18 Dec 2004, Erinn Clark wrote: > How do you deal with new upstream releases? The general answers I'm getting I'd suggest using a version control system (even a lame one such as CVS), so that you know exactly what changed from one upstream to another, and update the debian/ stuff and any dpatches accordingly. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New upstream packages?
* Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004:12:18 23:53 -0200]: > On Sat, 18 Dec 2004, Erinn Clark wrote: > > How do you deal with new upstream releases? The general answers I'm getting > > I'd suggest using a version control system (even a lame one such as CVS), so > that you know exactly what changed from one upstream to another, and update > the debian/ stuff and any dpatches accordingly. Yeah, I use arch. I know how to get a "working" release, but the documentation is sparse enough that I thought it suitable to seek out other procedures. OTOH, it seems the information I'm getting here is roughly the same as I've seen elsewhere. -- off the chain like a rebellious guanine nucleotide signature.asc Description: Digital signature
Re: New upstream packages?
Erinn Clark <[EMAIL PROTECTED]> writes: > * Erinn Clark <[EMAIL PROTECTED]> [2004:12:18 18:23 -0500]: > > > Of course, just after sending this mail, I was directed to: > > http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream > > ...which I somehow managed to miss. It's still a bit sparse, so any other > tips people have for dealing with new upstream releases is very welcome. First of all, I'll assume you've skimmed over the source as part of your initial packaging. I usually go through the following steps: 1. Read the upstream changelog, NEWS, and whatever other documentation they may have released with the new version. 2. Do a 'diff -urN' between the old and new upstream sources to try to get a feel for the scope of the changes, where work is actively being done (and thus where new bugs may appear), and also keep an eye out for anything suspicious. 3. Port the old Debian packaging to the new version. This basically involves applying the diff.gz from the old package to the new one and incrementing the debian/changelog. Tools like uupdate help automate this for you. Personally I keep all of my packages in a subversion repository and thus do an svn merge. 4. If the patch/merge did not apply cleanly, inspect the situation to determine what failed (clues are left in .rej files). Most often the problem is that a patch you applied to the source was integrated upstream, and thus the patch is no longer relevant. 5. If any changes were made to the build system (hopefully you'd know from steps 1 and 2) and update the debian/rules and debian/control build dependencies if necessary. 6. Build the new package. Personally I always build in a pbuilder chroot since I use some 3rd party packages on my system and I don't want those interfering. 7. Verify that the new package builds correctly. 8. Run lintian to catch any obvious policy violations. 9. Run 'debdiff old-package.change new-package.change'. Verify that no files have been unintentionally misplaced or removed, and no other inadvertent changes were made. 10. Verify the contents with 'debc new-package.changes'. Ensure no files are zero-length that should not be. 11. Install the new package. Verify it installs/upgrades correctly. Verify that it works normally. If the package makes use of non-trivial pre/post/inst/rm scipts, be sure to test the upgrade paths of those. 12. Check to see if any bugs have been fixed that are currently open in the BTS. If they have been, close them in the debian/changelog. 13. Check the sanity of the diff.gz file. Run 'interdiff -z old-package.diff.gz new-package.diff.gz' and verify any modifications changes are intentional and no junk files have crept in. 14. Check the contents of the .changes file to make sure you are uploading to the correct distribution, the proper bugs closures are listed in the Closes: field, the Maintainer: and Changed-By: fields match, the file is GPG-signed, etc. 15. If any changes were made to correct anything in the packaging along the way, repeat steps 6-13 until satisfied. If your upload needs to be sponsored, be sure to note any special options required when building the package (like 'dpkg-buildpackage -sa -v ...') and be sure to inform your sponsor so he or she builds it correctly. Did I miss anything? -- For every sprinkle I find, I shall kill you! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian bug #217571 : mediawiki package
On Sat, Dec 18, 2004 at 01:36:07PM +0100, Adeodato Simó wrote: > * Ashar Voultoiz [Sat, 18 Dec 2004 13:22:10 +0100]: Hi, Ashar. I'm working on a mediawiki package for Debian; thus the ITP registration. As you know, I'm also a MediaWiki developer. I'l be happy to incorporate any features from your package, or get suggestions. In the future, you can probably save yourself some time and effort by contacting the ITP'er before building a package on your own. ~ESP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
