Newmake Queries

[jubbler]

Hi guys, just a few queries:

using newmake on Suse (under VM) I can build the images fine (and thanks for fixing the dhcp Barf - I think pt-1 relayed my query at the time), including jffs2 and yadd. What I cant seem to do is remake things very well. I was told (probably by old make users) to delete the ./deps/neutrino file to rebuild say a new neutrino but it just doesn't exist.

I'd therefore be grateful for an idiots guide as to how to remake something against an updated CVS tree.

Also, what is the sequence when patches are applied ? i.e. I apply a diff with patch -p1 < diffname.diff , that all goes fine and then I get a CVS update..., so is the patch then overwritten so I need to do another patch or is it retained and I dont ?

Many thanks and Regards.

[PT-1]

After checkout:
set CVS_RSH=ssh && cvs -d anoncvs@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox -z3 up -P .

Go to the diff directory
patch -p0 < xxx.diff

Then:

Code:
./autogen.sh


From here: http://forum.tuxbox-cvs.sourceforge.net ... hp?t=40516

[jubbler]

Yeah, I understood how to update the CVS, just not how to remake things and it what sequence any patching needs doing or redoing after a cvs update.

Cheers.

[Barf]

I'd therefore be grateful for an idiots guide as to how to remake something against an updated CVS tree.

A guide for the reasonably sane is found here. I am not into writing idiot guides ("HOWTO"). Building tuxbox images can never be simpler than, say, compiling a Linux kernel.

I was told (probably by old make users) to delete the ./deps/neutrino file to rebuild say a new neutrino but it just doesn't exist.

This disgusting klude has been eliminated, and is no longer needed.

Also, what is the sequence when patches are applied ? i.e. I apply a diff with patch -p1 < diffname.diff , that all goes fine and then I get a CVS update..., so is the patch then overwritten so I need to do another patch or is it retained and I dont ?

There is not a canonical answer to that question!! Read the instructions that comes with (ideally...) each patch. Use your brain. Find out how CVS works. (In general a CVS update does not eradicate an applied patch)

[jubbler]

Thanks for answer and yes I had read the guide. I guess I should have been a bit clearer in my question so lets say I (new)make some images and yadd, I then come back in 2 weeks time and update the CVS and wish to remake the images and yadd. According to the guide, there is no further ./autogen and ./configure to do - I guess this is the query really - do I just run the (new)make command again which generated the images and yadd 2 weeks ago and do nothing else ? Thus it will automatically overwrite the images and yadd if the source has changed in those 2 weeks ?

Thanks.

[Barf]

Ideally, yes. (It warms my heart everytime someone get this right! ) With yadds, this to the best of my knowledge, this also works in practice (possibly with some minor glitches, none comes to my mind right now). When it comes to images, the dependencies are not really complete (working on it). Remove, say, $(flashprefix)/root-neutrino to force the neutrino part to be new installed. (Or use make flash-semiclean).

[jubbler]

Cheers Barf, thats exactly what I was looking for !

I tried the remake thing after I heard the dhcp fix was in the CVS but it did not remake the images so I'm guessing my mistake was not deleting the neutrino_root (and presumably, the image itself ?).

Will try it again.

[jubbler]

Oh, and 1 last query..., can I use newmake to remake just a single file, if so how and where does it put it ? (for example if I patch neutrino for the left/right scrolling and JUST want a new neutrino....?...

Cheers.

[Barf]

I would not say it was a "mistake" not to delete root-neutrino, I'd say that there is still an imperfection, in that the root-neutrino-jffs2 directory "in fact" depends on thousands of files, and the target does not depend (in the sense of make) on these. (One day, I may get this to work. However, that day will not be April 12.) (Ironically enough, most critisism on newmake have been around the theme "rebuilds too much"...)

To your example, after pathing neutrino, "make neutrino" rebuilds the neutrino part for yadd. Of course, a make target depending on the make target "neutrino" also will do. Like "make yadd-neutrino".

"make flash-neutrino" will say that there is nothing to do, for the reason outlined above. (It amounts to the file $(flashtarget)/root-neutrino). Manually nuking root-neutrino will do.

[jubbler]

Got it ! All clear now, and thanks.

Good luck with getting it to work as you want it to but seems a giant step forward as it is, once you know the little "tricks" like this, then its easy to manage.

Cheers.

[jubbler]

Just an update and semiclean did the trick for me. Now all I need to do is sort out why I get "bad magic bytes" on half of the x2 images it makes ! I dont see it on X1 and it seems to vary if I use (say) Ubuntu or Suse so I assume its a product of the tool versions used somewhere in the equation.

I was wondering if it gets rid of the "bad" by adding the jffs2.flfsx2+root-neutrino.jffs2 together (as a binary DOS file addition - the addition itself works and the image is flashable) or whether the end result of this (binary-DOS) addition is exactly the same as the "bad" file it makes anyway ?

Cheers.

[Barf]

I was wondering if it gets rid of the "bad" by adding the jffs2.flfsx2+root-neutrino.jffs2 together (as a binary DOS file addition - the addition itself works and the image is flashable) or whether the end result of this (binary-DOS) addition is exactly the same as the "bad" file it makes anyway ?

The correct term is "concatenation", and it has nothing to do with an ancient Microsoft product. The concatenation does not create the "bad magic bytes, they reside in the components. Does this answer your question?

[jubbler]

No, I understood the bad bytes reside in the files and I thought the concatenation might have got rid of it as I was misled by the fact that the flfs and root images are not tagged with the "bad" flag, thus I had assumed wrongly that they were not "bad". Therefore, I further thought that the "bad" might have been induced as a product of 2 "goods". But no, I did concatenate and found by binary file compare that the file is identical.

So firstly, could I add a recommendation that perhaps the root and/or flfs image are also tagged with the "bad" to avoid this confusion ? (Just a thought) and my further question as a result of this is: in which part does the "bad" reside ? If its only in the flfs then an easy workaround would be to concatenate the root (assuming no "bad" in that one) with a known good flfs thus producing a good+good=good combination ?

Cheers.

[jubbler]

I know that Barf suggested that the ftp (initial login lands at /root not /) "issue" is not an issue but I was wondering if we could debate this a little

I agree entirely that a linux-purist view is that landing at the users' home folder is standard behaviour. However, as Tux is not a multi-user system and this convention has been changed in (old) Make to land logins to ftp and telnet at the / folder would it therefore be a logical step for this to be the tuxbox preference ?

Cheers.

[Barf]

So firstly, could I add a recommendation that perhaps the root and/or flfs image are also tagged with the "bad" to avoid this confusion ? (Just a thought) and my further question as a result of this is: in which part does the "bad" reside ? If its only in the flfs then an easy workaround would be to concatenate the root (assuming no "bad" in that one) with a known good flfs thus producing a good+good=good combination ?

I think I will add a few lines to the "What about bad magic bytes"-section in my article. Otherwise, when shit happens, a human have to use his brain, automation is not the way to go.

this convention has been changed in (old) Make to land logins to ftp and telnet at the / folder

No. (Possibly in some images, but that is another issue.) (/etc/passwd in CVS has not been changed for three years.) As a stated in a message to PT-1, newmake does not have own versions of /etc/passwd, (neither telnet nor ftp). You can use root-local.sh to change or replace /etc/passwd.

[Barf]

Having said that, I have to remark that /root as home directory for root is the worst possible choice... I just saw that jtg uses /var.

[jubbler]

What about having / as the default choice ? Its easy to "fix" with a "ln -sf / /root" but just a bit of an "annoyance".

[jubbler]

@Barf

Possiblly one issue solved but now I've got a new one

Barf's pages indicate that unless the dhcp server is stopped then the network for a Yadd running Neutrino is broken...., well this might need a slight revision as if you set up a DNS server and Gateway in the dhcpd.conf file, and have Neutrino networking set to DHCP, then it seems to work fine

The new issue is that Newmake makes a yadd with LCARS intact (which is good) but there are no make targets for an image version of LCARS (which is unfortunate). I'm doing a bit of work on a resurrected LCARS which may lead to being able to relaunch a slightly improved version, therefore would it possible to (a) have LCARS make targets in Newmake and (b) what would be the route to get any changes to the sources resulting from this work, reflected (uploaded ?) into the CVS ?

Cheers.

[Barf]

Barf's pages indicate that unless the dhcp server is stopped then the network for a Yadd running Neutrino is broken....,

No, just that running dhcp may force a dBox to boot from a server even though this may not always be desirable.

The new issue is that Newmake makes a yadd with LCARS intact (which is good) but there are no make targets for an image version of LCARS (which is unfortunate). I'm doing a bit of work on a resurrected LCARS which may lead to being able to relaunch a slightly improved version, therefore would it possible to (a) have LCARS make targets in Newmake and (b) what would be the route to get any changes to the sources resulting from this work, reflected (uploaded ?) into the CVS ?

Super. Please then try to get the lcars Makefile[.am] to work properly using the install target, i.e., so that it can be installed in CDK with "make install" and in flash images with a command like "make install prefix=$(flashprefix)/lcars". The reason why I commented it out in make/lcars.mk was that I the code was old and not tested (?) for the last few years. (Normally I consider checking in commented-out code nothing but a sign of bad self-confidence )