Please package Amarok Rio Karma support (--with-libkarma)

Bug #89591 reported by Richard J. Turner
14
Affects Status Importance Assigned to Milestone
amarok (Ubuntu)
Invalid
Wishlist
Unassigned

Bug Description

Binary package hint: amarok

Since v.1.4.4 Amarok has had support for Rio Karma DAPs. In Feisty could this support either be enabled by default or made available as a separate package please?

Tags: packaging
Revision history for this message
Sense Egbert Hofstede (sense) wrote :

Thanks for your report. Your idea might get more attention and have the possibility of being implemented if you submit a specification for it. First check whether the idea is already registered <https://launchpad.net/ubuntu/+specs>, and if so, contact the specification's drafter about your ideas. Otherwise, you can start writing a spec yourself. <https://wiki.ubuntu.com/FeatureSpecifications>

Changed in amarok:
status: Unconfirmed → Rejected
Revision history for this message
Andrew Ash (ash211) wrote :

Hold on just a second. The only change required for this is to add --with-libkarma to the debian/rules file in the package the next time it's built. Now this might depend on a new library package, but that's a small price to pay for having your mp3 player work with Amarok!

I'd like to see this change made as well.

Changed in amarok:
status: Rejected → Confirmed
Revision history for this message
Richard J. Turner (richard-zygous) wrote :

Ah, thanks for taking a look Andrew. I clearly should have been a little more explicit about what is required. I can't help thinking that writing-up a spec for this change would be a little bureaucratic!

As you say, the --with-libkarma configuration flag is required. Three new files will be compiled so those will need to be added to the debian.install file. They are:

* /usr/lib/kde3/libamarok_riokarma-mediadevice.la
* /usr/lib/kde3/libamarok_riokarma-mediadevice.so
* /usr/share/services/amarok_riokarma-mediadevice.desktop

Finally, the libkarma0 package is required and libkarma-dev is a build requirement. I don't think the karma-tools package is required.

Additionally, OMFS is required - the kernel module to support the Karma file system. I don't think this is a package at the moment. See http://linux-karma.sourceforge.net/rio-usb.html.

I've managed to get my Karma auto-mounting by using the settings files listed here, although in Feisty there's no need to manually create the mount-point:

http://www.mail-archive.com/linux-karma-devel%40lists.sourceforge.net/msg00258.html

I guess it'd be handy to suggest to the HAL package maintainer that these settings files be added to the package, but I'm a bit loathe to try after the reception of this bug!

Revision history for this message
Andrew Ash (ash211) wrote :

So it looks like there are 3 changes necessary:

1) packaging changes to debian/rules and debian.install
2) libkarma0 & libkarma-dev packages
3) an OMFS package.

1 will be relatively easy, but 2 and 3 more difficult. As far as I'm aware, libkarma0 and libkarma-dev packages don't exist in either debian or ubuntu. See packages.{debian.org|ubuntu.com} I think I've seen an OMFS package on debian, but that doesn't exist in ubuntu yet. So libkarma will need to be packaged, and then OMFS will probably need to be synced from debian.

So new bugs need to be filed for parts 2 and 3. Please file those bugs, both against ubuntu, and subscribe the MOTU to those bugs and link them back to this bug - https://launchpad.net/bugs/89591 Hopefully someone in that team (MOTU does packaging work) will be able to get those packages together and get them into Ubuntu.

I think it's cutting it close for feisty now, since feature freeze is already in place, but this should be doable for feisty+1.

Revision history for this message
Richard J. Turner (richard-zygous) wrote :

The libkarma packages are available in universe:

richardt@melkor:~$ aptitude show libkarma0
Package: libkarma0
State: installed
Automatically installed: no
Version: 0.0.6-0ubuntu1
Priority: extra
Section: universe/libs
Maintainer: Ubuntu MOTU Developers <email address hidden>
Uncompressed Size: 139k
Depends: libc6 (>= 2.5-0ubuntu1), libtagc0 (>= 1.4)

Sadly OMFS is not; I'll raise a bug for that....

Revision history for this message
Andrew Ash (ash211) wrote :

Sorry, I was searching the edgy repo when I said libkarma0 was unavailable. Please link the bug you raise for OMFS to this one so people seeing that one can better understand the situation.

Revision history for this message
Richard J. Turner (richard-zygous) wrote :

Hmm. Well, I've tried three times to raise a bug for OMFS today, but keep seeing a Launchpad timeout error. Fortunately I think I was wrong in saying it's required for this Amarok patch - it's just that this patch won't be useful without it. Happily too, installing OMFS support the old-fashioned way is easy, just a "sudo make modules modules_installl", so it's not the end of the world if it's not packaged-up.

I'll try again later I guess....

Revision history for this message
alphablue52 (torsten-doerschel) wrote :

Well, the Debian experimental package of Amarok is compiled with Rio Karma support (search for version 1.4.5-3).
The libkarma0 is in the Ubuntu universe repository of feisty fawn, so all left to do is recompiling Amarok with the --with-libkarma option and providing an OMFS package, maybe just as a source package.

I acutally use the Debian Amarok package without any problems, you just have to pin the version so that apt-get won't "upgrade" it.

Revision history for this message
Andrew Ash (ash211) wrote :

Well if Debian's Amarok is compiled with libkarma and it works there, it must be providing the OMFS package somewhere, right? Would a simple sync of that package into Ubuntu make this just a change in the debian/rules file problem?

Revision history for this message
Andrew Ash (ash211) wrote :

I actually just saw omfs come through the gutsy changes list - https://launchpad.net/ubuntu/gutsy/+source/omfs/0.7.2-1

Looks like the only t hing to do now is enable --with-libkarma in amarok's debian/rules file.

Revision history for this message
Tom Helner (duffman) wrote :

I have opened a bug report to have omfs added to feisty:
https://bugs.launchpad.net/ubuntu/+bug/118300

Revision history for this message
Sarah Kowalik (hobbsee-deactivatedaccount) wrote :

libkarma needs a MIR for this to happen.

Revision history for this message
Sarah Kowalik (hobbsee-deactivatedaccount) wrote :

added to the list of MIR's needed. anyone feel like doing this MIR?

Changed in amarok:
assignee: nobody → hobbsee
importance: Undecided → Wishlist
Revision history for this message
alphablue52 (torsten-doerschel) wrote :

I started it, and added it to the MIR queue

https://wiki.ubuntu.com/MainInclusionReportlibkarma

Changed in amarok:
assignee: hobbsee → nobody
Revision history for this message
Martin Pitt (pitti) wrote :

Unsub'ing ubuntu-mir. Bug 174306 is the MIR bug.

Revision history for this message
alphablue52 (torsten-doerschel) wrote :

Okay, here's how to get karma&amarok working with Hardy:

1. install amarok and libkarma from ubuntu sources
2. download the OMFS module ver.0.7.6 from http://sourceforge.net/project/showfiles.php?group_id=155788&package_id=175124
3. untar, make_modules, make_modules_install
4. download the amarok package from debian with same version as your ubuntufied amarok
5. Get these files out of the package (it's a tar.gz, and you can find the files in data.tar.gz) and copy them to your local system
* /usr/lib/kde3/libamarok_riokarma-mediadevice.la
 * /usr/lib/kde3/libamarok_riokarma-mediadevice.so
 * /usr/share/services/amarok_riokarma-mediadevice.desktop
6. Probably restart your KDE
7. plug in your karma, mount the second partition somewhere (e.g. sudo mount /dev/sdb2 -t omfs /media/karma) and tell Amarok where to find your karma (/media/karma)
8. Be happy!

Okay, this is how we did it the last months but I guess 2 and 3 are available now. Only thing is that libkarma isn't main jet, and omfs-source is outdated for the hardy kernel (bug report already posted)

Revision history for this message
Perry E. Metzger (perry-piermont) wrote :

Following the previous directions (with a few difficulties -- I needed to get the amarok_riokarma-mediadevice.desktop file out of the amarok sources), I got my Karma working under Hardy. It would be nice to make the thing automatically mount when it is plugged in (which I don't know how to do) but I am not clueful enough to know how to do that.

It would be nice if this was fnally all packaged up -- clearly there is not much required to do it as Debian seems to have the whole thing done.

Revision history for this message
alphablue52 (torsten-doerschel) wrote :

I did automount the following way:
edit the options of your media player in amarok and add the following lines:
before connect: "kdesu mount /dev/sdb2 /media/karma/"
after disconnect: "kdesu umount /media/karma/"
Labels might be different, don't know because i use the german translation :-)
This way has one handicap: Now amarok asks me for sudo pwd everytime i start it. but you can ignore this.
There might also be a better way via HAL, but I have no clue how this stuff works.

I guess the Ubuntu guys won't add karma support to amarok anymore, although it would be really easy. The official reason might be because libkarma and omfs are not in main repository, so they would have dependencies to universe.
That means:
recompile omfs-source on every kernel upgrade
copy libamarok_riokarma-mediadevice files from debian on every amarok upgrade.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Amarok 2.0 no longer supports Rio Karma, so closing.

Changed in amarok:
status: Confirmed → Invalid
Revision history for this message
alphablue52 (torsten-doerschel) wrote :

What the ...???
You guys trying really hard to keep me away from Amarok 2 - Guess now you got it :-(

Only one question: Why? Support less than more?

Revision history for this message
Perry E. Metzger (perry-piermont) wrote :

Way to go with the sensitive treatment of the community, Jon Thomas! People sit around waiting for a couple of years for a support issue to be fixed for their hardware, limping along when things could Just Work with minimal effort. Therefore, the right thing is to say to yourself "oh, the new release doesn't support your hardware anyway, HAHAHAHAH LOSERS! I'm closing your bug report. That's another one closed for me today! SCORE! I WIN YOU SUCKERS!"

Do you ask "would people still want 1.4 around so they could use their Karmas still"? No. Did you even apologize for the fact that a trivial thing was left untouched for a couple of YEARS when it could have been fixed quickly and would have made people happy? No. Do you acknowledge the work people put in to make it easy for the support to be added, the work no one bothered to pay attention to? No.

Instead we get your wonderful example of public relations, lets see if I can quote this accurately, it is so long:

"Amarok 2.0 no longer supports Rio Karma, so closing."

You even managed to save a few words by not using proper English grammar, thus speeding your way through your day.

Must be a great feeling, getting another bug report closed without even having to write one complete grammatical sentence! *THAT* is truly the most important thing. Remember to put the notch in the belt!

Revision history for this message
Perry E. Metzger (perry-piermont) wrote : Re: [Bug 89591] Re: Please package Amarok Rio Karma support (--with-libkarma)

Jonathan Thomas <email address hidden> writes:
> Amarok 2.0 no longer supports Rio Karma, so closing.

You know, in addition to the quality of your prose, I've gone over the
Amarok web site and I've been unable to find evidence that they dumped
Karma support. Not that (as I've noted) any of that probably matters to
you.

Revision history for this message
Lydia Pintscher (lydia-pintscher) wrote :

Perry: Please cool down. Jonathan is handling a few hundred bugs a day sometimes. And the Kubuntu team has limited resources which need to be used wisely. Would you rather have a new package/a fixed bug or him spending a lot of time on a reply in a bugreport?
Help with finding more people to help with bug reports is always appreciated.

Thank you.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :
Revision history for this message
Perry E. Metzger (perry-piermont) wrote :

Lydia Pintscher <email address hidden> writes:
> Perry: Please cool down. Jonathan is handling a few hundred bugs a
> day sometimes.

So?

> And the Kubuntu team has limited resources which need to be used
> wisely. Would you rather have a new package/a fixed bug or him
> spending a lot of time on a reply in a bugreport?

I think the criterion here seems to be "if we close the bug report,
we've succeeded, because that is as good as a fixed bug" rather than
"if we've fixed the problem users are experiencing, we've
succeeded". This is a twisted criterion.

And yes, I'd rather have fewer packages that were properly maintained
with care and consideration for the users than some mechanical figure
of merit being met.

Ubuntu has greatly disappointed me in this regard across the board. It
is not enough to claim you want great user experience -- you actually
have to deliver, and part of "deliver" means "don't leave a bug report
to rot for two years and then close it with an abrupt who
cares". The "we're understaffed" excuse doesn't make people feel
better about the slap.

Perry

Revision history for this message
Perry E. Metzger (perry-piermont) wrote :

Jonathan Thomas <email address hidden> writes:
> See the last comment here: https://bugs.kde.org/show_bug.cgi?id=132713

Note the URL doesn't claim that it is policy not to support the Karma,
just that the work hasn't been done yet.

Lets forget that, though. There's a much deeper problem. Responding to
someone who feels slighted at the short shrift you've given them with
a second one-liner shows an unique sense of style. Remind me to
recommend you for a job in public relations. Oh wait! -- slaps thigh
-- you already have one. When you do stuff like this, it reflects on
the whole project.

Every Ubuntu release breaks my existing hardware worse, and in each
case it is a known bug, sometimes known for years. In other cases,
I've been waiting for years for simple bug reports to be dealt with
only to have them closed with some unresponsive message from a person
who clearly dealt with 300 other bugs that same day and might not even
understand the original issue.

Project management clearly does not understand that if you intend to
have people think your product is high quality, you cannot pretend
closing bug reports equals fixing bugs.

Perry

Revision history for this message
Harald Sitter (apachelogger) wrote :

Right. Write a mail to our boss. Oh wait! -- slaps thigh -- we don't have one.

Anyway, this is not a discussion forum. So please stop unrelated discussion.

Thank you.

Revision history for this message
Harald Sitter (apachelogger) wrote :
Download full text (3.3 KiB)

Perry E. Metzger wrote:
- When all was said and done, a bug that shouldn't have been
- closed without a discussion remains closed. Feel proud? You certainly
- showed that asshole user that he can't push maintainers around.
-
- Not that I care. Two nights ago I got a new gift from Ubuntu -- a
- binary upgrade that makes my laptop hang the second I close the
- lid. I'd file a bug report, but none of my others have ever been
- fixed, so why would this one. I think I'll just find another OS. Two
- years of Ubuntu quality control have taught me to give up. I will not
- be trying any longer.

Lets see....

a) _anyone_ can close bugs, and _anyone_ can open them again ... from what I
see nothing prevented you from doing the latter

b) my maintainer opinion on this is that the close was completely valid.
Granted, the close message could have been more verbose. But generally
speaking the request is invalid because Amaork 2 does not have support for Rio
Karma (and to be honest, it's not in sight either). In addition to that a
request for readding support for it would not belong in the Ubuntu bug tracker
but http://brainstorm.ubuntu.com so leaving this request open would give no
advantage, since someone who wants to implement a new feature for Amarok and
is searching for ideas, will be using brainstorm and not Launchpad to find
them.
So in the best case scenario the bug would just rot for months before either
the Amarok team reimplements support for Rio Karma, or someone else closes it
because it should be add to brainstorm.ubuntu.com.

c) you are blaming Jon, or rather, all Ubuntu/Kubuntu contributors that we
didn't move our arses to get this fixed, yet you didn't do anything to do that
"quick fix" you were talkign about, you didn't even offer your help, certainly
someone could have at least told you what the hold up is and what to do about
it

d) you want us to upgrade libkarma's and omfs's support level (which is
basically what being in main means) yet you say yourself that you'd "rather
have fewer packages that were properly maintained with care and consideration
for the users than some mechanical figure of merit being met", so you are
happy as long as those few packages are the ones you need? Just wondering...
how exactly do you think this ought to work out with | 1,000 users? | 10,000
users? | 1,000,000 users?

e) you call Lydia's "we're understaffed" an excuse, yet you have no clue about
the size of our team, nor how much time we spend on ubuntu matters per day

f) you complain about Ubuntu breaking support for your hardware all the time,
due to issues that were reported years ago. So... how exactly do you think
important bugs will ever get noticed if you insist on keeping obviously
invalid feature requests open and thus want them to fill up the bug tracker
for no good reason?

Truth be told, I don't give a crap. Buy a mac and get all the commercial
support you can get. If you want, use Ubuntu CDs as wallpaper replacement or
print out our mission statement and use it as toilet paper... I simply do not
care.

But don't you dare ranting about a committed Free/Libre Open Source Software
contributor who spends his spare t...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.