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 attachment 66467 [details] libifp-1.0.0.1.ebuild ebuild file, WITHOUT building a kernel module
Created attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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.
