Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

> Can Grub be set up in a way that it falls back on booting a 32-bit > kernel if the 64-bit one doesn't boot? I suppose you haven't seen my previous mail. Note that this problem (autodetecting 64-bit) is already solved in etch. -- Robert Millan My spam trap is [EMAIL PROTECTED

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

On Mon, Apr 09, 2007 at 07:16:12PM +0200, Robert Millan wrote: > - flash (I expect swfdec will be ready to replace non-free 32bit-only > implementation) Btw, I wonder how would Adobe feel about a feature in swfdec akin to iceweasel's "block banners from this site"

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

dares to invest in developing that now; it would be suicidal. If a game really needs bigmem, PAE is much more feasible (it is a trap, but that's not a problem for the game vendor ;-)). -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters.

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

On Mon, Apr 09, 2007 at 04:00:45PM -0400, Matthias Julius wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > > I suppose you haven't seen my previous mail. Note that this problem > > (autodetecting 64-bit) is already solved in etch. > > True. I've

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

When DOS was set in stone, not even Microsoft was able to replace it with Windows untill they started offering the huge advantage of native 32-bit addressing and protected mode. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

On Mon, Apr 09, 2007 at 03:48:06PM -0400, Matthias Julius wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > > You mean win64-only games? Nobody dares to invest in developing that now; > > it would be suicidal. > > I don't know about the practices of game

Bug#418448: general: PDF files not shown correctly due to missing 'Courier'

idea to file it on the package that exposes the problem. It'll probably have to be reassigned, but the maintainers of xpdf and evince could know better about the problem. (adding them to CC) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harv

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

s) too. The > > real problem is, can they be compatible with x86_64-linux-gnu api ? > > Why would they care to be? That isn't their market. If x86_64-linux-gnu is stablished as the new reference api, well, they'll be forced to. -- Robert Millan My spam trap is [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

hat, or wait untill all these hardware becomes obsolete and is replaced. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

On Mon, Apr 09, 2007 at 04:59:57PM -0400, Matthias Julius wrote: > > But anyway, what do we care? I have my working 64bit platform. It currently works for more people than win64 does, that's for sure. The question is if it'll maintain this edge during the next two years. -- R

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

platform. [1] and yes, "they" doesn't necessarily mean non-free. It can be GPLed vendors too, and it's in fact very likely since these happens to be the same that also target i386-linux-gnu (think of Id software now). -- Robert Millan My spam trap is [EMAIL PROTEC

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

ry qemu. > > Ahh, true. That's another chapter I havn't looked into, yet. sudo apt-get install qemu qemu -cdrom debian.iso That's all :-) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it wil

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

On Tue, Apr 10, 2007 at 04:43:09PM -0400, Matthias Julius wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > > If x86_64-linux-gnu is stablished as the new reference api, well, they'll > > be forced to. > > Reference for what? Is there any software vendor

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

On Wed, Apr 11, 2007 at 06:23:32PM +0100, Luis Matos wrote: > Qua, 2007-04-11 às 17:33 +0200, Robert Millan escreveu: > > > I don't know what the critical mass of Linux users is that generates > > > interest for Linux among software vendors. We seem to be far from >

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

ead has been moved from debian-release already. We're discussing a question that could affecte decisions on the lenny release schedule. Which list is appropiate for that? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

happens for desktop computers. So far > it doesn't provide a real advantage for the average desktop computer. As soon as the average desktop has 8 GiB, some of the vendors will want to ditch the uglyness of win32+pae and go 64-bit. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: t

Re: Use bz2 not gz for orig.tar ?

ferent implementation) It can be used for data.tar as well. The dpkg shipped in etch had support for unpacking it, so technicaly we can do it. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

you're not going to explain (and that's ok with me), please do at least acknowledge that you're just not interested in this discussion at all. > You don't need to keep an off-topic thread alive so that your reasons are > heard. Correct. My reasons have already been he

Re: Use bz2 not gz for orig.tar ?

es now to > uncompress the archives. Compression time would be 10 times more (1000% the > time it takes now). I wonder if that would be suitable for smaller systems. Yeah, but decompression is still faster than bzip2 though. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this

Re: Use bz2 not gz for orig.tar ?

pression scheme that upstream developer or Debian maintainer might > care to use? (perhaps the CPU arguments answer this sufficiently, > though I'm not convinced by them myself). I think binaries are more important, since they're unpacked an order of magnitude more times than source.

Re: Use bz2 not gz for orig.tar ?

On Thu, Apr 12, 2007 at 08:38:34AM +, Lars Wirzenius wrote: > On to, 2007-04-12 at 10:12 +0200, Robert Millan wrote: > > On Thu, Apr 12, 2007 at 12:12:00PM +1000, Drew Parsons wrote: > > > This would reduce our archive size by some 20% if all packages moved to > > &

Re: Use bz2 not gz for orig.tar ?

On Thu, Apr 12, 2007 at 09:07:57PM +0100, Luis Matos wrote: > Qui, 2007-04-12 às 21:03 +0200, Robert Millan escreveu: > > On Fri, Apr 13, 2007 at 03:38:56AM +1000, Drew Parsons wrote: > > > > Why not lzma? It reduces size even more > > > > > > It's t

Re: The number of etch installations is rocketing...

y). I'm not sure how this would fit in your client/server protocol, but I can easily grab the code from win32-loader and integrate it if you tell me. Want a bug report? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it

Re: The number of etch installations is rocketing...

fit in your client/server protocol, but I can > > easily grab the code from win32-loader and integrate it if you tell me. > > You can also see this by looking at /proc/cpuinfo looking for "lm" in > flags. Sounds good. Maybe we could just include the whole cpuinfo ? --

Re: Mandatory -dbg packages for libraries?

On Sun, 2007-04-22 at 16:14 -0500, Steve Greenland wrote: > On 22-Apr-07, 14:39 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote: > > > > I'd like to see all library source packages having a minimum of 4 > > binary packages required by Policy: the SONAME, the -dev, the -dbg and > > a -doc package.

Re: Mandatory -dbg packages for libraries?

On Tue, 2007-04-24 at 14:40 +0200, Loïc Minier wrote: > On Tue, Apr 24, 2007, Josselin Mouette wrote: > > Apport sends complete core dumps, which is a very bad idea. The dumps > > can be huge (for desktop applications they often grow beyond 200MB) and > > they can contain gazillions of sensitive in

Bug#425038: ITP: win32-loader -- Debian-Installer loader for win32

Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: win32-loader * URL : http://goodbye-microsoft.com/ * License : GPL Programming Lang: NSIS, C, Bash. Description : Debian-Installer loader for win32 This package prov

Re: Intention to drop sparc32 support for Lenny

Frans Pop wrote: On Monday 21 May 2007 21:49, Martin Habets wrote: FYI, 2.6.21 is rock solid on my SS20 here. Do you consider it broken just because of some cdrom issues? Or is there more? I don't have more details than this: http://lists.debian.org/debian-kernel/2007/05/msg00305.html

Bug#320283: ITO: re2c

Debian. I intend to adopt re2c and upload the latest upstream version (0.12.1). [0] http://lwn.net/Articles/232696/ -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature

Re: Bug#320283: ITA: re2c

W, are you planning to fix the sa-update cron spam issue (#425962) soon? :) -- Robert Edmonds [EMAIL PROTECTED] signature.asc Description: Digital signature

Re: python, then C++, or C++ from the start?

On Wed, 2007-05-30 at 17:34 +0200, martin f krafft wrote: > Dear colleagues, ... > But I am asking you still: can you think of anything to say against > such an approach? Please don't flame languages or anything of that > sort. The question is just: is it viable for a C++ coder with > a Python pro

Re: discussion with the FSF: GPLv3, GFDL, Nexenta

lowed to make this copyleft by forbidding that", I'm stronly > considering making new software GPLv2 only in the future, too. I doubt they did this intentionally. Can you ellaborate on it? Which phrase in particular? Did you send your concerns as comments to the latest draft?

Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

On Thu, 2007-06-28 at 14:54 +1000, Andrew Donnellan wrote: > On 6/28/07, Michael Biebl <[EMAIL PROTECTED]> wrote: > > FWIW recent GNOME desktops in unstable using gnome-mount for doing the > > mounting > > stuff, already have this kind of functionality. Whenever you unmount a > > removable > > de

RFC: declaritive diversions

Ian and I have chatted a few times about diversions in packages. It seems like it would be easier to look for packages that should divert (and don't), or do (and perhaps shouldn't :)) if the diversions were declared in the package rather than being done by turing complete code :). This is a long-p

Bug#431809: ITP: podofo -- library and tools to work with the PDF file format

Package: wnpp Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]> Severity: wishlist * Package name: podofo Version : 0.5.0 Upstream Author : Dominik Seichter * URL : http://podofo.sourceforge.net/ * License : GPLv2 or later, LGPLv2 or later Pro

Re: RFC: declaritive diversions

On Tue, 2007-07-17 at 11:55 +0200, Goswin von Brederlow wrote: > Did you see my earlier mail about the very same thing? No I didn't, sorry. I'm glad the concept seems to have positive reactions regardless. -Rob -- GPG key available at: . signature.asc D

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

On Mon, 2007-07-16 at 00:28 +0200, Stefano Zacchiroli wrote: > I don't want to see a bzr-foo package in the archive for each .py module > available on the internet which provides yet another sub-command for > bzr. I asked under the (wrong) assumption that bzrtools was a Debian > package shipping

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

On Tue, 2007-07-17 at 19:56 +0200, Adeodato Simó wrote: > * Manoj Srivastava [Tue, 17 Jul 2007 09:11:45 -0500]: > > > > * Create a 'bazaar' package which is a metapackage depending on bzr, > > > recommending key plugins, and suggesting others. > > > This would be a bug. While I understa

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

On Tue, 2007-07-17 at 09:11 -0500, Manoj Srivastava wrote: > On Tue, 17 Jul 2007 20:19:59 +1000, Robert Collins > <[EMAIL PROTECTED]> said: > > > * rename the 'bazaar' package to 'baz' - both source and binary, > >though binary is t

Bug#492935: ITP: seabios -- Legacy BIOS implementation

Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: seabios Version : 0.2.3 Upstream Author : Kevin O'Connor <[EMAIL PROTECTED]> * URL : http://linuxtogo.org/~kevin/legacybios/ * License : GPL Programmi

Re: Bits from the Debian Eee PC team, summer 2008

non-free is not part of Debian. Check the Social Contract. Friendly, -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not ac

confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)

[ adding debian-project ] On Sun, Aug 03, 2008 at 01:53:54PM +0200, Robert Millan wrote: > On Sun, Aug 03, 2008 at 08:28:19AM -0300, Ben Armstrong wrote: > > > > Earliest Eee models fully supported in Lenny > > > >Lenny will release with the atl2 ether

Re: lzma: New upstream version available (#460501)

Hi, Please could you aim at 4.58beta instead? It's the first version that can be used by grub-pc for compression of boot blocks. See: http://lists.gnu.org/archive/html/grub-devel/2008-07/msg00036.html thanks -- Robert Millan The DRM opt-in fallacy: "Your data belongs to u

Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)

> : Components: main contrib non-free > : Description: Debian x.y Testing distribution - Not Released > > So lenny is made from main (Debian), contrib and non-free. Therefore Lenny is not Debian, but a superset of it? This is troubling. Do you have any suggestions on how to address th

Re: confusion about non-free (Re: Bits from the Debian Eee PC team, summer 2008)

On Mon, Aug 04, 2008 at 08:46:36PM +0200, Julien Cristau wrote: > On Mon, Aug 4, 2008 at 20:36:17 +0200, Robert Millan wrote: > > > This is troubling. Do you have any suggestions on how to address this? > > Stop trolling about utterly uninteresting details? I think it'

Re: Bits from the Debian Eee PC team, summer 2008

On Sun, Aug 03, 2008 at 10:11:32AM -0300, Ben Armstrong wrote: > As Robert Millan brought to my attention, in my enthusiasm to present > our progress towards fully Lenny support for the Eee in the best > possible light, my announcement muddied the distinction between Lenny > and non

Re: Deprecating (and deactivation) of an archive feature?!

elf (main) and the other archives we provide /support as a supplement to Debian. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your dat

EULA as well: xsane

good? regards robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature

Re: EULA as well: xsane

away in 0.995-3? yes, i didn't get that it was removed in testing (thanks!) still: can we make this a policy item? cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature

Re: EULA as well: xsane

because of the mozilla change, and making such a policy decision at a time when it does not mean reverting some big package back to an older version. think of it as a regression... cu robert -- Robert Lemmen http://www.semistable.com -- To UNSUBSCRIBE, email to [E

Re: EULA as well: xsane

d support making such a decision. > > I would support it too, provided that it's tied to a policy decision not > to accept works licensed under the AGPL into main. please forgive my ignorance, but i don't understand what the AGPL has to do with click-through license agreements.

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

bs from Microsoft. Unfortunately they aren't very explicit about what the problem is, but it is certain there is one, so please find that out, and have it discussed in debian-legal. Thanks -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

terop/msnovellcollab/moonlight.mspx -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSC

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

On Mon, Oct 06, 2008 at 03:24:26PM +0200, Robert Millan wrote: > > Description : open source implementation of Microsoft Silverlight > > > > [...] > > Hi, > > The description is misleading. This is (AFAICT) not an implementation of a > standard but a c

Re: Bug#500176: This bug is still around and release-critical

not make > both conflict, both should work fine. yes, virtual packages are a nonstarter because of all the strange ways dns can be combined on the same machine (see, e.g., the dnsproxy package). -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

On Mon, Oct 06, 2008 at 03:33:48PM +0200, Robert Millan wrote: > [2] http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx Btw, an independent analisys of that covenant is available: http://www.groklaw.net/article.php?story=20080528133529454 -- Robert Millan The DRM opt

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

ve this kind of problem. > ** Note, apologies to debian-devel@ for the offtopic nature of these > messages, my reply is aimed at debian-devel only for mailing list > archive purposes ** It is standard practice to CC debian-devel in new ITPs. Though, as I said for legal discussions

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

On Tue, Oct 07, 2008 at 11:05:58AM +0200, Holger Levsen wrote: > Hi, > > On Tuesday 07 October 2008 09:03, Robert Millan wrote: > > Unclaimed patents are precisely the reason we don't have any MPEG encoders > > in Debian (see http://techliberation.com/2006/05/11/mpeg-pa

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

ry least, we could distribute them in a specific "patented" > section, with rules similar to non-free, and that we’d only mirror in > countries where it is not a problem. While we are at it, would be nice to have a section for DMCA-impaired software such as libdvdcss. -- Robert Milla

Re: Bug#501190: Reworded control

hat might be necessary to implement 1.0, beyond what is currently published on the web; [...]" http://tirania.org/blog/archive/2007/Sep-05.html -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody

Re: Bug#501190: Reworded control

Btw, please keep in mind that the description issues I pointed out are relatively unimportant compared to legal risk (and I haven't seen that being discussed in debian-legal yet). On Thu, Oct 09, 2008 at 03:32:48PM +0200, Robert Millan wrote: > On Wed, Oct 08, 2008 at 12:38:41AM +

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

On Tue, Oct 07, 2008 at 04:44:40PM +0200, Reinhard Tartler wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > >> At the very least, we could distribute them in a specific "patented" > >> section, with rules similar to non-free, and that we’d only mi

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

and our users don't really miss anything if we don't ship it. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

their tax and politely let you know that you have to pay as well. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not acc

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

istributors. > > Such convenience services already exist (debian-multimedia.org, > debian-unofficial.org), Debian doesn't need to start one. But they don't get the associated benefits of being officially part of Debian, like BTS and such. (which contrib and non-free do *g*) --

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

to be patent-encumbered, we're sending a message claiming that it is not. I don't appreciate the Moonlight folks trying to use Debian for this purpose. Whatever the choice is, let us at least be consistent... -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will

Bug#502183: ITP: ExactImage -- A fast, modern and generic image processing library

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: ExactImage Version: 0.6.3 Upstream Author: René Rebe <[EMAIL PROTECTED]> URL: http://www.exactcode.de/site/open_source/exactimage/ License: GPL-2 Description: ExactImage is

ITP: a52 -- Motorola DSP56001 assembler (Re: Bug#494010: Source for dsp56k firmware)

compiling the firmware used in Linux' dsp56k.c driver. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

ecided to look the other way: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823 Btw, I'm looking for supporters for a GR to stop this gross violation of the SC. Any DDs who read this, please let me know if you're interested. -- Robert Millan The DRM opt-in fallacy: "

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

nding a name, I think "Blobbie" is a pretty one. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote: > Le lundi 20 octobre 2008 à 16:08 +0200, Robert Millan a écrit : > > > Has the current release team lowered the bar on Debian actually > > > trying to follow the social contract? > > >

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

.html btw, would be really nice if it can be fast-tracked. [3] that means either sanctioned by the maintainers or by the DPL -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote: > > You cannot ask, so late in the release process, Some of these bugs have been known for *years*. In one of them, I even got a reply saying something along the lines of "I was expecting this one". -- Robert M

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

On Mon, Oct 20, 2008 at 10:48:57AM -0700, Thomas Bushnell BSG wrote: > On Mon, 2008-10-20 at 16:08 +0200, Robert Millan wrote: > > On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote: > > > > > > Has the current release team lowered the bar on Debia

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

On Mon, Oct 20, 2008 at 08:46:18PM +0200, Marc 'HE' Brockschmidt wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > It seems we relied primarily on the release team, which has betrayed > > the goals of the project, > > I do not accept to be calle

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

On Mon, Oct 20, 2008 at 12:23:20PM -0700, Thomas Bushnell BSG wrote: > On Mon, 2008-10-20 at 20:18 +0200, Robert Millan wrote: > > Apparently, our control structures are not reliable enough to _enforce_ > > what we have decided. It seems we relied primarily on the release team

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

I can't believe those come from the same people who keep this as one of their official songs: http://www.openbsd.org/lyrics.html#39 Our contradictions might not be so unique to Debian after all ... -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

ting anything simpler. > > Ever hear of the Technical Committee? The Technical Committee is not empowered to override foundation documents. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threa

Re: [DRAFT] resolving DFSG violations

ublic, please stop this and come back to more constructive > discussions). And I take it that Thomas is supposed to take your attitude as an example on how being constructive? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may acce

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

On Thu, Oct 23, 2008 at 05:41:05PM +0100, Neil McGovern wrote: > On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote: > > On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote: > > > On Tuesday 21 October 2008, you wrote: > > > > But, in fact, fixes

Re: Bug#503395: ITP: libapache2-mod-spamhaus -- Apache module that use DNSBL to deny access to a known bad IP address

ombined SBL/XBL zone is sbl-xbl.spamhaus.org. -- Robert Edmonds [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#503395: ITP: libapache2-mod-spamhaus -- Apache module that use DNSBL to deny access to a known bad IP address

haus; it appears to be a DNSBL access control filter for apache that can only query one DNSBL zone. i also notice that mod_spamhaus's DNSBL lookup routine only checks for the presence or absence of a host record, rather than checking like a sensible DNSBL client that the response lies in t

Re: [DRAFT] resolving DFSG violations

On Wed, 2008-10-29 at 22:33 +0100, Michelle Konzack wrote: > > Anw what do you do with sourcode, for which there is not even a > compiler > availlable under Linux/BSD? And you HAV to buy a 8000 US$ > development > suit from the chip manufacturer to build the firmware? Free software is an iterat

Re: Free OS versus free hw

On Wed, 2008-10-29 at 15:15 +0100, Loïc Minier wrote: > On Wed, Oct 29, 2008, Ben Finney wrote: > > Since the Social Contract promises Debian *won't* ship non-free > > things, that's not an option compatible with the promises made by the > > Debian project. > > I might not have said it clearly en

DFSG violations: non-free but no contrib

now, end non-free code is marked as such... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature

Re: DFSG violations: non-free but no contrib

route (put firmware in non-free, and make sure you can still use your system) what is most in line with how we deal with these things in debian? cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature

Re: DFSG violations: non-free but no contrib

. cu robert [0] http://womble.decadent.org.uk/blog/for-those-who-care-about-firmware -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature

Re: DFSG violations: non-free but no contrib

t work (in some cases) without package B should declare some kind of relationship on it. simply because there *is* a relation between them... doesn't that sound reasonable to you? cu robert -- Robert Lemmen http://www.semistable.com signature.asc Descripti

Re: DFSG violations: non-free but no contrib

ok, i think i have just woken up and must have mixed up a few unrelated things in my previous mail(s). please disregard everything i said... thanks robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature

Re: DFSG violations: non-free but no contrib

On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote: > Everyone agrees that firmwares are a bit special > in the world of software due to the fact they don't run on the host > CPU. I don't think they are at all special. What interprets the software - be it a 'cpu', a 'vm' or a co-processor lik

Re: DFSG violations: non-free but no contrib

On Mon, 2008-11-03 at 21:20 +0100, Loïc Minier wrote: ... > for which providing a source is not critical. ... I wish I understood the reasoning here - putting aside the fact that most of the software in Debian is under a copyleft licence and so we *must* provide the source. Why is the source for

Re: DFSG violations: non-free but no contrib

On Tue, 2008-11-04 at 15:11 +0100, Loïc Minier wrote: > On Tue, Nov 04, 2008, Robert Collins wrote: > > I wish I understood the reasoning here - putting aside the fact that > > most of the software in Debian is under a copyleft licence and so we > > *must* provide the source.

Re: Leverage in licensing discussions

On Fri, 2008-11-07 at 20:01 +, David Given wrote: > > 1. Some devices require firmware blobs with no source available. > Because > of this, such firmware can't be distributed in Debian. ack. > 2. For at least some of these devices, even if the source code was > available it would add no valu

Bug#505224: RFP: freecad -- An extensible CAx program (alpha)

Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: freecad Version : 0.7.1672 * URL : http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page * License : LGPLv2.1+ Programming Lang: C++, Python Descr

The firmware GR

02665 http://bugs.debian.org/502666 http://bugs.debian.org/502667 http://bugs.debian.org/502669 I hope this helps everyone pick the options they feel most comfortable with. Sincerely, -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) y

Re: I hereby resign as secretary

in separate ballots. This doesn't change anything I said in this mail, nor make me feel that his decisions as secretary are somehow illegitimate. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but no

Re: problems with the concept of unstable -> testing

bugs silently make it to testing. for the record: i have a script running that monitors that, and bugs are found 50/50 in unstable and testing. no real trend over the last 1.5 years. considering how many people use testing, and how few use unstable, i think unstable is quite effective! cu

Re: Bug#509225: ITP: tevent -- talloc-based event loop library

On Fri, 2008-12-19 at 23:49 +0100, Jelmer Vernooij wrote: > An alternative would be to implement tevent as a wrapper around libev or > libevents that added talloc support to the API but that's hardly worth > the trouble as that would add another dependency and the library is > pretty small itself

Bug#510035: ITP: libmaa -- The Maa programming library

Package: wnpp Severity: wishlist Owner: Robert Luberda Hi, I'm intending to pacakge libmaa library, which used to be part of dictd sources, but now is an independent librabry, needed to build the newest version of dictd. * Package name: libmaa (binary pkgs: libmaa1, libmaa-dev) Ve

Re: Bug#509225: ITP: tevent -- talloc-based event loop library

On Sat, 2008-12-20 at 01:57 +0100, Jelmer Vernooij wrote: > Am Samstag, den 20.12.2008, 11:10 +1100 schrieb Robert Collins: > > libevent + libtevent-which-wraps-libevent is better than > > libtevent-which-duplicates-much-of-libevent. :) > In theory, I agree. However, in this

<    1   2   3   4   5   6   7   8   9   >