Closed GoogleCodeExporter closed 8 years ago
Issue #34 needs to be fixed before release.
Original comment by david.g.hoyt
on 8 Apr 2010 at 5:19
Because I don't want to delay the release any further, I'm removing speex +
associated plugins from the installers. Once it's fixed it will be added back
in.
Original comment by david.g.hoyt
on 8 Apr 2010 at 11:06
The first release candidate (RC01) has been uploaded. It includes the latest
dependency update.
Original comment by david.g.hoyt
on 9 Apr 2010 at 12:03
Let's leave the farsight updates until after the release. It's been too long
since
our last release and the last major gstreamer releases.
Original comment by david.g.hoyt
on 9 Apr 2010 at 12:16
One last thing regarding the SDK. It seems that we are not including the .pc
files
with the right path. I'll take a look at it tomorrow. A simple port-install .bat
using sed with the pc templates should do the job. It's important for developers
using mingw/msys :)
Original comment by ylatuya
on 9 Apr 2010 at 12:20
Tomorrow I'll also add a closing notice on the wiki redirecting all to this
site :)
Original comment by ylatuya
on 9 Apr 2010 at 12:22
The templates for the gstreamer's .pc files are also missing. We should add
them too
before the release
Original comment by ylatuya
on 9 Apr 2010 at 3:45
In order to be compatibles with mingw/msys we need:
* Add gstreamer's .pc templates
* Add .pc files to the SDK installer
* Add .la files to the SDK installer (this is not mandatory since gcc can link
against the dll's)
The Python bindings installer needs also to be fixed, take a look at
http://code.google.com/p/ossbuild/source/browse/trunk/Packaging/Win32/Python/pyt
hon_bindings.iss
to see how it needs to be deployed.
Original comment by ylatuya
on 9 Apr 2010 at 10:41
Package config and libtool files pose a bit of a challenge in MSI packages due
to
the file manipulation that would have to take place. Also, we wouldn't know
where to
install them to since the mingw installation could be anywhere on disk and it
doesn't provide any registry entries that we can read to determine its
installation
directory.
Originally my intent was to provide these packages for Windows developers. And
to
that end eventually I'd like to see complete integration with Visual Studio
including GStreamer projects that one could create to get off the ground
running.
But for now I'm unsure how we should proceed.
Regarding the python bindings, what is it in particular that's not being
followed? I
tried to match that as best I could when I originally created the installers.
Original comment by david.g.hoyt
on 10 Apr 2010 at 4:47
dshowvideosrc has issues. If you stop and start it several times very quickly
it
freezes (deadlocks). directdrawsink doesn't have that problem. I haven't
pinpointed
the exact cause and not being a direct show guru, it's unlikely I'll be able to
do
so.
So -- I recommend that directdrawsink be primary until dshowvideosrc can be
properly
fixed.
Original comment by david.g.hoyt
on 10 Apr 2010 at 7:00
Yes let's do that. That might be the cause
https://bugzilla.gnome.org/show_bug.cgi?
id=579926#c15
Original comment by ylatuya
on 10 Apr 2010 at 7:34
>Package config and libtool files pose a bit of a challenge in MSI packages due
to
>the file manipulation that would have to take place. Also, we wouldn't know
where to
>install them to since the mingw installation could be anywhere on disk and it
>doesn't provide any registry entries that we can read to determine its
installation
>directory.
You don't need to know where MSYS was installed. You can install it in the SDK
folder, since you can do 'export PKG_CONFIG_PATH=/c/Program
Files/OSSBuild/GStreamer/v0.16/sdk/lib/pkgconfig'.
Can't you add a post-install script which 'sed' the lib/pkgconfig folder and
replace
the values in the templates with the installation path?
Original comment by ylatuya
on 10 Apr 2010 at 7:35
>Regarding the python bindings, what is it in particular that's not being
followed? I
>tried to match that as best I could when I originally created the installers.
You should execute the installer and see how it's deployed.
1) Defs and examples should be deployed in share/gst-python/0.10/examples and
share/gst-python/0.10/defs
2) Binaries should be deployed in lib/site-packages/gst/gst-0.10/
3) pygst.py should be deployed in lib/site-packages/
4) gstlibtoolimporter.py is missing and should be deployed in lib/site-
packages/gst/gst-0.10/
5) entends are also missing and should be deployed in lib/site-packages/gst/gst-
0.10/extend
6) __init__.py is missing in lib/site-packages/gst/gst-0.10/
pygst.py needs to be patched, I'll try to integrate it in the build cleanly.
Original comment by ylatuya
on 10 Apr 2010 at 7:57
Can you check before the release why iconv.dll was overwritten wihtout the
libiconv
support?
)http://code.google.com/p/ossbuild/source/detail?r=386&path=/trunk/Libraries/Bui
ld-All-Windows-x86.sh)
The one in trunk only export iconv* symbols and the patch was to enable also
libconv*
symbols for compatibility with gnuiconv.
Original comment by ylatuya
on 13 Apr 2010 at 1:21
This the layout that should be used to deploy python:
./pygst.py
./gst-0.10
./gst-0.10/gst
./gst-0.10/gst/extend
./gst-0.10/gst/extend/discoverer.py
./gst-0.10/gst/extend/jukebox.py
./gst-0.10/gst/extend/leveller.py
./gst-0.10/gst/extend/pygobject.py
./gst-0.10/gst/extend/sources.py
./gst-0.10/gst/extend/utils.py
./gst-0.10/gst/extend/__init__.py
./gst-0.10/gst/audio.pyd
./gst-0.10/gst/farsight.pyd
./gst-0.10/gst/interfaces.pyd
./gst-0.10/gst/pbutils.pyd
./gst-0.10/gst/tag.pyd
./gst-0.10/gst/video.pyd
./gst-0.10/gst/_gst.pyd
./gst-0.10/gst/__init__.py
./share
./share/gst-python
./share/gst-python/0.10
./share/gst-python/0.10/defs
./share/gst-python/0.10/defs/audio.defs
./share/gst-python/0.10/defs/base.defs
./share/gst-python/0.10/defs/gst-extrafuncs.defs
./share/gst-python/0.10/defs/gst-types.defs
./share/gst-python/0.10/defs/gst.defs
./share/gst-python/0.10/defs/interfaces.defs
./share/gst-python/0.10/defs/libs.defs
./share/gst-python/0.10/defs/pbutils.defs
./share/gst-python/0.10/defs/tag.defs
./share/gst-python/0.10/defs/video.defs
./share/gst-python/0.10/defs/xoverlay.defs
./share/gst-python/0.10/examples
./share/gst-python/0.10/examples/audio-controller.py
./share/gst-python/0.10/examples/audioconcat.py
./share/gst-python/0.10/examples/bps.py
./share/gst-python/0.10/examples/cp.py
./share/gst-python/0.10/examples/debugslider.py
./share/gst-python/0.10/examples/decodebin.py
./share/gst-python/0.10/examples/f2f.py
./share/gst-python/0.10/examples/filesrc.py
./share/gst-python/0.10/examples/fvumeter.py
./share/gst-python/0.10/examples/gst-discover
./share/gst-python/0.10/examples/gstfile.py
./share/gst-python/0.10/examples/mixer.py
./share/gst-python/0.10/examples/pipeline-tester
./share/gst-python/0.10/examples/play.py
./share/gst-python/0.10/examples/remuxer.py
./share/gst-python/0.10/examples/sinkelement.py
./share/gst-python/0.10/examples/vumeter.py
All the .py .defs files can be copyed from the gst-python sources, except for
./pygst.py which I have stored in
Main\GStreamer\Windows\Build\Bindings\Python\pygst.py (should this be stored in
the
Windows\Install\ ?)
The .pyd are the ones that we build.
The installer should also update/create the PYTHONPATH environment variable
and add
the deployment folder.
Original comment by ylatuya
on 14 Apr 2010 at 7:35
It should be:
./lib
./lib/site-packages
./lib/site-packages/gst-0.10
./lib/site-packages/gst-0.10/gst
./lib/site-packages/gst-0.10/gst/extend
./lib/site-packages/gst-0.10/gst/extend/discoverer.py
./lib/site-packages/gst-0.10/gst/extend/jukebox.py
./lib/site-packages/gst-0.10/gst/extend/leveller.py
./lib/site-packages/gst-0.10/gst/extend/pygobject.py
./lib/site-packages/gst-0.10/gst/extend/sources.py
./lib/site-packages/gst-0.10/gst/extend/utils.py
./lib/site-packages/gst-0.10/gst/extend/__init__.py
./lib/site-packages/gst-0.10/gst/audio.pyd
./lib/site-packages/gst-0.10/gst/farsight.pyd
./lib/site-packages/gst-0.10/gst/interfaces.pyd
./lib/site-packages/gst-0.10/gst/pbutils.pyd
./lib/site-packages/gst-0.10/gst/tag.pyd
./lib/site-packages/gst-0.10/gst/video.pyd
./lib/site-packages/gst-0.10/gst/_gst.pyd
./lib/site-packages/gst-0.10/gst/__init__.py
./lib/site-packages/gst-0.10/gst/__init__.pyc
./lib/site-packages/pygst.py
./share
./share/gst-python
./share/gst-python/0.10
./share/gst-python/0.10/defs
./share/gst-python/0.10/defs/audio.defs
./share/gst-python/0.10/defs/base.defs
./share/gst-python/0.10/defs/gst-extrafuncs.defs
./share/gst-python/0.10/defs/gst-types.defs
./share/gst-python/0.10/defs/gst.defs
./share/gst-python/0.10/defs/interfaces.defs
./share/gst-python/0.10/defs/libs.defs
./share/gst-python/0.10/defs/pbutils.defs
./share/gst-python/0.10/defs/tag.defs
./share/gst-python/0.10/defs/video.defs
./share/gst-python/0.10/defs/xoverlay.defs
./share/gst-python/0.10/examples
./share/gst-python/0.10/examples/audio-controller.py
./share/gst-python/0.10/examples/audioconcat.py
./share/gst-python/0.10/examples/bps.py
./share/gst-python/0.10/examples/cp.py
./share/gst-python/0.10/examples/debugslider.py
./share/gst-python/0.10/examples/decodebin.py
./share/gst-python/0.10/examples/f2f.py
./share/gst-python/0.10/examples/filesrc.py
./share/gst-python/0.10/examples/fvumeter.py
./share/gst-python/0.10/examples/gst-discover
./share/gst-python/0.10/examples/gstfile.py
./share/gst-python/0.10/examples/mixer.py
./share/gst-python/0.10/examples/pipeline-tester
./share/gst-python/0.10/examples/play.py
./share/gst-python/0.10/examples/remuxer.py
./share/gst-python/0.10/examples/sinkelement.py
./share/gst-python/0.10/examples/vumeter.py
The reason to use this layout is because the user can choose to install it under
c:\Python25 and everything will be integrated with the python installation.
Adding the PYTHONPATH variable might not be a good idea...
Original comment by ylatuya
on 14 Apr 2010 at 7:41
[deleted comment]
I reintroduced your iconv.dll, but I think the correct solution will require a
complete rebuild of all libs using iconv.dll. The idea, as I understand it, is
that
the win iconv pkg allows you to put in iconv.dll if you want to. Otherwise it's
meant to be statically linked to those dlls that think they need it.
Original comment by david.g.hoyt
on 16 Apr 2010 at 5:22
I'm not familiar w/ the python bindings at all -- if pygst.py is a customized
version of an existing file, it needs to have a patch in the
Main/GStreamer/Source/patches/ directory and should be submitted upstream. If
it
doesn't exist, then where you have it is fine unless it might be needed on
linux/other OSes - in which case we'll have to talk about it further. If it's
installer-related only it should be in Main/GStreamer/Windows/Install/ (as in
files
actually used to create the installer).
Also you mention in comment #13 that gstlibtoolimporter.py is needed, but I
don't
see it in your lists above. Is it still needed?
As for the msys integration -- I don't think that'll make it into this release
unless you can find the time to do it. But perhaps the next one. In Windows
installers, those kinds of tasks require a custom action and it's easier said
than
done. There are some open source projects that will do what we need, but it'll
take
me too much time to learn and integrate them for this release.
I believe the gstreamer folks or almost ready for a new release any day now,
and I
don't want to be lagging behind so badly w/ our own release. But I do think in
the
future we'll be a lot better since we'll have these growing pains all worked
out.
That said, I think after the new gstreamer release we should do a quick release
of
our own (v0.10.6.2 or something of that nature) and then start focusing on x64
support which I think will end up being fairly difficult and will probably
require
even more patches than we have now for win32. The msys/mingw package that's
provided
includes a gcc 4.4.3 x64 cross compiler, so we should be able to hit the ground
running w/ that. That was very much on purpose. (c:
Original comment by david.g.hoyt
on 16 Apr 2010 at 7:03
Hi,
I deleted your message by mistake ;)
The idea of compiling iconv with this flag is that it enables
cross-compatibility
wince it's exports both iconv* and libiconv*, thus it's compatible with
win_iconv and
gnuiconv
Original comment by ylatuya
on 16 Apr 2010 at 9:47
I think we should release ASAP and take care of the rest on a another "bugfix"
release. You have done a great job with the installers and the following
releases
should go smoothly ;)
glibtoolimporter.py is not needed for Python for the moment. pygst.py is
generated
from pygst.py.in y can integrate it in the Generate.bat script if you want, but
this
file won't change anymore, at least until the next GStreamer major version
release :)
Original comment by ylatuya
on 16 Apr 2010 at 9:50
How were you able to get the libiconv* symbols in iconv.dll? No matter what I
did I
couldn't get them in there short of writing my own code for it or patching the
existing code. I saw nothing in there that exported any libiconv*
function/variable.
And when you ran the script as it was, it produced the exact same output that
was in
the repo. I don't think the iconv* symbols were supposed to be there at all.
Instead
I think other libs were supposed to statically link those functions. The
-DUSE_LIBICONV_DLL allows you to use iconv.dll if you have it available,
otherwise it
uses a default implementation.
Original comment by david.g.hoyt
on 16 Apr 2010 at 3:56
If I open inconv.dll from r386
(http://code.google.com/p/ossbuild/source/browse/trunk/Shared/Build/Windows/Win3
2/bin/iconv.dll?spec=svn386&r=386)
with Dependency Walker I can see these symbols exported:
_libiconv_version
iconv
iconv_close
iconv_open
libiconv
libiconv_close
libiconv_open
libiconv_set_relocation_prefix
libiconvctl
libiconvlist
locale_charset
That makes this lib comptabile with both implementations. This way a dll
linking to
iconv and using iconv_open and another dll using libiconv_open can both use the
same
iconv.dll.
Original comment by ylatuya
on 17 Apr 2010 at 1:33
The readme in win_iconv says:
"I just added some small bits:
the trivial iconv.h header, the win_iconv_dll.c wrapper that makes it
possible to build win_iconv.c into a DLL that has the same API and ABI
as GNU libiconv, the Makefile."
The tricky part is in:
#if defined(USE_LIBICONV_DLL)
static int
libiconv_iconv_open(rec_iconv_t *cd, const char *fromcode, const char *tocode)
If USE_LIBICONV_DLL is not defined this function will never be exported, and
this
function does the mapping from libiconv to iconv
Original comment by ylatuya
on 17 Apr 2010 at 1:50
I used what you had defined w/ -DUSE_LIBICONV_DLL and it was not exporting
those
symbols. You typically need to specify an external symbol with dllexport. Run
that
portion of the script and see if you get a dll w/ all the symbols you mentioned.
As I was saying, I believe win_iconv is meant to be statically linked meaning
there
should be no iconv.dll at all. However, if you have the gnu one, it will pick
it up
and use it. Please see the description about it here under "About win_iconv":
http://www.gtk.org/download-windows.html
If you want to use win_iconv_dll, I believe that's separate and I'm unsure
where the
source is -- but that's not what's in our packages.
Original comment by david.g.hoyt
on 17 Apr 2010 at 7:11
What the about says is the win_iconv is statically linked to GLib and thus is
not
needed, but if you read the iconv.dll about it says:
"This can either be the GNU libiconv iconv.dll, or the identically named
win_iconv_dll one which obviosuly is intented to be a drop-in replacement."
So both of them can be used as a dynamic dll.
When win_iconv is compiled with the USE_LIBICONV_DLL, it will export libiconv*,
or at
least this is what I got in r386 and:
"* If $WINICONV_LIBICONV_DLL environment variable was defined, win_iconv
* loads the specified DLL dynamically and uses it. If loading the DLL
* or iconv_open() failed, falls back to internal conversion.
"
Since this env variable is not defined it will fallback to the internal
conversion.
Anyway the problem we are facing is much simpler to solve. Since win_iconv is
for
static linking we should use gnu_iconv. The problem we have currently is that
our
iconv.dll exports iconv* and the gstreamer binaries binaries are expecting an
iconv.dll exporting iconv* funtions, but other FOSS projects like GTK are
expecting
an iconv.dll exporting libiconv*, and therefore our binaries are incompatibles
with
other projects. So waht we are doing wrong is using win_iconv to generate a
dynamic
dll and using gnu_iconv would solve it.
Original comment by ylatuya
on 18 Apr 2010 at 7:45
As I've been saying, **compile it yourself** -- it's not exporting those
functions
using the gcc 4.4.3 that I'm using. I see in the source where it has the
functions,
but I also don't see an extern C anywhere nor a dll export. Therefore it makes
sense
that it's not exporting the functions. If you modified the source to export it,
then
a patch needs to be provided.
The GTK folks say glib and related libs will be using win iconv so we should
continue to use it.
I fail to see after reading your comment how what I said before was in any way
incorrect or a misunderstanding. I know and understand what other FOSS projects
expect and what I'm telling you is that the script you modified is in some way
wrong
or the compiler I'm using for some reason does not pick up the exports because
the
required functions are not being exported as per the original intent of r386.
Please examine the source in the package and the output after compiling it.
Original comment by david.g.hoyt
on 19 Apr 2010 at 9:06
I would be happy if someone else could compile the iconv portion and confirm
that
I'm not crazy. :) Well I suppose I could still be crazy, but at least not about
this
issue. :p
Original comment by david.g.hoyt
on 19 Apr 2010 at 9:09
I must be the crazy one :) I have misunderstood all the win_iconv thingy and
indeed
it's impossible that those symbols where exported with the current code. I
don't know
what the hell I did to build this dll :/
win_iconv is supposed to be be linked statically (as glib do) and indeed the
USE_LIBCONV_DLL flag won't export any of those symbols but will try to load an
existing inconv.dll an map iconv_* to libiconv_* to use gnu iconv for the
conversion.
From my point of view we have 2 options:
* use win_iconv and link it statically
* use gnu_iconv to build iconv.dll
What do you think?
Original comment by ylatuya
on 19 Apr 2010 at 10:31
For instance
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/win-iconv-dll_tml-200
90213_win32.zip
exports:
_libiconv_version
libiconv
libiconv_close
libiconv_open
libiconv_set_relocation_prefix
libiconvctl
libiconvlist
locale_charset
Original comment by ylatuya
on 19 Apr 2010 at 10:32
I'm not crazy either ;)
http://win-iconv.googlecode.com/svn-history/trunk/iconv.def
Original comment by ylatuya
on 19 Apr 2010 at 10:37
Okay, I have an updated installer w/ the python fixes. Please validate that it
does
the job. You'll notice that it installs it in the C:\Program Files\OSSBuild\...
folder instead of C:\Python25\. That's due to the feature selection in the MSI
package and working it out right now would take too much time and I'd like to
roll
out this release ASAP. We can get it working for the next release perhaps. At
any
rate, if you go into the install folder, you'll see that you can copy
everything you
need from the <Install Folder>\sdk\bindings\python\v2.5\ directly into
C:\Python25\.
I know it's not ideal, but for now I'm setting the PYTHONPATH env. variable.
That
may end up being the most intuitive thing to do, though, b/c a lot of users
might
not know or even think to set the path to C:\Python25\ if that feature were
even
available.
I also prefer to keep the SDK install without any selectable folder b/c it
automatically detects and knows where to install based off of the
previous "complete" install.
Anyway, you can download and test the packages here:
http://code.google.com/p/ossbuild/downloads/detail?name=GStreamer-WinBuilds-GPL-
x86.zip
Original comment by david.g.hoyt
on 24 Apr 2010 at 8:03
Also, from what I can tell, the farsight binding should be lib/site-
packages/farsight/farsight.pyd
Is that correct?
Original comment by david.g.hoyt
on 24 Apr 2010 at 8:06
I will try it in a couple of ours, so that we can release tomorrow.
Original comment by ylatuya
on 24 Apr 2010 at 11:53
Someone asked about the fluendo plugins. What should we do? Shouldn't Fluendo
itself
be the ones to provide them? If they're looking at integrating w/ us anyway,
then
they can easily enough write an intaller that locates our install directory and
then
installs their plugins.
But I don't think we should be building their plugins.
Just my $0.02.
Original comment by david.g.hoyt
on 24 Apr 2010 at 7:22
There is small issue in the bindings installer. It should use
Main\GStreamer\Windows\Build\Bindings\Python\pygst.py and not the one included
in the
sources
Original comment by ylatuya
on 24 Apr 2010 at 7:55
I think we should not include the Fluendo plugins either.
Some time ago Fluendo had 3 free plugins (mpeg demuxer mpeg muxer and
mp3decoder).
Currently all the improvements in the mpeg muxer/demuxer are available upstream
and
there is no need to include them. I think Fluendo hasn't made a public release
for
years, and those plugins should be considered obsolete.
So agreed, we shouldn't include them.
Original comment by ylatuya
on 24 Apr 2010 at 8:04
There is another issue with the Python installer. PYTHONPATH should point to
where
'pygst.py' has been deployed. The reason why I wouldn't set this variable is
that you
would have to include both the python25 and the python26 folders. Depending on
which
version of python you are using it will load the wrong the pygst bindings.
Original comment by ylatuya
on 25 Apr 2010 at 6:19
I understand that, but what's the most likely version of python that people
will be
using? I figure w/ python being in the 3.1 series, that python 2.6 would be a
prudent stable version to support. The installer by default is installing the
2.6
bindings. v2.5 is still available in the <Install
Path>\sdk\bindings\python\v2.5\
directory, however, if a user needs it.
I can't see us trying to maintain any number of python versions. That becomes
really
difficult to manage. It wouldn't be such a big deal, I don't think, if the
python
folks didn't keep changing the name of the python shared library with every
minor
release.
Perhaps in the future we can enhance the installer to detect python
installations
and allow the user to select where they want the bindings installed. But not
for
this release.
On another note -- shall I delete the fluendo source in the repo.?
Original comment by david.g.hoyt
on 26 Apr 2010 at 3:17
>On another note -- shall I delete the fluendo source in the repo.?
We could delete the sources but I wouldn't delete the project files in case
some one
would want to use it.
Original comment by ylatuya
on 26 Apr 2010 at 7:23
Done.
Original comment by david.g.hoyt
on 26 Apr 2010 at 8:41
There's not a reason to leave the project files, b/c if someone needs them,
they can
go back into the repo.'s history and pull them out.
Original comment by david.g.hoyt
on 26 Apr 2010 at 11:22
I think it's time to do the release even w/ the known issues. The ones I know
about
are:
* Speex crash
* rtph264pay crash
* svq1 crash
BTW, gstreamer has a new release so we'll need to upgrade ASAP and come out w/
a
point release (0.10.6.1?).
Original comment by david.g.hoyt
on 1 May 2010 at 7:52
If RC02 seems acceptable I'll change the file names and release that.
Original comment by david.g.hoyt
on 1 May 2010 at 7:54
I think it's time to release!!!!!
I think no more changes were added after RC02 so we should just rename it :D
Kudos to you!
Original comment by ylatuya
on 2 May 2010 at 3:15
Kudos to everyone. :)
Original comment by david.g.hoyt
on 3 May 2010 at 3:52
Time to close this out.
Original comment by david.g.hoyt
on 6 May 2010 at 7:38
Original issue reported on code.google.com by
david.g.hoyt
on 8 Apr 2010 at 12:03