[PATCH] config/arm/arm.c: Use GOT instead of GOTOFF when XIP
This patch forces the use of GOT relocations instead of GOTOFF when
compiling execute-in-place (XIP) code. I've defined XIP as the
combination of -fpic and -msingle-pic-base.
There is room for improvement in using GOTOFF relocations for symbols
that will be in the same addressing space as the GOT (.data likely)
and PC relative relocations for symbols that will be in the same
addressing space as the PC (.text and .rodata likely).
I'm open to suggestions for the name of the new predicate, which I've
named local_symbol_p here. I had named it use_gotoff_p at one point.
Cheers,
Shaun
2006-06-29 Shaun Jackman [EMAIL PROTECTED]
* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 115074)
+++ config/arm/arm.c(working copy)
@@ -3193,6 +3193,17 @@
return 1;
}
+static int
+local_symbol_p(rtx x)
+{
+ /* Execute-in-place code fails if a GOTOFF relocation is used to
+ * adress a local symbol in the .text segment. */
+ if (flag_pic TARGET_SINGLE_PIC_BASE)
+return 0;
+ return GET_CODE (x) == LABEL_REF
+|| (GET_CODE (x) == SYMBOL_REF SYMBOL_REF_LOCAL_P (x));
+}
+
rtx
legitimize_pic_address (rtx orig, enum machine_mode mode, rtx reg)
{
@@ -3271,10 +3282,7 @@
else
emit_insn (gen_pic_load_addr_thumb (address, orig));
- if ((GET_CODE (orig) == LABEL_REF
- || (GET_CODE (orig) == SYMBOL_REF
- SYMBOL_REF_LOCAL_P (orig)))
- NEED_GOT_RELOC)
+ if (NEED_GOT_RELOC local_symbol_p (orig))
pic_ref = gen_rtx_PLUS (Pmode, cfun-machine-pic_reg, address);
else
{
@@ -11292,12 +11300,10 @@
if (NEED_GOT_RELOC flag_pic making_const_table
(GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF))
{
- if (GET_CODE (x) == SYMBOL_REF
- (CONSTANT_POOL_ADDRESS_P (x)
- || SYMBOL_REF_LOCAL_P (x)))
+ if ((GET_CODE (x) == SYMBOL_REF
+CONSTANT_POOL_ADDRESS_P (x))
+ || local_symbol_p (x))
fputs ((GOTOFF), asm_out_file);
- else if (GET_CODE (x) == LABEL_REF)
- fputs ((GOTOFF), asm_out_file);
else
fputs ((GOT), asm_out_file);
}
2006-06-29 Shaun Jackman [EMAIL PROTECTED]
* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 115074)
+++ config/arm/arm.c(working copy)
@@ -3193,6 +3193,17 @@
return 1;
}
+static int
+local_symbol_p(rtx x)
+{
+ /* Execute-in-place code fails if a GOTOFF relocation is used to
+ * adress a local symbol in the .text segment. */
+ if (flag_pic TARGET_SINGLE_PIC_BASE)
+return 0;
+ return GET_CODE (x) == LABEL_REF
+|| (GET_CODE (x) == SYMBOL_REF SYMBOL_REF_LOCAL_P (x));
+}
+
rtx
legitimize_pic_address (rtx orig, enum machine_mode mode, rtx reg)
{
@@ -3271,10 +3282,7 @@
else
emit_insn (gen_pic_load_addr_thumb (address, orig));
- if ((GET_CODE (orig) == LABEL_REF
- || (GET_CODE (orig) == SYMBOL_REF
- SYMBOL_REF_LOCAL_P (orig)))
- NEED_GOT_RELOC)
+ if (NEED_GOT_RELOC local_symbol_p (orig))
pic_ref = gen_rtx_PLUS (Pmode, cfun-machine-pic_reg, address);
else
{
@@ -11292,12 +11300,10 @@
if (NEED_GOT_RELOC flag_pic making_const_table
(GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF))
{
- if (GET_CODE (x) == SYMBOL_REF
- (CONSTANT_POOL_ADDRESS_P (x)
- || SYMBOL_REF_LOCAL_P (x)))
+ if ((GET_CODE (x) == SYMBOL_REF
+CONSTANT_POOL_ADDRESS_P (x))
+ || local_symbol_p (x))
fputs ((GOTOFF), asm_out_file);
- else if (GET_CODE (x) == LABEL_REF)
- fputs ((GOTOFF), asm_out_file);
else
fputs ((GOT), asm_out_file);
}
Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)
On 6/27/06, David McCullough [EMAIL PROTECTED] wrote:
AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
PowerPC and SPARC.' For my purposes, it makes no difference on the
ARM.
You could try some experiments using the older toolchain to see how it
puts binaries together etc. AFAIK, thumb and most archs are supported
by it, it provides at least a working reference for fixing a new
toolchain at least,
I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that
4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32
relocations. Apparently these are a new feature and preferable in some
instances since they do reduce the number of instructions by one.
However, GOTOFF32 does not work when a the relocation is emitted for a
symbol in the .text segment. As far as I know, any XIP application
with a static callback function should fail if it's compiled with
arm-elf-gcc 4.1.x. If anyone else is using this toolchain, I'd
appreciate the confirmation. The following diff of the output from GCC
4.0.3 to GCC 4.1.1 illustrates the new behaviour.
Cheers,
Shaun
$ cat f.c
void g(void (*h)(void)) {}
static void f(void) { g(f); }
$ diff -u f.s-4.0.3 f.s-4.1.1
--- f.s-4.0.3 2006-06-28 09:32:54.044964568 -0600
+++ f.s-4.1.1 2006-06-28 08:55:49.880089024 -0600
@@ -8,11 +8,12 @@
.type g, %function
g:
push{r7, lr}
- mov r7, sp
sub sp, sp, #4
- sub r3, r7, #4
+ add r7, sp, #0
+ mov r3, r7
str r0, [r3]
mov sp, r7
+ add sp, sp, #4
@ sp needed for prologue
pop {r7, pc}
.size g, .-g
@@ -22,10 +23,9 @@
.type f, %function
f:
push{r7, lr}
- mov r7, sp
+ add r7, sp, #0
ldr r3, .L5
add r3, r3, sl
- ldr r3, [r3]
mov r0, r3
bl g
mov sp, r7
@@ -34,6 +34,6 @@
.L6:
.align 2
.L5:
- .word f(GOT)
+ .word f(GOTOFF)
.size f, .-f
- .ident GCC: (GNU) 4.0.3
+ .ident GCC: (GNU) 4.1.1
Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)
On 6/28/06, Shaun Jackman [EMAIL PROTECTED] wrote: I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that 4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32 relocations. Apparently these are a new feature and preferable in some instances since they do reduce the number of instructions by one. However, GOTOFF32 does not work when a the relocation is emitted for a symbol in the .text segment. As far as I know, any XIP application with a static callback function should fail if it's compiled with arm-elf-gcc 4.1.x. If anyone else is using this toolchain, I'd appreciate the confirmation. The following diff of the output from GCC 4.0.3 to GCC 4.1.1 illustrates the new behaviour. Cheers, Shaun I've opened a new bug, GCC #28194 [1], for this matter. Cheers, Shaun [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
Which patch added R_ARM_GOTOFF32 support?
Hello Richard, Dan, I'm trying to track down which part of the GCC source tree makes the decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation. A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a reference to a static function. I thought there was a good chance one of you two might have added this feature. If you're familiar with the the patch, would you please point me to the relevant ChangeLog entry? I'm hoping to add an exception for execute in place (XIP) code (-fPIC -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32. Many thanks, Shaun See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
Re: Which patch added R_ARM_GOTOFF32 support?
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: GOTOFF support has been there for a long while. Only use of it for static functions is recent. It should be easy to find. But this is not at all the only problem. GCC's PIC model assumes a fixed displacement between segments. Even if a fixed displacement is a basic assumption, it doesn't seem to affect the ARM PIC/XIP code drastically, except for this specific case of a static callback function. Everything else seems to `just work'. A simple Hello, world! application linked statically against newlib and using stdio (which is fairly non-trivial) works, for example. I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? We've implemented something similar to what you need for VxWorks. A couple of other places had to be changed. I don't remember if the VxWorks gcc port was submitted, or just the binutils bits. Any chance of this work making it into GCC? Cheers, Shaun
Re: Which patch added R_ARM_GOTOFF32 support?
On 6/28/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote: I'm not terribly familiar with the GCC source tree. I scanned config/arm/arm.c and its SVN log for changes that might affect GOTOFF32, but came up empty. Do you know where the decision of GOT or GOTOFF would be handled? Sorry, it was written quite a while ago. I don't know. Do you know who added this feature? What is you, or perhaps Nick Clifton or Richard Earnshaw? If I could find the person and the file that added this feature, I could probably track down the patch in svn and modify it for XIP. Cheers, Shaun
arm-elf-gcc 4.0.3: ICE when compiling crtstuff.c
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC -msingle-pic-base fails. I had no trouble compiling GCC 4.1.1. Cheers, Shaun make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/ -isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include \ AR_FOR_TARGET=arm-elf-ar \ AR_CREATE_FOR_TARGET=arm-elf-ar rc \ AR_EXTRACT_FOR_TARGET=arm-elf-ar x \ AR_FLAGS_FOR_TARGET= \ CC=gcc CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES= \ LIBGCC2_CFLAGS=-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -mthumb -fPIC -msingle-pic-base \ MULTILIB_CFLAGS= -mthumb -fPIC -msingle-pic-base T=thumb/pic/xip/ thumb/pic/xip/crtbegin.o thumb/pic/xip/crtend.o thumb/pic/xip/crti.o thumb/pic/xip/crtn.o make[3]: Entering directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' /home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc -B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/ -B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/-isystem /usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include -O2-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -Ithumb/pic/xip -I../../gcc -I../../gcc/thumb/pic/xip -I../../gcc/../include -I../../gcc/../libcpp/include -mthumb -fPIC -msingle-pic-base -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -Dinhibit_libc -c ../../gcc/crtstuff.c -DCRT_BEGIN \ -o thumb/pic/xip/crtbegin.o ../../gcc/crtstuff.c: In function 'frame_dummy': ../../gcc/crtstuff.c:325: internal compiler error: in thumb_find_work_register,at config/arm/arm.c:3140 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [thumb/pic/xip/crtbegin.o] Error 1 make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[2]: *** [extrathumb_pic_xip] Error 2 make[2]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc' make: *** [all-gcc] Error 2
XIP on an ARM processor (R_ARM_GOTOFF32)
I'm attempting to build an XIP Hello, world! application for the ARM processor. I'm compiling with -fPIC -msingle-pic-base with the default -mpic-register=r10. The layout of the memory map is such that the .text and .rodata are in flash memory, and the .got, .data and so forth are loaded into RAM. r10 is loaded with the address of the .got. I'm having trouble with string constants. The address of a string constant is being resolved using a R_ARM_GOTOFF32 relocation. For example... d6:4803ldr r0, [pc, #12] (e4 .text+0xe4) d8:4450add r0, sl ... e4:ffdc undefined e4: R_ARM_GOTOFF32 .LC0 The address to the string constant is being specified as a negative offset from the GOT. However, in this memory layout the GOT does not immediately follow the .text section, so a negative offset from the GOT expecting to find the .text section does not make any sense. A PC relative relocation (R_ARM_PC24), on the other hand, should work. The address of the string constant would be specified as a positive offset from the program counter, rather than a negative offset from the GOT. Is there a compiler option to force this behaviour? Please cc me in your reply. Thanks, Shaun
Re: [uClinux-dev] XIP on an ARM processor (R_ARM_GOTOFF32)
On 6/27/06, Erwin Authried [EMAIL PROTECTED] wrote:
Hi,
which compiler/binutil version did you use? Could you post the source
that you used?
One other thing (although that doesn't seem to have to do with your
problem): It is important that you use -fpic (not -fPIC) so that the
correct multilib library is used. For the same reason, -fpic must be
specified in CFLAGS as well as in LDFLAGS if you use a Makefile.
Regards,
Erwin
Hello Erwin,
The source is simply...
int main() { puts(Hello, world!); return 0; }
I'm using binutils 2.17 and gcc 4.1.1.
The issue-raising difference is that I attempted to place .rodata
after the .text semgent in flash, rather than with the .data segment
in RAM. This should work, except that GCC is creating GOT-relative
references to the symbols in .rodata rather than PC-relative
references. The GOT-relative reference does not work if the .rodata
symbol is with the .text segment instead of with the .data segment.
Cheers,
Shaun
Re: XIP on an ARM processor (R_ARM_GOTOFF32)
On 6/27/06, Shaun Jackman [EMAIL PROTECTED] wrote: I'm attempting to build an XIP Hello, world! application for the ARM processor. I'm compiling with -fPIC -msingle-pic-base with the default -mpic-register=r10. The layout of the memory map is such that the .text and .rodata are in flash memory, and the .got, .data and so forth are loaded into RAM. r10 is loaded with the address of the .got. A workaround is to place the .rodata section after the .got with the .data section rather than with the .text data. This work-around loses the advantage of keeping the read-only data in flash, instead of copying it to RAM. Cheers, Shaun
Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)
On 6/27/06, David McCullough [EMAIL PROTECTED] wrote:
Are you using the ld-elf2flt/elf2flt.ld combo ?
It lays things out in a known way and has a '-move-rodata' option which
will put the rodata in with the .text if it contains no relocation info
needed at runtime.
Something like this on the link line:
-gcc -Wl,-move-rodata
The uClinux-dist has this as the default for !MMU systems that can do
XIP,
Cheers,
Davidm
I'm not using ld-elf2flt, but I am using elf2flt.ld.
arm-elf-gcc -mthumb -fPIC -msingle-pic-base -Wl,-q -Telf2flt.ld hello.c -o hello
arm-elf-elf2flt -adp hello hello -o hello.bflt
The ld script that puts .rodata in .text fails, due to GCC referencing
symbols in .rodata with a GOTOFF32 relocation. So, I used the other
linker script instead, which put .rodata in .data after the .got. This
got me as far as an XIP Hello, world! working, which is thrilling!
Unfortunately, a more complex application, busybox, which uses bsearch
and thus a callback function, fails because GCC loads the address for
the callback function using a GOTOFF32 relocation. In the XIP case
where .text and .data are separated and .got does not immediately
follow .text, a GOTOFF32 relocation to a symbol in the .text segment
is super broken.
bc84:4b05ldr r3, [pc, #20] (bc9c .text+0xbc9c)
bc86:b081sub sp, #4
bc88:4453add r3, sl
bc8a:9300str r3, [sp, #0]
...
bc9c:2461movsr4, #97
bc9c: R_ARM_GOTOFF32applet_name_compare
Loading the address of the callback function with either a PC relative
relocation or a GOT (not GOTOFF) relocation would work. Can I prevent
GCC from using GOTOFF32 relocations to symbols located in the .text
segment?
Can someone on the list verify with their toolchain that the address
of a static function is loaded using a GOTOFF32 relocation? The
following test should suffice. It's interesting to note that if the
callback function is not static, GCC will use a GOT32 relocation
instead, which will work.
I'm using binutils 2.17 and gcc 4.1.1.
Cheers,
Shaun
$ cat f.c
void g(void (*h)(void)) {}
static void f(void) { g(f); }
$ arm-elf-gcc -mthumb -fPIC -msingle-pic-base -c f.c
$ arm-elf-objdump -rS f.o | tail -3
24: lslsr0, r0, #0
24: R_ARM_GOTOFF32 f
...
Re: [Monotone-devel] Merge of net.venge.monotone.debian
On 6/26/06, Matthew A. Nicholson [EMAIL PROTECTED] wrote: Greetings, I think net.venge.monotone.debian is just about ready to be merged. Could the debian package maintainers take a look and share their thoughts please. The branch basically adds a monotone-server package which makes it easier to administer a monotone server on a debian machine. The patch also installs the bash completion script to the proper place. The monotone-server package attempts to migrate your database on upgrade if possible as well. Is there an autogen.sh (or equivalent) script to deal with the autotools magickery. I got as far as... config.status: error: cannot find input file: po/Makefile.in.in make: *** [config.status] Error 1 debuild: fatal error at line 857: couldn't exec fakeroot debian/rules: Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Merge of net.venge.monotone.debian
On 6/27/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Tue, Jun 27, 2006 at 02:20:07PM -0600, Shaun Jackman wrote: Is there an autogen.sh (or equivalent) script to deal with the autotools magickery. I got as far as... config.status: error: cannot find input file: po/Makefile.in.in make: *** [config.status] Error 1 debuild: fatal error at line 857: couldn't exec fakeroot debian/rules: autoreconf -i should take care of it; see INSTALL. I think the debian package stuff expects a source distribution, not a checkout, and source distributions already have ./configure and so forth generated in them. I found in addition to autoreconf I also had to run gettextize. Although gettextize modified a few files that I had to revert -- using monotone, of course. What's the proper way to generate the missing po/* files? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
The default -mpic-register for -mthumb
The default -mpic-register (on ARM/Thumb) is r10. In -mthumb mode, r10 is not available to the math instructions as a direct argument. On top of that, preserving r10 complicates the function prologue. Does it make more sense to use a directly accessible register, r7 for example, as the default -mpic-register when in -mthumb mode? Can a non-preserved register, such as r3, be used instead? (assuming the compiler saves the function argument in r3 somewhere) Why is the PIC register fixed? Could the compiler register allocation logic be allowed to allocate the _GLOBAL_OFFSET_TABLE_ pointer the same as any other variable? In which case it would probably realise that cost(r3) cost(r7) cost(r10) at least in the case where r3 isn't being used by a function argument. Cheers, Shaun
Re: The default -mpic-register for -mthumb
On 6/26/06, Richard Earnshaw [EMAIL PROTECTED] wrote: As of gcc-4.2 it isn't fixed, it's just like any other pseudo generated by the compiler. Glad to hear it! Thanks, Shaun
Testing MULTILIB configurations
After I've modified the MULTILIB options in t-arm-elf, what's the fastest way to test the new configuration without rebuilding the entire toolchain? Right now the best method I have is `make clean-gcc all-gcc', which is admittedly quite slow. Please cc me in your reply. Thanks! Shaun
Re: Specifying a MULTILIB dependency
On 26 Jun 2006 14:04:36 -0700, Ian Lance Taylor [EMAIL PROTECTED] The usual hacked up way is to MULTILIB_EXCEPTIONS to remove -msingle-pic-base without -fPIC. Something like MULTILIB_EXCEPTIONS = -msingle-pic-base might do it. I tried your suggestion, but it didn't seem to have the desired effect. With my limited understanding of how MULTILIB_EXCEPTIONS works, I thought the following attempt might have a chance: MULTILIB_EXCEPTIONS += *!fPIC*/*msingle-pic-base* No luck though. Cheers, Shaun
Re: Specifying a MULTILIB dependency
On 26 Jun 2006 14:42:20 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote: No, that wouldn't work. MULTILIB_EXCEPTIONS takes a shell glob pattern. It is invoked for each option set which is going to be generated. I would expect that one of the option sets would be simply -msingle-pic-base. So it seems to me that MULTILIB_EXCEPTIONS can be made to work, if you play with the syntax. However, if it can not be made to work for some reason, then I don't know of anything else which will do what you want. Sorry. Reading through gcc/genmultilib, it looks as though MULTILIB_EXCLUSIONS can take a '!' parameter, but MULTILIB_EXCEPTIONS cannot. Here's another failed experiment: MULTILIB_OPTIONS+= fno-pic/fPIC MULTILIB_DIRNAMES += nopic pic # MULTILIB_OPTIONS+= mno-single-pic-base/msingle-pic-base MULTILIB_DIRNAMES += noxip xip MULTILIB_EXCEPTIONS += *fno-pic*/*msingle-pic-base* I wish I knew what text the shell glob pattern was globbing against. It's clearly not using the resulting directory structure, since the EXCEPTIONS use the OPTIONS names and not the DIRNAMES. Cheers, Shaun
Re: Specifying a MULTILIB dependency
On 6/26/06, Shaun Jackman [EMAIL PROTECTED] wrote: Reading through gcc/genmultilib, it looks as though MULTILIB_EXCLUSIONS can take a '!' parameter, but MULTILIB_EXCEPTIONS cannot. The solutions was to use MULTILIB_EXCLUSIONS! MULTILIB_EXCLUSIONS += !fPIC/msingle-pic-base Yeeha! Cheers, Shaun
Re: Testing MULTILIB configurations
On 6/26/06, Shaun Jackman [EMAIL PROTECTED] wrote: After I've modified the MULTILIB options in t-arm-elf, what's the fastest way to test the new configuration without rebuilding the entire toolchain? Right now the best method I have is `make clean-gcc all-gcc', which is admittedly quite slow. Please cc me in your reply. Thanks! Shaun The best method I found was to remove gcc/s-mlib and gcc/stmp-multilib, rebuild xgcc (make -C gcc xgcc), and run xgcc -print-multi-lib to find the new multilib configuration. Cheers, Shaun
Bug#369376: please move azureus to main
Hello Robin, Sorry, for my delay in replying. I was on vacation in Montréal. Yes, org.gudy.azureus2.ui.swt.Tab seems to be causing a `java.lang.IllegalArgumentException: Argument cannot be null'. This error might be the reason Azureus won't start with java-gcj-compat 1.0.56-2, but I'm not certain of that. I just tested Azureus with cacao 0.96-1 and classpath 2:0.91-3, and it works! Wonderful news. Thanks for pointing this out. I would guess that it's not so much cacao that makes it work, but the fact that cacao uses classpath, whereas java-gcj-compat uses libgcj7, and classpath must be more up-to-date than libgcj7. Is there a package that provides a `java' alternative using the GIJ VM and the classpath library? This configuration would be ideal, in my mind. Cheers, Shaun On 6/14/06, Robin Putters [EMAIL PROTECTED] wrote: Hi there, I noticed you are trying to get Azureus working with 100% free tools, and having problems with the 'tab'-traceback. I've built Azureus on debian, using the ECJ compiler, and ran it using Cacao vm. You might want to try that. Otherwise, feel free to send me the source debian package, and I'll have a look at it (don't know much about debian packages, other than dpkg-buildpackage stuff, but I still will try to have a go at it :)) Robin
Bug#369376: please move azureus to main
On 6/25/06, Shaun Jackman [EMAIL PROTECTED] wrote: I just tested Azureus with cacao 0.96-1 and classpath 2:0.91-3, and it works! Wonderful news. Thanks for pointing this out. I would guess that it's not so much cacao that makes it work, but the fact that cacao uses classpath, whereas java-gcj-compat uses libgcj7, and classpath must be more up-to-date than libgcj7. I may have spoken too soon. Although the GUI runs, Azureus doesn't to transfer any data when run with cacao 0.96-1 and classpath 2:0.91-3. In addition, when I select the `Browse' button of the `Open Torrent(s)' window, it crashes: Cannot find Java function at 0xb7c94f5e java: codegen-common.c:547: codegen_findmethod: Assertion `0' failed. Aborted Have you seen these troubles? Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369376: please move azureus to main
On 6/25/06, Robin Putters [EMAIL PROTECTED] wrote: I think I updated classpath from experimental, since I was having problems with an eclipse project of mine. OK. I'll test classpath from experimental as well. Cannot find Java function at 0xb7c94f5e java: codegen-common.c:547: codegen_findmethod: Assertion `0' failed. Aborted I'm running a mostly sarge system, with a few thing pulled from testing. Classpath uses Qt4, which is a libstdc++6 library, whereas sarge is libstdc++5. So, my browse crash is probably due to the difference in libstdc++ version. Unfortunately, I won't be able to fix this until I upgrade to etch. I see the following AttachCurrentThread warning repeatedly. Although it doesn't seem to affect anything, it's a little disconcerting. LOG: [0x809de70] JNI-Call: AttachCurrentThread: IMPLEMENT ME! I have been able to download, so that's good. Perhaps I was just too impatient last time I tested it. I'm also seeing this error message: Disk read error - write fails: retry limit exceeded, write fails, flush fails Can't say I know what's causing that. The disk appears fine and has room. I don't think the GIJ jvm can run with the classpath package, I think we'll have to wait for GCC 4.2 for a more recent classpath. If you're worried about performance, I remember Azureus on windows (Sun 1.5 JDK) to be absolutely terrible for system performance, but it runs really smooth with cacao for me on the same system. Thanks for your effort in packaging this! My pleasure! Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#369376: please move azureus to main
Hello Robin, Sorry, for my delay in replying. I was on vacation in Montréal. Yes, org.gudy.azureus2.ui.swt.Tab seems to be causing a `java.lang.IllegalArgumentException: Argument cannot be null'. This error might be the reason Azureus won't start with java-gcj-compat 1.0.56-2, but I'm not certain of that. I just tested Azureus with cacao 0.96-1 and classpath 2:0.91-3, and it works! Wonderful news. Thanks for pointing this out. I would guess that it's not so much cacao that makes it work, but the fact that cacao uses classpath, whereas java-gcj-compat uses libgcj7, and classpath must be more up-to-date than libgcj7. Is there a package that provides a `java' alternative using the GIJ VM and the classpath library? This configuration would be ideal, in my mind. Cheers, Shaun On 6/14/06, Robin Putters [EMAIL PROTECTED] wrote: Hi there, I noticed you are trying to get Azureus working with 100% free tools, and having problems with the 'tab'-traceback. I've built Azureus on debian, using the ECJ compiler, and ran it using Cacao vm. You might want to try that. Otherwise, feel free to send me the source debian package, and I'll have a look at it (don't know much about debian packages, other than dpkg-buildpackage stuff, but I still will try to have a go at it :)) Robin
Re: Bug#369376: please move azureus to main
On 6/25/06, Shaun Jackman [EMAIL PROTECTED] wrote: I just tested Azureus with cacao 0.96-1 and classpath 2:0.91-3, and it works! Wonderful news. Thanks for pointing this out. I would guess that it's not so much cacao that makes it work, but the fact that cacao uses classpath, whereas java-gcj-compat uses libgcj7, and classpath must be more up-to-date than libgcj7. I may have spoken too soon. Although the GUI runs, Azureus doesn't to transfer any data when run with cacao 0.96-1 and classpath 2:0.91-3. In addition, when I select the `Browse' button of the `Open Torrent(s)' window, it crashes: Cannot find Java function at 0xb7c94f5e java: codegen-common.c:547: codegen_findmethod: Assertion `0' failed. Aborted Have you seen these troubles? Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#369376: please move azureus to main
On 6/25/06, Robin Putters [EMAIL PROTECTED] wrote: I think I updated classpath from experimental, since I was having problems with an eclipse project of mine. OK. I'll test classpath from experimental as well. Cannot find Java function at 0xb7c94f5e java: codegen-common.c:547: codegen_findmethod: Assertion `0' failed. Aborted I'm running a mostly sarge system, with a few thing pulled from testing. Classpath uses Qt4, which is a libstdc++6 library, whereas sarge is libstdc++5. So, my browse crash is probably due to the difference in libstdc++ version. Unfortunately, I won't be able to fix this until I upgrade to etch. I see the following AttachCurrentThread warning repeatedly. Although it doesn't seem to affect anything, it's a little disconcerting. LOG: [0x809de70] JNI-Call: AttachCurrentThread: IMPLEMENT ME! I have been able to download, so that's good. Perhaps I was just too impatient last time I tested it. I'm also seeing this error message: Disk read error - write fails: retry limit exceeded, write fails, flush fails Can't say I know what's causing that. The disk appears fine and has room. I don't think the GIJ jvm can run with the classpath package, I think we'll have to wait for GCC 4.2 for a more recent classpath. If you're worried about performance, I remember Azureus on windows (Sun 1.5 JDK) to be absolutely terrible for system performance, but it runs really smooth with cacao for me on the same system. Thanks for your effort in packaging this! My pleasure! Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Monotone-devel] Re: Fixed in NMU of monotone 0.25-0.1
On 5/13/06, Tomas Fasth [EMAIL PROTECTED] wrote: I have managed to build and upload the latest version (0.26.0). I use the pbuilder package and the pdebuild command to do clean environment builds. It has been an easy task maintaining the monotone package. I have so far not been trying to do automatic database migration as part of a package upgrade. I think together with help from the monotone developer community you will be able to do this in the future. The main programmer Nathaniel and the core developers around him has been very helpful and understanding. Let me know when you're ready to adopt. Regards, Tomas Hello Tomas, My wrist has healed, and I've packaged monotone 0.27. If you're still happy with my adopting the package, I'm ready to upload. Cheers, Shaun --- monotone-0.27.orig/debian/changelog +++ monotone-0.27/debian/changelog @@ -1,3 +1,11 @@ +monotone (0.27-1) unstable; urgency=low + + * New upstream release. + * New maintainer. + * New watch file. + + -- Shaun Jackman [EMAIL PROTECTED] Mon, 19 Jun 2006 09:26:53 -0600 + monotone (0.27-0.1) unstable; urgency=low * New upstream release. --- monotone-0.27.orig/debian/docs +++ monotone-0.27/debian/docs @@ -10,4 +10,3 @@ contrib debian/README.Debian debian/TODO.Debian -examples ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Fixed in NMU of monotone 0.25-0.1
On 6/21/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Wed, 21 Jun 2006 10:49:58 -0600, Shaun Jackman [EMAIL PROTECTED] said: sjackman --- monotone-0.27.orig/debian/docs sjackman +++ monotone-0.27/debian/docs sjackman @@ -10,4 +10,3 @@ sjackman contrib sjackman debian/README.Debian sjackman debian/TODO.Debian sjackman -examples sjackman sjackman I noticed that diff, and would like to suggest you apply this change instead. It's been applied to monotone after 0.27: --- Makefile.am +++ Makefile.am @@ -423,6 +423,7 @@ contrib/ciabot_monotone_hookversion.py \ contrib/monotone-cvs-ignore.lua \ contrib/usher.cc \ + $(wildcard $(srcdir)/examples/*) \ win32/monotone.iss \ $(wildcard $(srcdir)/debian/*) Cheers, Richard This diff applies against the tarball, not against a checkout of the monotone repository, so there are no examples files to include. If at all possible, I prefer using the identical upstream tarball, so that the hash of the tarball is identical. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] examples directory
On 6/19/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Mon, 19 Jun 2006 23:04:41 +0200 (CEST), Richard Levitte - VMS Whacker [EMAIL PROTECTED] said: richard Oh, for the love of (/#%¤(/%/)I( Forgot to add the files to richard EXTRA_DIST in Makefile.am. OK, correcting. Speaking of that, does anyone know why the files in contrib/ are being specified exactly instead of using $(wildcard $(srcdir)/contrib/*), just as is done with the debian/ files, the examples/ files (from now on) and so on? Cheers, Richard For automake files, I have a general preference for specifying distribution files explicitly. Also, $(wildcard *) is a GNU make extension, I believe, although I'm not sure that's much of a practical concern. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] cmd_automate.cc:128: error: using-declaration for non-member at class scope
I'm seeing the following error when attempting to compile monotone 0.27. cmd_automate.cc:128: error: using-declaration for non-member at class scope I'm using GCC 4.0.3 (Debian 4:4.0.3-4) and boost 1.32.0 (Debian 1.32.0-6). I haven't looked into this too closely yet, but does anyone have any obvious suggestions? Thanks, Shaun g++ -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I. -I. -I. -I./lua -I./sqlite -DNDEBUG -DBOOST_DISABLE_THREADS -DBOOST_SP_DISABLE_THREADS -g -Wall -O2 -fno-strict-aliasing -Wall -W -Wno-unused -DBOOST_REGEX_V4_CHAR_REGEX_TRAITS_HPP -DBOOST_REGEX_COMPILE_HPP -c -o mtn-cmd_automate.o `test -f 'cmd_automate.cc' || echo './'`cmd_automate.cc In file included from /usr/include/boost/config.hpp:35, from /usr/include/boost/bind.hpp:23, from cmd_automate.cc:14: /usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning Unknown compiler version - please run the configure tests and report the results cmd_automate.cc:128: error: using-declaration for non-member at class scope cmd_automate.cc:128: error: expected ';' before '' token cmd_automate.cc:159: error: 'boost::function1' has not been declared cmd_automate.cc:159: error: expected ',' or '...' before '' token cmd_automate.cc: In member function 'virtual std::streamsize my_stringbuf::xsputn(const char*, std::streamsize)': cmd_automate.cc:145: error: 'on_write' was not declared in this scope cmd_automate.cc: In member function 'virtual int my_stringbuf::sync()': cmd_automate.cc:154: error: 'on_write' was not declared in this scope cmd_automate.cc: In member function 'void my_stringbuf::set_on_write(int)': cmd_automate.cc:161: error: 'on_write' was not declared in this scope cmd_automate.cc:161: error: 'x' was not declared in this scope cmd_automate.cc: In member function 'virtual void automation::auto_stdio::run(std::vectorutf8, std::allocatorutf8 , const std::string, app_state, std::ostream) const': cmd_automate.cc:263: error: no matching function for call to 'my_stringbuf::set_on_write(boost::_bi::bind_tvoid, void (*)(int, int, bool, const std::string, std::ostream, int, int), boost::_bi::list7boost::_bi::valueint, boost::reference_wrapperint, boost::_bi::valuebool, boost::_bi::bind_tstd::basic_stringchar, std::char_traitschar, std::allocatorchar , boost::_mfi::cmf0std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_stringbufchar, std::char_traitschar, std::allocatorchar , boost::_bi::list1boost::_bi::valuemy_stringbuf* , boost::reference_wrapperstd::basic_ostreamchar, std::char_traitschar , boost::reference_wrapperint, boost::arg1 )' cmd_automate.cc:159: note: candidates are: void my_stringbuf::set_on_write(int) make[3]: *** [mtn-cmd_automate.o] Error 1 make[3]: Leaving directory `/home/sjackman/work/debian/monotone/monotone-0.27' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sjackman/work/debian/monotone/monotone-0.27' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sjackman/work/debian/monotone/monotone-0.27' make: *** [debian/stamp-makefile-build] Error 2 debuild: fatal error at line 767: dpkg-buildpackage failed! ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] cmd_automate.cc:128: error: using-declaration for non-member at class scope
On 6/19/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Mon, Jun 19, 2006 at 10:55:37AM -0600, Shaun Jackman wrote: I'm seeing the following error when attempting to compile monotone 0.27. cmd_automate.cc:128: error: using-declaration for non-member at class scope I'm using GCC 4.0.3 (Debian 4:4.0.3-4) and boost 1.32.0 (Debian 1.32.0-6). I haven't looked into this too closely yet, but does anyone have any obvious suggestions? This appears to be the same as: https://savannah.nongnu.org/bugs/?func=detailitemitem_id=16866 I've committed the fix suggested there to mainline (it's trivial and you can just make the change locally, if you want -- just add #include boost/function.hpp towards the top of cmd_automate.cc). I haven't tested it or anything, though, because I don't have boost 1.32.0 -- does that fix work for you? Yes, this fix works. Thank you, Nathan. I assume then that this patch is not necessary with boost 1.33.0. My system is mostly Debian Sarge -- with a few cherry-picked upgrades -- which is showing its age. Thanks for the help. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] examples directory
The examples directory is mentioned in the ChangeLog and in debian/docs, but does not seem to be included in the 0.27 tarball distribution. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Bug#374102: azureus: swarm network in 'Show details' tab doesn't show
package azureus tag 374102 +unreproducible thanks Hello Tore, I just tested for this bug myself, and my installation does not behave in the manner you reported. I'm still running XFree86 4.3.0.dfsg.1-1. I've seen other bugs related to the version of XFree86/Xorg being used. Perhaps this is similar. If it is, you might try scanning the upstream bug tracking system for your issue. Cheers, Shaun On 6/17/06, Tore Ferner [EMAIL PROTECTED] wrote: Package: azureus Version: 2.4.0.2-1 Severity: normal When you click on a torrent and selects 'view details' and then the 'swarm' tab, the swarm shows up for a fraction of a second and then disappears, the whole tab being just the blank gnome background color (greyish). This happens each time you reselect the swarm tab. Further information about the environment: ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354626: ITA: glosstex -- Prepare glossaries and lists of acronyms
On 6/10/06, Arnaud Fontaine [EMAIL PROTECTED] wrote: retitle 354626 ITA: glosstex -- Prepare glossaries and lists of acronyms owner 354626 ! thanks Hello, I'm interested by taking care of this package. I'm using latex regularly. I will upload a new version of the package ASAP. Regards, Arnaud Fontaine Wondeful. Glad to hear it! Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354626: ITA: glosstex -- Prepare glossaries and lists of acronyms
On 6/10/06, Arnaud Fontaine [EMAIL PROTECTED] wrote: retitle 354626 ITA: glosstex -- Prepare glossaries and lists of acronyms owner 354626 ! thanks Hello, I'm interested by taking care of this package. I'm using latex regularly. I will upload a new version of the package ASAP. Regards, Arnaud Fontaine Wondeful. Glad to hear it! Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[VAC] Montréal 2006-06-09/16
My broken wrist has healed -- yeah! -- so I'm back from that `vacation', and now I'm on my way to Montréal for a week. Cheers, Shaun
[Monotone-devel] Removing a revision from a branch
I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? Thanks, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Removing a revision from a branch
On 6/8/06, Chad Walstrom [EMAIL PROTECTED] wrote: Shaun Jackman [EMAIL PROTECTED] wrote: I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? Yes. As long as the change has not propagated to other databases via synchronization, you can: $ mtn -d DATABASEPATH db kill_rev_locally REVISION I didn't explain my problem correctly. The revision is good, and I do want it to exist, but it accidentally has two `branch' certs and two `date' certs. One is for the branch is should be in, and I have no idea where the other came from. I'd like to remove the spurious branch cert. This error hasn't made it into any other databases. I suppose want I want is a `db kill_cert_locally' command. Would the cert be specified by revision/name/value? The output of `ls certs' showing my problem follows. Cheers, Shaun $ mtn ls certs e529 mtn: expanded selector 'e529' - 'i:e529' mtn: expanding selection 'e529' mtn: expanded to 'e529f44eef1fc60ef5e66cbe545ec43513222970' Key : [EMAIL PROTECTED] Sig : ok Name : author Value : Shaun Jackman [EMAIL PROTECTED] Key : [EMAIL PROTECTED] Sig : ok Name : branch Value : busybox Key : [EMAIL PROTECTED] Sig : ok Name : branch Value : busybox-sdj Key : [EMAIL PROTECTED] Sig : ok Name : changelog Value : * .config: New file. Key : [EMAIL PROTECTED] Sig : ok Name : date Value : 2006-06-05T20:48:43 Key : [EMAIL PROTECTED] Sig : ok Name : date Value : 2006-06-05T20:51:15 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Removing a revision from a branch
On 6/8/06, Timothy Brownawell [EMAIL PROTECTED] wrote: On Thu, 2006-06-08 at 10:23 -0600, Shaun Jackman wrote: I don't know how it happened, but apparently I accidentally added a revision to a branch to which it does not belong. How do I remove the revision from the branch? Is there a command to remove a specified cert? No, you have to use 'db execute'. Make a copy of your db, then run mtn db execute delete from revision_certs where id = 'revid' and name = 'branch' (remove all branch certs from that revision), then mtn approve revid -b branch-you-want (put back the one you want). Thanks! Your advice worked perfectly. Incidentally, the branch still has two `date' certs. I can figure out on my own how to remove one of them with `db execute' command. What could possibly cause two date certs to be created? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Bug#361603: FTBFS with GCC 4.2: cast from pointer to integer of different size
On 6/5/06, Andrew Pollock [EMAIL PROTECTED] wrote: The issue is that I uploaded -3; it was not a QA upload. My changes in -3 seem to have been omitted from the QA upload of -4. See (far) below for the changelog from my -3 upload. Sure, I read the changelog before composing my previous email. My point remains: when I do a QA upload, I take what's currently in unstable. The only possibility, (and it's quite possible, given that I appear to have uploaded this package twice) is I downloaded what was in unstable at some point between you making your upload and me making mine. If this is the case, then I am entirely at fault, and need to stop working in a vacuum, and apologise profusely. Sorry, Andrew. I didn't mean to imply that you had reverted the changes intentionally. I only meant to point out that that was the effect, when Martin was wondering why the bug reappeared. There appears to have been some sort of race condition here. Although, if we had both used -2 as a starting point and both uploaded a -3, I don't see how this would not have been caught by the FTP masters, and how it would have resulted in a -4 version. My best guess is that your -3 upload was rejected (due to -3 already exisiting in the archive) which caused you to upload -4 some time later. You started with -3 (which you didn't realise was your rejected -3 and not my -3) made your -4 changes, and uploaded it. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361603: FTBFS with GCC 4.2: cast from pointer to integer of different size
On 6/5/06, Andrew Pollock [EMAIL PROTECTED] wrote: The issue is that I uploaded -3; it was not a QA upload. My changes in -3 seem to have been omitted from the QA upload of -4. See (far) below for the changelog from my -3 upload. Sure, I read the changelog before composing my previous email. My point remains: when I do a QA upload, I take what's currently in unstable. The only possibility, (and it's quite possible, given that I appear to have uploaded this package twice) is I downloaded what was in unstable at some point between you making your upload and me making mine. If this is the case, then I am entirely at fault, and need to stop working in a vacuum, and apologise profusely. Sorry, Andrew. I didn't mean to imply that you had reverted the changes intentionally. I only meant to point out that that was the effect, when Martin was wondering why the bug reappeared. There appears to have been some sort of race condition here. Although, if we had both used -2 as a starting point and both uploaded a -3, I don't see how this would not have been caught by the FTP masters, and how it would have resulted in a -4 version. My best guess is that your -3 upload was rejected (due to -3 already exisiting in the archive) which caused you to upload -4 some time later. You started with -3 (which you didn't realise was your rejected -3 and not my -3) made your -4 changes, and uploaded it. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Monotone-devel] monotone-viz: _MTN
Is monotone-viz 0.14 meant to be able to pull the options and revision from _MTN as it does for MT? It doesn't seem to work for me. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz: _MTN
On 6/5/06, Olivier Andrieu [EMAIL PROTECTED] wrote: No but the latest revision on the venge.net repository, yes. I should have released that ages ago, sorry. Off-topic, but I won't release the next monotone-viz for Debian for a couple weeks anyways. I'm going on vacation to Montréal for a couple weeks, and on top of that, the latest libgnomeui-dev on Debian wants to pull in XOrg 7, whereas I'm still at 6.9. I don't want to blindly upgrade without a bit of time to play around with it. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Bug#361603: FTBFS with GCC 4.2: cast from pointer to integer of different size
On 6/4/06, Martin Michlmayr [EMAIL PROTECTED] wrote: found 361603 0.1.2.2-4 thanks * Martin Michlmayr [EMAIL PROTECTED] [2006-04-09 21:11]: * Shaun Jackman [EMAIL PROTECTED] [2006-04-09 13:07]: It should be noted that this bug only affects 64-bit targets. This patch is untested on 64-bit targets, but should fix the issue. This works, thanks. Is it possible that this change got lost? 0.1.2.2-4 fails to build on Alpha with GCC 4.2. Apparently, yes, it is! How's this for irony. The QA upload of 0.1.2.2-4 reverted the changes from 0.1.2.2-3 and broke the package! Funny. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361603: FTBFS with GCC 4.2: cast from pointer to integer of different size
On 6/4/06, Andrew Pollock [EMAIL PROTECTED] wrote: Apparently, yes, it is! How's this for irony. The QA upload of 0.1.2.2-4 reverted the changes from 0.1.2.2-3 and broke the package! Funny. How's that? I just took what was in unstable and rebuilt it. I don't go reverting things. Strange in this particular case how I did two uploads of the package though... Too long (and too many packages) ago to remember the specifics. The issue is that I uploaded -3; it was not a QA upload. My changes in -3 seem to have been omitted from the QA upload of -4. See (far) below for the changelog from my -3 upload. Cheers, Shaun Your message dated Sun, 09 Apr 2006 14:03:30 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#361603: fixed in simulavr 0.1.2.2-3 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Forwarded message -- From: Martin Michlmayr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 9 Apr 2006 12:00:00 +0200 Subject: FTBFS with GCC 4.2: cast from pointer to integer of different size Package: simulavr Version: 0.1.2.2-2 Your package fails to build with GCC 4.2. Version 4.2 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. The bug below is in your package and not because I'm using a snapshot of the compiler so please take a look at it. You can reproduce this with the gcc-snapshot package. Automatic build of simulavr_0.1.2.2-2 on em64t by sbuild/amd64 1.112 ... if x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.-Wall -Winline -Werror -I../src/getopt -Wall -g -O2 -MT adc.o -MD -MP -MF .deps/adc.Tpo -c -o adc.o adc.c; \ then mv -f .deps/adc.Tpo .deps/adc.Po; else rm -f .deps/adc.Tpo; exit 1; fi cc1: warnings being treated as errors adc.c: In function 'adc_intr_cb': adc.c:270: warning: cast from pointer to integer of different size make[4]: *** [adc.o] Error 1 -- Martin Michlmayr http://www.cyrius.com/ -- Forwarded message -- From: Shaun Jackman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 09 Apr 2006 14:03:30 -0700 Subject: Bug#361603: fixed in simulavr 0.1.2.2-3 Source: simulavr Source-Version: 0.1.2.2-3 We believe that the bug you reported is fixed in the latest version of simulavr, which is due to be installed in the Debian FTP archive: simulavr_0.1.2.2-3.diff.gz to pool/main/s/simulavr/simulavr_0.1.2.2-3.diff.gz simulavr_0.1.2.2-3.dsc to pool/main/s/simulavr/simulavr_0.1.2.2-3.dsc simulavr_0.1.2.2-3_i386.deb to pool/main/s/simulavr/simulavr_0.1.2.2-3_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Shaun Jackman [EMAIL PROTECTED] (supplier of updated simulavr package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 9 Apr 2006 12:59:37 -0600 Source: simulavr Binary: simulavr Architecture: source i386 Version: 0.1.2.2-3 Distribution: unstable Urgency: low Maintainer: Shaun Jackman [EMAIL PROTECTED] Changed-By: Shaun Jackman [EMAIL PROTECTED] Description: simulavr - Atmel AVR simulator Closes: 361603 Changes: simulavr (0.1.2.2-3) unstable; urgency=low . * src/intvects.h (irq_vect_table_index): Use offsetof. Closes: #361603. * Update config.guess and config.sub to version 2006-02-23. * Clean up debian/rules. Files: e35c15337f45949f37a4a26b0f0b863c 615 electronics optional simulavr_0.1.2.2-3.dsc 90e8f190929562eca64e12b4a77d7c6b 18752 electronics optional simulavr_0.1.2.2-3.diff.gz d9503a3d1405d1a7c20304c0e3406092 83258 electronics optional simulavr_0.1.2.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEOVv/vFdYF1IwUUoRAuOfAKDUayScLrt+SI5Ula4aTiSowjY/vACfddKW XXZO8p77qyhmQT0+fSwMUJs= =AB+d -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361603: FTBFS with GCC 4.2: cast from pointer to integer of different size
On 6/4/06, Martin Michlmayr [EMAIL PROTECTED] wrote: found 361603 0.1.2.2-4 thanks * Martin Michlmayr [EMAIL PROTECTED] [2006-04-09 21:11]: * Shaun Jackman [EMAIL PROTECTED] [2006-04-09 13:07]: It should be noted that this bug only affects 64-bit targets. This patch is untested on 64-bit targets, but should fix the issue. This works, thanks. Is it possible that this change got lost? 0.1.2.2-4 fails to build on Alpha with GCC 4.2. Apparently, yes, it is! How's this for irony. The QA upload of 0.1.2.2-4 reverted the changes from 0.1.2.2-3 and broke the package! Funny. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361603: FTBFS with GCC 4.2: cast from pointer to integer of different size
On 6/4/06, Andrew Pollock [EMAIL PROTECTED] wrote: Apparently, yes, it is! How's this for irony. The QA upload of 0.1.2.2-4 reverted the changes from 0.1.2.2-3 and broke the package! Funny. How's that? I just took what was in unstable and rebuilt it. I don't go reverting things. Strange in this particular case how I did two uploads of the package though... Too long (and too many packages) ago to remember the specifics. The issue is that I uploaded -3; it was not a QA upload. My changes in -3 seem to have been omitted from the QA upload of -4. See (far) below for the changelog from my -3 upload. Cheers, Shaun Your message dated Sun, 09 Apr 2006 14:03:30 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#361603: fixed in simulavr 0.1.2.2-3 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Forwarded message -- From: Martin Michlmayr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 9 Apr 2006 12:00:00 +0200 Subject: FTBFS with GCC 4.2: cast from pointer to integer of different size Package: simulavr Version: 0.1.2.2-2 Your package fails to build with GCC 4.2. Version 4.2 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. The bug below is in your package and not because I'm using a snapshot of the compiler so please take a look at it. You can reproduce this with the gcc-snapshot package. Automatic build of simulavr_0.1.2.2-2 on em64t by sbuild/amd64 1.112 ... if x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.-Wall -Winline -Werror -I../src/getopt -Wall -g -O2 -MT adc.o -MD -MP -MF .deps/adc.Tpo -c -o adc.o adc.c; \ then mv -f .deps/adc.Tpo .deps/adc.Po; else rm -f .deps/adc.Tpo; exit 1; fi cc1: warnings being treated as errors adc.c: In function 'adc_intr_cb': adc.c:270: warning: cast from pointer to integer of different size make[4]: *** [adc.o] Error 1 -- Martin Michlmayr http://www.cyrius.com/ -- Forwarded message -- From: Shaun Jackman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 09 Apr 2006 14:03:30 -0700 Subject: Bug#361603: fixed in simulavr 0.1.2.2-3 Source: simulavr Source-Version: 0.1.2.2-3 We believe that the bug you reported is fixed in the latest version of simulavr, which is due to be installed in the Debian FTP archive: simulavr_0.1.2.2-3.diff.gz to pool/main/s/simulavr/simulavr_0.1.2.2-3.diff.gz simulavr_0.1.2.2-3.dsc to pool/main/s/simulavr/simulavr_0.1.2.2-3.dsc simulavr_0.1.2.2-3_i386.deb to pool/main/s/simulavr/simulavr_0.1.2.2-3_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Shaun Jackman [EMAIL PROTECTED] (supplier of updated simulavr package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 9 Apr 2006 12:59:37 -0600 Source: simulavr Binary: simulavr Architecture: source i386 Version: 0.1.2.2-3 Distribution: unstable Urgency: low Maintainer: Shaun Jackman [EMAIL PROTECTED] Changed-By: Shaun Jackman [EMAIL PROTECTED] Description: simulavr - Atmel AVR simulator Closes: 361603 Changes: simulavr (0.1.2.2-3) unstable; urgency=low . * src/intvects.h (irq_vect_table_index): Use offsetof. Closes: #361603. * Update config.guess and config.sub to version 2006-02-23. * Clean up debian/rules. Files: e35c15337f45949f37a4a26b0f0b863c 615 electronics optional simulavr_0.1.2.2-3.dsc 90e8f190929562eca64e12b4a77d7c6b 18752 electronics optional simulavr_0.1.2.2-3.diff.gz d9503a3d1405d1a7c20304c0e3406092 83258 electronics optional simulavr_0.1.2.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEOVv/vFdYF1IwUUoRAuOfAKDUayScLrt+SI5Ula4aTiSowjY/vACfddKW XXZO8p77qyhmQT0+fSwMUJs= =AB+d -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369376: please move azureus to main
On 5/29/06, Matthias Klose [EMAIL PROTECTED] wrote: Shaun Jackman writes: You've clearly put a fair amount of work into Ubuntu's Azureus package. Would you be interested in maintaining the Debian package as well? sorry, no. lack of time. You can't blame me for trying. =) I'm likewise strapped for time. Debian's .diff.gz is some 400 lines, whereas Ubuntu's is some 2200 lines, not counting the graphic icons. I'm afraid I just don't have the time to maintain such a large patch set. So, I won't adopt your package wholesale, but I'll try to incorporate the changes necessary to move Azureus into main. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369376: please move azureus to main
On 6/1/06, Matthias Klose [EMAIL PROTECTED] wrote: ok, but still wondering how you will compile using a free runtime and compiler. I'm working on it. When I run Azureus with java-gcj-compat, the splash screen comes up but never displays the main GUI or the system tray applet. I thought it might be related to the following CTabItem exception, which I thought might be related to the azureus-nativetabs.patch. Can you tell me what this patch does? It's a shame each patch file doesn't include a brief comment. Cheers, Shaun DEBUG::Thu Jun 01 11:02:05 MDT 2006::org.gudy.azureus2.core3.util.DebugLight::printStackTrace::38: java.lang.IllegalArgumentException: Argument cannot be null at org.eclipse.swt.SWT.error(SWT.java:2914) at org.eclipse.swt.SWT.error(SWT.java:2865) at org.eclipse.swt.SWT.error(SWT.java:2836) at org.eclipse.swt.widgets.Widget.error(Widget.java:408) at org.eclipse.swt.widgets.Widget.checkParent(Widget.java:282) at org.eclipse.swt.widgets.Widget.init(Widget.java:174) at org.eclipse.swt.widgets.Item.init(Item.java:62) at org.eclipse.swt.custom.CTabItem.init(CTabItem.java:121) at org.gudy.azureus2.ui.swt.Tab.init(Tab.java:101) at org.gudy.azureus2.ui.swt.Tab.init(Tab.java:92) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow.showMyTorrents(MainWindow.java:952) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow.openMainWindow(MainWindow.java:834) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow.access$16(MainWindow.java:814) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow$38.runSupport(MainWindow.java:1703) at org.gudy.azureus2.core3.util.AERunnable.run(AERunnable.java:38) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:36) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2844) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2575) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:114) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:60) at org.gudy.azureus2.ui.swt.mainwindow.Initializer.init(Initializer.java:108) at org.gudy.azureus2.ui.swt.Main.init(Main.java:147) at org.gudy.azureus2.ui.swt.Main.main(Main.java:163) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369376: please move azureus to main
On 6/1/06, Shaun Jackman [EMAIL PROTECTED] wrote: When I run Azureus with java-gcj-compat, the splash screen comes up but never displays the main GUI or the system tray applet. I thought it might be related to the following CTabItem exception, which I thought might be related to the azureus-nativetabs.patch. Can you tell me what this patch does? It's a shame each patch file doesn't include a brief comment. I applied azureus-nativetabs.patch, and the exception is different (TabItem instead of CTabItem) but still now GUI. Cheers, Shaun DEBUG::Thu Jun 01 11:38:57 MDT 2006::org.gudy.azureus2.core3.util.DebugLight::printStackTrace::38: java.lang.IllegalArgumentException: Argument cannot be null at org.eclipse.swt.SWT.error(SWT.java:2914) at org.eclipse.swt.SWT.error(SWT.java:2865) at org.eclipse.swt.SWT.error(SWT.java:2836) at org.eclipse.swt.widgets.Widget.error(Widget.java:408) at org.eclipse.swt.widgets.Widget.checkParent(Widget.java:282) at org.eclipse.swt.widgets.Widget.init(Widget.java:174) at org.eclipse.swt.widgets.Item.init(Item.java:62) at org.eclipse.swt.widgets.TabItem.init(TabItem.java:108) at org.gudy.azureus2.ui.swt.Tab.init(Tab.java:131) at org.gudy.azureus2.ui.swt.Tab.init(Tab.java:92) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow.showMyTorrents(MainWindow.java:952) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow.openMainWindow(MainWindow.java:834) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow.access$16(MainWindow.java:814) at org.gudy.azureus2.ui.swt.mainwindow.MainWindow$38.runSupport(MainWindow.java:1703) at org.gudy.azureus2.core3.util.AERunnable.run(AERunnable.java:38) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:36) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2844) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2575) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:114) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:60) at org.gudy.azureus2.ui.swt.mainwindow.Initializer.init(Initializer.java:108) at org.gudy.azureus2.ui.swt.Main.init(Main.java:147) at org.gudy.azureus2.ui.swt.Main.main(Main.java:163) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted swt-gtk 3.1.2-3 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 28 May 2006 09:23:30 -0600 Source: swt-gtk Binary: libswt-mozilla-gtk-dev libswt-gtk-3.1-jni libswt-gtk-3.1-java libswt-mozilla-gtk-3.1-jni libswt-gtk-3.1 libswt-mozilla-gtk-3.1 libswt-gnome-gtk-3.1-jni libswt-gtk-dev Architecture: source i386 all Version: 3.1.2-3 Distribution: unstable Urgency: low Maintainer: Shaun Jackman [EMAIL PROTECTED] Changed-By: Shaun Jackman [EMAIL PROTECTED] Description: libswt-gnome-gtk-3.1-jni - Standard Widget Toolkit for GTK Gnome JNI library libswt-gtk-3.1 - Standard Widget Toolkit for GTK native library libswt-gtk-3.1-java - Standard Widget Toolkit for GTK Java library libswt-gtk-3.1-jni - Standard Widget Toolkit for GTK JNI library libswt-gtk-dev - Standard Widget Toolkit for GTK development libswt-mozilla-gtk-3.1 - Standard Widget Toolkit for GTK Mozilla Java library libswt-mozilla-gtk-3.1-jni - Standard Widget Toolkit for GTK Mozilla JNI library libswt-mozilla-gtk-dev - Standard Widget Toolkit for GTK Mozilla JNI library Closes: 359741 364380 Changes: swt-gtk (3.1.2-3) unstable; urgency=low . * Build using java-gcj-compat-dev and gcj instead of libgcj-dev. Closes: #359741. * Build using libxul-dev instead of mozilla-dev. Closes: #364380. * Update the policy to version 3.7.2.0. No changes were necessary. Files: 830071b66c1dc0ecf971b2231d9e4afc 798 libs optional swt-gtk_3.1.2-3.dsc f62a85218b1361cb47c8f6e1fcf6f9ba 21023 libs optional swt-gtk_3.1.2-3.diff.gz 3f813e43276097ab498c47022538bb4d 15780 libdevel optional libswt-gtk-dev_3.1.2-3_all.deb 05e1dc9380342cf8b2cc06bdad10d2a0 2021654 libs optional libswt-gtk-3.1-java_3.1.2-3_all.deb a00e57dfe19f15685808ee5b6c8794d2 15544 libdevel optional libswt-mozilla-gtk-dev_3.1.2-3_all.deb 7be5e2553b0a5f9ab5190c4663e8577f 1562702 libs optional libswt-gtk-3.1_3.1.2-3_i386.deb 087100b64621577f1813be2098020358 143160 libs optional libswt-gtk-3.1-jni_3.1.2-3_i386.deb 62115a5ed9b2896a47d789160865e4c4 19668 libs optional libswt-gnome-gtk-3.1-jni_3.1.2-3_i386.deb c990311d47c742c83c5d4bcf7b6f5ae6 754446 libs optional libswt-mozilla-gtk-3.1_3.1.2-3_i386.deb 08a0c742ac6fffb60e5757e808c014aa 23894 libs optional libswt-mozilla-gtk-3.1-jni_3.1.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEe7LKvFdYF1IwUUoRAgk1AKD2J5E5uqS66SDzo2IWiEJvYqWWAwCfaClV zsgvXrDbtfZy2e4UjgHs8e8= =AKIv -END PGP SIGNATURE- Accepted: libswt-gnome-gtk-3.1-jni_3.1.2-3_i386.deb to pool/main/s/swt-gtk/libswt-gnome-gtk-3.1-jni_3.1.2-3_i386.deb libswt-gtk-3.1-java_3.1.2-3_all.deb to pool/main/s/swt-gtk/libswt-gtk-3.1-java_3.1.2-3_all.deb libswt-gtk-3.1-jni_3.1.2-3_i386.deb to pool/main/s/swt-gtk/libswt-gtk-3.1-jni_3.1.2-3_i386.deb libswt-gtk-3.1_3.1.2-3_i386.deb to pool/main/s/swt-gtk/libswt-gtk-3.1_3.1.2-3_i386.deb libswt-gtk-dev_3.1.2-3_all.deb to pool/main/s/swt-gtk/libswt-gtk-dev_3.1.2-3_all.deb libswt-mozilla-gtk-3.1-jni_3.1.2-3_i386.deb to pool/main/s/swt-gtk/libswt-mozilla-gtk-3.1-jni_3.1.2-3_i386.deb libswt-mozilla-gtk-3.1_3.1.2-3_i386.deb to pool/main/s/swt-gtk/libswt-mozilla-gtk-3.1_3.1.2-3_i386.deb libswt-mozilla-gtk-dev_3.1.2-3_all.deb to pool/main/s/swt-gtk/libswt-mozilla-gtk-dev_3.1.2-3_all.deb swt-gtk_3.1.2-3.diff.gz to pool/main/s/swt-gtk/swt-gtk_3.1.2-3.diff.gz swt-gtk_3.1.2-3.dsc to pool/main/s/swt-gtk/swt-gtk_3.1.2-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369376: please move azureus to main
On 5/29/06, Matthias Klose [EMAIL PROTECTED] wrote: Package: azureus Version: 2.4.0.2 azureus can be built using gij/gcj and be moved to main. Please consider using the upstream build procedure and do not include upstream jar files found in debian as well. A package including patches can be found at http://packages.ubuntu.com/dapper/net/azureus To which upstream jar file are you referring, exactly? $ apt-src install azureus $ cd azureus-2.4.0.2 $ find . -name *.jar |wc 0 0 0 Cheers, Shaun
Bug#369376: please move azureus to main
On 5/29/06, Matthias Klose [EMAIL PROTECTED] wrote: the bouncycastle provider. Provided by the libbcprov-java package. I see. Thanks for pointing this duplication out to me. It's the first I'd seen it. You've clearly put a fair amount of work into Ubuntu's Azureus package. Would you be interested in maintaining the Debian package as well? Cheers, Shaun
Bug#356497: Azureus Dapper Package and mozilla
On 5/27/06, Michael Koch [EMAIL PROTECTED] wrote: As said here and in the BTS several times before: On Debian SWT only works with Mozilla. We tried it with Firefox and other browsers and failed badly. On Ubuntu it works woth Firefox somehow. Ubuntu has a slightly different version of Firefox. I haven't tried swt-mozilla with any browser besides mozilla-browser. However, should it be possible to install SWT -- excluding swt-mozilla -- without installing a browser? We are working on a solution for this. But this needs some time to check the technical issues. I'll be interested to hear your results. I'd like to run swt-mozilla with firefox. BTW: Shaun: How does your wrist? Is it better? If so can you please updated your SWT/Swing/etc. packages to use GCJ 4.1 instead of 4.0. We want to remove 4.0 from the archive. Still busted. I'll have the cast off in a week though. Until then, I have to choose my projects. Updating SWT to GCJ 4.1 sounds like a good one though. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369144: toolchain-source: Confuses -linux with -linux-gnu
Package: toolchain-source Version: 3.4-5 Severity: important Building GCC for powerpc-linux fails because it's confusing powerpc-linux with powerpc-linux-gnu. Cheers, Shaun gcc-powerpc-linux-3.4.3$ fakeroot debian/rules binary ... rm -rf debian/cpp-3.4-powerpc-linux dh_installdirs -pcpp-3.4-powerpc-linux usr/share/doc usr/share/man/man1 usr/binusr/lib/gcc/powerpc-linux/3.4.4 DH_COMPAT=2 dh_movefiles -pcpp-3.4-powerpc-linux usr/bin/powerpc-linux-gnu-cpp-3.4 usr/share/man/man1/powerpc-linux-gnu-cpp-3.4.1 usr/lib/gcc/powerpc-linux/3.4.4/cc1 dh_movefiles: debian/tmp/usr/bin/powerpc-linux-gnu-cpp-3.4 not found (supposed to put it in cpp-3.4-powerpc-linux) dh_movefiles: debian/tmp/usr/share/man/man1/powerpc-linux-gnu-cpp-3.4.1 not found (supposed to put it in cpp-3.4-powerpc-linux) make[1]: *** [stamps/08-binary-stamp-cpp] Error 1 make[1]: Leaving directory `/home/sjackman/work/gamecube/src/gcc-powerpc-linux-3.4.3' make: *** [binary] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369144: toolchain-source: Confuses -linux with -linux-gnu
On 5/27/06, Shaun Jackman [EMAIL PROTECTED] wrote: Building GCC for powerpc-linux fails because it's confusing powerpc-linux with powerpc-linux-gnu. This bug is caused by using dpkg-architecture from dpkg-dev 1.13.19. Downgrading dpkg-dev to 1.10.28 works around this issue. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340998: Temporary solution
Only just today I discovered that Ubuntu's version of Azureus is compiled against Eclipse's SWT. It might be possible to install the deb package of Azureus from Ubuntu on a Debian box. Cheers, Shaun On 5/27/06, Sebastian Ley [EMAIL PROTECTED] wrote: Hi, I rebuilt azureus against the SWT which comes with Eclipse. Some minor modification needed to be done. I built a package which can be obtained here: http://www.withouthat.org/~sebastian/azureus/ Disclaimer: I won't maintain the package there. It is just a solution for me to have Azureus and Eclipse installed at the same time, which may happen to be useful to others as well. Hopefully there is a solution for the SWT stuff soon. Anyway, thanks Shaun, for the package! Regards, Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356497: Azureus Dapper Package and mozilla
On 5/26/06, Matt Philmon [EMAIL PROTECTED] wrote: Thanks Shaun. On Ubuntu (Dapper), azureus requires the package libswt3.1-gtk-java (listed as one of the Eclipse libraries), which requires mozilla-browser. It appears that the same is true with Debian. So, I guess it's really up to the packagers of Eclipse to consider using firefox instead (or setting up a mozilla | firefox | epiphany) situation. Sorry to bug you. Matt No worries, Matt. On Debian, I maintain a stand-alone version of SWT that is not part of Eclipse, named libswt-gtk-3.1-java. My package does not have the bug of depending on mozilla, but the package libswt3.1-gtk-java from Eclipse does. It's unfortunate that there are two versions of SWT in Debian at the moment. Unfortunately, there are a few unresolved technical issues. Cheers, Shaun ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#356497: Azureus Dapper Package and mozilla
On 5/26/06, Matt Philmon [EMAIL PROTECTED] wrote: Thanks Shaun. On Ubuntu (Dapper), azureus requires the package libswt3.1-gtk-java (listed as one of the Eclipse libraries), which requires mozilla-browser. It appears that the same is true with Debian. So, I guess it's really up to the packagers of Eclipse to consider using firefox instead (or setting up a mozilla | firefox | epiphany) situation. Sorry to bug you. Matt No worries, Matt. On Debian, I maintain a stand-alone version of SWT that is not part of Eclipse, named libswt-gtk-3.1-java. My package does not have the bug of depending on mozilla, but the package libswt3.1-gtk-java from Eclipse does. It's unfortunate that there are two versions of SWT in Debian at the moment. Unfortunately, there are a few unresolved technical issues. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368619: azureus: fails to start web browser
tag 368619 +confirmed thanks On 5/23/06, Johannes Rohr [EMAIL PROTECTED] wrote: ... As said above. Azureus fails to launch the web browser, e.g. from the help menu items which link to web pages. I have epiphany and firefox installed. The mozilla alternative points to /usr/bin/firefox. I cannot find any config option to set the default browser in Azureus. Also grepping the config files for mozilla or browser was unsuccessful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367390: Debian eagle package bug(?)
Package: eagle Version: 4.16-2 On 5/3/06, Thorsten Schulz [EMAIL PROTECTED] wrote: Hi Shaun, I recently upgraded to Xorg7 (I have Debian/unstable installed), and with that I also upgraded eagle to 4.16-2. But the user-interface comes up only with square blocks instead of readable font. Is this a dependecy problem?? I downgraded to stable (4.11-8) which seems to work fine. While installing that it also requested libstdc++2.10-glibc2.2 which 4.16-2 did not depend on. But even with that libstc++ installed, 4.16-2 did not work. Sorry, this is probably a bit of a crude bug report, but I have never done one before. If you need any supplementary info, I am happy to help, just tell me what ;) ciao, Thorsten Hello Thorsten, First off, sorry for the delayed reply. I'll look into this issue the next time I package eagle, which will most likely be with the next upstream release. Cheers, Shaun
Bug#285719: closed by Shaun Jackman [EMAIL PROTECTED] (Re: [Freeguide-tv-devel] FreeGuide: Debian bug clean-up)
On 5/15/06, Uwe Storbeck [EMAIL PROTECTED] wrote: Are you still seeing this bug with recent versions of FreeGuide? Does Andy's suggestion help? Sorry for the delay. Yes, Andy's suggestion seems to work, at least for version 0.8.5 and 0.8.6. Thanks, Uwe No worries. Glad to hear Andy's suggestion worked. Cheers, Shaun
[VAC] Broke my wrist, afk 3-6 weeks
I can type -- slowly -- but I won't be doing any package maintenance for three to six weeks. Cheers, Shaun
Bug#354629: acknowledged by developer (Bug#354629: fixed in bindgraph 0.2-5)
This is not the bug you are looking for. Cheers, Shaun On 5/10/06, Debian Bug Tracking System [EMAIL PROTECTED] wrote: This is an automatic notification regarding your Bug report #354629: RM: sjforth -- RoM; unmaintained, which was filed against the ftp.debian.org package. It has been closed by one of the developers, namely Jose Luis Tallon [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Forwarded message -- From: Jose Luis Tallon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 10 May 2006 17:47:11 -0700 Subject: Bug#354629: fixed in bindgraph 0.2-5 Source: bindgraph Source-Version: 0.2-5 We believe that the bug you reported is fixed in the latest version of bindgraph, which is due to be installed in the Debian FTP archive: bindgraph_0.2-5.diff.gz to pool/main/b/bindgraph/bindgraph_0.2-5.diff.gz bindgraph_0.2-5.dsc to pool/main/b/bindgraph/bindgraph_0.2-5.dsc bindgraph_0.2-5_all.deb to pool/main/b/bindgraph/bindgraph_0.2-5_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jose Luis Tallon [EMAIL PROTECTED] (supplier of updated bindgraph package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 11 May 2006 1:32:26 +0200 Source: bindgraph Binary: bindgraph Architecture: source all Version: 0.2-5 Distribution: unstable Urgency: low Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: Jose Luis Tallon [EMAIL PROTECTED] Description: bindgraph - DNS statistics RRDtool frontend for BIND9 Closes: 313156 327122 331600 331761 353101 354629 362982 Changes: bindgraph (0.2-5) unstable; urgency=low . * Acknowledge NMU. Thanks! (Closes: #354629) - Fix broken recommends (Closes: #353101). - Add debconf-2.0 alternative (Closes: #331761). - Remove /etc/default/bindgraph on purge (Closes: #327122). - Add Vietnamese debconf translation (Closes: #313156). . * l10n: - Swedish translation (Closes: #331600) - Portuguese translation (Closes: #362982) Files: 2f17f8c4f81feb9e788d09f2a6f373a1 599 admin extra bindgraph_0.2-5.dsc d488206370547aa98499365b248170f8 16981 admin extra bindgraph_0.2-5.diff.gz 769a501f19fe30b7271298c29b733765 19400 admin extra bindgraph_0.2-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEYohFipBneRiAKDwRAomJAJ4mMR+W8DTqwjS8/UsMM50tPBQFEgCfXhNC MpmFKFMi9cb0RRe+E+l2SFw= =bYLg -END PGP SIGNATURE-
mthumb: generate a tail-call
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
Please cc me in your reply. Thanks!
Shaun
arm-elf-gcc (GCC) 4.1.0
$ cat EOF tail.c
int tail(void);
int main()
{
return tail();
}
EOF
$ arm-elf-gcc -mthumb -S -O2 tail.c
$ sed -ne '/^main/,/pop/p' tail.s
main:
push{lr}
bl tail
@ sp needed for prologue
pop {pc}
.size main, .-main
.ident GCC: (GNU) 4.1.0
$ arm-elf-gcc -S -O2 tail.c
$ sed -ne '/^main/,/pop/p' tail.s
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
b tail
.size main, .-main
.ident GCC: (GNU) 4.1.0
Bug#362699: dpkg-source: Timestamps on documentation advance artificially
clone 362699 -1 reassign -1 dpkg-dev retitle -1 dpkg-source: Timestamps on documentation advance artificially severity -1 normal thanks When dpkg-source applies the patch, the time stamp on each of the patched files advances artificially. This makes it look as though the documentation in /usr/share/doc/ has been modified recently at the time the patch was applied, rather than its actual modification date. See also... dpkg-dev [DPKG-SOURCE] touch all patched files to avoid race conditions http://bugs.debian.org/105750 dpkg-dev [DPKG-SOURCE] applying patch causes timestamps to skew and upset make http://bugs.debian.org/208276 debhelper Feature request: dh_fixtimestamps http://bugs.debian.org/362699 Quoting from #208276... 9/1/03 Dirk Eddelbuettel replies to Daniel Schepler: I've heard this is going to be fixed in dpkg-source v2, by saving time stamps in the diff.gz. Yes, agreed. This patching/timestamp issue is old. Cheers, Shaun
Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
On 5/9/06, A. Costa [EMAIL PROTECTED] wrote: If you're too busy to report it I'd do it, but probably not half as well, since I haven't yet used 'dpkg-source' and don't quite know what to look for. The symptoms seem plain enough though. OK, done. You should see a report on dpkg-dev soon. Thanks for bugging me. =P 9/1/03 Dirk Eddelbuettel replies to Daniel Schepler: I've heard this is going to be fixed in dpkg-source v2, by saving time stamps in the diff.gz. Yes, agreed. This patching/timestamp issue is old. This issue is quite clear-cut and really ought to be fixed. It's a semi-major change, but I would certainly suggest issuign a new release of dpkg-dev that adds only this one feature. Let people acclimatise to it, and I'm sure the world wouldn't end. I don't think it's necessary to wait for the mythical dpkg-dev v2. ...Either way though, I'd agree that it would be useful for our purposes to have time stamps in patches, unless there are compelling though seldom heard reasons not to. I would be interested to hear any argument against including the time stamp information in the .diff.gz. sounds of crickets chirping I want to go camping in the country now. smirk Cheers, Shaun
Bug#364706: azureus bug
On 5/9/06, Lex Hider [EMAIL PROTECTED] wrote: http://sourceforge.net/tracker/index.php?func=detailaid=1474796group_id=84122atid=575154 Thanks for making the connection to the upstream bug, Lex! It explains a lot. This bug seems specific to running Xorg 7 -- I run Xorg 6.9 myself -- and I've filed a bug against Xorg 7. Mystery solved. Cheers, Shaun
Bug#364706: azureus
On 5/9/06, Lex Hider [EMAIL PROTECTED] wrote: which xorg bug is that? http://bugs.debian.org/366557
Bug#364706: me too
Great! I look forward to your troubleshooting and response. Cheers, Shaun On 5/8/06, Lex Hider [EMAIL PROTECTED] wrote: I to am having this problem. I get the warning popup in the bottom right corner, and hitting hide or hide all does nothing. Am running sid with azureus 2.4.0.2-1 sun package made with java-package sun-j2re1.5 1.5.0+update06 I too will try to isolate where the problem is. One thing I have eliminated is any issue with file in ~/.azureus/ I wiped .azureus and ran azureus again and still had the same issue that this bug is about. Will keep you posted, Lex.
Bug#366346: HOWTO/README: dead link
Package: toolchain-source Version: 3.4-5 /usr/share/doc/toolchain-source/HOWTO/README contains a dead link to http://people.debian.org/~debacle/cross.html Cheers, Shaun
Re: [Monotone-devel] [PATCH] monotone 0.25-0.1
On 5/3/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: ... Wasn't it concluded that we (monotone ppl) would use the 0.25-0.x standard, and that Debian maintainers would use 0.25-y, so there would be a difference between us and Debian? Right now, you're patch clashes with an already existing 0.25-0.1 entry, and I simply cannot see myself overriding that. There's not a lot of choice when picking a version number. 0.25-0.1 is the recommended version number for a new upstream version NMU. In fact, the reason you use -0.1 is because, if it were uploaded, it would be an NMU. Only the maintainer may upload -1, but he's missing-in-action. Since my 0.25-0.1 release has been uploaded and accepted, I'd recommend keeping the monotone debian/ directory in sync with Debian's. In the future, I'll post my changelog entry here before uploading to Debian. Sorry for the confusion. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Bug#364706: azureus: Also unable to close the warning window
Thanks for the added info, Lauri. I've been unable to reproduce this bug. It has me mystified. I've tried using different window managers. I'm not sure which software component is the root-cause of this bug. If this bug ever `goes away' for you, I'd be really interested to hear what you think might have been the cause. Cheers, Shaun On 5/4/06, Lauri Alanko [EMAIL PROTECTED] wrote: Just another data point here. After upgrading to 2.4.0.2, the warning window wouldn't close if I click hide. My window manager is ion3, and I'm using a patched version of libswt-gtk-3.1-java, since #354358 still hasn't been closed.
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
On 5/4/06, Lauri Alanko [EMAIL PROTECTED] wrote: May I ask what exactly is preventing this bug from being fixed? As I told two months ago, it seems that the problem is only that upstream's 64-bit sources aren't used by the package on amd64. When I applied the changes between the 32-bit and 64-bit upstream sources to the build tree, everything worked, and has worked now for two months. The only problem is the window closing in azureus 2.4.0.2, but I suspect that is not related to SWT. I see this bug has been tagged upstream, but the upstream sources are just fine, they are just used wrong by the debian package. So what is preventing from including the 64-bit parts in the debian package and closing the bug? Maintaining a package by creating a giant '64-bit' patch by hand for every release does not make a maintainable package. It makes a disaster. The problem is that upstream continues to release one source tarball for 32-bit architectures and a separate source tarball for 64-bit architectures. Neither of these packages contains the ant scripts that they use to create one from the other. For the intents of a Debian maintainer, upstream essentially does not release a source package of SWT *at all*, since it does not contain the necessary scripts to actually build the package. That's why this bug is tagged upstream. Cheers, Shaun
Bug#364706: azureus: unable to close warning window too
On 5/3/06, Edward J. Shornock [EMAIL PROTECTED] wrote: I also have the problem of not being able to close the warning window. Thanks for the report. If, between the three of you bug reporters, you could figure out what you have in common, I'd much appreciate it. Cheers, Shaun
Bug#354358: libswt-gtk-3.1-java: Unusable on amd64 (ia32-specific sources used)
On 5/4/06, Lauri Alanko [EMAIL PROTECTED] wrote: May I ask what exactly is preventing this bug from being fixed? As I told two months ago, it seems that the problem is only that upstream's 64-bit sources aren't used by the package on amd64. When I applied the changes between the 32-bit and 64-bit upstream sources to the build tree, everything worked, and has worked now for two months. The only problem is the window closing in azureus 2.4.0.2, but I suspect that is not related to SWT. I see this bug has been tagged upstream, but the upstream sources are just fine, they are just used wrong by the debian package. So what is preventing from including the 64-bit parts in the debian package and closing the bug? Maintaining a package by creating a giant '64-bit' patch by hand for every release does not make a maintainable package. It makes a disaster. The problem is that upstream continues to release one source tarball for 32-bit architectures and a separate source tarball for 64-bit architectures. Neither of these packages contains the ant scripts that they use to create one from the other. For the intents of a Debian maintainer, upstream essentially does not release a source package of SWT *at all*, since it does not contain the necessary scripts to actually build the package. That's why this bug is tagged upstream. Cheers, Shaun
Bug#361719: [libnjb-users] RFA: libnjb - Creative Labs Nomad Jukebox library
On 4/29/06, John Bovey [EMAIL PROTECTED] wrote: I do have Lintian and Linda installed but I didn't look carefully enough at the output. The new build is attached. I've uploaded the new build to the Debian archive. Congratulations on completing your first package! Cheers, Shaun
Bug#364706: azureus: Unable to close Warning window
On 4/26/06, Huy Duong [EMAIL PROTECTED] wrote: Hi Shaun, Here's the info from the azureus About screen: Java 1.5.0_04 Sun Microsystems Inc. SWT v3139, gtk Linux v2.6.14, i386 Same as me, for the most part. I tried switching window manager to sawfish, but I got the same problem, so it doesn't seem to be related to the window manager. I'm not sure what else could be affecting the behaviour. Anyway, thanks for the help. No worries at all, but I've run out of ideas. If your problem ever goes away by magic, please write me back. Cheers, Shaun
Accepted monotone 0.25-0.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 17 Apr 2006 16:46:54 -0600 Source: monotone Binary: monotone Architecture: source i386 Version: 0.25-0.1 Distribution: unstable Urgency: low Maintainer: Tomas Fasth [EMAIL PROTECTED] Changed-By: Shaun Jackman [EMAIL PROTECTED] Description: monotone - A distributed version (revision) control system Closes: 358096 358220 Changes: monotone (0.25-0.1) unstable; urgency=low . * Non-maintainer upload (NMU). * New upstream release. Closes: #358220. - Fix build with G++ 4.1. Closes: #358096. * Add a watch file. Files: f26bd4a78b38e3a7e6d99938b9ab3e65 766 devel optional monotone_0.25-0.1.dsc fb0ad449cd0093854c55dbd5c6fc07e2 5415426 devel optional monotone_0.25.orig.tar.gz f772845a25213b1729e98ea1db16a66b 939 devel optional monotone_0.25-0.1.diff.gz 92d9af817ed4bf4dccc7ded6bc263601 3866996 devel optional monotone_0.25-0.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEROgPvFdYF1IwUUoRAthoAJ4mMfyLp04ocFf82e/k+BnvOKzUQgCg3zLo lyKhG6KNk9cBsZSrYel4f60= =rStW -END PGP SIGNATURE- Accepted: monotone_0.25-0.1.diff.gz to pool/main/m/monotone/monotone_0.25-0.1.diff.gz monotone_0.25-0.1.dsc to pool/main/m/monotone/monotone_0.25-0.1.dsc monotone_0.25-0.1_i386.deb to pool/main/m/monotone/monotone_0.25-0.1_i386.deb monotone_0.25.orig.tar.gz to pool/main/m/monotone/monotone_0.25.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
On 4/26/06, A. Costa [EMAIL PROTECTED] wrote: On Sat, 22 Apr 2006 14:10:23 -0600 Shaun Jackman [EMAIL PROTECTED] wrote: The bug probably shouldn't be closed. I would tag it wontfix, and post it on debian-devel for discussion. I'm with you for reopening and reclassifying, but I don't mix well with '-devel', so far anyway. Irreconcilable humor differences, maybe. Hold off on the debhelper bug for now, perhaps. The dpkg-source utility from the dpkg-dev package seems like a better place to start. That dpkg-source doesn't preserve time stamps is a straight-forward bug. Has it been reported already? Not yet. Likewise for the Debian diff. All the Debian packaging, including documentation, is packaged in the diff, and by default, debuild does not preserve the time stamp meta-data in the diff. I don't know why this is though, because diff does, by default, preserve the time stamp meta-data. A question... my typo fixes all use '.diff' files. I used to use the default 'diff' format which looked like this: ... ...then as per the useful critique of C. Wilson, I started using the '-u' switch: ... Now it looks like the latter 'diff -u' keeps a time stamp, while the former (default) 'diff' does not. But you're saying that the default of 'diff' does preserve time stamps. Seems like a mix-up. Debian uses (and most of the open-source world) uses unified (-u) diffs. I meant diff -u includes the time stamp information by default. Either way though, I'd agree that it would be useful for our purposes to have time stamps in patches, unless there are compelling though seldom heard reasons not to. I would be interested to hear any argument against including the time stamp information in the .diff.gz. Cheers, Shaun
Bug#354358: RM: swt-gtk [ia64] -- RoM; SIGSEGV
Package: ftp.debian.org swt-gtk 3.0-6 (in sarge) does not work on ia64. It dies with a SIGSEGV. Please remove the binary packages. libswt-gtk3_3.0-6_ia64.deb libswt-gtk3-jni_3.0-6_ia64.deb libswt-mozilla3-jni_3.0-6_ia64.deb Thanks, Shaun On 4/26/06, Shaun Jackman [EMAIL PROTECTED] wrote: On 4/26/06, Ian Wienand [EMAIL PROTECTED] wrote: On Wed, Apr 26, 2006 at 10:13:05AM -0600, Shaun Jackman wrote: Try... $ java -Djava.library.path=/usr/lib/jni:/usr/lib \ -classpath .:/usr/share/java/swt-gtk-3.jar:/usr/share/java/swt-pi-gtk-3.jar Hello Ok, we have lift-off. Well, it launches but then crashes. Error log attached. Excellent detective work! I suspected SWT never worked on any 64-bit architecture. This confirms one architecture. I'll file a bug against ftp.debian.org to remove swt-gtk 3.0-6 for ia64. Then I can concentrate my effort on getting SWT 3.1.2 working on amd64, and hopefully the other 64-bit architectures by extension. Thanks for your help, Shaun
Bug#354358: RFH: Please test swt-gtk on ia64
On 4/26/06, Ian Wienand [EMAIL PROTECTED] wrote: On Wed, Apr 26, 2006 at 10:13:05AM -0600, Shaun Jackman wrote: Try... $ java -Djava.library.path=/usr/lib/jni:/usr/lib \ -classpath .:/usr/share/java/swt-gtk-3.jar:/usr/share/java/swt-pi-gtk-3.jar Hello Ok, we have lift-off. Well, it launches but then crashes. Error log attached. -i Excellent detective work! I suspected SWT never worked on any 64-bit architecture. This confirms one architecture. I'll file a bug against ftp.debian.org to remove swt-gtk 3.0-6 for ia64. Then I can concentrate my effort on getting SWT 3.1.2 working on amd64, and hopefully the other 64-bit architectures by extension. Thanks for your help, Shaun
Re: RFH: Please test swt-gtk on ia64
On 4/26/06, Ian Wienand [EMAIL PROTECTED] wrote: On Wed, Apr 26, 2006 at 10:13:05AM -0600, Shaun Jackman wrote: Try... $ java -Djava.library.path=/usr/lib/jni:/usr/lib \ -classpath .:/usr/share/java/swt-gtk-3.jar:/usr/share/java/swt-pi-gtk-3.jar Hello Ok, we have lift-off. Well, it launches but then crashes. Error log attached. -i Excellent detective work! I suspected SWT never worked on any 64-bit architecture. This confirms one architecture. I'll file a bug against ftp.debian.org to remove swt-gtk 3.0-6 for ia64. Then I can concentrate my effort on getting SWT 3.1.2 working on amd64, and hopefully the other 64-bit architectures by extension. Thanks for your help, Shaun
RM: swt-gtk [ia64] -- RoM; SIGSEGV
Package: ftp.debian.org swt-gtk 3.0-6 (in sarge) does not work on ia64. It dies with a SIGSEGV. Please remove the binary packages. libswt-gtk3_3.0-6_ia64.deb libswt-gtk3-jni_3.0-6_ia64.deb libswt-mozilla3-jni_3.0-6_ia64.deb Thanks, Shaun On 4/26/06, Shaun Jackman [EMAIL PROTECTED] wrote: On 4/26/06, Ian Wienand [EMAIL PROTECTED] wrote: On Wed, Apr 26, 2006 at 10:13:05AM -0600, Shaun Jackman wrote: Try... $ java -Djava.library.path=/usr/lib/jni:/usr/lib \ -classpath .:/usr/share/java/swt-gtk-3.jar:/usr/share/java/swt-pi-gtk-3.jar Hello Ok, we have lift-off. Well, it launches but then crashes. Error log attached. Excellent detective work! I suspected SWT never worked on any 64-bit architecture. This confirms one architecture. I'll file a bug against ftp.debian.org to remove swt-gtk 3.0-6 for ia64. Then I can concentrate my effort on getting SWT 3.1.2 working on amd64, and hopefully the other 64-bit architectures by extension. Thanks for your help, Shaun
Bug#354358: RM: swt-gtk [ia64] -- RoM; SIGSEGV
Package: ftp.debian.org swt-gtk 3.0-6 (in sarge) does not work on ia64. It dies with a SIGSEGV. Please remove the binary packages. libswt-gtk3_3.0-6_ia64.deb libswt-gtk3-jni_3.0-6_ia64.deb libswt-mozilla3-jni_3.0-6_ia64.deb Thanks, Shaun On 4/26/06, Shaun Jackman [EMAIL PROTECTED] wrote: On 4/26/06, Ian Wienand [EMAIL PROTECTED] wrote: On Wed, Apr 26, 2006 at 10:13:05AM -0600, Shaun Jackman wrote: Try... $ java -Djava.library.path=/usr/lib/jni:/usr/lib \ -classpath .:/usr/share/java/swt-gtk-3.jar:/usr/share/java/swt-pi-gtk-3.jar Hello Ok, we have lift-off. Well, it launches but then crashes. Error log attached. Excellent detective work! I suspected SWT never worked on any 64-bit architecture. This confirms one architecture. I'll file a bug against ftp.debian.org to remove swt-gtk 3.0-6 for ia64. Then I can concentrate my effort on getting SWT 3.1.2 working on amd64, and hopefully the other 64-bit architectures by extension. Thanks for your help, Shaun
Bug#354358: RFH: Please test swt-gtk on ia64
On 4/26/06, Ian Wienand [EMAIL PROTECTED] wrote: On Wed, Apr 26, 2006 at 10:13:05AM -0600, Shaun Jackman wrote: Try... $ java -Djava.library.path=/usr/lib/jni:/usr/lib \ -classpath .:/usr/share/java/swt-gtk-3.jar:/usr/share/java/swt-pi-gtk-3.jar Hello Ok, we have lift-off. Well, it launches but then crashes. Error log attached. -i Excellent detective work! I suspected SWT never worked on any 64-bit architecture. This confirms one architecture. I'll file a bug against ftp.debian.org to remove swt-gtk 3.0-6 for ia64. Then I can concentrate my effort on getting SWT 3.1.2 working on amd64, and hopefully the other 64-bit architectures by extension. Thanks for your help, Shaun
Bug#364706: azureus: Unable to close Warning window
Did this happen just once or every time you start Azureus? Cheers, Shaun On 4/25/06, Huy Duong [EMAIL PROTECTED] wrote: Package: azureus Version: 2.4.0.2-1 Severity: normal I was using Azureus when it suddenly shutdown due to a NullPointerException (already reported to Azureus dev). When I re-ran Azureus, a Warning dialog opens in the lower right corner telling me that Azureus did not shutdown tidilty I try to click on the Hide button to close the window but it does not close. When the mouse hovers over the button, it highlights, so it seems like the button is receiving the proper events, but clicking on the button doesn't cause it to do anything. I'm not sure if this is a problem with Azureus or the window manager (I'm using metacity), but I'm assuming it is Azureus as I don't have this problem with other apps. Thanks, -hd
Bug#364706: azureus: Unable to close Warning window
Hello Huy, I tested azureus 2.4.0.2-1 with libswt-gtk-3.1-java 3.1.2-2 and sun-j2sdk1.5 1.5.0+update04, which is your exact setup, and was unable to reproduce the bug. I ran... $ azureus $ kill -KILL %% $ azureus ... to shut down azureus uncleanly and restart azureus. I saw the Warning dialog, but I was able to close it with the Hide button. I use kwin 4:3.3.2-1sarge1. I also tested against metacity 2.12.3-3 and was unable to reproduce this bug. Can you run `java -version' and `/usr/sbin/update-alternatives --display java' for me? Thanks, Shaun On 4/25/06, Huy Duong [EMAIL PROTECTED] wrote: Hi Shaun, The Warning dialog in question only appears once after an unexpected shutdown of the application. In order to get rid of the dialog, I have to close Azureus and restart it. The same problem has occurred in another instance where Azureus lost its connection to the UPnP service on my Linksys router. A warning dialog pops up in the lower-right corner of the screen advising me of the problem, but I am unable to close the dialog box by clicking on the Hide button. I suppose you can test the problem by killing the app from a console so that you can see the dialog window in question. The problem does not prevent me from using the app, but the dialog window remains on top at all times and stays on the screen even when switching to other virtual desktops. Its quite annoying, especially when a torrent is going especially fast and I don't want to shutdown the app. -hd
Bug#364820: Add /usr/lib/jni to the default java.library.path
Package: gcj-4.0 Version: 4:4.0.3-3 Severity: important Justification: violates a *should* directive of the Debian Policy for Java The default java.library.path of applications compiled using gcj does not include /usr/lib/jni. The Debian Policy for Java [1] states that /usr/lib/jni *should* be the default. $ gcj -I/usr/share/java/swt.jar Hello.java -lswt -lswt-pi --main=Hello -oHello $ ./Hello Exception in thread main java.lang.UnsatisfiedLinkError: libswt-pi-gtk-3139: libswt-pi-gtk-3139.so: cannot open shared object file: No such file or directory at java.lang.Runtime._load(java.lang.String, boolean) (/usr/lib/libgcj.so.6.0.0) ... $ LD_LIBRARY_PATH=/usr/lib/jni ./Hello [works] The rpath can be used, although this is not recomended by Debian policy. $ gcj -I/usr/share/java/swt.jar Hello.java -lswt -lswt-pi --main=Hello -oHello -Wl,-rpath,/usr/lib/jni $ ./Hello [works] ... or /usr/lib/jni can be added to /etc/ld.so.conf. $ sudo sh -c 'echo /usr/lib/jni /etc/ld.so.conf' $ sudo ldconfig $ ./Hello [works] However, I'd like to see /usr/lib/jni added to the default java.library.path of an application compiled with gcj. Cheers, Shaun [1] http://www.debian.org/doc/packaging-manuals/java-policy/x105.html
Bug#364820: Add /usr/lib/jni to the default java.library.path
On 4/25/06, Shaun Jackman [EMAIL PROTECTED] wrote: Package: gcj-4.0 Version: 4:4.0.3-3 Severity: important Justification: violates a *should* directive of the Debian Policy for Java ... [1] http://www.debian.org/doc/packaging-manuals/java-policy/x105.html It seems that a package `should' put the JNI solib in /usr/lib/jni; however, the virtual machine must include the directory /usr/lib/jni in its search path for these dynamic libraries. [1] Violating a `must' directive of the Debian Policy for Java is surely a release critical issue. Cheers, Shaun [1] http://www.debian.org/doc/packaging-manuals/java-policy/c36.html
Bug#364706: azureus: Unable to close Warning window
package azureus tag 364706 unreproducible thanks Hello Huy, On 4/25/06, Huy Duong [EMAIL PROTECTED] wrote: Here's the output you requested: ... These look fine. As for metacity, I'm using 2.14.1-1 I just tested 2.14.1-1, I don't see the bug there either. When my mouse hovers over the button, nothing happens. I wonder why your button widget is behaving differently. Can you select Help / About Azureus and tell me what the System information in the bottom right says? Mine says... Java 1.5.0_04 Sun Microsystems Inc. SWT v3139, gtk Linux v2.6.15-1-k7, i386 Cheers, Shaun
Re: RFH: Please test swt-gtk on ia64
On 4/25/06, Ian Wienand [EMAIL PROTECTED] wrote:
The azureus package is `Arch: all' and shouldn't require rebuilding.
Could you install libswt-gtk3-jni 3.0-6 (Arch: any) and azureus
2.2.0.2-1 (Arch: all), and test azureus?
(sorry, I've been away)
If we're talking about the same thing (and maybe we're not) the
Azureus package at
http://packages.debian.org/stable/net/azureus
is i386 only (from the control file). It has a few .so's which I
guess is why. As I mentioned, I tried to build it for ia64, but can't
get the dependencies.
You're right. I forgot azureus 2.2.0.2-1 was monolithic and came with
its own version of SWT. If you're die-hard, you should be able to
extract the Azureus2.jar from the i386 deb and test it. However, all I
really want to do is test SWT. To that end, the attached Hello.class
(using SWT) should work just fine. I've attached the source and a
compiled .class file.
Thanks for your help with this porting predicament.
Cheers,
Shaun
$ javac -classpath /usr/share/java/swt.jar Hello.java
$ java -Djava.library.path=/usr/lib/jni:/usr/lib \
-classpath .:/usr/share/java/swt.jar \
Hello $@
import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;
public class Hello {
public static void main(String[] args)
{
Display display = new Display();
Shell shell = new Shell(display);
shell.setText(Hello World);
shell.open ();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep ();
}
display.dispose ();
}
}
Hello.class
Description: Binary data
Bug#364820: Add /usr/lib/jni to the default java.library.path
On 4/25/06, Shaun Jackman [EMAIL PROTECTED] wrote: Package: gcj-4.0 Version: 4:4.0.3-3 Severity: important Justification: violates a *should* directive of the Debian Policy for Java ... [1] http://www.debian.org/doc/packaging-manuals/java-policy/x105.html It seems that a package `should' put the JNI solib in /usr/lib/jni; however, the virtual machine must include the directory /usr/lib/jni in its search path for these dynamic libraries. [1] Violating a `must' directive of the Debian Policy for Java is surely a release critical issue. Cheers, Shaun [1] http://www.debian.org/doc/packaging-manuals/java-policy/c36.html
Bug#361719: [libnjb-users] RFA: libnjb - Creative Labs Nomad Jukebox library
Excellent progress, John! Send me a .diff.gz, .dsc, .deb, and .changes, just as soon as you have them. After looking 'em over, I'll sponsor the upload changing maintainership of the package and advocate for you. Cheers, Shaun On 4/24/06, John Bovey [EMAIL PROTECTED] wrote: Shaun, I have started the Debian Developer application process. The page where you need to confirm that you will advocate is https://nm.debian.org/nmadvocate.php?email=jdb%40kent.ac.uk I have been quite busy for the last few days but I plan to do the repackaging of libnjb on Wednesday. Regards, John
Bug#361719: [libnjb-users] RFA: libnjb - Creative Labs Nomad Jukebox library
Excellent progress, John! Send me a .diff.gz, .dsc, .deb, and .changes, just as soon as you have them. After looking 'em over, I'll sponsor the upload changing maintainership of the package and advocate for you. Cheers, Shaun On 4/24/06, John Bovey [EMAIL PROTECTED] wrote: Shaun, I have started the Debian Developer application process. The page where you need to confirm that you will advocate is https://nm.debian.org/nmadvocate.php?email=jdb%40kent.ac.uk I have been quite busy for the last few days but I plan to do the repackaging of libnjb on Wednesday. Regards, John
Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
On 4/22/06, A. Costa [EMAIL PROTECTED] wrote: ... I'm going to reassign this bug as a wishlist item to the debhelper package. Thanks for making the call, but just as the little bug was a symptom of a bigger systemic bug, now the bigger bug closing is perhaps a symptom of the biggest bug yet; the BTS makes it very easy for overworked maintainers to forget what they're doing here, and maintainers are their own guardians. (And on the whole, they do a great job, considering human nature...) To elaborate, the maintainer of 'debhelper' sees that the wishlist remedy seems to contradict his vision of packaging simplicity and elegance; fair enough, but then he forgets that the origin of this bug was a symptom, not a proposed remedy -- that is, closing the wishlist bug neither solves the problem of useful date information being lost in '/usr/share/doc' nor addresses the symptom in 'freeguide'. Assuming that a wishlist was indeed a bad idea, then to make the best use of the BTS, the bug should be reclassified to wherever it best fits; or put aside until it makes more sense. For example, it might be reassigned back to 'freeguide' and tagged 'upstream' or 'wontfix'. The bug probably shouldn't be closed. I would tag it wontfix, and post it on debian-devel for discussion. That dpkg-source doesn't preserve time stamps is a straight-forward bug. Preferably, the installed document should have the same time stamp as the document's source file. Preferably, but I'm thinking of cases where the automated conversion adds or subtracts enough data to make its revision noteworthy. Suppose a man2info converter deletes boilerplate paragraphs about see the info page since those are redundant in the info page itself. Would that be different enough to deserve a new date? Any conversion performed on a regular, automated basis doesn't warrant updating the time stamp. However, if a developer runs help2man once by hand to create a man page, I would update the time stamp. I'm afraid fixing the time stamps of the Debian documentation is actually *harder* than fixing the time stamps of the upstream documentation. The Debian documentation is distributed in a patch ... Perhaps I've misunderstood what you're saying about Debian's patch system. Did you mean that all patches, old or new, are born yesterday on unpacking? Exactly. Time stamp information is meta-data, and a lot of mediums don't preserve meta-data. For example, when a document is attached to an email, typically the time stamps, permissions, et cetera are all lost. Likewise for the Debian diff. All the Debian packaging, including documentation, is packaged in the diff, and by default, debuild does not preserve the time stamp meta-data in the diff. I don't know why this is though, because diff does, by default, preserve the time stamp meta-data. Cheers, Shaun
Bug#364338: kernel-image-2.4.27-3-k7: Failed to create initrd image.
Package: kernel-image-2.4.27-3-k7 Version: 2.4.27-10sarge2 Severity: normal Unpacking kernel-image-2.4.27-3-k7 (from .../kernel-image-2.4.27-3-k7_2.4.27-10sarge2_i386.deb) ... Selecting previously deselected package kernel-image-2.4-k7. Unpacking kernel-image-2.4-k7 (from .../kernel-image-2.4-k7_101sarge1_i386.deb)... Setting up kernel-image-2.4.27-3-k7 (2.4.27-10sarge2) ... /bin/bash: error while loading shared libraries: libdl.so.2: cannot open sharedobject file: No such file or directory Failed to create initrd image. dpkg: error processing kernel-image-2.4.27-3-k7 (--configure): subprocess post-installation script returned error exit status 9 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (499, 'testing'), (498, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.15-1-k7 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages kernel-image-2.4.27-3-k7 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii modutils 2.4.26-1.2 Linux module utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Monotone-devel] One person in many places
On 7/25/05, Shaun Jackman [EMAIL PROTECTED] wrote: On 7/25/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: Nonsense. All you need to require is that each *private* key has a unique keyid. And honestly, who would want to have two private keys with the same keyid in the same database? I've run into a problem involving exactly this. Before I really understood monotone's concept of databases and keys, I created two projects each with their own db and each with their own private key, although both keys have the same keyid. I'd now like to serve both projects out of the same database, but I can't push changes from one to the other because... monotone: warning: saving public key for [EMAIL PROTECTED] to database monotone: error: another key with name '[EMAIL PROTECTED]' already exists Any suggestion on how to remedy this? Can I rename the keyid in one of the databases after the fact? With the wonder of ~/.monotone/keys this is now fairly straight forward. The two keys both had a keyid of [EMAIL PROTECTED] I renamed one of the keys to ~/.monotone/keys/[EMAIL PROTECTED] In my busybox database, which was signed with the [EMAIL PROTECTED] while it was still named [EMAIL PROTECTED], I used this SQL call to rename the key in the database: mtn db execute 'update revision_certs set keypair = [EMAIL PROTECTED] where keypair = [EMAIL PROTECTED]' I've now relegated that old key to legacy, and I sign all my new changes with [EMAIL PROTECTED] One thing I didn't expect, but I understand now, is that `mtn log' and monotone-viz still show [EMAIL PROTECTED] as the author for *all* the changes, old and new. I now understand that both front-ends are simply showing the value of the `author' cert, which hasn't changed and is still [EMAIL PROTECTED] However, that cert is now signed by the [EMAIL PROTECTED] key. This make absolute sense; Alice can certainly certify that Bob is the author of a given revision. What's interesting though, is that the UI only shows that Bob is the author, and this cert is signed, but it doesn't show *who* signed it. Now that I understand this separation of keyid and author, I'd like to use Shaun Jackman [EMAIL PROTECTED] for all my future author certs. Besides being more descriptive, this aids generating ChangeLog entires from monotone logs. Is there a LUA hook to change one's preferred author cert? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: About the maintainance of monotone
On 4/18/06, Shaun Jackman [EMAIL PROTECTED] wrote: After fixing these minor issues, the NMU package would be suitable for uploading. Would anyone like to first test it out? I've posted my monotone 0.25-0.1 packages: http://people.debian.org/~sjackman/debian/pool/main/m/monotone/ I've uploaded monotone 0.25-0.1 to the delayed 7-day queue. Without intervention from the maintainer, it will move to Debian's master queue in seven days. I've also uploaded monotone 0.26-0.1 to people.debian.org/~sjackman. I have *not* tested this binary, because I have not yet made the move to rosters. Once I have, I'll post my experience and upload 0.26-0.1 to the delayed 7-day queue. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] One person in many places
On 4/20/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Thu, 20 Apr 2006 09:55:54 -0600, Shaun Jackman [EMAIL PROTECTED] said: sjackman One thing I didn't expect, but I understand now, is that sjackman `mtn log' and monotone-viz still show [EMAIL PROTECTED] as sjackman the author for *all* the changes, old and new. [...] What's sjackman interesting though, is that the UI only shows that Bob is sjackman the author, and this cert is signed, but it doesn't show sjackman *who* signed it. Well, monotone-viz will show you who signed each cert. You just have to scroll the log box (bottom left one) horizontally way to the right. I stand corrected. Thanks for pointing this out, Richard! Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
