"tpup" T2 Woof build

I'm going to have a go at adding T2 compatible-distro to Woof. Doing a T2 compile right now...

One thing that stopped me before is that T2 builds Xorg in /usr/X11R7, whereas Woof expects it to be in /usr (which is in accordance with all other modern distros). However, building "ppup" from Puppy 4.1.2 PET packages I figured out a workaround for this, a script that creates appropriate symlinks.

This puts T2 back on the agenda.

The remaining main stumbling block for T2 is that they don't seem to be bothered anymore with doing a release version, it's a "rolling release" model of source packages. Therefore, if I wanted to build a Puppy5 based on T2, then I would need the sources to remain available, which they won't on the T2 repos. So we would have to host them.

However, there is a way out. Back when there were questions about Puppy perhaps not meeting GPL requirements, someone reported to the Free Software Foundation that we were not providing the source packages. A lawyer from the FSF contacted me, and we sorted it out. There was one interesting bit of information that I got from the lawyer -- if a distro is unable to host the source packages, they are allowed to provide them on media that is provided at cost-price. That is, CD or DVD. "Cost price" I presume can include a bit for the time involved in copying and posting. This is what D**n Small Linux does.

I have a fondness for T2, it enables us to create the leanest and meanest Puppy, with absolute minimum dependencies. For those who don't know, Puppy 4.x was built from T2, which was very successful.


Posted on 5 Apr 2009, 8:56


Comments:

Posted on 5 Apr 2009, 9:20 by kirk
T2
Barry,

I was thinking of doing that again too. I did a T2 build back in November, when Xorg 7.4 first came out. Xorg 7.4 wasn't working too well then, seems to be better now. I was waiting to see if the T2 folks where going to update mesa to 7.4. You'll probably have to use dbus. I used an older version of libgsf (gnome2), the latest version requires libbonono which required dbus.





Posted on 5 Apr 2009, 9:26 by kirk
T2
Also, The gcc package T2 builds is still broke.



Posted on 5 Apr 2009, 10:14 by BarryK
re: libgsf
kirk,
Thanks for that information. I'm doing this T2 build "properly", with a target/puppy5 and various pkg_*.conf files to modify the builds of various packages. The intention is for anyone else to be able to grab the T2-core package all setup for puppy5 and it will just work.

I took a look in the libgsf 1.14.11 source package, and it seems that bonobo and gnome-vfs dependency can be turned off, so I've created target/puppy5/pkg_libgsf.conf with this in it:

# --- T2-COPYRIGHT-NOTE-BEGIN ---

# This copyright note is auto-generated by ./scripts/Create-CopyPatch.
#
# T2 SDE: target/puppy5/pkg_libgsf.conf
# Copyright (C) 2004 - 2007 The T2 SDE Project
# Copyright (C) 1998 - 2004 ROCK Linux Project
#
# More information can be found in the files COPYING and README.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License. A copy of the
# GNU General Public License can be found in the file COPYING.
# --- T2-COPYRIGHT-NOTE-END ---

# this file created by BK

var_append confopt ' ' '--disable-schemas-install --without-python --with-bz2 --with-gio --without-gnome-vfs --without-bonobo'


I have configured T2 with dbus, bonobo and gconf not selected.



Posted on 5 Apr 2009, 13:25 by ttuuxxx
t2
Hi Barry, Like I've been Saying, as long as FF3 works like in Dpup, I'm ready to to shoot my full support at it. Also why couldn't we host the sources? Most people wouldn't be downloading the sources anyways, it would me more for storage, Couldn't there just be a all in one directory or even make a .sfs file with them all in it and make it 'on request' for the sources link to the sfs file. Or heck put a 'Buy it now' link on your desktop for the source cd.

I don't know I just want some sort of base to start building on.
T2,Dpup,Spup,Upup so many options, we need to group together and decide what base, Or better yet Barry you've been the leader for so long, you decide. I just want to move on with the next puppy 5.0
ttuuxxx




Posted on 5 Apr 2009, 15:30 by BarryK
Common base
Yeah, I've been acutely aware of the need for this. The main problem is, when I have wanted to compile a package, I have asked myself which one will I use, dpup, spup, etc? I have already experienced the problem of compiling in upup and the application did not work in dpup.

Another thing to think about is whether we really need to hang onto another distro. Having access to all the Ubuntu repos is nice, with a reasonable assurance that the packages once installed will work.

I decided to bring T2 back into the equation. I'll do a Woof-T2 build and we'll take a look at it.

It may turn out that we can choose T2 for Puppy5, but still have a good success rate with installing say Ubuntu packages, just like we have a good success rate with Slackware 12.2 packages in Puppy4. Maybe we could even slog through say the Ubuntu repos testing the packages in a T2-woof-puppy and make up a list of verified pkgs and only offer those in PPM -- so we be able to offer more pkgs than just whats in the PET repos.



Posted on 5 Apr 2009, 17:38 by ttuuxxx
t2
Hi Barry

I really do Like Dpup, The speed of it is really nice, Maybe its using some of my pc resources that earlier puppies weren't, Its just really snappy, my pc is a dual core 64bit am2 with sata2 hard drives, with 4gigs ddr2-800MHz memory. Puppy alway ran fine well other than with Pmusic which slows it down to a turtle speed, But with Dpup it really flies, I don't know if its the kernel, or that it comes with mesa, what ever it is, I would say its 2-3 times faster than it was with 4 series.

Really if we had a Dpup base without any debian packages capabilities and we went back to compiling them for the repo that would be ideal, I never like the added size of the extra libraries that Ubuntu & Debian uses. Just to having a regular package manager that updates with a click, is perfect, That way we stay independent and we could add to the repo as we go, It would be nice if we had a testing area in the forum, where we submit packages, and people test them. and if all goes well then they move to the repo.
Then when we update the package manager, the new packages will be listed.
ttuuxxx




Posted on 5 Apr 2009, 24:41 by happypuppy
ttuuxxx & Dpup
ttuuxxx: It's the kernel.It includes updated / working drivers for your hardware (videocard,serial ATA,memory controller,etc.)

I've experienced 10x faster 2D performance with Slackpup (spup). Extremely snappy. since it includes updated drivers for modern ATI cards.

Dpup and Upup feel sluggish.Besides the lack of working ATI drivers for RadeonX/RadeonHD cards,there's more CPU overhead with Upup and Dpup.



Posted on 6 Apr 2009, 8:32 by Raffy
Git, Woof and Org needs
Development of packages "native" to Puppy will sync well with Git.

At the moment, Git and Woof are being handled by separate guys (the best guys in our community, of course :). It's just a matter of time before things are really made to sync.

By that time, the question will be, "What then", at least on the developer side of things. From what I've experienced with a Taiwan thin client company benefited by Puppy (minipup), customer orgs come to them with a list of protocol to be supported, mostly proprietary. (The company owner asked me for help but...)

Individual home enthusiasts cannot do it because the proprietary systems are not available to them. Some access to a laboratory is essential.

Whatever, am just thinking aloud and pointing out a need. Good Linux is needed in the workplace, but it has to enter through a door. And the door seems to have the big letter "P" on it. :)



Posted on 6 Apr 2009, 10:06 by dogone
Being sure of what works
I too am concerned that activity in supported repos could cause PPM grief. It's something Puppy has no control over. I see a couple of options. PPM package lists could be maintained centrally - items added only when verified. PPM would consult this official list rather than distro lists. It might also be wise to take a tip from Arch and establish "testing" and "core" package lists. Both would be avalable to PPM. Entries still in "test" would be clearly flagged but easily available to all for testing/verification, ultimately moving them to the "core" list.


Posted on 6 Apr 2009, 10:29 by dogone
Being sure of what works
I too am concerned that activity in supported repos could cause PPM grief. It's something Puppy has no control over. I see a couple of options. PPM package lists could be maintained centrally - items added only when verified. PPM would consult this official list rather than distro lists. It might also be wise to take a tip from Arch and establish "testing" and "core" package lists. Both would be avalable to PPM. Entries still in "test" would be clearly flagged but easily available to all for testing/verification, ultimately moving them to the "core" list.


Posted on 6 Apr 2009, 11:12 by dogone
Being sure of what works
I too am concerned that activity in supported repos could cause PPM grief. It's something Puppy has no control over. I see a couple of options. PPM package lists could be maintained centrally - items added only when verified. PPM would consult this official list rather than distro lists. It might also be wise to take a tip from Arch and establish "testing" and "core" package lists. Both would be avalable to PPM. Entries still in "test" would be clearly flagged but easily available to all for testing/verification, ultimately moving them to the "core" list.


Posted on 6 Apr 2009, 11:16 by dogone
double post
Thou shalt have but one browser window open while addressing his Majesty.

Lock him up and throw away the link!