Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11
Hi,
On Wed, May 29, 2024 at 12:16 AM gregor herrmann wrote:
>
> On Mon, 27 May 2024 22:33:45 +0200, gregor herrmann wrote:
>
> > … on amd64 and some other architectures; on others the testsuite now
> > fails in t/13dtd.t with SIGSEGV or SIGBUS etc.:
> > https://buildd.debian.org/status/package.php?p=libxml-libxml-perl
>
> Additionally the upload triggers a gazillion of autopkgtest failures
> in reverse dependencies:
>
> Issues preventing migration:
> ∙ ∙ autopkgtest for libatteanx-endpoint-perl/0.002-6: amd64: Regression
> or new test ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻),
> i386: Regression or new test ♻ (reference ♻), riscv64: Pass
[...]
>
> They all seem to fail with:
>
> Warning: program compiled against libxml 212 using older 209
>
> and this comes from libxml:
>
> https://sources.debian.org/src/libxml2/2.12.7+dfsg-2/parserInternals.c/?hl=79#L79
>
> if ((myversion / 100) < (version / 100)) {
> xmlGenericError(xmlGenericErrorContext,
> "Warning: program compiled against libxml %d using older
> %d\n",
> (version / 100), (myversion / 100));
> }
>
>
> Not sure if this is should be fixed in libxml2 or if we should add an
> artifical dependency on a newer libxml2 (to avoid testing against the
> version in testing). The former sounds more logic to me.
>
Although it looks trivial to remove the warning from libxml2, I'm
reluctant since this piece of code existed for a very long time, a
random check shows that version 2.2.3 (in 2000) has the logic:
https://gitlab.gnome.org/GNOME/libxml2/-/blob/04698d9e1c56467007fcbb9472e5db67cf5938f5/parserInternals.c#L66
Cheers,
Aron
Bug#1072017: ruby-libxml: new upstream release, addressing test failures with libxml2 >= 2.12
Package: src:ruby-libxml Version: 3.2.4-2 X-Debbugs-Cc: debian-xml-sgml-pkgs at alioth-lists.debian.net Hi, libxml2 has been updated to upstream 2.12.7 release and the autopkgtest shows regressions[1] regarding ruby-libxml: 47s 1) Failure: 47s TestSaxParser#test_parse_seg_fail [/tmp/autopkgtest-lxc.00ga17my/downtmp/build.LIY/src/test/test_sax_parser.rb:321]: 47s --- expected 47s +++ actual 47s @@ -1 +1 @@ 47s -"Fatal error: xmlParseEntityRef: no name at :5." 47s +"Fatal error: xmlParseEntityRef: no name at :4." 47s 47s 47s 2) Failure: 47s TestParser#test_file_encoding [/tmp/autopkgtest-lxc.00ga17my/downtmp/build.LIY/src/test/test_parser.rb:66]: 47s Expected nil to be truthy. 47s 47s 3) Failure: 47s TestParser#test_bad_xml [/tmp/autopkgtest-lxc.00ga17my/downtmp/build.LIY/src/test/test_parser.rb:286]: 47s --- expected 47s +++ actual 47s @@ -1 +1 @@ 47s -"Fatal error: Extra content at the end of the document at :1." 47s +"Fatal error: Couldn't find end of Start Tag ruby_array line 1 at :1." 47s 47s 47s 4) Failure: 47s TestReader#test_string_encoding [/tmp/autopkgtest-lxc.00ga17my/downtmp/build.LIY/src/test/test_reader.rb:362]: 47s Expected: 10 47s Actual: 0 47s 47s 353 runs, 42311 assertions, 4 failures, 0 errors, 0 skips Upstream has fixed a few issues with libxml2 2.12.x in 5.0.x release. It would be nice if upstream release or some patch works can be considered to help unblock the migration of new libxml2. I would give it a try on patching but I'm unfortunately not a Ruby expert. [1]https://ci.debian.net/packages/r/ruby-libxml/testing/amd64/47035876/
Bug#1072012: libxml-libxml-perl: new upstream release 2.0210, addressing test failures with libxml2 >= 2.11
Package: src:libxml-libxml-perl Version: 2.0207+dfsg+really+2.0134-1 X-Debbugs-Cc: debian-xml-sgml-p...@alioth-lists.debian.net Hi, libxml2 has been updated to upstream 2.12.7 release and the autopkgtest shows regressions[1] regarding libxml-libxml-perl: 72s t/35huge_mode.t 72s 1..5 72s ok 1 - huge mode disabled by default 72s not ok 2 - exception thrown during parse 72s 72s # Failed test 'exception thrown during parse' 72s # at t/35huge_mode.t line 56. 72s # got: '' 72s # expected: anything else 72s not ok 3 - exception refers to entity reference loop 72s 72s # Failed test 'exception refers to entity reference loop' 72s # at t/35huge_mode.t line 57. 72s # '' 72s # doesn't match '(?^si:entity.*loop)' 72s ok 4 - no exception thrown during parse 72s ok 5 - entity was parsed and expanded correctly 72s # Looks like you failed 2 tests of 5. 72s Dubious, test returned 2 (wstat 512, 0x200) 72s Failed 2/5 subtests It appears that upstream has fixed this issue in 2.0209 with commit 57e712c9[2]. Since we have only 2.0207 in sid, I therefore request to update this package to the latest upstream release, 2.0210, which would help unblock the migration of libxml2 to testing. [1]https://ci.debian.net/packages/libx/libxml-libxml-perl/testing/amd64/47035875/ [2]https://github.com/shlomif/perl-XML-LibXML/commit/57e712c98b285be4d286fd55a53984d4035fcb65
Bug#1067088: [Pkg-zfsonlinux-devel] Bug#1067088: zfs-linux: missing B-D: libtirpc-dev
Control: tags -1 + pending On Mon, Mar 18, 2024 at 5:31 PM Andreas Beckmann wrote: > > > This could be fixed by adding an explicit Build-Depends on libtirpc-dev. > The glibc change will likely be reverted in the short term, but given > its a change we want to do for Trixie, this will only lower the severity > of the bug. > This has been fixed in git and will be addressed in the next upload. https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/f2ca97fdca7a35d63a3bae1af106bc3c238ca95f Regards, Aron
Bug#1066279: [Debian-zh-dev] Bug#1066279: Bug#1066279: unicon: FTBFS: cin2tab.c:238:13: error: implicit declaration of function ‘tolower’ [-Werror=implicit-function-declaration]
On Thu, Mar 14, 2024 at 10:34 AM xiao sheng wen wrote: > > Hi, > > Thanks for your report. > > I'd uploaded the new version in mentors to fix this bug. > > https://mentors.debian.net/package/unicon/ > > Welcome to review and upload. > This has been sponsored to Sid, thanks for your contribution! Regards, Aron
Bug#1065089: ITP: libwww-telegram-botapi-perl -- module of Telegram Bot API in Perl
Package: wnnp Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org Owner: Aron Xu * Package name: libwww-telegram-botapi-perl Version : 0.12 Upstream Author : Roberto Frenna * URL : https://metacpan.org/release/WWW-Telegram-BotAPI * License : Artistic Programming Lang: Perl Description : module of Telegram Bot API in Perl WWW:TELEGRAM::BOTAPI is an implementation of Telegram Bot API in Perl, You can use it simply as an API if you want to implement logic by yourself, or you can enable retrieving of updates and get messages sent to your bot in a callback. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library
Hi, On Tue, 20 Feb 2024 14:43:22 +0800 MouseZhang wrote: > Hi, > > Thanks for your inquiry regarding the package. > > > * Which version of the original kwin is used? > Based on version 5.27.5 of the original kwin. > OK, please document that somewhere in your release. > > * What is missing from the original kwin and why is a fork needed? > The decision to fork the original kwin was driven by specific needs and > requirements that were not fully met by the original project. > This fork allows us to tailor the window manager more closely to our specific > features within the UKUI environment. > 1. Tablet Mode Support: We have incorporated support for the UKUI tablet > mode, which differs from the existing tablet mode mechanism in KWin. > Therefore, corresponding modifications are required to adapt to our desktop > environment. > 2. Virtual Keyboard: We have developed a virtual keyboard, but the current > window layering in KWin does not fully meet our needs. Particularly, when > using the virtual keyboard for text input, pop-up windows such as QCompleter > often obscure the virtual keyboard. To address this issue, we need to add a > new window layer to ensure that the virtual keyboard always displays above > popup windows. > 3. Custom Protocols: To fulfill the application requirements in the UKUI > environment, we have added or modified certain protocols, such as the blur > effect with gradual intensity changes. > 4. Window Snapping Functionality: We have implemented a window snapping > feature similar to that in Windows 11, which allows users to manage windows > more efficiently. > 5. Global Gestures: We have replaced the original edge gestures in KWin with > global gestures, such as using a four-finger swipe to invoke search. > 6. Dependency Management: We aim to release UKUI without some of the > dependencies associated with the Plasma desktop environment, while still > using KWin as our window manager and Wayland compositor. > 7. X11 Support: We require continued support for X11 and plan to develop new > features to ensure flexibility and compatibility of UKUI across various > systems. > Understood. > > * What changes have been made based on the original kwin? > Currently, ukui-kwin only replaces the name and does not conflict with the > original kwin. > In order to meet the Ubuntu DebianImportFreeze deadline, we hope to first > introduce ukui-kwin into the Debian repository and then proceed with > functionality transplantation. The existing kwin repository used by the UKUI > desktop environment is located at https://gitee.com/openkylin/kwin, which > includes the aforementioned functionality. However, this conflicts with the > original kwin, so we need to fork ukui-kwin. Subsequently, the functionality > will be transplanted into UKUI-Kwin (https://gitee.com/openkylin/ukui-kwin). > But this does not sound like a reason to just rename and release - if the reasons behind forking it aren't addressed to some certain extent, it makes little to no sense to duplicate it in the archive. Therefore I'd vote my -1 regarding this upload. Thanks, Aron
Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library
Hi, Since this package is a fork of kwin, would you mind to elaborate some technical questions: * Which version of the original kwin is used? * What is missing from the original kwin and why is a fork needed? * What changes have been made based on the original kwin? Also, it would be nice to mention this is a fork somewhere, rather than using a quick sed script to replace kwin to ukui-kwin everywhere. Thanks, Aron
Bug#1052597: RFS: libkysdk-base/2.2.0.1-1 -- common files for kylin sdk base library
Hi, It appears the included symbols file isn't complete and lintian complains: E: libkysdk-base: symbols-file-contains-current-version-with-debian-revision on symbol _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEE10json_value7destroyENS_6detail7value_tE@Base and 84 others (libkydiagnostics.so.1) [symbols] I: libkysdk-base: symbols-file-missing-build-depends-package-field libkydiagnostics.so.1 [symbols] Looking through the build log, dpkg-gensymbols has emitted some warnings: dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libkysdk-base/DEBIAN/symbols doesn't match completely debian/libkysdk-base.symbols --- debian/libkysdk-base.symbols (libkysdk-base_2.2.0.1-1_amd64) +++ dpkg-gensymbolsiEEcLA 2024-02-16 09:59:46.896778987 + @@ -18,6 +18,91 @@ _ZN3kdk11BuriedPointC2Ev@Base 2.2.0.1 _ZN3kdk11BuriedPointD1Ev@Base 2.2.0.1 _ZN3kdk11BuriedPointD2Ev@Base 2.2.0.1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEE1 0json_value7destroyENS_6detail7value_tE@Base 2.2.0.1-1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEEC 1EDn@Base 2.2.0.1-1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEEC 2EDn@Base 2.2.0.1-1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEED 1Ev@Base 2.2.0.1-1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEED 2Ev@Base 2.2.0.1-1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEEi xERKS8_@Base 2.2.0.1-1 + _ZN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES2_IhSaIhEEEi xIKcEERSC_PT_@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_s erializerES4_IhSaIhE12dump_escapedERKSA_b@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_s erializerES4_IhSaIhE12dump_integerIhLi0EEEvT_@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES4_IhSaIhE12dump_integerIlLi0EEEvT_@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES4_IhSaIhE12dump_integerImLi0EEEvT_@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES4_IhSaIhE4dumpERKSE_bbjj@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES4_IhSaIhED1Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail10serializerINS_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmdSaNS_14adl_serializerES4_IhSaIhED2Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail10type_errorD0Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail10type_errorD1Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail10type_errorD2Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail21output_string_adapterIcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIc15write_characterEc@Base 2.2.0.1-1+ _ZN8nlohmann6detail21output_string_adapterIcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIc16write_charactersEPKcm@Base 2.2.0.1-1 + _ZN8nlohmann6detail21output_string_adapterIcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD0Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail21output_string_adapterIcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD1Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail21output_string_adapterIcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD2Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail8to_charsIdEEPcS2_PKcT_@Base 2.2.0.1-1 + _ZN8nlohmann6detail9dtoa_impl13format_bufferEPc@Base 2.2.0.1-1 + _ZN8nlohmann6detail9dtoa_impl16grisu2_digit_genEPcRiS3_NS1_5diyfpES4_S4_@Base 2.2.0.1-1 + _ZN8nlohmann6detail9dtoa_impl18compute_boundariesIdEENS1_10boundariesET_@Base 2.2.0.1-1 + _ZN8nlohmann6detail9dtoa_impl6grisu2IdEEvPcRiS4_T_@Base 2.2.0.1-1 + _ZN8nlohmann6detail9exception4nameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base 2.2.0.1-1 + _ZN8nlohmann6detail9exceptionD0Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail9exceptionD1Ev@Base 2.2.0.1-1 + _ZN8nlohmann6detail9exceptionD2Ev@Base 2.2.0.1-1 +
Bug#1052597: RFS: libkysdk-base/2.2.0.1-1 -- common files for kylin sdk base library
Hi, It appears you've removed the symbols file for libraries included in the latest version on mentors.d.n, would you mind bringing it back? Thanks, Aron
Bug#1028613: [Pkg-zfsonlinux-devel] Bug#1028613: libpam-zfs: zfs_umount failed on closing ssh session
Hi, On Sat, Jan 6, 2024 at 1:27 AM 陈 晟祺 wrote: > > > You may want to try (as workaround): > > 1. skip pam_zfs_key when pam_systemd is used, as #12430 suggests; or, > 2. use `zfs allow` to grant `mount` permission to yourself. > I'd like to mention that zfs-allow cannot grant mount/umount permission on Linux as stated in zfs-allow(8): Delegations are supported under Linux with the exception of mount, unmount, mountpoint, canmount, rename, and share. These permissions cannot be delegated because the Linux mount(8) command restricts modifications of the global namespace to the root user. A way to work this around could be to allow zfs commands through /etc/sudoers.d/zfs configuration, which is commented out on Debian by default. Thanks, Aron
Bug#1059877: RFS: cglm/0.9.2-1 -- Optimized OpenGL Mathematics library for C
Hi, Thanks for the work! I would like to ask you to document the symbols update in d/changelog, otherwise this update looks fine. Thanks, Aron
Bug#1059040: libxml2: ABI change? (undefined references)
Hi Rene, On Wed, Dec 20, 2023 at 3:39 AM Rene Engelhard wrote: > > Am Tue, Dec 19, 2023 at 08:03:56PM +0100 schrieb Rene Engelhard: > > LibreOffice builds (patch available), but doesn't yet build with 2.12. > > "... but doesn't yet succeed the tests with 2.12" > > > S=/home/rene/LibreOffice/git/libreoffice-24-2 && I=$S/instdir && > > W=$S/workdir && /usr/bin/ccache x86_64-linux-gnu-g++ -pthread > > -flto=jobserver -fuse-linker-plugin -O2 -Wl,-z,origin > > '-Wl,-rpath,$ORIGIN/../Library' -Wl,-rpath-link,$I/program -Wl,-z,defs > > -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -Wl,--hash-style=gnu > > -Wl,-Bsymbolic-functions -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib > > -L$I/program -L$I/program -L$W/LinkTarget/Library -ffat-lto-objects > > -Wl,-z,relro$W/CxxObject/xmlsecurity/workben/pdfverify.o > > -Wl,--start-group-Wl,--end-group -Wl,--no-as-needed -luno_cppu > > -luno_cppuhelpergcc3 -luno_sal -lxmlsecurity -lmergedlo -o > > $W/LinkTarget/Executable/pdfverify > > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to > > `xmlIOFTPMatch@LIBXML2_2.4.30' > > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to > > `xmlNanoFTPCleanup@LIBXML2_2.4.30' > > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to > > `xmlIOFTPOpen@LIBXML2_2.4.30' > > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to > > `xmlIOFTPClose@LIBXML2_2.4.30' > > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to > > `xmlIOFTPRead@LIBXML2_2.4.30' > > /usr/bin/ld: /lib/x86_64-linux-gnu/libxmlsec1.so.1: undefined reference to > > `xmlNanoFTPInit@LIBXML2_2.4.30' > > collect2: error: ld returned 1 exit status > > make[3]: *** > > [/home/rene/LibreOffice/git/libreoffice-24-2/solenv/gbuild/LinkTarget.mk:853: > > > > /home/rene/LibreOffice/git/libreoffice-24-2/workdir/LinkTarget/Executable/pdfverify] > > Error 1 > > > > Do we have removed symbols/removed versions here? (libxmlsec.so.1 was > > not rebuilt) > > After a rebuild of libxmlsec1 this link succeeds... > I see that you've committed this patch[1] to libreoffice, does this mean I can proceed to upload this version of libxml2 to unstable without further action? Or is there anything else I should coordinate with you to prevent breakage? Regards, Aron Xu [1]https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/56d340483b0285c079c7ac08ddf441457d40b955
Bug#1042730:
Control: retitle -1 bookworm-pu: package zfs-linux/2.1.11-1+deb12u1 Hi, Please find a further updated version of debdiff in the attachment, it includes the fix for Bug #1056752 which is a data loss issue. The debdiff itself looks very large (2298 insertions), but filtering the actual changes there are quite a lot of upstream commit messages and noises of test cases: $ cd zfs-linux-2.1.11/debian/patches/ $ diffstat 001[2-9]*.patch 002*.patch b/cmd/zed/agents/zfs_mod.c |2 b/cmd/zed/agents/zfs_retire.c |8 + b/contrib/bash_completion.d/zfs.in |2 b/contrib/initramfs/scripts/zfs |6 - b/contrib/pam_zfs_key/pam_zfs_key.c | 13 -- b/include/sys/spa.h |1 b/module/os/linux/spl/spl-kmem-cache.c | 12 ++ b/module/os/linux/zfs/zfs_vnops_os.c |6 + b/module/zfs/dmu_recv.c | 26 + b/module/zfs/dmu_send.c |8 + b/module/zfs/dnode.c | 12 ++ b/module/zfs/mmp.c |2 b/module/zfs/spa.c |5 - b/module/zfs/spa_misc.c | 29 +- b/module/zfs/vdev.c | 12 ++ b/module/zfs/vdev_label.c |3 b/module/zfs/vdev_trim.c | 28 -- b/module/zfs/zil.c |1 b/tests/runfiles/common.run |2 b/tests/runfiles/sanity.run |1 b/tests/zfs-tests/tests/functional/cli_root/zpool_import/Makefile.am |1 b/tests/zfs-tests/tests/functional/cli_root/zpool_import/import_log_missing.ksh | 75 + b/tests/zfs-tests/tests/functional/cli_root/zpool_resilver/Makefile.am |3 b/tests/zfs-tests/tests/functional/cli_root/zpool_resilver/zpool_resilver_concurrent.ksh | 101 +++ b/tests/zfs-tests/tests/functional/l2arc/persist_l2arc_001_pos.ksh | 19 +--- b/tests/zfs-tests/tests/functional/rsend/Makefile.am |1 b/tests/zfs-tests/tests/functional/rsend/send_encrypted_freeobjects.ksh | 87 +++ cmd/zed/agents/zfs_retire.c |5 + include/sys/spa.h |2 module/zfs/spa.c | 15 +++ module/zfs/vdev.c | 24 - tests/runfiles/common.run |9 +- 32 files changed, 460 insertions(+), 61 deletions(-) There are totally 299 changes in tests which are mostly insertions. Thanks, Aron zfs-linux_2.1.11-1+deb12u1.debdiff Description: Binary data
Bug#1056752: [Pkg-zfsonlinux-devel] Bug#1056752: CVE-2023-49298 also affect Bullseye and Bookworm
Hi, On Sat, Dec 2, 2023 at 3:51 PM Roman Veselý wrote: > > Dear Maintainers, > > The bug CVE-2023-49298 is here: https://tracker.debian.org/pkg/zfs-linux > marked as LOW PRIORITY for Bullseye and Bookworm. > > Are you planning to fix this bug in Bullseye and Bookworm soon? > > For many users, the fix is important - if the official Debian fix will take > longer, > it's good to know and make the fix yourself. > > Thank you for your support for ZFS in Debian, > The fix will land in bookworm-backports and bullseye-backports-sloppy shortly after 2.1.14-1 migrates to testing, which will take about 2 days hopefully. Fixes to 2.0.3-9+deb11u1 (bullseye) and 2.1.11-1 (bookworm) are planned but will likely take more time. Such an issue is marked low-priority because the bug itself isn't urgent from a security update point of view, which means an attacker can only cause damage in rare cases. It's still recommended to update or at least apply mitigations to the problem (by setting zfs_dmu_offset_next_sync to 0 on bookworm) to avoid potential data loss. Thanks, Aron
Bug#1052597: RFS: libkysdk-base/2.2.0.1-1 -- common files for kylin sdk base library
Hi, On Mon, 25 Sep 2023 11:11:05 +0800 "xibowen" wrote: > > Changes since the last upload: > > libkysdk-base (2.2.0.1-1) unstable; urgency=medium > . >* Update libs soname version. >* Fix compile error on armhf and ppc64el. >* d/control: > - Add libkysdk-base-common. > - Add Multi-Arch. > I'm curious if libkysdk-base-common is really needed? This will also require a NEW processing btw. $ cat libkysdk-base-common.install etc/kysdk/kysdk-base/kylog-rotate-default src/log/kylog-default.conf etc/kysdk/kysdk-base Regards, Aron
Bug#1035936: fixed in maradns 2.0.13-1.4+deb11u1
Hi, On Sat, Oct 28, 2023 at 4:39 PM Andreas Beckmann wrote: > > On Thu, 29 Jun 2023 22:32:33 + Debian FTP Masters > wrote: > > Source: maradns > > Source-Version: 2.0.13-1.4+deb11u1 > > Done: Aron Xu > > > maradns (2.0.13-1.4+deb11u1) bullseye-security; urgency=high > > . > >* Non-maintainer upload by the Security Team, patches are from > > Bastien Roucariès of LTS team. > >* CVE-2023-31137: integer underflow in the DNS packet decompression > > (Closes: #1035936). > >* CVE-2022-30256: revoked and expired domains remain resolvable for > > a long time (Closes: #1033252). > > Can you upload that to unstable, too? > Sure, I will do that shortly. Thanks, Aron
Bug#1054567: ocserv: Compilation error on the LoongArch architecture
Hi, > On Oct 26, 2023, at 10:54, wuruilong wrote: > > Source: ocserv > Version: 1.2.1-1 > Severity: normal > X-Debbugs-Cc: wuruil...@loongson.cn > > Dear Maintainer, > > There is a compilation error for ocserv on the loongarch machine. > Tested the patch attached to the email on the LoongArch machine and it > resolved the issue. > I see the patch is quite straightforward, would you mind submit it to upstream, too? Cheers, Aron
Bug#1042730: bookworm-pu: package zfs-linux/2.1.12-1~deb12u1
Control: tag -1 - moreinfo Hi, On Wed, Aug 2, 2023 at 3:57 AM Jonathan Wiltshire wrote: > > On Mon, Jul 31, 2023 at 03:53:23PM +0800, Aron Xu wrote: > > zfs-linux in bookworm is affected by #1040183 which is considered an > > important malfunction. > > Please cherry-pick a fix for this and propose a new debdiff; the upstream > release contains too much else to be accepted. > I've tried to narrow down to a couple of stability fixes, with explanations for each patch in d/changelog, would you mind having a look? Thanks, Aron zfs-linux_2.1.11-1+deb12u1.debdiff Description: Binary data
Bug#1036062: frr: CVE-2023-31490
Hi, On Tue, 11 Jul 2023 13:47:46 +0300 Adrian Bunk wrote: > On Tue, Jun 13, 2023 at 03:17:52PM +0200, David Lamparter wrote: > > Fixed upstream in 9f1ba873637fd6ce4a2d366eafcf41402775852b on stable/8.4 > > branch. > > > > Debian fix incoming with bump to 8.4.4 if that's OK? That wouldn't be a > > targeted security fix, but FRR minor versions are bugfix-only. > > These two CVEs are not marked "no-dsa" so far, it would be for Salvatore > or someone else from the security team to decide what is acceptable if > they want to publish a security advisory for bookworm. > > > -equi > > cu > Adrian > I've read through upstream changes from 8.4.2 to 8.4.4 and agreed it is a stable bugfix-only update. I have talked to Salvatore and believe it's a good idea to upload 8.4.4 through bookworm-security to address those issues. Would you mind preparing and uploading it to security-master? Please use a lower version number than testing, e.g. 8.4.4-1~deb12u1. Thanks, Aron
Bug#1041465: pristine-tar: pristine-xz failed to reproduce build of ../libxml2-2.11.4.tar.xz
Package: pristine-tar Version: 1.50 Severity: important While importing libxml2-2.11.4.tar.xz through gbp: $ gbp import-orig --pristine-tar ../libxml2-2.11.4.tar.xz What is the upstream version? [2.11.4] gbp:info: Importing '../libxml2-2.11.4.tar.xz' to branch 'upstream'... gbp:info: Source package is libxml2 gbp:info: Upstream version is 2.11.4 gbp:error: Import of ../libxml2_2.11.4.orig.tar.xz failed: Couldn't commit to 'pristine-tar' with upstream '96ab8ed14cb3 6463c3531d5f6f3c8c897d187d57': pristine-xz failed to reproduce build of ../libxml2_2.11.4.orig.tar.xz (Please file a bug report.) pristine-tar: failed to generate delta gbp:error: Error detected, Will roll back changes. gbp:info: Rolling back branch upstream by resetting it to 7188a3bc963343a2dfc60c7510807e6c3c14aeda gbp:info: Rolling back branch pristine-tar by resetting it to 96b561e8b4f167e53a88f8b68703c79d1735d6c2 gbp:error: Rolled back changes after import error. The tarball is at https://download.gnome.org/sources/libxml2/2.11/libxml2-2.11.4.tar.xz And the git repository to import to: https://salsa.debian.org/xml-sgml-team/libxml2/ Thanks, Aron
Bug#1006551: bullseye-pu: package tiff/4.2.0-1+deb11u1
Hi SRMs, I think this can be closed since tiff already has the deb11u4 version in bullseye through a previous security update. Regards, Aron
Bug#1040041: bookworm-pu: package dnf/4.14.0-3+deb12u1
Hi! On Sat, Jul 1, 2023 at 10:44 PM Frédéric Pierret wrote: > > Hello Aron, > I'm sorry for the delay, I'm just getting out of Holidays and other duties. > If anything should be done, let me know. > > Also, I rely a lot on Holger for pushing stuff, and I need to candidate for > DM/DD, just need to find time to do that. > Fully understand and that's perfectly OK. I'm just trying to speed up the process since everyone can propose a proposed-updates to stable release unless the maintainer has objections, which I don't think we are in the case, ;-) Regards, Aron
Bug#1040041: bookworm-pu: package dnf/4.14.0-3+deb12u1
On Sat, Jul 1, 2023 at 10:47 PM Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > On Sat, 2023-07-01 at 22:13 +0800, Aron Xu wrote: > > Fix bug in stable release affecting dependent package (Bug #1034828, > > affecting src:dnf-plugins-core). > > > > We generally prefer codenames - i.e. "bookworm" - rather than suites > (i.e. "stable") in changelogs. > > Please go ahead. > Uploaded, with changelog entry aligned to use "bookworm" instead of "stable". Thanks! Aron
Bug#1040041: bookworm-pu: package dnf/4.14.0-3+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: d...@packages.debian.org Hi, [ Reason ] Fix bug in stable release affecting dependent package (Bug #1034828, affecting src:dnf-plugins-core). [ Impact ] Unfixed bug, dnf-plugins-core will not work with default configuration. [ Tests ] dnf has a testsuite, run at build time. [ Risks ] Only change defaults to Debian's python dist-packages path, risk is minimal. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable The proposed debdiff is identical to the version in unstable (4.14.0-4) except filtering out an indentation change in d/rules. [ Changes ] dnf encodes PYTNON_INSTALL_DIR into it's PLUGINPATH during build, which is not desired Debian's dist-packages path, thus packaged plugins are not found. This update changes it to a value corrospond to Debian defaults. Regards, Aron dnf_4.14.0-3+deb12u1.debdiff Description: Binary data
Bug#1039487: [Pkg-zfsonlinux-devel] Bug#1039487: zfs-dkms: autopkgtest fails on Linux 6.3 (arm64 only)
Control: forwarded -1 https://github.com/openzfs/zfs/issues/14555 The issue first appeared in Linux 6.2, caused by commit aaeca98456431a8d9382ecf48ac4843e252c07b3[1]. Let's wait a bit to see what upstream would respond. We could patch to disable simd on arm64 (as well as the runtime benchmarks with simd) as a last resort, though I personally wish to avoid that. [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aaeca98456431a8d9382ecf48ac4843e252c07b3 Regards, Aron
Bug#1034828:
As discussed, this issue could be in the dnf package which didn't have the PLUGINPATH updated to Debian's path, which could be verified in /usr/lib/python3/dist-packages/dnf/const.py. Can be worked around by adding the following line in [main] section of /etc/dnf/dnf.conf: pluginpath=/usr/lib/python3/dist-packages/dnf-plugins Regards, Aron
Bug#1034569: dolphin: very slow and cpu hungery for displaying thumbnails of CR3 raw image files
Package: dolphin Version: 5.103-2 Hi, Dolphin gains the ability to display thumbnails of Canon's CR3 raw image files through the updated libraw and kimageformats in bookworm, but it is too slow and consumes too much CPU especially when the directory has a number of image files and RAW preview is toggled on in preference, the fans of my workstation are roaring constantly. It looks to me that it's always trying to render the thumbnail from a full RAW file, rather than using the embedded thumbnail (which is commonly seen in RAW image formats). Darktable in bookworm, which is also backed by libraw for CR3 support, is able to display the embedded thumbnail. Finally I'm not sure whether this report is suitable for dolphin or kimageformat-plugins, please help reassign the proper package. Thanks, Aron
Bug#1032237: bullseye-pu: zfs-linux/2.0.3-9+deb11u1
Control: tags -1 - moreinfo On Sun, Apr 2, 2023 at 3:10 AM Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > On Thu, 2023-03-02 at 15:33 +0800, Aron Xu wrote: > > I would like to apply a few patches to address some stability issues > > in the > > zfs-linux package in bullseye. All the patches are cherry-picked from > > upstream > > > > 2.0.x and 2.1.x stable branches. > > > > +This change reworks the zfs_file_[get|put] interface to not rely > +on the file descriptor but instead pass the zfs_file_t pointer around. > > I'm assuming that nothing outside of zfs-linux depends on the signature > of the affected functions? > No, there are no other packages depending on the signature of the affected functions. Regards, Aron
Bug#1033614: unblock: zfs-linux/2.1.9-3
Package: release.debian.org Severity: normal User:release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc:pkg-zfsonlinux-de...@alioth-lists.debian.net Please unblock the package zfs-linux/2.1.9-3. [ Reason ] zfs-linux has autopkgtest but it never passed on armel (because the kernel header detection logic), even though this is marked as "Not a regression" auto-migration is blocked. See https://ci.debian.net/packages/z/zfs-linux/testing/armel/ Changes included are targeted small fixes based on upstream 2.1.10-staging branch, which is intended for releasing the next stable minor release. Most importantly, there is a change fixing https://github.com/openzfs/zfs/issues/14599 which we have in the previous 2.1.9-2 that would affect some users from booting the system. [ Impact ] The user won't notice any difference except some bugs have been fixed. [ Tests ] Manually installed the binaries and verified that things work as expected. [ Risks ] Changes are minimal. I can't think of any negative side effects. Because some of the new patches are added to series file in the middle, it results in quite some noise in the debdiff (some old patches are shown as removed). To help reviewing the patches, the commit itself can be found on salsa: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/a02ecc74c240e64ead560091ae68f2252b072adf New patches are: * 0002-System-wide-speculative-prefetch-limit.patch include/sys/arc_impl.h | 1 + module/zfs/dmu_zfetch.c | 29 - 2 files changed, 25 insertions(+), 5 deletions(-) * 0003-Add-missing-increment-to-dsl_deadlist_move_bpobj.patch module/zfs/dsl_deadlist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) * 0008-initramfs-fix-zpool-get-argument-order.patch contrib/initramfs/scripts/zfs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) * 0011-Fix-for-mountpoint-legacy.patch contrib/initramfs/scripts/zfs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) * 0012-QAT-Fix-uninitialized-seed-in-QAT-compression.patch module/os/linux/zfs/qat_compress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock zfs-linux/2.1.9-3 zfs-linux_2.1.9-3.debdiff Description: Binary data
Bug#1032863: unblock: mitmproxy/8.1.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: mitmpr...@packages.debian.org Control: affects -1 + mitmproxy Dear Release Team, Could you unblock package mitmproxy/8.1.1-2, in this version it applies an upstream patch to fix Python 3.11 compatibility, otherwise the package would fail to start, although the original bug report (#1031787) wasn't marked RC. Regards, Aron diff -Nru mitmproxy-8.1.1/debian/changelog mitmproxy-8.1.1/debian/changelog --- mitmproxy-8.1.1/debian/changelog2023-02-06 00:00:42.0 +0800 +++ mitmproxy-8.1.1/debian/changelog2023-03-03 01:21:00.0 +0800 @@ -1,3 +1,10 @@ +mitmproxy (8.1.1-2) unstable; urgency=medium + + * Team upload. + * Add upstream patch to fix Python 3.11 compatibility (Closes: #1031787) + + -- Aron Xu Fri, 03 Mar 2023 01:21:00 +0800 + mitmproxy (8.1.1-1) unstable; urgency=high * Team upload diff -Nru mitmproxy-8.1.1/debian/patches/0007-use-default_factory-for-parser_options-field-5476.patch mitmproxy-8.1.1/debian/patches/0007-use-default_factory-for-parser_options-field-5476.patch --- mitmproxy-8.1.1/debian/patches/0007-use-default_factory-for-parser_options-field-5476.patch 1970-01-01 08:00:00.0 +0800 +++ mitmproxy-8.1.1/debian/patches/0007-use-default_factory-for-parser_options-field-5476.patch 2023-03-03 01:20:48.0 +0800 @@ -0,0 +1,34 @@ +From 55a64b7ad993fd52fbff19f33e3c6e153b3e8d9b Mon Sep 17 00:00:00 2001 +From: rathann +Date: Sat, 23 Jul 2022 10:15:03 +0200 +Subject: [PATCH] use default_factory for parser_options field (#5476) + +* use default_factory for field parser_options + +When running mitmproxy under python 3.11, the following exception +is thrown otherwise: +``` +ValueError: mutable default for field parser_options is not allowed: use default_factory +``` + +Fixes #5474. +--- + mitmproxy/contentviews/grpc.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/mitmproxy/contentviews/grpc.py b/mitmproxy/contentviews/grpc.py +index a5ef99708..5c73220c8 100644 +--- a/mitmproxy/contentviews/grpc.py b/mitmproxy/contentviews/grpc.py +@@ -951,7 +951,7 @@ def format_grpc( + + @dataclass + class ViewConfig: +-parser_options: ProtoParser.ParserOptions = ProtoParser.ParserOptions() ++parser_options: ProtoParser.ParserOptions = field(default_factory=ProtoParser.ParserOptions) + parser_rules: list[ProtoParser.ParserRule] = field(default_factory=list) + + +-- +2.30.2 + diff -Nru mitmproxy-8.1.1/debian/patches/series mitmproxy-8.1.1/debian/patches/series --- mitmproxy-8.1.1/debian/patches/series 2023-02-06 00:00:42.0 +0800 +++ mitmproxy-8.1.1/debian/patches/series 2023-03-03 01:19:49.0 +0800 @@ -3,3 +3,4 @@ 0004-Remove-test_cibuild.py.patch 0005-Remove-test_readfile.py.patch 0006-Delete-asciinema-for-which-we-only-have-minified-ver.patch +0007-use-default_factory-for-parser_options-field-5476.patch signature.asc Description: PGP signature
Bug#1032237: bullseye-pu: zfs-linux/2.0.3-9+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: pkg-zfsonlinux-de...@alioth-lists.debian.net Dear release team, I would like to apply a few patches to address some stability issues in the zfs-linux package in bullseye. All the patches are cherry-picked from upstream 2.0.x and 2.1.x stable branches. * 0002-Initialize-ZIL-buffers.patch zio_crypt.c |1 + 1 file changed, 1 insertion(+) * 0003-Fix-crash-in-zio_done-error-reporting.patch zio.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) * 0004-Fix-AVX512BW-Fletcher-code-on-AVX512-but-not-BW-mach.patch zfs_fletcher_avx512.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) * 0005-Fix-zfs_get_data-access-to-files-with-wrong-generati.patch cmd/ztest/ztest.c |4 ++-- include/sys/zil.h |3 ++- include/sys/zvol_impl.h|4 ++-- module/os/linux/zfs/zfs_vnops_os.c | 14 +- module/zfs/zfs_log.c |5 + module/zfs/zil.c |3 ++- module/zfs/zvol.c |3 ++- 7 files changed, 28 insertions(+), 8 deletions(-) * 0006-Linux-always-check-or-verify-return-of-igrab.patch include/os/linux/zfs/sys/zfs_znode_impl.h |8 +++- module/os/linux/zfs/zfs_ctldir.c |3 ++- module/os/linux/zfs/zfs_vfsops.c |6 +- module/os/linux/zfs/zpl_inode.c |3 ++- 4 files changed, 16 insertions(+), 4 deletions(-) * 0007-Avoid-deadlock-when-removing-L2ARC-devices-under-I-O.patch arc.c | 17 ++--- zio.c |3 --- 2 files changed, 6 insertions(+), 14 deletions(-) * 0008-file-reference-counts-can-get-corrupted.patch include/sys/fm/util.h |5 +++-- include/sys/zfs_file.h |6 -- include/sys/zfs_ioctl.h |2 +- include/sys/zfs_onexit.h|4 ++-- lib/libzpool/kernel.c | 20 +--- module/os/freebsd/zfs/zfs_file_os.c | 19 ++- module/os/linux/zfs/zfs_file_os.c | 28 +++- module/zfs/fm.c | 20 module/zfs/zfs_ioctl.c | 71 ++- module/zfs/zfs_onexit.c | 23 +-- 10 files changed, 91 insertions(+), 107 deletions(-) * 0009-libshare-nfs-don-t-leak-nfs_lock_fd-when-lock-fails.patch freebsd/nfs.c | 13 + linux/nfs.c | 13 + 2 files changed, 18 insertions(+), 8 deletions(-) Regards, Aron diff -Nru zfs-linux-2.0.3/debian/changelog zfs-linux-2.0.3/debian/changelog --- zfs-linux-2.0.3/debian/changelog2021-07-01 13:44:20.0 +0800 +++ zfs-linux-2.0.3/debian/changelog2023-03-02 00:15:02.0 +0800 @@ -1,3 +1,9 @@ +zfs-linux (2.0.3-9+deb11u1) bullseye; urgency=medium + + * cherry-pick upstream fixes for stability issues + + -- Aron Xu Thu, 02 Mar 2023 00:15:02 +0800 + zfs-linux (2.0.3-9) unstable; urgency=medium * Cherry-pick "Remove iov_iter_advance() for iter_write" (Closes: #989373) diff -Nru zfs-linux-2.0.3/debian/patches/0002-Initialize-ZIL-buffers.patch zfs-linux-2.0.3/debian/patches/0002-Initialize-ZIL-buffers.patch --- zfs-linux-2.0.3/debian/patches/0002-Initialize-ZIL-buffers.patch 1970-01-01 08:00:00.0 +0800 +++ zfs-linux-2.0.3/debian/patches/0002-Initialize-ZIL-buffers.patch 2023-02-27 15:29:01.0 +0800 @@ -0,0 +1,31 @@ +From e219935f10f6f604a3dafb4727715c3741480fd4 Mon Sep 17 00:00:00 2001 +From: Brian Behlendorf +Date: Fri, 5 Mar 2021 14:45:13 -0800 +Subject: [PATCH] Initialize ZIL buffers + +When populating a ZIL destination buffer ensure it is always +zeroed before its contents are constructed. + +Reviewed-by: Matthew Ahrens +Reviewed-by: Tom Caputi +Signed-off-by: Brian Behlendorf +Closes #11687 +--- + module/os/linux/zfs/zio_crypt.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/module/os/linux/zfs/zio_crypt.c b/module/os/linux/zfs/zio_crypt.c +index 96dabe55a..e2abc0ae2 100644 +--- a/module/os/linux/zfs/zio_crypt.c b/module/os/linux/zfs/zio_crypt.c +@@ -1399,6 +1399,7 @@ zio_crypt_init_uios_zil(boolean_t encrypt, uint8_t *plainbuf, + nr_src = 1; + nr_dst = 0; + } ++ bzero(dst, datalen); + + /* find the start and end record of the log block */ + zilc = (zil_chain_t *)src; +-- +2.30.2 + diff -Nru zfs-linux-2.0.3/debian/patches/0003-Fix-crash-in-zio_done-error-reporting.patch zfs-linux-2.0.3/debian/patches/0003-Fix-crash-in-zio_done-error-reporting.patch --- zfs-linux-2.0.3/debian/patches/0003-Fix-crash-in-zio_done-error-reporting.patch 1970-01-01 08:00:00.0 +0800 +++ zfs-linux-2.0.3/debian/patches/0003-Fix-crash-in-zio_done-error-reporting.patch 2023-02-27 15:33:33.0 +0800 @@ -0,0 +1,4
Bug#1030841: ITP: frp -- A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet
Hi, On Wed, Feb 8, 2023 at 4:39 PM Bo YU wrote: > > Package: wnpp > Severity: wishlist > Owner: Bo YU > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: frp > Version : 0.36.1-1 > Upstream Author : > * URL : https://github.com/fatedier/frp > * License : Apache-2.0 > Programming Lang: Go > Description : A fast reverse proxy to help you expose a local server > behind a NAT or firewall to the internet. > > . > frp is a fast reverse proxy to help you expose a local server behind a > NAT or firewall to the Internet. As of now, it supports **TCP** and > **UDP**, as well as **HTTP** and **HTTPS** protocols, where requests can > be forwarded to internal services by domain name. > . > > This package will be maintained under Debian go team. > Thanks for contributing to Debian! I'd like to mention that please make sure that the default configuration shipped with Debian package is reasonably secure after installation, based on my limited knowledge of its upstream defaults. Regards, Aron
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Fri, Jan 27, 2023 at 9:42 PM Andreas Tille wrote: > > Am Fri, Jan 27, 2023 at 08:21:46PM +0800 schrieb Aron Xu: > > On Fri, Jan 27, 2023 at 7:12 PM Andreas Tille wrote: > > > make: *** [debian/rules:83: binary] Terminated > > > ninja: build stopped: interrupted by user. > > > > > > could be a sign for this. Was I to naive to assume Salsa CI could > > > manage a pytorch build and should we possibly switch this off again? > > > > > > > Not sure but by wild guess it could be caused by running for too long? > > I do not think so. Since I was aware that it will take long I have > adjusted the timeout from 1h (default) to 4h. The log stops a bit after > 3h. To my experience if timeout is the reason the log ends with this > information. > Then I guess it could be out-of-memory, the build process is hungry for RAM and a single cc1plus process can take at least up to 2GB memory during my quick observation. Regards, Aron
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Fri, Jan 27, 2023 at 9:42 PM Andreas Tille wrote:
>
> So what help could I (as someone who does not know pytorch at all, just
> maintains some packages that are depending from it) can I provide?
>
Here is the fail log just in case you can have a look...
/build/pytorch/build$ ninja
[1/5] Building CXX object
caffe2/torch/CMakeFiles/torch_python.dir/csrc/Exceptions.cpp.o
FAILED: caffe2/torch/CMakeFiles/torch_python.dir/csrc/Exceptions.cpp.o
/usr/bin/c++ -DAT_PER_OPERATOR_HEADERS -DBUILDING_TESTS
-DGFLAGS_IS_A_DLL=0 -DGLOG_CUSTOM_PREFIX_SUPPORT
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1
-DHAVE_SHM_UNLINK=1 -DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS
-DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 -DONNX_NAMESPACE=onnx
-DTHP_BUILD_MAIN_LIB -DUSE_C10D -DUSE_C10D_GLOO -DUSE_DISTRIBUTED
-DUSE_EXTERNAL_MZCRC -DUSE_NUMPY -DUSE_RPC -DUSE_TENSORPIPE
-DUSE_VALGRIND -D_FILE_OFFSET_BITS=64 -Dtorch_python_EXPORTS
-I/build/pytorch/build/aten/src -I/build/pytorch/aten/src
-I/build/pytorch/build -I/build/pytorch
-I/build/pytorch/cmake/../third_party/benchmark/include
-I/build/pytorch/debian/foxi -I/build/pytorch/build/debian/foxi
-I/build/pytorch/torch/.. -I/build/pytorch/torch/../aten/src
-I/build/pytorch/torch/../aten/src/TH
-I/build/pytorch/build/caffe2/aten/src
-I/build/pytorch/build/third_party
-I/build/pytorch/build/third_party/onnx
-I/build/pytorch/torch/../third_party/valgrind-headers
-I/build/pytorch/torch/../third_party/gloo
-I/build/pytorch/torch/../third_party/onnx
-I/build/pytorch/torch/../third_party/flatbuffers/include
-I/build/pytorch/debian/kineto/libkineto/include
-I/build/pytorch/torch/csrc -I/build/pytorch/torch/csrc/api/include
-I/build/pytorch/torch/lib -I/build/pytorch/torch/lib/libshm
-I/build/pytorch/torch/csrc/api -I/build/pytorch/c10/..
-I/build/pytorch/torch/lib/libshm/../../../torch/lib -isystem
/build/pytorch/build/third_party/gloo -isystem
/build/pytorch/cmake/../third_party/gloo -isystem
/build/pytorch/cmake/../third_party/googletest/googlemock/include
-isystem /build/pytorch/cmake/../third_party/googletest/googletest/include
-isystem /usr/include/opencv4 -isystem /usr/include/eigen3 -isystem
/usr/include/python3.11 -isystem
/usr/lib/python3/dist-packages/numpy/core/include -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/build/pytorch=.
-fstack-protector-strong -Wformat -Werror=format-security
-gsplit-dwarf -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp
-DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE
-DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra
-Werror=return-type -Werror=non-virtual-dtor
-Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds
-Wno-unknown-pragmas -Wunused-local-typedefs -Wno-unused-parameter
-Wno-unused-function -Wno-unused-result -Wno-strict-overflow
-Wno-strict-aliasing -Wno-error=deprecated-declarations
-Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic
-Wno-error=redundant-decls -Wno-error=old-style-cast
-fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable
-Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math
-Werror=format -Werror=cast-function-type -Wno-stringop-overflow
-DHAVE_AVX512_CPU_DEFINITION -DHAVE_AVX2_CPU_DEFINITION -O2 -g
-DNDEBUG -fPIC -DCAFFE2_USE_GLOO -DTH_HAVE_THREAD -Wno-unused-variable
-fno-strict-aliasing -Wno-write-strings -Wno-strict-aliasing
-std=gnu++14 -MD -MT
caffe2/torch/CMakeFiles/torch_python.dir/csrc/Exceptions.cpp.o -MF
caffe2/torch/CMakeFiles/torch_python.dir/csrc/Exceptions.cpp.o.d -o
caffe2/torch/CMakeFiles/torch_python.dir/csrc/Exceptions.cpp.o -c
/build/pytorch/torch/csrc/Exceptions.cpp
/build/pytorch/torch/csrc/Exceptions.cpp: In destructor
'torch::PyWarningHandler::~PyWarningHandler()':
/build/pytorch/torch/csrc/Exceptions.cpp:264:23: error: no matching
function for call to 'format_to(fmt::v9::memory_buffer&,
torch::PyWarningHandler::~PyWarningHandler()FMT_COMPILE_STRING,
std::__cxx11::basic_string&, const char*&, uint32_t&)'
264 | fmt::format_to(
| ~~^
265 | buf,
|
266 | FMT_STRING("{} (Triggered internally at {}:{}.)"),
| ~~
267 | msg,
|
268 | source_location.file,
| ~
269 | source_location.line);
| ~
In file included from /usr/include/fmt/format.h:48,
from /build/pytorch/torch/csrc/Exceptions.cpp:10:
/usr/include/fmt/core.h:3233:17: note: candidate: 'template::value, int>::type > OutputIt
fmt::v9::format_to(OutputIt, format_string, T&& ...)'
3233 | FMT_INLINE auto format_to(OutputIt out, format_string
fmt, T&&... args)
| ^
/usr/include/fmt/core.h:3233:17: note: template argument
deduction/substitution failed:
/usr/include/fmt/core.h:3232:11: error: no type named 'type' in
'struct
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Fri, Jan 27, 2023 at 7:12 PM Andreas Tille wrote: > > BTW, I tried to switch on Salsa-CI which failed[2] and I suspect this > might be due to insufficient memory. At least I've found references in > Web that > > make: *** [debian/rules:83: binary] Terminated > ninja: build stopped: interrupted by user. > > could be a sign for this. Was I to naive to assume Salsa CI could > manage a pytorch build and should we possibly switch this off again? > Not sure but by wild guess it could be caused by running for too long? I'm building and testing it with a quite high end configuration that's able to finish the build stage in a few minutes... Regards, Aron
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
On Fri, Jan 27, 2023 at 3:48 PM Andreas Tille wrote: > > Hi Aron, > > Am Fri, Jan 27, 2023 at 02:09:05AM +0800 schrieb Aron Xu: > > > > The packaging work of 1.13.1[1] has started on salsa. We still have a > > failure related to fmtlib before making the package build successfully > > [5/1781]. Both Mo and I have limited bandwidth here and help is always > > appreciated. > > I've just checked the changelog and noticed: > >Bump SOVERSION to 1.13 > > but we are in transition freeze. So this needs to be coordinated with > release team. I guess if we argue that 1.13 will support Python3.11 > this could be some argument after the decision that this should be the > supported Python3 version for the next release. > Agreed. And it seems the only rdepends of libtorch1.12 is python3-torchvision which is owned by us, too, so the update would be fairly easy to handle. Regards, Aron
Bug#1027851: pytorch FTBFS with Python 3.11 as default version
Hi On Fri, Jan 27, 2023 at 1:27 AM Andreas Tille wrote: > > Hi, > > I was checking this bug log and realised, that the "Forwarded" field > links to an old PR[1] that was merged long before this bug was filed. > Checking upstream I realised that the Debian package is lagging behind > upstream releases. > > Could someone please give a status update what might be the plan to get > pytorch back into testing (either be applying the PR patch to the old > version or upgrading to latest upstream which will most probably support > Python 3.11). > The packaging work of 1.13.1[1] has started on salsa. We still have a failure related to fmtlib before making the package build successfully [5/1781]. Both Mo and I have limited bandwidth here and help is always appreciated. [1]https://salsa.debian.org/deeplearning-team/pytorch Regards, Aron
Bug#958242: Bug #958242: Use system libinih-dev
ocserv uses a modified version[1] of inih, I wonder what would the possibility of updating/merging these changes to system libinih-dev? [1]https://gitlab.com/openconnect/ocserv/-/commit/92c31d1c02b49232b310177f7a6ec361c79880bf Regards, Aron
Bug#1029063: anbox-binder issues reported to src:linux/src:dkms
Control: severity -1 normal dkms never risks creating an unbootable environment by exiting with an error during the configuration of the corresponding linux-image-* package when a module fails to build. Even though it looks annoying when the failing dkms packages are not-so-critical to booting the system, dkms has no knowledge about which package is critical and which is less harmful. I'm downgrading the issue to normal severity to allow more discussion on possible better handling of such cases in the future. For anbox-binder users who are reporting this issue to src:linux/src:dkms on sid/testing, please look for updating the source if it's very useful to you and hold the linux-image-* package for a while, or remove it to allow upgrading to newer version of linux packages for the moment. Regards, Aron
Bug#1023127: [Pkg-zfsonlinux-devel] Bug#1023127: zfs-linux: please make zfs-{initramfs, dracut} Depend on their respective -core packages
Hi, On Sun, Oct 30, 2022 at 9:42 PM наб wrote: > > Source: zfs-linux > Version: 2.1.6-2 > Severity: wishlist > Tags: patch > > Dear Maintainer, > > Currently, zfs-initramfs and zfs-dracut are not co-installable, > because they have Depends: initramfs-tools and dracut, respectively, > and those conflict. > > initramfs-tools and dracut are the "please use > initramfs-tools-core/dracut-core to generate system initrds" > integration-only packages. > > The actual generation program and plugins are provided in the > -core packages. Please consider the attached patches, based on recent > Salsa, to make them co-installable. > If I understand correctly, the -core packages provide the tools for generating initramfs, but they'll not automatically update the actual initramfs image. Depending only on the -core packages looks a bit unusual for integration packages like zfs-initramfs and zfs-dracut, for example cryptsetup,dropbear (they do not provide -dracut package, though), and clevis. Regards, Aron
Bug#1026440: librecad: new upstream release 2.2.0
Package: src:librecad Severity: wishlist Upstream has tagged 2.2.0 during the last weekend, please have a look when it is convenient for you. https://github.com/LibreCAD/LibreCAD/releases/tag/2.2.0 Regards, Aron
Bug#1020544: siconos: FTBFS on s390x: Cholesky solve kNM_test failed
Package: siconos Version: 4.4.0+dfsg-1 Severity: important The new version FTBFS on s390x in test suite 23, relevant log entry: > Cholesky solve preserving matrix > Cholesky solve kNM_test: ./numerics/src/tools/NumericsMatrix.c:3023: NM_csc: > > Assertion `A->matrix2->csc->m == A->size0 && "inconsistent size Full build log is https://buildd.debian.org/status/fetch.php?pkg=siconos=s390x=4.4.0%2Bdfsg-1=1663797112=0 Regards, Aron
Bug#1018814: exif: update for null ptr fixes
Package: exif
Severity: wishlist
I have prepared an update for exif package to address two null pointer issues,
changes have been submitted as an MR on salsa, also see the debdiff in
attachement.
Regards,
Aron Xu
diff -Nru exif-0.6.22/debian/changelog exif-0.6.22/debian/changelog
--- exif-0.6.22/debian/changelog2020-07-09 10:58:17.0 +
+++ exif-0.6.22/debian/changelog2022-08-31 07:35:27.0 +
@@ -1,3 +1,11 @@
+exif (0.6.22-3) unstable; urgency=medium
+
+ * Add patch for NULL Pointer Deference when printing out XML formatted
+EXIF data (CVE-2021-27815)
+ * Add patch for NullPointer in strncpy() in Action.c
+
+ -- Aron Xu Wed, 31 Aug 2022 07:35:27 +
+
exif (0.6.22-2) unstable; urgency=medium
* Add upstream patch to fix test failures on big endian systems
diff -Nru
exif-0.6.22/debian/patches/0001-added-empty-strign-check-which-would-lead-to-NULL-pt.patch
exif-0.6.22/debian/patches/0001-added-empty-strign-check-which-would-lead-to-NULL-pt.patch
---
exif-0.6.22/debian/patches/0001-added-empty-strign-check-which-would-lead-to-NULL-pt.patch
1970-01-01 00:00:00.0 +
+++
exif-0.6.22/debian/patches/0001-added-empty-strign-check-which-would-lead-to-NULL-pt.patch
2022-08-31 07:26:54.0 +
@@ -0,0 +1,27 @@
+From f6334d9d32437ef13dc902f0a88a2be0063d9d1c Mon Sep 17 00:00:00 2001
+From: Marcus Meissner
+Date: Thu, 25 Feb 2021 08:31:53 +0100
+Subject: [PATCH 01/25] added empty strign check, which would lead to NULL ptr
+ deref/crash in exif XML display. fixes
+ https://github.com/libexif/exif/issues/4
+
+---
+ exif/actions.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/exif/actions.c b/exif/actions.c
+index ed245df..123c064 100644
+--- a/exif/actions.c
b/exif/actions.c
+@@ -661,6 +661,8 @@ escape_xml(const char *text)
+ char *out;
+ size_t len;
+
++ if (!strlen(text)) return "empty string";
++
+ for (out=escaped, len=0; *text; ++len, ++out, ++text) {
+ /* Make sure there's plenty of room for a quoted character */
+ if ((len + 8) > escaped_size) {
+--
+2.30.2
+
diff -Nru
exif-0.6.22/debian/patches/0002-actually-return-empty-stringand-not-em-pty-string-as.patch
exif-0.6.22/debian/patches/0002-actually-return-empty-stringand-not-em-pty-string-as.patch
---
exif-0.6.22/debian/patches/0002-actually-return-empty-stringand-not-em-pty-string-as.patch
1970-01-01 00:00:00.0 +
+++
exif-0.6.22/debian/patches/0002-actually-return-empty-stringand-not-em-pty-string-as.patch
2022-08-31 07:27:02.0 +
@@ -0,0 +1,26 @@
+From eb84b0e3c5f2a86013b6fcfb800d187896a648fa Mon Sep 17 00:00:00 2001
+From: Marcus Meissner
+Date: Thu, 25 Feb 2021 09:45:36 +0100
+Subject: [PATCH 02/25] actually return empty stringand not 'em,pty string' as
+ expected
+
+---
+ exif/actions.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/exif/actions.c b/exif/actions.c
+index 123c064..4fade01 100644
+--- a/exif/actions.c
b/exif/actions.c
+@@ -661,7 +661,7 @@ escape_xml(const char *text)
+ char *out;
+ size_t len;
+
+- if (!strlen(text)) return "empty string";
++ if (!strlen(text)) return "";
+
+ for (out=escaped, len=0; *text; ++len, ++out, ++text) {
+ /* Make sure there's plenty of room for a quoted character */
+--
+2.30.2
+
diff -Nru exif-0.6.22/debian/patches/0003-avoid-NULL-ptr-crash.patch
exif-0.6.22/debian/patches/0003-avoid-NULL-ptr-crash.patch
--- exif-0.6.22/debian/patches/0003-avoid-NULL-ptr-crash.patch 1970-01-01
00:00:00.0 +
+++ exif-0.6.22/debian/patches/0003-avoid-NULL-ptr-crash.patch 2022-08-31
07:28:52.0 +
@@ -0,0 +1,31 @@
+From a702ad911f7c9824979a6534d87dfb1ec9928533 Mon Sep 17 00:00:00 2001
+From: Marcus Meissner
+Date: Wed, 18 Aug 2021 14:53:24 +0200
+Subject: [PATCH 20/25] avoid NULL ptr crash fixes
+ https://github.com/libexif/exif/issues/5
+
+---
+ exif/actions.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/exif/actions.c b/exif/actions.c
+index 4fade01..d7ab870 100644
+--- a/exif/actions.c
b/exif/actions.c
+@@ -715,7 +715,12 @@ show_entry_xml (ExifEntry *e, void *data)
+ fprintf (stdout, "%s", escape_xml(exif_entry_get_value (e, v,
sizeof (v;
+ fprintf (stdout, "", e->tag);
+ } else {
+- strncpy (t, exif_tag_get_title_in_ifd(e->tag,
exif_entry_get_ifd(e)), sizeof (t));
++ const char *title = exif_tag_get_title_in_ifd(e->tag,
exif_entry_get_ifd(e));
++ if (!title) {
++ /* might just be an unknown tag */
++ return;
++ }
++ strncpy (t, title, sizeof (t));
+ t[sizeof(t)-1] = 0;
+
+ /* Remove invalid characters from tag eg. (, ), space */
+--
+2.30.2
+
diff -Nru exif-0.6.22/debian/patches/s
Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.
Hi, On Sat, Jun 18, 2022 at 12:43 AM Lance Lin wrote: > > Package: wnpp > Severity: wishlist > Owner: Lance Lin > X-Debbugs-Cc: debian-de...@lists.debian.org, lqi...@protonmail.com > > * Package name: libBabaSSL > Version : 8.3.1 > Upstream Author : Copyright (c) 2020-2022 Alibaba Digital Economy > * URL : https://github.com/BabaSSL/BabaSSL > * License : Apache 2.0 > Programming Lang: C > Description : BabaSSL is a base library for modern cryptography and > communication security protocols. > > - BabaSSL is a modern cryptographic and secure protocol library developed by > the amazing people in Alibaba Digital Economy. > - BabaSSL provides the following major features: > -Support RFC 8998, Chinese SM cipher suites in TLS 1.3 protocol > -Support NTLS (formal GM dual-certificate protocol) handshake processing, > according to GB/T 38636-2020 TLCP > -QUIC API support > -Support delegated credentials, according to draft-ietf-tls-subcerts-10 > > I plan to package and maintain BabaSSL myself. > AFAIK this library is forked from OpenSSL with some extensive modifications to support new crypto technologies, do you think we need to involve the Security Team to review whether this package can be supported during the next stable release cycle? Also this project has a planned rename, and I'm a bit concerned this could cause some maintenance burden if the rename is not well coordinated at the time we accept it into Debian. Regards, Aron
Bug#1012305: [Pkg-zfsonlinux-devel] Bug#1012305: zfsutils-linux: tried to instal zfsutils-linux on 2 systems, it fails to compile the module on both.
Hi, On Fri, Jun 3, 2022 at 6:21 PM Andrei wrote: > > Package: zfsutils-linux > Version: 2.0.3-9 > Severity: important > X-Debbugs-Cc: andrei.horn...@ist.ac.at > > Dear Maintainer, > > I recently tried to install zfsutils-linux on 2 separate Debian11.2 desktop > installation. Initially it was a test instance on my main system, which I > dual- > booted with the previous system. The initial ubuntu install has zfs installed > and working. The installation of zfsutils-linux on the debian 11 install > failed > at the modules, just like now. This attempts was several months ago. > > I tried again today on my laptop that also is running Debian 11 desktop just > to > see if it was fixed. It also failed to install and failed to compile the > modules. > I have tried this again with an up-to-date bullseye VM and it worked fine. > The relevant section is: > Setting up zfs-dkms (2.0.3-9) ... > Removing old zfs-2.0.3 DKMS files... > > -- > Deleting module version: 2.0.3 > completely from the DKMS tree. > -- > Done. > Loading new zfs-2.0.3 DKMS files... > Building for 5.10.0-14-amd64 > Building initial module for 5.10.0-14-amd64 > grep: /lib/modules/5.10.0-14-amd64/build/include/linux/miscdevice.h: No such > file or directory Missing this file means that you don't have the proper header package installed, would you mind double checking whether you have linux-headers-5.10.0-14-common installed? Regards, Aron
Bug#991373:
Hi, The dependency about libpython3-stdlib looks like the following: python3-distutils | libpython3-stdlib (<< 3.6.4) So either python3-distutils or libpython3-stdlib (<< 3.6.4) can satisfy this dependency, and also python3-distutils is preferred. Regards, Aron
Bug#995014: [Pkg-zfsonlinux-devel] Bug#995014: linux/linux-signe-* break zfs-linux autopkgtest: None of the expected "capability" interfaces were detected
Control: forwarded -1 https://github.com/openzfs/zfs/issues/12590 I've reported this problem upstream, let's wait for their response. Regards, Aron
Bug#990871: zfs-linux: periodic-trim should deal with SATA SSD with protocol > 3.0
Package: src:zfs-linux Version: 2.0.3-3 Severity: normal periodic-trim's current behavior only deals with NVMe-only pools, to be more clear this means all SSDs in the pool are using NVMe protocol. This is not sufficient since there are many new SATA SSDs that come with protocol version > 3.0. For reference: === START OF INFORMATION SECTION === Model Family: Sandisk SATA Cloudspeed Max and GEN2 ESS SSDs Device Model: SDLF1CRR-019T-1HA1 Serial Number: A028D942 LU WWN Device Id: 5 001173 101148678 Firmware Version: ZR11RPA1 User Capacity: 1,920,383,410,176 bytes [1.92 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Jul 10 13:08:52 2021 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF INFORMATION SECTION === Device Model: Samsung SSD 870 QVO 8TB Serial Number: S5SSNF0R400589B LU WWN Device Id: 5 002538 f4147f25e Firmware Version: SVQ01B6Q User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5 SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Jul 10 13:06:12 2021 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled
Bug#989373:
Control: severity -1 important I'm downgrading this bug to important temporarily to avoid this package to be removed from bullseye. Since we are late in the release freeze, we cannot guarantee the fix to land in time for bullseye, but if that fails let's push a fix in -updates as soon as the release comes out. Regards, Aron
Bug#989900: ITP: dnf-plugins-core -- Core plugins for DNF, the Dandified Yum package manager
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dnf-plugins-core Version : 4.0.21 Upstream Author : DNF-PLUGINS-CORE authors and contributors * URL : https://github.com/rpm-software-management * License : GPL-2+ Programming Lang: Python Description : This package enhances DNF with builddep, config-manager, copr, debug, debuginfo-install, download, needs-restarting, groups-manager, repoclosure, repograph, repomanage, reposync, changelog and repodiff commands. . Additionally provides generate_completion_cache passive plugin. Note, the initial purpose of packaging these dnf plugins are not meant to make dnf more useful to install RPM packages on Debian, but rather it enables the downloading and mirroring of Yum repositories on Debian based systems.
Bug#986301: [Pkg-zfsonlinux-devel] Bug#986301: README.Debian: zfs-initramfs is stable now
Hi, On Sat, Apr 3, 2021 at 1:03 AM наб wrote: > > Source: zfs-linux > Version: 2.0.3-4 > Severity: normal > > Dear Maintainer, > > d/README.Debian says this: > -- >8 -- > 2. Use zfs-initramfs with caution. > -- > > Debian Installer's root installation support is being worked on, > and zfs-initramfs is included here but still needs to be tested > in detail. Since faulty operation on filesystem can lead to major > loss of data, please use zfs-initramfs with caution. > > -- Aron Xu Sat, 3 Aug 2013 03:23:11 +0800 > -- >8 -- > > d-i doesn't support root-on-ZFS installations (and I doubt it ever > will, considering the licensing), but that's beside the point: > zfs-initramfs is stable now (i.e. 2.0.x and forward, after I got my > hands on it, though even in 8.4.x it wasn't /too/ bad), > as is zfs-dracut. > > It's probably best to remove outdated information like this. > Although it's supporting many use cases very well, I still want to keep this warning for Debian, well maybe the wording could be updated slightly to be not so scary - when the installer cannot help users create a proper pool and dataset layout, users who're not very experienced with ZFS might get bitten by the set up. Cheers, Aron
Bug#985590: (pre-approval) unblock: zfs-linux/2.0.3-2
Hi, On Tue, Mar 30, 2021 at 4:17 AM Paul Gevers wrote: > [...] > > > 3. Add new debconf questions, for the cron jobs of pool scrub and trim, with > >translation updates from debian-i18n people. > > But here, I think there's a serious issue. You seem to be querying the > debconf database during cron jobs, but debconf is not a registry. This > is not acceptable. Lintian warns about this too: > https://lintian.debian.org/tags/debconf-is-not-a-registry.html > > I suggest you prepare an upload with 1 and 2. I don't feel comfortable > with 3, even if you fix the debconf-is-not-a-registry issue. > I have reverted 3, and attached is the new debdiff. Thanks for the comments! Cheers, Aron zfs-linux_2.0.3-2.debdiff.gz Description: application/gzip
Bug#985590: (pre-approval) unblock: zfs-linux/2.0.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please pre-approve unblock package zfs-linux/2.0.3-2. This revision is mainly consisted of the following enhancements: 1. Cherry-pick of upstream changes after 2.0.3, which is a subset of 2.0.4 with irrelevant linux 5.12 compat and other stuff removed, making it a pure bug fix update; 2. Fixed update failure from buster-bpo (#983401); 3. Add new debconf questions, for the cron jobs of pool scrub and trim, with translation updates from debian-i18n people. Regards, Aron Xu zfs-linux_2.0.3-2.debdiff.gz Description: application/gzip signature.asc Description: PGP signature
Bug#946497: [Pkg-zfsonlinux-devel] Bug#946497: zfs-dkms: module wants to build with gcc instead of kernel's compiler
Control: severity -1 important On Tue, Mar 9, 2021 at 6:51 PM Andreas Beckmann wrote: > > Followup-For: Bug #946497 > Control: severity -1 serious > > Please depend on gcc if you cannot find a way to use the kernel > compiler. You cannot expect build-essential to be available. > Depending directly on gcc or build-essential will not actually resolve the issue, sometimes it works coincidentally when kernel gcc is the same as default gcc, which isn't guaranteed by the kernel team's design. This is true for almost all dkms packages, and you might want to raise this issue to the dkms package and kernel team one more time. Regards, Aron
Bug#983086: [Pkg-zfsonlinux-devel] Bug#983086: zfsutils-linux: TRIM crashes SSD drives
Hi, On Fri, Feb 19, 2021 at 4:45 PM Xavier wrote: > > Package: zfsutils-linux > Version: 0.8.6-1~bpo10+1 > Severity: important > > Dear Maintainer, > > The recently added cron "TRIM the first Sunday of every month" makes some SSD > drives crash. > > The problem appears on reasonnably busy and otherwise stable servers: >* with about 100 containers, >* each on a separate zvol, ext4 mounted with discard option, >* on a 6 identical drives raidz2. > > The issue has been observed on these drives: >* Micron_5100_MTFDDAK960TCB >* Samsung_SSD_850_EVO_1TB >* Samsung_SSD_860_EVO_1TB > I'm particularly interested in the protocol used by these disks, I suspect all of them are equipped with SATA 2.x/3.0? Prior to SATA 3.1, TRIM command is considered blocking (non-queued) and this might be the root cause of crashing your workload in a busy environment. In other words, actively trimming on SATA 2.x/3.0 disks could be considered harmful to the operational status of heavy workloads even though the disks are enterprise graded with superfluous IOPS capacity. > When affected (it not always the case), the systems could not complete the > cancelling of the trim with: > # zpool trim -c pool > Testing trim on one drive only, and reducing the rate to as low as 50, > did not help. > > A reset seems the only solution, followed by a zpool trim -c after reboot. > > It would be wise to deactivate that cron by default, or at least to provide > some kind of convenient way to do so, like an option in /etc/default/zfs. > Thanks for this advice and we'll have a look on how to get something landed for bullseye and buster-bpo. Regards, Aron
Bug#983298: unblock: ocserv/1.1.2-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Dear release team,
This is a pre-approval request that please unblock package ocserv/1.1.2-2, which
is a version with cherry picked upstream bug fixes.
unblock ocserv/1.1.2-2
Regards,
Aron
diff -Nru ocserv-1.1.2/debian/changelog ocserv-1.1.2/debian/changelog
--- ocserv-1.1.2/debian/changelog 2020-12-17 18:38:57.0 +0800
+++ ocserv-1.1.2/debian/changelog 2021-02-22 11:37:07.0 +0800
@@ -1,3 +1,9 @@
+ocserv (1.1.2-2) unstable; urgency=medium
+
+ * d/patches: cherry-pick upstream post 1.1.2 bug fixes
+
+ -- Aron Xu Mon, 22 Feb 2021 11:37:07 +0800
+
ocserv (1.1.2-1) unstable; urgency=medium
* New upstream version 1.1.2
diff -Nru
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
---
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
1970-01-01 08:00:00.0 +0800
+++
ocserv-1.1.2/debian/patches/0009-update_auth_time_stats-cast-operations-to-avoid-over.patch
2021-02-22 11:33:03.0 +0800
@@ -0,0 +1,27 @@
+From e035221030f8fdfbb38483889631916fef9d9798 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos
+Date: Wed, 9 Dec 2020 15:05:24 +0100
+Subject: [PATCH 09/36] update_auth_time_stats: cast operations to avoid
+ overflows
+
+Signed-off-by: Nikos Mavrogiannopoulos
+---
+ src/sec-mod-auth.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/sec-mod-auth.c b/src/sec-mod-auth.c
+index c769643c..b4b2f3fd 100644
+--- a/src/sec-mod-auth.c
b/src/sec-mod-auth.c
+@@ -131,7 +131,7 @@ static void update_auth_time_stats(sec_mod_st * sec,
time_t secs)
+
+ if (secs > sec->max_auth_time)
+ sec->max_auth_time = secs;
+- sec->avg_auth_time =
(sec->avg_auth_time*(sec->total_authentications-1)+secs) /
sec->total_authentications;
++ sec->avg_auth_time =
((uint64_t)sec->avg_auth_time*((uint64_t)(sec->total_authentications-1))+secs)
/ (uint64_t)sec->total_authentications;
+ }
+
+ static
+--
+2.20.1
+
diff -Nru
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
---
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
1970-01-01 08:00:00.0 +0800
+++
ocserv-1.1.2/debian/patches/0020-ocserv-worker-renamed-loop-to-worker_loop.patch
2021-02-22 11:35:22.0 +0800
@@ -0,0 +1,131 @@
+From 47c6638286a694b4d278e01b278f64f9368b3e1a Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos
+Date: Sat, 12 Dec 2020 22:41:50 +0100
+Subject: [PATCH 20/36] ocserv-worker: renamed loop to worker_loop
+
+This avoids warnings and static analyzers complains about
+the libev functions hiding the global 'loop' variable
+
+Signed-off-by: Nikos Mavrogiannopoulos
+---
+ src/worker-vpn.c | 34 +-
+ 1 file changed, 17 insertions(+), 17 deletions(-)
+
+Index: ocserv/src/worker-vpn.c
+===
+--- ocserv.orig/src/worker-vpn.c
ocserv/src/worker-vpn.c
+@@ -95,7 +95,7 @@ struct worker_st *global_ws = NULL;
+ static int terminate = 0;
+ static int terminate_reason = REASON_SERVER_DISCONNECT;
+
+-static struct ev_loop *loop = NULL;
++static struct ev_loop *worker_loop = NULL;
+ ev_io command_watcher;
+ ev_io tls_watcher;
+ ev_io tun_watcher;
+@@ -433,8 +433,8 @@ static int setup_dtls_connection(struct
+ dtls->dtls_session = session;
+ ev_init(>io, dtls_watcher_cb);
+ ev_io_set(>io, dtls->dtls_tptr.fd, EV_READ);
+- ev_io_start(loop, >io);
+- ev_invoke(loop, >io, EV_READ);
++ ev_io_start(worker_loop, >io);
++ ev_invoke(worker_loop, >io, EV_READ);
+
+ return 0;
+ fail:
+@@ -2609,7 +2609,7 @@ static int test_for_tcp_health_probe(str
+
+ static void syserr_cb (const char *msg)
+ {
+- struct worker_st * ws = ev_userdata(loop);
++ struct worker_st * ws = ev_userdata(worker_loop);
+ int err = errno;
+
+ oclog(ws, LOG_ERR, "libev fatal error: %s / %s", msg, strerror(err));
+@@ -2637,7 +2637,7 @@ static void cstp_send_terminate(struct w
+
+ static void command_watcher_cb (EV_P_ ev_io *w, int revents)
+ {
+- struct worker_st *ws = ev_userdata(loop);
++ struct worker_st *ws = ev_userdata(worker_loop);
+
+ int ret = handle_commands_from_main(ws);
+ if (ret == ERR_NO_CMD_FD) {
+@@ -2723,7 +2723,7 @@ static void invoke_dtls_if_needed(struct
+ if ((dtls->udp_state > UP_WAIT_FD) &&
+ (dtls->dtls_session != NULL) &&
+ (gnutls_record_check_pending(dtls->dtls_session))) {
+- ev_invoke(loop, &g
Bug#978979: RM: gmlive -- RoQA; Orphaned; Upstream Dead; Affected by unversioned py2 removal
On Sat, Jan 2, 2021 at 12:39 AM Boyuan Yang wrote: > > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-CC: a...@debian.org > > Dear Debian FTP Masters, > > Package gmlive ( https://tracker.debian.org/pkg/gmlive ) is orphaned > since 2015, received no update since 2011 and has a dead upstream for 8 > years. It is affected by unversioned python (python2) removal. There > are bunches of alternatives available as the frontend of mplayer so > removing the package won't cause a loss to Debian's functionality. > Besides, its popcon value is also low (65). > > As a result, please consider removing this package from Debian archive > (sid). Thanks! > Thanks Boyuan for bringing this up, please go ahead and remove this package. Regards, Aron
Bug#978502: ITP: astunparse -- AST unparser for Python
Package: wnpp Severity: wishlist * Package name: astunparse Version : 1.6.3 Upstream Author : Simon Percivall * URL : https://github.com/simonpercivall/astunparse * License : BSD-3-Clause and PFSL Programming Lang: Python Description : AST unparser for Python
Bug#978501: ITP: easydict -- Javascript-like properties dot notation for python dicts
Package: wnpp Severity: wishlist * Package name: easydict Version : 1.9 Upstream Author : Mathieu Leplatre * URL : https://github.com/makinacorpus/easydict * License : LGPL-3 Programming Lang: Python Description : Javascript-like properties dot notation for python dicts
Bug#977952: libgoogle-glog-dev: please ship cmake support
Package: libgoogle-glog-dev Version: 0.4.0-1 Severity: wishlist google-glog comes with cmake support upstream, but it's not built when the package is built using autotools (which is preferred by dh sequence over cmake). While I tried to build google-glog with cmake, it appears that pkg-config file is not present in this way. Regards, Aron
Bug#977656: [Pkg-zfsonlinux-devel] Bug#977656: zfs-dkms: Fail to build with 5.10 kernel with "error: ‘struct percpu_ref’ has no member named ‘count’"
Hi Christian, On Fri, Dec 18, 2020 at 6:12 PM Christian Marillat wrote: > > Package: zfs-dkms > Version: 0.8.6-1 > Severity: normal > > Dear Maintainer, > > This commit fix various issues with kernel 5.10 > > https://github.com/openzfs/zfs/pull/11085/commits > Thanks for pointing this out, let's wait a few more days until this version migrates to testing since stable-bpo people have been sitting around for a version supporting 5.9 for a long while. At the moment, we are working on an initial upload of 2.x release to experimental, I think all of these stuff will be able to land next week. Regards, Aron
Bug#970845: ITP: opengauss-server -- high multi-core performance relational DBMS
Package: wnpp Severity: wishlist * Package name: opengauss-server * Version : 1.0.0 * URL : https://gitee.com/opengauss/openGauss-server * License : Mulan PSL v2 * Programming Lang: C++ * Description : openGauss provides high multi-core performance, full link security, intelligent operation and maintenance for enterprise features. Originated from PostgreSQL-XC a few years ago, it comes with improved architecture, transaction, storage engine, optimizer as well as special enhancements on aarch64 hardware. Regards, Aron
Bug#969583: RM: tcpcopy -- RoQA; unmaintained, RC-buggy
On Sat, Sep 5, 2020 at 9:30 PM Sebastian Ramacher wrote: > > Package: ftp.debian.org > Severity: normal > > Please consider removal of tcpcopy from unstable. It is currently > unmaintained and RC-buggy (#835591, #952570). > I am the initial package maintainer of tcpcopy who later orphaned it, and I think it's a good idea to remove it from the archive since nobody else is actually interested in taking it over. Regards, Aron Xu
Bug#969135: ITP: ttf-deepin-opensymbol -- Allows you to seamlessly transit from Wingdings to Deepin OpenSymbol
Hi, On Fri, Aug 28, 2020 at 10:03 AM stan clay wrote: > > Package: wnpp > Severity: wishlist > Owner: Hu Feng > X-Debbugs-Cc: debian-de...@lists.debian.org > > > * Package name: ttf-deepin-opensymbol > Version : 1.360 > Upstream Author : leaeasy > * URL : https://github.com/linuxdeepin/deepin-opensymbol-fonts > License : Apache-2.0 Would you mind to clarify the license? The license file inside the github repository says those fonts are under "Deepin OpenSymbol Public License" while here you say it is Apache-2.0. Regards, Aron
Bug#965264: fcitx: cannot switch to Chinese pinyin input by pressing Ctrl+space
Hi, Would you mind to attach the output of `fcitx-diagnose` command? Best, Aron
Bug#962369: ocserv: Please consider packaging new upstream release (1.0.1)
On Sun, Jun 7, 2020 at 6:21 AM Boyuan Yang wrote: > > Source: ocserv > Version: 0.12.6-1 > X-Debbugs-CC: mtmil...@debian.org > > Dear Debian ocserv maintainers, > > The ocserv upstream seems to have released the 1.0.x versions of > ocserv. The latest release is ocserv 1.0.1, tagged back in 2020-04-09. > > Please consider packaging the new release. Thanks! > I'm waiting for upstream's opinion on which tarball to use. They have some issues using the infra at ftp.infradead.org for unspecified reasons. Regards, Aron Xu
Bug#962644: ITP: ukui-wallpapers -- Wallpapers for UKUI desktop environment
On Thu, Jun 11, 2020 at 1:57 PM Kevin Duan wrote: > > Package: wnpp > Severity: wishlist > Owner: Kevin Duan > > * Package name: ukui-wallpapers > Version : 20.04.2 > Upstream Author : handsome_feng > * URL : https://github.com/ukui/ukui-wallpapers > * License : (GPL) > Programming Lang: (Python) > Description : Wallpapers for UKUI desktop environment > If I'm recalling correctly, the license should be CC-BY-SA-3.0? Regards, Aron Xu
Bug#960986: RFS: fortune-zh/2.96 [ITA] -- Chinese Data files for fortune
On Wed, May 20, 2020 at 11:27 AM atzlinux 肖盛文 wrote: > > IMHO, do some "house keeping work" like ITA(if ITA is a truely house > keeping work as your point of view ), is a good beginning for a new man. > > But how many ITA packages is fit for a new man? 5,10,20 ? I'm not very > sure this. > > So, I don't think that show my ITA packages number in email is the > aggressive. Any body can do more ITA work. > By saying housekeeping, it means doing works that does not change the package behavior that would affect the user experience. For example changing the DH compat and fix lintian warnings by updating the packaging. These works are friendly to new comers, but people are not encouraged to adopt the package if main intention is updating these stuff. Adopting packages usually requires more dedication than slightly updating the packaging, rather you will need to invest more time on keeping it in good shape in the long run. By adopting them you become the maintainer and you have the ultimate responsibility to the quality of that package in Debian. Regards, Aron
Bug#960986: RFS: fortune-zh/2.96 [ITA] -- Chinese Data files for fortune
On Wed, May 20, 2020 at 2:00 AM atzlinux 肖盛文 wrote: > > Hi, > > I uploaded 15 packages untill today.[1] > Well my main concern is that the number of packages you have ITA'd doesn't contribute positively to a rushing NM application, so you don't have to emphasis on how many packages you have uploaded in a month, you contributions are really appreciated. But since you are targeting to become an uploading Debian Developer, doing a lot of house keeping work isn't an efficient way because you might not get the idea that Debian upload rights cannot be granted overnight. I understand an official status at a top-level open source project could drastically change some real life conditions but please don't be so aggressive which might be harming it in the other way, ;) Regards, Aron
Bug#960986: RFS: fortune-zh/2.96 [ITA] -- Chinese Data files for fortune
On Tue, May 19, 2020 at 9:18 PM Mo Zhou wrote: > > Hi atzlinux, > > I appreciate your work on the Chinese-related packages, but only when > people try to do something other than repetitive householding works will > they gain further knowledge and skills. This way is inevitable if you > really want to become a DD, since you have to first prove your expertise > to the advocators. > > When you gained enough experience in debian development, you will > discover that some packages without householding for years are still in > good shape. Besides, the package uploading tally is not strictly > proportional to ones expertise and influence within this community. > > Just two tips for you as you have opened an AM process. > Also, the Debian Chinese Team is an umbrella project we founded a few years ago to be home of those Chinese related, but less interested packages. Interest of taking care of those packages is appreciated but maintainer ship does not contribute positively to a rushing NM application, we prefer concrete and sincere adopters who are carrying out the actual day-to-day maintenance . Regards, Aron
Bug#958314: mirror submission for mirrors.bfsu.edu.cn
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirrors.bfsu.edu.cn Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Aron Xu Country: CN China Location: Beijing Sponsor: Beijing Foreign Studies University http://global.bfsu.edu.cn Trace Url: http://mirrors.bfsu.edu.cn/debian/project/trace/ Trace Url: http://mirrors.bfsu.edu.cn/debian/project/trace/ftp-master.debian.org Trace Url: http://mirrors.bfsu.edu.cn/debian/project/trace/mirrors.bfsu.edu.cn
Bug#956195: buster-pu: package cloud-init/18.3-6+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: debian-cl...@lists.debian.org Dear release team, As discussed in #947351, this is a more targeted fix prepared for buster-pu. The updated debdiff is attached. Regards, Aron cloud-init_18.3-6+deb10u1.debdiff Description: Binary data
Bug#947351: package cloud-init
Control: retitile -1 buster-pu: package cloud-init/18.3-6+deb10u1 Control: tags + patch Hi, After a brief discussion with zigo@d.o I'm trying to prepare a stable-pu update of cloud-init to address Bug #936030. I'm reusing the previous release.d.o bug report for 18.3-6 which wasn't closed, please let me know if opening a new one is preferred. Regards, Aron cloud-init_18.3-6+deb10u1.debdiff Description: Binary data
Bug#955535: Bug #955535: httping: flaky autopkgtest: PING google.com:80
Hi, The two different results are caused by different CI workers - some of our workers at ci.d.n does not have reliable network to public services, in this case to google.com:80, which makes the test result flaky. Would you mind to consider setting up something locally (a small web server) in testing environment to facilitate this test? If that's okay I can help to cook a patch. Regards, Aron
Bug#671827: Bug #671827 libcurl3-gnutls: git over HTTPS hangs if behind a proxy
Control: found -1 curl/7.64.0-4+deb10u1 I think this upstream pull request is relevant: https://github.com/curl/curl/pull/3148 It's not related to NTLM authentication but because some HTTP proxies converted chunked response body unchunked without Content-Length header. Sometimes it is quite hard for users to ask their IT to change the proxy's behavior, so a popular workaround to this problem is to recompile src:git to link with the openssl version of libcurl. Not sure whether Debian is happy to talk with upstream again about the problem or just carry the proposed patch on our own. Cheers, Aron
Bug#953346: open-vm-tools: consider raise process priority of vmtoolsd
On Mon, Mar 9, 2020 at 2:23 AM Bernd Zeimetz wrote: > > Hi Aron, > > which nice level do you suggest? -10? > I'd suggest -20, since vmtoolsd does not consume a lot resources itself while the highest priority would give it better chance to deal with watchdog stuff. Regards, Aron
Bug#953346: open-vm-tools: consider raise process priority of vmtoolsd
Package: open-vm-tools Severity: wishlist I've been experiencing false alarms of VM monitoring for those who runs very CPU intensive tasks for long time (i.e. several hours), and it seems that raising the process priority of vmtoolsd will let the watchdog work more properly. This has relaxed the situation for several VMs at my site so I think it might be worth proposing. Cheers, Aron
Bug#951079: [Pkg-zfsonlinux-devel] Bug#951079: zfs-dkms: Uses only single core during compile
Hi, I'm curious about which version of dkms package do you have? The build process itself is parallel by default since dkms/2.2.0.3-4. It would take a lot of time at configure stage because versions prior to zfs-linux/0.8.3-1 suffer from the non-parallel KABI check, and if you have plenty of cores on the system then it gives an impression that configure takes ages but the actual build finishes in seconds. Regards, Aron
Bug#937321: presage: Python2 removal in sid/bullseye
Hi, I have uploaded the NMU for removing python sub-packages, and we can wait Matteo to see how to deal with the Python porting. Also I've updated the dh compat to 10 so that the build process can proceed with more parallelism. Regards, Aron On Sat, Jan 25, 2020 at 10:33 AM Scott Talbert wrote: > > Hi Matteo, > > I don't know if you saw, but I sent you a merge request[1] to remove the > Python subpackages in presage. They don't have any rdeps and have very > low popcon so it seems reasonable to remove them now (and they can be > added back later when Python 3 support is ready). > > Let me know if you are good with this change. > > Thanks, > Scott > > [1] https://sourceforge.net/p/presage/presage-debian/merge-requests/1/ > > On Tue, 3 Dec 2019, Matteo Vescovi wrote: > > > Hi Scott, > > > > Someone approached me and volunteered to port presage to Python 3 in late > > October, but I haven't heard back since them. > > > > Let me take a look at what kind of an effort it would be to port to python > > 3: that would be my preferred option if I can find the time to do. > > > > Else, the suggestion to remove the python pieces sound like the next best > > thing, if I can't find the time to port to python 3 now, we can then later > > reintroduce the python pieces. > > > > What are the planned timelines for the python 2 removal? > > > > Cheers, > > - Matteo > > > > > > > > > > On Tuesday, 3 December 2019, 05:02:48 CET, Scott Talbert > > wrote: > > > > > > On Mon, 2 Dec 2019, Scott Talbert wrote: > > > > >> Python2 becomes end-of-live upstream, and Debian aims to remove > > >> Python2 from the distribution, as discussed in > > >> https://lists.debian.org/debian-python/2019/07/msg00080.html > > >> > > >> Your package either build-depends, depends on Python2, or uses Python2 > > >> in the autopkg tests. Please stop using Python2, and fix this issue > > >> by one of the following actions. > > > > > > Hi Matteo, > > > > > > Do you plan to port presage to Python 3? If not, I'll probably convert > > this > > > to an RM request as the package seems to be mostly unmaintained and is > > > blocking the removal of Python 2. > > > > Alternatively, perhaps just the Python pieces of presage can be removed, > > as those don't seem to have any rdepends? > > > > Scott > > > >
Bug#938473: Bug #938473: sgmltools-lite: Python2 removal in sid/bullseye
Control: block -1 by 949748 Since sgmltools-lite was last updated on 2016-07-19, and it does not have a big list dependencies, this bug can be closed by removing sgmltools-lite. $ apt rdepends sgmltools-lite sgmltools-lite Reverse Depends: Suggests: lyx Depends: translate-docformat Suggests: sgml2x |Recommends: sgml2x Suggests: sdf Because translate-docformat (Depends) is stable only, removing Recommends status from sgml2x should be sufficient to unblock the process. Regards, Aron
Bug#949748: sgml2x: remove sgmltools-lite from Recommends
Package: sgml2x Severity: normal Version: 1.0.0-11.5 User: debian-pyt...@lists.debian.org Usertags: py2removal Please remove sgmltools-lite from Recommends, because sgmltools-lite is Python 2 only and has no other strong reverse dependencies, so that we are able to remove it to unblock the python2-rm transition. $ apt rdepends sgmltools-lite sgmltools-lite Reverse Depends: Suggests: lyx Depends: translate-docformat Suggests: sgml2x |Recommends: sgml2x Suggests: sdf Regards, Aron
Bug#936882: libjsoncpp: diff for NMU version 1.7.4-3.1
Control: tags 936882 + patch Control: tags 936882 + pending Dear maintainer, I've prepared an NMU for libjsoncpp (versioned as 1.7.4-3.1) and uploaded it since there hasn't been an upload for a long time. Please feel free to revert if there is anything missing. Regards. -- Regards, Aron Xu diff -Nru libjsoncpp-1.7.4/debian/changelog libjsoncpp-1.7.4/debian/changelog --- libjsoncpp-1.7.4/debian/changelog 2016-08-23 09:09:02.0 + +++ libjsoncpp-1.7.4/debian/changelog 2020-01-24 12:32:52.0 + @@ -1,3 +1,10 @@ +libjsoncpp (1.7.4-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Port build system to use Python 3 (Closes: #936882) + + -- Aron Xu Fri, 24 Jan 2020 12:32:52 + + libjsoncpp (1.7.4-3) unstable; urgency=medium * Add patch to fix pkg-config file diff -Nru libjsoncpp-1.7.4/debian/control libjsoncpp-1.7.4/debian/control --- libjsoncpp-1.7.4/debian/control 2016-08-23 09:09:02.0 + +++ libjsoncpp-1.7.4/debian/control 2020-01-24 12:29:56.0 + @@ -3,7 +3,7 @@ Maintainer: Peter Spiess-Knafl Uploaders: Cleto Martín Testsuite: autopkgtest -Build-Depends: cmake, debhelper (>= 9), doxygen, python:any +Build-Depends: cmake, debhelper (>= 9), doxygen, python3:any Standards-Version: 3.9.8 Section: libs Homepage: https://github.com/open-source-parsers/jsoncpp diff -Nru libjsoncpp-1.7.4/debian/patches/port-to-python3.patch libjsoncpp-1.7.4/debian/patches/port-to-python3.patch --- libjsoncpp-1.7.4/debian/patches/port-to-python3.patch 1970-01-01 00:00:00.0 + +++ libjsoncpp-1.7.4/debian/patches/port-to-python3.patch 2020-01-24 12:31:30.0 + @@ -0,0 +1,12 @@ +Index: libjsoncpp-1.7.4/doxybuild.py +=== +--- libjsoncpp-1.7.4.orig/doxybuild.py libjsoncpp-1.7.4/doxybuild.py +@@ -1,7 +1,5 @@ + """Script to generate doxygen documentation. + """ +-from __future__ import print_function +-from __future__ import unicode_literals + from devtools import tarball + from contextlib import contextmanager + import subprocess diff -Nru libjsoncpp-1.7.4/debian/patches/series libjsoncpp-1.7.4/debian/patches/series --- libjsoncpp-1.7.4/debian/patches/series 2016-08-23 09:09:02.0 + +++ libjsoncpp-1.7.4/debian/patches/series 2020-01-24 12:30:19.0 + @@ -1 +1,2 @@ fix-pkgconfig.patch +port-to-python3.patch diff -Nru libjsoncpp-1.7.4/debian/rules libjsoncpp-1.7.4/debian/rules --- libjsoncpp-1.7.4/debian/rules 2016-08-23 09:09:02.0 + +++ libjsoncpp-1.7.4/debian/rules 2020-01-24 12:31:59.0 + @@ -18,7 +18,7 @@ $(CONFIGURE_FLAGS) override_dh_auto_build-indep: - python doxybuild.py --doxygen=/usr/bin/doxygen + python3 doxybuild.py --doxygen=/usr/bin/doxygen override_dh_makeshlibs: dh_makeshlibs -V "libjsoncpp1 (>= 1.7.4)" signature.asc Description: PGP signature
Bug#936129: Bug #936129: apr-util: Python2 removal in sid/bullseye
It looks that src:apr-util does not have python code itself, while it makes use of gen-build.py from libapr1-dev (src:apr). So that once #936128 is closed, apr-util can move to python3 by changing the build-dep. Regards, Aron
Bug#936128: Bug #936128: apr: Python2 removal in sid/bullseye
Control: tags -1 + patches
Please find the attached patch to make apr build with python3. I've also
created a
pull request on salsa repository with the same content:
https://salsa.debian.org/apache-team/apr/merge_requests/2
Regards,
Aron
From 0ba955bab778cdc63530ed1ce0cb1e0cca75d77f Mon Sep 17 00:00:00 2001
From: Aron Xu
Date: Sun, 19 Jan 2020 03:01:46 +
Subject: [PATCH] Add patch to make the package use python3 (Closes: #936128)
---
debian/control | 4 +-
debian/patches/port-to-python3.patch | 63
debian/patches/series| 1 +
3 files changed, 66 insertions(+), 2 deletions(-)
create mode 100644 debian/patches/port-to-python3.patch
diff --git a/debian/control b/debian/control
index 0e97170..6f0cbe5 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: libs
Priority: optional
Maintainer: Debian Apache Maintainers
Uploaders: Stefan Fritsch
-Build-Depends: debhelper (>= 11), autoconf, mawk, uuid-dev, doxygen, netbase, net-tools, libtool (>= 2), python:any, libsctp-dev [linux-any]
+Build-Depends: debhelper (>= 11), autoconf, mawk, uuid-dev, doxygen, netbase, net-tools, libtool (>= 2), python3:any, libsctp-dev [linux-any]
Standards-Version: 4.2.1
Vcs-Browser: https://salsa.debian.org/apache-team/apr
Vcs-Git: https://salsa.debian.org/apache-team/apr.git
@@ -24,7 +24,7 @@ Package: libapr1-dev
Architecture: any
Section: libdevel
Depends: libapr1 (= ${binary:Version}), uuid-dev, ${misc:Depends}, libsctp-dev [linux-any]
-Suggests: python
+Suggests: python3
Conflicts: libapr1.0-dev, libapr0-dev
Description: Apache Portable Runtime Library - Development Headers
APR is Apache's Portable Runtime Library, designed to be a support library
diff --git a/debian/patches/port-to-python3.patch b/debian/patches/port-to-python3.patch
new file mode 100644
index 000..651fd86
--- /dev/null
+++ b/debian/patches/port-to-python3.patch
@@ -0,0 +1,63 @@
+From: Aron Xu
+Date: Sun, 19 Jan 2020 02:59:41 +
+Subject: Port to use Python3
+
+===
+---
+ build/buildcheck.sh | 10 +-
+ build/gen-build.py | 6 +++---
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/build/buildcheck.sh b/build/buildcheck.sh
+index 9fb2b2a..7edc405 100755
+--- a/build/buildcheck.sh
b/build/buildcheck.sh
+@@ -4,15 +4,15 @@ echo "buildconf: checking installation..."
+ res=0
+
+ # any python
+-python=`build/PrintPath python`
++python=`build/PrintPath python3`
+ if test -z "$python"; then
+- echo "buildconf: python not found."
+- echo " You need python installed"
++ echo "buildconf: python3 not found."
++ echo " You need python3 installed"
+ echo " to build APR from SVN."
+ res=1
+ else
+- py_version=`python -c 'import sys; print sys.version' 2>&1|sed 's/ .*//;q'`
+- echo "buildconf: python version $py_version (ok)"
++ py_version=`python3 -c 'import sys; print(sys.version)' 2>&1|sed 's/ .*//;q'`
++ echo "buildconf: python3 version $py_version (ok)"
+ fi
+
+ # autoconf 2.59 or newer
+diff --git a/build/gen-build.py b/build/gen-build.py
+index aa94c33..31ed574 100755
+--- a/build/gen-build.py
b/build/gen-build.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/env python3
+ #
+ # USAGE: gen-build.py TYPE
+ #
+@@ -10,7 +10,7 @@
+
+
+ import os
+-import ConfigParser
++import configparser
+ import getopt
+ import string
+ import glob
+@@ -36,7 +36,7 @@ MAKE_PLATFORMS = [
+
+
+ def main():
+- parser = ConfigParser.ConfigParser()
++ parser = configparser.ConfigParser()
+ parser.read('build.conf')
+
+ if parser.has_option('options', 'dsp'):
diff --git a/debian/patches/series b/debian/patches/series
index d1e5fdc..6631e11 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,3 +10,4 @@ libtoolize_check.patch
debug_testpoll_failure.patch
use_fcntl_locking.patch
cross.patch
+port-to-python3.patch
--
2.20.1
signature.asc
Description: PGP signature
Bug#936030: #936030: /usr/bin/cloud-init: cloud-init 18.3 failed to detect network link type: cascading (datasource: OpenStack)
On Fri, Jan 17, 2020 at 4:30 PM Thomas Goirand wrote: > > On 1/15/20 3:19 PM, Aron Xu wrote: > > Hi, > > > > I've created a pull request for this report: > > https://salsa.debian.org/cloud-team/cloud-init/merge_requests/3 > > > > Huawei Cloud or Huawei Fusion will feed cloud-init with an unusually > > network type called "cascading". This makes the instance provision > > from Debian image fail, and I have reproduced it with our cloud image > > from cdimage.d.o. Although I don't know what it is but treating it as > > "physical" will just work. > > > > The suggested patch does not add support for "cascading" network type, > > but it will treat anything unknown as "physical" network type and let > > the cloud init process continue, rather than fail very early and give > > up the entire provision process because of the failure. > > > > I would propose this patch to be added in a stable update of buster's > > cloud-init package. > > > > Regards, > > Aron > > > > Hi Aron, > > I have merged your patch in the Buster branch, however, the current plan > is to get version 19.3 in Buster as a replacement. Therefore, it makes > little sense right now to ask the release team about this patch, when > we've already asked for approval of version 19.3. FYI, your patch is > already included in version 19.3. Maybe you could test with the version > in Sid? > I have verified that sid version works, and waiting for 19.3 to land in buster works perfectly fine for me. Thanks! Best wishes, Aron
Bug#936030: #936030: /usr/bin/cloud-init: cloud-init 18.3 failed to detect network link type: cascading (datasource: OpenStack)
Hi, I've created a pull request for this report: https://salsa.debian.org/cloud-team/cloud-init/merge_requests/3 Huawei Cloud or Huawei Fusion will feed cloud-init with an unusually network type called "cascading". This makes the instance provision from Debian image fail, and I have reproduced it with our cloud image from cdimage.d.o. Although I don't know what it is but treating it as "physical" will just work. The suggested patch does not add support for "cascading" network type, but it will treat anything unknown as "physical" network type and let the cloud init process continue, rather than fail very early and give up the entire provision process because of the failure. I would propose this patch to be added in a stable update of buster's cloud-init package. Regards, Aron
Bug#894429:
Would like to suggest that even the @tracker.d.o team address can serve as a mini mailing list very well (except I don't see a list archive service), and this is what Kylin Team has done so far - team+kylin@tracker.d.o Regards, Aron
Bug#620754: Bug #620754: dkms should depend on kernel gcc version
Although this is a report long time ago, I would like to clarify the situation: src:linux produces a bunch of image and headers packages, as well as some called linux-compiler-gcc-8-x86, but these packages contain the major version of GCC as well as the architecture names which could be a burden for dkms maintainers to deal with in the long run. Also, linux-compiler-gcc-*-* only exist on x86, arm and s390 platforms and are missing on other ones officially supported by Debian. We rely on the relevant linux-headers-* packages to pull in the real compiler required by the corresponding version of kernel and in theory this dependency on gcc itself could be eliminated. Even worse, there isn’t a universal “linux-headers” package we are able to Depends on to magically make kernel headers available on any machine. But we would like to try to keep things work for most of the common cases without too much trouble for ordinary users, so it is kept in such a situation. Regards, Aron
Bug#942103: tasksel: Move fonts-arphic-* to Suggests for task-chinese-{s,t}-desktop
Package: tasksel
Severity: normal
Tags: patch
Since fonts-arphic-{ukai,uming} have quite unfriendly fontconfig
configurations due to historical reasons, it makes default user
experience confusing, thus lowering them from Recommends to Suggests,
avoiding them from being automatically installed.
These two fonts have embeded bitmap version of characters, making
it becomes very clear on smaller font size of a non-HiDPI display.
But these font face is not so popular nowadays and Noto CJK has
alternative serif font face, so that we would like to shift to the
latter as default.
Regards,
Aron
0001-Move-fonts-arphic-to-Suggests-for-task-chinese-s-t-d.patch
Description: Binary data
Bug#939845:
I tried more to reproduce this bug, the problem only affect linux 4.19.0-0.bpo.4 and 4.19.0-0.bpo.5 (while I haven't tried earlier bpo versions), and does not affect 4.9 or 4.19.0-0.bpo.6 Since the affecting surface is small so far, I would suggest anyone run into this problem on stretch(-bpo) to upgrade to 4.19.0-0.bpo.6, it does not matter whether the kernel is the current running one at the time wireguard.ko is built. Cheers, Aron
Bug#939845:
Appears that I have encountered this problem as well. Running kernel is 4.19.0-0.bpo.4-rt-amd64, which is the only installed kernel, relevant kernel headers are also installed (and are the only headers packages). # dpkg -l 'linux-headers-*' 'linux-image-*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--=-=-= ii linux-headers-4.19.0-0.b 4.19.28-2~bpo9+1 all Common header files for Linux 4.19.0-0.bpo.4-rt ii linux-headers-4.19.0-0.b 4.19.28-2~bpo9+1 amd64 Header files for Linux 4.19.0-0.bpo.4-rt-amd64 ii linux-image-4.19.0-0.bpo 4.19.28-2~bpo9+1 amd64 Linux 4.19 for 64-bit PCs, PREEMPT_RT (signed) # modprobe -v wireguard insmod /lib/modules/4.19.0-0.bpo.4-rt-amd64/updates/dkms/wireguard.ko modprobe: ERROR: could not insert 'wireguard': Exec format error # dmesg | tail -1 [omitted] module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 000 072e61b9a, val c0cb8896
Bug#940512: feature is no longer recommended by Mozilla
Package: sso.debian.org Severity: normal With a Firefox nightly 71.0a1 (2019-09-15), tag does not work for sso.debian.org anymore. After searching a little bit, it appears that Mozilla claims on their website that is no longer recommended[1]. [1]https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen Regards, Aron
Bug#934736: initramfs-tools: MODULES=dep fails when rootfs is zfs
Package: initramfs-tools Version: 0.130 Severity: normal Tags: patch Hi, In hook-funtions, dep_add_modules_mount() wants a real mount point while zfs only presents its mount point as a virtual one named by the underlying dataset in /proc/mounts, this makes the function abort claiming unable to detect the root device. Such behavior breaks the installation of kdump-tools with zfs as rootfs because it explictly generates a new initrd with MODULES=dep. Attached patch makes dep_add_modules_mount() return upon detecting a zfs rootfs. Because users who run zfs as rootfs are required to install zfs-initramfs package, where a lot more details are handled, there is no potential breakage for not handling zfs related kernel modules here. If someday we have built-in support of zfs in initramfs-tools package, this peice of code should be revisted, though. Regards, Aron 0001-hook-funtions-return-from-dep_add_modules_mount-for-.patch Description: Binary data
Bug#898306:
Since spl package in Debian archive is no longer required by spl-dkms, a user can install a fully functional ZFS environment without the package. But I'm going to remove the Conflicts in future updates but it seems not really relevant enough to warrent such a dependency. Regards, Aron
Bug#932251: buster-pu: package spl-linux/0.7.12-2+deb10u1
On Wed, Jul 17, 2019 at 01:41:12AM +, Aron Xu wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Dear release team,
>
> We would like to apply a single-line patch in addition to spl-linux/0.7.12-2
> which fixes a deadlock[1], please see the changes in debdiff.
>
> [1]https://github.com/zfsonlinux/spl/commit/cb4464f1549087794fdbe0f5ad2328618de2033e
>
Please find debdiff in attachment.
diff -Nru spl-linux-0.7.12/debian/changelog spl-linux-0.7.12/debian/changelog
--- spl-linux-0.7.12/debian/changelog 2019-02-19 04:40:38.0 +
+++ spl-linux-0.7.12/debian/changelog 2019-07-17 01:21:03.0 +
@@ -1,3 +1,10 @@
+spl-linux (0.7.12-2+deb10u1) buster; urgency=medium
+
+ * debian/patches:
+- fix deadlock between mm_sem and tx assign in zfs_write() and page fault
+
+ -- Aron Xu Wed, 17 Jul 2019 01:21:03 +
+
spl-linux (0.7.12-2) unstable; urgency=medium
[ Colin Ian King ]
diff -Nru
spl-linux-0.7.12/debian/patches/0006-deadlock-between-mm_sem-and-tx-assign-in-zfs_write-a.patch
spl-linux-0.7.12/debian/patches/0006-deadlock-between-mm_sem-and-tx-assign-in-zfs_write-a.patch
---
spl-linux-0.7.12/debian/patches/0006-deadlock-between-mm_sem-and-tx-assign-in-zfs_write-a.patch
1970-01-01 00:00:00.0 +
+++
spl-linux-0.7.12/debian/patches/0006-deadlock-between-mm_sem-and-tx-assign-in-zfs_write-a.patch
2019-07-17 01:16:28.0 +
@@ -0,0 +1,44 @@
+From cb4464f1549087794fdbe0f5ad2328618de2033e Mon Sep 17 00:00:00 2001
+From: Tony Hutter
+Date: Fri, 18 Jan 2019 10:05:58 -0800
+Subject: [PATCH 1/6] deadlock between mm_sem and tx assign in zfs_write() and
+ page fault
+
+(This is the ported SPL portion of this patch)
+
+The bug time sequence:
+1. thread #1, `zfs_write` assign a txg "n".
+2. In a same process, thread #2, mmap page fault (which means the
+`mm_sem` is hold) occurred, `zfs_dirty_inode` open a txg failed,
+and wait previous txg "n" completed.
+3. thread #1 call `uiomove` to write, however page fault is occurred
+in `uiomove`, which means it need `mm_sem`, but `mm_sem` is hold by
+thread #2, so it stuck and can't complete, then txg "n" will
+not complete.
+
+So thread #1 and thread #2 are deadlocked.
+
+Reviewed-by: Chunwei Chen
+Reviewed-by: Brian Behlendorf
+Reviewed-by: Matthew Ahrens
+Signed-off-by: Grady Wong
+Closes #7939
+---
+ include/sys/uio.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/include/sys/uio.h b/include/sys/uio.h
+index 764beb9..47715db 100644
+--- a/include/sys/uio.h
b/include/sys/uio.h
+@@ -53,6 +53,7 @@ typedef struct uio {
+ int uio_iovcnt;
+ offset_tuio_loffset;
+ uio_seg_t uio_segflg;
++ boolean_t uio_fault_disable;
+ uint16_tuio_fmode;
+ uint16_tuio_extflg;
+ offset_tuio_limit;
+--
+2.11.0
+
diff -Nru spl-linux-0.7.12/debian/patches/series
spl-linux-0.7.12/debian/patches/series
--- spl-linux-0.7.12/debian/patches/series 2019-01-18 14:29:38.0
+
+++ spl-linux-0.7.12/debian/patches/series 2019-07-17 01:18:28.0
+
@@ -3,3 +3,4 @@
0003-Add-check-for-ktime_get_ts64-for-V5.0-ke.patch
0004-Add-check-for-timespec64-sub.patch
0005-Use-64-bit-timespec-fixes.patch
+0006-deadlock-between-mm_sem-and-tx-assign-in-zfs_write-a.patch
signature.asc
Description: PGP signature
Bug#932251: buster-pu: package spl-linux/0.7.12-2+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Dear release team, We would like to apply a single-line patch in addition to spl-linux/0.7.12-2 which fixes a deadlock[1], please see the changes in debdiff. [1]https://github.com/zfsonlinux/spl/commit/cb4464f1549087794fdbe0f5ad2328618de2033e Regards, Aron signature.asc Description: PGP signature
Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]
Hi, I have tested the package in a virtual machine on amd64 for linux/4.19.37-3 (buster) and a locally built updated linux kernel that breaks zfs-linux/0.7.12-2. The dkms package builds fine with both of the versions and zpool create/export/import works fine. Therefore, please unblock the t-p-u update for buster, thanks. Regards, Aron
Bug#926982: unblock: ocserv/0.12.2-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, Please unblock package ocserv It fixes a segfault problem in the worker binary as described in upstream bug tracker: https://gitlab.com/openconnect/ocserv/issues/197 Attached is the debdiff between 0.12.2-2 and 0.12.2-3. unblock ocserv/0.12.2-3 Regards, Aron ocserv_0.12.2-3.debdiff Description: Binary data
Bug#923770: unblock: zfs-linux/0.7.13-1
Hi, Similar to what I have replied for Bug #923769, this is a new upstream bug fix minor point release, and here are some details. In packaging: 1. Rebase 2332-OpenZFS-8898-creating-fs-with-checksum-skein-on-the-.patch A simple patch rebase. 2. Remove linux 4.20 and 5.0 compat fixes. Included in upstream 0.7.13. See # in the following section. 3. Bump Standards-Version to 4.3.0 (no change). 4. Include new example scripts Installs a new example file `etc/zfs/vdev_id.conf.scsi.example' which is left out unintentionally in previous version. Changes in upstream release are here: https://github.com/zfsonlinux/zfs/commits/zfs-0.7-release In more detail: 1. https://github.com/zfsonlinux/zfs/commit/2428fbbfcf7f1b2298e1e4ee054430ca155144cc Non-significant change to use automake to build initramfs scripts and hooks. 2. https://github.com/zfsonlinux/zfs/commit/edb504f9dbeb2921da2eb669ff052e11c8079e9d Minor fix to make initramfs/dracut able to find mount.zfs mount helper when not installed to /sbin 3. https://github.com/zfsonlinux/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a Avoid a deadlock by not creating/removing zfs_dbuf_evict_key tsd values, also improves performance a little bit 4. https://github.com/zfsonlinux/zfs/commit/14a5e48fb92210541ffd04081c313f4d6061a4d9 Replace hard coded command cpp with $CPP, to fix cross-compiling. 5. https://github.com/zfsonlinux/zfs/commit/e3fb781c5fdaaba0ee788a1602490dc9e3a7c7d5 Auto load zfs kernel module when needed. Previous behavior is that, there must be an active zpool to make systemd services to load the kernel module at system boot time, otherwise user must run modprobe themselves before using any zfs/zpool command lines. Auto loading would improve user experience but previously we are conservative. 6. https://github.com/zfsonlinux/zfs/commit/f325d76e962fa569503189797ffdd447114db88c Fix a conflict of marco ZFS_MINOR which interferes with Lustre 7. https://github.com/zfsonlinux/zfs/commit/2b8c3cb0c83681d7425fa5bf567e726b7ba975e9 https://github.com/zfsonlinux/zfs/commit/41f7723e9cb260f313f99d667142e37617812fca https://github.com/zfsonlinux/zfs/commit/89019a846b90f933db13082cdfe7c046dee0a210 Helper shell script, udev rule and man page changes, making `vdev_id' command behave similar with SCSI disks to previously supported SAS disks, also make it generates consistently named links in /dev/by-enclosure/ by adding a `enclosure_symlinks' option to this piece of shell script. 8. https://github.com/zfsonlinux/zfs/commit/7e5def8ae0586d1fb9a27411e529ad1a356795c3 Minor fix in man page examples. 9. https://github.com/zfsonlinux/zfs/commit/b0d579bc55a8536fe6313a7627d52206322d39b9 Only affects contributing commits to the project -- make commit subject length limit bump from 50 to 72 characters. 10. https://github.com/zfsonlinux/zfs/commit/44f463824bc78df2d23dd049c3ef57ddaf464feb Add an option to dkms configuration to empower the user to forcibly enable debuginfo generation at dkms build time. 11. https://github.com/zfsonlinux/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d Deadlock fix, which is useful together with this change in spl-linux: https://github.com/zfsonlinux/spl/commit/cb4464f1549087794fdbe0f5ad2328618de2033e 12. https://github.com/zfsonlinux/zfs/commit/0a3a4d067a40bf3a84fcbe0a4f3869fb1bca8f18 https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730 https://github.com/zfsonlinux/zfs/commit/5c4ec382a76c7c0d6b218fcab5a1c2e035012158 Already cherry-picked in zfs-linux/0.7.12-2 which is now released in upstream tarball. 13. https://github.com/zfsonlinux/zfs/commit/edc2675aed7d05f7ec230874e33c8a20d7402b02 https://github.com/zfsonlinux/zfs/commit/ba8024a2849d347886328a1148d1ed820869a4e2 https://github.com/zfsonlinux/zfs/commit/f45ad7bff6cacb4ca0717a1f6686873136a5aa22 These 4 patches are changes for Linux 5.0 compatibility, and mostly they are conditional applied to higher versions of Linux when detected (most diffs are to m4 and Makefile files to implement such behavior). As spl/zfs are already declared to support up to Linux version 5.0 in debian/linux_compat, we would like to have these compatibility patches applied. 14. https://github.com/zfsonlinux/zfs/commit/2254b2bbbe17a1ad34b016d1605fea49c01461cf Compiler compatibility fix for GCC9.0. Also the command is only used when testing zpool/zfs itself. 15. https://github.com/zfsonlinux/zfs/commit/c32c2f17d06cea5dc298b404fad7696921e490e0 test-runner python3 compatibility. The stuff is only used when running upstream tests. Please unblock zfs-linux/0.7.13-1, thanks. Regards, Aron
