On 2008-03-16 23:59:52 (+), Steve McIntyre <[EMAIL PROTECTED]> wrote:
> [ Please note Reply-To: to debian-cd... ]
>
> Hi folks,
>
> It's time for me to ask the question again - what CDs and DVDs will we
> find useful enough that we should make them for lenny? The reason I'm
> asking is that w
For those that are interested:
CALL FOR PAPERS for the 6th EMBEDDED track at FOSDEM 2008
=
sat 23 - sun 24 February 2008, Brussels
Call for papers
The 2008 edition of FOSDEM (Free and Open Source Developers' European
Meeti
>
> But say you have the old i486 ls installed in /bin/ls and now you
> install the new amd64 ls in /bin/ls/x86_64.
>
> Wait a second. How do you create the dir when the file already exists?
> dpkg has to specialy handle this case for every package.
>
That's probably a bit of a problem. But tha
> > I don't think so. I see at least a few possible uses for this :
> >
> > 1) have a shared filesystem between machines of multiple architectures
> > 2) test your programs on architectures you don't have by using qemu
>
> It might have its use there but it can't be simply done. The files
> from t
>
> The obvious problem here: The scheme is incompatible with non-multiarched
> software. It would at least require a package manager which specialcases
> /bin directory, a one-time conversion which moves the binaries, and
> some trickery for alternatives. Plus some more things which don't co
> > Being able to install multiple versions is some use to multiarch, but
> > could also be used for other things, such if two packages provide the
> > same binary (git for example).
> > Or to install multiple 'version 'numbers' of the same package.
>
> The big problem then is when to install mult
Package: wnpp
Severity: wishlist
Owner: "Peter 'p2' De Schrijver" <[EMAIL PROTECTED]>
* Package name: libftdi
Version : 0.7
Upstream Author : Intra2net AG <[EMAIL PROTECTED]>
* URL : http://www.intra2net.com/de/produkte/opensourc
On Sat, Dec 10, 2005 at 04:00:14PM +0100, Daniel Baumann wrote:
> Francesco Paolo Lovergine wrote:
> > X31 and T43p, and some friends with X40 and A series :-P
>
> I can even top that one: r40, r50, x31, x40, x41, t42p, t43p and a30 :PP
>
You want a beowulf of thinkpads ? :)
> (and, just for th
On Mon, Sep 19, 2005 at 12:59:52PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 19, 2005 at 08:16:42AM +, W. Borgert wrote:
> > On Mon, Sep 19, 2005 at 10:45:26AM +0930, Debonaras Project Lead wrote:
> > > The Debonaras project (http://www.debonaras.org) is a group of Linux
> > > developers wh
> 2) make makedev produce more of these files (but probably most users
>don't need them, at least not on desktop PCs which have seldomly
>two mouses or keyboards)
That's probably the right solution. Device nodes hardly take any
resources anyway.
Cheers,
Peter (p2).
signature.asc
Descri
> > > * 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 n
> * 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 automa
On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
> wrote:
> >Something like this is in fact considered. Probably Ubuntu won't use
> >pbuilder itself since it is not the most efficient implementation
> >around, but rebu
On Tue, Aug 23, 2005 at 12:00:07AM +0200, Wouter Verhelst wrote:
> On Mon, Aug 22, 2005 at 01:53:37PM +0200, Peter 'p2' De Schrijver wrote:
> > > Claiming "nobody sane will ever use that" means someone who's actually
> > > interested in using said
> Uh, no. Just to name one example: tell me, are you absolutely and 100%
> sure no user will ever try to use a gecko-based browser on an older
> architecture? And yes, if you want to support that, that means you have
> to build mozilla
>
> There _are_ lightweight gecko-based browsers, you know.
>
>
> I don't agree with that interpretation of "arch-specific", and neither
> do the maintainers of the Packages-arch-specific list AFAICT, so please
> stop trying to use creative interpretations of people's words to torpedo
> the proposal that porters should be accountable for their ports.
>
I
> > but well, I suppose the line is hard to draw.
>
> Exactly, and that is why we don't try.
>
> I agree with you that mozilla is probably fairly useless on m68k. But if
> you start excluding packages, you'll fairly soon end up on a slipperly
> slope where you start excluding packages, and in the
> > Trivial. debootstrap does that.
>
> Debootstrap is not an installer, in very much the same way that tar
> isn't, either.
>
They both are. They can install debian, so it's an installer.
> > > - security team, DSA, and release team must not veto inclusion
> >
> > Arbitrary veto power. This
On Mon, Aug 22, 2005 at 11:05:59AM +0200, Pierre Habouzit wrote:
> Le Lun 22 Août 2005 10:29, Peter 'p2' De Schrijver a écrit :
> > Hi,
> >
> > > The "reasonable foundation" for having a redundant buildd in a
> > > separate physical loca
> > How do you boot to a system to run debian-installer when there is no
> > bios or bootloader on the system yet?
>
> Just take a look at the existing Debian ports, and you see that it's ok
> to use a bios that's part of the hardware.
>
> > Should debian-installer support
> > installing via JTAG
Hi,
> The "reasonable foundation" for having a redundant buildd in a separate
> physical location is, I think, well-established. Any random facility
> can lose power, perform big router upgrades, burn down, etc. Debian
> machines also seem to be prone to bad RAM, bad power supplies, bad disk
> a
Hi,
>
> > Bogus requirement. At the moment we have less then 1 s390 buildd for
> > example.
>
> "machine" translates with partition btw - though the two different
> partitions should be in different physical locations, for obvious
> reasons. Yes, we want a redundancy for good reasons.
>
Which
Hi,
Some comments :
> Initial:
> - must be publically available to buy new
Trivially true for any architecture, even VAX.
> - must be freely usable (without NDA)
> - must be able to run a buildd 24/7 without crashing
> - must have an actual, working buildd
> - must include basic UNIX functional
>
> Ummm... And if instead of asking the user for a disk change, this
> mini-initrd just keeps polling the floppy for a non-erroneous read
> (this means, the drive is not empty) with the correct magic at the
> correct place?
I don't think you actually have to read anything. You can use the disk
c
> That gdb-problem is under investigation.
>
> > Well, at least we've got a porter machine, could that be turned into a
> > buildd on relatively short notice if necessary? The gdb issue is
> > something I certainly hope is being looked into or at least has been
> > brought up to the LKML and debi
On Tue, Jun 07, 2005 at 09:47:23AM +0200, Stig Sandbeck Mathisen wrote:
> Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes:
>
> > That sounds retarded in an age where a 200GB HD cost less then 100
> > Euro...
>
> Regarding storage: "Fast, cheap and
On Mon, Jun 06, 2005 at 11:24:14PM +0200, Wouter Verhelst wrote:
> On Mon, Jun 06, 2005 at 07:22:08PM +0200, Peter 'p2' De Schrijver wrote:
> > > * Split the architectures over two sets of mirror networks, so that
> > > mirror administrators don't nee
> > Then how did these people end up choosing to support the same set of
> > architectures as Ubuntu?
>
> I know I've been screaming murder and hell about this, but in hindsight,
> after having read the proposers' explanations (and the proposal itself
> for a few more times), this certainly is not
On Sat, Apr 09, 2005 at 01:13:57PM -0400, Andres Salomon wrote:
> On Thu, 07 Apr 2005 01:11:38 +0200, Peter 'p2' De Schrijver wrote:
>
> > Hi,
> >
> > Reading http://lists.debian.org/debian-legal/2004/12/msg00078.html I
> > wondered if people would be wi
Hi,
Reading http://lists.debian.org/debian-legal/2004/12/msg00078.html I
wondered if people would be willing to work on a free firmware for
the Tigon II chip. I didn't look at the existing code yet, but looking
at the datasheet
(http://alteon.shareable.org/firmware-source/12.4.13/tigonbk.pdf.bz2)
On Sun, Apr 03, 2005 at 10:30:03PM +1000, Andrew Pollock wrote:
> On Sun, Mar 27, 2005 at 05:03:50PM +0200, Peter 'p2' De Schrijver wrote:
> >
> > You don't need to install anyone else's operating system. You can easily
> > do :
> >
> > Boo
On Sun, Mar 27, 2005 at 03:00:07AM -0800, Steve Langasek wrote:
> On Tue, Mar 15, 2005 at 01:39:27PM +0100, Peter 'p2' De Schrijver wrote:
> > > | - the release architecture must have a working, tested installer
> > > I hope that's obvious why. :)
>
>
>
> The only sarge architectures that are likely of being affected by your
> "must be publicly available to buy new" rule during the next 10 years
> are hppa and alpha (dunno about s390).
>
Given IBM's track record in backwards compatibility I don't expect s390
to die at all :) Even the latest
On Tue, Mar 22, 2005 at 07:45:00AM +, Alastair McKinstry wrote:
> On Máirt, 2005-03-22 at 00:11 +0100, Peter 'p2' De Schrijver wrote:
> > > If Debian is keeping an arch alive so much that one can still buy it new,
> > > I
> > > certainly can't see
> If Debian is keeping an arch alive so much that one can still buy it new, I
> certainly can't see why we should not continue releasing for that arch,
> however. So I'd say Matthew's explanation is not perfect. But the
> reasoning behind it is not difficult to spot.
>
> Throwing out this requir
> That has happened, but that are not the really bad problems with the
> toolchain. The really bad problems is if e.g. a class of packages starts
> to fail to build from source. Or some new required kernel version forces
> all to upgrade some autoconf-scripts.
>
Both problems are easy to solve co
>
Because it should not be reason to throw out an entire architecture. Ie.
if the package can not be compiled on $arch and the toolchain can not be
fixed in time, then release $arch without the package instead of
throwing out the whole arch.
Cheers,
Peter (p2).
signature.asc
Description: Digi
> * the release architecture must be publicly available to buy new
>
> Avoids a situation where Debian is keeping an architecture alive. This
> isn't intended to result in an architecture being dropped part way
> through a release cycle or once it becomes hard to obtain new hardware.
>
What prob
> A QA measure for kernel/toolchain issues, sure. Many compiler bugs are
> identified by compiling 10G worth of software for an architecture;
> perhaps we should have a better way of tracking these, but it surely is
> a class of problems that /cannot/ be identified by just building on the
> big N
On Mon, Mar 21, 2005 at 03:09:26PM +0100, Andreas Barth wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) [050321 15:05]:
> > On Sun, Mar 20, 2005 at 03:16:08PM +0100, Andreas Barth wrote:
> > > Well, the toolchain is perhaps not the part where they turn up most
> > > likely, but it's the part that cr
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? (As
> > * 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 application
> Yes, but the argument against cross-compiling has always been stronger
> - If you are compiling under an emulator, you can at least test the
> produced binaries under that same emulator, and you have a high degree
> of confidence that they work reliably (this is, if an emulator bug
> leads to gcc
On Fri, Mar 18, 2005 at 06:58:50PM -0800, Thomas Bushnell BSG wrote:
> Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes:
>
> > A much faster solution would be to use distcc or scratchbox for
> > crosscompiling.
>
> Debian packages cannot be reliably bui
On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote:
> Hi,
>
> I haven't followed as thoroughly as I would have liked the recent
> verborrhea in the list regarding the Vancouver proposal. Anyway, I'd
> like to raise a point that I brought up during Debconf3, in the light
> of the changes t
> Porters who have worked on getting an arch to REGUALR status are in a much
> better position (demonstrated commitment, technical aptness and
> experiencewise) to solve those problems than random-joe-developer.
>
I have no idea what you're trying to say here.
> Always remember that the main r
> Except the possibility to profit from the release team's efforts,
> and to create an actually supported release. It is not reasonable
> to believe a small porter team can do security updates for a
> unstable snapshot when a task of similiar size already overloads
> the stable security team.
>
N
On Thu, Mar 17, 2005 at 08:22:04PM +0100, Goswin von Brederlow wrote:
> Andreas Barth <[EMAIL PROTECTED]> writes:
>
> > * Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
> >> Andreas Barth wrote:
> >> >If that happens for a too long period, we might consider such an
> >> >architecture to be too slo
> > Sbapshots of unstable. And people would run that on their servers?
>
> Some, maybe. Are there lots of people running servers on m68k and arm?
>
Debian/ARM is becoming viable as a handheld platform as they get 400+
Mhz CPUs and gigabytes of storage (which is all available now).
Cheers,
Pe
> > I strongly disagree with this. There is a need for a set of base
> > packages to work, but it's entirely reasonable to have a release for eg
> > m68k without KDE or other large package sets. It's not as if debian/m68k
> > would be unusable without KDE packages for example.
>
> You might try t
> | - the release architecture must have N+1 buildds where N is the number
> | required to keep up with the volume of uploaded packages
> The reason for this proposal should be instantly clear to everyone who
> ever suffered from buildd backlogs. :)
>
> We want that all unstable packages are dir
> The main problem with distcc across architectures is the FUD
> surrounding whether gcc-as-cross-compiler spits out the same code as
> gcc-as-native-compiler. The gcc team seem to be very hesitant to make
> any guarantees about that, as it's not something they test much.
> Without better inform
> There are a few reasons why we usually avoid cross-compilers for buildd
> purposes. For one, as one cannot as easily test a cross-compiler by
> running a test suite, it may have been miscompiled -- but you wouldn't
> notice; this would result in strange, hard to debug behaviour by the
> resulting
On Wed, Feb 02, 2005 at 04:41:15PM +, Paul Brossier wrote:
> On Wed, 2005-02-02 at 10:41 +0100, Peter 'p2' De Schrijver wrote:
> > * Package name: btexmms
>
> xmms plugins would be better named xmms- (btexmms for the
> source should be fine though)
>
Package: wnpp
Severity: wishlist
* Package name: btexmms
Version : x.y.z
Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
Description : XMMS plugin to use some (Sony) Ericsson phones as a
>
> And I still don't think anyone could argue that it would be reasonable
> to stick a driver on a Debian CD with a README that says "if you want
> to use this driver, you'll need to write a firmware file for your SCSI
> card. Use the following assembler"
>
I never said the USER HAS to wri
>Firmware files are not the sort of thing people can create their own
>versions of. In most cases the format is not documented and there
>are no free or even publicly available tools for this, and even in
>cases where it *is* documented, this is not by any stretch of the
>imagi
> What would you gain by having the firmware source.
> Please don't tell me that you want to fix bugs there.
>
> The firmware is part of the hardware and we don't ask the vendors to
> give away their .vhdl files of the hardware. Both firmware and hardware
> source are useless as they usually need
Hi,
>
> * We should commit to strict release cylces of a base system others
>(and Debian itself) can build value upon.
>
> * We should proabably also commit to a set of core architectures which
>*need* to be bug-free on release, while the rest *should* be, but
>would not delay the
59 matches
Mail list logo
