Bugzilla Bug 103222

libifp is a general-purpose library-driver for iRiver's iFP (flash-based)
portable audio players

qaution: ifp-line or ifp-gui doesn't depend on this package

libifp's ifpline program is an example. it's a tool compatible with the `ifp'
program (in the ifp-line package) that uses library from this package

for now - I'm able to build and install everything, without a kernel module...
there's an (let's say) `portage kernel issue`... running make outside the emerge
process works great, but inside it gives me errors about missing includes.

Package may be a blocker for programs that depends on this library.

Regards,
Przemek

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=66467) [details]
libifp-1.0.0.1.ebuild

ebuild file, WITHOUT building a kernel module

Created an attachment (id=66469) [details]
libifp-1.0.0.1.ebuild (BROKEN: with module use flag)

this ebuild has one more USE flag - "module". Unfortuantelly it gives me errors
mentioned in first post...

currently BROKEN - DO NOT USE THIS!

Can somebody check this? It would be nice to have ability to mount IMM type
iRiver players...

Regards,
Przemek

an update to version 1.0.0.2 is now available

I checked source code - should require only ebuild name changing. Will try it
later, today.

Cheers,
Przemek

Created an attachment (id=66686) [details]
libifp-1.0.0.2.ebuild

Ok - updated ebuild to version 1.0.0.2 .

One new line to configure : --with-libusb
Without this, libifp is not giong to be build corectly.... don't have a clue
why. Now it works.

PS. Will check how is this version works with ifp-gui

Regards,
Przemek

Created an attachment (id=66687) [details]
libifp-1.0.0.2.ebuild (BROKEN: not working module USE flag)

- ifp-gui works and build ok with updated libifp
- same problem with module USE flag, as described previously

I will try to do something with this module.... :|

Regards,
Przemek

I can take over maintainership of this ebuild, if a maintainer is needed.
(given
who the bug is assigned to, I am assuming that is the case)

I will take a look into the module USE flag soon, also I am planning to write
an
ebuild for the ifp-gnome package (http://ifp-gnome.sourceforge.net)

it would be nice to have working module use flag :)

Cheers,
Przemek

Created an attachment (id=77229) [details]
ebuild with working module USE flag

Here is a fixed ebuild, and I will take over official maintainership of this
package once I finish my dev mentorship.

Good work Patrick!

Also - it's good you will maintain this. If my ebuild quiz will be aproved I
want to maintain ifpgui, for which libifp is a depend package.

BTW. my 2 cents - maybe it would be better to split libifp into two pakcages -
module one and library itself? This way, if user will change a kernel it
wouldn't be nesseccery to recompile library, when only building a module is
needed?

PS. Good luck with your dev mentorship.

Regards,
Przemek

One more info - same spliting I talk about (lib/module) was done with
em8300-{libraries,modules} packages.

Regards,
Przemek

I was mostly looking at svgalib as an example, which has a similar helper
module for non-root use, it's all in one package. The module is part of the
package, and libifp doesn't take very long to compile (considerably less time
than svgalib, for example).

Maybe we should see what a real dev has to say about this.

(In reply to comment #11)
> The module is part of the package, and libifp doesn't take very long
> to compile (considerably less time than svgalib, for example).
true, but still - imho - as separate packages, it would look better (imho ;) )

> Maybe we should see what a real dev has to say about this.
yeap - agree :)

eighter way - it's good, that it will finally be in portage :)

Regards,
Przemek

Reassigning to sound as this really needs to get in portage as soon as Patrick
get access (it's an optional dependency of amarok 1.4).

/me prepares enlistment of him into sound herd :P

Created an attachment (id=77263) [details]
separate ebuild for the libifp module

Here is the separate ebuild for the module, will post the new libifp in a few
moments.

Created an attachment (id=77264) [details]
new libifp ebuild with the module moved into a separate ebuild

I also moved the compiled ifpline example to /usr/bin, it actually is a useful
app, there's no reason not to put it in the path.

(In reply to comment #15)
> I also moved the compiled ifpline example to /usr/bin, it actually is a useful
> app, there's no reason not to put it in the path.
I did this, cause there is a seperate package with this command line tool,
called ifp-line :
http://bugs.gentoo.org/show_bug.cgi?id=103188

and in this package it's only an example.

Regards,
Przemek

Created an attachment (id=77269) [details]
libifp ebuild with "doc" use flag, and a few cleanups

Put back the moving of ifpline, added a doc USE flag, and a couple of misc
cleanups.

Since I am a dev now, I will take this bug.

Ebuilds added to CVS tree.