Bug#893188: 答复: Bug#893188: mapnik: add mips* back to arch list

[Sebastiaan Couwenberg]

Hi 李超,

On 03/22/2018 04:31 AM, 李超 wrote:
>   About "mapnik" package for mips*, there really has actual users of
> mapnik in Loongson's customers
> list, most user is in the government, and the specific users is inconvenient
> to inform, hope you understanding.

If it's the geospatial intelligence agency they should employ people to
maintain mapnik for their infrastructure.

Secret users don't motivate me to do work on mapnik for mips*, sorry. I
hope for your understanding in return.

Kind Regards,

Bas

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[Bas Couwenberg]

On 2018-03-20 11:53, James Cowgill wrote:

On 18/03/18 09:37, YunQiang Su wrote:

On Sun, Mar 18, 2018 at 5:05 PM, Sebastiaan Couwenberg
 wrote:

On 03/18/2018 09:23 AM, YunQiang Su wrote:

On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg wrote:

Why do you want mapnik back on mips*?

I don't expect any actual users of the mapnik family of packages on
mips*, so despite improvements to the architecture in Debian I 
don't

think it's worth the effort.


How much extra effort is required here?


Updating the Architecture list in debian/control, having to fix 
architecture specific issues when the builds fail on mips*, requesting 
removal of the package and its rdeps from mips* when architecture 
specific issues cannot be fixed.


The first is not a lot of work, the others are.


At least Loongson may need it, as Loongson is working on providing
high-end PC/Server in China, and some department of government and
some companies will need it.
At least please provide mips64el and mips64r6el, both of them are
targeting for high-end machines.


If they "may" need it, I strongly prefer those users who will 
actually

use mapnik on mips* to request it. So far it's still hypothetical.


In deed, a Loongson guy told me that their customers are using mapnik.
He didn't tell me the customers of course.

@Anibal, @Douglas,
   I guess we should also ask for any our customers are using it.

@Sebastiaan, I know it is a quite hard work to maintain so many 
packages,
and before the response from MIPS is some slow, I am very sorry of 
that.

Anyway, we can have a quicker response in future.


I'm inclined to close this as wontfix until actual users of mapnik
request it on mips64el.


Debian policy lists the two valid reasons for restricting the
architecture list (5.6.8):
- A package is not portable to that arch.
- A package would not be useful on that arch.


I consider a package which doesn't have any users on that arch not 
useful.


I argue that none of these reasons apply here and therefore the 
packages

should be Architecture: any (or possibly linux-any, but I haven't
checked non-linux arches). This would also assist ia64 which I notice 
is

not in the architecture list. Also note that none of these reasons
require actual users. Do you think there are users of mapnik on every
architecture you currently have in the architecture list? Can you
provide the requests from users of these architectures to enable 
mapnik?


Please don't motivate me to mark all GIS and OSM packages as for amd64 + 
i386 only, which I'm tempted to do whenever I get confronted by 
architecture specific issues.


Those are the only architectures actually used, and in the case of 
mapnik it's most likely not used on i386 either. But i386 is a special 
architecture in britney for which package removals don't unblock testing 
migration.



If you are concerned about mips (or any architecture) blocking testing
migration then the two correct options are:
- Asking the porters for help.
- Requesting removal of your package on that architecture.

Sometimes the porters have a lot of other work to do or are 
unavailable.

Sorry if this has happened to you.

The advantage of requesting removal over restricting the arch list is
that the package automatically becomes available again if it gets fixed
(eg by upstream) and the package is continually built and tested each
upload so people can see what is broken. Not restricting the
architecture list avoids porters having to poke maintainers when a new
architecture is bootstrapped.


Porters should spend their time on more important packages than mapnik, 
binutils for example (#765710).


Having to deal with issues on mips* is not worth the effort for me. 
Asking the porters for help doesn't seem like a viable option if they 
don't even get around to helping with important toolchain packages. No 
need to put more work on busy people.


Not having mips* in the Architecture list for mapnik saves the effort 
having to ask for removal.


I see no benefit in adding mips* back to the architecture list, it just 
makes my life more miserable having to deal with issues on those 
architectures again.


If there are actual users of mapnik on mips* the added misery may be 
worth the effort in the interest of our users.


Kind Regards,

Bas

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[James Cowgill]

Hi,

On 18/03/18 09:37, YunQiang Su wrote:
> On Sun, Mar 18, 2018 at 5:05 PM, Sebastiaan Couwenberg
>  wrote:
>> On 03/18/2018 09:23 AM, YunQiang Su wrote:
>>> On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg wrote:
 Why do you want mapnik back on mips*?

 I don't expect any actual users of the mapnik family of packages on
 mips*, so despite improvements to the architecture in Debian I don't
 think it's worth the effort.

How much extra effort is required here?

>>> At least Loongson may need it, as Loongson is working on providing
>>> high-end PC/Server in China, and some department of government and
>>> some companies will need it.
>>> At least please provide mips64el and mips64r6el, both of them are
>>> targeting for high-end machines.
>>
>> If they "may" need it, I strongly prefer those users who will actually
>> use mapnik on mips* to request it. So far it's still hypothetical.
> 
> In deed, a Loongson guy told me that their customers are using mapnik.
> He didn't tell me the customers of course.
> 
> @Anibal, @Douglas,
>I guess we should also ask for any our customers are using it.
> 
> @Sebastiaan, I know it is a quite hard work to maintain so many packages,
> and before the response from MIPS is some slow, I am very sorry of that.
> Anyway, we can have a quicker response in future.
> 
>> I'm inclined to close this as wontfix until actual users of mapnik
>> request it on mips64el.

Debian policy lists the two valid reasons for restricting the
architecture list (5.6.8):
- A package is not portable to that arch.
- A package would not be useful on that arch.

I argue that none of these reasons apply here and therefore the packages
should be Architecture: any (or possibly linux-any, but I haven't
checked non-linux arches). This would also assist ia64 which I notice is
not in the architecture list. Also note that none of these reasons
require actual users. Do you think there are users of mapnik on every
architecture you currently have in the architecture list? Can you
provide the requests from users of these architectures to enable mapnik?

If you are concerned about mips (or any architecture) blocking testing
migration then the two correct options are:
- Asking the porters for help.
- Requesting removal of your package on that architecture.

Sometimes the porters have a lot of other work to do or are unavailable.
Sorry if this has happened to you.

The advantage of requesting removal over restricting the arch list is
that the package automatically becomes available again if it gets fixed
(eg by upstream) and the package is continually built and tested each
upload so people can see what is broken. Not restricting the
architecture list avoids porters having to poke maintainers when a new
architecture is bootstrapped.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[YunQiang Su]

On Sun, Mar 18, 2018 at 5:05 PM, Sebastiaan Couwenberg
 wrote:
> On 03/18/2018 09:23 AM, YunQiang Su wrote:
>> On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg wrote:
>>> Why do you want mapnik back on mips*?
>>>
>>> I don't expect any actual users of the mapnik family of packages on
>>> mips*, so despite improvements to the architecture in Debian I don't
>>> think it's worth the effort.
>>
>> At least Loongson may need it, as Loongson is working on providing
>> high-end PC/Server in China, and some department of government and
>> some companies will need it.
>> At least please provide mips64el and mips64r6el, both of them are
>> targeting for high-end machines.
>
> If they "may" need it, I strongly prefer those users who will actually
> use mapnik on mips* to request it. So far it's still hypothetical.
>

In deed, a Loongson guy told me that their customers are using mapnik.
He didn't tell me the customers of course.

@Anibal, @Douglas,
   I guess we should also ask for any our customers are using it.

@Sebastiaan, I know it is a quite hard work to maintain so many packages,
and before the response from MIPS is some slow, I am very sorry of that.
Anyway, we can have a quicker response in future.

> I'm inclined to close this as wontfix until actual users of mapnik
> request it on mips64el.
>
> Kind Regards,
>
> Bas



-- 
YunQiang Su

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[Sebastiaan Couwenberg]

On 03/18/2018 09:23 AM, YunQiang Su wrote:
> On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg wrote:
>> Why do you want mapnik back on mips*?
>>
>> I don't expect any actual users of the mapnik family of packages on
>> mips*, so despite improvements to the architecture in Debian I don't
>> think it's worth the effort.
> 
> At least Loongson may need it, as Loongson is working on providing
> high-end PC/Server in China, and some department of government and
> some companies will need it.
> At least please provide mips64el and mips64r6el, both of them are
> targeting for high-end machines.

If they "may" need it, I strongly prefer those users who will actually
use mapnik on mips* to request it. So far it's still hypothetical.

I'm inclined to close this as wontfix until actual users of mapnik
request it on mips64el.

Kind Regards,

Bas

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[YunQiang Su]

On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg
 wrote:
> Control: tags -1 moreinfo
>
> Hi YunQiang,
>
> Thanks for your work improving the mips* architectures in Debian.
>
> On 03/17/2018 09:38 AM, YunQiang Su wrote:
>> With some test on mips64el/mipsel machines, mapnik builds well,
>> without memory exhibition problems.
>>
>> I think it should be fixed now,  with
>>   1) We update some hardware of mips*, dropped some old Loongson 2E machines.
>>   2) Set -param ggc-min-expand default now on mips/mipsel.
>>
>> It should be OK to add these architectures back.
>>
>> The full mips* arch list:
>>mips mipsel mipsn32 mipsn32el mips64 mips64el
>>mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el
>>
>> If you feel OK, I suggest we can use any now,
>>
>> At least please add
>>mips mipsel mips64el mips64r6el
>
> Why do you want mapnik back on mips*?
>
> I don't expect any actual users of the mapnik family of packages on
> mips*, so despite improvements to the architecture in Debian I don't
> think it's worth the effort.

At least Loongson may need it, as Loongson is working on providing
high-end PC/Server in China, and some department of government and
some companies will need it.
At least please provide mips64el and mips64r6el, both of them are
targeting for high-end machines.

>
> Kind Regards,
>
> Bas



-- 
YunQiang Su

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

Hi YunQiang,

Thanks for your work improving the mips* architectures in Debian.

On 03/17/2018 09:38 AM, YunQiang Su wrote:
> With some test on mips64el/mipsel machines, mapnik builds well,
> without memory exhibition problems.
> 
> I think it should be fixed now,  with
>   1) We update some hardware of mips*, dropped some old Loongson 2E machines.
>   2) Set -param ggc-min-expand default now on mips/mipsel.
> 
> It should be OK to add these architectures back.
> 
> The full mips* arch list:
>mips mipsel mipsn32 mipsn32el mips64 mips64el
>mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el
> 
> If you feel OK, I suggest we can use any now,
> 
> At least please add
>mips mipsel mips64el mips64r6el

Why do you want mapnik back on mips*?

I don't expect any actual users of the mapnik family of packages on
mips*, so despite improvements to the architecture in Debian I don't
think it's worth the effort.

Kind Regards,

Bas

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Processed: Re: Bug#893188: mapnik: add mips* back to arch list

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #893188 [src:mapnik] mapnik: add mips* back to arch list
Added tag(s) moreinfo.

-- 
893188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893188
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#893188: mapnik: add mips* back to arch list

[YunQiang Su]

Package: src:mapnik
Version: 3.0.19+ds-1

With some test on mips64el/mipsel machines, mapnik builds well,
without memory exhibition problems.

I think it should be fixed now,  with
  1) We update some hardware of mips*, dropped some old Loongson 2E machines.
  2) Set -param ggc-min-expand default now on mips/mipsel.

It should be OK to add these architectures back.

The full mips* arch list:
   mips mipsel mipsn32 mipsn32el mips64 mips64el
   mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el

If you feel OK, I suggest we can use any now,

At least please add
   mips mipsel mips64el mips64r6el

-- 
YunQiang Su

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel