Re: Sun Java available from non-free
On Wed, 24 May 2006 07:41:04 -0500, Matthew R. Dempsky wrote: On Wed, May 24, 2006 at 12:10:43AM +0200, Michael Banck wrote: Sure we could just have disclosed the license to -legal beforehand, but then Sun probably would never talk to us about doing things like this one again and just tend to OpenSUSE or some other community distribution next time to collaborate with when they might open source Java. Sun's non-free software is *that* important to Debian? Don't miss the text book straw man.¹ Breaching confidences by disclosing the license beforehand is a misrepresentation of the best alternative: simply letting Sun know that community consultation is going to be necessary and that consultation can occur when Sun chooses to publish its license. It's preposterous that Sun would otherwise never talk to Debian again and collaborate with some other community distribution. Amusingly this Doomsday scenario is only adverted through the community distribution keeping its activities secret. Regards, Adam 1. http://en.wikipedia.org/wiki/Straw_man -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Sun, 21 May 2006 23:25:28 -0700, Russ Allbery wrote: Adam Warner [EMAIL PROTECTED] writes: On Sun, 21 May 2006 20:20:09 -0700, Russ Allbery wrote: It's an important document and certainly something that every developer should read and endeavor to follow where it makes sense, but things go into the Developer's Reference rather than Policy frequently precisely *because* they don't make sense as global requirements and there are reasons why one might not wish to follow them. You're correct. So can you give reasonable and legitimate reasons why one might not wish to follow the you must guidelines in this instance? Two, actually. One for the advantage of PR with the timing of the release, which while it's a reason that I can see people not agreeing with and it isn't important to me personally, I think it's a reasonable one. Later in the reply you state, *I* think the license is murky, potentially problematic, and borderline for non-free. Looks like a hard call. Good thing I don't have to make it. Many thanks to the people who do that work. I don't see how Debian acting as Sun's public relations poodle on such a murky, potentially problematic and borderline decision is reasonable. Second, the people involved were certainly in a position to know whether anyone else was working on this (given the people who cooperated on it), so they may have concluded that an ITP would have served no useful coordinating purpose. (And, in fact, if they did conclude that, they would appear to be correct -- I haven't seen anyone stepping forward upset that their efforts to package Sun Java were stomped on.) The process would have included a license discussion. Yet in this case the ITP would have served an extremely useful coordination purpose: letting interested parties participate. It would only have served no useful purpose if the intent was to ensure the packages went into non-free without dissent. Do you think that this package would have ever gone into non-free without dissent? An ITP would have resulted in the exact same discussion we just had, and if the ftp-masters had then approved it after concluding that the arguments presented weren't strong enough, people would have been just as upset if not more so. Postulating that the same decision would be made if appropriate processes had been followed does not excuse their short-circuiting. I suspect the outcome would have been different because a public process would have removed PR deadline pressure. You seem to be assuming that if they'd filed an ITP first, this discussion would have changed their mind. I don't see any reason to believe that. I don't see any reason to believe that this discussion raised any issues that they'd not already thought about. In that case, I'm not sure what the point would have been, given that the people involved were the people who were going to make the decision anyway. The murky, potentially problematic and borderline decision was made under the pressure of a public relations deadline. I see many reasons why a different decision would have resulted from a leisurely examination of the license. Posting the ITP first would have indeed been the right move if license evaluation were a democratic or consensus process. My understanding is that this is not how Debian works, whether one likes that or not. My understanding is that debian-legal gives INPUT into whether a package is suitable for main, contrib or non-free; *especially* in the case of a brand new license. I'll tone down the rhetoric: Having FTP masters Anthony Towns (aka The Debian Project Leader), James Troup and Ryan Murray personally liable to defend and indemnify Sun for mistakes made in the Debian packaging and distribution of Sun Java could adversely affect the wider Debian community. Almost everything the ftp-masters do could have an adverse affect on the wider Debian community if they do it poorly. That's why the position is so important. Fair enough. I feel one or more of the ftp-masters did their job poorly. They inadvertently put the interests of Sun before the wider community. So far, I see a bunch of amateur legal theorizing (my own included) and a lot of people worrying. I am, so far, failing to detect falling fragments of sky. *little shrug*. I do understand some of why you're upset, I think, but it does seem like it's at least partially based on a mistaken impression of who is responsible for doing license evaluation in non-free and who they're obligated to consult with first. Maybe I'm weird in this because of my personal background. One of my previous volunteer jobs was to run the Usenet newsgroup creation process for the Big Eight hierarchies. After doing that for a number of years, I have to say that I've had the problems with public consensus processes rubbed in my face fairly effectively a number of times. With the Big Eight, there's no formal organizational structure
Re: Sun Java available from non-free
On Sun, 21 May 2006 16:17:52 -0500, Raphael Hertzog wrote: If Sun doesn't fix the license (and I don't think it is our work to fix The license is good enough for Debian (ftpmasters took their decisions). There's no fix to require, but it would be good to continue working them to enhance even more the license. Such a constructive behaviour would put us in a good position to make sure that Sun releases java in a DFSG-free compliant license when they will open-source it. As Bill Allombert just pointed out, the Intention To Package process was clearly subverted: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-newpackage Assuming no one else is already working on your prospective package, you must then submit a bug report (Bug reporting, Section 7.1) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package, and the current URL where it can be downloaded from. That is, you must submit descriptions of the new packages, including their license(s). In this case the license was brand new and likely controversial. Yet every stage was conducted in secret, including immediate uploads into non-free. Will YOU take personal responsibility to stand by this license as appropriate for non-free? Reread clause 2 of the Distributor License for Java version 1.1: License Grant. Subject to the terms and conditions of this Agreement, as well as the restrictions and exceptions set forth in the Software README file, Sun grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and use the Software internally, complete and unmodified, for the sole purposes of running Programs and designing, developing and testing Programs. Sun also grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and distribute the Software, directly or indirectly through your licensees, distributors, resellers, or OEMs, electronically or in physical form or pre-installed with your Operating System on a general purpose desktop computer or server, provided that: (a) the Software and any proprietary legends or notices are complete and unmodified; (b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System; (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; (d) you do not remove or modify any included license agreement or impede or prevent it from displaying and requiring acceptance; (e) you only distribute the Software subject to this license agreement; and (f) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from (i) the use or distribution of your Operating System, or any part thereof, in any manner, or (ii) your use or distribution of the Software in violation of the terms of this Agreement or applicable law. You shall not be obligated under Section 2(f)(i) if such claim would not have occurred but for a modification made to your Operating System by someone not under your direction or control, and you were in compliance with all other terms of this Agreement. If the Software README file permits certain files to be replaced or omitted from your distribution, then any such replacement(s) or omission(s) shall not be considered a breach of Section 2(a). Distribution is conditioned upon acceptance of subclause (f). The distributor agrees to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from (i) the use or distribution of your Operating System, or any part thereof, in any manner... IN ANY MANNER. Note that arises or results from in any manner is distinct from your use or distribution of the Software in violation of the terms of this Agreement or applicable law. There is a defence for (f)(i) if the modifications causing the damages, costs, liabilities, settlement amounts, etc. were not under the distributors direction or control (while being in compliance with all other terms of the Agreement). This defence may not be applicable when modifications that happen to cause damage, etc. are under the direction or control of Debian/SPI. When did we decide,
Re: Sun Java available from non-free
On Sun, 21 May 2006 20:20:09 -0700, Russ Allbery wrote: Adam Warner [EMAIL PROTECTED] writes: As Bill Allombert just pointed out, the Intention To Package process was clearly subverted: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-newpackage Assuming no one else is already working on your prospective package, you must then submit a bug report (Bug reporting, Section 7.1) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, a description of the package, the license of the prospective package, and the current URL where it can be downloaded from. That is, you must submit descriptions of the new packages, including their license(s). Er, statements in the Developer's Reference are not Policy and are not a requirement for Debian Developers. The word must there does not mean what it means in Policy. It's an important document and certainly something that every developer should read and endeavor to follow where it makes sense, but things go into the Developer's Reference rather than Policy frequently precisely *because* they don't make sense as global requirements and there are reasons why one might not wish to follow them. You're correct. So can you give reasonable and legitimate reasons why one might not wish to follow the you must guidelines in this instance? It is, in fact, quite common for no ITP to be filed when the people doing the work believe that everyone involved already knows that it's going on and the ITP would serve no useful coordination purpose. Yet in this case the ITP would have served an extremely useful coordination purpose: letting interested parties participate. It would only have served no useful purpose if the intent was to ensure the packages went into non-free without dissent. For example, I don't recall any ITPs filed for all the X.Org 7 packages, and I think doing so would have been silly. Because there was general consensus to move to x.org after *massive* discussion on public mailing lists, including debian-legal. Also a staggering amount of publicly accessible work was available while the packages were being developed, all archived in debian-x. When did we decide, as a community, to defend and indemnify Sun for the community's mistakes in packaging Sun's implementation of Java the language and platform? Since Debian has no legal existence as an entity, we clearly didn't. There is no legal Debian entity that could take on such an obligation other than the SPI, and I think it's clear that the SPI didn't in this case. I'd say that the obvious interpretation would be that the ftp-masters take on that responsibility individually. I'll tone down the rhetoric: Having FTP masters Anthony Towns (aka The Debian Project Leader), James Troup and Ryan Murray personally liable to defend and indemnify Sun for mistakes made in the Debian packaging and distribution of Sun Java could adversely affect the wider Debian community. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DO NOT UPGRADE UNSTABLE: Terminal text stops functioning
Hi all, Since upgrading to the latest unstable I have discovered that after my startup reaches Setting up X socket server directory ... that I get no further output at the terminal. I have confirmed this on two different computers. Neither the computers nor keyboards are locked up. I am able to boot into single user mode and then blindly type in my root password at what should be the request for a root password and then blindly type reboot and the system reboots. I have recently upgraded: dialog_0.9b-20030720-1_i386.deb base-files_3.0.9_i386.deb initscripts_2.85-5_all.deb sysvinit_2.85-5_i386.deb sysv-rc_2.85-5_all.deb libsasl2_2.1.15-3_i386.deb apt_0.5.6_i386.deb apt-utils_0.5.6_i386.deb ilisp_5.12.0+cvs.2003.07.20_all.deb ilisp-doc_5.12.0+cvs.2003.07.20_all.deb po-debconf_0.7.0_all.deb libncurses5_5.3.20030719-1_i386.deb libncurses5-dev_5.3.20030719-1_i386.deb ncurses-base_5.3.20030719-1_all.deb ncurses-bin_5.3.20030719-1_i386.deb autotools-dev_20030717.1_all.deb libsasl7_1.5.28-5_i386.deb base-config_1.67_all.deb libnewt0.51_0.51.4-14_i386.deb whiptail_0.51.4-14_i386.deb The bug is most likely caused by initscripts, sysvinit or sysv-rc. If you have upgraded you may wish to downgrade/wait for a fix before rebooting, especially if your computer doesn't automatically boot into X. Regards, Adam
Re: DO NOT UPGRADE UNSTABLE: Terminal text stops functioning
I wrote: The bug is most likely caused by initscripts, sysvinit or sysv-rc. If you have upgraded you may wish to downgrade/wait for a fix before rebooting, especially if your computer doesn't automatically boot into X. I have confirmed that downgrading to initscripts_2.85-4.1_all.deb sysv-rc_2.85-4.1_all.deb and sysvinit_2.85-4.1_i386.deb will resolve the lack of terminal output. I am submitting a bug report for the initscripts package, soon to appear here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=initscripts Regards, Adam
Re: DO NOT UPGRADE UNSTABLE: Terminal text stops functioning
Hi Geordie Birch, On Tue, Jul 22, 2003 at 06:14:01PM +1200, Adam Warner wrote: I wrote: The bug is most likely caused by initscripts, sysvinit or sysv-rc. If you have upgraded you may wish to downgrade/wait for a fix before rebooting, especially if your computer doesn't automatically boot into X. I have confirmed that downgrading to initscripts_2.85-4.1_all.deb sysv-rc_2.85-4.1_all.deb and sysvinit_2.85-4.1_i386.deb will resolve the lack of terminal output. I am submitting a bug report for the initscripts package, soon to appear here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=initscripts FWIW, I have version 2.85-5 of initscripts, sysvinit, and sysv-rc installed and am not having any problems re. terminal output. Just to confirm, your system boots into a terminal by default, you rebooted your computer and all text was displayed at the terminal including the login prompt? How about if you boot into single-user mode? (you should be able to do this by entering linux single (without the quotation marks) at the lilo prompt). Regards, Adam
Re: DO NOT UPGRADE UNSTABLE: Terminal text stops functioning
Hi Geordie Birch, The bug is most likely caused by initscripts, sysvinit or sysv-rc. If you have upgraded you may wish to downgrade/wait for a fix before rebooting, especially if your computer doesn't automatically boot into X. I have confirmed that downgrading to initscripts_2.85-4.1_all.deb sysv-rc_2.85-4.1_all.deb and sysvinit_2.85-4.1_i386.deb will resolve the lack of terminal output. I am submitting a bug report for the initscripts package, soon to appear here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=initscripts FWIW, I have version 2.85-5 of initscripts, sysvinit, and sysv-rc installed and am not having any problems re. terminal output. FWIW this has also happened on a third system. I am running out of additional computers to break. Regards, Adam
Re: DO NOT UPGRADE UNSTABLE: Terminal text stops functioning
Hi Geordie Birch, FWIW, I have version 2.85-5 of initscripts, sysvinit, and sysv-rc installed and am not having any problems re. terminal output. Upon standard bootup into a terminal it appears that output ceases before the INIT: Entering Runlevel : 2 message but will start up again if the kernel sends a message to the terminal. This could explain how you were still able to see the login. I suspect if you look harder at your terminal output you will see some of it is missing. You could be fortunate that a kernel message restarted the terminal output. On my third system output had also fully ceased in single user mode just like the rest. But when booting normally it restarted after a while when the parport module produced output. Perhaps one of the upgraded scripts contains an XOFF (CTRL-S) character code. Regards, Adam
Re: why mplayer not in Debian
Hi A Mennucc1, I just want to say that some time ago Dariush Pietrzak [EMAIL PROTECTED] and I decided to package mplayer when we uploaded for the first time, the ftp-installer had some (good) reasons not to accept it so we went into it and tried to clear all possible problems w.r.t. DFSG: we sent e-mails to any author of any piece of code that was suspicious, and at the end we did a packaging of mplayer 0.90 rc4 that we thought was ok I follow Debian Legal and I am aware that this issue was raised most recently in May: http://lists.debian.org/debian-legal/2003/debian-legal-200305/msg00618.html Have you or Dariush Pietrzak addressed Don Armstrong's response? It would be great to know that you have cleared the non-patent-related problems: mplayer may or may not have patent problems, but they are not what is stopping it from going into Debian. Please read the threads starting at [1] [2] for more information on why mplayer is currently not in debian. You may have sent emails but did you get replies, and where have you documented them? And did you let anyone know? Why doesn't there appear to have been any followup to Debian legal? I am still willing to mantain mplayer, but I will not do any work unless someone that has ftp-installer priviledge in Debian states that s/he will help (= examine it when we upload and tell if it can go into Debian, or why it cannot go) Well I'm also willing to download the mplayer source myself, extract it and type fakeroot debian/rules binary. What you need to be willing to address are the concerns that were raised. Please address Debian legal. ps: I am not subscribed to the list I have also emailed you my response. If as a Debian developer you are unwilling to subscribe perhaps you could check the archives: http://lists.debian.org/debian-devel/2003/debian-devel-200307/thrd4.html Or point your news client to nntp://news.gmane.org. Regards, Adam
Re: DO NOT UPGRADE UNSTABLE: Terminal text stops functioning
Hi Lucas Moulin, I've upgraded my system yesterday, and I've seen the problem you're talking about. Actually, I don't see any boot messages after Setting up ICE socket..., but I see wdm starting, and I got the login prompt right after. That makes me think this is bootlogd related. It is. And it has hopefully been addressed by Miquel van Smoorenburg (thanks Miquel). Less than five hours from report to new packages being created: Changes: sysvinit (2.85-6) unstable; urgency=high . * When bootlogd gets an error writing to the real console, try to re-open. If that fails, roll over and die (closes: #202382) Why should bootlogd get an error writing to the real console? What's the significance of this? I'm pleased this didn't result from carelessness. Miquel writes on #202382 that he had thoroughly tested it [bootlogd]. It's not worthy of comparison with the 2001 PAM login bug. Regards, Adam
Re: why mplayer not in Debian
Hi A Mennucc1, I had actually asked for help on debian-legal, in [1] http://lists.debian.org/debian-legal/2003/debian-legal-200301/msg00173.html This and the follow-ups you have now received are great. It must be very frustrating when so much time goes by that someone like myself misses all the context of six months ago. Sorry. I have also emailed you my response. If as a Debian developer you are unwilling to subscribe perhaps you could check the archives: http://lists.debian.org/debian-devel/2003/debian-devel-200307/thrd4.html (thanks, I am using that) Or point your news client to nntp://news.gmane.org. thanks, it is quite useful You can also post via this gateway via your news client (as I do). The first time you go to post for each mailing list you will have to respond to an authorisation request, so make sure you use a valid email address when posting. Regards, Adam
Re: Bug#198158: architecture i386 isn't i386 anymore
Hi Arnd Bergmann, On Tuesday 24 June 2003 02:00, Adam Heath wrote: On Tue, 24 Jun 2003, Martin v. Löwis wrote: In g++ 3.2, this code was distributed as i386, and nobody noticed that it doesn't work on i386 for quite some time. In gcc 3.3, an implementation is provided that works on i386, and this implementation here is declared i486. Unfortunately, the two implementations are not binary compatible. Debian has to pick one of these, and it needs to pick the i486 version for compatibility with other Linux distributions (which either ship with gcc 3.2 today, or target i586+ only, anyway). Er, if this function is inlined, then how can it be part of some published api? If it's not part of some published api, then how can using an i386 variation cause problems with other distributions? The API requires that access to atomic variables is truly atomic. The i386 version uses a semaphore to synchronize the access to an atomic variable, the i486+ version uses the lock prefix. When you mix these two in one program, two threads might access the variable without locking against each other because the code inside the semaphore does not lock the memory bus. This has been a very informative discussion. While hesitant about dropping i386 support I am now convinced that: (a) i386 support should be dropped so that binary compatibility can be maintained with other Linux distributions. Debian's binary compatibility is a very important feature, especially as a lot of proprietary Linux software companies provide no official support for Debian. Binary compatibility helps fulfil the social contract where although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. (b) i486+ should be targeted, but GCC-compiled code optimised for either i586 or i686 (consider whichever is also best for P4 and Athlon). Debian has the goal of being a universal distribution and operating system, and even ditching i386 support is chilling enough. Pragmatically, even though i486 desktops are now relatively scarce i486 laptops still make very useful portable routers. (c) Just keep the i386 name. Changing it will break too many scripts when all that is needed to resolve confusion is a release note. i486+ would still be misleading to those who need to understand that even though i486 is supported the binaries are still optimised for a more recent architecture. One day support for i486 will be dropped and then we also won't need to worry about changing the architecture name. I'd appreciate replies to this message to be CCed to my email address. Regards, Adam
Re: dpkg-buildpackage -rfakeroot error
Hi Bart Schuller, sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied chmod +x debian/rules Of course! Thanks Bart and Daniel. The resulting diff of debian/rules to compile in POSIX regular expression support for CLISP is below. 28a29 --with-module=regexp \ Regards, Adam
Re: xfonts-*dpi and reiserfs?
On Mon, 2001-09-10 at 22:01, Sander Smeenk (CistroN Medewerker) wrote: |Sep 10 11:54:05 replicator kernel: reiserfs_add_entry: Congratulations! |we have got hash function screwed up So what kernel are you running Sander? There are data corruption bugs in earlier 2.4 kernels. In fstab are you currently using the notail option? It might be safer. Regards, Adam
wipe WARNING (it will delete parent files and directories!)
Package: wipe (0.16-4) Version: This is wipe version 0.16, Jul 8 2001 by Berke Durak, compiled Jul 8 2001. If you wipe hidden directories using the command: wipe -r .* once it has finished deleting files down the directory tree it will move up to the root of your hard disk while continuing to delete everything (if run as root). The wildcard .* is matched against the parent directories (..) I do not consider this to be safe behaviour. In comparison a rm -f -R .* will only result in: rm: cannot remove `.' or `..' rm: cannot remove `.' or `..' i.e. a rm doesn't touch parent directories and files. Regards, Adam Warner PS: I am extremely fortunate that I only lost program files in /usr :-) I got to it before it took out my data files.
