The start of raspbian (Debian Hard Float (armhf) for RPi)


 
614 posts   Page 3 of 25   1, 2, 3, 4, 5, 6 ... 25
by mpthompson » Fri Apr 06, 2012 9:54 pm
Sorry, I meant I'm reaching out to Dom.  It's been too long of a week.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by mpthompson » Sat Apr 07, 2012 4:24 am
A big thank you to Dom.  He booted the Debian armhf image on a beta Raspberry Pi and it actually worked.  In addition, he ran a simple benchmark on both the Debian armhf image and on the Debian armel image so we can compare the speeds between the two distributions.

The results of the benchmarks can be seen here: http://pastebin.com/2NZqH2yY

As expected, the hardware floating point execution was significantly faster than the software emulation.  Perhaps by a factor of 10x or better.  The benchmark also indicates the RPi hardware floating point outperforms the floating point operations of the iMX53 Cortex-A8 at 1 GHz, but this would need to be examined further.  Of course the Cortex-A8 is significantly faster in general computation by a factor of about 2x.

As things are looking pretty good, now to determine what the next steps might be.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by jerry.tk » Sat Apr 07, 2012 7:40 am
Mike, I registered here only because I wanted to say big THANK YOU for all the effort! I believe this is the only viable approach for using RPi to its fullest.

Hopefully I'll be an owner of iMX.53 in one or two months, too. Will be glad to help with compiling and stuff.

I am not an expert on all things ARM but I read somewhere that iMX.53 CPU actually has something called VFPlite - slower subset of the "real" VFP. This might explain floating point results discrepancy.
Posts: 63
Joined: Sat Apr 07, 2012 6:26 am
Location: CZ
by mpthompson » Sat Apr 07, 2012 11:18 am
jerry.tk said:


Mike, I registered here only because I wanted to say big THANK YOU for all the effort! I believe this is the only viable approach for using RPi to its fullest.


Thank you, I appreciate the encouragement.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by mpthompson » Sat Apr 07, 2012 11:22 am
Some thoughts about next steps.

Turning these first few steps into a real Debian port is going to take a serious amount of work.  I've read through a number of the early email threads on the debian-arm email list involving the armhf port and it took an enormous effort to get the that project started.  Much of that effort continues today as armhf problems are still being resolved in various packages.  Of course, an RPi flavored armhf port can leverage 99% of that effort, but even if it is just a task of recompiling and distributing the packages, there are 10,000's of Debian packages that need to built and managed.

First of all, if this is to be done, I would really like to see this be done right.  This project has a lot less appeal to me if the end result is only a minor subset of the Debian packages being made available that are just used by a handful of RPi hackers.  My own personal goal would be to make an RPi optimized Debian port as easy (of course that's a relative term) to use on the RPi as it is on any of the other platforms supported by Debian.  Any end user should be able to start with a basic Debian boot image on an SD card and then customize their system from the myriad of packages supported by Debian.  They should know that what they download will function as advertised and will run as efficiently as possible on the RPi.  If that can be achieved, I believe Debian would indeed become the premiere Linux distribution on the RPi and attract thousands of new users into using Linux in general, and Debian in particular.

Doing things right includes honoring all Debian licensing terms.  Much of it involving GPL.  It is particularly important that the project begin on the right footing in the this regards if we are going to attract the support of the Debian developers and community which is important for success.  This means that in addition to making the binary packages available, the source code also needs to be managed in such a way that it is available for download as well for a term of 3 years from the binaries being available.  I've already been told by people associated with Debian that simply pointing URLs at the source code for Debian packages is insufficient to satisfy the GPL licensing terms -- the source needs to be located with the binaries and equally accessible.  I mention this as it does increase the logistics of making packages available.  Also, how to handle the proprietary packages that would come from closed binaries from Broadcom and the RPi foundation would need to be resolved as well in a way consistent with Debian practices.

BTW, honoring the licensing terms is what is going to keep me from making available for now the binary packages I've already compiled.  I simply don't have the time or resources to honor, to the letter, the licensing terms with regards to source code.  However, I'll look into what I can do about this over the next week.  Although it may be more convenient, ignoring the terms now would not be setting this project on the right foot for long term success.

At this point, I'll need to get some Debian mentors.  These mentors will be people already established in the Debian hierarchy with upload privileges and they will have tribal knowledge of how to get things done "the Debian way".  Hopefully, because RPi is already so well known, finding mentors that will support a Debian armhf flavor for the RPi won't be a hard task.  The harder task will be convincing Debian mentors that I and other people interested in this project are serious and have the skills and motivation to see to the project through to success.  I'll start putting out some emails on this and see how far I get.

Another aspect to be considered is what hardware infrastructure will be required to compile the 10,000's of Debian packages and keep the packages refreshed as new versions are made available.  I simply don't yet know what would be involved with using existing Debian resources to build such packages and what might be involved with applying to use the resources -- this is where a mentor could help answer a lot of questions.  Looking over how other Debian ports began, it seems they usually start with hardware resources outside of Debian and as the port achieves success then Debian begins to consider how to fold the process of building packages for the port into the Debian build infrastructure.  If this is the case, this would involve purchasing and managing a build cluster of at least a half dozen systems to get the port underway.  This is usually done with the sponsorship of a company or university, but I don't see that happening here unless someone knows of a company willing to help sponsor a Debian port with financial and other resources.  As long as the costs can be kept reasonable, I can probably cover the expense of such a cluster (although I'll have to pass this by my wife :-) .

So, there are my early thoughts on what the next steps will be to make an RPi flavored Debian armhf port a reality.  More immediately, over the next week I'm going to investigate automating the Debian package build process -- most likely using sbuild.  This will undoubtedly involve hand building dozens of additional packages to install the sbuild.  However, once done, it should be easy to replicate and get other build systems set up.  Also, I'll need to start building the packages without cutting some corners such as skipping digital signatures, lintian processing and such. I also have lingering issues with the compilers and with the debootstrap process that need to be resolved.

I'll keep posting in this thread the status of progress made against the items discussed above.

Mike
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by chrisw2 » Sat Apr 07, 2012 12:39 pm
Mike,

Another big THANK YOU for all the effort.

Long standing user of debian and I'm sure your approach re the debian community is the right one.
Posts: 106
Joined: Sat Apr 07, 2012 11:22 am
Location: Manchester, UK
by shirro » Sat Apr 07, 2012 1:26 pm
You could have an installer package that downloads the binaries from the foundations github like the flash installer that way people can update their installation without you having to provide a separate non-free repo. The SD card image would need the binaries preinstalled but it is more likely to be made available via RPF or distributors anyway. I think I would prefer a non-free repo because an installer seems more likely to break but it might be a pragmatic way to get started.

It sounds like you are on the right track to me. I hope the Debian guys can be flexible in accommodating a port that has originated outside. Are you a Debian project member? You will probably have to jump through a few hoops there. Given the scope of the task ahead it is well worth having them onside rather than being a fork I think. For one I expect you aren't going to be able to continue calling the distro Debian without someones blessing as it diminishes their trademark. That sort of issue goes away if you get unofficial port status.

Once you get the status of the port sorted infrastructure shouldn't be as much of an issue. Debian already have some stuff and there are a couple of Raspberry Pi distributors who can probably source gear at a pretty good price or may even have some "ex-demo" units available.
Posts: 248
Joined: Tue Jan 24, 2012 4:54 am
by mpthompson » Sun Apr 08, 2012 6:30 pm
Taking some time off over the holiday weekend for family activities so not much going on right now.

I"m learning that Debian wheezy is a moving target and that a handful of new packages are released every few days. This makes it critical I get to a position of doing automated builds of packages ASAP. Fortunately, some of the latest packages have resolved the debootstrap/dpkg problems I described earlier. Also, it looks like gcc-4.7 is now part of wheezy and I"m attempting a build of that now (12+ hour compile). That could resolve some of the compiler issues with gcc-4.6.

That"s it for now.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by mpthompson » Sun Apr 08, 2012 6:54 pm
shirro, I like a non-free repo approach for the proprietary binary pieces as well. I"ll leave that to be solved in the future. With multiple possible solutions it doesn"t worry me too much.

My posting in the main forum didn"t bring out any Debian mentors to help. I"ll start reaching out in the Debian email lists. As you mention, I would really like to see this become an unofficial port of Debian with some community support. A branch is entirely possible if needed, but would be unfortunate.

The delays in the RPi hardware have dampened some enthusiasm for projects like this, but with hardware about to ship (crossing my fingers) hopefully it will be easier to get the attention of people within the Debian community. They can"t let Fedora steal the thunder. :-)
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by Chris.Rowland » Sun Apr 08, 2012 8:32 pm
Could the 10,000 packages be built using some distributed background build process rather like SETI at Home? Each source code file is downloaded and compiled in the background and the resulting output uploaded for use by the next stage in the process.

Or is this just adding more complexity with no benefit?
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm
by shirro » Mon Apr 09, 2012 12:46 am
Chris, the only issue I have with that is trust. I am not a Debian member but I believe the process of becoming a Debian developer is fairly convoluted and involves mentorship, peer review and keysigning and it has a pretty good record.

I might take a take a leap of faith and decide to trust mpthompson to provide software to read my personal email, log into my servers and do my Internet banking. I am not so sure I would trust a process where packages were built with no audit trail by anonymous. You could treat the Pi as an untrusted platform and only use it for games and programming but it is still on peoples internal network behind their firewall.

Long term, I really want packages signed by people who have been checked out face to face by Debian community members and a proper keysigning done with identity checks (passport, government photo id etc).
Posts: 248
Joined: Tue Jan 24, 2012 4:54 am
by mpthompson » Mon Apr 09, 2012 4:10 am
Chris, a distributed approach has been suggested in other threads as well.  However, for all the reasons Shirro mentioned, I don't think it's a realistic approach.

Right now, all the packages I'm building are unsigned as I'm really just trying to reach a critical mass as quickly as possible to be able to do additional testing and create the automated build systems.  Therefore these packages I have now are meant to be disposed of and not really meant for distribution.  However, they will allow the initial builds of the real packages if we ever get to that point.  In an ideal world, the packages will ultimately be signed using the existing Debian gpg keys, but as shirro indicates, who knows what hurtles will have to be jumped over for that to happen.

On another note, I just discovered there is a local Bay Area Debian group that meets up in San Francisco every month or so and there is a meeting this coming Wednesday.  My wife informed me she has a business meeting that night and I'll have to figure how where to park the kids, but hopefully I can free myself to head up to San Francisco and see what interest I can gin for a port of Debian for the Raspberry Pi.  My luck with IRC and email lists has not been all that great so perhaps face-to-face contact might work better.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by mpthompson » Mon Apr 09, 2012 5:57 am
Hmmm. Anyone know much about Linux Mint?  Particularly the LXDE (Debian Edition)?  I wonder if following in the footprints of Linux Mint makes sense if getting the support of Debian proper becomes too much of a burden.

The more I look over the Linux Mint website the more I like what I see.  They also seem to take a very pragmatic approach to proprietary software such as the Binary blobs that have to be distributed with the Raspberry Pi -- something folks in the Debian community can at times be pretty hard nosed about.

I'm curious as to whether Linux Mint rebuilds all their packages from Ubuntu and Debian sources with their own gpg keys, or if they are simply redistributing Ubuntu and Debian packages unchanged and adding a few of their own to give the distribution the "Linux Mint" look and feel.   I'll have to look into this more.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by john.mills » Mon Apr 09, 2012 6:59 am
@mpthompson, I have been following your post for a few weeks and I just have just  registered here to give you some encouragement. Firstly what you are working on is really great and much needed and is a strong foundation to build from in the future. You have proved that the hard float builds provide a tangible benefit to the Raspberry Pi. It will be just awesome to see a Debian build on the desks of hundreds of thousands of awe struck children (both big and small) one day. Please continue with this work you are doing.

I have used Linux Mint in the past and one thing I can say is that they have a great and supportive community and the leaders are very approachable. I would try to speak with Clem (project lead) who I'm sure will be able to answer your questions. Like in lots of forums there has also been talk of the Raspberry Pi over there. If you intended to seek help from them I am sure you would be able to get some advice and knowledgeable feedback on this project. And if you wanted to get help with a desktop edition similar to LXDE then you would be looking in a good place with some very passionate people.

Not to use the old sayings too much but the further you sow your seeds the more of a harvest you will get in return.

I truly wish you the best of luck and once again thank you for the hard work you are putting in to this project.
Posts: 81
Joined: Mon Apr 09, 2012 5:23 am
by mpthompson » Mon Apr 09, 2012 7:24 am
John, thanks for the encouragement.  I tried to engage some of the people on the Linux Mint IRC channels, but didn't get too far.  I guess there is something about me and IRC (perhaps IRC is best left to young :-) ). Anyway, I've just downloaded the Linux Mint Debian Edition and will be looking at it closely to understand where Debian ends and Mint begins. I think Mint provides a possible template to follow so there are certainly ideas to be mined.

Also, I very much like their "rolling release" attitude Mint offers towards the Debian.  I believe that is something that is more friendly to the end user as long as it doesn't get too unstable.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by john.mills » Mon Apr 09, 2012 9:15 am
Hi thanks, I will post some messages on their (Mint) forums and see if I can drum up some support for the project. I totally agree with the rolling distro idea too. This is why I can't see a Fedora release being much use for the Pi. The Fedora releases are too frequent and not supported for long enough on hardware that would be used in a class room environment for many years. Teachers and supprt staff will need longer release windows and more up to date software. This is precisely why something like Debian is perfect for the Pi, or perhaps at a push Arch... although Debian I feel is a much better fit for the audience the Pi is aimed at.

I will see if there is anything I can do (if you want). Are you on a shortlist for a early Pi release. If so you should have it shortly I guess. I know it might be premature but perhaps a Google + / Facebook group might help get some attention?

Best regards,

John
Posts: 81
Joined: Mon Apr 09, 2012 5:23 am
by Chris.Rowland » Mon Apr 09, 2012 9:49 am
I'm sure that the trust issue with a distributed build could be solved by some process such as compiling each part multiple times and checking signatures to remove rogue versions.

But it's clearly not something that can be done without the cooperation of the powers that be and I can see that this will be a problem, especially when starting a new version.

Thank you for for all the work.
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm
by Montala » Mon Apr 09, 2012 2:27 pm
I am afraid to say that I do not understand the majority of what has already been posted above (sorry!) but I am sure that Liz mentioned in one of her replies on the 'Home' page that an updated 'version' of Debian for the Raspberry Pi is due to be released very shortly?
User avatar
Posts: 638
Joined: Mon Mar 05, 2012 11:54 pm
Location: Herefordshire (U.K.)
by abishur » Mon Apr 09, 2012 2:46 pm
Montala said:


I am afraid to say that I do not understand the majority of what has already been posted above (sorry!) but I am sure that Liz mentioned in one of her replies on the 'Home' page that an updated 'version' of Debian for the Raspberry Pi is due to be released very shortly?


I don't think the updated version will take advantage of the hard float these guys have been working on :-)   My understanding is it will take better advantage of the GPU and will have an update for the firmware to resolve some excess noise that was being generated on the HDMI port.
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4313
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by plugwash » Mon Apr 09, 2012 2:51 pm
mpthompson said:


Some thoughts about next steps.

Turning these first few steps into a real Debian port is going to take a serious amount of work.  I've read through a number of the early email threads on the debian-arm email list involving the armhf port and it took an enormous effort to get the that project started.  Much of that effort continues today as armhf problems are still being resolved in various packages.


We still see the occasional new armhf only problem but TBH most of the problems we are seeing are no longer armhf problems per-se.


Of course, an RPi flavored armhf port can leverage 99% of that effort, but even if it is just a task of recompiling and distributing the packages, there are 10,000's of Debian packages that need to built and managed.


mmm


Any end user should be able to start with a basic Debian boot image on an SD card and then customize their system from the myriad of packages supported by Debian.  They should know that what they download will function as advertised


Frankly even with official debian ports you have no real gaurantee that everything you install will function as advertised. Some packages have build time test suites but many don't (and sometimes disabling a failing test with unknown real world applicability is considered a lesser evil than not building the package at all) so really the only way to get problems rooted out is to get users using the port and reporting issues.


This means that in addition to making the binary packages available, the source code also needs to be managed in such a way that it is available for download as well for a term of 3 years from the binaries being available.


The three years requirement only applies in the specific case of distributing software in binary only form with a written offer to supply the source code it is not relevant to online distribution.

For digital download the relavent clause in version 2 of the GPL says

"If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. "

GPLv3 is actually a bit looser in this regard but since there is some software in debian that is GPLv2 only you need to comply with the requirements of GPLv2.

So basically if you are posting binary packages then you need to post the corresponding source packages but you only need to keep the source packages for as long as you keep the binary packages. You do not need to keep a historic archive of source packages.

If you haven't already done so your repositry should be setup to handle both source and binary packages. You should also adopt a versioning convention that makes it clear which packages you have modified (e.g. using +rpi1 in the version numbers of packages you modify)


I've already been told by people associated with Debian that simply pointing URLs at the source code for Debian packages is insufficient to satisfy the GPL licensing terms -- the source needs to be located with the binaries and equally accessible.


Indeed.


I mention this as it does increase the logistics of making packages available.  Also, how to handle the proprietary packages that would come from closed binaries from Broadcom and the RPi foundation would need to be resolved as well in a way consistent with Debian practices.


I would think creating a seperate area in the repositry for those (just as debian itself has main, contrib and non-free areas) would be the way to go.

Likely you would have to coordinate with the foundation to get hardfloat versions of the closed binaries built.


Another aspect to be considered is what hardware infrastructure will be required to compile the 10,000's of Debian packages and keep the packages refreshed as new versions are made available.


Four i.mx53 quickstart boards are enough to pretty much keep up with debian sid though with that number there will be backlogs when big changes come through. Keeping up with wheezy should be easier though I don't have any figures for exactly how much easier.

In addition to the boards running the autobuilders you will almost certainly want a system for manual building and testing of packages that show problems during autobuilding.


I simply don't yet know what would be involved with using existing Debian resources to build such packages and what might be involved with applying to use the resources


(nearly) everything debian uses is donated by someone and it's mostly spoken for. There isn't some big pool of arm boxes sitting around to build another arm variant.


-- this is where a mentor could help answer a lot of questions.  Looking over how other Debian ports began, it seems they usually start with hardware resources outside of Debian


In general autobuilder hardware is donated by those who care about the port.

Afaict in the case of armel and armhf the build hardware was donated by linaro but since broadcom is not a member of linaro and almost everyone else seems to have moved on from armv6 it seems unlikely they would provide financial support for an armv6 variant of armhf.


and as the port achieves success then Debian begins to consider how to fold the process of building packages for the port into the Debian build infrastructure.


I think it's unlikely that this flavour will ever be accepted into the official archive. Firstly because the archive can't handle two sets of packages with the same architecture name (and it is correct to maintain the armhf architecture name because these packages are compatible with the official armhf packages) and secondly because it's really only targeted at one particular (though admittedly very popular) board.

Also, I'll need to start building the packages without cutting some corners such as skipping digital signatures,

The binary packages themselves are not normally signed, only the changes files used to upload them to a repository and the packages files in the repository. It is generally suggested to generate keys explicitly for these purposes (and sign them with your main key) to reduce the risk of compromise to your main key.

Speaking of digital signatures if you have not already done so you should get your key into the web of trust and preferably signed by some debian developers.


lintian processing


Afaict lintian is not normally run as part of the package build process.
Forum Moderator
Forum Moderator
Posts: 2390
Joined: Wed Dec 28, 2011 11:45 pm
by mpthompson » Mon Apr 09, 2012 2:56 pm
john.mills said:


I will see if there is anything I can do (if you want). Are you on a shortlist for a early Pi release. If so you should have it shortly I guess. I know it might be premature but perhaps a Google + / Facebook group might help get some attention?


No, I have no connections to get a Pi early.  Frankly, the lack of a Pi is not really hindering 95% of the things I need to get done.  Real hardware comes into play when it comes to testing and running basic benchmarks that would be useful to help move things along.

I think getting attention is a bit premature right now until a umbrella is found that this project is parked under.  Be it Debian, Linux Mint or some other Debian offshoot group that already has infrastructure in place that would otherwise be a diversion from the goal of getting a proper set of binaries built ASAP for the 10,000s of soon to be RPi owners (crossing my fingers on that one).  Where attention is needed is from people who already are familiar with what it takes to get a Debian distribution actually rolling.  Hopefully we'll be in better standing in that regards soon.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by mpthompson » Mon Apr 09, 2012 3:06 pm
Abishur said:

I don't think the updated version will take advantage of the hard float these guys have been working on :-)   My understanding is it will take better advantage of the GPU and will have an update for the firmware to resolve some excess noise that was being generated on the HDMI port.

I believe this is correct, but we'll know for sure next week.  Any progress to improve the armel release will certainly help an armhf version as well.  Also, I could see efforts to rebuild and distribute specific Debian armel packages recompiled with hard float instructions, but I would be surprised if the Foundation is going that route with all the other things they seem to have on their plate.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by abishur » Mon Apr 09, 2012 3:29 pm
I have to admit that my understanding of this thread is also limited (not clueless, but very limited ;-) ) When it comes to recompiling the packages with hard float instructions, is that as simple a matter as downloading the source code and compiling it on an distribution designed to take advantage of hard floats, or are there some special switches you need to use when you do this?
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4313
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by mpthompson » Mon Apr 09, 2012 3:55 pm
Abishur said:


When it comes to recompiling the packages with hard float instructions, is that as simple a matter as downloading the source code and compiling it on an distribution designed to take advantage of hard floats, or are there some special switches you need to use when you do this?


Yes, in theory, it is a simple as downloading the packages and recompiling them.  The only actual package I've changed is the GCC package where I had to adjust the compiler options used to build GCC so that the default code produced by the compiler is for the ARMv6+VFP rather than ARMv7+VFPv3-D16+Thump2.  And this is all done in the debian/rules file so I'm really not even changing GCC source code in that case.

However, in practice, things are a bit trickier.  For instance, I did run into some internal compiler errors where I had to figure out how to coax the compiler to use different optimization options when building the package.  This isn't always a clear cut thing to do in Debian packages.  I basically have to examine the debian/rules and associated files to figure out which magic settings will adjust the compiler as needed.  This can sometimes take a few minutes, or hours in the case of the very complex packages.  I'm learning more and getting better/faster at doing this.

Another big problem is that a handful of packages statically link to other libraries.  Because I'm using a standard armhf build system, this means that anytime static linking occurs the package becomes tainted with ARMv7 code that will not run on the RPi. When this happens, I need to track down which dependent library has been linked to which again could mean a lot of time pouring over build logs to figure where the linking occurred.  Once found, I then have to download the dependent library, build it, and then restart the build of the original package up again.  For instance, I have the python package on hold because it's doing such linking somewhere and I haven't tracked it down yet.  Fortunately, 95% or more of the packages don't do static linking and this problem will become less serious as a larger portion of the packages get built for ARMv6.

The other significant issue I'm running into is that Debian wheezy is a moving target.  For instance, it took me about one week to manually rebuild the minimal install and build-essential packages, but in that time about a dozen packages have been upgraded by wheezy.  I was getting strange dependency issues when using debootstrap (the tool I use to create a Debian filesystems from my packages) that I spent hours chasing down, that in the end, were simply fixed when I updated the packages to reflect the changes in wheezy.

However, the bottom line, the packages are downloaded and simply recompiled.  When I do run into issues, I'm learning enough to better handle the problems than I was just a week or two ago.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by pepedog » Mon Apr 09, 2012 4:12 pm
I love thump2
Posts: 984
Joined: Fri Oct 07, 2011 9:55 am