Hello,
That's really funny. 😀
On Wed, Feb 1, 2017 at 12:01 PM, Michael Meskes wrote:
> Hi,
>
> could anyone please enlighten me why we have a chromium version in stable
> security that is newer than what we have in unstable? The same version I
> did
> find, though, in experimental. However, I wo
Hi,
could anyone please enlighten me why we have a chromium version in stable
security that is newer than what we have in unstable? The same version I did
find, though, in experimental. However, I wonder if anything not stable
enough(?) for unstable can make it into stable security. Or the other w
On 07/06/2011 08:52 PM, Aaron Toponce wrote:
> I would like to mimic the build process of the chromium-browser as closely
> as possible on a development system, but I am unaware of the process that
> the Debian Chromium Package Maintainers use. I'm not as interested as
> building
On Fr, 18 Feb 2011, Daniel Leidert wrote:
> > [Added Associations]
> > x-scheme-handler/http=iceweasel.desktop;
> > x-scheme-handler/https=iceweasel.desktop;
>
> into $HOME/.local/share/applications/mimeapps.list.
YEAHHH!!! Finally someone who stepped forward and *explained* what to
do instead o
Am Freitag, den 11.02.2011, 17:11 +0100 schrieb Leo "costela" Antunes:
> On 11/02/11 16:49, Norbert Preining wrote:
> > On Fr, 11 Feb 2011, Cyril Brulebois wrote:
> >> $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache
> >> x-scheme-handler/http=midori.desktop;chromium-browser.desk
Le mardi 15 février 2011 à 11:30 +0100, Fabian Greffrath a écrit :
> > The disappearance of this applet in git master is very concerning, but I
> > just received mention on IRC (thanks fredp) that the functionality will
> > be back soon.
>
> I see, it will most probably become part of the System
The disappearance of this applet in git master is very concerning, but I
just received mention on IRC (thanks fredp) that the functionality will
be back soon.
I see, it will most probably become part of the System Information tab:
http://live.gnome.org/Design/SystemSettings/SystemInformation
Le lundi 14 février 2011 à 15:33 +0100, Fabian Greffrath a écrit :
> It seems the panel to set the preferred applications has been removed
> from future versions of the control center on purpose of the GNOME
> developers:
>
> http://osdir.com/ml/fedora-development/2011-02/msg00116.html
The dis
Le mardi 15 février 2011 à 01:03 +0900, Norbert Preining a écrit :
> > The defaults are set in /etc/gnome/defaults.list. This file is used in
>
> And per user?
.local/share/applications/defaults.list and mimeapps.list
The former sets defaults associations, the latter is necessary to add
associat
On Mo, 14 Feb 2011, Josselin Mouette wrote:
> > How is that default communicated? An environment variable? A gconf key?
>
> The defaults are set in /etc/gnome/defaults.list. This file is used in
And per user?
> Good. We can probably let it migrate once epiphany and iceweasel have
> been fixed; u
Le lundi 14 février 2011 à 14:28 +0100, Raphael Hertzog a écrit :
> On Mon, 14 Feb 2011, Josselin Mouette wrote:
> > There will be a default selected in gnome-session, that can be changed
> > by user action. Without a session-wide default (any session manager can
> > set one, of course) a random c
There will be a default selected in gnome-session, that can be changed
by user action. Without a session-wide default (any session manager can
set one, of course) a random choice (possibly alphabetical) is used.
It seems the panel to set the preferred applications has been removed
from future v
On Mo, 14 Feb 2011, Josselin Mouette wrote:
> We are used to have much more terrible breakage in testing/unstable
> right after a release. If our concerns are now bugs wrt. setting the
> default browser, it must mean we are doing *great* :)
Aehmm, I have set the default browser in about 10 places
On Mon, 14 Feb 2011, Josselin Mouette wrote:
> > How is one supposed to prioritize between the various browsers?
>
> There will be a default selected in gnome-session, that can be changed
> by user action. Without a session-wide default (any session manager can
> set one, of course) a random choic
On Lu, 14 feb 11, 12:33:49, Josselin Mouette wrote:
> >
> > How is one supposed to prioritize between the various browsers?
>
> There will be a default selected in gnome-session, that can be changed
> by user action. Without a session-wide default (any session manager can
> set one, of course) a
Le lundi 14 février 2011 à 12:26 +0100, Raphael Hertzog a écrit :
> > There are defaults shipped in gnome-session, precisely to avoid that
> > kind of issue.
> >
> > With glib 2.28, the x-scheme-handler/* stuff becomes the new priority.
> > It just means we have to update epiphany to include it a
Hi,
On Mon, 14 Feb 2011, Josselin Mouette wrote:
> Le samedi 12 février 2011 à 01:15 +0900, Norbert Preining a écrit :
> > > I'd say it should probably be reported as a minor bug in gvfs-open, to
> > > respect gnome settings before falling back to mimeinfo.cache.
> >
> > I consider that not mino
Le samedi 12 février 2011 à 01:15 +0900, Norbert Preining a écrit :
> > I'd say it should probably be reported as a minor bug in gvfs-open, to
> > respect gnome settings before falling back to mimeinfo.cache.
>
> I consider that not minor. If alphabetic order is what I am forced to
> live with, t
On Fr, 11 Feb 2011, Josh Triplett wrote:
> See http://bugs.debian.org/612876 for the bug report. I encountered the
> same issue, and finally found the culprit through reading the
> chromium-browser changelog.
Umpf, I have removed the x-scheme-handler/http and x-scheme-handler/https
See http://bugs.debian.org/612876 for the bug report. I encountered the
same issue, and finally found the culprit through reading the
chromium-browser changelog.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
> iceweasel.desktop doesn't really solve the issue, because there doesn't
> seem to be a mechanism to define priorities in update-desktop-database,
> so gvfs-open uses the first entry in mimeinfo.cache.
Umpf, so we are either forced to always use what comes
alphabetically first, or remove package
On 11/02/11 16:49, Norbert Preining wrote:
> On Fr, 11 Feb 2011, Cyril Brulebois wrote:
>> $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache
>> x-scheme-handler/http=midori.desktop;chromium-browser.desktop;
>> x-scheme-handler/https=midori.desktop;chromium-browser.desktop;
>>
>> A
On Fr, 11 Feb 2011, Cyril Brulebois wrote:
> $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache
> x-scheme-handler/http=midori.desktop;chromium-browser.desktop;
> x-scheme-handler/https=midori.desktop;chromium-browser.desktop;
>
> And it takes precedence over what you quoted.
Tha
Norbert Preining (12/02/2011):
> I checked:
> - alternatives of: x-www-browser, sensible-browser, www-browser, gnome-browser
> and all of them point to iceweasel
> - checked the "preferred applications" in GNOME and it also shows
> iceweasel
> - checked with
> xdg-settings get default-web
Hi everyone, esp chromium and mime devs,
since some time chromium has taken over all http/https urls. I checked
every place I could for the correct settings, but I didn't manage to
find the real culprit. It seems that gnome/VTE/whatever uses xdg-open,
which in turn uses gvfs-open.
Reading through
On 08/10/2010 09:25 PM, Adam D. Barratt wrote:
>> > Chromium isn't meant to be released with Squeeze. We'll reevaluate for
>> > Squeeze+1.
> Is that still the case?
No, it isn't. Please see #581265 and in particular message #32, #37 and #44
Cheers,
Giuseppe.
signature.asc
Description: OpenPGP
75600 (tagged wontfix). Moreover, Debian's copy of
> > ffmpeg will always be out-of-date.
> >
> > I wonder why the security team hasn't vetoed this move...
>
> Chromium isn't meant to be released with Squeeze. We'll reevaluate for
> Squeeze+1.
Is that
On Wed, Jun 30, 2010 at 06:27:43AM -0600, Aaron Toponce wrote:
> On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
> > On 06/30/2010 06:15 AM, Aaron Toponce wrote:
> >> I just noticed that the chromium-browser package releases in Debian
> >> GNU/Linux unstable are sync
On Mi, 30 iun 10, 06:27:43, Aaron Toponce wrote:
>
> Well, when you put it that way. :) Honestly, I don't think of Sid as a
> collection of stable packages. That's what I think about Lenny. I think
> of Sid as "the latest and greatest", regardless of version, and that's
> why I thought the nightli
Aaron Toponce wrote:
> On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
>> Should we use the Chromium nightly builds ? Really? :)
>
> Well, when you put it that way. :) Honestly, I don't think of Sid as a
> collection of stable packages. That's what I think about Lenny. I think
> of Sid as "the l
On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
> On 06/30/2010 06:15 AM, Aaron Toponce wrote:
>> I just noticed that the chromium-browser package releases in Debian
>> GNU/Linux unstable are synced version-for-version with the google-chrome
>> beta package provided by the 3
On Tue, Jun 29, 2010 at 10:15:11PM -0600, Aaron Toponce wrote:
> I just noticed that the chromium-browser package releases in Debian
> GNU/Linux unstable are synced version-for-version with the google-chrome
> beta package provided by the 3rd party Google Linux repository. Is this
>
On 06/30/2010 06:15 AM, Aaron Toponce wrote:
> I just noticed that the chromium-browser package releases in Debian
> GNU/Linux unstable are synced version-for-version with the google-chrome
> beta package provided by the 3rd party Google Linux repository. Is this
> intentional?
No, w
I just noticed that the chromium-browser package releases in Debian
GNU/Linux unstable are synced version-for-version with the google-chrome
beta package provided by the 3rd party Google Linux repository. Is this
intentional? What's the rationale behind using the beta releases for
chromium-br
Package: wnpp
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I request assistance with maintaining the chromium-browser package.
In reality, the team mentioned in the Maintainer field currently consists of me.
This package really needs a team to work on it.
Alioth project
On Thu, May 13, 2010 at 03:34:06 (CEST), Andreas Marschke wrote:
>> What I could imagine is to seperate out the ffmpeg module into a
>> seperate source package, and ship it in a 3rd party repository outside
>> of debian squeeze.
>>
> Wouldn't this be a perfect candidate for debimedia?
Probably
> What I could imagine is to seperate out the ffmpeg module into a
> seperate source package, and ship it in a 3rd party repository outside
> of debian squeeze.
>
Wouldn't this be a perfect candidate for debimedia? And since it's the source
code only that we distribute with the package it shouldn
.
>
>
Just so you know, ffmpeg-0.6 which sits in NEW is meant for
experimental. Furthermore, there's currently no plans to move it into
unstable until after the release of Squeeze.
Here's a preliminary patch that allows chromium-browser to build with
system ffmpeg-0.5.1. This is
;s no more the fault of chromium-browser than it's the
fault of the other 2 copies. All in all, we can all easily guess that
the number of our users interested in using chromium-browser (i.e. one
of our priorities) matches quite easily the number of our users
interested in using the other two fr
Il 12/05/2010 06:38, Reinhard Tartler ha scritto:
> TBH, I'm very skeptical. While I'm not sure why google has decided to
> choose astrange's branch/fork, I fear that there have been too many
> changes to the external public API that this is not going to work out.
> I'm basing this opinion on the G
On 2010-05-11, Stefano Zacchiroli wrote:
> I understand that the security team might be skeptical about security
> support, but IIRC past vetoes from the security team came from software
> with bad _history_ of security support, while in this case it would seem
> a preemptive move, isn't it?
It i
en compile against ffmpeg 0.5 (debian' system) ffmpeg.
It would be of course interesting to see how this works out with ffmpeg
0.6 (currently in NEW), but for totally unrelated reasons to this one, I
fear it won't be processes as well, just like mplayer.
> At worst, if that will turn o
; patch chromium to work with the system ffmpeg headers.
>
> chromium doesn't link against the ffmpeg libraries, it dlopen() them, so
> you are right for libavcodec52 libavformat52, but for libavutil50
> it searches /usr/lib/chromium-browser/libavutil.so.50 , and this is a
> s
king on
compiling against system ffmpeg and not using at all the private copy of
ffmpeg, so that shouldn't be a showstopper. At worst, if that will turn
out not to be possible, we can disable ffmpeg support (as a last resort)
and still ship chromium-browser in Squeeze (unless of course other RC
nst the ffmpeg libraries, it dlopen() them, so
you are right for libavcodec52 libavformat52, but for libavutil50
it searches /usr/lib/chromium-browser/libavutil.so.50 , and this is a
symlink to /usr/lib/libavutil.so.50 .
If it doesn't find it you have the "Aw, Snap!" message or the
On 2010-05-11, Reinhard Tartler wrote:
> On Mon, May 10, 2010 at 22:36:00 (CEST), Giuseppe Iuculano wrote:
>
>> Chromium in Debian is built against the system FFmpeg headers via
>> pkg-config. This means when Chromium is launched it will assume that
>> FFmpeg is present in the system library path
On Tue, May 11, 2010 at 17:27:31 (CEST), Giuseppe Iuculano wrote:
> severity 580947 important
> thanks
For the record, after reading your latest mail, I still disagree with
this assessment, but won't play BTW ping pong.
> Il 11/05/2010 10:44, Reinhard Tartler ha scritto:
>> I can only assume tha
On Tue, May 11, 2010 at 17:27:31 +0200, Giuseppe Iuculano wrote:
> There was another solution, and this is now adopted in the latest
> experimental package, Compile with use_system_ffmpeg=1 and
> build_ffmpegsumo=0, but use the in-sources include path for headers, see
> [1] and [2].
>
> In this w
On Tue, May 11, 2010 at 05:27:31PM +0200, Giuseppe Iuculano wrote:
[...]
> chromium doesn't compile with the current version of ffmpeg in unstable
> because it is too outdated, this means I had three choices:
>
> - compile with use_system_ffmpeg=0 and build_ffmpegsumo=0 (this means
> drop ffmpeg s
t searches also libavutil50, this is in not yet in the
archive, it is in NEW (experimental) or in debian-multimedia repository.
[1]http://patch-tracker.debian.org/patch/series/view/chromium-browser/5.0.375.29~r46008-2/ffmpeg-no-pkgconfig.patch
[2]http://src.chromium.org/viewvc/chrome/trunk/src/
On Tue, May 11, 2010 at 10:22:02 (CEST), Philipp Kern wrote:
> On 2010-05-11, Reinhard Tartler wrote:
>> [1] http://experimental.ftbfs.de/chromium-browser (unavailable at time
>> of writing)
>
> experimental.ftbfs.de is down for good. I guess you meant [0] or simi
Hi,
On 11/05/10 10:13, Reinhard Tartler wrote:
> [1] http://experimental.ftbfs.de/chromium-browser (unavailable at time
> of writing)
Experimental is now on buildd.d.o, see
https://buildd.debian.org/status/package.php?p=chromium-browser&suite=experimental
Cheers,
Emilio
--
To U
On 2010-05-11, Reinhard Tartler wrote:
> [1] http://experimental.ftbfs.de/chromium-browser (unavailable at time
> of writing)
experimental.ftbfs.de is down for good. I guess you meant [0] or similar.
Kind regards,
Philipp Kern
[0]
https://buildd.debian.org/status/package.php?p=ch
er_5.0.375.29\~r46008-3_i386.deb, it turns out that the
package ships the following symlinks:
./usr/lib/chromium-browser/libavcodec.so.52 -> ../libavcodec.so.52
./usr/lib/chromium-browser/libavformat.so.52 -> ../libavformat.so.52
./usr/lib/chromium-browser/libavutil.so.50 -> ../libavuti
Reinhard Tartler wrote:
> Surely not. Chromium ships a *private* copy of ffmpeg, more precisely, a
> fork of ffmpeg called ffmpeg-mt. Debian does not include ffmpeg-mt
> because of bug #575600 (tagged wontfix). Moreover, Debian's copy of
> ffmpeg will always be out-of-date.
>
> I wonder why the se
On Mon, May 10, 2010 at 22:15:28 (CEST), Iker Salmón San Millán wrote:
> Hi, i didn't know where or how to report this, but i have readed in a forum
> that an user has tried chromium-browser from experimental and seems that it
> includes by default those privative codecs.
As oth
On Mon, May 10, 2010 at 22:36:00 (CEST), Giuseppe Iuculano wrote:
> Chromium in Debian is built against the system FFmpeg headers via
> pkg-config. This means when Chromium is launched it will assume that
> FFmpeg is present in the system library path. In this way you can
> decide which codecs c
On Monday 10 May 2010 17:36:59 Sven Arvidsson wrote:
> On Mon, 2010-05-10 at 22:36 +0200, Giuseppe Iuculano wrote:
> > If you can watch youtube html5 video, probably you have installaed
> > libavcodec52, libavformat52 and libavutil50 from debian-multimedia[1] or
> > other third repositories.
>
> W
Giuseppe Iuculano writes:
> If you can watch youtube html5 video, probably you have installaed
> libavcodec52, libavformat52 and libavutil50 from debian-multimedia[1] or
> other third repositories.
Hmm? Mplayer in debian unstable plays youtube h.264 just fine. No
non-free stuff needed:
$ youtube
On Mon, 2010-05-10 at 22:36 +0200, Giuseppe Iuculano wrote:
> If you can watch youtube html5 video, probably you have installaed
> libavcodec52, libavformat52 and libavutil50 from debian-multimedia[1] or
> other third repositories.
Why? Debian ships decoders for H264, so it should work out of the
On 05/10/2010 10:44 PM, Iker Salmón San Millán wrote:
> I didn't report as a bug because there wasn't anything wrong with the
> usability, i tought it was something that goes against debian social
> contract.
Which would still be a bug, with a a release critical severity.
Best thing to do in such
El 10 de mayo de 2010 22:36, Giuseppe Iuculano escribió:
>
> No, it doesn't contain those, see below
>
> Chromium in Debian is built against the system FFmpeg headers via
> pkg-config. This means when Chromium is launched it will assume that
> FFmpeg is present in the system library path.
> In
Hi,
Il 10/05/2010 22:15, Iker Salmón San Millán ha scritto:
> Hi, i didn't know where or how to report this, but i have readed in a
> forum that an user has tried |chromium-browser from experimental and
> seems that it includes by default those privative codecs. I have tried
>
Hi, i didn't know where or how to report this, but i have readed in a forum
that an user has tried chromium-browser from experimental and seems that it
includes by default those privative codecs. I have tried by myself and i
agree with him, but maybe i am wrong.
this is the process. Adding u
64 matches
Mail list logo
