The software side

[Cloudef]

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]

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?

 

[Askarus]

will it download and compile directly on your unit

or will the repo pull the stuff from there and compile it up as PND?

Both doesn't make sense to me.

Why should one use the PUR instead of compiling the PND and upload to the REPO?

 

[Cloudef]

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.

 

[Askarus]

Understood .

 

[bzar]

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.

 

[levi]

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]

Do we have the source for all the pnds on the repo (except the cloused source ones)?

 

[klapse]

Do we have the source for all the pnds on the repo (except the cloused source ones)?

Not the one I uploaded. Not sure where to put the source.

 

[_jr_]

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]

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_]

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.

 

[Cloudef]

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]

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.

 

[vinipsmaker]

[...] 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?

 

[klapse]

[...] 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]

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.

 

[bzar]

Something like OBS? For example Jolla's open repo uses it.

 

[vinipsmaker]

Something like OBS? For example Jolla's open repo uses it.

It seems better. Thanks for the kickstarter in the research effort. Now somebody need to look how the service can be used to serve the Pandora devs.

 

[klapse]

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.