Re: chromium-browser from experimental has included h.264 by default?

[Stefano Zacchiroli]

On Wed, May 12, 2010 at 05:43:37AM +, Sune Vuorela wrote:
> It is the 3rd copy of webkit code in the archive, again most likely
> from a different branch point. (webkit source package building the gtk
> frontend to webkit, qt4-x11 building qtwebkit and now chrome)

Right, but it'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 front-ends. So, if we have to fix a
threshold (and I hope we don't!), one might wonder why we should keep
chrome out and not one of the others.

The point is then how each of the copies is handled individually by
upstream, security-wise (and from what I've read in this thread,
chromium-browser has a reactive team behind it).

/me just trying to avoid post-release comments like «Debian doesn't even
have chromium», unless there's a valid technical reason we can offer
to users.
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: UPG and the default umask

[Stefano Zacchiroli]

On Tue, May 11, 2010 at 06:09:58PM -0700, Russ Allbery wrote:
> Aaron already explained this, but I was confused for quite some time about
> the point of UPG and I'm not sure I would have gotten it from his
> explanation, so let me say basically the same thing he said in different
> words.

> UPG without a umask of 002 is pointless.  One may as well just put all
> users in a users group.

[ As always, I'm impressed by your ability to expose things clearly ]

Can you, or Aaron, or anyone else interested in the matter submit a
proper bug report (at least against "login" for /etc/login.defs)
summarizing the point in favor and against the change (if any resisted
this presentation)?

That way it would be easier to track the status of this proposed change.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: chromium-browser from experimental has included h.264 by default?

[Andres Mejia]

On Wed, May 12, 2010 at 2:31 AM, Giuseppe Iuculano  wrote:
> 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 Giuseppe's observation that Chromium does
>> not even 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.
>
> I already tried to compile against the ffmpeg in NEW, and it compiles
> fine (and works fine). For this reason, waiting the new version in NEW,
> the ugly hack for the current version in unstable was a tentative to
> obtain a working chromium for users with and without debian-multimedia
> repository in sources.list.
>
>
>> For this reason, I think that chromium
>> upstream is providing excellent security support for its copy of ffmpeg!
>
> I full agree, I contacted the chromium security team some time ago
> asking an help to triage all security vulnerabilities in our sec
> tracker. I was impressed by their responsiveness and helpfulness.
>
> Cheers,
> Giuseppe.
>
>

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 a hard hack to drop back to functions
that were not deprecated until 0.6. Also, this patch shouldn't be
submitted upstream as is. It patches the packaging done in the bzr
branch.

Aside from allowing it to build with system ffmpeg 0.5.1, the
packaging is updated to make use of the shlib files for the ffmpeg
libs, to acquire proper entries for the Depends field.

I'm writing this email through gmail with the newly built
chromium-browser, although I'm still getting the 'Aw Snap' message
trying to view HTML5 content. I was getting that message with the
current chromium in experimental as well. I guess this patch is a
start to figuring out that issue at least : /

-- 
Regards,
Andres Mejia
=== modified file 'debian/changelog'
--- debian/changelog	2010-05-10 18:46:43 +
+++ debian/changelog	2010-05-12 00:18:07 +
@@ -1,5 +1,6 @@
 chromium-browser (5.0.375.29~r46008-4) UNRELEASED; urgency=low
 
+  [ Giuseppe Iuculano ]
   * Use system copy of libv8
- update debian/control
- update debian/patches/series
@@ -12,7 +13,10 @@
 - update debian/patches/series
 - add debian/patches/memory_iceweasel.patch
 
- -- Giuseppe Iuculano   Mon, 10 May 2010 20:46:26 +0200
+  [ Andres Mejia ]
+  * Be able to use system ffmpeg-0.5.1.
+
+ -- Andres Mejia   Tue, 11 May 2010 20:17:48 -0400
 
 chromium-browser (5.0.375.29~r46008-3) experimental; urgency=low
 

=== removed file 'debian/chromium-browser.links'
--- debian/chromium-browser.links	2010-05-07 22:37:15 +
+++ debian/chromium-browser.links	1970-01-01 00:00:00 +
@@ -1,3 +0,0 @@
-usr/lib/libavcodec.so.52 usr/lib/chromium-browser/libavcodec.so.52
-usr/lib/libavformat.so.52 usr/lib/chromium-browser/libavformat.so.52
-usr/lib/libavutil.so.50 usr/lib/chromium-browser/libavutil.so.50

=== modified file 'debian/control'
--- debian/control	2010-05-10 17:33:49 +
+++ debian/control	2010-05-12 07:56:55 +
@@ -55,15 +55,16 @@
 	libicu-dev,
 	libevent-dev,
 	yasm,
-	libv8-dev (>= 2.2.7-1)
+	libv8-dev (>= 2.2.7-1),
+	libavcodec-dev,
+	libavformat-dev,
+	libavutil-dev
 Standards-Version: 3.8.4
 
 Package: chromium-browser
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
 	libnss3-1d (>= 3.12.3),
-	libavcodec52,
-	libavformat52,
 	xdg-utils,
 	chromium-browser-inspector
 Suggests: chromium-browser-l10n

=== removed file 'debian/patches/ffmpeg-no-pkgconfig.patch'
--- debian/patches/ffmpeg-no-pkgconfig.patch	2010-05-07 22:37:15 +
+++ debian/patches/ffmpeg-no-pkgconfig.patch	1970-01-01 00:00:00 +
@@ -1,21 +0,0 @@
 a/third_party/ffmpeg/ffmpeg.gyp
-+++ b/third_party/ffmpeg/ffmpeg.gyp
-@@ -767,12 +767,14 @@
- 
- # Add pkg-config result to include path when use_system_ffmpeg!=0
- ['use_system_ffmpeg!=0', {
--  'cflags': [
--'(output_buffer_.get());
+   int output_buffer_size = kOutputBufferSize;
+-  int result = avcodec_decode_audio3(codec_context_,
++  int result = avcodec_decode_audio2(codec_context_,
+  output_buffer,
+  &output_buffer_size,
+- &packet);
++ packet.data,
++ packet.size);
+ 
+   // TODO(ajwong): Consider if kOutputBufferSize should just be an int instead
+   // of a size_t.
+--- a/media/fil

content providers from Jaipur

[thoughtful minds]

*Thoughtfulminds*

*Innovating ways to help you get good potential customers…*


Dear Sir/Madam,


Greetings of the day!


We at Thoughtful Minds, a *content writing* and *website
development/promotion* company feel great pleasure in introducing ourselves
as the one stop supplier for all your requirements related to content
writing and website promotion.


Today it is really very difficult to get potential customers in any field
and the best option for getting success in any online business is by
approaching them via impressive website with good S.E.O enriched content.
With the help of good marketing articles posted in various directories you
can easily grasp the attention of end number of customers who are searching
for your product. Be it *article writing, website content writing, the Copy
writing, Search engine friendly content, Technical writing, press release or
even e-books writing* we can surely serve you the most effective and
affordable content.


We offer content that is 100% unique and tested through copyscape with the
appropriate keyword density (checked through Dupefree Pro). With other
things we understand that the time is the most important factor behind the
success of any business and so we keep a close watch on the timely delivery
of all assignments of all our clients. So if you need the best content at
the very best prices then we are surely the best option for you.


Now you are hardly a step away from your customers with the help of
attractive content that is possible only through Thoughtful Minds. Send your
enquiries now to i...@thoughtfulminds.org


Thanks and Regards

Swadesh Rohilla

Director

Thoughtful Minds

(www.thoughtfulminds.org, www.seocontentonline.com)

+91-9413348979

Economia de Água

[João do Projeto CURA]

Olá!
Sou do Projeto C.U.R.A.- Consumo e Uso Racional da Água.
O Projeto CURA pode reduzir até 50% o valor de sua conta de água.
SEM CUSTO PARA VOCÊ.
100% SUBSIDIADO PELA CONCESSIONÁRIA.
Seu prédio gasta mais de 5 mil reais de água?
Se sua resposta for "sim" vou poder reduzi-la em até 50%.
Aguardo seu contato para agendarmos uma visita.
Pergunte a quem já fez. Confira em nosso site: www.projetocura.com.br
Meu nome é João Batista Quiliconi
Me ligue Agora Mesmo: 11 2100.2872 ramal 2007 - Meu celular: 11 9640-0136
Até já!
Sustentabilidade não é mais teoria.
Passou a ser uma ação prática e inadiável.
Para que? Para assegurar um ecossistema equilibrado,harmonioso para gerações 
presente e futuras.
Por isso, empresas Preocupadas em evitar desperdícios de toda ordem, contribuem 
de maneira inteligente para a manutenção e preservação do meio ambiente 
valorizando, principalmente, o recurso mais importante e essencial à vida - A 
ÁGUA POTÁVEL

Bug#581397: ITP: libharu -- cross platform C library for generating pdf files

[Johan Van de Wauw]

Package: wnpp
Severity: wishlist
Owner: Johan Van de Wauw 
Owner: Johan Van de Wauw 

* Package name: libharu
  Version : 2.1.0
  Upstream Author : Antony Dovgal 
* URL : http://libharu.org
* License : ZLIB/LIBPNG License
  Programming Lang: C
  Description : cross platform library for generating pdf files

cross platform C library for generating pdf files with the following features:
  * Generating PDF files with lines, text, images.
  * Outline, text annotation, link annotation.
  * Compressing document with deflate-decode.
  * Embedding PNG, Jpeg images.
  * Embedding Type1 font and TrueType font.
  * Creating encrypted PDF files.
  * Using various character sets (ISO8859-1~16, MSCP1250~8, KOI8-R).
  * Supporting CJK fonts and encodings.
  * You can add the feature of PDF creation by using HARU without
  understanding complicated internal structure of PDF.


The license of Haru is as follows.

Copyright (C) 1999-2006 Takeshi Kanno
Copyright (C) 2007-2008 Antony Dovgal
This software is provided 'as-is', without any express or implied warranty.

In no event will the authors be held liable for any damages arising from the
use of this software.

Permission is granted to anyone to use this software for any purpose,including
commercial applications, and to alter it and redistribute it freely, subject
to the following restrictions:

 1. The origin of this software must not be misrepresented; you must not claim
that you wrote the original software. If you use this software in a
product, an acknowledgment in the product documentation would be
appreciated but is not required.
 2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
 3. This notice may not be removed or altered from any source distribution



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100512163626.1943.2603.report...@debiansqueeze

Re: perl: 64-bit integers and long doubles

[Niko Tyni]

On Sun, May 09, 2010 at 11:37:24PM +0300, Niko Tyni wrote:

> Testing 5.12.0 with and without use64bitint on x86 shows an approximately
> 10% increase with scalars and arrays:
> 
>  perl -e '${"v$i"} = $i while ($i++ < $ARGV[0]); system("ps -o rss $$")' 
> 100
>  perl -e '$a[$i++] = $i while ($i++ < $ARGV[0]); system("ps -o rss $$")' 
> 1000
> 
> and a 7-8% increase for hashes:
> 
>  perl -e '$h{$i++} = $i while ($i++ < $ARGV[0]); system("ps -o rss $$")' 
> 500

To supplement these pathological cases, I compared a possibly more relevant
 /usr/bin/time -f %M dpkg-reconfigure tzdata

on i386 with debconf-english and whiptail installed, and got

5.10.1/32bitint 23008
5.12.0/32bitint 23744
5.12.0/64bitint 24512

which means a 3% increase or thereabouts.

> I'm partial to enabling use64bitint on all architectures, if only for the
> sake of uniformity already mentioned in the uselongdouble discussion: bugs
> that only happen on the "smaller" architectures because of differences
> like this are not nice to isolate and debug.

To conclude, I'm going ahead with use64bitint but not uselongdouble on all
architectures. 5.12.0-2 is now in experimental with this configuration,
and I don't intend to change it for sid.

Many thanks for your comments,
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100512192020.ga12...@madeleine.local.invalid

Re: snapshot.debian.org implications for you

[Felipe Sateler]

On 11/05/10 03:26, Peter Palfrader wrote:


Short version:
--

If you uploaded stuff to debian that is not redistributable you
will have to let the snapshot people know to remove it.


Would it be feasible to have some sort of automation surrounding this?
Breaches that are fixed by a subsequent upload will very likely contain 
some strings in the changelog: strip, distributable, dfsg-free or non-free.
Also, a significant part of the breaches would have to be fixed by a 
repacked tarball. Thus, detecting changes in the version string (adding 
dfsg or repack) would give a good pointer on packages that need to go 
from snapshot.debian.org.


Saludos,
Felipe Sateler


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hsf15s$lr...@dough.gmane.org

Re: Parallellizing the boot in Debian Squeeze - ready for wider testing

[Petter Reinholdtsen]

[Cesare Leonardi]
> If that helps, reading this thread i've set the previous variable in
> my notebook (Sid with Gnome environment). I can see no problem but the
> speed improvement is really small.

Great to see more test results. :)

> Here what i've measured, from the Grub start to the Gdm prompt, in
> either case starting from a completely power off machine:
> Without concurrency: 33 sec.
> With concurrency (try 1): 29 sec.
> With concurrency (try 2): 31 sec.

The brave can try to merge the symlinks in rcS.d and rc2.d to get
maximum concurrency using the declared dependencies, but such setup is
not really maintainable in the long run and I only use it on machines
I can reinstall after testing the effect.  Doing this exposes
incomplete dependencies, and is an effective way to find bugs in
packages. :)

Note that there are several serialization points in the boot today,
reducing the effect of concurrent booting, and one way to reduce that
problem is to move as many scripts as possible out of rcS.d/ and into
runlevels 1-5, to reduce the serialization effect of the switch from
rcS.d/ to rc2.d/ during the normal boot.

Only the scripts required to get the machine into single user should
be in rcS.d/, and all others should be in rc[1-5].d/.  When we get
that in place, Debian would finally have a single user mode that work
properly. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl7hn8opq8@login1.uio.no

ITP: plasma-widget-smooth-tasks -- alternate task manager plasma widget

[Salvo Rinaldi]

Package: wnpp
Severity: wishlist
Owner: Salvo Rinaldi 
Owner: Salvo Rinaldi 


* Package name: plasma-widget-smooth-tasks
  Version : 0.0~wip20100227-1
  Upstream Author : Mathias Panzenböck 
* URL : http://kde-
look.org/content/show.php/Smooth+Tasks?content=101586
* License : GPL
  Programming Lang: C++
  Description : alternate task manager plasma widget

 This task manager replacement shows only task icons
 to increase the free space of the panel.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201005122207.11000.sal...@cryptolab.net

Bug#581422: ITP: eclipse-mylyn -- Task support for Eclipse

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 
Owner: Niels Thykier 

* Package name: eclipse-mylyn
  Version : 3.2.1
* URL : http://www.eclipse.org/mylyn
* License : EPL v1.0
  Programming Lang: Java
  Description : Task support for Eclipse

 Mylyn integrates task support into Eclipse. It supports offline editing
 for certain task repositories and monitors work activity to hide
 information that is not relevant to the current task. Also included is
 the Mylyn Focused UI for reducing information overload when working with
 tasks and the Bugzilla task connector.


~Niels



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100512211025.9818.54344.report...@getsu.thykier.net

Re: chromium-browser from experimental has included h.264 by default?

[Andreas Marschke]

> 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't be a legal issue or 
is it?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201005130334.06652.xxtj...@gmail.com

Re: UPG and the default umask

[Charles Plessy]

found 248140 5.3
thanks

Dear Santiago,

You probably have seen the discussion about user private groups on debian-devel
this week: http://lists.debian.org/msgid-search/4be830c8.5050...@gmail.com

The core argument is that since user private groups are not meant to be shared,
and that therefore an umask of 002 is not creating security risk. On the other
hand, an umask of 022 is preventing from harvesting the benefits of user
private groups. See in particular the summarry from Russ Allbery:
http://lists.debian.org/87fx1ykjrt@windlord.stanford.edu

I read this bug report (http://bugs.debian.org/248140) and indeed, if users
have been used that Debian has an umask of 022, perhaps the change could be
surprising. However, it would not affect existing systems. I can propose a
patch to the release notes if pepole think it would be useful.

If no stronger objections against a change from 022 to 002 is raised, would you
agree changing base-files so that /etc/profile uses 002 on new systems?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100513014356.ga15...@kunpuu.plessy.org

Re: chromium-browser from experimental has included h.264 by default?

[Reinhard Tartler]

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 yes.

> And since it's the source code only that we distribute with the
> package it shouldn't be a legal issue or is it?

I think we would want to have binary packages as well in debimedia.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87eihgtkst@faui44a.informatik.uni-erlangen.de

Bug#581488: general: lower vm.swappiness by default for desktop installations

[Marcus Better]

Package: general
Severity: wishlist

I have been plagued by long delays with an unresponsive laptop,
waiting for it to swap in Eclipse for several minutes at a time,
several times per day. This is a Thinkpad T61 with 4 GB of RAM,
squeeze/sid, X.org, KDE and Eclipse. (4 GB ought to be enough for
everyone, right?)

Recently I got the advice [1] to set vm.swappiness to 0, rather than
the default 60. This improved things dramatically. Apparently Eclipse
is no longer being swapped out preemptively all the time. The
difference in perceived responsiveness is spectacular.

Shouldn't we provide a lower swappiness by default for desktop
installs, at least those with a fair amount of RAM? This could improve
the user experience on most modern desktop systems. Most users will
probably never find out to tune this on their own. Ubuntu recommends a
value of 10 for desktop systems [2, 3] (but ship with the default
value).

I realise that I don't have any solid evidence that this is a good
move, maybe others can fill in with their experience. The goal here is
to improve desktop responsiveness when multi-tasking, especially on
machines with reasonably large RAM and one or more large applications.

[1] http://lists.debian.org/debian-kde/2010/05/msg00313.html
[2] 
[3] http://brainstorm.ubuntu.com/idea/5481/

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.33.2-melech (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100512192226.234eaf...@better.bindows.net

Processed: Re: Bug#581488: general: lower vm.swappiness by default for desktop installations

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 581488 desktop-base
Bug #581488 [general] general: lower vm.swappiness by default for desktop 
installations
Bug reassigned from package 'general' to 'desktop-base'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
581488: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581488
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.12737328778591.transcr...@bugs.debian.org