Bug#909778: libsdl2-dev: SDL_config.h no longer in cflags provided by pkg-config/sdl2-config
Hi, Em dom, 30 de set de 2018 às 16:57, Simon McVittie escreveu: > > For the short term, I'm preparing a NMU that reverts the multiarch change > and adds an autopkgtest that confirms that the package is usable, because > libsdl2-dev is currently unusable, and that's a considerably worse bug > than not being multiarch-friendly. For the record: I spoke to Simon and acked the NMU with no delay, to avoid affecting more packages. Thanks Simon for fixing this! -- Manuel A. Fernandez Montecelo
Bug#906429: systemd: Please raise timeout for tests (for riscv64)
Em sáb, 29 de set de 2018 às 01:32, Manuel A. Fernandez Montecelo escreveu: > > Submitted merge request: > https://salsa.debian.org/systemd-team/systemd/merge_requests/17 > > Not tested, but will do during the weekend and will report back. I have modified it slightly from the 1st version that I submitted as Merge Request, and it works fine and passes all the tests when building the package in 3 porterboxes: amd64, ppc64el and s390x. So please tell me if you're happy with it in its current form, or prefer to have it in other way. If you want to change it slightly yourself I'm happy that you do it without consultation -- I'm more concerned with getting the issue fixed than authorship :) Cheers. -- Manuel A. Fernandez Montecelo
Bug#906429: systemd: Please raise timeout for tests (for riscv64)
Hi, 2018-09-04 22:44 GMT+02:00 Michael Biebl : > On Fri, 17 Aug 2018 23:07:39 +0200 "Manuel A. Fernandez Montecelo" > wrote: > >> So perhaps debian/rules should be changed to use "meson test" instead, >> as Meson upstream recommended, and so we can pass on the "-t 10" for >> riscv64. > > I would prefer this approach > > Ideally this would be split into two commits: > 1/ switching the existing ninja test to meson test > 2/ adding the multiplier (for riscv64 alone or generally) > > Would be awesome if you can create a MR on salsa for that. Submitted merge request: https://salsa.debian.org/systemd-team/systemd/merge_requests/17 Not tested, but will do during the weekend and will report back. Cheers. -- Manuel A. Fernandez Montecelo
Bug#907153: qtdeclarative-opensource-src: Please update symbols for riscv64
Source: qtdeclarative-opensource-src Version: 5.10.1-4 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, Please update symbols for riscv64, the diff is a single line: == dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libqt5qml5/DEBIAN/symbols doesn't match completely debian/libqt5qml5.symbols --- debian/libqt5qml5.symbols (libqt5qml5_5.11.1-4_riscv64) +++ dpkg-gensymbols1TPFdR 2018-08-24 02:30:12.216039000 + @@ -2630,7 +2630,7 @@ _ZNK3QV45Value16toQStringNoThrowEv@Qt_5_PRIVATE_API 5.2.0~beta1 1 _ZNK3QV45Value8toUInt16Ev@Qt_5_PRIVATE_API 5.2.0~beta1 1 _ZNK3QV45Value9sameValueES0_@Qt_5_PRIVATE_API 5.2.0~beta1 1 - (arch=!amd64 !arm64 !mips64el !ppc64el !sparc64)_ZNK3QV45Value9toIntegerEv@Qt_5_PRIVATE_API 5.11.1 1 +#MISSING: 5.11.1-4# (arch=!amd64 !arm64 !mips64el !ppc64el !sparc64)_ZNK3QV45Value9toIntegerEv@Qt_5_PRIVATE_API 5.11.1 1 _ZNK3QV45Value9toQStringEv@Qt_5_PRIVATE_API 5.2.0~beta1 1 _ZNK3QV46Object11getPropertyEjPNS_8PropertyEPNS_18PropertyAttributesE@Qt_5_PRIVATE_API 5.6.0~beta 1 _ZNK3QV46Object11hasPropertyEPNS_6StringE@Qt_5_PRIVATE_API 5.4.0 1 == Thanks and cheers. -- Manuel A. Fernandez Montecelo
Bug#906429: systemd: Please raise timeout for tests (for riscv64)
Hi again, 2018-08-17 16:24 Manuel A. Fernandez Montecelo: [...] To try to address it, I first tried to increase the timeout only for the riscv64 architecture, with this recipe in debian/rules (the lines added and commented out): +++ systemd-239/debian/rules2018-08-16 17:02:43.0 +0200 @@ -5,6 +5,12 @@ export LC_ALL = C.UTF-8 +#include /usr/share/dpkg/architecture.mk +# +#ifeq ($(DEB_HOST_ARCH),riscv64) +#TEST_TIMEOUT_MULTIPLIER = "-t 10" +#endif + include /usr/share/dpkg/default.mk ifeq ($(DEB_VENDOR),Ubuntu) @@ -282,6 +288,8 @@ ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS))) echo "01234567890123456789012345678901" > build-deb/machine-id # some tests hang under fakeroot, so disable fakeroot +# env -u LD_PRELOAD SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id ninja $(TEST_TIMEOUT_MULTIPLIER) -C build-deb test || ( \ +# env -u LD_PRELOAD SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id ninja -C build-deb test || ( \ cat build-deb/meson-logs/testlog.txt; \ exit 1) However, I believe that this would have worked if invoking "meson test" directly, but not when invoking "ninja", because it doesn't pass the -t argument down to "meson test", and there doesn't seem to be any other way to achieve this. There's an open issue about this upstream, but it doesn't seem like it's to be implemented any time soon: https://github.com/mesonbuild/meson/issues/2037 (An environment variable would be a possible solution, I left a comment there). In that bug report, a devel said: "ninja test just calls meson test, so they should definitely switch to meson test if they can." And they are not happy with using env variables to change the default timeouts. So perhaps debian/rules should be changed to use "meson test" instead, as Meson upstream recommended, and so we can pass on the "-t 10" for riscv64. However, as I said, I don't have experience with meson/ninja, so I am unaware of possible problems or drawbacks. Cheers. -- Manuel A. Fernandez Montecelo
Bug#884750: happy: stage1 build profile FTBFS
2018-08-17 17:28 GMT+02:00 John Paul Adrian Glaubitz : > Hi Manuel! > > The changelog entry in your NMU is a tad misleading as the changes are not > specific to riscv64. Yeah it's true, I was attaching what I knew at the time and with the message that I put in the changelog, but the problem is completely generic. -- Manuel A. Fernandez Montecelo
Bug#906437: haskell-vector: FTBFS in riscv64, tests failing due to timeout
Source: haskell-vector Version: 0.12.0.1-5 Severity: normal User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, The package fails to build in riscv64 due to timeout of the test suite: https://buildd.debian.org/status/fetch.php?pkg=haskell-vector=riscv64=0.12.0.1-5=1532612044=0 If possible, please consider to print output of progress, in which case the buildd would not kill the process and hopefully it would finish successfully. Thanks and cheers. -- Manuel A. Fernandez Montecelo
Bug#884750: happy: stage1 build profile FTBFS
Source: happy Version: 1.19.9-4 Followup-For: Bug #884750 User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, As Adrian said, this was still failing recently when bootstrapping riscv64. We were working on it in parallel by mistake, and I attach the patch that I got, basically the same. I reported the problem to src:alex in: https://bugs.debian.org/906434 Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru happy-1.19.9/debian/changelog happy-1.19.9/debian/changelog --- happy-1.19.9/debian/changelog 2018-07-14 20:20:35.0 +0200 +++ happy-1.19.9/debian/changelog 2018-07-24 23:07:48.0 +0200 @@ -1,3 +1,10 @@ +happy (1.19.9-4~0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * Bootstrap for riscv64 + + -- Manuel A. Fernandez Montecelo Tue, 24 Jul 2018 23:07:48 +0200 + happy (1.19.9-4) unstable; urgency=medium * Set Rules-Requires-Root to no. diff -Nru happy-1.19.9/debian/rules happy-1.19.9/debian/rules --- happy-1.19.9/debian/rules 2018-04-09 21:06:48.0 +0200 +++ happy-1.19.9/debian/rules 2018-07-24 23:07:48.0 +0200 @@ -17,7 +17,7 @@ DEB_SETUP_GHC_CONFIGURE_ARGS += --with-happy=/bin/true cleanbuilddir/happy:: - cp -a dist/build/happy/happy-tmp/*.hs src/ +# cp -a dist/build/happy/happy-tmp/*.hs src/ endif clean::
Bug#906434: alex: Changes needed to bootstrap? (riscv64)
Source: alex Version: 3.2.4-3 Severity: minor Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, When bootstrapping Haskell for riscv64 a few weeks ago I had to change this package. I don't have any specific knowledge of the Haskell ecosystem. The stage1 profile is useful, but still I had to modify the package to be able to build it the first time, patch attached. Basically, the modification was to just comment out this line: == cleanbuilddir/alex:: - cp -a dist/build/alex/alex-tmp/*.hs src/ +# cp -a dist/build/alex/alex-tmp/*.hs src/ == I don't know how to get those files and how people bootstrapping are supposed to modify the package in such a way that this works automatically. After the initial package built, possibly non-functional, it was immediately rebuilt cleanly in the buildds [1] (all build-deps were satisfied, and thus no need for using build profiles), and everything seems to be fine since then. [1] https://buildd.debian.org/status/fetch.php?pkg=alex=riscv64=3.2.4-3=1532512437=0 So I send this bug report in the case that the instructions need to be updated, or explained for future porters, etc. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru alex-3.2.4/debian/changelog alex-3.2.4/debian/changelog --- alex-3.2.4/debian/changelog 2018-04-12 20:40:32.0 +0200 +++ alex-3.2.4/debian/changelog 2018-07-24 22:53:25.0 +0200 @@ -1,3 +1,10 @@ +alex (3.2.4-3~0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * Bootstrap riscv64 + + -- Manuel A. Fernandez Montecelo Tue, 24 Jul 2018 22:53:25 +0200 + alex (3.2.4-3) unstable; urgency=medium * Use Distribution.Version instead. diff -Nru alex-3.2.4/debian/rules alex-3.2.4/debian/rules --- alex-3.2.4/debian/rules 2018-04-09 21:05:35.0 +0200 +++ alex-3.2.4/debian/rules 2018-07-24 22:53:25.0 +0200 @@ -18,7 +18,7 @@ DEB_SETUP_GHC_CONFIGURE_ARGS := --with-alex=/bin/true cleanbuilddir/alex:: - cp -a dist/build/alex/alex-tmp/*.hs src/ +# cp -a dist/build/alex/alex-tmp/*.hs src/ endif clean::
Bug#906429: systemd: Please raise timeout for tests (for riscv64)
Source: systemd
Version: 239-7
Severity: normal
Tags: upstream patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hi,
This package fails to build in riscv64 due to timeout of the tests (it varies,
but it's often around 5 test cases of the current ~300).
systemd is one of the two remaining packages left from the base set that we have
to patch and ship from "unreleased" instead of "unstable", and possibly the only
remaining one that makes impossible to use "debootstrap" at the moment, so it
would be very nice if this could be sorted out soonish.
Admittedly, this is a problem specially in this architecture due to having
buildds using qemu-system at the moment. However, it's not the only one with
buildds running in qemu (although the others use qemu-user, AFAIK), or with slow
hardware or potentially with systems under load for other reasons, so it could
become a problem for other arches in the future also due to changes upstream (if
the tests start to take more time).
In my opinion, the fact that the buildds are slow by itself shouldn't be a
reason to fail tests, unless the times are truly disproportionate or disruptive
(e.g. taking hours, or more time than the build itself). This is clearly not
the case, waiting 300s instead of 30s is still a very small % of the total time
to build, probably less than 1%.
To try to address it, I first tried to increase the timeout only for the riscv64
architecture, with this recipe in debian/rules (the lines added and commented
out):
+++ systemd-239/debian/rules2018-08-16 17:02:43.0 +0200
@@ -5,6 +5,12 @@
export LC_ALL = C.UTF-8
+#include /usr/share/dpkg/architecture.mk
+#
+#ifeq ($(DEB_HOST_ARCH),riscv64)
+#TEST_TIMEOUT_MULTIPLIER = "-t 10"
+#endif
+
include /usr/share/dpkg/default.mk
ifeq ($(DEB_VENDOR),Ubuntu)
@@ -282,6 +288,8 @@
ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
echo "01234567890123456789012345678901" > build-deb/machine-id
# some tests hang under fakeroot, so disable fakeroot
+# env -u LD_PRELOAD
SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id ninja
$(TEST_TIMEOUT_MULTIPLIER) -C build-deb test || ( \
+#
env -u LD_PRELOAD
SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id ninja -C build-deb test
|| ( \
cat build-deb/meson-logs/testlog.txt; \
exit 1)
However, I believe that this would have worked if invoking "meson test"
directly, but not when invoking "ninja", because it doesn't pass the -t argument
down to "meson test", and there doesn't seem to be any other way to achieve
this.
There's an open issue about this upstream, but it doesn't seem like it's to be
implemented any time soon:
https://github.com/mesonbuild/meson/issues/2037
(An environment variable would be a possible solution, I left a comment
there).
Anyway, so what I did was to use the patch attached to modify upstream in a
couple of places to increase or add explicitly timeout for some tests (instead
of the default of 30s), and this makes it build fine in the same systems used as
buildds now.
So please consider to apply this patch or any equivalent solution that you
prefer, to make unnecessary to build this package every time that there's a new
version, and to be able to use "debootstrap".
Thanks and cheers.
--
Manuel A. Fernandez Montecelo
diff -Nru systemd-239/debian/changelog systemd-239/debian/changelog
--- systemd-239/debian/changelog2018-07-22 13:40:15.0 +0200
+++ systemd-239/debian/changelog2018-08-16 17:02:43.0 +0200
@@ -1,3 +1,10 @@
+systemd (239-7+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: increase timeout for tests
+
+ -- Manuel A. Fernandez Montecelo Thu, 16 Aug 2018 17:02:43
+0200
+
systemd (239-7) unstable; urgency=medium
* autopkgtest: Add iputils-ping dependency to root-unittests.
diff -Nru systemd-239/debian/patches/riscv64-support.patch
systemd-239/debian/patches/riscv64-support.patch
--- systemd-239/debian/patches/riscv64-support.patch1970-01-01
01:00:00.0 +0100
+++ systemd-239/debian/patches/riscv64-support.patch2018-08-16
17:02:43.0 +0200
@@ -0,0 +1,41 @@
+--- a/meson.build
b/meson.build
+@@ -2382,7 +2382,8 @@
+
+ test('test-systemd-tmpfiles',
+ test_systemd_tmpfiles_py,
+- args : exe.full_path())
++ args : exe.full_path(),
++ timeout : 300)
+ # https://github.com/mesonbuild/meson/issues/2681
+ endif
+
+@@ -2559,7 +2560,7 @@
+ type = tuple.length() >= 5 ? tuple[4] : ''
+ defs = tuple.length() >= 6 ? tuple[5] : []
+ incs = tuple.length() >= 7 ? tuple[6] : includes
+-
Bug#906204: simutrans: Please switch to SDL2
Source: simutrans Version: 120.3-2 Severity: normal Hello, This package apparently supports SDL2, so please try to enable it and see if it works, because it's probably better than using SDL 1.2 at this point. SDL2 has been released in 2012, more and more important and well-maintained packages are switching to it, and SDL1.2 only receives really critical patches. Cheers. -- Manuel A. Fernandez Montecelo
Bug#895711: gstreamer1.0: please add support for riscv64
2018-07-28 0:05 GMT+02:00 Manuel A. Fernandez Montecelo : > > It would be nice if you could include this patch in future uploads, Thanks Sebastian! -- Manuel A. Fernandez Montecelo
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
2018-07-28 1:45 GMT+02:00 John Paul Adrian Glaubitz : > On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote: >> I was using codesearch.d.n and there are 83 that match "qdoc": >> https://codesearch.debian.net/search?q=%5CWqdoc%5CW > > Wait a minute. How can there be 83 packages already using qdoc when > Lisandro just uploaded the version of qttools to unstable which first > contained the qdoc utility. I am confused. The packages matching the search contain code matching *.qdoc for example, not all necessarily invoke qdoc. Maybe one can restrict the query to calls of qdoc from d/rules, but I think that there will be indirect ways to use qdoc (like "make" in docs dir or something). Anyway, maybe I am misunderstanding the problem, but as I understand it (don't know for sure) is that qdoc was there for a long time, it's not a new thing, and what changed is that it now uses llvm/clang to parse and generate doc instead of some internal code or other external parsers. And the breakage for some ports is that not all of them have support in llvm/clang, whereas presumably what they used before was OK. >> Probably not all of these will actually use it for building (maybe >> they will only test if available, and will generate an empty package >> or something), others might do it only on -indep as Adrian says. >> Almost certainly it will break some package. > > It shouldn't break any package. Again, building documentation in the > binary-arch target should be considered a bug and get fixed. That's more or less what I said, in other words. I am convinced that it will cause some breakage, because not all packages are perfect or because of corner cases, only that uncovering the breakage is probably a good thing in most or all cases, alerting about wrong practices. -- Manuel A. Fernandez Montecelo
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
2018-07-27 14:48 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer : > El viernes, 27 de julio de 2018 09:24:46 -03 Manuel A. Fernandez Montecelo > escribió: > > [snip] >> This page states that: >> >> http://doc.qt.io/qt-5/gettingstarted.html >> >> Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++ >> header and source files, and for parsing the function signatures in >> \fn commands. See Installing clang for QDoc for details. >> >> However, if it can be built without these doc tools, for example using >> Adrian's patch, it would be very nice to try. >> >> Not sure if it will break many packages (for these arches), packages >> might assume that qdoc tools are there, but the alternative is at least >> equally bad, and potentially worse. > > It will also mean that we Qt maintainers will start receiving valid bugs. > Considering the ratio of work and manpower we have now it's not something we > would like to deal with. Now if you can somehow chime in here, well, we can > make an arrangement of some type I guess. > > Maybe by opening a bug due to qdoc removal on some archs might help, you could > subscribe there if needed. OK, sounds fair, whatever the solution is implemented. I was using codesearch.d.n and there are 83 that match "qdoc": https://codesearch.debian.net/search?q=%5CWqdoc%5CW Probably not all of these will actually use it for building (maybe they will only test if available, and will generate an empty package or something), others might do it only on -indep as Adrian says. Almost certainly it will break some package. At that point we can intervene and explain to maintainers, or provide patches, for them to build it as -indep, so it's a win also for the wide Debian project (building -indep when possible, saving resources, etc). -- Manuel A. Fernandez Montecelo
Bug#895711: gstreamer1.0: please add support for riscv64
Hi, 2018-04-15 01:35 Aurelien Jarno: [...]> As requested in the error message, I have filed a bug with at patch upstream: https://bugzilla.gnome.org/show_bug.cgi?id=795271 I have also prepared the corresponding patch for the debian package, please find it attached. Would it be possible to include it to the next upload? It would be nice if you could include this patch in future uploads, otherwise we have to keep building versions of the package and upload to "unreleased" every time that there's an upload -- many rev-build-deps break otherwise. We use this patch when building packages for this port, so it's known to work, and has been accepted upstream already. Cheers. -- Manuel A. Fernandez Montecelo
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
Hi, 2018-07-26 21:48 Lisandro Damián Nicanor Pérez Meyer: Control: severity -1 wishlist Hi Thorsten! El jue., 26 de jul. de 2018 14:03, Thorsten Glaser escribió: Source: qttools-opensource-src Version: 5.11.1-3 Severity: important Justification: fails to build from source (but built successfully in the past), on d-ports arches https://buildd.debian.org/status/package.php?p=qttools-opensource-src LLVM/clang simply is not available for many Debian architectures as it’s not portable. Please drop the B-D for these architectures. I haven't looked at the code but it seems that this dependency is now required in order to build qdoc, so reducing the severity to wishlist. I don't know if it's possible at all to build everything but qdoc. And the effect of this could be many packages starting to FTBFS. This page states that: http://doc.qt.io/qt-5/gettingstarted.html Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++ header and source files, and for parsing the function signatures in \fn commands. See Installing clang for QDoc for details. However, if it can be built without these doc tools, for example using Adrian's patch, it would be very nice to try. Not sure if it will break many packages (for these arches), packages might assume that qdoc tools are there, but the alternative is at least equally bad, and potentially worse. I think that this is similar to the case discussed in #897667, not being able to build qt4-x11 makes big portions of the archive unbuildable, many thousands of packages. Not being able to build qttools-opensource-src will have a similar effect, I think. Cheers. -- Manuel A. Fernandez Montecelo
Bug#896180: cwidget: Bug in updatecursornow(), toplevel.cc:1059
Control: tags -1 + pending Hi Peter, 2018-04-20 16:20 Manuel A. Fernandez Montecelo: Source: cwidget Version: 0.5.17-7 Severity: normal Tags: upstream Hi, I spotted this bug report by chance, from Peter Siket, so submitting to the BTS before it gets lots: https://alioth-lists-archive.debian.net/pipermail/cwidget-devel/2018-March/000255.html You catched this very ancient bug before it became a FTBFS, will apply the fix now, thanks! Cheers. -- Manuel A. Fernandez Montecelo
Bug#904096: ghc: Please add support for riscv64
Source: ghc Version: 8.2.2-4 Severity: normal Tags: upstream patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, We need support in this package for the riscv64 architecture. Adian Glaubitz cross-compiled the package using the patch: https://lists.debian.org/debian-riscv/2018/07/msg7.html Patches are already being applied upstream to support this arch: https://git.haskell.org/ghc.git/commit/beba89a0f16681c85d39fc8a894bde4162ff492a https://git.haskell.org/ghc.git/commit/5e63a25249f3cb07300258e115af9ff55079d2ea https://git.haskell.org/ghc.git/commit/e175aaf6918bb2b497b83618dc4c270a0d231a1c It would be great if you could include these changes and release a new version for unstable, it will live in "unreleased" for a time until then. Thanks and cheers. -- Manuel A. Fernandez Montecelo
Bug#883027: Processed: new upstream release 1.06
2018-07-17 14:44 GMT+02:00 Steven De Herdt : > Hello Manuel > > On 17-07-18 14:38, Manuel A. Fernandez Montecelo wrote: >> Hi Steven, >> >> Thanks for the heads-up. Are you interested in co-maintaining, or it >> was an update to let us know? >> >> >> Cheers. >> > > Just an update to let you know. The most I can aim for, realistically, > is some limited 'drive-by' contribution. But at the moment I can't even > do that. Ah, no problem,thanks for the heads-up. In fact I asked upstream to tag 1.0 to release a new version in Debian, but it took a while and since then I embarked on bootstrapping the RISC-V 64 architecture. Hopefully I can find some time to tackle this in the coming weeks, now that the waters are calmer on other fronts. Cheers. -- Manuel A. Fernandez Montecelo
Bug#883027: Processed: new upstream release 1.06
Hi Steven, 2018-07-17 14:12 GMT+02:00 Debian Bug Tracking System : > >> retitle 883027 new upstream release 1.06 > Bug #883027 [flare-engine] flare-engine: new upstream release 0.20 > Changed Bug title to 'new upstream release 1.06' from 'flare-engine: new > upstream release 0.20'. Thanks for the heads-up. Are you interested in co-maintaining, or it was an update to let us know? Cheers. -- Manuel A. Fernandez Montecelo
Bug#760571: libftgl2: problems with bitmap fonts, incorrect blending function, etc.
Hi, 2018-02-15 21:02 GMT+01:00 Frank Heckenbach : > > My patches (plus a bugfix to them by Olivier Sohn) are now pulled > into this repository, as well as my fork > https://github.com/frankheckenbach/ftgl (ATM both are identical; > ulrichard doesn't really want to "take over" the library, as he > wrote in the mail CCed to you, so you might want to use my fork). > > So can you use it make a Debian upload, or what else do we need to > go on? Sorry, this time it was me who was delayed... This slipped through the cracks because the reply arrived when I was about to depart for FOSDEM and work-related travel, in which I fell ill and was in a horrible state for the best part of February, and since I recovered I was working hard on a port for the new RISC-V architecture for months until now, and busy with family stuff. Still recovering with backlog of stuff to do, but I have the intention of working on this in the coming months, to try to get this into the next stable. But if somebody beats me to it or you find a sponsor, please go ahead. If I don't reply by end of August and still intested, please ping me, I will then try to allocate time more aggressively to make sure that we get this into the next versions. Cheers. -- Manuel A. Fernandez Montecelo
Bug#901566: qtwebkit: Please add support for architecture "riscv64"
2018-06-19 15:08 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer : >> >> [...] >> So please consider including support for this architecture by applying the >> attached patch if you upload new versions. >> [...] > > Very pretty please create a merge request in [salsa] against the repo's master > HEAD. I'll happily push it after that. And sorry for the delay! > > [salsa] <https://salsa.debian.org/qt-kde-team/qt/qtwebkit> No problem for the "delay", quick enough! Here it is, it's my first MR on Salsa so I hope that everything is OK :) https://salsa.debian.org/qt-kde-team/qt/qtwebkit/merge_requests/1 Thanks! -- Manuel A. Fernandez Montecelo
Bug#901577: vlc: Please add support for architecture "riscv64"
Control: forwarded -1 https://trac.videolan.org/vlc/ticket/20683 2018-06-15 11:46 GMT+02:00 Sebastian Ramacher : >> >> I can build successfully just applying the attached minimal patch to >> debian/rules, which should also work fine for all arches, but maybe it would >> be >> better to apply only to riscv64. > > … but does it acutally work? Yep, works fine :) >> It would probably be better to solve this upstream, I don't know if you >> can/prefer contact them or you prefer that we do it. Also not sure how >> likely >> are they to fix the issue and how long it will take. > > I think it would be better if you'd report the issue upstream at > https://trac.videolan.org/vlc/ so that it gets solved properly. For questions > about riscv64 I'd have to forward anything to you anyway. Done, and set forwarded above. >> So we'll appreciate if you fix it in some way in Debian while it's not fixed >> upstream, otherwise a big part of the archive is blocked by this package, >> and we >> have to keep applying the patch, building the package and uploading to a >> special >> archive for this port with every upload or binNMU to src:vlc. > > I can add the -pthread (for riscv64 only) in the next upload. But please, > please, please get it fixed upstream. I don't want to carry those kind of > workarounds around forever. Will try to get them fixed ASAP, yes :-)
Bug#895257: firebird3.0: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2018-04-09 11:47 Manuel A. Fernandez Montecelo:
2018-04-09 02:02 Manuel A. Fernandez Montecelo:
So this will need more work, but please keep the bug open so either
myself or other people can investigate.
I was able to build with the patch attached.
This package is quite important in Debian because Qt depends on it, so
many hundreds of packages or even thousands depend on it indirectly.
We have to keep building a special version of this package every time
that you release a new version or there's a binNMU, or otherwise Qt
might stop compiling, so it's quite a lot of work for us.
Will you please be able to include it in the next uploads?
Another question. I am not sure if this patch that I picked from
upstream will aready appear in 3.0.4 or next versions of 3.x, or it's
only targetted for future major versions that might take years to arrive
in Debian. If you know the reply to this, please tell.
The patch might need some cleanup, but this also depends on when the
upstream patch will enter Debian. It would be nice if this patch from
upstream is included soon and we could rebase the patch, so the delta
carried by Debian is minimal, or even non-existent :-)
Cheers,
--
Manuel A. Fernandez Montecelo
diff -Nru firebird3.0-3.0.3.32900.ds4/debian/changelog
firebird3.0-3.0.3.32900.ds4/debian/changelog
--- firebird3.0-3.0.3.32900.ds4/debian/changelog2018-04-20
15:42:14.0 +0200
+++ firebird3.0-3.0.3.32900.ds4/debian/changelog2018-05-17
22:33:51.0 +0200
@@ -1,3 +1,19 @@
+firebird3.0 (3.0.3.32900.ds4-3+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch from upstream to add riscv64 support:
+- riscv64-support.1e8e7858db84750a77006d307bf28e9686f9414e.patch, with
+ modifications to apply cleanly:
+ + removed hunk fixing typo in "encyption", fixed separately (in another
+patch of the series applied to the package in Debian)
+ + removed extra tab in the second line after "backEndianess" (there are
+only two tabs before the last character, a '1' in the line; in the
+patch from upstream there are 3, so lines don't match)
+ + fixed whitespace in the hunk for configure.ac
+ + refresh
+
+ -- Manuel A. Fernandez Montecelo Thu, 17 May 2018 22:33:51
+0200
+
firebird3.0 (3.0.3.32900.ds4-3) unstable; urgency=medium
* disable UDFs in firebird.conf due to a remote authenticated code execution
diff -Nru
firebird3.0-3.0.3.32900.ds4/debian/patches/riscv64-support.1e8e7858db84750a77006d307bf28e9686f9414e.patch
firebird3.0-3.0.3.32900.ds4/debian/patches/riscv64-support.1e8e7858db84750a77006d307bf28e9686f9414e.patch
---
firebird3.0-3.0.3.32900.ds4/debian/patches/riscv64-support.1e8e7858db84750a77006d307bf28e9686f9414e.patch
1970-01-01 01:00:00.0 +0100
+++
firebird3.0-3.0.3.32900.ds4/debian/patches/riscv64-support.1e8e7858db84750a77006d307bf28e9686f9414e.patch
2018-05-17 22:32:54.0 +0200
@@ -0,0 +1,145 @@
+From 1e8e7858db84750a77006d307bf28e9686f9414e Mon Sep 17 00:00:00 2001
+From: AlexPeshkoff
+Date: Wed, 21 Mar 2018 15:19:20 +0300
+Subject: [PATCH] Patch for CORE-5779: support for riscv64, also some code
+ fixes related with prior ports
+
+---
+ configure.ac| 12
+ src/common/classes/DbImplementation.cpp | 29 -
+ src/common/common.h | 4
+ src/include/gen/msgs.h | 2 +-
+ src/jrd/inf_pub.h | 2 +-
+ 5 files changed, 34 insertions(+), 15 deletions(-)
+
+--- a/configure.ac
b/configure.ac
+@@ -251,6 +251,18 @@
+ libdir=/usr/lib64
+ ;;
+
++ riscv64*-*-linux*)
++MAKEFILE_PREFIX=linux_riscv64
++INSTALL_PREFIX=linux
++PLATFORM=LINUX
++AC_DEFINE(LINUX, 1, [Define this if OS is Linux])
++EDITLINE_FLG=Y
++SHRLIB_EXT=so
++STD_EDITLINE=true
++STD_ICU=true
++libdir=/usr/lib64
++;;
++
+ powerpc64le-*-linux*)
+ MAKEFILE_PREFIX=linux_powerpc64el
+ INSTALL_PREFIX=linux
+--- a/src/common/classes/DbImplementation.cpp
b/src/common/classes/DbImplementation.cpp
+@@ -49,6 +49,7 @@
+ static const UCHAR CpuArm64 = 15;
+ static const UCHAR CpuPowerPc64el = 16;
+ static const UCHAR CpuM68k = 17;
++static const UCHAR CpuRiscV64 = 18;
+
+ static const UCHAR OsWindows = 0;
+ static const UCHAR OsLinux = 1;
+@@ -89,7 +90,8 @@
+ "Alpha",
+ "ARM64",
+ "PowerPC64el",
+- "M68k"
++ "M68k",
++ "RiscV64"
+ };
+
+ const char* operatingSystem[] = {
+@@ -116,22 +118,23 @@
+ // This table lists pre-fb3 implementation codes
+ const UCHAR backwardTable[FB_NELEM(hardware) * FB_NELEM(operatingSystem)] =
+ {
+-//Intel AMD Sparc PPC
PPC64 MIPSEL MIPSARM IA64s390s390x SH
Bug#901577: vlc: Please add support for architecture "riscv64"
Control: reassign -1 src:vlc 3.0.1-3 2018-06-15 0:56 GMT+02:00 Manuel A. Fernandez Montecelo : > Source: src:vlc > Version: 3.0.1-3 > ... For some reason reportbug added src:vlc as the name of Source: ...
Bug#901577: vlc: Please add support for architecture "riscv64"
Source: src:vlc Version: 3.0.1-3 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, vlc fails to build in riscv64: https://buildd.debian.org/status/fetch.php?pkg=vlc=riscv64=3.0.3-1=1527581471=0 The reason for this failure is that it needs to be linked against -latomic to be able to work with sub-word sizes. This library is pulled in automatically when using -pthread if needed, but presumably vlc uses -lpthread to link, which works in most places and architectures, but not this one. I think that this happens in this block: https://sources.debian.org/src/vlc/3.0.3-1/configure.ac/?hl=806#L805 in which probably LIBPTHREAD="$ac_cv_search_pthread_rwlock_init" (or its use in later parts of the compilation) gets the value "-l + pthread" instead of the special "-pthread" needed in this case. I can build successfully just applying the attached minimal patch to debian/rules, which should also work fine for all arches, but maybe it would be better to apply only to riscv64. It would probably be better to solve this upstream, I don't know if you can/prefer contact them or you prefer that we do it. Also not sure how likely are they to fix the issue and how long it will take. So we'll appreciate if you fix it in some way in Debian while it's not fixed upstream, otherwise a big part of the archive is blocked by this package, and we have to keep applying the patch, building the package and uploading to a special archive for this port with every upload or binNMU to src:vlc. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru vlc-3.0.3/debian/changelog vlc-3.0.3/debian/changelog --- vlc-3.0.3/debian/changelog 2018-05-28 23:51:35.0 +0200 +++ vlc-3.0.3/debian/changelog 2018-06-08 17:41:17.0 +0200 @@ -1,3 +1,10 @@ +vlc (3.0.3-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: build with -pthread + + -- Manuel A. Fernandez Montecelo Fri, 08 Jun 2018 15:41:17 + + vlc (3.0.3-1) unstable; urgency=medium * New upstream release. diff -Nru vlc-3.0.3/debian/rules vlc-3.0.3/debian/rules --- vlc-3.0.3/debian/rules 2018-05-21 14:18:40.0 +0200 +++ vlc-3.0.3/debian/rules 2018-06-08 17:41:17.0 +0200 @@ -1,6 +1,6 @@ #!/usr/bin/make -f -DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed +DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed -pthread DEB_BUILD_MAINT_OPTIONS=hardening=+all include /usr/share/dpkg/architecture.mk
Bug#901566: qtwebkit: Please add support for architecture "riscv64"
Source: qtwebkit Version: 2.3.4.dfsg-9.1 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, I know that you want this package removed soonish [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876905 However, until it gets removed from the archive and because still many packages directly build-depend on it, it's a problem for new ports, because it blocks a substantial part of the archive from being built. I cannot recall all the packages right now, since I was working on this a few weeks ago and had to stop for a bit, but it blocks many dozens or hundreds of packages among direct and indirect packages, sometimes very remotely related to this source package, but nevertheless affected. We have this package in the suite "unreleased"; as long as there are no more uploads, we're good. But if there are new uploads with version >= 9.2, it can break things for us. So please consider including support for this architecture by applying the attached patch if you upload new versions. BTW, I think that we already submitted support for this upstream (or if not, we'll do it over the next weeks), but I suspect that this package will not get new upstream releases, so adding the patch directly is the only option in this case. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru qtwebkit-2.3.4.dfsg/debian/changelog qtwebkit-2.3.4.dfsg/debian/changelog --- qtwebkit-2.3.4.dfsg/debian/changelog2016-11-23 11:46:11.0 +0100 +++ qtwebkit-2.3.4.dfsg/debian/changelog2018-05-04 22:40:02.0 +0200 @@ -1,3 +1,10 @@ +qtwebkit (2.3.4.dfsg-9.1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: add support + + -- Manuel A. Fernandez Montecelo Fri, 04 May 2018 20:40:02 + + qtwebkit (2.3.4.dfsg-9.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru qtwebkit-2.3.4.dfsg/debian/patches/riscv64-support.patch qtwebkit-2.3.4.dfsg/debian/patches/riscv64-support.patch --- qtwebkit-2.3.4.dfsg/debian/patches/riscv64-support.patch1970-01-01 01:00:00.0 +0100 +++ qtwebkit-2.3.4.dfsg/debian/patches/riscv64-support.patch2018-05-04 22:40:02.0 +0200 @@ -0,0 +1,47 @@ +Index: qtwebkit-2.3.4.dfsg/Source/WTF/wtf/Platform.h +=== +--- qtwebkit-2.3.4.dfsg.orig/Source/WTF/wtf/Platform.h qtwebkit-2.3.4.dfsg/Source/WTF/wtf/Platform.h +@@ -345,13 +345,20 @@ + #endif + #endif + ++/* CPU(RISCV64) - RISC-V 64 */ ++#if defined(__riscv) && (__riscv_xlen == 64) ++#define WTF_CPU_RISCV64 1 ++#define ENABLE_JIT 0 ++#define ENABLE_YARR_JIT 0 ++#endif ++ + /* CPU(M68K) - m68k */ + #if defined(__mc68000__) + #define WTF_CPU_M68K 1 + #define WTF_CPU_BIG_ENDIAN 1 + #endif + +-#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC) || CPU(MIPS64) ++#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC) || CPU(MIPS64) || CPU(RISCV64) + #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1 + #endif + +@@ -914,6 +921,7 @@ + || CPU(SPARC64) \ + || CPU(S390X) \ + || CPU(AARCH64) \ ++|| CPU(RISCV64) \ + || CPU(MIPS64) \ + || CPU(PPC64) + #define WTF_USE_JSVALUE64 1 +Index: qtwebkit-2.3.4.dfsg/Source/WTF/wtf/dtoa/utils.h +=== +--- qtwebkit-2.3.4.dfsg.orig/Source/WTF/wtf/dtoa/utils.h qtwebkit-2.3.4.dfsg/Source/WTF/wtf/dtoa/utils.h +@@ -49,7 +49,7 @@ + defined(__ARMEL__) || \ + defined(_MIPS_ARCH_MIPS32R2) + #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1 +-#elif CPU(MIPS) || CPU(PPC) || CPU(PPC64) || OS(WINCE) || CPU(SH4) || CPU(S390) || CPU(S390X) || CPU(IA64) || CPU(SPARC) || CPU(ALPHA) || CPU(MIPS64) || CPU(AARCH64) || CPU(HPPA) ++#elif CPU(MIPS) || CPU(PPC) || CPU(PPC64) || OS(WINCE) || CPU(SH4) || CPU(S390) || CPU(S390X) || CPU(IA64) || CPU(SPARC) || CPU(ALPHA) || CPU(MIPS64) || CPU(AARCH64) || CPU(HPPA) || CPU(RISCV64) + #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1 + #elif defined(_M_IX86) || defined(__i386__) + #if defined(_WIN32) diff -Nru qtwebkit-2.3.4.dfsg/debian/patches/series qtwebkit-2.3.4.dfsg/debian/patches/series --- qtwebkit-2.3.4.dfsg/debian/patches/series 2016-11-17 22:20:52.0 +0100 +++ qtwebkit-2.3.4.dfsg/debian/patches/series 2018-05-04 22:34:46.0 +0200 @@ -26,3 +26,4 @@ fix_x32_cpu_detection.patch disable-jit-nonsse2.patch m68k_support.diff +riscv64-support.patch
Bug#893027: aptitude: [INTL:ru] Update Russian translation of aptitude's manual
Control: tags -1 + pending Hi, 2018-03-15 19:59 Lev Lamberov: Package: aptitude Version: 0.8.10-6 Severity: wishlist Tags: l10n patch Dear Maintainer, please find attached the patch to update Russian translation of aptitude's manual. Thanks for the translation (also the program strings), applied now. -- Manuel A. Fernandez Montecelo
Bug#892983: [Aptitude-devel] Bug#892983 + Bug#892984: please allow filtering on/displaying the release 'label'/'suite'
Control: tags 892983 + pending Hi, 2018-04-02 21:35 GMT+02:00 Manuel A. Fernandez Montecelo : > Hi Thomas, > > 2018-04-02 15:51 GMT+02:00 Tomas Pospisek : >> Hi Manuel, >> >> I want to ping you on this wishlist ticket. >> >> I do not want to stress you out: you have your own life and priorities, just >> as everybody else, full respect for that. >> >> However sometimes stuff falls through the cracks, that's why I'm pinging you >> on this. >>[...] With significant delay (alioth/salsa migrations and other stuff in between), finally this is added to the repo. I had to make some changes for the column, but nothing big. Also, I cannot remember why I didn't add it at the time along with Origin, if there was an issue, it might be gone now, not sure. Finally, about the tests, I didn't run them yet, I am going to look at this along with other changes that I am making that will very likely cause some breakage, and I also looking into your other patch (didn't do it yet) and other pending submissions. Cheers. -- Manuel A. Fernandez Montecelo
Bug#897039: java-common: please add support for riscv64
Hi, 2018-04-27 13:37 Aurelien Jarno: Source: java-common Version: 0.63 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 I am in the process of bootstrapping openjdk-9 for the riscv64 architecture (https://wiki.debian.org/RISC-V). java-common builds successfully on this architecture, however the generated packages are unusable as they depend on a non-existing version less openjdk (e.g. openjdk--jdk-headless). The fix is to add proper support for riscv64 in java-common, declaring it as a Java 9 architecture. The attached patch should do that. Would it be possible to include it in the next upload? It would be very nice if this change could be included in the next uploads, otherwise we have to keep spinning special modified builds of this package every time that there's an upload, to avoid having hundreds of unsatisfied build-dependencies / uninstallable packages. openjdk-10 can be used as default, both -9 and -10 are available. Cheers. -- Manuel A. Fernandez Montecelo
Bug#896147: howto limit build-dependency to selected architectures
Hi, 2018-04-23 14:57 Georges Khaznadar: Hello Adrian, I did not find how to specify build dependencies for a subset of architectures. Please do you know some howto about it? Thank you in advance for any highlight. Here you can see an example for the build-dependency on firebird-dev in the package src:qt4-x11: https://sources.debian.org/src/qt4-x11/4:4.8.7+dfsg-17/debian/control/ So just do the same, only with the list that Adrian provided. Also, you need to include explicitly the address of the submitter (or include 896147-submit...@bugs.debian.org) if you want submitters to actually get your emails. Hope that helps :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#899020: qtbase-opensource-src: Please disable gdb build-dependency on riscv64
2018-05-18 18:00 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com>: > Control: tag -1 pending > > That dependency is already removed in our repos. I'll merge with the > relevant bug later. That's great, thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#899020: qtbase-opensource-src: Please disable gdb build-dependency on riscv64
Source: qtbase-opensource-src
Version: 5.9.2+dfsg-12
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hi,
This package depends on gdb, which is not available yet in Debian for the
riscv64 architecture.
We're generally reluctant to ask to disable dependencies specifically for this
architecture, because we hope to get them available in a reasonable timeframe.
However, since it might take a while to get support for riscv64 upstream in gdb
and then in Debian, it is probably better to disable this build-dependency in
riscv64 for the time being, to avoid having to upload packages to "unreleased"
after each upload from you to unstable, or transitions from other libraries that
involve this package.
If we don't do that, packages [transitively] build-depending on this one cannot
be built, since some dependencies cannot be fulfilled, like this one (random
example):
misc/pgmodeler_0.9.1-1 [optional:out-of-date:calprio{47}:days{3}]
Reasons for BD-Uninstallable:
pgmodeler build-depends on:
- qtbase5-dev:riscv64
qtbase5-dev depends on:
- libqt5core5a:riscv64 (= 5.10.1+dfsg-5+0.riscv64.1)
libqt5core5a depends on missing:
- libicu57:riscv64 (>= 57.1-1~)
It would be great if you could include these changes in your next release to
unstable.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
diff -Nru qtbase-opensource-src-5.10.1+dfsg/debian/control
qtbase-opensource-src-5.10.1+dfsg/debian/control
--- qtbase-opensource-src-5.10.1+dfsg/debian/control2018-04-06
16:15:12.0 +0200
+++ qtbase-opensource-src-5.10.1+dfsg/debian/control2018-04-11
02:14:34.0 +0200
@@ -11,9 +11,9 @@
freetds-dev,
- gdb,
+ gdb [!riscv64],
libasound2-dev [linux-any],
libatspi2.0-dev,
libcups2-dev,
Bug#898502: ucommon: Please update symbols for riscv64 and ia64
2018-05-13 12:05 GMT+02:00 Adrian Bunk <b...@debian.org>: > > Builds in reproducible on all 4 architectures: > https://tests.reproducible-builds.org/debian/history/ucommon.html > > Lowering the severity. Thanks for the correction. >> It's strange that symbols change in this way with the same GCC major version, >> the compiler was 7.2 when compiled in the other arches. But the alternative >> explanation that the symbols are fine in all arches except in ia64 and >> riscv64 >> is even more improbable IMO, given the additional coincidade of build dates. >>... > > These have explicit architecture lists in the symbols file, > so not a real surprise when they also appear on new architectures. Indeed, I was looking at the wrong pattern in the symbols file. > --- debian/libucommon8.symbols.old 2018-05-13 09:18:17.048018630 + > +++ debian/libucommon8.symbols 2018-05-13 09:20:12.696017528 + > @@ -2166,16 +2166,8 @@ > (c++)"ucommon::String::unquote(char*, char const*)@Base" 7.0.0 > (c++)"ucommon::String::upper()@Base" 7.0.0 > (c++)"ucommon::String::upper(char*)@Base" 7.0.0 > - (c++|arch=alpha sh4)"ucommon::String::vprintf(char const*, > __va_list_tag)@Base" 7.0.0 > - (c++|arch=amd64 kfreebsd-amd64 powerpc powerpcspe s390x > x32)"ucommon::String::vprintf(char const*, __va_list_tag*)@Base" 7.0.0 > - (c++|arch=hurd-i386 i386 kfreebsd-i386 ppc64 > ppc64el)"ucommon::String::vprintf(char const*, char*)@Base" 7.0.0 > - (c++|arch=arm64 armel armhf)"ucommon::String::vprintf(char const*, > std::__va_list)@Base" 7.0.0 > - (c++|arch=hppa m68k mips mips64el mipsel > sparc64)"ucommon::String::vprintf(char const*, void*)@Base" 7.0.0 > - (c++|arch=alpha sh4)"ucommon::String::vscanf(char const*, > __va_list_tag)@Base" 7.0.0 > - (c++|arch=amd64 kfreebsd-amd64 powerpc powerpcspe s390x > x32)"ucommon::String::vscanf(char const*, __va_list_tag*)@Base" 7.0.0 > - (c++|arch=hurd-i386 i386 kfreebsd-i386 ppc64 > ppc64el)"ucommon::String::vscanf(char const*, char*)@Base" 7.0.0 > - (c++|arch=arm64 armel armhf)"ucommon::String::vscanf(char const*, > std::__va_list)@Base" 7.0.0 > - (c++|arch=hppa m68k mips mips64el mipsel > sparc64)"ucommon::String::vscanf(char const*, void*)@Base" 7.0.0 > + (c++|regex)"^ucommon::String::vprintf\(char const\*, (.+)\)@Base" 7.0.0 > + (c++|regex)"^ucommon::String::vscanf\(char const\*, (.+)\)@Base" 7.0.0 > (c++)"ucommon::String::~String()@Base" 7.0.0 > (c++|arch-bits=32)"ucommon::StringPager::StringPager(char**, unsigned > int)@Base" 7.0.0 > (c++|arch-bits=64)"ucommon::StringPager::StringPager(char**, unsigned > long)@Base" 7.0.0 I am not sure if it's OK to loosen it up so much, because as I understand it, then the changes from: ucommon::String::vscanf(char const*, void*) to, for example: ucommon::String::vscanf(char const*, int, char*) would not be detected. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#898502: ucommon: Please update symbols for riscv64 and ia64
Source: ucommon Version: 7.0.0-12 Severity: serious User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, This is possibly related with #897878 (FTBFS due to symbols with GCC-8), and indeed the solution it's similar, needs an update to the symbols file, but decided to report it separately just in case. The problem of symbols mismatch already happens with gcc-7, the default compiler in unstable, for two arches: https://buildd.debian.org/status/fetch.php?pkg=ucommon=ia64=7.0.0-12=1523296684=0 https://buildd.debian.org/status/fetch.php?pkg=ucommon=riscv64=7.0.0-12=1524128306=0 Also can be seen in the main buildd page in a clear way, the same missing symbol for both ia64 and riscv64 (but different from the ones in gcc-8): https://buildd.debian.org/status/package.php?p=ucommon=sid + _ZN7ucommon6String6vscanfEPKcPv@Base 7.0.0-12 + _ZN7ucommon6String7vprintfEPKcPv@Base 7.0.0-12 So, conjecturing a bit, to me it seems likely that it actually FTBFS in all arches, only that it was not detected because the last builds for these two ones happend in the last <33 days, and for the rest many months ago (8+ months, all during the same days). It's strange that symbols change in this way with the same GCC major version, the compiler was 7.2 when compiled in the other arches. But the alternative explanation that the symbols are fine in all arches except in ia64 and riscv64 is even more improbable IMO, given the additional coincidade of build dates. I'm OK if you decide to set a lower priority, but given that it already fails in at least two arches, the possibility that it happens in others nowadays, and GCC-8 becoming the default soonish (< 3 months, if we look at what happened in previous years), made me to decide for severity "serious". Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#898497: gsettings-qt: Please increase timeout of tests
Source: gsettings-qt Version: 0.1+17.10.20170824-3 Severity: normal Tags: upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, This program fails to build in riscv64 due to timeout of the tests. Admittedly this is a problem specially in this architecture due to having buildds using qemu-system at the moment. However, it's not the only one with buildds running in qemu (although the others use qemu-user, AFAIK), or with slow hardware or potentially with systems under load for any reason. The fact that the buildds are slow by itself shouldn't be a reason to fail tests, and 1 millisecond seems a bit tight to me. So I propose to increase the timeout in line 28 of "tests/cpptest.cpp", "QVERIFY(spy.wait(1));", from 1 millisecond to 1000 (1 second), or at least 100. https://sources.debian.org/src/gsettings-qt/0.1+17.10.20170824-3/tests/cpptest.cpp/ I am not sure if upstream is active and you want me to contact them, or if you would be happy to apply the patch, or refuse, or prefer some other way. Please tell to know if and how we can proceed. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic
2018-05-12 12:14 GMT+02:00 Alberto Garcia <be...@igalia.com>: > fixed 895969 2.20.2-1 > thanks > >> >I think that the patch proposed by Aurelien is probably the best way: >> > >> >set(THREADS_PREFER_PTHREAD_FLAG ON) >> >> This was fixed in 2.20.2-1, but it was missing Closes, perhaps >> intentionally: > > Yes, we can close the bug now. > >> However, the one of experimental seems to have the same problem: > > Yes, because the patch hasn't been applied there yet. I'll try to have > it merged upstream. Perfect, thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#898475: astropy: Please support riscv64, problem with cfitsio
Source: astropy Version: 3.0-3 Severity: normal User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, This package FTBFS under riscv64: https://buildd.debian.org/status/fetch.php?pkg=astropy=riscv64=3.0-3=1525457671=0 The thing that it complains about is cfitsio not being ported: == RuntimeError: unknown error 1. /tmp/astropy-test-uxz2amon/lib/python3.6/site-packages/docs/io/fits/usage/unfamiliar.rst:512: UnexpectedException 61 failed, 10491 passed, 201 skipped, 58 xfailed, 4 xpassed in 7626.39 seconds !!! Byteswapping is not being done correctly on this system. Check the MACHINE and BYTESWAPPED definitions in fitsio2.h Please report this problem to the CFITSIO developers. ... == However, src:cfitsio is ready for riscv64: https://packages.qa.debian.org/c/cfitsio/news/20180406T195008Z.html cfitsio (3.430-2) unstable; urgency=medium . * Add 10-riscv.patch to add support for riscv64. src:astropy contains an embedded copy of cfitsio, so perhaps it's using this copy instead of the one in the system (it has "libcfitsio-dev | libcfitsio3-dev" in the build-dependencies): https://sources.debian.org/src/astropy/3.0-3/cextern/cfitsio/lib/cfileio.c/?hl=4072#L4071 So if it's possible to use the one in the system it would be great, it should fix both problems (riscv64 support, and other ports in the future, and using an embedded copy). BTW, src:astropy builds python3-astropy (note the '3'), and not sure what's the relationship between this one and python-astropy (for Python 2), but the latter also built fine in this architecture. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic
2018-04-26 20:04 Alberto Garcia: On Wed, Apr 25, 2018 at 11:47:39PM +0200, Manuel A. Fernandez Montecelo wrote: I was able to build with the simple patch/debdiff attached (and uploaded to "unreleased"). I am now sure, though, which knobs need to be modified to make this happen in the upstream part in the cleanest way. I think that the patch proposed by Aurelien is probably the best way: set(THREADS_PREFER_PTHREAD_FLAG ON) This was fixed in 2.20.2-1, but it was missing Closes, perhaps intentionally: webkit2gtk (2.20.2-1) unstable; urgency=high . * New upstream release. + This fixes CVE-2018-4200. * debian/patches/fix-atomics-build.patch: + Set THREADS_PREFER_PTHREAD_FLAG to ON. This fixes the build in riscv64 (thanks, Aurelien Jarno). * debian/libwebkit2gtk-4.0-doc.install, debian/rules: + Update path of installed documentation (see WebKit #184771). This version built fine in unstable: https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=riscv64 Another version is building at the moment, a binNMU: "Rebuild against libicu60". However, the one of experimental seems to have the same problem: https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=riscv64=2.21.1-1=1524285204=0 ... ./obj-riscv64-linux-gnu/Source/JavaScriptCore/./obj-riscv64-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Atomics.h:86: undefined reference to `__atomic_compare_exchange_1' ... ./obj-riscv64-linux-gnu/Source/JavaScriptCore/./Source/JavaScriptCore/runtime/JSCellInlines.h:365: undefined reference to `__atomic_fetch_or_1' ... /usr/include/c++/7/bits/atomic_base.h:413: undefined reference to `__atomic_exchange_1' /usr/include/c++/7/bits/atomic_base.h:413: undefined reference to `__atomic_exchange_1' ... Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64
2018-05-11 10:23 GMT+02:00 Simon McVittie <s...@debian.org>: > On Fri, 11 May 2018 at 09:55:38 +0200, Manuel A. Fernandez Montecelo wrote: >> 2018-05-11 2:06 GMT+02:00 Manuel A. Fernandez Montecelo >> <manuel.montez...@gmail.com>: >> > >> > It's starting to build now in one if the buildds, I hope that tomorrow >> > we have the answer. >> >> It failed, log attached. This is the bit that failed: >> >> ==> debian/build-debug/test/test-refs.log <== >> test-refs: pthread_mutex_lock.c:115: __pthread_mutex_lock: Assertion >> `mutex->__data.__owner == 0' failed. >> ../../../build-aux/tap-driver.sh: line 639: 11060 Aborted >> "$@" >> # random seed: R02S40f93f7456852a624ddb781e5293fa4c >> 1..4 >> # Start of refs tests >> # Resetting test timeout (reference: 0x2c80c0; factor: 1) >> ERROR: test-refs - too few tests run (expected 4, got 0) >> ERROR: test-refs - exited with status 134 (terminated by signal 6?) > > That seems to be a legitimate test failure (a glibc bug, not a > timeout). Are atomic operations and mutexes believed to work correctly > in qemu-system-riscv64? Yep, it should work fine, CC'ing Aurélien so it's under his radar. It works fine in hardware too, just compiled successfully, see attached log. So I guess that it's fine and done from the packaging side, unless you want to tweak the timeouts further. Thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> dbus_1.13.4-2_riscv64-2018-05-11T08:00:07Z.build.xz Description: application/xz
Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64
2018-05-11 2:06 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > > It's starting to build now in one if the buildds, I hope that tomorrow > we have the answer. It failed, log attached. This is the bit that failed: ==> debian/build-debug/test/test-refs.log <== test-refs: pthread_mutex_lock.c:115: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. ../../../build-aux/tap-driver.sh: line 639: 11060 Aborted "$@" # random seed: R02S40f93f7456852a624ddb781e5293fa4c 1..4 # Start of refs tests # Resetting test timeout (reference: 0x2c80c0; factor: 1) ERROR: test-refs - too few tests run (expected 4, got 0) ERROR: test-refs - exited with status 134 (terminated by signal 6?) I will start it now in the hardware (although this will not be representative for timeouts and so on in the buildds, for the time being). -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> dbus_1.13.4-2_riscv64-2018-05-11T00:05:41Z.build.xz Description: application/xz
Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64
Hi, 2018-05-11 1:53 GMT+02:00 Simon McVittie <s...@debian.org>: > On Wed, 09 May 2018 at 17:56:01 +0100, Simon McVittie wrote: >> On Sat, 05 May 2018 at 01:46:19 +0200, Manuel A. Fernandez Montecelo wrote: >> > So the build failed in other tests now. >> >> Based on these numbers I've tried a 20x multiplier for the timeouts on >> __riscv in my recent upload to experimental. I've also added better >> logging for buildd builds, so that I don't have to keep asking you >> for logs. >> >> If these changes are successful in experimental then I'll land them >> in unstable. > > Please could you try building dbus/1.13.4-2 from experimental, if you're > keen to accelerate this process? The riscv64 buildds seem to be having > trouble getting the source package, and I'd prefer not to upload this > change to unstable until I can be more confident that it works. Sorry, was travelling for a few days. Only two of the buildds have "experimental" enabled, and large transitions underway, thus the delay. It's starting to build now in one if the buildds, I hope that tomorrow we have the answer. Thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#898023: notmuch: Please disable gdb build-dependency on riscv64
2018-05-06 13:55 GMT+02:00 David Bremner <da...@tethera.net>: > David Bremner <da...@tethera.net> writes: > >> David Bremner <da...@tethera.net> writes: >> >>> >>> These architectures have gdb, but it's broken in various ways. They're >>> also release architectures, where bugs in gdb introduced a regression in >>> notmuch. >> >> I see that some of these architectures have stopped being release >> architectures since that exclusion was added. Probably that list should >> be cleaned up. >> > > In the just uploaded 0.26.2-2, I've done that trimming, and marked gdb > as , so it need not block bootstrapping efforts. Ah, that's good, thanks. I'll build it during this next week. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897667: qt4-x11: Please add support for new architecture "riscv64"
2018-05-06 18:47 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com>: >> >> I somehow prefer to use generic, because there's no point in low-level >> porting Qt4 at this point. > > Worst case scenario: C generic to riscv64, fix that line and be done. But > yes, let's use this as a last resort, as the fix seems legit. Gracias! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#865797: signond FTBFS: symbol changes
user debian-ri...@lists.debian.org usertag 865797 + riscv64 stop Hi, 2017-06-24 23:17 Adrian Bunk: Source: signond Version: 8.59-1 Severity: serious Tags: buster sid Some recent change in unstable makes signond FTBFS: https://tests.reproducible-builds.org/debian/history/signond.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/signond.html FWIW I was able to build for riscv64 updating symbols with pkgkde-symbolshelper (update for all arches), debdiff attached. ia64 and riscv64 are the only ones built recently though. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> diff -Nru signond-8.59/debian/changelog signond-8.59/debian/changelog --- signond-8.59/debian/changelog 2016-06-24 14:20:35.0 +0200 +++ signond-8.59/debian/changelog 2018-05-06 19:35:09.0 +0200 @@ -1,3 +1,10 @@ +signond (8.59-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: symbols update + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Sun, 06 May 2018 17:35:09 + + signond (8.59-1) unstable; urgency=medium [ Diane Trout ] diff -Nru signond-8.59/debian/libsignon-plugins-common1.symbols signond-8.59/debian/libsignon-plugins-common1.symbols --- signond-8.59/debian/libsignon-plugins-common1.symbols 2016-06-24 14:20:35.0 +0200 +++ signond-8.59/debian/libsignon-plugins-common1.symbols 2018-05-06 19:34:49.0 +0200 @@ -1,15 +1,15 @@ -# SymbolsHelper-Confirmed: 8.59 amd64 +# SymbolsHelper-Confirmed: 8.59-1 alpha arm64 armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32 libsignon-plugins-common.so.1 libsignon-plugins-common1 #MINVER# - (optional=templinst|arch=mips64el mipsel)_Z17qRegisterMetaTypeI13QDBusArgumentEiPKcPT_N9QtPrivate21MetaTypeDefinedHelperIS3_Xaasr12QMetaTypeId2IS3_E7DefinedntsrS8_9IsBuiltInEE11DefinedTypeE@Base 8.57+20150423 +#MISSING: 8.59-1# (optional=templinst|arch=mips64el mipsel)_Z17qRegisterMetaTypeI13QDBusArgumentEiPKcPT_N9QtPrivate21MetaTypeDefinedHelperIS3_Xaasr12QMetaTypeId2IS3_E7DefinedntsrS8_9IsBuiltInEE11DefinedTypeE@Base 8.57+20150423 _Z23expandDBusArgumentValueRK8QVariantPb@Base 8.57+20150423 (optional=templinst|arch=amd64)_Z27qRegisterNormalizedMetaTypeI13QDBusArgumentEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS4_Xaasr12QMetaTypeId2IS4_E7DefinedntsrS9_9IsBuiltInEE11DefinedTypeE@Base 8.57+20150423 - (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6CreateEPKv@Base 8.57+20150423 - (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6DeleteEPv@Base 8.57+20150423 +#MISSING: 8.59-1# (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6CreateEPKv@Base 8.57+20150423 +#MISSING: 8.59-1# (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6DeleteEPv@Base 8.57+20150423 (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE8DestructEPv@Base 8.57+20150423 (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE9ConstructEPvPKv@Base 8.57+20150423 (optional=templinst)_ZN4QMapI7QString8QVariantE13detach_helperEv@Base 8.57+20150423 - (optional=templinst)_ZN4QMapI7QString8QVariantED1Ev@Base 8.59 - (optional=templinst)_ZN4QMapI7QString8QVariantED2Ev@Base 8.59 + (optional=templinst|arch=!ia64 !riscv64)_ZN4QMapI7QString8QVariantED1Ev@Base 8.59 + (optional=templinst|arch=!ia64 !riscv64)_ZN4QMapI7QString8QVariantED2Ev@Base 8.59 _ZN6SignOn13BlobIOHandler11qt_metacallEN11QMetaObject4CallEiPPv@Base 8.57+20150423 _ZN6SignOn13BlobIOHandler11qt_metacastEPKc@Base 8.57+20150423 _ZN6SignOn13BlobIOHandler11receiveDataEi@Base 8.57+20150423 @@ -31,23 +31,26 @@ (optional=templinst)_ZN7QVectorI10QByteArrayE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base 8.57+20150423 (optional=templinst)_ZN7QVectorI10QByteArrayE6appendERKS0_@Base 8.57+20150423 (optional=templinst)_ZN8QMapNodeI7QString8QVariantE14destroySubTreeEv@Base 8.57+20150423 + (arch=ia64 riscv64)_ZN9QtPrivate16StreamStateSaverD1Ev@Base 8.59-1 + (arch=ia64 riscv64)_ZN9QtPrivate16StreamStateSaverD2Ev@Base 8.59-1 + (optional=templinst|arch=ia64 riscv64)_ZN9QtPrivate24readAssociativeContainerI4QMapI7QString8QVariantEEER11QDataStreamS6_RT_@Base 8.59-1 _ZNK6SignOn13BlobIOHandler10metaObjectEv@Base 8.57+20150423 (optional=templinst)_ZNK8QMapNodeI7QString8QVariantE4copyEP8QMapDataIS0_S1_E@Base 8.57+20150423 _ZTVN6SignOn13BlobIOHandlerE@Base 8.57+20150423 (optional=templinst)_ZZN11QMetaTypeIdI13QDBusArgumentE14qt_metatype_idEvE11metatype_id@Base 8.57+20150423 - (optional=templinst)_ZrsI7QString8QVariantER11QDataStreamS3_R4QMapIT_T0_E@Base 8.57+20150423 + (optional=templinst|arch=!ia
Bug#897256: re2: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Control: tags -1 + patch Hi again, 2018-04-30 23:49 Manuel A. Fernandez Montecelo: Source: re2 Version: 20180301+dfsg-1 Severity: normal User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for RISC-V to bootstrap the riscv64 architecture. It would be great if you could update the symbols file and release a new version for unstable. Build log with the missing symbols: https://buildd.debian.org/status/fetch.php?pkg=re2=riscv64=20180301%2Bdfsg-1=1524132718=0 If we can do something to speed-up this process, e.g. if you prefer that we provide a patch, please let me/us know. Attaching trivial patch and new file now. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> --- /tmp/re2/re2-20180301+dfsg/debian/libre2-4.symbols 2018-03-03 21:42:20.0 +0100 +++ /home/mafm/prj/riscv/debian-unreleased/re2/built+signed/libre2-4.symbols 2018-05-06 15:45:28.214596819 +0200 @@ -1,6 +1,6 @@ libre2.so.4 libre2-4 #MINVER# -(arch= alpha amd64 arm64 ia64 mips64 mips64el ppc64 ppc64el s390x sparc64 netbsd-alpha kfreebsd-amd64 s390 avr32)#include "libre2.symbols.long_size_t" -(arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !ppc64 !ppc64el !s390x !sparc64 !netbsd-alpha !kfreebsd-amd64 !s390 !avr32)#include "libre2.symbols.int_size_t" +(arch= alpha amd64 arm64 ia64 mips64 mips64el ppc64 ppc64el riscv64 s390x sparc64 netbsd-alpha kfreebsd-amd64 s390 avr32)#include "libre2.symbols.long_size_t" +(arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !ppc64 !ppc64el !riscv64 !s390x !sparc64 !netbsd-alpha !kfreebsd-amd64 !s390 !avr32)#include "libre2.symbols.int_size_t" _ZN3re211FilteredRE214PrintPrefilterEi@Base 20131024+dfsg _ZN3re211FilteredRE219RegexpsGivenStringsERKSt6vectorIiSaIiEEPS3_@Base 20131024+dfsg _ZN3re211FilteredRE23AddERKNS_11StringPieceERKNS_3RE27OptionsEPi@Base 20131024+dfsg libre2.so.4 libre2-4 #MINVER# (arch= alpha amd64 arm64 ia64 mips64 mips64el ppc64 ppc64el riscv64 s390x sparc64 netbsd-alpha kfreebsd-amd64 s390 avr32)#include "libre2.symbols.long_size_t" (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !ppc64 !ppc64el !riscv64 !s390x !sparc64 !netbsd-alpha !kfreebsd-amd64 !s390 !avr32)#include "libre2.symbols.int_size_t" _ZN3re211FilteredRE214PrintPrefilterEi@Base 20131024+dfsg _ZN3re211FilteredRE219RegexpsGivenStringsERKSt6vectorIiSaIiEEPS3_@Base 20131024+dfsg _ZN3re211FilteredRE23AddERKNS_11StringPieceERKNS_3RE27OptionsEPi@Base 20131024+dfsg _ZN3re211FilteredRE27CompileEPSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base 20150701+dfsg _ZN3re211FilteredRE2C1Ei@Base 20161101+dfsg _ZN3re211FilteredRE2C1Ev@Base 20131024+dfsg _ZN3re211FilteredRE2C2Ei@Base 20161101+dfsg _ZN3re211FilteredRE2C2Ev@Base 20131024+dfsg _ZN3re211FilteredRE2D1Ev@Base 20131024+dfsg _ZN3re211FilteredRE2D2Ev@Base 20131024+dfsg _ZN3re211StringPiece4nposE@Base 0+hg23 _ZN3re23RE210FullMatchNERKNS_11StringPieceERKS0_PKPKNS0_3ArgEi@Base 0+hg23 _ZN3re23RE211MaxSubmatchERKNS_11StringPieceE@Base 20131024+dfsg _ZN3re23RE213GlobalReplaceEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKS0_RKNS_11StringPieceE@Base 20150701+dfsg _ZN3re23RE213PartialMatchNERKNS_11StringPieceERKS0_PKPKNS0_3ArgEi@Base 0+hg23 _ZN3re23RE215FindAndConsumeNEPNS_11StringPieceERKS0_PKPKNS0_3ArgEi@Base 0+hg23 _ZN3re23RE23Set3AddERKNS_11StringPieceEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 20150701+dfsg _ZN3re23RE23Set7CompileEv@Base 20131024+dfsg _ZN3re23RE23SetC1ERKNS0_7OptionsENS0_6AnchorE@Base 20131024+dfsg _ZN3re23RE23SetC2ERKNS0_7OptionsENS0_6AnchorE@Base 20131024+dfsg _ZN3re23RE23SetD1Ev@Base 20131024+dfsg _ZN3re23RE23SetD2Ev@Base 20131024+dfsg _ZN3re23RE24InitERKNS_11StringPieceERKNS0_7OptionsE@Base 0+hg23 _ZN3re23RE27ExtractERKNS_11StringPieceERKS0_S3_PNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 20150701+dfsg _ZN3re23RE27Options14kDefaultMaxMemE@Base 0+hg23 _ZN3re23RE27OptionsC1ENS0_13CannedOptionsE@Base 20131024+dfsg _ZN3re23RE27OptionsC2ENS0_13CannedOptionsE@Base 20131024+dfsg _ZN3re23RE27ReplaceEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKS0_RKNS_11StringPieceE@Base 20150701+dfsg _ZN3re23RE28ConsumeNEPNS_11StringPieceERKS0_PKPKNS0_3ArgEi@Base 0+hg23 _ZN3re23RE29QuoteMetaB5cxx11ERKNS_11StringPieceE@Base 20150701+dfsg _ZN3re23RE2C1EPKc@Base 0+hg23 _ZN3re23RE2C1ERKNS_11StringPieceE@Base 0+hg23 _ZN3re23RE2C1ERKNS_11StringPieceERKNS0_7OptionsE@Base 0+hg23 _ZN3re23RE2C1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 20150701+dfsg _ZN3re23RE2C2EPKc@Base 0+hg23 _ZN3re23RE2C2ERKNS_11StringPieceE@Base 0+hg23 _ZN3re23RE2C2ERKNS_11StringPieceERKNS0_7OptionsE@Base 0+hg23 _ZN3re23RE2C2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 20150701+dfsg _ZN3re23RE2D1Ev@Base 0+hg23 _ZN3re23RE2D2Ev@Base 0+hg23 _ZNK3re211FilteredRE210AllMatc
Bug#898020: poco: Please add support for arch riscv64
2018-05-06 12:36 GMT+02:00 Francis ANDRE <francis.andre.kampb...@orange.fr>: > Hi > > Integrated in upcoming Poco release: poco-1.9.1 Thanks both! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#898023: notmuch: Please disable gdb build-dependency on riscv64
Source: notmuch Version: 0.26.2-1 Severity: normal User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, notmuch depends on gdb, which is not available yet in Debian for the riscv64 architecture. After a bit of research, it's not clear to me the purpose of build-depending on gdb. (If you know from the top of your head and can explain briefly it would be great, I am curious now :) ). We're generally reluctant to ask to disable dependencies specifically for this architecture, because we hope to get them available in a reasonable timeframe. However, since this is also disables in fully supported arches for many years like s390x, ppc64el or mips*, in this case is probably better to remove it for riscv64 as well. It would be great if you could include these changes and release a new version for unstable soonish. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#898020: poco: Please add support for arch riscv64
Source: poco Version: 1.9.0-2 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for the riscv64 architecture. I am attaching a patch that adds support. It applies cleanly when added last in the "series" file. Without it, it simply FTBFS since it doesn't know about the architecture. It would be great if you could include these changes and release a new version for unstable soonish. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> Index: poco-1.9.0/Foundation/include/Poco/Platform.h === --- poco-1.9.0.orig/Foundation/include/Poco/Platform.h +++ poco-1.9.0/Foundation/include/Poco/Platform.h @@ -134,6 +134,7 @@ #define POCO_ARCH_NIOS2 0x0e #define POCO_ARCH_AARCH64 0x0f #define POCO_ARCH_ARM64 0x0f // same as POCO_ARCH_AARCH64 +#define POCO_ARCH_RISCV64 0x10 #if defined(__ALPHA) || defined(__alpha) || defined(__alpha__) || defined(_M_ALPHA) @@ -224,6 +225,9 @@ #elif defined(__AARCH64EB__) #define POCO_ARCH POCO_ARCH_AARCH64 #define POCO_ARCH_BIG_ENDIAN 1 +#elif defined(__riscv) && (__riscv_xlen == 64) + #define POCO_ARCH POCO_ARCH_RISCV64 + #define POCO_ARCH_LITTLE_ENDIAN 1 #endif Index: poco-1.9.0/Foundation/src/utils.h === --- poco-1.9.0.orig/Foundation/src/utils.h +++ poco-1.9.0/Foundation/src/utils.h @@ -62,6 +62,7 @@ defined(__sparc__) || defined(__sparc) || defined(__s390__) || \ defined(__SH4__) || defined(__alpha__) || \ defined(_MIPS_ARCH_MIPS32R2) || \ +defined(__riscv) || \ defined(__AARCH64EL__) || \ defined(nios2) || defined(__nios2) || defined(__nios2__) #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1 diff -Nru poco-1.9.0/debian/changelog poco-1.9.0/debian/changelog --- poco-1.9.0/debian/changelog 2018-04-06 13:39:17.0 +0200 +++ poco-1.9.0/debian/changelog 2018-05-05 22:59:49.0 +0200 @@ -1,3 +1,10 @@ +poco (1.9.0-2+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: add support + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Sat, 05 May 2018 20:59:49 + + poco (1.9.0-2) unstable; urgency=medium * Upload to unstable. diff -Nru poco-1.9.0/debian/patches/riscv64-support.patch poco-1.9.0/debian/patches/riscv64-support.patch --- poco-1.9.0/debian/patches/riscv64-support.patch 1970-01-01 01:00:00.0 +0100 +++ poco-1.9.0/debian/patches/riscv64-support.patch 2018-05-05 22:59:43.0 +0200 @@ -0,0 +1,34 @@ +Index: poco-1.9.0/Foundation/include/Poco/Platform.h +=== +--- poco-1.9.0.orig/Foundation/include/Poco/Platform.h poco-1.9.0/Foundation/include/Poco/Platform.h +@@ -134,6 +134,7 @@ + #define POCO_ARCH_NIOS2 0x0e + #define POCO_ARCH_AARCH64 0x0f + #define POCO_ARCH_ARM64 0x0f // same as POCO_ARCH_AARCH64 ++#define POCO_ARCH_RISCV64 0x10 + + + #if defined(__ALPHA) || defined(__alpha) || defined(__alpha__) || defined(_M_ALPHA) +@@ -224,6 +225,9 @@ + #elif defined(__AARCH64EB__) + #define POCO_ARCH POCO_ARCH_AARCH64 + #define POCO_ARCH_BIG_ENDIAN 1 ++#elif defined(__riscv) && (__riscv_xlen == 64) ++ #define POCO_ARCH POCO_ARCH_RISCV64 ++ #define POCO_ARCH_LITTLE_ENDIAN 1 + #endif + + +Index: poco-1.9.0/Foundation/src/utils.h +=== +--- poco-1.9.0.orig/Foundation/src/utils.h poco-1.9.0/Foundation/src/utils.h +@@ -62,6 +62,7 @@ + defined(__sparc__) || defined(__sparc) || defined(__s390__) || \ + defined(__SH4__) || defined(__alpha__) || \ + defined(_MIPS_ARCH_MIPS32R2) || \ ++defined(__riscv) || \ + defined(__AARCH64EL__) || \ + defined(nios2) || defined(__nios2) || defined(__nios2__) + #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1 diff -Nru poco-1.9.0/debian/patches/series poco-1.9.0/debian/patches/series --- poco-1.9.0/debian/patches/series2018-02-28 21:00:38.0 +0100 +++ poco-1.9.0/debian/patches/series2018-05-05 22:59:44.0 +0200 @@ -6,3 +6,4 @@ 0007-Switch-FreeBSD-to-poll.patch 0009-Link-against-dl-on-FreeBSD.patch MySQL-5.7-compatibility.patch +riscv64-support.patch
Bug#898019: sunpinyin: Please add support for arch riscv64
Source: sunpinyin Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for the riscv64 architecture. I am attaching a patch that adds support. It applies cleanly when added last in the "series" file. Without it, it doesn't even start to build and it FTBFS. It would be great if you could include these changes and release a new version for unstable soonish. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> Index: sunpinyin-3.0.0~git20160910/SConstruct === --- sunpinyin-3.0.0~git20160910.orig/SConstruct +++ sunpinyin-3.0.0~git20160910/SConstruct @@ -333,6 +333,7 @@ def AppendEndianCheck(conf): || defined(_M_X64)|| defined(__bfin__) \ || defined(__alpha__) || defined(__ARMEL__) \ || defined(_MIPSEL) || (defined(__sh__) && defined(__LITTLE_ENDIAN__)) \ + || defined(__riscv) \ || defined(__AARCH64EL__) # undef WORDS_BIGENDIAN diff -Nru sunpinyin-3.0.0~git20160910/debian/changelog sunpinyin-3.0.0~git20160910/debian/changelog --- sunpinyin-3.0.0~git20160910/debian/changelog2016-10-12 20:44:02.0 +0200 +++ sunpinyin-3.0.0~git20160910/debian/changelog2018-05-05 23:54:46.0 +0200 @@ -1,3 +1,10 @@ +sunpinyin (3.0.0~git20160910-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: support, endianness + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Sat, 05 May 2018 21:54:46 + + sunpinyin (3.0.0~git20160910-1) unstable; urgency=medium * New upstream snapshot 20160910 diff -Nru sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch --- sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch 1970-01-01 01:00:00.0 +0100 +++ sunpinyin-3.0.0~git20160910/debian/patches/riscv64-support.patch 2018-05-05 23:54:46.0 +0200 @@ -0,0 +1,12 @@ +Index: sunpinyin-3.0.0~git20160910/SConstruct +=== +--- sunpinyin-3.0.0~git20160910.orig/SConstruct sunpinyin-3.0.0~git20160910/SConstruct +@@ -333,6 +333,7 @@ def AppendEndianCheck(conf): + || defined(_M_X64)|| defined(__bfin__) \ + || defined(__alpha__) || defined(__ARMEL__) \ + || defined(_MIPSEL) || (defined(__sh__) && defined(__LITTLE_ENDIAN__)) \ ++ || defined(__riscv) \ + || defined(__AARCH64EL__) + # undef WORDS_BIGENDIAN + diff -Nru sunpinyin-3.0.0~git20160910/debian/patches/series sunpinyin-3.0.0~git20160910/debian/patches/series --- sunpinyin-3.0.0~git20160910/debian/patches/series 2016-10-12 20:44:02.0 +0200 +++ sunpinyin-3.0.0~git20160910/debian/patches/series 2018-05-05 23:54:46.0 +0200 @@ -1 +1,2 @@ fix-data-dir.diff +riscv64-support.patch
Bug#898018: marisa: Please add support for arch riscv64
Source: marisa Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for the riscv64 architecture. I am attaching a patch that adds support. It applies cleanly when added last in the "series" file. Without it, the tests fail, and it FTBFS. It would be great if you could include these changes and release a new version for unstable soonish. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> Index: marisa-0.2.4/lib/marisa/base.h === --- marisa-0.2.4.orig/lib/marisa/base.h +++ marisa-0.2.4/lib/marisa/base.h @@ -31,6 +31,7 @@ typedef uint64_t marisa_uint64; #if defined(_WIN64) || defined(__amd64__) || defined(__x86_64__) || \ defined(__ia64__) || defined(__ppc64__) || defined(__powerpc64__) || \ ( defined(__sparc__) && defined(__arch64__) ) || \ +( defined(__riscv) && (__riscv_xlen == 64) ) || \ defined(__mips64) || defined(__aarch64__) || defined(__s390x__) #define MARISA_WORD_SIZE 64 #else // defined(_WIN64), etc. diff -Nru marisa-0.2.4/debian/changelog marisa-0.2.4/debian/changelog --- marisa-0.2.4/debian/changelog 2014-10-11 16:08:17.0 +0200 +++ marisa-0.2.4/debian/changelog 2018-05-06 01:47:40.0 +0200 @@ -1,3 +1,10 @@ +marisa (0.2.4-8+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: add support for riscv64 to fix tests + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Sat, 05 May 2018 23:47:40 + + marisa (0.2.4-8) unstable; urgency=medium [debian/control] diff -Nru marisa-0.2.4/debian/patches/riscv64-support.patch marisa-0.2.4/debian/patches/riscv64-support.patch --- marisa-0.2.4/debian/patches/riscv64-support.patch 1970-01-01 01:00:00.0 +0100 +++ marisa-0.2.4/debian/patches/riscv64-support.patch 2018-05-06 01:47:40.0 +0200 @@ -0,0 +1,12 @@ +Index: marisa-0.2.4/lib/marisa/base.h +=== +--- marisa-0.2.4.orig/lib/marisa/base.h marisa-0.2.4/lib/marisa/base.h +@@ -31,6 +31,7 @@ typedef uint64_t marisa_uint64; + #if defined(_WIN64) || defined(__amd64__) || defined(__x86_64__) || \ + defined(__ia64__) || defined(__ppc64__) || defined(__powerpc64__) || \ + ( defined(__sparc__) && defined(__arch64__) ) || \ ++( defined(__riscv) && (__riscv_xlen == 64) ) || \ + defined(__mips64) || defined(__aarch64__) || defined(__s390x__) + #define MARISA_WORD_SIZE 64 + #else // defined(_WIN64), etc. diff -Nru marisa-0.2.4/debian/patches/series marisa-0.2.4/debian/patches/series --- marisa-0.2.4/debian/patches/series 2014-09-17 18:05:17.0 +0200 +++ marisa-0.2.4/debian/patches/series 2018-05-06 01:47:40.0 +0200 @@ -1,3 +1,4 @@ module-version-for-egg-inof.patch wordsize-test-for-some-archs.patch support-mips64el.patch +riscv64-support.patch
Bug#898016: speech-tools: needs config.guess/sub update for riscv64
Source: speech-tools
Version: 1:2.5.0-4
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hi,
We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).
The files config.{guess,sub} included in this package are too old to detect this
system.
This package is using dh-autoreconf, as Debian Policy §4.3 recommends, to update
these automatically [1].
However, for some reason it's not working, the tool is not working well together
with the build system as implemented by this package.
[1] https://www.debian.org/doc/debian-policy/#changes-to-the-upstream-sources
"You should make sure that the configure utility detects the correct
architecture specification string (refer to Architecture specification
strings for details).
If your package includes the scripts config.sub and config.guess, you should
arrange for the versions provided by the package autotools-dev be used
instead (see autotools-dev documentation for details how to achieve
that). This ensures that these files can be updated distribution-wide at
build time when introducing new architectures."
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#897667: qt4-x11: Please add support for new architecture "riscv64"
2018-05-05 3:56 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
<perezme...@gmail.com>:
> I was about to upload qt4 when I found:
>
> -Q_GLOBAL_STATIC_WITH_ARGS(const QString, orgFreedesktopDBusString,
> (QLatin1String(DBUS_SERVICE_DBUS)))
> +Q_GLOBAL_STATIC_WITH_ARGS(QString, orgFreedesktopDBusString,
> (QLatin1String(DBUS_SERVICE_DBUS)))
>
> This clearly does not looks ok. Probably a mistake?
I changed this because the compilation fails otherwise:
../../include/QtCore/../../src/corelib/arch/qatomic_generic.h:197:49:
error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
return QBasicAtomicPointer_testAndSetOrdered(pointer.voidp,
expectedValue, newValue);
../../include/QtCore/../../src/corelib/arch/qatomic_generic.h:108:20:
note: initializing argument 3 of 'bool
QBasicAtomicPointer_testAndSetOrdered(void* volatile*, void*,
void*)'
Q_CORE_EXPORT bool QBasicAtomicPointer_testAndSetOrdered(void *
volatile *, void *, void *);
Indeed the definition in "qatomic_generic" is void*,
./src/corelib/arch/qatomic_generic.h:Q_CORE_EXPORT bool
QBasicAtomicPointer_testAndSetOrdered(void * volatile *, void *, void
*);
And that line that I patch is the only one that uses "const QString"
instead of non-const:
$ rgrep 'Q_GLOBAL_STATIC_WITH_ARGS(.*QString' .
./src/gui/embedded/qwindowsystem_qws.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QString,
defaultMouse, (QLatin1String("Auto")))
./src/gui/embedded/qwindowsystem_qws.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QString,
defaultKeyboard, (QLatin1String("TTY")))
./src/dbus/qdbusservicewatcher.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QString,
busService, (QLatin1String(DBUS_SERVICE_DBUS)))
./src/dbus/qdbusservicewatcher.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QString,
busInterface, (QLatin1String(DBUS_INTERFACE_DBUS)))
./src/dbus/qdbusservicewatcher.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QString,
signalName, (QLatin1String("NameOwnerChanged")))
./src/dbus/qdbusintegrator.cpp:Q_GLOBAL_STATIC_WITH_ARGS(const
QString, orgFreedesktopDBusString, (QLatin1String(DBUS_SERVICE_DBUS)))
The alternative would be to use -fpermissive globally, I think, but
this would mask other similar problems, so I patched that one and it
was the only such problematic line in the whole code.
My best guess is that no other [popular] platforms are using "generic"
but its own, so this code is never compiled in Debian for other arches
and thus it doesn't fail, it's a latent error in code of unused
code-paths.
I somehow prefer to use generic, because there's no point in low-level
porting Qt4 at this point.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897667: qt4-x11: Please add support for new architecture "riscv64"
2018-05-05 1:17 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com>: > El viernes, 4 de mayo de 2018 13:45:08 -03 Manuel A. Fernandez Montecelo >> >> 300 is a very low estimation/calculation, if you're using something >> like "build-rdeps" it doesn't tell the whole picture at all, at least >> for new ports. > [snip explanation that rdeps != bootstrapping a new arch] >> So in short, really, about half of Debian depends on qt4-x11 in one >> way or another, including ironically KDE, that moved away from Qt4 >> long ago. > > ACK, and thanks a lot for the detailed explanation :-) Hey, don't worry, it's also confusing for me. Not long ago I thought that the new default method using "dose" would print all the tree of dependencies, but although it prints a bit more than the simple direct ones that build-depend on the package being asked, it's not the full tree by any means. It also surprised me that Qt4 would be so deep-rooted. I though that only packages depending directly on the toolkit and not ported would be involved, and hoped to not have to deal with qt4-x11 at all for this new port, but things turned to be otherwise :( >> This is a chicken and egg problem though, because maintainers don't >> want to remove support until Qt4 is really going away, and this kind >> of migrations of "everything going together at once" is always >> painful. Two ones come to mind: IPv4/6 and Python2/3 :( > > Exactly. As I said in the previous email and what another person wrote in private related to this question, I think that removing it from libffado, fcitx and phonon goes already a long way. I also just noticed these that might be in your hand to remove soon-ish: plasma-theme-oxygen depends upon kde-style-oxygen-qt4 (= 4:5.12.0-2) kde-style-oxygen depends upon kde-style-oxygen-qt4 soprano-daemon depends upon libqt4-dbus (>= 4:4.5.3) At least, when I remove libqt4* from my system, it's only libqt4* and kde4 stuff (kamerka, katepart) , plus a few specific packages like phonon and these 3 that I mention above. > Given all the above I'll try to push Qt4 tonight. If in 24hs I do not get to > do it please do no heasitate in NMUing (or waiting a little more until I or > someone else in the team gets to it). Don't worry, it's not that urgent, but I appreciate the effort. Like for qtbase* in qt5, we can use "unreleased" suite, and the buildds pick up the dependency for it. It is a problem in the long term, thinking in months, because at some point the packages need changes, get entangled in transitions, etc, so the packages to "unreleased" sometimes have to be refreshed and it's a hassle. We have 40~80 there, while we solve problems with their build-deps or send patches that need to be accepted, so sooner or later some of them needs to be refreshed. But I hope that it's not the case of Qt4, specially since it's not supposed to change much :) >> > By the way: in http://deb.li/qt5builds I noticed that most qt5 submodules >> > have been built but not qtbase! How did you achieve that? >> >> Basically, we achieved it by disabling firebird3.0 and gdb as build >> deps, and related packages, which are not yet ready, debdiff: >> >> http://paste.debian.net/hidden/3fcebf14/ > > gdb! That might be comming from the initial packaging and might be a leftover > from qt4. I have already filed a bug against the source to check that, as I > think it is not really used. See, something good might come out of all this > after all :-) Heh, good news :) And don't worry really, I expect that people are reluctant to modify packages that are obsolete long ago. I co-maintain libsdl1.2 ones, which have the same problem, obsoleted since 2012 but still more popular than libsdl2 :( >> In that case we prefer to not submit these changes to you because we >> hope to get them sorted out in a reasonable timeframe, so it would >> mean extra work for you with little gain (to first add exceptions for >> this arch, then remove them). > > Gracias for that Manuel! De nada ;-) I just sent a request to update symbols of kdeclarative, some packages will need updates on the Debian side at least. (I don't say this as a request to fast-track that change, I also added it to "unreleased" so no rush, but I say this as an example that some packages of Qt5/KDE5 will need modifications, even if some for some changes we send directly upstream). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64
2018-05-04 0:49 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > 2018-05-03 19:09 GMT+02:00 Simon McVittie <s...@debian.org>: > >> Please could you try the build on a representative >> riscv64 emulator with the attached hack, and send >> the resulting debian/build-main/test/test-monitor.log and >> debian/build-main/test/test-relay.log to this bug? If it fails, increase >> the numbers as desired (they're an arbitrary number of minutes per >> test-case), but either way I'd like to see the logs so that I can tell >> how much margin of error we get. > > Thanks for the quick feedback, I'll try overnight. So the build failed in other tests now. == ERROR: test-dbus-daemon === ... [many lines like these] dbus-daemon[4174]: [session uid=1000 pid=4174] The maximum number of pending replies for ":1.0" (uid=1000 pid=4094 comm="/<>/debian/build-debug/") has been reached (max_replies_per_connection=128) ../../../build-aux/tap-driver.sh: line 639: 4094 Aborted "$@" # random seed: R02Sf9146ddabfc9fd50b71fb474add3ca89 1..31 # Resetting test timeout (reference: 0x2cdcf0; factor: 1) # ProcessID of this process is 4094 # UnixUserID of this process is 1000 # Time since timeout reset 0x2cdcf0: 1.157 seconds ok 1 /creds PASS: test-dbus-daemon 1 /creds # Resetting test timeout (reference: 0x2cf1d0; factor: 1) # GetConnectionUnixProcessID returned 4094 # Time since timeout reset 0x2cf1d0: 1.239 seconds ok 2 /processid PASS: test-dbus-daemon 2 /processid # Resetting test timeout (reference: 0x2d5c50; factor: 1) # Bug Reference: https://bugs.freedesktop.org/show_bug.cgi?id=61303 # max perf: 2000 messages / 15.252061 seconds # Time since timeout reset 0x2d5c50: 16.087 seconds ok 3 /unix-runtime-is-default PASS: test-dbus-daemon 3 /unix-runtime-is-default # Start of echo tests # Resetting test timeout (reference: 0x2f48e0; factor: 1) # max perf: 2000 messages / 14.492696 seconds # Time since timeout reset 0x2f48e0: 15.351 seconds ok 4 /echo/session PASS: test-dbus-daemon 4 /echo/session # Resetting test timeout (reference: 0x2aaac19cb0; factor: 1) # Bug Reference: https://bugs.freedesktop.org/show_bug.cgi?id=34393 Bail out! Test timed out (SIGALRM received) ERROR: test-dbus-daemon - Bail out! Test timed out (SIGALRM received) == == ERROR: test-header-fields = ../../../build-aux/tap-driver.sh: line 639: 4249 Aborted "$@" # random seed: R02S1ae01519f2b8fdb3e66f5e49563999ed 1..5 # Start of message tests # Start of weird-header-field tests # Resetting test timeout (reference: 0x2cb070; factor: 1) # Running "/message/weird-header-field/none" once to count mallocs # "/message/weird-header-field/none" has about 604 mallocs in total # testing "/message/weird-header-field/none" with up to 2 consecutive malloc failures # testing "/message/weird-header-field/none" with 2 consecutive malloc failures # Time since timeout reset 0x2cb070: 41.593 seconds ok 1 /message/weird-header-field/none PASS: test-header-fields 1 /message/weird-header-field/none # Resetting test timeout (reference: 0x2e5910; factor: 1) # Running "/message/weird-header-field/append" once to count mallocs # "/message/weird-header-field/append" has about 617 mallocs in total # testing "/message/weird-header-field/append" with up to 2 consecutive malloc failures # testing "/message/weird-header-field/append" with 2 consecutive malloc failures # Time since timeout reset 0x2e5910: 47.164 seconds ok 2 /message/weird-header-field/append PASS: test-header-fields 2 /message/weird-header-field/append # Resetting test timeout (reference: 0x2cbf40; factor: 1) # Running "/message/weird-header-field/change" once to count mallocs # "/message/weird-header-field/change" has about 612 mallocs in total # testing "/message/weird-header-field/change" with up to 2 consecutive malloc failures # testing "/message/weird-header-field/change" with 2 consecutive malloc failures Bail out! Test timed out (SIGALRM received) ERROR: test-header-fields - Bail out! Test timed out (SIGALRM received) == The log files of the previous ones that failed: test-relay.log === # random seed: R02S48976acf87ad7a1d71e0cada0537b918 1..3 # Resetting test timeout (reference: 0x2c5760; factor: 10) # Time since timeout reset 0x2c5760: 0.036 seconds ok 1 /connect PASS: test-relay 1 /connect # Resetting test timeout (reference: 0x2c8d40; fac
Bug#897941: kactivities-kf5: Please update symbols for riscv64
Source: kactivities-kf5
Version: 5.42.0-2
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hello,
We need support in this package for the riscv64 architecture.
I am attaching a patch that adds support for the architecture, just symbols
update, and that just built successfully.
It would be great if you could include these changes and release a new version
for unstable, at the moment it lives in "unreleased".
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
# SymbolsHelper-Confirmed: 5.25.0 amd64
libKF5Activities.so.5 libkf5activities5 #MINVER#
_ZN11KActivities10Controller11addActivityERK7QString@Base 4.96.0
_ZN11KActivities10Controller11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
_ZN11KActivities10Controller11qt_metacastEPKc@Base 4.96.0
_ZN11KActivities10Controller12stopActivityERK7QString@Base 4.96.0
_ZN11KActivities10Controller13startActivityERK7QString@Base 4.96.0
_ZN11KActivities10Controller14removeActivityERK7QString@Base 4.96.0
_ZN11KActivities10Controller15setActivityIconERK7QStringS3_@Base 4.96.0
_ZN11KActivities10Controller15setActivityNameERK7QStringS3_@Base 4.96.0
_ZN11KActivities10Controller16staticMetaObjectE@Base 4.96.0
_ZN11KActivities10Controller18setCurrentActivityERK7QString@Base 4.96.0
_ZN11KActivities10Controller22setActivityDescriptionERK7QStringS3_@Base 5.16.0
_ZN11KActivities10ControllerC1EP7QObject@Base 4.96.0
_ZN11KActivities10ControllerC2EP7QObject@Base 4.96.0
_ZN11KActivities10ControllerD0Ev@Base 4.96.0
_ZN11KActivities10ControllerD1Ev@Base 4.96.0
_ZN11KActivities10ControllerD2Ev@Base 4.96.0
_ZN11KActivities12versionMajorEv@Base 4.96.0
_ZN11KActivities12versionMinorEv@Base 4.96.0
_ZN11KActivities13versionStringEv@Base 4.96.0
_ZN11KActivities14versionReleaseEv@Base 4.96.0
_ZN11KActivities15ActivitiesModel11qt_metacallEN11QMetaObject4CallEiPPv@Base
5.21.0
_ZN11KActivities15ActivitiesModel11qt_metacastEPKc@Base 5.21.0
_ZN11KActivities15ActivitiesModel14setShownStatesERK7QVectorINS_4Info5StateEE@Base
5.21.0
_ZN11KActivities15ActivitiesModel16staticMetaObjectE@Base 5.21.0
_ZN11KActivities15ActivitiesModel18shownStatesChangedERK7QVectorINS_4Info5StateEE@Base
5.21.0
_ZN11KActivities15ActivitiesModelC1E7QVectorINS_4Info5StateEEP7QObject@Base
5.21.0
_ZN11KActivities15ActivitiesModelC1EP7QObject@Base 5.21.0
_ZN11KActivities15ActivitiesModelC2E7QVectorINS_4Info5StateEEP7QObject@Base
5.21.0
_ZN11KActivities15ActivitiesModelC2EP7QObject@Base 5.21.0
_ZN11KActivities15ActivitiesModelD0Ev@Base 5.21.0
_ZN11KActivities15ActivitiesModelD1Ev@Base 5.21.0
_ZN11KActivities15ActivitiesModelD2Ev@Base 5.21.0
_ZN11KActivities16ResourceInstance11qt_metacallEN11QMetaObject4CallEiPPv@Base
4.96.0
_ZN11KActivities16ResourceInstance11qt_metacastEPKc@Base 4.96.0
_ZN11KActivities16ResourceInstance11setMimetypeERK7QString@Base 4.96.0
_ZN11KActivities16ResourceInstance13requestsFocusEv@Base 4.96.0
_ZN11KActivities16ResourceInstance14notifyAccessedERK4QUrlRK7QString@Base
4.96.0
_ZN11KActivities16ResourceInstance14notifyModifiedEv@Base 4.96.0
_ZN11KActivities16ResourceInstance15notifyFocusedInEv@Base 4.96.0
_ZN11KActivities16ResourceInstance16notifyFocusedOutEv@Base 4.96.0
_ZN11KActivities16ResourceInstance16staticMetaObjectE@Base 4.96.0
_ZN11KActivities16ResourceInstance6setUriERK4QUrl@Base 4.96.0
_ZN11KActivities16ResourceInstance8setTitleERK7QString@Base 4.96.0
(subst)_ZN11KActivities16ResourceInstanceC1E{quintptr}4QUrlRK7QStringS4_S4_P7QObject@Base
4.96.0
(subst)_ZN11KActivities16ResourceInstanceC1E{quintptr}P7QObject@Base 4.96.0
(subst)_ZN11KActivities16ResourceInstanceC1E{quintptr}RK7QStringP7QObject@Base
4.96.0
(subst)_ZN11KActivities16ResourceInstanceC2E{quintptr}4QUrlRK7QStringS4_S4_P7QObject@Base
4.96.0
(subst)_ZN11KActivities16ResourceInstanceC2E{quintptr}P7QObject@Base 4.96.0
(subst)_ZN11KActivities16ResourceInstanceC2E{quintptr}RK7QStringP7QObject@Base
4.96.0
_ZN11KActivities16ResourceInstanceD0Ev@Base 4.96.0
_ZN11KActivities16ResourceInstanceD1Ev@Base 4.96.0
_ZN11KActivities16ResourceInstanceD2Ev@Base 4.96.0
_ZN11KActivities4Info11iconChangedERK7QString@Base 4.96.0
_ZN11KActivities4Info11infoChangedEv@Base 4.96.0
_ZN11KActivities4Info11nameChangedERK7QString@Base 4.96.0
_ZN11KActivities4Info11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
_ZN11KActivities4Info11qt_metacastEPKc@Base 4.96.0
_ZN11KActivities4Info12stateChangedENS0_5StateE@Base 4.96.0
_ZN11KActivities4Info16isCurrentChangedEb@Base 5.25.0
_ZN11KActivities4Info16staticMetaObjectE@Base 4.96.0
_ZN11KActivities4Info18descriptionChangedERK7QString@Base 5.16.0
_ZN11KActivities4Info5addedEv@Base 4.96.0
_ZN11KActivities4Info7removedEv@Base 4.96.0
_ZN11KActivities4Info7startedEv@Base 4.96.0
_ZN11KActivities4Info7stoppedEv@Base 4.96.0
_ZN11KActivities4InfoC1ERK7QStringP7QObject@Base 4.96.0
_ZN11KActivities4InfoC2ERK7QStringP7QObject@Base 4.96.0
_ZN11KActivities4Info
Bug#897598: cln: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2018-05-03 23:40 Richard B. Kreckel: On 05/03/2018 02:39 PM, Manuel A. Fernandez Montecelo wrote: I am attaching a patch that adds support for the arquitecture. I don't know if you will send upstream yourself or if you prefer that we send it. Pushed patch upstream: https://www.ginac.de/CLN/cln.git/?p=cln.git;a=commit;h=26aaf349a1fb3879274090d9e1c8f86da4a0a585 Thanks for this and for pushing also a release to unstable so quickly! Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897667: qt4-x11: Please add support for new architecture "riscv64"
sorts of interesting cycles to follow in what I wrote above. I fear that the ones that I analysed more closely above are only the tip of the iceberg, but many more packages will need disabling Qt4. >> I am attaching a patch that adds support for the architecture. AFAIK >> (please confirm) upstream doesn't accept patches since long ago, so no >> point in sending it there. > > Yes, Qt4 is **dead** upstream. Adding whatever support means becoming it's > maintainer. And adding more probable life to something that should be not be > here already. As I said, we already have this in unreleased, is impossible to get to >60% of the archive built without qt4 (or else hacking in dozens of packages to remove support from Qt4, and keep a fork of all of them for this port, which is a worse option). So it would be nice to have this patch it in the main package so we don't have to rebuild it from time to time if we need the changes. But there's no other option for us than to have it, really. >> For Qt5 we're already sending it upstream, e.g. >> webkit stuff. > > *Thanks* a lot for that. If you need help prodding upstream please be sure to > contact us. > >> It would be great if you could include these changes and release a new >> version for unstable, for the time being the patched version lives in >> "unreleased". > > I must admit that the patch looks good. But before accepting it I really want > to dig into the dependency chain you wrote above. This seems like a great > opportunity to find possibly wrong stuff. Yeah, I agree. For example, the major ones that I see at the moment are: - libffado should stop depending on python-qt4*, so pulseaudio or libsdl2 doesn't depend indirectly on Qt4 (through jack-audio-connection-kit and jackd2). - phonon direclty depends on libqt4-dev too, so it needs to go. - fcitx needs to stop depending on it, so libsdl2 and its deps like ffmpeg don't (indirectly) depend on Qt4. I think that with those three, a lot of ground is already covered. The good part is that second-level dependencies like "jack*" and libsdl2 don't need to be modified in principle, they don't use the qt4 stuff of libffado or fcitx directly; so a rebuild of fcitx and libffado without Qt4 support shouldn't affect (most of) the packages that depend on it. This is a chicken and egg problem though, because maintainers don't want to remove support until Qt4 is really going away, and this kind of migrations of "everything going together at once" is always painful. Two ones come to mind: IPv4/6 and Python2/3 :( > By the way: in http://deb.li/qt5builds I noticed that most qt5 submodules have > been built but not qtbase! How did you achieve that? Basically, we achieved it by disabling firebird3.0 and gdb as build deps, and related packages, which are not yet ready, debdiff: http://paste.debian.net/hidden/3fcebf14/ I submitted a bug for firebird3.0, but still couldn't get it to build cleanly; and gdb still needs the port of RISC-V merged and then that version uploading to Debian. Similar to qt4-x11, a version of qtbase is living in "unreleased". In that case we prefer to not submit these changes to you because we hope to get them sorted out in a reasonable timeframe, so it would mean extra work for you with little gain (to first add exceptions for this arch, then remove them). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897667: qt4-x11: Please add support for new architecture "riscv64"
Source: qt4-x11 Version: 4:4.8.7+dfsg-15 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package to bootstrap the riscv64 architecture. Yes, I know that you want to get rid of Qt4 once and for all and ASAP, and I fully agree with the goal. However, a bazillion of packages depend on qt4-x11 indirectly, for example libsdl2 needs it (through fcitx, then cmake-extra-modules, then qt5-qmake, then qtchooser that depends on Qt4 stuff); many package still need it directly; etc. So without support in this package, progress becomes impossible at an early stage. I am attaching a patch that adds support for the architecture. AFAIK (please confirm) upstream doesn't accept patches since long ago, so no point in sending it there. For Qt5 we're already sending it upstream, e.g. webkit stuff. It would be great if you could include these changes and release a new version for unstable, for the time being the patched version lives in "unreleased". Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> diff -Nru qt4-x11-4.8.7+dfsg/debian/changelog qt4-x11-4.8.7+dfsg/debian/changelog --- qt4-x11-4.8.7+dfsg/debian/changelog 2018-04-18 22:45:31.0 +0200 +++ qt4-x11-4.8.7+dfsg/debian/changelog 2018-04-27 21:01:58.0 +0200 @@ -1,3 +1,10 @@ +qt4-x11 (4:4.8.7+dfsg-15+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64 support + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Fri, 27 Apr 2018 21:01:58 +0200 + qt4-x11 (4:4.8.7+dfsg-15) unstable; urgency=medium * Actually upload it to unstable. diff -Nru qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch --- qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch 1970-01-01 01:00:00.0 +0100 +++ qt4-x11-4.8.7+dfsg/debian/patches/riscv64-support.patch 2018-04-27 21:01:58.0 +0200 @@ -0,0 +1,86 @@ +--- a/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h b/src/3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h +@@ -167,6 +167,15 @@ + #define WTF_CPU_BIG_ENDIAN 1 + #endif + ++/* CPU(RISCV64) - RISC-V 64-bit */ ++#if defined(__riscv) ++#if (__riscv_xlen == 64) ++#define WTF_CPU_RISCV64 1 ++#elif (__riscv_xlen == 32) ++#define WTF_CPU_RISCV32 1 ++#endif ++#endif ++ + /* CPU(SH4) - SuperH SH-4 */ + #if defined(__SH4__) + #define WTF_CPU_SH4 1 +@@ -919,7 +928,7 @@ + #endif + + #if !defined(WTF_USE_JSVALUE64) && !defined(WTF_USE_JSVALUE32) && !defined(WTF_USE_JSVALUE32_64) +-#if (CPU(X86_64) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || CPU(SPARC64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X) ++#if (CPU(X86_64) && (OS(UNIX) || OS(WINDOWS) || OS(SOLARIS) || OS(HPUX))) || (CPU(IA64) && !CPU(IA64_32)) || CPU(ALPHA) || CPU(AIX64) || CPU(SPARC64) || CPU(MIPS64) || CPU(AARCH64) || CPU(S390X) || CPU(RISCV64) + #define WTF_USE_JSVALUE64 1 + #elif CPU(ARM) || CPU(PPC64) + #define WTF_USE_JSVALUE32 1 +--- a/src/3rdparty/webkit/Source/JavaScriptCore/wtf/Platform.h b/src/3rdparty/webkit/Source/JavaScriptCore/wtf/Platform.h +@@ -187,6 +187,15 @@ + #define WTF_CPU_BIG_ENDIAN 1 + #endif + ++/* CPU(RISCV64) - RISC-V 64-bit */ ++#if defined(__riscv) ++#if (__riscv_xlen == 64) ++#define WTF_CPU_RISCV64 1 ++#elif (__riscv_xlen == 32) ++#define WTF_CPU_RISCV32 1 ++#endif ++#endif ++ + /* CPU(SH4) - SuperH SH-4 */ + #if defined(__SH4__) + #define WTF_CPU_SH4 1 +@@ -1000,6 +1009,7 @@ + #if (CPU(X86_64) && (OS(UNIX) || OS(WINDOWS))) \ + || (CPU(IA64) && !CPU(IA64_32)) \ + || CPU(ALPHA) \ ++|| CPU(RISCV64) \ + || CPU(SPARC64) \ + || CPU(S390X) \ + || CPU(PPC64) \ +--- a/src/corelib/arch/qatomic_arch.h b/src/corelib/arch/qatomic_arch.h +@@ -76,6 +76,8 @@ + # include "QtCore/qatomic_parisc.h" + #elif defined(QT_ARCH_POWERPC) + # include "QtCore/qatomic_powerpc.h" ++#elif defined(QT_ARCH_RISCV64) ++# include "QtCore/qatomic_generic.h" + #elif defined(QT_ARCH_S390) + # include "QtCore/qatomic_s390.h" + #elif defined(QT_ARCH_SPARC) +--- /dev/null b/src/corelib/arch/riscv64/arch.pri +@@ -0,0 +1,8 @@ ++# ++# RISC-V 64 architecture ++# ++ ++unix:SOURCES += ../generic/qatomic_generic_unix.cpp ++win32:SOURCES += ../generic/qatomic_generic_windows.cpp ++ ++QMAKE_CXXFLAGS += -fpermissive +--- a/src/dbus/qdbusintegrator.cpp b/src/dbus/qdbusintegrator.cpp +@@ -73,7 +73,7 @@ + static bool isDebugging; + #define qDBusDebug if (!::isDebugging); else qDebug + +-Q_GLOBAL_STATIC_WITH_ARGS(const QString, orgFreedesktopDBusString, (QLatin1String(DBUS_SERVICE_DBUS))) ++Q_GLOBAL_STATIC_WITH_ARGS(QString, orgFreedesktopDBusString, (QLatin1String(DBUS_SERVICE_DBUS))) + + static inline QString dbusServiceString() +
Bug#897663: ogre-1.9: Add support for riscv64
Source: ogre-1.9 Version: 1.9.0+dfsg1-10 Severity: normal Tags: upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Add support for new architecture -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64
2018-05-03 19:09 GMT+02:00 Simon McVittie <s...@debian.org>: > Control: tags -1 + moreinfo > > On Thu, 03 May 2018 at 16:30:19 +0200, Manuel A. Fernandez Montecelo wrote: >> This package fails to build for the riscv64 architecture, because these two >> test >> cases don't pass: >> >> >> https://buildd.debian.org/status/fetch.php?pkg=dbus=riscv64=1.12.8-2=1525355576=0 >> >> ERROR: test-monitor - Bail out! Test timed out (GLib main loop timeout >> callback reached) >> ERROR: test-relay - Bail out! Test timed out (SIGALRM received) > > As you conjectured, those arbitrary timeouts are meant to be there to stop > the tests from waiting forever if there's a deadlock or infinite loop bug. > >> So there are high chances that it's only that, slow "hardware". > > Looking at the results of other tests, it's taking between 40 and 100 > times as long as my laptop for some tests that succeeded; so yes, very > slow "hardware". FWIW I built it in the real hardware board, it built successfully and it took: 00:28:49 > I'm a little reluctant to just add zeroes to the timeout until it succeeds; > building and testing dbus takes 10 minutes on x86 and 40 minutes on mips, > and I suspect you don't want it to take 16 hours (10 minutes * 100x > worst-case factor) to run the build and the tests on riscv64 :-) Many packages take days, e.g. Python or the several versions of GCC uploaded at least once per week, and same for some packages like Qt or math/science software, so we're used to wait :) But yeah, I get the point. > Please could you try the build on a representative > riscv64 emulator with the attached hack, and send > the resulting debian/build-main/test/test-monitor.log and > debian/build-main/test/test-relay.log to this bug? If it fails, increase > the numbers as desired (they're an arbitrary number of minutes per > test-case), but either way I'd like to see the logs so that I can tell > how much margin of error we get. Thanks for the quick feedback, I'll try overnight. > Alternatively, do you have a pre-prepared riscv64 qemu image that I could > try, or some other way to get the equivalent of a porterbox? How fast > is your slowest host machine for this qemu-system-riscv64 - hopefully > at least as fast as my laptop? We don't have porterboxes yet, hopefully we'll set up something within the month, at least qemu images as you suggested :) Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897655: xutils-dev: Please add support for riscv64
Source: xutils-dev Version: 1:7.7+5 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for the riscv64 architecture. I am attaching a patch that adds support. It applies cleanly when added last in the "series" file. A similar patch was sent by Fedora people ~1 month ago and rejected, since upstream are not interested in continuing support of this software. They already said something similar when I sent a patch back in 2014 for OpenRISC or1k. They were even surprised that people wanted to add support to it. I would gladly let it go, but it turns out that packages like for example emacs25 still need it (through xaw3d). It would be great if you could include these changes and release a new version for unstable, it lives in "unreleased" for the time being. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> Description: Add support for riscv64 Upstream is not interested in adding these patches, they rejected changes when proposed by people from Fedora. . They were already reluctant to add support back in 2014 for other arches, e.g. OpenRISC or1k (I sent the support then). Author: Manuel A. Fernandez Montecelo <m...@debian.org> Last-Update: 2018-05-03 --- a/xorg-cf-files/Imake.cf +++ b/xorg-cf-files/Imake.cf @@ -1037,6 +1037,10 @@ # define AArch64Architecture # undef __aarch64__ # endif +# if defined(__riscv) && (__riscv_xlen == 64) +# define RISCV64Architecture +# /* undef __riscv */ +# endif #endif /* linux || __GLIBC__ */ #if (defined(__Lynx__) || defined(Lynx)) && (defined(i386) || defined(__i386__) || defined(__x86__) || defined(__powerpc__) || defined(__sparc__) || defined(sparc)) --- a/xorg-cf-files/linux.cf +++ b/xorg-cf-files/linux.cf @@ -,6 +,15 @@ # define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines -D_XSERVER64 #endif /* AArch64Architecture */ +#ifdef RISCV64Architecture +# ifndef OptimizedCDebugFlags +# define OptimizedCDebugFlags DefaultGcc2RISCV64Opt DefaultGcc2OptimizeOpt GccAliasingArgs +# endif +# define LinuxMachineDefines -D__riscv +# define ServerOSDefines XFree86ServerOSDefines -DDDXTIME +# define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines -D_XSERVER64 +#endif /* RISCV64Architecture */ + #ifndef StandardDefines # ifdef __linux__ # define StandardDefines -Dlinux LinuxMachineDefines LinuxSourceDefines --- a/xorg-cf-files/xfree86.cf +++ b/xorg-cf-files/xfree86.cf @@ -2067,6 +2067,12 @@ # endif #endif +#if HasGcc2 && defined(RISCV64Architecture) +# ifndef DefaultGcc2RISCV64Opt +# define DefaultGcc2RISCV64Opt DefaultGcc2OptimizeOpt GccAliasingArgs +# endif +#endif + #if HasGcc2 && defined(AlphaArchitecture) # ifndef DefaultGcc2AxpOpt # define DefaultGcc2AxpOpt DefaultGcc2OptimizeOpt GccAliasingArgs --- a/xorg-cf-files/xorg.cf +++ b/xorg-cf-files/xorg.cf @@ -1584,6 +1584,12 @@ # endif #endif +#if HasGcc2 && defined(RISCV64Architecture) +# ifndef DefaultGcc2RISCV64Opt +# define DefaultGcc2RISCV64Opt DefaultGcc2OptimizeOpt GccAliasingArgs +# endif +#endif + #if HasGcc2 && defined(AMD64Architecture) # ifndef DefaultGcc2AMD64Opt # define DefaultGcc2AMD64Opt DefaultGcc2OptimizeOpt GccAliasingArgs
Bug#897650: dh-dlang: Please add support for riscv64
Source: dh-dlang
Version: 0.5
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hello,
We need support in this package for riscv64.
Basically, this means to add gdc as the default-d-compiler, please see attached
patch.
It would be great if you could include these changes and release a new version
for unstable.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
diff -Nru dh-dlang-0.5/debian/changelog
dh-dlang-0.5+0.riscv64.1/debian/changelog
--- dh-dlang-0.5/debian/changelog 2018-03-20 00:28:51.0 +0100
+++ dh-dlang-0.5+0.riscv64.1/debian/changelog 2018-05-03 20:10:04.0
+0200
@@ -1,3 +1,10 @@
+dh-dlang (0.5+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: add default-d-compiler
+
+ -- Manuel A. Fernandez Montecelo <m...@debian.org> Thu, 03 May 2018 20:10:04
+0200
+
dh-dlang (0.5) unstable; urgency=medium
* Fix FTBFS when building arch-dependent packages only (Closes: #893371)
diff -Nru dh-dlang-0.5/debian/control dh-dlang-0.5+0.riscv64.1/debian/control
--- dh-dlang-0.5/debian/control 2018-03-19 22:26:40.0 +0100
+++ dh-dlang-0.5+0.riscv64.1/debian/control 2018-05-03 20:10:04.0
+0200
@@ -24,8 +24,8 @@
for the current architecture.
Package: default-d-compiler
-Architecture: amd64 arm64 armel armhf i386 ppc64 ppc64el x32
-Depends: gdc (>= 8) [arm64 armel ppc64el ppc64 x32],
+Architecture: amd64 arm64 armel armhf i386 ppc64 ppc64el riscv64 x32
+Depends: gdc (>= 8) [arm64 armel ppc64el ppc64 x32 riscv64],
ldc (>= 1:1.8) [amd64 i386 armhf],
${misc:Depends}
Description: Default D compiler (metapackage)
Bug#897649: kdeclarative: Please update symbols for riscv64
Source: kdeclarative Version: 5.42.0-2 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, We are in the process of bootstrapping a Debian port for the riscv64 architecture (https://wiki.debian.org/RISC-V). The symbols need to be updated for this arch, please see the patch attached. We would appreciate if you could upload a version soonish to unstable including this fix, to keep the delta as small as possible. If you need help or want us to NMU, etc., please tell. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> diff -Nru kdeclarative-5.44.0/debian/changelog kdeclarative-5.44.0/debian/changelog --- kdeclarative-5.44.0/debian/changelog2018-03-21 14:40:36.0 +0100 +++ kdeclarative-5.44.0/debian/changelog2018-05-02 19:16:47.0 +0200 @@ -1,3 +1,10 @@ +kdeclarative (5.44.0-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: symbols update + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Wed, 02 May 2018 19:16:47 +0200 + kdeclarative (5.44.0-1) sid; urgency=medium * New upstream release (5.44.0). diff -Nru kdeclarative-5.44.0/debian/libkf5declarative5.symbols kdeclarative-5.44.0/debian/libkf5declarative5.symbols --- kdeclarative-5.44.0/debian/libkf5declarative5.symbols 2018-03-21 14:40:36.0 +0100 +++ kdeclarative-5.44.0/debian/libkf5declarative5.symbols 2018-05-02 19:16:47.0 +0200 @@ -1,4 +1,4 @@ -# SymbolsHelper-Confirmed: 5.25.0 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 mips mips64el mipsel powerpc ppc64el s390x x32 +# SymbolsHelper-Confirmed: 5.25.0 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x x32 libKF5Declarative.so.5 libkf5declarative5 #MINVER# _ZN12KDeclarative12KDeclarative10initializeEv@Base 4.96.0 _ZN12KDeclarative12KDeclarative13setupBindingsEv@Base 4.96.0 @@ -67,42 +67,42 @@ _ZNK12KDeclarative9QmlObject6sourceEv@Base 4.96.0 _ZNK12KDeclarative9QmlObject6statusEv@Base 5.12.0 _ZNK12KDeclarative9QmlObject7packageEv@Base 5.7.0+git20150305.0804+15.04 - (optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base 5.12.0 - (optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base 5.12.0 - (optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base 5.12.0 - (optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base 5.12.0 - (optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base 5.12.0 - (optional=templinst|arch=armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base 5.12.0 - (optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base 5.12.0 - (optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base 5.12.0 - (optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base 5.12.0 - (optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base 5.12.0 - (optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base 5.12.0 - (optional=templinst|arch=!armel)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base 5.12.0 + (optional=templinst|arch=armel riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base 5.12.0 + (optional=templinst|arch=armel riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base 5.12.0 + (optional=templinst|arch=armel riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base 5.12.0 + (optional=templinst|arch=armel riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base 5.12.0 + (optional=templinst|arch=armel riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base 5.12.0 + (optional=templinst|arch=armel riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base 5.12.0 + (optional=templinst|arch=!armel !riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base 5.12.0 + (optional=templinst|arch=!armel !riscv64)_ZNSt23_Sp_counted_ptr_inplaceI10QQmlEngineSaIS0_ELN9__gnu_cxx12_Lock_policyE2EE10
Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64
Source: dbus Version: 1.12.8-2 Severity: normal Tags: upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, This package fails to build for the riscv64 architecture, because these two test cases don't pass: https://buildd.debian.org/status/fetch.php?pkg=dbus=riscv64=1.12.8-2=1525355576=0 ERROR: test-monitor - Bail out! Test timed out (GLib main loop timeout callback reached) ERROR: test-relay - Bail out! Test timed out (SIGALRM received) Summary: # TOTAL: 138 # PASS: 129 # SKIP: 7 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 2 Although it could be that there's an infinite loop or some other problem for those 2 cases, most of the tests pass fine; and the fact is that the buildds at the moment are qemu-system, which make the system slow and timeouts occur in many other packages. So there are high chances that it's only that, slow "hardware". It would be great if you could raise the timeout individually for this architecture or these two test cases, or in the worst case disable them in some way. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#897598: cln: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: cln Version: 1.3.4-3 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for RISC-V to bootstrap the riscv64 architecture. I am attaching a patch that adds support for the arquitecture. I don't know if you will send upstream yourself or if you prefer that we send it. It would be great if you could include these changes and release a new version for unstable. If we can do something to speed-up this process, please let me/us know. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> --- a/include/cln/object.h +++ b/include/cln/object.h @@ -25,7 +25,7 @@ #if defined(__i386__) || (defined(__mips__) && !defined(__LP64__)) || (defined(__sparc__) && !defined(__arch64__)) || defined(__hppa__) || defined(__arm__) || defined(__rs6000__) || defined(__m88k__) || defined(__convex__) || (defined(__s390__) && !defined(__s390x__)) || defined(__sh__) || (defined(__x86_64__) && defined(__ILP32__)) #define cl_word_alignment 4 #endif -#if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || (defined(__sparc__) && defined(__arch64__)) || (defined(__x86_64__) && !defined(__ILP32__)) || defined(__s390x__) || defined(__aarch64__) +#if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || (defined(__sparc__) && defined(__arch64__)) || (defined(__x86_64__) && !defined(__ILP32__)) || defined(__s390x__) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64) #define cl_word_alignment 8 #endif #if !defined(cl_word_alignment) --- a/include/cln/types.h +++ b/include/cln/types.h @@ -48,7 +48,7 @@ #undef HAVE_LONGLONG #endif #endif - #if defined(HAVE_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__)) + #if defined(HAVE_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64)) // 64 bit registers in hardware #define HAVE_FAST_LONGLONG #endif @@ -76,7 +76,7 @@ // Integer type used for counters. // Constraint: sizeof(uintC) >= sizeof(uintL) - #if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__))) + #if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__) || (defined(__riscv) && __riscv_xlen == 64))) #define intCsize long_bitsize typedef long sintC; typedef unsigned long uintC; @@ -88,7 +88,7 @@ // Integer type used for lfloat exponents. // Constraint: sizeof(uintE) >= sizeof(uintC) - #if (defined(HAVE_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__i386__) || defined(__mips__) || defined(__rs6000__) || defined(__aarch64__))) + #if (defined(HAVE_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__i386__) || defined(__mips__) || defined(__rs6000__) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64))) #define intEsize 64 typedef sint64 sintE; typedef uint64 uintE; @@ -127,7 +127,7 @@ typedef int sintD; typedef unsigned int uintD; #else // we are not using GMP, so just guess something reasonable -#if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__) && defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__))) +#if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__) && defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__) || (defined(__riscv) && __riscv_xlen == 64))) #define intDsize 64 typedef sint64 sintD; typedef uint64 uintD; diff -Nru cln-1.3.4/debian/changelog
Bug#897256: re2: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: re2 Version: 20180301+dfsg-1 Severity: normal User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for RISC-V to bootstrap the riscv64 architecture. It would be great if you could update the symbols file and release a new version for unstable. Build log with the missing symbols: https://buildd.debian.org/status/fetch.php?pkg=re2=riscv64=20180301%2Bdfsg-1=1524132718=0 If we can do something to speed-up this process, e.g. if you prefer that we provide a patch, please let me/us know. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#895577: libdbusmenu: Please add ia64 and riscv64 to the list of ports without valgrind
user debian-ri...@lists.debian.org usertag 895577 + riscv64 stop 2018-04-12 23:43 Adrian Bunk: Source: libdbusmenu Version: 16.04.1+17.04.20170109.1-5 Severity: normal Please add ia64 and riscv64 to the list of ports without valgrind, neither port is likely to have valgrind soon. Thanks Adrian, I was going to ask the same thing :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
2018-04-28 7:46 GMT+02:00 Niko Tyni <nt...@debian.org>: > On Thu, Apr 26, 2018 at 09:09:27AM +0200, Manuel A. Fernandez Montecelo wrote: >> >> But since longer builds are not a problem for us, as long as it >> doesn't affect other architectures, it'll be better to increase the >> factor for this arch, to be on the safe side. > > Thanks. I did this in 5.26.2-3, we'll see how it goes. Went great, it built successfully! Thanks :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#897128: atlas: Please add "archdefs" file for riscv64
Source: atlas Version: 3.10.3-5 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, I send attached the files that got computed during a build in real hardware, to be added for this architecture. It would be great if you could include these changes and release a new version for unstable, because we're building it manually at the moment (times out in the buildds). This is the hardware: https://www.sifive.com/products/hifive-unleashed/ Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> GENERIC64.tar.bz2 Description: BZip2 compressed data
Bug#896983: cwidget: Enable mouse wheel as button 5 with new ncurses ABI
2018-04-26 18:31 GMT+02:00 Sven Joachim <svenj...@gmx.de>: > On 2018-04-26 16:23 +0200, Manuel A. Fernandez Montecelo wrote: >> >> Sven, I decided to not enable this functionality just yet, because I thought >> that it would be nice to understand it before and be able to reply myself to >> questions such as: "does it scroll up or down when moving the wheel >> up? > > Moving the wheel forward scrolls up, moving it backward scrolls down, as > you would expect. > >> how many lines scrolls, etc?" > > The minimum appears to be three lines. This is also what I see in > nano(1) (with the -m option). I didn't mean that you should reply to this, but that I like to know exactly what I am enabling. But thanks for the info, knowing that it behaves the same as other applications is a reassurance. I haven't even used the mouse in terminal applications since the VT days, before starting to use X(Free86) regularly :) >> Anyway, so I just uploaded a version of cwidget to experimental, disabling >> the >> code and depending on a new version of cwidget. When uploaded to unstable, I >> will move cwidget there and will upload aptitude depending on the new >> version. >> I think that this should be enough to deal with the immediate problem of the >> transition. > > I have just uploaded ncurses to unstable, waiting for acceptance by the > ftp-masters. Good. I have the change for cwidget ready, will start preparing aptitude. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#896983: cwidget: Enable mouse wheel as button 5 with new ncurses ABI
Source: cwidget
Version: 0.5.17-7
Severity: normal
Tags: upstream patch
Hi,
This is a follow-up of https://bugs.debian.org/891161 , I submit this new one
rather than cloning to not have to go through many messages before learning
about the current status.
Sven, I decided to not enable this functionality just yet, because I thought
that it would be nice to understand it before and be able to reply myself to
questions such as: "does it scroll up or down when moving the wheel up? how
many lines scrolls, etc?"
The missing functionality has been there for more than a decade, so waiting a
bit more shoudln't hurt much.
Unfortunately, in the last few weeks I was busy with the riscv64 port, it was
more quick and intense than what I expected. The removal of Alioth didn't help
at all, I had to migrate many projects, repos, ask mailing lists to be kept
(including cwidget-{devel,users}@ and aptitude-devel@), then tend in an
emergency to moderation of the >1k pending messages before they get lost by an
imminent change that the new admins will impose on mailing lists only announced
a few days ago, etc.
So in the end, I couldn't really investigate the problem deepeer, as well as
other pending bugs that might benefit from a soname bump. (This includes
changes and bugs that were reported in the mailing lists of cwidget* years ago,
that I now noticed due to the removal of alioth and reviewing the archive from
a very long time ago).
Now with the bulk of the administrative diversion stuff done and the riscv64
port progressing at good pace, I will be able to pay more attention to these
projects.
Anyway, so I just uploaded a version of cwidget to experimental, disabling the
code and depending on a new version of cwidget. When uploaded to unstable, I
will move cwidget there and will upload aptitude depending on the new version.
I think that this should be enough to deal with the immediate problem of the
transition.
I could have avoided that by changing the type of mmask_t to a type compatible
witht the old version long ago, but aptitude needs then binNMUs anyway, so
there's not much difference in the outcome -- althought perhaps this could have
saved you some time and trouble if done earlier, sorry for that.
Lastly, these are the changes that Sven created that will allow to enable the
change:
https://salsa.debian.org/joachim-guest/cwidget/commits/ncurses6
https://salsa.debian.org/joachim-guest/aptitude/commits/ncurses6
Cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
2018-04-26 0:25 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > 2018-04-24 23:10 GMT+02:00 Manuel A. Fernandez Montecelo > <manuel.montez...@gmail.com>: >> >> I'm just firing up a build in the board to see if it passes the tests, >> I will report when it finishes, if everything goes all right. > > So it didn't go all right for various reasons, trying again tonight > but I am not very hopeful. For example I am using tmpfs, and some > tests fail (or at least complain) due to that. In the end it built successfully last night, things like the one about tmpfs were only complaints. All tests successful. Elapsed: 3970 sec u=57.60 s=9.86 cu=3460.11 cs=181.47 scripts=2445 tests=1244110 Time for the whole build: Build needed 04:28:34, 541080k disk space (This was in the board.) > However, I think that the best thing to do is indeed increasing the > time to perform the tests, to see if it advances or gets stuck in some > tests, so please enable the change in the next upload. > > If it's not a problem for other architectures I'd even use a bigger > factor, like 5 instead of 2. Some workloads under qemu are really > slow, like 50x times slower than arm64 and 3-4x slower than m68k or > sh4. So the above is in the board, this still applies for the buildds. Re-reading my paragraphs above I shall say, to not give a terrible impression, that some workloads are not slower than in other architectures. But since longer builds are not a problem for us, as long as it doesn't affect other architectures, it'll be better to increase the factor for this arch, to be on the safe side. Cheers and thanks. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
2018-04-24 23:10 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > > I'm just firing up a build in the board to see if it passes the tests, > I will report when it finishes, if everything goes all right. So it didn't go all right for various reasons, trying again tonight but I am not very hopeful. For example I am using tmpfs, and some tests fail (or at least complain) due to that. However, I think that the best thing to do is indeed increasing the time to perform the tests, to see if it advances or gets stuck in some tests, so please enable the change in the next upload. If it's not a problem for other architectures I'd even use a bigger factor, like 5 instead of 2. Some workloads under qemu are really slow, like 50x times slower than arm64 and 3-4x slower than m68k or sh4. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic
Hi,
2018-04-23 10:22 Alberto Garcia:
On Sun, Apr 22, 2018 at 08:48:19PM +0200, Aurelien Jarno wrote:
The correct way to link with -pthread instead of -lpthread is to
use define THREADS_PREFER_PTHREAD_FLAG before importing the Thread
package:
Oh, great, I'll give it a try.
I haven't tried the patch for webkit2gtk, but it works for
qtwebkit. In addition I guess it's necessary to add support for
riscv64 in various places of WTF, by defining WTF_CPU_RISCV64. At
least it's the case also for qtwebkit.
webkit has now WTF_CPU_UNKNOWN for cases like this so perhaps we don't
need to do anything else.
I was able to build with the simple patch/debdiff attached (and uploaded
to "unreleased").
I am now sure, though, which knobs need to be modified to make this
happen in the upstream part in the cleanest way.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
diff -Nru webkit2gtk-2.20.1/debian/changelog webkit2gtk-2.20.1/debian/changelog
--- webkit2gtk-2.20.1/debian/changelog 2018-04-10 20:34:42.0 +0200
+++ webkit2gtk-2.20.1/debian/changelog 2018-04-20 15:50:56.0 +0200
@@ -1,3 +1,10 @@
+webkit2gtk (2.20.1-1+0.riscv64.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * riscv64: force build with -pthread
+
+ -- Manuel A. Fernandez Montecelo <m...@debian.org> Fri, 20 Apr 2018 13:50:56
+
+
webkit2gtk (2.20.1-1) unstable; urgency=medium
[ Alberto Garcia ]
diff -Nru webkit2gtk-2.20.1/debian/rules webkit2gtk-2.20.1/debian/rules
--- webkit2gtk-2.20.1/debian/rules 2018-04-10 20:34:42.0 +0200
+++ webkit2gtk-2.20.1/debian/rules 2018-04-20 15:50:56.0 +0200
@@ -7,6 +7,7 @@
CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS) -Wall
CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS) -Wl,--as-needed
+LDFLAGS += -pthread
DEBHELPER_VERSION = $(shell dpkg-query -W -f='$${source:Version}' debhelper)
Bug#891161: cwidget: FTBFS with libncursesw6
2018-04-25 20:16 GMT+02:00 Sven Joachim <svenj...@gmx.de>: > On 2018-04-20 16:46 +0200, Manuel A. Fernandez Montecelo wrote: > >> 2018-03-31 21:13 GMT+02:00 Manuel A. Fernandez Montecelo >> <manuel.montez...@gmail.com>: >>> 2018-03-31 20:20 GMT+02:00 Sven Joachim <svenj...@gmx.de>: >>>>> So I have to wait to upload cwidget until the new ncurses gets the >>>>> green light and enters unstable, right? >>>> >>>> For uploads to unstable, yes. This holds for both plans (SONAME change or >>>> shlibs bump + Breaks against aptitude). >>> >>> Right, so I can prepare this within a day, for both cwidget and aptitude. >> >> Do you have any indication of when you'll get the green light for unstable? > > Sorry for not replying sooner. Today I finally received a "please go > ahead" mail[1], and I will upload ncurses to unstable soon, possibly > tomorrow. Great, thanks :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#896827: perl: FTBFS on riscv64: t/re/fold_grind timeout
Hi Niko,
2018-04-24 18:55 GMT+02:00 Niko Tyni <nt...@debian.org>:
> Package: perl
> Version: 5.26.2-2
> X-Debbugs-Cc: debian-ri...@lists.debian.org
>
> This package failed to build on riscv64.
>
> t/re/fold_grind # Test
> process timed out - terminating
> FAILED--no leader found
>
> [...]
>
> Failed 1 test out of 2457, 99.96% okay.
> re/fold_grind.t
>
> [...]
>
> Build needed 05:11:45, 350184k disk space
Thanks for taking care :)
> It looks to me like the buildd host is just too slow for this test.
> >From the test:
>
> my $time_out_factor = $ENV{PERL_TEST_TIME_OUT_FACTOR} || 1;
> $time_out_factor = 1 if $time_out_factor < 1;
>
> watchdog(5 * 60 * $time_out_factor);
>
> so the default timeout is five minutes but can be multiplied with
> PERL_TEST_TIME_OUT_FACTOR in the environment.
>
> AFAICS the build time of five hours is well above all the other
> architectures, even m68k and sh4, and it's still less than half of
> a successful build (we have to build perl three times with different
> options, and run the test suite for two of those builds.)
At the moment, these builds are using qemu-system emulation (not even
qemu-user, as --some, or all?-- of the m68k/sh4 buildds). And a new
implementation at that, not very streamlined or tuned for performance.
So yes, they are slower than any other arch at the moment.
It could also happen that the test is stuck due to bugs in qemu, the
toolchain, etc, we already found similar problems in other packages.
> @debian-riscv: I guess I can set PERL_TEST_TIME_OUT_FACTOR=2 for riscv64
> in debian/rules or something like that, do you think that's sensible or
> are the current riscv64 buildds going to get faster any time soon?
We hope to get (donations of) proper hardware at some point, but at
the moment there's only a very limited run of hardware in the world,
and the only one that I got so far is being used for testing and not
for building (not as part of the buildd network, at any rate).
The timeline for getting more hardware is unknown, but I cannot see us
getting faster buildds at least until July, even in the best scenario,
so it's better if you increase the time out factor by two, if not
more.
I'm just firing up a build in the board to see if it passes the tests,
I will report when it finishes, if everything goes all right.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#895864: leptonlib: needs config.guess/sub update for riscv64
2018-04-24 1:59 GMT+02:00 Jeff Breidenbach <j...@jab.org>: > Okay, uploading now. Thanks for all the help! You're welcome. Thanks for applying! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#895864: leptonlib: needs config.guess/sub update for riscv64
2018-04-23 23:22 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > > This additionally runs the tests, > can be disabled with another override_dh_auto_test and leaving it > empty, but I recommend to enable them. The tests built in riscv64 successfully: Testsuite summary for leptonica 1.75.3 # TOTAL: 111 # PASS: 96 # SKIP: 15 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 And: Build needed 00:24:24, 341376k disk space So IMO it's worth enabling them. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#895864: leptonlib: needs config.guess/sub update for riscv64
Hi, 2018-04-23 21:12 GMT+02:00 Jeff Breidenbach <j...@jab.org>: > Is it sufficient to put Build-Depends: debhelper (>= 11.0.0) in > debian/control and 11 in debian/compat ? Thanks for taking care of this. You have to un-comment the "dh_autoreconf*" lines in debian/rules too, not sure why they are disabled, but possibly because they don't work (there's an error from libtoolize/autoconf). It seems to need additionally "pkg-config" in the build-depends, when reconfguring. To the best of my knowledge, if you were using a rule like the following one and without the handcrafted rules, I think that it would be part of the commands invoked by default, but with the handcrafted rules they take precedence, so the defaults are not invoked. = %: dh $@ = The rule above covers the defaults of leptonlib quite well, since it's not using anything contrived, only needs a minor modification for the manpage. Things like noopt and nostrip are supposed to be handled automatically. I attach 3 files: 1) the minimal conversion so dh-autoreconf works (leptonlib_1.75.3-3.1.debdiff) 2) and 3) the full conversion to simple rules, with leptonlib_1.75.3-3.2.debdiff and debian/rules attached separate, to see clearly the benefits. (Obviously, by the way, the message in d/changelog should be squashed). This additionally runs the tests, can be disabled with another override_dh_auto_test and leaving it empty, but I recommend to enable them. I tested 1 and 2/3 and it works fine, both produce binaries in amd64 that don't differ from the previous version (debdiff). Hope that helps. If in any doubt, please ask. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> leptonlib_1.75.3-3.1.debdiff Description: Binary data leptonlib_1.75.3-3.2.debdiff Description: Binary data rules Description: Binary data
Bug#896514: Fix symbols for riscv64 and symbol cleanup
user debian-ri...@lists.debian.org usertag 896514 + riscv64 stop Hi, 2018-04-22 00:43 Alf Gaida: Package: libfm-qt3 Severity: normal two new symbols from Qt 5.10 transition add riscv64 to symbols Wow, only minutes after the fist build of the package happened. I was about to submit the request, and the bug was here already :) So yes please, add support for the new arch, in this case it seems that it only needs update to symbols. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#890791: stretch-pu: package dpkg/1.18.25
Hi, 2018-04-20 1:52 GMT+02:00 Guillem Jover <guil...@debian.org>: > Hi! > > On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote: >> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote: >> > 2018-02-18 22:26 Guillem Jover: >> > > I'd like to update dpkg in stretch. This includes several fixes for >> > > documentation, regressions, misbheavior, minor security issues, and >> > > a new arch definition so that DAK can accept packages using it. The >> > > fixes have been in sid/buster for a while now. >> > >> > We depend on this version being accepted and installed in the systems >> > where DAK lives to learn about the new architecture. After that, >> > several other packages can add support for the architecture, without >> > receiving an automatic reject when uploaded. >> > >> > It would be great if this update could enter in the next stable >> > update, so we can make progress on that front. > >> We've been discussing this amongst the SRMs and are quite wary of a >> dpkg update this close to the p-u freeze. We appreciate that the >> changes individually seem self-contained but would like to have an >> update of such a key package able to be tested more than is feasible in >> the time available. >> >> (On a related note, in practical terms it's very unlikely that there >> would be sufficient time to get the new strings that are introduced >> translated.) > > Is there perhaps anything you are waiting for me to do here? > > For the strings I realized afterwards I can take the ones from sid. > I've not yet checked how many, or if I'd really need a call for > translation, but I'd rather do that only after I know which parts you > are going to accept. :) But TBH, this being gettext I'm not sure it > matters that much, as only those strings might end up not being > translated and dpkg does not have 100% coverage for all languages > anyway. :) Thanks Guillem. So in the 2+ months since that original request, we went from scattered packages outside the Debian infrastructure to having a port in debian-ports infra, with >60% of packages built. Unfortunately, important packages like binutils, glibc or linux-* have to stay in the separate "unreleased" suite for that reason, so the lack of support in dak for riscv64 is causing us to do this extra work, which would be otherwise unneeded It would be very nice if this update could move to stable-updates to unblock the situation in a few weeks/months time. Thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#895748: mpi-default-dev: add riscv64 to list of MPI arches
Control: tags -1 + pending Hi, 2018-04-16 5:00 GMT+02:00 Drew Parsons <dpars...@debian.org>: > On Sun, 2018-04-15 at 18:33 +0200, Manuel A. Fernandez Montecelo wrote: >> >> > Whether default to openmpi or to mpich, your choice. >> >> mpich fails due to tests in the current buildd, and although ideally >> we'll work on it and get it properly fixed soon, for riscv64 it'd >> better >> be "openmpi" at the moment -- which is the defalt for almost all >> other >> arches anyway, as you say further down in your message. > > Thanks Manuel, that's a good reason for assigning openmpi to the > riscv64 defaults then. I committed support here: https://salsa.debian.org/science-team/mpi-defaults/commit/9ecb7d06b0e283ad8464900bd6800214c1157115 Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#891161: cwidget: FTBFS with libncursesw6
Hi Sven, 2018-03-31 21:13 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > 2018-03-31 20:20 GMT+02:00 Sven Joachim <svenj...@gmx.de>: >>> So I have to wait to upload cwidget until the new ncurses gets the >>> green light and enters unstable, right? >> >> For uploads to unstable, yes. This holds for both plans (SONAME change or >> shlibs bump + Breaks against aptitude). > > Right, so I can prepare this within a day, for both cwidget and aptitude. Do you have any indication of when you'll get the green light for unstable? -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#896181: cwidget: [PATCH] Use %p for pointers instead of %x
Source: cwidget Version: 0.5.17-7 Severity: normal Tags: patch upstream Hi, Attaching patch from Ahmed Charles sent to the mailing list a while ago: https://alioth-lists-archive.debian.net/pipermail/cwidget-devel/2016-March/000251.html Thanks! -- Manuel A. Fernandez Montecelo <m...@debian.org> >From c22b4342e679badad3448c6f2c76d47995042041 Mon Sep 17 00:00:00 2001 From: Ahmed Charles <achar...@outlook.com> Date: Thu, 24 Mar 2016 16:55:45 -0700 Subject: [PATCH] Use %p for pointers instead of %x. --- src/cwidget/widgets/table.cc | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/cwidget/widgets/table.cc b/src/cwidget/widgets/table.cc index 70962ba..f2e77d4 100644 --- a/src/cwidget/widgets/table.cc +++ b/src/cwidget/widgets/table.cc @@ -719,7 +719,7 @@ namespace cwidget vector sorted_children; #ifdef DEBUG_TABLES - fprintf(debug, "-- Begin ideal width allocation for 0x%x (w=%d,h=%d) --\n", this, getmaxx(), getmaxy()); + fprintf(debug, "-- Begin ideal width allocation for 0x%p (w=%d,h=%d) --\n", this, getmaxx(), getmaxy()); #endif for(vector::iterator i=col_sizes.begin(); i!=col_sizes.end(); ++i) @@ -791,7 +791,7 @@ namespace cwidget } #ifdef DEBUG_TABLES - fprintf(debug, "Child at (%d,%d) requested %d columns\n", + fprintf(debug, "Child at (%d,%d) requested %d columns (current: %d)\n", (*i)->col_start, (*i)->row_start, (*i)->request_w, current_width); #endif } @@ -802,7 +802,7 @@ namespace cwidget fprintf(debug, " %d", col_sizes[i]); fprintf(debug, "\n"); - fprintf(debug, " end ideal allocation for 0x%x -\n\n", this); + fprintf(debug, " end ideal allocation for 0x%p -\n\n", this); #endif } @@ -833,7 +833,7 @@ namespace cwidget return; #ifdef DEBUG_TABLES - fprintf(debug, " Expanding 0x%x (w=%d, h=%d) to %d columns **\n", this, getmaxx(), getmaxy(), target_w); + fprintf(debug, " Expanding 0x%p (w=%d, h=%d) to %d columns **\n", this, getmaxx(), getmaxy(), target_w); #endif // Note that this is redundant with the previous algorithm. Merge? @@ -895,7 +895,7 @@ namespace cwidget fprintf(debug, " %d", col_sizes[i]); fprintf(debug, "\n"); - fprintf(debug, "* end expanding columns of 0x%x \n\n", this); + fprintf(debug, "* end expanding columns of 0x%p \n\n", this); #endif } @@ -921,7 +921,7 @@ namespace cwidget return; #ifdef DEBUG_TABLES - fprintf(debug, "++ Shrinking columns of 0x%x (w=%d, h=%d) to %d \n", this, getmaxx(), getmaxy(), target_w); + fprintf(debug, "++ Shrinking columns of 0x%p (w=%d, h=%d) to %d \n", this, getmaxx(), getmaxy(), target_w); #endif for(int i=0; i<num_cols; ++i) @@ -990,7 +990,7 @@ namespace cwidget fprintf(debug, " %d", col_sizes[i]); fprintf(debug, "\n"); - fprintf(debug, " end shrinking 0x%x +\n\n", this); + fprintf(debug, " end shrinking 0x%p +\n\n", this); #endif } @@ -1013,7 +1013,7 @@ namespace cwidget vector sorted_children; #ifdef DEBUG_TABLES - fprintf(debug, "-- Begin ideal height allocation for 0x%x (w=%d,h=%d) --\n", this, getmaxx(), getmaxy()); + fprintf(debug, "-- Begin ideal height allocation for 0x%p (w=%d,h=%d) --\n", this, getmaxx(), getmaxy()); #endif for(vector::iterator i=row_sizes.begin(); i!=row_sizes.end(); ++i) @@ -1101,7 +1101,7 @@ namespace cwidget fprintf(debug, " %d", row_sizes[i]); fprintf(debug, "\n"); - fprintf(debug, " end ideal allocation for 0x%x -\n\n", this); + fprintf(debug, " end ideal allocation for 0x%p -\n\n", this); #endif } @@ -1132,7 +1132,7 @@ namespace cwidget return; #ifdef DEBUG_TABLES - fprintf(debug, " Expanding 0x%x (w=%d, h=%d) to %d rows **\n", this, getmaxx(), getmaxy(), target_h); + fprintf(debug, " Expanding 0x%p (w=%d, h=%d) to %d rows **\n", this, getmaxx(), getmaxy(), target_h); #endif // Note that this is redundant with the previous algorithm. Merge? @@ -1194,7 +1194,7 @@ namespac
Bug#896180: cwidget: Bug in updatecursornow(), toplevel.cc:1059
Source: cwidget Version: 0.5.17-7 Severity: normal Tags: upstream Hi, I spotted this bug report by chance, from Peter Siket, so submitting to the BTS before it gets lots: https://alioth-lists-archive.debian.net/pipermail/cwidget-devel/2018-March/000255.html Thanks Peter! -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#894995: rdma-core: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2018-04-19 14:00 GMT+02:00 Benjamin Drung <benjamin.dr...@profitbricks.com>: > > RISC-V has a FENCE instruction and the A extension (which is part of > the G instruction set) provides atomic memory operations. So the > architecture should provide coherent DMA support. To enable support, > util/udma_barrier.h needs to be adjusted. I am including > linux-r...@vger.kernel.org in the loop for help. Thanks! (not CC'ing the list). -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#896127: glew: needs config.guess/sub update for riscv64
Source: glew
Version: 2.0.0-5
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hi,
We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).
The files config.{guess,sub} included in this package are too old to detect this
system.
Debian Policy §4.3 recommends to update these automatically [1], one of the best
ways to achieve this is to depend on newer versions of debhelper and use
dh-autoreconf.
This package is QA-maintained, anybody who reads this please feel free to work
on it and upload :)
[1] https://www.debian.org/doc/debian-policy/#changes-to-the-upstream-sources
"You should make sure that the configure utility detects the correct
architecture specification string (refer to Architecture specification
strings for details).
If your package includes the scripts config.sub and config.guess, you should
arrange for the versions provided by the package autotools-dev be used
instead (see autotools-dev documentation for details how to achieve
that). This ensures that these files can be updated distribution-wide at
build time when introducing new architectures."
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#896126: mpg123: symbols update for riscv64
Source: mpg123 Version: 1.25.10-1 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, We are in the process of bootstrapping a Debian port for the riscv64 architecture (https://wiki.debian.org/RISC-V). The symbols need to be updated for this arch, please see the patch attached. We would appreciate if you could upload a version soonish to unstable including this fix, to keep the delta as small as possible. If you need help or want us to NMU, etc., please tell. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> diff -Nru mpg123-1.25.10/debian/libmpg123-0.symbols mpg123-1.25.10/debian/libmpg123-0.symbols --- mpg123-1.25.10/debian/libmpg123-0.symbols 2016-09-28 18:43:08.0 +0200 +++ mpg123-1.25.10/debian/libmpg123-0.symbols 2018-04-19 18:13:34.0 +0200 @@ -1,3 +1,3 @@ #include "libmpg123-0.symbols.common.in" #include "libmpg123-0.symbols.64bit.in" -(arch=!amd64 !arm64 !ia64 !kfreebsd-i386 !kfreebsd-amd64 !s390x !ppc64 !ppc64el !alpha !sparc64 !mips64 !mips64el !x32)#include "libmpg123-0.symbols.32bit.in" +(arch=!amd64 !arm64 !ia64 !kfreebsd-i386 !kfreebsd-amd64 !s390x !ppc64 !ppc64el !alpha !sparc64 !mips64 !mips64el !x32 !riscv64)#include "libmpg123-0.symbols.32bit.in"
Bug#895864: leptonlib: needs config.guess/sub update for riscv64
Source: leptonlib
Version: 1.75.3-3
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hi,
We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).
The files config.{guess,sub} included in this package are too old to detect this
system.
This package is quite important as it's a dependency of ffmpeg, and thus of all
of its many reverse-dependencies.
Debian Policy §4.3 recommends to update these automatically [1], one of the best
ways to achieve this is to depend on newer versions of debhelper (the current
level used by this package is deprecated) and use dh-autoreconf.
If you need help or want us to provide a patch, prefer that we NMU, etc., please
tell.
[1] https://www.debian.org/doc/debian-policy/#changes-to-the-upstream-sources
"You should make sure that the configure utility detects the correct
architecture specification string (refer to Architecture specification
strings for details).
If your package includes the scripts config.sub and config.guess, you should
arrange for the versions provided by the package autotools-dev be used
instead (see autotools-dev documentation for details how to achieve
that). This ensures that these files can be updated distribution-wide at
build time when introducing new architectures."
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#895748: mpi-default-dev: add riscv64 to list of MPI arches
Control: user debian-ri...@lists.debian.org Control: usertag -1 + riscv64 Hi, 2018-04-15 17:19 Drew Parsons: Package: mpi-default-dev Version: 1.10 Severity: normal Both openmpi and mpich now build on the new arch riscv64. So riscv64 should be added to the list of default arches. I was going to submit a bug report right now (thanks for beating me to it!), so yes, please add support for this arch. Whether default to openmpi or to mpich, your choice. mpich fails due to tests in the current buildd, and although ideally we'll work on it and get it properly fixed soon, for riscv64 it'd better be "openmpi" at the moment -- which is the defalt for almost all other arches anyway, as you say further down in your message. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#895333: double-conversion: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: double-conversion Version: 2.0.1-4 Severity: normal Tags: patch upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We need support in this package for the riscv64 architecture. With the "quick and dirty" patch attached it builds and passes the test suite, but ideally it should also test which of the ISA extensions (including which of the FP extensions, Float, Double, Quad) actually fullfil the property that needs support. (In "riscv64" we are using "G+C"="IMAFD+C" as baseline, so with the Float and Double extensions). The package is orphaned and under the umbrella of Science Team, so if anybody feels adventurous, please go and team-fix or NMU :) Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> --- a/src/utils.h +++ b/src/utils.h @@ -58,6 +58,7 @@ defined(__hppa__) || defined(__ia64__) || \ defined(__mips__) || \ defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) || \ +defined(__riscv) || \ defined(__sparc__) || defined(__sparc) || defined(__s390__) || \ defined(__SH4__) || defined(__alpha__) || \ defined(_MIPS_ARCH_MIPS32R2) || \
Bug#895257: firebird3.0: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2018-04-09 02:02 Manuel A. Fernandez Montecelo:
It needs some modifications (file attached) to be applied in the current version
of this package in unstable:
+ removed hunk fixing typo in "encyption", fixed separately (in another
patch of the series applied to the package in Debian)
+ removed extra tab in the second line after "backEndianess" (there are
only two tabs before the last character, a '1' in the line; in the
patch from upstream there are 3, so lines don't match)
+ fixed whitespace in the hunk for configure.ac
+ refresh
The patch needs more things, in particular
builds/posix/prefix.linux_riscv64, which exists for other architectures
but the upstream patch doesn't include.
Attached this latest version.
The build didn't finish yet, we will confirm later when it works, or will send
further fixes.
In the end the build failed:
===
In file included from
/<>/src/yvalve/../yvalve/../yvalve/../common/StatusHolder.h:36:0,
from
/<>/src/yvalve/../yvalve/../yvalve/YObjects.h:32,
from
/<>/src/yvalve/../yvalve/DistributedTransaction.h:32,
from /<>/src/yvalve/DistributedTransaction.cpp:31:
/<>/src/yvalve/../yvalve/../yvalve/../common/../common/DynamicStrings.h:37:95:
warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
unsigned makeDynamicStrings(unsigned len, ISC_STATUS* const dst, const
ISC_STATUS* const src) throw(BadAlloc);
^
/<>/gen/Release/firebird/bin/gpre_current -m -z -n
/<>/src/yvalve/blob.epp /<>/temp/Release/yvalve/blob.cpp
gpre version LI-V3.0.3.32900 Firebird 3.0
free(): invalid size
make[4]: *** [make.rules:85: /<>/temp/Release/yvalve/blob.cpp]
Aborted
make[4]: *** Deleting file '/<>/temp/Release/yvalve/blob.cpp'
===
So this will need more work, but please keep the bug open so either
myself or other people can investigate.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Based on patch:
From 1e8e7858db84750a77006d307bf28e9686f9414e Mon Sep 17 00:00:00 2001
From: AlexPeshkoff <alexander.peshk...@gmail.com>
Date: Wed, 21 Mar 2018 15:19:20 +0300
Subject: [PATCH] Patch for CORE-5779: support for riscv64, also some code fixes related with prior ports
---
configure.ac| 12
src/common/classes/DbImplementation.cpp | 29 -
src/common/common.h | 4
src/include/gen/msgs.h | 2 +-
src/jrd/inf_pub.h | 2 +-
5 files changed, 34 insertions(+), 15 deletions(-)
--- a/configure.ac
+++ b/configure.ac
@@ -251,6 +251,18 @@
libdir=/usr/lib64
;;
+ riscv64*-*-linux*)
+MAKEFILE_PREFIX=linux_riscv64
+INSTALL_PREFIX=linux
+PLATFORM=LINUX
+AC_DEFINE(LINUX, 1, [Define this if OS is Linux])
+EDITLINE_FLG=Y
+SHRLIB_EXT=so
+STD_EDITLINE=true
+STD_ICU=true
+libdir=/usr/lib64
+;;
+
powerpc64le-*-linux*)
MAKEFILE_PREFIX=linux_powerpc64el
INSTALL_PREFIX=linux
--- a/src/common/classes/DbImplementation.cpp
+++ b/src/common/classes/DbImplementation.cpp
@@ -49,6 +49,7 @@
static const UCHAR CpuArm64 = 15;
static const UCHAR CpuPowerPc64el = 16;
static const UCHAR CpuM68k = 17;
+static const UCHAR CpuRiscV64 = 18;
static const UCHAR OsWindows = 0;
static const UCHAR OsLinux = 1;
@@ -89,7 +90,8 @@
"Alpha",
"ARM64",
"PowerPC64el",
- "M68k"
+ "M68k",
+ "RiscV64"
};
const char* operatingSystem[] = {
@@ -116,22 +118,23 @@
// This table lists pre-fb3 implementation codes
const UCHAR backwardTable[FB_NELEM(hardware) * FB_NELEM(operatingSystem)] =
{
-//Intel AMD Sparc PPC PPC64 MIPSEL MIPS ARM IA64 s390 s390x SH SHEB HPPA Alpha ARM64 PowerPC64el
-/* Windows */ 50, 68, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-/* Linux */ 60, 66, 65, 69, 86, 71, 72, 75, 76, 79, 78, 80, 81, 82, 83, 84, 85,
-/* Darwin */ 70, 73, 0, 63, 77, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-/* Solaris */ 0, 0, 30, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-/* HPUX */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 31, 0, 0, 0,
-/* AIX */ 0, 0, 0, 35, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-/* MVS */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-/* FreeBSD */ 61, 67, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-/* NetBSD */ 62, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+//Intel AMD Sparc PPC PPC64 MIPSEL MIPS ARM IA64 s390 s390x SH SHEB HPPA Alpha ARM
Bug#895257: firebird3.0: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: firebird3.0
Version: 3.0.3.32900.ds4-2
Severity: normal
Tags: patch upstream fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
Hello,
We need support in this package for the riscv64 architecture.
There is a patch from upstream:
https://github.com/FirebirdSQL/firebird/commit/1e8e7858db84750a77006d307bf28e9686f9414e
It needs some modifications (file attached) to be applied in the current version
of this package in unstable:
+ removed hunk fixing typo in "encyption", fixed separately (in another
patch of the series applied to the package in Debian)
+ removed extra tab in the second line after "backEndianess" (there are
only two tabs before the last character, a '1' in the line; in the
patch from upstream there are 3, so lines don't match)
+ fixed whitespace in the hunk for configure.ac
+ refresh
The build didn't finish yet, we will confirm later when it works, or will send
further fixes.
It would be great if, upon confirmation that it works, you could include it as a
patch and release a new version for unstable as soon as possible, since there
are very important packages depending on this package (php7, graphviz on php7,
and many packages needing graphviz for their documentation).
If you need any assistance, please let me/us know.
Thanks and cheers.
--
Manuel A. Fernandez Montecelo <m...@debian.org>
>From 1e8e7858db84750a77006d307bf28e9686f9414e Mon Sep 17 00:00:00 2001
From: AlexPeshkoff <alexander.peshk...@gmail.com>
Date: Wed, 21 Mar 2018 15:19:20 +0300
Subject: [PATCH] Patch for CORE-5779: support for riscv64, also some code
fixes related with prior ports
---
configure.ac| 12
src/common/classes/DbImplementation.cpp | 29 -
src/common/common.h | 4
src/include/gen/msgs.h | 2 +-
src/jrd/inf_pub.h | 2 +-
5 files changed, 34 insertions(+), 15 deletions(-)
--- a/configure.ac
+++ b/configure.ac
@@ -251,6 +251,18 @@
libdir=/usr/lib64
;;
+ riscv64*-*-linux*)
+MAKEFILE_PREFIX=linux_riscv64
+INSTALL_PREFIX=linux
+PLATFORM=LINUX
+AC_DEFINE(LINUX, 1, [Define this if OS is Linux])
+EDITLINE_FLG=Y
+SHRLIB_EXT=so
+STD_EDITLINE=true
+STD_ICU=true
+libdir=/usr/lib64
+;;
+
powerpc64le-*-linux*)
MAKEFILE_PREFIX=linux_powerpc64el
INSTALL_PREFIX=linux
--- a/src/common/classes/DbImplementation.cpp
+++ b/src/common/classes/DbImplementation.cpp
@@ -49,6 +49,7 @@
static const UCHAR CpuArm64 = 15;
static const UCHAR CpuPowerPc64el = 16;
static const UCHAR CpuM68k = 17;
+static const UCHAR CpuRiscV64 = 18;
static const UCHAR OsWindows = 0;
static const UCHAR OsLinux = 1;
@@ -89,7 +90,8 @@
"Alpha",
"ARM64",
"PowerPC64el",
- "M68k"
+ "M68k",
+ "RiscV64"
};
const char* operatingSystem[] = {
@@ -116,22 +118,23 @@
// This table lists pre-fb3 implementation codes
const UCHAR backwardTable[FB_NELEM(hardware) * FB_NELEM(operatingSystem)] =
{
-// Intel AMD Sparc PPC
PPC64 MIPSEL MIPSARM IA64s390s390x SH
SHEBHPPAAlpha ARM64 PowerPC64el
-/* Windows */ 50, 68, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0,
-/* Linux */60, 66, 65, 69,
86, 71, 72, 75, 76,
79, 78, 80, 81, 82, 83,
84, 85,
-/* Darwin */ 70, 73, 0, 63,
77, 0, 0, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0,
-/* Solaris */ 0, 0, 30, 0,
0, 0, 0, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0,
-/* HPUX */ 0, 0, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0, 0, 31,
0, 0, 0,
-/* AIX */ 0, 0, 0,
35, 0, 0, 0, 0,
0, 0,
Bug#894995: rdma-core: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: rdma-core Version: 17.1-1 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, The current version of this package doesn't build for the riscv64 port. First it fails to be considered to build (due to missing valgrind) and, when fixing that problem, FBTFS, because of missing files (see at bottom). I applied the same fix as for many other arches, which is to add the arch to the list of NO_COHERENT_DMA_ARCHS in debian/rules. I am not sure if support could be added at a later date, but for the time being, seems to be the best way to get it working -- I don't know enough details of the architecture or the assembly language to get the necessary incantations in place. So please, consider to apply the patch attached, to add support for the new architecture. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org> === make[1]: Entering directory '/<>' dh_install --fail-missing -X"etc/init.d/srpd" -X"usr/sbin/run_srp_daemon" -X"usr/sbin/srp_daemon.sh" dh_install: Please use dh_missing --list-missing/--fail-missing instead dh_install: This feature will be removed in compat 12. dh_install: Cannot find (any matches for) "etc/modprobe.d/mlx4.conf" (tried in ., debian/tmp) dh_install: rdma-core missing files: etc/modprobe.d/mlx4.conf dh_install: Cannot find (any matches for) "usr/lib/*/libmlx4.so.*" (tried in ., debian/tmp) dh_install: ibverbs-providers missing files: usr/lib/*/libmlx4.so.* dh_install: Cannot find (any matches for) "usr/lib/*/libmlx5.so.*" (tried in ., debian/tmp) dh_install: ibverbs-providers missing files: usr/lib/*/libmlx5.so.* dh_install: Cannot find (any matches for) "usr/include/infiniband/mlx4dv.h" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/include/infiniband/mlx4dv.h dh_install: Cannot find (any matches for) "usr/include/infiniband/mlx5dv.h" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/include/infiniband/mlx5dv.h dh_install: Cannot find (any matches for) "usr/lib/*/libmlx4.so" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/lib/*/libmlx4.so dh_install: Cannot find (any matches for) "usr/lib/*/libmlx5.so" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/lib/*/libmlx5.so dh_install: Cannot find (any matches for) "usr/share/man/man3/mlx4dv_*.3" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/share/man/man3/mlx4dv_*.3 dh_install: Cannot find (any matches for) "usr/share/man/man3/mlx5dv_*.3" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/share/man/man3/mlx5dv_*.3 dh_install: Cannot find (any matches for) "usr/share/man/man7/mlx4dv.7" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/share/man/man7/mlx4dv.7 dh_install: Cannot find (any matches for) "usr/share/man/man7/mlx5dv.7" (tried in ., debian/tmp) dh_install: libibverbs-dev missing files: usr/share/man/man7/mlx5dv.7 dh_install: missing files, aborting make[1]: *** [debian/rules:60: override_dh_install] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:10: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 === diff -Nru rdma-core-17.1/debian/changelog rdma-core-17.1/debian/changelog --- rdma-core-17.1/debian/changelog 2018-03-19 13:32:31.0 +0100 +++ rdma-core-17.1/debian/changelog 2018-04-05 22:59:07.0 +0200 @@ -1,3 +1,13 @@ +rdma-core (17.1-1~0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * Add support for riscv64: + - Disable valgrind build-dependency, not available +- Add to NO_COHERENT_DMA_ARCHS in d/rules (FTBFS otherwise, code not + ready yet) + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Thu, 05 Apr 2018 22:59:07 +0200 + rdma-core (17.1-1) unstable; urgency=medium * New upstream bugfix release. diff -Nru rdma-core-17.1/debian/control rdma-core-17.1/debian/control --- rdma-core-17.1/debian/control 2018-03-19 13:30:01.0 +0100 +++ rdma-core-17.1/debian/control 2018-04-05 22:59:07.0 +0200 @@ -12,7 +12,7 @@ ninja-build, pkg-config, python, - valgrind [!alpha !armel !hppa !ia64 !m68k !powerpcspe !sh4 !sparc64 !x32] + valgrind [!alpha !armel !hppa !ia64 !m68k !powerpcspe !sh4 !sparc64 !x32 !riscv64] Standards-Version: 4.1.3 Vcs-Git: https://github.com/linux-rdma/rdma-core.git Vcs-Browser: https://github.com/linux-rdma/rdma-core diff -Nru rdma-core-17.1/debian/rules rdma-core-17.1/debian/rules --- rdma-core-17.1/debian/rules 2018-03-19 13:30:01.0 +0100 +++ rdm
Bug#894987: libtommath: FBTFS in riscv64: Please increase the time for timeout of "testme.sh"
Source: libtommath Version: 1.0.1-1 Severity: normal Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, The version of the package currently FBTFS on the riscv64 port, due to insufficient time for timeout when running testme.sh (it's running under qemu-system VMs at the moment): https://buildd.debian.org/status/fetch.php?pkg=libtommath=riscv64=1.0.1-1=1522960928=0 ... echo "running auto_test" running auto_test # this script runs "make clean" so it cannot be run after build /bin/bash testme.sh uname=Linux rv-mit-04 4.15.0_riscv-linux-4.15_2b0aa1de4+ #1 SMP Wed Mar 28 12:36:27 UTC 2018 riscv64 GNU/Linux gcc=7 Compile gcc Run test gcc error 124 while running tests assuming timeout while running test - continue 1 tests timed out make[1]: *** [debian/rules:26: override_dh_auto_build] Error 1 I tried with this simple change and it works (it took less than 6 minutes for sure, but I wasn't looking all the time, setting 900 for safe measure): + sed -i '/timeout --foreground 90/ s/ 90/ 900/g' testme.sh /bin/bash testme.sh (I set +patch tag because a fix is provided, but if you prefer a more formal patch please tell me) I think that it would be nice if you could increase the timeout, so other ports in the future don't find themselves in the same situation, if forced to use qemu-system or some other reason that makes them slow. Failing in 5, 10 or 15 minutes is not too long to wait IMO, and when it works in faster architectures, there's no penalty for them. Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#892983: [Aptitude-devel] Bug#892983 + Bug#892984: please allow filtering on/displaying the release 'label'/'suite'
Hi Thomas, 2018-04-02 15:51 GMT+02:00 Tomas Pospisek <tpo_...@sourcepole.ch>: > Hi Manuel, > > I want to ping you on this wishlist ticket. > > I do not want to stress you out: you have your own life and priorities, just > as everybody else, full respect for that. > > However sometimes stuff falls through the cracks, that's why I'm pinging you > on this. >[...] I couldn't look into this yet, if you're a reader of planet-debian you might guess why :) I still plan to look at this in the next days/weeks. We need a more immediate action for cwidget and aptitude though, which is to fix an incompatibility with the release of ncurses that it's about to enter unstable. Feel free to ping me again if I didn't reply in 2-3 weeks! Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#891161: cwidget: FTBFS with libncursesw6
2018-03-31 20:20 GMT+02:00 Sven Joachim <svenj...@gmx.de>: > On 2018-03-31 19:56 +0200, Manuel A. Fernandez Montecelo wrote: > >> I think shlib bumping is a better plan than waiting for an unknown >> time in the NEW queue, although for new binary package names it's >> usually a short wait. > > If you have a libcwidget4 package ready, don't hesitate to upload it to > experimental. This gives me at least something to show in bug #894049, > where I haven't received a reply yet. I don't have it ready, but I imagine that it's not too much work either way. I wanted to include other changes in parallel, but didn't have time to prepare it. So I think that shlib bumping is a better route at this point. About copying to #894049, I tought about replying to that bug report instead, to show RMs that we're ready to go. Feel free to point to it, or tell me and I will reply to the other bug myself. >> So I have to wait to upload cwidget until the new ncurses gets the >> green light and enters unstable, right? > > For uploads to unstable, yes. This holds for both plans (SONAME change or > shlibs bump + Breaks against aptitude). Right, so I can prepare this within a day, for both cwidget and aptitude. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#891161: cwidget: FTBFS with libncursesw6
Hi, 2018-03-26 1:54 GMT+02:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: >> I intend to file a transition bug for ncurses tomorrow. If you can >> finish the changes for libcwidget4 until Easter, that's probably >> sufficiently early, but I have also come up with a backup plan: declare >> a versioned Breaks against aptitude and bump shlibs in libcwidget3v5. >> This requires uploads for both cwidget and aptitude, but does not need >> to through NEW. >> >> See these branches for cwidget and aptitude: >> https://salsa.debian.org/joachim-guest/cwidget/commits/ncurses6 >> https://salsa.debian.org/joachim-guest/aptitude/commits/ncurses6 > > That's good. Sorry for not being more responsive, but I am massively > snowed under. > > I was leaving this precisely for Easter, because I have like 5 days of > holidays in total :) I think shlib bumping is a better plan than waiting for an unknown time in the NEW queue, although for new binary package names it's usually a short wait. So I have to wait to upload cwidget until the new ncurses gets the green light and enters unstable, right? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#891799: openssl1.0: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2018-03-26 21:01 GMT+02:00 Sebastian Andrzej Siewior <sebast...@breakpoint.cc>: > On 2018-02-28 23:38:44 [+0100], Manuel A. Fernandez Montecelo wrote: >> Hello, > Hi, > >> We need support in this package for RISC-V, to bootstrap the riscv64 >> architecture. > > Please be aware that we plan to get rid of this. Yep, but there are still more than a hundred dependencies, incl. important things like openssh and curl... >> I am attaching a patch that allowed me to cross-compile the package. I am >> not >> completely sure if all of the options are the most correct or the best choice >> (more optimised), for example I used DES_RISC2 because the MIPS family uses >> those and it's probably the closest to RISC-V, so it's my best-guess. But if >> you spot something fishy, please tell. > > for the reason above I would care too much about this package on your > side. Make sure the test suite passes and you should be good. True. Yeah, the test suite ran fine :) >> It would be great if you could include these changes and release a new >> version >> for unstable. > > There should be a new upstream version this week. This change should be > part of it. Great timing, we just added the arch to debian-ports, so maybe we don't even need to upload to "unreleased". >> If we can do something to speed-up this process, please let me/us know. > > I do accept a bribe. :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
