Bug#1027065: Clarification

[Ludovic Brenta]

On bookworm (testing) I get:

$ gm2 --version
gm2 (Debian 12.2.0-10) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gm2 hello.mod
hello.mod:1:2: error: expecting one of: ‘IMPLEMENTATION’ ‘MODULE’ ‘DEFINITION’
1 | FROM StrIO IMPORT WriteString, WriteLn;
  |  ^~~~
hello.mod:1:2: error: compilation failed

Adding a first line, "MODULE hello;" makes the program legal but then I
get the same symptoms as in the original bug report.

Adding -fpim2 or -fpim3 to the compiler command line has no effect.

Adding -fiso silences the compiler even though StrIO is not an ISO
module.  Therefore a complete workaround is:

$ cat hello.mod
MODULE hello;
FROM StrIO IMPORT WriteString, WriteLn;
BEGIN
 WriteString('hello world');
 WriteLn
END hello.
$ gm2 -fiso hello.mod -o hello
$ ./hello
hello world

It seems that libm2pim.so lacks some necessary functions which
libm2iso.so has.

-- 
Ludovic Brenta.

Bug#1027284: mpfr_custom_get_kind broken in current 4.1.1

[Vincent Lefevre]

Control: tags -1 upstream fixed-upstream

On 2022-12-29 19:22:12 +0100, Yuri D'Elia wrote:
> According to https://github.com/CGAL/cgal/issues/7064 mpfr 4.1.1 was
> updated after-the-fact without a version bump.

I'm wondering what you mean by "version bump".

> mpfr 4.1.1 in debian has a broken macro definition of
> mpfr_custom_get_kind that prevents building against CGAL.
> 
> Looks like the package needs to be refreshed with the updated upstream's
> version or apply the patch[0] independently.
> 
> [0] 
> https://github.com/BrianGladman/mpfr/commit/0ce17bae34a6c54de31b126f969d3ddd72c6bc37

There's no newer version for the 4.1 branch. So I suggest one of
these 3 possibilities:

1. Apply the patch available on https://www.mpfr.org/mpfr-4.1.1/#bugs

2. Apply the patch from the git commit 0ce17bae34a6c54de31b126f969d3ddd72c6bc37

3. Upgrade to 4.2.0-rc1 (this version is ABI and API compatible and
has the fix for this bug). I will do the release in a few days, as
everything seems fine (there's only a possible failure on m68k with
QEMU, but after investigation, this is due to a QEMU bug, and the
generated code should be correct; BTW, the 4.1.* versions also have
the concerned test).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Processed: Re: Bug#1027284: mpfr_custom_get_kind broken in current 4.1.1

[Debian Bug Tracking System]

Processing control commands:

> tags -1 upstream fixed-upstream
Bug #1027284 [libmpfr-dev] mpfr_custom_get_kind broken in current 4.1.1
Added tag(s) upstream and fixed-upstream.

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

Bug#1027284: mpfr_custom_get_kind broken in current 4.1.1

[Yuri D'Elia]

Package: libmpfr-dev
Version: 4.1.1-1
Severity: important

According to https://github.com/CGAL/cgal/issues/7064 mpfr 4.1.1 was
updated after-the-fact without a version bump.

mpfr 4.1.1 in debian has a broken macro definition of
mpfr_custom_get_kind that prevents building against CGAL.

Looks like the package needs to be refreshed with the updated upstream's
version or apply the patch[0] independently.

[0] 
https://github.com/BrianGladman/mpfr/commit/0ce17bae34a6c54de31b126f969d3ddd72c6bc37

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmpfr-dev:amd64 depends on:
ii  libgmp-dev  2:6.2.1+dfsg1-1.1
ii  libmpfr64.1.1-1

libmpfr-dev:amd64 recommends no packages.

Versions of packages libmpfr-dev:amd64 suggests:
pn  libmpfr-doc  

Bug#1027278: gcc-12: change multiarch from loongarch64-linux-gnu to loongarch64-linux-gnuf64

[zhangdandan]

Package: gcc-12
Version: 12.2.0-11
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear gcc maintainers,

According to LoongArch manual: 
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html
LoongArch need to change multiarch from loongarch64-linux-gnu to 
loongarch64-linux-gnuf64.


Please consider applying the attached patch and we could continue to 
discuss.


Thanks
Dandan Zhang

diff --git a/debian/patches/gcc-multilib-multiarch.diff b/debian/patches/gcc-multilib-multiarch.diff
index 128d6008a..bd05f757b 100644
--- a/debian/patches/gcc-multilib-multiarch.diff
+++ b/debian/patches/gcc-multilib-multiarch.diff
@@ -119,7 +119,7 @@
  # Only define MULTIARCH_DIRNAME when multiarch is enabled,
  # or it would always introduce ${target} into the search path.
 -MULTIARCH_DIRNAME = $(LA_MULTIARCH_TRIPLET)
-+MULTIARCH_DIRNAME = $(call if_multiarch,loongarch64-linux-gnu)
++MULTIARCH_DIRNAME = $(call if_multiarch,loongarch64-linux-gnuf64)
  endif
  
  # Don't define MULTILIB_OSDIRNAMES if multilib is disabled.
@@ -128,7 +128,7 @@
  MULTILIB_OSDIRNAMES = \
 -  mabi.lp64d=../lib64$\
 -  $(call if_multiarch,:loongarch64-linux-gnuf64)
-+  mabi.lp64d=../lib$(call if_multiarch,:loongarch64-linux-gnu)
++  mabi.lp64d=../lib$(call if_multiarch,:loongarch64-linux-gnuf64)
  
  MULTILIB_OSDIRNAMES += \
 -  mabi.lp64f=../lib64/f32$\