Best way to report bugs in packages?

In playing with xoscope on a Pi4 equipped with an ALSA sound capture device it looks as if the xoscope installed by apt has been compiled without ALSA support. This conjecture comes from:

formatting link

Looks like it's fixed in 2.2-2, but apt installs 2.2 Is there any point in making a noise, if so, where?

I'll attempt to compile xoscope 2.3 from source now, but gtk3+ (named gtk+3 for some reason) is turning out to be huge. I hope it's enough 8-)

Thanks for reading,

bob prohaska

Reply to
bob prohaska
Loading thread data ...

I'm not as familiar with the Debian/Raspbian bug reporting culture and attitudes as I am with that of Fedora, though I have bug reportings logins for both Fedora and Raspbian.

In your shoes I'd probably raise a bug on the grounds that if nobody raises a bug the package will remain uninstallable and won't get fixed. Then if I didn't want to wait for a fix to appear, I'd download and compile from source - and add comments to my previous bug if the source failed to compile.

I'm in a similar position with Audacity: the current version crashes if I try to record from an old Ion MixMeister ADC, and so does the previous (2.4.2 version) though both were fine in the past. The Audacity gang apparently don't have any similar ADCs so I'm currently helping to sort sort the problem out - bit of a faff since I'm not a fan of debuggers like gdb, preferring to work with run-time tracing rather than poring over crashdumps: when you've developed projects using standard languages (C, COBOL, PL/I) and standardish OSen (Unices, OS/400, VME/B), much more hardware specific kit like debuggers gets old fairly fast, but as always its a matter of horses for courses and YMMV.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Oh right, should have read that post before replying in the other thread then. Could have saved digging up that same part of the README the hard way (by downloading the source).

Well there is a guide:

formatting link

I don't know if there's much point, because honestly I've always been too lazy to jump through all the right hoops, so never gone through with reporting a Debian bug.

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

On Sun, 2 May 2021 18:41:54 -0000 (UTC), bob prohaska declaimed the following:

Probably not... xoscope 2.2-3 is currently in the "testing" version of Debian "Bullseye" (Debian 11).

formatting link
I don't envision the Debian crew back-fitting it to "stable" (Buster).

Which means that, shortly after Bullseye goes "stable", the Raspberry foundation should begin (actually, they may already be using "testing" for preparation) to configure a RaspiOS based upon it.

You could try

formatting link
and see if you can manually install the .deb file on Buster...

I suspect you'll end up with lots of dependencies (newer versions) that are not in "Buster".

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

The puzzle is _where_ to raise the bug. Starting from

formatting link
it isn't at all clear where bugs should be reported. Almost like the Foundation doesn't _want_ bug reports. Part of the trouble is likely mixed parentage: RaspiOS is a Debian derivative, so who's responsible? There's no hint at raspberrypi.org.

I did try to download and compile xoscope 2.3 from github. It looks like the configure script fails. There's no very explicit guidance on how to specify an ALSA-compatible build, either. Since ALSA seems to be the only choice on the Pi that's a serious hurdle.

In the meantime it turned out that a build of xoscope on FreeBSD worked without a hitch; recognized the audio capture device and displayed reasonable waveforms. I will admit that the behavior of xoscope is somewhat obscure to somebody who learned about 'scopes on

500 series Tektronix instruments equipped with Polaroid cameras 8-)

At least there's a group of developers to help. Xoscope is much, much more obscure. But, you make a point, the program developers are maybe the folks who have the most interest in seeing things work.

I'll hold my peace for now, as I'm not sure xoscope will do what I want. It has the bandwidth and resolution needed, but triggering behavior is most confusing.

Thanks for writing!

bob prohaska

>
Reply to
bob prohaska

There does seem to be a "chain of command", in that Debian originates software, Raspberrypi.org modifies it and folks like me attempt to install and use it.

If I find something that doesn't work, is it my fault, raspberrypi.org's fault, or Debian's fault? First burden is on me, next seems to be raspberrypi.org and if they can't fix it the problem is Debian's. If Debian can't fix it the problem comes back to me.

Thanks for writing,

bob prohaska

Reply to
bob prohaska

In Debian, you would use reportbug. This is available on the Pi, and presumably has been tweaked to send the report to the right place. It isn't installed by default.

Everywhere a package is modified should be in the bug loop i.e. the Pi maintainers first, then Debian, then the mysterious 'upstream'. Whoever fixes the bug, if the bug came from further up the chain, will report it and probably provide a patch. If the bug comes from further upstream and is fairly fundamental, it will be passed up the chain.

--
Joe
Reply to
Joe

In the past I've reported Raspbian bugs here:

formatting link

... but I don't remember how I found the raspbian.org website or the but reporting part of it.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Cough: ITYM Raspbian.org, since they own the OS and bug reporting system, although they're most likely to be the software part of the Raspberry Pi organisation.

That looks about right, though if it crashes on take-off without any Mayday message the finger points pretty directly at raspbian.org Similarly, my first port of call for anything in a package installed from the Fedora repository is the Fedora bugzilla regardless of who wrote and/ or maintain the packaged code. I think this is the usual and expected approach for most Linux distros.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

The bug has been reported, thank you for letting me know about reportbug!

bob prohaska

Reply to
bob prohaska

cat /etc/os-release

--
Regards 
Kees Nuyt
Reply to
Kees Nuyt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.