Re: [GR] DD should be allowed to perform binary-only uploads
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 got a few cases where emulated builds on amd64, sparc64 and s390x failed to produce working binaries for i386, sparc and s390. Usually, these are considered bugs in the affected packages. And what exactly is this emulation? It's just running the 32 bit application on the 64 bit arch? Eg. syscalls are translated from the 32bit to the 64bit world (arch/x86_64/ia32/sys_ia32.c). L L p2. -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
On Wed, Aug 30, 2006 at 10:00:43PM -0400, David Nusinow wrote: On Wed, Aug 30, 2006 at 09:54:31PM -0400, David Nusinow wrote: On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote: David Nusinow [EMAIL PROTECTED] writes: Would you, or someone else, mind pointing out some examples of firmware with source? Preferrably with some of the breadth you refer to above? I understand firmware in concept, but beyond seeing it as a binary blob I've not really come seriously in to contact with it. If I'm going to vote on this issue, I'd really like to actually understand what I'm going to be voting on. I think it's widely in agreement that hardware manufacturers have assemblers and other tools they use for building firmware. So we don't have any firmware with source? Sorry. I've since read further in to this thread and found answers. I'll grab the kernel code and have a look. - David Nusinow Look at http://alteon.shareable.org/ for an example of actual production firmware (for the tigon 2 gige NIC) including source code and modified gnu tools for compiling. L L p2. -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
On Wed, Aug 30, 2006 at 10:00:43PM -0400, David Nusinow wrote: On Wed, Aug 30, 2006 at 09:54:31PM -0400, David Nusinow wrote: On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote: David Nusinow [EMAIL PROTECTED] writes: Would you, or someone else, mind pointing out some examples of firmware with source? Preferrably with some of the breadth you refer to above? I understand firmware in concept, but beyond seeing it as a binary blob I've not really come seriously in to contact with it. If I'm going to vote on this issue, I'd really like to actually understand what I'm going to be voting on. I think it's widely in agreement that hardware manufacturers have assemblers and other tools they use for building firmware. So we don't have any firmware with source? Sorry. I've since read further in to this thread and found answers. I'll grab the kernel code and have a look. The kernel source has firmware with source for the keyspan PDA USB serial dongle (linux-2.6.17.7/drivers/usb/serial/keyspan_pda.S). http://homepage3.nifty.com/StudioBreeze/software/bin/usbmidi-20040829.tar.gz has firmware with source for some M-audio midisport midi interfaces. sdcc is needed for compilation. L L p2. -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Hi, Well, the point is the following. From the driver point of view, it speaks to the device, with a given protocol, over a given hardware interface (pci, random set of GPIO pins, etc). No. It talks to the firmware. Or do you really believe anything else then the firmware can give a sensible answer to commands like 'get version' ? And why do the commands remain unanswered before the firmware is loaded ? But there is no way the device driver can make a difference between speaking to said firmware program running on the device, or to a firmware version not uploaded but hold in flash, or to a hardcoded non-firmware device. It can. Requests remain unanswered or return an error when the driver sends them before the firmware is loaded. Requests do get answered properly after the firmware has been loaded and started. In short don't try to deny reality... Cheers, Peter (p2). -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Though I understand your motivation, I prefer to have this GR executable (hm, is this the right word?), i.e. a text that has as few as possible disambiguties. If we say until it will become practical, anyone can jump up even next week to say now it is practical. I however want a statement from all developers they are not (now). I'm only willing to give you : They are, but I'm willing to live with it for now as I don't have a good idea yet on what is acceptable and what not. L L p2. -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Hi, I'd actually see some restriction with regard to interoperability (i.e. some reasonably documented interface between the firmware and the driver code), but getting this right is likely not worth the effort. Hmm, I'm not sure what that would look like at all; as someone else noted, one generally doesn't talk to the firmware even, one talks to the device. That's mostly wrong. In case of the DAC960 for example the driver does talk to the firmware, same for the fore ATM cards or USB devices which have downloadable firmware. L L p2. -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
On Sun, Mar 20, 2005 at 09:27:26AM +0100, Matthias Urlichs wrote: Hi, Peter 'p2' De Schrijver wrote: This is obviously unacceptable. Why would a small number of people be allowed to veto inclusion of other people's work ? Why not? (Assuming they do have a valid reason. For instance, I probably wouldn't allow an MMIX port into the archive even if it sat up and begged.) Because it's not fair ? I would allow an MMIX port if it would exist and work. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: my thoughts on the Vancouver Prospectus
* Why is the permitted number of buildds for an architecture restricted to 2 or 3? - Architectures which need more than 2 buildds to keep up with package uploads on an ongoing basis are very slow indeed; while slower, low-powered chips are indeed useful in certain applications, they are a) unlikely to be able to usefully run much of the software we currently expect our ports to build, and b) definitely too slow in terms of You're sprouting non-sense here. The vast majority of the debian packages is useful on slower architectures. single-package build times to avoid inevitably delaying high-priority package fixes for RC bugs. - If an architecture requires more than 3 buildds to be on-line to keep up with packages, we are accordingly spreading thin our trust network for binary packages. I'm sure I'll get flamed for even mentioning it, but one concrete example of this is that the m68k port, today, is partially dependent on build daemons maintained by individuals who have chosen not to go through Debian's New Maintainer process. Whether or not these particular individuals should be trusted, the truth is that when you have to have 10 buildds running to keep up with unstable, it's very difficult to get a big-picture view of the security of your binary uploads. Security is only as strong as the weakest link. We now rely on about 1000 developers which can upload binary packages for any arch and they do not get rebuild by the buildd's. thanks for playing. - While neither of the above concerns is overriding on its own (the ftpmasters have obviously allowed these ports to persist on ftp-master.debian.org, and they will be released with sarge), there is a general feeling that twelve architectures is too many to try to keep in sync for a release without resulting in severe schedule slippage. Pre-sarge, I don't think it's possible to quantify slippage that's preventible by having more active porter teams vs. slippage that's due to unavoidable overhead; but if we do need to reduce our count of release archs, and I believe we do, then all other things being equal, we should take issues like the above into consideration. Would you please stop generalizing your opinions ? There is an idea in some people's mind that 12 architectures is too much. If you look at the number of reactions on this list, you will notice that a lot of people do not agree with you on this point. So stop inventing bogus arguments to justify your point. * Three bodies (Security, System Administration, Release) are given independent veto power over the inclusion of an architecture. A) Does the entire team have to exercise this veto for it to be effective, or can one member of any team exercise this power effectively? It's expected that each team would exercise that veto as a *team*, by reaching a consensus internally. This is obviously unacceptable. Why would a small number of people be allowed to veto inclusion of other people's work ? B) Is the availability of an able and willing Debian Developer to join one of these teams for the express purpose of caring for a given architecture expected to mitigate concerns that would otherwise lead to a veto? Without knowing beforehand what the reason for the veto would be (and if we knew, we would list them explicitly as requirements), this isn't possible to answer. So drop this bullshit veto thing. There is no reason to have this. Cheers, Peter (p2). signature.asc Description: Digital signature
