[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2020-02-23 Thread Bug Watch Updater
** Changed in: binutils
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Released
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Other Info]

   * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed
  instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci-
  train-ppa-service/+archive/ubuntu/3878 for the -security pocket as
  2.33-2ubuntu1.2.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2020-01-12 Thread Launchpad Bug Tracker
This bug was fixed in the package binutils - 2.33-2ubuntu1.2

---
binutils (2.33-2ubuntu1.2) eoan; urgency=medium

  * Rebuild for the -security pocket

binutils (2.33-2ubuntu1.1) eoan; urgency=medium

  * Cherry-pick from binutils master branch:
PR25237, set no file contents PT_LOAD p_offset to first page (LP: #1843479)

 -- Balint Reczey   Thu, 19 Dec 2019 12:46:41 +0100

** Changed in: binutils (Ubuntu Eoan)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Released
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Other Info]

   * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed
  instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci-
  train-ppa-service/+archive/ubuntu/3878 for the -security pocket as
  2.33-2ubuntu1.2.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-20 Thread Mathew Hodson
** Changed in: binutils (Ubuntu)
   Importance: Undecided => Medium

** Changed in: binutils (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: gzip (Ubuntu Eoan)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Other Info]

   * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed
  instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci-
  train-ppa-service/+archive/ubuntu/3878 for the -security pocket as
  2.33-2ubuntu1.2.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-20 Thread Balint Reczey
Verified binutils 2.33-2ubuntu1.2 by rebuilding gzip in the Bileto PPA
with new binutils and checking the rebuilt gzip binary:

root@ee-dwz:~# wget 
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+build/18334107/+files/gzip_1.10-0ubuntu3.1_amd64.deb
--2019-12-20 17:50:02--  
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+build/18334107/+files/gzip_1.10-0ubuntu3.1_amd64.deb
Resolving launchpad.net (launchpad.net)... 91.189.89.222, 91.189.89.223, 
2001:67c:1560:8003::8003, ...
Connecting to launchpad.net (launchpad.net)|91.189.89.222|:443... connected.
HTTP request sent, awaiting response... 303 See Other
Location: 
https://launchpadlibrarian.net/456546671/gzip_1.10-0ubuntu3.1_amd64.deb 
[following]
--2019-12-20 17:50:03--  
https://launchpadlibrarian.net/456546671/gzip_1.10-0ubuntu3.1_amd64.deb
Resolving launchpadlibrarian.net (launchpadlibrarian.net)... 91.189.89.228, 
91.189.89.229, 2001:67c:1560:8003::8007, ...
Connecting to launchpadlibrarian.net 
(launchpadlibrarian.net)|91.189.89.228|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 95292 (93K) [application/x-debian-package]
Saving to: ‘gzip_1.10-0ubuntu3.1_amd64.deb’

gzip_1.10-0ubuntu3.1_amd64.deb
100%[=>]
93.06K  --.-KB/sin 0.1s

2019-12-20 17:50:03 (715 KB/s) - ‘gzip_1.10-0ubuntu3.1_amd64.deb’ saved
[95292/95292]

root@ee-dwz:~# apt install ./gzip_1.10-0ubuntu3.1_amd64.deb 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Note, selecting 'gzip' instead of './gzip_1.10-0ubuntu3.1_amd64.deb'
gzip is already the newest version (1.10-0ubuntu3.1).
The following package was automatically installed and is no longer required:
  libdumbnet1
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
root@ee-dwz:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
root@ee-dwz:~# echo $?
0
root@ee-dwz:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE

Elf file type is DYN (Shared object file)
Entry point 0x4190
There are 14 program headers, starting at offset 64

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz 
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x000310 
0x000310 R   0x8
  INTERP 0x000350 0x0350 0x0350 0x1c 
0x1c R   0x1
  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD   0x00 0x 0x 0x0027a0 
0x0027a0 R   0x1000
  LOAD   0x003000 0x3000 0x3000 0x00ea05 
0x00ea05 R E 0x1000
  LOAD   0x012000 0x00012000 0x00012000 0x003e80 
0x003e80 R   0x1000
  LOAD   0x016690 0x00017690 0x00017690 0x000d70 
0x000d70 RW  0x1000
  LOAD   0x00 0x0001a000 0x0001a000 0x00 
0x0ca048 RW  0x1000
  DYNAMIC0x016b80 0x00017b80 0x00017b80 0x0001f0 
0x0001f0 RW  0x8
  NOTE   0x000370 0x0370 0x0370 0x20 
0x20 R   0x8
  NOTE   0x000390 0x0390 0x0390 0x44 
0x44 R   0x4
  GNU_PROPERTY   0x000370 0x0370 0x0370 0x20 
0x20 R   0x8
  GNU_EH_FRAME   0x01433c 0x0001433c 0x0001433c 0x000404 
0x000404 R   0x4
  GNU_STACK  0x00 0x 0x 0x00 
0x00 RW  0x10
  GNU_RELRO  0x016690 0x00017690 0x00017690 0x000970 
0x000970 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00 
   01 .interp 
   02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash 
.dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03 .init .plt .plt.got .plt.sec .text .fini 
   04 .rodata .eh_frame_hdr .eh_frame 
   05 .init_array .fini_array .data.rel.ro .dynamic .got .data 
   06 .bss 
   07 .dynamic 
   08 .note.gnu.property 
   09 .note.gnu.build-id .note.ABI-tag 
   10 .note.gnu.property 
   11 .eh_frame_hdr 
   12 
   13 .init_array .fini_array .data.rel.ro .dynamic .got 
root@ee-dwz:~# 


** Description changed:

- IMPORTANT: Binutils was accidentally built in -proposed instead of in a
- PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
- service/+archive/ubuntu/3877 for the -security pocket.
- 
  [Impact]
  
   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of 

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-20 Thread Steve Langasek
Hello Hayden, or anyone else affected,

Accepted binutils into eoan-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/binutils/2.33-2ubuntu1.2 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Tags removed: verification-done verification-done-eoan
** Tags added: verification-needed verification-needed-eoan

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Other Info]

   * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed
  instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci-
  train-ppa-service/+archive/ubuntu/3878 for the -security pocket as
  2.33-2ubuntu1.2.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-19 Thread Balint Reczey
** Description changed:

  IMPORTANT: Binutils was accidentally built in -proposed instead of in a
  PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
- service/+archive/ubuntu/3876 for the -security pocket.
+ service/+archive/ubuntu/3877 for the -security pocket.
  
  [Impact]
  
   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.
  
  [Test Case]
  
   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
  
  [ Regression Potential ]
  
   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.
  
  [Originial Bug Text]
  
  Summary:
  
  Running gzip on WSL1 results in the following error:
  
  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error
  
  What I expect to happen:
  
  gzip executes correctly on WSL1.
  
  What happens instead:
  
  gzip fails with an Exec format error.
  
  Notes:
  
  I suspect a change in how gzip is being built for Eoan is causing issues
  with ELF parsing on the WSL1 translation layer. For example:
  
  On Disco with gzip 1.9-3:
  
  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped
  
  On Eoan with gzip 1.10-0ubuntu3:
  
  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped
  
  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not
  believe this is an issue in 1.10 because this error does not occur when
  building gzip from GNU project source on Ubuntu Eoan.
  
  Justifications:
  
  WSL1 will need to be patched in future Windows builds for this change in
  ELF. However that patch will likely not be backported to older builds of
  Windows, including Windows Enterprise/Server 2019.
  
  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.
  
  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461
  
  Details:
  
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10
  
  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  IMPORTANT: Binutils was accidentally built in -proposed instead of in
  a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/3877 for the -security pocket.

  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and 

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-19 Thread Łukasz Zemczak
So the binutils upload will need to be re-built against security and
pushed to the -security pocket additionally to the -updates pocket,
otherwise all the future potential gzip security updates would revert
this fix here. Balint is preparing the rebuild, but I think ubuntu-
security should be notified.

In the meantime, I have released gzip as is as it does not have any
runtime dependency on the new binutils. It did not age fully but I am
conditionally accepting it earlier.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  IMPORTANT: Binutils was accidentally built in -proposed instead of in
  a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/3876 for the -security pocket.

  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-19 Thread Launchpad Bug Tracker
This bug was fixed in the package gzip - 1.10-0ubuntu3.1

---
gzip (1.10-0ubuntu3.1) eoan; urgency=high

  * Rebuild with binutils 2.33-2ubuntu1.1 (LP: #1843479)
- Build-depend on binutils (>= 2.33-2ubuntu1.1)

 -- Balint Reczey   Fri, 13 Dec 2019 16:41:46 +0100

** Changed in: gzip (Ubuntu Eoan)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  IMPORTANT: Binutils was accidentally built in -proposed instead of in
  a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/3876 for the -security pocket.

  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-19 Thread Łukasz Zemczak
(actually, I don't think security needs to be notified, so scratch that)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  IMPORTANT: Binutils was accidentally built in -proposed instead of in
  a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/3876 for the -security pocket.

  [Impact]

   * Running gzip on WSL1 results in the following error:
     $ gzip
     -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
    $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-19 Thread Balint Reczey
** Description changed:

+ IMPORTANT: Binutils was accidentally built in -proposed instead of in a
+ PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa-
+ service/+archive/ubuntu/3876 for the -security pocket.
+ 
  [Impact]
  
-  * Running gzip on WSL1 results in the following error:
-$ gzip
--bash: /bin/gzip: cannot execute binary file: Exec format error
-  * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
-  * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.
+  * Running gzip on WSL1 results in the following error:
+    $ gzip
+    -bash: /bin/gzip: cannot execute binary file: Exec format error
+  * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
+  * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.
  
  [Test Case]
  
-  * Check the gzip binary for wrong offset:
-   $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
+  * Check the gzip binary for wrong offset:
+   $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
  
  [ Regression Potential ]
  
-  * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
-  * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.
+  * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
+  * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.
  
  [Originial Bug Text]
  
  Summary:
  
  Running gzip on WSL1 results in the following error:
  
  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error
  
  What I expect to happen:
  
  gzip executes correctly on WSL1.
  
  What happens instead:
  
  gzip fails with an Exec format error.
  
  Notes:
  
  I suspect a change in how gzip is being built for Eoan is causing issues
  with ELF parsing on the WSL1 translation layer. For example:
  
  On Disco with gzip 1.9-3:
  
  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped
  
  On Eoan with gzip 1.10-0ubuntu3:
  
  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped
  
  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not
  believe this is an issue in 1.10 because this error does not occur when
  building gzip from GNU project source on Ubuntu Eoan.
  
  Justifications:
  
  WSL1 will need to be patched in future Windows builds for this change in
  ELF. However that patch will likely not be backported to older builds of
  Windows, including Windows Enterprise/Server 2019.
  
  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.
  
  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461
  
  Details:
  
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10
  
  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Released

Bug description:
  IMPORTANT: 

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-17 Thread Balint Reczey
Verified gzip 1.10-0ubuntu3.1 rebuilt with binutils (2.33-2ubuntu1.1):

root@ee-motd-verify:~# dpkg -l gzip
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
+++-==-===--=
ii  gzip   1.10-0ubuntu3.1 amd64GNU compression utilities
root@ee-motd-verify:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | 
awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print 
"wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' && echo 
ok
ok
root@ee-motd-verify:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE

Elf file type is DYN (Shared object file)
Entry point 0x4190
There are 14 program headers, starting at offset 64

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz 
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x000310 
0x000310 R   0x8
  INTERP 0x000350 0x0350 0x0350 0x1c 
0x1c R   0x1
  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD   0x00 0x 0x 0x0027a0 
0x0027a0 R   0x1000
  LOAD   0x003000 0x3000 0x3000 0x00ea05 
0x00ea05 R E 0x1000
  LOAD   0x012000 0x00012000 0x00012000 0x003e80 
0x003e80 R   0x1000
  LOAD   0x016690 0x00017690 0x00017690 0x000d70 
0x000d70 RW  0x1000
  LOAD   0x00 0x0001a000 0x0001a000 0x00 
0x0ca048 RW  0x1000
  DYNAMIC0x016b80 0x00017b80 0x00017b80 0x0001f0 
0x0001f0 RW  0x8
  NOTE   0x000370 0x0370 0x0370 0x20 
0x20 R   0x8
  NOTE   0x000390 0x0390 0x0390 0x44 
0x44 R   0x4
  GNU_PROPERTY   0x000370 0x0370 0x0370 0x20 
0x20 R   0x8
  GNU_EH_FRAME   0x01433c 0x0001433c 0x0001433c 0x000404 
0x000404 R   0x4
  GNU_STACK  0x00 0x 0x 0x00 
0x00 RW  0x10
  GNU_RELRO  0x016690 0x00017690 0x00017690 0x000970 
0x000970 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00 
   01 .interp 
   02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash 
.dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03 .init .plt .plt.got .plt.sec .text .fini 
   04 .rodata .eh_frame_hdr .eh_frame 
   05 .init_array .fini_array .data.rel.ro .dynamic .got .data 
   06 .bss 
   07 .dynamic 
   08 .note.gnu.property 
   09 .note.gnu.build-id .note.ABI-tag 
   10 .note.gnu.property 
   11 .eh_frame_hdr 
   12 
   13 .init_array .fini_array .data.rel.ro .dynamic .got 
root@ee-motd-verify:~# stat -c %s /usr/bin/gzip
97496


Note that the last PT_LOAD segment is set to 0.

** Tags removed: verification-needed verification-needed-eoan
** Tags added: verification-done verification-done-eoan

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
 $ gzip
 -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-16 Thread Launchpad Bug Tracker
This bug was fixed in the package gzip - 1.10-0ubuntu4

---
gzip (1.10-0ubuntu4) focal; urgency=high

  * Rebuild with binutils 2.33.1-6ubuntu1 (LP: #1843479)
- Build-depend on binutils (>= 2.33.1-6ubuntu1)
  * Pass -fstack-protector to mingw build to fix FTBFS

 -- Balint Reczey   Fri, 13 Dec 2019 16:41:46 +0100

** Changed in: gzip (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  Fix Released
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
 $ gzip
 -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-16 Thread Łukasz Zemczak
Hello Hayden, or anyone else affected,

Accepted gzip into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/gzip/1.10-0ubuntu3.1
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: gzip (Ubuntu Eoan)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  In Progress
Status in binutils source package in Eoan:
  Fix Committed
Status in gzip source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
 $ gzip
 -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-13 Thread Launchpad Bug Tracker
This bug was fixed in the package binutils - 2.33.1-6ubuntu1

---
binutils (2.33.1-6ubuntu1) focal; urgency=medium

  * Merge with Debian; remaining changes:
- Build from upstream sources.
- Don't generate control file entries for any native mips* packages.
  * Cherry-pick from binutils master branch:
PR25237, set no file contents PT_LOAD p_offset to first page (LP: #1843479)

binutils (2.33.1-6) unstable; urgency=medium

  * Update from the binutils 2.33 branch:
- [gas] Implement .cfi_negate_ra_state directive (AArch64).

 -- Balint Reczey   Fri, 13 Dec 2019 16:24:27 +0100

** Changed in: binutils (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  Fix Released
Status in gzip package in Ubuntu:
  In Progress
Status in binutils source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
 $ gzip
 -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-13 Thread Steve Langasek
Hello Hayden, or anyone else affected,

Accepted binutils into eoan-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/binutils/2.33-2ubuntu1.1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: binutils (Ubuntu Eoan)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-eoan

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress
Status in binutils source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
 $ gzip
 -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
    Installed: 1.10-0ubuntu3
    Candidate: 1.10-0ubuntu3
    Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-13 Thread Balint Reczey
** Description changed:

+ [Impact]
+ 
+  * Running gzip on WSL1 results in the following error:
+$ gzip
+-bash: /bin/gzip: cannot execute binary file: Exec format error
+  * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
+  * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.
+ 
+ [Test Case]
+ 
+  * Check the gzip binary for wrong offset:
+   $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'
+ 
+ [ Regression Potential ]
+ 
+  * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
+  * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.
+ 
+ [Originial Bug Text]
+ 
  Summary:
  
  Running gzip on WSL1 results in the following error:
  
  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error
  
  What I expect to happen:
  
  gzip executes correctly on WSL1.
  
  What happens instead:
  
  gzip fails with an Exec format error.
  
  Notes:
  
  I suspect a change in how gzip is being built for Eoan is causing issues
  with ELF parsing on the WSL1 translation layer. For example:
  
  On Disco with gzip 1.9-3:
  
  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped
  
  On Eoan with gzip 1.10-0ubuntu3:
  
  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped
  
  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not
  believe this is an issue in 1.10 because this error does not occur when
  building gzip from GNU project source on Ubuntu Eoan.
  
  Justifications:
  
  WSL1 will need to be patched in future Windows builds for this change in
  ELF. However that patch will likely not be backported to older builds of
  Windows, including Windows Enterprise/Server 2019.
  
  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.
  
  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461
  
  Details:
  
  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10
  
  gzip:
-   Installed: 1.10-0ubuntu3
-   Candidate: 1.10-0ubuntu3
-   Version table:
-  *** 1.10-0ubuntu3 500
- 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
- 100 /var/lib/dpkg/status
+   Installed: 1.10-0ubuntu3
+   Candidate: 1.10-0ubuntu3
+   Version table:
+  *** 1.10-0ubuntu3 500
+ 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
+ 100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * Running gzip on WSL1 results in the following error:
 $ gzip
 -bash: /bin/gzip: cannot execute binary file: Exec format error
   * The error occurs frequently in package updates and makes gzip inoperable 
on WSL1
   * The problem is caused by PT_LOAD offset pointing past the end of file and 
the fix is fixing strip to not generate such ELF files and recompiling gzip 
with the fixed strip.

  [Test Case]

   * Check the gzip binary for wrong offset:
$ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v 
size=$(stat -c %s $FILE) '/^  LOAD/ {if (strtonum($2) > size) {print "wrong 
offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}'

  [ Regression Potential ]

   * The binutils fix could cause binutils to generate invalid ELF files. The 
fix is very small and isolated and has been tested and accepted by upstream, 
which makes such problems unlikely.
   * Bugs in the toolchain in general can make the rebuilt gzip show new 
errors, but this generally applies to many SRUs and security updates. The 
testing period in proposed should mitigate this risk.

  [Originial Bug Text]

  Summary:

  Running gzip on WSL1 results 

[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-08 Thread Balint Reczey
I've forwarded the binutils patch to the mailing list, too:
https://sourceware.org/ml/binutils/2019-12/msg00104.html .

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-08 Thread Balint Reczey
The offset pointing past EOF is observed only in gzip and in several
debug files:

$ grep -v dbg wrong-offsets 
gzip_1.10-0ubuntu3_amd64.deb: /bin/gzip
libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: 
/usr/lib/libhugetlbfs/tests/obj64/xB.linkhuge
libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: 
/usr/lib/libhugetlbfs/tests/obj64/xB.linkhuge_nofd
libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: 
/usr/lib/libhugetlbfs/tests/obj64/xB.linkshare
libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: 
/usr/lib/libhugetlbfs/tests/obj64/zero_filesize_segment

After binutils is backported only gzip needs to be rebuilt.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-02 Thread Bug Watch Updater
** Changed in: binutils
   Status: Won't Fix => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Confirmed
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-12-01 Thread Bug Watch Updater
** Changed in: binutils
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Won't Fix
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-11-30 Thread Bug Watch Updater
Launchpad has imported 1 comments from the remote bug at
https://sourceware.org/bugzilla/show_bug.cgi?id=25237.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.


On 2019-11-30T23:38:36+00:00 Balint Reczey wrote:

Created attachment 12095
Patch adjusting offset to stay in the file

This itself was tolerated for long time, but WSL's ELF loader crashes
due to the offset and it seems to be easy to fix.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/comments/7


** Changed in: binutils
   Status: Unknown => New

** Changed in: binutils
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  New
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-11-30 Thread Balint Reczey
** Bug watch added: Sourceware.org Bugzilla #25237
   https://sourceware.org/bugzilla/show_bug.cgi?id=25237

** Also affects: binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=25237
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils:
  Unknown
Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-11-30 Thread Balint Reczey
While this is a bug in WSL's ELF loader I located to problem in
binutil's strip and after the fix passed my testing I'll send it
upstream and also SRU it to Eoan to let us rebuild affected packages.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-11-30 Thread Balint Reczey
** Also affects: binutils (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: binutils (Ubuntu)
   Status: New => In Progress

** Changed in: binutils (Ubuntu)
 Assignee: (unassigned) => Balint Reczey (rbalint)

** Changed in: gzip (Ubuntu)
   Status: Invalid => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in binutils package in Ubuntu:
  In Progress
Status in gzip package in Ubuntu:
  In Progress

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-10-01 Thread Sebastien Bacher
Thanks Hayden, closing

** Changed in: gzip (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Invalid

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-09-30 Thread Hayden Barnes
This was determined to be a bug in the WSL1 ELF loader and fix is
inbound from the WSL side.
https://github.com/microsoft/WSL/issues/4461#issuecomment-536023805

Please close on Ubuntu.

** Bug watch added: github.com/microsoft/WSL/issues #4461
   https://github.com/microsoft/WSL/issues/4461

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Confirmed

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-09-23 Thread Hayden Barnes
>From the WSL issues page:

> Now, thing is, all of the new binaries (f.e. /bin/ls) have that
.plt.sec section also, and they work just fine. Also compiling a hello.c
with -fcf-protection works. Because of course it does. The only other
new section in there (Disco gzip has 27 sections, Eoan has 29) is
.note.gnu.property. No joy after stripping that either. Meh. It's not
.note.ABI-tag; I stripped that as a WAG right after this issue was
posted. Which is all a long description of things that don't work. Next
thing to try would be to grab the apt-source, try to build a broken
binary, and then try to guess what makes gzip so special (contrast say
/bin/ls).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Confirmed

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-09-11 Thread Stephen Kitt
I tried comparing the binaries with diffoscope, and one difference which
jumped out at me is the .plt.sec section which is present in the Eoan
binary. This presumably comes from CET (gcc -fcf-protection). There are
other differences, less significant IMO; .plt.sec is a likely candidate
for something WSL1 might not support.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Confirmed

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-09-11 Thread Sebastien Bacher
** Changed in: gzip (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Confirmed

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-09-11 Thread Sebastien Bacher
** Tags added: wsl

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Confirmed

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1

2019-09-11 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: gzip (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1843479

Title:
  gzip in Ubuntu Eoan results in Exec format error on WSL1

Status in gzip package in Ubuntu:
  Confirmed

Bug description:
  Summary:

  Running gzip on WSL1 results in the following error:

  $ gzip
  -bash: /bin/gzip: cannot execute binary file: Exec format error

  What I expect to happen:

  gzip executes correctly on WSL1.

  What happens instead:

  gzip fails with an Exec format error.

  Notes:

  I suspect a change in how gzip is being built for Eoan is causing
  issues with ELF parsing on the WSL1 translation layer. For example:

  On Disco with gzip 1.9-3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped

  On Eoan with gzip 1.10-0ubuntu3:

  $ file /bin/gzip
  /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, 
stripped

  Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do
  not believe this is an issue in 1.10 because this error does not occur
  when building gzip from GNU project source on Ubuntu Eoan.

  Justifications:

  WSL1 will need to be patched in future Windows builds for this change
  in ELF. However that patch will likely not be backported to older
  builds of Windows, including Windows Enterprise/Server 2019.

  To ensure Eoan can run on current and older builds of Windows Ubuntu
  should consider looking at how it's building gzip and see if it can be
  made to 'play nice' until WSL1 can be updated.

  This was originally reported here:
  https://github.com/microsoft/WSL/issues/4461

  Details:

  Description:Ubuntu Eoan Ermine (development branch)
  Release:19.10

  gzip:
Installed: 1.10-0ubuntu3
Candidate: 1.10-0ubuntu3
Version table:
   *** 1.10-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp