Re: Security updates for sarge?
Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > But I think you're right... it's not about getting work done, it's about > politics and a orwellian "all users are equal, DDs are more equal" nonsense. > With every day passing by, it seems even more clearly to me that Debian has > lost its basics and has turned into a project that prefer to deal with > itself for that reason. And now it's even controlled by a venture > capitalist. Great job, well done... :-( Ingo, You appear to be discussing some Debian that doesn't exist. In itself, this isn't surprising - you appear to have spent a significant period of time discussing a Debian that is only mildly related to the Debian that most people appear to perceive. Your postings to debian-devel have generally resulted in large quantities of noise and a complete absence of useful conclusions. You're either a revolutionary arguing on the side of the largely silent majority, or you're in a minority. In the first case, I'd suggest that you engage in making it clearer that a large set of people agree with you. In the latter case, I'd like to request that you stop. Your posts are counter-productive - your style of argumentation repels those who may have sympathy, and inflames those who already disagree with you. Your current activities are accomplishing nothing. There is no advantage to be gained in "I told you so" - instead, you merely delay us from going anywhere. Please. No more. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Mike Hommey <[EMAIL PROTECTED]> wrote: > The point is, some drivers DO require firmwares. I'd rather say: Some > depend on firmware. In that case, if the firmware is non-free, the > driver can't go in main. Is this the case even if the firmware is in a flash chip attached to the device? If the total amount of non-free software on a user's system is the same regardless, why are we concerned about how it's packaged? -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett <[EMAIL PROTECTED]> wrote: > Mike Hommey <[EMAIL PROTECTED]> wrote: > >> The point is, some drivers DO require firmwares. I'd rather say: Some >> depend on firmware. In that case, if the firmware is non-free, the >> driver can't go in main. > > Is this the case even if the firmware is in a flash chip attached to the > device? If the total amount of non-free software on a user's system is > the same regardless, why are we concerned about how it's packaged? Argh. Sorry, I shouldn't be allowed to post while drunk. That was meant to go to -legal, not -devel. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Security updates for sarge?
Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > IIRC, you're one of those Ubuntus, right? No more to be said then... I am not an employee of Canonical, and nor have I ever been. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
Loïc Minier <[EMAIL PROTECTED]> wrote: > * Package name: ibm-acpi This has been integrated into the acpi.sf.net patch, so is fairly likely to end up in the mainstream kernel before too long. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols
Ricardo Mones <[EMAIL PROTECTED]> wrote: > * URL : http://www.softwarestudio.org/libical/ The last version of this appears to have been released in 2002. Is there any sign of ongoing development, and is there any software that actually uses this library? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
Loïc Minier <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> - Sun, Oct 24, 2004: > >> This has been integrated into the acpi.sf.net patch, so is fairly likely >> to end up in the mainstream kernel before too long. > > Oh never read of that, do you have some pointers? Are you sure it's > the same driver? Thanks! http://marc.theaimsgroup.com/?l=acpi4linux&m=109823399515032&w=2 is the response from the acpi maintainer. -- Matthew Garrett | [EMAIL PROTECTED]
An important lesson
Developers, do not allow http://www.google.com/search?q=inurl%3Asecring.gpg to happen to you. -- Matthew Garrett | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Andrew Suffield <[EMAIL PROTECTED]> wrote: > [...] freedom of expression constitutes one of the essential > foundations of a democratic society and one of the basic conditions > for its progress and each individual's self-fulfilment. > > [...] it is applicable not only to "information" or "ideas" that are > favourably received or regarded as inoffensive or as a matter of > indifference, but also to those that offend, shock or disturb. Such > are the demands of pluralism, tolerance and broadmindedness, without > which there is no "democratic society". > Debian is not a democratic society. It is not intended to be a source of all information known to man. It is supposed to be a project to produce a Free operating system. That means: a) Things that are not useful should not be in there b) Things that are gratuitously insulting to a large number of people should not be there unless they're fantastically useful Having this argument over a program that is entirely useless in the first place just makes it harder to have a proper discussion in the cases where it actually matters. Or, putting it another way: failing to include this piece of code does Debian no demonstrable harm. Including it does. I know we have something of a reputation for preferring philosophical masturbation to actually doing the useful thing, but that shouldn't result in a several hundred post flamewar. What are you all, stupid or something? -- Matthew Garrett | [EMAIL PROTECTED]
Re: charsets in debian/control
Thaddeus H. Black <[EMAIL PROTECTED]> wrote: > We are not speaking of a stricken Polish L, a > double-accented Magyar O, or a euro sign. We are > speaking of... well, to tell the truth I have no idea > what these letters are. Have you? More to the point, > should you and I learn to recognize such letters? > Should we expect basic Latin terminal fonts to cover > them? Is it reasonable to marginalize the =E1's and =FC's > of Latin-1 by lumping them with the "squat reversed > esh"? Why is it important that you recognise them? I can't see any reasonable argument against UTF-8 that doesn't also remove anything other than ascii. > In my view, a terminal which cannot correctly display > the "=E1" is somewhat broken, and a user who does not > recognize the "=E1" probably should learn. I would not > say the same with respect to the "squat reversed esh". > However, this is just my view. Defining the character set as utf-8 means that any non-unicode capable application is going to have issues, yes. But so does defining the character set as anything other than ascii - people using a non-8859-1 terminal encoding won't be able to read any of the non-ascii characters in the file. The only two character sets that make any sense whatsoever in the Unix world are ascii and UTF-8. I'd be happy with either, but I've got a fairly anglo-centric viewpoint. I can see a strong argument for maintainers actually being allowed to spell their name properly, even if pragmatism suggests that we want a latinised version available as well. -- Matthew Garrett | [EMAIL PROTECTED]
Re: charsets in debian/control
Daniel Burrows <[EMAIL PROTECTED]> wrote: > iso-8859-1 is an 8-bit charset, while Unicode is a 32-bit [0] charset. =20 > Storing and manipulating iso-8859-1 strings requires no changes to internal= >=20 > datatypes (only conversions for input and output); storing and manipulating= >=20 > Unicode means you have to switch to a completely different set of=20 > string-handling functions for all internal operations. utf-8 is an 8-bit encoding of unicode, using variable length characters. Traditional string manipulation routines work fine, except in the case where you need to know the number of characters rather than the number of bytes. This is typically not a large number of areas of code. > [0] According to the libc manual, only 16 bits have been assigned, but GN= > U=20 > systems use 32-bit encoding internally if the libc transcoding functions ar= > e=20 > used. The libc manual is out of date. We've been using more than 16 bits for a while. -- Matthew Garrett | [EMAIL PROTECTED]
Bug#284909: ITP: vbetool -- run real-mode video BIOS code to alter hardware state
Package: wnpp Severity: wishlist * Package name: vbetool Version : 0.1 Upstream Author : Matthew Garrett <[EMAIL PROTECTED]> * URL : http://www.srcf.ucam.org/~mjg59/laptops/ * License : GPL Description : run real-mode video BIOS code to alter hardware state vbetool uses lrmi in order to run code from the video BIOS. Currently, it is able to alter DPMS states, save/restore video card state and attempt to initialize the video card from scratch. vbetool is primarily useful for attempting to recover from ACPI S3, since most hardware leaves the video card in an undefined state. Since it uses vm86, it will currently only work on x86 hardware - in the long run, I'd hope to move it over to Scitech's x86emu and give it more portability. It's also currently in the form of three separate tools, but I'll merge those in the near future. Currently, the combination of: switch away from X vbetool savestate >foo vbetool dpms off (suspend) vbetool post vbetool restorestate
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Because if it were stored on the device itself, and always packaged > with the device, then there *still* wouldn't be a dependency, because > all owners of the hardware would already have the firmware. In most cases, the owner of the device will already have the firmware. If the package had code to copy the firmware off the manufacturer's shipped CD, would you be happy for the driver to then be in main? > Think of it this way. For the card with the built-in firmware, the > driver does not depend on any additional packages or software > distribution to work. By contrast, for the card with the separate > firmware, the driver *does* depend on that additional package to work. The dependency still exists - it just isn't expressed within the terms of our package management system. I am entirely happy to describe this distinction as arbitrary. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> wrote: This would make more sense if I sent it to the right list, really. Sorry about that. > Brian Nelson <[EMAIL PROTECTED]> wrote: > >> You are the only person I've seen express views similar to mine on >> debian-legal. All other participants argue for non-free-firmware-using >> drivers going in contrib. > > (cough) > > I'm still entirely unclear on the logic of moving drivers that require > firmware to be loaded from disk to contrib. If they didn't require that > non-free code to be on disk, it'd be in a ROM on the device instead. All > drivers require non-free firmware - whether we have to ship it or not > should not affect the freedom (or otherwise) of a driver. > > Let's pretend that Debian actually has a significant amount of leverage > on this sort of issue, and that vendors see their drivers appearing in > contrib and want to do something about it. They /could/ open the > firmware and provide a toolchain for it. We'd put the driver in main, > then. Alternatively, they could put the firmware in ROM. In this case, > the amount of non-free code on a user's system would not change, but > we'd move the driver to main anyway. > > Note that this doesn't mean I think firmware should be in main. But I > think that's an entirely separate argument. Picking on drivers that > force us to notice their dependencies on non-free code while ignoring > drivers that are just as dependent (but in a less obvious way) is > hypocrisy. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > With drivers that load external firmware files this split is possible > leaving the driver in main inside the kernel and the non DFSG free > firmware in non-free. This argument suggests that we can shift drivers from contrib to main simply by turning them into kernel patches and getting them included in the stock kernel. This seems, uh, odd. > No. I have no binary blob (from Debian) at all on any of my debian > systems spaning several archs. There is a huge difference between the > hardware having firmware and the driver including or loading > one. Don't confuse that. But... > For Debian it is all about distribution. The rest does not matter at > all. Debian is not distributing the firmware that is in hardwares > eproms. Everything the user has is a big black box that somehow > works. What's inside it does not matter, only what Debian distributes. No. Debian is not about distribution. It is about free software. We don't make the distinction between main and contrib because of distribution requirements - we make it because we think that free code that requires non-free code is "tainted" by this. We put it in contrib so that people know that by using this software, they will also have to use non-free code. This is less obvious for drivers that use firmware in flash, but it's still true. For what it's worth, we don't distribute the ipw2100 firmware. The user has to obtain that themself. For various other bits of hardware, the firmware is already on a CD that the user owns. > We don't care what blobs do as long as they are not linked into GPL > software (like the kernel). Only then they have to follow the GPL. > Standalone blobs just have to follow DFSG if they want to be in main > and some of the BSD licensed blobs can be once they stop linking into > the kernel. Blame it on the viral nature of the GPL. Yes. That's an entirely separate issue. The definition of a DFSG blob is difficult, though. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: >> The dependency still exists - it just isn't expressed within the terms >> of our package management system. I am entirely happy to describe this >> distinction as arbitrary. > > And yet, in this case the non-freeness of the software isn't hurting > the user. The point isn't whether the firmware "exists", the point is > whether the user is being prevented from modifying it by licensing or > non-source-distribution restrictions. Oh, but it does. Having the source code to the firmware of my DVD drive would allow me to remove some silly restrictions. I've even got software that would allow me to reflash it. Now, you could make the argument that if I bought the DVD drive then I've never agreed not to reverse engineer the code in question. On the other hand, the documentation attempts to claim that I have no right to do so, and if I installed the Windows drivers they'd make me agree to do the same thing. If you've got any European case law that shows that I have significantly more rights because the software is in flash instead of on disk, I'd be fascinated to hear it. I've no especially good reason to believe that to be true at present. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Michael Poole <[EMAIL PROTECTED]> wrote: > Thomas Bushnell BSG writes: >> And yet, in this case the non-freeness of the software isn't hurting >> the user. The point isn't whether the firmware "exists", the point is >> whether the user is being prevented from modifying it by licensing or >> non-source-distribution restrictions. > > When the firmware is burned into the device, the user is prevented > from modifying it in a rather more drastic and permanent fashion than > when the restrictions are a matter of missing code or permissions. Indeed. If I want to flash various bits of hardware I have, I need to reverse engineer the flash method first. This isn't necessary if I have a driver that uploads an image on every boot. If the firmware isn't in flash, I'm completely screwed. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > No, because we have chosen a limited set of goals. We are for free > software, not Curing All The World's Ills. There is nothing > hypocritical about Debian deciding to attack one problem (non-free > software) without attacking a different problem (unchangeable > burned-in software). Burned-in software is, in general, non-free software. It would be as easy for us to write a free alternative as it would be to write a free version of firmware loaded from disk. Why do you believe this goal to be less important? -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > >> This argument suggests that we can shift drivers from contrib to main >> simply by turning them into kernel patches and getting them included in >> the stock kernel. This seems, uh, odd. > > That's our policy. Every policy will have curious corner cases. >::shrug:: It also means that I can upload a kernel image that contains all these drivers, ensure that it's ABI compatible with the "official" kernels, and then build udebs containing the firmware-requiring drivers. These could then be grabbed by d-i. The drivers would then be available during install. So, for the cost of a relatively small amount of time, I could happily ensure that all these drivers end up in main. This suggests that there's something slightly wrong. The dependency on non-free code wouldn't have changed in the slightest. > But if you want a new policy, it should be discussed on debian-project > or perhaps debian-policy. I'm entirely happy to bring this up on debian-project. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le samedi 11 d=E9cembre 2004 =E0 21:47 +, Matthew Garrett a =E9crit : >> We put it in contrib >> so that people know that by using this software, they will also have to >> use non-free code. This is less obvious for drivers that use firmware in >> flash, but it's still true. > > Where do you put xine, then? It works fine with only free code, but can > open more formats when dlopen()ing optional non-free libraries. Should > it go outside of main because it is "tainted"? I don't believe so; the > user himself chooses to taint his system by installing these libraries. > The problem is exactly the same for non-free blobs: the user will know > he is installing some non-free stuff, either by downloading it from our > non-free archive, either by installing it by himself. xine should certainly remain within main - it's useful without any non-free software. But then compare to, say, kernel-patch-2.6-bluez - all the devices that this code will work with have non-free firmware, though only one of them requires it to be loaded from userspace. Main or contrib? -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Bruce Perens <[EMAIL PROTECTED]> wrote: > If the manufacturer wants their device to be supported, they can put a > fifty-cent FLASH chip on their hardware and program it before the sale. > Debian should be pro-active in publishing a list of devices that require > BLOBs in their drivers, so that users are warned away from them. How does moving firmware from the disk to the hardware (therefore making it harder to modify and more expensive) further the cause of free software? -- Matthew Garrett | [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
Bruce Perens <[EMAIL PROTECTED]> wrote: > Is a driver that loads a BLOB Free Software? The problem is connected > with distribution. The BLOB is unquestionably software. It runs below > the bus, which is our /usual /demarcation between Free Software and the > rest of the system, but it starts life above the bus at boot time, and > *we have to distribute it. In many cases, we do not have to distribute it. We could - alternatively, we could use the copy that the user has on a CD already[1]. Bruce, why do you keep sending HTML? [1] This isn't true for a small set of drivers - the ipw2100 requires different firmware for Linux and Windows. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Obfuscated source
John Hasler <[EMAIL PROTECTED]> wrote: > Andi writes: >> "preferred form for modification" is _only_ a GPL-term and not part of >> the SC. > > The SC is not a legal document. Common sense should suffice to conclude > that obfuscated source does not comply with the DFSG. While I tend to agree, this has the unfortunate side-effect of removing any form of support for Nvidia graphics cards. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Blars Blarson <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> > [EMAIL PROTECTED] writes: >>How does moving firmware from the disk to the hardware (therefore making >>it harder to modify and more expensive) further the cause of free >>software? > > It makes it covered by the hardware manufacturers warentee. If it is > faulty, you can return it for repair or refund. Under UK law, I have the same rights with faulty software. Do other jurisdictions actually treat software and hardware differently in this respect? -- Matthew Garrett | [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
Bruce Perens <[EMAIL PROTECTED]> wrote: > Certainly there are AVR and ARM chips that do glue-less downloading from > serial FLASH chips at boot time. Atmel sells them, among others. > Reprogramming of the FLASH is done via JPEG and not under the embedded > processor's control. Bruce, as far as I can tell, you're claiming that it's better for vendors to put code in flash because that way Debian doesn't have to worry about the non-freeness of it. While I can see ways in which that is true, I don't believe it /should/ be true. Non-free code in flash is no more or less a problem than non-free code on disk. We shouldn't be encouraging manufacturers to make their products more expensive by putting it in flash - we should be encouraging manufacturers to open the specifications so we can implement free versions, or encouraging them to open the firmware in its entirity. One of these choices does nothing to advance freedom. The other does. If anything, we should be happy that manufacturers /are/ starting to move away from flash - it makes it clearer that there's a freedom issue that we're not at liberty to ignore. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Why firmware generally won't be Free Software
Bruce Perens <[EMAIL PROTECTED]> wrote: > Matthew Garrett wrote: >>Non-free code in flash is no more or less a problem than non-free code on >>disk. >> >> > Except that we have to distribute it. If the manufacturer is so > concerned about their code that they can't disclose its source, they > should hide the code on the device, below the bus interface where we > don't care about it. But why do we not care about it? It's non-free. There are benefits to being able to change it. "Oh, good, we don't have to distribute it so it's not a problem" doesn't deal with the freeness argument - the code is still sitting there festering away. I can pretend it isn't. I can pretend that aliens live inside my DVD drive and make it work, or that it's actually made out of clockwork, but we know that that's a lie. Hiding non-free software doesn't make it any better. > It is to the Free Software community's advantage to ask only for > bus-level programming information rather than to ask for firmware to be > opened. We have enough trouble convincing manufacturers to make it > possible to drive their devices with Free Software. By establishing a > bus-level demarcation between the realm of Free Software and the > manufacturer's copyrighted property, we can give them the confidence > that revealing driver details will not allow other manufacturers to > clone their devices. No, you're missing the point. I understand that there are practical arguments against this desire for freedom, but that doesn't alter the philosophical basis - as far as freedom is concerned, there is no difference in having non-free code in ROM or on disk. None at all. The set of rights I have is not interestingly different. Saying "If it's the other side of the bus, we don't have to care" is a fudge - you're choosing to ignore the non-freeness because it's ended up on the other side of some arbitrary line. The "If it doesn't get executed on the host processor, we don't have to care" argument is just as valid, and just as arbitrary. I understand that vendors have commercial concerns. I'm not saying that we should start making demands. I'm saying that in the long run, we can work towards encouraging vendors to make this information available. I expect this to take a long time. > In addition, embedded programming is not like the kind you're used to. > In general an error in a Free Software program can cause loss of data, > and the damage ends there. This is only exceeded in some device drivers, > but embedded programming generally is not so protected - certain kinds > of errors are much more likely to cause permanent physical damage to the > device. I'm familiar with the consequences of modifying firmware, Bruce - I had to do so to get my laptop to boot if my wireless card is inserted. If I'd had the source code, this would have been significantly easier. I did this with the full knowledge that the hardware could be damaged if I fucked up. My hardware, my choice. Don't attempt to use the "Oh, you can't be trusted with that knowledge" argument, because it sucks. I entirely and absolutely reject the idea that non-free software is less of a problem if we don't have to distribute it ourselves. A world in which this code is free is a better world, and our willingness to work with vendors to free it should not be altered by the vendor's choice of media. Whether we treat firmware as a problem or not should be a choice entirely independent of implementation technicalities. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#285518: misdn-utils includes a firmware loader
Frank Küster <[EMAIL PROTECTED]> wrote: > P.S. Shouldn't this be moved to -legal? No. -legal is useful for determining whether a given piece of code meets the DFSG or not. It doesn't make policy decisions. -project is a better place for non-technical discussion of this sort of thing. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#285518: misdn-utils includes a firmware loader
Manoj Srivastava <[EMAIL PROTECTED]> wrote: > Well, if you need the non-free component to be on the file > system, why is this different from contrib? Why can't say of > everything in contrib that well, if the non-free jvm were to > magically appear on the file system this java code would work? Or any > other non-free stuff that needs to be on the fs? The requirement for the non-free component exists, even if it isn't on the filesystem. What philosophical benefit is there to distinguishing between non-free code in a chip on a device and non-free code that exists on the filesystem but is executed on that device? How is the cause of free software advanced? How is the experience of our users improved? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard <[EMAIL PROTECTED]> wrote: > No, there's a very concrete reason: given an installation of Debian > main, the driver works. Drivers that require non-free firmware don't > work out of the box; The vast, vast majority of drivers require non-free firmware. > Your sarcasm and condescension make me wonder why you're here at all, > though; you appear to regard Debian's founding principles with contempt. Jonathan believes (as I do) that you're choosing the wrong place to draw an arbitrary line. He has chosen to express this opinion via humour. Given all that he's done for Debian at various points, suggesting that he shouldn't be here is really going too far. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote: >> Glenn Maynard <[EMAIL PROTECTED]> wrote: >> >> > No, there's a very concrete reason: given an installation of Debian >> > main, the driver works. Drivers that require non-free firmware don't >> > work out of the box; >> >> The vast, vast majority of drivers require non-free firmware. > > Hmm. A few places to draw the "dependency from driver to firmware" > line seem to be: No, that's not what you said. There's some room to quibble over whether a dependency exists - there's no room to quibble over whether a requirement exists. Almost all modern hardware either contains firmware or requires firmware to be uploaded. Therefore, almost all drivers require firmware, since otherwise the hardware they drive would not exist. Please, let's be honest about what requirements software has. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > Please at least read Policy on what "Depends" means first. If you > also read the archives, you'll have a chance at understanding the > position of other debaters here, and of generating original > arguments. So far, this is all a repeat. It wasn't convincing any of > the last couple times, so it won't be this time. Note that the social contract says "requires", not "depends". I'm inclined to believe that policy is in the wrong here. (This does not mean that I believe the social contract's wording to be sane in this respect) -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: >> So if EEPROMs contain software, why "don't [you] get to distribute any >> drivers"? I don't understand. > > You can get software out of an firmware-EEPROM on a hardware device. > I don't think it's appropriate to call that software as is, or in > general. This line *could* be drawn in lots of places, but if you say > that the contents of an EEPROM are software, then how about a one-shot > PROM? How about a book with a print-out of the source code? A PROM generally contains software (unless you're going to argue that executable code is not always software, in which case I'm going to ignore you). A book is a representation of software but not software itself, since the book exists outside the digital domain. > The only reasonable place to draw the line, for Debian, is this: can > Debian physically ship it in a useful way? For files on disk, the > answer is yes. We are constrained only by the license. For the book > or the PROM, the answer is no. For an EEPROM, in general, the answer > is no. For any such correctly operating device, the firmware is > already there. Debian can't usefully ship it. It would be > interesting to try supporting an architecture to run on those devices > instead of Wind River or whatever, but there isn't one now. Ignoring license constraints, I can find you any number of cases of eeproms where Debian could ship the contents. I can probably find you several that would run on hardware you currently own. Again, drawing the distinction at this point results in the solution that provides more practical freedom to the user being penalised. This implies very strongly that we're doing something wrong. > When the firmware has to be uploaded, it's a dependency. If it were > just a magic initialization sequence, that would be OK -- such a > sequence is presumably too short to copyright. But this is long and > non-free, clearly software, and clearly a dependency. The dependency is not on the specific firmware in question - the dependency is on code that will cause the general purpose device to behave in the way that the driver expects. In the vast majority of cases, the only code that currently satisfies that constraint is non-free, but there's no intrinsic reason why it has to be so. We can compare this to other hardware. The orinoco wireless driver depends on the hardware acting in a specific way, and does this by communicating with the firmware in the device. In doing so, it is communicating (and hence depending) upon non-free executable code - ie, software. But, again, there's no intrinsic reason why it has to be so. You could write free firmware, or you could reimplement the device in such a way that it doesn't actually have any firmware (for sufficiently simple cases, you might be able to reimplement it in a fairly large quantity of clockwork), and hence remove the dependency. But these are hypotheticals. Drivers that require loaded firmware tend to use non-free code, and drivers that require hardware to respond in certain ways tend to use non-free firmware on that hardware. In both cases, we could reimplement something in order to remove that non-free dependency (either free firmware or hardware that doesn't use firmware), but *nobody has done so*. A hypothetical implementation of something without non-free code doesn't satisfy us. You have argued that drivers don't really depend on firmware, but instead depend on the hardware expressing the correct interface. As an example, we can compare maria-vis, which depends on the graphviz package. maria-vis is in contrib, because it depends on graphviz, which is in non-free. But by your argument, it doesn't actually depend on graphviz - it merely depends on something that presents a correctly functioning graphviz interface. This could be a piece of non-free code, but it could also be a piece of free code, an interface to a remote application server, or a userspace application to drive hardware that kicks intelligent rodents until they draw the correct graph. There's no intrinsic dependency on the non-free code. But since the non-free code is currently the only solution that /does/ express the correct interface, there exists a dependency on non-free code. If you can find me a piece of hardware that can be driven by the kernel's orinoco driver and which contains no non-free executable code, I will agree that the driver does not require the use of non-free executable code. But not until then. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > If you want answers, mail me your questions privately. BTW: the questions I > asked within the thread are still unanswered as well. :) If you can't play politely, other people will not be inclined to play with you. Your continued abuse of volunteers, accusations of conspiracies and generally nasty attitude is a good combination of tactics to ensure that your questions are never answered, no matter how good they are. If you have any desire to help Debian, then lose the attitude. If you don't, then please stop wasting our time. -- Matthew Garrett | [EMAIL PROTECTED]
Re: New stable version after Sarge
Andrew Pollock <[EMAIL PROTECTED]> wrote: > That said, this (rather large) blocker shouldn't be the issue it has been > for this release for the next one. The two biggest blockers to releasing any > time soon have been the installer and the security infrastructure. I'm > actually not abreast of what the issue is with the security infrastructure, > so I don't know if it's likely to be a blocker all over again come etch > release time. I'd like to think it's going to easier to release etch sooner. It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? How can we fix this? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: >> Does the new address bring with it a more constructive attitude towards >> volunteers who have contributed countless hours over the years to keeping >> this project running, or should I plan to killfile this one as well? > > So you decided to play a "my volunteer work is worth more than your > volunteer work" game? When you do feel annoyed by me, why do you still reply > to my mails? Trolling attitude of yours... I believe Steve's volunteer work to be worth more than your volunteer work. Now, you're welcome to point out that I'm guilty of hypocrisy here, since I complained about your abuse of volunteers. But you've done so while continuing to expect them to provide you with useful services, whereas I expect nothing useful from you whatsoever. There is a line at which someone who is volunteering their time and effor is doing so in such a way that they take up more of other people's time than they save. You've crossed that line, and you show no signs whatsoever of wanting to get back on the correct side of it. As a project, Debian owes you nothing. If you're not going to make a sufficiently useful contribution to outweigh your character flaws, then it's better for you to make no contribution whatsoever. Unless you're a FPAV fan, please don't Cc: me. -- Matthew Garrett | [EMAIL PROTECTED]
Re: New stable version after Sarge
Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> wrote: > I agree with you on this. People using stable can not cope with > upgrades each 6 months or so. The issue isn't the frequency of new stable releases - the issue is how long a given stable release will be supported for. Releasing every 6 months wouldn't be a problem if we could support the previous two releases as well. That's probably excessive, but the optimal release length depends on how much support we can provide. -- Matthew Garrett | [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
Glenn Maynard <[EMAIL PROTECTED]> wrote: > It doesn't matter if a piece of software works with non-free stuff, or even > if most of its use, by design, is for non-free stuff. All that matters is > that there exists some free stuff that it works with. For example, the > vast majority of the stuff that runs in Wine is non-free--but not all, so > Wine goes in main. The relative quantities aren't relevant. Even then, the freeness of material outside Debian is generally ignored. We have multiple clients that only work with non-free servers. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
Oliver Kurth <[EMAIL PROTECTED]> wrote: > Naming wired network eth%d and wireless wlan%d would make things a lot > easier. For example, it is easier to find out whether to start ifplugd > or waproamd when the interface is created. There's other (more resiliant) ways of doing that. In 2.6, wireless cards will have a directory called wireless under sys/class/net/foo. > I dislike naming wireless interfaces eth%d, because I often plug in a > wired network card into my notebook at work, and a wireless card at > home. They would both get eth1, but I may want different > configurations.=20 But really, that's a problem that should be solved in a more generic fashion. If I plug in two different wired cards, I'm probably doing so because they've been left in two different places, and so want two different configurations. But they'll both end up as eth2 anyway. It makes more sense to either bind configuration to specific cards (using the mac address, for instance), or different classes of card. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
Oliver Kurth <[EMAIL PROTECTED]> wrote: > On Mon, 2005-02-07 at 18:45 +, Matthew Garrett wrote: >> Oliver Kurth <[EMAIL PROTECTED]> wrote: >> > Naming wired network eth%d and wireless wlan%d would make things a lot >> > easier. For example, it is easier to find out whether to start ifplugd >> > or waproamd when the interface is created. >> There's other (more resiliant) ways of doing that. In 2.6, wireless >> cards will have a directory called wireless under sys/class/net/foo. > > I still use 2.4 as long as sound support for my cs46xx card is broken in > 2.6. Also, I will still use 2.4 on embedded devices (yes, they use > pcmcia cards). In 2.4, wireless devices are listed under /proc/net/wireless. >> It makes more sense to either bind configuration to specific cards >> (using the mac address, for instance), or different classes of card. > > I know that there are other ways. But it makes things more complicated. > Complicated things break more easily. Why not leave it simple, and just > use an easy name scheme? Because in order to solve the problem properly, you need to deal with all the use cases. "I want different configuration on wireless cards and wired cards" is a subset of the "I want different configuration depending on which network card I'm using" problem, and it's possibly easier to solve. But it's better to solve the general problem, rather than attempt to impose policy on the kernel in order to make it slightly easier to solve the simple case. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: self-depending packages
Adam Heath <[EMAIL PROTECTED]> wrote: > Er, hardly. libdpkg will contain *extremely* low-level stuff. > Reading/writing debs(ar/tar/gzip/bzip/checksum stuff). It won't contain > higher-level anything. The active development seems to disagree with you... -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: usbmount: udev script to automatically (un)mount USB mass storage devices: include in Debian?
Pierre Habouzit <[EMAIL PROTECTED]> wrote: > mount -o sync ... is then a solution, especially if you only put small=20 > things, and that the performance loss is not too painfull. Currently sync isn't supported on FAT (there are patches to provide it). If you're using ext2/3, that isn't a problem. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Andreas Schuldei <[EMAIL PROTECTED]> wrote: > To my best knowledge Branden did not know about the proposal at > the time of the LWN interview. So from him it was no demagogy but > his own honest, private oppinion. I and AJ knew about it since we > were involved in the meeting. We both sidestepped the question > since the proposal was still not ready at that time. Uhm. You knew that conclusions from that meeting would be likely to contradict the answers from other DPL candidates, but you did nothing to make them aware of this before they had those answers published to a large audience? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Questions for the DPL candidates (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Steve Langasek <[EMAIL PROTECTED]> wrote: > Andreas Schuldei (DPL candidate) > Angus Lees (DPL candidate) > Branden Robinson (DPL candidate) > Jonathan Walther (DPL candidate) Little advance public warning was given about this meeting, and the scope of the discussions that would take place was not made clear beforehand. As a result, the rest of the project had little input into the decision-making process. Do the other candidates believe that this was the best that could be done in the circumstances, and if not how would they avoid similiar situations (and the ensuing fallout) arising in future? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Rob Taylor <[EMAIL PROTECTED]> wrote: > I feel the need point out that the current DPL and one DPL candidate, > Matthew Garrett, havn't expressed support for this proposal in its > current form. I should say that I don't necessarily disagree with the current proposals, just the process by which they were obtained and presented. I honestly don't know whether they're the best solution or not yet. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Andreas Schuldei <[EMAIL PROTECTED]> wrote: > On Mon, Mar 14, 2005 at 11:58:06AM +, Matthew Garrett wrote: >> Uhm. You knew that conclusions from that meeting would be likely to >> contradict the answers from other DPL candidates, but you did nothing to >> make them aware of this before they had those answers published to a >> large audience? > > I knew nothing about the candiates' answers, no. > > I did not use the knowledge to my own advantage, either. How is using that knowledge to sidestep the question not using it to your own advantage? We have a situation where several DPL candidates have voiced support for the release team, only to have an announcement three days later that flatly contradicts them. Would it not have been better for Debian if you'd told the other candidates what decision had been reached? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Supporting tier-2 (was Re: COUNT(buildd) IN (2,3))
David Schmitt <[EMAIL PROTECTED]> wrote: > On Monday 14 March 2005 17:39, Frank Küster wrote: >> No testing, no release, no security support. For me, that is so close >> to "not support at all" that I hardly see the difference. > > No testing and release support by the current RMs and no security support by > the current security team. Any interested developer should be able to pick up > where the current powers that be have given up. Reasonable security support requires some degree of cooperation with the current security team. Without that, vulnerabilities notifications won't be available. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Supporting tier-2 (was Re: COUNT(buildd) IN (2,3))
David Nusinow <[EMAIL PROTECTED]> wrote: > On Mon, Mar 14, 2005 at 05:57:05PM +, Matthew Garrett wrote: >> Reasonable security support requires some degree of cooperation with the >> current security team. Without that, vulnerabilities notifications won't >> be available. > > Why can't porters join the security team? Then everyone benefits. There's a fairly high bar of entry to the security team, for fairly justifiable reasons. People get very unhappy if advisories are leaked early, so it's necessary to have complete trust in the people involved. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Julien BLACHE <[EMAIL PROTECTED]> wrote: > You'll figure out that the timing for this new policy is absolutely > perfect; we're a week away from the voting period for the new DPL > term. The current DPL can't (and won't, obviously) do anything about > it, and the candidates signed the proposal. I haven't signed the proposal. I'm undecided on the technical side of things (I'd rather see a list of the problems that are being solved, and a description of how these proposals fix those problems), and I think the way the meeting and conclusions were announced was fairly disasterous. > I should add that the > Vancouver meeting was announced at the very last minute, too. And I'm > wondering, who paid for the travel expenses ? Did the people involved > pay out of their own pocket ? Did the Project pay ? Did somebody else > pay the bill ? As mentioned in http://lists.debian.org/debian-project/2005/03/msg00015.html , the funding came from NUUGF. As far as I know, the project spent no money on this. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Matthias Urlichs <[EMAIL PROTECTED]> wrote: > Hi, Goswin von Brederlow wrote: > >> If scc is split into a seperate archive >> (seperate hostname and all) and is strictly voluntary it in no way affects >> the size or mirrors of the main archs. > > As I understand it, SCC *binaries* get their own domain / mirrors / > everything, but the *source* shall be shared with the main archive. Uh. Not if you want to distribute any GPLed material. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 2005-03-14 at 21:49 +0100, Moritz Muehlenhoff wrote: > Matthew Garrett wrote: > >> As I understand it, SCC *binaries* get their own domain / mirrors / > >> everything, but the *source* shall be shared with the main archive. > > > > Uh. Not if you want to distribute any GPLed material. > > The FSF doesn't consider this a problem: > http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites It's not clear that an FTP site really satisfies that, and it's also the case that this is the FSF's interpretation rather than being the one that all GPL copyright holders hold. I'd worry that we might fall foul of some (seemingly valid) GPL interpretations. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Steve Langasek <[EMAIL PROTECTED]> wrote: > Correct me if I'm wrong, but I think the timeline went something like: > > - Sunday evening, meeting adjourns > - Monday noon-ish, first real draft of the meeting report posted > - Tuesday morning, everyone who needs to review it gets on a plane > - Tuesday evening, DPL candidates have their deadline for responding to > LWN interview questions That appears about right. > I hope you'll be somewhat forgiving of the people involved for the > unfortunate case of timing at work here. Oh, I'm not claiming that there was any sort of conspiracy to make people look stupid. However, given that two of the people responding knew that the situation had changed, it ought to have been possible to let the others know that answering this question was a bad idea. As you say, though, the timing was unfortunate. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > >> It's not clear that an FTP site really satisfies that, and it's also the >> case that this is the FSF's interpretation rather than being the one >> that all GPL copyright holders hold. I'd worry that we might fall foul >> of some (seemingly valid) GPL interpretations. > > If the relevant tools were to automatically fetch from the right > place, and we have administrative control over both, then we certainly > do come under that statement. Remember that the relevant tools include arbitrary ftp clients. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions for the DPL candidates
Anthony Towns wrote: > Really, I think this is a necessary consequence of having small meetings > of the relevant people; the alternatives are to invite everyone -- which > is more or less the same as just having the discussion on the lists, > which has its own problems that I hope have adequately been covered > elsewhere; or to have meetings that don't generate any conclusions -- > which strike me as a waste of time. I think this is interesting from a social point of view. Would increasing the number of teams inside the project increase the number of incidents like this? If so, would people become more or less tolerant of them? > OTOH, doing RM work is pretty difficult at the best of times, and only > becomes more so when it becomes necessary to start proposing major and > controversial changes like this, and without the forthright support of > the DPL, rapidly approaches impossible. IMO, anyway. Sure. If it's the opinion of the release managers that something of this magnitude is the only way to fix the problems we face in producing new releases, then that's something that ought to be supported. However, in this case we've already seen a great deal of debate over whether various bits of the proposal solve problems in the optimal way. Clearer communication of what the problems being addressed were would have helped here, as would presenting it as something more obviously a proposal. > That said, I don't think any of the implementation has been started yet, > and it certainly won't be completed 'til sarge is released; so there's > plenty of time for further comments or tweaks or even reinventions. Absolutely. I'm heartened to see that amongst the flaming, there /is/ solid technical discussion going on. We do have problems, and this is (so far) the best proposal we've had for dealing with them. I just wish it had been reached somewhat differently. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > Again, without a proper communication there's no chance of cooperation. > Otherwise those kinds of "I've heard that you've done..."-stories would have > happen again and again... Ingo, stop being such a cock. Even if you'd found James assaulting your dog with a cucumber, you'd be overreacting. Your repeated outbursts actively hinder other developers. If you're not going to contribute anything useful, then kindly fuck off and improve the signal to noise ratio. Please note the mail-followup-to in replies. This discussion doesn't belong on this list. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Social pressure on mailing lists (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Norbert Tretkowski <[EMAIL PROTECTED]> wrote: > * Ingo Juergensmann wrote: >> Your wording is not on a level I would expect from a DD. > > And especially not on a level I would expect from someone who runs for > DPL. Ok. It's probably the case that I went too far there, and I do apologise for that. However, I /do/ think we need to be more willing to apply social pressure against people whose sole contribution to mailing lists is to disrupt them. The status-quo is plainly not desperately helpful, and I'm not a fan of using technical or policy measures as anything other than an absolutely final resort. (m-f-t -project - this isn't a technical discussion) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The sarge release disaster - some thoughts
Bas Zoetekouw <[EMAIL PROTECTED]> wrote: > I definately agree with you on this. The way this discussion is going > atm is in the direction of finding solutions while the underlying > problems aren't at all clear[1]. > > [1] At least not to the developers at large. Andreas Barth has posted a good description of the problems that the release team face, and how the proposal would help. I'm hoping that something similary will be forthcoming from the ftp-masters. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Anthony Towns wrote: > So, I looked at the website, but all I can see are expensive PCs that > happen to have an arm chip. Put them behind a firewall on a trusted LAN, > use them to develop software for arm chips, and then just follow > unstable or run non-security-supported snapshots. Apart from writing > software for embedded arm things, I can't see the value -- and if an > arch is just going to be used for development, does it really need all > the support we give stable in order to make it useful for servers and > such? If so, why? If not, what level of support does it need, that goes > beyond "unstable + snapshotting facility", and why? Debian developers > manage to develop on unstable fairly well, eg, why isn't that enough? Is > this just a PR issue, in that "unstable" and "snapshot" aren't something > you can put on a brochure or brag about on slashdot? This is very much a "What should Debian be" question, and I don't think trying to answer it along purely practical lines is reasonable. A moderately large number of our developers have become involved *because* we support these niche architectures - how do we reasonably quantify that and compare it to the effort required to keep them up to date? I do very much sympathise with the idea that expecting the release team to carry the burden of looking after under-maintained architectures is entirely unreasonable, but that doesn't mean that the only two choices are to drop architectures or to give up on releasing. We have more choices than that, we're just not sure how practical they are yet. I'm not going to agree with any "Oh, it's hard to release this many architectures" argument - I /will/ agree with "This architecture is holding us back, so we should drop it". Debian is a community project. Many people are involved because they want to be, not because they need to be. Implying that their work isn't massively useful isn't helpful, and may well have the effect of discouraging people who /aren't/ working on the potentially affected ports. If we're going to fail to release architectures, then let's base this on technical grounds rather than "I don't see any real reason why you need to release this architecture". -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]
Bill Allombert <[EMAIL PROTECTED]> wrote: > Is it possible to get one or two to run as buildd and/or developer > machine ? Being stuck with netwinder when XScale are available is > a bit like trying to build Debian on a 586. There's no shortage of ARM hardware available to Debian, but so far it hasn't been added to the buildd setup. I'm not clear on the reasons for this. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
Steve Langasek <[EMAIL PROTECTED]> wrote: > - While neither of the above concerns is overriding on its own (the > ftpmasters have obviously allowed these ports to persist on > ftp-master.debian.org, and they will be released with sarge), there is a > general feeling that twelve architectures is too many to try to keep in > sync for a release without resulting in severe schedule slippage. > Pre-sarge, I don't think it's possible to quantify "slippage that's > preventible by having more active porter teams" vs. "slippage that's > due to unavoidable overhead"; but if we do need to reduce our count of > release archs, and I believe we do, then all other things being equal, we > should take issues like the above into consideration. This, uh, sounds very much like "We need to drop architectures, and so we have come up with these criteria that will result in us dropping architectures". Which is a reasonable standpoint to take, but which also seems to imply that if 12 architectures manage to fulfil all the criteria, we'll need to come up with some new criteria to ensure that the number drops below 12 again. If this is the case, I think that needs to be made clearer to avoid situations where people work to meet the criteria but are vetoed by the release team because there are already too many architectures. I'm not massively keen on this - it ends up sounding a bit too much like dead man's shoes. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Marc Haber <[EMAIL PROTECTED]> wrote: > What are you trying to do instead? If you might have noticed, we have > _just_ _another_ ftpmaster situation _right_ _now_, and from handling > of #339686 by a member of the DPL team I don't get the impression that > the DPL team actually cares. (#340306) > In fact, how can the message of "we don't care about security if it's > ftpmaster breaking security features" be more official than by the > downgrade of that bug to wishlist by a DPL team member? Rejecting signed packages is not equivalent to "we don't care about security". You appear to be complaining that a bug that was filed on Tuesday hasn't been fixed on Wednesday. Further, this appears to be a bug that affects a tiny number of people. Expecting it to be prioritised over anything else that people may be working on is insane, and bringing it up in such a hostile manner (not to mention attempting to use it to claim that the DPL team don't care about your particular issue) isn't going to result in it being fixed faster. Instead, it's going to result in people assuming that you're some sort of conspiracy-theory loon. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Use 2: I have this Ubuntu CD and want to know which debs are from >debian and which got recompiled > > Look for all debs that have a deb signature of the debian archive > (to be added to dinstall at some point). The answer is "all of them", so this one's not very compelling. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Peter Samuelson <[EMAIL PROTECTED]> wrote: > [Goswin von Brederlow] >> > Use 2: I have this Ubuntu CD and want to know which debs are from >> >debian and which got recompiled >> >=20 >> > Look for all debs that have a deb signature of the debian archive >> > (to be added to dinstall at some point). > > [Matthew Garrett] >> The answer is "all of them", so this one's not very compelling. [Someone with a horrid, horrid quoting style] > What? All Ubuntu .deb files went through ftp-master.debian.org at some > point? I know you can't actually mean that. Hmmm, perhaps you meant > "none of them"? If so, that's an Ubuntu-specific answer, because even > if Ubuntu recompiles all packages, many Debian derivative distributions > do not. I was unclear. All of them are recompiled. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Kevin Locke <[EMAIL PROTECTED]> wrote: > Fundamentally, our goal is to create an architecture-independent, > power-system-independent, and power-daemon-independent system to handle > power-related events (e.g. lid close, battery events). This will likely > happen by hooks from the power daemons (scripts in their event handlers) > that will invoke a common event handler. This common handler will run > its system-independent scripts (possibly in the style of a runlevel) > based on its configuration, then return control to the daemon to > complete its handling. To a large extent, this sort of work is currently being done in HAL. Is there any need to create another level of abstraction, or should we just work on that? It also sounds (though I'm not certain) like you're concentrating on system-wide power management transitions, whereas I'd argue that it needs to be possible for configuration to be done on a per-user basis (you wouldn't believe the degree of argument over whether closing the lid of a laptop should trigger a suspend or not) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > Can I tell HAL to just handle power management instead of touching anything > else, and get it to do the right thing in a headless, GUIless server > environment? Can I do that with standard, system-wide configuration files? HAL on its own will never trigger any actions. It will provide information about events, and it can be asked to perform certain transitions. For power management there's a need for another small daemon that provides local policy, and it's entirely sensible to have one that can be configured for a server-type environment. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Kevin Locke <[EMAIL PROTECTED]> wrote: > Interesting. I wasn't aware to what extent HAL is able to notify > programs about power-related events. In fact, we had briefly discussed > receiving events from HAL in addition to the power-daemons. Perhaps > with some work, we would be able to rely completely on HAL. At the moment, HAL will listen for ACPI events and has partial support for PMU notifications. APM is a bit more awkward, since the standard doesn't really allow for a great deal of policy - the system is told that a suspend is going to happen, has an opportunity to run some code and then the system suspends. This can possibly be hacked around in the kernel to some extent, but, well. However, the basic idea behind using HAL is to get PM event notification in a platform independent way. Whether it's an ACPI or a PMU-based system is fairly uninteresting - userspace just wants to know that the user has pressed the power button, pulled the poewr, closed the lid or whatever. HAL provides that, so lets the policy daemon be entirely ignorant of the underlying hardware. > The common power-management framework is really intended to be a policy > layer, so it may still have some value for running scripts based on > power events (it could fill the roll of the "small daemon" you talk > about in your second mail to this thread). However, I realize that the > GNOME Power Manager[1], and likely a KDE equivalent, already handles > several of the tasks normally associated with power-management, so > perhaps there is no need for another program to be handling events. Gnome power manager is an implementation of a policy daemon, yes. It's well-suited to certain types of desktop environment, but it's not ideally suited to server environments. On a desktop, stuff like screen-blanking and response to lid closing is a per-user preference, whereas on a server you probably don't want users to be able to fiddle with that. > What are your (or anyone else's) thoughts about the value of a daemon to > invoke scripts based on the power-related HAL events? Is this > unnecessary given the function of the GNOME Power Manager and > equivalents, or would it have enough value to be worth implementing? HAL will call scripts to perform certain actions, such as triggering suspends and (where possible) will do things like altering screen brightness on request. The policy daemon is responsible for asking for these things to happen, and is also necessary for notifying other bits of userspace. > Would it be better to spend our time adding features to the Gnome Power > Manager and equivalents instead of creating a separate program? I'm > sure we will be discussing this extensively on the powermgmt-devel list > in the near future, but I would like to hear what the -devel community > thinks of this idea (it's too easy to justify ones own work in ones own > mind). I think a small, light daemon that runs configurable scripts on various HAL events would be an entirely sensible thing to implement. Ideally, it should check whether some user manager has started and (depending on configuration) let that take care of things instead. That way, there's a system-wide config up until the point where someone logs in. So, I think the best plan of action would be: 1) Implement a small PM daemon on top of HAL (basically a replacement for apmd, acpid and pmud) a) Should call HAL for system state transitions b) Should call scripts installed by other packages c) Should be configurable in terms of default response to actions d) Should (optionally) get out of the way if a user runs a power management daemon 2) Define a mechanism for packages to drop scripts into this framework 3) Ensure that packages like gnome-power-manager and whatever KDE come up with are able to call the same scripts when necessary -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > 1. power management is system infrastructure. I can explain WHY it > is so, but I don't think many people would argue that power > management is an user-level service. Whether a laptop suspends when you close the lid is a per-user preference. The length of time before an idle system suspends is a per-user preference. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > Nobody said the user can't give his input on how the service will behave. > That's what the GUI is for, and what configuration files are for. The user needs to be able to configure this without any form of excessive privileges, which means that some amount of policy has to be determined by processes running as the user. It's also important that this sort of thing can only be controlled by an appropriate user - if I'm logged in on a background VT, I shouldn't be able to trigger power management state transitions. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit : >> How many more years are we going to waste time with this hysteria before >> realising it doesn't achieve anything but "rapidly sucking the fun out >> of things"? > > How many developer resignations will you need to understand inaction > from people at key positions sucks the fun out of things in a worse way? Reading these threads makes me want to resign. WILL YOU NOT THINK OF THE CHILDREN? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > I'm not really convinced that such an approach would have a significant > effect as long as you're not measuring existing DD's to the same > standards. Which, as far as I can see, does not happen. A procedure is in place for developers to be ejected from the project. If you feel that anyone is behaving in a way that would not have allowed them to get through NM, then please do invoke it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Steve Langasek <[EMAIL PROTECTED]> wrote: > The principle is the same: /lib is used only for the minimal system required > for booting, and everything else should go in /usr/lib. /run should be used > only for junk that needs to be stored early in the boot sequence, and > everything else should go in /var/run. Under Linux, can't all of this be done with mount --move anyway? I'm not convinced that we actually need a /run any more. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote: >> Under Linux, can't all of this be done with mount --move anyway? I'm not >> convinced that we actually need a /run any more. > > So you would have these files stored in /var/run from the beginning, and use > mount --move to shuffle them around if /var is a separate mount point? I'm > pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid > of 2.4 for etch; and is there an equivalent solution for non-Linux ports? Yeah, it's 2.6 only. Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it? The linux-onlyness of it is a bit more awkward, but non-Linux OSs tend to be lacking things like decent ram filesystems anyway, so the semantics are going to vary in any case. But I guess if it's difficult, sticking with /run might be easier. Has anyone talked to the FHS guys about this? (I haven't actually checked whether it's in there, so the answer may well be "yes" :) ) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Anand Kumria <[EMAIL PROTECTED]> wrote: > On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote: >> 5.5 hours for a package to make it through NEW. I think you owe some >> people an apology. > > -> 8126 T Oct 25 Debian Installe ( 46) xmovie_1.9.13-0_i386.changes is N= > EW >10552 T Dec 14 Joerg Jaspert ( 23) xmovie_1.9.13-0_i386.changes REJ= > ECTED > > How many hours is that, David? David's example is representative. Your one isn't. Of all the people to pick on in Debian, the ftp-masters aren't the obvious target. How about dealing with some more significant problems? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
Michael Poole <[EMAIL PROTECTED]> wrote: > Wesley J. Landaker writes: > >> Readers should also note that the FSF believes[1] that the QPL is a free >> license; but it's not GPL compatible. > > This does not mean a lot. They believe the same thing of the GNU FDL, > but the FDL is non-DFSG-free in the general case. I don't think the FSF have ever claimed that the GFDL would class as a free software license. Their standards for free documentation licenses are clearly different to the DFSG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
Francesco Poli <[EMAIL PROTECTED]> wrote: > That is completely irrelevant. The FSF doesn't use the DFSG as freeness > guidelines. But the DFSG are intended to be a more detailed description of what free software (a term initially defined by the FSF) is. If the DFSG are wildly divergent from the FSF's viewpoint, we need to figure out how and why. Having two different definitions of free software does nothing to help the community. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
Matthew Garrett <[EMAIL PROTECTED]> wrote: > Francesco Poli <[EMAIL PROTECTED]> wrote: > >> That is completely irrelevant. The FSF doesn't use the DFSG as freeness >> guidelines. > > But the DFSG are intended to be a more detailed description of what free > software (a term initially defined by the FSF) is. If the DFSG are > wildly divergent from the FSF's viewpoint, we need to figure out how and > why. Having two different definitions of free software does nothing to > help the community. Argh, sorry. This should have been on -legal -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Lars Wirzenius <[EMAIL PROTECTED]> wrote: > * Less strong ownership of packages. (snip) > This idea hasn't been tested. It could be tested if > some group of maintainers declared that some or all > of their packages were part of the experiment, that > anyone could NMU them for any reason whatsoever, as > long as they take proper care not to mess the package > up. It's not something that's been tested in Debian, but it's the standard way of getting things done in Ubuntu. So far, it seems to have worked fairly well. The two situations aren't directly analagous since Ubuntu has a smaller and more cohesive group of people involved, but I think it's possibly indicative that this proposal would work. I think I've said this before, but I have no objections to anyone uploading any of my packages. I'd be even happier if anyone who did so was willing to enter into some sort of reciprocal agreement. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
Adam Heath <[EMAIL PROTECTED]> wrote: > That's the wrong answer. > > What ever happened to standard unix tools? chmod/mkdir/chown/mv? > > You're suggesting doing things like some other OS(like Windows, were you have > to edit a registry). Indeed. Editing plain text configuration files has never been the Unix way, and vi certainly isn't a standard unix tool. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Michelle Konzack <[EMAIL PROTECTED]> wrote: > If you need to pay 450.000 DHs (42.000 ¤) for an E3 of 34 MBit > which give you maximum 20-24 MBit because the Infrastructure is > to bad in Morocco then it IS expensive. No. Based on what you've said, the price is the same regardless of whether you download 1GB or 20GB in a month. Therefore, as long as the increase in traffic doesn't saturate your line, the cost per GB is 0. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Frans Jessop <[EMAIL PROTECTED]> wrote: > Ubuntu's launchpad is amazing. Do you think it would be helpful if all DD's > worked through it on their projects? Wouldn't that keep things more > organized and efficient? Or perhaps Debian could build its own version of > launchpad which is better. Again, I think it would do a good job keeping > everything organized an efficient. Launchpad is currently non-free, so it doesn't seem terribly likely. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Federico Di Gregorio <[EMAIL PROTECTED]> wrote: > What really I don't understand is how a proprietary tool can promote > more efficient collaboration on the development of _free software_. > Sounds like an ossimoron to me. I think it's hard to argue against the fact that Sourceforge has encouraged a great deal of collaboration on free software, despite now not being entirely open. (It's probably also hard to argue against the fact that Sourceforge has discouraged a great deal of collaboration, what with their inability to do things like run a stable CVS service. Thanks, Sourceforge) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote: > i've thought for a long time about how to reply to your message. Let's quickly outline what's happened here: 1) Luke files a bug agains Debian. So far, so good. 2) Some time later, Luke contacts a KDE developer and asks if the bug has been fixed. 3) The response is, approximately, "This is the first I've heard of it". We (Debian) have a bug tracking system in order to keep track of bugs in our distribution. It's the job of either the bug submitter or (more usually) the Debian maintainer to contact upstream to make sure that they're aware of the bug. It is *not* the upstream maintainer's job to examine Debian's bug database. Which is, uh, pretty much what Dirk said. Luke, what the christ are you upset about? Nobody's said "Don't report this bug to us", they've said "If you report a bug to Debian and nobody forwards it, we know nothing about it". -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
David Nusinow <[EMAIL PROTECTED]> wrote: > Please stop trying to twist my words around. Canonical didn't contribute > back. An individual who happened to work for Canonical did. If someone > employed by the US government contributes to Debian of his own volition do > we say that the US government gives back to Debian? Do we say that your > employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > No other Debian derivative, as far as I'm aware, says that it > cooperates fully with Debian. Other than, say, the DCC Alliance? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
John Hasler <[EMAIL PROTECTED]> wrote: > mdz writes: >> Have you ever received such a notification? > > Yes. I haven't. I'm going to cry now :-((( -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: >> Other than, say, the DCC Alliance? > > I wasn't aware of them until just now. :) Wow! > Interestingly, the DCC Alliance says that it wants to become part of > Debian. > > Do you have information on their plans with respect to the issues > discussed in this thread? The DCCA distribution is a mixture of packages from Sarge plus some backports. In all cases, the Maintainer: field appears to be the same as in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are supposed to be using these packages in an unmodified form, as I understand it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Wed, 18 Jan 2006, Matthew Garrett wrote: >> Patch clauses only prohibit code reuse if your build system is >> insufficiently complicated. > > And you are willing to contain an entire copy of the codebase from > which you are extracting. [Unless the patch clause is per-file...] Oh, sure. But bandwidth and disk space are relatively cheap commodities compared to what they used to be. If the Linux source tree contained an entire copy of the BSD kernel source, I doubt anyone would really bat an eyelid. It's certainly an inconvenience, but I don't think it really prevents anything of any great interest. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 07:23:41PM -0800, Thomas Bushnell BSG wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > The DCCA distribution is a mixture of packages from Sarge plus some > > backports. In all cases, the Maintainer: field appears to be the same as > > in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, > > Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are > > supposed to be using these packages in an unmodified form, as I > > understand it. > > Have they modified these packages? Some of them, yes. Mostly the backports. > What do they do about version numbering of recompilations? (Do they > recompile?) They have to recompile the backports, at least. I haven't checked the MD5s of the binaries, but that's easy enough to do. > Do they modify the packages at all? As stated, in some cases yes. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 07:32:20PM -0800, Thomas Bushnell BSG wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > >> Have they modified these packages? > > > > Some of them, yes. Mostly the backports. > > What happens to the maintainer field in these cases? I haven't seen any that have been changed. > Certainly, if they are modifying the packages, I would think the same > there here applies as in the case of Ubuntu: they should reset the > Maintainer field to point to themselves, and continue to give credit > to the Debian developer in a suitable fashion. The founder of Debian seems to disagree, but still. The DCCA situation suggests that we need to define exactly what we want and make it clear to all derived distributions that this is what we expect. This isn't something that only affects Ubuntu - we're talking about a large number of fairly major distributions. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Wed, Jan 18, 2006 at 03:21:14AM +, Matthew Garrett wrote: >> I'm not going to defend patch clauses. I think they're massively >> horrible things, and the world would be a better place without them. But >> deciding that they're not free any more would involve altering our >> standards of freedom, and I don't see any way that we can reasonably do >> that. > > It's disappointing, then, that Debian is so fixed in stone that it's > incapable of correcting its mistakes. Declaring patch clauses non-free isn't correcting a mistake. It's stating that the entire community's definition of freedom is wrong. Patch clauses have been acceptable for longer than Debian has existed. The degree of freedom they provide has, if anything, increased with improvements in technology. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
I do apologise. These should plainly have been on -legal. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, Jan 18, 2006 at 08:43:48PM -0500, Ian Murdock wrote: > Fact is, the potential for confusion here never even occurred to > me when we started doing this at Progeny. Quite the contrary to what > Matthew suggests, it seems to me that changing the Maintainer > field is a perfectly reasonable thing to do now that I'm aware of it. Ah, my apologies. I'd assumed it was something that you'd probably have thought about, so I'll happily withdraw that. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works [was: Anton's amendment]
Anton Zinoviev <[EMAIL PROTECTED]> wrote: > Obviously any patch that is automatically generated in this way is a > work based on A. The license of A permits to use "patch files" for > the purpose of modifying the sources of A at build time. However the > license of A doesn't explicitly permit us to use "patch files" or any > other work based on A for the purpose of modifying the sources of > another program, in our case B. If the license forbids the use of modified code in other works, then it's plainly not a free license. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
Pierre Habouzit <[EMAIL PROTECTED]> wrote: > I know Sven may sometimes be a bit overpresent in some trolls, he also=20 > may answer too quick, without having read the mail he answers to=20 > correctly enough. But AFAICT, I've always seen him apologies when he=20 > did so (I can provide links if you can't believe me). Sven has insulted me and accused me of engaging in a conspiracy against him and his employers in order to cover up my own incompetence on more than one occasion without any hint of an apology. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
Mike Bird <[EMAIL PROTECTED]> wrote: > Your accusation fails to allege sufficient facts to constitute > an allegation of defamation. The facts have previously been discussed elsewhere. I replied merely to point out that Sven does not always apologise for his behaviour. > Rather than wasting list bandwidth, please consult a solicitor. I have absolutely no interest in starting legal action against Sven. And rather than wasting /my/ bandwidth, would you please not Cc me on replies? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
On Wed, Mar 15, 2006 at 05:56:05PM +0100, Sven Luther wrote: > I was a bit short on you, because you started to make noise about the reason > for the refusal being a #include being wrongly placed in the patch, and a > printk that was not strictly necessary, which i think for someone like you or > the ubuntu kernel team is a joke reason not to even do a single reply on the > bug report. I hadn't replied to the bug report because I wasn't involved in the Ubuntu kernel at the point when it was filed, so I didn't reply there. When you brought my attention to it, I pointed out two issues that you could fix in seconds. I had none of the hardware in question, and didn't want to spend time trying to work out if there was some subtle reason for the code being there. There was certainly no effort to sabotage your platform, and I haven't heard any sort of apology for your accusations. > I also remember that you where much less than curteous and extremely > patronizing when i proposed myself to handle the ubuntu powerpc kernels, a > year or so ago, when i still believed that cooperation was possible, and i > never heard you apologize for that, so should we expulse you for both being > offensive to me (and having gone over to the ennemy :) ? I have absolutely no recollection of this happening, and can't find any references to you talking to me about it in my logs. You appeared to spend some time arguing with Thibaut Varene - are you sure you're not confused? Friendly, -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: acpi vs apm
Cameron Patrick <[EMAIL PROTECTED]> wrote: > What kind of userland support do you see as being missing? I use the > hibernate package for ACPI sleep and it works pretty well. Most of > the problems that I've seen with ACPI have been kernel or BIOS issues > (e.g. the screen not being switched on when resuming unless you give > particular kernel options). The ACPI spec makes it the OS's responsibility to reinitialise the video hardware, not the BIOS's. The kernel is (for the most part) incapable of doing so - there are some cases where you can get it to bring it back, but there's a huge range of hardware where those options crash the machine on resume. The main things that need doing are: 1) Dealing with network interfaces and the like sensibly - at the moment, this will often require unloading and reloading modules pre/post suspend 2) Working with video state. The vbetool package makes it possible to save and restore the graphics card state from userland, which tends to work much better than the kernel fudges. In the long run, either X or the framebuffer drivers need to get much better at programming the video. 3) Decent integration into user configuration. In a lot of cases, you want PM policy to be definable by the person carrying the computer around, even if they don't have administrative access. I've got some amount of code for doing most of these things, but it's very heavily a post-Sarge thing - it involves touching a lot of packages. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
martin f krafft <[EMAIL PROTECTED]> wrote: > Okay, well, tough luck for him. That said, he can take over the > package when he's a DD. I need it now, but I don't insist on > maintaining it. I'm curious - what functionality do you need that isn't present in the stock kernel? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
Anthony Towns wrote: > If they can all satisfy the criteria, they're likely to be doing well > enough that there's not much *point* to dropping them -- the reason 11 > architectures are hard to manage is because they're not all being > supported at an adequate level. The criteria listed try to give a good > idea of what "an adequate level" is likely to look like. That doesn't seem to match up very well with: "there is a general feeling that twelve architectures is too many to try to keep in sync for a release without resulting in severe schedule slippage." I agree with the idea that architectures that have a history of falling behind and having severe toolchain breakage shouldn't be allowed to hold up the other architectures from releasing, but if it's the feeling of the release team that releasing that many architectures is basically impossible then we may have problems. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > I tend to agree that the veto rights in the proposal are undemocratic. > It is probably better to allow the DPL to veto the inclusion, and > document that he is required to ask the porters, the ftp masters and > the release team before making up his mind. This way the decition is > taken by an elected person, based on the available input from the > relevant teams. Constitutionally, I think it makes more sense to devolve it to the technical committee. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
Sven Luther <[EMAIL PROTECTED]> wrote: > No, that is not acceptable, and probably not the right reason for this. Until > evidence proves otherwise, it is just because they don't care to read those > emails, and that that email address is simply forwarded to /dev/null. This assertion isn't justifiable. I appreciate that you're upset about the amount of feedback you're getting from ftp-masters, but that doesn't mean you should take the opportunity to abuse them further. Doing so helps nobody, and certainly doesn't encourage them to send you more email. Problems with communication come from both sides. If you're rude to people, they become less likely to do useful stuff for you. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
