Robby Workman | 9 Mar 18:08 2011

[ANNOUNCE]: Slackware 13.37 rc1 and SBo

Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
know why we closed pending a few days ago :-)  We're doing some early
work on getting ready for 13.37, and we'll be soliciting feedback for
that soon, but at the moment, I personally would like to know if there
are any pressing issues that need to be handled in our 13.1 repo.
I'm not making any promises to do anything, but if you have some 
important things that need to be addressed there, now is the time to
let me know (and make it as easy as possible to do - i.e. provide a
tarball, git pull request, etcetera).  I've already got the update
to tor, so don't mention that one.  My goal is to finalize 13.1 so
that we can all focus on getting everything in place for 13.37.

-RW
Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
know why we closed pending a few days ago :-)  We're doing some early
work on getting ready for 13.37, and we'll be soliciting feedback for
that soon, but at the moment, I personally would like to know if there
are any pressing issues that need to be handled in our 13.1 repo.
I'm not making any promises to do anything, but if you have some 
important things that need to be addressed there, now is the time to
let me know (and make it as easy as possible to do - i.e. provide a
tarball, git pull request, etcetera).  I've already got the update
to tor, so don't mention that one.  My goal is to finalize 13.1 so
that we can all focus on getting everything in place for 13.37.

-RW
Ozan Türkyılmaz | 9 Mar 18:29 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

2011/3/9 Robby Workman <rworkman <at> slackbuilds.org>:
> Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> know why we closed pending a few days ago :-)  We're doing some early
> work on getting ready for 13.37, and we'll be soliciting feedback for
> that soon, but at the moment, I personally would like to know if there
> are any pressing issues that need to be handled in our 13.1 repo.
> I'm not making any promises to do anything, but if you have some
> important things that need to be addressed there, now is the time to
> let me know (and make it as easy as possible to do - i.e. provide a
> tarball, git pull request, etcetera).  I've already got the update
> to tor, so don't mention that one.  My goal is to finalize 13.1 so
> that we can all focus on getting everything in place for 13.37.
>

I'm cooking some for mkv. Others have small fixes and I'll go over
them and send it a patch.

--

-- 
Ozan, BSc, BEng
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Rich Shepard | 9 Mar 19:12 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Wed, 9 Mar 2011, Robby Workman wrote:

> Okay, everybody saw the 13.37 rc1 announcement,

   First I've seen of it.

   Just curious why the version is 13.37 rather than 13.2.

Rich
Robby Workman | 9 Mar 19:24 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Wed, 9 Mar 2011 10:12:57 -0800 (PST)
Rich Shepard <rshepard@...> wrote:

> On Wed, 9 Mar 2011, Robby Workman wrote:
> 
> > Okay, everybody saw the 13.37 rc1 announcement,
> 
>    First I've seen of it.
> 
>    Just curious why the version is 13.37 rather than 13.2.

Why would it be 13.2 rather than 13.37?  :-)

-RW
On Wed, 9 Mar 2011 10:12:57 -0800 (PST)
Rich Shepard <rshepard@...> wrote:

> On Wed, 9 Mar 2011, Robby Workman wrote:
> 
> > Okay, everybody saw the 13.37 rc1 announcement,
> 
>    First I've seen of it.
> 
>    Just curious why the version is 13.37 rather than 13.2.

Why would it be 13.2 rather than 13.37?  :-)

-RW
(Continue reading)

Rich Shepard | 9 Mar 20:19 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Wed, 9 Mar 2011, Robby Workman wrote:

> Why would it be 13.2 rather than 13.37?  :-)

   Because 2 comes before 37 when counting? Because previous minor version
numbers have been 1 and 2? If there's no particular reason that's fine with
me. At least we don't have silly version names like the ubuntus do. :-)

Rich
Eric Pratt | 9 Mar 19:24 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

It was in the changelog.

If you remove the '.' in 13.37, its like 'elite' in l33t speak.

On Wed, Mar 9, 2011 at 1:12 PM, Rich Shepard <rshepard@...> wrote:
> On Wed, 9 Mar 2011, Robby Workman wrote:
>
>> Okay, everybody saw the 13.37 rc1 announcement,
>
>  First I've seen of it.
>
>  Just curious why the version is 13.37 rather than 13.2.
>
> Rich
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users@...
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>
Grissiom | 10 Mar 02:12 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Thu, Mar 10, 2011 at 2:24 AM, Eric Pratt <eric.b.pratt <at> gmail.com> wrote:
> It was in the changelog.
>
> If you remove the '.' in 13.37, its like 'elite' in l33t speak.
>

Not mentioned in slackware64-current ChangeLog.txt tough...

I think there is an other reason to be numbered as .37 -- RC1 use
2.6.37 kernel, which is going to be the kernel in next release.

--

-- 
Cheers,
Grissiom

> On Wed, Mar 9, 2011 at 1:12 PM, Rich Shepard <rshepard <at> appl-ecosys.com> wrote:
>> On Wed, 9 Mar 2011, Robby Workman wrote:
>>
>>> Okay, everybody saw the 13.37 rc1 announcement,
>>
>>  First I've seen of it.
>>
>>  Just curious why the version is 13.37 rather than 13.2.
>>
>> Rich
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
(Continue reading)

King Beowulf | 9 Mar 19:53 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

Well, I guess I need to check the changelog more that once or twice a
week!  Holy l337-speak batman!

I will hop on it as soon as I can and check the slackbuilds I maintain
ater I update my VMs. I'll send in updated stuff to for the nvidia
binary blobs I took over.

I forgot "volunteering" also meant "work" ;-)

On 3/9/11, Robby Workman <rworkman@...> wrote:
> Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> know why we closed pending a few days ago :-)  We're doing some early
> work on getting ready for 13.37, and we'll be soliciting feedback for
> that soon, but at the moment, I personally would like to know if there
> are any pressing issues that need to be handled in our 13.1 repo.
> I'm not making any promises to do anything, but if you have some
> important things that need to be addressed there, now is the time to
> let me know (and make it as easy as possible to do - i.e. provide a
> tarball, git pull request, etcetera).  I've already got the update
> to tor, so don't mention that one.  My goal is to finalize 13.1 so
> that we can all focus on getting everything in place for 13.37.
>
> -RW
>

--

-- 
Sent from my mobile device

You! What PLANET is this!
	-- McCoy, "The City on the Edge of Forever", stardate 3134.0
(Continue reading)

Matteo Bernardini | 9 Mar 22:33 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

Il 09/03/2011 18:08, Robby Workman ha scritto:
> if you have some
> important things that need to be addressed there, now is the time to
> let me know (and make it as easy as possible to do - i.e. provide a
> tarball, git pull request, etcetera)

I have three thingies that I promised to take over maintaining but I 
hadn't submitted yet, just changed maintainer data in the .info files

http://ompldr.org/vN3Frbw/libfm.tar.gz
http://ompldr.org/vN3FrZg/lxpanel.tar.gz
http://ompldr.org/vN3Frag/pcmanfm.tar.gz

if you prefeer a "git send-email" just let me know :)

Matteo

P.S. to all: if can be useful, this is the stuff I'm building on RC1, 
feel free to have a look :D

http://cgit.ponce.cc/slackbuilds/refs/heads
Robby Workman | 10 Mar 05:34 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Wed, 09 Mar 2011 22:33:07 +0100
Matteo Bernardini <matteo.bernardini@...> wrote:

> Il 09/03/2011 18:08, Robby Workman ha scritto:
> > if you have some
> > important things that need to be addressed there, now is the time to
> > let me know (and make it as easy as possible to do - i.e. provide a
> > tarball, git pull request, etcetera)
> 
> I have three thingies that I promised to take over maintaining but I 
> hadn't submitted yet, just changed maintainer data in the .info files
> 
> http://ompldr.org/vN3Frbw/libfm.tar.gz
> http://ompldr.org/vN3FrZg/lxpanel.tar.gz
> http://ompldr.org/vN3Frag/pcmanfm.tar.gz
> 
> if you prefeer a "git send-email" just let me know :)

Got them; thanks!

-RW
On Wed, 09 Mar 2011 22:33:07 +0100
Matteo Bernardini <matteo.bernardini@...> wrote:

> Il 09/03/2011 18:08, Robby Workman ha scritto:
> > if you have some
> > important things that need to be addressed there, now is the time to
> > let me know (and make it as easy as possible to do - i.e. provide a
(Continue reading)

Gwenhael Le Moine | 10 Mar 04:36 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

2011/3/10 Robby Workman <rworkman <at> slackbuilds.org>:
> Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> know why we closed pending a few days ago :-)  We're doing some early
> work on getting ready for 13.37, and we'll be soliciting feedback for
> that soon, but at the moment, I personally would like to know if there
> are any pressing issues that need to be handled in our 13.1 repo.
> I'm not making any promises to do anything, but if you have some
> important things that need to be addressed there, now is the time to
> let me know (and make it as easy as possible to do - i.e. provide a
> tarball, git pull request, etcetera).  I've already got the update
> to tor, so don't mention that one.  My goal is to finalize 13.1 so
> that we can all focus on getting everything in place for 13.37.
>
> -RW

I just have the updated .info for gem2tgz  <at> 
https://github.com/cycojesus/slackbuilds/tree/master/SBo/gem2tgz
It's not at all tied to a release of Slackware so feel free to ignore
it from now and I'll re-submit it when things calm down.
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Robby Workman | 10 Mar 05:29 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Thu, 10 Mar 2011 10:36:37 +0700
Gwenhael Le Moine <gwenhael.le.moine@...> wrote:

> I just have the updated .info for gem2tgz  <at> 
> https://github.com/cycojesus/slackbuilds/tree/master/SBo/gem2tgz
> It's not at all tied to a release of Slackware so feel free to ignore
> it from now and I'll re-submit it when things calm down.

I've got this queued for addition to 13.1 since I was working 
on that branch anyway.  Thanks!

-RW
On Thu, 10 Mar 2011 10:36:37 +0700
Gwenhael Le Moine <gwenhael.le.moine@...> wrote:

> I just have the updated .info for gem2tgz  <at> 
> https://github.com/cycojesus/slackbuilds/tree/master/SBo/gem2tgz
> It's not at all tied to a release of Slackware so feel free to ignore
> it from now and I'll re-submit it when things calm down.

I've got this queued for addition to 13.1 since I was working 
on that branch anyway.  Thanks!

-RW
Ozan Türkyılmaz | 12 Mar 20:39 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

2011/3/9 Robby Workman <rworkman@...>:
> Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> know why we closed pending a few days ago :-)  We're doing some early
> work on getting ready for 13.37, and we'll be soliciting feedback for
> that soon, but at the moment, I personally would like to know if there
> are any pressing issues that need to be handled in our 13.1 repo.
> I'm not making any promises to do anything, but if you have some
> important things that need to be addressed there, now is the time to
> let me know (and make it as easy as possible to do - i.e. provide a
> tarball, git pull request, etcetera).  I've already got the update
> to tor, so don't mention that one.  My goal is to finalize 13.1 so
> that we can all focus on getting everything in place for 13.37.
>

Updates attached. Updated scripts; libebml (version bump and option to
build static), libmatroska (version bump and option to build static)
libtbb (version bump) gsnmp(version bump. And I know web site is down
but ftp works fine) mkvtoolnix (version bump and option to build QT
gui).

--

-- 
Ozan, BSc, BEng
Attachment (update.tar.gz): application/x-gzip, 8093 bytes
2011/3/9 Robby Workman <rworkman@...>:
> Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> know why we closed pending a few days ago :-)  We're doing some early
> work on getting ready for 13.37, and we'll be soliciting feedback for
> that soon, but at the moment, I personally would like to know if there
(Continue reading)

Robby Workman | 14 Mar 19:51 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Sat, 12 Mar 2011 21:39:03 +0200
Ozan Türkyılmaz <ozan.turkyilmaz@...> wrote:

> 2011/3/9 Robby Workman <rworkman@...>:
> > Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> > know why we closed pending a few days ago :-)  We're doing some
> > early work on getting ready for 13.37, and we'll be soliciting
> > feedback for that soon, but at the moment, I personally would like
> > to know if there are any pressing issues that need to be handled in
> > our 13.1 repo. I'm not making any promises to do anything, but if
> > you have some important things that need to be addressed there, now
> > is the time to let me know (and make it as easy as possible to do -
> > i.e. provide a tarball, git pull request, etcetera).  I've already
> > got the update to tor, so don't mention that one.  My goal is to
> > finalize 13.1 so that we can all focus on getting everything in
> > place for 13.37.
> >
> 
> Updates attached. Updated scripts; libebml (version bump and option to
> build static), libmatroska (version bump and option to build static)
> libtbb (version bump) gsnmp(version bump. And I know web site is down
> but ftp works fine) mkvtoolnix (version bump and option to build QT
> gui).

Is this stuff that's necessary (REALLY needed) for 13.1, or can it
wait for submissions to open after 13.37 releases?

-RW
(Continue reading)

Greg' Ar Tourter | 13 Mar 00:15 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

Hi,

There are quite a few packages that, although do not need to be
upgraded to work in 13.37, they need to be recompiled as the libraries
they depend on have changed.
this include all the perl modules, texlive (pdftex at least does not
work due to poppler) pdftk (due to libgcj). I suspect there are others
but it gives a good idea of the issue.

Should be bump the build number of these package on the 13.37 repo
when there isn't a new version available, to help users?

Cheers

Greg

On 9 March 2011 17:08, Robby Workman <rworkman <at> slackbuilds.org> wrote:
> Okay, everybody saw the 13.37 rc1 announcement, I guess, so now you
> know why we closed pending a few days ago :-)  We're doing some early
> work on getting ready for 13.37, and we'll be soliciting feedback for
> that soon, but at the moment, I personally would like to know if there
> are any pressing issues that need to be handled in our 13.1 repo.
> I'm not making any promises to do anything, but if you have some
> important things that need to be addressed there, now is the time to
> let me know (and make it as easy as possible to do - i.e. provide a
> tarball, git pull request, etcetera).  I've already got the update
> to tor, so don't mention that one.  My goal is to finalize 13.1 so
> that we can all focus on getting everything in place for 13.37.
>
> -RW
(Continue reading)

Erik Hanson | 13 Mar 00:34 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Sat, 12 Mar 2011 23:15:54 +0000
"Greg' Ar Tourter" <artourter@...> wrote:

> There are quite a few packages that, although do not need to be
> upgraded to work in 13.37, they need to be recompiled as the libraries
> they depend on have changed.
> this include all the perl modules, texlive (pdftex at least does not
> work due to poppler) pdftk (due to libgcj). I suspect there are others
> but it gives a good idea of the issue.
> 
> Should be bump the build number of these package on the 13.37 repo
> when there isn't a new version available, to help users?

Although I see your point, we haven't done this in the past, so I'm
inclined to say no.

--

-- 
Erik Hanson
On Sat, 12 Mar 2011 23:15:54 +0000
"Greg' Ar Tourter" <artourter@...> wrote:

> There are quite a few packages that, although do not need to be
> upgraded to work in 13.37, they need to be recompiled as the libraries
> they depend on have changed.
> this include all the perl modules, texlive (pdftex at least does not
> work due to poppler) pdftk (due to libgcj). I suspect there are others
> but it gives a good idea of the issue.
> 
(Continue reading)

Ozan Türkyılmaz | 13 Mar 00:42 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

2011/3/13 Erik Hanson <erik@...>:
> On Sat, 12 Mar 2011 23:15:54 +0000
> "Greg' Ar Tourter" <artourter@...> wrote:
>
>> There are quite a few packages that, although do not need to be
>> upgraded to work in 13.37, they need to be recompiled as the libraries
>> they depend on have changed.
>> this include all the perl modules, texlive (pdftex at least does not
>> work due to poppler) pdftk (due to libgcj). I suspect there are others
>> but it gives a good idea of the issue.
>>
>> Should be bump the build number of these package on the 13.37 repo
>> when there isn't a new version available, to help users?
>
> Although I see your point, we haven't done this in the past, so I'm
> inclined to say no.

Any sane user would recompile them anyway.

--

-- 
Ozan, BSc, BEng
Robby Workman | 14 Mar 03:30 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Sat, 12 Mar 2011 17:34:24 -0600
Erik Hanson <erik@...> wrote:

> On Sat, 12 Mar 2011 23:15:54 +0000
> "Greg' Ar Tourter" <artourter@...> wrote:
> 
> > There are quite a few packages that, although do not need to be
> > upgraded to work in 13.37, they need to be recompiled as the
> > libraries they depend on have changed.
> > this include all the perl modules, texlive (pdftex at least does not
> > work due to poppler) pdftk (due to libgcj). I suspect there are
> > others but it gives a good idea of the issue.
> > 
> > Should be bump the build number of these package on the 13.37 repo
> > when there isn't a new version available, to help users?
> 
> Although I see your point, we haven't done this in the past, so I'm
> inclined to say no.

Same inclination here.   :-)

-RW
On Sat, 12 Mar 2011 17:34:24 -0600
Erik Hanson <erik@...> wrote:

> On Sat, 12 Mar 2011 23:15:54 +0000
> "Greg' Ar Tourter" <artourter@...> wrote:
> 
(Continue reading)

Yucatan "Kenjiro" Costa | 14 Mar 12:35 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

Just to let you guys know, the chromium.SlackBuild works with 13.1 and -current (13.37rc1), so no changes need on this regard.


I barely can't wait for the official release of 13.37 :D



On Sun, Mar 13, 2011 at 11:30 PM, Robby Workman <rworkman-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org> wrote:
On Sat, 12 Mar 2011 17:34:24 -0600
Erik Hanson <erik-ko+OqhKiB2ybq9pD2ovt6w@public.gmane.orgg> wrote:

> On Sat, 12 Mar 2011 23:15:54 +0000
> "Greg' Ar Tourter" <artourter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > There are quite a few packages that, although do not need to be
> > upgraded to work in 13.37, they need to be recompiled as the
> > libraries they depend on have changed.
> > this include all the perl modules, texlive (pdftex at least does not
> > work due to poppler) pdftk (due to libgcj). I suspect there are
> > others but it gives a good idea of the issue.
> >
> > Should be bump the build number of these package on the 13.37 repo
> > when there isn't a new version available, to help users?
>
> Although I see your point, we haven't done this in the past, so I'm
> inclined to say no.


Same inclination here.   :-)

-RW

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/





--
May the Force be with you!

Yucatan "Kenjiro" Costa

<div>
<p>Just to let you guys know, the chromium.SlackBuild works with 13.1 and -current (13.37rc1), so no changes need on this regard.</p>
<div><br></div>
<div>I barely can't wait for the official release of 13.37 :D</div>
<div><br></div>
<div>
<br><br><div class="gmail_quote">On Sun, Mar 13, 2011 at 11:30 PM, Robby Workman <span dir="ltr">&lt;<a href="mailto:rworkman <at> slackbuilds.org">rworkman@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>
<div></div>
<div class="h5">On Sat, 12 Mar 2011 17:34:24 -0600<br>
Erik Hanson &lt;<a href="mailto:erik@...">erik@...g</a>&gt; wrote:<br><br>
&gt; On Sat, 12 Mar 2011 23:15:54 +0000<br>
&gt; "Greg' Ar Tourter" &lt;<a href="mailto:artourter <at> gmail.com">artourter@...</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; There are quite a few packages that, although do not need to be<br>
&gt; &gt; upgraded to work in 13.37, they need to be recompiled as the<br>
&gt; &gt; libraries they depend on have changed.<br>
&gt; &gt; this include all the perl modules, texlive (pdftex at least does not<br>
&gt; &gt; work due to poppler) pdftk (due to libgcj). I suspect there are<br>
&gt; &gt; others but it gives a good idea of the issue.<br>
&gt; &gt;<br>
&gt; &gt; Should be bump the build number of these package on the 13.37 repo<br>
&gt; &gt; when there isn't a new version available, to help users?<br>
&gt;<br>
&gt; Although I see your point, we haven't done this in the past, so I'm<br>
&gt; inclined to say no.<br><br><br>
</div>
</div>Same inclination here. &nbsp; :-)<br><br>
-RW<br><br>_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br><br>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>May the Force be with you!<div><br></div>
<div>Yucatan "Kenjiro" Costa</div>
<br>
</div>
</div>
Ben Mendis | 14 Mar 13:48 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo



On Sun, Mar 13, 2011 at 10:30 PM, Robby Workman <rworkman-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org> wrote:
On Sat, 12 Mar 2011 17:34:24 -0600
Erik Hanson <erik-ko+OqhKiB2ybq9pD2ovt6w@public.gmane.orgg> wrote:

> On Sat, 12 Mar 2011 23:15:54 +0000
> "Greg' Ar Tourter" <artourter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > There are quite a few packages that, although do not need to be
> > upgraded to work in 13.37, they need to be recompiled as the
> > libraries they depend on have changed.
> > this include all the perl modules, texlive (pdftex at least does not
> > work due to poppler) pdftk (due to libgcj). I suspect there are
> > others but it gives a good idea of the issue.
> >
> > Should be bump the build number of these package on the 13.37 repo
> > when there isn't a new version available, to help users?
>
> Although I see your point, we haven't done this in the past, so I'm
> inclined to say no.


Same inclination here.   :-)

Out of curiosity, what would be the potential downsides to bumping the build numbers?
Is it just that it's inconsistent with previous releases, or that it involves a lot of work? (I'm not implying that you're lazy, I appreciate the valuable time you donate to helping us out.)
Or are there some other problems that it might introduce that I'm not aware of?

I'd just like to understand the reasoning behind this decision.
Thanks,
Ben
 

-RW

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/



<div>
<br><br><div class="gmail_quote">On Sun, Mar 13, 2011 at 10:30 PM, Robby Workman <span dir="ltr">&lt;<a href="mailto:rworkman@...">rworkman@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>
<div></div>
<div class="h5">On Sat, 12 Mar 2011 17:34:24 -0600<br>
Erik Hanson &lt;<a href="mailto:erik@...">erik@...g</a>&gt; wrote:<br><br>
&gt; On Sat, 12 Mar 2011 23:15:54 +0000<br>
&gt; "Greg' Ar Tourter" &lt;<a href="mailto:artourter <at> gmail.com">artourter@...</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; There are quite a few packages that, although do not need to be<br>
&gt; &gt; upgraded to work in 13.37, they need to be recompiled as the<br>
&gt; &gt; libraries they depend on have changed.<br>
&gt; &gt; this include all the perl modules, texlive (pdftex at least does not<br>
&gt; &gt; work due to poppler) pdftk (due to libgcj). I suspect there are<br>
&gt; &gt; others but it gives a good idea of the issue.<br>
&gt; &gt;<br>
&gt; &gt; Should be bump the build number of these package on the 13.37 repo<br>
&gt; &gt; when there isn't a new version available, to help users?<br>
&gt;<br>
&gt; Although I see your point, we haven't done this in the past, so I'm<br>
&gt; inclined to say no.<br><br><br>
</div>
</div>Same inclination here. &nbsp; :-)<br>
</blockquote>
<div>
<br>Out of curiosity, what would be the potential downsides to bumping the build numbers? <br>Is it just that it's inconsistent with previous releases, or that it involves a lot of work? (I'm not implying that you're lazy, I appreciate the valuable time you donate to helping us out.)<br>
Or are there some other problems that it might introduce that I'm not aware of? <br><br>I'd just like to understand the reasoning behind this decision. <br>Thanks,<br>Ben<br>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
-RW<br><br>_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br><br>
</blockquote>
</div>
<br>
</div>
Chris Abela | 14 Mar 14:21 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo


>> Out of curiosity, what would be the potential downsides to bumping the build numbers?

We write SlackBuilds so build numbers should reflect SlackBuilds. It is up to the users to compile, package and install on their machines.

<div>

<div class="Section1">

<div>

<div>

<p class="MsoNormal"><span><br><span>&gt;&gt; </span>Out of
curiosity, what would be the potential downsides to bumping the build numbers? <br><br><p></p></span></p>

</div>

</div>

<p class="MsoNormal"><span>We write SlackBuilds so build numbers
should reflect SlackBuilds. It is up to the users to compile, package and
install on their machines. <p></p></span></p>

</div>

</div>
xgizzmo | 14 Mar 14:41 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Monday 14 March 2011 09:21:15 Chris Abela wrote:
> 
> We write SlackBuilds so build numbers should reflect SlackBuilds. It is up
> to the users to compile, package and install on their machines. 
> 
> 

That is correct the build number reflects the changes to the SlackBuild in 
our case. But just for fun lets say you want to use the logic that this is 
a new Slackware version and the build numbers need to be changed, then they 
should all be reset to 1. In any case we don't dictate how the admin manage 
their system but we do make provisions for the admin to change the build
number if they want to. For example BUILD="5" TAG="_SBo_13.37" ./Some.SlackBuild

--dsomero
Antonio Hernández Blas | 14 Mar 16:04 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Mon, Mar 14, 2011 at 7:41 AM,  <xgizzmo <at> slackbuilds.org> wrote:
> That is correct the build number reflects the changes to the SlackBuild in
> our case. But just for fun lets say you want to use the logic that this is
> a new Slackware version and the build numbers need to be changed, then they
> should all be reset to 1. In any case we don't dictate how the admin manage
> their system but we do make provisions for the admin to change the build
> number if they want to. For example BUILD="5" TAG="_SBo_13.37" ./Some.SlackBuild
>

Keeping BUILD the same helps to those one (like me) who still uses
13.0, so they just rsync its local port with SBo 13.1/13.37 and theres
no need to worry (mostly) about changes between slackware version,
BUILD and SBo ports at all... so i don´t see any need (at least for
me) to use that "change-the-build-number-if-they-want" thing ;)

--

-- 
- hba
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Ben Mendis | 14 Mar 18:38 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo



2011/3/14 Antonio Hernández Blas <hba.nihilismus <at> gmail.com>
On Mon, Mar 14, 2011 at 7:41 AM,  <xgizzmo-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org> wrote:
> That is correct the build number reflects the changes to the SlackBuild in
> our case. But just for fun lets say you want to use the logic that this is
> a new Slackware version and the build numbers need to be changed, then they
> should all be reset to 1. In any case we don't dictate how the admin manage
> their system but we do make provisions for the admin to change the build
> number if they want to. For example BUILD="5" TAG="_SBo_13.37" ./Some.SlackBuild
>

Keeping BUILD the same helps to those one (like me) who still uses
13.0, so they just rsync its local port with SBo 13.1/13.37 and theres
no need to worry (mostly) about changes between slackware version,
BUILD and SBo ports at all... so i don´t see any need (at least for
me) to use that "change-the-build-number-if-they-want" thing ;)

Perhaps I misunderstood. I thought the proposal was to bump the build number for SlackBuilds in the new 13.37 repository that would need to be rebuilt after updating from 13.1 (as a convenience to sbopkg users). I had assumed that the SlackBuilds in the 13.1 repository would stay the same since no re-build was necessary. 

Also, I realize that the build number can be specified at build-time, but that doesn't provide any assistance to sbopkg users at all, they would still need to manually add each package to the queue to be rebuilt. (Furthermore, sbopkg seems to lack the ability to override the default BUILD or TAG on a per-package basis, but that has nothing to do with SBo itself.)

I can accept the argument that the build number reflects changes in the SlackBuild itself, but there didn't seem to be any harm in making an exception in this situation.

Oh well, it just means that users will need to do a bit more manual work (and we'll probably find ourselves answering a lot of very similar questions on LQ and ##slackware after people upgrade), but that really nothing new.

Would it be acceptable for maintainers to submit a build bump if they wanted to, or is there a hard "NO" on this issue?
Not that it even affects me since I don't currently maintain any packages which would be affected.


--
- hba

<div>
<br><br><div class="gmail_quote">2011/3/14 Antonio Hern&aacute;ndez Blas <span dir="ltr">&lt;<a href="mailto:hba.nihilismus@...">hba.nihilismus <at> gmail.com</a>&gt;</span><br><blockquote class="gmail_quote">
<div class="im">On Mon, Mar 14, 2011 at 7:41 AM, &nbsp;&lt;<a href="mailto:xgizzmo@...">xgizzmo@...</a>&gt; wrote:<br>
&gt; That is correct the build number reflects the changes to the SlackBuild in<br>
&gt; our case. But just for fun lets say you want to use the logic that this is<br>
&gt; a new Slackware version and the build numbers need to be changed, then they<br>
&gt; should all be reset to 1. In any case we don't dictate how the admin manage<br>
&gt; their system but we do make provisions for the admin to change the build<br>
&gt; number if they want to. For example BUILD="5" TAG="_SBo_13.37" ./Some.SlackBuild<br>
&gt;<br><br>
</div>Keeping BUILD the same helps to those one (like me) who still uses<br>
13.0, so they just rsync its local port with SBo 13.1/13.37 and theres<br>
no need to worry (mostly) about changes between slackware version,<br>
BUILD and SBo ports at all... so i don&acute;t see any need (at least for<br>
me) to use that "change-the-build-number-if-they-want" thing ;)<br>
</blockquote>
<div>
<br>Perhaps I misunderstood. I thought the proposal was to bump the build number for SlackBuilds in the new 13.37 repository that would need to be rebuilt after updating from 13.1 (as a convenience to sbopkg users). I had assumed that the SlackBuilds in the 13.1 repository would stay the same since no re-build was necessary.&nbsp; <br><br>Also, I realize that the build number can be specified at build-time, but that doesn't provide any assistance to sbopkg users at all, they would still need to manually add each package to the queue to be rebuilt. (Furthermore, sbopkg seems to lack the ability to override the default BUILD or TAG on a per-package basis, but that has nothing to do with SBo itself.)<br><br>I can accept the argument that the build number reflects changes in the SlackBuild itself, but there didn't seem to be any harm in making an exception in this situation. <br><br>Oh well, it just means that users will need to do a bit more manual work (and we'll probably find ourselves answering a lot of very similar questions on LQ and ##slackware after people upgrade), but that really nothing new. <br><br>Would it be acceptable for maintainers to submit a build bump if they wanted to, or is there a hard "NO" on this issue?<br>Not that it even affects me since I don't currently maintain any packages which would be affected. <br><br>
</div>
<blockquote class="gmail_quote">
<br>
--<br>
- hba<br><div>
<div></div>
<div class="h5">_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
T3slider | 14 Mar 19:12 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

Bumping the version number for every package on SBo would be the
equivalent of doing `slackpkg clean-system` and recompiling each
third-party application from slackbuilds.org -- which would be the
standard advice for anyone having such troubles with multiple packages.
Otherwise, applications that may be ABI-compatible with dependencies
from Slackware 13.37 would need to maintain the same build number while
others that would require a recompile would need a bump. Determining
which ones would need this is too much effort in my opinion, especially
when you get into issues like an application breaking not because it
isn't ABI-compatible with Slackware packages, but because it isn't
ABI-compatible with an SBo dependency that breaks with new Slackware.

You can take your chances running old 13.1-compiled apps on 13.37 and
recompile those that are broken, or clean-system and rebuild them all
(`ls /var/log/packages/*_SBo` would get a list). Of course you would
need to build them in the right order which would involve reading
READMEs or using build queues. In the end, I don't think bumping
versions has *any* benefit that I can see and it's certainly more work
anyway.

On Mon, Mar 14, 2011 at 01:38:10PM -0400, Ben Mendis wrote:
>    Perhaps I misunderstood. I thought the proposal was to bump the build
>    number for SlackBuilds in the new 13.37 repository that would need to be
>    rebuilt after updating from 13.1 (as a convenience to sbopkg users). I had
>    assumed that the SlackBuilds in the 13.1 repository would stay the same
>    since no re-build was necessary. 
> 
>    Also, I realize that the build number can be specified at build-time, but
>    that doesn't provide any assistance to sbopkg users at all, they would
>    still need to manually add each package to the queue to be rebuilt.
>    (Furthermore, sbopkg seems to lack the ability to override the default
>    BUILD or TAG on a per-package basis, but that has nothing to do with SBo
>    itself.)
> 
>    I can accept the argument that the build number reflects changes in the
>    SlackBuild itself, but there didn't seem to be any harm in making an
>    exception in this situation.
> 
>    Oh well, it just means that users will need to do a bit more manual work
>    (and we'll probably find ourselves answering a lot of very similar
>    questions on LQ and ##slackware after people upgrade), but that really
>    nothing new.
> 
>    Would it be acceptable for maintainers to submit a build bump if they
>    wanted to, or is there a hard "NO" on this issue?
>    Not that it even affects me since I don't currently maintain any packages
>    which would be affected.
> 
>      --
>      - hba
>      _______________________________________________
>      SlackBuilds-users mailing list
>      SlackBuilds-users@...
>      http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>      Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>      FAQ - http://slackbuilds.org/faq/

> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users@...
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
> 

Robby Workman | 14 Mar 19:50 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Mon, 14 Mar 2011 14:12:18 -0400
T3slider <t3slider@...> wrote:

> Bumping the version number for every package on SBo would be the
> equivalent of doing `slackpkg clean-system` and recompiling each
> third-party application from slackbuilds.org -- which would be the
> standard advice for anyone having such troubles with multiple
> packages. Otherwise, applications that may be ABI-compatible with
> dependencies from Slackware 13.37 would need to maintain the same
> build number while others that would require a recompile would need a
> bump. Determining which ones would need this is too much effort in my
> opinion, especially when you get into issues like an application
> breaking not because it isn't ABI-compatible with Slackware packages,
> but because it isn't ABI-compatible with an SBo dependency that
> breaks with new Slackware.
> 
> You can take your chances running old 13.1-compiled apps on 13.37 and
> recompile those that are broken, or clean-system and rebuild them all
> (`ls /var/log/packages/*_SBo` would get a list). Of course you would
> need to build them in the right order which would involve reading
> READMEs or using build queues. In the end, I don't think bumping
> versions has *any* benefit that I can see and it's certainly more work
> anyway.

Good summary there too.  

-RW
On Mon, 14 Mar 2011 14:12:18 -0400
T3slider <t3slider@...> wrote:

> Bumping the version number for every package on SBo would be the
> equivalent of doing `slackpkg clean-system` and recompiling each
> third-party application from slackbuilds.org -- which would be the
> standard advice for anyone having such troubles with multiple
> packages. Otherwise, applications that may be ABI-compatible with
> dependencies from Slackware 13.37 would need to maintain the same
> build number while others that would require a recompile would need a
> bump. Determining which ones would need this is too much effort in my
> opinion, especially when you get into issues like an application
> breaking not because it isn't ABI-compatible with Slackware packages,
> but because it isn't ABI-compatible with an SBo dependency that
> breaks with new Slackware.
> 
> You can take your chances running old 13.1-compiled apps on 13.37 and
> recompile those that are broken, or clean-system and rebuild them all
> (`ls /var/log/packages/*_SBo` would get a list). Of course you would
> need to build them in the right order which would involve reading
> READMEs or using build queues. In the end, I don't think bumping
> versions has *any* benefit that I can see and it's certainly more work
> anyway.

Good summary there too.  

-RW
Ben Mendis | 14 Mar 19:57 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

Ah, this explanation makes perfect sense. Thanks!

On Mon, Mar 14, 2011 at 2:12 PM, T3slider <t3slider-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Bumping the version number for every package on SBo would be the
equivalent of doing `slackpkg clean-system` and recompiling each
third-party application from slackbuilds.org -- which would be the
standard advice for anyone having such troubles with multiple packages.
Otherwise, applications that may be ABI-compatible with dependencies
from Slackware 13.37 would need to maintain the same build number while
others that would require a recompile would need a bump. Determining
which ones would need this is too much effort in my opinion, especially
when you get into issues like an application breaking not because it
isn't ABI-compatible with Slackware packages, but because it isn't
ABI-compatible with an SBo dependency that breaks with new Slackware.

You can take your chances running old 13.1-compiled apps on 13.37 and
recompile those that are broken, or clean-system and rebuild them all
(`ls /var/log/packages/*_SBo` would get a list). Of course you would
need to build them in the right order which would involve reading
READMEs or using build queues. In the end, I don't think bumping
versions has *any* benefit that I can see and it's certainly more work
anyway.

On Mon, Mar 14, 2011 at 01:38:10PM -0400, Ben Mendis wrote:
>    Perhaps I misunderstood. I thought the proposal was to bump the build
>    number for SlackBuilds in the new 13.37 repository that would need to be
>    rebuilt after updating from 13.1 (as a convenience to sbopkg users). I had
>    assumed that the SlackBuilds in the 13.1 repository would stay the same
>    since no re-build was necessary.
>
>    Also, I realize that the build number can be specified at build-time, but
>    that doesn't provide any assistance to sbopkg users at all, they would
>    still need to manually add each package to the queue to be rebuilt.
>    (Furthermore, sbopkg seems to lack the ability to override the default
>    BUILD or TAG on a per-package basis, but that has nothing to do with SBo
>    itself.)
>
>    I can accept the argument that the build number reflects changes in the
>    SlackBuild itself, but there didn't seem to be any harm in making an
>    exception in this situation.
>
>    Oh well, it just means that users will need to do a bit more manual work
>    (and we'll probably find ourselves answering a lot of very similar
>    questions on LQ and ##slackware after people upgrade), but that really
>    nothing new.
>
>    Would it be acceptable for maintainers to submit a build bump if they
>    wanted to, or is there a hard "NO" on this issue?
>    Not that it even affects me since I don't currently maintain any packages
>    which would be affected.
>
>      --
>      - hba
>      _______________________________________________
>      SlackBuilds-users mailing list
>      SlackBuilds-users-ko+OqhKiB2wsHrnhXWJB8w@public.gmane.org
>      http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>      Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>      FAQ - http://slackbuilds.org/faq/

> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users <at> slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>

_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users <at> slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/


<div>
<p>Ah, this explanation makes perfect sense. Thanks!<br><br></p>
<div class="gmail_quote">On Mon, Mar 14, 2011 at 2:12 PM, T3slider <span dir="ltr">&lt;<a href="mailto:t3slider@...">t3slider@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Bumping the version number for every package on SBo would be the<br>
equivalent of doing `slackpkg clean-system` and recompiling each<br>
third-party application from <a href="http://slackbuilds.org" target="_blank">slackbuilds.org</a> -- which would be the<br>
standard advice for anyone having such troubles with multiple packages.<br>
Otherwise, applications that may be ABI-compatible with dependencies<br>
from Slackware 13.37 would need to maintain the same build number while<br>
others that would require a recompile would need a bump. Determining<br>
which ones would need this is too much effort in my opinion, especially<br>
when you get into issues like an application breaking not because it<br>
isn't ABI-compatible with Slackware packages, but because it isn't<br>
ABI-compatible with an SBo dependency that breaks with new Slackware.<br><br>
You can take your chances running old 13.1-compiled apps on 13.37 and<br>
recompile those that are broken, or clean-system and rebuild them all<br>
(`ls /var/log/packages/*_SBo` would get a list). Of course you would<br>
need to build them in the right order which would involve reading<br>
READMEs or using build queues. In the end, I don't think bumping<br>
versions has *any* benefit that I can see and it's certainly more work<br>
anyway.<br><div>
<div></div>
<div class="h5">
<br>
On Mon, Mar 14, 2011 at 01:38:10PM -0400, Ben Mendis wrote:<br>
&gt; &nbsp; &nbsp;Perhaps I misunderstood. I thought the proposal was to bump the build<br>
&gt; &nbsp; &nbsp;number for SlackBuilds in the new 13.37 repository that would need to be<br>
&gt; &nbsp; &nbsp;rebuilt after updating from 13.1 (as a convenience to sbopkg users). I had<br>
&gt; &nbsp; &nbsp;assumed that the SlackBuilds in the 13.1 repository would stay the same<br>
&gt; &nbsp; &nbsp;since no re-build was necessary.<br>
&gt;<br>
&gt; &nbsp; &nbsp;Also, I realize that the build number can be specified at build-time, but<br>
&gt; &nbsp; &nbsp;that doesn't provide any assistance to sbopkg users at all, they would<br>
&gt; &nbsp; &nbsp;still need to manually add each package to the queue to be rebuilt.<br>
&gt; &nbsp; &nbsp;(Furthermore, sbopkg seems to lack the ability to override the default<br>
&gt; &nbsp; &nbsp;BUILD or TAG on a per-package basis, but that has nothing to do with SBo<br>
&gt; &nbsp; &nbsp;itself.)<br>
&gt;<br>
&gt; &nbsp; &nbsp;I can accept the argument that the build number reflects changes in the<br>
&gt; &nbsp; &nbsp;SlackBuild itself, but there didn't seem to be any harm in making an<br>
&gt; &nbsp; &nbsp;exception in this situation.<br>
&gt;<br>
&gt; &nbsp; &nbsp;Oh well, it just means that users will need to do a bit more manual work<br>
&gt; &nbsp; &nbsp;(and we'll probably find ourselves answering a lot of very similar<br>
&gt; &nbsp; &nbsp;questions on LQ and ##slackware after people upgrade), but that really<br>
&gt; &nbsp; &nbsp;nothing new.<br>
&gt;<br>
&gt; &nbsp; &nbsp;Would it be acceptable for maintainers to submit a build bump if they<br>
&gt; &nbsp; &nbsp;wanted to, or is there a hard "NO" on this issue?<br>
&gt; &nbsp; &nbsp;Not that it even affects me since I don't currently maintain any packages<br>
&gt; &nbsp; &nbsp;which would be affected.<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp;--<br>
&gt; &nbsp; &nbsp; &nbsp;- hba<br>
&gt; &nbsp; &nbsp; &nbsp;_______________________________________________<br>
&gt; &nbsp; &nbsp; &nbsp;SlackBuilds-users mailing list<br>
&gt; &nbsp; &nbsp; &nbsp;<a href="mailto:SlackBuilds-users@...">SlackBuilds-users@...</a><br>
&gt; &nbsp; &nbsp; &nbsp;<a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
&gt; &nbsp; &nbsp; &nbsp;Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
&gt; &nbsp; &nbsp; &nbsp;FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
&gt; _______________________________________________<br>
&gt; SlackBuilds-users mailing list<br>
&gt; <a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br>
&gt; <a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
&gt; Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
&gt; FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
&gt;<br><br>
_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
Robby Workman | 14 Mar 19:49 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Mon, 14 Mar 2011 13:38:10 -0400
Ben Mendis <dragonwisard@...> wrote:

> Perhaps I misunderstood. I thought the proposal was to bump the build
> number for SlackBuilds in the new 13.37 repository that would need to
> be rebuilt after updating from 13.1 (as a convenience to sbopkg
> users). I had assumed that the SlackBuilds in the 13.1 repository
> would stay the same since no re-build was necessary.
> 
> Also, I realize that the build number can be specified at build-time,
> but that doesn't provide any assistance to sbopkg users at all, they
> would still need to manually add each package to the queue to be
> rebuilt. (Furthermore, sbopkg seems to lack the ability to override
> the default BUILD or TAG on a per-package basis, but that has nothing
> to do with SBo itself.)
> 
> I can accept the argument that the build number reflects changes in
> the SlackBuild itself, but there didn't seem to be any harm in making
> an exception in this situation.

This is the first release that we've been using git during the change
from previous to new, so the workflow is a bit different, and we can't
do what we've always done, which is reset all of the BUILD numbers to
"1" regardless.  It's never caused problems (that we're aware of) for
sbopkg before, and I don't see why it should, and even if it does, I
still don't think that would be a large enough issue to change what
we do.  Besides, I'd be quite surprised if sbopkg didn't allow setting
BUILD locally.

> Would it be acceptable for maintainers to submit a build bump if they
> wanted to, or is there a hard "NO" on this issue?

No, that's a timesink that we can't afford at this point.

-RW

On Mon, 14 Mar 2011 13:38:10 -0400
Ben Mendis <dragonwisard@...> wrote:

> Perhaps I misunderstood. I thought the proposal was to bump the build
> number for SlackBuilds in the new 13.37 repository that would need to
> be rebuilt after updating from 13.1 (as a convenience to sbopkg
> users). I had assumed that the SlackBuilds in the 13.1 repository
> would stay the same since no re-build was necessary.
> 
> Also, I realize that the build number can be specified at build-time,
> but that doesn't provide any assistance to sbopkg users at all, they
> would still need to manually add each package to the queue to be
> rebuilt. (Furthermore, sbopkg seems to lack the ability to override
> the default BUILD or TAG on a per-package basis, but that has nothing
> to do with SBo itself.)
> 
> I can accept the argument that the build number reflects changes in
> the SlackBuild itself, but there didn't seem to be any harm in making
> an exception in this situation.

This is the first release that we've been using git during the change
from previous to new, so the workflow is a bit different, and we can't
do what we've always done, which is reset all of the BUILD numbers to
"1" regardless.  It's never caused problems (that we're aware of) for
sbopkg before, and I don't see why it should, and even if it does, I
still don't think that would be a large enough issue to change what
we do.  Besides, I'd be quite surprised if sbopkg didn't allow setting
BUILD locally.

> Would it be acceptable for maintainers to submit a build bump if they
> wanted to, or is there a hard "NO" on this issue?

No, that's a timesink that we can't afford at this point.

-RW

slakmagik | 15 Mar 03:55 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On 2011-03-14 (Mon) 13:49:51 [-0500], Robby Workman wrote:
> On Mon, 14 Mar 2011 13:38:10 -0400
> Ben Mendis <dragonwisard@...> wrote:
> 
> > 
> > Also, I realize that the build number can be specified at build-time,
> > but that doesn't provide any assistance to sbopkg users at all, they
> > would still need to manually add each package to the queue to be
> > rebuilt. (Furthermore, sbopkg seems to lack the ability to override
> > the default BUILD or TAG on a per-package basis, but that has nothing
> > to do with SBo itself.)
> > 
> 
> This is the first release that we've been using git during the change
> from previous to new, so the workflow is a bit different, and we can't
> do what we've always done, which is reset all of the BUILD numbers to
> "1" regardless.  It's never caused problems (that we're aware of) for
> sbopkg before, and I don't see why it should, and even if it does, I
> still don't think that would be a large enough issue to change what
> we do.  Besides, I'd be quite surprised if sbopkg didn't allow setting
> BUILD locally.
> 

Well... :) I'm surprised it doesn't allow it properly.

A way to change the build on a per package basis from the command line
is to use the 'per app options' syntax on the command line and use
standard vars (BUILD, etc.) like special vars (WITH_WHIZBANG_FEATURE,
etc.):

# sbopkg -i app:BUILD=build

However, doing the same for TAG fails because sbopkg uses an internal
variable. The following is *wrong* (because the user shouldn't use this
variable) but "works" (at least as far as building):

# sbopkg -i app:REPO_TAG=tag

The queuefiles don't-quite-work the same way:

app|BUILD=build REPO_TAG=tag

From the menu interface, using the 'OPTIONS' item is the same - though,
if you didn't mind changing the SlackBuild, you'd could also use
'CUSTOM' to do it directly.

And, regardless, this isn't directly documented.

IOW, Ben, you should have reported this as a bug and there's work to do.
If there's anything you can do *without* sbopkg that you can't do *with*
sbopkg, it's at least theoretically a bug.

But, while possibly simple to fix (hope springs eternal), the general
issue is in a lot of areas of the code, some of it really squirrelly,
and a proper fix may have to wait until next time. As is (aside from one
small glitch whose tiny patch just needs to be tested a little more and
committed), sbopkg seems to be working (though changing BUILD and TAG is
awkward and inconsistent) and I wouldn't want to break anything right
now trying to smooth that out.

If this needs more discussion, shifting this part to sbopkg-users would
be best.

One last note: I don't know what you mean by "need to manually add each
package to the queue to be rebuilt". I keep a master queue of every SBo
package (or sub-queue of packages) on a given system (and one of local
stuff) and habitually rebuild everything at new Slackware/SBo releases
by reusing that (them). If you don't have such a queue then, from the
menu interface, there's 'Add/Add all installed packages to the queue',
'Sort/Sort items in build queue', and 'Save/Save the current build
queue' (though I'd just use $EDITOR for sorting in that case).
Eric Pratt | 15 Mar 04:49 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Mon, Mar 14, 2011 at 10:55 PM, slakmagik <slakmagik@...> wrote:
>
> If there's anything you can do *without* sbopkg that you can't do *with*
> sbopkg, it's at least theoretically a bug.
>

I knew it was a bug when I couldn't make a pot pie with sbopkg.  I just KNEW it!
Robby Workman | 15 Mar 05:03 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Mon, 14 Mar 2011 23:49:08 -0400
Eric Pratt <eric.b.pratt@...> wrote:

> On Mon, Mar 14, 2011 at 10:55 PM, slakmagik <slakmagik@...>
> wrote:
> >
> > If there's anything you can do *without* sbopkg that you can't do
> > *with* sbopkg, it's at least theoretically a bug.
> >
> 
> I knew it was a bug when I couldn't make a pot pie with sbopkg.  I
> just KNEW it!

While we're fixing these egregious oversights, someone should figure
out how to make it bring me a beer.  ;-)

-RW
On Mon, 14 Mar 2011 23:49:08 -0400
Eric Pratt <eric.b.pratt@...> wrote:

> On Mon, Mar 14, 2011 at 10:55 PM, slakmagik <slakmagik@...>
> wrote:
> >
> > If there's anything you can do *without* sbopkg that you can't do
> > *with* sbopkg, it's at least theoretically a bug.
> >
> 
> I knew it was a bug when I couldn't make a pot pie with sbopkg.  I
> just KNEW it!

While we're fixing these egregious oversights, someone should figure
out how to make it bring me a beer.  ;-)

-RW
slakmagik | 15 Mar 22:04 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On 2011-03-14 (Mon) 23:03:34 [-0500], Robby Workman wrote:
> On Mon, 14 Mar 2011 23:49:08 -0400
> Eric Pratt <eric.b.pratt@...> wrote:
> 
> > On Mon, Mar 14, 2011 at 10:55 PM, slakmagik <slakmagik@...>
> > wrote:
> > >
> > > If there's anything you can do *without* sbopkg that you can't do
> > > *with* sbopkg, it's at least theoretically a bug.
> > >
> > 
> > I knew it was a bug when I couldn't make a pot pie with sbopkg.  I
> > just KNEW it!
> 
> 
> While we're fixing these egregious oversights, someone should figure
> out how to make it bring me a beer.  ;-)
> 

Oops :) - scope error. I mean "anything related to building SBo
packages". Though, actually, then it should still probably bring pot
pies and beer. ;)

Oh, and to Ben, I have a question - I was originally thinking about
abstract consistency for per app settings but is there a use case where
you'd *want* to set the BUILD of all packages to the same number or the
TAG of a set of packages to different values? While not the most
consistent (but, after all, they're doing different things),

# sbopkg -i foo:BUILD=build # per app
# TAG=tag sbopkg -i foo     # all apps

should cover most needs.
Ben Mendis | 16 Mar 02:57 2011
Picon

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo



On Tue, Mar 15, 2011 at 5:04 PM, slakmagik <slakmagik <at> gmail.com> wrote:
On 2011-03-14 (Mon) 23:03:34 [-0500], Robby Workman wrote:
> On Mon, 14 Mar 2011 23:49:08 -0400
> Eric Pratt <eric.b.pratt <at> gmail.com> wrote:
>
> > On Mon, Mar 14, 2011 at 10:55 PM, slakmagik <slakmagik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > wrote:
> > >
> > > If there's anything you can do *without* sbopkg that you can't do
> > > *with* sbopkg, it's at least theoretically a bug.
> > >
> >
> > I knew it was a bug when I couldn't make a pot pie with sbopkg.  I
> > just KNEW it!
>
>
> While we're fixing these egregious oversights, someone should figure
> out how to make it bring me a beer.  ;-)
>

Oops :) - scope error. I mean "anything related to building SBo
packages". Though, actually, then it should still probably bring pot
pies and beer. ;)

Oh, and to Ben, I have a question - I was originally thinking about
abstract consistency for per app settings but is there a use case where
you'd *want* to set the BUILD of all packages to the same number or the
TAG of a set of packages to different values? While not the most
consistent (but, after all, they're doing different things),

# sbopkg -i foo:BUILD=build # per app
# TAG=tag sbopkg -i foo     # all apps

should cover most needs.

I didn't realize it was possible to use the "foo:BUILD=build" syntax to set per-package build numbers. Off the top of my head, I can't think of any reason to mangle either value, but I'm sure someone could find a clever way to abuse either or both.

Also, I had always assumed that the BUILD number represented the package build and not the SlackBuild revision. Eg, if Pat were to rebuild a package against a new library using the same SlackBuild, wouldn't he bump the BUILD of that package in the tree? But I guess SBo is doing it differently since they host SlackBuilds and not packages. (And the issue of complex dependency chains makes perfect sense as well.)

<div>
<br><br><div class="gmail_quote">On Tue, Mar 15, 2011 at 5:04 PM, slakmagik <span dir="ltr">&lt;<a href="mailto:slakmagik@...">slakmagik <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>
<div></div>
<div class="h5">On 2011-03-14 (Mon) 23:03:34 [-0500], Robby Workman wrote:<br>
&gt; On Mon, 14 Mar 2011 23:49:08 -0400<br>
&gt; Eric Pratt &lt;<a href="mailto:eric.b.pratt@...">eric.b.pratt <at> gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Mon, Mar 14, 2011 at 10:55 PM, slakmagik &lt;<a href="mailto:slakmagik@...">slakmagik@...</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If there's anything you can do *without* sbopkg that you can't do<br>
&gt; &gt; &gt; *with* sbopkg, it's at least theoretically a bug.<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I knew it was a bug when I couldn't make a pot pie with sbopkg. &nbsp;I<br>
&gt; &gt; just KNEW it!<br>
&gt;<br>
&gt;<br>
&gt; While we're fixing these egregious oversights, someone should figure<br>
&gt; out how to make it bring me a beer. &nbsp;;-)<br>
&gt;<br><br>
</div>
</div>Oops :) - scope error. I mean "anything related to building SBo<br>
packages". Though, actually, then it should still probably bring pot<br>
pies and beer. ;)<br><br>
Oh, and to Ben, I have a question - I was originally thinking about<br>
abstract consistency for per app settings but is there a use case where<br>
you'd *want* to set the BUILD of all packages to the same number or the<br>
TAG of a set of packages to different values? While not the most<br>
consistent (but, after all, they're doing different things),<br><br>
# sbopkg -i foo:BUILD=build # per app<br>
# TAG=tag sbopkg -i foo &nbsp; &nbsp; # all apps<br><br>
should cover most needs.<br>
</blockquote>
<div>
<br>I didn't realize it was possible to use the "foo:BUILD=build" syntax to set per-package build numbers. Off the top of my head, I can't think of any reason to mangle either value, but I'm sure someone could find a clever way to abuse either or both.<br><br>Also, I had always assumed that the BUILD number represented the package build and not the SlackBuild revision. Eg, if Pat were to rebuild a package against a new library using the same SlackBuild, wouldn't he bump the BUILD of that package in the tree? But I guess SBo is doing it differently since they host SlackBuilds and not packages. (And the issue of complex dependency chains makes perfect sense as well.)<br>
</div>
<blockquote class="gmail_quote">
<div>
<div></div>
<div class="h5">_______________________________________________<br>
SlackBuilds-users mailing list<br><a href="mailto:SlackBuilds-users@...">SlackBuilds-users <at> slackbuilds.org</a><br><a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
Robby Workman | 16 Mar 03:07 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Tue, 15 Mar 2011 21:57:09 -0400
Ben Mendis <dragonwisard@...> wrote:

> Also, I had always assumed that the BUILD number represented the
> package build and not the SlackBuild revision. Eg, if Pat were to
> rebuild a package against a new library using the same SlackBuild,
> wouldn't he bump the BUILD of that package in the tree? But I guess
> SBo is doing it differently since they host SlackBuilds and not
> packages.

Bingo.  BUILD for *us* is something that we increment when changes
on our end would result in changes to the resulting package.  For
example, if we make edits to README, we would not increment BUILD,
while modification of an installed config file would result in a
BUILD increment.

However, BUILD for *you* (and other sysadmins) is whatever *you*
want it to be. 

-RW
On Tue, 15 Mar 2011 21:57:09 -0400
Ben Mendis <dragonwisard@...> wrote:

> Also, I had always assumed that the BUILD number represented the
> package build and not the SlackBuild revision. Eg, if Pat were to
> rebuild a package against a new library using the same SlackBuild,
> wouldn't he bump the BUILD of that package in the tree? But I guess
> SBo is doing it differently since they host SlackBuilds and not
> packages.

Bingo.  BUILD for *us* is something that we increment when changes
on our end would result in changes to the resulting package.  For
example, if we make edits to README, we would not increment BUILD,
while modification of an installed config file would result in a
BUILD increment.

However, BUILD for *you* (and other sysadmins) is whatever *you*
want it to be. 

-RW
Robby Workman | 14 Mar 19:03 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Mon, 14 Mar 2011 08:48:30 -0400
Ben Mendis <dragonwisard@...> wrote:

> On Sun, Mar 13, 2011 at 10:30 PM, Robby Workman
> <rworkman@...>wrote:
> 
> > On Sat, 12 Mar 2011 17:34:24 -0600
> > Erik Hanson <erik@...> wrote:
> >
> > > On Sat, 12 Mar 2011 23:15:54 +0000
> > > "Greg' Ar Tourter" <artourter@...> wrote:
> > >
> > > > There are quite a few packages that, although do not need to be
> > > > upgraded to work in 13.37, they need to be recompiled as the
> > > > libraries they depend on have changed.
> > > > this include all the perl modules, texlive (pdftex at least
> > > > does not work due to poppler) pdftk (due to libgcj). I suspect
> > > > there are others but it gives a good idea of the issue.
> > > >
> > > > Should be bump the build number of these package on the 13.37
> > > > repo when there isn't a new version available, to help users?
> > >
> > > Although I see your point, we haven't done this in the past, so
> > > I'm inclined to say no.
> >
> >
> > Same inclination here.   :-)
> >
> 
> Out of curiosity, what would be the potential downsides to bumping
> the build numbers?
> Is it just that it's inconsistent with previous releases, or that it
> involves a lot of work? (I'm not implying that you're lazy, I
> appreciate the valuable time you donate to helping us out.)
> Or are there some other problems that it might introduce that I'm not
> aware of?
> 
> I'd just like to understand the reasoning behind this decision.

We're lazy and it involves a lot of work, and it really doesn't
add any benefit to admins who keep well-managed systems anyway.

-RW
On Mon, 14 Mar 2011 08:48:30 -0400
Ben Mendis <dragonwisard@...> wrote:

> On Sun, Mar 13, 2011 at 10:30 PM, Robby Workman
> <rworkman@...>wrote:
> 
> > On Sat, 12 Mar 2011 17:34:24 -0600
> > Erik Hanson <erik@...> wrote:
> >
> > > On Sat, 12 Mar 2011 23:15:54 +0000
> > > "Greg' Ar Tourter" <artourter@...> wrote:
> > >
> > > > There are quite a few packages that, although do not need to be
> > > > upgraded to work in 13.37, they need to be recompiled as the
> > > > libraries they depend on have changed.
> > > > this include all the perl modules, texlive (pdftex at least
> > > > does not work due to poppler) pdftk (due to libgcj). I suspect
> > > > there are others but it gives a good idea of the issue.
> > > >
> > > > Should be bump the build number of these package on the 13.37
> > > > repo when there isn't a new version available, to help users?
> > >
> > > Although I see your point, we haven't done this in the past, so
> > > I'm inclined to say no.
> >
> >
> > Same inclination here.   :-)
> >
> 
> Out of curiosity, what would be the potential downsides to bumping
> the build numbers?
> Is it just that it's inconsistent with previous releases, or that it
> involves a lot of work? (I'm not implying that you're lazy, I
> appreciate the valuable time you donate to helping us out.)
> Or are there some other problems that it might introduce that I'm not
> aware of?
> 
> I'd just like to understand the reasoning behind this decision.

We're lazy and it involves a lot of work, and it really doesn't
add any benefit to admins who keep well-managed systems anyway.

-RW
markus reichelt | 13 Mar 00:55 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

* Greg' Ar Tourter <artourter@...> wrote:

> Should be bump the build number of these package on the 13.37 repo
> when there isn't a new version available, to help users?

I wondered about that too, but decided not to fiddle with build
numbers since the upcoming stable release is a new branch on SBo
anyway.

That said, I can tell that the scripts I maintain all work on -rc1
and thus are most likely ready to be bumped to the upcoming release
branch, namely:

libraries/Botan
system/aespipe
libraries/dietlibc
system/extundelete
libraries/libowfat
network/opera
network/sslscan
development/tcc
network/vidalia
graphics/xzgv

network/GeoIP (new maintainer)

I took the opportunity to add the missing GeoIP support to vidalia,
since I promised to also take over the GeoIP SlackBuild. Both will
run just fine on -rc1 as-is and are by no means a security update.

Whoever may need the updated SlackBuilds:

http://mareichelt.de/tmp/GeoIP.tar.gz
http://mareichelt.de/tmp/vidalia.tar.gz

HTH

-- 
left blank, right bald
* Greg' Ar Tourter <artourter@...> wrote:

> Should be bump the build number of these package on the 13.37 repo
> when there isn't a new version available, to help users?

I wondered about that too, but decided not to fiddle with build
numbers since the upcoming stable release is a new branch on SBo
anyway.

That said, I can tell that the scripts I maintain all work on -rc1
and thus are most likely ready to be bumped to the upcoming release
branch, namely:

libraries/Botan
system/aespipe
libraries/dietlibc
system/extundelete
libraries/libowfat
network/opera
network/sslscan
development/tcc
network/vidalia
graphics/xzgv

network/GeoIP (new maintainer)

I took the opportunity to add the missing GeoIP support to vidalia,
since I promised to also take over the GeoIP SlackBuild. Both will
run just fine on -rc1 as-is and are by no means a security update.

Whoever may need the updated SlackBuilds:

http://mareichelt.de/tmp/GeoIP.tar.gz
http://mareichelt.de/tmp/vidalia.tar.gz

HTH

--

-- 
left blank, right bald
Robby Workman | 14 Mar 19:01 2011

Re: [ANNOUNCE]: Slackware 13.37 rc1 and SBo

On Sun, 13 Mar 2011 00:55:39 +0100
markus reichelt <ml@...> wrote:

> * Greg' Ar Tourter <artourter@...> wrote:
> 
> > Should be bump the build number of these package on the 13.37 repo
> > when there isn't a new version available, to help users?
> 
> I wondered about that too, but decided not to fiddle with build
> numbers since the upcoming stable release is a new branch on SBo
> anyway.
> 
> That said, I can tell that the scripts I maintain all work on -rc1
> and thus are most likely ready to be bumped to the upcoming release
> branch, namely:
> 
> libraries/Botan
> system/aespipe
> libraries/dietlibc
> system/extundelete
> libraries/libowfat
> network/opera
> network/sslscan
> development/tcc
> network/vidalia
> graphics/xzgv

I've noted these as good.

> network/GeoIP (new maintainer)
> 
> I took the opportunity to add the missing GeoIP support to vidalia,
> since I promised to also take over the GeoIP SlackBuild. Both will
> run just fine on -rc1 as-is and are by no means a security update.
> 
> Whoever may need the updated SlackBuilds:
> 
> http://mareichelt.de/tmp/GeoIP.tar.gz
> http://mareichelt.de/tmp/vidalia.tar.gz

For us, these can wait until after the release :-)

-RW
On Sun, 13 Mar 2011 00:55:39 +0100
markus reichelt <ml@...> wrote:

> * Greg' Ar Tourter <artourter@...> wrote:
> 
> > Should be bump the build number of these package on the 13.37 repo
> > when there isn't a new version available, to help users?
> 
> I wondered about that too, but decided not to fiddle with build
> numbers since the upcoming stable release is a new branch on SBo
> anyway.
> 
> That said, I can tell that the scripts I maintain all work on -rc1
> and thus are most likely ready to be bumped to the upcoming release
> branch, namely:
> 
> libraries/Botan
> system/aespipe
> libraries/dietlibc
> system/extundelete
> libraries/libowfat
> network/opera
> network/sslscan
> development/tcc
> network/vidalia
> graphics/xzgv

I've noted these as good.

> network/GeoIP (new maintainer)
> 
> I took the opportunity to add the missing GeoIP support to vidalia,
> since I promised to also take over the GeoIP SlackBuild. Both will
> run just fine on -rc1 as-is and are by no means a security update.
> 
> Whoever may need the updated SlackBuilds:
> 
> http://mareichelt.de/tmp/GeoIP.tar.gz
> http://mareichelt.de/tmp/vidalia.tar.gz

For us, these can wait until after the release :-)

-RW

Gmane