I'm adopting Qtella and I'm in need of a sponsor. It's a simple package
with a tiny diff, available here:
http://bignachos.com/~nelson/debian/
Thanks,
Brian
--
People said I was dumb, but I proved them!
msg07865/pgp0.pgp
Description: PGP signature
I have a bug report against php-gtk:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164619
The error occured when a new version of php was uploaded to unstable.
The error is:
Warning: php-gtk: Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20020429
PHP c
I have a bug report against php-gtk:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164619
The error occured when a new version of php was uploaded to unstable.
The error is:
Warning: php-gtk: Unable to initialize module
Module compiled with debug=0, thread-safety=0 module API=20020429
PHP c
On Thu, Nov 14, 2002 at 10:06:29AM -0600, Steve Langasek wrote:
SL> Tcl is Tcl, so I wouldn't follow its example for, well... anything.
Except that Alicq is written entirely in Tcl, so I have to at least
respect the choice made by other Tcl programs maintainers.
SL> I imagine python stores ever
On Fri, Nov 15, 2002 at 12:07:45AM +0900, Junichi Uekawa wrote:
JU> Yes, I was quite wondering that too, and people tend to disagree on
JU> that point, and some people tend to be walking around filing RC
JU> bugs on this regard.
RC bug would definitely be an overkill, I have shown that FHS is
a
On Thu, Nov 14, 2002 at 04:54:40PM +0200, Dmitry Borodaenko wrote:
> On Thu, Nov 14, 2002 at 02:25:15PM +, Mark Howard wrote:
> MH> Java programs/libraries (arch independent bytecode) all go in
> MH> /usr/share/java, as per policy. I guess your situation isn't all
> MH> that different, so th
On Thu, Nov 14, 2002 at 10:06:29AM -0600, Steve Langasek wrote:
SL> Tcl is Tcl, so I wouldn't follow its example for, well... anything.
Except that Alicq is written entirely in Tcl, so I have to at least
respect the choice made by other Tcl programs maintainers.
SL> I imagine python stores ever
On Fri, Nov 15, 2002 at 12:07:45AM +0900, Junichi Uekawa wrote:
JU> Yes, I was quite wondering that too, and people tend to disagree on
JU> that point, and some people tend to be walking around filing RC
JU> bugs on this regard.
RC bug would definitely be an overkill, I have shown that FHS is
a
> Putting script libraries into /usr/lib does not break systems mounted in
> such manner, it only increases number of files that should be stored
> separately for each architecture.
Yes, I was quite wondering that too, and people tend to disagree
on that point, and some people tend to be walking
On Thu, Nov 14, 2002 at 02:25:15PM +, Mark Howard wrote:
MH> Java programs/libraries (arch independent bytecode) all go in
MH> /usr/share/java, as per policy. I guess your situation isn't all
MH> that different, so they should go in /usr/share, IMHO.
That shows that Debian interpreted langu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 14 November 2002 07:16, Karolina Lindqvist wrote:
> Wednesday 13 November 2002 12.18 skrev Paul Cupis:
> > It should be called noteedit_2.0.16.orig.tar.gz, per the packaging
> > manual.
>
> Meaning the only modification is to change the na
On Thu, Nov 14, 2002 at 11:55:08AM +0100, Sven Luther wrote:
DB>> I can't come to agreement with Alicq upstream about where is a
DB>> proper place to put Alicq optional modules (written in Tcl). FHS
DB>> 2.1 contains self-contradictory recommendations on that issue: on
DB>> one hand, .tcl files
On Thu, 2002-11-14 at 10:21, Dmitry Borodaenko wrote:
> I can't come to agreement with Alicq upstream about where is a proper
> place to put Alicq optional modules (written in Tcl). FHS 2.1 contains
> self-contradictory recommendations on that issue: on one hand, .tcl
> files are arch-independent a
On Thu, Nov 14, 2002 at 04:54:40PM +0200, Dmitry Borodaenko wrote:
> On Thu, Nov 14, 2002 at 02:25:15PM +, Mark Howard wrote:
> MH> Java programs/libraries (arch independent bytecode) all go in
> MH> /usr/share/java, as per policy. I guess your situation isn't all
> MH> that different, so th
> Putting script libraries into /usr/lib does not break systems mounted in
> such manner, it only increases number of files that should be stored
> separately for each architecture.
Yes, I was quite wondering that too, and people tend to disagree
on that point, and some people tend to be walking
On Thu, Nov 14, 2002 at 02:25:15PM +, Mark Howard wrote:
MH> Java programs/libraries (arch independent bytecode) all go in
MH> /usr/share/java, as per policy. I guess your situation isn't all
MH> that different, so they should go in /usr/share, IMHO.
That shows that Debian interpreted langu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 14 November 2002 07:16, Karolina Lindqvist wrote:
> Wednesday 13 November 2002 12.18 skrev Paul Cupis:
> > It should be called noteedit_2.0.16.orig.tar.gz, per the packaging
> > manual.
>
> Meaning the only modification is to change the na
On Thu, Nov 14, 2002 at 11:55:08AM +0100, Sven Luther wrote:
DB>> I can't come to agreement with Alicq upstream about where is a
DB>> proper place to put Alicq optional modules (written in Tcl). FHS
DB>> 2.1 contains self-contradictory recommendations on that issue: on
DB>> one hand, .tcl files
On Thu, 2002-11-14 at 10:21, Dmitry Borodaenko wrote:
> I can't come to agreement with Alicq upstream about where is a proper
> place to put Alicq optional modules (written in Tcl). FHS 2.1 contains
> self-contradictory recommendations on that issue: on one hand, .tcl
> files are arch-independent a
On Thu, Nov 14, 2002 at 12:21:59PM +0200, Dmitry Borodaenko wrote:
> I can't come to agreement with Alicq upstream about where is a proper
> place to put Alicq optional modules (written in Tcl). FHS 2.1 contains
> self-contradictory recommendations on that issue: on one hand, .tcl
> files are arch-
I can't come to agreement with Alicq upstream about where is a proper
place to put Alicq optional modules (written in Tcl). FHS 2.1 contains
self-contradictory recommendations on that issue: on one hand, .tcl
files are arch-independent and thus belong to /usr/share, OTOH
/usr/share is supposed to c
On Thu, Nov 14, 2002 at 12:21:59PM +0200, Dmitry Borodaenko wrote:
> I can't come to agreement with Alicq upstream about where is a proper
> place to put Alicq optional modules (written in Tcl). FHS 2.1 contains
> self-contradictory recommendations on that issue: on one hand, .tcl
> files are arch-
I can't come to agreement with Alicq upstream about where is a proper
place to put Alicq optional modules (written in Tcl). FHS 2.1 contains
self-contradictory recommendations on that issue: on one hand, .tcl
files are arch-independent and thus belong to /usr/share, OTOH
/usr/share is supposed to c
Wednesday 13 November 2002 12.18 skrev Paul Cupis:
> It can be modified. It should be unchanged. Being unchanged has beneifts
> including but not limited to allowing users to verify the original tgz with
> upstream and clearly showing (in the diff.gz) what changes were made during
> packaging. If
Wednesday 13 November 2002 22.30 skrev Roger Leigh:
> The `clean' rule is run before the build (by dpkg-buildpackage), so I
> would do
>
> find . -name '*.moc' | xargs rm -f
>
> to remove the .moc files. If they can easily be regenerated, I would
> ask upstream to remove them from the tarball (bu
25 matches
Mail list logo
