usr_devx - too much stripping ?

Please post any bugs you have found
Message
Author
User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#21 Post by MU »

I have some problems, but actually I am quite satisfied with compiling apps on Puppy.
Compiling on Linux in general is a pain due to the dependency-hell, incompatible GCC-releases and dependeny on certain releases of autoconf and automake.
But however it is better than in Windows ;)
"Big" Linuxsystems cause even more problems - the more programs, the more dependencies.

But of course some things might be improved.

I tried to compile some Gnome-libs, and get:

Code: Select all

# ./dpupmaker.sh /mnt/sda7/_dotpupsource/gnome-libs-1.4.2/oaf-0.3.0.tar.gz     
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... Illegal instruction
Illegal instruction
configure: error: can not guess host type; you must specify one
dpupmaker.sh: Error: Unable to configure application oaf-0.3.0
Tried already several versions, and ./configure --options , but no success yet.
Time to go to bed...
Mark

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#22 Post by MU »

I never liked EMail-lists, thats why I founded my own forum.
Doing online-search in EMail-archives is a pain, I really prefer a forum for that.

Mark

costal martignier
Posts: 198
Joined: Sat 28 Jan 2006, 15:55

#23 Post by costal martignier »

a good mailinglist archive is exportable to the mbox format, then you can use your favorit mailapp to browse and search LOCAL the whole mailbox....

also mailinglists are normaly used in mailapps and not online

regrads
costal

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#24 Post by BarryK »

MU wrote:I have some problems, but actually I am quite satisfied with compiling apps on Puppy.
Compiling on Linux in general is a pain due to the dependency-hell, incompatible GCC-releases and dependeny on certain releases of autoconf and automake.
But however it is better than in Windows ;)
"Big" Linuxsystems cause even more problems - the more programs, the more dependencies.

But of course some things might be improved.

I tried to compile some Gnome-libs, and get:

Code: Select all

# ./dpupmaker.sh /mnt/sda7/_dotpupsource/gnome-libs-1.4.2/oaf-0.3.0.tar.gz     
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... Illegal instruction
Illegal instruction
configure: error: can not guess host type; you must specify one
dpupmaker.sh: Error: Unable to configure application oaf-0.3.0
Tried already several versions, and ./configure --options , but no success yet.
Time to go to bed...
Mark
Have you tried --build=i486-pc-linux-gnu?
Or rather, you should run ./configure --help and see whether --build or
--host needs to be specified.
The one with "(guessed)" alongside it is the one to use.

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#25 Post by MU »

no, without "pc"
--build=i586-linux-gnu --host=i586-linux-gnu --target=i586-linux-gnu

In some cases that seems to work :)
But in others not :roll:

But currently I am satisfied how far I got.
I think I could compile allmost all dependencies and libs of gnome1 , just vfs is resistent.
Will try it tomorrow.

Thanks, Mark

cncuser_

progress - puppy sourcecompile

#26 Post by cncuser_ »

Hi,

I am sorry for the delay. had some other stuff todo lately.

i setup 2 mailinglists for this topic: http://lists.hinternet.at
PuppyFromSource Puppy from Source - User Mailinglist
PuppyFromSource-Dev Puppy from Source - Developer Mailinglist


regarding the progress of the LFS install im done with
"5.31. Stripping" but havent done much the last week.
i may look at it the next days again if i have some sparetime.

im not that shure if this is really a good idea anymore.

the problem with doing it from scratch is that we need maintainers
for every piece of software. they must watch the devopment of the
software and add securitypatches. much to do!

maybe it would be better to use sourcepackes of a widespread
distribution? and just modify(patch) the buildscripts for puppystyle.
(stripping, compression of binaries, busybox init..to name a few)
thatway updating to a securityfixed package could be as
easy as (debian system as example):
running apt-get update, parse the output to see if there is
something to update ? -> yes
get the sourcepackage
compile it
make puppypackage
validate
put online for distribution

looks like the more reallistc way for puppyfromscratch.

i guess im going to finish LFS anyways. even if i dont puppackage
it up when im done it cant be bad, every linuxuser should have
done this at least once in his life ;)

well, the list is open for registration. please dump your suggestions
ideas. worldpeacestatements or whatever else is in any way related
to sexual reproduction of puppys at the lists.

cu
cncuser

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

Re: progress - puppy sourcecompile

#27 Post by jmarsden »

cncuser_ wrote:i setup 2 mailinglists for this topic: http://lists.hinternet.at
PuppyFromSource Puppy from Source - User Mailinglist
PuppyFromSource-Dev Puppy from Source - Developer Mailinglist
Apparently we are working at almost exactly the same speed...!?

puppy-devel@freelists.org is now set up. See http://www.freelists.org/list/puppy-devel or send email to puppy-devel-request@freelists.org with the word "subscribe" in the subject to subscribe to it.

Note, I have set up puppy-devel as a general developers list for anyone doing "from source" development in Puppy, though it is likely to focus on SelfHostingPuppy. But if you are an application developer building apps in Puppy from source, you are very much welcome on puppy-devel, whether or not you have any interest in SelfHostingPuppy.
the problem with doing it from scratch is that we need maintainers for every piece of software. they must watch the devopment of the software and add securitypatches.
That's part of being an independent distribution, it seems to me. Puppy's small size keeps it more manageable (300+ packages) than larger distributions with thousands of packages. Thirty or so developers maintaining an average of ten packages each is all it will take, and some packages are very small and simple indeed.

Jonathan
Last edited by jmarsden on Mon 06 Feb 2006, 17:10, edited 1 time in total.

costal martignier
Posts: 198
Joined: Sat 28 Jan 2006, 15:55

#28 Post by costal martignier »

i would love to see this real puppy development-environment/self-compiling puppy, but i think without barry and/or the other regulars on board of this project, this is the same as creating a new distribution (puppy fork)

but i think this is not what "we" want...

best rgerads
costal

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#29 Post by jmarsden »

costal martignier wrote:i would love to see this real puppy development-environment/self-compiling puppy, but i think without barry and/or the other regulars on board of this project, this is the same as creating a new distribution (puppy fork)
Then we need to figure out how to keep Barry and the regulars on board :-)

Barry has already indicated his interest in seeing a replacement usr_devx.sfs that is more conventionally created, so from my perspective, we'll start with that. A set of trusted developer tools is necessary anyway if development is to be done under Puppy, and I don't like trusting tools compiled who-knows-where by some-unknown-person when I can recompile a toolset myself. Hence, M1 of the milestones for SelfHostingPuppy is just such a toolset.

This is likely to be a slow and at times frustrating project. But that doesn't mean it is completely impossible.

Jonathan

Guest

#30 Post by Guest »

i wrote:
>>the problem with doing it from scratch is that we need maintainers for every
>> piece of software. they must watch the devopment of the software and add
>> securitypatches.
jmarsden wrote:
>That's part of being an independent distribution, it seems to me. Puppy's
>small size keeps it more manageable (300+ packages) than larger
>distributions with thousands of packages. Thirty or so developers
>maintaining an average of ten packages each is all it will take, and some
>packages are very small and simple indeed.

i really dont see how this could come true :( i think that if we dont
use a "stronger base" its very likley that this will never happen :(
even if it where just 300 packages. i dont even see enough people
here for maintaining the gnubase(glibc,binutils,gcc..)

using the source packages of other distributions wouldnt be that
dependent. for we decide what to "port/take" into puppy and what not.


a completly different thing:
has any of you had any datamisscorruption due to unionfs ?
ive had severall problems with it now. it all ends up in a
directory not deleteable or writeable anymore. an fsck fixes
somethings. i must say that the unions dont get unmounted
correctly very often due to systemhangs and resets (still dont
have a working Xserver in my puppy devel environment)


bye
cncuser

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#31 Post by jmarsden »

jmarsden wrote:That's part of being an independent distribution, it seems to me. Puppy's small size keeps it more manageable (300+ packages) than larger distributions with thousands of packages. Thirty or so developers maintaining an average of ten packages each is all it will take, and some packages are very small and simple indeed.
Guest (really cncuser) wrote:i really dont see how this could come true :( i think that if we dont use a "stronger base" its very likley that this will never happen :( even if it where just 300 packages. i dont even see enough people here for maintaining the gnubase(glibc,binutils,gcc..)
How many security patches for binutils and gcc have been released in the last couple of years that were significant enough to force major distributions to issue updated packages between releases? How many for for coreutils or diffutils or bash or find for that matter? I suspect the answer is either "none" or "very few"! Which means that the burden of maintaining Puppy source packages for those kinds of things is likely to be fairly low. System libs like glibc are, of course, going to take more work to maintain. One really 'interesting' one to maintain from a security perspective may be Xorg, since AFAIK it is not designed to be run as root, but Puppy runs it as root... but let's not discuss that right now!

Right now, Puppy uses fairly old versions of many packages and has no established security update team, nor a mechanism for distributing such updates to users. It seems to me that using more current sources and then working towards having assigned package maintainers is a step forward for Puppy. We won't know whether it is doable until we try it. Even if we end up with only 5 people doing all the package maintenance, that is probably still a useful improvement in scalability and long term viability compared to Barry doing everything himself!

Jonathan

flavour
Posts: 125
Joined: Thu 08 Sep 2005, 20:26
Location: Bicester, UK

#32 Post by flavour »

Puppy users don't generally need to worry about security updates as much as many other distros for 2 reasons:
(1) not often multi-user
- hence locally-exploitable holes are (almost) irrelevant
(2) not often a public-facing server
- hence remote attackers have nothing to target

The 1 area that needs attention is the apps that access remote servers
- particularly browsers (e.g. Firefox when that's present) & e-mail clients.

Of course, it doesn't hurt to keep other stuff refreshed as/when possible...but mostly that should be the job of the 3rd-party packagers, such as SSHd (which is critical for my own version...)

F

flavour
Posts: 125
Joined: Thu 08 Sep 2005, 20:26
Location: Bicester, UK

#33 Post by flavour »

Puppy users don't generally need to worry about security updates as much as many other distros for 2 reasons:
(1) not often multi-user
- hence locally-exploitable holes are (almost) irrelevant
(2) not often a public-facing server
- hence remote attackers have nothing to target

The 1 area that needs attention is the apps that access remote servers
- particularly browsers (e.g. Firefox when that's present) & e-mail clients.

Of course, it doesn't hurt to keep other stuff refreshed as/when possible...but mostly that should be the job of the 3rd-party packagers, such as SSHd (which is critical for my own version...)

F

cncuser...

#34 Post by cncuser... »

jmarsden wrote:
>Right now, Puppy uses fairly old versions of many packages and has no
>established security update team, nor a mechanism for distributing such
>updates to users. It seems to me that using more current sources and then
>working towards having assigned package maintainers is a step forward for

well, if every package has its maintainer then i too think it would be best.

>Puppy. We won't know whether it is doable until we try it. Even if we end up
> with only 5 people doing all the package maintenance, that is probably still
>a useful improvement in scalability and long term viability compared to
>Barry doing everything himself!

maybe. id rather compare it to using rocklinux or debian sourcepackages.
they for shure are maintained activly. and the scalability and longterm-
vialibility would be even bigger in my opionion. whatever :)

going to study rocklinux tonight.

cu

Guest

#35 Post by Guest »

flavour wrote:
>Puppy users don't generally need to worry about security updates as much
>as many other distros for 2 reasons:
>(1) not often multi-user
>- hence locally-exploitable holes are (almost) irrelevant
>(2) not often a public-facing server
>- hence remote attackers have nothing to target
>
nice view. but not realistic. puppy users have to be even more
frightenend. they most of the time run each and every app
with root privileges..."and one two three, a rootkit to thee".
there have been numerous exploits for gaim and firefox in the past.
also ive been stepping over some network enabled apps (wiki, some
timetracker..) which of course could be a remote attackers target.

>
>The 1 area that needs attention is the apps that access remote servers
>- particularly browsers (e.g. Firefox when that's present) & e-mail clients.

partly true. but every mp3 every jpg every piece of external data
beeing interpreted by some software on puppy could be the target
for a exploit.

EXCLUSION: PUPPY USERS DO HAVE TO WORRY MORE ABOUT
SECURITY THEN USERS OF MAJOR DISTRUBUTIONS. IMHO

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#36 Post by Pizzasgood »

Root root root. Trees make extensive use of roots, and they're just fine. My roots extend across the Atlantic ocean to Germany, Ireland, and Scotland. I'm still standing. Mountains are also said to have roots.

In my opinion, there are specific areas where the root issue is a problem. Running a webserver, for example. Or multi-user situations.

Neglecting accidental deletion, being a user would limit me more than protecting me. My data, which is what is important, is still just as vulnerable. The OS files can be replaced easily. Especially with Puppy. But that essay I wrote can't. Neither can that wallpaper I drew, or my 242 megabyte wallpaper collection. I care MUCH more about them. But does being a user protect them? Nope. So, being a user offers me no protection.


Another thing to consider is the Puppy Factor. Puppies are tough little guys. Especially Aussie Pups. They have boot scripts that you CAN'T alter without remastering. Any altered or removed files from /usr can be fixed by removing it form /root/.usr. /root/ and /etc are the only other directories you can edit. The rest are INVINCIBLE! /root/ (your home directory) would be vulnerable as a user too, it would just be called /home/pizzasgood/ instead. So /etc is the only thing left particularly vulnerable.

Puppy is also easy to back up, just make a copy of the pup001 file. That backs up the ENTIRE thing. Puppy is also easy to reinstall. As Lobster frequently mentions, he can be on the net after three minutes of inserting the disk and booting.


If you ask me, the all the above make Puppy one tough little penguin. And that's not taking into account the option of running entirely in the ramdisk for the truly paranoid, or multisession for archives of EVERY USE, which makes it very easy to go back and find backups. Then there is the somewhat unknown quality, which adds a small bit to Puppy's hide. Not much, but it's there none the less.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

cnc

#37 Post by cnc »

pizzasgood wrote:
.....
>Another thing to consider is the Puppy Factor. Puppies are tough little guys.
>Especially Aussie Pups. They have boot scripts that you CAN'T alter without
>remastering. Any altered or removed files from /usr can be fixed by
>removing it form /root/.usr. /root/ and /etc are the only other directories
>you can edit. The rest are INVINCIBLE! /root/ (your home directory) would
>be vulnerable as a user too, it would just be called /home/pizzasgood/
>instead. So /etc is the only thing left particularly vulnerable.

what do you mean with invincible ? full write access to all (raw)devices ?
i dont get you :)

>If you ask me, the all the above make Puppy one tough little penguin.
>And that's not taking into account the option of running entirely in the
>ramdisk for the truly paranoid, or multisession for archives of EVERY
>USE, which makes it very easy to go back and find backups. Then there
>is the somewhat unknown quality, which adds a small bit to Puppy's hide.
> Not much, but it's there none the less.

shure a system running of a readonly medium isnt vulnerable to
manipulation of files. your are also right that runnning entirely from
ramdisk would not do any harm thats not undoable by rebooting :)

maybe i am old school believing in the seperation of 0 and the others.
but it served me well till now.

i played around with vserver and usermodelinux in the past. now that
i discovered unionfs via puppy, i can imagine some really comfortable
puppy cages that keeps flees of the "delicate" parts.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#38 Post by Pizzasgood »

what do you mean with invincible ? full write access to all (raw)devices ?
i dont get you :)
I mean changes aren't saved. Just reboot and BAM! All is well. Only /root, /etc, and /usr are writable, and /usr is only partially so. Plus, certain scripts in /etc get copied fresh out of image.gz with each boot, so changes to them aren't kept either.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

cncuse

#39 Post by cncuse »

>I mean changes aren't saved. Just reboot and BAM! All is well. Only /root,
>/etc, and /usr are writable, and /usr is only partially so. Plus, certain scripts
>in /etc get copied fresh out of image.gz with each boot, so changes to them
>aren't kept either.

looks like you believe :) good luck.

cncuse

#40 Post by cncuse »

and before i forget.

mountains dont have roots. imho they been pushed up and or
washed out by water, fire and ice

next time i hope i remeber to talk about uid:0.

root seems to be a little to confusing for some.

Post Reply