Bug#738849: Please enable webview support for wx3.0
Hi dear Olly, Il Sabato 24 Maggio 2014 15:31, Olly Betts o...@survex.com ha scritto: I've just discovered an annoying consequence of this change. If you now install libwxgtk3.0-dev and ask for libraries to link with, you get: $ wx-config --libs -L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_webview-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 Note that this includes -lwx_gtk2u_webview-3.0, but that's not installed, so linking fails. The same thing happens if you ask for an explicit list of libraries and include std in that list. This is pretty serious as it's likely to cause packages to FTBFS. Some options I can see for fixing this and their downsides: * Make libwxgtk3.0-dev depend on libwxgtk-webview3.0-dev - this would pull in libwxgtk-webview3.0-0 and hence webkit for such builds; it may also sometimes end up with webkit getting unnecessarily included as a runtime dependency, for packages which don't link with -Wl,--as-needed. This seems ugly, at least on debian (no changes on ubuntu, I wonder if debian will ever se them as default) * Alter the meaning of std in wx-config - makes it behave differently on Debian to elsewhere. This is something I didn't understand correctly, but I think I did something similar * Update all packages to explicitly request the wx component libraries they actually need - significant fiddly work, but perhaps the way forwards. This seems to require a lot of uploads... I'm attaching a little patch I did to make wx-webview behave a more little closer than wx-media... However I'm stuck with a little problem: how can I use wx-config to export wx-media libraries? I think we can make it return wx-webview only if the library is found on the system, with this patch I made webview optional, next step is to understand how wx-config really works (I fall asleep before understanding it completely). I see wx-config already have some loops inside looking for libraries on the system, my approach will return the flags only if found on the system, and since this webview is marked as mandatory but seems optional I think we can push this patch also upstream. Is that what you intended in #2? for me if I can fix this last problem we can ask even for an upstream inclusion. Do you want to let this package reach testing? maybe reopening and reassignig the severity will prevent automatic rebuild failures... what do you think? cheers, Gianfranco Any better ideas? Cheers, Olly debdiff Description: Binary data debdiff Description: Binary data
Bug#738849: Please enable webview support for wx3.0
On Sun, May 25, 2014 at 09:17:51AM +0100, Gianfranco LocutusOfBorg Costamagna wrote: Hi dear Olly, Il Sabato 24 Maggio 2014 15:31, Olly Betts o...@survex.com ha scritto: I've just discovered an annoying consequence of this change. If you now install libwxgtk3.0-dev and ask for libraries to link with, you get: $ wx-config --libs -L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_webview-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 Note that this includes -lwx_gtk2u_webview-3.0, but that's not installed, so linking fails. The same thing happens if you ask for an explicit list of libraries and include std in that list. This is pretty serious as it's likely to cause packages to FTBFS. Some options I can see for fixing this and their downsides: * Make libwxgtk3.0-dev depend on libwxgtk-webview3.0-dev - this would pull in libwxgtk-webview3.0-0 and hence webkit for such builds; it may also sometimes end up with webkit getting unnecessarily included as a runtime dependency, for packages which don't link with -Wl,--as-needed. This seems ugly, at least on debian (no changes on ubuntu, I wonder if debian will ever se them as default) It's ugly even without the --as-needed issue as it bloats the BDs for every package building with wx GUI libraries which doesn't use wxWebView (which is likely to be most of them). * Update all packages to explicitly request the wx component libraries they actually need - significant fiddly work, but perhaps the way forwards. This seems to require a lot of uploads... Probably - only packages which explicitly list the component libraries they need (and don't ask for std) will continue to work. * Alter the meaning of std in wx-config - makes it behave differently on Debian to elsewhere. This is something I didn't understand correctly, but I think I did something similar So wx-config --libs will output the flags needed to link particular component libraries. You can optionally provide a list of them, which can include std. If there's no list, the default list of just std is assumed. Without webview enabled (i.e. in 3.0.0-2), std expands to: xrc html qa adv core xml net base With webview enabled (i.e. in 3.0.0-3), std expands to: xrc webview html qa adv core xml net base Note that this doesn't include all component libraries (e.g. media isn't included, you have to request that explicitly), so my idea was just to move webview to the same status as media. The issue with this is that wx-config is then incompatible for applications which use wxWebView, though applications can just use --libs std,webview to work with both. It seems unhelpful for libraries which aren't enabled if you build wxWidgets from source with the default --enable and --with option to be in std. So I think this might be a fix to suggest to upstream (wxWebView is new, so making this change in 3.0.1 might be viewed as reasonable). I'm attaching a little patch I did to make wx-webview behave a more little closer than wx-media... However I'm stuck with a little problem: how can I use wx-config to export wx-media libraries? wx-config --libs std,media (As noted above, media isn't in std). I think we can make it return wx-webview only if the library is found on the system, with this patch I made webview optional, next step is to understand how wx-config really works (I fall asleep before understanding it completely). That's an interesting idea. It means that wx-config behaves compatibly to a build without webview enabled if libwx-webview3.0-dev isn't installed, which is less surprising. I see wx-config already have some loops inside looking for libraries on the system, my approach will return the flags only if found on the system, and since this webview is marked as mandatory but seems optional I think we can push this patch also upstream. wx-config is generated at configure time (from wx-config.in), and if you don't enable webview, then wx-config won't have it in its list of libraries to expand std to. So such a patch wouldn't really make sense for upstream, as they have a mechanism to handle this already for those building from source. Do you want to let this package reach testing? maybe reopening and reassignig the severity will prevent automatic rebuild failures... I did that, though I notice that it's not currently blocking transition as the found version is already in testing. I'll open a new bug in a moment. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
I've just discovered an annoying consequence of this change. If you now install libwxgtk3.0-dev and ask for libraries to link with, you get: $ wx-config --libs -L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_webview-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 Note that this includes -lwx_gtk2u_webview-3.0, but that's not installed, so linking fails. The same thing happens if you ask for an explicit list of libraries and include std in that list. This is pretty serious as it's likely to cause packages to FTBFS. Some options I can see for fixing this and their downsides: * Make libwxgtk3.0-dev depend on libwxgtk-webview3.0-dev - this would pull in libwxgtk-webview3.0-0 and hence webkit for such builds; it may also sometimes end up with webkit getting unnecessarily included as a runtime dependency, for packages which don't link with -Wl,--as-needed. * Alter the meaning of std in wx-config - makes it behave differently on Debian to elsewhere. * Update all packages to explicitly request the wx component libraries they actually need - significant fiddly work, but perhaps the way forwards. Any better ideas? Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Il Venerdì 2 Maggio 2014 3:37, Olly Betts o...@survex.com ha scritto: On Fri, May 02, 2014 at 01:58:16AM +0100, Gianfranco LocutusOfBorg Costamagna wrote: I already added you export line at the bottom (please see my commit on github) https://github.com/LocutusOfBorg/wx/commit/15e8f7d106298109e58a2a3c8bf8add0b3001aa7 Hi again, One problem is that: +export DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --get LDFLAGS should be: +export DEB_LDFLAGS_APPEND=-Wl,--as-needed But it seems the real issue is actually that the export doesn't happen before the $(shell dpkg-buildflags --export=configure) gets expanded. A simple fix is to just specify it there directly: $(shell DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --export=configure) yes, that one did the trick, thanks! should be good enough :) so I also checked the webkitgtk build archs, and seems to be supported on every arch, but *not* on gnu hurd (failng to build) https://buildd.debian.org/status/package.php?p=webkitgtksuite=sid is this a problem? hurd shouldn't be a release architecture, and shouldn't prevent the testing migration. what do you think? I hope they'll fix soon the hurd build failure, thanks, Gianfranco Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
On Fri, May 02, 2014 at 07:43:47AM +0100, Gianfranco Costamagna wrote: so I also checked the webkitgtk build archs, and seems to be supported on every arch, but *not* on gnu hurd (failng to build) https://buildd.debian.org/status/package.php?p=webkitgtksuite=sid Oh yes, an important consideration. is this a problem? hurd shouldn't be a release architecture, and shouldn't prevent the testing migration. I think it isn't something to worry about too much. And older versions of webkitgtk have built OK on hurd, so I'd guess it's not anything fundamental. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Il Giovedì 1 Maggio 2014 0:32, Olly Betts o...@survex.com ha scritto:
On Wed, Apr 30, 2014 at 07:34:03PM +0100, costamagnagianfra...@yahoo.it
wrote:
Il Mercoledì 30 Aprile 2014 12:39, Olly Betts o...@survex.com
ha scritto:
On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna
wrote:
Isn't the -Wl,--as-needed automatically passed by
dh
system? are you
overriding LDFLAGS somewhere?
I don't believe either is true. Passing it unconditionally
wouldn't be
a good plan, as it breaks some cases (as I mentioned above).
Are you perhaps thinking of -Wl,-z,relro (which is related
to
hardening)?
ok can it be that ubuntu enables them by default and debian not?
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
I don't follow Ubuntu development these days, but possibly.
ubuntu is using them since three years, and why should removing a not
used library be a problem?
I mean if no symbols are used we can drop safely right?
It isn't always safe to do so - you can get a clean build but hit
problems at runtime. For example a program might use dlsym() to look up
a symbol from a library it was linked against, but if there aren't any
references at link time, the library won't be there if --as-needed is
used:
olly@gemse:~$ cat asneeded.c
#include dlfcn.h
#include stdio.h
int main(int argc, char ** argv) {
void * handle = dlopen(NULL, RTLD_NOW);
if (!handle) {
fprintf(stderr, dlopen failed: %s\n, dlerror());
return 1;
}
(void)argc;
while (*++argv) {
printf(%s=%p\n, *argv, dlsym(handle, *argv));
}
return 0;
}
olly@gemse:~$ gcc -Wall -W -O2 asneeded.c -ldl -lz -o asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=0x7fc6e04a9fc0
olly@gemse:~$ gcc -Wall -W -O2 -Wl,--as-needed asneeded.c -ldl -lz -o
asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=(nil)
Lol, please look what happens on my ubuntu saucy machine
gcc -Wall -W -O2 as.c -ldl -lz
./a.out zlibVersion
zlibVersion=(nil)
gcc -Wall -W -O2 -Wl,--as-needed as.c -ldl -lz
./a.out zlibVersion
zlibVersion=(nil)
So should be harmless because I didn't see a ton of bug reports on ubuntu for
this :)
Thanks for teaching me this, I wasn't aware of the dlopen possibility
Can we safely leave them inside?
The patch is so ugly, but the libraries are not there anymore
https://github.com/LocutusOfBorg/wx/commit/e18d875c355096e458371d7f83910d02c926c294
A much cleaner way is just to add this to debian/rules instead of the
above changes:
export DEB_LDFLAGS_APPEND=-Wl,--as-needed
Oh yes, I was aware of something like this, but I forgot the exact syntax and
slipped out of my mind...
Should be fixed and ready now!
https://github.com/LocutusOfBorg/wx/commit/7ad7d5974db86f62b805c33ef6d61e6d25dd
Attached the log of the new debdiffs
Great, that looks much better to me. Thanks for all your work on this.
Thanks to you! I have still too much to learn from debian and you all :)
(I'm rebuilding right now)
Cheers,
Olly
Have a nice day,
Gianfranco
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Hi again Olly
Il Giovedì 1 Maggio 2014 0:32, Olly Betts o...@survex.com ha scritto:
On Wed, Apr 30, 2014 at 07:34:03PM +0100, costamagnagianfra...@yahoo.it
wrote:
Il Mercoledì 30 Aprile 2014 12:39, Olly Betts o...@survex.com
ha scritto:
On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna
wrote:
Isn't the -Wl,--as-needed automatically passed by
dh
system? are you
overriding LDFLAGS somewhere?
I don't believe either is true. Passing it unconditionally
wouldn't be
a good plan, as it breaks some cases (as I mentioned above).
Are you perhaps thinking of -Wl,-z,relro (which is related
to
hardening)?
ok can it be that ubuntu enables them by default and debian not?
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
I don't follow Ubuntu development these days, but possibly.
ubuntu is using them since three years, and why should removing a not
used library be a problem?
I mean if no symbols are used we can drop safely right?
It isn't always safe to do so - you can get a clean build but hit
problems at runtime. For example a program might use dlsym() to look up
a symbol from a library it was linked against, but if there aren't any
references at link time, the library won't be there if --as-needed is
used:
olly@gemse:~$ cat asneeded.c
#include dlfcn.h
#include stdio.h
int main(int argc, char ** argv) {
void * handle = dlopen(NULL, RTLD_NOW);
if (!handle) {
fprintf(stderr, dlopen failed: %s\n, dlerror());
return 1;
}
(void)argc;
while (*++argv) {
printf(%s=%p\n, *argv, dlsym(handle, *argv));
}
return 0;
}
olly@gemse:~$ gcc -Wall -W -O2 asneeded.c -ldl -lz -o asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=0x7fc6e04a9fc0
olly@gemse:~$ gcc -Wall -W -O2 -Wl,--as-needed asneeded.c -ldl -lz -o
asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=(nil)
Can we safely leave them inside?
The patch is so ugly, but the libraries are not there anymore
https://github.com/LocutusOfBorg/wx/commit/e18d875c355096e458371d7f83910d02c926c294
A much cleaner way is just to add this to debian/rules instead of the
above changes:
export DEB_LDFLAGS_APPEND=-Wl,--as-needed
are you sure about this? Seems to be not working
DEB_LDFLAGS_APPEND=-Wl,--as-needed
and neither this
DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed
(or at least I don't see them when building)
are them hidden?
cheers,
Gianfranco
Attached the log of the new debdiffs
Great, that looks much better to me. Thanks for all your work on this.
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
On Fri, May 02, 2014 at 01:20:28AM +0100, Gianfranco Costamagna wrote: A much cleaner way is just to add this to debian/rules instead of the above changes: export DEB_LDFLAGS_APPEND=-Wl,--as-needed are you sure about this? Seems to be not working DEB_LDFLAGS_APPEND=-Wl,--as-needed and neither this DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed (or at least I don't see them when building) are them hidden? It works for me (on unstable): olly@gemse:~$ dpkg-buildflags --get LDFLAGS -Wl,-z,relro olly@gemse:~$ DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --get LDFLAGS -Wl,-z,relro -Wl,--as-needed Did you include the *export* before them? That's important as it means make will export the make variable DEB_LDFLAGS_APPEND to an environment variable with the same name in the environment for child processes. Without the export, you've only set the make variable DEB_LDFLAGS_APPEND, which dpkg-buildflags can't see. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
On Fri, May 02, 2014 at 12:18:44AM +0100, Gianfranco Costamagna wrote: So should be harmless because I didn't see a ton of bug reports on ubuntu for this :) Yes - they seem to be using 3.0.0-2 unpatched. Given it's a popular package, it seems likely they'd have bug reports if this caused issues. Sounds like we're quite close to this being uploadable. Let me know when you're done and I'll pull the changes into the main repo. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Il Venerdì 2 Maggio 2014 2:34, Olly Betts o...@survex.com ha scritto:
On Fri, May 02, 2014 at 12:18:44AM +0100, Gianfranco Costamagna wrote:
So should be harmless because I didn't see a ton of bug reports on
ubuntu for this :)
Yes - they seem to be using 3.0.0-2 unpatched. Given it's a popular
package, it seems likely they'd have bug reports if this caused issues.
Sounds like we're quite close to this being uploadable. Let me know
when you're done and I'll pull the changes into the main repo.
Tomorrow I'll see more deeply about this problem
I already added you export line at the bottom (please see my commit on github)
but I see this on a pbuilder build
../configure --prefix=/usr --cache-file=../config_deb.cache
--with-flavour= --with-zlib=sys --with-expat=sys CFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security FCFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 FFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 GCJFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
OBJCXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security --disable-gui
--libdir=\${exec_prefix}/lib/x86_64-linux-gnu
something prevents the flags to be correctly appended...
I'll look more in detail tomorrow
thanks for all,
Gianfranco
Cheers,
Olly
Bug#738849: Please enable webview support for wx3.0
On Fri, May 02, 2014 at 01:58:16AM +0100, Gianfranco LocutusOfBorg Costamagna wrote: I already added you export line at the bottom (please see my commit on github) https://github.com/LocutusOfBorg/wx/commit/15e8f7d106298109e58a2a3c8bf8add0b3001aa7 One problem is that: +export DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --get LDFLAGS should be: +export DEB_LDFLAGS_APPEND=-Wl,--as-needed But it seems the real issue is actually that the export doesn't happen before the $(shell dpkg-buildflags --export=configure) gets expanded. A simple fix is to just specify it there directly: $(shell DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --export=configure) Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna wrote: Isn't the -Wl,--as-needed automatically passed by dh system? are you overriding LDFLAGS somewhere? I don't believe either is true. Passing it unconditionally wouldn't be a good plan, as it breaks some cases (as I mentioned above). Are you perhaps thinking of -Wl,-z,relro (which is related to hardening)? I'll rebuild and give you results soon, in the meanwhile I attach the two build logs Aha, this part is interesting (and suggests that -Wl,--as-needed will fix this, if it doesn't break anything; and if not, sorting out the -l flags passed should resolve it): dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_ribbon-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_gl-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_propgrid-3.0.so.0.0.0 were not linked against libjavascriptcoregtk-1.0.so.0 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_ribbon-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_gl-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_propgrid-3.0.so.0.0.0 were not linked against libwebkitgtk-1.0.so.0 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_ribbon-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_gl-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_propgrid-3.0.so.0.0.0 were not linked against libsoup-2.4.so.1 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk-media3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_media-3.0.so.0.0.0 was not linked against libsoup-2.4.so.1 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk-media3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_media-3.0.so.0.0.0 was not linked against libjavascriptcoregtk-1.0.so.0 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk-media3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_media-3.0.so.0.0.0 was not linked against libwebkitgtk-1.0.so.0 (it uses none of the library's symbols) Last thing: I installed in a sid chroot the wx-3 package, with also the webview support package. After that I removed the libwebkitgtk-dev and dpkg didn't complain, also didn't complain about anything else. So can we say libwebkitgtk-dev is just a build dep and not a runtime one? Can this simplify things? (I think it doesn't simplify anything because the package brings other dependencies) libwebkitgtk-dev should only be a build dependency - it's the runtime dependencies which are the issue here. Cheers, Olly -- To
Bug#738849: Please enable webview support for wx3.0
Il Mercoledì 30 Aprile 2014 12:39, Olly Betts o...@survex.com ha scritto: On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna wrote: Isn't the -Wl,--as-needed automatically passed by dh system? are you overriding LDFLAGS somewhere? I don't believe either is true. Passing it unconditionally wouldn't be a good plan, as it breaks some cases (as I mentioned above). Are you perhaps thinking of -Wl,-z,relro (which is related to hardening)? ok can it be that ubuntu enables them by default and debian not? https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed ubuntu is using them since three years, and why should removing a not used library be a problem? I mean if no symbols are used we can drop safely right? I can understand that having as-needed flag may introduce some weird build failures, such when you wrongly build with commands like gcc -lm -library file.c in this way with --as-needed the math link is dropped and you won't likely be able to build correctly the c code (I fixed many of this kind of wrong makefiles when I started contributing in debian, because ubuntu was failing to build almost every package I was able to build in debian). So, with the new flag the package is building, and the unneeded libraries seems to have gone. Can we safely leave them inside? The patch is so ugly, but the libraries are not there anymore https://github.com/LocutusOfBorg/wx/commit/e18d875c355096e458371d7f83910d02c926c294 I'll rebuild and give you results soon, in the meanwhile I attach the two build logs Aha, this part is interesting (and suggests that -Wl,--as-needed will fix this, if it doesn't break anything; and if not, sorting out the -l flags passed should resolve it): dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_ribbon-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_gl-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_propgrid-3.0.so.0.0.0 were not linked against libjavascriptcoregtk-1.0.so.0 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_ribbon-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_gl-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_propgrid-3.0.so.0.0.0 were not linked against libwebkitgtk-1.0.so.0 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_xrc-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_ribbon-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_gl-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_richtext-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_aui-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_qa-3.0.so.0.0.0 debian/libwxgtk3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_propgrid-3.0.so.0.0.0 were not linked against libsoup-2.4.so.1 (they use none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libwxgtk-media3.0-0/usr/lib/x86_64-linux-gnu/libwx_gtk2u_media-3.0.so.0.0.0
Bug#738849: Please enable webview support for wx3.0
On Wed, Apr 30, 2014 at 07:34:03PM +0100, costamagnagianfra...@yahoo.it wrote:
Il Mercoledì 30 Aprile 2014 12:39, Olly Betts o...@survex.com ha scritto:
On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna wrote:
Isn't the -Wl,--as-needed automatically passed by dh
system? are you
overriding LDFLAGS somewhere?
I don't believe either is true. Passing it unconditionally wouldn't be
a good plan, as it breaks some cases (as I mentioned above).
Are you perhaps thinking of -Wl,-z,relro (which is related to
hardening)?
ok can it be that ubuntu enables them by default and debian not?
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
I don't follow Ubuntu development these days, but possibly.
ubuntu is using them since three years, and why should removing a not
used library be a problem?
I mean if no symbols are used we can drop safely right?
It isn't always safe to do so - you can get a clean build but hit
problems at runtime. For example a program might use dlsym() to look up
a symbol from a library it was linked against, but if there aren't any
references at link time, the library won't be there if --as-needed is
used:
olly@gemse:~$ cat asneeded.c
#include dlfcn.h
#include stdio.h
int main(int argc, char ** argv) {
void * handle = dlopen(NULL, RTLD_NOW);
if (!handle) {
fprintf(stderr, dlopen failed: %s\n, dlerror());
return 1;
}
(void)argc;
while (*++argv) {
printf(%s=%p\n, *argv, dlsym(handle, *argv));
}
return 0;
}
olly@gemse:~$ gcc -Wall -W -O2 asneeded.c -ldl -lz -o asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=0x7fc6e04a9fc0
olly@gemse:~$ gcc -Wall -W -O2 -Wl,--as-needed asneeded.c -ldl -lz -o asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=(nil)
Can we safely leave them inside?
The patch is so ugly, but the libraries are not there anymore
https://github.com/LocutusOfBorg/wx/commit/e18d875c355096e458371d7f83910d02c926c294
A much cleaner way is just to add this to debian/rules instead of the
above changes:
export DEB_LDFLAGS_APPEND=-Wl,--as-needed
Attached the log of the new debdiffs
Great, that looks much better to me. Thanks for all your work on this.
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Hi Olly! Il Lunedì 28 Aprile 2014 7:47, Olly Betts o...@survex.com ha scritto: Il Giovedì 24 Aprile 2014 18:11, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Hi Olly, I'm looking right now at the package. Enabling webview gives us a new library, so I think a new package is the most feasible way, right? Yes, seems we should be able to put the webview library into a new binary package (very like how the mmedia library is handled). yes, I started from media package and did some magic sed commands to copy paste My opinion: -leave headers in the generic package (should check but I'm pretty sure they already are there That seems reasonable (and to be what we do for the wxmediactrl headers). mmm the headers were already there, so I don't think we need to change anything here (the files have some magic #ifdef inside) https://packages.debian.org/sid/amd64/wx3.0-headers/filelist /usr/include/wx-3.0/wx/webview.h /usr/include/wx-3.0/wx/webviewarchivehandler.h /usr/include/wx-3.0/wx/webviewfshandler.h something like libwxgtk-webview=SOV with the library inside and a libwxgtk-webview-dev with the link? Yes. wonderful the patch seems to be really trivial if I'm understanding correctly how does your package work If there's already a separate library built, then it shouldn't be a complex patch, though it still needs careful testing as the simple changes in the patch can cause major changes in the resulting packages. yes of course I double checked the libraries, they aren't anymore in the gtk package and they are in the webview one. Have you compared the existing binary packages before and after your changes with debdiff? That's a good way to pick up any files that have inadvertently been installed to a different package, or which have changed in ways we don't want. I did some magic test here: the new packages shows these files $ dpkg -c libwxgtk-webview3.0-0_3.0.0-3_amd64.deb drwxr-xr-x root/root 0 2014-04-28 17:34 ./ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/share/doc/libwxgtk-webview3.0-0/ -rw-r--r-- root/root 22859 2014-04-28 09:25 ./usr/share/doc/libwxgtk-webview3.0-0/copyright -rw-r--r-- root/root 79775 2013-11-11 14:10 ./usr/share/doc/libwxgtk-webview3.0-0/changelog.gz -rw-r--r-- root/root 18441 2014-04-28 11:04 ./usr/share/doc/libwxgtk-webview3.0-0/changelog.Debian.gz drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/lintian/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/lintian/overrides/ -rw-r--r-- root/root 57 2014-04-28 17:33 ./usr/share/lintian/overrides/libwxgtk-webview3.0-0 drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/lib/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/x86_64-linux-gnu/ -rw-r--r-- root/root 122608 2014-04-28 17:34 ./usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0.0.0 lrwxrwxrwx root/root 0 2014-04-28 17:33 ./usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0 - libwx_gtk2u_webview-3.0.so.0.0.0 $ dpkg -c libwxgtk-webview3.0-0-dbg_3.0.0-3_amd64.deb drwxr-xr-x root/root 0 2014-04-28 17:34 ./ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/ -rw-r--r-- root/root 22859 2014-04-28 09:25 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/copyright -rw-r--r-- root/root 79775 2013-11-11 14:10 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/changelog.gz -rw-r--r-- root/root 18441 2014-04-28 11:04 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/changelog.Debian.gz drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/debug/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/debug/.build-id/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/debug/.build-id/a5/ -rw-r--r-- root/root 638129 2014-04-28 17:34 ./usr/lib/debug/.build-id/a5/eafcf1baff67ffc345ddf7927e5a47f28ed8d6.debug $ dpkg -c libwxgtk-webview3.0-dev_3.0.0-3_amd64.deb drwxr-xr-x root/root 0 2014-04-28 17:34 ./ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/share/doc/libwxgtk-webview3.0-dev/ -rw-r--r-- root/root 22859 2014-04-28 09:25 ./usr/share/doc/libwxgtk-webview3.0-dev/copyright -rw-r--r-- root/root 79775 2013-11-11 14:10 ./usr/share/doc/libwxgtk-webview3.0-dev/changelog.gz -rw-r--r-- root/root 18441 2014-04-28 11:04
Bug#738849: Please enable webview support for wx3.0
On Tue, Apr 29, 2014 at 09:45:32AM +0100, Gianfranco Costamagna wrote:
I did some magic test here:
the new packages shows these files
[snip]
These all look good.
I'm not really sure what's up with the upstream 3.0.1 release. It seems
to be have been close for a while, but with about 5 open bugs (just not
always the same 5), and it's now way past the date on their trac
milestone for it.
I asked on the mailing list about this:
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/153565/focus=155839
If you're interested in contributing more generally, you might want to
consider joining the team: https://alioth.debian.org/projects/freewx/
done
Looks like Ron's the only one who can accept people. I'll try to sort
that out.
---
debdiff libwxgtk3.0-0_3.0.0-2_amd64.deb libwxgtk3.0-0_3.0.0-3_amd64.deb
---
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: libatk1.0-0 (= 1.12.4), libc6 (= 2.15), libcairo2 (= 1.6.0),
libfontconfig1 (= 2.11), libfreetype6 (= 2.2.1), libgcc1 (= 1:4.1.1),
libgdk-pixbuf2.0-0 (= 2.22.0), libgl1-mesa-glx | libgl1, libglib2.0-0 (=
2.24.0), libglu1-mesa | libglu1, libgtk2.0-0 (= 2.24.0),
{+libjavascriptcoregtk-1.0-0 (= 1.5.1),+} libjpeg8 (= 8c), libpango-1.0-0
(= 1.18.0), libpangocairo-1.0-0 (= 1.14.0), libpangoft2-1.0-0 (= 1.14.0),
libpng12-0 (= 1.2.13-4), libsm6, {+libsoup2.4-1 (= 2.4.0),+} libstdc++6 (=
4.1.1), libtiff5 (= 4.0.3), {+libwebkitgtk-1.0-0 (= 1.3.10),+}
libwxbase3.0-0 (= 3.0.0), libx11-6, libxxf86vm1, zlib1g (= 1:1.1.4)
This is bad - the main library package has gained dependencies on:
libjavascriptcoregtk-1.0-0 (= 1.5.1)
libsoup2.4-1 (= 2.4.0)
libwebkitgtk-1.0-0 (= 1.3.10)
Not sure what's going on here - dh_shlibdeps should get this right, and
it seems to for the media libraries. I probably won't have time to poke
at this for a few days (I was away last week and have a bit of a
backlog), but you could try looking at the libraries in your newer
libwxgtk3.0-0 package and see if any of them actually depend on any of
the libraries in the list above.
Not sure if there's a simple way to run dh_shlibdeps or dpkg-shlibdeps
in a way to see what's going on there, but you can easily look at what
the elf data says about needed libraries like so:
readelf -a libwx_gtk2u_core-3.0.so.0|grep NEEDED
---
debdiff libwxgtk-media3.0-0_3.0.0-2_amd64.deb
libwxgtk-media3.0-0_3.0.0-3_amd64.deb
---
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: libatk1.0-0 (= 1.12.4), libc6 (= 2.2.5), libcairo2 (= 1.2.4),
libfontconfig1 (= 2.11), libfreetype6 (= 2.2.1), libgcc1 (= 1:4.1.1),
libgdk-pixbuf2.0-0 (= 2.22.0), libglib2.0-0 (= 2.12.0),
libgstreamer-plugins-base0.10-0 (= 0.10.0), libgstreamer0.10-0 (= 0.10.0),
libgtk2.0-0 (= 2.24.0), {+libjavascriptcoregtk-1.0-0 (= 1.5.1),+} libjpeg8
(= 8c), libpango-1.0-0 (= 1.14.0), libpangocairo-1.0-0 (= 1.14.0),
libpangoft2-1.0-0 (= 1.14.0), libpng12-0 (= 1.2.13-4), libsm6,
{+libsoup2.4-1 (= 2.4.0),+} libstdc++6 (= 4.1.1), libtiff5 (= 4.0.3),
{+libwebkitgtk-1.0-0 (= 1.3.10),+} libwxbase3.0-0 (= 3.0.0), libwxgtk3.0-0
(= 3.0.0), libx11-6, libxml2 (= 2.6.27), libxxf86vm1, zlib1g (= 1:1.1.4)
Also not good for the same reason.
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
On Tue, Apr 29, 2014 at 07:24:15PM +0100, Gianfranco Costamagna wrote: If I understand correctly now the step is: see if they are really needed in the core (so they should be needed from some ifdef with webview code), if not this should be a bug, and they should be linked only against the webview package, right? Most likely issue is that these libraries are listed when linking the core wx library, in which case not doing that should fix it. A simpler option may be to pass -Wl,--as-needed when linking - this tells the linker to only actually link against libraries which contribute symbols, which usually works, but fails in some unusual cases. We should see from the debdiffs what effects it has. It could be there's actually some code which references these libraries which goes into the core wx library - in that case, we'll probably need to patch the upstream source so that code goes into the webview library. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Il Giovedì 24 Aprile 2014 18:11, Gianfranco Costamagna
costamagnagianfra...@yahoo.it ha scritto:
Hi Olly, I'm looking right now at the package.
Enabling webview gives us a new library, so I think a new package is the most
feasible way, right?
Yes, seems we should be able to put the webview library into a new
binary package (very like how the mmedia library is handled).
My opinion:
-leave headers in the generic package (should check but I'm pretty sure they
already are there
That seems reasonable (and to be what we do for the wxmediactrl
headers).
something like libwxgtk-webview=SOV with the library inside and a
libwxgtk-webview-dev with the link?
Yes.
the patch seems to be really trivial if I'm understanding correctly how does
your package work
If there's already a separate library built, then it shouldn't be a
complex patch, though it still needs careful testing as the simple
changes in the patch can cause major changes in the resulting packages.
I double checked the libraries, they aren't anymore in the gtk package
and they are in the webview one.
Have you compared the existing binary packages before and after your
changes with debdiff? That's a good way to pick up any files that
have inadvertently been installed to a different package, or which
have changed in ways we don't want.
I also checked the documentation, and updated it.
https://github.com/LocutusOfBorg/wx/commit/92a5bd8ff7c2347d00beac74f0938689ce706679
https://github.com/LocutusOfBorg/wx/commit/4b357103f85186a8585edb60d0ef6c707dfac5ba
I'm still a little bit worried about the dependencies that I should
add for the new packages, can you please review?
You shouldn't need to add libwebkitgtk-3.0-0 manually -
${shlibs:Depends} should take care of adding that for you.
I wouldn't make libwebkitgtk-3.0-0-dbg a hard dependency either (as you
can definitely do useful debugging with just the wx debug symbols), but
it might be reasonable to add them as Suggests:.
I would like to contribute a little more if you want, bumping standard
version, maybe cherry-pick the patch from #736374 or would you like to
wait for the new upcoming release?
I'm not really sure what's up with the upstream 3.0.1 release. It seems
to be have been close for a while, but with about 5 open bugs (just not
always the same 5), and it's now way past the date on their trac
milestone for it.
If we're going to make an upload for this bug, we might as well bundle
in that patch, plus the one for #746192.
It looks like no changes are required for policy 3.9.5, so that can be
bumped too.
If you're interested in contributing more generally, you might want to
consider joining the team: https://alioth.debian.org/projects/freewx/
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Hi again Olly. The package seems to be building fine, running with the split and boinc now builds correctly (I didn't test the run, just the build). I double checked the libraries, they aren't anymore in the gtk package and they are in the webview one. I also checked the documentation, and updated it. https://github.com/LocutusOfBorg/wx/commit/92a5bd8ff7c2347d00beac74f0938689ce706679 https://github.com/LocutusOfBorg/wx/commit/4b357103f85186a8585edb60d0ef6c707dfac5ba I'm still a little bit worried about the dependencies that I should add for the new packages, can you please review? The patch was really trivial, it needed just a little time for me once I got the courage for starting Nothing should be pushed upstream, the package already correctly builds its own library. I would like to contribute a little more if you want, bumping standard version, maybe cherry-pick the patch from #736374 or would you like to wait for the new upcoming release? I really would like a positive, negative or whatever feedback (please ask me to test whatever you want, I don't know if I did the whole work correctly) have a nice weekend cheers, Gianfranco Il Giovedì 24 Aprile 2014 18:11, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Hi Olly, I'm looking right now at the package. Enabling webview gives us a new library, so I think a new package is the most feasible way, right? (sorry, the package is quite heavy, I can miss something) ldd debian/tmp/usr/bin/boincmgr |grep wx libwx_gtk2u_webview-3.0.so.0 = /usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0 (0x7fd6b9232000) this is the library installed in libwxgtk3.0-0_3.0.0 because of install-gtk-lib: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so.* usr/lib/$(DEB_HOST_MULTIARCH) [/snip] install-gtk-dev: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so usr/lib/$(DEB_HOST_MULTIARCH) [snip] and I'll look shortly where the headers file are located but I'm pretty sure they are in package_headers := wx$(release)-headers since they are included as wx/webview.h wx/webviewfshandler.h so can you please suggest me how to move on? My opinion: -leave headers in the generic package (should check but I'm pretty sure they already are there -create a new package? move on -media? this is up to you something like libwxgtk-webview=SOV with the library inside and a libwxgtk-webview-dev with the link? the patch seems to be really trivial if I'm understanding correctly how does your package work cheers, Gianfranco Il Giovedì 17 Aprile 2014 3:03, Olly Betts o...@survex.com ha scritto: On Wed, Apr 16, 2014 at 07:00:15AM +0100, costamagnagianfra...@yahoo.it wrote: Hi Olly, do you have any news on this? Boinc 7.4.x is going to be released soon, with webview support, would be nice to have it at least in experimental for testing, do you think is it possible? I seem to be the only active member of the wx maintainers team, and my wx time is already occupied with trying to migrate the archive away from 2.8. It would be good if that happened before jessie, and there's still a lot to do (and this is only the C++ packages - I've not even started on wxpython yet): https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0 So if you want to get webview support with any degree of urgency, you'll have to do the hard work yourself I'm afraid - just chucking the trivial patch at me isn't anything like enough. If someone provides a well tested and sane patch, I'm very likely to apply it. As I've outlined already at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738849#22 we can't have libwxgtk3.0-0 depending on webkit or else people will quite reasonably complain about the dependency bloat. The webkit libraries either need to be loaded dynamically on demand, or else we need a separate binary package containing just the webkit parts of wx (similar to libwxgtk-media3.0-0 for wxMediaCtrl). To be explicit: For webview support, the first thing you probably need to do is check the binary packages you built from your modified source package and see what their dependencies are compared to those for the packages currently in the archive. If your changes gain us a dependency on webkit libraries (which seems likely) you need to either split off that code into a separate library and put it in its own binary package, or change wx to load those libraries only when actually used, ideally using the wx wrappers around dlopen(), dlsym(), etc so we can try to push the patch upstream. If you want us to switch to using libnotify instead of the generic wx implementation, you need to respond to my query (and quoted source code comment) in
Bug#738849: Please enable webview support for wx3.0
Hi Olly, I'm looking right now at the package. Enabling webview gives us a new library, so I think a new package is the most feasible way, right? (sorry, the package is quite heavy, I can miss something) ldd debian/tmp/usr/bin/boincmgr |grep wx libwx_gtk2u_webview-3.0.so.0 = /usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0 (0x7fd6b9232000) this is the library installed in libwxgtk3.0-0_3.0.0 because of install-gtk-lib: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so.* usr/lib/$(DEB_HOST_MULTIARCH) [/snip] install-gtk-dev: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so usr/lib/$(DEB_HOST_MULTIARCH) [snip] and I'll look shortly where the headers file are located but I'm pretty sure they are in package_headers := wx$(release)-headers since they are included as wx/webview.h wx/webviewfshandler.h so can you please suggest me how to move on? My opinion: -leave headers in the generic package (should check but I'm pretty sure they already are there -create a new package? move on -media? this is up to you something like libwxgtk-webview=SOV with the library inside and a libwxgtk-webview-dev with the link? the patch seems to be really trivial if I'm understanding correctly how does your package work cheers, Gianfranco Il Giovedì 17 Aprile 2014 3:03, Olly Betts o...@survex.com ha scritto: On Wed, Apr 16, 2014 at 07:00:15AM +0100, costamagnagianfra...@yahoo.it wrote: Hi Olly, do you have any news on this? Boinc 7.4.x is going to be released soon, with webview support, would be nice to have it at least in experimental for testing, do you think is it possible? I seem to be the only active member of the wx maintainers team, and my wx time is already occupied with trying to migrate the archive away from 2.8. It would be good if that happened before jessie, and there's still a lot to do (and this is only the C++ packages - I've not even started on wxpython yet): https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0 So if you want to get webview support with any degree of urgency, you'll have to do the hard work yourself I'm afraid - just chucking the trivial patch at me isn't anything like enough. If someone provides a well tested and sane patch, I'm very likely to apply it. As I've outlined already at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738849#22 we can't have libwxgtk3.0-0 depending on webkit or else people will quite reasonably complain about the dependency bloat. The webkit libraries either need to be loaded dynamically on demand, or else we need a separate binary package containing just the webkit parts of wx (similar to libwxgtk-media3.0-0 for wxMediaCtrl). To be explicit: For webview support, the first thing you probably need to do is check the binary packages you built from your modified source package and see what their dependencies are compared to those for the packages currently in the archive. If your changes gain us a dependency on webkit libraries (which seems likely) you need to either split off that code into a separate library and put it in its own binary package, or change wx to load those libraries only when actually used, ideally using the wx wrappers around dlopen(), dlsym(), etc so we can try to push the patch upstream. If you want us to switch to using libnotify instead of the generic wx implementation, you need to respond to my query (and quoted source code comment) in comment 22. If you want us to enable sdl and libmspack support, you also need to justify why doing so is useful, and investigate the (direct and indirect) extra dependencies which each results in. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
(Thanks Olly, sending to the bug report too, damn reply all button on my little android screen) Hi Olly, do you have any news on this? Boinc 7.4.x is going to be released soon, with webview support, would be nice to have it at least in experimental for testing, do you think is it possible? Thanks Gianfranco Sent from Yahoo Mail on Android
Bug#738849: Please enable webview support for wx3.0
On Wed, Apr 16, 2014 at 07:00:15AM +0100, costamagnagianfra...@yahoo.it wrote: Hi Olly, do you have any news on this? Boinc 7.4.x is going to be released soon, with webview support, would be nice to have it at least in experimental for testing, do you think is it possible? I seem to be the only active member of the wx maintainers team, and my wx time is already occupied with trying to migrate the archive away from 2.8. It would be good if that happened before jessie, and there's still a lot to do (and this is only the C++ packages - I've not even started on wxpython yet): https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0 So if you want to get webview support with any degree of urgency, you'll have to do the hard work yourself I'm afraid - just chucking the trivial patch at me isn't anything like enough. If someone provides a well tested and sane patch, I'm very likely to apply it. As I've outlined already at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738849#22 we can't have libwxgtk3.0-0 depending on webkit or else people will quite reasonably complain about the dependency bloat. The webkit libraries either need to be loaded dynamically on demand, or else we need a separate binary package containing just the webkit parts of wx (similar to libwxgtk-media3.0-0 for wxMediaCtrl). To be explicit: For webview support, the first thing you probably need to do is check the binary packages you built from your modified source package and see what their dependencies are compared to those for the packages currently in the archive. If your changes gain us a dependency on webkit libraries (which seems likely) you need to either split off that code into a separate library and put it in its own binary package, or change wx to load those libraries only when actually used, ideally using the wx wrappers around dlopen(), dlsym(), etc so we can try to push the patch upstream. If you want us to switch to using libnotify instead of the generic wx implementation, you need to respond to my query (and quoted source code comment) in comment 22. If you want us to enable sdl and libmspack support, you also need to justify why doing so is useful, and investigate the (direct and indirect) extra dependencies which each results in. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Package: libwxgtk3.0-0 Severity: serious The wx3.0 package *should* depend from libwebkitgtk-3.0-dev. The last boinc release needs webwview support, and I finally spotted why I didn't succeed in building it on a clean debian environment. Your build log clearly says that you are enabling webview checking for --enable-printarch... yes checking for --enable-svg... yes checking for --enable-webkit... yes checking for --enable-webview... yes checking for --enable-graphics_ctx... yes BUT after that you can see it gets disabled checking for linux/joystick.h... yes checking for python... /usr/bin/python configure: WARNING: webkitgtk not found. configure: WARNING: WebKit not available, disabling wxWebView checking for WEBKIT... checking for CAIRO... yes checking for cairo_push_group... yes boinc fails with this log, while building with a custom wx3.0 library doesn't fail. I can upload on mentors or a debdiff here if needed. thanks. G. /usr/include/wx-3.0/wx/vector.h:44:23: warning: previous declaration of 'void wxQsort(void*, size_t, size_t, wxSortCallback, const void*)' [-Wredundant-decls] WXDLLIMPEXP_BASE void wxQsort(void* pbase, size_t total_elems, ^ In file included from NoticeListCtrl.cpp:36:0: NoticeListCtrl.h:48:25: error: 'wxWebViewEvent' has not been declared void OnLinkClicked( wxWebViewEvent event ); ^ NoticeListCtrl.h:49:26: error: 'wxWebViewEvent' has not been declared void OnWebViewError( wxWebViewEvent event ); ^ NoticeListCtrl.h:59:5: error: 'wxWebView' does not name a type wxWebView* m_browser; ^ NoticeListCtrl.cpp:53:72: error: invalid use of non-static member function 'void CNoticeListCtrl::OnLinkClicked(int)' EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked) ^ NoticeListCtrl.cpp:53:85: error: 'EVT_WEBVIEW_NAVIGATING' was not declared in this scope EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked) ^ NoticeListCtrl.cpp:54:5: error: expected '}' before 'EVT_WEBVIEW_ERROR' EVT_WEBVIEW_ERROR(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnWebViewError) Building wx [1] https://buildd.debian.org/status/fetch.php?pkg=wxwidgets3.0arch=i386ver=3.0.0-2stamp=1385783568 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
severity 738849 wishlist thanks On Thu, Feb 13, 2014 at 12:51:31PM +, Gianfranco Costamagna wrote: Package: libwxgtk3.0-0 Severity: serious Please don't inflate severity - it won't get your bug addressed any sooner. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
