On Tue, Aug 23, 2005 at 07:58:40PM +0200, Adrian von Bidder wrote:
On Monday 22 August 2005 23.51, Steve Langasek wrote:
On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
really matters: can we (the Debian
On Tue, Aug 23, 2005 at 11:06:37PM -0700, Steve Langasek wrote:
(I mean, how does my proposal to drop the 'has users' requirement in favor
of 'do we have developers' ignore the resource usage. I certainly do not
dispute that a port uses resources.)
Ok, then perhaps it doesn't ignore it,
At Sun, 21 Aug 2005 03:58:24 +0200,
Wouter Verhelst wrote:
- must be a developer-accessible debian.org machine for the
architecture
Does this part mean developer-accessible machine is always usable for
all debian developers? Does such machine have dchroot for
old-stable/stable/unstable ?
I
* Olaf van der Spek
| I understand most maintainers don't try the new toolchain themselves,
| but wouldn't it be possible for someone else to build the entire
| archive (or parts of it by multiple people) and (automatically) report
| bugs?
With the toolchain, it won't help to just rebuild the
On Wed, Aug 24, 2005 at 05:04:40PM +0900, GOTO Masanori wrote:
At Sun, 21 Aug 2005 03:58:24 +0200,
Wouter Verhelst wrote:
- must be a developer-accessible debian.org machine for the
architecture
Does this part mean developer-accessible machine is always usable for
all debian
Hi,
* GOTO Masanori ([EMAIL PROTECTED]) [050824 10:38]:
At Sun, 21 Aug 2005 03:58:24 +0200,
Wouter Verhelst wrote:
- must be a developer-accessible debian.org machine for the
architecture
Does this part mean developer-accessible machine is always usable for
all debian developers?
On 8/24/05, Tollef Fog Heen [EMAIL PROTECTED] wrote:
* Olaf van der Spek
| I understand most maintainers don't try the new toolchain themselves,
| but wouldn't it be possible for someone else to build the entire
| archive (or parts of it by multiple people) and (automatically) report
|
On Wed, Aug 24, 2005 at 11:42:28AM +0200, Olaf van der Spek wrote:
And what about cross-compiling?
Cross-compiling is no magic wand that can save us from the slow
architectures. There are quite a number of problems with
cross-compiling:
* Many packages don't support cross-compiling, and those
* Many packages don't support cross-compiling, and those that do may
have bugs in their makefiles that make cross-compiling either harder
or impossible.
* You can't run the test suites of the software you're compiling, at
least not directly.
* There's a serious problem with
On Wed, Aug 24, 2005 at 02:13:50PM +0200, Peter 'p2' De Schrijver wrote:
* Many packages don't support cross-compiling, and those that do may
have bugs in their makefiles that make cross-compiling either harder
or impossible.
* You can't run the test suites of the software you're
On Wed, Aug 24, 2005 at 02:13:50PM +0200, Peter 'p2' De Schrijver wrote:
* Many packages don't support cross-compiling, and those that do may
have bugs in their makefiles that make cross-compiling either harder
or impossible.
* You can't run the test suites of the software you're
* Olaf van der Spek
| On 8/24/05, Tollef Fog Heen [EMAIL PROTECTED] wrote:
| * Olaf van der Spek
|
| | I understand most maintainers don't try the new toolchain themselves,
| | but wouldn't it be possible for someone else to build the entire
| | archive (or parts of it by multiple people)
On 8/24/05, Tollef Fog Heen [EMAIL PROTECTED] wrote:
| Wouldn't that at least catch the non-platform-specific bugs?
They are usually caught fairly quickly. The problem here is what to
do in the cases where nobody cares enough about the port to fix
toolchain breakages which only affect that
On 8/24/05, Wouter Verhelst [EMAIL PROTECTED] wrote:
On Wed, Aug 24, 2005 at 02:13:50PM +0200, Peter 'p2' De Schrijver wrote:
Do you want to take the chance of finding out the hard way after having
built 10G (or more) worth of software?
This is not a case of embedded software where you
* Olaf van der Spek ([EMAIL PROTECTED]) [050824 15:52]:
On 8/24/05, Tollef Fog Heen [EMAIL PROTECTED] wrote:
| Wouldn't that at least catch the non-platform-specific bugs?
They are usually caught fairly quickly. The problem here is what to
do in the cases where nobody cares enough about
* By using a cross-compiler, by definition you use a compiler that is
not the same as the default compiler for your architecture. As such,
your architecture is no longer self-hosting. This may introduce bugs
when people do try to build software for your architecture natively
Quoting Peter 'p2' De Schrijver [EMAIL PROTECTED]:
Most packages are not tested automatically at all.
Unfortunately not.
Most cross compiled software also runs 24/7. I have yet to see problems
produced by cross compiling the code.
...
I don't think the risk is real considering the amount of
On 8/23/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Roger Leigh [EMAIL PROTECTED] writes:
Andreas Jochens in particular did a lot of hard work in fixing most of
the GCC 4.0 failures and regressions over the last year while porting
for amd64. The fact that many maintainers have not
On Mon, 22 Aug 2005 14:51:52 -0700, Steve Langasek [EMAIL PROTECTED]
wrote:
On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
really matters: can we (the Debian project) maintain the port? Thus I
propose we only
On Tue, Aug 23, 2005 at 11:12:09AM +0200, Marc Haber wrote:
On Mon, 22 Aug 2005 14:51:52 -0700, Steve Langasek [EMAIL PROTECTED]
wrote:
On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
really matters: can we
On Mon, Aug 22, 2005 at 11:42:50AM -0400, David Nusinow wrote:
On Mon, Aug 22, 2005 at 12:22:47AM -0700, Steve Langasek wrote:
There was discussion in Vancouver about requiring ports to have an
upstream kernel maintainer, FSO upstream; perhaps we should be
considering requiring there to be
Olaf van der Spek [EMAIL PROTECTED] writes:
On 8/23/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Roger Leigh [EMAIL PROTECTED] writes:
Andreas Jochens in particular did a lot of hard work in fixing most of
the GCC 4.0 failures and regressions over the last year while porting
for
On Monday 22 August 2005 23.51, Steve Langasek wrote:
On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
really matters: can we (the Debian project) maintain the port? Thus
I propose we only limit on the number
Hello David,
* David Nusinow [EMAIL PROTECTED], [2005-08-21 19:44 -0400]:
On Sun, Aug 21, 2005 at 11:29:51PM +0200, Petter Reinholdtsen wrote:
[Wouter Verhelst]
b) the three beforementioned teams could already refuse to
support a port anyhow, simply by not doing the work.
Wouter Verhelst wrote:
Vancouver has gotten a very specific meaning in the Debian
community: one of a visionary proposal[1] that received quite its
share of flames from many Debian contributors, including
myself. Since it appeared to many of us that the intentional result
of this proposal
* Sven Luther [Mon, 22 Aug 2005 23:17:10 +0200]:
Sven Luther dijo [Mon, Aug 22, 2005 at 12:52:06PM +0200]:
the security level would still be higher using only official
buildds and centraly controled.
The only reason this does not happen is that the ftp-masters dislike the
x86
* Manoj Srivastava [Mon, 22 Aug 2005 07:58:06 -0500]:
The end goal is not just to have packages built on the
buildd -- and important goal for Debian, certainly, but not the only
one we have. As promoters of free software, we also are committed to
have packages build for our users,
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements --
Wouter,
Thank you for your work in preparing this; I think this summary is a
good beginning for revisiting the questions the Vancouver meeting poses
for etch.
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
Vancouver has gotten a very specific meaning in the Debian community:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
1. The requirement that 'an architecture must be publically available to
buy new'.
It was explained that this requirement was not made to be applied
retroactively to already existing ports; rather, it was designed to
On Mon, Aug 22, 2005 at 10:19:38AM +0200, Ingo Juergensmann wrote:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
1. The requirement that 'an architecture must be publically available to
buy new'.
It was explained that this requirement was not made to be applied
On Sun, Aug 21, 2005 at 10:30:08PM +0200, Laszlo Boszormenyi wrote:
I do rebuild them and more on this that I download the .orig.tar.gz
for myself from the official upstream location and check the diff
ofcourse. This may sound paranoid, but this is me.
As a user, I certainly appreciate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22-08-2005 08:24, Sven Luther wrote:
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable. Some may
remember that the new glibc/gcc blocked non-toolchain progress for
months during the beginning of
On Mon, Aug 22, 2005 at 10:19:38AM +0200, Ingo Juergensmann wrote:
3. The veto powers given to the DSA team, the Security team, and the
Release team, on a release of any given port.
Some of us feared for abuse of this veto power. All understood the
problems that exist if any
Sven Luther a écrit :
All packages should be built by official debian buildds anyway, not on
developper machines with random cruft and unsecure packages installed, or even
possibly experimental or home-modified stuff.
What about packages built on developer machines, but using the same
On Mon, Aug 22, Wouter Verhelst wrote:
- binary packages must be built from unmodified Debian source
Uhm? When there is a new arch upcoming, they need to modifiy the Debian
source, at least sometimes, right?
Yes, and this happens. I've already had requests to modify my
Architecture:
On Mon, Aug 22, 2005 at 11:51:55AM +0200, Aurelien Jarno wrote:
Sven Luther a écrit :
All packages should be built by official debian buildds anyway, not on
developper machines with random cruft and unsecure packages installed, or
even
possibly experimental or home-modified stuff.
What
On Mon, 22 Aug 2005 10:19:38 +0200, Ingo Juergensmann
[EMAIL PROTECTED] wrote:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
4. The requirement that any port has to have 5 developers support it,
and be able to demonstrate that there are (at least) 50 users.
How should this
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 12:35]:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable. Some may
remember that the new glibc/gcc blocked
* Ingo Juergensmann ([EMAIL PROTECTED]) [050822 10:42]:
On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote:
4. The requirement that any port has to have 5 developers support it,
and be able to demonstrate that there are (at least) 50 users.
How should this demonstration
On Mon, 22 Aug 2005 11:51:55 +0200, Aurelien Jarno [EMAIL PROTECTED] said:
Sven Luther a écrit :
All packages should be built by official debian buildds anyway, not
on developper machines with random cruft and unsecure packages
installed, or even possibly experimental or home-modified stuff.
On Mon, Aug 22, 2005 at 12:52:06PM +0200, Sven Luther wrote:
On Mon, Aug 22, 2005 at 11:51:55AM +0200, Aurelien Jarno wrote:
Sven Luther a écrit :
All packages should be built by official debian buildds anyway, not on
developper machines with random cruft and unsecure packages installed, or
Am Sonntag, 21. August 2005 03.58 schrieb Wouter Verhelst:
Hi all,
Good morning
Most of the time I only read on this list and so I've done with this
discussion. But sometimes I dare to write something and suggest somthing ;-)
(see below).
snip
Initial:
- must be publically available to
On Mon, 22 Aug 2005 11:27:33 +0200, Jonas Smedegaard [EMAIL PROTECTED] said:
Also, as Manoj[1] and others have pointed out, sponsors are
_expected_ to recompile packages they sign, but I believe it is not
part of policy.
Which policy?
So I ask again: Is this an intended (and IMO
Hi!
Manoj Srivastava [2005-08-22 7:58 -0500]:
The end goal is not just to have packages built on the
buildd -- and important goal for Debian, certainly, but not the only
one we have. As promoters of free software, we also are committed to
have packages build for our users, in a
On 8/22/05, Andreas Barth [EMAIL PROTECTED] wrote:
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 12:35]:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to
On 8/22/05, Hamish Moffatt [EMAIL PROTECTED] wrote:
Really? The maintainer can still embed rm -rf / in the postinst either
way. We need to be able to trust developers.
Similarly, sponsored packages should be rebuilt because the project
hasn't decided to official trust those contributors.
On 8/22/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
The end goal is not just to have packages built on the
buildd -- and important goal for Debian, certainly, but not the only
one we have. As promoters of free software, we also are committed to
have packages build for our
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 17:01]:
On 8/22/05, Andreas Barth [EMAIL PROTECTED] wrote:
* Olaf van der Spek ([EMAIL PROTECTED]) [050822 12:35]:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
Sven Luther dijo [Mon, Aug 22, 2005 at 12:52:06PM +0200]:
What about packages built on developer machines, but using the same
software as on the official debian buildds? I mean using sbuild in a
dedicated chroot. I sometimes do that for my packages when buildd are
lagging or when a
Jonas Smedegaard dijo [Sun, Aug 21, 2005 at 07:28:55PM +0200]:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements -- requirements that
a port would need to fulfill in order to be allowed on the mirror
network -- but
On Mon, Aug 22, 2005 at 12:22:47AM -0700, Steve Langasek wrote:
There was discussion in Vancouver about requiring ports to have an
upstream kernel maintainer, FSO upstream; perhaps we should be
considering requiring there to be a glibc/gcc/binutils upstream for each
port, so that we don't get
* Gunnar Wolf ([EMAIL PROTECTED]) [050822 18:01]:
Huh? Would an off-the-shelf old 1.5GHz P4 lag behind a top-of-the-line
m68k or ARM?
If you manage to put enough ram in the current arm: Definitly yes. Last
time when I was about to buy me a new machine, the only reason why I
didn't buy an
On Monday 22 August 2005 12.58, Marc Haber wrote:
I can imagine that for archs with less than 50 machines reporting to
popcon it could be possible to have some kind of registration
mechanism.
Uh, please don't add huge technical overhead for corner cases that will
rarely happen, if ever. I'm
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
really matters: can we (the Debian project) maintain the port? Thus I
propose we only limit on the number of developers: are there people who
are willing and competent to maintain kernel, boot loader, platform
specific
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olaf van der Spek [EMAIL PROTECTED] writes:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable. Some may
On Mon, Aug 22, 2005 at 11:44:05AM +0200, Olaf van der Spek wrote:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is uploaded to unstable. Some may
remember that the new
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
On Mon, Aug 22, 2005 at 11:44:05AM +0200, Olaf van der Spek wrote:
On 8/22/05, Steve Langasek [EMAIL PROTECTED] wrote:
In particular, we invariably run into arch-specific problems every time
a new version of a toolchain package is
On Mon, Aug 22, 2005 at 10:32:31AM -0500, Gunnar Wolf wrote:
Sven Luther dijo [Mon, Aug 22, 2005 at 12:52:06PM +0200]:
What about packages built on developer machines, but using the same
software as on the official debian buildds? I mean using sbuild in a
dedicated chroot. I sometimes
[Adrian von Bidder]
Why not have a per-port blacklist (maintained by the port
maintainers, not the package maintainers) of packages that are not
suitable for a port
They do.
and just put up a section in the release notes (or wherever) on why
such-and-such packages are not available.
That
On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote:
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote:
really matters: can we (the Debian project) maintain the port? Thus I
propose we only limit on the number of developers: are there people who
are willing and
On Mon, Aug 22, 2005 at 04:45:28PM +0200, Olaf van der Spek wrote:
On 8/22/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
The end goal is not just to have packages built on the
buildd -- and important goal for Debian, certainly, but not the only
one we have. As promoters of free
Roger Leigh [EMAIL PROTECTED] writes:
Andreas Jochens in particular did a lot of hard work in fixing most of
the GCC 4.0 failures and regressions over the last year while porting
for amd64. The fact that many maintainers have not yet applied, or at
least carefully reviewed and applied
Hi all,
Vancouver has gotten a very specific meaning in the Debian community:
one of a visionary proposal[1] that received quite its share of flames from
many Debian contributors, including myself. Since it appeared to many of us
that the intentional result of this proposal would have been to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements -- requirements that
a port would need to fulfill in order to be allowed on the
Jonas Smedegaard a écrit :
Currently, sponsored packages are only signed, not built, by official
Debian Developers.
Is that intended to change, or is it a typo in the proposal?
I don't know what is the rule but personnally, I never upload a package
I haven't build, I rebuild all packages I
On Sun, 2005-08-21 at 19:28 +0200, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements --
Hi Jonas!
You wrote:
- binaries must have been built and signed by official Debian
Developers
Currently, sponsored packages are only signed, not built, by official
Debian Developers.
Sponsors do build the packages they sponsor themselves.
Or at least, they should.
--
Kind regards,
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-08-2005 03:58, Wouter Verhelst wrote:
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements --
On Sun, 21 Aug 2005, Jonas Smedegaard wrote:
Currently, sponsored packages are only signed, not built, by official
Debian Developers.
They are supposed to be BUILT by the sponsor of non-DDs, not just signed.
--
One disk to rule them all, One disk to find them. One disk to bring
them all
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote:
Currently, sponsored packages are only signed, not built, by official
Debian Developers.
Ahem, no! As the sponsor, you should rebuild the package from source using
the diff from the packager, and using the upstream sources, not
On Sun, 21 Aug 2005 19:28:55 +0200, Jonas Smedegaard [EMAIL PROTECTED] said:
Currently, sponsored packages are only signed, not built, by
official Debian Developers.
Can you share with us the list of developers merely signing
sponsored packages, so action can be taken?
Is that
On Sun, 2005-08-21 at 19:55 +0200, Aurelien Jarno wrote:
Jonas Smedegaard a écrit :
Currently, sponsored packages are only signed, not built, by official
Debian Developers.
Is that intended to change, or is it a typo in the proposal?
I don't know what is the rule but personnally, I
[Wouter Verhelst]
b) the three beforementioned teams could already refuse to
support a port anyhow, simply by not doing the work.
This is not really a valid argument. If a team in debian refuses to
accept decisions made by a majority of debian developers, or rejects
democratic control,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 21-08-2005 21:42, Manoj Srivastava wrote:
On Sun, 21 Aug 2005 19:28:55 +0200, Jonas Smedegaard [EMAIL PROTECTED]
said:
Currently, sponsored packages are only signed, not built, by
official Debian Developers.
Can you share with
On Sun, Aug 21, 2005 at 11:29:51PM +0200, Petter Reinholdtsen wrote:
[Wouter Verhelst]
b) the three beforementioned teams could already refuse to
support a port anyhow, simply by not doing the work.
This is not really a valid argument. If a team in debian refuses to
accept
On Sun, Aug 21, 2005 at 11:29:51PM +0200, Petter Reinholdtsen wrote:
[Wouter Verhelst]
b) the three beforementioned teams could already refuse to
support a port anyhow, simply by not doing the work.
This is not really a valid argument. If a team in debian refuses to
accept
Jonas Smedegaard [EMAIL PROTECTED] writes:
- binaries must have been built and signed by official Debian
Developers
Currently, sponsored packages are only signed, not built, by official
Debian Developers.
I always build the packages before sponsor it since I usually check
against trivial
79 matches
Mail list logo
