Ticket #305 (closed bug: worksforme)

Opened 4 years ago

Last modified 4 years ago

ffado-mixer crashes

Reported by: oget Assigned to: arnonym
Priority: major Milestone:
Component: ffado-mixer Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to:

Description

We have 3 crash reports with backtraces at Fedora bugzilla for ffado-mixer, all from panelmanager.py

https://bugzilla.redhat.com/show_bug.cgi?id=634871 https://bugzilla.redhat.com/show_bug.cgi?id=635315 https://bugzilla.redhat.com/show_bug.cgi?id=634917

Please let me know if there is a fix or workaround for these crashes. Our ffado package is based on the SVN snapshot of the trunk from July 6th, 2010.

Thanks

Change History

(follow-ups: ↓ 2 ↓ 3 ) 09/19/10 15:18:50 changed by arnonym

  • status changed from new to assigned.

First note: You ship trunk (what will become 2.1) as 2.0.1. That is wrong!!! We already have a version 2.0.1 released which doesn't contain any of the files that your bug-reports mention!

Further more: That Motu-error seems to be fixed in r1873. (Hint: when using the development version, try updating to the current HEAD before reporting a bug.)

For the other two reports: There is a reason we ask for certain information in our README-file. For 634917 it seems that the mixer for the saffire (no LE) is loaded. but we don't know whether that is the right device... And 634871 could be with a usb-soundcard for all we know from the report...

Sorry if that sounds harsh, but especially the first note has me rather pumped up.

(in reply to: ↑ 1 ; follow-up: ↓ 4 ) 09/19/10 15:30:34 changed by oget

Replying to arnonym:

First note: You ship trunk (what will become 2.1) as 2.0.1. That is wrong!!! We already have a version 2.0.1 released which doesn't contain any of the files that your bug-reports mention!

Shipping trunk (what will become 2.1) is what was advised to me by one of your developers on IRC Freenode.

The user can't simply update to the HEAD before reporting the bug, because they are using compiled packages, and may not even know how to construct one. Do you advise me to prepare a test package to the user and see if he can reproduce?

Sorry if that sounds harsh, but especially the first note has me rather pumped up.

It's okay. This means you folks need better communication on what to advise to packagers.

Thanks.

(in reply to: ↑ 1 ) 09/19/10 16:16:41 changed by oget

Replying to arnonym:

For the other two reports: There is a reason we ask for certain information in our README-file.

Well, I would like to remind you that I am neither the actual bug reporter nor a ffado developer. I am just acting as a bridge in between. We provide the users the README file, and it is their choice not to read it. Would you like to subscribe to the Fedora bugzilla, and talk to the users directly? This would eliminate me as I don't have much of a function other than causing a lag.

(in reply to: ↑ 2 ) 09/19/10 16:30:50 changed by arnonym

Replying to oget:

Replying to arnonym:

First note: You ship trunk (what will become 2.1) as 2.0.1. That is wrong!!! We already have a version 2.0.1 released which doesn't contain any of the files that your bug-reports mention!

Shipping trunk (what will become 2.1) is what was advised to me by one of your developers on IRC Freenode. The user can't simply update to the HEAD before reporting the bug, because they are using compiled packages, and may not even know how to construct one. Do you advise me to prepare a test package to the user and see if he can reproduce?

Given the fact that you provided the (wrongly numbered package) in the first place and are the one to do the packaging (I suppose?), why not prepare and up-to-date test-package. Or check for yourself in the "upstream" repository if one of the files mentioned in the reports have changes since the version packaged.

Sorry if that sounds harsh, but especially the first note has me rather pumped up.

It's okay. This means you folks need better communication on what to advise to packagers.

Cool. We release 2.0.0 and create a branch for 2.0.X and label our trunk as 2.1.999. But we are to blame when distributions ship 2.0.1 created from trunk while we really ship 2.0.1 from 2.0-branch where its supposed to be created from.

I was confused some days ago when someone said that his dice-based device was working with 2.0.1. Now I know why. Thanks for misleading our users and getting us in trouble. Its not like we don't have anything else to do...

And no, I don't want to subscribe to fedoras bugtracker. Your bugtracker is for faults in your packages, our bugtracker is for faults in our software.

Which means: Yes, please tell your users to report bugs (that are not a result of your shipping) at our bug tracker. And if you don't tell them to read the README beforehand, we will. Because we really need the information asked there...

09/19/10 16:50:47 changed by oget

In Fedora versioning convention, ffado-2.0.1-3.20100706.svn1864 means - It is svn snapshot. - The svn snapshot is made post 2.0.1

If it were a release candidate/beta/snapshot pre 2.0.1 we would use ffado-2.0.1-0.x.rc1 (note the 0 after the -)

Following this convention, I would love to have our package versioned as ffado-2.1.0-0.x.2010xxxx.svnxxxx but I can't guess what your next version number is going to be. Some say 2.1, some say 2.1.0, now you are saying 2.1.999 labeling your trunk, which suggests a release number of 2.2.0 or something in that order...

And no, I don't want to subscribe to fedoras bugtracker. Your bugtracker is for faults in your > packages, our bugtracker is for faults in our software.

I can't agree more. However the users (not just ffado users) keep reporting bugs in our bugzilla no matter how much we try to educate them. What you are suggesting is the ideal way of processing bugs. However it has not been the actual case for us. The users have been and will be coming to us first.

About the Fedora package, what do you suggest me to do now? I can fallback to the 2.0.1 version, or the SVN of that branch, or keep updating to the latest trunk until 2.1 (?) is released, and keep stable versions afterwards. I am not fond of shipping SVN snapshots to users, especially for libraries.

09/19/10 17:49:35 changed by oget

Let me elaborate more on the versioning on our package since I believe I did right with the amount of information I was given. Let's assume that the next version is going to be 2.1.0. (Note that I asked for this specific information before, but got no answer.). This is how things would go:

ffado-2.0.1-1                    (The actual 2.0.1 release)
ffado-2.0.1-2.20100811.svn1900   (SVN snapshot based on the 2.0 branch)
ffado-2.0.1-3.20100818.svn1920   (SVN snapshot based on the 2.1.0 branch, but I don't have the 
                                 information that the next branch is actually *2.1.0*)
ffado-2.1.0-0.1.20100828.svn1930 (SVN snapshot based on the 2.1.0 branch, given that now I am 
                                 given the information that the next release will be *2.1.0*)
ffado-2.1.0-0.2.beta1            (You release some beta1 for 2.1.0)
ffado-2.1.0-1                    (The actual 2.1.0 release)
ffado-2.1.0-2                    (I find a packaging bug (my fault) and fix it)
...

I think this will give you the idea.

09/20/10 01:13:17 changed by arnonym

The problem with your version-convention is that people install 2.0.1 version (the parts after that are ignored by most people writing bugreports directly to us) and ask about features/bugs that are only there in trunk.

I concurr that our naming system is not optimal. But its been the same before the 2.0.0 release: 2.0.999-something are the versions/dev-tree before the actual 2.0(.0) release. 2.1.999 is therefor the trunk-branch which will become 2.1-branch and 2.1.0 release in the future. Note that we speak about 2.0 and 2.1 releases because after these releases (which are published as 2.0.0 and 2.1.0) we don't touch these branches except for bug-fixes and do bug-fix releases after that, which will be names 2.0.X with X>1.

Its true that we never really made a statement what the next release will be named. Basically because we don't know how many bug-fix-releases the 2.0-branch will see. And because we don't know yet which features we will implement before the next major release. There are certain features (mostly resulting in major changes in the core) which would qualify the next release to be called 3.0. If these don't get implemented, we still have a long list of features and bugs to do for a 2.1 release.

I know our versioning scheme is actual hell for versions in a packaging system but thats how it is. And any packaging solution should reflect that there are stable versions and trunk development versions. One solution could be to ship libffado from the 2.0 releases and ship libffado-trunk with regular snapshots (or nightly snapshots everytime something changes) to allow people to follow trunk and get newest features without compiling themselve. If we devs could wish for something, these trunk packages would also be available in debug and non-debug flavour as its impossible to debug problems when the debug-info is stripped out but once the users system is set up and work, it gives better performance when a non-debug build is used...

I know its a mess. And I am very glad you packagers do this job to lighten our (the developers) burden. But please don't make it more complicated for us by using version-strings that do not follow our conventions...

10/02/10 22:07:57 changed by oget

Hi, I still need advise on how to proceed.

- Fall back to 2.0.1? or - Keep updating to latest 2.1.0 trunk? If yes, how would you like me to version the package: libffado-2.1.0 ? Can you promise me you will never release libffado-2.1 (without the 0)?

10/08/10 21:52:54 changed by oget

Hi, I did not got a response yet. :(

I will wait another week, if there is still no response I will go with the original advise: keep packaging the trunk (2.1 series).

10/13/10 00:12:26 changed by arnonym

Hi,

there is nothing wrong with packaging trunk. Only you have to name it correctly... Preferable give it the same version as the source uses.

One thing I can promise is that our releases will have three digits. And possibly some more appendizies (like -betaX or -rcX).

You could package both 2.0.1 (the stable series) and trunk in separate packages. They should be interchangable as the binary interface exported didn't (yet) change. And the firewire-backend of jack is the only one using it, so if in doubt, package and version that together with ffado.

Have fun and keep up the job!

PS: Can I reolve this report as "invalid" or "fixed"?

10/13/10 15:14:48 changed by oget

Sure. I will go with something like ffado-2.1.0-0.1.20101013.1970svn.fc13.rpm

That way when you do release 2.x.0, I can use ffado-2.x.0-1.fc13.rpm and the upgrade path is not broken. The only possible subtlety might happen if you release the next version as, say 2.0.5. But from what I understood, this is not likely to happen.

You can close the bug. But I am not sure if it should be "invalid" or "fixed" or "wontfix", since the crashes do happen, yet we don't know if they are fixed or not, and we have insufficient information to make this conclusion.

Maybe add a "insufficient info" to the list of possible resolutions and select that?

(follow-up: ↓ 13 ) 10/13/10 15:34:00 changed by arnonym

  • status changed from assigned to closed.
  • resolution set to worksforme.

I can't say anything about 2.0.5. But I think a 2.0.2 is possible...

But if you are packaging trunk as 2.1.0-X, this will not affect you as 2.0.[2-] will all be based on the 2.0-branch. So this would not be an update for your packaging.

Regarding the actual crashes: One is definitely fixed and the other two we don't even know the device the users are using which makes the reports un-usable/invalid. Please encourage the users of your package to report bugs and stuff here and tell them to read (and follow) the instructions in the readme-file.

Probably an arrogant "worksforme" is the "solution" to this ticket...

(in reply to: ↑ 12 ) 10/13/10 15:48:19 changed by oget

Replying to arnonym:

Please encourage the users of your package to report bugs and stuff here and tell them to read (and follow) the instructions in the readme-file.

Sure, will do. I actually told the reporters of the 2 bugs to do this but I am not sure if they actually took their time to report the bugs to you.