[Suggestion]public compile farm for Arch

user · 2006-06-12 06:50:10

Hi,

I tried check curl version

 > curl --version
curl 7.15.1 (i686-pc-linux-gnu) libcurl/7.15.1 OpenSSL/0.9.8b zlib/1.2.3
 >

current curl version is 7.15.4, so if i want to use that version, i have to download PKGBUILD something.

I think this is waste of time to other ppl except doer, if this is done(PKGBUILD) by on the public compile-farm-server,
The compiled result(binary) save to arch files server.

everyone happy to use "sudo pacman -Suy"! Right?

What i meant that "public compile-farm server" is sort of like this one(not exactly same, but anyway..)

http://llvm.org/demo/

iphitus · 2006-06-12 07:18:02

yeah, but the problem with that is when people start putting rm -rf /'s, and forkbombs, rootkits, and all sorts of nasty things inside the PKGBUILD. Or someone will put some rm -rf's, or dd's into the post install script. Sure, some of those are preventable, but you cannot prevent against everything.

how about you just flag stuff out of date instead and let the devs update them?

because this aint goin to happen, it is entirely impractical as it's entirely unsafe for the server, and for the users of the packages from the server.

James

user · 2006-06-12 07:52:40

you don't understand, I shouldn't mentioned PKGBUILD thing,

No, i try to explain here is server-side application.
Bad ass ppl can't do any evil thing on there, but very limited action allowed, for example config option(this also can be disabled for real extremely env).

PS: want more secure? then only ppl here who registered bbs.archlinux.org, he doing something bad, then ban him, or even sue him.

AndyRTR · 2006-06-12 08:09:38

no automatism please! not every update is good update ;-)

user · 2006-06-12 08:34:13

AndyRTR wrote:

no automatism please! not every update is good update ;-)

generally, new software include more new feaures, and security fixes.

kth5 · 2006-06-12 09:27:34

what about pacbuild?

user · 2006-06-12 10:03:43

kth5 wrote:

what about pacbuild?

but curl is 7.15.1, AISB.

stavrosg · 2006-06-12 14:42:06

user wrote:

kth5 wrote:
what about pacbuild?
but curl is 7.15.1, AISB.

You are free to edit the PKGBUILD to produce a package with a newer version.
I do it all the time, but don't bitch about it. ;-)

dtw · 2006-06-12 14:51:25

Personally I'd like to see any pkg flagged safe in the AUR by the TUs automatically built by a compile farm and stored on a nice fat server. Dusty and I discussed it once, I think it's a great idea but of course there are concerns re: storage and bandwidth. You could add a minimum vote requirement as well. E.g. once flagged safe when votes exceed 15 the pkg gets auto-built. Lovely

Cerebral · 2006-06-12 14:59:57

dtw wrote:

Once flagged safe when votes exceed 15 the pkg gets auto-built. Lovely

That'd be sweet - and if the build fails, the package maintainer, and possibly the TU who flagged it safe, could be emailed a log of the build for purposes of fixing.

dtw · 2006-06-12 20:03:12

Well, Cerebral, TBH most pkgs in the AUR are built by the person that submits them before they do so they should always build! Though I guess they could miss deps... But when they do break, due to updated deps, we'll all know because people will actually be using them.

Does that make sense?

Cerebral · 2006-06-12 20:33:12

dtw wrote:

Well, Cerebral, TBH most pkgs in the AUR are built by the person that submits them before they do so they should always build!

While I agree that's how it should happen, it won't always be the case, and it can't hurt to have a check in place - I'm reminded of the thread about AUR and x86_64, where someone (neotuli, was it?) mentioned flagging a pkg as safe but it wouldn't build because of md5sums. Things like this can happen, and a notification to the people responsible for the pkg would be good in such an event.

Expanding on the idea; ideally, such a system would even tie back into the AUR, which would have a way of indicating whether prebuilt packages are available for x86 or x86_64 (as a nod, once again, back to the x86_64 thread) and, while less useful (since people would be using pacman more often than not, wouldn't they?), links to those packages.

Hijacking the thread further ( :oops: ), I'm enjoying pondering the secondary side-effects of such a system, even if it's just talk at the moment. Would [community] become obsolete? What about tools like Aurbuild? Would the TU's "job" become that of simply flagging packages submitted to the AUR?

dtw · 2006-06-12 21:10:17

Cerebral wrote:

dtw wrote:
Well, Cerebral, TBH most pkgs in the AUR are built by the person that submits them before they do so they should always build!
While I agree that's how it should happen, it won't always be the case, and it can't hurt to have a check in place

Yeah, I massively over simplified - sorry

Cerebral wrote:

Would the TU's "job" become that of simply flagging packages submitted to the AUR?

If it did I can see how that wouldn't suit everybody but it would suit a lot more people which means we could expand the TU group even further: many hands make very light work

Arch Linux

#1 2006-06-12 06:50:10

[Suggestion]public compile farm for Arch

#2 2006-06-12 07:18:02

Re: [Suggestion]public compile farm for Arch

#3 2006-06-12 07:52:40

Re: [Suggestion]public compile farm for Arch

#4 2006-06-12 08:09:38

Re: [Suggestion]public compile farm for Arch

#5 2006-06-12 08:34:13

Re: [Suggestion]public compile farm for Arch

#6 2006-06-12 09:27:34

Re: [Suggestion]public compile farm for Arch

#7 2006-06-12 10:03:43

Re: [Suggestion]public compile farm for Arch

#8 2006-06-12 14:42:06

Re: [Suggestion]public compile farm for Arch

#9 2006-06-12 14:51:25

Re: [Suggestion]public compile farm for Arch

#10 2006-06-12 14:59:57

Re: [Suggestion]public compile farm for Arch

#11 2006-06-12 20:03:12

Re: [Suggestion]public compile farm for Arch

#12 2006-06-12 20:33:12

Re: [Suggestion]public compile farm for Arch

#13 2006-06-12 21:10:17

Re: [Suggestion]public compile farm for Arch

Board footer