Bug#1070703: transition: libunibreak
Package: release.debian.org Severity: normal X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for the update of the libunibreak library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in this case there are only few new symbols. There are few users of libunibreak in Debian: - fbreader - krita - libass I verified that all of them build fine using the new version of libunibreak. Ben file: title = "libunibreak"; is_affected = .depends ~ "libunibreak5" | .depends ~ "libunibreak6"; is_good = .depends ~ "libunibreak6"; is_bad = .depends ~ "libunibreak5"; Thanks, -- Pino
Bug#1052253: transition: libunibreak
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak Hi, I'd like to request a transition slot for the much needed update of the libunibreak library (from 1.1 to 5.1). The only dependency in Debian is fbreader, which I verified that builds fine using the new version of libunibreak. Ben file: title = "libunibreak"; is_affected = .depends ~ "libunibreak1" | .depends ~ "libunibreak5"; is_good = .depends ~ "libunibreak5"; is_bad = .depends ~ "libunibreak1"; Thanks, -- Pino
Bug#1052252: transition: grantlee5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: grantl...@packages.debian.org, pkg-kde-t...@alioth-lists.debian.net Control: affects -1 + src:grantlee5 Hi, grantlee (packaged in Debian in src:grantlee5) is a library (two libraries, in practice) that has a stable API/ABI. The new release 5.3.x, currently in experimental, is generally usable by users built with the old version. The only gotcha is that plugins for it are installed and loaded from paths with the major and minor version in it, i.e. ../plugins/grantlee/./ This means that, after the upgrade to a new minor series, the plugins installed after building with the old version are not used anymore; usually software using grantlee and shipping plugins for it follows the grantlee version, so a simple rebuild is enough to fix the issue. Since I wanted to avoid uploading the new version and have to manually track external plugins and breaking users that rely on those plugins, I created a new simple dh_grantlee helper to track the dependency on the version the plugins were built for, adding the provide for it in one of the two grantlee libraries as "grantlee5-templates-MAJOR-MINOR". This is already in place in unstable starting from grantlee5 5.2.0-5, and the 4 sources that install plugins for it were already changed to use dh_grantlee, and thus now properly track their plugin dependency. Hence, I'd like to request a transition slot for uploading grantlee5 5.3.x to unstable, rebuilding the few dependencies needed: - kcalutils - kdevelop - libkf5grantleetheme - skrooge They all build fine with the new grantlee; I have the new version of kdevelop ready in experimental, and I can upload that rather than rebuilding the current version in unstable. Ben file: title = "grantlee5"; is_affected = .depends ~ "grantlee5-templates-5-2" | .depends ~ "grantlee5-templates-5-3"; is_good = .depends ~ "grantlee5-templates-5-3"; is_bad = .depends ~ "grantlee5-templates-5-2"; Thanks, -- Pino
Bug#1040418: nmu: libheif_1.16.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libh...@packages.debian.org, ba...@struktur.de, sramac...@debian.org Control: affects -1 + src:libheif nmu libheif_1.16.2-1 . ANY . unstable . -m "rebuild on buildd" Please rebuild libheif (on all architectures, as it has M-A:same binaries), so it can migrate to testing; kimageformat will need it soon. Thanks, -- Pino
Bug#1014502: nmu: labplot_2.9.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, I just started a very small transition affecting cantor & labplot; I checked in advance that it should not affect existing transitions, nor it is affected by any currently ongoing. The new cantor was already uploaded and installed on all the architectures (which are few, as it requires Qt WebEngine). labplot builds fine with the new cantor (I checked this too). Hence, please: nmu labplot_2.9.0-1 . amd64 arm64 armhf i386 mips64el mipsel . unstable . -m "rebuild with cantor 22.04" Thanks, -- Pino
Bug#1013679: nmu: xq_0.0.7-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please rebuild xq on amd64 after it was accepted from NEW; it is a simple tool, so rebuilding it only on amd64 is enough. nmu xq_0.0.7-1 . amd64 . unstable . -m "rebuild on buildd" Thanks, -- Pino
Bug#992759: nmu: tagua_1.0~alpha2-16-g618c6a0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild tagua in unstable against the libkdegames recently uploaded. tagua builds fine with the newer libkdegames. nmu tagua_1.0~alpha2-16-g618c6a0-3 . ANY . unstable . -m "rebuild for libkdegames 21.08.0 (libkf5kdegamesprivate7)" Thanks, -- Pino
Bug#992758: nmu: calamares_3.2.36-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild calamares in unstable against the newer kpmcore recently uploaded. calamares builds fine with the newer kpmcore. nmu calamares_3.2.36-1 . ANY . unstable . -m "rebuild against kpmcore 21.08.0 (libkpmcore11)" Thanks, -- Pino
Bug#992757: nmu: qtwebview-opensource-src_5.15.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild qtwebview-opensource-src in unstable for the new qtwebengine 5.15.5 recently uploaded, so it depends on the new internal ABI dependency. qtwebview builds fine with the newer qtwebengine. nmu qtwebview-opensource-src_5.15.2-2 . ANY . unstable . -m "rebuild with qtwebengine-opensource-src 5.15.5 (qtwebengine-abi-5-15-5)" Thanks, -- Pino
Re: Plasma transition to testing
In data domenica 27 dicembre 2020 11:03:52 CET, Norbert Preining ha scritto: > Hi Graham, > > > If you are referring to the 'Test in progress' status for > > systray-mdstat/1.1.0-1, then I think you just need to wait. Debian > > CI's Pending Jobs page [1], shows it was requested on: > > 2020-12-26 09:10:46 UTC | 23 hour(s) ago > > Ok, then I don't get it: > * plasma-workspace does not mention systray-mdstat anywhere > * systray-mdstat does not mention plasma-workspace anywhere > (just checked the git repo of current and version 1.1.0-1) > None of the two programs depend on each other in either B-D or D, none > has a test somehow at least for what I see, and looking a previous > ci tests > https://ci.debian.net/packages/s/systray-mdstat/testing/armhf/ > the only ones are from perl. Because systray-mdstat depends on notification-daemon, and plasma-workspace provides notification-daemon, so the CI checks that the plasma-workspace update does not break systray-mdstat. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#960193: ICU rebuilds in experimental
Hi, can you please rebuild for the ICU transition also the packages in experimental? I see the following sources, at least on amd64: dcmtk gnustep-base gnustep-gui libqalculate performous qtbase-opensource-src qtlocation-opensource-src qtwebkit-opensource-src webkit2gtk zimwriterfs Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#952886: mini-transition: okular
In data lunedì 2 marzo 2020 11:50:24 CET, Emilio Pozuelo Monfort ha scritto: > On 01/03/2020 15:36, Pino Toscano wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi, > > > > this is a very small transition: the new version of okular bumps the > > SONAME of the okular core library, and the only user of it is calligra. > > > > calligra builds fine with the newer okular core library, and at the > > moment it does not seem involved in other transitions. > > Go ahead. Uploaded yesterday, and built everywhere. Feel free to schedule the calligra binNMU at your convenience. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#952886: mini-transition: okular
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, this is a very small transition: the new version of okular bumps the SONAME of the okular core library, and the only user of it is calligra. calligra builds fine with the newer okular core library, and at the moment it does not seem involved in other transitions. Ben file: title = "okular"; is_affected = .depends ~ "libokular5core8" | .depends ~ "libokular5core9"; is_good = .depends ~ "libokular5core9"; is_bad = .depends ~ "libokular5core8"; Thanks, -- Pino
Bug#949326: [Pkg-kde-extras] Bug#949326: transition: libgwenhywfar
In data lunedì 20 gennaio 2020 22:10:38 CET, Micha Lenk ha scritto: > Control: tags -1 moreinfo > > On 20.01.20 09:52, Pino Toscano wrote: > > Since you are already updating Gwenhywfar, can you please update it to > > the newly released 5.1.2? > > Just uploaded to experimental. Thanks! > > The newly released version of KMyMoney (5.0.8) requires: > > - Gwenhywfar >= 5.1.2 > > - AqBanking >= 6.0.1 > > I looked into that and just realized this version of AqBanking did a > SONAME bump as well. This means its uploads will go through NEW. :( Ouch... OTOH, the AqBanking transition is basically a subset of the Gwenhywfar transition, so packing these two transitions together should simplify things a bit. Considering the requirements of KMyMoney 5.0.8, I will upload this new version once the Gwenhywfar/AqBanking transition starts -- let me know when that happens. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#949326: [Pkg-kde-extras] Bug#949326: transition: libgwenhywfar
In data domenica 19 gennaio 2020 20:56:32 CET, Micha Lenk ha scritto: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi release team, > > The Gwenhywfar package got its SONAME bumped in a recent release because some > deprecated API functions got removed. For this reason its reverse dependencies > need to be rebuilt at least. Since you are already updating Gwenhywfar, can you please update it to the newly released 5.1.2? The newly released version of KMyMoney (5.0.8) requires: - Gwenhywfar >= 5.1.2 - AqBanking >= 6.0.1 > * https://tracker.debian.org/kmymoney will need a binNMU to pick up the new > SONAME from libgwenhywfar. Did you rebuild KMyMoney with the new Gwenhywfar? Does it build fine? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#942415: Calligra and Akonadi
In data domenica 17 novembre 2019 13:59:59 CET, Sandro Knauß ha scritto: > thanks for your last update of calligra! That at least makes it build again > *yeah* But for me it seems like, the whole Akonadi dependency isn't used at > all. Sure, it is only checked at cmake time, and apparently not actually used. > Why this is not built and shipped and still we have the dependency? I do not see any akonadi dependency in the binary packages, can you please explain exactly what you see? > calligra is identified as fake candidate (for the moment) every reverse > dependency is built correctly and it is nothing to do left expect for wait > till kdepim will go to testing. > > Just for the record, for thise who are not familiar with the other red > crosses: > libkf5sieve, kf5-messagelib, kmail, libkf5mailcommon and kmail can only be > built for 5 archs, that are supported by qtwebengine. This is because the tracker for the transition is partially wrong: - it considers "affected" all the sources that only build-depend on PIM packages: while this is generally correct, it ought to check both the actual bad _and_ good runtime dependencies instead - the "good" check seems correctly checking for the "new library names" - the "bad" check is basically "everything that does not depend on depend on the new names"... which is wrong -- it ought to explicitly check for the _old_ names instead - also I see whitespaces in all the regexps in the HTML page of the transition -- not sure whether it is actually like that in the ben file, or just a glitch in the HTML page This would explain why: - calligra is considered "bad" - libkf5sieve, kf5-messagelib, kmail, libkf5mailcommon, and kmail are considered "bad" in all the architectures where they are not actually built - maybe (although I'm not sure about this) also all the "?!" states Please fix the ben file for this transition, so its status can be checked properly. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#917196: qtbase 5.11.2 binNMUs in experimental
Hi, while the transition is over in unstable, there are still things to do in experimental. Can you please issue binNMUs for affected packages there? There should be only kmymoney. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#903853: transition: removal of nepomuk support from src:kde4libs
In data lunedì 30 luglio 2018 07:25:08 CEST, Pino Toscano ha scritto: > In data sabato 28 luglio 2018 10:16:15 CEST, Emilio Pozuelo Monfort ha > scritto: > > Control: tags -1 confirmed > > > > On 15/07/18 22:33, Pino Toscano wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Hi, > > > > > > I'd like to remove the support for Nepomuk in src:kde4libs. > > > > > > Since Nepomuk has been deprecated, and already unused in Debian for > > > quite some time, this allows us to drop src:soprano & > > > src:shared-desktop-ontologies. The result is the drop of 3 library > > > packages from src:kde4libs: libnepomuk4, libnepomukquery4a, and > > > libnepomukutils4. > > > > > > The reason of this transition is that libnepomuk was so far listed as > > > public library dependency for the kde4 versions of kio (libkio5), and > > > kparts (libkparts4), resulting in overlinking. Fortunately, almost all > > > the packages either already link in as-needed more, or switched to KDE > > > Frameworks 5. The only exception is src:kpartsplugin. > > > > > > Hence, the plan is the following: > > > 1) upload src:kde4libs without Nepomuk support > > > 2) binNMU src:kpartsplugin > > > > > > I verified that src:kpartsplugin builds fine even without Nepomuk > > > libraries, effectively not linking against them anymore. I also did > > > a rebuild of all the other sources still using kdelibs 4.x, and there > > > were no changes in their build. > > > > > > PS: since I uploaded kde4libs 4:4.14.38-1 yesterday, I'd wait for it to > > > migrate to testing, first. > > > > Please go ahead. > > Uploaded two days ago, and built everywhere now. Can you please > schedule the binNMUs for kpartplugins? Anyone in release-team: considering Emilio is not around this week, can you please schedule this binNMU? Thanks in advance, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#904777: transition: libraw
In data sabato 28 luglio 2018 10:13:19 CEST, Emilio Pozuelo Monfort ha scritto: > Control: tags -1 confirmed > > On 27/07/18 23:05, Matteo F. Vescovi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear Release Team, > > > > I'm filing this bug for a new transition of libraw package. > > > > On June 29, 2018 the 0.19.0 stable version has been released by > > upstream. > > > > On July 23 and 26, 2018 a couple of testing-purpose packages has been > > uploaded to experimental, the first as first attempt to check the > > packaging on all architectures, the latter to fix a bunch of FTBFS due > > to C++ symbols. > > > > So, following the auto-libraw checklist[1], here is the list of source > > packages reverse-depending on libraw and the results of the builds: > > > > * deepin-image-viewer_1.2.23-1 => OK > > * efl_1.20.7-6 => OK > > * entangle_0.7.2-1 => OK > > * fotoxx_18.01.1-2 => OK > > * freeimage_3.17.0+ds1-5 => OK > > * gegl_0.4.2-1 => OK > > * gthumb_3:3.6.1-1 => OK > > * krita_1:4.1.1+dfsg-1 => FTBFS > > * kstars_5:2.9.6-1 => FTBFS > > * libkf5kdcraw_17.08.3-1 => FTBFS > > * luminance-hdr_2.5.1+dfsg-3 => OK > > * nomacs_3.10.2+dfsg-1 => OK > > * openimageio_1.8.12~dfsg0-1 => OK > > * shotwell_0.28.3-1 => OK > > * siril_0.9.9-1 => OK > > > > All the FTBFS (3) are caused by some changes in libraw 0.19.0 compared > > to older 0.18.xx version. > > Go ahead and please file bug against those three packages and make them block > this one. Other than what Lisandro said in #905032 [1], note that due to the involved packages this means entangling the libraw transition with the Qt 5.11 one. So please wait at least for the completion of the Qt 5.11 transition, and possibly also for the fixes to the above FTBFSes (which are either not even reported upstream, or just recently reported). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905032#14 Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#903853: transition: removal of nepomuk support from src:kde4libs
In data sabato 28 luglio 2018 10:16:15 CEST, Emilio Pozuelo Monfort ha scritto: > Control: tags -1 confirmed > > On 15/07/18 22:33, Pino Toscano wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi, > > > > I'd like to remove the support for Nepomuk in src:kde4libs. > > > > Since Nepomuk has been deprecated, and already unused in Debian for > > quite some time, this allows us to drop src:soprano & > > src:shared-desktop-ontologies. The result is the drop of 3 library > > packages from src:kde4libs: libnepomuk4, libnepomukquery4a, and > > libnepomukutils4. > > > > The reason of this transition is that libnepomuk was so far listed as > > public library dependency for the kde4 versions of kio (libkio5), and > > kparts (libkparts4), resulting in overlinking. Fortunately, almost all > > the packages either already link in as-needed more, or switched to KDE > > Frameworks 5. The only exception is src:kpartsplugin. > > > > Hence, the plan is the following: > > 1) upload src:kde4libs without Nepomuk support > > 2) binNMU src:kpartsplugin > > > > I verified that src:kpartsplugin builds fine even without Nepomuk > > libraries, effectively not linking against them anymore. I also did > > a rebuild of all the other sources still using kdelibs 4.x, and there > > were no changes in their build. > > > > PS: since I uploaded kde4libs 4:4.14.38-1 yesterday, I'd wait for it to > > migrate to testing, first. > > Please go ahead. Uploaded two days ago, and built everywhere now. Can you please schedule the binNMUs for kpartplugins? Thanks, -- Pino Toscano
Bug#903853: transition: removal of nepomuk support from src:kde4libs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to remove the support for Nepomuk in src:kde4libs. Since Nepomuk has been deprecated, and already unused in Debian for quite some time, this allows us to drop src:soprano & src:shared-desktop-ontologies. The result is the drop of 3 library packages from src:kde4libs: libnepomuk4, libnepomukquery4a, and libnepomukutils4. The reason of this transition is that libnepomuk was so far listed as public library dependency for the kde4 versions of kio (libkio5), and kparts (libkparts4), resulting in overlinking. Fortunately, almost all the packages either already link in as-needed more, or switched to KDE Frameworks 5. The only exception is src:kpartsplugin. Hence, the plan is the following: 1) upload src:kde4libs without Nepomuk support 2) binNMU src:kpartsplugin I verified that src:kpartsplugin builds fine even without Nepomuk libraries, effectively not linking against them anymore. I also did a rebuild of all the other sources still using kdelibs 4.x, and there were no changes in their build. PS: since I uploaded kde4libs 4:4.14.38-1 yesterday, I'd wait for it to migrate to testing, first. Ben file: title = "kde4libs without nepomuk"; is_affected = .depends ~ /\blibnepomuk/; is_good = ''; is_bad = .depends ~ /\blibnepomuk/; Thanks, -- Pino
Re: Help on meta-kde and kde-baseapps migration
On lunedì 15 gennaio 2018 10:09:33 CET Emilio Pozuelo Monfort wrote: > On 13/01/18 18:13, Pino Toscano wrote: > > Dear release team, > > > > some days ago I uploaded src:meta-kde and src:kde-baseapps to unstable, > > and the things that "ties" them is that the kde-baseapps metapackage > > from src:kde-baseapps (in preparation of the future removal of it) to > > src:meta-kde. OTOH, they have not migrated to testing for the last 4 > > days, and I do not understand what is going on, and why they do not > > migrate to testing. > > > > Can you please help for this? > > trying: libkf5eventviews kcalcore libkolab kdepim-runtime kmbox kmime > kmailtransport kf5-messagelib kidentitymanagement pim-data-exporter kcontacts > akonadi-search kmail libkf5ksieve libkf5pimcommon kmail-account-wizard kldap > libkf5libkdepim akonadi-contacts akonadi kalarm kholidays kalarmcal meta-kde > kleopatra libkf5libkleo kpimtextedit kdepim-addons libkf5mailcommon > libkf5mailimporter akonadi-import-wizard mbox-importer akonadi-mime > akonadi-calendar korganizer libkf5incidenceeditor libkf5calendarsupport > kcalutils kf5-kdepim-apps-libs libkf5grantleetheme kontact akregator > syndication > kblog kaddressbook libkf5gravatar ktnef akonadi-notes kimap knotes -kdepim > blogilo akonadi-calendar-tools pim-sieve-editor zanshin akonadiconsole > libkgapi > skipped: libkf5eventviews kcalcore libkolab kdepim-runtime kmbox kmime > kmailtransport kf5-messagelib kidentitymanagement pim-data-exporter kcontacts > akonadi-search kmail libkf5ksieve libkf5pimcommon kmail-account-wizard kldap > libkf5libkdepim akonadi-contacts akonadi kalarm kholidays kalarmcal meta-kde > kleopatra libkf5libkleo kpimtextedit kdepim-addons libkf5mailcommon > libkf5mailimporter akonadi-import-wizard mbox-importer akonadi-mime > akonadi-calendar korganizer libkf5incidenceeditor libkf5calendarsupport > kcalutils kf5-kdepim-apps-libs libkf5grantleetheme kontact akregator > syndication > kblog kaddressbook libkf5gravatar ktnef akonadi-notes kimap knotes -kdepim > blogilo akonadi-calendar-tools pim-sieve-editor zanshin akonadiconsole > libkgapi > (0, 82, 286) > got: 37+0: a-2:i-24:a-0:a-0:a-0:m-0:m-10:m-0:p-0:s-1 > * mips64el: education-desktop-kde, kde-baseapps, kde-full, > kde-plasma-desktop, kde-standard, kf5-kdepimlibs-kio-plugins, > task-pkgs-are-installable-faux > > kf5-kdepimlibs-kio-plugins becomes uninstallable because kdepim-runtime breaks > it. I don't know if there are other problems with the other packages or if > they > break because they depend on kf5-kdepimlibs-kio-plugins. kf5-kdepimlibs-kio-plugins comes from src:kf5-kdepimlibs, which is obsolete with the new KDE PIM, see its RM #887074. Can you please try hinting it out of testing? > PS: any plans for switching kde to the new libical? src:kcalcore (Qt5) 17.12 supports libical 3.x, and it's part of the KDE PIM 17.12 stack which will be worked on once 17.08 migrates to testing... The other source is kdepimlibs, which is deprecated as Qt4, used less and less. It is basically dead upstream, so we will evaluate its state in a few months, once the release freeze approaches. kmymoney uses the PIM libraries too; at the moment it uses Qt4, so it is forced to use libical2 as well to avoid potential symbols clashes. Once it will be released as Qt5, it will use whatever kcalcore will use too (eventually switching at the same time with it). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: kdepim 17.08.3 and kde-l10n
Dear release team, On domenica 31 dicembre 2017 14:24:20 CET Pino Toscano wrote: > On domenica 31 dicembre 2017 14:03:56 CET Sandro Knauß wrote: > > Hey, > > > > I added the release team list, cause they may help explaining interpret the > > britney output. > > And help to find the right buttons to push, to get kdepim migrating to > > testing. > > > > > > I tried to understand, why kdepim hasn't moved to testing, but I don't > > > > understand the britney output completely. > > > > > > I don't either, but let's see. > > > > well I looked at the documentation to understand the output better: > > https://release.debian.org/doc/britney/short-intro-to-migrations.html > > > > But still I'm not completely sure how to interpret the output :D > > If I'm not wrong, than the first try to install complete kdepim as one set > > is the one we should care about: > > > > trying: kleopatra libkf5libkleo kmail-account-wizard libkf5pimcommon > > akonadi-contacts kf5-kdepim-apps-libs kaddressbook akonadi-search > > akonadi-mime libkf5mailcommon pim-data-exporter libkf5libkdepim > > libkf5eventviews libkf5calend > > arsupport kholidays kalarmcal kcalcore kdepim-runtime kmbox kmime > > kf5-messagelib kmailtransport akonadi-import-wizard kdepim-addons kimap > > kpimtextedit kidentitymanagement mbox-importer korganizer kcontacts ktnef > > kcalutils libkol > > ab akonadi kalarm kmail libkf5ksieve libkf5gravatar -kdepim kldap > > syndication kblog akregator libkf5grantleetheme kontact pim-sieve-editor > > libkf5incidenceeditor akonadi-calendar blogilo knotes > > akonadi-calendar-tools libkf5mailim > > porter akonadi-notes akonadiconsole libkgapi > > > > > > skipped: kleopatra libkf5libkleo kmail-account-wizard libkf5pimcommon > > akonadi-contacts kf5-kdepim-apps-libs kaddressbook akonadi-search > > akonadi-mime libkf5mailcommon pim-data-exporter libkf5libkdepim > > libkf5eventviews libkf5calen > > darsupport kholidays kalarmcal kcalcore kdepim-runtime kmbox kmime > > kf5-messagelib kmailtransport akonadi-import-wizard kdepim-addons kimap > > kpimtextedit kidentitymanagement mbox-importer korganizer kcontacts ktnef > > kcalutils libko > > lab akonadi kalarm kmail libkf5ksieve libkf5gravatar -kdepim kldap > > syndication kblog akregator libkf5grantleetheme kontact pim-sieve-editor > > libkf5incidenceeditor akonadi-calendar blogilo knotes > > akonadi-calendar-tools libkf5maili > > mporter akonadi-notes akonadiconsole libkgapi (6, 1706, 170) > > > > > > got: 39+0: a-2:i-24:a-0:a-0:a-0:m-0:m-3:m-0:p-0:s-10 > > > > > > * s390x: education-desktop-kde, kde-full, kde-standard, kdepim, > > kf5-kdepimlibs-kio-plugins, knotes, konsolekalendar, korganizer, > > task-pkgs-are-installable-faux > > > > - splitting the component into single items and retrying them > > > > If I compare the trying line with all packages inside kdepim i see, that > > grantlee-editor, kdav, kgpg and kontactinterface are missing in that list. > > kdav is already migrated. From kgpg and grantlee-editor nothing depends on, > > so we can skip them. > > The only missing package we care at this migration is kontactinterface, > > that explains, why korganizer, knotes will be uninstallable in testing. > > Maybe it is easier to see these dependencies in graphs: > > https://pkg-kde.alioth.debian.org/applications-17.08-build-deps.html > > Because both depend on kontactinterface. > > And because korganzier >= 17.08 won't be in testing konsolecalender can't > > migrate, because it breaks against korganzier <= 17.08. > > education-desktop-kde, kde-full, kde-standard look fine for me, possible, > > because of korganzier and knotes not migrating having issues. > > kdepim, kf5-kdepimlibs-kio-plugins both getting unstallable is fine, cause > > they should be removed form testing. > > What I noticed earlier is that kde-standard unconditionally depends on > kmail and akregator, and
Help on meta-kde and kde-baseapps migration
Dear release team, some days ago I uploaded src:meta-kde and src:kde-baseapps to unstable, and the things that "ties" them is that the kde-baseapps metapackage from src:kde-baseapps (in preparation of the future removal of it) to src:meta-kde. OTOH, they have not migrated to testing for the last 4 days, and I do not understand what is going on, and why they do not migrate to testing. Can you please help for this? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: kdepim 17.08.3 and kde-l10n
with the other batch of uploads I did few days ago, and then I will upload the aforementioned sources and few more PIM-related with pending changes. Of course, if anyone in release-team spots more issues to fix, I will gladly hear about them. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#885452: release.debian.org: please age pykde4 4:4.14.3-4 to migrate to testing
In data mercoledì 27 dicembre 2017 11:16:22 CET, Pino Toscano ha scritto: > Package: release.debian.org > Severity: wishlist > > Hi, > > as $subject, please age the pykde4 in unstable so it migrates to > testing: this (together with the other rebuilds [1][2]) will drop the > kdepim-runtime usage from non-kdepim5 stuff, and thus hopefully allow > kdepim-runtime 17.08.3 (with the rest of the kdepim 5 stack in unstable) > to migrate to testing. > > [1] https://lists.debian.org/debian-release/2017/12/msg00600.html > [2] https://lists.debian.org/debian-wb-team/2017/12/msg00037.html Gentle ping. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#885452: release.debian.org: please age pykde4 4:4.14.3-4 to migrate to testing
Package: release.debian.org Severity: wishlist Hi, as $subject, please age the pykde4 in unstable so it migrates to testing: this (together with the other rebuilds [1][2]) will drop the kdepim-runtime usage from non-kdepim5 stuff, and thus hopefully allow kdepim-runtime 17.08.3 (with the rest of the kdepim 5 stack in unstable) to migrate to testing. [1] https://lists.debian.org/debian-release/2017/12/msg00600.html [2] https://lists.debian.org/debian-wb-team/2017/12/msg00037.html Thanks, -- Pino
Bug#883622: transition: analitza 17.08
In data martedì 12 dicembre 2017 11:07:54 CET, Emilio Pozuelo Monfort ha scritto: > On 09/12/17 23:46, Pino Toscano wrote: > > In data venerdì 8 dicembre 2017 19:52:13 CET, Emilio Pozuelo Monfort ha > > scritto: > >> On 05/12/17 21:57, Pino Toscano wrote: > >>> Package: release.debian.org > >>> Severity: normal > >>> User: release.debian@packages.debian.org > >>> Usertags: transition > >>> > >>> Hi, > >>> > >>> I would like to request a slot for the analitza 17.08.x transition. > >>> There are only two affected sources: > >>> - kalgebra (which will get a sourceful upload) > >>> - cantor, which just needs a rebuild > >>> > >>> I will wait for this weekend for the batch of 17.08 uploads I did last > >>> weekend to migrate to testing: the reason is that the new versions of > >>> analitza and kalgebra carry their translations files, right now shipped > >>> as part of kde-l10n (and thus a coordinated upload is needed, I will > >>> take care of it). > >> > >> Ack. > > > > Uploaded few hours ago, and analitza and kalgebra already built > > everywhere. > > You need a RM bug against ftp.debian.org for the kalgebra binaries that are no > longer built on some architectures: > > kalgebra [armel kfreebsd-amd64 kfreebsd-i386 mips mips64el powerpc ppc64el > s390x] This was done, and analiza migrated to testing 10 days ago. Is there anything else left to do for this transition? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883624: transition: libkf5kipi + marble 17.08
In data sabato 9 dicembre 2017 23:48:10 CET, Pino Toscano ha scritto: > In data venerdì 8 dicembre 2017 19:53:03 CET, Emilio Pozuelo Monfort ha > scritto: > > On 05/12/17 22:03, Pino Toscano wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Hi, > > > > > > I would like to request a slot for the transitions of libkf5kipi 17.08 > > > and marble 17.08. I'm requesting a single slot for them as the impact > > > of each is limited, and they boh affect digikam (big source, so one > > > rebuild can be avoided). > > > > > > The sources affected by libkf5kipi are: > > > - digikam > > > - gwenview > > > - kde-spectacle > > > - kphotoalbum > > > The sources affected by marble are: > > > - digikam > > > - kreport > > > - libkf5kgeomap > > > > > > I will wait for this weekend for the batch of 17.08 uploads I did last > > > weekend to migrate to testing: the reason is that the new versions of > > > libkf5kipi and marble carry their translations files, right now shipped > > > as part of kde-l10n (and thus a coordinated upload is needed, I will > > > take care of it). > > > > You can go ahead. > > Uploaded libkf5kipi, marble and libkf5kgeomap few hours ago, and all of > them already built everywhere. libkf5kipi migrated to testing 12 days ago, and marble 2 days ago. Is there anything else left to do for this transition? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Rebuilds needed to drop kdepim-runtime dependency
In data venerdì 22 dicembre 2017 11:44:12 CET, Pino Toscano ha scritto: > Hi, > > src:kdepimlibs (which uses Qt4/kdelibs 4.x) used to inject > kdepim-runtime via symbols files as runtime dependency for most of the > libraries: this was done because they sort of needed the "runtime" > parts. However, when most of the KDEPIM stack (kdepim-runtime included) > was updated to Qt5/KF5, we forgot to drop this injection in kdepimlibs, > so the few kdelibs 4.x applications left still using kdepimlibs install > also components they are not able to use. This came to light yesterday, > when updating the KDEPIM stack to a newer version, as kdepim-runtime > will not be available on all the architectures due to the indirect use > of QtWebEngine (which is not portable). > > I just uploaded kdepimlibs 4:4.14.10-9 to unstable, removing the > kdepim-runtime injection. Can you please schedule few binNMUs in > unstable (with proper dep-wait), to remove the dependency in packages? > The list of affected sources is short: > > baloo kdepim4 kdewebdev kmymoney kraft pykde4 > (theoretically there is syncevolution too, but it FTBFSes already for > other reasons) > > Apologies for the late heads-up on this. Gentle ping on this. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Rebuilds needed to drop kdepim-runtime dependency
Hi, src:kdepimlibs (which uses Qt4/kdelibs 4.x) used to inject kdepim-runtime via symbols files as runtime dependency for most of the libraries: this was done because they sort of needed the "runtime" parts. However, when most of the KDEPIM stack (kdepim-runtime included) was updated to Qt5/KF5, we forgot to drop this injection in kdepimlibs, so the few kdelibs 4.x applications left still using kdepimlibs install also components they are not able to use. This came to light yesterday, when updating the KDEPIM stack to a newer version, as kdepim-runtime will not be available on all the architectures due to the indirect use of QtWebEngine (which is not portable). I just uploaded kdepimlibs 4:4.14.10-9 to unstable, removing the kdepim-runtime injection. Can you please schedule few binNMUs in unstable (with proper dep-wait), to remove the dependency in packages? The list of affected sources is short: baloo kdepim4 kdewebdev kmymoney kraft pykde4 (theoretically there is syncevolution too, but it FTBFSes already for other reasons) Apologies for the late heads-up on this. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883921: Please rebuild digikam to pick old libical
Hi, after I fixed kcalcore (#883960), now digikam should use libical2, just like kcalcore did and still does, hence avoid loading both libical2 and libical3. Can you please rebuild digikam in unstable and experimental? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883624: transition: libkf5kipi + marble 17.08
In data sabato 9 dicembre 2017 23:48:10 CET, Pino Toscano ha scritto: > Uploaded libkf5kipi, marble and libkf5kgeomap few hours ago, and all of > them already built everywhere. Can you please rebuild also digikam in experimental? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883624: transition: libkf5kipi + marble 17.08
In data venerdì 8 dicembre 2017 19:53:03 CET, Emilio Pozuelo Monfort ha scritto: > On 05/12/17 22:03, Pino Toscano wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi, > > > > I would like to request a slot for the transitions of libkf5kipi 17.08 > > and marble 17.08. I'm requesting a single slot for them as the impact > > of each is limited, and they boh affect digikam (big source, so one > > rebuild can be avoided). > > > > The sources affected by libkf5kipi are: > > - digikam > > - gwenview > > - kde-spectacle > > - kphotoalbum > > The sources affected by marble are: > > - digikam > > - kreport > > - libkf5kgeomap > > > > I will wait for this weekend for the batch of 17.08 uploads I did last > > weekend to migrate to testing: the reason is that the new versions of > > libkf5kipi and marble carry their translations files, right now shipped > > as part of kde-l10n (and thus a coordinated upload is needed, I will > > take care of it). > > You can go ahead. Uploaded libkf5kipi, marble and libkf5kgeomap few hours ago, and all of them already built everywhere. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883622: transition: analitza 17.08
In data venerdì 8 dicembre 2017 19:52:13 CET, Emilio Pozuelo Monfort ha scritto: > On 05/12/17 21:57, Pino Toscano wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi, > > > > I would like to request a slot for the analitza 17.08.x transition. > > There are only two affected sources: > > - kalgebra (which will get a sourceful upload) > > - cantor, which just needs a rebuild > > > > I will wait for this weekend for the batch of 17.08 uploads I did last > > weekend to migrate to testing: the reason is that the new versions of > > analitza and kalgebra carry their translations files, right now shipped > > as part of kde-l10n (and thus a coordinated upload is needed, I will > > take care of it). > > Ack. Uploaded few hours ago, and analitza and kalgebra already built everywhere. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883624: transition: libkf5kipi + marble 17.08
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to request a slot for the transitions of libkf5kipi 17.08 and marble 17.08. I'm requesting a single slot for them as the impact of each is limited, and they boh affect digikam (big source, so one rebuild can be avoided). The sources affected by libkf5kipi are: - digikam - gwenview - kde-spectacle - kphotoalbum The sources affected by marble are: - digikam - kreport - libkf5kgeomap I will wait for this weekend for the batch of 17.08 uploads I did last weekend to migrate to testing: the reason is that the new versions of libkf5kipi and marble carry their translations files, right now shipped as part of kde-l10n (and thus a coordinated upload is needed, I will take care of it). Thanks, -- Pino
Bug#883622: transition: analitza 17.08
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to request a slot for the analitza 17.08.x transition. There are only two affected sources: - kalgebra (which will get a sourceful upload) - cantor, which just needs a rebuild I will wait for this weekend for the batch of 17.08 uploads I did last weekend to migrate to testing: the reason is that the new versions of analitza and kalgebra carry their translations files, right now shipped as part of kde-l10n (and thus a coordinated upload is needed, I will take care of it). Thanks, -- Pino
Re: Please block kdevplatform/5.1.1-1
In data lunedì 10 luglio 2017 09:18:11 CEST, Julien Cristau ha scritto: > On 07/10/2017 08:29 AM, Pino Toscano wrote: > > Hi, > > > > can you please block kdevplatform/5.1.1-1 from entering testing > > tonight? > > kdevelop is affected by #866354 on armel, and I'd like the whole > > kdevelop stack (kdevplatform, kdevelop, kdevelop-python, and > > kdevelop-php) to migrate to testing at the same time. > > > Block hint added (not version specific, so you'll need to prod again to > get it lifted). It looks like the kdevelop stack is built on all the release archs now, can you please remove the block hint to let the packages migrate? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Please block kdevplatform/5.1.1-1
Hi, can you please block kdevplatform/5.1.1-1 from entering testing tonight? kdevelop is affected by #866354 on armel, and I'd like the whole kdevelop stack (kdevplatform, kdevelop, kdevelop-python, and kdevelop-php) to migrate to testing at the same time. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#854044: unblock: soprano/2.9.4+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package soprano: the upload removes a spurious build dependency on the old soprano1 (soprano2 was used even before); this helps in getting rid of the old soprano1 (#850840). unblock soprano/2.9.4+dfsg-5 Thanks, -- Pino diff -Nru soprano-2.9.4+dfsg/debian/changelog soprano-2.9.4+dfsg/debian/changelog --- soprano-2.9.4+dfsg/debian/changelog 2016-08-19 22:08:33.0 +0200 +++ soprano-2.9.4+dfsg/debian/changelog 2017-02-03 12:51:43.0 +0100 @@ -1,3 +1,14 @@ +soprano (2.9.4+dfsg-5) unstable; urgency=medium + + * Team upload. + + [ Simon McVittie ] + * Remove obsolete libraptor1-dev build-dependency (Closes: #854034). +Build-depend on libraptor2-dev instead, which is what +soprano-daemon actually uses. + + -- Pino Toscano <p...@debian.org> Fri, 03 Feb 2017 12:51:43 +0100 + soprano (2.9.4+dfsg-4) unstable; urgency=medium * Team upload. diff -Nru soprano-2.9.4+dfsg/debian/control soprano-2.9.4+dfsg/debian/control --- soprano-2.9.4+dfsg/debian/control 2016-08-19 22:04:16.0 +0200 +++ soprano-2.9.4+dfsg/debian/control 2017-02-03 12:31:45.0 +0100 @@ -8,7 +8,7 @@ Maximiliano Curia <m...@debian.org> Build-Depends: debhelper (>= 9), cmake (>= 2.6.2), pkg-kde-tools (>= 0.12), dpkg-dev (>= 1.15.5), libclucene-dev (>= 0.9.21b), libqt4-dev (>= 4.5.3), - libraptor1-dev (>= 1.4.16), librdf0-dev (>= 1.0.13), + libraptor2-dev (>= 1.4.16), librdf0-dev (>= 1.0.13), doxygen (>= 1.7.1), graphviz, libiodbc2-dev Standards-Version: 3.9.8 Homepage: http://soprano.sourceforge.net
Bug#839869: transition: poppler 0.48.0
In data venerdì 4 novembre 2016 23:56:44 CET, Emilio Pozuelo Monfort ha scritto: > On 31/10/16 08:28, Emilio Pozuelo Monfort wrote: > > On 31/10/16 07:57, Pino Toscano wrote: > >> In data giovedì 20 ottobre 2016 13:49:55 CET, Emilio Pozuelo Monfort ha > >> scritto: > >>> Control: tags -1 confirmed > >>> > >>> On 18/10/16 23:30, Pino Toscano wrote: > >>>> In data lunedì 17 ottobre 2016 21:11:00 CEST, Emilio Pozuelo Monfort ha > >>>> scritto: > >>>>> On 08/10/16 20:34, Pino Toscano wrote: > >>>>>> In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha > >>>>>> scritto: > >>>>>>> Hi, > >>>>>>> > >>>>>>> On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote: > >>>>>>>> This transition impacts the existing poppler libraries in the > >>>>>>>> following ways: > >>>>>>>> - libpoppler61 → libpoppler64 > >>>>>>> [...] > >>>>>>>> boomaga > >>>>>>>> calligra > >>>>>>>> cups-filters > >>>>>>>> emacs-pdf-tools > >>>>>>>> gambas3 > >>>>>>>> gdal > >>>>>>>> gdcm > >>>>>>>> inkscape > >>>>>>>> ipe-tools > >>>>>>>> pdf2djvu > >>>>>>>> pdf2htmlex > >>>>>>>> popplerkit.framework > >>>>>>>> texlive-bin > >>>>>>>> texworks > >>>>>>>> xpdf > >>>>>>> > >>>>>>> I believe there's stuff missing there for whatever reason. E.g. > >>>>>>> libreoffice > >>>>>>> (via libreoffice-pdfimport, > >>>>>>> https://packages.debian.org/sid/libreoffice-pdfimport). > >>>>>>> > >>>>>>> Was in your last transition bugs afaicr, so I wonder what went wrong > >>>>>>> this time ;) > >>>>>> > >>>>>> Oh right, sorry, it was indeed missing. In the above list there is > >>>>>> also: > >>>>>> > >>>>>> libreoffice > >>>>>> openscenegraph > >>>>>> openscenegraph-3.4 > >>>>> > >>>>> I see the new poppler is now in experimental. Do the rdeps build > >>>>> against the new > >>>>> version? > >>>> > >>>> I could test everything but LibreOffice: no failures. > >>>> > >>>> Rene, could you please give LO + poppler/experimental a try? Thanks! > >>> > >>> Rene told me LO is fine. Please go ahead. > >> > >> Sorry for the late reply -- I was busy and thus I couldn't dedicate the > >> proper time to follow the transition. > >> > >> Is the slot for this transtition still open, or should I wait for any > >> other in progress transitions? > > > > Let's wait for the gdal transition to finish. Thanks for checking first. > > gdal is done. Let's do this. Thanks! Uploaded few hours ago, and at this point built and uploaded on all the release architectures (and not only those). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#839869: transition: poppler 0.48.0
In data giovedì 20 ottobre 2016 13:49:55 CET, Emilio Pozuelo Monfort ha scritto: > Control: tags -1 confirmed > > On 18/10/16 23:30, Pino Toscano wrote: > > In data lunedì 17 ottobre 2016 21:11:00 CEST, Emilio Pozuelo Monfort ha > > scritto: > >> On 08/10/16 20:34, Pino Toscano wrote: > >>> In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha scritto: > >>>> Hi, > >>>> > >>>> On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote: > >>>>> This transition impacts the existing poppler libraries in the following > >>>>> ways: > >>>>> - libpoppler61 → libpoppler64 > >>>> [...] > >>>>> boomaga > >>>>> calligra > >>>>> cups-filters > >>>>> emacs-pdf-tools > >>>>> gambas3 > >>>>> gdal > >>>>> gdcm > >>>>> inkscape > >>>>> ipe-tools > >>>>> pdf2djvu > >>>>> pdf2htmlex > >>>>> popplerkit.framework > >>>>> texlive-bin > >>>>> texworks > >>>>> xpdf > >>>> > >>>> I believe there's stuff missing there for whatever reason. E.g. > >>>> libreoffice > >>>> (via libreoffice-pdfimport, > >>>> https://packages.debian.org/sid/libreoffice-pdfimport). > >>>> > >>>> Was in your last transition bugs afaicr, so I wonder what went wrong > >>>> this time ;) > >>> > >>> Oh right, sorry, it was indeed missing. In the above list there is also: > >>> > >>> libreoffice > >>> openscenegraph > >>> openscenegraph-3.4 > >> > >> I see the new poppler is now in experimental. Do the rdeps build against > >> the new > >> version? > > > > I could test everything but LibreOffice: no failures. > > > > Rene, could you please give LO + poppler/experimental a try? Thanks! > > Rene told me LO is fine. Please go ahead. Sorry for the late reply -- I was busy and thus I couldn't dedicate the proper time to follow the transition. Is the slot for this transtition still open, or should I wait for any other in progress transitions? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#839869: transition: poppler 0.48.0
In data lunedì 17 ottobre 2016 21:11:00 CEST, Emilio Pozuelo Monfort ha scritto: > On 08/10/16 20:34, Pino Toscano wrote: > > In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha scritto: > >> Hi, > >> > >> On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote: > >>> This transition impacts the existing poppler libraries in the following > >>> ways: > >>> - libpoppler61 → libpoppler64 > >> [...] > >>> boomaga > >>> calligra > >>> cups-filters > >>> emacs-pdf-tools > >>> gambas3 > >>> gdal > >>> gdcm > >>> inkscape > >>> ipe-tools > >>> pdf2djvu > >>> pdf2htmlex > >>> popplerkit.framework > >>> texlive-bin > >>> texworks > >>> xpdf > >> > >> I believe there's stuff missing there for whatever reason. E.g. libreoffice > >> (via libreoffice-pdfimport, > >> https://packages.debian.org/sid/libreoffice-pdfimport). > >> > >> Was in your last transition bugs afaicr, so I wonder what went wrong this > >> time ;) > > > > Oh right, sorry, it was indeed missing. In the above list there is also: > > > > libreoffice > > openscenegraph > > openscenegraph-3.4 > > I see the new poppler is now in experimental. Do the rdeps build against the > new > version? I could test everything but LibreOffice: no failures. Rene, could you please give LO + poppler/experimental a try? Thanks! -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#838234: transition: readline/readline6
Hi, In data martedì 11 ottobre 2016 00:14:35 CEST, Emilio Pozuelo Monfort ha scritto: > Control: tags -1 confirmed > > On 03/10/16 00:10, Emilio Pozuelo Monfort wrote: > > Control: forwarded -1 > > https://release.debian.org/transitions/html/readline7.html > > > > Hi, > > > > On 18/09/16 20:43, Matthias Klose wrote: > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: transition > >> > >> readline 7.0 is now released, changing the soversion. The idea is to > >> upload the > >> readline package from experimental (plus providing the libreadline*6-dev > >> packages), and stop building the -dev packages and common packages from > >> readline6. Afaics, the API didn't change; for rebuild tests I only see > >> build > >> failures for unrelated reasons. readline and readline6 can stay in > >> testing for > >> some time, but readline6 should be removed from testing before the stretch > >> release. > >> > >> I haven't done a test rebuild on unstable, but building on Ubuntu yakkety. > >> The > >> current state of the transition can be seen at > >> http://people.canonical.com/~ubuntu-archive/transitions/html/readline.html > > > > Sounds good. I'd prefer to see a test rebuild on sid, but I think we could > > go > > ahead with this as it's a separate source and shouldn't block anything. > > readline 6 got decrufted. Rebuilds scheduled. Please adjust the tracker to consider also Pre-Depends on libreadline6: gawk has Pre-Depends instead of Depends, and there's libreadline6 there. As consequence, please also schedule the binNMU of gawk for this transition. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#839869: transition: poppler 0.48.0
In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha scritto: > Hi, > > On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote: > > This transition impacts the existing poppler libraries in the following > > ways: > > - libpoppler61 → libpoppler64 > [...] > > boomaga > > calligra > > cups-filters > > emacs-pdf-tools > > gambas3 > > gdal > > gdcm > > inkscape > > ipe-tools > > pdf2djvu > > pdf2htmlex > > popplerkit.framework > > texlive-bin > > texworks > > xpdf > > I believe there's stuff missing there for whatever reason. E.g. libreoffice > (via libreoffice-pdfimport, > https://packages.debian.org/sid/libreoffice-pdfimport). > > Was in your last transition bugs afaicr, so I wonder what went wrong this > time ;) Oh right, sorry, it was indeed missing. In the above list there is also: libreoffice openscenegraph openscenegraph-3.4 Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#839869: transition: poppler 0.48.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to ask a slot for a Poppler 0.48.0 transition. Poppler 0.48.0 is hopefully going to be released this month, so it will be uploaded to experimental first, as usual. This transition impacts the existing poppler libraries in the following ways: - libpoppler61 → libpoppler64 - libpoppler-glib8 -- BC with 0.44 (one new symbol) - libpoppler-qt4-4 -- BC with 0.44 (few new symbols) - libpoppler-qt5-1 -- BC with 0.44 (few new symbols) Below it is a list of sources which are touched by the transition: boomaga calligra cups-filters emacs-pdf-tools gambas3 gdal gdcm inkscape ipe-tools pdf2djvu pdf2htmlex popplerkit.framework texlive-bin texworks xpdf I haven't tested them yet with versions > 0.44, although it seems there should not be distruptive enough changes to the API of the private libpoppler. I will deal with the failures anyway (as I have done in the past). Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. Ben file: title = "poppler 0.48.0"; is_affected = .depends ~ "libpoppler61" | .depends ~ "libpoppler64"; is_good = .depends ~ "libpoppler64"; is_bad = .depends ~ "libpoppler61"; Thanks, -- Pino
Bug#823669: transition: ctemplate 2.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a transition for ctemplate 2.3. ctemplate 2.3, already in experimental and building fine everywhere, bumped SONAME from libctemplate2 to libctemplate3. The transition involves the following sources: kraft mysql-workbench all of them build fine with the new ctemplate. Ben file: title = "ctemplate"; is_affected = .depends ~ "libctemplate2v5" | .depends ~ "libctemplate3"; is_good = .depends ~ "libctemplate3"; is_bad = .depends ~ "libctemplate2v5"; Thanks, -- Pino
Bug#823667: transition: poppler 0.42
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.42.0 transition. Currently there is Poppler 0.42.0 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler57 → libpoppler60 Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: boomaga cups-filters gambas3 gdal gdcm inkscape ipe-tools libreoffice pdf2djvu pdf2htmlex popplerkit.framework texlive-bin texworks xpdf Sources that currently FTBFS: * calligra FTBFS for other reasons, not in testing already (can be ignored) Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. A change in poppler-glib 0.39 is the removal of an unused enum; this so far impacted only two sources: - ruby-gnome2 (#812677, fixed) - python-poppler (#812680) OTOH, this issue does not directly affect the libpoppler transition. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.39 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.40 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.42 Ben file: title = "poppler 0.42"; is_affected = .depends ~ "libpoppler57" | .depends ~ "libpoppler60"; is_good = .depends ~ "libpoppler60"; is_bad = .depends ~ "libpoppler57"; Thanks, -- Pino
Bug#822616: jessie-pu: package poppler/0.26.5-2+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
simple jessie-pu for poppler, just fixed in unstable, which fixes
CVE-2015-8868; attached debdiff.
I guess I need to do binary uploads in (old-)stable, right?
Thanks,
--
Pino
diff -Nru poppler-0.26.5/debian/changelog poppler-0.26.5/debian/changelog
--- poppler-0.26.5/debian/changelog 2014-10-19 18:24:18.0 +0200
+++ poppler-0.26.5/debian/changelog 2016-04-25 19:02:20.0 +0200
@@ -1,3 +1,11 @@
+poppler (0.26.5-2+deb8u1) stable; urgency=medium
+
+ * Backport upstream commit b3425dd3261679958cd56c0f71995c15d2124433 to fix
+a crash on invalid files, reported also as CVE-2015-8868; patch
+upstream_Do-not-crash-on-invalid-files.patch. (Closes: #822578)
+
+ -- Pino Toscano <p...@debian.org> Mon, 25 Apr 2016 19:02:11 +0200
+
poppler (0.26.5-2) unstable; urgency=medium
* Backport upstream commit 01723aa17e836e818158dbdc56df642a290be300 to map
diff -Nru poppler-0.26.5/debian/patches/series poppler-0.26.5/debian/patches/series
--- poppler-0.26.5/debian/patches/series 2014-10-19 17:45:40.0 +0200
+++ poppler-0.26.5/debian/patches/series 2016-04-25 18:39:35.0 +0200
@@ -1,2 +1,3 @@
upstream_Map-Standard-Expert-encoding-ligatures-to-AGLFN-name.patch
qt-visibility.diff
+upstream_Do-not-crash-on-invalid-files.patch
diff -Nru poppler-0.26.5/debian/patches/upstream_Do-not-crash-on-invalid-files.patch poppler-0.26.5/debian/patches/upstream_Do-not-crash-on-invalid-files.patch
--- poppler-0.26.5/debian/patches/upstream_Do-not-crash-on-invalid-files.patch 1970-01-01 01:00:00.0 +0100
+++ poppler-0.26.5/debian/patches/upstream_Do-not-crash-on-invalid-files.patch 2016-04-25 18:39:35.0 +0200
@@ -0,0 +1,28 @@
+From b3425dd3261679958cd56c0f71995c15d2124433 Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid <aa...@kde.org>
+Date: Tue, 22 Dec 2015 22:50:33 +0100
+Subject: [PATCH] Do not crash on invalid files
+
+Bug #93476
+---
+ poppler/Function.cc | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/poppler/Function.cc b/poppler/Function.cc
+index 67283df..ee5afc1 100644
+--- a/poppler/Function.cc
b/poppler/Function.cc
+@@ -577,6 +577,10 @@ ExponentialFunction::ExponentialFunction(Object *funcObj, Dict *dict) {
+ goto err2;
+ }
+ n = obj1.arrayGetLength();
++if (unlikely(n > funcMaxOutputs)) {
++ error(errSyntaxError, -1, "Function's C0 array is wrong length");
++ n = funcMaxOutputs;
++}
+ for (i = 0; i < n; ++i) {
+ obj1.arrayGet(i, );
+ if (!obj2.isNum()) {
+--
+2.8.0.rc3
+
Bug#822531: nmu: swftools_0.9.2+git20130725-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu swftools correctly build-depends on libjpeg-dev, but the amd64 version (coming from the binary upload by the maintainer) depends on libjpeg8. Rebuilding in a clean up-to-date environment should fix this. @Christian Welzel: you are CC'ed because you are the maintainer of swftools, although there is no action required on your side. In future uploads, either do source-only uploads (preferred), or at least upload binaries built in a clean and up-to-date unstable chroot (e.g. with pbuilder/sbuild/etc). nmu swftools_0.9.2+git20130725-4 . amd64 . unstable . -m "Rebuild in clean environment" Thanks, -- Pino
Bug#821190: transition: lensfun 0.3.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a lenfun 0.3.2 transition. Currently it in experimental already. This transition changes the SONAME of the lensfun library from liblensfun0 to liblensfun1. The transition involves the following sources: darktable digikam gimplensfun ufraw - darktable, digikam, and ufraw build fine with the new version - gimplensfun 0.2.3 doesn't build with lensfun 0.3.x, and the new version 0.2.4 supports only lensfun >= 0.3; thus Evgeni will need to upload the new version once the transition starts Ben file: title = "lensfun"; is_affected = .depends ~ "liblensfun0" | .depends ~ "liblensfun1"; is_good = .depends ~ "liblensfun1"; is_bad = .depends ~ "liblensfun0"; Thanks, -- Pino
Bug#807089: transition: poppler 0.38
Control: tags -1 pending In data mercoledì 9 dicembre 2015 20:09:34, Emilio Pozuelo Monfort ha scritto: > On 05/12/15 09:53, Pino Toscano wrote: > > I would like to ask a slot for a Poppler 0.38.x transition. > > Currently there is Poppler 0.38.x in experimental already. > > You can go ahead. Thanks -- done yesterday evening already. Feel free to start with binNMUs, excluding cups-filters which got an upload and is built with new poppler already. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#807089: transition: poppler 0.38
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 807087 Hi, I would like to ask a slot for a Poppler 0.38.x transition. Currently there is Poppler 0.38.x in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler46 → libpoppler57 - libpoppler-glib8 -- BC with 0.26 (one new symbol) - libpoppler-qt4-4 -- BC with 0.26 (few new symbols) - libpoppler-qt5-1 -- BC with 0.26 (few new symbols) Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: boomaga cups-filters gdal inkscape ipe-tools libreoffice pdf2djvu pdf2htmlex popplerkit.framework texlive-bin texworks Sources that currently FTBFS: * xpdf The version currently in unstable does not support Poppler 0.38.0 (#807087). * calligra gambas3 gdcm These should be support Poppler 0.38.0 already, but they FTBFS for other reasons, and currently all of them are out of testing. Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.38 A ben tracker for poppler would have: title = "poppler 0.38"; is_affected = .build-depends ~ "libpoppler-private-dev" | .source ~ /texworks/; is_good = .depends ~ "libpoppler57"; is_bad = .depends ~ "libpoppler46"; Thanks, -- Pino
Bug#765950: nmu: sflphone_1.4.1-0.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please rebuild sflphone/amd64, as the latest upload has been built on a non-clean environment (with deb-multimedia packages, in particular). nmu sflphone_1.4.1-0.1 . amd64 . -m Rebuild in a clean environment. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141019135826.9160.25146.reportbug@drak
Bug#765040: unblock: libkexiv2/4:4.14.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, Please unblock package libkexiv2. This version (well, with the backported patches too) should fix issues with metadata handling (#763991, and possibly few more in src:digikam). A new upstream release will come tomorrow with the backported (and other) fixes provided, so in the meanwhile having libkexiv2 4:4.14.1-1 should reduce the crashes people are getting with digikam. unblock libkexiv2/4:4.14.1-1 Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013062359.30467.58876.reportbug@drak
Bug#761279: nmu: calligra_1:2.8.5+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu calligra_1:2.8.5+dfsg-1 . amd64 . -m Rebuild against libexiv2-13. Please rebuild calligra on amd64 only, since it was uploaded to NEW before the exiv2 transition took place. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912112318.3719.51266.reportbug@drak
Bug#732957: exiv2 transition: status
tag 732957 + pending thanks On 2014-09-05 17:50, Emilio Pozuelo Monfort wrote: Control: tags -1 confirmed Control: notforwarded -1 On 05/09/14 07:46, Pino Toscano wrote: tag 732957 - moreinfo thanks Hi, I'll take care of this transition, since it is kind of needed. I've checked the status of all the rdeps, and all of them were building fine with exiv2 0.24. So, at least from my point of view this could be ready to be started. Go ahead. Thank you. I did upload some hours ago, and now it has built and it is installed everywhere. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2037d1479602943074f25f6d222f5...@pino.toscano.name
Bug#732957: exiv2 transition: status
tag 732957 - moreinfo thanks Hi, I'll take care of this transition, since it is kind of needed. I've checked the status of all the rdeps, and all of them were building fine with exiv2 0.24. So, at least from my point of view this could be ready to be started. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8d27ed1bf1df5db760da5222912f2...@pino.toscano.name
Bug#751525: transition: poppler 0.26
On 2014-07-07 10:13, Emilio Pozuelo Monfort wrote: On 04/07/14 00:12, Pino Toscano wrote: On 2014-07-03 00:39, Emilio Pozuelo Monfort wrote: On 13/06/14 20:41, Pino Toscano wrote: Sources that currently FTBFS: * gdcm Compatibility with Poppler 0.26.x fixed upstream, asked to backport the patches in #751432. That's RC now. ... and NMU uploaded to DELAYED/2. gdcm failed on kfreebsd. Can you take a look? That's the last thing preventing testing migration. I can try, although not for the next couple of days, sorry :-/ Wouldn't be possible to smooth-migrate poppler anyway? Oh, and it seems like poppler now is waiting for the qtbase transition... (maybe a gb of gammaray could make it build again) -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/67cba8e5ad7e33461c06baf810c30...@pino.toscano.name
Bug#751525: transition: poppler 0.26
On 2014-07-03 00:39, Emilio Pozuelo Monfort wrote: On 13/06/14 20:41, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 751432 Hi, I would like to ask a slot for a Poppler 0.26.x transition. Currently there is Poppler 0.26.1 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler44 → libpoppler46 - libpoppler-glib8 -- BC with 0.24 (with few new symbols) - libpoppler-qt4-4 -- BC with 0.24 (with one new symbol) - libpoppler-qt5-1 -- BC with 0.24 (with one new symbol) Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: calligra cups-filters gambas3 gdal inkscape libreoffice pdf2djvu pdftoipe popplerkit.framework texlive-bin texworks (has a spurious dependency on libpoppler, handling it upstream and then to Debian) xpdf Scheduled. Thanks! I would have pinged when having successful poppler builds everywhere, but you where faster in scheduling binNMUs :) Sources that currently FTBFS: * gdcm Compatibility with Poppler 0.26.x fixed upstream, asked to backport the patches in #751432. That's RC now. ... and NMU uploaded to DELAYED/2. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/952337f29823710b223bc813b5df7...@pino.toscano.name
Bug#751525: transition: poppler 0.26
Hi, On 2014-06-24 10:52, Emilio Pozuelo Monfort wrote: On 14/06/14 12:11, Emilio Pozuelo Monfort wrote: On 13/06/14 20:41, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 751432 Hi, I would like to ask a slot for a Poppler 0.26.x transition. Currently there is Poppler 0.26.1 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler44 → libpoppler46 - libpoppler-glib8 -- BC with 0.24 (with few new symbols) - libpoppler-qt4-4 -- BC with 0.24 (with one new symbol) - libpoppler-qt5-1 -- BC with 0.24 (with one new symbol) Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Looks so good that I was going to ack it immediately, but unfortunately libreoffice clashes with the ongoing iceweasel transition, so let's wait until that finishes. libreoffice is about to transition, so please go ahead. I'll just wait until libreoffice migrates before scheduling its binNMU. Thanks for the ACK. Unfortunately I'm not that available for uploading, NMU gdcm and following the transition in the next 7 days. Please let me know whether there are blockers before July 3rd. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fb420cca6236a3a3271fc66e6be37...@pino.toscano.name
Bug#751525: transition: poppler 0.26
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 751432 Hi, I would like to ask a slot for a Poppler 0.26.x transition. Currently there is Poppler 0.26.1 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler44 → libpoppler46 - libpoppler-glib8 -- BC with 0.24 (with few new symbols) - libpoppler-qt4-4 -- BC with 0.24 (with one new symbol) - libpoppler-qt5-1 -- BC with 0.24 (with one new symbol) Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: calligra cups-filters gambas3 gdal inkscape libreoffice pdf2djvu pdftoipe popplerkit.framework texlive-bin texworks (has a spurious dependency on libpoppler, handling it upstream and then to Debian) xpdf Sources that currently FTBFS: * gdcm Compatibility with Poppler 0.26.x fixed upstream, asked to backport the patches in #751432. Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.26 A ben tracker for poppler would have: title = poppler 0.26; is_affected = .build-depends ~ libpoppler-private-dev | .source ~ /texworks/; is_good = .depends ~ libpoppler46; is_bad = .depends ~ libpoppler44; Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140613184151.13530.70779.reportbug@drak
Re: gnome-terminal: FTBFS on kfreebsd hurd archs
tag 749888 + patch thanks Hi, On 2014-05-31 15:43, Robert Millan wrote: Which makes me wonder: Does gnome-terminal actually work without gnome-shell? It seems (just looking at the sources, I'm not a GNOME guy) gnome-shell is needed to integrate gnome-terminal as search provider for gnome-shell; OTOH the feature seems optional, and passing --disable-search-provider indeed disables it. Attached a first version of patch for it; the changes to control.in and rules should be fine, while most probably the .install files could need few tricks (since gnome-terminal-search-provider.ini is not installed). GNOME team: if you could help on this, that would be great. Thanks, -- Pino Toscano--- a/debian/control.in +++ b/debian/control.in @@ -26,7 +26,7 @@ Build-Depends: cdbs (= 0.4.41), desktop-file-utils, appdata-tools, gsettings-desktop-schemas-dev (= 0.1.0), - gnome-shell, + gnome-shell [linux-any], libnautilus-extension-dev Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/gnome-terminal/ Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-terminal/ --- a/debian/rules +++ b/debian/rules @@ -9,10 +9,16 @@ include /usr/share/gnome-pkg-tools/1/rul include /usr/share/gnome-pkg-tools/1/rules/gnome-version.mk -include /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk +DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) + LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed DEB_CONFIGURE_EXTRA_FLAGS += --enable-distro-packaging +ifneq ($(DEB_HOST_ARCH_OS),linux) +DEB_CONFIGURE_EXTRA_FLAGS += --disable-search-provider +endif + build/gnome-terminal:: /usr/bin/docbook-to-man debian/gnome-terminal.sgml debian/gnome-terminal.1 --- a/debian/gnome-terminal.install +++ b/debian/gnome-terminal.install @@ -5,6 +5,5 @@ usr/share/applications usr/share/dbus-1/services usr/share/glib-2.0/schemas usr/lib/nautilus/extensions-3.0/libterminal-nautilus.so -usr/share/gnome-shell/search-providers/gnome-terminal-search-provider.ini debian/gnome-terminal.wrapper /usr/bin --- /dev/null +++ b/debian/gnome-terminal.install.linux @@ -0,0 +1,10 @@ +usr/bin +usr/lib/gnome-terminal +usr/share/appdata +usr/share/applications +usr/share/dbus-1/services +usr/share/glib-2.0/schemas +usr/lib/nautilus/extensions-3.0/libterminal-nautilus.so +usr/share/gnome-shell/search-providers/gnome-terminal-search-provider.ini + +debian/gnome-terminal.wrapper /usr/bin
Bug#740375: transition: poppler 0.24
On 2014-04-06 18:57, Julien Cristau wrote: On Sat, Apr 5, 2014 at 23:16:25 +0200, Pino Toscano wrote: Uploaded few hours ago, and now built everywhere. Scheduled binnmus (except for gdal, want to get -5 in testing first). Thanks for the binNMUs (no problem delaying gdal's binNMUs). A small update regarding the situation so far: - gambas3 seems to be FTBFSing (what a surprise...) due to something related to pgsql; can be kicked out of testing, in case - gdcm cannot be built on s390x due to the ongoing (and un-ACKed...) mpich transition (#742821), so maybe that transition should be brought forward (luckly it affects mostly s390x and mips/mipsel) - gnome-commander FTBFSes on armel/armhf; the new upstream release 1.4.1 fixes that FTBFS, and also switches the libpoppler usage to poppler-glib (which would make it out of this transition); I contacted Alessio about it, and he should upload it within few days -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/86de279d3cbdd95d92f13b4222f0b...@pino.toscano.name
Bug#740375: transition: poppler 0.24
Control: tag -1 pending On 2014-04-05 15:54, Julien Cristau wrote: On Fri, Feb 28, 2014 at 19:44:28 +0100, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.24.x transition. Feel free to upload to unstable. Thanks! Uploaded few hours ago, and now built everywhere. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/822760c0b8e744cde4c5e7131df67...@pino.toscano.name
Bug#740375: transition: poppler 0.24
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.24.x transition. I know a 0.22 transition has been done recently, but the future 0.26 will not be released at least for another month and it breaks few sources using the private libpoppler, so I would like to introduce 0.24 in Debian soon. Currently there is Poppler 0.24.x in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler37 → libpoppler44 Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: calligra cups-filters gambas3 gdal gdcm gnome-commander inkscape pdf2djvu pdftoipe popplerkit.framework texlive-bin Sources that currently FTBFS: * xpdf The version currently in unstable does not support Poppler 0.24, while the version in experimental does (#736443). * libreoffice LO 4.1 does not support Poppler 0.24 (needs an upstream commit [1]), while LO 4.2 (currently in experimental) does. Thus it is matter of either backporting that commit, or pushing LO 4.2 in unstable. Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.24 A ben tracker for poppler would have: is_affected = .build-depends ~ libpoppler-private-dev; is_good = .depends ~ libpoppler44; is_bad = .depends ~ libpoppler37; [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=828ebc542b980fce90e70459eb2d13e6eeecc355 Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140228184428.19303.16751.reportbug@drak
Bug#740375: transition: poppler 0.24
On 2014-02-28 20:00, Rene Engelhard wrote: Hi, On Fri, Feb 28, 2014 at 07:44:28PM +0100, Pino Toscano wrote: * libreoffice LO 4.1 does not support Poppler 0.24 (needs an upstream commit [1]), sure? That mentioned commit *is* in 4.1.5 afaics? I know earlier versions of 4.1 didn't support 0.24, and I didn't check lately if it has been backported. Could you please check whether LO/sid builds fine with poppler 0.24? Thanks! -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d7122285c93a71424fd74a53fd5e4...@pino.toscano.name
Bug#719227: transition: poppler 0.22
On 2014-01-20 10:25, Julien Cristau wrote: On Fri, Aug 9, 2013 at 15:45:19 +0200, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 679896 719224 712688 Hi, I would like to ask a slot for a Poppler 0.22.x transition. Currently there is Poppler 0.22.x in experimental already. Please note that there are still few issues that prevents it to be started, so I'm filing this at this time to have this transition considered by the release team. Is this only blocking on us now? If so please feel free to upload. Thanks, just done now. Regarding the binNMUs: - the priority of #690161 has just been raised to serious; OTOH it is not a blocker (as the source produces only an arch:all binary) - a fixed xpdf is in experimental, maybe Gilber will notice... the rest should be fine, so feel free to schedule binNMUs as you can and it is possible for the relevant sources. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/06946c2bdc2613189f5bcd53b064d...@pino.toscano.name
Re: Roll call for porters of architectures in sid and testing
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For hurd-i386, I - test parts of the base system, the packages I use/deal with, and occasionally the ones for which other people asked for Hurd fixes - help maintaining glibc, with the help of Samuel and Thomas - help maintaining arch-specific packages - triage and fix arch-specific bugs - help Samuel maintaning the exodar porter box I am a DD. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#707018: Status of KDE 4.10 transition
In data martedì 27 agosto 2013 20:07:02, Luk Claes ha scritto: On 08/27/2013 05:26 PM, Pino Toscano wrote: Alle martedì 27 agosto 2013, Luk Claes ha scritto: With the hints Luk added this morning basically almost everything migrated, except some sources split of kdemultimedia: libkcddb and kio-audiocd; kdemultimedia should be hinted out of testing (will be RMed afterwards) as all the new sources conver its binaries (excluding kdemultimedia-dbg). I think with the above all should be complete; I will be able to confirm when the above bits are done. Ok, I have added an easy hint to migrate libkcddb and kio-audiocd while removing kdemultimedia, hope that helps. Apparently it didn't help (and I specified the wrong source name, should be audiocd-kio and not kio-audiocd, sorry). Unfortunately it seems that kde-full still depends on kdemultimedia. So I have added the removal of meta-kde to the easy hint as it can come back easily when it gets fixed. With tonight's hints libkcddb and audiocd-kio have migrated successfully while src:kdemultimedia has been hinted out of testing. I think we are done now with this transition, we will take care or RM kdegames and kdemultimedia and other small cleanup tasks. Thanks for the work and patience in this, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#707018: Status of KDE 4.10 transition
Alle martedì 27 agosto 2013, Luk Claes ha scritto: With the hints Luk added this morning basically almost everything migrated, except some sources split of kdemultimedia: libkcddb and kio-audiocd; kdemultimedia should be hinted out of testing (will be RMed afterwards) as all the new sources conver its binaries (excluding kdemultimedia-dbg). I think with the above all should be complete; I will be able to confirm when the above bits are done. Ok, I have added an easy hint to migrate libkcddb and kio-audiocd while removing kdemultimedia, hope that helps. Apparently it didn't help (and I specified the wrong source name, should be audiocd-kio and not kio-audiocd, sorry). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#707018: Status of KDE 4.10 transition
Alle domenica 25 agosto 2013, Adam D. Barratt ha scritto: On 2013-08-25 15:03, Luk Claes wrote: On 08/25/2013 02:25 PM, Pino Toscano wrote: So, given that things are getting stuck because of us, I'm getting prodded in different channels, different new transitions are coming up, and I don't have time/experience to debug the aforementioned issues, I (reluctantly, from my personal POV) ask to unblock kde4libs and let things migrate. (You most probably need to either age or remove from testing tagua.) Ok, unblocked kde4libs and aged tagua. I've also dropped my block hint. Thank you both for the help. With the hints Luk added this morning basically almost everything migrated, except some sources split of kdemultimedia: libkcddb and kio-audiocd; kdemultimedia should be hinted out of testing (will be RMed afterwards) as all the new sources conver its binaries (excluding kdemultimedia-dbg). I think with the above all should be complete; I will be able to confirm when the above bits are done. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#707018: Status of KDE 4.10 transition
Hi, Alle lunedì 12 agosto 2013, Adam D. Barratt ha scritto: On Mon, 2013-08-12 at 20:08 +0200, Pino Toscano wrote: Alle domenica 11 agosto 2013, Adam D. Barratt ha scritto: On Sun, 2013-07-21 at 14:10 +0200, Pino Toscano wrote: That said, we are tackling few issues/regressions (mostly in the new pim stack), so could it be possible to hold the kde4libs migration with a block for now? (It should avoid all the rest to migrate too.) What's the current status here? Regarding the rest, I'm sure Sune could give an update of the status. In terms of RC bugs, the only issues I could see are a couple of FTBFS - tagua and kdenetwork. tagua is leaf, so could be removed until it's fixed. kdenetwork appears to be tied up with another transition but AIUI isn't part of the core transition so shouldn't block the majority of packages from migrating. IIRC kdenetwork is tied with kde-workspace. We're now hitting a month since the transition started in unstable. I'm wary that we don't let perfect be the enemy of perfectly reasonable here. It's early in the cycle and if any remaining issues aren't critical then could we get the current set of packages migrated and work on the final polishing afterwards? We had (and still have) regressions (from minor to potentially important as #717040) in kmail. I asked Sune to take a look at bugs, and he did nothing. So, given that things are getting stuck because of us, I'm getting prodded in different channels, different new transitions are coming up, and I don't have time/experience to debug the aforementioned issues, I (reluctantly, from my personal POV) ask to unblock kde4libs and let things migrate. (You most probably need to either age or remove from testing tagua.) -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#707018: Status of KDE 4.10 transition
Alle domenica 11 agosto 2013, Adam D. Barratt ha scritto: On Sun, 2013-07-21 at 14:10 +0200, Pino Toscano wrote: That said, we are tackling few issues/regressions (mostly in the new pim stack), so could it be possible to hold the kde4libs migration with a block for now? (It should avoid all the rest to migrate too.) What's the current status here? For sure there is kdepim/mips to build successfully first (first attempt got stuck, and the giveback failed because of not enough space). Regarding the rest, I'm sure Sune could give an update of the status. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#719227: transition: poppler 0.22
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 679896 719224 712688 Hi, I would like to ask a slot for a Poppler 0.22.x transition. Currently there is Poppler 0.22.x in experimental already. Please note that there are still few issues that prevents it to be started, so I'm filing this at this time to have this transition considered by the release team. This transition impacts the existing poppler libraries in the following ways: - libpoppler19 → libpoppler37 - libpoppler-glib8 -- BC with 0.18; provides symbols file (with few new symbols though) - libpoppler-qt4-3 → libpoppler-qt4-4 Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: calligra (poppler, poppler-qt4) comparepdf (poppler-qt4) cups-filters (poppler) diffpdf (poppler-qt4) gambas3 (poppler) gdcm (poppler) gnome-commander (poppler) inkscape (poppler) katarakt (poppler-qt4) kbibtex (poppler-qt4) ktikz (poppler-qt4) libreoffice (poppler) luatex (poppler) nepomuk-core (poppler-qt4) okular (poppler-qt4) pdf2djvu (poppler) pdftoipe (poppler) popplerkit.framework (poppler) prerex (poppler-qt4) python-poppler-qt4 (poppler-qt4) qcomicbook (poppler-qt4) qpdfview (poppler-qt4) tellico (poppler-qt4) texlive-bin (poppler) texmaker (poppler-qt4) texstudio (poppler-qt4) texworks (poppler-qt4) Sources that currently FTBFS: * gdal (poppler) gdal currently in unstable FTBFS with new Poppler (#679887), while the version in experimental builds fine. OTOH, gdal/experimental needs a transition (#712688). * xpdf (poppler) The patches needed to compile with poppler 0.22.x are not compatible with poppler 0.18, so they cannot be uploaded to unstable right now. They are #679896 (for 0.18 → 0.20) and #719224 (for 0.20 → 0.22). Other cases: * derivations (poppler) This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. It currently FTBFS with Poppler = 0.20 (#690161), but given what said above it can be left out of the transition (the bug severity will be raised to serious once the transition starts). I grouped all the bugs mentioned above (even the solved ones) with the following usertag: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.20 http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.22 A ben tracker for poppler would have: title = poppler 0.22; is_affected = .build-depends ~ libpoppler-private-dev | .build-depends ~ libpoppler-qt4-dev; is_good = .depends ~ libpoppler37 | .depends ~ libpoppler-qt4-4; is_bad = .depends ~ libpoppler19 | .depends ~ libpoppler-qt4-3; Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130809134519.6839.93451.reportbug@drak
Bug#707018: Status of KDE 4.10 transition
Hi, yet another update on the status of the KDE 4.10 transition: Alle venerdì 19 luglio 2013, Pino Toscano ha scritto: * thanks to the latest givebacks [1], now basically all the uploaded sources are built. There are still a couple of failures on mipsel, but they are in leaf sources which do not affect this transitions (I will ask for further gb). There is only rocs left in such state. * regarding the rest of the sources: apper -- binNMU bespin -- binNMU calligra -- binNMU digikam -- (A) kamoso -- (A) kde-style-qtcurve -- binNMU kdevelop -- binNMU knights -- binNMU kphotoalbum -- binNMU kshutdown -- binNMU ktorrent -- binNMU kwin-style-crystal -- (A) kwin-style-dekorator -- binNMU plasma-widget-fastuserwitch -- binNMU tagua -- binNMU (A) the version in sid/testing is not compatible with newer libs, we either are going to upload the version in experimental or a proper fix I missed the status of knights and tagua, that FTBFSed (#717414 and #717415); calligra did it too (#717413). knights and calligra had both MUs which fixed the build issues, and tagua has a patch for fixing it (it is a leaf package, so if unfixed could be hinted out of testing). That said, we are tackling few issues/regressions (mostly in the new pim stack), so could it be possible to hold the kde4libs migration with a block for now? (It should avoid all the rest to migrate too.) Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#707018: Status of KDE 4.10 transition
Hi, after few days, let's sum up the status of the KDE 4.10 transition: * thanks to the latest givebacks [1], now basically all the uploaded sources are built. There are still a couple of failures on mipsel, but they are in leaf sources which do not affect this transitions (I will ask for further gb). * the tracker somehow seems confused by the following parts: - good: libkdecorations4abi1, libanalitzagui4abi1 - bad: libkdecorations4, libanalitzagui4 somehow the bad library names being substring of the good ones makes few sources (cantor, kalgebra, kdeartwork) being mistaken as bad; would it be possible to fix this? * regarding the rest of the sources: apper -- binNMU bespin -- binNMU calligra -- binNMU digikam -- (A) kamoso -- (A) kde-style-qtcurve -- binNMU kdevelop -- binNMU knights -- binNMU kphotoalbum -- binNMU kshutdown -- binNMU ktorrent -- binNMU kwin-style-crystal -- (A) kwin-style-dekorator -- binNMU plasma-widget-fastuserwitch -- binNMU tagua -- binNMU (A) the version in sid/testing is not compatible with newer libs, we either are going to upload the version in experimental or a proper fix [1] http://lists.debian.org/debian-wb-team/2013/07/msg00028.html Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#712928: nmu: klog_0.6.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu klog_0.6.1-1 . amd64 . -m Rebuild in an up-to-date environment It seems the klog maintainer upload (with an amd64 build) was not done in an up-to-date environment, and it links to kdebase-runtime instead of kde-runtime (which it should do since March 2012). Jaime, please make sure to build your packages in a clean and up-to-date sid/unstable build environment. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130620201107.14570.21323.reportbug@drak
Bug#706971: transition: attica 0.4
Alle sabato 15 giugno 2013, Julien Cristau ha scritto: On Fri, Jun 14, 2013 at 10:11:45 +0200, Pino Toscano wrote: I uploaded it some hours ago, and now it is built and installed on all the archs. Scheduled binNMUs for kde4libs; will do the others afterwards. Thanks for all the binNMUs. There's the kde4libs/mipsel FTBFS due to libpcre; although the thread at 0lq67a-ol4@argenau.downhill.at.eu.org would seem to suggest a newer binutils would fix the issue, the latest binutils was used already in that build. Furthermore, would it be possible to handle the binNMUs for the sources in experimental too? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#706971: transition: attica 0.4
Alle giovedì 13 giugno 2013, Julien Cristau ha scritto: On Mon, May 6, 2013 at 17:20:13 +0200, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to request a slot for a small libattica 0.4.x transition. The newer attica source is already in experimental, and the transition affects just few (KDE-related) sources. Go ahead. Thanks. I uploaded it some hours ago, and now it is built and installed on all the archs. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#710699: nmu: xjig_2.4-14
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu xjig_2.4-14 . i386 . -m Rebuild in a clean environment It seems the xjig maintainer upload (with an i386 build) was not done in a clean (or up-to-date) environment, and it uses libjpeg62 instead of libjpeg8 (current libjpeg-dev provider). Dave, please make sure to build your packages in clean and up-to-date build environment. Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130601163744.8965.64607.reportbug@drak
Bug#706971: transition: attica 0.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to request a slot for a small libattica 0.4.x transition. The newer attica source is already in experimental, and the transition affects just few (KDE-related) sources. The SONAME change is the following: * libattica-dev (src:attica): libattica0 - libattica0.4 The sources affected by the transition are: choqok kde4libs kdeplasma-addons kde-runtime smokekde there are also calligra and parley which build-depend on libattica-dev and checking for it at cmake time but not actually using it; should be enough to ignore them. Ben file: title = attica 0.4; is_affected = .build-depends ~ /libattica-dev/; is_good = .depends ~ libattica0.4; is_bad = .depends ~ libattica0; Thanks, -- Pino -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130506152013.26459.27575.reportbug@drak
Removing a file with unclear license from kdesdk
Hi, while reviewing copyright for newer versions of kdesdk, we found out that one of the files, scripts/add_trace.pl, has an unclear license: | ## Written by David Faure fa...@kde.org, licensed under pizzaware. and there's no associated text on what it would imply. This script is not installed, so it is not part of any binary package we currently ship. Would you, release-team, allow an upload of kdesdk only dropping this file from the source (which is already +dfsg)? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#703930: unblock: poppler/0.18.4-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
I just uploaded poppler/0.18.4-6 fixing CVE-2013-1788 and CVE-2013-1790
(#702071). Could you please unblock it?
(Also, I noticed during the upload to have left urgency=low, maybe
is it worth urgency=medium.)
unblock poppler/0.18.4-6
Thanks,
--
Pino
diff -Nru poppler-0.18.4/debian/changelog poppler-0.18.4/debian/changelog
--- poppler-0.18.4/debian/changelog 2013-01-31 15:20:54.0 +0100
+++ poppler-0.18.4/debian/changelog 2013-03-25 21:43:14.0 +0100
@@ -1,3 +1,18 @@
+poppler (0.18.4-6) unstable; urgency=low
+
+ * Backport upstream commits 0388837f01bc467045164f9ddaff787000a8caaa (patch
+upstream_Fix-another-invalid-memory-access-in-1091.pdf.asan.7.patch),
+8b6dc55e530b2f5ede6b9dfb64aafdd1d5836492 (adapted patch
+upstream_Fix-invalid-memory-access-in-1150.pdf.asan.8.69.patch), and
+e14b6e9c13d35c9bd1e0c50906ace8e707816888 (adapted patch
+upstream_Fix-invalid-memory-access-in-2030.pdf.asan.69.463.patch) to fix
+CVE-2013-1788.
+ * Backport upstream commit b1026b5978c385328f2a15a2185c599a563edf91 to fix
+CVE-2013-1790 (patch upstream_Initialize-refLine-totally.patch).
+ * With the changes above, this upload closes: #702071.
+
+ -- Pino Toscano p...@debian.org Mon, 25 Mar 2013 21:43:07 +0100
+
poppler (0.18.4-5) unstable; urgency=low
* Correctly initialize PSOutputDev::fontFileNameLen and
diff -Nru poppler-0.18.4/debian/patches/series poppler-0.18.4/debian/patches/series
--- poppler-0.18.4/debian/patches/series 2013-01-31 13:58:17.0 +0100
+++ poppler-0.18.4/debian/patches/series 2013-03-23 07:48:04.0 +0100
@@ -4,3 +4,7 @@
upstream_Change-nn-to-number.patch
upstream_fix-GooString-insert.diff
psoutputdev-initialize-vars.diff
+upstream_Fix-another-invalid-memory-access-in-1091.pdf.asan.7.patch
+upstream_Fix-invalid-memory-access-in-2030.pdf.asan.69.463.patch
+upstream_Fix-invalid-memory-access-in-1150.pdf.asan.8.69.patch
+upstream_Initialize-refLine-totally.patch
diff -Nru poppler-0.18.4/debian/patches/upstream_Fix-another-invalid-memory-access-in-1091.pdf.asan.7.patch poppler-0.18.4/debian/patches/upstream_Fix-another-invalid-memory-access-in-1091.pdf.asan.7.patch
--- poppler-0.18.4/debian/patches/upstream_Fix-another-invalid-memory-access-in-1091.pdf.asan.7.patch 1970-01-01 01:00:00.0 +0100
+++ poppler-0.18.4/debian/patches/upstream_Fix-another-invalid-memory-access-in-1091.pdf.asan.7.patch 2013-03-23 07:48:04.0 +0100
@@ -0,0 +1,40 @@
+From 0388837f01bc467045164f9ddaff787000a8caaa Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid aa...@kde.org
+Date: Thu, 10 Jan 2013 20:29:06 +0100
+Subject: [PATCH] Fix another invalid memory access in 1091.pdf.asan.72.42
+
+---
+ poppler/Stream.cc | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/poppler/Stream.cc b/poppler/Stream.cc
+index d118ddd..4cb3326 100644
+--- a/poppler/Stream.cc
b/poppler/Stream.cc
+@@ -2132,7 +2132,8 @@ GBool CCITTFaxStream::isBinary(GBool last) {
+
+ // clip [-256,511] -- [0,255]
+ #define dctClipOffset 256
+-static Guchar dctClip[768];
++#define dctClipLength 768
++static Guchar dctClip[dctClipLength];
+ static int dctClipInit = 0;
+
+ // zig zag decode map
+@@ -3078,7 +3079,12 @@ void DCTStream::transformDataUnit(Gushort *quantTable,
+
+ // convert to 8-bit integers
+ for (i = 0; i 64; ++i) {
+-dataOut[i] = dctClip[dctClipOffset + 128 + ((dataIn[i] + 8) 4)];
++const int ix = dctClipOffset + 128 + ((dataIn[i] + 8) 4);
++if (unlikely(ix 0 || ix = dctClipLength)) {
++ dataOut[i] = 0;
++} else {
++ dataOut[i] = dctClip[ix];
++}
+ }
+ }
+
+--
+1.7.10.4
+
diff -Nru poppler-0.18.4/debian/patches/upstream_Fix-invalid-memory-access-in-1150.pdf.asan.8.69.patch poppler-0.18.4/debian/patches/upstream_Fix-invalid-memory-access-in-1150.pdf.asan.8.69.patch
--- poppler-0.18.4/debian/patches/upstream_Fix-invalid-memory-access-in-1150.pdf.asan.8.69.patch 1970-01-01 01:00:00.0 +0100
+++ poppler-0.18.4/debian/patches/upstream_Fix-invalid-memory-access-in-1150.pdf.asan.8.69.patch 2013-03-23 07:48:04.0 +0100
@@ -0,0 +1,27 @@
+From 8b6dc55e530b2f5ede6b9dfb64aafdd1d5836492 Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid aa...@kde.org
+Date: Thu, 10 Jan 2013 22:31:52 +0100
+Subject: [PATCH] Fix invalid memory access in 1150.pdf.asan.8.69
+
+---
+ splash/Splash.cc |5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/splash/Splash.cc
b/splash/Splash.cc
+@@ -1521,11 +1521,14 @@ SplashPath *Splash::makeDashedPath(Splas
+ lineDashStartPhase -= (SplashCoord)i * lineDashTotal;
+ lineDashStartOn = gTrue;
+ lineDashStartIdx = 0;
+- while (lineDashStartPhase = state-lineDash[lineDashStartIdx]) {
++ while (lineDashStartIdx state-lineDashLength lineDashStartPhase = state-lineDash[lineDashStartIdx]) {
+ lineDashStartOn = !lineDashStartOn
Bug#700568: pu: package poppler/0.12.4-1.2+squeeze1
Hi, Alle venerdì 15 febbraio 2013, Adam D. Barratt ha scritto: On Thu, 2013-02-14 at 13:18 +0100, Pino Toscano wrote: +poppler (0.12.4-1.2+squeeze1) stable; urgency=low + + * Add myself as uploader. + * Fix CVE-2010-0206. + * Fix CVE-2010-0207; patch adapted to be API-/ABI-compatible. + * Fix CVE-2010-4653; patch adapted to include object.h instead +of goo/GooLikely.h (non-existent in poppler 0.12.x). + * Backport upstream commits 7ba15d11e56175601104d125d5e4a47619c224bf and + 55940e989701eb9118015e30f4f48eb654fa34c4 to fix GooString::insert; +patch upstream_fix-GooString-insert.diff. (Closes: #693817) + * Correctly initialize PSOutputDev::fontFileNameLen and + PSOutputDev::psFileNames; patch psoutputdev-initialize-vars.diff. +(Closes: #699421) Please go ahead; thanks. Thanks, uploaded. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#700568: pu: package poppler/0.12.4-1.2+squeeze1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I would like to upload a squeeze update for poppler, fixing three CVEs
(which were deemed minor, hence with no dsa), and a crasher bug and a
memory handling issue recently fixed in unstable (and wheezy).
The changes are:
* fix CVE-2010-0206:
- patch straight from upstream
* fix CVE-2010-0207:
- patch from upstream adapted to be API-/ABI-compatible, even though
the functions were private
* fix CVE-2010-4653
- patch from upstream adapted to include Object.h instead of
goo/GooLikely.h (non-existent in poppler 0.12.x)
- fix GooString::insert (#693817)
- backport the fix
- fix two uninitialized vars in PSOutputDev (#699421)
- backport the fix
I also added myself as uploader, as I did many months ago.
Let me know whether the proposed change seem okay, and I can upload to
stable.
Thanks,
--
Pino
diff -u poppler-0.12.4/debian/changelog poppler-0.12.4/debian/changelog
--- poppler-0.12.4/debian/changelog
+++ poppler-0.12.4/debian/changelog
@@ -1,3 +1,19 @@
+poppler (0.12.4-1.2+squeeze1) stable; urgency=low
+
+ * Add myself as uploader.
+ * Fix CVE-2010-0206.
+ * Fix CVE-2010-0207; patch adapted to be API-/ABI-compatible.
+ * Fix CVE-2010-4653; patch adapted to include object.h instead
+of goo/GooLikely.h (non-existent in poppler 0.12.x).
+ * Backport upstream commits 7ba15d11e56175601104d125d5e4a47619c224bf and
+55940e989701eb9118015e30f4f48eb654fa34c4 to fix GooString::insert;
+patch upstream_fix-GooString-insert.diff. (Closes: #693817)
+ * Correctly initialize PSOutputDev::fontFileNameLen and
+PSOutputDev::psFileNames; patch psoutputdev-initialize-vars.diff.
+(Closes: #699421)
+
+ -- Pino Toscano p...@debian.org Thu, 14 Feb 2013 13:05:25 +0100
+
poppler (0.12.4-1.2) unstable; urgency=medium
* Non-maintainer upload by the Security Team
diff -u poppler-0.12.4/debian/control poppler-0.12.4/debian/control
--- poppler-0.12.4/debian/control
+++ poppler-0.12.4/debian/control
@@ -4,7 +4,8 @@
Maintainer: Loic Minier l...@dooz.org
Uploaders: Josselin Mouette j...@debian.org,
Dave Beckett daj...@debian.org,
- Ross Burton r...@debian.org
+ Ross Burton r...@debian.org,
+ Pino Toscano p...@debian.org
Build-Depends: cdbs (= 0.4.52),
debhelper (= 5),
quilt,
diff -u poppler-0.12.4/debian/patches/series poppler-0.12.4/debian/patches/series
--- poppler-0.12.4/debian/patches/series
+++ poppler-0.12.4/debian/patches/series
@@ -4 +4,6 @@
-04_security.patch
\ No newline at end of file
+04_security.patch
+05_CVE-2010-0206.patch
+06_CVE-2010-0207.patch
+07_CVE-2010-4653.patch
+upstream_fix-GooString-insert.diff
+psoutputdev-initialize-vars.diff
only in patch2:
unchanged:
--- poppler-0.12.4.orig/debian/patches/psoutputdev-initialize-vars.diff
+++ poppler-0.12.4/debian/patches/psoutputdev-initialize-vars.diff
@@ -0,0 +1,41 @@
+Author: Pino Toscano p...@debian.org
+Description: initialize PSOutputDev::fontFileNameLen and PSOutputDev::psFileNames
+ Avoid crashing in ~PSOutputDev when the PSOutputDev instance is not ok.
+Applied-Upstream: not-needed
+Last-Update: 2013-01-31
+Bug-Debian: http://bugs.debian.org/699421
+
+--- a/poppler/PSOutputDev.cc
b/poppler/PSOutputDev.cc
+@@ -1012,6 +1012,7 @@ PSOutputDev::PSOutputDev(const char *fil
+ fontIDs = NULL;
+ fontFileIDs = NULL;
+ fontFileNames = NULL;
++ fontFileNameLen = 0;
+ font8Info = NULL;
+ font16Enc = NULL;
+ imgIDs = NULL;
+@@ -1022,6 +1023,7 @@ PSOutputDev::PSOutputDev(const char *fil
+ haveTextClip = gFalse;
+ haveCSPattern = gFalse;
+ t3String = NULL;
++ psFileNames = NULL;
+
+ forceRasterize = forceRasterizeA;
+
+@@ -1077,6 +1079,7 @@ PSOutputDev::PSOutputDev(PSOutputFunc ou
+ fontIDs = NULL;
+ fontFileIDs = NULL;
+ fontFileNames = NULL;
++ fontFileNameLen = 0;
+ font8Info = NULL;
+ font16Enc = NULL;
+ imgIDs = NULL;
+@@ -1087,6 +1090,7 @@ PSOutputDev::PSOutputDev(PSOutputFunc ou
+ haveTextClip = gFalse;
+ haveCSPattern = gFalse;
+ t3String = NULL;
++ psFileNames = NULL;
+
+ forceRasterize = forceRasterizeA;
+
only in patch2:
unchanged:
--- poppler-0.12.4.orig/debian/patches/05_CVE-2010-0206.patch
+++ poppler-0.12.4/debian/patches/05_CVE-2010-0206.patch
@@ -0,0 +1,56 @@
+From 30ea3ab8a1eecafb3366aef193910098fdb7ccc8 Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid aa...@kde.org
+Date: Tue, 25 May 2010 23:07:56 +0100
+Subject: [PATCH] Fix crash when parsing pdf in bug 28170
+
+This code is a can of crashing worms :-7
+---
+ poppler/JBIG2Stream.cc | 23 ---
+ 1 file changed, 16 insertions(+), 7 deletions(-)
+
+diff --git a/poppler/JBIG2Stream.cc b/poppler/JBIG2Stream.cc
+index 97994bd..f16ad58 100644
+--- a/poppler/JBIG2Stream.cc
b/poppler/JBIG2Stream.cc
+@@ -742,13 +742,18 @@ JBIG2Bitmap *JBIG2Bitmap::getSlice(Guint x, Guint y, Guint wA, Guint hA) {
+ Guint xx, yy
Bug#699443: unblock: poppler/0.18.4-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I would like to upload poppler 0.18.4-5, which would initialize two class members of PSOutputDev to avoid crashing in the destructor if the initialization of the output device is not ok (e.g. when the requested output file name cannot be opened, like in #699421). This bug, other than hitting that pdftops case, can hit library users of PSOutputDev, and its poppler-glib wrapping (such as epdfview). Attached the proposed debdiff. Thanks, -- Pino diff -Nru poppler-0.18.4/debian/changelog poppler-0.18.4/debian/changelog --- poppler-0.18.4/debian/changelog 2012-11-27 16:24:20.0 +0100 +++ poppler-0.18.4/debian/changelog 2013-01-31 14:03:45.0 +0100 @@ -1,3 +1,12 @@ +poppler (0.18.4-5) UNRELEASED; urgency=low + + [ Pino Toscano ] + * Correctly initialize PSOutputDev::fontFileNameLen and +PSOutputDev::psFileNames; patch psoutputdev-initialize-vars.diff. +(Closes: #699421) + + -- Pino Toscano p...@debian.org Thu, 31 Jan 2013 13:19:35 +0100 + poppler (0.18.4-4) unstable; urgency=low * Backport upstream commits 7ba15d11e56175601104d125d5e4a47619c224bf and diff -Nru poppler-0.18.4/debian/patches/psoutputdev-initialize-vars.diff poppler-0.18.4/debian/patches/psoutputdev-initialize-vars.diff --- poppler-0.18.4/debian/patches/psoutputdev-initialize-vars.diff 1970-01-01 01:00:00.0 +0100 +++ poppler-0.18.4/debian/patches/psoutputdev-initialize-vars.diff 2013-01-31 13:58:06.0 +0100 @@ -0,0 +1,41 @@ +Author: Pino Toscano p...@debian.org +Description: initialize PSOutputDev::fontFileNameLen and PSOutputDev::psFileNames + Avoid crashing in ~PSOutputDev when the PSOutputDev instance is not ok. +Applied-Upstream: not-needed +Last-Update: 2013-01-31 +Bug-Debian: http://bugs.debian.org/699421 + +--- a/poppler/PSOutputDev.cc b/poppler/PSOutputDev.cc +@@ -1012,6 +1012,7 @@ PSOutputDev::PSOutputDev(const char *fil + fontIDs = NULL; + fontFileIDs = NULL; + fontFileNames = NULL; ++ fontFileNameLen = 0; + font8Info = NULL; + font16Enc = NULL; + imgIDs = NULL; +@@ -1022,6 +1023,7 @@ PSOutputDev::PSOutputDev(const char *fil + haveTextClip = gFalse; + haveCSPattern = gFalse; + t3String = NULL; ++ psFileNames = NULL; + + forceRasterize = forceRasterizeA; + +@@ -1077,6 +1079,7 @@ PSOutputDev::PSOutputDev(PSOutputFunc ou + fontIDs = NULL; + fontFileIDs = NULL; + fontFileNames = NULL; ++ fontFileNameLen = 0; + font8Info = NULL; + font16Enc = NULL; + imgIDs = NULL; +@@ -1087,6 +1090,7 @@ PSOutputDev::PSOutputDev(PSOutputFunc ou + haveTextClip = gFalse; + haveCSPattern = gFalse; + t3String = NULL; ++ psFileNames = NULL; + + forceRasterize = forceRasterizeA; + diff -Nru poppler-0.18.4/debian/patches/series poppler-0.18.4/debian/patches/series --- poppler-0.18.4/debian/patches/series 2012-11-27 16:20:00.0 +0100 +++ poppler-0.18.4/debian/patches/series 2013-01-31 13:58:17.0 +0100 @@ -3,3 +3,4 @@ upstream_pdfinfo-decode-utf-16-surrogate-pairs.patch upstream_Change-nn-to-number.patch upstream_fix-GooString-insert.diff +psoutputdev-initialize-vars.diff
Bug#697011: unblock: filelight/4:4.8.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package filelight. The upload just improves/fixes the information in copyright. unblock filelight/4:4.8.4-2 Thanks, -- Pino diff -Nru filelight-4.8.4/debian/changelog filelight-4.8.4/debian/changelog --- filelight-4.8.4/debian/changelog 2012-06-20 00:18:44.0 +0200 +++ filelight-4.8.4/debian/changelog 2012-12-30 20:16:27.0 +0100 @@ -1,3 +1,10 @@ +filelight (4:4.8.4-2) unstable; urgency=low + + * Team upload. + * copyright: fix/improve information. + + -- Pino Toscano p...@debian.org Sun, 30 Dec 2012 20:16:15 +0100 + filelight (4:4.8.4-1) unstable; urgency=low * Team upload. diff -Nru filelight-4.8.4/debian/copyright filelight-4.8.4/debian/copyright --- filelight-4.8.4/debian/copyright 2012-06-20 00:10:11.0 +0200 +++ filelight-4.8.4/debian/copyright 2012-12-30 19:33:28.0 +0100 @@ -10,12 +10,16 @@ Files: doc/* Copyright: 2003-2004, Max Howell max.how...@methylblue.com 2008-2009 Martin Sandsmark sandsm...@samfundet.no -License: GFDL-NIV-1.2 +License: GFDL-NIV-1.2+ Files: debian/* Copyright: 2012, Eshat Cakar i...@eshat.de License: GPL-2+ +License: GPL-2+ + On Debian systems, the complete text of the GNU General Public License + version 2 can be found in `/usr/share/common-licenses/GPL-2'. + License: GPL-2+ or GPL-3+ with KDE e.V. exception This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as @@ -33,32 +37,15 @@ You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. . - On Debian systems, the full text of the GNU General Public - License version 2 can be found in the file + On Debian systems, the full text of the GNU General Public License + versions 2 and 3 can be found in `/usr/share/common-licenses/GPL-2' and `/usr/share/common-licenses/GPL-3'. -License: GFDL-NIV-1.2 - The purpose of this License is to make a manual, textbook, or other - functional and useful document free in the sense of freedom: to - assure everyone the effective freedom to copy and redistribute it, - with or without modifying it, either commercially or noncommercially. - Secondarily, this License preserves for the author and publisher a way - to get credit for their work, while not being considered responsible - for modifications made by others. - . - This License is a kind of copyleft, which means that derivative - works of the document must themselves be free in the same sense. It - complements the GNU General Public License, which is a copyleft - license designed for free software. - . - We have designed this License in order to use it for manuals for free - software, because free software needs free documentation: a free - program should come with manuals providing the same freedoms that the - software does. But this License is not limited to software manuals; - it can be used for any textual work, regardless of subject matter or - whether it is published as a printed book. We recommend this License - principally for works whose purpose is instruction or reference. +License: GFDL-NIV-1.2+ + Permission is granted to copy, distribute and/or modify this document under + the terms of the GNU Free Documentation License, Version 1.2 or any later + version published by the Free Software Foundation; with no Invariant + Sections, no Front-Cover Texts, and no Back-Cover Texts. . - On Debian systems, the full text of the GNU General Public - License version 2 can be found in the file - `/usr/share/common-licenses/GFDL-1.2'. \ No newline at end of file + On Debian systems, the complete text of the GNU Free Documentation License + version 1.2 can be found in `/usr/share/common-licenses/GFDL-1.2'.
Bug#695160: unblock (pre-approval): akonadi/1.7.2-2
Alle lunedì 10 dicembre 2012, Julien Cristau ha scritto: On Thu, Dec 6, 2012 at 16:22:55 +0100, Pino Toscano wrote: Alle mercoledì 5 dicembre 2012, Julien Cristau ha scritto: On Tue, Dec 4, 2012 at 20:09:38 +0100, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I would like to upload akonadi 1.7.2-2. The only change is a fix in the provided README.Debian, to actually match the configuration format. You don't really need pre-approval for trivial changes... OK, uploaded and built everywhere. Unblocked. For whatever reason it's stuck behind qt4-x11, though. It has not been actually unblocked... -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#694617: unblock (pre-approval): konsole/4:4.8.4-2
Alle venerdì 7 dicembre 2012, Niels Thykier ha scritto: On 2012-11-28 13:31, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I would like to upload konsole 4:4.8.4-2 with the following two changes: - konsole-dbg recommends kdelibs5-dbg - backport an upstream patch to simplify/fix the search of executables; upstream recommended us to provide it, he fixed that while working on another bug Attached the current diff out of the packaging repo of the changes above. Thanks, -- Pino Hi, Please go ahead and let us know when it has been rebuilt on the relevant architectures. Thank you; it has been uploaded a couple of hours ago, and built fine everywhere. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#695160: unblock (pre-approval): akonadi/1.7.2-2
Alle mercoledì 5 dicembre 2012, Julien Cristau ha scritto: On Tue, Dec 4, 2012 at 20:09:38 +0100, Pino Toscano wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I would like to upload akonadi 1.7.2-2. The only change is a fix in the provided README.Debian, to actually match the configuration format. You don't really need pre-approval for trivial changes... OK, uploaded and built everywhere. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#694830: unblock: kde-workspace/4:4.8.4-5
Alle lunedì 3 dicembre 2012, Julien Cristau ha scritto: On Sat, Dec 1, 2012 at 00:28:05 +0100, Pino Toscano wrote: we would like to upload kde-workspace 4:4.8.4-5, which so far would provide a number of updates/fixes: - a minor changelog fix to the previous version - fix the X session registration, which was off due to a mismatch between an old debian option and the actual configuration key (#692730) - the backport of an upstream fix for the taskbar widget, which would not unnecessarly notify windows as demanding attention (#685334) - the backport of an upstream patch to improve a patch backported already in 4:4.8.4-3 - the backport of 3 upstream patches to fix the reading of two configuration files (kwinrc and powermanagementprofilesrc) as cascading configuration (i.e. so values in configs in global paths like /u/s/kde4/config and the Debian-specific /e/kde4, for the local admin, can be used) - the backport of an upstream fix for the saving of panel launchers of preferred apps (#686131) - drop hal from kdm.init (#694021) - kde-workspace-bin: - ship a /etc/kde4 directory, so postinst can work (#694253) - explicitly depend on qdbus, used by startkde - encoding fixes for the debconf translations of es (#692209) and pl (#691953) Generally, all the proposed changes should be safe; in case, the upload could be aged to more days to give it more days. Ack to all except the hal removal in kdm.init, this is still needed on !linux. With the above change, uploaded and built basically everywhere. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#695160: unblock (pre-approval): akonadi/1.7.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I would like to upload akonadi 1.7.2-2. The only change is a fix in the provided README.Debian, to actually match the configuration format. Attached the current diff out of the packaging repo of the changes above. Thanks, -- Pino diff --git a/debian/README.Debian b/debian/README.Debian index fc6d9fc..774b7c5 100644 --- a/debian/README.Debian +++ b/debian/README.Debian @@ -47,7 +47,7 @@ At the moment, the following backends are supported: This backend uses official QSql MySQL driver. The following configuration options are available: - [General] + [%General] Driver=QMYSQL [QMYSQL] @@ -71,7 +71,7 @@ At the moment, the following backends are supported: This backend uses QSql PSQL driver. The following configuration options are available: - [General] + [%General] Driver=QPSQL [QPSQL] @@ -94,7 +94,7 @@ At the moment, the following backends are supported: also shipped in the backend package. The following configuration options are available: - [General] + [%General] Driver=QSQLITE3 [QSQLITE3] diff --git a/debian/changelog b/debian/changelog index a60860c..78c7441 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +akonadi (1.7.2-2) UNRELEASED; urgency=low + + [ Lisandro Damián Nicanor Pérez Meyer ] + * Change [General] to [%General] in README.Debian (Closes: #688236). +Thanks Alexander Wuerstlein for noticing. + + -- Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Thu, 20 Sep 2012 14:58:24 -0300 + akonadi (1.7.2-1) unstable; urgency=low * New upstream release.
Bug#694830: unblock: kde-workspace/4:4.8.4-5
Alle lunedì 3 dicembre 2012, Julien Cristau ha scritto: On Sat, Dec 1, 2012 at 00:28:05 +0100, Pino Toscano wrote: we would like to upload kde-workspace 4:4.8.4-5, which so far would provide a number of updates/fixes: - a minor changelog fix to the previous version - fix the X session registration, which was off due to a mismatch between an old debian option and the actual configuration key (#692730) - the backport of an upstream fix for the taskbar widget, which would not unnecessarly notify windows as demanding attention (#685334) - the backport of an upstream patch to improve a patch backported already in 4:4.8.4-3 - the backport of 3 upstream patches to fix the reading of two configuration files (kwinrc and powermanagementprofilesrc) as cascading configuration (i.e. so values in configs in global paths like /u/s/kde4/config and the Debian-specific /e/kde4, for the local admin, can be used) - the backport of an upstream fix for the saving of panel launchers of preferred apps (#686131) - drop hal from kdm.init (#694021) - kde-workspace-bin: - ship a /etc/kde4 directory, so postinst can work (#694253) - explicitly depend on qdbus, used by startkde - encoding fixes for the debconf translations of es (#692209) and pl (#691953) Generally, all the proposed changes should be safe; in case, the upload could be aged to more days to give it more days. Ack to all except the hal removal in kdm.init, this is still needed on !linux. Hm, but hal does not ship an init.d script in current wheezy though, so how could that dependency be satisfied even with hal installed? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#694830: unblock: kde-workspace/4:4.8.4-5
Alle lunedì 3 dicembre 2012, Julien Cristau ha scritto: On Mon, Dec 3, 2012 at 21:59:08 +0100, Pino Toscano wrote: Alle lunedì 3 dicembre 2012, Julien Cristau ha scritto: On Sat, Dec 1, 2012 at 00:28:05 +0100, Pino Toscano wrote: we would like to upload kde-workspace 4:4.8.4-5, which so far would provide a number of updates/fixes: - a minor changelog fix to the previous version - fix the X session registration, which was off due to a mismatch between an old debian option and the actual configuration key (#692730) - the backport of an upstream fix for the taskbar widget, which would not unnecessarly notify windows as demanding attention (#685334) - the backport of an upstream patch to improve a patch backported already in 4:4.8.4-3 - the backport of 3 upstream patches to fix the reading of two configuration files (kwinrc and powermanagementprofilesrc) as cascading configuration (i.e. so values in configs in global paths like /u/s/kde4/config and the Debian-specific /e/kde4, for the local admin, can be used) - the backport of an upstream fix for the saving of panel launchers of preferred apps (#686131) - drop hal from kdm.init (#694021) - kde-workspace-bin: - ship a /etc/kde4 directory, so postinst can work (#694253) - explicitly depend on qdbus, used by startkde - encoding fixes for the debconf translations of es (#692209) and pl (#691953) Generally, all the proposed changes should be safe; in case, the upload could be aged to more days to give it more days. Ack to all except the hal removal in kdm.init, this is still needed on !linux. Hm, but hal does not ship an init.d script in current wheezy though, so how could that dependency be satisfied even with hal installed? Hrm. I seem to remember a conversation with Michael about that, don't remember what the outcome was. OK, I removed that change for now, let's revise that after Wheezy; the rest will be uploaded soon. Thanks for the review, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#694830: unblock: kde-workspace/4:4.8.4-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
we would like to upload kde-workspace 4:4.8.4-5, which so far would
provide a number of updates/fixes:
- a minor changelog fix to the previous version
- fix the X session registration, which was off due to a mismatch
between an old debian option and the actual configuration key
(#692730)
- the backport of an upstream fix for the taskbar widget, which would
not unnecessarly notify windows as demanding attention (#685334)
- the backport of an upstream patch to improve a patch backported
already in 4:4.8.4-3
- the backport of 3 upstream patches to fix the reading of two
configuration files (kwinrc and powermanagementprofilesrc) as
cascading configuration (i.e. so values in configs in global paths
like /u/s/kde4/config and the Debian-specific /e/kde4, for the local
admin, can be used)
- the backport of an upstream fix for the saving of panel launchers of
preferred apps (#686131)
- drop hal from kdm.init (#694021)
- kde-workspace-bin:
- ship a /etc/kde4 directory, so postinst can work (#694253)
- explicitly depend on qdbus, used by startkde
- encoding fixes for the debconf translations of es (#692209) and pl
(#691953)
Generally, all the proposed changes should be safe; in case, the upload
could be aged to more days to give it more days.
Attached the current debdiff.
Thanks,
--
Pino
diff -Nru kde-workspace-4.8.4/debian/changelog kde-workspace-4.8.4/debian/changelog
--- kde-workspace-4.8.4/debian/changelog 2012-10-21 11:07:18.0 -0300
+++ kde-workspace-4.8.4/debian/changelog 2012-11-30 20:04:40.0 -0300
@@ -1,6 +1,44 @@
+kde-workspace (4:4.8.4-5) UNRELEASED; urgency=low
+
+ [ Lisandro Damián Nicanor Pérez Meyer ]
+ * Remove New upstream release from the previous changelog entry
+(Closes: #691302). Thanks Filipus Klutiero.
+ * sessreg was merged in kdm (Closes: #692730):
+- Drop the use-sessreg option in kdm.options and its man page, as it is
+ no longer needed.
+- Do not set UseSessReg to false in debian/patches/kdmrc_defaults.diff.
+ The bug it solved has dissapeared during the merge.
+Thanks Wolfgang Schweer and Petter Reinholdtsen for digging into this.
+
+ [ Pino Toscano ]
+ * Backport upstream commit 89161c40e064958aa192b2202670316671d7e377 to fix
+the demand status of windows in the taskbar widget; patch
+upstream_Check-if-attention-demanding-status-has-changed-when.patch.
+(Closes: #685334)
+ * Backport upstream commits d0343319fcfc249a38c79171be727d7133984eeb and
+53f6eca921a44a1f5e567b92d45ea84599afea74 to make powermanagementprofilesrc
+read as cascading config, and 9994e178b790b03a464c335e624366f82f0da643 for
+kwinrc.
+ * Backport upstream commit 5b35757fc3613a18e2d784af53d1d23ebe295028 to
+improve the sorting of init .js files (followup of the changes backported
+in 4:4.8.4-3 with upstream_make-sure-scripts-are-executed-sorted.patch);
+patch upstream_Make-sure-the-plasma-desktop-scripts-are-sorted-in-t.patch.
+ * Backport upstream commit 70cd86a5eef103137e64f2e3868a5bd2d58d71d7 to fix
+the deletion of launchers of preferred applications; patch
+upstream_Fix-deletion-of-preferred-application-launchers.patch.
+(Closes: #686131)
+ * Drop hal from kdm.init. (Closes: #694021)
+ * Make kde-workspace-bin ship a /etc/kde4 directory. (Closes: #694253)
+ * Make kde-workspace-bin explicitly depend on qdbus, used by startkde.
+
+ [ Debconf translation updates ]
+ * Fix encoding of Polish (thanks to David Prévot). (Closes: #691953)
+ * Fix encoding of Spanish (thanks to Camaleón). (Closes: #692209)
+
+ -- Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Wed, 24 Oct 2012 17:06:28 -0300
+
kde-workspace (4:4.8.4-4) unstable; urgency=low
- * New upstream release.
* The package (re)building switches to XZ compression. (Closes: #688761)
[ Pino Toscano ]
diff -Nru kde-workspace-4.8.4/debian/control kde-workspace-4.8.4/debian/control
--- kde-workspace-4.8.4/debian/control 2012-10-21 11:06:24.0 -0300
+++ kde-workspace-4.8.4/debian/control 2012-11-30 20:04:40.0 -0300
@@ -109,7 +109,7 @@
Depends: ${shlibs:Depends}, ${misc:Depends}, iso-codes,
plasma-desktop (= ${binary:Version}) | plasma-netbook (= ${binary:Version}),
kde-workspace-data (= ${source:Version}), x11-utils, x11-xserver-utils,
- kde-workspace-kgreet-plugins (= ${binary:Version})
+ kde-workspace-kgreet-plugins (= ${binary:Version}), qdbus
Recommends: plasma-scriptengines, polkit-kde-1 (= 0.99) | policykit-1-gnome,
upower [linux-any]
Suggests: x11-xkb-utils
diff -Nru kde-workspace-4.8.4/debian/kde-workspace-bin.dirs kde-workspace-4.8.4/debian/kde-workspace-bin.dirs
--- kde-workspace-4.8.4/debian/kde-workspace-bin.dirs 1969-12-31 21:00:00.0 -0300
+++ kde-workspace-4.8.4/debian/kde-workspace-bin.dirs 2012-11-30 20:04:40.0 -0300
@@ -0,0 +1 @@
+etc/kde4
diff -Nru kde
Bug#694830: unblock: kde-workspace/4:4.8.4-5
retitle 694830 unblock (pre-approval): kde-workspace/4:4.8.4-5 thanks Alle sabato 1 dicembre 2012, Pino Toscano ha scritto: we would like to upload kde-workspace 4:4.8.4-5, which so far would provide a number of updates/fixes: Forgot to properly modify the subject, as this is a pre-approval request. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#694743: unblock (pre-approval): kgpg/4:4.8.4-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
I would like to upload kgpg 4:4.8.4-4.
The only change is the addition of the gnupg | gnupg2 dependency;
so far it went unnoticed because apt depends on gnupg (so kgpg would
work in basically almost any Debian installation), but having the
explicit dependency would be a good idea anyway.
Attached the current diff out of the packaging repo of the changes
above.
Thanks,
--
Pino
diff --git a/debian/changelog b/debian/changelog
index a8ab8f2..bd02e1e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kgpg (4:4.8.4-4) UNRELEASED; urgency=low
+
+ [ Lisandro Damián Nicanor Pérez Meyer ]
+ * Depend on gnupg or gnupg2 (Closes: #686632).
+
+ -- Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Tue, 04 Sep 2012 20:40:47 -0300
+
kgpg (4:4.8.4-3) unstable; urgency=low
* Team upload.
diff --git a/debian/control b/debian/control
index 14adc66..74c34f7 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Vcs-Git: git://git.debian.org/pkg-kde/kde-sc/kgpg.git
Package: kgpg
Section: utils
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: gnupg | gnupg2, ${shlibs:Depends}, ${misc:Depends}
Description: graphical front end for GNU Privacy Guard
Kgpg manages cryptographic keys for the GNU Privacy Guard, and can encrypt,
decrypt, sign, and verify files. It features a simple editor for applying
Bug#694743: unblock (pre-approval): kgpg/4:4.8.4-4
Hi, Alle giovedì 29 novembre 2012, Adam D. Barratt ha scritto: On Thu, 2012-11-29 at 20:18 +0100, Pino Toscano wrote: I would like to upload kgpg 4:4.8.4-4. The only change is the addition of the gnupg | gnupg2 dependency; so far it went unnoticed because apt depends on gnupg (so kgpg would work in basically almost any Debian installation), but having the explicit dependency would be a good idea anyway. Please go ahead; thanks. Thanks; uploaded and built almost everywhere. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#694600: unblock (pre-approval): kgamma/4:4.8.4-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
I would like to upload kgamma 4.8.4-2.
The only change is the backport of an upstream patch to fix the crash
of this configuration module when being run as different user than the
one currently logged in X.
Attached the current diff out of the packaging repo of the changes
above.
Thanks,
--
Pino
diff --git a/debian/changelog b/debian/changelog
index c8f3e08..8af9522 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+kgamma (4:4.8.4-2) UNRELEASED; urgency=low
+
+ [ Pino Toscano ]
+ * Backport upstream commit 1918f145261a52a3b2a917c6784c2cebecbb4064 to fix
+crash when run as different user (e.g. root); patch
+upstream_Fix-crash-when-XVidExtWrap-is-not-available.patch.
+(Closes: #688767)
+
+ -- Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Wed, 28 Nov 2012 10:42:59 +0100
+
kgamma (4:4.8.4-1) unstable; urgency=low
* Team upload.
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..b4726e5
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+upstream_Fix-crash-when-XVidExtWrap-is-not-available.patch
diff --git a/debian/patches/upstream_Fix-crash-when-XVidExtWrap-is-not-available.patch b/debian/patches/upstream_Fix-crash-when-XVidExtWrap-is-not-available.patch
new file mode 100644
index 000..abe8479
--- /dev/null
+++ b/debian/patches/upstream_Fix-crash-when-XVidExtWrap-is-not-available.patch
@@ -0,0 +1,50 @@
+From 1918f145261a52a3b2a917c6784c2cebecbb4064 Mon Sep 17 00:00:00 2001
+From: Christoph Feck christ...@maxiom.de
+Date: Sun, 11 Nov 2012 02:19:01 +0100
+Subject: [PATCH] Fix crash when XVidExtWrap is not available
+
+This can happen when run as root
+BUG: 292335
+FIXED-IN: 4.10
+---
+ kcmkgamma/kgamma.cpp | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/kcmkgamma/kgamma.cpp b/kcmkgamma/kgamma.cpp
+index ffe29ea..890ba99 100644
+--- a/kcmkgamma/kgamma.cpp
b/kcmkgamma/kgamma.cpp
+@@ -70,7 +70,7 @@ KGamma::KGamma(QWidget* parent_P, const QVariantList )
+ :KCModule(KGammaConfigFactory::componentData(), parent_P), rootProcess(0)
+ {
+ bool ok;
+- GammaCorrection = true;
++ GammaCorrection = false;
+ xv = new XVidExtWrap(ok, NULL);
+ if (ok) { /* KDE 4: Uneccessary test, when all KCM wrappers do conditional loading */
+ xv-getGamma(XVidExtWrap::Red, ok);
+@@ -94,6 +94,7 @@ KGamma::KGamma(QWidget* parent_P, const QVariantList )
+ xv-setScreen(currentScreen);
+
+ rootProcess = new KProcess;
++ GammaCorrection = true;
+ setupUI();
+ saved = false;
+
+@@ -107,10 +108,9 @@ KGamma::KGamma(QWidget* parent_P, const QVariantList )
+ }
+ load();
+ }
+-else { //something is wrong, show only error message
+- GammaCorrection = false;
+- setupUI();
+-}
++ }
++ if (!GammaCorrection) { //something is wrong, show only error message
++setupUI();
+ }
+ }
+
+--
+1.7.10.4
+
