SBo scripts not building on current (read 1st post, pls)

moesasji · 06-12-2016, 03:07 AM

Quote:

Originally Posted by montagdude

It looks like the SlackBuild for password-store hasn't been updated in a very long time, because the version on master is 4 years old.

...outdated packages is indeed very common for anything not that mainstream. Is there an efficient way to flag up what requires updating (for things where it does matter)?

Examples:
1) msmtp (https://slackbuilds.org/repository/1...twork/msmtp/); the current stable is at 1.6.5, while slackbuild is at 1.4.31. As the older version might have SSL embedded it seems not be a good idea to have it >2 years out of date. I'm running 1.6.3 at the moment and works fine, i.e. simple version bump.

2) Julia (https://slackbuilds.org/repository/1...opment/julia); latest stable is at 0.4.5. The version on 0.3.3 SBo is no longer supported upstream.

3) btsync (https://slackbuilds.org/repository/14.1/network/btsync/) current stable is at 2.3.7 vs the 1.4.110 on SBo. Although in this specific case there might be motivation to keep the older one. I never installed it in the end, so not sure.

btw) In particular for packages that are not that mainstream contacting the listed maintainer gets no response in my experience.

ponce · 06-12-2016, 03:39 AM

you might not receive the latest versions also for specific reasons (incompatibilities or such), but if you test an upgrade and report that it's functional and it doesn't cause regressions for anything depending on it to its maintainer then it's his job to answer you, motivating.

I don't say at all it's your case, but if someone writes me for a package I'm maintaining telling me "version X of foo is out" and he hasn't tested it at all for anything above and I am aware that there are incompatibilities and such, it could happen that I don't answer too (also if I gave specific answers about foo multiple times in the past).

but let's suppose someone report updates to the maintainer in a useful way: in that case, if the maintainer doesn't answer in a reasonable period of time (one month?), the reporter should post the same request on the slackbuilds-users mailing list, still putting the maintainer in cc, also specifing if he wants to step on maintaining, and then one of the admins will take care of it.

Quote:

Originally Posted by moesasji

btw) In particular for packages that are not that mainstream contacting the listed maintainer gets no response in my experience.

you should report these cases.

55020 · 06-12-2016, 04:17 AM

Quote:

Originally Posted by moesasji

btw) In particular for packages that are not that mainstream contacting the listed maintainer gets no response in my experience.

So your next step is to tell us on the mailing list that the maintainer has not responded, preferably with an offer to become the new maintainer.

SBo has almost no barrier to participation (which is something to be proud of) so there are going to be some maintainers who help the community on just one occasion and then move on. The constant turnover of new maintainers with new ideas is really valuable and if you want to participate you'll be welcome.

Quote:

Originally Posted by moesasji

Is there an efficient way to flag up what requires updating (for things where it does matter)?

We have no technical solution for that. Fedora has some form of scraper iirc, in Arch it's manual. Once an update is noticed, it's a human judgment call whether the update is good (compatibilty, stability, functionality, security).

Since SlackBuilds are trivially usable with a new version number, mere version bumps are no big deal if they 'just work'.

Please feel free to suggest how SBo could do better on any of this.

moesasji · 06-12-2016, 05:55 AM

Quote:

Originally Posted by 55020

Please feel free to suggest how SBo could do better on any of this.

Personally I'm not convinced that the sequence of contacting the "listed" maintainer, waiting a month and sending an alert to the mailing-list works that well for packages with a small user-base. I for example would not remember a month later...

In my opinion having the option to have packages not explicitly maintained by a person would be an improvement for some of these types of packages. That way the person upfront gives an indication how much time they have to keep an eye on it. I would have opted for that option for some that I submitted. This also dramatically lowers the threshold to submit a bumb-request after testing it works as that way it is clear that effectively there is no maintainer so no need to wait.

btw) yes I've went through the cycle, although I didn't step up to maintain. Searching for syncthing on the mailing-list might illustrate.

55020 · 06-12-2016, 06:09 AM

I've been wondering for a while whether to suggest this: maybe when a maintainer has stepped down, in the .info file we could have MAINTAINER="SlackBuilds Community" and EMAIL="slackbuilds-users@slackbuilds.org" (which describes the true situation better than "unmaintained") -- and then anybody could submit updates (subject to approval), or (better still) step up to become a new maintainer.

suppy · 06-12-2016, 06:11 AM

Quote:

Originally Posted by moesasji

Personally I'm not convinced that the sequence of contacting the "listed" maintainer, waiting a month and sending an alert to the mailing-list works that well for packages with a small user-base. I for example would not remember a month later...

In my opinion having the option to have packages not explicitly maintained by a person would be an improvement for some of these types of packages. That way the person upfront gives an indication how much time they have to keep an eye on it. I would have opted for that option for some that I submitted. This also dramatically lowers the threshold to submit a bumb-request after testing it works as that way it is clear that effectively there is no maintainer so no need to wait.

btw) yes I've went through the cycle, although I didn't step up to maintain. Searching for syncthing on the mailing-list might illustrate.

All this sounds like a great idea to me. I'd very much approve.

ponce · 06-12-2016, 06:19 AM

Quote:

Originally Posted by moesasji

Personally I'm not convinced that the sequence of contacting the "listed" maintainer, waiting a month and sending an alert to the mailing-list works that well for packages with a small user-base. I for example would not remember a month later...

IHMO that shouldn't be an issue with all the accessible schedulers available (not to suggest anything in particular, but I use google calendar a lot).

Quote:

In my opinion having the option to have packages not explicitly maintained by a person would be an improvement for some of these types of packages. That way the person upfront gives an indication how much time they have to keep an eye on it. I would have opted for that option for some that I submitted. This also dramatically lowers the threshold to submit a bumb-request after testing it works as that way it is clear that effectively there is no maintainer so no need to wait.

well, I'm personally against that basically because whenever scripts get unmaintained then they become an additional burden for SBo's admins, that maybe aren't so into that particular piece of software so they might not be aware, for example, of security problems with the version on the repository...
I think we want scripts to have a maintainer.

Don't get me wrong, but I also think it's better to discuss these kind of things not here on LQ on a topic dedicated to an unofficial fork of the SBo's repository for current, but on SBo's mailing list, so that admins and maintainers can follow the topic and express their opinion.

montagdude · 06-12-2016, 08:08 AM

In the future should I first try emailing the listed maintainer about severely out of date packages? You guys are always very responsive to implementing fixes in general, so I've been turning to this thread first to report any issues.

I understand this thread is for -current only, so to me it makes sense that new versions of severely outdated packages would be updated here first.

ponce · 06-12-2016, 08:44 AM

Quote:

Originally Posted by montagdude

In the future should I first try emailing the listed maintainer about severely out of date packages? You guys are always very responsive to implementing fixes in general, so I've been turning to this thread first to report any issues.

I understand this thread is for -current only, so to me it makes sense that new versions of severely outdated packages would be updated here first.

the logic that sould make people report any issue on this topic is if it's current-specific and if it's not already fixed in the unofficial repository.
following this, possible updates belong to the mailing list as also users of the stable repository could benefit of the eventual upgrades.

montagdude · 06-12-2016, 03:28 PM

OK, I just signed up for the mailing list. I'll use that in the future to report out of date packages.

kjhambrick · 06-17-2016, 01:21 AM

All --

The Battery in one of my APC (not so) Smart UPS's went out this evening ( APC BackUps ES 450 ).

I had to build and install apcupsd so I could run apctest Option 6 to turn off the infernal alarm

Anyhow, apcupsd-3.14.14.tar.gz is now available from sourceforge:

http://downloads.sourceforge.net/apc...3.14.14.tar.gz

I checked the .sig -- it passed OK on my system ... used a self-generated md5sum to validate the .tar.gz file after testing the .sig

# cat apcupsd-3.14.14.tar.gz.md5

Code:

cc8f5ced77f38906a274787acb9bc980  apcupsd-3.14.14.tar.gz

Built and installed fine.

Robbie's README.SLACKWARE File still appears to be applicable but I did not test it because all I needed was the apctest app to turn off the alarm.

I did chmod 644 etc/rc.d/rc.apcupsd and I did not modify /etc/rc.d/rc.local nor the /etc/rc.d/rc.6 scripts because I don't need / want the daemon running ...

Thanks all !

-- kjh

p.s. to talk to the UPS via the APC USB-RJ11 Cable, I had to edit /etc/apcupsd/apcupsd.conf and change:

Code:

UPSCABLE smart
UPSTYPE usb

Otherwise it defaults to /dev/ttyS0.

Edit2: I installed apcupsd-3.14.13 before I tried the 3.14.14 and I just noticed there is a /etc/apcupsd/apcupsd.conf.new file which is properly configured !

montagdude · 06-18-2016, 10:25 PM

I was just poking around and I came across this typo in gis/polyline.SlackBuild:

Code:

PRGNAM=polyline
VERSION=${VERS2ON:-1.1}
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}

rworkman · 06-18-2016, 10:42 PM

Quote:

Originally Posted by montagdude

I was just poking around and I came across this typo in gis/polyline.SlackBuild:

Code:

PRGNAM=polyline
VERSION=${VERS2ON:-1.1}
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}

Code:

commit 308617048fa4dccc521fd53d4e1f9be0e568e2a7
Author: Robby Workman <rworkman@slackware.com>
Date:   Sat Jun 18 22:41:36 2016 -0500

    gis/polyline: Fixed type in VERSION string of build script
    
    Thanks to montagdude on LQ.

diff --git a/gis/polyline/polyline.SlackBuild b/gis/polyline/polyline.SlackBuild
index 6df4f34..d7fe8e6 100644
--- a/gis/polyline/polyline.SlackBuild
+++ b/gis/polyline/polyline.SlackBuild
@@ -23,7 +23,7 @@
 #  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 PRGNAM=polyline
-VERSION=${VERS2ON:-1.1}
+VERSION=${VERSION:-1.1}
 BUILD=${BUILD:-1}
 TAG=${TAG:-_SBo}

montagdude · 06-18-2016, 10:56 PM

Thanks for fixing it so quickly.

brobr · 06-23-2016, 04:39 AM

QT-5 source is not downloadable as given in the SBo script;

Quote:

The requested URL /official_releases/qt/5.6/5.6.1/single/qt-everywhere-opensource-src-5.6.1.tar.xz was not found on this server.

new: http://download.qt.io/official_relea...5.6.1-1.tar.xz

the addition of "-1" also needs a change in the script as it is only needed at the unpacking-step.

Rob