Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Tue, Jun 29, 2010 at 08:31:25PM -0400, Michael Gilbert wrote:
> 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.

- Problems for all rdeps of xulrunner-1.9.1 and libmozjs2d, and all
  build-rdeps of libmozjs-dev and xulrunner-dev that don't depend on
  either of both (e.g. plugins), and ensuing problem for users of those
  packages.

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

That surely can be arranged with a special security upload of the
package displaying a message to the user in some way (which, IMHO,
should be done with any package which security support is dropped)

> - this will be a lot more work for the maintainers due to manual
>   backports of mozilla patches

and?

> - three different code bases to support: stable, testing/unstable, and
>   oldstable (when that is supported)

and?

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

Your debate is pointless. Why do you care ? What is your agenda ? Do you
want me to list the same kind of problems webkit gives ? IMHO, webkit
gives more headaches than mozilla. Simply because despite all you can
say, you have several codebases for each debian suite. Each of which may
or may not have some of the security issues. This is in no way any
better than with mozilla.

As for access to the security bugs information, relying on the public
information is not enough anyway if you want to provide *timely*
security updates. The current webkit support in debian is way after
the facts. The current mozilla support in debian is only a few days
off, merely because the CVE and MFSA information is not available to me
until upstream releases its security update.

Also, speaking of upstream security support, I have yet to see an
upstream "stable" release of webkit that includes security fixes. I
don't remember there was any for the GTK port, despite a promise for
some, and I don't think there was any for the QT port either.
At least, Mozilla continues to support older releases for some months
after a new major release. So far, that doesn't appear to have been
true for webkit. Actually, apart from Chromium, I don't think there are
releases with security fixes in webkit at all. And even then, I don't
think Chromium upstream releases security fixes for older major
releases.

The best you can do is actually to go through the CVEs and webkit
security bugs, and find the relevant patches in svn, hoping they are not
dependent on changes in the codebase between the moment it was fixed in
svn, and the codebase you're trying to patch. And then, you have to
account for the fact that you have several codebases in each debian
suite. How exactly is that supposed to be better ? So, why exactly would
we have to chose webkit over mozilla ? Because it's the new cool kid on
the block ?

Finally, the security team hasn't been involved in patching mozilla for
years. AFAIK, patching is what makes most of the work in security
support. Except this work is done by the mozilla maintainers and has
been for a while. What exactly are you trying to get off the security
team shoul

Re: chromium-browser in Debian Sid

[Giuseppe Iuculano]

On 06/30/2010 06:15 AM, Aaron Toponce wrote:
> I just noticed that the chromium-browser package releases in Debian
> GNU/Linux unstable are synced version-for-version with the google-chrome
> beta package provided by the 3rd party Google Linux repository. Is this
> intentional?

No, we follow the stable channel.


> What's the rationale behind using the beta releases for
> chromium-browser in Debian rather than just using the nightlies?

Should we use the Chromium nightly builds ? Really? :)


Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Re: chromium-browser in Debian Sid

[Jonathan Wiltshire]

On Tue, Jun 29, 2010 at 10:15:11PM -0600, Aaron Toponce wrote:
> I just noticed that the chromium-browser package releases in Debian
> GNU/Linux unstable are synced version-for-version with the google-chrome
> beta package provided by the 3rd party Google Linux repository. Is this
> intentional? What's the rationale behind using the beta releases for
> chromium-browser in Debian rather than just using the nightlies?

Isn't this a question for the chromium-browser maintainers?


-- 
Jonathan Wiltshire

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Re: xulrunner 1.9.2 into sid?

[Alexander Reichle-Schmehl]

Hi!

Am 30.06.2010 02:31, schrieb Michael Gilbert:

> 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)

As current maintainer of the iceweasel and xulrunner backports I invite
you to try that out.  Calling that "very simple maintainance" is far
from what I experienced so far.

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/4c2af924.5060...@debian.org

Re: xulrunner 1.9.2 into sid?

[Mike Hommey]

On Wed, Jun 30, 2010 at 09:58:28AM +0200, Alexander Reichle-Schmehl wrote:
> Hi!
> 
> Am 30.06.2010 02:31, schrieb Michael Gilbert:
> 
> > 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)
> 
> As current maintainer of the iceweasel and xulrunner backports I invite
> you to try that out.  Calling that "very simple maintainance" is far
> from what I experienced so far.

As current maintainer of the iceweasel and xulrunner packages I'm
curious to know what kind of problems you have that makes it not a "very
simple maintainance". AFAIK, you should only need a couple backports
(off the top of my head, debhelper, nspr, possibly nss, sqlite and
cairo).

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/20100630093209.ga4...@glandium.org

backports and volatile (was: Re: xulrunner 1.9.2 into sid?)

[Gerfried Fuchs]

Hi!

 I'd like to excuse for the style of my initial response, it was pretty
terse and just pointed out the misinterpretations without offering
corrections to them. I'd like to address them now.

* Michael Gilbert  [2010-06-29 21:50:31 CEST]:
> On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
> > 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.

 That's not completely true. For a start, it's for recompilations for
packages from *testing* (not unstable) in a stable environment. But
reducing it to that is missing the point: The purpose of backports is to
offer newer features in packages that are intended for the next stable
release available for the current stable release.

 Wanting to put a package into backports as sole place won't get
accepted because it won't be part of the next stable release. If we
don't want to release a package it shouldn't go there neither.

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

 It might have evaded you, but volatile _is_ officially supported, for
quite a long while already. See  about
it, it uses .debian.org ressources directly. backports just started to
get into there with being integrated into the official buildd network,
things are progressing slowly.

 I only can see that you mean "officially supported *by the security
team*", neither of them is, which is true. I am very grateful that the
security-tracker does include the status for backports, though - that's
extremely helpful to track issues. Additionally though, they are also
both neither integrated into the BTS, which is another quite unfortunate
state.

 But there is *need* for both: While backports is for getting newer
features into stable for otherwise already good working software, the
purpose of volatile is a completely different: It is about getting
software into shape that does _not_ work anymore properly in stable
anymore but would require deeper changes than just a small patch that
could get in easily through a point release.

 Yes, clamav is a very good example here: The required engine changes
are too much for a security/point release update, thus volatile is the
proper place for it.

 I hope this clears up some confusion that might spin around in some
heads.

 Thanks, and sorry for the initial response style again,
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/20100630100148.ga7...@anguilla.debian.or.at

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

[Charles Plessy]

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

Thanks for the fast answer!

First of all, I would like to make clear that I am not trying to bikeshed
xulrunner: I am more self-centered than this and was only thinking on how to
use backports.debian.org for the Debian Med packages (this is why I opened a
separate thread).

When I asked about relaxing the rules, I was in particular thinking about
upload of backports prepared by the original maintainer, before testing
migration. For instance in some cases, it is crystal clear from the debdiff and
the maintainer's tests on his computer that some changes uploaded to unstable
will not introduce new bugs. Updating the backport at the same time would save
some time and simplify our schedules (no upload echo 10 days later). The other
constraint that I would be interested to be lifted is the passage through the
NEW queue when the backport maintainer is the original maintainer, but if it
requires toolchain development, I understand that this would not be done (again
the goal is to remove issues from the radar after upload).

I think that backports.debian.org will be a tremendous addition to our
distribution, that will distinguish us from many others, and I thank you for
all the hard work and perseverence that lead to this. Since it opens many
possibilities, I think that it is important to have a discussion in advance to
make sure that the vision of the uploaders and the administrators fit well. In
particular, I think that the question of whether backports should only exist
for packages that are aimed at a stable release is a very important one. For
some of the packages I maintain, I predict that my users will be much more
interested in snapshots (to be consistent over a project) or backports of the
main package. In that sense, although the package in stable may be released and
maintained with care, it will be more a byproduct than the real aim.

By the way, will the backports.debian.org uploads archived on
snapshots.debian.org?

Cheers,

-- 
Charles


-- 
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/20100630104752.gd7...@kunpuu.plessy.org

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

[Alexander Wirt]

Charles Plessy schrieb am Wednesday, den 30. June 2010:

Hi, 

*snip*

> Thanks for the fast answer!
> 
> First of all, I would like to make clear that I am not trying to bikeshed
> xulrunner: I am more self-centered than this and was only thinking on how to
> use backports.debian.org for the Debian Med packages (this is why I opened a
> separate thread).
> 
> When I asked about relaxing the rules, I was in particular thinking about
> upload of backports prepared by the original maintainer, before testing
> migration. For instance in some cases, it is crystal clear from the debdiff 
> and
> the maintainer's tests on his computer that some changes uploaded to unstable
> will not introduce new bugs. Updating the backport at the same time would save
> some time and simplify our schedules (no upload echo 10 days later). The other
> constraint that I would be interested to be lifted is the passage through the
> NEW queue when the backport maintainer is the original maintainer, but if it
> requires toolchain development, I understand that this would not be done 
> (again
> the goal is to remove issues from the radar after upload).
I'm strongly against that. I want packages properly tested and in your own
interest you should wait for testing migration of your packages. (of course
there can be exception, but not in general). 

I want well tested packages in bpo (which means tested by users, not
uploaders). 

> I think that backports.debian.org will be a tremendous addition to our
> distribution, that will distinguish us from many others, and I thank you for
> all the hard work and perseverence that lead to this. Since it opens many
> possibilities, I think that it is important to have a discussion in advance to
> make sure that the vision of the uploaders and the administrators fit well. In
> particular, I think that the question of whether backports should only exist
> for packages that are aimed at a stable release is a very important one. For
> some of the packages I maintain, I predict that my users will be much more
> interested in snapshots (to be consistent over a project) or backports of the
> main package. In that sense, although the package in stable may be released 
> and
> maintained with care, it will be more a byproduct than the real aim.
I have the vision of well tested packages, maintained by experienced
developers users can trust in. 

This is how I run backports.org and I plan to continue it. I don't want
backports as a place for snapshot or to deliver development packages to
users. 

> By the way, will the backports.debian.org uploads archived on
> snapshots.debian.org?
This is already done for backports.org and will be continued if the service
is offical. 


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/20100630105824.gc6...@hawking.credativ.lan

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

[Julien Cristau]

On Wed, Jun 30, 2010 at 19:47:52 +0900, Charles Plessy wrote:

> When I asked about relaxing the rules, I was in particular thinking about
> upload of backports prepared by the original maintainer, before testing
> migration.

I, for one, certainly hope this one won't be relaxed.

Cheers,
Julien


signature.asc
Description: Digital signature

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

[Andrei Popescu]

On Mi, 30 iun 10, 12:58:25, Alexander Wirt wrote:
> Charles Plessy schrieb am Wednesday, den 30. June 2010:
> > 
> > When I asked about relaxing the rules, I was in particular thinking about
> > upload of backports prepared by the original maintainer, before testing
> > migration. For instance in some cases, it is crystal clear from the debdiff 
> > and
> > the maintainer's tests on his computer that some changes uploaded to 
> > unstable
> > will not introduce new bugs. Updating the backport at the same time would 
> > save
> > some time and simplify our schedules (no upload echo 10 days later). The 
> > other

> I'm strongly against that. I want packages properly tested and in your own
> interest you should wait for testing migration of your packages. (of course
> there can be exception, but not in general). 

Maybe the backports upload queue could automatically put the package on 
hold until the unstable package has migrated to testing.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

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

[Alexander Wirt]

Andrei Popescu schrieb am Wednesday, den 30. June 2010:

> On Mi, 30 iun 10, 12:58:25, Alexander Wirt wrote:
> > Charles Plessy schrieb am Wednesday, den 30. June 2010:
> > > 
> > > When I asked about relaxing the rules, I was in particular thinking about
> > > upload of backports prepared by the original maintainer, before testing
> > > migration. For instance in some cases, it is crystal clear from the 
> > > debdiff and
> > > the maintainer's tests on his computer that some changes uploaded to 
> > > unstable
> > > will not introduce new bugs. Updating the backport at the same time would 
> > > save
> > > some time and simplify our schedules (no upload echo 10 days later). The 
> > > other
> 
> > I'm strongly against that. I want packages properly tested and in your own
> > interest you should wait for testing migration of your packages. (of course
> > there can be exception, but not in general). 
> 
> Maybe the backports upload queue could automatically put the package on 
> hold until the unstable package has migrated to testing.
Send patches :)

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/20100630111859.gd6...@hawking.credativ.lan

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

[Andrei Popescu]

On Mi, 30 iun 10, 13:18:59, Alexander Wirt wrote:
> > 
> > Maybe the backports upload queue could automatically put the package on 
> > hold until the unstable package has migrated to testing.

> Send patches :)

Sorry, should have mentioned it's just an ideea of mine and I posted it 
for the benefit of maintainers that would use such functionality and 
would be interested in providing the patches ;)

Sorry for the noise,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

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

[Gerfried Fuchs]

* Andrei Popescu  [2010-06-30 13:10:20 CEST]:
> On Mi, 30 iun 10, 12:58:25, Alexander Wirt wrote:
> > I'm strongly against that. I want packages properly tested and in your own
> > interest you should wait for testing migration of your packages. (of course
> > there can be exception, but not in general). 
> 
> Maybe the backports upload queue could automatically put the package on 
> hold until the unstable package has migrated to testing.

 I am working on setting such an upload queue up for myself and have
some code starters for that already. It just needs to get finalized.
Given that the "support contract" I mentioned in my blog did run out
this monday (and I have to say extremely successful :)) I think this can
go out for public testing soon.

 Enjoy,
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/20100630122428.ga15...@anguilla.debian.or.at

Re: chromium-browser in Debian Sid

[Aaron Toponce]

On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
> On 06/30/2010 06:15 AM, Aaron Toponce wrote:
>> I just noticed that the chromium-browser package releases in Debian
>> GNU/Linux unstable are synced version-for-version with the google-chrome
>> beta package provided by the 3rd party Google Linux repository. Is this
>> intentional?
> 
> No, we follow the stable channel.

Stable: 5.0.375.86
Beta: 5.0.375.86
Dev: 6.0.437.3

For some reason, I thought the stable channel was still in v4.

>> What's the rationale behind using the beta releases for
>> chromium-browser in Debian rather than just using the nightlies?
> 
> Should we use the Chromium nightly builds ? Really? :)

Well, when you put it that way. :) Honestly, I don't think of Sid as a
collection of stable packages. That's what I think about Lenny. I think
of Sid as "the latest and greatest", regardless of version, and that's
why I thought the nightlies would be appropriate here.

In my mind's eye, I played out that Sid would get the nightlies and
Squeeze would get the beta pushes. But, following the stable channel
makes sense. I was 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: chromium-browser in Debian Sid

[Didier 'OdyX' Raboud]

Aaron Toponce wrote:

> On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
>> Should we use the Chromium nightly builds ? Really? :)
> 
> Well, when you put it that way. :) Honestly, I don't think of Sid as a
> collection of stable packages. That's what I think about Lenny. I think
> of Sid as "the latest and greatest", regardless of version, and that's
> why I thought the nightlies would be appropriate here.

Well… Nightlies would be appropriate in experimental. And even there, I'm 
far from certain that daily uploads for a given package would really be 
appreciated (it puts a big load on buildds, mirrors, networks, …).

unstable is certainly not for "the latest and greatest", especially now that 
we are approaching freeze time. Packages uploaded to unstable are meant as 
candidates for testing.

> In my mind's eye, I played out that Sid would get the nightlies and
> Squeeze would get the beta pushes. But, following the stable channel
> makes sense. I was just curious.

With our current processes, there is no possibility of differentiating 
uploads to unstable and uploads to testing: a packages _migrates_ to testing 
from unstable when a given set of conditions is fulfilled.

Cheers, 

OdyX



-- 
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/i0fdio$qt...@dough.gmane.org

Re: Improve support for installing 32-bit libraries on 64-bit systems

[Goswin von Brederlow]

Michael Tsang  writes:

> I have a recommendation for 32-bit libraries on 64-bit systems:
>
> Now, some libraries are available on 64-bit systems as lib32* but these are 
> very few. To improve this situation, I think that we can organise the library 
> packages as follows:
>
> For a library with soname libfoo.so.1, we can make the following packages:
> libfoo1   - /usr/lib/libfoo.so.1
> lib32foo1 - /usr/lib32/libfoo.so.1

That would be lib32, lib64, libn32, libo32, lib32el, lib32eb, libn32el,
libn32eb, lib64el, lib64eb, ... Need I go on?

Also note that you need lib32foo1 on ia64 but you can not compile
one. There is no multilib or cross-compiler for i386 on ia64 in Debian.

> libfoo-dev- /usr/lib32/libfoo.so /usr/lib/libfoo.so /usr/include/foo.h
>   libfoo-dev depends on libfoo1 | lib32foo1 (if one of them aren't 
> installed, left the .so link as a dead link)

Which would mean that tons of users would end up with broken symlinks
and sources would fail to compile. apt-get build-dep would not work
anymore and so on. Verry bad idea.

No, you need libfoo-dev and lib32foo-dev and all the other names from
above.

> libfoo-shared - architecture-independent files of libfoo (excluding 
> development files)
>
> This should be implemented as a build template to make all library packages 
> use this organisation scheme. I think this should be implemented after the 
> release of Squeeze.
> -- 
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html

Multiarch solves this much better and includes cross-compile support in
this while also avoiding the many multiple of compiles of the same lib.

Also ia32-apt-get solved this issue nicely for the time till true
multiarch will finally be available. You can pick pretty much any
library and "apt-get install ia32-libfoo" or install 32bit debs directly
and apt will resolve the depends just fine.

The parts that possibly break in ia32-apt-get are the parts packages
must fix to be multiarch compliant. Even if dpkg/apt don't support
multiarch then ia32-apt-get could install multiarch package reliably
under the prefixed name. But 99% of use cases work just fine already.

And don't forget there is a Google summer of code project to
multiarchify apt.

MfG
Goswin


-- 
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/874ogklmhg@frosties.localdomain

Re: chromium-browser in Debian Sid

[Andrei Popescu]

On Mi, 30 iun 10, 06:27:43, Aaron Toponce wrote:
> 
> Well, when you put it that way. :) Honestly, I don't think of Sid as a
> collection of stable packages. That's what I think about Lenny. I think
> of Sid as "the latest and greatest", regardless of version, and that's
> why I thought the nightlies would be appropriate here.

By lurking on debian-devel I learned that sid/unstable is where packages 
intended for the next stable release are uploaded. In certain cases the 
testing migration is intentionally (and hopefully only temporary, 
otherwise it would miss the point) blocked by an RC-bug.

Some given piece of software might be good enough for a stable release 
even in non-stable form, which is why there is some software labeled 
alpha/beta/dev-snapshot/whatever even in Debian stable, but this is 
highly project-dependent.

The place to experiment with nightly builds and similar stuff would be 
experimental ;)

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Essentiality of Bash

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le samedi 26 juin 2010 à 22:30 +0200, Marc Haber a écrit :
>> On Sat, 26 Jun 2010 15:20:46 +0200, Josselin Mouette 
>> wrote:
>> >Furthermore, I’d be interested to know how to fix such a “shortcoming”
>> >in our software. If both A and B depend on each other, A.postinst must
>> >be executed before B.postinst, and vice versa.
>> 
>> That's only one kind of circular dependency, and the one making the
>> problems. When you look at the circular dependencies, for example
>> within the exim4 or the aide packages, you see that the dependencies
>> defined in there aren't _that_ strict.
>
> You could say it’s not problematic all the time - that’s the case of
> fcron/exim4, which is only a problem for users installing fcron. But it
> is a real one: if fcron requires exim to be running to work correctly,
> while exim requires fcron to be running to work correctly, you’re
> doomed.
>
> In this case, there’s a solution: exim needs (f)cron installed on the
> system, but it doesn’t need it to be configured and running. But there’s
> simply no way for dpkg to know that, since the semantics of dependencies
> don’t express that order.
>
> For aide, I just don’t see the point: it’s the simplest, straight
> example of an unjustified 2-packages circular dependency.

It would be nice to introduce a Post-Depends. Post-Depends means the
depended on package needs to be installed but is not needed for
maintainer script. As such the order in which packages are configured is
not restricted.

MfG
Goswin


-- 
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/87vd90k7ji@frosties.localdomain

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

[Charles Plessy]

Hello again,

I have another question: backports-user is quite high traffic, but to upload
backports it is required to be subscribed. Will this change for
backports.debian.org? Will the users be invited to use the BTS?

Cheers,

-- 
Charles


-- 
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/20100630125318.ga9...@kunpuu.plessy.org

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Goswin von Brederlow]

Petter Reinholdtsen  writes:

> [Christoph Anton Mitterer]
>> Hi folks.
>>
>> IIRC, Jonas already put some of these issues up here some time ago.
>> I was recently investigating, and thanks to the help of many people
>> found out how deep the problems actually are.
>
> I suspect this problem is one best solved by using an event based
> system for the early boot, to avoid trying to come up with a fixed
> sequence to enable block devices and disks.  Any fixed sequence is
> going to fail for some setup, and the current alternative is for the
> maintainers to decide on some supported setup and create a working
> sequence for that setup, and leave it to the local sysadmin to cope
> with alternative setups on her own.
>
> Happy hacking,

There is one big problem with an event based startup. Specifically for
raid1/4/5/6 devices. Those you can use just fine with missing devices
but the boot should really wait for all device to be present.

The big question is how long do you wait? How do you detect that a
device is actually broken/missing and its event will never come? You
can't even check if there are any pending events (udev-settle) because
the device might be slow to start (e.g. a disk on a SATA port multiplier
or SCSI with delayed spin up or external enclosures) and no event has
yet been initialized for it.

MfG
Goswin


-- 
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/87r5jok74b@frosties.localdomain

Re: chromium-browser in Debian Sid

[Mike Hommey]

On Wed, Jun 30, 2010 at 06:27:43AM -0600, Aaron Toponce wrote:
> On 06/30/2010 01:18 AM, Giuseppe Iuculano wrote:
> > On 06/30/2010 06:15 AM, Aaron Toponce wrote:
> >> I just noticed that the chromium-browser package releases in Debian
> >> GNU/Linux unstable are synced version-for-version with the google-chrome
> >> beta package provided by the 3rd party Google Linux repository. Is this
> >> intentional?
> > 
> > No, we follow the stable channel.
> 
> Stable: 5.0.375.86
> Beta: 5.0.375.86
> Dev: 6.0.437.3
> 
> For some reason, I thought the stable channel was still in v4.
> 
> >> What's the rationale behind using the beta releases for
> >> chromium-browser in Debian rather than just using the nightlies?
> > 
> > Should we use the Chromium nightly builds ? Really? :)
> 
> Well, when you put it that way. :) Honestly, I don't think of Sid as a
> collection of stable packages. That's what I think about Lenny. I think
> of Sid as "the latest and greatest", regardless of version, and that's
> why I thought the nightlies would be appropriate here.
> 
> In my mind's eye, I played out that Sid would get the nightlies and
> Squeeze would get the beta pushes. But, following the stable channel
> makes sense. I was just curious.

Sid is for what is eventually going in testing/squeeze, which ultimately
becomes stable. At some point, you have to have stable software in sid.

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/20100630130125.gb5...@glandium.org

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

[Alexander Wirt]

Charles Plessy schrieb am Wednesday, den 30. June 2010:

> Hello again,
> 
> I have another question: backports-user is quite high traffic, but to upload
> backports it is required to be subscribed. Will this change for
> backports.debian.org? Will the users be invited to use the BTS?
Not, currently the bts is not able to reflect the situation that we have
different and changing maintainers. As soon as somebody has a solution for me
we will move to it. Currently I don't have one. 

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/20100630130516.ge6...@hawking.credativ.lan

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Daniel Pittman]

Petter Reinholdtsen  writes:
> [Goswin von Brederlow]
>
>> There is one big problem with an event based startup. Specifically for
>> raid1/4/5/6 devices. Those you can use just fine with missing devices but
>> the boot should really wait for all device to be present.
>
> This problem is not specific for event based startup.  It also exist with
> the current sequence based boot system.  There are heaps of setups that fail
> to boot because the required are missing when the init.d script using them
> are running during boot.  The only known solution today is to add a long
> delay during boot to try to increase the chance of having all devices
> available when they are needed. :(
>
>> The big question is how long do you wait?

Please, for the love of everything sane, ask a low priority debconf question
with a default of five minutes[1] — and display a note in the initramfs about
what you are waiting for, and how long.

(Actually, the countdown from the DRBD init script, including the prompt to
 override the configured wait time, would be absolutely wonderful to have
 here, since it gives excellent feedback, a good UI to bypass things, and is
 generally quite informative.)

>> How do you detect that a device is actually broken/missing and its event
>> will never come? You can't even check if there are any pending events
>> (udev-settle) because the device might be slow to start (e.g. a disk on a
>> SATA port multiplier or SCSI with delayed spin up or external enclosures)
>> and no event has yet been initialized for it.
>
> Yeah.  With the current Linux kernel, I am not aware of any way to
> answer these questions. :(

You can't answer them, ever, for some busses: there is no possible way to
determine that you have completed enumeration of a USB bus.  ATAoE, and iSCSI
present similar problems.  It just can't be done.

So, eventually you have to accept that you either wait, or give up, for as
long as the owner of the machine will accept.

(Especially if what you are waiting for is, oh, the second machine in your
 DRBD pair to boot.  Not that I have an agenda or anything. ;)

Daniel

Footnotes: 
[1]  Long enough for most things to boot, short enough that an admin who can't
 read will not go entirely crazy waiting.

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons


-- 
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/877hlgtznm@rimspace.net

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Petter Reinholdtsen]

[Goswin von Brederlow]
> There is one big problem with an event based startup. Specifically
> for raid1/4/5/6 devices. Those you can use just fine with missing
> devices but the boot should really wait for all device to be
> present.

This problem is not specific for event based startup.  It also exist
with the current sequence based boot system.  There are heaps of
setups that fail to boot because the required are missing when the
init.d script using them are running during boot.  The only known
solution today is to add a long delay during boot to try to increase
the chance of having all devices available when they are needed. :(

> The big question is how long do you wait? How do you detect that a
> device is actually broken/missing and its event will never come? You
> can't even check if there are any pending events (udev-settle)
> because the device might be slow to start (e.g. a disk on a SATA
> port multiplier or SCSI with delayed spin up or external enclosures)
> and no event has yet been initialized for it.

Yeah.  With the current Linux kernel, I am not aware of any way to
answer these questions. :(

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/20100630131002.gh3...@login1.uio.no

python-twitter package should be removed from testing (Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Hideki Yamane]

Hi,

On Tue, 29 Jun 2010 22:47:45 -0300
Mauro Lizaur  wrote:
> 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.

 Okay, I propose once python-twitter package should be removed from testing.
 If we're lucky :), it'll be in squeeze, again.

-- 
Regards,

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


pgpvbEd75Szf1.pgp
Description: PGP signature

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Goswin von Brederlow]

Petter Reinholdtsen  writes:

> [Goswin von Brederlow]
>> There is one big problem with an event based startup. Specifically
>> for raid1/4/5/6 devices. Those you can use just fine with missing
>> devices but the boot should really wait for all device to be
>> present.
>
> This problem is not specific for event based startup.  It also exist
> with the current sequence based boot system.  There are heaps of
> setups that fail to boot because the required are missing when the
> init.d script using them are running during boot.  The only known
> solution today is to add a long delay during boot to try to increase
> the chance of having all devices available when they are needed. :(

Yes it is. The problem is that the linux kernel changed from a
asynchronous, wait till the module is completly loaded and all
ports/luns have been scanned mode to one that generates events
asynchronously.

So part of the startup, the most problematic part in this actually, has
already changed to event based. The init.d scripts may or may not
follow. Mdadm already has an event based startup script by the way.

>> The big question is how long do you wait? How do you detect that a
>> device is actually broken/missing and its event will never come? You
>> can't even check if there are any pending events (udev-settle)
>> because the device might be slow to start (e.g. a disk on a SATA
>> port multiplier or SCSI with delayed spin up or external enclosures)
>> and no event has yet been initialized for it.
>
> Yeah.  With the current Linux kernel, I am not aware of any way to
> answer these questions. :(
>
> Happy hacking,

MfG
Goswin


-- 
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/87tyokini8@frosties.localdomain

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Goswin von Brederlow]

Daniel Pittman  writes:

> Petter Reinholdtsen  writes:
>> [Goswin von Brederlow]
>>
>>> There is one big problem with an event based startup. Specifically for
>>> raid1/4/5/6 devices. Those you can use just fine with missing devices but
>>> the boot should really wait for all device to be present.
>>
>> This problem is not specific for event based startup.  It also exist with
>> the current sequence based boot system.  There are heaps of setups that fail
>> to boot because the required are missing when the init.d script using them
>> are running during boot.  The only known solution today is to add a long
>> delay during boot to try to increase the chance of having all devices
>> available when they are needed. :(
>>
>>> The big question is how long do you wait?
>
> Please, for the love of everything sane, ask a low priority debconf question
> with a default of five minutes[1] — and display a note in the initramfs 
> about
> what you are waiting for, and how long.

For most people that is about 4 minutes and 30 seconds too long.

And don't forget that this needs to be multiple times. Usualy once in
the initramfs and once in the real system. But if devices are really
multilayered you can end up having to do this for every layer.

The multipath waits for both its paths. Then the raid waits for all its
devices. Then the drbd waits for both its other hosts to boot. That is
15 minutes already in case of a bad error.

> (Actually, the countdown from the DRBD init script, including the prompt to
>  override the configured wait time, would be absolutely wonderful to have
>  here, since it gives excellent feedback, a good UI to bypass things, and is
>  generally quite informative.)

Which I think is a verry good compromise. As long as you have a keyboard
to press ctrl-c. :)

One small problem though. This requires that you know beforehand what
devices to expect at all. For event based mdadm startup you afaik need
no config at all. It will detect any device ment for the local host and
assemble it. So even if all devices for md0 did show up and md0 was
started successfully you still don't know if the devices for md1 are all
still coming. You don't know if there is supposed to be a md1.

>>> How do you detect that a device is actually broken/missing and its event
>>> will never come? You can't even check if there are any pending events
>>> (udev-settle) because the device might be slow to start (e.g. a disk on a
>>> SATA port multiplier or SCSI with delayed spin up or external enclosures)
>>> and no event has yet been initialized for it.
>>
>> Yeah.  With the current Linux kernel, I am not aware of any way to
>> answer these questions. :(
>
> You can't answer them, ever, for some busses: there is no possible way to
> determine that you have completed enumeration of a USB bus.  ATAoE, and iSCSI
> present similar problems.  It just can't be done.
>
> So, eventually you have to accept that you either wait, or give up, for as
> long as the owner of the machine will accept.
>
> (Especially if what you are waiting for is, oh, the second machine in your
>  DRBD pair to boot.  Not that I have an agenda or anything. ;)
>
> Daniel
>
> Footnotes: 
> [1]  Long enough for most things to boot, short enough that an admin who can't
>  read will not go entirely crazy waiting.

Which might have physical rather than mental reasons.

MfG
Goswin


-- 
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/87pqz8imzz@frosties.localdomain

Bug#587645: ITP: mipav -- quantitative analysis and visualization of medical images

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 
Owner: Yaroslav Halchenko 


* Package name: mipav
  Version : 4.1.1
  Upstream Author : Matthew McAuliffe 
* URL : http://mipav.cit.nih.gov
* License : non-free: closed-source, package is just a 
downloader/installer
  Programming Lang: Java
  Description : quantitative analysis and visualization of medical images
 The MIPAV (Medical Image Processing, Analysis, and Visualization)
 application enables quantitative analysis and visualization of
 medical images of numerous modalities such as PET, MRI, CT, or
 microscopy.  Using MIPAV's standard user-interface and analysis
 tools, researchers at remote sites can easily share research data and
 analyses, thereby enhancing their ability to research, diagnose,
 monitor, and treat medical disorders.  MIPAV provides an interface
 for plug-ins and serves as the foundation for other projects
 (e.g. JIST).
 .
 This package provides downloader/installer for non-redistributable
 closed-source version of MIPAV and a convenience startup wrapper.
 You will have a choice of reviewing the license and accepting or
 declining it upon installation.



-- 
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/20100630151635.27264.50411.report...@novo.onerussian.com

Re: python-twitter package should be removed from testing (Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Josselin Mouette]

Le mercredi 30 juin 2010 à 12:47 +0900, Hideki Yamane a écrit :
> Hi,
> 
> On Tue, 29 Jun 2010 22:47:45 -0300
> Mauro Lizaur  wrote:
> > 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.
> 
>  Okay, I propose once python-twitter package should be removed from testing.
>  If we're lucky :), it'll be in squeeze, again.

You should probably file a RC bug so that it doesn’t migrate again
without being fixed first.

Cheers,
-- 
 .''`.
: :' :  “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/1277914082.28997.6.ca...@meh

Re: xulrunner 1.9.2 into sid?

[Yavor Doganov]

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

Have you discussed this proposal with other members of the security
team?  And/or the relase team?

Ignoring the fact whether this is something possible or not currently,
just think of the rdepends.  Seriously.  xulrunner is not clamav in
this regard.


-- 
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/87aaqc7b41.gnus_not_unix!%ya...@gnu.org

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

[Bernd Zeimetz]

On 06/30/2010 02:53 PM, Charles Plessy wrote:
> Hello again,
> 
> I have another question: backports-user is quite high traffic, but to upload
> backports it is required to be subscribed. Will this change for
> backports.debian.org? Will the users be invited to use the BTS?

80 messages in a month is a high traffic mailing list for you?
debian-bugs-dist is high traffic, or LKLM, or sometimes debian-devel, but not
backport-users.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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/4c2b6f9b.8030...@bzed.de

another disadvantage of backports

[Holger Levsen]

backports.org is (currently) not available for all debian archs.


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

Re: another disadvantage of backports

[Alexander Wirt]

Holger Levsen schrieb am Wednesday, den 30. June 2010:

> backports.org is (currently) not available for all debian archs.
same as experimental. 





signature.asc
Description: Digital signature

Re: Bindv6only once again

[Henrique de Moraes Holschuh]

On Mon, 14 Jun 2010, Brian May wrote:
> On 14 June 2010 16:35, Marco d'Itri  wrote:
> > I believe that now we fixed ~everything which can be fixed, so this
> > leaves us with the proprietary Java implementation which apparently Sun
> > is unwilling to fix.
> 
> Is there software that still requires this proprietary Java
> implementation? I hear openjdk is getting better all the time.

Yes.  OpenJDK doesn't have all the crap required for crypto (or something
like that. All I know is that no Brazilian linux user can file his Income
Tax forms with OpenJDK, we have to use the Sun JDK).

> Is proprietary Java the only reason we should keep having bindv6only=0?

No.  Other software not in Debian will also have the same problem.  Not all
of it will be fixed/fixable.

> For me, bindv6only=0 seems like an ugly hack designed to make existing
> applications work without change. Although all these arguments have
> been hashed out before, no point to repeat them.

Actually, one probably has to mess with /etc/gai.conf to get glibc to not do
anything surprising for IPv6-braindamaged applications (i.e. those who work
partially, maybe depending on the bindv6only setting) if one wants to be
safe from IPv4/IPv6 misbehaviour.

On a dual stack box and any application that does NOT work in ipv6only=1
mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6
([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]).  Icky.   Expect a
lot of problems over this as IPv6 connectivity becomes more widely used.

BTW, this is a problem MS Windows won't have.  They require explicit IPv6
sockets, so it is basically ipv6only=1 for them.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20100630202310.gb30...@khazad-dum.debian.net

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

[Christoph Berg]

Re: Bernd Zeimetz 2010-06-30 <4c2b6f9b.8030...@bzed.de>
> > I have another question: backports-user is quite high traffic, but to upload
> > backports it is required to be subscribed. Will this change for
> > backports.debian.org? Will the users be invited to use the BTS?
> 
> 80 messages in a month is a high traffic mailing list for you?
> debian-bugs-dist is high traffic, or LKLM, or sometimes debian-devel, but not
> backport-users.

It is. 80 messages, of which about 0.5 are of relevance for the
backports I care about are the reason I'm not subscribed.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Deal with sqlite3 with dbconfig-common

[nikrou77]

postinst
Description: Binary data

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

[Joey Hess]

Alexander Wirt wrote:
> I'm strongly against that. I want packages properly tested and in your own
> interest you should wait for testing migration of your packages. (of course
> there can be exception, but not in general). 
> 
> I want well tested packages in bpo (which means tested by users, not
> uploaders). 

Pardon me if this is a stupid question, but, it seems to me that relying
on a package propigating to testing doesn't ensure that a build of it
for backports is particularly well tested. The two are two entirely
different builds targeted at two entirely different systems.

I've run unstable and testing on servers for ages. Now that I have some
recent months of experience using backports, and a lesser amount of
experience providing a couple, my level of trust that a given backport
will be well-tested and free of integration problems is somewhere
between my trust in testing and my (lack of) trust in unstable.

Is anything being  done to push that assurance level closer to that of
testing, or ideally, closer to that of stable? For example, are there
any plans to only allow a package into bpo proper after the *backport*
has received testing-like aging in a bpo-unstable?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bindv6only once again

[Juliusz Chroboczek]

Why is it that suddenly everyone is an expert in double-stack programming?

Brian May:

>> For me, bindv6only=0 seems like an ugly hack designed to make existing
>> applications work without change.

Bindv6only=0 is a way to allow servers to be written to listen to just
one socket, which allows making blocking accept calls.  With bindv6only=1,
you need to listen on two sockets simultaneously, which
requires some mildly more complex code (either forking or calling
select/poll.)

(Yes, I know about setsockopt(IPV6_V6ONLY), and I use it whenever
possible, but that's not portable.)

Henrique de Moraes Holschuh:

> one probably has to mess with /etc/gai.conf
[...]
> On a dual stack box and any application that does NOT work in ipv6only=1
> mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6
> ([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]).  Icky.

I suspect you don't really don't know what you're speaking about.

With bindv6only=0, a v6 socket bound to :: will not accept v4
connections, full stop.  With bindv6only=0, connecting a v6 socket to
a v4-mapped address will not work, full stop.

No amount of tweaking /etc/gai.conf, no amount of firewalling will
change the above facts.

Juliusz


pgpVsWjX2jDN7.pgp
Description: PGP signature

Re: Bindv6only once again

[Henrique de Moraes Holschuh]

(cc's dropped, sorry, I was in "kernel" ML netiquete mode).

On Wed, 30 Jun 2010, Juliusz Chroboczek wrote:
> Henrique de Moraes Holschuh:
> > one probably has to mess with /etc/gai.conf
> [...]
> > On a dual stack box and any application that does NOT work in ipv6only=1
> > mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6
> > ([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]).  Icky.
> 
> I suspect you don't really don't know what you're speaking about.

Maybe.

> With bindv6only=0, a v6 socket bound to :: will not accept v4
> connections, full stop.  With bindv6only=0, connecting a v6 socket to
> a v4-mapped address will not work, full stop.

Well:

http://www.mail-archive.com/debian-devel@lists.debian.org/msg277726.html

says: "When net.ipv6.bindv6only is set to 0, an application binding an
AF_INET6 listening socket to "any" will receive on the same socket IPv4
connections as well, with the endpoint addresses converted in the form
:::1.2.3.4[1]."

So, which one is correct?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20100630220935.ge30...@khazad-dum.debian.net

Re: Bindv6only once again

[Juliusz Chroboczek]

>> With bindv6only=0, a v6 socket bound to :: will not accept v4
>> connections, full stop.  With bindv6only=0, connecting a v6 socket to
>> a v4-mapped address will not work, full stop.

That's obviously a typo -- I meant bindv6only=1.

Juliusz


pgpEstR4godnU.pgp
Description: PGP signature

Re: Bindv6only once again

[Henrique de Moraes Holschuh]

On Thu, 01 Jul 2010, Juliusz Chroboczek wrote:
> >> With bindv6only=0, a v6 socket bound to :: will not accept v4
> >> connections, full stop.  With bindv6only=0, connecting a v6 socket to
> >> a v4-mapped address will not work, full stop.
> 
> That's obviously a typo -- I meant bindv6only=1.

Then, what does it have to do with my email, which is concerned with
half-converted ipv6 applications running in bindv6only=0 mode?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20100630224911.ga11...@khazad-dum.debian.net

Bug#587701: ITP: flashbake -- automated version control with git

[Abhishek Dasgupta]

Package: wnpp
Severity: wishlist
Owner: Abhishek Dasgupta 


* Package name: flashbake
  Version : 0.26.2
  Upstream Author : Thomas Gideon 
* URL : http://bitbucketlabs.net/flashbake/
* License : GPL-3
  Programming Lang: Python
  Description : automated version control with git

Flashbake is a tool which watches files and automatically checks
them in to a git repository. The commit lines can be customised
using plugins and are autogenerated. Thus it simplifies life for
the user by taking off the burden of manually committing changes
and allowing one to focus on the work.



-- 
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/20100630232411.16714.50331.report...@twilight.abhidg.net

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Daniel Pittman]

Goswin von Brederlow  writes:
> Daniel Pittman  writes:
>> Petter Reinholdtsen  writes:
>>> [Goswin von Brederlow]

[... waiting for enough devices to show up ...]

>>> The only known solution today is to add a long delay during boot to try to
>>> increase the chance of having all devices available when they are
>>> needed. :(
>>>
 The big question is how long do you wait?
>>
>> Please, for the love of everything sane, ask a low priority debconf question
>> with a default of five minutes[1] — and display a note in the initramfs 
>> about
>> what you are waiting for, and how long.
>
> For most people that is about 4 minutes and 30 seconds too long.  And don't
> forget that this needs to be multiple times. Usualy once in the initramfs
> and once in the real system. But if devices are really multilayered you can
> end up having to do this for every layer.
>
> The multipath waits for both its paths. Then the raid waits for all its
> devices. Then the drbd waits for both its other hosts to boot. That is 15
> minutes already in case of a bad error.

*nod*

>> (Actually, the countdown from the DRBD init script, including the prompt to
>>  override the configured wait time, would be absolutely wonderful to have
>>  here, since it gives excellent feedback, a good UI to bypass things, and is
>>  generally quite informative.)
>
> Which I think is a verry good compromise. As long as you have a keyboard
> to press ctrl-c. :)
>
> One small problem though. This requires that you know beforehand what
> devices to expect at all.

It took me two tries to understand what you were saying here.  Yes, that would
be an issue, even if it can be solved in some cases.  The "waiting for" is
"for the root device to show up", and what is happening is event-driven stuff
is building — and, hopefully, eventually that creates the root device.

So, either the system would need to "document" the path to the root device
somewhere, and use that to drive the "what we are waiting for next" part, or
you would need to treat that as a global timeout.

The later would at least reduce it from one-wait-per-device worst case,
I guess. ;)

Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons


-- 
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/87vd8z7tv7@rimspace.net