M-Audio DFU firmware loader for MobilePre, Ozone, Sonica and Transit USB audio interfaces. Contains firmware and udev rules. The firmware files (*.bin) are copyrighted by M-Audio, the rest is under GPL-2.
Created attachment 95030 [details] madfuload-1.2.ebuild I'm not sure about the license.
Created attachment 95031 [details] LICENSE
- einstall is a hack and only to be used, when the build script is so ugly that make DESTDIR="${D}" install doesn't work and the script is not easily fixable.
Created attachment 95034 [details] fixed ebuild with make DESTDIR="${D}" install
What keeps this ebuild from going into the tree?
(In reply to comment #5) > What keeps this ebuild from going into the tree? > Most likely the fact that there's no developers with this equipment.
The ebuild will be in sunrise as soon as it's reviewed.
Debian/Ubuntu has some fixes for this: http://osdir.com/ml/debian-bugs-rc/2009-09/msg01899.html
Created attachment 208726 [details] ubuntu-fixes-2009-09.txt ubuntu-fixes-2009-09.txt additional resources: - https://code.launchpad.net/~neil-aldur/ubuntu/karmic/madfuload/madfuload-fixes - http://www.mail-archive.com/debian-multimedia@lists.debian.org/msg03400.html
Created attachment 213886 [details] new ebuild
Created attachment 213888 [details, diff] udev rules patch as extracted from .txt
Created attachment 213889 [details, diff] configure.ac.patch as extracted from ubuntu.txt
Created attachment 213891 [details, diff] 64bit fix patch as extracted from ubuntu .txt
I Would like to see if someone on x86 and amd64 could test this, even if i will make the 64bit patch conditional later. Right now i would like to see if this works in this revision. (udev wise mostly i guess) Works as expected on my M-Audio Transit USB.
Created attachment 213896 [details] changed udevcontrol reload-rules to udevadm control --reload-rules
Created attachment 213898 [details] --reload-rules not --reload_rules, sloppy editing, sorry if there is a better way than 'udevadm control --reload-rules' please advice
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
