On Sunday 05 Jan 2014 23:03:23 Mark Lee wrote:
> This all boils down to what does Arch consider a bug. If code that
> cannot be compiled in parallel is a bug then Arch should make parallel
> building the default (since these are bugs that upstream should fix). If
> instead it is not a bug but is th
On Sun, 2014-01-05 at 15:42 -0600, David C. Rankin wrote:
> On 12/31/2013 12:51 AM, Sébastien Leblanc wrote:
> > I would advise against doing that, considering that there are at least a
> > handful of packages (can't name them) that have broken or otherwise
> > malfunctioning Makefiles when run in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2014 09:26 AM, Thomas Bächler wrote:
> Error and inexperience can occur while learning. If you upload to the
> AUR, I expect you to have polished and finished material, not your first
> draft.
>
> There's enough places with kind people who wi
On 12/31/2013 12:51 AM, Sébastien Leblanc wrote:
> I would advise against doing that, considering that there are at least a
> handful of packages (can't name them) that have broken or otherwise
> malfunctioning Makefiles when run in parallel.
There are more than a few. If you get a PKGBUILD from
Isaac Dupree wrote:
> Probably most code doesn't consume 256 MB RAM per GCC invocation. C++'s
> templates and lack of module system...
Correct...also in special for C and other compilers.
Important is to create more parallel instances then the number of available
cores in order to have threa
On 01/03/2014 04:03 PM, Mark Lee wrote:
On Fri, 2014-01-03 at 15:55 -0500, Isaac Dupree wrote:
On 01/03/2014 10:37 AM, Anatol Pomozov wrote:
Using -j$(cpunum) is a sane default that saves a lot of time to users.
I agree, but for the record, 'nice' and scheduling are no panacea in my
experienc
On Fri, Jan 3, 2014 at 10:23 PM, Isaac Dupree
wrote:
> On 01/03/2014 04:10 PM, Karol Blazewicz wrote:
>>
>> On Fri, Jan 3, 2014 at 9:55 PM, Isaac Dupree
>> wrote:
>>>
>>> On 01/03/2014 10:37 AM, Anatol Pomozov wrote:
Using -j$(cpunum) is a sane default that saves a lot of time to u
On 01/03/2014 04:10 PM, Karol Blazewicz wrote:
On Fri, Jan 3, 2014 at 9:55 PM, Isaac Dupree
wrote:
On 01/03/2014 10:37 AM, Anatol Pomozov wrote:
Using -j$(cpunum) is a sane default that saves a lot of time to users.
I agree, but for the record, 'nice' and scheduling are no panacea in my
ex
On Fri, Jan 3, 2014 at 9:55 PM, Isaac Dupree
wrote:
> On 01/03/2014 10:37 AM, Anatol Pomozov wrote:
>>
>> Using -j$(cpunum) is a sane default that saves a lot of time to users.
>
>
> I agree, but for the record, 'nice' and scheduling are no panacea in my
> experience. It's fine for CPU loads, but
On 01/03/2014 10:37 AM, Anatol Pomozov wrote:
Using -j$(cpunum) is a sane default that saves a lot of time to users.
I agree, but for the record, 'nice' and scheduling are no panacea in my
experience. It's fine for CPU loads, but compilations are also
disk-heavy (which mattered when I used a
On Fri, Jan 03, 2014 at 07:06:31PM +0100, Timoth?e Ravier wrote:
> On 03/01/2014 17:46, Martin S. Weber wrote:
> (...)
> > (...)
> > Read e.g. this message from the author of SQLite and fossil about packager's
> > need/want for splitting dynamic libs from projects using said dynamic libs
> > (sqlit
On 03/01/2014 17:46, Martin S. Weber wrote:
> Sermons from packager from pkg systems A, B, C, D (...)
> sooner or later provoke ignorance from upstream dev (...).
No sermons should ever be made to upstream by packagers. Upstream should
not be blamed for bugs, but helped with. This is free software
On Fri, Jan 03, 2014 at 04:44:05PM +0100, Timoth?e Ravier wrote:
> On 03/01/2014 16:24, Martin S. Weber wrote:
> > (...)
>
> As far as I know, MAKE_JOBS_SAFE and 'options="!makeflags"' are
> packaging "tricks" to work around an upstream bug.
I agree with that assessment.
> Enabling parallel buil
On Jan 3, 2014 11:23 AM, "Leonid Isaev" wrote:
>
> Why is the default "-j" such a big deal?
>
It really isn't a big deal. While I think we should leave it unset so the
user can set it their self, most of the packages in the AUR that have an
issue with - j > 1 already have a work around in place.
On Fri, 3 Jan 2014 08:03:33 -0800
Anatol Pomozov wrote:
> Hi
>
> On Fri, Jan 3, 2014 at 6:55 AM, Paul Gideon Dann wrote:
> > On Friday 03 Jan 2014 15:33:05 Martti Kühne wrote:
> >> Because I have a strong opinion about this. Also to prevent people
> >> from running into this who are not that ex
Hi
On Fri, Jan 3, 2014 at 6:55 AM, Paul Gideon Dann wrote:
> On Friday 03 Jan 2014 15:33:05 Martti Kühne wrote:
>> Because I have a strong opinion about this. Also to prevent people
>> from running into this who are not that experienced in making things
>> work.
>
> If someone makes more than a f
On Friday 03 Jan 2014 16:26:27 Thomas Bächler wrote:
> Error and inexperience can occur while learning. If you upload to the
> AUR, I expect you to have polished and finished material, not your first
> draft.
>
> There's enough places with kind people who will look at your PKGBUILD
> and point out
On Fri, 03 Jan 2014 15:49:27 +0100
Thomas Bächler wrote:
>
> If it were my choice, we would enforce high quality standards for the
> AUR (which would likely force us to delete 90% of PKGBUILDs from it).
>
Speaking of which: https://bbs.archlinux.org/viewtopic.php?id=175171
Hi
> 'nice' works just fine, and I haven't seen machines slow down due to
> compiling even without it - the Linux scheduler handles many
> simultaneous workloads just fine.
Thats right. Linux kernel developers spent a lot of time to optimize
scheduler both for long batch jobs (like compilation) a
On 03/01/2014 16:24, Martin S. Weber wrote:
> because for each new occurrence, it will have to be determined manually:
> concurrency brings non-determinism with it. Many of these pkgs built
> just fine (tm) for developers a, b and d (not only on, but also on multi-core
> and/or SMP machines) while
On Sat, Jan 04, 2014 at 01:07:47AM +1000, Allan McRae wrote:
> On 04/01/14 01:03, Martin S. Weber wrote:
> > On Fri, Jan 03, 2014 at 03:23:24PM +0100, Thomas B?chler wrote:
> >> Am 03.01.2014 15:21, schrieb Martti K?hne:
> >>> You can't expect every upstream to fix their autohell to conform to
> >>
Am 03.01.2014 16:11, schrieb Paul Gideon Dann:
>> If it were my choice, we would enforce high quality standards for the
>> AUR (which would likely force us to delete 90% of PKGBUILDs from it).
>
> Sounds like a barrel of laughs!
When I look at the AUR sometimes, I don't laugh - I cry. The current
On Friday 03 Jan 2014 15:49:27 Thomas Bächler wrote:
> If you are not "experienced", you should think about your operating
> system choice. We are not a kindergarten, we are a distribution with a
> target audience of experienced and advanced users.x
I reckon plenty of Arch users weren't used to cu
On 04/01/14 01:03, Martin S. Weber wrote:
> On Fri, Jan 03, 2014 at 03:23:24PM +0100, Thomas B?chler wrote:
>> Am 03.01.2014 15:21, schrieb Martti K?hne:
>>> You can't expect every upstream to fix their autohell to conform to
>>> our expectations here.
>>
>> So, we keep repeating ourselves.
>>
>> T
On Fri, Jan 03, 2014 at 03:23:24PM +0100, Thomas B?chler wrote:
> Am 03.01.2014 15:21, schrieb Martti K?hne:
> > You can't expect every upstream to fix their autohell to conform to
> > our expectations here.
>
> So, we keep repeating ourselves.
>
> There is the !makeflags option for PKGBUILDs to
On Friday 03 Jan 2014 15:33:05 Martti Kühne wrote:
> Because I have a strong opinion about this. Also to prevent people
> from running into this who are not that experienced in making things
> work.
If someone makes more than a few packages, they will have encountered
makepkg.conf, to
at least s
Am 03.01.2014 15:33, schrieb Martti Kühne:
> On Fri, Jan 3, 2014 at 3:23 PM, Thomas Bächler wrote:
>> Am 03.01.2014 15:21, schrieb Martti Kühne:
>>> You can't expect every upstream to fix their autohell to conform to
>>> our expectations here.
>>
>> So, we keep repeating ourselves.
>>
>
> Because
On Fri, Jan 3, 2014 at 3:23 PM, Thomas Bächler wrote:
> Am 03.01.2014 15:21, schrieb Martti Kühne:
>> You can't expect every upstream to fix their autohell to conform to
>> our expectations here.
>
> So, we keep repeating ourselves.
>
Because I have a strong opinion about this. Also to prevent pe
Am 03.01.2014 15:21, schrieb Martti Kühne:
> You can't expect every upstream to fix their autohell to conform to
> our expectations here.
So, we keep repeating ourselves.
There is the !makeflags option for PKGBUILDs to work around this problem
(which you would know if you read the thread). If a p
On Fri, Jan 3, 2014 at 3:16 PM, Thomas Bächler wrote:
> Am 03.01.2014 15:03, schrieb Øyvind Heggstad:
>>> You are suggesting not changing to a sane default because some
>>> packages (especially in the AUR) have crappy maintainers. That's
>>> hardly a reason for anything.
>>>
>>>
>>
>> Your defenit
Am 03.01.2014 15:03, schrieb Øyvind Heggstad:
>> You are suggesting not changing to a sane default because some
>> packages (especially in the AUR) have crappy maintainers. That's
>> hardly a reason for anything.
>>
>>
>
> Your defenition of sane default might not match someone elses.
>
> Many pe
On Tue, 31 Dec 2013 19:39:03 +0100
Thomas Bächler wrote:
> Am 31.12.2013 07:51, schrieb Sébastien Leblanc:
> > I would advise against doing that, considering that there are at
> > least a handful of packages (can't name them) that have broken or
> > otherwise malfunctioning Makefiles when run in
On Tue, 31 Dec 2013 19:39:03 +0100
Thomas Bächler wrote:
> Really? Who?
Hmm, me. Intel atom here...
> You are suggesting not changing to a sane default because some packages
> (especially in the AUR) have crappy maintainers. That's hardly a reason
> for anything.
A sane default would probably
Am 31.12.2013 07:51, schrieb Sébastien Leblanc:
> I would advise against doing that, considering that there are at least a
> handful of packages (can't name them) that have broken or otherwise
> malfunctioning Makefiles when run in parallel. The package maintainers
> _should_ be aware of those issu
I would advise against doing that, considering that there are at least a
handful of packages (can't name them) that have broken or otherwise
malfunctioning Makefiles when run in parallel. The package maintainers
_should_ be aware of those issues, and would accordingly add
'options="!makeflags"' to
Salutations,
I was wondering if we could change the default value for j in MakeFlags
in makepkg.conf to "-j$(nproc)". This would allow makepkg to scale the
number of threads per pc as default.
Regards,
Mark
--
Mark Lee
signature.asc
Description: This is a digitally signed message part
36 matches
Mail list logo
