Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar

2022-11-20 Thread Michał Górny
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

2022-11-20 Thread Michał Górny
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

2022-11-19 Thread Michał Górny
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+

2016-02-14 Thread Michał Górny
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

2011-09-19 Thread Michał Górny
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

2011-08-30 Thread Michał Górny
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

2010-09-27 Thread Michał Górny
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