Support for arm arch in the prebuildt .deb packages?

FireFly Media Server Firefly Media Server Forums Firefly Media Server Feature Requests Support for arm arch in the prebuildt .deb packages?

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #640
    drone
    Participant

    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.

    #6644
    drone
    Participant

    I 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 —

    #6645
    rpedde
    Participant

    @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

    #6646
    drone
    Participant

    As 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-common

    Oh really, x11 stuf eh? And 33 packages, this is one killer of a mediaserver…

    Anyway, thanks for making my life even more easy. 8)

    #6647
    rpedde
    Participant

    @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-common

    Oh 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

Viewing 5 posts - 1 through 5 (of 5 total)
  • The forum ‘Feature Requests’ is closed to new topics and replies.