Call For Help - Please support the ppc64 architecture
Hello, This is a call for help from the 'ppc64' porters. On 05-Mar-14 16:14, Martin Michlmayr wrote: > Also, as with the amd64 port, there is disagreement about the name. > While ppc64 would be nicer and in line with the LSB, our current > PowerPC port is called powerpc and therefore it would make more sense > to call the 64 bit port powerpc64. There has been a decision of the Debian Technical Committee concerning the name of the amd64 port which basically says that the porting team should decide on the architecture name generally (see [1]). The ppc64 porters decided to use the name 'ppc64' as the package name a few month ago. That decision was mainly based on the fact that the Linux Standard Base LSB 2.0 states that 'ppc64' is the correct package name for the architecture. Other distributions like Fedora and Gentoo also use the name 'ppc64'. The Linux kernel uses 'ppc64', while the GNU toolchain uses 'powerpc64' with 'ppc64' as an alias. In the meantime, an archive for the ppc64 port has been set up on alioth (see http://debian-ppc64.alioth.debian.org/READ_ME for details). That archive uses the name 'ppc64' as the package name. An autobuilder for ppc64 is running, which follows the Debian unstable distribution. The autobuilder is self-hosting since January 2005, i.e. it runs the ppc64 port itself. The ppc64 archive on alioth currently has more than 85% of the packages from the Debian unstable distribution compiled. That number is still (slowly) rising. Every help will be appreciated, of course. Please help the ppc64 port by including support for the ppc64 architecture in 'dpkg' and other packages. Many thanks to all package maintainers who already applied patches to their packages to support the ppc64 architecture. Regards Andreas Jochens [1] http://lists.debian.org/debian-ctte/2004/06/msg00115.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-16 21:16, Scott James Remnant wrote: > On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > > > This is a call for help from the 'ppc64' porters. > > > Which group? According to Sven Luther's e-mail to debian-devel there > are currently two competing efforts for this port. There is only one native ppc64 port. There are people like Sven Luther and others who try to convert the current powerpc port into a biarch port, which is still mainly 32-bit based. This approach intends to add a 64-bit kernel and a biarch toolchain to the powerpc port and will allow the installation of selected 64-bit libraries and 64-bit binaries besides the 32-bit ones. This is somewhat similar to the i386 port which has already been extended with a 64-bit (amd64) kernel, a biarch (gcc-3.4) toolchain and some amd64 64-bit libraries. This kind of 64-bit extension of a 32-bit port is not the same thing as a native 64-bit port. Anyway, the biarch approach will also need a 'dpkg' which supports separate 64-bit ppc64 packages in the end. What are your concerns? Do you refuse to support a native 64-bit powerpc64/ppc64 port? Or do you want a different name for it? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-16 22:01, Scott James Remnant wrote: > On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: > > > On 05-Mar-16 21:16, Scott James Remnant wrote: > > > On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > > > > > > > This is a call for help from the 'ppc64' porters. > > > > > > > Which group? According to Sven Luther's e-mail to debian-devel there > > > are currently two competing efforts for this port. > > > > What are your concerns? Do you refuse to support a native 64-bit > > powerpc64/ppc64 port? Or do you want a different name for it? > > > My concern is the same as that of the Project Leader, that the existing > powerpc port is called "powerpc" -- and that we should at least try to > be consistent with already chosen architecture names. > > amd64 was reasonably unique in that it wasn't derived from any existing > architecture name. And in fact, in that case, I championed using the > LSB-mandated name (or as close thereto). > > If anything, that's ruled that Debian does not attempt harmony with LSB > names for architectures. So you would add 'powerpc64' support to dpkg if the port changes its package name accordingly? It would be possible to change the name to 'powerpc64' without too many problems. The port does not have many users yet and it will take only three or four weeks to recompile the current archive with a new package name. However, I still do not understand why you and/or the Project Leader want to override the decision of the porters and choose a different name than the LSB specifies. I am not saying that Debian should always follow the LSB blindly, but I cannot see a good reason for deviating from the LSB in this case. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On 05-Mar-17 09:46, Benjamin Herrenschmidt wrote: > Have we any proper way of doing multiarch setups ? The "proper" way to > do ppc64 is to have both archs libs and 32 bits userland for most > things, as ppc64 native code is slightly slower. Detailed measurements of 32 bit vs. 64 bit code for different applications have yet to be made. One of the purposes of the native 64 bit approach is that such comparisons will become easily possible. Without having native 64 bit libraries and binaries this would be just guesswork. > Also make sure the compiler is biarch as the kernel build will soon > require this. The compiler in the current ppc64 archive is fully biarch, i.e. it can produce 64 bit and 32 bit binaries. There is also a 64 bit and a 32 bit glibc version in the archive. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-16 22:24, Scott James Remnant wrote: > > So you would add 'powerpc64' support to dpkg if the port changes its > > package name accordingly? > > > Yes, that'd be applied to the 1.13 branch straight away. > > > However, I still do not understand why you and/or the Project Leader > > want to override the decision of the porters and choose a different name > > than the LSB specifies. I am not saying that Debian should always follow > > the LSB blindly, but I cannot see a good reason for deviating from the > > LSB in this case. > > > Because it's a 64-bit version of an already supported architecture. > Having "ppc" and "ppc64" would be fine, as would having "powerpc" and > "powerpc64". Having "powerpc" and "ppc64" is inconsistent. Inconsistent like i386/amd64 or s390/s390x? There is no rule which says that for a 64 bit architecture a '64' suffix has to be appended. There is not even a single case in Debian where this has been done, as far as I know. Moreover, I seriously doubt that this is an honest argument. I think you just want to decide the architecture name yourself. I am saying this because a few month ago you wrote this: On 04-Nov-24 08:29, Scott James Remnant wrote: > Please file this request with the powerpc64 port team, rather than with > the dpkg maintainer. > > Support for this architecture will not be included until the port team > have picked a name for it. This seemed to imply that you would respect the decision of the porters and that you do not want to decide the name yourself. Now that there is a decision and a whole archive with 85% of the packages compiled, you do not accept that decision. You are basically saying: "Take the name 'powerpc64' which I like best - or that architecture will not be supported." But you do not have any convincing reason for not accepting the choosen name. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-17 00:10, Scott James Remnant wrote: > No, I would just prefer consistency. You've deliberately chosen an > architecture name that's jarringly different from your 32-bit variant; > that's a rather bold thing to do, and I think you need to justify that. The decision to use the name 'ppc64' is based on the LSB and it is consistent with the decision of all other distributions I know of. > Obviously I have no power to overrule you on your choice of architecture > name, but I'd like to try and appeal to some common sense in you, if > there is any. I think that common sense would be to follow the LSB and to use the LSB conforming package name that all other distributions use. Again, the name of the port could be changed and the existing archive could be recompiled. But I think that people would later come to the conclusion that deviating from the standard was a bad thing in this case. I did not yet hear a single vote for the package name 'powerpc64' from anybody who is actively involved in the p(ower)pc64 port. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On 05-Mar-17 09:31, Bastian Blank wrote: > glibc 2.3.2 does not properly support powerpc64. This is correct. Because of this, the ppc64 Port uses glibc-2.3.4. The current Debian package has been patched to use version 2.3.4 for the ppc64 port. All patches used by the current Debian glibc which are already in version 2.3.4 have been dropped for this. Only about 30 patches out of more than 100 had to be kept. The newer glibc version works quite well so far. Two other packages needed a small patch to properly run with glibc-2.3.4. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Webmin-maintainers] Bug#304208: usermin-contrib: FTBFS: FileManager.java:6: package netscape.javascript does not exist
On 05-Apr-12 09:30, Jaldhar H. Vyas wrote: > Andreas Jochens wrote: > > When building 'usermin-contrib' on i386/unstable with sun-j2sdk1.4, > > I get the following error: > > So don't do that then. The build depends is for j2sdk1.4 (i.e. Blackdown.) 'j2sdk1.4' is virtual package which is provided by 'sun-j2sdk1.4', 'blackdown-j2sdk1.4' and 'ibm-j2sdk1.4' all of which can be created with the help of 'make-jpkg' from 'java-package'. So the Build-Depends seem to allow the use of 'sun-j2sdk1.4'. Anyway, the package also does not compile with the j2sdk1.4 from Blackdown or IBM. > > Something seems to be missing here. > > netscape.javascript.JSObject used to be in the Java plugin but apparently > Sun has dropped it. I know next to nothing about Java but if you can > figure out a workaround that would be great. I googled a bit, but unfortunately I could not yet find any useful hint where to get 'netscape.javascript.JSObject', sorry. Why did you close #304208? Can you compile 'usermin-contrib'? I think that it is a bug if a source package cannot be compiled. Even if the package is from 'contrib', there should be at least a description of a working procedure to build the package. If external files are necessary to build a package, it should also be specified how to get those files. Am I wrong here? What is the general opinion on this? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Webmin-maintainers] Bug#304208: usermin-contrib: FTBFS: FileManager.java:6: package netscape.javascript does not exist
On 05-Apr-12 10:52, Jaldhar H. Vyas wrote: > I was able to on Jan 30, when I built the package. > > > I think that it is a bug if a source package cannot be compiled. > > Oh definitely. The question is why can I do it and you can't? My fault, it was a problem with my setup. I have 4 different j2sdk versions installed in parallel and I did not make the correct changes to debian/rules to make the compilation work with one of them. I tried it a few more times and finally managed to compile the package by just changing the classpath and the javac command in debian/rules to $(JAVA_HOME)/bin/javac -classpath $(JAVA_HOME)/jre/lib/plugin.jar [...] and pointing $(JAVA_HOME) to the appropriate directory. Maybe you could introduce 'JAVA_HOME' in debian/rules to make this easier? Or even 'JAVA_HOME_DIRS' with the default directories from the standard 'java-package' j2sdk1.4 packages preset? Thank you for your fast reply and sorry for the noise. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of 'sarge' for the amd64 architecture
As a preparation for the amd64 porters irc meeting tomorrow, I tried to build the complete Debian sarge archive for the amd64 architecture from the unpatched Debian sarge sources. It took about a week to build all 8800+ source packages on a standard single processor EM64T-P4 box (Every package was built in a newly created clean chroot environment. By relaxing this requirement, the build time for the archive could probably be reduced to less than four days.) The result was very encouraging. Almost all packages build now on amd64 without problems using the pristine Debian sarge sources. There are very few remaining cases where a patch has been submitted to the BTS a long time ago and for some reason that patch has not yet been applied. These cases could either be solved by a porting NMU or by just dropping that package from the amd64 version of sarge. For some reason, the amd64 architecture has not been added to the official Debian archive. There is a plan to change this when sarge is released, but as I understand it, there is no plan to provide amd64 binaries for sarge in the official Debian archive. This means that Debian sarge will be released with source packages that can be used to build a complete and fully usable Debian sarge distribution for the amd64 architecture, but there will be no binaries available in the main Debian archive. This is not necessarily as bad as it may look at a first glance. First of all, everybody can build its own Debian amd64 sarge archive from the official Debian sarge sources. It will take only a few days to build the complete archive on cheap commodity hardware. This archive build process, including later updates, can easily be automated by a small script. To build packages from sources instead of downloading binary packages from a Debian archive may be a good idea from a security point of view. For critical applications it seems to be problematic to trust a binary archive which depends on the integrity of the machines of 1000 Debian developers. But of course, there _is_ a binary Debian amd64 sarge archive. The debian-pure64 amd64 archive on alioth is maintained by members of the amd64 porting team. It tracks the current Debian 'unstable' and 'testing' distributions. In the current situation, the amd64 porting team is responsible for providing and maintaining the amd64 binary archive and the amd64 buildd infrastructure, while the sources are taken from the normal Debian source archive. I consider this a good way to split up responsibilities. This way of handling things could serve as a good example of how other ports may be organized after sarge is released. As a conclusion, I think that it may still be possible to release the amd64 port with sarge. Nothing in the current setup has to be changed for that. It is just a matter of recognizing the current state of affairs officially. It will only be necessary to describe the current situation in the official release documents and include pointers to the separate amd64 archive, which will be provided by the amd64 porting team anyway. Regards Andreas Jochens P.S.: The above statements represent my personal view only. Other members of the amd64 porting team may view things differently, of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Hello Steve, thank you for your reply to my status report. Steve Langasek wrote: > Andreas Jochens wrote: >> It will only be necessary to describe the current situation >> in the official release documents and include pointers >> to the separate amd64 archive, which will be provided >> by the amd64 porting team anyway. > > Have you discussed this with the security team, and have they agreed to > provide stable security support for amd64 in sync with the other > architectures? Or have they agreed to coordinate with someone on the amd64 > team for security support? I don't think we can consider it an official > stable port without this key feature. This is still an open issue, yes. Security support for amd64 sarge will be one of the main topics for the amd64 porters irc meeting today. An autobuilder has been prepared which will build amd64 security updates for sarge as soon as the sources become available. However, as far as I know, this has not yet been officially coordinated with the security team and I do not know the position of the security team on this. But I am confident that a solution can be found for this issue. The amd64 is certainly willing to do the necessary work. Besides security support, do you have any other concerns which should be addressed to make a sarge release for the amd64 architecture possible? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sarge release for amd64 - Please help to fix the remaining bugs
tion found (/usr/lib/libsctp.a) ruby-gnome2 #304951 "*** extconf.rb failed ***" sam #280259+ missing '#include ' in libframe/misc.c snacc#277690 "*** [tbl.c] Segmentation fault" socks4-server#280262+ missing '#include ' syslinux #306123+ amd64 missing from architecture list and FTBFS tct #254165+ missing 'defined(x86_64)' and '#include ' tela - configure: error: "Blas not found!" vnc4 #276238 "debian/scripts/vars.amd64: No such file" wine - needs porting/depends on 32bit libs xfs-xtt #253544+ "debian/scripts/vars.amd64: No such file" xmms-kde #284977 "Can't find X libraries" xppaut #306173+ missing '#include ' xview#294844+ amd64 missing from architecture list A '+' after the bug number indicates that a patch is available which fixes the problem. Additionally, the following "Architecture: all" packages from Debian sarge fail to build from source on amd64: Package Bug No. Description --- --- libtool1.4 #247299 demo-nopic.test has to be skipped on amd64 ... [this table has to be completed] Last update: 2005-04-24 Andreas Jochens <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
Hello Steve, thank you for your quick reply to my amd64 bug list. Steve Langasek wrote: >> libmysqlclient-lgpl - Linuxthreads test has to be switched off for amd64 > > I'm not going to give this a high priority, personally; all my reasons for > adding this package in the first place have since been addressed by the > upstream licensing fixes, so anything still using it is of fairly limited > use (especially with the protocol incompatibilities with MySQL 4.1). I agree with this. Applications should Build-Depend on the newer libmysqlclient14-dev or at least libmysqlclient12-dev instead of libmysqlclient10-dev from libmysqlclient-lgpl. This was one reason why I did not yet file a patch for libmysqlclient-lgpl with a similar change as the one that has been applied to the mysql-dfsg and mysql-dfsg-4.1 packages. However, I made a mistake with respect to the importance of the libmysqlclient-lgpl package. It was possible to build it on amd64 about a year ago when the toolchain was different. That version is still in the current amd64 archive on alioth. But now, with the new toolchain, it does not build on amd64 anymore. Unfortunately, quite a few important packages still Build-Depend on libmysqlclient10-dev: cyrus-sasl2 cyrus-sasl2-mit exim4 gpsdrive ircii-pana linesrv motion mp3kult mydns mysql-navigator pam-mysql pike7.2 pike7.4 pike7.6 pimppa postfix prokyon3 pure-ftpd www-sql xlc It would certainly be a good idea to update the Build-Depends for those packages. Ideally, the libmysqlclient-lgpl package could be dropped entirely. But I guess it will not be possible to fix all those Build-Depends for sarge. I will file a patch for libmysqlclient-lgpl in a separate mail. >> portslave- "pppd.h: No such file or directory" > > Hmm, you may want to re-check this against current versions of ppp and > portslave. This was a bug in sid which has been fixed recently. The fixed version of portslave has entered sarge, but sarge has an older version of ppp, which does not work with that fix. Because of this, portslave has a FTBFS problem in sarge now until the latest ppp makes it into sarge. Again, thanks for looking at my list of amd64 related FTBFS bugs. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
Steve Langasek wrote: >> portslave- "pppd.h: No such file or directory" > > Hmm, you may want to re-check this against current versions of ppp and > portslave. I just re-checked this again and now portslave builds fine in testing, thanks. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
Hello Kurt, thank you for the clarifications. On 05-Apr-25 19:49, Kurt Roeckx wrote: > On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote: > > gnustep-base - + does not build with gcc-3.3 (needs gcc >= 3.4) > It looks like it builds fine with gcc-3.3. But if my memory is > any good, it (used to?) miscompile it? Yes, gcc-3.3 used to miscompile gnustep-base on amd64. The build of many gnustep-related packages stopped with something like "autogsdoc ... error" if I remember correctly. I have to re-check if this is still the case. > > libgtk-java - java.lang.NullPointerException > There are alot of java package that fail to build and I still > have to track those down. Those are ussually not the fault of > the package itself. They're also arch all, so you can get them > from the archive anyway. kaffe used to work fine for quite some time on amd64, but the latest versions either stop with "java.lang.NullPointerException" or get into an endless loop when I try to build a java package. Unfortunately, libgtk-java is not arch:all. We need to get kaffe fixed somehow :) > > portslave- "pppd.h: No such file or directory" > ?? This was a problem with an older version of ppp that seems to be fixed. portslave builds fine now. > > tela - configure: error: "Blas not found!" > ?? I still have to check this one further. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
Andrew M.A. Cater wrote: > On Mon, Apr 25, 2005 at 11:32:25AM +0200, Andreas Jochens wrote: >> Debian sarge release for the amd64 architecture >> --- >> >> At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting >> team decided to release a version of sarge for amd64 which is based on the >> unpatched Debian sarge source packages. >> > This is good news for at least some of the users I support :) > > I run a full mirror of Debian here: can you please advise precisely what > else I need to mirror? The basic source of information for amd64 archive and mirror questions is http://debian-amd64.alioth.debian.org/archive-structure.txt However, please note that this structure is not yet fully in place. An announcement will be made when the move to the new host has been completed and the structure has been set up. > Has the amd64 / pure64 split been sorted out yet: which amd distribution > is this? If this is "straight amd64", should I also be making plans to > mirror pure64 / amd64-gcc4.0 or whatever it's to be called? There will only be one official amd64 archive. That archive will follow the unpatched Debian stable, testing and unstable distributions. The current amd64/gcc-4.0 archive will be continued in a separated project to sort out any remaining issues for Debian's planned move to gcc-4.0 for etch. Now that gcc-4.0 has been officially released, the gcc-4.0 archive will be recompiled from scratch and reuploaded to a different location. Details will be announced as soon as this has been completed. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#306639: batik: FTBFS: JAVA_HOME_DIRS incorrect
Hello Arnaud,
On 05-Apr-27 23:07, Arnaud Vandyck wrote:
> Thanks for your bug reports, but you have to know that you can't file
> FTBFS bugs reports about packages that are in contrib and relay on
> packages that are not in Debian to build!
> The non-free JDK's are not officially supported so the packages built
> with non-free jdk's are not meant to be built 'as is' (I mean without
> modification).
> I have no problem with wishlist bugs to ease the build of the package on
> every arches (which is not needed because these packages are arch: all!)
> but this is *not* serious bugs!
I tried to file only those bugs as 'serious' which can be reproduced on
i386. For bugs which are amd64 specific, I usually use 'wishlist' severity.
Of course, I may have made a mistake in some cases.
At least this particular bug occurs on all arches. It is not very nice
to have to read, understand and manually change 'debian/rules' and
maybe some other files to get a package built. In particular, this makes
any kind of autobuilding impossible, which is a bad thing from a
security point of view - and also inconvenient, of course.
For the Java related packages, the {sun,ibm,blackdown}-j2sdk1.x packages
which can be created by make-jpkg from 'java-package' make it easy to
set up an autobuilder, as long as all packages support this by setting
the correct JAVA_HOME directories and by specifying the correct
Build-Depends.
Anyway, I will file those problems as 'wishlist' in the remaining cases.
Some other types of bugs like
"'Missing Build-Depends on 'junit'" or
"'./debian_patch' not executable"
also appear on all arches including i386. I think those are 'serious'
FTBFS bugs, even for packages in 'contrib'. What should be done with
those?
> Any way, I leave all the bug you reported and will try to upload fixes
> as soon as possible.
Thank you for all the fixes to my reports which you already uploaded
and for your work in general!
Regards
Andreas Jochens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#306639: batik: FTBFS: JAVA_HOME_DIRS incorrect
Hello Steve, On 05-Apr-28 02:56, Steve Langasek wrote: > by Debian, so I don't think it's fair to require that contrib java packages > be buildable with any particular j2sdk package. > > By all means, please keep filing (and fixing) bugs so that we can get as > many contrib packages as possible autobuilding, but especially with the > freeze coming soon, I don't think this should be RC for sarge. OK, I will file the remaining similar issues as 'wishlist' items. > > Some other types of bugs like > > > "'Missing Build-Depends on 'junit'" or > > "'./debian_patch' not executable" > > > also appear on all arches including i386. I think those are 'serious' > > FTBFS bugs, even for packages in 'contrib'. What should be done with > > those? > > I agree that those should be RC, since they are not about packages we don't > distribute. Thank you for clarifying this. Regards Andreas Jochens P.S.: Thanks a lot for the upload of the 'libmysqlclient-lgpl' package with the amd64 fix! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#306254: axe: FTBFS: "Failed to satisfy Build-Depends dependency for axe: libxaw-dev"
On 05-Apr-28 12:21, H. S. Teoh wrote: > On Mon, Apr 25, 2005 at 11:42:50AM +0200, Andreas Jochens wrote: > > E: Package libxaw-dev has no installation candidate > > E: Failed to satisfy Build-Depends dependency for axe: libxaw-dev > > > > The new version 6.1.2-14 in 'sid' does not have this problem. > [...] > > Yes, I have already fixed this problem in 6.1.2-14, but it is not > getting into testing. This package is non-free, and unfortunately that > means people aren't very inclined to build it on the various archs for > me. > > Also, I don't think this bug should affect the RC bug count for sarge, > since it *is* non-free after all. Is there any reason for severity: > serious here, other than the fact that the fixed package hasn't made > it into testing yet? The bug is tagged 'sarge' which indicates that it does not affect sid. I think it is an RC bug for sarge as long as the new version has not entered testing/sarge, which may or may not happen before the release. Please correct me if I am wrong here. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug Squashing: List of remaining FTBFS bugs for amd64/sarge
On 05-May-06 00:24, Steve Langasek wrote:
> On Fri, May 06, 2005 at 08:58:27AM +0200, Andreas Jochens wrote:
> A few things you might want to do with this list here:
...
> - post it to debian-devel so people can poke through these for the BSP this
> weekend
The new list of FTBFS bugs will still not be perfect, but here it is.
Thank you to everyone who helped to fix some of the bugs from the
previous version of this list.
Packages from sarge with build problems on amd64
There are still a few packages in sarge which fail to build on amd64.
Those packages and all their dependencies will be removed from the
amd64 sarge release unless the problems are fixed and the fixed
version gets accepted into sarge by the release team. (For a very
limited number of release critical packages, like debian-installer, the
amd64 porting team may decide to make an exception to this rule and use
a package version with a minimal patch to make the release possible.)
Please note that many of the problems listed below also occur on
other architecures.
A '+' after the BTS bug number indicates that a patch is available
which fixes the problem. A '*' after the BTS bug number indicates
that there is a fixed version available in the 'unstable' distribution.
Any fixes for the listed bugs and any information regarding the status
of the bugs will be highly appreciated.
Especially the packages listed with a proper bug number and a patch
sign ('+') may be candidates for the Bug Squashing Party this weekend.
Release critical bugs for amd64:
sarge/main/amd64 BTS Bug Problem description
--- ---
debian-installer #306976+ libdevmapper1.00 does not exist (should be 1.01)
debian-installer #307306+ Uses kernel 2.6.10 which is not in sarge
syslinux #306123+ amd64 missing from architecture list and FTBFS
FTBFS bugs for amd64 which have been fixed in sid but not in sarge:
hfsutils #280310* missing '#include '
krb4 #175491* configure does not define HAVE_H_ERRNO
libglademm2.0#279985* "$LD" vs. $LD in configure
libhdf4 #251275* missing amd64 support in hdf/src/hdfi.h
lvm2 #298762* "device/dev-io.c:342:3: #error miss O_NOATIME"
radiusd-livingst #273629* missing '#include '
Other FTBFS bugs for sarge/main/amd64:
advi #307919+ missing Build-Depends on groff-base
amsynth #274703+ missing '#include ' in main.cc
armagetron - dh_installchangelogs: command returned error code 11
atari-fdisk #248794+ amd64 not in architecture list
binutils-h8300-h #251648+ machine `x86_64-pc' not recognized
cbmlink #207003+ uses i386 specific code
cdrdao #249634+ x86_64-linux-{cc,gcc}.rul links missing
cfdisk-utf8 #249926+ missing 'defined(__x86_64__)' / not in Arch list
commons-daemon # + x86_64 support missing in Makedefs and configure
elk - + needs workaround for ICE with gcc-3.3
freewnn #142253+ segfaults during build (same as on ia64 #229390)
ghdl #276399 ghdl internal compiler error: Segmentation fault
guile-core #255894+ amd64 missing in UNSUPPORTED_QTHREAD_ARCHS
guile-gnome-plat #304936+ "comparison always false due to limited range..."
heaplayers - "*** [allocators] Error 1"
ircd-ircu#254165+ configure check for res_mkquery fails
k3d #278966 compilation of expression.cpp does not finish
kmatplot #286533+ missing -fPIC
libgtk-java - + java.*.NullPointerException/builds without-javadoc
libnss-pgsql #273800+ should use pthread_mutex_t instead of libc_lock_t
libooc-vo#164726 "*** [EMAIL PROTECTED]@] Error 1"
libpolyxmass #303856+ passing arg 5 of `bsearch' from incompatible pointer
licq - + undefined reference to pthread_kill_other_threads_np
linux86 #260647+ elksemu's file format not recognized
lxdoom #279190+ missing '#include '
masqmail #254720+ configure check for res_search in -lresolv fails
mindi- + missing amd64 in architecture list
mn-fit #301509 segmentation fault on 64bit architectures
mondo- + missing amd64 in architecture list
mtr #254089+ configure check for res_mkquery broken
muddleftpd #253618 missing -fPIC
mypasswordsafe #307316+ FTBFS if USER environment variable is not set
nntp #280278+ missing '#include '
octave-gpc #307188* no match for 'operator[]' in '*m["vertices"]'
octaviz #302688+ cast from 'vtkObjectBase*' to 'int' loses precision
ogre - &q
Re: Compatibility between Debian amd64 and other distributions
Hello, On 06-Sep-23 02:50, Goswin von Brederlow wrote: > FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non > Debian distributions follow that line. Gentoo uses basically the same setup as Debian, i.e. it installs 64-bit libraries in /usr/lib and it has a symlink from /usr/lib64 to /usr/lib. > Steve Langasek had concerns about side-effects: > > That probably means that a change for this would not be accepted > > into etch, since fiddling library paths may have unexpected > > side-effects and glibc is already frozen. > > So far I have seen none. The proposed glibc patch will break the installer. The installer does not have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. It has been decided following some discussion.) The proposed patch changes the 64-bit library access paths used by glibc, i.e. (s)libdir, from (/usr)/lib to (/usr)/lib64. With this change, the /usr/lib64 symlink would become a necessary requirement for things to work properly. Currently, the distribution works even without the /usr/lib64 symlink. > Now I guess the release-team has to make a decision how important the > FHS and compatibility is to Debian. The proposed patch may improve compatibility with Redhat or Novell but it does not improve compliance with the FHS. The relevant parts of the FHS 2.3 are: A) "/lib : Essential shared libraries and kernel modules Purpose: The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin. B) "/lib : Alternate format essential shared libraries (optional) Purpose: There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries. [Footnote:] This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them." C) "/lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. Rationale: This is a refinement of the general rules for /lib and /usr/lib. The architectures PPC64, s390x, sparc64 and AMD64 support support [sic!] both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture." Summarized, Debian and Gentoo comply with A) and B) but not with C) while Redhat and Novell comply with B) and C) but not with A). It could be argued that the special rule C) overrides the general rule A). On the other hand, the "Rationale" of C) shows that C) was designed specifically for i386/amd64 biarch distributions with a strong i386 32-bit part. But Debian amd64 is a full native 64-bit distribution. The 32-bit part is purely optional and many people will not install any 32-bit binaries at all on their amd64 machines. The status quo for 64-bit and 32-bit libraries on Debian amd64 is as follows: 1) (/usr/)/lib64 is a symlink to (/usr)/lib 2) The dynamic linker name is /lib64/ld-linux-x86-64.so.2 (as per LSB). 3) 64-bit libraries are installed in /usr/lib and accessed via /usr/lib. 4) 32-bit libraries are installed in /emul/ia32-linux/(usr/)lib and there are symlinks from (/usr)/lib32 to /emul/ia32-linux(/usr)/lib. 1), 2) and 3) are consistent with the FHS 2.3 as long as no 32-bit libraries are installed on the system. Only 4) is a deviation from C) with respect to the location of the 32-bit libraries. The FHS 2.3 rule C) mandates that 32-bit libraries have to be stored in (/usr)/lib on amd64. To implement this in Debian would be difficult because almost every library package would have to be changed to install the native library files in a separate /usr/lib64 directory instead of the usual /usr/lib. The other Debian ports have their native libraries installed in /usr/lib. Many packages rely on this fact. Many things, especially during the build process, will break if the native libraries are not in /usr/lib. It would be a _lot_ of work to change the whole distribution to use /usr/lib64 instead of /usr/lib as the location of the native libraries. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
Hello Frans, Frans Pop wrote: > Andreas Jochens wrote: > > The proposed glibc patch will break the installer. The installer does > > not have the symlink from /usr/lib64 to /usr/lib. (This is not by > > accident. It has been decided following some discussion.) > > The symlink currently is there actually: > > rootskel (0.79) unstable; urgency=low > [...] > * Joshua Kwan > - Symlink lib to lib64 to unhork amd64 images. Patch by Kurt Roeckx > <[EMAIL PROTECTED]> (Closes: #256738) > > -- Colin Watson <[EMAIL PROTECTED]> Fri, 2 Jul 2004 12:05:29 +0100 > > The link is currently created for amd64 and ppc64. rootskel only creates the symlink from /lib64 to /lib which is required to run dynamically linked binaries. It does _not_ create the symlink from /usr/lib64 to /usr/lib. This can be verified by looking into an amd64 installer image. There is no /usr/lib64 in the amd64 installer images. BTW, thank you for applying the ppc64 patch. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365203: rootskel: Please support the ppc64 architecture
On 06-Apr-29 20:51, Frans Pop wrote: > tags 365203 - pending > tags 365203 + wontfix > tags 365345 + wontfix > tags 339716 + wontfix > tags 354947 + wontfix > thanks > > I'm very sorry, but after discussing this during the d-i development > meeting and consulting with Release Management, we feel that the ppc64 > port ever reaching the archives is currently too uncertain to add support > for it in D-I packages. > > Please try to get consensus on the future of the port first. Hello Frans, thank you for looking at the ppc64 patches and for discussing ppc64 on the d-i meeting. I know that there is no consensus about the future of the ppc64 port. There have been some discussions that the native ppc64 port might be useful to provide multiarch support for powerpc/ppc64 in the same way as for i386/amd64. The ppc64 port is currently the only way to get a reasonably complete set of 64-bit libraries for ppc64 machines. But again, there is no consensus about this and there is certainly no plan to add the ppc64 port to the official archive in the near future. Despite of this, I would like to ask the d-i team and all other developers to help the ppc64 port by continuing to apply simple ppc64 patches, which in most cases just add 'ppc64' to the architecture line in debian/control and similar places. Even if the ppc64 port will never be part of an official release, this should not do any harm. Most packages in the archive have already added ppc64 support (most notably gcc, glibc and dpkg). The ppc64 archive has about 98% of the source packages from the unstable distribution compiled. Even some d-i packages (netcfg and yaboot-installer) added explicit ppc64 support some time ago. Please do not tag wishlist requests for the addition of 'ppc64' to the architecture line in debian/control as 'wontfix'. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Hello Aurelien, On 06-May-19 04:15, Aurelien Jarno wrote: > [Ccing: amd64 and dpkg developers as they are concerned by this subject] > Currently the (/usr)/lib64 -> /lib symlink is shipped in the libc6 > package. Goswin von Brederlow asked for this link to be created in the > postinst instead, so that packages could install files in both > (/usr)/lib and (/usr)/lib64 directories. > > > Could you please give me your opinion on that, so that I can take a > decision? please do not change the status quo regarding the lib64 symlinks. During the porting of Debian to amd64 quite a few alternatives regarding the lib64 issue were discussed and tested. The biarch approach with /usr/lib and /usr/lib64 as two different directories failed badly. > I have concerns about that: > - I don't really want to add something specific to amd64 in postinst. > But ok, that's not an argument. > - I am not sure that creating the link in postinst will work. Creating > it in preinst looks safer to me. > - If you can install files in (/usr)/lib64, the files will end up in > (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other > tools won't work correctly. > - If you have two packages providing the same files in (/usr)/lib and > (/usr)/lib64, then the files will be overwritten without warning. This > is IMHO not acceptable. I share these concerns. The current policy which requires all packages to install native amd64 libraries in /usr/lib is simple and sane. This should not be changed. Anything which makes it easier to violate this simple policy will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently to problems which could be difficult to disentangle later. This is just my personal opinion. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
On 06-May-19 11:02, Goswin von Brederlow wrote: > Andreas Jochens <[EMAIL PROTECTED]> writes: > > Anything which makes it easier to violate this simple policy > > will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently > > to problems which could be difficult to disentangle later. > > The goal would be to actualy get everything into (/usr)/lib64 while > intermittendly allowing a mixed usage. That would allow for FHS > compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*, > lib32asound, ia32-libs and more to come. Yes, I understand that it is your goal get everything into /usr/lib64. But this means that every single library package has to be changed to use /usr/lib64 instead /usr/lib. You will probably not achieve that in an etch or even in an etch+1 time frame. You will just get an ugly mixture of /usr/lib and /usr/lib64 usage. If you really want to do this, I suggest that you set up a test archive and convert everything to use /usr/lib64 and collect all the patches that are necessary to achieve this. Then these patches can be reviewed and it can be decided if this is the way to go. However, this has been tried before. The result was that this does not work well. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Will the amd64 port be rejected because of the 98% rule?
On 05-Aug-21 03:58, Wouter Verhelst wrote: > - must have successfully compiled 98% of the archive's source (excluding > arch-specific packages) It is not possible to build 98% of the unmodified source packages from the 'unstable' distribution. This is true for any port including i386. For the current 'unstable' distribution it is not even possible to build 90% of the unmodified source packages because of the ongoing transitions and the high number of FTBFS bugs. I followed the 'unstable' distribution since the beginning of 2004 with private buildds on different architectures and I recreated the complete 'unstable' distribution many times from scratch by rebuilding every package. It was hardly ever possible to build more than 95% of the unmodified source packages from 'unstable' at any given point in time, even when the number of FTBFS bugs was much lower than it is now. I understand that the amd64 port has to be recompiled for the final inclusion into the official archive because the current amd64 packages have not been built by DDs. But currently more than 10% of the unmodified source packages from 'unstable' FTBFS. It will likely take many months, if not years, for amd64 to get anywhere near to the requested 98% mark again. Will the amd64 port be rejected if more than two percent of the unmodified source packages from 'unstable' fail to compile? If not, what does the 98% rule really mean? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will the amd64 port be rejected because of the 98% rule?
On 05-Aug-22 11:48, Andreas Barth wrote: > * Andreas Jochens ([EMAIL PROTECTED]) [050822 11:36]: > > I understand that the amd64 port has to be recompiled for the > > final inclusion into the official archive because the current amd64 > > packages have not been built by DDs. But currently more than 10% of > > the unmodified source packages from 'unstable' FTBFS. It will likely > > take many months, if not years, for amd64 to get anywhere near to the > > requested 98% mark again. > > Come one. Packages which are known as buggy (= have FTBFS RC-bugs) are > of course counted as, well, buggy. Though of course our hope is that the > number of such packages goes down, both by removals and bug fixing. > > > > If not, what does the 98% rule really mean? > > "Your port needs to be able to and does build the vast majority of the > archive before we consider it fitting for release." That there are more This is of course a fully reasonable requirement. I hope that the final policy will use these words instead of the "98% rule" which will likely cause misunderstandings. Moreover, I think that the release team should have the power to decide if this general requirement is fulfilled. This seems to be better than specifying some arbitrary and debatable figure which will most probably lead to useless discussions and flames about numbers. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Results of the meeting in Helsinki about the Vancouver proposal
> On Mon, Aug 22, Wouter Verhelst wrote: > > > - binary packages must be built from unmodified Debian source > > > > Uhm? When there is a new arch upcoming, they need to modifiy the Debian > > source, at least sometimes, right? > > Yes, and this happens. I've already had requests to modify my > Architecture: line in my nbd packages for new ports, such as amd64 and > ppc64, even before they're part of the archive. > > It's not hard to do this, and if there's a valid patch, people usually > apply it. Yes, most maintainers are very helpful to porters and apply those kind of simple patches to add support for a new architecture. As someone who sent quite a few such requests, I would like to thank all maintainers who applied these kind of changes and helped to sort out architecture specific problems. Unfortunately, there are also maintainers who say something like "I will not make my package work on architecture xxx because that architecture is not part of Debian.". This is rare, but it happens. I recently got such a reaction when I tried to convice a maintainer of the 'linux-2.6' kernel package to add a small 8-line patch to support the native ppc64 port by reusing the kernel config files which are already available on the regular powerpc architecture. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] You can't host a full Debian archive on Alioth
On 05-Sep-20 13:41, Raphaël Hertzog wrote: > Alioth is running out of space and that's mostly because of the > debian-ppc64 archive. > > Please use the alioth project for what it is: a project coordination > place. Not a Debian repository. > > Please remove the archive and host it somewhere else. You should keep > only what's useful to start helping : > - failed build logs > - patches > > Please act promply and reply to us or we'll arbitrarily remove a part of > it so that we have again a bit of free space. Hello Raphaël, I just freed about 25 GB of disk space on alioth. That space was occupied by the old amd64/gcc-4.0 archive which was used to prepare the Debian transition from gcc-3.3 to gcc-4.0. Now that the transition to gcc-4.0 is almost complete, that archive will no longer be necessary for any purpose. Generally, alioth has been used to host full Debian repositories for a long time now. The various amd64 repositories have been hosted on alioth from the beginning of 2004 until a few month ago and the ppc64 repository has been hosted on alioth since December 2004. The request for the debian-ppc64 alioth project explicitly stated that a binary package repository for native ppc64 packages would be created. I understand from your mail that the policy for alioth projects has changed since then. I currently have no other place to host a public archive for the native 64-bit Debian-ppc64 port. Because of this, I did not yet delete the debian-ppc64 archive from alioth as you requested. I hope that someone has an idea what to do with the debian-ppc64 archive and that alioth can host it until a better solution is found. The ppc64 archive currently has a size of about 30 GB, but I will probably be able reduce this to about 15 GB by dropping old package versions. Hopefully this will be acceptable. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] You can't host a full Debian archive on Alioth
On 05-Sep-20 19:01, Bastian Blank wrote: > On Tue, Sep 20, 2005 at 05:44:34PM +0200, Andreas Jochens wrote: > > I currently have no other place to host a public archive for the > > native 64-bit Debian-ppc64 port. Because of this, I did not yet > > delete the debian-ppc64 archive from alioth as you requested. > > Debian have access to two openpower machines with some disk space. May > a partition on one of this machines suffice your needs? This would of course be great. What would I have to do make this happen? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The Debian package name for the ppc64 architecture is 'ppc64'
On 05-Sep-23 15:54, Sven Luther wrote: > (and btw, i may have posted about in favour of ppc64 in the paste, but > powerpc64 is indeed what looks best :) Hello Sven, six month ago the Debian package name for the ppc64 port was discussed on debian-devel and you voted for 'ppc64' in that discussion (http://lists.debian.org/debian-devel/2005/03/msg01828.html). A decision for the name 'ppc64' has been made six month ago. The main reasons for that decision was that the LSB specifies 'ppc64' as the standard package name and that all other distributions which have ppc64 packages use that name. Packages in the Debian archive have started to use that name in many places after that decision, e.g. 'dpkg', 'apt', 'gcc-4.0' and many others. About 95% of the 'unstable' distribution have been compiled for the ppc64 architecture using that name. Please stop trying to change the package name 'ppc64'. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
