conffiles no longer needed except ...

2005-11-23 Thread Willi Mann

Hi!

I have no idea how to properly handle the following situation: My 
package logwatch previously had all their configuration files in 
/etc/logwatch/conf. They were marked as conffiles so dpkg was 
responsible for policy-compliant upgrading.


However, since version 7.0 logwatch has a very cool(TM) way to specify 
the configuration. There is a directory default.conf, containing the 
proposed upstream configuration, there is an optional dist.conf dir 
containing the debian specific modifications  (both in 
/usr/share/logwatch/), and there is /etc/logwatch/conf, containing 
optional site-specific modifications. (the ./conf is there because 
upstream allows local scripts to be put in ./scripts ..)


Now the issue is, that all the old files in /etc/logwatch/conf are no 
longer needed, except if it was customized. If it was not customized, 
they should be removed, because they will interfere with the 
configuration by me and upstream, especially when some changes are needed.


The question is: How should they be removed?

- Just by putting a warning in NEWS.Debian, telling the local admin to 
remove them except if he modified it. (A NEWS.Debian file will be needed 
anyway, so users don't stumble over the new layout)
- Trying to figure out in the maintainer scripts if the file has been 
modified, and if it hasn't been modified, delete it?
- Provide the local user a script he can optionally run to remove 
unneeded files (of course with a hint in README.Debian and NEWS.Debian)

- another way?

The current list of files:
http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelistword=logwatchversion=unstablearch=all

thanks for you replies
Willi


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Patching a config file

2005-11-23 Thread Goswin von Brederlow
Joe Smith [EMAIL PROTECTED] writes:

 Goswin von Brederlow [EMAIL PROTECTED] wrote in
 message news:[EMAIL PROTECTED]
 Joe Smith [EMAIL PROTECTED] writes:

 Justin Pryzby [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
 On Sun, Oct 30, 2005 at 06:00:48PM +0100, Danai SAE-HAN wrote:
 Package freetype1-tools owns a configuration file, namely
 /etc/ttf2pk/ttfonts.map.
 It is a conffile, because it is contained in the package:


 That won't work right. On the next upgrade with a changed conffile pkg
 will claim the package was modified by the user while in fact it was
 modifed by the package. That is just wrong.

 If you need to modify the file then don't make it a conffile. Create
 it completly automatically, e.g. in /var/lib/package/, or make it a
 configuartion file and use ucf.

 You misunderstood. I said that it is possible that a Configuration
 file that is stored in the .deb could be a non-conffile.
 The previous poster had asserted that it must be. I had showed how it
 might not be the case.


 Basically The package could leave the file as a plain file, and in
 preinst gather any user changes, let the new version destroy the old
 version (AFAIK dpkg won't compain because it is NOT a conffile), and
 then restore user changes.)

 Just re-read my post thinking I was talking about a normal file rather
 than a confile.

Debian Policy 10.7.3:

| The other way to do it is via the maintainer scripts. In this case,
| the configuration file must not be listed as a conffile and must not
| be part of the package distribution.

So our previous poster is completly right by saing it is a conffile
since it is contained in the package. Anything else would be a policy
violation.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: conffiles no longer needed except ...

2005-11-23 Thread Justin Pryzby
On Wed, Nov 23, 2005 at 10:50:47AM +0100, Willi Mann wrote:
 Hi!
 
 I have no idea how to properly handle the following situation: My 
 package logwatch previously had all their configuration files in 
 /etc/logwatch/conf. They were marked as conffiles so dpkg was 
 responsible for policy-compliant upgrading.
 
 However, since version 7.0 logwatch has a very cool(TM) way to specify 
 the configuration. There is a directory default.conf, containing the 
 proposed upstream configuration, there is an optional dist.conf dir 
 containing the debian specific modifications  (both in 
 /usr/share/logwatch/), and there is /etc/logwatch/conf, containing 
 optional site-specific modifications. (the ./conf is there because 
 upstream allows local scripts to be put in ./scripts ..)
 
 Now the issue is, that all the old files in /etc/logwatch/conf are no 
 longer needed, except if it was customized. If it was not customized, 
 they should be removed, because they will interfere with the 
 configuration by me and upstream, especially when some changes are needed.
 
 The question is: How should they be removed?
You should look at dpkg.org, where there are some useful conffile
examples, and maybe also play with udev, which I think helps to handle
this type of situation.

-- 
Clear skies,
Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



How to create the most compatible package

2005-11-23 Thread Bram Neijt
Hi.

I'm working on a very simple package which, only has compile time dependencies.
I'm currently on debian unstable, with g++-4.0 as my main compiler
(it's a C++ program).

I've succesfully created a package and installed it on another debian
system, however when I go to an Ubuntu system, it seems to needs the
newer libraries (g++-4.0 libraries?)

So my question is:
  How can I create the most compatible package without resorting to source?

Greetings,
  Bram
--
Key fingerprint = CFF9 A55D 6677 7EF2 035D  7695 639D 107C EDB3 D318



Re: Menu problems

2005-11-23 Thread Jon Dowland
On Tue, Nov 22, 2005 at 10:02:39AM -0500, Daniel Milstein wrote:
 The menu system will only install entries in a Debian/ directory in
 xdg-aware  desktop environments, where users are not likely to look, 

This is a concious decision on the part of the respective upstream
authors and/or maintainers of the xdg-aware desktop environments, and
IMHO a bug. I'm planning to see if this can be fixed for etch when I
have finished a few other things first.

 and only if the menu-xdg package is installed.

Personally, I think this should be Depends:-ed in for menu-carrying apps
which don't supply a menu-method.

 You could have your package depend on the menu-xdg package, but I
 would recommend using desktop files in addition to menu files.

But only for those reasons stated above?

-- 
Jon Dowland
http://jon.dowland.name/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: cdbs and i686-pc-linux-gnu-ar error

2005-11-23 Thread Loïc Minier
On Wed, Nov 23, 2005, Alexei Chetroi wrote:
 make[2]: i686-pc-linux-gnu-ar: Command not found

 I'd say this is somewhere in your environment, and shouldn't, try:
   env | grep i686

  HTH,
-- 
Loïc Minier [EMAIL PROTECTED]
What do we want? BRAINS!When do we want it? BRAINS!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



RFS: mednafen -- multi-system emulator

2005-11-23 Thread Ryan Schultz
Package: wnpp
Owner: Ryan Schultz [EMAIL PROTECTED]
Severity: wishlist

* Package name: medanfen
  Version : 0.3.7
  Upstream Author : Mednafen Team
* URL : http://mednafen.com/
* License : GPL
  Description : multi-system emulator

 Mednafen is a command-line driven emulator for many different systems. It
 has full support for OpenGL and SDL graphics, network play, sound output via
 various methods (Esound, Jack, etc.), remappable input configuration,
 joystick and keyboard support, save states, game rewinding, and screenshots.
 .
 The systems supported by Mednafen are:
* Atari Lynx
* GameBoy
* GameBoy Color
* GameBoy Advance
* NES
* PC Engine (TurboGrafx 16)
* SuperGrafx
 .
 Hardware emulated by Mednafen includes:
* NES gamepad, Zapper, PowerPad
* Four-Score, Famicom multiplayer adapter
* Arkanoid, HyperShot, Space Shadow, Mahjong controllers
* Oeka Kids tablet, Quiz King buzzers, Family Trainer, Barcode World 
reader
* Game Genie

PBuilder/Lintian-clean packages available at:
deb http://rschultz.ath.cx/debian unstable/i386/
deb-src http://rschultz.ath.cx/debian unstable/source/

-- 
Ryan Schultz
vi users are mammals, and they flip out and kill people *all the time.*


pgpDK3jF039Ss.pgp
Description: PGP signature


RFS: pykdeextensions -- Python packages to support KDE applications (scripts)

2005-11-23 Thread Fathi Boudra
* Package name: pykdeextensions
  Version : 0.4.0
  Upstream Author : Simon Edwards [EMAIL PROTECTED]
* URL : http://www.simonzone.com/software/pykdeextensions
* License : GPL
  Description : Python packages to support KDE applications (scripts)

PyKDE Extensions is a collection of software and Python packages
to support the creation and installation of KDE applications.

the same source provides also libpythonize0 package.

You can find my packages on mentors.debian.net

There's some lintian and linda reports :

1) lintian :
W: libpythonize0: 
binary-or-shlib-defines-rpath ./usr/lib/libpythonize.so.0.0.0 /usr/lib
N:
N:   The binary or shared library defines the `RPATH'. Usually this is a
N:   bad thing. Most likely you will find a Makefile with a line like:
N:   gcc test.o -o test -Wl,--rpath
N:   or
N:   gcc test.o -o test -R/usr/local/lib
N:   Please contact debian-devel@lists.debian.org if you have questions
N:   about this.
N:

2) linda :

W: libpythonize0-dev; The .la file /usr/lib/libpythonize.la contains a libdir 
which is different to its path.
 The .la file shown above contains a line libdir='somedir'. This
 should be set to the directory that the .la file exists in, not where
 the .la file was built.
W: libpythonize0; Binary /usr/lib/libpythonize.so.0.0.0 compiled with an RPATH 
of /usr/lib.
 This binary or shared library defines the `RPATH', which is usually a
 bad thing.  Most likely you will find a Makefile with a line like: gcc
 test.o -o test -Wl,--rpath

kde-guidance needs libpytonize.

cheers,

Fathi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: How to create the most compatible package

2005-11-23 Thread Matt Zimmerman
On Wed, Nov 23, 2005 at 01:56:30PM +0100, Bram Neijt wrote:
 I'm working on a very simple package which, only has compile time 
 dependencies.
 I'm currently on debian unstable, with g++-4.0 as my main compiler
 (it's a C++ program).
 
 I've succesfully created a package and installed it on another debian
 system, however when I go to an Ubuntu system, it seems to needs the
 newer libraries (g++-4.0 libraries?)
 
 So my question is:
   How can I create the most compatible package without resorting to source?

The most compatible package is a source package.  Debian and Ubuntu both
have autobuilders to handle creating binary packages with the appropriate
toolchain and dependencies.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Bangladesh Key-Signing completed - Debian Maintiner base can now be extended there.

2005-11-23 Thread Jamil Ahmed

Matthew Grant wrote:


Hi teRHe!

One of my dreams for the last 4 years has been to help the Bangladesh IT
industry expand and be enhanced by IT workers having the opportunity to
join us, and also to enhance Bangla language support in Linux.
 



Thanks for your interest and great effort!


I GPG signed and identified 4 people by their passports and other
official ID, on the chance that they may want to become maintainers.

Two have decided to go ahead, and I mention them here.  It would be good
if some Mentors got in touch with them.

They are:

Salahuddin Pasha [EMAIL PROTECTED]
Jamil Ahmed [EMAIL PROTECTED]

I believe that Salahuddin is an active participant in the Bangla
localisation effort for OpenOffice.org (or is it Jamil - please correct
me?)



It is me. :)


I believe they are both already quite active on some Debian
mailing lists.

Thank you for helping them.  I am looking forward to the Debian
Community embracing them and encouragin them with open arms.  It is good
to see another corner of the map soon to have a red dot on it!
 



Some introduction of me:

I am Jamil Ahmed from Dhaka, Bangladesh. Professionally I am working in 
a local software development company. In my spare time I do maintain 
some activities for Open Source, mainly localization. Currently I am 
maintaining/working Bengali/Bangla L10n for Debian, Fedora, Mandriva, 
OpenSUSE, Gnome, Firefox, Thunderbird, OpenOffice.org .


I will try my best to work for Debian. I hope I will get necessary 
assistance from you when required. :)


Regards,
`Jamil


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Package versioning troubles

2005-11-23 Thread Svata Dedic
Hello,

sorry for a newbie question, but:
I have patched a little some package (iptraf, in fact) - and created a
package with adjusted version number. I added a changelog entry,
changing the patchlevel number (the number after dash), so the new
.deb's version is 2.7.0-9 (the original version was 2.7.0-8).

When I add it to my repository (rebuild Packages.gz), and do apt-get
update ; apt-get install iptraf, the original iptraf package version
2.7.0-8 is not upgraded to 2.7.0-9.

I really don't know why, and I suspect I am making some very stupid
error. For a short play, the repository is at
deb http://belgarat.klfree.net/klfree-debian/ testing unofficial

Thanks for any help,
-Svata


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Package versioning troubles

2005-11-23 Thread Roberto C. Sanchez
On Wed, Nov 23, 2005 at 09:06:53PM +0100, Svata Dedic wrote:
 Hello,
 
 sorry for a newbie question, but:
 I have patched a little some package (iptraf, in fact) - and created a
 package with adjusted version number. I added a changelog entry,
 changing the patchlevel number (the number after dash), so the new
 .deb's version is 2.7.0-9 (the original version was 2.7.0-8).
 
 When I add it to my repository (rebuild Packages.gz), and do apt-get
 update ; apt-get install iptraf, the original iptraf package version
 2.7.0-8 is not upgraded to 2.7.0-9.
 
 I really don't know why, and I suspect I am making some very stupid
 error. For a short play, the repository is at
   deb http://belgarat.klfree.net/klfree-debian/ testing unofficial
 
 Thanks for any help,
 -Svata
 

Maybe these can help?

http://familiasanchez.net/~roberto/howtos/debrepository
http://familiasanchez.net/~roberto/howtos/debcustomize

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpwsABuAWrln.pgp
Description: PGP signature


Re: Package versioning troubles

2005-11-23 Thread Svata Dedic
Hello,

Thanks for the pointers, I have already seen them in the past - and now
I hopefully made a proper repository. But to be more specific about the
situation:
- apt-get update proceeds OK,
- aptitude shows the customized package as a version of iptraf (this
is OK)
- I can do apt-get install iptraf=2.7.0-8.0.whatever_custom_version and
it works OK,

but when official iptraf (2.7.0-8) is installed, the iptraf package is
not recognized as upgradeable to 2.7.0-8.0.whavever_custom_version
(which I would like to achieve). So plain
apt-get install iptraf
will not do anything

Thanks!
-Svata

Roberto C. Sanchez wrote:
 On Wed, Nov 23, 2005 at 09:06:53PM +0100, Svata Dedic wrote:
When I add it to my repository (rebuild Packages.gz), and do apt-get
update ; apt-get install iptraf, the original iptraf package version
2.7.0-8 is not upgraded to 2.7.0-9.

I really don't know why, and I suspect I am making some very stupid
error. For a short play, the repository is at
  deb http://belgarat.klfree.net/klfree-debian/ testing unofficial
 
 Maybe these can help?
 
 http://familiasanchez.net/~roberto/howtos/debrepository
 http://familiasanchez.net/~roberto/howtos/debcustomize
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Package versioning troubles

2005-11-23 Thread Roberto C. Sanchez
On Wed, Nov 23, 2005 at 10:11:17PM +0100, Svata Dedic wrote:
 Hello,
 
 Thanks for the pointers, I have already seen them in the past - and now
 I hopefully made a proper repository. But to be more specific about the
 situation:
 - apt-get update proceeds OK,
 - aptitude shows the customized package as a version of iptraf (this
 is OK)
 - I can do apt-get install iptraf=2.7.0-8.0.whatever_custom_version and
 it works OK,
 
 but when official iptraf (2.7.0-8) is installed, the iptraf package is
 not recognized as upgradeable to 2.7.0-8.0.whavever_custom_version
 (which I would like to achieve). So plain
   apt-get install iptraf
 will not do anything
 

What is the output of `apt-cache policy iptraf` ?

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpdY1YivMuS1.pgp
Description: PGP signature


Re: Package versioning troubles

2005-11-23 Thread Rogério Brito
On Nov 23 2005, Roberto C. Sanchez wrote:
 What is the output of `apt-cache policy iptraf` ?

The thing is that if the original poster is running a sufficiently new
apt, then it will give preference to trusted (i.e., signed)
repositories and ignore those that aren't.


Hope this helps, Rogério Brito.

-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



RFC: vrms -- virtual Richard M. Stallman

2005-11-23 Thread Rogério Brito
Dear developers,

I am interested in getting feedback on the packaging of vrms. The vrms
package contains the program vrms which lists the non-free packages
installed in your system.

It was poorly maintained[1] for some time and I would like to get the
ball rolling on this package, as you can notice from the changelogs[2]
and from my actions taken triaging and merging bugs on the BTS etc.

Before adding new features and addressing new problems, I would like to
ask you opinions, coments, criticisms etc regarding the packaging of
vrms.

It currently has an open RC bug[3] that was fixed as soon as I received
the report. Unfortunately, as I am not a Debian Developer, I can't
upload it yet (nor can I upload other packages that I'd like to adopt)
and it seems that the other maintainers (that can upload it) are quite
busy right now.

Anyway, while they can't upload the package to sid and following the
mantra that given enough eyeballs, all bugs are shallow, I would like
to ask you for some comments and even style. I'm mostly concerned with
best current practices.

The project is registered in alioth[4] and I can provide source Debian
packages if that is a preferred format for inspection.


Thank you very much for any help, Rogério Brito.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302504;msg=5
[2] http://packages.debian.org/changelogs/pool/main/v/vrms/vrms_1.10/changelog
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338243
[4] http://svn.debian.org/wsvn/vrms
-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]