Request to maintainer of Linux kernel package for arm64
I have a simple request for the maintainer of the Linux kernel package for arm64 architecture. Please include a module with a VIRTIO sound driver. The config file for the 6.1.0-23 kernel contains the following line: # CONFIG_SND_VIRTIO is not set Please change it to: CONFIG_SND_VIRTIO=m I downloaded the Debian linux kernel source package for 6.1.0 and built it after making the above change to the config file. The kernel was successfully built and the VIRTIO sound driver was now included and works great under the UTM virtualization software for MacOS on Apple Sliicon machines. Background: UTM is open source virtualization software that runs under MacOS on Apple Silicon (arm64) machines. UTM has two choices for the virtualization back-end. They are QEMU and the Apple virtualization platform. QEMU exposes sound to the virtual machine by emulating several different sound cards commonly used in PC's. The Apple virtualization platform exposes sound through the VIRTO sound device. Using the Apple virtualization platform (rather then QEMU) has various advantages. I am assuming that arm64 builds of the Linux kernel did not create a VIRTIO sound driver because of a perceived lack of need. Well, there is now a scenario where the module is needed. I have built the 6.1.0 kernel as discussed above and everything (including sournd) is working great inside a UTM virtual machine. By the way, the current release of Ubuntu Linux includes the VIRTIO sound driver. It works under UTM without any need to build your own kernel. Thank you. Tony Sarto tonysa...@comcast.net .
Bug#1023779: linux: deleting the kernel image package leaves back /lib/modules/ when a kernel package was built
Hey Diederik and Bastian On Thu, 2022-11-10 at 13:07 +0100, Bastian Blank wrote: > Those symlinks are included in linux-headers-6.0.0-3-amd64, see > https://packages.debian.org/sid/amd64/linux-headers-6.0.0-3-amd64/filelist > > Did you remove that package as well? You are both right, I have linux-headers-6.0.0-3-amd64 and totally forgotten about that. But nevertheless, shouldn't that then contain those files and dpkg not print out an error then? And indeed: $ dpkg -L linux-headers-6.0.0-3-amd64 | grep '^/lib' /lib /lib/modules /lib/modules/6.0.0-3-amd64 /lib/modules/6.0.0-3-amd64/build /lib/modules/6.0.0-3-amd64/source So I'm a bit surprised why I saw some error at all in that case. Thanks, Chris.
Bug#1023779: linux: deleting the kernel image package leaves back /lib/modules/ when a kernel package was built
On Thu, Nov 10, 2022 at 03:37:16AM +0100, Christoph Anton Mitterer wrote: > l 6.0.0-3-amd64/build 6.0.0-3-amd64/source > lrwxrwxrwx 1 calestyo calestyo 36 Nov 5 14:41 6.0.0-3-amd64/build -> > /usr/src/linux-headers-6.0.0-3-amd64 > lrwxrwxrwx 1 calestyo calestyo 37 Nov 5 14:41 6.0.0-3-amd64/source -> > /usr/src/linux-headers-6.0.0-3-common > I guess something during the build process creates these symlinks? Those symlinks are included in linux-headers-6.0.0-3-amd64, see https://packages.debian.org/sid/amd64/linux-headers-6.0.0-3-amd64/filelist Did you remove that package as well? Bastian -- There's coffee in that nebula! -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"
Bug#1023779: linux: deleting the kernel image package leaves back /lib/modules/ when a kernel package was built
On donderdag 10 november 2022 03:42:36 CET Christoph Anton Mitterer wrote: > On Thu, 2022-11-10 at 03:37 +0100, Christoph Anton Mitterer wrote: > > $ ls -al 6.0.0-3-amd64/build 6.0.0-3-amd64/source > > lrwxrwxrwx 1 calestyo calestyo 36 Nov 5 14:41 6.0.0-3-amd64/build -> > > /usr/src/linux-headers-6.0.0-3-amd64 lrwxrwxrwx 1 calestyo calestyo 37 > > Nov 5 14:41 6.0.0-3-amd64/source -> > > /usr/src/linux-headers-6.0.0-3-common > The date of the symlinks is November the 5th, however I built the > custom kernel this night. https://tracker.debian.org/news/1381949/accepted-linux-607-1-source-into-unstable/ Shows that 6.0.0-3 was accepted into Unstable on Nov 5 ... > So there must have been something else that created them (dkms? - at > least not me personally)... or is there some date mangling somewhere > for making reproducible builds? https://tracker.debian.org/pkg/linux does say "Does not build reproducibly" But in the aforemention link you can also see this line: "Date: Sat, 05 Nov 2022 14:41:22 +0100" It _could_ be a coincidence, but I doubt it. So it looks like it's not fully reproducible (yet), but using that date is a step towards it. Getting (back) to the actual subject of the bug report, it seems quite likely that you also have linux-headers-X.Y.Z installed. And IIRC, it needs/creates those 'source' and 'build' dirs/links. signature.asc Description: This is a digitally signed message part.
Bug#1023779: linux: deleting the kernel image package leaves back /lib/modules/ when a kernel package was built
Just noted, that part of what I wrote is probably bollocks. ^^ On Thu, 2022-11-10 at 03:37 +0100, Christoph Anton Mitterer wrote: > $ ls -al 6.0.0-3-amd64/build 6.0.0-3-amd64/source > lrwxrwxrwx 1 calestyo calestyo 36 Nov 5 14:41 6.0.0-3-amd64/build -> > /usr/src/linux-headers-6.0.0-3-amd64 > lrwxrwxrwx 1 calestyo calestyo 37 Nov 5 14:41 6.0.0-3-amd64/source -> > /usr/src/linux-headers-6.0.0-3-common The date of the symlinks is November the 5th, however I built the custom kernel this night. So there must have been something else that created them (dkms? - at least not me personally)... or is there some date mangling somewhere for making reproducible builds?
Bug#1023779: linux: deleting the kernel image package leaves back /lib/modules/ when a kernel package was built
Source: linux Version: 6.0.7-1 Severity: normal Hey. When I tried out some recent patch from the intel folks for i915, I built a custom kernel as described in: https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official Now before I installed the custom built debs, I wanted to make sure the Debian ones are gone completely so I purged them, causing apt to: Purging configuration files for linux-image-6.0.0-3-amd64 (6.0.7-1) ... W: Last kernel image has been removed, so removing the default symlinks rmdir: failed to remove '/lib/modules/6.0.0-3-amd64': Directory not empty $ diff -qr --no-dereference /lib/modules/6.0.0-3-amd64/ 6.0.0-3-amd64/ Only in 6.0.0-3-amd64/: build Only in 6.0.0-3-amd64/: source with the former being again a completely fresh installation of the Debian package, and the latter begin a copy from the Debian package's dir, after I had built my custom kernel and before I purged the package. l 6.0.0-3-amd64/build 6.0.0-3-amd64/source lrwxrwxrwx 1 calestyo calestyo 36 Nov 5 14:41 6.0.0-3-amd64/build -> /usr/src/linux-headers-6.0.0-3-amd64 lrwxrwxrwx 1 calestyo calestyo 37 Nov 5 14:41 6.0.0-3-amd64/source -> /usr/src/linux-headers-6.0.0-3-common I guess something during the build process creates these symlinks? So either, that shouldn't happen in the first place. Or removing the package should clean it up. I'd guess the former? Thanks, Chris. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#852749: Bug still present, patches work on modules in kernel package 4.9.0-9
Control: tags -1 + moreinfo On Fri, May 10, 2019 at 10:10:05PM -0400, AJ Milne wrote: > Realizing this thread is now a few years old: I had the same error > (transfer buffer not dma capable, coming from usb_hcd_map_urb_for_dma) > using a Line6 Pod XT through the snd-usb-pod kernel module (uses > snd-usb-line6), the machine running stock kernel package 4.9.0-9. > > Inspecting the source, it appears the message buffers are still coming from > the stack as of this kernel package. Applying Ben Hutchings' patches as of > message: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852749#10 > > ... these moving the message buffers off the stack and adding error checks > to the toneport set, doing so corrected the problem. Device is now > functional; thanks much. Can you check with more recent kernels if the issue still persist without the patches from Ben? (I.e. has the issue in meanwhile been fixed upstream directly)? Regards, Salvatore
Processed: Re: Bug#852749: Bug still present, patches work on modules in kernel package 4.9.0-9
Processing control commands: > tags -1 + moreinfo Bug #852749 [src:linux] linux-image-4.9.0-1-amd64: usb-audio-device not working since kernel 4.9.0.1 Added tag(s) moreinfo. -- 852749: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852749 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#856999: marked as done (kernel-package: does not compile Documentation/cdrom)
Your message dated Sat, 24 Apr 2021 05:26:25 -0700 (PDT)
with message-id <60840e71.1c69fb81.8103.7...@mx.google.com>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #856999,
regarding kernel-package: does not compile Documentation/cdrom
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
856999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856999
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: kernel-package
Version: 13.014+nmu1
Severity: normal
Dear Maintainers,
kernel-package suggests docbook-utils that depends on jadetex that depends on
texlive-latex-base
in order to build some (actually the only one) .tex file included in the kernel
documentation,
but the current texlive cannot build the .tex file.
$ cd linux/Documentation/cdrom
$ ls
00-INDEX Makefile cdrom-standard.tex ide-cd packet-writing.txt
$ make
...
...
[15]
! Undefined control sequence.
l.1012 ...nel~2.0. Further thanks to Heiko Ei{\sz
}feldt,
?
The use of {\sz} in cdrom-standard.tex has existed since 2007, thus the current
texlive cannot build the documentation of any recent kernel versions since then.
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=96de0e252cedffad61b3cb5e05662c591898e69a
-- System Information:
Debian Release: 8.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.4 (SMP w/18 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages kernel-package depends on:
ii bc 1.06.95-9
ii binutils 2.25-5
ii build-essential 11.7
ii bzip21.0.6-7+b3
ii dpkg-dev 1.17.27
ii file 1:5.22+15-2+deb8u3
ii gettext 0.19.3-2
ii kmod 18-3
ii lzma 9.22-2
ii po-debconf 1.0.16+nmu3
ii xmlto0.0.25-2
ii xz-utils [lzma] 5.1.1alpha+20120614-2+b3
Versions of packages kernel-package recommends:
ii cpio 2.11+dfsg-4.1+deb8u1
ii docbook-utils 0.6.14-3
ii kernel-common 13.014+nmu1
pn uboot-mkimage
Versions of packages kernel-package suggests:
ii libncurses5-dev [libncurses-dev] 5.9+20140913-1+b1
pn linux-source
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi
This bug was filed for a very old kernel or the bug is old itself
without resolution.
If you can reproduce it with
- the current version in unstable/testing
- the latest kernel from backports
please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.
Regards,
Salvatore--- End Message ---
Processed: Re: io.weight cannot be enabled in recent Debian kernel package
Processing control commands: > retitle -1 Please enable CONFIG_IOSCHED_BFQ=y Bug #946791 [linux] io.weight cannot be enabled in recent Debian kernel package Changed Bug title to 'Please enable CONFIG_IOSCHED_BFQ=y' from 'io.weight cannot be enabled in recent Debian kernel package'. -- 946791: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946791 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#946791: io.weight cannot be enabled in recent Debian kernel package
Control: retitle -1 Please enable CONFIG_IOSCHED_BFQ=y On Thu, 26 Dec 2019 23:17:13 +0900 Ryutaroh Matsumoto wrote: > Source: linux > Followup-For: Bug #946791 > Control: tags -1 + patch > > Dear Maintainer, > > I reported that IOWeight config item in systemd has no effect > on recent Debian kernels. I found the root cause. > io.weight was changed to io.bfq.weight, and recent systemd sets > values of IOWeight to io.bfq.weight as > > https://github.com/systemd/systemd/commit/2dbc45aea747f25cc1c3848fded2ec0062f96bcf > > For io.bfq.weight to appear in cgroup v2 filesystem, the bfq kernel > module must be loaded. Addition of "bfq" to /etc/initramfs- tools/modules > solved this issue. Since the systemd needs bfq module to be loaded, > changing CONFIG_IOSCHED_BFQ=m to CONFIG_IOSCHED_BFQ=y in kernel config > seems suitable. > > If the Debian kernel team considers this issue to be handled by another > package, e.g. initramfs-tools or systemd, please reassign this. > If this issue is considered not being a bug, please close this. > Fwiw, the fedora kernel in F33 uses # grep CONFIG_IOSCHED_BFQ /boot/config-5.10.22-200.fc33.x86_64 CONFIG_IOSCHED_BFQ=y I think using CONFIG_IOSCHED_BFQ=y instead of loading it via initramfs- tools makes more sense (assuming it is safe to enable). Regards, Michael signature.asc Description: This is a digitally signed message part
Request: 5.4 kernel package with the dm-crypt patch from Cloudflare?
Ignat Korchagin from Cloudflare has created a patch to improve the performance of dm-crypt considerably, see https://github.com/cloudflare/linux It seems they run this patch themself in over 200 datacenters. And he has today initiated actions to get the patch included in the upstream, see https://lkml.org/lkml/2020/6/19/1934 Perhaps the Debian-kernel maintainers would consider creating a 5.4 amd64 kernel-package with this patch implemented. Just as *linux-image-5.4.0-0.bpo.4-amd64* package in buster-backports repository. In the light of SEDs (self-encrypting drives) the latest years have turned out to be less secure than expected, dm-crypt is more relevant than ever ;-) Best regards Brian Wengel, Denmark
RE: [External] Difficulties with kernel package contributions
Thanks Ben > -Original Message- > From: Ben Hutchings > Sent: Sunday, May 17, 2020 11:50 AM > To: Mark Pearson > Cc: Pete Batard ; Debian kernel maintainers ker...@lists.debian.org> > Subject: [External] Difficulties with kernel package contributions > > I'm not cc'ing the BTS on this as this discussion is no longer specific > to one bug report. > > On Sun, 10 May 2020 16:46:47 + Mark Pearson > wrote: > [...] > > I'm hesitant to post to this thread as I don't agree with all of Pete's > > points, > > but this thread somewhat resonated, especially this last comment. > > As someone who is still learning and finding their way through the process > > myself - finding the preferred way of doing things and all the little > > details > > is hard - or at least that's my experience. The kernel handbook is OK, but > > it doesn't cover this detail in my opinion > > Yes, there's definitely room for improvement in the documentation. > > We also have documentation spread across debian/README.source, kernel- > handbook, the docs directory of kernel-team.git, and some wiki pages. > We (the kernel team) should clarify who they're for and what > information belongs where; and probably we should add more cross- > references. > > Oh, and I gave this talk: > > https://peertube.debian.social/videos/watch/3b1818f2-e44c-4cbd-b9a0- > c9465c53667a > https://www.decadent.org.uk/ben/talks/mdch2018-help-the-kernel-team.pdf > These are good - thank you. > and I'm not sure all of the information there is written down elsewhere... > > > It would be really nice to have an idiots/beginners guide to what the best > way > > is to make the maintainers life easy - I have been stumbling my way through, > > making plenty of mistakes and I'm sure I generate more headaches then I > mean > > to. > > I got the impression that you're not hugely familiar with git, so > having to deal with git and quilt at the same time is bound to be > difficult. > That's fair. I have used git but there has definitely been some learning of functionality (rebase) that I'd not come across before. Quilt is new to me but I'm getting more used to it > > Having a guide explaining how to backport a patch cleanly from kernel.org > > would be a really nice thing to have - down to best working practices with > > salsa, all the bits of info that have to be added to the patch(es), using > > dch, > > how to deal with patches that don't merge cleanly, git best practices etc. > > A fair amount of that is needed for Debian packages in general, so I > don't think we should be writing our own documentation about it but we > should refer to existing documentation. > Makes sense - I need to make more effort to go through those. I've tended to be kernel focused as it's the area where I'm more aware of patches upstream that impact our platforms that are (I hope) good to get into Debian sooner. > > I'm > > sure as a kernel maintainer you see the same mistake again and again and it > > must be infuriating. Recommended workflows would be amazing - I'm still > not > > sure what the *best* way to work on the Debian kernel is (I have steps I use > > but I had to figure them out myself and I suspect they could be better). > > I'm going to assume that you're talking specifically about backporting > features from upstream (either mainline or a maintainer tree). If the > target Debian branch is not far behind, that I would usually: > > 1. Export the upstream commits with git-format-patch-for-debian. This is a >wrapper for "git format-patch" that adds the extra patch headers, and it's >in the kernel-team.git repository. > 2. Depending on the number of patches, either: >- Import them individually, with something like: > quilt import -P features/all/foo.patch ~/linux/0001-foo.patch >- Move them into a subdirectory of debian/patches, e.g.: > cd debian/patches > mkdir features/all/foo > mv ~/linux/0*.patch features/all/foo/ > ls features/all/foo/*.patch >> series > 3. Apply each patch (quilt push) and fix up any conflicts. > 4. Build and test (to the extent possible). > > If the target Debian branch is further behind (e.g. 4.19 as Pete is > dealing with) then I would more likely: > > 1. Start a git branch from the upstream stable branch. > 2. For each upstream commit: >1. Cherry-pick it with "git cherry-pick -x" it. Fix up any > conflicts and note the change in the commit message. >2. Build the k
Difficulties with kernel package contributions
I'm not cc'ing the BTS on this as this discussion is no longer specific to one bug report. On Sun, 10 May 2020 16:46:47 + Mark Pearson wrote: [...] > I'm hesitant to post to this thread as I don't agree with all of Pete's > points, > but this thread somewhat resonated, especially this last comment. > As someone who is still learning and finding their way through the process > myself - finding the preferred way of doing things and all the little details > > is hard - or at least that's my experience. The kernel handbook is OK, but > it doesn't cover this detail in my opinion Yes, there's definitely room for improvement in the documentation. We also have documentation spread across debian/README.source, kernel- handbook, the docs directory of kernel-team.git, and some wiki pages. We (the kernel team) should clarify who they're for and what information belongs where; and probably we should add more cross- references. Oh, and I gave this talk: https://peertube.debian.social/videos/watch/3b1818f2-e44c-4cbd-b9a0-c9465c53667a https://www.decadent.org.uk/ben/talks/mdch2018-help-the-kernel-team.pdf and I'm not sure all of the information there is written down elsewhere... > It would be really nice to have an idiots/beginners guide to what the best way > is to make the maintainers life easy - I have been stumbling my way through, > making plenty of mistakes and I'm sure I generate more headaches then I mean > to. I got the impression that you're not hugely familiar with git, so having to deal with git and quilt at the same time is bound to be difficult. > Having a guide explaining how to backport a patch cleanly from kernel.org > would be a really nice thing to have - down to best working practices with > salsa, all the bits of info that have to be added to the patch(es), using > dch, > how to deal with patches that don't merge cleanly, git best practices etc. A fair amount of that is needed for Debian packages in general, so I don't think we should be writing our own documentation about it but we should refer to existing documentation. > I'm > sure as a kernel maintainer you see the same mistake again and again and it > must be infuriating. Recommended workflows would be amazing - I'm still not > sure what the *best* way to work on the Debian kernel is (I have steps I use > but I had to figure them out myself and I suspect they could be better). I'm going to assume that you're talking specifically about backporting features from upstream (either mainline or a maintainer tree). If the target Debian branch is not far behind, that I would usually: 1. Export the upstream commits with git-format-patch-for-debian. This is a wrapper for "git format-patch" that adds the extra patch headers, and it's in the kernel-team.git repository. 2. Depending on the number of patches, either: - Import them individually, with something like: quilt import -P features/all/foo.patch ~/linux/0001-foo.patch - Move them into a subdirectory of debian/patches, e.g.: cd debian/patches mkdir features/all/foo mv ~/linux/0*.patch features/all/foo/ ls features/all/foo/*.patch >> series 3. Apply each patch (quilt push) and fix up any conflicts. 4. Build and test (to the extent possible). If the target Debian branch is further behind (e.g. 4.19 as Pete is dealing with) then I would more likely: 1. Start a git branch from the upstream stable branch. 2. For each upstream commit: 1. Cherry-pick it with "git cherry-pick -x" it. Fix up any conflicts and note the change in the commit message. 2. Build the kernel, or at least the affected subsystem or driver. Fix any failure, possibly by picking additional commits it depends on. Note any changes in the commit message. 3. Export the backported commits and import into the Debian package as in the previous list. (This requires fixing up the Origin headers, and I don't currently have an easy way to do that.) > It would also be really nice to have a way to reasonably escalate things (with > a reason for the escalation) without pissing off people who are too busy to > be > swamped with nag-emails (I've been told those are a huge no-no with the > kernel Debian community). I'd be OK with a "this is not a priority I will > look at it > in N weeks" but having no insight into where you are in the queue or if you > have been missed is hard. Speaking just for myself, I don't have a queue of work. I look at bug reports as they come in, and triage them (adjust severity, reassign, close if invalid). I also make a note of those that appear to be immediately actionable (request applying a patch from upstream, or request a config change), and I deal with those in batches. I will take longer to answer bug reports that look like they require more time to investigate or review. And unfortunately, with the current size and availability of the team, there are just too many bugs to answer all of
Processed: reassigning from kernel-package to linux
Processing commands for cont...@bugs.debian.org: > reassign 878146 src:linux Bug #878146 [kernel-common] kernel-common: mac80211 module crash Bug reassigned from package 'kernel-common' to 'src:linux'. No longer marked as found in versions 4.12.0-1-amd64. Ignoring request to alter fixed versions of bug #878146 to the same values previously set > found 878146 4.12.6-1 Bug #878146 [src:linux] kernel-common: mac80211 module crash Marked as found in versions linux/4.12.6-1. > retitle 878146 linux-image-4.12.0-1-amd64: mac80211 module crash Bug #878146 [src:linux] kernel-common: mac80211 module crash Changed Bug title to 'linux-image-4.12.0-1-amd64: mac80211 module crash' from 'kernel-common: mac80211 module crash'. > End of message, stopping processing here. Please contact me if you need assistance. -- 878146: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878146 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: kernel-handbook: How to rebuild official Debian Linux kernel package with debug info disabled?
On Thu, 2020-03-05 at 18:23 +0100, Thomas Schwinge wrote:
[...]
> > ..., so I'll try again with setting 'debug-info' to 'false' both in
> > 'debian/config/defines' and 'debian/config/i386/defines'.
>
> Eh, same result/problem... ;-/
>
> I'll (later) try to figure out the right edits or commands to use, but
> would also appreciate working instructions, if anyone knows off-hand?
> Probably separate '.config' generation and alternation
> ('CONFIG_DEBUG_INFO=n', is that enough?) from the actual build?
If you already started a build, changing debian/config won't affect it.
In general, you would need to run "debian/rules debian/control", clean,
and build again.
If you have done that, then I don't understand how this is going wrong.
> > Why do some of these configuration files override the generic one
> > (without giving rationale), and/or do the kernel-handbook instructions
> > need to be updated?
We used to enable debug-info only for a few configurations; then we
changed to enable it for all configurations but didn't delete the
redundant settings. And I documented this wrongly.
I've updated the handbook (only git and the online version so far) to
correct this. I have also deleted the redundant settings, to make this
simpler in future.
Ben.
--
Ben Hutchings
Knowledge is power. France is bacon.
signature.asc
Description: This is a digitally signed message part
Re: kernel-handbook: How to rebuild official Debian Linux kernel package with debug info disabled?
Hi!
On 2020-03-05T09:35:16+0100, I wrote:
> To test something, I need to rebuild the official Debian Linux kernel
> package, so I'm following
> <https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official>
> "4.2. Rebuilding official Debian kernel packages".
>
> # apt-get --purge install build-essential fakeroot
> # apt-get --purge build-dep linux/testing
> $ apt-get source linux/testing
> $ cd linux-5.4.19/
>
> As disk space is limited, I'd like to build with debug info disabled, so
> per the instructions given I "disable debug info by changing the value of
> 'debug-info' to 'false' in 'debian/config/defines'". I ignored the "(or
> 'debian/config/*arch*/defines' in older package versions)" remark, as I
> didn't think I was building an "older package version".
>
> $ PATH=/usr/lib/ccache:$PATH
> $ fakeroot debian/rules source
> $ fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae
>
> After a few hours that exploded with "disk full", and indeed
> 'CONFIG_DEBUG_INFO=y' is set in
> 'debian/build/build_i386_none_686-pae/.config' (the file matches
> '/boot/config-5.4.0-4-686-pae').
>
> I now see:
>
> $ grep -r -B1 debug-info debian/config/
> debian/config/amd64/defines-[build]
> debian/config/amd64/defines:debug-info: true
> --
> debian/config/s390x/defines-[s390x_build]
> debian/config/s390x/defines:debug-info: true
> --
> debian/config/hppa/defines-# temporarily disable debug info: Required
> disk size exceeds our hppa buildd machines.
> debian/config/hppa/defines:debug-info: false
> --
> debian/config/defines-[build]
> debian/config/defines:debug-info: true
> --
> debian/config/arm64/defines-[build]
> debian/config/arm64/defines:debug-info: true
> --
> debian/config/i386/defines-[686-pae_build]
> debian/config/i386/defines:debug-info: true
>
> ..., so I'll try again with setting 'debug-info' to 'false' both in
> 'debian/config/defines' and 'debian/config/i386/defines'.
Eh, same result/problem... ;-/
I'll (later) try to figure out the right edits or commands to use, but
would also appreciate working instructions, if anyone knows off-hand?
Probably separate '.config' generation and alternation
('CONFIG_DEBUG_INFO=n', is that enough?) from the actual build?
> Why do some of these configuration files override the generic one
> (without giving rationale), and/or do the kernel-handbook instructions
> need to be updated?
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
kernel-handbook: How to rebuild official Debian Linux kernel package with debug info disabled?
- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter --- Begin Message --- Hi! To test something, I need to rebuild the official Debian Linux kernel package, so I'm following <https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official> "4.2. Rebuilding official Debian kernel packages". # apt-get --purge install build-essential fakeroot # apt-get --purge build-dep linux/testing $ apt-get source linux/testing $ cd linux-5.4.19/ As disk space is limited, I'd like to build with debug info disabled, so per the instructions given I "disable debug info by changing the value of 'debug-info' to 'false' in 'debian/config/defines'". I ignored the "(or 'debian/config/*arch*/defines' in older package versions)" remark, as I didn't think I was building an "older package version". $ PATH=/usr/lib/ccache:$PATH $ fakeroot debian/rules source $ fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae After a few hours that exploded with "disk full", and indeed 'CONFIG_DEBUG_INFO=y' is set in 'debian/build/build_i386_none_686-pae/.config' (the file matches '/boot/config-5.4.0-4-686-pae'). I now see: $ grep -r -B1 debug-info debian/config/ debian/config/amd64/defines-[build] debian/config/amd64/defines:debug-info: true -- debian/config/s390x/defines-[s390x_build] debian/config/s390x/defines:debug-info: true -- debian/config/hppa/defines-# temporarily disable debug info: Required disk size exceeds our hppa buildd machines. debian/config/hppa/defines:debug-info: false -- debian/config/defines-[build] debian/config/defines:debug-info: true -- debian/config/arm64/defines-[build] debian/config/arm64/defines:debug-info: true -- debian/config/i386/defines-[686-pae_build] debian/config/i386/defines:debug-info: true ..., so I'll try again with setting 'debug-info' to 'false' both in 'debian/config/defines' and 'debian/config/i386/defines'. Why do some of these configuration files override the generic one (without giving rationale), and/or do the kernel-handbook instructions need to be updated? Grüße Thomas signature.asc Description: PGP signature --- End Message ---
Bug#949910: Same failure mode continues to exist in 5.3 kernel package.
On Wed, 2020-01-29 at 07:58 -0600, Adam Thompson wrote: > Same failure mode continues to exist in 5.3 kernel package. > How best to upload 5000+ lines of dmesg here? As an attachment. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your signature. signature.asc Description: This is a digitally signed message part
Bug#949910: Same failure mode continues to exist in 5.3 kernel package.
Same failure mode continues to exist in 5.3 kernel package. How best to upload 5000+ lines of dmesg here?
Processed: Re: io.weight cannot be enabled in recent Debian kernel package
Processing control commands: > tags -1 + patch Bug #946791 [linux] io.weight cannot be enabled in recent Debian kernel package Added tag(s) patch. -- 946791: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946791 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#946791: io.weight cannot be enabled in recent Debian kernel package
Source: linux Followup-For: Bug #946791 Control: tags -1 + patch Dear Maintainer, I reported that IOWeight config item in systemd has no effect on recent Debian kernels. I found the root cause. io.weight was changed to io.bfq.weight, and recent systemd sets values of IOWeight to io.bfq.weight as https://github.com/systemd/systemd/commit/2dbc45aea747f25cc1c3848fded2ec0062f96bcf For io.bfq.weight to appear in cgroup v2 filesystem, the bfq kernel module must be loaded. Addition of "bfq" to /etc/initramfs-tools/modules solved this issue. Since the systemd needs bfq module to be loaded, changing CONFIG_IOSCHED_BFQ=m to CONFIG_IOSCHED_BFQ=y in kernel config seems suitable. If the Debian kernel team considers this issue to be handled by another package, e.g. initramfs-tools or systemd, please reassign this. If this issue is considered not being a bug, please close this. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Processed: io.weight cannot be enabled in recent Debian kernel package
Processing control commands: > reassign -1 linux 5.3.15-1 Bug #946791 [systemd] systemd: IOWeight config item does not take effect under cgroupv2 / unified hierarchy Bug reassigned from package 'systemd' to 'linux'. No longer marked as found in versions systemd/244-3. Ignoring request to alter fixed versions of bug #946791 to the same values previously set Bug #946791 [linux] systemd: IOWeight config item does not take effect under cgroupv2 / unified hierarchy There is no source info for the package 'linux' at version '5.3.15-1' with architecture '' Unable to make a source version for version '5.3.15-1' Marked as found in versions 5.3.15-1. > retitle -1 io.weight cannot be enabled in recent Debian kernel package Bug #946791 [linux] systemd: IOWeight config item does not take effect under cgroupv2 / unified hierarchy Changed Bug title to 'io.weight cannot be enabled in recent Debian kernel package' from 'systemd: IOWeight config item does not take effect under cgroupv2 / unified hierarchy'. -- 946791: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946791 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#920263: custom AMD-server kernel-package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am no longer trying to configure backported kernel-sources now, but in
fact my build-pc has the stable (buster) distribution software-set now, there
seems to be some problem about SSL, and I cannot see which option to disable
in the crypto-section of the kernel.
What does it mean anyway, is it not necessary anymore to build a
server-configured custom kernel-image, or maybe do I have to wait for a few
years, until it works out with LLVM??
> build@virtsrv:~/linux-source-4.19$ time make -j8 LOCALVERSION=-asrv deb-pkg
> UPD include/config/kernel.release
> make clean
> /bin/bash ./scripts/package/mkdebian
> TAR linux-4.19.67-asrv.tar.gz
> origversion=$(dpkg-parsechangelog -SVersion |sed 's/-[^-]*$//');\
> mv
> linux-4.19.67-asrv.tar.gz ../linux-4.19.67-asrv_${origversion}.orig.tar.gz
> dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -i.git -us -uc
> dpkg-buildpackage: info: source package linux-4.19.67-asrv
> dpkg-buildpackage: info: source version 4.19.67-asrv-1 dpkg-buildpackage:
> info: source distribution buster dpkg-buildpackage: info: source changed by
> build dpkg-buildpackage: info: host architecture amd64
> dpkg-buildpackage: warning: debian/rules is not executable; fixing that
> dpkg-source -i.git --before-build .
> fakeroot -u debian/rules clean
> rm -rf debian/*tmp debian/files
> make clean
> dpkg-source -i.git -b .
> dpkg-source: warning: no source format specified in debian/source/format,
> see dpkg-source(1) dpkg-source: info: using source format '1.0'
> dpkg-source: warning: source directory 'linux-source-4.19' is not
> - 'linux-4.19.67-asrv-4.19.67-asrv'
> dpkg-source: warning: .orig directory name linux-source-4.19.orig is not
> - (wanted linux-4.19.67-asrv-4.19.67-asrv.orig)
> dpkg-source: info: building linux-4.19.67-asrv using existing
> linux-4.19.67-asrv_4.19.67-asrv.orig.tar.gz dpkg-source: info: building
> linux-4.19.67-asrv in linux-4.19.67-asrv_4.19.67-asrv-1.diff.gz
> dpkg-source: warning: ignoring deletion of file .scmversion dpkg-source:
> warning: the diff modifies the following upstream
> files: .clang-format .cocciconfig .get_maintainer.ignore .mailmap
> CREDITS
> LICENSES/exceptions/Linux-syscall-note
> LICENSES/other/Apache-2.0
> LICENSES/other/CDDL-1.0
> LICENSES/other/GPL-1.0
> LICENSES/other/Linux-OpenIB
> LICENSES/other/MPL-1.1
> LICENSES/other/X11
> LICENSES/preferred/BSD-2-Clause
> LICENSES/preferred/BSD-3-Clause
> LICENSES/preferred/BSD-3-Clause-Clear
> LICENSES/preferred/GPL-2.0
> LICENSES/preferred/LGPL-2.0
> LICENSES/preferred/LGPL-2.1
> LICENSES/preferred/MIT
> MAINTAINERS
> README
> dpkg-source: info: use the '3.0 (quilt)' format to have separate and
> documented changes to upstream files, see dpkg-source(1) dpkg-source: info:
> building linux-4.19.67-asrv in linux-4.19.67-asrv_4.19.67-asrv-1.dsc
> dpkg-source: warning: missing information for output field
> Standards-Version debian/rules build make KERNELRELEASE=4.19.67-asrv
> ARCH=x86 KBUILD_BUILD_VERSION=1 KBUILD_SRC= WRAP
> arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP
> arch/x86/include/generated/uapi/asm/poll.h HOSTCC scripts/basic/fixdep
> SYSTBL arch/x86/include/generated/asm/syscalls_32.h
> UPD include/generated/uapi/linux/version.h
> SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
> UPD include/generated/package.h
> SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
> DESCEND objtool
> SYSTBL arch/x86/include/generated/asm/syscalls_64.h
> HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
> SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
> SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
> SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
> HOSTCC /home/build/linux-source-4.19/tools/objtool/fixdep.o
> HOSTLD /home/build/linux-source-4.19/tools/objtool/fixdep-in.o
> LINK /home/build/linux-source-4.19/tools/objtool/fixdep
> CC /home/build/linux-source-4.19/tools/objtool/exec-cmd.o
> CC /home/build/linux-source-4.19/tools/objtool/help.o
> CC /home/build/linux-source-4.19/tools/objtool/pager.o
> CC /home/build/linux-source-4.19/tools/objtool/parse-options.o
> GEN
> /home/build/linux-source-4.19/tools/objtool/arch/x86/lib/inat-tables.c
> CC /home/build/linux-source-4.19/tools/objtool/arch/x86/decode.o
> CC /home/build/linux-source-4.19/tools/objtool/run-command.o
> CC /home/build/linux-source-4.19/tools/objtool/builtin-check.o
> CC /home/build/linux-source-4.19/tools/objtool/builtin-orc.o
> CC /home/build/linux-source-4.19/tools/objtool/sigchain.o
> CC /home/build/linux-source-4.19/tools/objtool/subcmd-config.o
> LD /home/build/linux-source-4.19/tools/objtool/arch/x86/objtool-in.o
> CC /home/build/linux-source-4.19/tools/objtool/check.o
> CC /home/build/linux-source-4.19/tools/objtool/orc_gen.o
>
Bug#852749: Bug still present, patches work on modules in kernel package 4.9.0-9
Realizing this thread is now a few years old: I had the same error (transfer buffer not dma capable, coming from usb_hcd_map_urb_for_dma) using a Line6 Pod XT through the snd-usb-pod kernel module (uses snd-usb-line6), the machine running stock kernel package 4.9.0-9. Inspecting the source, it appears the message buffers are still coming from the stack as of this kernel package. Applying Ben Hutchings' patches as of message: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852749#10 ... these moving the message buffers off the stack and adding error checks to the toneport set, doing so corrected the problem. Device is now functional; thanks much. AJM
Bug#897599: A mistake in old kernel package version
Hi I made small mistake in old kernel version. Previous working properly kernel is of linux-image-4.9.0-6-amd64 with version 4.9.82-1+deb9u3. Sorry, Rolandas
Bug#886693: linux: please reinstate ia64 for the linux kernel package
Control: tag -1 - moreinfo Control: tag -1 pending I got fed up of seeing ia64 build failures so I've re-added ia64 configurations on the master branch. On Wed, 2018-01-17 at 01:20 +, Ben Hutchings wrote: > Control: tag -1 moreinfo > > On Mon, 2018-01-08 at 19:04 -0500, Jason Duerstock wrote: > > Source: linux > > Severity: normal > > Tags: patch > > > > Dear Maintainer, > > > > As you may be aware, the ia64 architecture has recently been added > > back to Debian, but now resides in Debian ports. > > The attached patch should enable the linux package to build the ia64 > > kernel again. > > > > Thanks for your time! > > This appears to be almost exactly reverting the change I made to remove > ia64 support, which is not the right thing to do. > > You need to actually review the changes that have happened in the 2.5 > years since then and update the config accordingly. In particular, the > following symbols no longer exist in Linux 4.15-rc8: > > CONFIG_BLK_CPQ_CISS_DA > CONFIG_BLK_CPQ_DA > CONFIG_CISS_SCSI_TAPE > CONFIG_I2O > CONFIG_I2O_BLOCK > CONFIG_I2O_CONFIG > CONFIG_I2O_PROC > CONFIG_I2O_SCSI > CONFIG_MMTIMER > CONFIG_SCSI_DC390T I deleted all of these from the configuration. > The commit message for the removal of CONFIG_MMTIMER upstream (commit > 07903ada96139ced48f2f893fe57a26a8fbc6043) implies that SGI SN2 systems > are no longer supported, in which case presumably the sn-modules udeb > should also be removed. I was confused about this; there evidently is still general support for SN2 systems. > Do Itanium systems typically have floppy drives? If not, delete the > "suggests: fdutils" from debian/config/ia64/defines. I've done this. > Shouldn't the "mckinley" configuration be renamed, since it's supposed > to support later processors as well? > > Does it still make sense to build an "itanium" configuration, given how > few Merced systems exist? I've left the flavour names as they are but changed their descriptions. > Also, do you have any idea whether these bugs have been fixed upstream: > > https://bugs.debian.org/679545 This seems to be unfixed (the patches weren't applied upstream). > https://bugs.debian.org/691576 This seems to have been a gcc bug that is now fixed. > https://bugs.debian.org/728706 Unknown. > If not, those should be reopened when ia64 is enabled again. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#886693: linux: please reinstate ia64 for the linux kernel package
Processing control commands: > tag -1 - moreinfo Bug #886693 [src:linux] linux: please reinstate ia64 for the linux kernel package Removed tag(s) moreinfo. > tag -1 pending Bug #886693 [src:linux] linux: please reinstate ia64 for the linux kernel package Added tag(s) pending. -- 886693: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886693 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package
Control: reassign -1 src:spl-linux 0.7.5-1 Control: forwarded -1 https://github.com/zfsonlinux/spl/issues/670 Control: retitle -1 spl-linux: Build failure with kernel 4.15 (timer updates) On Fri, Feb 23, 2018 at 06:32:37PM +0100, Bastian Blank wrote: > Hi > > On Fri, Feb 23, 2018 at 05:39:49PM +0100, Hans Freitag wrote: > > I have problems updating to kernel 4.15 due to the fact that zfs-dkms and > > spl- > > dkms won't compile automatically anymore. > > There is not much that the kernel can do if other stuff does not follow. > Please write the bug against correct package. That looks to be reported in https://github.com/zfsonlinux/spl/issues/670 and https://github.com/zfsonlinux/spl/issues/671 in the spl-linux project. Regards, Salvatore
Processed: Re: Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package
Processing control commands: > reassign -1 src:spl-linux 0.7.5-1 Bug #891235 [linux-headers-4.15.0-1-amd64] linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package Bug reassigned from package 'linux-headers-4.15.0-1-amd64' to 'src:spl-linux'. No longer marked as found in versions linux/4.15.4-1. Ignoring request to alter fixed versions of bug #891235 to the same values previously set Bug #891235 [src:spl-linux] linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package Marked as found in versions spl-linux/0.7.5-1. > forwarded -1 https://github.com/zfsonlinux/spl/issues/670 Bug #891235 [src:spl-linux] linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package Set Bug forwarded-to-address to 'https://github.com/zfsonlinux/spl/issues/670'. > retitle -1 spl-linux: Build failure with kernel 4.15 (timer updates) Bug #891235 [src:spl-linux] linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package Changed Bug title to 'spl-linux: Build failure with kernel 4.15 (timer updates)' from 'linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package'. -- 891235: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891235 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package
Hi On Fri, Feb 23, 2018 at 05:39:49PM +0100, Hans Freitag wrote: > I have problems updating to kernel 4.15 due to the fact that zfs-dkms and spl- > dkms won't compile automatically anymore. There is not much that the kernel can do if other stuff does not follow. Please write the bug against correct package. Bastian -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package
Unfortunately, I was to fast, the workaround does not work so I had to go back on 4.14, but i am sure that you can copy the stuff together. I tried a similar procedure a few weeks ago. > Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled >
Bug#891235: linux-headers-4.15.0-1-amd64: dkms modules, like zfs-dkms and spl-dkms do not compile against this kernel package
Package: linux-headers-4.15.0-1-amd64 Version: 4.15.4-1 Severity: important Dear Maintainer, I have problems updating to kernel 4.15 due to the fact that zfs-dkms and spl- dkms won't compile automatically anymore. Error Message is: Building initial module for 4.15.0-1-amd64 configure: error: *** Please make sure the kmod spl devel package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 4.15.0-1-amd64 (x86_64) Consult /var/lib/dkms/zfs/0.6.5.9/build/make.log for more information. There is a manual workaround after installing linux-headers you have to execute in /usr/src : (cd linux-kbuild-4.15/ ; tar cvfz - . )| (cd linux-headers-4.15.0-1-amd64/ ; tar xvfz - ) to make the objects available in linux-headers. It means however some manual interaction, in an otherwise automatic update procedure. regards Hans -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Processed: Re: Bug#886693: linux: please reinstate ia64 for the linux kernel package
Processing control commands: > tag -1 moreinfo Bug #886693 [src:linux] linux: please reinstate ia64 for the linux kernel package Added tag(s) moreinfo. -- 886693: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886693 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#886693: linux: please reinstate ia64 for the linux kernel package
Control: tag -1 moreinfo On Mon, 2018-01-08 at 19:04 -0500, Jason Duerstock wrote: > Source: linux > Severity: normal > Tags: patch > > Dear Maintainer, > > As you may be aware, the ia64 architecture has recently been added > back to Debian, but now resides in Debian ports. > The attached patch should enable the linux package to build the ia64 > kernel again. > > Thanks for your time! This appears to be almost exactly reverting the change I made to remove ia64 support, which is not the right thing to do. You need to actually review the changes that have happened in the 2.5 years since then and update the config accordingly. In particular, the following symbols no longer exist in Linux 4.15-rc8: CONFIG_BLK_CPQ_CISS_DA CONFIG_BLK_CPQ_DA CONFIG_CISS_SCSI_TAPE CONFIG_I2O CONFIG_I2O_BLOCK CONFIG_I2O_CONFIG CONFIG_I2O_PROC CONFIG_I2O_SCSI CONFIG_MMTIMER CONFIG_SCSI_DC390T The commit message for the removal of CONFIG_MMTIMER upstream (commit 07903ada96139ced48f2f893fe57a26a8fbc6043) implies that SGI SN2 systems are no longer supported, in which case presumably the sn-modules udeb should also be removed. Do Itanium systems typically have floppy drives? If not, delete the "suggests: fdutils" from debian/config/ia64/defines. Shouldn't the "mckinley" configuration be renamed, since it's supposed to support later processors as well? Does it still make sense to build an "itanium" configuration, given how few Merced systems exist? Also, do you have any idea whether these bugs have been fixed upstream: https://bugs.debian.org/679545 https://bugs.debian.org/691576 https://bugs.debian.org/728706 If not, those should be reopened when ia64 is enabled again. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Bug#886693: linux: please reinstate ia64 for the linux kernel package
/installer/ia64/modules/ia64/xfs-modules 2017-12-11 14:51:56.433451017 -0500 @@ -0,0 +1,2 @@ +#include + diff -u -r -N debian/installer/ia64/package-list debian/installer/ia64/package-list --- debian/installer/ia64/package-list 1969-12-31 19:00:00.0 -0500 +++ debian/installer/ia64/package-list 2017-12-11 14:51:24.069193580 -0500 @@ -0,0 +1,34 @@ +# This file is used to build up the control file. The kernel version and +# "-di" are appended to the package names. Section can be left out. So can +# architecture, which is derived from the files in the modules directory. +# It overwrites specifications from /usr/share/kernel-wedge/package-list. +# +Package: fat-modules +Priority: standard + +Package: ide-core-modules +Depends: kernel-image +Priority: standard +Description: IDE support + This package contains core IDE support for the kernel. + +Package: ide-modules +Depends: kernel-image, ide-core-modules, sn-modules +Priority: standard +Description: IDE drivers + This package contains IDE drivers for the kernel. + +Package: cdrom-core-modules +Depends: kernel-image, scsi-core-modules, ide-modules, isofs-modules + +Package: serial-modules +Depends: kernel-image, pcmcia-modules, sn-modules + +Package: sn-modules +Depends: kernel-image +Priority: extra +Description: SN modules + This package contains SN modules for Altix systems + +Package: kernel-image +Provides: efi-modules, zlib-modules diff -u -r -N debian/config/ia64/config debian/config/ia64/config --- debian/config/ia64/config 1969-12-31 19:00:00.0 -0500 +++ debian/config/ia64/config 2017-12-11 14:48:16.039695000 -0500 @@ -0,0 +1,867 @@ +## +## file: arch/ia64/Kconfig +## +CONFIG_HOTPLUG_CPU=y +CONFIG_SCHED_SMT=y +CONFIG_PERMIT_BSP_REMOVE=y +CONFIG_NODES_SHIFT=8 +CONFIG_IA64_MCA_RECOVERY=m +CONFIG_PERFMON=y +CONFIG_IA64_PALINFO=m +CONFIG_KEXEC=y +CONFIG_CRASH_DUMP=y +CONFIG_MSPEC=m + +## +## file: arch/ia64/Kconfig.debug +## +## choice: Physical memory granularity +CONFIG_IA64_GRANULE_16MB=y +# CONFIG_IA64_GRANULE_64MB is not set +## end choice +CONFIG_IA64_PRINT_HAZARDS=y +# CONFIG_DISABLE_VHPT is not set +# CONFIG_IA64_DEBUG_CMPXCHG is not set +# CONFIG_IA64_DEBUG_IRQ is not set + +## +## file: arch/ia64/hp/sim/Kconfig +## +# CONFIG_HP_SIMETH is not set +# CONFIG_HP_SIMSERIAL is not set +# CONFIG_HP_SIMSCSI is not set + +## +## file: block/partitions/Kconfig +## +CONFIG_ACORN_PARTITION=y +# CONFIG_ACORN_PARTITION_CUMANA is not set +CONFIG_ACORN_PARTITION_EESOX=y +CONFIG_ACORN_PARTITION_ICS=y +CONFIG_ACORN_PARTITION_ADFS=y +CONFIG_ACORN_PARTITION_POWERTEC=y +CONFIG_ACORN_PARTITION_RISCIX=y +CONFIG_OSF_PARTITION=y +CONFIG_AMIGA_PARTITION=y +CONFIG_ATARI_PARTITION=y +CONFIG_MAC_PARTITION=y +CONFIG_BSD_DISKLABEL=y +CONFIG_MINIX_SUBPARTITION=y +CONFIG_SOLARIS_X86_PARTITION=y +CONFIG_UNIXWARE_DISKLABEL=y +CONFIG_LDM_PARTITION=y +CONFIG_LDM_DEBUG=y +CONFIG_SGI_PARTITION=y +CONFIG_ULTRIX_PARTITION=y +CONFIG_SUN_PARTITION=y + +## +## file: drivers/acpi/Kconfig +## +CONFIG_ACPI_DOCK=y +CONFIG_ACPI_PCI_SLOT=y +CONFIG_ACPI_CONTAINER=y + +## +## file: drivers/ata/Kconfig +## +CONFIG_PATA_ALI=m +CONFIG_PATA_AMD=m +CONFIG_PATA_CMD64X=m +CONFIG_PATA_CS5520=m +CONFIG_PATA_EFAR=m +CONFIG_PATA_HPT366=m +CONFIG_PATA_HPT37X=m +CONFIG_PATA_NETCELL=m +CONFIG_PATA_NS87415=m +CONFIG_PATA_OLDPIIX=m +CONFIG_PATA_PDC2027X=m +CONFIG_PATA_PDC_OLD=m +CONFIG_PATA_SC1200=m +CONFIG_PATA_SERVERWORKS=m +CONFIG_PATA_SIL680=m +CONFIG_PATA_TRIFLEX=m +CONFIG_PATA_VIA=m +CONFIG_PATA_MPIIX=m +CONFIG_PATA_NS87410=m +CONFIG_PATA_OPTI=m +CONFIG_PATA_LEGACY=m + +## +## file: drivers/block/Kconfig +## +CONFIG_BLK_CPQ_DA=m +CONFIG_BLK_CPQ_CISS_DA=m +CONFIG_CISS_SCSI_TAPE=y +CONFIG_BLK_DEV_DAC960=m +CONFIG_BLK_DEV_UMEM=m +CONFIG_BLK_DEV_SX8=m +CONFIG_CDROM_PKTCDVD=m +CONFIG_CDROM_PKTCDVD_BUFFERS=8 +# CONFIG_CDROM_PKTCDVD_WCACHE is not set + +## +## file: drivers/char/Kconfig +## +CONFIG_SGI_SNSC=y +CONFIG_SGI_TIOCX=y +CONFIG_SGI_MBCS=m +CONFIG_PRINTER=m +# CONFIG_LP_CONSOLE is not set +CONFIG_PPDEV=m +CONFIG_DTLK=m +CONFIG_APPLICOM=m +CONFIG_RAW_DRIVER=m +CONFIG_MAX_RAW_DEVS=256 +CONFIG_HPET=y +# CONFIG_HPET_MMAP is not set +CONFIG_MMTIMER=m + +## +## file: drivers/char/agp/Kconfig +## +#. Workaround +CONFIG_AGP=y +#. Workaround +CONFIG_AGP_I460=y +#. Workaround +CONFIG_AGP_HP_ZX1=y +#. Workaround +CONFIG_AGP_SGI_TIOCA=y + +## +## file: drivers/char/ipmi/Kconfig +## +CONFIG_IPMI_HANDLER=m +# CONFIG_IPMI_PANIC_EVENT is not set +CONFIG_IPMI_DEVICE_INTERFACE=m +CONFIG_IPMI_SI=m +CONFIG_IPMI_WATCHDOG=m +CONFIG_IPMI_POWEROFF=m + +## +## file: drivers/cpufreq/Kconfig +## +CONFIG_IA64_ACPI_CPUFREQ=m + +## +## file: drivers/firmware/Kconfig +## +CONFIG_DMIID=y + +## +## file: drivers/firmware/efi/Kconfig +## +CONFIG_EFI_VARS=y + +## +## file: drivers/gpu/drm/Kconfig +## +CONFIG_DRM=m +CONFIG_DRM_TDFX=m +CONFIG_DRM_R128=m +CONFIG_DRM_RADEON=m +CONFIG_DRM_MGA=m +CONFIG_DRM_SIS=m + +## +## file: drivers/gpu/drm/i2c/Kconfig +## +CONFIG_DRM_I2C_CH7006=m +CONFIG_DRM_I2C_SIL
Re: Generating a cloud / VM kernel package
On Sun, Aug 27, 2017 at 04:16:50PM +0200, Thomas Goirand wrote: > Basically, the only thing that I want to see is a specific config for > that kernel, nothing else. Otherwise, it's going to be too much > maintenance work. Indeed, it should *not* be a different source upload, > that's too much work as well. There also may be some optimization that > we could do. > > Also, I don't see this happening without a prior agreement from the > kernel team (which means probably that Ben has to agree). On our side, > we could prepare a list of kernel modules that we do *not* want. You might consider looking at what Ubuntu did to their kernel. https://insights.ubuntu.com/2017/04/05/ubuntu-on-aws-gets-serious-performance-boost-with-aws-tuned-kernel/ suggests that they did more than just disable some modules, but it's light on details. If we're able to come up with a specific list of proposed changes, we'll probably be able to have a more fruitful conversation. noah signature.asc Description: PGP signature
Bug#873373: parallel building of kernel package seems broken
On Sun, Aug 27, 2017 at 3:14 PM, Roger Shimizu wrote: On Mon, Aug 28, 2017 at 1:09 AM, Debian Bug Tracking System wrote: > -- Forwarded message -- > From: Roger Shimizu > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Sun, 27 Aug 2017 15:14:17 +0900 > Subject: parallel building of kernel package seems broken > Package: src:linux > Version: 4.9.30-2+deb9u3 > Severity: normal > > Dear Maintainer, > > In d/changelog, I read there's support for "DEB_BUILD_OPTIONS=parallel=N", > but this setting seems broken. No actual parallel compiling is proceeded, > as I spotted by running "uptime" command several times during building. > > Is anything else need to be set, or parallel building is turned off > because some other bugs? > > -- Forwarded message -- > From: Ben Hutchings > To: 873373-d...@bugs.debian.org > Cc: > Bcc: > Date: Sun, 27 Aug 2017 17:07:12 +0100 > Subject: Re: Bug#873373: parallel building of kernel package seems broken > On Sun, 2017-08-27 at 15:14 +0900, Roger Shimizu wrote: >> Package: src:linux >> Version: 4.9.30-2+deb9u3 >> Severity: normal >> >> Dear Maintainer, >> >> In d/changelog, I read there's support for "DEB_BUILD_OPTIONS=parallel=N", >> but this setting seems broken. No actual parallel compiling is proceeded, >> as I spotted by running "uptime" command several times during building. >> >> Is anything else need to be set, or parallel building is turned off >> because some other bugs? > > It works for me and it looks like it works on the buildds. > > I use the dpkg-buildpackage -j option rather than directly setting an > environment variable. It might be that the way you start the build > replaces or deletes this variable. Thanks for this hint! Looked up manpage of dpkg-buildpackage, I find option "-j" equals adding: - DEB_BUILD_OPTIONS - MAKEFLAGS After adding MAKEFLAGS option, my script works as expected. [0] Thanks again! [0] https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage?action=diff&rev2=13&rev1=12 PS. Maybe you can also add this to the kernel handbook. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Generating a cloud / VM kernel package
On Sat, Aug 26, 2017 at 11:48:22AM +0200, Thomas Goirand wrote: > This makes the kernel binary package a lot smaller, Is the size a problem right now? > and also potentially reduces the surface of attack in case of a security > problem. What attach surface? > For example, we wouldn't need ax25, appletalk and such, which > are unfortunately automatically loaded in case matching packets are > received by the kernel, This is long gone. And apart from OpenStack you would not receive such packets ever anyway. >Most hardware drivers would also go away. Which ones? > Could we see this happening in Debian? Please let us know your thoughts. Please provide numbers what benefits such a seperate kernel package would provide. Apart from the raw size I'm not seeing it. Also the addition of a different package means that we need to track hardware requirements for the different cloud vendors pretty closely. So please define what you think should be in it and what should be not. Recently there have been several changes on what drivers are needed. EC2 started to switch to virtual functions for the network devices. Azure does this as well as option for the larges VM sizes, using large Mellanox cards. Other vendors may as well, but would you get the memo that something new it needed? Especially OpenStack runs in such diverse environments that you may find everything. Bastian -- Immortality consists largely of boredom. -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
Re: Generating a cloud / VM kernel package
On Mon, Aug 28, 2017 at 01:31:31AM +0100, Ben Hutchings wrote: > > OTOH, the list of required modules may be small enough for us to > > enumerate the ones we need for booting in /etc/initramfs-tools/modules. > > ...and then you could use MODULES=list. initramfs-tools will still > follow module static dependencies in this case. > > > I will look into this, and we'll see what it does to boot times. > > Note that the saving will mainly be in time to load the initramfs - > which on Google Compute Engine is done through BIOS disk services that > have very low performance. The mere presence of the unneeded modules > in the initramfs won't cause them to be loaded into the kernel and > shouldn't make much difference to the time taken to boot after this > point. On Amazon's HVM instance families, the initramfs is read from "local" disk, which may be network-attached or actually local. I haven't profiled load times in great depth, but my guess is that reading and uncompressing the image would be the biggest contributors to the load time. In my experimentation, uncompressing an 18 MB initramfs takes roughly 500 ms of clock time when read from network storage. That's not completely insignificant, but considering the fragility of MODULES=list or MODULES=dep, I'm not sure it's the best place to look for optimizations right now. noah signature.asc Description: PGP signature
Re: Generating a cloud / VM kernel package
On Sun, 2017-08-27 at 16:38 -0700, Noah Meyerhans wrote: > On Sat, Aug 26, 2017 at 05:18:45PM +0100, Ben Hutchings wrote: > > > Thomas, can you elaborate why you think this a good idea? Is this about > > > boot time of the kernel image? The thing I really do not want to have is > > > additional kernel source uploads to the archive for just those cloud > > > kernel images, but you already considered that a bad idea (from what I > > > read between your lines). > > > > When the Google Cloud people talked to me about slow booting, it turned > > out that reconfiguring initramfs-tools to MODULES=dep made a big > > improvement. That is likely to be a sensible configuration for most > > cloud images. > > I'm not sure that'll work for us. The image generation is not generally > expected to occur on cloud instances (though in practice it certainly > may). That discussion was about the images provided by Google, not by Debian. You're quite right that it won't be suitable for images that may be built in a different VM configuration. > OTOH, the list of required modules may be small enough for us to > enumerate the ones we need for booting in /etc/initramfs-tools/modules. ...and then you could use MODULES=list. initramfs-tools will still follow module static dependencies in this case. > I will look into this, and we'll see what it does to boot times. Note that the saving will mainly be in time to load the initramfs - which on Google Compute Engine is done through BIOS disk services that have very low performance. The mere presence of the unneeded modules in the initramfs won't cause them to be loaded into the kernel and shouldn't make much difference to the time taken to boot after this point. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Re: Generating a cloud / VM kernel package
On Sat, Aug 26, 2017 at 05:18:45PM +0100, Ben Hutchings wrote: > > Thomas, can you elaborate why you think this a good idea? Is this about > > boot time of the kernel image? The thing I really do not want to have is > > additional kernel source uploads to the archive for just those cloud > > kernel images, but you already considered that a bad idea (from what I > > read between your lines). > > When the Google Cloud people talked to me about slow booting, it turned > out that reconfiguring initramfs-tools to MODULES=dep made a big > improvement. That is likely to be a sensible configuration for most > cloud images. I'm not sure that'll work for us. The image generation is not generally expected to occur on cloud instances (though in practice it certainly may). OTOH, the list of required modules may be small enough for us to enumerate the ones we need for booting in /etc/initramfs-tools/modules. I will look into this, and we'll see what it does to boot times. noah signature.asc Description: PGP signature
Bug#873373: marked as done (parallel building of kernel package seems broken)
Your message dated Sun, 27 Aug 2017 17:07:12 +0100 with message-id <1503850032.4448.3.ca...@decadent.org.uk> and subject line Re: Bug#873373: parallel building of kernel package seems broken has caused the Debian Bug report #873373, regarding parallel building of kernel package seems broken to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 873373: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873373 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 4.9.30-2+deb9u3 Severity: normal Dear Maintainer, In d/changelog, I read there's support for "DEB_BUILD_OPTIONS=parallel=N", but this setting seems broken. No actual parallel compiling is proceeded, as I spotted by running "uptime" command several times during building. Is anything else need to be set, or parallel building is turned off because some other bugs? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 --- End Message --- --- Begin Message --- On Sun, 2017-08-27 at 15:14 +0900, Roger Shimizu wrote: > Package: src:linux > Version: 4.9.30-2+deb9u3 > Severity: normal > > Dear Maintainer, > > In d/changelog, I read there's support for "DEB_BUILD_OPTIONS=parallel=N", > but this setting seems broken. No actual parallel compiling is proceeded, > as I spotted by running "uptime" command several times during building. > > Is anything else need to be set, or parallel building is turned off > because some other bugs? It works for me and it looks like it works on the buildds. I use the dpkg-buildpackage -j option rather than directly setting an environment variable. It might be that the way you start the build replaces or deletes this variable. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part --- End Message ---
Re: Generating a cloud / VM kernel package
On 08/26/2017 12:15 PM, Martin Zobel-Helas wrote: > a) we need to decide then if we need one kernel flavour for each cloud > provider or if we can agree on a basic set of kernel compile options > that every cloud provider can use. I don't think that's needed at all. > b) most kernels Debian ships are kernels that have most drivers needed > as modules, so even though the kernel images are big, the kernel should > only load modules it really needs. Size is a concern, yes. Having too many modules slows down all sorts of things. I'm not sure, but aren't all modules added to the initrd by default? > Thomas, can you elaborate why you think this a good idea? Is this about > boot time of the kernel image? The thing I really do not want to have is > additional kernel source uploads to the archive for just those cloud > kernel images, but you already considered that a bad idea (from what I > read between your lines). Basically, the only thing that I want to see is a specific config for that kernel, nothing else. Otherwise, it's going to be too much maintenance work. Indeed, it should *not* be a different source upload, that's too much work as well. There also may be some optimization that we could do. Also, I don't see this happening without a prior agreement from the kernel team (which means probably that Ben has to agree). On our side, we could prepare a list of kernel modules that we do *not* want. Cheers, Thomas Goirand (zigo)
Bug#873373: parallel building of kernel package seems broken
Package: src:linux Version: 4.9.30-2+deb9u3 Severity: normal Dear Maintainer, In d/changelog, I read there's support for "DEB_BUILD_OPTIONS=parallel=N", but this setting seems broken. No actual parallel compiling is proceeded, as I spotted by running "uptime" command several times during building. Is anything else need to be set, or parallel building is turned off because some other bugs? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Generating a cloud / VM kernel package
On Sat, 2017-08-26 at 12:15 +0200, Martin Zobel-Helas wrote: [...] > Thomas, can you elaborate why you think this a good idea? Is this about > boot time of the kernel image? The thing I really do not want to have is > additional kernel source uploads to the archive for just those cloud > kernel images, but you already considered that a bad idea (from what I > read between your lines). When the Google Cloud people talked to me about slow booting, it turned out that reconfiguring initramfs-tools to MODULES=dep made a big improvement. That is likely to be a sensible configuration for most cloud images. Ben. -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Re: Generating a cloud / VM kernel package
On Sat, 2017-08-26 at 11:48 +0200, Thomas Goirand wrote: > Dear Kernel maintainers, > > As you may know, it's been years that Ubuntu is shipping a kernel > designed for the cloud. Such a kernel is simply a version of the kernel > that is stripped down for running on VMs. The point here is that VMs do > not need all the drivers that we typically build for the generic Debian > kernel (and if one still needs it, a fallback to the generic kernel is > always possible). This makes the kernel binary package a lot smaller, > and also potentially reduces the surface of attack in case of a security > problem. For example, we wouldn't need ax25, appletalk and such, which > are unfortunately automatically loaded in case matching packets are > received by the kernel, They aren't. Ben. > and which have been proven to be problematic in > terms of security maintenance. Most hardware drivers would also go away. > > Since it is only a mater of *removing* some modules, I don't think > adding a cloud / VM kernel flavor would be a lot of maintenance. Though > of course, as I wouldn't be the one doing it, it is not up to me to > judge the amount of work. > > Could we see this happening in Debian? Please let us know your thoughts. > > Cheers, > > Thomas Goirand (zigo) > -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Re: Generating a cloud / VM kernel package
Hi, On Sat Aug 26, 2017 at 11:48:22 +0200, Thomas Goirand wrote: > Dear Kernel maintainers, > > As you may know, it's been years that Ubuntu is shipping a kernel > designed for the cloud. Such a kernel is simply a version of the kernel > that is stripped down for running on VMs. The point here is that VMs do > not need all the drivers that we typically build for the generic Debian > kernel (and if one still needs it, a fallback to the generic kernel is > always possible). This makes the kernel binary package a lot smaller, > and also potentially reduces the surface of attack in case of a security > problem. For example, we wouldn't need ax25, appletalk and such, which > are unfortunately automatically loaded in case matching packets are > received by the kernel, and which have been proven to be problematic in > terms of security maintenance. Most hardware drivers would also go away. > > Since it is only a mater of *removing* some modules, I don't think > adding a cloud / VM kernel flavor would be a lot of maintenance. Though > of course, as I wouldn't be the one doing it, it is not up to me to > judge the amount of work. > > Could we see this happening in Debian? Please let us know your thoughts. I personaly think this is a good idea in general. Most cloud providers will probably want/love this, esp. when it comes to specifica of their environments. On the other hand I have some concerns: a) we need to decide then if we need one kernel flavour for each cloud provider or if we can agree on a basic set of kernel compile options that every cloud provider can use. b) most kernels Debian ships are kernels that have most drivers needed as modules, so even though the kernel images are big, the kernel should only load modules it really needs. Thomas, can you elaborate why you think this a good idea? Is this about boot time of the kernel image? The thing I really do not want to have is additional kernel source uploads to the archive for just those cloud kernel images, but you already considered that a bad idea (from what I read between your lines). Cheers, Martin -- Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Generating a cloud / VM kernel package
Dear Kernel maintainers, As you may know, it's been years that Ubuntu is shipping a kernel designed for the cloud. Such a kernel is simply a version of the kernel that is stripped down for running on VMs. The point here is that VMs do not need all the drivers that we typically build for the generic Debian kernel (and if one still needs it, a fallback to the generic kernel is always possible). This makes the kernel binary package a lot smaller, and also potentially reduces the surface of attack in case of a security problem. For example, we wouldn't need ax25, appletalk and such, which are unfortunately automatically loaded in case matching packets are received by the kernel, and which have been proven to be problematic in terms of security maintenance. Most hardware drivers would also go away. Since it is only a mater of *removing* some modules, I don't think adding a cloud / VM kernel flavor would be a lot of maintenance. Though of course, as I wouldn't be the one doing it, it is not up to me to judge the amount of work. Could we see this happening in Debian? Please let us know your thoughts. Cheers, Thomas Goirand (zigo)
Bug#839157: marked as done (xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, depends on kernel-VERSION, not provided by unsigned-kernel-Package)
Your message dated Thu, 22 Dec 2016 00:04:30 + with message-id <1482365070.2677.6.ca...@decadent.org.uk> and subject line Re: xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, depends on kernel-VERSION, not provided by unsigned-kernel-Package has caused the Debian Bug report #839157, regarding xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, depends on kernel-VERSION, not provided by unsigned-kernel-Package to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 839157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839157 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: xen-linux-system-4.7.0-0.bpo.1-amd64 Version: 4.7.2-1~bpo8+1 Severity: normal Tags: patch Dear Maintainer, Package depends on "linux-image-4.7 (= VERSION) - Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1), xen-system-amd64 - In jessie-backports in the moment there is just linux-image-4.7.0-0.bpo.1-amd64-unsigned which - Provides: linux-image-4.7.0-0.bpo.1-amd64 - This can not satisfy the Depends:. So Depends:-Line could be - Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1) | linux-image-4.7.0-0.bpo.1-amd64-unsigned (= 4.7.2-1~bpo8+1), xen-system-amd64 - -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (101, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xen-linux-system-4.7.0-0.bpo.1-amd64 depends on: ii linux-image-4.7.0-0.bpo.1-amd64-unsigned [linux-image-4.7.0 4.7.2-1~bpo8+1 ii xen-system-amd64 4.4.1-9+deb8u7 xen-linux-system-4.7.0-0.bpo.1-amd64 recommends no packages. xen-linux-system-4.7.0-0.bpo.1-amd64 suggests no packages. -- no debconf information --- control 2016-09-07 22:41:42.0 +0200 +++ control_20160929 2016-09-29 16:49:20.899532199 +0200 @@ -4,7 +4,7 @@ Architecture: amd64 Maintainer: Debian Kernel Team Installed-Size: 404 -Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1), xen-system-amd64 +Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1) | linux-image-4.7.0-0.bpo.1-amd64-unsigned (= 4.7.2-1~bpo8+1), xen-system-amd64 Section: metapackages Priority: optional Homepage: https://www.kernel.org/ --- End Message --- --- Begin Message --- This is not a bug. The 'unsigned' packages shouldn't get installed automatically. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#839157: xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, depends on kernel-VERSION, not provided by unsigned-kernel-Package
Package: xen-linux-system-4.7.0-0.bpo.1-amd64 Version: 4.7.2-1~bpo8+1 Severity: normal Tags: patch Dear Maintainer, Package depends on "linux-image-4.7 (= VERSION) - Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1), xen-system-amd64 - In jessie-backports in the moment there is just linux-image-4.7.0-0.bpo.1-amd64-unsigned which - Provides: linux-image-4.7.0-0.bpo.1-amd64 - This can not satisfy the Depends:. So Depends:-Line could be - Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1) | linux-image-4.7.0-0.bpo.1-amd64-unsigned (= 4.7.2-1~bpo8+1), xen-system-amd64 - -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (101, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xen-linux-system-4.7.0-0.bpo.1-amd64 depends on: ii linux-image-4.7.0-0.bpo.1-amd64-unsigned [linux-image-4.7.0 4.7.2-1~bpo8+1 ii xen-system-amd64 4.4.1-9+deb8u7 xen-linux-system-4.7.0-0.bpo.1-amd64 recommends no packages. xen-linux-system-4.7.0-0.bpo.1-amd64 suggests no packages. -- no debconf information --- control 2016-09-07 22:41:42.0 +0200 +++ control_20160929 2016-09-29 16:49:20.899532199 +0200 @@ -4,7 +4,7 @@ Architecture: amd64 Maintainer: Debian Kernel Team Installed-Size: 404 -Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1), xen-system-amd64 +Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1) | linux-image-4.7.0-0.bpo.1-amd64-unsigned (= 4.7.2-1~bpo8+1), xen-system-amd64 Section: metapackages Priority: optional Homepage: https://www.kernel.org/
Re: Possible to backport commit a03e6fe569713fb3ff0714f8fd7c8785c0ca9e22 to 4.6 kernel package?
On Sun, 2016-08-14 at 11:42 +0200, Oliver Feiler wrote: > Dear maintainers, > > would it be possible to include a03e6fe569713fb3ff0714f8fd7c8785c0ca9e22 > into the 4.6 backports kernel? [...] Not immediately, as unstable must be fixed first and then testing (via the usual propagation). The next upload to unstable will be based on Linux 4.7, which as you know has that fix. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Possible to backport commit a03e6fe569713fb3ff0714f8fd7c8785c0ca9e22 to 4.6 kernel package?
Dear maintainers, would it be possible to include a03e6fe569713fb3ff0714f8fd7c8785c0ca9e22 into the 4.6 backports kernel? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a03e6fe569713fb3ff0714f8fd7c8785c0ca9e22 Without this patch every kernel from 4.6.1 panics when deleting the ingress qdisc. Almost every firewall/traffic shaper script panics the system when reloaded. (https://www.spinics.net/lists/netdev/msg385343.html) The named commit seems to be included in 4.7-rc3. Maybe it could be pulled into 4.6? Right now the only usable backports kernel for us is linux-image-4.5.0-0.bpo.2-amd64. Kind regards, Oliver
Re: Linux 4.6 kernel package fixes
On Thu, 2016-05-05 at 00:07 +0200, Lukas Wunner wrote:
> Hi Ben,
>
> I upgraded to tag debian/4.6_rc5-1_exp1 today and wanted to provide some
> quick feedback. First of all it's good to no longer have linux-tools
> separately, thanks for doing this.
>
>
> On first build I got messages like this because config.h is only generated
> later in the build and the target install-usbip failed:
>
> sed: can't read debian/build/build-tools/tools/usb/usbip/config.h: No such
> file or directory
>
> After invoking "make -f debian/rules binary-arch" a second time the package
> was built without a hitch because config.h was now there.
Ah, I see the problem. dpkg-buildpackage invokes the build target
before binary{,-arch,-indep}, so this isn't a problem for auto-builds.
> In rules.d/tools/lib/lockdep/Makefile, ln -s fails for liblockdep.so
> because the symlink already exists. Either this should be ln -sf or
> the command is superfluous.
It's not superfluous, and it normally works. You'll have to explain
what commands you're using that cause it to fail.
> About this issue I mentioned in my Linux 4.5 e-mail in February:
>
> On Thu, Feb 25, 2016 at 09:41:28PM +, Ben Hutchings wrote:
> >
> > On Thu, 2016-02-25 at 16:16 +0100, Lukas Wunner wrote:
> > >
> > > ---
> > > a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> > > +++
> > > b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
> > > @@ -13,11 +13,7 @@ a version of the script which is directly derived from
> > > the driver.
> > >
> > > --- a/drivers/media/usb/dvb-usb/Kconfig
> > > +++ b/drivers/media/usb/dvb-usb/Kconfig
> > > -@@ -227,10 +227,10 @@ config DVB_USB_OPERA1
> > > -
> > > - config DVB_USB_AF9005
> > > - tristate "Afatech AF9005 DVB-T USB1.1 support"
> > > --depends on BROKEN
> > > +@@ -236,6 +236,7 @@ config DVB_USB_AF9005
> > > depends on DVB_USB
> > > select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> > > select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> > This file is also patched by debian/patches/debian/dfsg/drivers-media-
> > dvb-dvb-usb-af9005-disable.patch when building the 'orig' tarball.
> So this patch adds "depends on BROKEN":
> debian/patches/debian/dfsg/drivers-media-dvb-dvb-usb-af9005-disable.patch
>
> And this patch subsequently removes it:
> debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch
>
> Forgive me for being dense but what is the motivation for this?
The orig tarball should have minimal changes from the upstream source
for DFSG compliance. In the upstream source, the firmware for this
driver is built-in, so when we delete the firmware (done by
debian/patches/debian/dfsg/files-1) the driver can't be built. This
first patch, applied when building the orig tarball, documents that
breakage.
The second patch, applied when unpacking the source package, is a
bigger change that fixes the driver by adding the ability to load
firmware from a separate file.
> I keep bringing this up because it breaks my workflow: I use
> "quilt pop -a" to remove all debian patches before rebasing
> or switching branches, and later use "quilt push -a" when I
> actually want to compile. I can work around this by keeping
> a modified version of the second above-mentioned patch in
> my tree but I'm wondering if it might be possible to just not
> add the "depends on BROKEN" in the first place?
You seem to be asking us to make the orig tarball the same as the
upstream git tag.
In order to do that, we'll need to get those changes upstream in some
way. That probably will happen eventually, but it hasn't been a high
priority. Maybe you're the one to do that?
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names taken.
signature.asc
Description: This is a digitally signed message part
Linux 4.6 kernel package fixes
Hi Ben, I upgraded to tag debian/4.6_rc5-1_exp1 today and wanted to provide some quick feedback. First of all it's good to no longer have linux-tools separately, thanks for doing this. On first build I got messages like this because config.h is only generated later in the build and the target install-usbip failed: sed: can't read debian/build/build-tools/tools/usb/usbip/config.h: No such file or directory After invoking "make -f debian/rules binary-arch" a second time the package was built without a hitch because config.h was now there. In rules.d/tools/lib/lockdep/Makefile, ln -s fails for liblockdep.so because the symlink already exists. Either this should be ln -sf or the command is superfluous. About this issue I mentioned in my Linux 4.5 e-mail in February: On Thu, Feb 25, 2016 at 09:41:28PM +, Ben Hutchings wrote: > On Thu, 2016-02-25 at 16:16 +0100, Lukas Wunner wrote: > > --- > > a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch > > +++ > > b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch > > @@ -13,11 +13,7 @@ a version of the script which is directly derived from > > the driver. > > > > --- a/drivers/media/usb/dvb-usb/Kconfig > > +++ b/drivers/media/usb/dvb-usb/Kconfig > > -@@ -227,10 +227,10 @@ config DVB_USB_OPERA1 > > - > > - config DVB_USB_AF9005 > > - tristate "Afatech AF9005 DVB-T USB1.1 support" > > -- depends on BROKEN > > +@@ -236,6 +236,7 @@ config DVB_USB_AF9005 > > depends on DVB_USB > > select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT > > select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT > > This file is also patched by debian/patches/debian/dfsg/drivers-media- > dvb-dvb-usb-af9005-disable.patch when building the 'orig' tarball. So this patch adds "depends on BROKEN": debian/patches/debian/dfsg/drivers-media-dvb-dvb-usb-af9005-disable.patch And this patch subsequently removes it: debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch Forgive me for being dense but what is the motivation for this? I keep bringing this up because it breaks my workflow: I use "quilt pop -a" to remove all debian patches before rebasing or switching branches, and later use "quilt push -a" when I actually want to compile. I can work around this by keeping a modified version of the second above-mentioned patch in my tree but I'm wondering if it might be possible to just not add the "depends on BROKEN" in the first place? Thanks, Lukas
Re: Linux 4.5 kernel package fixes
On Thu, 2016-02-25 at 16:16 +0100, Lukas Wunner wrote: > Hi Ben, > > I've hit a few issues while upgrading kernel packages to 4.5 and wanted > to give a quick heads-up. > > > In linux-tools, the following is needed lest dkms packages won't build: > > diff --git a/debian/rules.d/scripts/Makefile b/debian/rules.d/scripts/Makefile > index 8d97087..b2e2cd3 100644 > --- a/debian/rules.d/scripts/Makefile > +++ b/debian/rules.d/scripts/Makefile > @@ -14,6 +14,7 @@ DATA = \ > Makefile.lib \ > Makefile.modinst \ > Makefile.modpost \ > + Makefile.ubsan \ > mkversion \ > module-common.lds > This is already pending. > In linux, drivers-media-dvb-usb-af9005-request_firmware.patch > needs a rebase, this issue has already existed since I think 4.3, > I'm wondering why noone else has hit upon it yet: > > diff --git > a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch > > b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch > index 7ab3e6b..5015ceb 100644 > --- > a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch > +++ > b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch > @@ -13,11 +13,7 @@ a version of the script which is directly derived from the > driver. > > --- a/drivers/media/usb/dvb-usb/Kconfig > +++ b/drivers/media/usb/dvb-usb/Kconfig > -@@ -227,10 +227,10 @@ config DVB_USB_OPERA1 > - > - config DVB_USB_AF9005 > - tristate "Afatech AF9005 DVB-T USB1.1 support" > --depends on BROKEN > +@@ -236,6 +236,7 @@ config DVB_USB_AF9005 > depends on DVB_USB > select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT > select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT This file is also patched by debian/patches/debian/dfsg/drivers-media- dvb-dvb-usb-af9005-disable.patch when building the 'orig' tarball. > In debian/rules.real when building the linux-image package, a few > files are supposed to be copied from debian/templates/image.bug/, > but for some reason the dh_install command doesn't do anything. > I tried to figure out why but gave up after a while and added a > "cp -a". Without this the build fails for me on the "chmod" > immediately afterwards because the file whose mode is attempted > to be changed is missing: > > diff --git a/debian/rules.real b/debian/rules.real > index d0498bd..72c664c 100644 > --- a/debian/rules.real > +++ b/debian/rules.real > @@ -404,6 +404,7 @@ endif > install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_bug: > dh_installdirs usr/share/bug/$(PACKAGE_NAME) > dh_install debian/templates/image.bug/* usr/share/bug/$(PACKAGE_NAME) > + cp -a debian/templates/image.bug/* > $(PACKAGE_DIR)/usr/share/bug/$(PACKAGE_NAME) > chmod 755 $(PACKAGE_DIR)/usr/share/bug/$(PACKAGE_NAME)/script > printf > "RELEASE='$(REAL_VERSION)'\nDISTRIBUTOR='$(DISTRIBUTOR)'\nSOURCEVERSION='$(SOURCEVERSION)'\n" > > $(PACKAGE_DIR)/usr/share/bug/$(PACKAGE_NAME)/info > Well, it worked on my computer and it worked on all the build daemons so I don't believe this change is really needed. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Linux 4.5 kernel package fixes
Hi Ben, I've hit a few issues while upgrading kernel packages to 4.5 and wanted to give a quick heads-up. In linux-tools, the following is needed lest dkms packages won't build: diff --git a/debian/rules.d/scripts/Makefile b/debian/rules.d/scripts/Makefile index 8d97087..b2e2cd3 100644 --- a/debian/rules.d/scripts/Makefile +++ b/debian/rules.d/scripts/Makefile @@ -14,6 +14,7 @@ DATA = \ Makefile.lib \ Makefile.modinst \ Makefile.modpost \ + Makefile.ubsan \ mkversion \ module-common.lds In linux, drivers-media-dvb-usb-af9005-request_firmware.patch needs a rebase, this issue has already existed since I think 4.3, I'm wondering why noone else has hit upon it yet: diff --git a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch index 7ab3e6b..5015ceb 100644 --- a/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch +++ b/debian/patches/features/all/drivers-media-dvb-usb-af9005-request_firmware.patch @@ -13,11 +13,7 @@ a version of the script which is directly derived from the driver. --- a/drivers/media/usb/dvb-usb/Kconfig +++ b/drivers/media/usb/dvb-usb/Kconfig -@@ -227,10 +227,10 @@ config DVB_USB_OPERA1 - - config DVB_USB_AF9005 - tristate "Afatech AF9005 DVB-T USB1.1 support" -- depends on BROKEN +@@ -236,6 +236,7 @@ config DVB_USB_AF9005 depends on DVB_USB select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT In debian/rules.real when building the linux-image package, a few files are supposed to be copied from debian/templates/image.bug/, but for some reason the dh_install command doesn't do anything. I tried to figure out why but gave up after a while and added a "cp -a". Without this the build fails for me on the "chmod" immediately afterwards because the file whose mode is attempted to be changed is missing: diff --git a/debian/rules.real b/debian/rules.real index d0498bd..72c664c 100644 --- a/debian/rules.real +++ b/debian/rules.real @@ -404,6 +404,7 @@ endif install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_bug: dh_installdirs usr/share/bug/$(PACKAGE_NAME) dh_install debian/templates/image.bug/* usr/share/bug/$(PACKAGE_NAME) + cp -a debian/templates/image.bug/* $(PACKAGE_DIR)/usr/share/bug/$(PACKAGE_NAME) chmod 755 $(PACKAGE_DIR)/usr/share/bug/$(PACKAGE_NAME)/script printf "RELEASE='$(REAL_VERSION)'\nDISTRIBUTOR='$(DISTRIBUTOR)'\nSOURCEVERSION='$(SOURCEVERSION)'\n" > $(PACKAGE_DIR)/usr/share/bug/$(PACKAGE_NAME)/info Best regards, Lukas
Processed: Re: /etc/kernel-img.conf not documented unless 'kernel-package' package installed
Processing control commands:
> reopen -1
Bug #373872 {Done: Ben Hutchings } [src:linux-2.6]
/etc/kernel-img.conf not documented unless 'kernel-package' package installed
Warning: Unknown package 'src:linux-2.6'
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
Warning: Unknown package 'src:linux-2.6'
Warning: Unknown package 'src:linux-2.6'
No longer marked as fixed in versions 3.4.1-1~experimental.1+rm.
Warning: Unknown package 'src:linux-2.6'
> reassign -1 src:linux
Bug #373872 [src:linux-2.6] /etc/kernel-img.conf not documented unless
'kernel-package' package installed
Warning: Unknown package 'src:linux-2.6'
Bug reassigned from package 'src:linux-2.6' to 'src:linux'.
Ignoring request to alter found versions of bug #373872 to the same values
previously set
Ignoring request to alter fixed versions of bug #373872 to the same values
previously set
--
373872: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373872
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Re: Is it possible to include vdso files in the kernel package?
On Wed, 2016-01-13 at 12:59 +0800, Jinhua Luo wrote: Hi All, Without vdso files and its debuginfo files, the systemtap could not unwind the user backtrace when the process is interrupted mid-syscall. It's important for off-cpu profiling. See https://sourceware.org/ml/systemtap/2016-q1/msg00021.html for the issue. The ubuntu (14.04) also do vdso_install for the kernel pckage. Thanks for reporting this. It should be fixed in the next upload to unstable. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Is it possible to include vdso files in the kernel package?
Hi All, Without vdso files and its debuginfo files, the systemtap could not unwind the user backtrace when the process is interrupted mid-syscall. It's important for off-cpu profiling. See https://sourceware.org/ml/systemtap/2016-q1/msg00021.html for the issue. The ubuntu (14.04) also do vdso_install for the kernel pckage. Regards, Jinhua Luo
Bug#797878: marked as done (QNAP TS-219P II bricked by linux-image-4.1.0-0.bpo.1-kirkwood (4.1.3-1~bpo8+1) from jessie-backports: missing dependency on updated flash-kernel package)
Your message dated Tue, 06 Oct 2015 19:50:58 + with message-id and subject line Bug#797878: fixed in linux 4.2.3-1 has caused the Debian Bug report #797878, regarding QNAP TS-219P II bricked by linux-image-4.1.0-0.bpo.1-kirkwood (4.1.3-1~bpo8+1) from jessie-backports: missing dependency on updated flash-kernel package to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 797878: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797878 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image-4.1.0-0.bpo.1-kirkwood Version: 4.1.3-1~bpo8+1 Installing this package from the jessie-backports distribution "bricked" my QNAP TS-219P II. The Linux kernel no longer boots. Attaching a serial console revealed that the Linux kernel did not recognize the machine id. Further investigation revealed that the flash-kernel package version 3.35 in debian jessie neglected to append the DTB to the Linux kernel when flashing it. flash-kernel package version 3.45 from the unstable distribution has additional entries in its database, stating that this machine needs to have a DTB appended for Linux kernel versions 3.17 or later. Proposed fix: Add flash-kernel 3.45 to jessie-backports and add a dependency of any Linux kernels 3.17 or later on at least this package version. Best Regards, Robert Schlabbach --- End Message --- --- Begin Message --- Source: linux Source-Version: 4.2.3-1 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 797...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings (supplier of updated linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 06 Oct 2015 17:44:55 +0100 Source: linux Binary: linux-source-4.2 linux-doc-4.2 linux-manual-4.2 linux-support-4.2.0-1 linux-libc-dev linux-headers-4.2.0-1-all linux-headers-4.2.0-1-all-alpha kernel-image-4.2.0-1-alpha-generic-di nic-modules-4.2.0-1-alpha-generic-di nic-wireless-modules-4.2.0-1-alpha-generic-di nic-shared-modules-4.2.0-1-alpha-generic-di serial-modules-4.2.0-1-alpha-generic-di usb-serial-modules-4.2.0-1-alpha-generic-di ppp-modules-4.2.0-1-alpha-generic-di pata-modules-4.2.0-1-alpha-generic-di cdrom-core-modules-4.2.0-1-alpha-generic-di scsi-core-modules-4.2.0-1-alpha-generic-di scsi-modules-4.2.0-1-alpha-generic-di scsi-common-modules-4.2.0-1-alpha-generic-di scsi-extra-modules-4.2.0-1-alpha-generic-di loop-modules-4.2.0-1-alpha-generic-di btrfs-modules-4.2.0-1-alpha-generic-di ext4-modules-4.2.0-1-alpha-generic-di isofs-modules-4.2.0-1-alpha-generic-di jfs-modules-4.2.0-1-alpha-generic-di xfs-modules-4.2.0-1-alpha-generic-di fat-modules-4.2.0-1-alpha-generic-di md-modules-4.2.0-1-alpha-generic-di multipath-modules-4.2.0-1-alpha-generic-di usb-modules-4.2.0-1-alpha-generic-di usb-storage-modules-4.2.0-1-alpha-generic-di fb-modules-4.2.0-1-alpha-generic-di input-modules-4.2.0-1-alpha-generic-di event-modules-4.2.0-1-alpha-generic-di mouse-modules-4.2.0-1-alpha-generic-di nic-pcmcia-modules-4.2.0-1-alpha-generic-di pcmcia-modules-4.2.0-1-alpha-generic-di nic-usb-modules-4.2.0-1-alpha-generic-di sata-modules-4.2.0-1-alpha-generic-di core-modules-4.2.0-1-alpha-generic-di crc-modules-4.2.0-1-alpha-generic-di crypto-modules-4.2.0-1-alpha-generic-di crypto-dm-modules-4.2.0-1-alpha-generic-di ata-modules-4.2.0-1-alpha-generic-di nbd-modules-4.2.0-1-alpha-generic-di squashfs-modules-4.2.0-1-alpha-generic-di virtio-modules-4.2.0-1-alpha-generic-di zlib-modules-4.2.0-1-alpha-generic-di fuse-modules-4.2.0-1-alpha-generic-di srm-modules-4.2.0-1-alpha-generic-di linux-headers-4.2.0-1-common linux-image-4.2.0-1-alpha-generic linux-headers-4.2.0-1-alpha-generic linux-image-4.2.0-1-alpha-smp linux-headers-4.2.0-1-alpha-smp linux-headers-4.2.0-1-all-amd64 kernel-image-4.2.0-1-amd64-di nic-modules-4.2.0-1-amd64-di nic-wireless-modules-4.2.0-1-amd64-di nic-shared-modules-4.2.0-1-amd64-di serial-modules-4.2.0-1-amd64-di usb-serial-modules-4.2.0-1-amd64-di ppp-modules-4.2.0-1-amd64-di pata-modules-4.2.0-
Bug#797878: QNAP TS-219P II bricked by linux-image-4.1.0-0.bpo.1-kirkwood (4.1.3-1~bpo8+1) from jessie-backports: missing dependency on updated flash-kernel package
On Thu, 2015-09-03 at 11:58 +0200, Robert Schlabbach wrote: > Proposed fix: Add flash-kernel 3.45 to jessie-backports and add a > dependency of any Linux kernels 3.17 or later on at least this > package version. Agreed. The important change was made in flash-kernel 3.37 so the breaks in the kernel should be updated to at least that. I'll do that and arrange for f-k 3.46 to go into bpo. Thanks, Ian.
Bug#797878: QNAP TS-219P II bricked by linux-image-4.1.0-0.bpo.1-kirkwood (4.1.3-1~bpo8+1) from jessie-backports: missing dependency on updated flash-kernel package
Package: linux-image-4.1.0-0.bpo.1-kirkwood Version: 4.1.3-1~bpo8+1 Installing this package from the jessie-backports distribution "bricked" my QNAP TS-219P II. The Linux kernel no longer boots. Attaching a serial console revealed that the Linux kernel did not recognize the machine id. Further investigation revealed that the flash-kernel package version 3.35 in debian jessie neglected to append the DTB to the Linux kernel when flashing it. flash-kernel package version 3.45 from the unstable distribution has additional entries in its database, stating that this machine needs to have a DTB appended for Linux kernel versions 3.17 or later. Proposed fix: Add flash-kernel 3.45 to jessie-backports and add a dependency of any Linux kernels 3.17 or later on at least this package version. Best Regards, Robert Schlabbach
Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
I was basically doing the same steps as the initial poster, I upgraded my Amilo M 7400 from wheezy-xfce to sid. With diffrent issues. Wheezy was running fine with kernel 3.2.0-4-486. During dist-upgrade I noticed a previous kernel version kernel was installed (iirc 3.15-586). 1. On first boot I noticed the i9xx "pipe a underrun" error on the screen right after GRUB. 2. A minute on the desktop and the system went into S3 state. 3. resuming from S3 results in S3 state again after around 30 seconds tail -f syslog reveals constant pipe underrun messages I am able to boot, both the old 3.2.0-4-486 and the newly installed 3.1x-586 kernel into the sid desktop. But end up in S3 state as mentioned (both kernels). If there is time I'm going to run a clean testing install on this notebook. --- Sebastian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKH2fmeSnqyNR55VeTO+tq95L08p0QDT=36-sBCfC775pbfB=q...@mail.gmail.com
Bug#777243: Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
W dniu 06.02.2015 o 20:31, Ben Hutchings pisze: Control: retitle -1 Boot fails due to missing ext4 module On Fri, 2015-02-06 at 18:48 +0100, Rafał Pietrak wrote: W dniu 04.02.2015 23:07, Ben Hutchings pisze: [...] Severity: grave Tags: newcomer Justification: renders package unusable I've upgraded my LG notebook (X-note: LS50a) from wheezy to jessie and: 1. the upgrade have installed kernel "version-i585" in addition to my earlier (automatically installed during an upgrade to wheezy) "version-i486". 2. when booting "i486", it fails to modprobe "ext4-fs" during the boot. It breaks boot sequence, but manual (from shell prompt) modprobe ext4 does not load the module into the kernel. Can you clarify how far the system boots? Does it stop at a shell with the prompt '(initramfs)'? Stops at: "maintenance mode. Give root password or control-D" And I think, it does that because /srv/pgdat is ext4 and cannot be mounted because of missing ext4.ko within the kernel. I vagually remember the boot stopping at "(initramfs)", but after I've moved /usr to jfs it is mounted during the boot and the process stops somewhat farther. Please send a copy of the /etc/fstab file. =/etc/fstab=== proc /procprocdefaults0 0 /dev/mapper/vg0-root/xfsdefaults0 1 [...] So is the root filesystem type really xfs, or is it ext4? Yes, it's XFS. I didn't bother to change that after "my experimentation time was done" (I don't mind since my /usr is on a separate partition). So, at this point only /srv/pgdat is ext4 and it looks like it only rises a problem of missing ext4.ko module when booting kernel 3.2.xxx-486, which was the kernel *number* I used before the upgrade (it was upgraded by apt-get since); Yet, ext4 are modprobed correctly only when I boot from 3.16.x-586 kernel, which jessie have installed on this machine. One additional info regarding keyboard: 1. currently, after the upgrade I have six entries in my grub.menu: 1) linux-586, 2) linux-586 (sysvinit), 3) linux-586 (recover), 4) linux-486, 5) linux-486 (sysvinit), and 6) linux-486 (recover) 2. when I boot (5) (e.g.: linux-486/sysvinit) I get the notebook keyboard working correctly. No other boot does that. -R -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d538c2.4030...@ztk-rp.eu
Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Control: retitle -1 Keyboard non-functional on LG X-note LS50a (I've split this into two bug reports.) On Fri, 2015-02-06 at 18:48 +0100, Rafał Pietrak wrote: [...] > >> 4. DRM:i9xx fails to configure with "*ERROR* pipe A underrun" > > Please send the full kernel boot messages when booting with old and new > > kernel versions (run 'dmesg > filename'). > > > > Ben. > > > > attached. That's with the new kernel (3.16.0-4-586); how about the old one (3.2.0-4-486)? If you didn't find a way to boot the old kernel, you should be able to work around the problem by running these commands (as root) under the new kernel before rebooting into the old one: echo >> /etc/initramfs-tools/modules ext4 update-initramfs -u -k 3.2.0-4-486 Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Processing control commands: > retitle -1 Keyboard non-functional on LG X-note LS50a Bug #776909 [src:linux] kernel-package: couple of modules fail to load after wheezy to jessie upgrade Changed Bug title to 'Keyboard non-functional on LG X-note LS50a' from 'kernel-package: couple of modules fail to load after wheezy to jessie upgrade' -- 776909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776909 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b776909.14232514304352.transcr...@bugs.debian.org
Bug#777243: Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Control: retitle -1 Boot fails due to missing ext4 module On Fri, 2015-02-06 at 18:48 +0100, Rafał Pietrak wrote: > W dniu 04.02.2015 23:07, Ben Hutchings pisze: [...] > >> Severity: grave > >> Tags: newcomer > >> Justification: renders package unusable > >> > >> I've upgraded my LG notebook (X-note: LS50a) from wheezy to jessie and: > >> 1. the upgrade have installed kernel "version-i585" in addition to my > >> earlier > >> (automatically installed during an upgrade to wheezy) "version-i486". > >> 2. when booting "i486", it fails to modprobe "ext4-fs" during the boot. It > >> breaks boot sequence, but manual (from shell prompt) modprobe ext4 does not > >> load the module into the kernel. Can you clarify how far the system boots? Does it stop at a shell with the prompt '(initramfs)'? > > Please send a copy of the /etc/fstab file. > > =/etc/fstab=== > proc /procprocdefaults0 0 > /dev/mapper/vg0-root/xfsdefaults0 1 [...] So is the root filesystem type really xfs, or is it ext4? Ben. -- Ben Hutchings The first rule of tautology club is the first rule of tautology club. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Processing control commands: > retitle -1 Boot fails due to missing ext4 module Bug #777243 [initramfs-tools] kernel-package: couple of modules fail to load after wheezy to jessie upgrade Changed Bug title to 'Boot fails due to missing ext4 module' from 'kernel-package: couple of modules fail to load after wheezy to jessie upgrade' -- 777243: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777243 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b777243.14232511042525.transcr...@bugs.debian.org
Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
W dniu 04.02.2015 23:07, Ben Hutchings pisze: Control: tag -1 moreinfo On Tue, 03 Feb 2015 10:20:42 +0100 Rafal Pietrak wrote: Package: kernel-package Version: 13.014+nmu1 This is not the right package name. The kernel is packaged as linux-image-3.16.0-4-586 (and other names). What version of that package do you have installed? = $ uname -a Linux porta 3.16.0-4-586 #1 Debian 3.16.7-ckt2-1 (2014-12-08) i686 GNU/Linux $ ls -la /boot/ total 37136 drwxr-xr-x 4 root root 2048 lut 1 18:34 . drwxr-xr-x 24 root root 4096 lut 3 18:21 .. -rw-r--r-- 1 root root 160031 gru 9 03:25 config-3.16.0-4-586 -rw-r--r-- 1 root root 134707 lip 23 2014 config-3.2.0-4-486 drwxr-xr-x 5 root root 5120 lut 1 18:38 grub -rw-r--r-- 1 root root 16172521 lut 1 18:34 initrd.img-3.16.0-4-586 -rw-r--r-- 1 root root 12348889 sty 16 20:20 initrd.img-3.2.0-4-486 drwxr-xr-x 2 root root12288 lip 18 2006 lost+found -rw-r--r-- 1 root root 128796 lip 12 2009 memtest86+.bin -rw-r--r-- 1 root root 1984406 gru 9 03:25 System.map-3.16.0-4-586 -rw-r--r-- 1 root root 1578153 lip 23 2014 System.map-3.2.0-4-486 -rw-r--r-- 1 root root 2820976 gru 9 03:25 vmlinuz-3.16.0-4-586 -rw-r--r-- 1 root root 2513120 lip 23 2014 vmlinuz-3.2.0-4-486 === Severity: grave Tags: newcomer Justification: renders package unusable I've upgraded my LG notebook (X-note: LS50a) from wheezy to jessie and: 1. the upgrade have installed kernel "version-i585" in addition to my earlier (automatically installed during an upgrade to wheezy) "version-i486". 2. when booting "i486", it fails to modprobe "ext4-fs" during the boot. It breaks boot sequence, but manual (from shell prompt) modprobe ext4 does not load the module into the kernel. Please send a copy of the /etc/fstab file. =/etc/fstab=== proc /procprocdefaults0 0 /dev/mapper/vg0-root/xfsdefaults0 1 /dev/vg0/swapswapswapdefaults0 0 /dev/vg0/swap2swapswapdefaults0 0 none/cgroupcgroupdefaults 0 0 UUID=d7a6270c-b191-4cdd-832c-26344a9d1eed /boot ext2 defaults0 2 /dev/vg0/usr/usrautoro,defaults 0 2 /dev/vg0/var/varjfsdefaults0 1 /dev/vg0/home/homexfsdefaults0 2 /dev/vg0/opt/optautodefaults,ro02 /dev/vg0/pgd/srv/pgdataext4defaults0 2 /dev/vg0/archive /srv/atticjfsdefaults02 /dev/cdrom /media/cdromautoro,user,noauto 0 0 But to be able to boot it, I've copied my old /dev/vg0/usr into a newly created volume, which I've formated as jfs and renamed to /dev/vg0/usr ... so the state right after the upgrade is lost. 3. when booting "i586", it fails to load kernel module responsible for notebook keyboard (touchpad is loaded OK). USB keyboard works fine. What kernel module is needed? I would expect the keyboard to be handled I don't really know. by the built-in i8042 keyboard driver. I was expecting that, but the notebook kbd is dead. I can only work with usb attached keyboard now. 4. DRM:i9xx fails to configure with "*ERROR* pipe A underrun" Please send the full kernel boot messages when booting with old and new kernel versions (run 'dmesg > filename'). Ben. attached. -R dmesg.logfile.gz Description: application/gzip
Bug#776909: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Control: tag -1 moreinfo On Tue, 03 Feb 2015 10:20:42 +0100 Rafal Pietrak wrote: > Package: kernel-package > Version: 13.014+nmu1 This is not the right package name. The kernel is packaged as linux-image-3.16.0-4-586 (and other names). What version of that package do you have installed? > Severity: grave > Tags: newcomer > Justification: renders package unusable > > I've upgraded my LG notebook (X-note: LS50a) from wheezy to jessie and: > 1. the upgrade have installed kernel "version-i585" in addition to my earlier > (automatically installed during an upgrade to wheezy) "version-i486". > 2. when booting "i486", it fails to modprobe "ext4-fs" during the boot. It > breaks boot sequence, but manual (from shell prompt) modprobe ext4 does not > load the module into the kernel. Please send a copy of the /etc/fstab file. > 3. when booting "i586", it fails to load kernel module responsible for > notebook > keyboard (touchpad is loaded OK). USB keyboard works fine. What kernel module is needed? I would expect the keyboard to be handled by the built-in i8042 keyboard driver. > 4. DRM:i9xx fails to configure with "*ERROR* pipe A underrun" Please send the full kernel boot messages when booting with old and new kernel versions (run 'dmesg > filename'). Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Processed: Re: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Processing control commands: > tag -1 moreinfo Bug #776909 [src:linux] kernel-package: couple of modules fail to load after wheezy to jessie upgrade Added tag(s) moreinfo. -- 776909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776909 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b776909.142308764512701.transcr...@bugs.debian.org
Processed: Re: kernel-package: couple of modules fail to load after wheezy to jessie upgrade
Processing control commands: > tag -1 moreinfo Bug #776909 [src:linux] kernel-package: couple of modules fail to load after wheezy to jessie upgrade Ignoring request to alter tags of bug #776909 to the same tags previously set -- 776909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776909 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.u776909.142308764512692.transcr...@bugs.debian.org
Bug#770102: marked as done (PATCH: fix packaging the hppa kernel package)
Your message dated Tue, 27 Jan 2015 19:50:06 + with message-id and subject line Bug#770102: fixed in linux 3.16.7-ckt4-2 has caused the Debian Bug report #770102, regarding PATCH: fix packaging the hppa kernel package to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 770102: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770102 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: linux Version: 3.16.7-2 Severity: important Tags: patch Dear debian kernel maintainers, please apply the attached patch to the debian kernel sources for the next upload. It fixes this error when building and packaging the debian hppa kernel: ... kernel-wedge install-files 3.16.0-4 ... kernel-wedge find-dups 3.16.0-4-parisc some modules are in more than one package debian/pata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko debian/ata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko command exited with status 1 Thanks, Helge diff -up ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules --- ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org 2014-11-05 22:27:31.0 +0100 +++ ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules 2014-11-13 14:58:24.0 +0100 @@ -1 +1,2 @@ #include +libata - diff -up ./linux-3.16.7/debian/installer/hppa/package-list.org ./linux-3.16.7/debian/installer/hppa/package-list --- ./linux-3.16.7/debian/installer/hppa/package-list.org 2014-09-08 06:58:01.0 +0200 +++ ./linux-3.16.7/debian/installer/hppa/package-list 2014-11-13 22:38:11.0 +0100 @@ -12,7 +12,7 @@ Package: ide-modules Depends: kernel-image, ide-core-modules, nls-core-modules Package: pata-modules -Depends: kernel-image, scsi-core-modules +Depends: kernel-image, ata-modules, scsi-core-modules Package: fb-modules Depends: kernel-image --- End Message --- --- Begin Message --- Source: linux Source-Version: 3.16.7-ckt4-2 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 770...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings (supplier of updated linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 27 Jan 2015 03:57:26 + Source: linux Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 linux-support-3.16.0-4 linux-libc-dev linux-headers-3.16.0-4-all linux-headers-3.16.0-4-all-alpha linux-headers-3.16.0-4-common linux-image-3.16.0-4-alpha-generic linux-headers-3.16.0-4-alpha-generic linux-image-3.16.0-4-alpha-smp linux-headers-3.16.0-4-alpha-smp linux-image-3.16.0-4-alpha-legacy linux-headers-3.16.0-4-alpha-legacy linux-headers-3.16.0-4-all-amd64 kernel-image-3.16.0-4-amd64-di nic-modules-3.16.0-4-amd64-di nic-wireless-modules-3.16.0-4-amd64-di nic-shared-modules-3.16.0-4-amd64-di serial-modules-3.16.0-4-amd64-di usb-serial-modules-3.16.0-4-amd64-di ppp-modules-3.16.0-4-amd64-di pata-modules-3.16.0-4-amd64-di cdrom-core-modules-3.16.0-4-amd64-di firewire-core-modules-3.16.0-4-amd64-di scsi-core-modules-3.16.0-4-amd64-di scsi-modules-3.16.0-4-amd64-di scsi-common-modules-3.16.0-4-amd64-di scsi-extra-modules-3.16.0-4-amd64-di loop-modules-3.16.0-4-amd64-di btrfs-modules-3.16.0-4-amd64-di ext4-modules-3.16.0-4-amd64-di isofs-modules-3.16.0-4-amd64-di jfs-modules-3.16.0-4-amd64-di ntfs-modules-3.16.0-4-amd64-di xfs-modules-3.16.0-4-amd64-di fat-modules-3.16.0-4-amd64-di md-modules-3.16.0-4-amd64-di multipath-modules-3.16.0-4-amd64-di usb-modules-3.16.0-4-amd64-di usb-storage-modules-3.16.0-4-amd64-di pcmcia-storage-modules-3.16.0-4-amd64-di fb-modules-3.16.0-4-amd64-di input-modules-3.16.0-4-amd64-di event-modules-3.16.0-4-amd64-di mouse-modules-3.16.0-4-amd64-di nic-pcmcia-modules-3.16.0-4-amd64-di pcmcia-modules-3.16.0-4-amd64-di nic-usb-modules-3.16.0-4-amd64-di sata-modules-3.16.0-4-amd64-di core-modules-3.16.0-4-amd64-di acpi-modules-3.16.0-4-amd64-di i2c-modules-3.16.0-4-amd64-di
Bug#770102: marked as done (PATCH: fix packaging the hppa kernel package)
Your message dated Mon, 19 Jan 2015 01:49:50 + with message-id and subject line Bug#770102: fixed in linux 3.18.3-1~exp1 has caused the Debian Bug report #770102, regarding PATCH: fix packaging the hppa kernel package to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 770102: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770102 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: linux Version: 3.16.7-2 Severity: important Tags: patch Dear debian kernel maintainers, please apply the attached patch to the debian kernel sources for the next upload. It fixes this error when building and packaging the debian hppa kernel: ... kernel-wedge install-files 3.16.0-4 ... kernel-wedge find-dups 3.16.0-4-parisc some modules are in more than one package debian/pata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko debian/ata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko command exited with status 1 Thanks, Helge diff -up ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules --- ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org 2014-11-05 22:27:31.0 +0100 +++ ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules 2014-11-13 14:58:24.0 +0100 @@ -1 +1,2 @@ #include +libata - diff -up ./linux-3.16.7/debian/installer/hppa/package-list.org ./linux-3.16.7/debian/installer/hppa/package-list --- ./linux-3.16.7/debian/installer/hppa/package-list.org 2014-09-08 06:58:01.0 +0200 +++ ./linux-3.16.7/debian/installer/hppa/package-list 2014-11-13 22:38:11.0 +0100 @@ -12,7 +12,7 @@ Package: ide-modules Depends: kernel-image, ide-core-modules, nls-core-modules Package: pata-modules -Depends: kernel-image, scsi-core-modules +Depends: kernel-image, ata-modules, scsi-core-modules Package: fb-modules Depends: kernel-image --- End Message --- --- Begin Message --- Source: linux Source-Version: 3.18.3-1~exp1 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 770...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings (supplier of updated linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Jan 2015 20:48:06 + Source: linux Binary: linux-source-3.18 linux-doc-3.18 linux-manual-3.18 linux-support-3.18.0-trunk linux-libc-dev linux-headers-3.18.0-trunk-all linux-headers-3.18.0-trunk-all-alpha linux-headers-3.18.0-trunk-common linux-image-3.18.0-trunk-alpha-generic linux-headers-3.18.0-trunk-alpha-generic linux-image-3.18.0-trunk-alpha-smp linux-headers-3.18.0-trunk-alpha-smp linux-image-3.18.0-trunk-alpha-legacy linux-headers-3.18.0-trunk-alpha-legacy linux-headers-3.18.0-trunk-all-amd64 kernel-image-3.18.0-trunk-amd64-di nic-modules-3.18.0-trunk-amd64-di nic-wireless-modules-3.18.0-trunk-amd64-di nic-shared-modules-3.18.0-trunk-amd64-di serial-modules-3.18.0-trunk-amd64-di usb-serial-modules-3.18.0-trunk-amd64-di ppp-modules-3.18.0-trunk-amd64-di pata-modules-3.18.0-trunk-amd64-di cdrom-core-modules-3.18.0-trunk-amd64-di firewire-core-modules-3.18.0-trunk-amd64-di scsi-core-modules-3.18.0-trunk-amd64-di scsi-modules-3.18.0-trunk-amd64-di scsi-common-modules-3.18.0-trunk-amd64-di scsi-extra-modules-3.18.0-trunk-amd64-di loop-modules-3.18.0-trunk-amd64-di btrfs-modules-3.18.0-trunk-amd64-di ext4-modules-3.18.0-trunk-amd64-di isofs-modules-3.18.0-trunk-amd64-di jfs-modules-3.18.0-trunk-amd64-di ntfs-modules-3.18.0-trunk-amd64-di xfs-modules-3.18.0-trunk-amd64-di fat-modules-3.18.0-trunk-amd64-di md-modules-3.18.0-trunk-amd64-di multipath-modules-3.18.0-trunk-amd64-di usb-modules-3.18.0-trunk-amd64-di usb-storage-modules-3.18.0-trunk-amd64-di pcmcia-storage-modules-3.18.0-trunk-amd64-di fb-modules-3.18.0-trunk-amd64-di input-modules-3.18.0-trunk-amd64-di event-modules-3.18.0-trunk-amd64-di mouse-modules-3.18.0-trunk-amd64-di nic-pcmcia-modules-3.18.0-trunk-amd64-di pcmcia-modules
Re: Next kernel package upload?
Karsten Merker (2014-12-01): > I would like to kindly ask what the current plans are regarding > the next kernel package upload and getting a freeze exception for > it. Is there already some agreement with the release team? > > I ask because I would really like to see the fix for bug > #767042 (which is in current SVN) going into Jessie, as this bug > breaks the installer on the Banana Pi board. On Saturday the > next phase of the freeze starts and the general acceptance of > fixes for bugs with severity: important in packages of priority: > optional ends, so this might become a problem afterwards. I don't think either the release team or the d-i release manager are going to forbid further migrations of the linux package to testing. Mraw, KiBi. signature.asc Description: Digital signature
Next kernel package upload?
Hello, I would like to kindly ask what the current plans are regarding the next kernel package upload and getting a freeze exception for it. Is there already some agreement with the release team? I ask because I would really like to see the fix for bug #767042 (which is in current SVN) going into Jessie, as this bug breaks the installer on the Banana Pi board. On Saturday the next phase of the freeze starts and the general acceptance of fixes for bugs with severity: important in packages of priority: optional ends, so this might become a problem afterwards. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201201443.ga4...@excalibur.cnev.de
Bug#770102: PATCH: fix packaging the hppa kernel package
Source: linux Version: 3.16.7-2 Severity: important Tags: patch Dear debian kernel maintainers, please apply the attached patch to the debian kernel sources for the next upload. It fixes this error when building and packaging the debian hppa kernel: ... kernel-wedge install-files 3.16.0-4 ... kernel-wedge find-dups 3.16.0-4-parisc some modules are in more than one package debian/pata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko debian/ata-modules-3.16.0-4-parisc-di lib/modules/3.16.0-4-parisc/kernel/drivers/ata/libata.ko command exited with status 1 Thanks, Helge diff -up ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules --- ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules.org 2014-11-05 22:27:31.0 +0100 +++ ./linux-3.16.7/debian/installer/hppa/modules/hppa/ata-modules 2014-11-13 14:58:24.0 +0100 @@ -1 +1,2 @@ #include +libata - diff -up ./linux-3.16.7/debian/installer/hppa/package-list.org ./linux-3.16.7/debian/installer/hppa/package-list --- ./linux-3.16.7/debian/installer/hppa/package-list.org 2014-09-08 06:58:01.0 +0200 +++ ./linux-3.16.7/debian/installer/hppa/package-list 2014-11-13 22:38:11.0 +0100 @@ -12,7 +12,7 @@ Package: ide-modules Depends: kernel-image, ide-core-modules, nls-core-modules Package: pata-modules -Depends: kernel-image, scsi-core-modules +Depends: kernel-image, ata-modules, scsi-core-modules Package: fb-modules Depends: kernel-image
Re: latest kernel package with sources.list
On Thu, 2014-01-16 at 11:24 +0100, Joerg Henner wrote: [...] > Could you please help me to install "3.12.xxx" Releases, as it is described > here: http://packages.debian.org/de/sid/linux-image-amd64 > > And how do i include them in my "sources.list" ? > > Thanks in advance for your help and answers :) These questions should be directed to debian-user or other user support channels. They are not specific to the kernel packages. Linux 3.12 is also available in wheezy-backports which might be a better choice. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
latest kernel package with sources.list
Hello, on my WHEEZY System, i got following output: aptitude search latest p kde-sc-dev-latest - ensure that the latest KDE Development Platform is installed v linux-latest-modules-3.2.0-4-486 - v linux-latest-modules-3.2.0-4-686-pae - v linux-latest-modules-3.2.0-4-amd64- v linux-latest-modules-3.2.0-4-rt-686-pae - My "sources.list" shows as follow: deb http://ftp.de.debian.org/debian/ wheezy main contrib non-free deb-src http://ftp.de.debian.org/debian/ wheezy main contrib non-free deb http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free # wheezy-updates, previously known as 'volatile' deb http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free deb-src http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free Could you please help me to install "3.12.xxx" Releases, as it is described here: http://packages.debian.org/de/sid/linux-image-amd64 And how do i include them in my "sources.list" ? Thanks in advance for your help and answers :) Greetings, Joerg Henner. -- www: http://www.jh-networks.de phone/fax: +49-32121-435020 mobile: +49-152-53704927 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/trinity-90ef5f2d-d241-4e38-90f5-49c17e56a2ca-1389867853363@3capp-webde-bs03
Processed: Re: Bug#721635: [kernel-package] error on shutdown
Processing control commands: > reassign -1 src:linux Bug #721635 [kernel-package] [kernel-package] error on shutdown Bug reassigned from package 'kernel-package' to 'src:linux'. No longer marked as found in versions kernel-package/12.036+nmu3. Ignoring request to alter fixed versions of bug #721635 to the same values previously set -- 721635: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721635 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b721635.137820444231181.transcr...@bugs.debian.org
Re: Bug#721635: [kernel-package] error on shutdown
control: reassign -1 src:linux On Dienstag, 3. September 2013, Marco Righi wrote: > The problem are born after apt-get dist-upgrade to the last kernel > > uname -a > Linux gaia 3.10-2-amd64 #1 SMP Debian 3.10.7-1 (2013-08-17) x86_64 > GNU/Linux > > It's a standard kernel. thanks for info, reassigning accordingly. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: [PATCH 0/4] Replace the kernel-package template system
I've applied these patches (to trunk). Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/4] Replace the kernel-package template system
Here's the diff between control files for linux-image-3.11-rc4-amd64
before and after this patch series (ignoring the md5sums):
diff -urN linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/control
linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/control
--- linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/control
2013-08-08 14:27:02.0 +0200
+++ linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/control
2013-08-15 01:45:58.0 +0200
@@ -1,11 +1,11 @@
Package: linux-image-3.11-rc4-amd64
Source: linux
-Version: 3.11~rc4-1~exp1
+Version: 3.11~rc4-1~exp2
Architecture: amd64
Maintainer: Debian Kernel Team
-Installed-Size: 113707
+Installed-Size: 113729
Pre-Depends: debconf | debconf-2.0
-Depends: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools (>=
0.110~) | linux-initramfs-tool
+Depends: kmod | module-init-tools, linux-base (>= 3~), debconf (>= 0.5) |
debconf-2.0, initramfs-tools (>= 0.110~) | linux-initramfs-tool
Recommends: firmware-linux-free (>= 3~)
Suggests: linux-doc-3.11, debian-kernel-handbook, grub-pc | extlinux | lilo
Breaks: at (<< 3.1.12-1+squeeze1), initramfs-tools (<< 0.110~)
diff -urN linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/postinst
linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/postinst
--- linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/postinst
2013-08-08 14:27:02.0 +0200
+++ linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/postinst
2013-08-15 01:45:57.0 +0200
@@ -16,13 +16,12 @@
my $no_symlink= "";
my $do_symlink= "Yes"; # target machine defined
my $kimage= "vmlinuz";
-my $initrd= "YES";# initrd kernel
+my $initrd= "YES";
my $mkimage = ""; # command to generate the initrd image
my $use_hard_links= ''; # hardlinks do not work across fs boundaries
my $postinst_hook = ''; #Normally we do not
my $minimal_swap = ''; # Do not swap symlinks
my $ignore_depmod_err = ''; # normally we do not
-my $kernel_arch = "x86";
my $ramdisk = '';
my $package_name = "linux-image-$version";
@@ -99,8 +98,6 @@
# most of our work is done in $image_dest (nominally /)
chdir("$image_dest") or die "could not chdir to $image_dest:$!\n";
-$ENV{KERNEL_ARCH}=$kernel_arch if $kernel_arch;
-
die "Internal Error: Could not find image (" . $realimageloc
. "$kimage-$version)\n" unless -e $realimageloc
diff -urN linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/postrm
linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/postrm
--- linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/postrm
2013-08-08 14:27:02.0 +0200
+++ linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/postrm
2013-08-15 01:45:58.0 +0200
@@ -22,10 +22,8 @@
my $version = "3.11-rc4-amd64";
my $link_in_boot = "";
my $kimage= "vmlinuz";
-my $initrd= "YES"; # initrd kernel
+my $initrd= "YES";
my $postrm_hook = ''; #Normally we do not
-my $kernel_arch = "x86";
-my $ramdisk = "=MK"; # List of tools to create initial ram fs.
my $package_name= "linux-image-$version";
#known variables
@@ -66,8 +64,6 @@
chdir("$image_dest") or die "could not chdir to $image_dest:$!\n";
}
-$ENV{KERNEL_ARCH}=$kernel_arch if $kernel_arch;
-
##
##
diff -urN linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/preinst
linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/preinst
--- linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/preinst
2013-08-08 14:27:02.0 +0200
+++ linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/preinst
2013-08-15 01:45:57.0 +0200
@@ -13,7 +13,6 @@
my $version = "3.11-rc4-amd64";
my $kimage = "vmlinuz";
my $preinst_hook= ''; #Normally we do not
-my $kernel_arch = "x86";
my $package_name= "linux-image-$version";
#known variables
@@ -40,8 +39,6 @@
}
}
-$ENV{KERNEL_ARCH}=$kernel_arch if $kernel_arch;
-
# set the env var stem
$ENV{'STEM'} = "linux";
diff -urN linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/prerm
linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/prerm
--- linux-image-3.11-rc4-amd64_3.11~rc4-1~exp1_amd64/DEBIAN/prerm
2013-08-08 14:27:02.0 +0200
+++ linux-image-3.11-rc4-amd64_3.11~rc4-1~exp2_amd64/DEBIAN/prerm
2013-08-15 01:45:57.0 +0200
@@ -11,7 +11,6 @@
my $version = "3.11-rc4-amd64";
my $kimage = "vmlinuz";
my $prerm_hook = ''; #Normally we do not
-my $kernel_arch = "x86";
my $package_name= "linux-image-$version";
#known variables
@@ -43,8 +42,6 @@
}
-$ENV{KERNEL_ARCH}=$kernel_arch if $kernel_arch
[PATCH 0/4] Replace the kernel-package template system
During DebCamp I started work on cleaning up the maintainer scripts and the templating for them. I'm going to post changes for review in several groups. As a first step, this patch series changes several files from kernel-package template system, now implemented using sed expressions in debian/rules.gen, to the template system and syntax implemented in gencontrol.py. Along the way, it moves all those files into the debian/templates subdirectory and makes more use of debhelper. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Bug#567591: marked as done (linux-image-2.6.32-trunk-amd64: kernel package should conflict with lvm2 package from Lenny)
Your message dated Mon, 24 Sep 2012 16:08:56 -0700 with message-id <20120924230856.GA30488@elie.Belkin> and subject line Re: [squeeze] kernel package should conflict with lvm2 package from Lenny has caused the Debian Bug report #567591, regarding linux-image-2.6.32-trunk-amd64: kernel package should conflict with lvm2 package from Lenny to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 567591: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567591 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image-2.6.32-trunk-amd64 Version: 2.6.32-5 Severity: normal I have just done an upgrade from Lenny to Testing. When I ran "apt-get dist-upgrade" it aborted because it tried to upgrade udev first and the kernel wasn't new enough. So I ran "apt-get install linux-image-2.6.32-trunk-amd64" which worked but then it didn't recognise the LVM volumes. I had to run "apt-get install lvm2" to get newer lvm modules to allow the kernel to mount an LVM based root filesystem. It seems that either the newer kernel packages should conflict with old versions of LVM, or the kernel should just work with the older LVM utilities. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (500, 'lenny-backports'), (350, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- Hi, In January, 2010, Russell Coker wrote: > On Sat, 30 Jan 2010, Ben Hutchings wrote: >>> When I ran "apt-get dist-upgrade" it aborted because it tried to upgrade >>> udev first and the kernel wasn't new enough. So I ran "apt-get install >>> linux-image-2.6.32-trunk-amd64" which worked but then it didn't recognise >>> the LVM volumes. I had to run "apt-get install lvm2" to get newer lvm >>> modules to allow the kernel to mount an LVM based root filesystem. >> >> I wasn't aware of this problem. What is the failure mode? > > It just doesn't find the LVs. Sorry I didn't take better notes. Closing because I do not see us getting closer to understanding and fixing this one, but I'd be happy to revisit it if you run into it again (the lenny -> squeeze upgrade path is still supported). Thanks, Jonathan--- End Message ---
Bug#664171: marked as done (initramfs-tools: initrd cannot be easily disabled when not using kernel-package)
Your message dated Fri, 21 Sep 2012 11:03:00 +
with message-id
and subject line Bug#664171: fixed in initramfs-tools 0.108
has caused the Debian Bug report #664171,
regarding initramfs-tools: initrd cannot be easily disabled when not using
kernel-package
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
664171: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664171
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: initramfs-tools
Version: 0.100
Severity: normal
Tags: patch
Dear Maintainer,
when creating kernel package by other means than make-kpkg
(e.g. using the kernel's make deb-pkg target), initrd creation
cannot be disabled easily, since the appropriate script checks
whether $KERNEL_PACKAGE_VERSION is set, for a reason that seems
entirely unclear to me. The patch below removes the superfluous
check:
diff --git a/kernel/postinst.d/initramfs-tools
b/kernel/postinst.d/initramfs-tools
index 76bb7ee..42474c7 100755
--- a/kernel/postinst.d/initramfs-tools
+++ b/kernel/postinst.d/initramfs-tools
@@ -9,8 +9,8 @@ if [ -z "${version}" ]; then
exit 2
fi
-# exit if custom kernel does not need an initramfs
-if [ -n "${KERNEL_PACKAGE_VERSION}" ] && [ "$INITRD" = 'No' ]; then
+# exit if kernel does not need an initramfs
+if [ "$INITRD" = 'No' ]; then
exit 0
fi
(As a followup, I have a straightforward patch for the kernel ready
that allows easily disabling initrd when invoking make deb-kpkg;
but the patch cannot work as-is before this change without also
setting fake KERNEL_PACKAGE_VERSION, which might confuse some other
script.)
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.11-7
ii findutils 4.4.2-4
ii klibc-utils2.0~rc3-1
ii module-init-tools 3.16-1
ii udev 175-3.1
Versions of packages initramfs-tools recommends:
ii busybox 1:1.19.3-5
Versions of packages initramfs-tools suggests:
ii bash-completion 1:1.99-3
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: initramfs-tools
Source-Version: 0.108
We believe that the bug you reported is fixed in the latest version of
initramfs-tools, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 664...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Prokop (supplier of updated initramfs-tools package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 21 Sep 2012 12:10:28 +0200
Source: initramfs-tools
Binary: initramfs-tools
Architecture: source all
Version: 0.108
Distribution: unstable
Urgency: low
Maintainer: Debian kernel team
Changed-By: Michael Prokop
Description:
initramfs-tools - generic modular initramfs generator
Closes: 619711 664171 682340
Changes:
initramfs-tools (0.108) unstable; urgency=low
.
[ maximilian attems ]
* [a8420de] hook-functions: add hid-generic module (Closes: #682340)
* [9723143] debian/control: Scratch 2.6 mention
.
[ Petr Baudis ]
* [1d6b272] initramfs-tools: allow disabling initrd for make deb-pkg
(Closes: #664171)
.
[ Michael Prokop ]
* [0ffc800] Use setupcon to install system's keymap. Thanks to
Andreas Altergott for the initial
patch. Thanks to Raphaël Hertzog for testing,
feedback and review. (Closes: #619711)
Checksums-Sha1:
7f57efd8b112c150e1d0f67d0726e8dfa3607cfb 1052 initramfs-tools_0.108.dsc
0fea1ed898d64b4ce72faf9513c1603f83c36041 85131 initramfs-tools_0.108.tar.gz
304252da50bf6156037cfe1bb4d1c6b6936b5aae 91098 initramfs-tools_0.108_all.deb
Checksums-Sha256:
3eddead65002d095883ae31590b71895be2e8f2fa588aa3506444e7c0cfe1b39 1052
initramfs-tools_0.108.dsc
f6e5c0feeea94698257462a882b915f835d9ffa2e76bc9e9a8bf3000d09c3e84
Re: Adding x32 support to kernel package
On Wed, Jun 13, 2012 at 9:25 AM, Ben Hutchings wrote: > On Wed, Jun 13, 2012 at 09:08:54AM -0700, Daniel Schepler wrote: >> I was thinking that x32 would just duplicate the linux-image-*-amd64 >> packages, >> similar to the way i386 currently generates amd64 kernel packages. > [...] > > No, that's a pre-multiarch legacy. It will be gone in wheezy+1 (if > not sooner). Any x32 installation should be multiarch amd64 + x32 > (optionally + i386). Ah, good to hear. > Because it takes more archive space, more auto-builder resources, and > offers minimal performance benefits over i386 for most programs. > > However, I hope that Debian can start to support 'partial > architectures' where we deliberately only build some packages. Then > we could build selected packages for x32 where the performance > benefit is found to be worthwhile. OK, I guess that would be a discussion best carried over to debian-devel -- and postponed until after the upcoming release. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadf0c459yjpw5erkgydbcvyi4dny9ccjwq872ebvzonm1ft...@mail.gmail.com
Re: Adding x32 support to kernel package
OK, I eventually figured out that I also need to add x32 to the architecture list in debian/config/defines. Then I also changed the x32 compiler to gcc-4.7 by following the example of alpha using gcc-4.5. But then checking debian/control, it turned out that the -amd64 header packages were depending on both gcc-4.6 and gcc-4.7 on both amd64 and x32. So I just skipped building actual kernel packages for now and invoked binary-libc-dev_x32 manually. I was thinking that x32 would just duplicate the linux-image-*-amd64 packages, similar to the way i386 currently generates amd64 kernel packages. As for the installer, I guess it would be up to them whether they want to build an x32 installer, or just add an option to the amd64 installer to install an x32 system. (Or maybe even make the amd64 installer based on x32, since I can't imagine the installer ever needing more than 4G address space in a single process.) I'm curious why you think Debian wouldn't want to support x32. It's already in dpkg, and the binutils and eglibc maintainers weren't rejecting the idea of eventually adding support when I had exchanges with them. Also, I've been seeing news that Ubuntu does plan to support x32 eventually. (Sorry for the lack of quotation and possibly broken threading -- I'm not currently subscribed to debian-kernel so I didn't get a copy of the message.) -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206130908.55019.dschep...@gmail.com
Re: Adding x32 support to kernel package
On Wed, Jun 13, 2012 at 09:08:54AM -0700, Daniel Schepler wrote: > OK, I eventually figured out that I also need to add x32 to the architecture > list in debian/config/defines. Then I also changed the x32 compiler to > gcc-4.7 > by following the example of alpha using gcc-4.5. But then checking > debian/control, it turned out that the -amd64 header packages were depending > on both gcc-4.6 and gcc-4.7 on both amd64 and x32. So I just skipped > building > actual kernel packages for now and invoked binary-libc-dev_x32 manually. > > I was thinking that x32 would just duplicate the linux-image-*-amd64 > packages, > similar to the way i386 currently generates amd64 kernel packages. [...] No, that's a pre-multiarch legacy. It will be gone in wheezy+1 (if not sooner). Any x32 installation should be multiarch amd64 + x32 (optionally + i386). > As for the > installer, I guess it would be up to them whether they want to build an x32 > installer, or just add an option to the amd64 installer to install an x32 > system. (Or maybe even make the amd64 installer based on x32, since I can't > imagine the installer ever needing more than 4G address space in a single > process.) > > I'm curious why you think Debian wouldn't want to support x32. [...] Because it takes more archive space, more auto-builder resources, and offers minimal performance benefits over i386 for most programs. However, I hope that Debian can start to support 'partial architectures' where we deliberately only build some packages. Then we could build selected packages for x32 where the performance benefit is found to be worthwhile. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120613162559.gj2...@decadent.org.uk
Re: Adding x32 support to kernel package
On Tue, 2012-06-12 at 20:02 -0700, Daniel Schepler wrote: > Hi, over the past week or two I've been working on bootstrapping Debian > packages for x32. As of now, linux-libc-dev is the last remaining package > before I have enough built (at least with by-hand builds) to be able to do a > debootstrap. > > So, I've been trying to add x32 support to the linux-2.6 version in > experimental, but I'm stuck. I tried copying debian/config/amd64 to > debian/config/x32 and debian/installer/amd64 to debian/installer/x32, and > regenerating debian/control, but the new architecture still isn't registering > in debian/rules.gen: But x32 is a partial architecture; there will never be a kernel or installer for it. The current kernel package doesn't support that at all. > dh_testdir > /usr/bin/make -f debian/rules.gen source_x32 > make[1]: Entering directory `/home/lfs/src/debian/linux-2.6/linux-2.6-3.4.1' > make[1]: *** No rule to make target `source_x32'. Stop. > make[1]: Leaving directory `/home/lfs/src/debian/linux-2.6/linux-2.6-3.4.1' > make: *** [debian/stamps/source-base] Error 2 > > According to debian/rules, it looks like debian/rules.gen is auto-generated > by > debian/bin/gencontrol.py, along with debian/control. Yes. > So -- what am I missing that I need to get x32 rules generated? How can I tell you that when you haven't shown your work so far? > Also, could I request that CONFIG_X86_X32 be enabled for amd64? I don't want to do that unless the project makes a decision to support x32. Which I don't think it will. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Adding x32 support to kernel package
Hi, over the past week or two I've been working on bootstrapping Debian packages for x32. As of now, linux-libc-dev is the last remaining package before I have enough built (at least with by-hand builds) to be able to do a debootstrap. So, I've been trying to add x32 support to the linux-2.6 version in experimental, but I'm stuck. I tried copying debian/config/amd64 to debian/config/x32 and debian/installer/amd64 to debian/installer/x32, and regenerating debian/control, but the new architecture still isn't registering in debian/rules.gen: dh_testdir /usr/bin/make -f debian/rules.gen source_x32 make[1]: Entering directory `/home/lfs/src/debian/linux-2.6/linux-2.6-3.4.1' make[1]: *** No rule to make target `source_x32'. Stop. make[1]: Leaving directory `/home/lfs/src/debian/linux-2.6/linux-2.6-3.4.1' make: *** [debian/stamps/source-base] Error 2 According to debian/rules, it looks like debian/rules.gen is auto-generated by debian/bin/gencontrol.py, along with debian/control. So -- what am I missing that I need to get x32 rules generated? Also, could I request that CONFIG_X86_X32 be enabled for amd64? -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206122002.20682.dschep...@gmail.com
Bug#664171: Info received (initramfs-tools: initrd cannot be easily disabled when not using kernel-package)
Hi! Ping, any news? Thanks, Petr "Pasky" Baudis -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120511151511.gi6...@machine.or.cz
Bug#664171: initramfs-tools: initrd cannot be easily disabled when not using kernel-package
Package: initramfs-tools
Version: 0.100
Severity: normal
Tags: patch
Dear Maintainer,
when creating kernel package by other means than make-kpkg
(e.g. using the kernel's make deb-pkg target), initrd creation
cannot be disabled easily, since the appropriate script checks
whether $KERNEL_PACKAGE_VERSION is set, for a reason that seems
entirely unclear to me. The patch below removes the superfluous
check:
diff --git a/kernel/postinst.d/initramfs-tools
b/kernel/postinst.d/initramfs-tools
index 76bb7ee..42474c7 100755
--- a/kernel/postinst.d/initramfs-tools
+++ b/kernel/postinst.d/initramfs-tools
@@ -9,8 +9,8 @@ if [ -z "${version}" ]; then
exit 2
fi
-# exit if custom kernel does not need an initramfs
-if [ -n "${KERNEL_PACKAGE_VERSION}" ] && [ "$INITRD" = 'No' ]; then
+# exit if kernel does not need an initramfs
+if [ "$INITRD" = 'No' ]; then
exit 0
fi
(As a followup, I have a straightforward patch for the kernel ready
that allows easily disabling initrd when invoking make deb-kpkg;
but the patch cannot work as-is before this change without also
setting fake KERNEL_PACKAGE_VERSION, which might confuse some other
script.)
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.11-7
ii findutils 4.4.2-4
ii klibc-utils2.0~rc3-1
ii module-init-tools 3.16-1
ii udev 175-3.1
Versions of packages initramfs-tools recommends:
ii busybox 1:1.19.3-5
Versions of packages initramfs-tools suggests:
ii bash-completion 1:1.99-3
-- no debconf information
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120316024422.14158.69547.report...@machine.or.cz
Re: kernel-package for wheezy
On Sun, 29 Jan 2012 17:09:32 -0500 (EST), Ben Hutchings wrote: > > kernel-package is apparently not compatible with Linux 3.x and I don't > believe it can be released with wheezy in this state. > > You have not uploaded a new version for 18 months. If you do not have > time to work on kernel-package, please RFH/RFA/orphan it as appropriate. I don't mean to butt in to a private conversation here, gentlemen, but I too have noticed the problem with kernel-package and Linux 3.x, and I have published an unofficial patch that seems to enable it to work. The patch is available here http://users.wowway.com/~zlinuxman/kernel-package/linuxv3.diff I refer to this patch on my kernel-building web page http://users.wowway.com/~zlinuxman/Kernel.htm As I state in my web page, this is an unofficial patch: it is not provided by, nor endorsed by, the upstream author or the Debian package maintainer for kernel-package (i.e. Manoj). It seems to work for me and for my purposes, but I do not warrant the patch to be free from defects. Take this with as many grains of salt as you think it's worth. P.S. kernel-package is also incompatible with make 3.82 -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1851217686.783815.1327878307221.javamail.r...@md01.wow.synacor.com
kernel-package for wheezy
kernel-package is apparently not compatible with Linux 3.x and I don't believe it can be released with wheezy in this state. You have not uploaded a new version for 18 months. If you do not have time to work on kernel-package, please RFH/RFA/orphan it as appropriate. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: [PATCH kernel-wedge] Add support for building within a kernel package
On Sun, 2011-09-04 at 20:06 -0400, Joey Hess wrote:
> I don't want to waste your time, but there are enough changes here
> that a split patchset would improve reviewing.
Perhaps, but they're really not huge.
> > if [ "$os" = "linux" ] ; then
> > - if [ ! -e "$moddir/modules.dep" ]; then
> > - echo "no $moddir/modules.dep. This file is required by
> > kernel-wedge" >&2
> > - exit 1
> > + if [ -e "$moddir/modules.dep" ]; then
> > + modulesdep=$moddir/modules.dep
> > + else
> > + modulesdep=$tmpdir/modules.dep
> > + depmod ${SOURCEDIR:+-b $SOURCEDIR} -V $installedname -n
> > >$modulesdep
>
> Shouldn't depmod be passed a System.map here? My experience with d-i's
> build system's use of depmod has taught me to always provide a
> System.map to it when the running kernel may differ from the kernel
> being prepared.
According to my reading of the manual page, it only wants System.map
when checking for undefined symbols (the -e option). And strace shows
that it does not attempt to open any default System.map file.
But more importantly, the -V option is *completely* bogus, so thank you
for bringing my attention back to this command.
Ben.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH kernel-wedge] Add support for building within a kernel package
I don't want to waste your time, but there are enough changes here
that a split patchset would improve reviewing.
> if [ "$os" = "linux" ] ; then
> - if [ ! -e "$moddir/modules.dep" ]; then
> - echo "no $moddir/modules.dep. This file is required by
> kernel-wedge" >&2
> - exit 1
> + if [ -e "$moddir/modules.dep" ]; then
> + modulesdep=$moddir/modules.dep
> + else
> + modulesdep=$tmpdir/modules.dep
> + depmod ${SOURCEDIR:+-b $SOURCEDIR} -V $installedname -n
> >$modulesdep
Shouldn't depmod be passed a System.map here? My experience with d-i's
build system's use of depmod has taught me to always provide a
System.map to it when the running kernel may differ from the kernel
being prepared.
--
see shy jo
signature.asc
Description: Digital signature
[PATCH kernel-wedge] Add support for building within a kernel package
ommands/gen-control
index ed3f612..3f75211 100755
--- a/commands/gen-control
+++ b/commands/gen-control
@@ -11,7 +11,10 @@ my %packages;
my @builddeps;
my %excluded;
-if (open(EXCLUDED, "exclude-packages")) {
+my $fixkernelversion = $ARGV[0];
+my $configdir = ($ARGV[1] || '.');
+
+if (open(EXCLUDED, "$configdir/exclude-packages")) {
while () {
chomp;
$excluded{$_}=1;
@@ -19,7 +22,7 @@ if (open(EXCLUDED, "exclude-packages")) {
close EXCLUDED;
}
-open(KVERS, "kernel-versions") || die "kernel-versions: $!";
+open(KVERS, "$configdir/kernel-versions") || die "kernel-versions: $!";
while () {
chomp;
next if /^#/ || ! length;
@@ -28,22 +31,32 @@ while () {
if (! length $arch || ! length $kernelversion || ! length $flavour) {
die "parse error";
}
+ if (defined($fixkernelversion)) {
+ $kernelversion = $fixkernelversion;
+ } elsif ($kernelversion eq "-") {
+ die "kernel version not set in file or on command line";
+ }
push @versions, [ $arch, $kernelversion, $flavour ];
- foreach my $pkg (split(", ", $builddep)) {
- push @builddeps, "$pkg [$arch]";
+ if ($builddep ne "-") {
+ foreach my $pkg (split(", ", $builddep)) {
+ push @builddeps, "$pkg [$arch]";
+ }
}
}
close KVERS;
-open(STUB, "debian/control.stub") || die "debian/control.stub: $!";
-while () {
- chomp;
- if (/^Build-Depends:/) {
- $_=join(", ", $_, @builddeps);
+# Building with installed kernel package, or as part of a package?
+if (@builddeps) {
+ open(STUB, "debian/control.stub") || die "debian/control.stub: $!";
+ while () {
+ chomp;
+ if (/^Build-Depends:/) {
+ $_=join(", ", $_, @builddeps);
+ }
+ print $_."\n";
}
- print $_."\n";
+ close STUB;
}
-close STUB;
sub read_package_list
{
@@ -96,7 +109,7 @@ sub read_package_list
close LIST;
}
read_package_list("/usr/share/kernel-wedge/package-list");
-read_package_list("package-list");
+read_package_list("$configdir/package-list");
foreach my $ver (@versions) {
my ($arch, $kernelversion, $flavour) = @$ver;
@@ -121,14 +134,14 @@ foreach my $ver (@versions) {
# Check for a modules list file for this architecture and
# package.
my $modlistdir="";
- if (-d "modules/$arch-$flavour") {
- $modlistdir="modules/$arch-$flavour";
+ if (-d "$configdir/modules/$arch-$flavour") {
+ $modlistdir = "$configdir/modules/$arch-$flavour";
}
- elsif (-d "modules/$flavour") {
- $modlistdir="modules/$flavour";
+ elsif (-d "$configdir/modules/$flavour") {
+ $modlistdir = "$configdir/modules/$flavour";
}
else {
- $modlistdir="modules/$arch";
+ $modlistdir = "$configdir/modules/$arch";
}
next unless -e "$modlistdir/".$package->("Package");
diff --git a/commands/gen-deps b/commands/gen-deps
index 94e77be..9dfd610 100755
--- a/commands/gen-deps
+++ b/commands/gen-deps
@@ -7,6 +7,7 @@ my $arch=`dpkg-architecture -qDEB_HOST_ARCH`;
chomp $arch;
my $flavour=$ARGV[0];
+my $configdir = ($ARGV[1] || '.');
my @out;
@@ -26,14 +27,14 @@ sub read_package_list
my @depends=split(", ", $1);
# Skip packages that are not built for this
architecture.
my $modlistdir="";
- if (-d "modules/$arch-$flavour") {
- $modlistdir="modules/$arch-$flavour";
+ if (-d "$configdir/modules/$arch-$flavour") {
+ $modlistdir =
"$configdir/modules/$arch-$flavour";
}
elsif (-d "modules/$flavour") {
- $modlistdir="modules/$flavour";
+ $modlistdir = "$configdir/modules/$flavour";
}
else {
- $modlistdir="modules/$arch";
+ $modlistdir = "$configdir
Re: kernel-package - English Language Typo (In Synaptic's Description)
On Sat, Jul 16, 2011 at 09:56:27PM -0400, Tin Kidneys wrote: > Hey folks, > > Typo i spotted while installing the kernel-package package in Debian Testing > (Wheezy) on AMD64. > > I realize it's really not a big deal, but i just wanted to let you know just > in case. [...] 'kernel-package' is no longer maintained by the kernel team. Please use 'reportbug kernel-package' to report this. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110717060156.gv29...@decadent.org.uk
