Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar
On Mon, 2022-11-21 at 00:03 +1100, Stuart Prescott wrote: > The error is coming from the invocation of dpkg-deb which runs > ["tar", "-x", "-m", "-f", "-", "--warning=no-timestamp"] > > Do I take it that on your system dpkg-deb exists but is entirely > non-functional because it can't actually work with any archives? Ah, I've just looked into dpkg and it seems to switch to `gtar` invocation if such an executable is present. So it failed only because I haven't rebuilt dpkg after we've switched to installing GNU tar as `gtar`. In this case, there is nothing to be fixed in dpkg and we just need to handle this on Gentoo end. I'm sorry for the false report and thank you for all your guidance. -- Best regards, Michał Górny
Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar
On Mon, 2022-11-21 at 00:03 +1100, Stuart Prescott wrote: > Hi Michał, > > Thanks for the intriguing report. > > The error is coming from the invocation of dpkg-deb which runs > ["tar", "-x", "-m", "-f", "-", "--warning=no-timestamp"] > > Do I take it that on your system dpkg-deb exists but is entirely > non-functional because it can't actually work with any archives? Ah, I didn't even realize I have dpkg installed! I've never used it but if you think it's broken, then it probably is ;-). > If that's the case, I guess the real solution is fixing dpkg-deb. In the > meantime, I'll need to think about how the test can navigate its way > around a broken dpkg-deb being installed — at present, it assumes that > the tools it finds are not broken. Indeed. Should I file a new bug against dpkg, or can you "reassign" this one then? As for python-debian, please don't worry too much about it. This setup with bsdtar is quite experimental, and mostly meant to catch and report potential issues right now. I don't think you have to worry about real users being affected right now. -- Best regards, Michał Górny
Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar
Package: python-debian Version: 0.1.49 When tar(1) executable is a non-GNU implementation of tar (bsdtar from libarchive here), test_control fails trying to pass unsupported `-- warning=no-timestamp` option: ``` === FAILURES === ___ TestDebFile.test_control ___ self = sample_deb = '/tmp/portage/dev-python/python-debian- 0.1.49/temp/test_debfile.cwjvb8xc/test.ar' @pytest.mark.skipif(not _dpkg_deb_path, reason="dpkg-deb not installed") def test_control(self, sample_deb): # type: (str) -> None """ test for control contents equality """ with os.popen("dpkg-deb -f %s" % sample_deb) as dpkg_deb: filecontrol = "".join(dpkg_deb.readlines()) with debfile.DebFile(sample_deb) as deb: ctrl = deb.control.get_content("control") assert ctrl is not None > assert ctrl.decode("utf-8") == filecontrol [... cut long diff between expcected and "" ...] deb= dpkg_deb = filecontrol = '' sample_deb = '/tmp/portage/dev-python/python-debian- 0.1.49/temp/test_debfile.cwjvb8xc/test.ar' self = lib/debian/tests/test_debfile.py:623: AssertionError - Captured stderr call - tar: Option --warning=no-timestamp is not supported Usage: List:tar -tf Extract: tar -xf Create: tar -cf [filenames...] Help:tar --help dpkg-deb: error: tar subprocess returned error exit status 1 ``` This is Gentoo Linux/amd64 with libarchive-3.6.1. GNU tar is available as `gtar` if you really need it. I suspect the same problem applies to *BSD systems. -- Best regards, Michał Górny
Bug#814688: posh: tests/th uses deprecated perl4 'getopts.pl' module that is removed in perl-5.15+
Package: posh Version: 0.12.5 Tags: patch The tests/th Perl script is using perl4-specific 'getopts.pl' module for option parsing. As noted in [1], those modules are no longer included in perl since version 5.15. Therefore, an attempt to run tests results in the following error: ./th-sh ./th -s . -p ../posh -C sh,posix,pdksh,posh,debian,no-history,no-typeset,no-aliases,no-arrays,no-coprocs,no-herestrings,no-ulimit Can't locate getopts.pl in @INC (@INC contains: /etc/perl /usr/local/lib64/perl5/5.22.1/x86_64-linux-thread-multi /usr/local/lib64/perl5/5.22.1 /usr/lib64/perl5/vendor_perl/5.22.1/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.22.1 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl/5.22.0/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.22.0 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.22.1/x86_64-linux-thread-multi /usr/lib64/perl5/5.22.1 .) at ./th line 133. I am attaching a patch that fixes the issue by using the more modern Getopt::Std module that is part of Perl core distribution since perl-5.0. I've tested the resulting patch on Gentoo with perl-5.22.1. [1]:https://metacpan.org/pod/Perl4::CoreLibs -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> From 893b644fc8c840d0a29974c90e0a80f7ce8146ba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= <mgo...@gentoo.org> Date: Sun, 14 Feb 2016 10:21:02 +0100 Subject: [PATCH] tests/th: Update to work with perl-5.15+ The 'getopts.pl' module (dating back to perl4) was finally nuked in perl-5.16+, therefore making it impossible to run tests in posh. Use the perl5 Getopt::Std module instead. --- tests/th | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/th b/tests/th index 72eb812..920d54c 100755 --- a/tests/th +++ b/tests/th @@ -130,7 +130,7 @@ $os = defined $^O ? $^O : 'unknown'; -require 'getopts.pl'; +use Getopt::Std; ($prog = $0) =~ s#.*/##; @@ -200,7 +200,7 @@ $nxpassed = 0; %known_tests = (); -if (!('C:p:Ps:t:ve:')) { +if (!('C:p:Ps:t:ve:')) { print STDERR $Usage; exit 1; } -- 2.7.1 pgpXx09JSgWFQ.pgp Description: OpenPGP digital signature
Bug#642168: RFP: npapi-sdk -- NPAPI headers bundle for building plugins
Package: wnpp Severity: wishlist * Package name: npapi-sdk Version: 0.27 * URL: http://code.google.com/p/npapi-sdk/ https://github.com/mgorny/npapi-sdk/ * License: MPL 1.1/GPL 2.0/LGPL 2.1 NPAPI-SDK is the bundle of NPAPI headers lately decoupled from Mozilla sources. Although the original upstream project is all concerned about bundling live sources, we [Gentoo Mozilla team] are adding a build system, pkg-config file and packaging releases of it. Thanks to that, NPAPI-SDK project becomes a good and tiny alternative to complete Mozilla install for many NPAPI plugins which currently are built against xulrunner or Mozilla. And unlike those, aims to provide versioned API to make handling changes to it less painful. Building against NPAPI-SDK is already supported by icedtea-web and freewrl Mozilla plugins, and we're working on bringing its support to other packages. State of the support can be found in our wiki: - https://github.com/mgorny/npapi-sdk/wiki/NPAPI-SDK-migration We'd really appreciate having our little package supported by Debian as well. -- Best regards, Michał Górny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598236: posh: variable assignments do not affect the env when calling a function
Ping. This is still a case in 0.10. -- Best regards, Michał Górny signature.asc Description: PGP signature
Bug#598236: posh: variable assignments do not affect the env when calling a function
Package: posh Version: 0.6.18 Hello, Consider the following test code: #v+ func() { :; } A=test func echo $A #v- Running that code in strict POSIX mode of bash or dash results in 'test' output. However, running in posh it doesn't output anything. Trying to explain that behavior, I run into bug #485463 which seems to be the reason of it. The reasoning assumed for that patch is unfortunately not true. Quite a good explanation can be found on bug-bash: http://lists.gnu.org/archive/html/bug-bash/2010-08/msg00164.html Thus, I think that the particular change done due to bug #485463 should be reverted and the original behavior should be restored as the one being POSIX compliant. -- Best regards, Michał Górny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org