I see. Thanks!
On Sun, Mar 13, 2016 at 11:02 PM, Willy Sudiarto Raharjo <
will...@slackbuilds.org> wrote:
> > Well, it looks like the same guy did it again in January. I thought only
> > the maintainer could submit updates to the slackbuild. Is that
> incorrect?
> >
> > Since this appears to b
> Well, it looks like the same guy did it again in January. I thought only
> the maintainer could submit updates to the slackbuild. Is that incorrect?
>
> Since this appears to be happening, lets just go ahead and commit this
> update. It eliminates the cumbersome patch files and gets us all th
On 2016-03-13 20:00, Andrzej Telszewski wrote:
On 13/03/16 19:46, Ryan P.C. McQuen wrote:
On Sun, Mar 13, 2016 at 11:36 AM Andrzej Telszewski
mailto:atelszew...@gmail.com>> wrote:
On 13/03/16 19:29, Luís Fernando Carvalho Cavalheiro wrote:
> Well, well... sudo is a example of piece o
Well, it looks like the same guy did it again in January. I thought only
the maintainer could submit updates to the slackbuild. Is that incorrect?
Since this appears to be happening, lets just go ahead and commit this
update. It eliminates the cumbersome patch files and gets us all the
latest b
> This update isn't critical so it can wait. But when we went from 14.0 to
> 14.1, the slackbuild was updated by someone other than me and I don't know
> why or by whom. As long as that isn't going to happen, I'll wait.
You can check the history here
https://slackbuilds.org/cgit/slackbuilds/
--
This update isn't critical so it can wait. But when we went from 14.0 to
14.1, the slackbuild was updated by someone other than me and I don't know
why or by whom. As long as that isn't going to happen, I'll wait.
On Sun, Mar 13, 2016 at 9:05 PM, Willy Sudiarto Raharjo <
will...@slackbuilds.org>
On 3/12/16, Erik Hanson wrote:
> On Sun, 13 Mar 2016 00:23:17 +
> "Ryan P.C. McQuen" wrote:
>
>
>> Erik,
>>
>> Are you opposed to this solution?
>>
>> find -L . \
>> \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
>> -o -perm 511 \) -print0 | \
>> xargs -0 chmod 755
>>
> I have an update for a slackbuild I maintain (VICE), but the current one is
> building fine but it is a rather old version of the package. Do I have to
> wait until 14.2 opens or will submissions re-open before 14.2 for general
> updates?
It's up to you if you want to wait but if you think it n
I have an update for a slackbuild I maintain (VICE), but the current one is
building fine but it is a rather old version of the package. Do I have to
wait until 14.2 opens or will submissions re-open before 14.2 for general
updates?
Eric
___
SlackBuilds
> Are you guys up to date with the Thu Mar 10 02:46:49 UTC 2016 -current
> update?
Yes, my system is up to date with latest current update, but probably
since i tested in my desktop, it's also filled with many packages i used
so it may affect the build.
let me try on a clean VM like i always do
It makes sense, Ryan...
Em 13 de 03 de 2016 às 20:00:18T+0100, Andrzej Telszewski
escreveu:
> On 13/03/16 19:46, Ryan P.C. McQuen wrote:
> >
> >
> > On Sun, Mar 13, 2016 at 11:36 AM Andrzej Telszewski
> > mailto:atelszew...@gmail.com>> wrote:
> >
> > On 13/03/16 19:29, Luís Fernando Carvalh
On 13/03/16 19:46, Ryan P.C. McQuen wrote:
On Sun, Mar 13, 2016 at 11:36 AM Andrzej Telszewski
mailto:atelszew...@gmail.com>> wrote:
On 13/03/16 19:29, Luís Fernando Carvalho Cavalheiro wrote:
> Well, well... sudo is a example of piece of software (personally
I call sudo "piece of
On 03/13/2016 01:27 AM, Matteo Bernardini wrote:
> 2016-03-13 10:15 GMT+01:00 Matteo Bernardini :
>> I'll keep testing it on my laptop.
>
> not really sure if it's something wrong here but when running ldconfig
> I got this output:
>
> ldconfig: /usr/lib64/libGLESv1_CM.so.1 is not a symbolic link
On Sun, Mar 13, 2016 at 11:36 AM Andrzej Telszewski
wrote:
> On 13/03/16 19:29, Luís Fernando Carvalho Cavalheiro wrote:
> > Well, well... sudo is a example of piece of software (personally I call
> sudo "piece of cr..") that relies on strange permissions: /etc/sudoers
> needs to be at 440.
> >
>
On 13/03/16 19:29, Luís Fernando Carvalho Cavalheiro wrote:
Well, well... sudo is a example of piece of software (personally I call sudo "piece
of cr..") that relies on strange permissions: /etc/sudoers needs to be at 440.
But you talk about *already* installed software, which is different
s
Well, well... sudo is a example of piece of software (personally I call sudo
"piece of cr..") that relies on strange permissions: /etc/sudoers needs to be
at 440.
Em 13 de 03 de 2016 às 19:23:50T+0100, Andrzej Telszewski
escreveu:
> On 13/03/16 17:03, Erik Hanson wrote:
> > On Sun, 13 Mar 201
On 13/03/16 19:18, Luís Fernando Carvalho Cavalheiro wrote:
If qtwebengine isn't a hard dependency, it should be better having a option to
build qt5 without it - but letting qtwebengine enabled by default.
I was able to build qt5 without qtwebengine, and Qt Creator also built
and runs fine.
On 13/03/16 17:03, Erik Hanson wrote:
On Sun, 13 Mar 2016 16:28:36 +0100
Andrzej Telszewski wrote:
On 13/03/16 16:23, Erik Hanson wrote:
On Sun, 13 Mar 2016 15:34:25 +0100
Johannes Schöpfer wrote:
It would be helpful If someone could name a single reallife
example, where the chmod approach
If qtwebengine isn't a hard dependency, it should be better having a option to
build qt5 without it - but letting qtwebengine enabled by default.
Em 13 de 03 de 2016 às 19:16:18T+0100, Andrzej Telszewski
escreveu:
> On 13/03/16 18:42, David Spencer wrote:
> >> /home/software/slackware/pkg/tmpd
On 13/03/16 18:42, David Spencer wrote:
/home/software/slackware/pkg/tmpdir/qt-everywhere-opensource-src-5.5.1/qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2091:15:
error: ‘CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}’ has no member
named ‘pIv’
aeadParams.pIv =
> /home/software/slackware/pkg/tmpdir/qt-everywhere-opensource-src-5.5.1/qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2091:15:
> error: ‘CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}’ has no member
> named ‘pIv’
> aeadParams.pIv = (unsigned char *) additionalData;
>
On 13/03/16 17:10, Erik Hanson wrote:
On Sun, 13 Mar 2016 16:24:17 +0100
Andrzej Telszewski wrote:
On 13/03/16 16:05, Erik Hanson wrote:
On Sun, 13 Mar 2016 11:18:47 +0100
Andrzej Telszewski wrote:
Hi,
I know that as a general rule, we don't patch and keep upstream
source intact, but mayb
On Sun, 13 Mar 2016 16:24:17 +0100
Andrzej Telszewski wrote:
> On 13/03/16 16:05, Erik Hanson wrote:
> > On Sun, 13 Mar 2016 11:18:47 +0100
> > Andrzej Telszewski wrote:
> >
> >> Hi,
> >>
> >> I know that as a general rule, we don't patch and keep upstream
> >> source intact, but maybe fpm2 co
On Sun, 13 Mar 2016 16:28:36 +0100
Andrzej Telszewski wrote:
> On 13/03/16 16:23, Erik Hanson wrote:
> > On Sun, 13 Mar 2016 15:34:25 +0100
> > Johannes Schöpfer wrote:
> >
> >> It would be helpful If someone could name a single reallife
> >> example, where the chmod approach fails.
> >
> >
On 13/03/16 16:35, Luís Fernando Carvalho Cavalheiro wrote:
Plus consider to fork original code and maintain it by yourself.
I'm already thinking about that, but if I decided to do so, I would
rewrite the application using Qt. But it's a distant future.
I keep using FPM2 because it suits my
Plus consider to fork original code and maintain it by yourself.
Em 13 de 03 de 2016 às 10:05:49T-0500, Erik Hanson
escreveu:
> On Sun, 13 Mar 2016 11:18:47 +0100
> Andrzej Telszewski wrote:
>
> > Hi,
> >
> > I know that as a general rule, we don't patch and keep upstream
> > source intact,
On 13/03/16 16:23, Erik Hanson wrote:
On Sun, 13 Mar 2016 15:34:25 +0100
Johannes Schöpfer wrote:
It would be helpful If someone could name a single reallife example,
where the chmod approach fails.
It changes permissions of 700 to 755, which is something the 'find'
lines don't do. The merit
On 13/03/16 16:05, Erik Hanson wrote:
On Sun, 13 Mar 2016 11:18:47 +0100
Andrzej Telszewski wrote:
Hi,
I know that as a general rule, we don't patch and keep upstream
source intact, but maybe fpm2 could be patched with the two patches I
kept hidden for myself for quite some time? They are wri
On Sun, 13 Mar 2016 15:34:25 +0100
Johannes Schöpfer wrote:
> It would be helpful If someone could name a single reallife example,
> where the chmod approach fails.
It changes permissions of 700 to 755, which is something the 'find'
lines don't do. The merits and circumstances behind this, or my
It would be helpful If someone could name a single reallife example, where the
chmod approach fails.
FranzenAm 13.03.2016 2:18 vorm. schrieb Luís Fernando Carvalho Cavalheiro
:
>
> I'd stick with find solution. If a source has more files than chmod can
> handle (or perhaps bash can do, since th
On Sun, 13 Mar 2016 11:18:47 +0100
Andrzej Telszewski wrote:
> Hi,
>
> I know that as a general rule, we don't patch and keep upstream
> source intact, but maybe fpm2 could be patched with the two patches I
> kept hidden for myself for quite some time? They are written by me.
>
> fpm2 seems to
On 13/03/16 11:12, Willy Sudiarto Raharjo wrote:
Well, for me, the RESUMED build fails with the single job too, now with
the following error:
best not to resume a broken build
please restart the whole process as i just built Qt 5.5.1 yesterday and
it went fine
Are you guys up to date with th
Let's suppose a source with a very huge number of files on it, with a very deep
directory structure. If if goes bigger than bash expansion of maximum command
line size chmod would fail and leave some files with unchanged permissions.
I don't understand, through, why the find + xargs approach. Wh
On 13/03/16 11:12, Willy Sudiarto Raharjo wrote:
Well, for me, the RESUMED build fails with the single job too, now with
the following error:
best not to resume a broken build
please restart the whole process as i just built Qt 5.5.1 yesterday and
it went fine
Have you looked at my "build en
Hi,
I know that as a general rule, we don't patch and keep upstream source
intact, but maybe fpm2 could be patched with the two patches I kept
hidden for myself for quite some time? They are written by me.
fpm2 seems to be not developed since ~2012.
--
Best regards,
Andrzej Telszewski
--- fp
> Well, for me, the RESUMED build fails with the single job too, now with
> the following error:
best not to resume a broken build
please restart the whole process as i just built Qt 5.5.1 yesterday and
it went fine
--
Willy Sudiarto Raharjo
signature.asc
Description: OpenPGP digital signatu
On 13/03/16 10:09, Matteo Bernardini wrote:
2016-03-13 10:00 GMT+01:00 Andrzej Telszewski :
Hi,
I'm on Slackware-current and SBo master.
I'm trying to build qt5 and it fails with the following error:
[6/10258] CXX
obj/src/3rdparty/chromium/third_party/protobuf/src/google/protobuf/compiler/pro
On Sunday, March 13, 2016, Matteo Bernardini
wrote:
> 2016-03-13 10:15 GMT+01:00 Matteo Bernardini >:
> > I'll keep testing it on my laptop.
>
> not really sure if it's something wrong here but when running ldconfig
> I got this output:
>
> ldconfig: /usr/lib64/libGLESv1_CM.so.1 is not a symboli
On 03/13/2016 01:15 AM, Matteo Bernardini wrote:
> 2016-03-13 8:09 GMT+01:00 King Beowulf :
>> Attached is a diff against 14.2 master (based on about 15:00 pm PST USA)
>> for the newest nvidia binary driver 361.28, or you can get the files here:
>>
>> (fast) http://www.koenigcomputers.com/sbo-testi
2016-03-13 10:15 GMT+01:00 Matteo Bernardini :
> I'll keep testing it on my laptop.
not really sure if it's something wrong here but when running ldconfig
I got this output:
ldconfig: /usr/lib64/libGLESv1_CM.so.1 is not a symbolic link
ldconfig: /usr/lib64/libEGL.so.1 is not a symbolic link
ldc
2016-03-13 8:09 GMT+01:00 King Beowulf :
> Attached is a diff against 14.2 master (based on about 15:00 pm PST USA)
> for the newest nvidia binary driver 361.28, or you can get the files here:
>
> (fast) http://www.koenigcomputers.com/sbo-testing/
> (slow) http://www.linuxgalaxy.org/files/sbo-testi
2016-03-13 10:00 GMT+01:00 Andrzej Telszewski :
> Hi,
>
> I'm on Slackware-current and SBo master.
>
> I'm trying to build qt5 and it fails with the following error:
>
> [6/10258] CXX
> obj/src/3rdparty/chromium/third_party/protobuf/src/google/protobuf/compiler/protobuf_full_do_not_use.parser.o
> n
Hi,
I'm on Slackware-current and SBo master.
I'm trying to build qt5 and it fails with the following error:
[6/10258] CXX
obj/src/3rdparty/chromium/third_party/protobuf/src/google/protobuf/compiler/protobuf_full_do_not_use.parser.o
ninja: build stopped: subcommand failed.
Makefile.gyp_run:766
On 13/03/16 02:18, Luís Fernando Carvalho Cavalheiro wrote:
I'd stick with find solution. If a source has more files than chmod can handle
(or perhaps bash can do, since there may be a limitation on * expansion), it
would fail to set desired permissions to files.
Em 13 de 03 de 2016 às 08:11:1
44 matches
Mail list logo
