Bug#1061954: frog: NMU diff for 64-bit time_t transition
Hi Joost, Lukas, On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time and checked the updated Frog sources, there is no time_t exposed at all anymore in the new version I'm packaging. So if I understand things correctly, the new libfrog3 library does not need the t64 transition and I can revert https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f ? > Afaik the plan is to keep the binary packages named libt64 (reading > https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the > transition. I'll rebase so the libfrog2t64 patch is included, but it'll be immediately superseded by libfrog3. Regards, -- Maarten van Gompel (proycon) web: https://proycon.anaproy.nl gpg: 0x39FE11201A31555C signature.asc Description: PGP signature
Bug#1061954: frog: NMU diff for 64-bit time_t transition
Hi Lukas,
On Tue Jan 30, 2024 at 2:31 PM CET, Lukas Märdian wrote:
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> frog as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time. Therefore I have prepared a 0-day NMU for frog
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP. Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
Thanks for your patch. I am currently in the progress of upgrading these
packages to the new upstream sources after a long hiatus. This would
involve a library transition anyway (libfrog2 -> libfrog3). Is it
sufficient if I include 'Provides: ${t64:Provides}' for the new
libfrog3 package to accomodate this transition? I just did this in
commit 2bbda8d92d40b96a216e8d8db972a9589f8df02f:
https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
Perhaps that also removes the need for the oddly named frog2t64 package?
If not, I'll apply your patch and rebase my changes on top of it.
Regards,
--
Maarten van Gompel (proycon)
web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C
signature.asc
Description: PGP signature
Bug#1025778: libnewuoa breaks libpdb-redo autopkgtest: pdb-redo-example (Failed)
Dear Paul, The issue with libnewuoa and libpdb-redo is solved in the new version of libpdb-redo that is waiting in experimental. And libpdb-redo is coupled to libcifpp which is also waiting in experimental, hoping it will get a slot to move into testing. Perhaps the bug in libnewuoa should be reassigned to libpdb-redo? regards, -maarten Op 08-12-2022 om 22:02 schreef Paul Gevers: Source: libnewuoa, libpdb-redo Control: found -1 libnewuoa/0.1.2-1 Control: found -1 libpdb-redo/2.0.3-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of libnewuoa the autopkgtest of libpdb-redo fails in testing when that autopkgtest is run with the binary packages of libnewuoa from unstable. It passes when run with only packages from testing. In tabular form: pass fail libnewuoa from testing 0.1.2-1 libpdb-redo from testing 2.0.3-1 all others from testing from testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of libnewuoa to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libnewuoa https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpdb-redo/29137519/log.gz -- The CXX compiler identification is GNU 12.2.0 -- The C compiler identification is GNU 12.2.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Looking for ccp4/ccp4_general.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libccp4c.so -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE -- Looking for clipper/clipper.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so -- FFTW2 libraries - /usr/lib/libsfftw.so -- - /usr/lib/libsrfftw.so -- FFTW2 header directory - /usr/include -- Performing Test _LINKING_WITH_CLIPPER_CORE -- Performing Test _LINKING_WITH_CLIPPER_CORE - Success -- Looking for clipper/clipper-ccp4.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so -- Looking for clipper/clipper-contrib.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so -- CCP4 include directory: /usr/include -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.70.0") found components: system iostreams regex -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.70.0") found components: system date_time regex -- Looking for ccp4/ccp4_general.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libccp4c.so -- Looking for clipper/clipper.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so -- FFTW2 libraries - /usr/lib/libsfftw.so -- - /usr/lib/libsrfftw.so -- FFTW2 header directory - /usr/include -- Looking for clipper/clipper-ccp4.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so -- Looking for clipper/clipper-contrib.h - /usr/include -- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so -- CCP4 include directory: /usr/include -- Configuring done -- Generating done -- Build files have been written to: /tmp/autopkgtest-lxc.qdh1lkps/downtmp/autopkgtest_tmp/build [ 50%] Building CXX object CMakeFiles/pdb-redo-example.dir/example.cpp.o [100%] Linking CXX executable pdb-redo-example /usr/bin/ld: warning: libnewuoa.so.0, needed by /usr/lib/x86_64-linux-gnu/libpdb-redo.so.2.0.3, not found (try using -rpath or -rpath-link) [100%] Built target pdb-redo-example Test project /tmp/autopkgtest-lxc.qdh1lkps/downtmp/autopkgtest_tmp/build Start 1: pdb-redo-example 1/1 Test #1: pdb-redo-example .***Failed 0.00 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.00 sec The following tests FAILED: 1 - pdb-redo-example (Failed) Errors while running CTest Output from these tests are in: /tmp/autopkgtest-lxc.qdh1lkps/downtmp/autopkgtest_tmp/build/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-f
Bug#979314: libccp4: The endianness check in ccp4_sysdep.h is incorrect assuming powerpc is always big endian
Source: libccp4 Version: 6.5.1-4 Severity: grave Tags: patch upstream Justification: renders package unusable X-Debbugs-Cc: maar...@hekkelman.com -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.4.0-58-generic (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect The file ccp4_sysdep.h checks for the endianness in an incorrect way, the check assumes powerpc is always big endian. By moving the catch-all test up the test is more robust. regards, -maarten --- a/ccp4/ccp4_sysdep.h +++ b/ccp4/ccp4_sysdep.h @@ -177,6 +177,26 @@ #define DFNTF_CONVEXNATIVE 5/**< Convex native floats */ #define DFNTF_LEIEEE4 /**< little-endian IEEE format */ +/* From time to time new architectures are added here, often because Linux + * packagers want to build it on all platforms supported by their distro. + * Here we try to catch machines not listed explicitely above, under + * assumption that endianness is the same for floating point numbers + * as for integers. Which is safe assumption on modern standard computers + * (not embedded systems), according to + * http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness + */ +#if defined(__BYTE_ORDER) +# if __BYTE_ORDER == __LITTLE_ENDIAN +# define NATIVEIT DFNTI_IBO +# define NATIVEFT DFNTF_LEIEEE +# elif __BYTE_ORDER == __BIG_ENDIAN +# define NATIVEIT DFNTI_MBO +# define NATIVEFT DFNTF_BEIEEE +# endif +#endif + +#if !defined(NATIVEIT) && !defined(NATIVEFT) + #if defined (VAX) || defined (vax) /* gcc seems to use vax */ # define NATIVEFT DFNTF_VAX # define NATIVEIT DFNTI_IBO @@ -222,22 +242,6 @@ # endif #endif -/* From time to time new architectures are added here, often because Linux - * packagers want to build it on all platforms supported by their distro. - * Here we try to catch machines not listed explicitely above, under - * assumption that endianness is the same for floating point numbers - * as for integers. Which is safe assumption on modern standard computers - * (not embedded systems), according to - * http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness - */ -#if !defined(NATIVEIT) && !defined(NATIVEFT) && defined(__BYTE_ORDER) -# if __BYTE_ORDER == __LITTLE_ENDIAN -# define NATIVEIT DFNTI_IBO -# define NATIVEFT DFNTF_LEIEEE -# elif __BYTE_ORDER == __BIG_ENDIAN -# define NATIVEIT DFNTI_MBO -# define NATIVEFT DFNTF_BEIEEE -# endif #endif #ifndef NATIVEFT
Bug#974895: ftp.debian.org: MRS should be updated to support the new libzeep library
Package: ftp.debian.org Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) MRS is an information retrieval system, used to index terabytes of text based databanks on a single machine. Mostly used in the medical and biological world. The version of MRS in currently in Debian is based on libzeep version 3. Libzeep was in fact a spin off project from MRS. I stopped development of MRS in 2012 when I switched to a new employer but I took libzeep with me. Since then, libzeep has evolved and changed a lot and now compatibility with MRS is broken. I've submitted the new version of libzeep into debian (it is currently in unstable) but now MRS no longer builds and so I request to remove it from Debian until it is updated. regards, -maarten
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
Hi Juhani, Bug #974074 is in fact a bug in MRS. However, the bug report does contain a useful observation, the usage of the various override_dh_auto_configure rules in libzeep is incorrect and no shared library is created. Now the question is, is a shared library really required? If so I will have to go back to the drawing board and redesign the makefiles in the upstream project to create proper shared libraries, including a version numbering scheme. regards, -maarten Op 11-11-2020 om 09:13 schreef Juhani Numminen: On Tue, 10 Nov 2020 23:03:57 +0100 Sebastian Ramacher wrote: Hi Marten On 2020-11-10 07:42:45 +0100, Maarten L. Hekkelman wrote: ... Sorry, long story. To make it short. - Keep mrc, no problem there - Upgrade libzeep to version 5 Thanks for the detailed explanation. The first two steps are almost done The current versions of mrc and libzeep should be able to migrate soon as their RC bugs have been fixed. ... Right, but one RC bug is not fixed yet: libzeep packages are missing the shared library altogether; the .so files are not there. For that we have bug #974074, and see gregor's message for suggested fix. It seems he is confident in the first diff of that mail, while the latter diff is more speculative. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974074#19 Regards, Juhani -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http://www.hekkelman.com/ +31 24 348 0192
Bug#973526: FTBFS due to SIGABRT while running HTTP server tests, bug #973526
Op 10-11-2020 om 16:21 schreef Andrey Rahmatullin: Running 7 test cases... started daemon at port 5923 terminate called after throwing an instance of 'boost::wrapexcept' what(): resolve: Host not found (authoritative) Looks like it tries to resolve something, and that usually implies Internet access, as otherwise you could just connect to localhost? Accessing the Internet is forbidden during building. The test case tried to resolve "127.0.0.1" as host. I've changed that to "localhost" since adding a flag for boost to only interpret the value as numeric is not easy to add to the code. I've seen hosts where localhost is mapped to some other IP address in the range 127.0.0.0/255 Could this be the case on the particular build machine where the test failed? Anyway, I assume that using localhost will be sufficient to fix this problem. We'll see that shorly. regards, -maarten
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
Hi Andreas, To avoid confusion, we're talking about three tools here: libzeep, mrc and mrs. mrc is a simple resource compiler, is now compatible and bug free, builds on all architectures and should be kept. I believe it is very useful, using it I can create downloadable, portable applications that need additional static data without the need for installer scripts. libzeep version 5 is the latest incarnation of a library I've been working on for 12 years now. It has evolved into a toolbox to build web applications in C++ inspired by the popular Java Spring framework and Thymeleaf template processor. It also contains a full XML and a JSON library. Using this library I could e.g. convert a pipeline to process genomics data into an interactive web application, the python scripts took up to 4 hours for each run, now you can do the same analysis in less than 5 seconds. I have a couple of applications based on libzeep that I would like to add to Debian, most of them tools used in crystallography and genomics research. But also a content management system. And then we have MRS. This is a retrieval system, a web application capable of indexing and then searching terabytes of text based databanks on a single machine. Mostly used in the medical and biological world. It is used e.g. on mini computers that are sent into Africa where internet access is limited, that way large databanks like EMBL are still available. But I stopped development in 2012 when I switched jobs. I continued development of libzeep on which MRS is based but someone else took over development of MRS. A year ago I did a consultancy job fixing MRS which basically came down to reverting most of the attempted 'improvements' after I left. Currently I'm working at the Netherlands Cancer Institute, here I write both software used in crystallography as well as a genomics analysis tool. Many of the crystallographic tools are moving into open source right now. We would have liked to include those in the CCP4 distribution, but unfortunately my code is way too new (C++17) to work in that environment. Next to that we would like to include our tools in Debian (DSSP already is, but that application needs an update), but if that won't work, I will set up a private repository to distribute our binaries. I know libzeep is not very popular, that's because I never bothered much to find an audience. But I can't live without it myself, a lot of my tools are based on it one way or another. Libzeep is also quite mature and has been used in many tools in a production environment for many years now. Sorry, long story. To make it short. - Keep mrc, no problem there - Upgrade libzeep to version 5 - Kick out mrs until it is upgraded to use libzeep 5 regards, -maarten Op 09-11-2020 om 20:49 schreef Andreas Tille: Hi Maarten, On Mon, Nov 09, 2020 at 07:22:30PM +0100, Maarten L. Hekkelman wrote: I'm sorry, but mrs as it is currently in Debian is not compatible with libzeep version 5. It needs a major rewrite. Libzeep is a spin off project of mrs and has evolved a lot since then. So either libzeep should be kept at version 3 or mrs should be removed. If mrs and libzeep are kept, I will not be able to release my other tools based on libzeep in Debian. You are the Uploader and the only competent person to decide. If I understood the issue correctly it came up right after mrc was added to the Build-Depends. Wouldn't it be an option to just de-couple both again. Upgrading mrs is of course the best option, but I won't have time to do that soon. So please draw a sensible decision. Libzeep was according to popcon[1] never installed by more than 10 users - currently the vote (active users) is at zero. Feel free to decided what *you* personally love to see in Debian (but decreasing a version number is usually not nice). Kind regards Andreas. [1] https://qa.debian.org/popcon.php?package=libzeep regards, -maarten Op 09-11-2020 om 16:19 schreef Niko Tyni: On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote: Source: mrs Version: 6.0.5+dfsg-8 Severity: serious Tags: ftbfs sid Justification: fails to build from source (but built successfully in the past) | Checking for libzeep...libzeep is not installed, either install the package libzeep-dev | or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep | and run configure again. | make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2 Looks to me like libzeep-dev is broken because the build doesn't pass --enable-shared to ./configure. Probably the override_dh_auto_configure-arch and override_dh_auto_configure-indep targets in src:libzeep debian/rules are not effective because of the earlier override_dh_auto_configure target. But I didn't actually test any of this. Hope this helps, -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http://www.hekkelman.com/ -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
I'm sorry, but mrs as it is currently in Debian is not compatible with libzeep version 5. It needs a major rewrite. Libzeep is a spin off project of mrs and has evolved a lot since then. So either libzeep should be kept at version 3 or mrs should be removed. If mrs and libzeep are kept, I will not be able to release my other tools based on libzeep in Debian. Upgrading mrs is of course the best option, but I won't have time to do that soon. regards, -maarten Op 09-11-2020 om 16:19 schreef Niko Tyni: On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote: Source: mrs Version: 6.0.5+dfsg-8 Severity: serious Tags: ftbfs sid Justification: fails to build from source (but built successfully in the past) | Checking for libzeep...libzeep is not installed, either install the package libzeep-dev | or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep | and run configure again. | make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2 Looks to me like libzeep-dev is broken because the build doesn't pass --enable-shared to ./configure. Probably the override_dh_auto_configure-arch and override_dh_auto_configure-indep targets in src:libzeep debian/rules are not effective because of the earlier override_dh_auto_configure target. But I didn't actually test any of this. Hope this helps, -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http://www.hekkelman.com/
Bug#917700: dimbl: FTBFS: build-dependency not installable: libtimbl4-dev
Hi Lucas, We're going to let this package get autoremoved, it's hardly used anyway and not worth the effort to maintain. Regards, -- Maarten van Gompel Language Machines research group Centre for Language and Speech Technology Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.org Telegram: proycon IRC: proycon (freenode) Discord:proycon#8272 Mastodon: https://mastodon.social/@proycon (@proycon@mastodon.social) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006 Keybase:https://keybase.io/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd signature.asc Description: PGP signature
Bug#913514: libfolia FTBFS with ICU 63.1
On 18-11-11 08:18, László Böszörményi wrote: > Source: libfolia > Source-Version: 1.6-2 > Severity: important > Tags: patch > Usertags: icu63 > > Dear Maintainer, > > ICU 63.1 recently released, packaged and uploaded to experimental. > Its transition is going to start soon. However your package fails to > build with this version. I attach a patch which fixes the problem. > Please check if it works with the version in Sid and upload the > package when it's feasible for you. > > Thanks, > Laszlo/GCS Thanks for the heads up and the patch! This problem had already been addressed upstream as well and I just prepared new updated debian packages that should fix it, still pending upload. Kind egards, -- Maarten van Gompel Language Machines research group Centre for Language and Speech Technology Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x39FE11201A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:matrix.org Telegram: proycon IRC: proycon (freenode) Discord:proycon#8272 Mastodon: https://mastodon.social/@proycon (@proycon@mastodon.social) Twitter:https://twitter.com/proycon ORCID: https://orcid.org/-0002-1046-0006 Keybase:https://keybase.io/proycon Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
old directory '/etc/ucto': Directory > not empty > Setting up libgomp1:amd64 (6.3.0-4) ... > Setting up libxml2:amd64 (2.9.4+dfsg1-2.2) ... > Processing triggers for libc-bin (2.24-9) ... > Setting up libucto2:amd64 (0.9.6-1) ... > Removing obsolete conffile /etc/ucto/e-mail.rule ... > Removing obsolete conffile /etc/ucto/smiley.rule ... > Removing obsolete conffile /etc/ucto/url.rule ... > Removing obsolete conffile /etc/ucto/standard-eos.eos ... > Removing obsolete conffile /etc/ucto/standard-quotes.quote ... > Removing obsolete conffile /etc/ucto/tokconfig-generic ... > Processing triggers for libc-bin (2.24-9) ... > > > libucto2.maintscript is missing this line: > > rm_conffile /etc/ucto/tokconfig-generic 0.9.6-2~ Really? There's a line "rm_conffile /etc/ucto/tokconfig-generic 0.9.6~" since the first commit. And it does say "Removing obsolete conffile /etc/ucto/tokconfig-generic" above. Ciao, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Quoting Andreas Beckmann (2017-01-24 02:54:36)
> On 2017-01-24 02:51, Andreas Beckmann wrote:
> > spotted a typo (trailing "a") in frogdata.maintscript
> >
> > echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt
> > 0.13.7~"a
>
> but that's harmless, its still a valid version to achieve your goal
Oops... Well spotted, I just fixed it in git, but it is probably overkill to
prepare/upload a new release just
for that now I guess?
--
Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen
proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon
GnuPG key: 0x1A31555C
XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl
Telegram: proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Hi Mattia, Andreas, @Mattia: Thanks! I'm trying to finalize the packages but still running into something: > use debian/$package.maintscript instead of doing it directly in maintscripts > > put in there lines like > > rm_conffile /etc/ucto/tokconfig-es 0.4-1~ > > no dpkg-maintscript-helper prefix, no default arguments, no trailing > comments! > use $VERSION_TO_BE_UPLOADED + "~" as prior-version argument > > this will generate appropriate pre/post/inst/rm scripts with the same > content This is what I was looking for yes, I knew something must exist to take care of this but didn't know what it was. I now followed Andreas' instructions, but on but upon gbp buildpackage I now get errors like: /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: 1: /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: rm_conffile: not found So I'm still doing something wrong. Any idea what I am missing? You said no dpkg-maintscript-helper prefix.. Ciao, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Hi Andreas et al, Short follow up: we discussed it internally and think it's indeed best to just move the 'configuration' files to /usr/share, as you pointed out; simplifying the package and resolving the conflicts. We're currently working on new upstream releases for ucto, uctodata, frogdata, and frog (the latter two have the same division and make the same mistake, and depends on ucto/uctodata too) that implement this. I hope releasing four new packages so close to the freeze is not going to be a problem. At least it should fix this bug for good. Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd Quoting Maarten van Gompel (2017-01-23 11:10:18) > Hi Andreas, > > Thanks for your elaborate response! It seems this has indeed opened quite a > can > of worms.. Here we go: > > Quoting Andreas Beckmann (2017-01-22 22:27:08) > > TL;DR: You have an ambitious task before you. > > So I see... > > > Let me see if I understand what's going on. > > > > Renaming conffiles and changing the owning package at the same time is a > > PITA. > > You add an extra point by making the old name a symlink to the new one, > > owned by the new package > > > > In jessie, everything in /etc/ucto was owned by ucto. > > In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata > > or libucto2, a m-a:same library package. These come from 2 different > > source packages. > > Indeed.. > > > Yuck. While putting conffiles in m-a:same packages is allowed, I highly > > discourage this. Even if I haven't seen this fail once, yet. I'm just > > afraid, someone has to clean up a mess caused by this at some point in > > the future. and I'm afraid, I won't keep my fingers out of then :-( > > Ok, we'll come back to this in your later suggestion to move the conffiles to > a > new package. > > > Before we start: Are these really conffiles? Supposed to be modified by > > the local admin? Or are these rather data files that are not supposed to > > be updated locally? And would better live in /usr/share in that case? > > You have a point there; the user MAY add a new configuration or modify an > existing one, but it is indeed not something that NEEDS to be modified to > run. You may be right that > /usr/share might be better here. I'd have to discuss with the main upstream > developer, but I think we're not opposed to such 'radical' solutions if that > solves the packaging problems and makes more semantic sense anyway. > What do you think is best for the short term to get this fixed before the > freeze? > > > And nearly everything from jessie's /etc/ucto content is now renamed and > > a symlink. > > > Can't you just fork the project? I'd suggest 'hpgb' and then use > > /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new > > source packages ... > > > > Oh yeah, it well be a mess. But we will do it right. Including making > > dpkg forget about the old conffiles. > > > > Right now, all upgrade attempts from jessie to stretch should always > > have failed, so there is no further messed up state inbetween that > > should be supported for clean upgrades. > > Right > > > can we move the conffiles from libucto2 to a new package, e.g. > > ucto-common (which would be either m-a:foreign or m-a:allowed, but I > > always mess up these two, I need to look up what's right? > > Okay, that sounds good to me, if there's no objection to having yet another > package. > > > * Which version introduced the new layout? > > * can you give me a list of > > + removed conffiles > > + renamed conffiles (old name, new name, new owning package, whether > > they have a compat symlink, did the content change between jessie and sid) > > ucto 0.9.2 introduced the split into uctodata. The jessie version is very > old: 0.5.3-3.1 > The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata > package: > > config/es.abr > config/exotic-eos.eos > config/exotic-quotes.quote > config/ligatures.filter > config/nl_afk.abr > config/pt.abr (not in jessie version) > config/tokconfig-de > config/tokconfig-en > config/tokconfig-es > config/tokconfig-fr > config/tokconfig-fy > config/tokconfig-it > config/
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
(not in jessie version) -> config/tokconfig-tur config/tokconfig-sv -> config/tokconfig-swe At that point we decided to symlink from the old two-letter versions to the new three-letter versions, for backward compatibility "to make things easy".. but apparantly this didn't play out as anticipated :) > Do you *really* need the compat symlinks? No, it's just a courtesy for the user that we don't mind dropping at all if it complicates matters like this. > OK, packaging is in git. Need to check whether I have write permissions > there ... > > rough plan: > > ucto uses d-m-h move-conffile (but provides no new version, so the old > conffile should "disappear" and dpkg should forget about it. > Maybe it's better to rm_conffile it instead. Okay, I'll read up on all that today then because I have to prior experience with those. > uctodata will probably need a Conflicts against ucto (<< current+fixed~) Right, Thanks for your help! -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Quoting Andreas Beckmann (2017-01-16 17:24:19) > Followup-For: Bug #838112 > Control: found -1 0.3.1-1 > Control: affects -1 + ucto > > that bug has just reappered: > > Preparing to unpack .../ucto_0.9.5-1_amd64.deb ... > Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ... > dpkg: warning: unable to delete old directory '/etc/ucto': Directory not > empty > Selecting previously unselected package uctodata. > Preparing to unpack .../uctodata_0.3.1-1_all.deb ... > Unpacking uctodata (0.3.1-1) ... > dpkg: error processing archive > /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack): >trying to overwrite '/etc/ucto/es.abr', which is also in package ucto > 0.9.5-1 > > > Andreas Hi, Thanks for the notification. It seems this bug is a persistent one and I don't really get why it's resurfacing; I'm probably missing something so CC'ing the debian-science list for help. Ucto 0.9.5 no longer has the mentioned file /etc/ucto/es.abr, is was part of ucto until 0.8.0-1 and then moved to a separate uctodata package. To prevent this issue, ucto 0.9.5 (package libucto2 actually), states: Replaces: ucto (<< 0.5.5-1) Breaks: ucto (<< 0.5.5-1) Uctodata also states: Replaces: ucto (<< 0.9.2-1) Breaks: ucto (<< 0.9.2-1 But as this resurfaced, it's apparently not enough, What am I missing here? Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#754221: Drop xf86-video-msm?
Op 16-08-14 om 17:15 schreef Ying-Chun Liu (PaulLiu): 於 2014年07月16日 18:26, Maarten Lankhorst 提到: Hey, I think this package is outdated and should be dropped. Rob Clark has been doing some work on adreno with the xf86-video-freedreno ddx, a more open replacement. Could you get xf86-video-msm deleted? And if you're still interested in msm, would you want to package freedreno? ~Maarten Hi Maarten, Thanks for the info. I think we should drop xf86-video-msm and package freedreno instead. I'll try to package freedreno, test, and then drop msm. Thanks a lot. Regards, Paul I've already prepared packaging at ssh://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-freedreno waiting for it to clear through NEW. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735532: libanyevent-rabbitmq-perl: Invalid location of fixed_amqp0-9-1.xml
Package: libanyevent-rabbitmq-perl Version: 1.15~dfsg-1 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, The XML spec file that is used by AnyEvent::RabbitMQ seems to be in the wrong location. Because of licensing issues the original file is removed from the package, and replaced by a symlink to a stripped version included in amqp-specs. The location of the symlink differs from the expected location though. To demonstrate the issue: $ perl -MAnyEvent::RabbitMQ -e 'AnyEvent::RabbitMQ-new-load_xml_spec();' Could not create file parser context for file /usr/share/perl5/auto/share/dist/AnyEvent-RabbitMQ/fixed_amqp0-9-1.xml: No such file or directory at /usr/share/perl5/Net/AMQP/Protocol.pm line 64. (in cleanup) close already in progress at /usr/share/perl5/AnyEvent/RabbitMQ.pm line 612. (This command is expected to give no output and no error.) The symlink is located in a subdirectory 'share', which is not expected by the library. This patch fixes the issue for me: diff --git a/debian/rules b/debian/rules index 46cd581..a86c334 100755 --- a/debian/rules +++ b/debian/rules @@ -52,8 +52,8 @@ clean:: # use separately packaged spec files DEB_DH_LINK_$(pkg) = \ /usr/share/amqp/specs/0-9-1-rabbit/amqp0-9-1.stripped.extended.xml \ - /usr/share/perl5/auto/share/dist/AnyEvent-RabbitMQ/share/fixed_amqp0-9-1.xml + /usr/share/perl5/auto/share/dist/AnyEvent-RabbitMQ/fixed_amqp0-9-1.xml common-configure-arch common-configure-indep:: - ln -sf /usr/share/amqp/specs/0-9-1-rabbit/amqp0-9-1.stripped.extended.xml share/fixed_amqp0-9-1.xml + ln -sf /usr/share/amqp/specs/0-9-1-rabbit/amqp0-9-1.stripped.extended.xml fixed_amqp0-9-1.xml clean:: - rm -rf share/fixed_amqp0-9-1.xml + rm -rf fixed_amqp0-9-1.xml -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libanyevent-rabbitmq-perl depends on: ii libanyevent-perl 7.070-1 ii libdevel-globaldestruction-perl 0.12-1 ii libfile-sharedir-perl1.03-1 ii liblist-moreutils-perl 0.33-1+b2 ii libnamespace-clean-perl 0.24-1 ii libnet-amqp-perl 0.06~dfsg-1 ii libreadonly-perl 1.04-1 ii perl 5.18.1-5 Versions of packages libanyevent-rabbitmq-perl recommends: ii amqp-specs 1-0r0-2 libanyevent-rabbitmq-perl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713631: proposed fix (debdiff)
This should fix the FTBFS. diff -u gyrus-0.3.10/debian/changelog gyrus-0.3.10/debian/changelog --- gyrus-0.3.10/debian/changelog +++ gyrus-0.3.10/debian/changelog @@ -1,3 +1,10 @@ +gyrus (0.3.10-1.2) unstable; urgency=low + + * Non-maintainer upload. + * Do not use floor, it causes a FTBFS. (Closes: #713631) + + -- Maarten Lankhorst maarten.lankho...@ubuntu.com Thu, 12 Dec 2013 10:27:55 + + gyrus (0.3.10-1.1) unstable; urgency=low * Non-maintainer upload. only in patch2: unchanged: --- gyrus-0.3.10.orig/debian/patches/713631.diff +++ gyrus-0.3.10/debian/patches/713631.diff @@ -0,0 +1,12 @@ +diff -ru gyrus-0.3.10/src/gyrus-report.c gyrus-0.3.10.new/src/gyrus-report.c +--- gyrus-0.3.10/src/gyrus-report.c2010-12-29 00:52:13.0 +0100 gyrus-0.3.10.new/src/gyrus-report.c2013-12-12 11:27:39.299266559 +0100 +@@ -407,7 +407,7 @@ + report = (GyrusReportData *) user_data; + + height = gtk_print_context_get_height (context) - HEADER_HEIGHT - HEADER_GAP - TITLE_HEIGHT - TITLE_GAP; +- report-lines_per_page = floor (height / report-font_size); ++ report-lines_per_page = (int)(height / report-font_size); + report-num_pages = (report-num_users - 1) / report-lines_per_page + 1; + gtk_print_operation_set_n_pages (operation, report-num_pages); + } -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719517: jitsi: FTBFS against libav9
Package: jitsi Version: 2.3.4687.9786-1 Followup-For: Bug #719517 Dear Maintainer, with libavfilter2 no longer available in testing or unstable, jitsi has become effectively uninstallable. I have been looking through the jitsi mailinglist archives (dev, user), but cannot find any further discussion of this issue. After the debconf talks and the announcement that jitsi got accepted into Debian, I convinced a lot of my immediate friends and family to try jitsi and have succesfully used it for cross-platform rtc (brilliant!). But having recently switched from Ubuntu to Debian testing, this issue renders it impossible to continue using it myself :-) Could you please provide a status update, or perhaps point to the relevant resources tracking progress if you feel this is not the right place to do so? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613843: Backport fix
Hello, Any chance that this issue can be fixed in the stable release? (or is there ant indication that the testing version is going to be stable anytime soon?) Basically the patch to fix this issue is in the upstream report: http://trac.edgewall.org/ticket/8897 namely changeset http://trac.edgewall.org/changeset/8646 This changeset is the next one after svn8365 (for trac mercurial plugin), so backporting this issue is basically upgrading the trac-mercurial package to version 0.11.0.8+svn8646 Thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646699: btrfs: Installer offers BTRFS an optional filesystem
Package: btrfs Severity: critical Justification: causes serious data loss BTRFS shouldn't be offert as a option filesystem in the debian installer. It is unsafe to use. Quallity is poor. No recovery possible on filesystem errors. (The btrfs driver will even crash on a filesystem error) The provided tool btrfsck doesn't actually do anything. There doesn't seem to be any progres on a working btrfsck. Atleased users should be warned to not use it, unless they don't care about dataloss -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502357: [libpam-mount] pammount doesn't mount loopback filesystem after upgrade
Package: libpam-mount Version: 0.48-1 Severity: grave --- Please enter the report below this line. --- Hi, I upgraded my Debian/Sid today and my pam-mount doesn't mount my loopback AES encrypted home partition anymore. At login, it gives this error: login: crypto.c:213: decrypted_key: Assertion `ret == 0` failed. Because I can manually mount the partition as root (with encryption), I expect the problem to be in pam-mount. Inside my pam_mount.conf.xml: volume user=user1 fstype=auto path=/dev/sda10 mountpoint=/home options=noexec,loop,encryption=aes256 fskeycipher=aes-256-cbc fskeypath=/etc/security/user1.key / If I look at the error-message, it seems a developer piece of code isn't removed... is that correct? And how can I fix this? Thanks! --- System information. --- Architecture: amd64 Kernel: Linux 2.6.26-1-amd64 Debian Release: lenny/sid 500 unstableftp.nl.debian.org --- Package information. --- Depends(Version) | Installed -+-== libc6 (= 2.7-1) | 2.7-15 libhx14 | 1.25-1 libpam0g (= 0.99.7.1) | 1.0.1-4+b1 libssl0.9.8(= 0.9.8f-5) | 0.9.8g-13 libxml2 (= 2.6.27) | 2.6.32.dfsg-4 mount(= 2.12-3) | 2.13.1.1-1 libxml-writer-perl | 0.604-1 debconf | 1.5.24 signature.asc Description: OpenPGP digital signature
Bug#432009: artwiz-cursor: Cause of this problem
Package: artwiz-cursor Followup-For: Bug #432009 This problem is caused by the fact that xcursor-themes is not yet installed. This package should be made to depend on xcursor-themes. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-ck1 (SMP w/1 CPU core; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages artwiz-cursor depends on: ii x11-common1:7.2-5X Window System (X.Org) infrastruc ii xfonts-utils 1:1.0.1-2 X Window System font utility progr artwiz-cursor recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418021: kl
Hi, IDL [1] also segfaults when running on libx11-6 1.0.3-7. Strace-log is attached. When downgrading to 1.0.3-4, the problems goes away. [1] http://www.ittvis.com/idl/ -- ~~~ Wireless Community Camp 2007 http://www.wifisoft.org ~~~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
