Bug#613365: New upstream release available
Package: desmume Version: 0.9.6-1-1 Severity: wishlist A new upstream release is available since feb 01: http://sourceforge.net/projects/desmume/files/desmume/0.9.7/ It fixes a number of issues with homebrew programs compiled with recent versions of devkitpro-arm. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages desmume depends on: ii libasound2 1.0.23-2.1shared library for ALSA applicatio ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libgcc11:4.4.5-10GCC support library ii libgl1-mesa-glx [libgl 7.10-3A free implementation of the OpenG ii libglade2-01:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.28.0-1 The GLib library of C routines ii libglu1-mesa [libglu1] 7.10-3The OpenGL utility library (GLU) ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libosmesa6 7.10-3Mesa Off-screen rendering extensio ii libpango1.0-0 1.28.3-1+squeeze1 Layout and rendering of internatio ii libsdl1.2debian1.2.14-6.1Simple DirectMedia Layer ii libstdc++6 4.4.5-10 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime desmume recommends no packages. desmume suggests no packages. -- no debconf information -- Computer Architecture and Networks Group University of Castilla-La Mancha [http://arco.esi.uclm.es/~francisco.moya/] Tel:(+34) 926 295 483, Fax:(+34) 926 295 354
Bug#551074: zeroc-ice33 build for etch (still) failing to detect amd64 bit arch, generates ICE_32 libs
Thanks for your bug report. I added an #include stdint.h to get WORDSIZE defined on etch libc. I also applied your fallback to upstream wordsize/endian selection. A new version should be uploaded shortly. Is your backport of zeroc-ice33 and related packages available to anyone? Regards, Paco On Thu, Oct 15, 2009 at 2:37 PM, Siim Põder s...@p6drad-teel.net wrote: Package: zeroc-ice Version: 3.3.1-6 Although bug #539930 has been closed, I recently tried building zeroc-ice on 64bit etch system. This time it fails more consistently - the build works fine but resulting IceUtil libraries use long long for 64bit integres. I checked the Config.h and sure enough, it was defining ICE_32 where the endianlimits patch adds the __WORDSIZE detection. This seems to be the problem: $ nm -CD /usr/lib/libIceUtil.so | grep seconds 0002c770 T IceUtil::Time::seconds(long long) Resulting in at least this: $ python Python 2.4.4 (#2, Oct 22 2008, 20:20:22) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type help, copyright, credits or license for more information. import Ice Traceback (most recent call last): File stdin, line 1, in ? File /var/lib/python-support/python2.4/Ice.py, line 19, in ? import IcePy ImportError: /var/lib/python-support/python2.4/IcePy.so: undefined symbol: _ZN7IceUtil4Time12microSecondsEl But probably other stuff is likely to be broken as well. For now I'm building with your endianlimits patch changed to check if __WORDSIZE is even defined and fall back to upstream wordsize detection: // // 32 or 64 bit mode? // +#if defined(HAVE_LIMITS_H) +# ifndef __USE_XOPEN +# define __USE_XOPEN +# endif +# include limits.h +# if defined(__WORDSIZE) +# if __WORDSIZE == 32 +# define ICE_32 +# else +# define ICE_64 +# endif +# endif +#endif + +#if !defined(ICE_32) !defined(ICE_64) #if defined(__linux) defined(__sparc__) // // We are a linux sparc, which forces 32 bit usr land, no matter ... #else # define ICE_32 #endif +#endif I understand that failing __WORDSIZE detection, the upstream one will not work on all platforms supported by Debian. However, at least on 64bit etch, it works: $ nm -CD libIceUtil.so.33 | grep seconds 0002c720 T IceUtil::Time::seconds(long) I don't think this bug is particularily important and will not take it as a personal offence should you decide to wontfix it ;) Siim -- Computer Architecture and Networks Group University of Castilla-La Mancha http://arco.esi.uclm.es/~francisco.moya/http://arco.esi.uclm.es/%7Efrancisco.moya/ Tel:(+34) 926 295 483, Fax:(+34) 926 295 354
Bug#530562: icecpp is not required for newer releases
notfound 530562 3.3.0-1 thanks From upstream release 3.3.0 the developers dropped icecpp. They now use libmcpp which is listed as a dependency. Regards, F. Moya
Bug#543990: It should not but it is
tags 543990 +pending thanks On Sun, Aug 30, 2009 at 4:06 AM, Ana Guerrero a...@debian.org wrote: Dear Francisco and Cleto (I expect), [...] By the way, it is not your package, but since you are the sponsor, I understand you feel resposible about it, which is quite fine. Indeed, a serious violation of the policy would be my responsibility. On Fri, Aug 28, 2009 at 11:22:08PM +0200, Francisco Moya wrote: I must have missed something. What is wrong in my statements? What file is rejected by Debian and why? What in this package contradicts the debian policy? I not only mean the letter of the DP but also the rationale behind it. What is wrong with this particular package given that ows is in Debian till 2007 and nobody complained? Since you do not quote here what you are answering, I am not sure at all what are you answering. It is usually nice quote exaclty what you are answering, it is one of the problems I have found to follow and understand you correctly in this bug report. My fault, sorry. 1. Upstream main author is David Villa, which clearly stated *his* release policy and clearly refused to change it. I try to respect upstream opinions as much as Debian allows it. You do not have to change David's release policy at all. Actually, in this case, for what I have seen, David does not have any release policy, he does Obviously you didn't even tried to contact David. You didn't even tried to see the upstream head, which enforces *his* release policy. not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. Wrong (Cf. Debian Policy 3.2.1) For what I have seen in the package, the versions that are being uploaded are numbered after the date YYMMDD from a checkout of the code in the SVN and this code include a debian/ directory. Wrong, versions (and releases) are changed at commit time. The current head generates versions and releases at commit time, see upstream head. Let me explain you the way this is usually handled in Debian: CASE A) (easy case) When upstream release tarballs with the debian/ dir. This happens from time to time. Maintainer usually ask upstream to drop this directory from the tarballs and in the meanwhile (or if upstream just do not care), the maintainer repackage upstream's tarball to remove this directory. Not in this case. The maintainer is a developer. It wouldn't make much sense to ask himself to remove the debian directory. CASE B) (complicated case) upstream does not do releases at all and has debian/ in their repo. It seems to be the case here. In short, maintainer do a svn checkout, version it someway, package it and upload it. And follows Debian policy 3.2.1. He uses the same version numbers of upstream code. More lengthy: since there are not releases maintainers ned to version it, usually people start with a 0 and use the svn revision, for example, for the revision 56 of atheist, you could number it: 0.svn56 or 0.0.svn56, so it indicates in the version number exacty what revision is, which is quite handy when bug reports are filed to upstream. Using the date as it is being used in atheist is not a good idea, what if you need to do 2 or more uploads in the same day due to upstream changes? There is a release, although is not an orthodox release. Read the source and talk to David, much better than using the BTS for this. If in the future upstream starts releasing and it breaks your invented revision number, you can use an epoch. Indeed David already provides something like an epoch in his release scheme. See atheist.py from svn. Whan packaging, packager put this fictional version number and then the packaging revision with -X. About the debian/ dir, you just ignore it and if it is the case you are using that debian/ then you add it later. Not the case, the maintainer cannot ignore his own debian directory. In this case, of fictional versions it is a very good idea ask your sponsoree add a get-orig-source: rule in his debian/rules, so you can fetch the code exaclty as the sponsoree did and just the version he wants to upload easily. Fictional versions are only appropriate if the upstream release scheme does not work for Debian. It is not the case. No, you won't find about get-orig-source: in the policy, that does not mean you can not use it, if you google it you will see how useful it is for a lot of people, even for one of the policy maintainers: http://www.eyrie.org/~eagle/notes/debian/scripts.htmlhttp://www.eyrie.org/%7Eeagle/notes/debian/scripts.html there you can find some info of how to implement and use the get-orig-source: target. Yeah, sounds quite easy. You are basically asking upstream to use two branches to maintain a 32KiB package just to cope with your best practices and it wouldn't get you anything (see below). And you know what it is very good about get-orig
Bug#544245: perhaps it shouldn't but it is
severity 544245 wishlist tags 544245 +pending thanks Package: go2 Version: 0.090827 Please, make the package no native, I do not see reason to make it native. Please, see bug 543990 for more information. It will be fixed in the next upload.
Bug#543990: It should not but it is
On Sun, Aug 30, 2009 at 2:02 PM, Ana Guerrero a...@debian.org wrote: On Sun, Aug 30, 2009 at 01:37:32PM +0200, Francisco Moya wrote: Obviously you didn't even tried to contact David. You didn't even tried to see the upstream head, which enforces *his* release policy. You are pointing me again to talk with upstream several times. That is *your* job,( sorry, your sponsoree's job...), upstream theoreticaly has nothing do to with debian. Right, my job. I talked to David, but you don't seem to believe it. Do contact him *if you don't trust me*. I also told you to contact Cleto to get more information on why he doesn't want to be listed as an author. Is that also my responsibility? not release tarballs, and even if he did, you are not affected but his release policy to be forced to ship binary packages. Wrong (Cf. Debian Policy 3.2.1) yes, when upstream does releases, no the case. Your opinion and David's opinion seem to differ. He is the main author. Who is right? His opinion is also in svn head: atheist/doc/conf.py: ... from atheist import VERSION version = VERSION # The full version, including alpha/beta/rc tags. release = version David releases the code for every commit. Odd? Probably, but considering this as unreleased code is not less unusual. I already talked to David about releases, versions, and packaging. Besides, after wasting hours the bug is already pending and it will be fixed in the next upload. Do you really think we are doing any good to Debian now? Rest of the mail skip since you are repeating again and again the same stuff and you keep reciting your own interpretation of the the debian policy as a parrot. It is also sad you did not even try to understand what other people and I tried to explain you. We all are far more experienced than you in Debian and we have tried to explain you how do things better, and you have not even tried to think about what we explained you. What is really sad is that you didn't even notice that I made my best to reach a consensus. Indeed this bug is already tagged pending. If I open the discussion in -devel then I would need to allocate enough time to collect opinions, summarize, etc. I'm sorry but my time is limited right now. Things may change in the future, but I consider this a minor issue and indeed we all agreed to fix this in the next release, even when I didn't find *any* convincing argument. If things are so worthless as you think they are it should be a quick discussion. And if you want to ask and discuss about policy changes, use -policy, no -devel... Ana I don't see the correlation between severity and time to reach a consensus. This thread seems to contradict what you say.
Bug#544171: copyright file does not mention any web page
Insulting Ana? I do value her work as much as anybody else. I did not pretend to be rude to Ana. My apologies if it sounds that bad. It was all about prioritizing QA. Anything that - Affect minimally to users - Affect minimally to developers - Affect minimally to the overall quality of the package and/or the distribution - Does not violate DP both in letter and/or spirit Should be considered low priority in my opinion. Of course you can ignore what I say. Regarding the title of the bug report note that I also explained why the title lead to confusion. A quick and dirty web page without any commitment to be maintained in the future is much worse than a subversion repository, which was the original source. Regards, F. Moya On Sun, Aug 30, 2009 at 4:01 PM, Cyril Brulebois k...@debian.org wrote: Hi dear overlord Francisco. I'm deeply sorry in advance for eating your great time, but I feel compelled to reply, in particular to you (but I'm keeping the bug and Ana in Cc for further reference). Francisco Moya francisco.m...@uclm.es (30/08/2009): I do value my time, so please, do not CC me unless I request it. How the hell are we supposed to know you're going to get a reply? You're not the maintainer, so unless you're subscribed to the PTS or to the bug, nobody can know you're going to get a reply. Unless you say so of course, which you didn't. Given you're also breaking the mail thread, one can only assume you never got the reply. Not to mention that the policy on the BTS is obviously to Cc everyone involved since there's no autosubscription. But maybe you're not *that* familiar to the BTS yet? The file does not say anything about the content, it just provides an URI. Therefore there is nothing there that could possibly confuse people. If you wish a clarification on how to fetch the code then please, use a bug title which doesn't lead to more confusion. Given it's a *title* it can't really be as long as the body, which covers your expectation. I answered the bug report to reduce the severity, because the maintainer is not yet used to the Debian policy. For example, he made a quick and dirty web page because he thought he had to provide one due to your bug report. That's not the case. The source was taken from the svn repo and there is no official atheist page yet. It's too bad the maintainer can't read what Ana wrote. Or (XML-)parse it properly. Or can't get from the requirements from the Policy. Or whatever. It seems you enjoy some spare time these days. Perhaps you are also interested on working on these bugs http://bugs.debian.org/release-critical/ You may want to stop insulting Ana. From what I've seen, she's the one doing QA those days, _and_ working on RC bugs. Not you. On Sun, Aug 30, 2009 at 2:58 AM, Ana Guerrero a...@debian.org wrote: Top-posting and full-quoting? Nice job! Mraw, KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqahkMACgkQeGfVPHR5Nd1RcwCeNLHsB/J/r67N8uHajahLm7rO gVAAoJD3TqAYMpFhqCstDM7eg/At87fw =J5kE -END PGP SIGNATURE-
Bug#543990: It should not but it is
On Sat, Aug 29, 2009 at 12:17 PM, Aurelien Jarno aurel...@aurel32.netwrote: I don't understand why you insist on hiding this discussion in all your emails. It looks like you are not confident with you opinion. Since when are the discussions of debian-devel hidden? Since when talking about the Debian policy and upstream release policies is a problem? I insist on talking about bugs in the BTS and talking about the Debian policy on the proper places. And as you like citing the Debian Social Contract, let me do the same: | 3. We will not hide problems | We will keep our entire bug report database open for public view at | all times. Reports that people file online will promptly become | visible to others. Who is talking about hidding anything? Please, do use the BTS, and report bugs or provide information. But don't use it as a communication tool because it isn't. For example, your message and this message have nothing to do with the bug report. Is the BTS the appropriate place to send them? No. Regards, F. Moya
Bug#544171: copyright file does not mention any web page
severity 544171 wishlist thanks Currently the Debian policy does not require that the program source must be available from an HTTP stream with text/html content. Therefore, whether a text/html renderer is able to show the source or not is a non-issue for any package. I changed the severity of this bug to reflect this. We will add a notice to clarify this in the next release. Regards, F. Moya
Bug#544171: copyright file does not mention any web page
I do value my time, so please, do not CC me unless I request it. The file does not say anything about the content, it just provides an URI. Therefore there is nothing there that could possibly confuse people. If you wish a clarification on how to fetch the code then please, use a bug title which doesn't lead to more confusion. I say we, because I have commited my first change into upstream svn repo, to close 543990. I answered the bug report to reduce the severity, because the maintainer is not yet used to the Debian policy. For example, he made a quick and dirty web page because he thought he had to provide one due to your bug report. That's not the case. The source was taken from the svn repo and there is no official atheist page yet. It seems you enjoy some spare time these days. Perhaps you are also interested on working on these bugs http://bugs.debian.org/release-critical/ Regards, F. Moya On Sun, Aug 30, 2009 at 2:58 AM, Ana Guerrero a...@debian.org wrote: On Sun, Aug 30, 2009 at 02:46:00AM +0200, Francisco Moya wrote: severity 544171 wishlist thanks Currently the Debian policy does not require that the program source must be available from an HTTP stream with text/html content. Therefore, whether a text/html renderer is able to show the source or not is a non-issue for any package. I changed the severity of this bug to reflect this. debian/copyright should state where the code was fetched, it does not necessarly need to be a website, but the way you present it in the file leads to think it, that is why asked you to make explicity how it is fetched. We will add a notice to clarify this in the next release. we? the package only has one maintainer who already answered the bug report :D Ana PS: it is usually a good idea CC the submitter of the bug and quote the bug report you are answering. -- Computer Architecture and Networks Group University of Castilla-La Mancha http://arco.esi.uclm.es/~francisco.moya/ Tel:(+34) 926 295 483, Fax:(+34) 926 295 354
Bug#543990: It should not but it is
Probably Chris Lamb is right in that atheist *should not* be a debian native package. But it is by decision of upstream authors. There is no separate repository for debian stuff and debian releases *do change* the atheist package version. Therefore while it is not a Debian specific package it is nonetheless [...] the case where a piece of software was written specifically to be turned into a Debian package (cf. DP 5.6.12). It wouldn't make sense to make a source package where diffs are always empty (forced by release policy) and the debian revision is always 1. Of course things may change in the future but the main upstream author does not seem to be open to discuss the release policy and version scheme (I tried). OTOH, I believe these issues should not be discussed in a bug tracking database. If doubts on the technical competence of the maintainer and/or the sponsor arise, please do contact them directly rather than filling the bug database with non-issues. Best regards, F. Moya -- Computer Architecture and Networks Group University of Castilla-La Mancha http://arco.esi.uclm.es/~francisco.moya/ Tel:(+34) 926 295 483, Fax:(+34) 926 295 354
Bug#543990: Debian maintainers should not impose upstream release policies
severity 543990 wishlist thanks As I already stated I contacted upstream authors to have a sane release policy. But I'm not the one to decide. Neither the maintainer. As I already stated the *upstream* release policy dictates that a new debian release increases the *upstream* package version. It is that simple and there is nothing we can do about it. I'll forward your concerns to upstream authors but *as I already stated* upstream author is not currently willing to change the release policy. There are a million reasons to support that debian releases should be separate from upstream releases but *as I already stated* I tried and failed to convince upstream author. As long as the package does not break the debian policy it can no longer be considered a serious bug. Nonetheless we will keep this as a wishlist item as a testimony of your thoughts (which are also mine). Cheers, F. Moya -- Computer Architecture and Networks Group University of Castilla-La Mancha http://arco.esi.uclm.es/~francisco.moya/ Tel:(+34) 926 295 483, Fax:(+34) 926 295 354
Bug#543990: Ok, ok, please, help us to reduce the noise
Since the issue is treated with enough level of detail I think there is no need to increase the BTS traffic. Just for your information many (if not all) of the packages developed by David Villa follow similar release policies. Therefore ows, atheist and some others I hope to upload to Debian in a near future will have the very same problem. Almost every aspect of *his* release policy is in the border of what Debian policy recommends. There are three options here: 1) convince David of the need for a different policy, 2) promote some changes in the Debian policy (some *should* may be turned into *must*), 3) issue wishlist bugs against all these packages. Regards, F. Moya
Bug#543990: It should not but it is
I must have missed something. What is wrong in my statements? What file is rejected by Debian and why? What in this package contradicts the debian policy? I not only mean the letter of the DP but also the rationale behind it. What is wrong with this particular package given that ows is in Debian till 2007 and nobody complained? 1. Upstream main author is David Villa, which clearly stated *his* release policy and clearly refused to change it. I try to respect upstream opinions as much as Debian allows it. 2. The package maintainer is Cleto Martin, also a developer of atheist. His commits go directly into the svn repo. There is no separate branch for packaging because, as the *main* upstream author requires, package version is also changed when the debian directory changes. Therefore this is indeed a Debian native package. It may posibly be turned into a non-native package but it would require a fork, which in my opinion is much worse than this. 3. The versioning scheme although not the most orthodox one does not create problems for Debian. No need for epochs and no problems in case of debian-only related changes. For me it is just a matter of inconvenience for them. Could you be more precise on the problems you forsee for Debian? 4. I consider the package itself to be a small utility but extremely convenient for many people. Therefore I think it should be part of Debian (Debian Social Contract #4). 5. The maintainer *is* one of the upstream developers with commit rights to the atheist repo but he is not entitled to change the release policy. Therefore if upstream ships a file that Debian does not want to include anymore then Cleto Martin, the maintainer will remove it from upstream repo. It works as long as the maintainer is an upstream developer and there is a real commitment to develop a Debian package. That is precisely what a native package is. 6. Having a discussion like this in a place like the BTS is worse than having the same discussion in debian-devel or debian-private. As you can imagine, people which are so strongly opinionated on their release policy may easily get angry at such loose argumentation against their way of doing things. Should Debian require the package maintainer (an upstream developer) to remove the debian directory from upstream source to introduce it afterwards in the diff? Wow, this really sounds tough. If upstream author writes a sentence if not in_a_Debian_system(): exit 0 then we would consider it a native package? How many debian dependencies must be introduced in order to consider it a native package? No joking, these are the complaints I heard today. Should Debian require an empty diff to go along the package for its whole life? This one is easier to swallow. Is there any other rationale behind native packages than trying to avoid empty diffs? Note that using nativeness to infer debian infrastructure packages is plainly wrong. Let's just imagine apt is ported to work on RPM repositories. Sounds familiar? Should we turn apt into non-native now? On the other hand having this kind of discussions on a BTS is just faking the stats. One more serious bug in the back of Debian distro. No wait it is closed. No, wait, it was reopened as a serious bug. No, wait it is wishlist. 9 follow-ups. This one must be a tough bug! Is it? Come on, this is a small simple package which just happens to have an unusual name and an unusual release policy. But it is still useful nonetheless. I do believe that there are hundreds of bugs which require more attention than this one. But since it seems to be such an attractor I propose two actions: 1. I'll try to convince the maintainer to turn this package into a non-native package with an empty diff. It sounds silly to me but it seems way better than splitting upstream source as proposed by Luk. What Luk propose would be equivalent to deny anybody the right to make a program ready to be used in Debian. 2. I urge you to reconsider having this discussion in a more appropriate place. Cheers, F. Moya
Bug#484683: New release is out
Note that desmume 0.9 was already released. It would be great if you reconsider your decision not to enable gdb stubs. Desmume is so nice for homebrew developers just because of this feature. Desmume is not too accurate (specially regarding illegal conditions, such as unmapped memory access) but it is the only free emulator with builtin gdb support. Thanks, F. Moya
Bug#497964: zeroc-ice: FTBFS on GNU/kFreeBSD
Hi Petr,
Thank you for the patch and the bug report.
I've just added a slightly modified version of your patch to a new
release of zeroc-ice packages but before I request changes upstream
I need to understand what is going there.
ZeroC Ice source contains several #ifdef __FreeBSD__ what makes me
think that FreeBSD (though unsupported) is being used by some staff
at ZeroC. But they don't remove monotonic clocks calls on FreeBSD.
Therefore I would like to verify whether this stanza should be using
__FreeBSD_kernel__ or another more appropriate define:
diff -u zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch
zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch
--- zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch
+++ zeroc-ice-3.3.0/debian/patches/20-hppa-linux-threads.patch
@@ -6,7 +6,7 @@
}
-#if !defined(__hpux) !defined(__APPLE__)
-+#if !defined(__hppa) !defined(__APPLE__)
++#if !defined(__hppa) !defined(__APPLE__) !defined(__FreeBSD_kernel__)
rc = pthread_condattr_setclock(attr, CLOCK_MONOTONIC);
if(rc != 0)
{
@@ -18,7 +18,7 @@
return Time(static_castInt64(tb.time) * ICE_INT64(100) +
tb.millitm * 1000);
}
-#elif defined(__hpux) || defined(__APPLE__)
-+#elif defined(__hppa) || defined(__APPLE__)
++#elif defined(__hppa) || defined(__APPLE__) || defined(__FreeBSD_kernel__)
//
// HP/MacOS does not support CLOCK_MONOTONIC
//
OTOH your changes in Make.common.rules seem to be cheating to me:
+--- zeroc-ice-3.3.0.orig/config/Make.common.rules
zeroc-ice-3.3.0/config/Make.common.rules
+@@ -28,6 +28,15 @@
+ UNAME := $(shell uname)
+ MACHINE_TYPE := $(shell uname -m)
+
++ifeq ($(UNAME),GNU/kFreeBSD)
++ UNAME := Linux
++endif
++
++ifeq ($(UNAME),GNU)
++ UNAME := Linux
++endif
++
++
I made a variant of this in debian/rules because it breaks the way ZeroC
handles different systems. ZeroC includes a per-system Make.rules and
therefore if there are two systems similar they should be handled with
a common include.
For me, the most intringuing stanza is the following:
+--- zeroc-ice-3.3.0.orig/cpp/src/IceSSL/Instance.cpp
zeroc-ice-3.3.0/cpp/src/IceSSL/Instance.cpp
+@@ -69,7 +69,7 @@
+ // On some platforms, pthread_t is a pointer to a per-thread structure.
+ //
+ return reinterpret_castunsigned long(pthread_self());
+-#elif (defined(__linux) || defined(__sun) || defined(__hpux)) || defined(_AIX)
++#elif (defined(__linux) || defined(__sun) || defined(__hpux)) ||
defined(_AIX) || defined(__GLIBC__)
+ //
+ // On Linux, Solaris, HP-UX and AIX, pthread_t is an integer.
+ //
You are essentially claiming that all GNU libc on any system are using
a pthread_t of type long integer. Are you sure of this? A quick grep
into GNU libc source reveals that on Solaris it is defined as a thread_t.
Nowadays a thread_t is certainly a long int but it is an indication of
GNU libc using the native platform representation for threads.
I did not apply the following stanza to the debian package but I will
report it upstream. Debian packages do not need to generate a binary
distribution other than the one generated by dpkg-buildpackage.
Would it be safe to say sys.platform.startswith(gnu)? That would take
into account GNU/Hurd too.
+--- zeroc-ice-3.3.0.orig/py/makebindist.py
zeroc-ice-3.3.0/py/makebindist.py
+@@ -87,7 +87,7 @@
+ platform =
+ if sys.platform.startswith(win) or sys.platform.startswith(cygwin):
+ platform = win32
+-elif sys.platform.startswith(linux):
++elif sys.platform.startswith(linux) or
sys.platform.startswith(gnukfreebsd):
+ platform = linux
+ elif sys.platform.startswith(sunos):
+ platform = solaris
--
Francisco Moya Fernandez Computer Architecture and Networks Group
Assistant Professor
[EMAIL PROTECTED] School of Computer Science
Fax:(+34 926) 29 53 54University of Castilla-La Mancha
Tel:(+34 926) 29 54 83 http://arco.esi.uclm.es/
-Original Message-
From: Petr Salinger [mailto:[EMAIL PROTECTED]
Sent: Fri 05/09/2008 20:48
To: [EMAIL PROTECTED]
Subject: Bug#497964: zeroc-ice: FTBFS on GNU/kFreeBSD
Package: zeroc-ice
Severity: important
Version: 3.3.0-9
Tags: patch
User: [EMAIL PROTECTED]
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It needs following changes:
* alter of debian/rules-*.mk
* extend debian/patches/20-hppa-linux-threads.patch, as the same
approach is needed for GNU/kFreeBSD
* new debian/patches/20-kfreebsd.patch, GNU/kFreeBSD specific patch
Please find attached patch with all needed changes.
The override in clean target (UNAME=Linux) is because during make clean
is not applied 20-kfreebsd.patch which also alters config/Make.common.rules.
It would be nice if you can ask upstream
to include changes in 20-kfreebsd.patch.
Thanks in advance
Petr
Bug#497885: zeroc-icee-translators: FTBFS on GNU/kFreeBSD
I will add your patch to the debian package ASAP but I'm afraid ZeroC dropped icecpp some time ago. Icecpp is now replaced by libmcpp. Therefore there is no way to incorporate the patch upstream. Cheers, Paco -Mensaje original- De: Petr Salinger [mailto:[EMAIL PROTECTED] Enviado el: vie 05/09/2008 8:53 Para: [EMAIL PROTECTED] Asunto: Bug#497885: zeroc-icee-translators: FTBFS on GNU/kFreeBSD Package: zeroc-icee-translators Severity: important Version: 1.2.0-5 Tags: patch User: [EMAIL PROTECTED] Usertags: kfreebsd Hi, the current version fails to build on GNU/kFreeBSD. It needs small tweak, see bellow. It would also be nice if you can ask upstream to include this changes. Thanks in advance Petr only in patch2: unchanged: --- zeroc-icee-translators-1.2.0.orig/src/icecpp/config.h +++ zeroc-icee-translators-1.2.0/src/icecpp/config.h @@ -12,7 +12,7 @@ // configure script from the gcc-2.8.1 distribution. // -#if defined(__linux) || defined(__FreeBSD__) \ +#if defined(__linux) || defined(__GLIBC__) || defined(__FreeBSD__) \ || defined(__sun) || defined(__hpux) || defined(__APPLE__) \ || defined(_AIX) || defined(__osf1__) # define TIME_WITH_SYS_TIME 1 @@ -42,7 +42,7 @@ # endif #endif -#if defined(__linux) || defined(__FreeBSD__) || defined(__sun) || \ +#if defined(__linux) || defined(__GLIBC__) || defined(__FreeBSD__) || defined(__sun) || \ defined(__hpux) || defined(__APPLE__) || defined(_AIX) # define HAVE_INTTYPES_H 1 #endif
Bug#497609: RM: zeroc-ice-csharp -- ROM; zeroc-ice replaces it
Package: ftp.debian.org Severity: normal Upstream developers no longer distribute zeroc-ice-csharp as an independent package. Starting in zeroc-ice 3.3.0 it is already included in zeroc-ice. It was not removed automatically because zeroc-ice provides libzeroc-ice-3.3-cil while the latest zeroc-ice-csharp provided libzeroc-ice-3.2-cil. Regards, F. Moya [EMAIL PROTECTED]
Bug#496562: FTBFS bug not fixed
close 496562 thanks Domenico Andreoli kindly allowed me to use his Debian/HPPA to explore this bug. The package compiled fine out of the box and I performed some basic tests to ensure the packages are fully functional. Now let's look into the build log failing on HPPA: http://buildd.debian.org/fetch.cgi?pkg=zeroc-ice;ver=3.3.0-8;arch=hppa;stamp=1219692046 ... c++ -c -I.. -I../../include -DICE_API_EXPORTS -ftemplate-depth-128 -Wall -D_REENTRANT -I/usr/include/nptl -D_REENTRANT -DHAVE_ENDIAN_H -DHAVE_LIMITS_H -fPIC -g Instance.cpp c++ -c -I.. -I../../include -DICE_API_EXPORTS -ftemplate-depth-128 -Wall -D_REENTRANT -I/usr/include/nptl -D_REENTRANT -DHAVE_ENDIAN_H -DHAVE_LIMITS_H -fPIC -g LocalException.cpp c++: LocalException.cpp: No such file or directory c++: no input files make[3]: *** [LocalException.o] Error 1 make[3]: Leaving directory `/build/buildd/zeroc-ice-3.3.0/cpp/src/Ice' make[2]: *** [all] Error 1 make[2]: Leaving directory `/build/buildd/zeroc-ice-3.3.0/cpp/src' make[1]: *** [all] Error 1 make[1]: Leaving directory `/build/buildd/zeroc-ice-3.3.0/cpp' make: getcwd: No such file or directory make: *** cpp/doc: No such file or directory. Stop. make: *** [debian/stamp-build-cpp] Error 2 1. Make starts compiling LocalException.cpp. Therefore it was there when make was looking for a way to obtain LocalException.o. 2. When c++ fails it is no longer there, but worst of all, the whole directory was removed (getcwd fails). 3. There was no messages on exceeding maximum compilation time. What should I do now? I have working packages made from the latest archive sources but they were not compiled with pbuilder. Should I submit a new version to force recompilation? Regards, Paco
Bug#487038: zeroc-ice-csharp: FTBFS: Nonexistent build-dependency: ice32-services
Dear Thijs, zeroc-ice-csharp, zeroc-ice-python, zeroc-ice-java and zeroc-ice-ruby are going to be removed from the archives as soon as the new zeroc-ice (=3.3.0-1) is properly built on all architectures. There was a major change in the release policy upstream and now there is a single tar ball (zeroc-ice). Currently it fails on hppa. I wrote an email to the debian-hppa list but I didn't receive a response yet. I don't have access to any HPPA machine either. If problems are not fixed by this week I'll drop hppa from the supported architectures. Regards, F. Moya -- Francisco Moya Fernandez Computer Architecture and Networks Group Assistant Professor [EMAIL PROTECTED] School of Computer Science Fax:(+34 926) 29 53 54University of Castilla-La Mancha Tel:(+34 926) 29 54 83 http://arco.esi.uclm.es/ -Mensaje original- De: Thijs Kinkhorst [mailto:[EMAIL PROTECTED] Enviado el: jue 28/08/2008 0:16 Para: FRANCISCO MOYA FERNANDEZ CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: Re: zeroc-ice-csharp: FTBFS: Nonexistent build-dependency: ice32-services Hi Francisco, On Wed, 2 Jul 2008 13:54:01 +0200, you wrote: I'm aware of the buildep problems. Ice embedded should be fixed shortly. OTOH zeroc-ice-python, zeroc-ice-ruby, zeroc-ice-php, zeroc-ice-java and zeroc-ice-csharp will all be requested to be removed from ftpmaster as soon as some arch-related problems are sorted out. The latter packages were replaced by a monolithic zeroc-ice source package due to upstream reorganization. We're now nearly two months later.. are those arch problems resolved, or is there still something to do before we can fix these bugs? cheers, Thijs
Bug#496562: zeroc-ice: FTBFS on hppa
Package: zeroc-ice Version: 3.3.0-7 Severity: serious Justification: no longer builds from source According to buildd.debian.org package zeroc-ice fails to compile on hppa due to missing POSIX monotonic clocks on libc6. It seems Linux/HPPA still uses LinuxThreads instead of NPTL. A possible solution might be to change #ifdef __hpux into #ifdef __hppa in the appropriate places of the source code in order to disable monotonic clocks on this platform. I do not have access to a HPPA machine though.
Bug#496562: FTBFS bug not fixed
reopen 496562 thanks Build log for 3.3.0-8 reveals that the bug is not yet fixed. http://buildd.debian.org/fetch.cgi?pkg=zeroc-ice;ver=3.3.0-8;arch=hppa;stamp=1219692046 F. Moya [EMAIL PROTECTED]
Bug#489761: Bug#489718: python-zeroc-ice: Cannot load IcePy.so from python2.5
Package: zeroc-ice Version: 3.3.0-4 I believe bug #489718 was fixed in release 3.3.0-4 but I forgot to add a changelog entry. Regards, F. Moya
Bug#489761: zeroc-ice-manual: Add HTML doc
Dear Romain, I've just uploaded a new set of zeroc-ice 3.3.0 packages. I added the HTML documentation generated from the Slice files but I'm not sure this is what you requested in your bug report. I'm aware of an online HTML version of the ZeroC Ice manual but I'm afraid ZeroC does not redistribute it as a package for offline reading. Am I wrong? Regards, F. Moya -Original Message- From: Romain Bossart [mailto:[EMAIL PROTECTED] Sent: Mon 07/07/2008 17:54 To: Debian Bug Tracking System Subject: Bug#489761: zeroc-ice-manual: Add HTML doc Package: zeroc-ice-manual Version: 3.3.0-1 Severity: wishlist Hi, Could you add the html documentation in the next release? Thanks! Regards, Romain -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.4 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information
Bug#487028:
tags 487038 +pending tags 487028 +pending tags 487040 +pending tags 487030 +pending tags 487033 +pending tags 487027 +pending thanks I'm aware of the buildep problems. Ice embedded should be fixed shortly. OTOH zeroc-ice-python, zeroc-ice-ruby, zeroc-ice-php, zeroc-ice-java and zeroc-ice-csharp will all be requested to be removed from ftpmaster as soon as some arch-related problems are sorted out. The latter packages were replaced by a monolithic zeroc-ice source package due to upstream reorganization. Regards, Paco
Bug#484683: desmume: Segfault when using GDB stubs
Package: desmume Version: 0.8-1 Severity: important Hi, I get a segfault whenever I try to use the --arm9gdb or --arm7gdb command line options. The fix is quite easy. Upstream source should have a configure option to enable GDB stubs. But currently they use a preprocessor constant (GDB_STUB). Therefore you may just change the definition of CFLAGS in debian/rules: CFLAGS = -DGDB_STUB -Wall -g Thanks, F. Moya -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages desmume depends on: ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libc6 2.7-12GNU C Library: Shared libraries ii libcairo2 1.6.4-3 The Cairo 2D vector graphics libra ii libgl1-mesa-glx [libgl 7.0.3-1 A free implementation of the OpenG ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libglu1-mesa [libglu1] 7.0.3-1 The OpenGL utility library (GLU) ii libgtk2.0-02.12.9-4 The GTK+ graphical user interface ii libgtkglext1 1.2.0-1 OpenGL Extension to GTK+ (shared l ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libpango1.0-0 1.20.2-2 Layout and rendering of internatio ii libsdl1.2debian1.2.13-2 Simple DirectMedia Layer ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxml22.6.32.dfsg-2 GNOME XML library ii libxmu62:1.0.4-1 X11 miscellaneous utility library ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii xlibmesa-gl1:7.3+11 transitional package for Debian et ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime desmume recommends no packages. -- no debconf information
Bug#484450: Upstream reorganization of source packages
tag 484450 +pending thanks This source package will be removed shortly because of upstream reorganization of the code. As soon as the new zeroc-ice 3.3.0 source package gets into lenny I will request ftp-master to remove zeroc-ice-java. The new zeroc-ice 3.3.0 package which fixes this bug and also 478642 and 479246 was uploaded 11 days ago. Regards, Paco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459829:
tag 459829 +patch
thanks
The following patch fixes this bug. Please, fix this package as soon as
possible, I need it for zeroc-ice.
diff --git a/proguard-4.1/debian/rules b/proguard-4.1/debian/rules
index d1f189e..d4ba74f 100755
--- a/proguard-4.1/debian/rules
+++ b/proguard-4.1/debian/rules
@@ -19,8 +19,9 @@ build:
${JAVA_COMPILER} -d build/proguardtask -sourcepath src -cp ${ANTJAR} src
${JAR} cfm lib/proguard.jar proguard.manifest -C build/proguard proguard
${JAR} cfm lib/proguardgui.jar proguardgui.manifest -C build/proguardgui
+ ${JAR} cfm lib/ant-proguard.jar proguard.manifest -C build/proguardtask
cd src ${JAR} uf ../lib/proguardgui.jar proguard/gui/vtitle.gif progu
- cp lib/proguard.jar lib/ant-proguard.jar
+ cd src ${JAR} uf ../lib/ant-proguard.jar proguard/ant/task.properties
Regards,
Paco
Francisco Moya [EMAIL PROTECTED]
Bug#474169: Patch proposal
tags 474169 + patch
thanks
Attached to this email you will find a patch against mcpp-2.7-1 from
unstable to enable libmcpp. I tried to respect the original structure
of debian/rules although it would probably be wiser to go for a single
DESTDIR and dh_install files.
--
Francisco Moya Fernandez Computer Architecture and Networks Group
Assistant Professor
[EMAIL PROTECTED] School of Computer Science
Fax:(+34 926) 29 53 54 University of Castilla-La Mancha
Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
diff -Nru mcpp-2.7/debian/control mcpp-2.7-1.1/debian/control
--- mcpp-2.7/debian/control 2008-04-04 12:29:44.0 +0200
+++ mcpp-2.7-1.1/debian/control 2008-04-04 12:20:16.0 +0200
@@ -23,3 +23,34 @@
proprocessor or as a subroutine called from some other main program,
this package installs only a stand-alone program named 'mcpp' which
behaves independent from GCC.
+
+Package: libmcpp0
+Architecture: any
+Depends: ${shlibs:Depends}
+Description: Alternative C/C++ preprocessor (shared library)
+ C/C++ preprocessor expands macros and processes '#if', '#include' and
+ some other directives.
+ .
+ MCPP is an alternative C/C++ preprocessor with the highest
+ conformance, implementated by Kiyoshi Matsui. MCPP is especially
+ useful for debugging the source program which use complicated macros
+ and also useful for checking portability of the source. It supports
+ multiple standards: KR, ISO C90, ISO C99, and ISO C++98.
+ .
+ This package installs the shared library version of MCPP.
+
+Package: libmcpp0-dev
+Architecture: any
+Depends: libmcpp0
+Description: Alternative C/C++ preprocessor (development files)
+ C/C++ preprocessor expands macros and processes '#if', '#include' and
+ some other directives.
+ .
+ MCPP is an alternative C/C++ preprocessor with the highest
+ conformance, implementated by Kiyoshi Matsui. MCPP is especially
+ useful for debugging the source program which use complicated macros
+ and also useful for checking portability of the source. It supports
+ multiple standards: KR, ISO C90, ISO C99, and ISO C++98.
+ .
+ This package installs the development files for the library version
+ of MCPP.
diff -Nru mcpp-2.7/debian/rules mcpp-2.7-1.1/debian/rules
--- mcpp-2.7/debian/rules 2008-04-04 12:29:44.0 +0200
+++ mcpp-2.7-1.1/debian/rules 2008-04-04 12:25:05.0 +0200
@@ -17,21 +17,27 @@
INSTALL_PROGRAM += -s
endif
-config.status: configure
+bin/config.status: configure
dh_testdir
- CFLAGS=$(CFLAGS) ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
+ mkdir -p bin cd bin CFLAGS=$(CFLAGS) ../configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
+
+lib/config.status: configure
+ dh_testdir
+ mkdir -p lib cd lib CFLAGS=$(CFLAGS) ../configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --enable-mcpplib
build: build-stamp
-build-stamp: config.status
+build-stamp: bin/config.status lib/config.status
dh_testdir
- $(MAKE)
+ $(MAKE) -C bin
+ $(MAKE) -C lib
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp
+ rm -rf lib bin
[ ! -f Makefile ] || $(MAKE) distclean
dh_clean
@@ -41,10 +47,16 @@
dh_clean -k
dh_installdirs
- $(MAKE) install DESTDIR=$(CURDIR)/debian/mcpp
- rmdir $(CURDIR)/debian/mcpp/usr/lib
+ $(MAKE) -C bin install DESTDIR=$(CURDIR)/debian/mcpp
+ $(MAKE) -C lib install DESTDIR=$(CURDIR)/debian/libmcpp0-dev
+ mkdir -p $(CURDIR)/debian/libmcpp0-dev/usr/include
+ mkdir -p $(CURDIR)/debian/libmcpp0/usr/lib
+ cp src/mcpp_lib.h $(CURDIR)/debian/libmcpp0-dev/usr/include
+ mv $(CURDIR)/debian/libmcpp0-dev/usr/lib/*.so.* \
+ $(CURDIR)/debian/libmcpp0/usr/lib
# LICENSE is included in debian/copyright
rm -f $(CURDIR)/debian/mcpp/usr/share/doc/mcpp/LICENSE
+ rm -f $(CURDIR)/debian/libmcpp0-dev/usr/share/doc/mcpp/LICENSE
# Build architecture-independent files here.
diff -Nru mcpp-2.7/src/internal.H mcpp-2.7-1.1/src/internal.H
--- mcpp-2.7/src/internal.H 2008-03-11 17:04:07.0 +0100
+++ mcpp-2.7-1.1/src/internal.H 2008-04-04 10:58:37.0 +0200
@@ -526,7 +526,7 @@
/* Do the final commands*/
extern void print_heap( void);
/* Print blocks of heap memory */
-#if ! HOST_HAVE_STPCPY || HOST_COMPILER == GNUC
+#if ! HOST_HAVE_STPCPY
extern char * stpcpy( char * dest, const char * src);
/* Non-Standard library function*/
#endif
Bug#474169: Please, provide libmcpp as well
Package: mcpp Version: 2.7-1 Severity: wishlist Package zeroc-ice now depends on libmcpp. 36 binary packages are currently affected by this issue. Since it is not a functional misbehavior of your package I cannot raise the severity but please, note that this is blocking new upstream of 7 source packages and 36 binary packages. Best regards, F. Moya -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mcpp depends on: ii libc6 2.7-10 GNU C Library: Shared libraries mcpp recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463725: vlc: Please, enable python bindings
Hi,
Attached to this email you will find the patch against current debian package
in unstable.
--
Francisco Moya Fernandez Computer Architecture and Networks Group
Assistant Professor
[EMAIL PROTECTED] School of Computer Science
Fax:(+34 926) 29 53 54University of Castilla-La Mancha
Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
-Mensaje original-
De: Loïc Minier [mailto:[EMAIL PROTECTED]
Enviado el: mar 12/02/2008 17:21
Para: FRANCISCO MOYA FERNANDEZ; [EMAIL PROTECTED]
Asunto: Re: Bug#463725: vlc: Please, enable python bindings
Hi,
On Sat, Feb 02, 2008, FRANCISCO MOYA FERNANDEZ wrote:
Please, enable MediaControl python bindings. Attached to this report
you will find a diff which adds a patch from Fedora Core 8 to fix
compilation issues of the python extension when libtool libraries are
used.
Could you please attach a patch instead?
Thanks!
--
Loïc Minier
diff -Nru vlc-0.8.6.c/debian/changelog vlc-0.8.6.c+python/debian/changelog
--- vlc-0.8.6.c/debian/changelog 2008-02-12 18:22:14.0 +0100
+++ vlc-0.8.6.c+python/debian/changelog 2008-02-02 03:40:23.0 +0100
@@ -1,3 +1,15 @@
+vlc (0.8.6.c-6.2) unstable; urgency=low
+
+ * Fixed compliance with Python policy
+
+ -- Francisco Moya [EMAIL PROTECTED] Sat, 02 Feb 2008 03:40:22 +0100
+
+vlc (0.8.6.c-6.1) unstable; urgency=low
+
+ * Added support for python bindings (patch taken from Fedora)
+
+ -- Francisco Moya [EMAIL PROTECTED] Fri, 01 Feb 2008 22:54:34 +0100
+
vlc (0.8.6.c-6) unstable; urgency=high
[ Nico Golde ]
diff -Nru vlc-0.8.6.c/debian/control vlc-0.8.6.c+python/debian/control
--- vlc-0.8.6.c/debian/control 2008-02-12 18:22:14.0 +0100
+++ vlc-0.8.6.c+python/debian/control 2008-02-02 02:14:21.0 +0100
@@ -76,7 +76,8 @@
libsdl-image1.2-dev,
libnotify-dev,
libgtk2.0-dev,
- python-dev,
+ python-all-dev,
+ python-support,
libfaad-dev,
libjack-dev
Standards-Version: 3.7.3
@@ -366,3 +367,16 @@
DivX, MOV, WMV, QuickTime, mp3, Ogg/Vorbis files, DVDs, VCDs, and multimedia
streams from various network sources.
+Package: python-vlc
+Section: python
+Architecture: any
+Depends: ${shlibs:Depends}, ${python:Depends}
+Provides: ${python:Provides}
+Description: multimedia player and streamer library (Python bindings)
+ This package contains the binary module required by python
+ applications using VLC features.
+ .
+ VLC is the VideoLAN project's media player. It plays MPEG, MPEG2, MPEG4,
+ DivX, MOV, WMV, QuickTime, mp3, Ogg/Vorbis files, DVDs, VCDs, and multimedia
+ streams from various network sources.
+
diff -Nru vlc-0.8.6.c/debian/patches/400_python_fedora.diff vlc-0.8.6.c+python/debian/patches/400_python_fedora.diff
--- vlc-0.8.6.c/debian/patches/400_python_fedora.diff 1970-01-01 01:00:00.0 +0100
+++ vlc-0.8.6.c+python/debian/patches/400_python_fedora.diff 2008-02-02 02:59:14.0 +0100
@@ -0,0 +1,189 @@
+Index: vlc-0.8.6.c/bindings/mediacontrol-python/Makefile.am
+===
+--- vlc-0.8.6.c.orig/bindings/mediacontrol-python/Makefile.am 2008-02-02 02:56:12.0 +0100
vlc-0.8.6.c/bindings/mediacontrol-python/Makefile.am 2008-02-02 02:57:44.0 +0100
+@@ -3,6 +3,7 @@
+ ###
+
+ EXTRA_DIST = vlcglue.c vlcglue.h setup.py vlcwrapper.py
++PYTHON = python
+
+ if BUILD_PYTHON
+
+@@ -13,12 +14,12 @@
+ endif
+
+ all:
+- srcdir=$(srcdir) top_builddir=$(top_builddir) python $(srcdir)/setup.py build $(COMPILERARG) --build-base=$(top_builddir)/bindings/mediacontrol-python --build-temp=$(top_builddir)/bindings/mediacontrol-python
++ srcdir=$(srcdir) top_builddir=$(top_builddir) $(PYTHON) $(srcdir)/setup.py build $(COMPILERARG) --build-base=$(top_builddir)/bindings/mediacontrol-python --build-temp=$(top_builddir)/bindings/mediacontrol-python
+
+ # FIXME: python setup.py install does not have any option to install from a different build directory
+ # so this will not work in a separate builddir
+ install:
+- python $(srcdir)/setup.py install
++ $(PYTHON) $(srcdir)/setup.py install
+
+ clean:
+ $(RM) -rf build
+Index: vlc-0.8.6.c/bindings/mediacontrol-python/setup.py
+===
+--- vlc-0.8.6.c.orig/bindings/mediacontrol-python/setup.py 2008-02-02 02:53:12.0 +0100
vlc-0.8.6.c/bindings/mediacontrol-python/setup.py 2008-02-02 02:56:26.0 +0100
+@@ -13,6 +13,23 @@
+ top_builddir = os.path.join( '..', '..' )
+ os.environ['top_builddir'] = top_builddir
+
++# Determine the extra link args. Normally, vlc-config should take care
++# of this and return the right path values, from a development tree or
++# an installed version.
++libtool=False
++linkargs=[]
++d=os.path.join
Bug#446757: Found a simple workaround
tags 446757 = pending fixed thanks It seems that this bug is triggered by optimization flags on g++ 4.2.2-3. As a simple workaround I'm turning off optimizations on AMD64. It is not yet clear to me whether this is a compiler bug or an Ice bug. Regards, F. Moya
Bug#446757: More info requested
tags 446757 - unreproducible thanks I was able to reproduce this bug using icegridnode instead of icegridregistry. Regards, F. Moya -Mensaje original- De: FRANCISCO MOYA FERNANDEZ Enviado el: mié 17/10/2007 0:38 Para: [EMAIL PROTECTED]; [EMAIL PROTECTED] Asunto: More info requested tags 446757 = moreinfo unreproducible thanks Thank you for your bug report, unfortunately I was unable to reproduce it. I tested the given config file on an AMD64 X2 and on Pentium Dual Core without any problem. Please, verify that this was not a hardware problem (e.g. faulty memory). If possible provide a complete minimal example to exercise the bug. Regards, F. Moya -- Francisco Moya Fernandez Computer Architecture and Networks Group Assistant Professor [EMAIL PROTECTED] School of Computer Science Fax:(+34 926) 29 53 54University of Castilla-La Mancha Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
Bug#446757: More info requested
tags 446757 = moreinfo unreproducible thanks Thank you for your bug report, unfortunately I was unable to reproduce it. I tested the given config file on an AMD64 X2 and on Pentium Dual Core without any problem. Please, verify that this was not a hardware problem (e.g. faulty memory). If possible provide a complete minimal example to exercise the bug. Regards, F. Moya -- Francisco Moya Fernandez Computer Architecture and Networks Group Assistant Professor [EMAIL PROTECTED] School of Computer Science Fax:(+34 926) 29 53 54University of Castilla-La Mancha Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
Bug#445411: python-zeroc-ice: module is linked to libpython
tags 445411 + fixed pending thanks Thank you for your bug report. Please, note that it was actually two bug reports in one. It would be better if you send a separate report for each one in the future. I've sent a fixed release to my package sponsor and it will be available in a few days. In the meantime you may get it from my private repo: deb http://arco.inf-cr.uclm.es/~francisco.moya/debian ./ Regards, F. Moya -Mensaje original- De: Josselin Mouette [mailto:[EMAIL PROTECTED] Enviado el: vie 05/10/2007 18:09 Para: Debian Bug Tracking System Asunto: Bug#445411: python-zeroc-ice: module is linked to libpython Package: python-zeroc-ice Version: 3.2.1-1 Severity: wishlist Hi, this package depends on python2.4, because the IcePy.so module is linked to libpython. This is bad and completely unnecessary practice. Furthermore, it would be nice to switch to a multi-build system, so that the package is built for several python versions at once. Thanks.
Bug#444565: live-helper: lh_binary_debian-installer points to unexistent config
Package: live-helper Version: 1.0~a29-1 Severity: normal When including local debs lh_binary_debian-installer uses a piece of code that refers to ../config/ when it sould refer to config/ Regards, F. Moya -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages live-helper depends on: ii cdebootstrap 0.4.3 Bootstrap a Debian system ii debootstrap 1.0.3 Bootstrap a basic Debian system live-helper recommends no packages. -- no debconf information
Bug#444174: zeroc-ice-java: Add support for slice2java ant tasks
Package: zeroc-ice-java
Severity: wishlist
Original submitter: Mary Ellen Foster
Original subject: Slice2Java ant tasks in Debian/Ubuntu Ice packages?
[...]
I can't seem to find the Slice2Java* task for ant in these
packages -- are they included somewhere? These would be files called
things like Slice2JavaTask.class ...
I've recently become the Fedora maintainer of the Ice packages. I
don't know if anyone other than me is actually using them, of course,
but it's still fun. :) (I put the files into
/usr/share/Ice-%{version}/ant/, but I'm thinking of using a jar file
next time because bare .class files in the file system is a bit ugly).
Thanks,
MEF
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Bug#424074: python-zeroc-ice: Unable to import Ice on AMD64 (IcePy.so: undefined symbol: _ZN7IceUtil4Time12milliSecondsEl)
I still need to perform some more tests but definitely your bug should not be against this package but against zeroc-ice. $ echo _ZN7IceUtil4Time12milliSecondsEl | c++filt IceUtil::Time::milliSeconds(long) This is right, since sizeof(long)==8 in AMD64. $ nm --dynamic /usr/lib/libIceUtil.so.32 | grep milliSeconds | c++filt 000287f0 T IceUtil::Time::milliSeconds(long long) This is wrong, since an Int64 is a simple long in AMD64. I do not yet understand how zeroc-ice was compiled on AMD64. I recompiled zeroc-ice and everything worked as expected. More testing is needed but in the meantime I'm reassigning this bug to zeroc-ice. Regards, F. Moya winmail.dat
Bug#397958: scapy: Package does not conform to current python policy
Package: scapy Severity: important Package scapy provides a pure python module but it fails to conform to current python policy [1]. You may use the information contained in [2] to adapt your package. There is one more policy violation that linda and lintian reports: the scapy.1 manpage is not gzipped with maximum compression level. [1] http://lists.debian.org/debian-devel-announce/2006/06/msg9.html [2] http://wiki.debian.org/DebianPython/NewPolicy -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397958: Python policy compliance fixes
tag 397958 +patch
thanks
Attached to this email you will find a patch for scapy-1.0.4-1 to comply
with current python policy. It uses distutils and python-support.
Regards,
F. Moya
diff -Nru scapy-1.0.4.orig/debian/postrm scapy-1.0.4/debian/postrm
--- scapy-1.0.4.orig/debian/postrm 2006-11-10 18:36:07.0 +0100
+++ scapy-1.0.4/debian/postrm 1970-01-01 01:00:00.0 +0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-
-[ -f /usr/bin/scapy.pyc ] rm -f /usr/bin/scapy.pyc
-
-#DEBHELPER#
-
-exit 0
-
diff -Nru scapy-1.0.4.orig/debian/rules scapy-1.0.4/debian/rules
--- scapy-1.0.4.orig/debian/rules 2006-11-10 18:36:07.0 +0100
+++ scapy-1.0.4/debian/rules 2006-11-10 19:00:30.0 +0100
@@ -2,6 +2,8 @@
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
+PYVERS=$(shell pyversions -vr)
+
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
@@ -15,37 +17,42 @@
touch configure-stamp
build: configure-stamp build-stamp
-build-stamp:
+build-stamp: $(PYVERS:%=build-python%)
dh_testdir
# Add here commands to compile the package.
touch build-stamp
+build-python%:
+ python$* setup.py build
+ touch $@
clean:
dh_testdir
dh_testroot
- rm -f build-stamp configure-stamp
+ rm -f build-stamp configure-stamp build-python*
dh_clean
+ $(RM) scapy.1
+ $(RM) -r build
+
+install: pre-install $(PYVERS:%=install-python%)
-install: build
+pre-install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
+ echo -e #!/bin/sh\nexec /usr/bin/python /usr/share/python-support/python-scapy/scapy.py $(CURDIR)/debian/python-scapy/usr/bin/scapy
+ gzip -dc scapy.1.gz scapy.1
- # Add here commands to install the package into debian/ipcheck.
- #$(MAKE) install DESTDIR=$(CURDIR)/debian/ipcheck
-
- install scapy.py $(CURDIR)/debian/scapy/usr/bin/scapy.py
+install-python%:
+ python$* setup.py install --root $(CURDIR)/debian/python-scapy
# Build architecture-independent files here.
binary-indep: build install
dh_testdir
dh_testroot
+ dh_pysupport
dh_installdocs
dh_installman scapy.1.gz
- dh_link /usr/bin/scapy.py /usr/bin/scapy
- dh_link /usr/share/man/man1/scapy.1.gz /usr/share/man/man1/scapy.py.1.gz
- dh_link /usr/bin/scapy.py /usr/lib/site-python/scapy.py
dh_installchangelogs
dh_compress
dh_fixperms
@@ -53,6 +60,7 @@
dh_gencontrol
dh_md5sums
dh_builddeb
+
binary-arch: build install
# Nothing to do..
diff -Nru scapy-1.0.4.orig/setup.py scapy-1.0.4/setup.py
--- scapy-1.0.4.orig/setup.py 1970-01-01 01:00:00.0 +0100
+++ scapy-1.0.4/setup.py 2006-11-10 19:03:40.0 +0100
@@ -0,0 +1,14 @@
+from distutils.core import setup
+
+DESC = Packet generator/sniffer and network scanner.
+
+setup(name = 'scapy',
+ version = '1.0.4',
+ description = DESC,
+ author = 'Philippe Biondi',
+ author_email = '[EMAIL PROTECTED]',
+ url = 'http://www.secdev.org/projects/scapy/',
+ license = 'GPL v2 or later',
+ data_files = [('share/man/man1',['scapy.1'])],
+ py_modules = ['scapy']
+ )
signature.asc
Description: This is a digitally signed message part
Bug#355656:
tags 355656 +patch
thanks
File tclconfig/tcl.m4 has two extra quotes. Old versions of bash did not
catch the errors.
The following patch solves the problem.
--- rivet-0.5.0.orig/tclconfig/tcl.m4 2004-12-03 04:34:22.0 +0100
+++ rivet-0.5.0/tclconfig/tcl.m42006-10-22 02:35:30.0 +0200
@@ -773,7 +773,7 @@
# results, and the version is kept in special file).
if test -r /etc/.relid -a X`uname -n` = X`uname -s` ; then
- system=MP-RAS-`awk '{print $3}' /etc/.relid'`
+ system=MP-RAS-`awk '{print $3}' /etc/.relid`
fi
if test `uname -s` = AIX ; then
system=AIX-`uname -v`.`uname -r`
@@ -2160,7 +2160,7 @@
# results, and the version is kept in special file).
if test -r /etc/.relid -a X`uname -n` = X`uname -s` ; then
- system=MP-RAS-`awk '{print $3}' /etc/.relid'`
+ system=MP-RAS-`awk '{print $3}' /etc/.relid`
fi
if test `uname -s` = AIX ; then
system=AIX-`uname -v`.`uname -r`
Regards,
F. Moya
--
Francisco Moya Fernandez Computer Architecture and Networks Group
Assistant Professor
[EMAIL PROTECTED] School of Computer Science
Fax:(+34 926) 29 53 54University of Castilla-La Mancha
Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
signature.asc
Description: This is a digitally signed message part
Bug#394588: rivet: TCL_PACKAGE_PATH may contain more than one directory
Package: rivet
Version: 0.5.0-3
Severity: normal
Tags: patch
The build system in this package relies on TCL_PACKAGE_PATH being
a single directory but it may contain more than one. For example,
package tcl8.4-dev defines two (/usr/lib /usr/share).
The easiest way around this bug is to just take the first directory
before substituting the variable:
diff -Nru rivet-0.5.0.orig/configure.ac rivet-0.5.0/configure.ac
--- rivet-0.5.0.orig/configure.ac 2005-03-24 11:29:15.0 +0100
+++ rivet-0.5.0/configure.ac2006-10-22 02:01:49.0 +0200
@@ -268,6 +268,7 @@
AC_DEFINE_UNQUOTED(NAMEOFEXECUTABLE,${TCLSH_PROG},[The path to a working
tclsh executable])
# We need to use the package path for the installation procedure.
+TCL_PACKAGE_PATH=${TCL_PACKAGE_PATH/ */}
AC_SUBST(TCL_PACKAGE_PATH)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325206: rivet: FTBFS - invalid lvalue in assignment
tags 325206 +patch
thanks
The following patch fixes the gcc-4.x compilation errors. This patch,
along with the one at #394588 and the one at #355656 were used to
successfully build a rivet package in sid.
diff -Nru rivet-0.5.0.orig/src/rivetCore.c rivet-0.5.0/src/rivetCore.c
--- rivet-0.5.0.orig/src/rivetCore.c2004-12-03 03:17:11.0 +0100
+++ rivet-0.5.0/src/rivetCore.c 2006-10-22 01:07:25.0 +0200
@@ -640,7 +640,7 @@
if (TclWeb_UploadChannel(varname, chan, globals-req) != TCL_OK) {
return TCL_ERROR;
}
- (CONST84 char *)channelname = Tcl_GetChannelName(chan);
+ channelname = (char*)Tcl_GetChannelName(chan);
Tcl_SetStringObj(result, channelname, -1);
break;
}
diff -Nru rivet-0.5.0.orig/src/TclWebapache.c rivet-0.5.0/src/TclWebapache.c
--- rivet-0.5.0.orig/src/TclWebapache.c 2004-12-03 03:17:10.0 +0100
+++ rivet-0.5.0/src/TclWebapache.c 2006-10-22 01:08:19.0 +0200
@@ -660,10 +660,10 @@
TclWeb_InitEnvVars( req );
/* Check to see if it's a header variable first. */
-(const char *)val = ap_table_get( req-req-headers_in, key );
+val = (char*)ap_table_get( req-req-headers_in, key );
if( !val ) {
- (const char *)val = ap_table_get( req-req-subprocess_env, key );
+ val = (char*)ap_table_get( req-req-subprocess_env, key );
}
return val;
At the very least you should also create a debian/compat, add a
dh_installdirs to the install target, and add etc/apache/conf.d to your
dirs file (or mkdir -p just before copying the rivet.conf).
Regards,
F. Moya
--
Francisco Moya Fernandez Computer Architecture and Networks Group
Assistant Professor
[EMAIL PROTECTED] School of Computer Science
Fax:(+34 926) 29 53 54University of Castilla-La Mancha
Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394023: python-zeroc-ice: Should not depend on python2.3
The dependency is set by ${shlibs:Depends} because IcePy.so was indeed
compiled using libpython2.3.so when multiple python versions are
installed. A pbuilder build would not be affected. debian/rules should
be modified by appending a PYTHON_VERSION=$(shell pyversions -d) to the
DEB_MAKE_INVOKE variable.
A new upstream version with a fixed rules is being built using pbuilder
and will be uploaded soon.
On Wed, 2006-10-18 at 17:36 -0500, Luis Rodrigo Gallardo Cruz wrote:
Package: python-zeroc-ice
Version: 3.1.0-3
Severity: normal
This package depends on python2.3, but does not provide files compiled
for it. Either one of thos thing needs to change. Since the package is
not in sarge, and thus is unlikely anyone depends on its supporting
2.3, I recommend the dependency is dropped.
This bug might be a violation of the new python policy. If so, it is a
serious bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392979: java.io.IOException: No such file or directory
Please, provide information on your build information and package versions. The interesting lines are just above of what you sent. Package zeroc-ice-java 3.1.0-4 was supposed to fix just that. Regards, Paco On Sat, 2006-10-14 at 16:06 +0200, Julien Louis wrote: Package: zeroc-ice-java Severity: serious Justification: no longer builds from source hi, your package failed to build from source, from my build log i get the following error : BUILD FAILED /tmp/buildd/zeroc-ice-java-3.1.0/build.xml:66: Execute failed: java.io.IOException: java.io.IOException: No such file or directory A Build-Depends seems to be missing but i don't really know which is missing. Cheers -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388472: Fixed installation path
Next upload will fix this bug. On AMD64 the package was being installed in /usr/lib64 zeroc-icee (1.1.0-4) unstable; urgency=low * Fixed intallation directory on AMD64 (Closes: #388472). -- Francisco Moya [EMAIL PROTECTED] Wed, 20 Sep 2006 20:12:04 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382322: Patch
I sent the fixed package (along with some upstream patches) to my current package sponsor two days ago. I cannot sign them by myself. I sicerely hope you didn't actually issue an NMU as stated in the changelog. Regards, F. Moya On Sun, 2006-08-13 at 18:02 -0500, Luis Rodrigo Gallardo Cruz wrote: Attached -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373413: diff for 3.0.1-3.1 NMU
Thanks, F. Moya -Mensaje original- De: Pierre HABOUZIT [mailto:[EMAIL PROTECTED] Enviado el: dom 02/07/2006 0:11 Para: [EMAIL PROTECTED] Asunto: Bug#373413: diff for 3.0.1-3.1 NMU Hi, Attached is the diff for my zeroc-ice-python 3.0.1-3.1 NMU. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org winmail.dat
Bug#360235: zeroc-ice: ftbfs [sparc] [Admin.cpp] Segmentation fault
Would you be so kind to send me the whole build log? I do not have a sparc64 but a former user reported a missing include string.h in src/icecpp/prefix.c as a possible cause of problems in 64 bit architectures. I don't think so because icecpp just used strlen. Besides, ZeroC distributes fully working binaries for sparc64 and amd64 without source modifications. But just in case, would it be possible to try an #include string.h in src/icecpp/prefix.c ? Thanks in advance, F. Moya El vie, 31-03-2006 a las 06:14 -0800, Blars Blarson escribió: Package: zeroc-ice Version: 3.0.1-2 Severity: important Justification: fails to build from source zeroc-ice failed to build on a sparc buildd, duplicated on my sparc pbuilder. making all in IceGrid make[3]: Entering directory `/build/buildd/zeroc-ice-3.0.1/src/IceGrid' rm -f ../../include/IceGrid/Admin.h Admin.cpp ../../bin/slice2cpp --checksum --ice --include-dir IceGrid --dll-export ICE_GRID_API -I../../slice -I.. ../../slice/IceGrid/Admin.ice make[3]: *** [Admin.cpp] Segmentation fault make[3]: *** Deleting file `Admin.cpp' make[3]: Leaving directory `/build/buildd/zeroc-ice-3.0.1/src/IceGrid' make[2]: *** [all] Error 1
Bug#360316: zeroc-icee: FTBFS: #error IceE version mismatch!
Please, be patient. FYI IceE 1.1.0 was already uploaded to master on 29-03-2006. El sáb, 01-04-2006 a las 09:57 +0200, Andreas Jochens escribió: Package: zeroc-icee Version: 1.0.0-3 Severity: serious When building 'zeroc-icee' on unstable, I get the following error: rm -f ../../include/IceE/RouterF.h RouterF.cpp slice2cppe --ice --include-dir IceE --dll-export ICE_API -I../../slice ../../slice/IceE/RouterF.ice mv RouterF.h ../../include/IceE c++ -c -I.. -I../../include -DICE_API_EXPORTS -m32 -ftemplate-depth-128 -Wall -D_REENTRANT -fPIC -g BasicStream.cpp In file included from ../IceE/Instance.h:16, from BasicStream.cpp:11: ../../include/IceE/LoggerF.h:27:9: error: #error IceE version mismatch! In file included from ../../include/IceE/LocalException.h:14, from BasicStream.cpp:14: ../../include/IceE/Identity.h:27:9: error: #error IceE version mismatch! In file included from ../../include/IceE/LocalException.h:15, from BasicStream.cpp:14: ../../include/IceE/BuiltinSequences.h:28:9: error: #error IceE version mismatch! make[3]: *** [BasicStream.o] Error 1 make[3]: Leaving directory `/zeroc-icee-1.0.0/src/IceE' Regards Andreas Jochens
Bug#358488: FTBFS (alpha): #error unsupported operating system or platform
Hi Falk, I'm reluctant to apply changes that should be applied upstream. Also note that Alpha is not an officially supported platform for ZeroC Ice. Therefore there may be more problems than just icecpp not compiling. Your suggestion requires config.h to include limits.h which is a bad thing IMO. icecpp is just a renamed cccp from GNU gcc 2.8 and the right way to handle this issue is through autoconf (as GNU version does). ZeroC sadly removed autoconf from their build system and tweaked hand-edited macros to deal with multiple archs. Besides it is unlikely that ZeroC will accept your patch (I forwarded it to them just in case) because there are plenty of limits.h out there without WCHAR_MAX defined. OTH GNU gcc no longer uses WCHAR in cpp. Therefore I don't think it would stay there for long. I do not have an Alpha system, would you be so kind to test if the following simpler patch works for you? --- src/icecpp/config.h~2006-03-20 00:42:36.0 + +++ src/icecpp/config.h 2006-03-20 00:47:51.0 + @@ -63,7 +63,7 @@ #if defined(_WIN32) # define WCHAR_TYPE_SIZE 2 #elif (defined(__linux) || defined(__FreeBSD__)) \ - (defined(__i386) || defined(__x86_64) || defined(__sparc)) || \ + (defined(__i386) || defined(__x86_64) || defined(__sparc) || \ + defined(__mips) || defined(__alpha__)) || \ defined (__sun) || defined(__hpux) || defined(__APPLE__) || \ defined(_AIX) || defined(__osf1__) # define WCHAR_TYPE_SIZE 4 El mié, 22-03-2006 a las 22:57 +0100, Falk Hueffner escribió: Package: zeroc-ice Severity: important Justification: fails to build from source zeroc-ice fails to build on Alpha: [...] make[3]: Entering directory `/tmp/buildd/zeroc-ice-3.0.1/src/icecpp' cc -c -I../../include -O2 -I. -DPREFIX=\\ cccp.c In file included from cccp.c:21: config.h:80:5: error: #error unsupported operating system or platform make[3]: *** [cccp.o] Error 1 make[3]: Leaving directory `/tmp/buildd/zeroc-ice-3.0.1/src/icecpp' Full log at; http://buildd.debian.org/fetch.php?pkg=zeroc-icever=3.0.1-1arch=alphastamp=1142961876file=logas=raw I'd suggest to replace the logic in config.h with something like #if WCHAR_MAX == 32767 || WCHAR_MAX == 65536 # define WCHAR_TYPE_SIZE 2 #elif WCHAR_MAX == 2147483647 || WCHAR_MAX == 4294967295 # define WCHAR_TYPE_SIZE 4 #else # error unsupported operating system or platform #endif Falk -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc4-dirty Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Bug#357890: Please support mips
IceE 1.1.0 is already packaged but I'm waiting for my package sponsor to upload those to master. If you can't wait get them at deb http://personales.ya.com/fmoya ./ deb-src http://personales.ya.com/fmoya ./ Regards, F. Moya El lun, 20-03-2006 a las 01:20 +, Martin Michlmayr escribió: package: zeroc-icee-translators Version: 1.0.0-3 Severity: wishlist Tags: patch Please support the MIPS platform. Automatic build of zeroc-icee-translators_1.0.0-3 on bigsur by sbuild/mips 1.106 ... make[3]: Entering directory `/build/tbm/zeroc-icee-translators-1.0.0/src/IceUtil' c++ -c -I../../include -DICE_UTIL_API_EXPORTS -I.. -ftemplate-depth-128 -Wall -D_REENTRANT -O3 -DNDEBUG Base64.cpp In file included from ../../include/IceUtil/Base64.h:13, from Base64.cpp:10: ../../include/IceUtil/Config.h:26:5: error: #error Unknown architecture make[3]: *** [Base64.o] Error 1 The following patch is against 1.0.0. I see that 1.1.0 is out already but you can see from the patch below what needs to be done. --- ./include/IceUtil/Config.h~ 2005-08-16 16:46:12.0 + +++ ./include/IceUtil/Config.h2006-03-20 01:06:27.0 + @@ -17,10 +17,10 @@ // of Itanium (IA64) and MIPS. // #if defined(__i386) || defined(_M_IX86) || defined (__x86_64) || \ -defined(__alpha__) +defined(__alpha__) || defined(__MIPSEL__) # define ICE_LITTLE_ENDIAN #elif defined(__sparc) || defined(__sparc__) || defined(__hppa) || \ - defined(__ppc__) || defined(_ARCH_COM) + defined(__ppc__) || defined(__MIPSEB__) || defined(_ARCH_COM) # define ICE_BIG_ENDIAN #else # error Unknown architecture --- ./src/icecpp/config.h~2006-03-20 00:42:36.0 + +++ ./src/icecpp/config.h 2006-03-20 00:47:51.0 + @@ -63,7 +63,7 @@ #if defined(_WIN32) # define WCHAR_TYPE_SIZE 2 #elif (defined(__linux) || defined(__FreeBSD__)) \ - (defined(__i386) || defined(__x86_64) || defined(__sparc)) || \ + (defined(__i386) || defined(__x86_64) || defined(__sparc) || defined(__mips)) || \ defined (__sun) || defined(__hpux) || defined(__APPLE__) || \ defined(_AIX) || defined(__osf1__) # define WCHAR_TYPE_SIZE 4 -- Francisco Moya Fernandez Computer Architecture and Networks Group Assistant Professor [EMAIL PROTECTED] School of Computer Science Fax:(+34 926) 29 53 54University of Castilla-La Mancha Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/
Bug#343827: ITP: zeroc-ice -- ZeroC Internet Communications Engine
Package: wnpp Severity: wishlist Owner: Francisco Moya [EMAIL PROTECTED] * Package name: zeroc-ice Version : 3.0.0 Upstream Author : ZeroC, Inc. * URL : http://www.zeroc.com/ * License : GPL Description : ZeroC Internet Communications Engine Ice is a CORBAish middleware. It implements a few interesting services for developers of robust distributed software. It includes mappings for C++, Python, Java, PHP, C# and Visual Basic. It also includes a version for embedded devices (J2ME and C++). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (101, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-marvin Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
