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

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

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

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

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

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

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

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

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

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;

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

[Slackbuilds-users] Suggestion: monospace font for README

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

Re: [Slackbuilds-users] Error building atom package

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

Re: [Slackbuilds-users] Help offer

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

Re: [Slackbuilds-users] SlackBuilds.org automated build system [was: Help offer]

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

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

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

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

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

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

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

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

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

Re: [Slackbuilds-users] Help offer

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 :)

Re: [Slackbuilds-users] Help offer

> 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

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

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

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

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

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

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

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

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

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

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