Hi Iulian and all
thanks for you work. I'm a beginner with t2 in the sense of contribution. I have some questions for my understanding. > 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. ? Could it be that the tools in the t2-9.0minimal has different version in the sense, that the interaction between them is instable? > issue 2: udev is a big mess and strange. ? : no questions > 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. ? What is the problem to update this version directly in t2-9.0minimal? Perhaps I didn't understand the philosophy of the process between stable version. > issue4: updated packages break more than fix I have the same experience. One problem was the different library-locations /usr/lib versus /usr/local/lib. But I think it was my fault (perhaps direct compiling versus ./build-emerg....) > 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 ? Shall we "downgrading" package version to get a more stable system? Thanks for the answers. Regards Dan At Tue, 10 Mar 2015 11:28:11 +1100, Iulian Demetrescu wrote: > > [1 <multipart/alternative (7bit)>] > [1.1 <text/plain; UTF-8 (7bit)>] > 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 > [1.2 <text/html; UTF-8 (quoted-printable)>] > > [2 footer <text/plain; us-ascii (8bit)>] > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [email protected] with a subject of: unsubscribe t2 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
