Re: [Slackbuilds-users] 13.1 Repo Live! - git stuff

2010-05-29 Thread Matteo Bernardini
I forked slackbuilds.org git master, and I checked all the branches I had done on the github SBo-git repo against that, branching the changes on the new fork. This is the result: (sorry for the pastebin link but it wouldn't be much readable in the email body)

Re: [Slackbuilds-users] 13.1 Repo Live! - git stuff

2010-05-29 Thread Matteo Bernardini
sorry for the double posting but yesterday evening I was I little tired and I forgot the most important thing. I tried as much as I can to follow robby advices in committing the branches (also for the commit text): if any of you got suggestions to improve the way I followed or you just spotted

Re: [Slackbuilds-users] 13.1

2010-05-27 Thread Antoine NONYME
Le Wed, 26 May 2010 17:57:59 -0500, Rob McGee r...@slackbuilds.org a écrit : I have found in two cases, one of which was 11.x[1], that installing the *binary* xz package and upgradepkg pkgtools is all it takes to get the ability to deal with .txz in the packaging system[2,3]. I didn't do

Re: [Slackbuilds-users] 13.1

2010-05-26 Thread Ozan Türkyılmaz
2010/5/26 Robby Workman rwork...@slackbuilds.org: On Wed, 26 May 2010 03:12:06 +0100 Eugen Wissner belka...@gmail.com wrote: we decided to use .tgz at least for 13.0 http://lists.slackbuilds.org/pipermail/slackbuilds-users/2009-July/004281.html As it turned out, we *did* make it

Re: [Slackbuilds-users] 13.1

2010-05-26 Thread David Woodfall
On (22:41 25/05/10), Patrick Volkerdink volke...@slackware.com put forth the proposition: On 05/25/2010 10:30 PM, Robby Workman wrote: Anyway, since there seems to be some desire for a definitive statement on this, I'm going to make one: There are no plans to change the default package

Re: [Slackbuilds-users] 13.1

2010-05-26 Thread Rob McGee
On Tue, May 25, 2010 at 10:02:01PM +0200, Antoine NONYME wrote: Rob McGee: xz is a fine tool, possibly superior to gz in every way. But it has not been around as long. I run numerous older boxes, some of which are not likely to get upgraded soon if ever, and sometimes it's nice to be

Re: [Slackbuilds-users] 13.1

2010-05-26 Thread Robby Workman
On Wed, 26 May 2010 10:08:58 +0300 Ozan Türkyılmaz ozan.turkyil...@gmail.com wrote: 2010/5/26 Robby Workman rwork...@slackbuilds.org: On Wed, 26 May 2010 03:12:06 +0100 Eugen Wissner belka...@gmail.com wrote: we decided to use .tgz at least for 13.0

[Slackbuilds-users] 13.1

2010-05-25 Thread Eugen Wissner
hello, can we resubmit our slackbuilds for 13.1? it's out! Should we use .txz as extension or $PKGTYPE variable as earlier? Best regards Eugene. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Ben Mendis
On Tue, May 25, 2010 at 10:36 AM, Eugen Wissner belka...@gmail.com wrote: Should we use .txz as extension or $PKGTYPE variable as earlier? I think we should still use $PKGTYPE, but the question is whether the default should be .txz. Personally, I'm in favor of changing the default to txz.

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Rob McGee
On Tue, May 25, 2010 at 11:03:47AM -0400, Ben Mendis wrote: On Tue, May 25, 2010 at 10:36 AM, Eugen Wissner belka...@gmail.com wrote: Should we use .txz as extension or $PKGTYPE variable as earlier? I think we should still use $PKGTYPE, but the question is whether the default should be

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Ben Mendis
For the sake of debate, only. (Please don't take offense at any of my comments.) On Tue, May 25, 2010 at 2:29 PM, Rob McGee r...@slackbuilds.org wrote: xz is a fine tool, possibly superior to gz in every way. But it has not been around as long. Linux is a fine tool, possibly superior to

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Antoine NONYME
Le Tue, 25 May 2010 13:29:05 -0500, Rob McGee r...@slackbuilds.org a écrit : On Tue, May 25, 2010 at 11:03:47AM -0400, Ben Mendis wrote: On Tue, May 25, 2010 at 10:36 AM, Eugen Wissner belka...@gmail.com wrote: Should we use .txz as extension or $PKGTYPE variable as earlier? I

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Murat D. Kadirov
On 26.05.2010 00:29, Rob McGee wrote: On Tue, May 25, 2010 at 11:03:47AM -0400, Ben Mendis wrote: On Tue, May 25, 2010 at 10:36 AM, Eugen Wissner belka...@gmail.com wrote: Should we use .txz as extension or $PKGTYPE variable as earlier? I think we should still use

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Leonardo
all the question is about to make the 13.x repo to be retrocompatible or not. just leave it .tgz, http://darkstar.ist.utl.pt/slackware/slackware-current/source/a/pkgtools/scripts/ makepkg script adds also .tbz and .tlz as compression options, so if it's so important to support the new format,

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Ash Wiren
I just flipped a coin, and it came up tails for tgz, so thats my vote. I flipped a coin because really its a meaningless point considering one can override the default at build time. On Wed, May 26, 2010 at 4:11 AM, Leonardo sombr...@gmail.com wrote: all the question is about to make the 13.x

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Eugen Wissner
we decided to use .tgz at least for 13.0 http://lists.slackbuilds.org/pipermail/slackbuilds-users/2009-July/004281.html but now we have 13.1 and I don't think, that there are so many changes, that sbo couldn't make one more update. We can use standard slackware format (.txz) and leave it in

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Robby Workman
On Wed, 26 May 2010 03:12:06 +0100 Eugen Wissner belka...@gmail.com wrote: we decided to use .tgz at least for 13.0 http://lists.slackbuilds.org/pipermail/slackbuilds-users/2009-July/004281.html As it turned out, we *did* make it configurable by passing an alternate value to PKGTYPE when

Re: [Slackbuilds-users] 13.1

2010-05-25 Thread Patrick J. Volkerding
On 05/25/2010 10:30 PM, Robby Workman wrote: Anyway, since there seems to be some desire for a definitive statement on this, I'm going to make one: There are no plans to change the default package compression at any point in the near future. The reasons include, but are not necessarily limited