Re: dpkg_1.18.10~bpo8+1_amd64.changes is NEW

[YunQiang Su]

On Sun, Oct 16, 2016 at 8:44 PM, Guillem Jover  wrote:
> Hi!
>
> On Sun, 2016-10-16 at 06:18:40 +, Debian FTP Masters wrote:
>> binary:dpkg is NEW.
>> binary:dpkg-dev is NEW.
>> binary:dselect is NEW.
>> binary:libdpkg-dev is NEW.
>> binary:libdpkg-perl is NEW.
>> source:dpkg is NEW.
>>
>> Your package has been put into the NEW queue, which requires manual action
>> from the ftpteam to process. The upload was otherwise valid (it had a good
>> OpenPGP signature and file hashes are valid), so please be patient.
>
>> If you have any questions, you may reply to this email.
>
> Unfortunately I'd like to request for this uncoordinated upload to be
> rejected. I think it might have been rejected anyway, as it has been
> the case in the past for potential dpkg backports, but still.
>
> YunQiang, this seems to be due to the MIPS ports, and the newish
> requirements from DAK to know all architectures present in packaging,
> or they get rejected. :( In any case, sorry I've not handled that
> before, the proper course of action here is to cherry-pick those
> changes into a stable update, which I'll be doing now.

Thank you very much for this help.

>
> Thanks,
> Guillem

Bug#807340: dpkg: please add MIPS R6 support

[YunQiang Su]

On Tue, Dec 22, 2015 at 9:10 AM, Guillem Jover <guil...@debian.org> wrote:
> Hi!
>
> On Tue, 2015-12-08 at 01:07:16 +0800, YunQiang Su wrote:
>> Package: src:dpkg
>> Version: 1.18.3
>
>> We are working on add basic support of MIPS R6 support to Debian.
>> Please add the support of R6 architectures to dpkg.
>>
>> About MIPS R6:
>> MIPS R6 is a new release of MIPS32 and MIPS64.
>> R6 is not fully compatible with R5-,
>> as it adds and *removes* some instructions, and add emulation
>> of the removed instructions in kernel,
>> so old binaries can still run on new R6 CPUs.
>>
>> While for the new CPUs, we still wish they can have their own architectures.
>
> I feel quite uneasy with these kind of architecture requests, when they
> seem to be mostly just new ISAs of pre-existing CPUs. More so when there's
> kernel emulation for missing instructions and such.
>
> Are the removed instructions widely used? Are they emitted as part of
> normal gcc output, or are they contained in very specific areas, that
> providing optimized versions of those packages using hwcap support
> would mean no degradation at all?

https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/documentation/MD00087-2B-MIPS64BIS-AFP-06.04.pdf

As this document says: even `add' and `ABS.fmt' areve removed.
You can search by words ` removed in Release 6'.

>
> I see that config.guess/config.sub already support this, I've had no
> time to check what's the status on the rest of the toolchain?

At least gcc/binutils/glibc/linux support these new architectures.
For other packages, we can add support for them by autoreconf.

>
> Also I guess this is extremely new, but before considering to add this
> stuff, I'd also like to know the stance of the pre-existing mips porters
> on these. Should we instead try to target a bump of the MIPS ISAs?

Bump current MIPS ISAs will not a good idea, as the current hardware
will not be workable at all.

Let's CC to debian-mips.

>
>> diff --git a/cputable b/cputable
>> index 676dcd7..f9f7f63 100644
>> --- a/cputable
>> +++ b/cputable
>> @@ -29,6 +29,10 @@ mips   mipsmips(eb)?  
>>  32  big
>>  mipsel   mipsel  mipsel  32  little
>>  mips64   mips64  mips64  64  big
>>  mips64el mips64elmips64el64  little
>> +mips32r6 mipsisa32r6 mipsisa32r6 `   32  big
>
> As Helmut pointed out on IRC, there's a spurious ` here.

Ohh, it is a typo.

>
>> diff --git a/triplettable b/triplettable
>> index 7257744..a5ec5f1 100644
>> --- a/triplettable
>> +++ b/triplettable
>> @@ -9,10 +9,14 @@ musleabihf-linux-armmusl-linux-armhf
>> +gnuabin32-linux-mips64r6 mipsn32r6
>> +gnuabin32-linux-mips64r6el   mipsn32r6el
>> +gnuabi64-linux-mips64r6  mips64r6
>> +gnuabi64-linux-mips64r6elmips64r6el
>
> Are you really going to try to get all these arches up? Otherwise I'd
> avoid the clutter.

We don't need so many architectures.
While they may be needed in future.
The most high priority one is mips64r6el and then mips32r6el.
If you still want to remove some, please keep these 2 at least.

I still wish you can keep all of them.

>
> Thanks,
> Guillem



-- 
YunQiang Su

Bug#707323: Please support mips64 and mips64el

[YunQiang Su]

Package: dpkg
Tag: patch

We are working on port Debian to mips64/mips64el/mipsn32/mipsn32el
This patch add the support of these architecture.

Please consider merge it.

--
YunQiang Su


mips64.diff
Description: Binary data

Bug#707323: Please support mips64 and mips64el

[YunQiang Su]

On Thu, May 9, 2013 at 11:50 AM, Guillem Jover guil...@debian.org wrote:
 Control: forcemerge 685096 -1

 On Thu, 2013-05-09 at 10:57:14 +0800, YunQiang Su wrote:
 Package: dpkg
 Tag: patch

 We are working on port Debian to mips64/mips64el/mipsn32/mipsn32el
 This patch add the support of these architecture.

 There was a bug already filed for this. The mips64el arch names make
 more sense than the mipsel64 proposed on the other bug report. The n32
 just follow logically. Although I don't see the GNU triplets in the
 upstream GNU config git repo (git://git.sv.gnu.org/config.git). Is there
 already a gcc patch for this too?
sorry， my typo

 I'll check the additions to the tables tomorrow, and if a port is in
 progress going somewhere, then I can add this for 1.17.0, most probably.
yes, the we have the patch for gcc-4.7 and gcc-4.8,
but I have not submit it as we have no multilib support for now.
When multilib is ready, I will sumbit it.

 Thanks,
 Guillem



--
YunQiang Su


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org