Package: wnpp
Severity: wishlist
* Package name: libvisual
Version : 0.2.0
Upstream Author : Dennis Smit et al [EMAIL PROTECTED]
* URL : http://libvisual.sourceforge.net/V2/index.php
* License : LGPL
Description : abstraction library for visualization
On Sun, 2004-12-12 at 02:18 +0100, Robert Millan wrote:
On Tue, Dec 07, 2004 at 01:06:11PM +0900, Clemens Schwaighofer wrote:
True, the Koran just invites to kill your ennemy bloodily, that's very
different...
Thats wrong, thats just an interpretion.
I wonder how could text be
Package: wnpp
Severity: wishlist
* Package name: libchewing
Version : 0.2.4
Upstream Author : Jim Huang [EMAIL PROTECTED]
* URL : http://chewing.csie.net/
* License : LGPL
Description : libchewing - The intelligent phonetic input method library
SVN
On Sun, 12 Dec 2004, Ron Johnson wrote:
On Sun, 2004-12-12 at 02:18 +0100, Robert Millan wrote:
On Tue, Dec 07, 2004 at 01:06:11PM +0900, Clemens Schwaighofer wrote:
True, the Koran just invites to kill your ennemy bloodily, that's very
different...
Thats wrong, thats just an
Hallo Joey,
I added the section ReleaseAsSubsystemChoice to your wiki
(http://wiki.debian.net/index.cgi?ReleaseProposals).
I wasn't sure whether it should be included into ReleasePerSubsystem or not. I
made it separate so you can delete it easier if you think it is complete
nonsense.
For
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Tim Cutts [EMAIL PROTECTED] writes:
[...]
It's not the driver software depends on the firmware to function; it's
the hardware that depends on the firmware to function. The software
dependency is a side-effect.
With the driver software loading
On Sat, Dec 11, 2004 at 11:25:49AM -0800, Steve Langasek wrote:
Bug #270388 regards the cedet-common package breaking emacs -batch. A
proposed fix in the bug report is for cedet-common to Pre-Depend on emacs21
| emacsen instead of depending on it.
An NMU based on this proposed fix has
El dom, 12-12-2004 a las 00:22 +0100, Goswin von Brederlow escribi:
[...]
Installing non-free firmware taints your filesystem, using AIM does
not.
Taints your filesytem??? Oh, this is more than I expected.
Are you really aware that your computer is plenty of non-freeness? That
the device
El dom, 12-12-2004 a las 04:52 +0100, Goswin von Brederlow escribi:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
Yes. Once you eliminate the dependency on the non-free file the driver
becomes suitable for main.
The
On Sat, Dec 11, 2004 at 01:45:01PM -0800, Thomas Bushnell BSG wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 11, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Your case of hardware wich already includes firmware is totaly
irelevant since Debian does not distributes hardware,
On Sun, 2004-12-12 at 22:24 +1300, Philip Charles wrote:
On Sun, 12 Dec 2004, Ron Johnson wrote:
On Sun, 2004-12-12 at 02:18 +0100, Robert Millan wrote:
On Tue, Dec 07, 2004 at 01:06:11PM +0900, Clemens Schwaighofer wrote:
True, the Koran just invites to kill your ennemy
On Sun, Dec 12, 2004 at 04:09:04AM +0100, Goswin von Brederlow wrote:
Is a bit of flash or rom that much bigger than ram? Isn't most of the
space in the dongle air or filling material?
Space is space on the board (not to mention the complexity of the board)
as well as three dimenisonal space.
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
[..]
There are a number of reasons that a device's firmware won't generally
be opened to us:
1. The manufacturer's concerns regarding the proprietary nature of
information about their device that is below the bus.
2. The fact
Ron Johnson wrote:
On Sun, 2004-12-12 at 22:24 +1300, Philip Charles wrote:
On Sun, 12 Dec 2004, Ron Johnson wrote:
On Sun, 2004-12-12 at 02:18 +0100, Robert Millan wrote:
On Tue, Dec 07, 2004 at 01:06:11PM +0900, Clemens Schwaighofer wrote:
True, the Koran just invites to kill your ennemy
On Sat, Dec 11, 2004 at 11:50:44AM -0800, Thomas Bushnell BSG wrote:
Brian Nelson [EMAIL PROTECTED] writes:
It's a completely inconsistent and arbitrary policy.
It's hardly that. We distribute only free software, that's our rule.
I thought the post
On Sat, Dec 11, 2004 at 05:39:37PM +0100, Marcin Orlowski wrote:
Package: wnpp
Severity: wishlist
* Package name: kwirelessmonitor
Version : x.y.z
Upstream Author : Name [EMAIL PROTECTED]
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD,
Neil Roeth [EMAIL PROTECTED] wrote:
One of my packages, xfonts-kapl, installs fonts to
usr/X11R6/lib/X11/fonts, as it should, according to policy 11.8.5. I
get a lintian warning that nothing should install to /usr/X11R6/lib
unless it uses imake, and that is just reflecting policy 11.8.7.
I'm pleased at the discussion this thread has generated. Thanks to
everyone who has participated.
As a next step, I've created a mailing list where we can continue the
discussion ([EMAIL PROTECTED],
http://lists.progeny.com/listinfo/lsb-workers/). I'm out of town
all day today, but I'll go
Package: wnpp
Severity: wishlist
* Package name: gazpacho
Version : 0.3.1
Upstream Author : Lorenzo Gil Sanchez [EMAIL PROTECTED]
* URL : http://gruppy.sicem.biz/componentes#gazpacho
* License : LGPL
Description : GTK+ User Interface Designer
Gazpacho is
Jose Carlos Garcia Sogo [EMAIL PROTECTED] writes:
El dom, 12-12-2004 a las 04:52 +0100, Goswin von Brederlow escribió:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
Yes. Once you eliminate the dependency on the non-free
El dg 12 de 12 del 2004 a les 00:05 +0100, en/na Goswin von Brederlow va
escriure:
The difference between a standalone driver and a driver included in
the kernel is the usability. A standalone driver is not useable
without its firmware and needs a depends, the kernel works very well
without
On 10-Dec-04, 17:02 (CST), Florent Rougon [EMAIL PROTECTED] wrote:
Bernd Eckenfels [EMAIL PROTECTED] wrote:
No, it is because the shortcuts are completely non-intuitive. I use
aptitude for the good intuitive keymapping, not for its menu.
I see. You find them utterly unintuitive, and
Jose Carlos Garcia Sogo [EMAIL PROTECTED] writes:
El dom, 12-12-2004 a las 00:22 +0100, Goswin von Brederlow escribió:
[...]
Installing non-free firmware taints your filesystem, using AIM does
not.
Taints your filesytem??? Oh, this is more than I expected.
Are you really aware that
I am trying to make sense of /var/log/*. I noticed the following
peculiarities:
- user.log is 0640. However, aren't user messages possibly
relevant to users? If so, I suggest making the file 0644.
- uucp.log, mail.* and news/* are 0644. I would say that these
should be 0640.
- why
Miguel Gea Milvaques [EMAIL PROTECTED] writes:
El dg 12 de 12 del 2004 a les 00:05 +0100, en/na Goswin von Brederlow va
escriure:
The difference between a standalone driver and a driver included in
the kernel is the usability. A standalone driver is not useable
without its firmware and needs
martin f krafft [EMAIL PROTECTED] - Sun, Dec 12, 2004:
I am trying to make sense of /var/log/*. I noticed the following
peculiarities:
- user.log is 0640. However, aren't user messages possibly
relevant to users? If so, I suggest making the file 0644.
I think this is user as in
On Sun, Dec 12, 2004 at 04:54:14PM +0100, martin f krafft wrote:
- why is dmesg 0644? This is not really a problem, but do users
need access to the boot messages?
The log buffer can normally be read using the dmesg utility (or similar
code) as well as via the log file.
--
You grabbed my
On Sun, 12 Dec 2004, martin f krafft wrote:
I am trying to make sense of /var/log/*. I noticed the following
peculiarities:
- user.log is 0640. However, aren't user messages possibly
relevant to users? If so, I suggest making the file 0644.
640 is not necessarily broken. There might
also sprach Loïc Minier [EMAIL PROTECTED] [2004.12.12.1706 +0100]:
I think this is user as in userland, simply because this is the
default level for programs.
ah, okay.
also sprach Mark Brown [EMAIL PROTECTED] [2004.12.12.1706 +0100]:
The log buffer can normally be read using the dmesg
also sprach Santiago Vila [EMAIL PROTECTED] [2004.12.12.1708 +0100]:
My mail.* files are 640 and I don't remember having done anything
special for that to happen.
Judging from an IRC conversation, I should note that I just did
a fresh install into VMware from the 2004-11-27 netinst ISO. The log
Neil Roeth [EMAIL PROTECTED] wrote:
One of my packages, xfonts-kapl, installs fonts to usr/X11R6/lib/X11/fonts,
as it should, according to policy 11.8.5. I get a lintian warning that
nothing should install to /usr/X11R6/lib unless it uses imake, and that is
just reflecting policy 11.8.7.
Goswin von Brederlow wrote:
If it comes down to the driver, on its own, would not be acceptable for
main because it is not functional; but as a practical matter, we allow
it aggregated with the rest of the kernel because splitting individual
drivers into contrib is a pain for everyone involved and
Goswin von Brederlow wrote:
Your opinion (and I would generaly agree there) would be that the
pseudo source files released are not source as per GPLs definition
A lot of these BLOBs have been identified as ARM7 code, and generally
thumb (the 8-bit ARM instructions). They come from C or
Goswin von Brederlow wrote:
Imagine a source where all variables are named vnumber and all
functions fnumber. Is that still free? Where do we draw the line?
When does source stop to be bad style and start to become obfuscated
and unacceptable for main?
This has been handled before. Some
Glenn Maynard wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact, depend on such an item is a pretty
basic violation of Debian's principles.
It's not
* Bruce Perens ([EMAIL PROTECTED]) [041212 17:50]:
Goswin von Brederlow wrote:
Imagine a source where all variables are named vnumber and all
functions fnumber. Is that still free? Where do we draw the line?
When does source stop to be bad style and start to become obfuscated
and
Hamish Moffatt wrote:
And 4. They're not allowed to by regulations, eg wireless hardware
whose firmware cannot be distributed by FCC rule.
It's not at all clear to me that the type-approval process depends on
security by obscurity in the firmware. Some manufacturers may think it
does, but I
Steve Greenland writes,
Which, of course, isn't to say that it should be
removed. I was surprised by how many people still use
it; I hope some one will pick [dselect] up.
Dselect is sufficiently important to me that, as time
permits, I mean to pick it up.
Another competent person with more
Andrew Suffield wrote:
http://wiki.debian.net/index.cgi?ReleaseProposals
Every single one of these falls into one of these four groups:
Please note the wiki in the URL and the edit page button on the
page.
(Or are you just pointlessly bitching?)
--
see shy jo
signature.asc
Description:
Steve Langasek wrote:
Well, my first question is why, irrespective of how valuable the LSB itself
is to them, any ISV would choose to get their apps LSB certified. The
benefits of having one's distro LSB certified are clear, but what does an
LSB certification give an ISV that their own
[EMAIL PROTECTED] (Nathanael Nerode) writes:
Goswin von Brederlow wrote:
If it comes down to the driver, on its own, would not be acceptable for
main because it is not functional; but as a practical matter, we allow
it aggregated with the rest of the kernel because splitting individual
drivers
Bruce Perens [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Your opinion (and I would generaly agree there) would be that the
pseudo source files released are not source as per GPLs definition
A lot of these BLOBs have been identified as ARM7 code, and generally
thumb (the 8-bit ARM
On Sun, 12 Dec 2004 18:40:07 +0100, Joey Hess wrote:
Andrew Suffield wrote:
http://wiki.debian.net/index.cgi?ReleaseProposals
Every single one of these falls into one of these four groups:
Please note the wiki in the URL and the edit page button on the
page.
Inspired by A.S.'s comment
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.
--
John Hasler
Op za, 11-12-2004 te 16:37 -0600, schreef Graham Wilson:
On Sat, Dec 11, 2004 at 10:53:10PM +0100, Marcin Orlowski wrote:
Package: wnpp
Severity: wishlist
* Package name: unlzx
Version : x.y.z
Upstream Author : Name [EMAIL PROTECTED]
* URL :
Op za, 11-12-2004 te 16:59 +0100, schreef Goswin von Brederlow:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 10, Matthew Palmer [EMAIL PROTECTED] wrote:
You may want to take a look at debian-legal, because some people there
think that even free drivers for hardware devices which
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is a natural
demarcation between our Free
Op zo, 12-12-2004 te 04:52 +0100, schreef Goswin von Brederlow:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
Yes. Once you eliminate the dependency on the non-free file the driver
becomes suitable for main.
The driver
* Bruce Perens:
That's why I say the BLOB should be in a file rather than the driver.
The problem is that this introduces unnecessary complexity. If the
blob is required for booting, it has to be put into the initial
ramdisk anyway, and a fail to see a significant advantage over the
* Adam Heath
| The above makes it easy to exclude whole heiarachies, ie, /usr/share/doc.
So will the filetype part of how Scott James is doing stuff.
| It can also be used to alter /lib to /lib64 or /lib32, on the fly, during
| install.
You can't do that in a sane way anyhow. (Think libtool
* John Hasler ([EMAIL PROTECTED]) [041212 19:35]:
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.
I didn't argue against
* Brian Nelson
| Anyone, developer or non-developer, can help fix toolchain problems.
| However, the only people who can work on the testing-security
| autobuilders are ... the security team and the ftp-masters? What's
| that, a handful of people? With a bottleneck like that, isn't that a
|
Wouter Verhelst [EMAIL PROTECTED] writes:
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is
Florian Weimer [EMAIL PROTECTED] writes:
* Bruce Perens:
That's why I say the BLOB should be in a file rather than the driver.
The problem is that this introduces unnecessary complexity. If the
blob is required for booting, it has to be put into the initial
ramdisk anyway, and a fail to
Tollef Fog Heen [EMAIL PROTECTED] writes:
* Adam Heath
| The above makes it easy to exclude whole heiarachies, ie, /usr/share/doc.
So will the filetype part of how Scott James is doing stuff.
| It can also be used to alter /lib to /lib64 or /lib32, on the fly, during
| install.
You
Tollef Fog Heen [EMAIL PROTECTED] writes:
* Brian Nelson
| Anyone, developer or non-developer, can help fix toolchain problems.
| However, the only people who can work on the testing-security
| autobuilders are ... the security team and the ftp-masters? What's
| that, a handful of people?
* Goswin von Brederlow:
That's why I say the BLOB should be in a file rather than the driver.
The problem is that this introduces unnecessary complexity. If the
blob is required for booting, it has to be put into the initial
ramdisk anyway, and a fail to see a significant advantage over
On Sun, Dec 12, 2004 at 08:53:32AM -0800, Bruce Perens wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact, depend on such an item is a pretty
basic
Florian Weimer [EMAIL PROTECTED] writes:
* Goswin von Brederlow:
That's why I say the BLOB should be in a file rather than the driver.
The problem is that this introduces unnecessary complexity. If the
blob is required for booting, it has to be put into the initial
ramdisk anyway, and a
On Sun, Dec 12, 2004 at 06:05:58PM +0100, Andreas Barth wrote:
* Bruce Perens ([EMAIL PROTECTED]) [041212 17:50]:
Goswin von Brederlow wrote:
Imagine a source where all variables are named vnumber and all
functions fnumber. Is that still free? Where do we draw the line?
When does
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 20:25]:
Compiled in the blob MUST comply to the GPL. The nature of being a
blob already seems to violate that.
Only if the blob is derived from the GPL-code.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1
On Sun, Dec 12, 2004 at 08:29:16PM +0100, Goswin von Brederlow wrote:
Tollef Fog Heen [EMAIL PROTECTED] writes:
The problem is not the autobuilder infrastructure per se. It is that
testing and unstable are largely in sync (!). This, combinded with the
fact that testing must not have
On Dec 12, Goswin von Brederlow [EMAIL PROTECTED] wrote:
And why it should be different if that firmware is distributed by the
manufacturer on a CD instead of a flash EPROM chip?
Because the user has to actively do something and taint his filesystem
with the non-free files from the CD.
And
On Dec 12, Bruce Perens [EMAIL PROTECTED] wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is a natural
demarcation between our Free Software and the proprietary hardware
design. It loads an arbitrary
On Dec 12, Bruce Perens [EMAIL PROTECTED] wrote:
A lot of these BLOBs have been identified as ARM7 code, and generally
thumb (the 8-bit ARM instructions).
I know of some devices (very cheap stuff, nothing fancy) which even uses
VxWorks. This explains why it is not even possible for some
On Sat, 11 Dec 2004, Christoffer Sawicki wrote:
Perhaps a stupid question because I do not understand all this menu stuff:
Would this (together with Gnome 2.8) fix the user menus in Gnome???
This would be reall great for Sarge release!
No, this is about fixing the available session types in gdm
On Dec 11, Glenn Maynard [EMAIL PROTECTED] wrote:
If the driver has to be able to open the file and read the blob so it
can send it to the device, there's a clear relationship and dependency
between the driver and the blob: if you don't have a copy of the blob,
the driver doesn't work.
* Goswin von Brederlow
| Tollef Fog Heen [EMAIL PROTECTED] writes:
|
| * Brian Nelson
|
| | Anyone, developer or non-developer, can help fix toolchain problems.
| | However, the only people who can work on the testing-security
| | autobuilders are ... the security team and the
* Tollef Fog Heen ([EMAIL PROTECTED]) [041212 21:35]:
* Goswin von Brederlow
| Tollef Fog Heen [EMAIL PROTECTED] writes:
| * Brian Nelson
|
| | Anyone, developer or non-developer, can help fix toolchain problems.
| | However, the only people who can work on the testing-security
| |
Glenn Maynard [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 08:53:32AM -0800, Bruce Perens wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact,
Glenn Maynard [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 06:05:58PM +0100, Andreas Barth wrote:
* Bruce Perens ([EMAIL PROTECTED]) [041212 17:50]:
Goswin von Brederlow wrote:
Imagine a source where all variables are named vnumber and all
functions fnumber. Is that still free?
Andreas Barth [EMAIL PROTECTED] writes:
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 20:25]:
Compiled in the blob MUST comply to the GPL. The nature of being a
blob already seems to violate that.
Only if the blob is derived from the GPL-code.
No, always. Compiled in it is part of the
On Sun, Dec 12, 2004 at 09:27:05PM +0100, Marco d'Itri wrote:
On Dec 11, Glenn Maynard [EMAIL PROTECTED] wrote:
If the driver has to be able to open the file and read the blob so it
can send it to the device, there's a clear relationship and dependency
between the driver and the blob: if
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 21:55]:
Andreas Barth [EMAIL PROTECTED] writes:
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 20:25]:
Compiled in the blob MUST comply to the GPL. The nature of being a
blob already seems to violate that.
Only if the blob is
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 12, Goswin von Brederlow [EMAIL PROTECTED] wrote:
And why it should be different if that firmware is distributed by the
manufacturer on a CD instead of a flash EPROM chip?
Because the user has to actively do something and taint his filesystem
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 11, Glenn Maynard [EMAIL PROTECTED] wrote:
If the driver has to be able to open the file and read the blob so it
can send it to the device, there's a clear relationship and dependency
between the driver and the blob: if you don't have a copy of
Tollef Fog Heen [EMAIL PROTECTED] writes:
* Goswin von Brederlow
| Tollef Fog Heen [EMAIL PROTECTED] writes:
|
| * Brian Nelson
|
| | Anyone, developer or non-developer, can help fix toolchain problems.
| | However, the only people who can work on the testing-security
| |
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 08:29:16PM +0100, Goswin von Brederlow wrote:
Tollef Fog Heen [EMAIL PROTECTED] writes:
The problem is not the autobuilder infrastructure per se. It is that
testing and unstable are largely in sync (!). This, combinded with
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 22:20]:
Tollef Fog Heen [EMAIL PROTECTED] writes:
t-p-u is not uploaded from another host through a mapping. (Remember,
uploads to stable are mapped to stable-security on
security.debian.org, then uploaded to stable from that host. The
On Mon, 2004-12-13 at 00:12 +1100, Hamish Moffatt wrote:
On Sat, Dec 11, 2004 at 05:39:37PM +0100, Marcin Orlowski wrote:
Package: wnpp
Severity: wishlist
* Package name: kwirelessmonitor
Version : x.y.z
Upstream Author : Name [EMAIL PROTECTED]
* URL :
On Fri, Dec 10, 2004 at 07:04:57AM -0800, Steve Langasek wrote:
On Fri, Dec 10, 2004 at 02:45:17PM +0100, Michael Banck wrote:
One could argue about sending the NMU-patch/interdiff to the BTS, but I
personally do not see much point in it, since (hi Omnic!) you can just
get it from the
I demand that Bruce Perens may or may not have written...
Goswin von Brederlow wrote:
Your opinion (and I would generaly agree there) would be that the pseudo
source files released are not source as per GPLs definition
A lot of these BLOBs have been identified as ARM7 code, and generally
Package: wnpp
Severity: wishlist
* Package name: rssreader.app
Version : 0.1.2
Upstream Author : Günther Noack [EMAIL PROTECTED]
* URL : http://www.unix-ag.uni-kl.de/~guenther/rssreader.html
* License : GNU GPL
Description : RSS reader for GNUstep
This
Package: wnpp
Severity: wishlist
* Package name: gtamsanalyzer.app
Version : 0.42
Upstream Author : Matthew Weinstein [EMAIL PROTECTED]
* URL : http://tamsys.sourceforge.net/gtams/
* License : GNU GPL
Description : Qualitative Research Software for the
hello,
the new quik is now in sid, as per discussed earlier i was to email
[EMAIL PROTECTED] to notify them about it. well, it's there
(finally! :).
you have been warned tongue in cheek /
eric
--
I believe that part of what propels science is the thirst for wonder. It's a
very powerful
Please retain the d-devel@ CC. It's horrible for some posts in a thread
to go to one list, some to another, and some to both, since it forces
everyone wanting to follow the conversation to read the entire thread on
two lists.
On Sun, Dec 12, 2004 at 04:44:44PM -0500, Michael Poole wrote:
Does
I challenge you to tell me the dates of the packages using just the
Packages file. The best you can do is
$ grep-available -F version 200 -s Version|wc -l
1207
But that still leaves
$ grep-available -F version 200 -vs Version|wc -l
15127
packages that don't put the date into their version
This one time, at band camp, Dan Jacobson said:
Off line with just the Packages file, you can't tell a dusty 1997
package from an up to the minute state of the art package.
You have the changelogs. Use them.
--
-
| ,''`.
On Sun, Dec 12, 2004 at 06:06:59PM -0500, Stephen Gran wrote:
This one time, at band camp, Dan Jacobson said:
Off line with just the Packages file, you can't tell a dusty 1997
package from an up to the minute state of the art package.
You have the changelogs. Use them.
You must have a
On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
[..]
There are a number of reasons that a device's firmware won't generally
be opened to us:
1. The manufacturer's concerns regarding the proprietary nature of
On Sun, Dec 12, 2004 at 02:30:51PM +0100, Wouter Verhelst wrote:
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to
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
On Sunday 12 Dec 2004 00:43, Bruce Perens wrote:
1. The manufacturer's concerns regarding the proprietary nature of
information about their device that is below the bus.
2. The fact that misprogramming the device at that level can damage the
hardware.
3. They aren't going to want to support
[MFT: set to -legal, since this is kind of OT for -devel]
On Sun, 12 Dec 2004, Andreas Barth wrote:
Why should elf-aggregation always mean to be part of a derived code,
and fs-level aggregation mean that not?
The absence of a trivial method to separate the driver from the other
part and the
Stephen Gran writes:
You have the changelogs. Use them.
The changelogs are in the Packages file?
--
John Hasler
On Sun, 2004-12-12 at 17:37, Matthew Palmer wrote:
On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
[..]
There are a number of reasons that a device's firmware won't generally
be opened to us:
1. The
On Sun, Dec 12, 2004 at 11:43:40PM +, Matthew Garrett wrote:
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
This one time, at band camp, Matthew Palmer said:
On Sun, Dec 12, 2004 at 06:06:59PM -0500, Stephen Gran wrote:
This one time, at band camp, Dan Jacobson said:
Off line with just the Packages file, you can't tell a dusty 1997
package from an up to the minute state of the art package.
1 - 100 of 154 matches
Mail list logo
