Bug#1070806: RM: kseexpr/experimental -- ROM; 64bit time_t transition not needed
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ksee...@packages.debian.org Control: affects -1 + src:kseexpr User: ftp.debian@packages.debian.org Usertags: remove Hi, please remove kseexpr from experimental: the 64bit time_t transition for it is not needed, as the only time_t reference is an unused typedef in a public header. Thanks, -- Pino
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#1041516: RM: kalgebra kalgebra-common [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kalge...@packages.debian.org Control: affects -1 + src:kalgebra Control: block 1041268 by -1 Hi, please remove the kalgebra & kalgebra-common binary packages on mipsel: they used to be built because qtwebengine-opensource-src is available on mipsel. Since qtwebengine-opensource-src FTBFSes on mipsel, and it is scheduled for removal on architecture, please remove the cruft binaries. Please note that src:kalgebra still builds a kalgebramobile binary package on mipsel (like in all the architectures without QtWebEngine). Thanks, -- Pino
Bug#1041515: RM: kalendar [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kalen...@packages.debian.org Control: affects -1 + src:kalendar Control: block 1041268 by -1 Hi, please remove kalendar from mipsel: it uses qtwebengine-opensource-src, which currently FTBFS on mipsel, and thus kalendar was excluded from building on mipsel. Thanks, -- Pino
Re: Proposal: drop Salsa CI testing for now
In data domenica 29 agosto 2021 08:37:00 CEST, Pino Toscano ha scritto: > <<<<< > variables: > SALSA_CI_DISABLE_BLHC: 'no' > >>>>> My bad, this should have been 'yes' (or '1') to actually disable the blhc test. Sorry for the typo, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Proposal: drop Salsa CI testing for now
Hi Norbert, first of all, I just noticed this after you started to disable the salsa CI almost everywhere; this email was sent to the wrong discussion list, and thus it got buried in the usual flood of upload/bug emails. In data mercoledì 18 agosto 2021 08:21:49 CEST, Norbert Preining ha scritto: > I would like to collect opinions concerning Salsa CI testing: Sure. > I contemplate disabling the whole salsa-ci for now, since all tests > always fail, No, all tests do not "always fail". What is usually failing is the blhc test, due to blhc mistaking the cmake automoc commands as build commands. There is a semi-long story about this, which is a different discussion topic than this. To make it short, it can be easily disabled for the affected projects (i.e. only those using qt5+cmake, qt5+qmake is not affected) using the following variable in the yaml file: <<<<< variables: SALSA_CI_DISABLE_BLHC: 'no' >>>>> Every other test is perfectly valid and working. Even better, they actually showed issues in your recent uploads that would have been nice to first *before* the upload, rather than afterwards; for example https://salsa.debian.org/qt-kde-team/kde/cantor/-/jobs/1833161 i.e. cantor being unbuildable because of an unsatified build dependency (old libqalculate). There are similar cases also for failed autopkgtest that I fixed after. There are possible failures due to another kde package being not available yet in the archive; I think the various plasma package use a custom repository for it, which should do the job. If it does not, let's look into it. > and we only take a lot of computing power for tests > that nobody looks into, and hundreds of emails. Well, if you don't care about it, that isn't the same as saying it is not useful. It only means that, well, you don't care about it. > I have no intention to fix the salsa-ci stuff, so I would like to > disable it. > > If someone wants to work on getting the CI testing working again, we can > reenable it again. I mentioned above the way to avoid getting rid of the majority of the "issues". Hence, please re-enable the salsa CI, which *is* useful even if you don't care about it. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Proposal: drop Salsa CI testing for now
In data mercoledì 18 agosto 2021 21:26:04 CEST, Nicholas D Steeves ha scritto: > It's also a problem if all tests need to be updated for every release, > because that means that uploads of new releases will stall until a > hypothetical volunteer for CI work fixes the tests...if we use CI as a > "ready for upload" indicator. If we're not using it for that, then it's > a waste of electricity. > > I'm also concerned that the situation is fundamentally wrong: If tests > need to be updated with every new release, something is wrong with the > tests, or the infrastructure... Tests and infrastructure are supposed > to be the controls that enable meaningful results when testing for > correct functionality in the face of changes. eg: Imho, changing the > tests or infrastructure for every new release is bad methodology that > does not provide meaningful results. There is no such thing as "tests that need to be updated for every release"; I have no idea who told you that or where you read it, but it is definitely wrong. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
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-kde@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-kde@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-kde@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
Bug#992697: RM: cantor [armel ppc64el s390x] -- ROM; requires QtWebEngine
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-qt-kde@lists.debian.org Hi, the new version of src:cantor requires QtWebEngine for the main interface: as result, it is built only on few architectures. Hence, please remove cantor on the following architectures: armel ppc64el s390x Thanks, -- Pino
Bug#981515: kcoreaddons: please replace fam with gamin
block 981515 by 510368 thanks Hi, In data venerdì 20 agosto 2021 13:32:08 CEST, Chris Hofstaedtler ha scritto: > given we are now in the bookworm cycle - do you think kcoreaddons > could remove fam (or replace it with gamin if really needed)? As I wrote a couple of times in this bug already: #510368 must be fixed first. It seems like I forgot to set this dependency, so I'm adding it now. Also, considering that there is a huge queue of RM bugs on the FTP-masters side that have been attended so far a couple of times in this year (sigh), rushing this won't make any change, since the RM will be ignored for some time anyway. Also #2: considering that we are not even a week since the lift of the freeze and everybody and their dogs have already uploaded things of every sort of unstable, please give (me) some time for what is really not a priority. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Hi Dennis,
In data venerdì 26 febbraio 2021 22:48:43 CET, Dennis Filder ha scritto:
> If you decide to use the attached patch, please put the bugnumber in
> the Bug-Debian: field for me.
The patch you provided is the following:
--- qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp
2021-02-26 18:48:50.407487828 +0100
+++ qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp
2021-02-26 18:48:52.711491373 +0100
@@ -8335,8 +8335,8 @@
QQuickItemLayer::~QQuickItemLayer()
{
-delete m_effectSource;
-delete m_effect;
+if (m_effectSource) delete m_effectSource; // FIXME: consider Q_ASSERT()
here instead
+if (m_effect) delete m_effect; // FIXME: consider Q_ASSERT() here instead
}
/*!
Did you actually check that it fixes the problem for you?
The thing is, in C++ (at least since C++98) the delete operator is
defined to be a no-op for a null pointer, much like free() in C.
Hence, constructs like "if (foo) delete foo;" are essentially doing
null pointer checks twice, and with the same no-op result.
A possible cause of the crash could be that the item being deleted was
already deleted, and thus there was a stale pointer somewhere. That is
my own speculation though.
Because of this, I'm inclined to remove the "patch" tag from this bug;
I'd like to hear from Dmitry what he thinks about it (since he already
handled this bug).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
In data venerdì 5 marzo 2021 18:16:18 CET, Glenn Strauss ha scritto: > On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote: > > > Personally, I'd argue that switching the FAM implementation across the > > distribution _is_ a "transition", and as such it ought to have been > > requested (if not even started) two months ago. > > In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor > > I posted in October 2020 on that bug where FAM was abandoned. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 > Debian developers did not suggest "next steps" for over 3 months, > until the freeze occurred. > > The bug was not touched by a Debian Developer until 31 Jan 2021. This message was addressed only to bugs, one of them was assigned to "wnpp" and the other to libgamon0: this means that only the gamin maintainer (1 specific person, as there is no group maintenance) and who watches the bugs of wnpp and src:gamin actually read it. Becuase of this, its audience was limited, and neither the general list for Debian development (debian-devel) nor the release team (release-team) were notified/aware of it by default. I can understand your frustation, but that is not a reason to rush things just because of this. All the deadline for Debian releases have been more or less streamlined/standardized for at least the past 2 stable releases already, so every step is well known in advance. Because of this, for example, we were not able to provide Plasma 5.12 in Bullseye. > The solution is to remove FAM. And nobody, really, *nobody* ever said the opposite, so please stop repeating that it is not wanted. > Back on topic: > > If you take a moment to look in the kcoreaddons code, you can see that > kcoreaddons has multiple mechanisms for filesystem notification. > If FAM interfaces fail for any reason, kcoreaddons switches to an > alternative mechanism. > > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611 > > Therefore, your FUD is unsubstantiated. Changing kcoreaddons to use > gamin, or to not use FAM or gamin, are both reasonable options. > As I posted in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49 > gamin can be configured to poll NFS locations and so is a reasonable > substitution for FAM, not limited to inotify() as Sune suggested in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39 Sure, I well know that KDirWatch in kcoreaddons builds fine with either libfam or gamin as "FAM", I remember people doing this many years ago in other distributions. However, what I said is something completely different, let me summarize it in short points for easier understanding: - I am fine switching from libfam to gamin in the future - I am fine dropping libfam from Debian in the future - I want first libgamin to stop providing libfam - switching from libfam from gamin *is* switching FAM implementation, and thus which code is used for "FAM", and possibily different bugs; hence, this is *too late* to properly test is in Bullseye There is no FUD in what I said. > It is true that this relatively safe change is being requested during > the soft freeze and so should be scrutinized. However, that does not > make the requested change any more or less dangerous. It does mean > less time to test by people who, in your own words, might not be using > this feature: > > and these FAM/gamin bits do not get much of use these days So if, "less time to test by people who [...] might not be using this feature", this switch is even more dangerous. Thanks from proving my point. > I posit that the code in upstream kcoreaddons is already better tested > than would be Debian "testing" (existence in tree?) of an additional > month or two or three of the Debian kcoreaddons package configured to > use gamin (or to use neither FAM nor gamin). This "additional month or two or three" we are talking about is called "Debian freeze". Dependency changes like this are very much *not* the kind of changes we want to introduce during a freeze. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
Dear Glenn, In data venerdì 5 marzo 2021 16:41:40 CET, Glenn Strauss ha scritto: > In #981513, courier changed to use libgamin-dev, so > kcoreaddons is now the *only* remaining package using FAM. > > As such, there is considerably more risk to doing nothing > than there is to migrating to gamin. No, there is more risk in switching to a different library at this phase of the Debian freeze. > ==> Please change kcoreaddons to use libgamin-dev for Bullseye. > https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 While I understand your motivation behind this change, I'll repeat once again what I said previously in this bug: this is *not* going to happen for Bullseye, full stop. The reason is that we are talking about switching to a different library for a functionality that is rarely used these days (but potentially can be), hence a switch at this phase is very risky, and gives basically no time to test or even get feedback about it. The freeze for transitions started almost two months ago, on January 13th: https://lists.debian.org/debian-devel-announce/2021/01/msg2.html Personally, I'd argue that switching the FAM implementation across the distribution _is_ a "transition", and as such it ought to have been requested (if not even started) two months ago. On February 13th, a "mild freeze" started: https://lists.debian.org/debian-devel-announce/2021/02/msg2.html while changes at the beginning of it still migrated to testing, IMHO the switch of a dependency raises the bar of the risk; while I can check it for things I upload and work for, this feature represents something corner-case, which I don't have neither the setup nor the time to properly test. This request was opened at the end of January (so in transition freeze already, and IMHO enough to make it out of scope for Bullseye), and my question about the timing for this got "not for Bullseye" as answer. All the more traffic for you, Glenn, started two days ago, already in a time frame where uploads to unstable will not migrate to testing anymore [1], and thus it will need exception from release-team, meaning it has to be something importat/serious enough (and this is not, as the status of it would be the same as in previous Debian releases). [1] automatic migration ends on March 13th, and the default migration time is 10 days, which means the last day for such uploads was March 2nd Moreover, I already stated that I really want #510368 fixed _before_ switching the dependency, and that bug has not been fixed yet (and unlikely to be for Bullseye). So, thanks again for the time and interest in this, but this will be handled only after both a) Bullseye is released b) #510368 is fixed. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon
In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto: > I had checked the upstream repository before reporting this issue > (that's where I got the filename), it still contains this version of the > icon. Reporting here, because I couldn't find an issue tracker on KDE > GitLab. https://bugs.kde.org is the KDE upstream bug tracking system. Please report it there, rather than on a downstream bug tracking system. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon
Hi Bohdan, In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto: > Package: kdeconnect > Version: 20.04.3-1 > Severity: wishlist > > Dear Maintainer, > > the current icon looks very similar to a broken image icon. I thought it > was broken for several months, until I squinted and found out that × is > actually K. Though when I glance over it, I still subconciously percieve > it as a broken image icon. Please redesign it to something more contrast > and distinct; the light version of the icon does not have this issue. Please note that we do not do upstream development, and this kind of change (i.e. artwork) ought to be done by upstream, either in kdeconnect itself or in the breeze icon theme. Please note also: > Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, > TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), > LANGUAGE=ru_UA:ru > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages kdeconnect depends on: > ii kde-cli-tools 4:5.17.5-2 > ii kio 5.70.1-1 > ii libc6 2.31-3 > ii libfakekey0 0.3+git20170516-2 > ii libkf5configcore5 5.70.0-1 kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04: your system is ~6 month behind of the current Debian testing. Please fully dist-update your system when reporting bugs for unstable or testing, as otherwise there is the risk of reporting stale issues. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981679: Closing as per reporter request
reopen 981679 thanks Hi, In data giovedì 11 febbraio 2021 10:18:14 CET, Aurélien COUDERC ha scritto: > control: fixed -1 4:5.6.2-4 > > Thanks for the follow up. > Closing as per your request. > > What I read from upstream git log is that the commit you mention is on master > and the fix was actually backported to the 5.6 branch as > 4688d626c145711e35f3676dbd4c827b3b2ea7f6. The upload of kdevelop 4:5.6.2-4 fixes what Justin reported, i.e. that the clang plugin cannot parse the clang version string in more recent Debian clang versions. The original problem, though, is totally different: the clang plugin hardcodes the clang include directory and the clang version and, while it appears to have some logic to handle runtime version bumps, it seems it cannot fully cope with this situation. It looks like there is no more issue simply because the upload of kdevelop 5.6.2 (starting with 4:5.6.2-1) rebuilds with the latest clang, so it makes the problem "go away" until the next time the default clang version (currently 11) is updated in Debian. Because of this, the actual problem reported in this bug report *is* still valid, and I hope upstream can do something about it so we (in Debian) don't get breakages on clang version bumps. Luckly, I did changes in the packaging so it is possible to binNMU (i.e. a plain no-changes rebuild) kdevelop in such situations, and the rebuilt kdevelop will not migrate to testing until the newer clang version migrated too; it is mostly a workaround though. Julien: while I thank you for spotting the issue with the parsing of clang version string, I strongly recommend you to report *new* bugs for problems different that what reported. It is always easier to merge bugs in case they are actually the same issue, while adding different and unrelated issues to a bug makes it really hard to properly track what is fixed and what is not. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: plasma-firewall_5.20.90-1_amd64.changes REJECTED
Hi Thorsten, In data mercoledì 3 febbraio 2021 23:00:09 CET, Thorsten Alteholz ha scritto: > Hi Pino, > > please also mention the LGPL of some .po-files in your debian/copyright. These .po files are still free software, released under a DFGS license. I honestly see no reason to reject a package just because of this, rather than sending a note to the uploader, and optionally opening an RC bug with the issue to make sure it is not forgotten. Not to mention that the affected files are translations, dynamically loaded at runtime, and whose license does not affect the license of the main "binary" components. Now, instead of fixing copyright adding the DFSG license and doing a simple source-only upload as usual, I need to: - rebuild the binaries - upload the binaries to NEW - wait for an FTP-Master to re-review this once again, with no time expectations (as usual...) FTP-Masters: please consider to be a bit more helpful towards maintainers' work, rather than expecting perfection for new sources. It will be surely appreciated. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
In data lunedì 1 febbraio 2021 00:00:47 CET, Chris Hofstaedtler ha scritto: > Source: kcoreaddons > Version: 5.54.0-1 > > Dear Maintainer, > > your package currently Depends on libfam0 (fam), which has > been requested to be removed in #966273. Please switch to gamin > instead. You can find more info, and an analysis of what probably > needs to be done for your package in this message from Glenn Strauss: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 I wouldn't say that gamin is more maintained than FAM: - on the upstream side (gnome.org), it was moved the "Archive" section of the gnome gitlab - during the migration to gitlab, all the bugzilla tickets were closed instead of migrated too, because the project is archived - on the Debian side, gamin saw 4 uploads (one of them is an NMU) in the last 10 years - #510368 prevents to switch from FAM to gamin, as it will build against libgamin but still pulling libfam (or keep an old libfam as valid package satisfying the dependency) > Severity of this bug will probably raise over time. What is "over time" implying, please? I really hope this is not for bullseye: we are so close to its freeze, and these FAM/gamin bits do not get much of use these days, so the risk of release regressions seems medium/high to me. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#966036: kajongg: Uses old name of sip module
Hi Dmitry,
apparently I missed this sip-related bug.
In data mercoledì 22 luglio 2020 13:31:19 CET, Dmitry Shachnev ha scritto:
> Source: kajongg
> Version: 4:19.12.3-1
> Usertags: sip5
>
> Dear Maintainer,
>
> You are receiving this bug because your package seems to be using PyQt5
> and has Python files with "import sip" lines.
>
> With the latest version of PyQt5 in experimental, the private sip module
> used by PyQt5 is called "PyQt5.sip", not just "sip". I am going to upload
> this version to unstable around end of August.
>
> You may need to update your imports to do something like this:
>
> try:
> from PyQt5 import sip
> except ModuleNotFoundError:
> import sip
>
> Alternatively, you may import sip after importing PyQt5. So the following
> will work too:
>
> from PyQt5 import QtCore
> import sip
>
> Please see the following link for details:
>
> https://www.riverbankcomputing.com/static/Docs/PyQt5/incompatibilities.html#importing-the-sip-module
>
> If you use sip for reasons unrelated to PyQt5, you may leave the old import
> as is, but please bear in mind that sip4 is deprecated.
>
> Also, calls like "sip.setapi('QDate', 2)" are not needed at all with PyQt5.
> They were needed only with PyQt4 and Python 2. It is safe to delete them.
>
> For the actual documentation of sip module, see the following link:
>
> https://www.riverbankcomputing.com/static/Docs/PyQt5/api/sip/sip-module.html
It seems the sip-related bits are still the same. It looks to me that
sip is used for the following this:
1) sip.unwrapinstance()
2) sip.SIP_VERSION_STR (printed in the about dialog)
3) sip.cast()
I do not know whether it is possible to "do stuff" without using them;
would it be possible for you (not a priority though) to send patches
upstream in case?
https://invent.kde.org/games/kajongg
It definitely should be easier than with krita... ;-)
Thanks,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#979577: qtcreator: Clang Code Model no longer finds 'stddef.h' since version 4.14.0-2
In data venerdì 8 gennaio 2021 16:52:02 CET, Michael Weghorn ha scritto: > Package: qtcreator > Version: 4.14.0-2 > Severity: normal > X-Debbugs-Cc: m.wegh...@posteo.de > > Dear Maintainer, > > since version 4.14.0-2, Qt Creator's Clang Code Model is unable to find the > 'stddef.h' header. It still works OK with version 4.14.0-1. qtcreator 4.14.0-2 has been available in unstable (which you use) for more than two weeks, so reading this problem now seems slightly awkward. Have you used qtcreator 4.14.0-2 (and it code model) successfully so far in the past two weeks? My suspect is the upload of llvm-toolchain-11 done yesterday, and your package list: > ii libclang1-11 1:11.0.1-2 show you updated to it. Can you please try to backport your LLVM/Clang 11 packages to the same version used to build qtcreator? You can get the list of installed packages using: $ dpkg -l '*llvm*11*' | grep ^ii $ dpkg -l '*clang*11*' | grep ^ii and then use the `debsnap` tool, part of the devscripts package, to download them, e.g.: $ debsnap -d . -a amd64 libclang-11 1:11.0.1~+rc2-1 (you will need to repeat that for all the packages you have installed, removing the :amd64 suffix in the packages that have multi-arch annotations). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever
In data domenica 27 dicembre 2020 03:53:01 CET, Jonas Smedegaard ha scritto: > Version: 9.53.3~dfsg-6 > > Quoting Pino Toscano (2020-12-22 10:08:12) > > In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto: > > > > On my side, rebuilding libspectre1 solved this on my system. > > > > > > If a simple rebuild with no source changes fixes the symptoms of a > > > bug, that might indicate an unintended ABI break in libgs9, or > > > perhaps a bug in the old libgs9 headers (but fixed in the new > > > headers) in code that gets inlined into libspectre at compile time. > > > > Both of them are issues in ghostscript anyway. > > This was fixed in Ghostscript since release 9.53.3~dfsg-6 - I just > forgot to mention it in changelog (that will be corrected in next > release). Oh nice, I did not notice it. I can confirm that using - libgs9 9.53.3~dfsg-6 - libspectre1 0.2.9-1 - evince 3.38.0-3 there are no problems opening PS files in evince. Thanks! -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#881761: signon-plugin-oauth2 FTCBFS: does not pass cross tools to qmake and other issues
Hi Helmut, In data martedì 14 novembre 2017 22:32:01 CET, Helmut Grohne ha scritto: > Source: signon-plugin-oauth2 > Version: 0.22-1 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > signon-plugin-oauth2 fails to cross build from source for multiple > reasons: > * It does not pass cross tools to qmake. This task can be easily >deferred to dh_auto_configure these days, but it doesn't fully work, >so in the best case dh_auto_build will fail until debhelper is fixed. This was a bug, even more problematic than just for cross-building. I included this part in my recent signon-plugin-oauth2 0.25-1 upload. > * It uses uname -m to discover the host cpu, but that returns the build >cpu of course. > * It uses plain pkg-config, which is the build architecture pkg-config >while the host architecture one was expected. These two look like genuine bugs as well. Can you please send them as merge requests to the upstream repository? https://gitlab.com/accounts-sso/signon-plugin-oauth2 Upstream accepts MRs, so it should be easy to send them patches. I'd rather not include patches downstream that are kept there forever, adding more work to the already small enough attention that this package (and other Accounts SSO packages) already gets... Thanks in advance, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
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#978164: kguiaddons: FTBFS on non-linux
tag 978164 + pending thanks In data sabato 26 dicembre 2020 21:54:19 CET, Samuel Thibault ha scritto: > Source: kguiaddons > Version: 5.77.0-3 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > > Hello, > > kguiaddons currently doesn't build on non-Linux, where Wayland is not > available. The attached patch fixes this. Yes, I know. I already fixed it few days ago: https://salsa.debian.org/qt-kde-team/kde/kguiaddons/-/commit/1130cd0d8f0c95c9536a74034826fbb0ed5f0d8c -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#941721: kde-standard: Cannot open the desktop settings dialog
reassign 941721 dde-qt5integration retitle 941721 crash in libdstyleplugin.so severity 941721 important thanks Hi, sorry for the late answer. In data venerdì 4 ottobre 2019 11:28:48 CET, Mebus ha scritto: > Package: kde-standard > Version: 5:102 > Severity: normal > > Hallo, > > when I open the desktop settings dialog the whole desktop seems to crash and > restart. It happens right after I right click on the desktop. I am expecting > the destkop settings dialog to appear. Let's see the crash report: [KCrash Handler] #6 0x7fbcc97dbdd0 in QWidget::style() const () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #7 0x7fbcc1c28efb in dstyle::Style::drawComboBoxLabelControl(QStyleOption const*, QPainter*, QWidget const*) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/libdstyleplugin.so #8 0x7fbcc1c17636 in dstyle::Style::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/libdstyleplugin.so #9 0x7fbcb83f4d84 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/libqtquickcontrolsplugin.so #10 0x7fbcb83f57ec in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/libqtquickcontrolsplugin.so #11 0x7fbcca798573 in QQuickWindowPrivate::polishItems() () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #12 0x7fbcca7275b5 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #13 0x7fbcca728615 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #14 0x7fbcc90771d5 in QWindow::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #15 0x7fbcca7a22db in QQuickWindow::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #16 0x7fbcc97b64b1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x7fbcc97bd950 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x7fbcc8cbd5a9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x7fbcc906c203 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #20 0x7fbcc906cead in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #21 0x7fbcc904706b in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #22 0x7fbcc34473eb in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #23 0x7fbcc8cbc27b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x7fbcc8cc4262 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #25 0x55990a38d1ab in ?? () #26 0x7fbcc873209b in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #27 0x55990a38d62a in _start () [Inferior 1 (process 1318) detached] It seems like it crashed in libdstyleplugin.so, which is a Deepin DE style plugin. Hence, I'm reassigning this bug to dde-qt5integration; Thank you for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1
reassign 977329 lxqt-qtplugin retitle 977329 lxqt-plugin: platform theme needs fixes for Qt 5.15 tag 977329 = fixed-upstream severity 977329 serious thanks Hi, In data giovedì 24 dicembre 2020 20:48:32 CET, proctor ha scritto: > hi! thanks very much for your help. > > the krita segfault still happens with all latest updates, including the > most recent kernel 5.9.0-5-amd64 > > krita crashes at open. when i select the krita program from the menu > nothing happens at all. > when i run like this: > $ krita > Segmentation fault > > that's what happens > > i'm using lxqt Thanks for the detail about this, and most probably you have lxqt-qtplugin installed, right? I see that the there were various fixes upstream related to the compatibility with Qt 5.15 and color palettes, and I would not be surprised that any of these issues would cause a crash: https://github.com/lxqt/lxqt-qtplugin/issues/54 https://github.com/lxqt/lxqt-qtplugin/pull/55 https://github.com/lxqt/lxqt-qtplugin/commit/8cc32d94b4c9de74b5bcf27fae2d10e6b2b11caf It looks like everything is included in the new upstream release 0.16.0, which then needs to be packaged in Debian. Another check you can do is try to run krita in a different desktop environment / window manager than LxQt. Hence, I'm reassigning this to lxqt-qtplugin with proper metadata. Thanks for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#848180: konsole: Includes application name in window title when configured not to do so
reassign 848180 src:qtbase-opensource-src qtbase-opensource-src/5.7.1~20161021+dfsg-6 retitle 848180 setWindowTitle() includes application name in window title when configured not to do so thanks In data venerdì 23 dicembre 2016 16:36:15 CET, Maximiliano Curia ha scritto: > ¡Hola Aaron! > > El 2016-12-13 a las 19:49 -0500, Aaron Schrab escribió: > > Package: konsole > > Version: 4:16.08.3-1 > > Severity: minor > > > After unchecking the "Show application name on the titlebar" option in the > > Configure Konsole dialog it still inludes " - Konsole" at the end of window > > titles. This occurs even after closing all Konsole windows and restarting > > the > > application. > > > I first observed this with version 4:16.08.2-2 of both the konsole and > > konsole-kpart packages. I upgraded both of those to 4:16.08.3-1 from > > unstable > > to check if the issue was still present (and I again made sure to close all > > windows after the upgrade). Before I installed the version from testing > > yesterday I hadn't used this package in long time, so I can't say how long > > this > > bug has existed. > > I can reproduce the issue, this seems to be a issue in kxmlgui rather than > konsole. konsole calls setCaption or setPlainCaption depending on the value > of > the user setting, the first on documents that it would add the application > name, and the second one that it wouldn't, but sadly this is no longer true ( > since this was ported to qt5), as setCaption is implemented as a single call > to setPlainCaption (and the responsible for adding the application name in > the > title is the qt qpa plugin). > > The setCaption and setPlainCaption documentation can be seen here: > https://cgit.kde.org/kxmlgui.git/tree/src/kmainwindow.h > > While the implementation can be seen here: > https://api.kde.org/frameworks/kxmlgui/html/kmainwindow_8cpp_source.html > > The qt documentation for setWindowTitle can be found here: > http://doc.qt.io/qt-5/qwidget.html#windowTitle-prop > > kxmlgui is missing a way to workaround the setWindowTitle use of the qpa > plugin, this may need to be scale to qtbase. Indeed, this is a Qt limitation: https://bugreports.qt.io/browse/QTBUG-75535 Hence, reassigning to Qt 5. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#942129: kio: no multiarch support.
severity 942129 wishlist thanks Hi, In data giovedì 10 ottobre 2019 19:57:05 CET, peter green ha scritto: > While trying to install a kde app for a foreign architecture. I noticed that > while libkf5declarative5 is multi-arch: same it can only be installed for one > architecture at a time, because it depends on kio and kio has no multi-arch > field. > > Unfortunately it seems kio contains a bunch of stuff in architecture-specific > paths which look like they may be used from other packages, but also contains > native binaries in /usr/bin , so it seems adding multi-arch support would > require splitting the package. > > Thoughts? Multi-arch is in general not something upstream supports; we have some changes mostly related to cross-building, but otherwise anything beyond that is mostly "nice to have". Some of the KDE Frameworks (such as kio) also have runtime components/daemons that can spawn D-Bus services and/or load plugins. This makes the scenario you described above as hard to do, and (personally speaking) not something to invest into unless there is a strong demand for it. Hence, I'm lowering the severity of this to wishlist. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#947361: krita: Keyboard doesn't respond after some popups (f.e show color selector) are opened.
tag 947361 + moreinfo thanks Hi, In data mercoledì 25 dicembre 2019 18:45:19 CET, Fenix ha scritto: > Package: krita > Version: 1:4.2.8.2+dfsg-1 > Severity: normal > > Dear Maintainer, > > Krita seems to have problems with some popups docks, for example > color selector, minimal shade selector... After this controls are showed > if they are hidden just moving the pointer outside its domain, keyboard > doesn't respond anymore, unless you change to another program or window. > > Brush preset, for example, works fine. This type of popup are close > clicking outside and not just moving pointer outside. > > > * What led up to the situation? > > 1.- Create new image. > 2.- Open, for example, a color selector (Shift + I) > 3.- Select a color and move the cursor outside the selector. It > will be vanished. > 4.- Try to open again the color selector with Shift + I or made > something with keyboard: change to full screen, undo action (ctrl-z)... > 5.- The keyboard will not repond. > 6.- Change to another program and back to Krita (Krita must lost the > focus). > 7.- Try again show color selector (Shift + I). It will work again. > > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > If enter key is pressed just before choosing color in color > selector and with the pointer inside the control (for not hide it), the > keyboard works fine: accept other shourtuts. But if the popup is hide > only moving the pointer outside its domain, the keyboard will be stucked > into Krita. And only come back after loosing the focus into another > program or window. Can you still reproduce the issue with a more recent version of krita, like krita 4.4.1 currently available in testing? If so, can you please report the bug to the upstream development team, as they have more expertise than me? See the following page: https://docs.krita.org/en/untranslatable_pages/reporting_bugs.html Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1
tag 977329 + moreinfo thanks Hi, In data lunedì 14 dicembre 2020 02:12:14 CET, proctor ha scritto: > Package: krita > Version: 1:4.4.1+dfsg-1+b1 > Severity: important > X-Debbugs-Cc: damonswir...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > krita will not open. when i try i get this in dmesg and syslog > > [327378.536890] krita[1273329]: segfault at 0 ip 7efdeea7c190 sp > 7fff99cbf6f8 error 4 in libQt5Gui.so.5.15.1[7efdee9fe000+4c3000] > [327378.536895] Code: e0 10 48 09 f0 48 c1 e0 10 4c 09 e8 49 89 40 04 31 c0 > 66 41 89 40 0c 48 83 c4 18 4c 89 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 <48> > 8b 06 8b 56 08 48 89 07 89 57 08 f0 83 00 01 c3 90 66 66 2e 0f > > krita does work on a similar system but with AMD video card (this machine > has nvidia card) so maybe this is a video driver problem instead? is so let > me know and i will try to file this bug there instead! Unfortunately this dmesg line is not exactly useful, it merely says it crashed "somewhere" within QtGui. Do you still get a crash in an up-to-date testing installation? What where you doing when krita crashed? Which desktop environment or WM are you running? Are you running a Wayland session or an Xorg session? In case you still get a crash: please follow these two pages to install the debug packages for krita, and get a stack trace of the crash: https://wiki.debian.org/HowToGetABacktrace https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#955730: krita does not start under wayland
severity 955730 wishlist retitle 955730 krita does not support wayland forwarded 955730 https://bugs.kde.org/show_bug.cgi?id=429079 thanks Hi, In data sabato 4 aprile 2020 11:22:08 CET, Nicolas Évrard ha scritto: > I have started to use sway as my primary window manager unfortunately > krita does not work with wayland it seems. Other Qt applications seems > to work just find (provided I set the right environment variable ie > QT_QPA_PLATFORM=wayland) krita has never supported Wayland so far. It uses various X technologies (e.g. tablet support, color management) that are not available under Wayland, or nobody worked on them in krita. There is an upstream bug mentioning this: https://bugs.kde.org/show_bug.cgi?id=429079 starting from the upcoming version 4.4.2, you will even get an error message with krita closing itself afterwards in case you are running under Wayland. Please run krita within XWayland until proper Wayland support is implemented in krita. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977988: /usr/bin/spectacle: does not start (libkImageAnnotator.so.0.3.2 not found)
reassign 977988 src:kimageannotator forcemerge 977649 977988 thanks In data mercoledì 23 dicembre 2020 22:26:13 CET, Dominik George ha scritto: > Package: kde-spectacle > Version: 20.12.0-1 > Severity: grave > File: /usr/bin/spectacle > Justification: renders package unusable > > After a recent update, spectacle stoppede working, and errors out on start > with: > > spectacle: error while loading shared libraries: > libkImageAnnotator.so.0.3.2: cannot open shared object file: No such file or > directory > > Maybe it needs a binNMU? No, it needs a fixed SONAME and a fixed Debian package name matching it. See also #977649 (which this bug will be merged to). In the meanwhile, I will disable the kimageannotator-related features, as at least there will be a functional Spectacle. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever
reassign 975387 libgs9 ghostscript/9.53.0~dfsg-1
retitle 975387 wrong size check for display_callback_v2_s struct
severity 975387 serious
forwarded 975387 https://bugs.ghostscript.com/show_bug.cgi?id=703301
tag 975387 + patch
merge 975387 975574
thanks
In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto:
> > On my side, rebuilding libspectre1 solved this on my system.
>
> If a simple rebuild with no source changes fixes the symptoms of a bug,
> that might indicate an unintended ABI break in libgs9, or perhaps a bug
> in the old libgs9 headers (but fixed in the new headers) in code that
> gets inlined into libspectre at compile time.
Both of them are issues in ghostscript anyway.
The rebuild, while "easy as it seems", does not consider an important
fact. From what I see, libgs got new APIs in 9.53.0, and libspectre
does not (optionally) use any of them. This means that a rebuild most
probably would not cause libspectre to require the newer ghostscript,
migrating instantly to testing. Considering that what we have here
smells like a behaviour change, this means making libspectre unusable
for the users of testing, and I do not find this acceptable.
I checked the changes between ghostscript 9.52.1 and 9.53.3, and I found
one thing: gs 9.53.0 reworks a bit the display device stuff, adding a
v3 device_callback struct, and keeping the support for what is now v2:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=eed3bad23510e59278bdaa5f7d0ab01fc1a1c21b;hp=04e937862eaa7e66bb9a87109874112cd354bf6f
display_callback is actually used in libspectre, see spectre-device.c.
Because it relies on DISPLAY_VERSION_MAJOR/DISPLAY_VERSION_MINOR, this
explains why it works after a rebuild, as it will use the
device_callback v3. This also shows that a rebuild is a no-no, as it
will get in the situation I described earlier (i.e. stop working with
ghostscript in testing).
There is actually code in ghostscript to support the old device_callback
(v2, as built in libspectre during the last built), as it can be see in
devices/gdevdsp.c, function display_check_structure:
static int display_check_structure(gx_device_display *ddev)
[...]
else if (ddev->callback->size == sizeof(struct display_callback_v2_s)) {
/* V2 structure with added display_separation callback */
if (ddev->callback->size != sizeof(display_callback))
return_error(gs_error_rangecheck);
[...]
Considering that:
- sizeof(struct display_callback_v2_s) != sizeof(display_callback);
the addition to new stuff to display_callback was the reason for the
new struct in the first place, so of course the two structs do not
have the same size
- the last libspectre build uses display_callback v2, so the check:
ddev->callback->size == sizeof(struct display_callback_v2_s)
is true
then the check "ddev->callback->size != sizeof(display_callback)" will
be always false! Indeed, tried a simple patch to drop this, and evince
shows again PS files without rebuilding libspectre.
I submitted this as ghostscript bug:
https://bugs.ghostscript.com/show_bug.cgi?id=703301
Because of this, I'm reassigning 977754/975387 to ghostscript, merging
also 975574 to them, and setting the proper metadata. I'm also attaching
a copy of the patch I submitted upstream.
Thanks,
--
Pino Toscanodiff --git a/devices/gdevdsp.c b/devices/gdevdsp.c
index 0a66a0278..52087f8d6 100644
--- a/devices/gdevdsp.c
+++ b/devices/gdevdsp.c
@@ -1430,9 +1430,6 @@ static int display_check_structure(gx_device_display *ddev)
}
else if (ddev->callback->size == sizeof(struct display_callback_v2_s)) {
/* V2 structure with added display_separation callback */
-if (ddev->callback->size != sizeof(display_callback))
-return_error(gs_error_rangecheck);
-
if (ddev->callback->version_major != DISPLAY_VERSION_MAJOR_V2)
return_error(gs_error_rangecheck);
signature.asc
Description: This is a digitally signed message part.
Bug#977814: clazy's autopkg tests fail with llvm 11.0.1 rc2
retitle llvm-toolchain-11/1:11.0.1~+rc1-1 breaks behaviour with 1:11.0.0-5 reassign 977814 src:llvm-toolchain-11 llvm-toolchain-11/1:11.0.1~+rc1-1 affects 977814 src:clazy thanks Hi, I did a change in clazy today, landed as 1.8-2, but we still have failures, so I did some more research. We currently have these versions of llvm-toolchain-11 and clazy: - llvm-toolchain-11/testing: 1:11.0.0-5 - llvm-toolchain-11/unstable: 1:11.0.1~+rc2-1 (the same can be said for 1:11.0.1~+rc1-1 too) - clazy/testing: 1.8-1+b1 - clazy/unstable: 1.8-2 clazy executes its own test suite both at build time (with the just built binaries/plugin), and as autopkgtest (with what is installed by the 'clazy' package). We have the following situation: a) clazy/testing a.1) PASS: build against llvm-toolchain-11/testing a.2) PASS: autopkgtest against llvm-toolchain-11/testing a.3) FAIL: autopkgtest against llvm-toolchain-11/unstable b) clazy/unstable b.1) PASS: build against llvm-toolchain-11/unstable b.2) FAIL: autopkgtest against llvm-toolchain-11/testing b.3) PASS: autopkgtest against llvm-toolchain-11/unstable So, to me it looks like we have two problems in llvm-toolchain-11: 1) something in llvm-toolchain-11/unstable breaks compatibility with clazy/testing, and thus it breaks the CI testing for testing migration of llvm-toolchain-11/unstable, case (a.3); in addition, clazy/unstable is now blocked for a similar situation, i.e. case (b.2) 2) in the dependencies of clazy I see: Depends: libc6 (>= 2.14), libclang-cpp11, libllvm11 (>= 1:9~svn298832-1~), libstdc++6 (>= 9), clang-11 that is, libllvm11 has a version as specified by shlibs, while libclang-cpp11 not; this sort of causes the case (b.2), as it allows that combination (as llvm-toolchain-11/testing is enough to satisfy the dependencies of clazy/unstable); a possible workaround is to make sure that all the libraries in llvm-toolchain-11 without symbols cause strict dependencies, as done by the following patch: --- a/debian/rules +++ b/debian/rules @@ -724,7 +724,7 @@ override_dh_makeshlibs: dh_makeshlibs -pliblldb-$(LLVM_VERSION) -V"liblldb-$(LLVM_VERSION) (>= 1:9~svn298832-1~)" dh_makeshlibs -plibllvm$(LLVM_VERSION) -V"libllvm$(LLVM_VERSION) (>= 1:9~svn298832-1~)" dh_makeshlibs -plibomp$(SONAME_OPENMP)-$(LLVM_VERSION) -V"libomp$(SONAME_OPENMP)-$(LLVM_VERSION) (>= 1:9~svn298832-1~)" - dh_makeshlibs --remaining-packages + dh_makeshlibs --remaining-packages -V override_dh_shlibdeps: # Ignore asan libraries. They would trigger dependencies to multiarch libraries In short: I'm reassigning this to llvm-toolchain-11, because there is a behaviour change in the new version, and because its libraries cause too loose dependencies. In the end, the clazy autopkgtest works properly, and it looks like it caught actual issues in llvm-toolchain-11. LLVM maintainers: please investigate and fix, thanks. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977649: kde-spectacle: Spectacle no longer starts after an update to libkimageannotator0
reassign 977649 src:kimageannotator retitle 977649 bumped SONAME without name change affects 977649 kde-spectacle thanks In data venerdì 18 dicembre 2020 06:40:15 CET, Christopher Cormier ha scritto: > Package: kde-spectacle > Version: 20.12.0-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: christophercorm...@protonmail.com > > Dear Maintainer, > > Spectacle is unable to start after the libkimageannotator0 package updated to > 0.4.0-1 > > When attempting to start it, it crashes with "error while loading shared > libraries: libkImageAnnotator.so.0.3.2: cannot open shared object file: No > such file or directory" > > Presumably, it needs to be rebuilt against the newer version of > KImageAnnotator, and the package's dependency on it should be locked to the > specific version it's built with. No, the problem is rather that the new version of kimageannotator bumps the SONAME of the shared library from libkImageAnnotator.so.0.3.2 to libkImageAnnotator.so.0.4.0, which is a big no-no. This also means that kimageannotator sets the SONAME of its shared library to the full version number, basically breaking compatibility even in patch releases; this is _bad_... Also, the Debian packaging of it does not help detecting this kind of situations, as names the library package as if the SONAME was only "0": $ lintian -I -E --pedantic --no-tag-display-limit libkimageannotator0_0.3.2-2_amd64.deb W: libkimageannotator0: package-name-doesnt-match-sonames libkImageAnnotator0.3.2 I: libkimageannotator0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libkImageAnnotator.so.0.3.2 -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#975745: kexi: FTBFS: KReportGroupTracker.h:15: undefined reference to `vtable for KReportGroupTracker'
reassign 975745 libkreport3-4 kreport/3.2.0-2 tag 975745 = bullseye sid pending affects 975745 src:kexi thanks In data mercoledì 25 novembre 2020 20:58:28 CET, Lucas Nussbaum ha scritto: > Source: kexi > Version: 1:3.2.0-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201125 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > /usr/bin/ld: CMakeFiles/kexi_reportplugin.dir/krscriptfunctions.cpp.o: in > > function `KReportGroupTracker::~KReportGroupTracker()': > > /usr/include/KReport3/KReportGroupTracker.h:15: undefined reference to > > `vtable for KReportGroupTracker' > > collect2: error: ld returned 1 exit status Ops, I underestimated the symbols loss in kreport 3.2.0-2; fixing it soon, luckly already fixed upstream. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#974913: RM: libkf5kgeomap -- ROM; no more used; dead upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-qt-kde@lists.debian.org Hi, please remove src:libkf5kgeomap: it is not used anymore by any Qt-based application/library, and it is no more developed/released upstream. Thanks, -- Pino
Bug#936809: Processed: severity of 936809 is serious
severity 936809 important thanks Hi Moritz, In data domenica 25 ottobre 2020 10:45:05 CET, Debian Bug Tracking System ha scritto: > Processing commands for cont...@bugs.debian.org: > > > severity 936809 serious > Bug #936809 [src:kross-interpreters] kross-interpreters: Python2 removal in > sid/bullseye > Severity set to 'serious' from 'normal' This bug was already marked py2keep, as it depends only on src:python2.7, and we want to ship it in the next stable for now (it is not even fixed upstream). Hence, lowering its severity to important. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#971589: clazy's test suite uses the default clang, while the package uses the versioned one
severity 971589 important tag 971589 + needinfo thanks Hi, In data venerdì 2 ottobre 2020 13:12:19 CET, Matthias Klose ha scritto: > Package: src:clazy > Version: 1.7-3 > Severity: serious > Tags: sid bullseye > > This is seen when updating llvm-defaults to point to 11, and then running the > autopkg test. The test tries to run with the updated default clang (11), but > the package is still built using the previous 10 version. The package itself > uses a versioned clang for building, and also gets this dependency encoded in > the package. The plugins are not compatible across versions, so the test > should > always use the version that the package was built for. clazy will run against the clang version it was built with. The two unversioned invocations of clang are done only for diagnostic (one by the run-tests autopkgtest, and one by the upstream script used for testing). Considering the situation described is already what happens, I'm lowering the severity, and requesting for more information. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#972606: plasma-workspace FTFBS: cmake error / some missing dependency
reassign 972606 libkf5kdelibs4support-dev kdelibs4support/5.74.0-1 tag 972606 + pending thanks In data mercoledì 21 ottobre 2020 06:39:03 CEST, Norbert Preining ha scritto: > Hi > > On Wed, 21 Oct 2020, Helmut Grohne wrote: > > | -- Could NOT find KF5KDELibs4Support (found version "5.74.0"), checked > > the following files: > > | > > /usr/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake > > (version 5.74.0) > > | Reason given by package: KF5KDELibs4Support could not be found > > because dependency KF5ItemModels could not be found. > > Ahh, that is the same error I reported recently on IRC, it seems that > the kdelibs4support -dev package needs more Depends. Sandro removed it (again) in 5.74.0-1 :-/ I'll fix it soon. Sandro: when planning to remove dependencies from a -dev file, please rebuild the reverse dependencies to check everything still works (currently kdelibs4support has only 12 users in unstable). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#929742: kaddressbook: Kaddressbook not parsing gmail contacts
reassign 929742 src:libkgapi libkgapi/18.08.3-2 forwarded 929742 https://bugs.kde.org/show_bug.cgi?id=398847 tag 929742 + upstream fixed-upstream thanks In data giovedì 30 maggio 2019 02:18:03 CEST, Arnout Boelens ha scritto: > Package: kaddressbook > Version: 4:18.08.3-3 > Severity: normal > Tags: patch > > My contacts are showing up like this in kaddressbook: > > Contact Name > > This bug has been reported upstream: > > https://bugs.kde.org/show_bug.cgi?id=398847 > > and I was hoping that the patch provided there could be backported to the > version of kaddressbook in Debian. Thanks for the information, and sorry to get back to this bug so late. In the meanwhile, the bug was fixed in Debian by the rebase of the affected component, which was libkgapi. I'm reassigning it to libkgapi, setting proper metadata, and will cose it shortly after. Thanks for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#966588: kpat is spamming .xsession-errors
tag 966588 + moreinfo unreproducible thanks In data venerdì 31 luglio 2020 07:50:09 CEST, Hans-J. Ullrich ha scritto: > Package: kpat > Version: 4:18.04.1-1 > Severity: important > > Dear Maintainer, > > I discovered, that the latest version of kpat (4:20is spamming the file > .xsession-errors in the users home directory, when playing a card game. The > file is growing about 1-2 MB/minute, > > This is not at all card games, especially when playing "Vierzig und acht" > (Forty and eight), this behaviour appears. So the game is nearly unusable. > > The prior version (4:18.04.1-1) is working perfectly. > > Please feel free to ask for more info. Thanks for any help. This was already reported as #941858, and indeed the upstream version 20.04.2 fixes all the issues with logging. Which *exact* version of kpat did you try? Please be precise, "currently in testing" or "4:20" are too generic and change with time. Considering that: - I don't see any output when launching kpat from a terminal when playing "fourthy and eight" or "klondike" - I don't see any change upstream related to logging/output between 4:20.04.2-1 (the version that fixed the logging issues) and 4:20.08.0-1 (the version current in testing) then my initial guess is that you used an old version, or a version installed from somewhere else (maybe self-built). Please update kpat to at least 4:20.04.2-1 from a Debian repository, and try again. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#968438: Should this really be RC?
In data mercoledì 19 agosto 2020 17:54:47 CEST, Drew Parsons ha scritto: > On 2020-08-19 23:42, Lisandro Damián Nicanor Pérez Meyer wrote: > > I have updated okular and, while the bug is important I fail to see it > > as an RC bug. Most of okular's functionality is still there and > > working perfectly. > > > > I am not downgrading the bug severity because Pino did a first review > > and I might be missing something else. > > > Since it was a new release just uploaded to unstable, I marked it RC to > halt it from migrating to testing, at least until you had a chance to > review the problem. It's only the one piece of functionality that's > broken, but it's broken bad. (And for me, it's the functionality that I > like to use okular for). > > I'm happy for Pino to make the judgement to downgrade severity if you > and he thinks the new version is fit to go into testing. I understand the concern related to the bug introduced by the new version. I found an upstream bug that seems the same issue: https://bugs.kde.org/show_bug.cgi?id=425354 feel free to join it, and provide your feedback. Also, note that your point #1 is sort of invalid, as the design of the annotation toolbar was changed upstream. OTOH, all the other functionalities such as - opening and displaying any kind of document - dealing with attachments - dealing with forms - printing - all the various options/settings - showing the existing annotations - even modifying the properties of existing annotations - removing existing annotations work fine, TTBOMK. So yes, we have a bug that prevents creating new annotations, however it is just one of the possible functionalities. Because of this... > I think, and for that reason I've > marked this bug as Severity grave, "makes the package in question > mostly unusable" ... I disagree with this statement: the package in question is _not_ mostly unusable. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#964137: clazy: autopkgtests failure on 32bit
severity 964137 important tag 964137 - patch thanks In data giovedì 2 luglio 2020 13:12:54 CEST, Gianfranco Costamagna ha scritto: > Source: clazy > Version: 1.7-2 > severity: serious There are no 32bit architectures for autopkgtest in Debian, so this is definitely *not* a RC bug. > Hello, the following patch should be sufficient to make it work also in > autopkgtests. The patch is basically applying the workaround used in debian/rules also for autopkgtest; weird, flex, but I'd rather use the upstream patch that does the same. I will backport it after the current clazy 1.7 migrates to testing, since there is no reason it should be prevented to migrate. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#964126: krita: Please switch from sip4 to sip5
In data giovedì 2 luglio 2020 12:30:46 CEST, Dmitry Shachnev ha scritto:
> Source: krita
> Version: 1:4.3.0+dfsg-1
> Severity: important
> Usertags: sip5
>
> Dear Maintainer,
>
> Recently I have updated pyqt5 and related packages to use sip5 instead of
> sip4 for build. This is in experimental for now, but I want to upload it
> to unstable in a month or two.
Unfortunately it seems krita will require changes to use sip5.
You can see how krita checks for, and uses SIP looking at the following
files:
cmake/modules/FindPyQt5.cmake
cmake/modules/FindPyQt5.py
cmake/modules/FindSIP.cmake
cmake/modules/FindSIP.py
cmake/modules/SIPMacros.cmake
plugins/extensions/pykrita/sip/*
I found this upstream bug report:
https://bugs.kde.org/show_bug.cgi?id=415743
which links to some Arch Linux patch:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/krita-pyqt5-sip5.patch?h=packages/krita
which is:
diff --git a/cmake/modules/FindPyQt5.py b/cmake/modules/FindPyQt5.py
index 5849f40868..a42ba6c624 100644
--- a/cmake/modules/FindPyQt5.py
+++ b/cmake/modules/FindPyQt5.py
@@ -3,7 +3,7 @@
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
import PyQt5.Qt
-import sys
+import sys, site
import os.path
print("pyqt_version:%06.0x" % PyQt5.Qt.PYQT_VERSION)
@@ -30,7 +30,7 @@ except ValueError:
pass
# FIXME This next line is just a little bit too crude.
-pyqt_sip_dir = os.path.join(sys.prefix, "share", "sip", "PyQt5")
+pyqt_sip_dir = os.path.join(site.getsitepackages()[0], "PyQt5", "bindings")
print("pyqt_sip_dir:%s" % pyqt_sip_dir)
print("pyqt_sip_flags:%s" % PyQt5.Qt.PYQT_CONFIGURATION["sip_flags"])
It looks to me that patch addresses only the "build with PyQt5 compiled
with sip5" issue, and it still relies on sip4 to build (see the
aforementioned FindSIP.* files above). If so, this means one possibility
can be to switch to the PyQt5-build-with-sip5 for this bug, and then
later deal with sip5 at all.
In any case, I don't have much experience with sip & PyQt. If you have
some time to investigate it, and possibly send a merge request upstream
(see https://invent.kde.org/graphics/krita), that'd be awesome.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#849012: /usr/bin/spectacle: kde-spectacle: no longer works under VNC (ksnapshot did)
In data mercoledì 1 luglio 2020 16:23:49 CEST, Thorsten Glaser ha scritto: > >Anyhow: please report this at https://bugs.kde.org, "spectacle" product, > >so it can be properly tracker and acted upon by spectacle developers. > > Could you please just forward it, as DevRef says… I don’t think > users are happy about having to create accounts on hundreds of > upstream bugtrackers. Considering that: - this is definitely not your first bug related to KDE software - you are a technical person I'm pretty sure you can be helpful and report this bug yourself to upstream, so to ease a bit the work of an already well overloaded packaging team. Right? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#849012: /usr/bin/spectacle: kde-spectacle: no longer works under VNC (ksnapshot did)
In data mercoledì 1 luglio 2020 14:10:36 CEST, Thorsten Glaser ha scritto: > $ spectacle > > qt.qpa.xcb: XKeyboard extension not present on the X server This seems pretty clear to me. Have you tried to fix this? > QDBusConnection: name 'org.kde.kglobalaccel' had owner '' but we thought it > was ':1.99' > kf5.kservice.services: The desktop entry file > "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec > line > kf5.kservice.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop" > The X11 connection broke: Unsupported extension used (code 2) > XIO: fatal IO error 17 (File exists) on X server ":2" > after 221 requests (213 known processed) with 0 events remaining. Anyhow: please report this at https://bugs.kde.org, "spectacle" product, so it can be properly tracker and acted upon by spectacle developers. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#962780: kaccounts-integration: [ABI break] 20.04 and 20.04.1 have renamed symbols and needs an upstream ABI bump
In data giovedì 18 giugno 2020 12:51:59 CEST, Nicholas D Steeves ha scritto: > It just occurred to me that I thought we were waiting for upstream to > make a new release (now that would be ≥20.04.3), because from the > little I've learned about ABI updates "libkaccounts1" will also need > to be updated. Is that supposition correct? I'm not sure I understand what you are saying. For sure we will need to bump the SONAME of the libkaccounts library, because it is a public library and it had an ABI break. Ideally it should be done upstream, so we don't do it twice... assuming they answer. If upstream does not answer or does not care, we must apply our system, i.e. the ABI manager. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#962348: kig: boost1.67 is being removed from testing
In data lunedì 8 giugno 2020 14:19:39 CEST, Dimitri John Ledkov ha scritto: > You are not being reasonable either. I am being reasonable as your unreasonable attitude. > Boost1.71 transition was prepared since February. > > kig, like majority of packages, succeeded to build in all test rebuilds & > passed autopkgtest if any. Packages that successfully binNMU are not > notified about upcoming transitions. > Packages that ftbfs have patches developed and bugs opened. Again, I know how transitions works, no need for lecturing things that I've done for more than a decade. > kig gets binNMUed successfully. That is the unexpected part: the new boost ships cmake config files that make the cmake search for the "python" component of the Boost cmake package refer to the shipped boost-python, which is the Python 3 one. boost 1.67.0 does not have cmake config files, and thus the FindBoost.cmake provided by cmake detects the Python2-based boost-python as "python" component. This is why... > Then two days later you upload a uncoordinated downgrade to reintroduce > dependency on old python2 and old boost, in full knowledge that you are > hindering other people's work. ... I uploaded kig to switch it back to Python 2, because the automatic switch was not supposed to happen. More than "hindering other people's work", I restored a broken functionality that was switched because of the new boost. > Without opening any bug reports. I explained the reason in the changelog message, please do read it. > And during > that time tracker.d.o should have had a message that kig should not be > uploaded as it is part of an ongoing transition. There was no message in pts/tracker back then, and still there is nothing as of right now. Also, boost transitions works slightly different than other library transitions: the old and the new libraries are provided by different sources and they are co-installable (not their -dev, though). It's enough that the new boost is available in testing, so the switch of boost-default is not a blocker transition but a a gradual rebuild/fix that can generally happen side by side with other changes. This is similar to what happens when the default Python version is switched: both the old and the new are co-installable, and already in testing. > I notice regression in transition counts, and open a bug report to prevent > regressions entering testing and making it harder to remove boost1.67 & > python2. I explained already that the boost rebuild already created a buggy functionality, and because of the transition it already migrated to testing. > You then downgrade the bug report to force broken stuff into testing and > anchor it there. Sigh. > >From my point of view, [...] ... you ought to provide the information as they were asked, and leave the judgement the maintainer, especially if you clearly have NO IDEA about the sitation of kig. Now, I need the current version in unstable to migrate to testing, because as I said the boost binNMU created issues (and I got a private email by an user reporting that). In a couple of days I will check this again, and decide what to do. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#962348: kig: boost1.67 is being removed from testing
In data lunedì 8 giugno 2020 12:49:19 CEST, Dimitri John Ledkov ha scritto: > On Mon, 08 Jun 2020 08:38:44 +0200 Pino Toscano wrote: > > In data lunedì 8 giugno 2020 08:06:42 CEST, Dimitri John Ledkov ha scritto: > > > > I'm pretty sure boost 1.67.0 can stay 3 months more around, especially > > > > since I see it is still not the only package using the old boost. > > > > > > > > > > No, it cannot as it entangles too many other transitions. > > > > Which ones exactly, other than the ICU one? (And the ICU one could be > > easily done by rebuilding boost1.67.0 too) > > > > No, boost1.67 will not be rebuilt against new ICU as that will break > upgrades from stable. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962040 from > release team & the discussion on the boost1.71 transition bug. OK, and this is useful information. It would have been nicer to have it at the beginning instead of poking after a useless initial bug report. > > > boost1.67 will be shortly removed from both testing and unstable. > > > > Again, please open bugs about this. Also, where is this info coming > > from? I don't see anything in > > https://bugs.debian.org/961995 (boost-defaults transitions) > > https://bugs.debian.org/ftp.debian.org (ftp-masters bugs) > > > > boost1.67 is RC buggy in both testing & unstable. I'm not sure what > else i need to open? And those bugs already blocked by kig's bug > RE:python2 removal. Like, a classic RM bug for ftp-masters? How else do you expect to remove a package from Debian? > > > Please stop intentionally delaying completion of multiple archive > > > transitions. > > > > This is definitely way too harsh and untrue, especially when you are > > providing literally no references to blocked things or schedules for > > removals. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936794 was filed on > Date: Fri, 30 Aug 2019 07:22:06 + > > kig is a leaf package, itself not blocked by anything to migrate to > python3 or at least stop (temporarily) using python2. I don't see what Python 2 has anything to do here, and mixing up issues. I also explained in previous email in this bug report that the current stable version does not have all the changes needed for full Python 3 support, so your "not blocked by anything to migrate to python3" statement is false. > leaf packages like kig are overdue to drop python2 support. Your patches are welcome! > > > Would you like me to upload NMU to delayed/2 that disable python bindings? > > > > Please not, and please rather answer the questions I asked. > > kig had 9 months notice that it is blocking removal of python2 from unstable. Again, Python 2 is unrelated to this bug. > you can see progress of boost transition at > https://release.debian.org/transitions/html/boost1.71.html Yes, I know how transitions work, no need to lecture me about them. And TBH this transition has been badly handled, with no prior notifications to involved packages about them (like test rebuilds with bugs filed in advance about the lack of compatibility with boost 1.71). Also, with all the respect possible: please do not play with severity, especially when you have lacking to provide useful information for two emails so far. I'm monitoring these bugs, I can make a maintainer decision/choice once I have enough information, which finally you decided to provide _just now_. IOW, if you want maintainers' cooperation, please learn to provide information _in advance_, rather than just useless "everything is broken! remove! remove!" panic bug reports. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#962348: kig: boost1.67 is being removed from testing
In data lunedì 8 giugno 2020 08:06:42 CEST, Dimitri John Ledkov ha scritto: > > I'm pretty sure boost 1.67.0 can stay 3 months more around, especially > > since I see it is still not the only package using the old boost. > > > > No, it cannot as it entangles too many other transitions. Which ones exactly, other than the ICU one? (And the ICU one could be easily done by rebuilding boost1.67.0 too) > boost1.67 will be shortly removed from both testing and unstable. Again, please open bugs about this. Also, where is this info coming from? I don't see anything in https://bugs.debian.org/961995 (boost-defaults transitions) https://bugs.debian.org/ftp.debian.org (ftp-masters bugs) > Since the package is broken in both testing and unstable, in different > ways, please request its removal. The package in unstable is *not* broken. > Please stop intentionally delaying completion of multiple archive > transitions. This is definitely way too harsh and untrue, especially when you are providing literally no references to blocked things or schedules for removals. > Would you like me to upload NMU to delayed/2 that disable python bindings? Please not, and please rather answer the questions I asked. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#962348: kig: boost1.67 is being removed from testing
severity 962348 important thanks In data sabato 6 giugno 2020 16:26:34 CEST, Dimitri John Ledkov ha scritto: > Package: kig > Version: 4:20.04.1-1 > Severity: serious > > Hi, > > boost1.67 is being removed from testing and is transitioning to boost1.71. Yes, I know about the boost transition to 1.71.0, that the new boost does not provide Python 2 support, and that it is expected to not ship boost 1.67.0 in bullseye. > kig has just now switched from boost1.71 to boost1.67. Quoting what I wrote in the changelog entry of 4:20.04.1-1: * Temporarily switch from libboost-python-dev to libboost-python1.67-dev, as boost 1.67 is the latest version of boost in Debian that supports Python 2: kig < 20.08 is not ready for Python 3, so stil with Python 2 for now. As the version number hints, the new stable version will be released in (late) August; the development version already switched to Python 3 only, and it contains few Python 3 fixes. The current version does *not* work properly with Python 3, that is why I had to rollback to boost 1.67.0 (since boost 1.71.0 has no Python 2 bindings, sigh). > Thus I am opening this bug report to prevent kig from migrating. First of all, please do not abuse severities for things that are not critical yet. There is a catch here: the version in testing is the binNMU for the boost 1.71.0 rebuild, and apparently (to my surprise) it was detected and switched to Python 3. This is buggy though, so not letting this version migrate means having a buggy version in testing. > boost1.71 does not offer python2 bindings, as python2 is being removed to. Sure, I know this too. > I understand that kig is using boost-python2. Either please disable > python bindings usage at build time, or try to port to boost-python3? As I said, in ~3 months there will be a new upstream release fully supporting Python 3, and I will switch it when it is released. In the meanwhile, please: a) open a RM bug for boost 1.67.0, so it is clear that it will be removed b) make this bug block the RM bug I'm pretty sure boost 1.67.0 can stay 3 months more around, especially since I see it is still not the only package using the old boost. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: KDE/Plasma update for Debian
Hi Norbert, sorry for the late answer to this email: it was sent to the maintainer address, which gets all the emails of uploads, bugs, etc. I noticed it, however later it got "buried" in the traffic of the list, and thus it went out of my attention. The list for the general discussion is pkg-kde-talk, see also https://qt-kde-team.pages.debian.net/qtkde.html Possibly not the easier place to find, I'm open to suggestions on how to improve this. I'm answering how seeing users reporting your repository to our user support list, and that reminded me of your email. In data mercoledì 1 aprile 2020 02:37:59 CEST, Norbert Preining ha scritto: > you might have seen my blog post, but anyway, I have updated most kf* > and plasma packages to the latest versions, see > https://build.opensuse.org/project/show/home:npreining:debian-plasma > Source and binaries for i586/x86_64 for sid/testing are available there > (sid is currently broken because xorg-server is borken, so binaries can > be obtained from https://www.preining.info/debian/. Plasma 5.18 requires KF 5.64 (or so) which we don't have yet in Debian. Updating to a newer KF takes effort as well, and I believe Sandro Knauss started to work on this (at least I see some commits done by Sandro, I did not check all the repositories and all the commits). Ideally I'd ask for some kind of coordination with us, rather than a "this is the work, take it" approach, as there is lots of things to do, and review a monolithic approach IME takes more than the various bits of it. If you are interested, please contact Sandro about this. I also read in your blog about what somebody would have told you: I'm think of surprised to read that, since I don't see anything in any debian-kde-related list about this, nor as answers in your blogs. I hope that the lack of timely answer to your email was not seen as an implict "go away" reaction you describe, that would be a pity (and definitely not intended, since it simply slipped to me, as I said earlier). Again, what you wrote is not what I would have said, and I'm sure that the majority of other people (Lisandro, Sandro, Dmitry, Aurelien, Scarlett, etc) wouldn't have said that either way. Let me say it once more: - I'm again sorry for the late answer, because of life/other Debian work/etc, which I'm sure you can understand - I see no reason to reject help outright - if you are still interested, please let's talk in the -talk list about a way to get contribution to our repositories (which are always public and open to other people's contributions, like it happened also for the Plasma 5.17 upgrade) Take care, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: qtsystems-opensource-src_5.0~git20181230.e3332ee3-1_amd64.changes ACCEPTED into unstable, unstable
Hi Mike, In data martedì 21 aprile 2020 11:26:15 CEST, Mike Gabriel ha scritto: > Thanks for updating qtsystems. Did the unit tests succeed with > --parallel (which happens when calling dh_auto_test directly). It worked fine on my machine, and apparently on every buildd... but amd64 (!). Hence I just uploaded disabling the parallel execution of the test suite. Also as additional change I doubled the timeout (even if so far was fine even for slow architectures). > My reason for having run-tests.sh was to run unit tests in > --no-parallel mode. The limitation of dbus-test-runner is that you > can't pass cmdline option to the script to run, so I wrapped the -j1 > (or rather --no-parallel for dh_auto_test). Grr to dbus-test-runner... I ended up restoring the run-tests.sh script, however greatly simplified. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: qtsystems-opensource-src_5.0~git20181230.e3332ee3-1_amd64.changes ACCEPTED into unstable, unstable
Hi Mike, In data martedì 21 aprile 2020 00:14:03 CEST, Mike Gabriel ha scritto: > > One question: what is debian/copyright.in for? It looks like some > > unused leftover template. > > I uses this script [1] to generate my copyright.in template file. And > I do this when packaging a project initially and also for every > upstream release (or Git snapshot). > > When doing it for the first time, this copyright.in file is my > starting point for drafting d/copyright. > > With the first upload, I leave d/copyright.in in the package (or > rather: in the Git repo). > > When I do a new upstream release of the package, I re-run the script > [1] and get a "git diff" for d/copyright.in showing me all > auto-detectable changes between last upstream version and this > upstream version. > > I then take this auto-detected diff and weave it manually into > debian/copyright itself. This ought to be documented in the debian/README.source file then, otherwise it is hard to miss this. Possibly add a note about it in the top-level Comment section of the dep5 file, so people opening the copyright file have a chance to note that. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: qtsystems-opensource-src_5.0~git20181230.e3332ee3-1_amd64.changes ACCEPTED into unstable, unstable
Hi Mike, In data lunedì 20 aprile 2020 14:24:36 CEST, Mike Gabriel ha scritto: > > Can qtsystem be built also without Mir with no loss of binary packages? > > If so, I'd do that, and enable the support for Mir when it is available > > in unstable. What do you think? > > Yeah, that should work. Will prepare an upload. Great, thanks for the -2 upload, which indeed started to build fine (at least somewhere)! I see that most of the issues at the moment are symbols issues; I will handle that in the following days, waiting for the builds on almost all the architectures. In the meanwhile, I opened a -3 changelog in git, and started adding few bits; feel free to add your changes. One question: what is debian/copyright.in for? It looks like some unused leftover template. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: qtsystems-opensource-src_5.0~git20181230.e3332ee3-1_amd64.changes ACCEPTED into unstable, unstable
Hi Mike, In data lunedì 20 aprile 2020 12:10:11 CEST, Mike Gabriel ha scritto: > thanks for accepting qtsystems to unstable. However, you are aware > that it requires the Mir Display Server (mir) as a build requirement? > Mir is still in NEW afaict. (please do not forget to push missing commits and tags to the packaging repository ;-) ) Can qtsystem be built also without Mir with no loss of binary packages? If so, I'd do that, and enable the support for Mir when it is available in unstable. What do you think? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#958185: meta-kde: Don't depend on cantor, RC buggy and prevents hdf5 migration
In data domenica 19 aprile 2020 15:27:23 CEST, Sebastiaan Couwenberg ha scritto: > On 4/19/20 3:16 PM, Pino Toscano wrote: > >> Please apply the attached patch to not depend on cantor, it's RC buggy and > >> prevents the hdf5 transition from completing, see: > >> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954654#56 > > > > Sorry, but I do not agree with this fix. > > > > First of all, there are no bug reports against cantor, so knowing > > about it would be a nice thing. Second, it seems like the actual > > problem is scilab that FTBFS on amd64 (#955694). Cantor is definitely > > *not* RC buggy. > > > > So please contact the scilab maintainers about this, and let them fix > > it if possible. If not, then we can (temporarly?) drop the scilab > > backend from cantor, with no need to drop it from the kdeedu > > metapackage. > > The problem is that kdeedu Depends on cantor which Depends on scilab. To > quote the linked post in the hdf5 transition bugreport: > > " > Basically we could remove cdo, ruby-hdfeos5 (or wait for it to be a > candidate but I would remove it now to finish this) and scilab. > Unfortunately after checking with dak, I found that tasksel depends on > meta-kde, which depends on cantor, which depends on scilab, which means > that scilab is going to need a fix for #955694 in order for this > transition to finish. > " Yes, I did read that, and it even says what I wrote, i.e. that scilab requires a FTBFS fix. Before adding more work on our (qt-kde) side, can you please ping again the scilab maintainers (Julien Puydt in particular), and wait a couple of days for an answer? > Since a fix for scilab is not forthcoming, we need a different solution > to allow hdf5 to migrate to testing. The next best thing is for meta-kde > to not Depends on cantor which won't make it nor its dependencies like > scilab a key package. No, the next best thing is what I wrote earlier, i.e. drop the scilab backend from cantor. I don't see a reason to drop cantor from testing altogether just because one part of it might not be usable because of other packages. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#958185: meta-kde: Don't depend on cantor, RC buggy and prevents hdf5 migration
tag 958185 - patch thanks In data domenica 19 aprile 2020 15:01:34 CEST, Bas Couwenberg ha scritto: > Source: meta-kde > Version: 5:104 > Severity: important > Tags: patch > Control: block 954654 by -1 > > Dear Maintainer, > > Please apply the attached patch to not depend on cantor, it's RC buggy and > prevents the hdf5 transition from completing, see: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954654#56 Sorry, but I do not agree with this fix. First of all, there are no bug reports against cantor, so knowing about it would be a nice thing. Second, it seems like the actual problem is scilab that FTBFS on amd64 (#955694). Cantor is definitely *not* RC buggy. So please contact the scilab maintainers about this, and let them fix it if possible. If not, then we can (temporarly?) drop the scilab backend from cantor, with no need to drop it from the kdeedu metapackage. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault
In data martedì 25 febbraio 2020 22:05:21 CET, Paul Gevers ha scritto: > On 25-02-2020 20:41, Pino Toscano wrote: > > The test is not flaky. > > I can see why you say that now, but from my PoV (the release team) it is. As I wrote, the conditions for this test to fail in the way it was reported in bug are not definitely how a release is: | Putting all the pieces together: why the autopkgtest can fail? | The answer is simple: the version of src:llvm-defaults in the | environment of the test is different than the one used to build clazy. This is either: - temporary, like what happens with the src:llvm-defaults bump to a newer LLVM version with rebuilds related to that (including clazy) - a big problem for the Debian release altogether, because it would mean that src:llvm-defaults is stuck in unstable for any reason, while things built with it migrate happily to testing > > Although, as I said, the issue "fixed itself" until the next > > src:llvm-defaults switch, this is slightly less problematic. > > llvm-defaults and gcc-10 were blocked for some days by the clazy > regression on arm64. Can you explain why gcc-10 wasn't blocked by this > issue on amd64? Also, the failures on arm64 started before the > llvm-defaults upload [1] blocking glibc for some days. Do you also > understand that? > > [1] > https://ci.debian.net/data/autopkgtest/testing/arm64/c/clazy/4223149/log.gz Let's check this: [FAIL] old-style-connect (Failed to build test. Check old-style-connect/namespaces.cpp.out for details) --- Contents of old-style-connect/namespaces.cpp.out: In file included from old-style-connect/namespaces.cpp:2: old-style-connect/namespaces.h:22:9: warning: Old Style Connect [-Wclazy-old-style-connect] connect(obj, SIGNAL(signal1()), obj1, SIGNAL(signal1())); ^~~ ::Bar::signal1 ::Bar::signal1 old-style-connect/namespaces.cpp:32:5: warning: Old Style Connect [-Wclazy-old-style-connect] QObject::connect(o1, SIGNAL(signal1()), o1, SLOT(slot1())); // Warning ^~ ~ ::signal1::slot1 old-style-connect/namespaces.cpp:33:5: warning: Old Style Connect [-Wclazy-old-style-connect] QObject::connect(o1, SIGNAL(signal1()), o2, SLOT(separateNSSlot())); // Warning ^~ ~~ ::signal1::separateNSSlot old-style-connect/namespaces.cpp:42:5: warning: Old Style Connect [-Wclazy-old-style-connect] QObject::connect(o1, SIGNAL(signal1()), o1, SLOT(slot1())); // Warning ^~ ~ ::MyObj::signal1 ::MyObj::slot1 old-style-connect/namespaces.cpp:43:5: warning: Old Style Connect [-Wclazy-old-style-connect] QObject::connect(o1, SIGNAL(signal1()), o2, SLOT(separateNSSlot())); // Warning ^~ ~~ ::MyObj::signal1 ::MyObj2::separateNSSlot 5 warnings generated. /usr/bin/ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) This looks to me like bug #951086 of src:gcc-10, which was indeed a legit bug in gcc-10. Also, this is a totally different case than the build log posted when opening this bug. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: kde-l10n breaks/replaces for dh --with kf5
Hi,
please use the team ML, i.e. pkg-kde-t...@lists.alioth.debian.org for
these discussions.
In data domenica 23 febbraio 2020 21:53:51 CET, Aurélien COUDERC ha scritto:
> Dear team,
>
> disclaimer: I’m no dh or even makefile expert.
>
> I wanted to convert a package (juk) from dhmk to dh --with kf5, but I don’t
> understand how to / if I can keep the automated breaks / replaces injection
> that dhmk was doing with l10n-packages.mk and l10npkgs_firstversion_ok.
>
> I tried the following debian/rules to no avail :
>
> l10npkgs_firstversion_ok := 4:17.08.3-4~
>
> include /usr/share/pkg-kde-tools/qt-kde-team/2/l10n-packages.mk
>
> %:
> dh $@ --with kf5
>
>
> dpkg-gencontrol complains that:
> substitution variable ${kde-l10n:all} used, but is not defined
The kf5 dh addon has no knowledge of the kde-l10n breaks; however you
can integrate the makefile snippets with it. See for example
src:plasma-desktop, src:kstars.
HTH,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault
s is slightly less problematic. In the meanwhile: because of what I said above, I'm demoting the severity of this bug to important. Also, Paul, please re-enable the autopkgtest of clazy on ci.debian.net, as they will pass now. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Fwd: Fixing the broken activities KCM
In data giovedì 30 gennaio 2020 00:59:38 CET, Aurélien COUDERC ha scritto: > I’ve prepared an updated plasma-desktop with the cherrypick below. > Should I go ahead and upload to experimental or do you have other plans for > plasma-desktop ? If you think the issue is bad enough to justify an upload just for it (IMHO not so much -- YMMV), then go for it. In case there are users of Plasma 5.17.5 from experimental that complain hard enough about it, then go for it. Otherwise it will be part of the next upload, be it for some other important thing to fix in src:plasma-desktop 5.17.5, or when uploaded to unstable. Bottom line: use your best judgement. (PS: no need to CC me explicitly) -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#900710: a man page should be provided for kdeconnect-cli
Hi Nicholas, In data giovedì 23 gennaio 2020 14:46:04 CET, Nicholas D Steeves ha scritto: > > Date: Mon, 12 Nov 2018 08:41:46 + > > From: Pino Toscano > > To: 900710-cl...@bugs.debian.org > > Subject: Bug#900710: fixed in kdeconnect 1.3.3-1 > > > > Source: kdeconnect > > Source-Version: 1.3.3-1 > > > [snip] > > kdeconnect (1.3.3-1) unstable; urgency=medium > [snip] > >* Drop the Debian-provided kdeconnect-cli man page: very outdated, not > > touched in the last 4 years, and thus not useful. (Closes: #900710) > > This bug was closed in error at a time I was swamped with work, and I > didn't notice until now. No, this bug was definitely not closed in error. The original bug was about the man page being very outdated (and it was), so the removal was one possible way to fix this issue, in particular the one I chose. Because of this, I disagree with the reopening of this old bug and turning it into something else than it was originally. Opening a *new* wishlist bug "please provide a man page" would had been a better idea. > Please consult Policy §12.1 for why it was > wrong to close it. tldr; > > If no manual page is available, this is considered as a bug and > should be reported to the Debian Bug Tracking System (the > maintainer of the package is allowed to write this bug report > themselves, if they so desire). Do not close the bug report until > a proper man page is available. It is a *should*, so there is no requirement on us to either ship a man page, or even do the work to provide one as part of the Debian packaging. In general, we (Debian Qt/KDE) ought to *not* provide man pages ourselves, as it has many drawbacks: - the man page must be maintained by the team and, considering the huge amount of work the team already has, this means that a man page is rarely (if ever) updated after its first introduction; and this very reply of yours show this very well: if the person that adds a man page is busy or does not contribute to the team anymore, then nobody else will work on it - the man page is available only to Debian users - the man page is only in English - the Debian-provided man page will silently overwrite an upstream provided one (!); this actually happened in two cases that I spotted when updating KDE Applications to 17.08 a couple of years ago - unless the executable has any option other than the usual --help/--version/--author, a man page does not add any value to the package, and becomes just a bureaucratic formality than a real need So our guideline for this ought to be: - do not provide Debian-specific man page - *iff* (if and only if) a man page is requested for a real reason [1], forward the request upstream to provide a man page, if they desire; optionally submitting one in DocBook format (in case of KDE projects) - if there is no request it means there is no demand for it [1] for "real reason" I mean that the request is justified because of the executable, and not requested like "lintian complains" or "Policy says" Having a man page shipped by upstream has multiple advantages: - the man page is available to all the users, not just Debian ones (and thus more people can read it and spot issues, provide enhancements, etc) - the man page is available also in other languages - upstream (the developers directly, or the KDE documentation team) will keep the man page up-to-date - there is no additional work required on the Debian side, nor additional files in our debian/ directories Hope this clarifies the situation. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#949318: systemsettings should Replace (or Conflict) kde-config-systemd << 5.17
In data domenica 19 gennaio 2020 20:30:18 CET, Antonio Russo ha scritto: > Package: systemsettings > Version: 4:5.17.5-1 > Severity: normal > > During an upgrade from testing (4:5.14.5.1-5+b1) to experimental, > systemsettings > tries to overwrite files in kde-config-systemd. The conflict is due to the following file: /usr/share/kservices5/settings-system-administration.desktop (hint: please mention all the conflicting files when reporting this kind of bugs, or at least paste an English output of apt/aptitude/etc) Basically System Settings "adopted" the System Administration category that so far was introduced only with kde-config-systemd. The fix will be removing that file in kde-config-systemd, and adding proper breaks/replaces in systemsettings with the right version of kde-config-systemd that removes the file. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#949317: plasma-workspace should Replace (or Conflict) plasma-desktop and plasma-desktop-data << 5.17
tag 949317 + pending thanks Hi, In data domenica 19 gennaio 2020 20:26:55 CET, Antonio Russo ha scritto: > Package: plasma-workspace > Version: 4:5.17.5-1 > Severity: normal > > During an upgrade from testing (4:5.14.5.1-5+b1) to experimental, > plasma-workspace > tries to overwrite files in plasma-desktop and plasma-desktop data. Thanks, fixed in the packaging repository, and it will be part of the next upload. PS: considering there will be more issues like this, please report them to the debian-kde mailing list for now. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: 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#944710: RM: libindi -- ROM; replaced by src:indi
Package: ftp.debian.org Severity: normal Hi, please remove src:libindi, as it was recently renamed to src:indi (finally aligning to the upstream naming again). Thanks, -- Pino
Bug#941255: kate: Please enable -DENABLE_LSPCLIENT=ON on Kate build
Hi, In data venerdì 27 settembre 2019 11:00:36 CET, David Goodenough ha scritto: > Package: kate > Version: 4:19.08.1-1 > Severity: normal > > Dear Maintainer, > > LSP support in Kate is not enabled by default but needs to be enabled manually > using > > -DENABLE_LSPCLIENT=ON yes, I noticed that when working on kate 19.08. The situation I see of that plugin is: 1) it was added in this series, 19.08, and thus it is faily new 2) it is off by default 3) I see lots of updates on that plugin in the development branch of kate, i.e. the future 19.12 4) there are no backports to the 19.08.x series of changes/fixes/etc to that plugin Hence, for now I will not enable the LSP plugin in kate 19.08.x, and re-evaluate the situation for kate 19.12.x. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#941147: Please stop removing affects of #941147
In data mercoledì 6 novembre 2019 06:00:51 CET, Helmut Grohne ha scritto: > Control: affects 941147 + src:kde-cli-tools src:powerdevil src:systemsettings > src:apper src:kget src:kdeplasma-addons src:khotkeys src:plasma-desktop TL;DR: they are not needed anymore. > Hi Pino, > > Please stop removing the affected bugs of #941147 without giving a > reason. I am part of the team working on these packages, and thus the changes I do are generally because of a precise reason, not because I "vandalize" bugs. > The submission explains why they are needed and QA tooling > relies on these affects to avoid duplicate work. All the above packages build-depend on plasma-workspace-dev, which used to depend on plasma-workspace, which lead to an indirect dependency on breeze-cursor-theme. However, since the upload plasma-workspace 5.14.5.1-3, this is no more the case, and we can check the status of the aforementioned packages: http://crossqa.debian.net/src/kde-cli-tools -- OK http://crossqa.debian.net/src/powerdevil -- OK http://crossqa.debian.net/src/systemsettings -- OK http://crossqa.debian.net/src/apper -- OK http://crossqa.debian.net/src/kget -- OK http://crossqa.debian.net/src/kdeplasma-addons can be built now, fails because of #887308 http://crossqa.debian.net/src/khotkeys -- OK http://crossqa.debian.net/src/plasma-desktop still blocked by other issues I could had even closed bug #941147 altogether, since it is not needed anymore (at least for now), although I decided to leave it open "for the future". > Dear ow...@bugs.debian.org, > > I am hereby reporting that Pino Toscano vanadlizes > metadata of bug #941147 and ask you to take note of that behaviour in > case it is repeated elsewhere. It is really sad to see that, instead of checking yourself whether the situation of the bug was changed, you assumed that the metadata you set was perfect, and and set it back with no additional doubt on your side. Even more, calling other Debian developers "vandals" because of this, with "he touched my bug like I do not want" as the _sole_ reason. Hence: dead ow...@bugs.debian.org, please take note of the behaviour of Helmut Grohne , as it is _against_ any cooperation value of this community. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#921909: QCachegrind is not being packaged in KCachegrind 17
tag 921909 + wontfix thanks In data domenica 10 febbraio 2019 02:44:14 CET, nandhp ha scritto: > Dear Maintainer, > > QCachegrind is KCachegrind built without a KDE dependency. qcachegrind is declared "example code" in the upstream sources: https://cgit.kde.org/kcachegrind.git/tree/qcachegrind/README Hence, it is not meant to be installed, especially as it is not installed on purpose. > Please resume building the QCachegrind binary package. It is not going to happen. Just use kcachegrind, which works fine, and it is supported. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Qt 5.12 LTS in Buster
In data sabato 26 gennaio 2019 19:00:11 CET, Simon Quigley ha scritto: > Hello, > > On 1/26/19 11:56 AM, Matthias Klumpp wrote: > > I wonder whether it would have been possible to ask the release team > > for a freeze exception in advance for this release of Qt, as running > > the LTS on a stable release would ease future maintenance in Debian > > stable. > > Now though it's likely too late for that, as a new Qt could push back > > the schedule in case existing software breaks due to it. > > Also wearing my Ubuntu hat, we're going to get 5.12.1 in Disco (19.04) > as soon as it comes out; I brought it up between Debian Qt members > yesterday because I was also thinking about doing it in Experimental. If > that works out and the release team ACKs, I personally wouldn't be > opposed to it. > > I'll let other Debian Qt members give their opinion on the matter before > we consider talking to the release team. :) Definitely not an option at this point. As usual, a new minor Qt release introduces minor source incompatibilities (usually removing includes from public headers, breaking the build of sources). Also, there are also behaviour changes, e.g. in QtWayland and don't know where else. I remember seeing patches for both the situations in KDE's phabricator, and that would anyway cover only the issues in software by KDE (and not in any other Qt software). Considering that the last couple of 5.x -> 5.x+1 transitions of Qt caused a number of FTBFS & other issues, completely not planned in advanced (e.g. by reporting bugs to packages asking to make changes for compatibility with the upcoming Qt), doing this work right now at slightly more than 1 month before the freeze is simply not a reasonable choice. Also, having an LTS in stable would make sense only if, other than what I explained before, the release team would then agree to rebase Qt in stable. Considering this usually never happens, the benefit of an LTS is moot. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#894748: plasma-workspace: Plasmashell crashes when notification shown
In data domenica 20 gennaio 2019 15:20:06 CET, Bernhard Übelacker ha scritto: > Control: tags -1 + moreinfo > > Hello Tom Wa, > just got to this bug report. > Do you still get this kind of freezes? > [...] Hi Bernhard, first of all, thanks for the help triaging bugs, asking for more information to the users, etc. What is the reason why you send the messages to nnn-quiet@, instead of nnn@? -quiet means that the maintainer does *not* get any notification, so none of your emails reach the maintainer mailing list. Also, if the user replies, they will send their reply to nnn-quiet@ too, still without notifying the maintainer (and thus ignored). In short, please do not send to nnn-quiet@. There is a very narrow set of reasons why -quiet exists, and none of them is part of the daily workflow with the BTS. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#914211: Processed: fixed in 5.54.1-1
In data sabato 19 gennaio 2019 10:19:15 CET, Maximilian Engelhardt ha scritto: > On Samstag, 19. Januar 2019 08:15:20 CET Pino Toscano wrote: > > In data sabato 19 gennaio 2019 01:12:38 CET, Debian Bug Tracking System ha > scritto: > > > Processing commands for cont...@bugs.debian.org: > > > > fixed 914211 5.54.1-1 > > > > > > Bug #914211 [src:kio] [src:kio] please remove insecure TLS version > > > fall-back mechanism Marked as fixed in versions kio/5.54.1-1. > > > > > > > thanks > > > > > > Stopping processing here. > > > > Closing the bug then. > > > > Maximilian, please follow the right procedure for closing bugs: > > https://www.debian.org/Bugs/Developer.en.html#closing > > > > Thanks, > > Hi Pino, > > I didn't close the bug because the version in stable is still affected by it. > I filed my initial report against both versions, stable and testing/unstable > at > that time, because I was told on #debian-devel IRC to do so. > So if this bug is closed how can/should the version in stable be tracked? The version that fixes the bug is not in stable, and the bug has a version present in stable as "found". I'd personally add the tag for the stable version, since I don't see how leaving a bug open will change anything (maxy does not do fixes to stable, and the rest of the "team" does not have the capacity to do so). I don't see how this is different from any other bug reported in the past that gets fixed only in unstable: it is not obviously not fixed in stable, and leaving it open will not magically make it fixed for stable. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#784479: [kde4libs] Qt4's WebKit removal
In data lunedì 14 gennaio 2019 22:28:46 CET, Adrian Bunk ha scritto: > What is actually the overall plan for KDE4 in buster now? kdelibs 4.x will stay in buster. Period. Dropping stuff just for the sake of removal is a no-go, especially when done from people who have NO IDEA about Qt/KDE libraries/applications. As I already asked you: Adrian Bunk, please stay away from Qt/KDE stuff. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#784479: [kde4libs] Qt4's WebKit removal
In data lunedì 14 gennaio 2019 12:22:52 CET, Scott Kitterman ha scritto: > On Thu, 01 Nov 2018 14:04:12 -0300 Lisandro > =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer wrote: > > On Wed, 17 Oct 2018 15:57:25 +0200 Ivo De Decker wrote: > > > Hi, > > > > > > On Fri, Nov 24, 2017 at 04:59:58PM -0300, Lisandro Damián Nicanor Pérez > > Meyer wrote: > > > > Control: tag -1 patch > > > > > > > > There is patch available for this at > <https://git.archlinux.org/svntogit/ > > > > packages.git/tree/trunk/kdelibs-no-kdewebkit.patch?h=packages/kdelibs> > > > > > > > > We might want to wait for the last tandem of KF5 apps though. > > > > > > Is there anything still blocking this? > > > > Yes, at least one co maintainer believes the kde-runtime patch is not > > appropriate. > > That patch no longer seems to be available, so I made my own. Patches for > kde4libs and kde-runtime attached. I looked at the KDE4 packages still in > Buster and I don't believe this interferes with anything. This also fixes > the > FTBFS with Samba 4.9 by dropping the KDE4 kio_smb. The samba compatibility issue is a different story, and it can be fixed by just disabling kio_smb (in case it requires non-trivial work to make it work again). > I think we should move forward on these (or some improved version if someone > has suggestions). > > Even though there are separate bugs for kde-runtime, since the patch for it > was already discussed in this bug, I thought we might as well keep them > together. Did you check that all the packages using kde4libs still build fine? The removal of kio_thumbnail from kde-runtime is definitely not appropriate, since it will break the thunbnail support for any kdelibs 4.x application. Again: something worth to mention, since apparently it is not clear: removing bits from either kde4libs or kde-runtime has consequences, either build time or runtime ones. Randomly chopping pieces without checking what changes, and potentially what breaks, is generally a big no-no from me. I do not see how "remove qtwebkit" is an excuse to start messing up with packages, just for the sake of package removal. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#917910: plasma-desktop: separate binary package for xembedsniproxy
severity 917910 wishlist thanks Hi, In data lunedì 31 dicembre 2018 16:19:34 CET, Clint Adams ha scritto: > Source: plasma-desktop > Version: 4:5.14.3-1 > > Please split xembedsniproxy out into its own binary package. I > don't want the entirety of plasma-desktop and all its dependencies > just for this single utility. What is the use case for it? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Processed: reassign 404156 to kde-cli-tools
In data venerdì 21 dicembre 2018 19:51:06 CET, Debian Bug Tracking System ha
scritto:
> Processing commands for cont...@bugs.debian.org:
>
> > # Bug still exists in KDE4
> > reassign 404156 kde-cli-tools
> Bug #404156 {Done: Debian FTP Masters }
> [kdebase-bin] /usr/bin/kdesu: Should show message if root privileges obtained
> via sudo without password
> Bug reassigned from package 'kdebase-bin' to 'kde-cli-tools'.
> No longer marked as found in versions kdebase/4:3.5.5a.dfsg.1-2.
> No longer marked as fixed in versions 4:16.08.3-3+rm.
> > thanks
> Stopping processing here.
Note that kde-cli-tools is _not_ "kde4". If you really want to reassign
it, the right component is kde-runtime.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#916938: [kdevelop] Still depends on clang-6.0
In data giovedì 20 dicembre 2018 19:04:33 CET, Alexander Kernozhitsky ha scritto: > According to #916837, llvm-defaults-6.0 will be removed soon. But kdevelop > still depends on one of the packages from this source. This package is > > libclang1-6.0 > > It wasn't noticed by transition tracker checks. Please remove the dependency. The C++ plugin for kdevelop, based on LLVM/Clang, should be already compatible with Clang 7. The Debian package of kdevelop already depends on the default version of llvm/clang (see libclang-dev, and llvm-dev among the other build dependencies), so a simple rebuild will change the dependency. Since you seem to care about this, what about instead direct your efforts towards a successful migration of src:llvm-defaults (that switches the default from LLVM 6 to 7) to testing, since it is stuck in unstable for more than a month? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#914045: qtbase-opensource-src breaks lots of autopkgtests
In data domenica 18 novembre 2018 22:08:17 CET, Dmitry Shachnev ha scritto: > Hi Lisandro and Paul! > > On Sun, Nov 18, 2018 at 05:47:04PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > None of the qtbase changes should be triggering this. *But* all the packages > > are being built with qttools5-dev-tools 5.11.2-4 instead of 5.11.2-5, and > > that > > might be the issue, as the latest version contains a fix for some clang > > stuff: > > > > <https://bugreports.qt.io/browse/QTBUG-70896> > > > > Ideally this tests should be retried with qttools-dev-tools 5.11.2-5. Can > > that > > be done? No enough build power here to try myself. > > No, retrying them won’t help. > > (TL;DR: we need to patch extra-cmake-modules. Extended description below.) > > The failures are caused by my commit which was fixing bug #913499: > > https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/44912fe676105951250e2cf5ad6c9bccf21e72cc > > It broke the logic in FindQHelpGenerator.cmake, which was detecting > qhelpgenerator using the path from location of Qt5::qmake. > > Previously it was correctly detecting it in /usr/lib/qt5/bin/qhelpgenerator, > but after the above commit it detects it in /usr/bin/qhelpgenerator which > fails with: > > qhelpgenerator: could not find a Qt installation of '' > > I see that Pino already fixed this in extra-cmake-modules upstream: > > https://cgit.kde.org/extra-cmake-modules.git/commit/?id=96d169b87292d935 > > The best way forward will be to cherry-pick that patch in extra-cmake-modules. This is correct, but not enough. The fix of the qhelpgenerator detection works only when the cmake config module for it is installed, which is shipped in qttools5-dev. Sadly, this package is not installed by all the Frameworks packages that generate QCH documentation, so uploading extra-cmake-modules with the above commit will do not it alone. The additional fix is to add also qttools5-dev as build dependency, and possibly also limit the documentation building to indep-only builds (since the QCH files are shipped in arch:any -doc packages). Imagine that there are almost 80 sources of Frameworks, and 60 of them provide a QCH documentation... -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#858938: fixed in kopete 4:18.04.1-1
In data sabato 10 novembre 2018 13:30:19 CET, Kurt Roeckx ha scritto: > On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote: > > On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote: > > > On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote: > > > > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote: > > > > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote: > > > > > > Source: kopete > > > > > > Source-Version: 4:18.04.1-1 > > > > > > > > > > > > We believe that the bug you reported is fixed in the latest version > > > > > > of > > > > > > kopete, which is due to be installed in the Debian FTP archive. > > > > > > > > > > Any plans to upload this to unstable? > > > > > > > > There are just two packages left in testing which use openssl1.0. The > > > > last kopete upload was in mid June. Is there anything blocking an upload > > > > to unstable? > > > > > > The other one just got fixed in unstable, so this will soon be the > > > only package in testing still depending on libssl1.0.2. > > > > kopete is the only package in testing still using libssl1.0.2. Could > > someone please comment on this? > > This is in experimental for more than 5 months now. > > If nobody replies to this, I will upload an NMU to unstable. NMU *what*? Because if you upload the version in experimental to unstable, then you are effectively taking its maintainership. The version in experimental is *NOT* ready for unstable/testing, otherwise I would have uploaded it long ago. I cannot work on it today, maybe tomorrow. OTOH, this kind of non-helping attitude for you openssl guys (for example not helping fixing these porting bugs, constant useless poking, breakage of openssl 1.1 in unstable) certainly does not help. If you want cooperation, then be ccoperative yourself, instead of just expecting others to follow whatever you do. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: qtdatavis3d-everywhere-src_5.10.1-1_amd64.changes is NEW
Dear FTP Masters, In data lunedì 30 aprile 2018 07:20:03 CET, Debian FTP Masters ha scritto: > binary:libqt5datavisualization5 is NEW. > binary:libqt5datavisualization5-dev is NEW. > binary:qml-module-qtdatavisualization is NEW. > binary:qtdatavisualization5-doc is NEW. > binary:qtdatavisualization5-doc-html is NEW. > binary:qtdatavisualization5-examples is NEW. > binary:qml-module-qtdatavisualization is NEW. > binary:libqt5datavisualization5-dev is NEW. > binary:qtdatavisualization5-doc is NEW. > binary:qtdatavisualization5-doc-html is NEW. > binary:libqt5datavisualization5 is NEW. > binary:qtdatavisualization5-examples is NEW. > source:qtdatavis3d-everywhere-src is NEW. > > Your package has been put into the NEW queue, which requires manual action > from the ftpteam to process. The upload was otherwise valid (it had a good > OpenPGP signature and file hashes are valid), so please be patient. This source does not have that many source files after all, and its licensing status seemed simple enough when I analyzed it. Considering it has been sitting for 6 months in the NEW queue without a single feedback about it in the meanwhile, would it be possible to take a look at this? OK for the "please be patient" bit, but 6 months with no feedback whatsoever seem excessive to me. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#912475: qtmultimedia-opensource-src: FTBFS on hurd: no qtaudioengine
tag 912475 - patch thanks Hi, In data mercoledì 31 ottobre 2018 23:26:26 CET, Samuel Thibault ha scritto: > qtmultimedia-opensource-src currently FTBFS on hurd because > qtaudioengine doesn't get built. > > https://buildd.debian.org/status/fetch.php?pkg=qtmultimedia-opensource-src=hurd-i386=5.11.2-2=1540905856=0 > > Could you apply the attached patch to just disable the resulting > package? This fix is incorrect, and works around a bug in another package. The issue comes from the fact that libopenal seems to not have all the proper dependencies, and thus the linking test fails with all the sio_* symbols (provided by libsndio) undefined. (I saw these undefined symbols errors also in other packages, so this is definitely something to fix at openal level, or below it.) I tried taking a quick look, and I did not find yet why apparently there is a behaviour change between Linux and Hurd. I did not have a lot of time to spend on it, though. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#890606: updated patch
Hi Felix, In data giovedì 4 ottobre 2018 06:18:35 CEST, Felix Lechner ha scritto: > Please try the attached patch. Over here, it builds kopete 17.08.3-1 > from unstable against the linphone libraries in experimental. I hope > it allows Linphone to enter unstable. > > The patch also applies to kopete 18.04.2-1 from experimental (with > fuzz), but still throws the error. If it is okay with you, I will > leave that for another day. Please let me know how it goes. Thank you! Can you please open a new review request upstream [1]? You will need to download kopete from git though, although it should not be an issue (it is like building 18.04.x from experimental). [1] https://phabricator.kde.org/ Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#905629: krita-1:4.1.1+dfsg-1: The .desktop file should use %f instead of %u.
In data mercoledì 8 agosto 2018 07:13:28 CEST, Wang Gary ha scritto: > > Yes, this is a bug in krita's .desktop file, and I just fixed it > > upstream: > > https://commits.kde.org/krita/c6c2368a3edb119a037065c19e9f504630e6c11f (>= > > 4.2) > > https://commits.kde.org/krita/08a64c2c0cb00fecb96ead7f4dd05e22595e74d1 (>= > > 4.1.2) > > It seems you are missing some changes, there are not only > one .desktop file, you can find other .desktop files like > krita_png.desktop, krita_kra.desktop, etc. in the path: > /plugins/impex// . Done, see https://phabricator.kde.org/D14682#305167. > We can also edit these files and replace %u to %f to solve > this issue, but the better way is adding file:// scheme support > to Krita itself. I've submitted a patch to kde Phabricator at > here: https://phabricator.kde.org/D14682 but I'm not sure if it's > the right place to submit patch.. Yes, phabricator is the right place. > Since this bug is not actually solved, it probably shouldn't mark > as fixed-upstream. Now it is fixed, so the tag can stay. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#905629: krita-1:4.1.1+dfsg-1: The .desktop file should use %f instead of %u.
tag 905629 + upstream fixed-upstream thanks Hi, In data martedì 7 agosto 2018 13:21:18 CEST, Wang Gary ha scritto: > While Krita doesn't support file:// scheme url as a launch argument, > Krita's .desktop files are using %u > or %U in the Exec key. For some file manager app like PCManFM(package: > pcmanfm-qt) and Deepin > File Manager(this package is not yet avaliabe on debian), it will use > a file:// scheme URL to replace the > %u argument. Thus Krita can't open file correctly. Yes, this is a bug in krita's .desktop file, and I just fixed it upstream: https://commits.kde.org/krita/c6c2368a3edb119a037065c19e9f504630e6c11f (>= 4.2) https://commits.kde.org/krita/08a64c2c0cb00fecb96ead7f4dd05e22595e74d1 (>= 4.1.2) > This is more likely a packaging issue, hope I don't get to the wrong > place to report bug. No, this was a plain, and genuine upstream bug. Thanks for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: where are the qtbase5-dbg files ?
Hi, please use debian-kde@ as user support list. In data sabato 14 luglio 2018 15:51:52 CEST, shirish शिरीष ha scritto: > Please CC me as I'm offlist. I was reading > https://unix.stackexchange.com/questions/202374/how-to-debug-an-installed-qt5-library-with-gdb Here, the information about finding the debug packages is obsolete. > I have the testing debug mirror in my /etc/apt/sources.list > > The only two packages I have found are of the qtbase5-dev-tools > packages but not of the base packages themselves. > > $ aptitude search dbgsym | grep qtbase > p qtbase5-dev-tools-dbgsym - debug symbols for qtbase5-dev-tools > p qtbase5-examples-dbgsym - debug symbols for qtbase5-examples Each -dbgsym package is named after the binary package whose debug symbols are shipped. So "foo" => "foo-dbgsym". -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#888367: qtav: diff for NMU version 1.12.0+ds-4.1
In data mercoledì 11 luglio 2018 23:04:15 CEST, Sebastian Ramacher ha scritto: > On 2018-07-11 22:53:00, Pino Toscano wrote: > > In data mercoledì 11 luglio 2018 22:40:42 CEST, Sebastian Ramacher ha > > scritto: > > > Control: tags 888367 + pending > > > > > > Dear maintainer, > > > > > > I've prepared an NMU for qtav (versioned as 1.12.0+ds-4.1) and > > > uploaded it to DELAYED/2. Please feel free to tell me if I > > > should delay it longer. > > > > Yes, please cancel this. I can take of this this weekend -- it would > > have been nice to have a ping regarding the transition, instead of > > silently NMU'ing. > > I wouldn't have sent a mail if I'd wanted to silently NMU. Well, thanks I guess ... > Also James pinged with a patch at the end of May … He mentioned only the upstream fixes, not any detail regarding the transition. Knowing whether a transition is still far or is approaching makes a difference, and it helps to schedule work on a package. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#888367: qtav: diff for NMU version 1.12.0+ds-4.1
In data mercoledì 11 luglio 2018 22:40:42 CEST, Sebastian Ramacher ha scritto: > Control: tags 888367 + pending > > Dear maintainer, > > I've prepared an NMU for qtav (versioned as 1.12.0+ds-4.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Yes, please cancel this. I can take of this this weekend -- it would have been nice to have a ping regarding the transition, instead of silently NMU'ing. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#903120: Contains malformed Categories= entry
tag 903120 + upstream fixed-upstream thanks In data venerdì 6 luglio 2018 13:06:36 CEST, Michael Biebl ha scritto: > the desktop file > /usr/share/applications/org.kde.polkit-kde-authentication-agent-1.desktop > contains a line > > Categories= > > obamen from openbox does not properly handle such malformed keys and > chokes on that [1]. > While this is ultimately an issue in the openbox parser, please consider > dropping that offending line from the desktop file. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887122 (Poor Categories line, it did not want to offend anyone... ;-) ) It makes sense, especially that that desktop file has OnlyShowIn=KDE. I just fixed the issue upstream with the following commit https://commits.kde.org/polkit-kde-agent-1/f2c5c6d26fd9f90bc413a0f407d675189a648020 which will be in - plasma 5.12 >= 5.12.7 - plasma 5.13 >= 5.13.3 - plasma >= 5.14 Thanks for report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#902227: Krita lead developer has requested Debian cease distributing his software.
tag 902227 + moreinfo thanks Hi anonymous user, In data sabato 23 giugno 2018 17:13:11 CEST, anondeb...@1337.no ha scritto: > As per the reddit thread > https://www.reddit.com/r/linux/comments/8t2zgc/maintainers_matter_the_case_against_upstream/ > > (https://www.reddit.com/r/linux/comments/8t2zgc/maintainers_matter_the_case_against_upstream/), > the lead developer of Krita has made it very clear that they want Debian and > other distributions to cease packaging Krita unless they can always package > the latest version. As this is the wish of upstream, I feel that Debian > should immediately honor their wishes and stop packaging Krita, so we can get > the vastly superior version that is packaged in their appimage/flatpak, what > have you. I do not see any explicit request in that forum thread. Boudewijn Rempt knowns already who does most of the packaging work for Debian (which is me), and how to contact me. Hence, if he thinks there are issues with the way Krita is packaged and shipped in Debian, he is very well welcome to contact the Qt/KDE packaging team and/or me directly. I will not do changed based on random interpretations of comments in some random forum on the Internet made by some random/anonymous nick. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#900922: RM: jovie -- ROM; obsolete, not used anymore
Package: ftp.debian.org Severity: normal Hi, please remove src:jovie, as it is the KDE 4 solution for text-to-speech as a service. Qt5 applications have the QtTextToSpeech module, and the remaining applications based on kdelibs 4.x do not use the jovie service at all. Thanks, -- Pino
Bug#900827: okular: Maybe it should not recommend jovie anymore
tag 900827 + pending thanks In data martedì 5 giugno 2018 17:17:15 CEST, Lisandro Damián Nicanor Pérez Meyer ha scritto: > Source: okular > Version: 4:17.12.2-2 > Severity: normal > > Jovie has been superseded by QtSpeech and okular is Qt5 based. > Maybe jovie should be removed from Recommends? Already removed in the 18.04.0-1 upload, which is sitting for a month in the NEW queue (sigh...). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#899144: [oxygen-icon-theme] Please include scalable version
In data sabato 19 maggio 2018 22:41:16 CEST, Bastien ROUCARIES ha scritto: > On Sat, May 19, 2018 at 9:55 PM, Pino Toscano <p...@debian.org> wrote: > > tag 899144 + moreinfo > > thanks > > > > In data sabato 19 maggio 2018 21:42:15 CEST, Bastien ROUCARIÈS ha scritto: > >> Some package packages scalable version (svg) of this theme. Could be > >> possible > >> to get scalable version here in order to create symbolic link and reduce > >> code > >> duplication > > > > You generally should not rely on a specific icon theme, so what exactly > > needs such symlinks, and why? > > A js package use it (mocha). For now I use 22x22 png but it is ugly I > will prefer to use the svg one. Oxygen is also used by a few other js > package. This still does not tell me what exactly mocha and the other js packages are doing with oxygen icons. Please explain in detail what is the actual situation, otherwise it is hard for us to implement a solution (and maintain it) for a problem we have no idea about. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#899144: [oxygen-icon-theme] Please include scalable version
tag 899144 + moreinfo thanks In data sabato 19 maggio 2018 21:42:15 CEST, Bastien ROUCARIÈS ha scritto: > Some package packages scalable version (svg) of this theme. Could be possible > to get scalable version here in order to create symbolic link and reduce code > duplication You generally should not rely on a specific icon theme, so what exactly needs such symlinks, and why? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: knotifications_5.45.0-2_source.changes ACCEPTED into unstable
In data domenica 13 maggio 2018 10:10:56 CEST, Maximiliano Curia ha scritto:
> ¡Hola Pino!
>
> El 2018-05-13 a las 09:12 +0200, Pino Toscano escribió:
> > In data domenica 13 maggio 2018 09:01:18 CEST, Maximiliano Curia ha scritto:
> >> ¡Hola Debian!
>
> >> El 2018-05-13 a las 06:05 +, Debian FTP Masters escribió:
> >>> * Run the test suite during the build:
> >>> - add the dbus-x11, xauth, and xvfb build dependencies
> >>> - run xvfb-run, using a fake home directory for it, running the test
> >>> suite
> >>> inside a dbus session
>
> >> Interesting, that used to fail in the past.
>
> >>> * Remove the unused, and now no more useful autopkgtest stuff.
>
> >> You also dropped the acc tests with this change, the acc test builds the
> >> installed headers and that helps checking that the -dev package is not
> >> missing
> >> a dependency and that the installed headers are not include a header that's
> >> not being installed.
>
> > How does running a tool ('acc') that is supposed to check for ABI
> > compatibility do that? From what I see, it is supposed to be used with
> > existing data as baseline, and none of the sources ship that.
>
> The abi generated files are too large to ship them in our packages,
> way more unstable than symbols, and not catching things like changes in the
> struct size. But while doing these tests building the headers help finding
> quite a number of missing headers/missing dependencies, etc.
Still, this is misusing a tool for not what is designed for. The ABI
compliance checker is, well, a tool for checking ABI, not for "checking
headers", and this means that the tool can change its way of working
any day, breaking the way it is (mis)used in this case.
Also, neither dh-acc, acc, or any of the acc autopkgtest in sources
depend on a g++ compiler, so I don't see how this even works (unless
something else pulls it as side dependency, or a chroot with
build-essential is by chance reused for the test).
Furthermore, just parsing the headers is not a real-world test: acc
seems to discover the location of the headers used on its own, while
when using cmake/qmake the actual headers path will be added using
targets and/or variables, which is what needs to be tested (see
#877351 for example).
Another point is that acc seems to use a C compiler when parsing the
headers, which means that it basically skips all the content of KF5
headers, demoting the acc run to a mere "do all the #include's work",
and nothing else.
Again: acc is the wrong tool for this job.
> > Also, if we want to check that a -dev does not miss dependencies, then
> > there are better ways to do that, rather than relying on the indirect
> > results of a tool that does something else.
>
> > I have a small utility locally in my disk that does exactly this, i.e.
> > run cmake on an auto-generated temporary CMakeLists.txt with
> > find_package(...) calls for modules specified on command line -- i.e.
> > $ pkgkde-test-cmake --output-on-failure KF5Foo Grantlee5
> > (the name can be changed, of course)
> > This makes it easy to integrate it as autopkgtest, as it does not even
> > need an helper script -- i.e. just add in debian/tests/control:
> > Test-Command: pkgkde-test-cmake --output-on-failure KF5Foo
> > Depends: build-essential, cmake, libkf5foo-dev
>
> > In the same fashion, something similar for qmake .pro files can be
> > created too.
>
> > Also, for pkg-config files a better test IMHO is:
> > Test-Command: pkg-config --cflags --libs Qt5WebKit
> > Depends: pkg-config, libqt5webkit5-dev
>
> > Would the above suggestions be better options for you?
>
> Sounds interesting and I'm sure this could be of use, but from what I can
> infer these scripts don't actually build the installed headers, so this would
> be an additional test, not a replacement.
Then let's have a _proper_ build test: add a sample source code (or
uses the examples, if the sources ship any), and build it with
cmake/qmake. This will be way more close to how libraries are actually
used, rather than just parsing their headers.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
