[Pkg-javascript-devel] Bug#760297: Is MediaElement.js fit for testing?

[David Prévot]

On Fri, Sep 05, 2014 at 01:21:52AM +0200, Jonas Smedegaard wrote:
> Quoting Debian Bug Tracking System (2014-09-04 23:24:05)

> >> # Please, stop overriding the maintainer’s call without reason.
>
> I ask a question

I already pointed at explanations before, and didn’t want to give more
credit to your recurrent flame-baits on this topic. Anyway, for the sake
of third parties you’re willing to pull in the thread or any interested
people, let me try to gather some information bellow.

> you just silently play severity ping-pong here.

I just want you to stop playing, and advise you to get in touch with the
release team if you want them to enforce an RC-bug here.

> That pisses me off.

I find your behaviour off limit.

> I seriously consider no longer wasting my time here.

Please, consider stop wasting other people time and energy.

Now, to the facts:

- MediaElement is currently embedded in at least two packages
  (wordpress and owncloud). As such, preventing the current package to
  enter testing is pointless (it’s already there), and harmful (code
  duplication, security tracking, etc.)
- All functionalities of the package are not yet enabled, and that is
  documented in the package description. As proven (at least via
  owncloud: I’ve not investigated how/if the media playing works in
  wordpress), the current package allows to play video and audio in a
  browser, which make it all but useless.
- Since the initial packaging that has been approved by ftpmasters,
  upstream documented a way to rebuild the Flash parts. They use Flex
  SDK to do so (the present bug as been documented as blocked by the
  relevant RFP one day after you opened it).

What are our perspectives here?

- Manage to build the Flash parts using tools from main, i.e., either:
  + Introduce Flex SDK, in the archive (I’m waiting for an answer from
    the latest person who showed some interest into it [1]). I already
    started to look into this package, but it’s a big one, with a lot of
    Java stack. I’m really not comfortable with all that, and hope
    someone more interested than me could take the lead on this one, but
    in case nobody does, I’ll try to bite the bullet.
  + Use an alternative build system to the one used upstream, (e.g.,
    as3compile from swftools). I already tried that path before without
    much success, but back then, the package wasn’t yet accepted in the
    archive, which made the effort less attractive. Back then, the build
    system wasn’t documented either, so I intend to retry ASAP (i.e.,
    when done trying to document the current issue instead of trying to
    fix it).
- Manage to build the Silverlight parts: that one seems tricker, since
  there doesn’t seem to be any tool available in Debian (nor Linux-OSes
  at large) to even test them. I already looked into the Mono tools
  available in the archive, but the build system seems even more obscure
  than for Flash, and is not documented upstream. Someone with
  Silverlight or Mono knowledge would certainly be highly welcome, but I
  don’t know where to find such person (making this package available
  may help, that’s also why I preferred to go on and make it public
  instead of letting it rot in a private VCS).

What alternative?

Since you (Jonas) seem to have some specific expectations about how this
package should work, I can think of at least one alternative if you’re
not willing to help into the previously explained perspectives, that may
allow you to use a MediaElement package the way you see fit: simply
repackage it as, e.g., mediaelement-nonfree, without excluding the
build/*.swf and build/*.xap from source, and just copy them into the
binary package you may upload to non-free. Feel free to make it provide,
conflict, and replace libjs-mediaelement if you want to have it
installed in the same place. Feel also free to reuse (or not) part or
all of the existing package, and feel free to use dgit if you can’t
stand having to deal with the upstream VCS as part of the packaging one.
Disclaimer: I’m personally not interested at all by the non-free
alternative, just wanted to point it as a middle-ground workaround until
we’re able to properly fix this bug.

        1: https://bugs.debian.org/602499#87

Regards

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20140904/83bda6ab/attachment.sig>