Bug#797924: nmu: boost1.58_1.58.0+dfsg-3
Hi Julien. Thanks for the quick response. My apologies for it was actually a problem with my machine. I have re-done it to confirm with sbuild and it worked fine. This can be closed. Really sorry for the noise! Thank you.
Bug#783655: www.debian.org: addition of ppc64el page to ports
Hi Paul. Thank you for your input. paul.is.w...@gmail.com wrote on 01/05/2015 03:17:49: > For most other ports, the port names for a "family" of ports all > redirect to a single page, for example amrhf/arm64/armel all redirect > to the arm page. I wonder if that would be appropriate for > powerpc/ppc64el/powerpcspe? I can try and integrate what I have sent with powerpc page. I am not sure about powerpcspe though, because it already has a whole page of its own. Also it is an unofficial port (not that this really matters here). > I would recommend not hard-coding the list of porterbox names, that > sort of information is liable to get out of date. Indeed, there is > also plummer.d.o now in addition to pastel.d.n. How would you suggest it to be done? A contact point maybe? Thanks and regards. -- Fernando Seiti Furusato Software Engineer IBM Brazil - Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769959: FTBFS on arm64 and ppc64el
user debian-powe...@lists.debian.org usertags 769959 + ppc64el thanks This is also a problem on ppc64el, probably for the same reason. I tested Edmund's suggestion and it worked. But also, on different runs, declaring hash as unsigned or as volatile -- instead of casting it -- also worked. Anyway, I did not produce a patch because I am not entirely certain of this, as I am not an expert on the subject. Regards. Fernando
Bug#768236: ffcall: FTBFS on ppc64el: No rule to make target 'avcall-powerpc64le.lo'
Hello Christoph. Thanks for the very quick response! > Have you tested the patched ffcall? In my experience upstream might seem > inactive but these folks do actually respond to emails pretty quickly. Yes, (you mean this patch?). I have tested it and the package builds through to the end. I also downloaded the src from upstream via cvs and it seems pretty much the same. > I'm going to do that anyway for the next upload so no worries there! Cool, thank you =) > I guess it's too late for jessie now? So I guess it should go to > experimental for now? Yes, I guess you are right. Regards. Fernando
Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic
Hi Felipe. Thank you for your very quick response. > What does "usage of altivec is not implemented"? In supecollider, or > in the compiler? In supercollider. > In any case, perhaps the solution is to disable supernova in ppc64el > as well instead of adding custom flags. Simply disabling it for ppc64el did not do the work (completely), but you can test it if you want =) I think Konstantinos would be able to give you more accurate answers to your questions regarding altivec and simd in general. He knows a lot of that stuff. He is cc'ed (markos). Thanks!
Bug#764353:
Hello Johan. I have applied one of the patches gathered from the link you sent. That allowed the package to build successfully. The other one does not seem to work. The debdiff is attached to this msg. Regards. Fernando ppc64el.debdiff Description: Binary data
Bug#730885: Debian BTS Bug #730885
Hello John, I just stumbled onto the same error on ppc64el, and giving it a little search, I could find this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743059 Basically it says the problem is not in globus-common, since it is has been 'multiarched'. It would certainly be easier if we could use pkg-config as suggested in the aforementioned bug report, but since we can't, I sent a patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763409. Just thought it might be useful to you as well. Regards. Fernando
Bug#760302: libkqueue: fix ppc64el (and probably other 64bit) port(s)
Hello Mark. Ok, thanks for the update!
Bug#756428: [Pkg-xfce-devel] Bug#756428: xfconf: 4.10.0-2
Hello. Here is what I got so far with the package. The reason autoreconf is not working seems to be that the m4 macros are not being shipped with the package nor they are being included in Makefile.am or configure.ac After 'borrowing' the m4macros directory from xfce4-dev-tools and including the line ACLOCAL_AMFLAGS = -I m4macros within Makefile.am, the autoreconf command was able to run completely. After that, the build stopped with another error: make[4]: Entering directory `/home/xfconf/xfconf-4.10.0/tests/set-properties' Makefile:925: *** unterminated variable reference. Stop. make[4]: Leaving directory `/home/xfconf/xfconf-4.10.0/tests/set-properties' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/xfconf/xfconf-4.10.0/tests' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/xfconf/xfconf-4.10.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/xfconf/xfconf-4.10.0' dh_auto_build: make -j1 returned exit code 2 make: *** [binary] Error 2 Which is being caused, for a reason I don't know, by the command below, found at line 16, into tests/Makefile.inc check_SCRIPTS = $(addsuffix .sh,$(check_PROGRAMS)) Removing such line will allow the package to build, so maybe there could be another way to do what the command was intended to? This was as far as I could get for now. Thanks and regards. Fernando
Bug#756315: qtdeclarative-opensource-src: ftbfs on ppc64el -- missing arch in symbols files
Hello Lisandro. Thanks for the quick response. Apologies for the inconvenience, I actually saw that you worked according to debian-ports logs after I had already submitted the bug report, in archived bugs. Anyway the log for that can be found at the following url: http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/qtdeclarative-opensource-src_5.3.1-3_ppc64el.build Thanks for looking into this. Fernando
Bug#749530: libotf: use dh-autoreconf to build on new architectures
Hello Harshula. Yes, the patch I sent does exactly that, actually. But as long as your package builds and works successfully on our side, we will be glad =) Thank you! Fernando
Bug#753360: gsl: please use autoreconf to fix ftbfs on new archs
Hello Dirk. Thank you very much for accepting the patch. That was actually pretty quick. > Thank you so much for the concise patch which I just applied -- really > appreciate it. And sorry for the delay but I was out of town for two > conferences, but the updated package is now on its way to Debian unstable. > > [ And while I was at it, I finally added dpkg-buildflags call for CFLAGS and > LDFLAGS. What I once tried but failed to set up was the support for > multiarch. In case you know how to ... I'd appreciate a tip to. ] That is really great. Multiarch would be ideal indeed. Unfortunately I do not have the knowledge to help you at this point. I might learn something along the process of porting packages. In that case I may get in touch =) Thanks! Fernando.
Bug#752774: bino: [ftbfs] please include libharbuzz-dev as build-dep
Hello Daniel. You are right about that. My apologies for any inconvenience. Thanks! Fernando
