The software side

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
Sneak peek of PUR

It runs on WSGIRef server so it might not take big load, also the server doesn't have pygments installed so no syntax highlight.

Source is here: https://github.com/Cloudef/PUR

PUR will be important part of PNDBUILD/makepnd eco system, so until it's ready for release I'll hold back packaging makepnd to nice dev enviroinment.

But the code for that is on github too if you want to experiment (though you might want dchrt to use it with for convience too)
 

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,271
Age
42
Location
Ingolstadt
Nice :)

So, when you install something via PUR, will it download and compile directly on your unit (which will surely take a while...) or will the repo pull the stuff from there and compile it up as PND?
 

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
So, when you install something via PUR, will it download and compile directly on your unit (which will surely take a while...) or will the repo pull the stuff from there and compile it up as PND?
It's only for developers really. (And curious users)

dchrt includes distcc which is easy to enable so you get the niceness of native dev enviroinment and the speed of cross compiling at same time (as long as you are not using wifi)

Why should one use the PUR instead of compiling the PND and upload to the REPO?
You are missing the point, PUR is not about distribution of random binary blobs.

It's sharing recipes to build those binary blobs and improve the builds itself.
 
Last edited by a moderator:

bzar

A Commando
Joined
Sep 22, 2008
Messages
4,447
Location
Finland
Website
Visit site
To put it another way: currently, if some PND would need work on the source or build level and the original packager was nowhere to be found, someone would in the worst case need to reimplement all the patches and build configuration the previous packager had done. With PNDBUILD recipes these can be put out in the open via PUR for all to use and improve on. Also, new versions can be built using the same recipe by anyone given the build process hasn't changed.
 
Last edited by a moderator:

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,506
Location
Somewhere off the coast of the EU
Yes, or even if you're the maintainer, but forgot how exactly you invoked the build last time. Reproducible builds are a universally good thing, and done well they're no more complex than building locally, just a bit different.
 

rohezal

Advanced Member
Joined
Oct 18, 2009
Messages
1,673
Do we have the source for all the pnds on the repo (except the cloused source ones)?
 

_jr_

Advanced Member
Joined
May 5, 2013
Messages
1,170
It would be a great first step to have some kind of optional 'source package' upload on the repo. Or directly go the PUR route.


Would make it much easier to comply with typical copyleft licenses.
 

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
It would be a great first step to have some kind of optional 'source package' upload on the repo. Or directly go the PUR route.


Would make it much easier to comply with typical copyleft licenses.
No, source belong to other places like github and such.

If you have modified the upstream sources, you include patches in the recipe.

You don't want to upload modified sources that are hard to maintain, and ideally these patches that are made properly can be accepted by upstream as well (helping others)
 

_jr_

Advanced Member
Joined
May 5, 2013
Messages
1,170
Not that I disagree with your software engineering reasoning, but source packages are legally required for most copyleft type stuff, since we cannot guarantee that the original source will stay available in the documented place as long as the binary package is on our repo. That's why distributions do them and I think PUR could easily create them. It is not required that they are easy to use, more a backup for failure of the principal distribution point. And that is not only theoretical, it's a real PITA tracking down missing packages for e.g. older openembedded builds. Therefore it's also a good idea for non-copyleft stuff.
 
Last edited by a moderator:

Cloudef

Member
Joined
Dec 30, 2009
Messages
460
Location
Gensokyo
Not that I disagree with your software engineering reasoning, but source packages are legally required for most copyleft type stuff, since we cannot guarantee that the original source will stay available in the documented place as long as the binary package is on our repo. That's why distributions do them and I think PUR could easily create them. It is not required that they are easy to use, more a backup for failure of the principal distribution point. And that is not only theoretical, it's a real PITA tracking down missing packages for e.g. older openembedded builds. Therefore it's also a good idea for non-copyleft stuff.
As long as this does not encourage to modify the sources itself instead of providing patches in recipe, you can include tarball of the sources with the recipe no problem..

Not that I like that much, I would only do it for recipes which source you really can't guarantee to stay alive.
 

bzar

A Commando
Joined
Sep 22, 2008
Messages
4,447
Location
Finland
Website
Visit site
How about doing a source pull at PNDBUILD submit and hold onto that as a tarball? Or better yet, if we could get a build server set up to build PNDs/ipks/debs/whatever from PUR-based PNDBUILDs, it could also provide those.
 
Last edited by a moderator:

klapse

Central Scrutinizer
Joined
Aug 30, 2012
Messages
1,932
Location
Germany
[...] Or better yet, if we could get a build server set up to build PNDs/ipks/debs/whatever from PUR-based PNDBUILDs, it could also provide those.
Who will setup the security around the build servers? Or do you think nobody can send a malicious script and f*** up EVERY package?
Maybe the build server could run the script in a chroot.
 

vinipsmaker

Member
Joined
Jun 22, 2013
Messages
209
Location
Brazil
Website
vinipsmaker.github.io
Maybe the build server could run the script in a chroot.
This isn't enough. The process would still have the same view (namespace) of the operating system.

This would allow, for instance, a connection to the database. The database is just an example, because you can make authenticated connections or use unix sockets, but it illustrates the problem that someone actually must take care of the security and know what the system is doing.

Another problem with the same namespace: Script could DoS the servers (like the HTTP one) and run its own HTTP server, replacing the official one.

I think the minimum requirement is linux containers (banning root and/or combined with things like seccomp and selinux) or virtual machines.

And if the environment is compromissed, other scripts should be fine, then development effort must be wasted (?) creating a namespace for each build script.
 

klapse

Central Scrutinizer
Joined
Aug 30, 2012
Messages
1,932
Location
Germany
The simple solution would be to forego a build service. Let the PND packager do the build himself and provide a place to upload the source tarball.
 
Top