Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.
Adrian Bunk writes: > Paths of the input files changed: Ah, yeah, that would do it. Thanks for all your analysis! > The following in debian/rules work for me with current cmake: > CMakeTmp/CMakeFiles/Export/*/FLTK-Targets.cmake \ > CMakeTmp/CMakeFiles/Export/*/FLTK-Targets-none.cmake \ Got it, thanks, though I'm inclined to use find(1) so I'm not specifically tied to new cmake. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.
Adrian Bunk writes: > This makes it appear more likely that the root cause is a bug in FLTK or > a regression in CMake. Ah, yeah, FLTK's packaging post-processes some CMake output; it sounds like the relevant logic needs to be updated to work with current CMake. (Another option might have been to patch CMake's input, but I want to make some across-the-board tweaks that are best centralized modulo this sort of wrinkle.) I'll take a look when I get a chance. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1012026: Confirming #1012026 on Debian sid
I can confirm this bug using an Intel Alder Lake-P Integrated Graphics Controller as well (on a ThinkPad X1 Carbon Gen 10). The backtrace looks like this: [317658.882] (EE) Backtrace: [317658.882] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5600e5903bf9] [317658.883] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fdf7b847af0] [317658.883] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x15c) [0x7fdf7b89383c] [317658.883] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (raise+0x12) [0x7fdf7b847a52] [317658.883] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xcf) [0x7fdf7b832469] [317658.883] (EE) unw_get_proc_name failed: no unwind info found [-10] [317658.883] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7fdf7b832395] [317658.883] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7fdf7b840b02] [317658.883] (EE) 7: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0xc33) [0x5600e58bc113] [317658.884] (EE) 8: /usr/lib/xorg/Xorg (DRI2Authenticate+0xad) [0x5600e58be3ad] [317658.884] (EE) 9: /usr/lib/xorg/Xorg (DRI2GetParam+0x6cb) [0x5600e58bf12b] [317658.884] (EE) 10: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x5600e5790724] [317658.884] (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x5600e57946bc] [317658.884] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7fdf7b83320a] [317658.884] (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x7c) [0x7fdf7b8332bc] [317658.884] (EE) 14: /usr/lib/xorg/Xorg (_start+0x2a) [0x5600e577db6a] [317658.884] (EE) [317658.884] (EE) Fatal server error: [317658.884] (EE) Caught signal 6 (Aborted). Server aborting [317658.884] (EE) [317658.884] (EE) I can reliably reproduce it by invoking picard from the package of the same name under MATE. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#1019166: pd-lib-builder: bogus build-flags on armel and armhf
Package: pd-lib-builder
Version: 0.6.0-2
Severity: important
Dear Maintainer,
pd-lib-builder adds some optimization flags, depending on which target
architecture it detects.
unfortunately there are a couple of flaws:
- armv6 is detected with 'ifeq ($(shell uname), armv6l)' which i think cannot
work at all (instead if should call $(shell uname -m)
- this obviously fails when cross-compiling, and is not overridable
- the other check for arm ('ifeq ($(target.arch), arm)') is also too generic,
as it will wrongly match the 'armel' architecture (presumable *also* because
of the broken uname-check above), which does not like the '-mfloat-abi=hard'
flag and will fail (when including pthread.h) with
> fatal error: gnu/stubs-hard.h: No such file or directory
- it seems that it also breaks on 'armhf', as the resulting binaries throw a
bus-error...
the full optimization flags injected for "arm" (as found in the GNU-triplet)
are '-march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard'
probably we could use the following to narrow down the arm-architecture:
> gcc -march=native -Q --help=target|egrep "^[[:space:]]*-march="
this gives on the armdahl.debian.org:
| Debian architecture | -march |
|-||
| armel | armv5te|
| armhf | armv7-a+fp |
| arm64 | armv8-a|
or simply use some combination of DEB_HOST_ARCH, `dpkg-architecture
-qDEB_HOST_ARCH` and `dpkg --print-architecture`.
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pd-lib-builder depends on:
ii puredata-dev 0.52.2+ds0-1+exp1
pd-lib-builder recommends no packages.
pd-lib-builder suggests no packages.
-- no debconf information
Bug#1019153: php-horde-turba: fatal error: $name must be a string
Package: php-horde-turba Version: 4.2.23-1+deb10u1 Severity: important Dear Maintainer, after updating 'php-horde-turba' on my buster-system to the latest security patch, my users can no longer log into the horde webmail interface. instead they are greeted with an error message after authentication: ``` A fatal error has occurred $name must be a string in /usr/share/php/Horde/Registry.php:1679 1. Horde_Registry::appInit() /usr/share/horde/imp/index.php:19 2. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:298 3. Horde_Registry->_pushAppError() /usr/share/php/Horde/Registry.php:1622 4. Horde_Registry::appInit() /usr/share/horde/imp/index.php:19 5. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:298 6. Horde_Registry->callAppMethod() /usr/share/php/Horde/Registry.php:1617 7. Horde_Registry_Application->authenticated() /usr/share/php/Horde/Registry.php:1197 8. IMP_Application->_authenticated() /usr/share/php/Horde/Registry/Application.php:108 9. IMP_Auth::authenticateCallback() /usr/share/horde/imp/lib/Application.php:134 10. IMP_Imap->doPostLoginTasks() /usr/share/horde/imp/lib/Auth.php:243 11. IMP_Imap->updateFetchIgnore() /usr/share/horde/imp/lib/Imap.php:344 12. IMP_Mailbox::getSpecialMailboxes() /usr/share/horde/imp/lib/Imap.php:354 13. IMP_Mailbox_SessionCache->getSpecialMailboxes() /usr/share/horde/imp/lib/Mailbox.php:1364 14. IMP_Mailbox::getPref() /usr/share/horde/imp/lib/Mailbox/SessionCache.php:268 15. Horde_Prefs->getValue() /usr/share/horde/imp/lib/Mailbox.php:235 16. Horde_Prefs->_getScope() /usr/share/php/Horde/Prefs.php:304 17. Horde_Prefs->_loadScope() /usr/share/php/Horde/Prefs.php:397 18. Horde_Core_Prefs_Storage_Hooks->get() /usr/share/php/Horde/Prefs.php:467 19. Horde_Core_Hooks->callHook() /usr/share/php/Horde/Core/Prefs/Storage/Hooks.php:39 20. IMP_Hooks->prefs_init() /usr/share/php/Horde/Core/Hooks.php:61 21. Horde_Registry->call() /etc/horde/imp/hooks.php:29 22. Horde_Registry->callByPackage() /usr/share/php/Horde/Registry.php:1089 23. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:1128 24. Horde_Registry->_pushAppError() /usr/share/php/Horde/Registry.php:1640 25. Horde_Registry::appInit() /usr/share/horde/imp/index.php:19 26. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:298 27. Horde_Registry->callAppMethod() /usr/share/php/Horde/Registry.php:1617 28. Horde_Registry_Application->authenticated() /usr/share/php/Horde/Registry.php:1197 29. IMP_Application->_authenticated() /usr/share/php/Horde/Registry/Application.php:108 30. IMP_Auth::authenticateCallback() /usr/share/horde/imp/lib/Application.php:134 31. IMP_Imap->doPostLoginTasks() /usr/share/horde/imp/lib/Auth.php:243 32. IMP_Imap->updateFetchIgnore() /usr/share/horde/imp/lib/Imap.php:344 33. IMP_Mailbox::getSpecialMailboxes() /usr/share/horde/imp/lib/Imap.php:354 34. IMP_Mailbox_SessionCache->getSpecialMailboxes() /usr/share/horde/imp/lib/Mailbox.php:1364 35. IMP_Mailbox::getPref() /usr/share/horde/imp/lib/Mailbox/SessionCache.php:268 36. Horde_Prefs->getValue() /usr/share/horde/imp/lib/Mailbox.php:235 37. Horde_Prefs->_getScope() /usr/share/php/Horde/Prefs.php:304 38. Horde_Prefs->_loadScope() /usr/share/php/Horde/Prefs.php:397 39. Horde_Core_Prefs_Storage_Hooks->get() /usr/share/php/Horde/Prefs.php:467 40. Horde_Core_Hooks->callHook() /usr/share/php/Horde/Core/Prefs/Storage/Hooks.php:39 41. IMP_Hooks->prefs_init() /usr/share/php/Horde/Core/Hooks.php:61 42. Horde_Registry->call() /etc/horde/imp/hooks.php:29 43. Horde_Registry->callByPackage() /usr/share/php/Horde/Registry.php:1089 44. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:1128 45. Horde_Registry->callAppMethod() /usr/share/php/Horde/Registry.php:1635 46. Horde_Registry_Application->init() /usr/share/php/Horde/Registry.php:1197 47. Turba_Application->_init() /usr/share/php/Horde/Registry/Application.php:117 48. Turba::permissionsFilter() /usr/share/horde/turba/lib/Application.php:122 49. Turba_Factory_Driver->createFromConfig() /usr/share/horde/turba/lib/Turba.php:434 50. Turba_Factory_Driver->_create() /usr/share/horde/turba/lib/Factory/Driver.php:64 51. Turba_Driver_Share->__construct() /usr/share/horde/turba/lib/Factory/Driver.php:141 52. Turba_Factory_Driver->create() /usr/share/horde/turba/lib/Driver/Share.php:47 ``` downgrading to 4.2.23-1 fixes the issue (but of course this is somewhat suboptimal, giving the nature of security-upgrades). -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armhf (armv7l) Kernel: Linux 4.14.222-odroidxu4 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages php-horde-turba depends on: ii
Bug#1017772: OneTBB migration to testing stalled
Control: affects -1 src:onetbb It's due to a regression bug in GCC-12 that caused linker internal error on ppc64el: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772 Does not look like something I can look into. If you need it soon in testing, please go ahead and downgrade compiler to gcc-11 for ppc64el only. On Sun, 2022-09-04 at 10:50 +0530, Nilesh Patra wrote: > Hi Mo, > > It seems that the migration of oneTBB to testing is stalled (since 16 > days) due > to FTBFS on ppc64el with some linker errors[1] > I am not sure what is up there, could you please take a look? > > [1]: > https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1662266636=0 >
Bug#1019098: src:tbb: do not migrate. this source is deprecated in favor of src:onetbb
Source: tbb Version: 2020.3-2.1 Severity: serious src:tbb: do not migrate. this source is deprecated in favor of src:onetbb. The RM bug of src:tbb is filed at https://bugs.debian.org/1014990
Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1
Hello! On Sat, 2022-09-03 at 18:24 +0100, Adam D. Barratt wrote: > On Sat, 2022-09-03 at 14:06 -0300, Francisco M Neto wrote: > > Sent the package to mentors.d.n. Do you require an RFS? > > > > That's up to you, but for complete clarity we (i.e. the Release Team) > don't usually sponsor uploads for stable updates, unless we're involved > in the package in some way. Ahhh, understood. Thanks for the clarification! :) > It looks like your previous hydrapaper uploads have all had the same > sponsor, so maybe you could ask them? Will do. Cheers! -- Francisco signature.asc Description: This is a digitally signed message part
Bug#1019092: RFS: hydrapaper/2.0.2-1+deb11u1 [RC] -- Utility that sets background independently for each monitor
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "hydrapaper". This particular package is to be sent to Stable, because it contains an important bugfix (Bug#1010697), (which is already in Unstable but release is still pretty far away). It has been approved for bullseye-pu (See #1018977). * Package name: hydrapaper Version : 2.0.2-1+deb11u1 Upstream Author : Gabriele Musco * URL : https://gitlab.com/gabmus/HydraPaper * License : GPL-3+ * Vcs : https://salsa.debian.org/fmneto-guest/hydrapaper Section : graphics The source builds the following binary packages: hydrapaper - Utility that sets background independently for each monitor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hydrapaper/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hydrapaper/hydrapaper_2.0.2-1+deb11u1.dsc Changes since the last upload: hydrapaper (2.0.2-1+deb11u1) bullseye; urgency=medium . * debian/comtrol: - Added python3-pil to Depends: field (Closes: #1010697). Regards, -- Francisco Mariano Neto signature.asc Description: This is a digitally signed message part
Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1
Sent the package to mentors.d.n. Do you require an RFS? -- Francisco On Sat, 2022-09-03 at 17:53 +0100, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sat, 2022-09-03 at 13:14 -0300, Francisco M Neto wrote: > > Greetings > > > > On Sat, 2022-09-03 at 14:20 +0100, Adam D. Barratt wrote: > > > Control: tag -1 + moreinfo > > > > > > [...] > > > > [X] attach debdiff against the package in stable > > > > > > > > > > The debdiff is a _binary_ debdiff, between generated packages - the > > > intent is for a source debdiff, i.e. between the two source > > > packages / > > > .dscs. > > > > My mistake. Attached is the correct source debdiff. > > > > Thanks. Please go ahead. > > Regards, > > Adam > signature.asc Description: This is a digitally signed message part
Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1
Greetings
On Sat, 2022-09-03 at 14:20 +0100, Adam D. Barratt wrote:
> Control: tag -1 + moreinfo
>
> [...]
> > [X] attach debdiff against the package in stable
> >
>
> The debdiff is a _binary_ debdiff, between generated packages - the
> intent is for a source debdiff, i.e. between the two source packages /
> .dscs.
My mistake. Attached is the correct source debdiff.
Thanks,
Francisco
diff -Nru hydrapaper-2.0.2/debian/changelog hydrapaper-2.0.2/debian/changelog
--- hydrapaper-2.0.2/debian/changelog 2020-11-08 19:42:35.0 +
+++ hydrapaper-2.0.2/debian/changelog 2022-09-02 19:10:14.0 +
@@ -1,3 +1,10 @@
+hydrapaper (2.0.2-1+deb11u1) bullseye; urgency=medium
+
+ * debian/comtrol:
+- Added python3-pil to Depends: field (Closes: #1010697).
+
+ -- Francisco M Neto Fri, 02 Sep 2022 19:10:14 +
+
hydrapaper (2.0.2-1) unstable; urgency=medium
* New upstream version 2.0.2.
diff -Nru hydrapaper-2.0.2/debian/control hydrapaper-2.0.2/debian/control
--- hydrapaper-2.0.2/debian/control 2020-11-08 19:42:35.0 +
+++ hydrapaper-2.0.2/debian/control 2022-09-02 19:10:14.0 +
@@ -11,7 +11,7 @@
python3-willow,
libwnck-3-dev,
libgtk-3-dev
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Homepage: https://gitlab.com/gabmus/HydraPaper
Vcs-Browser: https://salsa.debian.org/fmneto-guest/hydrapaper
Vcs-Git: https://salsa.debian.org/fmneto-guest/hydrapaper.git
@@ -23,6 +23,7 @@
${misc:Depends},
${python3:Depends},
python3-gi,
+ python3-pil,
gir1.2-handy-1,
libhandy-1-0
Description: Utility that sets background independently for each monitor
diff -Nru hydrapaper-2.0.2/debian/copyright hydrapaper-2.0.2/debian/copyright
--- hydrapaper-2.0.2/debian/copyright 2020-11-08 19:42:35.0 +
+++ hydrapaper-2.0.2/debian/copyright 2022-09-02 19:08:51.0 +
@@ -8,7 +8,7 @@
License: GPL-3+
Files: debian/*
-Copyright: 2020 Francisco M Neto
+Copyright: 2022 Francisco M Neto
License: GPL-3+
License: GPL-3+
diff -Nru hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides
--- hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides 1970-01-01 00:00:00.0 +
+++ hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides 2022-09-02 19:10:14.0 +
@@ -0,0 +1,2 @@
+# Bug number is correct
+hydrapaper: improbable-bug-number-in-closes
signature.asc
Description: This is a digitally signed message part
Bug#1018987: nmu: minc-tools_2.3.00+dfsg-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu minc-tools_2.3.00+dfsg-9 . ANY . unstable . -m "rebuild against updated libminc"
Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: fmn...@fmneto.com
[ Reason ]
This solves the lack of a dependency in the binary package, as described in bug
#1010697. The only change is the addition of python3-pil to the Depends: field
in debian/control.
[ Impact ]
As is stands, the package is rendered unusable if the target host does not have
python3-pil installed. This solves the issue.
[ Tests ]
To keep the changes at a minimum, I have not added any automated tests. I did,
however, installed the new version of the package into a fresh stable
installation and the issue was not present.
[ Risks ]
Minimum risk involved. There are no packages that depend on hydrapaper.
[ 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 stable
[X] the issue is verified as fixed in unstable
[ Changes ]
The 2.0.2-1 version of the package lacks python3-pil in the Depends: field in
debian/control. Some users had success running hydrapaper because python3-pil
is a fairly common package in python applications, so there is a reasonable
chance that they already have it installed. I have added it to the appropriate
field in the control file, so now it is always installed as a dependency for
hydrapaper, solving the issue.
[ Other info ]
A fix for this bug is also present in version 3.3.1-2 in Unstable.
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /usr/share/lintian/overrides/hydrapaper
Control files: lines which differ (wdiff format)
Depends: dconf-gsettings-backend | gsettings-backend, python3:any, python3-gi,
{+python3-pil,+} gir1.2-handy-1, libhandy-1-0
Installed-Size: [-262-] {+266+}
Version: [-2.0.2-1-] {+2.0.2-1+deb11u1+}
Bug#1018888: nmu: elastix_5.0.1-3+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated insighttoolkit5"
Bug#1018839: nmu: insighttoolkit5_5.2.1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu insighttoolkit5_5.2.1-5 . ANY . unstable . -m "Rebuild against updated libminc"
Bug#1018793: bugs.debian.org: bad bug log for bugs #1017177 to #1017182
Package: bugs.debian.org Severity: important Dear Maintainer, it seems that bugs #1017177 to #1017182 (incl) are unavailable for browsing (and possibly other things as well). the error i get when accessing them via the webinterface is something like: > An error occurred. Error was: Bad bug log for Bug 1017181. Unable to read > records: state kill-init at end at /usr/local/lib/site_perl/Debbugs/Log.pm > line 320. this esp. annoying, as one of my packages has an RC-critical bug in this range, and I cannot even access the info about what failed. (I'm also afraid, that i won't be able to close the bug if the database is corrupted).
Bug#1018746: RFS: golang-github-mazznoer-colorgrad/0.9.0-1 -- Color scales library for maps, charts, data-visualization and creative coding
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-mazznoer-colorgrad": * Package name : golang-github-mazznoer-colorgrad Version : 0.9.0-1 * URL : https://github.com/mazznoer/colorgrad * License : MIT * Vcs : https://salsa.debian.org/go-team/packages/golang-github-mazznoer-colorgrad Section : golang The source builds the following binary packages: golang-github-mazznoer-colorgrad-dev - Color scales library for maps, charts, data-visualization and creative coding To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-mazznoer-colorgrad/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-mazznoer-colorgrad/golang-github-mazznoer-colorgrad_0.9.0-1.dsc Changes for the initial release: golang-github-mazznoer-colorgrad (0.9.0-1) unstable; urgency=low . * Initial release (Closes: TODO) Regards,
Bug#1009200: pytorch: (autopkgtest) needs update for python3.10: 'float' object cannot be interpreted as an integer
On Sat, 2022-08-27 at 08:55 +0200, Emanuele Rocca wrote: > On 08/04 09:36, Paul Gevers wrote: > > We are in the transition of making python3.10 the default Python > > versions > > [0]. With a recent upload of python3-defaults the autopkgtest of > > pytorch > > fails in testing when that autopkgtest is run with the binary > > packages of > > python3-defaults from unstable. It passes when run with only > > packages from > > testing. FYI, everything is already fixed in git a couple of months ago, and we are just waiting for the package to go through NEW queue.
Bug#1018110: RFS: hydrapaper/3.3.1-1 [RC] -- Utility that sets background independently for each monitor
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "hydrapaper": * Package name: hydrapaper Version : 3.3.1-1 Upstream Author : Gabriele Musco * URL : https://gitlab.com/gabmus/HydraPaper * License : GPL-3+ * Vcs : https://salsa.debian.org/fmneto-guest/hydrapaper Section : graphics The source builds the following binary packages: hydrapaper - Utility that sets background independently for each monitor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hydrapaper/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hydrapaper/hydrapaper_3.3.1-1.dsc Changes since the last upload: hydrapaper (3.3.1-1) unstable; urgency=medium . * New upstream version 3.3.1. * Bumped Standards-Version to 4.6.1. * Reorganized dependencies (application now uses GTK 4) (Closes: #1010697). Regards, -- Francisco Mariano Neto signature.asc Description: This is a digitally signed message part
Bug#1018091: RFS: starfighter/2.4-1 -- 2D scrolling shooter game
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "starfighter": * Package name: starfighter Version : 2.4-1 Upstream Author : diligentcir...@riseup.net * URL : http://pr-starfighter.github.io/ * License : GPL-3+ or CC-BY-SA-3.0, CC-BY-SA-3.0, CC-BY-3.0, public- domain, GPL-2+ or CC-BY-SA-3.0, GPL-2+ * Vcs : https://salsa.debian.org/fmneto-guest/starfighter Section : games The source builds the following binary packages: starfighter - 2D scrolling shooter game starfighter-data - 2D scrolling shooter game -- data files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/starfighter/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/starfighter/starfighter_2.4-1.dsc Changes since the last upload: starfighter (2.4-1) unstable; urgency=medium . * New upstream version: 2.4. * debian/control: Bumped Standards version to 4.6.1. * debian/source: created lintian-overrides file, to account for lintian false positive for very-long-line-length-in-source-file. * Removed patch 010_fix-autoconf-flags.patch; changes were incorporated by upstream. Regards, -- Francisco Mariano Neto signature.asc Description: This is a digitally signed message part
Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_allo
The bug should have been fixed in the -13 upload of src:onetbb The FTBFS occurred because of GCC-11 -> GCC-12 bump. According to upstream suggestion, we can simply turn off some warnings. Please let me know if this bug persists. On Wed, 2022-08-24 at 13:21 -0700, Diane Trout wrote: > On Fri, 2022-08-12 at 13:57 +0200, Lucas Nussbaum wrote: > > On 08/08/22 at 22:45 +0200, Richard B. Kreckel wrote: > > > I am unable to reproduce the above compile-time error. > > > > Hi, > > > > I can still reproduce it. > > > > Lucas > > > > I saw this bug floating around and thought I'd try building tbb as > well. > > The version in git on salsa built for me without issues. Though I was > wondering if maybe the build process behaves differently depending on > the cpu architecture? > > I've run into a few programs that behave differently at compile time > depending on the build cpu. > > > So here's the end of the sbuild run and the start of cat /proc/cpuinfo > on the machine I used. > > > +-- > + > > Summary > > > +-- > + > > Build Architecture: amd64 > Build Type: full > Build-Space: 2839101 > Build-Time: 1683 > Distribution: unstable > Host Architecture: amd64 > Install-Time: 82 > Job: /woldlab/loxcyc/home/diane/src/debian/onetbb_2021.5.0-13.dsc > Lintian: info > Machine Architecture: amd64 > Package: onetbb > Package-Time: 1775 > Source-Version: 2021.5.0-13 > Space: 2839101 > Status: successful > Version: 2021.5.0-13 > --- > - > Finished at 2022-08-24T18:51:48Z > Build needed 00:29:35, 2839101k disk space > diane@trog:~/src/debian/tbb$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family: 6 > model : 15 > model name: Intel(R) Xeon(R) CPU E5320 @ 1.86GHz > stepping : 7 > microcode : 0x66 > cpu MHz : 1748.216 > cache size: 4096 KB > physical id : 0 > siblings : 4 > core id : 0 > cpu cores : 4 > apicid: 0 > initial apicid: 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp: yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall > nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf > pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm > pti tpr_shadow dtherm > vmx flags : tsc_offset vtpr > bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass > l1tf mds swapgs itlb_multihit > bogomips : 3723.91 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: >
Bug#1017746: assimp: CMake variable DRACO_LIBRARIES is deprecated
Am 19. August 2022 21:33:06 MESZ schrieb "Timo Röhling" : >Source: assimp >Version: 5.2.4~ds0-3 >Severity: normal > >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > >Dear maintainer, > >the exported CMake configuration for draco has been overhauled >significantly, and the DRACO_LIBRARIES variable is no longer set. > >I have patched draco to keep the variable for the time being, but the >proper way to link against draco is the exported target > >draco::draco > >now. Please update assimp at your I'm not an expert when it comes to Cmake (being an autotools guy), so patches welcome mfh.her.fsr IOhannes
Bug#1017801: openmw: hangs at start (ffmpeg-5 related)
Package: openmw
Version: 0.47.0-1
Severity: important
Tags: upstream patch
Dear Maintainer,
When launching Morrowind with openmw, the game starts and you eventually come to
the initial game menu.
Clicking any item in the menu will freeze the game window.
The music keeps playing and the system stays otherwise reactive.
This is a known problem due to a bug in openmw that is triggered by ffmpeg-5.
The upstream bug-report can be found here:
https://gitlab.com/OpenMW/openmw/-/issues/6631
Upstream also has a fix, which I attach.
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openmw depends on:
ii libavcodec597:5.1-2+b1
ii libavformat59 7:5.1-2+b1
ii libavutil57 7:5.1-2+b1
ii libboost-filesystem1.74.0 1.74.0-16.1+b1
ii libboost-iostreams1.74.01.74.0-16.1+b1
ii libboost-program-options1.74.0 1.74.0-16.1+b1
ii libbullet3.06 3.06+dfsg-4+b1
ii libc6 2.34-4
ii libgcc-s1 12.1.0-8
ii libgl1 1.4.0-1
ii liblz4-11.9.3-2
ii libmyguiengine3debian1v53.4.1+dfsg-1
ii libopenal1 1:1.19.1-2
ii libopenscenegraph1613.6.5+dfsg1-7+b5
ii libopenthreads213.6.5+dfsg1-7+b5
ii librecast1 1.5.1+git20210215.e75adf8-1+b1
ii libsdl2-2.0-0 2.0.22+dfsg-6
ii libstdc++6 12.1.0-8
ii libswresample4 7:5.1-2+b1
ii libswscale6 7:5.1-2+b1
ii libtinyxml2.6.2v5 2.6.2-6
ii openmw-data 0.47.0-1
Versions of packages openmw recommends:
ii openmw-launcher 0.47.0-1
openmw suggests no packages.
-- no debconf information
Description: Fix video hang with ffmpeg-5
Author: Dominique Martinet
Origin: upstream
Applied-Upstream:
https://gitlab.com/OpenMW/openmw/-/commit/436db8c0e55b0d5be43df982d15025ed0fc76c40
Last-Update: 2022-08-20
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- openmw.orig/apps/openmw/mwsound/ffmpeg_decoder.cpp
+++ openmw/apps/openmw/mwsound/ffmpeg_decoder.cpp
@@ -18,11 +18,15 @@
std::istream& stream =
*static_cast(user_data)->mDataStream;
stream.clear();
stream.read((char*)buf, buf_size);
-return stream.gcount();
+std::streamsize count = stream.gcount();
+if (count == 0)
+return AVERROR_EOF;
+return count;
+
}
catch (std::exception& )
{
-return 0;
+return AVERROR_UNKNOWN;
}
}
Bug#1009684: openmw: FTBFS with glibc 2.34
Source: openmw
Version: 0.47.0-1
Followup-For: Bug #1009684
Control: tags -1 patch
Ubuntu appears to have patched openmw to fix this issue.
Please find the patch attached.
Description: Assume SIGSTKSZ is not a constant
Origin: upstream,
https://gitlab.com/OpenMW/openmw/-/commit/98a7d90ee258ceef9c70b0b2955d0458ec46f048
Author: elsid
Last-Update: 2021-09-24
--- a/components/crashcatcher/crashcatcher.cpp
+++ b/components/crashcatcher/crashcatcher.cpp
@@ -56,8 +56,6 @@
static char argv0[PATH_MAX];
-static char altstack[SIGSTKSZ];
-
static struct {
int signum;
@@ -475,9 +473,10 @@
/* Set an alternate signal stack so SIGSEGVs caused by stack overflows
* still run */
+static char* altstack = new char [SIGSTKSZ];
altss.ss_sp = altstack;
altss.ss_flags = 0;
-altss.ss_size = sizeof(altstack);
+altss.ss_size = SIGSTKSZ;
sigaltstack(, nullptr);
memset(, 0, sizeof(sa));
Bug#1017772: GCC-12 internal error when compiling onetbb on ppc64el
Package: gcc-12 Version: 12.1.0-8 Severity: important This bug seems like a regression. GCC-11 has no issue compiling the same source. https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1660844413=0 [183/315] : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now-rdynamic test/CMakeFiles/test_join_node.dir/tbb/test_join_node.cpp.o -o gnu_12.1_cxx11_64_none/test_join_node -Wl,-rpath,/<>/obj-powerpc64le-linux-gnu/gnu_12.1_cxx11_64_none gnu_12.1_cxx11_64_none/libtbb.so.12.5 -ldl && : FAILED: gnu_12.1_cxx11_64_none/test_join_node : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now-rdynamic test/CMakeFiles/test_join_node.dir/tbb/test_join_node.cpp.o -o gnu_12.1_cxx11_64_none/test_join_node -Wl,-rpath,/<>/obj-powerpc64le-linux-gnu/gnu_12.1_cxx11_64_none gnu_12.1_cxx11_64_none/libtbb.so.12.5 -ldl && : /usr/bin/ld: internal error ../../ld/ldlang.c 6452 collect2: error: ld returned 1 exit status
Bug#1017731: iem-plugin-suite: fails to build with JUCE-7.0.2
Source: iem-plugin-suite Version: 1.11.1-1 Severity: normal Dear Maintainer, JUCE-7.0.2 (not yet in Debian, but soon) introduced some BREAKING-CHANGES.txt regarding matrix3D multiplication. iem-plugin-suite is affected by this. at least the following plugins fail to build: - AllRadDecoder -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017421: fltk1.3: reproducible builds: locale-specific month embedded in fltk.pdf
Vagrant Cascadian writes: > The month embedded in the TODAY variable is translatable, and thus > changes depending on the locale of the build environment. Good catch, thanks! > The attached patch updates debian/patches/debian-changes to use a > numeric date, which should be independent of locale. I presume another option would be to run date with LC_ALL set to C, particularly given that the actual content is all in English anyway. > It is unclear if this alone will make fltk1.3 build reproducibly, but it > should reduce the differences even if it does not solve all issues. I seem to recall some other wrinkles, but I'll be happy to move closer to reproducibility regardless. > ++TODAY=`date -ud'$(DEB_DATE)' +'%Y-%m-%s'`; \ ITYM '%Y-%m-%d' or '%F' -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade
The pam-chroot source code from Ed Schmollinger is currently at: https://github.com/gpjt/pam-chroot Maybe he is willing to create an GitHub Organization and add you as a developer. Or he even is willing switch to Salsa. Kind regards Matthias "Maddes" Bücher
Bug#1016709: pd-lib-builder: provide a dh-sequence-pdlibbuilder
Source: pd-lib-builder
Version: 0.6.0-1
Severity: wishlist
Many pd-externals use pd-lib-builder, and the d/rules look all very similar.
It would be great if we could use dh to remove the duplicate work.
1. check if the make-based build system actually uses Makefile.pdlibbuilder
2. add 'PDLIBBUILDER_DIR=/usr/share/pd-lib-builder/ prefix=/usr
pkglibdir=$(pkglibdir)'
to the dh_auto_(clean|build|test|install) invocations
3. autofix permissions of pd-externals
4. possibly remove the extraneous LICENSE.txt files that come with Pd
Also, once we have puredata64 in Debian, this would:
- check which binary package variants are built ('pd-*' vs 'pd64-*)
- automatically build both package kinds (if so requested), using different
flags
And there should be something like ${Pd:Depends} and ${Pd64:Depends}
check out the dh-sequence-kf5 how to switch the dh-buildsystem via a sequence
Bug#990047: timeshift: Not possible to browse content of snapshot via the gui
On Mon, 2022-08-01 at 22:26 +, Ludovic Poujol wrote: > Steeve, > > Good question. And, you're right, thanks ! > > I thought it was some kind of "internal browser" provided with > timeshift. But after looking more closely, it was actually trying to > start VSCode ! :s And it's the one that do not like to be run as > root. > > Not sure why or how it decided to use it instead of the Gnome file > browser. But apt remove of it "fixed" the issue. > > I don't see any settings for that in the timeshift GUI. I'm not sure > how > I can force it to use the default gnome file browser :( > > > Thanks > > -- > Ludovic Poujol Ludovic, Timeshift first uses xdg-open to call the default tool of your desktop environment as it in turn calls gvfs-open, kde-open, exo-open, gnome- open, etc. as appropriate. On my Debian desktop with KDE running xdg- open and kde-open launche Dolphin, but on my Pop_OS laptop xdg_open is not installed and there is no gvfs-open for some reason. In the event that xdg_open fails, Timeshift tries in order to launch nemo, nautilus, thunar, io.elementary.files, pantheon-files, marlin, and dolphin lastly. In your case it seems that maybe xdg-open is resulting in "code" being called due to your Gnome settings. The command `xdg-mime query default inode/directory` should report out what the default file browser is set to. You can also look in ~/.config/mimeapps.list to see what it is set to. I think you can just edit this file or run a command similar to `xdg-mime default org.gnome.Nautilus.desktop inode/directory` to make a change. Please let me know how this works out as it may be worth asking upstream for a more robust means of opening the default file manager. Thanks -Steve
Bug#779969: ITP: coreclr -- .NET Core Runtime
If it helps anyone else, you can install .NET on Debian from packages.microsoft.com following https://docs.microsoft.com/en-us/dotnet/core/install/linux-debian wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb sudo apt-get update && sudo apt-get install dotnet-runtime-6.0 dotnet-sdk-6.0 You need the dotnet-runtime package to run .NET applications and dotnet-sdk package to develop .NET applications. Fedora uses a similar naming convention for its packages https://packages.fedoraproject.org/pkgs/dotnet6.0/ . It would be awesome to see these packages in Debian one day.
Bug#994704: timeshift: Unable to init server: connection refused. possible pkexec misconfiguration for timeshift-laucher command
Bruno, I've not been able to reproduce this problem. Does it still happen for you? Thanks -Steve
Bug#990047: timeshift: Not possible to browse content of snapshot via the gui
Ludovic, This sounds to me like an issue with not being allowed to run your file browser with root permissions. If this is still a problem for you, which file browser are you using? Thanks -Steve
Bug#976805: Progress?
https://salsa.debian.org/pkg-security-team/imhex I forgot the current status. In my fuzzy memory there are some new dependencies to be packaged. On Sat, 2022-07-30 at 11:07 -0700, Dima Kogan wrote: > Hi. Is this coming along? What needs to happen to get this into the > repos? Do you need help? > > Thanks!
Bug#1016436: lldb-14: lldb malfunctions due to faulty python path (ModuleNotFoundError: No module named 'lldb.embedded_interpreter')
Package: lldb-14 Version: 1:14.0.6-2 Severity: normal Dear Maintainer, There is a misconfiguration somewhere in the build, that embeds a non-existent python path: $ lldb -P /usr/lib/local/lib/python3.10/dist-packages This causes lldb to emit an error when starting: $ lldb Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'lldb.embedded_interpreter' See https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1972855 for full description and a workaround. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lldb-14 depends on: ii libc62.33-8 ii libclang-cpp14 1:14.0.6-2 ii libedit2 3.1-20210910-1 ii libgcc-s112.1.0-7 ii liblldb-14 1:14.0.6-2 ii libllvm141:14.0.6-2 ii libncurses6 6.3+20220423-2 ii libstdc++6 12.1.0-7 ii libtinfo66.3+20220423-2 ii libxml2 2.9.14+dfsg-1+b1 ii llvm-14-dev 1:14.0.6-2 ii python3-lldb-14 1:14.0.6-2 ii zlib1g 1:1.2.11.dfsg-4 lldb-14 recommends no packages. lldb-14 suggests no packages. -- no debconf information
Bug#1016230: auctex: FTBFS: ! LaTeX Error: File `hypdoc.sty' not found.
tags 1016230 + pending thanks. > LN == Lucas Nussbaum [2022-7-29] [...] LN> During a rebuild of all packages in sid, your package failed to build LN> on amd64. Thanks for the report. It should be fixed by adding a Build-Depends-Indep on texlive-latex-extra. I'll test and upload a fixed package next week. -- Thanks, Davide
Bug#1003165: scikit-learn testing migration
I have a long-term power 9 VM (not QEMU) as testbed. I'm trying to investigate the issues for release architectures, but this package is too slow to build with QEMU (multiple hours). (abel.debian.org is also extremely slow for scikit-learn) I've not yet given up, but the build speed means I cannot address this issue in timely manner. On Thu, 2022-07-28 at 10:15 +0200, Andreas Tille wrote: > Hi Graham, > > Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs: > > Hi > > > > On Wed, 27 Jul 2022 at 17:57, M. Zhou wrote: > > > The previous segfault on armel becomes Bus Error on armel and armhf. > > > I can build it on Power9, but it seems that the test fails on power8 (our > > > buildd). > > > > In #1003165, one of the arm porters wrote they are happy to look at > > the bus errors, but the baseline issue should be fixed first. > > ... this was five months ago and silence since then. We've lost lots of > packages in testing and I see no progress here. It seems upstream is not > actually keen on working on this as well. Meanwhile they stepped forward > with new releases and I simply refreshed the issues for the new version > (which are the same and not solved). > > Currently we have bus errors on arm 32 bit architectures and a baseline > violation on power. If there is no solution at the horizon I'd vote for > excluding these three architectures instead of sit and wait (which is all > I can personally do in this topic). > > > > I have skimmed over the build logs and one of the main issues is the use > > > of > > > -march flags to enforce a certain baseline [1]: > > > > > > powerpc64le-linux-gnu-gcc: error: unrecognized command-line option > > > ‘-march=native’; did you mean ‘-mcpu=native’? > > > > This may be the cause of the test failures on power8. > > Could someone give this a try? I know I could use a porter box to do > so but my time is to limited to do it in a sensible time frame. > > Kind regards > > Andreas. >
Bug#1016194: RM: onednn [all] -- ROM; no longer build for arch:all
Package: ftp.debian.org Severity: normal I removed bin:onednn-doc from src:onednn because it feels like a maintenance burden to me, and this doc package has a very low popcon number. Thus, since we no longer build bin:onednn-doc, we need to remove it so that the package can migrate to testing. Thank you for using reportbug
Bug#1008369: scikit-learn testing migration
The previous segfault on armel becomes Bus Error on armel and armhf. I can build it on Power9, but it seems that the test fails on power8 (our buildd). On Wed, 2022-07-27 at 09:56 +0200, Andreas Tille wrote: > Control: tags -1 unreproducible > Control: tags -1 moreinfo > Control: severity -1 important > > Hi, > > BTW, there is another bug in scikit-learn, but I can't reproduce it and > have set tags accordingly. Could someone else please give it a try? > > Kind regards > > Andreas. > > Am Wed, Jul 20, 2022 at 09:23:28PM +0200 schrieb Andreas Tille: > > Hi Nilesh, > > > > Am Wed, Jul 20, 2022 at 06:21:19PM +0530 schrieb Nilesh Patra: > > > On 7/20/22 4:50 PM, Andreas Tille wrote: > > > > Before we stop progress in Debian for many other architectures since we > > > > cant't solve this on our own or otherwise are burning patience of > > > > upstream I'd alternatively consider droping armel as supported > > > > architecture. > > > > > > I am definitely +1 for this, however scikit-learn is a key package and > > > dropping > > > it from armel would mean dropping several revdeps as well. > > > I am a bit unsure if that is fine or not. > > > > Its not fine at all and I would not be happy about it. However, the other > > side of a key package is, that lots of package have testing removal warnings > > on architectures which are widely used and we have real trouble because of > > this. > > > > Kind regards > > > > Andreas. > > > > -- > > http://fam-tille.de > > > > >
Bug#1013940: New version of nfft breaks its autopkgtest (Was: nfft breaks pynfft autopkgtest on i386: Segmentation fault
Andreas Tille writes: > [1] https://salsa.debian.org/science-team/nfft/-/jobs/3041717 | + gcc -Wall -DNFFT_PRECISION_SINGLE -lnfft3f -lfftw3f -o simple_test simple_test.c | /usr/bin/ld: /tmp/ccaUJ49M.o: in function `simple_test_nfft_1d': | simple_test.c:(.text+0x2c): undefined reference to `nfftf_init_1d' [...] Please try listing simple_test.c ahead of the libraries, which the linker otherwise discards as apparently unneeded. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1014891: timeshift: New upstream release 22.06.3
On Wed, 2022-07-13 at 17:32 -0400, Boyuan Yang wrote: > Package: timeshift > Version: 22.06.1-0.1 > Severity: normal > X-Debbugs-CC: s...@swm1.com > > Dear Debian timeshift package maintainers, > > A new upstream release is available at > https://github.com/linuxmint/timeshift/releases/tag/22.06.3 . Please > consider packaging it. > > Thanks, > Boyuan Yang Boyuan, Thank you for this alert and for preparing 22.06.4 in the Salsa git repo. I had a very busy two weeks when this happened but am anticipating more time now to work on Timeshift updates. I see that 22.06.5 has been released so I will work on merging in that update. Thanks -Steve
Bug#1016011: ITP: pd-mapper -- Qualcomm PD mapper service
Am 25. Juli 2022 11:01:03 MESZ schrieb Arnaud Ferraris : >Package: wnpp >Severity: wishlist >Owner: Arnaud Ferraris >X-Debbugs-Cc: debian-de...@lists.debian.org, aferra...@debian.org > >* Package name: pd-mapper > Version : 0.0+git20220208 > Upstream Author : Bjorn Andersson >* URL : https://github.com/andersson/pd-mapper >* License : BSD > Programming Lang: C > Description : Qualcomm PD mapper service > >'pd-mapper' is the reference implementation for Qualcomm's Protection >Domain mapper service. It is required for userspace applications to >access the various remote processors (Wi-Fi, modem, sensors...) on >recent Qualcomm SoCs using the QRTR protocol. Just to note: AFAIK all Debian packages that currently use the "pd-" prefix belong to the "pure-data" universe, just like Python packages have a "python-" prefix. There is no formal "reservation" of that namespace, but I would expect quite some confusion if there are a few totally unrelated packages using the same naming scheme. There's even an exusting pd-mapping package So I humbly suggest to pick a name that reduces confusion, if possible. mfh.her.fsr IOhannes mfh.her.fsr IOhannes
Bug#1013495: asio: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Source: asio Version: 1:1.18.1-1 Followup-For: Bug #1013495 any news on this? this serious bug is triggering an AUTOREMOVAL of *multiple* of my packages in about two weeks, which i would like to avoid. gfmds IOhannes PS: re-sending, as i think my original email got lost between MUA and MTA
Bug#1015805: scikit-learn tries to access network during documentation build
Source: scikit-learn Version: 1.1.1-1 Severity: serious Justification: Policy section 4.9 violation There are loads of similar traceback message saying the documentation build has failed to retrieve some URL, like this: ``` generating gallery for auto_examples/decomposition... [ 30%] plot_faces_decomposition.py WARNING: /<>/examples/decomposition/plot_faces_decomposition.py failed to execute correctly: Traceback (most recent ca ll last): File "/<>/examples/decomposition/plot_faces_decomposition.py", line 36, in faces, _ = fetch_olivetti_faces(return_X_y=True, shuffle=True, random_state=rng) File "/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_olivetti_faces.py", line 117, in fetch_olivetti_faces mat_path = _fetch_remote(FACES, dirname=data_home) File "/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_base.py", line 1511, in _fetch_remote urlretrieve(remote.url, file_path) File "/usr/lib/python3.10/urllib/request.py", line 241, in urlretrieve with contextlib.closing(urlopen(url, data)) as fp: File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen return opener.open(url, data, timeout) File "/usr/lib/python3.10/urllib/request.py", line 519, in open response = self._open(req, data) File "/usr/lib/python3.10/urllib/request.py", line 536, in _open result = self._call_chain(self.handle_open, protocol, protocol + File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain result = func(*args) File "/usr/lib/python3.10/urllib/request.py", line 1391, in https_open return self.do_open(http.client.HTTPSConnection, req, File "/usr/lib/python3.10/urllib/request.py", line 1351, in do_open raise URLError(err) urllib.error.URLError: ``` This is clearly policy violation and should be patched. This issue is found during the QEMU build on ppc64el machine for the armel architecture, and it extremly slows down the building process likely due to URL access timeout. As a result, the URL access timeout took the whole night and the doc build is not yet finished by a half. Well, I guess I will have to wait for two or three days to see the discussed armel segfault in qemu with this problem unfixed.
Bug#1001661: re: notcurses: flaky autopkgtests on armhf
On Tue, 17 May 2022 22:31:14 +0100 peter green wrote: Version 3.0.7 seems to be be passing most of the time on armhf, though there were a few failures duing attempts to migrate gcc-12. The failures appear to be timeouts. Unfortunately 3.0.7 seems to be pretty consistently failing on s390x :( can this be closed by now? https://ci.debian.net/packages/n/notcurses/unstable/armhf/ does not show any failures for armhf since the upload of 3.0.7+dfsg.1-1. and while s390x fails consistently, this appears to be not a regression. i really would like to have my 'snd' package be able to migrate to testing and make it to bookworm in time. alternatively i could just drop the dependency on 'notcurses' gfmads IOhannes OpenPGP_signature Description: OpenPGP digital signature
Bug#1015200: [blender] libtbb2 deprecated in favor of src:onetbb
Source: blender Severity: important libtbb2 (src:tbb) has been deprecated (#1014990) in favor of libtbb12 (src:onetbb). And blender is still one of the reverse dependencies of libtbb2. Please migrate to the new library.
Bug#1007222: transition: onetbb
I've filed the RM bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014990 Seems that we still have a bunch of blockers -- so this is not likely happening soon. On Fri, 2022-07-15 at 20:16 +0200, Graham Inggs wrote: > Hi > > libtbb2 is now gone from testing. Please file a RM bug for src:tbb > against ftp.debian.org, but maybe tag it 'moreinfo' until it is clear > what will happen to libtbb2's reverse-dependencies still in unstable. > > Regards > Graham
Bug#1014990: RM: tbb -- ROM; deprecated in favor of src:onetbb
Package: ftp.debian.org Severity: normal Tags: +moreinfo We have (somewhat) done the src:tbb -> src:onetbb transition, and the old codebase src:tbb is now deprecated. Before we really remove src:tbb from unstable, we still have some packages not yet finished the transition. I'll later file bugs (if there isn't) against the reverse dependencies and let the bugs block this one. libtbb2 Reverse Depends: Depends: python3-openvdb (>= 2017~U7) Depends: libopenvdb9.1 (>= 2017~U7) Depends: libopenvdb-tools (>= 2017~U7) Depends: libgazebo11 (>= 2017~U7) Depends: casparcg-server (>= 2017~U7) Breaks: libtbbmalloc2 (<< 2020.3-1ubuntu2) Depends: libyade (>= 2017~U7) Depends: twopaco (>= 2017~U7) Depends: prusa-slicer (>= 2017~U7) Depends: salmon (>= 2017~U7) Depends: r-cran-rstanarm (>= 2017~U7) Depends: python3-openvdb (>= 2017~U7) Depends: libopenvdb8.1 (>= 2017~U7) Depends: libopenvdb-tools (>= 2017~U7) Depends: libosdcpu3.4.4 (>= 2017~U7) Depends: libopenimageio2.3 (>= 2017~U7) Replaces: libtbbmalloc2 (<< 2020.3-1ubuntu2) Depends: embree-tools (>= 2017~U7) Depends: mpqc3 (>= 2017~U7) Depends: libgazebo11 (>= 2017~U7) Depends: flexbar (>= 2017~U7) Depends: libembree3-3 (>= 2018~U6) Depends: blender (>= 2018~U6) Thank you for using reportbug
Bug#1000922: reopen
Control: reopen -1 Control: found -1 0.38.1-3 Simply upgrading llvm deps from 11 to 13 leads to regression for numba. I'm reverting this change back until the upstream source code can really support a newer version.
Bug#1014661: ITP: lodepng -- LodePNG is a PNG image decoder and encoder
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lodepng Version : git master Upstream Author : Lode Vandevenne * URL : https://lodev.org/lodepng/ * License : Zlib Programming Lang: C Description : LodePNG is a PNG image decoder and encoder More than one package of my insterest has this dependency, including the mujoco physics simulator. Thank you for using reportbug
Bug#1003397: ITP: rapidyaml -- a library to parse and emit YAML, and do it fast.
Control: retitle -1 RFP: rapidyaml -- a library to parse and emit YAML, and do it fast. Control: owner -1 w...@debian.org I'm giving up this ITP bug. Any one who is interested in this ITP can take it over.
Bug#1014570: RM: rocm-device-libs/experimental [all] -- ROM; the binary packages are arch-dependent now
Package: ftp.debian.org Severity: normal The latest rocm-device-libs package is no longer producing arch-indep binary packages. And we will keep working on arch-specific packages. The arch:all package is no longer useful and it was not automatically removed. Thank you for using reportbug
Bug#1014569: transition: flatbuffers
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition PyTorch 1.12 will need flatbuffers 2.X . Specifically I'm going to upload flatbuffers 2.0.6+dfsg1 to unstable. It has three reverse dependencies as per build-rdeps. vast [already ftbfs due to libfmt] #1001527 kodi [already ftbfs due to ffmpeg] #1004612 armnn [ok] 20.08-10 Seems that we can go ahead with this. Ben file: title = "flatbuffers"; is_affected = .depends ~ "libflatbuffers1" | .depends ~ "libflatbuffers2"; is_good = .depends ~ "libflatbuffers2"; is_bad = .depends ~ "libflatbuffers1"; Thank you for using reportbug
Bug#1011033: onnx: flaky autopkgtest on armhf: Arrays are not almost equal to 7 decimals
Control: severity -1 important I've uploaded 1.12 to unstable. Let's see whether the situation has been changed a little bit for armhf. Floating point precision is sometimes flaky indeed, but I think this would not be that fatal. So changing the severity down to important. If the flaky test no longer appears, I'll close it.
Bug#1014491: python3-torch: import fails: undefined symbol
Hi, Thanks for the bug report. I'm aware of the break, and other users have reported this issue some time before: https://lists.debian.org/debian-ai/2022/06/msg00060.html The break is due to onnx 1.12 upgrade. The pytorch version in the new queue works fine with onnx 1.12, as mentioned in the above mailing list post. If you would like to continue using pytorch 1.8 for a while, you may need to pin onnx to the previous version, or rollback using our snapshot archive. When dealing with the pytorch 1.12 upgrade, I lost (to be honest I would like to stick to 1.8 but we have to go through python 3.10 transition) access to build machines due to complicated reasons, and the access will not be recovered. So in order to continue the pytorch upgrade, I have to upload reverse dependencies to unstable early, so that I can build pytorch and upload to the NEW queue. Theoretically this bug can only be resolved when pytorch 1.12 passes the new queue. On Wed, 2022-07-06 at 14:01 -0700, Dima Kogan wrote: > Package: python3-torch > Version: 1.8.1-5+b1 > Severity: grave > X-Debbugs-Cc: none, Dima Kogan > > Hi. Thanks for maintaining pytorch. I can't imagine the pain it took to > get this packaged. Currently it doesn't work, unfortunately: > > $ python3 -mtorch > > Traceback (most recent call last): > File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main > mod_name, mod_spec, code = _get_module_details(mod_name, _Error) > File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details > return _get_module_details(pkg_main_name, error) > File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details > __import__(pkg_name) > File "/usr/lib/python3/dist-packages/torch/__init__.py", line 196, in > > from torch._C import * > ImportError: /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.8: undefined > symbol: > _ZN4onnx12optimization8OptimizeERKNS_10ModelProtoERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISA_EE > > This symbol is missing. I looked around, and I can't figure out which > package was supposed to provide it. Without it the linking fails, and > the package is unusable. Am I missing some dependency? > > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), > (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armhf > > Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.utf-8), LANGUAGE=en_US.utf-8 > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages python3-torch depends on: > ii libc6 2.33-7 > ii libdnnl22.6-1 > ii libgcc-s1 12.1.0-4 > ii libgloo00.0~git20220518.5b14351-1 > ii libgoogle-glog0v6 0.6.0-1 > ii libonnx11.12.0-1 > ii libprotobuf23 3.12.4-1+b2 > ii libstdc++6 12.1.0-4 > ii libtorch-test 1.8.1-5+b1 > ii libtorch1.8 1.8.1-5+b1 > ii python3 3.10.4-1+b1 > ii python3-future 0.18.2-5 > ii python3-numpy [python3-numpy-abi9] 1:1.21.5-1 > ii python3-pkg-resources 59.6.0-1 > ii python3-requests2.25.1+dfsg-2 > ii python3-six 1.15.0-2 > ii python3-typing-extensions 3.10.0.2-1 > ii python3-yaml5.4.1-1+b1 > ii python3.10 3.10.5-1 > > Versions of packages python3-torch recommends: > ii build-essential 12.9 > pn libtorch-dev > ii ninja-build 1.10.1-1 > pn pybind11-dev > > Versions of packages python3-torch suggests: > ii python3-hypothesis 5.43.3-1 > ii python3-pytest 6.2.5-1 > > -- no debconf information >
Bug#950919: cura: AMFReader plugin not loadable due to missing python3-trimesh
Package: cura Version: 5.0.0-1 Followup-For: Bug #950919 Dear Maintainer, can confirm this bug for 5.0.0-1 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.5 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:nds:en_GB:en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cura depends on: ii cura-engine 1:5.0.0-1 ii fdm-materials5.0.0-1 ii fonts-open-sans 1.11-2 ii python3 3.10.4-1+b1 ii python3-certifi 2020.6.20-1 ii python3-charon 4.13.0-1 ii python3-cryptography 3.4.8-2 ii python3-keyring 23.5.1-1 ii python3-pynest2d 5.0.0-1 ii python3-pyqt66.3.1-1 ii python3-requests 2.27.1+dfsg-1 ii python3-savitar 5.0.0-1 ii python3-sentry-sdk 1.6.0-1 ii python3-serial 3.5-1 ii python3-shapely 1.8.0-1+b1 ii python3-uranium 5.0.0-1 ii qml6-module-qt-labs-folderlistmodel 6.2.4+dfsg-6 ii qml6-module-qtqml-workerscript 6.2.4+dfsg-6 ii qml6-module-qtquick-controls 6.2.4+dfsg-6 ii qml6-module-qtquick-dialogs 6.2.4+dfsg-6 ii qml6-module-qtquick-layouts 6.2.4+dfsg-6 ii qml6-module-qtquick-templates6.2.4+dfsg-6 ii qml6-module-qtquick-window 6.2.4+dfsg-6 ii qt6-qpa-plugins 6.2.4+dfsg-8 ii uranium-plugins 5.0.0-1 Versions of packages cura recommends: ii python3-zeroconf 0.38.7-1 cura suggests no packages. -- no debconf information
Bug#1004787: aubio: diff for NMU version 0.4.9-4.2
Control: tags 1004787 + patch
Control: tags 1004787 + pending
Dear maintainer,
I've prepared an NMU for aubio (versioned as 0.4.9-4.2) and
uploaded it to DELAYED/0 (:facepalm:, that was actually unintentional, but i
guess it's too late now). Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru aubio-0.4.9/debian/changelog aubio-0.4.9/debian/changelog
--- aubio-0.4.9/debian/changelog 2021-09-09 20:11:53.0 +0200
+++ aubio-0.4.9/debian/changelog 2022-06-30 22:35:01.0 +0200
@@ -1,3 +1,12 @@
+aubio (0.4.9-4.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch to build against ffmpeg-5.0 (Closes: #1004787)
+ * Add salsa-ci configuration
+ * Call dh_numpy3 to add dependency on numpy abi
+
+ -- IOhannes m zmölnig (Debian/GNU) Thu, 30 Jun 2022 22:35:01 +0200
+
aubio (0.4.9-4.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru aubio-0.4.9/debian/patches/ffmpeg5.patch aubio-0.4.9/debian/patches/ffmpeg5.patch
--- aubio-0.4.9/debian/patches/ffmpeg5.patch 1970-01-01 01:00:00.0 +0100
+++ aubio-0.4.9/debian/patches/ffmpeg5.patch 2022-06-30 22:35:01.0 +0200
@@ -0,0 +1,20 @@
+Description: Fix compilation with ffmpeg-5.0
+Author: Paul Brossier
+Origin: upstream
+Applied-Upstream: https://github.com/aubio/aubio/commit/8a05420e5dd8c7b8b2447f82dc919765876511b3
+Last-Update: 2022-06-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- aubio.orig/src/io/source_avcodec.c
aubio/src/io/source_avcodec.c
+@@ -68,6 +68,10 @@
+ #define AUBIO_AVCODEC_MAX_BUFFER_SIZE AV_INPUT_BUFFER_MIN_SIZE
+ #endif
+
++#if LIBAVCODEC_VERSION_MAJOR >= 59
++#define FF_API_LAVF_AVCTX 1
++#endif
++
+ struct _aubio_source_avcodec_t {
+ uint_t hop_size;
+ uint_t samplerate;
diff -Nru aubio-0.4.9/debian/patches/series aubio-0.4.9/debian/patches/series
--- aubio-0.4.9/debian/patches/series 2020-01-04 19:53:25.0 +0100
+++ aubio-0.4.9/debian/patches/series 2022-06-30 22:35:01.0 +0200
@@ -3,3 +3,4 @@
fixpowerpc.patch
fixi386.patch
wscript_py3.patch
+ffmpeg5.patch
diff -Nru aubio-0.4.9/debian/rules aubio-0.4.9/debian/rules
--- aubio-0.4.9/debian/rules 2020-01-08 13:04:19.0 +0100
+++ aubio-0.4.9/debian/rules 2022-06-30 22:35:01.0 +0200
@@ -59,4 +59,4 @@
# python extension
dh_auto_install --buildsystem=pybuild
# call dh_numpy to add dependency on numpy abi
- if [ -x /usr/bin/dh_numpy ]; then dh_numpy; fi
+ if [ -x /usr/bin/dh_numpy3 ]; then dh_numpy3; fi
diff -Nru aubio-0.4.9/debian/salsa-ci.yml aubio-0.4.9/debian/salsa-ci.yml
--- aubio-0.4.9/debian/salsa-ci.yml 1970-01-01 01:00:00.0 +0100
+++ aubio-0.4.9/debian/salsa-ci.yml 2022-06-30 22:35:01.0 +0200
@@ -0,0 +1,4 @@
+---
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
Bug#1013972: RM: juce [armel] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal please remove the 'armel' binary package produced by src:juce. The latest upstream (just uploaded to unstable; currently being rebuilt) FTBFS on this architecture. given the nature of JUCE (creating audio plugins with a nice GUI) and the power of armel, i came to the conclusion that it doesn't make sense to provide packages for this architecture. cheers
Bug#1013608: marked as done (ncbi-entrez-direct: FTBFS: cannot find package "github.com/shirou/gopsutil/mem")
"Debian Bug Tracking System" writes: >* d/rules: Pass right location of gopsutil/mem (Closes: #1013608) Thanks for looking into this report! FWIW, I reckon it should be possible to do away with this dependency altogether by retiring the shim that used it in favor of system golang-github-pbnjay-memory-dev now that the latter exists. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1013333: libidn12: Upgrade to libidn 1.40-1 breaks kmail
Package: libidn12 Version: 1.40-1 Severity: important Dear Maintainer, I had version 1.38-4 installed until I ran apt upgrade today. After the upgrade, mail that originated outside of my system seems to vanish. The mail logs show a normal delivery (by postfix). But kmail shows no sign of the mail. Nor does my android mail client that uses imap to read the same mailbox. I downgraded libidn12 back to 1.38-4 (with NO other changes to packages or configuration) and kmail is working again. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libidn12 depends on: ii libc6 2.33-7 libidn12 recommends no packages. libidn12 suggests no packages. -- no debconf information
Bug#1012362: transition: luajit
Hi Paul, I did not file the corresponding bugs. According to our workflow, will I or the release team file those bugs? If it is me who should file those bugs, I think the default severity should be serious. When all related bugs are resolved by reverse dependencies, I plan to remove ppc64el architecture from both src:luajit and src:luajit2, so that malfunctional binary packages are no longer built for it. On Mon, 2022-06-20 at 22:10 +0200, Paul Gevers wrote: > Hi Mo, > > On 13-06-2022 05:20, M. Zhou wrote: > > So let's inform the reverse dependencies to remove ppc64el support, > > or switch back to lua. > > Just curious, have you already done so? If yes, care to share the bug > report numbers? Otherwise I assume you expected me to file those bugs? > > Paul > > elbrus@coccia:~$ dak rm --no-action -R --suite testing luajit > --architecture=ppc64elW: -a/--architecture implies -p/--partial. > Will remove the following packages from testing: > > libluajit-5.1-2 | 2.1.0~beta3+dfsg-6 | ppc64el > libluajit-5.1-dev | 2.1.0~beta3+dfsg-6 | ppc64el > luajit | 2.1.0~beta3+dfsg-6 | source, ppc64el > > Maintainer: Enrico Tassi > > --- Reason --- > > -- > > Checking reverse dependencies... > # Broken Depends: > lua-ljsyscall: lua-ljsyscall > > # Broken Build-Depends: > bpfcc: libluajit-5.1-dev > luajit > cantor: libluajit-5.1-dev > dnsjit: libluajit-5.1-dev > luajit > efl: libluajit-5.1-dev > fastnetmon: libluajit-5.1-dev > love: libluajit-5.1-dev > lua-ljsyscall: luajit > nageru: libluajit-5.1-dev > nginx: libluajit-5.1-dev > obs-studio: libluajit-5.1-dev > suricata: libluajit-5.1-dev > uftrace: libluajit-5.1-dev > wrk: libluajit-5.1-dev > luajit > > Dependency problem found.
Bug#1013214: O: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++
Package: wnpp Severity: normal Control: affects -1 src:asmjit I intend to orphan the asmjit package. This package is in good shape. This package is a dependency of some optional pytorch dependencies, but I've forgotten the particular name. Anyway, I'm no longer planning to enable that optional dependency. So I'm no longer interested in maintaining this package. The package description is: AsmJit is a complete JIT and AOT assembler for C++ language. It can generate native code for x86 and x64 architectures and supports the whole x86/x64 instruction set - from legacy MMX to the newest AVX512. It has a type-safe API that allows C++ compiler to do semantic checks at compile-time even before the assembled code is generated and/or executed. . This package contains the header files and the static library. Thank you for using reportbug
Bug#971692: ITP: openzfs-docs -- OpenZFS Documentation
Control: close -1 It is not really necessary to package a volatile documentation project. Looking up through internet is already convenient enough.
Bug#964543: ITP: pymc3 -- Bayesian statistical modeling and Probabilistic Machine Learning
Control: owner -1 w...@debian.org Control: retitle -1 RFP: pymc3 -- Bayesian statistical modeling and Probabilistic Machine Learning I'm no longer interested in packaging this on my own.
Bug#959123: ITP: fbgemm -- Facebook GEneral Matrix Multiplication
Control: close -1 I'm no longer interested in packaging this. This package is only useful for pytorch. And I'm no longer planning to enable this package in pytorch build.
Bug#1013213: gftools: version outdated, blocking build of cascadia code
Source: gftools Version: 0.5.2+dfsg-2 Severity: wishlist Dear maintainer, I believe the gftools version in unstable is seriously outdated. And fonts-cascadia-code 2111.01 requires a newer version to successfully build. Please consider packaging a newer version if possible. make[1]: Entering directory '/<>' python3 build.py Traceback (most recent call last): File "/<>/build.py", line 17, in from gftools.stat import gen_stat_tables_from_config ImportError: cannot import name 'gen_stat_tables_from_config' from 'gftools.stat' (/usr/lib/python3/dist- packages/gftools/stat.py) make[1]: *** [debian/rules:10: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Build finished at 2022-06-19T02:44:43Z
Bug#1013212: O: vim-julia -- Vim support for Julia language
Package: wnpp Severity: normal Control: affects -1 src:vim-julia I intend to orphan the vim-julia package. This package is in good shape. This package is team-maintained, but in fact I'm the only effective maintainer. I'm no longer interested in maintaining this package. The package description is: An overview of some of the features: * Latex-to-Unicode substitutions * Block-wise movements and block text-objects * Changing syntax highlighting depending on the Julia version . The full documentation is available from Vim: after installation, you just need to type :help julia-vim. . To enable this vim addon, simply issue the following command: $ vam install julia Thank you for using reportbug
Bug#1013210: O: nsync -- C library that exports various synchronization primitives
Package: wnpp Severity: normal Control: affects -1 src:nsync I intend to orphan the nsync package. This package is tensorflow dependency. This package is in very good shape. I'm no longer interested in maintaining tensorflow dependencies. The package description is: nsync is a C library that exports various synchronization primitives: . * locks * condition variables * run-once initialization * waitable counter (useful for barriers) * waitable bit (useful for cancellation, or other conditions) . This package ships C++ shared object. Thank you for using reportbug
Bug#1013209: O: farmhash -- FarmHash, a family of hash functions
Package: wnpp Severity: normal Control: affects -1 src:farmhash I intend to orphan the farmhash package. This package is tensorflow dependency. This package is in good shape. I'm no longer interested in maintaining tensorflow dependency. The package description is: FarmHash provides hash functions for strings and other data. The functions mix the input bits thoroughly but are not suitable for cryptography. . This package contains development files and document. Thank you for using reportbug
Bug#1013208: O: highwayhash -- Fast strong hash functions: SipHash/HighwayHash
Package: wnpp Severity: normal Control: affects -1 src:highwayhash I intend to orphan the highwayhash package. It is tensorflow dependency. This package is in good shape. I'm no longer interested in maintaining tensorflow dependencies. The package description is: Highwayhash provides three 'strong' (well-distributed and unpredictable) hash functions: a faster version of SipHash, a data-parallel variant of SipHash using tree hashing, and an even faster algorithm called HighwayHash. . SipHash is a fast but 'cryptographically strong' pseudo-random function by Aumasson and Bernstein [https://www.131002.net/siphash/siphash.pdf]. . SipTreeHash slices inputs into 8-byte packets and computes their SipHash in parallel, which is faster when processing at least 96 bytes. . HighwayHash is a new way of mixing inputs which may inspire new cryptographically strong hashes. Large inputs are processed at a rate of 0.3 cycles per byte, and latency remains low even for small inputs. HighwayHash is faster than SipHash for all input sizes, with about 3.8 times higher throughput at 1 KiB. . This package ships the static library and development files. Thank you for using reportbug
Bug#1013207: RM: nnpack/experimental -- ROM; FTBFS; don't want to maintain anymore
Package: ftp.debian.org Severity: normal This package has been FTBFS for a long period. I have no interest in bringing it back into good shape. Thank you for using reportbug
Bug#1013206: O: python-fire -- automatically generate CLIs from absolutely any Python object
Package: wnpp Severity: normal Control: affects -1 src:python-fire I intend to orphan the python-fire package. This package is in good shape. I'm just not interested in maintaining this anymore. The package description is: Python Fire is a library for automatically generating command line interfaces (CLIs) from absolutely any Python object. . * Python Fire is a simple way to create a CLI in Python. * Python Fire is a helpful tool for developing and debugging Python code. * Python Fire helps with exploring existing code or turning other people's code into a CLI. * Python Fire makes transitioning between Bash and Python easier. * Python Fire makes using a Python REPL easier by setting up the REPL with the modules and variables you'll need already imported and created. Thank you for using reportbug
Bug#1002968: #1002968 tbb build success on riscv now
Control: reassign -1 src:onetbb Control: fixed -1 2021.5.0-8 src:tbb has been renamed into src:onetbb. riscv build was already fixed. On Sat, 2022-06-18 at 09:22 +0800, xiao sheng wen wrote: > Hi, > The tbb package had build successed on riscv now. > libtbb2 is one of it's binary package: > apt show libtbb2 > Package: libtbb2 > Version: 2020.3-2.1 > Priority: optional > Section: libs > Source: tbb > Maintainer: Debian Science Maintainers > > Installed-Size: 224 kB > Depends: libtbbmalloc2, libatomic1 (>= 4.8), libc6 (>= 2.32), libgcc-s1 (>= > 3.4), libstdc++6 (>= 11) > Homepage: https://www.threadingbuildingblocks.org/ > Download-Size: 109 kB > APT-Sources: https://mirrors.tencent.com/debian-ports unstable/main riscv64 > Packages > Description: parallelism library for C++ - runtime files > > The tbb (2020.3-2.1) cmake entry in debian/control still is: > > | Build-Depends: debhelper-compat (= 12), > |libjs-jquery, > |dh-exec, > |gdb, > | cmake [amd64 i386 arm64 armhf mips64el mipsel ppc64el s390x], > > It has not riscv list in, perhaps this cmake arches list is not necessary. >
Bug#1012740: ITP: ffcv -- Fast Forward Computer Vision (and other ML workloads)
On Mon, 2022-06-13 at 08:30 +0200, Gürkan Myczko wrote: > Package: wnpp > Severity: wishlist > Owner: Gürkan Myczko > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: ffcv >Version : 0.0.3 >Upstream Authors: ffcv team >URL : https://ffcv.io/ > * License : Apache-2.0 >Description : Fast Forward Computer Vision (and other ML > workloads) > This is a drop-in data loading system that dramatically increases data > throughput in model training. > > Maybe this is for the ai team? I'd say perfect match. You should be able to directly access salsa.debian.org/deeplearning-team as long as you have maintainer access to debian science team even if you are not a direct member.
Bug#1007222: transition: onetbb
Hi Andrius, Thank you so much for the help! I was still looking for time slot to login into a build server to deal with this hard-to-build package. Nowadays I sort of started to dislike packages that my laptop cannot easily build within a few minutes :-) On Mon, 2022-06-13 at 11:57 +0300, Andrius Merkys wrote: > Hi, > > On 2022-06-12 10:29, Graham Inggs wrote: > > Please go ahead with the upload of onetbb to unstable. > > Uploaded. Thanks for the guidance! > > Best wishes, > Andrius >
Bug#1012362: transition: luajit
On Sun, 2022-06-12 at 21:19 +0200, Paul Gevers wrote: > Hi Mo, > > On 10-06-2022 08:00, M. Zhou wrote: > > > There are some compilation flags tweakable. I'll try with > > > qemu to see whether I can make it work. > > > > I tried to tweak some compilation flags, and did not manage to make it > > work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro. > > Segfault persists. > > > > So src:luajit2 is still seemingly badly broken for ppc64el. > > Do you have a proposal how to continue? If you believe this can be fixed > soon (with help from upstream?) I'm OK with trying, but otherwise we > should inform the reverse dependencies on ppc64el that they have to > either remove themselves on ppc64el or switch to lua if that works for > them too. I don't want this lingering for months. src:luajit is > out-of-sync between testing and unstable since January already. After browsing the corresponding github issues I think there is virtually nobody working on the ppc64el port. And I don't have any idea on how to fix it. So let's inform the reverse dependencies to remove ppc64el support, or switch back to lua. The only outcome for this luajit2 transition is that s390x seems working.
Bug#1011281: opus: diff for NMU version 1.3.1-1
Control: tags 1011281 + patch Dear maintainer, I've prepared an NMU for opus (versioned as 1.3.1-1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. diff -u opus-1.3.1/debian/changelog opus-1.3.1/debian/changelog --- opus-1.3.1/debian/changelog +++ opus-1.3.1/debian/changelog @@ -1,3 +1,9 @@ +opus (1.3.1-1) unstable; urgency=medium + + * Salvaging package on behalf of the Multimedia Team (Closes: #1011281) + + -- IOhannes m zmölnig (Debian/GNU) Fri, 10 Jun 2022 08:51:39 +0200 + opus (1.3.1-0.1) unstable; urgency=medium * Non-maintainer upload. diff -u opus-1.3.1/debian/control opus-1.3.1/debian/control --- opus-1.3.1/debian/control +++ opus-1.3.1/debian/control @@ -1,13 +1,16 @@ Source: opus Section: sound Priority: optional -Maintainer: Ron Lee +Maintainer: Debian Multimedia Maintainers +Uploaders: + IOhannes m zmölnig (Debian/GNU) , + Ron Lee Build-Depends: debhelper (>= 9) Build-Depends-Indep: doxygen, graphviz Standards-Version: 4.2.1.5 Homepage: http://www.opus-codec.org -Vcs-Git: https://salsa.debian.org/ron/opus.git -Vcs-Browser: https://salsa.debian.org/ron/opus +Vcs-Git: https://salsa.debian.org/multimedia-team/opus.git +Vcs-Browser: https://salsa.debian.org/multimedia-team/opus Package: libopus0 Section: libs
Bug#1011278: libogg: diff for NMU version 1.3.4-1
Control: tags 1011278 + patch Control: tags 1011278 + pending Dear maintainer, I've prepared an NMU for libogg (versioned as 1.3.4-1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. diff -u libogg-1.3.4/debian/changelog libogg-1.3.4/debian/changelog --- libogg-1.3.4/debian/changelog +++ libogg-1.3.4/debian/changelog @@ -1,3 +1,9 @@ +libogg (1.3.4-1) unstable; urgency=medium + + * Salvaging package on behalf of the Multimedia Team (Closes: #1011278) + + -- IOhannes m zmölnig (Debian/GNU) Fri, 10 Jun 2022 08:45:49 +0200 + libogg (1.3.4-0.1) unstable; urgency=low [ Adrian Bunk ] diff -u libogg-1.3.4/debian/control libogg-1.3.4/debian/control --- libogg-1.3.4/debian/control +++ libogg-1.3.4/debian/control @@ -1,7 +1,10 @@ Source: libogg Section: libs Priority: optional -Maintainer: Ron Lee +Maintainer: Debian Multimedia Maintainers +Uploaders: + IOhannes m zmölnig (Debian/GNU) , + Ron Lee Build-Depends: debhelper (>= 8.1.3) Standards-Version: 3.9.5.0 Homepage: http://xiph.org/ogg/ only in patch2: unchanged: --- libogg-1.3.4.orig/.gitattributes +++ libogg-1.3.4/.gitattributes @@ -0,0 +1,2 @@ +.gitignore export-ignore +.gitattributes export-ignore only in patch2: unchanged: --- libogg-1.3.4.orig/.gitignore +++ libogg-1.3.4/.gitignore @@ -0,0 +1,10 @@ +autom4te.cache +config.log +config.status +*.o +*.d +*.a +*.so +*.so.* +*.sw[jklmnop] +Session.vim
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 21:51 -0700, M. Zhou wrote: > > > lua-moses autopkgtest failure [2] looks bad (still a segmentation fault): > > autopkgtest [07:20:14]: test command9: luajit debian/tests/simple.lua > > autopkgtest [07:20:14]: test command9: [--- > > bash: line 1: 1240 Segmentation fault bash -ec 'luajit > > debian/tests/simple.lua' 2> >(tee -a > > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stderr >&2) > >(tee -a > > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stdout) > > autopkgtest [07:20:14]: test command9: ---] > > There are some compilation flags tweakable. I'll try with > qemu to see whether I can make it work. I tried to tweak some compilation flags, and did not manage to make it work on ppc64el (qemu), even if I use the -DLUAJIT_DISABLE_JIT macro. Segfault persists. So src:luajit2 is still seemingly badly broken for ppc64el.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 13:58 +0200, Paul Gevers wrote: > Hi Mo, > > You may want to look at the FTBFS on mipsel for python-lupa. > > https://buildd.debian.org/status/fetch.php?pkg=python-lupa=mipsel=1.13%2Bdfsg-1%2Bb2=1654771416=0 Yunqiang Su (@syq) volunteers to look into luajit issues on mips* architecture.
Bug#1012362: transition: luajit
On Thu, 2022-06-09 at 10:47 +0200, Paul Gevers wrote: > > I think there one more *test* issue, the first test in src:luajit > doens't explicitly declare dependencies, which means it implicitly has > has '@'. Quoting [1]: > > > Which means that autopkgtest asks apt to make sure all packages from > src:luajit are installed, but the dependency tree of bin:luajit > conflicts with some. This can be solved by only depending on luajit, as > that pulls in the required packages anyways. > Yes. The libluajit-5.1-common has conflicts. Fixed in git: https://salsa.debian.org/lua-team/luajit/-/commit/0489ec840f2ab240785ecd8190962cb779858c29 > lua-moses autopkgtest failure [2] looks bad (still a segmentation fault): > autopkgtest [07:20:14]: test command9: luajit debian/tests/simple.lua > autopkgtest [07:20:14]: test command9: [--- > bash: line 1: 1240 Segmentation fault bash -ec 'luajit > debian/tests/simple.lua' 2> >(tee -a > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stderr >&2) > >(tee -a > /tmp/autopkgtest-lxc.u7chaju_/downtmp/command9-stdout) > autopkgtest [07:20:14]: test command9: ---] There are some compilation flags tweakable. I'll try with qemu to see whether I can make it work.
Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade
I had a look at the package source and only the paths in the file debian/rules [1] have to be changed. Extend all `lib/$(DEB_HOST_MULTIARCH)` to `lib/$(DEB_HOST_MULTIARCH)/security` (added suffix `/security`). [1] https://sources.debian.org/src/libpam-chroot/0.9-5/debian/rules/ Here the changed lines I tested successfully: ``` mkdir -p $(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security # Add here commands to install the package into debian/libpam-chroot $(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot LIBDIR=$(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security INSTALL="install --strip-program=true" ``` Enable source repositories, install build tools and dependencies, then build and install: ``` nano /etc/apt/sources.list apt-get update apt-get install devscripts build-essential cd /var/tmp apt-get build-dep libpam-chroot apt-get source libpam-chroot cd libpam-chroot-0.9*/ sed -i -e 's#lib/\$(DEB_HOST_MULTIARCH)\( \|$\)#lib/\$(DEB_HOST_MULTIARCH\)/security\1#' debian/rules debuild -us -uc # cd /var/tmp dpkg -i libpam-chroot_0.9*.deb ```
Bug#991113: libpam-chroot: pam_chroot.so installed in wrong place - Not able to login after upgrade
Package: libpam-chroot Version: 0.9-5 Followup-For: Bug #991113 X-Debbugs-Cc: maddes+deb...@maddes.net Dear Maintainer, the library pam_chroot.so is installed in the wrong location, therefore it cannot be loaded. This prevents anyone (incl. root) to log into systems that require that module. Changed the pam module to optional via a live linux and found an error message in auth.log: ``` Jun 8 19:30:16 test-debian11 sshd[459]: PAM unable to dlopen(pam_chroot.so): /lib/security/pam_chroot.so: cannot open shared object file: No such file or directory Jun 8 19:30:16 test-debian11 sshd[459]: PAM adding faulty module: pam_chroot.so ``` Current wrong location: `/usr/lib/x86_64-linux-gnu/pam_chroot.so` Correct location: /lib/security/pam_chroot.so -> /usr/lib/x86_64-linux-gnu/security/ Workaround: Boot from a live linux system and move/copy/link file to correct location. `ln -v -s -r -t /usr/lib/x86_64-linux-gnu/security/ /usr/lib/x86_64-linux-gnu/pam_chroot.so` -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-chroot depends on: ii libc6 2.31-13+deb11u3 ii libpam0g 1.4.0-9+deb11u1 libpam-chroot recommends no packages. libpam-chroot suggests no packages. -- no debconf information
Bug#1012362: transition: luajit
https://qa.debian.org/excuses.php?package=luajit autopkgtest on ibm archs encountered somewhat regression, since I only removed Conflicts+Replaces from the src:luajit side. I fixed this issue and uploaded src:luajit2 https://salsa.debian.org/lua-team/luajit2/-/commit/12818940efdf76cf48b8e2cfea2dfaa5dc11664a luajit2 (2.1-20220411-5) unstable Now it should be fine after several hours when we retry the autopkgtest. On Tue, 2022-06-07 at 22:28 -0700, M. Zhou wrote: > https://buildd.debian.org/status/package.php?p=luajit > All green, including ppc64el and s390x > (arch-specific transitional dummy package) > > Seems we are ready to start the rebuild? > > On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote: > > On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > > > > > > > Yes, except for the part about patching d/control. We'll have to find > > > > another way. An alternative to what I wrote before is a extension of > > > > the > > > > description to say that the binary is empty on s390x and ppc64el. > > > > > > So both patching control and double stanza do not work. Currently > > > the only solution that I can think of is to upload a NEW empty > > > dummy source package: > > > > > > src:luajit-ibm-transition > > > * bin:luajit > > >Architecture: ppc64el s390x > > >Depends: luajit2 > > > * ... > > > > > > > I realized that the solution is very simple. > > I can simply re-enable ppc64el s390x, and install nothing into the binary > > packages. Simple tweak on Depends/Conclicts/Replaces should be enough: > > https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa > > > > I built the package locally, and additionally with sbuild/qemu ppc64el. > > See following the trimmed debc information. I'm uploading this revision > > shortly. > > > > = > > > > > > libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > > > new Debian package, version 2.0. > > size 256424 bytes: control archive=1760 bytes. > > 833 bytes,20 lines control > > 240 bytes, 3 lines md5sums > > 66 bytes, 1 lines shlibs > > 4702 bytes, 148 lines symbols > > 67 bytes, 2 lines triggers > > Package: libluajit-5.1-2 > > Source: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: amd64 > > Maintainer: Debian Lua Team > > Installed-Size: 581 > > Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 > > (>= 2.29), libgcc-s1 (>= 3.3) > > Conflicts: libluajit2-5.1-2 > > Replaces: libluajit2-5.1-2 > > > > libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb > > --- > > new Debian package, version 2.0. > > size 49592 bytes: control archive=1104 bytes. > > 523 bytes,15 lines control > > 1503 bytes,19 lines md5sums > > Package: libluajit-5.1-common > > Source: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: all > > Maintainer: Debian Lua Team > > Installed-Size: 218 > > Conflicts: libluajit2-5.1-common > > Replaces: libluajit2-5.1-common > > > > libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > -- > > new Debian package, version 2.0. > > size 275064 bytes: control archive=916 bytes. > > 537 bytes,16 lines control > > 710 bytes,10 lines md5sums > > Package: libluajit-5.1-dev > > Source: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: amd64 > > Maintainer: Debian Lua Team > > Installed-Size: 771 > > Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) > > Conflicts: libluajit2-5.1-dev > > Replaces: libluajit2-5.1-dev > > > > luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > --- > > new Debian package, version 2.0. > > size 262800 bytes: control archive=888 bytes. > > 857 bytes,19 lines control > > 254 bytes, 4 lines md5sums > > Package: luajit > > Version: 2.1.0~beta3+git20220320+dfsg-2 > > Architecture: amd64 > > Maintainer: Debian Lua Team > > Installed-Size: 592 > > Dep
Bug#1012362: transition: luajit
https://buildd.debian.org/status/package.php?p=luajit All green, including ppc64el and s390x (arch-specific transitional dummy package) Seems we are ready to start the rebuild? On Tue, 2022-06-07 at 20:37 -0700, M. Zhou wrote: > On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > > > > Yes, except for the part about patching d/control. We'll have to find > > > another way. An alternative to what I wrote before is a extension of the > > > description to say that the binary is empty on s390x and ppc64el. > > > > So both patching control and double stanza do not work. Currently > > the only solution that I can think of is to upload a NEW empty > > dummy source package: > > > > src:luajit-ibm-transition > > * bin:luajit > >Architecture: ppc64el s390x > >Depends: luajit2 > > * ... > > > > I realized that the solution is very simple. > I can simply re-enable ppc64el s390x, and install nothing into the binary > packages. Simple tweak on Depends/Conclicts/Replaces should be enough: > https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa > > I built the package locally, and additionally with sbuild/qemu ppc64el. > See following the trimmed debc information. I'm uploading this revision > shortly. > > = > > > libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > > new Debian package, version 2.0. > size 256424 bytes: control archive=1760 bytes. > 833 bytes,20 lines control > 240 bytes, 3 lines md5sums > 66 bytes, 1 lines shlibs > 4702 bytes, 148 lines symbols > 67 bytes, 2 lines triggers > Package: libluajit-5.1-2 > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: amd64 > Maintainer: Debian Lua Team > Installed-Size: 581 > Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= > 2.29), libgcc-s1 (>= 3.3) > Conflicts: libluajit2-5.1-2 > Replaces: libluajit2-5.1-2 > > libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb > --- > new Debian package, version 2.0. > size 49592 bytes: control archive=1104 bytes. > 523 bytes,15 lines control > 1503 bytes,19 lines md5sums > Package: libluajit-5.1-common > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: all > Maintainer: Debian Lua Team > Installed-Size: 218 > Conflicts: libluajit2-5.1-common > Replaces: libluajit2-5.1-common > > libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > -- > new Debian package, version 2.0. > size 275064 bytes: control archive=916 bytes. > 537 bytes,16 lines control > 710 bytes,10 lines md5sums > Package: libluajit-5.1-dev > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: amd64 > Maintainer: Debian Lua Team > Installed-Size: 771 > Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) > Conflicts: libluajit2-5.1-dev > Replaces: libluajit2-5.1-dev > > luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb > --- > new Debian package, version 2.0. > size 262800 bytes: control archive=888 bytes. > 857 bytes,19 lines control > 254 bytes, 4 lines md5sums > Package: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: amd64 > Maintainer: Debian Lua Team > Installed-Size: 592 > Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2), > libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), > libc6 (>= 2.29), libgcc-s1 (>= 3.3) > Conflicts: luajit2 > Replaces: luajit2 > > == > > libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb > -- > new Debian package, version 2.0. > size 7584 bytes: control archive=780 bytes. > 703 bytes,18 lines control > 158 bytes, 2 lines md5sums > Package: libluajit-5.1-2 > Source: luajit > Version: 2.1.0~beta3+git20220320+dfsg-2 > Architecture: ppc64el > Maintainer: Debian Lua Team > Installed-Size: 15 > Depends: libluajit2-5.1-2 > > libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb > --- > new Debian pac
Bug#1012362: transition: luajit
On Tue, 2022-06-07 at 20:03 -0700, M. Zhou wrote: > > > > > Yes, except for the part about patching d/control. We'll have to find > > another way. An alternative to what I wrote before is a extension of the > > description to say that the binary is empty on s390x and ppc64el. > > So both patching control and double stanza do not work. Currently > the only solution that I can think of is to upload a NEW empty > dummy source package: > > src:luajit-ibm-transition > * bin:luajit >Architecture: ppc64el s390x >Depends: luajit2 > * ... > I realized that the solution is very simple. I can simply re-enable ppc64el s390x, and install nothing into the binary packages. Simple tweak on Depends/Conclicts/Replaces should be enough: https://salsa.debian.org/lua-team/luajit/-/commit/0cc94e0caf8f78568c42c8fdf8db0c34766710fa I built the package locally, and additionally with sbuild/qemu ppc64el. See following the trimmed debc information. I'm uploading this revision shortly. = libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_amd64.deb new Debian package, version 2.0. size 256424 bytes: control archive=1760 bytes. 833 bytes,20 lines control 240 bytes, 3 lines md5sums 66 bytes, 1 lines shlibs 4702 bytes, 148 lines symbols 67 bytes, 2 lines triggers Package: libluajit-5.1-2 Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team Installed-Size: 581 Depends: libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= 2.29), libgcc-s1 (>= 3.3) Conflicts: libluajit2-5.1-2 Replaces: libluajit2-5.1-2 libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb --- new Debian package, version 2.0. size 49592 bytes: control archive=1104 bytes. 523 bytes,15 lines control 1503 bytes,19 lines md5sums Package: libluajit-5.1-common Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: all Maintainer: Debian Lua Team Installed-Size: 218 Conflicts: libluajit2-5.1-common Replaces: libluajit2-5.1-common libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_amd64.deb -- new Debian package, version 2.0. size 275064 bytes: control archive=916 bytes. 537 bytes,16 lines control 710 bytes,10 lines md5sums Package: libluajit-5.1-dev Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team Installed-Size: 771 Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2) Conflicts: libluajit2-5.1-dev Replaces: libluajit2-5.1-dev luajit_2.1.0~beta3+git20220320+dfsg-2_amd64.deb --- new Debian package, version 2.0. size 262800 bytes: control archive=888 bytes. 857 bytes,19 lines control 254 bytes, 4 lines md5sums Package: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: amd64 Maintainer: Debian Lua Team Installed-Size: 592 Depends: libluajit-5.1-2 (= 2.1.0~beta3+git20220320+dfsg-2), libluajit-5.1-common (= 2.1.0~beta3+git20220320+dfsg-2), libc6 (>= 2.29), libgcc-s1 (>= 3.3) Conflicts: luajit2 Replaces: luajit2 == libluajit-5.1-2_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb -- new Debian package, version 2.0. size 7584 bytes: control archive=780 bytes. 703 bytes,18 lines control 158 bytes, 2 lines md5sums Package: libluajit-5.1-2 Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team Installed-Size: 15 Depends: libluajit2-5.1-2 libluajit-5.1-common_2.1.0~beta3+git20220320+dfsg-2_all.deb --- new Debian package, version 2.0. size 49592 bytes: control archive=1104 bytes. 523 bytes,15 lines control 1503 bytes,19 lines md5sums Package: libluajit-5.1-common Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: all Maintainer: Debian Lua Team Installed-Size: 218 Conflicts: libluajit2-5.1-common Replaces: libluajit2-5.1-common libluajit-5.1-dev_2.1.0~beta3+git20220320+dfsg-2_ppc64el.deb new Debian package, version 2.0. size 7444 bytes: control archive=636 bytes. 447 bytes,14 lines control 162 bytes, 2 lines md5sums Package: libluajit-5.1-dev Source: luajit Version: 2.1.0~beta3+git20220320+dfsg-2 Architecture: ppc64el Maintainer: Debian Lua Team Installed-Si
Bug#1012362: transition: luajit
On Tue, 2022-06-07 at 21:21 +0200, Paul Gevers wrote: > Hi Mo, > > On 07-06-2022 17:36, M. Zhou wrote: > > This should be achievable by patching debian/control > > during build once detected IBM architectures. > > This is not allowed. I currently fail to find where that's written down, > but I'm fairly sure that the relevant parties agree that debian/control > must not be mangled with during build. The ftp-reject list touches upon > it, albeit for a different reason [1]. debian/control has to be > unchanged in source. But, maybe you can try to add two stanza's for the > same binary name, one with the Archs !s390x !ppc64el and another for > s390x and ppc64el. I'm not totally sure if that's allowed and if the > tools handle it well, but may be worth a try. Indeed that's not allowed, although I should have seen some of such examples years ago IIRC. Apart from that, additional binary package entry with different architecture will be deemed as duplicate: dh: error: debian/control has a duplicate entry for luajit > > IIRC adding new architecture without new binary package > > does not have to go through NEW. > > Indeed, they don't. > > > Does that sound good? > > Yes, except for the part about patching d/control. We'll have to find > another way. An alternative to what I wrote before is a extension of the > description to say that the binary is empty on s390x and ppc64el. So both patching control and double stanza do not work. Currently the only solution that I can think of is to upload a NEW empty dummy source package: src:luajit-ibm-transition * bin:luajit Architecture: ppc64el s390x Depends: luajit2 * ... > Paul > > [1] https://ftp-master.debian.org/REJECT-FAQ.html : debian/control > breakage #2 > """ > which basically means that everything must be defined at the beginning > of the build. > """ Thanks. I was not aware of this.
Bug#1012362: transition: luajit
I have uploaded luajit/unstable 2.1.0~beta3+git20210112+dfsg-2, but please hold on. I should have split the ppc64el architecture removal to a future revision... Now that the ppc64el architecture is missing for src:luajit, and we still cannot safely remove luajit:ppc64el without manually changing their build depends into libluajit2-5.1-2 [ppc64el s390x] | libluajit-5.1-2 ... I'm thinking of yet another solution for the IBM architecture transition. It's to add ppc64el and s390x back into src:luajit, but make all binary packages transitional dummy packages, i.e. Package: libluajit-5.1-2 Architecture: ppc64el s390x Depends: libluajit2-5.1-2 Description: transitional dummy package This should be achievable by patching debian/control during build once detected IBM architectures. IIRC adding new architecture without new binary package does not have to go through NEW. So this architecture-specific transitional dummy package solution should be able to help us smoothly deal with IBM architectures. Does that sound good? If so I'll prepare another upload before we really start the transition. On Mon, 2022-06-06 at 20:45 +0200, Paul Gevers wrote: > Control: tag -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/libluajit2-support.html > > Hi Mo, > > On 05-06-2022 19:30, M. Zhou wrote: > > So, currently I have a pending commit[2] modifying the dependency > > template[1], > > so that src:luajit reverse dependencies can be rebuilt without source > > modification to allow library fallback. > > > > Specifically, before transition, luajit reverse dependencies will have: > >Depends: libluajit-5.1-2 > > After transition, they should have: > >Depends: libluajit-5.1-2 | libluajit2-5.1-2 > > And the only thing we need to do is to upload the pending commit[2] > > once approved. Then we just trigger a rebuild for all luajit reverse > > dependencies. > > Please go ahead. > > Paul
Bug#1012362: transition: luajit
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This bug is follow-up for this thread: https://lists.debian.org/debian-release/2022/06/msg9.html The original LuaJIT upstream does not care about IBM architectures, which causes problem in downstreams including us. I packaged src:luajit2 which seems to be working well for IBM architectures. src:luajit2 can be used as a drop-in replacement for src:luajit. So, currently I have a pending commit[2] modifying the dependency template[1], so that src:luajit reverse dependencies can be rebuilt without source modification to allow library fallback. Specifically, before transition, luajit reverse dependencies will have: Depends: libluajit-5.1-2 After transition, they should have: Depends: libluajit-5.1-2 | libluajit2-5.1-2 And the only thing we need to do is to upload the pending commit[2] once approved. Then we just trigger a rebuild for all luajit reverse dependencies. This is a special transition that should not break any package at all, as it is just inserting an alternative dependency. (I don't know how to write a correct ben file for such special case.) Ben file: title = "luajit"; is_affected = .depends ~ "libluajit-5.1-2" | .depends ~ "libluajit-5.1-2"; is_good = .depends ~ "libluajit2-5.1-2"; is_bad = .depends ~ "libluajit-5.1-2"; Thank you for using reportbug [1] deb-symbols(5), this is an less-known advanced usage. [2] https://salsa.debian.org/lua-team/luajit/-/commit/561f846d9c845876715eef086aeb9ff0fd80
Bug#1012186: dbus: does not recognize volume media keys as MPRIS events
Control: tags -1 - moreinfo Thank you Simon, turns out you hit the nail on the head: I had pulseaudio and pipewire, but did not have pipewire-pulse installed. Installed that, rebooted, and it's now working: volume up and down out of the box, mute when I set the keybindings. @gnome-shell team: considering I am on what is basically a fresh install, should pipewire-pulse come preinstalled? My system, out of the box (from a netinstall), comes with these packages (except pipewire-pulse, which I just installed, and probably vlc-plugin-pipewire, which may have been installed along with VLC) $ dpkg -l | grep -E "pulseaudio|pipewire" ii gstreamer1.0-pipewire:amd64 0.3.51-1 amd64GStreamer 1.0 plugin for the PipeWire multimedia server ii gstreamer1.0-pulseaudio:amd64 1.20.2-1 amd64GStreamer plugin for PulseAudio (transitional package) ii libpipewire-0.3-0:amd64 0.3.51-1 amd64libraries for the PipeWire multimedia server ii libpipewire-0.3-common0.3.51-1 all libraries for the PipeWire multimedia server - common files ii libpipewire-0.3-modules:amd64 0.3.51-1 amd64libraries for the PipeWire multimedia server - modules ii pipewire:amd640.3.51-1 amd64audio and video processing engine multimedia server ii pipewire-bin 0.3.51-1 amd64PipeWire multimedia server - programs ii pipewire-media-session0.4.1-2 amd64example session manager for PipeWire ii pipewire-pulse0.3.51-1 amd64PipeWire PulseAudio daemon ii pulseaudio15.0+dfsg1-4 amd64PulseAudio sound server ii pulseaudio-module-bluetooth 15.0+dfsg1-4 amd64Bluetooth module for PulseAudio sound server ii pulseaudio-utils 15.0+dfsg1-4 amd64Command line tools for the PulseAudio sound server ii vlc-plugin-pipewire:amd64 3-1 amd64PipeWire audio plugins for VLC Thanks! On Tue, May 31, 2022 at 9:51 PM Simon McVittie wrote: > Control: reassign -1 gnome-shell > Control: tags -1 + moreinfo > > On Tue, 31 May 2022 at 20:02:39 +0200, Claudio wrote: > > My system does not react to Volume Up/Down/Mute events, but still > > reacts to Play/Pause/Previous/Next. > > dbus is not responsible for generating events or reacting to events, > only delivering messages generated by something else, so this is very > unlikely to be a dbus bug. You implied that your UI is gnome-shell, > so I'm sending the bug report there for now, but I think it might be > working as designed. > > > Trying to trace the event I checked GNOME keybindings; the UI recognizes > > the Audio Raise/Lower/Mute Volume inputs when binding the keys, but > > nothing happens when I try to use them > > I believe the way volume keys are meant to work in GNOME is that > gnome-shell receives the keyboard events and uses them to control the > overall volume in PulseAudio (or Pipewire if you have pipewire-pulse > installed). > > The reason MPRIS is necessary is that for events like play/pause, there > is no reasonable thing that gnome-shell can do on its own: the only thing > it can usefully do is pass the event on to your active media player, > and hope it can do something useful in response. That isn't the case for > volume control, which gnome-shell can deal with in an app-independent way: > regardless of whether you are playing music through a MPRIS media player, > playing sounds from a non-MPRIS source like a game, both, or neither, > the Shell changes the volume level directly, which will result in media > players, games, system sounds and all other sound sources getting louder > or quieter as appropriate. > > So I think this is probably working as designed, unless the volume is > not actually changing (in which case that would be a problem with the > interaction between gnome-shell and pulseaudio). > > > xev does not recognize any > > XF86Audio* events (volume or play/pause/etc.). > > If you're using gnome-shell in its default Wayland mode, any key that is > grabbed by gnome-shell is not going to be visible to the X11 emulation > provided by Xwayland, and therefore not visible to xev. That's working > as designed. For applications, the result of pressing volume up/down keys > should be indistinguishable from the result of dragging the GUI volume > slider: either way, the representation is "volume changed". > > smcv >
Bug#1012294: O: jsonnet -- data templating language
Package: wnpp Severity: normal Control: affects -1 src:jsonnet I intend to orphan the jsonnet package, because I'm not interested in it anymore. The package is currently in good shape. The package description is: A data templating language for app and tool developers . * Generate config data * Side-effect free * Organize, simplify, unify * Manage sprawling config . A simple extension of JSON . * Open source (Apache 2.0) * Familiar syntax * Reformatter, linter * Editor & IDE integrations * Formally specified . Eliminate duplication with object-orientation. Or, use functions. Integrate with existing / custom applications. Generate JSON, YAML, INI, and other formats. . This package ships the binary executable. Thank you for using reportbug
Bug#1007222: transition: onetbb
On Wed, 2022-06-01 at 20:29 +0200, Graham Inggs wrote: > Control: tags -1 + moreinfo > > I noticed some packages in the tracker not appearing in your list; > e.g. openimageio, pcl and yade. These packages have transitive > build-dependencies on libtbb-dev through e.g. libopenvdb-dev or > libvtk9-dev, and should be investigated as well. My bad. So solely `reverse-depends -b` may miss something. I'll investigate and append results to the transition bug. > Note that we will require fixes, or at least patches, for "key > packages" [1] before starting with this transition, and at least > trilinos is currently on that list. > > It may be worth considering again Matthias' suggestion in #1006920 to > keep the old tbb package around as libtbb2-dev and libtbb2-doc in > order to allow packages like numba to get the new tbb soon, and other > packages stuck with the old tbb more time to get fixed. I personally dislike making the old package libtbb2-dev. How about we make the old src:tbb package go through NEW again with the following renames: libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev because it explains itself to be a to-be-deprecated version. In this way we can finish the transition very quickly and leave longer time for broken packages to migrate to onetbb. For me, submitting patches is as well much easier as I only have to change libtbb-dev -> libtbb-legacy-dev for broken packages.
Bug#1012118: rakudo: Maintainer script still talks about "perl6 modules"
Control: tags -1 +pending Thanks for catching this. Fixed in git salsa.debian.org:perl6-team/rakudo.git On Mon, 2022-05-30 at 15:10 +0200, Axel Beckert wrote: > Package: rakudo > Version: 2022.04-2 > Severity: minor > > Hi, > > I just noticed that the maintainer script still talks about "perl6 > modules": > > Setting up rakudo (2022.04-2) ... > rakudo-helper.pl: Reinstalling all perl6 modules ... > (1/4) reinstall: […] > > Shouldn't that be "raku modules" nowadays? > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), > (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), > (1, 'buildd-experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > LSM: AppArmor: enabled > > Versions of packages rakudo depends on: > ii libc6 2.33-7 > ii libgraph-perl 1:0.9725-1 > ii libipc-system-simple-perl 1.30-1 > ii libpath-tiny-perl 0.122-1 > ii moarvm 2022.04+dfsg-2 > ii nqp2022.04+dfsg-2 > > rakudo recommends no packages. > > Versions of packages rakudo suggests: > ii valgrind 1:3.18.1-1 > > -- no debconf information > > ___ > Pkg-rakudo-devel mailing list > pkg-rakudo-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rakudo-devel
Bug#1011345: transition: rakudo
On Sat, 2022-05-28 at 12:16 +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2022-05-20 10:36:34 -0400, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > We have uploaded rakudo 2022.04 to experimental, and would like to > > start the transition and rebuild packages > > Please go ahead > Uploaded to unstable.
Bug#1011928: trilinos FTBFS: isinf was not defined in this scope
Source: trilinos Version: 13.2.0-1 Severity: serious This is a side-product of a rebuild test against libtbb-dev/experimental ==> CMakeFiles/CMakeError.log <== Performing C++ SOURCE FILE Test FINITE_VALUE_HAVE_GLOBAL_ISNAN failed with the following output: Change Dir: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_c127c/fast && gmake[2]: Entering directory '/<>/obj- x86_64-linux-gnu/CMakeFiles/CMakeTmp' /usr/bin/gmake -f CMakeFiles/cmTC_c127c.dir/build.make CMakeFiles/cmTC_c127c.dir/build gmake[3]: Entering directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' Building CXX object CMakeFiles/cmTC_c127c.dir/src.cxx.o /usr/bin/mpicxx -DFINITE_VALUE_HAVE_GLOBAL_ISNAN -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong - Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE= 2 -O3 -DNDEBUG -std=c++14 -o CMakeFiles/cmTC_c127c.dir/src.cxx.o -c /<>/obj-x86_64-linux- gnu/CMakeFiles/CMakeTmp/src.cxx /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx: In function ‘int main()’: /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:6:3: error: ‘isnan’ was not declared in this scope; did you mean ‘std::isnan’? 6 | isnan(x); | ^ | std::isnan In file included from /<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:2: /usr/include/c++/11/cmath:632:5: note: ‘std::isnan’ declared here 632 | isnan(_Tp __x) | ^ gmake[3]: *** [CMakeFiles/cmTC_c127c.dir/build.make:78: CMakeFiles/cmTC_c127c.dir/src.cxx.o] Error 1 gmake[3]: Leaving directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' gmake[2]: *** [Makefile:127: cmTC_c127c/fast] Error 2 gmake[2]: Leaving directory '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Bug#1011667: ITP: mujoco -- A general purpose physics simulator.
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mujoco Version : 2.2.0 Upstream Author : DeepMind * URL : https://mujoco.org/ * License : Apache-2.0 Programming Lang: C Description : A general purpose physics simulator. I plan to maintain this under Debian Deep Learning Team.
Bug#1007222: transition: onetbb
This is the most uneasy transition I've ever handled. There was massive upstream code overhaul breaking basically everything. Build system has changed so I rewritten the d/rules, this took me a while. Going through NEW due to upstream rename took a while. Then only amd64 does not FTBFS. I wrote patches to make it green on release architectures, this took me a while. Then there is package split, which means we have to go through NEW again. This is relatively fast IIRC. Throughout the whole process I'm dealing with paper submission deadline which has passed several days ago. Before that I wasn't able to allocate time for the massive reverse dependency build. This took a while as well. Now we can finally go ahead. On Wed, 2022-05-25 at 20:07 -0400, M. Zhou wrote: > Control: tags -1 -moreinfo > > Reverse-Build-Depends > * blender [irrelevant; ftpfs, no matching function for call to > openvdb... ] #1011653 > * bowtie [ok] > * bowtie2 [ok] > * casparcg-server [ftbfs, TBB not found during cmake] #1011654 > * deal.ii [ftbfs, cmake could not find tbb] #1011655 > * embree [ok] > * flexbar [ftbfs, cannot find tbb header] #1011656 > * gazebo [irrelevant; ftbfs, missing symbol from libtiff] #1011657 > * gudhi [ok] > * libatomic-queue [ok] > * libpmemobj-cpp [ftbfs, tbb api break] #1011658 > * macaulay2 [unknown, timeout for doc build during ThreadedGB ... > Minimal.out] > * madness [ok] > * mathicgb [ok] > * mpqc3 [irrelevant; eigen3 api break; already FTBFS] > * numba [irrelevant; incompatible with py3.10] > * onednn [ok] > * open3d [ok] > * opencascade [ftbfs; tbb api break] #1011659 > * opencv [ok] > * opensubdiv [ftbfs; tbb api break] #1011660 > * openturns [ok] > * openvdb [irrelevant; help2man error during manpage build; already > FTBFS] > * pmemkv [ok] > * ptl [ok] > * r-cran-markovchain [ftbfs; tbb api break] #1011661 > * r-cran-rcppparallel [ok] > * r-cran-uwot [ok] > * salmon [ftbfs; tbb api break] #1011662 > * slic3r-prusa [FTBFS, TBB api break] #1011663 > * sysdig [ok] > * tiledarray [irrelevant: other build depenency uninstallable] > * tiny-dnn [ftbfs, TBB not found during cmake] #1011664 > * trilinos [irrelevant: isinf not defined] > * vtk9 [ok] > > > On Sun, 2022-03-13 at 22:28 +0100, Sebastian Ramacher wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/onetbb.html > Control: tags -1 moreinfo > > On 2022-03-13 16:59:48 -0400, M. Zhou wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi release team, > > > > This involves an upstream source name change (from tbb to onetbb), > > as well as SOVERSION bump (from 2 to 12), along with a major API > > change including some changes in the core API. > > > > I should have submitted this after my local build test for the > > reverse dependencies of libtbb-dev, but fellow developers from > > debian-science are eager to see this in unstable to unblock > > their works. > > > > I have not tested by myself, but I heard from an archlinux > > developer that this API bump breaks a lot packages. And > > some upstreams decided to disable or drop tbb support as > > a result. I guess we can take similar measures for short > > term workaround. > > Please remove the moreinfo tag once these issues have been > investigated > and bugs have been filed. > > Cheers > > > > > Ben file: > > > > title = "tbb"; > > is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12"; > > is_good = .depends ~ "libtbb12"; > > is_bad = .depends ~ "libtbb2"; > > Thank you for using reportbug > > >
Bug#1007222: transition: onetbb
Control: tags -1 -moreinfo Reverse-Build-Depends * blender [irrelevant; ftpfs, no matching function for call to openvdb... ] #1011653 * bowtie [ok] * bowtie2 [ok] * casparcg-server [ftbfs, TBB not found during cmake] #1011654 * deal.ii [ftbfs, cmake could not find tbb] #1011655 * embree [ok] * flexbar [ftbfs, cannot find tbb header] #1011656 * gazebo [irrelevant; ftbfs, missing symbol from libtiff] #1011657 * gudhi [ok] * libatomic-queue [ok] * libpmemobj-cpp [ftbfs, tbb api break] #1011658 * macaulay2 [unknown, timeout for doc build during ThreadedGB ... Minimal.out] * madness [ok] * mathicgb [ok] * mpqc3 [irrelevant; eigen3 api break; already FTBFS] * numba [irrelevant; incompatible with py3.10] * onednn [ok] * open3d [ok] * opencascade [ftbfs; tbb api break] #1011659 * opencv [ok] * opensubdiv [ftbfs; tbb api break] #1011660 * openturns [ok] * openvdb [irrelevant; help2man error during manpage build; already FTBFS] * pmemkv [ok] * ptl [ok] * r-cran-markovchain [ftbfs; tbb api break] #1011661 * r-cran-rcppparallel [ok] * r-cran-uwot [ok] * salmon [ftbfs; tbb api break] #1011662 * slic3r-prusa [FTBFS, TBB api break] #1011663 * sysdig [ok] * tiledarray [irrelevant: other build depenency uninstallable] * tiny-dnn [ftbfs, TBB not found during cmake] #1011664 * trilinos [irrelevant: isinf not defined] * vtk9 [ok] On Sun, 2022-03-13 at 22:28 +0100, Sebastian Ramacher wrote: Control: forwarded -1 https://release.debian.org/transitions/html/onetbb.html Control: tags -1 moreinfo On 2022-03-13 16:59:48 -0400, M. Zhou wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi release team, > > This involves an upstream source name change (from tbb to onetbb), > as well as SOVERSION bump (from 2 to 12), along with a major API > change including some changes in the core API. > > I should have submitted this after my local build test for the > reverse dependencies of libtbb-dev, but fellow developers from > debian-science are eager to see this in unstable to unblock > their works. > > I have not tested by myself, but I heard from an archlinux > developer that this API bump breaks a lot packages. And > some upstreams decided to disable or drop tbb support as > a result. I guess we can take similar measures for short > term workaround. Please remove the moreinfo tag once these issues have been investigated and bugs have been filed. Cheers > > Ben file: > > title = "tbb"; > is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12"; > is_good = .depends ~ "libtbb12"; > is_bad = .depends ~ "libtbb2"; > Thank you for using reportbug >
Bug#1011662: salmon ftbfs against onetbb/experimental: tbb api break
Source: salmon Version: 1.4.0+ds1-1 Severity: important tbb -> onetbb transition breaks this package.
Bug#1011663: slic3r-prusa ftbfs against onetbb/experimental: tbb api break
Source: slic3r-prusa Version: 2.4.2+dfsg-1 Severity: important tbb -> onetbb transition breaks this package.
