The very purpose of MediaElement.js is to act as a polyfill for browsers
that does not support html5 <audio> and <video> tags, and it does so by
use of either flash or silverlight code.

...but this package has both flash and silverlight code stripped,
rendering the package utterly useless.

Instead of putting a note in README.Debian seeking developers to help,
it would've been better to have renamed the ITP bug#733880 to an RFP and
put the note there. :-(


 - Jonas

- -- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
iQF8BAEBCgBmBQJUBfBoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWc9YH/0UtnY96fz3oV42EPwodbNyd
XDFMMnWaGgNL2+x4kZVh5VIWGJmfepsXetAkkQsLL/f7oJ4tWtSKGGp+3AmeBJAY
LZFUM64Kom3F9gR214/ZccYQEnsylPdnsOlEORx1Ibsg2ZXPy6FbCQdsU1XydWAW
XPMawDZG5CgHt5QGG35nIUOJlPPLcOt276+f7+P3BX6hbA2atxHMsDcVi9VFgLsr
h1EMF0cs4zmtvhZ8jqctnyLbCMhz1LnOeSyyo6sxitkVa3tP/iAeJIfGDQbg2jTz
jl9ofZG9r1HderUStQNsjVX7sVcKoIDwWgRj9YAqb9v0lK2gR+MVAmZRFwyG0Do=
=7zOP
-----END PGP SIGNATURE-----

Hi,

Le 02/09/2014 12:29, Jonas Smedegaard a écrit :

As (not enough) documented in the package description and (better) in
the upstream homepage, the purpose is to offer an unified interface in
order to offer the same experience whatever the browser. The Flash or
Silverlight shim are only used if needed to help legacy browsers not
HTML5-compatible to mimic those expectations. The middle-term goal is of
course to offer the the Flash and Silverlight shims, but the upstream
build process was not really open and properly documented at the time
the package was uploaded to Debian.

No, again, it’s not. As a proof of concept, it’s already used in
ownCloud (as an embedded library for the moment, since
libjs-mediaelement only made it out of NEW today).

Feel free to help getting one or both of these stuff in shape if you
need them, it’s a team maintained package after all. Hopefully upstream
managed to improve the building while the package was waiting in NEW,
and that won’t be as messy as it used to.

Regards

David

Quoting David Prévot (2014-09-02 21:50:54)

You honestly consider lack of those parts merely a wish, no bug at all?

Let's see - here are the bullet points from the front page:

  * HTML5 audio and video players in pure HTML and CSS.
  * Custom Flash and Silverlight players that mimic the HTML5
    MediaElement API for older browsers
  * Accessibility standards including WebVTT

Of those, the first point is not Javascript at all, the second is not
working at all, so your argument must be related to the third somehow.

Please elaborate!!


 - Jonas

severity 760297 grave
thanks

Quoting Jonas Smedegaard (2014-09-03 13:37:23)

Let's not complicate matters by allowing this package to enter testing,
until we agree that it is suitable for general use.


 - Jonas

Quoting Debian Bug Tracking System (2014-09-04 23:24:05)

I ask a question - you just silently play severity ping-pong here.

That pisses me off.

What do others in the team think of this bug?

If this is the quality of packaging in this team, I seriously consider
no longer wasting my time here.


 - Jonas

Le vendredi 05 septembre 2014 à 01:21 +0200, Jonas Smedegaard a écrit :

I agree mediaelementjs cannot go into testing like this - at least not
without a better reason than "it's too hard to properly package half of
it".
If that's really the case - the plugins cannot be recreated from source
without a crazy deal of work - package them in non-free and put
mediaelementjs in contrib.

Jérémy.

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.

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.

I find your behaviour off limit.

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

Quoting David Prévot (2014-09-05 03:57:02)

...and I pointed out how that reference did not answer the question.

Yes, that's an option if we cannot work as a team.  Or one of us can
leave the team.

Removing (all or some of) MediaElement from wordpress and owncloud
packages do not render those packages "mostly useless" by their users.

Whether that is also true for the js-mediaelement package depends on
answer to my question.
MediaElement is completely missing do owncloud then no longer allow
playing video and audio in a [modern] browser?

Ftpmaster approval relates to legality, and therefore irrelevant for
this discussion on qualitative assesment of the package.

Great that there is hope that MediaElement some day can make sense to
package.

Hence the question if the approach you considered "attractive" produces
relevant result for our users: Do we currently ship the main
functionality of MediaElement or a smaller/different subset than that?

Can you please elaborate on that question.


 - Jonas

severity 760297 grave
thanks

Quoting Jérémy Lal (2014-09-05 01:37:37)

[David wrote - via control@bugs.debian.org:]

I fully agree.

Maintainer of this package is the Javascript team

Reason for grave severity is to keep this package from entering testing,
because it is considered unsuitable in its current form (sorry if that
was somehow unclear from my previous posts).

Thanks for your input, Jérémy.

 - Jonas

retitle 760297 libjs-mediaelement: should (build and) ship Flash or Silverlight parts
thanks

Point of this bug is a) that the package is useless without those parts
(hence "should" instead of "please") and need only one of the fallbacks
for proper media element implementations (hence "or" instead of "and").

Also, titles should generally be prefixed with their package name.

 - Jonas

Control: severity -1 important

Really, again?

That’s fixed now, thanks again to your valuable input.

https://anonscm.debian.org/cgit/pkg-owncloud/mediaelement.git/commit/?id=d1f88116baff56bb4ae1c5ed54529b6905bcef8d

Regards

David

Quoting David Prévot (2014-09-05 15:05:50)

I would certainly prefer dialogue.  Sadly you apparently treat my
question (at bottom of <https://bugs.debian.org/760297#21>) as
"flamebait".

Sad that you choose that over teamwork.

Make an official Debian package release which includes above git commit,
and I shall stop consider myself co-maintainer of the package.

I still look forward to your answer to https://bugs.debian.org/760297#21


 - Jonas