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
