Bug#1076797: DDPO: VCS column marked as failed unexpectedly
Package: qa.debian.org Severity: normal Dear Maintainer, On my DDPO page [1] there are some packages for which the VCS column shows "failed" however, the "debian/latest" branch in itself didn't fail but the pipeline failure is on another branch "ubuntu/focal" for instance. In the pipeline list of salsa, it is even not the latest job that failed which could have explained that, but the one on ubuntu/focal. Moreover, if I delete the failing pipeline from salsa (this is the case for php-datto-json-rpc), it is still marked as "failed" (I deleted the job yesterday and today DDPO still shows it as "failed"). Packages are: php-datto-json-rpc php-datto-json-rpc-http php-giggsey-libphonenumber I would have expected the failure statut be the one of the branch that holds the debian tree (eg. main, master, debian/latest...) or as an alternative the branch marked as "default" in salsa. [1] https://qa.debian.org/developer.php?email=fabstz...@yahoo.fr Regards
Bug#1031047: keepass2: proposal for help
Hello, I would be happy to see someone adopting or NMUing the package. For your information I also made a merge request in addition to the debdiff at https://salsa.debian.org/dotnet-team/keepass2/-/merge_requests/2 Also, if you have interest in it, you could also maintain the KeepassRPC plugin for which I made a package under my account at: https://salsa.debian.org/bastif/keepass2-plugin-keepassrpc/ Its repo could be moved to the dotnet-team group. Regards Fab Le lundi 22 juillet 2024, 15:46:56 CEST Roland Mas a écrit : > Hi, > > A client of mine requires an updated version of keepass2 in their > Debian-based systems. I've been able to build 2.57 with a slightly > updated version of Fab Stz's debdiff (from > https://bugs.debian.org/1031047), and I propose to either adopt the > package or NMU it. I'm not too fluent in CLI stuff, which is why I'd > like to get reviewers, but if nobody objects I'd like to review the bug > reports, check if I can reproduce with the old version and if they're > fixed with the new one, and upload a fixed package first to experimental > then to unstable (then backports once it migrates to testing). > > What's your view? > > Roland.
Bug#1070561: php-league-csv: FTBFS with phpunit 11: There were 23 PHPUnit errors
Hello, This would be fixed by updating to latest upstream, however we have to wait until Debian migrates to a newer phpunit because changes for phpunit10/11 are not backward compatible with phpunit 9. Best regards On Mon, 6 May 2024 11:18:08 -0300 Athos Ribeiro wrote: > Source: php-league-csv > Version: 9.9.0-1 > Severity: normal > Justification: FTBFS > Tags: trixie sid ftbfs > User: pkg-php-p...@lists.alioth.debian.org > Usertags: phpunit11 > > Hi, > > phpunit 11 is out and is now available in experimental. During a test rebuild, > php-league-csv was found to fail to build with this new phpunit version. > > To reproduce this locally, you need to install phpunit from experimental on an > unstable system or build chroot. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > phpunit --exclude-group network > > PHPUnit 11.1.2 by Sebastian Bergmann and contributors. > > > > Runtime: PHP 8.2.18 > > Configuration: /<>/phpunit.xml > > > > ... 63 / 155 ( 40%) > > ... 126 / 155 ( 81%) > > sbb,one > > . 155 / 155 (100%) > > > > Time: 00:00.895, Memory: 18.00 MB > > > > There were 23 PHPUnit errors: > > > > 1) League\Csv\AbstractCsvTest::testGetInputBOM > > The data provider specified for League\Csv\AbstractCsvTest::testGetInputBOM is invalid > > Data Provider method League\Csv\AbstractCsvTest::bomProvider() is not static > > > > /<>/src/AbstractCsvTest.php:92 > > > > 2) League\Csv\AbstractCsvTest::testStreamFilterMode > > The data provider specified for League\Csv\AbstractCsvTest::testStreamFilterMode is invalid > > Data Provider method League\Csv\AbstractCsvTest::provideCsvFilterTestingData() is not static > > > > /<>/src/AbstractCsvTest.php:242 > > > > 3) League\Csv\AbstractCsvTest::testGetPathname > > The data provider specified for League\Csv\AbstractCsvTest::testGetPathname is invalid > > Data Provider method League\Csv\AbstractCsvTest::getPathnameProvider() is not static > > > > /<>/src/AbstractCsvTest.php:475 > > > > 4) League\Csv\AbstractCsvTest::testGetPathnameRemote > > The data provider specified for League\Csv\AbstractCsvTest::testGetPathnameRemote is invalid > > Data Provider method League\Csv\AbstractCsvTest::getPathnameProviderRemote() is not static > > > > /<>/src/AbstractCsvTest.php:489 > > > > 5) League\Csv\CharsetConverterTest::testConvertOnlyStringField > > The data provider specified for League\Csv\CharsetConverterTest::testConvertOnlyStringField is invalid > > Data Provider method League\Csv\CharsetConverterTest::converterProvider() is not static
Bug#1039787: php-league-csv: FTBFS with phpunit 10: make[1]: *** [debian/rules:42: override_dh_auto_test] Error 1
Hello, This would be fixed by updating to latest upstream, however we have to wait until Debian migrates to a newer phpunit because changes for phpunit10 are not backward compatible with phpunit 9. Best regards On Wed, 28 Jun 2023 18:08:21 -0300 Athos Ribeiro wrote: > Source: php-league-csv > Version: 9.9.0-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: pkg-php-p...@lists.alioth.debian.org > Usertags: phpunit > > Hi, > > We will start the phpunit 10 transition in unstable soon. During a test > rebuild, php-league-csv was found to FTBFS. > > To reproduce this locally, you need to install the phpunit 10 package (and any > other dependency, which should also be available) from experimental on an > unstable system or build chroot. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > phpunit --exclude-group network > > PHPUnit 10.2.2 by Sebastian Bergmann and contributors. > > > > Runtime: PHP 8.2.7 > > Configuration: /<>/phpunit.xml > > > > D.. 63 / 225 ( 28%) > > ... 126 / 225 ( 56%) > > ... 189 / 225 ( 84%) > > .sbb,one > > ...225 / 225 (100%) > > > > Time: 00:00.966, Memory: 18.00 MB > > > > There was 1 PHPUnit test runner warning: > > > > 1) XDEBUG_MODE=coverage or xdebug.mode=coverage has to be set > > > > -- > > > > There was 1 PHPUnit test runner deprecation: > > > > 1) Your XML configuration validates against a deprecated schema. Migrate your XML configuration using "--migrate-configuration"! > > > > -- > > > > 23 tests triggered 23 PHPUnit deprecations: > > > > 1) League\Csv\AbstractCsvTest::testGetInputBOM > > Data Provider method League\Csv\AbstractCsvTest::bomProvider() is not static > > > > /<>/src/AbstractCsvTest.php:92 > > > > 2) League\Csv\AbstractCsvTest::testStreamFilterMode > > Data Provider method League\Csv\AbstractCsvTest::provideCsvFilterTestingData() is not static > > > > /<>/src/AbstractCsvTest.php:242 > > > > 3) League\Csv\AbstractCsvTest::testGetPathname > > Data Provider method League\Csv\AbstractCsvTest::getPathnameProvider() is not static > >
Bug#1070526: php-datto-json-rpc: FTBFS with phpunit 11: Test results may not be as expected because the XML configuration file did not pass validation [debian/rules:37: override_dh_auto_test] Error 1
Hello Athos, Thanks for the report, As far as I understand these are just deprecation warnings. Is it expected that deprecation warnings make the tests fail? BTW, is there any migration date/plan to phpunit 11? About 1 year ago, rapid migration to phpunit10 was mentionned, but nothing happened. Regards On Mon, 6 May 2024 11:13:08 -0300 Athos Ribeiro wrote: > Source: php-datto-json-rpc > Version: 6.1.0-2 > Severity: normal > Justification: FTBFS > Tags: trixie sid ftbfs > User: pkg-php-p...@lists.alioth.debian.org > Usertags: phpunit11 > > Hi, > > phpunit 11 is out and is now available in experimental. During a test rebuild, > php-datto-json-rpc was found to fail to build with this new phpunit version. > > To reproduce this locally, you need to install phpunit from experimental on an > unstable system or build chroot. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > phpunit > > PHPUnit 11.1.2 by Sebastian Bergmann and contributors. > > > > Runtime: PHP 8.2.18 > > Configuration: /<>/phpunit.xml.dist > > > > DD..D 33 / 33 (100%) > > > > Time: 00:00.009, Memory: 8.00 MB > > > > There was 1 PHPUnit test runner warning: > > > > 1) Test results may not be as expected because the XML configuration file did not pass validation: > > > > Line 9: > > - Element 'log': This element is not expected. > > > > Line 11: > > - Element 'filter': This element is not expected. > > > > > > WARNINGS! > > Tests: 33, Assertions: 33, Warnings: 1, Deprecations: 1. > > make[1]: *** [debian/rules:37: override_dh_auto_test] Error 1 > > > The full build log is available at > http://people.ubuntu.com/~athos-ribeiro/rebuilds/phpunit11/0/php-datto-json-rpc/php-datto-json-rpc_6.1.0-2+rebuild1714366106_amd64-2024-04-29T04:48:27Z.build > >
Bug#1075722: google-android-platform-tools-installer: fail to install
Hello I can't reproduce this on my system on bookworm. However if I run these on Bookworm I get: $ echo "sample text" | LC_ALL=C TMPDIR=missing_dir tac tac: failed to create temporary file in 'missing_dir': No such file or directory $ echo "sample text" | LC_ALL=C tac sample text On both testing & sid there is no such error reported by tac. So maybe there is a difference in the tac (coreutils) program between bookworm & testing. However in the /usr/share/google-android-platform-tools-installer/Makefile at the time the tac command is run, the dir /usr/lib/android-sdk/platform- tools/ should already exist and consequently the case where "android-sdk/ platform-tools" doesn't exist shouldn't happen at all. So the problem might be somewhere else. Can you please try to purge the package, then completely delete /usr/lib/ android-sdk/platform-tools/ (in case it still exists) and then install it again? If this is still causing trouble on your system, maybe you could try renaming TMPDIR in debian/Makefile (in the source package) to something else and try again. Please report back if this fixes your issue. A patch would be welcome. Regards Fab On Wed, 03 Jul 2024 19:35:40 +0200 Paride Desimone wrote: > Package: google-android-platform-tools-installer > Version: 33.0.3+1675172738 > Severity: important > X-Debbugs-Cc: nos...@inventati.org > > Dear Maintainer, > > I try to install google-android-platform-tools-installer. But the installation > fail. > > paride@arda:~$ sudo apt install google-android-platform-tools-installer > Lettura elenco dei pacchetti... Fatto > Generazione albero delle dipendenze... Fatto > Lettura informazioni sullo stato... Fatto > I seguenti pacchetti aggiuntivi saranno inoltre installati: > google-android-licenses > I seguenti pacchetti NUOVI saranno installati: > google-android-licenses google-android-platform-tools-installer > 0 aggiornati, 2 installati, 0 da rimuovere e 0 non aggiornati. > È necessario scaricare 4.060 B/25,9 kB di archivi. > Dopo quest'operazione, verranno occupati 18,9 MB di spazio su disco. > Continuare? [S/n] > Scaricamento di:1 http://deb.debian.org/debian bookworm/non-free amd64 google- > android-licenses all 1675172738 [4.060 B] > Recuperati 4.060 B in 0s (25,5 kB/s) > Preconfigurazione dei pacchetti in corso > Selezionato il pacchetto google-android-licenses non precedentemente > selezionato. > (Lettura del database... 570561 file e directory attualmente installati.) > Preparativi per estrarre .../google-android-licenses_1675172738_all.deb... > Estrazione di google-android-licenses (1675172738)... > Selezionato il pacchetto google-android-platform-tools-installer non > precedentemente selezionato. > Preparativi per estrarre .../google-android-platform-tools- > installer_33.0.3+1675172738_amd64.deb... > Estrazione di google-android-platform-tools-installer (33.0.3+1675172738)... > Configurazione di google-android-licenses (1675172738)... > Configurazione di google-android-platform-tools-installer > (33.0.3+1675172738)... > make: ingresso nella directory «/var/cache/google-android-platform-tools- > installer» > cd /var/cache/google-android-platform-tools-installer && \ > su nobody -s /bin/sh -c "wget --continue > https://dl.google.com/android/repository/platform-tools_r33.0.3-linux.zip -O > platform-tools_r33.0.3-linux.zip.tmp && mv platform-tools_r33.0. > 3-linux.zip.tmp platform-tools_r33.0.3-linux.zip" > --2024-07-03 19:28:42-- https://dl.google.com/android/repository/platform-> > tools_r33.0.3-linux.zip > risoluzione di dl.google.com (dl.google.com)... 216.58.206.46, > 2a00:1450:4001:831::200e > connessione a dl.google.com (dl.google.com)|216.58.206.46|:443... connesso. > richiesta http inviata, in attesa di risposta... 200 ok > lunghezza: 7505569 (7,2m) [application/zip] > salvataggio in: «platform-tools_r33.0.3-linux.zip.tmp» > > platform-tools_r33.0.3-linux.zip.tmp > 100% [=>] > 7,16M 7,68MB/sin 0,9s > > 2024-07-03 19:28:43 (7,68 MB/s) - «platform-tools_r33.0.3-linux.zip.tmp»
Bug#1073562: qa.debian.org: (Some?) popcon statistic graphs not updated since May
Thanks for having investigated & fixed this. Unfortunately there are still issues: For example on [1] while the graph is now updated correctly, the written stats in the table are all "0". Besides that, on the list of package of "maintainer" [2], the popcon column is now empty. [1] https://qa.debian.org/popcon.php?package=freefilesync [2] https://qa.debian.org/developer.php?email=fabstz-it%40yahoo.fr Regards Fab
Bug#1074785: RFS: freefilesync/13.7-1 [RC] -- Cross-platform file sync utility with GUI (GPL release)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "freefilesync": * Package name : freefilesync Version : 13.7-1 Upstream contact : Zenju * URL : https://freefilesync.org/ * License : GPL-3.0, GPL-3.0 with MAME, FreeFileSync, Snes9x, ePSXe exception * Vcs : https://salsa.debian.org/bastif/freefilesync Section : utils The source builds the following binary packages: freefilesync - Cross-platform file sync utility with GUI (GPL release) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/freefilesync/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/f/freefilesync/ freefilesync_13.7-1.dsc Changes since the last upload: freefilesync (13.7-1) unstable; urgency=medium . [ Fab Stz ] * update header of d/p/pkg-config.patch * d/control: remove arc from the list or architectures . [ Jhonny Oliveira ] * New upstream version 13.4 * d/patches/*.patch Remove fix-gtk3... and refresh all patches . [ Fab Stz ] * New upstream version 13.5 * New upstream version 13.6 * refresh patches * drop ffs_traditional_view.patch * d/control: bump Standards-Version to 4.7.0 (no change required) * d/p/libcurl_improve_supported_error_codes.patch: support curl 8.8.0 (Closes: #1072759) * New upstream version 13.7 * refresh patches Regards, -- Fab Stz
Bug#1070017: google-android-installers: depends on pre-64 libraries
Hello, I already had a look at this and IMHO there is nothing to do as the package is amd64 only and as libasound2 will pull in the correct t64 anyway. Moreover the package doesn't build any binary, it is a wrapper that downloads upstreams binary, so nothing ca be changed here I think. Unless further notice or advice on how to fix that, I will close this in some time. Regards Fab On Sun, 28 Apr 2024 17:35:23 +0200 Sebastian Ramacher wrote: > Source: google-android-installers > Version: =1710437545-4 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > google-android-installers builds binary packages that depend on shared > libraries (at least libasound2) that were renamed as part of the t64 > transition. Please update the dependencies accordingly. > > Cheers > -- > Sebastian Ramacher > >
Bug#1069820: [Android-tools-devel] Bug#1069820: android-sdk-meta: Split udev rules in separate package
Hello, I like the idea. It would also be useful for those using google-android-*- installer packages. May I suggest using this line in Build-Depends instead of only systemd-dev? systemd-dev (>= 253-3~) | udev (<< 253-3~), It would permit to build your package also on bookworm and previous releases. Regards Fab Le jeudi 25 avril 2024, 12:39:30 CEST Andrea Pappacoda via Android-tools-devel a écrit : > Source: android-sdk-meta > Version: 28.0.2+10 > Severity: wishlist > Tags: patch
Bug#1069643: dh_installman: doesn't honor nodoc build profile
> I do not see anything in that commit that suggests that `dh_installman` > does not honor `nodoc`. What I am getting is that you wish that `dh` > would skip hook targets for any program that might react to `nodoc` > similar to `nostrip`. > > Assuming we agree on this being the ask, my answer that there is a > difference here in that `dh_installman` (etc.) operates during a `nodoc` > build. That is, I cannot omit the calls to `dh_installman` or > `dh_installdoc` as they still have things to do (such as re-encode any > manpage installed to UTF-8 or install the copyright file into the > package). Therefore, I do not plan to extend the `dh` feature to `nodoc` > as it cannot tell whether said hook target might still be useful under > `nodoc` or not. > > As an example based off mount-zip, it would not be unreasonable for you > to unconditionally remove the manpage rather than installing the > pre-built one in `execute_before_dh_installman` and then conditionally > regenerate it as an alternative to conditionally removing it and > conditionally regenerating it. We do not have a common baseline for this > and therefore `dh` cannot "optimize" for either way. > > Best regards, > Niels > > PS: Note that the semantics of `nodoc` are very poorly defined compared > to `nostrip` or `nocheck`, which does not help either. Unlike the > others, `nodoc` is just "skip problematic documentation" rather than > "skip all documentation" (case in point being we still one copyright > files, NEWS files, and changelogs) If dh_installman doesn't support nodoc as written in its manpage, then maybe the manpage should be changed. For instance this may have to be removed since I was mistaken by it. "In compat 11 and later, it also supports the default searchdir plus -- sourcedir like dh_install(1) and has the advantage that it respects the nodoc build profile (unlike dh_install(1))." Regards Fab
Bug#1069643: dh_installman: doesn't honor nodoc build profile
Control: tags -1 - moreinfo
Le lundi 22 avril 2024 10:12:45 CEST, vous avez écrit :
> Control: tags -1 moreinfo
>
> On Mon, 22 Apr 2024 09:37:55 +0200 Fab Stz wrote:
> > Package: debhelper
> > Version: 13.15.3
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > According to dh_installman, it should honor the nodoc build profile.
> > However, it doesn't. As well as execute_before_dh_install.
> >
> >
> > [...]
>
> Hi,
>
> Could you please provide the URL the packaging in question where it does
> not work along with a bit more details of what you expected vs. what you
> see? Notably, `dh_installman` will allow documentation to be missing
> during `nodoc` but it will still operate on the documentation there is
> (that has been the way of handling `nodoc` from the start in `debhelper`).
>
> Additionally, I am not sure what the `execute_before_dh_install` remark
> is about. The `execute_before_dh_install` hook targeted is not affected
> by `nodoc`. First off because it is `dh_install` and not one of the
> `dh_install{docs,man}` and secondly, most of the documentation commands
> still do something even under `nodoc` (unlike `dh_strip` with
> `nostrip`), so the commands are still run. Thirdly, even if it was to be
> affected, it would react to `DEB_BUILD_OPTIONS` and not the profile
> (which are not the same thing and that has been confusing people a lot
> at least with nocheck)
>
> Best regards,
> Niels
Hello Niels,
Oh sorry, I lost my initial mail and had to rewrite it and wasn't careful
enough. I meant execute_before_dh_installman and not
execute_before_dh_install.
Concerning your remark about DEB_BUILD_OPTIONS, it is populated automatically
with the value of the DEB_BUILD_PROFILES as displayed in the output of dpkg-
buildpackage. At least for nocheck & nodoc.
You can try with https://salsa.debian.org/bastif/mount-zip
Latest commit includes execute_before_dh_installman
For now, as a workaround in that target, I added a test on whether build
profile has "nodoc" set. But if you remove that "ifneq...", and build with
"nodoc" it will still invoke both dh_installmal &
execute_before_dh_installman. However, if one doesn't have pandoc installed
(eg because the "nodoc" build profile doesn't require it as dependency), that
target will fail because it is invoked, while I expected it to be skipped.
If you wish to check with that package, I suggest you also build with
"nocheck", because there is a test that takes a lot of time.
Regards
Fab
Bug#1069643: dh_installman: doesn't honor nodoc build profile
Package: debhelper Version: 13.15.3 Severity: normal Dear Maintainer, According to dh_installman, it should honor the nodoc build profile. However, it doesn't. As well as execute_before_dh_install. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debhelper depends on: ii autotools-dev20220109.1 ii dh-autoreconf20 ii dh-strip-nondeterminism 1.13.1-1 ii dpkg 1.21.22 ii dpkg-dev 1.21.22 ii dwz 0.15-1 ii file 1:5.44-3 ii libdebhelper-perl13.11.4 ii libdpkg-perl 1.21.22 ii man-db 2.11.2-2 ii perl 5.36.0-7+deb12u1 ii po-debconf 1.0.21+nmu1 debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make -- no debconf information
Bug#1069610: RFS: modernizr/3.13.0-0.1 [NMU] -- JavaScript library to detect HTML5 and CSS3 features in the user's browser
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "modernizr": It's an NMU and the changes of this NMU have already been approved and merged in salsa at https://salsa.debian.org/js-team/modernizr * Package name : modernizr Version : 3.13.0-0.1 Upstream contact : [fill in name and email of upstream] * URL : https://modernizr.com/ * License : MIT * Vcs : https://salsa.debian.org/js-team/modernizr Section : javascript The source builds the following binary packages: libjs-modernizr - JavaScript library to detect HTML5 and CSS3 features in the user's browser To access further information about this package, please visit the following URL: https://mentors.debian.net/package/modernizr/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/modernizr/ modernizr_3.13.0-0.1.dsc Changes since the last upload: modernizr (3.13.0-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release Closes: #1001203, #1067130 * d/control: - update Build-Depends - update standards version to 4.6.2, no changes needed. * d/copyright: - add/update entries for the new version - remove now useless Files-Excluded (file is not shipped anymore) * d/install: don't install feature-detects/* anymore * d/rules: - build modernizr.js with upstream's new build script - remove repack suffix (not needed anymore) and add it to d/watch * d/s/lintian-overrides: add lintian-overrides for 'source-is-missing' errors (files contain test data) * d/watch: update URL & methodology, add repacksuffix here instead of d/rules (but not used because there is no Files-Excluded in d/copyright) * add missing source file 'file.js' and add patch to use it. Regards,
Bug#1069609: RFS: mount-zip/1.0.14-1 [RFP] -- Read-only FUSE file system for ZIP archives
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "mount-zip": * Package name : mount-zip Version : 1.0.14-1 Upstream contact : François Degros * URL : https://github.com/google/mount-zip * License : GPL-3.0-or-later * Vcs : https://salsa.debian.org/bastif/mount-zip Section : utils The source builds the following binary packages: mount-zip - Read-only FUSE file system for ZIP archives To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mount-zip/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mount-zip/mount-zip_1.0.14-1.dsc Changes for the initial release: mount-zip (1.0.14-1) unstable; urgency=medium . * Initial release. Closes: #1068638 Regards,
Bug#1068824: welle.io: Remove myself from uploaders
Package: welle.io Version: 2.4+ds-2 Severity: normal Tags: patch Dear Maintainer, Please remove me from the Uploaders list, either with the attached patch, or by merging the MR at: https://salsa.debian.org/debian-hamradio-team/welle.io/-/merge_requests/5 Patch also available at: https://salsa.debian.org/debian-hamradio-team/welle.io/-/merge_requests/ 5.patch -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages welle.io depends on: ii libairspy0 1.0.10-2+b1 ii libasound2 1.2.8-1+b1 ii libc6 2.36-9+deb12u4 ii libfaad2 2.10.1-1 ii libfftw3-single3 3.3.10-1 ii libgcc-s1 12.2.0-14 ii libmp3lame03.100-6 ii libmpg123-01.31.2-1 ii libqt5charts5 5.15.8-2 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus55.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5multimedia5 5.15.8-2 ii libqt5multimedia5-plugins 5.15.8-2 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickcontrols2-5 5.15.8+dfsg-2 ii libqt5widgets5 5.15.8+dfsg-11 ii librtlsdr0 0.6.0-4 ii libsoapysdr0.8 0.8.1-3 ii libstdc++6 12.2.0-14 ii qml-module-qt-labs-settings5.15.8+dfsg-3 ii qml-module-qtcharts5.15.8-2 ii qml-module-qtgraphicaleffects 5.15.8-2 ii qml-module-qtquick-controls5.15.8-2 ii qml-module-qtquick-controls2 5.15.8+dfsg-2 ii qml-module-qtquick-dialogs 5.15.8-2 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick-localstorage5.15.8+dfsg-3 ii qml-module-qtquick-privatewidgets 5.15.8-2 ii qml-module-qtquick-templates2 5.15.8+dfsg-2 ii qml-module-qtquick-window2 5.15.8+dfsg-3 ii qml-module-qtquick25.15.8+dfsg-3 welle.io recommends no packages. welle.io suggests no packages. -- no debconf information From 0a8b301271c09be6c69bf6989b79f542dd19bf74 Mon Sep 17 00:00:00 2001 From: bastif <9907-bas...@users.noreply.salsa.debian.org> Date: Thu, 11 Apr 2024 16:47:12 + Subject: [PATCH] d/control: remove myself from Uploaders. --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 2168e65..e79eaef 100644 --- a/debian/control +++ b/debian/control @@ -2,7 +2,7 @@ Source: welle.io Section: hamradio Priority: optional Maintainer: Debian Hamradio Maintainers -Uploaders: Gürkan Myczko , Fab Stz +Uploaders: Gürkan Myczko Build-Depends: cmake, debhelper-compat (= 13), libairspy-dev, -- GitLab
Bug#1067130: modernizr: NMU or update to latest upstream 3.12 or 3.13
Hello, Today, I upladed the NMU to mentors.d.n: https://mentors.debian.net/package/modernizr/ Would someone sponsor it? Regards Fab
Bug#1068736: ITP: mount-zip -- recent FUSE file system for ZIP archives (read-only access)
Hello bartm, What's wrong? I thought there must be both RFP & ITP and that the package has to close an ITP and not a RFP? Rgds Fab On Wed, 10 Apr 2024 06:52:54 + ba...@debian.org wrote: > close 1068736 > stop > there is already an RFP > RFP 1068638 > ITP 1068736 > >
Bug#1068736: ITP: mount-zip -- recent FUSE file system for ZIP archives (read-only access)
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mount-zip Version : 1.0.7 Upstream Contact: François Degros * URL : https://github.com/google/mount-zip * License : GPL-3.0-or-later Programming Lang: C++ Description : recent FUSE file system for ZIP archives (read-only access) mount-zip is a tool allowing to open, explore and extract ZIP archives. . mount-zip mounts a ZIP archive as a read-only FUSE file system, which can then be explored and read by any application. . mount-zip aspires to be an excellent ZIP mounter. It starts quickly, uses little memory, decodes encrypted files, and provides on-the-go decompression and caching for maximum efficiency. . The mount point should be an empty directory. If the mount point doesn't exist yet, mount-zip creates it first. If no mount point is provided, mount-zip creates one in the same directory as the ZIP archive. . It is an alternative to fuse-zip. Compared to fuse-zip, its performance is improved, but write mode was dropped. Version 1.0.0 was forked from fuse-zip 0.7.2 See also RFP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068638
Bug#1068734: pandoc: Please update to latest version to fix bug in generation of manpages
Source: pandoc Severity: wishlist Dear Maintainer, As of today, the manpages generated by pandoc are somehow incompatible with the latest groff (1.23.0) that is in Debian. That leads to issues reported by lintian: groff-message troff::111: warning: cannot select font 'C' [usr/share/man/man1/mount-zip.1.gz:4] This was fixed in pandoc version 3.1.7 Upstream bug report is at https://github.com/jgm/pandoc/issues/9020 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068638: RFP: mount-zip -- FUSE file system for ZIP archives (read-only)
Package: wnpp Severity: wishlist * Package name: mount-zip Version : 1.0.12 Upstream Contact: François Degros * URL : https://github.com/google/mount-zip * License : GPL3 Programming Lang: C++ Description : FUSE file system for ZIP archives (read-only) This package provides an alternative to fuse-zip. Compared to fuse-zip, it seams reading performance is improved, but write mode was dropped. Version 1.0.0 was forked from fuse-zip 0.7.2 mount-zip is a tool allowing to open, explore and extract ZIP archives. mount-zip mounts a ZIP archive as a read-only FUSE file system, which can then be explored and read by any application. mount-zip aspires to be an excellent ZIP mounter. It starts quickly, uses little memory, decodes encrypted files, and provides on-the-go decompression and caching for maximum efficiency. The mount point should be an empty directory. If the mount point doesn't exist yet, mount-zip creates it first. If no mount point is provided, mount-zip creates one in the same directory as the ZIP archive. /// It provides an alternative to fuse-zip. Compared to fuse-zip, it seams reading performance is improved, but write mode was dropped. This can be useful when short on space and we don't want to unzip the file but still access its content on the fly, for example on gitlab ci runners, or any docker/CI instance.
Bug#1066055: re: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic
FWIW: - I created an issue upstream at [1] - rust-symphonia is required by czkawka #1032030 (+ MR at [2]) [1] https://github.com/pdeljanov/Symphonia/issues/254 [2] https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/583
Bug#1068312: piuparts: Error when Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged' (bullseye)
Package: piuparts Version: 1.4.1 Severity: normal Dear Maintainer, I have a CI job on salsa running piuparts with bullseye. Recently it started failing with this error: 0m4.3s DUMP: Enabling dpkg --force-unsafe-io. Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged' ln: failed to create symbolic link '/bin/sync': File exists 0m4.3s ERROR: Command failed (status=1): ['chroot', '/tmp/tmpoj1y68a1', 'eatmydata', 'tmp/scripts/post_setup_force-unsafe-io'] Enabling dpkg --force-unsafe-io. Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged' ln: failed to create symbolic link '/bin/sync': File exists Maybe this is somehow related to the latest changes in 1.4.1 mentioned as "also fix /bin/sync diversion for bookworm"? Log is attached. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages piuparts depends on: ii debootstrap 1.0.128+nmu2+deb12u1 pn debsums ii dpkg 1.21.22 ii libjs-sphinxdoc 5.3.0-4 ii lsb-release 12.0-1 ii lsof 4.95.0-1 ii mount2.38.1-5+deb12u1 pn piuparts-common pn python pn python-debian ii python3 3.11.2-1+b1 ii python3-debian 0.1.49 Versions of packages piuparts recommends: pn adequate Versions of packages piuparts suggests: pn docker.io ii schroot1.6.13-3+b2 salsa-piuparts-log.gz Description: application/gzip
Bug#1067130: modernizr: NMU or update to latest upstream 3.12 or 3.13
The merge request is now updated with the headers. Le 28 mars 2024 19:56:13 GMT+01:00, "Bastien Roucariès" a écrit : >Le jeudi 28 mars 2024, 18:36:54 UTC Fab Stz a écrit : >> To build modernizr an additional source file is required (file.js) this file >> is added to missing-sources (it comes from the npm package of the same name >> from npm server or from upstreams repo). It is required by the build script >> from upstream. >> >> The patch is only here to use that file. That way there is no need to create >> a Debian package for it (packaging npm nodes is beyond my knowledge and I'm >> not really interested in doing that). >> >> Concerning your other question, I don't understand it. The binary packages >> only ships the js & min.js, not the build script. The missing sources is >> required only by the build script iirc. > >Thanks, this should be documented in: >- the comment at the begiging of missing-source/file >- the header of patch see https://dep-team.pages.debian.net/deps/dep3/ >> >> >> Le 28 mars 2024 19:23:08 GMT+01:00, "Bastien Roucariès" a >> écrit : >> >Le jeudi 28 mars 2024, 18:16:09 UTC Fab Stz a écrit : >> >> Hello Bastien, >> >> >> >> Iirc not so many packages depend on it and none seems to use the files >> >> that are not shipped anymore in the binary package (the individual >> >> 'rules'). >> >> >> >> Concerning the build maybe you could look at d/rules on the merge >> >> request. It uses upstream's build script that builds the complete js. >> > >> >I do not understand: >> >- please document the patch using dep format >> >- explain how the build script do not ship in /usr/share >> >debian/missingsources >> > >> >bastien >> >> >> >> Regards >> >> Fab >> >> >> >> Le 28 mars 2024 18:54:27 GMT+01:00, "Bastien Roucariès" >> >> a écrit : >> >> >Le jeudi 28 mars 2024, 17:21:48 UTC Fab Stz a écrit : >> >> >> Dear Maintainers, >> >> >> >> >> >> I'm thinking of doing an NMU for the package by updating it to >> >> >> 3.13.0-0.1. The >> >> >> MR is now open since July 2023 and this bug referencing it has been >> >> >> existing >> >> >> for about 10 days (in case the MR wouldn't have been noticed). >> >> >> >> >> >> There is also bug >> >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001203 >> >> >> which request a newer version since 2021. >> >> >> >> >> >> BTW, I would require a sponsor to upload the NMU. >> >> >> >> >> >> Do you have advice or comment on this?* >> >> > >> >> >What is the state of reverse depends ? >> >> > >> >> >How does it build ? >> >> > >> >> >Bastien >> >> >> >> >> >> Regards >> >> >> Fab >> >> >> >> >> >> On Tue, 19 Mar 2024 08:58:23 +0100 Fab Stz >> >> >> wrote: >> >> >> > Source: modernizr >> >> >> > Version: update >> >> >> > Severity: wishlist >> >> >> > Tags: patch >> >> >> > >> >> >> > Dear Maintainer, >> >> >> > >> >> >> > Please update to latest upstream version 3.12 or 3.13 >> >> >> > >> >> >> > For 3.12 I created a merge request on the VCS at >> >> >> > >> >> >> > https://salsa.debian.org/js-team/modernizr/-/merge_requests/2 >> >> >> > >> >> >> > There is also one for 2.* in >> >> >> > >> >> >> > https://salsa.debian.org/js-team/modernizr/-/merge_requests/1 >> >> >> > >> >> >> > You just have to choose which you prefer or both one after the other. >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- System Information: >> >> >> > Debian Release: 12.5 >> >> >> > APT prefers stable-updates >> >> >> > APT policy: (991, 'stable-updates'), (991, 'stable-security'), >> >> >> > (991, >> >> >> > 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), >> >> >> > (390, >> >> >> > 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), >> >> >> > (379, >> >> >> > 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), >> >> >> > (94, >> >> >> > 'unstable'), (93, 'experimental') >> >> >> > Architecture: amd64 (x86_64) >> >> >> > Foreign Architectures: i386 >> >> >> > >> >> >> > Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) >> >> >> > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, >> >> >> > TAINT_UNSIGNED_MODULE >> >> >> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), >> >> >> > LANGUAGE=fr:en_US >> >> >> > Shell: /bin/sh linked to /usr/bin/dash >> >> >> > Init: systemd (via /run/systemd/system) >> >> >> > LSM: AppArmor: enabled >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> =<3776087.mvXUDI8C0e.ref@debian> >> >> >> <3776087.mvXUDI8C0e@debian> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >
Bug#1067130: modernizr: NMU or update to latest upstream 3.12 or 3.13
To build modernizr an additional source file is required (file.js) this file is added to missing-sources (it comes from the npm package of the same name from npm server or from upstreams repo). It is required by the build script from upstream. The patch is only here to use that file. That way there is no need to create a Debian package for it (packaging npm nodes is beyond my knowledge and I'm not really interested in doing that). Concerning your other question, I don't understand it. The binary packages only ships the js & min.js, not the build script. The missing sources is required only by the build script iirc. Le 28 mars 2024 19:23:08 GMT+01:00, "Bastien Roucariès" a écrit : >Le jeudi 28 mars 2024, 18:16:09 UTC Fab Stz a écrit : >> Hello Bastien, >> >> Iirc not so many packages depend on it and none seems to use the files that >> are not shipped anymore in the binary package (the individual 'rules'). >> >> Concerning the build maybe you could look at d/rules on the merge request. >> It uses upstream's build script that builds the complete js. > >I do not understand: >- please document the patch using dep format >- explain how the build script do not ship in /usr/share debian/missingsources > >bastien >> >> Regards >> Fab >> >> Le 28 mars 2024 18:54:27 GMT+01:00, "Bastien Roucariès" a >> écrit : >> >Le jeudi 28 mars 2024, 17:21:48 UTC Fab Stz a écrit : >> >> Dear Maintainers, >> >> >> >> I'm thinking of doing an NMU for the package by updating it to >> >> 3.13.0-0.1. The >> >> MR is now open since July 2023 and this bug referencing it has been >> >> existing >> >> for about 10 days (in case the MR wouldn't have been noticed). >> >> >> >> There is also bug >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001203 >> >> which request a newer version since 2021. >> >> >> >> BTW, I would require a sponsor to upload the NMU. >> >> >> >> Do you have advice or comment on this?* >> > >> >What is the state of reverse depends ? >> > >> >How does it build ? >> > >> >Bastien >> >> >> >> Regards >> >> Fab >> >> >> >> On Tue, 19 Mar 2024 08:58:23 +0100 Fab Stz wrote: >> >> > Source: modernizr >> >> > Version: update >> >> > Severity: wishlist >> >> > Tags: patch >> >> > >> >> > Dear Maintainer, >> >> > >> >> > Please update to latest upstream version 3.12 or 3.13 >> >> > >> >> > For 3.12 I created a merge request on the VCS at >> >> > >> >> > https://salsa.debian.org/js-team/modernizr/-/merge_requests/2 >> >> > >> >> > There is also one for 2.* in >> >> > >> >> > https://salsa.debian.org/js-team/modernizr/-/merge_requests/1 >> >> > >> >> > You just have to choose which you prefer or both one after the other. >> >> > >> >> > >> >> > >> >> > -- System Information: >> >> > Debian Release: 12.5 >> >> > APT prefers stable-updates >> >> > APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, >> >> > 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), >> >> > (390, >> >> > 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, >> >> > 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, >> >> > 'unstable'), (93, 'experimental') >> >> > Architecture: amd64 (x86_64) >> >> > Foreign Architectures: i386 >> >> > >> >> > Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) >> >> > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >> >> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), >> >> > LANGUAGE=fr:en_US >> >> > Shell: /bin/sh linked to /usr/bin/dash >> >> > Init: systemd (via /run/systemd/system) >> >> > LSM: AppArmor: enabled >> >> > >> >> > >> >> > >> >> > >> >> > >> >> =<3776087.mvXUDI8C0e.ref@debian> >> >> <3776087.mvXUDI8C0e@debian> >> >> >> >> >> >> >> > >> >
Bug#1067130: modernizr: NMU or update to latest upstream 3.12 or 3.13
Hello Bastien, Iirc not so many packages depend on it and none seems to use the files that are not shipped anymore in the binary package (the individual 'rules'). Concerning the build maybe you could look at d/rules on the merge request. It uses upstream's build script that builds the complete js. Regards Fab Le 28 mars 2024 18:54:27 GMT+01:00, "Bastien Roucariès" a écrit : >Le jeudi 28 mars 2024, 17:21:48 UTC Fab Stz a écrit : >> Dear Maintainers, >> >> I'm thinking of doing an NMU for the package by updating it to 3.13.0-0.1. >> The >> MR is now open since July 2023 and this bug referencing it has been existing >> for about 10 days (in case the MR wouldn't have been noticed). >> >> There is also bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001203 >> which request a newer version since 2021. >> >> BTW, I would require a sponsor to upload the NMU. >> >> Do you have advice or comment on this?* > >What is the state of reverse depends ? > >How does it build ? > >Bastien >> >> Regards >> Fab >> >> On Tue, 19 Mar 2024 08:58:23 +0100 Fab Stz wrote: >> > Source: modernizr >> > Version: update >> > Severity: wishlist >> > Tags: patch >> > >> > Dear Maintainer, >> > >> > Please update to latest upstream version 3.12 or 3.13 >> > >> > For 3.12 I created a merge request on the VCS at >> > >> > https://salsa.debian.org/js-team/modernizr/-/merge_requests/2 >> > >> > There is also one for 2.* in >> > >> > https://salsa.debian.org/js-team/modernizr/-/merge_requests/1 >> > >> > You just have to choose which you prefer or both one after the other. >> > >> > >> > >> > -- System Information: >> > Debian Release: 12.5 >> > APT prefers stable-updates >> > APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, >> > 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, >> > 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, >> > 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, >> > 'unstable'), (93, 'experimental') >> > Architecture: amd64 (x86_64) >> > Foreign Architectures: i386 >> > >> > Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) >> > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), >> > LANGUAGE=fr:en_US >> > Shell: /bin/sh linked to /usr/bin/dash >> > Init: systemd (via /run/systemd/system) >> > LSM: AppArmor: enabled >> > >> > >> > >> > >> > >> =<3776087.mvXUDI8C0e.ref@debian> >> <3776087.mvXUDI8C0e@debian> >> >> >> >
Bug#1067130: modernizr: NMU or update to latest upstream 3.12 or 3.13
Dear Maintainers, I'm thinking of doing an NMU for the package by updating it to 3.13.0-0.1. The MR is now open since July 2023 and this bug referencing it has been existing for about 10 days (in case the MR wouldn't have been noticed). There is also bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001203 which request a newer version since 2021. BTW, I would require a sponsor to upload the NMU. Do you have advice or comment on this? Regards Fab On Tue, 19 Mar 2024 08:58:23 +0100 Fab Stz wrote: > Source: modernizr > Version: update > Severity: wishlist > Tags: patch > > Dear Maintainer, > > Please update to latest upstream version 3.12 or 3.13 > > For 3.12 I created a merge request on the VCS at > > https://salsa.debian.org/js-team/modernizr/-/merge_requests/2 > > There is also one for 2.* in > > https://salsa.debian.org/js-team/modernizr/-/merge_requests/1 > > You just have to choose which you prefer or both one after the other. > > > > -- System Information: > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, > 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, > 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, > 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, > 'unstable'), (93, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE=fr:en_US > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > > > > =<3776087.mvXUDI8C0e.ref@debian> <3776087.mvXUDI8C0e@debian>
Bug#1067156: python-mkdocs: readthedocs theme links are not up-to-date
Source: python-mkdocs Version: theme Severity: normal Dear Maintainer, I noticed some things in the readthedocs theme that might be a bug. I just looked at the usage of modernizr of the package but am not a user of mkdocs. What I noticed: - d/copyright has some File-Excluded in mkdocs/themes/readthedocs/ - the supposedly excluded files are linked to in d/mkdocs.links. However the files listed are actually not used anymore by the version of readthedocs currently in 1.5.3 of upstream. Some examples are: mkdocs/themes/readthedocs/js/jquery-2.1.1.min.js mkdocs/themes/readthedocs/js/modernizr-2.8.3.min.js But "fonts" and "css" dirs are affected as well. - 1.5.3 uses readthedocs v 1.2.0 and the mkdocs package depends on sphinx-rtd- theme-common which is presently version 2.0.0, so file structure of readthedocs in mkdocs will not be concordant with the one provided by sphinx-rtd-theme -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1067130: modernizr: Please update to latest upstream 3.12 or 3.13
Source: modernizr Version: update Severity: wishlist Tags: patch Dear Maintainer, Please update to latest upstream version 3.12 or 3.13 For 3.12 I created a merge request on the VCS at https://salsa.debian.org/js-team/modernizr/-/merge_requests/2 There is also one for 2.* in https://salsa.debian.org/js-team/modernizr/-/merge_requests/1 You just have to choose which you prefer or both one after the other. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1066051: openjdk-8: make package usable on systems without t64 packages
Source: openjdk-8 Version: 8u402-ga-2 Severity: normal Dear Maintainer, I usually install openjdk-8 from unstable on bookworm. However this is not possible anymore because now it depends on t64 packages. Would it be possible to still install it on systems without t64 by updating the dependencies/build-depends? Thanks -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1065344: RM: google-android-patcher-4-installer -- ROM; NBS
Package: ftp.debian.org Severity: normal Since src:android-google-installers doesn't produce anymore the google-android-patcher-4-installer binary package, please kindly help to remove bin:google-android-patcher-4-installer from unstable. It is already removed from testing. Thank you Fab
Bug#1065304: mesa: 24.0.2 requires libdrm-dev >=2.4.119
Source: mesa Version: 24.0.2 requires libdrm-dev >=2.4.119 Severity: normal Dear Maintainer, While trying to build 24.0.2-1 on bookworm, mesa reported this issue. Maybe you would like to update d/control to the new required version of libdrm- dev Dependency libdrm_intel found: NO found 2.4.114 but need: '>=2.4.119' Dependency lookup for libdrm_intel with method 'pkgconfig' failed: Invalid version, need 'libdrm_intel' ['>=2.4.119'] found '2.4.114'. CMake binary for host machine is cached as not found Dependency lookup for libdrm_intel with method 'cmake' failed: CMake binary for machine host machine not found. Giving up. Run-time dependency libdrm_intel found: NO ../meson.build:1674:6: ERROR: Dependency lookup for libdrm_intel with method 'pkgconfig' failed: Invalid version, need 'libdrm_intel' ['>=2.4.119'] found '2.4.114'. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1063469: freefilesync: crash when opening "Options" dialog with wxwidgets3.0 & gtk3 (eg. jammy, bullseye, focal)
Package: freefilesync Version: 13.3-1~bpo22.04~1 Severity: normal If the screen resolution is 1024x768 (or any other width but a height of 768) and if the default Gtk theme named Adwaita is in use you may encounter a crash when opening the options window (Tools menu | Options). It is likely this is in relation with wxwidgets-3.0 + gtk3 + some specific theme installed. It seems related to computation of the sizes for display on screen. Maybe this happens in other conditions or screen resolutions depending on your theme and layout. This problem doesn't exist with : - another GTK Theme (another than Adwaita). It works with Numix, Yuyo, Greybird... The command would be (provided you have installed the package for it: numix-gtk-theme). GTK_THEME=Numix FreeFileSync - upstream's binary which is built with wxwidgets-3.2 + gtk2. - the debian package when it is built with wxwidgets-3.2 + gtk3 (it is the case since bookworm). The last line called in FreeFileSync before the crash (which happens in a function of glib2 and/or gtk3) is this one: https://github.com/hkneptune/FreeFileSync/blob/v13.3/FreeFileSync/Source/ui/ small_dlgs.cpp#L1522 `m_gridCustomCommand->SetColSize(0, w0);` backtrace attached (made on jammy) -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freefilesync depends on: ii libc6 2.36-9+deb12u4 ii libcurl4 7.88.1-10+deb12u5 ii libgcc-s1 12.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-03.24.38-2~deb12u1 ii libselinux1 3.4-1+b6 ii libssh2-1 1.10.0-3+b1 ii libssl1.1 1.1.1w-0+deb11u1 ii libstdc++612.2.0-14 ii libwxbase3.0-0v5 3.0.5.1+dfsg-2 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.13.dfsg-1 freefilesync recommends no packages. freefilesync suggests no packages. -- no debconf information trace_for_sigsegv.txt.gz Description: application/gzip
Bug#1062775: lintian: watchfile v3 + DEB_EXT in dversionmangle leads to debian-watch-not-mangling-version
Package: lintian Version: 2.116.3 Severity: normal Tags: patch Dear Maintainer, Consider this watchfile: version=3 # Search the version number on this page https://download.qt.io/development_releases/qt/6.7/ # Then use downloadurlmangle to transform it to the URL to the archive. # # We don't use repacksuffix=+ds because in salsa-ci we want to have the +ds suffix, even if we use --no-exclusion (ie even if we ignore Files-Excluded) # opts="uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/, \ dversionmangle=s/@DEB_EXT@//, \ oversionmangle=s/$/\+ds.1/, \ downloadurlmangle=s/\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/\/$1\/ single\/qt- everywhere-src-$1\.tar\.xz/, \ filenamemangle=s/.*\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/qt- everywhere-src-$1\.tar\.xz/" \ https://download.qt.io/development_releases/qt/6\.(?:[\d\.]*)/ ([\d\.]*-.*)/ debian bash debian/scripts/repack.sh Lintian will output: debian-watch-not-mangling-version opts="uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/, dversionmangle=s/@DEB_EXT@//, oversionmangle=s/$/\+ds.1/, downloadurlmangle=s/\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/\/$1\/ single\/qt- everywhere-src-$1\.tar\.xz/, filenamemangle=s/.*\/([\d\.]*(-((RC|rc|pre|dev|beta|alpha)\d*))?)\/$/qt- everywhere-src-$1\.tar\.xz/" https://download.qt.io/development_releases/qt/6\.(?:[\d\.]*)/ ([\d\.]*-.*)/ debian bash debian/scripts/repack.sh [debian/watch:12] I suspect this is because lintian considers that @DEB_EXT@ is only valid for a watchfile version >= 4 (see $DMANGLES_AUTOMATICALLY variable), but according to source code in uscan, it seems it requires version >= 2. BTW, I noticed that: - if I use version=4 with @DEB_EXT@, the lintian warning is gone - if I use version=3 + dversionmangle=auto, the lintian warning is gone as well. But version=3 with @DEB_EXT@ triggers the warning. I'm attaching a patch without being sure that it is the correct way to fix the issue, but when it is applied lintian doesn't report a warning. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.21.22 ii dpkg-dev1.21.22 ii file1:5.44-3 ii gettext 0.21-12 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.28-2 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.35-1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.21.22 ii libemail-address-xs-perl1.05-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004004-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.634-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.003+ds-1 ii libsereal-encoder-perl
Bug#1061575: php-codeigniter-framework: FTBFS with python 3.12
Hello Athos, Thank you for your patches. Does changing to SPHINXBUILD=/usr/bin/sphinx-build still use cilexer we installed by this command? "../../debian/build-doc/pythonvenv/bin/python" (I'm not very documented on python3/venv internals and so on) Regards Fab On Fri, 26 Jan 2024 15:10:11 -0300 Athos Ribeiro wrote: > Source: php-codeigniter-framework > Version: 3.1.13+dfsg1-2 > Severity: normal > Tags: patch > X-Debbugs-Cc: athos.ribe...@canonical.com > > Dear Maintainer, > > This package FTBFS with python 3.12. > > $ python setup.py install > > is no longer supported. > > I am attaching a fix proposal that should get the package to build for > python 3.12. =<170629261164.191837.10637237603982032509.reportbug@castor>
Bug#1060808: rustc: debian/rules source_orig-stage0 fails on 1.70.0
Package: rustc Version: 1.70.0+dfsg1 Severity: normal Dear Maintainer, I was trying to run this script as suggested in debian/README.source LC_ALL=C upstream_bootstrap_arch="i386" debian/rules source_orig-stage0 But it fails as follows: QUILT_PATCHES=debian/patches quilt push -aq; x=$?; if [ $x = 2 ]; then exit 0; else exit $x; fi File series fully applied, ends at patch ubuntu-ignore-arm-doctest.patch /usr/bin/make -f debian/rules clean make[1]: Entering directory '/build/rustc-1.70.0+dfsg1' dh clean --parallel debian/rules override_dh_auto_clean make[2]: Entering directory '/build/rustc-1.70.0+dfsg1' rm -f -rf build tmp debian/cargo_home config.stamp config.mk Makefile rm -f -rf debian/rustc-tests.log debian/config.toml debian/*.stamp rm -f -rf src/bootstrap/bootstrap.pyc src/bootstrap/__pycache__ src/etc/__pycache__/ config.toml make[2]: Leaving directory '/build/rustc-1.70.0+dfsg1' debian/rules override_dh_clean make[2]: Entering directory '/build/rustc-1.70.0+dfsg1' # Upstream contains a lot of these dh_clean -XCargo.toml.orig make[2]: Leaving directory '/build/rustc-1.70.0+dfsg1' make[1]: Leaving directory '/build/rustc-1.70.0+dfsg1' debian/make_orig-stage0_tarball.sh Traceback (most recent call last): File "/build/rustc-1.70.0+dfsg1/debian/get-stage0.py", line 31, in main(sys.argv) File "/build/rustc-1.70.0+dfsg1/debian/get-stage0.py", line 28, in main bootstrap.bootstrap(False) File "/build/rustc-1.70.0+dfsg1/src/bootstrap/bootstrap.py", line 858, in bootstrap build.verbose = args.verbose != 0 AttributeError: 'bool' object has no attribute 'verbose' make: *** [debian/rules:483: source_orig-stage0] Error 1 -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rustc depends on: ii binutils 2.40-2 ii gcc 4:12.2.0-3 ii libc6 2.36-9+deb12u3 ii libc6-dev [libc-dev] 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstd-rust-dev 1.63.0+dfsg1-2 Versions of packages rustc recommends: ii cargo0.66.0+ds1-1 ii llvm-14 1:14.0.6-12 Versions of packages rustc suggests: pn clang-14 pn lld-14 -- no debconf information
Bug#1059080: freefilesync: Please add support for loong64
Hello, Could you confirm that it builds on that arch and provide a patch please ? Regards Le 20 décembre 2023 03:59:11 GMT+01:00, wuruilong a écrit : >Source: freefilesync >Version: 12.5-1 >Severity: normal >X-Debbugs-Cc: wuruil...@loongson.cn > >Dear Maintainer, > >Please add support for loong64 arch in the debian/control file. > >wuruilong > >-- System Information: >Debian Release: trixie/sid > APT prefers unreleased > APT policy: (500, 'unreleased'), (500, 'unstable') >Architecture: loong64 (loongarch64) > >Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads) >Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set >Shell: /bin/sh linked to /usr/bin/dash >Init: unable to detect
Bug#1052444: ITA: librepfunc -- set of C++ classes and utilities for building multimedia tools
Hello Phil, Thank you for your ITA. Apostolos recently showed also some interest in adopting the packages (librepfunc & w-scan-cpp) although, IIRC he's a beginner in packaging. I gave him some directions. Maybe you could get in touch and discuss how you want to go further on this matter. As of today the packages are up to date in salsa but since I'm not a DD (and not a DM) I can't upload anyway. So you may upload them to unstable. For now the repo is located under my account. Would you like permission on the repo, or maybe you could move it to the "debian" group, or "vdr-team" group (where the older w-scan is located). There is a particularity with w-scan-cpp that one has to be aware of: it is a multiple upstream tarball package. So it uses the "component" feature for the "vdr" directory. You can grab more info on components in uscan(1) manpage. Because of this we have to ensure that upstream released the files (w-scan-cpp & third party packages) with same version number. See d/watch. The d/gbp.conf file already takes care of that aspect. Upstream author is very kind and was very helpful in adapting his software with the changes that were required to create the package. For the last update he even asked me if the changes he planned would be fine and how they would impact the Debian package, or how to coordinate on the impact. If you need assitance, please don't hesitate. Regards Fab Le lundi 11 décembre 2023, 19:43:01 CET Phil Wyett a écrit : > Hi Fab, Apostolos and all, > > My name is Phil Wyett (kathenas) and I am in the process of taking over as > the maintainer of 'librepfunc'. > > I would ask that no commits or releases take place without my approval until > the transition is complete. > > I thank you for your assistance with this transition and hope we will work > together in the future. > > Regards > > Phil
Bug#1053321: RM: google-android-platform-33-upsidedowncakeprivacysandbox-installer -- ROM; NVIU
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: google-android-install...@packages.debian.org Control: affects -1 + src:google-android-installers Please remove: google-android-platform-33-upsidedowncakeprivacysandbox-installer because it is now replaced by: google-android-platform-34-upsidedowncakeprivacysandbox-installer Actually the package should have been named with "34" since the beginning. Regards Fab
Bug#1052444: RFA: w-scan-cpp -- DVB channel scanner (successor of w_scan)
Package: wnpp
Severity: normal
X-Debbugs-Cc: w-scan-...@packages.debian.org
Control: affects -1 + src:w-scan-cpp
I request an adopter for the w-scan-cpp package (and it's dependency
src:librepfunc see RFA #1052443 )
My device (USB TV/DVB Dongle - RTL_SDR based) which I used with w-scan-cpp
broke (I don't plan to buy a new one), so I don't have use of w_scan_cpp and
can't test the package anymore. I can still update it, but can't guarantee
that the produced binary actually works.
The package description is:
This is w_scan_cpp - a dtv channel scanner based on VDR (www.tvdr.de)
and its Plugins.
.
w_scan_cpp supports
.
DVB-T(2), DVB-C, DVB-S(2), ATSC(VSB && QAM)
SAT>IP
SCR ("Unicable") EN-50494 & EN-50607 (aka. "JESS")
DiSEqC switches
DiSEqC rotors (Standard & USALS)
various output formats
VDR channels.conf
VLC channels.xspf
dtv scan tables for dvbv5-scan
channels.dat for the SAT>IP "DVB Viewer Lite for Windows"
(..)
.
Some features are more recent than those of w_scan, other outdated features
were not ported.
Bug#1052443: RFA: librepfunc -- set of C++ classes and utilities for building multimedia tools (dev files)
Package: wnpp Severity: normal X-Debbugs-Cc: librepf...@packages.debian.org Control: affects -1 + src:librepfunc I request an adopter for the librepfunc package (and it's dependent src:w-scan-cpp) My device (USB TV/DVB Dongle - RTL_SDR based) which I used with w-scan-cpp broke, so I don't have use of w_scan_cpp and can't test the package anymore. I can still update it, but can't guarantee that the produced binary actually works. The package description is: This is a collection of utilities and functions used for example in w-scan- cpp . This package contains the files required to build other packages.
Bug#1050065: ITP: sphinxcontrib-phpdomain -- Sphinx "phpdomain" extension
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: sphinxcontrib-phpdomain Version : 0.11.2 Upstream Contact: Mark Story * URL : https://pypi.python.org/pypi/sphinxcontrib-phpdomain * License : BSD-2-clause Programming Lang: Python Description : Sphinx "phpdomain" extension This package contains the PHP Domain extension for the Sphinx documentation system. This extension provides language support for PHP. This package is required by php-codeigniter-framework (ITP: #471583)
Bug#1040215: ITP: kalkun -- Open Source Web based SMS Manager
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: kalkun Version : 0.8.0 Upstream Contact: Fab Stz * URL : https://kalkun.sourceforge.io/ * License : GPL-3+ Programming Lang: PHP Description : Open Source Web based SMS Manager Kalkun is an open source web-based SMS (Short Message Service) manager. It uses gammu-smsd (part of gammu family) as SMS gateway engine to deliver and retrieve messages from your phone/modem. . Features: - Multi User feature - Display SMS by conversation - Multiple modems - Gammu & non gammu (aka alternate gateways). Non gammu is send-out only - Send SMS repeatedly with SMS Bomber - Add SMS Advertise to message - SMS templates - Spam Filter - various APIs to sens SMS from other application - SMS Merge. Package useful when associated with gammu-smsd for which it is a gui Maintained by myself or by team (php team?)
Bug#1040167: openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which is not in Debian
Package: openjdk-8-jre-headless Version: 8u382~b04-1 Severity: important Dear Maintainer, Updating from 8u372-ga-1 which was the previous version in unstable is not possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8 However libjpeg8 is not to be found in Debian Expected behaviour: correct dependencies or adding the missing libjpeg8 to Debian? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (991, 'stable-security'), (991, 'stable'), (990, 'proposed- updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable- updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20230103 ii java-common 0.74 ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libfontconfig12.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s1 12.2.0-14 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-22.14-2 ii libnss3 2:3.87.1-1 ii libpcsclite1 1.9.9-2 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u1 ii libxext6 2:1.3.4-1+b1 ii libxi62:1.8-1+b1 ii libxrender1 1:0.9.10-1.1 ii libxtst6 2:1.2.3-1.1 ii util-linux2.38.1-5+b1 ii zlib1g1:1.2.13.dfsg-1 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-6 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.15.1-3 -- no debconf information
Bug#992976: uscan: mode=git refs/heads/ instruction scans for tags instead, and fails
Hello,
I'm facing this too.
```d/watch
version=4
options=uversionmangle=s/-?([^\d.]+)/~$1/;tr/A-Z/a-z/,\
mode=git,gitmode=full,gitexport=all \
https://github.com/bcit-ci/CodeIgniter \
heads/master
```
Upstream's main branch is "develop". uscan takes this one instead of the
requested "master" branch
```$ uscan --debug --safe
uscan info: uscan (version 2.23.4) See uscan(1) for help
uscan info: Scan watch files in .
uscan debug: Found ./debian
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="php-codeigniter-framework"
version="0.0~git20230407.63d037565-1" (as seen in debian/changelog)
uscan info: package="php-codeigniter-framework"
version="0.0~git20230407.63d037565" (no epoch/revision)
uscan info: ./debian/changelog sets package="php-codeigniter-framework"
version="0.0~git20230407.63d037565"
uscan info: Process watch file at: debian/watch
package = php-codeigniter-framework
version = 0.0~git20230407.63d037565
pkg_dir = .
uscan debug: parse line options=uversionmangle=s/-?([^\d.]+)/~$1/;tr/A-Z/a-
z/,mode=git,gitmode=full,gitexport=all https://github.com/bcit-ci/CodeIgniter
heads/master
uscan info: opts: uversionmangle=s/-?([^\d.]+)/~$1/;tr/A-Z/a-
z/,mode=git,gitmode=full,gitexport=all
uscan info: line: https://github.com/bcit-ci/CodeIgniter heads/master
uscan info: Parsing uversionmangle=s/-?([^\d.]+)/~$1/;tr/A-Z/a-z/
uscan info: Parsing mode=git
uscan info: Parsing gitmode=full
uscan info: Parsing gitexport=all
uscan info: line: https://github.com/bcit-ci/CodeIgniter heads/master
uscan debug: $self->{'pgpmode'}=default, $self->{'pgpsigurlmangle'}=undef
uscan info: Last orig.tar.* tarball version (from debian/changelog):
0.0~git20230407.63d037565
uscan info: Last orig.tar.* tarball version (dversionmangled):
0.0~git20230407.63d037565
uscan debug: watch file has:
$base= https://github.com/bcit-ci/CodeIgniter
$filepattern = heads/master
$lastversion = 0.0~git20230407.63d037565
$action =
mode = git
pgpmode = default
versionmode = newer
$site= https://github.com/bcit-ci/CodeIgniter
$basedir =
uscan debug: line: search()
uscan debug: Execute: git clone --quiet --bare https://github.com/bcit-ci/
CodeIgniter ../php-codeigniter-framework-temporary.2454317.git...
uscan info: Looking at $base = https://github.com/bcit-ci/CodeIgniter with
$filepattern = heads/master found
$newfile = heads/master
$newversion = 0.0~git20230407.63d037565
$lastversion = 0.0~git20230407.63d037565
uscan debug: line: get_upstream_url()
uscan info: Upstream URL(+tag) to download is identified ashttps://
github.com/bcit-ci/CodeIgniter heads/master
uscan debug: line: get_newfile_base()
uscan info: Filename (filenamemangled) for downloaded file: php-codeigniter-
framework-0.0~git20230407.63d037565.tar.xz
uscan debug: line: cmp_versions()
uscan info: Newest version of php-codeigniter-framework on remote site is
0.0~git20230407.63d037565, local version is 0.0~git20230407.63d037565
uscan info: => Package is up to date from:
=> https://github.com/bcit-ci/CodeIgniter heads/master
uscan debug: line: download_file_and_sig()
uscan debug: line: mkorigtargz()
uscan debug: Keep git repo (../php-codeigniter-framework-temporary.
2454317.git)
uscan info: Scan finished
```
Maybe the problem has something to do with this command?
Execute: git clone --quiet --bare https://github.com/bcit-ci/CodeIgniter ../
php-codeigniter-framework-temporary.2454317.git...
Regards
Fab
On Wed, 25 Aug 2021 22:15:42 +0200 Romain Porte wrote:
> Package: devscripts
> Version: 2.21.3
> Severity: important
> X-Debbugs-Cc: deb...@microjoe.org
>
> Dear Maintainer,
>
> While trying to use uscan to scan for upstream commits on a specific
> branch instead of the default on, I tried to use refs/heads/ as
> explained in the uscan man page.
>
> Here is the content of the d/watch file I am using:
>
> version=4
> opts="mode=git, gitmode=full, pgpmode=none, pretty=8.994+git%cd.%h,
repack, compression=xz" \
> https://bitbucket.org/jpcgt/flatcam.git \
> refs/heads/Beta
>
> However when running uscan, the invocation fails with the following
> message:
>
> uscan info: uscan (version 2.21.3) See uscan(1) for help
> uscan info: Scan watch files in .
> uscan info: Check debian/watch and debian/changelog in .
> uscan info: package="flatcam" version="8.994+ds-1" (as seen in debian/
changelog)
> uscan info: package="flatcam" version="8.994+ds" (no epoch/revision)
> uscan info: ./debian/changelog sets package="flatcam" version="8.994+ds"
> uscan info: Process watch file at: debian/watch
> package = flatcam
> version = 8.994+ds
> pkg_dir = .
> uscan info: opts: mode=git, gitmode=full, pgpmode=none,
pretty=8.994+git%cd.%h, repack, compression=xz
> uscan info: line: https://bitbucket.org/jpcgt/flatcam.git refs/heads/
Beta
> uscan info: Parsing
Bug#1037986: uscan: support date/time conversion in *versionmangle
Hi, if "e" flag in 's///e' were supported, I could use: uversionmangle=s/(.*)/`date --date='$1' +%s`/e With a perl call from shell it would be: echo "2023-06-08 14:28:41.521115" | perl -p -e 's/(.*)/`date --date="$1" +%s`/ e' Full watch file for information (with s///e) version=4 opts="searchmode=plain, \ uversionmangle=s/(.*)/`date --date='$1' +%s`/e, \ downloadurlmangle=s#.*#https://dl.google.com/android/repository/ repository2-1.xml#, \ filenamemangle=s#.*#repository2-1.xml#" \ https://dl.google.com/android/repository/repository2-1.xml Generated\son\s(.*) \swith\sADRT Full watch file for information (with date) version=4 opts="searchmode=plain, \ uversionmangle=date//%s/, \ downloadurlmangle=s#.*#https://dl.google.com/android/repository/ repository2-1.xml#, \ filenamemangle=s#.*#repository2-1.xml#" \ https://dl.google.com/android/repository/repository2-1.xml Generated\son\s(.*) \swith\sADRT Regards Fab
Bug#1037986: uscan: support date/time conversion in *versionmangle
Package: devscripts
Version: 2.21.3+deb11u1
Severity: wishlist
Tags: patch
Dear Maintainer,
I'm maintaining a package for which things are bit unusual. I would like that
on tracker.debian.org & qa.debian.org which rely on
https://qa.debian.org/cgi-bin/watch report if there is a new upstream version
available.
In my case, I need to get the latest version from an XML file.
This files contains a date/time which is used to determine the version of the
package in debian in the format of a timestamp.
In the usptream XML there is:
The debian package version would be
1686227321
Now concerning uscan, I would need the ability to convert
from "2023-06-08 14:28:41.521115" to "1686227321"
I tried with `uversionmangle="s///e"` (ie with 'e' flag), something like this
`'s/(.*)/({ eval "date --date$1 +%s"})/ee'` but this returns: 'flags must
consist of "gix"'.
And maybe this would be some security issue to support that "e" flag.
Maybe it would be safer to support a "date" operation in mangle formulas.
You can find attached a patch which would add support for:
`uversionmangle=date//%s/`
It converts the input to the format given in parameter (here %s) and run date
--date='input' +%d
You may update/fix/improve that patch, perl is rather foreign to me. I just
wanted to check if that would be possible.
That feature may also be useful for those having to convert date/time between
upstream format & debian format. For example like:
-MM-DD → MMDD
DD-MM- → MMDD
DDMM → MMDD
-MM-DD → TIMESTAMP
TIMESTAMP → MMDD
...
Regards
Fab
-- Package-specific info:
--- /etc/devscripts.conf ---
Empty.
--- ~/.devscripts ---
Empty.
-- System Information:
Debian Release: 11.7
APT prefers oldstable-updates
APT policy: (991, 'oldstable-updates'), (991, 'oldstable-security'), (991,
'oldstable'), (990, 'oldstable-proposed-updates'), (380, 'oldoldstable'),
(379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (93,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages devscripts depends on:
ii dpkg-dev 1.20.12
ii fakeroot 1.25.3-1.1
ii file 1:5.39-3
ii gnupg 2.2.27-2+deb11u2
ii gpgv 2.2.27-2+deb11u2
ii libc6 2.31-13+deb11u6
ii libfile-dirlist-perl 0.05-2
ii libfile-homedir-perl 1.006-1
ii libfile-touch-perl0.11-1
ii libfile-which-perl1.23-1
ii libipc-run-perl 20200505.0-1
ii libmoo-perl 2.004004-1
ii libwww-perl 6.52-1
ii patchutils0.4.2-1
ii perl 5.32.1-4+deb11u2
ii python3 3.9.2-3
ii sensible-utils0.0.14
ii wdiff 1.2.2-2+b1
Versions of packages devscripts recommends:
ii apt 2.2.4
ii curl7.74.0-1.3+deb11u7
ii dctrl-tools 2.24-3+b1
ii debian-keyring 2021.07.26
ii dput1.1.0
ii equivs 2.3.1
ii libdistro-info-perl 1.0
ii libdpkg-perl1.20.12
ii libencode-locale-perl 1.05-1.1
ii libgit-wrapper-perl 0.048-1
ii libgitlab-api-v4-perl 0.26-1
ii liblist-compare-perl0.55-1
ii liblwp-protocol-https-perl 6.10-1
ii libsoap-lite-perl 1.27-1
ii libstring-shellquote-perl 1.04-1
ii libtry-tiny-perl0.30-1
ii liburi-perl 5.08-1
ii licensecheck3.1.1-2
ii lintian 2.104.0
ii man-db 2.9.4-2
ii patch 2.7.6-7
ii pristine-tar1.49
ii python3-apt 2.2.1
ii python3-debian 0.1.39
ii python3-magic 2:0.4.20-3
ii python3-requests2.25.1+dfsg-2
ii python3-unidiff 0.5.5-2
ii python3-xdg 0.27-2
ii strace 5.10-1
ii unzip 6.0-26+deb11u1
ii wget1.21-1+deb11u1
ii xz-utils5.2.5-2.1~deb11u1
Versions of packages devscripts suggests:
pn adequate
pn at
ii autopkgtest 5.16
pn bls-standalone
ii build-essential 12.9
pn check-all-the-things
pn cvs-buildpackage
ii debhelper 13.3.4
pn devscripts-el
pn diffoscope
pn disorderfs
pn dose-extra
Bug#1035966: unblock: google-android-installers/1675172738
Control: tags 1035966 - moreinfo Le vendredi 12 mai 2023, 10:07:46 CEST Sebastian Ramacher a écrit : > Control: tags -1 moreinfo confirmed > > On 2023-05-11 21:48:18 +0200, Fab Stz wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package google-android-installers > > > > At the time of writing this, I'm waiting for my sponsor to upload the > > latest version to unstable. > > Please remove the moreinfo tag once the package is available in > unstable. > > Cheers
Bug#1035966: unblock: google-android-installers/1675172738
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package google-android-installers
At the time of writing this, I'm waiting for my sponsor to upload the latest
version to unstable. It is also tagged in the VCS if you want to upload it
yourself. See:
https://salsa.debian.org/google-android-tools-team/google-android-installers
https://salsa.debian.org/google-android-tools-team/google-android-installers/-/tags/debian%2F1675172738
[ Reason ]
(Explain what the reason for the unblock request is.)
A RC bug was filed towards the package: #1035713
[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
[ Tests ]
(What automated or manual tests cover the affected code?)
- I tested that the binary package doesn't have any broken symbolic links, and
that the symbolic links target the correct file.
- I tested that the change didn't break installation with the other binary
packages.
[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
No particular risk AFAIK.
[ 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 testing
[ Other info ]
(Anything else the release team should know.)
At the time of writing this, I'm waiting for my sponsor to upload the latest
version to unstable. It is also tagged in the VCS if you want to upload it
yourself.
unblock google-android-installers/1675172738
diff -Nru google-android-installers-1675172737/debian/changelog google-android-installers-1675172738/debian/changelog
--- google-android-installers-1675172737/debian/changelog 2023-04-09 22:31:58.0 +0200
+++ google-android-installers-1675172738/debian/changelog 2023-05-09 17:35:00.0 +0200
@@ -1,3 +1,9 @@
+google-android-installers (1675172738) unstable; urgency=medium
+
+ * Makefile: fix broken symbolic links (Closes: #1035713)
+
+ -- Fab Stz Tue, 09 May 2023 17:35:00 +0200
+
google-android-installers (1675172737) unstable; urgency=medium
* cmdline-tools: set Architecture to 'amd64 i386'
diff -Nru google-android-installers-1675172737/for-postinst/default/Makefile google-android-installers-1675172738/for-postinst/default/Makefile
--- google-android-installers-1675172737/for-postinst/default/Makefile 2023-04-09 22:31:58.0 +0200
+++ google-android-installers-1675172738/for-postinst/default/Makefile 2023-05-09 17:35:00.0 +0200
@@ -49,6 +49,34 @@
cd $(DL_DIR) && unzip -ouq $(DL_DIR)/$(PKG_SOURCE); \
fi
+# Search for broken symbolic links & fix them
+ @if [ $$(unzip -Z -1 $(DL_DIR)/$(PKG_SOURCE) | cut -d '/' -f1 | sort -u | wc -l) -gt 1 ]; then \
+ ZIP_ROOT_DIR=$(TRG_DIR) ;\
+ else \
+ ZIP_ROOT_DIR=$$(unzip -Z -1 $(DL_DIR)/$(PKG_SOURCE) | head -1 | cut -d '/' -f 1) ;\
+ fi && \
+ BROKEN_SYMLINKS=$$(cd $(DL_DIR)/$$ZIP_ROOT_DIR && find -xtype l -exec ls {} \;) && \
+ if [ -n "$$BROKEN_SYMLINKS" ]; then \
+ echo "\n Fixing broken symbolic links."; \
+ fi && \
+ for file in $$BROKEN_SYMLINKS; do \
+ cd $(DL_DIR)/$$ZIP_ROOT_DIR && \
+ LINK_TARGET=$$(readlink "$$file") && \
+ REL_PATH_TO_TARGET=$$(echo "$$LINK_TARGET" | sed "s|.*$$ZIP_ROOT_DIR/\(.*\)|\1|") && \
+ echo "Replacing symbolic link: $$file" && \
+ echo " Original target: $$LINK_TARGET" && \
+ echo " New target: $$REL_PATH_TO_TARGET" && \
+ ln -fsr "$$REL_PATH_TO_TARGET" "$$file"; \
+ done; \
+ BROKEN_SYMLINKS_AFTER=$$(cd $(DL_DIR)/$$ZIP_ROOT_DIR && find -xtype l -exec ls {} \;) && \
+ if [ -n "$$BROKEN_SYMLINKS_AFTER" ]; then \
+ echo "\n Some files have broken symbolic links. Please report a bug to the package maintainer\n"; \
+ for item in $$BROKEN_SYMLINKS_AFTER; do \
+ echo "$$item"; \
+ done && \
+ exit 1 ;\
+ fi
+
$(DL_DIR)/$(PKG_SOURCE):
cd $(DL_DIR) && \
su nobody -s /bin/sh -c "wget --continue $(PKG_SOURCE_URL) -O $(PKG_SOURCE).tmp && mv $(PKG_SOURCE).tmp $(PKG_SOURCE)"
Bug#1034641: exiv2: Pick upstream patch for regression on Olympus Maker notes
Package: exiv2 Version: 0.27.6-1 Severity: normal Tags: patch upstream Dear Maintainer, Would you please pick a patch from upstream that fixes a regression in 0.27.6? This regression leads to loss of corruption of Olympus Makernotes. You can find all the details in the issue at https://github.com/Exiv2/exiv2/issues/2542 Upstream's patch is linked from https://github.com/Exiv2/exiv2/issues/2542#issuecomment-1493926009 -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages exiv2 depends on: ii libc62.31-13+deb11u5 ii libexiv2-27 0.27.3-3+deb11u1 ii libgcc-s110.2.1-6 ii libstdc++6 10.2.1-6 exiv2 recommends no packages. exiv2 suggests no packages.
Bug#1034404: unblock: google-android-installers/1675172737
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: fabstz...@yahoo.fr
Please unblock package google-android-installers
This version adds a Binary dependency that was missing.
It fixes #1033729
[ Reason ]
Fix bug, add missing binary package dependency.
[ Impact ]
Users that install google-android-cmdline-tools*-installers packages
will have
to manually install the google-android-build-tools-*-installer also (and
find
by themselves that they are required)
[ Tests ]
Manual test that the required dependencies are installed.
[ Risks ]
No big risk since it is just about specifying a dependency inside the same
source package.
[ 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 testing
[ Other info ]
(Anything else the release team should know.)
N/A
unblock google-android-installers/1675172737diff -Nru google-android-installers-1675172735/debian/changelog
google-android-installers-1675172737/debian/changelog
--- google-android-installers-1675172735/debian/changelog 2023-02-08
11:36:58.0 +0100
+++ google-android-installers-1675172737/debian/changelog 2023-04-09
22:31:58.0 +0200
@@ -1,3 +1,15 @@
+google-android-installers (1675172737) unstable; urgency=medium
+
+ * cmdline-tools: set Architecture to 'amd64 i386'
+
+ -- Fab Stz Sun, 09 Apr 2023 22:31:58 +0200
+
+google-android-installers (1675172736) unstable; urgency=medium
+
+ * cmdline-tools: add dependency to build-tools packages. Closes: #1033729
+
+ -- Fab Stz Mon, 03 Apr 2023 18:25:39 +0200
+
google-android-installers (1675172735) unstable; urgency=medium
* New upstream update
diff -Nru google-android-installers-1675172735/debian/cmdline-tools.control.in
google-android-installers-1675172737/debian/cmdline-tools.control.in
--- google-android-installers-1675172735/debian/cmdline-tools.control.in
2023-02-08 11:36:58.0 +0100
+++ google-android-installers-1675172737/debian/cmdline-tools.control.in
2023-04-09 22:31:58.0 +0200
@@ -1,7 +1,8 @@
Package: google-android-cmdline-tools-%VER%-installer
-Architecture: all
+Architecture: amd64 i386
Depends: default-jre-headless,
google-android-licenses (= ${source:Version}),
+ ${googleAndroidCmdlineToolsInstallers:Depends},
${googleAndroidInstallers:Depends},
${misc:Depends}
#Provides: apkanalyzer, avdmanager, lint, profgen, retrace, screenshot2,
sdkmanager,
diff -Nru
google-android-installers-1675172735/debian/cmdline-tools.substvars.in
google-android-installers-1675172737/debian/cmdline-tools.substvars.in
--- google-android-installers-1675172735/debian/cmdline-tools.substvars.in
1970-01-01 01:00:00.0 +0100
+++ google-android-installers-1675172737/debian/cmdline-tools.substvars.in
2023-04-09 22:31:58.0 +0200
@@ -0,0 +1 @@
+googleAndroidCmdlineToolsInstallers:Depends=
diff -Nru google-android-installers-1675172735/debian/control
google-android-installers-1675172737/debian/control
--- google-android-installers-1675172735/debian/control 2023-02-08
11:36:58.0 +0100
+++ google-android-installers-1675172737/debian/control 2023-04-09
22:31:58.0 +0200
@@ -2133,9 +2133,10 @@
available at developer.android.com.
Package: google-android-cmdline-tools-1.0-installer
-Architecture: all
+Architecture: amd64 i386
Depends: default-jre-headless,
google-android-licenses (= ${source:Version}),
+ ${googleAndroidCmdlineToolsInstallers:Depends},
${googleAndroidInstallers:Depends},
${misc:Depends}
#Provides: apkanalyzer, avdmanager, lint, screenshot2, sdkmanager,
@@ -2162,9 +2163,10 @@
Agreement of this binary package is available at developer.android.com.
Package: google-android-cmdline-tools-2.1-installer
-Architecture: all
+Architecture: amd64 i386
Depends: default-jre-headless,
google-android-licenses (= ${source:Version}),
+ ${googleAndroidCmdlineToolsInstallers:Depends},
${googleAndroidInstallers:Depends},
${misc:Depends}
#Provides: apkanalyzer, avdmanager, lint, screenshot2, sdkmanager,
@@ -2191,9 +2193,10 @@
Agreement of this binary package is available at developer.android.com.
Package: google-android-cmdline-tools-3.0-installer
-Architecture: all
+Architecture: amd64 i386
Depends: default-jre-headless,
google-android-licenses (= ${source:Version}),
+ ${googleAndroidCmdlineToolsInstallers:Depends},
${googleAndroidInstallers:Depends},
${misc:Depends}
#Provides: apkanalyzer, avdmanager, lint, screenshot2, sdkmanager,
@@ -2220,9 +2223,10 @@
Agreement of this binary package is available at developer.android.com.
Package: google-android-cmdline-tools-4.0-installer
-Architecture: all
+Architecture: amd64 i386
Depends: default-jre-headless,
google
Bug#1032405: installation-reports: missing nvidia nouveau firmware: nvac_fuc084 & nvac_fuc084d
Package: installation-reports Severity: normal I couldn't try on the real system which is an iMac 9.1 (because I don't have physical access to it presently), but there is no package shipping these firmware files which are required by nouveau. firmware: failed to load nouveau/nvac_fuc084 (-2) firmware: failed to load nouveau/nvac_fuc084d (-2) Boot method: DVD Image version: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso Date: 2023-03-06 Machine: imac 9.1 Until now, I installed them this way as per https://nouveau.freedesktop.org/VideoAcceleration.html mkdir /tmp/nouveau cd /tmp/nouveau wget https://raw.github.com/envytools/firmware/master/extract_firmware.py wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run sh NVIDIA-Linux-x86-325.15.run --extract-only python2.7 extract_firmware.py # this script is for python 2 only mkdir /lib/firmware/nouveau cp -d nv* vuc-* /lib/firmware/nouveau/ It would be nice if there were a firmware package for it in bookworm -- Package-specific info: I removed it because it was not related to the system for which I report the issue.
Bug#1032069: ITP: rust-rawloader -- Image processing pipeline
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-rawloader Version : 0.37.1 Upstream Author : Pedro Côrte-Real * URL : https://github.com/pedrocr/rawloader * License : LGPL-2.1 Programming Lang: Rust Description : Library to extract the data from camera raw formats This is a rust library to extract the raw data and some metadata from digital camera images. Given an image in a supported format and camera you will be able to get everything needed to process the image: - Identification of the camera that produced the image (both the EXIF name and a cleaned up name) - The raw pixels themselves, exactly as encoded by the camera - The number of pixels to crop on the top, right, bottom, left of the image to only use the actual image area - The black and white points of each of the color channels - The multipliers to apply to the color channels for the white balance - A conversion matrix between the camera color space and XYZ - The description of the bayer pattern itself so you'll know which pixels are which color Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032068: ITP: rust-imagepipe -- Image processing pipeline
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-imagepipe Version : 0.5.0 Upstream Author : Pedro Côrte-Real * URL : https://github.com/pedrocr/imagepipe * License : LGPL-3.0-only Programming Lang: Rust Description : Image processing pipeline An image pipeline capable of taking any image format, including camera RAW files and transforming it into a final output. Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032066: ITP: rust-image-hasher -- simple library that provides perceptual hashing and difference calculation for images
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-image-hasher Version : 1.1.2 Upstream Author : 2015-2017 The `img_hash` Crate Developers 2014-2021 Austin Bonander 2022-2023 Rafał Mikrut * URL : https://github.com/qarmin/img_hash * License : MIT or Apache-2.0 Programming Lang: Rust Description : Library for calculating perceptual hash values of images A simple library that provides perceptual hashing and difference calculation for images. Thanks to Dr. Neal Krawetz for the outlines of the Mean (aHash), Gradient (dHash), and DCT (pHash) perceptual hash algorithms: http://www.hackerfactor.com/blog/?/archives/432-Looks-Like-It.html (Accessed August 2014) Also provides an implementation of the Blockhash.io algorithm. This crate can operate directly on buffers from the PistonDevelopers/image crate. This is fork of img_hash library, but with updated dependencies without any license changes. Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032064: ITP: fluent-syntax -- Parser/Serializer tools for Fluent Syntax
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: fluent-syntax Version : 0.11.0 Upstream Author : Zibi Braniecki Staś Małolepszy * URL : https://github.com/projectfluent/fluent-rs * License : Apache-2.0 or MIT Programming Lang: Rust Description : Parser/Serializer tools for Fluent Syntax fluent-syntax is a parser/serializer API for the Fluent Syntax, part of the Project Fluent, a localization framework designed to unleash the entire expressive power of natural language translations. Required by czkawka #1032030 Should be maintained by rust team. Sponsor required
Bug#1032030: ITP: czkawka-gui -- Multi functional app to find duplicates, empty folders, similar images etc
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: czkawka-gui Version : 5.1.0 Upstream Author : Rafał Mikrut * URL : https://github.com/qarmin/czkawka * License : MIT Programming Lang: rust Description : Multi functional app to find duplicates, empty folders, similar images etc There is a GUI and a cli package: - czkawka-gui - czkawka-cli Czkawka (tch-kav-ka, hiccup) is a simple, fast and free app to remove unnecessary files from your computer. Features: - Written in memory safe Rust - Amazingly fast - due to using more or less advanced algorithms and multithreading - Free, Open Source without ads - Multiplatform - works on Linux, Windows and macOS - Cache support - second and further scans should be a lot faster than the first one - CLI frontend - for easy automation - GUI frontend - uses modern GTK 3 and looks similar to FSlint - Rich search option - allows setting absolute included and excluded directories, set of allowed file extensions or excluded items with the * wildcard - Multiple tools to use: - Duplicates - Finds duplicates basing on file name, size, hash, first 1 MB of hash - Empty Folders - Finds empty folders with the help of an advanced algorithm - Big Files - Finds the provided number of the biggest files in given location - Empty Files - Looks for empty files across the drive - Temporary Files - Finds temporary files - Similar Images - Finds images which are not exactly the same (different resolution, watermarks) - Zeroed Files - Finds files which are filled with zeros (usually corrupted) - Same Music - Searches for music with same artist, album etc. - Invalid Symbolic Links - Shows symbolic links which points to non-existent files/directories - Broken Files - Finds files with an invalid extension or that are corrupted This should close RFP: #1006181 fslint which did a similar job was removed from bullseye because it required python2. This is a alternative/replacement. Should be maintained by rust team.
Bug#1030211: qt6-charts-dev should depend on qml6-module-qtcharts?
Package: qt6-charts-dev Version: 6.4.2-1 Severity: normal Dear Maintainer, I was trying to configure a project which Build-Depends on qt6-charts-dev At build time I have the error below. If I install also qml6-module-qtcharts, then configure is made successfully. Should this be added as a dependency in qt6-charts-dev? Error: CMake Error at /usr/lib/x86_64-linux- gnu/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets.cmake:96 (message): The imported target "Qt6::qtchartsqml2" references the file -- Configuring incomplete, errors occurred! "/usr/lib/x86_64-linux-gnu/qt6/qml/QtCharts/libqtchartsqml2plugin.so" See also "/home/runner/work/welle.io/welle.io/build/CMakeFiles/CMakeOutput.log". but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux- gnu/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux- gnu/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Config.cmake:61 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlPlugins.cmake:18 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlConfig.cmake:133 (include) /usr/local/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtPublicDependencyHelpers.cmake:108 (find_dependency) /usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickDependencies.cmake:39 (_qt_internal_find_qt_dependencies) /usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickConfig.cmake:50 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package) CMakeLists.txt:58 (find_package) CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickConfig.cmake but it set Qt6Quick_FOUND to FALSE so package "Qt6Quick" is considered to be NOT FOUND. Call Stack (most recent call first): CMakeLists.txt:58 (find_package) -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt6-charts-dev depends on: pn libqt6charts6 pn libqt6chartsqml6 pn qt6-base-dev qt6-charts-dev recommends no packages.
Bug#1029599: gbp: Permit to run merge step alone after gbp import-orig --no-merge
Package: gbp Version: git-buildpackage Severity: normal Dear Maintainer, In my repo, there are various vendor branches, the upstream & pristine-tar branches. Let's say each vendor doesn't update to the latest upstream version at the same time. So the first one import the new upstream version runs: gbp import-orig --uscan --no-merge --pristine-tar But after that it is not possible to easily update the vendor branches with a given version that is now in upstream/* & pristine-tar Would it be possible to support a command in gbp import-orig to just run the "merge" step at the time each vendor branch wants it? I looked at the verbose output of git merge and there are rather a lot of command to do this manually. gbp:info: source package is freefilesync gbp:info: upstream version is 12.0 gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest'] gbp:debug: ['git', 'add', '-f', '.'] gbp:debug: ['git', 'write-tree'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest'] gbp:debug: ['git', 'commit-tree', '27314593587b7b431c0f7e0e400a6d11390c0214', '-p', '8dadd1b9fd4fb3a53ff2357eb3e7f6a602a8'] gbp:debug: ['git', 'update-ref', '-m', 'gbp: new upstream version 12.0', 'refs/heads/upstream/latest', '9f1e58d1da285e68cb26b9ea1527f22e590f80b1', '8dadd1b9fd4fb3a53ff2357eb3e7f6a602a8'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar'] gbp:debug: ['git', 'ls-tree', '-z', 'upstream/latest', '--'] gbp:debug: ['git', 'mktree', '-z'] gbp:debug: pristine-tar [] ['commit', '../freefilesync_12.0.orig.tar.xz', '27314593587b7b431c0f7e0e400a6d11390c0214'] gbp:debug: ['git', 'tag', '-m', 'upstream version 12.0', 'upstream/12.0', '9f1e58d1da285e68cb26b9ea1527f22e590f80b1'] gbp:debug: ['git', 'symbolic-ref', 'head'] gbp:debug: ['git', 'show-ref', 'refs/heads/debian/latest'] gbp:debug: rm ['-rf', '../tmptg4x81j5'] [] gbp:info: successfully imported version 12.0 of ../freefilesync_12.0.orig.tar.xz I also tried: git merge --strategy recursive --strategy-option theirs upstream/latest But it doesn't take all changes in my case. Some files from upstream are not updated. Thanks -- system information: debian release: 11.6 apt prefers stable-updates apt policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') architecture: amd64 (x86_64) foreign architectures: i386 kernel: linux 5.10.0-20-amd64 (smp w/4 cpu threads) kernel taint flags: taint_proprietary_module, taint_oot_module, taint_unsigned_module locale: lang=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hello, Not sure this fits your issue and if this could work. I used to produce android-builds that are sort of 'target' builds (and not host builds). There is a specific qmake to be called when building with a target-build. That qmake is in the bin directory of the target build. And that qmake uses the "target_qt.conf" file which should contain the path you expect. However, for now, not all path are there and especially the Plugins dir isn't there. They will be once this is merged: https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/ QtQmakeHelpers.cmake Maybe a solution could be to run qmake by specifying your own target_qt.conf that has the values you need ? Regards Fab On Wed, 7 Dec 2022 08:04:54 +0100 Helmut Grohne wrote: > Package: qmake6 > Version: 6.3.1+dfsg-10 > Severity: important > Control: affects -1 + src:fcitx-qt5 > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > X-Debbugs-Cc: debian-cr...@lists.debian.org > > Hi, > > we've hit an interesting issue with qmake for QT6. This almost certainly > is a pattern and I'll use fcitx-qt5 as an example. > > fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION > property to be able to run it. Then it runs that with -query > QT_INSTALL_PLUGINS to locate the installation directory for plugins. > Unfortunately, what it gets is the build architecture one rather than > the host architecture one. > > The crux of this is that /usr/bin/qmake6 cannot know about the host > architecture. That information is a parameter of the build and nothing > has passed this information along to it. It cannot just pull this > information out of nothing. So we basically have two options: > > a) Make sure that Qt6::qmake's LOCATION resolves to something that >includes the information of the host architecture somehow. > b) Declare that this method of querying qmake is unsupported and fix >every package (including fcitx-qt5) in some other way. > > For b), I have no clue what that other way would be. If someone knows, > that would be great. I also have little clue how frequent this pattern > is and how many packages we would have to fix. The expectation is "many" > from my experience with QT5. > > The implications of a) are quite well understood, because that's the > route we opted for with QT5. It's a fairly involved route that took us > more than a year to work properly, but maybe we can speed up by learning > from earlier mistakes, so how does it work? > > The qmake6 package gains new binaries /usr/bin/-qmake6. These > actually are shell scripts that wrap qmake6 and inject the information > about the host architecture into the command line. Then, we centrally > divert Qt6::qmake to this location and everything will magically work. > To get an idea how this works, install qt5-qmake and look at > /usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly > obvious. We're in a far better position than we started with QT5 as we > already have the necessary qmake6 vs qmake6-bin split in place in > exactly the way it needs to be. Also a number of client packages have > been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake > already. > > What we need now is a choice on which way we do it. The choice > essentially is: > > a) Add architecture-specific qmake wrappers for QT6. > b) Declare that running qmake6 -query SOMEVAR is unsupported. > > Patrick and Pino, what's your thoughts on this? If you feel like you > cannot make such a choice, let us figure out what information is > missing.
Bug#1023249: RFS: w-scan-cpp/20220105-1 [ITP] -- DVB channel scanner (successor of w_scan)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "w-scan-cpp": * Package name : w-scan-cpp Version : 20220105-1 Upstream contact : Winfried Koehler * URL : https://www.gen2vdr.de/wirbel/w_scan_cpp/index2.html * License : GPL-2.0, GPL-2.0+ * Vcs : https://salsa.debian.org/bastif/w-scan-cpp Section : video The source builds the following binary packages: w-scan-cpp - DVB channel scanner (successor of w_scan) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/w-scan-cpp/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/w/w-scan-cpp/w-scan-cpp_20220105-1.dsc Changes for the initial release: w-scan-cpp (20220105-1) unstable; urgency=low . * Initial release. (Closes: #1023169) This package depends on "librepfunc1" which is part of src:librepfunc, which is also needing a sponsor https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023115 Regards, -- Fab Stz
Bug#1023169: ITP: w-scan-cpp -- DVB channel scanner (successor of w_scan)
Package: wnpp
Severity: wishlist
Owner: Fab Stz
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: w-scan-cpp
Version : 20220105
Upstream Author : Winfried Koehler
* URL : https://www.gen2vdr.de/wirbel/w_scan_cpp/index2.html
* License : GPL
Programming Lang: C++
Description : DVB channel scanner (successor of w_scan)
This is w_scan_cpp - a dtv channel scanner based on VDR (www.tvdr.de)
and its Plugins.
.
w_scan_cpp supports
.
DVB-T(2), DVB-C, DVB-S(2), ATSC(VSB &=& qam)
sat>ip
scr ("unicable") en-50494 =& en-50607 (aka. "jess")
diseqc switches
diseqc rotors (standard =& usals)
various output formats
vdr channels.conf
vlc channels.xspf
dtv scan tables for dvbv5-scan
channels.dat for the sat>ip "dvb viewer lite for windows"
(..)
.
some features are more recent than those of w_scan, other outdated features
were not ported.
This package requires librepfunc. ITP here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023110
This could be added to/maintained by the "vdr" team.
This would also close:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000741
There is also a Merge Request updating w-scan here:
https://salsa.debian.org/vdr-team/w-scan/-/merge_requests
Sponsor required.
Bug#1023115: RFS: librepfunc/1.6.4-1 [ITP] -- set of C++ classes and utilities for building multimedia tools (dev files)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "librepfunc": * Package name : librepfunc Version : 1.6.4-1 Upstream contact : [fill in name and email of upstream] * URL : https://github.com/wirbel-at-vdr-portal/librepfunc * License : GPL-2.0-only * Vcs : https://salsa.debian.org/bastif/librepfunc Section : libs The source builds the following binary packages: librepfunc1 - set of C++ classes and utilities for building multimedia tools librepfunc-dev - set of C++ classes and utilities for building multimedia tools (dev files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/librepfunc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libr/librepfunc/ librepfunc_1.6.4-1.dsc Changes for the initial release: librepfunc (1.6.4-1) unstable; urgency=medium . * Initial release. (Closes: #1023110) I'm also looking for a sponsor for w-scan-cpp: https://mentors.debian.net/package/w-scan-cpp/ See request here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000741 I tried contacting Tobias Grimm a few weeks ago since he is the maintainer of w-scan and https://salsa.debian.org/vdr-team/vdr-plugin-wirbelscan but haven't got an answer yet. Regards, -- Fab Stz
Bug#1023110: ITP: librepfunc -- Set of C++ classes and utilities for building multimedia tools
Package: wnpp Severity: wishlist Owner: Fab Stz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: librepfunc Version : 1.6.4 Upstream Author : Winfried Koehler * URL : https://github.com/wirbel-at-vdr-portal/librepfunc * License : GPL Programming Lang: C++ Description : Set of C++ classes and utilities for building multimedia tools This is a collection of utilities and functions used for example in w-scan- cpp . string related: * LowerCase and UpperCase * LeftTrim and RightTrim and Trim * FrontFill and BackFill * ReplaceAll . vector of string related: * SplitStr . number conversion to string or vice versa * IntToStr * FloatToStr * ExpToStr * StrToInt + StrToFloat . print time * TimeStr . other conversions * BCDtoDecimal . sleep threads * Sleep, mSleep, uSleep . print hex data * HexDump . files and directories * FileExists * cFileList * ReadFileToStream * ReadFile * WriteStreamToFile * WriteFile . start/stop threads from main thread * ThreadBase This library is used by w_scan_cpp which is the successor of w_scan (w_scan is not maintained anymore). w_scan_cpp & w_scan are from same author. it is also used in https://salsa.debian.org/vdr-team/vdr-plugin-wirbelscan but for now, it embeds the library while it could make use of librepfunc. so at least 2 packages would use this library: w-scan-cpp =& vdr-plugin-wirbelscan see also this bug report asking for w_scan_cpp: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000741 Idealy this would be maintained in the vdr team like w-scan and vdr-plugin- wirbelscan
Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"
Hello Norbert,
This is still relevant for 22.04.2-1
Would you please add that patch to the package?
Since the "operator" group is present on a fresh install of Debian, and since
it is prefered to have group "cdrom" used by k3b, I think it would be better
if the patch was applied.
Rgds
Fab
Le mardi 2 mars 2021, 16:59:35 CEST Fab Stz a écrit :
> Hello,
>
> > Well, the original code is rather bad indeed, because it relies on the
> > order of groups returned by getgrent, and picks the *last* available
> > one. In your case, if you have an "operator" group, it will be used.
>
> Ok, this explains it then.
>
> Well it's a fresh debian install of testing/bullseye to find some bugs
> before the upcoming release. And on a fresh install "operator" group is
> present.
>
> If k3b's deb could be fixed for the next release of debian so that the
> package conforms debian's policies that would be great. I think this patch
> is sufficient since the group that fits this purpose, according to the
> group definition is "cdrom", so no need to search any other, and on debian
> it does exist.
>
> Regards
>
> Le mardi 2 mars 2021, 14:31:12 CET Norbert Preining a écrit :
> > Hi,
> >
> > not that I am an expert, and cd burning is anyway only for maniacs (like
> > me!!!) who want to get into contact with whom-who-must-not-be-named.
> >
> > > With k3b, when wanting to set the external program permissions, it wants
> > > to
> > > set them with user "operator" instead of "cdrom" which may be more
> > > adequate
> > >
> > > while (::group *g = ::getgrent()) {
> > >
> > > const QString groupName = QString::fromLocal8Bit(g->gr_name);
> > >
> > > -if (groupName == "cdrom" ||
> > > -groupName == "optical" ||
> > > -groupName == "operator" ) {
> > > +if (groupName == "cdrom") {
> > >
> > > m_permissionModel->setBurningGroup(groupName);
> > >
> > > }
> > >
> > > }
> >
> > Well, the original code is rather bad indeed, because it relies on the
> > order of groups returned by getgrent, and picks the *last* available
> > one. In your case, if you have an "operator" group, it will be used.
> >
> > I am not sure, maybe this is intended, but I guess there should be
> > either a break out of the loop after the first groupname is found,
> > or something else.
> >
> > Best
> >
> > Norbert
> >
> > --
> > PREINING Norbert https://www.preining.info
> > Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev
> > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1021497: autopkgtest: Provide a way to escape # character in Test-Command
Package: autopkgtest
Version: 5.16
Severity: normal
Dear Maintainer,
If I have such a line in the d/tests/control
Test-Command: modprobe --verbose --set-version "$(for kernel in /boot/config-
*;
do echo ${kernel#*-}; done | tail -n1)" my_kernel_module
It will consider the command is only
modprobe --verbose --set-version "$(for kernel in /boot/config-*; do echo
${kernel
Everything after '#' is ignored, as stated in [1]
Would you provide a way to escape it? I don't know how though...
For example in debhelper [2] to escape a $, they suggest ${Dollar}. Or for a
new line, they would do ${Newline}. So maybe something similar, like ${Hash}
or
${NumberSign}. But the use of the dollar sign, wouldn't be very optimal since
it already has a meaning in shell.
[1]
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
[2] https://manpages.debian.org/bullseye/debhelper/debhelper.7.en.html
For now, I put the command in a separate script called with "Command:"
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autopkgtest depends on:
ii apt-utils 2.2.4
ii libdpkg-perl1.20.12
ii procps 2:3.3.17-5
ii python3 3.9.2-3
ii python3-debian 0.1.39
Versions of packages autopkgtest recommends:
ii autodep8 0.24
Versions of packages autopkgtest suggests:
pn lxc
pn lxd
pn ovmf
pn qemu-efi-aarch64
pn qemu-efi-arm
pn qemu-system
ii qemu-utils1:5.2+dfsg-11+deb11u2
ii schroot 1.6.10-12+deb11u1
ii vmdb2 0.22-1
Bug#1021491: ntfs-3g: set /sbin/mount.ntfs as alternatives
Package: ntfs-3g Version: 1:2017.3.23AR.3-4+deb11u2 Severity: wishlist Tags: patch Dear Maintainer, For now, the /sbin/mount.ntfs file is a symlink to mount.ntfs-3g I would like to have both ntfs-3g and another driver installed and for that, I would like to be able to choose whether mount.ntfs is the one of ntfs-3g, or of the other driver. Currently I can't have another package write over mount.ntfs since it is the one of ntfs-3g. Could you consider making that link use the "alternatives" system? You could add this file "debian/ntfs-3g.alternatives" with this content: Name: mount.ntfs Link: /sbin/mount.ntfs Alternative: /sbin/mount.ntfs-3g Priority: 50 This should then automatically be managed by dh_installalternatives You may also need to remove the link you currently create in "debian/ntfs-3g.links" Regards -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ntfs-3g depends on: ii fuse3 [fuse] 3.10.3-2 ii libc6 2.31-13+deb11u4 ii libgcrypt201.8.7-6 ii libgnutls303.7.1-5+deb11u2 ii libntfs-3g883 1:2017.3.23AR.3-4+deb11u2 ntfs-3g recommends no packages. Versions of packages ntfs-3g suggests: ii fdisk 2.36.1-8+deb11u1
Bug#1020952: gradle fails to start - org/fusesource/jansi/AnsiOutputStream error
Package: gradle Version: 4.4.1-15 Severity: grave Justification: renders package unusable Dear Maintainer, running on testing a simple "gradle -version" leads to this failure. FAILURE: Build failed with an exception. * What went wrong: org/fusesource/jansi/AnsiOutputStream * Try: Run with --stacktrace option to get the stack trace. Run with --info or -- debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org The only way I could make it work is to manually downgrade libjansi-java to version from bullseye. Although you changed the dependency to libjansi1-java, libjansi-java is still installed because it is a dependency of groovy. Rgds Fab -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gradle depends on: ii default-jre-headless [java8-runtime-headless] 2:1.11-72 ii libgradle-core-java 4.4.1-13 ii libgradle-plugins-java4.4.1-13 ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.16+8-1~deb11u1 gradle recommends no packages. Versions of packages gradle suggests: pn gradle-doc
Bug#1010049: qt6-base-dev: should provide a QT_HOST_PATH directory for cross building
Hello.
I have a similar problem.
In addition to:
-DQT_HOST_PATH=/usr/lib/qt6
You must also set:
-DQT_HOST_PATH_CMAKE_DIR=/usr/lib/${DEB_HOST_MULTIARCH}/cmake
But then it still fails with this error now:
Configuring submodule 'qtbase'
-- Could NOT find Qt6CoreTools (missing: Qt6CoreTools_DIR)
CMake Error at qtbase/cmake/QtToolHelpers.cmake:184 (message):
Failed to find the host tool "Qt6::moc". It is part of the Qt6CoreTools
package, but the package could not be found. Make sure you have built and
installed the host Core module, which will ensure the creation of the
Qt6CoreTools package.
Call Stack (most recent call first):
qtbase/src/tools/moc/CMakeLists.txt:8 (qt_internal_add_tool)
Any idea how to make it find the Qt core tools like moc?
The qt6-base-dev package is installed, as well as qt6-base-dev-tools
Regards
On Sat, 23 Apr 2022 15:14:55 +0200 Helmut Grohne wrote:
> Hi,
>
> On Sat, Apr 23, 2022 at 09:38:54AM +0200, Helmut Grohne wrote:
> > I expect that QT_HOST_PATH also needs to point to architecture-dependent
> > files (e.g. libraries). Qt5 has faced as similar problem and thus added
>
> Dmitry noted that none of Qt6's executables (possibly except for qmake)
> are architecture-dependent and encouraged me to try
> -DQT_HOST_PATH=/usr/lib/qt6. When you
Bug#1016875: RFS: freefilesync/11.23-1 [ITP] -- cross-platform file sync utility, gpl release
Control: tags -1 -moreinfo Dear Boyuan, Thank you for your interest and asking the questions: Le jeudi 11 août 2022, 21:27:14 CEST Boyuan Yang a écrit : > I am curious on the current arrangement of your deb packaging. Specifically: > > * Why there are many separate ffs_* patches in debian/patches/? Where did > they originate from? If they originates from upstream (FreeFileSync), why > aren't they incorporated into upstream source code? Originally I found packaging for Devuan but also for Ubuntu on non official repos [1] & [2]. FreeFileSync has been packaged for years at least for Ubuntu but was never on Debian. So I took a lot of inspiration of these 2 packages to make this one. This also explains the list of authors in the d/copyright file. I also didn't known what to do with the history. Both packages share the same patches, but their d/ changelog doesn't cross each-other. Concerning the patches, I took them from bgstack15's repo [1]. BTW Most patches have his name/nickname in the patch headers. He also describes them with the rationale in the header. I did too for the ones I added by following DEP-3 Patch Tagging guidelines. Some patches are here because upstream works with the very latest versions of the dependencies or an older version, which are not always available on debian & derivatives. That's the case for wxwidgets-3.2 or gtk-2: - revert_zenju_aggressive_upstreamisms.patch - ffs_no_wx311.patch - ffs_devuan_gtk3.patch Some patches add, enable, remove or disable a feature (notification, check for updates...) - ffs_allow_parallel_ops.patch - ffs_traditional_view.patch - ffs_no_check_updates.patch - ffs_desktop_notifications.patch Some patches are to make it compatible with debian filesystem or build system - ffs_gcc.patch - ffs_devuan.patch - reproducible-build.patch - pkg-config.patch This one is probably to distinguish between the free version for which the code is published, and the binary builds that the author ships to donators. - ffs_dpkg_vendor_specific_about.patch Some patches fix upstream's code which is not buildable otherwise (either we don't have the same dependency version as the one used by upstream which leads to compilation errors, or he uses unavailable macro's that have to be patched) - ffs_sftp.patch - ffs_icon_loader.patch I sent mine upstream (pgk-config & reproducible) by email. Hopefully they will be merged. But on github, upstream says: "Please do not send pull requests" [3]. > * You are providing .desktop files under debian/desktop/. Does that mean > that upstream author is not providing any .desktop files so that you have to > write them yourself? Indeed. They are not available in the original sources shipped by the upstream author. However he/she provides some in his linux installer binary that I took manually from there. I also adapted them based also on the additions/changes found in the desktop files shipped in the Ubuntu & Devuan sources. > * Please do not hardcode g++-12:native in the Build-Depends field. A sane > environment should already have provided the proper g++. It could be g++ 12 > or other versions. That's fixed. Thanks. https://salsa.debian.org/bastif/freefilesync/-/commit/ a57b5655814b46559d875548526bfecc6690b269 > * You wrote Maintainer: B. Stack in debian/control > file, which looks falty to me. The maintainer should be package maintainer, > not upstream software author, unless the upstream author (B. Stack) will be > maintaining Debian package as well. That was originally in the d/control I took from him. I left it this way not really knowing what would be best. I talked to him, he would be happy to see this in Debian and said that he might take the package over once in Debian. I don't know exactly what he meant. What do you suggest in the meantime? > * You indicated "Multi-Arch: foreign" in debian/control file. However > according to https://wiki.debian.org/MultiArch/Hints#ma-foreign , M-A: > foreign only applies to Architecture: all packages. Your package is not of > Architecture: all. That's not what I understood from that paragraph. The rest of the paragraph suggests that foreign can also be for Architecture: any. Many packages have such a setup. Just an example: https://sources.debian.org/src/zip/3.0-12/debian/control/ Manpage of deb-control states foreign This package is not co-installable with itself, but should be allowed to satisfy a non-arch-qualified dependency of a package of a different arch from itself (if a dependency has an explicit arch- qualifier then the value foreign is ignored). I'm not sure to totally understand what is written here, but I understant that with "foreign" we can't install freefilesync:amd64 & freefilesync:i386 at the same time. But we can have a setup where we could have freefilesync:i386 installed on an amd64 system (with an additional arch of
Bug#996265: autopkgtest: The dependency of each test is added to the dependencies of the following tests
Hello Paul, Thanks for taking the time to look at this. > Can you please specify which backend you're using? This is *not* what > I'm seeing in the runs on ci.d.n which uses lxc. As an example, one of > my packages has Depends mariadb-server in the first test, it doesn't get > installed in the second test [1]. Can you also share the sources (at > least debian/control) of the package that builds > google-android-build-tools-*-installer)? I forked the google-android-* packages to update them. The changes have not been merged yet that may be why don't. My fork is here [1]. > Are you sure -21.1.2-installer > has no Dependency itself on the lower version? I checked again, I don't see such a dependency. The test jobs are run from the automatic salsa-ci server. I don't know which backend is actually used. Ci job is defined here: [4] You can have a look at the logs of this job here [2] tests/control can be seen here [3] [1] https://salsa.debian.org/bastif/google-android-installers [2] https://salsa.debian.org/bastif/google-android-installers/-/jobs/2069646/ raw [3] https://salsa.debian.org/bastif/google-android-installers/-/blob/master/ debian/tests/control [4] https://salsa.debian.org/bastif/google-android-installers/-/blob/master/ debian/.gitlab-ci.yml Thanks Fab
Bug#996265: autopkgtest: The dependency of each test is added to the dependencies of the following tests
Package: autopkgtest Version: 5.17 Severity: normal Dear Maintainer, I noticed that the dependency of each test is added to the dependencies of the following tests For example: debian/tests/control contains: Test-Command: /usr/lib/android-sdk/build-tools/19.1.0/aapt v Depends: google-android-build-tools-19.1.0-installer Test-Command: /usr/lib/android-sdk/build-tools/20.0.0/aapt v Depends: google-android-build-tools-20.0.0-installer Test-Command: /usr/lib/android-sdk/build-tools/21.1.2/aapt v Depends: google-android-build-tools-21.1.2-installer The observer behaviour is: - for the test #1, it installs: google-android-build-tools-19.1.0-installer - for the test #2, it installs: google-android-build-tools-19.1.0-installer & google-android-build-tools-20.0.0-installer - for the test #3, it installs: google-android-build-tools-19.1.0-installer & google-android-build-tools-20.0.0-installer & google-android-build- tools-21.1.2-installer And so on... The packages named here are packages build by the source package that is being tested Is this expected? I expected to have only the declared Dependency to be installed, but it seems they are cumulative. Thank you. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.2.4 ii libdpkg-perl1.20.9 ii procps 2:3.3.17-5 ii python3 3.9.2-3 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: pn lxc pn lxd pn ovmf pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:5.2+dfsg-11 ii schroot 1.6.10-12 ii vmdb2 0.22-1
Bug#995770: mk-origtargz: repacking is slow when there are big folders Files-Excluded
Package: devscripts Version: 2.21.3 Severity: normal Dear Maintainer, mk-origtargz uses tar --delete to remove files listed in Files-Excluded. However, when there are huge folders with many files in it, then it calls tar --delete a huge amount of times. This is because the size of the tar --delete command cannot contain all files to exclude and then calls it as many times as needed. When working on big archives this can take a very long time. For example I was working on a 600MB archive (compressed) from which I wanted to removed ~2GB of uncompressed data. This should lead to ~ 300MB archive in the end. Since it takes forever with mk-origtargz I finally repacked it with a script that uncompresses the tar, removes the files/folder listed in Files-Excluded, and then creates a new archive. In the documentation of --delete [1] it is already mentioned that "The ‘--delete’ operation can run very slowly" Would it be possible to improve mk-origtargz so that it doesn't use tar --delete but a faster alternative? BTW, this also affects uscan which calls mk-origtargz. [1] https://www.gnu.org/software/tar/manual/html_node/delete.html -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- Not present -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.20.9 ii fakeroot 1.25.3-1.1 ii file 1:5.39-3 ii gnupg 2.2.27-2 ii gpgv 2.2.27-2 ii libc6 2.31-13 ii libfile-dirlist-perl 0.05-2 ii libfile-homedir-perl 1.006-1 ii libfile-touch-perl0.11-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20200505.0-1 ii libmoo-perl 2.004004-1 ii libwww-perl 6.52-1 ii patchutils0.4.2-1 ii perl 5.32.1-4+deb11u1 ii python3 3.9.2-3 ii sensible-utils0.0.14 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 2.2.4 ii curl7.74.0-1.3+b1 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2021.07.26 ii dput1.1.0 ii equivs 2.3.1 ii libdistro-info-perl 1.0 ii libdpkg-perl1.20.9 ii libencode-locale-perl 1.05-1.1 ii libgit-wrapper-perl 0.048-1 ii libgitlab-api-v4-perl 0.26-1 ii liblist-compare-perl0.55-1 ii liblwp-protocol-https-perl 6.10-1 ii libsoap-lite-perl 1.27-1 ii libstring-shellquote-perl 1.04-1 ii libtry-tiny-perl0.30-1 ii liburi-perl 5.08-1 ii licensecheck3.1.1-2 ii lintian 2.104.0 ii man-db 2.9.4-2 ii patch 2.7.6-7 ii pristine-tar1.49 ii python3-apt 2.2.1 ii python3-debian 0.1.39 ii python3-magic 2:0.4.20-3 ii python3-requests2.25.1+dfsg-2 ii python3-unidiff 0.5.5-2 ii python3-xdg 0.27-2 ii strace 5.10-1 ii unzip 6.0-26 ii wget1.21-1+b1 ii xz-utils5.2.5-2 Versions of packages devscripts suggests: pn adequate pn at ii autopkgtest 5.16 pn bls-standalone ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper 13.3.4 pn devscripts-el pn diffoscope pn disorderfs pn dose-extra pn duck pn faketime pn gnuplot pn how-can-i-help ii libauthen-sasl-perl 2.1600-1.1 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-2 pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3300-2 pn libyaml-syck-perl ii mailutils [mailx]
Bug#995186: android-framework-23: somes classes are missing
Source: android-framework-23 Severity: normal Dear Maintainer, I'm trying to build Qt for Android using the android framework provided by Debian, however this is not possible because some classes are missing. For example: com.android.internal.view.menu.MenuBuilder com.android.internal.view.menu.MenuPresenter Building fails with this error: class file for com.android.internal.view.menu.MenuBuilder not found According to these 2 files they are not built https://sources.debian.org/src/android-framework-23/6.0.1+r72-6/debian/README.source/ https://sources.debian.org/src/android-framework-23/6.0.1+r72-6/frameworks/base/Android.mk/ Would it be possible to ship them? There may be other classes needed by Qt for Android. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#988596: akonadi-server: akonadi crashes permanently; akonadiconsole does not start
Hello, I had the same problem after migrating from Buster to Bullseye. However, I remembered that in the past I moved the akonadi folder in ~/.local/ share/ to another partition and then created a symbolic link to it. I reverted that and relocated the akonadi folder to its initial place, what fixed the problem for me. I don't really know AppArmor, but I noticed that akonadiserver didn't have a profile in buster but has one in bullseye. Maybe this can help someone. Regards On Tue, 24 Aug 2021 18:10:27 +0200 Matteo Semplice wrote: > Hi. > > Same issue on my machine after upgrading it to Debian 11. > > The file .local/share/akonadi/Akonadi.error contains > > 2021-08-24T18:02:17 [WARN ] default: Connecting to deprecated signal > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) > 2021-08-24T18:04:38 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: > Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore > sconosciuto) > 2021-08-24T18:05:39 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: > Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore > sconosciuto) > > Thanks, > > Matteo > > >
Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"
Hello,
> Well, the original code is rather bad indeed, because it relies on the
> order of groups returned by getgrent, and picks the *last* available
> one. In your case, if you have an "operator" group, it will be used.
Ok, this explains it then.
Well it's a fresh debian install of testing/bullseye to find some bugs before
the upcoming release. And on a fresh install "operator" group is present.
If k3b's deb could be fixed for the next release of debian so that the package
conforms debian's policies that would be great. I think this patch is
sufficient since the group that fits this purpose, according to the group
definition is "cdrom", so no need to search any other, and on debian it does
exist.
Regards
Le mardi 2 mars 2021, 14:31:12 CET Norbert Preining a écrit :
> Hi,
>
> not that I am an expert, and cd burning is anyway only for maniacs (like
> me!!!) who want to get into contact with whom-who-must-not-be-named.
>
> > With k3b, when wanting to set the external program permissions, it wants
> > to
> > set them with user "operator" instead of "cdrom" which may be more
> > adequate
> >
> > while (::group *g = ::getgrent()) {
> >
> > const QString groupName = QString::fromLocal8Bit(g->gr_name);
> >
> > -if (groupName == "cdrom" ||
> > -groupName == "optical" ||
> > -groupName == "operator" ) {
> > +if (groupName == "cdrom") {
> >
> > m_permissionModel->setBurningGroup(groupName);
> >
> > }
> >
> > }
>
> Well, the original code is rather bad indeed, because it relies on the
> order of groups returned by getgrent, and picks the *last* available
> one. In your case, if you have an "operator" group, it will be used.
>
> I am not sure, maybe this is intended, but I guess there should be
> either a break out of the loop after the first groupname is found,
> or something else.
>
> Best
>
> Norbert
>
> --
> PREINING Norbert https://www.preining.info
> Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev
> GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"
Package: k3b
Version: 20.12.2-1
Severity: normal
Tags: patch
Dear Maintainer,
With k3b, when wanting to set the external program permissions, it wants to
set
them with user "operator" instead of "cdrom" which may be more adequate
according to the description of the groups in
https://wiki.debian.org/SystemGroups
- operator: Operator was (historically) the only 'user' account that could
login remotely.
- cdrom: This group can be used locally to give a set of users access to a
CDROM drive and other optical drives.
This will patch k3b to use "cdrom" instead.
BTW, in buster, permissions used to be set to "root.root". I don't know why
it's not the same since that piece of code didn't change.
-- Package-specific info:
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type: Removable CD-ROM
Version: 5
Response Format: 2
Capabilities :
Vendor_info: 'HL-DT-ST'
Identification : 'DVD+-RW GSA-H31L'
Revision : 'W618'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (991, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages k3b depends on:
ii cdparanoia 3.10.2+debian-13.1
ii cdrdao 1:1.2.4-2
ii genisoimage9:1.1.11-3.2
ii k3b-data 20.12.2-1
ii kio5.78.0-4
ii libc6 2.31-9
ii libk3b720.12.2-1
ii libkf5archive5 5.78.0-2
ii libkf5authcore55.78.0-2
ii libkf5bookmarks5 5.78.0-2
ii libkf5cddb54:20.12.0-1
ii libkf5completion5 5.78.0-3
ii libkf5configcore5 5.78.0-4
ii libkf5configwidgets5 5.78.0-2
ii libkf5coreaddons5 5.78.0-2
ii libkf5i18n55.78.0-2
ii libkf5iconthemes5 5.78.0-2
ii libkf5jobwidgets5 5.78.0-2
ii libkf5kcmutils55.78.0-3
ii libkf5kiocore5 5.78.0-4
ii libkf5kiofilewidgets5 5.78.0-4
ii libkf5kiowidgets5 5.78.0-4
ii libkf5newstuff55.78.0-2
ii libkf5notifications5 5.78.0-2
ii libkf5notifyconfig55.78.0-2
ii libkf5service-bin 5.78.0-2
ii libkf5service5 5.78.0-2
ii libkf5solid5 5.78.0-2
ii libkf5widgetsaddons5 5.78.0-2
ii libkf5xmlgui5 5.78.0-2
ii libqt5core5a 5.15.2+dfsg-4
ii libqt5dbus55.15.2+dfsg-4
ii libqt5gui5 5.15.2+dfsg-4
ii libqt5webkit5 5.212.0~alpha4-11
ii libqt5widgets5 5.15.2+dfsg-4
ii libqt5xml5 5.15.2+dfsg-4
ii libstdc++6 10.2.1-6
ii udisks22.9.2-1
ii wodim 9:1.1.11-3.2
Versions of packages k3b recommends:
ii dvd+rw-tools 7.1-14+b1
ii growisofs7.1-14+b1
ii libk3b7-extracodecs 20.12.2-1
ii vcdimager2.0.1+dfsg-5
Versions of packages k3b suggests:
pn k3b-extrathemes
ii k3b-i18n 20.12.2-1
ii kde-config-cddb 4:20.12.0-1
pn movixmaker-2
ii normalize-audio 0.7.7-16
ii sox 14.4.2+git20190427-2
-- no debconf information
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
k3b (20.12.2-1.0~fab1) UNRELEASED; urgency=medium
.
* Personnal changelog entry 03/02/21 11:53:38
Author: Anonymous
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update: 2021-03-02
--- k3b-20.12.2.orig/src/option/k3bexternalbinwidget.cpp
+++ k3b-20.12.2/src/option/k3bexternalbinwidget.cpp
@@ -152,9 +152,7 @@ K3b::ExternalBinWidget::ExternalBinWidge
while (::group *g = ::getgrent()) {
const QString groupName = QString::fromLocal8Bit(g->gr_name);
-if (groupName == "cdrom" ||
-groupName == "optical" ||
-groupName == "operator" ) {
+if (groupName == "cdrom") {
m_permissionModel->setBurningGroup(groupName);
}
}
Bug#953328: sddm: No login prompt on tty1
Hello, I confirm this is still present in latest bullseye having sddm version 0.19.0-2 (amd64) Maybe this is somehow linked to https://github.com/systemd/systemd/issues/ 12345 ? Is that actually a sddm or a systemd bug ? Regards On Sat, 07 Mar 2020 20:55:57 + Andy Wood wrote: > Package: sddm > Version: 0.18.1-1 > Severity: important > Tags: patch > > Dear Maintainer, > > * What led up to the situation? > Installed version 0.18.1-1 as provided in bullseye [reboot] > > * What was the outcome of this action? > No login prompt on tty1 [but it is present on other tty's] > > * What outcome did you expect instead? > Normal login prompt on tty1 > > This seems to be caused by entries in /lib/systemd/system/sddm.service > > Changing: >Conflicts=getty@tty1.service getty@tty7.service >After=getty@tty1.service getty@tty7.service > > back to [as per the previous version]: >Conflicts=getty@tty7.service >After=getty@tty7.service > > fixes the problem. > > Andy. > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (300, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages sddm depends on: > ii adduser 3.118 > ii debconf [debconf-2.0] 1.5.73 > ii libc6 2.29-10 > ii libgcc-s1 10-20200222-1 > ii libpam0g 1.3.1-5 > ii libqt5core5a 5.12.5+dfsg-9 > ii libqt5dbus5 5.12.5+dfsg-9 > ii libqt5gui55.12.5+dfsg-9 > ii libqt5network55.12.5+dfsg-9 > ii libqt5qml55.12.5-5 > ii libqt5quick5 5.12.5-5 > ii libstdc++610-20200222-1 > ii libsystemd0 244.3-1 > ii libxcb-xkb1 1.13.1-5 > ii libxcb1 1.13.1-5 > ii qml-module-qtquick2 5.12.5-5
Bug#959229: gammu-smsd: systemd unit file references /etc/sysconfig/gammu-smsd instead of /etc/default/gammu-smsd
Package: gammu-smsd Version: 1.40.0-1 Severity: normal Dear Maintainer, The contrib/init/gammu-smsd.service that is packaged in the debian package has references to the folder /etc/sysconfig/gammu-smsd which doesn't exist in debian. It should be /etc/default/gammu-smsd instead -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gammu-smsd depends on: ii adduser3.118 ii libc6 2.28-10 ii libgammu8 1.40.0-1 ii libgsmsd8 1.40.0-1 ii lsb-base 10.2019051400 gammu-smsd recommends no packages. Versions of packages gammu-smsd suggests: ii gammu 1.40.0-1 pn gammu-doc -- Configuration Files: /etc/gammu-smsdrc changed [not included] -- no debconf information
Bug#959074: (no subject)
Please ignore and close this bug It actually isn't a bug, everything is working fine Apologies
Bug#959074: apache2: dh_apache2 doesn't detect conf filename correctly
Package: apache2 Version: 2.4.38-3+deb10u3 Severity: normal Dear Maintainer, I have this file "kalkun.apache2" containing this line: conf debian/kalkun.conf dh_apache2 produces this # Automatically added by dh_apache2/UNDECLARED if true; then if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper for conf in kalkun ; do apache2_invoke enconf $conf || exit 1 done fi fi # End automatically added section While it should produce this (note the difference of the filename in "for conf in kalkun.conf ; do" # Automatically added by dh_apache2/UNDECLARED if true; then if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper for conf in kalkun.conf ; do apache2_invoke enconf $conf || exit 1 done fi fi # End automatically added section There is no such problem when using "site" instead of "conf" in kalkun.apache2 -- Package-specific info: -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apache2 depends on: ii apache2-bin2.4.38-3+deb10u3 ii apache2-data 2.4.38-3+deb10u3 ii apache2-utils 2.4.38-3+deb10u3 ii dpkg 1.19.7 ii lsb-base 10.2019051400 ii mime-support 3.62 ii perl 5.28.1-6 ii procps 2:3.3.15-2 Versions of packages apache2 recommends: ii ssl-cert 1.0.39 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii chromium [www-browser] 80.0.3987.162-1~deb10u1 ii firefox-esr [www-browser]68.7.0esr-1~deb10u1 ii konqueror [www-browser] 4:18.12.0-1 ii links [www-browser] 2.18-2 ii lynx [www-browser] 2.8.9rel.1-3 ii opera-stable [www-browser] 68.0.3618.56 Versions of packages apache2-bin depends on: ii libapr1 1.6.5-1+b1 ii libaprutil1 1.6.1-4 ii libaprutil1-dbd-sqlite3 1.6.1-4 ii libaprutil1-ldap 1.6.1-4 ii libbrotli1 1.0.7-2 ii libc62.28-10 ii libcurl4 7.64.0-4+deb10u1 ii libjansson4 2.12-1 ii libldap-2.4-22.4.47+dfsg-3+deb10u1 ii liblua5.2-0 5.2.4-1.1+b2 ii libnghttp2-141.36.0-2+deb10u1 ii libpcre3 2:8.39-12 ii libssl1.11.1.1d-0+deb10u3 ii libxml2 2.9.4+dfsg1-7+b3 ii perl 5.28.1-6 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii chromium [www-browser] 80.0.3987.162-1~deb10u1 ii firefox-esr [www-browser]68.7.0esr-1~deb10u1 ii konqueror [www-browser] 4:18.12.0-1 ii links [www-browser] 2.18-2 ii lynx [www-browser] 2.8.9rel.1-3 ii opera-stable [www-browser] 68.0.3618.56 Versions of packages apache2 is related to: ii apache2 2.4.38-3+deb10u3 ii apache2-bin 2.4.38-3+deb10u3 -- Configuration Files: /etc/apache2/ports.conf changed: Listen 80 Listen 443 Listen 443 -- no debconf information
Bug#942513: linux 5.2.0-0.bpo.3-amd64: amdgpu doesn't find firmware
A workaround/fix is to patch /usr/share/initramfs-tools/hook-functions this
way (see patch attached)
That way, the firmware will be copied from
/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/
to this dir in the initramfs
usr/lib/firmware/amdgpu/
instead of
usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/
After that, at boot-time the amdgpu firmware is found.
Please note that after patching it is necessary to run this command:
# update-initramfs -u -k
BTW: #933733 and #942513 may be duplicates.
Regards
Le samedi 28 décembre 2019, 19:29:49 CET Fab Stz a écrit :
> Hello,
>
> Problem is still present in "5.3.0-0.bpo.2-amd64"
>
> It also looks similar to #933733 which I updated. Could these
> issues be duplicates ?
>
> Regards
> Fab--- hook-functions.bak 2019-08-23 03:11:27.0 +0200
+++ hook-functions 2019-12-28 20:07:32.732539852 +0100
@@ -101,7 +101,7 @@
if [ -e "/lib/firmware/${version}/${firmware}" ]; then
copy_file firmware \
- "/lib/firmware/${version}/${firmware}"
+ "/lib/firmware/${version}/${firmware}" "/lib/firmware/${firmware}"
else
copy_file firmware "/lib/firmware/${firmware}"
fi
Bug#933733: linux-image-4.19.0-5-amd64: amdgpu does not find installed firmware (Also "5.3.0-0.bpo.2-amd64")
Le samedi 28 décembre 2019, 19:21:47 CET Fab Stz a écrit :
> Hello,
>
> I have an equivalent problem with "5.3.0-0.bpo.2-amd64"
>
> [drm:amdgpu_pci_probe [amdgpu]] *ERROR* amdgpu requires firmware installed
>
> I have both "4.19.0-6-amd64" installed and "5.3.0-0.bpo.2-amd64"
>
> I checked the content of "/boot/initrd.img-5.3.0-0.bpo.2-amd64" which is the
> file used by grub according to /boot/grub/grub.cfg. Please find it attached
>
> # lsinitramfs /boot/initrd.img-5.3.0-0.bpo.2-amd64 | grep amdgpu >
> lsinitramfs.out.txt
>
> The firmware files are there, but
> - on 4.19 they are in folder usr/lib/firmware/amdgpu/
> - on 5.3 they are in folder usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/
>
> Could that difference in location be the cause ? How to get it working ?
>
> Regards
A workaround/fix is to patch /usr/share/initramfs-tools/hook-functions this
way (see patch attached)
That way, the firmware will be copied from
/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/
to this dir in the initramfs
usr/lib/firmware/amdgpu/
instead of
usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/
After that, at boot-time the amdgpu firmware is found.
Please note that after patching it is necessary to run this command:
# update-initramfs -u -k
BTW: #933733 and #942513 may be duplicates.
Regards--- hook-functions.bak 2019-08-23 03:11:27.0 +0200
+++ hook-functions 2019-12-28 20:07:32.732539852 +0100
@@ -101,7 +101,7 @@
if [ -e "/lib/firmware/${version}/${firmware}" ]; then
copy_file firmware \
- "/lib/firmware/${version}/${firmware}"
+ "/lib/firmware/${version}/${firmware}" "/lib/firmware/${firmware}"
else
copy_file firmware "/lib/firmware/${firmware}"
fi
Bug#942513: linux 5.2.0-0.bpo.3-amd64: amdgpu doesn't find firmware
Hello, Problem is still present in "5.3.0-0.bpo.2-amd64" It also looks similar to #933733 which I updated. Could these issues be duplicates ? Regards Fab
Bug#933733: linux-image-4.19.0-5-amd64: amdgpu does not find installed firmware (Also "5.3.0-0.bpo.2-amd64")
Hello, I have an equivalent problem with "5.3.0-0.bpo.2-amd64" [drm:amdgpu_pci_probe [amdgpu]] *ERROR* amdgpu requires firmware installed I have both "4.19.0-6-amd64" installed and "5.3.0-0.bpo.2-amd64" I checked the content of "/boot/initrd.img-5.3.0-0.bpo.2-amd64" which is the file used by grub according to /boot/grub/grub.cfg. Please find it attached # lsinitramfs /boot/initrd.img-5.3.0-0.bpo.2-amd64 | grep amdgpu > lsinitramfs.out.txt The firmware files are there, but - on 4.19 they are in folder usr/lib/firmware/amdgpu/ - on 5.3 they are in folder usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/ Could that difference in location be the cause ? How to get it working ? Regards etc/ld.so.conf.d/20-amdgpu.conf usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/banks_k_2_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_k_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_mc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_mec.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_sdma.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_sdma1.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_uvd.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/bonaire_vce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_mec.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_mec2.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_sdma.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_sdma1.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_uvd.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/carrizo_vce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_mec.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_mec2.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_sdma.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_sdma1.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_uvd.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/fiji_vce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_k_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_mc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hainan_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_k_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_mc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_mec.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_sdma.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_sdma1.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_smc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_uvd.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/hawaii_vce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_mec.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_sdma.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_sdma1.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_uvd.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kabini_vce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_ce.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_me.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_mec.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_mec2.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_pfp.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_rlc.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_sdma.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_sdma1.bin usr/lib/firmware/5.3.0-0.bpo.2-amd64/amdgpu/kaveri_uvd.bin
Bug#942513: linux 5.2.0-0.bpo.3-amd64: amdgpu doesn't find firmware
Le jeudi 17 octobre 2019, 17:54:28 CEST Ben Hutchings a écrit : > > and in > > # lsinitramfs /boot/initrd.img-5.2.0-0.bpo.3-amd64 | grep firmware | grep > > amdgpu | wc > > --> 289 lines > > > > $ dpkg -l : > > > > ii firmware-amd-graphics 20190717-2~bpo10+1 all > > …but this seems to rule that out. Are you sure you booted with this > version of the initramfs? Could you try rebooting? I double checked and that's indeed the initramfs file that is used. In grub config is as such : linux /boot/vmlinuz-5.2.0-0.bpo.3-amd64 root=UUID=58063ba7-15cf-4581-bf43-5da4b3486394 ro quiet zswap.enabled=1 zswap.max_pool_percent=20 drm.edid_firmware=DVI-D-1:edid/1024x768_75-F15.bin initrd /boot/initrd.img-5.2.0-0.bpo.3-amd64 Removing "drm.edid_firmware=DVI-D-1:edid/1024x768_75-F15.bin" doesn't workaround the issue. > If you run: > > modprobe -r amdgpu && modprobe amdpgu > > does the graphics driver start working? Yes it does ! Regards Fab
Bug#942513: linux 5.2.0-0.bpo.3-amd64: amdgpu doesn't find firmware
Source: linux Severity: normal Dear Maintainer, On buster with linux image 5.2.0-0.bpo.3-amd64 at boot time I have this error message : "*ERROR* amdgpu requires firmware installed" [1.317558] [drm] amdgpu kernel modesetting enabled. [1.317812] [drm:amdgpu_pci_probe [amdgpu]] *ERROR* amdgpu requires firmware installed But firmware is actually installed both in # ls /usr/lib/firmware/amdgpu/ | wc --> 289 lines and in # lsinitramfs /boot/initrd.img-5.2.0-0.bpo.3-amd64 | grep firmware | grep amdgpu | wc --> 289 lines $ dpkg -l : ii firmware-amd-graphics 20190717-2~bpo10+1 all -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#939484: welle.io: Missing binary dependency : qml-module-qtcharts
Package: welle.io Version: 2.0~beta2-2 Severity: normal Dear Maintainer, Please add this binary dependency : "qml-module-qtcharts" Otherwise some components like "Spectrum" won't be displayed in the GUI. (And probably also Constellation & Impulse) -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages welle.io depends on: ii libasound2 1.1.8-1 ii libc6 2.28-10 ii libfaad2 2.8.8-3 ii libfftw3-single3 3.3.8-2 ii libgcc11:8.3.0-6 ii libmp3lame03.100-2+b1 ii libmpg123-01.25.10-2 ii libqt5charts5 5.11.3-2 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5multimedia5 5.11.3-2 ii libqt5multimedia5-plugins 5.11.3-2 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5widgets5 5.11.3+dfsg1-1 ii librtlsdr0 0.6-1 ii libsoapysdr0.6 0.6.1-4+b1 ii libstdc++6 8.3.0-6 ii qml-module-qt-labs-settings5.11.3-4 ii qml-module-qtquick-controls5.11.3-2 ii qml-module-qtquick-controls2 5.11.3+dfsg-2 ii qml-module-qtquick-dialogs 5.11.3-2 ii qml-module-qtquick-layouts 5.11.3-4 ii qml-module-qtquick-localstorage5.11.3-4 ii qml-module-qtquick-privatewidgets 5.11.3-2 ii qml-module-qtquick-templates2 5.11.3+dfsg-2 ii qml-module-qtquick-window2 5.11.3-4 ii qml-module-qtquick25.11.3-4 welle.io recommends no packages. welle.io suggests no packages. -- no debconf information
Bug#934749: welle.io: some icons & widgets not displayed
Bug report for KDE can be found here: https://bugs.kde.org/show_bug.cgi?id=411127
Bug#916595: vlc: program doesn't close its process in some cases
Hello, There is a ticket on the VLC side that reports a similar issue with VLC on macOS. https://trac.videolan.org/vlc/ticket/20627 I added the reference to this debian bug report on that VLC ticket. Disabling hardware acceleration in VLC as suggested in that report is the current workaround that fixed the issue for me.
Bug#916595: vlc: program doesn't close its process in some cases
Package: vlc Version: 3.0.7-1 Followup-For: Bug #916595 Dear Maintainer, I have the same issue here. On buster, and also with vlc package 3.0.7.1-3 from testing (installed on buster) I noticed that it doesn't happen if I stop the video before closing VLC. It I close VLC white it is playin the video, VLC doesn't close. Playing stops but VLC remains in the system tray, it is even possible to get the list of actions when clicking on its icon in the system tray, but VLC doesn't respond. The VLC GUI can be restored but it is blank. The only way to close it is by killing it. My system uses VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev cb) CPU/APU is AMD Athlon 200GE with Vega3 graphics. Video driver is amdgpu -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vlc depends on: ii vlc-bin 3.0.7-1 ii vlc-plugin-base 3.0.7-1 ii vlc-plugin-qt3.0.7-1 ii vlc-plugin-video-output 3.0.7-1 Versions of packages vlc recommends: ii vlc-l10n 3.0.7-1 ii vlc-plugin-notify 3.0.7-1 ii vlc-plugin-samba 3.0.7-1 ii vlc-plugin-skins2 3.0.7-1 ii vlc-plugin-video-splitter 3.0.7-1 ii vlc-plugin-visualization 3.0.7-1 vlc suggests no packages. Versions of packages libvlc-bin depends on: ii libc62.28-10 ii libvlc5 3.0.7-1 Versions of packages libvlc5 depends on: ii libc62.28-10 ii libvlccore9 3.0.7-1 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.7-1 Versions of packages vlc-bin depends on: ii libc6 2.28-10 ii libvlc-bin 3.0.7-1 ii libvlc5 3.0.7-1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-19 ii libaom0 1.0.0-3 ii libarchive13 3.3.3-4 ii libaribb24-0 1.0.3-2 ii libasound2 1.1.8-1 ii libass9 1:0.14.0-2 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libavc1394-0 0.5.4-5 ii libavcodec58 7:4.1.4-1~deb10u1 ii libavformat587:4.1.4-1~deb10u1 ii libavutil56 7:4.1.4-1~deb10u1 ii libbasicusageenvironment12018.11.26-1.1 ii libbluray2 1:1.1.0-1 ii libc62.28-10 ii libcairo21.16.0-4 ii libcddb2 1.3.2-6 ii libchromaprint1 1.4.3-3 ii libcrystalhd31:0.0~git20110715.fdd2f19-13 ii libdbus-1-3 1.12.16-1 ii libdc1394-22 2.2.5-1 ii libdca0 0.0.6-1 ii libdvbpsi10 1.3.2-1 ii libdvdnav4 6.0.0-1 ii libdvdread4 6.0.1-1 ii libebml4v5 1.3.6-2 ii libfaad2 2.8.8-3 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libfribidi0 1.0.5-3.1 ii libgcc1 1:8.3.0-6 ii libgcrypt20 1.8.4-5 ii libglib2.0-0 2.58.3-2 ii libgnutls30 3.6.7-4 ii libgpg-error01.35-1 ii libgroupsock82018.11.26-1.1 ii libharfbuzz0b2.3.1-1 ii libixml101:1.8.4-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libkate1 0.4.1-9 ii liblirc-client0 0.10.1-5.2 ii liblivemedia64 2018.11.26-1.1 ii liblua5.2-0 5.2.4-1.1+b2 ii libmad0 0.15.1b-10 ii libmatroska6v5 1.4.9-1 ii libmicrodns0 0.0.10-1 ii libmpcdec6 2:0.1~r495-1+b2 ii libmpeg2-4 0.5.1-8 ii libmpg123-0 1.25.10-2 ii libmtp9 1.1.16-2 ii libncursesw6 6.1+20181013-2 ii libnfs12 3.0.0-2 ii libogg0
Bug#934749: welle.io: some icons & widgets not displayed
Upstream bugreport can be found here : https://github.com/AlbrechtL/welle.io/issues/387
Bug#934749: welle.io: some icons & widgets not displayed
Hello, I found out that the problem is actually the package "qml-module-org-kde- qqc2desktopstyle" which is installed with plasma/kde When one uses that desktop, this package can not be removed. Moreover, this is the style that is used as soon as one uses KDE/Plasma However, when I rename the folder /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/ Controls.2/org.kde.desktop then I don't have anymore these icon & display issues Nevertheless it is possible to define environment Variables for Qt Quick Controls 2 :) Thus the workaround for now is to load welle-io with QT_QUICK_CONTROLS_STYLE defined The styles that work best are : - Universal - designer With : - Material - Imagine - Fusion there are some issues (with the dropdown list, or colors of text/icons depending on background) With "org.kde.desktop" there are even more issues (that I described initially in this bug report) My current choice is running it with Universal (which can also be themed): QT_QUICK_CONTROLS_STYLE=Universal welle-io Other ways to control the QML style are defined here (either in the code configuration or through env Variables): https://doc.qt.io/qt-5/qtquickcontrols2-environment.html https://doc.qt.io/qt-5/qtquickcontrols2-configuration.html For reference, the version of qml-module-org-kde-qqc2desktopstyle on my system at the time of the report is 5.54.0-1 (currently in buster/stable, testing & sid)
Bug#934749: welle.io: some icons & widgets not displayed
Package: welle.io Version: 2.0~beta2-1 Severity: normal Dear Maintainer, When opening welle.io, the top left (menu - 3 horizontal bars) & top right (options) icons are missing. Loudspeaker (in service overview widget) icon is missing too Same problem with the dropdown menu "Favorites" which is not displayed, as well as the star icon and as well as vertical "3 dots" icon. There is no such problem with the Appimage provided on the official website. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (991, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages welle.io depends on: ii libc6 2.28-10 ii libfaad2 2.8.8-3 ii libfftw3-single3 3.3.8-2 ii libgcc11:8.3.0-6 ii libmp3lame03.100-2+b1 ii libmpg123-01.25.10-2 ii libqt5charts5 5.11.3-2 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5multimedia5 5.11.3-2 ii libqt5multimedia5-plugins 5.11.3-2 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5widgets5 5.11.3+dfsg1-1 ii librtlsdr0 0.6-1 ii libsoapysdr0.6 0.6.1-4+b1 ii libstdc++6 8.3.0-6 ii qml-module-qt-labs-settings5.11.3-4 ii qml-module-qtquick-controls5.11.3-2 ii qml-module-qtquick-controls2 5.11.3+dfsg-2 ii qml-module-qtquick-dialogs 5.11.3-2 ii qml-module-qtquick-layouts 5.11.3-4 ii qml-module-qtquick-localstorage5.11.3-4 ii qml-module-qtquick-privatewidgets 5.11.3-2 ii qml-module-qtquick-templates2 5.11.3+dfsg-2 ii qml-module-qtquick-window2 5.11.3-4 ii qml-module-qtquick25.11.3-4 welle.io recommends no packages. welle.io suggests no packages.
Bug#930508: installation-reports: Corrupt display after grub as soon as kernel loads - buster netinst iso
Please find updated system info attached. The ones added by reportbug are those of my previous system. 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex [1022:15d0] Subsystem: ASUSTeK Computer Inc. Device [1043:876b] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU [1022:15d1] Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU [1022:15d1] 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus A [1022:15db] Kernel driver in use: pcieport 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:876b] Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:876b] 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 0 [1022:15e8] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 1 [1022:15e9] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 2 [1022:15ea] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 3 [1022:15eb] Kernel driver in use: k10temp Kernel modules: k10temp 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 4 [1022:15ec] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 5 [1022:15ed] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 6 [1022:15ee] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 7 [1022:15ef] 01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller [1022:43d5] (rev 01) Subsystem: ASMedia Technology Inc. Device [1b21:1142] Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller [1022:43c8] (rev 01) Subsystem: ASMedia Technology Inc. Device [1b21:1062] Kernel driver in use: ahci Kernel modules: ahci 01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge [1022:43c6] (rev 01) Kernel driver in use: pcieport 02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01) Kernel driver in use: pcieport 02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01) Kernel driver in use: pcieport 02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01) Kernel driver in use: pcieport 02:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01) Kernel driver in use: pcieport 02:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port [1022:43c7] (rev 01) Kernel driver in use: pcieport 07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15) Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1043:8677] Kernel driver in use: r8169 Kernel modules: r8169 08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev cb) Subsystem: ASUSTeK Computer Inc. Device [1043:876b] Kernel driver in use: amdgpu Kernel modules: amdgpu 08:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Raven/Raven2/Fenghuang HDMI/DP Audio Controller [1002:15de] Subsystem: ASUSTeK Computer Inc. Device [1043:876b] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 08:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security
Bug#930508: installation-reports: Corrupt display after grub as soon as kernel loads - buster netinst iso
Package: installation-reports Severity: normal Dear Maintainer, I'm booting the latest weekly netinst iso to install Buster. I'm facing corrupt display as soon as grub starts loading the kernel. Grub's display is fine. [1] The only workaround I found working is setting these parameters to the kernel vga=794 or vga=791 for example. My System is ASUS Prime B450M-A with AMD Athlon 200GE CPU (with integrated vega graphics), and no additional video card. This is with the latest weekly netinst iso for buster (10/Jun/2019) It also happened with the one of 27/May. I don't know if this is a regression from previous versions (buster or stretch) since I didn't test them with that hardware Regards, [1] https://framapic.org/lbQZBKAocMy9/wpvIcPEyMzIY.jpg (URL valid 1 year) -- Package-specific info: Boot method: CD Image version: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: Machine: ASUS Prime B450M-A with AMD Athlon 200GE CPU (with Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="9 (stretch) - installer build 20170615" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82946GZ/PL/GL Memory Controller Hub [8086:2970] (rev 02) lspci -knn: Subsystem: Intel Corporation 82946GZ/PL/GL Memory Controller Hub [8086:2970] lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 82946GZ/PL/GL PCI Express Root Port [8086:2971] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82946GZ/GL Integrated Graphics Controller [8086:2972] (rev 02) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: Kernel modules: snd_hda_intel lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev e1) lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge [8086:27b8] (rev 01) lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7336] lspci -knn: 00:1f.2 IDE
Bug#771339: linux: linux-headers 3.16 Makefile contains VERSION=2 PATCHLEVEL=6
Le mardi 11 juin 2019, 21:41:25 CEST Ben Hutchings a écrit : > They should be using "make kernelversion" instead of looking for > variable assignments the Makefile. > > This is not even a Debian-specific problem any more. Looking for > variable assignments in the Makefile will break whenever the kernel is > built out-of-tree (since Linux 4.20). Oh, ok. Thank you for the tip.
Bug#771339: linux: linux-headers 3.16 Makefile contains VERSION=2 PATCHLEVEL=6
Source: linux Version: 4.9.0 or 4.19... probably any Followup-For: Bug #771339 Dear Maintainer, This bug still exists in linux 4.9 and 4.19 (stretch, stretch-backports and also buster) Like the first reporter, I tried compiling the amdgpu driver provided by AMD (through DKMS) and it is searching for the kernel version in that file. As a workaroung in the meantime, I manually set VERSION to 4 and PATCHLEVEL to 19 in /usr/src/linux-headers-4.9.0-9-amd64/Makefile or the equivalent for 4.19 -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#902573: firefox-esr: firefox 60.1.0esr requires nss >= 3.36.4
Package: firefox-esr Version: 60.0.1esr-2.0~fab1 Severity: serious Justification: fails to build from source (but built successfully in the past) When compiling firefox 60.1.0esr I get the following error : checking for NSS - version >= 3.36.4... no Which means the version check of nss while installing the dependencies is not up to date. -- Package-specific info: -- Addons package information -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox-esr depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libhunspell-1.6-0 1.6.1-2.0~fab1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.12-6 ii libnss3 2:3.36.1-1.0~fab1 ii libpango-1.0-01.40.5-1 ii libsqlite3-0 3.16.2-5+deb9u1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3+deb9u1 ii zlib1g1:1.2.8.dfsg-5 firefox-esr recommends no packages. Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-3 pn fonts-stix | otf-stix ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libgtk2.0-02.24.31-2 -- no debconf information
Bug#899160: firefox-esr: l10n language pack not detected with firefox-esr 60 (NEW)
Package: firefox-esr Version: 60.0.1esr-1.0~fab1 Severity: normal Tags: l10n Hello, I manually compiled firefox-esr 60.0.1 (personnal backport) on my stable system. I install both firefox-esr and firefox-esr-l10-fr of that version but the GUI doesn't show up in french, only in english. I Firefox add-ons menu there is no "language pack" option. Current workaround : I made a symlink to rename the language pack XPI package, reloaded firefox, after what there is a language pack section the firefox add-on menu. I had to disable/reenable the french language pack. BTW : on that screen there is a warning mentionning an unsigned language pack package now. # ln -s langpack-fr\@firefox-esr.mozilla.org.xpi langpack- fr\@firefox.mozilla.org.xpi BTW : there was no problem with my personnal backport of firefox 60.0 Could that be a packaging problem because the packages is named firefox-esr instead of firefox ? -- Package-specific info: -- Addons package information -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox-esr depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libhunspell-1.6-0 1.6.1-2.0~fab1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.12-6 ii libnss3 2:3.36.1-1.0~fab1 ii libpango-1.0-01.40.5-1 ii libsqlite3-0 3.23.1-1.0~fab1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3 ii zlib1g1:1.2.8.dfsg-5 firefox-esr recommends no packages. Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-3 pn fonts-stix | otf-stix ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libgtk2.0-02.24.31-2 -- no debconf information
