mozilla 1.3.1-1 segfaults
Are any arches other than debian ppc sid seeing the new mozilla 1.3.1-1 release segfault? This new version also causes galeon to segfault as well. Regressing back to 1.3-5 fixes both. Jack
libstdc++-pre6 vs build machines
I was wondering if any effort was being made to hold the build machines from installing the broken libstdc++-5_3.3-0pre6 packages. If there are missing symbols in those new libstdc++ libs I am wondering what the impact will be for any c++ code built against pre6 when the symbols return in the next fixed libstdc++ build. Jack
evolution menu icons broken
Does gdk-imlib1 need to be rebuilt? It seems since the new png changes went into debian ppc sid, the menu icons are broken in evolution. Jack
install-info and LSB
Has there ever been any discussion of the binary /usr/sbin/install-info in terms of the Linux Standard Base? I ask because dpkg is providing a perl based version of this utility whereas all other distros appear to be using binary only version. This came up because the regex in perl 5.80 is buggy and breaks the perl install-info for building glibc now. As a workaround I rebuilt texinfo-4.2 with all of the redhat install-info related patches and substituted this binary only version for the one dpkg installs. While this version is sufficient for building the packages there does appear to be some incompatibilities related to installing glibc-doc with this version of install-info. I am wondering if we aren't violating the spirit if not the letter of LSB by using a non-standard version of install-info. Wouldn't it be better to move install-info out of dpkg, add any required additional functionality to the texinfo version of install-info and push those changes upstream to the texinfo maintainers? Since install-info is being called at both the Makefile level in builds as well as at the packager level (eg rpm or dpkg) it seems that we would be much better off if the install-info used by debian was uniform with what everyone else is using (be it a perl or binary version). Any comments? Jack
why is /usr/sbin/install-info a perl script!!!
I am trying to get the glibc debian cvs for 2.2.92 to package (it builds and passes make check fine on debian ppc sid with the new gcc 3.2.1pre). However the buggy perl 5.80 in sid has broken install-info. I looked at a Yellow Dog Linux machine and noticed, however, that they had a texinfo 4.2 source package that builds an info package with a binary /usr/sbin/install-info instead of the perl version we have. Why is that and why don't we just NMU texinfo in sid to start building a binary install-info until perl 5.80's regex stops leaking memory like a sieve? Jack
consider regression of perl!
Hello, Considering how unstable perl 5.80 currently is, wouldn't it be wise to regress sid back to perl 5.60 and move 5.80 into experimental instead? So far this upgrade has done major damage to dpkg by breaking install-info making any additional glibc builds in sid impossible. I have also found similar bugreports in bugzilla of perl segfaulting in certain circumstances. With debian's heavy reliance on perl for its system maintenance scripts this current move to 5.80 seems far too destablizing for sid. Especially as it will wreak havoc with any move to gcc 3.2 builds. Jack
Re: consider regression of perl!
Adam, Well it will be one thing if the debian perl maintainers are going to actively track down and fix these critical perl bugs on their own. However if we are going to passively wait for fixes from upstream, perhaps perl 5.80 will introduce a bit too much breakage for right now. I mean dpkg IS an essential package. You can't break that willy nilly. Also, correct me if I'm wrong but doesn't even gentoo linux consider perl 5.80 too twitchy to include? Jack ~
Re: consider regression of perl!
Dan, Then you might take a stab at debugging the testcase from the bugzilla report... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=69254 ...since it sounds similar. If it isn't then we have another bug to fix. Jack
libwww-perl
Has anyone had any luck building libwww-perl against perl 5.80 yet? Jack
re: First experience with gcc-3.2 recompiles
Gerhard, I would be cautious about installing a gcc-3.2-built glibc unless you first purge your system of all binaries that were built with gcc 3.1. Jakub Jelinek said he was uncertain if s390/s390x was an arch that would require a libgcc-compat be added to glibc. If a libgcc-compat is required you will see certain old binaries fail under the new gcc 3.2 built glibc. According to Jakub you can see if this will be the case by doing the following... Basically, you take the list of libgcc.a (formerly) exported symbols and scan all binaries/libraries if they have undefined references to any of these symbols (as libc.so exports those on ia32/sparc and a few others only, they will not be exported on other arches from libc, thus are resolved to some unintentionally exported symbol in some other library which is going away after rebuild with 3.2). Jakub ...on a machine built entirely with a gcc 3.1. If you do find that binaries are showing undefined references to any of the libgcc symbols (which are now .hidden in gcc = 3.1) you need to construct a sysdeps/s390/libgcc-compat.c or .S that makes these libgcc symbols available for run-time resolution (but not exporting them for linking). Hope that helps. Jack
proposal for the gcc 3.2 transition
Hello, I would like to make a proposal for one aspect of the gcc 3.2 migration in sid. A critical part of this transition will be the discovery of how many arches still require creation of libgcc-compat code in glibc. Currently we are told by Jakub Jelinek that i386 is fine. Franz Sirl has just finished ppc in both branches of the glibc cvs. The ia64 arch has a version available in the glibc trunk that could be backported. Jakub also said alpha and sparc32 should be fine (not sure if that needs backported from the trunk though into glibc-2-2-branch). The rest will have to be handled by the arch maintainers here. After talking to Daniel Stone, I found out that the kde 3.0.3 introduction to sid was being delayed until the gcc 3.2 switchover has occurred. Since the scheme above will greatly delay kde 3.0.3 being added to sid, I would like to propose the following. Assuming each arch passes their gcc 3.2 testsuite and the most current binutils is mandated for use with gcc 3.2, we should be able to short-circuit the process as follows. 1) adjust the debian/control in glibc to build all arches at their current gcc 3.1 regardless if gcc 3.2 is installed. 2) switch the gcc-default to gcc 3.2 3) as each arch can demonstrate that their libgcc-compat issues are resolved, their arch would be switched over in the glibc debian/control file to build glibc with gcc 3.2. This approach has the advantages of making the transition to gcc 3.2 go much faster while removing the need for each arch to immediately resolve their issues with libgcc-compat. All comments and suggestions are welcome. Jack
Re: gnome 2.0 breakage
It would appear the problem may be with the gnome-vfs2 currently built on voltaire. I had built my own copy waiting for it to come off of voltaire earlier in the week. With that locally built copy of gnome-vfs2 installed, nautilus2 works fine. Also, if I rebuild current gnome-vfs2 against current debian sid locally that copy of gnome-vfs2 works fine. For some reason the same package version off of voltaire causes nautilus2 to flake out and not recognize paths as being valid. Jack
xmms needs rebuild in sid
I believe the libpng2-libpng3 migration in sid may have broken xmms. While I can run xmms somewhat, I can't get the playlist to display. If strace a run I see... rt_sigprocmask(SIG_SETMASK, NULL, [32], 8) = 0 rt_sigsuspend([] unfinished ... --- SIGRT_0 (Real-time signal 0) --- ... rt_sigsuspend resumed ) = 32 shmat(0, 0, 0x6ptrace: umoven: Input/output error )= ? which isn't clearly associated with a particular module loading. Jack
Re: xmms needs rebuild in sid
Eduard, Actually, Michel Danzer says he thinks in may be related to 100 dpi fonts. In any case, does xmms display its playlist in sid for you? Here I get nothing although xmms doesn't crash. I just rebuilt it against current sid and that didn't help. Do we know when this playlist failure bug arose? Jack
Re: xmms needs rebuild in sid
Josip, Changing the font didn't help, but deleting my .xmms directory in my account seemed to have cured it. Odd. Jack
Re: xmms needs rebuild in sid
Josip, Unless it was just random corruption of the .xmms in which case it would be impossible to determine what caused that. I actually set the font for the playlist to the same font as the main display (which is okay) and that didn't work. Unless someone else sees this today I would bet on random corruption of prefs. Jack
gnome 2.0 breakage
Is anyone else seeing major breakage on Gnome2 tonight? On current debian ppc sid, I found after rebooting that while gdm2 still worked and I could login that Nautilus2 is very broken and reports that variety of directory as being invalid with alerts at startup. Also the Applications menus are empty. I grabbed everything built tonight on incoming.debian.org but that didn't help. Jack
Re: GCC 3.2 transition
Steve, There shouldn't be huge issues in the gcc 2.95.4 to gcc 3.2 transition. Currently the only two major ones I know if are... 1) Rebuilding glibc with gcc 3.2 *may* require an arch to add a libgcc-compat section to provide libgcc symbols, now .hidden in gcc 3.2's libgcc_s.so, with local copies that are resolvable at runtime. Currently ia64 and ppc has such code available. This is to prevent breaking old binaries when a gcc 3.2 built glibc is installed. 2) Using something like a gcc 2.95.4 built jdk javaplugin (written in c++) with a gcc 3.2 built mozilla won't currently work although workarounds are said to exist. Since Blackdown JDK 1.4 development is underway a gcc 3.2 build JDK won't be far off. Jack
Re: XFree 4.2.0 - again
I agree with Chris it that is insulting for folks to be degrading the other arch's supported by Debian. What is strange is that someone would feel strongly enough about having a choice in operating systems to run Debian Linux yet think that a i386-only world is just fine. The two monopolies go hand in hand (Intel and Microsoft). Lastly the presence of non-i386 architectures has helped even the i386 folks by forcing Linux and gnu to be more rigorous in programming. The just because it runs on i386 won't cut it with multiple arches and enforces the requirement of clean coding that is processor independent. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xfree86 unbuildable on ppc
Hello, Could someone explain to me the point of releasing Xfree86 4.1.0-15 as is when clearly patch #065 was going to break builds on most non-intel arches? * patch #065: raped again by Herbert Xu and Ben Collins; you're not supposed to Build-Depend on a kernel package and at the same time the glibc versions of the kernel headers exclude SiS DRM ioctls that we need #defined to compile properly. Kludge these #defines into sis_alloc.c because, of course, it's XFree86's job to know what the uderlying kernel's ioctl numbers are. While we're at it, why don't we just stop using standardized constants in our C programs altogether? :-P Oh, by the way, these are the ioctl's for i386 Linux. Talk to Herbert and Ben if this sucks for you. (Closes: #139511) I simply don't see the logic at play here considering we're supposed to be closing in on woody's release. Jack Howarth ps See bug report 141114 for details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xfree86 unbuildable on ppc
Opps...that bug report associated with this problem is 141116 not 141114...sorry. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re vlc
Branden, Nevermind. I just heard back from Samuel Hocevar and he is aware of the problem and will fix it in the next build. I got thrown for a loop because there was a crashing bug not fixed in vlc until 0.2.92-7 (which isn't in sid ppc yet) and local builds were failing (because of xlibs-pics being installed). These two unrelated problems confused the situation for me. Jack
vlc, sdl and xlibs-pic conflict
Branden, I guess I'm just a tad thick here but I don't understand the rational for the following conflict. My debian ppc sid machine is current for all the packages in sid and has xlibs-pic installed as well. I discovered that when I tried to do... apt-get -b source vlc for the latest vlc-0.2.92-7 package to build locally that I got a failure in the link. The problem disappears when I deinstall xlibs-pic and then try rebuilding vlc again. The difference seems to be that when xlibs-pic is installed I get a build with... gcc -fPIC -o ../sdl.so sdl.o vout_sdl.o aout_sdl.o -shared -L/usr/lib -lSDL -lpthread -L/usr/X11R6/lib -lXxf86dga_pic -lXxf86vm_pic -lXv_pic which causes a link failure on vlc later on with unresolved symbols from those static pic libs whereas when xlibs-pic is deinstalled I get... gcc -fPIC -o ../sdl.so sdl.o vout_sdl.o aout_sdl.o -shared -L/usr/lib -lSDL -lpthread -L/usr/X11R6/lib and I get no link failures on vlc. I assume this is a flaw in vlc where the static pic libs are being incorrectly linked into a shared lib instead of the final program itself. I have passed this info onto the vlc maintainer but since you did the sdl NMU and I assume this link command is created using sdl-config, I thought you should be in the loop. Perhaps xlibs-pic should be installed on all the build machines when programs that link to libsdl1.2 are built so we can tickle this bug and identity all the programs that need to be fixed. Call me silly but it seems to me a program shouldn't have a build failure just because xlibs-pic is installed. Jack ps No more postings to announcements please (grin).
gnumeric and guppi in sid
Has anyone managed to get guppi to work in current sid? I have yet to have any success. Before today guppi would silently fail whereas today I get a crash in guppi-gnumeric. I am trying the following... 1) run gnumeric 2) enter two columns of three rows of numbers (1,2,3 and 2,4,6) 3) select these 6 cells 4) click on graph icon in the gnumeric tool bar I am just wondering if guppi has every worked properly in sid. Jack
Re: gnumeric and guppi in sid
Well, this is on ppc sid. I'll try to find someone else on ppc sid to check this. Oh I did file a bug report because guppi hasn't been working for me for quite some time. This is just the first time it actually showed a support program was segfaulting. Jack
Re: WARNING: Jack Howarth is an agent of destruction
This is absurd. Debian policy explicitly states that you should not create a shared lib using objects not created with -fPIC (which is exactly what libsdl-image does when it asks sdl-config what to use for static_x_extension_libs). This problem is identical to one just resolved in evolution... evolution (1.0-2) unstable; urgency=low * Applied fPIC patch of Bug#124141 (closes: #124141) * Applied correcthelosmtp.diff of Bug#123922 (closes: #123922) * debian/control: - remove beta notice from Description. ...where libcamellocal.so was being built using a static lib libebex built without using -fPIC. This was WRONG! One of the problems with this Debian policy violation is that it is not always reproducible as a bug on other folks machines. However feel free to ask on debian-powerpc and the will confirm that it is in fact wrong to use non-fPIC static libs in a shared lib on ppc and in fact any arch under Debian. Branden seems to have gone off the deep end here. All I am trying to do is eliminate a serious policy violation in libsdl. Either sdl-config is modified to be bright enough to return a different answer for static_x_extension_libs... static_x_extension_libs=-lXxf86dga_pic -lXxf86vm_pic -lXv_pic if a shared lib is being built or sdl-config has to always assume a shared lib might be built and do the same. Again, I'm just reporting a real bug in these packages that impacts Debian ppc sid (and probably other arches). Don't flame me just because you don't want to hear a real problem. Jack ps I can't be held for treason in the UK. We bailed out of that joint almost 100 years ago.
why does xlibs-pic exist?
After a number of rants from Branden I rather confused now as to why xlibs-pic exists at all. As best as I can tell through the froth, Branden is saying that absolutely no static libs should be linked into a shared lib. The conventional wisdom on debian-powerpc seems to be that this should be extended a tad to allow for programs that will need more work upstream. So that it should be... absolutely no static libs, that have not been built with -fPIC/-fpic, will be linked into a shared lib. The only statement I can find in the debian policy simply states... All libraries must have a shared version in the lib* package and a static version in the lib*-dev package. The shared version must be compiled with -fPIC, and the static version must not be. In other words, each *.c file will need to be compiled twice. This seems to be different from what I recall from only a few weeks ago when it seemed to only say shared libs must be built with -fPIC and nothing about static not being built that way. So what is really correct? It would seem that xlibs-pic seems to only encourage breaking the current new stricter policy on shared libs not containing static libs. I am very unclear as to what is the approved fix then. If something like libsdl-image should not link any static lib (even built with -fPIC) into its shared libs, then what use is xlibs-pic at all? If we are going to enforce this darconian rule then xlibs-pic should be depreciated out of xfree86 since it can't actually be used without violating current debian policy. Nice Catch22. Jack ps I didn't realize some parts of England were only recently, and partially, civilized (grin).
libsdl-image1.2
Ok. I see Branden's NMU declaration for changing the use of the static libs in SDL related packages. Still when I read the change log for libsdl-image1.2 I find... sdl-image1.2 (1.2.1-1) unstable; urgency=low * new upstream version * tried to add Brandens fixes again in Makefile.am, aclocal.m4 and configure.in * re-ran libtoolize --force --copy; aclocal; automake --foreign; autoconf -- Christian T. Steigies [EMAIL PROTECTED] Tue, 18 Dec 2001 21:21:39 -0500 I assume this is an implementation of Branden's suggestions from... http://lists.debian.org/debian-devel/2001/debian-devel-200110/msg00353.html If it is...it isn't working on Debian ppc sid. We still get the static versions of the libs. Jack
sdl-image1.2 fixed
Branden and Christian, Sorry that I misunderstood that the fix for this was already in place in the current libsdl-image1.2 package. However on debian ppc sid it doesn't appear to work unless I make the following change to the rules file. I have to put a call to autoconf before the ./configure occurs. Otherwise the build using apt-get source sdl-image1.2 cd sdl-image1.2-1.2.1 dpkg-buildpackage -rfakeroot doesn't generate a usable shared lib. I find that armagetron still segfaults with... ./armagetron: error while loading shared libraries: /usr/lib/libSDL_image-1.2.so.0: R_PPC_REL24 relocation at 0x0ffc48b4 for symbol `LoadBMP_RW' out of range if I use the currently built versions of libsdl-image1.2 or rebuild them locally. Again if I make that one minor line change to the rules, adding a call to autoconf before configure, this appears to resolve the problems with armagetron. At least on my machine. What I did notice is that unless I invoke autoconf...all I ever get for 'grep library-libs *' is... aclocal.m4:SDL_LIBS_FOR_LIBS=`$SDL_CONFIG $sdlconf_args --library-libs` even after building sdl-image1.2 with 'dpkg-buildpackage -rfakeroot' however only if I do autoconf does the change in aclocal.m4 get transmitted to configure. Sorry again about the winding path to finding this fix but at least it is a trivial one. Jack
one last comment
Branden and Christian, I guess I don't follow the finer nuance here but these are the different compile lines generated from libtool without doing an autoconf before configure... gcc -shared IMG.lo IMG_bmp.lo IMG_gif.lo IMG_jpg.lo IMG_lbm.lo IMG_pcx.lo IMG_png.lo IMG_pnm.lo IMG_tga.lo IMG_tif.lo IMG_xcf.lo IMG_xpm.lo -L/usr/lib /usr/lib/libSDL.so -lpthread -L/usr/X11R6/lib -lXxf86dga -lXxf86vm -lXv /usr/lib/libjpeg.so -lpng -lz -Wl,-soname -Wl,libSDL_image-1.2.so.0 -o .libs/libSDL_image-1.2.so.0.1.0 ...and with doing an autoconf first before configure in libsdl-image1.2... gcc -shared IMG.lo IMG_bmp.lo IMG_gif.lo IMG_jpg.lo IMG_lbm.lo IMG_pcx.lo IMG_png.lo IMG_pnm.lo IMG_tga.lo IMG_tif.lo IMG_xcf.lo IMG_xpm.lo -L/usr/lib -L/usr/X11R6/lib -lXxf86dga -lXxf86vm -lXv /usr/lib/libjpeg.so -lpng -lz /usr/lib/libSDL.so -lpthread -Wl,-soname -Wl,libSDL_image-1.2.so.0 -o .libs/libSDL_image-1.2.so.0.1.0 Does this look correct now? I am surprised as this looks to be just a simple reordering of the linkage rather than anything that invokes the xlibs-pic versions of -lXxf86dga -lXxf86vm -lXv explicitly. Guess I'll need to reread the mailing list on that issue again. In any case, the second link command generates a good copy of libSDL_image-1.2.so.0.1.0. Jack
openoffice in debian?
Hello, What exactly is the situation with regard to openoffice going into debian sid? I ask because OpenOffice 641C seems quite robust now (I've been doing some statistical data analysis in it this weekend and it works as well as Excel). The only current problem I see in it is that the new format files are saved down as compressed with gzip although the extensions don't indicate that which throws gnome-vfs for a loop. Hopefully OO will fix that some by changing their headers so that the files don't appear to be created by gzip. Anyway...it would be great to get it into debian. The current version loads in 7 secs now with combreloc. Quite nice. Jack
