On 20 December 2011 16:58, Timothy Pearson <kb9vqf(a)pearsoncomputing.net>wrote;wrote: Even more reason to switch to xz packages :)

On 20 December 2011 18:08, Timothy Pearson <kb9vqf(a)pearsoncomputing.net>wrote;wrote: Of course but after Arch Linux switched to xz I was mightily impressed. I wonder what policies exist.

On 20 December 2011 18:46, Keith Daniels <keithwdaniels(a)gmail.com> wrote: I think you're just a bit confused on this. we all do use the same source however

2011/12/21 Keith Daniels <keithwdaniels(a)gmail.com>om>: As far as I understood, the .xz packets are just compressed binaries created by make. In order to create PKGBUILDs for other distros we would need to provide a method for building them and installing. Building: something that interpretes PKGBUILD and use their inside function and variables to do buiding. Installing something that extracts them into root. We could do some research on this.

Hi L0ner I think you understood what I was implying. As Calvin observed I really don't understand enough about how the Arch system works (but I am studying, experimenting and trying to learn) to suggest what you can and can not do with it. Nor do I know what you need to store on the Trinity server, nor how you create the binaries for the other distros. But sometimes people who don't understand a process can come up with possible uses that more knowledgeable people would not think of--because they are so far out in left field. My original suggestion was not to "use" the Arch pacman system or software, but to take the "concept" of a PKGBUILD script and use that concept to possibly reduce the amount of effort required to create a distro's binary or to reduce the amount of "stored" files on the Trinity server required to support the various distros. Since creating binaries for the different distros is something that I imagine is time consuming, building a system to automate this--per distro--might speed up the process. If so, it could make it easier to provide beta binaries for the average user to test, and not require your more experienced programmers to create them. This would permit a lot more average users to tests the packages and would give you more feedback. Right now you have very little that non programmers can do to help you develop Trinity. Anything that could be set up that would permit non programmers to do things that would reduce the work load on your experienced programmers could make a big difference in your productivity. I am not a programmer, but in my past careers of Sysadmin and Webmaster I have been around them a lot and had to build a lot of software from source. I am impressed with the efficiency of the Arch packaging system and using it is very simple even for newbies. But... as is common with most OSS programming projects that create large complex software packages, they do not describe the "structure" and "interrelationships" of their overall system. Instead they give a lot of detailed step by step instructions for various parts of the system. For simply installing a package from their repository this works fine. But if you want to do things like create local repositories or create your own PKGBUILDs--not understanding the "Big Picture" makes it very confusing for a non programmer. Using something like a flow chart or even a "mind map" to show the relationships of the various processes and programs involved could help immensely and prevent a lot of confusion for new users. Keith On Wed, Dec 21, 2011 at 10:11 AM, Calvin Morrison <mutantturkey(a)gmail.com> wrote:

Hi Tim, This could be a mirror upload that's been stalled for two days. --Mike $ rsync -va mirror.ets.kth.se::trinity/trinity-v3.5.13/debian/pool/main/k/kipi-plugins-trinity/.kipi-plugins-trinity_3.5.13-0ubuntu9+r1254372+pr4~oneiric_i386.deb.Agl3VZ receiving incremental file list -rw------- 2883584 2012/01/10 23:51:41 .kipi-plugins-trinity_3.5.13-0ubuntu9+r1254372+pr4~oneiric_i386.deb.Agl3VZ sent 29 bytes received 143 bytes 49.14 bytes/sec total size is 2883584 speedup is 16765.02 $