Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
reassign 935902 g++-9 affects 935902 libcppunit-dev found 935902 9.2.1-12 close 935902 9.2.1-16 thanks Hi, On Thu, Oct 31, 2019 at 03:15:10PM +0100, Matthias Klose wrote: > The comment about cppunit made me look at the cppunit package to find > #935902, and yes, the test case is reproducible. So looking at the test Ah, that one... Reassigning to gcc (and marking as fixed) > failure would have been revealed that the test frame work is broken, not a > single test. This turned out to be https://gcc.gnu.org/PR92267, causing an > ABI breakage in cppunit. OK. > The fix is now in -16. Good. Can confirm. You can close the bug. Regards, Rene
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose : >And afaik there was no test rebuild for >bullseye >either. Accepted cppunit 1.14.0-4 (source) into unstable On July 26: https://tracker.debian.org/news/1049803/accepted-cppunit-1140-4-source-into-unstable/ Buster release was 3 weeks before that. So this "no test rebuild for bullseye" is not true. Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose : >On 29.10.19 15:09, Vincent Lefevre wrote: >> On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: >>> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre >: In case makefile magic triggers some rebuild, you can also run the generated executable directly (with the right environment >variables, in case this matters). If the programs honors the system ABI, this is allowed, and you'll effectively test the new libstdc++6. >>> >>> No, if the rebuild rebuilds cppunittester or one of the >>> exceptionprotectors or the smoketest so or similar we are at the >>> same situation as with the autopkgtest (that's what it builds) and >>> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the >>> test are an executable it's a executable with gazillions of .sos. >> >> I meant running the generated program (smoketest) without rebuilding >> it: >> >> 1. Build smoketest with the old g++-9 / libstdc++6. >> 2. Upgrade g++-9 / libstdc++6. >> 3. Run smoketest directly. >> >> (I assume that the smoketest executable does not invoke g++-9 to >> rebuild things on the fly.) > >I'm not sure if Rene wants to help tracking this down, he just disabled >running >the test in >https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494 *temporarily* >and introducing a typo in >https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b >So maybe don't commit if you are angry. > Maybe, yes, but I needed to get it builds le got the upload. Will fix, thanks. ><_rene_> how supported is clang on the various (release) archs? ><_rene_> completely? ><_rene_> (clang++ if it matters) ><_rene_> (actually probably only matters for amd64/arm64 for now, >but...) > >so I assume we cannot expect Rene's help for that issue anymore. Unfortunately the tests fail when LO is built with clang. So yes, we need to track it down. >The comment about cppunit made me look at the cppunit package to find >#935902, >and yes, the test case is reproducible. So looking at the test failure >would >have been revealed that the test frame work is broken, not a single >test. I said in some comment that "the first" test failed: basic_scanner. I didn't say smoketest was the only one. It's the only one done in autopkgtest though. This >turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage >in >cppunit. The fix is now in -16. Ok. Will try. Then I can add build-conflcts or so and reenable the tests. >So a symbols file and a test rebuild should have at least flagged >something, however cppunit doesn't have symbols files, because the >package >maintainer doesn't like them. For C++ and the mangling and handling it in all arxgs, yes. > And afaik there was no test rebuild for bullseye >l either. It does not help to blame people for not doing a rebuild when there is no rebuild necessary. Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
>> And afaik there was no test rebuild for bullseye >> either. > > It does not help to blame people for not doing a rebuild when there is no rebuild necessary. Please could you turn off your mode feeling attacked by any email, before you understood these? On 31.10.19 15:33, rene.engelh...@mailbox.org wrote: Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose : And afaik there was no test rebuild for bullseye either. Accepted cppunit 1.14.0-4 (source) into unstable On July 26: https://tracker.debian.org/news/1049803/accepted-cppunit-1140-4-source-into-unstable/ Buster release was 3 weeks before that. So this "no test rebuild for bullseye" is not true. bullseye didn't see any test rebuild of the archive, and filing of FTBFS bugs yet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
On 29.10.19 15:09, Vincent Lefevre wrote: On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre : In case makefile magic triggers some rebuild, you can also run the generated executable directly (with the right environment variables, in case this matters). If the programs honors the system ABI, this is allowed, and you'll effectively test the new libstdc++6. No, if the rebuild rebuilds cppunittester or one of the exceptionprotectors or the smoketest so or similar we are at the same situation as with the autopkgtest (that's what it builds) and are not sure whether it's g++-9 or libstdc++6. Neither LO nor the test are an executable it's a executable with gazillions of .sos. I meant running the generated program (smoketest) without rebuilding it: 1. Build smoketest with the old g++-9 / libstdc++6. 2. Upgrade g++-9 / libstdc++6. 3. Run smoketest directly. (I assume that the smoketest executable does not invoke g++-9 to rebuild things on the fly.) I'm not sure if Rene wants to help tracking this down, he just disabled running the test in https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494 and introducing a typo in https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b So maybe don't commit if you are angry. <_rene_> how supported is clang on the various (release) archs? <_rene_> completely? <_rene_> (clang++ if it matters) <_rene_> (actually probably only matters for amd64/arm64 for now, but...) so I assume we cannot expect Rene's help for that issue anymore. The comment about cppunit made me look at the cppunit package to find #935902, and yes, the test case is reproducible. So looking at the test failure would have been revealed that the test frame work is broken, not a single test. This turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage in cppunit. The fix is now in -16. So a symbols file and a test rebuild should have at least flagged something, however cppunit doesn't have symbols files, because the package maintainer doesn't like them. And afaik there was no test rebuild for bullseye either. The upstream issue was introduced in May, I don't know why it's only seen now.
Bug#943889: buster-pu: package hbci4java/3.0.22+dfsg-1 hibiscus/2.8.18+dfsg-2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi release team, I would like to integrate new upstream versions of hbci4java and hibiscus into Debian 10 (buster). Hibiscus is a electronic banking software and hbci4java the underlying library. The update is necessary because of the new EU directive on payment services (PSD2) [1], leading to changes in the interfaces of most European banks and thus breaking Hibiscus for most users. Due to the new upstream versions, the diff is quiet big (~1MB) so I only include links to the diff [2, 3] here. I can send the full diff as well, if you prefer. Apart from the upstream change there is only a small patch in hibiscus needed to remove a version locking [4]. The hibiscus version is in testing for some time and the previous patch release of hbci4java as well. Both versions have no open bugs and work fine for me and for others (according to user reports). I uploaded the latest version of hbci4java today which mostly contain licensing corrections. Note that it only makes sense to update both together so I open only one issue but can open a second one if you prefer. Cheers Jochen [1] https://en.wikipedia.org/wiki/Payment_Services_Directive#Revised_Directive_on_Payment_Services_(PSD2) [2] https://github.com/willuhn/hibiscus/compare/V_2_8_10_BUILD_374..V_2_8_18_BUILD_382 [3] https://github.com/hbci4j/hbci4java/compare/hbci4j-core-3.0.22...hbci4j-core-3.1.22 [4] https://sources.debian.org/src/hibiscus/2.8.18+dfsg-2/debian/patches/0006-Disable-version-check.patch/ -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#943882: buster-pu: distro-info-data/0.41+deb10u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: buster X-Debbugs-Cc: distro-info-d...@packages.debian.org Hi SRM, I wish to update distro-info-data in stable, so that it contains up-to-date data regarding the latest ubuntu development release. I actually plan to do the same to stretch at a later date. Below is the complete debdiff, which I already uploaded. diffstat for distro-info-data-0.41 distro-info-data-0.41+deb10u1 debian/changelog |7 +++ ubuntu.csv |1 + 2 files changed, 8 insertions(+) diff -Nru distro-info-data-0.41/debian/changelog distro-info-data-0.41+deb10u1/debian/changelog --- distro-info-data-0.41/debian/changelog 2019-06-14 19:50:04.0 +0200 +++ distro-info-data-0.41+deb10u1/debian/changelog 2019-10-31 12:00:12.0 +0100 @@ -1,3 +1,10 @@ +distro-info-data (0.41+deb10u1) buster; urgency=medium + + [ Stefano Rivera ] + * Add Ubuntu 20.04 LTS, Focal Fossa. + + -- Mattia Rizzolo Thu, 31 Oct 2019 12:00:12 +0100 + distro-info-data (0.41) unstable; urgency=medium * Add final animal name for Ubuntu 19.10 Eoan Ermine. diff -Nru distro-info-data-0.41/ubuntu.csv distro-info-data-0.41+deb10u1/ubuntu.csv --- distro-info-data-0.41/ubuntu.csv2019-06-14 19:50:04.0 +0200 +++ distro-info-data-0.41+deb10u1/ubuntu.csv2019-10-31 11:58:33.0 +0100 @@ -30,3 +30,4 @@ 18.10,Cosmic Cuttlefish,cosmic,2018-04-26,2018-10-18,2019-07-18 19.04,Disco Dingo,disco,2018-10-18,2019-04-18,2020-01-18 19.10,Eoan Ermine,eoan,2019-04-18,2019-10-17,2020-07-17 +20.04 LTS,Focal Fossa,focal,2019-10-17,2020-04-23,2025-04-23 -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Accidentally started liblinear transition
On 31.10.19 10:45, Paul Gevers wrote: > On 28-10-2019 20:52, Christian Kastner wrote: >> On 28.10.19 20:02, Paul Gevers wrote: >>> You'll also need to do a source-only upload, as we're not allowing >>> binaries build by maintainers to migrate to testing. >> >> Thanks for the pointer, I was not aware of this. > > When do you intent to do this? The transition is now blocked by this. Done! Thanks, Christian
Re: Accidentally started liblinear transition
Hi Christian, On 28-10-2019 20:52, Christian Kastner wrote: > On 28.10.19 20:02, Paul Gevers wrote: >> The auto tracker now exists, but didn't add python-pattern. Is there >> anything special that it needs rebuilding (normally python packages >> don't need that)? > > Not per se, it was only to be a functional test. Ack. >> It would have been slightly better if your previous mail would have been >> a transition bug report, as that makes following the follow-up easier if >> it needs to happen. > > That would have been my next step :-) Seeing as this is an irregularly > triggered transition, I wanted to first seek input for what else I might > need to include in the bug report. > > Would you still like me to file one, if only for the sake of > completeness/documentation? Not necessary if the package and rdeps migrates normally, but... >> You'll also need to do a source-only upload, as we're not allowing >> binaries build by maintainers to migrate to testing. > > Thanks for the pointer, I was not aware of this. When do you intent to do this? The transition is now blocked by this. Paul signature.asc Description: OpenPGP digital signature
Bug#894663: marked as done (transition: wxwidgets3.0-gtk3)
Your message dated Thu, 31 Oct 2019 09:29:17 +0100 with message-id <56a2b171-662c-41fd-61d9-3a9fe8ced...@debian.org> and subject line Re: Bug#894663: transition: wxwidgets3.0 has caused the Debian Bug report #894663, regarding transition: wxwidgets3.0-gtk3 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. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 894663: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894663 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition There are now packages with a GTK3 build of wxwidgets3.0, and these have just migrated to testing. We'd like to start to encourage dependent packages to switch to this instead of the GTK2 build. The GTK2 and GTK3 flavours coexist so dependent packages can move over individually and we don't need a transition slot, but it would be useful to have a transition tracker set up to help track progress. We've already switched a few source packages. The list of remaining affected source packages is: 0ad 3depict 4pane aegisub amule audacity bochs bossa cba chipw codeblocks codelite ctsim cubicsdr darkradiant delaboratory dolphin-emu ebook2cwgui erlang espeakedit eviacam filezilla fityk flamerobin freedink-dfarc freedv freespace2-launcher-wxlauncher/contrib fwknop-gui gentle ginkgocadx gnudatalanguage gnuplot golly gspiceui hugin icinga2 jugglemaster kicad lamarc libwx-glcanvas-perl libwx-perl libwx-scintilla-perl limesuite maitreya mathgl mediainfo megaglest mriconvert mrpt munipack objcryst-fox openbabel openmsx-catapult openyahtzee passwordsafe pcsx2 pgadmin3 pgn2web plee-the-bear plplot poedit qutemol rapidsvn saga sandboxgamemaker/contrib scorched3d scummvm-tools silverjuke sitplus slic3r-prusa sooperlooper spatialite-gui spek springlobby stimfit stx-btree thuban tintii treesheets treeviewx trustedqsl ucblogo usbprog wxastrocapture wxhexeditor wxmaxima wxsqlite3 xchm xmlcopyeditor The procedure for updating these is to update the BDs to use the wxgtk*3.0-gtk3-dev package(s) instead of wxgtk*3.0-dev, check that the package still builds OK, and then check that the result works OK. (There's also wxpython3.0 which has already been switched but is waiting to clear binary-NEW.) Cheers, Olly Ben file: title = "wxwidgets3.0"; is_affected = .depends ~ "libwxgtk(-media)?3\.0-0v5" | .depends ~ "libwxgtk(-media)?3\.0-gtk3-0v5"; is_good = .depends ~ "libwxgtk(-media)?3\.0-gtk3-0v5"; is_bad = .depends ~ "libwxgtk(-media)?3\.0-0v5"; signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Hi, On 30-10-2019 23:35, Olly Betts wrote: > I've uploaded wxwidgets3.0 dropping the GTK2 flavour packages, so I > think we can consider this transition complete. I'll leave actually > closing this bug to someone on the release team in case I've missed > something. The old libraries of wxwidgets3.0 are not in testing anymore AFAICT, so indeed the transition is over. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
