To clarify I'm one of the upstream bubblewrap maintainers, if you have
any concerns don't hesitate to file an issue upstream, but we can chat
here too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/170
> bubblewrap is setuid
Doesn't Ubuntu have unprivileged userns available, just like e.g.
Fedora? If so, then bwrap isn't setuid, and offers no more attack
surface than the kernel does to every process (that doesn't have access
to CLONE_NEWUSER denied via e.g. seccomp, as e.g. Docker does by defau
(In reply to comment #7)
> > From my reading of the manual page (haven't looked at the source),
> > it looks to me like you need to free() the individual elements too.
>
> Not according to the manpage for putenv(), which states that the string
> passed to putenv() becomes part of the environment d
Comment on attachment 76324
pkexec: Set process environment from pam_getenvlist()
Review of attachment 76324:
-
::: src/programs/pkexec.c
@@ +182,5 @@
> +{
> + guint n;
> + for (n = 0; envlist[n]; n++)
> +putenv
Tentative patch submitted here
https://bugzilla.gnome.org/show_bug.cgi?id=691987
** Bug watch added: GNOME Bug Tracker #691987
https://bugzilla.gnome.org/show_bug.cgi?id=691987
** Also affects: gdm via
https://bugzilla.gnome.org/show_bug.cgi?id=691987
Importance: Unknown
Status: U
This is a key bit:
Jan 17 07:54:33 workstation gnome-session[2959]: WARNING: Application
'gnome-shell.desktop' killed by signal 11
The lock screen is integrated into the compositor (gnome-shell) in 3.6.
An unfortunate side effect of this is that if the compositor crashes, it
will get auto-restart
GJS changes to support this release:
https://bugzilla.gnome.org/show_bug.cgi?id=646369
--
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 #30)
>
> Since we're deliberately changing the name, maybe libspidermonkey is a better
> name? I agree that putting 185 in the name isn't good. When we change to
> 1.9.0,
> would we have to change the SO name? That can't be right.
I don't think it matters a lot, honestly. I
Created attachment 521641
add pkg-config file
--
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 main
--
ubuntu-bugs mailing list
ubuntu-
(In reply to comment #20)
> Colin -- I checked in "configure" in purpose - it's part of the source tarball
> (which is what that repo tracks). The idea is to eliminate autoconf-2.13 as a
> dependency for projects embedding SpiderMonkey and building from (or
> incorporating) the source tarball.
No
A couple more things:
* The js-config script will conflict. Not quite sure what to do with it; most
"distros" ship pkg-config, which is really better in all conceivable ways.
* Speaking of pkg-config, this does *not* ship a .pc file (it lives in
mozilla-central/xulrunner/installer). Would you
Hi Wes, thanks a ton for your work here!
* You seem to have "configure" checked in to the hg repo, since it's
generated it shouldn't be (and it's not in mozilla-central)
Actually I'm getting a build error on RHEL6 I need to debug before I do
further checking.
--
You received this bug notificati
(In reply to comment #25)
>
> $ apt-file show libmozjs-dev | grep pkgconfig
> libmozjs-dev: /usr/lib/pkgconfig/mozilla-js.pc
Ok. Does your libxul.so (xulrunner package) depend on libmozjs.so
(libmozjs package), or are they on potentially separate schedules?
--
You received this bug notificatio
(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. The larger question
is what you do about the mozilla-js.pc fi
(In reply to comment #19)
> (In reply to comment #18)
> > * Remove the Firefox configure flag --enable-shared-js
>
> Why would we do this?
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 spi
I think a fundamental thing here is that there's a large world between:
[API changes all the time] -- ... -- [ stable API/ABI ]
In particular, in the middle area, there are small things that the
SpiderMonkey consuming community would greatly benefit from that don't
restrict SpiderMonkey really.
I would really appreciate if Hardy and Fedora 9 both used the same
behavior, as it reduces user confusion.
Your suggestion would change the behavior of the single-workspace case.
The reason I chose to patch Metacity is simple - it makes Firefox match
the behavior it has on both Windows and MacOS X
Just a note, Fedora is currently using the patch from the GNOME bug for
Fedora 9.
--
Firefox-3.0 window moves to current workspace
https://bugs.launchpad.net/bugs/175904
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mai
18 matches
Mail list logo
