Re: Upcoming changes to Debian Linux kernel packages
Sam Hartman writes: > B) They might already have headers installed. Imagine someone who > installs headers at the same time they install the kernel. Unless they > managed to upgrade the same version of their kernel without also > upgrading their headers, they will still have headers. They can still > build modules against that kernel, either because they installed a new > dkms package, or because one of their dkms packages upgraded. I am also really confused by this discussion and don't entirely understand the motivation for the proposed change to kernel headers, but isn't the situation Sam describes above the normal way Linux kernel headers work and have worked for years? Kernels come with headers matching the same version, if you want headers for external modules you install both packages at the same time via one mechanism or another, and you only remove the kernel and headers when you're pretty sure you will never use that kernel again. When I was using external modules heavily, I routinely kept three or four old kernels and their corresponding headers installed at the same time so that I could easily downgrade if I ran into regressions without having to track down old packages that may have been removed from the archive. This feels like a normal and somewhat obvious Debian systems administration thing to do to me. I realize in the new signing regime every new kernel would have a separate headers package (as opposed to today where the kernel and headers are updated in place with the same package name if there is no ABI change), but to me this doesn't feel like a significant difference for users. I haven't been paying close attention, so maybe I'm wrong, but I feel like most kernel package updates have been ABI updates anyway, particularly in stable. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#994409: task-laptop: please recommend automatic apt proxying
Phil Morrell writes: > Package: task-laptop > Version: 3.53 > Severity: wishlist > I'm not sure on the difference between auto-apt-proxy and > squid-deb-proxy-client. Avahi is already pulled in by task-laptop. Please do not do this. I do not want to have to reason about the security impact of someone who controls local DNS taking over my apt sources. I understand that people believe that this is harmless because of apt signature checking, but it still opens more attack paths and routes to exercise other possible vulnerabilities. The safe default for Debian in any standard installation mode, which I believe includes tasks, is to talk explicitly to Debian infrastructure. If people would like to improve local performance, they should automate the configuration of the machines that they control, with the permission and understanding of the people who are using those machines. We should not enable people who control the local network but not the Debian system to dynamically change security-relevant configuration of that system, which I believe includes apt sources, without explicit permission. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Heads-up: new lintian error: no-human-maintainers
Sean Whitton writes: > On Mon 22 Apr 2019 at 11:03AM -07, Russ Allbery wrote: >> This was a request from ftpmaster so that they had a contact point for >> each package in the case of any problems. If they're happy for this >> requirement to be removed for d-i packages, we're happy to update >> Policy accordingly. Presumably the d-i team is the contact for >> anything related to udebs, so that may fulfill their requirement. (If >> they're unhappy, we should talk more about it.) > Hmm, I think you might be forgetting a bit of context -- unless I'm > forgetting something, the main opposition to the 2017 attempt to kill > the human uploaders requirement was that it would make the MIA process > more difficult for the MIA team to carry out. > Both members and non-members of the MIA team were arguing that. I do > not believe the ftpmasters were involved in that discussion at all. Oh, I'm sorry, you're quite right. I completely forgot about that. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Heads-up: new lintian error: no-human-maintainers
Holger Levsen writes: > I've not really made up my mind of what I think about the general case, > I do think there are some merrits knowing/documenting human maintainers. > I also do think that this doesnt make that much sense for d-i packages. > (And I also think that policy should be changed (and not merely ignored) > if we find that we disagree with whats written in it.) > Shall I file a bug against debian-policy? This was a request from ftpmaster so that they had a contact point for each package in the case of any problems. If they're happy for this requirement to be removed for d-i packages, we're happy to update Policy accordingly. Presumably the d-i team is the contact for anything related to udebs, so that may fulfill their requirement. (If they're unhappy, we should talk more about it.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Charles Plessy <ple...@debian.org> writes: > First, minor point, but I think that #196367 (Clarify Policy on priority > inversion in dependencies) can also be closed by the changes. Thank you! > Second, I would like to propose one more clarification to the > description of the "Important" priority. I believe this is #776557 (and kind of unrelated to this discussion). Maybe move this discussion there? There's already been a fair bit of (rather inconclusive) discussion on that bug. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Control: tags -1 = pending Control: tags 759260 = pending Control: tags 660249 = pending I've merged this patch for the next release. The only change from my proposed wording was that I added this sentence to the description of extra, just to be clear how to treat any packages found in the wild with that priority: This priority should be treated as equivalent to optional. I don't think this will change anything, but it seemed best to be clear. The upgrading-checklist entry for this change: 2.5 Priorities are now used only for controlling which packages are part of a minimal or standard Debian installation and should be selected based on functionality provided directly to users (so nearly all shared libraries should have a priority of optional). Packages may now depend on packages with a lower priority. The extra priority has been deprecated and should be treated as equivalent to optional. All extra priorities should be changed to optional. Packages with a priority of optional may conflict with each other (but packages that both have a priority of standard or higher still may not conflict). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority
Andreas Henriksson <andr...@fatal.se> writes: > Can't help but wonder why not just remove the "extra" (and mentioning it > as deprecated in upgrade notes) rather than explicitly documenting it as > deprecated. I guess keeping it around is useful to avoid people > mass-bug-filing RC-bugs for all current extra packages. I'd like to keep the documentation of extra because, for some time to come, there will be a lot of packages in the wild that will have that priority in their control files (even if they've been overridden by ftp-master in the archive metadata). We therefore need to document that the priority still exists. Hm, it occurs to me that this wording should probably explicitly say that the extra priority should be treated the same as optional if it appears anywhere (although the archive-wide override change will mostly take care of that). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority
eprecated. Use the + optional priority instead. + + + The extra priority was previously used + for packages that conflicted with other packages and + packages that were only likely to be useful to people with + specialized requirements. However, this distinction was + somewhat arbitrary, not consistently followed, and not + useful enough to warrant the maintenance effort. - -Packages must not depend on packages with lower priority values -(excluding build-time dependencies). In order to ensure this, the -priorities of one or more packages may need to be adjusted. - - -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: cdimage?? What should we call it?
Steve McIntyre st...@einval.com writes: We called our main installer images distribution site cdimage.debian.org a long time ago, when that was all it published and most people downloaded images of CDs. Ummm. Things have moved on in the intervening years, and this name is looking more silly over time: * lots of people are using USB sticks * we're providing live images that don't fit on CD * we're providing cloud images (Openstack so far, with others coming soon!) So, I'm looking for suggestions. What should we call it? I had initially thought that images.debian.org is more generic, but it's also likely to confuse people into looking there for pictures... :-) install.debian.org? (get.debian.org is good too.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. [I can understand a bit of wariness of having d-i built with a version of syslinux that isn't being distributed in wheezy, but I think that might need to be discussed and a technical solution fleshed out elsewhere, and probably isn't ripe for a CTTE decision.] In practice, at least for the last couple of release cycles, we freeze unstable for non-leaf packages during the release freeze because otherwise it's too difficult with our current infrastructure to finish the release. I believe this has even been made explicit in release-team updates, although I haven't gone back and checked the exact wording. I concur with Daniel and with Anthony that it does feel like a deficiency in our tools that we don't have a way to distinguish wheezy-targeted packages from post-wheezy development and build wheezy-targeted packages with the build dependencies that will be released with wheezy. If we had such a thing, I think it would save the release team some time, since it would limit the problems caused by uncoordinated library transitions during the release freeze. I also concur with Daniel that it can make development during the release freeze rather annoying when there are multiple branches of upstream that one wants to follow, since we only have one other archive available for packages that aren't eligible for release. But, well, that's the architecture we have right now and we're clearly not going to fix it immediately. Given that, I think it makes sense to, as Daniel mentioned, make it rather explicit that, yes, unstable is frozen for non-leaf packages until we complete the release. And, in this specific case, to revert the syslinux update in unstable (and hopefully upload to experimental) so that we're not building d-i against a package that isn't part of the release. That does take over experimental for that purpose, but, well, there's always personal repositories; that's what I sometimes do when there are more branches of development to juggle than there is space in Debian. It's annoying, and we need better tools, but it's possible. In the longer term, I think it would be interesting to provide some more metadata and automation around the whole release request/unblock/build process than we have right now. For example, I could see some use in a system where one has to explicitly tag a package as being targeted for the next release or not targeted for the next release, which could be communicated to the buildds in some fashion so that they would build release-targeted packages against only the release-targeted packages, and new uploads of release-targeted packages would be automatically diffed and brought to the release team's attention. There could even be a convention for including the justification for the change. (I can see a lot of complexity here in how one would have to set up the archive suites, since you can't just point the buildds at testing since there would be no way to stage library transitions that *are* going into the release, so let me note that this is not a well-thought-out proposal, just the sketch of an idea.) But that's all outside the scope of tech-ctte deliberation, since that's technical design, and regardless isn't something that we would do right now. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vca5rvyu@windlord.stanford.edu
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee bd...@gag.com writes: I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! Yes. This is pretty much exactly how I feel. And I suspect it's a general feeling by a lot of people: we freeze for too long, and we don't like a lot of the implications of that, but we don't know how to do better and get releases out faster because there's a truly intimidating amount of work that has to get done to do the release and all the alternatives seem to make the work even worse. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3qlqdrq@windlord.stanford.edu
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Cyril Brulebois k...@debian.org writes: Bdale Garbee bd...@gag.com (06/02/2013): I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! How is that different from e.g. refraining to upload new libraries to unstable, so that a package needing an upload (say, we need RC bugfixes) doesn't pick new dependencies (on libraries not in testing)? I personally think it's exactly the same problem. I think the situation with libraries is regrettable as well. (Note that, and I'm guessing I speak for Bdale here too, regrettable is not intended to assign any sort of blame! This is the best solution that we've been able to come up with to date as a project. It's just still has some problems.) That's how testing works; and it's been this way for years/releases now (since testing replaced frozen, I think). Yes. It's always a source of some tension, since there are always people who would prefer to have a place to continue to do development in an unstable context even during the release process. (Cue the standard debate over the usability of experimental for this purpose -- I'm sure nearly everyone reading this can fill it in from memory. *grin*) If we could find a way to release some of that tension, that would be great, but it's a hard problem, and there's no way that we're going to come up with a solution to it right now in the middle of the wheezy freeze. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq0dx6xk@windlord.stanford.edu
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Michael Biebl bi...@debian.org writes: On 16.12.2011 18:38, Joey Hess wrote: Christian PERRIER wrote: I'm inclined to follow this advice and would indeed propose that the atomic partman-auto recipe is kept, however without a separate /usr partition (discussions on -devel and the current practice convinced me that a separate /usr is seomthing that probably belongs to the former century..:-) I don't think that d-i should be on the leading edge of this discussion. Once Debian has made up its mind, d-i can be updated to follow the consensus. To me it looks like there is broad consensus that a separate /usr partition should be considered deprecated and this option removed from the installer. There's a bit of disagreement over the deprecation part still, but I think there's a pretty good consensus that people with a separate /usr from / are doing so for fairly edge-case situations, such as wanting a partially encrypted file system, and hence are not the target audience for the pre-constructed partitioning choices in d-i. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa6s5osa@windlord.stanford.edu
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Josh Triplett j...@joshtriplett.org writes: In all of the recent discussions about separate /usr partitions, most people seem to acknowledge them as unusual, special-purpose configurations, even those who use them. To the extent they have a use at all, they primarily have a use for people who have very specific reasons for wanting them, and all of those people will know how to handle partitioning. To a lesser extent, that holds true for having separate partitions for /var, /tmp, or other top-level directories. It seems likely that any such setup will have custom requirements. I don't think these things are alike. Separating /var and /tmp from the rest of the file systems is done because those partitions contain varying amounts of data and often fill if something goes wrong, but can fill without impacting the rest of the system and allowing easy recovery if they're not on the same partition as everything else. Separating /var continues to be good and recommended practice if you're running anything that's likely to produce a lot of output, IMO. (/tmp should probalby just be tmpfs, but that's another discussion.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3bph1ww@windlord.stanford.edu
Re: Package-Type not included in udebs
Raphael Hertzog hert...@debian.org writes: dpkg-dev 1.15.7 stopped outputting the field by default. So this bug can be closed (doing so now). Not really a decision of the committee but I just wanted a decision taken. The lintian tag package-type-in-debian-control can be dropped and replaced by a xc-package-type-in-debian-control that suggests to do the opposite and use the official name. Done for the next Lintian release (as a pedantic tag, since as I understand it there's no functionality change). d-i folks, if you want a higher severity, let us know. Thanks, Raphael! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ljbkpyyv@windlord.stanford.edu
Bug#535197: installation-reports: Successful installation on HP Firebird 802
Package: installation-reports Severity: wishlist -- Package-specific info: Boot method: CD Image version: lenny i386 netinst CD (unknown exact build date or URL) Date: 2009-06-27 Machine: HP Firebird with VoodooDNA 802 Partitions: /dev/mapper/gwaihir-root ext320647548 3659096 15945784 19% / tmpfstmpfs 1942092 8 1942084 1% /lib/init/rw udev tmpfs 10240 156 10084 2% /dev tmpfstmpfs 1942092 0 1942092 0% /dev/shm /dev/sda1 ext2 25 15957204930 8% /boot /dev/mapper/gwaihir-home ext3 103212320 35667708 62301732 37% /home /dev/mapper/gwaihir-pbuilder ext320642428 1093820 18500032 6% /var/cache/pbuilder /dev/mapper/gwaihir-backup ext320642428 2313824 17280028 12% /srv/backup Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: nVidia video drivers version 180.* or higher were required (I used the 185.* version from current unstable). I got no sound with the default lenny kernel, but installing alsa-source 1.0.20 from testing and building those modules worked. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=5.0 (lenny) - installer build 20090123lenny1 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == umame -a: Linux gwaihir 2.6.26-2-486 #1 Thu Mar 26 00:13:41 UTC 2009 i686 unknown lspci -knn: 00:00.0 Host bridge [0600]: nVidia Corporation Device [10de:0a80] (rev b1) lspci -knn: 00:00.1 RAM memory [0500]: nVidia Corporation Device [10de:0a88] (rev b1) lspci -knn: 00:03.0 ISA bridge [0601]: nVidia Corporation Device [10de:0aad] (rev b2) lspci -knn: 00:03.1 RAM memory [0500]: nVidia Corporation Device [10de:0aa4] (rev b1) lspci -knn: 00:03.2 SMBus [0c05]: nVidia Corporation Device [10de:0aa2] (rev b1) lspci -knn: 00:03.3 RAM memory [0500]: nVidia Corporation Device [10de:0a89] (rev b1) lspci -knn: 00:03.4 RAM memory [0500]: nVidia Corporation Device [10de:0a98] (rev b1) lspci -knn: 00:03.5 Co-processor [0b40]: nVidia Corporation Device [10de:0aa3] (rev b1) lspci -knn: 00:04.0 USB Controller [0c03]: nVidia Corporation Device [10de:0aa5] (rev b1) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:04.1 USB Controller [0c03]: nVidia Corporation Device [10de:0aa6] (rev b1) lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: Kernel modules: ehci-hcd lspci -knn: 00:06.0 USB Controller [0c03]: nVidia Corporation Device [10de:0aa7] (rev b1) lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: Kernel modules: ohci-hcd lspci -knn: 00:06.1 USB Controller [0c03]: nVidia Corporation Device [10de:0aa9] (rev b1) lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: Kernel modules: ehci-hcd lspci -knn: 00:08.0 Audio device [0403]: nVidia Corporation Device [10de:0ac0] (rev b1) lspci -knn: 00:09.0 PCI bridge [0604]: nVidia Corporation Device [10de:0aab] (rev b1) lspci -knn: 00:0a.0 Ethernet controller [0200]: nVidia Corporation MCP79 Ethernet [10de:0ab0] (rev b1) lspci -knn: Kernel driver in use: forcedeth lspci -knn: Kernel modules: forcedeth lspci -knn: 00:0b.0 SATA controller [0106]: nVidia Corporation Device [10de:0ab8] (rev b1) lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:0c.0 PCI bridge [0604]: nVidia Corporation Device [10de:0ac4] (rev b1) lspci -knn: Kernel driver in use: pcieport-driver lspci -knn: 00:0d.0 PCI bridge [0604]: nVidia Corporation Device [10de:0ac5] (rev b1) lspci -knn: Kernel driver in use: pcieport-driver lspci -knn: 00:10.0 PCI bridge [0604]: nVidia Corporation Device [10de:0aa0] (rev b1) lspci -knn: 00:15.0 PCI bridge [0604]: nVidia Corporation Device [10de:0ac6] (rev b1) lspci -knn: Kernel driver in use: pcieport-driver lspci -knn: 00:16.0 PCI bridge [0604]: nVidia Corporation Device [10de:0ac7] (rev b1) lspci -knn: Kernel driver in use: pcieport-driver lspci -knn: 00:17.0 PCI bridge [0604]: nVidia Corporation
