[Kernel-packages] [Bug 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-10-11 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 5.13.0-19.19

---
linux (5.13.0-19.19) impish; urgency=medium

  * impish/linux: 5.13.0-19.19 -proposed tracker (LP: #1946337)

  * impish:linux-aws 5.13 panic during systemd autotest (LP: #1946001)
- [Config] disable KFENCE

 -- Andrea Righi   Thu, 07 Oct 2021 11:09:51
+0200

** Changed in: linux (Ubuntu)
   Status: Triaged => Fix Released

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux-oem-5.10 source package in Bionic:
  Invalid
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Released
Status in linux-oem-5.10 source package in Focal:
  Fix Released
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Released
Status in linux-oem-5.10 source package in Hirsute:
  Invalid
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-10-04 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux-oem-5.10 - 5.10.0-1049.51

---
linux-oem-5.10 (5.10.0-1049.51) focal; urgency=medium

  * focal/linux-oem-5.10: 5.10.0-1049.50 -proposed tracker (LP:
#1944209)

  * e1000e extremly slow (LP: #1930754)
- SAUCE: e1000e: Separate TGP board type from SPT
- SAUCE: e1000e: Fixing packet loss issues on new platforms

  * CVE-2021-41073
- io_uring: ensure symmetry in handling iter types in loop_rw_iter()

 -- Chia-Lin Kao (AceLan)   Mon, 27 Sep 2021
18:33:36 +0800

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: Fix Committed => Fix Released

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux-oem-5.10 source package in Bionic:
  Invalid
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Released
Status in linux-oem-5.10 source package in Focal:
  Fix Released
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Released
Status in linux-oem-5.10 source package in Hirsute:
  Invalid
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-28 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 4.15.0-159.167

---
linux (4.15.0-159.167) bionic; urgency=medium

  * Packaging resync (LP: #1786013)
- debian/dkms-versions -- update from kernel-versions (main/2021.09.06)

  * dell300x: rsi wifi and bluetooth crash after suspend and resume
(LP: #1940488)
- Revert "rsi: Use resume_noirq for SDIO"

  *  LRMv5: switch primary version handling to kernel-versions data set
(LP: #1928921)
- [Packaging] switch to kernel-versions

  * kvm_unit_tests: emulator test fails on 4.4 / 4.15 kernel, timeout
(LP: #1932966)
- kvm: Add emulation for movups/movupd

  * memory leaking when removing a profile (LP: #1939915)
- security/apparmor/label.c: Clean code by removing redundant instructions
- apparmor: Fix memory leak of profile proxy

  * ubunut_kernel_selftests: memory-hotplug: avoid spamming logs with
dump_page() (LP: #1941829)
- selftests: memory-hotplug: avoid spamming logs with dump_page(), ratio 
limit
  hot-remove error test

  * Bionic update: upstream stable patchset 2021-08-27 (LP: #1941916)
- btrfs: mark compressed range uptodate only if all bio succeed
- regulator: rt5033: Fix n_voltages settings for BUCK and LDO
- r8152: Fix potential PM refcount imbalance
- qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union()
- net: Fix zero-copy head len calculation.
- Revert "Bluetooth: Shutdown controller after workqueues are flushed or
  cancelled"
- KVM: do not allow mapping valid but non-reference-counted pages
- Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout"
- spi: mediatek: Fix fifo transfer
- padata: validate cpumask without removed CPU during offline
- Revert "ACPICA: Fix memory leak caused by _CID repair function"
- ALSA: seq: Fix racy deletion of subscriber
- clk: stm32f4: fix post divisor setup for I2S/SAI PLLs
- omap5-board-common: remove not physically existing vdds_1v8_main fixed-
  regulator
- scsi: sr: Return correct event when media event code is 3
- media: videobuf2-core: dequeue if start_streaming fails
- net: natsemi: Fix missing pci_disable_device() in probe and remove
- nfp: update ethtool reporting of pauseframe control
- mips: Fix non-POSIX regexp
- bnx2x: fix an error code in bnx2x_nic_load()
- net: pegasus: fix uninit-value in get_interrupt_interval
- net: fec: fix use-after-free in fec_drv_remove
- net: vxge: fix use-after-free in vxge_device_unregister
- Bluetooth: defer cleanup of resources in hci_unregister_dev()
- USB: usbtmc: Fix RCU stall warning
- USB: serial: option: add Telit FD980 composition 0x1056
- USB: serial: ch341: fix character loss at high transfer rates
- USB: serial: ftdi_sio: add device ID for Auto-M3 OP-COM v2
- usb: gadget: f_hid: added GET_IDLE and SET_IDLE handlers
- usb: gadget: f_hid: fixed NULL pointer dereference
- usb: gadget: f_hid: idle uses the highest byte for duration
- usb: otg-fsm: Fix hrtimer list corruption
- scripts/tracing: fix the bug that can't parse raw_trace_func
- staging: rtl8723bs: Fix a resource leak in sd_int_dpc
- media: rtl28xxu: fix zero-length control request
- pipe: increase minimum default pipe size to 2 pages
- ext4: fix potential htree corruption when growing large_dir directories
- serial: 8250: Mask out floating 16/32-bit bus bits
- MIPS: Malta: Do not byte-swap accesses to the CBUS UART
- pcmcia: i82092: fix a null pointer dereference bug
- spi: meson-spicc: fix memory leak in meson_spicc_remove
- perf/x86/amd: Don't touch the AMD64_EVENTSEL_HOSTONLY bit inside the guest
- qmi_wwan: add network device usage statistics for qmimux devices
- libata: fix ata_pio_sector for CONFIG_HIGHMEM
- reiserfs: add check for root_inode in reiserfs_fill_super
- reiserfs: check directory items on read from disk
- alpha: Send stop IPI to send to online CPUs
- net/qla3xxx: fix schedule while atomic in ql_wait_for_drvr_lock and
  ql_adapter_reset
- USB:ehci:fix Kunpeng920 ehci hardware problem
- ppp: Fix generating ppp unit id when ifname is not specified
- ovl: prevent private clone if bind mount is not allowed
- net: xilinx_emaclite: Do not print real IOMEM pointer
- KVM: x86: accept userspace interrupt only if no event is injected
- KVM: x86/mmu: Fix per-cpu counter corruption on 32-bit builds

  * Bionic update: upstream stable patchset 2021-08-17 (LP: #1940315)
- selftest: fix build error in tools/testing/selftests/vm/userfaultfd.c
- KVM: x86: determine if an exception has an error code only when injecting
  it.
- net: split out functions related to registering inflight socket files
- [Config] updateconfigs for UNIX_SCM
- af_unix: fix garbage collect vs MSG_PEEK
- net/802/mrp: fix memleak in mrp_request_join()
- net/802/garp: fix memleak in

[Kernel-packages] [Bug 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-27 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 5.4.0-88.99

---
linux (5.4.0-88.99) focal; urgency=medium

  * focal/linux: 5.4.0-88.99 -proposed tracker (LP: #1944747)

  * Packaging resync (LP: #1786013)
- debian/dkms-versions -- update from kernel-versions (main/2021.09.06)

  * please drop virtualbox-guest-dkms virtualbox-guest-source (LP: #1933248)
- Revert "UBUNTU: [Config] Disable virtualbox dkms build"

linux (5.4.0-87.98) focal; urgency=medium

  * please drop virtualbox-guest-dkms virtualbox-guest-source (LP: #1933248)
- [Config] Disable virtualbox dkms build

  * Packaging resync (LP: #1786013)
- debian/dkms-versions -- update from kernel-versions (main/2021.09.06)

  *  LRMv5: switch primary version handling to kernel-versions data set
(LP: #1928921)
- [Packaging] switch to kernel-versions

  * disable “CONFIG_HISI_DMA” config for ubuntu version (LP: #1936771)
- Disable CONFIG_HISI_DMA
- [Config] Record hisi_dma no longer built for arm64

  * memory leaking when removing a profile (LP: #1939915)
- apparmor: Fix memory leak of profile proxy

  * CryptoExpress EP11 cards are going offline (LP: #1939618)
- s390/zcrypt: Support for CCA protected key block version 2
- s390: Replace zero-length array with flexible-array member
- s390/zcrypt: Use scnprintf() for avoiding potential buffer overflow
- s390/zcrypt: replace snprintf/sprintf with scnprintf
- s390/ap: Remove ap device suspend and resume callbacks
- s390/zcrypt: use fallthrough;
- s390/zcrypt: use kvmalloc instead of kmalloc for 256k alloc
- s390/ap: remove power management code from ap bus and drivers
- s390/ap: introduce new ap function ap_get_qdev()
- s390/zcrypt: use kzalloc
- s390/zcrypt: fix smatch warnings
- s390/zcrypt: code beautification and struct field renames
- s390/zcrypt: split ioctl function into smaller code units
- s390/ap: rename and clarify ap state machine related stuff
- s390/zcrypt: provide cex4 cca sysfs attributes for cex3
- s390/ap: rework crypto config info and default domain code
- s390/zcrypt: simplify cca_findcard2 loop code
- s390/zcrypt: remove set_fs() invocation in zcrypt device driver
- s390/ap: remove unnecessary spin_lock_init()
- s390/zcrypt: Support for CCA APKA master keys
- s390/zcrypt: introduce msg tracking in zcrypt functions
- s390/ap: split ap queue state machine state from device state
- s390/ap: add error response code field for ap queue devices
- s390/ap: add card/queue deconfig state
- s390/sclp: Add support for SCLP AP adapter config/deconfig
- s390/ap: Support AP card SCLP config and deconfig operations
- s390/ap/zcrypt: revisit ap and zcrypt error handling
- s390/zcrypt: move ap_msg param one level up the call chain
- s390/zcrypt: Introduce Failure Injection feature
- s390/zcrypt: fix wrong format specifications
- s390/ap: fix ap devices reference counting
- s390/zcrypt: return EIO when msg retry limit reached
- s390/zcrypt: fix zcard and zqueue hot-unplug memleak
- s390/ap: Fix hanging ioctl caused by wrong msg counter

  * memfd from ubuntu_kernel_selftests failed to build on B-5.4 (LP: #1926142)
- SAUCE: selftests/memfd: fix build when F_SEAL_FUTURE_WRITE is not defined

  * [SRU] Ice driver causes the kernel to crash with Ubuntu 20.04.2 with ethtool
specific register commands (LP: #1939855)
- ice: Fix bad register reads

  * ubunut_kernel_selftests: memory-hotplug: avoid spamming logs with
dump_page() (LP: #1941829)
- selftests: memory-hotplug: avoid spamming logs with dump_page(), ratio 
limit
  hot-remove error test

  * e1000e blocks the boot process when it tried to write checksum to its NVM
(LP: #1936998)
- e1000e: Do not take care about recovery NVM checksum

  * Focal update: v5.4.140 upstream stable release (LP: #1941798)
- Revert "ACPICA: Fix memory leak caused by _CID repair function"
- ALSA: seq: Fix racy deletion of subscriber
- arm64: dts: ls1028a: fix node name for the sysclk
- ARM: imx: add missing iounmap()
- ARM: imx: add missing clk_disable_unprepare()
- ARM: dts: imx6qdl-sr-som: Increase the PHY reset duration to 10ms
- ARM: dts: colibri-imx6ull: limit SDIO clock to 25MHz
- ARM: imx: fix missing 3rd argument in macro imx_mmdc_perf_init
- ARM: dts: imx: Swap M53Menlo pinctrl_power_button/pinctrl_power_out pins
- arm64: dts: armada-3720-turris-mox: remove mrvl,i2c-fast-mode
- ALSA: usb-audio: fix incorrect clock source setting
- clk: stm32f4: fix post divisor setup for I2S/SAI PLLs
- ARM: dts: am437x-l4: fix typo in can@0 node
- omap5-board-common: remove not physically existing vdds_1v8_main fixed-
  regulator
- spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay
- spi: imx: mx51-ecspi: Fix low-speed CONFIGREG delay calculation
- scsi: sr: Return correct event when media event code is

[Kernel-packages] [Bug 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-27 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux - 5.11.0-37.41

---
linux (5.11.0-37.41) hirsute; urgency=medium

  * hirsute/linux: 5.11.0-37.41 -proposed tracker (LP: #1944180)

  * CVE-2021-41073
- io_uring: ensure symmetry in handling iter types in loop_rw_iter()

  * Packaging resync (LP: #1786013)
- debian/dkms-versions -- update from kernel-versions (main/2021.09.06)

  *  LRMv5: switch primary version handling to kernel-versions data set
(LP: #1928921)
- [Packaging] switch to kernel-versions

  * disable “CONFIG_HISI_DMA” config for ubuntu version (LP: #1936771)
- Disable CONFIG_HISI_DMA
- [Config] Record hisi_dma no longer built for arm64

  * ubunut_kernel_selftests: memory-hotplug: avoid spamming logs with
dump_page() (LP: #1941829)
- selftests: memory-hotplug: avoid spamming logs with dump_page(), ratio 
limit
  hot-remove error test

  * alsa: the soundwire audio doesn't work on the Dell TGL-H machines
(LP: #1941669)
- ASoC: SOF: allow soundwire use desc->default_fw_filename
- ASoC: Intel: tgl: remove sof_fw_filename set for tgl_3_in_1_default

  * e1000e blocks the boot process when it tried to write checksum to its NVM
(LP: #1936998)
- e1000e: Do not take care about recovery NVM checksum

  * Dell XPS 17 (9710) PCI/internal sound card not detected  (LP: #1935850)
- ASoC: Intel: sof_sdw: include rt711.h for RT711 JD mode
- ASoC: Intel: sof_sdw: add quirk for Dell XPS 9710

  * mute/micmute LEDs no function on HP ProBook 650 G8 (LP: #1939473)
- ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 650 G8 Notebook PC

  *  Fix mic noise on HP ProBook 445 G8 (LP: #1940610)
- ALSA: hda/realtek: Limit mic boost on HP ProBook 445 G8

  * GPIO error logs in start and dmesg after update of kernel (LP: #1937897)
- ODM: mfd: Check AAEON BFPI version before adding device

  * External displays not working on Thinkpad T490 with ThinkPad Thunderbolt 3
Dock (LP: #1938999)
- drm/i915/ilk-glk: Fix link training on links with LTTPRs

  * Fix kernel panic caused by legacy devices on AMD platforms (LP: #1936682)
- SAUCE: iommu/amd: Keep swiotlb enabled to ensure devices with 32bit DMA
  still work

  * Hirsute update: upstream stable patchset 2021-08-30 (LP: #1942123)
- drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
- Revert "drm/i915: Propagate errors on awaiting already signaled fences"
- regulator: rtmv20: Fix wrong mask for strobe-polarity-high
- regulator: rt5033: Fix n_voltages settings for BUCK and LDO
- spi: stm32h7: fix full duplex irq handler handling
- ASoC: tlv320aic31xx: fix reversed bclk/wclk master bits
- r8152: Fix potential PM refcount imbalance
- qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union()
- ASoC: rt5682: Fix the issue of garbled recording after powerd_dbus_suspend
- net: Fix zero-copy head len calculation.
- ASoC: ti: j721e-evm: Fix unbalanced domain activity tracking during 
startup
- ASoC: ti: j721e-evm: Check for not initialized parent_clk_id
- efi/mokvar: Reserve the table only if it is in boot services data
- nvme: fix nvme_setup_command metadata trace event
- drm/amd/display: Fix comparison error in dcn21 DML
- drm/amd/display: Fix max vstartup calculation for modes with borders
- Revert "Bluetooth: Shutdown controller after workqueues are flushed or
  cancelled"
- firmware: arm_scmi: Add delayed response status check
- Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout"
- selftest/bpf: Adjust expected verifier errors
- bpf, selftests: Adjust few selftest result_unpriv outcomes
- bpf: Update selftests to reflect new error states
- bpf, selftests: Adjust few selftest outcomes wrt unreachable code
- selftest/bpf: Verifier tests for var-off access
- spi: mediatek: Fix fifo transfer
- cifs: use helpers when parsing uid/gid mount options and validate them
- cifs: add missing parsing of backupuid
- net: dsa: sja1105: parameterize the number of ports
- ASoC: Intel: boards: handle hda-dsp-common as a module
- [Config] updateconfigs for SND_SOC_INTEL_HDA_DSP_COMMON
- ASoC: Intel: boards: create sof-maxim-common module
- [Config] updateconfigs for SND_SOC_INTEL_SOF_MAXIM_COMMON
- ASoC: Intel: boards: fix xrun issue on platform with max98373
- r8152: Fix a deadlock by doubly PM resume
- Revert "ACPICA: Fix memory leak caused by _CID repair function"
- ALSA: seq: Fix racy deletion of subscriber
- bus: ti-sysc: Fix gpt12 system timer issue with reserved status
- net: xfrm: fix memory leak in xfrm_user_rcv_msg
- arm64: dts: ls1028a: fix node name for the sysclk
- ARM: imx: add missing iounmap()
- ARM: imx: add missing clk_disable_unprepare()
- ARM: dts: imx6qdl-sr-som: Increase the PHY reset duration to 10ms
- arm64: dts: ls1028: sl28: fix networking for variant 2
- ARM:

[Kernel-packages] [Bug 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-16 Thread Stefan Bader 
** Tags removed: verification-needed-bionic verification-needed-focal 
verification-needed-hirsute
** Tags added: kernel-packaging-tracking-bug

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem-5.10 source package in Bionic:
  Invalid
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Committed
Status in linux-oem-5.10 source package in Hirsute:
  Invalid
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-11 Thread AceLan Kao 
** Also affects: linux-oem-5.10 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-oem-5.10 (Ubuntu)
   Status: New => Invalid

** Changed in: linux-oem-5.10 (Ubuntu Focal)
   Status: New => Fix Committed

** Changed in: linux-oem-5.10 (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: linux-oem-5.10 (Ubuntu Hirsute)
   Status: New => Invalid

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-oem-5.10 package in Ubuntu:
  Invalid
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem-5.10 source package in Bionic:
  Invalid
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux-oem-5.10 source package in Focal:
  Fix Committed
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Committed
Status in linux-oem-5.10 source package in Hirsute:
  Invalid
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-07 Thread Ubuntu Kernel Bot 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag 'verification-needed-bionic' to 'verification-failed-
bionic'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-bionic

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Committed
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-07 Thread Ubuntu Kernel Bot 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
hirsute' to 'verification-done-hirsute'. If the problem still exists,
change the tag 'verification-needed-hirsute' to 'verification-failed-
hirsute'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-hirsute

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Committed
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-07 Thread Ubuntu Kernel Bot 
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
focal' to 'verification-done-focal'. If the problem still exists, change
the tag 'verification-needed-focal' to 'verification-failed-focal'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-focal

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

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Committed
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-02 Thread Andy Whitcroft 
** Changed in: linux (Ubuntu Hirsute)
   Importance: Undecided => High

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

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux (Ubuntu Hirsute)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: linux (Ubuntu Hirsute)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Changed in: linux-restricted-modules (Ubuntu Bionic)
   Status: New => Fix Released

** Changed in: linux-restricted-modules (Ubuntu Focal)
   Status: New => Fix Released

** Changed in: linux-restricted-modules (Ubuntu Hirsute)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Committed

-- 
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/1928921

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-restricted-modules source package in Bionic:
  Fix Released
Status in linux source package in Focal:
  Fix Committed
Status in linux-restricted-modules source package in Focal:
  Fix Released
Status in linux source package in Hirsute:
  Fix Committed
Status in linux-restricted-modules source package in Hirsute:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-09-02 Thread Kleber Sacilotto de Souza 
** Also affects: linux (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: linux-restricted-modules (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: linux-restricted-modules (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

** Also affects: linux-restricted-modules (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

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

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

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Andy Whitcroft (apw)

-- 
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/1928921

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  In Progress
Status in linux-restricted-modules source package in Bionic:
  New
Status in linux source package in Focal:
  In Progress
Status in linux-restricted-modules source package in Focal:
  New
Status in linux source package in Hirsute:
  In Progress
Status in linux-restricted-modules source package in Hirsute:
  New

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-08-04 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux-restricted-modules -
4.15.0-153.160

---
linux-restricted-modules (4.15.0-153.160) bionic; urgency=medium

  * Master version: 4.15.0-153.160

  *  LRMv5: switch primary version handling to kernel-versions data set
(LP: #1928921)
- [Packaging] convert to v5 autogen form
- [Packaging] convert to v5 autogen form -- git compatibility

  * Miscellaneous Ubuntu changes
- debian/tracking-bug -- update from master
- debian/dkms-versions -- update from kernel-versions (main/2021.06.21)

 -- Stefan Bader   Thu, 29 Jul 2021 08:29:47
+0200

** Changed in: linux-restricted-modules (Ubuntu)
   Status: In Progress => Fix Released

-- 
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/1928921

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  Fix Released

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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 1928921] Re: LRMv5: switch primary version handling to kernel-versions data set

2021-07-21 Thread Andy Whitcroft 
** Changed in: linux (Ubuntu)
   Status: Incomplete => Triaged

-- 
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/1928921

Title:
   LRMv5: switch primary version handling to kernel-versions data set

Status in linux package in Ubuntu:
  Triaged
Status in linux-restricted-modules package in Ubuntu:
  In Progress

Bug description:
  Switch fetching dkms-versions data for these packages to the kernel-
  versions dataset.

  Currently the primary dkms-versions data is committed directly to the
  primary kernel packages.  This allows this information to cascade
  reliably to all derivatives and their associated LRM packages.  But
  once the primaries are closed it is increasingly hard to change this
  data.  This makes performing an LRM-only respin very difficult as it
  differs in handling from a primary spin.

  We move the primary version dataset out of the kernel packages into a
  shared external "kernel-versions" dataset.  Each package which needs
  this data then obtains the information it needs directly, with it
  committed locally to that package at update time.

  This renders preparation of am initial (-1) spin and a later LRM-only
  respin identicle.  We simply update the shared dataset and perform a
  no-change rebuild (./update-versions) on them and they will
  automatically get the updated version information.

  We will want to update update-dkms-versions in all primary main
  packages, and introduce same into all LRM packages.  As we already run
  update-dkms-versions in the primary main packages, and are introducing
  update-dkms-versions handling to update-versions in LRM this should
  not change kernel crank proceedure.  The cycle proceedure will need a
  new step to update the shared kernel-versions dataset before cranking
  commences.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+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