Bug#744894: awesome: Chromium redraw event on another tag display tab content in current tag
Package: awesome Version: 3.4.15-1+b1 Followup-For: Bug #744894 Seeing the same thing that Thierry reports here on 3.4.15-1+b1, using google-chrome (34.0.1847.132) Thanks, Arthur -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages awesome depends on: ii dbus-x11 1.8.0-3 ii libc6 2.18-5 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.0-3 ii libev41:4.15-3 ii libglib2.0-0 2.40.0-3 ii libimlib2 1.4.6-2 ii liblua5.1-0 5.1.5-5 ii libpango1.0-0 1.36.3-1 ii libstartup-notification0 0.12-3 ii libx11-6 2:1.6.2-1 ii libx11-xcb1 2:1.6.2-1 ii libxcb-icccm4 0.4.1-1 ii libxcb-image0 0.3.9-1 ii libxcb-keysyms1 0.3.9-1 ii libxcb-randr0 1.10-2 ii libxcb-render01.10-2 ii libxcb-shape0 1.10-2 ii libxcb-shm0 1.10-2 ii libxcb-util0 0.3.8-2 ii libxcb-xinerama0 1.10-2 ii libxcb-xtest0 1.10-2 ii libxcb1 1.10-2 ii libxcursor1 1:1.1.14-1 ii libxdg-basedir1 1.2.0-1 ii menu 2.1.46 Versions of packages awesome recommends: ii feh2.10-1 ii rlwrap 0.37-5 ii x11-xserver-utils 7.7+2 awesome suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519464: gupnp-tools: Universal control point can submit arguments in the wrong order
Package: gupnp-tools
Version: 0.6-1
Severity: normal
Tags: patch
gupnp-universal-cp can send UPnP arguments in the wrong order when
invoking actions. The UPnP spec requires that
action arguments are sent in the order in which they appear in the SCPD.
What's worse, the DLNA spec requires
compliant devices to reject invokations from clients that don't respect
argument ordering.
In action-dialog.c, the call to gupnp_service_proxy_begin_action_hash
(line 715) doesn't contain enough context for the
library to correctly order the arguments of the service call. As a
result, the arguments are ordered by the iteration
order of the hash keys. The correct answer is probably to add enough
context to a service proxy object for it to be able
to retrieve the order of an action's arguments, but I've attached
patches for an incorrect answer - adding an extra
function to the library that accepts more context, and changing the call
in action-dialog.c.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gupnp-tools depends on:
ii libc6 2.7-18GNU C Library: Shared libraries
ii libglade2-01:2.6.3-1 library to load .glade
files at ru
ii libglib2.0-0 2.18.4-2 The GLib library of C routines
ii libgssdp-1.0-1 0.6.4-1 GObject-based library for SSDP
ii libgtk2.0-02.12.11-4 The GTK+ graphical user
interface
ii libgupnp-1.0-2 0.12.6-2 GObject-based library for UPnP
ii libgupnp-av-1.0-1 0.2.1-1 Audio/Visual utility
library for G
ii libsoup2.4-1 2.24.3-2 an HTTP library
implementation in
ii libuuid1 1.41.3-1 universally unique id library
ii libxml22.6.32.dfsg-5 GNOME XML library
gupnp-tools recommends no packages.
gupnp-tools suggests no packages.
-- no debconf information
diff -ur gupnp-0.12.6/libgupnp/gupnp-service-proxy.c
gupnp-0.12.6-at/libgupnp/gupnp-service-proxy.c
--- gupnp-0.12.6/libgupnp/gupnp-service-proxy.c 2009-01-06 14:32:22.0
+
+++ gupnp-0.12.6-at/libgupnp/gupnp-service-proxy.c 2009-03-12
17:30:01.0 +
@@ -791,6 +791,52 @@
return ret;
}
+GUPnPServiceProxyAction *
+gupnp_service_proxy_begin_action_hash_with_ordering
+ (GUPnPServiceProxy *proxy,
+const char *action,
+GUPnPServiceProxyActionCallback callback,
+gpointeruser_data,
+GHashTable *hash,
+GUPnPServiceActionInfo
*action_info)
+{
+GUPnPServiceProxyAction *ret;
+
+g_return_val_if_fail (GUPNP_IS_SERVICE_PROXY (proxy), NULL);
+g_return_val_if_fail (action, NULL);
+g_return_val_if_fail (callback, NULL);
+
+/* Create message */
+ret = begin_action_msg (proxy, action, callback, user_data);
+
+if (ret-error) {
+callback (proxy, ret, user_data);
+
+return ret;
+}
+
+GList *iter;
+for (iter = action_info-arguments; iter; iter = iter-next)
+{
+GUPnPServiceActionArgInfo *arg_info = iter-data;
+GValue *value = g_hash_table_lookup(hash, arg_info-name);
+if (value != NULL)
+{
+write_in_parameter(arg_info-name, value,
ret-msg_str);
+}
+else
+{
+g_warning(No value supplied for action arg %s,
arg_info-name);
+}
+}
+
+/* Finish and send off */
+finish_action_msg (ret, action);
+
+return ret;
+
+}
+
/**
* gupnp_service_proxy_begin_action_hash
* @proxy: A #GUPnPServiceProxy
diff -ur gupnp-0.12.6/libgupnp/gupnp-service-proxy.h
gupnp-0.12.6-at/libgupnp/gupnp-service-proxy.h
--- gupnp-0.12.6/libgupnp/gupnp-service-proxy.h 2009-01-06 14:32:22.0
+
+++ gupnp-0.12.6-at/libgupnp/gupnp-service-proxy.h 2009-03-12
17:22:46.0 +
@@ -159,6 +159,15 @@
gpointeruser_data,
GHashTable *hash);
+GUPnPServiceProxyAction *
+gupnp_service_proxy_begin_action_hash_with_ordering
+ (GUPnPServiceProxy *proxy,
+const char *action,
+GUPnPServiceProxyActionCallback callback,
+
Bug#518007: php-gettext: fails with E_STRICT errors
Package: php-gettext
Version: 1.0.7-6
Severity: normal
Tags: patch
When included in a project that uses strict error checking (don't know
how may php projects do), the library fails out in a couple of places.
For example:
E_STRICT: Creating default object from empty value
in /usr/share/php/php-gettext/gettext.inc on line 154
The following patch clears up the warnings (albeit with slightly odd
indentation).
--- gettext/usr/share/php/php-gettext/gettext.inc 2006-02-07
20:43:11.0 +
+++ /usr/share/php/php-gettext/gettext.inc 2008-07-31 14:22:36.0
+0100
@@ -44,6 +44,12 @@
$EMULATEGETTEXT = 0;
$CURRENTLOCALE = '';
+class domain
+{
+ var $l10n;
+ var $path;
+ var $codeset;
+}
// Utility functions
@@ -64,6 +70,10 @@
else {
$input = null;
}
+if (!array_key_exists($domain, $text_domains))
+{
+ $text_domains[$domain] = new domain();
+}
$text_domains[$domain]-l10n = new gettext_reader($input,
$enable_cache);
}
return $text_domains[$domain]-l10n;
@@ -151,6 +161,10 @@
// ensure $path ends with a slash
if ($path[strlen($path) - 1] != '/') $path .= '/';
elseif ($path[strlen($path) - 1] != '\\') $path .= '\\';
+ if (!array_key_exists($domain, $text_domains))
+ {
+$text_domains[$domain] = new domain();
+ }
$text_domains[$domain]-path = $path;
}
@@ -166,8 +180,12 @@
* Sets the default domain.
*/
function _textdomain($domain) {
- global $default_domain;
+ global $default_domain, $text_domains;
$default_domain = $domain;
+ if (!array_key_exists($domain, $text_domains))
+ {
+$text_domains[$domain] = new domain();
+ }
}
/**
@@ -315,4 +333,4 @@
}
}
-?
\ No newline at end of file
+?
--- gettext/usr/share/php/php-gettext/gettext.php 2006-02-02
19:04:02.0 +
+++ /usr/share/php/php-gettext/gettext.php 2008-07-31 12:13:50.0
+0100
@@ -63,10 +63,12 @@
function readint() {
if ($this-BYTEORDER == 0) {
// low endian
-return array_shift(unpack('V', $this-STREAM-read(4)));
+$unpacked = unpack('V', $this-STREAM-read(4));
+return array_shift($unpacked);
} else {
// big endian
-return array_shift(unpack('N', $this-STREAM-read(4)));
+$unpacked = unpack('N', $this-STREAM-read(4));
+return array_shift($unpacked);
}
}
--- gettext/usr/share/php/php-gettext/streams.php 2006-02-02
19:59:18.0 +
+++ /usr/share/php/php-gettext/streams.php 2008-07-31 12:07:57.0
+0100
@@ -105,6 +105,7 @@
function read($bytes) {
if ($bytes) {
fseek($this-_fd, $this-_pos);
+ $data = '';
// PHP 5.1.1 does not read more than 8192 bytes in one fread()
// the discussions at PHP Bugs suggest it's the intended behaviour
@@ -163,4 +164,4 @@
}
-?
\ No newline at end of file
+?
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages php-gettext depends on:
ii php5 5.2.6-2server-side, HTML-embedded scripti
php-gettext recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#353169: libupnp: Fixed length buffer for UPNP Action URLs breaks applications
Hi Nick, Thanks for getting back. We used that patch here for a while so it was sound against v1.2.1, but we have since embarked on a rewrite (because that seemed easier than trying to weed out all the fixed-length buffers and possible other liabilities). The rewrite is in a different language, and integrated with our client code rather than packaged as a library - I don't think it would help you. Sorry not to be able to be of more use. We would have loved to have had an actively maintained libupnp to contribute to, but limited resources here meant we couldn't maintain the whole thing ourselves and customer requirements meant that we couldn't wait. Arthur Nick Leverton wrote: Thanks for the patch, Arthur, and sorry you had to wait so long. As new maintainer of libupnp I'm currently updating your patch to apply to pupnp 1.6.5. This being a C++ package, ideally I'd have liked to see a fix which made use of new/delete and object destructors to release memory, rather than malloc/free. But it looks as though that might need quite a lot of re-working of upstream code ! So I'm going with your patch for the moment. Would you be in a position to re-test ? If so I can send you a link to my updated sources. Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353169: libupnp: Fixed length buffer for UPNP Action URLs breaks applications
Please find attached a patch which goes some way to fixing this issue.
I've only tested it in my current configuration, so I don't know how
this impacts the webserver. I've had to introduce two new functions to
free structures that may be returned by the framework. Not sure how
necessary they are, as I think mostly it frees up what it gives you.
This library is still significantly broken. If upstream isn't planning a
version 2 this either wants fixing comprehensively by debian,
documenting with warnings in very large letters, or removing all
together. I think it would be a mistake to base a serious application on
the current version. Either that or it's actually perfectly safe and I'm
just using it 'wrong' :)
Arthur
--
Arthur Taylor, +44 (0) 1223 271512
Reciva Limited,
509 Coldhams Lane,
Cambridge,
CB1 3JS. England
Fax: +44 (0) 1223 702991
diff -ur libupnp/upnp/inc/config.h ../libupnp/upnp/inc/config.h
--- libupnp/upnp/inc/config.h 2006-02-01 17:01:06.0 +
+++ ../libupnp/upnp/inc/config.h2006-02-16 16:29:52.0 +
@@ -226,8 +226,8 @@
#define EXCLUDE_SOAP 0
#define EXCLUDE_GENA 0
#define EXCLUDE_DOM 0
-#define EXCLUDE_MINISERVER 0
-#define EXCLUDE_WEB_SERVER 0
+#define EXCLUDE_MINISERVER 1
+#define EXCLUDE_WEB_SERVER 1
#ifdef USE_JNI
#define EXCLUDE_JNI 0
#else
diff -ur libupnp/upnp/inc/upnp.h ../libupnp/upnp/inc/upnp.h
--- libupnp/upnp/inc/upnp.h 2006-02-01 17:01:07.0 +
+++ ../libupnp/upnp/inc/upnp.h 2006-02-16 17:04:15.0 +
@@ -669,7 +669,7 @@
int ErrCode;
/** The control URL for service. */
- char CtrlUrl[NAME_SIZE];
+ char *pCtrlUrl;
/** The DOM document describing the action. */
IXML_Document *ActionRequest;
@@ -719,7 +719,7 @@
int ErrCode;
/** The control URL for the service. */
- char CtrlUrl[NAME_SIZE];
+ char *pCtrlUrl;
/** The name of the variable. */
char StateVarName[NAME_SIZE];
@@ -807,7 +807,7 @@
int ErrCode;
/** The event URL being subscribed to or removed from. */
- char PublisherUrl[NAME_SIZE];
+ char *pPublisherUrl;
/** The actual subscription time (for subscriptions only). */
int TimeOut;
@@ -997,6 +997,9 @@
extern C {
#endif // __cplusplus
+void UpnpFreeSubscribeEvent(struct Upnp_Event_Subscribe *pEvt, int
free_pointer);
+void UpnpFreeActionCompleteEvent(struct Upnp_Action_Complete *pEvt, int
free_pointer);
+
///@name Initialization and Registration
//@{
/** Initializes the Linux SDK for UPnP Devices. This function must be called
diff -ur libupnp/upnp/src/api/upnpapi.c ../libupnp/upnp/src/api/upnpapi.c
--- libupnp/upnp/src/api/upnpapi.c 2006-02-01 17:01:14.0 +
+++ ../libupnp/upnp/src/api/upnpapi.c 2006-02-17 12:42:30.0 +
@@ -68,6 +68,8 @@
/*
** */
+static void free_param( struct UpnpNonblockParam *Param);
+
//Mutex to synchronize the subscription handling at the client side
CLIENTONLY( ithread_mutex_t GlobalClientSubscribeMutex;
)
@@ -290,8 +292,9 @@
DEVICEONLY( UpnpDevice_Handle device_handle;
)
CLIENTONLY( UpnpClient_Handle client_handle;
- )
-struct Handle_Info *temp;
+)
+ struct Handle_Info *temp;
+
DBGONLY( ThreadPoolStats stats;
)
@@ -370,6 +373,41 @@
} /* End of UpnpFinish */
+void
+UpnpFreeSubscribeEvent(struct Upnp_Event_Subscribe *pEvt, int free_pointer)
+{
+ if (pEvt == NULL)
+ {
+return;
+ }
+ if (pEvt-pPublisherUrl != NULL)
+ {
+free( pEvt-pPublisherUrl );
+ }
+ if (free_pointer)
+ {
+free( pEvt );
+ }
+}
+
+void
+UpnpFreeActionCompleteEvent(struct Upnp_Action_Complete *pEvt, int
free_pointer)
+{
+ if (pEvt == NULL)
+ {
+return;
+ }
+ if (pEvt-pCtrlUrl != NULL)
+ {
+free( pEvt-pCtrlUrl );
+ }
+ if (free_pointer)
+ {
+free( pEvt );
+ }
+}
+
+
/
* Function: UpnpGetServerPort
*
@@ -1746,7 +1784,8 @@
Param-FunName = SUBSCRIBE;
Param-Handle = Hnd;
-strcpy( Param-Url, EvtUrl );
+Param-pUrl = malloc(sizeof(char) * (strlen(EvtUrl) + 1));
+strcpy( Param-pUrl, EvtUrl );
Param-TimeOut = TimeOut;
Param-Fun = Fun;
Param-Cookie = ( void * )Cookie_const;
@@ -1951,6 +1990,7 @@
Param-FunName = UNSUBSCRIBE;
Param-Handle = Hnd;
+Param-pUrl = NULL;
strcpy( Param-SubsId, SubsId );
Param-Fun = Fun;
Param-Cookie = ( void * )Cookie_const;
@@ -2101,6 +2141,7 @@
Param-Handle = Hnd;
strcpy( Param-SubsId, SubsId );
Param-Fun = Fun;
+Param-pUrl = NULL;
Param-Cookie = ( void * )Cookie_const;
Param-TimeOut = TimeOut;
@@ -2691,12 +2732,13 @@
Param-FunName = ACTION;
Param-Handle = Hnd;
-strcpy( Param-Url, ActionURL );
+Param-pUrl = malloc(sizeof(char) * ((strlen(ActionURL) + 1)));
+strcpy( Param
Bug#353169: libupnp: Fixed length buffer for UPNP Action URLs breaks applications
Package: libupnp Severity: important When using the UpnpSendActionAsync method (and possibly other Async methods), the SDK stores the URL for the action in a struct UpnpNonblockParam. This has a fixed length array for storing the action URL of 100 characters. Some UPNP servers routinely generate control URLs longer than 100 characters: http://192.168.0.1:2869/upnphost/udhisapi.dll?control=uuid:-b4cb-41ac-827d-+urn:upnp-org:serviceId:ContentDirectory at src/api/upnpapi.c:2694, the SDK then proceeds to strcpy the control URL to the Param struct, resulting in stack-overwritey-badness. I might end up having to fix this, and if so will e-mail the package maintainer any patch I generate. For a temporary fix, increase NAME_SIZE in inc/upnp.h. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-skas3-v9-pre7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350568: libupnp fixed length buffer for SOAP messages breaks applications
Package: libupnp0
Version: 1.2.1-2
Severity: important
Tags: patch
When using libupnp to communicate with Windows Media Connect and
browsing a large directory on its Content Directory server (large = 15
files in this case), UpnpSendAction will return internal error -119,
UPNP_E_BAD_HTTPMSG because the http response parser in
genlib/net/http/httpreadwrite.c returns HTTP_REQ_ENTITY_TOO_LARGE on the
basis of a comparison of the parsed response's content_length with the
value g_maxContentLength. g_maxContentLength is arbitrarily set at
16000, and SOAP messages are unlimited in length, making this
restriction unhelpful in implementing compliant UPNP services.
In the context of receiving responses from remote servers, I believe the
restriction to be unnecessary. The parser allocates its buffer as data
comes in and fails 'gracefully' when it runs out of memory. The attached
patch removes the check, and running the code without the check seems to
cause no troubles for the purposes for which I am using it.
N.B.: I have not looked at the other code in the library in detail, and
have no doubt that there are places where this restriction is used to
make an assumption about the size of some other buffer. This obviously
needs fixing properly upstream, and I'm not recommending this patch is
included in the package, but attaching it for users in a similar
situation to my own.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-skas3-v9-pre7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=sh:
/usr/local/arm/3.3.1/bin/locale: cannot execute binary file)
Versions of packages libupnp0 depends on:
ii libc6 2.3.5-8.1 GNU C Library: Shared
libraries an
libupnp0 recommends no packages.
-- debconf information excluded
--- upnp/src/genlib/net/http/httpreadwrite.orig 2006-01-27
16:41:10.0 +
+++ upnp/src/genlib/net/http/httpreadwrite.c2006-01-27
16:35:35.0 +
@@ -214,11 +214,11 @@
//print_http_headers( parser-msg );
)
-if( parser-content_length
-( unsigned int )g_maxContentLength ) {
-*http_error_code = HTTP_REQ_ENTITY_TOO_LARGE;
-return UPNP_E_BAD_HTTPMSG;
-}
+//if( parser-content_length
+//( unsigned int )g_maxContentLength ) {
+//*http_error_code = HTTP_REQ_ENTITY_TOO_LARGE;
+//return UPNP_E_BAD_HTTPMSG;
+//}
return 0;
} else if( status == PARSE_FAILURE ) {
--
Arthur Taylor, +44 (0) 1223 271512
Reciva Limited,
509 Coldhams Lane,
Cambridge,
CB1 3JS. England
Fax: +44 (0) 1223 702991
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
