Bug#826818: kimageformats: OpenJPEG removal
Source: kimageformats Severity: important User: ma...@debian.org Usertags: stretch2000 This is a continued operation since src:jasper removal for stretch release. src:openjpeg will be removed from Debian for the stretch release (and following that, the archive in general). For more information see: http://bugs.debian.org/826805 It has been superseeded by src:openjpeg2 Your package uses src:openjpeg, so please either remove the JPEG2000 functionality or move to the new API. This bug will be bumped to release-critical status in a few weeks. Cheers, Mathieu
Bug#826808: calligra: OpenJPEG removal
Source: calligra Severity: important User: ma...@debian.org Usertags: stretch2000 This is a continued operation since src:jasper removal for stretch release. src:openjpeg will be removed from Debian for the stretch release (and following that, the archive in general). For more information see: http://bugs.debian.org/826805 It has been superseeded by src:openjpeg2 Your package uses src:openjpeg, so please either remove the JPEG2000 functionality or move to the new API. This bug will be bumped to release-critical status in a few weeks. Cheers, Mathieu
Bug#791485: symbols file: arch-bits=32|64 vs subst
Hi Lisandro, On Tue, Sep 15, 2015 at 3:50 PM, Lisandro Damián Nicanor Pérez <perezme...@gmail.com> wrote: > tag 791485 wontfix > thanks > > tl;dr: we still need to support qt4' qreal. > > On Tuesday 15 September 2015 15:13:29 Mathieu Malaterre wrote: >> Hi, >> >> [For some reason I never received your -submitter@b.d.o email] > > Sometimes mails get lost, it also happens to me from time to time. > >> > For what I understand of your bug report arch-bits it's simply 32 or 64. >> > The problem is that it's not as simple as that. There are differences >> > between archs that use the same amount of bits. >> :q! >> Could you name a single example in Debian archs ? >> >> Thx much. > > Take a look at <https://wiki.debian.org/ArchitectureSpecificsMemo>, first > table. Good. I see that sizeof (void*) is either 4 or 8 (which is how I understand `arch-bits` implementation) > An example was s390 and s390x which share the size of some types, like size_t. > While s390 is no longer a release arch it makes an example of something that > might happen again. So yes, we can now say this is a storical reason, but was > valid for quite some time. > > See the full table of conversions in: > > pkg-kde-tools/perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm As per my original post, I never said I wanted `subst` behavior. I said I wanted a merge mechanism based on `arch-bits`. > Another offender is qreal for qt4 apps, which we still need to support, and so > we need to keep this until we get rid of qt4... if we ever do. That's KDE-specific. There is no such thing as qreal in C++. > And if we do change this we would need to fix tons of packages... Sorry failed to understand you. > My suggestion is to really try to get a symbols generator directly in dpkg. I > would keep the possibility of not depending just on the arch-bits because > history has shown us that exceptions might happen. But that's up to the > implementer... until a new arch arrives ;) Ok. I've totally failed to follow you. Here is a simple one liner from dpkg-gensymbols file. The man page states: [...] The architecture-bits is either 32 or 64. (arch-bits=32)a_32bit_specific_symbol@Base 1.0 (arch-bits=64)a_64bit_specific_symbol@Base 1.0 [...] This is a strict *or*. As per my understanding one said arch is either `arch-bits=32` or `arch-bits=32`. So you are saying that for a said `arch-bits` (let's say 32) with a particular said function, you are saying the symbols for this C or C++ function will be different on another `arch-bits=32` ? Could you please take me by the hand and show me such function (C or C++, no KDE typedef please) ? Regards.
Bug#791485: symbols file: arch-bits=32|64 vs subst
Hi, [For some reason I never received your -submitter@b.d.o email] > For what I understand of your bug report arch-bits it's simply 32 or 64. The > problem is that it's not as simple as that. There are differences between > archs that use the same amount of bits. Could you name a single example in Debian archs ? Thx much.
Bug#791485: symbols file: arch-bits=32|64 vs subst
Package: pkg-kde-tools Version: 0.15.18 The current status of c++ symbols file in debian is that there is a single symbols generator (http://pkg-kde.alioth.debian.org/symbolfiles.html). Right now the strategy for merging symbols is using the `subst` keyword, however `subst` is a kde-* extension since it has never been integrated in dpkg (#533916). Would it be possible to have a different merging strategy based on `arch-bits` instead ? This would allow external kde-* packages to have simple management of c++ symbols files (eg.: vtk, openvdb, gdcm, openexr, ilmbase...), without adding build-dependencies on pkg-kde-tools. Feel free to re-assign to dpkg, if there is a strong reason for having `subst` support over `arch-bits=32|64` in pkg-kde-tools. Thanks for comments.
Bug#786969: pkgkde-symbolshelper batchpatch corrupts symbols file
Hi Lisandro ! On Wed, May 27, 2015 at 6:27 PM, Lisandro Damián Nicanor Pérez perezme...@gmail.com wrote: tag 786969 moreinfo thanks Hi Mathieu! Can you check the version of dpkg used in the build process? It might be related to that. I have the *exact* same output using a jessie or a sid chroot. So in my case: jessie: $ apt-cache policy dpkg dpkg: Installed: 1.17.25 Candidate: 1.17.25 Version table: *** 1.17.25 0 700 http://ftp.fr.debian.org/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status sid: $ apt-cache policy dpkg dpkg: Installed: 1.18.0 Candidate: 1.18.0 Version table: *** 1.18.0 0 500 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status IMHO, I suspect the issue lie instead in the merging of symbols (remember that the first dpkg-gensymbols generated file is ok), so I suspect: [...] pkgkde-symbolshelper: info: ambiguous symbols for subst detection (_ZNSt6vectorImSaImEE14_M_dlll_lnsertEN9__gnu_cll17__normal_lteratorIPmS1_EEmRKm@Base/libIlmImf.so.6). [...] indicate an error instead of just an information. It is hard to give more details as `pkgkde-symbolshelper` does not seems to be documented (no man page AFAIK) Comments ? -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+7wuszptffwwenbsfhs75smzqftujxjeoutb2q9c9+f8df...@mail.gmail.com
Bug#714768: documentation ?
On Mon, May 18, 2015 at 2:08 PM, Mathieu Malaterre ma...@debian.org wrote: Just for the record, getbuildlog currently supports this. Could someone please document this ? Currenly my ilmbase symbol file does not work on ports: http://buildd.debian-ports.org/status/package.php?p=ilmbasesuite=experimental Would have been nice to download them as well. FYI, instructions from: https://pkg-kde.alioth.debian.org/symbolfiles.html [Section Updating multiple symbols files at once] Simply change: $ pkgkde-getbuildlogs $ pkgkde-symbolshelper batchpatch -v 1.8 foo_unstable_logs/foo_1.8-1*.build into $ getbuildlog foo last-all $ pkgkde-symbolshelper batchpatch -v 1.8 foo*.log -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsz6D0VRnMgtAN1J4tJQ3PSUw8VgBNLZweKOb6yNzxV5=a...@mail.gmail.com
Bug#786969: pkgkde-symbolshelper batchpatch corrupts symbols file
Package: pkg-kde-tools Version: 0.15.17 Severity: important I have a case where running `pkgkde-symbolshelper batchpatch` actually breaks the symbols file. So I thought I should fill in an important bug report (this basically breaks assumption for this tool). Steps were done from a sid chroot (today): $ apt-get source openexr $ git clone git://anonscm.debian.org/pkg-phototools/openexr.git $ cd openexr $ rm debian/libopenexr6.symbols $ dpkg-buildpackage -rfakeroot -us -uc $ pkgkde-gensymbols -plibopenexr6 -v1.6.1 -Osymbols.amd64 -edebian/libopenexr6/usr/lib/x86_64-linux-gnu/libIlmImf.so.6.0.0 $ pkgkde-symbolshelper create -o debian/libopenexr6.symbols -v 1.6.1 symbols.amd64 At this point everything is fine ! However if one does now: $ pkgkde-getbuildlogs $ pkgkde-symbolshelper batchpatch -v 1.6.1 openexr_experimental_logs/openexr_1.6.1-10_*.build Looking for patches and reading them -- | Processing libopenexr6 package | -- Patching symbol file 'debian/libopenexr6.symbols' with supplied patches ... * patch 'libopenexr6_1.6.1-10_arm64 (--- debian/libopenexr6.symbols)' for arm64 ... OK. * patch 'libopenexr6_1.6.1-10_armel (--- debian/libopenexr6.symbols)' for armel ... OK. * patch 'libopenexr6_1.6.1-10_armhf (--- debian/libopenexr6.symbols)' for armhf ... OK. * patch 'libopenexr6_1.6.1-10_hurd-i386 (--- debian/libopenexr6.symbols)' for hurd-i386 ... OK. * patch 'libopenexr6_1.6.1-10_i386 (--- debian/libopenexr6.symbols)' for i386 ... OK. * patch 'libopenexr6_1.6.1-10_kfreebsd-i386 (--- debian/libopenexr6.symbols)' for kfreebsd-i386 ... OK. * patch 'libopenexr6_1.6.1-10_mipsel (--- debian/libopenexr6.symbols)' for mipsel ... OK. * patch 'libopenexr6_1.6.1-10_powerpc (--- debian/libopenexr6.symbols)' for powerpc ... OK. * patch 'libopenexr6_1.6.1-10_ppc64el (--- debian/libopenexr6.symbols)' for ppc64el ... OK. * patch 'libopenexr6_1.6.1-10_s390x (--- debian/libopenexr6.symbols)' for s390x ... OK. Confirmed arches: amd64 Generating symbol file template (this might take a while) pkgkde-symbolshelper: info: ambiguous symbols for subst detection (_ZNSt6vectorImSaImEE14_M_dlll_lnsertEN9__gnu_cll17__normal_lteratorIPmS1_EEmRKm@Base/libIlmImf.so.6). Processed by name: (optional=templinst|arch=!amd64 !arm64 !ppc64el !s390x)_ZNSt6vectorIjSaIjEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPjS1_EEjRKj@Base 1.6.1-10 (optional=templinst|arch=amd64 arm64 ppc64el s390x)_ZNSt6vectorImSaImEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPmS1_EEmRKm@Base 1.6.1 (optional=templinst|arch=!amd64 !arm64 !ppc64el !s390x)_ZNSt6vectorIySaIyEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPyS1_EEjRKy@Base 1.6.1-10 pkgkde-symbolshelper: info: architecture set changed for the symbols below: SONAME: libIlmImf.so.6 (optional=templinst|arch=amd64 hurd-i386 i386 kfreebsd-i386 mipsel)_ZNK5Imath8Matrix44IfE7inverseEb@Base 1.6.1 (was arch=) (optional=templinst|arch=amd64 hurd-i386 i386 kfreebsd-i386 mipsel)_ZNK5Imath8Matrix44IfE9gjInverseEb@Base 1.6.1 (was arch=) (optional=templinst|arch=amd64 arm64 ppc64el s390x)_ZNSt6vectorImSaImEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPmS1_EEmRKm@Base 1.6.1 (was arch=) (optional=templinst|arch=amd64 arm64 ppc64el)_ZNSt8_Rb_treeIN3Imf4NameESt4pairIKS1_NS0_5SliceEESt10_Select1stIS5_ESt4lessIS1_ESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERS3_@Base 1.6.1 (was arch=) (optional=templinst|arch=amd64 arm64 ppc64el)_ZNSt8_Rb_treeIN3Imf4NameESt4pairIKS1_NS0_7ChannelEESt10_Select1stIS5_ESt4lessIS1_ESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERS3_@Base 1.6.1 (was arch=) (optional=templinst|arch=amd64 arm64 ppc64el)_ZNSt8_Rb_treeIN3Imf4NameESt4pairIKS1_PNS0_9AttributeEESt10_Select1stIS6_ESt4lessIS1_ESaIS6_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS6_ERS3_@Base 1.6.1 (was arch=) Later on it can be checked that the newly generated symbols file is now incorrect on amd64: $ dpkg-buildpackage -rfakeroot -us -uc [...] make[1]: Leaving directory '/home/mathieu/debian/pkg-phototools/openexr' dh_fixperms dh_strip dh_makeshlibs dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libopenexr6/DEBIAN/symbols doesn't match completely debian/libopenexr6.symbols --- debian/libopenexr6.symbols (libopenexr6_1.6.1-11_amd64) +++ dpkg-gensymbolsL6TwTs 2015-05-27 09:49:11.856519399 + @@ -1,4 +1,3 @@ -# SymbolsHelper-Confirmed: 1.6.1 amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-i386 mipsel powerpc ppc64el s390x libIlmImf.so.6 libopenexr6 #MINVER# ImfApplyLut@Base 1.6.1 ImfCloseInputFile@Base 1.6.1 @@ -167,7 +166,8 @@ _ZN3Imf11FrameBufferixEPKc@Base 1.6.1 _ZN3Imf11StdIFStream4readEPci@Base 1.6.1 _ZN3Imf11StdIFStream5clearEv@Base 1.6.1 -
Bug#786969: pkgkde-symbolshelper batchpatch corrupts symbols file
On Wed, May 27, 2015 at 11:50 AM, Mathieu Malaterre ma...@debian.org wrote: [...] At this point everything is fine ! However if one does now: Another way to get this symbols file is from -10: $ dget -u http://snapshot.debian.org/archive/debian/20150402T213401Z/pool/main/o/openexr/openexr_1.6.1-10.dsc $ cd openexr-1.6.1 $ crc32 debian/libopenexr6.symbols 84ff0e5a debian/libopenexr6.symbols In other words, I've uploaded to debian autobuilders the symbols file generated by the above steps (using pkgkde-gensymbols+pkgkde-symbolshelper). -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+7wusystnnlyrwy3m11rvj8thipyyxcfn5n+lwfm9m...@mail.gmail.com
Bug#714768: documentation ?
Just for the record, getbuildlog currently supports this. Could someone please document this ? Currenly my ilmbase symbol file does not work on ports: http://buildd.debian-ports.org/status/package.php?p=ilmbasesuite=experimental Would have been nice to download them as well. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsxoSMu0q8qjVdbiT9MbGBHC_uUPH=cdwezd4w5o891...@mail.gmail.com
Re: Uploads/Rebuilds for sip4 update
On Wed, May 8, 2013 at 10:37 AM, Scott Kitterman deb...@kitterman.com wrote: I plan on coordinating this with the release team to get the binNMUs scheduled and dealing with fixing python-qt4/pykde4. I'm not sure what to do about serna. Leave it as-is. serna has been abandonned by upstream, serna-free never transitioned to testing. The package will need to be either removed and/or forked by new maintainers (upstream). Thanks. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsz3VXz4E11+m95=wsm-hw6gzo-jjsmp+kahlopdouj...@mail.gmail.com
Bug#624179: eigen2: New upsteam: 3.0.0
Package: eigen2 Version: 3.0.0 Severity: normal Tags: upstream Hi ! It would be nice to package eigen 3.0.0: http://eigen.tuxfamily.org/index.php?title=Main_Page#Download http://eigen.tuxfamily.org/index.php?title=3.0 There will be an API change: http://eigen.tuxfamily.org/dox/Eigen2ToEigen3.html Thanks ! -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426081138.11612.85201.report...@virtlap.malat.net
Bug#369835: qt4-x11: uninstallable with nvidia-glx-dev
Brian, Can I reassign a bug to a different package or is this locked ? Sorry for the noise, Mathieu On 6/1/06, Brian Nelson [EMAIL PROTECTED] wrote: severity 369835 normal thanks [Problems involving non-free packages are not RC bugs] Mathieu Malaterre [EMAIL PROTECTED] writes: Package: qt4-x11 Severity: grave Justification: renders package unusable I simply cannot install qt4-x11, therefore I cannot get the libQtAssistantClient libraries (Bug #355902). Why would this be qt4's problem? I'd think nvidia-glx-dev would be the one that needs fixing. -- Captain Logic is not steering this tugboat. -- Mathieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369835: qt4-x11: uninstallable with nvidia-glx-dev
Package: qt4-x11 Severity: grave Justification: renders package unusable I simply cannot install qt4-x11, therefore I cannot get the libQtAssistantClient libraries (Bug #355902). Step to reproduce: $ sudo apt-get build-dep qt4-x11 Reading package lists... Done Building dependency tree... Done The following packages will be REMOVED nvidia-glx-dev The following NEW packages will be installed libmysqlclient15-dev libpq-dev libsqlite0-dev libssl-dev xlibmesa-gl-dev 0 upgraded, 5 newly installed, 1 to remove and 0 not upgraded. Need to get 8858kB/9603kB of archives. After unpacking 26.8MB of additional disk space will be used. Do you want to continue [Y/n]? n Abort. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (989, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
