FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Feature Requests › Support for arm arch in the prebuildt .deb packages?
- This topic has 4 replies, 2 voices, and was last updated 18 years, 2 months ago by rpedde.
-
AuthorPosts
-
28/09/2006 at 1:15 PM #640droneParticipant
Questions, answers and maybe some solutions?
Hello, first off all let me say thank you for the great software.
Being both a debian and a mac user I was trying to get it running on a NSLU2. The NSLU runs two flavours of “debian” as some of you may know. I did a personal recompile for the bigendian version of the package a bit over a year ago, my little box was running the debonaras (an eb version of debian, its unofficial). We got it working and some of the debonaras developers included the package in the “debonaras feed”.However the train never stops for long… As work has been done getting a proper little endian debian version running on stock NSLU2 hardware I was trying out the firefly yet again.
My initial thoughts were “it would work” as I was now running a “proper debian” install, but the ARCH monster came to eat me. The downloadable .deb is i386 only.
My debian developer skills are not all that hot, but I figured if I could write up something once I should be able to do it again. And that is what Im up to now…
However, what would be my best use of resources so that all future users of the unstoppable firefly/debian/NSLU2 combo could live a carefree and easy life when it somes to installing it?
I could compile a .deb and let it be availible for download. But I wont. π
I could publish instructions how people could compile it themself. I will do that aswell ofc, but do we want the enduser to have a development enviroment on the slug just to live a happy media life? Not really I guess as it creates a big step up the learning curve for most users.
It could be included in the official debian resporitory, and have the autobuilders make me happy. But there is probably reasons its not in there already.
I could either give the .deb developer access to a slug so it could be buildt there with your control. Or Ill donate some money for a dev-slug if you want total control, I am guessing there is a sluguser in your midst already thu.
πMaybe debian on the NSLU2 is still so beta that all users running it have no problem with a local recompile with some instructions? I noticed the usercount passed 100 the other day, and maybe Im just flapping my arms for no reason. What you think?
Ill post back with some more of my sucsess (or lack thereof) as soon as I got some results. I may need the weekend as I dont really build .debs that often from source.
Pointers, rants, slaps and cheers are all welcome, hold the flames! But keep it up, you are doing great.
28/09/2006 at 4:59 PM #6644droneParticipantI should have mentioned the most obvious thing, so Ill add it here.
Compiling from source tarball is fast, clean and troublefree.
On my de-underclocked slug it took less then 10 min to compile.All the above fluff is just about the .deb precompiled package.
(Dont want to scare the DebianSlug users now would we) πAnd since I found this in the debian bug db Im guessing my ranting will come to an end soon’ish. I dont understand all the words, but I got the geist of it.
— start paste —
Date: Thu, 7 Sep 2006 11:15:40 -0700
Hi,
since these ITPs have stagnated, and mt-daapd can be compiled against
avahi’s howl compatibility now, I have prepared dfsg-free source
packages and am ready to upload them. If any of the previous ITPers
would like to comaintain this with me, I am quite willing, just contact
me..Thanks,
—
Joshua Kwan— end paste —
29/09/2006 at 3:21 AM #6645rpeddeParticipant@drone wrote:
Compiling from source tarball is fast, clean and troublefree.
On my de-underclocked slug it took less then 10 min to compile.I also run a de-underclocked debonaras slug. The tarballs come with debian rules, so building a debian package should be as simple as “fakeroot debian/rules binary”.
Although I haven’t updated the debian rules for nightly, so it might be off somewhate.
I’m in the middle of trying to set up an automated build chain to automatically build:
1. debian x86
2. debian armeb
3. debian mipsel
4. ipkg armeb
5. ipkg mipsel
6. windows
7. FC5
8. Ubuntu hairy palm or whatever the latest is
9. Maybe osx… that might end up manually built.I fought with getting esx server up and running, but was too slow with the ugly hardware I have laying around to make it work, so I’m switching to gsx server. I’m loading the vms now, and hopefully this weekend I’ll be dropping nightlies for all those platforms automagically.
since these ITPs have stagnated, and mt-daapd can be compiled against
avahi’s howl compatibility now, I have prepared dfsg-free source
packages and am ready to upload them. If any of the previous ITPers
would like to comaintain this with me, I am quite willing, just contact
me..Yeah, the thing that was stopping it was dfsg vs. aspl. Apple just bsd licensed the mdns stuff so I was going to repackage stable with avahi and the bsd licenced mdns stuff as 0.2.5, just so there was a free-free stable version around. The suse guys weren’t happy with aspl either, so that should make them happy too.
Hopefully I can get to all this over the weekend.
— Ron
08/11/2006 at 3:21 AM #6646droneParticipantAs I recently flashed the debian installer (d-i etch rc1) unto one of my slugs I was in the need of reinstalling mt-daapd. Ofc I had saved the .deb I made earlier myself, but as it was currently residing on another usb disk with no power supply I made for the nightlys. However having a fresh debian install with very little installed software (only samba, screen and irssi) I was very pleased to see that mt-daapd is in the etch feed. May I say YAY! π
Away I went and installed…
After unpacking 15.0MB of additional disk space will be used.
The following NEW packages will be installed:
avahi-daemon dbus liba52-0.7.4 libavahi-client3 libavahi-common-data
libavahi-common3 libavahi-compat-howl0 libavahi-core4 libavcodec0d
libavformat0d libdaemon0 libdbus-1-3 libdc1394-13 libexpat1 libflac7 libgsm1
libice6 libid3tag0 libogg0 libraw1394-8 libsm6 libsqlite3-0 libtag1c2a
libtagc0 libvorbis0a libvorbisenc2 libvorbisfile3 libx11-6 libx11-data
libxau6 libxdmcp6 mt-daapd x11-commonOh really, x11 stuf eh? And 33 packages, this is one killer of a mediaserver…
Anyway, thanks for making my life even more easy. 8)
08/11/2006 at 4:49 AM #6647rpeddeParticipant@drone wrote:
After unpacking 15.0MB of additional disk space will be used.
The following NEW packages will be installed:
avahi-daemon dbus liba52-0.7.4 libavahi-client3 libavahi-common-data
libavahi-common3 libavahi-compat-howl0 libavahi-core4 libavcodec0d
libavformat0d libdaemon0 libdbus-1-3 libdc1394-13 libexpat1 libflac7 libgsm1
libice6 libid3tag0 libogg0 libraw1394-8 libsm6 libsqlite3-0 libtag1c2a
libtagc0 libvorbis0a libvorbisenc2 libvorbisfile3 libx11-6 libx11-data
libxau6 libxdmcp6 mt-daapd[/size] x11-commonOh really, x11 stuf eh? And 33 packages, this is one killer of a mediaserver…
Don’t look at me, that’s an avahi dep. I’d make the argument that the avahi packages aren’t fine-grained enough if a text-only server drags in x11 packages.
Anyway, thanks for making my life even more easy. 8)
Don’t thank me, I’m not a dd. π
I am posting debonaras “sarge” debs on the nightlies page now. (that don’t drag in x11. π
— Ron
-
AuthorPosts
- The forum ‘Feature Requests’ is closed to new topics and replies.