[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Arm bof and raspbian.

Wookey wrote:
+++ peter green [2013-08-16 23:09 +0100]:
Wookey wrote:
Afterwards another suggestion was made: to simply do an armv6,vfp2
rebuild of armhf in ports.debian.net.
Never heard of ports.debian.net before. Is it in any way related to

Yes, that's what I meant.
Ok so you are saying ports.debian.net and debian-ports.org are the "same thing"?
Not sure how it's any easier than raspbian is now.

Well it would be pretty-much the same, but rather closer to the debian
It would be closer though i'm quite open to other dd's getting involved with raspbian.
and what advantage it would give over using the
infrastructure we have built out for raspbian, whether it could
handle the load (archive.raspbian.org and
mirrordirector.raspbian.org have nontrivial load),

I assume we can handle plenty of load, (there are 6 mirrors) but I
don't know the details, and yes there isn't much point moving stuff
unless there is some significant advantage.
I agree, unless significant advantages are demostrated i'm keeping things as they are with raspbian hosted on it's own server (generously dontated by bytemark).

BTW we have a mirrorbrain setup in place directing users to a lot more than 6 mirrors.

One possibility if there is someone sufficiently interested* in
unstable for the Pi would be to use ports.debian.net for that and
keep raspbian.org for testing and stable (for various reasons having
a derivative of unstable and a derivative of testing in the same
repo opens up a lot of nasty corner cases).

Yes it's true that ports does a good job of keeping unstable going,
but not stable. Not sure what happens if we enable that.
Doing both unstable and testing in the same repository for a derivative (and from this perspective debian-ports.org can be considered a derivative) is difficult due to the following scenario

1: Package x is uploaded to unstable and is built
2: A new version of library y is uploaded to unstable and is build
3: The derivative picks up both changes but ends up building library y because package x so package x ends up with a dependency on the new version of library y that package x in debian does not have.
4: package x in debian migrates to testing but library y does not

Now what is the derivative supposed to do? if it just blindly follows testing transitions from debian it will put package x into testing before it's dependencies are available. Working out a set of rules to handle this while keeping things reasonablly aligned with debian is nontrivial.

There is that. How many of what are you currently using?
Currently we are actually in the process of an upgrade and hosting change for our build hardware. We are trying to move out of basement hosting and into proper hosting and at the same time upgrade our autobuilders to something more modern.

Right now 8 imx53 boards at mikes place are building raspbian wheezy (and sitting mostly idle now wheezy is released) while a 2GB nitrogen6x and wandboard quad at my place are building raspbian jessie (and marginally keeping up most of the time but sometimes falling behind). We hope to move to a setup with four nitrogen6x boards at a proper hosting location for both raspbian wheezy and raspbian jessie in the not too distant future. Four wandboard quads will set you back about £500, you will need to add in accessories on top of that which i'm guessing will bring the price to ~£1K total depending on exactly what setup you go for.

If someone is serious about setting things up for an armv6 hardfloat sid, and is prepared to put up with autobuilders that have only 1GB of ram and a single core processor we may consider donating some of our old build hardware to them when we decommision it (can't say how long that will be though, it depends how long it takes to get the new cluster set up).

Having said that i'd rather see the effort go into reducing the delta between jessie and sid than into running a build cluster for armv6 sid.

Reply to: