On 1/15/07, Michael Gilbert [EMAIL PROTECTED] wrote:
...
the user did not initiate the action. azureus went out and checked for
updates, then told the user that they should update. and it does this every
time the application starts up unless the user chooses to update (at that
point, i don't
I attempted a quick update of Azureus to 2.5.0.2. It has a new
dependency on Java 1.5 (2.5.0.0 only required Java 1.4) and due to
that, I'm going to delay Azureus 2.5.0.2 until etch is released.
Cheers,
Shaun
javac -source 1.5 -target 1.5 -encoding ISO-8859-1 -nowarn -classpath
On 1/14/07, Manoj Srivastava [EMAIL PROTECTED] wrote:
...
If azereus is going out and adding things to the users home
dir without the users knowledge, that would be one thing. But in this
case the users has initiated the action -- and trying to save the
user from themselves is not
On 1/13/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
Please change the delay value in the ATmega8 section of your
avrdude.conf from 6 to 10 for the flash memory, and from 10 to 20
for the eeprom memory area.
I made both these changes, but the flash write is still timing out:
avrdude:
On 1/15/07, Shaun Jackman [EMAIL PROTECTED] wrote:
On 1/13/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
Please change the delay value in the ATmega8 section of your
avrdude.conf from 6 to 10 for the flash memory, and from 10 to 20
for the eeprom memory area.
I made both these changes
On 1/14/07, Manoj Srivastava [EMAIL PROTECTED] wrote:
...
If azereus is going out and adding things to the users home
dir without the users knowledge, that would be one thing. But in this
case the users has initiated the action -- and trying to save the
user from themselves is not
On 1/14/07, Linas Žvirblis [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Gilbert wrote:
is there a policy on whether an executable is permitted to update
itself?
Not sure about The Policy, but I can see a lot of reasons why this
should not be done:
1. The
On 1/14/07, Sam Morris [EMAIL PROTECTED] wrote:
How does the azureus package work around the fact that only root can write
to the package files?
The updated software is stored in ~/.Azureus/.
BTW, if you and the maintainer cannot agree on this you can reassign the
bug to tech-ctte, but that
On 1/14/07, Linas Žvirblis [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Gilbert wrote:
is there a policy on whether an executable is permitted to update
itself?
Not sure about The Policy, but I can see a lot of reasons why this
should not be done:
1. The
Great! Thanks for the fix. I'll try it out on Monday.
Cheers,
Shaun
On 1/13/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
Well, it could probably handle the error more gracefully -- but it
would fail anyway.
Sigh. That's yet another case where Atmel has silently modified
parameters in their XML
retitle 406583 libswt-mozilla-gtk-3.2-jni: Conflicts with libswt3.2-gtk-jni
tag 406583 confirmed sid
retitle 401570 libswt-gtk-3.2-jni: Conflicts with libswt3.2-gtk-jni
thanks
libswt-mozilla-gtk-3.2-jni is from the swt-gtk source package.
libswt3.2-gtk-jni is from the eclipse source package.
The
On 1/8/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
If you run avrdude with -, it will dump the programmer
communication to stderr. Similarly, at the end of appnote AVR068,
there's a description how to produce a trace of the STK500
communication. You might try comparing the relevant part
On 1/12/07, Shaun Jackman [EMAIL PROTECTED] wrote:
I used avrdude - to capture the offending packet. I'll be happy to
provide any other information that's needed to help troubleshoot this.
...
avrdude: jtagmkII_recv():
...
avrdude: Recv: . [88] . [13] . [80]
...
avrdude: jtagmkII_recv
retitle 406583 libswt-mozilla-gtk-3.2-jni: Conflicts with libswt3.2-gtk-jni
tag 406583 confirmed sid
retitle 401570 libswt-gtk-3.2-jni: Conflicts with libswt3.2-gtk-jni
thanks
libswt-mozilla-gtk-3.2-jni is from the swt-gtk source package.
libswt3.2-gtk-jni is from the eclipse source package.
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 11 Jan 2007 14:44:26 -0700
Source: eagle
Binary: eagle-data eagle
Architecture: source i386 all
Version: 4.16-4
Distribution: unstable
Urgency: low
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed-By: Shaun Jackman [EMAIL
package azureus
retitle 340998 libswt3.2-gtk-java: Should not conflict with libswt-gtk-3.2-java
reassign 340998 libswt3.2-gtk-java
thanks
The -java packages should not conflict. Only the -jni packages should
conflict. See below.
On 1/10/07, robin putters [EMAIL PROTECTED] wrote:
I´ve come up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 9 Jan 2007 12:59:29 -0700
Source: monotone
Binary: monotone monotone-doc monotone-server
Architecture: source i386 all
Version: 0.31-4
Distribution: unstable
Urgency: low
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed
On 1/9/07, Alan Ezust [EMAIL PROTECTED] wrote:
Ah, you maintain another java package! that's good to know.
So azureus does not require java 1.5, I take it?
I see under depends, it requires java2-runtime and
java-virtual-machine. Those are (I think) for 1.4?
jedit needs java 1.5, so should I
I attempted to use the AVR JTAG ICE mkII and the ATmega8 with both
avrdude and AVR Studio 4.12 Service Pack 2. Neither worked. I upgraded
to AVR Studio 4.12 Service Pack 4 and upgraded the firmware of the AVR
JTAG ICE mkII and now both avrdude and AVR Studio work.
Cheers,
Shaun
Hi Jürgen,
The JTAG ICE mkII is more expensive, but I already own one to program
the ATmega64 I use in other projects. So, it's also a convenient ISP
programmer.
It seems though that I need to qualify what I said earlier about using
the JTAG ICE mKII to program the ATmega8. Once I upgraded the
I'm attempting to use avrdude 5.3.1 to program a ATmega8 using a AVR
JTAG ICE mkII. To help troubleshooting, the same hardware setup works
in AVR Studio. Reading the Device ID and verifying the flash works,
but writing to the flash fails. The error message is
avrdude: stk500v2_command():
Thanks for the note, Jürgen. At the moment, I'm only trying to program
the ATmega8 using the AVR JTAG ICE mkII.
Cheers,
Shaun
On 1/8/07, Jürgen Schilling [EMAIL PROTECTED] wrote:
Hi Shaun,
I'll hope you know, that debugging with the ATmega8 and the JTAG ICE
mkII isn't possible. If you like to
If #404616 is in fact an RC bug, then #405599 should be as well. If
there are no objections, I'll bump the severity of #405599 to serious.
Cheers,
Shaun
On 1/4/07, Aaron M. Ucko [EMAIL PROTECTED] wrote:
I think bug #405599 may be responsible for #404616 (which I tried to
x-debbugs-cc):
If #404616 is in fact an RC bug, then #405599 should be as well. If
there are no objections, I'll bump the severity of #405599 to serious.
Cheers,
Shaun
On 1/4/07, Aaron M. Ucko [EMAIL PROTECTED] wrote:
I think bug #405599 may be responsible for #404616 (which I tried to
x-debbugs-cc):
Monotone has a bug (#404616) that seems to only affect powerpc. I
don't have access to a powerpc machine myself, so I'd like to use
bruckner.debian.org to troubleshoot the bug. How do I use the Etch
chroot on bruckner to install monotone and its dependencies and run
monotone without root access
package monotone
retitle 404616 monotone: Segmentation fault on powerpc
thanks
On 12/27/06, Brian May [EMAIL PROTECTED] wrote:
Me thinks it is still RC, as it makes monotone completely
unusable. Even if it is PowerPC specific, Debian is still supported on
all architectures, not just Intel.
I
On 1/4/07, Zack Weinberg [EMAIL PROTECTED] wrote:
Thanks for the symbol-ful backtrace. I regret to say I don't know
what is going on there, but I have this bad feeling it's a Boost bug.
I get the same impression. Or, perhaps a difference between how Boost
was compiled for Debian and how
package monotone
block 404616 405599
thanks
Thanks for tracking down the root cause, Aaron! I suspected a Boost bug.
Cheers,
Shaun
On 1/4/07, Aaron M. Ucko [EMAIL PROTECTED] wrote:
I think bug #405599 may be responsible for #404616 (which I tried to
x-debbugs-cc):
Package: libboost-dev
package monotone
retitle 404616 monotone: Segmentation fault on powerpc
thanks
On 12/27/06, Brian May [EMAIL PROTECTED] wrote:
Me thinks it is still RC, as it makes monotone completely
unusable. Even if it is PowerPC specific, Debian is still supported on
all architectures, not just Intel.
I
package monotone
block 404616 405599
thanks
Thanks for tracking down the root cause, Aaron! I suspected a Boost bug.
Cheers,
Shaun
On 1/4/07, Aaron M. Ucko [EMAIL PROTECTED] wrote:
I think bug #405599 may be responsible for #404616 (which I tried to
x-debbugs-cc):
Package: libboost-dev
package monotone
retitle 404616 monotone: Segmentation fault on powerpc
thanks
On 12/27/06, Brian May [EMAIL PROTECTED] wrote:
Me thinks it is still RC, as it makes monotone completely
unusable. Even if it is PowerPC specific, Debian is still supported on
all architectures, not just Intel.
I
On 1/4/07, Zack Weinberg [EMAIL PROTECTED] wrote:
Thanks for the symbol-ful backtrace. I regret to say I don't know
what is going on there, but I have this bad feeling it's a Boost bug.
I get the same impression. Or, perhaps a difference between how Boost
was compiled for Debian and how
package monotone
block 404616 405599
thanks
Thanks for tracking down the root cause, Aaron! I suspected a Boost bug.
Cheers,
Shaun
On 1/4/07, Aaron M. Ucko [EMAIL PROTECTED] wrote:
I think bug #405599 may be responsible for #404616 (which I tried to
x-debbugs-cc):
Package: libboost-dev
NMU as necessary. See you in the new year!
Cheers,
Shaun
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
package monotone
severity 404616 important
tag 404616 unreproducible
thanks
On 12/26/06, Brian May [EMAIL PROTECTED] wrote:
Package: monotone
Version: 0.31-3
Severity: grave
Justification: renders package unusable
I have tried three completely different working directories with
similar
package monotone
severity 404616 important
tag 404616 unreproducible
thanks
On 12/26/06, Brian May [EMAIL PROTECTED] wrote:
Package: monotone
Version: 0.31-3
Severity: grave
Justification: renders package unusable
I have tried three completely different working directories with
similar
package monotone
severity 404616 important
tag 404616 unreproducible
thanks
On 12/26/06, Brian May [EMAIL PROTECTED] wrote:
Package: monotone
Version: 0.31-3
Severity: grave
Justification: renders package unusable
I have tried three completely different working directories with
similar
Is it possible to register a heuristic dissector for a particular
wtap_encap type? I added a wtap MPEG file type, WTAP_ENCAP_MPEG. Now
I want to add two different dissectors, one for MPEG PES (a normal
MPEG video file), and one for MP3 (MPEG 1 layer 3 audio).
So, I called...
On 12/23/06, Shaun Jackman [EMAIL PROTECTED] wrote:
Is it possible to register a heuristic dissector for a particular
wtap_encap type?
I came up with a solution. I registered one normal dissector against
the specific wtap_encap type and all the other dissectors become
heuristic dissectors
On 12/20/06, Steve Langasek [EMAIL PROTECTED] wrote:
New version reviewed and hinted. Luk, can you drop your hint for the old
version?
Thanks, Steve.
Cheers,
Shaun
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: make
Version: 3.81-3
Severity: important
Firstly, I'm unsure if this bug is specific to make or wine, but since
this bug does not exist in make 3.80-9 and does exist in both make
3.81-2 and make 3.81-3, I filed it against make.
Wine segfaults when run from within make. I would tend to
On 12/11/06, Luk Claes [EMAIL PROTECTED] wrote:
Shaun Jackman wrote:
* swt-gtk (testing: 3.2.1-2, unstable: 3.2.1-3)
This update, which adds support for 64-bit architectures, is an
important one for etch. It is `out of date on sparc', which
apparently
has a Java-related dependency
On 11/26/06, Denis Vlasenko [EMAIL PROTECTED] wrote:
On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) 8) 0xff) | (((x) 0xff) 8))
Sometimes gcc is generating better code if you
On 12/18/06, Anton Erasmus [EMAIL PROTECTED] wrote:
Hi,
Not a macro, but the following seems to generate reasonable code.
...
Thanks Anton,
I came to the same conclusion.
Cheers,
Shaun
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
On 12/18/06, David VanHorn [EMAIL PROTECTED] wrote:
Am I missing something here?
Why not pop to assembler, push the high, push the low, pop the high, pop the
low?
* Inline assembler cannot be used at compile time, for example to
initialize a static variable.
* If the swap function is called
On 12/18/06, Nils Springob [EMAIL PROTECTED] wrote:
Hi,
and it is possible to use an anonymous struct:
True. However, unnamed struct/union fields are an extension of the C
language provided by GCC and not strictly portable. It is a nice
feature though. It would be nice if it crept its way
On 12/18/06, Anton Erasmus [EMAIL PROTECTED] wrote:
Hi,
Not a macro, but the following seems to generate reasonable code.
...
Thanks Anton,
I came to the same conclusion.
Cheers,
Shaun
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
On 12/18/06, Nils Springob [EMAIL PROTECTED] wrote:
Hi,
and it is possible to use an anonymous struct:
True. However, unnamed struct/union fields are an extension of the C
language provided by GCC and not strictly portable. It is a nice
feature though. It would be nice if it crept its way
Package: verilog
Severity: wishlist
Version: 0.8-4.1
Since the XNF target is now obsolete and replaced by EDIF, the package
description should mention EDIF support.
Cheers,
Shaun
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Architecture: source i386 all
Version: 3.2.1-4
Distribution: unstable
Urgency: medium
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed-By: Shaun Jackman [EMAIL PROTECTED]
Description:
libswt-gnome-gtk-3.2-jni - Standard Widget Toolkit for GTK Gnome JNI library
libswt-gtk-3.2 - Standard Widget Toolkit
reassign 403057 swt-gtk
retitle 403057 Fails on 64-bit architectures without SWT_PTR_SIZE_64
thanks
Since swt-gtk has not run on 64-bit architectures in the past, this
bug is not strictly release critical. However, I would very much like
to see this bug fixed in Etch.
-- sdj
--
To
On 12/12/06, Steve Langasek [EMAIL PROTECTED] wrote:
...
I don't see any conflicts between the -java packages, only the -jni
packages. I guess the -jni packages do need to conflict with each other
then, if they have file conflicts.
Thank you for bringing to my attention that only the -jni
On 12/12/06, Steve Langasek [EMAIL PROTECTED] wrote:
Should libswt-gtk-3.2-java (my package) conflict with
libswt3.2-gtk-java (the package from Eclipse)? Since Eclipse is not in
stable or testing (as you noted), I'm unsure if conflicting is
necessary. Is it sufficient for libswt3.2-gtk-java
On 12/12/06, Steve Langasek [EMAIL PROTECTED] wrote:
...
I don't see any conflicts between the -java packages, only the -jni
packages. I guess the -jni packages do need to conflict with each other
then, if they have file conflicts.
Thank you for bringing to my attention that only the -jni
On 12/12/06, Steve Langasek [EMAIL PROTECTED] wrote:
...
I don't see any conflicts between the -java packages, only the -jni
packages. I guess the -jni packages do need to conflict with each other
then, if they have file conflicts.
Thank you for bringing to my attention that only the -jni
Why is the buildd not finding debhelper?
Thanks,
Shaun
http://buildd.debian.org/build.php?pkg=monotonever=0.31-3arch=powerpcfile=log
Automatic build of monotone_0.31-3 on malo by sbuild/powerpc 99.99
Build started at 20061205-2149
...
** Using build dependencies supplied by package:
How do I identify which packages on my system are from
stable/testing/unstable/none-of-the-above?
For a single package, I use `apt-cache policy xxx'. I would like a
summary of this information that fits on a single line.
Thanks,
Shaun
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On 12/11/06, Mikhail Gusarov [EMAIL PROTECTED] wrote:
You ([EMAIL PROTECTED]) wrote:
SJ For a single package, I use `apt-cache policy xxx'. I would like
SJ a summary of this information that fits on a single line.
Probably apt-show-versions will help you.
Exactly what I wanted! Thanks,
I have three packages out of date between testing and unstable:
* avarice (testing: 2.4-3, unstable: 2.5-1)
This package programs Atmel AVR microcontrollers. Its usefulness
depends on its support for recent microcontrollers. The new upstream
version adds support for the microcontrollers
On 12/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:~$ madison avarice
avarice | 2.5-1 | testing | source, alpha, amd64, arm, hppa,
i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
avarice | 2.5-1 | unstable | source, alpha, amd64, arm,
On 12/11/06, Luk Claes [EMAIL PROTECTED] wrote:
Shaun Jackman wrote:
On 12/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote:
* swt-gtk (testing: 3.2.1-2, unstable: 3.2.1-3)
This update, which adds support for 64-bit architectures, is an
important one for etch. It is `out of date
On 12/11/06, Luk Claes [EMAIL PROTECTED] wrote:
The build has been retried on the buildd (and succeeded).
Good stuff.
Ok, unblocked.
Great, thanks!
Cheers,
Shaun
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On 12/7/06, Eric Weddington [EMAIL PROTECTED] wrote:
Hi Shaun,
Please add this to a Patch Tracker in the avr-libc project page on Savannah.
Emails have a tendency to get lost and I wouldn't want this to be forgotten.
Eric Weddington
Is there an email gateway to the Savannah patch tracker?
On 12/1/06, Galen Seitz [EMAIL PROTECTED] wrote:
Not exactly what you want, but this might help you get started.
galen
extern inline int16_t
mult_s16_u8s16(uint8_t a, int16_t b)
...
Thanks for the code snippet, Galen. Using your mult_s16_u8s16 for
inspiration, I wrote mul_16_8 (u16 * u8 -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 5 Dec 2006 13:37:52 -0700
Source: monotone
Binary: monotone monotone-doc monotone-server
Architecture: source i386 all
Version: 0.31-3
Distribution: unstable
Urgency: low
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each
On 12/4/06, Shaun Jackman [EMAIL PROTECTED] wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8
On 12/4/06, Andrew Haley [EMAIL PROTECTED] wrote:
Thanks. This is caused because
seda.sandStorm.internal.AggTPSThreadManager$governorThread is in the
file
seda/sandStorm/internal/ATTIC/AggTPSThreadManager$governorThread.class
(In other words, it's not where gcj expects to find it.)
This is a
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each
On 12/4/06, Shaun Jackman [EMAIL PROTECTED] wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each
On 12/4/06, Shaun Jackman [EMAIL PROTECTED] wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit - 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
On 11/30/06, Andreas Jochens [EMAIL PROTECTED] wrote:
...
With the attached patch which adds ppc64 to the list of 64-bit architectures
'swt-gtk' can be compiled on ppc64.
As soon as swt-gtk 3.2.1-3 migrates to testing, I'll apply your patch.
BTW, thank you for adding 64-bit support to the
$ gcj -c /usr/share/java/seda.jar
seda/sandStorm/internal/AggTPSThreadManager.java: In class
'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
seda/sandStorm/internal/AggTPSThreadManager.java: In method
'seda.sandStorm.internal.AggTPSThreadManager$governorThread.run()':
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit - 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 30 Nov 2006 09:42:26 -0700
Source: avarice
Binary: avarice
Architecture: source i386
Version: 2.5-1
Distribution: unstable
Urgency: low
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed-By: Shaun Jackman [EMAIL PROTECTED
On 11/29/06, Matti Pöllä [EMAIL PROTECTED] wrote:
On Sat, Nov 25, 2006 at 02:22:03PM -0700, Shaun Jackman wrote:
Are you still interested in adopting matroxset?
Hello Shaun,
Yes, I'm still interested in maintaining the package. If you would
like to sponsor the upload, I prepared a new
On 11/29/06, Matti Pöllä [EMAIL PROTECTED] wrote:
On Sat, Nov 25, 2006 at 02:22:03PM -0700, Shaun Jackman wrote:
Are you still interested in adopting matroxset?
Hello Shaun,
Yes, I'm still interested in maintaining the package. If you would
like to sponsor the upload, I prepared a new
On 11/28/06, Loïc Minier [EMAIL PROTECTED] wrote:
If you use simple-patchsys, you can prepend before any include line:
ifeq ($(DEB_HOST_ARCH),m68k)
DEB_PATCHDIRS = debian/patches debian/patches/$(DEB_HOST_ARCH)
endif
to add debian/patches/m68k to the list of directories with patches to
On 11/28/06, Ola Lundqvist [EMAIL PROTECTED] wrote:
But you will have complicated dependency problems. Or at least
users will install the wrong version, or do you intend to only release
the 64 bit version on 64 bit systems? and the 32 bit version on 32 bit
systems? I do not really see the point.
On 11/28/06, Shaun Jackman [EMAIL PROTECTED] wrote:
I'm personally leaning towards to two arch: all packages (one 32-bit,
one 64-bit) and a meta-package which depends on the right one. I am
considering and open to the one arch: any package though. If it
affects the decision, the binary package
Here is my list:
64-bit: alpha amd64 ia64
The rest are 32-bit.
Am I missing any?
Perhaps this is a suitable feature for dpkg-architecture.
Cheers,
Shaun
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Architecture: source i386 all
Version: 3.2.1-3
Distribution: unstable
Urgency: low
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed-By: Shaun Jackman [EMAIL PROTECTED]
Description:
libswt-gnome-gtk-3.2-jni - Standard Widget Toolkit for GTK Gnome JNI library
libswt-gtk-3.2 - Standard Widget Toolkit
On 11/28/06, Ola Lundqvist [EMAIL PROTECTED] wrote:
But you will have complicated dependency problems. Or at least
users will install the wrong version, or do you intend to only release
the 64 bit version on 64 bit systems? and the 32 bit version on 32 bit
systems? I do not really see the point.
On 11/28/06, Shaun Jackman [EMAIL PROTECTED] wrote:
I'm personally leaning towards to two arch: all packages (one 32-bit,
one 64-bit) and a meta-package which depends on the right one. I am
considering and open to the one arch: any package though. If it
affects the decision, the binary package
Although SWT uses Java, it is not entirely platform independent. It
requires one jar for 32-bit architectures and one jar for 64-bit
architectures. I could change libswt-gtk-3.2-java to be an
Architecture: any package -- it's currently an all package and does
not support 32-bit architectures --
When using CDBS, what is the best way to conditionally apply an
architecture-dependent patch. I'm using CDBS, but not yet using a
patch system such as simple-patchsys, dpatch, or quilt, so
recommendations of a patch system are welcome. Currently I have...
ARCH64 := alpha amd64 ia64
ifneq
Although SWT uses Java, it is not entirely platform independent. It
requires one jar for 32-bit architectures and one jar for 64-bit
architectures. I could change libswt-gtk-3.2-java to be an
Architecture: any package -- it's currently an all package and does
not support 32-bit architectures --
On 11/24/06, Jeff Morriss [EMAIL PROTECTED] wrote:
But why do all that autoconf work at all when glib has already done it
and is guaranteed to provide a g_ntohl()?
Because one method obfuscates the source code, and the other doesn't.
autoconf solves this problem the correct way, by fixing the
On 11/22/06, Michael Banck [EMAIL PROTECTED] wrote:
On Tue, Nov 21, 2006 at 01:25:54PM -0700, Shaun Jackman wrote:
On 11/19/06, Joerg Jaspert [EMAIL PROTECTED] wrote:
Simple fix for you: Upload a new one, ie slightly changing upstreams
version number.
Any comments on this migration from
On 11/22/06, Shaun Jackman [EMAIL PROTECTED] wrote:
On 11/22/06, Michael Banck [EMAIL PROTECTED] wrote:
On Tue, Nov 21, 2006 at 01:25:54PM -0700, Shaun Jackman wrote:
On 11/19/06, Joerg Jaspert [EMAIL PROTECTED] wrote:
Simple fix for you: Upload a new one, ie slightly changing upstreams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 22 Nov 2006 09:53:37 -0700
Source: monotone
Binary: monotone monotone-doc monotone-server
Architecture: source i386 all
Version: 0.31-2
Distribution: unstable
Urgency: medium
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 22 Nov 2006 13:17:40 -0700
Source: azureus
Binary: azureus
Architecture: source all
Version: 2.5.0.0+0-1
Distribution: unstable
Urgency: medium
Maintainer: Shaun Jackman [EMAIL PROTECTED]
Changed-By: Shaun Jackman [EMAIL
On 11/22/06, Shaun Jackman [EMAIL PROTECTED] wrote:
On 11/22/06, Michael Banck [EMAIL PROTECTED] wrote:
On Tue, Nov 21, 2006 at 01:25:54PM -0700, Shaun Jackman wrote:
On 11/19/06, Joerg Jaspert [EMAIL PROTECTED] wrote:
Simple fix for you: Upload a new one, ie slightly changing upstreams
On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote:
...
1. Is this more likely a bug in Boost or a bug in monotone?
2. Is it reasonable to workaround this bug by removing
-DBOOST_SP_DISABLE_THREADS?
3. Is it worth going to the extra effort to only define
-DBOOST_SP_DISABLE_THREADS on the
On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote:
...
1. Is this more likely a bug in Boost or a bug in monotone?
2. Is it reasonable to workaround this bug by removing
-DBOOST_SP_DISABLE_THREADS?
3. Is it worth going to the extra effort to only define
-DBOOST_SP_DISABLE_THREADS on the
On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote:
...
1. Is this more likely a bug in Boost or a bug in monotone?
2. Is it reasonable to workaround this bug by removing
-DBOOST_SP_DISABLE_THREADS?
3. Is it worth going to the extra effort to only define
-DBOOST_SP_DISABLE_THREADS on the
What's the best approach to place the length of a binary firmware
image in the image itself at a constant location in the image? If
possible, I'd like to avoid using a linker script. I suppose the ideal
location for the firmware length would be immediately following the
interrupt vector table. On
On 11/19/06, Joerg Jaspert [EMAIL PROTECTED] wrote:
Hey,
gah, im blind today, so I accepted azureus. It should have been a
reject, as you now will lose the orig tarball. dak bug, sorry.
Simple fix for you: Upload a new one, ie slightly changing upstreams
version number.
Sorry for that, but dak
601 - 700 of 1716 matches
Mail list logo
