Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 19
  1. #1
    Junior Member
    Join Date
    Oct 2007
    Posts
    12

    Packaging for openSUSE

    Hi all

    Just got my first squeezebox yesterday and am very happy with it.

    I've repackaged SqueezeCenter svn for openSUSE and have a couple of questions

    1) makerelease.pl builds an RPM using a simple specfile in platforms/redhat. How do you use the Debian and Fedora specfiles to build packages - are you dropping the tarball generated by makerelease.pl and the specfiles into a distro specific build service and turning the handle there?

    2) Are you moving towards using distro perl instead of the included CPAN directory? The thread 'Nightly Builds broken on Windows' can be read to suggest that problems should be solved by upgrading distro perl packages. If so I'll have to improve my perl packaging skills.

    3) Where/how are you distributing fedora/debian packages - the nightly RPM is apparently built with the simple redhat specfile - and are you aiming to get the redistributable parts upstream?

    There is a switch in the fedora specfile to delete the Firmware and Graphics subdirs - are these the only unredistributable portions of the source tree? Are there (treading lightly here) any distributability issues I should know about with any binary code included in the repo?

    I'll post a patch containing my changes when I get things cleaned up. At the moment I have edited slimserver.spec.build and hacked makerelease.pl to pass in suse-specific config and initscripts to the rpm build, but if there is another mechanism to build distro specific packages I'll use that instead.

    4) Finally, the webapp does not respond and cries
    [13:41:01.4112] Slim::Networking::Select::select (245) Error: Select task failed: Can't locate object method "canUseiTunesLibrary" via package "Slim::Plugin::iTunes::Common" (perhaps you forgot to load "Slim::Plugin::iTunes::Common"?) at /usr/lib/perl5/vendor_perl/5.8.8/Slim/Web/Settings/Server/Wizard.pm line 134.
    - is this probably an svn blip or a packaging error on my part? /usr/lib/perl5/vendor_perl/5.8.8/Slim/Plugin/iTunes/Common.pm has the function, but I can't see a use iTunes anywhere in Wizard.pm.

    Will Stephenson

  2. #2
    Former Squeezebox Guy andyg's Avatar
    Join Date
    Jan 2006
    Location
    Pittsburgh, PA
    Posts
    7,396

    Packaging for openSUSE

    On Oct 10, 2007, at 8:07 AM, wstephenson wrote:

    >
    > 1) makerelease.pl builds an RPM using a simple specfile in
    > platforms/redhat. How do you use the Debian and Fedora specfiles to
    > build packages - are you dropping the tarball generated by
    > makerelease.pl and the specfiles into a distro specific build service
    > and turning the handle there?


    makerelease.pl has a separate section for Debian. We don't build
    Fedora.

    >
    > 2) Are you moving towards using distro perl instead of the included
    > CPAN directory? The thread 'Nightly Builds broken on Windows' can be
    > read to suggest that problems should be solved by upgrading distro
    > perl
    > packages. If so I'll have to improve my perl packaging skills.


    No, distro Perl packages cause too many problems. I've just moved
    the Debian build back to using our CPAN directory. I know the Fedora
    build depends on a bunch of distro Perl packages but I'm not going to
    worry about it since we don't support it. If you can use distro
    packages and still pass the minimum version checks I guess it's OK.

    >
    > 3) Where/how are you distributing fedora/debian packages - the nightly
    > RPM is apparently built with the simple redhat specfile - and are you
    > aiming to get the redistributable parts upstream?


    What parts upstream? We have to distribute it ourselves because no
    one else is allowed to redistribute the firmware.

    >
    > There is a switch in the fedora specfile to delete the Firmware and
    > Graphics subdirs - are these the only unredistributable portions of
    > the
    > source tree? Are there (treading lightly here) any distributability
    > issues I should know about with any binary code included in the repo?


    I really don't understand why you would want to package SC only to
    pull out these directories. Just don't bother, and let people
    download it from us.

    >
    > I'll post a patch containing my changes when I get things cleaned up.
    > At the moment I have edited slimserver.spec.build and hacked
    > makerelease.pl to pass in suse-specific config and initscripts to the
    > rpm build, but if there is another mechanism to build distro specific
    > packages I'll use that instead.


    OK, but it won't be applied, since we won't be supporting a SUSE build.

    >
    > 4) Finally, the webapp does not respond and cries
    > [13:41:01.4112] Slim::Networking::Select::select (245) Error: Select
    > task failed: Can't locate object method "canUseiTunesLibrary" via
    > package "Slim::Plugin::iTunes::Common" (perhaps you forgot to load
    > "Slim::Plugin::iTunes::Common"?) at
    > /usr/lib/perl5/vendor_perl/5.8.8/Slim/Web/Settings/Server/Wizard.pm
    > line 134.
    > - is this probably an svn blip or a packaging error on my part?
    > /usr/lib/perl5/vendor_perl/5.8.8/Slim/Plugin/iTunes/Common.pm has the
    > function, but I can't see a use iTunes anywhere in Wizard.pm.


    No idea, if the tarball works, it's probably a packaging problem.

  3. #3
    Junior Member
    Join Date
    Oct 2007
    Posts
    12
    Hi Andy! You sound a bit pre-coffee, but thanks for responding so quickly .

    Quote Originally Posted by Andy Grundman View Post

    > makerelease.pl has a separate section for Debian. > We don't build
    > Fedora.
    So is someone external building Fedora or is the specfile just in the repo for the intrepid DIY fans?
    Would you consider adding a suse build setup to SVN for others to roll their own with?

    Quote Originally Posted by Andy Grundman View Post

    > No, distro Perl packages cause too many problems. > I've just moved the Debian build back to using our > CPAN directory. I know the Fedora build depends
    > on a bunch of distro Perl packages but I'm not
    > going to worry about it since we don't support it. > If you can use distro packages and still pass the
    > minimum version checks I guess it's OK.
    Fair enough, then I'll take the path of least resistance here and leave them inline.

    Quote Originally Posted by Andy Grundman View Post

    What parts upstream? We have to distribute it ourselves because no
    one else is allowed to redistribute the firmware.

    I really don't understand why you would want to package SC only to
    pull out these directories. Just don't bother, and let people download it from us.
    I want to make my SqueezeCenter installation easy for me to maintain, and maybe in doing so make SC more accessible to the broader openSUSE community. I'd prefer to fix the packages then let people download them from you, but if you can't do that, an RPM that contains the redistributable parts in the openSUSE build service, and points users at the tarball for the firmware is the other option.

    Quote Originally Posted by Andy Grundman View Post

    OK, but it won't be applied, since we won't be supporting a SUSE build.
    There are some fixes in there that you should have in the generic RPM too.

    Quote Originally Posted by Andy Grundman View Post
    No idea, if the tarball works, it's probably a packaging problem.
    No worries, it was just a shot in the dark. I haven't tried the tarball yet.

  4. #4
    Former Squeezebox Guy andyg's Avatar
    Join Date
    Jan 2006
    Location
    Pittsburgh, PA
    Posts
    7,396

    Packaging for openSUSE

    On Oct 10, 2007, at 11:29 AM, wstephenson wrote:

    > Andy Grundman;234058 Wrote:
    >>
    >>> makerelease.pl has a separate section for Debian. > We don't build

    >>
    >>> Fedora.

    >>

    >
    > So is someone external building Fedora or is the specfile just in the
    > repo for the intrepid DIY fans?
    > Would you consider adding a suse build setup to SVN for others to roll
    > their own with?


    I don't know anything about the Fedora build. I wouldn't have a
    problem adding a platforms/suse directory that is community-maintained.

    > Andy Grundman;234058 Wrote:
    >>
    >> What parts upstream? We have to distribute it ourselves because no
    >> one else is allowed to redistribute the firmware.
    >>
    >> I really don't understand why you would want to package SC only to
    >> pull out these directories. Just don't bother, and let people
    >> download
    >> it from us.
    >>

    >
    > I want to make my SqueezeCenter installation easy for me to maintain,
    > and maybe in doing so make SC more accessible to the broader openSUSE
    > community. I'd prefer to fix the packages then let people download
    > them from you, but if you can't do that, an RPM that contains the
    > redistributable parts in the openSUSE build service, and points users
    > at the tarball for the firmware is the other option.


    It's a lot of work for us to officially support a new distro package,
    so I'm going to say for now that we won't be distributing a SUSE
    package.

    >
    > Andy Grundman;234058 Wrote:
    >>
    >> OK, but it won't be applied, since we won't be supporting a SUSE
    >> build.
    >>

    >
    > There are some fixes in there that you should have in the generic RPM
    > too.


    OK, I have not yet taken a look at the status of our RPM build.



  5. #5
    Senior Member
    Join Date
    Sep 2006
    Posts
    622
    I'll post a patch containing ... suse-specific config and initscripts to the rpm build, but if there is another mechanism to build distro specific packages I'll use that instead.
    OK, but it won't be applied, since we won't be supporting a SUSE build.
    That comment got me wondering...

    1) Does SlimDevices/Logitech believe that there is any difference between "making XXX work" and "supporting XXX"? If a fringe distro just happens to work with the existing RPM, does this mean that distro is supported? I guess my point is I don't see the logical connection between applying a SUSE patch and supporting a SUSE build.

    2) I'm all for rejecting patches that either break or risk breaking existing functionality (and I haven't seen this hypothetical patch, so I can't say), but rejecting patches that break nothing and improve compatibility seems like, well, the start of a code fork. I know SlimServer is GPL, but if a third-party began distributing an "improved" SlimServer RPM that worked on more distros than the trunk builds, could they distribute the player firmware in that RPM?

  6. #6
    Former Squeezebox Guy andyg's Avatar
    Join Date
    Jan 2006
    Location
    Pittsburgh, PA
    Posts
    7,396

    Packaging for openSUSE

    On Oct 11, 2007, at 12:06 PM, CatBus wrote:

    >
    >>>>> I'll post a patch containing ... suse-specific config and
    >>>>> initscripts to
    >>> the rpm build, but if there is another mechanism to build distro
    >>> specific packages I'll use that instead.> >

    >>
    >> OK, but it won't be applied, since we won't be supporting a SUSE
    >> build.
    >>

    >
    > That comment got me wondering...
    >
    > 1) Does SlimDevices/Logitech believe that there is any difference
    > between "making XXX work" and "supporting XXX"? If a fringe distro
    > just happens to work with the existing RPM, does this mean that distro
    > is supported? I guess my point is I don't see the logical connection
    > between applying a SUSE patch and supporting a SUSE build.


    To me, supporting means:
    * building a nightly for that distro
    * tech support needs to be prepared to handle calls for users of that
    distro
    * QA testing for that distro

    >
    > 2) I'm all for rejecting patches that either break or risk breaking
    > existing functionality (and I haven't seen this hypothetical patch, so
    > I can't say), but rejecting patches that break nothing and improve
    > compatibility seems like, well, the start of a code fork. I know
    > SlimServer is GPL, but if a third-party began distributing an
    > "improved" SlimServer RPM that worked on more distros than the trunk
    > builds, could they distribute the player firmware in that RPM?


    No, the firmware can only be distributed by us.

  7. #7
    Senior Member
    Join Date
    Sep 2006
    Posts
    622
    Ah, I think I have the distinction I was looking for--

    - If someone committed a patch that required a separate RPM build, then SD/Logitech would need to build/QA that RPM. Makes sense, and I'd call that support.

    - If someone committed a patch that allowed the existing RedHat RPM to install on SUSE without breaking it on RedHat, SD/Logitech would not need to make or QA a different build. I would not call that "supporting SUSE", I'd just call that "works with SUSE"

    So a patch of the first type would not be committed, I understand. What about a patch of the second type?

  8. #8
    Former Squeezebox Guy andyg's Avatar
    Join Date
    Jan 2006
    Location
    Pittsburgh, PA
    Posts
    7,396

    Packaging for openSUSE

    On Oct 11, 2007, at 2:06 PM, CatBus wrote:

    >
    > Ah, I think I have the distinction I was looking for--
    >
    > - If someone committed a patch that required a separate RPM build,
    > then
    > SD/Logitech would need to build/QA that RPM. Makes sense, and I'd
    > call
    > that support.
    >
    > - If someone committed a patch that allowed the existing RedHat RPM to
    > install on SUSE without breaking it on RedHat, SD/Logitech would not
    > need to make or QA a different build. I would not call that
    > "supporting SUSE", I'd just call that "works with SUSE"
    >
    > So a patch of the first type would not be committed, I understand.
    > What about a patch of the second type?


    Yep, that sounds right to me. A patch of the second type should be
    fine.

  9. #9
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    19,303
    Since distribution of firmware can only be done by SD/Logitech - what is the position wrt to the Slimserver packages for NASs such as QNAP, Thecus or Synology ?

  10. #10
    Former Squeezebox Guy andyg's Avatar
    Join Date
    Jan 2006
    Location
    Pittsburgh, PA
    Posts
    7,396
    Those NAS packages should not distribute firmware, and it will be downloaded from us on first startup.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •