On Mon, 2 Jan 2012, Jonathan Nieder wrote:
chromium isn't available from backports.d.o.
Do you think it would make sense to add it there, and if so, would you
be willing to work on it? What change, if any, should be made to the
standard chromium package to support that?
The main thing I
On Sun, 13 May 2012, Ariel wrote:
The main thing I had an issue with when backporting it for myself was the
versioned dependency on libcups2-dev = 1.5.0.
Installing that from testing pulled a huge number of other packages along
with it.
Everything else was available from backports or was
I found this bug because of experiencing the same failure. I use
squeeze but installed with apt-get install -t testing chromium-browser
The --single-process option corrects the problem for me.
Mark
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Michael Gilbert michael.s.gilb...@gmail.com wrote:
Yes, I looked at a diff, but it wasn't immediately obvious which
change would actually solve the problem.
i think we have a misunderstanding here, i never claimed to have a
solution for the fix, rather, i reopened this bug *because* it still
On 01/04/2012 12:44 AM, Michael Gilbert wrote:
Which settings in particular do you know of that make the chromium
backport work?
haven't you looked at the git repository[0]? e.g. 'git diff
debian-wheezy..progress-artax-backports' gives all the changes.
citing from changelog:
---snip---
On Wed, Jan 4, 2012 at 4:29 AM, Daniel Baumann wrote:
On 01/04/2012 12:44 AM, Michael Gilbert wrote:
Which settings in particular do you know of that make the chromium
backport work?
haven't you looked at the git repository[0]? e.g. 'git diff
debian-wheezy..progress-artax-backports' gives
What change, if any, should be made to the
standard chromium package to support that?
like other packages do, chromium-browser should build-depend on
lsb-release and default automatically to certain settings depending on
if it's build on sid or squeeze.
Which settings in particular do you
reopen 647992
found 16.0.912.63~r113337-1
severity 647992 normal
thanks
Hi,
the issue still persists when backporting for squeeze. builds (any
version 14 till 16 is affected by it atm) can be found at:
unmerge 647992
clone 647992 -1
merge -1 647994
submitter 647992 Daniel Baumann daniel.baum...@progress-technologies.net
tags 647992 = squeeze
block 647992 by 651912
retitle 647992 [squeeze-backports] chromium: unrecoverable Aw, Snap! on start up
quit
Daniel Baumann wrote:
the issue still
severity 647992 wishlist
tags 647992 + moreinfo
quit
Hi again,
Daniel Baumann wrote:
the issue still persists when backporting for squeeze.
[...]
the builds are done against plain squeeze plus backports of libv8, nss,
nspr, and cairo (which is the same you would get on backports.d.o i
On 01/02/2012 09:37 PM, Jonathan Nieder wrote:
Do you think it would make sense to add it there
imho yes.
would you be willing to work on it
to the extend as its relevent for the derivative, other than that, no.
however, my git tree is public, anyone can always pick from it in case
there
Mattia Monga wrote:
Chromium starts with a Aw, Snap! page and it is stuck on that.
Still not clear what the underlying cause is (maybe libnspr is not
available in the sandboxed renderers to resolve weak references or
something like that), but here's a patch to get back to the version 14
Package: chromium
Version: 15.0.874.106~r107270-1
Severity: grave
Justification: renders package unusable
Chromium starts with a Aw, Snap! page and it is stuck on that.
Using an empty user-data-dir doesn't help. I managed to get it working by using
the --single-process option. Since I get a
merge 647992 648018 648035
quit
Mattia Monga wrote:
Using an empty user-data-dir doesn't help. I managed to get it working by
using the --single-process option.
Yep, that's inconvenient.
Backtrace: [1]
It seems that the segfault is happening somewhere within
14 matches
Mail list logo
