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

[Franzen]

It's about replicating *THE SAME INFORMATION THAT YOU PUT IN THE 
README*

into the .info file, so *MACHINES* can understand it.


Somebody would have to verify that it really is "*THE SAME INFORMATION
THAT YOU PUT IN THE README*", and really there is no way of automating
that, because the README is only readable by humans.


Yes.
If it comes that far, i'm willling to help by editing several hundreds 
.info-files.



You are not going to test it more than you do already.
Let's finally understand that.


But we *would* have to *review* more than we already do.


About 15% of all packages are affected with optional deps.
Just a rough find/grep
$ find . -type f -name 'README*' -exec fgrep -i optional '{}' + | wc -l
866

For new submitted packages the admins would have more work, for updates 
very less, as usually dependencies are not changing all the time.



We *want* SlackBuilds to have a really low barrier to entry. We want
them to be easy. We are proud that SlackBuilds.org is much easier for
new people to become maintainers than (for example) becoming a Debian
Developer.
Making 'OPTIONAL=' more than a plain list is dooming newbie
maintainers to one more headache.  So I think that, if we do have
OPTIONAL, it should be a plain list.


It's really important to keep it simple. In most cases(85%) a maintainer 
won't have to fill the option field at all.
In most cases of the affected 15%, it would be a simple list, like in 
the REQUIRED field.


For the rest(e.g.qemu/spice-gtk and usbredir), the OPTIONAL= field gets 
really interesting and most useful in my opinion, if an OPTION:

- requires the OPTION to build against another package
- makes sense only combined with another OPTION
- conflicts with another package

This rendered on SBo-website would prevent bugreports(two ccured in the 
last months about uncleraness of qemu/gtk-spice,usbredir), as it is more 
obvious that optional packages have to be checked for further optional 
packages, which then may have become a requirement.
Links are more userfriendly, in the current state it's errorprone on the 
SBo-website to copy-paste optional deps from optional deps from optional 
deps to the next browser-tab, where the website has to be opend before.
And that all *because* i want to read the READMEs, i want a better way 
to get the READMEs by OPTIONAL=.
The possibility for 3rd-party automation is a sideeffect, i don't use 
them.

If those tools don't want to fully support syntax like !,&&,(),
these still just could cycle through OPTIONAL= showing the READMEs.


Two: the single biggest problem we have at the moment (IMO) is qt5.
Lots of packages don't build properly unless you remove qt5 before
building.  The only solution we have is to mention it in the README.


If this problem only occurs on compiletime, maybe it
would be solved by implementing something like
"REQUIRED=!qt5" ?


Johannes
___
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] Suggestion: monospace font for README

[Fernando Lopez]

can we have a smaller font? font size is too big at least for me...

On Sun, Nov 6, 2016 at 7:54 PM, B Watson  wrote:

> On 11/6/16, Willy Sudiarto Raharjo  wrote:
>
> > I have implemented a css code to fix the wrap issue, but feel free to
> > update the README
>
> Still worth doing, the READMEs with long lines look like crap in text
> editors or less (which to me is their native environment, not the web).
> ___
> 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/
>
>


-- 


Regards,
Fernando Lopez Jr.
___
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] Suggestion: monospace font for README

[B Watson]

On 11/6/16, Willy Sudiarto Raharjo  wrote:

> I have implemented a css code to fix the wrap issue, but feel free to
> update the README

Still worth doing, the READMEs with long lines look like crap in text
editors or less (which to me is their native environment, not the web).
___
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] Suggestion: monospace font for README

[Willy Sudiarto Raharjo]

> I was about to comment that un-word-wrapped READMEs violate the
> guidelines, but went & looked first... and there's nothing in there
> about word-wrapping or max line length in the README.
>
> Maybe there should be?
>
> $ find . -name README | wc -l
> 6124
> $ find . -name README | xargs egrep -l
> '^.{81,}$'|wc -l
> 288
>
> Affects 5% of the builds. Shouldn't be too much work to fix, I'm willing
> to spend some time on it if you want. In theory, every maintainer should
> fix his own READMEs, but this is a cosmetic-only change, might be OK to
> just do it?

I have implemented a css code to fix the wrap issue, but feel free to
update the README

-- 
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/

Re: [Slackbuilds-users] Suggestion: monospace font for README

[Andrzej Telszewski]

On 07/11/16 01:35, Willy Sudiarto Raharjo wrote:

You could also just use some CSS and have browsers wrap the text. Seems
much easier than editing a ton of READMES...

pre {
white-space: pre-wrap;   /* css-3 */
white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
white-space: -pre-wrap;  /* Opera 4-6 */
white-space: -o-pre-wrap;/* Opera 7 */
word-wrap: break-word;   /* Internet Explorer 5.5+ */
}

http://stackoverflow.com/questions/248011/how-do-i-wrap-text-in-a-pre-tag

Any reasonably modern browser will not need a prefix, meaning you could
simplify the CSS to:

pre {
  white-space: pre-wrap;}


https://developer.mozilla.org/en-US/docs/Web/CSS/white-space#Browser_compatibility


I implemented this proposal (wrapping issue) just now
can anyone review the results in
https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/ ?



Works for me (SeaMonkey 2.40).


The content of the README will be using  and it looks different
from the rest of the page (deps, maintainer, etc).




___
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/




--
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] Suggestion: monospace font for README

[Willy Sudiarto Raharjo]

>> You could also just use some CSS and have browsers wrap the text. Seems
>> much easier than editing a ton of READMES...
>>
>> pre {
>> white-space: pre-wrap;   /* css-3 */
>> white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
>> white-space: -pre-wrap;  /* Opera 4-6 */
>> white-space: -o-pre-wrap;/* Opera 7 */
>> word-wrap: break-word;   /* Internet Explorer 5.5+ */
>> }
>>
>> http://stackoverflow.com/questions/248011/how-do-i-wrap-text-in-a-pre-tag
>>
>> Any reasonably modern browser will not need a prefix, meaning you could
>> simplify the CSS to:
>>
>> pre {
>>   white-space: pre-wrap;}
>>
>>
>> https://developer.mozilla.org/en-US/docs/Web/CSS/white-space#Browser_compatibility

I implemented this proposal (wrapping issue) just now
can anyone review the results in
https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/ ?

The content of the README will be using  and it looks different
from the rest of the page (deps, maintainer, etc).


-- 
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] Suggestion: monospace font for README

[Jeremy Hansen]

Yeah, it just covers any browsers that might not (which probably wouldn't
be frequently used by Slackware users).

On Sun, Nov 6, 2016, 6:14 PM Ryan P.C. McQuen  wrote:

> On Sun, Nov 6, 2016 at 2:48 PM Jeremy Hansen jebrhansen+...@gmail.com
>  wrote:
>
> You could also just use some CSS and have browsers wrap the text. Seems
> much easier than editing a ton of READMES...
>
> pre {
> white-space: pre-wrap;   /* css-3 */
> white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
> white-space: -pre-wrap;  /* Opera 4-6 */
> white-space: -o-pre-wrap;/* Opera 7 */
> word-wrap: break-word;   /* Internet Explorer 5.5+ */
> }
>
> http://stackoverflow.com/questions/248011/how-do-i-wrap-text-in-a-pre-tag
>
> Any reasonably modern browser will not need a prefix, meaning you could
> simplify the CSS to:
>
> pre {
>   white-space: pre-wrap;}
>
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/white-space#Browser_compatibility
> ​
> ___
> 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] Suggestion: monospace font for README

[Ryan P.C. McQuen]

On Sun, Nov 6, 2016 at 2:48 PM Jeremy Hansen jebrhansen+...@gmail.com
 wrote:

You could also just use some CSS and have browsers wrap the text. Seems
> much easier than editing a ton of READMES...
>
> pre {
> white-space: pre-wrap;   /* css-3 */
> white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
> white-space: -pre-wrap;  /* Opera 4-6 */
> white-space: -o-pre-wrap;/* Opera 7 */
> word-wrap: break-word;   /* Internet Explorer 5.5+ */
> }
>
> http://stackoverflow.com/questions/248011/how-do-i-wrap-text-in-a-pre-tag
>
Any reasonably modern browser will not need a prefix, meaning you could
simplify the CSS to:

pre {
  white-space: pre-wrap;}

https://developer.mozilla.org/en-US/docs/Web/CSS/white-space#Browser_compatibility
​
___
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] Suggestion: monospace font for README

[Jeremy Hansen]

You could also just use some CSS and have browsers wrap the text. Seems
much easier than editing a ton of READMES...

pre {
white-space: pre-wrap;   /* css-3 */
white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
white-space: -pre-wrap;  /* Opera 4-6 */
white-space: -o-pre-wrap;/* Opera 7 */
word-wrap: break-word;   /* Internet Explorer 5.5+ */
}

http://stackoverflow.com/questions/248011/how-do-i-wrap-text-in-a-pre-tag

On Sun, Nov 6, 2016, 5:41 PM B Watson  wrote:

> On 11/6/16, Erik Hanson  wrote:
>
> > If you want to push a branch that's just cosmetic fixes, I think we
> > could merge it.
>
> OK, working on it now, branch will be called user/urchlay/cosmetics.
> ___
> 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] Suggestion: monospace font for README

[B Watson]

On 11/6/16, Erik Hanson  wrote:

> If you want to push a branch that's just cosmetic fixes, I think we
> could merge it.

OK, working on it now, branch will be called user/urchlay/cosmetics.
___
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] Suggestion: monospace font for README

[Erik Hanson]

On Sun, 6 Nov 2016 15:47:56 -0500
B Watson  wrote:

> I was about to comment that un-word-wrapped READMEs violate the
> guidelines, but went & looked first... and there's nothing in there
> about word-wrapping or max line length in the README.
> 
> Maybe there should be?

I agree.

> Affects 5% of the builds. Shouldn't be too much work to fix, I'm
> willing to spend some time on it if you want. In theory, every
> maintainer should fix his own READMEs, but this is a cosmetic-only
> change, might be OK to just do it?

If you want to push a branch that's just cosmetic fixes, I think we
could merge it.


-- 
Erik
___
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] Suggestion: monospace font for README

[Ryan P.C. McQuen]

>
>
> That's IMHO why Markdown would be the best solution for README files.
>

I am a big fan of Markdown. How much support is needed? If we only want to
be able to have code snippets, I wrote a really lightweight JavaScript
library to parse text and syntax highlight blocks of code like this:

```sh
#!/bin/sh
slackpkg_update_only() {
  slackpkg update gpg
  slackpkg update
}
```

It ends up looking something like the attached image.[image: Screenshot at
2016-11-06 13:00:26.png]

https://github.com/ryanpcmcquen/codeFormatter

If we only need code snippet support, this may be easier to integrate than
a full fledged markdown parser (if people are even onboard with that).
___
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] Suggestion: monospace font for README

[Thomas Szteliga]

On 11/06/2016 09:47 PM, B Watson wrote:
> On 11/6/16, Erik Hanson  wrote:
>> I've made the change. Not sure what I think about it. Instantly I can
>> see some README files are not word wrapped properly:
>> https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/
> Yuck.
> I was about to comment that un-word-wrapped READMEs violate the
> guidelines, but went & looked first... and there's nothing in there
> about word-wrapping or max line length in the README.
> Maybe there should be?


Definitely. Max line length should be mandatory.


> $ find . -name README | wc -l
> 6124
> $ find . -name README | xargs egrep -l
> '^.{81,}$'|wc -l
> 288
> Affects 5% of the builds. Shouldn't be too much work to fix, I'm willing
> to spend some time on it if you want. In theory, every maintainer should
> fix his own READMEs, but this is a cosmetic-only change, might be OK to
> just do it?
> Some of them are formatted OK, except they have URLs that are too
> long. Not much can be done about that.



That's IMHO why Markdown would be the best solution for README files.


-- 
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] Suggestion: monospace font for README

[B Watson]

On 11/6/16, Erik Hanson  wrote:

> I've made the change. Not sure what I think about it. Instantly I can
> see some README files are not word wrapped properly:
> https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/

Yuck.

I was about to comment that un-word-wrapped READMEs violate the
guidelines, but went & looked first... and there's nothing in there
about word-wrapping or max line length in the README.

Maybe there should be?

$ find . -name README | wc -l
6124
$ find . -name README | xargs egrep -l
'^.{81,}$'|wc -l
288

Affects 5% of the builds. Shouldn't be too much work to fix, I'm willing
to spend some time on it if you want. In theory, every maintainer should
fix his own READMEs, but this is a cosmetic-only change, might be OK to
just do it?

Some of them are formatted OK, except they have URLs that are too
long. Not much can be done about that.
___
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] Suggestion: monospace font for README

[Thomas Szteliga]

On 11/06/2016 08:56 PM, Erik Hanson wrote:
> I've made the change. Not sure what I think about it. Instantly I can
> see some README files are not word wrapped properly:
> https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/
> It's probably smart to keep it though:
> https://slackbuilds.org/repository/14.2/multimedia/JSampler/


I don't think ACII-art should be supported ;-)
But if that's really needed the maintainer of JSampler
will be able to achieve this using Markdown.

So Markdown +1.


-- 
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] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Thomas Szteliga]

On 11/06/2016 09:15 PM, David Spencer wrote:
> Maybe we should give some thought to making README files nicer to use.
> Maybe they should become more like manpages, with less random
> description and with standardised headings and layout.  Markdown?


Markdown is a very good idea. It would also solve the
current problem which occurred after enabling the
monospaced font:

https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/

;-)

-- 
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] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[David Spencer]

> I would love to see it.
> But... wasn't it you that objected when I proposed tags in README?

There's a world of difference between semantic machine-readable xml or
bbcode style tags, which personally I don't like, and a light form of
markdown for headers, which improves readability for humans whether or
not the page is rendered.

And also I was sort-of trolling :)  Actually I would *hate* full-on
kramdown in README files.  It looks krap when it's not rendered.

But maybe it would be good to always say "OPTIONAL DEPENDENCIES" as a
header instead of "The following requirements can be enabled" or a
thousand variations.

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] OPTIONAL field [was: qemu/spice-gtk and usbredir]

[Andrzej Telszewski]

On 06/11/16 21:15, David Spencer wrote:

Maybe we should give some thought to making README files nicer to use.
Maybe they should become more like manpages, with less random
description and with standardised headings and layout.  Markdown?


I would love to see it.
But... wasn't it you that objected when I proposed tags in README?

--
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]

[David Spencer]

Folks, I'm going to reply to a lot of different people in this post.  Sorry!

>> It's about replicating *THE SAME INFORMATION THAT YOU PUT IN THE README*
>> into the .info file, so *MACHINES* can understand it.

Somebody would have to verify that it really is "*THE SAME INFORMATION
THAT YOU PUT IN THE README*", and really there is no way of automating
that, because the README is only readable by humans.

>> You are not going to test it more than you do already.
>> Let's finally understand that.

But we *would* have to *review* more than we already do.  It's one
more thing to go wrong, in a world where newbie maintainers can't even
get the slack-desc right.  It's one more way for reviewing admins to
make mistakes and approve something that's broken because README and
OPTIONAL say two different things.  That's not a total NO from me, but
it makes me worry a bit :(

We *want* SlackBuilds to have a really low barrier to entry. We want
them to be easy. We are proud that SlackBuilds.org is much easier for
new people to become maintainers than (for example) becoming a Debian
Developer. Making 'OPTIONAL=' more than a plain list is dooming newbie
maintainers to one more headache.  So I think that, if we do have
OPTIONAL, it should be a plain list.  And then I think we are going to
need to bring %README% back again, for cases where we need to say
"it's really complicated, you *must* read the README".

(But previously, people didn't understand %README%. Some maintainers
would always put it in, because it looked pretty.  So now, it really
means "This Package Clashes With Something In Slackware".)

> Implementation by the backend of SlackBuilds.org
> and package building tools (sbopkg/sbotools/slpkg) is another
> subject which is not important now, because we should let the
> maintainers of these tools (and Slackbuilds.org) decide if they
> implement this field or not.

But what's the point of a machine readable field that isn't being read
by the machine?  The tool maintainers would pretty much *have* to
implement it, otherwise you're all going to be very disappointed.

> In the worst case, if we agree how the format of OPTIONAL
> should look, we don't have to put this field in *.nfo,
> we can put it in the README or README.slackware or even create
> a dedicated SaaS returning the OPTIONAL value for each
> package via SOAP API call ;-)

Congratulations, you just reinvented slackrepo's hintfiles. You are
welcome to write a scraper to get the ADDREQUIRES fields from my
github. It would force me to update them properly :)  And there's lots
of other good stuff in there -- like what options are needed to enable
those deps, and which ones need -j1 to build.

Finally --

When I said we need to define the problems we currently have, I did
have two specific things in mind.

One: occasionally in the README files, there are mistakes in the
package names. Sometimes it's an upper/lower case error, or someone
has forgot (for example) "python-", or whatever.  I was going to audit
the whole lot before 14.2 came out, but didn't.  Sorry.  Anyway, this
still needs to be done.  If you see any mistakes, please do tell us.
Thanks in advance!

Two: the single biggest problem we have at the moment (IMO) is qt5.
Lots of packages don't build properly unless you remove qt5 before
building.  The only solution we have is to mention it in the README.

I'm generally a believer in "fix the technology, not the people".  But
I don't see how to avoid falling back to README when it's complicated.

Maybe we should give some thought to making README files nicer to use.
Maybe they should become more like manpages, with less random
description and with standardised headings and layout.  Markdown?

Maybe we should hide some prizes in README files, like someone once
did with a licence agreement. ;-)

Can I just say one more thing?
Thanks to everybody for caring so passionately about SlackBuilds.org :D
-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] Suggestion: monospace font for README

[Andrzej Telszewski]

On 06/11/16 20:56, Erik Hanson wrote:

On Sun, 6 Nov 2016 20:16:23 +0100
Andrzej Telszewski  wrote:


Hi,

I think it would make sense to have README enclosed within
 tags, having monospace font.

Otherwise, when using GUI web browser, we lose all the text
formatting the maintainers do.


I've made the change. Not sure what I think about it. Instantly I can
see some README files are not word wrapped properly:
https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/
It's probably smart to keep it though:
https://slackbuilds.org/repository/14.2/multimedia/JSampler/




That was fast :-)
Let's give it a try, because at first sight it looks strange.


--
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] Suggestion: monospace font for README

[Erik Hanson]

On Sun, 6 Nov 2016 20:16:23 +0100
Andrzej Telszewski  wrote:

> Hi,
> 
> I think it would make sense to have README enclosed within
>  tags, having monospace font.
> 
> Otherwise, when using GUI web browser, we lose all the text
> formatting the maintainers do.

I've made the change. Not sure what I think about it. Instantly I can
see some README files are not word wrapped properly:
https://slackbuilds.org/repository/14.2/multimedia/ExMplayer/
It's probably smart to keep it though:
https://slackbuilds.org/repository/14.2/multimedia/JSampler/


-- 
Erik
___
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] Suggestion: monospace font for README

[Andrzej Telszewski]

Hi,

I think it would make sense to have README enclosed within  
tags, having monospace font.


Otherwise, when using GUI web browser, we lose all the text formatting 
the maintainers do.


--
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] Error building atom package

[Thomas Szteliga]

On 11/05/2016 04:17 PM, 414N wrote:
> Hi everyone,
> it’s from some time that I’m not able anymore to build and upgrade my
> atom 
> installation to any of the newer versions (I’m currently running v1.9.8).
> What I get during every build is this:

...

> module.js:327 throw err; ^ Error: Cannot find module

...

> Anyone has the same issue?


I'm on 1.11.2 built few days ago (Oct 30). I had to build twice,
because during the first build npm had problems downloading
some required modules. I would suggest just try again
because your issue looks similar.



-- 
Thomas Szteliga

___
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] Help offer

[Thomas Szteliga]

On 11/06/2016 12:47 PM, David Spencer wrote:
> So the outline idea would be
>   - a submission arrives


Will we be able to download submissions from the pending queue?
That's a question to SlackBuilds.org maintainers :-)
https://slackbuilds.org/pending/


>   - our bot checks if it's a simple update, and how many packages
> depend on it -- including optional deps ;)


slpkg can do this (based on REQUIRES).
Short example with virt-manager:


# slpkg -t sbo virt-manager --check-deps
Resolving dependencies... Done

+
| Package virt-manager dependencies :
+
\
 +---[ Tree of dependencies ]
 |
 +--1: vala is dependency --> gtk-vnc, libosinfo, libvirt-glib,
spice-gtk, virt-manager, virt-viewer, vte3
 |
 +--2: celt051 is dependency --> spice, spice-gtk, virt-manager
 |
 +--3: pyparsing is dependency --> spice, spice-gtk, virt-manager
 |
 +--4: six is dependency --> spice, spice-gtk, virt-manager
 |
 +--5: spice-protocol is dependency --> spice, spice-gtk, virt-manager
 |
 +--6: spice is dependency --> spice-gtk, virt-manager
 |
 +--7: yajl is dependency --> libvirt, libvirt-glib, libvirt-python,
virt-manager
 |
 +--8: urlgrabber is dependency --> libvirt, libvirt-glib,
libvirt-python, virt-manager
 |
 +--9: libvirt is dependency --> libvirt-glib, libvirt-python, virt-manager
 |
 +--10: libosinfo is dependency --> virt-manager
 |
 +--11: libvirt-glib is dependency --> virt-manager
 |
 +--12: libvirt-python is dependency --> virt-manager
 |
 +--13: gnome-python2-gconf is dependency --> virt-manager
 |
 +--14: tunctl is dependency --> virt-manager
 |
 +--15: ipaddr-py is dependency --> virt-manager
 |
 +--16: python-urllib3 is dependency --> virt-manager
 |
 +--17: python-requests is dependency --> virt-manager
 |
 +--18: gtk-vnc is dependency --> virt-manager, virt-viewer
 |
 +--19: spice-gtk is dependency --> virt-manager
 |
 +--20: vte3 is dependency --> virt-manager



>   - if it's a simple update, and the total expected build time
> (including depending packages) is less than a threshold, throw all
> those builds and rebuilds at the automatic build queue (I already have
> a database of build times)
>   - if possible, do builds with multiple build tools (sbopkg sbotools
> slackrepo) because diverse tests catch more problems


And don't forget about slpkg: https://github.com/dslackw/slpkg


>   - do some automated tests on the final package (e.g. Heinz's lintpkg)


https://github.com/pprkut/lintpkg



-- 
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] SlackBuilds.org automated build system [was: Help offer]

[Andrzej Telszewski]

On 06/11/16 12:47, David Spencer wrote:

I haven't discussed this with anybody until now, but maybe buildbot
could be useful to us. Unless I've made a mistake reading the buildbot
docs, it would allow people to volunteer their own systems as build
hosts. There are a couple of things we would need to worry about -
clean build environment, authentication - but the idea would seem to
fit a project like SlackBuilds.org that tries to exist with minimum
infrastructure of our own.



Although people volunteering their systems sound appealing, I wouldn't 
go that direction.

You know how it goes, everything is fine until it's not.
It is much better to have system that you have total control over.
Then it's only you that is responsible for the system's security and 
also you don't have to worry about volunteer's system security.


Capable machines are dirt cheap.
For 20 euro/month you can have 8C/8T @ 2.4 GHz at https://www.online.net/
I can easily donate such machine.
Or gather 10 people, we pay 4 euro/month and you have two capable machines.


I've got a draft SlackBuild for buildbot-0.9.1, but since 0.9 it's one
of those packages that need to download huge quantities of npm stuff
at build time :(



Brr. I know it is 2016 and I should love Java and JavaScript, but I don't.
If you go this direction, I will try to do my best to help, but don't 
count on it too much.

Orthodox would apply to me very well in that respect ;-)

What I've been thinking of is brewing our own (because it's much cooler 
:-)) build system.


Quick draft would be:
- QEMU, for isolation from the host system,
- overlayfs -> chroot -> build tool, for keeping the system clean (you 
understand it correctly, i.e. slackrepo would run in overlayed chroot, 
creating its overlays/chroots inside),
- running everything from single QEMU instance would probably allow for 
easier memory management,
- some way of sending the SlackBuild, either tarball or something that 
is run based on git push (I have just started studying git, so I don't 
know yet its capabilities),

- some way of receiving/monitoring the build status.

--
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]

[Thomas Szteliga]

On 11/05/2016 09:20 PM, Andrzej Telszewski wrote:
> On 05/11/16 20:59, King Beowulf wrote:
>> to sift and test all OPTIONAL
>> deps.
> No, no, no.
> You're confusing what OPTIONAL is about.
> It's about replicating *THE SAME INFORMATION THAT YOU PUT IN THE README*
> into the .info file, so *MACHINES* can understand it.
> You are not going to test it more than you do already.
> Let's finally understand that.


Exactly.

What really needs to be discussed is the acceptable format of the
OPTIONAL field. Implementation by the backend of SlackBuilds.org
and package building tools (sbopkg/sbotools/slpkg) is another
subject which is not important now, because we should let the
maintainers of these tools (and Slackbuilds.org) decide if they
implement this field or not.

In the worst case, if we agree how the format of OPTIONAL
should look, we don't have to put this field in *.nfo,
we can put it in the README or README.slackware or even create
a dedicated SaaS returning the OPTIONAL value for each
package via SOAP API call ;-)


-- 
Thomas Szteliga

___
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]

... and then list them in order, showing their READMEs, asking the
user to confirm each of them (just as he needs to for regular
dependencies)

On 6 November 2016 at 14:40, Andreas Guldstrand
 wrote:
> On 6 November 2016 at 13:31, Erik Hanson  wrote:
>> No. Discussions are fine, we've made changes based on public
>> discourse in the past. What appears before us is a handful of people
>> really want to write some tool that plows through optional deps
>> automatically. They don't want to read the README files, or maybe
>> they don't need to, but I feel it's a bad idea to let EVERYBODY off
>> the hook when it comes to the READMEs.
>
> I'm sorry, but there are only two tools where anyone has mentioned
> support for this field in this thread (unless I missed something), and
> those are sbotools and slackrepo, and for slackrepo it was explicitly
> stated that the author would in fact *not* add any kind of support for
> these fields, and I myself mentioned I could see adding support for it
> in sbotools. However, you seem to believe "adding support" would
> necessarily entail skipping READMEs, but as the current maintainer of
> sbotools I can tell you that that would be absolutely wrong.
> Currently, sbotools does allow you to skip reading README files, but
> then it turns off all dependency resolution for you.
>
> Adding support for an OPTIONAL field would not in any way change this.
> In fact, the way I envision adding support for this kind of thing goes
> like this:
>
> sboinstall 
> => 
> =>
> => This slackbuild contains optional dependencies.
> => Please read the README before continuing.
> => Would you also like to include some of them? [y/N]
> ...
___
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]

On 6 November 2016 at 13:31, Erik Hanson  wrote:
> No. Discussions are fine, we've made changes based on public
> discourse in the past. What appears before us is a handful of people
> really want to write some tool that plows through optional deps
> automatically. They don't want to read the README files, or maybe
> they don't need to, but I feel it's a bad idea to let EVERYBODY off
> the hook when it comes to the READMEs.

I'm sorry, but there are only two tools where anyone has mentioned
support for this field in this thread (unless I missed something), and
those are sbotools and slackrepo, and for slackrepo it was explicitly
stated that the author would in fact *not* add any kind of support for
these fields, and I myself mentioned I could see adding support for it
in sbotools. However, you seem to believe "adding support" would
necessarily entail skipping READMEs, but as the current maintainer of
sbotools I can tell you that that would be absolutely wrong.
Currently, sbotools does allow you to skip reading README files, but
then it turns off all dependency resolution for you.

Adding support for an OPTIONAL field would not in any way change this.
In fact, the way I envision adding support for this kind of thing goes
like this:

sboinstall 
=> 
=>
=> This slackbuild contains optional dependencies.
=> Please read the README before continuing.
=> Would you also like to include some of them? [y/N]
...
___
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]

[Erik Hanson]

On Sun, 06 Nov 2016 08:05:01 +0100
Franzen  wrote:

> > Even if I were to explicitly say "don't bother with
> > the OPTIONAL field" I know they would check it. They're just really
> > good people that way, focused on the quality of our repository.
> > Regardless of what I say, they're going to feel burdened by it.
> > None of us want junk in the repo, or broken OPTIONAL lines.
> > This is just a reality, and I'm going to fight against more work for
> > these volunteer workers that put so much passion into this project.
> > They have families and lives and I care for them deeply.  
> 
> So, even if you would like to change something general like the 
> OPTION-field
> on SBo, it will hardly happen because of the workload?
> This is not meant offending, really, i just want to get the point.
> 
> If nothing gonna be changed now, it's fair to say that, to not make
> the OPTIONAL-discussion a fight against windmills.

No. Discussions are fine, we've made changes based on public
discourse in the past. What appears before us is a handful of people
really want to write some tool that plows through optional deps
automatically. They don't want to read the README files, or maybe
they don't need to, but I feel it's a bad idea to let EVERYBODY off
the hook when it comes to the READMEs.

I'm just one admin who decided to chime in with my thoughts on the
issue. I'm in no way the sole arbiter of all things SBo. If I see that
any number of admins view this issue differently, I'm happy to take
their considerations and concede.

> If it's all about manpower, something should be done about that.
> Maybe the community can get more ability to contribute in some ways, 
> beside providing SlackBuilds.

This particular issue is very much not just about manpower.


-- 
Erik
___
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] Help offer

[Andrzej Telszewski]

On 06/11/16 12:47, David Spencer wrote:

I have some ideas for automated builds of pending submissions, but that is
> for separate discussion (and I don't know how you admins are handling it
> now).

Awesome!

I'm sending this to the list because it needs to be sanity checked by
everybody else :)

As far as I know several people have been thinking independently about
automated testing, continuous integration, etc

I haven't discussed this with anybody until now, but maybe buildbot
could be useful to us. Unless I've made a mistake reading the buildbot
docs, it would allow people to volunteer their own systems as build
hosts. There are a couple of things we would need to worry about -
clean build environment, authentication - but the idea would seem to
fit a project like SlackBuilds.org that tries to exist with minimum
infrastructure of our own.

So the outline idea would be
  - a submission arrives
  - our bot checks if it's a simple update, and how many packages
depend on it -- including optional deps ;)
  - if it's a simple update, and the total expected build time
(including depending packages) is less than a threshold, throw all
those builds and rebuilds at the automatic build queue (I already have
a database of build times)
  - if possible, do builds with multiple build tools (sbopkg sbotools
slackrepo) because diverse tests catch more problems
  - do some automated tests on the final package (e.g. Heinz's lintpkg)
  - if the automatic builds fail, the submitter (maintainer) can see
what happened and resubmit
  - otherwise flag it for manual testing
  - final approval always a human decision

I've got a draft SlackBuild for buildbot-0.9.1, but since 0.9 it's one
of those packages that need to download huge quantities of npm stuff
at build time :(

Anyway I'd love to make some progress on this today, but I have a
wedding to go to -- not mine :)

Thanks!
-D.


You have outlined more than less what I've been thinking of ;-)

But I wonder if there could be a case where the update is not checked by 
human at all.


Assume it's a version bump.
Then you only make sure that the only part changed in the download link 
is version string.
The check for version can be very strict, e.g. it has to change from 0.1 
to 0.2 so it won't change from 0.1 to 0.$(screw up the system).


When it comes to automated build systems, there is also https://jenkins.io/

But I've been thinking about rolling our own too.

--
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] Help offer

[David Spencer]

> I can offer some man power.
> Please contact me by e-mail.
>
[...]
>
> I have some ideas for automated builds of pending submissions, but that is
> for separate discussion (and I don't know how you admins are handling it
> now).

Awesome!

I'm sending this to the list because it needs to be sanity checked by
everybody else :)

As far as I know several people have been thinking independently about
automated testing, continuous integration, etc

I haven't discussed this with anybody until now, but maybe buildbot
could be useful to us. Unless I've made a mistake reading the buildbot
docs, it would allow people to volunteer their own systems as build
hosts. There are a couple of things we would need to worry about -
clean build environment, authentication - but the idea would seem to
fit a project like SlackBuilds.org that tries to exist with minimum
infrastructure of our own.

So the outline idea would be
  - a submission arrives
  - our bot checks if it's a simple update, and how many packages
depend on it -- including optional deps ;)
  - if it's a simple update, and the total expected build time
(including depending packages) is less than a threshold, throw all
those builds and rebuilds at the automatic build queue (I already have
a database of build times)
  - if possible, do builds with multiple build tools (sbopkg sbotools
slackrepo) because diverse tests catch more problems
  - do some automated tests on the final package (e.g. Heinz's lintpkg)
  - if the automatic builds fail, the submitter (maintainer) can see
what happened and resubmit
  - otherwise flag it for manual testing
  - final approval always a human decision

I've got a draft SlackBuild for buildbot-0.9.1, but since 0.9 it's one
of those packages that need to download huge quantities of npm stuff
at build time :(

Anyway I'd love to make some progress on this today, but I have a
wedding to go to -- not mine :)

Thanks!
-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] Best place to install the EasyRSA scripts?

[Sebastian Arcus]

On 04/11/16 22:23, 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/...

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)


Thanks everybody. /usr/share/easyrsa is actually the place I settled in 
my mind after my initial post - it seems the most reasonable path. I 
will include some comments in the README as to their location, and they 
can be copied somewhere else when they are going to be used - if needed.

___
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 06/11/16 05:26, Erik Hanson wrote:

Currently, the active admins go above and beyond anything I would have
ever expected. I'm incredibly proud of the people we have brought on
board over the years. My heart swells when I think about how this
project continues to exist 10+ years later, and the level of quality we
maintain.



You can be sure that many of us appreciate the work.
We all remember how it was before SlackBuilds.org.


Another aspect of this, is that I expect they would feel obligated to
check everything in the OPTIONAL field, along side all the extra work
they already do. Even if I were to explicitly say "don't bother with
the OPTIONAL field" I know they would check it. They're just really
good people that way, focused on the quality of our repository.
Regardless of what I say, they're going to feel burdened by it. None of
us want junk in the repo, or broken OPTIONAL lines.



I understand what you want to say.
I too have to be very careful to limit the time I spend on the code.


There are much more pressing issues, our current server is on it's last
legs, there's an "amber light of death", dmesg is filled with garbage,
and I don't expect it to survive a reboot. Up 962 days as of this
writing. We'll be fine for the foreseeable future, but something has to
be done. We're not going down, it's not doom and gloom, I'll be sure of
that. This is all just for reference as to why I'm really opposed to
big changes right now. Or rather, why I'm able to squint, give a keen
eye, and say "we really don't need this".


I've already offered my help, feel obliged to contact me.
And ask the community to buy a new server, we all depend on the service.

--
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]

[Andrzej Telszewski]

On 06/11/16 05:26, Erik Hanson wrote:

On Sat, 5 Nov 2016 22:35:28 +0100
Andrzej Telszewski  wrote:


On 05/11/16 21:44, Erik Hanson wrote:

What I also don't see much (any?) mention of is what the admins will
have to refactor.. the website, php, database, internal tools we use
for submission/approval process (there are many) .. things are more
complicated behind the scenes than people realize. It's a messy and
time-consuming job. Adding an OPTIONAL field to the info file isn't
something that, if only someone would do it, magically "just
works".


I don't know behind the scenes, for that reason I don't see
SlackBuilds.org as complex software project.


It is a complex software project. Everything we do was built from
scratch, accommodating a custom submission system, a database,
eventually git integration, and so on.



You haven't convinced me ;-) I still don't see it as complex code.

--
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]

[Andrzej Telszewski]

On 06/11/16 04:39, Erik Hanson wrote:

On 06/11/16 03:33, Erik Hanson wrote:

> >> You kinda have point with the context of the deps, but we're not
> >> here

> >> > to babysit people. One shall README, period.

> > And there is the crux of the entire matter. Currently, we expect
> > people to read the README. A machine-readable field of optional
> > deps means people have even less reason to read the README. Nothing
> > good comes of this. A few power users might be okay, but the other
> > 99.9% of people: fucked. Our goal has always been a repo of scripts
> > that reliably create valid packages. OPTIONAL provides too many
> > ways for that to go wrong.
> >
> > Read the README and you're golden.

>
> Well, I don't know. This feels kinda bad. Like babysitting.
> It's Linux in the end, you are expected to know more less what you're
> doing. There are many more ways to screw up your system.

We should just delete the HOWTO and FAQ pages, I guess. Wouldn't want
to babysit.

I'm not sure how you get from "please read the README files, they
contain vital information" to "we need to hold your hand". The only
argument that I'm making is that demonstrably important information
can be contained in the README file, and that we shouldn't give anyone
a reason to bypass that information. It's not babysitting, it's not
hand-holding, it's literally saying there is information here, it's
important, and we CANNOT convey it to you in an OPTIONAL="" field.
Sorry, but you have to do some reading. Please, I beg of you, tell me
how reading up on things and gaining some understanding of how they
work is not the Slackware way.



I'm sorry for not being explicit.
If you look at my messages, you'll notice that I do encourage to read 
READMEs.
What I meant by babysitting was that you tell people to read README, but 
they don't do it anyway.


--
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]

[Franzen]

Even if I were to explicitly say "don't bother with
the OPTIONAL field" I know they would check it. They're just really
good people that way, focused on the quality of our repository.
Regardless of what I say, they're going to feel burdened by it. None of
us want junk in the repo, or broken OPTIONAL lines.
This is just a reality, and I'm going to fight against more work for
these volunteer workers that put so much passion into this project.
They have families and lives and I care for them deeply.


So, even if you would like to change something general like the 
OPTION-field

on SBo, it will hardly happen because of the workload?
This is not meant offending, really, i just want to get the point.

If nothing gonna be changed now, it's fair to say that, to not make the 
OPTIONAL-discussion a fight against windmills.


If it's all about manpower, something should be done about that.
Maybe the community can get more ability to contribute in some ways, 
beside providing SlackBuilds.


Johannes
___
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/