Re: [Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Kyle Guinn]

On 11/4/16, David Spencer  wrote:
> Hi - let me say to start that this is only a personal opinion, and
> I've been too busy recently to pay careful attention to this
> discussion. But IIRC we've talked about this before.  In my opinion,
> real life is much too complex for OPTIONAL=
>
> Look at this example (graphics/luminance-hdr)
>
>> The following are optional dependencies:
>> cfitsio and CCfits - for importing FITS images (both needed)
>> hugin  - for aligning multiple LDR exposures
>
> And this example (gis/gdal):
>
>> The following optional requirements are detected automatically:
>> cfitsio, freexl, hdf, hdf5, libwebp, netcdf, postgresql, xerces-c
>>
>> To enable OpenCL GPU-accelerated performance, specify the option
>> OPENCL=yes (requires opencl-headers to build, and either nvidia-driver
>> or amd-app-sdk with suitable GPU hardware to run).
>
> Users need to know what useful features each dep provides, if that
> information is available upstream.
>
> Users need to know if some deps are needed together (like cfitsio and
> CCfits above), or if some deps are mutually exclusive (like
> nvidia-driver and amd-app-sdk above).
>
> Some users want to know if deps are build-time only, or run-time only.
>
> Users need to know whether deps are automatically detected, or whether
> there are environment variables that need to be set.  (Not all
> SlackBuilds use environment variables in the same way, and some
> SlackBuilds would need to be rewritten if we standardised on (for
> example) OPTIONAL="libass:ASS=yes|no libbluray:BLURAY=yes|no".  Who's
> going to find them all?  Who's going to fix them all?  Who's going to
> change all the users' queue files and build scripts?)
>
> And some users (ok, me) don't like XML, and don't like YAML, and don't
> like new stuff such as "[opt]libass[/opt]" that I'd have to write a
> parser for from scratch when XML and YAML already exist, and don't
> like reading stuff that's complicated. I don't think anybody -- either
> maintainers or users -- would enjoy having half the README file or the
> .info file written in YAML, but that's the kind of thing that would be
> needed if you look at all the real examples in SBo.
>
> IMO it's best to read all ~5800 README files before thinking about a
> solution. I've done it. It's quite easy to spot the interesting ones
> if you step through them quickly.
>
> Cheers
> -D.

I like the idea of having an OPTIONAL field because it could allow us
to have clickable links on the website, and you could use it to build
a better dependency graph.  So for example if I'm updating a library
and want to know what packages might be using it, searching through
both REQUIRES and OPTIONAL could turn up a lot more hits than REQUIRES
alone.  It'd also be much more accurate than searching through README.

I'm not a fan of putting script parameters in OPTIONAL, I think that
would turn into a mess in a hurry.  Better to keep that info in the
README, and just keep OPTIONAL as a list of packages just like
REQUIRES.  Basically if any optional package is mentioned in the
README, also put it in OPTIONAL just to establish a link between the
two.


This is somewhat off-topic, but I remember discussions in the past
that the file is called README because you need to read it.  But I'm
sure we're all guilty of not reading it at some point.  I usually
don't, thinking that it just contains the package description, and if
I'm installing it I already have an idea of what it does and why I
need it.  Then I realize there may be installation information I'm
missing, so I go back and read it.

What do you think about splitting off the package description into its
own file (named "ABOUT" or somesuch)?  ABOUT would contain the
description (maybe just a repeat of slack-desc, or something longer
and more detailed).  README would contain package conflicts, more info
about optional dependencies and what they would provide, script
variables, pre-build or post-build instructions, etc.  The README file
itself would be optional in case there are no extra instructions, but
if it exists you should read it!  Each package should contain at least
one of the two files, the website would show both, and descriptions
could slowly be migrated to the ABOUT file at the maintainer's
leisure.  Any opinions?

-Kyle
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] ffmpeg and tetex

[Daniel Prosser]

(This is a copy of the message I accidentally sent as a reply to a
different thread. Please respond to this one.)

Hi,

I am installing ffmpeg on a clean 14.2 system (well, actually I am
installing vlc in order to test something, and ffmpeg is a dependency,
but that's not important). I have tetex installed instead of texlive,
and I get the following error:

Could not find texi2html! Please make sure to have tetex or texlive
installed and that texi2html is in PATH.

The message is clear enough: the problem is that texi2html is not in
the
PATH. I checked the install log for tetex and found that it is in
/usr/share/texmf/bin, so I made a symlink for it in /usr/bin. Is this
situation expected? IMO it is not a great solution, because ideally
any
given package on SBo *should* build properly on a clean system
provided
all the dependencies are present, without having to manually create
symlinks or modify the PATH. Someone new to Linux and/or Slackware,
for
example, would probably be stuck. At the very least, the README for
ffmpeg should make it clear how to get around the problem.

Or am I missing something?

Dan
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] ffmpeg and tetex

[Daniel Prosser]

I'm sorry, that was not supposed to be a reply to the OPTIONAL thread. I
will re-send it as a new message.

Dan

On Sat, Nov 05, 2016 at 02:23:13AM +, Daniel Prosser wrote:
> Hi,
> 
> I am installing ffmpeg on a clean 14.2 system (well, actually I am
> installing vlc in order to test something, and ffmpeg is a dependency,
> but that's not important). I have tetex installed instead of texlive,
> and I get the following error:
> 
> Could not find texi2html! Please make sure to have tetex or texlive
> installed and that texi2html is in PATH.
> 
> The message is clear enough: the problem is that texi2html is not in the
> PATH. I checked the install log for tetex and found that it is in
> /usr/share/texmf/bin, so I made a symlink for it in /usr/bin. Is this
> situation expected? IMO it is not a great solution, because ideally any
> given package on SBo *should* build properly on a clean system provided
> all the dependencies are present, without having to manually create
> symlinks or modify the PATH. Someone new to Linux and/or Slackware, for
> example, would probably be stuck. At the very least, the README for
> ffmpeg should make it clear how to get around the problem.
> 
> Or am I missing something?
> 
> Dan
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] ffmpeg and tetex

[Daniel Prosser]

Hi,

I am installing ffmpeg on a clean 14.2 system (well, actually I am
installing vlc in order to test something, and ffmpeg is a dependency,
but that's not important). I have tetex installed instead of texlive,
and I get the following error:

Could not find texi2html! Please make sure to have tetex or texlive
installed and that texi2html is in PATH.

The message is clear enough: the problem is that texi2html is not in the
PATH. I checked the install log for tetex and found that it is in
/usr/share/texmf/bin, so I made a symlink for it in /usr/bin. Is this
situation expected? IMO it is not a great solution, because ideally any
given package on SBo *should* build properly on a clean system provided
all the dependencies are present, without having to manually create
symlinks or modify the PATH. Someone new to Linux and/or Slackware, for
example, would probably be stuck. At the very least, the README for
ffmpeg should make it clear how to get around the problem.

Or am I missing something?

Dan
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Best place to install the EasyRSA scripts?

[Thomas Szteliga]

On 11/05/2016 01:56 AM, Rob McGee wrote:
> At least 3 problems I see with that as it implies:
>   1. that you have your CA on an openvpn server or client;
>   2. that you will be running these scripts as root;
>   3. that your CA is limited to use for openvpn.
> #1 is the big one, because that promotes insecure user practices; 
> Slackbuilds.org MUST NOT do that.



I'm aware. I have a separated isolated VM just for generating
CA's, keys and testing configs for multiple servers/clients.



> Admittedly I have never been in the position of having to support 
> multiple servers, but I'd still only maintain a single CA for all of 
> them in any given organization.  If you need to restrict access on 
> any given server, use a --client-config-dir and --ccd-exclusive 
> (touch a file in the CCD for any permitted client's commonName on 
> that server instance.)



I have individual CA's for each server, even when in a single
organization and of course if clients of a single server
need individual settings ccd's are used.


> Hehe, actually I don't have any strong feelings against this 
> suggestion.  It's as good as any.


I think /usr/doc/easy-rsa is way better than /usr/doc/easy-rsa-
/usr/libexec somehow feels really wrong.


CentOS: /usr/share/easy-rsa/
Archlinux: /etc/easy-rsa
FreeBSD: /usr/local/share/easy-rsa


>> and users will have to copy the contents of /usr/share/easyrsa
>> to a writable location like /etc/openvpn/server/server1/easyrsa
> Eeek!  How about /home/ca/ ?


Oh no, really, a user for each CA? ;-)


And just another fun-fact ;-)


If you are using Linux, BSD, or a unix-like OS, open a shell and cd to
the easy-rsa subdirectory. If you installed OpenVPN from an RPM or DEB
file, the easy-rsa directory can usually be found in
/usr/share/doc/packages/openvpn or /usr/share/doc/openvpn (it's best to
copy this directory to another location such as /etc/openvpn, before any
edits, so that future OpenVPN package upgrades won't overwrite your
modifications). If you installed from a .tar.gz file, the easy-rsa
directory will be in the top level directory of the expanded source tree.


Again:

"it's best to copy this directory to another location such as
/etc/openvpn" :-


It's from the official howto:
https://openvpn.net/index.php/open-source/documentation/howto.html



-- 
Thomas Szteliga




smime.p7s
Description: S/MIME Cryptographic Signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Best place to install the EasyRSA scripts?

[Rob McGee]

On Fri, Nov 04, 2016 at 11:23:06PM +0100, Thomas Szteliga wrote:
> On 11/04/2016 12:02 PM, Sebastian Arcus wrote:
> > I am making the SBo scripts for EasyRSA, and I need to decide 
> > where they will be installed. Before they were removed from 
> > Slackware - when they were part of Openvpn, I think they used to 
> > go under /usr/share/doc/openvpn. However, it seems a bit strange 
> > to install a package in the directory of another package. Maybe 
> > /usr/share/doc/easyrsa instead? However, they are sample scripts 
> > - not really documentation. According to Linux filesystem 
> > standards, would there be a better place? Maybe /usr/share 
> > directly, or /us/lib or something?
> 
> It was very handy to have them in /etc/openvpn/...

Eeek!  Why?

At least 3 problems I see with that as it implies:
  1. that you have your CA on an openvpn server or client;
  2. that you will be running these scripts as root;
  3. that your CA is limited to use for openvpn.

#1 is the big one, because that promotes insecure user practices; 
Slackbuilds.org MUST NOT do that.

> EasyRSA scripts will create keys in the `keys` subdir,
> so /usr/share and /usr/doc are probably not the best location
> without patching KEY_DIR in easyrsa/*/vars to point
> to a more reasonable location
> 
>   export KEY_DIR="$EASY_RSA/keys"
> 
> But this still should not be an absolute path,
> because when you're running multiple openvpn servers
> you would normally have something like:
> 
> /etc/openvpn/server/server1/easyrsa/*/keys
> /etc/openvpn/server/server2/easyrsa/*/keys
> /etc/openvpn/server/server3/easyrsa/*/keys

Ewww, really, why?

First thing, see above.  Also a server only needs ITS OWN KEY, it 
does not need (and should not have!) any other keys.

Admittedly I have never been in the position of having to support 
multiple servers, but I'd still only maintain a single CA for all of 
them in any given organization.  If you need to restrict access on 
any given server, use a --client-config-dir and --ccd-exclusive 
(touch a file in the CCD for any permitted client's commonName on 
that server instance.)

> and a patched KEY_DIR would place all keys by default
> in one directory. That's not what you want (with multiple servers).
> 
> 
> So after rethinking this my suggestion is:
> 
> 
>  /usr/share/easyrsa without patching KEY_DIR (keys placed in subdir)

Hehe, actually I don't have any strong feelings against this 
suggestion.  It's as good as any.

> and users will have to copy the contents of /usr/share/easyrsa
> to a writable location like /etc/openvpn/server/server1/easyrsa

Eeek!  How about /home/ca/ ?
-- 
Rob McGee - /dev/rob0 - r...@slackbuilds.org
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Updates - 20161105.1

[Willy Sudiarto Raharjo]

Sat Nov  5 00:17:41 UTC 2016
academic/gwyddion: Add more patches.
audio/sayonara-player: Updated for version 0.9.2-git11.
audio/snd: Updated for version 16.9.
audio/sunvox: Updated for version 1.9.2.
audio/volti: Switch to github release.
desktop/ComixCursors: Updated for version 0.9.0.
desktop/lumina: Fix VERSION.
desktop/neofetch: Updated for version 1.9.
desktop/numix-gtk-theme: Updated for version 2.6.5.606.201610230531.
desktop/numix-pack: Updated for version 0.4.1.
desktop/py3status: Updated for version 3.2.
desktop/wbar: Fix DOWNLOAD.
desktop/xed: Updated for version 1.2.0.
development/Bottleneck: Updated for version 1.2.0.
development/atom: Update script.
development/ccl: Added (Clozure Common Lisp).
development/dmd: Updated for version 2.072.0.
development/flow: Updated for version 0.34.0.
development/gambas3: Updated for version 3.9.1.
development/gtest: Updated for version 1.8.0.
development/gtkdialog: Updated for version 0.8.3.
development/maude: Added (high-performance reflective language).
development/menhir: Updated for version 20160825.
development/mutagen: Updated for version 1.35.
development/neovim: Updated for version 0.1.6.
development/p4v: Updated for version 2015.2.1458499.
development/perf: Updated for version 4.4.29.
development/poedit: Updated for version 1.8.11.
development/sbcl: Updated for version 1.3.11.
development/valgrind: Updated for version 3.12.0.
games/atanks: Updated for version 6.5.
games/domination: Use ARCH=noarch.
games/doomretro: Updated for version 2.3.3.
games/mame: Updated for version 0.179.
games/opendune: Added (realtime strategy game).
games/ppsspp: Update script.
games/snes9x: Fix MD5SUM.
games/stockfish: Added (UCI chess engine).
gis/opencpn: Update DEP and README.
gis/qgis: Updated for version 2.18.0.
graphics/pngcrush: Updated for version 1.8.10.
graphics/tintii: Updated for version 2.10.0.
libraries/audioread: Updated for version 2.1.4.
libraries/buddy: Added (Binary Decision Diagram library).
libraries/daq: Force -j1.
libraries/fuzzylite: Updated for version 5.1.
libraries/libfilezilla: Updated for version 0.8.0.
libraries/libfixposix: Added (Thin wrapper over POSIX syscalls).
libraries/libtecla: Added (interactive command line editing).
libraries/live555: Updated for version 2016.11.03
libraries/poco: Updated for version 1.7.6.
libraries/pycparser: Updated for version 2.17.
libraries/python-gnupg: Updated for version 0.3.9.
libraries/toro: Updated for version 1.0.1.
misc/KeePassHttp: Added (plugin for KeePass).
multimedia/MP3Diags: Add missing doinst.sh.
multimedia/gaupol: Updated an optional dependency in the README.
multimedia/mkvtoolnix: Updated for version 9.5.0.
multimedia/opera-ffmpeg-codecs: Added (Extra ffmpeg codec).
multimedia/pepperflash-plugin: Updated for version 23.0.0.205.
multimedia/spotify: Updated for version 1.0.42.145.g7a5a182e.
network/Electrum-DASH: Added (dash client).
network/PaleMoon: Update MD5SUM.
network/SoulseekQt: Added (Soulseek P2P network client).
network/bitcoin: Updated for version 0.13.1.
network/boxcryptor: Updated for version 2.2.410.162.
network/filezilla: Updated for version 3.22.2.
network/lighttpd: Updated for version 1.4.43.
network/mpop: Updated for version 1.2.5.
network/ncrack: Added (network authentication cracking tool).
network/nsd: Added (Name Server Daemon).
network/opera-developer: Update README and script.
network/opera: Added (Fast and secure web browser).
network/otter: Updated for version 0.9.11.
network/retroshare: Update script.
network/suricata: Updated for version 3.1.3.
network/tor: Updated for version 0.2.8.9.
network/wire: Updated for version 2.11.2665.
office/CherryTree: Updated for version 0.37.6.
office/LanguageTool: Updated for version 3.5.
office/LibreOffice: Updated for version 5.2.3.3
office/libreoffice-helppack: Updated for version 5.2.3.
office/libreoffice-langpack: Updated for version 5.2.3.
office/libreoffice: Updated for version 5.2.3.
office/lyx: Updated for version 2.2.2.
office/multivalent-tool-pdf: Added (PDF tools).
office/rednotebook: Updated an optional dependency in the README.
office/texlive-docs: Updated for version 2016.161031.
office/texlive-extra: Updated for version 2016.161031.
office/texlive-fonts: Updated for version 2016.161031.
office/texlive: Updated for version 2016.161031.
perl/perl-Math-GMPz: Updated for version 0.44.
python/Flask: Updated for version 0.11.1.
python/colored: Updated for version 1.3.2.
python/cssutils: Updated an optional dependency in the README.
python/mnemonic: Added (reference implementation of BIP-0039).
python/ndg_httpsclient: Updated for version 0.4.2.
python/pendulum: Updated for version 0.6.5.
python/psutil: Updated for version 4.4.1
python/python-x11_hash: Added (Python Module).
python/sge-pygame: Updated for version 1.3.
python/simplejson: Updated for version 3.10.0
python/tqdm: Updated for version 4.9.0.
python/trezor: Added (Bitcoin Hardware Wallet).
ruby/heroku-client: Update MD5SUM.
system/I-Nex: Updated for version 7.6.0.

Re: [Slackbuilds-users] Best place to install the EasyRSA scripts?

[Thomas Szteliga]

On 11/04/2016 12:02 PM, Sebastian Arcus wrote:
> I am making the SBo scripts for EasyRSA, and I need to decide where they
> will be installed. Before they were removed from Slackware - when they
> were part of Openvpn, I think they used to go under
> /usr/share/doc/openvpn. However, it seems a bit strange to install a
> package in the directory of another package. Maybe
> /usr/share/doc/easyrsa instead? However, they are sample scripts - not
> really documentation. According to Linux filesystem standards, would
> there be a better place? Maybe /usr/share directly, or /us/lib or
> something?


It was very handy to have them in /etc/openvpn/...

EasyRSA scripts will create keys in the `keys` subdir,
so /usr/share and /usr/doc are probably not the best location
without patching KEY_DIR in easyrsa/*/vars to point
to a more reasonable location

export KEY_DIR="$EASY_RSA/keys"

But this still should not be an absolute path,
because when you're running multiple openvpn servers
you would normally have something like:

/etc/openvpn/server/server1/easyrsa/*/keys
/etc/openvpn/server/server2/easyrsa/*/keys
/etc/openvpn/server/server3/easyrsa/*/keys

and a patched KEY_DIR would place all keys by default
in one directory. That's not what you want (with multiple servers).


So after rethinking this my suggestion is:


 /usr/share/easyrsa without patching KEY_DIR (keys placed in subdir)


and users will have to copy the contents of /usr/share/easyrsa
to a writable location like /etc/openvpn/server/server1/easyrsa



-- 
Thomas Szteliga




smime.p7s
Description: S/MIME Cryptographic Signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Best place to install the EasyRSA scripts?

[Andreas Guldstrand]

How about '/usr/libexec'?

On 4 November 2016 at 12:02, Sebastian Arcus  wrote:
> I am making the SBo scripts for EasyRSA, and I need to decide where they
> will be installed. Before they were removed from Slackware - when they were
> part of Openvpn, I think they used to go under /usr/share/doc/openvpn.
> However, it seems a bit strange to install a package in the directory of
> another package. Maybe /usr/share/doc/easyrsa instead? However, they are
> sample scripts - not really documentation. According to Linux filesystem
> standards, would there be a better place? Maybe /usr/share directly, or
> /us/lib or something?
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] libraries/libkate: You should recreate aclocal.m4

[Antonio Hernández Blas]

On Thu, Nov 3, 2016 at 3:46 AM, Willy Sudiarto Raharjo <
will...@slackbuilds.org> wrote:

> is this a clean slackware64-14.2 or upgrade from previous version?
>

Weird enough... slackware64-14.2 clean install and using sbopkg too. Not my
system but *sbopkg -b libkate* was executed some minutes ago and it
worked... false alarm ;-)

- Cheers

-- 
Antonio Hernández Blas | Oaxaca, México, Mx.
https://github.com/nihilismus | https://bitbucket.org/nihilismus |
https://twitter.com/nihilipster
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] problems with 'volti'

[Alexander Verbovetsky]

> if you are willing to step up and take over this package, please
> submit an update after the public update

I actually just tested it and found that it's not for me.

Best regards,
Alexander


On Fri, Nov 4, 2016, at 20:54, Willy Sudiarto Raharjo wrote:
> > there are problems with the volti SlackBuild:
> > 
> > 1. the download link is wrong, the new one that I found is:
> > 
> > https://github.com/gen2brain/volti/archive/0.2.3/volti-0.2.3.tar.gz
> > 
> > 2. the file PKG-INFO went away and should be removed from
> > volti.SlackBuild.
> > 
> > 3. The maintainer's address doesn't work:
> > 
> > : Host or domain name not found. Name service
> > error for name=gnomeslackbuild.org type=A: Host not found
> 
> Thanks for reporting
> it has been fixed on my branch
> 
> if you are willing to step up and take over this package, please submit
> an update after the public update
> 
> 
> -- 
> Willy Sudiarto Raharjo
> 
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[David Spencer]

Hi - let me say to start that this is only a personal opinion, and
I've been too busy recently to pay careful attention to this
discussion. But IIRC we've talked about this before.  In my opinion,
real life is much too complex for OPTIONAL=

Look at this example (graphics/luminance-hdr)

> The following are optional dependencies:
> cfitsio and CCfits - for importing FITS images (both needed)
> hugin  - for aligning multiple LDR exposures

And this example (gis/gdal):

> The following optional requirements are detected automatically:
> cfitsio, freexl, hdf, hdf5, libwebp, netcdf, postgresql, xerces-c
>
> To enable OpenCL GPU-accelerated performance, specify the option
> OPENCL=yes (requires opencl-headers to build, and either nvidia-driver
> or amd-app-sdk with suitable GPU hardware to run).

Users need to know what useful features each dep provides, if that
information is available upstream.

Users need to know if some deps are needed together (like cfitsio and
CCfits above), or if some deps are mutually exclusive (like
nvidia-driver and amd-app-sdk above).

Some users want to know if deps are build-time only, or run-time only.

Users need to know whether deps are automatically detected, or whether
there are environment variables that need to be set.  (Not all
SlackBuilds use environment variables in the same way, and some
SlackBuilds would need to be rewritten if we standardised on (for
example) OPTIONAL="libass:ASS=yes|no libbluray:BLURAY=yes|no".  Who's
going to find them all?  Who's going to fix them all?  Who's going to
change all the users' queue files and build scripts?)

And some users (ok, me) don't like XML, and don't like YAML, and don't
like new stuff such as "[opt]libass[/opt]" that I'd have to write a
parser for from scratch when XML and YAML already exist, and don't
like reading stuff that's complicated. I don't think anybody -- either
maintainers or users -- would enjoy having half the README file or the
.info file written in YAML, but that's the kind of thing that would be
needed if you look at all the real examples in SBo.

IMO it's best to read all ~5800 README files before thinking about a
solution. I've done it. It's quite easy to spot the interesting ones
if you step through them quickly.

Cheers
-D.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] problems with 'volti'

[Willy Sudiarto Raharjo]

> there are problems with the volti SlackBuild:
> 
> 1. the download link is wrong, the new one that I found is:
> 
> https://github.com/gen2brain/volti/archive/0.2.3/volti-0.2.3.tar.gz
> 
> 2. the file PKG-INFO went away and should be removed from
> volti.SlackBuild.
> 
> 3. The maintainer's address doesn't work:
> 
> : Host or domain name not found. Name service
> error for name=gnomeslackbuild.org type=A: Host not found

Thanks for reporting
it has been fixed on my branch

if you are willing to step up and take over this package, please submit
an update after the public update


-- 
Willy Sudiarto Raharjo



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Andrzej Telszewski]

On 04/11/16 14:49, Konrad J Hambrick wrote:

Yes, an OPTIONAL= Line might be nice to have

But as Andrzej Telszewski said the syntax would be TBD ...

In the meantime, I would love to see something like that :)


Yet another possibility would be to have special tags for README, 
something like:


[opt]libass[/opt]

Such tags would have to be nice for those who read READMEs as plain text.

On the website, the README could be parsed to generate OPTIONAL field of 
the .info file.


This would lessen the job of maintainers and lower the possibility of 
inconsistency between README and .info.


Another thing I would love to see is some form of README formatting when 
displayed in the web browser.


Having required, run-time and build-time dependencies all in separate, 
nicely laid out tables would be cool.


Again, all of this would have to be easily readable for pure text guys.

I'm not maintaining too many SlackBuilds, so my voice is what it is ;-)

--
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Konrad J Hambrick]

Yes, an OPTIONAL= Line might be nice to have

But as Andrzej Telszewski said the syntax would be TBD ...

In the meantime, I would love to see something like that :)

-- kjh

On Fri, Nov 4, 2016 at 8:25 AM, Petar Petrov  wrote:

> I do not mind having an "OPTIONAL=" field, if this will make third
> party automation tools more efficient.
>
> -petar
>
> 2016-11-04 9:01 GMT+02:00 Andreas Guldstrand  >:
> > As the current maintainer of sbotools, I would approve of an OPTIONAL
> > field like the one proposed by Andrzej, with the "libass:ASS=yes|no"
> > bits.
> >
> > Seems very useful and feasible to implement support for.
> >
> > On 3 November 2016 at 19:52, Andrzej Telszewski 
> wrote:
> >> Hi,
> >>
> >> I've spent some time building packages now and although I used an
> automated
> >> tool (slackrepo to the rescue, thank you David!), I'm from the camp that
> >> reads README, trying to leave as little as possible to the fate.
> >>
> >> I'm using web browser to find the SlackBuild in question, read on and
> decide
> >> what to do. If an optional dependency is mentioned, I search for it,
> read
> >> on, and so on ;-)
> >>
> >> Searching for optional dependency is the most frustrating point.
> >> Sometimes there are many search results and you need to scan the list to
> >> find the one you need.
> >> Sometimes, the search filed leaves the keyword you entered there, so you
> >> have to erase it, before proceeding, etc.
> >>
> >> So what's the use for OPTIONAL field you ask?
> >>
> >> 1) PHP could parse it to give us direct link to the optional SlackBuild
> in
> >> question,
> >> 2) PHP could parse it to let us know about possible circular dependency.
> >>
> >>
> >> When it comes to automated tools, I'd say we need something more than
> just
> >> the package name in the OPTIONAL field.
> >> Probably something like that (ffmpeg for example) would be needed:
> >>
> >> OPTIONAL="libass:ASS=yes|no libbluray:BLURAY=yes|no"
> >>
> >> This would have to be thought through to make the best design decisions
> and
> >> the SlackBuilds would have to be standardized in one way or the other.
> >>
> >> But for the next iteration, having OPTIONAL field mentioning just the
> >> packages names and SBo website listing them next to REQUIRES, would be
> the
> >> step towards the better, faster and more secure world :-)
> >>
> >>
> >> --
> >> Best regards,
> >> Andrzej Telszewski
> >> ___
> >> SlackBuilds-users mailing list
> >> SlackBuilds-users@slackbuilds.org
> >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> >> FAQ - https://slackbuilds.org/faq/
> >>
> > ___
> > SlackBuilds-users mailing list
> > SlackBuilds-users@slackbuilds.org
> > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> > FAQ - https://slackbuilds.org/faq/
> >
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Petar Petrov]

I do not mind having an "OPTIONAL=" field, if this will make third
party automation tools more efficient.

-petar

2016-11-04 9:01 GMT+02:00 Andreas Guldstrand :
> As the current maintainer of sbotools, I would approve of an OPTIONAL
> field like the one proposed by Andrzej, with the "libass:ASS=yes|no"
> bits.
>
> Seems very useful and feasible to implement support for.
>
> On 3 November 2016 at 19:52, Andrzej Telszewski  wrote:
>> Hi,
>>
>> I've spent some time building packages now and although I used an automated
>> tool (slackrepo to the rescue, thank you David!), I'm from the camp that
>> reads README, trying to leave as little as possible to the fate.
>>
>> I'm using web browser to find the SlackBuild in question, read on and decide
>> what to do. If an optional dependency is mentioned, I search for it, read
>> on, and so on ;-)
>>
>> Searching for optional dependency is the most frustrating point.
>> Sometimes there are many search results and you need to scan the list to
>> find the one you need.
>> Sometimes, the search filed leaves the keyword you entered there, so you
>> have to erase it, before proceeding, etc.
>>
>> So what's the use for OPTIONAL field you ask?
>>
>> 1) PHP could parse it to give us direct link to the optional SlackBuild in
>> question,
>> 2) PHP could parse it to let us know about possible circular dependency.
>>
>>
>> When it comes to automated tools, I'd say we need something more than just
>> the package name in the OPTIONAL field.
>> Probably something like that (ffmpeg for example) would be needed:
>>
>> OPTIONAL="libass:ASS=yes|no libbluray:BLURAY=yes|no"
>>
>> This would have to be thought through to make the best design decisions and
>> the SlackBuilds would have to be standardized in one way or the other.
>>
>> But for the next iteration, having OPTIONAL field mentioning just the
>> packages names and SBo website listing them next to REQUIRES, would be the
>> step towards the better, faster and more secure world :-)
>>
>>
>> --
>> Best regards,
>> Andrzej Telszewski
>> ___
>> SlackBuilds-users mailing list
>> SlackBuilds-users@slackbuilds.org
>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - https://slackbuilds.org/faq/
>>
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Konrad J Hambrick]

Thank you Christoph !

I think I'll kill the SlackBuild Session and stand by.

-- kjh

On Fri, Nov 4, 2016 at 6:36 AM, Christoph Willing <
chris.will...@iinet.net.au> wrote:

> On 04/11/16 20:55, Matteo Bernardini wrote:
>
>> 2016-11-04 11:47 GMT+01:00 Christoph Willing > >:
>>
>>> On 04/11/16 19:02, Willy Sudiarto Raharjo wrote:
>>>

> While trying to build PaleMoon 26.5.0, I am suffering from an md5sum
> error
> on 26.5.0_Release.tar.gz
>
> The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
> 5556f1a1d668a0d1d71387a6e66b53ca
>
> I've run my SBo wrapper script twice now.
>
> Is it me or does the md5sum fail for Y'All too ?
>


 Yes, it's incorrect
 i have fixed it on my branch


>>> Interestingly, the original md5sum works for me for a version downloaded
>>> around 1st October. Downloading it again just now, the new version
>>> (although
>>> with same name/version) has a new md5sum - also slightly different size:
>>>
>>> chris@d6:/storage/distfiles$ ls -l 26.5.0_Release.tar.gz
>>> -rw-r--r-- 1 chris vislab 128600018 Oct  1 13:49 26.5.0_Release.tar.gz
>>> chris@d6:/storage/distfiles$ md5sum 26.5.0_Release.tar.gz
>>> d7578845894fb58470b54d569615d32f  26.5.0_Release.tar.gz
>>>
>>> and new version:
>>>
>>> chris@d6:/tmp$ ls -l 26.5.0_Release.tar.gz
>>> -rw-r--r-- 1 chris vislab 128600081 Nov  4 20:41 26.5.0_Release.tar.gz
>>> chris@d6:/tmp$ md5sum 26.5.0_Release.tar.gz
>>> 5556f1a1d668a0d1d71387a6e66b53ca  26.5.0_Release.tar.gz
>>>
>>> I hate it when they do that.
>>>
>>> chris
>>>
>>
>> me too: it decreases the level of trust that I put on those particular
>> developers.
>>
>> That's important for a project that I thought was supposed to be "more
> open" with fewer binary blobs (unknown code in your system) i.e. more
> trustworthy.
>
> Anyway, I raised an issue about it at their website:
> https://github.com/MoonchildProductions/Pale-Moon/issues/651
>
> chris
>
>
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Christoph Willing]

On 04/11/16 20:55, Matteo Bernardini wrote:

2016-11-04 11:47 GMT+01:00 Christoph Willing :

On 04/11/16 19:02, Willy Sudiarto Raharjo wrote:


While trying to build PaleMoon 26.5.0, I am suffering from an md5sum
error
on 26.5.0_Release.tar.gz

The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
5556f1a1d668a0d1d71387a6e66b53ca

I've run my SBo wrapper script twice now.

Is it me or does the md5sum fail for Y'All too ?



Yes, it's incorrect
i have fixed it on my branch



Interestingly, the original md5sum works for me for a version downloaded
around 1st October. Downloading it again just now, the new version (although
with same name/version) has a new md5sum - also slightly different size:

chris@d6:/storage/distfiles$ ls -l 26.5.0_Release.tar.gz
-rw-r--r-- 1 chris vislab 128600018 Oct  1 13:49 26.5.0_Release.tar.gz
chris@d6:/storage/distfiles$ md5sum 26.5.0_Release.tar.gz
d7578845894fb58470b54d569615d32f  26.5.0_Release.tar.gz

and new version:

chris@d6:/tmp$ ls -l 26.5.0_Release.tar.gz
-rw-r--r-- 1 chris vislab 128600081 Nov  4 20:41 26.5.0_Release.tar.gz
chris@d6:/tmp$ md5sum 26.5.0_Release.tar.gz
5556f1a1d668a0d1d71387a6e66b53ca  26.5.0_Release.tar.gz

I hate it when they do that.

chris


me too: it decreases the level of trust that I put on those particular
developers.

That's important for a project that I thought was supposed to be "more 
open" with fewer binary blobs (unknown code in your system) i.e. more 
trustworthy.


Anyway, I raised an issue about it at their website:
https://github.com/MoonchildProductions/Pale-Moon/issues/651

chris

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

[Slackbuilds-users] Best place to install the EasyRSA scripts?

[Sebastian Arcus]

I am making the SBo scripts for EasyRSA, and I need to decide where they 
will be installed. Before they were removed from Slackware - when they 
were part of Openvpn, I think they used to go under 
/usr/share/doc/openvpn. However, it seems a bit strange to install a 
package in the directory of another package. Maybe 
/usr/share/doc/easyrsa instead? However, they are sample scripts - not 
really documentation. According to Linux filesystem standards, would 
there be a better place? Maybe /usr/share directly, or /us/lib or something?

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

Re: [Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Matteo Bernardini]

2016-11-04 11:47 GMT+01:00 Christoph Willing :
> On 04/11/16 19:02, Willy Sudiarto Raharjo wrote:
>>>
>>> While trying to build PaleMoon 26.5.0, I am suffering from an md5sum
>>> error
>>> on 26.5.0_Release.tar.gz
>>>
>>> The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
>>> 5556f1a1d668a0d1d71387a6e66b53ca
>>>
>>> I've run my SBo wrapper script twice now.
>>>
>>> Is it me or does the md5sum fail for Y'All too ?
>>
>>
>> Yes, it's incorrect
>> i have fixed it on my branch
>>
>
> Interestingly, the original md5sum works for me for a version downloaded
> around 1st October. Downloading it again just now, the new version (although
> with same name/version) has a new md5sum - also slightly different size:
>
> chris@d6:/storage/distfiles$ ls -l 26.5.0_Release.tar.gz
> -rw-r--r-- 1 chris vislab 128600018 Oct  1 13:49 26.5.0_Release.tar.gz
> chris@d6:/storage/distfiles$ md5sum 26.5.0_Release.tar.gz
> d7578845894fb58470b54d569615d32f  26.5.0_Release.tar.gz
>
> and new version:
>
> chris@d6:/tmp$ ls -l 26.5.0_Release.tar.gz
> -rw-r--r-- 1 chris vislab 128600081 Nov  4 20:41 26.5.0_Release.tar.gz
> chris@d6:/tmp$ md5sum 26.5.0_Release.tar.gz
> 5556f1a1d668a0d1d71387a6e66b53ca  26.5.0_Release.tar.gz
>
> I hate it when they do that.
>
> chris

me too: it decreases the level of trust that I put on those particular
developers.

Matteo
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Christoph Willing]

On 04/11/16 19:02, Willy Sudiarto Raharjo wrote:

While trying to build PaleMoon 26.5.0, I am suffering from an md5sum error
on 26.5.0_Release.tar.gz

The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
5556f1a1d668a0d1d71387a6e66b53ca

I've run my SBo wrapper script twice now.

Is it me or does the md5sum fail for Y'All too ?


Yes, it's incorrect
i have fixed it on my branch



Interestingly, the original md5sum works for me for a version downloaded 
around 1st October. Downloading it again just now, the new version 
(although with same name/version) has a new md5sum - also slightly 
different size:


chris@d6:/storage/distfiles$ ls -l 26.5.0_Release.tar.gz
-rw-r--r-- 1 chris vislab 128600018 Oct  1 13:49 26.5.0_Release.tar.gz
chris@d6:/storage/distfiles$ md5sum 26.5.0_Release.tar.gz
d7578845894fb58470b54d569615d32f  26.5.0_Release.tar.gz

and new version:

chris@d6:/tmp$ ls -l 26.5.0_Release.tar.gz
-rw-r--r-- 1 chris vislab 128600081 Nov  4 20:41 26.5.0_Release.tar.gz
chris@d6:/tmp$ md5sum 26.5.0_Release.tar.gz
5556f1a1d668a0d1d71387a6e66b53ca  26.5.0_Release.tar.gz

I hate it when they do that.

chris

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

Re: [Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Konrad J Hambrick]

thanks willy !

-- kjh

On Fri, Nov 4, 2016 at 4:02 AM, Willy Sudiarto Raharjo <
will...@slackbuilds.org> wrote:

> > While trying to build PaleMoon 26.5.0, I am suffering from an md5sum
> error
> > on 26.5.0_Release.tar.gz
> >
> > The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
> > 5556f1a1d668a0d1d71387a6e66b53ca
> >
> > I've run my SBo wrapper script twice now.
> >
> > Is it me or does the md5sum fail for Y'All too ?
>
> Yes, it's incorrect
> i have fixed it on my branch
>
> thanks
>
> --
> Willy Sudiarto Raharjo
>
>
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Willy Sudiarto Raharjo]

> While trying to build PaleMoon 26.5.0, I am suffering from an md5sum error
> on 26.5.0_Release.tar.gz
> 
> The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
> 5556f1a1d668a0d1d71387a6e66b53ca
> 
> I've run my SBo wrapper script twice now.
> 
> Is it me or does the md5sum fail for Y'All too ?

Yes, it's incorrect
i have fixed it on my branch

thanks

-- 
Willy Sudiarto Raharjo



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] PaleMoon 26.5.0 md5sum error

[Konrad J Hambrick]

All --

While trying to build PaleMoon 26.5.0, I am suffering from an md5sum error
on 26.5.0_Release.tar.gz

The Slackbuild's md5sum is d7578845894fb58470b54d569615d32f but I see
5556f1a1d668a0d1d71387a6e66b53ca

I've run my SBo wrapper script twice now.

Is it me or does the md5sum fail for Y'All too ?

Thank you !

-- kjh

Also reported on LQ
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Shouldn't KeePass (mono apps in general) be ARCH=noarch?

[Andreas Guldstrand]

On 29 October 2016 at 21:11, Thomas Szteliga  wrote:
> On 10/29/2016 08:37 PM, B Watson wrote:
>> Example: a lot of Perl packages install only perl code, nothing native,
>> but the install path is different (lib vs. lib64) so they can't use
>> noarch.

Actually, a lot of perl packages don't actually use lib/lib64 at all,
but are still not marked noarch in SBo.

I found this out when I carefully checked a bunch of perl submissions
of mine if they used an arch-dependent directory at all, and when they
didn't I marked them as noarch ... and then that was changed after I
submitted.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Andreas Guldstrand]

As the current maintainer of sbotools, I would approve of an OPTIONAL
field like the one proposed by Andrzej, with the "libass:ASS=yes|no"
bits.

Seems very useful and feasible to implement support for.

On 3 November 2016 at 19:52, Andrzej Telszewski  wrote:
> Hi,
>
> I've spent some time building packages now and although I used an automated
> tool (slackrepo to the rescue, thank you David!), I'm from the camp that
> reads README, trying to leave as little as possible to the fate.
>
> I'm using web browser to find the SlackBuild in question, read on and decide
> what to do. If an optional dependency is mentioned, I search for it, read
> on, and so on ;-)
>
> Searching for optional dependency is the most frustrating point.
> Sometimes there are many search results and you need to scan the list to
> find the one you need.
> Sometimes, the search filed leaves the keyword you entered there, so you
> have to erase it, before proceeding, etc.
>
> So what's the use for OPTIONAL field you ask?
>
> 1) PHP could parse it to give us direct link to the optional SlackBuild in
> question,
> 2) PHP could parse it to let us know about possible circular dependency.
>
>
> When it comes to automated tools, I'd say we need something more than just
> the package name in the OPTIONAL field.
> Probably something like that (ffmpeg for example) would be needed:
>
> OPTIONAL="libass:ASS=yes|no libbluray:BLURAY=yes|no"
>
> This would have to be thought through to make the best design decisions and
> the SlackBuilds would have to be standardized in one way or the other.
>
> But for the next iteration, having OPTIONAL field mentioning just the
> packages names and SBo website listing them next to REQUIRES, would be the
> step towards the better, faster and more secure world :-)
>
>
> --
> Best regards,
> Andrzej Telszewski
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/