Packages with different build dirs than source dirs

[Morgon Kanter]

Are there any packages that do this? In order to fully build gnu-crypto 
successfully, I will need to be able to have a seperate build directory 
than the source directory. I have been having trouble setting this up 
properly in debian/rules however, and I was wondering if there were 
any packages that do this that I could use as an example.

Morgon
-- 
"Man is the only creature capable of hating itself" -- Governor of Japan 
in The End of Evangelion


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

Re: Packages with different build dirs than source dirs

[Gergely Nagy]

> Are there any packages that do this? In order to fully build gnu-crypto 
> successfully, I will need to be able to have a seperate build directory 
> than the source directory. I have been having trouble setting this up 
> properly in debian/rules however, and I was wondering if there were 
> any packages that do this that I could use as an example.

Have a look at - for example - `thy'. That does this in a quite easy
way. If gnu-crypto is using autoconf+automake, or something similar,
doing this is rather trivial, methinks.


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

Packaging buggy programs

[Neil McGovern]

Hi all,

I was wondering over this (partially hypothetical) question:

If I find a program that contains quite a few bugs (causes crashing of
the program, no external data loss), should it be packaged?

The program I found contained too many bugs to be considered for
packaging (IMO), but should, in general, someone wait until the program
becomes stable within itself?

Many thanks,
Neil McGovern
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5


pgp0.pgp
Description: PGP signature

Re: Packaging buggy programs

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 06:30:26PM +0100, Neil McGovern wrote:

> I was wondering over this (partially hypothetical) question:
> 
> If I find a program that contains quite a few bugs (causes crashing of the
> program, no external data loss), should it be packaged?
> 
> The program I found contained too many bugs to be considered for packaging
> (IMO), but should, in general, someone wait until the program becomes
> stable within itself?

For unstable, if you are willing to support it, then I would say it is OK.
Supporting it means accepting bug reports and dealing with them (fixing or
forwarding), among other things.

For testing (and through testing, stable), others (such as the security
team) will need to support your package as well, so if you do not feel it is
in a releasable state, do not allow it to enter testing.

-- 
 - mdz


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

Re: Packaging buggy programs

[Thomas Viehmann]

Neil McGovern wrote:
> If I find a program that contains quite a few bugs (causes crashing of
> the program, no external data loss), should it be packaged?
IMHO only programs that are of use by reasonable many people should be submitted
to the debian archive. Thus, if the buggyness of the program renders it severely
less useful (or, for that matter, if there are more stable alternatives),
consider not submitting it.

Cheers

T.


pgp0.pgp
Description: PGP signature

Re: Packaging library examples (binaries/source)

[Andreas Rottmann]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Andreas Rottmann wrote:
>>>However - some of these apps are useful in their own right (such as a
>>>data viewer or conversion tool).  Is it ok to place a symlink from
>>>/usr/bin to /usr/share/libfoo-apps/bin so that users can invoke these
>>>apps directly?
>> I'd go for just putting them into /usr/bin (watch out for namespace
>> collisions/pollution, though) and not install the source at all. A
>> user needing the source could always 'apt-get source libfoo-apps'.
>
> Hmm. The mail was just about a month old yet unanswered, yes?
>
I tend to lag a bit behind with some messages on -devel :-)

> Just to add another cent:
>
> While it is common practice to put binaries which are not needed to
> be invoked directly into /usr/lib/libfoo or /usr/lib/package, and it
> can be argued that examples may belong in this category, no answer
> to this question is complete without mentioning that arch-dependent
> files in /usr/share seems to be in conflict of FHS and thus in
> violation of debian policy.
>
Indeed, stupid me has overlooked that really important issue.

Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!


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

How to deal with bogus bug reports (#197352)

[Johannes Rohr]

Dear all,

some days ago someone filed an obviously bogus bug against a package
I'm co-maintaining (nautilus-media, bug #197352), i.e. he complained
about being unable to install the gnome-core metapackage on hppa
because nautilus-media on which gnome-core depends is unavailable on
that arch. 

The reason is that the build-depends cannot be satisfied, as gstreamer
continues to FTBFS on hppa and a number of other arches.

This is quite obviously not the fault of my innocent little
package. 

But still, one Debian user felt the urge to file a "critical" bug
against nautilus-media, justification: "breaks other packages". This
is of course nonsense. nautilus-media does not break anything, it is
just not there, yet -- without any fault of its own.

Now, what can I do with such a bug? In bugzilla, one could simply tag
it as "RESOLVED, INVALID" to leave a marker that the report itself was
the bug.

What is the generally accepted way within the "Debian culture" to deal
with such reports? Do I close the bug right away? Do I downgrade it?
Do I reassign it (in this case to gstreamer)?

Thanks in advance!

Johannes
-- 
~/.signature under construction


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

Re: Packaging buggy programs

[Manoj Srivastava]

On Mon, 16 Jun 2003 18:30:26 +0100, Neil McGovern <[EMAIL PROTECTED]> said: 

> Hi all, I was wondering over this (partially hypothetical) question:

> If I find a program that contains quite a few bugs (causes crashing
> of the program, no external data loss), should it be packaged?

If you consider it worth while enough to spend your time doing
 it, there must be some value.

> The program I found contained too many bugs to be considered for
> packaging (IMO), but should, in general, someone wait until the
> program becomes stable within itself?

How can we find bugs if it is not tried out? 

It is up to you determine how buggy it is, and whether those
 bugs are serious enough to warrant placing it in experimental vs
 unstable. 

manoj
-- 
"The road to hell is paved with melting snowballs." --Larry Wall in
<[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Packages with different build dirs than source dirs

[Craig Small]

On Mon, Jun 16, 2003 at 12:30:45PM -0400, Morgon Kanter wrote:
> Are there any packages that do this? In order to fully build gnu-crypto 
> successfully, I will need to be able to have a seperate build directory 
> than the source directory. I have been having trouble setting this up 
> properly in debian/rules however, and I was wondering if there were 
> any packages that do this that I could use as an example.

So the .c and .h files are in directory "src" but you want the .o and the
binaries in a directory "build"?  Plenty do that, especially anything
that uses more than one database variety.  mnogosearch for example.

I do
 mkdir build-pgsql
 cd build-pgsql
 ../configure .

and

  $(MAKE) -C build-pgsql



-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>


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

Re: How to deal with bogus bug reports (#197352)

[Craig Small]

On Mon, Jun 16, 2003 at 10:43:25PM +0200, Johannes Rohr wrote:
> some days ago someone filed an obviously bogus bug against a package
> I'm co-maintaining (nautilus-media, bug #197352), i.e. he complained
> about being unable to install the gnome-core metapackage on hppa
> because nautilus-media on which gnome-core depends is unavailable on
> that arch. 

What you do is dependent on the maintainer and their philosophy.


> But still, one Debian user felt the urge to file a "critical" bug
> against nautilus-media, justification: "breaks other packages". This
> is of course nonsense. nautilus-media does not break anything, it is
> just not there, yet -- without any fault of its own.
That's a misuse of "breaks other packages".  For starters there is
dependencies, so that generally rules out using that justification.
Secondly as you say installing nautilus-media doesn't break gnome-core.

> What is the generally accepted way within the "Debian culture" to deal
> with such reports? Do I close the bug right away? Do I downgrade it?
> Do I reassign it (in this case to gstreamer)?
I'd close it.  At the very worse tag it wontfix and set it to normal.
But its not a real bug and should be closed.

  - Craig

-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>


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

Build non-free ncompress

[Kenneth Pronovici]

I know this question (or a similar one) comes up periodically both here
and on -devel.  Unfortunately, I have to ask it again, because I can't
find a complete solution to my problem.

Because I still use it, I adopted ncompress a few months ago when it was
orphaned.  I spent a night or two and closed all of the open bugs,
cleaned up its compile warnings, updated the manpages and brought the
packaging up to current standards.  Since there hasn't been an
"upstream" release in 10 years (!) or so, I'm essentially the upstream
maintainer now from Debian's perspective.  As a side-note, this package
is non-free because of issues surrounding the LZW patent, not because
its license is non-free.

Anyway, now that I've done all of this cleanup, I've realized that the
package won't move into testing until I build it on all of the
architectures it was built on for woody.  Right now, according to the
excuses list, I am missing alpha, arm, hppa, ia64, powerpc, s390 and
sparc.  I know that in order to take care of this, I will have to build
ncompress by hand on each of these architectures.  What I can't figure
out is exactly how to do that.

According to the machines list, I can get access to a machine running
sid for hppa, powerpc, sparc and mipsel.  This leaves alpha, arm, ia64
and s390 before ncompress can move into testing, and then also m68k and
mips before I can support all of the official architectures.

What am I supposed to do with all of those architectures for which no
sid environment exists?  I notice that some of the machines have
(+chroots) listed.  Is this the way I can build for sid on a machine
running woody?  If so, where can I find instructions on how to do it?

Thanks for the advice,

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp0.pgp
Description: PGP signature

Re: How to deal with bogus bug reports (#197352)

[Henrique de Moraes Holschuh]

On Mon, 16 Jun 2003, Johannes Rohr wrote:
> What is the generally accepted way within the "Debian culture" to deal
> with such reports? Do I close the bug right away? Do I downgrade it?
> Do I reassign it (in this case to gstreamer)?

You can reassign it with the priority and bug title changed to whatever you
find correct.  It is the "helpful samaritan" thing to do, since you have
actually figured out what was really breaking.

Or you can simply close it politely (mail the explanation to -done), and be
done with that. It is quite acceptable as well, especially if you didn't
have time to track down just what other package was really broken in the
first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Build non-free ncompress

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 06:19:21PM -0500, Kenneth Pronovici wrote:

> Because I still use it[...]

I have to ask...why? :-)

-- 
 - mdz


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

Re: Build non-free ncompress

[Kenneth Pronovici]

> > Because I still use it[...]
> 
> I have to ask...why? :-)

Well, I think you're poking fun at me, but I'm going to pretend that I
didn't notice and give you an answer anyway. :)

The main reason I took it is that my Cedar Backup package (not
officially in Debian) supports tar.Z backups and hence Suggests
ncompress.  It seemed contradictory for me to suggest ncompress but not
be willing to maintain it.

Besides that, though, I have two reasons to want ncompress: first, it
seems to be somewhat faster than gzip on large files (100MB+).  Second,
I don't think that gzip will generate portable .Z files, even though it
will read them.  Sometimes (though less and less frequently) I need that
for compatibility with non-Debian systems.  

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp0.pgp
Description: PGP signature

Re: Build non-free ncompress

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 06:19:21PM -0500, Kenneth Pronovici wrote:

> According to the machines list, I can get access to a machine running
> sid for hppa, powerpc, sparc and mipsel.  This leaves alpha, arm, ia64
> and s390 before ncompress can move into testing, and then also m68k and
> mips before I can support all of the official architectures.

Also, an emulator is available for s390 (hercules), which works fine for
small packages on a reasonably modern host, after taking a bit of time to
set it up with networking.

> What am I supposed to do with all of those architectures for which no sid
> environment exists?  I notice that some of the machines have (+chroots)
> listed.  Is this the way I can build for sid on a machine running woody?
> If so, where can I find instructions on how to do it?

Chroots are usually accessible with 'dchroot ' when and where
they are available.

This is one of the reasons why non-free sucks.

-- 
 - mdz


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

Re: Build non-free ncompress

[Joey Hess]

Kenneth Pronovici wrote:
> Anyway, now that I've done all of this cleanup, I've realized that the
> package won't move into testing until I build it on all of the
> architectures it was built on for woody.  Right now, according to the
> excuses list, I am missing alpha, arm, hppa, ia64, powerpc, s390 and
> sparc.  I know that in order to take care of this, I will have to build
> ncompress by hand on each of these architectures.  What I can't figure
> out is exactly how to do that.
> 
> According to the machines list, I can get access to a machine running
> sid for hppa, powerpc, sparc and mipsel.  This leaves alpha, arm, ia64
> and s390 before ncompress can move into testing, and then also m68k and
> mips before I can support all of the official architectures.
> 
> What am I supposed to do with all of those architectures for which no
> sid environment exists?  I notice that some of the machines have
> (+chroots) listed.  Is this the way I can build for sid on a machine
> running woody?  If so, where can I find instructions on how to do it?

If I were you I'd maybe build it on some of these architectures if I
felt motivated to do so, and then file a bug on ftp.debian.org to get
the old builds removed for the other architectures that are no longer
autobuilding non-free software. If they don't want to autobuild it, why
waste their CPU time and your time trying to do it manually. Ftp master
is generally responsive to such requests.

-- 
see shy jo


pgp0.pgp
Description: PGP signature

Re: Build non-free ncompress

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> As a side-note, this package
>is non-free because of issues surrounding the LZW patent, not because
>its license is non-free.

I've think that patent is about to expire.  (June 20?  I think I saw
it slashdotted within the past month.)  If you can confirm this, just
wait till then and move it to main.
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden


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

Re: Build non-free ncompress

[Thomas Viehmann]

Blars Blarson wrote:
> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>>As a side-note, this package
>>is non-free because of issues surrounding the LZW patent, not because
>>its license is non-free.
> I've think that patent is about to expire.  (June 20?  I think I saw
> it slashdotted within the past month.)  If you can confirm this, just
> wait till then and move it to main.
Unfortunately it seems that that's only true for very us-centric people, not Debian.

Cheers

T.



pgp0.pgp
Description: PGP signature

RFS: pose-skins - Skins for the PalmOS Emulator

[Juan Manuel García Molina]

Hi, mentors.

Few days ago I tried to convince you to upload pose, a Palm OS Emulator.

Today I pretend you to upload the skins for this emulator, a package called 
pose-skins.

The sources can be get by visiting:
http://www.superiodico.net/debian/upload/pose-skins/


And the package info comes here:

 Package: pose-skins
 Version: 1.9-1
 Section: contrib/otherosfs
 Priority: optional
 Architecture: all
 Depends: pose (>=3.5)
 Installed-Size: 7524
 Maintainer: Juan Manuel García Molina <[EMAIL PROTECTED]>
 Description: Skins for the PalmOS Emulator
  A generic skin is included in the pose package; use the skins in this
  package to make the emulator look like a specific device.


The list of changes in this version:

pose-skins (1.9-1) unstable; urgency=low

  * New upstream release.
  * New maintainer (Closes: #195374, #197696).
  * Changed download dir to sourceforge project page.
  * Clean example files from debian/ and minor changes.
  * Skins dir is now /usr/share/pose/skins (not /usr/share/pose/Skins).

 -- Juan Manuel García Molina <[EMAIL PROTECTED]>  Tue, 17 Jun 2003 
00:17:12 +0200


Thank you very much.

-- 
Juan Manuel  García Molina
   [EMAIL PROTECTED]


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

Re: Build non-free ncompress

[Kenneth Pronovici]

> > I've think that patent is about to expire.  (June 20?  I think I saw
> > it slashdotted within the past month.)  If you can confirm this, just
> > wait till then and move it to main.
> Unfortunately it seems that that's only true for very us-centric
> people, not Debian.

Yes - when I dug into this in April, it looked as if it wouldn't be
safe for non-free in Europe until at least 2004, and I'm not sure about
other places. 

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Personal Homepage: http://www.skyjammer.com/~pronovic/
"They that can give up essential liberty to obtain a little 
 temporary safety deserve neither liberty nor safety." 
  - Benjamin Franklin, Historical Review of Pennsylvania, 1759 


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

Re: Build non-free ncompress

[Kenneth Pronovici]

> Chroots are usually accessible with 'dchroot ' when and where
> they are available.

Got it.  I was able to do that on debussy for arm, and m68k on crest
(although it turns out m6k autobuilds at least some non-free already).

> This is one of the reasons why non-free sucks.

I understand now. :-)

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp0.pgp
Description: PGP signature

Re: Build non-free ncompress

[Kenneth Pronovici]

> If I were you I'd maybe build it on some of these architectures if I
> felt motivated to do so, and then file a bug on ftp.debian.org to get
> the old builds removed for the other architectures that are no longer
> autobuilding non-free software. If they don't want to autobuild it, why
> waste their CPU time and your time trying to do it manually. Ftp master
> is generally responsive to such requests.

I managed to build it on sparc, arm, powerpc, m68k, hppa and s390 -
which just leaves alpha and ia64.  I'll ask ftp-master to remove it from
those two architectures.

Thanks...

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp0.pgp
Description: PGP signature

unsubscribe

[pheret]

Packages with different build dirs than source dirs

[Morgon Kanter]

Are there any packages that do this? In order to fully build gnu-crypto 
successfully, I will need to be able to have a seperate build directory 
than the source directory. I have been having trouble setting this up 
properly in debian/rules however, and I was wondering if there were 
any packages that do this that I could use as an example.

Morgon
-- 
"Man is the only creature capable of hating itself" -- Governor of Japan 
in The End of Evangelion

Re: Packages with different build dirs than source dirs

[Gergely Nagy]

> Are there any packages that do this? In order to fully build gnu-crypto 
> successfully, I will need to be able to have a seperate build directory 
> than the source directory. I have been having trouble setting this up 
> properly in debian/rules however, and I was wondering if there were 
> any packages that do this that I could use as an example.

Have a look at - for example - `thy'. That does this in a quite easy
way. If gnu-crypto is using autoconf+automake, or something similar,
doing this is rather trivial, methinks.

Packaging buggy programs

[Neil McGovern]

Hi all,

I was wondering over this (partially hypothetical) question:

If I find a program that contains quite a few bugs (causes crashing of
the program, no external data loss), should it be packaged?

The program I found contained too many bugs to be considered for
packaging (IMO), but should, in general, someone wait until the program
becomes stable within itself?

Many thanks,
Neil McGovern
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5


pgp5BuQu9m43M.pgp
Description: PGP signature

Re: Packaging buggy programs

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 06:30:26PM +0100, Neil McGovern wrote:

> I was wondering over this (partially hypothetical) question:
> 
> If I find a program that contains quite a few bugs (causes crashing of the
> program, no external data loss), should it be packaged?
> 
> The program I found contained too many bugs to be considered for packaging
> (IMO), but should, in general, someone wait until the program becomes
> stable within itself?

For unstable, if you are willing to support it, then I would say it is OK.
Supporting it means accepting bug reports and dealing with them (fixing or
forwarding), among other things.

For testing (and through testing, stable), others (such as the security
team) will need to support your package as well, so if you do not feel it is
in a releasable state, do not allow it to enter testing.

-- 
 - mdz

Re: Packaging buggy programs

[Thomas Viehmann]

Neil McGovern wrote:
> If I find a program that contains quite a few bugs (causes crashing of
> the program, no external data loss), should it be packaged?
IMHO only programs that are of use by reasonable many people should be submitted
to the debian archive. Thus, if the buggyness of the program renders it severely
less useful (or, for that matter, if there are more stable alternatives),
consider not submitting it.

Cheers

T.


pgpAVEkZO80OJ.pgp
Description: PGP signature

Re: Packaging library examples (binaries/source)

[Andreas Rottmann]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Andreas Rottmann wrote:
>>>However - some of these apps are useful in their own right (such as a
>>>data viewer or conversion tool).  Is it ok to place a symlink from
>>>/usr/bin to /usr/share/libfoo-apps/bin so that users can invoke these
>>>apps directly?
>> I'd go for just putting them into /usr/bin (watch out for namespace
>> collisions/pollution, though) and not install the source at all. A
>> user needing the source could always 'apt-get source libfoo-apps'.
>
> Hmm. The mail was just about a month old yet unanswered, yes?
>
I tend to lag a bit behind with some messages on -devel :-)

> Just to add another cent:
>
> While it is common practice to put binaries which are not needed to
> be invoked directly into /usr/lib/libfoo or /usr/lib/package, and it
> can be argued that examples may belong in this category, no answer
> to this question is complete without mentioning that arch-dependent
> files in /usr/share seems to be in conflict of FHS and thus in
> violation of debian policy.
>
Indeed, stupid me has overlooked that really important issue.

Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!

How to deal with bogus bug reports (#197352)

[Johannes Rohr]

Dear all,

some days ago someone filed an obviously bogus bug against a package
I'm co-maintaining (nautilus-media, bug #197352), i.e. he complained
about being unable to install the gnome-core metapackage on hppa
because nautilus-media on which gnome-core depends is unavailable on
that arch. 

The reason is that the build-depends cannot be satisfied, as gstreamer
continues to FTBFS on hppa and a number of other arches.

This is quite obviously not the fault of my innocent little
package. 

But still, one Debian user felt the urge to file a "critical" bug
against nautilus-media, justification: "breaks other packages". This
is of course nonsense. nautilus-media does not break anything, it is
just not there, yet -- without any fault of its own.

Now, what can I do with such a bug? In bugzilla, one could simply tag
it as "RESOLVED, INVALID" to leave a marker that the report itself was
the bug.

What is the generally accepted way within the "Debian culture" to deal
with such reports? Do I close the bug right away? Do I downgrade it?
Do I reassign it (in this case to gstreamer)?

Thanks in advance!

Johannes
-- 
~/.signature under construction

Re: Packaging buggy programs

[Manoj Srivastava]

On Mon, 16 Jun 2003 18:30:26 +0100, Neil McGovern <[EMAIL PROTECTED]> said: 

> Hi all, I was wondering over this (partially hypothetical) question:

> If I find a program that contains quite a few bugs (causes crashing
> of the program, no external data loss), should it be packaged?

If you consider it worth while enough to spend your time doing
 it, there must be some value.

> The program I found contained too many bugs to be considered for
> packaging (IMO), but should, in general, someone wait until the
> program becomes stable within itself?

How can we find bugs if it is not tried out? 

It is up to you determine how buggy it is, and whether those
 bugs are serious enough to warrant placing it in experimental vs
 unstable. 

manoj
-- 
"The road to hell is paved with melting snowballs." --Larry Wall in
<[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Packages with different build dirs than source dirs

[Craig Small]

On Mon, Jun 16, 2003 at 12:30:45PM -0400, Morgon Kanter wrote:
> Are there any packages that do this? In order to fully build gnu-crypto 
> successfully, I will need to be able to have a seperate build directory 
> than the source directory. I have been having trouble setting this up 
> properly in debian/rules however, and I was wondering if there were 
> any packages that do this that I could use as an example.

So the .c and .h files are in directory "src" but you want the .o and the
binaries in a directory "build"?  Plenty do that, especially anything
that uses more than one database variety.  mnogosearch for example.

I do
 mkdir build-pgsql
 cd build-pgsql
 ../configure .

and

  $(MAKE) -C build-pgsql



-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>

Re: How to deal with bogus bug reports (#197352)

[Craig Small]

On Mon, Jun 16, 2003 at 10:43:25PM +0200, Johannes Rohr wrote:
> some days ago someone filed an obviously bogus bug against a package
> I'm co-maintaining (nautilus-media, bug #197352), i.e. he complained
> about being unable to install the gnome-core metapackage on hppa
> because nautilus-media on which gnome-core depends is unavailable on
> that arch. 

What you do is dependent on the maintainer and their philosophy.


> But still, one Debian user felt the urge to file a "critical" bug
> against nautilus-media, justification: "breaks other packages". This
> is of course nonsense. nautilus-media does not break anything, it is
> just not there, yet -- without any fault of its own.
That's a misuse of "breaks other packages".  For starters there is
dependencies, so that generally rules out using that justification.
Secondly as you say installing nautilus-media doesn't break gnome-core.

> What is the generally accepted way within the "Debian culture" to deal
> with such reports? Do I close the bug right away? Do I downgrade it?
> Do I reassign it (in this case to gstreamer)?
I'd close it.  At the very worse tag it wontfix and set it to normal.
But its not a real bug and should be closed.

  - Craig

-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>

Build non-free ncompress

[Kenneth Pronovici]

I know this question (or a similar one) comes up periodically both here
and on -devel.  Unfortunately, I have to ask it again, because I can't
find a complete solution to my problem.

Because I still use it, I adopted ncompress a few months ago when it was
orphaned.  I spent a night or two and closed all of the open bugs,
cleaned up its compile warnings, updated the manpages and brought the
packaging up to current standards.  Since there hasn't been an
"upstream" release in 10 years (!) or so, I'm essentially the upstream
maintainer now from Debian's perspective.  As a side-note, this package
is non-free because of issues surrounding the LZW patent, not because
its license is non-free.

Anyway, now that I've done all of this cleanup, I've realized that the
package won't move into testing until I build it on all of the
architectures it was built on for woody.  Right now, according to the
excuses list, I am missing alpha, arm, hppa, ia64, powerpc, s390 and
sparc.  I know that in order to take care of this, I will have to build
ncompress by hand on each of these architectures.  What I can't figure
out is exactly how to do that.

According to the machines list, I can get access to a machine running
sid for hppa, powerpc, sparc and mipsel.  This leaves alpha, arm, ia64
and s390 before ncompress can move into testing, and then also m68k and
mips before I can support all of the official architectures.

What am I supposed to do with all of those architectures for which no
sid environment exists?  I notice that some of the machines have
(+chroots) listed.  Is this the way I can build for sid on a machine
running woody?  If so, where can I find instructions on how to do it?

Thanks for the advice,

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp8U6PZxXlHM.pgp
Description: PGP signature

Re: How to deal with bogus bug reports (#197352)

[Henrique de Moraes Holschuh]

On Mon, 16 Jun 2003, Johannes Rohr wrote:
> What is the generally accepted way within the "Debian culture" to deal
> with such reports? Do I close the bug right away? Do I downgrade it?
> Do I reassign it (in this case to gstreamer)?

You can reassign it with the priority and bug title changed to whatever you
find correct.  It is the "helpful samaritan" thing to do, since you have
actually figured out what was really breaking.

Or you can simply close it politely (mail the explanation to -done), and be
done with that. It is quite acceptable as well, especially if you didn't
have time to track down just what other package was really broken in the
first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Build non-free ncompress

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 06:19:21PM -0500, Kenneth Pronovici wrote:

> Because I still use it[...]

I have to ask...why? :-)

-- 
 - mdz

Re: Build non-free ncompress

[Kenneth Pronovici]

> > Because I still use it[...]
> 
> I have to ask...why? :-)

Well, I think you're poking fun at me, but I'm going to pretend that I
didn't notice and give you an answer anyway. :)

The main reason I took it is that my Cedar Backup package (not
officially in Debian) supports tar.Z backups and hence Suggests
ncompress.  It seemed contradictory for me to suggest ncompress but not
be willing to maintain it.

Besides that, though, I have two reasons to want ncompress: first, it
seems to be somewhat faster than gzip on large files (100MB+).  Second,
I don't think that gzip will generate portable .Z files, even though it
will read them.  Sometimes (though less and less frequently) I need that
for compatibility with non-Debian systems.  

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgpRaDH0jyz9j.pgp
Description: PGP signature

Re: Build non-free ncompress

[Matt Zimmerman]

On Mon, Jun 16, 2003 at 06:19:21PM -0500, Kenneth Pronovici wrote:

> According to the machines list, I can get access to a machine running
> sid for hppa, powerpc, sparc and mipsel.  This leaves alpha, arm, ia64
> and s390 before ncompress can move into testing, and then also m68k and
> mips before I can support all of the official architectures.

Also, an emulator is available for s390 (hercules), which works fine for
small packages on a reasonably modern host, after taking a bit of time to
set it up with networking.

> What am I supposed to do with all of those architectures for which no sid
> environment exists?  I notice that some of the machines have (+chroots)
> listed.  Is this the way I can build for sid on a machine running woody?
> If so, where can I find instructions on how to do it?

Chroots are usually accessible with 'dchroot ' when and where
they are available.

This is one of the reasons why non-free sucks.

-- 
 - mdz

Re: Build non-free ncompress

[Joey Hess]

Kenneth Pronovici wrote:
> Anyway, now that I've done all of this cleanup, I've realized that the
> package won't move into testing until I build it on all of the
> architectures it was built on for woody.  Right now, according to the
> excuses list, I am missing alpha, arm, hppa, ia64, powerpc, s390 and
> sparc.  I know that in order to take care of this, I will have to build
> ncompress by hand on each of these architectures.  What I can't figure
> out is exactly how to do that.
> 
> According to the machines list, I can get access to a machine running
> sid for hppa, powerpc, sparc and mipsel.  This leaves alpha, arm, ia64
> and s390 before ncompress can move into testing, and then also m68k and
> mips before I can support all of the official architectures.
> 
> What am I supposed to do with all of those architectures for which no
> sid environment exists?  I notice that some of the machines have
> (+chroots) listed.  Is this the way I can build for sid on a machine
> running woody?  If so, where can I find instructions on how to do it?

If I were you I'd maybe build it on some of these architectures if I
felt motivated to do so, and then file a bug on ftp.debian.org to get
the old builds removed for the other architectures that are no longer
autobuilding non-free software. If they don't want to autobuild it, why
waste their CPU time and your time trying to do it manually. Ftp master
is generally responsive to such requests.

-- 
see shy jo


pgpahHH8plvoE.pgp
Description: PGP signature

Re: Build non-free ncompress

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> As a side-note, this package
>is non-free because of issues surrounding the LZW patent, not because
>its license is non-free.

I've think that patent is about to expire.  (June 20?  I think I saw
it slashdotted within the past month.)  If you can confirm this, just
wait till then and move it to main.
-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden