Re: two new packages, one depends upon the other
On Tue, Aug 03, 2004 at 12:08:10AM -0400, Jay Berkenbilt wrote: > Suppose I have two packages: A and B where B depends and build depends > upon A. Neither package has been uploaded before. I can easily build > A in pbuilder using pdebuild, but I can't do the same with B because B > build depends upon A and A is not in the archive (thereby causing > pbuilder-satisfydepends to fail). I have gotten around this by using > pbuilder login, installing A's debs manually, running > pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm > wondering whether there is a better/usual way to do this. Any > suggestions would be welcome. You can always add your own repository to the /etc/pbuilderrc. If you don't have time to create your own, you can use mentors.debian.net, that's what I do usually. > Also, when A and B are ready to be uploaded into unstable, I am > assuming that, as long as A is uploaded first, there's no reason not > to upload them together. Of course, B won't be able to built from > source until its build dependencies can be satisfied, which won't > happen until A is built. Would it be useful to wait a few days > between uploading A and B? The perfect solution would be to wait for ftp-master approval of the B package and then upload A package, but approval could take few weeks. I think that delay between uploads is a good idea. > If B fails to build from source, is it > the case that manual intervention is then required to get it to retry, > or does this happen automatically? Thanks again for any > clarification. That depends on the reason of not-building. What reasons do you expect? 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: How to retire a bug tagged wontfix,woody?
Kevin Glynn <[EMAIL PROTECTED]> writes: > Andreas Metzler writes: > > On Mon, Aug 02, 2004 at 03:03:31PM +0200, Kevin Glynn wrote: > > > I am the (new) maintainer for mozart. I have one Serious bug > > > outstanding: > > > > > >http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozart). > > > > > > The bug was tagged wontfix, woody. The bug has been fixed in versions > > > later than woody. What should I do? Will this just hang around > > > forever? > > [...] > > > > Basically that is up to you as maintainer. Having open bugs in the BTS > > tagged woody that you are not going to fix only serves one purpose: > > documentation. If you do not think this is necessary close it. > > > > Personally, for this specific bug I'd keep it open just a little bit > > longer until sarge is released. > > Thanks for the responses. I understand now, I was just worried about > having open 'Serious' bugs so close to a freeze Then downgrade it. There's a mismatch there anyway. A serious bug should *never* be tagged as wontfix. Either it needs to be fixed or it's not really serious. -- You win again, gravity!
Re: Bug#147813: help converting from latex2html
On Mon, Aug 02, 2004 at 11:33:27AM +0200, Frank K?ster wrote: > Frank K?ster <[EMAIL PROTECTED]> schrieb: > > > Blars Blarson <[EMAIL PROTECTED]> wrote: > > > >> > >> 1. Get some help to fix the latex. > > > > This hthtml.sty is really dumb. > > > > In the attached patch, > > Argh, there was no patch... > Thanks, patch applied and new package uploaded. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
Re: How to retire a bug tagged wontfix,woody?
On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: > Then downgrade it. There's a mismatch there anyway. A serious bug > should *never* be tagged as wontfix. Either it needs to be fixed or > it's not really serious. This is not true. For example, architecture-dependent data in /usr/share is a serious bug, but if a version in woody has this bug, it is still wontfix: such a bug doesn't render the package nearly unusable, doesn't cause dataloss, isn't a security issue, hence, isn't important enough to risk breaking stuff in woody for.. RC bugs tagged woody (and not sarge or sid) do in no way affect sarge's release, you can safely leave them around for documentation purposes (i.e., letting people know you're aware of the bug in woody, but that it won't be resolved in woody, so people won't file new bugs for it). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Packaging MAME
Hello! I have been using debian for a while, and have been compiling my own copy of MAME (the Multiple Arcade Machine Emulator) (from http://x.mame.net) for my own use. It looks as if someone packaged this at some point but it never got out of unstable (I used testing) and hasn't been updated in some time. I have tried emailing the maintainer some weeks ago and have recieved no reply. I would like therefore to perhaps take over this package and try to get it up to date. Nowadays, MAME's source has been merged (at least under UNIX) with MESS, a program which emulates a large range of computers and consoles. I am unsure of how to package two programs which come from the same source package so I thought to start with I would simply package MAME. I'm currently trying to package MAME, but thought that I would also look for a sponsor, as I wasn't sure if it might be difficult for a contraversal package. Thank you, Chris
Re: How to retire a bug tagged wontfix,woody?
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: >> Then downgrade it. There's a mismatch there anyway. A serious bug >> should *never* be tagged as wontfix. Either it needs to be fixed or >> it's not really serious. > > This is not true. For example, architecture-dependent data in /usr/share > is a serious bug, but if a version in woody has this bug, it is still > wontfix: such a bug doesn't render the package nearly unusable, doesn't > cause dataloss, isn't a security issue, hence, isn't important enough to > risk breaking stuff in woody for.. A serious bug usually implies a policy violation and not necessarily a usability issue. If the policy violation is exaggerated (like your above example, or the OP's bug), I'd just downgrade it. Leaving serious bugs open and tagged wontfix just makes no sense to me. -- You win again, gravity!
Re: Debian Weekly News - August 3rd, 2004
> 52. http://www.debian.org/devel/wnpp/ > > * [53]fftw -- Library for computing Fast Fourier Transforms. >([54]Bug#263126) > * [55]fftw3 -- Library for computing Fast Fourier Transforms. >([56]Bug#263125) I'd definitely like to see these stay in Debian. I'll look into picking up the work if someone will sponsor me. James? What are you motivations for orphaning fftw? Thanks, -- Justin aptitude install iraf saods9 eclipse xpa sextractor x11iraf wcstools pyraf http://www.justinpryzby.com/debian/ signature.asc Description: Digital signature
out-of-date-standards-version
Hi all, lintian complains: out-of-date-standards-version 3.6.0 N: N: The source package refers to a 'Standards-Version' that is starting to N: get out of date, compared to current Policy. You can safely ignore N: this warning, but please consider updating the package to current N: Policy. The reason I choose this standsards version, is that I can maintain both a woody backport and a normal package using this standard. Is that a valid reason? regards, Olivier
Re: out-of-date-standards-version
On Wed, Aug 04, 2004 at 12:39:22AM +0200, Olivier wrote: > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? It's certainly a better reason than "I couldn't be bothered", which is the standard reason why people don't update their standards-version. Looking at upgrading-checklist, the only change in 3.6.1 was a debconf change. Woody has debconf, and even if it didn't, or you need some feature only present in Sarge's debconf, you could backport debconf to woody (or use one of the pre-existing backports). Ordinarily, I'd say "don't worry about it too much", because Sarge's release is looming (and hence, in a couple of months time, a Woody backport won't be of much interest), however manual prompting is a big problem for certain segments of the community, so, if you really can't use Debconf for your Woody backport prompting, some sort of workaround is recommended. At the very least, *please* guard your manual prompting with a DEBCONF_FRONTEND=noninteractive check. - Matt
Re: out-of-date-standards-version
On Wed, Aug 04, 2004 at 12:39:22AM +0200, Olivier wrote: > Hi all, > > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? Your package in sid/sarge needs to confirm to the latest policy version, whatever you put in standards-version. That field is only a reminder to yourself, of what policy version you checked your package. Nothing automatic happens with it, you can technically set it to anything without any practical effect. 3.6.1 has compared to 3.6.0 only a deprecation, with a 'should' (i.e., not 'must'), so you can safely put 3.6.1 and not lying. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: out-of-date-standards-version
Hello Olivier, * Olivier <[EMAIL PROTECTED]> [2004-08-04 00:49]: > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? no, because your package have to fit in unstable. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
unsubscribe
--
perl -e'$u="\4\5\6";sub H{8*($_[1]%79)+($_[0]%8)}sub G{vec$u,H(@_),1}sub S{vec
($n,H(@_),1)=$_[2]}$_=q^{P`clear`;for$iX){PG($iY)?"O":" "forX8);P"\n"}for$iX){
forX8){$c=scalar [EMAIL PROTECTED];S$iY,G(
$iY)?$c=~/[23]/?1:0:$c==3?1:0}}$u=$n;select$M,$C,$T,.2;redo}^;s/Z/],[\$i/g;s/Y
/,\$_/xg;s/X/(0..7/g;s/P/print+/g;eval' # Michael C. Toren <[EMAIL
PROTECTED]>
RFS: libmarc-record-perl (wnpp #251875)
Request for Sponsor: libmarc-record-perl ITP: http://bugs.debian.org/251875 Description: Modules that define MARC fields, check the validity of MARC records, and handle MARC records as objects. The MARC (MAchine Readable Cataloging) format was designed by the Library of Congress in the late 1960s in order to allow libraries to convert their card catalogs into a digital format. The advantages of having computerized card catalogs were soon realized, and now MARC is being used by all sorts of libraries around the world to provide computerized access to their collections. MARC data in transmission format is optimized for processing by computers, so it's not very readable for the normal human. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: two new packages, one depends upon the other
> > Suppose I have two packages: A and B where B depends and build depends > > upon A. Neither package has been uploaded before. I can easily build > > A in pbuilder using pdebuild, but I can't do the same with B because B > > build depends upon A and A is not in the archive (thereby causing > > pbuilder-satisfydepends to fail). I have gotten around this by using > > pbuilder login, installing A's debs manually, running > > pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm > > wondering whether there is a better/usual way to do this. Any > > suggestions would be welcome. > > You can always add your own repository to the /etc/pbuilderrc. > If you don't have time to create your own, you can use mentors.debian.net, > that's what I do usually. That's so obvious I completely overlooked it. :-) Thanks! It worked perfectly. I already have a local repository, so I just copied these packages into it, reran dpkg-scanpackages, and added it to /etc/pbuilderrc in OTHERMIRROR. It worked perfectly (after I ran pbuilder update --config-override). > > If B fails to build from source, is it > > the case that manual intervention is then required to get it to retry, > > or does this happen automatically? Thanks again for any > > clarification. > > That depends on the reason of not-building. What reasons do you expect? Only not waiting long enough between uploading A and B. Probably nothing to worry about. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
RFS: vips and nip
I have packaged [1] vips and nip. The packages can be found on mentors.debian.net (details follow). All packages are lintian clean and were built in an up-to-date pbuilder environment. I have locally installed and tested the packages. 1. http://www.vips.ecs.soton.ac.uk The following introductory text, largely lifted from the vips web site, briefly describes the software: VIPS is a free image processing system. It is good with large images (images larger than the amount of RAM in your machine), and for working with colour. VIPS consists of two main components: an image processing library, and a spreadsheet-like graphical user interface, available in the nip package. The nip program is really quite remarkable, and has functionality unlike what I've seen any other packages. This is most certainly not just another image viewer or manipulation program. With this program, you can form complex pipelines of image operations using a spreadsheet-like user interface. The resulting images are updated dynamically as parameters are changed. One of the more interesting features here is mosaic assembly. I have used this successfully to create "seamless" scanned images out of parts scanned on my 8.5x11 flatbed scanner. Also, nip can work on very large images and is quite efficient. I was able to do manipulations on 9 300-dpi 24-bit color 8.5 x 11 images simultaneously without any observable lag. I have discussed my interest in packaging vips and nip for Debian with the upstream maintainers, who are enthusiastic about this possibility. There are packages for vips and nip for some other distributions including gentoo. An [2] RFS for this package already existed. I retitled the RFS to an ITP and posted a little bit of additional information. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188478 There are two source packages: vips7.8 and nip. The vips7.8 package creates four binary packages (shown here with their i386 names): libvips7.8-dev_7.8.14-1_i386.deb libvips7.8-doc_7.8.14-1_all.deb libvips7.8-tools_7.8.14-1_i386.deb libvips7.8_7.8.14-1_i386.deb The nip package creates a single binary package: nip_7.8.14-1_i386.deb The vips package has the version number built into the package name because it creates and installs a shared library. Unfortunately, the library version is 0.0.0, but the upstream maintainers have fixed this and are now using sensible shared library naming conventions. To my knowledge, they are not using versioned symbols, though I may take this issue up with them (particularly after this whole tiff fiasco). vips 7.10.0 is out, but it is considered a beta release. The upstream maintainers expressed a preference for having 7.8.14 packaged for Debian for now rather than 7.10.0. The new version of nip is now called nip2. It uses gtk2.0 instead of gtk+. I will package those in a few months when they are considered stable by upstream and have documentation. Clearly they will not be ready in time for sarge. I'm hoping someone will sponsor these packages and upload them soon. They need to be uploaded fairly quickly to make it into sarge. Any feedback on the packaging is, of course, appreciated so that if I need to make changes, there is still time. Since nip build depends upon libvips7.8-dev (which depends upon libvips7.8), a gap of a day or two should be left between uploading vips and uploading nip. A few final notes: I am on the [3] NM queue but have not yet been assigned an AM, so I have some time to go yet. I am currently maintaining the xerces packages (xerces23, xerces24, xerces25, and libxml-xerces-perl) as a member of the debian-sgml-xml group on alioth. I am listed as a co-maintainer of those packages, though I am presently the only person actively working on them. As for vips and nip, I am not associated with the packages in any way other than being a user. 3. http://nm.debian.org/nmstatus.php?email=ejb%40ql.org Thanks for your support. If no one steps up to sponsor these packages within a couple of days, I will ask two people who have sponsored uploads for me before, but I'm hoping someone who is interested in image manipulation software will take a look at these. I don't want to seem impatient, which is why I mention this up front. I'm only trying to act quickly because of the looming sarge freeze. :-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Call to undefined function: mysql_connect()
I have install php4-mysql package using apt-get but when i ran my php script, it gave me the error "Call to undefined function: mysql_connect()..." Did I missed out anything? Regards,Jarod Lim Wui KiatPhoenix Games Studio Sdn BhdSuite C211, 2nd Floor, Block 3440, Enterprise 1Jalan Teknokrat 3, 63000 CyberjayaSelangor Darul EhsanMalaysiaTel: +603 8319 5680Fax: +603 8319 5679www.phoenix-gamestudios.com = Disclaimer: Private and Confidential: This e-mail transmission is strictly confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not copy, disclose, distribute or take any action in reliance on it. If you have received this e-mail in error, please delete it then notify us as soon as possible. The sender of the email is not responsible for any changes made to it or any attachments after transmission. It is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect their systems or data. Please carry out virus and other such checks where appropriate.
Re: Call to undefined function: mysql_connect()
On Wed, Aug 04, 2004 at 12:44:23PM +0800, Jarod wrote: > I have install php4-mysql package using apt-get but when i ran my php script, > it gave me the error "Call to undefined function: mysql_connect()..." > > Did I missed out anything? add extension=mysql.so in the right php.ini and then restart apache. I think the package do the first, but not the second. btw I don't think it's the right place to ask your question, debian-user should be more appropriate. cheers, -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: How to retire a bug tagged wontfix,woody?
Kevin Glynn <[EMAIL PROTECTED]> writes: > Andreas Metzler writes: > > On Mon, Aug 02, 2004 at 03:03:31PM +0200, Kevin Glynn wrote: > > > I am the (new) maintainer for mozart. I have one Serious bug > > > outstanding: > > > > > >http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozart). > > > > > > The bug was tagged wontfix, woody. The bug has been fixed in versions > > > later than woody. What should I do? Will this just hang around > > > forever? > > [...] > > > > Basically that is up to you as maintainer. Having open bugs in the BTS > > tagged woody that you are not going to fix only serves one purpose: > > documentation. If you do not think this is necessary close it. > > > > Personally, for this specific bug I'd keep it open just a little bit > > longer until sarge is released. > > Thanks for the responses. I understand now, I was just worried about > having open 'Serious' bugs so close to a freeze Then downgrade it. There's a mismatch there anyway. A serious bug should *never* be tagged as wontfix. Either it needs to be fixed or it's not really serious. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#147813: help converting from latex2html
On Mon, Aug 02, 2004 at 11:33:27AM +0200, Frank K?ster wrote: > Frank K?ster <[EMAIL PROTECTED]> schrieb: > > > Blars Blarson <[EMAIL PROTECTED]> wrote: > > > >> > >> 1. Get some help to fix the latex. > > > > This hthtml.sty is really dumb. > > > > In the attached patch, > > Argh, there was no patch... > Thanks, patch applied and new package uploaded. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to retire a bug tagged wontfix,woody?
On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: > Then downgrade it. There's a mismatch there anyway. A serious bug > should *never* be tagged as wontfix. Either it needs to be fixed or > it's not really serious. This is not true. For example, architecture-dependent data in /usr/share is a serious bug, but if a version in woody has this bug, it is still wontfix: such a bug doesn't render the package nearly unusable, doesn't cause dataloss, isn't a security issue, hence, isn't important enough to risk breaking stuff in woody for.. RC bugs tagged woody (and not sarge or sid) do in no way affect sarge's release, you can safely leave them around for documentation purposes (i.e., letting people know you're aware of the bug in woody, but that it won't be resolved in woody, so people won't file new bugs for it). --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]
Packaging MAME
Hello! I have been using debian for a while, and have been compiling my own copy of MAME (the Multiple Arcade Machine Emulator) (from http://x.mame.net) for my own use. It looks as if someone packaged this at some point but it never got out of unstable (I used testing) and hasn't been updated in some time. I have tried emailing the maintainer some weeks ago and have recieved no reply. I would like therefore to perhaps take over this package and try to get it up to date. Nowadays, MAME's source has been merged (at least under UNIX) with MESS, a program which emulates a large range of computers and consoles. I am unsure of how to package two programs which come from the same source package so I thought to start with I would simply package MAME. I'm currently trying to package MAME, but thought that I would also look for a sponsor, as I wasn't sure if it might be difficult for a contraversal package. Thank you, Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to retire a bug tagged wontfix,woody?
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: >> Then downgrade it. There's a mismatch there anyway. A serious bug >> should *never* be tagged as wontfix. Either it needs to be fixed or >> it's not really serious. > > This is not true. For example, architecture-dependent data in /usr/share > is a serious bug, but if a version in woody has this bug, it is still > wontfix: such a bug doesn't render the package nearly unusable, doesn't > cause dataloss, isn't a security issue, hence, isn't important enough to > risk breaking stuff in woody for.. A serious bug usually implies a policy violation and not necessarily a usability issue. If the policy violation is exaggerated (like your above example, or the OP's bug), I'd just downgrade it. Leaving serious bugs open and tagged wontfix just makes no sense to me. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Weekly News - August 3rd, 2004
> 52. http://www.debian.org/devel/wnpp/ > > * [53]fftw -- Library for computing Fast Fourier Transforms. >([54]Bug#263126) > * [55]fftw3 -- Library for computing Fast Fourier Transforms. >([56]Bug#263125) I'd definitely like to see these stay in Debian. I'll look into picking up the work if someone will sponsor me. James? What are you motivations for orphaning fftw? Thanks, -- Justin aptitude install iraf saods9 eclipse xpa sextractor x11iraf wcstools pyraf http://www.justinpryzby.com/debian/ signature.asc Description: Digital signature
out-of-date-standards-version
Hi all, lintian complains: out-of-date-standards-version 3.6.0 N: N: The source package refers to a 'Standards-Version' that is starting to N: get out of date, compared to current Policy. You can safely ignore N: this warning, but please consider updating the package to current N: Policy. The reason I choose this standsards version, is that I can maintain both a woody backport and a normal package using this standard. Is that a valid reason? regards, Olivier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: out-of-date-standards-version
On Wed, Aug 04, 2004 at 12:39:22AM +0200, Olivier wrote: > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? It's certainly a better reason than "I couldn't be bothered", which is the standard reason why people don't update their standards-version. Looking at upgrading-checklist, the only change in 3.6.1 was a debconf change. Woody has debconf, and even if it didn't, or you need some feature only present in Sarge's debconf, you could backport debconf to woody (or use one of the pre-existing backports). Ordinarily, I'd say "don't worry about it too much", because Sarge's release is looming (and hence, in a couple of months time, a Woody backport won't be of much interest), however manual prompting is a big problem for certain segments of the community, so, if you really can't use Debconf for your Woody backport prompting, some sort of workaround is recommended. At the very least, *please* guard your manual prompting with a DEBCONF_FRONTEND=noninteractive check. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: out-of-date-standards-version
On Wed, Aug 04, 2004 at 12:39:22AM +0200, Olivier wrote: > Hi all, > > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? Your package in sid/sarge needs to confirm to the latest policy version, whatever you put in standards-version. That field is only a reminder to yourself, of what policy version you checked your package. Nothing automatic happens with it, you can technically set it to anything without any practical effect. 3.6.1 has compared to 3.6.0 only a deprecation, with a 'should' (i.e., not 'must'), so you can safely put 3.6.1 and not lying. --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: out-of-date-standards-version
Hello Olivier, * Olivier <[EMAIL PROTECTED]> [2004-08-04 00:49]: > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? no, because your package have to fit in unstable. regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
unsubscribe
--
perl -e'$u="\4\5\6";sub H{8*($_[1]%79)+($_[0]%8)}sub G{vec$u,H(@_),1}sub S{vec
($n,H(@_),1)=$_[2]}$_=q^{P`clear`;for$iX){PG($iY)?"O":" "forX8);P"\n"}for$iX){
forX8){$c=scalar [EMAIL PROTECTED];S$iY,G(
$iY)?$c=~/[23]/?1:0:$c==3?1:0}}$u=$n;select$M,$C,$T,.2;redo}^;s/Z/],[\$i/g;s/Y
/,\$_/xg;s/X/(0..7/g;s/P/print+/g;eval' # Michael C. Toren <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: libmarc-record-perl (wnpp #251875)
Request for Sponsor: libmarc-record-perl ITP: http://bugs.debian.org/251875 Description: Modules that define MARC fields, check the validity of MARC records, and handle MARC records as objects. The MARC (MAchine Readable Cataloging) format was designed by the Library of Congress in the late 1960s in order to allow libraries to convert their card catalogs into a digital format. The advantages of having computerized card catalogs were soon realized, and now MARC is being used by all sorts of libraries around the world to provide computerized access to their collections. MARC data in transmission format is optimized for processing by computers, so it's not very readable for the normal human. -- Encrypted Mail Preferred: Key ID: 8527B9AF Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF Information: http://www.gnupg.org/ ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html signature.asc Description: Digital signature
Re: two new packages, one depends upon the other
> > Suppose I have two packages: A and B where B depends and build depends > > upon A. Neither package has been uploaded before. I can easily build > > A in pbuilder using pdebuild, but I can't do the same with B because B > > build depends upon A and A is not in the archive (thereby causing > > pbuilder-satisfydepends to fail). I have gotten around this by using > > pbuilder login, installing A's debs manually, running > > pbuilder-satisfydepends, and then run dpkg-buildpackage, but I'm > > wondering whether there is a better/usual way to do this. Any > > suggestions would be welcome. > > You can always add your own repository to the /etc/pbuilderrc. > If you don't have time to create your own, you can use mentors.debian.net, > that's what I do usually. That's so obvious I completely overlooked it. :-) Thanks! It worked perfectly. I already have a local repository, so I just copied these packages into it, reran dpkg-scanpackages, and added it to /etc/pbuilderrc in OTHERMIRROR. It worked perfectly (after I ran pbuilder update --config-override). > > If B fails to build from source, is it > > the case that manual intervention is then required to get it to retry, > > or does this happen automatically? Thanks again for any > > clarification. > > That depends on the reason of not-building. What reasons do you expect? Only not waiting long enough between uploading A and B. Probably nothing to worry about. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: vips and nip
I have packaged [1] vips and nip. The packages can be found on mentors.debian.net (details follow). All packages are lintian clean and were built in an up-to-date pbuilder environment. I have locally installed and tested the packages. 1. http://www.vips.ecs.soton.ac.uk The following introductory text, largely lifted from the vips web site, briefly describes the software: VIPS is a free image processing system. It is good with large images (images larger than the amount of RAM in your machine), and for working with colour. VIPS consists of two main components: an image processing library, and a spreadsheet-like graphical user interface, available in the nip package. The nip program is really quite remarkable, and has functionality unlike what I've seen any other packages. This is most certainly not just another image viewer or manipulation program. With this program, you can form complex pipelines of image operations using a spreadsheet-like user interface. The resulting images are updated dynamically as parameters are changed. One of the more interesting features here is mosaic assembly. I have used this successfully to create "seamless" scanned images out of parts scanned on my 8.5x11 flatbed scanner. Also, nip can work on very large images and is quite efficient. I was able to do manipulations on 9 300-dpi 24-bit color 8.5 x 11 images simultaneously without any observable lag. I have discussed my interest in packaging vips and nip for Debian with the upstream maintainers, who are enthusiastic about this possibility. There are packages for vips and nip for some other distributions including gentoo. An [2] RFS for this package already existed. I retitled the RFS to an ITP and posted a little bit of additional information. 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188478 There are two source packages: vips7.8 and nip. The vips7.8 package creates four binary packages (shown here with their i386 names): libvips7.8-dev_7.8.14-1_i386.deb libvips7.8-doc_7.8.14-1_all.deb libvips7.8-tools_7.8.14-1_i386.deb libvips7.8_7.8.14-1_i386.deb The nip package creates a single binary package: nip_7.8.14-1_i386.deb The vips package has the version number built into the package name because it creates and installs a shared library. Unfortunately, the library version is 0.0.0, but the upstream maintainers have fixed this and are now using sensible shared library naming conventions. To my knowledge, they are not using versioned symbols, though I may take this issue up with them (particularly after this whole tiff fiasco). vips 7.10.0 is out, but it is considered a beta release. The upstream maintainers expressed a preference for having 7.8.14 packaged for Debian for now rather than 7.10.0. The new version of nip is now called nip2. It uses gtk2.0 instead of gtk+. I will package those in a few months when they are considered stable by upstream and have documentation. Clearly they will not be ready in time for sarge. I'm hoping someone will sponsor these packages and upload them soon. They need to be uploaded fairly quickly to make it into sarge. Any feedback on the packaging is, of course, appreciated so that if I need to make changes, there is still time. Since nip build depends upon libvips7.8-dev (which depends upon libvips7.8), a gap of a day or two should be left between uploading vips and uploading nip. A few final notes: I am on the [3] NM queue but have not yet been assigned an AM, so I have some time to go yet. I am currently maintaining the xerces packages (xerces23, xerces24, xerces25, and libxml-xerces-perl) as a member of the debian-sgml-xml group on alioth. I am listed as a co-maintainer of those packages, though I am presently the only person actively working on them. As for vips and nip, I am not associated with the packages in any way other than being a user. 3. http://nm.debian.org/nmstatus.php?email=ejb%40ql.org Thanks for your support. If no one steps up to sponsor these packages within a couple of days, I will ask two people who have sponsored uploads for me before, but I'm hoping someone who is interested in image manipulation software will take a look at these. I don't want to seem impatient, which is why I mention this up front. I'm only trying to act quickly because of the looming sarge freeze. :-) -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Call to undefined function: mysql_connect()
I have install php4-mysql package using apt-get but when i ran my php script, it gave me the error "Call to undefined function: mysql_connect()..." Did I missed out anything? Regards,Jarod Lim Wui KiatPhoenix Games Studio Sdn BhdSuite C211, 2nd Floor, Block 3440, Enterprise 1Jalan Teknokrat 3, 63000 CyberjayaSelangor Darul EhsanMalaysiaTel: +603 8319 5680Fax: +603 8319 5679www.phoenix-gamestudios.com = Disclaimer: Private and Confidential: This e-mail transmission is strictly confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not copy, disclose, distribute or take any action in reliance on it. If you have received this e-mail in error, please delete it then notify us as soon as possible. The sender of the email is not responsible for any changes made to it or any attachments after transmission. It is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect their systems or data. Please carry out virus and other such checks where appropriate.
Re: Call to undefined function: mysql_connect()
On Wed, Aug 04, 2004 at 12:44:23PM +0800, Jarod wrote: > I have install php4-mysql package using apt-get but when i ran my php script, it > gave me the error "Call to undefined function: mysql_connect()..." > > Did I missed out anything? add extension=mysql.so in the right php.ini and then restart apache. I think the package do the first, but not the second. btw I don't think it's the right place to ask your question, debian-user should be more appropriate. cheers, -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] signature.asc Description: Digital signature
