Bug#1053409: qtwebengine-opensource-src: FTBFS with re2 >= 20230601 (which requires abseil)
Control: tags -1 patch I created a merge request at: https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/ 26[1] -- Soren Stoutner so...@debian.org [1] https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/ 26 signature.asc Description: This is a digitally signed message part.
Bug#1053409: qtwebengine-opensource-src: FTBFS with re2 >= 20230601 (which requires abseil)
As Chromium has supported the updated RE2 since around 116, that will likely be included in the Qt WebEngine 6.7.0 release. https://wiki.qt.io/QtWebEngine/ChromiumVersions[1] It is unlikely to ever make it back to Qt WebEngine 5.15.x. Currently, Qt WebEngine 6 has switched to building against the embedded copy of RE2, which can be reverted once 6.7.0 is packaged. https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/commit/ d4ea2d870d0db1afc9c16668bf537f8fac28f3d7[2] I think I will make a similar adjustment to Qt WebEngine 5, but without the plan to ever switch it back as Qt WebEngine 5 is reaching end-of-life. -- Soren Stoutner so...@debian.org [1] https://wiki.qt.io/QtWebEngine/ChromiumVersions [2] https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/commit/ d4ea2d870d0db1afc9c16668bf537f8fac28f3d7 signature.asc Description: This is a digitally signed message part.
Bug#1067037: RFS: batsignal/1.8.0-1 -- Lightweight battery daemon written in C
On Monday, March 18, 2024 2:21:16 PM MST itd wrote: > > - d/watch / this dsc > > > > uscan download this: > > c8c2a048f4aa105aae389d9d765b76057d4998dbfc29a7dfeaf66351eaa7cba1 > > batsignal_1.8.0.orig.tar.gz> > > your dsc contains: > > d02e5c821d41e72c30d00bb88759287f9b74225e1217158e5e59f11ba03d5a5b > > batsignal_1.8.0.orig.tar.xz> > > when constructing your dsc, please make sure to use the same file as > > uscan would produce. (I've verified that the content of both orig files is > > identical) > Ouch, sorry about that. If I understand diffoscope correctly it's > indeed only the timestamps that differ. d/watch's version uses the date > of the upstream repo's 1.8.0 tag. My version, created via gbp, uses the > date of my repo's upstream/1.8.0 tag. I'll try to figure out how to > solve this. Without knowing for certain, I would suspect that the problem is that gbp is repacking your orig.tar as an .xz (the upstream is .gz). That is fine if a repack is intended, but in that case the file name should be something more like batsignal_1.8.0+dfsg.orig.tar.xz or batsignal_1.8.0+ds.orig.tar.xz. If you do intend to repackage the upstream tarball you should indicate it in the package version (+dfsg for upstream tarballs that need non-free components removed and +ds for tarballs that have things removed for reasons like size). https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds. 2BIB0_in_the_version_string_mean.3F[1] If you don’t intend to repackage the upstream tarball you probably need to modify your configuration to not do so. -- Soren Stoutner so...@debian.org [1] https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F signature.asc Description: This is a digitally signed message part.
Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, Thank you for your work on this package. It is quite impressive and I am happy to sponsor it. As this source package now contains new binary packages, I have done a source upload to the NEW queue. Soren On Thursday, March 7, 2024 12:19:47 PM MST Mateusz Łukasik wrote: > Hi Soren, > > Sorry for delay. I converted the sources into separate libraries in new > mentors upload. The soname will change every new version. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, Did you have any questions about what I was asking here? Soren On Tuesday, February 20, 2024 2:40:04 PM MST Soren Stoutner wrote: > Mateusz, > > When compiling locally on my system, the current version of lintian (2.117.0) > found the following problems. These are not displayed on mentors.debian.net, > leading me to believe they were recently added checks. > > W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/ > libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so] > N: > N: Although this package is not a "-dev" package, it installs a > N: "libsomething.so" symbolic link referencing the corresponding shared > N: library. When the link doesn't include the version number, it is used by > N: the linker when other programs are built against this shared library. > N: > N: Shared libraries are supposed to place such symbolic links in their > N: respective "-dev" packages, so it is a bug to include it with the main > N: library package. > N: > N: However, if this is a small package which includes the runtime and the > N: development libraries, this is not a bug. In the latter case, please > N: override this warning. > N: > N: Please refer to Development files (Section 8.4) in the Debian Policy > N: Manual for details. > N: > N: Visibility: warning > N: Show-Always: no > N: Check: libraries/shared/links > N: Renamed from: non-dev-pkg-with-shlib-symlink > N: > N: > W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8 > N: > N: The package name of a library package should usually reflect the soname > of N: the included library. The package name can determined from the > library N: file name with the following code snippet: > N: > N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/ > ^[[:space:]]*SONAME[[:space:]]*//p' | \ > N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/ \L&/' > N: > N: Visibility: warning > N: Show-Always: no > N: Check: libraries/shared/soname > N: > N: > I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct- common.so. > 1.8 > N: > N: Although the package includes a shared library, the package does not have > N: a symbols control file. > N: > N: dpkg can use symbols files in order to generate more accurate library > N: dependencies for applications, based on the symbols from the library that > N: are actually used by the application. > N: > N: Please refer to the dpkg-gensymbols(1) manual page and > N: https://wiki.debian.org/UsingSymbolsFiles for details. > N: > N: Visibility: info > N: Show-Always: no > N: Check: debian/shlibs > > As noted in the text of the checks, there are scenarios where these do not > apply (like small packages that include the runtime and the development > files), which appears to be the case with qt5ct. Can you please help me to > understand why qt5ct is including this shared library, if there are any other > packages in Debian that are building against this library, and if you feel > that any of the lintian checks above apply? If you feel they don’t apply I > would recommend you add lintian overrides and I will be happy to upload your > package. > > Soren -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1065078: Question about the debian group on Salsa
Generally you should create the repository under the debian namespace unless you really don’t want anyone else making any changes to it, even if the changes are urgent and you are AFK for some reason. I have created a repository named planner under debian and have granted you Developer access. :) On Thursday, February 29, 2024 7:28:59 AM MST Shriram Ravindranathan wrote: > Dear mentors, > > I'm curious about the guidelines for putting a package under the debian > namespace on Salsa <https://salsa.debian.org/debian>. I wasn't able to > find much discourse about this online. > > This package didn't have a salsa repository created for it, I am unsure > whether I should create a repository under my own namespace or if the > package should be placed under the debian namespace. > > Thank you, > > -- > Shriram Ravindranathan > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1054882: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp
On Wednesday, February 28, 2024 1:43:53 AM MST Simon Ruderich wrote: > The problem was the -std=gnu++11 which mas missing in the regexp, > now fixed in [1]. Thank you. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064346: Source is missing errors on HTML source files
Shriram, On Wednesday, February 21, 2024 8:30:54 AM MST Shriram Ravindranathan wrote: > Upon inspecting the embedded font, It seems to be a bespoke icon-font > generated using a tool called "Fontello" from one of the icons of the > octicons iconset from Atom <https://github.com/primer/octicons> (MIT > Licensed SVGs) > > The font has only 1 glyph, Would it suffice to add this source image to > d/missing-souces and add that copyright info to d/copyright? I would assume so. If anyone on mentors knows differently please speak up. > On 21/02/24 9:56 am, Soren Stoutner wrote: > > > > > > > Shriram, > > > > > > > > > > 1. For anything that has the unminified source in the upstream > > tarball, I would just create a lintian override with a comment listing > > the full path to the source for each file. You can see an example of > > how this can be done here: > > > > > > > > > > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/ sou > > rce/lintian-overrides?ref_type=heads > > > > > > > > > Typically you only copy the source to the debian/missing-sources > > directory when it is not included in the upstream tarball and you have > > had to acquire it from another place. > > > > > > > > > > 2. The github link below includes an embedded font in woff format. > > Typically, fonts like this would be considered compiled, so a separate > > font source would be needed. However, I’m not sure what the Debian > > guidance for dealing with an HTML embedded font like this. If someone > > else on mentors doesn’t know, I would recommend you ask on debian-legal. > > > > > > > > > > As these are mostly README files, and if it becomes difficult for you > > to acquire the source for some of them, you might consider excluding > > those you can’t get the source for, at least temporarily, using > > Files-Excluded in debian/copyright (and then running uscan, which will > > produce a modified tarball that does not include the problematic > > files). For example, see: > > > > > > > > > > https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/ copyr > > ight?ref_type=heads > > > > > > > > > Whether this is a good option depends on how helpful those README > > files are for the users of your package. If you go this route, you > > should add +dfsg to the version of your package to indicate that the > > upstream tarball has been repackaged to remove files that are not free > > (or for which the source is not available). > > > > > > > > > > Soren > > > > > > -- > Shriram Ravindranathan > ters > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064346: Source is missing errors on HTML source files
Shriram, 1. For anything that has the unminified source in the upstream tarball, I would just create a lintian override with a comment listing the full path to the source for each file. You can see an example of how this can be done here: https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads[1] Typically you only copy the source to the debian/missing-sources directory when it is not included in the upstream tarball and you have had to acquire it from another place. 2. The github link below includes an embedded font in woff format. Typically, fonts like this would be considered compiled, so a separate font source would be needed. However, I’m not sure what the Debian guidance for dealing with an HTML embedded font like this. If someone else on mentors doesn’t know, I would recommend you ask on debian-legal. As these are mostly README files, and if it becomes difficult for you to acquire the source for some of them, you might consider excluding those you can’t get the source for, at least temporarily, using Files-Excluded in debian/copyright (and then running uscan, which will produce a modified tarball that does not include the problematic files). For example, see: https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright? ref_type=heads[2] Whether this is a good option depends on how helpful those README files are for the users of your package. If you go this route, you should add +dfsg to the version of your package to indicate that the upstream tarball has been repackaged to remove files that are not free (or for which the source is not available). Soren On Tuesday, February 20, 2024 8:23:41 PM MST Shriram Ravindranathan wrote: > Thanks, Soren. > > It looks like most of these files have just one or two lines that are > extremely long. > > These are mostly README files. Most of them seem to have this > github-markdown.css > <https://gist.github.com/jojoldu/9cb1b6a5110619e221dfd4603f30ddd4> > minified and pasted in them. While others have the sources that were > used to generate them listed in the same folder. > > Should I copy these sources into the d/missing-sources directory? -- Soren Stoutner so...@debian.org [1] https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/ lintian-overrides?ref_type=heads [2] https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright? ref_type=heads signature.asc Description: This is a digitally signed message part.
Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, When compiling locally on my system, the current version of lintian (2.117.0) found the following problems. These are not displayed on mentors.debian.net, leading me to believe they were recently added checks. W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/ libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so] N: N: Although this package is not a "-dev" package, it installs a N: "libsomething.so" symbolic link referencing the corresponding shared N: library. When the link doesn't include the version number, it is used by N: the linker when other programs are built against this shared library. N: N: Shared libraries are supposed to place such symbolic links in their N: respective "-dev" packages, so it is a bug to include it with the main N: library package. N: N: However, if this is a small package which includes the runtime and the N: development libraries, this is not a bug. In the latter case, please N: override this warning. N: N: Please refer to Development files (Section 8.4) in the Debian Policy N: Manual for details. N: N: Visibility: warning N: Show-Always: no N: Check: libraries/shared/links N: Renamed from: non-dev-pkg-with-shlib-symlink N: N: W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8 N: N: The package name of a library package should usually reflect the soname of N: the included library. The package name can determined from the library N: file name with the following code snippet: N: N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/ ^[[:space:]]*SONAME[[:space:]]*//p' | \ N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/' N: N: Visibility: warning N: Show-Always: no N: Check: libraries/shared/soname N: N: I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct-common.so. 1.8 N: N: Although the package includes a shared library, the package does not have N: a symbols control file. N: N: dpkg can use symbols files in order to generate more accurate library N: dependencies for applications, based on the symbols from the library that N: are actually used by the application. N: N: Please refer to the dpkg-gensymbols(1) manual page and N: https://wiki.debian.org/UsingSymbolsFiles for details. N: N: Visibility: info N: Show-Always: no N: Check: debian/shlibs As noted in the text of the checks, there are scenarios where these do not apply (like small packages that include the runtime and the development files), which appears to be the case with qt5ct. Can you please help me to understand why qt5ct is including this shared library, if there are any other packages in Debian that are building against this library, and if you feel that any of the lintian checks above apply? If you feel they don’t apply I would recommend you add lintian overrides and I will be happy to upload your package. Soren -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1064346: Source is missing errors on HTML source files
The question is if the long lines in these HTML files are actually indications that the HTML files are not the original source. This usually happens in one of two cases. 1. The files have been minified. 2. The files were originally created in another format and converted to HTML. Sometimes HTML files naturally have long lines. If you look at the descriptions of the lintian warnings, they acknowledge that this is an imperfect check that will result in some false-positives. If that is the case, the HTML files are the original source, and they have not been minified, then you can override these warnings with a description as to why. On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote: > Hello mentors, > > I am getting a few lintian "source-is-missing" errors for some HTML > files. These HTML files are infact present in the source code but they > have too many lines which triggers a > "very-long-line-length-in-source-file" lintian tag and that in turn > causes the "source-is-missing" error. > > Most of the info I could find in the policy manual and in the forums > pertained to binary files that were included in the source, the strategy > these resources suggested were > 1. Repack upstream tar with the source code of these files > 2. Add the source code to the d/missing-sources directory > > I don't think either of these are viable options in my case. I was > wondering whether it would be okay to suppress these errors. Is there > any other way to solve this? > > -- > Shriram Ravindranathan > -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1062442: python3-trezor: electrum wants to use python3-trezor version 0.13.0 <= x < 0.14
Control: affects -1 + python3-electrum -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#683774: First time font packager questions
On Tuesday, February 13, 2024 3:17:00 PM MST Boyuan Yang wrote: > Welcome down to the rabbit hole. I believe the AFDKO issue is likely the > most important one. As far as I can tell it is blocked by > https://lists.debian.org/debian-fonts/2021/07/msg9.html , after which > no progress was made. If you could help, that would be really helpful and > unblock the packaging of a vast amount of different fonts. Boyuan, That is indeed a rabbit hole. Yao Wei, I would be interested in co-maintaining the AFDKO package with you if you would like. Specifically, I would like to address the two bug reports at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=afdko[1] As well as looking into the problem you described at: https://lists.debian.org/debian-fonts/2021/07/msg9.html If you are amenable to that I can prepare MRs on Salsa and submit them to you. -- Soren Stoutner so...@debian.org [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=afdko signature.asc Description: This is a digitally signed message part.
Bug#683774: RFP: fonts-source-sans -- set of OpenType fonts designed for user interfaces
Control: retitle -1 ITP: fonts-adobe-sourcesans3 -- set of OpenType fonts that have been designed to work well in user interface (UI) environments Control: owner -1 ! Control: tags -1 + ITP I would like to package these fonts as one of them is used by the Electrum package, which I maintain. My intention is to join to fonts group and maintain this package going forward. It should be noted that in 2020 the upstream author renamed the font from Source Sans Pro to Source Sans 3. https://github.com/adobe-fonts/source-sans/issues/192[1] Based on that, candidate names for the source package are: fonts-adobe-sourcesans3 fonts-adobe-source-sans3 fonts-adobe-source-sans-3 Does anyone have a strong preference as to which is used? -- Soren Stoutner so...@debian.org [1] https://github.com/adobe-fonts/source-sans/issues/192 signature.asc Description: This is a digitally signed message part.
Bug#1062448: python3-electrum missing dependency on python3-cbor
Control: tags -1 + pending Thanks for catching this. python3-cbor is listed in build-depends, but the system isn’t propagating that to the python3-electrum package. I will manually add it when I package the next upstream release, which I am planning to do in the next few days. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1057755: Qt WebEngine Security Support In Stable
On Sunday, December 24, 2023 3:50:26 AM MST Adrian Bunk wrote: > > If it ends up not being feasible to backport the entire Qt WebEngine from > > the next LTS release, then we could look at cherry-picking all of the > > security commits. This would be, by far, the most time-intensive solution. > > But, as your point out, the security fixes on the Chromium side are well > > marked. And, generally, they are small commits that only modify a few lines. > > > > For example: > >... > > Your "generally" is not true, it misses the biggest problem. > > Out of 20 CVEs there might be 19 easy ones, plus one that is a quite > invasive patch requiring a lot of backporting work. > > Who has both the required skills and a reliable commitment today for > doing in the year 2027 an urgent backport of a complex fix for a > zero-day vulnerability that is already being exploited in the wild? I intend to be involved in this work for a lot longer than 2027, although there will probably come a point 30 or 40 years down the road when I will need to hand it off to a future generation. As for the necessary skills, that is something I expect to pick up through a combination of hard work and being willing to ask questions. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1059164: angelfish: Stop depending on QQuickWebEngineDownloadItem private header
Package: angelfish Version: 22.11-1+b4 Severity: normal Tags: upstream Dear Maintainer, Angelfish currently depends on a private header for QQuickWebEngineDownloadItem. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057755 for context. This can be determined using the following command: $ nm -D /usr/bin/angelfish-webapp | grep Qt_5_PRIVATE_API U _ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API U _ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API It isn't clear to me exactly why this is happening. There is a public API for WebEngineDownloadItem. https://doc.qt.io/qt-5/qml-qtwebengine-webenginedownloaditem.html Qt 6 also has a public version of this API, which was renamed WebEngineDownloadRequest. https://doc.qt.io/qt-6/qml-qtwebengine-webenginedownloadrequest.html Looking at Angelfish's code, it appears that it is using the public Qt 5 version of this API, but for some reason it is pulling in the private header at some point. I haven't been able to determine if this is because of something explicit Angelfist is doing or if it is some bug on Qt's side. Privacy Browser doesn't exhibit this behavior when using the C++ version of WebEngineDownloadItem, so if it is a bug in Qt it is specific just to QML. But even more concerning is that, on Qt 6, Anglefish explicitly pulls in the private header for WebEngineDownloadRequest, even though I can't see anything they are doing that can't be done with the public API. >From https://sources.debian.org/src/angelfish/22.11-1/src/downloadsmodel.cpp/ #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0) #include "qquickwebenginedownloaditem.h" using DownloadItem = QQuickWebEngineDownloadItem; #else #include using DownloadItem = QQuickWebEngineDownloadRequest; #endif The current upstream maintains this behavior. From https://invent.kde.org/network/angelfish/-/blob/master/lib/angelfishwebprofile.cpp?ref_type=heads #include Depending on a private header when all the needed functionality appears to already be available in a public API doesn't make any sense and complicates efforts to include proper security support for Qt WebEngine in stable. If Anglefish does somehow need some functionality that is not included in the public API the best course of action would probably be to request that Qt publicly expose that functionality. If Angelfish doesn't actually need anything that isn't in the public API then it should be easy to stop using the private header. Looking through the code it appears the plumbing for this class and its methods have been significantly modified between Qt5 and Qt 6. If, for some reason, the QML version of the Qt 6 WebEngineDownloadRequest is still pulling in private versions of the methods, this would be a bug that I would imagine Qt would be willing to address. As this behavior doesn't exist for the C++ classes, I would not imagine that it is intentional. In the case of the current Qt 5 behavior, if this isn't something that is being explicitly done by Angelfish in some way, it is probably easiest to just let it go and expire when Qt 5 is removed from Debian. Altering these high-level APIs doesn't feel like the type of change Qt would be interesting in making to the Qt 5 LTS branch. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages angelfish depends on: ii libc6 2.37-12 ii libgcc-s1 13.2.0-7 ii libkf5configcore5 5.107.0-1 ii libkf5configgui55.107.0-1 ii libkf5coreaddons5 5.107.0-1 ii libkf5dbusaddons5 5.107.0-1 ii libkf5i18n5 5.107.0-1+b1 ii libkf5notifications55.107.0-1 ii libkf5windowsystem5 5.107.0-1 ii libqt5core5a5.15.10+dfsg-5 ii libqt5gui5 5.15.10+dfsg-5 ii libqt5network5 5.15.10+dfsg-5 ii libqt5qml5 5.15.10+dfsg-2 ii libqt5quick55.15.10+dfsg-2 ii libqt5sql5 5.15.10+dfsg-5 ii libqt5webengine55.15.15+dfsg-2+b1 ii libqt5webenginecore5 [qtwebengine-abi-5-15-15] 5.15.15+dfsg-2+b1 ii libqt5widgets5 5.15.10+dfsg-5 ii libstdc++6
Bug#1057758: kmail: Plain text emails truncated at 60 lines if HTML section is included
Package: kmail Version: 4:22.12.3-1 Severity: normal Tags: upstream Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=477443 When composing an email in both plain text and HTML, the plain text is truncated at 60 lines when the email is sent. The HTML contains the entire message.
Bug#1057755: qt6-webengine: Support security updates in stable
Source: qt6-webengine Version: 6.4.2-final+dfsg-12 Severity: normal Currently security patches to Qt WebEngine are not uploaded to Debian stable. The purpose of this bug report is to track efforts to change that.
Bug#1055066: usrmerge: Cannot update to version 38 on sbuild
Source: usrmerge Version: 37 Severity: critical Justification: breaks unrelated software Sbuild environments based on unstable are currently broken because they cannot update from version 37 to version 38. The following packages will be upgraded: cpp-12 dpkg dpkg-dev g++-12 gcc-12 gcc-12-base libdpkg-perl libgcc-12-dev libnsl-dev libnsl2 libseccomp2 libstdc++-12-dev usr-is-merged 13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 48.5 MB/48.5 MB of archives. After this operation, 84.0 kB of additional disk space will be used. Get:1 http://localhost:3142/deb.debian.org/debian unstable/main amd64 dpkg amd64 1.22.1 [1561 kB] Get:2 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libseccomp2 amd64 2.5.4-2 [46.8 kB] Get:3 http://localhost:3142/deb.debian.org/debian unstable/main amd64 g++-12 amd64 12.3.0-11 [10.8 MB] Get:4 http://localhost:3142/deb.debian.org/debian unstable/main amd64 gcc-12 amd64 12.3.0-11 [19.5 MB] Get:5 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libstdc++-12-dev amd64 12.3.0-11 [2068 kB] Get:6 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libgcc-12-dev amd64 12.3.0-11 [2436 kB] Get:7 http://localhost:3142/deb.debian.org/debian unstable/main amd64 cpp-12 amd64 12.3.0-11 [9855 kB] Get:8 http://localhost:3142/deb.debian.org/debian unstable/main amd64 gcc-12-base amd64 12.3.0-11 [40.7 kB] Get:9 http://localhost:3142/deb.debian.org/debian unstable/main amd64 dpkg-dev all 1.22.1 [1391 kB] Get:10 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libdpkg-perl all 1.22.1 [647 kB] Get:11 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libnsl-dev amd64 1.3.0-3 [66.9 kB] Get:12 http://localhost:3142/deb.debian.org/debian unstable/main amd64 libnsl2 amd64 1.3.0-3 [40.0 kB] Fetched 48.5 MB in 4s (11.4 MB/s) (Reading database ... 14797 files and directories currently installed.) Preparing to unpack .../archives/dpkg_1.22.1_amd64.deb ... Unpacking dpkg (1.22.1) over (1.22.0) ... Setting up dpkg (1.22.1) ... (Reading database ... 14795 files and directories currently installed.) Preparing to unpack .../libseccomp2_2.5.4-2_amd64.deb ... Unpacking libseccomp2:amd64 (2.5.4-2) over (2.5.4-1+b3) ... Setting up libseccomp2:amd64 (2.5.4-2) ... (Reading database ... 14794 files and directories currently installed.) Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) E: apt-get dist-upgrade failed This also breaks cowbuilder. https://lists.debian.org/debian-mentors/2023/10/msg00161.html
Bug#1054882: blhc: False positive: CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp
Package: blhc Version: 0.13+git20230913.fb2c46d-1 Severity: normal This bug appears to be a revival of #994422. It appears the that regex exception added there needs to be slightly tweaked to apply to all affected scenarios. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994422 It affects Privacy Browser as well as other packages like Falkon and possibly anything built with CMake. https://qa.debian.org/bls/packages/p/privacybrowser.html https://tracker.debian.org/media/packages/f/falkon/changelog-23.08.2-1 An example build log demonstrating the problem: https://buildd.debian.org/status/fetch.php?pkg=privacybrowser=amd64=0.5-1=1697132593=0 blhc complains about missing -D_FORTIFY_SOURCE=2 for the following line: /usr/bin/c++ -std=gnu++11 -dM -E -c /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp -DKCOREADDONS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICK_LIB -DQT_SQL_LIB -DQT_WEBCHANNEL_LIB -DQT_WEBENGINECORE_LIB -DQT_WEBENGINEWIDGETS_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/<>/obj-x86_64-linux-gnu/src -I/<>/src -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtSql -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtWebEngineCore -I/usr/include/x86_64-linux-gnu/qt5/QtQuick -I/usr/include/x86_64-linux-gnu/qt5/QtQmlModels -I/usr/include/x86_64-linux-gnu/qt5/QtQml -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtWebChannel -I/usr/include/x86_64-linux-gnu/qt5/QtPositioning -I/usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets -I/usr/include/KF5/KCompletion -I/usr/include/KF5 -I/usr/include/KF5/KConfigWidgets -I/usr/include/KF5/KWidgetsAddons -I/usr/include/KF5/KConfig -I/usr/include/KF5/KConfigGui -I/usr/include/x86_64-linux-gnu/qt5/QtXml -I/usr/include/KF5/KConfigCore -I/usr/include/KF5/KCoreAddons -I/usr/include/KF5/KCodecs -I/usr/include/KF5/KAuthWidgets -I/usr/include/KF5/KAuthCore -I/usr/include/KF5/KAuth -I/usr/include/KF5/KCrash -I/usr/include/KF5/KDBusAddons -I/usr/include/x86_64-linux-gnu/qt5/QtDBus -I/usr/include/KF5/KDocTools -I/usr/include/KF5/KI18n -I/usr/include/KF5/KNotifications -I/usr/include/KF5/KIOCore -I/usr/include/KF5/KIO -I/usr/include/KF5/KService -I/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -I/usr/include/KF5/KIOWidgets -I/usr/include/KF5/KIOGui -I/usr/include/KF5/KWindowSystem -I/usr/include/KF5/KJobWidgets -I/usr/include/KF5/Solid -I/usr/include/KF5/KXmlGui -I/usr/include -I/usr/include/c++/13 -I/usr/include/x86_64-linux-gnu/c++/13 -I/usr/include/c++/13/backward -I/usr/lib/gcc/x86_64-linux-gnu/13/include -I/usr/local/include -I/usr/include/x86_64-linux-gnu The -D_FORTIFY_SOURCE=2 flag is specified later in the build where it is actually needed. For example: cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ -DKCOREADDONS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICK_LIB -DQT_SQL_LIB -DQT_WEBCHANNEL_LIB -DQT_WEBENGINECORE_LIB -DQT_WEBENGINEWIDGETS_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/<>/obj-x86_64-linux-gnu/src -I/<>/src -I/<>/obj-x86_64-linux-gnu/src/privacybrowser_autogen/include -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtSql -isystem /usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtWebEngineCore -isystem /usr/include/x86_64-linux-gnu/qt5/QtQuick -isystem /usr/include/x86_64-linux-gnu/qt5/QtQmlModels -isystem /usr/include/x86_64-linux-gnu/qt5/QtQml -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtWebChannel -isystem /usr/include/x86_64-linux-gnu/qt5/QtPositioning -isystem /usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets -isystem /usr/include/KF5/KCompletion -isystem /usr/include/KF5 -isystem /usr/include/KF5/KConfigWidgets -isystem /usr/include/KF5/KWidgetsAddons -isystem /usr/include/KF5/KConfig -isystem /usr/include/KF5/KConfigGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KCoreAddons -isystem /usr/include/KF5/KCodecs -isystem /usr/include/KF5/KAuthWidgets -isystem /usr/include/KF5/KAuthCore -isystem /usr/include/KF5/KAuth -isystem /usr/include/KF5/KCrash -isystem /usr/include/KF5/KDBusAddons
Bug#1052211: bookworm-pu: package electrum/4.3.4+dfsg1-1+deb12u1
I’m afraid I don’t understand your comments. Are you saying I should wait longer for someone to review it or are you saying I should go ahead with the upload? On Thursday, September 28, 2023 1:07:47 PM MST Adam D. Barratt wrote: > More patience. :-p A week is not long to have waited, there's no need > to chase. > > Please go ahead. > > Regards, > > Adam -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020478: hunspell-br: Package the Qt WebEngine binary dictionary files from your Hunspell source
Would you be interested in a patch to implement this functionality? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1052211: bookworm-pu: package electrum/4.3.4+dfsg1-1+deb12u1
Are the any changes I should make before I upload a package? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1038240: chromium: Build with system libsrtp
On Wednesday, September 27, 2023 8:02:43 PM MST Andres Salomon wrote: > On Fri, 16 Jun 2023 11:15:32 -0700 Soren Stoutner > Really odd that I now get a "permission denied" error when I try to > access that upstream bug. :( I also get that, but when I log in it then allows me to see it. Perhaps that is because I am the original submitter of the bug. The bug is now labeled “Restrict-View-Google”. Perhaps they are taking it seriously as a security bug? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1052211: bookworm-pu: package electrum/4.0.9
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: elect...@packages.debian.org Control: affects -1 + src:electrum [ Reason ] A bug was discovered in a component known as Lightning of Electrum 4.1.0 - 4.4.5. https://github.com/spesmilo/electrum/security/advisories/GHSA-8r85-vp7r-hjxf [ Impact ] Users who opt to use the Lightning network (an optional component) can have portions of their Bitcoin transactions stolen by malicious nodes on the network. [ Tests ] Upstream has a test framework that I plan to integrate into autotests, but currently the Debian packages do not include those tests. [ Risks ] A cherry-picked fix was provided by upstream that patches 4.3.4 in bookworm. https://github.com/spesmilo/electrum/commit/11fba68126f82d05de90efd67f2b43dfd1b8f22c [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] The patch fixes the Lightning client to verify that all the components of a transaction are confirmed before releasing secrets to the Lightning node. I have also updated the Uploaders field to be myself. If that is inappropriate for a point release I can revert that change. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041171 [ Other info ] Discussion with upstream is at: https://github.com/spesmilo/electrum/issues/8588 This was discussed with Debian Security. I was going to attach a link to the public part of the discussion on the mailing list, but it appears that the list server web interface is currently down. However, there is some information on the security tracker. https://security-tracker.debian.org/tracker/TEMP-000-1C589C Note that the security tracker currently says that 4.0.9 in oldstable is affected. I had initially thought it was and indicated so to the Debian Security team. However, upstream recently confirmed that the bug wasn't introduced until 4.1.0, which is documented in the first and third GitHub links above.
Bug#1052200: electrum: Lightning security bug in bookworm 4.3.4+dfsg1-1
Package: electrum Version: 4.4.6+dfsg-1 Severity: grave Tags: patch security upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team 4.3.4+dfsg1-1 is susceptible to the Lightning bug fixed upstream in version 4.4.6. https://github.com/spesmilo/electrum/security/advisories/GHSA-8r85-vp7r-hjxf This can be fixed by a cherry-picked fix prepared by upstream. https://github.com/spesmilo/electrum/commit/11fba68126f82d05de90efd67f2b43dfd1b8f22c
Bug#1020475: Interest in a patch?
Would you be interested in a patch to implement this functionality? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1017646: Interest in patch?
Would you be interested in a patch to implement this functionality? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1041200: chromium: Uses deprecated Python distutils
Package: chromium Version: 114.0.5735.198-1 Severity: minor Tags: upstream There are a number of files that depend on Python's deprecated distutils. >From >https://udd.debian.org/lintian/?=chromium=html_information=on build/win/message_compiler.py:11 chrome/updater/test/service/win/run_command_as_standard_user.py:24 third_party/angle/src/tests/capture_replay_tests.py:26 third_party/depot_tools/external_bin/gsutil/gsutil_4.68/gsutil/third_party/crcmod/setup.py:1 third_party/depot_tools/external_bin/gsutil/gsutil_4.68/gsutil/third_party/crcmod/setup.py:2 third_party/depot_tools/fetch.py:34 third_party/depot_tools/scm.py:7 third_party/depot_tools/testing_support/coverage_utils.py:7 third_party/depot_tools/tests/fetch_test.py:17 third_party/grpc/src/setup.py:22 third_party/grpc/src/setup.py:27 third_party/grpc/src/setup.py:28 third_party/grpc/src/setup.py:29 third_party/grpc/src/src/python/grpcio/_parallel_compile_patch.py:20 third_party/grpc/src/src/python/grpcio/_spawn_patch.py:21 third_party/grpc/src/src/python/grpcio/support.py:15 third_party/grpc/src/src/python/grpcio_tests/commands.py:16 third_party/grpc/src/src/python/grpcio_tests/tests/protoc_plugin/_python_plugin_test.py:17 third_party/grpc/src/tools/distrib/python/grpcio_tools/_parallel_compile_patch.py:20 third_party/grpc/src/tools/distrib/python/grpcio_tools/setup.py:15 third_party/grpc/src/tools/distrib/python/grpcio_tools/setup.py:16 third_party/grpc/src/tools/distrib/python/grpcio_tools/setup.py:17 third_party/logilab/logilab/astroid/modutils.py:36 third_party/logilab/logilab/astroid/modutils.py:37 third_party/logilab/logilab/common/modutils.py:37 third_party/logilab/logilab/common/modutils.py:38 third_party/perfetto/python/setup.py:1 third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:38 third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:39 third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:40 third_party/protobuf/python/setup.py:24 third_party/protobuf/python/setup.py:25 third_party/protobuf/python/setup.py:26 third_party/protobuf/python/setup.py:27 third_party/protobuf/python/setup.py:7 third_party/pycoverage/setup.py:46 third_party/pycoverage/setup.py:47 third_party/pycoverage/setup.py:48 third_party/skia/infra/bots/assets/skp/create.py:14 third_party/tflite/src/tensorflow/api_template.__init__.py:29 third_party/tflite/src/tensorflow/api_template_v1.__init__.py:17 third_party/tflite/src/tensorflow/lite/python/convert.py:17 third_party/tflite/src/tensorflow/python/ops/math_ops_linspace_test.py:19 third_party/tflite/src/tensorflow/python/tpu/profiler/capture_tpu_profile.py:22 third_party/vulkan-deps/glslang/src/update_glslang_sources.py:24 third_party/webdriver/pylib/setup.py:18 third_party/wpt_tools/wpt/tools/wpt/browser.py:11 third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:5 third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:6 third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/wptcommandline.py:7 third_party/wpt_tools/wpt/tools/wpt/run.py:7 third_party/wpt_tools/wpt/tools/wpt/virtualenv.py:7 tools/binary_size/libsupersize/main.py:9 tools/bisect-builds.py:97 tools/ipc_fuzzer/scripts/cf_package_builder.py:12 tools/real_world_impact/real_world_impact.py:26 tools/valgrind/asan/third_party/asan_symbolize.py:31 v8/tools/release/common_includes.py:31 The description of this lintian tag reads as follows: This package uses the Python distutils module. In Python 3.10 and 3.11, distutils has been formally marked as deprecated. Code that imports distutils will no longer work from Python 3.12. Please prepare for this deprecation and migrate away from the Python distutils module. See-Also: https://peps.python.org/pep-0632 Python 3.12 is already in Debian and, presumably, at some point soon will become the default. https://tracker.debian.org/pkg/python3.12 This problem also affects qtwebengine-opensource-src and qt6-webengine, although the list of affected files is different. Does anyone know if upstream is working on removing the distutils dependency?
Bug#1041199: qt6-webengine: Uses deprecated Python distutils
Source: qt6-webengine Version: 6.4.2-final+dfsg-5 Severity: minor Tags: upstream There are a number of files that depend on Python's deprecated distutils. >From >https://udd.debian.org/lintian/?=qt6-webengine=html_information=on src/3rdparty/chromium/third_party/vulkan-deps/glslang/src/update_glslang_sources.py:24 src/3rdparty/chromium/third_party/webdriver/pylib/selenium/webdriver/firefox/firefox_profile.py:26 src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wpt/browser.py:10 src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:3 src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/browsers/safari.py:4 src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wptrunner/wptrunner/wptcommandline.py:5 src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wpt/run.py:5 src/3rdparty/chromium/third_party/wpt_tools/wpt/tools/wpt/virtualenv.py:5 src/3rdparty/chromium/tools/binary_size/libsupersize/main.py:9 src/3rdparty/chromium/tools/bisect-builds.py:93 src/3rdparty/chromium/tools/ipc_fuzzer/scripts/cf_package_builder.py:12 src/3rdparty/chromium/tools/real_world_impact/real_world_impact.py:26 src/3rdparty/chromium/tools/valgrind/asan/third_party/asan_symbolize.py:31 src/3rdparty/chromium/v8/tools/release/common_includes.py:31 tools/scripts/take_snapshot.py:13 src/3rdparty/chromium/build/toolchain/win/midl.py:10 src/3rdparty/chromium/build/win/message_compiler.py:12 src/3rdparty/chromium/third_party/pdfium/testing/tools/pngdiffer.py:8 src/3rdparty/chromium/third_party/perfetto/python/setup.py:1 src/3rdparty/chromium/third_party/protobuf/python/compatibility_tests/v2.5.0/setup.py:16 src/3rdparty/chromium/third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:38 src/3rdparty/chromium/third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:39 src/3rdparty/chromium/third_party/protobuf/python/protobuf_distutils/protobuf_distutils/generate_py_protobufs.py:40 src/3rdparty/chromium/third_party/protobuf/python/setup.py:19 src/3rdparty/chromium/third_party/protobuf/python/setup.py:20 src/3rdparty/chromium/third_party/protobuf/python/setup.py:21 src/3rdparty/chromium/third_party/protobuf/python/setup.py:4 src/3rdparty/chromium/third_party/pycoverage/setup.py:46 src/3rdparty/chromium/third_party/pycoverage/setup.py:47 src/3rdparty/chromium/third_party/pycoverage/setup.py:48 src/3rdparty/chromium/third_party/pyelftools/setup.py:10 src/3rdparty/chromium/third_party/tflite/src/tensorflow/api_template.__init__.py:29 src/3rdparty/chromium/third_party/tflite/src/tensorflow/api_template_v1.__init__.py:17 src/3rdparty/chromium/third_party/tflite/src/tensorflow/lite/python/convert.py:17 src/3rdparty/chromium/third_party/tflite/src/tensorflow/python/compiler/tensorrt/utils.py:17 src/3rdparty/chromium/third_party/tflite/src/tensorflow/python/ops/math_ops_linspace_test.py:19 src/3rdparty/chromium/third_party/tflite/src/tensorflow/python/tpu/profiler/capture_tpu_profile.py:22 src/3rdparty/chromium/third_party/tflite/src/tensorflow/tools/docs/base_dir.py:16 src/3rdparty/chromium/third_party/tflite/src/tensorflow/tools/docs/generate2.py:28 The description of this lintian tag reads as follows: This package uses the Python distutils module. In Python 3.10 and 3.11, distutils has been formally marked as deprecated. Code that imports distutils will no longer work from Python 3.12. Please prepare for this deprecation and migrate away from the Python distutils module. See-Also: https://peps.python.org/pep-0632 Python 3.12 is already in Debian and, presumably, at some point soon will become the default. https://tracker.debian.org/pkg/python3.12 This problem also affects qtwebengine-opensource-src and chromium, although the list of affected files is different. Does anyone know if upstream is working on removing the distutils dependency?
Bug#1041198: qtwebengine-opensource-src: Uses deprecated Python distutils
Source: qtwebengine-opensource-src Version: 5.15.13+dfsg-1~deb12u1 Severity: minor Tags: upstream There are a number of packages that depend on Python's deprecated distutils. >From >https://udd.debian.org/lintian/?=qtwebengine-opensource-src=html_information=on src/3rdparty/chromium/third_party/protobuf/python/setup.py:4 src/3rdparty/chromium/third_party/pycoverage/setup.py:46 src/3rdparty/chromium/third_party/pycoverage/setup.py:47 src/3rdparty/chromium/third_party/pycoverage/setup.py:48 src/3rdparty/chromium/third_party/pyelftools/setup.py:10 src/3rdparty/chromium/third_party/tlslite/setup.py:6 src/3rdparty/chromium/third_party/webdriver/pylib/selenium/webdriver/firefox/firefox_profile.py:26 src/3rdparty/chromium/third_party/webrtc/tools_webrtc/ios/build_ios_libs.py:17 src/3rdparty/chromium/tools/binary_size/diagnose_bloat.py:17 src/3rdparty/chromium/tools/binary_size/libsupersize/main.py:11 src/3rdparty/chromium/tools/binary_size/libsupersize/path_util.py:8 src/3rdparty/chromium/tools/ipc_fuzzer/scripts/cf_package_builder.py:12 src/3rdparty/chromium/tools/bisect-builds.py:90 src/3rdparty/chromium/tools/real_world_impact/real_world_impact.py:26 tools/scripts/take_snapshot.py:39 src/3rdparty/chromium/build/android/gyp/compile_java.py:7 src/3rdparty/chromium/build/toolchain/win/midl.py:10 src/3rdparty/chromium/build/win/message_compiler.py:12 src/3rdparty/chromium/third_party/angle/third_party/vulkan-loader/src/scripts/update_deps.py:245 src/3rdparty/chromium/third_party/angle/third_party/vulkan-tools/src/scripts/update_deps.py:245 src/3rdparty/chromium/third_party/blink/tools/blinkpy/third_party/wpt/wpt/tools/wpt/browser.py:10 src/3rdparty/chromium/third_party/blink/tools/blinkpy/third_party/wpt/wpt/tools/wpt/run.py:5 src/3rdparty/chromium/third_party/blink/tools/blinkpy/third_party/wpt/wpt/tools/wpt/virtualenv.py:5 src/3rdparty/chromium/third_party/glslang/src/update_glslang_sources.py:24 src/3rdparty/chromium/third_party/pdfium/testing/tools/pngdiffer.py:6 src/3rdparty/chromium/third_party/perfetto/src/trace_processor/python/setup.py:1 src/3rdparty/chromium/third_party/protobuf/python/compatibility_tests/v2.5.0/setup.py:16 src/3rdparty/chromium/third_party/protobuf/python/setup.py:18 src/3rdparty/chromium/third_party/protobuf/python/setup.py:19 src/3rdparty/chromium/third_party/protobuf/python/setup.py:20 The description of this lintian tag reads as follows: This package uses the Python distutils module. In Python 3.10 and 3.11, distutils has been formally marked as deprecated. Code that imports distutils will no longer work from Python 3.12. Please prepare for this deprecation and migrate away from the Python distutils module. See-Also: https://peps.python.org/pep-0632 Python 3.12 is already in Debian and, presumably, at some point soon will become the default. https://tracker.debian.org/pkg/python3.12 This problem also affects qt6-webengine and chromium, although the list of affected files is different. Does anyone know if upstream is working on removing the distutils dependency?
Bug#1039029: linux-signed-amd64: Core frequencies do not float correctly on AMD Ryzen 7 5700U when running on battery
Source: linux-signed-amd64 Version: 6.3.7+1 Severity: normal On my laptop running an AMD Ryzen 7 5700U CPU, when on battery there are problems with the core frequency logic. When a process consumes 100% CPU usage on a single core, the system forces the core frequencey to the lowest value (399 MHz) instead of letting it float up to the highest frequency (4.3 GHz). At the same time, other cores that have minimal CPU utilization will increate frequency up to the maximum, meaning that the CPU isn't locked to the lower frequency as a whole, but that something about the frequency control logic isn't making the correct decisions. This causes the system to run very slowly when on battery. When the laptop is plugged in the behavior disappears, with cores that are consuming significant CPU able to increase the frequency to the maximum value. It is unclear to me if this problem is with the Linux kernel or some other component. Someone who is more knowledgeable about these things than I am might be able to point me in the right direction. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1038240: chromium: Build with system libsrtp
Source: chromium Version: 113.0.5672.126-1 Severity: wishlist Tags: upstream Upstream recently added plumbing for building against a system libtiff. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033747 This means that there is only one system library outstanding: libsrtp. Adding support for building against a system libsrtp is going to be a little bit harder than it was for libtiff, as described at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866784 However, I thought it would be appropriate to make an upstream request: https://bugs.chromium.org/p/chromium/issues/detail?id=1455478
Bug#1038123: qt6-webengine: Build with system libpng beginning with Qt6 WebEngine 6.5
Source: qt6-webengine Version: 6.4.2-final+dfsg-1 Severity: normal Tags: upstream Beginning with 6.5, Qt WebEngine will have the plumbing to build against a system libpng. https://bugreports.qt.io/browse/QTBUG-112466 The purpose of this bug report is to provide a reminder that once 6.5 is released a build depends on libpng-dev needes to be added and likely a config option needs to be specified.
Bug#1020482: Ready to Implement
Rene, The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do for most of the dictionaries is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Regarding Aragonese, do you think upstream would be amenable to replacing the tab in their .aff file with spaces? For Galician, a copy of the .aff file will need to be made during build time, the extra long lines removed, and then the .bdic built from that modified .aff. For Hungarian and Ukrainian, a copy of the .aff files will need to be made during build time, the IGNORE commands removed, and then the .bdic files built from that modified .affs. Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020481: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Create a temporary copy of the dictionaries and remove the IGNORE commands from the .aff files. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020480: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020479: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Create a temporary copy of the dictionaries and remove the IGNORE commands from the .aff files. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020478: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020475: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020474: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1033747: Can’t Create Merge Request
https://salsa.debian.org/sorenstoutner/chromium/-/commit/ 4e771687e558a3c0b3c8dc052664e249d0db3c56[1] fixes this issue, but for some reason I can’t create a merge request. -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/sorenstoutner/chromium/-/commit/ 4e771687e558a3c0b3c8dc052664e249d0db3c56 signature.asc Description: This is a digitally signed message part.
Bug#1020473: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1033749: libqt6webenginecore6: WebEngine currently builds with an embedded copy of libtiff
Package: libqt6webenginecore6 Version: 6.4.2-final+dfsg-1 Severity: normal Tags: upstream WebEngine currently builds with an embedded copy of libtiff. https://udd.debian.org/lintian/?packages=qt6-webengine As described in the upstream Qt bug report, this appears to be a problem with the embedded pdfium, even though the standalong libQt6Pdf.so does not have an embedded copy, which has to do with different options being used during the separate build processes. https://bugreports.qt.io/browse/QTBUG-111626 An upstream Chromium bug has also been filed. https://bugs.chromium.org/p/chromium/issues/detail?id=1429647 The purpose of this bug report is to track the upstream progress of this fix. Once it is fixed upstream, it might or might not require a small modification in the packaging to enable building against the system libtiff. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqt6webenginecore6 depends on: ii libc6 2.36-8 ii libdbus-1-3 1.14.6-1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libfontconfig1 2.14.1-4 ii libfreetype62.12.1+dfsg-4 ii libgcc-s1 12.2.0-14 ii libharfbuzz-subset0 6.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libicu7272.1-3 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-2 2.14-2 ii libminizip1 1.1-8+b1 ii libnspr42:4.35-1 ii libnss3 2:3.87.1-1 ii libopenjp2-72.5.0-1+b1 ii libopus01.3.1-3 ii libpng16-16 1.6.39-2 ii libqt6core6 [qt6-base-abi] 6.4.2+dfsg-7 ii libqt6gui6 6.4.2+dfsg-7 ii libqt6network6 6.4.2+dfsg-7 ii libqt6positioning6 6.4.2-1 ii libqt6qml6 6.4.2+dfsg-1 ii libqt6quick66.4.2+dfsg-1 ii libqt6webchannel6 6.4.2-1 ii libqt6webengine6-data 6.4.2-final+dfsg-1 ii libre2-920220601+dfsg-1+b1 ii libsnappy1v51.1.9-3 ii libstdc++6 12.2.0-14 ii libvpx7 1.12.0-1 ii libwebp71.2.4-0.1 ii libwebpdemux2 1.2.4-0.1 ii libwebpmux3 1.2.4-0.1 ii libx11-62:1.8.4-2 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext62:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.5.0-1 ii libxkbfile1 1:1.1.0-1 ii libxml2 2.9.14+dfsg-1.1+b3 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii libxtst62:1.2.3-1.1 ii sse3-support15 ii zlib1g 1:1.2.13.dfsg-1 libqt6webenginecore6 recommends no packages. libqt6webenginecore6 suggests no packages. -- no debconf information
Bug#1033747: chromium: Build Chromium without the embedded libtiff
Package: chromium Version: 111.0.5563.110-1 Severity: normal Tags: upstream Chromium currently builds with an embedded copy of libtiff. This is likely pulled in by the embedded pdfium, althouth it might also be used in other places. Chromium usually detects the presence of system libraries at build time and uses them if they are present, but in the case of libtiff the necessary plumbing has never been added to do so. Upstream bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1429647 -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 111.0.5563.110-1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-02.46.0-5 ii libbrotli1 1.0.9-2+b6 ii libc62.36-8 ii libcairo21.16.0-7 ii libcups2 2.4.2-2 ii libdbus-1-3 1.14.6-1 ii libdouble-conversion33.2.1-1 ii libdrm2 2.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat12.5.0-1 ii libflac121.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-4 ii libgbm1 22.3.6-1+deb12u1 ii libgcc-s112.2.0-14 ii libglib2.0-0 2.74.6-1 ii libgtk-3-0 3.24.37-2 ii libjpeg62-turbo 1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.35-1 ii libnss3 2:3.87.1-1 ii libopenjp2-7 2.5.0-1+b1 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-16 1.6.39-2 ii libpulse016.1+dfsg1-2+b1 ii libre2-9 20220601+dfsg-1+b1 ii libsnappy1v5 1.1.9-3 ii libstdc++6 12.2.0-14 ii libwebp7 1.2.4-0.1 ii libwebpdemux21.2.4-0.1 ii libwebpmux3 1.2.4-0.1 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.4-2 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon01.5.0-1 ii libxml2 2.9.14+dfsg-1.1+b3 ii libxnvctrl0 525.85.05-1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.14.1-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 111.0.5563.110-1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.36-8 ii libdouble-conversion3 3.2.1-1 ii libjsoncpp25 1.9.5-4 ii libstdc++6 12.2.0-14 ii libx11-6 2:1.8.4-2 ii libxnvctrl0525.85.05-1 ii x11-utils
Bug#1020471: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020470: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020469: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020467: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020466: Ready to Implement
The dependencies are finally in place so this can be implemented. To make things simpler for dictionary packagers, we are using a virtual package and an unversioned path for the conversion tool so that dictionary packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depend on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. More detailed information can be found in the dictionary packager documentation at: file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic[1] Thanks, Soren -- Soren Stoutner so...@stoutner.com [1] file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic signature.asc Description: This is a digitally signed message part.
Bug#1020465: Ready to be implemented
The dependencies are finally in place where this is ready to be implemented. To make things simpler for the packagers, we are using a virtual package and an unversioned path for the conversion tool so that language packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depends on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1033136: chromium: Remove old Unicode DFSG-non-free license
Andres On Friday, March 17, 2023 6:11:04 PM MST Andres Salomon wrote: > Right, and debian's chromium is still carrying around a patch that > works around that older problematic unicode license. I've been meaning > to drop that patch. Currently, Lintian will flag any Convert-UTF file as a problem, even if it has the newer license. However, once the following MR is merged into Lintian, then it will no longer produce false positives. https://salsa.debian.org/lintian/lintian/-/merge_requests/461[1] > Where are you seeing this? > > dilinger@hm90:~$ grep -i "Unicode St" > sid-build/chromium-111.0.5563.64/third_party/icu/source/data/mappings/iso-88 > 59_1* ; echo $? > 1 > dilinger@hm90:~$ head -n2 > sid-build/chromium-111.0.5563.64/third_party/icu/source/data/mappings/iso-88 > 59_10-1998.ucm # Copyright (C) 2016 and later: Unicode, Inc. and others. > # License & terms of use: http://www.unicode.org/copyright.html It turns out that this has already been fixed sometimes between Chromium 108 and Chromium 111. https://sources.debian.org/src/chromium/108.0.5359.94-1~deb11u1/third_party/icu/source/ data/mappings/iso-8859_10-1998.ucm/[2] https://sources.debian.org/src/chromium/111.0.5563.64-1/third_party/icu/source/data/ mappings/iso-8859_10-1998.ucm/[3] After patching Lintian with a test that correctly found these files I ran it against a bunch of packages I had already built on my system. The version of the Chromium package I had around was 108, and I didn’t imagine that anything had changed in this regard since then. Turns our that assumption was incorrect. > Chromium's git repo doesn't include a bunch of third_party stuff; that > stuff gets pulled in automatically when the chromium devs generate > release tarballs. The directory in the release tarball documents where > they originate. In this case, in third_party/icu/README.chromium . > According to that, the source is from > https://github.com/unicode-org/icu . Even though I thought that repository had been updated in 2015, it looks like those particular licenses were only fixed in the repository in April 2022. Which explains the Chromium 108/111 difference. > > with the license at: > Yeah, breakpad's LICENSE file needs to be corrected. I can send a patch > upstream for that. Thanks. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#854209: Examples
Examples of how to appropriately relicense files that fail under this new Lintian check are below: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033134[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033135[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033136[3] -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033134 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033135 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033136 signature.asc Description: This is a digitally signed message part.
Bug#854209: Merge Request
There is a Salsa merge request that fixes this problem. https://salsa.debian.org/lintian/lintian/-/merge_requests/461[1] -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/461 signature.asc Description: This is a digitally signed message part.
Bug#854209: More general problem than just with convert_UTF
I was looking at Lintian’s source code to prepare a patch that would correct these false positives and I realized that Lintian doesn’t actually check for the presence of the problematic license at all. Rather, it was checking for some text that appears at the bottom of convert_UTF. Probably because they were worried that the words in the license file were too common and they didn’t want false-positives (which is what they ended up with anyway). So, I corrected the check to actually look for the problematic license and then ran the patched version against the qtwebengine-opensource-src package, which is one of the packages that had the false positive. This removed the false positive, but I was surprised to find that it discovered four other affected files in the package. E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/ 3rdparty/chromium/third_party/breakpad/breakpad/LICENSE] E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/ 3rdparty/chromium/third_party/icu/source/data/mappings/iso-8859_10-1998.ucm] E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/ 3rdparty/chromium/third_party/icu/source/data/mappings/iso-8859_11-2001.ucm] E: qtwebengine-opensource-src source: license-problem-convert-utf-code [src/ 3rdparty/chromium/third_party/icu/source/data/mappings/iso-8859_14-1998.ucm] One of these is a summary license file, but the other three are data files that contain the problematic license in their headers. This made me start to wonder how many other files in Debian also have the problematic license that have gone undetected because the Lintian check was not well formatted. In the case of these files it is possible, perhaps even likely, that Unicode also relicensed them under a DFSG-free license at some point. I am going to work with upstream to determine if that was the case and, if so, correct the license. Otherwise, I will work with upstream to see if there is some DFSG alternative to these files. Given the fact that this license extends beyond the convert_UTF file, I am planning on amending my patch to rename the check to something more generic, like license-problem-unicode and updating the description of the tag. For anyone coming to this bug report with questions about the status of a particular Unicode license, the problematic license contains the following statement: > Unicode, Inc. hereby grants the right to freely use the information > supplied in this file in the creation of products supporting the > Unicode Standard This is not DFSG-free because it restricts the users from using the source code in ways that do not support the Unicode standard. This phrase does not exist in the license that Unicode adopted later and which they relicensed their files to use. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
You are correct about past support. There probably hasn’t been anyone in Debian as focused on Qt WebEngine before me. That was part of the reason I decided to get involved in Debian. On Wednesday, March 15, 2023 11:05:14 PM MST Paul Wise wrote: > I don't see Debian security updates nor stable updates of Qt WebEngine > for current/previous Debian releases so far, but I am very glad to hear > that they are being worked on for the Debian bookworm release at least. > > https://lists.debian.org/debian-security-announce/ > https://lists.debian.org/debian-announce/ -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
I’m not sure I understand what point you are trying to make. On Wednesday, March 15, 2023 12:35:07 PM MST Mezgani Ali wrote: > Look Storen, > > Qt WebEgine used 15 years ago for developing a Safari from scratch. > Debian/GNU Linux is more GTK side than Qt. > > > Kind regards, > > Mezgani Ali > +212 6 44 17 94 51 > ali.mezg...@nativelabs.ma > https://wiki.debian.org/mezgani > > ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄⠀ > > > On 15/03/2023, at 19:52, Soren Stoutner wrote: > > > > Paul, > > > > The point is that these security updates are added upstream, they are > > regularly packaged in Debian, and it wouldn’t be any harder to support > > them in Debian stable than security updates for any other browser. Your > > original email indicated that none of these three things were true. > > > > Beyond that, you might find the following an interesting read (fairly > > long, but the point is that, as per the Chromium maintainer, Qt WebEngine > > has better coverage in Debian stable than Chromium does): > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255 > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255> Privacy > > Browser is not going to ship in Bookworm, but it will ship in Bookworm+1. > > Part of the reason why I have become one of the Qt maintainers is so > > that it receives proper security support in stable (and oldstable as much > > as possible, although there probably isn’t any web browser that currently > > has good security coverage in oldstable). > > > > Soren > > > > On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote: > > > Hi all! > > > > > > On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote: > > > > Paul, > > > > > > > > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit > > > > code > > > > to the upstream Qt project. > > > > > > > > The Salsa link you included appears to be a bit misinformed about > > > > security > > > > support for Qt WebEngine in Debian. For more accurate information, I > > > > would > > > > point you to this link: > > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794 > > > > > > Please note that this request is for a not-yet-released Debian version. > > > > > > I am not sure the Release team will agree to have such updates in > > > stable. > > > Although, I would be happy to discuss this with them. > > > > > > -- > > > Dmitry Shachnev > > > > -- > > Soren Stoutner > > so...@stoutner.com -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
Paul, The point is that these security updates /are/ added upstream, they /are /regularly packaged in Debian, and it wouldn’t be any harder to support them in Debian stable than security updates for any other browser. Your original email indicated that none of these three things were true. Beyond that, you might find the following an interesting read (fairly long, but the point is that, as per the Chromium maintainer, Qt WebEngine has better coverage in Debian stable than Chromium does): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255[1] Privacy Browser is not going to ship in Bookworm, but it will ship in Bookworm+1. Part of the reason why I have become one of the Qt maintainers is so that it receives proper security support in stable (and oldstable as much as possible, although there probably isn’t any web browser that currently has good security coverage in oldstable). Soren On Wednesday, March 15, 2023 11:34:58 AM MST Dmitry Shachnev wrote: > Hi all! > > On Tue, Mar 14, 2023 at 06:41:55PM -0700, Soren Stoutner wrote: > > Paul, > > > > I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code > > to the upstream Qt project. > > > > The Salsa link you included appears to be a bit misinformed about security > > support for Qt WebEngine in Debian. For more accurate information, I > > would > > point you to this link: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794 > > Please note that this request is for a not-yet-released Debian version. > > I am not sure the Release team will agree to have such updates in stable. > Although, I would be happy to discuss this with them. > > -- > Dmitry Shachnev -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387#255 signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
Paul, I /am/ one of the Debian Qt WebEngine maintainers, and I also submit code to the upstream Qt project. The Salsa link you included appears to be a bit misinformed about security support for Qt WebEngine in Debian. For more accurate information, I would point you to this link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794[1] Bug fixes for Qt WebEngine are backported every couple of months by upstream Qt: https://www.qt.io/blog/commercial-lts-qt-5.15.13-released[2] There are a number of other browsers based on Qt WebEngine currently in Debian. A non- exhaustive list includes the following: Konqueror Falkon qutebrowser Angelfish If you are interested in more information about the subject, I have a section of Privacy Browser’s handbook dedicated to the subject which is included in the index.docbook in the .deb. Soren On Tuesday, March 14, 2023 6:19:44 PM MST you wrote: > On Sat, 2023-03-11 at 14:41 -0700, Soren Stoutner wrote: > > * URL : https://www.stoutner.com/privacy-browser-pc/ > > privacybrowser - web browser that respects your privacy > > I note that this browser depends on Qt WebEngine, all the Qt based web > engines are not security supported in Debian. I encourage you to switch > to a browser engine that is security supported, or discuss with the > Debian and upstream Qt web engine maintainers to add such support. > > https://salsa.debian.org/debian/debian-security-support/-/blob/master/securi > ty-support-limited > * qtwebengine-opensource-src: No security support upstream and >backports not feasible, only for use on trusted content > * qtwebkit: No security support upstream and backports not feasible, >only for use on trusted content > * qtwebkit-opensource-src: No security support upstream and backports >not feasible, only for use on trusted content > * kde4libs: khtml has no security support upstream, only for use on >trusted content > * khtml: khtml has no security support upstream, only for use on >trusted content, see #1004293 -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032794 [2] https://www.qt.io/blog/commercial-lts-qt-5.15.13-released signature.asc Description: This is a digitally signed message part.
Bug#1032806: RFS: privacybrowser/0.1-1 [ITP] -- web browser that respects your privacy
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "privacybrowser": * Package name : privacybrowser Version : 0.1-1 Upstream contact : Soren Stoutner * URL : https://www.stoutner.com/privacy-browser-pc/ * License : GPL-3+, GFDL-NIV-1.3+ * Vcs : https://salsa.debian.org/sorenstoutner/privacybrowser Section : web The source builds the following binary packages: privacybrowser - web browser that respects your privacy To access further information about this package, please visit the following URL: https://mentors.debian.net/package/privacybrowser/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/privacybrowser/ privacybrowser_0.1-1.dsc Changes for the initial release: privacybrowser (0.1-1) experimental; urgency=low . * Initial release (closes: #1031755). Regards, -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1017646: Ready to implement
Don, I think we have finally reached a stage where we are ready to implement this. To make things simpler for the packagers, we are using a virtual package and an unversioned path for the conversion tool so that language packagers don’t have to make modifications to their packages when the versions of Qt change in Debian. All you should need to do is the following: 1. Build-depends on `convert-bdic`. 2. Use /usr/bin/convert-bdic to do the dictionary conversion. 3. Place the .bdic files in /usr/share/hunspell-bdic. Thanks, Soren -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1032673: lintian: inconsistent-appstream-metadata-license does not correctly match GFDL licenses
Package: lintian Version: 2.116.3 Severity: wishlist Lintian currently produces warnings like the following: inconsistent-appstream-metadata-license appdata.xml (gfdl-1.3 != gfdl-niv-1.3+) [debian/copyright] AppStream metadata defines a specific short list of acceptable licenses as described at: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license One of the available licenses uses the following syntax: GFDL-1.3 AppStream's documentation says that "The license codes correspond to the identifiers found at the SPDX OpenSource License Registry." However, SPDX does not use the simplified GFDL-1.3 syntax: https://spdx.org/licenses/ Rather, they describe the licence using the following syntax, which describe six subcategories of GFDL usage: GFDL-1.3-invariants-only GFDL-1.3-invariants-or-later GFDL-1.3-no-invariants-only GFDL-1.3-no-invariants-or-later GFDL-1.3-only GFDL-1.3-or-later Debian similarly uses specific syntax to describe subcategories of the GFDL: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name "For licenses that have multiple versions in use, the short name is formed from the general short name of the license family, followed by a dash and the version number. If the version number is omitted, the lowest version number is implied. When the license grant permits using the terms of any later version of that license, add a plus sign to the end of the short name. For example, the short name GPL refers to the GPL version 1 and is equivalent to GPL-1, although the latter is clearer and therefore preferred. If the package may be distributed under the GPL version 1 or any later version, use a short name of GPL-1+." "GFDL GNU Free Documentation License 1.0, 1.1, 1.2, or 1.3. Use GFDL-NIV instead if there are no Front-Cover or Back-Cover Texts or Invariant Sections." "GFDL-NIV GNU Free Documentation License, with no Front-Cover or Back-Cover Texts or Invariant Sections. Use the same version numbers as GFDL." Because the AppStream specification does not allow syntax that is any more precise than GFDL-1.3, Lintian should consider this to match against any of the following lincenses in debain/copyright: GFDL-1.3 GFDL-1.3+ GFDL-NIV-1.3 GFDL-NIV-1.3+ Similar matching should be applied for the AppStream's GFDL-1.1 and GDFL-1.2 licenses.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
I have created a merge request to update the documentation to reflect the changes in the Qt packaging that have entered unstable with qt6-webengine 6.4.2-final+dfsg-1. https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/6[1] https://tracker.debian.org/pkg/qt6-webengine[2] Soren -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/6 [2] https://tracker.debian.org/pkg/qt6-webengine signature.asc Description: This is a digitally signed message part.
Bug#1031755: ITP: privacybrowser -- web browser that respects your privacy
Package: wnpp Severity: wishlist Owner: Soren Stoutner X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: privacybrowser Version : 0.1 Upstream Contact: Soren Stoutner * URL : https://www.stoutner.com/privacy-browser-pc/ * License : (GPLv3+) Programming Lang: (C++) Description : web browser that respects your privacy Privacy Browser is a browser that is more focused on privacy than any of the other browsers currently available. It is developed using the Qt Toolkit and KDE Frameworks. I am the upstream developer and would like to also maintain the Debian package.
Bug#913758: Are you still having issues with hardware wallets?
It seems that some hardware wallets currently work with Electrum and others require software that is not currently packaged in Debian. I have recently added some documentation that will be included in future versions of Electrum. Could you take a look and see if there is any information you can add about the hardware wallets you use: https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16[1] Soren -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16 signature.asc Description: This is a digitally signed message part.
Bug#1030886: Proposed README file
I have added a proposed README file, which can be seen at: https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16[1] Let me know if there is anything else I should add or if you think anything should be reworded. Soren -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16 signature.asc Description: This is a digitally signed message part.
Bug#734235: Is this bug still an issue?
I have recently started working on the Electrum package and came across this old bug. Can you confirm that it is still an issue. It looks like at least some aspects of it have already been addressed upstream. https://github.com/spesmilo/electrum/issues/4637[1] -- Soren Stoutner so...@stoutner.com [1] https://github.com/spesmilo/electrum/issues/4637 signature.asc Description: This is a digitally signed message part.
Bug#772060: Is this bug still present
I recently started working on the Electrum package and noticed this bug report for a very old version. Can you confirm if this is still an issue? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#772059: Is this bug still relevant
I have recently started working on the Element package. I noticed this bug for a really old version. Can you confirm if it still exists in the current package? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#792399: Is bug still valid
I have recently started working on Electrum. I see this bug, which is for a really old version. Can you confirm if it is still a problem? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
It would be fine with me if Chromium provided the virtual package and symlink used to build the .bdic files. My only concern is that it is important that these always exist in Stable and Old Stable going forward. Otherwise, it makes backporting Hunspell language packages more difficult (not impossible, just more time consuming for the language package maintainers). On Thursday, February 16, 2023 1:19:45 PM MST Andres Salomon wrote: > Related to this - we got approval for chromium to ship in bookworm > (#1004441). That doesn't necessarily mean it'll be in future releases > (trixie or whatever), of course, but if it's easier for the dependency > chain; I'm open to discussing having chromium provide it. > > I haven't followed all of this very long thread, so it may be > irrelevant at this point. :) -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
Honestly, the impact on maintaining the Qt WebEngine packages is negligible. The Debian packages have been shipping the binary dictionary conversion tool for a long time, which is the biggest piece of the puzzle and has already been solved. Upstream (both Qt and Chromium) have not modified any of this code for a long time, and Chromium has stated that it is in maintenance mode, meaning they aren't currently planning to make any changes going forward, so nothing should need to change with the packaging of that. All the Qt packages need to do is to continue to ship the code that they have been shipping for a long time. The only difference is that now there is a symlink that makes it easy for language packaging to jump between Qt versions without needing to update their path to reference the new Qt version, there is a virtual package, so they don't need to update their build-depends to reference the new Qt version, and the WebEngines now have an environment variable set so they know where to look to find the dictionaries that are shipped by other packages. If this were going to be a large maintenance burden on Qt WebEngine packaging I could see there being some concern. But the burden on Qt packagers, myself or others, going forward is very minimal. On Thursday, February 16, 2023 11:22:01 AM MST Lisandro Damián Nicanor Pérez Meyer wrote: > El jueves, 16 de febrero de 2023 13:42:42 -03 Soren Stoutner escribió: > > Seeing as this is how Qt WebEngine is designed upstream, I think it is > > important to support it in Debian. From my personal perspective, the > > program I am developing (Privacy Browser) depends on Qt WebEngine and > > needs > > spell checking functionality to be viable in Debian. > > > > I have been working with the Qt 5 and 6 WebEngine code base recently and > > have submitted patches both to Debian and upstream. My goal is to make > > the > > WebEngine packages Lintian free, which is going to require a bit of work, > > but I am in it for the long haul. I am also willing to become the > > maintainer of the WebEngine packages or to co-maintain them with others. > > I'm totally in for this, but then I need to see proves before continue > exposing internal stuff to third parties. It's very much the same issue with > private headers. > > I would definitely do not mind to expose this if the Qt project compiles the > bdic files as part of their build process *and* it's part of their CI > testing. > > While I agree that the entire design of the .bdic binary dictionaries is > > suboptimal, I think that appropriately supporting them in Debian is the > > best way forward. > > Believe me I try to do the same, but web engines already made me waste too > much time, so I try to avoid whatever could bring us yet another headache. A > simple error can easily cost a couple of hours. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
Seeing as this is how Qt WebEngine is designed upstream, I think it is important to support it in Debian. From my personal perspective, the program I am developing (Privacy Browser) depends on Qt WebEngine and needs spell checking functionality to be viable in Debian. I have been working with the Qt 5 and 6 WebEngine code base recently and have submitted patches both to Debian and upstream. My goal is to make the WebEngine packages Lintian free, which is going to require a bit of work, but I am in it for the long haul. I am also willing to become the maintainer of the WebEngine packages or to co-maintain them with others. While I agree that the entire design of the .bdic binary dictionaries is suboptimal, I think that appropriately supporting them in Debian is the best way forward. On Thursday, February 16, 2023 4:25:45 AM MST Lisandro Damian Nicanor Perez Meyer wrote: > By the way: I **do** understand that what you all are proposing is an easy > way out and sounds like it makes sense. > > Now I have been around Qt for 10+ years already, and suffered each and every > web engine of the day source code during all this time. I know how > problematic it can be and how, at the end of the day, is us maintainers > then one that get the broken pieces when something breaks. Really, it's a > pain. > > Had this occurred in another Qt submodule I would probably not be so adamant > in avoiding it. But webengine/webkit where always a PITA. And I do not > expect that to change, I'm afraid. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
Which part do you not understand about not being needed on both Qt 5 and Qt 6? The part about building the .bdic files or the part about Qt WebEngine using the .bdic files at runtime? On Tuesday, February 14, 2023 12:25:20 PM MST Lisandro Damián Nicanor Pérez Meyer wrote: > One thing I do not understand is why is this needed on both Qt 5 and Qt 6? > What I understand from the thread is that currently any of them can provide > the dictionaries, so why not keeping this under just one source package? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1030916: Submit Upstream?
Would this be the type of patch that is more appropriate to submit upstream? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1030886: No Package Available
Vincas, Thank you for the information in your bug report and for your followup fix. I do not personally own any hardware wallets, so I have not been able to test out hardware wallet support. Based on what you have written, it would appear that the dependency you needed to have installed is not packaged in Debian. https://pypi.org/project/ledger-bitcoin/[1] https://packages.debian.org/search?keywords=ledger[2] Also, it appears it might be specific to hardware manufactured by Ledger, although I admit that I do now know enough about the subject to be sure. https://www.ledger.com/[3] In the future it would be ideal to package everything in Debian necessary to fully support hardware ledgers. However, as that is not likely to happen in the short term, I think it would be valuable to at least document what a user needs to add to get hardware wallets working in a README file installed with Electrum. Would you be willing to send me a list of what you have done to get hardware wallets working for you and which hardware wallets are supported by these steps? Thanks, Soren -- Soren Stoutner so...@stoutner.com [1] https://pypi.org/project/ledger-bitcoin/ [2] https://packages.debian.org/search?keywords=ledger [3] https://www.ledger.com/ signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
Yes, the packages will continue to ship the conversion tools under their current names in perpetuity. Because Qt goes through version transitions, there are often two version of Qt available in Debian (currently Qt 5 and Qt 6), both of which will ship this tool under a versioned path. The latest version of Qt will ship a virtual package named `convert-bdic` that will install a symlink from /usr/bin/convert-bdic to the actual location of the conversion utility that is shipped with the newest version of Qt packaged in Debian. When this commit is merged and released, the package providing the `convert-bdic` virtual package will be `qt6-webengine-dev-tools` and /usr/bin/convert-bdic will be a symlink to usr/lib/qt6/libexec/qwebengine_convert_dict. Packages manually calling the Qt 5 version will need to be updated when Qt 5 is removed from Debian (at some future date that will likely be a while). There is not currently any difference between the the copies of `qwebengine_convert_dict` that is shipped with Qt 5 and that shipped with Qt 6. Both are the same as the upstream Chromium `convert_dict`, which Google has not changed in a long time. On Monday, February 6, 2023 3:39:25 PM MST Agustin Martin wrote: > El sáb, 4 feb 2023 a las 20:20, Rene Engelhard () escribió: > > Hi, > > > > Am 04.02.23 um 19:14 schrieb Soren Stoutner: > > > Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is > > > probably not the most accurate name, but bdic-convert-dict would make > > > sense. Another option would be to name it convert-bdic. The Chromium > > > upstream names the tool convert_dict, but we aren’t beholden to follow > > > their lead. > > > > > > I have updated the merge request to name the tool /usr/bin/convert-bdic, > > > and the virtual package to be convert-bdic, but can change it again if > > > there is a consensus in a different direction. > > > > convert-bdic is fine with me, thanks :) > > Also fine with me, thanks. > > One question. Will old packages keep shipping conversion tool using > old name and location for a while? We would otherwise need to rebuild > dicts to use new dependency and avoid FTBFS. Once it is clear that > /usr/bin/convert-bdic is the new path I will add it as preferred path. > > Regards, -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is probably not the most accurate name, but bdic-convert-dict would make sense. Another option would be to name it convert-bdic. The Chromium upstream names the tool convert_dict, but we aren’t beholden to follow their lead. I have updated the merge request to name the tool /usr/bin/convert-bdic, and the virtual package to be convert-bdic, but can change it again if there is a consensus in a different direction. On Saturday, February 4, 2023 10:51:38 AM MST Rene Engelhard wrote: > Hi, > > Sorry for my absence, and sorry if it's already discussed: > > Why convert-dict? Sounds to generic to me, can't we at least do > qt-convert-dict or bdic-convert-dict or so? > > > Regards, > > > Rene -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
I have submitted a merge request to the qt6webengine package that implements what has been discussed. https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/merge_requests/4[1] Once it is merged, I will prepare a merge request for the documentation in this package that reflects these changes, specifically that Hunspell language packages should build- depend on the `convert-dict` virtual package and use the unversioned /usr/bin/convert_dict to create the .bdic files. On Tuesday, January 31, 2023 1:25:59 PM MST Soren Stoutner wrote: > In discussion with the Qt 5 maintainer, we have found a solution that does > not use a symlink, which will be included in the upcoming 5.15.12+dfsg-3 > release. > > More information can be found at: > > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/12[1] -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/merge_requests/4 signature.asc Description: This is a digitally signed message part.
Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
`UNRELEASED` is used because it will cause a failure if you accidentally try to upload it, which prevents accidental releases before they are intended. At the point of release, you should change it to be `unstable` or `experimental` or a backports repository. On Saturday, February 4, 2023 8:18:19 AM MST min sun wrote: > > Hello Min Sun, > > > > is there a particular reason why you opt for / stick to distribution > > `UNRELEASED` for a package already monitored by the tracker?[1] It is the > > entry e.g., `dch -i` puts into file `/debian/changelog` when you start to > > work on a new version (increment) of a package. After all other other > > work on your side is done, an eventual change to the string `unstable` > > (then lower case only) is one of the keys necessary to let results of > > your work enter branch `unstable`, and later `testing`, etc. > > Thanks for your clarification, Tony, > > I did not mean to specify it as `UNRELEASE`, the ‘uscan and uupdate” tools > insert this keyword to debian/changelog. > > I am not clear about the internal mechanism from `UNRELEASED` to `testing` > and later stage. > > I need learn more about Debian policy along with your guideline. > > All the best. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1030185: qutebrowser: Suggest or recommend the Hunspell dictionary packages
Package: qutebrowser Version: 2.5.2-2 Severity: wishlist Tags: upstream Debian recently added support for Hunspell .bdic binary dictionaries used by Qt WebEngine. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387 https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/12 There is an upstream request to handle the `QTWEBENGINE_DICTIONARIES_PATH` in a way that is compatible with Debian's implementation. https://github.com/qutebrowser/qutebrowser/issues/4966 Once that is in place, it might make sense to either recommend or suggest the Hunspell language packages.
Bug#1029621: Related bug
This has some relation to the integration of the Hunspell .bdic files into Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030183[1] and the links it contains. -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030183 signature.asc Description: This is a digitally signed message part.
Bug#1030183: falkon: Add support for system-wide dictionaries
Package: falkon Version: 22.12.0-3 Severity: wishlist Tags: upstream Debian recently added support for system-wide .bdic binary dictionaries used by Qt WebEngine. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387 https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/12 To support this, Falkon needs to look for dictionaries in the same manner as the Qt WebEngine, as can be seen on line 235 of the following file: https://sources.debian.org/src/qtwebengine-opensource-src/5.15.12%2Bdfsg-2/src/core/web_engine_library_info.cpp/ I have reported this upstream at https://bugs.kde.org/show_bug.cgi?id=465094 In addition to adding the correct detection logic, Falkon can also choose to suggest or recommend the various Hunspell language dictionary packages.
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
In discussion with the Qt 5 maintainer, we have found a solution that does not use a symlink, which will be included in the upcoming 5.15.12+dfsg-3 release. More information can be found at: https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/12[1] On Monday, January 9, 2023 11:37:58 AM MST Soren Stoutner wrote: > For sake of completeness, it was previously discussed that it would be > possible to patch the Qt WebEngine source to directly look for the > dictionaries in /usr/share/hunspell-bdic instead of the default upstream > location. It is unclear how much ongoing maintenance effort that would > entail, but it is a possible solution if the symlink is unacceptable. -- Soren Stoutner so...@stoutner.com [1] https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/12 signature.asc Description: This is a digitally signed message part.
Bug#854209: Interest in a patch
Would you be interested in a patch to fix the false positives in this Lintian check? -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1007002: Update Documentation
Thank you. On Wednesday, January 18, 2023 2:47:01 PM MST Axel Beckert wrote: > But I'll at least try to update doc/lintian.rst so that at least the > content is ready once we can update the website again. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1029055: Debian Expat and SPDX MIT License Text
Thanks Richard. I was unaware of the XML versions. So, this would mean that SPDX considers what Debian calls the MIT (Expat) license to match what SPDX calls MIT because the differences are all either considered by SPDX to be omittable or replaceable as demonstrated by the tags in the XML file and the text colors in the HTML version. On Wednesday, January 18, 2023 12:52:23 PM MST Richard Fontana wrote: > The SPDX definition of "MIT" is given in > https://github.com/spdx/license-list-XML/blob/main/src/MIT.xml > Based on a lot of experience now, you really have to consult the XML > files rather than rely on the convenience publication of license texts > at https://spdx.org/licenses > > Based on that, and https://www.debian.org/legal/licenses/mit, and > https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templa > tes/ > > I think the answer is that what Debian calls "MIT (Expat)" on that > page matches what SPDX calls "MIT" (I don't think they are "the same" > because the underlying concepts of what a license is and so forth are > not the same). > > Richard -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1007002: Update Documentation
It would probably be helpful to update the documentation at https://lintian.debian.org/manual/index.html#format-of-override-files[1] to describe the new pointed hints format. -- Soren Stoutner so...@stoutner.com [1] https://lintian.debian.org/manual/index.html#format-of-override-files signature.asc Description: This is a digitally signed message part.
Bug#854209: Update Description
Once this bug has been fixed, it would probably make sense to update the Lintian description to indicate that the problematic file can be appropriately relicensed to a DFSG compatible license, with a link to this bug report for information about the details. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1029064: Lintian Bug
There is some additional information in the Lintian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854209[1] -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854209 signature.asc Description: This is a digitally signed message part.
Bug#854209: Additional information
I recently came across this bug report while working on cleaning up Lintian errors on qtwebengine-opensource-src. The summarized version of the problem is that the file was originally licensed under a non- DFSG-free license, but was later changed by Unicode to be under a DFSG-free licence. Google has some discussion of the issue here: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=270[1] Based on what was documented, they changed the license of the file in their repository here: https://chromium.googlesource.com/breakpad/breakpad/+/ 14bbefbd9600e08d6a34d7250faa8bc9dba2113e%5E%21/[2] LLVM has recently changed the license of the code in their repository for the version 16 release: https://llvm.org/doxygen/ConvertUTF_8cpp_source.html[3] The text of the DFSG-free license can be found at: https://www.unicode.org/license.txt[4] The result is that some of the packages in Debian still have the problematic code listed in the header, but others do not. Packages with the non-DFSG-free license (correct Lintian positive): binaryen desmume funguloids libdbd-odbc-perl llvm-toolchain-9 llvm-toolchain-13 llvm-toolchain-14 llvm-toolchain-15 opencollada parser spring tla unshield zeek Packages with a DFSG-free license (false Lintian positive): firefox firefox-esr llvm-toolchain-snapshot qt6-webengine qtwebengine-opensource-src thunderbird It is easy to tell which packages have the problematic license because they contain the words “products supporting”, which phrase is not contained in the acceptable license. I propose that the Lintian check be modified to only flag files that contain “products supporting”. Once that change is made, I would be happy to work with the various maintainers of the problematic packages to help them get the correct licensing into their upstream files. signature.asc Description: This is a digitally signed message part.
Bug#1029064: binaryen: Fix for ConvertUTF.cpp licensing problem
Source: binaryen Version: 108-1 Severity: wishlist Your source contains a copy of ConvertUTF.cpp at third_party/llvm-project/ConvertUTF.cpp. As https://lintian.debian.org/tags/license-problem-convert-utf-code indicates, the license listed at the top of the file is not DFSG-free. However, as https://bugs.chromium.org/p/google-breakpad/issues/detail?id=270 and https://chromium.googlesource.com/breakpad/breakpad/+/14bbefbd9600e08d6a34d7250faa8bc9dba2113e%5E%21/ explain, the license was replaced by Unicode with a different license that is DFSG-free. Specifically, the file can now be licensed with the text at https://www.unicode.org/license.txt. It looks like your upstream code uses a copy acquired from LLVM. Beginning with version 16, LLVM has replaced the license the problematic licensing text with the current license as can be seen at https://llvm.org/doxygen/ConvertUTF_8cpp_source.html. Once your upstream updates the license, you can remove your current Lintian override.
Bug#1029055: Debian Expat and SPDX MIT License Text
SPDX itself might have an answer that is satisfactory: "The original replaceable text appears on the SPDX License List webpage in red text." "Omittable text appears on the SPDX License List webpage in blue text." https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/[1] On Monday, January 16, 2023 11:48:48 PM MST Soren Stoutner wrote: > There appears to be some question of opinion as to if the Debian MIT (Expat) > License is the same as the SPDX MIT License. > > https://www.debian.org/legal/licenses/mit[1] > > https://spdx.org/licenses/MIT.html[2] > > Can somebody at Debian Legal please comment? -- Soren Stoutner so...@stoutner.com [1] https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/ signature.asc Description: This is a digitally signed message part.
Bug#1029055: Debian Expat and SPDX MIT License Text
There appears to be some question of opinion as to if the Debian MIT (Expat) License is the same as the SPDX MIT License. https://www.debian.org/legal/licenses/mit[1] https://spdx.org/licenses/MIT.html[2] Can somebody at Debian Legal please comment? -- Soren Stoutner so...@stoutner.com [1] https://www.debian.org/legal/licenses/mit [2] https://spdx.org/licenses/MIT.html signature.asc Description: This is a digitally signed message part.
Bug#1029055: MIT License Text
I just noticed that AppStream specifies that their licenses use the text listed by SPDX. As the text of the MIT License at https://spdx.org/licenses/MIT.html[1] is the same as the Debian MIT License (Expat) at https://www.debian.org/legal/licenses/mit (except for the instructions in blue), there probably shouldn’t be any question that these are simply two different names for the same license (for reasons that probably shouldn’t surprise me, open-source people can’t just get along and agree on a name). -- Soren Stoutner so...@stoutner.com [1] https://spdx.org/licenses/MIT.html signature.asc Description: This is a digitally signed message part.
Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)
I created a new bug report to discuss this issue as the root cause ends up being different than what was originally reported here. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029055[1] -- Soren Stoutner so...@stoutner.com [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029055 signature.asc Description: This is a digitally signed message part.
Bug#1029055: lintian: Lintian does not recognize the AppStream's metainfo.xml MIT license is the same as Debian's Expat license
Package: lintian Version: 2.115.3 Severity: wishlist Debian has recently started requesting that graphical programs install AppStream metainfo.xml files. https://appstream.debian.org/sid/main/issues/electrum.html The AppStream specification has a very restricted listed of possible licenses for the metainfo.xml file. FSFAP MIT 0BSD CC0-1.0 CC-BY-3.0 CC-BY-4.0 CC-BY-SA-3.0 CC-BY-SA-4.0 GFDL-1.1 GFDL-1.2 GFDL-1.3 BSL-1.0 FTL FSFUL https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license No specific text is given for what they mean by the MIT license. The MIT license is a bit problematic because there are more than one license that has been called the MIT license over the years. https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants https://www.gnu.org/licenses/license-list.en.html#Expat When most people say MIT they mean Expat, so it is standard in the industry to assume that when no specific text is given MIT == Expat. Debian prefers the Expat name to the MIT name for this reason. https://www.debian.org/legal/licenses/mit The documentation for the Debian machine-readable copyright file says the following. "There are many versions of the MIT license. Please use Expat instead, when it matches." https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name The Electrum package, which is licensed upstream as MIT, is listed as Expat in debian/copyright according to the instructions in the copyright format and because the upstream MIT license matches exactly the Debian legal Expat example. Because the AppStream metainfo.xml file does not allow the use of the Expat name, or it will fail validation with appstreamcli, I licensed the metainfo.xml file as MIT. This made it easy to submit it upstream, which has already accepted it for the next release. In the meantime, I included the metadata.xml file in the debian directory for the current release. However, Lintian complained that Expat != MIT. I considered creating a override, but according to the instruction at https://lintian.debian.org/manual/index.html#overrides it seemed more appropriate to file a bug against Lintian, as every time there is an AppStream file with a MIT license this will create a false positive if matched against Expat. To work around this, I currently created a duplicate section in debian/copyright, which doesn't seem like an efficient long-term solution. https://salsa.debian.org/sorenstoutner/electrum/-/blob/master/debian/copyright I personally wish that those creating licenses had been more careful about the naming thereof. Secondarily, I wish that AppStream had followed best practices and allowed the use of the Expat name. However, given that neither of those things are within my control, the next best option is to make Lintian smart enough to work around this specific situation. This was originally discussed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002053 but was moved to this separate bug report because it didn't end up being the same root problem.
Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)
On Sunday, January 15, 2023 5:17:10 PM MST Axel Beckert wrote: > > Debian, of course, prefers the Expat name as it is more precise. > > According to > https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a > nd_SPDX SPDX does not have the Expat license. They do have though the "MIT > License" (the one and only ;-), so that would imply that they're not the > same license. Anyone who tells you there is a One And Only MIT License is trolling you. ;) https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants[1] "The name 'MIT License' is potentially ambiguous. The Massachusetts Institute of Technology has been using many licenses for software since its creation; for example, MIT offers four licensing options for the FFTW[2] C source code library, one of which is the GPL v2.0[3] and the other three of which are not open-source[4]. The term 'MIT License' has also been used to refer to the *Expat License* (used for the XML parsing library Expat[5]) and to the *X11 License* (also called '*MIT/X Consortium License'*; used for X Window System[6] by the MIT X Consortium[7]). Furthermore, the 'MIT License' as published by the Open Source Initiative[8] is the same as the Expat License. Due to this differing use of terms, some prefer to avoid the name 'MIT License'. The Free Software Foundation[9] argues that the term is misleading and ambiguous, and recommends against its use.” https://www.gnu.org/licenses/license-list.html#Expat[10] As noted in the quote above, and in the second link, the license that is most commonly called the MIT License is what is appropriately referred to as the Expat license in Debian. https://www.debian.org/legal/licenses/mit[11] If you prefer I can open a separate bug about this issue, as it is my belief that Lintian should consider an Expat license in debian/copyright to not be a conflict with a MIT license in an AppStream metainfo.xml file. -- Soren Stoutner so...@stoutner.com [1] https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants [2] https://en.wikipedia.org/wiki/FFTW [3] https://en.wikipedia.org/wiki/GNU_General_Public_License [4] https://en.wikipedia.org/wiki/Open-source_software [5] https://en.wikipedia.org/wiki/Expat_(library) [6] https://en.wikipedia.org/wiki/X_Window_System [7] https://en.wikipedia.org/wiki/MIT_X_Consortium [8] https://en.wikipedia.org/wiki/Open_Source_Initiative [9] https://en.wikipedia.org/wiki/Free_Software_Foundation [10] https://www.gnu.org/licenses/license-list.html#Expat [11] https://www.debian.org/legal/licenses/mit signature.asc Description: This is a digitally signed message part.
Bug#1002053: Also causes problems for MIT and Expat licenses
The same basic problem also occurs with MIT and Expat licenses. The specification for the AppStream metadata file only has a few options, one of them being MIT and none of them being Expat. https://freedesktop.org/software/appstream/docs/chap-Quickstart.html#qsr-app-contents[1] Debian, of course, prefers the Expat name as it is more precise. Which leads to this Lintian warning: inconsistent-appstream-metadata-license debian/metainfo.xml (mit != expat) [debian/ copyright] -- Soren Stoutner so...@stoutner.com [1] https://freedesktop.org/software/appstream/docs/chap-Quickstart.html#qsr-app-contents signature.asc Description: This is a digitally signed message part.
