[arch-dev-public] Tool tarball location
On 10/2/07, Jason Chu <jason@archlinux.org> wrote:
Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet...
Yeah, let's use ftp/other/<toolname>/ for all our official stuff like pacman, devtools, etc etc.
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/2/07, Jason Chu <jason@archlinux.org> wrote:
Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet...
Yeah, let's use ftp/other/<toolname>/ for all our official stuff like pacman, devtools, etc etc.
+1, although I'm not sure it was a vote. :) I would just say this- let's try to keep our FTP stuff as clean as we can since Eliott put so much work into getting it that way. Obviously this stuff belongs there, but keeping it in organized folders is important. -Dan
On 10/2/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/2/07, Jason Chu <jason@archlinux.org> wrote:
Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet...
Yeah, let's use ftp/other/<toolname>/ for all our official stuff like pacman, devtools, etc etc.
+1, although I'm not sure it was a vote. :) I would just say this- let's try to keep our FTP stuff as clean as we can since Eliott put so much work into getting it that way. Obviously this stuff belongs there, but keeping it in organized folders is important.
Yeah yeah - I mean, it's voteable sure, but it's kind of a bikeshed thing. I figured we'd just go with precedent - one dir per app.
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Aaron Griffin Verzonden: woensdag 3 oktober 2007 0:47 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] Tool tarball location
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/2/07, Jason Chu <jason@archlinux.org> wrote:
Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet...
Yeah, let's use ftp/other/<toolname>/ for all our official stuff
On 10/2/07, Dan McGee <dpmcgee@gmail.com> wrote: like
pacman, devtools, etc etc.
+1, although I'm not sure it was a vote. :) I would just say this- let's try to keep our FTP stuff as clean as we can since Eliott put so much work into getting it that way. Obviously this stuff belongs there, but keeping it in organized folders is important.
Yeah yeah - I mean, it's voteable sure, but it's kind of a bikeshed thing. I figured we'd just go with precedent - one dir per app.
What about software snapshots? We currently use www.archlinux.org/~name/mozilla/xulrunner-source-1.8.1.6.tar.bz2 for those things for example. Should we also put these snapshots in the other directory? I've seen these things disappearing from homedirs because of cleanups (gstreamer0.10-ffmpeg source was gone after arjan was degraded/promoted to a normal user)
2007/10/3, Jan de Groot <jan@jgc.homeip.net>:
What about software snapshots? We currently use www.archlinux.org/~name/mozilla/xulrunner-source-1.8.1.6.tar.bz2 for those things for example. Should we also put these snapshots in the other directory? I've seen these things disappearing from homedirs because of cleanups (gstreamer0.10-ffmpeg source was gone after arjan was degraded/promoted to a normal user)
Yep, that's exactly what I was thinking about when replying in previous thread (sorry, didn't see that this new one was created). Let's keep homedirs as playground only, while moving used in PKGBUILDs to ftp/other. -- Roman Kyrylych (Роман Кирилич)
Am Wed, 3 Oct 2007 11:03:28 +0300 schrieb "Roman Kyrylych" <roman.kyrylych@gmail.com>:
2007/10/3, Jan de Groot <jan@jgc.homeip.net>:
What about software snapshots? We currently use www.archlinux.org/~name/mozilla/xulrunner-source-1.8.1.6.tar.bz2 for those things for example. Should we also put these snapshots in the other directory? I've seen these things disappearing from homedirs because of cleanups (gstreamer0.10-ffmpeg source was gone after arjan was degraded/promoted to a normal user)
Yep, that's exactly what I was thinking about when replying in previous thread (sorry, didn't see that this new one was created). Let's keep homedirs as playground only, while moving used in PKGBUILDs to ftp/other.
A common source directory sounds good. Even better would be to host _all_ sources for every pkg release somewhere. Harddiscs got cheap and we could solve any possible GPL violence. Some other major distribution also do that. Andy
Am Mittwoch, 3. Oktober 2007 10:14:57 schrieb Andreas Radke:
A common source directory sounds good.
Just a note: if we want to get rid of ftp on gerolde we should put those packages on http. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
On 10/3/07, Andreas Radke <a.radke@arcor.de> wrote:
Even better would be to host _all_ sources for every pkg release somewhere. Harddiscs got cheap and we could solve any possible GPL violence. Some other major distribution also do that.
The last time we brought this up you were the only one against it because you didn't want to upload source tarballs as well as packages. Have you changed you mind on that?
Am Wed, 3 Oct 2007 10:43:50 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
On 10/3/07, Andreas Radke <a.radke@arcor.de> wrote:
Even better would be to host _all_ sources for every pkg release somewhere. Harddiscs got cheap and we could solve any possible GPL violence. Some other major distribution also do that.
The last time we brought this up you were the only one against it because you didn't want to upload source tarballs as well as packages.
Have you changed you mind on that?
Hm? Can't remember that. Sure it would be hard for me to uplaod each source with my slow connection. But it shouldn't be that hard to run a wget directly on our master server ;) Andy
On 10/3/07, Andreas Radke <a.radke@arcor.de> wrote:
Am Wed, 3 Oct 2007 10:43:50 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
On 10/3/07, Andreas Radke <a.radke@arcor.de> wrote:
Even better would be to host _all_ sources for every pkg release somewhere. Harddiscs got cheap and we could solve any possible GPL violence. Some other major distribution also do that.
The last time we brought this up you were the only one against it because you didn't want to upload source tarballs as well as packages.
Have you changed you mind on that?
Hm? Can't remember that. Sure it would be hard for me to uplaod each source with my slow connection. But it shouldn't be that hard to run a wget directly on our master server ;)
True. Would you be willing to script something like that? I don't think it'd be all that hard, but it'd require running through checked in PKGBUILDs and parsing each one's source array for remote files, downloading them, and putting them somewhere. The reason we wanted to do this on the client (and not the server) is because makepkg already does 90% of that. So it would actually be a one line addition to something like extrapkg when uploading - but doing it on the server side is much more code. Still, either way is fine, but I know I personally don't have the time to script a server process to do this. Does anyone?
On Wed, Oct 03, 2007 at 05:08:37PM -0500, Aaron Griffin wrote:
On 10/3/07, Andreas Radke <a.radke@arcor.de> wrote:
Am Wed, 3 Oct 2007 10:43:50 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
On 10/3/07, Andreas Radke <a.radke@arcor.de> wrote:
Even better would be to host _all_ sources for every pkg release somewhere. Harddiscs got cheap and we could solve any possible GPL violence. Some other major distribution also do that.
The last time we brought this up you were the only one against it because you didn't want to upload source tarballs as well as packages.
Have you changed you mind on that?
Hm? Can't remember that. Sure it would be hard for me to uplaod each source with my slow connection. But it shouldn't be that hard to run a wget directly on our master server ;)
True. Would you be willing to script something like that? I don't think it'd be all that hard, but it'd require running through checked in PKGBUILDs and parsing each one's source array for remote files, downloading them, and putting them somewhere.
The reason we wanted to do this on the client (and not the server) is because makepkg already does 90% of that. So it would actually be a one line addition to something like extrapkg when uploading - but doing it on the server side is much more code.
Still, either way is fine, but I know I personally don't have the time to script a server process to do this. Does anyone?
If no one else is going to step up, I can try to put it into my saturday changes. It's something we could put into effect right away to solve the problem. Looks like we have 56 gig free on gerolde, so storing that stuff will be no problem. Jason
Wait..what is this thread about? I may have lost some history due to early message deletion.... Are we talking about storing the source to every package in our ftp tree?
On Sun, Oct 07, 2007 at 05:18:31PM -0700, eliott wrote:
Wait..what is this thread about? I may have lost some history due to early message deletion....
Are we talking about storing the source to every package in our ftp tree?
Yeah. The GPL says that if you distribute a derivative work (binary package) you also have to make available the source. We will need a marker in the PKGBUILD to say that we can't distribute the source, but I'm not worried about that just yet. Jason
On 10/7/07, Jason Chu <jason@archlinux.org> wrote:
On Sun, Oct 07, 2007 at 05:18:31PM -0700, eliott wrote:
Wait..what is this thread about? I may have lost some history due to early message deletion....
Are we talking about storing the source to every package in our ftp tree?
Yeah. The GPL says that if you distribute a derivative work (binary package) you also have to make available the source.
We will need a marker in the PKGBUILD to say that we can't distribute the source, but I'm not worried about that just yet.
Before we dive too deep into this...we only have to _make available_. That doesn't mean we have to actually serve this up on FTP or mirror it or anything. Just having it on the server for compliance would be fine, as anyone that requested source could ask a developer and we could respond. -Dan
On Sun, Oct 07, 2007 at 08:15:59PM -0500, Dan McGee wrote:
On 10/7/07, Jason Chu <jason@archlinux.org> wrote:
On Sun, Oct 07, 2007 at 05:18:31PM -0700, eliott wrote:
Wait..what is this thread about? I may have lost some history due to early message deletion....
Are we talking about storing the source to every package in our ftp tree?
Yeah. The GPL says that if you distribute a derivative work (binary package) you also have to make available the source.
We will need a marker in the PKGBUILD to say that we can't distribute the source, but I'm not worried about that just yet.
Before we dive too deep into this...we only have to _make available_. That doesn't mean we have to actually serve this up on FTP or mirror it or anything. Just having it on the server for compliance would be fine, as anyone that requested source could ask a developer and we could respond.
From the GPL: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) So we either have to accompany our packages with complete corresponding machine-readable source code or a written offer that's valid for three years to distribute it. At this point, we're not doing any of these, so doing anything is better than doing nothing. I just want to make sure that there is no confusion about the requirements of the GPL. Jason
* On Wednesday, October 03 2007, Andreas Radke wrote:
Even better would be to host _all_ sources for every pkg release somewhere. Harddiscs got cheap and we could solve any possible GPL violence. Some other major distribution also do that.
And didn't we decide to do this a while ago in an IRC meeting? Or am I making that up... I think it would be a GREAT idea if we kept sources along with pkgbuilds and packages. We can just store the .tar.gz somewhere, it doesn't need to be versioned like pkgbuilds. We are violating licenses by not doing this, I think it's of high priority. The last thing we want is another Ion fiasco. // jeff -- .: [ + carpe diem totus tuus + ] :.
Wednesday 03 October 2007, Jeff 'codemac' Mickey wrote: | We are violating licenses by not doing this, I think it's of high | priority. i agree. | The last thing we want is another Ion fiasco. Ion fiasco? what happened actually there? i never heard of the state of it... - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
* On Wednesday, October 03 2007, Damir Perisa wrote:
Ion fiasco? what happened actually there? i never heard of the state of it...
As someone who has personal contact with Tuomo, I took it upon myself to make the changes he wanted. He just wanted a name change and the package to stay updated. He'll probably make Ion4 "closed" source, and still provide a binary blob. He knows my nick on freenode, he'll let me know if he has a problem again. // jeff -- .: [ + carpe diem totus tuus + ] :.
On 10/3/07, Jan de Groot <jan@jgc.homeip.net> wrote:
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Aaron Griffin Verzonden: woensdag 3 oktober 2007 0:47 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] Tool tarball location
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/2/07, Jason Chu <jason@archlinux.org> wrote:
Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet...
Yeah, let's use ftp/other/<toolname>/ for all our official stuff
On 10/2/07, Dan McGee <dpmcgee@gmail.com> wrote: like
pacman, devtools, etc etc.
+1, although I'm not sure it was a vote. :) I would just say this- let's try to keep our FTP stuff as clean as we can since Eliott put so much work into getting it that way. Obviously this stuff belongs there, but keeping it in organized folders is important.
Yeah yeah - I mean, it's voteable sure, but it's kind of a bikeshed thing. I figured we'd just go with precedent - one dir per app.
What about software snapshots? We currently use www.archlinux.org/~name/mozilla/xulrunner-source-1.8.1.6.tar.bz2 for those things for example. Should we also put these snapshots in the other directory? I've seen these things disappearing from homedirs because of cleanups (gstreamer0.10-ffmpeg source was gone after arjan was degraded/promoted to a normal user)
Yeah - we shouldn't host this stuff in user directories. It's a little ugly, if you ask me. I say we stick with the precedent - logrotate, mailx, pacman, etc - we have all these tarballs up there in ftp/other/<foo>/ It makes sense to me just to follow this
participants (10)
-
Aaron Griffin
-
Andreas Radke
-
Damir Perisa
-
Dan McGee
-
eliott
-
Jan de Groot
-
Jason Chu
-
Jeff 'codemac' Mickey
-
Pierre Schmitz
-
Roman Kyrylych