Re: RFS: gthumb (updated and adopted package)

[Ove Kaaven]

David Paleino skrev:

Il giorno Wed, 2 Jan 2008 12:02:58 +0100
David Paleino <[EMAIL PROTECTED]> ha scritto:


Please don't upload it yet. I've just found out a minor issue during build:
after svn-buildpackage the sources are left modified. Looking at it right now.


Ok, I can't solve this, thus asking for help.

Upstream's tarball provides a file, src/GNOME_GThumb.h, which is dynamically
generated during the build. Now, it happens that this file, at the end of the
build, is different from the provided one, and $(MAKE) distclean deletes it.


Does it *need* to exist before you start the build, or is it a 
completely autogenerated file? If the latter, you shouldn't have to do 
anything at all. Let distclean wipe it, it'll result in a clean .diff.gz.



This gives a tarball different from the original one, thus having unmatching
md5sums.


If it's a non-native package, the orig tarball doesn't change. If you're 
making a new tarball after building, you're doing something wrong. 
Pretty much any attempt to create the exact same tarball more than once 
is doomed to fail, if only because the timestamp will be different.


(Just pitching in...)



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

Re: RFS: gthumb (updated and adopted package)

[Ove Kaaven]

David Paleino skrev:

I'm not recreating the tarball. The first times I was making packages, my
sponsors told me that the result of "debuild clean" (or fakeroot debian/rules
clean) had to be the same as the original tarball unpacked + debian/. Is this
wrong?


I'd qualify that somewhat. It's certainly good practice; the idea is 
that building again never results in something different, and it's good 
to be clean anyway. However, if doing that is difficult (such as if 
upstream forgot to run distclean and left cruft in the orig tarball), I 
think it's also reasonable to follow the following rule (considering 
dpkg-buildpackage will invoke clean before building):


Original tarball + debian diff + debuild clean = debuild + debuild clean

or, failing that, at least the fundamental rule:

Original tarball + debian diff + debuild + debuild clean = another 
debuild + debuild clean


You should never break this last rule, but the stricter rule you're 
currently following is not really worth bending over backwards for IMHO.





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

Need some advice on udev

[Ove Kaaven]

Hi mentors.

I am (nominally) the maintainer of the awesfx package. Admittedly, I 
haven't been bothered to do anything substantial with it for a while 
(not since I lost my own SoundBlaster 32, long story). But now, since I 
have some time, I figured I should at least fix some issues with it, 
even though it's not of much use to myself right now. I've found a new 
upstream release that I'm packaging, for example.


The big thing missing in this package is, of course, the ability to 
automatically load soundfonts into the AWE synthesizer on boot, or when 
the ALSA driver module is loaded, or whatever - so, udev support. There 
are some udev scripts in etc/ in the source tarball, but they don't look 
particularly FHS or Debian-policy-compliant. It looks like those scripts 
expect that you can install a couple of scripts into /etc/alsa.d/, and 
then have the udev rules invoke them, or something. I don't see such a 
directory in Debian... And I don't really know much about udev and how 
to integrate that in Debian. So, where do I put this stuff?


If you're interested, you can find the package at 
http://www.ping.uio.no/~ovehk/awesfx/, there's an unpacked source tree 
in there too so you don't have to download it.


Thanks for any insight...



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

Re: alpine_1.0+dfsg-2_source.changes REJECTED

[Ove Kaaven]

Asheesh Laroia skrev:
others here on debian-mentors and on debian-devel.  I think "Require 
binaries and throw them away" is a very good strategy.  It seems there 
is fairly wide consensus that having the buildds build every package is 
a good thing.


Man, source-only uploads would literally save me hours when uploading my 
packages... They're big (50-100MB) and my uplink bandwidth isn't so hot 
where I am right now... why not take things like that into consideration 
when considering this?




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

Re: RFH: liblicense: dpkg-shlibdeps: failure: couldn't find library

[Ove Kaaven]

Asheesh Laroia skrev:
Naturally, I'm probably doing something wrong - but I have no idea what 
it is.  I think that the soname and library package name are correct, 
for one thing.  Can someone perhaps help?


If you use dh_shlibdeps, you can try this:

dh_shlibdeps -Lliblicense1 -ldebian/liblicense1/usr/lib

(I use this construct in my multibinary package, so if it's wrong, let 
me know...)





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

Re: RFS: ia32-libs split packages

[Ove Kaaven]

Goswin von Brederlow skrev:

Hi,

the ia32-libs package will be split into seperate source packages (95
alltogether). Since my comaintainer is currently bussy I'm looking for
a sponsor for the first wave of those packages. The main converter
package and the 5 packages that are ia64 only in ia32-libs.

The packages are on mentors.debian.net (or getting there as you read):

ia32-libs-tools (0.2) - the converter package

ia32-alsa-lib
ia32-gcc-4.3
ia32-glibc
ia32-ncurses
ia32-zlib

These packages are somewhat special in that amd64 builds them natively
as 32bit but ia64 can't build them and needs converted packages.


It seems to me the changelogs in these packages are such that building 
these packages would generate .changes files that close the same bugs 
that original packages do, which is probably not desirable.




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

Re: RFS: ia32-libs-tools and others

[Ove Kaaven]

Goswin von Brederlow skrev:

Dear mentors,

I am looking for a sponsor for my package "ia32-libs-tools".


Since I assume this'll eventually help my Wine package, I'll take care 
of it.




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

Re: Packaging without Makefile

[Ove Kaaven]

Dominik George skrev:


$ dh-make
$ cd debian/
edit/copy in control, copyright, changelog and edit rules
remove unwanted files
$ cd ../
$ dpkg-buildpackage


Sounds easy - but how do I get it to copy my one single file?


I'd say with the "dh_install" part of your rules file, maybe? Read the docs.



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

Re: the quality of Debian's diff.gz

[Ove Kaaven]

George Danchev skrev:
Very good, but please make these easily visible/readable to the rest via 
diff.gz


Oh no, not again... This was already flam^H^H^H^Hdebated on 
debian-devel. I believe debian-mentors is where new maintainers learn 
current best practices, not where *new* practices are developed; for 
that, you'd go to debian-devel. Feel free to join the efforts there.



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

Re: the quality of Debian's diff.gz

[Ove Kaaven]

George Danchev skrev:
I don't see any new practices being developed here, Debian's diff.gz exists 
from the Debian packaging system's day 1 and abusing it prophesies no good. 


Debian's diff.gz that has existed from day 1 is *one* all-encompossing 
diff. You're requesting shipping *multiple* separable diffs in order to 
identify individual changes and improve readability and maintainability 
outside the package maintainer's own repository. That's quite different, 
and there are various, incompatible ways to do it already in use, and 
conflicting opinions on the best way. Like I said, this kind of 
discussion belongs on debian-devel.


It's not that I don't agree with your point. But if you want to create a 
debate, do it in the proper forum.


Feel free to join the efforts there. 


That didn't produced anything meaningful.


That's not an excuse to give up. In this case, I think the discussion 
stalled more on the lack of tools than anything else; everybody loves to 
discuss, but someone has to *do the work* if status quo is not the 
desired outcome, and nobody likes that part. Hence, creating tools would 
help a lot more than trying to upset people even more. Join the efforts 
by coming up with a technical *solution* to the "no can do/too much 
work" arguments against, and everybody would thank you.



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

Re: how to solve a non pic code in an shlib due to assembly code

[Ove Kaaven]

Picca Frédéric-Emmanuel skrev:
> Is someone on this mailing have the assembly skills to help me, and the
> upstream, solve this problem.
> 
> I already contact the main upstream but it does not know how to
> solve this.

The idea of position-independent code (PIC) is that no absolute memory
offsets should be assembled, everything should be made relative to a
known reference point, which can be the current program counter (or, as
Intel calls it, the instruction pointer).

The basic i386 instruction set does not inherently support PC-relative
addressing. Therefore, any instruction such as "movq mm1,
__jpmm_tg_2_16", "lea ebx,__jpmm_row_tab_frw", etc, that directly
reference a symbol will be given a text relocation (TEXTREL) entry.

When a compiler is given the -fPIC option, it usually solves this by
first using a call/pop combination on function entry to get the PC into
a register, then replacing the absolute reference with a relative one
using the known PC as a base. GCC uses the ebx register for this. (A
drawback of this technique is that performance is reduced slightly in
PIC code, since that means ebx can't be used for anything else.)

For example, instead of

 push ebx
 mov ecx, 8
 lea eax, __jpmm_row_tabs
 lea ebx, __jpmm_rounder
__mmx_idct_rows:

you might write something like this (if you decided to use edx as the
base register):

 call __mmx_idct_rows_base
__mmx_idct_rows_base:
 pop edx
 push ebx
 mov ecx, 8
 lea eax, [edx + __jpmm_row_tabs - __mmx_idct_rows_base]
 lea ebx, [edx + __jpmm_rounder - __mmx_idct_rows_base]

Here, instead of an absolute reference to __jpmm_row_tabs (whose address
won't be known at compile-time, and won't be known before the library is
loaded), we now have a relative offset, __jpmm_row_tabs -
__mmx_idct_rows_base, which *can* be computed at compile-time (since the
*difference* is always the same regardless of where in memory the
library is loaded), and therefore no absolute memory reference gets
assembled into the library. The memory reference is instead calculated
at runtime (using the absolute address loaded into edx as the base).

I'm not 100% sure whether amd64 code would also need a similar
treatment, but I think so. I don't exactly have time to do the job for
you, though. And ideally, it's upstream's job. They wrote the asm code...

However, if they can't or won't fix it, there's *some* good news. In
general, shared libraries must be compiled as PIC because on some
platforms, the library just won't work properly if you don't. However,
i386 and amd64 are not among those platforms. Since the MMX code is only
compiled for those, it might be safe to ignore the lintian error in this
particular case, if there's no other way.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: how to solve a non pic code in an shlib due to assembly code

[Ove Kaaven]

Goswin von Brederlow skrev:
> Ove Kaaven  writes:
> 
>> However, if they can't or won't fix it, there's *some* good news. In
>> general, shared libraries must be compiled as PIC because on some
>> platforms, the library just won't work properly if you don't. However,
>> i386 and amd64 are not among those platforms. Since the MMX code is only
>> compiled for those, it might be safe to ignore the lintian error in this
>> particular case, if there's no other way.
> 
> Slight correction for the books. No insult intended. Amd64 is verry
> much among those. You usualy end up with a 4 byte offset that is
> computed at runtime link time. But with a shared library there is no
> garanty that the offset will fit in 4 bytes and during compile time
> the linker will complain about a 32bit offset being used where 64bit
> might be needed. Sorry, don't know the exact error message by hard.

I suppose I haven't used the amd64 instruction set enough yet (never had
any excuse to do so yet). However, I've seen that, unlike i386, amd64
does have a PC-relative addressing mode. I'd assume the assembler would
usually use it to try to avoid these problems.

Reviewing the documentation, you have a point in that you probably need
to use amd64 addressing forms that allow this in order for the assembler
to be able to do the right thing. Perhaps the C compiler generally don't
if you don't use -fPIC. But the asm code used here seems to only use
constant displacements when loading memory addresses, which means the
assembler should be able to emit PC-relative addresses automatically, if
it knows what's good for it. And this *should* also go for any other
well-written amd64 asm code out there (even if written for Windows).

And so my excuse is that I was only concerned about the asm code...


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: the mingw-w64 toolchain

[Ove Kaaven]

Den 02. april 2011 23:16, skrev Stephen Kitt:
> The first strategy would allow the packages to make their way into the
> archive sooner, but I'm not sure what the FTP Masters' reaction would be to a
> NEW package relying on an "Arch: all" package to avoid bootstrapping itself.

They might be understanding about such bootstrapping - provided that all
the packages that depend on each other are all uploaded at once, so that
they all sit in NEW together, and can be checked and approved all at
once. I don't think this is the first time they've seen a bootstrap, and
I don't think it's productive to treat them like they're stupid.

> In addition to that, given the delays in the NEW queue just now, the second
> strategy would probably have the interesting side effect that the bootstrap
> packages would make it into the archive around the time Ubuntu unfreezes;
> having the bootstrap package at that point would allow the toolchain to be
> synced with Ubuntu. (Using the "Arch: all" shortcut would prevent that since
> Ubuntu packages are always rebuilt from source.)

All that would be Ubuntu's problem. If they have absolutely no way to
manually build a Debian package ever, then there's no reason for anybody
to even try to save them from themselves, as such ineptitude would
ultimately doom them no matter what. I would rather assume they know better.

> Thus I'd recommend the second strategy.

Well, neither argument seems convincing, and I believe it would also
have the interesting side effect of delaying Wine updates longer...

> If the packaging meets your requirements, would it be possible for me to
> join the wine party on Alioth and push my package to a git repository there?

The mingw packaging probably do not belong there. And when it comes to
wine-gecko, it probably won't be necessary since I made my own package
long ago. We'll see when the time comes.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d97d5f1.6040...@arcticnet.no

Re: Multiarch question

[Ove Kaaven]

Den 09. juni 2011 12:18, skrev Michael Wild:
> Hi all
> 
> I have a question concerning multiarch [1,2]. From what I read it is
> conceivable to have something like this on a system:
> 
> /usr/{lib,include}/i386-linux-gnu
> /usr/{lib,include}/x86_64-linux-gnu
> /usr/{lib,include}/x86_64-kfreebsd-gnu
> /usr/{lib,include}/sparc64-linux-gnu

I think only lib is addressed by multiarch at present, include dirs
aren't. Until cross-compilation is addressed in the spec, headers should
follow normal cross-compilation rules (/usr/$arch/include).

Ref: http://lists.debian.org/debian-devel/2011/04/msg01003.html

> Particularly, the case where both linux and kfreebsd directories are
> present is of interest. How would one tell gcc to use the foreign kernel?

gcc doesn't use a kernel. Do you mean cross-compilation? Multiarch
doesn't explicitly address ways to use foreign arches, so you would
cross-compile exactly the same way as before. (You do know how a
cross-compiler is configured, right?)

In general, it's *native* compilation that would change; libs would be
installed into /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH)
instead of plain /usr/lib (and some fields would be added to
debian/control, of course). If that's done, users will be able to
install packages from foreign arches in parallel with the same packages
for their native arches, if they like. Not much else would change.

I suppose that a (native) linker might want to look in /usr/lib/$arch in
addition to plain /usr/lib. Debian's toolchain probably do now.

> The background of this question is that at the moment Clang is
> completely broken w.r.t. multiarch and I'm looking into fixing it.

Well, maybe you should say what the problem is...


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4df10c27.5020...@arcticnet.no

Re: When is DAM approval supposed to happen?

[Ove Kaaven]

On Fri, 12 Jan 2001, Julian Gilbey wrote:

> On Fri, Jan 12, 2001 at 09:33:11AM +0200, Eray Ozkural (exa) wrote:
> > Hi,
> > 
> > It's already been a month and counting for DAM approval of my application.
> > I'd like to close some bugs with high severity on my packages, but
> > the fact that I don't have a debian account effectively prevents me
> > from doing so because it's a difficult thing to get every upload sponsored.
> > 
> > How does DAM approval occur?
> 
> When James has an opportunity.  He's been unable to do so recently for
> personal reasons but will be back on track soon.  (Details were posted
> to -private.)

But that doesn't help wondering people very much, we only get subscribed
to debian-private *after* DAM approval, right? (And I didn't see any
archive...)

Re: When is DAM approval supposed to happen?

[Ove Kaaven]

On Sat, 13 Jan 2001, Eric Dorland wrote:

> I've actually just taken a look at the applicants list
>  and it appears that today the DAM has
> apprently started creating accounts again today. Unfortunately, the six
> lucky people have apparently jumped the queue, and been rushed through
> the process, since they were all approved by their AMs in the last two
> weeks (most in the last two days!). I'm not sure why these six have been
> so fortunate and this hardly seems fair to a lot of people who have been
> waiting months for approval. I don't want this to degenerate into a
> deluge of flames, I'm honestly just curious and I don'ty think anyone
> likes it when someone cuts in line ahead of them.

Well, I was among the ones approved now... if it makes you feel any
better, at least I had been waiting for DAM approval a month and a half...
(and yes, my AM was also tbm (Martin Michlmayr)... though I'm the
maintainer of a relatively big package also...)

deleting uploads via queue

[Ove Kaaven]

I've packaged and uploaded gmime packages (libgmime0 and libgmime-dev),
but since auric was down, I had uploaded it into the queue daemon on
samosa. Now the daemon installed my stuff into ftp-master (auric), but I
just discovered that I put the wrong section into libgmime0 (it should be
libs, but it contains devel). And since the files in ftp-master's incoming
is owned by troup because of the queue daemon, I can't just rm these and
upload anew... I suppose I could file a bugreport if the ftp maintainers
add the package with the wrong section override, but I'd rather not cause
them extra work with my misguided upload if I can help it... so how would
I remove this package from incoming?

Re: deleting uploads via queue

[Ove Kaaven]

On Tue, 6 Feb 2001, Julian Gilbey wrote:

> On Mon, Feb 05, 2001 at 11:46:26PM +0100, Ove Kaaven wrote:
> > I've packaged and uploaded gmime packages (libgmime0 and libgmime-dev),
> > but since auric was down, I had uploaded it into the queue daemon on
> > samosa. Now the daemon installed my stuff into ftp-master (auric), but I
> > just discovered that I put the wrong section into libgmime0 (it should be
> > libs, but it contains devel). And since the files in ftp-master's incoming
> > is owned by troup because of the queue daemon, I can't just rm these and
> > upload anew... I suppose I could file a bugreport if the ftp maintainers
> > add the package with the wrong section override, but I'd rather not cause
> > them extra work with my misguided upload if I can help it... so how would
> > I remove this package from incoming?
> 
> Once a package has been uploaded for more than about 60 seconds, don't
> try replacing it with a new package with the same version number.
> Just upload a new version with the correct information.  Incidentally,
> I don't know whether katie bothers looking at the information in the
> package itself; I know the old dinstall didn't.  Have a look at the
> overrides files on ftp-master.  (I don't off-hand remember where they
> are kept, though.)

But it's not in the overrides file yet... it's a completely new package,
that was the point of this... if it wasn't new, the section in the debs
wouldn't matter much, but for new packages, the section information in the
new package would be valuable for the ftp maintainers that add it to the
override, I think... and I didn't want them to add it to the wrong section
first and then force them to change it later... would uploading a new
version be sensible for complete new packages that has never before been
in debian (except for incoming, obviously)?

package naming

[Ove Kaaven]

Are there any docs with guidelines on package naming? I need to package
some dependencies, one of which is the MetaKit portable embedded database
library (http://www.equi4.com/metakit/). The build process gives me
libmk4.so.0.0.0, libmk4tcl.so.0.0.0, and optionally libmk4py.so.0.0.0
(they don't seem to have considered library versioning in their
"portability" or something). The upstream version is 2.0.1. So, what
should I call this package?

Alternatives seem to be:

libmk40
libmk4
libmetakit40
libmetakit4
libmetakit0
libmetakit
metakit0
metakit

or maybe something else?

(of course with a -dev package to go with it, not sure if I want to split
up the tcl and python stuff into their own packages too, since I'm not
particularly interested in this lib, it's just a dependency not in debian
yet...)

Re: package naming

[Ove Kaaven]

On Thu, 15 Feb 2001, Ingo Saitz wrote:

> MoiN
> 
> On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven wrote:
> > Are there any docs with guidelines on package naming?
> 
> See the packaging manual, Section 11.3.

There's no such section in the packaging manual. But maybe you're
referring to policy manual... well, I looked in policy before, but didn't
find it before... the "Files" chapter was a pretty non-obvious location
for a package nomenclature rule.

Oh well, now I know where it is for *next* time, at least...

Re: Policy and conffile editing

[Ove Kaaven]

On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote:

> If you really think you want to change this automatically, you can ask the 
> squid maintainer to remove /etc/squid.conf from his conffiles.

If it's necessary to remove it from conffiles in order to edit it from a
script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat
edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by
update-mime) violates this policy.

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Michael Beattie wrote:

> On Sun, Feb 25, 2001 at 09:26:55PM -0500, Matt Zimmerman wrote:
> > In the current crafty (17.13-3) these files are conffiles (look in
> > debian/conffiles or debian/crafty.conffiles), which means that they will 
> > only
> > overwrite the existing versions if they have not been modified or the user
> > requests it.
> 
> and the user would be insane to request it... perhaps you should install
> them to doc/crafty/examples, and use postinst to check if they should be
> upgraded?  if so, mv them to the proper location in /var.
> 
> same thing is done for ppp's provider peer/chatscript files.

But that's a policy violation (13.3)

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Josip Rodin wrote:

> On Mon, Feb 26, 2001 at 10:43:03AM +0100, Ove Kaaven wrote:
> > > > In the current crafty (17.13-3) these files are conffiles (look in
> > > > debian/conffiles or debian/crafty.conffiles), which means that they 
> > > > will only
> > > > overwrite the existing versions if they have not been modified or the 
> > > > user
> > > > requests it.
> > > 
> > > and the user would be insane to request it... perhaps you should install
> > > them to doc/crafty/examples, and use postinst to check if they should be
> > > upgraded?  if so, mv them to the proper location in /var.
> > > 
> > > same thing is done for ppp's provider peer/chatscript files.
> > 
> > But that's a policy violation (13.3)
> 
> What ppp does with /etc/{ppp/peers,chatscripts}/provider is not a policy
> violation.

Maybe you misunderstood what I was referring to... of course changing or
messing with them isn't, but generating/installing them from e.g.
/usr/share/doc/foo/examples is a violation, according to 13.3.

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Julian Gilbey wrote:

> On Mon, Feb 26, 2001 at 10:43:03AM +0100, Ove Kaaven wrote:
> > > and the user would be insane to request it... perhaps you should install
> > > them to doc/crafty/examples, and use postinst to check if they should be
> > > upgraded?  if so, mv them to the proper location in /var.
> > > 
> > > same thing is done for ppp's provider peer/chatscript files.
> > 
> > But that's a policy violation (13.3)
> 
> No it isn't.  They are being treated as "configuration files".

Nothing in doc/ can be tagged as configuration files, as far as I know.

> Please read that section again.

Did you? 13.3 isn't the config file policy, it's the /usr/share/doc
policy. I interpret the last paragraph as forbidding what he was saying,
provided a postinst script qualifies as "any program".

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Josip Rodin wrote:

> On Mon, Feb 26, 2001 at 01:23:47PM +0100, Josip Rodin wrote:
> > 
> > It does not violate 13.3 because at the time the package is newly installed,
> > /usr/share/doc/ppp/examples/* exists.
> 
> ...so the system administrator won't get a chance to delete them and won't 
> cause the program (the script) to break. That's the rationale behind that
> policy section, it seems.

Plausible argument, but I seem to recall discussions of scenarios where
the sysadmin wants /usr/share/doc so un-badly that it will never exist and
will never be installed, e.g. by using some kind of dpkg feature to avoid
installation of these directories. Can't hurt to be prepared for that kind
of thing? Maybe policy should be clarified here whether maintainer scripts
need apply or not...

Re: keeping files from one version to the other.

[Ove Kaaven]

On Tue, 27 Feb 2001, Michael Beattie wrote:

> On Mon, Feb 26, 2001 at 01:27:41PM +0100, Ove Kaaven wrote:
> > > No it isn't.  They are being treated as "configuration files".
> > 
> > Nothing in doc/ can be tagged as configuration files, as far as I know.
> > 
> > > Please read that section again.
> > 
> > Did you? 13.3 isn't the config file policy, it's the /usr/share/doc
> > policy. I interpret the last paragraph as forbidding what he was saying,
> > provided a postinst script qualifies as "any program".
> 
> 
> Where in the goddamned hell did you interpret that I said files in
> /usr/share/doc/* should be included in conffiles ?!??!?!?
> 

That wasn't a reply to you...

Re: keeping files from one version to the other.

[Ove Kaaven]

On Tue, 27 Feb 2001, Michael Beattie wrote:

> On Mon, Feb 26, 2001 at 01:37:40PM +0100, Ove Kaaven wrote:
> > > 
> > > Where in the goddamned hell did you interpret that I said files in
> > > /usr/share/doc/* should be included in conffiles ?!??!?!?
> > > 
> > 
> > That wasn't a reply to you...
> 
> I dont care. I brought up the point, and you said it was against policy.

I talked about the doc section of policy (13.3), Julian Gilbey started
talking about config files; hence the logical implication for the
sufficiently argumentative (me): Julian Gilbey was talking about config
files in doc/. It didn't have anything to do with anything *you* said, but
what he said, and so it wasn't a reply to you. Simple as that.

Re: keeping files from one version to the other.

[Ove Kaaven]

On Tue, 27 Feb 2001, Michael Beattie wrote:

> On Mon, Feb 26, 2001 at 01:48:06PM +0100, Ove Kaaven wrote:
> > 
> > I talked about the doc section of policy (13.3), Julian Gilbey started
> > talking about config files; hence the logical implication for the
> > sufficiently argumentative (me): Julian Gilbey was talking about config
> > files in doc/. It didn't have anything to do with anything *you* said, but
> > what he said, and so it wasn't a reply to you. Simple as that.
> 
> Beg to differ..

Why? You said to copy the files from doc and to where they belong, nowhere
did you say that the config files would stay in doc or anything. Then I
pointed at the doc part of policy, and I got a reply not-from-you that
said something about treating them as config files when I was talking
about /usr/share/doc. So the reply wasn't directed at you, isn't that
clear enough? Typically my remarks can be interpreted in many negative
ways, but I don't quite see how that mail can be interpreted as targeting
*you*, especially when I said that it didn't, and who it did target,
whether I'm mistaken in what I said or not.

This isn't a very constructive thing to argue anyway...

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Julian Gilbey wrote:

> On Mon, Feb 26, 2001 at 01:48:06PM +0100, Ove Kaaven wrote:
> > I talked about the doc section of policy (13.3), Julian Gilbey started
> > talking about config files; hence the logical implication for the
> > sufficiently argumentative (me): Julian Gilbey was talking about config
> > files in doc/. It didn't have anything to do with anything *you* said, but
> > what he said, and so it wasn't a reply to you. Simple as that.
> 
> Whereas, in reality, I was talking about copying an example
> configuration file from doc to its proper location.

OK, but that certainly wasn't very clear from "treated as configuration
files"...

Re: building binary-only package with different name?

[Ove Kaaven]

On Tue, 27 Feb 2001, Peter van Rossum wrote:

> Yes, of course, and that is what I did. But the actual question was:
> how do I get dpkg-buildpackage to give the potato version a different
> *name*? Just renaming the files gives problems with the signature on
> the .changes/.dsc files.

If you're just going to put these on the webpage, why would you even need
the .changes file? (And the .dsc is only for the source package, so you
don't need that for the potato build either)

I'd put the potato and woody build in different directories, then I
wouldn't need to rename, but if you don't want to, I don't see why you
can't rename the potato build and drop the .changes file.

Re: building binary-only package with different name?

[Ove Kaaven]

On Tue, 27 Feb 2001, Peter van Rossum wrote:

> On Tue, Feb 27, 2001 at 01:56:29PM +0100, Ove Kaaven wrote:
> > If you're just going to put these on the webpage, why would you even need
> > the .changes file? (And the .dsc is only for the source package, so you
> > don't need that for the potato build either)
> > 
> > I'd put the potato and woody build in different directories, then I
> > wouldn't need to rename, but if you don't want to, I don't see why you
> > can't rename the potato build and drop the .changes file.
> 
> That's certainly a valid question. In fact, I lied :-) I don't want
> to put them just on the web page, I also want to keep them (both) in
> my local tree of packages and be able to install and de-install them at
> will with dpkg or apt. That's the real reason I want to have different names.

dpkg-scanpackages don't need the .changes file either. I have an apt-able
http repository for my potato packages and I didn't need to put any
.changes in there.

Re: Library packaging

[Ove Kaaven]

On Sat, 3 Mar 2001, Sam Couter wrote:

> I tried to use the electric-fence and dmalloc packages as examples to
> follow. Neither are named libwhatever, both contain shared objects. dmalloc
> has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does
> have a .so symlink, but it's also only an old policy version.

For yet another example, look at debauch, which does pretty much exactly
what you want to do... (and it seems to give that lintian warning too,
hmm.)

Re: variable path names in manpages

[Ove Kaaven]

On Thu, 10 May 2001, Manfred Wassmann wrote:

> I'm currently writing a manpage which is to be used in a Debian package,
> but not exclusively.  To be most flexible I want to use variables for path
> names that are expanded at build time.  Is there any standard or
> recommended way implement this?  

If you're using autoconf, you can have a prog.1.in file that you can have
configure process just like all those Makefile.in files to generate a
prog.1 along with the Makefiles. (wine uses this technique)

Re: using conditionals in autoconf/automake

[Ove Kaaven]

On Wed, 23 May 2001, Gustavo Noronha Silva wrote:

> I need help with stuff regarding a configure.in and a Makefile.am, I'm
> stucked trying to find a way to make the 'make install' command
> conditionally install some files.

Well, here's what one of my projects do:

configure.in:
...
AC_CHECK_LIB(ncurses, initscr)
AM_CONDITIONAL(HAVE_LIBNCURSES, test "$ac_cv_lib_ncurses_initscr" = yes)
...

Makefile.am:
AUTOMAKE_OPTIONS = foreign
if HAVE_LIBNCURSES
NCURSES_CLIENT = ncurses-client
else
NCURSES_CLIENT =
endif
bin_PROGRAMS = $(NCURSES_CLIENT) ...other-clients...
...

Re: Fwd: ITP: glib2, gtk2, inti

[Ove Kaaven]

On Fri, 1 Jun 2001, Michèl Alexandre Salim wrote:

> > IANAD yet but wanting to get up to speed on the
> > upcoming GNOME 2 platform, I wanted to start
> > programming in Gtk+ 1.3.x / Inti. They are not
> > available as Debian packages so far so I guess I
> > will
> > package them myself.
> > 
> > Note that the Glib/GTK+ packages will be temporary,
> > if
> > anyone think it should go to the Debian tree then if
> > Ben is willing I will hand them over.

I know that at least *I* would like to have those packages (I could even
sponsor them if Ben won't).

(By the way, that'd help Debian get closer to the coveted full UTF-8
support, too, as discussed elsewhere, heh...)

Re: license question and problems

[Ove Kaaven]

On Wed, 13 Jun 2001, Muhammad Hussain Yusuf wrote:

> The license for babel is: 
> 
> 
> This software is provided on an "as is" basis, and without warranty of
> any  kind, including but not limited to any implied warranty of
> merchantability  or fitness for a particular purpose.
> 
> In no event shall the authors or the University of Arizona be liable for 
> any direct, indirect, incidental, special, or consequential damages
> arising from use or distribution of this software. The University of Arizona
> also shall not be liable for any claim against any user of this program by
> any third party.
> 
> (That's it!)

That is the disclaimer (warranty) part (normally last paragraph) of a
standard BSD or X11 license text, not the license part. The license part
goes like "Permission is hereby granted, free of charge..." blah blah. If
you don't have that part, you don't have a license at all, and hence can't
redistribute.

> 1) Is the above license OK for Debian?
> 2) If so, is it OK to go ahead if I do not get a reply from the authors?

No, you need a license.

> 3) The new gdis  package also depends on the Debian povray package, which is 
> in
> non-free: I assume that my gdis package will therefore also have to go
> in non-free?

Or contrib.

Re: Conflict with debian/files

[Ove Kaaven]

On Wed, 13 Jun 2001, Brett Cundal wrote:

> I'm using dh_movefiles, which uses a package file called
> ".files", or "files" which applies to the main package only. This
> appears to conflict with (I think) dpkg-genchanges, which clobbers
> debian/files with some information about the built packages. So the next
> time the package is built it fails because dh_movefiles can't find the files
> specified in the new debian/files...

Usually, there are two circumstances:

1. A multi-package source, in which case you'd use ".files", not
"files" (or at least I do)

2. A single-package source, in which case you don't use dh_movefiles
(you'd install directly to debian/ instead of debian/tmp)

In neither case do you need "files", so there's no *real* problem.
At best, the bugreport should be severity wishlist, in my opinion.

Re: Conflict with debian/files

[Ove Kaaven]

On Wed, 13 Jun 2001, Brett Cundal wrote:

> That's correct, except dh_movefiles will look for debian/files whether you
> want it to or not... if there's no debian/mainpackage.files it will try
> debian/files which will be present after a build and will cause problems on
> the next build...

Hmm. OK, but not if you call dh_clean. The install target of my packages's
rules files calls dh_clean, hence files will be deleted before make
install, and dh_movefiles only makes sense after make install...
So, still a wishlist bug in my opinion.

library soversion

[Ove Kaaven]

I have a library package at version 2.01, and the soversion in it is 0.0.0
(seems upstream hadn't heard about library versioning). Now, I'm
considering packaging a new upstream version (2.3.4, still in prerelease
though), but they *still* haven't heard about library versioning, so
compiling the new source still just yields 0.0.0. And the new version is
binary-incompatible with the old release (some C++ classes changed).

What course of action is recommended here? I guess that perhaps I could
hack the upstream makefiles to add some library version, but then which
version to use? Or just rename the library? Hmm... or simply drop the old
version, since I seem to maintain all the packages that currently depend
on it anyway?

Re: binary-all packaging

[Ove Kaaven]

On Wed, 27 Jun 2001, Robert Millan wrote:

> # Build architecture-independent files here.
> binary-indep: build install
> # We have nothing to do by default.
> 
> # Build architecture-dependent files here.
> binary-arch: build install

Where's all the commands to build the package?

Try something like this (from a Arch: all package I have)

# Build architecture-independent files here.
binary-indep: install
dh_testdir
dh_testroot
dh_installdocs
dh_installchangelogs ChangeLog
dh_link
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb

# Build architecture-dependent files here.
binary-arch: build install

binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure

Re: i can't find my /etc/*.conf files

[Ove Kaaven]

On Fri, 3 Aug 2001, Pratik Sinha wrote:

> i tried packaging cups

To my knowledge, cups is already packaged, isn't it? Why not check out the
existing packaging then?

Re: When is DAM approval supposed to happen?

[Ove Kaaven]

On Fri, 12 Jan 2001, Julian Gilbey wrote:

> On Fri, Jan 12, 2001 at 09:33:11AM +0200, Eray Ozkural (exa) wrote:
> > Hi,
> > 
> > It's already been a month and counting for DAM approval of my application.
> > I'd like to close some bugs with high severity on my packages, but
> > the fact that I don't have a debian account effectively prevents me
> > from doing so because it's a difficult thing to get every upload sponsored.
> > 
> > How does DAM approval occur?
> 
> When James has an opportunity.  He's been unable to do so recently for
> personal reasons but will be back on track soon.  (Details were posted
> to -private.)

But that doesn't help wondering people very much, we only get subscribed
to debian-private *after* DAM approval, right? (And I didn't see any
archive...)


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

Re: When is DAM approval supposed to happen?

[Ove Kaaven]

On Sat, 13 Jan 2001, Eric Dorland wrote:

> I've actually just taken a look at the applicants list
>  and it appears that today the DAM has
> apprently started creating accounts again today. Unfortunately, the six
> lucky people have apparently jumped the queue, and been rushed through
> the process, since they were all approved by their AMs in the last two
> weeks (most in the last two days!). I'm not sure why these six have been
> so fortunate and this hardly seems fair to a lot of people who have been
> waiting months for approval. I don't want this to degenerate into a
> deluge of flames, I'm honestly just curious and I don'ty think anyone
> likes it when someone cuts in line ahead of them.

Well, I was among the ones approved now... if it makes you feel any
better, at least I had been waiting for DAM approval a month and a half...
(and yes, my AM was also tbm (Martin Michlmayr)... though I'm the
maintainer of a relatively big package also...)


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

deleting uploads via queue

[Ove Kaaven]

I've packaged and uploaded gmime packages (libgmime0 and libgmime-dev),
but since auric was down, I had uploaded it into the queue daemon on
samosa. Now the daemon installed my stuff into ftp-master (auric), but I
just discovered that I put the wrong section into libgmime0 (it should be
libs, but it contains devel). And since the files in ftp-master's incoming
is owned by troup because of the queue daemon, I can't just rm these and
upload anew... I suppose I could file a bugreport if the ftp maintainers
add the package with the wrong section override, but I'd rather not cause
them extra work with my misguided upload if I can help it... so how would
I remove this package from incoming?


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

Re: deleting uploads via queue

[Ove Kaaven]

On Tue, 6 Feb 2001, Julian Gilbey wrote:

> On Mon, Feb 05, 2001 at 11:46:26PM +0100, Ove Kaaven wrote:
> > I've packaged and uploaded gmime packages (libgmime0 and libgmime-dev),
> > but since auric was down, I had uploaded it into the queue daemon on
> > samosa. Now the daemon installed my stuff into ftp-master (auric), but I
> > just discovered that I put the wrong section into libgmime0 (it should be
> > libs, but it contains devel). And since the files in ftp-master's incoming
> > is owned by troup because of the queue daemon, I can't just rm these and
> > upload anew... I suppose I could file a bugreport if the ftp maintainers
> > add the package with the wrong section override, but I'd rather not cause
> > them extra work with my misguided upload if I can help it... so how would
> > I remove this package from incoming?
> 
> Once a package has been uploaded for more than about 60 seconds, don't
> try replacing it with a new package with the same version number.
> Just upload a new version with the correct information.  Incidentally,
> I don't know whether katie bothers looking at the information in the
> package itself; I know the old dinstall didn't.  Have a look at the
> overrides files on ftp-master.  (I don't off-hand remember where they
> are kept, though.)

But it's not in the overrides file yet... it's a completely new package,
that was the point of this... if it wasn't new, the section in the debs
wouldn't matter much, but for new packages, the section information in the
new package would be valuable for the ftp maintainers that add it to the
override, I think... and I didn't want them to add it to the wrong section
first and then force them to change it later... would uploading a new
version be sensible for complete new packages that has never before been
in debian (except for incoming, obviously)?


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

package naming

[Ove Kaaven]

Are there any docs with guidelines on package naming? I need to package
some dependencies, one of which is the MetaKit portable embedded database
library (http://www.equi4.com/metakit/). The build process gives me
libmk4.so.0.0.0, libmk4tcl.so.0.0.0, and optionally libmk4py.so.0.0.0
(they don't seem to have considered library versioning in their
"portability" or something). The upstream version is 2.0.1. So, what
should I call this package?

Alternatives seem to be:

libmk40
libmk4
libmetakit40
libmetakit4
libmetakit0
libmetakit
metakit0
metakit

or maybe something else?

(of course with a -dev package to go with it, not sure if I want to split
up the tcl and python stuff into their own packages too, since I'm not
particularly interested in this lib, it's just a dependency not in debian
yet...)


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

Re: package naming

[Ove Kaaven]

On Thu, 15 Feb 2001, Ingo Saitz wrote:

> MoiN
> 
> On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven wrote:
> > Are there any docs with guidelines on package naming?
> 
> See the packaging manual, Section 11.3.

There's no such section in the packaging manual. But maybe you're
referring to policy manual... well, I looked in policy before, but didn't
find it before... the "Files" chapter was a pretty non-obvious location
for a package nomenclature rule.

Oh well, now I know where it is for *next* time, at least...


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

Re: Policy and conffile editing

[Ove Kaaven]

On Sat, 24 Feb 2001 [EMAIL PROTECTED] wrote:

> If you really think you want to change this automatically, you can ask the 
> squid maintainer to remove /etc/squid.conf from his conffiles.

If it's necessary to remove it from conffiles in order to edit it from a
script in /usr/sbin, then both sgml-base (/etc/sgml/transitional.cat
edited by install-sgmlcatalog) and mime-support (/etc/mailcap edited by
update-mime) violates this policy.


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Michael Beattie wrote:

> On Sun, Feb 25, 2001 at 09:26:55PM -0500, Matt Zimmerman wrote:
> > In the current crafty (17.13-3) these files are conffiles (look in
> > debian/conffiles or debian/crafty.conffiles), which means that they will only
> > overwrite the existing versions if they have not been modified or the user
> > requests it.
> 
> and the user would be insane to request it... perhaps you should install
> them to doc/crafty/examples, and use postinst to check if they should be
> upgraded?  if so, mv them to the proper location in /var.
> 
> same thing is done for ppp's provider peer/chatscript files.

But that's a policy violation (13.3)


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Josip Rodin wrote:

> On Mon, Feb 26, 2001 at 10:43:03AM +0100, Ove Kaaven wrote:
> > > > In the current crafty (17.13-3) these files are conffiles (look in
> > > > debian/conffiles or debian/crafty.conffiles), which means that they will only
> > > > overwrite the existing versions if they have not been modified or the user
> > > > requests it.
> > > 
> > > and the user would be insane to request it... perhaps you should install
> > > them to doc/crafty/examples, and use postinst to check if they should be
> > > upgraded?  if so, mv them to the proper location in /var.
> > > 
> > > same thing is done for ppp's provider peer/chatscript files.
> > 
> > But that's a policy violation (13.3)
> 
> What ppp does with /etc/{ppp/peers,chatscripts}/provider is not a policy
> violation.

Maybe you misunderstood what I was referring to... of course changing or
messing with them isn't, but generating/installing them from e.g.
/usr/share/doc/foo/examples is a violation, according to 13.3.


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Julian Gilbey wrote:

> On Mon, Feb 26, 2001 at 10:43:03AM +0100, Ove Kaaven wrote:
> > > and the user would be insane to request it... perhaps you should install
> > > them to doc/crafty/examples, and use postinst to check if they should be
> > > upgraded?  if so, mv them to the proper location in /var.
> > > 
> > > same thing is done for ppp's provider peer/chatscript files.
> > 
> > But that's a policy violation (13.3)
> 
> No it isn't.  They are being treated as "configuration files".

Nothing in doc/ can be tagged as configuration files, as far as I know.

> Please read that section again.

Did you? 13.3 isn't the config file policy, it's the /usr/share/doc
policy. I interpret the last paragraph as forbidding what he was saying,
provided a postinst script qualifies as "any program".


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Josip Rodin wrote:

> On Mon, Feb 26, 2001 at 01:23:47PM +0100, Josip Rodin wrote:
> > 
> > It does not violate 13.3 because at the time the package is newly installed,
> > /usr/share/doc/ppp/examples/* exists.
> 
> ...so the system administrator won't get a chance to delete them and won't 
> cause the program (the script) to break. That's the rationale behind that
> policy section, it seems.

Plausible argument, but I seem to recall discussions of scenarios where
the sysadmin wants /usr/share/doc so un-badly that it will never exist and
will never be installed, e.g. by using some kind of dpkg feature to avoid
installation of these directories. Can't hurt to be prepared for that kind
of thing? Maybe policy should be clarified here whether maintainer scripts
need apply or not...


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Tue, 27 Feb 2001, Michael Beattie wrote:

> On Mon, Feb 26, 2001 at 01:27:41PM +0100, Ove Kaaven wrote:
> > > No it isn't.  They are being treated as "configuration files".
> > 
> > Nothing in doc/ can be tagged as configuration files, as far as I know.
> > 
> > > Please read that section again.
> > 
> > Did you? 13.3 isn't the config file policy, it's the /usr/share/doc
> > policy. I interpret the last paragraph as forbidding what he was saying,
> > provided a postinst script qualifies as "any program".
> 
> 
> Where in the goddamned hell did you interpret that I said files in
> /usr/share/doc/* should be included in conffiles ?!??!?!?
> 

That wasn't a reply to you...


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Tue, 27 Feb 2001, Michael Beattie wrote:

> On Mon, Feb 26, 2001 at 01:37:40PM +0100, Ove Kaaven wrote:
> > > 
> > > Where in the goddamned hell did you interpret that I said files in
> > > /usr/share/doc/* should be included in conffiles ?!??!?!?
> > > 
> > 
> > That wasn't a reply to you...
> 
> I dont care. I brought up the point, and you said it was against policy.

I talked about the doc section of policy (13.3), Julian Gilbey started
talking about config files; hence the logical implication for the
sufficiently argumentative (me): Julian Gilbey was talking about config
files in doc/. It didn't have anything to do with anything *you* said, but
what he said, and so it wasn't a reply to you. Simple as that.


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Tue, 27 Feb 2001, Michael Beattie wrote:

> On Mon, Feb 26, 2001 at 01:48:06PM +0100, Ove Kaaven wrote:
> > 
> > I talked about the doc section of policy (13.3), Julian Gilbey started
> > talking about config files; hence the logical implication for the
> > sufficiently argumentative (me): Julian Gilbey was talking about config
> > files in doc/. It didn't have anything to do with anything *you* said, but
> > what he said, and so it wasn't a reply to you. Simple as that.
> 
> Beg to differ..

Why? You said to copy the files from doc and to where they belong, nowhere
did you say that the config files would stay in doc or anything. Then I
pointed at the doc part of policy, and I got a reply not-from-you that
said something about treating them as config files when I was talking
about /usr/share/doc. So the reply wasn't directed at you, isn't that
clear enough? Typically my remarks can be interpreted in many negative
ways, but I don't quite see how that mail can be interpreted as targeting
*you*, especially when I said that it didn't, and who it did target,
whether I'm mistaken in what I said or not.

This isn't a very constructive thing to argue anyway...


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

Re: keeping files from one version to the other.

[Ove Kaaven]

On Mon, 26 Feb 2001, Julian Gilbey wrote:

> On Mon, Feb 26, 2001 at 01:48:06PM +0100, Ove Kaaven wrote:
> > I talked about the doc section of policy (13.3), Julian Gilbey started
> > talking about config files; hence the logical implication for the
> > sufficiently argumentative (me): Julian Gilbey was talking about config
> > files in doc/. It didn't have anything to do with anything *you* said, but
> > what he said, and so it wasn't a reply to you. Simple as that.
> 
> Whereas, in reality, I was talking about copying an example
> configuration file from doc to its proper location.

OK, but that certainly wasn't very clear from "treated as configuration
files"...


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

Re: building binary-only package with different name?

[Ove Kaaven]

On Tue, 27 Feb 2001, Peter van Rossum wrote:

> Yes, of course, and that is what I did. But the actual question was:
> how do I get dpkg-buildpackage to give the potato version a different
> *name*? Just renaming the files gives problems with the signature on
> the .changes/.dsc files.

If you're just going to put these on the webpage, why would you even need
the .changes file? (And the .dsc is only for the source package, so you
don't need that for the potato build either)

I'd put the potato and woody build in different directories, then I
wouldn't need to rename, but if you don't want to, I don't see why you
can't rename the potato build and drop the .changes file.


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

Re: building binary-only package with different name?

[Ove Kaaven]

On Tue, 27 Feb 2001, Peter van Rossum wrote:

> On Tue, Feb 27, 2001 at 01:56:29PM +0100, Ove Kaaven wrote:
> > If you're just going to put these on the webpage, why would you even need
> > the .changes file? (And the .dsc is only for the source package, so you
> > don't need that for the potato build either)
> > 
> > I'd put the potato and woody build in different directories, then I
> > wouldn't need to rename, but if you don't want to, I don't see why you
> > can't rename the potato build and drop the .changes file.
> 
> That's certainly a valid question. In fact, I lied :-) I don't want
> to put them just on the web page, I also want to keep them (both) in
> my local tree of packages and be able to install and de-install them at
> will with dpkg or apt. That's the real reason I want to have different names.

dpkg-scanpackages don't need the .changes file either. I have an apt-able
http repository for my potato packages and I didn't need to put any
.changes in there.


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

Re: Library packaging

[Ove Kaaven]

On Sat, 3 Mar 2001, Sam Couter wrote:

> I tried to use the electric-fence and dmalloc packages as examples to
> follow. Neither are named libwhatever, both contain shared objects. dmalloc
> has no .so symlink, just libdmalloc.so.4.2 or something. electric-fence does
> have a .so symlink, but it's also only an old policy version.

For yet another example, look at debauch, which does pretty much exactly
what you want to do... (and it seems to give that lintian warning too,
hmm.)


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

Re: variable path names in manpages

[Ove Kaaven]

On Thu, 10 May 2001, Manfred Wassmann wrote:

> I'm currently writing a manpage which is to be used in a Debian package,
> but not exclusively.  To be most flexible I want to use variables for path
> names that are expanded at build time.  Is there any standard or
> recommended way implement this?  

If you're using autoconf, you can have a prog.1.in file that you can have
configure process just like all those Makefile.in files to generate a
prog.1 along with the Makefiles. (wine uses this technique)


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

Re: using conditionals in autoconf/automake

[Ove Kaaven]

On Wed, 23 May 2001, Gustavo Noronha Silva wrote:

> I need help with stuff regarding a configure.in and a Makefile.am, I'm
> stucked trying to find a way to make the 'make install' command
> conditionally install some files.

Well, here's what one of my projects do:

configure.in:
...
AC_CHECK_LIB(ncurses, initscr)
AM_CONDITIONAL(HAVE_LIBNCURSES, test "$ac_cv_lib_ncurses_initscr" = yes)
...

Makefile.am:
AUTOMAKE_OPTIONS = foreign
if HAVE_LIBNCURSES
NCURSES_CLIENT = ncurses-client
else
NCURSES_CLIENT =
endif
bin_PROGRAMS = $(NCURSES_CLIENT) ...other-clients...
...


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

Re: Fwd: ITP: glib2, gtk2, inti

[Ove Kaaven]

On Fri, 1 Jun 2001, Michèl Alexandre Salim wrote:

> > IANAD yet but wanting to get up to speed on the
> > upcoming GNOME 2 platform, I wanted to start
> > programming in Gtk+ 1.3.x / Inti. They are not
> > available as Debian packages so far so I guess I
> > will
> > package them myself.
> > 
> > Note that the Glib/GTK+ packages will be temporary,
> > if
> > anyone think it should go to the Debian tree then if
> > Ben is willing I will hand them over.

I know that at least *I* would like to have those packages (I could even
sponsor them if Ben won't).

(By the way, that'd help Debian get closer to the coveted full UTF-8
support, too, as discussed elsewhere, heh...)


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

Re: license question and problems

[Ove Kaaven]

On Wed, 13 Jun 2001, Muhammad Hussain Yusuf wrote:

> The license for babel is: 
> 
> 
> This software is provided on an "as is" basis, and without warranty of
> any  kind, including but not limited to any implied warranty of
> merchantability  or fitness for a particular purpose.
> 
> In no event shall the authors or the University of Arizona be liable for 
> any direct, indirect, incidental, special, or consequential damages
> arising from use or distribution of this software. The University of Arizona
> also shall not be liable for any claim against any user of this program by
> any third party.
> 
> (That's it!)

That is the disclaimer (warranty) part (normally last paragraph) of a
standard BSD or X11 license text, not the license part. The license part
goes like "Permission is hereby granted, free of charge..." blah blah. If
you don't have that part, you don't have a license at all, and hence can't
redistribute.

> 1) Is the above license OK for Debian?
> 2) If so, is it OK to go ahead if I do not get a reply from the authors?

No, you need a license.

> 3) The new gdis  package also depends on the Debian povray package, which is in
> non-free: I assume that my gdis package will therefore also have to go
> in non-free?

Or contrib.


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

Re: Conflict with debian/files

[Ove Kaaven]

On Wed, 13 Jun 2001, Brett Cundal wrote:

> I'm using dh_movefiles, which uses a package file called
> ".files", or "files" which applies to the main package only. This
> appears to conflict with (I think) dpkg-genchanges, which clobbers
> debian/files with some information about the built packages. So the next
> time the package is built it fails because dh_movefiles can't find the files
> specified in the new debian/files...

Usually, there are two circumstances:

1. A multi-package source, in which case you'd use ".files", not
"files" (or at least I do)

2. A single-package source, in which case you don't use dh_movefiles
(you'd install directly to debian/ instead of debian/tmp)

In neither case do you need "files", so there's no *real* problem.
At best, the bugreport should be severity wishlist, in my opinion.


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

Re: Conflict with debian/files

[Ove Kaaven]

On Wed, 13 Jun 2001, Brett Cundal wrote:

> That's correct, except dh_movefiles will look for debian/files whether you
> want it to or not... if there's no debian/mainpackage.files it will try
> debian/files which will be present after a build and will cause problems on
> the next build...

Hmm. OK, but not if you call dh_clean. The install target of my packages's
rules files calls dh_clean, hence files will be deleted before make
install, and dh_movefiles only makes sense after make install...
So, still a wishlist bug in my opinion.


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

library soversion

[Ove Kaaven]

I have a library package at version 2.01, and the soversion in it is 0.0.0
(seems upstream hadn't heard about library versioning). Now, I'm
considering packaging a new upstream version (2.3.4, still in prerelease
though), but they *still* haven't heard about library versioning, so
compiling the new source still just yields 0.0.0. And the new version is
binary-incompatible with the old release (some C++ classes changed).

What course of action is recommended here? I guess that perhaps I could
hack the upstream makefiles to add some library version, but then which
version to use? Or just rename the library? Hmm... or simply drop the old
version, since I seem to maintain all the packages that currently depend
on it anyway?


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

Re: binary-all packaging

[Ove Kaaven]

On Wed, 27 Jun 2001, Robert Millan wrote:

> # Build architecture-independent files here.
> binary-indep: build install
> # We have nothing to do by default.
> 
> # Build architecture-dependent files here.
> binary-arch: build install

Where's all the commands to build the package?

Try something like this (from a Arch: all package I have)

# Build architecture-independent files here.
binary-indep: install
dh_testdir
dh_testroot
dh_installdocs
dh_installchangelogs ChangeLog
dh_link
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb

# Build architecture-dependent files here.
binary-arch: build install

binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure


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

strange problems with testing

[Ove Kaaven]

I want to fix bug #106690, which only exists in the testing distribution,
not in the unstable distribution. (I admit that it's probably partly my
fault that the bug had a chance of occurring in the first place, I should
have added some Depends or Conflicts lines or something, but now I can't
fix it)

Problem is:
flightgear 0.7.6 is in testing, it depends on simgear0 0.0.14 and plib1 1.2
flightgear 0.7.8 is in unstable, it depends on simgear0 0.0.16 and plib 1.4

simgear0 0.0.16 is in testing and unstable, it is built against plib 1.4
plib1 1.2 is in testing, plib1 1.4 is in unstable
(and I consider the plib maintainer somewhat clueless, 1.4 should probably 
have become plib2 or something, since it's a revamped API, but anyway...)

The bottom line is, the current combination of packages in testing does
not work, and for some reason the packages in unstable just doesn't move
into testing. If they did move, that would solve the problem (and I can
try to be more vigilant with depends and conflicts next time), and as far
as I can tell, there's nothing preventing them from it, but they don't.

Does anyone have a clue why the working packages won't move into testing,
and what I can do about it?


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

Re: Tight versions depends

[Ove Kaaven]

On Sat, 13 Jul 2002, Jeff Bailey wrote:

> I'm having some trouble I can't seem to find the answer to.  Mailutils
> creates both 'mailutils-pop3d', and 'libmailutils0'.  The two need to
> tightly depend on one another, since the ABI hasn't stabilized yet.
> 
> In my control file I have:
> 
> Depends: ${shlibs:Depends}, netbase, libmailutils0 (= ${Source-Version})
> 
> However, Lintian throws up on me for:
> 
> E: mailutils-imap4d: package-has-a-duplicate-relation libmailutils0, libmailutils0 
>(= 20020713-1)
> 
> The generate mailutils.pop3d-substvars has:
> 
> shlibs:Depends=libc6 (>= 2.2.4-4), libgdbmg1, libmailutils0, libpam0g (>= 0.72-1)
> 
> What's the best fix for this?  It seems I need to get dh_shlibdeps to
> not put in libmailutils0 somehow.

Maybe it's better to make dh_shlibdeps generate the correct dependency in
the first place. Say, do you want ALL packages built against
libmailutils0-dev to have a tight version dependency (not just your pop3d
package)? If so, you can make it so by adding the -V option to your
dh_makeshlibdeps command. If not, perhaps you can get it done by making a
debian/shlibs.local file that contains the dependency you need when you
run dh_shlibdeps.


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

Re: Compiling C++ without -g

[Ove Kaaven]

On Sat, 3 Aug 2002, Matt Zimmerman wrote:

> On Sat, Aug 03, 2002 at 03:00:41PM +0100, Will Newton wrote:
> 
> > Is there a way to prevent autoconf from appending "-g" to every g++ command 
> > line? I really want to reduce the diskspace and CPU time required to build my 
> > package, but autoconf seems to assume if you have g++ you have to have "-g" 
> > also.
> > 
> > e.g.
> > AC_PROG_CXX calls _AC_PROG_CXX_G which if successful unconditionally appends 
> > "-g" to the command line.
> 
> Try passing CFLAGS to configure, e.g. CFLAGS="-O2" ./configure...

And if that doesn't work, try CXXFLAGS (which applies to C++ code)...
although in some of my packages I've opted to override CXXFLAGS for the
subsequent make (make CXXFLAGS="...") rather than for the configure
(CXXFLAGS="..." ./configure), for some reason I can't remember.


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

strange problems with testing

[Ove Kaaven]

I want to fix bug #106690, which only exists in the testing distribution,
not in the unstable distribution. (I admit that it's probably partly my
fault that the bug had a chance of occurring in the first place, I should
have added some Depends or Conflicts lines or something, but now I can't
fix it)

Problem is:
flightgear 0.7.6 is in testing, it depends on simgear0 0.0.14 and plib1 1.2
flightgear 0.7.8 is in unstable, it depends on simgear0 0.0.16 and plib 1.4

simgear0 0.0.16 is in testing and unstable, it is built against plib 1.4
plib1 1.2 is in testing, plib1 1.4 is in unstable
(and I consider the plib maintainer somewhat clueless, 1.4 should probably 
have become plib2 or something, since it's a revamped API, but anyway...)

The bottom line is, the current combination of packages in testing does
not work, and for some reason the packages in unstable just doesn't move
into testing. If they did move, that would solve the problem (and I can
try to be more vigilant with depends and conflicts next time), and as far
as I can tell, there's nothing preventing them from it, but they don't.

Does anyone have a clue why the working packages won't move into testing,
and what I can do about it?

Re: Tight versions depends

[Ove Kaaven]

On Sat, 13 Jul 2002, Jeff Bailey wrote:

> I'm having some trouble I can't seem to find the answer to.  Mailutils
> creates both 'mailutils-pop3d', and 'libmailutils0'.  The two need to
> tightly depend on one another, since the ABI hasn't stabilized yet.
> 
> In my control file I have:
> 
> Depends: ${shlibs:Depends}, netbase, libmailutils0 (= ${Source-Version})
> 
> However, Lintian throws up on me for:
> 
> E: mailutils-imap4d: package-has-a-duplicate-relation libmailutils0, 
> libmailutils0 (= 20020713-1)
> 
> The generate mailutils.pop3d-substvars has:
> 
> shlibs:Depends=libc6 (>= 2.2.4-4), libgdbmg1, libmailutils0, libpam0g (>= 
> 0.72-1)
> 
> What's the best fix for this?  It seems I need to get dh_shlibdeps to
> not put in libmailutils0 somehow.

Maybe it's better to make dh_shlibdeps generate the correct dependency in
the first place. Say, do you want ALL packages built against
libmailutils0-dev to have a tight version dependency (not just your pop3d
package)? If so, you can make it so by adding the -V option to your
dh_makeshlibdeps command. If not, perhaps you can get it done by making a
debian/shlibs.local file that contains the dependency you need when you
run dh_shlibdeps.


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

Re: Compiling C++ without -g

[Ove Kaaven]

On Sat, 3 Aug 2002, Matt Zimmerman wrote:

> On Sat, Aug 03, 2002 at 03:00:41PM +0100, Will Newton wrote:
> 
> > Is there a way to prevent autoconf from appending "-g" to every g++ command 
> > line? I really want to reduce the diskspace and CPU time required to build 
> > my 
> > package, but autoconf seems to assume if you have g++ you have to have "-g" 
> > also.
> > 
> > e.g.
> > AC_PROG_CXX calls _AC_PROG_CXX_G which if successful unconditionally 
> > appends 
> > "-g" to the command line.
> 
> Try passing CFLAGS to configure, e.g. CFLAGS="-O2" ./configure...

And if that doesn't work, try CXXFLAGS (which applies to C++ code)...
although in some of my packages I've opted to override CXXFLAGS for the
subsequent make (make CXXFLAGS="...") rather than for the configure
(CXXFLAGS="..." ./configure), for some reason I can't remember.

Re: How can I upload package into woody?

[Ove Kaaven]

On Sun, 20 Oct 2002, Takashi Okamoto wrote:

> Hi,
> 
> I'm very shameful that I can't upload my package into woody.

Don't be, nobody except the release manager and security team can. New
packages and normal updates must go into sid (unstable).

> When I used stable instead of woody, I got same result.

If you really wanted to do it, you'd have to use proposed-updates, then
pray that the release manager thinks your update is worth putting into
woody proper at the next point release (not likely)