That which could be fixed in SBo thread.

Well I've now experimented with both fakeroot building and overlayfs+chroot building, and looked at almost the whole SBo repository.

Overlayfs+chroot gives you everything on the whole system that was modified, including plenty of things that fakeroot misses (such as dotfiles in the user's home directory -- did you know several upstream installers modify ~/.gnupg?).

Fakeroot building is not very helpful. It just stops at the first permission error. I think that is distorting a4z's perception.

a4z is blaming 'the buildscript', but the problem is usually in the upstream installer that the SlackBuild calls. But when the upstream installer puts something outside the packaging directory, does it matter if the SlackBuild immediately corrects the mistake and moves the wrongly installed files to the right place?

In these circumstances fakeroot will stop with an error, *preventing* the SlackBuild from correcting the upstream error.

overlayfs+chroot will show you that the directory was touched, but it will also show you if the SlackBuild then moved all the incorrectly installed files to the right places in the next stage. (You can see an empty modified directory in the 'upper filesystem'.)

There are probably a lot of people reading this thread who are asking "does this really matter, if the package is ok and the host has no rubbish left in the wrong place?" And the answer is, no, it doesn't really matter.

In other cases, there are clear obvious errors in the SlackBuilds, and I will be reporting them to the maintainers in the routine way and giving the maintainers the chance to fix them, without this public blame game on LQ where the maintainers might not even see it.

@55020: as the maintainer of (very few) SlackBuilds I appreciate your contribution on security and your constructive attitude. Thank you.

To me it's clear the error lies in the lua distribution. The slackbuild itself is pretty acceptable and already works around many quirks that would not be needed if lua was not so weird. Building the shared library by hand, having to replace /usr/local by /usr in some header file... it's ridiculous. Of the 40ish unofficial packages I run in my system, no other is that weird. Most others are fine with a "configuration" phase, whatever that is, followed by the compilation and installation steps, and no other writes outside the installation root by accident.

Originally Posted by rg3 To me it's clear the error lies in the lua distribution. The slackbuild itself is pretty acceptable and already works around many quirks that would not be needed if lua was not so weird.

Well, there are a lot of weirdly dysfunctional projects out there. In an ideal world the projects in SBo's development/ category would have the highest quality and best practice in software engineering, but no!!! development/ is a sewer, and the packagers at SBo and Arch and Debian and Fedora and Gentoo and... etc have a really difficult job, and you are right, lua is part of that.

Originally Posted by Didier Spaier @55020: as the maintainer of (very few) SlackBuilds I appreciate your contribution on security and your constructive attitude. Thank you.

Thanks, but it's produced just a small pile of random stuff to fix that wasn't really very evil. What you do with slint actually positively helps people and even attracts people to Planet Slackware.

(Also, building the whole repo on a P4 has kept my house warm for two weeks, which is nice. The bugs are really an unwanted waste product)

Originally Posted by 55020 Well I've now experimented with both fakeroot building and overlayfs+chroot building, and looked at almost the whole SBo repository. Overlayfs+chroot gives you everything on the whole system that was modified, including plenty of things that fakeroot misses (such as dotfiles in the user's home directory -- did you know several upstream installers modify ~/.gnupg?). Fakeroot building is not very helpful. It just stops at the first permission error. I think that is distorting a4z's perception. a4z is blaming 'the buildscript', but the problem is usually in the upstream installer that the SlackBuild calls. But when the upstream installer puts something outside the packaging directory, does it matter if the SlackBuild immediately corrects the mistake and moves the wrongly installed files to the right place? In these circumstances fakeroot will stop with an error, *preventing* the SlackBuild from correcting the upstream error. overlayfs+chroot will show you that the directory was touched, but it will also show you if the SlackBuild then moved all the incorrectly installed files to the right places in the next stage. (You can see an empty modified directory in the 'upper filesystem'.) There are probably a lot of people reading this thread who are asking "does this really matter, if the package is ok and the host has no rubbish left in the wrong place?" And the answer is, no, it doesn't really matter. In other cases, there are clear obvious errors in the SlackBuilds, and I will be reporting them to the maintainers in the routine way and giving the maintainers the chance to fix them, without this public blame game on LQ where the maintainers might not even see it.

That made me remember an old hint on LFS.

Anyway, a SlackBuild that fails in a fake root environment is broken and has to be fixed.


Cheers

Originally Posted by 55020 ....

I am totally aware of the fact that it is very unpopular to point in problems of popular services. so it is OK if you, or others, bash against me because I did not say 'holy Bob, SBo or whoever' and talk about reality.

Is it of course strange because I think, there is nothing to criticise if someone points out a reality, which is that QA is missing and buggy scripts are published, a proven fact.

That which could be fixed in SBo, look at SBo FAQ11, that's bad attitude,
They could also give some useful information in the FAQ, fakeroot, or chroot stuff, or how to apply QA, but they do not, they play the cool kids but they have self proven that they are not and they spread wrong info instead of knowledge.
It is not my fault that they devalue their work like this.

And now, since I again said something unpopular, feel free to bash against me, spread technical nonsense terms like fakeroot feature and have a nice day.

Originally Posted by a4z I am totally aware of the fact that it is very unpopular to point in problems of popular services. so it is OK if you, or others, bash against me because I did not say 'holy Bob, SBo or whoever' and talk about reality.

It is not about bashing. You have an opinion, and we (hopefully) respect you for that, but you are not running SBo. If the SBo admins decide that your suggestions are not going to be implemented then that is their prerogative. It is a matter of differing philosophy. I said it to you on several occasions: when we started the site we decided to stick to the official Slackware way of working and not diverge from it... to spare Patrick some future headaches just like the one you are trying to induce with your fakeroot mission. You have to accept that.

Is it of course strange because I think, there is nothing to criticise if someone points out a reality, which is that QA is missing and buggy scripts are published, a proven fact.

QA is missing at SBo? Buggy scripts are published? Who's bashing who now?
I know as a fact that QA is very important to the SBo admin team. Scripts are checked, the resulting packages are checked, applications are started.
Functional issues will not always be caught by the admins because the SlackBuild submitter often knows how the application works but the admins do not have the same knowledge. This is the limit to what can be done for a proper QA.

Have you ever considered the sheer work that's involved in maintaining a repository like SBO, with all the submissions and update requests? I am still amazed (I have not been an SBO admin for several years now) on how the team manages to keep up with the flow of scripts and maintains the high quality.
I think it is only natural that some bugs will pass the QA tests undetected, it is unfortunate but we are all still human.

But fakeroot is really not going to solve this.

MAME/MESS suggestion.

I know we have a script to build MAME, but since MAME/MESS unified their sources, there's been no effort to build both emulators. Why not have the existing MAME Slackbuild be able to also build MESS if called by an optional parameter such as WITH_MESS=yes to give a more comprehensive package?

Originally Posted by ReaperX7 MAME/MESS suggestion. I know we have a script to build MAME, but since MAME/MESS unified their sources, there's been no effort to build both emulators. Why not have the existing MAME Slackbuild be able to also build MESS if called by an optional parameter such as WITH_MESS=yes to give a more comprehensive package?

Apparently Erik Hanson already thought of that three days ago.
http://slackbuilds.org/cgit/slackbui...?h=mame-review
But the branch is named 'mame-review' so I guess he's not sure if it's ready yet...

Originally Posted by Alien Bob It is not about bashing. You have an opinion, and we (hopefully) respect you for that, but you are not running SBo. If the SBo admins decide that your suggestions are not going to be implemented then that is their prerogative. It is a matter of differing philosophy. I said it to you on several occasions: when we started the site we decided to stick to the official Slackware way of working and not diverge from it... to spare Patrick some future headaches just like the one you are trying to induce with your fakeroot mission. You have to accept that.

what, beside nothing, do you need to implement in the scripts to use them in a chroot env or with fakeroot?

Originally Posted by Alien Bob QA is missing at SBo? Buggy scripts are published? Who's bashing who now? I know as a fact that QA is very important to the SBo admin team. Scripts are checked, the resulting packages are checked, applications are started.

I am not bashing, the lua52 here is a typical example, there are others.
QA is where you use tools like a chroot env or fakeroot.
they do not use the tool, so it is missing and bugs like in zarfy or lua52 happen.

declaring chroot env or fakeroot as a feature that needs extra support is technical nonsenses, thats a fact,

Slackware and SBo created for a lot of people the myth that buildscripts have be be run as root, this is technical nonsenses, thats a fact,

FAQ11 is nothing that helps or spread useful information or teach good practice, thats a fact,

Originally Posted by Alien Bob Have you ever considered the sheer work that's involved in maintaining a repository like SBO, with all the submissions and update requests? I am still amazed (I have not been an SBO admin for several years now) on how the team manages to keep up with the flow of scripts and maintains the high quality. I think it is only natural that some bugs will pass the QA tests undetected, it is unfortunate but we are all still human.

Yes , thats why I suggest they do them self a favour and use tools that help to be more efficient and that guarantee that certain types of bugs do not happen.
is going into a chroot env or using fakeroot ./program.Slackbuild to much work?
what do they fear by doing so? its not even more work, it makes less work at the end.

Originally Posted by Alien Bob But fakeroot is really not going to solve this.

would have, for example, reported the bugs in lua52 and zarfy, this is no help?
maybe a chroot env is more professional, who knows, it would have also helped.

use write it in the FAQ11, and give a good sample how to to solid sustainable work.

Originally Posted by a4z what, beside nothing, do you need to implement in the scripts to use them in a chroot env or with fakeroot?

Apart from what I already said many times to you (SlackBuilds.org will stick to the way in which Slackware itself builds packages): if SBo would additionally support fakeroot, it means the admins get twice the work: first build and check the traditional Slackware way, and then again, using fakeroot. Not going to happen.

I still do not know what you mean with "use them in a chroot env". You will not find more errors in a script by building in a chroot.

I am not bashing, the lua52 here is a typical example, there are others. QA is where you use tools like a chroot env or fakeroot. they do not use the tool, so it is missing and bugs like in zarfy or lua52 happen.

OK this is the last post where I keep commenting on identical accusations. Mistakes happen, and SBo has two mailing lists as well as a IRC channel to report these errors. It happens all the time. What's your point? I did not see you reporting the lua52 bug to either the maintainer of the script nor the SBo admin team. Yet you keep using it here as an example of a "broken process".

declaring chroot env or fakeroot as a feature that needs extra support is technical nonsenses, thats a fact,

See above. Duplicate work load is unacceptible.

Slackware and SBo created for a lot of people the myth that buildscripts have be be run as root, this is technical nonsenses, thats a fact,

It is not a myth, it is the recommended way of working. If you want to use fakeroot, no one is stopping you. If you want to use a Slackware build script or one of SBo, then you have to accept that it works the way it works.

Originally Posted by Alien Bob I still do not know what you mean with "use them in a chroot env". You will not find more errors in a script by building in a chroot.

He means overlayfs + chroot. It's another approach to what slacktrack, checkinstall, installwatch etc etc does. Requires 3.18 kernel (when overlayfs was finally merged).

mkdir -p /tmp/{changes,workdir,chroot}
mount -t overlay overlay -olowerdir=/,upperdir=/tmp/changes,workdir=/tmp/workdir /tmp/chroot
chroot /tmp/chroot sh /path/to/thing.SlackBuild
umount /tmp/chroot

Now look at the contents of /tmp/changes. Everything added, modified or deleted by the SlackBuild is in there.

(There are some implementation details -- /proc, what if your SlackBuild or /tmp is on a mounted filesystem, etc -- but basically that's it.)

Originally Posted by a4z ....

Not only is the horse dead, but you have turned it into a 2mm thick paste on the ground. Please stop beating it.

Originally Posted by Alien Bob I still do not know what you mean with "use them in a chroot env". You will not find more errors in a script by building in a chroot.

thats wrong, of course you will find errors

overlay fs was mentioned and here an other way

http://www.linuxquestions.org/questi...ml#post5309345

Originally Posted by Alien Bob See above. Duplicate work load is unacceptible.

thats wrong, not using a QA tool means more work. and not just for you but also for others.