Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: DSA concerns for jessie architectures
On Sun, Jul 21, 2013 at 09:06:31PM +0200, Bernd Zeimetz wrote: On 06/22/2013 07:26 PM, Martin Zobel-Helas wrote: * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. I think all machines except stadler and sompek are US IIIi machines. The problem with US IIIi is, that sun never published the cpu specs - they would have done it if somebody would have paid for the lawyers to look trough them before publishing. US IIi support was implemented by a student working at SUN under NDA and US IV and later was published. So I think if dropping (official) support for US IIIi CPUs would keep the port alive, we should do that. Running Debian on the more recent machines makes more sense anyway imho. The older ones are nice, but they consume a lt of power. If you drop support for US II and IIIi, we basicly have 2 boxes left, of which one acts as sparc buildd and the other as sparc64 and sparc buildd. Those 2 boxes in their current state really can't keep up, specially since they're not stable at all when trying to use multiple cores. You would also be missing a porterbox. I thought the plan was to drop 32 bit support and move to sparc64? But that still doesn't seem to have moved to the Debian archive. Is there something holding back moving to sparc64? There is also Matthias Klose mail asking what to do with gcc. sparc is still on gcc-4.6 and I think he isn't willing to maintain that any longer. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130808173254.ga25...@roeckx.be
Re: mixed up LDFLAGS on amd64 buildds?
On Fri, Jun 01, 2012 at 04:19:30PM +0700, Daniel Glassey wrote: Hi, My package grcompiler version 4.2~pre5 is failing to build on the amd64 buildd brahms and now barber as well. The log is for 4.2~pre5-2 on brahms is at: https://buildd.debian.org/status/fetch.php?pkg=grcompilerarch=amd64ver=4.2~pre5-1stamp=1338365349 The log is for 4.2~pre5-2 on barber at: https://buildd.debian.org/status/fetch.php?pkg=grcompilerarch=amd64ver=4.2~pre5-2stamp=1338528478 In 4.2~pre5-2 debhelper 9 is being used so it is supposed to be getting the hardening flags gcc -DPACKAGE_NAME=\grcompiler\ -DPACKAGE_TARNAME=\grcompiler\ -DPACKAGE_VERSION=\4.2\~pre5\ -DPACKAGE_STRING=\grcompiler\ 4.2\~pre5\ -DPACKAGE_BUGREPORT=\silgraphite-de...@lists.sourceforge.net\ -DPACKAGE_URL=\\ -DPACKAGE=\grcompiler\ -DVERSION=\4.2\~pre5\ -DHAVE_ICONV=1 -DICONV_CONST= -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME=1 -I. -D_FORTIFY_SOURCE=2 -Dunix -DGDLPP -DPKGDATADIR=\/usr/share/grcompiler\ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -DNDEBUG -c -o gdlpp-usecpp.o `test -f 'usecpp.c' || echo './'`usecpp.c gcc -Dunix -DGDLPP -DPKGDATADIR=\/usr/share/grcompiler\ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -DNDEBUG -Wl,-z,relro -o gdlpp gdlpp-cpp1.o gdlpp-cpp2.o gdlpp-cpp3.o gdlpp-cpp4.o gdlpp-cpp5.o gdlpp-cpp6.o gdlpp-memory.o gdlpp-usecpp.o -fPIE -pie -Wl,-z,relro -Wl,-z,now -ldl -lm -L/usr/lib/x86_64-linux-gnu -licui18n -licuuc -licudata -ldl -lm /usr/bin/ld: gdlpp-cpp1.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC gdlpp-usecpp.o clearly wasn't build using -fPIE, which should also be in the CFLAGS (if you wanted to have PIE enabled) dpkg-buildflags shows this when enabling pie: CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-fPIE -pie -Wl,-z,relro It looks from here like LDFLAGS is being set to -fPIE -pie -Wl,-z,relro -Wl,-z,now on the build machine unconditionally and isn't coming from dpkg-buildflags. I can't replicate that on a porterbox. We do not set anything special on the buildds. We clearly don't default to enabling pie. But it looks like it's CFLAGS / LDFLAGS from a invokation of dpkg-buildflags with different DEB_BUILD_MAINT_OPTIONS The only thing we might set up in DEB_BUILD_MAINT_OPTIONS is a parallel option. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120601234439.ga4...@roeckx.be
Re: GCC-4.5 as the default for (at least some) architectures
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426192857.ga10...@roeckx.be
Re: DSO linking changes for wheezy
On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101114125148.ga26...@roeckx.be
Re: I want all my 4GB!!!
On Wed, Jul 22, 2009 at 12:23:13PM +0400, James Brown wrote: ~$ dmesg | grep BIOS [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) That is 653312 bytes = 638 KB [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000dc000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - bf68 (usable) That is 3211231232 bytes = 3062 MB = 2.99 GB [0.00] BIOS-e820: bf68 - bf70 (ACPI NVS) [0.00] BIOS-e820: bf70 - c000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) That's 268435456 bytes = 256 MB, which is not usable. [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed0 - fed00400 (reserved) [0.00] BIOS-e820: fed14000 - fed1a000 (reserved) [0.00] BIOS-e820: fed1c000 - fed9 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff00 - 0001 (reserved) [0.00] ACPI: BIOS bug: multiple APIC/MADT found, using 0 [0.00] early res: 0 [0-fff] BIOS data page [0.00] early res: 4 [9f800-f] BIOS reserved [0.004000] Calgary: detecting Calgary via BIOS EBDA area [0.264998] ACPI: BIOS _OSI(Linux) query ignored via DMI So the BIOS atleast tells you you have 3 GB of usable memory. There might be some option that changes it so that more is available, and that it's now using some compatibility option for things that do not support more than 32 bit. I suggest you look for options in your bios that might be related to that. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 64 bit LFS compile error
On Thu, May 28, 2009 at 06:18:56PM -0500, Leslie Rhorer wrote: I downloaded an application (mfs-tools) which I am trying to compile on my Debian Lenny system, but the make is failing with the following errors: gcc -DHAVE_CONFIG_H -I. -I../include -I../include-g -O2 -MT readwrite.o -MD -MP -MF .deps/readwrite.Tpo -c -o readwrite.o readwrite.c readwrite.c: In function 'tivo_partition_read': readwrite.c:146: error: 'off64_t' undeclared (first use in this function) readwrite.c:146: error: (Each undeclared identifier is reported only once readwrite.c:146: error: for each function it appears in.) readwrite.c:146: error: expected ')' before 'sector' readwrite.c:146: error: expected ')' before 'sector' readwrite.c: In function 'tivo_partition_write': readwrite.c:261: error: 'off64_t' undeclared (first use in this function) readwrite.c:261: error: expected ')' before 'sector' readwrite.c:261: error: expected ')' before 'sector' make[1]: *** [readwrite.o] Error 1 make[1]: Leaving directory `/downloads/software/mfstools-src/lib' make: *** [all-recursive] Error 1 I've searched for the error, and I found some background information, but no clear suggestions on how to resolve the issue. I submitted the issue to some Usenet groups, and one of the respondents suggested I report the issue here. Clearly, the off64_t type is not defined in any of the headers. I have glibc-source installed, and it looks to me like the type may be defined there, but the make is not seeing it. On amd64 off_t and all the others are naturally 64bit. And for 32bit code you should rather enable LFS so off_t is 64bit instead of using off64_t (adding -D_FILE_OFFSET_BITS=64). I'm sorry, but I don't quite follow your meaning. Are you saying I should replace all references to off_64t with off_t in readwrite.c? And I should add -D_FILE_OFFSET_BITS=64 to what file? off64_t does exist. You need to do define _LARGEFILE64_SOURCE (or _GNU_SOURCE), so something like: #define _LARGEFILE64_SOURCE1 #include sys/types.h Instead of using a define in the source, you can also use tell it to the compiler using gcc -D_LARGEFILE64_SOURCE=1 Instead of using off64_t, you could also use off_t and add the output of 'getconf LFS_CFLAGS' to the gcc command line. If you're using a Makefile, that would need to be added to the CFLAGS. getconf LFS_CFLAGS will output something like something like -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 on arches that need it. It will not change anything on amd64 since it's already 64 bit. Do not just always add those, it will break on some arches. If _FILE_OFFSET_BITS is defined, off_t will be replaced by an off64_t. If _LARGEFILE64_SOURCE is defined the off64_t type will be available. So what most applications want to do is use off_t and use getconf LFS_CFLAGS. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [ Experimental ] Debian kernel 2.6.28.7 amd64
On Wed, Mar 04, 2009 at 06:29:51PM -0500, Ghost Kilah wrote: Debian amd64 kernel packages Download from here : http://debian.unixcod.org linux-headers-2.6.28.7-unixcod_amd64.deb linux-image-2.6.28.7-unixcod_amd64.deb The debian kernel team provides experimental kernels at deb http://kernel-archive.buildserver.net/debian-kernel trunk main If you want an experimental kernel, I suggest you try those instead. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: off_t
On Tue, Dec 30, 2008 at 04:50:17PM +0100, Kurt Roeckx wrote:
On Tue, Dec 30, 2008 at 04:41:57PM +0100, Kurt Roeckx wrote:
On Tue, Dec 30, 2008 at 03:11:59PM +, Kai Hendry wrote:
http.c:730: error: format '%lld' expects type 'long long int', but
argument 8 has type '__off_t'
I think it's actually a long int (or just long) on amd64, since it's
already 64 bit long. I think we have 1 or 2 other arches with
the same problem.
As far as I know, there is no printf specifier for it, and
inttypes.h doesn't seem to have anything for it either.
So what you should do is make a configure test to check the size
and then use something like PRId32 / PRId64.
A configure check probably isn't needed. You can probably just
use sizeof(off_t) at compile time.
You can't use sizeof() in an #if, the package is not using configure,
so it seems the easiest way is to cast it to an intmax_t and use
%jd. I've attached a patch that does that.
Kurt
diff --git a/src/nhttpd/http.c b/src/nhttpd/http.c
index 571ed8c..d9950a7 100644
--- a/src/nhttpd/http.c
+++ b/src/nhttpd/http.c
@@ -30,6 +30,7 @@
#include syslog.h
#include time.h
#include unistd.h
+#include stdint.h
#include ../libmy/str.h
#include ../libmy/file.h
@@ -725,9 +726,9 @@ http_proc(const char *header, char *body, const int hr, const int blen,
/* create html file entry */
snprintf(tmp, sizeof(tmp),
trtd%s/tdtda href=\%s\%s/a
- /tdtd%s/tdtd%lld/td/tr\n,
+ /tdtd%s/tdtd%jd/td/tr\n,
image, dirsort[i], dirsort[i], http_date(t),
- sta.st_size);
+ (intmax_t)sta.st_size);
/* buffer full? send it! */
if (strlen(tmp) sizeof(buf) - strlen(buf)) {
@@ -1051,9 +1052,9 @@ http_alog(const int sfd, const int hr)
time(tnow);
t = localtime(tnow);
- snprintf(log_1, sizeof(log_1), %s - - %s \%s\ %d %lld,
+ snprintf(log_1, sizeof(log_1), %s - - %s \%s\ %d %jd,
c[sfd].ip, sys_date(t), c[sfd].plreq[hr], c[sfd].psta[hr],
- c[sfd].pfds[hr]);
+ (intmax_t)c[sfd].pfds[hr]);
snprintf(log_2, sizeof(log_2), \%s\ \%s\,
c[sfd].plref[hr], c[sfd].plagt[hr]);
@@ -1731,14 +1732,16 @@ http_header(const char *header_data, const char *force_status,
/* Last-Modified:, Content-Length: */
if ((h-rp_status == 200 || h-rp_status == 206) h-x_cgi == 0
h-x_idx == 0) {
- snprintf(tmp, sizeof(tmp), %s %s\r\n%s %lld\r\n,
- http_fn_lmd, h-rp_fv_dam, http_fn_clt, h-rp_fsize);
+ snprintf(tmp, sizeof(tmp), %s %s\r\n%s %jd\r\n,
+ http_fn_lmd, h-rp_fv_dam, http_fn_clt,
+ (intmax_t)h-rp_fsize);
strlcat(h-rp_header, tmp, sizeof(h-rp_header));
}
/* Content-Range: */
if (h-rp_status == 206 h-x_cgi == 0 h-x_idx == 0) {
- snprintf(tmp, sizeof(tmp), %s bytes %lld-%lld/%lld\r\n,
- http_fn_rac, h-rp_foffs, fsize - 1, fsize);
+ snprintf(tmp, sizeof(tmp), %s bytes %jd-%jd/%jd\r\n,
+ http_fn_rac, (intmax_t)h-rp_foffs,
+ (intmax_t)(fsize - 1), (intmax_t)fsize);
strlcat(h-rp_header, tmp, sizeof(h-rp_header));
}
/* Content-Type: */
Re: off_t
On Sat, Jan 24, 2009 at 06:25:58PM +, Kai Hendry wrote: Thanks Kurt! Do you approve of this GNUmakefile change too? -CCFLAGS = -O2 -pipe -Wall -Werror -Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -c +CCFLAGS = -O2 -pipe -Wall -Wstrict-prototypes $(shell getconf LFS_CFLAGS) -c I see no problem with that. It will atleast properly enable LFS support. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: off_t
On Tue, Dec 30, 2008 at 03:11:59PM +, Kai Hendry wrote: http.c:730: error: format '%lld' expects type 'long long int', but argument 8 has type '__off_t' I think it's actually a long int (or just long) on amd64, since it's already 64 bit long. I think we have 1 or 2 other arches with the same problem. As far as I know, there is no printf specifier for it, and inttypes.h doesn't seem to have anything for it either. So what you should do is make a configure test to check the size and then use something like PRId32 / PRId64. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: off_t
On Tue, Dec 30, 2008 at 04:41:57PM +0100, Kurt Roeckx wrote: On Tue, Dec 30, 2008 at 03:11:59PM +, Kai Hendry wrote: http.c:730: error: format '%lld' expects type 'long long int', but argument 8 has type '__off_t' I think it's actually a long int (or just long) on amd64, since it's already 64 bit long. I think we have 1 or 2 other arches with the same problem. As far as I know, there is no printf specifier for it, and inttypes.h doesn't seem to have anything for it either. So what you should do is make a configure test to check the size and then use something like PRId32 / PRId64. A configure check probably isn't needed. You can probably just use sizeof(off_t) at compile time. If you want to do it at configure time, make sure that you properly enable LFS support in the configure script. The proper way to get the CFLAGS for LFS support is: getconf LFS_CFLAGS Just doing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is not enough and will not work on all arches in Debian. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: broken package
On Mon, Dec 22, 2008 at 02:47:18AM -0800, Dzilberte Bekode wrote: Hi I have problem with broken postgresql package. I've accidentally deleted some postgresql files and now I can't reinstal or remove it. Also after every instalation i get: Setting up postgresql-client-7.4 (7.4.23-0etch1) ... /var/lib/dpkg/info/postgresql-client-7.4.postinst: line 5: /usr/share/postgresql-common/maintscripts-functions: No such Try reinstalling the postgresql-common package first? apt-get --reinstall install postgresql-common or dpkg -i postgresql-common_71_all.deb Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: weired message
On Sat, Dec 20, 2008 at 02:31:07PM +0100, Hans-J. Ullrich wrote: Hi all, when I start cinelerra, I always get the following message: --- void MWindow::init_shm(): Warning: /proc/sys/kernel/shmmax is 0x7ff, which is too low. Before running Cinelerra do the following as root: echo 0x7fff /proc/sys/kernel/shmmax --- So far so well, but /proc/sys/kernel/shmmax is not existent. What is this command for? I guess it allocates more ram. Do you have /proc, and is there anything in it? If not, make sure you have this in your /etc/fstab: proc /proc proc defaults 0 0 And then run mount /proc Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Several bugs dicovered: hald (or laptop-mode) and kded
On Thu, May 08, 2008 at 08:31:12PM +0200, Hans-J. Ullrich wrote: Dear maintainers, I discovered two little bugs, but I do not know, whom to report to, as I do not know, to which package it belongs. So I hope, the responsible maintainer might read it. 1. laptop-mode ist starting to early by default, or hald is starting to late. At boot I can see, that laptop-mode wants to get access to hald, but at this time, hal demaon ist not started. It will be started later in the boot process. So, I think, one of the start points should be altered per default. Which one ? I do not know I suggest you file the bug against laptop-mode-tools. If you want you can also file it against the two packages, but I'm not sure if the tool for reporting bugs allow that. 2. When starting KDE, and using kwallet, it is recommended, to enter the passwort in the opening window, as soon as it is starting. If you will not do it, and you are waiting some minutes (i.e. when your telephone rings), then the process kded amounts 100 percent of cpu-power. I do not know, to which package aor application the process kded is belonging to. I hope, one of the maintainers know. If someone can tell me, which packages are involved, I will be pleased, to file a bugreport. There is an /usr/bin/kded in kdelibs4c2a and an /usr/bin/kded4 in kdelibs-bin. You probably want the first. If it's wrong, people will reassign the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-image-amd64 unstable not pulling new kernel
On Wed, May 07, 2008 at 08:24:28AM -0500, Seb wrote: Hi, The description for linux-image-amd64 says: --cut here---start- Description: Linux image on AMD64 This package depends on the latest binary image for Linux kernel on all 64bit single- and multiprocessor AMD and Intel machines. --cut here---end--- and I have linux-image-2.6.24-1-amd64 (version 2.6.24-6), yet a new image version has been available for some time (linux-image-2.6.25-1-amd64). 'apt-get update; apt-get upgrade' doesn't pull the new package. Is this a bug in linux-image-amd64? This is just because linux-latest-2.6 hasn't been updated yet. You only install the new kernel automaticly when that package is update and you installed one of binary packages from that package like linux-image-2.6-amd64. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with reproducing bug #424643
On Tue, Apr 01, 2008 at 10:34:44PM +0200, Stefano Canepa wrote: Dear all, I'm working on apt-spy becouse I'd like to adopt this package. I don't have an AMD64 and I cannot reproduce bug #424643 [1]. On i386 on sid I have libcurl3-openssl and cannot install libcurl4-openssl. Could somebody be so kind to try to reproduce this bug and help me in figuring out if this is an apt-spy bug or a libcurl4-openssl bug as I suspect? I asked also to the man who filed the bug and I'll ask libcurl4-openssl mantainers. Note that it was filed against an old version. In the changelog for -17 I see: * segfault_418548.diff: invalid pointer causes a segfault (Closes: #418548) - Thanks to Steve Kemp for the patch I'm guessing it's a duplicate. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian 4.0r1 amd64 DVD iso files are broken on the mirrors
On Sun, Oct 28, 2007 at 01:44:52AM -0200, Luiz Guilherme Regis Emediato wrote: Hi there, I notice that the following Debian 4.0r1 amd64 DVD iso files are broken on the mirrors, that is, they are only 400MB big and the MD5SUM checksum does not return the correct values. debian-40r1-amd64-DVD-1.iso debian-40r1-amd64-DVD-2.iso debian-40r1-amd64-DVD-3.iso They're 4.4 GB, as in 400 MB bigger then 4 GB. Either the server you're using or the client you're using to download the files does not support files bigger then 2 GB. There are a few things you can do: - Try a different program to download them, for instance wget - Try a different protocol to download them. There are a few options: - ftp: wget ftp://cdimage.debian.org/debian-cd/4.0_r1/amd64/iso-dvd/debian-40r1-amd64-DVD-1.iso - http: wget http://cdimage.debian.org/debian-cd/4.0_r1/amd64/iso-dvd/debian-40r1-amd64-DVD-1.iso - rsync: rsync --progress cdimage.debian.org::debian-cd/4.0_r1/amd64/iso-dvd/debian-40r1-amd64-DVD-1.iso . - torrent: Use http://cdimage.debian.org/debian-cd/4.0_r1/amd64/bt-dvd/debian-40r1-amd64-DVD-1.iso.torrent Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian 4.0r1 amd64 DVD iso files are broken on the mirrors
On Sun, Oct 28, 2007 at 10:20:05AM -0200, Luiz Guilherme Regis Emediato wrote: Hi Kurt, Length: 401,496,064 [application/octet-stream] I get: Length: 4,696,463,360 (4.4G) [application/octet-stream] (Which is exactly 4 GB more) The version from i386 etch works, the version from i386 sarge still has the problem that it doesn't support files over 2 GB. So try one of the others, like rsync. Even the sarge version should have proper large file support. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating libc6
On Wed, Jul 25, 2007 at 11:18:56AM +0100, Pedro Sousa wrote: Preparing to replace libc6 2.3.6.ds1-13 (using .../archives/libc6_2.6-2_amd64.deb) ... Unpacking replacement libc6 ... dpkg: error processing /var/cache/apt/archives/libc6_2.6-2_amd64.deb (--unpack): trying to overwrite `/usr/lib64', which is also in package virtualbox This is clearly a bug in virtualbox. It should not be putting files in /usr/lib64, it should put them in /usr/lib instead. I suggest you first remove virtual box, then upgrade libc6, and then reinstall virtualbox. This is something you'll have to do until virtualbox is fixed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug or no bug, this is the question
On Mon, Jul 09, 2007 at 07:03:09PM +0200, Hans-J. Ullrich wrote: protheus2:/var/cache/apt/archives# LANG=C dpkg -i libc6-i386_2.6-1_amd64.deb (Reading database ... 234520 files and directories currently installed.) Preparing to replace libc6-i386 2.5-11 (using libc6-i386_2.6-1_amd64.deb) ... Unpacking replacement libc6-i386 ... dpkg: error processing libc6-i386_2.6-1_amd64.deb (--install): trying to overwrite `/usr/lib32', which is also in package lib32z1 Errors were encountered while processing: libc6-i386_2.6-1_amd64.deb This has been reported several times, and it has been fixed very recently. The problem is in lib32z1. The fixed package should be available on the mirrors in a few hours. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ld ? ldd ? please help
On Sun, Jul 01, 2007 at 12:52:02PM +0300, Danny Tiberman wrote: Hello When I do /sbin/ldconfig -v | grep libtk I get : libtk8.4.so.0 --- libtk8.4.so.0 but when I run ldd executable i get: libtk8.4.so -- not found Where did you get that executable from? It shouldn't be using libtk8.4.so but libtk8.4.so.0. The libtk8.4.so file would be in the tk8.4-dev package, which you normally shouldn't need to run the executable. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Help] AMD64 specific bug on libblitz0 (#424644)
On Fri, May 18, 2007 at 10:31:52AM +0200, Andreas Metzler wrote: On 2007-05-18 Andreas Tille [EMAIL PROTECTED] wrote: I would like to ask kindly for support regarding bug #424644 because I do not own any amd64 and thus feel unable to solve this problem. Any hints / patches? http://lists.debian.org/debian-devel/2007/05/msg00340.html I can not reproduce the probem in unstable. I do have the problem when using the version from unstable in etch. And libblitz0 is only in unstable. It's using a gnu hash section. There are alot of things that don't properly seem to be handeling it yet. gcc was changed to use both the old hash and the gnu hash to avoid such problems. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: maildrop lacking courier-authlib dependency on amd64, still
On Sun, May 06, 2007 at 10:31:13AM +0200, Josip Rodin wrote:
On Sun, May 06, 2007 at 05:07:52AM +0200, Kurt Roeckx wrote:
The versions of the programs he used for autoreconf were:
* automake/aclocal 1.9.6
* autoconf 2.59
* config.{guess,sub} timestamp='2006-07-02'
* ltmain.sh 1.5.22
Those should all work without problems. I'm guessing it's something
else, like a file that wasn't updated or regenerated.
Would you be so kind to get the new package and try it so that I don't
upload and burden the buildds?
He seems to be not using the upstream libtool 1.5.22 version, but one
that is patched is atleast known to break other things on amd64. I
have no idea where he got his version from, but I suggest you use
upstream's or Debian's version.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need access to an amd64 system for bug fixing
On Mon, Apr 23, 2007 at 08:37:51AM +0200, Uwe Steinmann wrote: On Sat, Apr 21, 2007 at 11:48:44PM +0200, Kurt Roeckx wrote: On Sat, Apr 21, 2007 at 09:28:56PM +0200, Uwe Steinmann wrote: Hi, I get occasional reports from users using one of my libraries in debian (I'm upstream too), which has bugs on a 64 bit platform. I'd love to fix them, but don't have access to a 64 bit system. Is there anybody here who can help? You know that we have amd64 porting machines right? See: http://db.debian.org/machines.cgi And: http://www.debian.org/ports/amd64/ I have looked into those, even been on pergolesi, but didn't get any further. May I set up a development toolchain on one of those machines in a chroot environment? Those hosts have various chroots. Ask the admin if you want some packages installed on it. You can build as many things as you want and things like that. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: troublesome dist-upgrade
On Mon, Apr 23, 2007 at 10:09:02PM +0200, jmt wrote: Hi, Last update screw up my box : linux-image-2.6.18-4-amd64 has no sk98lin (no network then). Which module replaces it ? It's now done by the skge module. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need access to an amd64 system for bug fixing
On Sat, Apr 21, 2007 at 09:28:56PM +0200, Uwe Steinmann wrote: Hi, I get occasional reports from users using one of my libraries in debian (I'm upstream too), which has bugs on a 64 bit platform. I'd love to fix them, but don't have access to a 64 bit system. Is there anybody here who can help? You know that we have amd64 porting machines right? See: http://db.debian.org/machines.cgi And: http://www.debian.org/ports/amd64/ Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-amd64 mirror plans
On Tue, Apr 10, 2007 at 03:18:18PM -0400, Noah Meyerhans wrote: I'm mirrorring debian-amd64, including the unofficial sarge, on debian.csail.mit.edu. For how much longer should that mirror stick around? Does it need to exist after sarge has been moved off the main mirror network or after the security team stops supporting it (1 year from now)? Is the mirror still needed for stuff other than sarge? See: http://lists.debian.org/debian-amd64/2007/04/msg00061.html Basicly, we follow what Debian does. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.1
On Sun, Apr 01, 2007 at 09:52:50PM +0200, Gudjon I. Gudjonsson wrote: Hi Has anyone noticed that gcc is older in experimental for amd64 than for other architectures. It seems to me like dependencies that go in circles. If so, does anyone have an explanation? I wanted to compile the newest version of openoffice but I need this version of gcc for that. gcc-4.1 is in testing and unstable for quite a while, and is the default compiler for testing/etch. openoffice.org is also available in testing/etch, and I have no idea why it would suddenly require a newer gcc. I have no idea why you have a problem with this. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: out of memory
On Sun, Apr 01, 2007 at 01:18:07PM -0700, Francesco Pietra wrote: System; two dual-opteron, amd64 etch, 16GB ram, raid1. Heavy computation (memory either 1750 mb or 3750 mb per node) started with high % cpu usage and little usage of memory. Then, the two factors inverted, the HD led became lighted without interruption. The computation then closed incomplete with the warning message in the output file; *** ARMCI INFO The application attempted to allocate a shared memory segment of 38731776 bytes in size. This might be in addition to segments that were allocated succesfully previously. The current system configuration does not allow enough shared memory to be allocated to the application. This is most often caused by: 1) system parameter SHMMAX (largest shared memory segment) being too small or 2) insufficient swap space. Please ask your system administrator to verify if SHMMAX matches the amount of memory needed by your application and the system has sufficient amount of swap space. Most UNIX systems can be easily reconfigured to allow larger shared memory segments, see http://www.emsl.pnl.gov/docs/global/support.html [...] The http suggested above is of no help, referring to Linux kernel 2) This warning message was exaclty the same with the two different mem allocations. With smaller matrices (ie smaller molecules) the same type of computation ends OK. Thanks for suggestions how to tune the system. Did you read about how to increate the shmmax parameter, and did you change it? It actually tells you how to change that setting. It still defaults to 32 MB, and you tried to allocate more (36 MB). Anyway, use /etc/sysctl.conf to set it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update of AMD64 port page for Etch
On Wed, Mar 21, 2007 at 02:51:43AM -0600, Jaime Ochoa Malagón wrote: Frans, if my memory don't fail gcc 3.4 was the first gcc eable to compile for amd64 now the reference is clearly obsolete... This is about an amd64 kernel that can be installed from a .deb on i386. I don't remember exactly why the kernel was build with 3.4, but it did have better support for amd64 than 3.3. I think the reason is that the 3.4 version could build both 32 and 64 bit code from a single binary with the -m32 and -m64 options. The reason 3.3 didn't have this is probably related to that 3.4 wasn't the default in sarge. Anyway, I don't know about the current state of amd64 kernels for i386, so I don't have a suggestion for that text. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update of AMD64 port page for Etch
On Wed, Mar 21, 2007 at 06:35:39PM +0100, Kurt Roeckx wrote: Anyway, I don't know about the current state of amd64 kernels for i386, so I don't have a suggestion for that text. So we have an linux-image-2.6.18-4-amd64 and amd64-libs packages on i386. The default gcc version supports building 64 bit binaries, I suggest you change gcc-3.4 by toolchain. Anyway, the limits are outdated by now. I think the current limit is 47 bit (128 TiB) of memory per process. 1 TiB physical is still what the the processor only support, but the kernel supports 46 bit (64 TiB). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Download Problems
On Sat, Mar 03, 2007 at 06:11:09PM -, Peter Wilkes wrote: Hello I am having problems downloading the first ISO for the 64 bit version of debian. The FTP listings show a file size of around 4.4 Gb but when I download the size is only 376 Mb. I have tried on 3 different computer systems / networks with the same problem. I have also tried using many different FTP servers. The second DVD ISO is downloaded fine and the md5 is also ok. The problem could be either the server or the client can't handle files that are bigger then 2GB. I suggest you try a different client. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: maildrop lacking courier-authlib dependency on amd64, still
On Tue, Feb 06, 2007 at 02:22:06PM +0100, Josip Rodin wrote: BTW, couldn't this also be addressed just by adding a -l/usr/lib/courier-authlib option to dh_shlibdeps? That seems to work too. Why does this only happen on amd64? I don't really want an architecture-specific kludge in the package, let's fix the tools to be consistent. Or at least produce useful error information (e.g. crapping out instead of letting bad things pass). The version you're using of libtool does not work properly (on amd64). It's also mixing various versions, and I have to wonder why not more is broken. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: maildrop lacking courier-authlib dependency on amd64, still
On Sun, Feb 04, 2007 at 11:54:47PM +, Stephen Gran wrote: [EMAIL PROTECTED]:~$ dpkg -x maildrop_2.0.3-1_amd64.deb tmp/maildrop/ [EMAIL PROTECTED]:~$ objdump -x tmp/maildrop/usr/bin/maildrop | grep auth NEEDED libcourierauth.so.0 RPATH /usr/lib:/usr/lib/courier-authlib You need to either: - Fix dpkg-shlibdeps to look at all rpath entries. - Prevent /usr/lib from being in the rpath, or atleast have /usr/lib/courier-authlib as first in it. The suggested way for the later is upgrading your libtool version. It seems this was done _partialy_. Lots of the aclocal.m4 files still contain old copies of it. The only version of courier-authlib I have locally (courier-authlib_0.58-5_amd64.deb) has a correct looking shlibs file. The problem is not the shlibs file of courier-authlib, the problem is that dpkg-shlibdeps for some reason doesn't find the library because of the rpath that maildrop sets. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#405012: libwmf: Dependencies problem on experimental
On Sat, Jan 27, 2007 at 09:00:42AM +0100, Loïc Minier wrote: On Sat, Jan 27, 2007, Vitezslav Kotrla wrote: I've noticed new i386 package in experimental, thanks a lot. Is it possible to provide amd64 package, too? I don't have an amd64 and the amd64 buildd is probably not able to autobuild libwmf in experimental with its current software, so you'll have to wait until someone uploads a binary build or the software is fixed. It failed with: The following packages have unmet dependencies: libgtk2.0-dev: Depends: libgtk2.0-0 (= 2.10.7-1) but 2.8.20-5 is to be installed It also needs libgtk2.0-0 libgtk2.0-common from experimental, and sbuild won't try to install those unless the build dependencies say so. I've build it manually, it seems to work, so I've uploaded it. dpkg (subprocess): unable to execute old post-removal script: Exec format error This is weird, did you use a chroot for building? It looks like mixed architectures to me. Looks weird to me too. And I have to wonder in what state the package is if it complains about the old postrm script. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linker error on unstable amd64
On Mon, Jan 22, 2007 at 08:48:21PM -0500, Bharath Ramesh wrote: I am trying to compile a software. When I try to do it I get error. Which seems to be a linker error I assume. This compiles cleanly on a machine running fedora. The error I get is as follows: `.gnu.linkonce.t._ZNK22goto_program_templatetI5exprtE18output_instructionERK10namespacetRK7dstringRSoSt20_List_const_iteratorINS1_12instructiontEE' referenced in section `.rodata' of goto_functions.o: defined in discarded section `.gnu.linkonce.t._ZNK22goto_program_templatetI5exprtE18output_instructionERK10namespacetRK7dstringRSoSt20_List_const_iteratorINS1_12instructiontEE' of goto_functions.o Any help on this is appreciated. What version of the compiler are you using? Afaik, this is a bug in gcc, but I have no idea which version works and which don't. I suggest you try a different version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linker error on unstable amd64
On Tue, Jan 23, 2007 at 10:35:32PM +0100, Goswin von Brederlow wrote: ld -r -o goto-programs.o goto_convert.o goto_function.o goto_main.o goto_sideeffects.o goto_program.o basic_blocks.o goto_threads.o goto_check.o goto_function_pointers.o goto_functions.o goto_inline.o remove_skip.o function_dependencies.o goto_convert_functions.o builtin_functions.o show_claims.o destructor.o set_claims.o slicer.o invariant_set.o invariant_propagation.o add_race_assertions.o rw_set.o read_goto_binary.o read_goto_object.o xml_goto_function.o xml_goto_program.o xml_goto_program_hashing.o xml_goto_function_hashing.o invariant_set_domain.o static_analysis.o That is the _C_ linker. The same linker is used for both C and C++. However, the weird part here is that it's creating a relocatable object (-r switch, .o file) from other relocatable objects. I've atleast seen weird behaviour that way and it's probably better to just create an archive out of those .o files. I'm not at all sure if that's going to work, it'll probably just delay the problem until it gets really linked. And this way is also supposed to work. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please build core++ and cgal on amd64
On Sat, Jan 20, 2007 at 09:52:37AM +0100, Joachim Reichel wrote: Hi, http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html yes, I'm aware of the non-free buildd network, and both packages have already been built on other architectures. But as you can see on http://www.buildd.net/ there is currently no machine for non-free/amd64. It might not list a machine, but that doesn't mean there isn't any. I think we have one, but I'm not 100% sure. The stats it's showing also don't make any sense at all. Anyway, it doesn't have XS-Autobuild: yes header, nor does it mention anything in the copyright file that gives me an indication that it's legal for me to actually upload a binary package. Please follow the guidelines in the above mail if you want someone to build it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please build core++ and cgal on amd64
On Sat, Jan 20, 2007 at 01:51:10PM +0100, Kurt Roeckx wrote: On Sat, Jan 20, 2007 at 09:52:37AM +0100, Joachim Reichel wrote: Hi, http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html yes, I'm aware of the non-free buildd network, and both packages have already been built on other architectures. But as you can see on http://www.buildd.net/ there is currently no machine for non-free/amd64. It might not list a machine, but that doesn't mean there isn't any. I think we have one, but I'm not 100% sure. The stats it's showing also don't make any sense at all. Anyway, it doesn't have XS-Autobuild: yes header, nor does it mention anything in the copyright file that gives me an indication that it's legal for me to actually upload a binary package. So core++ does have it, cgal doesn't. I of course only looked at cgal before. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please build core++ and cgal on amd64
On Fri, Jan 19, 2007 at 10:37:20PM +0100, Joachim Reichel wrote: Hi, is there someone willing to build and upload core++ and cgal (both non-free due to QPL) on amd64? Unfortunately, there is still no (unofficial) autobuilder for non-free/amd64 and amd64 is the architecture I care most about besides i386. It takes about 30 minutes to build core++ (testsuite) and about 5 minutes for cgal; cgal depends on core++. I'm not a DD, so I can't do this myself. Please look at: http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.20 ext3 fix backported to Debian?
On Sat, Jan 13, 2007 at 08:47:33AM +0100, Jean-Luc Coulon (f5ibh) wrote: Le 12.01.2007 23:14:48, Lennart Sorensen a écrit : On Fri, Jan 12, 2007 at 10:32:23PM +0100, Jean-Luc Coulon (f5ibh) wrote: Is there a 2.6.19 in Debian? I don't think so yet. I beleive the decision is that etch will use 2.6.18, which means unstable isn't too likely to move past 2.6.18 until etch is released. My question was because the original question (see title) asked about a backport of a 2.6.20 fix to the _Debian_ 2.6.19. It seems that 2.6.19 has some bugs not fixed for the moment and probably harf to fix. Maybe 2.6.19 will be skipped? To start, I think you're asking this on the wrong list. There is probably is nothing amd64 or even 64-bit about this, and it's probably a general bug. debian-kernel@lists.debian.org would be a better list to ask such questions. Anyway, I have no idea what bug you're talking about. I know about corruption caused by msync(), which doesn't have anything to do with ext3, it affects all filesystems. This bug is actually present in Debian's 2.6.18-3 kernels because of a backport of 2.6.19 and should get fixed before the release. Debian's kernel team is actually the one that tracked which change caused it. See http://bugs.debian.org/401006 and related bugs. If you're talking about another bug, it might be a good idea to file a bug against the kernel package so that they know about it. It's unlikely that Debian will have an 2.6.19 kernel in unstable since 2.6.20 is probably already out by that time. In any case, if that's the bug you're talking about, and we get a 2.6.19 kernel in unstable, it should be fixed. If it's not that bug, and you file a bug about it, it probably gets fixed too. Kurt fixed too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Openoffice
On Sat, Jan 13, 2007 at 11:54:25AM +0200, Antti-Juhani Kaijanaho wrote: On Thu, Jan 11, 2007 at 07:52:16PM +0100, Gudjon I. Gudjonsson wrote: it's in experimental. Probably all the maintainers are working to try to release etch as soon and not put more difficult thing as openoffice 2.1 in sid. Then I don't understand. On the following page http://packages.debian.org/experimental/editors/openoffice.org the only supported architecture is i386 and It's probably just not built for it. Experimental is not a big priority for autobuilding. The problem seems to be that it's not actually listed as needing to build, I'm looking into it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice.org-hyphenation-en package missing?
On Wed, Dec 20, 2006 at 02:56:45PM -0800, Andrew Sharp wrote: I thought I would ping the list to see if anyone knows why the openoffice.org-hyphenation-en* packages are missing from etch. They're in i386. In fact, only a handfull of the hyphenation packages are available on amd64. Those packages do not exist anymore, and have been removed because of license problems. They do not exist on i386 anymore either, but it could be you still have it installed from a time before it got removed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bad mirror list in 3.1r3 netinst
On Sun, Nov 05, 2006 at 10:30:51PM -0700, dann frazier wrote: That was quick, thanks Kurt! Now, who can we poke about updating the installer images? I think we need to wait for sarge r5, there aren't any plans to make any for sarge r4. Afaik, r5 is planned for in about 2 months. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bad mirror list in 3.1r3 netinst
On Fri, Nov 03, 2006 at 05:11:33PM -0700, dann frazier wrote: I tried an install with the 3.1r3 netinst ISO, and noticed that it appears to have reverted to the debian.org mirror list. It looks like it is no longer using a pure64 version of base-config. I merged the diff between base-config 2.53.10 and 2.53.10-0.0.0.1.pure64 onto 2.53.10.2 (patch below), and it fixed this problem. Patch is here: http://dannf.org/base-config-pure64-3.1r3.patch Uploaded to the archive and pushed to stable. However, the install quickly falls on its face again when it configures debsig-verify and all remaining debs fail to install. Missing override? It seems they were missing yes, that has been fixed too. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing Debian amd64 on an asus P5W DH Deluxe + E6600 : kernel on installer broken + bugs in d-i when changing kernel + modules
On Wed, Nov 01, 2006 at 05:08:21PM +0100, Eric Valette wrote: Kurt Roeckx wrote: On Mon, Oct 30, 2006 at 09:46:03AM +0100, Eric Valette wrote: 2) Downloaded ftp://ftp.fr.debian.org/debian/dists/unstable/main/installer-amd64/20061022/images/gtk-miniiso burned it and booted it. Starts well but hangs after a while because of spurious interrupts related to disk activities (SATA) endless reset of controller. Have also spurious irq listed in dmesg. Did not know if a kernel was correctly running on this mtherboard + CPU combination. So tried to find another instable AMD64 distrib. Could you please file an installation-report? There are some tools in the installer that can show us more information about the hardare you're using. You can probably also run them on an installed system. If you hunt asus you can download the user manual with all chipsets listed. But I will report once I managed to install. Nothing really special except PCI-E and sky2 ethernet driver. We have a P5W Delux at work which had various problems too. It is running windows XP, and after about a week of time it stops booting. It shows the splash screen of windows, and at the point it should change to a higher resolution you just get a black screen. Sometimes in the event log it shows disks errors. This is with an SATA disk. We've replaced the disk, still the same problem. We've replaced the motherboard, power supply, and still have the same problem. I've also tried it using Debian (i386 netinst etch beta3), I've ran a badblock read-only test, didn't find any problems. Then I ran a read-write test, after a short time the disks basicly stops responding. The led of the disk on the PC is constatly on, instead of most of the time on, blinking. At that point, the tests only shows failed sectors. We've replaced the disk with an PATA disk, and didn't see a problem so far. We also have an identical PC that doesn't show any problems. I really can't do any tests with this, since someone is using it. Kurt Can you please show the messages the kernel reports? No. No time to do that as it would require booting with a serial line connected + compiling a newer kernel solve the problem. Will do once the system is operationnal. Is what you're seeing simular to: http://bugs.debian.org/309964 Or: http://bugs.debian.org/393977 For the irq message yes. For the SATA controller reset no. -- eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing Debian amd64 on an asus P5W DH Deluxe + E6600 : kernel on installer broken + bugs in d-i when changing kernel + modules
On Mon, Oct 30, 2006 at 09:46:03AM +0100, Eric Valette wrote: 2) Downloaded ftp://ftp.fr.debian.org/debian/dists/unstable/main/installer-amd64/20061022/images/gtk-miniiso burned it and booted it. Starts well but hangs after a while because of spurious interrupts related to disk activities (SATA) endless reset of controller. Have also spurious irq listed in dmesg. Did not know if a kernel was correctly running on this mtherboard + CPU combination. So tried to find another instable AMD64 distrib. Could you please file an installation-report? There are some tools in the installer that can show us more information about the hardare you're using. You can probably also run them on an installed system. Can you please show the messages the kernel reports? Is what you're seeing simular to: http://bugs.debian.org/309964 Or: http://bugs.debian.org/393977 Have you tried booting with options like noacpi and acpi=off? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenOffice.org 2.0.4 64-bit: error opening literature datase and other databses?
On Sat, Oct 28, 2006 at 08:15:42PM +0200, Joost Kraaijeveld wrote: Hi, I try to use the 64-bit version of OOo 2.-0.4 on my Etch AMD64 machine. If I try to open the literature databse it gives me an error saying that the columns cannot be found. Opening the same database from my 32-bit choooted OOo works OK. Is this a known bug in the 64-bit version ? What version are you using exactly? Please use atleast 2.0.4-2. Try something like dpkg -l openoffice.org-writer to see the version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenOffice.org 2.0.4 64-bit: error opening literature datase and other databses?
On Mon, Oct 30, 2006 at 12:45:07PM +0100, Joost Kraaijeveld wrote: On Mon, 2006-10-30 at 11:35 +0100, Kurt Roeckx wrote: On Sat, Oct 28, 2006 at 08:15:42PM +0200, Joost Kraaijeveld wrote: Hi, I try to use the 64-bit version of OOo 2.-0.4 on my Etch AMD64 machine. If I try to open the literature databse it gives me an error saying that the columns cannot be found. Opening the same database from my 32-bit choooted OOo works OK. Is this a known bug in the 64-bit version ? What version are you using exactly? Please use atleast 2.0.4-2. Try something like dpkg -l openoffice.org-writer to see the version. Ales, I am using 2.0.4-2. Does your remark mean that it works for you (64-bit) ? There are various problem with versions older than 2.0.4-2, and that's just to make sure it's not about one that is already fixed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: update gnutls11 please
On Thu, Aug 10, 2006 at 10:20:25AM -0600, Cedar Cox wrote: I'm requesting that gnutls11 be updated to 1.0.16-13.2sarge1. This update has already been uploaded to sarge-proposed-updates for the official archs. This will be on the archive around the time sarge r3 releases, which should be soon. I suggest you build it yourself until then. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: socket related problem in AMD64?
On Thu, Jul 27, 2006 at 02:43:15PM +0200, Adrian von Bidder wrote: Yo! See #380079 for reference Christian Schletig reported the postgrey package not working on AMD64. Looking at the log message: Jul 27 11:18:26 mail kernel: postgrey[6026] general protection rip:2a9687fd2c rsp:7fb640 error:0 I've been trying this, and get: Jul 27 19:57:38 intrepid postgrey[5727]: 2006/07/27-19:57:38 postgrey (type Net::Server::Multiplex) starting! pid(5727) Jul 27 19:57:38 intrepid postgrey[5727]: Binding to TCP port 6 on host 127.0.0.1 Jul 27 19:57:38 intrepid postgrey[5727]: Setting gid to 65534 65534 Jul 27 19:57:38 intrepid postgrey[5727]: Setting uid to 108 I've tried conneting to the smptd, and things got rejected as expected. So this seems all to work to me. Anyway, if their is a problem, I can't reproduce this. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Openoffice on AMD64
On Thu, Jul 20, 2006 at 03:57:07PM +0100, Adam Stiles wrote: On Thursday 20 July 2006 14:47, sigi wrote: I'm using this [64-bit OpenOffice.org] package since it's released, and had only very few crashes. OOo only crashes while opening some MS-word files - with some others it has no problem. Saving documents failed never here - neither on .odt nor .doc-files. Mostly I use OOo-writer - and that package seems to work very well. Where can I get the .dsc, .diff and .tar.gz files to build this? I'm running 64-bit Sid. On any debian mirror. It's just not building the .debs for amd64 yet until the maintainer thinks it's ready. He keeps the .debs on http://people.debian.org/~rene/openoffice.org instead. It requires some minor changes to the build scripts to build it yourself. Note that upstream still thinks that the 64 bit version is still alpha quality. If it's saying saving doesn't work, it might mean that if you save it, and you try to open it with an other (32 bit) version, it doesn't work. I kow that didn't use to work, not sure of how much has been fixed. In short, don't use a 64 bit version of it, if you can't handle alpha qualitity software. If you want something that should work, wait untils it's properly in the archive. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd failures for amd64?
On Thu, Jul 20, 2006 at 11:19:38AM +0200, Joost Witteveen wrote: Hi, I from time-to-time notice that amd64 doesn't have a package in unstable/testing, while most (all) other archs do. At the moment for example natios-plugins is compiled for most archs, but the amd64 arch reports maybe-failed: A maybe-failed is a state of a log file. But the package is in installed state, as you can see here: http://buildd.debian.org/nagios-plugins In this case, I've actually build + uploaded the package manually. I haven't really tested this, but because of the setup of the buildd, it's ping test probably failed. I assumed it tried to ping localhost, which happens to not work. So, I wonder, could my box help with the compiling (I have hd and bandwidth to burn)? (If so, does anyone know where to apply?) We already have 2 buildds, and 1 can keep up very easy. We currently really don't need more. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd failures for amd64?
On Thu, Jul 20, 2006 at 01:53:54PM +0200, Joost Witteveen wrote: Yes. Although most packages are available for amd64, whenever I noticed an unavailable package, I could manually build it without any changes. Can you give me any list of packages that we should build, are unavailable, and don't have an RC bug open that it failed to build? Note that some of the problems might be temporary, because they were caused by an other package. In those cases, it can be just retried. I currently don't know any of those types. Some might be caused by missing build dependencies, and when you try it you have them installed while the buildd didn't. Other might for instance be caused by incorrect build depedencies, where it needed a newer version of it's build dependency, that wasn't in the archive at the moment it was tried but is now. In this case, it's a bug in the package where it should actually specifiy a correct versioned build dependency. Even though we could build it at a later time, we don't, and expect the maintainer to upload a new version with that bug fixed. Yet an other type of bug might be some race condition, that happens to trigger on the buildd but doesn't happen on your host. For instance, the latest version of tar was unavailable because of that for some time. We've uploaded that version since it's not a regression, and it actually fixes an other important bug. There might be other type of bugs in packages, which the buildd might find and you don't, but I currently can't think of any others. So maybe it would be useful to send a STOP instead of TERM signal to the process (and an email to the owner), go on with the next package, and let the owner of the machine find out later what went wrong with the build (connecting to the stopped process with gdb and friends). I don't see the point of this. It's probably reproducible in most cases. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd failures for amd64?
On Thu, Jul 20, 2006 at 08:50:58PM +0200, Joost Witteveen wrote: Can you give me any list of packages that we should build, are unavailable, and don't have an RC bug open that it failed to build? Not anymore. I remember a that a few weeks (months?) ago apt-get-ing from testing complained about a lot missing packages. But now at least that works OK again for me. Those were just problems with migration to testing, those things sort themself out over time, but it had some help of upload to testing-proposed-updates. The other (other than nagios-plugins) packages I remember compiling when they were unavailable for some time in unstable were sendmail (after a security bug), and ntp 4.2.0a+stable-8.2. But both now are available from the testing archive, so both problems have already been noticed. Afaik, ntp isn't in testing yet on amd64, and I should know. 4.2.0a+stable-8.2 was only in unstable. Hopefully the new version we're working on is ready soon, and move to testing fast. In this case, it's a bug in the package where it should actually specifiy a correct versioned build dependency. Even though we could build it at a later time, we don't, and expect the maintainer to upload a new version with that bug fixed. Agreed. BTW, are you sure it was builddeps in this case? the build haning in trying to ping localhost seems not to relate to builddeps. nagios-plugins didn't have a missing build dependency or anything. I was trying to explain reasons why something might fail to build on the buildd and work for you. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binNMU for sarge/amd64 (#374258 / speedy-cgi-perl)
Hi, The binNMU has been done and is available on the mirrors now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gluck.debian.org compromised ?
http://lists.debian.org/debian-news/debian-news-2006/msg00030.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch weekly build
On Thu, Jun 29, 2006 at 12:17:07PM +0200, David Haworth wrote: Hi, http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/ I just noticed that the weekly build of etch for amd64 is now 3 DVDs. Does this mean that the etch DVDs are now usable? There are still things in etch that are not installable. For instance kde is missing kdewebdev and kdesdk, and gnome is missing rhythmbox, totem, sound-juicer, gnome-media. Those are all helps are missing because some other arches have problems building them. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 at buildd.debian.org
On Mon, Jun 26, 2006 at 11:03:17AM +0200, Thomas Viehmann wrote: Hi, amd64 seems to lack the canonical buildd.debian.org email alias. Could you please see to have this enabled for you? I'll send a mail asking this. I've found out because I wanted to ask for the removal of the dep-wait for my package qbankmanager. It would be cool if someone could take care of that as well. It will be taken care of. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gfortran
On Sun, Jun 25, 2006 at 09:26:19AM +0200, Francesco Pietra wrote: I wish to compile on amd64 debian etch (two dual opteron on Tyan K8WE S2895) a program (gamess-us, as a merely a curiosity to see how it runs in comparison with mpqc) that is indicated: Your computer must have a FORTRAN compiler and a C compiler in order to compile GAMESS from its source. No other software is required, usually (the exceptions are high end parallel systems which may require extra messaging software) $gcc -v gcc version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4) From $apt-cache search gfortran and $apt-cache show gfortran I have no idea what you did. Can you please show us your /etc/apt/sources.list? The version of gcc you have is the version of gcc-4.1 in testing, but testing is still using gcc-4.0 as default, so you should get: gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) Also, there should be a gfortran, gfortran-4.0 and gfortran-4.1. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gfortran
On Sun, Jun 25, 2006 at 02:24:31PM +0200, Francesco Pietra wrote: I have no idea what you did. Can you please show us your /etc/apt/sources.list? deb http://ftp.debian.org/debian etch main contrib non-free deb-src http://ftp.debian.org/debian etch main contrib deb http://security.debian.org etch main contrib non-free deb-src http://security.debian.org etch main contrib So, when was the last time you did an apt-get update? Everything really should be there. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting libc6 updated after uml-utilities screwup
On Mon, Apr 17, 2006 at 12:55:48PM -0700, [EMAIL PROTECTED] wrote:
Friends -
I can't find my way to fix my half-upgraded libc6 on amd64 sid,
caused by bug #362058. I have apt-get pointed to
deb http://ftp.us.debian.org/debian/ unstable main
so I now have libc6{,-dev}_2.3.6-7 and uml-utilities_20060323-3
ready to install. But even with the --force-yes switch, no
combination of the three packages will install properly.
I suggest you start with removing uml-utilities:
dpkg --remove uml-utilities
Then try apt-get -f install libc6 libc6-dev
Then try installing uml-utilities when it's fixed.
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ProFTP segfaults.
On Wed, Apr 12, 2006 at 09:08:52AM +0200, Thomas Alexander Frederiksen wrote: Hi. I've run into an issue of ProFTPd segfaulting whenever mod_delay kicks in, but as it was on a critical production server, I've had no chance of doing any serious debugging. We had to get it back up ASAP, and that meant reverting to 32 bit Sarge, on which proftpd doesn't segfault. Afaik, this isn't 64 bit specific. And it was fixed right after sarge was released. See also http://bugs.debian.org/308313 http://bugs.debian.org/301275 http://bugs.proftpd.org/show_bug.cgi?id=2622 http://bugs.proftpd.org/show_bug.cgi?id=2630 I have no idea if this has been fixed in a security upload, or will be in next stable release. I've been running it without problems for a long time now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of the amd64 port
On Sun, Apr 09, 2006 at 06:47:14PM -0400, Joey Hess wrote: (Please CC me, I forget if I'm subscribed.) At what point should Mirrors.masterlist be updated to remove the amd64.debian.net mirrors and stop listing all the main mirror network as !amd64? As used in the installer? I guess as long as it supports installing sarge. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compile failure libGL.a
On Sat, Mar 25, 2006 at 11:03:47AM +0100, Gudjon I. Gudjonsson wrote: Hi Has anyone had the following problem when compiling C++ programs: /usr/X11R6/lib/libGL.a: could not read symbols: Bad value I found this on the internet which is the same problem in Ubuntu. http://www.cegui.org.uk/mantis/view.php?id=7 But my question is the following. Assuming the problem stems from libGL.a not having been compiled with the -fPIC option. Can I recompile it safely with this option? I downloaded the Debian version of xorg-x11-6.9.0.dfsg.1 but decided to ask the list before continuing. My guess is that you're trying to link libGL.a which is a static library, and therefor not build with -fPIC, into a shared library, which needs to be build with -fPIC. Instead of /usr/X11R6/lib/libGL.a, you need to link to /usr/X11R6/lib/libGL.so. Both are be part of xlibmesa-gl-dev. I have no idea why you try to link the static version, but you shouldn't. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compile failure libGL.a
On Sat, Mar 25, 2006 at 04:26:47PM +0100, Gudjon I. Gudjonsson wrote: -L/usr/share/qt3/lib -L/usr/X11R6/lib -lz -lqt-mt -lGLU -lGL -lXmu -lpthread /usr/bin/ld: /usr/X11R6/lib/libGL.a(glapi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib/libGL.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [lib/libqwtplot3d.so.0.3.0] Error 1 Please check that you have an /usr/X11R6/lib/libGL.so file, and that it points to some other /usr/X11R6/lib/libGL.so.* files, and that those exist. Also, from what package is that libGL.a? Try a dpkg --search /usr/X11R6/lib/libGL.a It should say xlibmesa-gl-dev. Anyway, I suggest you (re)install xlibmesa-gl-dev. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compile failure libGL.a
On Sat, Mar 25, 2006 at 05:37:11PM +0100, Gudjon I. Gudjonsson wrote: $ ls -la /usr/X11R6/lib/libGL* -rw-r--r-- 1 root root 1005478 2006-03-22 09:21 /usr/X11R6/lib/libGL.a lrwxrwxrwx 1 root root 12 2006-03-25 17:03 /usr/X11R6/lib/libGL.so - libGL.so.1.2 -rw-r--r-- 1 root root 915718 2006-03-22 09:21 /usr/X11R6/lib/libGLU.a lrwxrwxrwx 1 root root 13 2006-03-25 17:12 /usr/X11R6/lib/libGLU.so - libGLU.so.1.3 lrwxrwxrwx 1 root root 13 2006-03-25 17:12 /usr/X11R6/lib/libGLU.so.1 - libGLU.so.1.3 -rw-r--r-- 1 root root 544968 2006-03-22 09:21 /usr/X11R6/lib/libGLU.so.1.3 -rw-r--r-- 1 root root 47510 2006-03-22 09:21 /usr/X11R6/lib/libGLw.a -rw-r--r-- 1 root root 47510 2006-03-22 09:21 /usr/X11R6/lib/libGLw_pic.a There is no libGL.so.1.2 there. It looks like this here: -rw-r--r-- 1 root root 1005478 Mar 22 09:21 /usr/X11R6/lib/libGL.a lrwxrwxrwx 1 root root 12 Mar 23 20:53 /usr/X11R6/lib/libGL.so - libGL.so.1.2 lrwxrwxrwx 1 root root 12 Mar 22 18:27 /usr/X11R6/lib/libGL.so.1 - libGL.so.1.2 -rw-r--r-- 1 root root 557224 Mar 22 09:21 /usr/X11R6/lib/libGL.so.1.2 -rw-r--r-- 1 root root 915718 Mar 22 09:21 /usr/X11R6/lib/libGLU.a lrwxrwxrwx 1 root root 13 Mar 23 20:53 /usr/X11R6/lib/libGLU.so - libGLU.so.1.3 lrwxrwxrwx 1 root root 13 Mar 22 18:27 /usr/X11R6/lib/libGLU.so.1 - libGLU.so.1.3 -rw-r--r-- 1 root root 544968 Mar 22 09:21 /usr/X11R6/lib/libGLU.so.1.3 -rw-r--r-- 1 root root 47510 Mar 22 09:21 /usr/X11R6/lib/libGLw.a -rw-r--r-- 1 root root 47510 Mar 22 09:21 /usr/X11R6/lib/libGLw_pic.a Notice that I have an libGL.so.1.2. The libGL.so.1 isn't that important, but you also seem to be missing it. Those files are part of xlibmesa-gl. Do you have some nvidia drivers or something installed? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [P-a-s] Please enable %firebird2/amd64 to help unblock qt-x11-free.
On Fri, Mar 24, 2006 at 02:00:12PM -0500, Aaron M. Ucko wrote: Greetings. As an amd64 user (though admittedly not an official porter), I have been following the new official buildd's progress with some interest, and observed a problem with the potential to block quite a few packages: although the firebird2 source package rightly claims to support amd64 (I just verified that 1.5.3.4870-3 builds without errors on my system), Packages-arch-specific lists it as specific to (hurd-)i386. Could you please bless it for amd64 as well? I've requested that myself like half an hour before your mail, and it was added within 10 minutes. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch amd64 dvds
On Thu, Mar 16, 2006 at 03:14:13PM -0600, Don Montgomery wrote: So, what is the projected timeframe for complete integration/restoration of archive integrity? It's going to take atleast a few weeks. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch amd64 dvds
On Thu, Mar 16, 2006 at 03:09:17PM +0100, Frans Pop wrote: + Trying to add kdebase-bin... libcupsys2 doesn't exist... Can't add kdebase-bin ... dependency problem. Which seems to be a generic problem in amd64 at the moment... :-( Yes. It is probably a result from the accidental migration some time ago that was reversed. That reversal resulted in the AMD64 archive being partially broken. Yes, as a result lots of packages are missing. As AMD64 is currently being integrated into the main archive, it is probably not worth trying to fix this. Which is why I never bothered to try and fix it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrdao and growisofs
On Sat, Mar 11, 2006 at 04:22:50PM +0100, Dirk Schleicher wrote: Hello, where I can find cdrdao and growisofs? growisofs is part of dvd+rw-tools. cdrdao isn't in sarge, but there is a version available if you add this to your sources.list: deb http://amd64.debian.net/debian stinkypete main Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netinst Image AMD64 where
On Fri, Mar 10, 2006 at 04:17:48PM +0100, Dirk Schleicher wrote: Hello, where can I find a netinst image for the amd port? At the same place as you can get it for other arches: http://www.debian.org/devel/debian-installer Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Failure within netinst: ide-disk and ide-generic are hanging each other
On Wed, Mar 08, 2006 at 12:13:22AM +0200, Arkadi Kagan wrote: I tried the testing image. The only noticible difference is klogd not running or misconfigured. (after running it manually - all the same) Could you please file an installation report about that? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Failure within netinst: ide-disk and ide-generic are hanging each other
On Tue, Mar 07, 2006 at 08:46:50PM +0200, Arkadi Kagan wrote: image: sarge-amd64-2.6.12-netinst.iso Could you please try the beta2 image? It's available at: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/ It should have a more recent kernel (2.6.15). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update killed X11 and damaged Locales
On Sat, Mar 04, 2006 at 06:24:00PM -0600, Russ Cook wrote: No, I checked with dselect, searching on locale, and balocs-locales(*) is not installed. The only locale that is installed is liblocale-gettext-perl 1.05-1. Thanks for taking the time to reply. So try apt-get install locales, or something simular in whatever tool you're using. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6-i386
On Fri, Mar 03, 2006 at 11:13:36PM -0800, David Liontooth wrote: Just to make sure I understand: we're going multiarch? No more chrooted 32-bit environment? No, this is biarch. It's to replace ia32-libs. Multiarch is something totaly different. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6-i386
On Sat, Mar 04, 2006 at 04:34:35AM -0800, David Liontooth wrote: Kurt Roeckx wrote: On Fri, Mar 03, 2006 at 11:13:36PM -0800, David Liontooth wrote: Just to make sure I understand: we're going multiarch? No more chrooted 32-bit environment? No, this is biarch. It's to replace ia32-libs. Multiarch is something totaly different. Thank you. Can I install OpenOffice in the regular root with libc6-i386? No, it's not meant to support full biarch. This is just a temporary solution, mostly to have a biarch gcc. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing eclipse gives conflicts
On Thu, Feb 23, 2006 at 10:33:43AM +0100, Koos Vriezen wrote: Hi, I'm having trouble installing eclipse, due to a conflict between eclipse-jdt-common (3.1.2-1) and eclipse-jdt (3.1.1-8) and depends on eclipse-jdt-common=3.1.1-8. Given that these packages are from 10 feb. and I couldn't find this w/ google, I must overlook something. Can someone give me a hint how to install eclipse? The problem is that it failed to build on the autobuilder. As a result there was a release critical bug filed: http://bugs.debian.org/352726 If someone fixed that simple thing, it should probably be available in the archive. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Perl is broken: Can't locate overload.pm
On Sun, Feb 12, 2006 at 05:35:24PM -0500, Carl Beckhorn wrote: On Sat, Feb 11, 2006 at 12:50:27PM -0800, Max wrote: With recent update of my debian-amd64/unstable I've got perl broken. Now it reports error like debconf: Perl may be unconfigured (Can't locate overload.pm in @INC You can compile perl 5.8.8-2 yourself from source with apt-get source perl cd perl-5.8.8 su debian/rules binary or you can just find a copy of overload.pm and put it in /usr/lib/perl/5.8.8/overload.pm until perl-base 5.8.8-2 appears in the archives. Either way fixes the problem. It is in the archive since like 12 hours ago. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-get: Where to get the gpg-key?
On Fri, Jan 20, 2006 at 04:39:44PM +0100, rainer herrendoerfer wrote: Hi, During # apt-get update I received the GPG error ... NO_PUBKEY 22DB56F984478DDF And from where are you trying to download something? Maybe this is some package repository for something that isn't in Debian? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc bug?
On Fri, Jan 13, 2006 at 05:18:13PM -0400, Peter Cordes wrote: strfry(string); This bug has been fixed in glibc 2.3.5-10. There was a bug open at: http://bugs.debian.org/343365 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages.gz out-of-date
On Mon, Jan 09, 2006 at 10:14:50PM +0200, Török Edvin wrote: Hello, I noticed that kde 3.5 appeared in Debian unstable. I wanted to do an upgrade, but upgrading kdeadmin complains that it cannot find kcron 3.5. The latest version according to the Packages file is 3.4.3-2. However kcron version 3.5 is available on amd64.debian.net (and its mirrors). The kcron version you see in the pool (pool/main/k/kdeadmin/kcron_3.5.0-3_amd64.deb) is in the Packages file. Maybe not in the one you expect though. It's in experimental. It's not in unstable yet. I downloaded the Packages file for i386, and it contains the correct version of kcron (3.5). i386 has version 3.5.0-4, which was uploaded to unstable yesterday. It's just not available on amd64 yet. Just be patient. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eterm broken on AMD64
On Mon, Jan 09, 2006 at 06:27:14PM +0100, Juanjo Garcia wrote: This is just to report that the same exact bug is to be found with Eterm in Debian- UltraSPARC (also 64 bit arch.) That would probably be: http://bugs.debian.org/157084 Which is open for 3 years and has a patch for over a year. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anyone willing to seed sarge amd64 isos?
On Thu, Jan 05, 2006 at 01:33:56PM +, [EMAIL PROTECTED] wrote: Hi. Is there anyone (hopefully, more than one person) who's willing to seed sarge amd64 dvd ISOs for bittorrent for a while? I've been stuck at 39% and 24% for quite a while. Edit: well, it looks like someone has ESP, in that someone just started seeding within the last 30 minutes. Still, if more people could jump in that'd be very very helpful (especially since I dunno how long that person will be around). Thanks. I just started them, and someone started downloading them at 700 KB/s Why didn't you just download them from one of the mirrors anyway? I started the bt on bytekeeper.as28747.net, where they're on /cdimage-amd64/sarge-amd64/iso-dvd/ Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Boot floppies?
On Mon, Jan 02, 2006 at 01:00:34AM -0800, Joachim Achtzehnter wrote: Is there a reason why the simple boot floppy approach is not offered for the amd64 port? Because nobody put time in it yet to get a 2.6 linux kernel to fit on a floppy. Mostly because their are various other ways to get it working. i386 doesn't have support for floppy with a 2.6 kernel either, only with a 2.4 kernel. And we only have a 2.6 kernel. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building ghdl for amd64
On Sat, Dec 31, 2005 at 03:17:16PM -0700, Wesley J. Landaker wrote: Hi folks, I just (several hours ago) uploaded a new version of ghdl that builds on amd64; the previous versions didn't build. Do I need to do anything to get the amd64 buildds to build it? According to http://people.debian.org/~igloo/status.php?packages=ghdl, it doesn't seem like anything is going on with amd64; for all[1] other architectuers, there is at least some status. You just need to wait until the ghdl source gets on the mirrors. We do not build from incoming, but only start after dinstall. So it should get build in about 10 hours, and be available in about 24 on the amd64 mirrors if it build succesfully. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ghemical is broken
On Sat, Dec 24, 2005 at 01:44:25PM +0100, Jean-Luc Coulon (f5ibh) wrote: Hi, Does somebody managed to build ghemical? On the repositories, it is at version 0.90 while the lib and data related packages are 0.91. Thre is a reason 0.91 is not in the archive. I downloaded the source but it fails to build. http://bugs.debian.org/341798 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc bug?
On Wed, Dec 14, 2005 at 11:10:41AM +0300, Basil K wrote: Hi, I just to try compile example from OProfile docs with strfry(char *) function. Seg fault occured when I run result program. I saw someone else having a problem with it like a week ago, and expected him to file a bug report about it, but I can't find it. I'll ask around. Anyway, this seems to be a known bug. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc build failure analysis (was Re: StrongARM tactics)
On Sun, Dec 11, 2005 at 05:55:23AM -0800, Steve Langasek wrote: Indeed, for practical buildd maintainance purposes, the distinction is not that important -- though 'Failed' is known to not benefit of a requeue, while 'Building:Maybe-Failed' might or might not, it's unkown, most archs should have enough surplus buildd power that retrying everything once in a while doesn't hurt. The major benefit is though to make it apparant for porters what to look into, without all the 'noise' in between of maybe-transient failures. One could also make sure that the FTBFS bugs are tagged (user-tagged) with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a nice overview of all the porting bugs. It'd make sense to synchronise this across all architectures, so that it is consistent. http://lists.debian.org/debian-alpha/2005/12/msg00028.html I have a long list of bug affecting amd64, but I haven't started with usertags for it. The (FTBFS) bugs I encouter (as buildd admin) are: - General bugs affecting all arches. - General bugs affecting 64 bit arches. - Bugs affecting some arches (like not using -fPIC) - Bugs only affecting amd64. And the later really is the minorty of the problems. Note that this does not cover runtime problems or something like that, but they're very simular. Do we need to have a special usertag for the first kind? This is basicly something everybody can look at. The only reason I can think of that it requires some tag is that it's better then looking at those that don't have a tag. So, I'm open for suggestions on how to tag the first 3 of those. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia32-libs
On Mon, Nov 28, 2005 at 06:13:10PM +0100, Lubos Vrbka wrote: hi guys, i am not able to update ia32-libs on sid. i get the following error: dpkg: error processing /var/cache/apt/archives/ia32-libs_1.5_amd64.deb (--unpack): trying to overwrite '/usr/lib32', which is also in package libg2c0-dev and it fails to install. i found something similare there: http://lists.ubuntu.com/archives/ubuntu-bugs/2005-July/065679.html any hints how to solve this? i cannot remove libg2c0-dev because several other packages depend upon it... :( It seems nobody filed a bug about this yet, will do shortly. To work around this, first remove libg2c0-dev, then install or upgrade ia32-libs, then install libg2c0-dev again. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beta status
On Sat, Nov 05, 2005 at 03:19:06PM +0100, Kurt Roeckx wrote: On Sat, Nov 05, 2005 at 12:22:49AM +0100, Kurt Roeckx wrote: The problem now seems to be that rootskel-locale still seems to exist in testing for some reason. It's unclear to me why it still exists. This is causing the monolithic target to fail to build because it can't find the locale. The next problem is to actually get it into the archive. It's getting rejected: Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't say debian-installer-images_20051026 for Source Rejected: debian-installer-images_20051026_amd64.tar.gz: should be 20051026 according to changes file. Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't list `source' in Architecture field. The tar has now been manually extracted and available. The .deb package isn't installed yet however, we'll get back to that later. The netinst build should now be buildable. There is a proposed patch amd64.debian.net/~aba/diff.jennifer that should fix this in the future, and hopefully get applied soon. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beta status
On Sun, Nov 06, 2005 at 02:39:38PM -0500, Joey Hess wrote: Kurt Roeckx wrote: The next problem is to actually get it into the archive. It's getting rejected: Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't say debian-installer-images_20051026 for Source Rejected: debian-installer-images_20051026_amd64.tar.gz: should be 20051026 according to changes file. Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't list `source' in Architecture field. It also did that with the previous version that build (20051009), and I have no idea why. It seems to think that debian-installer-images_20051026_amd64.tar.gz is the source while it's actually a (special) binary package. Sounds to me like a broken .changes file.. I would be suprised if it generated broken .changes files. I've attached it. Kurt -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Oct 2005 18:55:45 -0400 Source: debian-installer Binary: debian-installer Architecture: amd64 Version: 20051026 Distribution: unstable Urgency: low Maintainer: Kurt Roeckx [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: debian-installer - Debian installer Closes: 334780 Changes: debian-installer (20051026) unstable; urgency=low . [ Joey Hess ] * Add cramfsprogs dependency for mipsel. Closes: #334780 * Syslinux ignores failures due to being out of disk space (#335152). Avoid this bug by running syslinux on the original, empty disk image. * If the boot logo can't be copied onto a floppy, don't fail, just proceed on without a boot logo. Yes, we're that short on space on the i386 boot floppies, no more logos for them until space is freed up. * Deal with changed case of Kernel-Version fields in stat generation code. . [ Colin Watson ] * Improve wording of debian-installer binary package description. Files: cf4dca5ef36c3ab9e8794be42533fd5e 574138 devel optional debian-installer_20051026_amd64.deb 35a90f59e9d7ee2694ad2e94e1b30746 49826709 raw-installer - debian-installer-images_20051026_amd64.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbKoLQdwckHJElwsRAhl2AJsE8s2MViJ71sEhAB/KG52X/Z7vAACg5uN5 458rVpt0tO9fnElMPON6Uao= =EAQJ -END PGP SIGNATURE-
Re: beta status
On Sun, Nov 06, 2005 at 06:27:52PM -0500, Joey Hess wrote: Kurt Roeckx wrote: I would be suprised if it generated broken .changes files. I've attached it. It's broken, what's the listed debian-installer_20051026_amd64.deb? dpkg -I debian-installer_20051026_amd64.deb new debian package, version 2.0. size 574138 bytes: control archive= 370 bytes. 356 bytes,10 lines control Package: debian-installer Version: 20051026 Section: devel Priority: optional Architecture: amd64 Installed-Size: 1316 Maintainer: Debian Install System Team debian-boot@lists.debian.org Description: Debian installer This package currently only contains some documentation for the Debian installer. We welcome suggestions about what else to put in it. And it contains things in /usr/share/doc. It's also the only thing that is actually in debian/control. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beta status
On Fri, Nov 04, 2005 at 10:02:37PM -0500, Joey Hess wrote: You know, amd64 is the only arch to build the monolithic target by default. I think that this is because it used to be hard to get businesscard CDs for amd64, but we build them now. And also there used to be the mirror selection issues which made it harder to install amd64 than other arches, but those are also now resolved. The biggest issue we used to have is that we didn't have testing at all, which resulted in netboot breaking alot. So you could just turn off this target. It's mostly only useful for debugging non-uploaded udebs during development. I've been pondering about doind that myself the last few days, and so I've just did it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beta status
On Sat, Nov 05, 2005 at 12:22:49AM +0100, Kurt Roeckx wrote: The problem now seems to be that rootskel-locale still seems to exist in testing for some reason. It's unclear to me why it still exists. This is causing the monolithic target to fail to build because it can't find the locale. The next problem is to actually get it into the archive. It's getting rejected: Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't say debian-installer-images_20051026 for Source Rejected: debian-installer-images_20051026_amd64.tar.gz: should be 20051026 according to changes file. Rejected: debian-installer-images_20051026_amd64.tar.gz: changes file doesn't list `source' in Architecture field. It also did that with the previous version that build (20051009), and I have no idea why. It seems to think that debian-installer-images_20051026_amd64.tar.gz is the source while it's actually a (special) binary package. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beta status
On Wed, Nov 02, 2005 at 02:08:07PM -0500, Joey Hess wrote: This was resolved, only to hit the next problem with amd64: The amd64 archive signing key is not trusted by apt. So currently testing amd64 installs only work from the netinst CD, all the other install methods, which use apt authentication, are broken. This is fixed in apt 0.6.42.2, but it won't reach testing in a while due to annoying gcc-4.0 dependencies needing to reach testing first. We've pushed apt 0.6.42.2 to testing in the amd64 archive. We didn't have the problem with the gcc-4.0 dependency and did a local override to get the new apt in testing. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 Debian Installer netinst
On Fri, Nov 04, 2005 at 02:05:48PM -0600, Thomas F. O'Connell wrote: After starting this thread on debian-boot, I was gently pushed to this list. I recently tried to get Debian Installer going on a single Opteron custom-built machine using the daily build of the netinst CD image from here: http://www.debian.org/devel/debian-installer/ Could you please provide an url to the actual location what image you downloaed? And on what date did you download those? The current is a symlink that changes every day. Some of the problems might have been fixed already. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
