from:"Jason Duerstock"

Re: Important packages that are broken ia64

2023-08-09 Thread Jason Duerstock

Hi Pedro,

Did you finish the git bisect?  What was the commit that broke it?

Thanks,

Jason

On Wed, Aug 9, 2023 at 9:41 PM Pedro Miguel Justo  wrote:
>
> >
> > Well, you need to install efibootmgr. Not sure why it isn't installed on 
> > your
> > machine in the first place since it's needed for grub-install to update the
> > boot manager settings in firmware and create the "grub" entry.
> >
> > Just install it with:
> >
> > # apt install efibootmgr
> >
> > Adrian
> >
>
> Thanks Adrian. It is a mystery why it was previously installed. After that I 
> was able to go through 3 or 4 bisections with successful boots. Then, 
> finally, I hit the problem. The trouble is that it seems to have also 
> affected my “debian” entry, so no safe boot:
>
> Loading.: debian
> Starting: debian
> Welcome to GRUB!
>
> 7 0 0x6B 0x001E unexpected trap
> 7 0 0x66 0x001E trap taken, number in ext PE
> 7 0 0x3C 0x5A00 trap taken, offset in ext PE

Re: IA-64 GCC deprecation?

2019-06-14 Thread Jason Duerstock

Regarding LRA, I saw this coming and started working on it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90785
Judging from the similar SH4 PR, I understand this isn't a trivial thing to
fix.
Is there any reason I couldn't become the ia64 maintainer, assuming there
was someone available to act as my general gcc mentor?

Jason

On Thu, Jun 13, 2019 at 5:24 PM Jim Wilson  wrote:

> On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz
>  wrote:
> > I know that argument and I have heard it before but whenever I asked
> > for a particular example which code in question of a backend would
> > block something else, I never received an answer.
>
> It is hard to produce good examples on demand, as some of these things
> tend to be temporary problems, and someone just gets impatient enough
> that they just make a blind fix to the targets that can't be properly
> tested.
>
> A possible example here is LRA.  This is a new local register
> allocation pass that is intended to replace the very old reload pass.
> For now, some ports are continuing to use reload.  Some ports are
> using LRA.  Generally, the well maintained ports are using LRA because
> it has a number of advantages, and the poorly maintained ports are
> still using reload.  We would like to eventually obsolete the reload
> code, but we can't do that until every port switches over.  Meanwhile,
> we have to maintain two very different register allocation passes that
> do the same thing, which is twice as much work as only having one of
> them.  So we'd really like to see all ports switch over to LRA.  IA-64
> is one of the ports that hasn't switched yet.  Most of the unfixed
> ports are embedded targets, and eventually someone will get impatient
> enough to fix them even though they don't care about the target, using
> a simulator to test it.  But IA-64 is a server part, not an embedded
> part, so in theory requires more testing.  Also, there is no free
> simulator for IA-64 that I know of which makes the testing harder.
> However, there are over 20 targets that don't have LRA support yet, so
> the IA-64 port is not a blocking factor here yet.  There are people
> slowly converting random embedded ports over though, so eventually
> IA-64 will be a blocking factor if it doesn't get fixed.
>
> Jim
>
>

Bug#930119: gcc-8: __dso_handle place in wrong segment on ia64

2019-06-07 Thread Jason Duerstock

Package: gcc-8
Version: 8.3.0-7
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

On ia64, __dso_handle is placed in .data/.bss rather than .sdata/.sbss,
causing a link failure on at least one package (libphonenumber).  The
patch has been added to trunk here:

https://gcc.gnu.org/viewcvs/gcc?view=revision=271977

A PR has also been opened but for some reason does not reflect the trunk
change.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90714

Thank you.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 5.0.0-trunk-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-8 depends on:
ii  binutils  2.31.1-16
ii  cpp-8 8.3.0-7
ii  gcc-8-base8.3.0-7
ii  libc6.1   2.28-2
ii  libcc1-0  9-20190428-1
ii  libgcc-8-dev  8.3.0-7
ii  libgcc1   1:9-20190428-1
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++69-20190428-1
ii  libunwind81.2.1-9
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages gcc-8 recommends:
ii  libc6.1-dev  2.28-2

Versions of packages gcc-8 suggests:
pn  gcc-8-doc 
pn  gcc-8-locales 
pn  libasan5-dbg  
pn  libatomic1-dbg
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan1-dbg 

-- no debconf information

Bug#930082: gmt: FTBFS on ia64

2019-06-06 Thread Jason Duerstock

Source: gmt
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

gmt fails to build from source on ia64.  A patch has been submitted
upstream:

https://github.com/GenericMappingTools/gmt/pull/849

Please include it in your next release.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 5.0.0-trunk-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/src/common_sighandler.c b/src/common_sighandler.c
index f1825595d..42ca21c98 100644
--- a/src/common_sighandler.c
+++ b/src/common_sighandler.c
@@ -106,6 +106,8 @@ void backtrace_symbols_fd(void *const *buffer, int size, 
int fd) {
 #  define UC_IP(uc) ((void *) (uc)->uc_mcontext.arm_pc)
 # elif defined(__powerpc__) || defined(__powerpc64__)
 #  define UC_IP(uc) ((void *) (uc)->uc_mcontext.regs->nip)
+# elif defined(__ia64__)
+#  define UC_IP(uc) ((void *) (uc)->uc_mcontext.sc_ip)
 # else
 #  define UC_IP(uc) ((void *) (uc)->uc_mcontext.eip)
 # endif

Re: FFmpeg bootstrap

2019-06-03 Thread Jason Duerstock

Hello again Carl,

Sorry it took so long to get back to you.  I took another stab at
bootstrapping ffmpeg, and it seems like the bulk of the test errors revolve
around src/libavcodec/ituh263enc.c.  Specifically:

$ gdb ./ffmpeg --core=core.1559574121
GNU gdb (Debian 8.2.50.20190222-1) 8.2.50.20190222-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "ia64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./ffmpeg...
[New LWP 6314]
[New LWP 6317]
[New LWP 6318]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/ia64-linux-gnu/libthread_db.so.1".
Failed to read a valid object file image from memory.
Core was generated by `/home/jason/ffmpeg-4.1.3/debian/standard/ffmpeg
-nostdin -nostats -y -cpuflags'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  init_mv_penalty_and_fcode (s=0x2008000f3880) at
src/libavcodec/ituh263enc.c:776
776 s->me.mv_penalty= mv_penalty; // FIXME exact table for MSMPEG4
& H.263+
[Current thread is 1 (Thread 0x2dbc6c20 (LWP 6314))]
(gdb) bt
#0  0x20baeb10 in init_mv_penalty_and_fcode (s=0x2008000f3880)
at src/libavcodec/ituh263enc.c:776
#1  0x20baeb10 in ff_h263_encode_init (s=0x2008000f3880) at
src/libavcodec/ituh263enc.c:774
#2  0x20bdbda0 in ff_mpv_encode_init (avctx=0x2008000f3450) at
src/libavcodec/mpegvideo_enc.c:983
#3  0x21848e90 in avcodec_open2 (avctx=0x2008000f3450,
codec=, options=0x2008000c8450)
at src/libavcodec/utils.c:930
#4  0x200800052940 in init_output_stream (ost=0x2008000c82f0,
error=0x6f88c510 "", error_len=1024)
at src/fftools/ffmpeg.c:3525
#5  0x200800056890 in reap_filters (flush=0) at
src/fftools/ffmpeg.c:1446
#6  0x200800060b20 in transcode_step () at src/fftools/ffmpeg.c:4651
#7  0x200800060b20 in transcode () at src/fftools/ffmpeg.c:4695
#8  0x2008ff20 in main (argc=60, argv=0x6f88d618) at
src/fftools/ffmpeg.c:4914
(gdb) print s->me
$1 = {avctx = 0x0, skip = 0, co_located_mv = {{0, 0}, {0, 0}, {0, 0}, {0,
0}}, direct_basis_mv = {{0, 0}, {0, 0}, {0, 0}, {0, 0}},
  scratchpad = 0x0, best_mb = 0x0, temp_mb = {0x0, 0x0}, temp = 0x0,
best_bits = 0, map = 0x2008000a4560,
  score_map = 0x2008000a3e00, map_generation = 0, pre_penalty_factor =
0, penalty_factor = 0, sub_penalty_factor = 0,
  mb_penalty_factor = 0, flags = 0, sub_flags = 0, mb_flags = 0, pre_pass =
0, dia_size = 0, xmin = 0, xmax = 0, ymin = 0,
  ymax = 0, pred_x = 0, pred_y = 0, src = {{0x0, 0x0, 0x0, 0x0}, {0x0, 0x0,
0x0, 0x0}, {0x0, 0x0, 0x0, 0x0}, {0x0, 0x0, 0x0,
  0x0}}, ref = {{0x0, 0x0, 0x0, 0x0}, {0x0, 0x0, 0x0, 0x0}, {0x0, 0x0,
0x0, 0x0}, {0x0, 0x0, 0x0, 0x0}}, stride = 0,
  uvstride = 0, mc_mb_var_sum_temp = 0, mb_var_sum_temp = 0,
scene_change_score = 0, hpel_put = 0x0, hpel_avg = 0x0,
  qpel_put = 0x0, qpel_avg = 0x0, mv_penalty = 0x22232bf9
, current_mv_penalty = 0x0,
  sub_motion_search = 0x0}
(gdb) print mv_penalty
$2 = {'\a' , '\a' , '\a' , '\a' ,
  '\a' , '\a' , '\a' , '\a' }
(gdb) print _penalty
$3 = (uint8_t (*)[8][4097]) 0x2206d2e1 
(gdb) print s->me.mv_penalty
$4 = (uint8_t (*)[4097]) 0x22232bf9 

Until we can get you porterbox access, is there any additional debugging
information I can provide?

Jason


On Sat, Mar 17, 2018 at 8:01 AM Carl Eugen Hoyos  wrote:

> 2018-03-16 23:07 GMT+01:00, Jason Duerstock :
> > Hi Carl,
> >
> > There are some Java dependencies that will get in the way of the
> > dependency chain, but with any luck, Java will get fixed in the next
> > couple of weeks.
>
> Good to know, I had forgotten this dependency.
>
> > In the meantime, I built stage1 manually.
>
> Thank you!
>
> > I attached the log.
>
> Unfortunately, it shows many crashes, don't know
> if this will ever work;-(
>
> If you can provide me with a login to one of the build
> systems, I could have another look.
> (Some other maintainers like hppa offered this in
> the past.)
>
> Thank you, Carl Eugen
>

Bug#929326: subversion: please add pkg.subversion.nokde build profile

2019-05-21 Thread Jason Duerstock

Source: subversion
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

Subversion currently depends on KDE in order to build, which creates an
excessive build dependency chain.  Please accept the following patch
which adds a pkg.subversion.nokde build profile that removes the KDE
dependency requirement.

-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.19.0-5-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/control  2019-05-21 14:32:14.938904862 -0400
+++ debian/control  2019-05-21 14:32:25.070975575 -0400
@@ -17,9 +17,9 @@
libdb5.3-dev,
libdbus-1-dev,
liblz4-dev (>= 0.0~r129),
-   libkf5coreaddons-dev,
-   libkf5i18n-dev,
-   libkf5wallet-dev,
+   libkf5coreaddons-dev ,
+   libkf5i18n-dev ,
+   libkf5wallet-dev ,
libperl-dev,
libsasl2-dev,
libsecret-1-dev,
--- debian/rules2019-05-21 14:32:09.770868795 -0400
+++ debian/rules2019-05-21 14:32:20.826945955 -0400
@@ -89,7 +89,6 @@
--with-editor=/usr/bin/editor \
--with-ruby-sitedir=/usr/lib/ruby \
--with-swig=/usr/bin/swig \
-   --with-kwallet=/usr/include:$(libdir) \
--with-lz4 \
--with-utf8proc \
CFLAGS="$(CFLAGS)" \
@@ -102,6 +101,10 @@
   confflags+= --enable-debug
 endif
 
+ifeq ($(filter pkg.subversion.nokde,$(DEB_BUILD_PROFILES)),)
+  confflags+= --with-kwallet=/usr/include:$(libdir)
+endif
+
 export DH_OPTIONS
 ifdef DEB_OPT_WITH_JAVAHL
   # jikes 1.22 cannot compile javahl.

Re: gzip (i386) uses TEXTRELs

2018-09-27 Thread Jason Duerstock

As I believe this would fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688958, I say go
ahead.

Jason
On Thu, Sep 27, 2018 at 6:37 AM Andreas Henriksson  wrote:
>
> Hello,
>
> I've just built gzip in a i386 chroot with the previously supplied
> debdiff applied and checked with scanelf (from pax-utils) that the
> textrel goes away.
>
> # scanelf -t noasm/bin/* /bin/gzip
> TYPE   TEXTREL FILE
>  ET_DYN-noasm/bin/gzip
>  ET_DYN TEXTREL /bin/gzip
>
> Andreas Pommer: It would be great if you could verify that
> gzip built with the patch you find at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=890279;filename=gzip-no-asm.debdiff;msg=21
> (ie. attached to #890279 ) makes it possible for you to reenable the
> protection in the logrotate service file that Christian had to drop
> for you. (Either by downgrading to previous logrotate version or
> just systemctl edit and put the service changes back in again.)
>
> m68k and ia64 porters: Please note that gzip seems to have asm code for
> your architectures as well which gets disabled by the proposed patch.
> Please speak up now if you think the asm for your architecture is better
> and should be preferred over the C code.
> Previous discussion quoted below to give you some background. See
> #890279 for entire discussion.
>
> Given the lack of feedback on this issue, I assume NMU will be the next
> step here unless I get any feedback soon after this message.
>
> Regards,
> Andreas Henriksson
>
>
> On Wed, Aug 29, 2018 at 12:11:20PM +0200, Andreas Henriksson wrote:
> > Hi,
> >
> > There are some useful info in the discussion at:
> > https://launchpad.net/ubuntu/+source/gzip/+bug/49067
> >
> > Apparently fedora (et.al.) has nowadays abandoned their patch in favour
> > of using 'export DEFS="NO_ASM"' in the spec file, see
> > https://src.fedoraproject.org/rpms/gzip/tree/master
> >
> > Their changelog also comes with this interesting claim:
> > "- don't use the asm code again as it's slower than the gcc compiled one"
> >
> > Googling "gzip DEFS NO_ASM" gives a number of matches including
> > openembedded, coreos, etc.
> > It seems it's pretty common to disable the (i386) assembler code
> > and given the benefits it seems to have, I think it would be
> > useful for debian to also do that.
> >
> > For potential convenience I'm attaching an untested debdiff which I
> > hope someone can help test and verify on i386.
> >
> > Regards,
> > Andreas Henriksson
> >
> > PS. Please also note fedora seems to be carrying a patch for glibc 2.28
> > which might be useful in debian soon as well.
> > https://src.fedoraproject.org/rpms/gzip/blob/master/f/gnulib.patch
>
> > diff -Nru gzip-1.9/debian/changelog gzip-1.9/debian/changelog
> > --- gzip-1.9/debian/changelog 2018-08-05 02:30:09.0 +0200
> > +++ gzip-1.9/debian/changelog 2018-08-29 11:40:01.0 +0200
> > @@ -1,3 +1,11 @@
> > +gzip (1.9-2.1) UNRELEASED; urgency=medium
> > +
> > +  * Non-maintainer upload.
> > +  * Disable usage of assembler code (Closes: #890279)
> > +- fedora claims gcc generates more optimized code anyway.
> > +
> > + -- Andreas Henriksson   Wed, 29 Aug 2018 11:40:01 +0200
> > +
> >  gzip (1.9-2) unstable; urgency=medium
> >
> >* move to upstream's less-ugly fix for mingw compilation failure
> > diff -Nru gzip-1.9/debian/rules gzip-1.9/debian/rules
> > --- gzip-1.9/debian/rules 2018-08-05 02:30:09.0 +0200
> > +++ gzip-1.9/debian/rules 2018-08-29 11:40:01.0 +0200
> > @@ -24,6 +24,7 @@
> >  endif
> >  endif
> >
> > +export DEFS=NO_ASM # Avoid TEXTRELs on i386
> >  EXTRA_CFLAGS=-Wall
> >  EXTRA_CPPFLAGS=
> >
>

Bug#908519: linux: asciidoctor dependency blocks ia64 build

2018-09-10 Thread Jason Duerstock

Source: linux
Severity: normal
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

Due to some ruby issues, asciidoctor is currently blocking the linux
package from building on ia64.  Since asciidoctor is only used to build
the linux-perf documentation, does it make more sense to:
1) move asciidoctor into the Build-Depends-Indep: section in the control
file, or
2) flag asciidoctor as [!ia64]?

I think #1 is the correct answer, but it's entirely possible my
understanding of build dependencies is incomplete.

Thanks,

Jason


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.18.0-1-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#906822: gdb: gdb FTBFS on ia64

2018-08-21 Thread Jason Duerstock

Package: gdb
Version: 7.12-6+ia64.1
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

gdb 8.1 FTBFS on ia64 because an internal API change was not fully
propagated across all callers.  This is fixed in upstream git commit
5d691c8829d0e5c4c4b9cfb147c8a873ce18085b, which is included here for
your convenience.

Jason


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.17.0-3-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdb depends on:
ii  libc6.1   2.27-5
ii  libexpat1 2.2.6-1
ii  liblzma5  5.2.2-1.3+b1
ii  libncurses5   6.1+20180714-1
ii  libpython3.6  3.6.6-2
ii  libreadline7  7.0-5
ii  libtinfo5 6.1+20180714-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages gdb recommends:
ii  libc6.1-dbg [libc-dbg]  2.27-5

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information
diff --git a/gdb/ia64-tdep.c b/gdb/ia64-tdep.c
index 0df62e26ab..2fab60c1d0 100644
--- a/gdb/ia64-tdep.c
+++ b/gdb/ia64-tdep.c
@@ -69,6 +69,7 @@ struct ia64_table_entry
   };
 
 static struct ia64_table_entry *ktab = NULL;
+static gdb::optional ktab_buf;
 
 #endif
 
@@ -2647,11 +2648,9 @@ ia64_access_mem (unw_addr_space_t as,
 }
 
 /* Call low-level function to access the kernel unwind table.  */
-static LONGEST
-getunwind_table (gdb_byte **buf_p)
+static gdb::optional
+getunwind_table ()
 {
-  LONGEST x;
-
   /* FIXME drow/2005-09-10: This code used to call
  ia64_linux_xfer_unwind_table directly to fetch the unwind table
  for the currently running ia64-linux kernel.  That data should
@@ -2660,10 +2659,8 @@ getunwind_table (gdb_byte **buf_p)
  we should find a way to override the corefile layer's
  xfer_partial method.  */
 
-  x = target_read_alloc (current_top_target (), TARGET_OBJECT_UNWIND_TABLE,
-NULL, buf_p);
-
-  return x;
+  return target_read_alloc (current_top_target (), TARGET_OBJECT_UNWIND_TABLE,
+   NULL);
 }
 
 /* Get the kernel unwind table.  */ 
@@ -2674,15 +2671,12 @@ get_kernel_table (unw_word_t ip, unw_dyn_info_t *di)
 
   if (!ktab) 
 {
-  gdb_byte *ktab_buf;
-  LONGEST size;
-
-  size = getunwind_table (_buf);
-  if (size <= 0)
+  ktab_buf = getunwind_table ();
+  if (!ktab_buf)
return -UNW_ENOINFO;
 
-  ktab = (struct ia64_table_entry *) ktab_buf;
-  ktab_size = size;
+  ktab = (struct ia64_table_entry *) ktab_buf->data ();
+  ktab_size = ktab_buf->size ();
 
   for (etab = ktab; etab->start_offset; ++etab)
 etab->info_offset += KERNEL_START;

Bug#906675: gcc-8: remove obsolete ia64 gcc bug workaround

2018-08-19 Thread Jason Duerstock

Package: gcc-8
Version: 8.1.0-9
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

The debian/rules2 file has an obsolete compiler bug workaround that can
now be removed.  The attached patch removes it.  Please include it in
the next release.

Thank you.


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.17.0-3-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-8 depends on:
ii  binutils  2.31.1-4
ii  cpp-8 8.1.0-9
ii  gcc-8-base8.1.0-9
ii  libc6.1   2.27-5
ii  libcc1-0  8.1.0-9
ii  libgcc-8-dev  8.1.0-9
ii  libgcc1   1:8.1.0-9
ii  libgmp10  2:6.1.2+dfsg-3
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.1-1
ii  libstdc++68.1.0-9
ii  libunwind81.2.1-8
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages gcc-8 recommends:
ii  libc6.1-dev  2.27-5

Versions of packages gcc-8 suggests:
pn  gcc-8-doc 
pn  gcc-8-locales 
pn  libasan5-dbg  
pn  libatomic1-dbg
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan1-dbg 

-- no debconf information
--- debian/rules2.orig  2018-08-19 09:56:05.076926333 -0400
+++ debian/rules2   2018-08-19 09:56:16.232982161 -0400
@@ -120,11 +120,6 @@
   endif
 endif
 
-# work around PR 57689
-ifeq ($(DEB_TARGET_ARCH),ia64)
-  BOOT_CFLAGS  = -g -O1
-endif
-
 ifeq ($(with_ssp_default),yes)
   STAGE1_CFLAGS= -g
   ifeq (,$(BOOT_CFLAGS))

Bug#906531: qtdeclarative-opensource-src: libqt5qml5.symbols and libqt5quick5.symbols need update for ia64

2018-08-17 Thread Jason Duerstock

Source: qtdeclarative-opensource-src
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

The source currently fails to build because of some symbol
inconsistencies.  The attached patch should fix them.


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.17.0-3-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- qtdeclarative-opensource-src-5.11.1/debian/libqt5quick5.symbols 
2018-07-26 21:08:31.0 -0400
+++ qtdeclarative-opensource-src-5.11.1.new/debian/libqt5quick5.symbols 
2018-08-17 16:30:51.207202160 -0400
@@ -3296,7 +3296,7 @@
  
_ZN36QQuickDesignerSupportPropertyChanges15detachFromStateEP7QObject@Qt_5_PRIVATE_API
 5.6.0~beta 1
  
_ZN36QQuickDesignerSupportPropertyChanges16changeExpressionEP7QObjectRK10QByteArrayRK7QString@Qt_5_PRIVATE_API
 5.6.0~beta 1
  
_ZN36QQuickDesignerSupportPropertyChanges16isNormalPropertyERK10QByteArray@Qt_5_PRIVATE_API
 5.6.0~beta 1
- (optional=templinst|arch=alpha mips64el riscv64 
sparc64)_ZN3QV45Value2asINS_6ObjectEEEPT_v@Qt_5 5.9.1
+ (optional=templinst)_ZN3QV45Value2asINS_6ObjectEEEPT_v@Qt_5 5.9.1
  _ZN40QSGDistanceFieldShiftedStyleTextMaterialC1Ev@Qt_5_PRIVATE_API 5.0.2 1
  _ZN40QSGDistanceFieldShiftedStyleTextMaterialC2Ev@Qt_5_PRIVATE_API 5.0.2 1
  _ZN40QSGDistanceFieldShiftedStyleTextMaterialD0Ev@Qt_5_PRIVATE_API 5.0.2 1
--- qtdeclarative-opensource-src-5.11.1/debian/libqt5qml5.symbols   
2018-07-26 21:08:17.0 -0400
+++ qtdeclarative-opensource-src-5.11.1.new/debian/libqt5qml5.symbols   
2018-08-17 20:29:36.086200229 -0400
@@ -2631,7 +2631,7 @@
  _ZNK3QV45Value16toQStringNoThrowEv@Qt_5_PRIVATE_API 5.2.0~beta1 1
  _ZNK3QV45Value8toUInt16Ev@Qt_5_PRIVATE_API 5.2.0~beta1 1
  _ZNK3QV45Value9sameValueES0_@Qt_5_PRIVATE_API 5.2.0~beta1 1
- (arch=!amd64 !arm64 !mips64el !ppc64el 
!sparc64)_ZNK3QV45Value9toIntegerEv@Qt_5_PRIVATE_API 5.11.1 1
+ (arch=!amd64 !arm64 !ia64 !mips64el !ppc64el 
!sparc64)_ZNK3QV45Value9toIntegerEv@Qt_5_PRIVATE_API 5.11.1 1
  _ZNK3QV45Value9toQStringEv@Qt_5_PRIVATE_API 5.2.0~beta1 1
  
_ZNK3QV46Object11getPropertyEjPNS_8PropertyEPNS_18PropertyAttributesE@Qt_5_PRIVATE_API
 5.6.0~beta 1
  _ZNK3QV46Object11hasPropertyEPNS_6StringE@Qt_5_PRIVATE_API 5.4.0 1

Re: Debian installer

2018-08-16 Thread Jason Duerstock

Hi Pedro,

I'm using 3.14-2 (from wheezy).

http://ftp.us.debian.org/debian/pool/main/e/elilo/elilo_3.14-2_ia64.deb

Jason


On Thu, Aug 16, 2018 at 11:38 AM Pedro Miguel Teixeira 
wrote:

>
> Hi Jason.
>
> Can you please share which ELILO you are using? This is the one I have on
> my Montvale machine:
>
> ELILO v3.12 for EFI/IA-64
>
> But I afraid it might be too old for current kernels.
>
> BTW, this is what I currently have on mine:
>
>Linux b777 3.2.0-4-mckinley #1 SMP Debian 3.2.78-1 ia64 GNU/Linux
>
> _
> Pedro
>
> ____
> From: Jason Duerstock 
> Sent: Wednesday, August 15, 2018 11:43:24 AM
> To: frank.schei...@web.de
> Cc: John Paul Adrian Glaubitz; debian-ia64
> Subject: Re: Debian installer
>
>
> https://salsa.debian.org/kernel-team/linux/commit/8b3963b0ebe7f3fee96bc541363bfe0a95f8999a
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905461
>
> I'm currently using elilo, but grub is rumored to work.  Now that the
> kernel works again, I will try to test grub myself at some point soon.
>
> Jason
>
>
> On Wed, Aug 15, 2018 at 2:33 PM Frank Scheiner  frank.schei...@web.de> wrote:
> On 08/15/2018 02:07 AM, Jason Duerstock wrote:
> > FYI, as of today's build, the kernel works again:
> >
> > ii  linux-image-4.17.0-2-mckinley   4.17.14-1
> >   ia64 Linux 4.17 for Itanium 2+
> >
> > $ uname -a
> > Linux netsvcs1 4.17.0-2-mckinley #1 SMP Debian 4.17.14-1 (2018-08-13)
> > ia64 GNU/Linux
> >
> > Jason
>
> Cool, will give it a try soon.
>
> Any idea what was changed to make it work? Kernel config maybe?
>
> And say, what machine and what boot loader and boot method (e.g.
> netboot, boot from disk, etc.) did you use?
>
> Cheers,
> Frank
>

Re: Debian installer

2018-08-15 Thread Jason Duerstock

https://salsa.debian.org/kernel-team/linux/commit/8b3963b0ebe7f3fee96bc541363bfe0a95f8999a

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905461

I'm currently using elilo, but grub is rumored to work.  Now that the
kernel works again, I will try to test grub myself at some point soon.

Jason


On Wed, Aug 15, 2018 at 2:33 PM Frank Scheiner 
wrote:

> On 08/15/2018 02:07 AM, Jason Duerstock wrote:
> > FYI, as of today's build, the kernel works again:
> >
> > ii  linux-image-4.17.0-2-mckinley   4.17.14-1
> >   ia64 Linux 4.17 for Itanium 2+
> >
> > $ uname -a
> > Linux netsvcs1 4.17.0-2-mckinley #1 SMP Debian 4.17.14-1 (2018-08-13)
> > ia64 GNU/Linux
> >
> > Jason
>
> Cool, will give it a try soon.
>
> Any idea what was changed to make it work? Kernel config maybe?
>
> And say, what machine and what boot loader and boot method (e.g.
> netboot, boot from disk, etc.) did you use?
>
> Cheers,
> Frank
>

Re: Debian installer

2018-08-14 Thread Jason Duerstock

FYI, as of today's build, the kernel works again:

ii  linux-image-4.17.0-2-mckinley   4.17.14-1
 ia64 Linux 4.17 for Itanium 2+

$ uname -a
Linux netsvcs1 4.17.0-2-mckinley #1 SMP Debian 4.17.14-1 (2018-08-13) ia64
GNU/Linux

Jason

On Sun, Jul 29, 2018 at 2:46 PM Frank Scheiner 
wrote:

> On 07/28/2018 06:34 PM, John Paul Adrian Glaubitz wrote:
> > We might want to tackle the installer on ia64 next, but that should
> > probably go onto the ia64 mailing list. The FTBFS of d-i on most
> > ports architectures should have been fixed with this [1] commit.
> > [...]
> >> [1]
> https://salsa.debian.org/installer-team/debian-installer/commit/b4ec9f8a40c0f1a3a077d32debf751bc1c1b3b9f
>
> I'd definitely be interested. But due to the heat at the moment I don't
> (want to) run my Itanium gear (or any other of my bigger/hotter
> machines) that much.
>
> A few remaining issues should be solved before putting our hands on d-i:
>
> ## Bootloader ##
>
> elilo is no longer built for ia64 since Jessie and I'm not sure if GRUB
> is already working well on ia64. I made good experience with elilo from
> Wheezy, it works with everything I tested (Wheezy/Wheezy backports and
> Gentoo kernels) so far, e.g. it was able to load a manually created ~120
> MiB (!) initramfs via netboot for a Gentoo installation in mid 2017. I
> haven't yet tested the current Gentoo version of elilo ([2]) which is
> more recent.
>
> [2]: https://packages.gentoo.org/packages/sys-boot/elilo
>
> ## Linux kernel ##
>
> So far we don't have a working Debian Linux kernel for ia64. All tested
> 4.x Debian Linux kernels show the same issue:
>
> ```
> [ 0.052000] Kernel panic - not syncing: corrupted stack end detected
> inside scheduler
> ```
>
> ...as mentioned in [3] throughout rx2620, rx4640, rx2660 and rx2800 i2.
> I tested up to 4.18.0-rc3 without luck.
>
> [3]: https://lists.debian.org/debian-ia64/2018/06/msg0.html
>
> I therefore used the current stable Gentoo kernel sources (v4.14.52,
> [4]) to build a working Linux kernel for ia64.
>
> [4]: https://packages.gentoo.org/packages/sys-kernel/gentoo-sources
>
> May I ask what Linux kernel version you are running on the buildds (lenz
> and titanium as per [5]) and what type of machines these are?
>
> [5]: https://monitor.jrtc27.com/
>
> Cheers,
> Frank
>
>

Bug#905536: python3.7: disable -O3 on ia64 due to compiler bug

2018-08-05 Thread Jason Duerstock

Source: python3.7
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

The attached patch includes a number of fixes to python3.7's
debian/rules:
1) Due to a gcc bug[1], -O3 needs to be disabled on ia64.
2) The -O2 override for m68k added for Debian bug #326903 is
no longer needed, and was removed
3) The -mieee and -O2 overrides for DEC Alpha added for Debian
bug #212912 are no longer needed, and were removed

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 4.17.0-1-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/rules.orig   2018-08-05 13:09:54.027342191 -0400
+++ debian/rules2018-08-05 13:12:50.900361875 -0400
@@ -160,14 +160,9 @@
 OPT_CFLAGS   := $(filter-out -O%,$(DPKG_CFLAGS)) # default is -O3
 DEBUG_CFLAGS := $(patsubst -O%,-Og,$(DPKG_CFLAGS))
 
-# on alpha, use -O2 only, use -mieee
-ifeq ($(DEB_HOST_ARCH),alpha)
-OPT_CFLAGS += -mieee
-DEBUG_CFLAGS += -mieee
-EXTRA_OPT_FLAGS += -O2
-endif
-ifeq ($(DEB_HOST_ARCH),m68k)
-EXTRA_OPT_FLAGS += -O2
+# on ia64, disable -O3 until gcc bug #85412 is fixed
+ifeq ($(DEB_HOST_ARCH),ia64)
+EXTRA_OPT_CFLAGS += -O2
 endif
 ifneq (,$(filter $(DEB_HOST_ARCH), ppc64 ppc64el))
 OPT_CFLAGS += -fexceptions

Bug#897178: mozjs52: more fixes for ia64

2018-04-29 Thread Jason Duerstock

Source: mozjs52
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

Attached please find patches to let mozjs52 build on ia64, and (mostly) pass 
the test suite.
ia64 currently requires -G0 for linking, but crashes if the current 
*MAINT_APPEND strings are
used.  Also, the memory allocation fails because the address space randomizer 
does not
take into account ia64 memory allocation.


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- debian/test.sh.orig 2018-04-29 08:55:47.958055376 -0400
+++ debian/test.sh  2018-04-29 08:59:29.181143034 -0400
@@ -28,6 +28,9 @@
(s390x|ppc64)
echo "Ignoring test failure, 
https://bugs.debian.org/878286;
;;
+   (ia64)
+   echo "Ignoring test failure, 
https://bugs.debian.org/897117;
+   ;;
(*)
echo "Test failure is considered serious, causing FTBFS"
exit 1
--- debian/rules.orig   2018-04-29 09:00:41.632848488 -0400
+++ debian/rules2018-04-29 09:02:53.504307305 -0400
@@ -17,8 +17,15 @@
 SRCDIR = $(CURDIR)/js/src
 CONFIGURE_FLAGS =
 
-DEB_CFLAGS_MAINT_APPEND += -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks
-DEB_CXXFLAGS_MAINT_APPEND += -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks
+# ia64 currently has toolchain issues, so relax the link optimization
+# -fno-schedule-insns2 breaks gcc on ia64, so leave it enabled
+ifneq (,$(findstring $(DEB_BUILD_ARCH),ia64))
+   DEB_CFLAGS_MAINT_APPEND += -G0
+   DEB_CXXFLAGS_MAINT_APPEND += -G0
+else
+   DEB_CFLAGS_MAINT_APPEND += -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks
+   DEB_CXXFLAGS_MAINT_APPEND += -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks
+endif
 ifneq (,$(findstring $(DEB_BUILD_ARCH),armel armhf))
 DEB_CFLAGS_MAINT_APPEND += -fno-schedule-insns
 DEB_CXXFLAGS_MAINT_APPEND += -fno-schedule-insns
--- mozjs52-52.3.1/js/src/jit/ProcessExecutableMemory.cpp   2017-08-08 
06:25:50.0 -0400
+++ mozjs52.fixed/js/src/jit/ProcessExecutableMemory.cpp2018-04-27 
09:30:47.390494330 -0400
@@ -290,8 +290,13 @@
 void* randomAddr = ComputeRandomAllocationAddress();
 void* p = MozTaggedAnonymousMmap(randomAddr, bytes, PROT_NONE, MAP_PRIVATE 
| MAP_ANON,
  -1, 0, "js-executable-memory");
-if (p == MAP_FAILED)
-return nullptr;
+if (p == MAP_FAILED) {
+// the comment above appears to be incorrect, so retry without the hint
+p = MozTaggedAnonymousMmap(NULL, bytes, PROT_NONE, MAP_PRIVATE | 
MAP_ANON,
+ -1, 0, "js-executable-memory");
+if (p == MAP_FAILED) 
+return nullptr;
+}
 return p;
 }

Bug#897117: mozjs52: tests fail on ia64: memory and math

2018-04-28 Thread Jason Duerstock

Source: mozjs52
Severity: normal
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

The following tests fail on ia64:

## ecma_6/Math/log2-approx.js: rc = 3, run time = 0.109967
ecma_6/Math/shell.js:7:19 Error: got -Infinity, expected a number near -1074
Stack:
  fail@ecma_6/Math/shell.js:7:19
  assertNear@ecma_6/Math/shell.js:61:17
  @ecma_6/Math/log2-approx.js:2:5
TEST-UNEXPECTED-FAIL | ecma_6/Math/log2-approx.js | (args: "")

## ecma_6/Math/fround.js: rc = 3, run time = 0.111898
ecma_6/Math/fround.js:65:1 Error: Assertion failed: got 0, expected 5e-324
Stack:
  @ecma_6/Math/fround.js:65:1
TEST-UNEXPECTED-FAIL | ecma_6/Math/fround.js | (args: "")

## js1_5/Regress/regress-422348.js: rc = 0, run time = 0.101824
BUGNUMBER: 422348
STATUS: Proper overflow error reporting
 FAILED! [reported from test()] Proper overflow error reporting : Expected 
value 'InternalError: allocation size overflow', Actual v
alue 'out of memory'
TEST-UNEXPECTED-FAIL | js1_5/Regress/regress-422348.js | (args: "")

## js1_5/Array/regress-157652.js: rc = 0, run time = 0.110511
BUGNUMBER: 157652
STATUS: Testing that Array.sort() doesn't crash on very large arrays
--- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 0 ---
--- NOTE: IN THIS TESTCASE, WE EXPECT EXIT CODE 5 ---
 FAILED! [reported from top level script] Testing that Array.sort() doesn't 
crash on very large arrays : Expected value 'InternalErr
or: allocation size overflow', Actual value 'out of memory'
TEST-UNEXPECTED-FAIL | js1_5/Array/regress-157652.js | (args: "")

The rest of the test suite passes or fails as expected.


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#731983: runtime warnings: in:imuxsock: unaligned access to 0x0000000043765a09

2018-04-05 Thread Jason Duerstock

Package: rsyslog
Version: 8.33.1-1
Followup-For: Bug #731983
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

This bug has been fixed upstream in this commit:
https://github.com/rsyslog/rsyslog/commit/64b6f5f7b924aa62a800c2e02e68cb498ed50acc

Please add this patch to the package until 8.34 is released.

Thanks!

Jason

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.51
ii  libc6.1  2.27-2
ii  libestr0 0.1.10-2.1
ii  libfastjson4 0.99.8-2
ii  liblogging-stdlog0   1.0.6-3
ii  liblognorm5  2.0.3-1
ii  libsystemd0  238-4
ii  libuuid1 2.31.1-0.5
ii  lsb-base 9.20170808
ii  zlib1g   1:1.2.8.dfsg-5+b1

Versions of packages rsyslog recommends:
ii  logrotate  3.11.0-0.1

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- no debconf information

Bug#892200: qdbm: FTBFS on arches without openjdk

2018-03-06 Thread Jason Duerstock

Source: qdbm
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

As currently configured, gcc-7 does not know where to find the Java jni.h 
headers if the arch is
using gcj rather than openjdk. [1]  The attached patch should clean up the Java 
detection and set
the relevant environment variables correctly.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=qdbm=ia64=1.8.78-6.2=1518046955=0


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- qdbm-1.8.78/debian/rules2018-02-06 10:12:44.0 -0500
+++ qdbm-1.8.78-new/debian/rules2018-03-06 11:19:25.125571799 -0500
@@ -43,13 +43,12 @@
--includedir=\$${prefix}/include/qdbm \
--enable-pthread --enable-zlib --enable-iconv
 
-DEFAULT_JAVA ?= $(shell readlink /etc/alternatives/java | sed 
s@/jre/bin/java@@)
-ifneq (,$(findstring /usr/bin/gij,$(DEFAULT_JAVA)))
+JAVA_HOME = /usr/lib/jvm/default-java
+CONFIGURE_VARS += JAVA_HOME="$(JAVA_HOME)"
+DEFAULT_JAVA ?= $(shell readlink -f $(JAVA_HOME)/bin/java)
+ifneq (,$(filter /usr/bin/%gij%, $(DEFAULT_JAVA)))
 CONFIGURE_VARS += JAVAC="gcj-wrapper" JAR="fastjar"
 CONFIGURE_SWITCHES += --with-gcj
-else
-JAVA_HOME = $(DEFAULT_JAVA)
-CONFIGURE_VARS += JAVA_HOME="$(JAVA_HOME)"
 endif
 
 build: build-arch build-indep

Bug#890432: suricata: FTBFS on ia64

2018-02-14 Thread Jason Duerstock

Source: suricata
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

>From 
>https://buildd.debian.org/status/fetch.php?pkg=suricata=ia64=1%3A4.0.4-1=1518609275=0

gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  
-I/usr/lib/ia64-linux-gnu/htp/include -I/usr/include/nspr -I/usr/include/nspr 
-I/usr/include/nss -I/usr/include/nspr -I/usr/include/nss -I/usr/include  
-Wextra -Werror-implicit-function-declaration  -fstack-protector 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -I/usr/include 
-DLOCAL_STATE_DIR=\"/var\" -std=gnu99 -Wall -Wno-unused-parameter 
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wwrite-strings 
-Wbad-function-cast -Wformat-security -Wno-format-nonliteral 
-Wmissing-format-attribute -funsigned-char  -g -O2 
-fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs 
-Wformat -Werror=format-security -c -o conf-yaml-loader.o conf-yaml-loader.c
cc1: warning: -fstack-protector not supported for this target
In file included from /usr/include/ia64-linux-gnu/bits/siginfo-consts.h:184:0,
 from /usr/include/signal.h:58,
 from suricata-common.h:152,
 from conf-yaml-loader.c:27:
/usr/include/ia64-linux-gnu/bits/siginfo-consts-arch.h:39:17: error: 
'TRAP_TRACE' undeclared here (not in a function); did you mean '_SC_TRACE'?
   TRAP_BRANCH = TRAP_TRACE + 1,
 ^~
 _SC_TRACE
Makefile:1687: recipe for target 'conf-yaml-loader.o' failed
make[4]: *** [conf-yaml-loader.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory '/<>/src'
Makefile:1131: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/<>/src'
Makefile:494: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/<>'
Makefile:422: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j2 returned exit code 2
debian/rules:57: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Patch attached.

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- src/suricata-common.h.orig  2018-02-14 12:27:29.727546789 -0500
+++ src/suricata-common.h   2018-02-14 12:27:43.135478812 -0500
@@ -34,7 +34,6 @@
 #define FALSE  0
 
 #define _GNU_SOURCE
-#define __USE_GNU
 
 #if HAVE_CONFIG_H
 #include

Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

2018-02-14 Thread Jason Duerstock

Hi Pedro,

Can you try booting this ISO and let us know what happens?
http://distfiles.gentoo.org/releases/ia64/autobuilds/20180201T031003Z/install-ia64-minimal-20180201T031003Z.iso

Thanks,

Jason




On Wed, Feb 14, 2018 at 2:52 AM, Pedro Miguel Teixeira <pm...@texair.net> wrote:
>
>
> Hi Emeric.
>
>
>
> The machine has no iLO card, so it can’t be because of it. As far as I can
> tell, either ELILO never gets to pass control to the kernel, or the kernel
> never gets to output the 1st message.
>
>
>
> _
> Pedro
>
>
>
> From: Émeric MASCHINO
> Sent: Tuesday, February 13, 2018 23:43
> To: Pedro Miguel Teixeira
> Cc: Jason Duerstock; Gatis Visnevskis; Ivan Zakharyaschev; debian-ia64;
> gle...@altlinux.org
>
>
> Subject: Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2,
> mckinley, rx2620)
>
>
>
> Well, problem is then likely with iLO card or serial console.
> Indeed, I'm daily using a zx6000 workstation for years, being with
> Debian for more than a decade, now with Gentoo since Debian has killed
> the plug on ia64 in 2013.
> I have no problem booting/using it locally (GNOME 3.24 desktop
> environment) with kernels 4.9.76 and 4.12.12. Kernels were compiled
> either with GCC 4.5.4 (because of a nasty error with GDB that
> sometimes segfaults when kernels i compiled with GCC > 4.5) or 6.2.0.
>
> 2018-02-14 1:41 GMT+01:00 Pedro Miguel Teixeira <pm...@texair.net>:
>>
>>
>> Hi Jason.
>>
>>
>>
>> That was close – I was really about to send the zx6000 onto the tech
>> recycle.
>>
>>
>>
>> The following is all I get coming out from the console (Serial A, since
>> the
>> zx6000 does not have a management card / iLO). After the initrd line
>> shows,
>> a good 5 seconds pass. Then the front panel becomes all red and the
>> cryptic
>> modem-style sounds come out. I’ve wondered about the health of both my
>> ELILO
>> and Kernel, but my rx2660 boots fine with the exact the same two.
>>
>>
>>
>>
>>
>> EFI Boot Manager ver 1.10 [14.61]  Firmware ver 2.31 [4411]
>>
>>
>>
>> Loading device drivers
>>
>>
>>
>> Loading.: Auxiliary Floating Point Driver
>>
>> Load of Auxiliary Floating Point Driver failed: Not Found
>>
>> EFI Boot Manager ver 1.10 [14.61]  Firmware ver 2.31 [4411]
>>
>>
>>
>> Please select a boot option
>>
>>
>>
>> Windows Boot Manager
>>
>> Debian
>>
>> EFI Shell [Built-in]
>>
>> Removable Media
>>
>> Boot Option Maintenance Menu
>>
>> System Configuration Menu
>>
>>
>>
>>
>>
>> Use ^ and v to change option(s). Use Enter to select an option
>>
>> Loading.: Debian
>>
>> Starting: Debian
>>
>> ELILO v3.14 for EFI/IA-64
>>
>> ..
>>
>> Uncompressing Linux... done
>>
>> Loading file \EFI\debian\initrd.img...done
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _
>> Pedro
>>
>>
>>
>> From: Jason Duerstock
>> Sent: Friday, February 9, 2018 04:01
>> To: Pedro Miguel Teixeira
>> Cc: Gatis Visnevskis; Ivan Zakharyaschev; debian-ia64; gle...@altlinux.org
>>
>>
>> Subject: Re: Bug#711135: Re: compiling a bootable kernel for ia64
>> (itanium2,
>> mckinley, rx2620)
>>
>>
>>
>> Hi Pedro,
>>
>> Can you file a separate bug for this, and include a boot log?
>>
>> Thanks,
>>
>> Jason
>>
>>
>> On Fri, Feb 9, 2018 at 6:24 AM, Pedro Miguel Teixeira <pm...@texair.net>
>> wrote:
>>>
>>>
>>> The latest kernel available from Debian does work fine on my Montvale
>>> rx2660. However, I cannot boot my McKinley zx6000 with it. It will MCA
>>> really early in the boot process.
>>>
>>>
>>>
>>> Linux b777 3.2.0-4-mckinley #1 SMP Debian 3.2.78-1 ia64 GNU/Linux
>>>
>>>
>>>
>>>
>>>
>>> _
>>> Pedro
>>>
>>>
>>>
>>> From: Gatis Visnevskis
>>> Sent: Friday, February 9, 2018 03:13
>>> To: Ivan Zakharyaschev
>>> Cc: Jason Duerstock; debian-ia64; gle...@altlinux.org
>>> Subject: Re: Bug#711135: Re: compiling a bootable kernel for ia64
>>> (itanium2,
>>> mckinley, rx2620)
>>>
>>>
>>>
>>> Hi all
>>>
>>> I got working 3.2.0 kernel after som

Re: Bug#890185: seqan2: FTBFS on ia64

2018-02-11 Thread Jason Duerstock

Apologies.  I should have said forwarded.

On Sun, Feb 11, 2018 at 12:17 PM, John Paul Adrian Glaubitz
<glaub...@physik.fu-berlin.de> wrote:
> On 02/11/2018 06:12 PM, Jason Duerstock wrote:
>> This has been pushed upstream as https://github.com/seqan/seqan/issues/2281
>
> Be careful, "pushed" is misleading here. It's not been pushed yet as in
> it has been merged. You merely filed an issue unless I missed the commit.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#890185: seqan2: FTBFS on ia64

2018-02-11 Thread Jason Duerstock

Source: seqan2
Severity: normal
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

seqan fails to build on ia64 due to some apparently gratuitous assembly calls 
from gcc.

>From include/seqan/parallel/parallel_lock.h:

#else  // everything else.
asm volatile ("nop" ::: "memory");  // default operation - does nothing => 
Might lead to passive spinning.
#endif

This is invalid on ia64, as nop requires an operand.

This has been pushed upstream as https://github.com/seqan/seqan/issues/2281


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

2018-02-09 Thread Jason Duerstock

Hi Pedro,

Can you file a separate bug for this, and include a boot log?

Thanks,

Jason


On Fri, Feb 9, 2018 at 6:24 AM, Pedro Miguel Teixeira <pm...@texair.net> wrote:
>
>
> The latest kernel available from Debian does work fine on my Montvale
> rx2660. However, I cannot boot my McKinley zx6000 with it. It will MCA
> really early in the boot process.
>
>
>
> Linux b777 3.2.0-4-mckinley #1 SMP Debian 3.2.78-1 ia64 GNU/Linux
>
>
>
>
>
> _
> Pedro
>
>
>
> From: Gatis Visnevskis
> Sent: Friday, February 9, 2018 03:13
> To: Ivan Zakharyaschev
> Cc: Jason Duerstock; debian-ia64; gle...@altlinux.org
> Subject: Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2,
> mckinley, rx2620)
>
>
>
> Hi all
>
> I got working 3.2.0 kernel after some work. Without recompilation.
> HP rx4640. That was 2 years ago. Server switched off for cost saving :(
>
> Started to install toolchain for compilation, but not finished.
> Internal disks were too small, some 36 gb i think.
>
> It seems that i have to boot my server, and try again, as there is some
> light in end of tunnel. I was hoping to get LXC working on ia64 some
> day.
>
> Gasha
>
> On Fri, 9 Feb 2018 11:33:16 +0300 (MSK)
> Ivan Zakharyaschev <i...@altlinux.org> wrote:
>
>> Hi,
>>
>> On Wed, 7 Feb 2018, Ivan Zakharyaschev wrote:
>>
>> > On Sun, 4 Feb 2018, Jason Duerstock wrote:
>> >
>> >>  Does the kernel from here work for you?:
>> >>
>> >>  https://people.debian.org/~jrtc27/wheezy-backports-ia64/
>> >>
>> >>  Specifically
>> >>
>> >> https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb
>> >
>> > (As I've already said, this kernel works for our machine.)
>> >
>> > How to reproduce this build? Have you published the corresponding
>> > rules?
>> >
>> > I tried:
>> >
>> > $ apt-get source linux-image-3.16.0-0.bpo.4-mckinley
>> > $ cd linux-3.16.39/
>> > $ sed -e 's/gcc-4.6/gcc-4.4/g' debian/config/ia64/defines -i
>> > $ debuild -b -us -uc
>> > $ debuild -j2 -b -us -uc
>> > ...
>> >   Kernel: vmlinux.gz is ready
>> > ERROR: "numa_slit" [drivers/block/nvme.ko] undefined!
>> > make[6]: *** [__modpost] Error 1
>>
>> BTW, has anyone been working on adapting the newest kernel package
>> for ia64? (buildd simply reports that there are no rules for ia64.)
>>
>> As for building 3.16 myself (reproducing Jason's build), I've found
>> an obvious fix for the above build problem at
>>
>> https://kernel.opensuse.org/cgit/kernel-source/commit/patches.arch/ia64-export-numa_slit.patch?h=packaging=bbf39ca510248f9f9cbfc3c65e8514df929a3094
>> :
>>
>> $ cd debian/patches/
>> $ mkdir bugfix/ia64
>> $ wget
>>
>> 'https://kernel.opensuse.org/cgit/kernel-source/plain/patches.arch/ia64-export-numa_slit.patch?h=packaging=bbf39ca510248f9f9cbfc3c65e8514df929a3094'
>> -O bugfix/ia64/ia64-export-numa_slit.patch
>> $ cat bugfix/ia64/ia64-export-numa_slit.patch
>> From: Hannes Reinecke <h...@suse.de>
>> Date: Wed, 14 Jan 2015 15:01:30 +0100
>> Subject: [PATCH] ia64: export numa_slit()
>> Patch-Mainline: not yet
>> References: bnc#913030,FATE#317455
>>
>> nvme triggers a build error with 'numa_slit' being undefined.
>>
>> Signed-off-by: Hannes Reinecke <h...@suse.de>
>> ---
>>   arch/ia64/mm/numa.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/ia64/mm/numa.c b/arch/ia64/mm/numa.c
>> index 88f4eeb..23a914c 100644
>> --- a/arch/ia64/mm/numa.c
>> +++ b/arch/ia64/mm/numa.c
>> @@ -35,6 +35,7 @@ struct node_cpuid_s node_cpuid[NR_CPUS] =
>>* proportional to the memory access latency ratios.
>>*/
>>   u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
>> +EXPORT_SYMBOL(numa_slit);
>>
>>   /* Identify which cnode a physical address resides on */
>>   int
>
>

Re: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

2018-02-04 Thread Jason Duerstock

Does the kernel from here work for you?:

https://people.debian.org/~jrtc27/wheezy-backports-ia64/

Specifically 
https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb

Jason

On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev  wrote:
> On Mon, 5 Feb 2018, Ivan Zakharyaschev wrote:
>
>> On Sun, 4 Feb 2018, Frank Scheiner wrote:
>>
>>>  just a quick pointer:
>>>
>>>  I had Debian Wheezy with Linux v3.2.x (vmlinuz-3.2.0-4-mckinley, i.e.
>>>  [this one]) running w/o issues on my rx2620 with two Itanium 2 9040
>>>  (Montecito) both from an on-disk installation and a NFS root FS, but I
>>> ran
>>>  it on bare-metal, not in a VM.
>>
>>
>> Yes, [this one] doesn't boot on our system. It might even be in our case a
>> strange/buggy behavior caused by old firmware for an otherwise correct
>> kernel binary code (or, of course, the code might be not correct). Perhaps,
>> there is a difference between yours and ours machines:
>>
>> root@rx2620:~# cat /proc/cpuinfo
>> processor  : 0
>> vendor : GenuineIntel
>> arch   : IA-64
>> family : 31
>> model  : 2
>> model name : Madison up to 9M cache
>> revision   : 1
>> archrev: 0
>> features   : branchlong
>> cpu number : 0
>> cpu regs   : 4
>> cpu MHz: 1600.021
>> itc MHz: 1600.021752
>> BogoMIPS   : 2390.01
>> siblings   : 1
>> physical id: 0
>>
>> processor  : 1
>> vendor : GenuineIntel
>> arch   : IA-64
>> family : 31
>> model  : 2
>> model name : Madison up to 9M cache
>> revision   : 1
>> archrev: 0
>> features   : branchlong
>> cpu number : 0
>> cpu regs   : 4
>> cpu MHz: 1600.021
>> itc MHz: 1600.021752
>> BogoMIPS   : 2390.01
>> siblings   : 1
>> physical id: 1
>>
>> root@rx2620:~#
>>
>> It looks like ours has 2 Madison CPUs (if we are to trust this cpuinfo),
>> which are older than your Montecito ones.
>
>
>>>  [this one]:
>>>  https://packages.debian.org/wheezy/linux-image-3.2.0-4-mckinley
>>
>>
>> As for gathering information, I can't think of some useful information
>> from a working system so far. The same applies to testing. We are able to
>> test it here. Anyway, thanks for your messages, Frank and Daniel! The
>> remaining useful tasks which I see are:
>>
>> 1) learn how to compile a bootable kernel for this machine and apply this
>> knowledge to compile a fresh current kernel;
>>
>> 2) understand what goes wrong (by bisecting gcc), suggest a fix. (Before
>> we understand it, we can't be sure what should be fixed: it's not
>> necessarily abug in gcc).
>>
>> So far, we've done a number of attempts to compile and boot a kernel (I'm
>> going to post the details and the kernels soon), and my conclusion so far is
>> that the only affecting factor is the version of gcc (even not -O1 vs
>> -Os/-O2).
>>
>> gcc <= 4.5.3 produces a bootable kernel (as for
>> linux-image-3.2.0-4-mckinley, gcc 4.4.7 from wheezy and gcc 4.5.3 from
>> snapshots produced a bootable one in my experiments);
>> gcc > = 4.6.3 produces a non-bootable kernel.
>>
>> So this already gives an initial hypothesis about the solution to 1):
>>
>> To compile a bootable kernel for this machine, use gcc <= 4.5.3.
>
>
> Now that we know how to build a bootable kernel for such machines as ours
> (rx2620 with Madison CPU) and probably Daniel Kasza's rx2600, can such an
> update be published for wheezy?
>
> Perhaps, an additional variant of linux-image-mckinley built with gcc-4.4
> (4.4.7) present in wheezy? As a workaround for this bug.
>
> And what about an updated installation image? So that people trying to
> install Debian on such a machine would succeed not only of they take the
> Debian 6 (squeeze) image (which is definitely not the first thing they would
> try when searching for an installation image), but so that Debian 7 (wheezy)
> images (more likely to be found by them) would work for them, too.
>

Bug#889057: gdbm: please remove dependency on dietlibc for ia64

2018-02-01 Thread Jason Duerstock

Source: gdbm
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

As dietlibc does not currently build for ia64, please remove the dependency on 
it.

Patch attached.



-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- debian/control.orig 2018-02-01 07:55:07.603676109 -0500
+++ debian/control  2018-02-01 07:55:34.359575320 -0500
@@ -5,7 +5,7 @@
 Build-Depends: texinfo,
debhelper (>= 10),
dh-exec,
-   dietlibc-dev (>= 0.34~cvs20160606-3) [alpha amd64 arm arm64 
armeb armel armhf hppa i386 ia64 mips mipsel mips64el powerpc powerpcspe ppc64 
ppc64el s390 s390x sparc sparc64 x32],
+   dietlibc-dev (>= 0.34~cvs20160606-3) [alpha amd64 arm arm64 
armeb armel armhf hppa i386 mips mipsel mips64el powerpc powerpcspe ppc64 
ppc64el s390 s390x sparc sparc64 x32],
libreadline-dev
 Standards-Version: 4.1.3
 Homepage: https://gnu.org/software/gdbm

Re: Bug#886175: cross-toolchain-base-ports: Please add support for ia64

2018-01-25 Thread Jason Duerstock

Maybe it needs a stage1 with --disable-libunwind-exceptions?

On Thu, Jan 25, 2018 at 11:00 AM, John Paul Adrian Glaubitz
 wrote:
> On 01/25/2018 04:54 PM, James Clarke wrote:
>>>
>>> I *think* this is because libunwind-dev has to be [ia64] as well in
>>> debian/control.source.in, but I am not 100% sure yet. Testing now.
>>
>>
>> Well, if it didn’t work without [ia64], it won’t work with.
>
>
> It currently has [amd64 i386 x32]. My original patch didn't have this
> limitation. But it still doesn't work anyway which drives me nuts, it
> did work here and I still have the build log and packages built.
>
> I might have used the internal libunwind for gcc.
>
>> The problem is you need the target’s libunwind-dev, so
>> cross-toolchain-base-ports needs to build it itself, I assume, if the target
>> is ia64.
>
>
> No, I most certainly didn't do it that way.
>
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Bug#887453: libunwind: please disable lzma on ia64

2018-01-16 Thread Jason Duerstock

Source: libunwind
Severity: normal
Tags: patch
User: debian-ia64@lists.debian.org
Usertags: ia64

Dear Maintainer,

For the ia64 port, we would like to disable lzma support for ia64, as it has 
caused several packages
to fail building when static linking is used.  (gcc doesn't know to include 
liblzma.a when it tries to
include libunwind.a).

The attached patch should accomplish this.

We will re-enable it once we've determined a good way to work through this 
problem.

Thanks,

Jason


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- debian/control.orig 2018-01-16 10:06:58.752562266 -0500
+++ debian/control  2018-01-16 10:07:19.420483094 -0500
@@ -2,8 +2,8 @@
 Priority: optional
 Section: libs
 Maintainer: Adrian Bunk 
-Build-Depends: debhelper (>= 10), liblzma-dev , 
texlive-extra-utils
-Build-Conflicts: liblzma-dev 
+Build-Depends: debhelper (>= 10), liblzma-dev [!ia64] , 
texlive-extra-utils
+Build-Conflicts: liblzma-dev [ia64] 
 Standards-Version: 4.1.1
 Homepage: http://www.nongnu.org/libunwind

Re: Important packages that are broken ia64

Re: IA-64 GCC deprecation?

Bug#930119: gcc-8: __dso_handle place in wrong segment on ia64

Bug#930082: gmt: FTBFS on ia64

Re: FFmpeg bootstrap

Bug#929326: subversion: please add pkg.subversion.nokde build profile

Re: gzip (i386) uses TEXTRELs

Bug#908519: linux: asciidoctor dependency blocks ia64 build

Bug#906822: gdb: gdb FTBFS on ia64

Bug#906675: gcc-8: remove obsolete ia64 gcc bug workaround

Bug#906531: qtdeclarative-opensource-src: libqt5qml5.symbols and libqt5quick5.symbols need update for ia64

Re: Debian installer

Re: Debian installer

Re: Debian installer

Bug#905536: python3.7: disable -O3 on ia64 due to compiler bug

Bug#897178: mozjs52: more fixes for ia64

Bug#897117: mozjs52: tests fail on ia64: memory and math

Bug#731983: runtime warnings: in:imuxsock: unaligned access to 0x0000000043765a09

Bug#892200: qdbm: FTBFS on arches without openjdk

Bug#890432: suricata: FTBFS on ia64

Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

Re: Bug#890185: seqan2: FTBFS on ia64

Bug#890185: seqan2: FTBFS on ia64

Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

Re: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

Bug#889057: gdbm: please remove dependency on dietlibc for ia64

Re: Bug#886175: cross-toolchain-base-ports: Please add support for ia64

Bug#887453: libunwind: please disable lzma on ia64

28 matches

Site Navigation

Mail list logo

Footer information