Hi Rene, i am sorry if my frustration was seeping through every word i wrote and i also appreciate updates from all of the contributors. I will try to post my updates also when i manage to get my system right and i promise i will write an updated tutorial... Keep up the good work.
regards, JD On Tue, Mar 10, 2015 at 7:44 PM, René Rebe <[email protected]> wrote: > Hi Iulian, > > thank you for your detailed, in-depth email. > > Some of the latest external contributions may have been a bit massive. But > I nonetheless appreciate such updates, as I can obviously not gather all > kinds of new packages, nor update all areas that I do not use personally. > > I recently built minimal-xorg ISOs for many architectures and will do so > again soon, and obviously fix any problems I encounter in my daily use. > > Any kind of patches highly appreciated - I will go thru your email soon > and try to reproduce and fix things, too. > > René > > On Mar 10, 2015, at 1:28, Iulian Demetrescu <[email protected]> > wrote: > > Hi all, > i am struggling lately to build again a usable T2 with Xorg and xfce based > on the latest t2-9.0 minimal image only to discover that the build became > harder and harder to maintain and build. > > Issue 1: in order to fix packages, sometimes, you have to keep source on > error and try to fix the issue there and then create the patches to fix the > main stream. On 8.0 this option worked perfectly. Now i cannot compile > anymore and get a segmentation fault whenever i try to rebuild a broken > package. Steps to reproduce: > a. download and install t2-90.minimal ( tested on x86 and x86_64) > b. download via SVN the t2 SDE > c. configure a t2 build for x86 with minimal packages and iso installation > disk, do not forget to add keep src on error, ccache, print build progress > on screen,etc > d. download the required packages > e. start build > At this stage it is more likely that one package will fail at some time. > Break the build process (CTRL+C), go to the package failed source folder > and: > f: execute ./debug.sh ( this will put you presumably in the same > environment as the build) > g: execute as instructed in the manual $MAKE $MAKEARGS > h: observe the segmentation fault message > How to fix this? > > > issue 2: udev is a big mess and strange. > The implementation of udev in 8.0 was working. The current one does not. I > cannot test in a virtual machine ( t2 9.0 currently cannot install on > VirtualBox) so i use real hardware for build and test. At boot virtual > consoles get messed up all the time. sometimes you miss VC1 3 and 6 and > other times you miss 2 and 4 ( the links for agetty not the /dev/ttyX) so > that console is unusable. tried fixing it a couple of times but gave up. > Also because of this, we get a X respawning too fast disabled for x minutes > message now and then on the console. Also a lot of links that are supposed > to be created ad boot by udev are not linking. Also if you ever try to put > the console in anything else other than 80x25 ( 640x480 default terminal > mode) and try to use a higher console resolution you will never be able to > do that. 8.0 had that in configured corectly. 9.0 does not. Even if the > Penguins appear ( a sign that FB was initialized successfuly) the boot > never finishes( on screen) and you have no login prompt on any of the VCs > you try to use. > How to fix this? > > issue3: build still does not take into consideration old and already known > issues > I remember clearly, when i wrote my first guide for building t2 from > scratch ( and published it later on with the permission and help of Rene) i > outlined that after install, in order to have a correct build environment, > you still need to build, perl, m4, python, autoconf,etc. The issue persists > on the current 9.0 minimal. I still have to build at least m4, python and > others just to have a stable build environment. > Also i remember once arguing when building GCC ( for x86 and x86_64) that > i get an error about unknown memory model for jumps. To fix this you have > to use the -disable-sjlj-exceptions in configure params for GCC. No way of > getting around this exception and, to be honest, it is buried too deep > inside GCC internals to try to figure out why it's not detecting the > correct memory model and build correct jump code.So for now, on x86 at > least, you have to use the disable switch to build a working compiler. > Again i remember e-mailing this to the group but no response was received . > > issue4: updated packages break more than fix > i really know we are all in a rush to get the distribution up to a point ( > a more recent one) but i think we do this at the expense of killing a lot > of hours in fixing stuff that breaks other stuff. In this way we end up > with something that is anything but stable. I know i am just winging but > when i took t2 8.0 it took me 4 weeks to actually learn it, build a > workable distribution and improve it slowly but steadily. Right now i am at > the 7-nth week of fighting to build the basic X without any bells or > whistles. An example of course.... mesa package. it was updated i think > last week to a new version. But the new version introduced new dependencies > (mako ) which....do not build correctly because Python is lacking other > dependencies that are not by default selected if you enable them. Also > basic packages which should build correctly and without issues are becoming > a nightmare. apr, intltool, freeglut and the list is constantly growing > cannot be built anymore in a correct fashion. apr fails for unknown > reasons. if you try to build it several times, it will build correctly > because there is no fault in there. The build environment either locks > files, or does not give permission to use /usr/bin/install or simply say > that some file is busy... busy doing what???. Freeglut fails in building a > stupid example because it has a DSO error. To build that example, > apparently an extra -lGL is required to be added but because there is no > way currently to build the package in fix mode i cannot fix the thing.... > > > Finally i admit my limitations. I know how to fix some stuff but for some > others i require more experienced assistance. I also know that Rene is most > probably overwhelmed with the amount of work he has to do in maintaining > this mammoth T2 became. But i would still like to have something solid and > workable before we adventure in upgrading and updating stuff. We need a > solid base from which to start on. I would really like to see all of us > concentrating first on fixing the current distribution to a stable way and > later on bringing new stuff in slowly. I understand the need to be more up > to date but let's not do that at the expense of destabilizing what we have. > We do not benefit from a very large pool of users and if we make the things > difficult they will desert the project and it will become harder and harder > to go. > > Regards, > JD > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [email protected] with a subject of: unsubscribe t2 > > > -- > ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > http://exactcode.com | http://exactscan.com | http://ocrkit.com | > http://t2-project.org | http://rene.rebe.de > >
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
