On 15.03.2016 03:17, Luís Fernando Carvalho Cavalheiro wrote:
I've not tried with plus sign. I've tested
- find ... -print0 | xargs -0 ...
- find ... -exec 755 {} \;
- find ... -execdir 755 {} \;
It's all about the "+" if you compare to the xargs-approach.
Here's some discussion about it
I've not tried with plus sign. I've tested
- find ... -print0 | xargs -0 ...
- find ... -exec 755 {} \;
- find ... -execdir 755 {} \;
Last two forms required like ten times more time than first one. On MAME case,
it's a huge amount of time.
Em 14 de 03 de 2016 às 20:32:44T-0500, Kyle Guinn
On 3/14/16, Didier Spaier wrote:
> Let me add: only make a change if there is a proven advantage, like
> _ old way failing (provide example), where the new one does not
I occasionally come across source tarballs where every file
unintentionally has the sticky bit set. (I don't
On 3/14/16, Luís Fernando Carvalho Cavalheiro
wrote:
> Hey guys. As ironic it looks like, the fastest approach is find + xargs. I
> won't rewrite my own SlackBuilds, but new ones will use find + xargs.
Have you tried "-exec chmod 644 {} +" or "-execdir chmod 644 {} +"
Hey guys. As ironic it looks like, the fastest approach is find + xargs. I
won't rewrite my own SlackBuilds, but new ones will use find + xargs.
Em 14 de 03 de 2016 às 15:48:55T-0500, Erik Hanson
escreveu:
> On Mon, 14 Mar 2016 16:04:50 -0300
> Luis Cavalheiro
I'm with -execdir approach. I use it on my personal slackbuild scripts (hosted
at https://github.com/lcavalheiro/slackbuilds - I plan to submit them to
http://slackbuilds.org as soon as submissions are allowed again), and all of
them build very well :-)
I'm testing the tree approaches (find +
On Mon, 14 Mar 2016 16:04:50 -0300
Luis Cavalheiro wrote:
> Indeed it should be
>
> -execdir chmod 755 {} \;
>
> ...at end of command line. I was fast typing and I did this little
> mistake. As said, command will stop in error in "-print0 | xargs -0"
> form if no
Indeed it should be
-execdir chmod 755 {} \;
...at end of command line. I was fast typing and I did this little mistake.
As said, command will stop in error in "-print0 | xargs -0" form if no
matching file is provided. Plus, since the sole function of this piped
xargs is chmod, it is an uneeded
On 14/03/2016 18:29, Erik Hanson wrote:
> Didier Spaier wrote:
>
>> Maybe it wouldn't hurt to write
>> -execdir 755
>
> Unless I'm misunderstanding the man page, this would need to be
> -execdir chmod 755 {} \;
Indeed, sorry for the mistake.
Didier
0x60C03EEA.asc
On Mon, 14 Mar 2016 17:50:39 +0100
Didier Spaier wrote:
> Maybe it wouldn't hurt to write
> -execdir 755
Unless I'm misunderstanding the man page, this would need to be
-execdir chmod 755 {} \;
It seems like there's possible value there, and it doesn't deviate too
far from
On 14/03/2016 13:39, Bryan Harris wrote:
> Why worry so much over something so insignificant? Just do whatever
> Volkerding does.
+1.
Let me add: only make a change if there is a proven advantage, like
_ old way failing (provide example), where the new one does not
_ new way *significantly*
Why worry so much over something so insignificant? Just do whatever
Volkerding does.
https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
On Mon, Mar 14, 2016 at 2:00 AM, Franzen wrote:
> On 2016-03-13 20:00, Andrzej Telszewski wrote:
>
>> On 13/03/16 19:46,
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
> wrote:
On 13/03/16 19:29, Luís Fernando Carvalho Cavalheiro wrote:
> Well, well...
On 13/03/16 19:46, Ryan P.C. McQuen wrote:
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
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
>
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
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
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
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
> >>
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'
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
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
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.
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
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:12T+0700, Willy Sudiarto Raharjo
>> 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
>> find -L . \
>> \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
>> -o -perm 440 -o -perm
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
> find -L . \
> \( -perm
>
> > On 24/02/16 07:37, Kyle Guinn wrote:
> > > On 2/23/16, Andrzej Telszewski wrote:
> > >> On 05/02/16 13:48, Martijn Dekker wrote:
> > >>> 2. The following horrible, broken and obsolete eyesore:
> > >>>
> > >>> find -L . \
> > >>>\( -perm 777 -o -perm 775 -o -perm
On 24/02/16 16:14, Erik Hanson wrote:
On Wed, 24 Feb 2016 08:22:43 +0100
Andrzej Telszewski wrote:
On 24/02/16 07:37, Kyle Guinn wrote:
On 2/23/16, Andrzej Telszewski wrote:
On 05/02/16 13:48, Martijn Dekker wrote:
2. The following horrible,
On Wed, 24 Feb 2016 08:22:43 +0100
Andrzej Telszewski wrote:
> On 24/02/16 07:37, Kyle Guinn wrote:
> > On 2/23/16, Andrzej Telszewski wrote:
> >> On 05/02/16 13:48, Martijn Dekker wrote:
> >>> 2. The following horrible, broken and obsolete
On 24/02/16 07:37, Kyle Guinn wrote:
On 2/23/16, Andrzej Telszewski wrote:
On 05/02/16 13:48, Martijn Dekker wrote:
2. The following horrible, broken and obsolete eyesore:
find -L . \
\( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
-o -perm
On 2/23/16, Andrzej Telszewski wrote:
> On 05/02/16 13:48, Martijn Dekker wrote:
>> 2. The following horrible, broken and obsolete eyesore:
>>
>> find -L . \
>> \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
>>-o -perm 511 \) -exec chmod 755 {} \;
On 23/02/16 12:51, Andrzej Telszewski wrote:
On 05/02/16 13:48, Martijn Dekker wrote:
2. The following horrible, broken and obsolete eyesore:
find -L . \
\( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
-o -perm 511 \) -exec chmod 755 {} \; -o \
\( -perm 666 -o -perm
it's a pity gnome-colors is gone. What's the reason?
-petar
2016-02-11 20:44 GMT+02:00 Willy Sudiarto Raharjo :
> > Please remove libeXosip2, libosip2, hsetroot and gnome-colors.
>
> Done
>
>
> --
> Willy Sudiarto Raharjo
>
>
>
Last time I used gnome-colors was in the times of GTK2, I have no idea
if it still works. I haven't built the packages for ages now. If you
want you can get the build script and resubmit it later for 14.2 :)
Eugene
Am Donnerstag, den 11.02.2016, 22:42 +0200 schrieb Petar Petrov:
> it's a pity
Please remove libeXosip2, libosip2, hsetroot and gnome-colors.
Eugene Wissner
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives -
> Please remove libeXosip2, libosip2, hsetroot and gnome-colors.
Done
--
Willy Sudiarto Raharjo
signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
Hello,
What is the status of TexLive? Will it be updated to 2015 or will it be
removed?
Anand
On Fri, Feb 5, 2016 at 5:57 AM, Willy Sudiarto Raharjo <
will...@slackbuilds.org> wrote:
> Hi folks,
>
>
> i have just merged all branches in SBo to master branch and it includes
> most of the bug and
>>gis/OTB
>>gis/horao
>
> Please remove these two from 14.2.
done, added to removal-review
>>gis/pointcloud
>
> This builds and runs fine for me.
Unfortunately not for us
gcc -o cu_tester cu_tester.o cu_pc_bytes.o cu_pc_schema.o cu_pc_point.o
cu_pc_patch.o cu_pc_patch_ght.o
>> This builds and runs fine for me.
>
> Unfortunately not for us
>
> gcc -o cu_tester cu_tester.o cu_pc_bytes.o cu_pc_schema.o cu_pc_point.o
> cu_pc_patch.o cu_pc_patch_ght.o ../libpc.a -lxml2 -lz -lm -ldl -lcunit
> -lz -lm
> make[2]: Leaving directory '/tmp/SBo/pointcloud-1.0.1/lib/cunit'
>
On Fri, 5 Feb 2016 07:27:42 +0700, Willy Sudiarto Raharjo
wrote:
> development/latrace
Please remove latrace.
Peter
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
>> development/latrace
>
> Please remove latrace.
Done
--
Willy Sudiarto Raharjo
signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
> Please remove openmodelica for now. I will upload the buildscript later
> after it builds properly on current.
Thanks
pushed to removed-review for now
--
Willy Sudiarto Raharjo
signature.asc
Description: OpenPGP digital signature
___
Hello,
Please remove openmodelica for now. I will upload the buildscript later
after it builds properly on current.
Anand
On Fri, Feb 5, 2016 at 5:57 AM, Willy Sudiarto Raharjo <
will...@slackbuilds.org> wrote:
> Hi folks,
>
>
> i have just merged all branches in SBo to master branch and it
>> graphics/rawtherapee
> The source is to old for gcc-5.3.
>
> As until now 4.2 is the last release i have self hosted a fresh
> snapshot from git and also i make a small modification to SlackBuild.
>
> It builds fine now in both arch!
Hi Panagiotis
i have made a simpler fix on my branch to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/05/2016 03:42 PM, Willy Sudiarto Raharjo wrote:
>>> graphics/rawtherapee >> The source is to old for gcc-5.3. >> >> As until
>>> now 4.2 is the last
release i have self hosted a fresh >> snapshot from git and also i make
a small modification
> i'll see what i can do for academic/tophat over the weekend. If i can't fix
> it, then we will have to remove it and possibly add it later if a new
> version that builds is released. Alternatively, i can take the ready
> binaries from the External Tools of Ugene (http://ugene.net/external.html)
Hi,
i checked if i am still maintainer of emacs-w3m. As it is i am
although there were already 2 candidates who wanted to take
it over. Please remove either the package or my name under it. ;)
Also whoever asked to maintain it, yes please claim it!
Greetings,
Felix
On 5 February 2016 at 10:14,
hi,
i'll see what i can do for academic/tophat over the weekend. If i can't fix
it, then we will have to remove it and possibly add it later if a new
version that builds is released. Alternatively, i can take the ready
binaries from the External Tools of Ugene (http://ugene.net/external.html)
and
>> network/seafile-server
>
> It's working again since my libevhtp commit yesterday.
Hi Marcel
the list was generated before your commits so probably some of them are
no longer valid since there were some commits by other maintainers as well.
David will try to build another list again this
Willy Sudiarto Raharjo schreef op 05-02-16 om 00:27:
> There are still a lot of build failures out there and we need your help
> to make sure our repository is ready for 14.2 when it has been released.
Is this a good moment to bring up a few more general issues?
I'm thinking of two things for
51 matches
Mail list logo