Re: [DRAFT] resolving DFSG violations
Am Donnerstag, den 30.10.2008, 01:48 -0500 schrieb William Pitcock: > On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote: > > But regardless, Debian has promised that Debian is only free software. > > Then why does Debian have non-free? Is that not part of Debian? "Thus, although non-free works are not a part of Debian, ..." Social contract, paragraph 5. > If non-free is meant to be an opt-in part of Debian, then put the > distributable firmware there and be done with it. You know, quite a big part of the discussion is about whether this is a) feasible at all b) feasible so short before a release Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Wed,29.Oct.08, 22:11:27, Michelle Konzack wrote: > I am not realy sure, 50.000 customers would accept hardware which cost > 45 US$ instead of 40 US$ because there are 2-3 OSS frickler which want > access to the source because they want to fix something. > > Do you would give the FIXES back to the manufacturer? I thought that was the nice thing about GPL. If you want to distribute your changes the receiver has to get the source too ;) > IF the hardware is working under Linux, BSD, MacOS, Windows and others, > are you realy willing to give the changes back even the other users are > using Windows? > > I know a hardware manufacturer which gaved the sourcecode away under GPL > and it is IN the Debian distribution, but its OSS frickler upstream has > never gaved the changes back to the manufacturer so others can benefit > from it... The manufacturer can get it with a copy of Debian if he wants to ;) > Note: The OSS firmware IS NOT compatibel with Windows and does > not add any additional functionalyty except it is open! And why is this NOT important? Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: can a kernel in main depend on firmware in non-free to work?
Le mercredi 29 octobre 2008 à 22:10 -0200, Alexandre Oliva a écrit : > > Because the kernel is perfectly usable without the firmwares. > > But how about the specific modules that require them, the ones that > got this sub-thread started in the first place? It doesn't make sense > to me to frame the discussion in such terms as most of Linux is useful > without the component's dependencies, when what we're talking about is > the component, not the whole. Whether they are plugins or modules or whatnot is irrelevant here. The only thing that matters is package dependencies. > There *is* reason to split the linux package, I thought that was > beyond any doubt by now. Debian isn't supposed to ship non-Free > Software, and Linux does include non-Free firmwares. And this has already been the case for long. > The doubt is whether the split is going to stop at the firmwares, or > also cover the modules that require the firmwares. No, there is no doubt about that either. There is absolutely no need to split these modules. > > Does the kernel require the firmwares in non-free for execution? > > Portions of it do, for sure. We don’t talk about portions, but about packages. The kernel package does not require binary firmwares for execution. > Could it be that convenience and limited interpretations of practical > consequences of policies are turning against the actual policies and > priorities? It unfortunately looks like it from where I stand, but it > could be that I'm just still missing something. If so, please share > your enlightenment. It seems you are misunderstanding what contrib is for. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: [DRAFT] resolving DFSG violations
On Wed, Oct 29, 2008 at 10:42:56PM +0100, Michelle Konzack wrote: > Am 2008-10-29 00:39:40, schrieb Ben Hutchings: > > How exactly do you propose to load the firmware, if not through a JTAG > > port? Back in the world of production hardware which Debian runs on, > > ASICs tend to have power-on-reset logic built-in... > > Most PCI hardware has a very small bootloader which checks some signals > on the PCI bus... I have a book about it but no time to read in since > it is very complicated... PCI (Express) hardware has to be able to initialise at least the bus interface and PCI config space at power-on reset. That includes board- specific information like subsystem IDs. The network controllers I work with can initialise their config registers either from built-in ROM or from external EEPROM or flash, selected by strap pins. Production boards always initialise from flash; thankfully no-one expects to be able to remove flash from NICs as they need to provide PXE boot code to the host. Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: Digital signature
DFSG violations: non-free but no contrib
hi everyone, the current situation concerning firmware blobs and dfsg-freeness is a bit sad, among other things because there really isn't too much we can do about it in the short run. so how about some practical proposal that we can actually implement in a reasonable timeframe that gets us in a better position to deal with this in the long run? my idea would be: firmware blobs without source get put into non-free, firmware blobs with source but without the necessary free tools to generate the image end up in contrib, firmware which is cryptographically signed and can tehrefore not be modified goes to non-free. we relax the "main" requirements insofar that a package that depends on another package in non-free may stay in main (and doesn't have to go to contrib), if the contents of that other package are not executed or used on the main/host computer'c cpu, but on some additional hardware. (this would of course need to be phrased a bit better, but you get the idea). this way everyone could still use their computer (if using contrib and non-free), and not every other package will end up in contrib. main will contain less non-free code than it does now, end non-free code is marked as such... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: What provides ginstall?
Hi, "ginstall" is the name of the GNU project's variant of "install" on systems that ship with an implementation that does not have GNU extensions. On Debian, the default "install" binary is the GNU one, so there is no need to rename. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, 2008-10-30 at 10:34 +, Robert Lemmen wrote: > hi everyone, > > the current situation concerning firmware blobs and dfsg-freeness is a > bit sad, among other things because there really isn't too much we can > do about it in the short run. so how about some practical proposal that > we can actually implement in a reasonable timeframe that gets us in a > better position to deal with this in the long run? my idea would be: > > firmware blobs without source get put into non-free, firmware blobs with > source but without the necessary free tools to generate the image end up > in contrib, firmware which is cryptographically signed and can tehrefore > not be modified goes to non-free. we relax the "main" requirements > insofar that a package that depends on another package in non-free may > stay in main (and doesn't have to go to contrib), if the contents of > that other package are not executed or used on the main/host computer'c > cpu, but on some additional hardware. (this would of course need to be > phrased a bit better, but you get the idea). Not possible, non-free is not enabled by default. Suggests/Recommends: would be technically feasible though. William signature.asc Description: This is a digitally signed message part
Re: can buildd logs be sorted (again)?
* Thomas Viehmann [Thu, 30 Oct 2008 00:11:09 +0100]: > If someone could attest to > http://buildd.debian.org/~tviehmann/cmp_versions_php.txt > (translated from the perl that udd uses) being wrong in only harmless > ways (except showing that C->Perl->PHP with the last step being done by > someone disliking PHP is not a good idea), I could ask Ryan to put > http://buildd.debian.org/~tviehmann/build.php > in the appropriate location. If acceptable, an easier option could perhaps be to just sort all the package/*/__log files globally by . -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Matthew Kimball - I don't need -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 05:31:44AM -0500, William Pitcock wrote: > Not possible, non-free is not enabled by default. Suggests/Recommends: > would be technically feasible though. true, perhaps we even need a special dependency type. but these are implementation issues. isn't the general 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
Le jeudi 30 octobre 2008 à 10:34 +, Robert Lemmen a écrit : > the current situation concerning firmware blobs and dfsg-freeness is a > bit sad, among other things because there really isn't too much we can > do about it in the short run. Wrong. You can help Ben Finney testing his packages. That would be much more useful than useless babbling on mailing lists. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: DFSG violations: non-free but no contrib
Le jeudi 30 octobre 2008 à 12:07 +0100, Josselin Mouette a écrit : > Wrong. You can help Ben Finney testing his packages. That would be much > more useful than useless babbling on mailing lists. Of course that’s Ben Hutchings. Sorry for mistaking you, Ben. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote: > Wrong. You can help Ben Finney testing his packages. That would be much > more useful than useless babbling on mailing lists. if you are talking about these [0], i certainly do not own any of these pieces of hardware... 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: [DRAFT] resolving DFSG violations
On Wed, Oct 29, 2008 at 10:33:27PM +0100, Michelle Konzack wrote:
> Am 2008-10-28 02:45:31, schrieb Thadeu Lima de Souza Cascardo:
> > If it's not clear by now, people are not arguing that hardware should
> > not be used if it is not free hardware (either it is feasible or not to
> > distribute or exist source code). The matter is whether source for code
> > that will not execute in the main CPU is needed for those codes in the
> > main section. So, your point that it is not x86 code is moot in the case
> > "firmware" is considered to be the same as other software in Debian. If
> > source code isn't available or "possible" for the chip carries the same
> > requirements for DFSG as the case would be for the x86 code, in the case
> > "firmware" should still follow DFSG.
>
> 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?
If the source code is not "human-readable", but it is free/libre, I
would study it in the case I consider the chance there is a bug.
Perhaps, if it was of my interest, I would even study the possibility of
reverse-engineering it, so it could be more "human-readable" and provide
tools to "build" it.
> I have such software and EVEN me can not read the firmware.
>
> I have ONLY a "project" in my IDE and it produce the firmware.
>
> And now you!
I consider that a problem with the tool you use. It has a major defect
("by design"): it is not free/libre. So you cannot modify your IDE to
give you any more "human-readable" format or something else.
> > Even machine readable form would still be considered source if its
> > interpretation by the machine could be presented to someone to make
> > modifications to it. If it is not modifiable for some reason and every
> > design should be done from scratch, perhaps there is a problem with the
> > tools and/or processes used.
>
> Do you have already tried to modify a binary blob or simply opened a (no
> mather which) binary from /bin/ in a HEX editor and tried to modify it?
In my /bin/ directory? If I had to really modify it, why would I use a
hex-editor if I have source code in C?
However, I have programmed a microcontroller using a text editor and
hexadecimal numbers, even had to recode some constants present in code
because I had to add a single instruction in the middle of it. Until I
stopped being too lazy to code a simple assembler.
> > > Even the chip manufacturers don't know what they are. It's totally
> > > machine generated chip garbage as far as they are concerned. Once you
> >
> > Which machines do generate this "garbage"? Do they do it all by
> > themselves? Are there machines designing new hardware now without human
> > intervention? Or are those chips magically enhanced so they could make
> > some sense of any random bitstream and there is no real mistery in
> > generating this "garbage"?
>
> The software/IDE use "projects" which are not in human readable form...
> ...and if you have finisched, you klick the button "Output firmware"
> and then you have the firmware blob.
Again, this is a issue with your IDE. It could certainly be modified to
output some more "human-readable" format that represents its internal
representation of the "project"... if only it were free/libre.
> > If the manufacturers are unaware of it, I doubt the designer is unaware
> > of it.
>
> ???
>
> It seems you have never designed Hardware or realy coded software for it
Does writing a microprocessor in Verilog count as designing hardware?
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
Anyway, this is about the DFSG and the requirement of distributing
source code. I would really like that the requirement for distributing
the needed tools to build and modify this source code was in DFSG too.
Unfortunately, they are not. Fortunately, many packages that
Build-Depends on packages on non-free are in contrib. I hope that will
be the case too for any "firmware".
So, it doesn't matter if the preferred form of modification (by the way,
do you open on your IDE your output "firmware" or your "project"?) is
"human-readable" or not. It is, in anyway, required by DFSG. If it is
the same as the "binary" distributed, the other DSFG requirementes still
apply.
Regards,
Cascardo.
signature.asc
Description: Digital signature
Re: [DRAFT] resolving DFSG violations
On Wed, Oct 29, 2008 at 10:40:03PM +0100, Michelle Konzack wrote: > Am 2008-10-28 09:33:07, schrieb Tristan Seligmann: > > Again, assuming I'm not misspeaking, that form of the work is already > > what we have. > > ACK ;-) > > Thanks, Greetings and nice Day/Evening > Michelle Konzack In which cases? Which of the firmwares? How can you be sure? Regards, Cascardo. signature.asc Description: Digital signature
Re: [DRAFT] resolving DFSG violations
On Wed, Oct 29, 2008 at 10:58:12PM +0100, Michelle Konzack wrote: > Am 2008-10-27 17:01:50, schrieb Felipe Sateler: > > Jeff Carr wrote: > > > > > But the opencore case is the easy case, hybrid chips don't even have > > > source. The firmware blob is often generated when you fabricate the > > > chip & changes with the physical board layout. You guys just don't > > > understand the issues here. > > > > Please explain what the issues are, then. The firmware blob has to be > > generated > > *somehow*. There is a tool that generates the blob. Which data does the tool > > need to generate it? > > The IDE/Software which produce the firmware blobs mostly generate it > directly and the projects the developers are using are binary stuff. And what do you type in this software to produce this "project"? This "project" would be source code, anyway. Even if we did not have the tools to produce the same "firmware" from this. > Parts of it maybe human readable but not suffisant to compile it or do > anything usefull with it. > > And as I have already written, SDCC compiled code is 3 times bigger as > the firmeware blob generated by a 8000 US$ IDE. And do you write C code in your IDE? What else does this IDE provide you to help you optimize your C code? If it's not C code, what is it? And it would be very hard to compare C-code with hand-written assembly. > And using a Microcontroller/ASIC with bigger memory is no solution since > sometimes it would be very costly... > > In my case arround 3 million Euro more for the final production (18mio). A good solution would be to improve the free/libre software available in Debian, since you seem to claim that SDCC is an option as a development tool to this said micro-controller. Is it a 8051? > Thanks, Greetings and nice Day/Evening > Michelle Konzack signature.asc Description: Digital signature
Come Join My Network at Digg
jai is a member of Digg and would like to send you an invitation. With Digg you can help promote and share news to the millions of Digg viewers with a single click (Digging a story). It is free to join and only takes a minute to sign up! To accept this invitation follow this URL: http://digg.com/invitefrom/jaiseo87?OTC-em-in1 To verify that this email was sent by Digg user jaiseo87, visit: http://digg.com/verifymail?key=e9035b38c2c67b9041bdfdda12f3a01c&OTC-em-in2 To opt out of ALL future emails from Digg, visit: http://digg.com/optout?key=c4b71992bd71327e8969323a5058372a&OTC-em-in3 Digg will NOT store your email address, even if you opt out! Digg will store only an encrypted key, which even Digg cannot decipher.
Re: [DRAFT] resolving DFSG violations
William Pitcock <[EMAIL PROTECTED]> writes: > On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote: >> But regardless, Debian has promised that Debian is only free software. > > Then why does Debian have non-free? Is that not part of Debian? One way to resolve this dilemma is to realize that 'Debian' can refer to two things: the project and the distribution. Debian the operating system is free software since non-free/contrib is not part of Debian (== main). Debian the project is not (strictly) a free software project since it contains and supports the non-free part. Thus, a reasonable position for a free software supporter may be to support the Debian operating system but not support the Debian project. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le jeudi 30 octobre 2008 à 12:07 +0100, Josselin Mouette a écrit : > > Wrong. You can help Ben Finney testing his packages. That would be > > much more useful than useless babbling on mailing lists. > > Of course that’s Ben Hutchings. Sorry for mistaking you, Ben. Anyone is welcome to *also* test my packages, of course; but those don't currently have much impact for the free vs. non-free divide :-) -- \“The right to search for truth implies also a duty; one must | `\ not conceal any part of what one has recognized to be true.” | _o__) —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504004: ITP: libsvn-look-perl -- A caching wrapper aroung the svnlook command.
Package: wnpp Severity: wishlist Owner: "Angel Abad (Ikusnet SLL)" <[EMAIL PROTECTED]> * Package name: libsvn-look-perl Version : 0.12.442 Upstream Author : Gustavo Chaves <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/SVN-Look/ * License : GPL3+ Programming Lang: Perl Description : A caching wrapper aroung the svnlook command. The svnlook command is the workhorse of Subversion hook scripts, being used to gather all sorts of information about a repository, its revisions, and its transactions. This script provides a simple object oriented interface to a specific svnlook invocation, to make it easier to hook writers to get and use the information they need. Moreover, all the information gathered buy calling the svnlook command is cached in the object, avoiding repetitious calls. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies
On Oct 21, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > I'm not sure that filing lots of bugs about missing Depends on > update-inetd really delays the release. Chris Lamb is fixing those bugs > faster than I file them anyway ;) WTF? Packages other than inetd daemons MUST NOT depend on update-inetd. Doing that is WRONG. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies
On 30/10/08 at 13:50 +0100, Marco d'Itri wrote: > On Oct 21, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > > > I'm not sure that filing lots of bugs about missing Depends on > > update-inetd really delays the release. Chris Lamb is fixing those bugs > > faster than I file them anyway ;) > WTF? Packages other than inetd daemons MUST NOT depend on update-inetd. > Doing that is WRONG. Are common maintainer scripts problems documented somewhere ? It would be very interesting to start a developers-reference chapter about such things. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504011: ITP: monodevelop-versioncontrol-bzr -- Bazaar support for MonoDevelop
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij <[EMAIL PROTECTED]> * Package name: monodevelop-versioncontrol-bzr Version : 0.0.1 Upstream Author : Levi Bard <[EMAIL PROTECTED]> Jelmer Vernooij <[EMAIL PROTECTED]> * URL : https://launchpad.net/monodevelop-bzr * License : GPL Programming Lang: C#, Python Description : Bazaar support for MonoDevelop Simple Add-In for MonoDevelop that provides support for the Bazaar Version Control System. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 10:34:47AM +, Robert Lemmen wrote: > we relax the "main" requirements insofar that a package that depends > on another package in non-free may stay in main (and doesn't have to > go to contrib). For the sake of 10 binary firmwares, you want to make whole Debian depend upon non-free ? Wow, what an achievement. No, please, we don't accept regressions as a solution. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpZxptM7mEq7.pgp Description: PGP signature
Re: DFSG violations: non-free but no contrib
Le Thu, Oct 30, 2008 at 05:31:44AM -0500, William Pitcock a écrit : > > non-free is not enabled by default. Suggests/Recommends: > would be technically feasible though. … but Recommends would not be welcome, as "No unmet recommends" was a release goal of Lenny. http://release.debian.org/lenny/goals.txt This leaves "Suggests". Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote: > For the sake of 10 binary firmwares, you want to make whole Debian > depend upon non-free ? Wow, what an achievement. ok, i think i came across in a wrong way, because that is certainly not what i want! but look at it this way: if we have a package that contains totally non-free firmware which is required to make it work, we basically have a few choices: 1. the whole package has to go to non-free 2. the package is split up into a non-free part and one that goes in main, which then cannot depend on the non-free one 3. the same, but with a dependency and the parts go to contrib and non-free respectively if i understand things correctly than option 2 is what we are trying to do with the kernel in the moment (correct me if i am wrong), and the only thing i am saying is that having a package A which will not 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 Description: Digital signature
Re: can buildd logs be sorted (again)?
Hi, On Wed, Oct 29, 2008 at 21:11, Thomas Viehmann <[EMAIL PROTECTED]> wrote: >> Can this be fixed? The current situation is less than useful since >> the latest build is buried in other output. > > If someone could attest to > http://buildd.debian.org/~tviehmann/cmp_versions_php.txt > (translated from the perl that udd uses) being wrong in only harmless > ways (except showing that C->Perl->PHP with the last step being done by > someone disliking PHP is not a good idea), I could ask Ryan to put > http://buildd.debian.org/~tviehmann/build.php > in the appropriate location. If it's of any use, the PET project has a implementation from scratch of Debian version comparison, made by reading policy and dpkg code. The only bug I know of is that it doesn't reject some invalid versions. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: [DRAFT] resolving DFSG violations
Am 2008-10-29 22:52:52, schrieb Thomas Bushnell BSG: > > I am sure, my enterprise is not the only one wondering about such > > requirement to let users modify firmware of sensibel hardware which CAN > > destuct the whole computer since they have to leafe out some stuff to > > get it into the small memories... > > How is this a reason not to provide source code? Manufacturerers can be sued... You get the hell if you for example modify the firmware uf a GSM modem and you disturb the GSM communication... It is NOT the Software distributor, but the Hardware Manufacturer which run into touble. I must certify my Hardware to be used in GSM networks. The if you modify the Firmware of my "24V DC Modular ATX PSU" which is connectedt to 24V Batteries and a SolarCharger and now you change the Reference vomtage from 24V (Gel batteries) to 25,9V (Li-Poly batteries), You can burn your computer and after this, there is NO preuv, it was my Firmware or your modified one. So now as a Manufacturer I have the choice between 1) Use a huge NV/FLASH/EEPROM Memory which make the Hardware maybe 10-20 Euro more expensive and I will lost customers. 2) Use huge external SRAM (makes the Hardware expensive too) to let users load there own non tested and non-optimised blob and become sued if something goes wrong. So, the Open-Source System does not realy work on Hardware... > I don't understand why this matters to you. Provide the source code; > Debian ships it, and nobody is hurt. If nobody ever makes use of it, > how has it harmed you? The sourcecode is the blob. I can reload it into my Develoment suit and edit it, but thats all. This SDKs use highly optimized builders/compilr and there is NO OpenSource solution for it. Increasing FLASH/SRAM only because someone maybe want to burn its hardware or damage others is braindamaged since they are NO waraties something will work correctly... The problem is, IF someone (e.g. Hobby frickler) do something wrong, I can be f...ed. I do not know HOW OpenMoko do this, but the certification for GSM software/firmware IS expensive and it IS required by law. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: DFSG violations: non-free but no contrib
In article <[EMAIL PROTECTED]> you wrote: > doesn't that sound reasonable to you? Yes maybe, but on the other hand, arent ppl used to the fact that the kernel does not know about some available modules? Thats the whole idea of modules (and plugins in other situations like media encoders). Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about bts-link: call for adoption
Re: Pierre Habouzit 2008-10-30 <[EMAIL PROTECTED]> > Anyways, the information is: I don't intend to maintain or run bts-link > anymore[2], it is up for adoption. If the BTS people wish to inherit the > beast they come first, but any motivated group of people are welcomed. If the BTS folks don't want it, we should put it into the QA realm. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: [DRAFT] resolving DFSG violations
Michelle Konzack wrote: Am 2008-10-29 22:52:52, schrieb Thomas Bushnell BSG: I am sure, my enterprise is not the only one wondering about such requirement to let users modify firmware of sensibel hardware which CAN destuct the whole computer since they have to leafe out some stuff to get it into the small memories... How is this a reason not to provide source code? Manufacturerers can be sued... You get the hell if you for example modify the firmware uf a GSM modem and you disturb the GSM communication... But most of the firmwares are outside wireless communication. How many manufacturers was sued because users burn the monitors (it was very easy) or other hardwares (e.g. try with hdparam) ? How many non conforming GSM devices are sold? How many of such devices are recalled by manufactures? ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 03:47:56PM +, Robert Lemmen wrote: > On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote: > > For the sake of 10 binary firmwares, you want to make whole Debian > > depend upon non-free ? Wow, what an achievement. > > ok, i think i came across in a wrong way, because that is certainly not > what i want! > > but look at it this way: if we have a package that contains totally > non-free firmware which is required to make it work, we basically have a > few choices: > > 1. the whole package has to go to non-free > 2. the package is split up into a non-free part and one that goes in >main, which then cannot depend on the non-free one > 3. the same, but with a dependency and the parts go to contrib and >non-free respectively no that's not how it will work. The split will be (and that's the sole *reasonnable* way to do it) to put firmwares away, it *different* source packages in non-free. The kernel will have patches to load those firmwares on demand (and fail if they're not here). This is what Ben did, and what needs testing. The kernel doesn't need to depend on the firmwares at _all_. All other options are silly and should not even be mentioned, unless the expected reactions to it are nervous laughs. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYSY5UlM7lf.pgp Description: PGP signature
Re: [DRAFT] resolving DFSG violations
Am 2008-10-30 17:49:40, schrieb Giacomo A. Catenazzi: > But most of the firmwares are outside wireless communication. Right, but they are some like the one from me. > How many manufacturers was sued because users burn the monitors > (it was very easy) or other hardwares (e.g. try with hdparam) ? Do you think, someone (manufacturers) is making it public? > How many non conforming GSM devices are sold? How many of such devices > are recalled by manufactures? You can not even sell GSM devices, if your software is not certified. The recalls are very very low... because they are tested Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: For those who care about bts-link: call for adoption
On Thu, Oct 30, 2008 at 04:52:58PM +, Christoph Berg wrote: > Re: Pierre Habouzit 2008-10-30 <[EMAIL PROTECTED]> > > Anyways, the information is: I don't intend to maintain or run bts-link > > anymore[2], it is up for adoption. If the BTS people wish to inherit the > > beast they come first, but any motivated group of people are welcomed. > > If the BTS folks don't want it, we should put it into the QA realm. Well, I have a small issue with that, in the sense that the QA "team" is completely disorganized, as every single DD is de facto a QA team member. I'd prefer if there are designated people(s) in charge, even if the chosen way to maintain it is to put it on collab-maint and can be altered by any DD. For now it needs constant care. Maybe it'll change later (which I wasn't able to achieve, by lack of interest), but for now it cannot "just work" sadly. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpeC4AmsxO2K.pgp Description: PGP signature
Re: [DRAFT] resolving DFSG violations
I'll add my two cents. I have some experience with radios. The FCC requires all radios to be certified before they can be sold, and there is a requirement that you must not make a device that is easily modifiable to operate outside the limits put forth by the FCC. In this case, it would be illegal to release the firmware's source code since it would violate the FCC rules, violate and void the radio's certification (and this also applies to Wifi/Bluetooth devices). I do agree firmwares fall under the DFSG and the social contract, and they should be split out, but included on the CD/DVDs so I can at least enable full hardware support out of the box. Michael On Thu, Oct 30, 2008 at 1:11 PM, Michelle Konzack <[EMAIL PROTECTED]> wrote: > Am 2008-10-30 17:49:40, schrieb Giacomo A. Catenazzi: >> But most of the firmwares are outside wireless communication. > > Right, but they are some like the one from me. > >> How many manufacturers was sued because users burn the monitors >> (it was very easy) or other hardwares (e.g. try with hdparam) ? > > Do you think, someone (manufacturers) is making it public? > >> How many non conforming GSM devices are sold? How many of such devices >> are recalled by manufactures? > > You can not even sell GSM devices, if your software is not certified. > The recalls are very very low... because they are tested > > Thanks, Greetings and nice Day/Evening >Michelle Konzack >Systemadministrator >24V Electronic Engineer >Tamay Dogan Network >Debian GNU/Linux Consultant > > > -- > Linux-User #280138 with the Linux Counter, http://counter.li.org/ > # Debian GNU/Linux Consultant # > Michelle Konzack Apt. 917 ICQ #328449886 > +49/177/935194750, rue de Soultz MSN LinuxMichi > +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 03:47:56PM +, Robert Lemmen wrote: > if i understand things correctly than option 2 is what we are trying to > do with the kernel in the moment (correct me if i am wrong), and the > only thing i am saying is that having a package A which will not work > (in some cases) without package B should declare some kind of > relationship on it. simply because there *is* a relation between them... That "sort of relationship" between a package A that possibly (i.e. "in some cases") might use a package B is AFAIK called "suggests" which would be just fine: it declares a relationship and it is allowed to declare it between packages in main and non-free. Hauke signature.asc Description: Digital signature
Re: [DRAFT] resolving DFSG violations
On Thu, 2008-10-30 at 01:48 -0500, William Pitcock wrote: > On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote: > > But regardless, Debian has promised that Debian is only free software. > > Then why does Debian have non-free? Is that not part of Debian? No, it's not part of Debian. Non-free is distributed by Debian, but it does not form a part of the Debian system. > If non-free is meant to be an opt-in part of Debian, then put the > distributable firmware there and be done with it. Of course, what I would be happy to see is the firmware moved to the non-free respository. That's exactly what we're talking about. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503991 closed by Michael Biebl (Re: Bug#503991: debian policy requires the configurable files be under /etc)
package powersaved reopen 503991 thanks On Thu, Oct 30, 2008 at 10:28:36AM +, Debian Bug Tracking System wrote: > Stanislav Maslovski wrote: > > Package: powersaved > > Version: 0.15.20-3 > > Severity: serious > > > > This severity is totally exagerrated. wishlist would have been much more > appropriate > > > Any non-trivial configuration of powersaved requires writing event scripts. > > At the moment these scripts must be placed under /usr/lib/powersave/scripts > > which violates Debian Policy (see below). Please respect the policy. > > I don't agree. You do not agree with the Debian Policy? > Event scripts are not configuration files and shouldn't > be edited. Wrong. In the case of powersaved they are. You can find many examples of such scripts placed under /etc in other packages (acpid, pm-utils, etc). The system administrator must have a possibility to add his own scripts and they must be placed under /etc, not to some random place in the filesystem. *At least* you have to provide a mean to do that for locally created scripts, but it would be better if all powersaved scripts where treated the same. > If you want to create locally modified scripts, feel free to > put them under /etc and symlink them. That is exactly what policy requires from _you_ as the package maintainer to do. I am reopening this bug and also CC-ing this message to debian-devel. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, 2008-10-30 at 17:34 +0100, Michelle Konzack wrote: > So now as a Manufacturer I have the choice between > > 1) Use a huge NV/FLASH/EEPROM Memory which make the Hardware maybe > 10-20 Euro more expensive and I will lost customers. > > 2) Use huge external SRAM (makes the Hardware expensive too) to let > users load there own non tested and non-optimised blob and become > sued if something goes wrong. Um, no. See, what you don't seem to understand is that users can load their own non-tested and non-optimized blob whether you release source or not. In fact, by not releasing source, you *increase* the risk that users' modifications will damage the hardware. The point here is that loadable firmware exposes you to a risk. The refusal to provide source has nothing to do with whether the risk is exposed; but providing source would *reduce* it. > So, the Open-Source System does not realy work on Hardware... Of course, we're not talking about Hardware, we're talking about firmware, which is, of course, a kind of software. > I do not know HOW OpenMoko do this, but the certification for GSM > software/firmware IS expensive and it IS required by law. If I understand correctly, then you (and perhaps many others), are not being honest in attaining GSM certification. You seem to be saying that the certification is contigent upon it being impossible for the user to change the behavior of the device in a non-compliant way. But the mere fact that you are using loadable firmware means that the user can make such a change. It has nothing to do with the license for the firmware, or whether there is source, or even whether your or Debian or anyone else distribute the firmware. The device, in fact, *cannot* be guaranteed to meet the certification, because it provides the capacity for users to load non-compliant firmware. Now whether that's a serious problem or not, I don't know, but it is entirely distinct from the license terms on the firmware blob. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, 2008-10-30 at 13:23 -0400, Michael Casadevall wrote: > I have some experience with radios. The FCC requires all radios to be > certified before they can be sold, and there is a requirement that you > must not make a device that is easily modifiable to operate outside > the limits put forth by the FCC. In this case, it would be illegal to > release the firmware's source code since it would violate the FCC > rules, violate and void the radio's certification (and this also > applies to Wifi/Bluetooth devices). The mere fact that the firmware can be loadable--with or without source code--means that it can be easily modified. The ease of modification is not about the obfuscation of the blob, but about the mere fact that it can be loaded. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about bts-link: call for adoption
On Thu, 30 Oct 2008, Pierre Habouzit wrote: > Anyways, the information is: I don't intend to maintain or run > bts-link anymore[2], it is up for adoption. If the BTS people wish > to inherit the beast they come first, but any motivated group of > people are welcomed. I'd really be glad if someone would want to maintain it under the debbugs group. Unfortunatly, because it's written in python, that pretty much excludes me. [Well, at least for all but the most trivial and obvious fixes.] Don Armstrong -- Every gun that is made, every warship launched, every rocket fired signifies in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. This is not a way of life at all in any true sense. Under the clouds of war, it is humanity hanging on a cross of iron. -- Dwight Eisenhower, April 16, 1953 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can a kernel in main depend on firmware in non-free to work?
On Oct 30, 2008, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Whether they are plugins or modules or whatnot is irrelevant here. I'm not sure on what policies your statement is based on, but clearly to me what defines a package is not just an artifact of upstream packaging that Debian itself is Free to modify, and quite often does. It does make a difference when the components don't quite form an inseparable unit, but rather they're just put together in a single tarball for convenience. Say, Debian splits out the kernel documentation and kernel headers from the kernel image+modules, although they ship in a single package upstream. Say, the stuff David Woodhouse put together in the kernel firmware git repository hardly forms a unit or a package proper, it's just a bunch of unrelated firmware files. It doesn't make sense to push them all into main just because they're released in a single tarball. The fact that Debian does hard work to split Free from non-Free to keep portions of a package in main while moving others to non-free shows that this upstream package boundary is quite a thin argument for you to stand on. > The only thing that matters is package dependencies. But not as in '.deb requirements tags', but rather in 'compilation or execution requirements', as per the Debian policies, right? And then, ultimately, it's Debian that decides what a Debian package amounts to. >> There *is* reason to split the linux package, I thought that was >> beyond any doubt by now. Debian isn't supposed to ship non-Free >> Software, and Linux does include non-Free firmwares. > And this has already been the case for long. I can't tell what point you're trying to make with this statement, or how it relates with the conversation underway. Can you please elaborate, so that I don't misunderstand what you were trying to communicate? >> The doubt is whether the split is going to stop at the firmwares, or >> also cover the modules that require the firmwares. > No, there is no doubt about that either. There is absolutely no need to > split these modules. Err... Are you just voicing your personal opinion, or is this authoritative information about a decision you're in charge of, or widely known among Debian developers? I don't know your role in the Debian project, so please bear with my ignorance. I can see that, given a certain set of policies, there would be no need for such a split. But, heck, it's not even clear to me whether the policies distinguish source and binary packages. Like, I know the sources for main binaries can't contain non-Free components, so different sources are used for main and non-free split builds, and that's how it should be IMHO. But do policies make room for a single Debian package build to create a binary .deb that goes in main and another binary .deb that goes in contrib? If so, this would enable the trivial creation of separate packages for kernel modules, in contrib, that explicitly Depend on the corresponding non-Free firmwares in non-free, while the binary package in main is self-contained, fully-functional (i.e., no code is limited in its functionality because some other piece it requires is absent), easy to maintain (I suppose) and even amenable to run-time combination with the modules that have non-Free dependencies, for those who tolerate or even like that. >> it could be that I'm just still missing something. If so, please >> share your enlightenment. > It seems you are misunderstanding what contrib is for. /me missed the enlightenment sharing requested above :-( Please do share. What is contrib for, in your understanding? And pretty please copy me, as requested in the Mail-Followup-To header, I'm not on this list. BTW, is this an appropriate forum for seeking enlightenment and offering suggestions about Debian policies, and how they apply to the decision at hand? If not, I'd be glad to abide by suggestions of more appropriate Debian mailing lists. Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, Oct 30, 2008 at 12:10:48AM +0100, Michelle Konzack wrote: > Curently I am building a hardware where the parts cost arround 40US$ per > device (@10.000) and using the same microcontroller with a "big" FLASH > memory would mke this Hardware arround 5 US$ in final production more > expensive. > > So for the end-users arreound 10 US$ or 8 Euro > > Are you willing to pay arround 15-18% more for such hardware? Yes I would. Given that hardware modems were still available but at higher cost after software modems started taking over the market just shows that there are people who will pay for good hardware that can actually be supported by free software. > Also you shouls know, that code generated by SDCC is 3 times bigger then > the one build by my IDE provided by the Microcontroller manufacturer. So, maybe SDCC could be improved. > Which mean, I must switch from a 32 kByte model to a 128 kByte one. Not as if that's big by today's standards. > Or by attaching an external NVRAM of 128 kByte like the Atmel AT29BV010A > and I think, you can check the price for yourself... > > Again: ARE you realy willing to pay at least > 10US$ or 8? more for the hardware? Absolutely. I know I may be a minority, but I do pay extra to buy high quality hardware rather than the cheapest crap I can find. On the other hand I am much happier with my stuff because it works better, lasts longer, and doesn't waste my time dealing with @#$#$ firmware files. > I mean, the I am trying currently servera hardware models since I need > highly optimized one (for solar-Energie Systems) and there is nothing in > production yet. I am 100% free what to do and how I do it... > > Since all of my software must run under GNU/Linux and is licensed under > GNU GPL version 3 I like to see, that my hardware/Software fit the DFSG > which mean, must run with "main". Well if you require firmware to be provided by the OS to the hardware, then the firmware either includes sources and goes in free, or it doesn't and goes in non-free and some people will want to avoid buying it for that reason. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Wed, Oct 29, 2008 at 09:47:00PM +0100, Michelle Konzack wrote: > There are SDKs called "Builder" where you will have NEVER source code, > even as Developer, since the "Builder" create an IMAGE which will be > uploaded into the the SRAM of a Microcontroller (I have some 8051 > compatibles) and then after uploading it is executed... So if you use one of those, YOU chose to use non-free software. That isn't Debian's fault, and it isn't their problem that you chose to use such a combination. > The Microcontroller cost arround 4 US$ but if I user the same WITH > integrated FLASH memory, it cost arround 9-12 US$. > > So, the prefered form of distributing is a 16/32/64/128/256 kByte IMAGE. > > Currently I am developing a Hardware where I need such thing and now > puzzeling arround whether to use a firmware loader (GNU GPL version 3.0, > already coded and packed for the Debian distribution) or use the same > Microcontroller WITH FLASH which then is arround 5 US$ more expensive > and if the final Hardware cost arround 40 US$ (without VAT) in Low-Cost. > > I do not know, whether my customers accepet 5 US$ more. Who knows. I guess a question is, do you want it to work with a free system like Debian, or are you going to require users to use an external firmware file that in the case of Debian at best would mean they have to enable non-free. > However, my Firmware Loader must be there anyway for upgrades... Sure, but the user would only need to deal with non-free stuff if they actually want to update it. Not for normal use. > The question is, what do you want with the Sourcecode? Who knows, who cares. That doesn't matter. > Reprogramming? A singel error in the parameters will cook your computer > hardware and HOW do you want to recode something or add functionality? > > I have choosen the smallest Microcontroller required to save money... Yep. Again your choice. Might be a good choice, but every choice has advantages and disadvantages. > Yes, I can reploaye a MC with 16 kByte SRAM with one which has 256 kByte > and then OSS frickler can add stuff, but this would make the controller > over 10 times more expensive... > > Please think about it. We have. Debian main's policies are not and should not be influenced by your bottom line. It just doesn't matter to the Debian project. It is not decided by the convinience factor of end users who decided to go for the cheapest piece of crap hardware they could find. If convinience was the only factor, then why not use the OS the hardware developer provided drivers for (probably windows of course)? > I have the hell striping down the firmware of my hardware to fit into > 32 kByte and you are talking about modifications to it... > > I am sure, my enterprise is not the only one wondering about such > requirement to let users modify firmware of sensibel hardware which CAN > destuct the whole computer since they have to leafe out some stuff to > get it into the small memories... That still isn't the point. If someone uses a soldering iron on the device they are also likely to break it. A hammer could break it too. Who cares. The point is whether or not your device is capable of operating with a system consisting entirely of free software or not. This doesn't mean you have to provide free firmware, as long as the operating system doesn't need to have anything to do with getting that firmware to your device. If you have flash to provide it to yourself at power on, great, you took care of it. Some users may still dislike your device for having closed hardware, but that's a free hardware question, not a free operating system/software question, and Debian isn't about free hardware, it is about free software. > It is useless because I am building a hardware which take me several > month to develop plus coding testing the software in a secured > environement where hardware can not be destucted... > > The lifetime of such hardware would be maybe 3-5 years and now, you can > explain me, HOW you would develop/recode the firmware, if you have NOT > the requirement environement, risking damages to the hardware and more. > > You do not know the internals of my hardware and have to guess things. > Without the hardware developer tools you can not even DEBUG the Hardware > while loading YOUR hacked firmware. Even if my hardware has a JTAG > connector... It might be useful to one person in a million. > > > So the plan is: "Debian is only for hardware manufacturers that > > > embed the firmware in flash. If you hide your non-free stuff, that'd > ^ > Which would make hardware much more expensive That's right. You can make your hardware contain non-free stuff, and Debian doesn't care since that's a hardware thing. Other people will still care of cousrse, but probably a lot less. Just don't require Debian to include non-free stuff to make your hardware work
Re: DFSG violations: non-free but no contrib
On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote: > For the sake of 10 binary firmwares, you want to make whole Debian > depend upon non-free ? Wow, what an achievement. > > No, please, we don't accept regressions as a solution. So if any of the hardware that requires non-free firmware to operate and currently works in etch was to not work with Lenny, then that's completely unacceptable? If that's the case, then there is no way EVER to make Debian comply with the DFSG since you aren't going to get free firmware for all those devices. Maintaining support for most of that hardware through the use of non-free can be done. Maintaining support for all that hardware through only main is imposible and unrealistic. So a demand of no regressions is just insane. Debian shouldn't ever have worked with that hardware in the first place in the case of main only installs. -- Len SOrensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can buildd logs be sorted (again)?
Adam D. Barratt wrote: > > In this specific case, he was already CCed on Steve's mail which began > this thread... Didn't notice it, sorry for the noise. > > Adam Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can buildd logs be sorted (again)?
Thomas Viehmann wrote: > Hi, > > Steve M. Robbins wrote: >> The buildd log pages, e.g. [1], used to be sorted by package version >> (or maybe build date). However that is no longer the case. > > It seems that build.php relies on the results of opendir/readdir to be > in order and that assumption not being valid anymore. > >> Can this be fixed? The current situation is less than useful since >> the latest build is buried in other output. > > If someone could attest to > http://buildd.debian.org/~tviehmann/cmp_versions_php.txt > (translated from the perl that udd uses) being wrong in only harmless > ways (except showing that C->Perl->PHP with the last step being done by > someone disliking PHP is not a good idea), I could ask Ryan to put > http://buildd.debian.org/~tviehmann/build.php > in the appropriate location. Nice, yet another rewrite of dpkg's code, but now in PHP[1]. So, let's test it with a script I wrote during DC8 (as suggested by Lucas): 8<->8 buildd.php failed test 'foo- foo 0'/tests/foo with '1' buildd.php failed test 'foo fo 1'/tests/foo with '-1' buildd.php failed test 'foo- foo+ -1'/tests/foo with '1' buildd.php failed test 'foo~1 foo -1'/tests/foo with '1' buildd.php failed test 'foo.bar foo1bar 1'/tests/foo with '-1' buildd.php failed test 'foo.bar foo0bar 1'/tests/foo with '-1' buildd.php failed test '1foo:bar 1:bar x This is a syntax violation so the result is "undetermined" but shouldn't be any of these: -1 0 1'/tests/foo with '-1' buildd.php failed test '1foo-1 foo-1 -1'/tests/foo with '1' buildd.php failed test '0.8.0a-1 0.8.0-2 1 gnunet'/tests/versions.lenny-sid with '-1' buildd.php failed test '0.8.0a-1 0.8.0-1 1 gnunet-gtk'/tests/versions.lenny-sid with '-1' buildd.php reached the 10 tolerated failures The remaining tests will be skipped 8<->8 With regard to the '1foo:bar 1:bar' test: this test is usually passed when the versions comparing function returns null (in PHP terms), making the 'case' script exit with a non-zero status. In your implementation I see parseversion returning null when it encounters an invalid version, but cmp_version doesn't care about it. The tests are in a "version1 version2 expected_result comments"-format. I will later test udd's perl implementation just to make sure it is ok (although I believe it's PET's which is not perfect either). [1] I promised Christoph Berg that I am going to write a PHP extension, actually an interface, to libapt's functions; but I haven't been lucky enough to find the docs (libapt-pkg-doc isn't what I expected). If somebody can point me to the right documents it would be great. > > Kind regards > > T. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can buildd logs be sorted (again)?
Martín Ferrari wrote: [...] > > If it's of any use, the PET project has a implementation from scratch > of Debian version comparison, made by reading policy and dpkg code. > The only bug I know of is that it doesn't reject some invalid > versions. > To be more precise: $ ./test pet.pl pet.pl failed test 'foo- foo 0'/tests/foo with '1' pet.pl failed test 'foo- foo+ -1'/tests/foo with '1' pet.pl failed test '1foo:bar 1:bar x This is a syntax violation so the result is "undetermined" but shouldn't be any of these: -1 0 1'/tests/foo with '-1' pet.pl failed 3 over 731 tests @Martín[OT]: hope you can find some time to write an email, probably addressed to [EMAIL PROTECTED], about your proposed version=4 watch files; as I'm about to write down my proposed "watch file format" specs. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, 2008-10-30 at 16:33 -0400, Lennart Sorensen wrote: > So if any of the hardware that requires non-free firmware to operate and > currently works in etch was to not work with Lenny, then that's > completely unacceptable? > > If that's the case, then there is no way EVER to make Debian comply with > the DFSG since you aren't going to get free firmware for all those > devices. Um, yes there is. We could do the same thing we do with codecs, file formats, and all the rest--in the absence of support with free software, we don't support it in Debian. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Oct 31, 2008
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 498 (new: 60) Total number of packages offered up for adoption: 118 (new: 0) Total number of packages requested help for: 49 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: a2ps-perl-ja (#503554), orphaned 4 days ago Description: perl version of Miguel Santana's a2ps (supports KANJI) Installations reported by Popcon: 164 chdrv (#503522), orphaned 4 days ago Description: Chinese terminal for the Linux console Installations reported by Popcon: 5 chdrvfont (#503522), orphaned 4 days ago Description: Chinese terminal for the Linux console Reverse Depends: chdrv Installations reported by Popcon: 38 cookietool (#503560), orphaned 4 days ago Description: A team of programs to help you maintain your fortune database Installations reported by Popcon: 122 crafty (#503533), orphaned 4 days ago (non-free) Description: state-of-the-art chess engine, compatible with xboard Reverse Depends: gnome-games Installations reported by Popcon: 398 crafty-books-medium (#503534), orphaned 4 days ago Description: Small-size opening books for crafty chess engine. Installations reported by Popcon: 154 crafty-books-medtosmall (#503534), orphaned 4 days ago Description: Small-size opening books for crafty chess engine. Installations reported by Popcon: 146 crafty-books-small (#503534), orphaned 4 days ago Description: Small-size opening books for crafty chess engine. Installations reported by Popcon: 29 epic4 (#503558), orphaned 4 days ago Description: epic irc client, version 4 Reverse Depends: epic4-script-hienoa epic4-script-lice Installations reported by Popcon: 381 epic4-help (#503558), orphaned 4 days ago Description: epic irc client, version 4 Reverse Depends: epic4 Installations reported by Popcon: 397 es (#503547), orphaned 4 days ago Description: An extensible shell based on `rc' Installations reported by Popcon: 46 fluidsynth (#503528), orphaned 4 days ago Description: Real-time MIDI software synthesizer Reverse Depends: audacious-plugins-dev audacious-plugins-extra fluidsynth fluidsynth-dssi freesci freewheeling libcsound64-5.1 libfluidsynth-dev libtritonus-bin mscore (5 more omitted) Installations reported by Popcon: 4273 freetype1 (#503505), orphaned 4 days ago Description: Old FreeType 1 development files (static library and headers) Reverse Depends: freetype1-tools libttf-dev ttf2tex Installations reported by Popcon: 10171 gnuplot-mode (#503549), orphaned 4 days ago Description: Yet another Gnuplot mode for Emacs Installations reported by Popcon: 720 hbf-cns40-1 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Reverse Depends: hbf-cns40-b5 Installations reported by Popcon: 134 hbf-cns40-2 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Reverse Depends: hbf-cns40-b5 Installations reported by Popcon: 133 hbf-cns40-3 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Reverse Depends: hbf-cns40-b5 Installations reported by Popcon: 133 hbf-cns40-4 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Installations reported by Popcon: 87 hbf-cns40-5 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Installations reported by Popcon: 87 hbf-cns40-6 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Installations reported by Popcon: 86 hbf-cns40-7 (#503508), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (CNS plane 1) for CJK Installations reported by Popcon: 85 hbf-cns40-b5 (#503511), orphaned 4 days ago Description: Chinese Fanti Song 40x40 bitmap font (Big5) for CJK Installations reported by Popcon: 127 hbf-jfs56 (#503507), orphaned 4 days ago Description: Chinese Jianti Fangsong 56x56 bitmap font (GB2312) for CJK Installations reported by Popcon: 101 hbf-kanji48 (#503506), orphaned 4 days ago Description: Japanese Kanji 48x48 bitmap font (JIS X-0208) for CJK Installations reported by Popcon: 162 hermes1 (#503535), orphaned 4 days ago Description: The Hermes pixel-format library Reverse D
Is Christian Sánche z still active?
[Cc me on replies, thanks] Hi Jose and Anibal, You did sponsor packages for Christian Sánchez before, do you know if he is still active in Debian or how could I contact him? I failed to contact him on two ocasions: about an RC bug[1] in libfile-sharedir-perl, and about his ITP[2] of libopenoffice-oodoc-perl [1] http://bugs.debian.org/496122 [2] http://bugs.debian.org/457482 Searching lists.debian.org shows that his last activity was from around the late 2007. There were 4 NMUs of his (total 6) packages in 2008. Unless I hear otherwise soon, I will take over libfile-sharedir-perl and the libopenoffice-oodoc-perl ITP (or any of his packages, all lib*-perl) for the Debian Perl Group. Of course, he is welcome to join the group and have his packages being co-maintained by us. -- damJabberID: [EMAIL PROTECTED] signature.asc Description: Digital signature
