OK, thanks for the clarification. I ran into some folks on the IRC were hardcore about the three year requirement. I think the basic answer is I need to take the time to learn this. It's just much less fun that building code and getting things work.
I wouldn't worry too much about it. I've never heard of someone getting into any trouble over minor technical violations of a license as long as when push comes to shove they do actually release the source code in question.
Ah, terrific suggestion. Fortunately, I've not had to modify any package yet except for the gcc compiler and one or two others to coax the compiler to build with certain optimization options. BTW,
Even if the modifications are trivial though (e.g changing optimisation levels) you still need to keep track of them so you can port them forward to new versions of packages.
I noticed some of the armh packages are stamped with ":armhf" in the binary package name/version. Is this for the same reason?
The filenames of binary packages contain _armhf to identify them as armhf packages in the archive. This has nothing to do with architecture specific modificaitons. Packages for all architectures in the official archive are built from the same source packages (though those source packages may contain conditionals that make them behave differently on different architectures).
:armhf in the package manager interface is notation related to multiarch, don't worry about that for now.
With regards to my repository, I've just got things setup at the most basic level on my internal server for binary files. I obviously need to get more sophisticated with things. Are there specific tools I should be looking to help manage upload and storage of packages in a repository?
There are many tools that can be used to manage a repositry. http://wiki.debian.org/HowToSe.....able_Tools
dak is the one used by the official archive but it's not normally used for unofficial repositries due to it's complexity.
mini-dak ( http://www.hadrons.org/~guillem/debian/mini-dak/
) is the tool used to run the debian-ports.org archive and is probablly where I would look first if I was doing a project like this.
Right now, I'm just using apt-ftparchive to lay things out and build the various indexes.
apt-ftparchive is fine for a local mini-repository but I don't think it's really designed for a project of this scale/type
Yeah, I have faith that once enough progress is made on a hard float version of Debian that shouldn't be too much of an issue. It really should be just a recompile. Perhaps I'm being naive though.
Yeah hopefully it should.
As long as the costs are reasonable (ie. can be kept under a few thousand), I can help build out the infrastructure. The only thing holding me back is some worries that the future of the RPi is somewhat murky and the hardware delays aren't exactly encouraging in this regards. However, hopefully it's all just a bump in the road, and RPi will get back its mojo.
I know the feeling, it's difficult to put too much into a project like this when one doesn't actually have the hardware in question and are looking at unknown lead times to get it.
I expect this as well. Where I could really get support from Debian is just having a few interested mentors/advisors who can help steer development of the port so that it honors the spirit of Debian and spend the time to give guidance to myself and others over whatever bumps in the road we're likely to encounter in trying to launch a full Debian port for the RPi. Would you, or someone you know, be interested in mentoring/advising in this manner?
I will certainly continue to advise you as best I can, once you make the repositry available I may even help with some actual troubleshooting.
As for following the spirit of debian I think the main things are making sure you release source, pushing any changes that are not specific to the Pi port back to debian, and generally trying to keep the differences between your port and normal debian to a minimum .
More stuff to learn about . I have zero clue what the "web of trust" is.
With PGP/GPG each key has one or more UIDs associated with it. Each UID usually contains a name and an email address. UIDs on a key can be signed by other keys.
When you sign a UID on someones key you are basically saying you have checked their ID and that it matches who they claim to be in their UID. Typically keysigning is reciprocal, you check their ID and sign their key and they check your ID and sign your key. It is also common to send the signatures by email to the email addresses in the UIDs rather than uploading them direct to the keyservers to show that the person has access to the email address they have placed in their UID.
These signatures form a directed graph known as the "web of trust", the more independent paths there are from your key to another key in the web of trust and the shorter those paths are the greater the assurance you can have that you are dealing with who you think you are dealing with.
So your personal key (which should at the very least be protected with a passphrase and not kept on systems that other people have access to) should be signed by some other people in the web of trust (preferably including debian developers if at all possible*). The keys used for autosigning the repo and uploads to it (if required by the archive setup you are using) should have UIDs that clearly identify them as automatic signing keys and should be signed by your personal key.
I think lintian is run everytime I build a package. I turn it off though using a switch in debuild as it is a major time sink and I'm not changing the packages.
Ah never used debuild myself, i've always used dpkg-buildpackage directly.
Anyway lintian is not normally run as part of the build process on autobuilders and I see no reason for you to run it on yours.
* You will need your key to be signed by debian developers if you ever want to become a DM or DD, further debian developers tend to be well connected in the web of trust and having your key signed by them should give your users more confidence that you are who you say your are.