[Kernel-packages] [Bug 1878899] Re: Call trace from __video_do_ioctl

2020-09-29 Thread Tiago Stürmer Daitx 
** Also affects: v4l2loopback (Ubuntu)
   Importance: Undecided
   Status: New

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

** No longer affects: linux (Ubuntu)

** Summary changed:

- Call trace from __video_do_ioctl
+ Call trace from __video_do_ioctl on focal

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1878899

Title:
  Call trace from __video_do_ioctl on focal

Status in v4l2loopback package in Ubuntu:
  Confirmed

Bug description:
  [92420.303133] [ cut here ]
  [92420.303141] WARNING: CPU: 2 PID: 259541 at 
drivers/media/v4l2-core/v4l2-ioctl.c:1069 v4l_querycap+0x8f/0xa0 [videodev]
  [92420.303141] Modules linked in: btrfs xor zstd_compress raid6_pq ufs qnx4 
hfsplus hfs minix ntfs msdos jfs xfs gspca_zc3xx joydev snd_seq_dummy 
iptable_mangle xt_CHECKSUM iptable_nat xt_MASQUERADE nf_nat nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_tcpudp bridge stp llc iptable_filter 
bpfilter v4l2loopback(OE) binfmt_misc nls_iso8859_1 uvcvideo gspca_vc032x 
gspca_main videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common 
videodev snd_usb_audio snd_usbmidi_lib mc snd_seq_midi snd_seq_midi_event 
snd_rawmidi edac_mce_amd kvm_amd ccp snd_hda_codec_realtek snd_seq 
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel kvm 
snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq_device snd_pcm 
input_leds serio_raw k10temp fam15h_power snd_timer snd soundcore mac_hid 
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 uas 
usb_storage dm_crypt amdgpu amd_iommu_v2 gpu_sched hid_generic usbhid hid 
crct10dif_pclmul crc32_pclmul
  [92420.303167]  ghash_clmulni_intel radeon i2c_algo_bit ttm aesni_intel 
drm_kms_helper crypto_simd syscopyarea cryptd sysfillrect sysimgblt glue_helper 
fb_sys_fops ahci libahci i2c_piix4 drm r8169 realtek video
  [92420.303174] CPU: 2 PID: 259541 Comm: teams Tainted: GW  OE 
5.4.0-29-lowlatency #33-Ubuntu
  [92420.303175] Hardware name: Gigabyte Technology Co., Ltd. To be filled by 
O.E.M./G1.Sniper A88X-CF, BIOS F7 01/08/2014
  [92420.303182] RIP: 0010:v4l_querycap+0x8f/0xa0 [videodev]
  [92420.303183] Code: 00 00 80 48 b9 00 00 20 00 00 00 20 00 48 0b 4b 54 21 d6 
39 f2 75 13 48 89 4b 54 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b eb d0 <0f> 0b 48 
89 4b 54 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 44 00 00
  [92420.303184] RSP: 0018:b4aa44dd7c78 EFLAGS: 00010202
  [92420.303186] RAX:  RBX: b4aa44dd7d88 RCX: 
8520800185208001
  [92420.303187] RDX: 85008003 RSI: 85008001 RDI: 

  [92420.303188] RBP: b4aa44dd7ca0 R08:  R09: 
000a
  [92420.303188] R10:  R11:  R12: 
994f4e421000
  [92420.303189] R13: 994f4de6bf00 R14: 994f4c191940 R15: 
c0f2e360
  [92420.303191] FS:  7f47f2ffd700() GS:994f5fb0() 
knlGS:
  [92420.303192] CS:  0010 DS:  ES:  CR0: 80050033
  [92420.303193] CR2: 7f482c0e1000 CR3: 0003d0084000 CR4: 
000406e0
  [92420.303194] Call Trace:
  [92420.303201]  __video_do_ioctl+0x1a7/0x410 [videodev]
  [92420.303204]  ? default_send_IPI_single+0x20/0x40
  [92420.303206]  ? resched_curr+0x62/0xe0
  [92420.303213]  video_usercopy+0x2ad/0x690 [videodev]
  [92420.303220]  ? v4l_s_fmt+0x670/0x670 [videodev]
  [92420.303224]  ? wake_up_q+0x40/0x70
  [92420.303230]  video_ioctl2+0x15/0x20 [videodev]
  [92420.303237]  v4l2_ioctl+0x4c/0x60 [videodev]
  [92420.303238]  do_vfs_ioctl+0x405/0x660
  [92420.303240]  ? __fget+0x77/0xa0
  [92420.303242]  ksys_ioctl+0x67/0x90
  [92420.303244]  __x64_sys_ioctl+0x1a/0x20
  [92420.303246]  do_syscall_64+0x57/0x190
  [92420.303248]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [92420.303249] RIP: 0033:0x7f489773737b
  [92420.303251] Code: 0f 1e fa 48 8b 05 15 3b 0d 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d e5 3a 0d 00 f7 d8 64 89 01 48
  [92420.303252] RSP: 002b:7f47f2ff77e8 EFLAGS: 0246 ORIG_RAX: 
0010
  [92420.303254] RAX: ffda RBX: 7f4824026900 RCX: 
7f489773737b
  [92420.303255] RDX: 7f47f2ff78b0 RSI: 80685600 RDI: 
0046
  [92420.303256] RBP: 80685600 R08:  R09: 
5645ec03ee68
  [92420.303257] R10: 0048 R11: 0246 R12: 
0046
  [92420.303258] R13: 7f47f2ff78b0 R14: 0015 R15: 
7f485b666039
  [92420.303260] ---[ end trace 6e9a5041142fdaab ]---

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-lowlatency 5.4.0.29.34
  ProcVersionSignature: Ubuntu 5.4.0-29.33-lowlatency 5.4.30
  Uname: Linux 5.4.0-29-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture:

[Kernel-packages] [Bug 1793290] Re: Purging the custom kernel does not remove initramfs

2018-09-19 Thread Tiago Stürmer Daitx 
A few questions:
- Could you please provide the output of the apt-get purge call?
- If update-initramfs is called in it, could you please manually call it with 
the verbose flag (-v) and attach the output?
- Does this only happen on the half-configured scenario?

I'm moving the status to Incomplete. Please feel free to move it back to
New as soon as new information is available.

** Changed in: linux-aws (Ubuntu)
   Status: New => Incomplete

** Changed in: linux-kvm (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1793290

Title:
  Purging the custom kernel does not remove initramfs

Status in linux-aws package in Ubuntu:
  Incomplete
Status in linux-kvm package in Ubuntu:
  Incomplete

Bug description:
  Purge the kernel and you will be left with the initramfs in /boot and
  /var/lib/initramfs-tools.  This is handled correctly for linux-generic
  /linux-virtual.

  * Launch a bionic/cosmic AWS image
  * Purge the kernel
  $ sudo apt-get purge --assume-yes '^linux-.*' 'linux-base+' initramfs*

  $ ls /boot/
  grub  initrd.img-4.15.0-1021-aws

  $ ls /var/lib/initramfs-tools/
  4.15.0-1021-aws

  This was seen with Bionic and Cosmic with linux-aws and linux-kvm

  Impact: during cloud image builds we remove one kernel and install the
  optimized kernel like linux-aws.  The missing cleanup consumes disk
  space for images that are meant to be small; it also surfaces a latent
  bug in initramfs-tools where mkinitramfs will attempt to run to update
  every initramfs in /var/lib/initramfs-tools/ when it is only half-
  configured and it falls over.  We'll work around this but the kernels
  should clean up when purged.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1793290/+subscriptions

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

[Kernel-packages] [Bug 1791959] Re: [SRU] remove orphaned initrd old-dkms files in /boot

2018-09-18 Thread Tiago Stürmer Daitx 
SRU as a merge proposal for both this and bug 1667512 available at

Bionic: 
https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355189
Xenial: 
https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355190

** No longer affects: dkms (Ubuntu)

** No longer affects: dkms (Ubuntu Xenial)

** No longer affects: dkms (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  [SRU] remove orphaned initrd old-dkms files in /boot

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing old-dkms initrd files using the
  kernel's prerm hook, but that is only executed for the kernel version
  being removed: any other old-dkms file generated prior to that would
  not be removed by the hook, taking space in the /boot directory and
  being carried forward with every upgrade.

  Note: Filling up the /boot partition causes updates and upgrades to
  fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.

  This assumes a new Xenial/Bionic schroot.

  1) create files to work as a placeholders for old dkms files (there are 4 
possible namings for these files)
  touch /boot/initrd-4.0.0-0-generic.img.old-dkms 
/boot/initramfs-4.0.0-0-generic.img.old-dkms 
/boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  * xenial:
  apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic 
linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12
  * bionic:
  apt-get install -y linux-image-4.15.0-32-generic 
linux-image-4.15.0-33-generic linux-image-4.15.0-34-generic r8168-dkms 
initramfs-tools=0.130ubuntu3.3

  3) install the headers for the old kernels (forces dkms to run)
  * xenial:
  apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
  * bionic:
  apt-get install -y linux-headers-4.15.0-32-generic 
linux-headers-4.15.0-33-generic linux-headers-4.15.0-34-generic

  4) verify that there are 7 old-dkms, the 4 manually created ones and one for 
each installed kernel
  ls -1 /boot/*.old-dkms

  5) install the initramfs-tools from proposed that contains this fix
  apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms files were removed and that 
there are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms

  7) mark kernel images and headers as automatically installed
  apt-mark auto linux-image-4*-generic linux-headers-4*-generic

  8) autoremove the older kernel
  apt-get autoremove -y

  9) verify that there are now only 2 old-dkms, one for each installed kernel
  ls -1 /boot/*.old-dkms

  
  These steps guarantees that:
  - orphaned old-dkms are correctly removed from /boot
  - non-orphaned old-dkms are kept
  - when kernel is removed the related old-dkms are also deleted

  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

  One notices *.old-dkms files being left behind still sitting on the
  disk after purging the related kernel. This can cause /boot to become
  full, and when it gets really bad, even sudo apt-get autoremove won't
  fix the problem - only deleting the old-dkms files manually solves the
  problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1791959/+subscriptions

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

[Kernel-packages] [Bug 1791959] Re: [SRU] remove orphaned initrd old-dkms files in /boot

2018-09-12 Thread Tiago Stürmer Daitx 
attaching bionic sru patch

** Patch added: "initramfs-tools_0.130ubuntu3.3_debdiff_0.130ubuntu3.4.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1791959/+attachment/5187983/+files/initramfs-tools_0.130ubuntu3.3_debdiff_0.130ubuntu3.4.patch

** Tags added: bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  [SRU] remove orphaned initrd old-dkms files in /boot

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in dkms source package in Xenial:
  Invalid
Status in initramfs-tools source package in Xenial:
  New
Status in dkms source package in Bionic:
  Invalid
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing old-dkms initrd files using the
  kernel's prerm hook, but that is only executed for the kernel version
  being removed: any other old-dkms file generated prior to that would
  not be removed by the hook, taking space in the /boot directory and
  being carried forward with every upgrade.

  Note: Filling up the /boot partition causes updates and upgrades to
  fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.

  This assumes a new Xenial/Bionic schroot.

  1) create files to work as a placeholders for old dkms files (there are 4 
possible namings for these files)
  touch /boot/initrd-4.0.0-0-generic.img.old-dkms 
/boot/initramfs-4.0.0-0-generic.img.old-dkms 
/boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  * xenial:
  apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic 
linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12
  * bionic:
  apt-get install -y linux-image-4.15.0-32-generic 
linux-image-4.15.0-33-generic linux-image-4.15.0-34-generic r8168-dkms 
initramfs-tools=0.130ubuntu3.3

  3) install the headers for the old kernels (forces dkms to run)
  * xenial:
  apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
  * bionic:
  apt-get install -y linux-headers-4.15.0-32-generic 
linux-headers-4.15.0-33-generic linux-headers-4.15.0-34-generic

  4) verify that there are 7 old-dkms, the 4 manually created ones and one for 
each installed kernel
  ls -1 /boot/*.old-dkms

  5) install the initramfs-tools from proposed that contains this fix
  apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms files were removed and that 
there are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms

  7) mark kernel images and headers as automatically installed
  apt-mark auto linux-image-4*-generic linux-headers-4*-generic

  8) autoremove the older kernel
  apt-get autoremove -y

  9) verify that there are now only 2 old-dkms, one for each installed kernel
  ls -1 /boot/*.old-dkms

  
  These steps guarantees that:
  - orphaned old-dkms are correctly removed from /boot
  - non-orphaned old-dkms are kept
  - when kernel is removed the related old-dkms are also deleted

  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

  One notices *.old-dkms files being left behind still sitting on the
  disk after purging the related kernel. This can cause /boot to become
  full, and when it gets really bad, even sudo apt-get autoremove won't
  fix the problem - only deleting the old-dkms files manually solves the
  problem.

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

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

[Kernel-packages] [Bug 1791959] Re: [SRU] remove orphaned initrd old-dkms files in /boot

2018-09-12 Thread Tiago Stürmer Daitx 
attaching cosmic patch

** Patch added: "initramfs-tools_0.131ubuntu10_debdiff_0.131ubuntu11.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1791959/+attachment/5187984/+files/initramfs-tools_0.131ubuntu10_debdiff_0.131ubuntu11.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  [SRU] remove orphaned initrd old-dkms files in /boot

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in dkms source package in Xenial:
  Invalid
Status in initramfs-tools source package in Xenial:
  New
Status in dkms source package in Bionic:
  Invalid
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing old-dkms initrd files using the
  kernel's prerm hook, but that is only executed for the kernel version
  being removed: any other old-dkms file generated prior to that would
  not be removed by the hook, taking space in the /boot directory and
  being carried forward with every upgrade.

  Note: Filling up the /boot partition causes updates and upgrades to
  fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.

  This assumes a new Xenial/Bionic schroot.

  1) create files to work as a placeholders for old dkms files (there are 4 
possible namings for these files)
  touch /boot/initrd-4.0.0-0-generic.img.old-dkms 
/boot/initramfs-4.0.0-0-generic.img.old-dkms 
/boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  * xenial:
  apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic 
linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12
  * bionic:
  apt-get install -y linux-image-4.15.0-32-generic 
linux-image-4.15.0-33-generic linux-image-4.15.0-34-generic r8168-dkms 
initramfs-tools=0.130ubuntu3.3

  3) install the headers for the old kernels (forces dkms to run)
  * xenial:
  apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
  * bionic:
  apt-get install -y linux-headers-4.15.0-32-generic 
linux-headers-4.15.0-33-generic linux-headers-4.15.0-34-generic

  4) verify that there are 7 old-dkms, the 4 manually created ones and one for 
each installed kernel
  ls -1 /boot/*.old-dkms

  5) install the initramfs-tools from proposed that contains this fix
  apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms files were removed and that 
there are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms

  7) mark kernel images and headers as automatically installed
  apt-mark auto linux-image-4*-generic linux-headers-4*-generic

  8) autoremove the older kernel
  apt-get autoremove -y

  9) verify that there are now only 2 old-dkms, one for each installed kernel
  ls -1 /boot/*.old-dkms

  
  These steps guarantees that:
  - orphaned old-dkms are correctly removed from /boot
  - non-orphaned old-dkms are kept
  - when kernel is removed the related old-dkms are also deleted

  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

  One notices *.old-dkms files being left behind still sitting on the
  disk after purging the related kernel. This can cause /boot to become
  full, and when it gets really bad, even sudo apt-get autoremove won't
  fix the problem - only deleting the old-dkms files manually solves the
  problem.

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

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

[Kernel-packages] [Bug 1791959] Re: [SRU] remove orphaned initrd old-dkms files in /boot

2018-09-12 Thread Tiago Stürmer Daitx 
attaching xenial sru patch

** Description changed:

  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.
  
  bug 1515513 dealt with removing old-dkms initrd files using the kernel's
  prerm hook, but that is only executed for the kernel version being
  removed: any other old-dkms file generated prior to that would not be
  removed by the hook, taking space in the /boot directory and being
  carried forward with every upgrade.
  
  Note: Filling up the /boot partition causes updates and upgrades to
  fail.
  
  [Test Case]
  As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.
  
- This assumes a new Xenial/Bionic/Cosmic schroot.
+ This assumes a new Xenial/Bionic schroot.
  
  1) create files to work as a placeholders for old dkms files (there are 4 
possible namings for these files)
- sudo touch /boot/initrd-4.0.0-0-generic.img.old-dkms 
/boot/initramfs-4.0.0-0-generic.img.old-dkms 
/boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms
+ touch /boot/initrd-4.0.0-0-generic.img.old-dkms 
/boot/initramfs-4.0.0-0-generic.img.old-dkms 
/boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms
  
  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  * xenial:
- sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12
+ apt-get install -y linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic 
linux-image-4.4.0-24-generic r8168-dkms initramfs-tools=0.122ubuntu8.12
  * bionic:
- TBD
- * cosmic:
- TBD
+ apt-get install -y linux-image-4.15.0-32-generic 
linux-image-4.15.0-33-generic linux-image-4.15.0-34-generic r8168-dkms 
initramfs-tools=0.130ubuntu3.3
  
  3) install the headers for the old kernels (forces dkms to run)
  * xenial:
- sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
+ apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
  * bionic:
- TBD
- * cosmic:
- TBD
+ apt-get install -y linux-headers-4.15.0-32-generic 
linux-headers-4.15.0-33-generic linux-headers-4.15.0-34-generic
  
  4) verify that there are 7 old-dkms, the 4 manually created ones and one for 
each installed kernel
- ls /boot/*.old-dkms
+ ls -1 /boot/*.old-dkms
  
- 5) install the initramfs-tools that contains this fix
- sudo apt-get install -y initramfs-tools
+ 5) install the initramfs-tools from proposed that contains this fix
+ apt-get install -y initramfs-tools
  
  6) verify that the manually created old-dkms files were removed and that 
there are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms
  
- 7) autoremove the older kernel
- sudo apt-get autoremove -y
+ 7) mark kernel images and headers as automatically installed
+ apt-mark auto linux-image-4*-generic linux-headers-4*-generic
  
- 8) verify that there are now only 2 old-dkms, one for each installed kernel
- ls /boot/*.old-dkms
+ 8) autoremove the older kernel
+ apt-get autoremove -y
+ 
+ 9) verify that there are now only 2 old-dkms, one for each installed kernel
+ ls -1 /boot/*.old-dkms
+ 
+ 
+ These steps guarantees that:
+ - orphaned old-dkms are correctly removed from /boot
+ - non-orphaned old-dkms are kept
+ - when kernel is removed the related old-dkms are also deleted
  
  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.
  
  One notices *.old-dkms files being left behind still sitting on the disk
  after purging the related kernel. This can cause /boot to become full,
  and when it gets really bad, even sudo apt-get autoremove won't fix the
  problem - only deleting the old-dkms files manually solves the problem.

** Patch added: "initramfs-tools_0.122ubuntu8.12_debdiff_0.122ubuntu8.13.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1791959/+attachment/5187982/+files/initramfs-tools_0.122ubuntu8.12_debdiff_0.122ubuntu8.13.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  [SRU] remove orphaned initrd old-dkms files in /boot

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in dkms source package in Xenial:
  Invalid
Status in initramfs-tools source package in Xenial:
  New
Status in dkms source package in Bionic:
  Invalid
Status in

[Kernel-packages] [Bug 1791959] Re: [SRU] remove orphaned initrd old-dkms files in /boot

2018-09-12 Thread Tiago Stürmer Daitx 
** Summary changed:

- remove /boot/initrd.img-*.old-dkms files left behind
+ [SRU] remove orphaned initrd old-dkms files in /boot

** Description changed:

  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.
  
- bug 1515513 dealt with removing initrd.img-.old-dkms files
- using the kernel's prerm hook, but that is only executed for the kernel
- version being removed: any other old-dkms file generated prior to that
- would not be removed by the hook, taking space in the /boot directory.
+ bug 1515513 dealt with removing old-dkms initrd files using the kernel's
+ prerm hook, but that is only executed for the kernel version being
+ removed: any other old-dkms file generated prior to that would not be
+ removed by the hook, taking space in the /boot directory and being
+ carried forward with every upgrade.
  
- Note: Filling up the /boot partition causes updates to fail.
+ Note: Filling up the /boot partition causes updates and upgrades to
+ fail.
  
  [Test Case]
  As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.
  
- This assumes a new Xenial/Bionic schroot.
+ This assumes a new Xenial/Bionic/Cosmic schroot.
  
- 1) create a file to work as a placeholder for the initrd.img old dkms file
- sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms
+ 1) create files to work as a placeholders for old dkms files (there are 4 
possible namings for these files)
+ sudo touch /boot/initrd-4.0.0-0-generic.img.old-dkms 
/boot/initramfs-4.0.0-0-generic.img.old-dkms 
/boot/initrd.img-4.0.0-0-generic.old-dkms /boot/initrd-4.0.0-0-generic.old-dkms
  
  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  * xenial:
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12
  * bionic:
+ TBD
+ * cosmic:
  TBD
  
  3) install the headers for the old kernels (forces dkms to run)
  * xenial:
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
  * bionic:
  TBD
+ * cosmic:
+ TBD
  
- 4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
+ 4) verify that there are 7 old-dkms, the 4 manually created ones and one for 
each installed kernel
  ls /boot/*.old-dkms
  
  5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools
  
- 6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
+ 6) verify that the manually created old-dkms files were removed and that 
there are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms
  
  7) autoremove the older kernel
  sudo apt-get autoremove -y
  
  8) verify that there are now only 2 old-dkms, one for each installed kernel
  ls /boot/*.old-dkms
  
  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.
  
  One notices *.old-dkms files being left behind still sitting on the disk
  after purging the related kernel. This can cause /boot to become full,
  and when it gets really bad, even sudo apt-get autoremove won't fix the
  problem - only deleting the old-dkms files manually solves the problem.

** Patch removed: 
"initramfs-tools_0.122ubuntu8.12_debdiff_0.122ubuntu8.13.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1791959/+attachment/5187601/+files/initramfs-tools_0.122ubuntu8.12_debdiff_0.122ubuntu8.13.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  [SRU] remove orphaned initrd old-dkms files in /boot

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in dkms source package in Xenial:
  Invalid
Status in initramfs-tools source package in Xenial:
  New
Status in dkms source package in Bionic:
  Invalid
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing old-dkms initrd files using the
  kernel's prerm hook, but that is only executed for the kernel version
  being removed: any other old-dkms file generated prior to that would
  not be

[Kernel-packages] [Bug 1791959] Re: remove /boot/initrd.img-*.old-dkms files left behind

2018-09-11 Thread Tiago Stürmer Daitx 
** Changed in: dkms (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: dkms (Ubuntu Bionic)
   Status: New => Invalid

** Description changed:

  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.
  
  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the kernel
  version being removed: any other old-dkms file generated prior to that
  would not be removed by the hook, taking space in the /boot directory.
  
  Note: Filling up the /boot partition causes updates to fail.
  
  [Test Case]
- As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.
+ As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.
  
- This assumes a new Xenial schroot.
+ This assumes a new Xenial/Bionic schroot.
  
  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms
  
  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
+ * xenial:
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12
+ * bionic:
+ TBD
  
  3) install the headers for the old kernels (forces dkms to run)
+ * xenial:
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
+ * bionic:
+ TBD
  
  4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
  ls /boot/*.old-dkms
  
  5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools
  
  6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms
  
  7) autoremove the older kernel
  sudo apt-get autoremove -y
  
  8) verify that there are now only 2 old-dkms, one for each installed kernel
  ls /boot/*.old-dkms
  
  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.
  
  One notices *.old-dkms files being left behind still sitting on the disk
  after purging the related kernel. This can cause /boot to become full,
  and when it gets really bad, even sudo apt-get autoremove won't fix the
  problem - only deleting the old-dkms files manually solves the problem.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  remove /boot/initrd.img-*.old-dkms files left behind

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in dkms source package in Xenial:
  Invalid
Status in initramfs-tools source package in Xenial:
  New
Status in dkms source package in Bionic:
  Invalid
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the
  kernel version being removed: any other old-dkms file generated prior
  to that would not be removed by the hook, taking space in the /boot
  directory.

  Note: Filling up the /boot partition causes updates to fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial and Bionic it is no longer 
possible to reproduce this by simply installing and updating kernels - dkms 
2.2.0.3-2ubuntu11.3/xenial or 2.3-3ubuntu1/bionic would be required for that. 
In order to replicate it an old dkms file will be created by hand.

  This assumes a new Xenial/Bionic schroot.

  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  * xenial:
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12
  * bionic:
  TBD

  3) install the headers for the old kernels (forces dkms to run)
  *

[Kernel-packages] [Bug 1791959] Re: remove /boot/initrd.img-*.old-dkms files left behind

2018-09-11 Thread Tiago Stürmer Daitx 
** Changed in: dkms (Ubuntu)
   Importance: Undecided => Medium

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

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Confirmed

** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  remove /boot/initrd.img-*.old-dkms files left behind

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the
  kernel version being removed: any other old-dkms file generated prior
  to that would not be removed by the hook, taking space in the /boot
  directory.

  Note: Filling up the /boot partition causes updates to fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.

  This assumes a new Xenial schroot.

  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12

  3) install the headers for the old kernels (forces dkms to run)
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic

  4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
  ls /boot/*.old-dkms

  5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms

  7) autoremove the older kernel
  sudo apt-get autoremove -y

  8) verify that there are now only 2 old-dkms, one for each installed kernel
  ls /boot/*.old-dkms

  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

  One notices *.old-dkms files being left behind still sitting on the
  disk after purging the related kernel. This can cause /boot to become
  full, and when it gets really bad, even sudo apt-get autoremove won't
  fix the problem - only deleting the old-dkms files manually solves the
  problem.

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

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

[Kernel-packages] [Bug 1791959] Re: remove /boot/initrd.img-*.old-dkms files left behind

2018-09-11 Thread Tiago Stürmer Daitx 
** Changed in: dkms (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  remove /boot/initrd.img-*.old-dkms files left behind

Status in dkms package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has been manually configured by a user then when a kernel is removed its 
possible for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the
  kernel version being removed: any other old-dkms file generated prior
  to that would not be removed by the hook, taking space in the /boot
  directory.

  Note: Filling up the /boot partition causes updates to fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.

  This assumes a new Xenial schroot.

  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12

  3) install the headers for the old kernels (forces dkms to run)
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic

  4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
  ls /boot/*.old-dkms

  5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms

  7) autoremove the older kernel
  sudo apt-get autoremove -y

  8) verify that there are now only 2 old-dkms, one for each installed kernel
  ls /boot/*.old-dkms

  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

  One notices *.old-dkms files being left behind still sitting on the
  disk after purging the related kernel. This can cause /boot to become
  full, and when it gets really bad, even sudo apt-get autoremove won't
  fix the problem - only deleting the old-dkms files manually solves the
  problem.

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

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

[Kernel-packages] [Bug 1791959] Re: remove /boot/initrd.img-*.old-dkms files left behind

2018-09-11 Thread Tiago Stürmer Daitx 
** Description changed:

  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has be manually configured by a user then when a kernel is removed its possible 
for an ".old-dkms" file to be left in /boot with no associated kernel.
  
  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the kernel
  version being removed: any other old-dkms file generated prior to that
  would not be removed by the hook, taking space in the /boot directory.
  
  Note: Filling up the /boot partition causes updates to fail.
- 
  
  [Test Case]
  As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.
  
  This assumes a new Xenial schroot.
  
  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms
  
  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12
  
  3) install the headers for the old kernels (forces dkms to run)
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic
  
- 4) verify that there are 4 old-dkms
+ 4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
  ls /boot/*.old-dkms
  
- 5) install the proposed initramfs-tools with this fix
+ 5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools
  
- 6) verify that the manually created old-dkms file was removed (only 3 files 
now)
+ 6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms
  
  7) autoremove the older kernel
  sudo apt-get autoremove -y
  
- 8) verify that there are now only 2 old-dkms
+ 8) verify that there are now only 2 old-dkms, one for each installed kernel
  ls /boot/*.old-dkms
- 
  
  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.
  
  One notices *.old-dkms files being left behind still sitting on the disk
  after purging the related kernel. This can cause /boot to become full,
  and when it gets really bad, even sudo apt-get autoremove won't fix the
  problem - only deleting the old-dkms files manually solves the problem.

** Tags added: xenial

** Tags added: patch

** Patch added: "initramfs-tools_0.122ubuntu8.12_debdiff_0.122ubuntu8.13.patch"
   
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1791959/+attachment/5187601/+files/initramfs-tools_0.122ubuntu8.12_debdiff_0.122ubuntu8.13.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  remove /boot/initrd.img-*.old-dkms files left behind

Status in dkms package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has be manually configured by a user then when a kernel is removed its possible 
for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the
  kernel version being removed: any other old-dkms file generated prior
  to that would not be removed by the hook, taking space in the /boot
  directory.

  Note: Filling up the /boot partition causes updates to fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.

  This assumes a new Xenial schroot.

  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12

  3) install the headers for the old kernels (forces dkms to run)
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic

  4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
  ls /boot/*.old-dkms

  5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms file

[Kernel-packages] [Bug 1791959] [NEW] remove /boot/initrd.img-*.old-dkms files left behind

2018-09-11 Thread Tiago Stürmer Daitx 
Public bug reported:

[Impact]
If a dkms package is installed which has REMAKE_INITRD or the same setting has 
be manually configured by a user then when a kernel is removed its possible for 
an ".old-dkms" file to be left in /boot with no associated kernel.

bug 1515513 dealt with removing initrd.img-.old-dkms files
using the kernel's prerm hook, but that is only executed for the kernel
version being removed: any other old-dkms file generated prior to that
would not be removed by the hook, taking space in the /boot directory.

Note: Filling up the /boot partition causes updates to fail.

[Test Case]
As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.

This assumes a new Xenial schroot.

1) create a file to work as a placeholder for the initrd.img old dkms file
sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms

2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12

3) install the headers for the old kernels (forces dkms to run)
sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic

4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
ls /boot/*.old-dkms

5) install the initramfs-tools that contains this fix
sudo apt-get install -y initramfs-tools

6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
ls /boot/*.old-dkms

7) autoremove the older kernel
sudo apt-get autoremove -y

8) verify that there are now only 2 old-dkms, one for each installed kernel
ls /boot/*.old-dkms

[Regression Potential]
Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

One notices *.old-dkms files being left behind still sitting on the disk
after purging the related kernel. This can cause /boot to become full,
and when it gets really bad, even sudo apt-get autoremove won't fix the
problem - only deleting the old-dkms files manually solves the problem.

** Affects: dkms (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1791959

Title:
  remove /boot/initrd.img-*.old-dkms files left behind

Status in dkms package in Ubuntu:
  New

Bug description:
  [Impact]
  If a dkms package is installed which has REMAKE_INITRD or the same setting 
has be manually configured by a user then when a kernel is removed its possible 
for an ".old-dkms" file to be left in /boot with no associated kernel.

  bug 1515513 dealt with removing initrd.img-.old-dkms files
  using the kernel's prerm hook, but that is only executed for the
  kernel version being removed: any other old-dkms file generated prior
  to that would not be removed by the hook, taking space in the /boot
  directory.

  Note: Filling up the /boot partition causes updates to fail.

  [Test Case]
  As the fix for bug 1515513 is available on Xenial it is no longer possible to 
reproduce this by simply installing and updating kernels (dkms 
2.2.0.3-2ubuntu11.3 would be required for that). In order to replicate it an 
old dkms file will be created by hand.

  This assumes a new Xenial schroot.

  1) create a file to work as a placeholder for the initrd.img old dkms file
  sudo touch /boot/initrd.img-4.0.0-0-generic.old-dkms

  2) install 3 old kernels, r8168-dkms, and the current initramfs-tools
  sudo apt-get install -y linux-image-4.4.0-21-generic 
linux-image-4.4.0-22-generic linux-image-4.4.0-24-generic r8168-dkms 
initramfs-tools=0.122ubuntu8.12

  3) install the headers for the old kernels (forces dkms to run)
  sudo apt-get install -y linux-headers-4.4.0-21-generic 
linux-headers-4.4.0-22-generic linux-headers-4.4.0-24-generic

  4) verify that there are 4 old-dkms, the manually created and one for each 
installed kernel
  ls /boot/*.old-dkms

  5) install the initramfs-tools that contains this fix
  sudo apt-get install -y initramfs-tools

  6) verify that the manually created old-dkms file was removed and that there 
are only 3 files now, one for each installed kernel
  ls /boot/*.old-dkms

  7) autoremove the older kernel
  sudo apt-get autoremove -y

  8) verify that there are now only 2 old-dkms, one for each installed kernel
  ls /boot/*.old-dkms

  [Regression Potential]
  Somebody out there might expect the .old-dkms file to be kept, but that seems 
like an odd expectation.

  One notices *.old-dkms files being left behind still sitting on the
  disk after purging the related kernel. This can cause /boot to

[Kernel-packages] [Bug 1699772] Re: linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regressio

2018-06-08 Thread Tiago Stürmer Daitx 
IcedTea 2.6.14 has backported a fix for the exec guard issue and will be
available in Trusty's openjdk-7 version 7u181-2.6.14-0ubuntu0.1.

The fix for OpenJDK-8 will be included in the next security update.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1699772

Title:
  linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-
  image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-
  image-3.13.0-121-generic | Regression: many user-space apps crashing

Status in LibreOffice:
  Won't Fix
Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  Incomplete
Status in linux source package in Artful:
  Incomplete
Status in linux source package in Bionic:
  Incomplete
Status in linux package in Debian:
  Fix Released

Bug description:
  Distribution: Ubuntu 16.04 x64 (Flavour: KDE Neon User Edition 5.10)

  linux-image-4.4.0-81-generic appears to contain a regression, probably
  related to the CVE-2017-1000364 fix backport / patch.

  Using this kernel, the Oracle Java browser plugin always crashes
  during stack-related actions on initialization. This means, the plugin
  completely stopped working.

  
  It works perfectly fine in linux-image-4.4.0-79-generic (vurlerable to 
CVE-2017-1000364) as well as linux-image-4.11.6-041106-generic, which also 
contains a fix for CVE-2017-1000364.


  uname -a:

  > Linux Zweiblum 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06
  UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


  I tested Oracle Java 1.8 u131 as well as 1.6 u64 in Firefox 51.0.1 as
  well as Iceweasel / Firefox/3.5.16 in a chroot.

  Using linux-image-4.4.0-81-generic it crashes in all combinations
  while with both other kernels it works.

  
  I was not able to obtain any detailed crash information from Firefox 51.0.1, 
but Iceweasel 3.5.16 crashed completely, allowing me to obtain a stack trace 
which shows the relation to stack operations performed by the plugin, even 
without proper debug symbols:

  
  > (gdb) bt full
  > #0  0x7fa06d805307 in _expand_stack_to(unsigned char*) () from 
/opt/java-8-oracle/jre/lib/amd64/server/libjvm.so
  > No symbol table info available.
  > #1  0x7fa06d8053ae in os::Linux::manually_expand_stack(JavaThread*, 
unsigned char*) ()
  >from /opt/java-8-oracle/jre/lib/amd64/server/libjvm.so
  > No symbol table info available.
  > #2  0x7fa06d80cf0b in JVM_handle_linux_signal () from 
/opt/java-8-oracle/jre/lib/amd64/server/libjvm.so
  > No symbol table info available.
  > #3  0x7fa06d802e13 in signalHandler(int, siginfo*, void*) () from 
/opt/java-8-oracle/jre/lib/amd64/server/libjvm.so
  > No symbol table info available.
  > #4  

  
  I first assumed a bug in the Java plugin, but it works fine in Linux 4.11.6.

  
  The crash will be triggered by any applet, for example the test applet at:

  * https://java.com/en/download/installed8.jsp

  
  I'm running the Ubuntu 16.04 based KDE Neon distribution which somehow 
apparently does not allow me to use apport to report this bug:

  > $ LANG= apport-cli linux-image-4.4.0-81-generic
  > 
  > *** Collecting problem information
  > 
  > The collected information can be sent to the developers to improve the
  > application. This might take a few minutes.
  > .
  > 
  > *** Problem in linux-image-4.4.0-81-generic
  > 
  > The problem cannot be reported:
  > 
  > This is not an official KDE package. Please remove any third party package 
and try again.

  If someone can tell me how to get apport working for this package, I
  can use it to collect additional information, but (unfortunately?) the
  problem should be fairly easy to reproduce...

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/1699772/+subscriptions

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

[Kernel-packages] [Bug 1699772] Re: linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression: many user-space apps crashing

2017-08-21 Thread Tiago Stürmer Daitx 
Regarding OpenJDK 8, it crashes as soon as Xss is set to (or higher
than) 1141K in a i386 JVM (32-bit).

I used the example code from bug #1700270. Please note that there is no
need to even use the java class: the program will segfault while
starting the JVM, so do remove lines 30-34 from either test_case1.c or
test_case2.c and set Xss to 1441K (or bigger).

The OpenJDK part where the stack location and size are calculated is in
os::Linux::capture_initial_stack() [1], specially
_initial_thread_stack_bottom [2].

>From GDB I was able to collect the following data from that function:
(gdb) p max_size
$1 = 1171456

Note: max_size is Xss rounded to vm_page_size(), thus 1144K [3].

(gdb) info locals
rlim = {rlim_cur = 8388608, rlim_max = 4294967295}
stack_size = 8380416
stack_start = 4294956864
p = 0xf7ffcf34 <__libc_stack_end>
stack_top = 4294959104
low = 0xfffdd000 ""
high = 0xe000 

(gdb) x p
0xf7ffcf34 <__libc_stack_end>:  0xd740
(gdb) x stack_top
0xe000: Cannot access memory at address 0xe000
(gdb) x low
0xfffdd000: 0x
(gdb) x high
0xe000: Cannot access memory at address 0xe000
(gdb) p _initial_thread_stack_size
$43 = 1171456
(gdb) x _initial_thread_stack_bottom
0xffee: 0x

Backtrace:
(gdb) bt
#0  os::Linux::capture_initial_stack (max_size=1171456) at 
./src/hotspot/src/os/linux/vm/os_linux.cpp:1272
#1  0xf7394287 in os::init_2 () at 
./src/hotspot/src/os/linux/vm/os_linux.cpp:4939
#2  0xf74ee886 in Threads::create_vm (args=0xd62c, canTryAgain=0xd5bf) 
at ./src/hotspot/src/share/vm/runtime/thread.cpp:3361
#3  0xf7151423 in JNI_CreateJavaVM (vm=0xd684, penv=0xd624, 
args=0xd62c) at ./src/hotspot/src/share/vm/prims/jni.cpp:5220
#4  0x5655561f in create_vm (jvm=0xd684) at test_case.c:16
#5  0x56555685 in main (argc=1, argv=0xd744) at test_case.c:25


That information is used by os::Linux::default_guard_size() [4] to fetch both 
'bottom' and 'size' used to indicate the start of the guard page - and it has a 
nice doc explaining the stack layout. The values from default_guard_size are in 
turn used by os::current_stack_base() [5] to calculate what should be the stack 
base.

Let me know if there's any additional information I can help with.

[1] 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l1081
[2] 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l1271
[3] 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l5010
[4] 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l714
[5] 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l745

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1699772

Title:
  linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-
  image-4.4.0-81-generic, linux-image-3.13.0-121-generic Regression:
  many user-space apps crashing

Status in LibreOffice:
  Won't Fix
Status in commons-daemon package in Ubuntu:
  Confirmed
Status in eclipse package in Ubuntu:
  Confirmed
Status in imagej package in Ubuntu:
  Confirmed
Status in libreoffice package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in octave package in Ubuntu:
  Confirmed
Status in python-jpype package in Ubuntu:
  Confirmed
Status in rustc package in Ubuntu:
  Confirmed
Status in scilab package in Ubuntu:
  Confirmed
Status in linux package in Debian:
  Confirmed

Bug description:
  Distribution: Ubuntu 16.04 x64 (Flavour: KDE Neon User Edition 5.10)

  linux-image-4.4.0-81-generic appears to contain a regression, probably
  related to the CVE-2017-1000364 fix backport / patch.

  Using this kernel, the Oracle Java browser plugin always crashes
  during stack-related actions on initialization. This means, the plugin
  completely stopped working.

  
  It works perfectly fine in linux-image-4.4.0-79-generic (vurlerable to 
CVE-2017-1000364) as well as linux-image-4.11.6-041106-generic, which also 
contains a fix for CVE-2017-1000364.


  uname -a:

  > Linux Zweiblum 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06
  UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


  I tested Oracle Java 1.8 u131 as well as 1.6 u64 in Firefox 51.0.1 as
  well as Iceweasel / Firefox/3.5.16 in a chroot.

  Using linux-image-4.4.0-81-generic it crashes in all combinations
  while with both other kernels it works.

  
  I was not able to obtain any detailed crash information from Firefox 51.0.1, 
but Iceweasel 3.5.16 crashed completely, allowing me to obtain a stack trace 
which shows the relation to stack operations performed by the plugin, even 
without proper debug symbols:

  
  > (gdb) bt full
  > #0  0x7fa06d805307 in _expand_stack_to(unsigned char*) () from 
/opt/java-8-oracle/jre/lib/amd64/server/libjvm.so

Re: [Kernel-packages] [Bug 1710653] Re: Reboot into linux 4.11.0-13 after update caused 100% cpu on btrfs-cleaner/btrfs-transaction

2017-08-14 Thread Tiago Stürmer Daitx 
On Mon, Aug 14, 2017 at 4:06 PM, Joseph Salisbury
 wrote:
> Would it be possible for you to test the latest upstream kernel? Refer
> to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
> v4.13 kernel[0].
>
> If this bug is fixed in the mainline kernel, please add the following
> tag 'kernel-fixed-upstream'.
>
> If the mainline kernel does not fix this bug, please add the tag:
> 'kernel-bug-exists-upstream'.
>
> Once testing of the upstream kernel is complete, please mark this bug as
> "Confirmed".

As I stated on a previous post, I somewhat 'fixed' the issue by
disabling quotas on the root subvolume. I enabled those again and just
rebooted, but there has been no further problems. If this ever happens
again I will try the latest upstream kernel.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1710653

Title:
  Reboot into linux 4.11.0-13 after update caused 100% cpu on btrfs-
  cleaner/btrfs-transaction

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  After doing no updates for a while I did a big update after the
  archive transitions.

  On the first boot I got btrfs-cleaner stuck at 100% CPU, sometimes
  changing place with btrfs-transaction. Atop does not report a high IO
  usage, only high CPU. The computer gets super slow with this.

  PRC |  sys   10.13s |  user   0.56s |  #proc249  | #zombie2  | #exit  
1  |
  CPU |  sys 101% |  user  5% |  irq   0%  | idle293%  | wait   
   0%  |
  cpu |  sys  83% |  user  0% |  irq   0%  | idle 17%  | cpu000 
w  0%  |
  cpu |  sys  18% |  user  2% |  irq   0%  | idle 81%  | cpu001 
w  0%  |
  cpu |  sys   0% |  user  2% |  irq   0%  | idle 98%  | cpu002 
w  0%  |
  cpu |  sys   0% |  user  2% |  irq   0%  | idle 98%  | cpu003 
w  0%  |
  CPL |  avg14.23 |  avg54.94 |  avg15   3.90  | csw14872  | intr   
10422  |
  MEM |  tot19.1G |  free   13.8G |  cache   3.0G  | buff   15.4M  | slab  
549.2M  |
  SWP |  tot 6.0G |  free6.0G || vmcom   4.6G  | vmlim  
15.5G  |
  LVM |  root |  busy  0% |  read   1  | write  0  | avio 
0.00 ms  |
  DSK |   sda |  busy  0% |  read   1  | write  0  | avio 
0.00 ms  |
  NET |  transport|  tcpi   8 |  tcpo   5  | udpi   7  | udpo   
6  |
  NET |  network  |  ipi   15 |  ipo   11  | ipfrw  0  | deliv  
   15  |
  NET |  wlan0 0% |  pcki  14 |  pcko  10  | si1 Kbps  | so
1 Kbps  |
  NET |  lo   |  pcki   2 |  pcko   2  | si0 Kbps  | so
0 Kbps  |

 PID SYSCPU USRCPU  VGROW   RGROW  RDDSK  WRDSK ST  EXC S CPUNR  CPU  CMD   
 1/1
 423  8.95s  0.00s 0K  0K16K   384K --- R 0  90%  
btrfs-transact

  Collected data with apport-cli, hopefully this is worth something.
  Will reboot and check how it goes.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-image-4.11.0-13-generic 4.11.0-13.19
  ProcVersionSignature: Ubuntu 4.11.0-13.19-generic 4.11.12
  Uname: Linux 4.11.0-13-generic x86_64
  AlsaVersion: Advanced Linux Sound Architecture Driver Version 
k4.11.0-13-generic.
  ApportVersion: 2.20.6-0ubuntu5
  Architecture: amd64
  ArecordDevices:
   Home directory not accessible: Permission denied
    List of CAPTURE Hardware Devices 
   card 1: PCH [HDA Intel PCH], device 0: CX20751/2 Analog [CX20751/2 Analog]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tdaitx 2812 F pulseaudio
   /dev/snd/controlC1:  tdaitx 2812 F pulseaudio
  Card0.Amixer.info:
   Card hw:0 'HDMI'/'HDA Intel HDMI at 0xf711c000 irq 49'
 Mixer name : 'Intel Broadwell HDMI'
 Components : 'HDA:80862808,80860101,0010'
 Controls  : 35
 Simple ctrls  : 5
  Card1.Amixer.info:
   Card hw:1 'PCH'/'HDA Intel PCH at 0xf7118000 irq 48'
 Mixer name : 'Conexant CX20751/2'
 Components : 'HDA:14f1510f,1043183d,00100100'
 Controls  : 20
 Simple ctrls  : 9
  Date: Mon Aug 14 11:50:30 2017
  HibernationDevice: #RESUME=/dev/mapper/asus_vg-swap
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 004: ID 8087:0a2a Intel Corp. 
   Bus 001 Device 003: ID 03eb:8b06 Atmel Corp. 
   Bus 001 Device 002: ID 064e:9700 Suyin Corp. Asus Integrated Webcam
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: ASUSTeK COMPUTER INC. UX303LAB
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: root=/dev/mapper/root rootflags=subvol=@,compress ro 
i915.modeset=1 video=i915 quiet splash 
cryptopts=target=root,source=UUID=36b37f43-e457-4be2-becc-4a49ca1d5b71 
fbcon=scrollback:8192k
  PulseList:
   Error: command ['pacmd', 'list']

[Kernel-packages] [Bug 1710653] Re: Reboot into linux 4.11.0-13 after update caused 100% cpu on btrfs-cleaner/btrfs-transaction

2017-08-14 Thread Tiago Stürmer Daitx 
FYI I was using 4.10.0-26 for the past days before the 400+ packages
upgrade in artful. I am using snapper to get periodic system snapshots
(pre/post apt install|remove and also hourly/daily/weekly).

The actual behavior was that a short time after boot the btrfs 
cleaner/transaction process got permanently stuck to 100% in a single CPU. 
After that the system cycled between somewhat responsive to unresponsive every 
couple/few minutes. Unresponsiveness varied: 
- a terminal command was unresponsive and only finished later on
- no screen refresh in a workspace, but I was able to cycle between workspaces
- sometimes even X got unresponsive (not even a cursor)

tl;dr I finally got it to work by disabling btrfs quotas on the root
subvolume. I did enable it afterward and had no problems so far.

For the sake of keeping some history on what I did in between, here are
the steps I tried:

1) Waited for a couple hours in case btrfs was stuck due to too many snapshots.
I am using snapper to get periodic system snapshots and I did notice that 
apt-get install/remove was getting slight slower in the past days under 
4.10.0-26. 

2) Waiting in step #1 didn't help, so I rebooted into 4.11.0-10, still
the same issue.

3) I thought about rebooting into 4.10.0-26, but then I read one report about 
btrfs snapshots changes in the kernel causing the slowdown on netgear NAS 
devices and it was not possible to downgrade due to those changes.
There was no information what kernel version was that and - since I had to 
browse from the phone - whether there were any such changes between 4.10 to 
4.11 so I decided to avoid downgrading just in case.

4) Rebooted into 4.11.0-13 again, still the same issue - as expected.

5) I had around 40 snapshots between pre/post apt installs and
hourly/daily/weekly snapshots from snapper, so I set a lower threshold
and had snapper drop the oldest ones. Didn't help.

6) On the same netgear page I saw some users reporting that disabling btrfs 
quota helped (some said it didn't).
Tried that on the root subvolume and it helped - I have various subvolumes, but 
it worked on the first try for root. I did enable quotas again to check if the 
btrfs cleaner/transaction was going to misbehave again, but everything is still 
running smooth. Didn't try rebooting yet - I will report back if rebooting 
turns out to be an issue.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1710653

Title:
  Reboot into linux 4.11.0-13 after update caused 100% cpu on btrfs-
  cleaner/btrfs-transaction

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  After doing no updates for a while I did a big update after the
  archive transitions.

  On the first boot I got btrfs-cleaner stuck at 100% CPU, sometimes
  changing place with btrfs-transaction. Atop does not report a high IO
  usage, only high CPU. The computer gets super slow with this.

  PRC |  sys   10.13s |  user   0.56s |  #proc249  | #zombie2  | #exit  
1  |
  CPU |  sys 101% |  user  5% |  irq   0%  | idle293%  | wait   
   0%  |
  cpu |  sys  83% |  user  0% |  irq   0%  | idle 17%  | cpu000 
w  0%  |
  cpu |  sys  18% |  user  2% |  irq   0%  | idle 81%  | cpu001 
w  0%  |
  cpu |  sys   0% |  user  2% |  irq   0%  | idle 98%  | cpu002 
w  0%  |
  cpu |  sys   0% |  user  2% |  irq   0%  | idle 98%  | cpu003 
w  0%  |
  CPL |  avg14.23 |  avg54.94 |  avg15   3.90  | csw14872  | intr   
10422  |
  MEM |  tot19.1G |  free   13.8G |  cache   3.0G  | buff   15.4M  | slab  
549.2M  |
  SWP |  tot 6.0G |  free6.0G || vmcom   4.6G  | vmlim  
15.5G  |
  LVM |  root |  busy  0% |  read   1  | write  0  | avio 
0.00 ms  |
  DSK |   sda |  busy  0% |  read   1  | write  0  | avio 
0.00 ms  |
  NET |  transport|  tcpi   8 |  tcpo   5  | udpi   7  | udpo   
6  |
  NET |  network  |  ipi   15 |  ipo   11  | ipfrw  0  | deliv  
   15  |
  NET |  wlan0 0% |  pcki  14 |  pcko  10  | si1 Kbps  | so
1 Kbps  |
  NET |  lo   |  pcki   2 |  pcko   2  | si0 Kbps  | so
0 Kbps  |

 PID SYSCPU USRCPU  VGROW   RGROW  RDDSK  WRDSK ST  EXC S CPUNR  CPU  CMD   
 1/1
 423  8.95s  0.00s 0K  0K16K   384K --- R 0  90%  
btrfs-transact

  Collected data with apport-cli, hopefully this is worth something.
  Will reboot and check how it goes.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-image-4.11.0-13-generic 4.11.0-13.19
  ProcVersionSignature: Ubuntu 4.11.0-13.19-generic 4.11.12
  Uname: Linux 4.11.0-13-generic x86_64
  AlsaVersion: Advanced Linux Sound Architecture Driver Version 
k4.11.0-13-generic.
  ApportVersion: 2.20.6-0ubuntu5
  Architecture: amd64
  ArecordDevices:

[Kernel-packages] [Bug 1710653] [NEW] Reboot into linux 4.11.0-13 after update caused 100% cpu on btrfs-cleaner/btrfs-transaction

2017-08-14 Thread Tiago Stürmer Daitx 
Public bug reported:

After doing no updates for a while I did a big update after the archive
transitions.

On the first boot I got btrfs-cleaner stuck at 100% CPU, sometimes
changing place with btrfs-transaction. Atop does not report a high IO
usage, only high CPU. The computer gets super slow with this.

PRC |  sys   10.13s |  user   0.56s |  #proc249  | #zombie2  | #exit
  1  |
CPU |  sys 101% |  user  5% |  irq   0%  | idle293%  | wait 
 0%  |
cpu |  sys  83% |  user  0% |  irq   0%  | idle 17%  | cpu000 w 
 0%  |
cpu |  sys  18% |  user  2% |  irq   0%  | idle 81%  | cpu001 w 
 0%  |
cpu |  sys   0% |  user  2% |  irq   0%  | idle 98%  | cpu002 w 
 0%  |
cpu |  sys   0% |  user  2% |  irq   0%  | idle 98%  | cpu003 w 
 0%  |
CPL |  avg14.23 |  avg54.94 |  avg15   3.90  | csw14872  | intr   
10422  |
MEM |  tot19.1G |  free   13.8G |  cache   3.0G  | buff   15.4M  | slab  
549.2M  |
SWP |  tot 6.0G |  free6.0G || vmcom   4.6G  | vmlim  
15.5G  |
LVM |  root |  busy  0% |  read   1  | write  0  | avio 
0.00 ms  |
DSK |   sda |  busy  0% |  read   1  | write  0  | avio 
0.00 ms  |
NET |  transport|  tcpi   8 |  tcpo   5  | udpi   7  | udpo 
  6  |
NET |  network  |  ipi   15 |  ipo   11  | ipfrw  0  | deliv
 15  |
NET |  wlan0 0% |  pcki  14 |  pcko  10  | si1 Kbps  | so1 
Kbps  |
NET |  lo   |  pcki   2 |  pcko   2  | si0 Kbps  | so0 
Kbps  |

   PID SYSCPU USRCPU  VGROW   RGROW  RDDSK  WRDSK ST  EXC S CPUNR  CPU  CMD 
   1/1
   423  8.95s  0.00s 0K  0K16K   384K --- R 0  90%  
btrfs-transact

Collected data with apport-cli, hopefully this is worth something. Will
reboot and check how it goes.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-image-4.11.0-13-generic 4.11.0-13.19
ProcVersionSignature: Ubuntu 4.11.0-13.19-generic 4.11.12
Uname: Linux 4.11.0-13-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 
k4.11.0-13-generic.
ApportVersion: 2.20.6-0ubuntu5
Architecture: amd64
ArecordDevices:
 Home directory not accessible: Permission denied
  List of CAPTURE Hardware Devices 
 card 1: PCH [HDA Intel PCH], device 0: CX20751/2 Analog [CX20751/2 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC0:  tdaitx 2812 F pulseaudio
 /dev/snd/controlC1:  tdaitx 2812 F pulseaudio
Card0.Amixer.info:
 Card hw:0 'HDMI'/'HDA Intel HDMI at 0xf711c000 irq 49'
   Mixer name   : 'Intel Broadwell HDMI'
   Components   : 'HDA:80862808,80860101,0010'
   Controls  : 35
   Simple ctrls  : 5
Card1.Amixer.info:
 Card hw:1 'PCH'/'HDA Intel PCH at 0xf7118000 irq 48'
   Mixer name   : 'Conexant CX20751/2'
   Components   : 'HDA:14f1510f,1043183d,00100100'
   Controls  : 20
   Simple ctrls  : 9
Date: Mon Aug 14 11:50:30 2017
HibernationDevice: #RESUME=/dev/mapper/asus_vg-swap
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 8087:0a2a Intel Corp. 
 Bus 001 Device 003: ID 03eb:8b06 Atmel Corp. 
 Bus 001 Device 002: ID 064e:9700 Suyin Corp. Asus Integrated Webcam
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: ASUSTeK COMPUTER INC. UX303LAB
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: root=/dev/mapper/root rootflags=subvol=@,compress ro 
i915.modeset=1 video=i915 quiet splash 
cryptopts=target=root,source=UUID=36b37f43-e457-4be2-becc-4a49ca1d5b71 
fbcon=scrollback:8192k
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not 
accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.11.0-13-generic N/A
 linux-backports-modules-4.11.0-13-generic  N/A
 linux-firmware 1.167
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/11/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX303LAB.203
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX303LAB
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrUX303LAB.203:bd12/11/2014:svnASUSTeKCOMPUTERINC.:pnUX303LAB:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX303LAB:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: UX303LAB
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug artful

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to

[Kernel-packages] [Bug 1619446] Re: mismatching headers between powerpc/ppc64el and other archs

2016-09-01 Thread Tiago Stürmer Daitx 
** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1619446

Title:
  mismatching headers between powerpc/ppc64el and other archs

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  the header files from linux-libc-dev are causing repsnapper on
  -proposed to FTBFS on powerpc/ppc64el

  I tracked it to 2 include clauses:

  #include 
  #include 

  causing the following error on powerpc/ppc64el builds:

  following errors:

src/printer/custom_baud.cpp: In function 'bool set_custom_baudrate(int, 
int)':
src/printer/custom_baud.cpp:15:19: error: aggregate 
'set_custom_baudrate(int, int)::termios2 options' has incomplete type and 
cannot be defined
   struct termios2 options;
 ^
src/printer/custom_baud.cpp:17:26: error: 'TCGETS2' was not declared in 
this scope
   if ( ioctl( device_fd, TCGETS2,  ) < 0 ) {
^
src/printer/custom_baud.cpp:27:26: error: 'TCSETS2' was not declared in 
this scope
   if ( ioctl( device_fd, TCSETS2,  ) < 0 ) {

  Please see bug #1619100 for more info.

  Comparing the powerpc/ppc64el headers to amd64 I found that they seem
  to be missing includes to other headers under asm-generic/

  If I try to add the missing asm-generic headers:

  #include 
  #include 
  #include 
  #include 

  Then the build again fails on both powerpc/ppc64el and succeeds on all
  other archs, this time the error is:

  In file included from src/printer/custom_baud.cpp:11:0:
  /usr/include/asm-generic/termbits.h:11:8: error: redefinition of ‘struct 
termios’
   struct termios {
  ^~~
  In file included from src/printer/custom_baud.cpp:9:0:
  /usr/include/powerpc-linux-gnu/asm/termbits.h:22:8: error: previous 
definition of ‘struct termios’
   struct termios {
  ^~~
  In file included from src/printer/custom_baud.cpp:11:0:
  /usr/include/asm-generic/termbits.h:31:8: error: redefinition of ‘struct 
ktermios’
   struct ktermios {
  ^~~~
  In file included from src/printer/custom_baud.cpp:9:0:
  /usr/include/powerpc-linux-gnu/asm/termbits.h:35:8: error: previous 
definition of ‘struct ktermios’
   struct ktermios {
  ^~~~

  Finally, modifying the original includes to remove the asm/termbits.h:

  #include 
  #include 
  #include 

  Allows for the repsnapper build to succeed on all arches, including
  powerpc/ppc64el. Question is: why is this even needed?

  
  linux-libc-dev packages:
  Get:10 http://ftpmaster.internal/ubuntu yakkety/main powerpc linux-libc-dev 
powerpc 4.4.0-9136.55 [818 kB]
  Get:10 http://ftpmaster.internal/ubuntu yakkety/main ppc64el linux-libc-dev 
ppc64el 4.4.0-9136.55 [818 kB]
  Get:10 http://ftpmaster.internal/ubuntu yakkety/main amd64 linux-libc-dev 
amd64 4.4.0-9136.55 [828 kB]

  Checking the headers is seems that powerpc/ppc64el are missing
  includes for asm-generics:

  $ grep -r TCGETS2 linux-libc-dev_4.4.0-9136.55_*/
  linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/ioctls.h:#define 
TCGETS2   _IOR('T', 0x2A, struct termios2)
  linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/ioctls.h:#define 
TCGETS2 _IOR('T', 0x2A, struct termios2)

  $ grep -r ioctls.h linux-libc-dev_4.4.0-9136.55_*/
  
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/x86_64-linux-gnu/asm/ioctls.h:#include
 
  linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/termios.h:#include 

  
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/termios.h:#include 

  
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/powerpc64le-linux-gnu/asm/termios.h:#include
 

  $ grep -r "termios2 {" linux-libc-dev_4.4.0-9136.55_*/ 
  linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/termbits.h:struct 
termios2 {
  
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/termbits.h:struct 
termios2 {

  $ grep -r termbits.h linux-libc-dev_4.4.0-9136.55_*/  
  
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/x86_64-linux-gnu/asm/termbits.h:#include
 
  linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/termios.h:#include 

  
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/termios.h:#include 

  
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/powerpc64le-linux-gnu/asm/termios.h:#include
 

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

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

[Kernel-packages] [Bug 1619446] [NEW] mismatching headers between powerpc/ppc64el and other archs

2016-09-01 Thread Tiago Stürmer Daitx 
Public bug reported:

the header files from linux-libc-dev are causing repsnapper on -proposed
to FTBFS on powerpc/ppc64el

I tracked it to 2 include clauses:

#include 
#include 

causing the following error on powerpc/ppc64el builds:

following errors:

  src/printer/custom_baud.cpp: In function 'bool set_custom_baudrate(int, int)':
  src/printer/custom_baud.cpp:15:19: error: aggregate 'set_custom_baudrate(int, 
int)::termios2 options' has incomplete type and cannot be defined
 struct termios2 options;
   ^
  src/printer/custom_baud.cpp:17:26: error: 'TCGETS2' was not declared in this 
scope
 if ( ioctl( device_fd, TCGETS2,  ) < 0 ) {
  ^
  src/printer/custom_baud.cpp:27:26: error: 'TCSETS2' was not declared in this 
scope
 if ( ioctl( device_fd, TCSETS2,  ) < 0 ) {

Please see bug #1619100 for more info.

Comparing the powerpc/ppc64el headers to amd64 I found that they seem to
be missing includes to other headers under asm-generic/

If I try to add the missing asm-generic headers:

#include 
#include 
#include 
#include 

Then the build again fails on both powerpc/ppc64el and succeeds on all
other archs, this time the error is:

In file included from src/printer/custom_baud.cpp:11:0:
/usr/include/asm-generic/termbits.h:11:8: error: redefinition of ‘struct 
termios’
 struct termios {
^~~
In file included from src/printer/custom_baud.cpp:9:0:
/usr/include/powerpc-linux-gnu/asm/termbits.h:22:8: error: previous definition 
of ‘struct termios’
 struct termios {
^~~
In file included from src/printer/custom_baud.cpp:11:0:
/usr/include/asm-generic/termbits.h:31:8: error: redefinition of ‘struct 
ktermios’
 struct ktermios {
^~~~
In file included from src/printer/custom_baud.cpp:9:0:
/usr/include/powerpc-linux-gnu/asm/termbits.h:35:8: error: previous definition 
of ‘struct ktermios’
 struct ktermios {
^~~~

Finally, modifying the original includes to remove the asm/termbits.h:

#include 
#include 
#include 

Allows for the repsnapper build to succeed on all arches, including
powerpc/ppc64el. Question is: why is this even needed?


linux-libc-dev packages:
Get:10 http://ftpmaster.internal/ubuntu yakkety/main powerpc linux-libc-dev 
powerpc 4.4.0-9136.55 [818 kB]
Get:10 http://ftpmaster.internal/ubuntu yakkety/main ppc64el linux-libc-dev 
ppc64el 4.4.0-9136.55 [818 kB]
Get:10 http://ftpmaster.internal/ubuntu yakkety/main amd64 linux-libc-dev amd64 
4.4.0-9136.55 [828 kB]

Checking the headers is seems that powerpc/ppc64el are missing includes
for asm-generics:

$ grep -r TCGETS2 linux-libc-dev_4.4.0-9136.55_*/
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/ioctls.h:#define 
TCGETS2 _IOR('T', 0x2A, struct termios2)
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/ioctls.h:#define 
TCGETS2   _IOR('T', 0x2A, struct termios2)

$ grep -r ioctls.h linux-libc-dev_4.4.0-9136.55_*/
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/x86_64-linux-gnu/asm/ioctls.h:#include
 
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/termios.h:#include 

linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/termios.h:#include 

linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/powerpc64le-linux-gnu/asm/termios.h:#include
 

$ grep -r "termios2 {" linux-libc-dev_4.4.0-9136.55_*/ 
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/termbits.h:struct 
termios2 {
linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/termbits.h:struct 
termios2 {

$ grep -r termbits.h linux-libc-dev_4.4.0-9136.55_*/  
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/x86_64-linux-gnu/asm/termbits.h:#include
 
linux-libc-dev_4.4.0-9136.55_amd64/usr/include/asm-generic/termios.h:#include 

linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/asm-generic/termios.h:#include 

linux-libc-dev_4.4.0-9136.55_ppc64el/usr/include/powerpc64le-linux-gnu/asm/termios.h:#include
 

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- mismatch headers between powerpc/ppc64el and other archs
+ mismatching headers between powerpc/ppc64el and other archs

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1619446

Title:
  mismatching headers between powerpc/ppc64el and other archs

Status in linux package in Ubuntu:
  New

Bug description:
  the header files from linux-libc-dev are causing repsnapper on
  -proposed to FTBFS on powerpc/ppc64el

  I tracked it to 2 include clauses:

  #include 
  #include 

  causing the following error on powerpc/ppc64el builds:

  following errors:

src/printer/custom_baud.cpp: In function 'bool set_custom_baudrate(int, 
int)':
src/printer/custom_baud.cpp:15:19: error: aggregate 
'set_custom_baudrate(int, int)::termios2 options' has incomplete type and 
cannot be defined
   struct termios2 options;

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-10-08 Thread Tiago Stürmer Daitx 
This patch also fixes LP: #1501566 and LP: #1496924.

** Patch added: "squid3_3.3.8-1ubuntu16.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1496223/+attachment/4489239/+files/squid3_3.3.8-1ubuntu16.debdiff

** Patch removed: "fixes for this bug as well as LP: #1501566 and LP: #1496924"
   
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1496223/+attachment/4480476/+files/squid3_3.3.8-1ubuntu16.debdiff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Squid:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-10-08 Thread Tiago Stürmer Daitx 
libecap3 was been deleted. I have created LP: #1504200 to handle the
gcc5 transition. After it gets sponsored it should be ok to apply the
squid debdiff.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Squid:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-10-01 Thread Tiago Stürmer Daitx 
I agree that merging the new one is the best approach and rbasak was
already working in it, for this reason I was withholding my patches (at
the time they required -D_GLIBCXX_USE_CXX11_ABI=0 since I didn't have a
libecap2 compiled for gcc5).

I decided to publish my patches for 3.3.8 just in case we don't get it
in time and also because yadi said it was better to revert libecap at
this time [1] and to avoid duplicated work since sil200 also tried to
fix it.

As yadi also commented in [1], Squid 3.3 and 3.4 require libecap 0.20
(libecap2), only squid 3.5 works with libecap 1.0 (libecap3).

[1]
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1496924/comments/7

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Squid:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-09-30 Thread Tiago Stürmer Daitx 
** Patch added: "fixes for this bug as well as LP: #1501566 and LP: #1496924"
   
https://bugs.launchpad.net/squid/+bug/1496223/+attachment/4480476/+files/squid3_3.3.8-1ubuntu16.debdiff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Squid:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-09-30 Thread Tiago Stürmer Daitx 
The squid3_3.3.8-1ubuntu16.debdiff patch requires gcc5 transition of
libecap2. I kept the lib soname and added a Conflicts: as per
https://wiki.debian.org/TransitionBestPractices

libecap2 and squid3 have been build at
https://launchpad.net/~tdaitx/+archive/ubuntu/testing/+sourcepub/5445490/+listing-archive-extra
https://launchpad.net/~tdaitx/+archive/ubuntu/testing/+sourcepub/5445498/+listing-archive-extra

** Patch added: "gcc5 transition for libecap2"
   
https://bugs.launchpad.net/squid/+bug/1496223/+attachment/4480477/+files/libecap_0.2.0-1ubuntu6.debdiff

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Squid:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-09-25 Thread Tiago Stürmer Daitx 
** Project changed: linux => squid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Squid:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-09-18 Thread Tiago Stürmer Daitx 
** Bug watch added: Squid Bugzilla #4323
   http://bugs.squid-cache.org/show_bug.cgi?id=4323

** Also affects: linux via
   http://bugs.squid-cache.org/show_bug.cgi?id=4323
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in Linux:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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

[Kernel-packages] [Bug 1496223] Re: squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

2015-09-17 Thread Tiago Stürmer Daitx 
** Also affects: glibc (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1496223

Title:
  squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New
Status in squid3 package in Ubuntu:
  New

Bug description:
  With the fix at LP: #1496924 applied, squid3 fails due to mismatching
  headers between linux-libc-dev_4.2.0-10.11 and
  libc6-dev_2.21-0ubuntu4.

  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:28:16: error: redeclaration of 'IPPROTO_IP'
     IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
  ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:42:5: note: previous declaration ' 
IPPROTO_IP'
   IPPROTO_IP = 0,/* Dummy protocol for TCP.  */
   ^
  In file included from /usr/include/linux/netfilter.h:7:0,
   from /usr/include/linux/netfilter_ipv4.h:8,
   from Intercept.cc:99:
  /usr/include/linux/in.h:30:18: error: redeclaration of 'IPPROTO_ICMP'
     IPPROTO_ICMP = 1,  /* Internet Control Message Protocol */
    ^
  In file included from /usr/include/arpa/inet.h:22:0,
   from ../../include/util.h:42,
   from ../../include/Array.h:39,
   from ../../src/comm/forward.h:4,
   from ../../src/comm/Connection.h:40,
   from Intercept.cc:34:
  /usr/include/netinet/in.h:44:5: note: previous declaration ' 
IPPROTO_ICMP'
   IPPROTO_ICMP = 1,/* Internet Control Message Protocol.  */
   ^
  

  Tried to ignore "#include linux/netfilter.h" in src/ip/Intercept.cc:99
  to no avail as build fails later on due to missing "SO_ORIGINAL_DST"
  in Intercept.cc. Removing arpa and netinet header inclusions also lead
  to eventual build failures due to missing symbols.

  So far I have found no way to have squid linking solely to either the
  kernel or libc without disabling netfilter altogether.

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

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