* Hamish Moffatt:
Do you think it's likely that it can boot the kernel and run the build
environment without crashing, but produce broken binaries?
We've got a few cases where emulated builds on amd64, sparc64 and
s390x failed to produce working binaries for i386, sparc and s390.
Usually,
On Wed, Feb 14, 2007 at 11:31:17AM +0100, Florian Weimer wrote:
* Hamish Moffatt:
Do you think it's likely that it can boot the kernel and run the build
environment without crashing, but produce broken binaries?
We've got a few cases where emulated builds on amd64, sparc64 and
s390x
On Wed, Feb 14, 2007 at 06:37:25PM +0100, Kurt Roeckx wrote:
On Wed, Feb 14, 2007 at 11:31:17AM +0100, Florian Weimer wrote:
* Hamish Moffatt:
Do you think it's likely that it can boot the kernel and run the build
environment without crashing, but produce broken binaries?
We've
On Sat, Feb 10, 2007 at 01:05:19PM +1000, Anthony Towns wrote:
On Sat, Feb 10, 2007 at 01:24:21AM +0100, Pierre Habouzit wrote:
One thing that strikes me is that in all of the emails so far,
everyone is ignoring that this whole thing started because Aurelien
decided to start autobuilding
On Tue, Feb 13, 2007 at 02:02:51AM +, MJ Ray wrote:
Neil McGovern [EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2007 at 11:58:46AM +, MJ Ray wrote:
What says SPI only listens to the DPL, not the project? AIUI, the DPL
is appointed as an adviser to SPI's board, not a veto.
Further
Neil McGovern writes (Re: [GR] DD should be allowed to perform binary-only
uploads):
I'll extract the exact line from the above text for you:
... state the SPI Board's current understanding of who is authorised to
act for the project ...
In this case, the DPL.
Nonsense. If we were
Neil McGovern [EMAIL PROTECTED] wrote:
On Tue, Feb 13, 2007 at 02:02:51AM +, MJ Ray wrote:
Yes, but sorry if this question was unclear: What says SPI only listens to
the DPL, not the project?
I'll extract the exact line from the above text for you:
... state the SPI Board's current
On Tue, Feb 13, 2007 at 11:20:24PM +, MJ Ray wrote:
Neil McGovern [EMAIL PROTECTED] wrote:
On Tue, Feb 13, 2007 at 02:02:51AM +, MJ Ray wrote:
Yes, but sorry if this question was unclear: What says SPI only listens to
the DPL, not the project?
I'll extract the exact line from
Neil McGovern [EMAIL PROTECTED] wrote:
On Tue, Feb 13, 2007 at 11:20:24PM +, MJ Ray wrote:
Neil McGovern [EMAIL PROTECTED] wrote:
On Tue, Feb 13, 2007 at 02:02:51AM +, MJ Ray wrote:
Yes, but sorry if this question was unclear: What says SPI only listens
to
the DPL, not
Martin Schulze [EMAIL PROTECTED] wrote:
Julien BLACHE wrote:
Could be at the request of the Project, via a GR I think, if the DPL
was, say, unwilling to act and fix a broken situation wrt
infrastructure administration and developer access to the said
infrastructure.
Unlikely. SPI
It was a mail to -devel, and I mispoke, it was aranym, not qemu,
;-) ok - getting closer to the true story here, but unfortunately I
could not locate any 'failed build' email in the -devel from him within
any reasonable timeframe where he would mentioned failed build. But I've
found
This one time, at band camp, Yaroslav Halchenko said:
It was a mail to -devel, and I mispoke, it was aranym, not qemu,
;-) ok - getting closer to the true story here, but unfortunately I
could not locate any 'failed build' email in the -devel from him within
any reasonable timeframe where he
On Monday 12 February 2007 09:08, Stephen Gran wrote:
[...] reproducibility will suffer. The fact that it failed to run the
binary correctly in this failure instance is good. But another day, it
may fail to correctly run gcc, and that would be bad if it exited 0 with
a wrongly built binary.
Wesley J. Landaker wrote:
On Monday 12 February 2007 09:08, Stephen Gran wrote:
[...] reproducibility will suffer. The fact that it failed to run the
binary correctly in this failure instance is good. But another day, it
may fail to correctly run gcc, and that would be bad if it exited 0
On Mon, 12 Feb 2007 10:20:12 -0500, Yaroslav Halchenko
[EMAIL PROTECTED] said:
The discussion is either it is as reliable to use emulator (QEMU in
particular) as the real box. You brought an example where build
process under emulator failed. I mentioned that it might be not
emulator false
The greater question is, if the archive masters request
developers not to submit packages built on emulated hardware, should
that request not be heeded?
No, why would that be within the bailiwick of the ftp-team? If you're
going to claim that they have ultimate authority over all
Neil McGovern [EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2007 at 11:58:46AM +, MJ Ray wrote:
What says SPI only listens to the DPL, not the project? AIUI, the DPL
is appointed as an adviser to SPI's board, not a veto.
Further down the resolution, which you snipped:
snip
Andreas Barth [EMAIL PROTECTED] wrote:
Note that if you can get SPI to transfer the debian.org zone to other
DNS servers than the current ones, you can NMU the infrastructure.
I heavily disagree to that. The current servers are owned by Debian or
sponsored to Debian by some people. So Debian
Note that if you can get SPI to transfer the debian.org zone to other
DNS servers than the current ones, you can NMU the infrastructure.
Andreas Barth [EMAIL PROTECTED] wrote:
I heavily disagree to that. The current servers are owned by Debian or
sponsored to Debian by some people. So
On Sat, Feb 10, 2007 at 09:17:44PM +0100, Julien BLACHE wrote:
Clint Adams [EMAIL PROTECTED] wrote:
Debian infrastructure and portions thereof are not analogous to
packages. As many have pointed out already, packages can be NMUed.
Note that if you can get SPI to transfer the debian.org
Neil McGovern [EMAIL PROTECTED] wrote:
Note that if you can get SPI to transfer the debian.org zone to other
DNS servers than the current ones, you can NMU the infrastructure.
But (probably) only if it was at the request of the DPL.
Could be at the request of the Project, via a GR I think,
Julien BLACHE wrote:
Note that if you can get SPI to transfer the debian.org zone to other
DNS servers than the current ones, you can NMU the infrastructure.
But (probably) only if it was at the request of the DPL.
Could be at the request of the Project, via a GR I think, if the DPL
Martin Schulze [EMAIL PROTECTED] wrote:
Unlikely. SPI usually has a defined authorisationship with an associated
project, this refers to people, not the project as a whole or their
developers or their internal voting results. However, a GR should be
able to kick the DPL out of leadership
This one time, at band camp, Hamish Moffatt said:
On Sat, Feb 10, 2007 at 12:02:57AM +, Stephen Gran wrote:
I am sure qemu is very good at what it does, but I do not have faith
that it can stand in for a real CPU in all the corner cases. If
Do you think it's likely that it can boot
Julien BLACHE wrote:
Martin Schulze [EMAIL PROTECTED] wrote:
Unlikely. SPI usually has a defined authorisationship with an associated
project, this refers to people, not the project as a whole or their
developers or their internal voting results. However, a GR should be
able to kick
Julien BLACHE [EMAIL PROTECTED] writes:
Which is interesting, considering that in such a situation we might
not even be able to run a vote.
To block a vote you need both the Project Secretary and the chairman
of the ctte to act together. Even then the body of the ctte could
simply elect a new
Kurt Roeckx [EMAIL PROTECTED] wrote:
On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
The error rate on requeue requests that reach me is significant, even from
people who are well-informed and involved in the process (e.g., fellow
On Sun, 11 Feb 2007, Stephen Gran wrote:
ballombe has already found differences between an emulated environment
and a real cpu, where the test suite failed on qemu and passed on a real
cpu. I have no confidence that it can't fail the other way.
I am sorry - could you please refer to that case?
On 2007-02-10, Anthony Towns aj@azure.humbug.org.au wrote:
Personally, I don't like either of the checks, but I've seen zero
effort from Aurelian and friends to demonstrate they can be trusted,
if we have DDs that can't be trusted, don't we have major problem?
AJ: if you really mean they are
At 1171076719 time_t, Anthony Towns wrote:
Personally, I don't like either of the checks, but I've seen zero
effort from Aurelian and friends to demonstrate they can be trusted,
and this GR just seems to be continuing the whole adversarial approach,
so as far as I'm concerned the last sentence
Steve Langasek [EMAIL PROTECTED] wrote:
The error rate on requeue requests that reach me is significant, even from
people who are well-informed and involved in the process (e.g., fellow
release-team members). Maybe they're less cautious because they know I vet
all requests, but I would
Andreas Barth [EMAIL PROTECTED] wrote:
* Manoj Srivastava ([EMAIL PROTECTED]) [070210 04:44]:
However, a buildd
operator using qemu is not responsible for bugs filed on the packages
created on his set up -- He is not performing an NMU.
I disagree on this statement. If I e.g. upload an
On Sat, Feb 10, 2007 at 10:34:34AM +0100, Julien Danjou wrote:
At 1171076719 time_t, Anthony Towns wrote:
Personally, I don't like either of the checks, but I've seen zero
effort from Aurelian and friends to demonstrate they can be trusted,
and this GR just seems to be continuing the whole
http://www.beyondintractability.org/essay/trust_building/
Might be a good start. I'm sure Google can find you other things.
Implying that the people whom you'd like to trust you are unreasonable
probably isn't a good start.
Great. I don't trust you to do the right thing as DPL. I don't
On Sat, 2007-02-10 at 15:27 +0100, Frank Küster wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
[...]
Heck, before m68k was dropped as a factor in package propagation into
testing, I was routinely finding bogus dep-waits set by the m68k buildd
maintainers themselves, and that's only about a
On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
The error rate on requeue requests that reach me is significant, even from
people who are well-informed and involved in the process (e.g., fellow
release-team members). Maybe they're
On Sat, 10 Feb 2007 11:00:28 -0500, Clint Adams [EMAIL PROTECTED] said:
http://www.beyondintractability.org/essay/trust_building/
Might be a good start. I'm sure Google can find you other things.
That's a pretty decent essay. I found myself mostly in
agreement.
Implying that the
On Thu, 8 Feb 2007 10:41:29 -0700, Wesley J Landaker
[EMAIL PROTECTED] said, in:
Message-Id: [EMAIL PROTECTED]
Seconded.
I can not verify the signature on this message.
manoj
Bad signature from F0A98A4C4CD6E3D2 Wesley J. Landaker [EMAIL PROTECTED]
--
You get what you pay
It is actually pretty relevant to your packages. I do not
expect you to add co-maintainers to zsh packages whom you do not
trust. It is pretty irrelevant to areas you are not responsible
for.
Debian infrastructure and portions thereof are not analogous to
packages. As many have
Clint Adams [EMAIL PROTECTED] wrote:
Debian infrastructure and portions thereof are not analogous to
packages. As many have pointed out already, packages can be NMUed.
Note that if you can get SPI to transfer the debian.org zone to other
DNS servers than the current ones, you can NMU the
On Sat, Feb 10, 2007 at 12:02:57AM +, Stephen Gran wrote:
I am sure qemu is very good at what it does, but I do not have faith
that it can stand in for a real CPU in all the corner cases. If
Do you think it's likely that it can boot the kernel and run the build
environment without
* Julien BLACHE ([EMAIL PROTECTED]) [070210 21:17]:
Clint Adams [EMAIL PROTECTED] wrote:
Debian infrastructure and portions thereof are not analogous to
packages. As many have pointed out already, packages can be NMUed.
Note that if you can get SPI to transfer the debian.org zone to
On Sat, Feb 10, 2007 at 03:27:25PM +0100, Frank Küster wrote:
- it's not easy to see what's going on there, and why. For example, I
don't know where I can read what dep-wait means and why and how a
package is put in this state.
On Fri, Feb 09, 2007, Loïc Minier wrote:
I am not sure you got my last two arguments, or you're distorting them
here: I'm not discussing the current or best upload rights, I would
certainly prefer it if everybody could upload arm binaries; what I'm
pointing at is that this GR might
Sam Hocevar [EMAIL PROTECTED] wrote:
I think you got it backwards, it seems to me to be about reinstating
some developers' rights. Unless unilaterally preventing developers from
doing something that has always be possible in Debian is considered a
right, of course.
Ah, we'll need another
At 1171012211 time_t, Julien BLACHE wrote:
Ah, we'll need another GR to be able to log into *all* debian hosts
again, then. Because that's something that has always been possible in
the past, until a couple of years ago.
Seconded.
Cheers,
--
Julien Danjou
.''`. Debian Developer
: :' :
Bill Allombert [EMAIL PROTECTED] writes:
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the same set of architectures.
The use case I imagine at this point is that
On Fri, Feb 09, 2007 at 01:52:20PM +0100, Reinhard Tartler wrote:
Bill Allombert [EMAIL PROTECTED] writes:
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the
On Fri, Feb 09, 2007 at 02:44:37PM +0100, Francesco P. Lovergine wrote:
The security implications of those practices should be evident to anyone.
This is (sorry) bullshit. Binary only uploads are _not_ less secure
than binary+source ones. Having a source side by side with the binary
module
At 1171031848 time_t, Pierre Habouzit wrote:
At no stage the fact that the upload is not sourceless helped. src+bin
uploads is just a moral contract from the uploader that he did not faked
the build and tested it. a _moral_ constraint, not a technical one.
OMG, so we need a moral-ctte.
On a
On Fri, Feb 09, 2007 at 03:37:28PM +0100, Pierre Habouzit wrote:
On Fri, Feb 09, 2007 at 02:44:37PM +0100, Francesco P. Lovergine wrote:
The security implications of those practices should be evident to anyone.
This is (sorry) bullshit. Binary only uploads are _not_ less secure
than
I don't recall murphy being open access in the nine years or so I've
been a DD.
Did you never see a problem with that?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Friday 09 February 2007 05:52, Reinhard Tartler wrote:
The use case I imagine at this point is that a maintainer uploads a
library package src+bin (e.g. src+amd64) for his private arch, and after
weeks he notices, that it still has not been built on e.g. sparc yet. So
he decides to start
Francesco P. Lovergine [EMAIL PROTECTED] wrote:
On Fri, Feb 09, 2007 at 03:37:28PM +0100, Pierre Habouzit wrote:
On Fri, Feb 09, 2007 at 02:44:37PM +0100, Francesco P. Lovergine wrote:
The security implications of those practices should be evident to anyone.
This is (sorry) bullshit.
On Fri, Feb 09, 2007 at 03:55:32PM +0100, Francesco P. Lovergine wrote:
On Fri, Feb 09, 2007 at 03:37:28PM +0100, Pierre Habouzit wrote:
On Fri, Feb 09, 2007 at 02:44:37PM +0100, Francesco P. Lovergine wrote:
The security implications of those practices should be evident to anyone.
On Fri, Feb 09, 2007 at 08:23:54AM -0700, Wesley J. Landaker wrote:
On Friday 09 February 2007 05:52, Reinhard Tartler wrote:
The use case I imagine at this point is that a maintainer uploads a
library package src+bin (e.g. src+amd64) for his private arch, and after
weeks he notices, that
On Fri, Feb 09, 2007 at 04:35:24PM +0100, Pierre Habouzit [EMAIL PROTECTED]
wrote:
One could also ask the maintainer to upload (or send to the right
email address) the buildd logs of their build if that's really a
problem. Note that could be a good thing anyway, as it could help to
spot
* Mike Hommey ([EMAIL PROTECTED]) [070209 19:00]:
On Fri, Feb 09, 2007 at 04:35:24PM +0100, Pierre Habouzit [EMAIL PROTECTED]
wrote:
One could also ask the maintainer to upload (or send to the right
email address) the buildd logs of their build if that's really a
problem. Note that
On Fri, Feb 09, 2007 at 08:19:07PM +0100, Andreas Barth wrote:
That sounds like a good idea anyways. Perhaps we can start with be an
optional part for starters, and see how it performs.
Déjà vu. What happened the last time when you suggested (and
implemented) an optional part in a Debian data
On Fri, Feb 09, 2007 at 04:33:14PM +0100, Pierre Habouzit wrote:
* security (I _really_ think it's nonsense, as it's not less secure
than the usual DD's uploads, which I tried to prove) ;
Maybe security in this context means build can be reproduced by our
official buildd network and we
This one time, at band camp, Pierre Habouzit said:
I also addressed that part in my mail. The arguments I've read against
rogue buildds are threefold:
* security (I _really_ think it's nonsense, as it's not less secure
than the usual DD's uploads, which I tried to prove) ;
[0]
On Sat, Feb 10, 2007 at 12:02:57AM +, Stephen Gran wrote:
This one time, at band camp, Pierre Habouzit said:
I also addressed that part in my mail. The arguments I've read against
rogue buildds are threefold:
* security (I _really_ think it's nonsense, as it's not less secure
On Fri, Feb 9, 2007 at 17:17:10 +0100, Michael Banck wrote:
On Fri, Feb 09, 2007 at 04:33:14PM +0100, Pierre Habouzit wrote:
* security (I _really_ think it's nonsense, as it's not less secure
than the usual DD's uploads, which I tried to prove) ;
Maybe security in this context
On Sat, Feb 10, 2007, Julien Cristau [EMAIL PROTECTED] wrote:
On Fri, Feb 9, 2007 at 17:17:10 +0100, Michael Banck wrote:
Maybe security in this context means build can be reproduced by our
official buildd network and we are therefore sure our security team can
issue security updates for
On Friday 09 February 2007 17:02, Stephen Gran wrote:
I am sure qemu is very good at what it does, but I do not have faith
that it can stand in for a real CPU in all the corner cases. If
Aurelien builds a java package that had previously FTBFS'd, do we have
any guarantee that it will build
This one time, at band camp, Wesley J. Landaker said:
On Friday 09 February 2007 17:02, Stephen Gran wrote:
I am sure qemu is very good at what it does, but I do not have faith
that it can stand in for a real CPU in all the corner cases. If
Aurelien builds a java package that had
On Sat, Feb 10, 2007 at 01:24:21AM +0100, Pierre Habouzit wrote:
I agree that the way the restriction was implemented was odd, but I can
see the point of it. I doubt that the occasional one off binNMU is
going to have very much affect on the quality of the archive overall,
but I do have
FWIW, I got w-b access after demonstrating that I knew what needed done,
regularly feeding batches of give-back requests to Ryan and James for builds
that were release priorities/had obviously gone missing/had long-standing
build problems that had been resolved, and generally not trying to be
On Sat, Feb 10, 2007 at 01:24:21AM +0100, Pierre Habouzit wrote:
One thing that strikes me is that in all of the emails so far,
everyone is ignoring that this whole thing started because Aurelien
decided to start autobuilding packages in qemu.
That's not what justified the alpha problem
On Fri, 9 Feb 2007 18:16:38 -0700, Wesley J Landaker [EMAIL PROTECTED] said:
On Friday 09 February 2007 17:02, Stephen Gran wrote:
I am sure qemu is very good at what it does, but I do not have
faith that it can stand in for a real CPU in all the corner cases.
If Aurelien builds a java
* Manoj Srivastava ([EMAIL PROTECTED]) [070210 04:44]:
However, a buildd
operator using qemu is not responsible for bugs filed on the packages
created on his set up -- He is not performing an NMU.
I disagree on this statement. If I e.g. upload an package to unstable
linking to an
Dear Debian voters,
I hereby propose the following General Resolution for sponsoring.
---
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
On Thu, Feb 08, 2007 at 06:00:15PM +0100, Bill Allombert wrote:
Dear Debian voters,
I hereby propose the following General Resolution for sponsoring.
---
The Debian project resolves that Debian developers allowed to perform
combined
At 1170954015 time_t, Bill Allombert wrote:
---
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the same set of
On Thu, Feb 08, 2007, Bill Allombert wrote:
I hereby propose the following General Resolution for sponsoring.
---
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be
On 2007-02-08, Bill Allombert [EMAIL PROTECTED] wrote:
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Dear Debian voters,
I hereby propose the following General Resolution for sponsoring.
On Thursday 08 February 2007 10:00, Bill Allombert wrote:
Dear Debian voters,
I hereby propose the following General Resolution for sponsoring.
---
The Debian project resolves that Debian developers allowed to perform
combined source and
On Thursday 08 February 2007 10:33, Sune Vuorela wrote:
Why do you want to lose the ability to do src+bin uploads for arm+alpha?
It sounded to me like this GR is saying that binary-only uploads couldn't be
restricted to a small set of people, but would be allowed for anyone who
could normally
Sune Vuorela [EMAIL PROTECTED] wrote:
On 2007-02-08, Bill Allombert [EMAIL PROTECTED] wrote:
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Dear Debian voters,
I hereby propose the following General
On 2007-02-08, Wesley J. Landaker [EMAIL PROTECTED] wrote:
--nextPart7890285.rJ3zYKgNs2
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday 08 February 2007 10:33, Sune Vuorela wrote:
Why do you want to lose the
On Thu, Feb 08, 2007 at 06:00:15PM +0100, Bill Allombert [EMAIL PROTECTED]
wrote:
Dear Debian voters,
I hereby propose the following General Resolution for sponsoring.
---
The Debian project resolves that Debian developers allowed to
On Thu, Feb 08, 2007 at 06:58:06PM +0100, Frank Küster wrote:
Sune Vuorela [EMAIL PROTECTED] wrote:
On 2007-02-08, Bill Allombert [EMAIL PROTECTED] wrote:
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding:
On Thu, Feb 08, 2007 at 06:00:15PM +0100, Bill Allombert wrote:
---
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads
On Thu, Feb 08, 2007, Bill Allombert wrote:
The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the same set of architectures.
1) I know why this GR is proposed; I don't
On Thu, Feb 08, 2007, Loïc Minier wrote:
But since this GR is about revoking some ftpmasters rights which
should be exercized with judgment,
I think you got it backwards, it seems to me to be about reinstating
some developers' rights. Unless unilaterally preventing developers from
doing
Hi,
On Thu, Feb 08, 2007 at 06:00:15PM +0100, Bill Allombert wrote:
Dear Debian voters,
I hereby propose the following General Resolution for sponsoring.
---
The Debian project resolves that Debian developers allowed to perform
On Fri, Feb 09, 2007, Sam Hocevar wrote:
But since this GR is about revoking some ftpmasters rights which
should be exercized with judgment,
I think you got it backwards, it seems to me to be about reinstating
some developers' rights.
I am not sure you got my last two arguments, or
87 matches
Mail list logo
