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
debian-ports.org?
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
infrastructure.
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: