Bug#355872: Please close, new upstream release fixed the bug
Hi, Changelog for upstream version 2.5.0beta1 (dated Feb. 29, 2008) contains: * The bug that caused busy loop when initial connection was immediately refused was fixed. and I am happy to confirm that this closes the Busy waiting on querying localhost bug I reported a bit more than two years ago. Yay! Cheers, -- Daniel Déchelotte http://yo.dan.free.fr/
Bug#397886: apache2.2-common: non wanted behaviour during upgrade: charset MUST not be created without user consent
severity 397886 important (breaks something both valid and common, and that used to work) Steinar H. Gunderson a écrit : Now, what you are probably thinking of is the following abomination: head meta http-equiv=Content-type content=text/html; charset=iso-8859-15 /head This abomination :) is perfectly a valid one [1]. [1] http://www.w3.org/TR/html4/charset.html It is true that a Content-type: header with a character set will override this. As per [1]. However, using http-equiv is strongly discouraged in general, and has been so for years Hmmm. Where in [1] (or another reference) exactly? -- after all, what character set would the browser assume for the meta tag? This is described in [1] (The META declaration must only be used when the character encoding is organized such that ASCII-valued bytes stand for ASCII characters). (And if you were serving non-HTML content, like plain text, how would you specify the character set information if not in the HTTP headers?) Now this is a good point: as Debian Etch uses UTF-8 locales/charset by default, it is indeed desirable to (explicitely) serve as UTF-8 plain/text files, which are likely to contain UTF-8 text. But setting such a DefaultCharset *breaks* *working* pages (and perfectly valid ones) for very little benefit. Sites that use latin encoding for latin characters are *not* broken. Here is what I can read in apache2.conf : [...] IfModule mod_mime.c # # Specify a default charset for all pages sent out. This is # always a good idea and opens the door for future internationalisation # of your web site, should you ever want it. Specifying it as # a default does little harm; as the standard dictates that a page # is in iso-8859-1 (latin1) unless specified otherwise i.e. you # are merely stating the obvious. There are also some security # reasons in browsers, related to javascript and URL parsing # which encourage you to always set a default char set. # #AddDefaultCharset ISO-8859-1 [...] Note the ambivalent comment, and that AddDefaultCharset is eventually not set. BTW, why isn't /etc/apache2/conf.d/charset properly marked as a conffile, or integrated in apache2.conf? Or why not ask the user a debconf question? (not what I suggest, I prefer letting the www-admin consciously set a DefaultCharset, if she so wishes). Creating the file on the fly in the postinst script is a silent if not hidden way to suddenly break the user's site. Cheers, -- Daniel Déchelotte http://yo.dan.free.fr/
Bug#397886: apache2.2-common: non wanted behaviour during upgrade: charset MUST not be created without user consent
Steinar H. Gunderson a écrit : On Fri, Dec 22, 2006 at 06:42:46PM +0100, Daniel Déchelotte wrote: But setting such a DefaultCharset *breaks* *working* pages (and perfectly valid ones) for very little benefit. Sites that use latin encoding for latin characters are *not* broken. Discussions about best behavior aside, just to summarize: The bug here (if any) is that AddDefaultCharset is added even on an upgrade. [...] This might have been discussed somewhere before, but why set a default charset at the first place (even for fresh installs)? I agree that it may help for files that do not explicitely specify their encodings, i.e., plain text files. Provided that they are indeed UTF-8 files. But are there any others cases where it is needed? Would there be a way to limite the scope of the default charset to the only files whose mime type is text/plain? Anyways, the server doesn't have to force an arbitrary charset when it is not specified: apache can let it unspecified, and up to the client to guess. For every other mime types (html, static or not, xml, ...), the blind HTTP directive is to supercede the correct indication contained in the file, and break it. A similar (albeit old) bug against apache is #305495. -- Daniel Déchelotte http://yo.dan.free.fr/
Bug#105351: Now with patch pseudo-header
Tags: patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#105351: [PATCH] Bug with omnipresent appicon at startup
Hi,
I think bugs #105351 (omnipresent icons disappear when first clicked) and
#316044 (docked apps disappear in special situation) refer to the same
problem and should be closed after applying the enclosed patch.
In function wWorkspaceRestoreState() (file src/workspace.c), after
restoring each workspace, all omnipresent appicons are made omnipresent
(with wClipMakeIconOmnipresent(): the appicons are prepended to the list of
global_icons) and then are merely mapped (with XMapWindow()), but are not
actually _moved_ from workspace[i] to workspace[0], which the proposed
patch does.
To prove this is the cause of the two bug reports, I describe in details
what is happening in each of them. The critical condition to reproduce
these bugs is to exit (or restart) WM from a workspace **different from
workspace 0** (any other workspace will do) and to have, obviously, at
least one omnipresent appicon docked in the clip.
In bug #105351, Alessandro Dalvit [EMAIL PROTECTED] wrote:
I have 4 virtual desktops in WindowMaker, and the icon of rxvt in the
clip set as Omnipresent; if I start X and click on this icon it
disappears,
Excerpt from src/dock.c, function handleIconMove, lines 3968--3975:
if (omnipresent) {
int i;
for (i=0; iscr-workspace_count; i++) {
if (i == scr-current_workspace)
continue;
wDockHideIcons(scr-workspaces[i]-clip);
}
}
After moving the rxvt appicon (which is omnipresent), the code cycle
through all workspaces (except the current one) and hides their appicons
(to undo lines 3843--3850). The problem is, the omnipresent appicons still
belong to workspace[i] (for some i), and are thus unmapped at this point.
but it's sufficient to swap to another desktop to make it
appear again. The problem doesn't happen anymore, until I close X and
run it again;
Indeed, wWorkspaceForceChange() calls wClipUpdateForWorkspaceChange(),
which moves all omnipresent appicons to the correct workspace and fixes the
issue until WM ends.
even restarting only wmaker doesn't seem to recreate the
conditions for the problem to happen.
It does, if the restart is called from workspace i, i 0.
I've been using wmaker for a
couple years and the this happened in all the versions I tried.
In bug #316044, Mario Frasca [EMAIL PROTECTED] wrote:
[...]
quite intermittently, the following bug appears: after logging in,
before moving to another workspace, I click (single click is enough) on
a wmWeather unstarted dock and the whole set of docks disappears,
leaving the clip in some sort of collapsed mode (by way of explaining,
but not literally, because the clip retains its colors typical for
uncollapsed mode).
moving to an other workspace makes the docked applications show up
again. clicking on an unstarted dockapp does not cause the bug any
more, it is something which happens only once per session and only if I
do not change workspace before clicking on a non started dockapp.
Same as above.
immediately after logging in, before moving to a workspace other than
#1, I click and drag the clip and only those dockapps which are not
omnipresent move following the dragged clip. [...]
moveDock(), called by handleDockMove(), only (and quite logically) moves
appicons that appear in the clip's icon_array, which doesn't include the
omnipresent appicons until the first workspace switch. So non-omnipresent
appicons are dragged but not the omnipresent ones.
The enclosed patch applies to wmaker-0.92.0-5.3. Please apply it (or
let me know why not! ;-) and forward it to upstream.
Best,
--
Daniel Déchelotte
http://yo.dan.free.fr/
diff -Naur -x 74_omnipresent_appicon_startup.diff
wmaker-0.92.0-1-a/src/workspace.c wmaker-0.92.0-1-b/src/workspace.c
--- wmaker-0.92.0-1-a/src/workspace.c 2005-08-08 11:54:42.0 +0200
+++ wmaker-0.92.0-1-b/src/workspace.c 2005-08-08 11:55:02.0 +0200
@@ -1519,6 +1519,8 @@
wfree(scr-workspaces[i]-name);
scr-workspaces[i]-name = wstrdup(WMGetFromPLString(pstr));
if (!wPreferences.flags.noclip) {
+int omnipresent_icons_added = 0;
+
clip_state = WMGetFromPLDictionary(wks_state, dClip);
if (scr-workspaces[i]-clip)
wDockDestroy(scr-workspaces[i]-clip);
@@ -1534,13 +1536,30 @@
*/
for (j=0; jscr-workspaces[i]-clip-max_icons; j++) {
WAppIcon *aicon = scr-workspaces[i]-clip-icon_array[j];
+int index;
+
+if (!aicon || !aicon-omnipresent)
+continue;
+aicon-omnipresent = 0;
+if (wClipMakeIconOmnipresent(aicon, True) != WO_SUCCESS)
+continue;
+if (i == 0)
+continue;
+
+/* Move this appicon
Bug#334486: beep: [INTL:fr] French debconf templates translation
Package: beep Version: N/A Severity: wishlist Tags: patch l10n [ Handmade bug report, copied from a sample l10n bug report: I hope I do not break any script... ] Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. If you do not already use it, please remember about the podebconf-report-po utility, which helps warning translators about changes when you modify some debconf templates in your packages. See its man page for details. The usual policy when using it is sending a warning to translators when you plan to upload a version of your package with debconf templates changes (EVEN TYPO CORRECTIONS). Then leave about one week for them to update their files (several translation teams have a QA process which requires time). podebconf-report-po will take care of sending the translators the needed material as well as getting the translators adresses from the PO files. All you have to do is just using the utility..:-) If you apply this policy, please forget about these remarks, of courseThis message is generic..:-) -- Daniel Déchelotte http://yo.dan.free.fr/ # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # #Developers do not need to manually edit POT or PO files. # msgid msgstr Project-Id-Version: beep 1.2.2-10\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2005-06-14 00:09+0200\n PO-Revision-Date: 2003-03-13 22:18+0100\n Last-Translator: Daniel Déchelotte [EMAIL PROTECTED]\n Language-Team: Debian-l10n-french debian-l10n-french@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=ISO-8859-15\n Content-Transfer-Encoding: 8bit\n #. Type: select #. Choices #: ../templates:3 msgid suid root for all, suid root with only group audio executable, not suid at all msgstr Exécution par tous en setuid root, Exécution par le seul groupe audio en setuid root, Pas de setuid root #. Type: select #. Description #: ../templates:5 msgid How do you want to handle suid root for the beep program? msgstr Gestion des privilèges spéciaux du programme beep : #. Type: select #. Description #: ../templates:5 msgid beep must be run as root since it needs to access the speaker hardware. There are several posibilities to make the program usable: Either only for root (no suid bit at all), executable only by users of the group audio, or usable for all. msgstr Le programme beep doit être lancé avec les privilèges du superutilisateur pour pouvoir accéder au haut-parleur. Cela est possible de plusieurs façons : soit le bit setuid est positionné et tout le monde peut exécuter ce programme, soit le bit setuid est positionné et seuls les membres du groupe audio peuvent exécuter le programme, soit le bit setuid n'est pas positionné et beep n'est alors exécutable que par le superutilisateur. #. Type: select #. Description #: ../templates:5 msgid Since each program set as suid root can be a security risk this is not done by default. However, the program is quite small (~150 lines of code), so it is fairly easy to verify the safety of the code yourself, if you don't trust my judgement. msgstr Comme tout programme « setuid root » représente a priori un risque du point de vue de la sécurité, cela n'est pas fait par défaut. Toutefois, ce programme est vraiment petit (environ 150 lignes de code) et il est relativement facile de vérifier par vous-même que le code est sûr, en cas de doute.
