Bug#1067312: spirv-tools: FTBFS: operand.kinds-unified1.inc:566:97: error: ‘SPV_OPERAND_TYPE_NAMED_MAXIMUM_NUMBER_OF_REGISTERS’ was not declared in this scope
Hi, On Wed, 20 Mar 2024 21:58:27 +0100 Lucas Nussbaum wrote:> During a rebuild of all packages in sid, your package failed to build on amd64. I'm having the same problem. As a data point, builds succeeds as soon as I revert spirv-headers to 1.6.1+1.3.275.0-1. HTH, Gio.
Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
Hi, On Thu, 18 Aug 2022 15:32:41 +0200 Giovanni Mascellani wrote:> If you still have version 1.1.34 (or downgrade), then everything will work and the output file output.boostbook will be generated (a couple of warnings will be printed, but they are not problematic; or, at least, they are a different problem). As a further step, I bisected libxslt and determined that the regression (if it is a regression) is caused by commit [1], which claims to solve [2]. Apparently libxslt was evaluating XSLT templates in the wrong order, and that commit fixed that, but I guess that boostbook depended on that order to work properly. [1] https://gitlab.gnome.org/GNOME/libxslt/-/commit/b0074eeca3c6b21b4da14fdf712b853900c51635 [2] https://gitlab.gnome.org/GNOME/libxslt/-/issues/55 Giovanni.
Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
Il 12/08/22 21:32, Giovanni Mascellani ha scritto: Thanks for filing the bug. It seems that Boost builds fine with xsltproc and libxslt1version 1.1.34 (instead of 1.1.35 currently in sid). I am not an XSLT master and it seems that nobody upstream has noticed yet, maybe because 1.1.35 is still relatively recent. I'll file a bug upstream to see if they can work out a solution. I sent an email to the Boost development mailing list[1], which is unfortunately not getting any attention for the moment. [1] https://lists.boost.org/Archives/boost/2022/08/253369.php In the meantime, I also created a minimal test case, so that somebody who knows about XSLT can look at that without having to deal with the Boost building system. In order to reproduce the bug, you have to: 1. Download the attached reproduce.tar.gz 2. Extract it in /tmp. You can also use another directory, but then you have to fix an absolute path, se below. 3. Install docbook-xml, docbook-xsl and xsltproc. 4. If you didn't extract in /tmp, edit the absolute path in reproduce/boostbook/boostbook_catalog.xml appropriately. 5. Go to /tmp/reproduce, or wherever you extracted it, and launch ./execute.sh (which is just a wrapper over the appropriate xsltproc command line). If you already have xsltproc and libxslt1.1 version 1.1.35, then you will see a lot of errors of this form: runtime error: file boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName. If you still have version 1.1.34 (or downgrade), then everything will work and the output file output.boostbook will be generated (a couple of warnings will be printed, but they are not problematic; or, at least, they are a different problem). If anybody knows how to fix libxslt or the boostbook XSLTs, then please let me know! Thanks, Giovanni. -- Giovanni Mascellani reproduce.tar.gz Description: application/gzip
Bug#1016321: boost1.74: FTBFS: runtime error: file /<>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
Hi, Il 29/07/22 20:32, Lucas Nussbaum ha scritto: During a rebuild of all packages in sid, your package failed to build on amd64. Thanks for filing the bug. It seems that Boost builds fine with xsltproc and libxslt1version 1.1.34 (instead of 1.1.35 currently in sid). I am not an XSLT master and it seems that nobody upstream has noticed yet, maybe because 1.1.35 is still relatively recent. I'll file a bug upstream to see if they can work out a solution. Giovanni.
Bug#1000506: boost1.71 FTBFS with Python 3.10
Hi, On 24/11/21 12:53, Adrian Bunk wrote: Source: boost1.71 Version: 1.71.0-7+b3 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=boost1.71&ver=1.71.0-7%2Bb3 ... libs/python/src/exec.cpp:109:14: error: ‘_Py_fopen’ was not declared in this scope; did you mean ‘_Py_wfopen’? 109 | FILE *fs = _Py_fopen(f, "r"); | ^ | _Py_wfopen ... Thanks for reporting this. Ideally the best way to fix this bug would be to get rid of boost1.71, given that boost1.74 already exists (also, a new version should be packaged, but that's another story). Giovanni. -- Giovanni Mascellani
Bug#995162: cannot install together with i386
Hi Mattia, Il 29/09/21 19:28, Mattia Rizzolo ha scritto: This is triggered by the binNMU, which varies the date of the changelog, so that dh_strip_nondeterminism will normalize the metadata of the .png to the binNMU build time instead of the time of the source upload as it was before. Thanks for the info. Unless I am mistaken, this means that any package which installs a shared PNG breaks at every binNMU, unless the binNMU is for all architectures. Wouldn't it be better if dh_strip_nondeterminism used the last sourceful upload as reference timestamp? Was this option considered? Thanks, Giovanni. -- Giovanni Mascellani
Bug#962320: facter crashes with "free(): invalid pointer"
Il 13/06/20 11:05, Giovanni Mascellani ha scritto: > No problems in line of principle, but I am not sure I understand what > would this solve: the conflict between two different versions of Boost > arises when the same executable links against both (through different > dependencies). There is no problem in having both versions installed at > the same time. > > So, given that we have to make sure that bullseye packages link only > against 1.71 (or whatever it will be, but just one version), what is to > be gained by having the Break: indication? Ping? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#960379: FTBFS again
Bitcoin is FTBFSing again because of a missing dependency on bsdextrautils (from which hexdump is used). Therefore I am uploading another NMU fixing this. I am not delaying it, since I had no objections on the first NMU and I believe this one to be uncontroversial. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Il 20/06/20 19:01, Mike Gabriel ha scritto: > Thanks for patching libzypp. Your NMU is ok, I will include your > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > zypper in Debian. Do you have interest in taking over? Ugh, I just realized I stupidly embedded the amd64 architecture in my patch, leading to obvious FTBFS on the other archs. It is ok for you if I directly NMU libzypp replacing x86_64-linux-gnu with $(DEB_HOST_MULTIARCH)? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Il 20/06/20 19:01, Mike Gabriel ha scritto: > Thanks for patching libzypp. Your NMU is ok, I will include your > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > zypper in Debian. Do you have interest in taking over? No, I have no interest. Actually, I barely know what they do: I am just doing some RC sniping. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Control: tags 949196 + patch
Control: tags 949196 + pending
Dear maintainer,
I've prepared an NMU for libzypp (versioned as 17.7.0-1.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.
Regards.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
diff -Nru libzypp-17.7.0/debian/changelog libzypp-17.7.0/debian/changelog
--- libzypp-17.7.0/debian/changelog 2018-09-17 13:31:02.0 +0200
+++ libzypp-17.7.0/debian/changelog 2020-06-20 16:35:50.0 +0200
@@ -1,3 +1,12 @@
+libzypp (17.7.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around broken libsolv detection (closes: #949196).
+ * Fix build with Boost 1.71.
+ * Treat libxml as a C++ library.
+
+ -- Giovanni Mascellani Sat, 20 Jun 2020 16:35:50 +0200
+
libzypp (17.7.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch
--- libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch 2020-06-20 16:35:50.0 +0200
@@ -0,0 +1,69 @@
+From 40e772a952ed8b0525430bca6a226e054826c662 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Wed, 28 Nov 2018 16:56:15 +0100
+Subject: [PATCH] Need to explitily cast of Tribool to boolean
+
+Only explicit casts are allowed as of Boost 1.69
+---
+ zypp/RepoInfo.cc | 8
+ zypp/RepoManager.cc| 2 +-
+ zypp/repo/Applydeltarpm.cc | 2 +-
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/zypp/RepoInfo.cc b/zypp/RepoInfo.cc
+index 0a3575bc8..db230c727 100644
+--- a/zypp/RepoInfo.cc
b/zypp/RepoInfo.cc
+@@ -387,11 +387,11 @@ namespace zypp
+
+
+ bool RepoInfo::repoGpgCheck() const
+- { return gpgCheck() || _pimpl->cfgRepoGpgCheck(); }
++ { return gpgCheck() || bool(_pimpl->cfgRepoGpgCheck()); }
+
+ bool RepoInfo::repoGpgCheckIsMandatory() const
+ {
+-bool ret = ( gpgCheck() && indeterminate(_pimpl->cfgRepoGpgCheck()) ) || _pimpl->cfgRepoGpgCheck();
++bool ret = ( gpgCheck() && indeterminate(_pimpl->cfgRepoGpgCheck()) ) || bool(_pimpl->cfgRepoGpgCheck());
+ if ( ret && _pimpl->internalUnsignedConfirmed() ) // relax if unsigned repo was confirmed in the past
+ ret = false;
+ return ret;
+@@ -402,10 +402,10 @@ namespace zypp
+
+
+ bool RepoInfo::pkgGpgCheck() const
+- { return _pimpl->cfgPkgGpgCheck() || ( gpgCheck() && !bool(validRepoSignature())/*enforced*/ ) ; }
++ { return bool(_pimpl->cfgPkgGpgCheck()) || ( gpgCheck() && !bool(validRepoSignature())/*enforced*/ ) ; }
+
+ bool RepoInfo::pkgGpgCheckIsMandatory() const
+- { return _pimpl->cfgPkgGpgCheck() || ( gpgCheck() && indeterminate(_pimpl->cfgPkgGpgCheck()) && !bool(validRepoSignature())/*enforced*/ ); }
++ { return bool(_pimpl->cfgPkgGpgCheck()) || ( gpgCheck() && indeterminate(_pimpl->cfgPkgGpgCheck()) && !bool(validRepoSignature())/*enforced*/ ); }
+
+ void RepoInfo::setPkgGpgCheck( TriBool value_r )
+ { _pimpl->rawPkgGpgCheck( value_r ); }
+diff --git a/zypp/RepoManager.cc b/zypp/RepoManager.cc
+index dbcf7a1b5..ad53013fe 100644
+--- a/zypp/RepoManager.cc
b/zypp/RepoManager.cc
+@@ -2243,7 +2243,7 @@ namespace zypp
+
+ // Make sure the service repo is created with the appropriate enablement
+ if ( ! indeterminate(toBeEnabled) )
+- it->setEnabled( toBeEnabled );
++ it->setEnabled( ( bool ) toBeEnabled );
+
+ DBG << "Service adds repo " << it->alias() << " " << (it->enabled()?"enabled":"disabled") << endl;
+ addRepository( *it );
+diff --git a/zypp/repo/Applydeltarpm.cc b/zypp/repo/Applydeltarpm.cc
+index 7b382be9b..0a1b8ad7e 100644
+--- a/zypp/repo/Applydeltarpm.cc
b/zypp/repo/Applydeltarpm.cc
+@@ -82,7 +82,7 @@ namespace zypp
+ else
+ WAR << "No executable " << prog << endl;
+ }
+- return _last;
++ return ( bool ) _last;
+ }
+
+ /**
diff -Nru libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch
--- libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch 2020-06-20 16:35:50.0 +0200
@@ -0,0 +1,24 @@
+From 867c6b3190dafcd07f0ac5d8eef39268cc925141 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Tue, 27 Nov 2018 15:45:43 +0100
+Subject: [PATCH] Boost.Tribool requir
Bug#922579: FTBFS against opencv 4.0.1 (exp)
Control: block 962950 by -1 On Tue, 23 Apr 2019 14:13:22 + (GMT) Chiara Marmo wrote: > Hi, > > sorry, I'm a bit confused about this bug. > > This is a problem with opencv4 in experimental distribution, right? > Not with power pc architecture... No, the same thing definitely happens on amd64 as well. I tried adding a "-I/usr/include/opencv4" to the compiler command line to see if the same code worked with OpenCV 4, but apparently it does not. It is probably necessary to manually port the code to the new version. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#936483: Possible fix
Il 19/06/20 16:51, Giovanni Mascellani ha scritto: > Basically I am replacing PyInt_Check with PyLong_Check, under the > assumption that "long" is the new name of "int" in Python 3. This > assumptions is corroborated by PyGame having this line in > /usr/include/python3.8m/pygame/pgcompat.h: > > #define PyInt_Check(op) PyLong_Check(op) > > That said, I wouldn't mind some competent Python developer to review the > patch. Comparing with [1], it seems my patch is ok. https://github.com/enki-community/enki/commit/db813cdb7b669231b6670ccc9ee8f562aed29807 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#960379: bitcoin: diff for NMU version 0.18.1~dfsg-1.1
Control: tags 960379 + patch
Control: tags 960379 + pending
Dear maintainer,
I've prepared an NMU for bitcoin (versioned as 0.18.1~dfsg-1.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.
Regards.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
diff -Nru bitcoin-0.18.1~dfsg/debian/changelog bitcoin-0.18.1~dfsg/debian/changelog
--- bitcoin-0.18.1~dfsg/debian/changelog 2019-08-19 11:50:52.0 +0200
+++ bitcoin-0.18.1~dfsg/debian/changelog 2020-06-19 18:20:38.0 +0200
@@ -1,3 +1,10 @@
+bitcoin (0.18.1~dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS with new Univalue interface (closes: #960379).
+
+ -- Giovanni Mascellani Fri, 19 Jun 2020 18:20:38 +0200
+
bitcoin (0.18.1~dfsg-1) unstable; urgency=medium
[ upstream ]
diff -Nru bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch
--- bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch 1970-01-01 01:00:00.0 +0100
+++ bitcoin-0.18.1~dfsg/debian/patches/0006-Fix-FTBFS-with-new-Univalue-Interface.patch 2020-06-19 18:20:38.0 +0200
@@ -0,0 +1,21 @@
+From: Giovanni Mascellani
+Date: Wed, 17 Jun 2020 19:05:43 +0200
+Subject: Fix FTBFS with new Univalue Interface.
+
+---
+ src/rpc/blockchain.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
+index bd35163..52fcd3c 100644
+--- a/src/rpc/blockchain.cpp
b/src/rpc/blockchain.cpp
+@@ -2198,7 +2198,7 @@ UniValue scantxoutset(const JSONRPCRequest& request)
+ // no scan in progress
+ return NullUniValue;
+ }
+-result.pushKV("progress", g_scan_progress);
++result.pushKV("progress", int(g_scan_progress));
+ return result;
+ } else if (request.params[0].get_str() == "abort") {
+ CoinsViewScanReserver reserver;
diff -Nru bitcoin-0.18.1~dfsg/debian/patches/series bitcoin-0.18.1~dfsg/debian/patches/series
--- bitcoin-0.18.1~dfsg/debian/patches/series 2019-08-19 11:50:52.0 +0200
+++ bitcoin-0.18.1~dfsg/debian/patches/series 2020-06-19 18:20:38.0 +0200
@@ -3,3 +3,4 @@
1003_man_proper_header.patch
2001_avoid_embedded_libs.patch
2002_avoid_network_tests.patch
+0006-Fix-FTBFS-with-new-Univalue-Interface.patch
Bug#936483: Possible fix
Hi, the attached patch seems to fix the FTBFS with Python 3. I am not completely sure it is the right fix, though, meaning that the package compiles with my patch, but I am not sure the logic is correct. Basically I am replacing PyInt_Check with PyLong_Check, under the assumption that "long" is the new name of "int" in Python 3. This assumptions is corroborated by PyGame having this line in /usr/include/python3.8m/pygame/pgcompat.h: #define PyInt_Check(op) PyLong_Check(op) That said, I wouldn't mind some competent Python developer to review the patch. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles diff --git a/python/enki.cpp b/python/enki.cpp index b18e6ea..216ae41 100644 --- a/python/enki.cpp +++ b/python/enki.cpp @@ -105,11 +105,11 @@ struct Vector_from_python PyObject* item0(PyTuple_GetItem(objPtr, 0)); assert (item0); - if (!(PyFloat_Check(item0) || PyInt_Check(item0))) + if (!(PyFloat_Check(item0) || PyLong_Check(item0))) return 0; PyObject* item1(PyTuple_GetItem(objPtr, 1)); assert (item1); - if (!(PyFloat_Check(item1) || PyInt_Check(item1))) + if (!(PyFloat_Check(item1) || PyLong_Check(item1))) return 0; } else @@ -120,11 +120,11 @@ struct Vector_from_python PyObject* item0(PyList_GetItem(objPtr, 0)); assert (item0); - if (!(PyFloat_Check(item0) || PyInt_Check(item0))) + if (!(PyFloat_Check(item0) || PyLong_Check(item0))) return 0; PyObject* item1(PyList_GetItem(objPtr, 1)); assert (item1); - if (!(PyFloat_Check(item1) || PyInt_Check(item1))) + if (!(PyFloat_Check(item1) || PyLong_Check(item1))) return 0; } signature.asc Description: OpenPGP digital signature
Bug#962320: facter crashes with "free(): invalid pointer"
Hi, Il 09/06/20 17:06, Adrian Bunk ha scritto: > For avoiding similar problems for people upgrading from buster, > it would be good if for both 1.71 and whatever version of Boost > will be released in Buster the library packages will add a Breaks: > on the corresponding libboost-*1.67.0 package. No problems in line of principle, but I am not sure I understand what would this solve: the conflict between two different versions of Boost arises when the same executable links against both (through different dependencies). There is no problem in having both versions installed at the same time. So, given that we have to make sure that bullseye packages link only against 1.71 (or whatever it will be, but just one version), what is to be gained by having the Break: indication? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#875584: Can jhdf be uploaded?
Apparently jhdf has a patch committed in Salsa which would fix a FTBFS (which currently prevents hdfview from installing in sid). Is there are reason for not uploading it? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Il 08/01/20 00:14, Andreas Beckmann ha scritto: > since python2.7 is back in boost-python and my shlibs patch is in, too, > I've requested a "transition" to get the binNMUs done to tighten the > boost-python dependencies: https://bugs.debian.org/948378 Great, thanks. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Hi, Il 06/01/20 13:54, Andreas Beckmann ha scritto: > This bug is not about the python2 removal. This bug is about removing a > shared library without doing a proper transition, i.e. renaming the > package (which will happen with boost1.71) or adding a bunch of Breaks. > The same will happen again once python3.7 gets removed and only > python3.8 remains as a supported version. (Similar bugs happened during > the python3.6->python3.7 switch and prompted for the introduction of > some virtual packages) I agree. > To simplify such future transitions, I created a patch (#948273) to > actually make use of the virtual packages introduced in -12. > Please include it along with the reintroduction of python2 support in > *sid*. Then we can binNMU all rdepends of libboost-python1.67.0, > libboost-mpi-python1.67.0, libboost-numpy1.67.0 to add more strict > dependencies on the required python support. So, if I get this right, the point of binNMU-ing is to make sure that all the rev deps choose their versioned dependency, so that when a Python version goes away the breakage will be recorded in the packages dependencies (and won't be an actual breakage). Is this right? And then you need to have Boost.Python with Python 2.7 back because otherwise binNMUs will just fail, right? If so, then I agree. If not, please explain me, because I am still learning this kind of things. > For the transition to boost1.71 it would be best if that happens before > python3.8 is the only supported python3 and we can thus remove a > boost1.67 still supporting python2.7 and python3.7 from sid. Why this? Anyway, I started filing bugs for transitioning to Boost 1.71[1]. It will take some time, though. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org&tag=boost1.71 > In the unlikely event that bullseye should ship boost1.67 (along 1.71+), > we need to reinvestigate this to ensure partial upgrades from buster to > bullseye don't break anything. Probably renaming the three binary > packages to get a -python3 suffix would be easiest. Again, I am not sure of what is actually going on here, but I really hope this will not happen. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Hi, Il 03/01/20 22:07, Adrian Bunk ha scritto: > Dimitri already agreed in a private discussion that this change was bogus. > > Are there any objections against an NMU reverting the bogus Python 2 > removal in boost1.67? Totally agree that there is no reason to remote Python 2 support from boost1.67. Please do the NMU. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Il 05/12/19 22:37, Dimitri John Ledkov ha scritto: > All python2 bugs for leaf packages have been made RC on like 30th of > november, causing a tonne of packages to be scheduled for autoremoval. > Most of them are on 18th/19th December. See tracker.d.o for various > leaf packages. That's only from testing. I still believe that unstable should not be broken if it can be avoided at nearly zero cost. However, I see your point now. I think disabling Python 2 should have been handled differently (i.e., not disabling it in Boost before all the rev deps in unstable wouldn't use it any more), but let's call it a day and avoid uselessly escalating this. I will not re-enable Python 2 in boost1.67. Thanks for working on this anyway. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Il 05/12/19 22:15, Dimitri John Ledkov ha scritto:>> Also, I hope to finish working on 1.71 as soon as possible, so that we >> can start that migration. > > But 1.71 for sure will not have python2 bindings enabled. Thus > re-enabling python2 in boost is a stopgap until December 18th when > those reverse-deps will be removed from testing anyway. Wait, where does this date (December 18th) come from? Will all Python 2 packages get deleted on that date? Is this documented anywhere? If it is already decided that Python 2 is going away very soon anyway (I didn't know this and I cannot find it written anywhere), then I agree there is no reason to re-enable Python 2. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, Il 05/12/19 17:55, Dimitri John Ledkov ha scritto: > In principal I agree, in practice the only broken app today is ledger, > which should have by now uploaded without a python bridge enabled; or > build with python3 bridge as now available from upstream master (ported > by me after this issue was filed / escalated). Thanks for working on ledger, but it is not the only affected application. At least mirage is affected too. Are you sure there are not others? How? > And no, unstable is not supported and frequently has uninstallable > packages, multiple known regressions, RC bugs, and automated autopkgtest > regressions. One should only dist-upgrade unstable packages they use, if > they are ok with the RC bugs and autopkgtest regressions automatically > identified in the builds anyway. Thus no, I will not be making > incremental uploads, to temporarily unbreak unstable users, using hacks > which are not the way we intend to ship in testing later as that is > added churn and drag on the development (ie. port/rebuild ledger in this > case). I don't agree. I ordinarily use unstable and usually everything runs fine. There are breakages every now and then, and I know that if unstable breaks I keep the pieces. But this does not mean that one should do that on purpose. There can be situations in which this is unavoidable, but clearly this is not one of those: there is not harm in keeping Python 2 enabled as long as users are still using it. Therefore I will upload a new version of boost1.67 temporarily reverting your patch. By the way, I don't think that boost1.67 will go in bullseye anyway: I hope to get rid of it well before that. So the point here is not getting the package in shape for the release; it is just avoid making the life of unstable's users unnecessarily complicated. Also, I hope to finish working on 1.71 as soon as possible, so that we can start that migration. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, Il 01/12/19 23:33, Dimitri John Ledkov ha scritto: > All the broken packages, are RC buggy themselves already. Anything that > is using py2 is RC buggy. I'm sorry, but this does not look like the way Python maintainers asked to deal with reverse dependencies: from [1] it is clear that you should not remove Python 2 support if you have reverse dependencies using it. The right way is to keep Python 2 and make the rev dep's bug affect #936227. [1] https://wiki.debian.org/Python/2Removal People are using unstable. I agree with the principle that Python 2 applications should disappear as soon as possible, but breaking things randomly is not going to do any good. Please, if you see a mistake in my reasoning explain me, otherwise I will re-enable Python 2 support for 1.67.0 in Debian (I have no idea about policies in Ubuntu) until reverse dependencies are clean. Incidentally, it seems that ledger does not have any Python 2 removal related bug. I would file one. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory
Hi, On Fri, 29 Nov 2019 16:42:58 +0100 Kiko Piris wrote:> /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory Dimitri, it seems that removing Python 2 support for Boost 1.67 was a bit too quick. Apparently some packages are still using it, so this is causing breakages. Therefore I will upload a new version that re-enables Python 2. Of course Python 2 should never be enabled from Boost 1.71 on. Also, could you please check that you pushed 1.67.0-15 to the git repository? I cannot see it. Of course, reverse dependencies of Boost 1.67 be aware that you will break when 1.71 will be made the default Boost version, which hopefully will be relatively soon. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#915270: NMU patch for version 0.3.4-2+deb9u1
Hi, I prepared an NMU for stretch as well. The patch is essentially the same, but I am attaching it again. If the maintainer does not oppose, I will file a bug against release.debian.org for updating the stretch version. Thanks, Giovanni. Il 05/08/19 18:02, Santiago Vila ha scritto: > reopen 915270 > found 915270 0.3.4-2 > fixed 915270 0.3.4-3.1 > thanks > > Hi. > > Could we please fix this in stretch as well? (Packages in buster must > build in buster, packages in stretch must build in stretch). > > Would your diff apply cleanly to the version in stretch? > (I have not tested this yet). > > Thanks. > -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles diff -Nru libgovirt-0.3.4/debian/changelog libgovirt-0.3.4/debian/changelog --- libgovirt-0.3.4/debian/changelog 2016-04-24 07:02:46.0 +0200 +++ libgovirt-0.3.4/debian/changelog 2019-08-17 18:15:01.0 +0200 @@ -1,3 +1,11 @@ +libgovirt (0.3.4-2+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * Regenerate test certificates with expiration date far in the future to + fix test failures (closes: #915270). + + -- Giovanni Mascellani Sat, 17 Aug 2019 18:15:01 +0200 + libgovirt (0.3.4-2) unstable; urgency=medium * debian/control.in: Add libglib2.0-dev and librest-dev to the libgovirt-dev diff -Nru libgovirt-0.3.4/debian/patches/series libgovirt-0.3.4/debian/patches/series --- libgovirt-0.3.4/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libgovirt-0.3.4/debian/patches/series 2019-08-17 18:14:30.0 +0200 @@ -0,0 +1 @@ +update_certs diff -Nru libgovirt-0.3.4/debian/patches/update_certs libgovirt-0.3.4/debian/patches/update_certs --- libgovirt-0.3.4/debian/patches/update_certs 1970-01-01 01:00:00.0 +0100 +++ libgovirt-0.3.4/debian/patches/update_certs 2019-08-17 18:14:30.0 +0200 @@ -0,0 +1,269 @@ +From: Giovanni Mascellani +Subject: Regenerate test certificates +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915270 + +Tests fail because test certificates are now expired. This patch +regenerates them with expiration date in a century (I'll remember +to ask my grandchildren to regenerate them before then in my +will). + +Useful information about how to regenerate: https://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/ +(but I doubt my granchildren will be able to still see that +page). + +Index: libgovirt-0.3.4/tests/https-cert/ca-cert.pem +=== +--- libgovirt-0.3.4.orig/tests/https-cert/ca-cert.pem libgovirt-0.3.4/tests/https-cert/ca-cert.pem +@@ -1,32 +1,22 @@ + -BEGIN CERTIFICATE- +-MIIFfzCCA2egAwIBAgIJAJe68wcZuCytMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV +-BAYTAlhYMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkxHDAaBgNVBAoME0RlZmF1bHQg +-Q29tcGFueSBMdGQxEjAQBgNVBAMMCWdvdmlydCBDQTAeFw0xNjA0MTIxNTEyNDFa +-Fw0xOTA0MTIxNTEyNDFaMFYxCzAJBgNVBAYTAlhYMRUwEwYDVQQHDAxEZWZhdWx0 +-IENpdHkxHDAaBgNVBAoME0RlZmF1bHQgQ29tcGFueSBMdGQxEjAQBgNVBAMMCWdv +-dmlydCBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALj2s6YqG9CE +-O7ZxudxjGRSN3rUsnc++p0I+Exo32lsPMD3AXGJ9EwGnXhoRvGnuF2piICZ3CLl2 +-nOH/7Ta8Sb/RuHj67XpJyOhgamM9HULff7ZFXyOrSVyf7YhetCqtx6QhwGfeJ88A +-MsClJmLZ0AkC1rqtIze9r7HCHZCQxkZZHKV0EhF8RaK0oBxjt6MFIru/kzQCXvWT +-t9/RaaxhOdboCtTEmu5oTBQfmKUzl4KT3byYVhdm70MEu/PES1XcgnI2RiHcggrI +-jJ7IknDZTZVK6r0uYLwhBLYA7WsHjRuinTC45dfGcZo0ZTn3khO2Get1negU6wuq +-kkxyc/Su+tU+eH74haW58Xa3DRXlRNHu91ll81W1Wtpi2osDlImIbM/a+FTSTenl +-/bIpPOSqbncvi0yfOoZJhH/u8jgQl3hKVgcA8wYdBj/zcHknldnjeS/k0zI84jOd +-ZrSWL/U7CRGiqJJgRpEKMlggf8Zyh+Lu5Hs6DJrSMG36nbLuukioNCzk7mzMJtOk +-kcE2576RA/1qkYdno06ZHCR7AnOlwvOKusS8ApIti/quQy1COanBYKaiXOJOemZ2 +-n5D3cDsqRk1s/Wj53Ci9KurhGoQOoquRXHv7Z3vzBtZdqZBdwLH3r0pM85a//M6c +-HkDwEDsZNUPlvteDahhMPt2qjJNI1ucVAgMBAAGjUDBOMB0GA1UdDgQWBBTxTMG0 +-4azCV/NN7/DhFI5tVp9t3TAfBgNVHSMEGDAWgBTxTMG04azCV/NN7/DhFI5tVp9t +-3TAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4ICAQA0OOkImczWNwgz/CaB +-mEx6odCM0Kv2ozZ6d8ttsj4w9S3tn0HSR1xM62F/GmO1NfxQXKWTR3xYMou0fQVA +-RskWy/I9WVN/BTD2QSPD9b3fqZvXgi5eMXVeT/1zO2LywV/APLzVl+jbB3WT9J+9 +-1CHyiMNQUUbkIULmE3Z4FPYL30TGbAj4QSIIAbJlHAxRsrTbLXqRXnqw/NxdKdBk +-v1AOvCenu1HcbtWwDnwrIJGt8/igPB5KqsBzHVfcVmvpXUDC1oLf8w8v7nUB55hs +-ZMFyaeEcmc+W2B/JM26npbfTCjST9D6kxBXUhIeu9oJDimfiUqYUaZOuybUM6ZEy +-76vsO8qB06AuA+KhbvBgz8VHveMCnL516VIB8gxThvBgGIe7AQJuDHCy3+oRJ1+k +-kQm04t2k+Gg03ZpgtzbKaOCL6zRFyy5XE8h59/92KyUh804WTiS5MQZLTnqONqS1 +-49BWXgTZgL+PvMr2xzE5ECs3lkcNpO3TvQJB6eSg0X6NQEscQRbTI1qrmszfAov3 +-teQQlwZZHwzXhJxDNAW9u4oaCWbhRsVbYIoDDdvgIeeLozNaQgJkVzQOrSDOcbrk +-4cclYBgxgSAp1wvlje6iUFGGz6Q37GLBhqBTONjIL2ArlizqznGvBbQ/0CO1bij4 +-mePFkPdR8OZWT1+FN6HavKYtPg== ++MIIDlTCCAn2gAwIBAgIUU7iorrGTiREybI5F0KxeT7bSGkwwDQYJKoZIhvcNAQEL ++BQAwWTELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoM ++GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDESMBAGA1UEAwwJZ292aXJ0IENBMCAX ++DTE5MDUyMTEyMj
Bug#915270: libgovirt: diff for NMU version 0.3.4-3.1
Control: tags 915270 + patch Control: tags 915270 + pending Dear maintainer, I've prepared an NMU for libgovirt (versioned as 0.3.4-3.1) and uploaded it to DELAYED/02. Please feel free to tell me if I should delay it longer. Regards, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles diff -Nru libgovirt-0.3.4/debian/changelog libgovirt-0.3.4/debian/changelog --- libgovirt-0.3.4/debian/changelog 2018-12-28 03:33:34.0 +0100 +++ libgovirt-0.3.4/debian/changelog 2019-05-21 14:32:51.0 +0200 @@ -1,3 +1,11 @@ +libgovirt (0.3.4-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Regenerate test certificates with expiration date far in the future to +fix test failures (closes: #915270). + + -- Giovanni Mascellani Tue, 21 May 2019 14:32:51 +0200 + libgovirt (0.3.4-3) unstable; urgency=medium * Bump debhelper compat to 11 diff -Nru libgovirt-0.3.4/debian/patches/series libgovirt-0.3.4/debian/patches/series --- libgovirt-0.3.4/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libgovirt-0.3.4/debian/patches/series 2019-05-21 14:16:12.0 +0200 @@ -0,0 +1 @@ +update_certs diff -Nru libgovirt-0.3.4/debian/patches/update_certs libgovirt-0.3.4/debian/patches/update_certs --- libgovirt-0.3.4/debian/patches/update_certs 1970-01-01 01:00:00.0 +0100 +++ libgovirt-0.3.4/debian/patches/update_certs 2019-05-21 14:32:51.0 +0200 @@ -0,0 +1,269 @@ +From: Giovanni Mascellani +Subject: Regenerate test certificates +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915270 + +Tests fail because test certificates are now expired. This patch +regenerates them with expiration date in a century (I'll remember +to ask my grandchildren to regenerate them before then in my +will). + +Useful information about how to regenerate: https://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/ +(but I doubt my granchildren will be able to still see that +page). + +Index: libgovirt-0.3.4/tests/https-cert/ca-cert.pem +=== +--- libgovirt-0.3.4.orig/tests/https-cert/ca-cert.pem libgovirt-0.3.4/tests/https-cert/ca-cert.pem +@@ -1,32 +1,22 @@ + -BEGIN CERTIFICATE- +-MIIFfzCCA2egAwIBAgIJAJe68wcZuCytMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV +-BAYTAlhYMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkxHDAaBgNVBAoME0RlZmF1bHQg +-Q29tcGFueSBMdGQxEjAQBgNVBAMMCWdvdmlydCBDQTAeFw0xNjA0MTIxNTEyNDFa +-Fw0xOTA0MTIxNTEyNDFaMFYxCzAJBgNVBAYTAlhYMRUwEwYDVQQHDAxEZWZhdWx0 +-IENpdHkxHDAaBgNVBAoME0RlZmF1bHQgQ29tcGFueSBMdGQxEjAQBgNVBAMMCWdv +-dmlydCBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALj2s6YqG9CE +-O7ZxudxjGRSN3rUsnc++p0I+Exo32lsPMD3AXGJ9EwGnXhoRvGnuF2piICZ3CLl2 +-nOH/7Ta8Sb/RuHj67XpJyOhgamM9HULff7ZFXyOrSVyf7YhetCqtx6QhwGfeJ88A +-MsClJmLZ0AkC1rqtIze9r7HCHZCQxkZZHKV0EhF8RaK0oBxjt6MFIru/kzQCXvWT +-t9/RaaxhOdboCtTEmu5oTBQfmKUzl4KT3byYVhdm70MEu/PES1XcgnI2RiHcggrI +-jJ7IknDZTZVK6r0uYLwhBLYA7WsHjRuinTC45dfGcZo0ZTn3khO2Get1negU6wuq +-kkxyc/Su+tU+eH74haW58Xa3DRXlRNHu91ll81W1Wtpi2osDlImIbM/a+FTSTenl +-/bIpPOSqbncvi0yfOoZJhH/u8jgQl3hKVgcA8wYdBj/zcHknldnjeS/k0zI84jOd +-ZrSWL/U7CRGiqJJgRpEKMlggf8Zyh+Lu5Hs6DJrSMG36nbLuukioNCzk7mzMJtOk +-kcE2576RA/1qkYdno06ZHCR7AnOlwvOKusS8ApIti/quQy1COanBYKaiXOJOemZ2 +-n5D3cDsqRk1s/Wj53Ci9KurhGoQOoquRXHv7Z3vzBtZdqZBdwLH3r0pM85a//M6c +-HkDwEDsZNUPlvteDahhMPt2qjJNI1ucVAgMBAAGjUDBOMB0GA1UdDgQWBBTxTMG0 +-4azCV/NN7/DhFI5tVp9t3TAfBgNVHSMEGDAWgBTxTMG04azCV/NN7/DhFI5tVp9t +-3TAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4ICAQA0OOkImczWNwgz/CaB +-mEx6odCM0Kv2ozZ6d8ttsj4w9S3tn0HSR1xM62F/GmO1NfxQXKWTR3xYMou0fQVA +-RskWy/I9WVN/BTD2QSPD9b3fqZvXgi5eMXVeT/1zO2LywV/APLzVl+jbB3WT9J+9 +-1CHyiMNQUUbkIULmE3Z4FPYL30TGbAj4QSIIAbJlHAxRsrTbLXqRXnqw/NxdKdBk +-v1AOvCenu1HcbtWwDnwrIJGt8/igPB5KqsBzHVfcVmvpXUDC1oLf8w8v7nUB55hs +-ZMFyaeEcmc+W2B/JM26npbfTCjST9D6kxBXUhIeu9oJDimfiUqYUaZOuybUM6ZEy +-76vsO8qB06AuA+KhbvBgz8VHveMCnL516VIB8gxThvBgGIe7AQJuDHCy3+oRJ1+k +-kQm04t2k+Gg03ZpgtzbKaOCL6zRFyy5XE8h59/92KyUh804WTiS5MQZLTnqONqS1 +-49BWXgTZgL+PvMr2xzE5ECs3lkcNpO3TvQJB6eSg0X6NQEscQRbTI1qrmszfAov3 +-teQQlwZZHwzXhJxDNAW9u4oaCWbhRsVbYIoDDdvgIeeLozNaQgJkVzQOrSDOcbrk +-4cclYBgxgSAp1wvlje6iUFGGz6Q37GLBhqBTONjIL2ArlizqznGvBbQ/0CO1bij4 +-mePFkPdR8OZWT1+FN6HavKYtPg== ++MIIDlTCCAn2gAwIBAgIUU7iorrGTiREybI5F0KxeT7bSGkwwDQYJKoZIhvcNAQEL ++BQAwWTELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoM ++GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDESMBAGA1UEAwwJZ292aXJ0IENBMCAX ++DTE5MDUyMTEyMjMyMloYDzIxMTkwNDI3MTIyMzIyWjBZMQswCQYDVQQGEwJBVTET ++MBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQ ++dHkgTHRkMRIwEAYDVQQDDAlnb3ZpcnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB ++DwAwggEKAoIBAQCukmY8BbTogh/5cRv5ZOZx2NSUGSK7XufwN6Cbi/m9DufFtTfx ++sQDy9mTNkZOghCcm1DM4Grw6T+d02JUjBFPUyDFmjyQqq2yK7Ew5DcOGY9AgmTC0 ++8T2PLHQ9cZWSAicxKU1+IhSiTiT2uZJ7A1poEILg/txzpH7OiuPV2jMYXwm12gdO ++BhHb+RQMuKKTVmnl9rvmOUu4R5o/J2wgoHNjwHUbY9c2fF3OQK6vee/2UH9ASWhy ++K9qB0C4TD2OBTiU8NuDOw1mN2Wfy7bZmva0uFfHZDqHbMR+CxdPDi0P4XC
Bug#923930: testsuite comes with built-in time-bomb
Hi again, On Mon, 20 May 2019 19:23:40 +0200 Giovanni Mascellani wrote: > If we ignore this and just consider the bug as FTBFS, then it is easy to > patch the package to that failing tests are ignored under 32 bit archs. > Otherwise, the patch might be more complicated; I prodded upstream on > the GitHub issue to understand their intentions. Upstream confirms that an update that handles 32 bit archs is not on the radar soon. I don't know what it is the best way forward now, but if it is decided that it is ok the ignore the error for 32 bit archs, then I can try to cook up the required patch. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#923930: testsuite comes with built-in time-bomb
Hi, On Sun, 7 Apr 2019 16:46:01 +0200 Andreas Henriksson wrote: > The lazy solution here is to argue that we don't want time-bombs and > just disable the test-suite. The better solution involves generating > the certificates so that they align with what 32bit machines can handle, > uuencoding the result and setting up debian/rules handling to "manually > patch" the build. It has to be decided whether the issue, Debian-wise, is the FTBFS or the fact that heimdal does not properly handle dates beyond 2038 in 32 bit archs. I do not have hard data, but I believe that sometimes CAs set their expiration dates even decades in the future, so not verifying certificates expiring after 2038 might be an issue right now, and even more probably the buster's EOL. If we ignore this and just consider the bug as FTBFS, then it is easy to patch the package to that failing tests are ignored under 32 bit archs. Otherwise, the patch might be more complicated; I prodded upstream on the GitHub issue to understand their intentions. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#915319: kde-runtime FTBFS with samba 4.9
Hi, Il 13/04/19 12:27, Ivo De Decker ha scritto: > I would suggest you upload this NMU. If this isn't the right fix, it can > always be reverted. Right. I uploaded as 0-day NMU, with the diff I sent a few emails ago. For the maintainers: the corresponding commits are here: https://salsa.debian.org/gio/kde-runtime (I cannot push to the original repository) Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#912467: Partial triaging
Hi, Il 30/03/19 15:06, Giovanni Mascellani ha scritto: > I can try to devise a patch, but I do not know this API, so if there > is someone more expert at that I would leave it to them. If not, I > can give a try. Using [1] and a partial previous patch by Andrej Shadura as a base, I managed to create a patch that fixes FTBFS on jasperreports, which I pushed to Salsa[2]. I did not test it because I do not know how to do it. It would be nice if other members of the Java team reviewed my work before uploading it, because I am not completely confident with the changes that I made on the POM. [1] https://github.com/TIBCOSoftware/jasperreports/commit/b7bd874137d357e0c27e04d1595086826c38995b [2] https://salsa.debian.org/java-team/jasperreports/commit/90fdfb5a6f1e413ba81f9be56513a92605634350 HTH, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#905697: kdepimlibs: don't depend on libical
user debian-rele...@lists.debian.org
usertags 905697 + bsp-2019-03-fr-paris
thank you
Hi,
On Thu, 14 Feb 2019 10:07:42 +0100 Emilio Pozuelo Monfort
wrote:
> kde-runtime has dozens of rdeps, so unless its dep on kdepimlibs can be broken
> somehow, this would be much harder to solve for buster.
Hoping it might be helpful, I ported kdepimlibs to libical3. This should
finally make us able to remove libical2, I believe. With the attached
patch kdepimlibs compiles, but I did not try to use it (I am not a KDE
user, and much less a KDE PIM user). Could KDE maintainers test it?
My patch was mostly adapted from [1]. I am also attaching another patch
that explicitly sets QT_SELECT to version 4, so that build does not fail
even if Qt 5 is available.
[1]
https://github.com/KDE/kcalcore/commit/27eaa211b23a6bb0bcba5a91cf7cadfc1e888e21?diff=unified
HTH, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
From 7ef777b77083500d06f9117096239c2e929858c1 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sun, 31 Mar 2019 17:48:14 +0200
Subject: [PATCH 1/2] Select QT version 4.
---
debian/rules | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/rules b/debian/rules
index 57ddfa6..7230a24 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@ libpkgs_addsubst_allLibraries = kdepimlibs5-dev
libpkgs_gen_strict_local_shlibs = $(libpkgs_all_packages)
include /usr/share/pkg-kde-tools/qt-kde-team/2/library-packages.mk
+export QT_SELECT=4
+
override_dh_auto_configure:
$(overridden_command) -- -DKDE4_BUILD_TESTS=false
--
2.20.1
From 909fa74d0c745f9beda474d3affecaa7f2d2e2ca Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani
Date: Sun, 31 Mar 2019 17:07:13 +0200
Subject: [PATCH 2/2] Port to libical3.
---
debian/changelog | 7 ++
debian/control| 2 +-
debian/patches/libical3.patch | 196 ++
debian/patches/series | 1 +
4 files changed, 205 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/libical3.patch
diff --git a/debian/changelog b/debian/changelog
index edd8c2b..ccfa2d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kdepimlibs (4:4.14.10-10.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Port to libical3.
+
+ -- Giovanni Mascellani Sun, 31 Mar 2019 17:06:59 +0200
+
kdepimlibs (4:4.14.10-10) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index 5809d2a..5f67151 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends: cmake,
libboost-dev (>= 1.34),
libboost-graph-dev (>= 1.34.0~),
libgpgme11-dev,
- libical2-dev (>= 0.42),
+ libical-dev,
libldap2-dev,
libqjson-dev,
libqt4-dev (>= 4:4.8),
diff --git a/debian/patches/libical3.patch b/debian/patches/libical3.patch
new file mode 100644
index 000..6b12024
--- /dev/null
+++ b/debian/patches/libical3.patch
@@ -0,0 +1,196 @@
+Description: Compile with libical3
+From: Giovanni Mascellani
+Bug-Debian: https://bugs.debian.org/905697
+
+Index: kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp
+===
+--- kdepimlibs-4.14.10.orig/kcalcore/icalformat_p.cpp
kdepimlibs-4.14.10/kcalcore/icalformat_p.cpp
+@@ -2301,7 +2301,6 @@ icaltimetype ICalFormatImpl::writeICalDa
+ t.second = 0;
+
+ t.is_date = 1;
+-t.is_utc = 0;
+ t.zone = 0;
+
+ return t;
+@@ -2323,7 +2322,9 @@ icaltimetype ICalFormatImpl::writeICalDa
+ t.second = datetime.time().second();
+ }
+ t.zone = 0; // zone is NOT set
+-t.is_utc = datetime.isUtc() ? 1 : 0;
++if (datetime.isUtc()) {
++t = icaltime_convert_to_zone(t, icaltimezone_get_utc_timezone());
++}
+
+ // _dumpIcaltime( t );
+
+@@ -2398,7 +2399,7 @@ icalproperty *ICalFormatImpl::writeICalD
+ }
+
+ KTimeZone ktz;
+-if (!t.is_utc) {
++if (!icaltime_is_utc(t)) {
+ ktz = dt.timeZone();
+ }
+
+@@ -2431,7 +2432,7 @@ KDateTime ICalFormatImpl::readICalDateTi
+ // _dumpIcaltime( t );
+
+ KDateTime::Spec timeSpec;
+-if (t.is_utc || t.zone == icaltimezone_get_utc_timezone()) {
++if (icaltime_is_utc(t) || t.zone == icaltimezone_get_utc_timezone()) {
+ timeSpec = KDateTime::UTC; // the time zone is UTC
+ utc = false;// no need to convert to UTC
+ } else {
+Index: kdepimlibs-4.14.10/kcalcore/icaltimezones.cpp
+===
+--- kdepimlibs-4.14.10.orig/kcalcore/icaltimezones.cpp
kdepimlibs-4.14.10/kcalcore/icaltimezones.cpp
+@@ -54,7 +54,7 @@ static QDateTime toQDateTime(const icalt
+ {
+ return QDateTime(QDate(t.year, t.month, t.day),
+ QTime(t.hour, t.minute, t.second),
+- (
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
Hi, On Sat, 27 Oct 2018 17:30:32 +0300 Adrian Bunk wrote: > Properly handling this in package like libarcus3 becomes difficult once > you consider that such packages might be backported to stretch-backports > and would use libprotobuf10 there. > > We might even end up with upgrade failures if a user could end up with > a nonworking combination of packages installed during an upgrade, and > a maintainer script calls such a nonworking program. This is a sensible concern, but I share László's view here: the two versions of protobuf are not in conflict and can happily coexist on the same system, so there is no reason to declare a Break. What must be ensured is that no package depends on both at the same time: wouldn't it be better that this last package declared Conflicts and possibly Build-Conflicts towards the version of protobuf that is not meant to be used? Hop this helps, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#917501: Attempt to work on the bug
user debian-rele...@lists.debian.org usertags 917501 + bsp-2019-03-fr-paris thank you Hi, I tried to work on this bug for a few hours, but I am quite puzzled: first of all, the issue I am experiencing right now is different from what is already described in the bug log. If I build meson with sbuild it fails because the test "test_generate_gir_with_address_sanitizer" in run_unittests.py fails (if I comment out that test, the package builds correctly). Such test consists in configuring and compiling the directory "test cases/frameworks/7 gnome" using meson, passing the options "-Db_sanitize=address -Db_lundef=false" to meson itself. Well, if I do that myself "by hand" meson and the compilation work without problems. I have tried in many ways to replicate the failure, for example by checking thoroughly passed options and environment variables, but I could not find the core point. So I am leaving this issue for the moment. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#915319: Further triaging
Il 30/03/19 19:14, Scott Kitterman ha scritto: > Is there anything left in the archive that uses this functionality? I am not sure this question is for me, but just in case: I have no idea. I just met this bug during the Paris BSP, but I do not specific knowledge of neither KDE nor CMake. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#915319: Further triaging
user debian-rele...@lists.debian.org usertags 915319 + bsp-2019-03-fr-paris tags 915319 + patch thank you Hi, I did some further diagnosis on this bug: the reason why CMake fails to discover libsmbclient is because CMake tries to compile a little program including libsmbclient.h using -std=c90, which is insufficient for libsmbclient.h. However libsmbclient.h works with more recent C standards, like the GCC default -std=gnu11. The attached patch should fix the problem. I can NMU if this is ok for you. Probably it is not the cleanest solution ever (if would be better to fix CMake files from kdelibs5-dev), but it seems to work. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles From 5acb1dc95b67b14d9939ec54135c06b132996776 Mon Sep 17 00:00:00 2001 From: Giovanni Mascellani Date: Sat, 30 Mar 2019 18:59:00 +0100 Subject: [PATCH] Fix libsmbclient.h discovery. --- debian/changelog | 9 + debian/rules | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 60e7c0d..29b52fc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +kde-runtime (4:17.08.3-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Force usage of -std=gnu11 for CMake compilation, because CMake's default +seems to be -std=c90 which makes libsmbclient.h discovery fail +(closes: #915319). + + -- Giovanni Mascellani Sat, 30 Mar 2019 19:03:11 +0100 + kde-runtime (4:17.08.3-2) unstable; urgency=medium * Team upload. diff --git a/debian/rules b/debian/rules index a581bcd..25cc39a 100755 --- a/debian/rules +++ b/debian/rules @@ -4,7 +4,7 @@ include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk include /usr/share/dpkg/architecture.mk override_dh_auto_configure: - $(overridden_command) -- -DBUILD_khelpcenter=FALSE -DBUILD_drkonqi=FALSE + $(overridden_command) -- -DBUILD_khelpcenter=FALSE -DBUILD_drkonqi=FALSE -DCMAKE_REQUIRED_FLAGS="-std=gnu11" override_dh_auto_test: # Disable dh_auto_test at build time -- 2.20.1 signature.asc Description: OpenPGP digital signature
Bug#912467: Partial triaging
erreports-6.3.1/jasperreports/src/net/sf/jasperreports/engine/export/JRXlsMetadataExporter.java:[2122,40] > bad operand types for binary operator '+' > first type: int > second type: org.apache.poi.ss.usermodel.VerticalAlignment > [ERROR] > /home2/giovanni2/packages/tmp/jasperreports/build-area/jasperreports-6.3.1/jasperreports/src/net/sf/jasperreports/engine/export/JRXlsMetadataExporter.java:[2225,32] > incompatible types: org.apache.poi.ss.usermodel.CellType cannot be converted > to int > [INFO] 12 errors I believe these are caused by the recent major upload of libapache-poi-java, which might have changes a few APIs (in particular, most changes seem to be in the direction of replacing a numeric flag with a dedicated type). I can try to devise a patch, but I do not know this API, so if there is someone more expert at that I would leave it to them. If not, I can give a try. Hope this helps! Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#917711: Bug triaged and submitted upstream
user debian-rele...@lists.debian.org usertags 917711 + bsp-2019-03-fr-paris forwarded 917711 https://github.com/steveire/grantlee/issues/51 thank you Dear maintainer, I triaged and submitted upstream this bug: https://github.com/steveire/grantlee/issues/51 The upstream bug contains my current understanding of the bug and asks for help on how to proceed, because I am not really sure on what is the best way forward. I hope this helps fixing the bug! Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#920209: [debian-mysql] Bug#920209: Suggested fix
Hi, Il 23/01/19 15:57, Otto Kekäläinen ha scritto: > If you want, you can submit the patch above as a Merge Request on > Salsa and thus ensure there are no obvious visible regressions related > to it: > https://wiki.debian.org/Teams/MySQL/patches This has been marked pending for two months now. Is it possible to upload the fix so that we can progress towards the release? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#925957: fstransform: Reproducible filesystem corruption (data loss)
Hi, Il 29/03/19 11:12, Alexander E. Patrakov ha scritto: > Dear Maintainer, > > approximately 1.5 years ago I have discovered a reproducible case > of filesystem corruption by fstransform, and reported it upstream: > > https://github.com/cosmos72/fstransform/issues/13 > > I understand that the reproducer is with non-default options, > but it may also apply with the default options to systems with > huge storage and relatively small amount of RAM. Thanks for reporting this bug. I can reproduce it, but given that the upstream issue has been open for more than a year I doubt it will be solved soon. I agree that having a silent failure with data corruption is not nice towards the user, but given that fstransform displays prominent warnings about the fact that it can easily screw up data, I think it is not a ground for removing the package altogether. The package can still be helpful to the users, as long as the users are aware of the risks connected with it. So what I would rather do is to modify the starting up message so that the user is aware that running fstransform in low resources environments can lead to data corruption. Of course, if the user goes to plumbing level and manually changes internal options, then risks for breakages is really to be expected. Of course a proper fix for the bug would be better, but in the meantime I think this is enough to fix this RC bug and keep fstransform in the release without putting to much risk on the users. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#920209: Suggested fix
Hi, the failure is apparently due to insufficient timeout time for some tests. Some mipsel builders are more powerful, therefore manage to go through all the tests without problems, but other are weaker and are not able to complete the test before the timeout, thus triggering a failure. I suggest to add some code in d/rules like that: # Some mipsel buildd's are a bit slow and fail tests if they are not # given enough time ifeq (mipsel,$(DEB_HOST_ARCH)) export CK_TIMEOUT_MULTIPLIER=2 endif This should double the test timeout for all tests when building on mipsel. I don't know if 2 is the right factor, because the porterbox is of the strong kind, so it does not provide a reliable benchmark. I guess the best way is to try to upload this (I can NMU, if you want), and possibly raise the multiplier if needed. HTH and all the best, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#911625: libboost-python1.62.0: insufficient python dependencies allow early upgrade, breaking stretch->buster upgrades
Control: reassign -1 src:boost1.67 1.67.0-11 Reassigning to boost1.67, because boost1.62 will be hopefully removed soon. And it won't go in buster. Giovanni. Il 22/10/18 20:59, Andreas Beckmann ha scritto: > Package: libboost-python1.62.0 > Version: 1.62.0+dfsg-10 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > Control: affects -1 + libcasa-measures2 > > Hi, > > during a test with piuparts I noticed your package causes other packages > to fail to upgrade from 'stretch'. > It installed fine in 'stretch', then the upgrade to 'buster' fails. > > From the attached log (scroll to the bottom...): > > Setting up casacore-data-tai-utc (1.2) ... > Traceback (most recent call last): > File "/usr/bin/casacore-update-tai_utc", line 11, in > from casacore import tables > File "/usr/lib/python3/dist-packages/casacore/tables/__init__.py", line > 60, in > from .table import table > File "/usr/lib/python3/dist-packages/casacore/tables/table.py", line 44, > in > from ._tables import Table > ImportError: libboost_python-py35.so.1.62.0: cannot open shared object > file: No such file or directory > dpkg: error processing package casacore-data-tai-utc (--configure): >subprocess installed post-installation script returned error exit status 1 > > This is a upgrade test of stretch/amd64 with --install-recommends enabled. > It failed during 'apt-get upgrade'. At the point of failure the following > relevant packages are installed: > > # dpkg -l | grep python | cut -c-60 > ii dh-python 3.20180927all > ii libboost-python1.62.0 1.62.0+dfsg-10amd64 > ii libcasa-python3-2:amd64 2.2.0-2 amd64 > ii libpython3-stdlib:amd64 3.5.3-1 amd64 > ii libpython3.5:amd64 3.5.3-1 amd64 > ii libpython3.5-minimal:amd64 3.5.3-1 amd64 > ii libpython3.5-stdlib:amd64 3.5.3-1 amd64 > ii python3 3.5.3-1 amd64 > ii python3-casacore2.1.2-3+b1amd64 > ii python3-minimal 3.5.3-1 amd64 > ii python3-numpy 1:1.12.1-3amd64 > ii python3-pkg-resources 40.2.0-1 all > ii python3-six 1.11.0-2 all > ii python3.5 3.5.3-1 amd64 > ii python3.5-minimal 3.5.3-1 amd64 > > i.e. libboost-python1.62.0 is already upgraded to buster > while python3 is still python3.5 from stretch. > > The dependency chain starting from casacore-data-tai-utc looks as follows: > > Package: casacore-data-tai-utc > Status: install ok half-configured > Architecture: all > Version: 1.2 > Config-Version: 1.1 > Depends: python3, python3-casacore, tzdata > > Package: python3-casacore > Status: install ok installed > Architecture: amd64 > Source: python-casacore (2.1.2-3) > Version: 2.1.2-3+b1 > Provides: python3.5-casacore > Depends: python3-numpy, python3-six, python3 (<< 3.6), python3 (>= 3.5~), > python3-pkg-resources, python3:any (>= 3.4~), libboost-python1.62.0, libc6 > (>= 2.14), libcasa-casa2, libcasa-coordinates2, libcasa-fits2, > libcasa-images2, libcasa-lattices2, libcasa-measures2, libcasa-mirlib2, > libcasa-python3-2, libcasa-scimath-f2, libcasa-scimath2, libcasa-tables2, > libgcc1 (>= 1:4.0), libstdc++6 (>= 5.2) > > Package: libboost-python1.62.0 > Status: install ok installed > Architecture: amd64 > Source: boost1.62 > Version: 1.62.0+dfsg-10 > Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2) > Suggests: python, python3 > > > Just an idea, do not know if this can be implemented efficiently: > > If libboost-python1.62.0 provides pythonX.Y-libboost-python1.62.0 > and the consumers depend on pythonX.Y-libboost-python1.62.0 instead of > (or in addition to) libboost-python1.62.0, everything should be fine. > > > As a workaround you could add > Breaks: python3-casacore (<< 2.2.0) > (and probably some more in case I hit them) > to libboost-python1.62.0 (2.2.0-1 was the first version built without > python3.5 support). > No need to carry this Breaks over to newer boost versions. > > > cheers, > > Andreas > -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914056: Patch for FTBFS
Hi,
here is a small patch that should fix the FTBFS.
Cheers, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
Description: Fix FTBFS with Boost 1.67
In Boost 1.67 parameters passed to time constructors must be
integral. This does not change the previos behaviour, since
the count was already stored as an integer anyway. The only
different is that now the conversion must be explicit.
Author: Giovanni Mascellani
Bug-Debian: https://bugs.debian.org/914056
--- cclive-0.9.3.orig/src/cc/progressbar.h
+++ cclive-0.9.3/src/cc/progressbar.h
@@ -316,7 +316,7 @@ private:
static inline std::string eta_from_seconds(const double s)
{
-const pt::time_duration& td = pt::seconds(s);
+const pt::time_duration& td = pt::seconds(static_cast(s));
return pt::to_simple_string(td);
}
signature.asc
Description: OpenPGP digital signature
Bug#914146: Patch for FTBFS
Hi,
the attached patch should fix the FTBFS.
Cheers, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
Description: Fix FTBFS
Fix some API usages that changed between Boost 1.62 and Boost 1.67.
Author: Giovanni Mascellani
Bug-Debian: https://bugs.debian.org/914146
--- dogecoin-1.10.0.orig/src/bitcoin-cli.cpp
+++ dogecoin-1.10.0/src/bitcoin-cli.cpp
@@ -105,7 +105,7 @@ Object CallRPC(const string& strMethod,
// Connect to localhost
bool fUseSSL = GetBoolArg("-rpcssl", false);
boost::asio::io_service io_service;
-boost::asio::ssl::context context(io_service, boost::asio::ssl::context::sslv23);
+boost::asio::ssl::context context(boost::asio::ssl::context::sslv23);
context.set_options(boost::asio::ssl::context::no_sslv2 | boost::asio::ssl::context::no_sslv3);
boost::asio::ssl::stream sslStream(io_service, context);
SSLIOStreamDevice d(sslStream, fUseSSL);
--- dogecoin-1.10.0.orig/src/rpcserver.cpp
+++ dogecoin-1.10.0/src/rpcserver.cpp
@@ -503,8 +503,8 @@ private:
void ServiceConnection(AcceptedConnection *conn);
//! Forward declaration required for RPCListen
-template
-static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor,
+template
+static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor,
ssl::context& context,
bool fUseSSL,
boost::shared_ptr< AcceptedConnection > conn,
@@ -513,8 +513,8 @@ static void RPCAcceptHandler(boost::shar
/**
* Sets up I/O resources to accept and handle a new connection.
*/
-template
-static void RPCListen(boost::shared_ptr< basic_socket_acceptor > acceptor,
+template
+static void RPCListen(boost::shared_ptr< basic_socket_acceptor > acceptor,
ssl::context& context,
const bool fUseSSL)
{
@@ -524,7 +524,7 @@ static void RPCListen(boost::shared_ptr<
acceptor->async_accept(
conn->sslStream.lowest_layer(),
conn->peer,
-boost::bind(&RPCAcceptHandler,
+boost::bind(&RPCAcceptHandler,
acceptor,
boost::ref(context),
fUseSSL,
@@ -536,8 +536,8 @@ static void RPCListen(boost::shared_ptr<
/**
* Accept and handle incoming connection.
*/
-template
-static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor,
+template
+static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor,
ssl::context& context,
const bool fUseSSL,
boost::shared_ptr< AcceptedConnection > conn,
@@ -631,7 +631,7 @@ void StartRPCThreads()
assert(rpc_io_service == NULL);
rpc_io_service = new boost::asio::io_service();
-rpc_ssl_context = new ssl::context(*rpc_io_service, ssl::context::sslv23);
+rpc_ssl_context = new ssl::context(ssl::context::sslv23);
const bool fUseSSL = GetBoolArg("-rpcssl", false);
@@ -650,7 +650,7 @@ void StartRPCThreads()
else LogPrintf("ThreadRPCServer ERROR: missing server private key file %s\n", pathPKFile.string());
string strCiphers = GetArg("-rpcsslciphers", "TLSv1.2+HIGH:TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH");
-SSL_CTX_set_cipher_list(rpc_ssl_context->impl(), strCiphers.c_str());
+SSL_CTX_set_cipher_list(rpc_ssl_context->native_handle(), strCiphers.c_str());
}
std::vector vEndpoints;
signature.asc
Description: OpenPGP digital signature
Bug#914140: pytango FTBFS with boost 1.67
Hi, Il 24/11/18 09:58, Giovanni Mascellani ha scritto: > I posted a new bug to discuss the issue of Python links. Please, follow > the discussion there and bring your contribution if necessary. The outcome is that the compatibility links will not get retained, so you need to slightly change your build script: remove "-py" in the Debian suffix in [1]. I'd say this change can be safely propagated upstream. [1] https://sources.debian.org/src/pytango/9.2.4-2/setup.py/#L375 Let me know if there are other problems. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914051: Discussion on python-freecontact FTBFS
Hi, Il 01/12/18 10:04, Giovanni Mascellani ha scritto: > the boost_python library is still there, but it changed name. We are > still discussing how to lay out compatibility links at #914513 [1]. > Depending on the outcome of that discussion, this bug could be solved > automatically, or it might require a small change in the library name. In the end we decided to not add additional compatibility links. However, the change on your side should be really small: just remove "-py" from "boost_python-py" in the setup.py file[1]. [1] https://sources.debian.org/src/python-freecontact/1.1-3/setup.py/#L34 Please let me know if there are problems. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914049: Fix
Hi,
this is fortunately relatively easy: the push_back is fine, the problem
is the argument. Basically the argument passed to the push_back is a
pointer, but the vector to which we want to push is a vector of tuples,
whose first entry is actually an argument. That is fine, because a Boost
tuple can be constructed from its first entry (the other entries will
simply be default-constructed).
The point is that up to Boost 1.62 the tuple constructor constructing
from the first entry was not marked as "explicit", so the C++ compiler
could just invoke it implicitly. Now the constructor has become
"explicit", so it must be called explicitly. See the attached patch
("NeighborhoodGroup" is an alias for the tuple type).
Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
Author: Giovanni Mascellani
Bug-Debian: https://bugs.debian.org/914049
Subject: Fix FTBFS with boost1.67
Make an explicit call to the constructor for NeighborhoodGroup (which is
an alias for a specialization of boost::tuple), which is not marked
as "explicit".
--- progressivemauve-1.2.0+4713+dfsg.orig/src/repeatoire.cpp
+++ progressivemauve-1.2.0+4713+dfsg/src/repeatoire.cpp
@@ -1591,7 +1591,7 @@ void processNovelSubsetMatches( GappedMa
getSubsets(M_j,-direction*ni_parity*nj_parity).push_back(nj_link);
//getExtraSubsets(M_j,-direction*ni_parity*nj_parity).push_back(nj_link);
// push M_n onto the heap
- novel_subset_list.push_back(M_n);
+ novel_subset_list.push_back(NeighborhoodGroup{M_n});
//procrastination_queue.push(M_n);
novel_subset_count++;
}
signature.asc
Description: OpenPGP digital signature
Bug#914051: Discussion on python-freecontact FTBFS
Hi, the boost_python library is still there, but it changed name. We are still discussing how to lay out compatibility links at #914513 [1]. Depending on the outcome of that discussion, this bug could be solved automatically, or it might require a small change in the library name. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914513 Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#911625: libboost-python1.62.0: insufficient python dependencies allow early upgrade, breaking stretch->buster upgrades
Hi, Il 22/10/18 20:59, Andreas Beckmann ha scritto: > Just an idea, do not know if this can be implemented efficiently: > > If libboost-python1.62.0 provides pythonX.Y-libboost-python1.62.0 > and the consumers depend on pythonX.Y-libboost-python1.62.0 instead of > (or in addition to) libboost-python1.62.0, everything should be fine. I see the problem, thanks for bringing this up. I agree with your solution: basically we let Boost.Python expose the Python versions it is compiled with, so that packages can depend on the right version. It seems reasonable. I would just change the provided package name, because calling something "pythonX.Y-name" seems to imply that there is an actual Python extension called "name" inside, which is not the case here. I would use something like "libboost-python1.62.0-pyXY". Also, I'll do the same for boost1.67, which would have the same problem. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914140: pytango FTBFS with boost 1.67
Hi, Il 22/11/18 20:39, Adrian Bunk ha scritto: > I don't know, adding the boost maintainers to Cc for that. I posted a new bug to discuss the issue of Python links. Please, follow the discussion there and bring your contribution if necessary. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914513 Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#899454: boost-defaults: Invalid maintainer address pkg-boost-de...@lists.alioth.debian.org
Hi, Il 18/11/18 02:20, Dimitri John Ledkov ha scritto: > Hmmm so i'm not sure what to do about this. > > Is it allowed to use Debian Boost Team > as the maintainer field? Yes, we had already discussed this and it is ok. We do the same for boost1.62 and boost1.67. I'd say the bug is already solved, it was filed for 1.62 which had not been changed yet. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#913709: boost1.67: intermitent FTBFS on mips64el: build hangs
Hi, Il 14/11/18 18:16, Emilio Pozuelo Monfort ha scritto: > Some questions which may help solve this: > > - What is happening when the build hangs? Is xsltproc still running, just > being > too slow / taking way too long? I believe so, since apparently, even on the slow builders, given enough time it completes successfully. I haven't checked this first-hand, though. > - Note that the inactivity timeout gets triggered only if there are no new > lines > printed in the timeout period. So can xsltproc or whatever is getting killed > be > made more verbose? I can try. But probably the third one is the most important point. > - Is this just generating documentation? The -doc package is architecture: > all, > can't we just skip building the docs on binary-arch builds? Fair point. That's definitely might be something to fix in the packaging. I'll try to check this thing. However, I will be away out of town and without my usual computing resources for a few days (more or less until next Tuesday), so I am not sure if I will be able to do this quickly. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#913709: boost1.67: intermitent FTBFS on mips64el: build hangs
Hi, Il 14/11/18 09:56, Emilio Pozuelo Monfort ha scritto: > Your package fails to build quite often on mips64el, where the build gets > killed due to inactivity: > > Cannot find class named 'action' > Cannot find class named 'action' > Cannot find class named 'file-target' > Cannot find class named 'generator' > Cannot find class named 'generator' > Cannot find class named 'std::bad_cast' > E: Build killed with signal TERM after 150 minutes of inactivity > > This may be due to an actual hang, or something just taking so long > that causes the build to get killed. Thanks for bringing this up. Actually, I was concerned about the same thing, but I do not really know what is the way forward here. The "Cannot find class" messages are harmless: they are produced on all architectures and are not fatal. It is not a compiler that produces them, but a documentation postprocessor. So the worse that can happen is that some internal links in the documentation are broken or ignored. Looking at [1] and comparing with [2] it seems that the compilation takes much longer when compiled on a "Loongson 3A" machine then when compiled on a "Cavium Octeon III" machine. MIPS porters, is this sensible? The longer compilation time (apparently ~8.5h vs ~4.75h) triggers the build node timeout. However this is probably a close call, because version 1.67.0-6 managed to finish even when building on a weaker machine. [1] https://buildd.debian.org/status/logs.php?pkg=boost1.67&arch=mips64el [2] https://wiki.debian.org/MIPSPort?action=show&redirect=mips64el#Build_daemons_.26_porter_boxes I am not sure of what is the way forward here: can larger packages, like boost, be forced to compile on stronger machines? Or can the timeout be raised for larger packages? Or is there anything that can I due within the package compilation script to avoid triggering timeout? (although this last road seems to be risky, as it might then prevent triggering the timeout for an actually stuck build process). In line of principle even the current situation can somewhat be tolerated, since it is enough to reschedule the build until it gets a strong machine. However, that does not seem optimal. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#905056: libboost-numpy1.67-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/libboost_numpy*.so -> libboost_numpy*.so.1.67.0
tags 905056 + pending thanks Hi, thanks for the report. Il 31/07/2018 02:21, Andreas Beckmann ha scritto: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. I believe the symlink is correct, but libboost-numpy1.67-dev does not depend on libboost-numpy1.67, which contains the files pointed by the symlinks. I pushed a patch the fixes the dependency in the repository. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#902921: boost1.63: FTBFS with python3.7 supported: libs/python/src/converter/builtin_converters.cpp:51:35: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
Hi, Il 03/07/2018 17:01, Simon McVittie ha scritto:> Similar to #902702, boost1.63 fails to build when binNMU'd against > python3.7. This example build log is from amd64: Thanks for reporting. My feeling here is that it would be advisable to just remove boost1.63 from unstable. No package depends on it (as it was never promoted to the default boost version) and hopefully both 1.62 and 1.63 will be soon replaced by 1.67, which is close to being ready now. What do other boost maintainers propose? Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#902028: libstax2-api-java: FTBFS: The POM for stax:stax-api:jar:debian is missing
Hi, thanks for the bug report. On Thu, 21 Jun 2018 19:43:30 +0200 Andreas Beckmann wrote: > Source: libstax2-api-java > Version: 4.0.0-1 > Severity: serious > Justification: fails to build from source > > Hi, > > libstax2-api-java/experimental recently started to FTBFS: Under which environment did you try? I just uploaded a new version to unstable, and it seems that it is compiling fine on both my computer (inside an sbuild chroot) and on the official buildd: https://buildd.debian.org/status/package.php?p=libstax2-api-java&suite=sid Could you please confirm if the bug is still there or not? Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#871326: The bug is in freehep-chartableconverter-plugin-java
reassign 871326 freehep-chartableconverter-plugin-java 2.0-9 retitle 871326 Wrong classpath in plugin thanks As suggested by Emmanuel Bourg in [1], this bug is in freehep-chartableconverter-plugin-java. [1] https://lists.debian.org/msgid-search/af53c509-8813-3dc5-bea4-4f4cc2175...@apache.org Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles http://poisson.phc.unipi.it/~mascellani signature.asc Description: OpenPGP digital signature
Bug#821726: mandelbulber2: please build-depend on libpng-dev (=> libpng16 instead of libpng12)
Hi. Il 18/04/2016 23:16, Mattia Rizzolo ha scritto: > looks like you missed the libpng16 transition :) I definitely did. I'm uploading a new version in a few minutes. Thanks, Giovanni. -- Giovanni Mascellani PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani signature.asc Description: OpenPGP digital signature
Bug#816495: [pysatellites] Does not contain executable
Package: pysatellites Version: 2.3-2 Severity: serious Hi. $ dpkg -L pysatellites /. /usr /usr/share /usr/share/doc /usr/share/doc/pysatellites /usr/share/doc/pysatellites/changelog.gz /usr/share/doc/pysatellites/changelog.Debian.gz /usr/share/doc/pysatellites/copyright /usr/share/man /usr/share/man/man1 /usr/share/man/man1/pysatellites.1.gz (or, if you prefer, https://packages.debian.org/sid/all/pysatellites/filelist) There are no executables in the package! :-) Probably just a missing install line. Thanks, Giovanni. --- System information. --- Architecture: amd64 Kernel: Linux 4.4.0-trunk-amd64 Debian Release: stretch/sid 500 unstablerepos.fds-team.de 500 unstableftp.ch.debian.org 500 stable dl.google.com 500 sid linux.dropbox.com 1 experimentalftp.ch.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- Giovanni Mascellani PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani signature.asc Description: OpenPGP digital signature
Bug#736426: freehep-graphicsio-svg: Recompilation of the package breaks other packages
Hi. Il 06/08/2014 00:06, Emmanuel Bourg ha scritto: > Le 05/08/2014 23:55, Giovanni Mascellani a écrit : > >> For what it's worth, I'm inclined to think that the fix to #688043 >> should be ported to stable and then the affected packages should be >> rebuilt. But this is a decision that competes to maven-debian-helper >> maintainers. > > I haven't studied this issue precisely, but would a backport of > maven-debian-helper/1.6.8 to unstable help? The patch in [1] is enough (I just tried in a stable chroot). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688043 There should be no reason to rebuilt freehep-graphicsio-svg, because the binary package is already ok (the problem is triggered when _rebuiliding_ the binary package, but the one currently in stable is ok; I don't know why the first compilation was ok, but it is good that it was). I don't know whether some other package have to be rebuilt. Probably the Stable Release Managers should be contacted in order to understand whether they are interested in this upload. I can do it if maven-debian-helper's maintainers are ok. Thanks, Gio. -- Giovanni Mascellani PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani signature.asc Description: OpenPGP digital signature
Bug#736426: freehep-graphicsio-svg: Recompilation of the package breaks other packages
Hi. Il 24/01/2014 10:49, Moritz Muehlenhoff ha scritto: > In didn't some digging in the reverse deps and found the following > bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688043 > > In fact, adding that patch to the version of maven-debian-helper in > Wheezy and rebuilding the source packages mentioned above fixes the > geogebra build. > > I'm adding the Debian Java maintainers to CC, what's the proper fix > forward here, should the patch from #688043 be shipped in a point > release or are the freehep packages buggy and require other fixes? For what it's worth, I'm inclined to think that the fix to #688043 should be ported to stable and then the affected packages should be rebuilt. But this is a decision that competes to maven-debian-helper maintainers. Gio. -- Giovanni Mascellani PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani signature.asc Description: OpenPGP digital signature
Bug#708543: Re : Re : Bug#708543: geogebra: Geogebra crashes now on start
severity 708543 normal retitle 708543 geogebra: detect and avoid headless JREs thanks Hi. Il 18/05/2013 14:15, nicolas.patr...@gmail.com ha scritto: > It lives! > Thanks. > I don’t know why this package was uninstalled or not installed. Ok, then I'm degrading and retitling the bug report. I still hope someone in the Java team to have some suggestion about how to handle this problem. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#708543: Re : Bug#708543: geogebra: Geogebra crashes now on start
Hi. (Cc:-ing debian-java@d.o for more comments) Il 17/05/2013 19:14, nicolas.patr...@gmail.com ha scritto: > Le 16/05/2013 22:42:01, Giovanni Mascellani a écrit : > >> It sounds like you're using a headless JRE. Could you please check >> the output of: > >> java -version > java version "1.7.0_21" > OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-4+b1) > OpenJDK Server VM (build 23.7-b01, mixed mode) > >> and post it here? What happens if you launch: > >> /usr/lib/jvm/java-6-openjdk-amd64/bin/java -jar >> /usr/share/geogebra/geogebra.jar > > It works but with the i386 version. Oh yes, my bad about the architecture. Anyway, I'd say that the problem is that you have installed: * openjdk-6-jre * openjdk-7-jre-headless, but not openjdk-7-jre (can you confirm? If you install openjdk-7-jre, does the bug get solved?) Geogebra ensures (via its dependencies) that there is at least one complete (i.e., non headless) JRE installed, but then uses the most recent one, even if that one is headless. Then GeoGebra dies, because it requires a working GUI. I don't know whether there is a general solution to this problem (i.e., detecting which installed JREs are non headless and using one of them). Maybe the Java team has something to comment? (I had a look at java-wrappers, but there seems to be no provision for this kind of problems) Thanks. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#708543: geogebra: Geogebra crashes now on start
Hi. Il 16/05/2013 16:47, Nicolas Patrois ha scritto: >> geogebra > Exception in thread "main" java.awt.HeadlessException > at > java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207) > at java.awt.Window.(Window.java:535) > at java.awt.Frame.(Frame.java:420) > at java.awt.Frame.(Frame.java:385) > at geogebra.SplashWindow.splash(SplashWindow.java:178) > at geogebra.GeoGebra.main(GeoGebra.java:79) > > In fact, I don’t know if it’s a Java bug (wrong version of Java) or a > Geogebra bug. It sounds like you're using a headless JRE. Could you please check the output of: java -version and post it here? What happens if you launch: /usr/lib/jvm/java-6-openjdk-amd64/bin/java -jar /usr/share/geogebra/geogebra.jar Thanks for your report. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#687405: Upstream fix hard to port to Debian
This FTBFS was fixed upstream. Unfortunately, the patch is hard to port to Debian, since many filenames were changes in the meantime. I have no time to look after this at the moment. Another option is to apply my patch instead of upstream's. My patch is rather messy, but it should be dropped anyway when the next version is packages, since that will benefit from the upstream fix. I leave this decision to the maintainer. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#687405: audiofile: FTBFS: test failed
Il 15/09/2012 22:58, Giovanni Mascellani ha scritto: > Il 15/09/2012 11:08, Lucas Nussbaum ha scritto: >>> All the failures appear related to the /tmp/test file with unrecognized >>> audio file format. Lucas, could it be some strange configuration in your >>> build environment (for example, /tmp not really available, or with >>> limited space)? >> >> It shouldn't be the case. However, using '/tmp/test' is a bit fragile, >> isn't it? > > Ok, the attached patch should fix the problem. However, it is quite a > complicated and hard to maintain patch for a rather minor thing (it is a > FTBFS, but it happens only under certain conditions and it just a small > technical issue in the testing platform). I don't feel comfortable with > uploading it without hearing back from the maintainer. I also sent the patch upstream: https://github.com/mpruett/audiofile/pull/11 Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#687405: audiofile: FTBFS: test failed
tag 687405 + patch
thanks
Il 15/09/2012 11:08, Lucas Nussbaum ha scritto:
>> All the failures appear related to the /tmp/test file with unrecognized
>> audio file format. Lucas, could it be some strange configuration in your
>> build environment (for example, /tmp not really available, or with
>> limited space)?
>
> It shouldn't be the case. However, using '/tmp/test' is a bit fragile,
> isn't it?
Ok, the attached patch should fix the problem. However, it is quite a
complicated and hard to maintain patch for a rather minor thing (it is a
FTBFS, but it happens only under certain conditions and it just a small
technical issue in the testing platform). I don't feel comfortable with
uploading it without hearing back from the maintainer.
Giovanni.
--
Giovanni Mascellani
Pisa, Italy
Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org
Index: audiofile/test/miscellaneous.cpp
===
--- audiofile.orig/test/miscellaneous.cpp 2012-09-15 18:47:55.747463233
+0200
+++ audiofile/test/miscellaneous.cpp2012-09-15 19:42:52.563324587 +0200
@@ -50,7 +50,7 @@
const int kNumMiscellaneous = sizeof (kMiscellaneous) / sizeof (Miscellaneous);
-const char kTestFileName[] = "/tmp/test";
+char kTestFileName[] = "/tmp/testXX";
void writeMiscellaneous(int fileFormat)
{
@@ -143,6 +143,7 @@
int main(int argc, char **argv)
{
+ int tmp = mkstemp(kTestFileName);
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
Index: audiofile/test/aes.cpp
===
--- audiofile.orig/test/aes.cpp 2012-09-15 18:26:18.783517776 +0200
+++ audiofile/test/aes.cpp 2012-09-15 19:42:52.555324584 +0200
@@ -34,7 +34,7 @@
#include
#include
-static const char *kTestFileName = "/tmp/test.aiff";
+static char kTestFileName[] = "/tmp/test.aiffXX";
TEST(AES, AIFF)
{
@@ -68,6 +68,7 @@
int main(int argc, char **argv)
{
+ int tmp = mkstemp(kTestFileName);
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
Index: audiofile/test/channelmatrix.cpp
===
--- audiofile.orig/test/channelmatrix.cpp 2012-09-15 18:26:18.783517776
+0200
+++ audiofile/test/channelmatrix.cpp2012-09-15 19:42:52.559324586 +0200
@@ -30,7 +30,7 @@
#include
#include
-const char *kTestFileName = "/tmp/test.aiff";
+char kTestFileName[] = "/tmp/test.aiffXX";
template
void testChannelMatrixReading(int sampleFormat, int sampleWidth)
@@ -213,6 +213,7 @@
int main(int argc, char **argv)
{
+ int tmp = mkstemp(kTestFileName);
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
Index: audiofile/test/floattoint.cpp
===
--- audiofile.orig/test/floattoint.cpp 2012-09-15 18:26:18.783517776 +0200
+++ audiofile/test/floattoint.cpp 2012-09-15 19:42:52.559324586 +0200
@@ -40,13 +40,14 @@
protected:
virtual void SetUp()
{
+ int tmp = mkstemp(FloatToIntTest::kTestFileName);
}
virtual void TearDown()
{
::unlink(kTestFileName);
}
- static const char *kTestFileName;
+ static char kTestFileName[];
static AFfilehandle createTestFile(int sampleWidth)
{
@@ -67,7 +68,7 @@
}
};
-const char *FloatToIntTest::kTestFileName = "/tmp/test.aiff";
+char FloatToIntTest::kTestFileName[] = "/tmp/test.aiffXX";
static const int8_t kMinInt8 = std::numeric_limits::min();
static const int8_t kMaxInt8 = std::numeric_limits::max();
Index: audiofile/test/inttofloat.cpp
===
--- audiofile.orig/test/inttofloat.cpp 2012-09-15 18:26:18.787517776 +0200
+++ audiofile/test/inttofloat.cpp 2012-09-15 19:42:52.563324587 +0200
@@ -40,13 +40,14 @@
protected:
virtual void SetUp()
{
+ int tmp = mkstemp(IntToFloatTest::kTestFileName);
}
virtual void TearDown()
{
::unlink(kTestFileName);
}
- static const char *kTestFileName;
+ static char kTestFileName[];
static AFfilehandle createTestFile(int sampleWidth)
{
@@ -66,7 +67,7 @@
}
};
-const char *IntToFloatTest::kTestFileName = "/tmp/test.aiff";
+char IntToFloatTest::kTestFileName[] = "/tmp/test.aiffXX";
static const int8_t kMinInt8 = std::numeric_limits::min();
static const int8_t kMaxInt8 = std::numeric_limits::max();
Index: audiofile/test/large.cpp
===
--- audiofil
Bug#687405: audiofile: FTBFS: test failed
Hi. Il 12/09/2012 15:06, Lucas Nussbaum ha scritto: > During a rebuild of all packages in *wheezy*, your package failed to > build on amd64. I can't reproduce it. I tried with a testing cowbuilder (managed via debomatic) on amd64. Tests are just fine and the binary package is produced correctly. >> [==] Running 4 tests from 1 test case. >> [--] Global test environment set-up. >> [--] 4 tests from Miscellaneous >> [ RUN ] Miscellaneous.AIFF >> Audio File Library: could not open file '/tmp/test' [error 3] >> miscellaneous.cpp:72: Failure >> Value of: file >> Actual: false >> Expected: true >> Audio File Library: '/tmp/test': unrecognized audio file format [error 0] >> miscellaneous.cpp:91: Failure >> Value of: file >> Actual: false >> Expected: true >> [ FAILED ] Miscellaneous.AIFF (1 ms) >> [ RUN ] Miscellaneous.AIFFC >> Audio File Library: could not open file '/tmp/test' [error 3] >> miscellaneous.cpp:72: Failure >> Value of: file >> Actual: false >> Expected: true >> Audio File Library: '/tmp/test': unrecognized audio file format [error 0] >> miscellaneous.cpp:91: Failure >> Value of: file >> Actual: false >> Expected: true All the failures appear related to the /tmp/test file with unrecognized audio file format. Lucas, could it be some strange configuration in your build environment (for example, /tmp not really available, or with limited space)? Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#687397: beast: FTBFS: birnetutils.cc:725:44: error: 'access' was not declared in this scope
Hi. Il 12/09/2012 14:27, Lucas Nussbaum ha scritto: > During a rebuild of all packages in *wheezy*, your package failed to > build on amd64. > > Relevant part: >> /bin/bash ../libtool --silent --tag=CXX --mode=compile g++ >> -DBIRNET_LOG_DOMAIN=\"BIRNET\" -D_BIRNET_SOURCE_EXTENSIONS -I. -I.. -I.. >> -I.. -I. -I. -pthread -I/usr/include/glib-2.0 >> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -D_BIRNET_SOURCE_EXTENSIONS >> -g -DG_ENABLE_DEBUG -Wall -Wdeprecated -Wno-cast-qual -pipe -O2 -ftracer >> -finline-functions -fno-keep-static-consts -c -o birnetutils.lo >> birnetutils.cc >> birnetthreadimpl.cc:1515:43: warning: 'gint >> g_atomic_int_exchange_and_add(volatile gint*, gint)' is deprecated (declared >> at /usr/include/glib-2.0/glib/gatomic.h:66): Use 'g_atomic_add' instead >> [-Wdeprecated-declarations] >> birnetthreadimpl.cc:1520:43: warning: 'gint >> g_atomic_int_exchange_and_add(volatile gint*, gint)' is deprecated (declared >> at /usr/include/glib-2.0/glib/gatomic.h:66): Use 'g_atomic_add' instead >> [-Wdeprecated-declarations] >> birnetthreadimpl.cc:1654:43: warning: 'gint >> g_atomic_int_exchange_and_add(volatile gint*, gint)' is deprecated (declared >> at /usr/include/glib-2.0/glib/gatomic.h:66): Use 'g_atomic_add' instead >> [-Wdeprecated-declarations] >> birnetthreadimpl.cc:1659:43: warning: 'gint >> g_atomic_int_exchange_and_add(volatile gint*, gint)' is deprecated (declared >> at /usr/include/glib-2.0/glib/gatomic.h:66): Use 'g_atomic_add' instead >> [-Wdeprecated-declarations] >> birnetthreadimpl.cc:1740:43: warning: 'gint >> g_atomic_int_exchange_and_add(volatile gint*, gint)' is deprecated (declared >> at /usr/include/glib-2.0/glib/gatomic.h:66): Use 'g_atomic_add' instead >> [-Wdeprecated-declarations] >> birnetthreadimpl.cc:1745:43: warning: 'gint >> g_atomic_int_exchange_and_add(volatile gint*, gint)' is deprecated (declared >> at /usr/include/glib-2.0/glib/gatomic.h:66): Use 'g_atomic_add' instead >> [-Wdeprecated-declarations] >> birnetutils.cc: In function 'int Birnet::Path::errno_check_file(const char*, >> const char*)': >> birnetutils.cc:725:44: error: 'access' was not declared in this scope >> birnetutils.cc: In function 'void Birnet::unlink_file_name(gpointer)': >> birnetutils.cc:1213:27: error: 'unlink' was not declared in this scope >> birnetutils.cc: In function 'const gchar* Birnet::url_create_redirect(const >> char*, const char*, const char*)': >> birnetutils.cc:1228:81: error: 'getpid' was not declared in this scope >> birnetutils.cc:1253:27: error: 'write' was not declared in this scope >> birnetutils.cc:1257:18: error: 'close' was not declared in this scope >> birnetutils.cc:1261:27: error: 'unlink' was not declared in this scope >> make[4]: *** [birnetutils.lo] Error 1 A patch is already available for that: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672030 But there is now another problem. Upstream is aware and will investigate this. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#674900:
Hi Salvatore. Il 08/09/2012 17:32, Andrea Spadaccini ha scritto: > We fixed the errors we got, patch is attached. > > Unfortunately, it appears that after it compiles it then fails in the > compilation (?) of IDL files. I don't know much about GObject or IDL, > and could not go further in the debugging. The failed build log is at: > http://pastebin.com/nLD0uZWm. > > Somebody with knowledge of GObject should have a look at it. We're already discussing this bug in [1]. Upstream is looking on it and can reproduce it. Please, follow the discussion there. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672030 Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#672030: Fwd: Re: Cannot build beast with gcc 4.7
I noticed upstream developers of this bug. Answer follows. They will be looking into it. Giovanni. Messaggio originale Oggetto: Re: Cannot build beast with gcc 4.7 Data: Mon, 10 Sep 2012 12:49:13 +0200 Mittente: Tim Janik A: Giovanni Mascellani On 04.09.2012 14:36, Giovanni Mascellani wrote: > Hi. Hi Giovanni, thanks for the report, we will be looking into it. Stefan already reported he could reproduce your problem. I don't have a distribution with gcc-4.7 yet, so can only look into this later. > > I'm a Debian Developer and I'm triaging a bug reported against the beast > package in Debian: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672030 > > Beast doesn't compile with gcc 4.7, but it does with 4.6. The same > behavior happens both for the Debian package and the pristine tarball > distributed on your website. > > Let aside a few missing header files (check the patch at [1]), the > problem is that a program invoked during compilation (lt-bseprocidl) > segfaults. I tried to inspect the problem, and it appears that it is > connected with the Gobject library, since it happens during the > initialization of the Gobject structures related with class > BseStandardOsc. Unfortunately, I'm not very into the glib, so I cannot > give much more details. > > [1] http://goo.gl/1eiI3 > > Did you already try to compile beast with gcc 4.7? Do you have any plans > of supporting it? > > In case this can be helpful for you, my box runs Debian sid on an amd64 > processor. > > Thanks, Giovanni. -- Yours sincerely, Tim Janik --- http://timj.testbit.eu/ - Free software Author signature.asc Description: OpenPGP digital signature
Bug#685776: Patch for jackd2's FTBFS
Hi. Attached is a patch that fixes jackd2's FTBFS on all non-Linux archs. I can NMU if you want. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org From b1ac90680b777fe3e99aaeb827d8d5f5043f7849 Mon Sep 17 00:00:00 2001 From: Giovanni Mascellani Date: Wed, 29 Aug 2012 12:02:50 +0200 Subject: [PATCH] Fix kFreeBSD FTBFS (closes: #685776). --- debian/jackd2.install |1 - debian/rules |1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/jackd2.install b/debian/jackd2.install index ad588c6..0101295 100644 --- a/debian/jackd2.install +++ b/debian/jackd2.install @@ -1,5 +1,4 @@ debian/tmp/usr/bin/jack* -debian/tmp/usr/share/dbus-1/* debian/tmp/usr/lib/*/libjackserver.so.* debian/tmp/usr/lib/*/jack/netmanager.so debian/tmp/usr/lib/*/jack/profiler.so diff --git a/debian/rules b/debian/rules index 88d26ac..efd4c62 100755 --- a/debian/rules +++ b/debian/rules @@ -86,6 +86,7 @@ ifeq ($(DEB_HOST_ARCH_OS),linux) dh_install -pjackd2 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/jack/jack_alsa.so dh_install -pjackd2 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/jack/jack_alsarawmidi.so dh_install -pjackd2 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/jack/audioadapter.so + dh_install -pjackd2 debian/tmp/usr/share/dbus-1/* endif binary-install/jackd2:: -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
Bug#672030: FTBFS only with gcc-4.7
retitle 672030 FTBFS with gcc-4.7: segfaults in lt-bseprocidl thanks Hi. (context: I'm writing about the FTBFS in beast) I can reproduce this bug using gcc-4.7, but the package compiles correctly with gcc-4.6 (which is bad, because the bug is buried inside the internals of glib). The same behavior happens with the upstream distributed tarball and with upstream latest git code. I think the best idea is to write upstream and ask whether they've already tried to build with 4.7. I can do this: any objections? Any special care I need to have with upstream? (is he Debian friendly?) Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#655115: Not installable on kfreebsd-amd64, prevents geogebra testing migration
Hi Joachim. On 08/01/2012 18:04, Joachim Breitner wrote: > geogebra-kde seems to prevent the new geogebra version from entering > testing: > http://release.debian.org/migration/testing.pl?package=geogebra > > The reason seems to be that geogebra bumped its Recommends on > icedtea-plugin to a Dependency, making the package uninstallable on > architectures where this is not available (kfreebsd-*, s390*). Because > it is an arch:all package, this does not prevent its migration to > testing by itself. > > But geogebra-kde, being an arch:any package, was installable on > kfreebsd-* before and would not be after the geogebra migration, so > geogebra cannot migrate. Thanks for your analysis. Anyway, I'm working on Geogebra 4.0, which will drop dependency on icedtea-plugin (it'll depend on icedtea-netx-common, which is arch:all and shouldn't give this sort of problems). This should fix this problem. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#647307: [Pkg-haskell-maintainers] Bug#647307: Bug#647307: Bug#647307: Bug#647307: haskell-xss-sanitize: fails to build on mipsel
Hi. On 23/11/2011 17:43, Joachim Breitner wrote: > oh, and I think it is reasonable to upload the build (if it was built > with -b -B), as long as it stays the exception. Honestly, I prefer to see the problem fixed. If we just upload this build, next time we'll have the same problem. If we're unable to work out a solution, I'd rather prefer disabling the compilation on architectures unable to sustain it. I really hope MIPS porters to be able to say something. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#647307: [Pkg-haskell-maintainers] Bug#647307: Bug#647307: Bug#647307: haskell-xss-sanitize: fails to build on mipsel
Hi. On 22/11/2011 23:20, Joachim Breitner wrote: > Am Freitag, den 18.11.2011, 14:10 +0100 schrieb Giovanni Mascellani: >> I just asked to install build dependencies on eder to do tests on >> mipsel. > > any news from this front? Yes: the package builds without errors. As usual, I don't know what to do in this situation. Moreover, today another build was attempted and it failed, but with a different error. https://buildd.debian.org/status/logs.php?pkg=haskell-xss-sanitize&arch=mipsel&ver=0.3.0.1-1 Apparently rem and mayer have the same CPU, but mayer has more memory than rem. On the other side, eder (the porterbox I used for my compilation) has 1G RAM as mayer, and I'm not able to compare the CPUs (they appear to be quite different inside, even if theoretically they should behave the same). During the compilation on eder, I noticed that the cc1 process used about 80% of the memory, which leads me to thinking that it was also using heavily the swap. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#647307: [Pkg-haskell-maintainers] Bug#647307: Bug#647307: haskell-xss-sanitize: fails to build on mipsel
Hi. On 01/11/2011 21:37, Joachim Breitner wrote: > Am Dienstag, den 01.11.2011, 20:14 +0100 schrieb Julien Cristau: >> Package: haskell-xss-sanitize >> Version: 0.3.0.1-1 >> Severity: serious >> >> See >> https://buildd.debian.org/status/fetch.php?pkg=haskell-xss-sanitize&arch=mipsel&ver=0.3.0.1-1&stamp=1320029811 > > thanks for the report. It also fails on armel, where I tried to debug > this problem, but the package builds fine on abel.d.o. Difficult stuff. Apparently the only significant difference between version 0.2.6-1 and 0.3.0.1 in xss-sanitize is the use of Text instead of String. Since Text is a completely different tool, this could well justify the behavior difference. Anyway, it's not clear to me why xss-sanitize was built correctly on armel once (0.3.0.1-1) and then failed when building 0.3.0.1-1+b1. The only difference in dependencies appears to be network, which is version 2.3.0.6 instead of 2.3.0.2. And the version installed on abel (which presumably was used by Joachim) is 2.3.0.6, so it's difficult to find the problem there. Also the buildd machine used doesn't seem to be significant, because actually the same one (ancina) was used for both processes. I just asked to install build dependencies on eder to do tests on mipsel. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#628289: geogebra: FTBFS: [javac] /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:1593: cannot find symbol
Hi. On 02/06/2011 16:43, Damien Raude-Morvan wrote: >> The other option is to remove from Geogebra the code depending on >> netscape.javascript.*. Given that Geogebra in Debian is meant to be used >> just as an application, this shouldn't hurt that much. Some work would >> be needed anyway. > > There was a split between upstream icedtea (openjdk-* packages) et > icedtea-web > (icedtea-plugin and icedtea-netx packages). > > netscape.javascript.* classes are now located inside /usr/share/icedtea- > web/plugin.jar (icedtea-plugin). I found them just before your email arrived. :-) Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#628289: geogebra: FTBFS: [javac] /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:1593: cannot find symbol
tag 628289 + pending thanks Ciao. On 02/06/2011 15:40, Giovanni Mascellani wrote: > The other option is to remove from Geogebra the code depending on > netscape.javascript.*. Given that Geogebra in Debian is meant to be used > just as an application, this shouldn't hurt that much. Some work would > be needed anyway. > > I'll work deeper in this issue next weekend. Actually it was easier than expected. An upload it's on the way. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#628289: geogebra: FTBFS: [javac] /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:1593: cannot find symbol
Hi. Thanks for the report. On 28/05/2011 15:48, Lucas Nussbaum wrote: >> [javac] >> /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:53: >> package netscape.javascript does not exist >> [javac] import netscape.javascript.JSObject; >> [javac] ^ >> [javac] >> /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:87: >> cannot find symbol >> [javac] symbol : class JSObject >> [javac] location: class geogebra.main.AppletImplementation >> [javac] private JSObject browserWindow; >> [javac] ^ >> [javac] >> /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:1571: >> cannot find symbol >> [javac] symbol : variable JSObject >> [javac] location: class geogebra.main.AppletImplementation >> [javac] browserWindow = >> JSObject.getWindow(applet); >> [javac] ^ >> [javac] >> /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/geogebra/main/AppletImplementation.java:1593: >> cannot find symbol >> [javac] symbol : variable JSObject >> [javac] location: class geogebra.main.AppletImplementation >> [javac] browserWindow = >> JSObject.getWindow(applet); >> [javac] ^ >> [javac] Note: Some input files use or override a deprecated API. >> [javac] Note: Recompile with -Xlint:deprecation for details. >> [javac] Note: Some input files use unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> [javac] 4 errors >> [javac] 100 warnings >> >> BUILD FAILED >> /build/user-geogebra_3.2.46.0+dfsg1-1-amd64-cG9nle/geogebra-3.2.46.0+dfsg1/build.xml:59: >> Compile failed; see the compiler error output for details. The same problem happens also in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/geogebra/+bug/749271 Some classes disappeared from OpenJDK and I'm trying to understand how difficult it would be to have them back again. The other option is to remove from Geogebra the code depending on netscape.javascript.*. Given that Geogebra in Debian is meant to be used just as an application, this shouldn't hurt that much. Some work would be needed anyway. I'll work deeper in this issue next weekend. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#626979: [Pkg-haskell-maintainers] Bug#626979: haskell-platform requires older libghc-quickcheck2-dev than exists
Hi. On 16/05/2011 22:37, Anders Kaseorg wrote: > Package: haskell-platform > Version: 2011.2.0.1.1 > Severity: serious > > haskell-platform depends libghc-quickcheck2-dev (>= 2.4.0.1), > libghc-quickcheck2-dev (< 2.4.0.1+), but this dependency is unsatisfiable > because Debian only has libghc-quickcheck2-dev 2.4.1.1-1. Thanks for your report. Last version of quickcheck was uploaded in order to fix a build issue on some architectures. Probably the best thing is to make the haskell-platform depend on quickcheck 2.4.1.1, but I'd like to hear Joachim on this. BTW, Joachim is away ATM and will be back in a week (although he could have some sporadic Internet access), so we could have to wait a bit. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#626710: [Pkg-haskell-maintainers] Bug#626710: gitit: Not installable due to missing dependency
Hi. On 14/05/2011 16:17, Frederik Schwarzer wrote: > Hi, > > gitit cannot be installed in Sid, because it depends on > libghc6-filestore-data, which is a dummy package. > I think gitit is supposed to be depending on > libghc-filestore-data instead? We're still working on the transition GHC 6 -> GHC 7, with consequent renaming of all library packages. Packages still not uploaded remain uninstallable because they depend on old names. Moreover, in the specific case of gitit, we're also waiting for upstream to finish testing with the new version of happstack. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#602171: Patch is good
Hi Gregor. Your patch works fine for me. I think it's ready for upload. Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#548099: Some debug
Hi. I can reproduce this bug (using a kFreeBSD AMD64 in VirtualBox). As noted, this bug does only happen when root access is gained using sudo, because $SSH_CONNECTION is not passed to sudo's children. Using su or logging directly as root works fine. Unfortunately the patch suggested by Martin doesn't completely solve the Linux-ism, because under kFreeBSD sshd apparently doesn't retain the TTY name in the children it spawns: > r...@bestiola:~# ps ax | grep sshd > 911 ?R+ 0:00 grep sshd > 862 ?S 0:00 /usr/sbin/sshd -R > 858 ?Ss 0:00 /usr/sbin/sshd -R > 468 ?Ss 0:00 /usr/sbin/sshd Thus the pgrep test always fails and isn't able to detect SSH connections (unless $SSH_CONNECTION is set, that triggers the other test). I don't know why, but ps seems to be unable to detect the running TTY of a program (here, the TTY column is the one full of "?": the same happens for the rest of processes in "ps ax"). One could rely on the fact that "ps" (without arguments) displays the processes with the same TTY and calling user and test if its output contains a sshd. It doesn't seem to be the Right Way(tm), but it may work. Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#598474: marked as done (unusable on GNU/kFreeBSD)
severity 598474 normal thanks Il 03/11/2010 19:59, Simon McVittie ha scritto: > On Sun, 10 Oct 2010 at 10:40:46 +0200, Giovanni Mascellani wrote: >> reopen 598474 >> found 598474 0.7.dfsg-9.2 >> retitle 598474 Multicast not working on kFreeBSD >> thanks > > Is multicast not working really release-critical, or can the remaining part > of this bug be downgraded? I'd call this normal, or possibly important at a > stretch, even if Linux was affected too. I think you're right. Thanks for reminding me. I'm lowering the severity. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#598474: marked as done (unusable on GNU/kFreeBSD)
reopen 598474 found 598474 0.7.dfsg-9.2 retitle 598474 Multicast not working on kFreeBSD thanks Il 10/10/2010 00:33, Debian Bug Tracking System ha scritto: > Your message dated Sat, 09 Oct 2010 22:32:08 + > with message-id > and subject line Bug#598474: fixed in atftp 0.7.dfsg-9.2 > has caused the Debian Bug report #598474, > regarding unusable on GNU/kFreeBSD > to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. Well, as discussed in the report the bug is only partially solved, so I'm reopening it. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#597208: Progress?
Any progress on this bug? José, if you're still searching sponsors for fixing RC bug, please consider me. I'm more than interested in getting squeeze released, so will do all that I can to help your fixes reach the archive. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#598474: Intent to NMU
Il 08/10/2010 03:19, Doug Brewer ha scritto: > Hi Giovanni, > > I fired up two consoles, running atftp --option multicast --get -r > ex.bin 10.0.0.1 I think I were wrong, the problem seems to be quite different: the failing sendto() sets errno to 22, which means "Invalid argument". I don't know where is the problem, but have not enough time to investigate right now. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#598474: Intent to NMU
Hi, thanks for your feedback. Il 07/10/2010 10:38, Doug Brewer ha scritto: > Hi Giovanni, > > I confirmed your patch fixes the problem, thanks. > There's another problem in multicast support with over one client: I probably have an idea of what to do. Could you please tell me the exact commands you entered to replicate your bug? Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#598474: Intent to NMU
Il 04/10/2010 11:34, Giovanni Mascellani ha scritto: > The problem seems to stay in tftp_io.c, function tftp_send_data: the > sendto call fails with errno = 56 (EISCONN). Don't know why under > kFreeBSD the socket appears to be already connected, I'll investigate > more in the next days. FreeBSD doesn't like that an address is specified to sendto() data on a connected socket, while Linux allows it. Thus, we have to disable the call to connect() on FreeBSD. I'm attaching a patch for it, I intend to NMU it on DELAYED/03. Thanks, Gio. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org diff -u atftp-0.7.dfsg/tftpd.c atftp-0.7.dfsg/tftpd.c --- atftp-0.7.dfsg/tftpd.c +++ atftp-0.7.dfsg/tftpd.c @@ -673,6 +673,9 @@ retval = ABORT; } /* connect the socket, faster for kernel operation */ + /* this is not a good idea on FreeBSD, because sendto() cannot + be used on a connected datagram socket */ +#if !defined(__FreeBSD_kernel__) if (connect(data->sockfd, (struct sockaddr *)&data->client_info->client, sizeof(data->client_info->client)) == -1) @@ -680,6 +683,7 @@ logger(LOG_ERR, "connect: %s", strerror(errno)); retval = ABORT; } +#endif logger(LOG_DEBUG, "Creating new socket: %s:%d", sockaddr_print_addr(&to, addr_str, sizeof(addr_str)), sockaddr_get_port(&to)); diff -u atftp-0.7.dfsg/debian/changelog atftp-0.7.dfsg/debian/changelog --- atftp-0.7.dfsg/debian/changelog +++ atftp-0.7.dfsg/debian/changelog @@ -1,3 +1,11 @@ +atftp (0.7.dfsg-9.2) unstable; urgency=low + + * Non-maintainer upload. + * Fixed use of sendto() over a connected datagram socket on FreeBSD +(closes: #598474). + + -- Giovanni Mascellani Mon, 04 Oct 2010 16:46:32 +0200 + atftp (0.7.dfsg-9.1) unstable; urgency=low * Non-maintainer upload. signature.asc Description: OpenPGP digital signature
Bug#598474: Some debugging
Hi. The problem seems to stay in tftp_io.c, function tftp_send_data: the sendto call fails with errno = 56 (EISCONN). Don't know why under kFreeBSD the socket appears to be already connected, I'll investigate more in the next days. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#590147: Working for me
Akregator starts and works correctly also for me, and the version in testing is the same as in unstable. Don't have a testing environment to test it there right now. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#590765: Intent to NMU
tag 590765 + pending thanks Hi. Following Luk's suggestion, I'm uploading a NMU for this bug. Given that the bug has received no action in a month, it'll go in DELAYED/03. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org diff -Nru aircrack-ng-1.1/debian/changelog aircrack-ng-1.1/debian/changelog --- aircrack-ng-1.1/debian/changelog 2010-05-31 23:22:05.0 +0200 +++ aircrack-ng-1.1/debian/changelog 2010-10-02 19:24:25.0 +0200 @@ -1,3 +1,11 @@ +aircrack-ng (1:1.1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fixed FTBFS on sparc due to incorrect detection of Solaris OS + (closes: #590765). + + -- Giovanni Mascellani Sat, 02 Oct 2010 19:23:51 +0200 + aircrack-ng (1:1.1-1) unstable; urgency=low * New upstream release (Closes: #582658): diff -Nru aircrack-ng-1.1/debian/patches/003-fix-ftbfs-590765.diff aircrack-ng-1.1/debian/patches/003-fix-ftbfs-590765.diff --- aircrack-ng-1.1/debian/patches/003-fix-ftbfs-590765.diff 1970-01-01 01:00:00.0 +0100 +++ aircrack-ng-1.1/debian/patches/003-fix-ftbfs-590765.diff 2010-10-02 22:22:00.0 +0200 @@ -0,0 +1,19 @@ +Description: Fixes a FTBFS on sparc + Because of wrong preprocessing instructions, the build systm, when + run on sparc, thinks to be using Solaris, so tries to include headers + that are not available under Linux. This patch fixes this test. +Author: Giovanni Mascellani +Bug-Debian: http://bugs.debian.org/590765 +Forwarded: no + +--- aircrack-ng-1.1.orig/src/osdep/byteorder.h aircrack-ng-1.1/src/osdep/byteorder.h +@@ -167,7 +167,7 @@ + * Solaris + * --- + */ +- #if defined(__sparc__) ++ #if defined(__sparc__) && defined(__sun__) + #include + #include + #include diff -Nru aircrack-ng-1.1/debian/patches/series aircrack-ng-1.1/debian/patches/series --- aircrack-ng-1.1/debian/patches/series 2010-05-31 23:22:05.0 +0200 +++ aircrack-ng-1.1/debian/patches/series 2010-10-02 22:15:45.0 +0200 @@ -1,2 +1,3 @@ 000-Airmon_needs_bash.diff 002-Fix_airodump-ng_manpage.diff +003-fix-ftbfs-590765.diff signature.asc Description: OpenPGP digital signature
Bug#590765: [b-d][smetana] aircrack-ng (sid)
Please install build dependencies for aircrack-ng on smetana, in order to make me able to test the patch for #590765. Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#596882: Intent to NMU
Hi again. Il 24/09/2010 00:58, Giovanni Mascellani ha scritto: > @release team: the patch should be easily ported to the version now in > testing. Are you ok if I backport this patch for testing-proposed-updates? Sorry for the noise, the bug doesn't exist in squeeze, please just ignore my message. :-) Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#596882: Intent to NMU
package gaphor
tag 596882 + sid pending
user g...@debian.org
usertag 596882 + interesting
thanks
Hi.
Fixing this bug is rather easy (just adding the missing dependency), I'm
NMU-ing it in DELAY/5, patch attached.
@release team: the patch should be easily ported to the version now in
testing. Are you ok if I backport this patch for testing-proposed-updates?
Thanks, Giovanni.
--
Giovanni Mascellani
Pisa, Italy
Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org
diff -Nru gaphor-0.15.0/debian/changelog gaphor-0.15.0/debian/changelog
--- gaphor-0.15.0/debian/changelog 2010-08-06 22:02:52.0 +0200
+++ gaphor-0.15.0/debian/changelog 2010-09-24 00:45:04.0 +0200
@@ -1,3 +1,10 @@
+gaphor (0.15.0-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Adding missing dependency against python-simplegeneric (closes: #596882).
+
+ -- Giovanni Mascellani Fri, 24 Sep 2010 00:44:41 +0200
+
gaphor (0.15.0-1) unstable; urgency=low
* New upstream release (Closes: #550093)
diff -Nru gaphor-0.15.0/debian/control gaphor-0.15.0/debian/control
--- gaphor-0.15.0/debian/control 2010-08-06 20:49:48.0 +0200
+++ gaphor-0.15.0/debian/control 2010-09-24 00:45:43.0 +0200
@@ -9,7 +9,7 @@
Package: gaphor
Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-gaphas (>= 0.6.0), python-zope.component, python-pkg-resources, python-cairo, python-gnome2, python-gtk2, python-gobject
+Depends: ${python:Depends}, ${misc:Depends}, python-gaphas (>= 0.6.0), python-zope.component, python-pkg-resources, python-cairo, python-gnome2, python-gtk2, python-gobject, python-simplegeneric
Description: UML modeling tool
This program is an easy to use UML (Unified Modeling Language) modeling
environment. It allows you to create UML diagrams for documentation and to
signature.asc
Description: OpenPGP digital signature
Bug#595861: Fixed in sid
package chiark-tcl tag 595861 - sid fixed 595861 1.1.0+nmu2 thanks Hi. This bug was fixed in sid by upload 1.1.0+nmu2, which currently cannot migrate to testing because of another RC bug. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#594708: Patch for emerillon
Hi Gregor. We just replied to the same bug (#594708) at the same time! :-) I produced another patch, which is in my opinion a bit better that that already on the BTS, and just sent a DELAYED/14 NMU. Let me know if you have objection on this and prefer Ying-Chun's patch to be uploaded. Thanks, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#594708: Another patch
Hi. I produced another patch for this bug. Instead of modifying shipped configuration scripts (which would introduce tons of lines in the diff for me), I just modified debian/rules to run autoreconf at each compilation. This has the side effect of making debclean insufficient (because it's not able to recover the previous versions of modified files). Anyway, I think this is acceptable for a NMU, because it solves an RC bug and keeps the patch short. I'm going to NMU with a rather long delay (14 days), because of this problem with debclean. Please, let me know if I should cancel the upload. I'm attaching the patch. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org diff -Nru emerillon-0.1.1/debian/changelog emerillon-0.1.1/debian/changelog --- emerillon-0.1.1/debian/changelog 2010-06-16 12:38:13.0 +0200 +++ emerillon-0.1.1/debian/changelog 2010-09-12 16:02:58.0 +0200 @@ -1,3 +1,10 @@ +emerillon (0.1.1-2.1) unstable; urgency=low + + * Non-maintainer upload. + * Fixing FTBFS because of updated library (closes: #594708). + + -- Giovanni Mascellani Sun, 12 Sep 2010 15:30:10 +0200 + emerillon (0.1.1-2) unstable; urgency=low * Remove .la files diff -Nru emerillon-0.1.1/debian/patches/ftbfs-594708 emerillon-0.1.1/debian/patches/ftbfs-594708 --- emerillon-0.1.1/debian/patches/ftbfs-594708 1970-01-01 01:00:00.0 +0100 +++ emerillon-0.1.1/debian/patches/ftbfs-594708 2010-09-12 16:02:58.0 +0200 @@ -0,0 +1,13 @@ +Index: emerillon/configure.ac +=== +--- emerillon.orig/configure.ac 2010-09-12 16:01:59.0 +0200 emerillon/configure.ac 2010-09-12 16:02:06.0 +0200 +@@ -103,7 +103,7 @@ + AC_SUBST(SEARCH_DEPS_LIBS) + PKG_CHECK_MODULES(SEARCH_DEPS, + [ +- rest-0.6 >= 0.6 ++ rest-0.7 >= 0.6 + ] + ) + diff -Nru emerillon-0.1.1/debian/patches/series emerillon-0.1.1/debian/patches/series --- emerillon-0.1.1/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ emerillon-0.1.1/debian/patches/series 2010-09-12 16:02:58.0 +0200 @@ -0,0 +1 @@ +ftbfs-594708 diff -Nru emerillon-0.1.1/debian/rules emerillon-0.1.1/debian/rules --- emerillon-0.1.1/debian/rules 2010-06-16 12:07:12.0 +0200 +++ emerillon-0.1.1/debian/rules 2010-09-12 16:02:58.0 +0200 @@ -12,6 +12,11 @@ DEB_CONFIGURE_EXTRA_FLAGS := --enable-deprecations=no DEB_DH_MAKESHLIBS_ARGS_ALL := -X/usr/lib/emerillon/plugins/ +# Recompile auto-anything scripts, thus making patch to NMU #594708 smaller +# Warning: this action cannot be undone by debclean +makebuilddir/emerillon:: + autoreconf -v --install + pre-build:: if [ "$(DEB_UPSTREAM_GIT_REV)" != "" ]; then \ NOCONFIGURE=true ./autogen.sh; \ signature.asc Description: OpenPGP digital signature
Bug#593145: Why pidof?
I cannot reproduce this bug, but agree with Julian: I don't understand why you need pidof to detect if chrony is started, you can do the same watching the return value of start-stop-daemon. Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
