Re: broken upload

[Joerg Jaspert]

On 12161 March 1977, Russell Coker wrote:

> Below are two messages I have received after attempts to upload a new 
> refpolicy package.  I first tried via FTP but the 3G Internet connection I'm 
> using gives me a 10.0.0.0/24 address with NAT that doesn't support FTP, so I 
> ended up with a zero byte file on anonymous-ftp-master.  Then I got scp 
> working with ftp-master which allows me to upload all the files but then 
> doesn't process them.

Aha. How do you get scp working with ftp-master? Thats simply
impossible, unless you somehow hacked your way into the system.

> Apart from doing another package build with version -2 what can I do to solve 
> this?

The usual, use dcut.

> Your Debian queue daemon (running on host ravel.debian.org)

Aha, not using ftp-master, but ravel AKA ssh.upload

-- 
bye, Joerg
Maybe, just once, someone will call me 'Sir' without adding, 'You're
making a scene.'


-- 
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/87tyomb90l@gkar.ganneff.de

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote:
> Mozilla actively makes it hard to stay up to date
> (by providing as little information as possible in their advisories);
> webkit (for the most part except for Apple announcements) makes it
> easy.  This means security fixes are going to happen a lot faster since
> there is a lot less downtime waiting for patches to by disclosed.

Actually, that's not true. It's pretty easy to track the security
related changes in mercurial now (that was indeed a problem when mozilla
was still using CVS), and security bugs are as documented as Webkit's.
The only difference, for now, is that we have access to the Webkit bugs
while we (still) don't have access to the Mozilla ones. But that should
happen some day.

IOW, your point is void ;)

Mike


-- 
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/20100629073746.gd3...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Josselin Mouette]

Le mardi 29 juin 2010 à 02:57 -0400, Michael Gilbert a écrit :
> Losing mozilla wouldn't be that significant of an loss since there
> are plenty of other good options nowadays (webkit, konquerer, chromium,
> etc.), which wasn't the case a year or so ago.

I would love to get rid of it, but unfortunately there is still a way
too large number of broken websites that won’t work without Firefox.

-- 
 .''`.
: :' :  “Fuck you sir, don’t be suprised when you die if
`. `'   you burn in Hell, because I am a solid Christian
  `-and I am praying for you.”   --  Mike


--
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/1277802199.22309.2.ca...@meh

Bug#587494: ITP: xgks -- X11 Graphical Kernel System

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: xgks
  Version : 2.6
  Upstream Author :  UCAR/Unidata
* URL : http://xgks.sourceforge.net/
* License : BSD
  Programming Lang: C, Fortran
  Description : X11 Graphical Kernel System

XGKS is a level 2C implementation of the ANSI Graphical Kernel System (GKS) 
for use in a Unix environment with the X Window System. It supports the 
Fortran language binding and a C language binding based on the 1988 draft. 

XGKS is used in both the CDMS2 and FERRET climate tools which are currently
being packaged for Debian.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
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/20100629094744.9221.21566.report...@ailm.sceal.ie

Re: xulrunner 1.9.2 into sid?

[Adam Borowski]

On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote:
> and engage in poor supportability/secuirity practices (using embedded
> code copies instead of system libraries) [0]. This path is
> unnacceptable for Debian.
> 
> In my personal opinion, the only viable option left is to drop all
> mozilla and mozilla-depending packages from main
> [...]
> Losing mozilla wouldn't be that significant of an loss since there
> are plenty of other good options nowadays (webkit, konquerer, chromium,
> etc.), which wasn't the case a year or so ago.

Wait, wait... you promote webkit-based browsers, every single of which
embeds the complete webkit codebase -- while you name exactly that issue as
the reason why Ubuntu's approach to xulrunner is unacceptable.  Hmm...
Yeah, indeed that approach is bad, but that's a reason to remove chromium
and konqueror which do use it, not iceweasel which doesn't.

Also, Chromium doesn't support even the base essentials, like working
AdBlock[1] or sane cookie handling[2].  And Konqueror is just a bad joke,
barely better than Dillo or Amaya (no, not the DD).

So your proposal would remove the only reasonably featured browser from
Debian.



[1]. A Chromium extension named "AdBlock" exists, but it merely hides the
junk after downloading them -- so you merely don't see them while still
being subjected to slowdown, having your bandwidth stolen, being tracked,
having advertising scripts running, being exposed to more of potentially
unpatched vulnerabilities, and all that kind of goodies...

[2]. Chromium doesn't even understand the concept of session cookies.  It
does allow purging cookies at exit -- but that applies to all cookies,
including the few you do want to keep.  Iceweasel's default handling isn't
perfect, but it can be set to something sane even without installing any
extensions, 

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20100629095720.ga12...@angband.pl

Re: xulrunner 1.9.2 into sid?

[Evgeni Golov]

On Tue, Jun 29, 2010 at 11:57:20AM +0200, Adam Borowski wrote:
> [1]. A Chromium extension named "AdBlock" exists, but it merely hides the
> junk after downloading them -- so you merely don't see them while still
> being subjected to slowdown, having your bandwidth stolen, being tracked,
> having advertising scripts running, being exposed to more of potentially
> unpatched vulnerabilities, and all that kind of goodies...

This is not true anymore...
https://chrome.google.com/extensions/detail/gighmmpiobklfepjocnamgkkbiglidom

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20100629100030.go19...@dorei.kerker.die-welt.net

Re: xulrunner 1.9.2 into sid?

[Adam Borowski]

On Tue, Jun 29, 2010 at 12:00:30PM +0200, Evgeni Golov wrote:
> On Tue, Jun 29, 2010 at 11:57:20AM +0200, Adam Borowski wrote:
> > [1]. A Chromium extension named "AdBlock" exists, but it merely hides the
> > junk after downloading them -- so you merely don't see them while still
> > being subjected to slowdown, having your bandwidth stolen, being tracked,
> > having advertising scripts running, being exposed to more of potentially
> > unpatched vulnerabilities, and all that kind of goodies...
> 
> This is not true anymore...
> https://chrome.google.com/extensions/detail/gighmmpiobklfepjocnamgkkbiglidom

This is a new development, good to know.

They say it's badly incomplete, mostly due to no support in the underlying
API, but since it's being worked on, it looks like this particular show
stopper is already mostly gone.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20100629105544.ga12...@angband.pl

Re: xulrunner 1.9.2 into sid?

[Aaron Toponce]

On 06/29/2010 03:57 AM, Adam Borowski wrote:
> [1]. A Chromium extension named "AdBlock" exists, but it merely hides the
> junk after downloading them -- so you merely don't see them while still
> being subjected to slowdown, having your bandwidth stolen, being tracked,
> having advertising scripts running, being exposed to more of potentially
> unpatched vulnerabilities, and all that kind of goodies...

No longer the case with Adblock 2.0, as already pointed out by Evgeni.

> [2]. Chromium doesn't even understand the concept of session cookies.  It
> does allow purging cookies at exit -- but that applies to all cookies,
> including the few you do want to keep.  Iceweasel's default handling isn't
> perfect, but it can be set to something sane even without installing any
> extensions, 

While true, this is rather trivial to setup:

rm ~/.config/chromium/Default/Cookies
ln -s /dev/null ~/.config/chromium/Default/Cookies

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: xulrunner 1.9.2 into sid?

[Adam Borowski]

On Tue, Jun 29, 2010 at 04:57:53AM -0600, Aaron Toponce wrote:
> On 06/29/2010 03:57 AM, Adam Borowski wrote:
> > [2]. Chromium doesn't even understand the concept of session cookies.  It
> > does allow purging cookies at exit -- but that applies to all cookies,
  
> > including the few you do want to keep.  Iceweasel's default handling isn't
^
> > perfect, but it can be set to something sane even without installing any
> > extensions, 
> 
> While true, this is rather trivial to setup:
> 
> rm ~/.config/chromium/Default/Cookies
> ln -s /dev/null ~/.config/chromium/Default/Cookies

Uhm, and that gets me what?  It would nuke all cookies, including those
which are supposed to last beyond the session.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20100629111657.ga13...@angband.pl

Re: broken upload

[Adam Borowski]

On Tue, Jun 29, 2010 at 04:06:17PM +1000, Russell Coker wrote:
> Below are two messages I have received after attempts to upload a new 
> refpolicy package.  I first tried via FTP but the 3G Internet connection I'm 
> using gives me a 10.0.0.0/24 address with NAT that doesn't support FTP,

Are you sure you had passive mode on in your ftp client?


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20100629112008.gb13...@angband.pl

Re: xulrunner 1.9.2 into sid?

[Aaron Toponce]

On 06/29/2010 05:16 AM, Adam Borowski wrote:
> Uhm, and that gets me what?  It would nuke all cookies, including those
> which are supposed to last beyond the session.

Touche. I misread your post, and Chromium's ability to do this by
default. Apologies.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Bug#587514: ITP: cpupowerd -- daemon for frequency and voltage control of AMD K8 CPUs with undervolting/overvolting capability

[Antti J. Salminen]

Package: wnpp
Severity: wishlist
Owner: "Antti J. Salminen" 


* Package name: cpupowerd
  Version : 0.2.1
  Upstream Author : Markus Strobl 
* URL : http://cpupowerd.sourceforge.net/
* License : GPL-2
  Programming Lang: C
  Description : daemon for frequency and voltage control of AMD K8 CPUs 
with undervolting/overvolting capability

 cpupowerd can be used with AMD K8 processors to adjust the CPU frequency 
 and voltage dynamically.
 It can be run as a daemon that dynamically adjusts the processor state
 according to load.
 .
 It's capabilities include overvolting as well as undervolting. This means
 you can use it to run your processor at a voltage lower than what it is
 supposed to run at according to it's specifications and make it run cooler
 and with lower power consumption. WARNING: Doing this could cause damage to
 your hardware so only do it if you know what you're doing and are willing to
 accept the risk.
 . 
 Currently it supports only AMD K8 processors like Athlon, Athlon64 (X2), 
 Sempron, Opteron, Turion...



-- 
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/20100629124815.12518.51138.report...@linger.inshadows

Bug#587521: ITP: dose3

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen

Package name:dose3
Version: 0.7
Upstream Author: Pietro Abate  
URL: http://gforge.info.ucl.ac.be/frs/download.php/160/dose3-0.7.tar.gz
Licence: GPL >=3
Programming Language: OCaml
Tentative Description:
  Dose3 is a framework made of several OCaml libraries for managing
  distribution packages and their dependencies.

  Though not tied to any particular distribution, dose3 constitutes a pool of
  libraries which enable analyzing packages coming from various
  distributions.

  Besides basic functionalities for querying and setting package properties,
  dose3 also implements algorithms for solving more complex problems
  (monitoring package evolutions, correct and complete dependency resolution,
  repository-wide uninstallability checks). 
Maintainer: Debian OCaml Maintainers

Remark: This is the new implementation of the dose2 libraries and the 
accompanying tools, in particular edos-distcheck. We will for the moment
upload only to experimental until we are comfident that the new
implementation can be used as a replacement of the old one. During that
time we will use names of binary packages that do not clash with existing
names of binary packages in unstable. Once we know everything is OK we will
transition from the old edos-distcheck to the new one.

-Ralf.
-- 
Ralf Treinen
Laboratoire Preuves, Programmes et Systèmes
Université Paris Diderot, Paris, France.
http://www.pps.jussieu.fr/~treinen/



--
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/20100629130913.ge12...@vanadium.pps.jussieu.fr

Bug#587522: ITP: twms -- tiny WMS service

[Andrew O. Shadoura]

Package: wnpp
Severity: wishlist
Owner: "Andrew O. Shadoura" 

* Package name: twms
  Version : 0.01q
  Upstream Author : Darafei Praliaskouski 
* URL : http://code.google.com/p/twms/
* License : GPL-3+
  Programming Lang: Python
  Description : tiny WMS service

 tWMS is a tiny WMS-like script for exporting your map
 tiles to WMS-enabled applications.

-- System Information:
Debian Release: 5.0
  APT prefers sid
  APT policy: (500, 'sid'), (500, 'unstable'), (500, 'testing'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)



-- 
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/20100629133054.17730.84891.report...@localhost

Re: Bug#587514: ITP: cpupowerd -- daemon for frequency and voltage control of AMD K8 CPUs with undervolting/overvolting capability

[Michael Biebl]

On 29.06.2010 14:48, Antti J. Salminen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Antti J. Salminen" 
> 
> 
> * Package name: cpupowerd
>   Version : 0.2.1
>   Upstream Author : Markus Strobl 
> * URL : http://cpupowerd.sourceforge.net/
> * License : GPL-2
>   Programming Lang: C
>   Description : daemon for frequency and voltage control of AMD K8 CPUs 
> with undervolting/overvolting capability
> 
>  cpupowerd can be used with AMD K8 processors to adjust the CPU frequency 
>  and voltage dynamically.
>  It can be run as a daemon that dynamically adjusts the processor state
>  according to load.
>  .
>  It's capabilities include overvolting as well as undervolting. This means
>  you can use it to run your processor at a voltage lower than what it is
>  supposed to run at according to it's specifications and make it run cooler
>  and with lower power consumption. WARNING: Doing this could cause damage to
>  your hardware so only do it if you know what you're doing and are willing to
>  accept the risk.
>  . 
>  Currently it supports only AMD K8 processors like Athlon, Athlon64 (X2), 
>  Sempron, Opteron, Turion...

Do we really need yet another cpu frequency scaling daemon?
What features does it have over existing packages?
Looking at the upstream homepage, the last release is from 1,5 years ago, so the
development looks pretty much stalled. Is this software actively maintained?

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#587514: ITP: cpupowerd -- daemon for frequency and voltage control of AMD K8 CPUs with undervolting/overvolting capability

[Yves-Alexis Perez]

On 29/06/2010 16:00, Michael Biebl wrote:
> What features does it have over existing packages?

And why not using ondemand? Is AMD support bad?
-- 
Yves-Alexis


-- 
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/4c29fdb4.1010...@debian.org

Re: Essentiality of Bash

[Josselin Mouette]

Le dimanche 27 juin 2010 à 14:27 +0200, Marc Haber a écrit :
> The problem is that we don't properly distinguish between "foo needs
> bar during installation or foo's installation will fail" and "foo
> needs bar to be installed or foo will not work". One could express
> this via Recommends, but the sheer wording is too lose for this.

Yes. A possible solution would be to introduce a new type of dependency.
I’m not sure the number of impacted packages justifies the amount of
work.

> >For aide, I just don’t see the point: it’s the simplest, straight
> >example of an unjustified 2-packages circular dependency.
> 
> explain "unjustified". This implies that the aide maintainers didn't
> think when they established the dependencies as they are.

Indeed. Every time the circular dependencies topic surfaces, we find
another maintainer who shows an example of a package for which circular
dependencies are necessary according to him. And every time, the package
quoted as an example can be fixed. I’m kind of tired of this behavior.
Given the low number of remaining packages to be fixed, it should be
forbidden by the policy so that maintainers fix their bugs instead of
finding excuses.

-- 
 .''`.
: :' :  “Fuck you sir, don’t be suprised when you die if
`. `'   you burn in Hell, because I am a solid Christian
  `-and I am praying for you.”   --  Mike


--
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/1277820365.22309.9.ca...@meh

Re: Bug#587514: ITP: cpupowerd -- daemon for frequency and voltage control of AMD K8 CPUs with undervolting/overvolting capability

[Josselin Mouette]

Le mardi 29 juin 2010 à 16:05 +0200, Yves-Alexis Perez a écrit :
> On 29/06/2010 16:00, Michael Biebl wrote:
> > What features does it have over existing packages?
> 
> And why not using ondemand? Is AMD support bad?

Well, some CPUs (like the L110) don’t support it with a stock kernel.

I haven’t checked whether the daemon relies on ACPI, but if it doesn’t,
it’s a solution that allows to use states that aren’t normally
available.

-- 
 .''`.
: :' :  “Fuck you sir, don’t be suprised when you die if
`. `'   you burn in Hell, because I am a solid Christian
  `-and I am praying for you.”   --  Mike


--
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/1277820626.22309.13.ca...@meh

Re: Bug#587514: ITP: cpupowerd -- daemon for frequency and voltage control of AMD K8 CPUs with undervolting/overvolting capability

[Ben Hutchings]

On Tue, Jun 29, 2010 at 04:10:26PM +0200, Josselin Mouette wrote:
> Le mardi 29 juin 2010 à 16:05 +0200, Yves-Alexis Perez a écrit :
> > On 29/06/2010 16:00, Michael Biebl wrote:
> > > What features does it have over existing packages?
> > 
> > And why not using ondemand? Is AMD support bad?
> 
> Well, some CPUs (like the L110) don’t support it with a stock kernel.
> 
> I haven’t checked whether the daemon relies on ACPI, but if it doesn’t,
> it’s a solution that allows to use states that aren’t normally
> available.
 
and to causes crashes and false bug reports for other packages, I expect.

Antti, if you insist on packaging this, please ensure that it does:
echo 64 > /proc/sys/kernel/tainted
on startup.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20100629145320.gb5...@decadent.org.uk

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 11:57:20 +0200, Adam Borowski wrote:
> On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote:
> > and engage in poor supportability/secuirity practices (using embedded
> > code copies instead of system libraries) [0]. This path is
> > unnacceptable for Debian.
> > 
> > In my personal opinion, the only viable option left is to drop all
> > mozilla and mozilla-depending packages from main
> > [...]
> > Losing mozilla wouldn't be that significant of an loss since there
> > are plenty of other good options nowadays (webkit, konquerer, chromium,
> > etc.), which wasn't the case a year or so ago.
> 
> Wait, wait... you promote webkit-based browsers, every single of which
> embeds the complete webkit codebase -- while you name exactly that issue as
> the reason why Ubuntu's approach to xulrunner is unacceptable.  Hmm...
> Yeah, indeed that approach is bad, but that's a reason to remove chromium
> and konqueror which do use it, not iceweasel which doesn't.

Like I said, that is hopefully just a temporary problem and will be
fixed following the squeeze release.  To clarify my point, it will be
easier to support six forks of the same codebase rather than six forks
of the same codebase plus a completely separate codebase as well
(especially when those six forks are roughly feature-equivalent to the
separate codebase).

> Also, Chromium doesn't support even the base essentials, like working
> AdBlock[1] or sane cookie handling[2].  And Konqueror is just a bad joke,
> barely better than Dillo or Amaya (no, not the DD).

It's open source (and in rapid development); if these are features
interest you then them or pay someone to do it for you.

> So your proposal would remove the only reasonably featured browser from
> Debian.

No, my proposal is to move the package to a better home: backports.

Best wishes,
Mike


-- 
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/20100629112400.b276dc06.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote:
> No, my proposal is to move the package to a better home: backports.

Same question as for Md with volatile:

apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2

What do you do with these packages ? backports too ? Do you realize some
of these are part of the core of the GNOME desktop ?

Also, using backports doesn't magically solve the issue that all these
package need to be updated when there is a new ABI/API (which basically is
the case with major xulrunner versions)

Mike


-- 
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/20100629152920.ga12...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote:
> On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote:
> > Mozilla actively makes it hard to stay up to date
> > (by providing as little information as possible in their advisories);
> > webkit (for the most part except for Apple announcements) makes it
> > easy.  This means security fixes are going to happen a lot faster since
> > there is a lot less downtime waiting for patches to by disclosed.
> 
> Actually, that's not true. It's pretty easy to track the security
> related changes in mercurial now (that was indeed a problem when mozilla
> was still using CVS), and security bugs are as documented as Webkit's.
> The only difference, for now, is that we have access to the Webkit bugs
> while we (still) don't have access to the Mozilla ones. But that should
> happen some day.
> 
> IOW, your point is void ;)

OK, point taken (I don't have any perspective on mozilla's inner
workings, so I didn't know this). However, do you want to continue
suffering with the workload required to support the mozilla packages?
The core problem I see is that there are two very vulnerable codebases
currently planned to be supported, and manpower could be roughly halved
if the codebases were reduced to one.

Best wishes,
Mike


-- 
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/20100629113528.d113c16d.michael.s.gilb...@gmail.com

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Hideki Yamane]

Hi,

On Mon, 28 Jun 2010 19:21:52 +0200
Luk Claes  wrote:
>Will they also not be usable anymore with identi.ca and similar twitter
>like services? If not, there is no reason to have them dropped AFAICS.

 I haven't known about similar services are there, thanks!
 However, at least remove "twitter" word or add some descriptions that they
 cannot use twitter itself (not only in README.Debian but also in its 
 descriptions).

 Because... if I were a user and install any "twitter client" and it couldn't
 connect to twitter, I'll tweet full of complains for Debian (from browsers ;-)
 I'm afraid that it would be kind of negative campaign for Debian Desktop 
 environment.


> PS: I don't get why they abandon a proven standard that everyone knows.

 I guess they think it can reduce hijacking twitter account or so.



-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20100629205429.a91f17f7.henr...@debian.or.jp

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Hideki Yamane]

Hi Carlos,

On Mon, 28 Jun 2010 17:28:00 +0200
Carlos Galisteo  wrote:
> Waiting for qoauth [1].

 Thanks! I haven't heard about it. Choqok author seems to make a fork from
 that, see http://momeny.wordpress.com/2010/06/09/kde-oauth/#comment-248


>Please, notice that oauth may imply some issues about distributing
>application secret tokens [2]. Upstream and maintainers should be
>aware of it and try to implement the better possible solution.

 Yes, you're right. We should track they implement oauth mecanism for
 their twitter clients and should check it is appropriate or not.


 And, twitter will provide some for opensource applications, so stay tuned...

Mon, 28 Jun 2010 08:02:00 -0700
D. Taylor Singletary @ twitter.com wrote :
> The answer is soon! :) We hope to roll this out more widely this week.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20100629205455.63b81a90.henr...@debian.or.jp

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Hideki Yamane]

Hi Sune,

On Mon, 28 Jun 2010 15:25:10 + (UTC)
Sune Vuorela  wrote:
> plasma-widgets-addons (microblog widget)

 Thanks, added. Is plasma part of KDE, right? If so, as Carlos suggests
 qoauth (or forked one) will help that if someone would package it, I guess.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20100630003500.d085b2fd.henr...@debian.or.jp

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Tue, Jun 29, 2010 at 11:35:28AM -0400, Michael Gilbert wrote:
> On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote:
> > On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote:
> > > Mozilla actively makes it hard to stay up to date
> > > (by providing as little information as possible in their advisories);
> > > webkit (for the most part except for Apple announcements) makes it
> > > easy.  This means security fixes are going to happen a lot faster since
> > > there is a lot less downtime waiting for patches to by disclosed.
> > 
> > Actually, that's not true. It's pretty easy to track the security
> > related changes in mercurial now (that was indeed a problem when mozilla
> > was still using CVS), and security bugs are as documented as Webkit's.
> > The only difference, for now, is that we have access to the Webkit bugs
> > while we (still) don't have access to the Mozilla ones. But that should
> > happen some day.
> > 
> > IOW, your point is void ;)
> 
> OK, point taken (I don't have any perspective on mozilla's inner
> workings, so I didn't know this). However, do you want to continue
> suffering with the workload required to support the mozilla packages?
> The core problem I see is that there are two very vulnerable codebases
> currently planned to be supported, and manpower could be roughly halved
> if the codebases were reduced to one.

The point in releasing squeeze with 3.5/1.9.1 is precisely to only have
to support one codebase for all mozilla based software in debian...

Mike


-- 
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/20100629153957.ga12...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 17:39:57 +0200, Mike Hommey wrote:
> On Tue, Jun 29, 2010 at 11:35:28AM -0400, Michael Gilbert wrote:
> > On Tue, 29 Jun 2010 09:37:46 +0200, Mike Hommey wrote:
> > > On Tue, Jun 29, 2010 at 02:57:32AM -0400, Michael Gilbert wrote:
> > > > Mozilla actively makes it hard to stay up to date
> > > > (by providing as little information as possible in their advisories);
> > > > webkit (for the most part except for Apple announcements) makes it
> > > > easy.  This means security fixes are going to happen a lot faster since
> > > > there is a lot less downtime waiting for patches to by disclosed.
> > > 
> > > Actually, that's not true. It's pretty easy to track the security
> > > related changes in mercurial now (that was indeed a problem when mozilla
> > > was still using CVS), and security bugs are as documented as Webkit's.
> > > The only difference, for now, is that we have access to the Webkit bugs
> > > while we (still) don't have access to the Mozilla ones. But that should
> > > happen some day.
> > > 
> > > IOW, your point is void ;)
> > 
> > OK, point taken (I don't have any perspective on mozilla's inner
> > workings, so I didn't know this). However, do you want to continue
> > suffering with the workload required to support the mozilla packages?
> > The core problem I see is that there are two very vulnerable codebases
> > currently planned to be supported, and manpower could be roughly halved
> > if the codebases were reduced to one.
> 
> The point in releasing squeeze with 3.5/1.9.1 is precisely to only have
> to support one codebase for all mozilla based software in debian...

The point I was trying to make in that paragraph is that there are two
browser codebases (webkit and mozilla) that need to be supported, which
could be halved by dropping one.

On the current path, there will be three mozilla versions that need to
be supported; lenny, squeeze, and unstable (which is of course
quasi-supported). On the new path, this could be reduced to one version;
backports.

Mike


-- 
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/20100629115147.3b6364df.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote:
> On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote:
> > No, my proposal is to move the package to a better home: backports.
> 
> Same question as for Md with volatile:
> 
> apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2
> 
> What do you do with these packages ? backports too ? Do you realize some
> of these are part of the core of the GNOME desktop ?

Yes, I would say drop them all.  The maintainer should be free to
choose whether they want to continue to support the package in
backports, convert the backend to use webkit, or to drop the package
altogether.

Which of those are gnome core packages?  Only liferea, galeon,
evolution-rss, and yelp stick out to me, but I don't use gnome.  Yelp
has a webkit backend, so the mozilla backend could be disabled.

> Also, using backports doesn't magically solve the issue that all these
> package need to be updated when there is a new ABI/API (which basically is
> the case with major xulrunner versions)

I agree, anyone planning to maintain those packages in backports will
indeed have to suffer through that, but it's just the fact of life
with mozilla.

Mike


-- 
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/20100629120604.6d8a7462.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Philipp Kern]

On 2010-06-29, Mike Hommey  wrote:
> On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote:
>> No, my proposal is to move the package to a better home: backports.
> Same question as for Md with volatile:
> apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2
> What do you do with these packages ? backports too ? Do you realize some
> of these are part of the core of the GNOME desktop ?

Actually we have the same problem with clamav in volatile.  We would need
to put all rdeps there, otherwise stuff gets messy.  At least that's a
very restricted set, yours is... not feasible, I suppose.

Kind regards,
Philipp Kern


-- 
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/slrni2k6lv.vri.tr...@kelgar.0x539.de

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 11:03:19 +0200, Josselin Mouette wrote:
> Le mardi 29 juin 2010 à 02:57 -0400, Michael Gilbert a écrit :
> > Losing mozilla wouldn't be that significant of an loss since there
> > are plenty of other good options nowadays (webkit, konquerer, chromium,
> > etc.), which wasn't the case a year or so ago.
> 
> I would love to get rid of it, but unfortunately there is still a way
> too large number of broken websites that won’t work without Firefox.

I've only encounter three or four websites in the last year that didn't
work quite right with webkit (I've been using midori for at least that
long as my primary browser), and upstream has been surprisingly
responsive to fixing those issues very quickly.

Best wishes,
Mike


-- 
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/20100629121745.bfdac139.michael.s.gilb...@gmail.com

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Carlos Galisteo]

On Tue, Jun 29, 2010 at 5:35 PM, Hideki Yamane  wrote:

>  Thanks, added. Is plasma part of KDE, right? If so, as Carlos suggests
>  qoauth (or forked one) will help that if someone would package it, I guess.

Noah Meyerhans (choqok maintainer) took over the qoauth ITP some days
ago, so I'm sure the package will be ready soon.

The fork you mentioned may be useful for some clients (those depending
on kdelibs), but qwit depends on libqt4 (not kdelibs), so 'original'
qoauth will be still needed.


Regards.

-- 
---
Carlos Galisteo 
GPG key :0x8E0076E9:
Fingerprint: 939E 3D10 EAA2 A972 3AF2  E25C 26B7 D8E3 8E00 76E9
---


--
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/aanlktimqq9owfe8h-hrjx_oabvkp6-naisj_tnewd...@mail.gmail.com

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote:
> The point I was trying to make in that paragraph is that there are two
> browser codebases (webkit and mozilla) that need to be supported, which
> could be halved by dropping one.
 
As long as there are people to support both, why drop one? I mean,
you're not involved in mozilla security support, why do you even
care?

And don't make me laugh with the number of codebases, please, because
the mozilla codebase in a given debian suite is the same, which can't be
said from each embedded version of webkit. Sure, some patches may be
applied as they are, or with minimal modifications, accross these
various versions.

But this is also true for mozilla. For instance, the last 3.0 upload in
stable-security was the first one without an upstream release, and out
of 17 patches, only one needed to be seriously amended, but wasn't
included in the end because of the low severity.

All in all, my gut feeling is that webkit is much more a burden to
support than mozilla, but I'm not advocating to drop it.

Mike


-- 
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/20100629162923.ga13...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Tue, Jun 29, 2010 at 12:06:04PM -0400, Michael Gilbert wrote:
> On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote:
> > On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote:
> > > No, my proposal is to move the package to a better home: backports.
> > 
> > Same question as for Md with volatile:
> > 
> > apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2
> > 
> > What do you do with these packages ? backports too ? Do you realize some
> > of these are part of the core of the GNOME desktop ?
> 
> Yes, I would say drop them all.  The maintainer should be free to
> choose whether they want to continue to support the package in
> backports, convert the backend to use webkit, or to drop the package
> altogether.
> 
> Which of those are gnome core packages?  Only liferea, galeon,
> evolution-rss, and yelp stick out to me, but I don't use gnome.  Yelp
> has a webkit backend, so the mozilla backend could be disabled.
> 
> > Also, using backports doesn't magically solve the issue that all these
> > package need to be updated when there is a new ABI/API (which basically is
> > the case with major xulrunner versions)
> 
> I agree, anyone planning to maintain those packages in backports will
> indeed have to suffer through that, but it's just the fact of life
> with mozilla.

Seeing how many problems there still are with webkit backed GNOME
applications, that sure is only a mozilla problem...

Mike


-- 
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/20100629163109.gb13...@glandium.org

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 18:31:09 +0200, Mike Hommey wrote:
> On Tue, Jun 29, 2010 at 12:06:04PM -0400, Michael Gilbert wrote:
> > On Tue, 29 Jun 2010 17:29:20 +0200, Mike Hommey wrote:
> > > On Tue, Jun 29, 2010 at 11:24:00AM -0400, Michael Gilbert wrote:
> > > > No, my proposal is to move the package to a better home: backports.
> > > 
> > > Same question as for Md with volatile:
> > > 
> > > apt-cache rdepends xulrunner-1.9.1 libmozjs2d libwebkit-1.0-2
> > > 
> > > What do you do with these packages ? backports too ? Do you realize some
> > > of these are part of the core of the GNOME desktop ?
> > 
> > Yes, I would say drop them all.  The maintainer should be free to
> > choose whether they want to continue to support the package in
> > backports, convert the backend to use webkit, or to drop the package
> > altogether.
> > 
> > Which of those are gnome core packages?  Only liferea, galeon,
> > evolution-rss, and yelp stick out to me, but I don't use gnome.  Yelp
> > has a webkit backend, so the mozilla backend could be disabled.
> > 
> > > Also, using backports doesn't magically solve the issue that all these
> > > package need to be updated when there is a new ABI/API (which basically is
> > > the case with major xulrunner versions)
> > 
> > I agree, anyone planning to maintain those packages in backports will
> > indeed have to suffer through that, but it's just the fact of life
> > with mozilla.
> 
> Seeing how many problems there still are with webkit backed GNOME
> applications, that sure is only a mozilla problem...

Apologies, I should have said that was a "fact of life for any abi/api
transition", so there is nothing special about a mozilla transition
(except that it touches a lot of packages) whether or not its in
backports or elsewhere.

Mike


-- 
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/20100629123520.5a7dcd17.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Joey Hess]

Mike Hommey wrote:
> On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote:
> > The point I was trying to make in that paragraph is that there are two
> > browser codebases (webkit and mozilla) that need to be supported, which
> > could be halved by dropping one.
>  
> As long as there are people to support both, why drop one? I mean,
> you're not involved in mozilla security support, why do you even
> care?

FWIW, this does not seem to be limited to one person, or one codebase.
This apparently well-meaning idea that we can improve Debian's security
etc by talking people out of doing jobs that they have volunteered to
do, and are doing, is a recent trend that I really don't understand.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 12:35:19 -0400, Joey Hess wrote:
> Mike Hommey wrote:
> > On Tue, Jun 29, 2010 at 11:51:47AM -0400, Michael Gilbert wrote:
> > > The point I was trying to make in that paragraph is that there are two
> > > browser codebases (webkit and mozilla) that need to be supported, which
> > > could be halved by dropping one.
> >  
> > As long as there are people to support both, why drop one? I mean,
> > you're not involved in mozilla security support, why do you even
> > care?
> 
> FWIW, this does not seem to be limited to one person, or one codebase.
> This apparently well-meaning idea that we can improve Debian's security
> etc by talking people out of doing jobs that they have volunteered to
> do, and are doing, is a recent trend that I really don't understand.

I really hope I haven't come across this way.  It was certainly not
my intention.  Like I said in my first post to this discussion, I think
a debate on the merit of the status quo with respect to the mozilla
packages is greatly needed right now.  If the result of this debate is
maintaining the status quo, then that's just fine with me, but at least
all of the dirty laundry has been aired, and an informed decision made.

I also stated that I did't want to diminish Mike's work in any way.
He's done a great job, and I hope the package will continue to be
maintained. I just think that a more appropriate home is in backports.
This is the same solution that has been implemented for clamav due to
its short upstream support time frame.

As for my non-involvement in mozilla security, that actually isn't
true.  I actually spent a great deal of effort to triage all of the
mozilla issues in the security tracker about a year ago, and submitted
bugs for the open ones. However, as a user, I have no access to
mozilla patches, so I could go no further.  I did what I could to
improve mozilla security, then I just simply lost interest because I
found webkit to be actually tractable.

Anyway, I think debate is healthy, and hopefully a broadly beneficial
solution can be reached.

Best wishes,
Mike


-- 
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/20100629133446.a1f3e0e4.michael.s.gilb...@gmail.com

Re: Bootloaders BoF at DebConf?

[Colin Watson]

On Mon, Jun 21, 2010 at 11:56:45PM +0200, Joachim Wiedorn wrote:
> Colin Watson  wrote on 2010-06-21 22:22:
> > There've been several bootloader-related threads here of late, and
> > grub2, lilo, and syslinux all seem to have fairly active work happening
> > on them.  (For all I know the same may be true of some of the
> > bootloaders specific to non-x86 architectures too.)  Would it be worth
> > having a bootloaders BoF of some kind at DebConf, or maybe some hacking
> > sessions?  I'd be curious to know who else would be interested in such a
> > thing, and whether there's anything particular that other bootloader
> > maintainers would like to discuss, or maybe things that people would
> > like to have supported in a bootloader and can come armed with
> > specialist knowledge.
> 
> I think that would be a interesting idea. I hope this could be made online,
> because I have no time to come to far away DebConf's.

DebConf recorded video is usually very good (is that the case for all
BoFs?), although actual live remote participation is probably rather
harder.

-- 
Colin Watson   [cjwat...@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/20100629180047.ga10...@master.debian.org

Re: Bootloaders BoF at DebConf?

[Colin Watson]

On Tue, Jun 22, 2010 at 09:36:54AM +0200, Stefano Zacchiroli wrote:
> On Mon, Jun 21, 2010 at 10:22:35PM +0100, Colin Watson wrote:
> > There've been several bootloader-related threads here of late, and
> > grub2, lilo, and syslinux all seem to have fairly active work happening
> > on them.  (For all I know the same may be true of some of the
> > bootloaders specific to non-x86 architectures too.)  Would it be worth
> > having a bootloaders BoF of some kind at DebConf, or maybe some hacking
> > sessions?  I'd be curious to know who else would be interested in such a
> 
> I think you should just go ahead and submit the BoF event to penta:
> given the interest the issue had on list, I very much doubt the BoF will
> go deserted.

OK, thanks - done, event id 654.

-- 
Colin Watson   [cjwat...@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/20100629180103.gb10...@master.debian.org

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Noah Meyerhans]

On Tue, Jun 29, 2010 at 08:54:55PM +0900, Hideki Yamane wrote:
> > Waiting for qoauth [1].
> 
>  Thanks! I haven't heard about it. Choqok author seems to make a fork from
>  that, see http://momeny.wordpress.com/2010/06/09/kde-oauth/#comment-248

There's no need for a qoauth fork.  The change is being merged upstream.

qoauth is in NEW as of last night.  I'll have new choqok packages by the
time it's accepted.

noah



signature.asc
Description: Digital signature

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sune Vuorela wrote:
> plasma-widgets-addons (microblog widget)

OAuth support added upstream:

https://bugs.kde.org/show_bug.cgi?id=242048

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwqP1sACgkQXjXn6TzcAQn11QCgkJHNUDvLEmZ0AXtCwvD9OePD
ySsAoPmR170pgBG7FHT6OLAqjRfO0+fr
=Otmz
-END PGP SIGNATURE-



-- 
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/i0df12$u0...@dough.gmane.org

Re: xulrunner 1.9.2 into sid?

[Alexander Reichle-Schmehl]

Hi!

Am 29.06.2010 17:24, schrieb Michael Gilbert:

> No, my proposal is to move the package to a better home: backports.

You don't know the current policies WRT packages in backports and about
their reasoning, do you?


Best regards,
  Alexander


-- 
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/4c2a4243.1060...@schmehl.info

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
> Hi!
> 
> Am 29.06.2010 17:24, schrieb Michael Gilbert:
> 
> > No, my proposal is to move the package to a better home: backports.
> 
> You don't know the current policies WRT packages in backports and about
> their reasoning, do you?

I believe I do.  Backports are for recompilations of unstable packages
for the stable releases.  Hence, that's why it seems like a good
solution here.  volatile seems like it has a much more restrictive set
of criteria, but I suppose it would also be a good solution if its
allowable.

I just realized that clamav actually went into volatile, and it was
flasplugin-nonfree that went to backports.  Anyway those two show the
two roads already traveled.  It's a matter of debating the best one
for this case.

Honestly, the ideal solution would be for either backports or volatile
to become officially supported (which from what I can tell has been in
discussion for a long time now). In fact, if one or the other did become
official, there would be no need for both.

Best wishes,
Mike


-- 
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/20100629155031.80bc198d.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Alexander Wirt]

Michael Gilbert schrieb am Tuesday, den 29. June 2010:

Hi, 

> In my personal opinion, the only viable option left is to drop all
> mozilla and mozilla-depending packages from main, and provide them in
> backports (as suggested already in another message in this thread).
> Backports' rolling release model makes it the perfect avenue to adhere
> to mozilla's dictated treadmill.  It may take quite a bit of work to
> excise the offending packages, but there is still quite a bit of time
> before the squeeze freeze; so it should be doable.  With respect to 
> upgrades from lenny, perhaps the iceweasel packages could upgrade to
> epiphany or chromium and provide a message about using backports
> informing the user about how to continue using iceweasel if that's
> really what they want.
You should talk with the backports ftpmaster before (yes thats me). 

Alex - Not happy about the idea. 


-- 
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/20100629202247.ga4...@lisa.snow-crash.org

Re: xulrunner 1.9.2 into sid?

[Gerfried Fuchs]

Hi!

* Michael Gilbert  [2010-06-29 21:50:31 CEST]:
> On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
> > Am 29.06.2010 17:24, schrieb Michael Gilbert:
> > 
> > > No, my proposal is to move the package to a better home: backports.
> > 
> > You don't know the current policies WRT packages in backports and about
> > their reasoning, do you?
> 
> I believe I do.  Backports are for recompilations of unstable packages
> for the stable releases.

 Thanks for excellently stating that you do *not* know about what is
backports about and for, you couldn't have done that better.

 Also, weren't it you who responded to a mail about getting the security
tracker informations straight that it is too much of trouble for you to
check backports informations, too? I fail to see how that would get
better if you want to push more stuff into backports?

> Honestly, the ideal solution would be for either backports or volatile
> to become officially supported (which from what I can tell has been in
> discussion for a long time now). In fact, if one or the other did become
> official, there would be no need for both.

 Also, you seem to know pretty little about volatile, it seems. Can you
please check the things you talk about before you are spreading false
statements just as they were facts?

 And no, the scope of volatile and backports is pretty much different,
none of them would obsolete the other.

 Thanks,
Rhon*please do your homework*da
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


-- 
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/20100629202505.ga8...@anguilla.debian.or.at

Re: xulrunner 1.9.2 into sid?

[Stefano Zacchiroli]

On Tue, Jun 29, 2010 at 12:35:19PM -0400, Joey Hess wrote:
> This apparently well-meaning idea that we can improve Debian's
> security etc by talking people out of doing jobs that they have
> volunteered to do, and are doing, is a recent trend that I really
> don't understand.

Amen.


On Tue, Jun 29, 2010 at 01:34:46PM -0400, Michael Gilbert wrote:
> I really hope I haven't come across this way.  It was certainly not
> my intention.  Like I said in my first post to this discussion, I think
> a debate on the merit of the status quo with respect to the mozilla
> packages is greatly needed right now.  If the result of this debate is
> maintaining the status quo, then that's just fine with me, but at least
> all of the dirty laundry has been aired, and an informed decision made.

Well, I confess that it did come across that way also to me, and
probably to many others. The impression was something like: “someone not
working on iceweasel security in Debian is trying to convince someone
else which is working on that, not only to stop, but also to throw out
of the Debian main archive iceweasel all together”.

Try looking at it that way for a minute and you surely understand how
surreal the debate looked like from the outside :-)

> As for my non-involvement in mozilla security, that actually isn't
> true.  I actually spent a great deal of effort to triage all of the
> mozilla issues in the security tracker about a year ago, and submitted
> bugs for the open ones. However, as a user, I have no access to
> mozilla patches, so I could go no further.  I did what I could to
> improve mozilla security, then I just simply lost interest because I
> found webkit to be actually tractable.

To the risk of repeating myself, Debian is a do-ocracy: who does the
work and does it well (as in this case!) gets the right to decide. If
you stopped working on iceweasel security, you kind of gave up your
rights of directly affecting the course of the package.

I'm sure that for a package as big and complex as iceweasel Mike and
Eric could use every single pair of helping hands: get involved again
and your "greatly needed debate" will have a much higher impact.
(That was written without iceweasel maintainers' permission, though.)

Besides, we all thank you for your security triaging activity for
Mozilla-related package: that helps other users way more than removing
their favorite browser from the main archive.

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: xulrunner 1.9.2 into sid?

[Gerfried Fuchs]

* Philipp Kern  [2010-06-28 11:55:22 CEST]:
> On 2010-06-28, Marco d'Itri  wrote:
> > If there is no manpower to do better than this then I feel that it would
> > be more honest to just use volatile.
> 
> The catch-all for "I can't maintain this stuff properly"[1] is not volatile,
> but backports.  Thanks.

 No it isn't, can you please stop disregarding backports in that way? If
you don't like it that's your fault - but calling it a dump place for
stuff that one can't maintain properly couldn't be further from reality.

> [1] No offence meant for the awesome mozilla maintainers.

 But offence meant for the backports maintainers? Thanks for the fish.
Rhonda
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


-- 
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/20100629203919.ga14...@anguilla.debian.or.at

Re: xulrunner 1.9.2 into sid?

[James Vega]

On Tue, Jun 29, 2010 at 3:50 PM, Michael Gilbert
 wrote:
> On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
>> Hi!
>>
>> Am 29.06.2010 17:24, schrieb Michael Gilbert:
>>
>> > No, my proposal is to move the package to a better home: backports.
>>
>> You don't know the current policies WRT packages in backports and about
>> their reasoning, do you?
>
> I believe I do.  Backports are for recompilations of unstable packages
> for the stable releases.

No, the backports service is for backporting packages from testing to
the stable release.  If a package (or the candidate version) does not
exist in testing, then it is not a candidate for backports except under
special circumstances.

A package still has to go through some sanity checking (via the unstable
-> testing transition) before being available for backporting since
packages targeted for use with the stable release are supposed to be
exactly that -- stable.  This means stable both in the sense of working
properly as well as not being a moving target because of behavior
changes introduced in newer versions.

The proposal to maintain the packages entirely in backports is not
congruent with this.  It sounds closer to the intent of volatile,
although I don't think that's a proper place for the packages being
discussed either since volatile is for packages which, more by
necessity, need to have multiple updates during the span of a stable
release.  This is not the case with the Mozilla-related packages, as
new version updates (other than the security fixes already being
handled) are a nicety, not a requirement.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


--
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/aanlktiluxaygkyf0rln3hpivq13ax6m3n2qsmqaw2...@mail.gmail.com

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 22:25:06 +0200, Gerfried Fuchs wrote:
>   Hi!
> 
> * Michael Gilbert  [2010-06-29 21:50:31 CEST]:
> > On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
> > > Am 29.06.2010 17:24, schrieb Michael Gilbert:
> > > 
> > > > No, my proposal is to move the package to a better home: backports.
> > > 
> > > You don't know the current policies WRT packages in backports and about
> > > their reasoning, do you?
> > 
> > I believe I do.  Backports are for recompilations of unstable packages
> > for the stable releases.
> 
>  Thanks for excellently stating that you do *not* know about what is
> backports about and for, you couldn't have done that better.

The second paragraph on the front page of backports.org says pretty
much the same exact thing in different words.  

>  Also, weren't it you who responded to a mail about getting the security
> tracker informations straight that it is too much of trouble for you to
> check backports informations, too? I fail to see how that would get
> better if you want to push more stuff into backports?

Yes, and I also stated that if backports were to become an officially
supported release, I would adapt my workflow to support it.  But until
then, it doesn't make sense.

Best wishes,
Mike


-- 
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/20100629165216.a3e20b7d.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 22:26:04 +0200, Stefano Zacchiroli wrote:
> On Tue, Jun 29, 2010 at 12:35:19PM -0400, Joey Hess wrote:
> > This apparently well-meaning idea that we can improve Debian's
> > security etc by talking people out of doing jobs that they have
> > volunteered to do, and are doing, is a recent trend that I really
> > don't understand.
> 
> Amen.
> 
> 
> On Tue, Jun 29, 2010 at 01:34:46PM -0400, Michael Gilbert wrote:
> > I really hope I haven't come across this way.  It was certainly not
> > my intention.  Like I said in my first post to this discussion, I think
> > a debate on the merit of the status quo with respect to the mozilla
> > packages is greatly needed right now.  If the result of this debate is
> > maintaining the status quo, then that's just fine with me, but at least
> > all of the dirty laundry has been aired, and an informed decision made.
> 
> Well, I confess that it did come across that way also to me, and
> probably to many others. The impression was something like: “someone not
> working on iceweasel security in Debian is trying to convince someone
> else which is working on that, not only to stop, but also to throw out
> of the Debian main archive iceweasel all together”.
> 
> Try looking at it that way for a minute and you surely understand how
> surreal the debate looked like from the outside :-)

I can certainly see that perspective, and I can see now that I've chosen
my words poorly, which has lead to a major communication breakdown.

Hopefully restating clearly this time: my proposal is to no longer
distribute mozilla packages in the main stable repository; instead they
can be maintained in backports (or volatile) at the choosing of the
maintainers of those packages (or converted to webkit to remain in
stable main). I propose no changes to the mozilla packages in unstable
or experimental.

> > As for my non-involvement in mozilla security, that actually isn't
> > true.  I actually spent a great deal of effort to triage all of the
> > mozilla issues in the security tracker about a year ago, and submitted
> > bugs for the open ones. However, as a user, I have no access to
> > mozilla patches, so I could go no further.  I did what I could to
> > improve mozilla security, then I just simply lost interest because I
> > found webkit to be actually tractable.
> 
> To the risk of repeating myself, Debian is a do-ocracy: who does the
> work and does it well (as in this case!) gets the right to decide. If
> you stopped working on iceweasel security, you kind of gave up your
> rights of directly affecting the course of the package.

Understood; however, ill-conceived security disclosure policies impede
this process. I would fix the issues myself, but I am restricted from
doing so because of upstream mozilla disclosure policy.  That policy is
the primary reason that I am no longer interested in mozilla.  I don't
really see my interests changing without changes happening upstream
first.

Best wishes,
Mike


-- 
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/20100629170727.3d70722d.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Philipp Kern]

On Tue, Jun 29, 2010 at 10:39:20PM +0200, Gerfried Fuchs wrote:
> * Philipp Kern  [2010-06-28 11:55:22 CEST]:
> > On 2010-06-28, Marco d'Itri  wrote:
> > > If there is no manpower to do better than this then I feel that it would
> > > be more honest to just use volatile.
> > The catch-all for "I can't maintain this stuff properly"[1] is not volatile,
> > but backports.  Thanks.
>  No it isn't, can you please stop disregarding backports in that way? If
> you don't like it that's your fault - but calling it a dump place for
> stuff that one can't maintain properly couldn't be further from reality.

It seems the irony was well hidden, then.

> > [1] No offence meant for the awesome mozilla maintainers.
>  But offence meant for the backports maintainers? Thanks for the fish.

I already took the offence for the volatile maintainers, thanks.

Ciao
Philipp Kern


-- 
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/20100629213812.ga2...@kelgar.0x539.de

Re: Bootloaders BoF at DebConf?

[Holger Levsen]

Hi,

On Dienstag, 29. Juni 2010, Colin Watson wrote:
> DebConf recorded video is usually very good (is that the case for all
> BoFs?),

It pretty much depends where the BoF is scheduled. As I understand it, there 
might be several rooms for BoFs to happen, but only the two main room will be 
covered by video.

So submit your BoF early :-)

> although actual live remote participation is probably rather 
> harder.

definitly, though its definitly possible :)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: Call for Testing: initramfs-tools 0.97

[Michael Prokop]

* Joachim Wiedorn  [Sun Jun 27, 2010 at 05:03:02PM +0200]:
> Michael Prokop  wrote on 2010-06-18 23:48:

> > we - the initramfs-tools maintainers in Debian - want to provide a
> > solid initramfs-tools version for squeeze. The new release 0.97 is
> > expected to fix many longstanding problems. It would be great if we
> > could receive feedback from testers.

> > The new release is available from Debian/unstable and is expected to
> > install without problems in at least lenny, squeeze and sid:

> >   
> > http://cdn.debian.net/debian/pool/main/i/initramfs-tools/initramfs-tools_0.97_all.deb
> >   SHA256:56eb56d472d0dd24c8f2fd030222586e258ec882b716f02d114865cef9c19639

> > No matter how your partition layout looks like (rootfs on lvm,
> > crypto, sw-raid,...), if you're booting on physical hardware or a
> > virtualized system (Xen, openvz, kvm,...) - please give it a shot
> > and report any possible problems.

> I have checked the scripts and I was very happy to see that lilo is
> furthermore supported by initramfs-tools (script update-initramfs).
> Can I be sure that this support stay in your package? Because of changes
> in some other packages this would be nearly an existential question.

Sorry for the delay in answering, we discussed that in the team.
Conclusion: no, we - as in initramfs-tools maintainers - won't
support that. The mechanism will change with run-parts execution of
/etc/initramfs hooks - the bootloader will add initramfs hooks.

As explanation for the "no" see thread with subject "[DRAFT] Policy
for Linux kernel, initramfs, boot loader update process"
(Message-ID: <1277690555.26161.532.ca...@localhost>) on
debian-devel. (I'm aware that you - Joachim - already mailed in that
thread and are aware of it therefore, I'm mentioning it here JFTR.)

regards,
-mika-


signature.asc
Description: Digital signature

Re: xulrunner 1.9.2 into sid?

[Michael Gilbert]

On Tue, 29 Jun 2010 17:07:27 -0400 Michael Gilbert wrote:
> Hopefully restating clearly this time: my proposal is to no longer
> distribute mozilla packages in the main stable repository; instead they
> can be maintained in backports (or volatile) at the choosing of the
> maintainers of those packages (or converted to webkit to remain in
> stable main). I propose no changes to the mozilla packages in unstable
> or experimental.

I'm going to make one more attempt at assembling a sound argument
supporting this proposal.  Note that my only vested interest in the
outcome of any decision is reducing the burden on the security team.  I
understand that Mike Hommey is ultimately responsible for any decision
that may be made, and the consequences of that decision primarily
only affect the mozilla maintainers' future workload (with some fallout
on the security team).

In the following lists, I break down the advantages and disadvantages
of each approach.  If there are other thoughts, I would be happy to see
them included.

Advantages of switching to backports:
- very simple for the maintainers to keep up to date with respect to
  security updates (a matter of just recompiling the unstable/testing
  package for stable)
- one (or almost the same) code base across backports and
  testing/unstable (and potentially oldstable-backports).

Disadvantages of switching to backports:
- no official security support.
- potential confusing for users since the mozilla packages will not be
  available in a default install.

Advantages of maintaining the status quo:
- continue to provide a highly demanded packages where users expect
  to find it.

Disadvantages of maintaining the status quo:
- part way through the release, security support will end and many
  users won't even notice (unless they're subscribed to
  debian-security); leaving a lot of the Debian user base vulnerable.
- this will be a lot more work for the maintainers due to manual
  backports of mozilla patches
- three different code bases to support: stable, testing/unstable, and
  oldstable (when that is supported)

Anyway, I hope I've done a better job of clearly defining the scope of
the problem.  I look forward to some constructive debate.

Best wishes,
Mike


-- 
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/20100629203125.af7af9af.michael.s.gilb...@gmail.com

Re: xulrunner 1.9.2 into sid?

[Russ Allbery]

Michael Gilbert  writes:

> In the following lists, I break down the advantages and disadvantages of
> each approach.  If there are other thoughts, I would be happy to see
> them included.

> Advantages of switching to backports:
> - very simple for the maintainers to keep up to date with respect to
>   security updates (a matter of just recompiling the unstable/testing
>   package for stable)
> - one (or almost the same) code base across backports and
>   testing/unstable (and potentially oldstable-backports).

People have been dancing around this, but no one seems to have said it
directly, so I will.  Packages that are excluded from the release are not
eligible for backports either.  If Mozilla was not considered a candidate
for the release, it also wouldn't be permitted in the backports.org
repository (unless the policies of the various archives changed).

backports.org only accepts backports of packages that have migrated to
testing.  Packages are only permitted to migrate to testing if they're
release candidates and are intended to be part of the next release.  If we
were not going to include Mozilla in subsequent releases, that would mean
blocking it from migration with an RC bug, and that in turn would mean
that it could not be uploaded to backports.org.

I suspect the repository that you're looking for when you say backports is
actually volatile, although there are doubtless other issues with hosting
all of Mozilla there.

-- 
Russ Allbery (r...@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/87eifpe3mc@windlord.stanford.edu

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Mauro Lizaur]

2010-06-28, Hideki Yamane:

> Hi,
> 
>  As I reported in Bug#587420, all twitter client should support OAuth since 
> twitter
>  will discard basic auth. If they not, we should drop them from Squeeze 
> release.
> 
>  These lists are assumed to be affected packages (got with "apt-cache search 
> twitter").
> 
> python-twitter: not yet, see
> http://code.google.com/p/python-twitter/issues/detail?id=65

Python-twitter doesn't seem to be on shape to be released, since the last 
commit is 
from 06/13 and there isn't a single line regarding oauth.
Also the author from oauth-python-twitter (which can be integrated in some way 
with
p-twitter) last commit was in November (last year) and the project has a couple 
of 
open bugs (with some patches waiting for approval).

So unless there's a marathonic session to close bugs and update both projects 
to 
make this oauth thing work just fine, I agree on dropping it from the release.

Saludos,
Mauro

--
JID: lavaram...@nube.usla.org.ar | http://lizaur.github.com/
2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1


-- 
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/20100630014745.ga22...@cacavoladora.org

Purpose and policy of the future backports.debian.org.

[Charles Plessy]

Dear Alexander, backport.org people, and everybody,

If I understand correctly, it is planned to incorporate the backports.org
service as an official Debian repository.

I would like to know if the policy of use for backports.debian.org has already
been discussed, drafted or decided. In particular:

 - Will there still be separate keyrings?
 - Will there still be a screening at the first upload: a NEW queue?
 - Who will be allowed to upload backports?
 - Will the upload policy change?

The current upload policy is well adapted to the fact that a backport can be
maintained by a different person from the official package maintainers. But
when backports are prepared by the same team as the main package, can the rules
be relaxed ?

Lastly, in echo to the xulrunner thread, I would like to know if it will be
possible to maintain a pakcage in backports.org when it is not targetted at a
stable release (for instance, when the program is still in a fast development
stage).

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/20100630015842.ga7...@kunpuu.plessy.org

chromium-browser in Debian Sid

[Aaron Toponce]

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-browser in Debian rather than just using the nightlies?

Just curious.

-- 
. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O



signature.asc
Description: OpenPGP digital signature

Re: Purpose and policy of the future backports.debian.org.

[Alexander Wirt]

Hi, 

> Dear Alexander, backport.org people, and everybody,
> 
> If I understand correctly, it is planned to incorporate the backports.org
> service as an official Debian repository.
Thats true. 
> 
> I would like to know if the policy of use for backports.debian.org has already
> been discussed, drafted or decided. In particular:
The current agreement is that everything will stay the same and that future
changes will stay in the hands of the backports team. 

>  - Will there still be separate keyrings?
Thats not clear yet, currently it seems - due to technical limitations in dak
- we will start with our own dak instance which means with our own keyring.
But this will be changed in the future. 

>  - Will there still be a screening at the first upload: a NEW queue?
Yes. 
>  - Who will be allowed to upload backports?
Every DD and probably every DM after he is added to our keyring. 

>  - Will the upload policy change?
There are some small changes planned, but nothing fundamental. 

> The current upload policy is well adapted to the fact that a backport can be
> maintained by a different person from the official package maintainers. But
> when backports are prepared by the same team as the main package, can the 
> rules
> be relaxed ?
I don't understand this question. Currently its already possible - and
preferred - if the maintainer of a package also work on the backport. I don't
see what can be relaxed here. 

> Lastly, in echo to the xulrunner thread, I would like to know if it will be
> possible to maintain a pakcage in backports.org when it is not targetted at a
> stable release (for instance, when the program is still in a fast development
> stage).
I don't think so. Rhonda (who will get a new ftpmaster for bpo if we moved)
thinks like me. For a simple package like flashplugin-nonfree this is
possible, but xulrunner is a monster with all its dependencys and its a
security nightmare. I don't see that backports is appropriate for such a
package. 

Alex


-- 
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/20100630065023.gd4...@lisa.snow-crash.org

Re: xulrunner 1.9.2 into sid?

[Alexander Reichle-Schmehl]

Hi!

Am 29.06.2010 22:52, schrieb Michael Gilbert:

>>> I believe I do.  Backports are for recompilations of unstable packages
>>> for the stable releases.
>>  Thanks for excellently stating that you do *not* know about what is
>> backports about and for, you couldn't have done that better.
> The second paragraph on the front page of backports.org says pretty
> much the same exact thing in different words.  

Uh?  "Backports are recompiled packages from testing (mostly) and
unstable (in a few cases only, e.g. security updates) [..]"


Best regards,
  Alexander


-- 
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/4c2ae94b.50...@schmehl.info