Re: [OM Cooker] i586 uclibc compile problems

2013/6/23 Matthew Dawkins <[email protected]>

>
>
>
> On Sat, Jun 22, 2013 at 6:35 PM, Per Øyvind Karlsen <
> [email protected]> wrote:
>
>> 2013/6/22 Matthew Dawkins <[email protected]>
>>
>>> does anyone know what is going on with uclibc builds on i586?
>>>
>> Busted compiler, for bero to fix...
>>
>
> \o/
>
>
>>
>> On a related note(/package), could you please not push out releases of
>> packages just because you've made cosmetic changes to them such as this:
>> https://abf.rosalinux.ru/openmandriva/uClibc/commits/master ?
>>
>
> Well.. I was trying to get a rebuild with a release bump to see if that
> actually fixed the uclibc problem.
>
>
>>
>> Also for the majority of your "cleanup" commits I've witnessed, they're
>> often just a matter of adjusting indenting of a few lines, or replacing
>> %patchX usage with %apply_patches, for which both of have too little to no
>> value for it to even be described as cleaning up, while possibly be at
>> conflict with personal preference and choices conciously made by others
>> previously.
>>
>
> And? I also catch a lot of legacy crap, convert tons of BRs to pkgconfig
> provides, clean up many poorly crafted pkgs? I guess my work on libreoffice
> is kinda crappy too huh?
>
And these things are more important than fixing actual bugs and maintaining
a focus on progress towards a release..?

>
> Can I ask things from you too? I have a long list for POK.
>
By all means, ask away..

>
>
>>
>> Please stop blindly replacing %apply_patches everywhere, my decissions
>> for when to use or not are usually quite consciously made at least, making
>> me rather annoyed when I keep finding such commits labelled as "cleanups"
>> with this as sole change made to so many packages where I'd prefer for it
>> to not having been done to begin with..
>>
>
> And? No, there is merit behind standardizing on %apply_patches. If you
> wanna leave notes in the spec about the patch, leave it up by the header.
> %apply_patches keeps lazy packing inline. It's easy to just comment out the
> line where the line is applied. I am going to say there are always special
> cases.
>
Well, one downside is that you cannot easily just temporarily disable
single patches or make them conditional..
I also often find myself doing things like adding an 'exit 1' after a
specific patch that I want to regenerate etc., when using %apply_patches
(which btw. is a distro specifc macro, not standardized upstream) you loose
the more fine grained control...

>
>
>>
>> And there certainly should be enough of far more urgent priorities to go
>> around for everyone and then some, what's the with the soft freeze you've
>> stressed so much about if this still remains as your primary focus?
>>
>
> You keep talking to me like I'm the head honcho, making decisions on what
> goes and what stay etc....
>
Well, you are the one who do restrict peoples' access and making the most
noise about others' work, callig attention to the soft freeze..


> AFAIK, I'm not the release manager, and my time is purely volunteer. I
> keep trying to say things of reason, ie the freeze. No one seems to listen
> there so...
>
And what's the point of this freeze period fo you, if you don't actually
use it productively focusing on more important issues?
You were so persistent and yelling about this freeze period, but yet you
expect for the actual work on stabilizing the distro during this period to
be conducted by everyone else than yourself?
If you're not going to do any relevant of the relevant work on stabilizing
the distro as intended by this soft freeze period, then why do you call
attention to it so much?

Idk, as long as we don't hard freeze. idk why you are barking at me?
>
Because you are the one who yells the highest and the most eager to
restrict the access of other people who actually focus on moving forward
and doing work of greater importance (which spec cleanining is simply not
by comparison)..

--
Regards,
Per Øyvind