If you're doing official releases, you also want to address bug 554088
at some point.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to gwt in Ubuntu.
https://bugs.launchpad.net/bugs/740815
Title:
[FFe] Updates to enable us to drop
(In reply to comment #26)
Created attachment 521593 [details]
Fix SONAME
This ensures that the resulting binary has the right soname
(libmozjs185.so.1.0). tbh, I couldn't figure out a better way of doing this,
so
I'm not sure if anyone else has any better ideas
Why does it need to be
Yes, except that YarrSyntaxChecker.cpp is in CPPSRCS only in
ENABLE_YARR_JIT case..
Both your patch and my older patch add YarrSyntaxChecker.cpp to CPPSRCS
in the non-ENABLE_YARR_JIT case
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
For checkSyntax, nothing needs to be done, really. Essentially, the
#ifdef is wrong, the code is not tied to the YARR JIT, it's tied to
YARR. So removing the #ifdef works.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
These symbols are supposed to be in one OR the other, not in both.
The relevant snippet in js/src/Makefile.in is:
ifeq (,$(MOZ_GLUE_PROGRAM_LDFLAGS))
# When building standalone, we need to include mfbt sources, and to declare
# exported mfbt symbols on its behalf when we use its headers.
include
Something else: mailcap support uses nsIProcess to start commands. These
wouldn't be covered either.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/159258
Title:
Helper applications launched
Something else: mailcap support uses nsIProcess to start commands. These
wouldn't be covered either.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/176902
Title:
kpdf locks sound output
To manage
Something else: mailcap support uses nsIProcess to start commands. These
wouldn't be covered either.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/102408
Title:
Helper apps inherit open file
Also note that mozgnome also may depend on libnotify. (mozilla builds
don't but distros' do)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/102408
Title:
Helper apps inherit open file descriptors
Also note that mozgnome also may depend on libnotify. (mozilla builds
don't but distros' do)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/159258
Title:
Helper applications launched by
Also note that mozgnome also may depend on libnotify. (mozilla builds
don't but distros' do)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/176902
Title:
kpdf locks sound output
To manage
(In reply to Karl Tomlinson (:karlt) from comment #73)
Helper apps should be fine in --enable-gio builds because
g_desktop_app_info_launch_uris also calls g_spawn_async without
G_SPAWN_LEAVE_DESCRIPTORS_OPEN.
Actually, Non-GNOME systems won't be covered with --enable-gio, because
the gio
(In reply to Karl Tomlinson (:karlt) from comment #73)
Helper apps should be fine in --enable-gio builds because
g_desktop_app_info_launch_uris also calls g_spawn_async without
G_SPAWN_LEAVE_DESCRIPTORS_OPEN.
Actually, Non-GNOME systems won't be covered with --enable-gio, because
the gio
(In reply to Karl Tomlinson (:karlt) from comment #73)
Helper apps should be fine in --enable-gio builds because
g_desktop_app_info_launch_uris also calls g_spawn_async without
G_SPAWN_LEAVE_DESCRIPTORS_OPEN.
Actually, Non-GNOME systems won't be covered with --enable-gio, because
the gio
Created attachment 603183
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
I refreshed the patch against current mozilla-inbound. Landry, can you
check I didn't break anything?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
(In reply to Marco Bonardo [:mak] from comment #67)
backed out as suspected for a bunch of jit tests failures in linux debug
builds
see
https://tbpl.mozilla.org/php/getParsedLog.php?id=9878244tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=9878570tree=Mozilla-Inbound
Well, if it's breaking linux debug builds, it means it's *not* only
shuffling ifdefs around. So you should start by checking that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
(In reply to Landry Breuil from comment #85)
(In reply to David Mandelin from comment #82)
Landry, following up on a hint from billm, I got your patch to work on Linux
with this addition:
diff -r e7bbcbb6c24a js/src/jscntxt.h
--- a/js/src/jscntxt.h Tue Mar 13 17:42:33 2012 -0700
The best place is probably js-config.h.in, so that external apps
building against the headers don't end up with the same problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
(In reply to Landry Breuil from comment #88)
Righto.. but ENABLE_YARR_JIT is not known when you're creating js-config.h,
since it's in Makefile.in. and ENABLE_YARR_JIT is needed to know if we need
to define ENABLE_ASSEMBLER. So ENABLE_YARR_JIT definition would have to go
to configure too ?
(In reply to David Mandelin from comment #91)
JSC sets those flags in what we imported as assembler/wtf/Platform.h, which
seems reasonable. In fact, I see they set ENABLE_ASSEMBLER in there
depending on various conditions, which is maybe why the patch works on most
platforms already.
Created attachment 588391
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
This is the bug I have for beta in Debian. Unfortunately, it doesn't apply to
aurora and m-c.
For me, this seriously raises the question as to whether we (mozilla) should be
adding
(In reply to Mike Hommey [:glandium] from comment #12)
Created attachment 588391
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
This is the bug
Err. the patch, not the bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
(In reply to Landry Breuil from comment #14)
Just to clarify.. is your patch in debian a build fix for fx 10.0beta on ppc
sparc, or only sparc ?
on platforms where YARR JIT is not supported
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hint: a lot of the !ENABLE_YARR_JIT uses really mean USE_PCRE.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To manage
That's why ENABLE_ASSEMBLER needs to be off.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To manage notifications about
Yes, but for sparc, it's more subtle: ENABLE_ASSEMBLER needs to be set
for the normal non YARR JIT. Man, what a mess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird
Created attachment 576542
Allow .js preference files to set locked prefs with lockPref()
Sorry for the noise, just testing hg bzexport. I'm still interested to
know who could review this, though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Created attachment 576542
Allow .js preference files to set locked prefs with lockPref()
Sorry for the noise, just testing hg bzexport. I'm still interested to
know who could review this, though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Created attachment 572068
Allow .js preference files to set locked prefs with lockPref()
Refreshed after the PRBool/bool change.
Now, as bsmedberg won't review it, and dwitte is essentially not around
anymore, who can review this?
--
You received this bug notification because you are a member
Created attachment 572068
Allow .js preference files to set locked prefs with lockPref()
Refreshed after the PRBool/bool change.
Now, as bsmedberg won't review it, and dwitte is essentially not around
anymore, who can review this?
--
You received this bug notification because you are a member
(In reply to comment #67)
So this is the culprit?
http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/md/unix/
uxproces.c#263
How exactly do you trigger this? I thought download code used GIO or
GnomeVFS now to spawn processes.
Is there any valid case for wanting to keep the file
(In reply to comment #67)
So this is the culprit?
http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/md/unix/
uxproces.c#263
How exactly do you trigger this? I thought download code used GIO or
GnomeVFS now to spawn processes.
Is there any valid case for wanting to keep the file
(In reply to comment #67)
So this is the culprit?
http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/md/unix/
uxproces.c#263
How exactly do you trigger this? I thought download code used GIO or
GnomeVFS now to spawn processes.
Is there any valid case for wanting to keep the file
If you're doing official releases, you also want to address bug 554088
at some point.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/740815
Title:
[FFe] Updates to enable us to drop xulrunner from
(In reply to comment #26)
Created attachment 521593 [details]
Fix SONAME
This ensures that the resulting binary has the right soname
(libmozjs185.so.1.0). tbh, I couldn't figure out a better way of doing this,
so
I'm not sure if anyone else has any better ideas
Why does it need to be
http://hg.mozilla.org/mozilla-central/rev/d253c44465ae
--
[MASTER] Firefox reports Gecko Engine Version in about:
https://bugs.launchpad.net/bugs/194894
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Created attachment 483431
Use nxIXULAppInfo to get application version number in about
Now that bug 349985 landed, this can be considered. Addressed concerns
from comment 16.
--
[MASTER] Firefox reports Gecko Engine Version in about:
https://bugs.launchpad.net/bugs/194894
You received this bug
(In reply to comment #18)
* Add a make dist target that generates spidermonkey-X.tar.gz to
js/src/Makefile.in
AFAIK, there is no make dist target to generate source tarballs for other
products. And there used to be spidermonkey releases, though it's been a while:
(In reply to comment #20)
Because it conceptually conflicts with a separate spidermonkey, assuming we
keep the same .so and .pc names. And if you were just interested in consuming
spidermonkey, why wouldn't you use /usr/lib/libmozjs.so.42 instead of being
coupled to Firefox's
(In reply to comment #20)
Because it conceptually conflicts with a separate spidermonkey, assuming we
keep the same .so and .pc names. And if you were just interested in consuming
spidermonkey, why wouldn't you use /usr/lib/libmozjs.so.42 instead of being
coupled to Firefox's
(In reply to comment #23)
Sure, though clearly separate tarballs are better. The larger question is
what
you do about the mozilla-js.pc file; in this case then, xulrunner-dev wouldn't
be providing it, right? Or do you have separate .pc files?
$ apt-file show libmozjs-dev | grep pkgconfig
(In reply to comment #23)
(In reply to comment #21)
Nothing prevents you to build spidermonkey from firefox and ship it in
/usr/lib. That's what we do in Debian, and it has worked for a quite long
time.
Sure, though clearly separate tarballs are better.
They also complicate things.
(In reply to comment #27)
Ok. Does your libxul.so (xulrunner package) depend on libmozjs.so (libmozjs
package), or are they on potentially separate schedules?
Package: xulrunner-1.9.2
Depends: (...) libmozjs3d (= 1.9.2.13-1) (...)
(I even force a strict dependency, version wise, though not
(In reply to comment #28)
Package: xulrunner-1.9.2
Depends: (...) libmozjs3d (= 1.9.2.13-1) (...)
(I even force a strict dependency, version wise, though not strictly
necessary)
(Both packages come from the same source (iceweasel) package)
--
You received this bug notification because
I concur with Karl. In fact, those crashes might be related to bug
920200.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
[regression] GLib-CRITICAL **: g_slice_set_config: assertion
(In reply to Chris Coulson from comment #0)
On Linux, the glib slice allocator is disabled in |XREMain::XRE_main| by
calling |g_slice_set_config| (see bug 431221). However, this no longer works
since glib 2.35 because libgobject (which libxul depends on) now has a
static initializer which
gah these things are confusing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
[regression] GLib-CRITICAL **: g_slice_set_config: assertion
`sys_page_size == 0' failed
To manage
It depends if you are talking about runtime requirements or build-time
requirements.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1051559
Title:
Build Firefox with GStreamer support
To manage
Comment on attachment 8367119
replace g_slice_set_config with G_SLICE env var
Review of attachment 8367119:
-
Considering g_slice_set_config is only deprecated at the moment, I'd rather use
it and fallback to environment variables
(In reply to Karl Tomlinson (back Jan 28 :karlt) from comment #44)
On irc, glandium indicated that he would prefer to dlopen libglib (before
anything depends on libgobject) and use the deprecated g_slice_set_config
internal debugging api, than follow Matthias' suggestion to use
Comment on attachment 713377
Store Master Password by using libsecret to Gnome Keyring patch v1
Review of attachment 713377:
-
::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +800,5 @@
+ rv =
Comment on attachment 713377
Store Master Password by using libsecret to Gnome Keyring patch v1
Review of attachment 713377:
-
::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +800,5 @@
+ rv =
(In reply to Alexander Korsunsky from comment #114)
This HAS been implemented as an addon:
https://github.com/infinity0/mozilla-gnome-keyring
The problem is that it has to be a binary add-on (...)
This isn't true. jsctypes can be used to call whatever APIs the binary
addon uses.
--
You
(In reply to Alexander Korsunsky from comment #114)
This HAS been implemented as an addon:
https://github.com/infinity0/mozilla-gnome-keyring
The problem is that it has to be a binary add-on (...)
This isn't true. jsctypes can be used to call whatever APIs the binary
addon uses.
--
You
(In reply to Karl Tomlinson (:karlt) from comment #27)
It seems unfortunate that different libraries and apps have a need to
implement their own allocators.
It seems unfortunate that disabling a library's internal allocator is an
internal debugging API
--
You received this bug notification
(In reply to jhorak from comment #79)
Thanks for feedback.
The ustr or NS_LL is char16_t*. I'm not sure if I can safely cast it to
PRUnichar), can I?
Note you can't use u because that's only supported in c++11 mode, and
we still support not building in that mode.
--
You received this bug
(In reply to jhorak from comment #79)
Thanks for feedback.
The ustr or NS_LL is char16_t*. I'm not sure if I can safely cast it to
PRUnichar), can I?
Note you can't use u because that's only supported in c++11 mode, and
we still support not building in that mode.
--
You received this bug
Comment on attachment 581198
Try creating a named cursor before a bitmap cursor (v2)
[Approval Request Comment]
User impact if declined: Regression in aspect of various mouse cursors not
following the system theme on Linux systems in Firefox with
ui.use_activity_cursor set to true, and in
(In reply to Mike Hommey [:glandium] from comment #17)
Risk to taking this patch (and alternatives if risky):
(forgot to fill here) very low risk, and has been tested widely for a
while now (since it was released in 11). It would be nice if it was
applied on ESR, though.
--
You received this
(In reply to Landry Breuil from comment #115)
So let's try to get this reviewed and hope this time it sticks. Only change
from att 619876 is indentation fixed in Makefile.in (use tabs) and
(defined(WTF_CPU_PPC) !defined(JS_CPU_PPC_OSX)) for using the dummy
cacheFlush.
You should use
What might work, is to remove the error and put nothing to replace it.
Adding a JIT for a new platform will make the function required, and
compilation will fail because it is completely missing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
(In reply to Landry Breuil from comment #117)
So that'd mean replacing :
#error The cacheFlush support is missing on this platform.
by
static void cacheFlush(void*, size_t)
{
#warning Using dummy generic empty cacheFlush for this platform.
}
Do you think that'll work out ? Since
https://hg.mozilla.org/integration/mozilla-inbound/rev/f5a3a7b9c6b0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To
A safe way to implement cacheFlush that would be to have a dummy implementation
that does nothing (cacheFlush is completely unimportant when there is no JIT),
with the following preprocessor goop (or something similar):
#ifndef ENABLE_ASSEMBLER
#error cacheFlush unimplemented for this platform
(In reply to Chris Coulson from comment #14)
Created attachment 602368
Treat distribution/searchplugins as a known location and don't use the full
path for the search engine ID's
We've been carrying a distro patch for a long time to do the normalize() in
_loadEnginesFromDir(), and I'd like
(In reply to comment #59)
Who would I have to blackmail to get more recent Nouveau drivers into
experimental?
You can try debia...@lists.debian.org directly, or file a wishlist bug
against xserver-xorg-video-nouveau.
--
You received this bug notification because you are a member of Ubuntu
Using cairo 1.10.0 and pixmap 0.21.2, everything is displayed gracefully
on 4.0b8 built against system cairo, on intel display. (iceweasel from
http://mozilla.debian.net/packages/, and cairo and pixmap from current
debian experimental, for those who care).
Nouveau drivers are likely to be the
(In reply to Matt Woodrow (:mattwoodrow) from comment #35)
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5fb4abaa3f
Matt, can you get this landed on beta?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Ubuntu also does Firefox builds on armhf.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1398898
Title:
[armhf] segfaults when trying to save a file
To manage notifications about this bug go to:
And, in fact, Fedora does too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1398898
Title:
[armhf] segfaults when trying to save a file
To manage notifications about this bug go to:
(In reply to Jacob Bramley [:jbramley] from comment #35)
Doesn't this affect Android too? They use armhf these days, I believe.
Android builds use softfp afaik.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
If every distro uses a different key, then Google can distinguish which
distro users are using. Wouldn't that qualify as a privacy breach? IIRC,
we explicitely don't send the google cookie for safebrowsing. If we
don't do that for geoloc, that would seem like a bug. OTOH, they can
probably
(In reply to Chris Coulson from comment #17)
The next Firefox update on Ubuntu will have this fixed
How are you fixing this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1401402
Title:
Ubuntu
(In reply to noitidart from comment #83)
(In reply to Mike Hommey [:glandium] from comment #82)
Comment on attachment 8573128
Backout the part that removed -remote
Approval Request Comment: See comment 64
Considering how late we are in the beta cycle, it's more reasonable to get
Comment on attachment 8573128
Backout the part that removed -remote
That being said, I can see a point in being more conservative for the
upcoming ESR.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Comment on attachment 8573128
Backout the part that removed -remote
Approval Request Comment: See comment 64
Considering how late we are in the beta cycle, it's more reasonable to
get this on 37. 38 will get the alternative approach.
--
You received this bug notification because you are a
(In reply to noitidart from comment #85)
(In reply to Mike Hommey [:glandium] from comment #84)
(In reply to noitidart from comment #83)
(In reply to Mike Hommey [:glandium] from comment #82)
Comment on attachment 8573128
Backout the part that removed -remote
Approval
(In reply to noitidart from comment #69)
Quick update, another thing this broke is the Windows 7 + jump menu:
http://i.imgur.com/OiyEzUI.png
This makes no sense, those are not using -remote:
https://dxr.mozilla.org/mozilla-
central/source/browser/modules/WindowsJumpLists.jsm#91
--
You
(In reply to Jean-Yves Perrier [:teoli] from comment #75)
So, if I'm following correctly: -remote was removed in Fx 36, readded in the
chemspill 36.0.1 and won't be removed in 37 at least?
Is this correct (We also need to update Fx 36 for devs).
Err, I missed a not in my sentence. It is
It's in 36.0.1, but it's guaranteed to still be there in 37.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425972
Title:
Firefox no longer supports -remote parameter
To manage notifications about
(In reply to noitidart from comment #80)
(In reply to Pavlos Touboulidis from comment #79)
(In reply to noitidart from comment #78)
I opened my 2nd profile with this:
firefox.exe -P Dev -no-remote
Try firefox.exe -P Dev -new-instance
Thanks Pavlos I tried that.
1) firefox.exe
(In reply to Karl Tomlinson (ni?:karlt) from comment #122)
> Comment on attachment 8630422
> Replace g_slice_set_config() with G_SLICE environment variable
>
> The g_type_init() call has been dropped.
> I don't know of a static constructor using GSlice in GLib 2.32.
Yeah, I was mistaken, I
Backed out for gtest bustage:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f955560a47
23:59:34 INFO - GThread-ERROR **: GThread system may only be initialized
once.
23:59:34 INFO - aborting...
23:59:34 INFO - Redirecting call to abort() to mozalloc_abort
23:59:35 WARNING
Created attachment 8628085
Replace g_slice_set_config() with G_SLICE environment variable
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
GLib-CRITICAL **: g_slice_set_config:
Created attachment 8630422
Replace g_slice_set_config() with G_SLICE environment variable
Turns out there aren't many places where g_thread_init is actually
called. There's some webrtc code that we don't build, and other than
that, other uses are exclusive... but need to be factored in, so this
... and it so happens that we're calling g_thread_init(NULL) from
different places, and likely crash for that reason with older glib...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1160569
Title:
Created attachment 8631479
Replace g_slice_set_config() with G_SLICE environment variable
Not enough changes to require another review from Nathan. This should
address your concerns.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
(In reply to Karl Tomlinson (ni?:karlt back June 30) from comment #112)
> I had intentionally chosen not to override an existing G_SLICE environment
> variable so that this could be overridden or debug-blocks could be used if
> desired. That's not a show-stopper, but avoiding overriding would
Created attachment 8626818
0001-Bug-833117-Replace-g_slice_set_config-with-G_SLICE-e.patch
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people
(In reply to Mike Hommey [:glandium] from comment #117)
> Backed out for gtest bustage:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/c0f955560a47
>
> 23:59:34 INFO - GThread-ERROR **: GThread system may only be initialized
> once.
And this error was removed in glib 2.23.x 5 years
FWIW, Gtk+3 >= 3.10 has gdk_x11_window_get_desktop() and
gdk_x11_window_move_to_desktop() functions... which, if you ask me, is
shortsighted, since it's limited to X11, and won't work in Wayland.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
It was removed in 39.0. I updated https://developer.mozilla.org/en-
US/docs/Mozilla/Command_Line_Options#-remote_remote_command to some
extent.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1425972
The syntax is a triviality of the patch. The core problem here is that
there's no one to review the patch so that it possibly lands.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/541951
Title:
(In reply to Mike Kaply [:mkaply] from comment #39)
> Oddly, this document:
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> A_brief_guide_to_Mozilla_preferences
>
> Says we already support lockPref in JS files?
It says: "All preferences files may call pref(), user_pref() and
>From a quick glance at the history of the patch in Debian, in the past 5
years, I had to do actual but trivial code changes twice, and adapt to
context changes twice (one of them having been the change from PRBool to
bool)
--
You received this bug notification because you are a member of Ubuntu
Comment on attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
>From b8015e0754742650a4877de9ebe7d6db2671970d Mon Sep 17 00:00:00 2001
>From: Mike Hommey
>Date: Sat, 21 Jun 2008 02:48:46 +0200
>Subject: [PATCH] Allow .js preference files to set locked prefs with
>
The preferences code is being heavily refactored, and this needs to wait
a bit for things to settle first. That being said, I do think the ideal
timing for this would be to get it into 60. Nick, what do you think?
--
You received this bug notification because you are a member of Ubuntu
Bugs,
(In reply to Mike Kaply [:mkaply] from comment #28)
> I really don't want it being called lockPref. That will confuse it with the
> autoconfig "lockPref" function.
What is confusing? It's the same syntax. The only difference aiui, is
the execution environment, which means autoconf can do more
Created attachment 8613433
Allow .js preference files to set locked prefs with lockPref()
Refreshed after bug 1098343. Benjamin, would you like to review this,
this time, considering comment 26?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
1 - 100 of 122 matches
Mail list logo
