Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.perl.modules > #209

[OT] reporting bugs

From Ivan Shmakov <oneingray@gmail.com>
Newsgroups comp.lang.perl.modules, comp.lang.perl.misc, alt.barcodes
Subject [OT] reporting bugs
Date 2013-03-30 11:02 +0000
Organization Aioe.org NNTP Server
Message-ID <87d2uh40by.fsf_-_@violet.siamics.net> (permalink)
References <87ehfjmst4.fsf@violet.siamics.net> <u0m61a-t5i1.ln1@anubis.morrow.me.uk> <87txo9j4d5.fsf@violet.siamics.net> <eclk1a-9d21.ln1@anubis.morrow.me.uk>

Cross-posted to 3 groups.

Show all headers | View raw


>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:

	(Thanks for the comments regarding ZBar, BTW.  I'm yet to check
	its sources myself, but I've also discovered that it behaves
	strangely not only for the octets having the most significant
	bit set, but for the "plain old" \x0D = \r just as well.)

[...]

 >>> There is a Perl decoder based on zbar (Barcode::ZBar), though
 >>> presumably it would behave the same as zbarimg.

 >> ... Indeed it does, which made me file Debian Bug#703234 [1].

 > <pet peeve> The correct place to file a bug in a Perl module is in
 > its CPAN bug tracker, or, in this case, in the zbar Sourceforce
 > tracker.

	BTW, there's a longstanding bug filed at the CPAN RT [2] (along
	with a patch.)  However, it appears to be filed against
	libwww-perl, while it actually belongs to Net-HTTP.

	The question is: how do I reassign it?

[2] https://rt.cpan.org/Public/Bug/Display.html?id=29468

 > Filing a bug with some random distro is Not Helpful, since such
 > reports frequently don't find their way upstream.

	Yes.  As long as an ideal world is considered, that is.

	There're a few things to note, however.  The general problems
	with upstream may include:

	* there's effectively no upstream;

	* the code in the distribution may be extensively modified, or
	  improperly built, or be alleged to be; the upstream then may
	  discourage the users of "non-authorized" builds to report bugs
	  directly to them; consider, e. g.:

--cut: http://foo2zjs.rkkda.com/ --
    *** DON'T USE the foo2zjs package from:

    Ubuntu, SUSE, Mandrake/Manrivia, Debian, RedHat, Fedora, Gentoo,
    Xandros, EEE PC, Linpus, MacOSX, or BSD!

    *** Download it here and follow the directions below.
--cut: http://foo2zjs.rkkda.com/ --

	  (or the Joerg Schilling, albeit sufficiently different, case);

	* the issue may indeed be specific to the distribution's build;
	  (naturally, building from the upstream sources for every bug
	  being I report just to check that it wasn't introduced by the
	  packagers is hardly an option.)

	Personally, I tend to prefer either the Debian BTS, or the
	CPAN RT, for these make it possible to file bugs via email,
	/and/ are better compatible with Lynx (which happens to be my
	primary browser) than most of the other BTS currently in use.
	(I'm particularly fond of RT, although the version installed at
	CPAN has certain surprising issue when it comes to the
	compatibility with non-ECMAScript-enabled browsers.)

	Alas, even for the Perl modules, the CPAN RT is not always the
	preferred but tracker.  Consider, e. g.:

--cut: https://rt.cpan.org/Public/Bug/Display.html?id=79999 --
    Please report issues via github at
    https://github.com/gbarr/perl-Convert-ASN1/issues
--cut: https://rt.cpan.org/Public/Bug/Display.html?id=79999 --

	Lastly, given the developer- and user-base of Debian (especially
	if the derivatives are included), I'd not call it "random."
	That being said, I tend to agree that when the D-M in charge
	fails to forward the request to the upstream, the reporter
	generally should try to do it him- or herself.

	(OTOH, even if D-M forwards the request, it may not have the
	desired effect.  Consider, e. g., Debian Bug#691221 [3].)

[3] http://bugs.debian.org/691221

[...]

-- 
FSF associate member #7257	http://hfday.org/

Back to comp.lang.perl.modules | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Imager::QRCode-ing octet sequences vs. zbarimg(1) Ivan Shmakov <oneingray@gmail.com> - 2013-03-13 11:40 +0000
  Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ben Morrow <ben@morrow.me.uk> - 2013-03-13 16:27 +0000
    bytes, English, and prototypes Ivan Shmakov <oneingray@gmail.com> - 2013-03-13 17:28 +0000
    Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ivan Shmakov <oneingray@gmail.com> - 2013-03-14 20:25 +0000
    Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ivan Shmakov <oneingray@gmail.com> - 2013-03-17 17:57 +0000
      Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ben Morrow <ben@morrow.me.uk> - 2013-03-18 23:42 +0000
        [OT] reporting bugs Ivan Shmakov <oneingray@gmail.com> - 2013-03-30 11:02 +0000
          Re: reporting bugs Ben Morrow <ben@morrow.me.uk> - 2013-04-01 22:58 +0100
            Re: reporting bugs Ivan Shmakov <oneingray@gmail.com> - 2013-04-06 13:50 +0000
          configuring CPAN to apply patches (such as #29468, IPv6 in Net::HTTP) Ivan Shmakov <oneingray@gmail.com> - 2013-06-28 19:48 +0000

csiph-web