Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Ruben Schuller
Hi! Just my two cents: I don't think that SlackBuilds on SBo are that outdated. Most of the time they are a rather new version. I'm guilty myself for not updating some of my SlackBuilds that often ;) Like some others posted here, I think that Gitlab (or something like that) would make updating

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Nicolas Kovacs
Le 21/01/2017 à 12:32, Andrzej Telszewski a écrit : > I'm really having hard times finding major problems with SBo, both as a > maintainer and user. Same here. SBo obeys to the KISS principle pretty much like its Slackware foundation. Recently I was annoyed by VirtualBox lagging several versions

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Andrzej Telszewski
On 21/01/17 12:21, David Spencer wrote: this is the first problem, as most of the times there aren't any pull request but "hey, X has been updated to W.Y.Z, update it ASAP!" I know you have had some bad experiences with pull requsts into your unofficial -current repository. But if we listen

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Matteo Bernardini
2017-01-21 12:21 GMT+01:00 David Spencer : >> this is the first problem, as most of the times there aren't any pull >> request but "hey, X has been updated to W.Y.Z, update it ASAP!" > > I know you have had some bad experiences with pull requsts into your >

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread David Spencer
> this is the first problem, as most of the times there aren't any pull > request but "hey, X has been updated to W.Y.Z, update it ASAP!" I know you have had some bad experiences with pull requsts into your unofficial -current repository. But if we listen to the idea behind Harald's suggestion,

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Andrzej Telszewski
On 21/01/17 11:56, Harald Achitz wrote: ok, slowly, one more time 1) the one who is sending the pull request 2) the one who is applying the pull request 3) those who use the package in testing, 4) merging testing into stable at the time a package can be considered as tested, eg due to positive

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Harald Achitz
there are no pull request because of missing chances , high entry barriers , ask the maintainer, and similar I am talking about projects that reduced work for 1 persons, as mentioned, and now I quit with this, I gave you knowledge,f feel free to ignore or discuss it to death, have a nice weekend

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Matteo Bernardini
2017-01-21 11:56 GMT+01:00 Harald Achitz : > ok, slowly, one more time > 1) the one who is sending the pull request this is the first problem, as most of the times there aren't any pull request but "hey, X has been updated to W.Y.Z, update it ASAP!" > 2) the one who is

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Andrzej Telszewski
On 21/01/17 11:56, Harald Achitz wrote: ok, slowly, one more time 1) the one who is sending the pull request 2) the one who is applying the pull request 3) those who use the package in testing, 4) merging testing into stable at the time a package can be considered as tested, eg due to positive

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Harald Achitz
ok, slowly, one more time 1) the one who is sending the pull request 2) the one who is applying the pull request 3) those who use the package in testing, 4) merging testing into stable at the time a package can be considered as tested, eg due to positive feedback on a issue tracer. more quality

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread David Spencer
> maybe it's me but I still can't understand also from this answer who's > gonna do the QA... If it's the maintainer, why would they respond to a pull request if they don't respond to email? If it's anybody, how do we (the community) know they have done enough tests, follow upstream mailing

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Matteo Bernardini
2017-01-21 11:42 GMT+01:00 Harald Achitz : > as mentioned in the earlier mail, for example > stable , testing, pull requests into testing, who wants can test, if no > problem reports, or some people say OK, (to be defined) it goes to stable. > the QA happens twice, once

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Harald Achitz
as mentioned in the earlier mail, for example stable , testing, pull requests into testing, who wants can test, if no problem reports, or some people say OK, (to be defined) it goes to stable. the QA happens twice, once when apply the pull request,similar what is already done today, so no more

Re: [Slackbuilds-users] Package versions

2017-01-21 Thread Andrzej Telszewski
On 21/01/17 08:21, Harald Achitz wrote: Hi, help is difficult, the SBo rules are clear, If you sent an updated version of a package, you need the OK of the maintainer. If you contact a maintainer, and there is no response, what than? This is a barrier, unnecessary. Git stable & testing, branch.

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Harald Achitz
Hi, help is difficult, the SBo rules are clear, If you sent an updated version of a package, you need the OK of the maintainer. If you contact a maintainer, and there is no response, what than? This is a barrier, unnecessary. Git stable & testing, branch. pull requests to testing, when some have

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Klaatu
On 21/01/17 06:12, Erik Hanson wrote: > On Fri, 20 Jan 2017 18:42:29 +1300 > Klaatu wrote: > >> I was under the impression that SlackBuilds.org mimicked Slackware >> itself in update policy: release, and then it's primarily up to the >> user to adapt the build scripts if

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread LukenShiro
Il giorno Thu, 19 Jan 2017 12:46:46 -0500 "Full Name" ha scritto: > Having said that, all too often maintainers do not update the > software all that promptly. It is not uncommon to have Slackbuilds > packages that are several releases behind what one can get from >

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Franzen
I contacted the maintainer of the qt build, no reply. This is not good. This picks up the initial post. The "mail the maintainer"-policy might not be efficient enough. Maybe a request-file per maintainer in git could help -the maintainer to keep track what has to be done -the

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Harald Achitz
Here my 2 cents Here is a list of files changed from Qt 5.6.1 to 5.6.2 each of the files contain a list of bugs. 5.6.2 has been release in October, this is quite a while ago. A update of Qt LTS is not about having the latest and greatest, it is about updating a package with known bugs against a

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Erik Hanson
On Fri, 20 Jan 2017 18:42:29 +1300 Klaatu wrote: > I was under the impression that SlackBuilds.org mimicked Slackware > itself in update policy: release, and then it's primarily up to the > user to adapt the build scripts if further maintenance is required. > That's why

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Andrzej Telszewski
On 20/01/17 08:18, x80 wrote: I'll add my thoughts as amusement for the group here. As a happy user of Slackware64 14.1 and a Linux user for almost 25 years when I access the slackbuilds repo for a build script I expect it to work, period. The last package I downloaded was the build script for

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Nicolas Kovacs
Le 19/01/2017 à 18:46, Full Name a écrit : > Having said that, all too often maintainers do not update the > software all that promptly. It is not uncommon to have Slackbuilds > packages that are several releases behind what one can get from > distributions like (shudder) Fedora or (shudder!)

Re: [Slackbuilds-users] Package versions

2017-01-20 Thread Petar Petrov
> If SlackBuilds.org is going to follow -current, then maybe there ought > to be a separate git branch for -current? That way I can pull in new > buildscripts without updating old buildscripts out from under me. I am _not_ following -current, nor am I going to. -petar

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Shane Kelly
>On 20/01/17 07:01, Ryan P.C. McQuen wrote: >> On 1/19/17, Full Name wrote: >>> As a long time user of Slackware, I am immensely grateful to the >>> people who have volunteered (and continue to do so) their time and >>> effort to maintain and update third-party code,

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread x80
On 01/19/2017 09:42 PM, Klaatu wrote: On 20/01/17 07:01, Ryan P.C. McQuen wrote: On 1/19/17, Full Name wrote: As a long time user of Slackware, I am immensely grateful to the people who have volunteered (and continue to do so) their time and effort to maintain

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Klaatu
On 20/01/17 07:01, Ryan P.C. McQuen wrote: > On 1/19/17, Full Name wrote: >> As a long time user of Slackware, I am immensely grateful to the people who >> have volunteered (and continue to do so) their time and effort to maintain >> and update third-party code, so

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Ryan P.C. McQuen
http://repology.org/ I’m going to have to level up on my maintaining :( What I hate about tools like these, is for packages like nodejs, we are shown as out-of-date, when in actuality we have the very latest LTS version. You’d be crazy to run a non-LTS node server, but alas … it is helpful for a

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Gerardo Zamudio
On 01/19/2017 07:01 PM, David Spencer wrote: > Blimey. This is new ... and *very* scary > > http://repology.org/ > > I'm going to have to level up on my maintaining :( > -D. > > I like to think they're doing me a favor and keeping track of my packages for me. Beats the sbo.txt I keep in ~

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread David Spencer
Blimey. This is new ... and *very* scary http://repology.org/ I'm going to have to level up on my maintaining :( -D. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Matthew Fillpot
I am currently guilty of not recently updating my builds, but will act promptly if i receive a report. With that being said, there are exceptions in which i will delay or skip an update. My preference is to test each new release for at least 2 weeks for stability and to watch bug reports before

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Ryan P.C. McQuen
On 1/19/17, Eric Pratt wrote: > I know I'm definitely guilty of letting my slackbuilds slip for long > periods of time. I'm trying to prevent that moving forward, but it's > really mostly a matter of getting the time to do it and remembering to do > it. So I like the

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Eric Pratt
I know I'm definitely guilty of letting my slackbuilds slip for long periods of time. I'm trying to prevent that moving forward, but it's really mostly a matter of getting the time to do it and remembering to do it. So I like the auto-updating idea. It would get many of us past the remembering

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Andrzej Telszewski
On 19/01/17 19:45, David Spencer wrote: As a radical idea, we could consider making some packages auto-updating. I suspect lots of perl, python, haskell and ruby could be completely automated. I bet everybody hates this idea :p You bet ;-) On the other hand, George from Salix made a very

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread David Spencer
A few constructive thoughts -- Many years ago the advice was that we should not always update our SlackBuilds for simple version bumps, because it's easy to use VERSION=. But I think times have changed, git makes the whole process easier for the admins and we are always happy to see updates. The

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Reedych
I think that slackware is easiers from ubuntu. That's my experience. Updates? Slackware's more stable. Need additional software? Slackbuilds.org. Yes, maintainers can don't update his software, but in 95% only VERSION variable update is needed. 19 янв. 2017 г. 23:46 пользователь Full Name

Re: [Slackbuilds-users] Package versions

2017-01-19 Thread Ryan P.C. McQuen
On 1/19/17, Full Name wrote: > As a long time user of Slackware, I am immensely grateful to the people who > have volunteered (and continue to do so) their time and effort to maintain > and update third-party code, so that the rest of us Slackware users can >