Re: RFS: swath
On Sat, Jul 01, 2006 at 12:37:37PM +0700, Theppitak Karoonboonyanan wrote: I would be glad if someone uploaded this package for me. Done. Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: RFS - kwin-style-dekorator -- window decoration for kde using png images
On 2006-07-01, George Danchev [EMAIL PROTECTED] wrote:
Looks correct... a couple of extra things you may want to correct anyway:
- since nothing goes to usr/{s}bin you don't need the debian/dirs file, so
you
can safely remove it.
Removed.
- also remove the last two commented lines in debian/copyright after
verifying
what has been suggested there.
Removed - and I have checked all the files.
KeyError thrown
('/usr/share/doc/kwin-style-dekorator/examples/themesStuff/The K-style').
).
Please report a bug against linda appending the full output of
linda --debug --traceback over your deb, and a pointer to your package
location.
Reported.
A upload would be nice.
Thanks in advance.
I hope you will find a sponsor.
So do I, thankyou for your time ;)
A new package is now uploaded on
http://mirror.pusling.com/dekorator
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: swath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/06, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: On Sat, Jul 01, 2006 at 12:37:37PM +0700, Theppitak Karoonboonyanan wrote: I would be glad if someone uploaded this package for me. Done. Thank you very much for your quick help. I really appreciate it. :-) Best regards, - - -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEp5paqgzR7tCLR/4RArE8AJ0QAY7C+Kdnvh51qLRngcyVXglD1gCfUs9c KyNEIHBqiygv4naxWYucJOA= =wuo4 -END PGP SIGNATURE-
RFS: pootle and python-jtoolkit
Dear mentors, I am looking for a sponsor for my packages pootle and python-jtoolkit, which pootle depends on. * Package name: pootle Version : 0.9-1 Upstream Author : David Fraser, translate.org.za * URL : http://translate.sourceforge.net/ * License : GPL Section : python * Package name: python-jtoolkit Version : 0.7.8 Upstream Author : David Fraser, Nick Hurley and Shayan Raghavjee of St James Software. * URL : http://jtoolkit.sourceforge.net/ * License : GPL Section : python They build these binary packages: pootle - Web-based translation and translation management tool python-jtoolkit - Web application framework The packages are linda and lintian clean (with overrides for script-not-executable, caused by python shebang lines in the modules) They should be OK with the new Python policy. The upload would fix these bugs: 353051 (ITP pootle) 334060 (ITP python-jtoolkit) The packages can be found on mentors.debian.net at http://mentors.debian.net/debian/pool/main/p/pootle http://mentors.debian.net/debian/pool/main/p/python-jtoolkit Or just apt-get source pootle python-jtoolkit if your sources.list contains: deb-src http://mentors.debian.net/debian unstable main contrib non-free I would be glad if someone uploaded these packages for me. Kind regards -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: qemu-launcher - GTK+ front-end to QEMU computer emulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, George Danchev wrote: Looks good. No, unfortunately it does not. I made the mandatory all vs. any mistake. Btw, you do not need to build-depend on perl, since debhelper will drag it for you anyway. I do not think that is a proper solution either. Moved it to Build-Depends-Indep instead. Also add a watch file ;-) I was going to, but Erik and I have not yet agreed on how new releases are going to be handled, so currently there is nothing to watch. Updated package is available at the same location. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEp6LGztOe9mov/y4RAgwkAKCANzypM4gTy57wJr+nRYAmLBt94gCg1pCa MNmcklq1sTRgmF3NzL1k88A= =5hW8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog of debian policy?
Hello Harri, Is there a changelog of the Debian policy online? Actually I would have expected a pointer on http://www.debian.org/doc/debian-policy/, but maybe I am too blind to see. That depends on what information you need. If you're refering to the packaging of the policy, that URL's have passed by now. But what I guess you mean is the changes between policy versions, i.e. what you need to change to upgrade a package's standards-version. That information is in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. I don't think that's available online though. Thijs signature.asc Description: This is a digitally signed message part
Re: [RFS] qterm: BBS client for X Window System written in Qt
LI Daobing [EMAIL PROTECTED] wrote: On 6/30/06, Frank Küster [EMAIL PROTECTED] wrote: LI Daobing [EMAIL PROTECTED] wrote: These two files were not added by me. they are in the original source[1]. so I think I have to repackage the source if I want to clear the warnings. Ah, I wasn't aware of that. Upstream has to fix that, you should add a note for ftp-master so that they know who's responsible. Can you tell me how to add this note, Thanks. Hm, I'd either put it into README.Debian, or send a mail to ftp-master just after uploading to the NEW queue. Maybe as a reply to the Foo is NEW message, so that the subject clearly indicates what this is about. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
RFS: rawstudio
Dear mentors, I am looking for a sponsor for my package rawstudio. * Package name: rawstudio Version : 0.2-1 Upstream Author : Anders Kvist [EMAIL PROTECTED] Anders Brander [EMAIL PROTECTED] * URL : http://www.rawstudio.org License : GPL Section : graphics It builds these binary packages: rawstudio - open source raw-image converter and manipulation application The package is lintian clean. The package can be found on mentors.debian.net at http://mentors.debian.net/debian/pool/main/r/rawstudio Or just apt-get source rawstudio if your sources.list contains: deb-src http://mentors.debian.net/debian unstable main contrib non-free I would be glad if someone uploaded this package for me. Kind regards Søren Hansen signature.asc Description: Digital signature
RFC: quilt-el
Hi mentors, I'd like to package quilt-el and submitted ITP[1] about two months ago. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364611 Now I have a problem with it. I can't decide which version I should package. Firstly, its stable release version[2] is quite old and has many bugs. Second, it has developing version[3], and it also has a bug. I sent upstream author some patches. One is only for bug fix, and the others are for add some new features. Unfortunately these are not applied yet. Finally, one month ago, I requested him to apply at least bug fix patche and release new stable release. However he had't replied to me so far. In this case, what should I do? 1. package stable release version 2. package developing version and don't apply any extra patches 3. package developing version and apply bug fix patch 4. wait for upstream to apply bug fix patch and release stable release 5. something else... [2] http://www.selenic.com/quilt/quilt.el [3] http://www.selenic.com/repo/quilt-el Regards, Satoru -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: quilt-el
On Sun, Jul 02, 2006 at 11:18:39PM +0900, Satoru Takeuchi wrote: 1. package stable release version 2. package developing version and don't apply any extra patches 3. package developing version and apply bug fix patch 4. wait for upstream to apply bug fix patch and release stable release 5. something else... The stable version has many bugs in it, so (1) seems pointless. If you go with (3), you will probably get a bug report, possibly with a patch attached, and you would then proceed to actually do (2). If upstream is as dead as you imply (4) will be a looong time in the future. If you have too much time, you can take over or fork upstream and apply any fixes you want and then package that. If you do not have time for this, I would go for (2). Cheers, Søren Hansen. signature.asc Description: Digital signature
Re: RFC: quilt-el
On Sun, 2006-07-02 at 16:28 +0200, Soren Hansen wrote: On Sun, Jul 02, 2006 at 11:18:39PM +0900, Satoru Takeuchi wrote: 1. package stable release version 2. package developing version and don't apply any extra patches 3. package developing version and apply bug fix patch 4. wait for upstream to apply bug fix patch and release stable release 5. something else... The stable version has many bugs in it, so (1) seems pointless. If you go with (3), you will probably get a bug report, possibly with a patch attached, and you would then proceed to actually do (2). If upstream is as dead as you imply (4) will be a looong time in the future. If you have too much time, you can take over or fork upstream and apply any fixes you want and then package that. If you do not have time for this, I would go for (2). Soren: I believe you've mixed the numbers saying (2) instead of (3) and vice versa in your whole post. If not I disagree with you. Satoru: So go with (3), and have the fix as a Debian specific patch for now. If upstream is dead and noone is willing to take over you might consider not packaging it at all. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Procedure for adopting a package?
Hello Mr. Fenski As the maintainer of the package calcurse (at least until yesterday) I was surprised, both good and bad, this morning to check my email and find that a new version of calcurse has been uploaded to Debian. I was surprised in a good way because the upload of version 1.4 was overdue and is now complete. That's great for the users of calcurse. The delay in packaging the update was entirely my fault and had to do with personal circumstances. My personal problems aside, it's great that a upload of calcurse occured to get the unstable package up-to-date. I was surprised in a bad way because with the new upload of version 1.4, I see that I have been replaced as the maintainer of the package. I thought that there was a process, at least informal and out of courtesy if not actually formal, where someone desiring to take over a package would contact the present maintainer and ask if he/she would be willing to part with the package. Either the present maintainer would agree and give up the package or not agree and hopefully invite the person to either co-maintain or assist with the package in some other way. Please let me know if I've misunderstood the adoption process. I absolutely love the Debian project and look forward to contributing my time and effort to it in the future. However I must admit that I'll think twice about packaging software in the future if there is indeed a policy where a DD can simply take over maintainence of a package without even sending me a courtesy email. From the bug reports you've filed against calcurse it's clear to me that you probably are the perfect person to maintain it, so in the final analysis I have no issue with you becoming the maintainer. But like I said, I thought there was a process regarding adoption. Ryan Coyner -- Ryan Coyner http://bakakaba.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: quilt-el
* Sun 2006-07-02 Satoru Takeuchi nqm08501 AT nifty.com * Message-Id: 87d5coks3k.wl%nqm08501 AT nifty.com Hi mentors, I'd like to package quilt-el and submitted ITP[1] about two months ago. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364611 Now I have a problem with it. I can't decide which version I should package. Firstly, its stable release version[2] is quite old and has many bugs. Second, it has developing version[3], and it also has a bug. I sent upstream author some patches. One is only for bug fix, and the others are for add some new features. Unfortunately these are not applied yet. Finally, one month ago, I requested him to apply at least bug fix patche and release new stable release. However he had't replied to me so far. In this case, what should I do? 1. package stable release version 2. package developing version and don't apply any extra patches 3. package developing version and apply bug fix patch Use 3. When the upstream releases new version you can drop the patches. Using dpatch(1) to manage this is easy Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog of debian policy?
Thijs Kinkhorst wrote: Hello Harri, Is there a changelog of the Debian policy online? Actually I would have expected a pointer on http://www.debian.org/doc/debian-policy/, but maybe I am too blind to see. That depends on what information you need. If you're refering to the packaging of the policy, that URL's have passed by now. But what I guess you mean is the changes between policy versions, i.e. what you need to change to upgrade a package's standards-version. That information is in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. I don't think that's available online though. Which is somewhat ironic, given that upgrading-checklist starts out as upgrading-checklist.html in the debian-policy source package, and is then stripped of tags to be distributed as a .txt file. It might be nice to distribute it as html and/or fix-up the reference in section 1.2 to point this file. Perhaps the checklist could be referenced as an appendix or the like so that the ref tag could be used, and then dwww could easily find it as well. However, I'm not sure whether this is wishlist bug-worthy or not. tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog of debian policy?
tony mancill [EMAIL PROTECTED] wrote: packaging of the policy, that URL's have passed by now. But what I guess you mean is the changes between policy versions, i.e. what you need to change to upgrade a package's standards-version. That information is in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. I don't think that's available online though. Which is somewhat ironic, given that upgrading-checklist starts out as upgrading-checklist.html in the debian-policy source package, and is then stripped of tags to be distributed as a .txt file. It might be nice to distribute it as html and/or fix-up the reference in section 1.2 to point this file. Perhaps the checklist could be referenced as an appendix or the like so that the ref tag could be used, and then dwww could easily find it as well. However, I'm not sure whether this is wishlist bug-worthy or not. Hmm.. don't the maintainers of the policy keep it in revision control somewhere? - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ace-of-penguins -- Solitaire-games with penguin-look
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uploaded. tony Jari Aalto+mail.linux wrote: * Sat 2006-07-01 jari.aalto AT cante.net (Jari Aalto+mail.linux) I'm looking for sponsor for followin package. Details below. ITA: ace-of-penguins -- Solitaire-games with penguin-look -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFEqB9ypdwBkPlyvgMRAlfrAJ4wLKE4098wflo5zp+2bHTWe2EnvgCY/HfY C6WiY+BRgr9S5tDu9mM/fQ== =UGOJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284039: Info received and FILED only (was Bug#284039: kdetv: existing debian packages)
Thank you for the additional information you have supplied regarding this problem report. It has NOT been forwarded to the package maintainers, but will accompany the original report in the Bug tracking system. Please ensure that you yourself have sent a copy of the additional information to any relevant developers or mailing lists. If you wish to continue to submit further information on your problem, please send it to [EMAIL PROTECTED], as before. Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: RFC: quilt-el
* Satoru Takeuchi [Sun, 02 Jul 2006 23:18:39 +0900]: 1. package stable release version 2. package developing version and don't apply any extra patches 3. package developing version and apply bug fix patch 4. wait for upstream to apply bug fix patch and release stable release 5. something else... Option (3) is the way to go if you think you're know what are doing and others don't disagree. ;-) It can get messy if further bugs are discovered by users, though, but chances are slimmer if the maintainer is a regulgar user of the package. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Que no te vendan amor sin espinas -- Joaquín Sabina, Noches de boda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure for adopting a package?
* Ryan Coyner [Sun, 02 Jul 2006 12:11:36 -0400]: However I must admit that I'll think twice about packaging software in the future if there is indeed a policy where a DD can simply take over maintainence of a package without even sending me a courtesy email. No, there isn't such policy. To all effects, the calcurse 1.4-1 upload was an unannounced hijack, which are not allowed in Debian at all (dev-ref 5.9.5). I can certainly understand the feelings of a DD who cares for a package if they think that the maintainer (particularly if not DD) is not doing a good job at it. However, I've always dealt with this situation by offering help to the original maintainer, in whichever way was appropriate (eg. co-maintainership if the maintainer just lacks time sometimes, or mentoring and sponsoring if the package is not in well form). I would expect the rest of DDs to do the same. But like I said, I thought there was a process regarding adoption. Confirmed. And thanks for bringing this to our attention in such a polite manner. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org And don't get me wrong - I don't mind getting proven wrong. I change my opinions the way some people change underwear. And I think that's ok. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure for adopting a package?
On Sun, Jul 02, 2006 at 12:11:36PM -0400, Ryan Coyner wrote: Hello Mr. Fenski Hi. As the maintainer of the package calcurse (at least until yesterday) I was surprised, both good and bad, this morning to check my email and find that a new version of calcurse has been uploaded to Debian. I was surprised in a good way because the upload of version 1.4 was overdue and is now complete. That's great for the users of calcurse. The delay in packaging the update was entirely my fault and had to do with personal circumstances. My personal problems aside, it's great that a upload of calcurse occured to get the unstable package up-to-date. I was surprised in a bad way because with the new upload of version 1.4, I see that I have been replaced as the maintainer of the package. I thought that there was a process, at least informal and out of courtesy if not actually formal, where someone desiring to take over a package would contact the present maintainer and ask if he/she would be willing to part with the package. Either the present maintainer would agree and give up the package or not agree and hopefully invite the person to either co-maintain or assist with the package in some other way. I tried to contact you several times. Mails sent to your address were bouncing all the time. I contacted your sponsor and talked about it with him. As a conclusion we decided that I can hijack this package. Please let me know if I've misunderstood the adoption process. I absolutely love the Debian project and look forward to contributing my time and effort to it in the future. However I must admit that I'll think twice about packaging software in the future if there is indeed a policy where a DD can simply take over maintainence of a package without even sending me a courtesy email. From the bug reports you've filed against calcurse it's clear to me that you probably are the perfect person to maintain it, so in the final analysis I have no issue with you becoming the maintainer. But like I said, I thought there was a process regarding adoption. Please don't feel offended. I tried to contact you several times and I hijacked this packaged because I couldn't do that. Feel free to reupload calcurse with you in the maintainer line again. I'm willing to sponsor your upload if you want. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
RFS: pmplib - create music databases used by portable media players
[Note that this request doesn't quite follow the mentors template... CC'ing anibal, who uploaded a similar package by the same upstream author] I am looking for a sponsor for my package pmplib. * Package name: pmplib Version : 0.11-1 (actually it's a 0.12 pre-release, see below) Upstream Authors : Nyaochi [EMAIL PROTECTED] Martin Ellis [EMAIL PROTECTED] * URL : http://pmplib.sourceforge.net/ * License : GPL Section : sound It builds these binary packages: easypmp- create music databases used by portable media players The package is lintian clean. The upload would fix these bugs: 369975 (ITP) The package can be found on mentors.debian.net at http://mentors.debian.net/debian/pool/main/p/pmplib Or just apt-get source pmplib if your sources.list contains: deb-src http://mentors.debian.net/debian unstable main contrib non-free We're nearly ready to release 0.12, and if possible I'd like to have that version in Debian. To the best of my knowledge, there is no other software that supports some of the devices supported by pmplib in the archive (for example, the iRiver U10). The package on mentors.debian.net is a 0.12 pre-release, but for the fact that we haven't bumped the version number from 0.11 yet. I'm looking for someone to review the package as it stands, in order that any necessary changes for inclusion in Debian can be made before 0.12 is released. (Hopefully, it's just the version number and changelog date) Once this is done, and 0.12 is ready, I'd need a sponsor to upload the package. Cheers, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
best practices for dependencies version in new package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Scenario. Package is new (no version uploaded yet). Dependences is determined: dpkg-depcheck and pbuilder was used. But these tools not help task determine dependences version. So, what best practices for dependencies version in this package? What I did already: look bug reports for Dependencies. Some hint? Thanks in advance. Regards, - -- Marcio Roberto Teixeira chave pública: hkp://wwwkeys.pgp.net http://marciotex.googlepages.com/keypub_8709626B.asc página pessoal (em construção): http://marciotex.googlepages.com Usuário tchê Debian/GNULinux Porto Alegre - RS - Brasil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFEqF0yrD1pS4cJYmsRAuUPAJ9YU2AqP3/cHZ4pQIRk6qnqDo1TVgCfdQEX Pcj+0ODav7uYmD1/ONl/dd4= =lMv4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: zeroinstall-injector
Thomas Leonard wrote: But, there also seems to be python-support (dh_pysupport) and python-central. Would using one of these make my package more likely to be accepted? I'm not keen on using python-central because most of the apt-get failures I've had recently with other packages seem to be due to it. That is because python has gone through a transition recently. Please refer to the python policy: http://www.debian.org/doc/packaging-manuals/python-policy/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Dependancies within multi-binary packages
Hi,
I am building some multi-binary packages. The packages contain libraries
that other packages in the same build will depend on. Because the
packages I am building potentially conflict with some already in the
repository I have renamed them all with an extenstion denoting their
purpose. In the control file I am setting the Conflicts and Provides
to turn the libraries into virtual packages and using
${shlibs:Depends} to define lib requirements. When I install my custom
libs dpkg does not seem to recognise the Provides section and tells me
that required libs are not installed -
Example:
From control file:
Package: libpq4-hw
Architecture: any
Section: hw/libs
Depends: ${shlibs:Depends}
Conflicts: libpq4
Provides: libpq4
Description: PostgreSQL C client library
Package: postgresql-client-8.0-hw
Architecture: any
Section: misc
Depends: ${shlibs:Depends}, postgresql-client-common
Conflicts: postgresql ( 7.5), postgresql-client-8.0
Provides: postgresql-client-8.0
Description: front-end programs for PostgreSQL 8.0
Once I install the libpq4-hw package dpkg will still complain:
[EMAIL PROTECTED] # dpkg -i postgresql-client-8.0-hw_8.0.7-1_i386.deb
Selecting previously deselected package postgresql-client-8.0-hw.
(Reading database ... 22134 files and directories currently installed.)
Unpacking postgresql-client-8.0-hw (from
postgresql-client-8.0-hw_8.0.7-1_i386.deb) ...
dpkg: dependency problems prevent configuration of
postgresql-client-8.0-hw:
postgresql-client-8.0-hw depends on libpq4 (= 8.0.4); however:
Package libpq4 is not installed.
dpkg: error processing postgresql-client-8.0-hw (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
postgresql-client-8.0-hw
The dependencies for the client package look like:
Package: postgresql-client-8.0-hw
Version: 8.0.7-1
Section: misc
Priority: optional
Architecture: i386
Depends: libc6 (= 2.3.2.ds1-21), libpq4 (= 8.0.4), libreadline5,
zlib1g (= 1:1.2.1), postgresql-client-common
Conflicts: postgresql ( 7.5), postgresql-client-8.0
Provides: postgresql-client-8.0
Does anyone know how I can fix this one?
--
Nikolai Lusan
Systems Administrator
Hitwise Pty. Ltd.
Level 7 / 580 St Kilda Road
Melbourne, Victoria 3004
Australia
Phone: +61 3 8530 2400
Fax: +61 3 9529 8907
www.hitwise.com.au
[EMAIL PROTECTED]
Worldwide: • United States • United Kingdom • Australia • New
Zealand • Singapore • Hong Kong
To subscribe to our complimentary monthly newsletter, visit:
http://www.hitwise.com.au/
The information transmitted may be confidential, is intended only for
the person to which it is addressed, and may not be reviewed,
retransmitted, disseminated or relied upon by any other persons. If you
received this message in error, please contact the sender and destroy
any paper or electronic copies of this message. Any views expressed in
this email communication are those of the individual sender, except
where the sender specifically states otherwise. Hitwise does not
represent, warrant or guarantee that the communication is free of
errors, virus or interference.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependancies within multi-binary packages
On Mon, Jul 03, 2006 at 12:02:24PM +1000, Nikolai Lusan wrote: Once I install the libpq4-hw package dpkg will still complain: [EMAIL PROTECTED] # dpkg -i postgresql-client-8.0-hw_8.0.7-1_i386.deb Selecting previously deselected package postgresql-client-8.0-hw. (Reading database ... 22134 files and directories currently installed.) Unpacking postgresql-client-8.0-hw (from postgresql-client-8.0-hw_8.0.7-1_i386.deb) ... dpkg: dependency problems prevent configuration of postgresql-client-8.0-hw: postgresql-client-8.0-hw depends on libpq4 (= 8.0.4); however: Package libpq4 is not installed. Versioned dependencies cannot be satisfied by Provided packages, AFAIK. Does anyone know how I can fix this one? I strongly suspect that You're Stuffed. For this sort of thing, I typically just create my own packages with the same name and cross my fingers that they don't get into the wild -- worst case, I make my packages depend on some sort of local dummy package that shouldn't end up in the wider world, to prevent major problems. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependancies within multi-binary packages
On Mon, 2006-07-03 at 12:15 +1000, Matthew Palmer wrote:
On Mon, Jul 03, 2006 at 12:02:24PM +1000, Nikolai Lusan wrote:
Versioned dependencies cannot be satisfied by Provided packages, AFAIK.
Great :)
Does anyone know how I can fix this one?
I strongly suspect that You're Stuffed. For this sort of thing, I typically
just create my own packages with the same name and cross my fingers that
they don't get into the wild -- worst case, I make my packages depend on
some sort of local dummy package that shouldn't end up in the wider world,
to prevent major problems.
looks like I remove the ${shlibs:Depends} from the control file and
put them in by hand, praying I don't leave something out. :)
Thanks for that.
--
Nikolai Lusan
Systems Administrator
Hitwise Pty. Ltd.
Level 7 / 580 St Kilda Road
Melbourne, Victoria 3004
Australia
Phone: +61 3 8530 2400
Fax: +61 3 9529 8907
www.hitwise.com.au
[EMAIL PROTECTED]
Worldwide: • United States • United Kingdom • Australia • New
Zealand • Singapore • Hong Kong
To subscribe to our complimentary monthly newsletter, visit:
http://www.hitwise.com.au/
The information transmitted may be confidential, is intended only for
the person to which it is addressed, and may not be reviewed,
retransmitted, disseminated or relied upon by any other persons. If you
received this message in error, please contact the sender and destroy
any paper or electronic copies of this message. Any views expressed in
this email communication are those of the individual sender, except
where the sender specifically states otherwise. Hitwise does not
represent, warrant or guarantee that the communication is free of
errors, virus or interference.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure for adopting a package?
On Sunday 02 July 2006 23:53, Bartosz Fenski aka fEnIo wrote: --cut-- From the bug reports you've filed against calcurse it's clear to me that you probably are the perfect person to maintain it, so in the final analysis I have no issue with you becoming the maintainer. But like I said, I thought there was a process regarding adoption. Please don't feel offended. I tried to contact you several times and I hijacked this packaged because I couldn't do that. In such cases you better document your intentions in BTS, since that: - will leave public records of your trials to reach the maintainer. - will prevent (or coordinate) duplicate hijack efforts if the package had been really in bad shape and this was the last resort in the light of better maintenance. Hijacking is not necessary a bad thing[tm] imho if done with respectcare. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] qterm: BBS client for X Window System written in Qt
On 7/2/06, Frank Küster [EMAIL PROTECTED] wrote: LI Daobing [EMAIL PROTECTED] wrote: On 6/30/06, Frank Küster [EMAIL PROTECTED] wrote: LI Daobing [EMAIL PROTECTED] wrote: These two files were not added by me. they are in the original source[1]. so I think I have to repackage the source if I want to clear the warnings. Ah, I wasn't aware of that. Upstream has to fix that, you should add a note for ftp-master so that they know who's responsible. Can you tell me how to add this note, Thanks. Hm, I'd either put it into README.Debian, or send a mail to ftp-master just after uploading to the NEW queue. Maybe as a reply to the Foo is NEW message, so that the subject clearly indicates what this is about. I am waiting for a DD help me upload this packge. Can you upload this packge for me? Thanks -- LI Daobing
Re: Dependancies within multi-binary packages
On Mon, Jul 03, 2006 at 12:32:53PM +1000, Nikolai Lusan wrote:
On Mon, 2006-07-03 at 12:15 +1000, Matthew Palmer wrote:
I strongly suspect that You're Stuffed. For this sort of thing, I typically
just create my own packages with the same name and cross my fingers that
they don't get into the wild -- worst case, I make my packages depend on
some sort of local dummy package that shouldn't end up in the wider world,
to prevent major problems.
looks like I remove the ${shlibs:Depends} from the control file and
put them in by hand, praying I don't leave something out. :)
Since all you'll be doing is putting in manually what shlibs:Depends would
have added, I don't think you're going to benefit much. If you're thinking
of gutting the versions, please reconsider -- they're there for very good
reason (ensuring that you don't go linking against a library version that
might not have all the symbols you need), and it'll almost certainly break
something, at some time, and be a right pest to debug.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependancies within multi-binary packages
postgresql-client-8.0-hw depends on libpq4 (= 8.0.4); however: shouldn't it be libpq8 really? or am I missing something? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17]
Re: Dependancies within multi-binary packages
On Mon, 2006-07-03 at 13:04 +1000, Matthew Palmer wrote:
looks like I remove the ${shlibs:Depends} from the control file and
put them in by hand, praying I don't leave something out. :)
Since all you'll be doing is putting in manually what shlibs:Depends would
have added, I don't think you're going to benefit much. If you're thinking
of gutting the versions, please reconsider -- they're there for very good
reason (ensuring that you don't go linking against a library version that
might not have all the symbols you need), and it'll almost certainly break
something, at some time, and be a right pest to debug.
I was thinking I might make it depend on my custom versions (so
libpq4-hw = 8.0.4), it would make my packages installable and tie
everything built from the one source package into each other - which
probably isn't a bad idea considering they will all be compiled with the
same options and packages from outside the build might try calling
features that are just not there.
--
Nikolai Lusan
Systems Administrator
Hitwise Pty. Ltd.
Level 7 / 580 St Kilda Road
Melbourne, Victoria 3004
Australia
Phone: +61 3 8530 2400
Fax: +61 3 9529 8907
www.hitwise.com.au
[EMAIL PROTECTED]
Worldwide: • United States • United Kingdom • Australia • New
Zealand • Singapore • Hong Kong
To subscribe to our complimentary monthly newsletter, visit:
http://www.hitwise.com.au/
The information transmitted may be confidential, is intended only for
the person to which it is addressed, and may not be reviewed,
retransmitted, disseminated or relied upon by any other persons. If you
received this message in error, please contact the sender and destroy
any paper or electronic copies of this message. Any views expressed in
this email communication are those of the individual sender, except
where the sender specifically states otherwise. Hitwise does not
represent, warrant or guarantee that the communication is free of
errors, virus or interference.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: zeroinstall-injector
Felipe Sateler wrote: Thomas Leonard wrote: But, there also seems to be python-support (dh_pysupport) and python-central. Would using one of these make my package more likely to be accepted? I'm not keen on using python-central because most of the apt-get failures I've had recently with other packages seem to be due to it. That is because python has gone through a transition recently. Please refer to the python policy: http://www.debian.org/doc/packaging-manuals/python-policy/ Also, read http://wiki.debian.org/DebianPython/NewPolicy -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
