Re: bugs.debian.org is randomly failing for src:linux
On Tue, 03 Jul 2018, Romain Perier wrote: > I am a Debian contributor. Currently, we have a ton of linux kernel > bugs assigned to src:linux. > Most of the time http://bugs.debian.org/src:linux is failing with an > error "500 Internal Server Error". > > After discussing about the issue on IRC, it seems to be caused by a > too important number of bugs on our side. Several hacks were > suggested, I have tried to use bugs-master or bugs-buxtehude instead, > these worked for a time, but it's still randomly failing. > > Would you have a solution or an idea of the problem ? Yeah, I'm aware of the issue, and unfortunately, the solution is quite complicated and involves larger changes to the way bugs are served by the BTS. However, these changes *are* in progress, and eventually they should be fixed. I've fixed a few of the lower hanging fruit, but src:linux keeps breaking as new bugs are filed and the archive itself gets larger. I'll try to fix a few more as I get a chance. While you're waiting for me to do that, https://bugs-devel.debian.org/cgi-bin/pkgreport.cgi?src=linux works, and I will try to keep it working. I haven't advertised this widely because I will likely break it from time to time (and the interface will definitely change). -- Don Armstrong https://www.donarmstrong.com Those who begin coercive elimination of dissent soon find themselves exterminating dissenters. Compulsory unification of opinion achieves only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. 624 (1943)
Re: jessie won't install/boot on a Dell Poweredge R815
On Wed, 22 Jun 2016, Jeffrey Mark Siskind wrote: > and attempted > >mdadm /dev/md0 --add /dev/sda1 >mdadm /dev/md0 --add /dev/sdb1 >mdadm /dev/md0 --add /dev/sdc1 >mdadm /dev/md0 --add /dev/sdd1 >mdadm /dev/md0 --add /dev/sde1 >mdadm /dev/md0 --add /dev/sdf1 > > but these all failed. This is the wrong command; it should be mdadm --assemble /dev/md0 /dev/sd[abcdef]1; And that should only be done if the md0 device doesn't show up in the initrd when you cat /proc/mdstat. What's happened is that the raid1 device now has 12 drives instead of 6, which basically isn't going to work at all. You should be able to just directly reinstall jessie on this machine; I'd also zero out the superblocks on the devices in /dev/md0, and then assuming that the syncing has proceeded enough, you should be able to install grub with an appropriate rootdelay and get it to boot. (Again, in theory.) -- Don Armstrong https://www.donarmstrong.com The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe
Re: jessie won't install/boot on a Dell Poweredge R815
On Tue, 21 Jun 2016, Jeffrey Mark Siskind wrote: > http://upplysingaoflun.ecn.purdue.edu/~qobi/20160619_140357.jpg Are you certain that there isn't a PERC H700 in this machine? [Sort of odd that mpt2sas is triggering a state error in your screenshot if there actually isn't one.] > I don't believe that I have any add-in cards. The machine was > purchased straight from Dell. It has six SATA disks and 4 gigabit > ethernet ports. It has four 12-core AMD CPUs and 128GB RAM. The output > of lspci on an indentical machin purchased at the same time that is > still running wheezy is enclosed below. OK. This: > 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI > SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] makes me think that the SATA controller is in IDE/Legacy mode instead of AHCI. In theory, this shouldn't matter, but it's possible that this is also a problem. I'd try switching it in the bios and see what happens. >What does the kernel output while it is detecting the disks and >partitions? Remove the quiet option from the kernel command line by editing it in grub. > Do all of the drives show up properly? echo /dev/sd*; should give you an idea of what is there in the initramfs. >When the boot fails, can you read from the underlying block >devices? more /dev/sda; should work, I believe. > I don't know what one can do in at the initramfs command prompt. If you give > me some commands, I will try them out and post the output. > >Does specifying delay=20 or similar result in a successful boot? > I will try this. This should actually be rootdelay=20; sorry. > I will try to get this info. It will require me to redo the exercise > of a fresh jessie install from USB. I'll have to take and post screen > pictures because I have no way to capture the console output. I believe the R815 still has a serial port; you can just plug in a serial cable and append an appropriate serial tty option to the kernel command line to get output as text. > But again note, that I do not believe that there are any disk hardware > errors. And I do not believe that there are any data errors in the > layout of the ext3 file system, the layout of the md0 raid array, or > the partition tables. The reason is that after the failed jessie > install, I reinstall a fressh wheezy from USB. I don't repartition. > And I don't rebuild md1 and don't rebuild /aux. But I do rebuild md0 > and / as part of the fresh install. And it works. Yes; it's possible that a change in one of the drivers between the wheezy and jessie kernels is exposing a firmware bug (or there's a bug in the kernel itself) which is causing this issue. What I'm trying to do is get enough information so that the error is obvious. -- Don Armstrong https://www.donarmstrong.com What I can't stand is the feeling that my brain is leaving me for someone more interesting.
Re: jessie won't install/boot on a Dell Poweredge R815
On Tue, 21 Jun 2016, Jeffrey Mark Siskind wrote: > Please note that all of the above systems have / as md0 RAID1. The fresh > install of jessie was successfull on all but the R815s. > >> Then it fails to reboot and goes into the initramfs. I have a > picture of >> the screen if anybody wishes. > >Yes please. Also please use the 'rescue' boot option which enables >more verbose logging to the screen. > > Thanks for your help. > > Here is a screen picture. Could you upload this to an image paste site or send it along (or use a serial console to get it as text?) > I conjecture that the jessie kernel has difficulty accessing the MD > array on disk. The same problem occurs when I attempt a direct fresh > install of jessie with the installer. Which add-in card are you using on the R815s? What does the kernel output while it is detecting the disks and partitions? Do all of the drives show up properly? Are the blocksizes correct for the partitions? When the boot fails, can you read from the underlying block devices? Do the block devices get detected after the boot fails? Does specifying delay=20 or similar result in a successful boot? > Here is what happens that is strange. When I do a fresh install of jessie, one > of the first things that the installer does is probe for hardware to try to > find the ISO. I have done this about 10 times. Sometimes (about 3 or 4) it > succeeds in finding the ISO. Sometimes (the rest) it comes up with a red > screen and claims that it can't find the ISO. In all cases, I am booting the > installer from the same USB dongle with the same data on it. I made the dongle > as follows: > ># cd /tmp ># wget > http://ftp.nl.debian.org/debian/dists/jessie/main/installer-amd64/current/images/hd-media/boot.img.gz ># wget > http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/8.5.0+nonfree/amd64/iso-cd/firmware-8.5.0-amd64-netinst.iso ># zcat boot.img.gz >/dev/sdf ># mount /dev/sdf /mnt ># cp firmware-8.5.0-amd64-netinst.iso /mnt/. You can actually just cat firmware-8.5.0-amd64-netinst.iso > /dev/sdf; > Every time so far, md1 has all 6 components. But md0 has only some of > the components, sometimes 5/6, sometimes 4/6, and sometimes 1/6. And > every time it is a different set of components. Even though, just a > few minutes earlier, I was running wheezy and md0 had all 6 > components. I do > > mdadm /dev/md0 --add > > but it refuses. I forget the error. The error would be useful to know. Most likely one or more of them dropped out of the array for some reason and you're booting off of one which has a lower event count and it won't assemble. But it could be any number of things. The output of mdadm --examine /dev/sd[abcdef]1; when md0 fails to assemble would also be useful. -- Don Armstrong https://www.donarmstrong.com S: Make me a sandwich B: What? Make it yourself. S: sudo make me a sandwich B: Okay. -- xkcd http://xkcd.com/c149.html
Bug#742109: Acknowledgement (Soft lookup during port scan and IPTables log enabled)
On Fri, 28 Mar 2014, daniel.gas...@basf.com wrote: > any update on this bug report so far? > Do you need further information from us? This looks awfully like https://bugzilla.kernel.org/show_bug.cgi?id=6816. Presumably, you're writing the LOG requests to something (serial console or similar) which cannot keep up, and the printk blocks. You should probably switch to using -j ULOG and ulogd instead of -j LOG. [As a note, you can just e-mail bug...@bugs.debian.org; sending mail to owner@ goes to the administrator of the bug tracking system, not the individual maintainers.] -- Don Armstrong http://www.donarmstrong.com I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered. My life is my own. I resign. -- Patrick McGoohan as Number 6 in "The Prisoner" -- 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/20140328161713.gi16...@teltox.donarmstrong.com
Bug#721002: Please set CONFIG_HID_HUION=m
Package: src:linux Version: 3.11~rc4-1~exp1 Severity: minor Please set CONFIG_HID_HUION=m; this driver handles a series of cheap tablet input devices which was recently added to the kernel. -- Don Armstrong http://www.donarmstrong.com DIE! -- Maritza Campos http://www.crfh.net/d/20020601.html -- 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/20130826223626.gs27...@rzlab.ucr.edu
Bug#649735: Null pointer dereference in sd_revalidate_disk
I've just seen this again in 3.2.4-1, and so it probably still hasn't been fixed yet. The patch to fix it is here, and it will presumably make it into newish releases: http://lkml.org/lkml/2012/2/21/443 Don Armstrong -- With one simple pill we cured unhappiness and art -- a softer world #437 http://www.asofterworld.com/index.php?id=437 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20120306210025.gv3...@rzlab.ucr.edu
Re: Bug#607368: Call for Vote: Kernel ABI numbering policy
On Mon, 27 Feb 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#607368: Call for Vote: Kernel ABI numbering
> policy"):
> > I call for a vote on the kernel ABI numbering policy bug with the
> > following ballot:
> >
> > A) The technical committee declines to override the kernel maintenance
> > team's ABI numbering policy.
> >
> > B) Further discussion
>
> I vote AB.
With Ian's vote, the outcome is no longer in doubt, and the decision is:
A) The technical committee declines to override the kernel maintenance
team's ABI numbering policy.
Don Armstrong
--
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
-- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.html
http://www.donarmstrong.com http://rzlab.ucr.edu
--
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/20120227173258.gf30...@rzlab.ucr.edu
Re: lkcl interference with initramfs-tools bug handling
On Fri, 26 Aug 2011, Ben Hutchings wrote: > http://bugs.debian.org/636123#138 > http://bugs.debian.org/636123#159 > http://bugs.debian.org/636123#172 > http://bugs.debian.org/638896#16 > http://bugs.debian.org/638896#26 Ok. These aren't quite the smoking gun I was looking for, but they're certainly problematic interactions. After bothering to go through everything else, I find some continuing antagonizing interactions, coupled with some useful reports. I'm going to restrict the user from interacting with the BTS, but I may remove that restriction after further discussion with the user. As a side note, it seems to me that a large number of the issues with conflict between maintainers and users are reported to me come the linux-2.6 package. Exchanges like this[1]: > I'd say this is fairly serious, and am not going to hang about: > will be moving this data onto ext3 as quickly as possible. And yet ext4 works fine for other people. aren't terribly productive. It's much easier for me to deal with problematic BTS interactions when I don't get the impression that both sides are contributing to the problem. Don Armstrong 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636290#10 -- "There's no problem so large it can't be solved by killing the user off, deleting their files, closing their account and reporting their REAL earnings to the IRS." -- The B.O.F.H.. http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110826022102.gc23...@teltox.donarmstrong.com
Re: lkcl interference with initramfs-tools bug handling
On Tue, 23 Aug 2011, maximilian attems wrote: > On Mon, Aug 22, 2011 at 09:10:17PM +0100, Ben Hutchings wrote: > > Luke Kenneth Casson Leighton (lkcl) reported bug > > #636123, which then received a follow-up which is very clearly (to me) > > this guy is adding to much noise, so that various bug reports get > useless. if strong words didn't help yet, please cut him off. It'd help if I was given links to specific messages that are problematic so I don't have to search through the whole set of bugs which this person has interacted with.[0] Though, other messages from this individual[1], my bar is not going to be very high to restrict him from mailing the BTS. Don Armstrong 0: http://bugs.debian.org/cgi-bin/pkgreport.cgi?correspondent=lkcl%40lkcl.net 1: http://lists.debian.org/debian-arm/2011/08/msg00155.html -- A citizen of America will cross the ocean to fight for democracy, but won't cross the street to vote in a national election. -- Bill Vaughan http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110825230337.gx5...@rzlab.ucr.edu
Re: Bug#607368: Please decide how kernel ABI should be managed
On Tue, 04 Jan 2011, Julien BLACHE wrote: > Don Armstrong wrote: > > Julien: Are you currently shipping a kernel in production which > > would be affected by this change if we don't change the ABI > > number? Or does this only affect cases where you are testing > > squeeze? Could it be > > I have 30 beta-testers that are affected by this issue on the > workstations they have started using for their everyday work. > Although it's still a beta phase, at this point, these workstations > are to be considered "in production" given the users have basically > made the switch now. Ok. My main concern here is what exactly would happen if we were to ignore the ABI change for this particular issue, and then put in place some kind of a process where the kernel team could be informed of downstream users of the ABI. From my current understanding, the ABI number is only meant to cover some of the symbols which can be used externally, not all of them. [Specifically, those that the kernel team are aware of being used externally.] > Full deployment involves over a thousand workstations. But presumably they're not running a testing version affected by this. > > worked around by using DKMS or similar with prebuilt binaries and > > requiring exact kernel version dependencies? > > DKMS is useless if the ABI number doesn't change, in its current > form. If DKMS was changed to rebuild all modules when the kernel > package is upgraded, we'd still have issues with on-disk modules not > matching the running kernel ABI until the machine is rebooted. This > can sometimes take two or three weeks if a long-running computation > is running on the machine. Presumably this wouldn't be much of an issue, unless users are going to be newly loading these modules. [Which I would hope wouldn't be the case if you were running a long-running computation.] > As to using strict dependencies... it makes all of the above even > worse. Certainly; there's a cost to be born on both sides. The most important thing to avoid from my perspective is a kernel which when booted has modules that cannot be loaded. > And I'll ask again: what's the point of the kernel ABI number if we > have to use strict dependencies? Some modules may need strict dependencies if they are using symbols not covered by the ABI; this is one possible way that we can resolve this issue. > Seriously? Lets restrict ourselves to discussing the technical issues and possible solutions instead of rhetorical flourishes. Don Armstrong -- The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110104230510.gn4...@rzlab.ucr.edu
Re: Bug#607368: Please decide how kernel ABI should be managed
On Mon, 27 Dec 2010, Ben Hutchings wrote: > On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote: > > Ok. And am I correct in assuming that if the ABI change would > > break an OOT module, you would normally change the ABI number? > > In the time I've been involved in the kernel team, I haven't yet > seen a case where a bug fix required an ABI change that I knew would > break an OOT module. So in this case, if it was clear that the change would have broken an OOT module, the kernel team would normally either postpone the change, or change the ABI number. > Anything distributed by Debian should meet those qualifications, but > users such as Julien also care about modules from other sources. I > normally use Google Code Search to check for OOT modules using > symbols that have changed ABI and which I think might be ignorable. Ok. For some reason, I hadn't originally noticed that this was concerning an OOT module which Debian itself didn't actually distribute. [Julien: I'm correct in that, right?] But that's probably fine. > > How are the symbols that those OOT modules use communicated to the > > kernel team? > > They aren't. Would putting the onus on OOT maintainers to maintain such a list be of benefit to the kernel maintainer team? > > What does the kernel maintainer team feel should be done by the > > maintainer in this case to ensure continuity of upgrades and rebuilds > > of the OOT modules? > [...] > > We recommend that OOT module package makes use of DKMS. DKMS > includes hook scripts to trigger rebuilding OOT modules > automatically for each new kernel ABI version, if the end user or > administrator installs the module source and the appropriate > linux-headers package. In a more tightly controlled environment > where such packages should not be installed on production servers, > the administrator must rebuild modules elsewhere and deploy them > along with the kernel upgrade. DKMS provides various means for this. Makes sense. What about this case? What should Julien do? Julien: Are you currently shipping a kernel in production which would be affected by this change if we don't change the ABI number? Or does this only affect cases where you are testing squeeze? Could it be worked around by using DKMS or similar with prebuilt binaries and requiring exact kernel version dependencies? Don Armstrong -- I don't care how poor and inefficient a little country is; they like to run their own business. I know men that would make my wife a better husband than I am; but, darn it, I'm not going to give her to 'em. -- The Best of Will Rogers http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110104045638.gg5...@teltox.donarmstrong.com
Re: Bug#607368: Please decide how kernel ABI should be managed
On Sun, 26 Dec 2010, Ben Hutchings wrote: > On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote: > > or possibly by using Breaks: for all of the affected out-of-tree > > modules where the change wasn't wide-spread enough to bump the ABI > > number. > > No. Firstly, if we know that an ABI change would break an OOT module > then we try to avoid making that change. Ok. And am I correct in assuming that if the ABI change would break an OOT module, you would normally change the ABI number? Which OOT modules are important enough to result in ABI number changes? How are the symbols that those OOT modules use communicated to the kernel team? What does the kernel maintainer team feel should be done by the maintainer in this case to ensure continuity of upgrades and rebuilds of the OOT modules? > > A slightly wilder alternative, is to Provides: > > linux-kernel-abi-2.6.32-vmware-5 or something for out-of-tree > > modules which aren't going to be covered by the main ABI, but are > > important enough to require compatibility. > > I refuse to support any specific OOT module in this way unless paid > to do so. I expect that other kernel team members will tell you the > same. I personally don't think a Provides: solution is going to be feasible for technical reasons, and coordination reasons. Lets restrict ourselves to discussing the technical reasons why a solution is infeasible, rather than possible monetary impetus required to implement them. Don Armstrong -- No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20101226235512.ga5...@teltox.donarmstrong.com
Re: Bug#607368: Please decide how kernel ABI should be managed
On Sun, 26 Dec 2010, Ben Hutchings wrote: > On Thu, 2010-12-23 at 12:08 -0800, Don Armstrong wrote: > > On Sun, 19 Dec 2010, Julien BLACHE wrote: > > > I think it would be best if this matter would be decided upon before > > > the release of Squeeze, or not too long after it, so as to avoid > > > further breakages in early kernel updates for Squeeze. > > > > I have a couple of (possibly naïve) questions that would help me > > understand the space of solutions here. > > > > 1) What is the kernel ABI currently used to indicate? > > The ABI *number* indicates a range of versions within which newer > versions are likely to remain compatible with modules built for an > older version. So currently there is no guarantee that a specific ABI maintains any kind of compatibility for out of tree modules; it is a best effort based on the kernel maintainer's understanding of what symbols have changed and what out of tree (or even in-tree) modules are affected. Do the kernel maintainers currently track compatibility of in-tree modules for modules which may reasonably be loaded during the lifetime of the install? [I'm thinking of removable device drivers, things like KVM, etc.] > I think I should explain at this point the trade-off we're trying to > make. > > As you know, the kernel-space ABI is volatile and upstream has no > intention of maintaining it, even within a stable/long-term series. > Build configuration changes may also change the ABI in unexpected > ways. Therefore it is generally not practical to maintain ABI within > a single upstream version. Right. > Changing the ABI number requires (1) changing the package names and > (2) rebuilding out-of-tree modules. (1) means linux-2.6 must go > through the NEW queue and also disrupts d-i development (the latter > problem may be reduced within the wheezy release cycle). It also > requires end users and administrators to explicitly remove old > kernel image packages. (2) should not be a huge burden so long as > the modules are packaged using dkms, but auto- rebuilding relies on > having a toolchain installed. Therefore we do not like to change the > ABI number during a stable release or the preceding freeze. So from what I can see, the ideal situation is to not change the kernel ABI number unless we absolutely have to. What I think is missing now, is a discussion of which cases where changing the ABI number is necessary for proper functioning, and which cases of malfunction we feel are acceptable, and which are not. For in tree modules, all of the problems that would occur from upgrading a kernel where the ABI had changed (but not the number) can be resolved by rebooting. I'm personally a bit concerned that these errors may be a bit disconcerting to our users, but that may be something we decide to live with and document. For out of tree modules, these problems can either be resolved by changing the ABI number, or possibly by using Breaks: for all of the affected out-of-tree modules where the change wasn't wide-spread enough to bump the ABI number. A slightly wilder alternative, is to Provides: linux-kernel-abi-2.6.32-vmware-5 or something for out-of-tree modules which aren't going to be covered by the main ABI, but are important enough to require compatibility. Alternatively, we can ignore them, and require that end-users of these out of tree modules know that they must upgrade their out-of-tree modules in lockstep with the kernel. Which in-tree modules should we change the ABI number for? Which out-of-tree modules? How does an out-of-tree module writer know? How can they promote their module to get a Breaks or Provides or whatever? Don Armstrong -- It has always been Debian's philosophy in the past to stick to what makes sense, regardless of what crack the rest of the universe is smoking. -- Andrew Suffield in 20030403211305.gd29...@doc.ic.ac.uk http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20101226202304.gx5...@teltox.donarmstrong.com
Bug#607368: Please decide how kernel ABI should be managed
On Sun, 19 Dec 2010, Julien BLACHE wrote: > I think it would be best if this matter would be decided upon before > the release of Squeeze, or not too long after it, so as to avoid > further breakages in early kernel updates for Squeeze. I have a couple of (possibly naïve) questions that would help me understand the space of solutions here. 1) What is the kernel ABI currently used to indicate? Where do we specify what it guarantees? 2) What are all of the options for handling this situation? Specifically, how should a package maintainer who is maintaining a out-of-tree module which uses symbols from the kernel handle them through an upgrade which changes the symbols? If the symbols need to be covered by the ABI, how can the maintainer get them covered by ABI? What should they do in cases when they are not covered by the ABI? My main concern is that there seems to be no way for oot modules like the vmware modules to sanely keep in step with the kernel ABI. While this may not be a concern for kernel upstream, it's something that we would ideally deal with to avoid issues for our users on upgrades. Don Armstrong -- He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101223200804.gq5...@teltox.donarmstrong.com -- 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/20101223200804.gq5...@teltox.donarmstrong.com
Bug#589118: `rdev` setting ignored
close 589118 thanks On Fri, 16 Jul 2010, Elliott Mitchell wrote: > reopen 589118 > quit If a maintainer closes a bug, and after a single round of explanation, still does not agree with reopening the bug, the bug should stay closed. If you disagree with the maintainer, then your choices are to either attempt to: 1) convince the maintainer that your viewpoint is correct, preferably by submitting a patch which fixes the perceived problem, along with rationale as to why the patch is correct. 2) attempt to convince the technical committee that the maintainer is incorrect, and should be overridden. This necessitates a patch as required for #1. In neither case should you reopen bugs that a maintainer has closed.[1] Continuing to do so will result in restricting your use of cont...@bugs.debian.org. Don Armstrong (on behalf of ow...@bugs.debian.org) 1: It is of course acceptable to reopen a bug in cases when the maintainer is likely to agree with you, but that is clearly not the case here. -- "There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself." -- Bach http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100717020343.gm31...@rzlab.ucr.edu
Re: Removing pseudo package "kernel"
On Sun, 04 Jan 2009, Moritz Muehlenhoff wrote: > The reportbug maintainers told me that current reportbug redirects > bugs filed against "kernel" against the pseudo package > "linux-image". There is no linux-image pseudopackage; it's a non-existant package. [Reassigning bugs to it is wrong.] What'd probably be reasonable is to assign those bugs to something like Source: linux-$(uname -r |cut -f1,2 -d.); instead. Don Armstrong -- A Democracy lead by politicians and political parties, fails. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Removing pseudo package "kernel"
On Sun, 28 Dec 2008, Don Armstrong wrote: > On Sun, 28 Dec 2008, Moritz Muehlenhoff wrote: > > BTS administrators, all bugs have been reassigned to linux-2.6 Can > > you please disable the "kernel" pseudo package? > > If there are no objections, I'll remove this around the 1st of the > year. I've gone ahead and removed the psuedopackage; there will be a bit of a delay before everything gets into sync, but that should happen shortly. I'd also appreciate it if one of you would occasionally check the kernel package to make sure that bugs aren't languishing there from releases of reportbugs which have kernel still listed as a valid psuedopackage. Don Armstrong -- Taxes are not levied for the benefit of the taxed. -- Robert Heinlein _Time Enough For Love_ p250 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Removing pseudo package "kernel"
On Sun, 28 Dec 2008, Moritz Muehlenhoff wrote: > On Wed, Dec 24, 2008 at 10:31:10AM -0700, dann frazier wrote: > > On Wed, Dec 24, 2008 at 02:53:29PM +0100, Moritz Muehlenhoff wrote: > > > Is there any point in keeping the pseudo package "kernel", > > > which still has another 63 bugs? It may have been useful > > > in times, where 12 different source packages existed for > > > the kernels, but seems like a useless duplication of > > > linux-2.6 nowadays. > > > > > > If noone disagrees, I'll poke submitters of the existing > > > bugs, reassign them to linux-2.6 and ask the Debian BTS > > > maintainers to remove the pseudo bug. > > > > seems reasonable to me > > BTS administrators, all bugs have been reassigned to linux-2.6 > Can you please disable the "kernel" pseudo package? If there are no objections, I'll remove this around the 1st of the year. [I should note that the archived bugs that are assigned to the kernel pseudopackage will still exist, but that shouldn't be a huge problem.] (Also, the bugs currently assigned to the linux-2.6 binary package will have to be reassigned to the linux-2.6 source package, but there are a bunch of bugs that have that problem, and I'll be making an anouncement about it later.) Don Armstrong -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#310668: 310668 isn't RC, downgrading
severity 310668 important thanks While this is likely a bug, the severity is at most important, as it doesn't affect everyone, or even every person who has a aha152x card. See http://www.debian.org/Bugs/Developer#severities for information on how the severities are assigned. Don Armstrong -- Taxes are not levied for the benefit of the taxed. -- Robert Heinlein _Time Enough For Love_ p250 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
[MFT set to -legal, as this is becoming legal arcana probably not particularly interesting to any other list.] On Tue, 05 Apr 2005, Sven Luther wrote: > There are two solutions to this issue, either you abide by the GPL > and provide also the source code of those firmware binaries (the > prefered solution :), or you modify the copyright statement of these > files, to indicate that even thought the file per se is under the > GPL, the firmware binary code is not, and give us a licence to > distribute it. Something akin to : > > /* This program, except the firmware binary code, is free software; you can > */ > /* redistribute it and/or modify it under the terms of the GNU General Public > */ > /* License as published by the Free Software Foundation, located in the file > */ > /* LICENSE. > */ > /* Distribution, either as is or modified syntactically to adapt to the > */ > /* layout of the surrounding GPLed code is allowed, provided this copyright > */ > /* notice is acompanying it > */ Just a word of warning: The wording above fails to make it clear what the second clause is applying to. Additionally it has the following restrictions that are probably not intended: 1) Does not specifically allow this firware to be sold as part of an aggregate 2) The range of modifications allowed is rather vague, and implies that the firmware can't be extracted I'd instead suggest applying a pre-existing license like MIT[1] to the firmware portion of the code file, rather than inventing your own licensing text that only partially deals with the problem(s) at issue. (Inventing licensing text is quite often very hazardous to your health.) Don Armstrong 1: http://www.opensource.org/licenses/mit-license.php -- Build a fire for a man, an he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Jules Bean http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: How long is it acceptable to leave *undistributable* files in the kernel package?
[Humberto: Can you please fix your MUA so that it provides In-Reply-To:, References:, and doesn't break threads?] On Wed, 16 Jun 2004, Humberto Massa wrote: > Firmware with _any_ distributable license + kernel (GPL) = > distributable even if non-free. This is not clear a priori. > Firmware and Kernel are agregating only, not derived works. They > don't link together; firmware is not a derived work of the kernel > nor /vice-versa/. The kernel+firmware work is a derived work of the kernel work and the firmware work. I'll assume that you're not arguing that it's not. The question is whether the GPL's exception for mere aggregates applies to such a work. Since that exception only seems to apply to "mere aggregation" on a storage medium, it's quite likely that it doesn't apply at all. In cases like these, unless you can provide clear and convincing arguments that this is "mere aggregation" (which should go to -legal) we should assume that the combined, derivative work cannot be distributed unless both works can satisfy the DFSG. Don Armstrong -- DIE! -- Maritza Campos http://www.crfh.net/d/20020601.html http://www.donarmstrong.com http://rzlab.ucr.edu
