From rworkman at slackbuilds.org Tue Jul 1 04:22:23 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 30 Jun 2014 23:22:23 -0500 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> Message-ID: <20140630232223.48274fcd@home.rlworkman.net> On Sat, 28 Jun 2014 15:00:42 -0400 B Watson wrote: > On 6/28/14, Robby Workman wrote: > > The first eight are self-explanatory, and "full" will contain the > > remainder. Each of those nine will be split into three parts: > > texlive-texmf-* > > texlive-texmf-*-doc > > texlive-texmf-*-src > > I'm not a tex user, I would only ever need texlive as a dependency for > other stuff (looks like only graphics/textext uses it), or for one of > my hypothetical users to use. Thoughts from that perspective: > > I think the name "full" is misleading. It's really more like "misc", > everything that didn't seem to fit in one of the other packages. > > 27 packages seems like overkill. Particularly for people who don't > know the first thing about texlive... just like core Slackware, if I > needed texlive for something, I'd do a full install of it (not > knowing what's safe to leave out). Yeah, 18 was the most it would be anyway, as the -src packages are largely irrelevant - no need for us or anyone else to be concerned about those. One of the later updates cut that number down to 10, and I'm about to reply to another mail with a suggestion to thin it out even more. Re the "full" name, yeah, agreed. I just needed a name for now, and "everythingelse" was too long :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rworkman at slackbuilds.org Tue Jul 1 04:27:42 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 30 Jun 2014 23:27:42 -0500 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> Message-ID: <20140630232742.17089a98@home.rlworkman.net> On Mon, 30 Jun 2014 16:15:26 +0200 Eugen Wissner wrote: > I agree with Ivan Zaigralin: single package was very easy to use. > Otherwise it's more easy to download the DVD and install it - it's > very quick and simple. Multiple packages or excluding some stuff is > problematic, because you have to waste your time if something doesn't > work and you have too search for needed packages or why this thing > doesn't work. Therefore I'm for minimal possible number of packages > and for complete TeXLive distribution. Yeah, I agree re the single package idea, and in an ideal world, that's exactly what I'd do. Size won't let it happen though. I hope we can reach a happy medium here... > On the one hand it is nice to have TeXLive in the stock Slackware. On > the other hand, I don't know why tetex can't be just removed and the > freed space could be used for another useful packages; TeXLive can be > anytime downloaded and installed from SBo. I had a friend, who said: > Don't use LaTeX shipped with your Linux Distribution (he's Gentoo > user), because it's always cut off and causes problems. I haven't any > troubles with TeXLive available from SBo in the past. Well, we need a TeX distribution in Slackware, if only to build docs and such when upstream sources require it. I think there's a general consensus that tetex simply isn't adequate for "real" TeX users, so they have to replace it with TeX Live in order to do their own work. What I'm hoping to accomplish is a tetex-like distribution of TeX Live included in Slackware, with everything else available at SlackBuilds.org. It's still not ideal, but it would eliminate the necessity of *removing* a package from stock Slackware and it would greatly shorten the build and installation time of any additional bits needed. I'm about to do a follow-up to my latest response on the original post in this thread; I'll share my latest ramblings on how I think I need to approach this... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rworkman at slackbuilds.org Tue Jul 1 04:28:39 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 30 Jun 2014 23:28:39 -0500 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <20140628184441.GB26269@jdiamond-nb2> References: <20140618184649.461f21f8@home.rlworkman.net> <20140628131034.1ce1c817@home.rlworkman.net> <20140628184441.GB26269@jdiamond-nb2> Message-ID: <20140630232839.092cb9ea@home.rlworkman.net> On Sat, 28 Jun 2014 15:44:41 -0300 Jim Diamond wrote: > On Sat, Jun 28, 2014 at 13:10 (-0500), Robby Workman wrote: > > > Obviously there's still some tweaking to do. Feedback is desired. > > I don't have time right now for a long look (hopefully RSN, but...), > but to answer your question about context: yes, I use it. (Having > said that, it doesn't seem to be as popular as I think it should be.) Okay, given the size, I don't think there's any valid reason to *not* include context in one of the other archives. More on that in a response to the original post in this thread... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rworkman at slackbuilds.org Tue Jul 1 04:41:43 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 30 Jun 2014 23:41:43 -0500 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <20140628131034.1ce1c817@home.rlworkman.net> References: <20140618184649.461f21f8@home.rlworkman.net> <20140628131034.1ce1c817@home.rlworkman.net> Message-ID: <20140630234143.631997ef@home.rlworkman.net> On Sat, 28 Jun 2014 13:10:34 -0500 Robby Workman wrote: > Okay, here's the next round of this stuff... > > I made some comments in the tarball-sizes.txt file that might need > feedback: http://rlworkman.net/TL2014-testing/tarball-sizes.txt > > Everything except actual tarballs and such is here: > http://rlworkman.net/TL2014-testing/ > > The make-slackware-plists.sh, helpers/*, and texlive.tlpdb are used > for generating the lists, while the tarball-contents/ directory > contains text files of exactly what the name implies. > > Obviously there's still some tweaking to do. Feedback is desired. Given the feedback I've received (some onlist and some offlist), here's what I'm thinking will be a good compromise for everyone. In the texlive-texmf-tetex archive (the name might need to change though as it will be more than just the tetex stuff), we'd have the contents of the texlive-texmf-tetex archive mentioned above *plus* the context stuff and the latexextra stuff, for total sizes of roughly: 299 MB -- texlive-texmf-tetex 790 MB -- texlive-texmf-tetex-doc The rest of everything would be what's currently stated as being in the "fontsextra" and "full" archives, for total sizes of roughly: 251 MB -- texlive-texmf-remainder 220 MB -- texlive-texmf-remainder-doc Again, the name would have to be changed, but you get the idea. The only drawback would be that there is absolutely no way to ship any of the docs as part of Slackware. On that note, perhaps it would be better to just bundle all of the docs together as a single archive, meaning that users would (ideally) get a functional TeX Live from Slackware, with all docs available as a ~1GB package from SBo and any other texmf (mainly fonts) available as a ~250MB package from SBo. This still puts about 300MB of texmf in Slackware (assuming it makes it that far), but we still have the compiled sources for the texlive binaries *and* we have to host the sources for that -- I don't recall how big the binaries are but the source archive is ~42MB. Thoughts? -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From ryanpcmcquen at gmail.com Tue Jul 1 05:44:16 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Mon, 30 Jun 2014 22:44:16 -0700 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <20140630234143.631997ef@home.rlworkman.net> References: <20140618184649.461f21f8@home.rlworkman.net> <20140628131034.1ce1c817@home.rlworkman.net> <20140630234143.631997ef@home.rlworkman.net> Message-ID: <9D7A6AFE-B732-457E-8732-F910510822E6@gmail.com> I like it. :^) --- > On Jun 30, 2014, at 9:41 PM, Robby Workman wrote: > > On Sat, 28 Jun 2014 13:10:34 -0500 > Robby Workman wrote: > >> Okay, here's the next round of this stuff... >> >> I made some comments in the tarball-sizes.txt file that might need >> feedback: http://rlworkman.net/TL2014-testing/tarball-sizes.txt >> >> Everything except actual tarballs and such is here: >> http://rlworkman.net/TL2014-testing/ >> >> The make-slackware-plists.sh, helpers/*, and texlive.tlpdb are used >> for generating the lists, while the tarball-contents/ directory >> contains text files of exactly what the name implies. >> >> Obviously there's still some tweaking to do. Feedback is desired. > > > Given the feedback I've received (some onlist and some offlist), here's > what I'm thinking will be a good compromise for everyone. > > In the texlive-texmf-tetex archive (the name might need to change though > as it will be more than just the tetex stuff), we'd have the contents of > the texlive-texmf-tetex archive mentioned above *plus* the context stuff > and the latexextra stuff, for total sizes of roughly: > > 299 MB -- texlive-texmf-tetex > 790 MB -- texlive-texmf-tetex-doc > > The rest of everything would be what's currently stated as being in the > "fontsextra" and "full" archives, for total sizes of roughly: > > 251 MB -- texlive-texmf-remainder > 220 MB -- texlive-texmf-remainder-doc > > Again, the name would have to be changed, but you get the idea. > > The only drawback would be that there is absolutely no way to ship any > of the docs as part of Slackware. On that note, perhaps it would be > better to just bundle all of the docs together as a single archive, > meaning that users would (ideally) get a functional TeX Live from > Slackware, with all docs available as a ~1GB package from SBo and any > other texmf (mainly fonts) available as a ~250MB package from SBo. > > This still puts about 300MB of texmf in Slackware (assuming it makes it > that far), but we still have the compiled sources for the texlive binaries > *and* we have to host the sources for that -- I don't recall how big the > binaries are but the source archive is ~42MB. > > Thoughts? > > -RW > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From belka.ew at gmail.com Tue Jul 1 06:49:59 2014 From: belka.ew at gmail.com (Eugen Wissner) Date: Tue, 1 Jul 2014 08:49:59 +0200 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <9D7A6AFE-B732-457E-8732-F910510822E6@gmail.com> References: <20140618184649.461f21f8@home.rlworkman.net> <20140628131034.1ce1c817@home.rlworkman.net> <20140630234143.631997ef@home.rlworkman.net> <9D7A6AFE-B732-457E-8732-F910510822E6@gmail.com> Message-ID: Right, it can be a dependency for documentation building; now I understand why it's needed. And your last suggestion sounds good (with bundled docs package + remainder package) 2014-07-01 7:44 GMT+02:00 Ryan P.C. McQuen : > I like it. :^) > > > --- > > > > > On Jun 30, 2014, at 9:41 PM, Robby Workman > wrote: > > > > On Sat, 28 Jun 2014 13:10:34 -0500 > > Robby Workman wrote: > > > >> Okay, here's the next round of this stuff... > >> > >> I made some comments in the tarball-sizes.txt file that might need > >> feedback: http://rlworkman.net/TL2014-testing/tarball-sizes.txt > >> > >> Everything except actual tarballs and such is here: > >> http://rlworkman.net/TL2014-testing/ > >> > >> The make-slackware-plists.sh, helpers/*, and texlive.tlpdb are used > >> for generating the lists, while the tarball-contents/ directory > >> contains text files of exactly what the name implies. > >> > >> Obviously there's still some tweaking to do. Feedback is desired. > > > > > > Given the feedback I've received (some onlist and some offlist), here's > > what I'm thinking will be a good compromise for everyone. > > > > In the texlive-texmf-tetex archive (the name might need to change though > > as it will be more than just the tetex stuff), we'd have the contents of > > the texlive-texmf-tetex archive mentioned above *plus* the context stuff > > and the latexextra stuff, for total sizes of roughly: > > > > 299 MB -- texlive-texmf-tetex > > 790 MB -- texlive-texmf-tetex-doc > > > > The rest of everything would be what's currently stated as being in the > > "fontsextra" and "full" archives, for total sizes of roughly: > > > > 251 MB -- texlive-texmf-remainder > > 220 MB -- texlive-texmf-remainder-doc > > > > Again, the name would have to be changed, but you get the idea. > > > > The only drawback would be that there is absolutely no way to ship any > > of the docs as part of Slackware. On that note, perhaps it would be > > better to just bundle all of the docs together as a single archive, > > meaning that users would (ideally) get a functional TeX Live from > > Slackware, with all docs available as a ~1GB package from SBo and any > > other texmf (mainly fonts) available as a ~250MB package from SBo. > > > > This still puts about 300MB of texmf in Slackware (assuming it makes it > > that far), but we still have the compiled sources for the texlive > binaries > > *and* we have to host the sources for that -- I don't recall how big the > > binaries are but the source archive is ~42MB. > > > > Thoughts? > > > > -RW > > _______________________________________________ > > SlackBuilds-users mailing list > > SlackBuilds-users at slackbuilds.org > > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > FAQ - http://slackbuilds.org/faq/ > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rshepard at appl-ecosys.com Tue Jul 1 12:47:52 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Tue, 1 Jul 2014 05:47:52 -0700 (PDT) Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <20140630232223.48274fcd@home.rlworkman.net> References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> <20140630232223.48274fcd@home.rlworkman.net> Message-ID: On Mon, 30 Jun 2014, Robby Workman wrote: > Re the "full" name, yeah, agreed. I just needed a name for now, > and "everythingelse" was too long :-) 'extra' would be in the Slackware tradition. Rich From rshepard at appl-ecosys.com Tue Jul 1 12:55:53 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Tue, 1 Jul 2014 05:55:53 -0700 (PDT) Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <20140630232742.17089a98@home.rlworkman.net> References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> <20140630232742.17089a98@home.rlworkman.net> Message-ID: On Mon, 30 Jun 2014, Robby Workman wrote: > Well, we need a TeX distribution in Slackware, if only to build docs and > such when upstream sources require it. I think there's a general consensus > that tetex simply isn't adequate for "real" TeX users, so they have to > replace it with TeX Live in order to do their own work. I must be missing something important. I've been using the tetex included with Slackware since I adopted this distribution in 2003. I've writen a book in it (published by Springer), prepare figures and plots with PSTricks, and do more than 90% of my writing with it (using the LyX front end for convenience). I recall reading several years ago that the tetex author (Tom E) was no longer maintaining it so it would be replaced. I thought that TeXLive was the replacement, yet I see that tetex is still in the Slackware distributions. Over the past decade I've not experienced any deficiencies in my use of tetex. I switched to TeXLive-2010 only because I thought tetex was deprecated. None of this bears on Robby's anguish over how to move TeXLive into the distribution, yet I'd like to learn why tetex is not adequate (I consider myself a 'real' LaTeX user) and why it's still in the distribution if maintanence was dropped a while ago. A curious mind would like to know, Rich From belka.ew at gmail.com Tue Jul 1 13:10:30 2014 From: belka.ew at gmail.com (Eugen Wissner) Date: Tue, 1 Jul 2014 15:10:30 +0200 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> <20140630232742.17089a98@home.rlworkman.net> Message-ID: tetex is really deprecated and the author of tetex said to use TeXLive instead of tetex. Slackware still ships tetex because of its size. Slackware is 1-dvd (4CD) distribution and texlive would need an additional space. Because of that Robby wants to create a smaller "main" package and do available everything else from SBo. Eugene 2014-07-01 14:55 GMT+02:00 Rich Shepard : > On Mon, 30 Jun 2014, Robby Workman wrote: > > Well, we need a TeX distribution in Slackware, if only to build docs and >> such when upstream sources require it. I think there's a general consensus >> that tetex simply isn't adequate for "real" TeX users, so they have to >> replace it with TeX Live in order to do their own work. >> > > I must be missing something important. I've been using the tetex included > with Slackware since I adopted this distribution in 2003. I've writen a > book > in it (published by Springer), prepare figures and plots with PSTricks, and > do more than 90% of my writing with it (using the LyX front end for > convenience). I recall reading several years ago that the tetex author (Tom > E) was no longer maintaining it so it would be replaced. I > thought that TeXLive was the replacement, yet I see that tetex is still in > the Slackware distributions. > > Over the past decade I've not experienced any deficiencies in my use of > tetex. I switched to TeXLive-2010 only because I thought tetex was > deprecated. > > None of this bears on Robby's anguish over how to move TeXLive into the > distribution, yet I'd like to learn why tetex is not adequate (I consider > myself a 'real' LaTeX user) and why it's still in the distribution if > maintanence was dropped a while ago. > > A curious mind would like to know, > > Rich > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jim.Diamond at acadiau.ca Tue Jul 1 14:31:10 2014 From: Jim.Diamond at acadiau.ca (Jim Diamond) Date: Tue, 1 Jul 2014 11:31:10 -0300 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> <20140630232742.17089a98@home.rlworkman.net> Message-ID: <20140701143110.GA29105@jdiamond-nb2> On Tue, Jul 1, 2014 at 05:55 (-0700), Rich Shepard wrote: > On Mon, 30 Jun 2014, Robby Workman wrote: >>Well, we need a TeX distribution in Slackware, if only to build docs and >>such when upstream sources require it. I think there's a general consensus >>that tetex simply isn't adequate for "real" TeX users, so they have to >>replace it with TeX Live in order to do their own work. > I must be missing something important. I've been using the tetex included > with Slackware since I adopted this distribution in 2003. I've writen a book > in it (published by Springer), prepare figures and plots with PSTricks, and > do more than 90% of my writing with it (using the LyX front end for > convenience). I recall reading several years ago that the tetex author (Tom > E) was no longer maintaining it so it would be replaced. I > thought that TeXLive was the replacement, yet I see that tetex is still in > the Slackware distributions. > Over the past decade I've not experienced any deficiencies in my use of > tetex. I switched to TeXLive-2010 only because I thought tetex was > deprecated. > None of this bears on Robby's anguish over how to move TeXLive into the > distribution, yet I'd like to learn why tetex is not adequate (I consider > myself a 'real' LaTeX user) and why it's still in the distribution if > maintanence was dropped a while ago. > A curious mind would like to know, A lot has changed in the TeX world since Tom Esser (IIRC) stopped maintaining tetex. One of the beauties of TeX, of course, is that you should be able to tex some document you created in 1985 and get the same output. However, there are a lot of new features which people use. For example, I stopped using PSTricks long ago in favour of TikZ (not to suggest it is uniformly superior), and assuming TikZ is not found in Slackware's tetex, I'd be dead in the water trying to use it. Judging by info on comp.text.tex, there have been lots of updates and additions to PSTricks in the last few years, so anyone using TE's last version of tetex would be out of luck on that. And luatex has come a long way recently, I perceive a lot of people are moving to that. So I'd say it is not so much that tetex has "deficiencies", but it is (now) a small subset of what TeX currently is. And anyone who is making use of "new" features can't live in the tetex world. Cheers. Jim From rshepard at appl-ecosys.com Tue Jul 1 14:54:23 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Tue, 1 Jul 2014 07:54:23 -0700 (PDT) Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: <20140701143110.GA29105@jdiamond-nb2> References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> <20140630232742.17089a98@home.rlworkman.net> <20140701143110.GA29105@jdiamond-nb2> Message-ID: On Tue, 1 Jul 2014, Jim Diamond wrote: > However, there are a lot of new features which people use. For example, I > stopped using PSTricks long ago in favour of TikZ (not to suggest it is > uniformly superior), and assuming TikZ is not found in Slackware's tetex, > I'd be dead in the water trying to use it. Jim, That's certainly reasonable. I stick with PSTricks because it's familiar and I have Herbert's books. I do upgrade when he makes changes so the backend (TeXLive since Tom Esser recommended it) is really immaterial for me. > Judging by info on comp.text.tex, there have been lots of updates and > additions to PSTricks in the last few years, so anyone using TE's last > version of tetex would be out of luck on that. Makes sense. > So I'd say it is not so much that tetex has "deficiencies", but it is > (now) a small subset of what TeX currently is. And anyone who is making > use of "new" features can't live in the tetex world. True. I've not looked closely at what's included with TeXLive, I just keep upgrading and using it. :-) Many thanks for the explanations, Rich From rsamurti at gmail.com Tue Jul 1 15:30:44 2014 From: rsamurti at gmail.com (Ananda Murthy R S) Date: Tue, 1 Jul 2014 21:00:44 +0530 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <3135791.5bzgfYpvNb@jerseybastion> <20140627162317.56764bfa@home.rlworkman.net> <20140627220829.GA16056@jdiamond-nb2> <20140627232052.2b7ff834@home.rlworkman.net> <20140630232742.17089a98@home.rlworkman.net> <20140701143110.GA29105@jdiamond-nb2> Message-ID: Hello, I also prefer a single texlive package containing everything even though it is bulky. Any way, the build script for this can be made available in SlackBuilds. Only those who want Texlive can build. Anand On Tue, Jul 1, 2014 at 8:24 PM, Rich Shepard wrote: > On Tue, 1 Jul 2014, Jim Diamond wrote: > > However, there are a lot of new features which people use. For example, I >> stopped using PSTricks long ago in favour of TikZ (not to suggest it is >> uniformly superior), and assuming TikZ is not found in Slackware's tetex, >> I'd be dead in the water trying to use it. >> > > Jim, > > That's certainly reasonable. I stick with PSTricks because it's familiar > and I have Herbert's books. I do upgrade when he makes changes so the > backend (TeXLive since Tom Esser recommended it) is really immaterial for > me. > > > Judging by info on comp.text.tex, there have been lots of updates and >> additions to PSTricks in the last few years, so anyone using TE's last >> version of tetex would be out of luck on that. >> > > Makes sense. > > > So I'd say it is not so much that tetex has "deficiencies", but it is >> (now) a small subset of what TeX currently is. And anyone who is making >> use of "new" features can't live in the tetex world. >> > > True. I've not looked closely at what's included with TeXLive, I just > keep > upgrading and using it. :-) > > Many thanks for the explanations, > > Rich > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -- Close Windows ! Open source !! Free software from proprietary mafia !!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From yalhcru at gmail.com Wed Jul 2 00:22:47 2014 From: yalhcru at gmail.com (B Watson) Date: Tue, 1 Jul 2014 20:22:47 -0400 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <20140628131034.1ce1c817@home.rlworkman.net> <20140630234143.631997ef@home.rlworkman.net> <9D7A6AFE-B732-457E-8732-F910510822E6@gmail.com> Message-ID: On 7/1/14, Eugen Wissner wrote: > Right, it can be a dependency for documentation building; now I understand > why it's needed. I could seriously wish some packages (especially ffmpeg) would make the docs optional (e.g. export DOCS=no, which would add --disable-doc to the configure command). It would save a lot of confusion for new users, and some effort and disk space for those of us who don't need the API docs. My own SlackBuilds, if there are API docs, I like to make them optional, especially large ones, or ones that need tex to build, or *especially* ones that need some other 3rd-party package to build the docs (that almost nobody is going to read). A bit more on-topic here: if texlive is being split into a core package that will be on the next DVD release, plus extra bits that come from SBo if needed, it would be worthwhile to go through the SBo builds that depend on tex and make sure the stuff most of them need will be in the core package (if feasible, I know space on the DVD is a concern). If I can find some time in the next few days, I'll see if I can semi-automate this testing: run each build once with all of Robby's texlive stuff installed, and once with only the core package, see which ones fail, and see whether the generated docs are identical in both runs... but there's no point doing this until the final decision is made on what goes on the DVD and what doesn't... and it'd be nice to have a list of all the SBo packages that use tex as part of the build process (not easy to auto-generate this list but if you're reading this and you know your build uses it, reply to this & let us know). Unless of course someone's way ahead of me and has already started doing this... From rworkman at slackbuilds.org Thu Jul 3 02:38:33 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Wed, 2 Jul 2014 21:38:33 -0500 Subject: [Slackbuilds-users] Tex Live 2014 - Update / Part 2 In-Reply-To: References: <20140618184649.461f21f8@home.rlworkman.net> <20140628131034.1ce1c817@home.rlworkman.net> <20140630234143.631997ef@home.rlworkman.net> <9D7A6AFE-B732-457E-8732-F910510822E6@gmail.com> Message-ID: <20140702213833.6f0ad105@home.rlworkman.net> On Tue, 1 Jul 2014 20:22:47 -0400 B Watson wrote: > A bit more on-topic here: if texlive is being split into a core > package that will be on the next DVD release, plus extra bits that > come from SBo if needed, it would be worthwhile to go through the SBo > builds that depend on tex and make sure the stuff most of them need > will be in the core package (if feasible, I know space on the DVD is > a concern). > > If I can find some time in the next few days, I'll see if I can > semi-automate this testing: run each build once with all of Robby's > texlive stuff installed, and once with only the core package, see > which ones fail, and see whether the generated docs are identical in > both runs... but there's no point doing this until the final decision > is made on what goes on the DVD and what doesn't... and it'd be nice > to have a list of all the SBo packages that use tex as part of the > build process (not easy to auto-generate this list but if you're > reading this and you know your build uses it, reply to this & let us > know). > > Unless of course someone's way ahead of me and has already started > doing this... Given the size of what I've come up with coupled with my testing here on *lots* of the Slackware tree, I think it's relatively safe to assume that everything will be fine. We can handle any outliers are we become aware of them - that's just too much time and effort to justify anybody bothering with it IMHO. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rworkman at slackbuilds.org Thu Jul 3 02:45:20 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Wed, 2 Jul 2014 21:45:20 -0500 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) Message-ID: <20140702214520.33157782@home.rlworkman.net> Okay, I think I've got something that we can all accept, even if we're not entirely happy with it. Please go forth and test. http://rlworkman.net/pkgs/sources/14.1/texlive-2014/ rsync://rlworkman.net/rworkman/sources/14.1/texlive-2014/ As before, these links are not permanent, so if you find this in a search engine, don't be surprised to see 404. :-) What I'd prefer is a test to see if your stuff works using *only* the plain "texlive" package - that's the one that I'm hoping Pat will like and be able to shoehorn into Slackware. If something you need is missing from it, then make sure it's present in the texlive-texmf-extra package. If not, then we have a problem. If it is, then all is well, unless you have a really strong case for why it should be included in the main texlive package. On the other hand, if you see something that has little reason to be included in the main texlive package and should be moved into the texlive-texmf-extra package instead, I'd love to hear that too. Assuming good feedback on testing and no major problems, these will be making their way to the main SBo repo soonish. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From melikamp at melikamp.com Thu Jul 3 06:12:40 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Wed, 02 Jul 2014 23:12:40 -0700 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <20140702214520.33157782@home.rlworkman.net> References: <20140702214520.33157782@home.rlworkman.net> Message-ID: <53B4F458.30307@melikamp.com> Everything builds, and the core package seems to work. I have some issue with mathdesign, though, even with everything installed. pdflatex-ing this file \documentclass{amsart} \usepackage[charter]{mathdesign} \begin{document} Hello world! \end{document} yields This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014 on Slackware (SlackBuilds.org)) (preloaded format=pdflatex) restricted \write18 enabled. entering extended mode (./test.tex LaTeX2e <2014/05/01> Babel <3.9k> and hyphenation patterns for 78 languages loaded. (/usr/share/texmf-dist/tex/latex/amscls/amsart.cls Document Class: amsart 2009/07/02 v2.20.1 (/usr/share/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/share/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd) (/usr/share/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) (/usr/share/texmf-dist/tex/latex/mathdesign/mathdesign.sty (/usr/share/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/share/texmf-dist/tex/latex/base/ifthen.sty) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdbch.cfg) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdbch.sty (/usr/share/texmf-dist/tex/latex/mathdesign/mdfont.def) (/usr/share/texmf-dist/tex/latex/mathdesign/mdsffont.def) (/usr/share/texmf-dist/tex/latex/mathdesign/mdttfont.def) (/usr/share/texmf-dist/tex/latex/xkeyval/xkeyval.sty (/usr/share/texmf-dist/tex/generic/xkeyval/xkeyval.tex)) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/ot1mdbch.fd)) (/usr/share/texmf-dist/tex/latex/base/fontenc.sty (/usr/share/texmf-dist/tex/latex/base/t1enc.def) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/t1mdbch.fd))) (./test.aux) (/usr/share/texmf-dist/tex/latex/mathdesign/mdacmr.fd) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbcmr.fd) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/omlmdbch.fd) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/omsmdbch.fd) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/omxmdbch.fd) (/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd) (/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdamdbch.fd) (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdbmdbch.fd) Package mathdesign/mdbch Warning: Package 'amsfonts' shouldn't be used in conjo nction with package mdbch, on input line 3. [1{/usr/share/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] (./test.aux) kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+403/600 --dpi 403 md-chr8y mktexpk: don't know how to create bitmap font for md-chr8y. mktexpk: perhaps md-chr8y is missing from the map file. kpathsea: Appending font creation commands to missfont.log. ) !pdfTeX error: pdflatex (file md-chr8y): Font md-chr8y at 403 not found ==> Fatal error occurred, no output PDF file produced! On 07/02/2014 07:45 PM, Robby Workman wrote: > Okay, I think I've got something that we can all accept, even if we're > not entirely happy with it. Please go forth and test. > > http://rlworkman.net/pkgs/sources/14.1/texlive-2014/ > rsync://rlworkman.net/rworkman/sources/14.1/texlive-2014/ > > As before, these links are not permanent, so if you find this in > a search engine, don't be surprised to see 404. :-) > > What I'd prefer is a test to see if your stuff works using *only* the > plain "texlive" package - that's the one that I'm hoping Pat will like > and be able to shoehorn into Slackware. > > If something you need is missing from it, then make sure it's present > in the texlive-texmf-extra package. If not, then we have a problem. > If it is, then all is well, unless you have a really strong case for > why it should be included in the main texlive package. > > On the other hand, if you see something that has little reason to be > included in the main texlive package and should be moved into the > texlive-texmf-extra package instead, I'd love to hear that too. > > Assuming good feedback on testing and no major problems, these > will be making their way to the main SBo repo soonish. > > -RW > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From rworkman at slackbuilds.org Thu Jul 3 08:13:22 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Thu, 3 Jul 2014 03:13:22 -0500 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <53B4F458.30307@melikamp.com> References: <20140702214520.33157782@home.rlworkman.net> <53B4F458.30307@melikamp.com> Message-ID: <20140703031322.2b250038@home.rlworkman.net> On Wed, 02 Jul 2014 23:12:40 -0700 Ivan Zaigralin wrote: > Everything builds, and the core package seems to work. > I have some issue with mathdesign, though, even with everything > installed. pdflatex-ing this file > > \documentclass{amsart} > \usepackage[charter]{mathdesign} > \begin{document} > Hello world! > \end{document} > > yields > > This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014 on > Slackware (SlackBuilds.org)) (preloaded format=pdflatex) > restricted \write18 enabled. > entering extended mode > (./test.tex > LaTeX2e <2014/05/01> > Babel <3.9k> and hyphenation patterns for 78 languages loaded. > (/usr/share/texmf-dist/tex/latex/amscls/amsart.cls > Document Class: amsart 2009/07/02 v2.20.1 > (/usr/share/texmf-dist/tex/latex/amsmath/amsmath.sty > For additional information on amsmath, use the `?' option. > (/usr/share/texmf-dist/tex/latex/amsmath/amstext.sty > (/usr/share/texmf-dist/tex/latex/amsmath/amsgen.sty)) > (/usr/share/texmf-dist/tex/latex/amsmath/amsbsy.sty) > (/usr/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) > (/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd) > (/usr/share/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) > (/usr/share/texmf-dist/tex/latex/mathdesign/mathdesign.sty > (/usr/share/texmf-dist/tex/latex/graphics/keyval.sty) > (/usr/share/texmf-dist/tex/latex/base/ifthen.sty) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdbch.cfg) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdbch.sty > (/usr/share/texmf-dist/tex/latex/mathdesign/mdfont.def) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdsffont.def) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdttfont.def) > (/usr/share/texmf-dist/tex/latex/xkeyval/xkeyval.sty > (/usr/share/texmf-dist/tex/generic/xkeyval/xkeyval.tex)) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/ot1mdbch.fd)) > (/usr/share/texmf-dist/tex/latex/base/fontenc.sty > (/usr/share/texmf-dist/tex/latex/base/t1enc.def) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/t1mdbch.fd))) > (./test.aux) (/usr/share/texmf-dist/tex/latex/mathdesign/mdacmr.fd) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbcmr.fd) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/omlmdbch.fd) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/omsmdbch.fd) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/omxmdbch.fd) > (/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd) > (/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdamdbch.fd) > (/usr/share/texmf-dist/tex/latex/mathdesign/mdbch/mdbmdbch.fd) > > Package mathdesign/mdbch Warning: Package 'amsfonts' shouldn't be > used in conjo nction with package mdbch, on input line 3. > > [1{/usr/share/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] > (./test.aux) kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag > 0+403/600 --dpi 403 md-chr8y mktexpk: don't know how to create bitmap > font for md-chr8y. mktexpk: perhaps md-chr8y is missing from the map > file. kpathsea: Appending font creation commands to missfont.log. > ) > !pdfTeX error: pdflatex (file md-chr8y): Font md-chr8y at 403 not > found ==> Fatal error occurred, no output PDF file produced! Hrm... reproduced here. Did this work in the first iteration I posted here (when everything was bundled all together in one big package)? If so, maybe I misunderstand what the purpose of the :src stuff is in the texmf tarball. See what happens if you put the contents of the texlive-texmf-src-20140525.tar.xz located at: http://harrier.slackbuilds.org/texlive-2014/ into your /usr/share/ directory (perhaps package it up first for easier removal later), re-run the stuff in texlive's doinst.sh, and see if it works then. If so, that's easy enough to fix up. Otherwise, I have no idea. Well, really, I guess I have no idea now :/ -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From leva at ecentrum.hu Thu Jul 3 09:53:41 2014 From: leva at ecentrum.hu (=?iso-8859-1?Q?L=C9VAI_D=E1niel?=) Date: Thu, 3 Jul 2014 11:53:41 +0200 Subject: [Slackbuilds-users] remove perl-Readonly Message-ID: <20140703095341.GB18510@serenity.local> Hi! Would you please remove perl-Readonly from /ready, it just got an update. Thanks, Daniel -- L?VAI D?niel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F From willysr at slackbuilds.org Thu Jul 3 12:16:39 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 03 Jul 2014 19:16:39 +0700 Subject: [Slackbuilds-users] remove perl-Readonly In-Reply-To: <20140703095341.GB18510@serenity.local> References: <20140703095341.GB18510@serenity.local> Message-ID: <53B549A7.2030600@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Would you please remove perl-Readonly from /ready, it just got an > update. Hi can you send me the updated one? a Diff or Patch is OK and i will merge it directly on my branch - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlO1SaYACgkQiHuDdNczM4F8+ACfeNmQ7C/FHEkkioHNsfnZiZ6M b+cAmwYvMTEZpQor5OF+nKH9NZUpQReh =Kt0P -----END PGP SIGNATURE----- From chaos.proton at gmail.com Fri Jul 4 03:30:57 2014 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 4 Jul 2014 11:30:57 +0800 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <20140702214520.33157782@home.rlworkman.net> References: <20140702214520.33157782@home.rlworkman.net> Message-ID: On Thu, Jul 3, 2014 at 10:45 AM, Robby Workman wrote: > Okay, I think I've got something that we can all accept, even if we're > not entirely happy with it. Please go forth and test. > > http://rlworkman.net/pkgs/sources/14.1/texlive-2014/ > rsync://rlworkman.net/rworkman/sources/14.1/texlive-2014/ > > As before, these links are not permanent, so if you find this in > a search engine, don't be surprised to see 404. :-) > > What I'd prefer is a test to see if your stuff works using *only* the > plain "texlive" package - that's the one that I'm hoping Pat will like > and be able to shoehorn into Slackware. > > If something you need is missing from it, then make sure it's present > in the texlive-texmf-extra package. If not, then we have a problem. > If it is, then all is well, unless you have a really strong case for > why it should be included in the main texlive package. > > I found the ctex package( http://www.ctan.org/pkg/ctex ) is in -extra but I think it's better in the main pkg since so many modern Chinese document is depend on the ctex classes and templates. The location of ctex in the -extra is: usr/share/texmf-dist/tex/latex/ctex/ -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From melikamp at melikamp.com Fri Jul 4 17:37:53 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Fri, 04 Jul 2014 10:37:53 -0700 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <20140703031322.2b250038@home.rlworkman.net> References: <20140702214520.33157782@home.rlworkman.net> <53B4F458.30307@melikamp.com> <20140703031322.2b250038@home.rlworkman.net> Message-ID: <53B6E671.6020806@melikamp.com> > Hrm... reproduced here. Did this work in the first iteration I > posted here (when everything was bundled all together in one big > package)? Bah, I didn't get a chance to test it. Is there still a Slackbuild for the bundle? > If so, maybe I misunderstand what the purpose of the :src stuff > is in the texmf tarball. See what happens if you put the contents > of the texlive-texmf-src-20140525.tar.xz located at: > http://harrier.slackbuilds.org/texlive-2014/ > into your /usr/share/ directory (perhaps package it up first for > easier removal later), re-run the stuff in texlive's doinst.sh, > and see if it works then. If so, that's easy enough to fix up. No effect :( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From bogus at bogzab.plus.com Fri Jul 4 19:34:34 2014 From: bogus at bogzab.plus.com (Bogus Zaba) Date: Fri, 04 Jul 2014 20:34:34 +0100 Subject: [Slackbuilds-users] NX Slackbuiuld for Versio n14.0 In-Reply-To: References: Message-ID: <53B701CA.60508@bogzab.plus.com> I want to update my nx and nxclient packages as Sbopkg suggests I should. However the URL from which one can allegedly pick up the source tarballs (http://64.34.173.142/download/3.5.0/sources/nxproxy-3.5.0-1.tar.gz) cannot be contacted. I note that for Slackware 14.1 the URL for the sources is completely different. If anyone can point me in the right direction I would be grateful. BZ -- Dr Bogumil N Zaba From willysr at slackbuilds.org Fri Jul 4 20:06:33 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 5 Jul 2014 03:06:33 +0700 Subject: [Slackbuilds-users] NX Slackbuiuld for Versio n14.0 In-Reply-To: <53B701CA.60508@bogzab.plus.com> References: <53B701CA.60508@bogzab.plus.com> Message-ID: <94C3D7FB-F4D0-4722-BADF-BB6C10139BB0@slackbuilds.org> > I want to update my nx and nxclient packages as Sbopkg suggests I should. However the URL from which one can allegedly pick up the source tarballs (http://64.34.173.142/download/3.5.0/sources/nxproxy-3.5.0-1.tar.gz) cannot be contacted. I note that for Slackware 14.1 the URL for the sources is completely different. If anyone can point me in the right direction I would be grateful. Grab it from our website http://slackbuilds.org/repository/14.1/network/nxclient/ -- Willy Sudiarto Raharjo -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sat Jul 5 01:59:03 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 05 Jul 2014 08:59:03 +0700 Subject: [Slackbuilds-users] Updates - 20140705.1 Message-ID: <53B75BE7.2040209@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sat Jul 5 01:17:59 UTC 2014 academic/galculator: Updated for version 2.1.3 + new maintainer. academic/gwyddion: Updated for version 2.37. audio/jack2: Fix source URL. business/reckon: Added (ledger csv converter). desktop/neutral: New maintainer. desktop/s1kls: Added (Keyboard Layout Switcher). desktop/superkey-launch: Updated for version 1.6.0. development/KKEdit: Added (simple text editor). development/avarice: Added (GDB for the AVR platform). development/avr-gdb: Added (GDB for the AVR platform). development/brackets: Updated for version 0.41. development/chibi-scheme: Updated for version 0.7. development/idea: Added (Development IDE). development/openocd: Added (jtag interface). development/quilt: Updated for version 0.63 + new maintainer. development/regina-rexx: Updated for version 3.8.2. development/rust: Updated for version 0.11.0. games/Pyfa: Fix typo. games/openmw: Added (Morrowind Engine). gis/grass: Updated for version 6.4.4. gis/qgis: Fixed icons. graphics/digikam: Updated for version 4.1.0. libraries/botocore: Updated for version 0.55.0. libraries/libnfs: Updated for version 1.9.4. libraries/libvirt-python: Updated for version 1.2.6. libraries/libvirt: Updated for version 1.2.6. libraries/opencv: Updated for version 2.4.9. libraries/utfcpp: Added (utf-8 in C++). multimedia/OpenLP: Updated for version 2.0.5. network/FireWorks: Updated for version 0.85. network/awscli: Updated for version 1.3.21. network/copy: Added desktop autostart file. network/dovecot-pigeonhole: Updated for version 0.4.3. network/dovecot: Updated for version 2.2.13. network/flexget: Updated for version 1.2.142. network/libnftnl: Updated for version 1.0.2. network/nft: Updated for version 0.3. network/postfix: Updated for version 2.11.1. network/silc-toolkit: Updated for version 1.1.12. network/sipp: Updated for version 3.4.1. network/skype: Updated for version 4.3.0.37. network/sphinx: Updated for version 2.1.8 + new maintainer. office/osmo: Updated for version r938 + new maintainer. perl/perl-Devel-StackTrace: Updated for version 1.34. perl/perl-Readonly: Updated for version 2.00. perl/perl-Test-Differences: Updated for version 0.62. python/colored: Added (python color library). python/pysed: Updated for version 0.1.9. python/six: Updated for version 1.7.3. ruby/rubygem-fastercsv: Added (ruby csv library). ruby/rubygem-highline: Added (ruby cli library). ruby/rubygem-terminal-table: Added (ascii table library). system/Attic: Updated for version 0.13. system/asbt: Updated for version 0.9.5. system/avfs: Updated for version 1.0.2. system/graphterm: Updated for version 0.56.1. system/mongodb: Updated for version 2.6.3. system/slpkg: Updated for version 1.5.3. system/trachet: Updated for version 1.0.8. system/vifm: Updated for version 0.7.7. - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlO3W+cACgkQiHuDdNczM4GhWgCeI//yTRpwV1dajXq+q3BClzo5 RQIAoJwbrPG5vVzugeHNUqQFvUf/+MXI =VJm4 -----END PGP SIGNATURE----- From rworkman at slackbuilds.org Mon Jul 7 05:09:15 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 7 Jul 2014 00:09:15 -0500 Subject: [Slackbuilds-users] Updates - 20140707.1 Message-ID: <20140707000915.3f8878fb@home.rlworkman.net> Mon Jul 7 05:02:27 UTC 2014 academic/speedcrunch: Updated for version 0.11. desktop/superkey-launch: Update Checksum. development/mysql-workbench: Updated for version 6.1.7. development/smartgithg: Updated for version 6.0.3. development/smartsvn: Updated for version 8.5.5. development/vstudio: Updated for version 5.5.8. development/xmlcopyeditor: Updated for version 1.2.1.2. games/galaxyv2: Updated for version 1.81. games/mednafen: Updated for version 0.9.36.2 + new maintainer. gis/OWSLib: Updated for version 0.8.8. libraries/cffi: Updated for version 0.8.6. libraries/goffice0.8: Fixed invalid linking to pcre libraries/jansson: Updated for version 2.6. libraries/libaacs: Updated for version 0.7.1. libraries/libbdplus: Updated for version 0.1.1. libraries/libbluray: Updated for version 0.6.0. libraries/libdc1394: Updated for version 2.2.2. libraries/libgit2: Added (C library for custom Git applications). libraries/msgpack-c: Updated for version 0.5.9. libraries/qt5: Updated for version 5.3.1. misc/subsurface: Updated for version 4.1. multimedia/xbmc: added patch to compile against libnfs 1.9.4+. office/calibre: Updated for version 1.43.0. office/grisbi: Updated for version 1.0.0. python/MarkupSafe: Updated for version 0.23. python/argh: Updated for version 0.25.0. python/colored: Updated for version 1.0.5. python/lxml: Updated for version 3.3.5. python/pysed: Updated for version 0.2.4. python/rope: Updated for version 0.10.2. python/s3cmd: Updated for version 1.5.0_rc1. python/simplejson: Updated for version 3.5.3. system/mlterm: Updated for version 3.3.7. system/mysql-utilities: Updated for version 1.5.0. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rworkman at slackbuilds.org Mon Jul 7 07:03:25 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 7 Jul 2014 02:03:25 -0500 Subject: [Slackbuilds-users] Abandoned build scripts Message-ID: <20140707020325.6219a5a2@home.rlworkman.net> I'm not sure if it's already been noted on the list or not (I've done a horrible job of keeping up with email in recent months), but vvoody has advised me privately that he's no longer using Slackware and so all of his builds are free to good homes. They are as follows: development/bpython development/pyenchant misc/fcitx misc/fcitx-configtool misc/kcm-fcitx multimedia/mimms network/fqterm network/mew network/opera python/stevedore python/virtualenv-clone python/virtualenvwrapper system/fbterm system/wqy-microhei-font-ttf -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From chaos.proton at gmail.com Mon Jul 7 07:41:19 2014 From: chaos.proton at gmail.com (Grissiom) Date: Mon, 7 Jul 2014 15:41:19 +0800 Subject: [Slackbuilds-users] Abandoned build scripts In-Reply-To: <20140707020325.6219a5a2@home.rlworkman.net> References: <20140707020325.6219a5a2@home.rlworkman.net> Message-ID: On Mon, Jul 7, 2014 at 3:03 PM, Robby Workman wrote: > I'm not sure if it's already been noted on the list or not (I've > done a horrible job of keeping up with email in recent months), > but vvoody has advised me privately that he's no longer using > Slackware and so all of his builds are free to good homes. > They are as follows: > misc/fcitx > misc/fcitx-configtool > misc/kcm-fcitx > So I would like the take the fcitx ones and > system/wqy-microhei-font-ttf > > the wqy fonts. ================================================= Moreover, I'd like to abandon some of my Slackbuilds: network/mldonkey libraries/libsunpinyin misc/ibus-pinyin misc/ibus-qt misc/ibus-sunpinyin misc/ibus development/generatorrunner development/sdcc Feel free to take them if you are interested. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From didier.spaier at epsm.fr Mon Jul 7 09:17:46 2014 From: didier.spaier at epsm.fr (Didier Spaier) Date: Mon, 07 Jul 2014 11:17:46 +0200 Subject: [Slackbuilds-users] Abandoned build scripts In-Reply-To: <20140707020325.6219a5a2@home.rlworkman.net> References: <20140707020325.6219a5a2@home.rlworkman.net> Message-ID: <53BA65BA.2090106@epsm.fr> On 07/07/2014 09:03, Robby Workman wrote: > I'm not sure if it's already been noted on the list or not (I've > done a horrible job of keeping up with email in recent months), > but vvoody has advised me privately that he's no longer using > Slackware and so all of his builds are free to good homes. > They are as follows: > > development/bpython > development/pyenchant > misc/fcitx > misc/fcitx-configtool > misc/kcm-fcitx > multimedia/mimms > network/fqterm > network/mew > network/opera > python/stevedore > python/virtualenv-clone > python/virtualenvwrapper > system/fbterm > system/wqy-microhei-font-ttf I use fbterm in the new slint installers so I can take it over. I can take also wqy-microhei-font-ttf that can be used with it (though I don"t know if it's better than wqy-zenhei shipped in Slackware, but I can ask Chinese speaking Slackware users. Any opinion if one read this?). Didier From didier.spaier at epsm.fr Mon Jul 7 09:25:35 2014 From: didier.spaier at epsm.fr (Didier Spaier) Date: Mon, 07 Jul 2014 11:25:35 +0200 Subject: [Slackbuilds-users] Abandoned build scripts In-Reply-To: <53BA65BA.2090106@epsm.fr> References: <20140707020325.6219a5a2@home.rlworkman.net> <53BA65BA.2090106@epsm.fr> Message-ID: <53BA678F.4070700@epsm.fr> On 07/07/2014 11:17, Didier Spaier wrote: > > On 07/07/2014 09:03, Robby Workman wrote: >> I'm not sure if it's already been noted on the list or not (I've >> done a horrible job of keeping up with email in recent months), >> but vvoody has advised me privately that he's no longer using >> Slackware and so all of his builds are free to good homes. >> They are as follows: >> >> development/bpython >> development/pyenchant >> misc/fcitx >> misc/fcitx-configtool >> misc/kcm-fcitx >> multimedia/mimms >> network/fqterm >> network/mew >> network/opera >> python/stevedore >> python/virtualenv-clone >> python/virtualenvwrapper >> system/fbterm >> system/wqy-microhei-font-ttf > > I use fbterm in the new slint installers so I can take it over. > I can take also wqy-microhei-font-ttf that can be used with it > (though I don"t know if it's better than wqy-zenhei shipped in > Slackware, but I can ask Chinese speaking Slackware users. > Any opinion if one read this?). Sorry I didn't read Grissiom's answer before posting. I don't claim wqy-microhei-font-ttf then. Didier From rworkman at slackbuilds.org Wed Jul 9 05:04:06 2014 From: rworkman at slackbuilds.org (Robby Workman) Date: Wed, 9 Jul 2014 00:04:06 -0500 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <53B6E671.6020806@melikamp.com> References: <20140702214520.33157782@home.rlworkman.net> <53B4F458.30307@melikamp.com> <20140703031322.2b250038@home.rlworkman.net> <53B6E671.6020806@melikamp.com> Message-ID: <20140709000406.56f8d58e@home.rlworkman.net> On Fri, 04 Jul 2014 10:37:53 -0700 Ivan Zaigralin wrote: > > Hrm... reproduced here. Did this work in the first iteration I > > posted here (when everything was bundled all together in one big > > package)? > > Bah, I didn't get a chance to test it. Is there still a Slackbuild > for the bundle? > > > If so, maybe I misunderstand what the purpose of the :src stuff > > is in the texmf tarball. See what happens if you put the contents > > of the texlive-texmf-src-20140525.tar.xz located at: > > http://harrier.slackbuilds.org/texlive-2014/ > > into your /usr/share/ directory (perhaps package it up first for > > easier removal later), re-run the stuff in texlive's doinst.sh, > > and see if it works then. If so, that's easy enough to fix up. > > No effect :( Okay, maybe someone can tell me what's wrong - i.e. why this has to be done in order for things to work. I *thought* the doinst.sh stuff would handle this... If I do this as root: updmap-sys --enable Map mdbch.map then that pdflatex run on your tex file works fine (it still spits out the warning about the amsfonts used in conjunction with some other font, but that's harmless, based on what I gather from the web). What am I missing here? -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From melikamp at melikamp.com Sat Jul 12 01:50:27 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Fri, 11 Jul 2014 18:50:27 -0700 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <20140709000406.56f8d58e@home.rlworkman.net> References: <20140702214520.33157782@home.rlworkman.net> <53B4F458.30307@melikamp.com> <20140703031322.2b250038@home.rlworkman.net> <53B6E671.6020806@melikamp.com> <20140709000406.56f8d58e@home.rlworkman.net> Message-ID: <53C09463.7030008@melikamp.com> On 07/08/2014 10:04 PM, Robby Workman wrote: > updmap-sys --enable Map mdbch.map Sorry for the delay. Indeed, it fixes the mdbch issue. The other mathdesign fonts (such as utopia) are still broken, but I assume can be fixed in a similar way. I am not sure why this extra step is required, but I'll try to figure it out. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From zacts.3.14159 at gmail.com Sat Jul 12 05:12:26 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Fri, 11 Jul 2014 23:12:26 -0600 Subject: [Slackbuilds-users] A Patch to convert tthe perl/perl-IO-Tty slackbuild to use metacpan. Message-ID: Hi, The cpan link is dead, breaking a few of my sboinstall builds. Attached is my patch to convert the perl/perl-IO-Tty slackbuild to use metacpan. Thanks, Zac --- Zachary Storer zacts on irc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-perl-perl-IO-Tty-Convert-from-cpan-to-metacpan.patch Type: text/x-patch Size: 918 bytes Desc: not available URL: From willysr at slackbuilds.org Sat Jul 12 08:28:32 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 12 Jul 2014 15:28:32 +0700 Subject: [Slackbuilds-users] A Patch to convert tthe perl/perl-IO-Tty slackbuild to use metacpan. In-Reply-To: References: Message-ID: <53C0F1B0.7090604@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The cpan link is dead, breaking a few of my sboinstall builds. > Attached is my patch to convert the perl/perl-IO-Tty slackbuild to use metacpan. Applied in my Branch Thanks - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPA8a8ACgkQiHuDdNczM4EPJACdFMg/krgxQaOHUAVk1pzJjICh hrgAn3D+zgNSRGa2RcSGboKnHSw+INFA =UYwA -----END PGP SIGNATURE----- From hostmaster at slackonly.com Sat Jul 12 10:08:17 2014 From: hostmaster at slackonly.com (hostmaster) Date: Sat, 12 Jul 2014 13:08:17 +0300 Subject: [Slackbuilds-users] camlp5 Message-ID: <53C10911.7000100@slackonly.com> Hi! building camlp5-6.02.3 points to error: Sorry: the compatibility with ocaml version "4.01.0" is not yet implemented. Please report. Information: directory ocaml_stuff/4.01.0 is missing. Installed dependencie ocaml 4.01.0 from SBo. From willysr at slackbuilds.org Sat Jul 12 15:36:57 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 12 Jul 2014 22:36:57 +0700 Subject: [Slackbuilds-users] camlp5 In-Reply-To: <53C10911.7000100@slackonly.com> References: <53C10911.7000100@slackonly.com> Message-ID: <53C15619.4030001@slackbuilds.org> On Sat 12 Jul 2014 05:08:17 PM WIB, hostmaster wrote: > Hi! > > building camlp5-6.02.3 points to error: > > Sorry: the compatibility with ocaml version "4.01.0" > is not yet implemented. Please report. > Information: directory ocaml_stuff/4.01.0 is missing. > > Installed dependencie ocaml 4.01.0 from SBo. I think you should contact the maintainer and ask him to update the package to newer version (currently 6.11) to be compatible with ocaml 4.01.0 -- Willy Sudiarto Raharjo From willysr at slackbuilds.org Sat Jul 12 15:38:47 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 12 Jul 2014 22:38:47 +0700 Subject: [Slackbuilds-users] camlp5 In-Reply-To: <53C15619.4030001@slackbuilds.org> References: <53C10911.7000100@slackonly.com> <53C15619.4030001@slackbuilds.org> Message-ID: <53C15687.7010900@slackbuilds.org> >> building camlp5-6.02.3 points to error: >> >> Sorry: the compatibility with ocaml version "4.01.0" >> is not yet implemented. Please report. >> Information: directory ocaml_stuff/4.01.0 is missing. >> >> Installed dependencie ocaml 4.01.0 from SBo. > > I think you should contact the maintainer and ask him to update the > package to newer version (currently 6.11) to be compatible with ocaml > 4.01.0 the email bounced back, so i guess you can take over this package and submit a newer version if you don't mind -- Willy Sudiarto Raharjo From hostmaster at slackonly.com Sat Jul 12 16:09:18 2014 From: hostmaster at slackonly.com (Panagiotis Nikolaou) Date: Sat, 12 Jul 2014 19:09:18 +0300 Subject: [Slackbuilds-users] camlp5 In-Reply-To: <53C15687.7010900@slackbuilds.org> References: <53C10911.7000100@slackonly.com> <53C15619.4030001@slackbuilds.org> <53C15687.7010900@slackbuilds.org> Message-ID: <53C15DAE.7060805@slackonly.com> On 07/12/2014 06:38 PM, Willy Sudiarto Raharjo wrote: >>> building camlp5-6.02.3 points to error: >>> >>> Sorry: the compatibility with ocaml version "4.01.0" >>> is not yet implemented. Please report. >>> Information: directory ocaml_stuff/4.01.0 is missing. >>> >>> Installed dependencie ocaml 4.01.0 from SBo. >> I think you should contact the maintainer and ask him to update the >> package to newer version (currently 6.11) to be compatible with ocaml >> 4.01.0 > the email bounced back, so i guess you can take over this package and > submit a newer version if you don't mind > > > -- > Willy Sudiarto Raharjo > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > OK submit now a newer version in SBo... Thanks... From melikamp at melikamp.com Sun Jul 13 03:26:06 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Sat, 12 Jul 2014 20:26:06 -0700 Subject: [Slackbuilds-users] TeX Live 2014 #3 (third time's the charm?) In-Reply-To: <20140709000406.56f8d58e@home.rlworkman.net> References: <20140702214520.33157782@home.rlworkman.net> <53B4F458.30307@melikamp.com> <20140703031322.2b250038@home.rlworkman.net> <53B6E671.6020806@melikamp.com> <20140709000406.56f8d58e@home.rlworkman.net> Message-ID: <53C1FC4E.8010308@melikamp.com> Robby, may be this has something to do with it. When I build and install your current texlive-2013 SB, there is no /usr/share/texmf-config/web2c/updmap.cfg When I install texlive-2014 + extra, that file exists post-install and every font in there is commented out. When I run updmap-sys --enable Map mdbch.map mdbch line gets uncommented. On 07/08/2014 10:04 PM, Robby Workman wrote: > On Fri, 04 Jul 2014 10:37:53 -0700 > Ivan Zaigralin wrote: > >>> Hrm... reproduced here. Did this work in the first iteration I >>> posted here (when everything was bundled all together in one big >>> package)? >> >> Bah, I didn't get a chance to test it. Is there still a Slackbuild >> for the bundle? >> >>> If so, maybe I misunderstand what the purpose of the :src stuff >>> is in the texmf tarball. See what happens if you put the contents >>> of the texlive-texmf-src-20140525.tar.xz located at: >>> http://harrier.slackbuilds.org/texlive-2014/ >>> into your /usr/share/ directory (perhaps package it up first for >>> easier removal later), re-run the stuff in texlive's doinst.sh, >>> and see if it works then. If so, that's easy enough to fix up. >> >> No effect :( > > Okay, maybe someone can tell me what's wrong - i.e. why this has > to be done in order for things to work. I *thought* the doinst.sh > stuff would handle this... > > If I do this as root: > updmap-sys --enable Map mdbch.map > > then that pdflatex run on your tex file works fine (it still spits > out the warning about the amsfonts used in conjunction with some > other font, but that's harmless, based on what I gather from the > web). > > What am I missing here? > > -RW > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From kingbeowulf at gmail.com Sun Jul 13 18:18:32 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 13 Jul 2014 11:18:32 -0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch Message-ID: <53C2CD78.1090706@gmail.com> I just realized a fix for a glitch with the new nvidia-driver and CUDA initialization. Since the slackbuild is already in "approved" and its not fatal unless you run CUDA/OpenCL programs, I'll fix this up on the next update. This issue popped up somewhere in the 331.xx drivers. For those of you, as I do, who run BOINC, or another CUDA program, you may have wondered about "no usable GPUs found" message in the BOINC log. Turns out, some weird process in the way Nvidia does things now, since the introduction of nvidia-uvm.ko, prevents the creation of a required device node unless you first run your CUDA program as "root." This then creates the device node and all is then well as a regular user. You should see: $ ls -l /dev/nvidia-uvm crw-rw-rw- 1 root root 248, 0 Jul 13 01:45 /dev/nvidia-uvm A quick test program, as well as possible fixes, are in the Reference below. The question now is, how best to handle this in the slackbuild? 1. put this in doinst.sh mknod -m 660 /dev/nvidia-uvm c 249 0 chgrp video /dev/nvidia-uvm 2. udev rule? KERNEL=="nvidia_uvm", RUN+="/usr/bin/bash -c '/usr/bin/mknod -m 666 /dev/nvidia-uvm c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 0; /usr/bin/chgrp video /dev/nvidia-uvm'" 3. Compile nvidia-modprobe by default (optional now) so that X userland can make the node, or invoke via doinst.sh if not. I'll post this in LQ as well to get better coverage. References: 1. https://devtalk.nvidia.com/default/topic/699610/334-21-driver-returns-999-on-cuinit-cuda-/ 2. http://us.download.nvidia.com/XFree86/Linux-x86/340.24/README/faq.html From yalhcru at gmail.com Sun Jul 13 21:38:40 2014 From: yalhcru at gmail.com (B Watson) Date: Sun, 13 Jul 2014 17:38:40 -0400 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C2CD78.1090706@gmail.com> References: <53C2CD78.1090706@gmail.com> Message-ID: On 7/13/14, King Beowulf wrote: > 1. put this in doinst.sh > mknod -m 660 /dev/nvidia-uvm c 249 0 > chgrp video /dev/nvidia-uvm Will the device node persist across a reboot? Last time I tried something like this (a while back), the device node had to be created in something like rc.local (due to /dev being virtual). You could create the node in /lib/udev/devices (which is used to populate /dev on every boot, and contains nodes like null, zero, urandom). doinst.sh should probably create both /dev/nvidia-uvm (for use now) and /lib/udev/devices/nvidia-uvm (to be used on next reboot). I've seen shutdown scripts for other Linux distros that look for new device nodes in /dev and store them elsewhere, so they can be re-created on the next boot. I don't see anything like this in either rc.0 or rc.udev on Slack 14, but I only took a minute to look at them (I might have missed it). > 2. udev rule? > KERNEL=="nvidia_uvm", RUN+="/usr/bin/bash -c '/usr/bin/mknod -m 666 > /dev/nvidia-uvm c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 0; > /usr/bin/chgrp video /dev/nvidia-uvm'" This seems like the "proper" solution, assuming it actually works (haven't tested, I'm currently using nouveau, not nvidia). > 3. Compile nvidia-modprobe by default (optional now) so that X userland > can make the node, or invoke via doinst.sh if not. No clue about this one, so no comment. From mats.bertil.tegner at gmail.com Sun Jul 13 22:39:24 2014 From: mats.bertil.tegner at gmail.com (Mats Bertil Tegner) Date: Mon, 14 Jul 2014 00:39:24 +0200 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C2CD78.1090706@gmail.com> References: <53C2CD78.1090706@gmail.com> Message-ID: <53C30A9C.2080305@gmail.com> On 2014-07-13 20:18, King Beowulf wrote: > I just realized a fix for a glitch with the new nvidia-driver and CUDA > initialization. Since the slackbuild is already in "approved" and its > not fatal unless you run CUDA/OpenCL programs, I'll fix this up on the > next update. This issue popped up somewhere in the 331.xx drivers. > > For those of you, as I do, who run BOINC, or another CUDA program, you > may have wondered about "no usable GPUs found" message in the BOINC log. > Turns out, some weird process in the way Nvidia does things now, since > the introduction of nvidia-uvm.ko, prevents the creation of a required > device node unless you first run your CUDA program as "root." This then > creates the device node and all is then well as a regular user. You > should see: > > $ ls -l /dev/nvidia-uvm > crw-rw-rw- 1 root root 248, 0 Jul 13 01:45 /dev/nvidia-uvm > > A quick test program, as well as possible fixes, are in the Reference > below. The question now is, how best to handle this in the slackbuild? > > 1. put this in doinst.sh > mknod -m 660 /dev/nvidia-uvm c 249 0 > chgrp video /dev/nvidia-uvm > > 2. udev rule? > KERNEL=="nvidia_uvm", RUN+="/usr/bin/bash -c '/usr/bin/mknod -m 666 > /dev/nvidia-uvm c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 0; > /usr/bin/chgrp video /dev/nvidia-uvm'" > > 3. Compile nvidia-modprobe by default (optional now) so that X userland > can make the node, or invoke via doinst.sh if not. > > I'll post this in LQ as well to get better coverage. > > References: > 1. > https://devtalk.nvidia.com/default/topic/699610/334-21-driver-returns-999-on-cuinit-cuda-/ > 2. > http://us.download.nvidia.com/XFree86/Linux-x86/340.24/README/faq.html Thanks for the heads-up. I need CUDA/OpenCL support right now. Using the .run-file will give me the nvidia-uvm device. Regards, Mats From kingbeowulf at gmail.com Mon Jul 14 01:09:04 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 13 Jul 2014 18:09:04 -0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C30A9C.2080305@gmail.com> References: <53C2CD78.1090706@gmail.com> <53C30A9C.2080305@gmail.com> Message-ID: <53C32DB0.8090907@gmail.com> On 07/13/2014 03:39 PM, Mats Bertil Tegner wrote: > On 2014-07-13 20:18, King Beowulf wrote: >> I just realized a fix for a glitch with the new nvidia-driver and CUDA >> initialization. Since the slackbuild is already in "approved" and its >> not fatal unless you run CUDA/OpenCL programs, I'll fix this up on the >> next update. This issue popped up somewhere in the 331.xx drivers. >> >> For those of you, as I do, who run BOINC, or another CUDA program, you >> may have wondered about "no usable GPUs found" message in the BOINC log. >> Turns out, some weird process in the way Nvidia does things now, since >> the introduction of nvidia-uvm.ko, prevents the creation of a required >> device node unless you first run your CUDA program as "root." This then >> creates the device node and all is then well as a regular user. You >> should see: >> >> $ ls -l /dev/nvidia-uvm >> crw-rw-rw- 1 root root 248, 0 Jul 13 01:45 /dev/nvidia-uvm >> >> A quick test program, as well as possible fixes, are in the Reference >> below. The question now is, how best to handle this in the slackbuild? >> >> 1. put this in doinst.sh >> mknod -m 660 /dev/nvidia-uvm c 249 0 >> chgrp video /dev/nvidia-uvm >> >> 2. udev rule? >> KERNEL=="nvidia_uvm", RUN+="/usr/bin/bash -c '/usr/bin/mknod -m 666 >> /dev/nvidia-uvm c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 0; >> /usr/bin/chgrp video /dev/nvidia-uvm'" >> >> 3. Compile nvidia-modprobe by default (optional now) so that X userland >> can make the node, or invoke via doinst.sh if not. >> >> I'll post this in LQ as well to get better coverage. >> >> References: >> 1. >> https://devtalk.nvidia.com/default/topic/699610/334-21-driver-returns-999-on-cuinit-cuda-/ >> >> 2. >> http://us.download.nvidia.com/XFree86/Linux-x86/340.24/README/faq.html > > Thanks for the heads-up. I need CUDA/OpenCL support right now. Using the > .run-file will give me the nvidia-uvm device. > > Regards, > Mats > You just need to run OPTAPPS=yes ./nvidia-driver.SlackBuild to compile it. After reboot, run as root "nvidia-modprobe -c 0 -u" This will create any missing dev nodes. This does not survive reboot, so udev rules are teh way to go but I am a bit clueless there. -Ed From kingbeowulf at gmail.com Mon Jul 14 01:11:25 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 13 Jul 2014 18:11:25 -0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: References: <53C2CD78.1090706@gmail.com> Message-ID: <53C32E3D.3000707@gmail.com> On 07/13/2014 02:38 PM, B Watson wrote: ... >> 2. udev rule? >> KERNEL=="nvidia_uvm", RUN+="/usr/bin/bash -c '/usr/bin/mknod -m 666 >> /dev/nvidia-uvm c $(grep nvidia-uvm /proc/devices | cut -d \ -f 1) 0; >> /usr/bin/chgrp video /dev/nvidia-uvm'" > > This seems like the "proper" solution, assuming it actually works > (haven't tested, I'm currently using nouveau, not nvidia). > ... I think so too. Hopefully someone chimes in to give me a clue on writing a proper udev rule. The example is from the nvidia dev forum. -Ed From mats.bertil.tegner at gmail.com Mon Jul 14 09:39:17 2014 From: mats.bertil.tegner at gmail.com (Mats Bertil Tegner) Date: Mon, 14 Jul 2014 11:39:17 +0200 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C32DB0.8090907@gmail.com> References: <53C2CD78.1090706@gmail.com> <53C30A9C.2080305@gmail.com> <53C32DB0.8090907@gmail.com> Message-ID: <53C3A545.1030500@gmail.com> King Beowulf skrev 2014-07-14 03:09: >> Thanks for the heads-up. I need CUDA/OpenCL support right now. Using the >> .run-file will give me the nvidia-uvm device. >> >> Regards, >> Mats >> > You just need to run OPTAPPS=yes ./nvidia-driver.SlackBuild to compile > it. After reboot, run as root "nvidia-modprobe -c 0 -u" This will > create any missing dev nodes. > > This does not survive reboot, so udev rules are the way to go but I am > a bit clueless there. > > -Ed Ok, I will rebuild the nvidia SlackBuilds. Not sure I need the dev to survive a reboot, will check... Mats From thedoogster at gmail.com Mon Jul 14 21:08:28 2014 From: thedoogster at gmail.com (Doogster) Date: Mon, 14 Jul 2014 14:08:28 -0700 Subject: [Slackbuilds-users] Needing requirements built with options Message-ID: I'm about to submit a new version of gnome-inform7, and I've run into a problem. It requires gst1-plugins-bad, and it needs gst1-plugins-bad to have been built with libmodplug support. The problem is that gst1-plugins-bad lists libmodplug as an optional dependency, not as a hard one. How should I handle that, The best solution I can think of is to specify gst1-plugins-bad in the info file as a hard requirement, then mention in the README that gst1-plugins-bad needs to have been built against libmodplug. Is there a better way? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Mon Jul 14 21:39:04 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Mon, 14 Jul 2014 14:39:04 -0700 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: References: Message-ID: <53C44DF8.8040504@gmail.com> On 07/14/2014 02:08 PM, Doogster wrote: > I'm about to submit a new version of gnome-inform7, and I've run into a > problem. It requires gst1-plugins-bad, and it needs gst1-plugins-bad to > have been built with libmodplug support. The problem is that > gst1-plugins-bad lists libmodplug as an optional dependency, not as a > hard one. How should I handle that, > > The best solution I can think of is to specify gst1-plugins-bad in the > info file as a hard requirement, then mention in the README that > gst1-plugins-bad needs to have been built against libmodplug. Is there a > better way? > IMO, think that is the best way. Specify the dep in .info, then give "gotchas" in the README. This might trip up the sbopkg users, but short of including a "special" gst1-plugings-bad, it'll be hard to cover every use case. After all, we should all be reading the README, right? -Ed From ryanpcmcquen at gmail.com Mon Jul 14 21:45:13 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Mon, 14 Jul 2014 14:45:13 -0700 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: <53C44DF8.8040504@gmail.com> References: <53C44DF8.8040504@gmail.com> Message-ID: <49DEAB36-08FC-4BA9-8629-258E9F643C24@gmail.com> If there are other situations meriting gst1-plugins-bad built against libmodplug, wouldn't it be worth it to make it a hard dependency? Does anyone really mind one extra package if it means better compatibility down the road? --- > On Jul 14, 2014, at 2:39 PM, King Beowulf wrote: > >> On 07/14/2014 02:08 PM, Doogster wrote: >> I'm about to submit a new version of gnome-inform7, and I've run into a >> problem. It requires gst1-plugins-bad, and it needs gst1-plugins-bad to >> have been built with libmodplug support. The problem is that >> gst1-plugins-bad lists libmodplug as an optional dependency, not as a >> hard one. How should I handle that, >> >> The best solution I can think of is to specify gst1-plugins-bad in the >> info file as a hard requirement, then mention in the README that >> gst1-plugins-bad needs to have been built against libmodplug. Is there a >> better way? > > IMO, think that is the best way. Specify the dep in .info, then give > "gotchas" in the README. This might trip up the sbopkg users, but short > of including a "special" gst1-plugings-bad, it'll be hard to cover every > use case. After all, we should all be reading the README, right? > > -Ed > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From thedoogster at gmail.com Mon Jul 14 22:52:08 2014 From: thedoogster at gmail.com (Doogster) Date: Mon, 14 Jul 2014 15:52:08 -0700 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: <49DEAB36-08FC-4BA9-8629-258E9F643C24@gmail.com> References: <53C44DF8.8040504@gmail.com> <49DEAB36-08FC-4BA9-8629-258E9F643C24@gmail.com> Message-ID: I would prefer that the only hard dependencies specified for gst1-plugins-bad be the ones that gst1-plugins-bad need in order to be built. If you start specifying optional dependencies as hard ones because unrelated packages need them, then you end up with a mess like Debian where installing Mutt on your headless server installs X. On Monday, July 14, 2014, Ryan P.C. McQuen wrote: > If there are other situations meriting gst1-plugins-bad built against > libmodplug, wouldn't it be worth it to make it a hard dependency? Does > anyone really mind one extra package if it means better compatibility down > the road? > > > --- > > > > > On Jul 14, 2014, at 2:39 PM, King Beowulf > wrote: > > > >> On 07/14/2014 02:08 PM, Doogster wrote: > >> I'm about to submit a new version of gnome-inform7, and I've run into a > >> problem. It requires gst1-plugins-bad, and it needs gst1-plugins-bad to > >> have been built with libmodplug support. The problem is that > >> gst1-plugins-bad lists libmodplug as an optional dependency, not as a > >> hard one. How should I handle that, > >> > >> The best solution I can think of is to specify gst1-plugins-bad in the > >> info file as a hard requirement, then mention in the README that > >> gst1-plugins-bad needs to have been built against libmodplug. Is there a > >> better way? > > > > IMO, think that is the best way. Specify the dep in .info, then give > > "gotchas" in the README. This might trip up the sbopkg users, but short > > of including a "special" gst1-plugings-bad, it'll be hard to cover every > > use case. After all, we should all be reading the README, right? > > > > -Ed > > _______________________________________________ > > SlackBuilds-users mailing list > > SlackBuilds-users at slackbuilds.org > > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > FAQ - http://slackbuilds.org/faq/ > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryanpcmcquen at gmail.com Mon Jul 14 23:05:07 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Mon, 14 Jul 2014 16:05:07 -0700 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: References: <53C44DF8.8040504@gmail.com> <49DEAB36-08FC-4BA9-8629-258E9F643C24@gmail.com> Message-ID: If that is what everyone else thinks is reasonable that is fine with me. --- > On Jul 14, 2014, at 3:52 PM, Doogster wrote: > > I would prefer that the only hard dependencies specified for gst1-plugins-bad be the ones that gst1-plugins-bad need in order to be built. > > If you start specifying optional dependencies as hard ones because unrelated packages need them, then you end up with a mess like Debian where installing Mutt on your headless server installs X. > >> On Monday, July 14, 2014, Ryan P.C. McQuen wrote: >> If there are other situations meriting gst1-plugins-bad built against libmodplug, wouldn't it be worth it to make it a hard dependency? Does anyone really mind one extra package if it means better compatibility down the road? >> >> >> --- >> >> >> >> > On Jul 14, 2014, at 2:39 PM, King Beowulf wrote: >> > >> >> On 07/14/2014 02:08 PM, Doogster wrote: >> >> I'm about to submit a new version of gnome-inform7, and I've run into a >> >> problem. It requires gst1-plugins-bad, and it needs gst1-plugins-bad to >> >> have been built with libmodplug support. The problem is that >> >> gst1-plugins-bad lists libmodplug as an optional dependency, not as a >> >> hard one. How should I handle that, >> >> >> >> The best solution I can think of is to specify gst1-plugins-bad in the >> >> info file as a hard requirement, then mention in the README that >> >> gst1-plugins-bad needs to have been built against libmodplug. Is there a >> >> better way? >> > >> > IMO, think that is the best way. Specify the dep in .info, then give >> > "gotchas" in the README. This might trip up the sbopkg users, but short >> > of including a "special" gst1-plugings-bad, it'll be hard to cover every >> > use case. After all, we should all be reading the README, right? >> > >> > -Ed >> > _______________________________________________ >> > SlackBuilds-users mailing list >> > SlackBuilds-users at slackbuilds.org >> > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> > FAQ - http://slackbuilds.org/faq/ >> > >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yalhcru at gmail.com Mon Jul 14 23:08:22 2014 From: yalhcru at gmail.com (B Watson) Date: Mon, 14 Jul 2014 19:08:22 -0400 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: References: Message-ID: On 7/14/14, Doogster wrote: > The best solution I can think of is to specify gst1-plugins-bad in the info > file as a hard requirement, then mention in the README that > gst1-plugins-bad needs to have been built against libmodplug. Is there a > better way? That's something people are already doing (I remember something needing wxPython built with gnomeprint, or similar), so it should be fine. IMO, you should also list libmodplug as a dep in inform7's info file. List it first (or at least, before gst-plugins-bad). If people are installing the deps in the order listed in REQUIRES, it'll take care of itself (because gst-plugins-bad will auto-detect that libmodplug is installed, doesn't need manual intervention). Also if someone's using sbotools, it'll Just Work (at least, it will on a clean system). A separate issue, unless it's been fixed already, is that the gst-plugins-bad version on SBo (as of last week or so) wouldn't build if libmodplug was installed. I've been too busy with other stuff to pay attention, this may not be a problem any more. From baildon.research at googlemail.com Mon Jul 14 23:29:59 2014 From: baildon.research at googlemail.com (David Spencer) Date: Tue, 15 Jul 2014 00:29:59 +0100 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: References: Message-ID: > IMO, you should also list libmodplug as a dep in inform7's info file. List > it first (or at least, before gst-plugins-bad). If people are installing > the deps in the order listed in REQUIRES, it'll take care of itself > (because gst-plugins-bad will auto-detect that libmodplug is installed, > doesn't need manual intervention). Also if someone's using sbotools, > it'll Just Work (at least, it will on a clean system). But with slackrepo, as an explicit design decision, that will *not* work. One of the reasons I wrote slackrepo was the unpredictability with sbopkg etc. of whether wxPython did or did not get gnomeprint, depending on which package you'd most recently built wxPython for... or what if someone has already got gst1-plugins-bad without libmodplug, and has already built libmodplug (e.g. for xbmc) -- the deps are already met, and there's nothing to trigger a rebuild of gst1-plugins-bad with libmodplug. So, my opinion is, just do the README thing. fwiw. -D. From thedoogster at gmail.com Mon Jul 14 23:56:30 2014 From: thedoogster at gmail.com (Doogster) Date: Mon, 14 Jul 2014 16:56:30 -0700 Subject: [Slackbuilds-users] Needing requirements built with options In-Reply-To: References: Message-ID: I'm also leaning towards the README thing. If a tool works by building and then traversing a dependency tree data structure, then listing libmodplug first will not guarantee that it's built first. On Monday, July 14, 2014, David Spencer wrote: > > IMO, you should also list libmodplug as a dep in inform7's info file. > List > > it first (or at least, before gst-plugins-bad). If people are installing > > the deps in the order listed in REQUIRES, it'll take care of itself > > (because gst-plugins-bad will auto-detect that libmodplug is installed, > > doesn't need manual intervention). Also if someone's using sbotools, > > it'll Just Work (at least, it will on a clean system). > > But with slackrepo, as an explicit design decision, that will *not* > work. One of the reasons I wrote slackrepo was the unpredictability > with sbopkg etc. of whether wxPython did or did not get gnomeprint, > depending on which package you'd most recently built wxPython for... > or what if someone has already got gst1-plugins-bad without > libmodplug, and has already built libmodplug (e.g. for xbmc) -- the > deps are already met, and there's nothing to trigger a rebuild of > gst1-plugins-bad with libmodplug. So, my opinion is, just do the > README thing. fwiw. > > -D. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Wed Jul 16 01:35:40 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 16 Jul 2014 08:35:40 +0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C2CD78.1090706@gmail.com> References: <53C2CD78.1090706@gmail.com> Message-ID: <53C5D6EC.9030602@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2014 01:18 AM, King Beowulf wrote: > I just realized a fix for a glitch with the new nvidia-driver and > CUDA initialization. Since the slackbuild is already in "approved" > and its not fatal unless you run CUDA/OpenCL programs, I'll fix > this up on the next update. This issue popped up somewhere in the > 331.xx drivers. Since it's not yet merged to master, i can still accept minor changes to fix the above problem You can send a diff based on what's in my branch Thanks - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPF1uwACgkQiHuDdNczM4GLlQCeNnqr4bvI4dyy2yJY1Arb9El5 XcoAniL65pcdPAcCZnaOuoKhstndq49x =o5Nf -----END PGP SIGNATURE----- From kingbeowulf at gmail.com Wed Jul 16 07:16:39 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Wed, 16 Jul 2014 00:16:39 -0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C5D6EC.9030602@slackbuilds.org> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> Message-ID: <53C626D7.6040207@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2014 06:35 PM, Willy Sudiarto Raharjo wrote: > On 07/14/2014 01:18 AM, King Beowulf wrote: >> I just realized a fix for a glitch with the new nvidia-driver >> and CUDA initialization. Since the slackbuild is already in >> "approved" and its not fatal unless you run CUDA/OpenCL programs, >> I'll fix this up on the next update. This issue popped up >> somewhere in the 331.xx drivers. > > Since it's not yet merged to master, i can still accept minor > changes to fix the above problem > > You can send a diff based on what's in my branch > > Thanks > I couldn't clone your branch for some reason, but since it looks the same as mine (as far as I can tell from the git repo browser), see attached patch. If you can't use it, no worries. I'll take care of it next time. Thanks Ed -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPGJs8ACgkQXvwMaW61dLeLIwCfckWvFI5Vct/VlUoyV06HRhSD s+IAoIxfpz5VHsmYKyTWlHGSvNLtwO9+ =ygT/ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: nvidia-driver.patch Type: text/x-patch Size: 2518 bytes Desc: not available URL: From willysr at slackbuilds.org Wed Jul 16 07:24:36 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 16 Jul 2014 14:24:36 +0700 Subject: [Slackbuilds-users] (no subject) In-Reply-To: <> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> <> Message-ID: <53C628B4.3000002@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I couldn't clone your branch for some reason, but since it looks the > same as mine (as far as I can tell from the git repo browser), see > attached patch. If you can't use it, no worries. I'll take care of it > next time. clone SBo's GIT repo and then checkout my branch: git checkout willysr - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPGKLQACgkQiHuDdNczM4Gq/ACfRG/K5i3Uewoo6ePCUJueI/TV rmgAoKAYYnrqHjet9KwAPsK1xodbdePY =zvc/ -----END PGP SIGNATURE----- From leva at ecentrum.hu Wed Jul 16 09:52:46 2014 From: leva at ecentrum.hu (=?iso-8859-1?Q?L=C9VAI_D=E1niel?=) Date: Wed, 16 Jul 2014 11:52:46 +0200 Subject: [Slackbuilds-users] ssmtp update with new patch Message-ID: <20140716095246.GB5003@serenity.local> Hi! Would you guys mind terribly to test a new patch from Debian for ssmtp? You can read about it in changelog.Debian [1], and can get the updated slackbuild from my git repo [2]. If you're using it, please give it a spin. Thanks, Daniel [1] - http://metadata.ftp-master.debian.org/changelogs//main/s/ssmtp/ssmtp_2.64-8_changelog [2] - https://github.com/levaidaniel/sbo/tree/mystuff/network/ssmtp -- L?VAI D?niel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F From willysr at slackbuilds.org Wed Jul 16 11:29:00 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 16 Jul 2014 18:29:00 +0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C626D7.6040207@gmail.com> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> <53C626D7.6040207@gmail.com> Message-ID: <53C661FC.2070601@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I couldn't clone your branch for some reason, but since it looks > the same as mine (as far as I can tell from the git repo browser), > see attached patch. If you can't use it, no worries. I'll take care > of it next time. Done please check my branch and confirm that it's OK - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPGYfwACgkQiHuDdNczM4Gm8ACeOq+GK50RpBBef1Z3O3OJkVTp iQMAn3HZ5vAzLhAPWyWiOIcjqVi33bA6 =PIo7 -----END PGP SIGNATURE----- From kingbeowulf at gmail.com Wed Jul 16 16:53:43 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Wed, 16 Jul 2014 09:53:43 -0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C661FC.2070601@slackbuilds.org> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> <53C626D7.6040207@gmail.com> <53C661FC.2070601@slackbuilds.org> Message-ID: <53C6AE17.2060409@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/16/2014 04:29 AM, Willy Sudiarto Raharjo wrote: >> I couldn't clone your branch for some reason, but since it looks >> the same as mine (as far as I can tell from the git repo >> browser), see attached patch. If you can't use it, no worries. >> I'll take care of it next time. > > Done please check my branch and confirm that it's OK > > -- Willy Sudiarto Raharjo Looks good, thanks! - -Ed -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPGrhUACgkQXvwMaW61dLc8GgCfSV+HBM4Ii9PAdtgCT/NXNd9N i4wAoJ/QHGYd3ceLZs/ErYxGR8amUVdA =yWEb -----END PGP SIGNATURE----- From thedoogster at gmail.com Wed Jul 16 19:06:44 2014 From: thedoogster at gmail.com (Doogster) Date: Wed, 16 Jul 2014 12:06:44 -0700 Subject: [Slackbuilds-users] Mistake in gnome-inform7 README Message-ID: I noticed this right after my submission left the pending queue: there's a mistake in gnome-inform7's README. "the world's best known writers of SF." should read: "the world's best known writers of IF." At this point, it's probably easier to ask the administrative team to make this change than to make another submission. Could you please fix the README? -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Thu Jul 17 00:26:04 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 17 Jul 2014 07:26:04 +0700 Subject: [Slackbuilds-users] Mistake in gnome-inform7 README In-Reply-To: References: Message-ID: <53C7181C.5050706@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I noticed this right after my submission left the pending queue: there's a > mistake in gnome-inform7's README. > > "the world's best known writers of SF." > > should read: > > "the world's best known writers of IF." > > At this point, it's probably easier to ask the administrative team to make > this change than to make another submission. Could you please fix the > README? done - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPHGBwACgkQiHuDdNczM4FQtQCffLQ6Ltn9GrVic4F2MQ7Qed8v AFQAnAukVgM4o72Myl8iEn0zsonu45Br =CZI4 -----END PGP SIGNATURE----- From ryanpcmcquen at gmail.com Thu Jul 17 00:28:02 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Wed, 16 Jul 2014 17:28:02 -0700 Subject: [Slackbuilds-users] steam slackbuild Message-ID: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> Thank you Talos for making this, very happy to see a SlackBuild for this. :) I would however, like to request that 'flashplayer-plugin' be removed as a hard dependency and moved to the README, I am almost certain it is not required, but recommended. Thanks, ryan --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at slackbuilds.org Thu Jul 17 00:52:15 2014 From: erik at slackbuilds.org (Erik Hanson) Date: Wed, 16 Jul 2014 19:52:15 -0500 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> Message-ID: <20140716195215.7f30a67d@shaggy.doo> On Wed, 16 Jul 2014 17:28:02 -0700 "Ryan P.C. McQuen" wrote: > I would however, like to request that 'flashplayer-plugin' be removed as > a hard dependency and moved to the README, I am almost certain it is not > required, but recommended. Listing an optional dep as required is fine and is entirely up to the maintainer. They may decide that it's easier from a support stand-point, for example. -- Erik Hanson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From ryanpcmcquen at gmail.com Thu Jul 17 02:08:26 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Wed, 16 Jul 2014 19:08:26 -0700 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: <20140716195215.7f30a67d@shaggy.doo> References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> <20140716195215.7f30a67d@shaggy.doo> Message-ID: Yes, I agree, was just hoping they may remove it when requested. :) --- > On Jul 16, 2014, at 5:52 PM, Erik Hanson wrote: > > On Wed, 16 Jul 2014 17:28:02 -0700 > "Ryan P.C. McQuen" wrote: > >> I would however, like to request that 'flashplayer-plugin' be removed as >> a hard dependency and moved to the README, I am almost certain it is not >> required, but recommended. > > Listing an optional dep as required is fine and is entirely up to the > maintainer. They may decide that it's easier from a support stand-point, > for example. > > > -- > Erik Hanson > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From kingbeowulf at gmail.com Thu Jul 17 05:07:48 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Wed, 16 Jul 2014 22:07:48 -0700 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> Message-ID: <53C75A24.7040408@gmail.com> On 07/16/2014 05:28 PM, Ryan P.C. McQuen wrote: > > Thank you Talos for making this, very happy to see a SlackBuild > for this. :) > > I would however, like to request that 'flashplayer-plugin' be > removed as a hard dependency and moved to the README, I am almost > certain it is not required, but recommended. > > Thanks, ryan > > --- > You pretty much *need* flashplayer, otherwise a bunch of stuff such as videos wont work. Without it Steam Client is only "partially" functional. Also, no mention is made about which Slackware Steam can be run on. Currently, the client and all games are 32-bit only. There needs comment in the README since the current package makes it look like Steam can run an all Slackware arch: - 32-bit only - 64-bit with unsupported multilib Secondly, I'm still using Alien Bob's spiffy package where he the added the following to the top of the bootstrap /usr/bin/steam: # --- Start Slackware mod --- export LD_LIBRARY_PATH=/usr/lib/seamonkey # Audio output goes to first "hw" device of ALSA export SDL_AUDIODRIVER=alsa #export AUDIODEV=hw # On window close, minimize to the system tray area: export STEAM_FRAME_FORCE_CLOSE=1 # Add any custom variable exports here [ -f ${HOME}/.steam4slackware ] && . ${HOME}/.steam4slackware # --- End Slackware mod --- Given the Ubuntu/pulseauidio centric nature of Steam, will sound work? are the seamonkey libs still needed? I couldn't test that since me VM is not set up for sound. I also didn't test if any games run since since all that resides on a Slack64 multilib that is "unclean" for SBo testing. Finally, as an FYI, Talos may want to mention in the README that one can put custom Steam icons in ~/.icons for those cases where the default steam control panel icon doesn't fit with your WM theme. A bunch of this has been discussed on LQ and the Slackware group on Steam. -Ed From ryanpcmcquen at gmail.com Thu Jul 17 05:56:07 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Wed, 16 Jul 2014 22:56:07 -0700 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: <53C75A24.7040408@gmail.com> References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> <53C75A24.7040408@gmail.com> Message-ID: Thanks for the tips Ed. I personally don't watch the videos on Steam and just use it to download/play games which does not require flash, hence why I think it is best as listed as recommended in the README. Just my opinion of course. --- > On Jul 16, 2014, at 10:07 PM, King Beowulf wrote: > >> On 07/16/2014 05:28 PM, Ryan P.C. McQuen wrote: >> >> Thank you Talos for making this, very happy to see a SlackBuild >> for this. :) >> >> I would however, like to request that 'flashplayer-plugin' be >> removed as a hard dependency and moved to the README, I am almost >> certain it is not required, but recommended. >> >> Thanks, ryan >> >> --- > > You pretty much *need* flashplayer, otherwise a bunch of stuff such as > videos wont work. Without it Steam Client is only "partially" functional. > > Also, no mention is made about which Slackware Steam can be run on. > Currently, the client and all games are 32-bit only. There needs > comment in the README since the current package makes it look like > Steam can run an all Slackware arch: > > - 32-bit only > - 64-bit with unsupported multilib > > Secondly, I'm still using Alien Bob's spiffy package where he the > added the following to the top of the bootstrap /usr/bin/steam: > > # --- Start Slackware mod --- > export LD_LIBRARY_PATH=/usr/lib/seamonkey > # Audio output goes to first "hw" device of ALSA > export SDL_AUDIODRIVER=alsa > #export AUDIODEV=hw > # On window close, minimize to the system tray area: > export STEAM_FRAME_FORCE_CLOSE=1 > # Add any custom variable exports here > [ -f ${HOME}/.steam4slackware ] && . ${HOME}/.steam4slackware > # --- End Slackware mod --- > > Given the Ubuntu/pulseauidio centric nature of Steam, will sound work? > are the seamonkey libs still needed? I couldn't test that since me VM > is not set up for sound. I also didn't test if any games run since > since all that resides on a Slack64 multilib that is "unclean" for SBo > testing. > > Finally, as an FYI, Talos may want to mention in the README that one > can put custom Steam icons in ~/.icons for those cases where the > default steam control panel icon doesn't fit with your WM theme. > > A bunch of this has been discussed on LQ and the Slackware group on > Steam. > > -Ed > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From willysr at slackbuilds.org Thu Jul 17 10:54:26 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 17 Jul 2014 17:54:26 +0700 Subject: [Slackbuilds-users] Updates - 20140717.1 Message-ID: <53C7AB62.6070200@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thu Jul 17 10:03:48 UTC 2014 academic/GeoGebra: Updated for version 4.4.40.0. academic/R: Updated for version 3.1.1. desktop/cnslock: Removed (upstream is no longer available). desktop/i3pystatus: Added (replacement for i3status). desktop/kdeconnect: Updated for version 0.7.2. desktop/kover: Fix source URL. desktop/kpartsplugin: fix source URL. desktop/qlandkartegt: Updated for version 1.7.7. development/atom: Updated for version 0.115.0. development/camlp5: Updated for version 6.11 + new maintainer. development/cmocka: Added (Unit testing framework for C). development/eclipse-cpp: Updated for version 4.4. development/eclipse: Updated for version 4.4. development/gnome-inform7: Updated for version 6L02. development/idea: Prevent some binaries to get stripped. development/jdk: Updated for version 7u65. development/lazarus: Updated for version 1.2.4. development/mono2: Added (software platform). development/monodevelop-database: Updated for version 5.0.1. development/monodevelop-debugger-gdb: Updated for version 5.0.1. development/monodevelop: Updated for version 5.0.1. development/qt-creator3: Updated for version 3.1.2. development/s51dude: Added (In-System programming tool). games/enigma: New maintainer. games/gbrainy: Updated for version 2.2.3 + new maintainer. games/hedgewars: Updated for version 0.9.20.5. games/nSnake: Updated for version 2.0.7. games/speed-dreams: Updated for version 2.1.0_r5799. games/steam: Added (digital distribution). games/term2048: Updated for version 0.2.4. gis/gdal: Updated README. gis/geogit-py: Updated for version 0.10. graphics/CairoSVG: Updated for version 1.0.8. graphics/CreateCloudMap: Updated for version 0.5.0. graphics/Shellpic: Updated for version 1.6. graphics/phototonic: Updated for version 1.00. ham/aldo: Added (morse code tutor for Linux). ham/baudline: Added (spectrum analyzer program). ham/cwdaemon: Added (Morse Code keyer daemon). ham/demorse: Added (morse code decoder program for Linux). ham/dxcc: Added (DXCC command line lookup utility). ham/ebook2cw: Added (ebook converter). ham/ebook2cwgui: Added (GUI front end for ebook2cw). ham/fldigi: Updated for version 3.21.83. ham/gridloc: Added (Maidenhead grid locator). ham/klog: Added (Ham Radio Logging program for KDE). ham/linlogbook: Added (QT4 Ham Radio Logging program). ham/linpsk: Added (QT4-based PSK31 program). ham/nec2c: Added (Antenna modeling software). ham/psk31lx: Added (ncurses psk31 program for Linux). ham/soundmodem: Added (Sound card driver for packet radio). ham/tqsl: Added (ARRL LOTW Trusted QSL software). ham/twhamqth: Added (callsign lookup program for linux). ham/unixcw: Added (Morse Code libraries and utilities). ham/wxapt: Added (weather satellite transmission decoder). ham/xanalyser: Added (stereo audio analyser). ham/xdemorse: Added (GTK+ Morse Code signal decoder). ham/xfhell: Added (GTK+ Hellschreiber program for Linux). ham/xgridloc: Added (Maidenhead grid square locator program for X). ham/xnec2c: Added (nec2 visualization program for X). ham/xpsk31: Added (GTK+ PSK31 program). ham/xwxapt: Added (GTK+ weather satellite image decoder). libraries/botocore: Updated for version 0.56.0. libraries/hdf: Added (HDF4 software libraries and utilities). libraries/leptonica: Updated for version 1.71. libraries/libearth: Updated for version 0.3.0. libraries/libvdpau: Updated for version 0.8. libraries/lksctp-tools: Updated for version 1.0.16. misc/dvtm: Updated for version 0.12. multimedia/TeamSpeak3: Updated for version 3.0.15.1. multimedia/cfourcc: Update source URL. multimedia/flashplayer-plugin: Updated for version 11.2.202.394. multimedia/gimp-gap: Update source URL. multimedia/gpodder: Updated for version 3.7.0. multimedia/mplayer-codecs64: Fixed VERSION string multimedia/x265: Updated for version 1.2. network/Pafy: Updated for version 0.3.54. network/QuiteRSS: Updated for version 0.16.1. network/aldryn-client: Updated for version 0.8.11. network/awscli: Updated for version 1.3.22. network/copy: Fix desktop file. network/flexget: Updated for version 1.2.143. network/mps: Updated for version 0.20.16. network/openconnect: Updated for version 5.03. network/pidgin-otr: Fix source URL. network/speedtest-cli: Updated for version 0.3.0. network/tornado: Updated for version 4.0. network/youtube-dl-server: Updated for version 0.1. network/youtube-dl: Updated for version 2014.07.11.3. office/osmo: Updated for version r944. office/pyspread: Updated for version 0.3.0. office/unoconv: Added (document converter). perl/perl-IO-Socket-INET6: Update source URL. perl/perl-IO-Tty: Convert from cpan to metacpan. perl/perl-Term-ProgressBar: Update source URL. perl/perl-config-general: Updated for version 2.56. python/PySDL2: Updated for version 0.9.3. python/click: Added (Python command line utility). python/colored: Updated for version 1.0.6. python/gst1-python: Added (GStreamer1 python bindings). python/python-future: Added (Python 2/3 compatibility). python/python-twitter: Updated for version 2.0. python/tornado_systemd: Added (socket activation with tornado). system/butterfly: Updated for version 1.5.3. system/docker: Updated for version 1.1.1. system/em: Updated for version 0.4. system/graphterm: Updated for version 0.56.2. system/nvidia-driver: Updated for version 340.24. system/nvidia-kernel: Updated for version 340.24. system/phoronix-test-suite: Updated for version 5.2.1. system/qingy: Script cleanup + fix multilib issue. system/qtgzmanager: Updated for version 1.0.2. system/slpkg: Updated for version 1.5.4. system/trachet: Updated for version 1.0.9. - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPHq2IACgkQiHuDdNczM4GbDACfa2sHb1dsxnIOgR6TmJszrxlv DUkAnR+1OskLrJ3Jx73ddtyfwxzXH8q3 =Lx6Q -----END PGP SIGNATURE----- From erik at slackbuilds.org Thu Jul 17 12:08:38 2014 From: erik at slackbuilds.org (Erik Hanson) Date: Thu, 17 Jul 2014 07:08:38 -0500 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: <53C75A24.7040408@gmail.com> References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> <53C75A24.7040408@gmail.com> Message-ID: <20140717070838.3db929ef@shaggy.doo> On Wed, 16 Jul 2014 22:07:48 -0700 King Beowulf wrote: > Also, no mention is made about which Slackware Steam can be run on. > Currently, the client and all games are 32-bit only. Not to complicate things, but all games are not 32-bit only. Many are shipping both 32 and 64-bit binaries, and some (such as the excellent XCOM EU) are 64-bit only. -- Erik Hanson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From joshuakwood at gmail.com Thu Jul 17 17:40:55 2014 From: joshuakwood at gmail.com (JK Wood) Date: Thu, 17 Jul 2014 12:40:55 -0500 Subject: [Slackbuilds-users] SlackBuilds TQSL In-Reply-To: References: Message-ID: On Jul 17, 2014 9:26 AM, "Richard Morton" wrote: > > Hello > > > For your TQSL SlackBuild the tqsl.SlackBuild script should be version 2.0.1 not 2.0.2 > After starting TQSL there is pop-up to a URL to the new version 2.0.2 > So you would have to rebuild it again and update. > > > Thank you > Richard Morton Whoops! I fixed it in the SlackBuild and in the VERSION, but not the DOWNLOAD (or the MD5SUM, I assume.) Incrementing the version in the .info file (and fixing the md5 if needed) will fix this. I can submit an update in about 5 hours to fix the problem. Thanks for the report! Thanks, JK -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Thu Jul 17 18:00:11 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Fri, 18 Jul 2014 01:00:11 +0700 Subject: [Slackbuilds-users] SlackBuilds TQSL In-Reply-To: References: Message-ID: <53C80F2B.1080301@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Incrementing the version in the .info file (and fixing the md5 if needed) > will fix this. I can submit an update in about 5 hours to fix the problem. I have fixed this on my branch no need to submit an update - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPIDysACgkQiHuDdNczM4HsMACfUUV+9J4SnIkYYExJ6THhzvsX BLwAoIf85VGs2/VpIug49qellay6RVGH =Rtix -----END PGP SIGNATURE----- From joshuakwood at gmail.com Thu Jul 17 18:07:10 2014 From: joshuakwood at gmail.com (JK Wood) Date: Thu, 17 Jul 2014 13:07:10 -0500 Subject: [Slackbuilds-users] SlackBuilds TQSL In-Reply-To: <53C80F2B.1080301@slackbuilds.org> References: <53C80F2B.1080301@slackbuilds.org> Message-ID: On Jul 17, 2014 1:00 PM, "Willy Sudiarto Raharjo" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Incrementing the version in the .info file (and fixing the md5 if needed) > > will fix this. I can submit an update in about 5 hours to fix the problem. > > I have fixed this on my branch > no need to submit an update > > - -- > Willy Sudiarto Raharjo > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlPIDysACgkQiHuDdNczM4HsMACfUUV+9J4SnIkYYExJ6THhzvsX > BLwAoIf85VGs2/VpIug49qellay6RVGH > =Rtix > -----END PGP SIGNATURE----- > Thanks Willy! Thanks, JK -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Thu Jul 17 22:07:59 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 17 Jul 2014 15:07:59 -0700 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: <20140717070838.3db929ef@shaggy.doo> References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> <53C75A24.7040408@gmail.com> <20140717070838.3db929ef@shaggy.doo> Message-ID: <53C8493F.80006@gmail.com> On 07/17/2014 05:08 AM, Erik Hanson wrote: > On Wed, 16 Jul 2014 22:07:48 -0700 > King Beowulf wrote: > >> Also, no mention is made about which Slackware Steam can be run on. >> Currently, the client and all games are 32-bit only. > > Not to complicate things, but all games are not 32-bit only. Many are > shipping both 32 and 64-bit binaries, and some (such as the excellent > XCOM EU) are 64-bit only. > > Some games with 64-bit binaries have trouble with the Steam social stuff, overlay and badges, for example, so you lose some of the Steam Client integration. Hammerwatch is a typical example. This has been our experience here on 3 separate systems. Perhaps those on this list can share their 32 vs. 64 Steam experience on the Slackware Steam group forum. It would be interesting compile a list of what does and does not work properly - and which arch gets autodetected and subsequently run. -Ed From kingbeowulf at gmail.com Thu Jul 17 22:10:32 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 17 Jul 2014 15:10:32 -0700 Subject: [Slackbuilds-users] steam slackbuild In-Reply-To: References: <94CB48D3-C459-45F4-B902-6E371C534AF6@gmail.com> <53C75A24.7040408@gmail.com> Message-ID: <53C849D8.3040103@gmail.com> On 07/16/2014 10:56 PM, Ryan P.C. McQuen wrote: > Thanks for the tips Ed. I personally don't watch the videos on Steam and just use it to download/play games which does not require flash, hence why I think it is best as listed as recommended in the README. Just my opinion of course. > > > --- > > FYI, There are a few indy games that are flash based and run on Linux (at least when I d/l from Humble Bundle), although often the Steam keys are windows only (weird). -Ed From mats.bertil.tegner at gmail.com Fri Jul 18 06:06:27 2014 From: mats.bertil.tegner at gmail.com (Mats Bertil Tegner) Date: Fri, 18 Jul 2014 08:06:27 +0200 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C6AE17.2060409@gmail.com> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> <53C626D7.6040207@gmail.com> <53C661FC.2070601@slackbuilds.org> <53C6AE17.2060409@gmail.com> Message-ID: <53C8B963.8010500@gmail.com> On 2014-07-16 18:53, King Beowulf wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/16/2014 04:29 AM, Willy Sudiarto Raharjo wrote: >>> I couldn't clone your branch for some reason, but since it looks >>> the same as mine (as far as I can tell from the git repo >>> browser), see attached patch. If you can't use it, no worries. >>> I'll take care of it next time. >> >> Done please check my branch and confirm that it's OK >> >> -- Willy Sudiarto Raharjo > > Looks good, thanks! > > - -Ed I think there is a small typo in the SlackBuild: PRGNAM=nvidia-driver VERSION=${VERSION:-340.24} MVERS=331 BUILD=${BUILD:-1} TAG=${TAG:-_SBo} CPROXY=${CPROXY:-no} Shouldn't that be MVERS=340 ? Mats From weldon at langurwallah.org Fri Jul 18 09:08:13 2014 From: weldon at langurwallah.org (Weldon Goree) Date: Fri, 18 Jul 2014 14:38:13 +0530 Subject: [Slackbuilds-users] Is anybody doing musl? Message-ID: <53C8E3FD.2040609@langurwallah.org> Hi all, Is anybody working on slackbuilding the musl C library? I use it a lot and have what I think is a pretty good slackbuild made, so if that's not stepping on anybody's toes I'll submit it. Thanks, Weldon From jjalmeida at gmail.com Fri Jul 18 10:31:09 2014 From: jjalmeida at gmail.com (Jorge Almeida) Date: Fri, 18 Jul 2014 11:31:09 +0100 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53C8E3FD.2040609@langurwallah.org> References: <53C8E3FD.2040609@langurwallah.org> Message-ID: On Fri, Jul 18, 2014 at 10:08 AM, Weldon Goree wrote: > Hi all, > > Is anybody working on slackbuilding the musl C library? I use it a lot > and have what I think is a pretty good slackbuild made, so if that's not > stepping on anybody's toes I'll submit it. > A slackbuild for musl would be a Good Thing (I know I'm not answering your question, but a little encouragement doesn't hurt :)) Cheers Jorge Almeida From kingbeowulf at gmail.com Fri Jul 18 18:28:24 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Fri, 18 Jul 2014 11:28:24 -0700 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C8B963.8010500@gmail.com> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> <53C626D7.6040207@gmail.com> <53C661FC.2070601@slackbuilds.org> <53C6AE17.2060409@gmail.com> <53C8B963.8010500@gmail.com> Message-ID: <53C96748.7040807@gmail.com> On 07/17/2014 11:06 PM, Mats Bertil Tegner wrote: > On 2014-07-16 18:53, King Beowulf wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > > I think there is a small typo in the SlackBuild: > PRGNAM=nvidia-driver VERSION=${VERSION:-340.24} MVERS=331 > BUILD=${BUILD:-1} TAG=${TAG:-_SBo} CPROXY=${CPROXY:-no} > > Shouldn't that be MVERS=340 ? > > Mats > Well, f..udge... That's a dang silly error on my part. Yes you are correct. AND this may explain a weird CUDA issue I started having with BOINC. Admins, please advise on weather you want me to submit new, submit patch, or if you can just fix those 2 char on the fly. Thanks, -Ed From matteo.bernardini at gmail.com Fri Jul 18 18:59:46 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Fri, 18 Jul 2014 20:59:46 +0200 Subject: [Slackbuilds-users] nvidia-driver CUDA glitch In-Reply-To: <53C96748.7040807@gmail.com> References: <53C2CD78.1090706@gmail.com> <53C5D6EC.9030602@slackbuilds.org> <53C626D7.6040207@gmail.com> <53C661FC.2070601@slackbuilds.org> <53C6AE17.2060409@gmail.com> <53C8B963.8010500@gmail.com> <53C96748.7040807@gmail.com> Message-ID: 2014-07-18 20:28 GMT+02:00 King Beowulf : > Admins, please advise on weather you want me to submit new, submit > patch, or if you can just fix those 2 char on the fly. it's fixed (in my branch, will go in the next update). Matteo From jvogel4 at stny.rr.com Fri Jul 18 20:54:13 2014 From: jvogel4 at stny.rr.com (John Vogel) Date: Fri, 18 Jul 2014 16:54:13 -0400 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53C8E3FD.2040609@langurwallah.org> References: <53C8E3FD.2040609@langurwallah.org> Message-ID: <20140718165413.4b97712d@stygian.midgard.home> On Fri, 18 Jul 2014 14:38:13 +0530 Weldon Goree wrote: > Hi all, > > Is anybody working on slackbuilding the musl C library? I use it a lot > and have what I think is a pretty good slackbuild made, so if that's not > stepping on anybody's toes I'll submit it. > > Thanks, > Weldon Hi Weldon, I would be interested in seeing what you have. I'm using musl for a project right now, so I'd be interested in giving your slackbuild a try. Thanks, John From didier.spaier at epsm.fr Fri Jul 18 21:43:51 2014 From: didier.spaier at epsm.fr (Didier Spaier) Date: Fri, 18 Jul 2014 23:43:51 +0200 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <20140718165413.4b97712d@stygian.midgard.home> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> Message-ID: <53C99517.5060704@epsm.fr> On 18/07/2014 22:54, John Vogel wrote: > On Fri, 18 Jul 2014 14:38:13 +0530 > Weldon Goree wrote: > >> Hi all, >> >> Is anybody working on slackbuilding the musl C library? I use it a lot >> and have what I think is a pretty good slackbuild made, so if that's not >> stepping on anybody's toes I'll submit it. >> >> Thanks, >> Weldon > Hi Weldon, > > I would be interested in seeing what you have. I'm using musl for a project > right now, so I'd be interested in giving your slackbuild a try. I see here: http://www.etalabs.net/compare_libcs.html that that musl misses POSIX localedef, legacy codepages and iconv. Could we imagine a repackaging of bits of glibc{,solibs,i18n} so that we be feature complete on that respect? Just curious (and currently cherry picking part of that to include it in Slint installers, hence the question). Didier PS Of course that would be needed only if/when Pat ships musl in Slackware as a drop-in replacement of glibc, so maybe not tomorrow morning ;) From weldon at langurwallah.org Sat Jul 19 05:21:04 2014 From: weldon at langurwallah.org (Weldon Goree) Date: Sat, 19 Jul 2014 10:51:04 +0530 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <20140718165413.4b97712d@stygian.midgard.home> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> Message-ID: <53CA0040.6070400@langurwallah.org> On 07/19/2014 02:24 AM, John Vogel wrote: > > I would be interested in seeing what you have. I'm using musl for a project > right now, so I'd be interested in giving your slackbuild a try. > http://langurwallah.org/slackbuilds/musl.tar.gz TL;DR: This puts the libs in /usr/$LIBDIR/musl, the inlcudes in /usr/include/musl, musl-gcc in /usr/bin, and the loader ld-musl-$ARCH.so.1 in /$LIBDIR with a symlink to it as /usr/bin/musl-ldd. I could use some advice on /usr/lib vs. /lib for this. I don't have a 32-bit machine lying around to test this on; in particular I'm worried about $(ARCH) in musl's Makefile, which gets used in the name of the ld-musl-$ARCH-so.1 symlink (and which I need to know to make ldd; see below). If somebody could let me know what it does on i486/i686 I'd really appreciate that (I have reasoned what it "should" do, but that's always questionable). It's currently set for 1.0.3 (the latest version of the stable branch), but it works with 1.1.2 and 1.1.3 also. I'm talking with the upstream about the life expectancy of the stable branch and it may be cut off in the next couple of quarters, so it might be better to stick with the 1.1 branch. Also, I may have done something the Wrong Way: doinst.sh needs to know LIBDIRSUFFIX and ARCH in order to link usr/bin/musl-ldd to lib$LIBDIRSUFFIX/ld-musl-$ARCH.so.1. I've never needed to know those in a doinst.sh before, so I just copied the relevant lines from the SlackBuild file. Or maybe I just shouldn't make the musl-ldd link to begin with, since the upstream doesn't in the install. Anyways, the big problem with having two C libraries is where to put the two libc.so's and the system headers. I put them in /usr/lib$LIBDIRSUFFIX/musl and /usr/include/musl. The musl-gcc.specs file takes care of gcc finding those (assuming you use the /usr/bin/musl-gcc wrapper), and the ld-musl* symlink is in /lib$LIBDIRSUFFIX, so it doesn't take any loader magic to make it work. (On that note: it's probably Broken and Wrong to have the loader in /lib linked to the full library in /usr, in case early programs use this. Should I make the main libdir /lib/musl instead? Or should I put the loader in /usr/lib/musl? I don't like a slackbuild writing outside of /usr and /etc by default, personally, but loaders really "want" to be in /lib...) Musl users often build a native or cross toolchain for it, too (you'll need that if you want to use C++ at all, for example), but that takes enough patching of gcc that it's probably not appropriate for SBo. Binutils (> 2.23) works fine out of the box; a cross or native musl binutils might be worth doing a slackbuild for some day. So, please let me know if this works for you; once I hear back from musl on the life expectancy I'll pick which branch to default to and submit this, barring problems. In particular let me know if it craps out and asks for -fno-toplevel-reorder in CFLAGS (I think that's limited to cross toolchains, but just in case). Thanks, Weldon From weldon at langurwallah.org Sat Jul 19 05:42:40 2014 From: weldon at langurwallah.org (Weldon Goree) Date: Sat, 19 Jul 2014 11:12:40 +0530 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53C99517.5060704@epsm.fr> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53C99517.5060704@epsm.fr> Message-ID: <53CA0550.5080907@langurwallah.org> On 07/19/2014 03:13 AM, Didier Spaier wrote: > I see here: http://www.etalabs.net/compare_libcs.html > that that musl misses POSIX localedef, legacy codepages and iconv. > > Could we imagine a repackaging of bits of glibc{,solibs,i18n} so that > we be feature complete on that respect? > > Just curious (and currently cherry picking part of that to include it > in Slint installers, hence the question). > Musl's next minor release (later this month) is going to have a locale framework based on .mo files and a stub gettext. I think iconv needs enough of glibc (and it is glibc-specific) that you'll end up needing a full install for it anyways. Another interesting thing musl doesn't do at all is any of the zoneinfo stuff (turns out, to my surprise, that's not POSIX). Weldon From zacts.3.14159 at gmail.com Sat Jul 19 18:16:08 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sat, 19 Jul 2014 12:16:08 -0600 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. Message-ID: Hello, I'm currently working on a script to convert and test-build all of the perl/* slackbuilds to use metacpan as their homepage, and www.cpan.org as their download link. search.cpan.org is providing many dead links, and users of sbotools are finding many dead download links, thus forcing them to build manually. To do this successfully, I need to update many of the perl/ slackbuilds to their latest version, and I want to do this in such a way to where it won't break other modules, such as perl/perl-IO-Tty and networks/mosh. Anyway, I also hope to update the modules in an automated way by using http://www.cpan.org/modules/02packages.details.txt.gz. So my questions are: 1) If we decide to automate upgrading all of the perl/ slackbuilds to use the latest version, how should we make sure it doesn't break other slackbuilds that rely on that perl module? 2) If we decide to automate upgrading all of the perl/ slackbuilds, should we have just a single maintainer for _all_ of the perl/ slackbuilds, or should we continue with having a different maintainer for each perl slackbuild module? 3) #perl on freenode recommended that we use www.cpan.org for the download link, if we decide to do this rather than using metacpan for the download link, we will have to upgrade all perl/ slackbuilds to their latest version, or we will have dead links. So, would you like to use www.cpan.org for the download link, or would you rather use metacpan for the download link until we make a decision on for my question #2? Note: I personally volunteer to help maintain perl/ slackbuilds if any help is needed. Also, please let me know if you have any questions. Thanks, Zac --- Zachary Storer zacts on irc From erik at slackbuilds.org Sat Jul 19 18:52:38 2014 From: erik at slackbuilds.org (Erik Hanson) Date: Sat, 19 Jul 2014 13:52:38 -0500 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: References: Message-ID: <20140719135238.2acfa6b4@shaggy.doo> On Sat, 19 Jul 2014 12:16:08 -0600 Zachary Storer wrote: > 2) If we decide to automate upgrading all of the perl/ slackbuilds, > should we have just a single maintainer for _all_ of the perl/ > slackbuilds, or should we continue with having a different maintainer > for each perl slackbuild module? It's fine if you'd like to send us a patch to change the download links to whatever is working/recommended, but taking over or updating scripts on behalf of someone else requires their permission. -- Erik Hanson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From zacts.3.14159 at gmail.com Sat Jul 19 19:42:51 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sat, 19 Jul 2014 13:42:51 -0600 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: <20140719135238.2acfa6b4@shaggy.doo> References: <20140719135238.2acfa6b4@shaggy.doo> Message-ID: <20140719194251.GA21444@slacker0> On Sat, Jul 19, 2014 at 01:52:38PM -0500, Erik Hanson wrote: > > It's fine if you'd like to send us a patch to change the download links to > whatever is working/recommended, but taking over or updating scripts on > behalf of someone else requires their permission. > > > -- > Erik Hanson Ok, the problem is this: If we decide to use the freenode #perl's recommended www.cpan.org as the cpan link, then we will have to upgrade many of the perl/ slackbuilds, because, as far as I know, www.cpan.org doesn't provide some of the older versions for those slackbuilds. Therefore, our options would be to email every perl/ slackbuild maintainer asking them to upgrade their slackbuild, use metacpan.org as the download link for the slackbuilds, or I could submit a patch that upgrades all of the slackbuilds at once, while also switching from search.cpan.org as the download link to use www.cpan.org, without the permission of the individual slackbuild maintainers. To me, it initially seems that in the future if we were to automate the upgrading of perl/ slackbuilds it would be nice to not have to ask each and every maintainer for permission to do this. For example, for my recent patch to fix perl/perl-IO-Tty I didn't hear back from the maintainer at all. This could make mass updates slow. Although, perhaps you guys have a good reason for having one maintainer per perl slackbuild. Thanks! Zac --- Zachary Storer zacts on irc From pprkut at slackbuilds.org Sat Jul 19 20:19:52 2014 From: pprkut at slackbuilds.org (Heinz Wiesinger) Date: Sat, 19 Jul 2014 22:19:52 +0200 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: <20140719194251.GA21444@slacker0> References: <20140719135238.2acfa6b4@shaggy.doo> <20140719194251.GA21444@slacker0> Message-ID: <28132310.sUTE282Fn5@titania> On Saturday 19 July 2014 13:42:51 Zachary Storer wrote: > On Sat, Jul 19, 2014 at 01:52:38PM -0500, Erik Hanson wrote: > > It's fine if you'd like to send us a patch to change the download links to > > whatever is working/recommended, but taking over or updating scripts on > > behalf of someone else requires their permission. > > Ok, the problem is this: If we decide to use the freenode #perl's > recommended www.cpan.org as the cpan link, then we will have to upgrade > many of the perl/ slackbuilds, because, as far as I know, > www.cpan.org doesn't provide some of the older versions for those > slackbuilds. > > Therefore, our options would be to email every perl/ slackbuild > maintainer asking them to upgrade their slackbuild, use > metacpan.org as the download link for the slackbuilds, or I could > submit a patch that upgrades all of the slackbuilds at once, while also > switching from search.cpan.org as the download link to use www.cpan.org, > without the permission of the individual slackbuild maintainers. You're jumping to conclusions here. *Some* SlackBuilds might have outdated links. That does not lead to anyone emailing *all* perl SlackBuild maintainers. At most this affects the maintainers of SlackBuilds where the current versions are not hosted at www.cpan.org. > To me, it initially seems that in the future if we were to automate the > upgrading of perl/ slackbuilds it would be nice to not have to ask each > and every maintainer for permission to do this. Mass updates are an exception, not a rule. And we haven't yet established that what is required to do at this point qualifies as a mass update at all. Before talking about bending rules, first focus on creating an actual overview of the fixes that need to be performed. > For example, for my recent > patch to fix perl/perl-IO-Tty I didn't hear back from the maintainer at > all. This could make mass updates slow. Although, perhaps you guys have > a good reason for having one maintainer per perl slackbuild. First, there is no such thing as "one maintainer per perl slackbuild", it's "one maintainer per SlackBuild". And yes, it can be slow, but that's the nature of email conversation. Sometimes you can speed things up by talking to people on IRC. The philosophy here is that maintainers know their application best and are presumably most suited to judge the impact of a change. Remember, that the SlackBuilds within perl are not self-contained. There are outside dependencies that need to be considered as well. Grs, Heinz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: This is a digitally signed message part. URL: From matteo.bernardini at gmail.com Sat Jul 19 20:25:42 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Sat, 19 Jul 2014 22:25:42 +0200 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: References: Message-ID: 2014-07-19 20:16 GMT+02:00 Zachary Storer : > 1) If we decide to automate upgrading all of the perl/ slackbuilds to > use the latest version, how should we make sure it doesn't break other > slackbuilds that rely on that perl module? > > 2) If we decide to automate upgrading all of the perl/ slackbuilds, > should we have just a single maintainer for _all_ of the perl/ > slackbuilds, or should we continue with having a different maintainer > for each perl slackbuild module? these two don't seem very reasonable to me: we have no guarantee at all that 1) works painlessly and about 2) we cannot have a single mantainer for all the perl stuff (he could become crazy -also there will be problems on new perl submissions, etc., etc.). maintainig perl modules through automated updates will lead to major breakages, IMHO. > 3) #perl on freenode recommended that we use www.cpan.org for the > download link, if we decide to do this rather than using metacpan for > the download link, we will have to upgrade all perl/ slackbuilds to > their latest version, or we will have dead links. So, would you like > to use www.cpan.org for the download link, or would you rather use > metacpan for the download link until we make a decision on for my > question #2? I would say to use metacpan for homepages and download links, but before giving a personal opinion I would like to read some statements about the cpan situation from some perl source... Matteo From zacts.3.14159 at gmail.com Sat Jul 19 20:44:59 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sat, 19 Jul 2014 14:44:59 -0600 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: References: Message-ID: <20140719204459.GA23856@slacker0> On Sat, Jul 19, 2014 at 10:25:42PM +0200, Matteo Bernardini wrote: > I would say to use metacpan for homepages and download links, but > before giving a personal opinion I would like to read some statements > about the cpan situation from some perl source... So, can I begin patching the SlackBuilds to use metacpan for the download links? I guess if we decide to use www.cpan.org later on for the download links I could have those ready also, but I'll only email either patch set depending on what we decide. Thanks, Zac --- Zachary Storer zacts on irc From baildon.research at googlemail.com Sat Jul 19 23:57:52 2014 From: baildon.research at googlemail.com (David Spencer) Date: Sun, 20 Jul 2014 00:57:52 +0100 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: <28132310.sUTE282Fn5@titania> References: <20140719135238.2acfa6b4@shaggy.doo> <20140719194251.GA21444@slacker0> <28132310.sUTE282Fn5@titania> Message-ID: On 19 July 2014 21:19, Heinz Wiesinger wrote: > Mass updates are an exception, not a rule. And we haven't yet established that > what is required to do at this point qualifies as a mass update at all. Before > talking about bending rules, first focus on creating an actual overview of the > fixes that need to be performed. fwiw, I've noticed that availability of search.cpan.org has been *awful* recently (three months or so), particularly at weekends, but is miraculously good today. These are the cpan URLs that are 404 right now and would need upversioning. (or, to avoid upversioning, alternative downloads for some of them can be located in the big source repos for Gentoo or Fedora.) perl-Config-IniFiles perl-Data-Dumper perl-Date-Manip perl-Statistics-Descriptive perl-Text-CSV_XS perl-XML-LibXSLT These six SlackBuilds have five distinct maintainers. Anyway, if a mass URL update is being done, please don't forget these which are not under perl/ : games/Chatbot-Eliza libraries/Crypt-SSLeay libraries/exiftool/exiftool.info [ Shockingly, exiftool is one of mine -- should I have moved it to perl/ ? ] btw, the md5sum for perl-xml-twig is wrong :-) Thanks folks -D. From willysr at slackbuilds.org Sun Jul 20 00:20:44 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 20 Jul 2014 07:20:44 +0700 Subject: [Slackbuilds-users] A question about maintaining perl/* slackbuilds. In-Reply-To: References: <20140719135238.2acfa6b4@shaggy.doo> <20140719194251.GA21444@slacker0> <28132310.sUTE282Fn5@titania> Message-ID: <53CB0B5C.60705@slackbuilds.org> > These are the cpan URLs that are 404 right now and would need > upversioning. (or, to avoid upversioning, alternative downloads for > some of them can be located in the big source repos for Gentoo or > Fedora.) > > perl-Config-IniFiles > perl-Data-Dumper > perl-Statistics-Descriptive > perl-Text-CSV_XS > perl-XML-LibXSLT Fixed in my branch > perl-Date-Manip This is mine and i have update it on my user branch > btw, the md5sum for perl-xml-twig is wrong :-) Fixed in my branch Thanks -- Willy Sudiarto Raharjo From jvogel4 at stny.rr.com Sun Jul 20 00:53:40 2014 From: jvogel4 at stny.rr.com (John Vogel) Date: Sat, 19 Jul 2014 20:53:40 -0400 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53CA0040.6070400@langurwallah.org> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> Message-ID: <20140719205340.1f13f860@stygian.midgard.home> On Sat, 19 Jul 2014 10:51:04 +0530 Weldon Goree wrote: > On 07/19/2014 02:24 AM, John Vogel wrote: > > > > I would be interested in seeing what you have. I'm using musl for a project > > right now, so I'd be interested in giving your slackbuild a try. > > > > http://langurwallah.org/slackbuilds/musl.tar.gz > > TL;DR: This puts the libs in /usr/$LIBDIR/musl, the inlcudes in > /usr/include/musl, musl-gcc in /usr/bin, and the loader > ld-musl-$ARCH.so.1 in /$LIBDIR with a symlink to it as > /usr/bin/musl-ldd. I could use some advice on /usr/lib vs. /lib for this. A good point. I have avoided this issue in my current work by only using the static library. > > I don't have a 32-bit machine lying around to test this on; in > particular I'm worried about $(ARCH) in musl's Makefile, which gets used > in the name of the ld-musl-$ARCH-so.1 symlink (and which I need to know > to make ldd; see below). If somebody could let me know what it does on > i486/i686 I'd really appreciate that (I have reasoned what it "should" > do, but that's always questionable). You might like to take a look at musl's configure script. It uses i?86) case string value to convert all included to i386. > > It's currently set for 1.0.3 (the latest version of the stable branch), > but it works with 1.1.2 and 1.1.3 also. I'm talking with the upstream > about the life expectancy of the stable branch and it may be cut off in > the next couple of quarters, so it might be better to stick with the 1.1 > branch. I have been following the 1.1.x branch, so I'm a bit biased on this point. > > Also, I may have done something the Wrong Way: doinst.sh needs to know > LIBDIRSUFFIX and ARCH in order to link usr/bin/musl-ldd to > lib$LIBDIRSUFFIX/ld-musl-$ARCH.so.1. I've never needed to know those in > a doinst.sh before, so I just copied the relevant lines from the > SlackBuild file. Or maybe I just shouldn't make the musl-ldd link to > begin with, since the upstream doesn't in the install. I'm not sure about right and wrong here, but I think the danger of breaking the toolchain or even the system by getting the two c libraries intermixed is an important concern. This is why I prefer to use static linking for musl binaries on builds where the system is glibc based. I usually install to /opt/musl. > > Anyways, the big problem with having two C libraries is where to put the > two libc.so's and the system headers. I put them in > /usr/lib$LIBDIRSUFFIX/musl and /usr/include/musl. The musl-gcc.specs > file takes care of gcc finding those (assuming you use the > /usr/bin/musl-gcc wrapper), and the ld-musl* symlink is in > /lib$LIBDIRSUFFIX, so it doesn't take any loader magic to make it work. > > (On that note: it's probably Broken and Wrong to have the loader in /lib > linked to the full library in /usr, in case early programs use this. > Should I make the main libdir /lib/musl instead? Or should I put the > loader in /usr/lib/musl? I don't like a slackbuild writing outside of > /usr and /etc by default, personally, but loaders really "want" to be in > /lib...) I agree that having the loader symlink placed in /lib$LIBDIRSUFFIX and pointing into a possible mount point is not a good plan. I also think that running system shared binaries that are not based on the base system's main c library a too fine line to walk for my taste. I walk on enough thin ice often enough to know better than to jump up and down on the cracks. > > Musl users often build a native or cross toolchain for it, too (you'll > need that if you want to use C++ at all, for example), but that takes > enough patching of gcc that it's probably not appropriate for SBo. > Binutils (> 2.23) works fine out of the box; a cross or native musl > binutils might be worth doing a slackbuild for some day. > > So, please let me know if this works for you; once I hear back from musl > on the life expectancy I'll pick which branch to default to and submit > this, barring problems. In particular let me know if it craps out and > asks for -fno-toplevel-reorder in CFLAGS (I think that's limited to > cross toolchains, but just in case). Have you tried using musl-cross (https://bitbucket.org/GregorR/musl-cross)? That might be another approach and might be a safer installation. > > Thanks, > Weldon > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From weldon at langurwallah.org Sun Jul 20 03:11:03 2014 From: weldon at langurwallah.org (Weldon Goree) Date: Sun, 20 Jul 2014 08:41:03 +0530 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <20140719205340.1f13f860@stygian.midgard.home> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> <20140719205340.1f13f860@stygian.midgard.home> Message-ID: <53CB3347.9020608@langurwallah.org> Update: I switched to the 1.1: http://langurwallah.org/slackbuilds/musl.tar.bz2 On 07/20/2014 06:23 AM, John Vogel wrote: > I have been following the 1.1.x branch, so I'm a bit biased on this point. Yeah, and upstream confirmed security backports for 1.0 will go away within the year, so 1.1 it is. > I agree that having the loader symlink placed in /lib$LIBDIRSUFFIX and > pointing into a possible mount point is not a good plan. I also think that > running system shared binaries that are not based on the base system's > main c library a too fine line to walk for my taste. I walk on enough thin > ice often enough to know better than to jump up and down on the cracks. Well, frankly that's the larger argument against dynamic linking as a whole... at any rate, the updated slackbuild puts all the libraries in /usr/$LIBDIR/musl, except for the loader, which is in /usr/$LIBDIR. There's no collision problems with the loader, because it's called ld-musl-$ARCH. > Have you tried using musl-cross (https://bitbucket.org/GregorR/musl-cross)? > That might be another approach and might be a safer installation. Yeah, his patches were the starting point for my toolchain. Good stuff. Weldon From zacts.3.14159 at gmail.com Sun Jul 20 11:28:13 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sun, 20 Jul 2014 05:28:13 -0600 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. Message-ID: <20140720112813.GA9149@slacker0> Hi, I've fixed up and tested all of the search.cpan.org links to point to metacpan. I would rather not flood this mailing list with tons of patches, or a large email, unless you prefer it. (but I assume not :-) Anyway, I have posted my metacpan branch of slackbuilds.git on my github page at https://github.com/zacts/slackbuilds/tree/metacpan. Please merge them if you like what you see. If you have any questions or concerns please let me know. Thanks, Zac --- Zachary Storer zacts on irc From willysr at slackbuilds.org Sun Jul 20 11:46:21 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 20 Jul 2014 18:46:21 +0700 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: <20140720112813.GA9149@slacker0> References: <20140720112813.GA9149@slacker0> Message-ID: <53CBAC0D.7060900@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I've fixed up and tested all of the search.cpan.org links to point to > metacpan. I would rather not flood this mailing list with tons of > patches, or a large email, unless you prefer it. (but I assume not :-) > Anyway, I have posted my metacpan branch of slackbuilds.git on my github > page at https://github.com/zacts/slackbuilds/tree/metacpan. Please merge > them if you like what you see. If you have any questions or concerns > please let me know. pushed to perl-zacts branch for review if anyone has comment on this branch, please let us know otherwise, this will be part of the next public update - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPLrA0ACgkQiHuDdNczM4GDmQCgmMelB/3lG3ld0A+uNXYWR724 suQAni91N7WC0Y+Bi9G0fpGwmmr9aSCg =VswL -----END PGP SIGNATURE----- From jvogel4 at stny.rr.com Sun Jul 20 16:27:24 2014 From: jvogel4 at stny.rr.com (John Vogel) Date: Sun, 20 Jul 2014 12:27:24 -0400 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53CB3347.9020608@langurwallah.org> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> <20140719205340.1f13f860@stygian.midgard.home> <53CB3347.9020608@langurwallah.org> Message-ID: <20140720122724.67642e7b@stygian.midgard.home> On Sun, 20 Jul 2014 08:41:03 +0530 Weldon Goree wrote: > Update: I switched to the 1.1: > > http://langurwallah.org/slackbuilds/musl.tar.bz2 > > > On 07/20/2014 06:23 AM, John Vogel wrote: > > I have been following the 1.1.x branch, so I'm a bit biased on this point. > > Yeah, and upstream confirmed security backports for 1.0 will go away > within the year, so 1.1 it is. > > > I agree that having the loader symlink placed in /lib$LIBDIRSUFFIX and > > pointing into a possible mount point is not a good plan. I also think that > > running system shared binaries that are not based on the base system's > > main c library a too fine line to walk for my taste. I walk on enough thin > > ice often enough to know better than to jump up and down on the cracks. > > Well, frankly that's the larger argument against dynamic linking as a > whole... at any rate, the updated slackbuild puts all the libraries in > /usr/$LIBDIR/musl, except for the loader, which is in /usr/$LIBDIR. > There's no collision problems with the loader, because it's called > ld-musl-$ARCH. > > > Have you tried using musl-cross (https://bitbucket.org/GregorR/musl-cross)? > > That might be another approach and might be a safer installation. > > Yeah, his patches were the starting point for my toolchain. Good stuff. > > Weldon Ok, sounds like we are on the same page. I will give your updated slackbuild some testing this evening. John From zacts.3.14159 at gmail.com Sun Jul 20 17:34:23 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sun, 20 Jul 2014 11:34:23 -0600 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. Message-ID: On Sun, Jul 20, 2014 at 06:46:21PM +0700, Willy Sudiarto Raharjo wrote: > pushed to perl-zacts branch for review > if anyone has comment on this branch, please let us know > > otherwise, this will be part of the next public update Ok, I've been chatting with mst on #perl on freenode. He suggests that we might want to use www.cpan.org and backpan rather than metacpan.org for the download links. I will prepare a patch set for this within the next 20-30 min. Then we can discuss and decide on whether or not to use www.cpan.org / backpan or metacpan. I'm voting for the former; it is the simpler approach and is basically what CPAN.pm does, and it follows the slackware philosophy. Thanks, Zac --- Zachary Storer zacts on irc From zacts.3.14159 at gmail.com Sun Jul 20 19:16:32 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sun, 20 Jul 2014 13:16:32 -0600 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: References: Message-ID: Ok, I have pushed my latest changes to my branch named 'cpan' at https://github.com/zacts/slackbuilds/. Everything in my email about my last push still applies. I have tested each new download location for an md5sum mismatch, and I've tested each new homepage for 404 Not Found errors. My cpan branch uses www.cpan.org or backpan.perl.org rather than metacpan, for a more robust system. Anyway, let me know if you have any questions and/or concerns. Thanks, Zac --- Zachary Storer zacts on irc From molbolom at gmail.com Sun Jul 20 20:56:01 2014 From: molbolom at gmail.com (Charles Kauffman) Date: Sun, 20 Jul 2014 15:56:01 -0500 Subject: [Slackbuilds-users] Any desire for pari/gp outside of sage? Message-ID: Howdy! Howdy! Howdy! I have been using pari and keeping it maintained on my system for quite a while now, and a few weeks ago went ahead and started using a slackbuild rather than a simple script to install into my user directory. Well, I went a head and touched up the slackbuild information and figured I'd see if any person/s around here would care for me to upload it to slackbuilds. Also, I have a script for yacas as well, but I'm not sure I'd want to keep it around. The only aspect of it that I'm interested in is utilizing "user defined" operators in place of function names. a || b := (a+b)/a instead of f(a,b) = (a+b)/a. So before I decide to continue using this, does anyone know of a CAS that allows for user defined operators? If anyone would like to test them out... https://dl.dropboxusercontent.com/u/8119425/system/pari.tar.gz https://dl.dropboxusercontent.com/u/8119425/system/yacas.tar.gz -------------- next part -------------- An HTML attachment was scrubbed... URL: From baildon.research at googlemail.com Sun Jul 20 22:53:01 2014 From: baildon.research at googlemail.com (David Spencer) Date: Sun, 20 Jul 2014 23:53:01 +0100 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: References: Message-ID: Hi folks, Can we include these in the mass update please? games/Chatbot-Eliza libraries/Crypt-SSLeay libraries/exiftool Thanks! -D. From zacts.3.14159 at gmail.com Sun Jul 20 22:58:29 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sun, 20 Jul 2014 16:58:29 -0600 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: References: Message-ID: <20140720225829.GA6223@slacker0> On Sun, Jul 20, 2014 at 11:53:01PM +0100, David Spencer wrote: > Hi folks, > > Can we include these in the mass update please? > > games/Chatbot-Eliza > libraries/Crypt-SSLeay > libraries/exiftool > > Thanks! > -D. Sure, since the mass update is one commit per slackbuild all that we need to do is add separate commits for each of your listed modules. I'll patch them for you know and push them to my 'cpan' branch on github. Thanks, - Zac --- Zachary Storer zacts on irc From thomas at beingboiled.info Mon Jul 21 03:35:46 2014 From: thomas at beingboiled.info (Thomas Morper) Date: Mon, 21 Jul 2014 05:35:46 +0200 (CEST) Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: <53CBAC0D.7060900@slackbuilds.org> References: <20140720112813.GA9149@slacker0> <53CBAC0D.7060900@slackbuilds.org> Message-ID: On Sun, 20 Jul 2014, Willy Sudiarto Raharjo wrote: > if anyone has comment on this branch, please let us know > otherwise, this will be part of the next public update I don't get this. The other thread mentioned a total of six SlackBuilds having non-working download links. Yet this branch will touch and change around 650, completely ignoring the respective maintainers who might have a reason for preferring search.cpan.org to metacpan.org and sticking to the download links either of them provide. Besides... a broken link often is an indicator for a SlackBuild in neglect. It's better when these get reported on the mailing list than having a nicely working download link for a version that's missing important bug or security fixes. -- From willysr at slackbuilds.org Mon Jul 21 03:43:14 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Mon, 21 Jul 2014 10:43:14 +0700 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: References: <20140720112813.GA9149@slacker0> <53CBAC0D.7060900@slackbuilds.org> Message-ID: <53CC8C52.7070509@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I don't get this. The other thread mentioned a total of six SlackBuilds > having non-working download links. Yet this branch will touch and change > around 650, completely ignoring the respective maintainers who might have > a reason for preferring search.cpan.org to metacpan.org and sticking to > the download links either of them provide. > > Besides... a broken link often is an indicator for a SlackBuild in > neglect. It's better when these get reported on the mailing list than > having a nicely working download link for a version that's missing > important bug or security fixes. search.cpan.org seems a bit unreliable lately, so there were some users having problems installing packages from SBo either downloading manually or using automatic tools, so zacts voluntarily create a mass patch to update the source to metacpan which is more reliable for future usage if any of the maintainers have any objections about their packages being modified, please let me know, and i will remove it from that branch Thanks - - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPMjFIACgkQiHuDdNczM4EpRwCgpTpSRQADVNZUc3YqRayxqn6T nPoAoJCisR4MPGSow0z0h2iApzVvsY9Z =lqCQ -----END PGP SIGNATURE----- From zacts.3.14159 at gmail.com Mon Jul 21 15:21:01 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Mon, 21 Jul 2014 09:21:01 -0600 Subject: [Slackbuilds-users] A request to pull from my metacpan branch. In-Reply-To: References: <20140720112813.GA9149@slacker0> <53CBAC0D.7060900@slackbuilds.org> Message-ID: <20140721152101.GA31469@slacker0> On Mon, Jul 21, 2014 at 05:35:46AM +0200, Thomas Morper wrote: > I don't get this. The other thread mentioned a total of six SlackBuilds > having non-working download links. Yet this branch will touch and change > around 650, completely ignoring the respective maintainers who might have > a reason for preferring search.cpan.org to metacpan.org and sticking to > the download links either of them provide. > > Besides... a broken link often is an indicator for a SlackBuild in > neglect. It's better when these get reported on the mailing list than > having a nicely working download link for a version that's missing > important bug or security fixes. It seems to me that many people in the perl community have been finding search.cpan.org to be continuously unreliable. According to the following stackoverflow comment by brian d foy, it is basically run by one person, Grahm Barr, and the source code for search.cpan.org is not available. As stated in the article you may contact Grahm Barr directly if you have questions. The stackoverflow link is here: http://stackoverflow.com/questions/23736052/whats-happening-with-search-cpan-org-and-how-to-install-an-redirector Contrast this with metacpan.org which is run by a team of people, and is opensource / free software. This allows members of the perl community to get involved with quickly fixing bugs. If you like I can site more sources on why metacpan.org should be used instead of search.cpan.org for the HOMEPAGE, but I am about to go to class soon, and I wanted to get this email out this morning. =) For the download links, I'm using what mst on freenode #perl suggested which is what CPAN.pm does itself. I'm using www.cpan.org. I'm *not* using metacpan in my latest branch for download links. I would argue that www.cpan.org, and backpan.perl.org, are currently the most reliable sources for up-to-date perl module downloads. According to my chat with mst on freenode #perl, using www.cpan.org rather than search.cpan.org or metacpan.org for DOWNLOAD would follow more of the slackware philosophy of doing things right. I'm not only changing the 300 or so perl SlackBuilds only because of the above reasons, but I'm changing them mainly because SlackBuilds users including myself have experienced dead links due, not to a maintainer who is neglecting the SlackBuild, but due to search.cpan.org giving dead links. The problem is with search.cpan.org, although I do agree that many perl SlackBuilds have been neglected, that is a separate issue. Anyway, thanks! If you guys have more questions or concerns please let me know. I would like to see the best for the perl SlackBuilds. Thanks, - Zac --- Zachary Storer zacts on irc From willysr at slackbuilds.org Tue Jul 22 11:08:50 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 22 Jul 2014 18:08:50 +0700 Subject: [Slackbuilds-users] Updates - 20140722.1 Message-ID: <53CE4642.7080602@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tue Jul 22 09:25:36 UTC 2014 academic/EMBASSY: Use self-hosted. academic/EMBOSS: Use self-hosted. academic/bwa: Updated for version 0.7.10. academic/fet: Updated for version 5.23.0. academic/geneconv: Use cp instead of cp -a. academic/genometools: Updated for version 1.5.3. academic/ij-plugins-LOCI: Updated for version 5.0.2. academic/io_lib: Updated for version 1.13.7, moved to academic. academic/jalview: Updated for version 2.8.1. academic/mafft: Updated for version 7.158. academic/seaview: Updated for version 4.5.2. academic/tophat: Updated for version 2.0.12. academic/zotero: Updated for version 4.0.21.2. audio/sunvox: Updated for version 1.7.5. desktop/homerun: Updated for version 1.2.5. development/diffuse: Updated for version 0.4.8. development/lighttable: Updated for version 0.6.7. games/Chatbot-Eliza: Fix source URLs. games/openmw: Updated for version 0.31.0. games/steam: Update deps and README. graphics/HotShots: Updated for version 2.1.1. graphics/converseen: Updated for version 0.7.3. graphics/phatch: Added (GUI photo batch processor). graphics/phototonic: Updated for version 1.01. ham/baudline: Fix desktop file to use aoss wrapper. ham/ebook2cwgui: Added desktop file and icon. ham/grig: Added (Ham Radio rig control interface). ham/linlogbook: Added desktop file and icon. ham/linpsk: Added desktop file and icon. ham/qradiopredict: Added (VHF-UHF Propagation calculator). ham/tqsl: Fix source version. ham/xfhell: Added desktop file and icon. ham/xgridloc: Added desktop file and icon. ham/xnec2c: Added desktop file and icon. ham/xpsk31: Added desktop file and icon. ham/xwxapt: Added desktop file and icon. libraries/Crypt-SSLeay: Fix source URLs. libraries/botocore: Updated for version 0.57.0. libraries/exiftool: Fix source URLs. misc/mosquitto: Updated for version 1.3.2. multimedia/Mopidy: Updated for version 0.19.0. network/Pafy: Updated for version 0.3.56. network/aria2: Updated for version 1.18.6. network/awscli: Updated for version 1.3.23. network/flexget: Updated for version 1.2.146. network/teamviewer: Updated for version 9.0.30203. office/pyspread: Updated for version 0.3.1. office/vlna: Added (Add nobreak). perl/Net-SSLeay: Fix source URLs. perl/libwww-perl: Fix source URLs. perl/perl-Algorithm-Diff: Fix source URLs. perl/perl-Alien-SDL: Fix source URLs. perl/perl-AppConfig: Fix source URLs. perl/perl-Archive-Zip: Fix source URLs. perl/perl-Astro-SunTime: Fix source URLs. perl/perl-Audio-FLAC-Header: Fix source URLs. perl/perl-Authen-SASL: Fix source URLs. perl/perl-BerkeleyDB: Fix source URLs. perl/perl-Bit-Vector: Fix source URLs. perl/perl-CSS-Squish: Fix source URLs. perl/perl-Cache-FastMmap: Fix source URLs. perl/perl-Capture-Tiny: Use metacpan.org. perl/perl-Carp-Clan: Fix source URLs. perl/perl-Class-Data-Inheritable: Fix source URLs. perl/perl-Class-Factory-Util: Fix source URLs. perl/perl-Class-Gomor: Fix source URLs. perl/perl-Class-Inspector: Fix source URLs. perl/perl-Class-Load: Fix source URLs. perl/perl-Class-Method-Modifiers: Use metacpan.org. perl/perl-Class-MethodMaker: Fix source URLs. perl/perl-Class-Singleton: Fix source URLs. perl/perl-Compress-Bzip2: Fix source URLs. perl/perl-Config-Find: Fix source URLs. perl/perl-Config-IniFiles: Fix source URL. perl/perl-Convert-ASN1: Fix source URLs. perl/perl-Convert-BinHex: Fix source URLs. perl/perl-Convert-TNEF: Fix source URLs. perl/perl-Convert-UU: Fix source URLs. perl/perl-Convert-UUlib: Fix source URLs. perl/perl-Crypt-Blowfish: Fix source URLs. perl/perl-Crypt-Blowfish_PP: Fix source URLs. perl/perl-Crypt-CAST5: Fix source URLs. perl/perl-Crypt-CBC: Fix source URLs. perl/perl-Crypt-DES: Fix source URLs. perl/perl-Crypt-IDEA: Fix source URLs. perl/perl-Crypt-OpenSSL-Bignum: Fix source URLs. perl/perl-Crypt-OpenSSL-RSA: Fix source URLs. perl/perl-Crypt-OpenSSL-Random: Fix source URLs. perl/perl-Crypt-Rijndael: Fix source URLs. perl/perl-Curses-UI: Fix source URLs. perl/perl-Curses: Fix source URLs. perl/perl-DBD-Pg: Fix source URLs. perl/perl-DBD-SQLite: Fix source URLs. perl/perl-Danga-Socket: Fix source URLs. perl/perl-Data-Dumper: Fix source URL. perl/perl-Data-OptList: Fix source URLs. perl/perl-Data-UUID: Fix source URLs. perl/perl-Date-Calc: Fix source URLs. perl/perl-Date-Manip: Updated for version 6.46. perl/perl-DateTime-Format-Builder: Fix source URLs. perl/perl-DateTime-Format-ISO8601: Fix source URLs. perl/perl-DateTime-Format-Strptime: Fix source URLs. perl/perl-DateTime-Locale: Fix source URLs. perl/perl-DateTime-TimeZone: Fix source URLs. perl/perl-DateTime: Fix source URLs. perl/perl-Devel-GlobalDestruction: Use metacpan.org. perl/perl-Devel-StackTrace: Fix source URLs. perl/perl-Devel-Symdump: Updated for version 2.12. perl/perl-Device-SerialPort: Fix source URLs. perl/perl-Digest-MD4: Fix source URLs. perl/perl-Dist-CheckConflicts: Fix source URLs. perl/perl-Email-Date-Format: Fix source URLs. perl/perl-Encode-Detect: Fix source URLs. perl/perl-Encode-EUCJPASCII: Fix source URLs. perl/perl-Encode-HanExtra: Fix source URLs. perl/perl-Encode-ISO2022: Fix source URLs. perl/perl-Encode-JISX0213: Fix source URLs. perl/perl-Exception-Class: Fix source URLs. perl/perl-ExtUtils-Config: Updated for version 0.008. perl/perl-ExtUtils-Helpers: Use metacpan.org. perl/perl-ExtUtils-InstallPaths: Use metacpan.org. perl/perl-ExtUtils-XSBuilder: Fix source URLs. perl/perl-FCGI: Fix source URLs. perl/perl-File-Find-Rule: Fix source URLs. perl/perl-File-HomeDir: Fix source URLs. perl/perl-File-ShareDir: Fix source URLs. perl/perl-File-Slurp: Fix source URLs. perl/perl-File-Tail: Use metacpan.org. perl/perl-File-Which: Fix source URLs. perl/perl-Font-AFM: Fix source URLs. perl/perl-Geo-IP: Fix source URLs. perl/perl-Geography-Countries: Fix source URLs. perl/perl-Gtk2-Unique: Fix source URLs. perl/perl-HTML-TableExtract: Fix source URLs. perl/perl-HTML-Tree: Fix source URLs. perl/perl-HTTP-Cache-Transparent: Fix source URLs. perl/perl-HTTP-Proxy: Fix source URLs. perl/perl-IO-HTML: Fix source URLs. perl/perl-IO-Interface: Fix source URLs. perl/perl-IO-Multiplex: Fix source URLs. perl/perl-IO-Socket-Multicast: Fix source URLs. perl/perl-IO-Socket-SSL: Fix source URLs. perl/perl-IO-stringy: Fix source URLs. perl/perl-IP-Country: Fix source URLs. perl/perl-IPC-DirQueue: Fix source URLs. perl/perl-IPC-Run3: Fix source URLs. perl/perl-IPC-Run: Fix source URLs. perl/perl-IPC-System-Simple: Fix source URLs. perl/perl-Image-Info: Fix source URLs. perl/perl-Image-Size: Fix source URLs. perl/perl-Import-Into: Updated for version 1.002004. perl/perl-Inline: Fix source URLs. perl/perl-JSON: Fix source URLs. perl/perl-LWP-Protocol-https: Fix source URLs. perl/perl-Lingua-EN-Numbers-Ordinate: Fix source URLs. perl/perl-List-MoreUtils: Fix source URLs. perl/perl-LockFile-Simple: Use metacpan.org. perl/perl-Log-Log4perl: Fix source URLs. perl/perl-MIME-Charset: Fix source URLs. perl/perl-MIME-Lite: Fix source URLs. perl/perl-MIME-tools: Fix source URLs. perl/perl-MP3-Info: Fix source URLs. perl/perl-Mail-DKIM: Fix source URLs. perl/perl-Mail-DomainKeys: Fix source URLs. perl/perl-Mail-SPF-Query: Fix source URLs. perl/perl-Mail-SPF: Fix source URLs. perl/perl-MailTools: Fix source URLs. perl/perl-Math-Base85: Fix source URLs. perl/perl-Math-Round: Fix source URLs. perl/perl-Module-Build-Tiny: Use metacpan.org. perl/perl-Module-Implementation: Fix source URLs. perl/perl-Module-Manifest: Fix source URLs. perl/perl-Module-Runtime: Fix source URLs. perl/perl-Module-Versions-Report: Fix source URLs. perl/perl-Moo: Use metacpan.org. perl/perl-Mozilla-CA: Fix source URLs. perl/perl-MusicBrainz-DiscID: Fix source URLs. perl/perl-Net-CIDR-Lite: Fix source URLs. perl/perl-Net-CIDR: Fix source URLs. perl/perl-Net-DNS-Resolver-Programmable: Fix source URLs. perl/perl-Net-Daemon: Fix source URLs. perl/perl-Net-IPv4Addr: Fix source URLs. perl/perl-Net-IPv6Addr: Fix source URLs. perl/perl-Net-Ident: Fix source URLs. perl/perl-Net-Jabber: Fix source URLs. perl/perl-Net-LDAP: Fix source URLs. perl/perl-Net-LibIDN: Fix source URLs. perl/perl-Net-Libdnet: Fix source URLs. perl/perl-Net-Netmask: Fix source URLs. perl/perl-Net-Packet: Fix source URLs. perl/perl-Net-Patricia: Fix source URLs. perl/perl-Net-Pcap: Fix source URLs. perl/perl-Net-RawIP: Fix source URLs. perl/perl-Net-SMTP-SSL: Fix source URLs. perl/perl-Net-Server: Fix source URLs. perl/perl-Net-Telnet: Fix source URLs. perl/perl-Net-UPnP: Fix source URLs. perl/perl-Net-Write: Fix source URLs. perl/perl-Net-XMPP: Fix source URLs. perl/perl-NetAddr-IP: Fix source URLs. perl/perl-NetPacket: Fix source URLs. perl/perl-Number-Compare: Fix source URLs. perl/perl-Ogg-Vorbis-Header-PurePerl: Fix source URLs. perl/perl-PHP-Serialization: Fix source URLs. perl/perl-Package-DeprecationManager: Fix source URLs. perl/perl-Package-Stash-XS: Fix source URLs. perl/perl-Package-Stash: Fix source URLs. perl/perl-Params-Classify: Fix source URLs. perl/perl-Params-Util: Fix source URLs. perl/perl-Params-Validate: Fix source URLs. perl/perl-Parse-RecDescent: Fix source URLs. perl/perl-PerlIO-Layers: Fix source URLs. perl/perl-Pod-Coverage: Use metacpan.org. perl/perl-Probe-Perl: Fix source URLs. perl/perl-Proc-Daemon: Fix source URLs. perl/perl-Proc-ProcessTable: Fix source URLs. perl/perl-Readonly: Fix source URLs. perl/perl-Regexp-Common: Fix source URLs. perl/perl-Regexp-IPv6: Fix source URLs. perl/perl-Role-Tiny: Use metacpan.org. perl/perl-SDL: Fix source URLs. perl/perl-SOAP-Lite: Fix source URLs. perl/perl-Scalar-List-Utils: Fix source URLs. perl/perl-Socket6: Fix source URLs. perl/perl-Sort-Naturally: Fix source URLs. perl/perl-Sort-Versions: Fix source URLs. perl/perl-Statistics-Descriptive: Fix source URL. perl/perl-String-ShellQuote: Fix source URLs. perl/perl-Sub-Exporter-Progressive: Fix source URLs. perl/perl-Sub-Exporter: Fix source URLs. perl/perl-Sub-Install: Fix source URLs. perl/perl-Sub-Uplevel: Fix source URLs. perl/perl-Sys-Hostname-Long: Fix source URLs. perl/perl-Sys-Mmap: Fix source URLs. perl/perl-Sys-Syscall: Fix source URLs. perl/perl-Task-Weaken: Fix source URLs. perl/perl-Template-Toolkit: Fix source URLs. perl/perl-Term-Animation: Fix source URLs. perl/perl-TermReadKey: Fix source URLs. perl/perl-Test-Deep: Fix source URLs. perl/perl-Test-Differences: Fix source URLs. perl/perl-Test-DistManifest: Fix source URLs. perl/perl-Test-Exception: Fix source URLs. perl/perl-Test-Harness: Use metacpan.org. perl/perl-Test-Inter: Use metacpan.org. perl/perl-Test-LongString: Fix source URLs. perl/perl-Test-Most: Fix source URLs. perl/perl-Test-NoWarnings: Fix source URLs. perl/perl-Test-Number-Delta: Fix source URLs. perl/perl-Test-Pod-Coverage: Updated for version 1.10. perl/perl-Test-Pod: Fix source URLs. perl/perl-Test-Requires: Fix source URLs. perl/perl-Test-Script: Fix source URLs. perl/perl-Test-SharedFork: Fix source URLs. perl/perl-Test-TCP: Fix source URLs. perl/perl-Test-Tester: Fix source URLs. perl/perl-Test-Trap: Fix source URLs. perl/perl-Text-Autoformat: Fix source URLs. perl/perl-Text-CSV: Fix source URLs. perl/perl-Text-CSV_XS: Fix source URL. perl/perl-Text-CharWidth: Fix source URLs. perl/perl-Text-Diff: Fix source URLs. perl/perl-Text-Glob: Fix source URLs. perl/perl-Text-Iconv: Fix source URLs. perl/perl-Text-Password-Pronounceable: Fix source URLs. perl/perl-Text-Patch: Fix source URLs. perl/perl-Text-Quoted: Fix source URLs. perl/perl-Text-Reform: Fix source URLs. perl/perl-Text-Tabulate: Fix source URLs. perl/perl-Text-WrapI18N: Fix source URLs. perl/perl-Tidy: Fix source URLs. perl/perl-Tie-IxHash: Fix source URLs. perl/perl-Tie-Simple: Fix source URLs. perl/perl-Time-Out: Fix source URLs. perl/perl-Time-Piece: Fix source URLs. perl/perl-Time-modules: Fix source URLs. perl/perl-TimeDate: Fix source URLs. perl/perl-Tk-TableMatrix: Fix source URLs. perl/perl-Unicode-LineBreak: Fix source URLs. perl/perl-Unicode-String: Fix source URLs. perl/perl-Unicode-UTF8simple: Fix source URLs. perl/perl-Unix-Syslog: Fix source URLs. perl/perl-X10: Fix source URLs. perl/perl-XML-Filter-BufferText: Fix source URLs. perl/perl-XML-LibXSLT: Fix source URL. perl/perl-XML-SAX-Writer: Fix source URLs. perl/perl-XML-Stream: Fix source URLs. perl/perl-XML-Writer: Fix source URLs. perl/perl-XML-XPath: Fix source URLs. perl/perl-YAML-Syck: Use metacpan.org. perl/perl-ZMQ-Constants: Fix source URLs. perl/perl-cairo: Fix source URLs. perl/perl-class-accessor: Fix source URLs. perl/perl-common-sense: Fix source URLs. perl/perl-config-general: Fix source URLs. perl/perl-data-dump: Fix source URLs. perl/perl-digest-hmac: Fix source URLs. perl/perl-digest-sha1: Fix source URLs. perl/perl-encode-locale: Fix source URLs. perl/perl-event: Fix source URLs. perl/perl-extutils-depends: Fix source URLs. perl/perl-extutils-pkgconfig: Fix source URLs. perl/perl-file-listing: Fix source URLs. perl/perl-file-path-expand: Fix source URLs. perl/perl-glib: Fix source URLs. perl/perl-gnome2-canvas: Fix source URLs. perl/perl-gnome2-gconf: Fix source URLs. perl/perl-gnome2-vfs: Fix source URLs. perl/perl-gnome2-wnck: Fix source URLs. perl/perl-gnome2: Fix source URLs. perl/perl-goo-canvas: Fix source URLs. perl/perl-gstreamer: Fix source URLs. perl/perl-gtk2-imageview: Fix source URLs. perl/perl-html-form: Fix source URLs. perl/perl-html-parser: Fix source URLs. perl/perl-html-tagset: Fix source URLs. perl/perl-http-cookies: Fix source URLs. perl/perl-http-daemon: Fix source URLs. perl/perl-http-date: Fix source URLs. perl/perl-http-message: Fix source URLs. perl/perl-http-negotiate: Fix source URLs. perl/perl-http-response-encoding: Fix source URLs. perl/perl-http-server-simple: Fix source URLs. perl/perl-libintl: Fix source URLs. perl/perl-lirc-client: Fix source URLs. perl/perl-lwp-mediatypes: Fix source URLs. perl/perl-net-dbus: Fix source URLs. perl/perl-net-dns: Fix source URLs. perl/perl-net-http: Fix source URLs. perl/perl-net-ip: Fix source URLs. perl/perl-pango: Fix source URLs. perl/perl-proc-processtable: Fix source URLs. perl/perl-strictures: Use metacpan.org. perl/perl-tk: Fix source URLs. perl/perl-tree-dagnode: Fix source URLs. perl/perl-www-mechanize: Fix source URLs. perl/perl-www-robotrules: Fix source URLs. perl/perl-x11-protocol: Fix source URLs. perl/perl-xml-libxml: Fix source URLs. perl/perl-xml-twig: Fix checksum. perl/perl-yaml: Fix source URLs. python/py: Updated for version 1.4.22. python/pysed: Updated for version 0.3.0. python/python-urllib3: Updated for version 1.9. system/butterfly: Updated for version 1.5.5. system/clamtk: Updated for version 5.07. system/graphterm: Updated for version 0.57.0. system/gtk-vnc: Update homepage. system/intel-microcode: Added (Linux Processor Microcode Data File). system/linkchecker: Updated for version 9.3. system/microcode_ctl: Updated for version 1.26. system/musl: Added (musl C library). system/nvidia-driver: Fixed typo. system/slpkg: Updated for version 1.5.6. system/udiskie: Updated for version 1.0.4. - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPORkIACgkQiHuDdNczM4EsqwCgql+bGNa5ifuQH8M1TKpA+4f+ dA0Ani+AhSxyvpFuCl7IfPNXhDkO9u4Z =smLP -----END PGP SIGNATURE----- From jvogel4 at stny.rr.com Thu Jul 24 03:28:35 2014 From: jvogel4 at stny.rr.com (John Vogel) Date: Wed, 23 Jul 2014 23:28:35 -0400 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53CB3347.9020608@langurwallah.org> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> <20140719205340.1f13f860@stygian.midgard.home> <53CB3347.9020608@langurwallah.org> Message-ID: <20140723232835.3869b0b0@stygian.midgard.home> I apologize for not getting back about this sooner. I built the slackbuild in a slackware qemu vm. Builds/installs fine. I was able to do a static build of bash-4.3, which runs fine (I need to use the make check or make test to verify, but that vm needs dejagnu, expect, tcl/tk, check, maybe more for full testing. I can get to that maybe this weekend. Also built dynamic bash which runs fine; musl-ldd reports proper loader and libc locations. From weldon at langurwallah.org Thu Jul 24 03:33:47 2014 From: weldon at langurwallah.org (Weldon Goree) Date: Thu, 24 Jul 2014 09:03:47 +0530 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <20140723232835.3869b0b0@stygian.midgard.home> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> <20140719205340.1f13f860@stygian.midgard.home> <53CB3347.9020608@langurwallah.org> <20140723232835.3869b0b0@stygian.midgard.home> Message-ID: <53D07E9B.4010107@langurwallah.org> On 07/24/2014 08:58 AM, John Vogel wrote: > I apologize for not getting back about this sooner. I built the slackbuild in > a slackware qemu vm. Builds/installs fine. I was able to do a static build > of bash-4.3, which runs fine (I need to use the make check or make test to > verify, but that vm needs dejagnu, expect, tcl/tk, check, maybe more for full > testing. I can get to that maybe this weekend. Also built dynamic bash which > runs fine; musl-ldd reports proper loader and libc locations. Did you get extra newlines in the output of musl-ldd? A few people have had that and I'm trying to track the problem down. WMG From jvogel4 at stny.rr.com Thu Jul 24 03:36:32 2014 From: jvogel4 at stny.rr.com (John Vogel) Date: Wed, 23 Jul 2014 23:36:32 -0400 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <53D07E9B.4010107@langurwallah.org> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> <20140719205340.1f13f860@stygian.midgard.home> <53CB3347.9020608@langurwallah.org> <20140723232835.3869b0b0@stygian.midgard.home> <53D07E9B.4010107@langurwallah.org> Message-ID: <20140723233632.3029482c@stygian.midgard.home> On Thu, 24 Jul 2014 09:03:47 +0530 Weldon Goree wrote: > Did you get extra newlines in the output of musl-ldd? A few people have > had that and I'm trying to track the problem down. No. I still had the vm running, so I just double checked and no blank lines between musl-ldd output and next shell prompt. But then this is a very, very minimal install. When I mess with more thorough testing this weekend, I can try adding packages to that vm until the symptom exhibits itself maybe. From weldon at langurwallah.org Thu Jul 24 03:47:33 2014 From: weldon at langurwallah.org (Weldon Goree) Date: Thu, 24 Jul 2014 09:17:33 +0530 Subject: [Slackbuilds-users] Is anybody doing musl? In-Reply-To: <20140723233632.3029482c@stygian.midgard.home> References: <53C8E3FD.2040609@langurwallah.org> <20140718165413.4b97712d@stygian.midgard.home> <53CA0040.6070400@langurwallah.org> <20140719205340.1f13f860@stygian.midgard.home> <53CB3347.9020608@langurwallah.org> <20140723232835.3869b0b0@stygian.midgard.home> <53D07E9B.4010107@langurwallah.org> <20140723233632.3029482c@stygian.midgard.home> Message-ID: <53D081D5.2000406@langurwallah.org> On 07/24/2014 09:06 AM, John Vogel wrote: > > No. I still had the vm running, so I just double checked and no blank lines > between musl-ldd output and next shell prompt. But then this is a very, very > minimal install. When I mess with more thorough testing this weekend, I can > try adding packages to that vm until the symptom exhibits itself maybe. Don't go to any trouble; my suspicion is PEBCAK (I can force the error by doing a bad cross-compile that pulls in both GNU and musl stuff). I don't use static linking very much, so let me know if you run into any problems in that direction especially. Also I'm traveling for the next few days, so I'll be going dark for a bit. Weldon From petar.linog at gmail.com Thu Jul 24 10:08:56 2014 From: petar.linog at gmail.com (petar) Date: Thu, 24 Jul 2014 12:08:56 +0200 Subject: [Slackbuilds-users] Choqok Message-ID: <53D0DB38.1070008@gmail.com> Hi, I asked maintainer of buildscript for Choqok, Dave, to "take over" his job (maintaining of the script) because He don't use the program anymore and don't want to maintain the script. He agree with that. > Hi, Dave > > are you still willing to maintain slackbuild script for the program? > I am using Choqok for years and I love the program. > Actual version of the program is 1.4, but in your script version is > 1.3. I ask this because I am wiling to continue to maintain the script > if you don't want anymore. Hi Petar, I don't really use choquk any more so if you want to take it over that's ok. > By the way, I built package Chokoq 1.4 with the script and it works > fine. I'm using it for several mounths and don't have any problems. > So, the script is good for the new version of the program, too. > > Regards, Petar (slackmuz) > > P.S. Sorry for my english. It's not my native language. No worries. Dave May I take over the maintaining? From willysr at slackbuilds.org Thu Jul 24 09:05:02 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 24 Jul 2014 16:05:02 +0700 Subject: [Slackbuilds-users] Choqok In-Reply-To: <53D0DB38.1070008@gmail.com> References: <53D0DB38.1070008@gmail.com> Message-ID: <53D0CC3E.9010407@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > May I take over the maintaining? Yes please submit the update through submission form make sure to use the latest version from our website Thanks - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPQzD4ACgkQiHuDdNczM4FkAwCdHx7u17BJ6NIZNC51/dRk1tX+ 2+YAn2j3oemfr+jvsASn5hu439gZnva6 =L8eT -----END PGP SIGNATURE----- From didier.spaier at epsm.fr Thu Jul 24 09:22:20 2014 From: didier.spaier at epsm.fr (Didier Spaier) Date: Thu, 24 Jul 2014 11:22:20 +0200 Subject: [Slackbuilds-users] Typo in SlackBuild for po4a Message-ID: <53D0D04C.1020809@epsm.fr> sed -i 's:rm -rf $PKG/usr/share:rm -rf $PKG/usr/share/man:' po4a.SlackBuild Sorry for that stupid mistake. Should I submit an update or can this be taken care of by an admin, possibly increasing the build number? Didier From willysr at slackbuilds.org Thu Jul 24 09:54:33 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 24 Jul 2014 16:54:33 +0700 Subject: [Slackbuilds-users] Typo in SlackBuild for po4a In-Reply-To: <53D0D04C.1020809@epsm.fr> References: <53D0D04C.1020809@epsm.fr> Message-ID: <53D0D7D9.3010304@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > sed -i 's:rm -rf $PKG/usr/share:rm -rf $PKG/usr/share/man:' > po4a.SlackBuild > > Sorry for that stupid mistake. > > Should I submit an update or can this be taken care of by an > admin, possibly increasing the build number? Fixed on my branch - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPQ19kACgkQiHuDdNczM4HuSQCfc8gdqI4dzzqr5S9uVqtXxyAJ w0AAn2d+D4G4ysG4TtoqUFy5kqtkP4JM =QsXL -----END PGP SIGNATURE----- From didier.spaier at epsm.fr Thu Jul 24 10:05:50 2014 From: didier.spaier at epsm.fr (Didier Spaier) Date: Thu, 24 Jul 2014 12:05:50 +0200 Subject: [Slackbuilds-users] Typo in SlackBuild for po4a In-Reply-To: <53D0D7D9.3010304@slackbuilds.org> References: <53D0D04C.1020809@epsm.fr> <53D0D7D9.3010304@slackbuilds.org> Message-ID: <53D0DA7E.7050204@epsm.fr> On 24/07/2014 11:54, Willy Sudiarto Raharjo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> sed -i 's:rm -rf $PKG/usr/share:rm -rf $PKG/usr/share/man:' >> po4a.SlackBuild >> >> Sorry for that stupid mistake. >> >> Should I submit an update or can this be taken care of by an >> admin, possibly increasing the build number? > Fixed on my branch > Thanks Willy. From rshepard at appl-ecosys.com Thu Jul 24 13:12:36 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Thu, 24 Jul 2014 06:12:36 -0700 (PDT) Subject: [Slackbuilds-users] Slackbuilds Plus Issue Message-ID: I looked at the slackbuilds plus pages on sourceforge.net without finding an e-mail address for the developer(s). Perhaps someone here can point me in the right direction. My question is how to specify an entry in /etc/slackpkg/blacklist when the same package is found in two repositories. This came up this morning when I saw messages from the slackware development team of patched packages and I ran slackpkgplus to update what needed to be updated. One of the listed packages was scribus-1.4.3-i486. I already had that version from the SBo repository, but did not check each package on the list so that package was replaced by the one from alien BOB's repository. There's no need to upgrade the same package version from a different repository, but the instructions for the blacklist are to list only the package name, not the version, nor (I assume) the tag. Is there a way to avoid replacing an exising version of a package with one from a different repository? Rich From matteo.bernardini at gmail.com Thu Jul 24 13:19:37 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Thu, 24 Jul 2014 15:19:37 +0200 Subject: [Slackbuilds-users] Slackbuilds Plus Issue In-Reply-To: References: Message-ID: 2014-07-24 15:12 GMT+02:00 Rich Shepard : > I looked at the slackbuilds plus pages on sourceforge.net without finding > an e-mail address for the developer(s). Perhaps someone here can point me in > the right direction. maybe someone can help you also here, but I think the best way to get in touch with the author or get general help from other users of slackpkg+ is to post on the dedicated LQ thread https://www.linuxquestions.org/questions/slackware-14/slackpkg-vs-third-party-package-repository-4175427364/ From rshepard at appl-ecosys.com Thu Jul 24 13:47:57 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Thu, 24 Jul 2014 06:47:57 -0700 (PDT) Subject: [Slackbuilds-users] Slackbuilds Plus Issue In-Reply-To: References: Message-ID: On Thu, 24 Jul 2014, Matteo Bernardini wrote: > maybe someone can help you also here, but I think the best way to get in > touch with the author or get general help from other users of slackpkg+ is > to post on the dedicated LQ thread > > https://www.linuxquestions.org/questions/slackware-14/slackpkg-vs-third-party-package-repository-4175427364/ Thanks, Matteo. I'll definitely follow that thread. Rich From hostmaster at slackonly.com Thu Jul 24 14:53:07 2014 From: hostmaster at slackonly.com (Panagiotis Nikolaou) Date: Thu, 24 Jul 2014 17:53:07 +0300 Subject: [Slackbuilds-users] xbmc Message-ID: <53D11DD3.80106@slackonly.com> I use slackware64-current and after last update of glew-1.9 to glew-1.10 xbmc failed to start because is linking to libGLEW.so.1.9. To resolve it add a symlink : ln -s /usr/lib64/libGLEW.so.1.10 /usr/lib64/libGLEW.so.1.9 Panagiotis From matteo.bernardini at gmail.com Thu Jul 24 15:26:50 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Thu, 24 Jul 2014 17:26:50 +0200 Subject: [Slackbuilds-users] xbmc In-Reply-To: <53D11DD3.80106@slackonly.com> References: <53D11DD3.80106@slackonly.com> Message-ID: 2014-07-24 16:53 GMT+02:00 Panagiotis Nikolaou : > I use slackware64-current and after last update of glew-1.9 to glew-1.10 > xbmc failed to start because is linking to libGLEW.so.1.9. > To resolve it add a symlink : ln -s /usr/lib64/libGLEW.so.1.10 > /usr/lib64/libGLEW.so.1.9 you probably have to rebuild the package in question. to avoid misunderstandings, SBo distributes only build scripts, not packages. Matteo From rshepard at appl-ecosys.com Thu Jul 24 22:59:41 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Thu, 24 Jul 2014 15:59:41 -0700 (PDT) Subject: [Slackbuilds-users] Slackbuilds Plus Issue [RESOLVED] In-Reply-To: References: Message-ID: On Thu, 24 Jul 2014, Matteo Bernardini wrote: > maybe someone can help you also here, but I think the best way to get > in touch with the author or get general help from other users of > slackpkg+ is to post on the dedicated LQ thread Matteo, As I upgraded packages on a laptop here this afternoon I saw something I have not noticed on the server/workstation: below the ncurses list of available packages is a status line that tells me what package is already installed and what package would replace it. With this information I can make informed decisions and not replace the same application and version with one from a different repository. Regards, Rich From kingbeowulf at gmail.com Fri Jul 25 03:22:49 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 24 Jul 2014 20:22:49 -0700 Subject: [Slackbuilds-users] Slackbuilds Plus Issue [RESOLVED] In-Reply-To: References: Message-ID: <53D1CD89.5030809@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2014 03:59 PM, Rich Shepard wrote: > On Thu, 24 Jul 2014, Matteo Bernardini wrote: > >> maybe someone can help you also here, but I think the best way to >> get in touch with the author or get general help from other users >> of slackpkg+ is to post on the dedicated LQ thread > > Matteo, > > As I upgraded packages on a laptop here this afternoon I saw > something I have not noticed on the server/workstation: below the > ncurses list of available packages is a status line that tells me > what package is already installed and what package would replace > it. With this information I can make informed decisions and not > replace the same application and version with one from a different > repository. > > Regards, > > Rich > Rich I was running all over Oregon this this week so missed your thread. Besides looking at the status line, you can do what I do (as an example). I've set up slackpkg+ to use its "greylist" function. This is for repos you wnat to flag but not automatically install/upgrade. Thus, in /etc/slackpkg/slackpkgplus.conf add: - --------------------- # Enable (on) / Disable (off) the greylist feature. See /etc/slackpkg/greylist GREYLIST=on - --------------------- Then, add the repos you want slackpkg to display as unchecked into /etc/slackpkg/greylist - --------------------- # Compiled our customized packages freetype # Don't automatically select external repos for upgrade alienbob kingbeowulf multilib restricted - ------------------- Now, when I run "slackpkg update" and "slackpkg upgrade-all" only the official patches are selected (see attached). Here you see only the official mainline patches selected with the rest displayed but not checked by default. That way, if I create a custom build (in kingbeowulf), or AlienBOB has a different build than what I or Slackware prefers, it is not automatically installed - until I look at it. Hope this helps. Have fun! - -Ed -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPRzYcACgkQXvwMaW61dLdceACfdOkNsDSlE4D9ATa8qz+xuvIG jrUAnj1GvW/hRkF3Y4SWb0MBSdxCUb7x =Tt3q -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: slackpkg_update_example.png Type: image/png Size: 50891 bytes Desc: not available URL: From rshepard at appl-ecosys.com Fri Jul 25 14:28:41 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Fri, 25 Jul 2014 07:28:41 -0700 (PDT) Subject: [Slackbuilds-users] Slackbuilds Plus Issue [RESOLVED] In-Reply-To: <53D1CD89.5030809@gmail.com> References: <53D1CD89.5030809@gmail.com> Message-ID: On Thu, 24 Jul 2014, King Beowulf wrote: > I've set up slackpkg+ to use its "greylist" function. This is for > repos you wnat to flag but not automatically install/upgrade. Ed, Looks like the perfect solution: shows what's new in all other repositories and lets me enable each upgrade only when appropriate. Thanks, Rich From rudsonalves at yahoo.com.br Sat Jul 26 17:18:01 2014 From: rudsonalves at yahoo.com.br (Rudson R Alves) Date: Sat, 26 Jul 2014 14:18:01 -0300 Subject: [Slackbuilds-users] Packages name rulers In-Reply-To: References: Message-ID: <53D3E2C9.5080509@yahoo.com.br> Hi people, Exist a clear ruler to build a package name? I was set a package name in may programs by a regular expression: r'^([^\-].*)\-([^\-]*)\-(x86_64|x86|i[3456]86|noarch|fw)\-([0-9][^\-]*)\.(t[gblx]z)$') and r'^([^\-].*)\-([^\-]*)\-(x86_64|x86|i[3456]86|noarch|fw)\-([0-9][^\.\-]*)\-upgraded\-.*$') for upgrade error packages. I based it in the official packages distributed by SlackwareDVD. However I have found some variants in SlackBuild.org, like ffmpeg thatuse '-custon' along the architecture. Is possible to define a ruler to packages names? If exist, is important to put them in any SlackBuild.org document toavoid variations. From rudsonalves at yahoo.com.br Sat Jul 26 17:19:32 2014 From: rudsonalves at yahoo.com.br (Rudson R Alves) Date: Sat, 26 Jul 2014 14:19:32 -0300 Subject: [Slackbuilds-users] Packages name rulers Message-ID: <53D3E324.8060101@yahoo.com.br> Hi people, Exist a clear ruler to build a package name? I was set a package name in may programs by a regular expression: r'^([^\-].*)\-([^\-]*)\-(x86_64|x86|i[3456]86|noarch|fw)\-([0-9][^\-]*)\.(t[gblx]z)$') and r'^([^\-].*)\-([^\-]*)\-(x86_64|x86|i[3456]86|noarch|fw)\-([0-9][^\.\-]*)\-upgraded\-.*$') for upgrade error packages. I based it in the official packages distributed by SlackwareDVD. However I have found some variants in SlackBuild.org, like ffmpeg thatuse '-custon' along the architecture. Is possible to define a ruler to packages names? If exist, is important to put them in any SlackBuild.org document toavoid variations. From thedoogster at gmail.com Sat Jul 26 17:28:12 2014 From: thedoogster at gmail.com (Doogster) Date: Sat, 26 Jul 2014 10:28:12 -0700 Subject: [Slackbuilds-users] Packages name rulers In-Reply-To: <53D3E324.8060101@yahoo.com.br> References: <53D3E324.8060101@yahoo.com.br> Message-ID: The rules for package names are simple. They follow the following format: [PACKAGE_NAME]-[VERSION]-ARCH-TAG Where the delimiters are the last three hyphens. This is what PKGTool expects, and it's consistent with Pat's package names. If your regex can't handle that, then it's the regex that needs to change. On Sat, Jul 26, 2014 at 10:19 AM, Rudson R Alves wrote: > Hi people, > > Exist a clear ruler to build a package name? > > I was set a package name in may programs by a regular expression: > > r'^([^\-].*)\-([^\-]*)\-(x86_64|x86|i[3456]86|noarch|fw)\-([0-9][^\-]*)\.(t[gblx]z)$') > > and > > r'^([^\-].*)\-([^\-]*)\-(x86_64|x86|i[3456]86|noarch|fw)\-([0-9][^\.\-]*)\-upgraded\-.*$') > > for upgrade error packages. > > I based it in the official packages distributed by SlackwareDVD. However I > have found some variants in SlackBuild.org, like ffmpeg thatuse '-custon' > along the architecture. > > Is possible to define a ruler to packages names? > > If exist, is important to put them in any SlackBuild.org document toavoid > variations. > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From j3ffdick at gmail.com Mon Jul 28 14:54:39 2014 From: j3ffdick at gmail.com (Jeffrey Dick) Date: Mon, 28 Jul 2014 22:54:39 +0800 Subject: [Slackbuilds-users] Recoll slackbuild problem Message-ID: Hi, I've found what looks like a bug in the SlackBuild for Recoll. Even if ENABLE_CAMELCASE is set to NO (the default), the test in the script returns true, and --enable-camelcase is passed to the configure command. The following partial diff shows a corrected version, with whitespace around the == operator: -if test $ENABLE_CAMELCASE=="YES" +if test $ENABLE_CAMELCASE == "YES" then CAMEL_CASE_CONFIG="--enable-camelcase" else CAMEL_CASE_CONFIG="" fi This was discovered while chasing down a Recoll indexing crash: https://bitbucket.org/medoc/recoll/issue/210/indexing-error-std-out_of_range-with-some Cheers, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at aaazen.com Mon Jul 28 16:12:58 2014 From: richard at aaazen.com (Richard) Date: Mon, 28 Jul 2014 09:12:58 -0700 (PDT) Subject: [Slackbuilds-users] Recoll slackbuild problem In-Reply-To: References: Message-ID: On Mon, 28 Jul 2014, Jeffrey Dick wrote: > I've found what looks like a bug in the SlackBuild for Recoll. Even if ENABLE_CAMELCASE is set to NO (the default), > the test in the script returns true, and --enable-camelcase is passed to the configure command. The following partial > diff shows a corrected version, with whitespace around the == operator: > > -if test $ENABLE_CAMELCASE=="YES" > +if test $ENABLE_CAMELCASE == "YES" > then CAMEL_CASE_CONFIG="--enable-camelcase" > else CAMEL_CASE_CONFIG="" > fi > Perhaps the style of the if statement could be changed to match the rest of the script? if [ "$ENABLE_CAMELCASE" = "YES" ]; then CAMEL_CASE_CONFIG="--enable-camelcase" else CAMEL_CASE_CONFIG="" fi Or to test for mixed/lower case versions of "YES", something like this? if [ "${ENABLE_CAMELCASE,,}" = "yes" ]; then CAMEL_CASE_CONFIG="--enable-camelcase" else CAMEL_CASE_CONFIG="" fi Richard Narron --------------------------------------------------------------------- Q: How many existentialists does it take to screw in a lightbulb? A: Two. One to screw it in and one to observe how the lightbulb itself symbolizes a single incandescent beacon of subjective reality in a netherworld of endless absurdity reaching out toward a maudlin cosmos of nothingness. From bch at shroggslodge.freeserve.co.uk Tue Jul 29 10:51:28 2014 From: bch at shroggslodge.freeserve.co.uk (bch at shroggslodge.freeserve.co.uk) Date: Tue, 29 Jul 2014 11:51:28 +0100 Subject: [Slackbuilds-users] webkitgtk compile time Message-ID: Hello SB Users List I am sorry if I am inappropriately posting with this one, however some comments would be appreciated in any case. It is currently 3.5 hours since I started compiling the webkitgtk slackbuild. This is on a quad core 2.6GHz machine (not the fastest I admit but still). >From searching around, it seems that the usual experience of compiling webkitgtk is not good, but one forum post seemed to suggest 45 mins or so and called that a 'long time'. I would be interested to know if any one else has compiled and had this 'problem', or is aware of it and if there are any steps I can take in situations like this to limit the compile time. I'm just getting used to building packages and things and slowly understanding the SlackBuilds process, but nothing has taken this long so far. Thanks for any comments. Habs -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.bernardini at gmail.com Tue Jul 29 11:06:22 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 29 Jul 2014 13:06:22 +0200 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: References: Message-ID: it's normal with webkitgtk, just be patient. From baildon.research at googlemail.com Tue Jul 29 11:24:20 2014 From: baildon.research at googlemail.com (David Spencer) Date: Tue, 29 Jul 2014 12:24:20 +0100 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: References: Message-ID: > It is currently 3.5 hours since I started compiling the webkitgtk > slackbuild. This is on a quad core 2.6GHz machine (not the fastest I admit > but still). The webkitgtk build process fails if run with multiple parallel jobs, so it will only use one of your cores. On a 3.2GHz box I expect about 3.5 hours. For you it'll be ~ 4h 20m at a guess. If it's any consolation, webkitgtk is (I think) the absolute longest build in SBo. Also, for anything that *does* use multiple jobs, your box is faster than anything I've got here... so don't feel bad if some boy racer boasts about 45 min compiles of webkitgtk (probably bs). -D. From ryanpcmcquen at gmail.com Tue Jul 29 12:09:34 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Tue, 29 Jul 2014 05:09:34 -0700 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: References: Message-ID: Just wait until you compile GCC on LFS. You have so many long compile times to look forward to. ;^) --- On Jul 29, 2014, at 4:24 AM, David Spencer wrote: >> It is currently 3.5 hours since I started compiling the webkitgtk >> slackbuild. This is on a quad core 2.6GHz machine (not the fastest I admit >> but still). > > The webkitgtk build process fails if run with multiple parallel jobs, > so it will only use one of your cores. On a 3.2GHz box I expect about > 3.5 hours. For you it'll be ~ 4h 20m at a guess. > > If it's any consolation, webkitgtk is (I think) the absolute longest > build in SBo. Also, for anything that *does* use multiple jobs, your > box is faster than anything I've got here... so don't feel bad if some > boy racer boasts about 45 min compiles of webkitgtk (probably bs). > > -D. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From aaditya_gnulinux at zoho.com Tue Jul 29 12:40:35 2014 From: aaditya_gnulinux at zoho.com (Aaditya Bagga) Date: Tue, 29 Jul 2014 18:10:35 +0530 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: References: Message-ID: <53D79643.2030009@zoho.com> On 29-07-2014 16:21, bch at shroggslodge.freeserve.co.uk wrote: > Hello SB Users List > > I am sorry if I am inappropriately posting with this one, however some > comments would be appreciated in any case. > > It is currently 3.5 hours since I started compiling the webkitgtk > slackbuild. This is on a quad core 2.6GHz machine (not the fastest I > admit but still). > > From searching around, it seems that the usual experience of compiling > webkitgtk is not good, but one forum post seemed to suggest 45 mins or > so and called that a 'long time'. > > I would be interested to know if any one else has compiled and had > this 'problem', or is aware of it and if there are any steps I can > take in situations like this to limit the compile time. > > I'm just getting used to building packages and things and slowly > understanding the SlackBuilds process, but nothing has taken this long > so far. > > Thanks for any comments. > Habs > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > That's the reason why whenever I compile it, I put it up on: http://sourceforge.net/projects/mefiles/files/Slackware/ You could also find some prebuilt SBo packages (not by me, though I do use them sometimes) on: http://slackonly.com/pub/packages/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From baildon.research at googlemail.com Tue Jul 29 13:51:39 2014 From: baildon.research at googlemail.com (David Spencer) Date: Tue, 29 Jul 2014 14:51:39 +0100 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: <53D79643.2030009@zoho.com> References: <53D79643.2030009@zoho.com> Message-ID: > That's the reason why whenever I compile it, I put it up on: > http://sourceforge.net/projects/mefiles/files/Slackware/ Actually, it's worth mentioning that Erik pushed an update for webkitgtk-2.4.4 to git last week, so we are all going to have to build it again soon... or wait for Aaditya ;-) -D. From aaditya_gnulinux at zoho.com Tue Jul 29 14:07:36 2014 From: aaditya_gnulinux at zoho.com (Aaditya Bagga) Date: Tue, 29 Jul 2014 19:37:36 +0530 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: References: <53D79643.2030009@zoho.com> Message-ID: <53D7AAA8.6090103@zoho.com> On 29-07-2014 19:21, David Spencer wrote: >> That's the reason why whenever I compile it, I put it up on: >> http://sourceforge.net/projects/mefiles/files/Slackware/ > Actually, it's worth mentioning that Erik pushed an update for > webkitgtk-2.4.4 to git last week, so we are all going to have to build > it again soon... or wait for Aaditya ;-) > > -D. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > Only if you use 64 bit :) And I may not build it immediately ;) (Last time I had waited a bit to see if an update came up from slackonly.org or slacky.eu) From hostmaster at slackonly.com Tue Jul 29 14:14:33 2014 From: hostmaster at slackonly.com (Panagiotis Nikolaou) Date: Tue, 29 Jul 2014 17:14:33 +0300 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: <53D7AAA8.6090103@zoho.com> References: <53D79643.2030009@zoho.com> <53D7AAA8.6090103@zoho.com> Message-ID: <53D7AC49.9030906@slackonly.com> On 07/29/2014 05:07 PM, Aaditya Bagga wrote: > On 29-07-2014 19:21, David Spencer wrote: >>> That's the reason why whenever I compile it, I put it up on: >>> http://sourceforge.net/projects/mefiles/files/Slackware/ >> Actually, it's worth mentioning that Erik pushed an update for >> webkitgtk-2.4.4 to git last week, so we are all going to have to build >> it again soon... or wait for Aaditya ;-) >> >> -D. >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> > Only if you use 64 bit :) > And I may not build it immediately ;) > (Last time I had waited a bit to see if an update came up from > slackonly.org or slacky.eu) > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > guys i promise to build immediately packages for x32 and x64 as a update come out... i have some spare time at this season :-) From ryanpcmcquen at gmail.com Tue Jul 29 14:24:43 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Tue, 29 Jul 2014 07:24:43 -0700 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: <53D7AC49.9030906@slackonly.com> References: <53D79643.2030009@zoho.com> <53D7AAA8.6090103@zoho.com> <53D7AC49.9030906@slackonly.com> Message-ID: I have 64-bit build of 2.4.4 here: https://bitbucket.org/ryanpcmcquen/slack-binaries/src/3d69ac1ce77d46c1cf3045772eecbc97c31e8ace/builtOn141/?at=master --- > On Jul 29, 2014, at 7:14 AM, Panagiotis Nikolaou wrote: > >> On 07/29/2014 05:07 PM, Aaditya Bagga wrote: >> On 29-07-2014 19:21, David Spencer wrote: >>>> That's the reason why whenever I compile it, I put it up on: >>>> http://sourceforge.net/projects/mefiles/files/Slackware/ >>> Actually, it's worth mentioning that Erik pushed an update for >>> webkitgtk-2.4.4 to git last week, so we are all going to have to build >>> it again soon... or wait for Aaditya ;-) >>> >>> -D. >>> _______________________________________________ >>> SlackBuilds-users mailing list >>> SlackBuilds-users at slackbuilds.org >>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >>> FAQ - http://slackbuilds.org/faq/ >> Only if you use 64 bit :) >> And I may not build it immediately ;) >> (Last time I had waited a bit to see if an update came up from >> slackonly.org or slacky.eu) >> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ > guys i promise to build immediately packages for x32 and x64 as a update > come out... > i have some spare time at this season :-) > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From yalhcru at gmail.com Tue Jul 29 17:06:42 2014 From: yalhcru at gmail.com (B Watson) Date: Tue, 29 Jul 2014 13:06:42 -0400 Subject: [Slackbuilds-users] webkitgtk compile time In-Reply-To: References: Message-ID: On 7/29/14, bch at shroggslodge.freeserve.co.uk wrote: > From searching around, it seems that the usual experience of compiling > webkitgtk is not good, but one forum post seemed to suggest 45 mins or so > and called that a 'long time'. Was that on Slackware, or some other distro? Slackware's make is GNU make 3, which has a bug relating to parallel builds that the GNU folks refuse to fix in the 3.x branch (their answer is that everyone should be using 4.x). The fix is a small patch that's been available since 2010 or so. Other distros have either already upgraded to make 4.x, or else their 3.x make includes the patch... but Slackware 14.1 doesn't, and since it's not a security fix, it never will. However, I just had a look at slackware-current, its make does have the patch, so this won't be a problem in Slackware 14.2 (or 15.0, whatever it ends up being called). If you're feeling adventurous, you could get the SlackBuild for make from the -current source tree and build it on 14.1. Odds are it would work just fine, and you'd end up being able to get rid of the "-j1" in the webkitgtk SlackBuild... but if it breaks, you get to keep both pieces.