Future of s390 port
Due to lack of time I am not able to do the s390 porting work anymore. I am looking for someone who is interested to take over the s390 port. This includes the administration of the buildd servers, analyzing build failures and requalification of the s390 port for the etch release, see http://lists.debian.org/debian-devel-announce/2005/09/msg00012.html . Regards, Gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: attention to bug 321435
Thomas Bushnell BSG wrote: Please see http://bugs.debian.org/321435. This bug is that gs-gpl fails to work on s390. I recall just seeing a principal s390 developers say he was no longer doing the Debian s390 port. I don't know what effect this has on the bug. This bug is blocking a number of packages, at the very least, ifhp and scummvm. Something needs to happen... I'm not sure what. I have already looked into the bug and it seems to be a rather complicated issue. I will debug it in more detail this weekend. Regards, Gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: attention to bug 321435
Gerhard Tonn wrote: Thomas Bushnell BSG wrote: Please see http://bugs.debian.org/321435. This bug is that gs-gpl fails to work on s390. I recall just seeing a principal s390 developers say he was no longer doing the Debian s390 port. I don't know what effect this has on the bug. This bug is blocking a number of packages, at the very least, ifhp and scummvm. Something needs to happen... I'm not sure what. I have already looked into the bug and it seems to be a rather complicated issue. I will debug it in more detail this weekend. For some reason a recompiled version works now. I have uploaded a binary NMU and will rebuild dependent packages tomorrow. Gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 3.2 transition
On Friday 16 August 2002 15:51, Matthew Wilcox wrote: > I got sick of listening to people discuss the gcc 3.2 transition in an > uninformed manner. So I've whipped up a transition plan which will > hopefully get us from A to B without causing too much pain. Haha. > I'm entirely fallible and I don't pretend to understand all the issues > involved with doing the transition. But by writing down a plan at > least it can be updated and fixed before we have to start _doing_ > the transition. > > Comments and corrections welcomed. > I think, the question is, whether the transition should be done by the package maintainers or by the platform porters. If it is done by the platform porters a special build server has to be setup for each platform recompiling all packages depending on c++. A wanna build feature creating packages for NMUs can be used. The packages that have been built successfully can then be uploaded to a local archive or to auric which will probably break some other packages. The packages that haven't been built successfully have to be rebuilt. This is basically the approach used to build packages for a new architecture. The advantage is that the transition takes probably only one week on most architectures. The disadvantage is that we must know all C++ packages in advance. Gerhard
Re: GCC 3.2 transition
On Friday 16 August 2002 20:26, you wrote: > On Friday 16 August 2002 15:51, Matthew Wilcox wrote: > > If it is done by the platform porters a special build server has to be > setup for each platform recompiling all packages depending on c++. A wanna > build feature creating packages for NMUs can be used. I am currently doing this experiment on s390 without uploading of course. I have grepped the build logs of about 4000 packages that I have access to for g++|c++ and about 900 packages qualified. I am currently rebuilding these packages with gcc-3.2 using a local wanna-build DB. This will take some days. I will let you know the results. Gerhard
Re: GCC 3.2 transition
On Saturday 17 August 2002 19:28, you wrote: > > I am currently doing this experiment on s390 without uploading of course. I > have grepped the build logs of about 4000 packages that I have access to > for g++|c++ and about 900 packages qualified. I am currently rebuilding > these packages with gcc-3.2 using a local wanna-build DB. This will take > some days. I will let you know the results. > I have put the preliminary data to http://people.debian.org/~gt/gcc-3.2_transition/ .The file Packages contains all files currently being rebuilt. The subdirectory failed contains the build logs of all failed packages, still a lot, mainly due to c++ default argument check changes since gcc 3.0. The subdirectory dep-wait contains the build logs of all packages that depend on another package being built with gcc 3.2. I have qualified the dependency with subdirectories if known. The subdirectory 1iteration contains the build logs of all packages that compiled successfully during the first iteration, i.e. only dependent on libstdc++. The subdirectory 2iteration will contain the build logs of all packages that will compile successfully during the second iteration and so on. I will update the data once a day. Currently about 300 packages have been touched. I hope the data helps with any transition plan. I think Matthew has presented a fine plan, but it is open how long the transition will take with this plan. Maybe a deadline will be helpful, after that source NMUs should be done. Doing binary NMUs for each platform as in my experiment would also work but needs a volunteer for each platform and a lot of bug reports for all the failed builds. Both approaches will duplicate the size of the affected packages in the archive of course. Gerhard
First experience with gcc-3.2 recompiles
As I have told in another thread, I am currently rebuilding all packages depending on c++ on s390. All packages have been touched now. The results are: 406 packages have been built successfully 222 packages depend on other packages built with gcc-3.2 90 on qt libraries 12 on libsigc++ 7 on gtkmm 9 on fltk ... 246 packages haven't been built successfully In most cases a compile error similar to default argument given for parameter 12 of ... after previous specification in ... occurs. The build logs of the packages can be found at http://people.debian.org/~gt/gcc-3.2_transition Gerhard
Re: First experience with gcc-3.2 recompiles
On Sunday 25 August 2002 22:00, you wrote: > > > The build logs of the packages can be found at > > http://people.debian.org/~gt/gcc-3.2_transition > > I hate to say, but the list of failed packages needs to get > investigated a little bit, since not all failures seem to be GCC 3.2 > and syntax related: > > > apt: failed with "debian/rules:20: build/environment.mak: No such file or > directory" gg: failed with "/usr/bin/ld: cannot find -ljpeg" > hylafax: failed because textfmt wasn't built[1] > latte: failed with "Your STL string implementation is unusable." > nana: failed with "make: dh_testdir: Command not found" > qnix: failed with "make: execvp: ./configure: Permission denied" > I am going to write bug reports for build problems that are not gcc 3.2 specific. Gerhard
Re: First experience with gcc-3.2 recompiles
On Monday 26 August 2002 18:55, you wrote: > On Mon, 26 Aug 2002, Gerhard Tonn wrote: > > > apt: failed with "debian/rules:20: build/environment.mak: No such file > > > or directory" gg: failed with "/usr/bin/ld: cannot find -ljpeg" > > > hylafax: failed because textfmt wasn't built[1] > > > latte: failed with "Your STL string implementation is unusable." > > > nana: failed with "make: dh_testdir: Command not found" > > > qnix: failed with "make: execvp: ./configure: Permission denied" > > > > I am going to write bug reports for build problems that are not gcc 3.2 > > specific. > > Do be a bit careful, APT didn't build because you changed the package > (NMU version number) and didn't have autoconf/etc installed which are not > needed otherwise. > I have started to subcategorize the failed packages. The subdirectory gcc-3.2_specific contains the gcc-3.2 specific compile problems. The other failed packages are still under investigation. I will rebuild them with gcc-2.95 and without NMU versioning to verify the failure. Gerhard
Re: First experience with gcc-3.2 recompiles
On Sunday 25 August 2002 22:00, you wrote: > Gerhard Tonn wrote: > > As I have told in another thread, I am currently rebuilding all packages > > depending on c++ on s390. All packages have been touched now. The results > > are: > > > > 406 packages have been built successfully > > 222 packages depend on other packages built with gcc-3.2 > >90 on qt libraries > >12 on libsigc++ > > 7 on gtkmm > > 9 on fltk > > ... > > 246 packages haven't been built successfully > > > > In most cases a compile error similar to > > > > default argument given for parameter 12 of ... > > after previous specification in ... > > > > occurs. > > > > The build logs of the packages can be found at > > http://people.debian.org/~gt/gcc-3.2_transition > > I hate to say, but the list of failed packages needs to get > investigated a little bit, since not all failures seem to be GCC 3.2 > and syntax related: > > I have moved them to 4 subdirectories - 157 packages in gcc-3.2_specific - 46 packages in common (error occurs also with gcc-2.95) - 3 packages in s390_specific (e.g. ICE) - 24 packages in build_dep (if build dep packages are not installable) Gerhard
problems with binary NMU and apt
Hi, I have done some binary NMUs for s390 in order to fix bugs caused by previous compiler bugs. I experience now the following problem: The architecture dependent package created by the NMU have a 0.1 version, the architecture independent package compiled from the same source package don't have this suffix. But apt is looking for 0.1 version even for the architecture independent package and refuses to install any package dependent on this package. Is this a bug in apt or is there any workaround for this situation? Thanks, Gerhard
Re: problems with binary NMU and apt
>Which packages are these? It's probably a bug in the package source, in >that it's coded in such a way that bin-nmu's aren't possible. There're >a bunch of packages like that. (ie, a Depends: otherpkg (= myver) line) In my case it's esound-common, which in turn makes the entire gnome tree not installable. Regards, Gerhard
Re: problems with binary NMU and apt
On Saturday 15 September 2001 07:29, you wrote:
> In my case it's esound-common, which in turn makes the entire gnome tree
> not installable.
Most of the esound packages have a 'esound-common (>= ${Source-Version})'
dependency in debian/control. Is there any generic solution for the problem?
Regards,
Gerhard
at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Hi, I had recently a runtime problem on s390 with a package that compiled fine. After a while I figured out that it was caused by the fact that the package owner assumes that a char is signed per default. This is _not_ true on arm powerpc s390 Since in some cases this wrong assumption results in a warning comparison is always true due to limited range of data type or comparison is always false due to limited range of data type I grepped my archived build logs and found that all packages below have got this problem. Since I have currently not the time to write a bug report for each I would appreciate if the respective owner could look into the problem. A solution is to declare the datatype explicitly as signed char or compile using the option -fsigned-char. The build logs can be found at http://buildd.debian.org/ . Thanks, Gerhard abiword aee afterstep amaya anjuta appindex aprsdigi apt-spy asclassic asd4 autoclass ava aview beav berlin bl blackened blinkd bnetd bottlerocket c2050 camserv catdoc catdvi cbedic cern-httpd chimera2 cim cint clanlib0 clara console-tools crawl crimson curl-ssl dact dbview denemo dopewars dotconf dstooltk dx e2ps eco5000 ee electric elvis eterm ethereal everybuddy-cvs everybuddy evolution exdbm exult falconseye fcron flek flightgear flin francine freeamp freesci ftpgrab fvwm95 fwlogwatch gdl genesis genparse gerbv gimp1.2 giram glibc gliv gnapster gnokii gnome-admin gnome-chess gnome-pilot-conduits gnome-utils gnugo-dv gnumeric gom gphoto2 gpm grace gtetrinet gtkcookie gtkhx gxedit hanzim hextype icewm id3ren iiwusynth ilu imlib2 imwheel jmon kdelibs knapster2 koules lbreakout2 lbreakout lclint ldmud le ledcontrol leksbot lesstif1-1 libconvert-uulib-perl libflux0 libgtop libsidplay libtrain lifelines liveice log2mail lout lpkg lpr-ppd mailleds malsync marbles marlais mdk metamail mgetty mh micq mnogosearch motv mp3rename mrt mscompress nail ncbi-tools6 ncpfs netdiag netspades newt nfs-utils ntop nullmailer octave2.1 omega-rpg openh323 openmotif opennap openslp oregano orville-write osdclock p2c partimage paul pdnsd penguineyes perl-tk pfaedit pftp phaseshift pike7-crypto pike7.2 pike7 pnm2ppa pptpd prips python-4suite qcad rats re recover rstatd rungetty s3mod sablotron sac scite sclient scribus sgb shapetools si sigrot sitecopy skkinput snmpkit snowflake songprint spell sphinx2 spider startalk sted2 sword t1lib taper tcpstat tct template-new tkdesk tmview transformiix uisp unhtml unicon unixodbc uudeview uutraf vcdimager vcg vflib3 vfu viewml vlad vpnd vrflash w3c-libwww webalizer wmaker wmppxp workbone worklog wxwindows2.2 x11iraf xarchon xastir xawtv xchat xcin2.3 xcingb xcircuit xdrawchem xerces xfce xgalaga xlispstat xlockmore xlogmaster xmille xmms xmove xpaint xpenguins-applet xpenguins xsane xscavenger xshipwars xzip yacas yardradius yorick zmailer-ssl zmailer
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
>> A solution is to declare the datatype explicitly as signed char or compile >> using the option -fsigned-char. >Compiling with -fsigned-char, though it works, is not the "right" >solution. It's better to fix the bug in the code. I agree. As soon as a source is compiled with -fsigned-char and contains a function which calls a function _not_ compiled with -fsigned-char passing a char, this approach doesn't work. Btw., I did the grep on a local copy of the build logs. If you don't find the log of your package at http://buildd.debian.org/ let me know and I will you send an excerpt of the log. Regards, Gerhard
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Hi, I have changed my mind and will write semi-automatically a bug report for each of the packages with severity grave. I am currently rebuilding the latest version of each of the packages, so that a build log for s390 will be available at http://buildd.debian.org/ . I will then check that the problem is still there and write a bug report considering those who have already answered me. Regards, Gerhard
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Saturday 29 December 2001 11:59, you wrote: > * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]: > > I have changed my mind and will write semi-automatically a bug > > report for each of the packages with severity grave. > > Don't do this. That's fine with me. I don't see what it helps though except that the problems don't appear in the list of release critical bugs. Gerhard
