Re: Sun Java available from non-free
Executive Summary: There are serious issues with clause 2a, 2b, 2c, 2f, and 4; and lesser issues with other bits of this license. As much as some of our users would like to see us distributing this JDK in non-free, I'm really not sure that it can be distributed while complying with the license or without incurring unreasonable burdens upon our mirror operators and Debian. I'd recommend that ftp-masters consider pulling this package from non-free until these issues are resolved (or at least understood.) First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. I'm also going to rip out the bits of the license which I don't feel are particularly useful; this doesn't mean that they don't have problems, only that I haven't seen them in a rapid pass through of the license.[0] As a final note, did anyone from Debian who usually examines licences actually examine this one? [At any time if you're unsure of a license, but don't want to disclose the new terms publicly you should be contacting someone who routinely does this kind of examination so this sort of problem doesn't occur. I'm always willing to help clarify the issues facing Debian in regards to both free and non-free licenses; I assume other contributors to -legal are willing to as well.] 2. License Grant. Subject to the terms and conditions of this Agreement, [...] provided that: (a) the Software and any proprietary legends or notices are complete and unmodified; This seems to cause a problem with actually packaging the software unless the Debian package counts as the Software... this seems to mean that any time that the package should be changed the maintainers need Sun to actually distribute the software to them (or otherwise grant them the ability to modify the software.) (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; non-free is not part of Debian so we definetly don't distribute it as part of the 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; This means that we can't distribute eclispse or anything else which implements part of the Java API (or if you're going to read this clause as broadly as possible,[1] things like perl which implement similar functionality in that perl is an implementation of a cross platform language Perl.) (d) you do not remove or modify any included license agreement or impede or prevent it from displaying and requiring acceptance; We may need to modify debconf preseeding to make sure that the user can't prevent the agreement from being shown... (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. I'm really not entirely sure what this clause is getting at, but it seems that the intention is that Debian needs to indemnify Sun for any litigation resulting by users of the package of Sun's JDK which Debian has distributed, even if Sun is grossly negligent.[2] 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun or a licensee of the Software (under section 4(b)) notifies you that there are compatibility issues [...] caused by the interaction of the Software with your Operating System, then within ninety (90) days you must either: (a) modify the Operating System in a way that resolves the compatibility issue (as determined by Sun) and make a patch or replacement version available [...] Oh, right... so if the Sun JDK is buggy, we have to modify our operating system to make it unbuggy in some way that makes Sun happy. Makes sense to me. 14. MISCELLANEOUS. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. A yeah! Now everyone gets to suffer! It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of
Re: Sun Java available from non-free
Here I was, as a user, happy to read the announcement that the real thing was going into non-free. Then this. Brilliant. This is a stuff-up of Kovco[1] proportions. How can Sun consider a license with those sort of provisions fair? How can the JDK get into the archive before anyone picking up on this? Eagerly awaiting a complete and free JDK so we won't have to put up with this kind of crap, Brendon 1: http://news.google.com.au/news?q=Kovcoie=UTF-8oe=UTF-8 pgptRoi93NPVP.pgp Description: PGP signature
Re: mdadm 2.4.1-1 ready for tests
martin f krafft [EMAIL PROTECTED] wrote: also sprach Simon Huggins [EMAIL PROTECTED] [2006.05.17.1029 -0500]: I know this isn't the sort of feedback you want but these aren't all please ship the new version of mdadm bugs and whilst they might well be fixed by this version I thought consensus was to try to describe what it was about this release that fixes these bugs. Mh. I don't want to (re)start a flamewar, but my take is that changelog.Debian documents changes I've made, and the upstream changelog documents the changes they've made. No need to restart the discussion, because this has already been discussed ad nauseam. The conclusion always was that you should give an explanation to each bug you close. In doubt, the list archives will help... Gruß, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: mdadm 2.4.1-1 ready for tests
also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2006.05.17.2210 -0500]: mdadm is a *critical* part of a system that uses linux software raid. Anything that helps users understand all the important changes an update will imply is always uselful. Of course, but if there weren't any important changes, doesn't it suffice that a bug is just fixed? As in: previously mdadm did that wrongly, and that's fixed. Why should a user care how it was fixed? Also, what you are saying leads me to believe that you would want me to document *all* important changes, whether respective Debian bugs existed or not. NEWS.Debian is clearly a better method for such announcements, but you *should* try to keep the stuff there down to a minimum, IMHO. In any case, I *will* go through the fixed-upstream bugs again to make sure that the fixes do not have implications for users who weren't affected by the bug. Anything that helps a developer easily track down what *exacly* caused a bug to be closed can be very useful, too. I would expect a developer to know to turn to the upstream changelog for such information. Apart, the Debian changelog would be hopelessly long if I had to specify what *exactly* caused a bug to be closed. but adding the main points there is *very* appreciated by many of us. This argument stands. I'll consider it. also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2006.05.17.2217 -0500]: I see debian work as tailoring upstream one so that it best fits our users. Selecting the appropriate information from the upstream changelog that describe how bugs reported in our BTS got closed is part of such tailoring. Yes, but see above. A bug that existed previously which is now fixed is in and of itself appropriate information: the problem now does not exist anymore. Beside that and more practical: why documenting closes: in debian/changelog if the users have no way to understand them? If it is only for automatically closing bugs with the upload there is something wrong with the usage of the instrument. Is there? I am telling the user that his/her bugs were closed by upstream, or have been obsoleted by the new release. So as you can see, I disagree. However, I do understand that mdadm is kind of critical, so I will reconsider and might change the changelog when I upload to unstable. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system http://kirch.net/unix-nt/ signature.asc Description: Digital signature (GPG/PGP)
Re: mdadm 2.4.1-1 ready for tests
I'll add the explanation; it should take less time than restarting the flame war or dealing with the consequences. Sorry, and thanks to Don Armstrong for a patient and convincing explanation. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system you can't assign IP address 127.0.0.1 to the loopback adapter, because it is a reserved address for loopback devices. -- micro$oft windoze xp professional signature.asc Description: Digital signature (GPG/PGP)
Re: Sun Java available from non-free
On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: I'm really disappointed: what's the use of spending time on debian-legal, when the Project seems to ignore us? As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). Maybe the admin who accepted the packages could tell us why he did and why he did in such a timely fashion. I am certainly interested in his reasoning. Michael P.S.: CCing ftpmaster so this admin definitely gets this email and can identify himself. -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Le jeudi 18 mai 2006 à 09:24 +0200, Michael Meskes a écrit : On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: I'm really disappointed: what's the use of spending time on debian-legal, when the Project seems to ignore us? As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). ... while there are packages that have been waiting for a month, holding GNOME 2.14 out of unstable. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: mdadm 2.4.1-1 ready for tests
martin f krafft [EMAIL PROTECTED] wrote: also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2006.05.17.2210 -0500]: mdadm is a *critical* part of a system that uses linux software raid. Anything that helps users understand all the important changes an update will imply is always uselful. Of course, but if there weren't any important changes, doesn't it suffice that a bug is just fixed? As in: previously mdadm did that wrongly, and that's fixed. Why should a user care how it was fixed? You don't even tell him *what* is fixed. Do you know by heart which bugs you reported to package foo, and if you get a notification that bug #219876 was finally closed, you still know whether this was an important issue or just a patch for a typo in the man page? I would expect a developer to know to turn to the upstream changelog for such information. Apart, the Debian changelog would be hopelessly long if I had to specify what *exactly* caused a bug to be closed. Since teTeX 3.0 was released really a long time after the 2.0.2, we also had this problem. In this case, I closed the bugs with this remark: , | * Lots of bugs are closed by this upload - all bugs listed below have | already been tagged fixed-upstream, and there should be an explanation | in the bug logs at http://bugs.debian.org/bugnumber. In some cases | the explanation is only a link to the LaTeX Project bug database, or | it is in the comments of the mail sent to the control server, but it's | always there. | | - For tetex-base: (closes: #221262, #261529, #272560, #119531, | #267768, #195711, #181310, #206315, #230931, #258976, #145339, | #190873, #214415, #255137, #181310, #219573, #229598, #286722) | | - For tetex-extra: (closes: #273246, #218178, #195109, #215925, | #251143, #202472, #259696, #261736, #271463, #273247) | | - For tetex-doc: (closes: #160692, #223569, #153985) ` Yes, but see above. A bug that existed previously which is now fixed is in and of itself appropriate information: the problem now does not exist anymore. Which problem? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Sun Java available from non-free
Le Jeu 18 Mai 2006 09:28, Josselin Mouette a écrit : Le jeudi 18 mai 2006 à 09:24 +0200, Michael Meskes a écrit : On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: I'm really disappointed: what's the use of spending time on debian-legal, when the Project seems to ignore us? As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). ... while there are packages that have been waiting for a month, holding GNOME 2.14 out of unstable. well, you're not alone, there is 217 source packages in NEW, most of them for more than 2 weeks, not to mention the ones that have been uploaded many times which hides the fact that they rot there since ages. NEW has worked for something like 6 monthes pretty well, maybe 8, and is stuck again. I'm still thinking that NEW for packages that already are in the archive is totally inefficient. at the least, NEW should be split into real NEW uploads (source packages that never wer ein the archive) and another queue for the packages that just have a new binary package. that queue should be treated really faster, it's often a big block for teams that see their upload schedule completely stuck because of the slowness of NEW processing. This produces irritation and frustration, and is of no good for the project. Oh and as we are speaking of NEW, I also think that most of the refusal for tiny problems (in tiny I mean that they need a couple of seconds to fix, like one forgotten file in a debian/copyright ...) should be accepted instead, with an RC open bug. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8WXZFEe3y4.pgp Description: PGP signature
Re: multiarch status update
#include hallo.h * Goswin von Brederlow [Tue, May 16 2006, 11:55:18PM]: What do you mean with invasive? Multiarch is designed to be implemented without disrupting the existing archive or mono-arch systems at any time. Each package can get converted to multiarch by itself and once a substantial number of packages have done so a multiarch dpkg/apt/aptitude can be used. And that is why I question it. Do we need that? You demonstrated that it is quite easy to setup the depencency chain for a package... but why should we care about change the whole distribution for the sake of few 3rd party packages if we have sufficient workarounds? But cooking the packages is not 100% successfull and involves a lot of diversions and alternatives. Every include file gets diverted, every binary in a library gets an alternative. All cooked packages depend on their uncooked other architecture version for pre/postinst/rm scripts, forcing both arch to be installed even if only the cooked one is needed. I don't see a bad problem with that, sounds like an acceptable compromise. And still some things won't work without the multiarch dirs being used by any software using dlopen and similar. That includes X locales, gtk-pixmap, pango to start with. Such things are not okay but there could be few workarounds as well. It works for a stable release but for unstable the constant stream of changes needed in the cooking script would be very disruptive for users. Only if you port the whole distribution. If you port few dozens of library packages, maintaining them should be feasible. It also is disruptive to building packages. Build-Depends will only work for the native arch and not for the cooked packages and building for the cooked arch will give precooked Depends (I do cook shlibs files) so they are invalid for uploads. This problem is only implied by porting the whole arch and using everything like a native package. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Thursday 18 May 2006 09:28, Josselin Mouette wrote: On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). Could have something to do with the fact that all involved persons were at Debconf and could effectively communicate together... Could also have something to do with the high visibility of this upload and the fact that parties involved would like to announce the availability of Sun Java in Debian... ... while there are packages that have been waiting for a month, holding GNOME 2.14 out of unstable. Could have something to do with the person normally doing NEW processing having a rather important role in the organization of Debconf leaving him no time to do his regular NEW processing... Be glad that NEW processing in general is so much improved over the last year and allow for special circumstances at some times. If you really have urgent reasons to get a package into new, the best action is probably to send a mail to debian-release and to present these reasons. Cheers, FJP pgppah8lqfMrt.pgp Description: PGP signature
Re: multiarch status update
On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Have you considered employing the alternatives system (or something similar)? What I'm suggesting is that you'd basically get a /bin64 and a /bin32, where binaries install themselves in /bin by default but divert to the /binXX when both versions are installed, and use symlinks in an update-alternatives way to select the default. Each package that deems it neccessary can choose to do so. That's not what I meant, really. I imagine the count to be near 0. Certainly nothing dpkg should handle automagicaly for all debs. Why not? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, May 18, 2006 at 03:23:44AM +0200, Goswin von Brederlow wrote: But there will be times where the actual source version of debs for each arch differs. Actualy at every upgarde that happens between arch1 getting unpacked and arch2 getting unpacked as well. Dpkg just has to handle it in some sane way. dpkg could just unconfigure (or even remove) all other arches before upgrading arch1, and allow configuring a new arch only if the version number (except for the binNMU component) is identical to the alread-configured arch. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ 4.1 transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Koch a écrit : The Debian Java Team wants to switch the default version gcj/gij to point to the according 4.1 version. Hi Michael, Who is the Debian Java Team? I did not see a mail about this decision. I thought I was a small part of the Debian Java Team... Cheers, PS: Don't missunderstand me, I'm of course ok with the GCJ4.1 transition, but I'm surprise you talked for the Debian Java Team but without coordination (of course I'm not the leader of DJT but I thought I did enough to be considered a part of the DJT. - -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEa7SN4vzFZu62tMIRAmfFAKChs5q2MusoeWLcXsKQmtdROPMCBQCeIOAE SlwKwulIMFLLFoB9x2NK+CQ= =ZbD7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Hello, On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson [EMAIL PROTECTED] wrote: [ udev being, umm, not very nice ] Need I say more? yes: Please say *why* newer 2.6.x kernels actually do depend on udev instead of hotplug. Thank you! Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Wednesday 17 May 2006 23:08, Roberto C. Sanchez wrote: Lionel Elie Mamane wrote: On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh wrote: An open outgoing port 25 is commonly blocked by default anywhere you have non-incompetent network management, unless you are on the business of selling full internet uplinks for server hosting, or you do business with spammers. Or unless you want ... customers. Except that most customers don't know what a port is, nor much less care that any are blocked (unless it prevents them from playing everquest or chatting). Most people don't run their own mail servers and can easily be convinced by the ISP to use a mail client like Lookout, which is pointed at the ISP's outbound mail server. Personally, I think it is a responsible thing for mass market ISPs to do. comment mode=SCNR recommending the most virus-infected piece of mail-software around is a responsible thing to do? comment -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpF2qwrwqQfv.pgp Description: PGP signature
Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Thu, 18 May 2006, Goswin von Brederlow wrote: No, you sounded like you wanted to enforce the installation of an MTA on every system and only support that (since all systems would have one why bother with anything else?). Drop the only and change that to by default always, and you will have what I proposed... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Am Donnerstag 18 Mai 2006 11:25 schrieb Toni Mueller: Hello, On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson [EMAIL PROTECTED] wrote: [ udev being, umm, not very nice ] Need I say more? yes: Please say *why* newer 2.6.x kernels actually do depend on udev instead of hotplug. Thank you! Best, --Toni++ Since hotplug's deprecation, udev has taken on the role of coldplugger, hotplugger. Maybe thats the reason. Greets -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mdadm 2.4.1-1 ready for tests
On Thu, 18 May 2006, martin f krafft wrote: Also, what you are saying leads me to believe that you would want me to document *all* important changes, whether respective Debian bugs existed or not. NEWS.Debian is clearly a better method for such Many important changes do not modify the intended behaviour of the program, nor do they require external action of the user for things ot keep working right. Those I never list on NEWS.Debian in my packages. OTOH, if it *does* change behaviour in an important way (whatever I deem to be important, or whatever I find out others considered important through feedback), or if it requires the user to take some action to keep things working smoothly, it is NEWS.Debian material IMHO. announcements, but you *should* try to keep the stuff there down to a minimum, IMHO. Agreed. but adding the main points there is *very* appreciated by many of us. This argument stands. I'll consider it. Thanks. As you said, this is *not* a big deal, it is exactly that, just a request. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Section of -dev packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17 May 2006, at 10:46 pm, Roberto C. Sanchez wrote: I found this more instructive: $ apt-cache search -n .\*-dev\$ | sed 's/ -.*//' | xargs apt-cache show | grep \^Section: | sort | uniq -c 1 Section: admin 1 Section: comm 3 Section: contrib/libdevel 256 Section: devel 5 Section: doc 1 Section: electronics 1 Section: games 3 Section: gnome 3 Section: graphics 6 Section: interpreters 3 Section: kde 1379 Section: libdevel ... etc In other words, on a Sarge system (with backports), over 93% of the packages (the total is 1757) report themselves as being in devel or libdevel. On the whole, I would say that is pretty good. Playing devil's advocate for a moment: I would have said there is sometimes an argument for a development package not being in devel, but rather being in the same section as its 'parent' program; one could think of devel and libdevel as being for general purpose programming tools and libraries. There could be examples where the development files are only really relevant in some extremely specialised context (for example some scientific application or other) and cluttering up the devel and libdevel sections with them just adds noise to those sections. I'm not saying I actually agree with this, but I can see an argument for it. A case in point might be libamu4-dev, a package for which I am the maintainer. This contains development files for libamu4, the core libraries of the BSD automounter. It is in libdevel, as you'd expect. I find it hard to believe that anyone actually uses these (I don't have any practical need for them, and I'm the package maintainer!) - they're there in case people want to, but I suspect it's a package needed or wanted by a vanishingly small number of people, and it certainly doesn't count as a general purpose programming library. Does it really need to be staring people in the face in the libdevel section? Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQEVAwUBRGxoBhypeFo2odvPAQIhpgf/XdDs0nRNAKrPOXpGTxSfRtqLsXzIQwPV bZPfNoeW0JcURqngfmmkb2Kv0ClEovsQ8qjEupzhYx6avX09iTmIKHvXQgZ7bckk Ve3wOgYZEHMpZOhmXyRe5SKNGXXoZqEZ8Wd4/Nl+twQlkrRXedPPO7NYXKkRgpVY T75+3PE5wrXgLafAuTGIIYthPiP4iLE8fwXBVP1qhG+jndvWoIbXe5wpQgsO5AmT 6ENlmFt7NULZsOJYlM4sP0YQHZR6lureP7dj0QNvp7dLdii9WBSH3byMsVAQAGbv j85D8Tf/SIfO4atmq1Eb4tpbPzOucvsuJM4VBFdzLNPWPu/eiNNGpQ== =FrSj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Thu, 2006-05-18 at 04:55 +0200, Jeroen van Wolffelaar wrote: On Wed, May 17, 2006 at 03:16:35PM -0500, Ron Johnson wrote: Ignorance, fear of becoming an open relay and years of learning will have to be overcome before Most Users will config Debian to use a relayhost. It's not very difficult to have exim, the default MTA, simply not launch an smtp listener. If it's only running queues and providing the /usr/sbin/sendmail interface, you cannot possibly be a mail relay, since nothing even listens on port 25. The configuration file to edit for this is /etc/default/exim4 Would that prevent local email? Or would you then say, only listen on localhost? -- - Ron Johnson, Jr. Jefferson, LA USA People like to call themselves social liberal fiscal conservative. Unfortunately, these 2 are diametrically opposed, since the social liberal wants more government help, and the fiscal conservative wants smaller government. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not making /sbin/sendmail a mantadory component for mail operation?
On Thu, 2006-05-18 at 13:11 +0200, cobaco (aka Bart Cornelis) wrote: chatting). Most people don't run their own mail servers and can easily be convinced by the ISP to use a mail client like Lookout, which is pointed at the ISP's outbound mail server. Personally, I think it is a responsible thing for mass market ISPs to do. comment mode=SCNR recommending the most virus-infected piece of mail-software around is a responsible thing to do? comment Responsible? No. But then neither is Windows, and that doesn't stop 90+% of people from using it. -- - Ron Johnson, Jr. Jefferson, LA USA this is how main street of town looked back in 1985 when I was of age of those girls http://www.angelfire.com/extreme4/kiddofspeed/page11.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, 2006-05-17 at 23:09 -0700, Don Armstrong wrote: [snip] (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; This means that we can't distribute eclispse or anything else which implements part of the Java API (or if you're going to read this clause as broadly as possible,[1] things like perl which implement similar functionality in that perl is an implementation of a cross platform language Perl.) I guess it hinges on the definition of in conjunction. I read this clause as meaning that you can't create a hybrid that uses the Sun javac with gjc jars. [snip] -- - Ron Johnson, Jr. Jefferson, LA USA Welfare Democracies will only work, in the long term, if the recipients of the wealth given to them by the earners use that wealth to become earners themselves. Unfortunately, only a small % of recipients seem to be availing themselves of the opportunity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367835: ITP: fetch-exc -- Fetches email from Microsoft Exchange servers
Package: wnpp Severity: wishlist Owner: Ted Percival [EMAIL PROTECTED] * Package name: fetch-exc Version : 1.0.0 Upstream Author : Juhani Rautiainen jrauti(at)iki.fi * URL : http://personal.inet.fi/atk/fetchexc/ * License : GPL Programming Lang: Java Description : Fetches email from Microsoft Exchange servers FetchExc retrieves emails using WebDAV (Outlook Web Access) and delivers it to an SMTP server or local mbox store. (I have obfuscated the upstream author's email address out of politenessbecause it is obfuscated on the project info page.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Le jeudi 18 mai 2006 à 10:09 +0200, Frans Pop a écrit : If you really have urgent reasons to get a package into new, the best action is probably to send a mail to debian-release and to present these reasons. I know that. However there's nothing that I could call urgent in GNOME 2.14. It's just that it's not in unstable and users don't understand why. If the situation holds on, we will have to review our plans for GNOME 2.16. It will be impossible to push it in etch if NEW takes as much time as for 2.14. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Conary is a distributed software management system for Linux distributions
Interesting. apt already provides some of the features of Conary but not all and Conary or a Conary-like system may help Debian-based distributions or local customizations. Conary is a package management system, based on concepts similar to those of the distributed Version Control Systems like darcs or mercurial. http://wiki.conary.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On 5/18/06, Frans Pop [EMAIL PROTECTED] wrote: On Thursday 18 May 2006 09:28, Josselin Mouette wrote: On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). Could have something to do with the fact that all involved persons were at So again the question is, why do we have to guess? Debconf and could effectively communicate together... Could also have something to do with the high visibility of this upload and the fact that parties involved would like to announce the availability of Sun Java in Debian... ... while there are packages that have been waiting for a month, holding GNOME 2.14 out of unstable. Could have something to do with the person normally doing NEW processing having a rather important role in the organization of Debconf leaving him no time to do his regular NEW processing... And again, why is there only one person?
Re: debian and UDEV
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote: What timeout? With feedback you would know exactly when it is done and wouldn't have to poll. Quoting Linus: : It really is very hard to accept the blocking behaviour. : : Some things can take a _loong_ time to be ready, including even : requiring user intervention. And even when scanning takes only a few : seconds, if there are multiple modules, you really want to scan things : in parallel. : : Not finding a disk is often a matter of timing out - not all buses : even have any real enumeration capability, and enumeration literally : ends up being try these addresses, and if nothing answers in 500 : msec, assume it's empty. : : Now, 500 msec may not sound very bad, but it all adds up. I get : unhappy if my bootup is a minute. I'd prefer booting up in a couple of : seconds. : : Also, how ready do you want things to be? Do you want to know the : device is there (disk at physical location X exists), or do you want : to have read the UUID off the disk and partitioned it? The latter is : what is needed for a mount, but it's often a _lot_ more expensive than : just knowing the disk is there, and it's not even necessarily needed : in many circumstances. So you can _not_ prevent polling. With some SCSI setups it literally takes minutes till all devices power up and answer to the inquiry command. If you happen to have several SCSI buses those latencies do add up pretty quickly. And not just SCSI: Linus: : For example, any USB host driver will always discover its devices : asynchronously, and has no dependency on CONFIG_HOTPLUG. It can take : several seconds for all the hubs to have powered up and discovered : what is behind them. Greg K-H: : And as others have pointed out, for a lot of busses, we just don't : know how long the device is going to take to be found. For one of my : boxes with a flaky USB controller, it takes _minutes_ for devices to : be detected (yes, it is broken hardware, but the rest of the system : works just fine while it is off and trying to be detected.) Scan the USB bus, find all devices on it, run all udev scripts for them, return. Greg K-H: : Another point is that some busses just don't know when all the devices : on it are found, as there is no such state. USB is one such bus, and : I imagine firewire is another one. So there is no real way for us to : delay at insmod time for all devices to be found. Just like the kernel always did prior to udev. You're missing a very important thing. This is _NOT_ a udev vs. pre-udev question. This is a new kernel hotplug behavior vs. old kernel hotplug behavior question. The fact is that the kernel behavior changed fundamentally in the early 2.6.x series compared to 2.4.x, and userspace did not follow that change ever since. udev simply exposes how the kernel really works. Not using udev solves NOTHING since it's not udev that is broken: it is the general userspace assumption about how the kernel works what is broken. I think it is pointless to bitch about udev without a clean proposal how should Debian handle hotplug events (including cases like when the device containing the root file system is literally plugged in _after_ the kernel/initrd has been loaded). That is a different matter. That never ever worked by itself and udev doesn't change anything there. Not different at _all_. As far as the kernel is concerned this is how it actually works right now. If you look at the initrd generators, they add delays and retries when mounting the root file system because the kernel does _not_ make any difference between delaying the discovery of an already-plugged-in device and physically plugging in the device later. In fact, if you have hotplug capable hardware, you could just connect the root device when you see the waiting for the root file system to appear (or similar) message and it would quite likely Just Work. But for already plugged in devices the device node was always ready when the insmod was done. And that has changed. And udev has _nothing_ to do with it apart from making that change more visible. Even with devfs. No. The confusion comes from the fact that when devfs was still maintained, the kernel still used the old device discovery scheme. If devfs had not been obsoloted it would have _exactly_ the same problems as udev because it used/uses the same internal in-kernel event notification mechanisms and data structures as udev. devfs may be somewhat faster than udev and therefore the time window between insmod returning and the device node appearing might be a bit smaller, but it would still be there and with a fast enough processor you'd hit it just as well you hit it with udev. For all cases where you load a module to activate a certain device (disk for initrd, mouse for X, ...) this is a serious step back. No, it's just the visible effect for the kernel slowly becoming fully hotplug-ready. It's just userspace that's
Re: Section of -dev packages
Goswin von Brederlow wrote: Kevin B. McCarty [EMAIL PROTECTED] writes: In case anyone is interested in filing mass bug reports (I am not sufficiently interested, sorry), here are the -dev packages in unexpected sections, obtained as follows: grep-aptavail -r -P '.*-dev$' -s Section,Package | paste -sd ' \n' | \ egrep -v '^Section: (|contrib/|non-free/)(doc|python|(lib|)devel)' | \ cut -d ' ' -f 4 | sort I excluded packages in libdevel,devel,python,doc from the list since: Exclude oldlibs too. Sure, here is the list with oldlibs excluded also. Note that there may also be a few non-i386 packages that I missed. (Scroll down for the list of source packages by maintainer.) Anyone intending to file bugs may want to go through the list in more detail - for instance a convincing argument could be made that kdevelop3-dev really does belong in section kde. (And I already switched the section of cernlib-core-dev from science to devel in my local copy to be uploaded in the next few days, so no need to chastise me :-) aleph-dev beagle-dev cernlib-core-dev cimg-dev cli-common-dev courier-authlib-dev dpkg-dev gmpc-dev gnome-applets-dev irssi-dev jsvc-dev k3d-dev kaffe-dev kdeutils-dev kdevelop3-dev konwert-dev libapr1.0-dev libapreq2-dev libaprutil1.0-dev libcdg123-dev libdb4.2-java-dev libdb4.3-java-dev libdb4.4-java-dev libdspam7-dev libfontenc-dev libghc6-plugins-dev libghc6-pugs-dev libgl1-mesa-directfb-dev libgnokii2-dev libgnome-media-dev libicee-dev libkexi-dev libmodplug-dev libmodxslt0-dev libmpd-dev libnautilus-burn-dev libnmz7-dev libnws-dev libqcad0-dev libqgis0-dev libqglviewer-dev libstk0-dev libverbiste0-dev libvncserver-dev libxfont-dev libxmpp4r-ruby1.8-dev ltp-dev madwifi-dev med-bio-dev med-imaging-dev mnogosearch-dev mozilla-thunderbird-dev nut-dev nvidia-glx-dev nvidia-glx-legacy-dev perdition-dev pike7.6-dev pinball-dev planetpenguin-racer-gimp-dev playground-dev plplot-tcl-dev rsbac-dev supercollider-dev swish-e-dev thunderbird-dev vdr-dev x11proto-bigreqs-dev x11proto-composite-dev x11proto-core-dev x11proto-damage-dev x11proto-dmx-dev x11proto-evie-dev x11proto-fixes-dev x11proto-fontcache-dev x11proto-fonts-dev x11proto-gl-dev x11proto-input-dev x11proto-kb-dev x11proto-print-dev x11proto-randr-dev x11proto-record-dev x11proto-render-dev x11proto-resource-dev x11proto-scrnsaver-dev x11proto-trap-dev x11proto-video-dev x11proto-xcmisc-dev x11proto-xext-dev x11proto-xf86bigfont-dev x11proto-xf86dga-dev x11proto-xf86dri-dev x11proto-xf86misc-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev xorg-dev xserver-xorg-dev xtrans-dev xutils-dev Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] stk Stefan Hornburg (Racke) [EMAIL PROTECTED] courier-authlib Sebastien Bacher [EMAIL PROTECTED] verbiste Paul Brossier [EMAIL PROTECTED] supercollider Ross Burton [EMAIL PROTECTED] nautilus-cd-burner Javier Carranza [EMAIL PROTECTED] qcad Debian Apache Maintainers debian-apache@lists.debian.org apr-util1.0 apr1.0 Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org kdeutils Debian X Strike Force debian-x@lists.debian.org libfontenc libxfont x11proto-bigreqs x11proto-composite x11proto-core x11proto-damage x11proto-dmx x11proto-evie x11proto-fixes x11proto-fontcache x11proto-fonts x11proto-gl x11proto-input x11proto-kb x11proto-randr x11proto-record x11proto-render x11proto-resource x11proto-scrnsaver x11proto-trap x11proto-video x11proto-xcmisc x11proto-xext x11proto-xf86bigfont x11proto-xf86dga x11proto-xf86dri x11proto-xf86misc x11proto-xf86vidmode x11proto-xinerama xorg xorg-server xtrans xutils-dev Dpkg Developers [EMAIL PROTECTED] dpkg Yann Dirson [EMAIL PROTECTED] konwert Randall Donald [EMAIL PROTECTED] nvidia-graphics-drivers nvidia-graphics-drivers-legacy Ludovic Drolez [EMAIL PROTECTED] libvncserver swish-e Jochen Friedrich [EMAIL PROTECTED] pinball David Moreno Garza [EMAIL PROTECTED] playground Jan-Marek Glogowski [EMAIL PROTECTED] libcdg123 Debian Mono Group [EMAIL PROTECTED] cli-common Debian QA Group [EMAIL PROTECTED] kexi Steinar H. Gunderson [EMAIL PROTECTED] libapreq2 Marek Habersack [EMAIL PROTECTED] pike7.6 Steve Halasz [EMAIL PROTECTED] qgis Johannes Hirche [EMAIL PROTECTED] qglviewer Simon Horman [EMAIL PROTECTED] perdition Philipp Hug [EMAIL PROTECTED] mnogosearch Norman Jordan [EMAIL PROTECTED] kdevelop3 Rafael Laboissiere [EMAIL PROTECTED] plplot Debian Berkeley DB Maintainers [EMAIL PROTECTED] db4.2 db4.3 db4.4 Debian DSPAM Maintainers [EMAIL PROTECTED] dspam Debian Java Maintainers pkg-java-maintainers@lists.alioth.debian.org commons-daemon kaffe Bradley Marshall [EMAIL PROTECTED] gnokii Kevin B. McCarty [EMAIL PROTECTED] cernlib Alastair McKinstry [EMAIL PROTECTED] ltp David Martínez Moreno [EMAIL PROTECTED] k3d
Re: Sun Java available from non-free
On Thu, 2006-05-18 at 16:02 +0200, Olaf van der Spek wrote: On 5/18/06, Frans Pop [EMAIL PROTECTED] wrote: On Thursday 18 May 2006 09:28, Josselin Mouette wrote: On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). Could have something to do with the fact that all involved persons were at So again the question is, why do we have to guess? This thread started yesterday. Is there some new policy where each and every question posted on a list needs to be fully answered within 24h now? Thijs signature.asc Description: This is a digitally signed message part
Re: Sun Java available from non-free
On 5/18/06, Thijs Kinkhorst [EMAIL PROTECTED] wrote: On Thu, 2006-05-18 at 16:02 +0200, Olaf van der Spek wrote: On 5/18/06, Frans Pop [EMAIL PROTECTED] wrote: On Thursday 18 May 2006 09:28, Josselin Mouette wrote: On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote: As far as I can tell the packages were accepted from NEW in a very short time frame (~ 5hours). Could have something to do with the fact that all involved persons were at So again the question is, why do we have to guess? This thread started yesterday. Is there some new policy where each and every question posted on a list needs to be fully answered within 24h now? Not that I'm aware of. But the decision (and argumentation) could've been public to begin with.
Re: debian and UDEV
On Thu, May 18, 2006 at 11:25:46AM +0200, Toni Mueller wrote: yes: Please say *why* newer 2.6.x kernels actually do depend on udev instead of hotplug. 1. They do not depend on it at all. 2.6.x kernels work just fine with a static /dev as long as you don't need dynamic device creation. There are no Depends: udev, nor even Recommends: udev or Suggests: udev in the kernel packages. 2. If you look at the upstream maintainers, you will find the same name in hotplug and udev. Greg K-H created udev to overcome the limitations of hotplug, and when it got ready, he abandoned hotplug. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote: On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote: Just like the kernel always did prior to udev. You're missing a very important thing. This is _NOT_ a udev vs. pre-udev question. This is a new kernel hotplug behavior vs. old kernel hotplug behavior question. The fact is that the kernel behavior changed fundamentally in the early 2.6.x series compared to 2.4.x, and userspace did not follow that change ever since. udev simply exposes how the kernel really works. Not using udev solves NOTHING since it's not udev that is broken: it is the general userspace assumption about how the kernel works what is broken. This is pure crap. Install udev on my system - things break randomly and unreproducibly, due to race conditions all over the place. Install hotplug on my system, and make sure udev is not installed - things Just Work(TM). -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Wouter Verhelst [EMAIL PROTECTED] writes: On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Have you considered employing the alternatives system (or something similar)? What I'm suggesting is that you'd basically get a /bin64 and a /bin32, where binaries install themselves in /bin by default but divert to the /binXX when both versions are installed, and use symlinks in an update-alternatives way to select the default. Each package that deems it neccessary can choose to do so. That's not what I meant, really. I imagine the count to be near 0. Certainly nothing dpkg should handle automagicaly for all debs. Why not? Extra complexity with extra risk of breaking for no practical gain. Also don't forget that you can have more than 2 archs but dpkg can't have more than 2 diversions. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Gabor Gombas [EMAIL PROTECTED] writes: On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote: What timeout? With feedback you would know exactly when it is done and wouldn't have to poll. Quoting Linus: : It really is very hard to accept the blocking behaviour. : : Some things can take a _loong_ time to be ready, including even : requiring user intervention. And even when scanning takes only a few : seconds, if there are multiple modules, you really want to scan things : in parallel. : : Not finding a disk is often a matter of timing out - not all buses : even have any real enumeration capability, and enumeration literally : ends up being try these addresses, and if nothing answers in 500 : msec, assume it's empty. : : Now, 500 msec may not sound very bad, but it all adds up. I get : unhappy if my bootup is a minute. I'd prefer booting up in a couple of : seconds. : : Also, how ready do you want things to be? Do you want to know the : device is there (disk at physical location X exists), or do you want : to have read the UUID off the disk and partitioned it? The latter is : what is needed for a mount, but it's often a _lot_ more expensive than : just knowing the disk is there, and it's not even necessarily needed : in many circumstances. So you can _not_ prevent polling. With some SCSI setups it literally takes minutes till all devices power up and answer to the inquiry command. If you happen to have several SCSI buses those latencies do add up pretty quickly. Yes it does. But then it works all the time. Now the system randomly doesn't boot and instead of a 10 minute boot time you have a 3 hour drive to reset the system and analyse that is was just udev screwing you over. And not just SCSI: Linus: : For example, any USB host driver will always discover its devices : asynchronously, and has no dependency on CONFIG_HOTPLUG. It can take : several seconds for all the hubs to have powered up and discovered : what is behind them. Greg K-H: : And as others have pointed out, for a lot of busses, we just don't : know how long the device is going to take to be found. For one of my : boxes with a flaky USB controller, it takes _minutes_ for devices to : be detected (yes, it is broken hardware, but the rest of the system ^^ : works just fine while it is off and trying to be detected.) USB seems to be pretty broken by design. But most hardware is not. Even scsi, while taking some time to scan the bus, will finish in a reasonable time. Scan the USB bus, find all devices on it, run all udev scripts for them, return. Greg K-H: : Another point is that some busses just don't know when all the devices : on it are found, as there is no such state. USB is one such bus, and : I imagine firewire is another one. So there is no real way for us to : delay at insmod time for all devices to be found. Just like the kernel always did prior to udev. You're missing a very important thing. This is _NOT_ a udev vs. pre-udev question. This is a new kernel hotplug behavior vs. old kernel hotplug behavior question. The fact is that the kernel behavior changed fundamentally in the early 2.6.x series compared to 2.4.x, and userspace did not follow that change ever since. udev simply exposes how the kernel really works. Not using udev solves NOTHING since it's not udev that is broken: it is the general userspace assumption about how the kernel works what is broken. Yes, it is a problem with the kernels hotplug implementation. Hotplug and udev are just linked together. I'm not blaming the userspace part (udev) but the kernel part (hotplug). I think it is pointless to bitch about udev without a clean proposal how should Debian handle hotplug events (including cases like when the device containing the root file system is literally plugged in _after_ the kernel/initrd has been loaded). That is a different matter. That never ever worked by itself and udev doesn't change anything there. Not different at _all_. As far as the kernel is concerned this is how it actually works right now. If you look at the initrd generators, they add delays and retries when mounting the root file system because the kernel does _not_ make any difference between delaying the discovery of an already-plugged-in device and physically plugging in the device later. In fact, if you have hotplug capable hardware, you could just connect the root device when you see the waiting for the root file system to appear (or similar) message and it would quite likely Just Work. But for already plugged in devices the device node was always ready when the insmod was done. And that has changed. And udev has _nothing_ to do with it apart from making that change more visible. And that is what I consider broken. I know it is not going to change but I pain for all the users (and myself) that will (and already have been) get hit by
Re: debian and UDEV
Toni Mueller [EMAIL PROTECTED] writes: Hello, On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson [EMAIL PROTECTED] wrote: [ udev being, umm, not very nice ] Need I say more? yes: Please say *why* newer 2.6.x kernels actually do depend on udev instead of hotplug. Thank you! Udev has just swallowed hotplug functionality making it obsolete. Nothing relay changed there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Section of -dev packages
Tim Cutts [EMAIL PROTECTED] writes: Playing devil's advocate for a moment: While we are at it why not remove sections alltogether? We have the debtags system that by far superseeds the sections and since the pool structure is used sections have been quite useless. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Have you considered employing the alternatives system (or something similar)? What I'm suggesting is that you'd basically get a /bin64 and a /bin32, where binaries install themselves in /bin by default but divert to the /binXX when both versions are installed, and use symlinks in an update-alternatives way to select the default. Each package that deems it neccessary can choose to do so. That's not what I meant, really. I imagine the count to be near 0. Certainly nothing dpkg should handle automagicaly for all debs. Why not? Extra complexity with extra risk of breaking for no practical gain. That could technically be said about all of multiarch... Also don't forget that you can have more than 2 archs but dpkg can't have more than 2 diversions. Err, okay. I guess I shouldn't have mentioned alternatives, because that clearly confused you. What I meant to say is that you could have dpkg set up things so that if multiarch is in effect, files would be installed in /multiarch/i386/bin rather than in /bin (or some such), and that symlinks would be made to /bin so that the entire process would be transparent to a package. Alternatively, you could also set it up so that files would be installed in /bin by default, but then moved to /multiarch if the same package, but compiled for a different architecture, would be installed. Next, you would create some program to manage those symlinks. If you prefer to run firefox in 32bit mode by default, you could say update-multiarch --config firefox i386, and it would move symlinks around so that /usr/bin/firefox, and all files from that package with it, refer to the i386 version of firefox rather than the amd64 version, or the ia64 one, or what have you. I mentioned the alternatives system because it already exists and it does something similar to what I'm proposing; not because I'm proposing you use exactly that to fix these issues. The whole point really is why not use symlinks? and We've already fixed a similar problem with symlinks, not use the alternatives system. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 04:50:44PM +0200, Wouter Verhelst wrote: Install udev on my system - things break randomly and unreproducibly, due to race conditions all over the place. This is quite in line with what I said about userspace not being ready for hotplug. The kernel can send the events in parallel (or nearly parallel on UP) and udev executes the events also in parallel. If the programs udev calls don't do the neccessary locking - fix them. Install hotplug on my system, and make sure udev is not installed - things Just Work(TM). That does not prove that the same race conditions do not exist. It only proves that the (quite noticable) overhead of forking a new shell for every event changes the timing so they are less likely to be hit, thus just papering over the bugs. Actually, if you look at the hotplug .agent scripts you may find artificial sleeps in some of them that's just seem to paper over the race conditions you're talking about... What happens if you add the same delays to the udev rules? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
solicitation for DevRef suggestions for usertags users (Re: Bug#367876: developers-reference: please recommend usertags for mass bug filing)
On Thu, May 18, 2006 at 08:36:05AM +0900, Osamu Aoki wrote: On Thu, May 18, 2006 at 11:01:52AM -0400, Justin Pryzby wrote: Package: developers-reference Version: 3.3.7 Severity: wishlist IMO it is a best-practice to set usertags when filing lots of bugs for a given problem, Good idea. preferably to a publically-known user such as [EMAIL PROTECTED] This choice of e-mail address is debatable depending on what was the problem. Thus please get consensus how it should be chosen and what will be the choice of e-mail adress for each types of reasons on [EMAIL PROTECTED] Please move discussion there and give us final result as a patch :-) What usertags users are in common use? I think everyone will agree that public usernames should be used whenever there is some common interest, for transparency, rather than random groups people all tweaking their own individual bug collections. Please Cc: me, not subscribed Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Section of -dev packages
Re: Kevin B. McCarty 2006-05-17 [EMAIL PROTECTED] In case anyone is interested in filing mass bug reports (I am not sufficiently interested, sorry), here are the -dev packages in unexpected sections, obtained as follows: Isn't that more a matter of updating the override files? Christoph signature.asc Description: Digital signature
Re: debian and UDEV
On May 18, Gabor Gombas [EMAIL PROTECTED] wrote: Actually, if you look at the hotplug .agent scripts you may find artificial sleeps in some of them that's just seem to paper over the race conditions you're talking about... What happens if you add the same delays to the udev rules? RUN rules do not need delays, they are guaranteed to not be run until the device node is available. -- ciao, Marco signature.asc Description: Digital signature
Bug#367893: ITP: digitools -- A set of tools to control ASUS Digimatrix embedded hardware
Package: wnpp Severity: wishlist Owner: Cyril Lacoux [EMAIL PROTECTED] * Package name: digitools Version : 1.0 Upstream Author : Andrew Calkin [EMAIL PROTECTED], Richard Taylor [EMAIL PROTECTED], Ben Potter [EMAIL PROTECTED] * URL : http://members.iinet.net.au/~mcalkin/ * License : GPL Description : A set of tools to control ASUS Digimatrix embedded hardware This package is a combination of the previous programs asusfan and setpanel. Included in this package are the following tools: digifan: allows fan speed control (formerly asusfan) digipanel: allows control of the LED display, and volume knob controls the soundcard master mixer channel (formerly part of setpanel) digiradio: allows control of the in-built radio (formerly part of setpanel) digiwake: allows for Wake-On-CIR (wake on remote) with existing versions of LIRC that support the digimatrix. This program just needs to be run after lircd, and the digimatrix will power on when pressing the music/(on/off) button on the remote control. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 05:01:53PM +0200, Goswin von Brederlow wrote: Now the system randomly doesn't boot and instead of a 10 minute boot time you have a 3 hour drive to reset the system and analyse that is was just udev screwing you over. Then introduce a timeout. Create /etc/default/wait_for_device_timeout and make it a policy that everyone must obey it. USB seems to be pretty broken by design. But most hardware is not. But normal users _do_ use broken hw, and they often has no choice. With the current kernel solution, broken hw presents a much smaller problem than it would with synchronous discovery. Even scsi, while taking some time to scan the bus, will finish in a reasonable time. But I don't want to wait for that. Users are unhappy because Linux already takes too long to boot. Yes, it is a problem with the kernels hotplug implementation. Hotplug and udev are just linked together. I'm not blaming the userspace part (udev) but the kernel part (hotplug). Why? Hotplug HW is now commodity, hw components appearing and disappearing any time (and in parallel) are a fact of life. Generalizing the concept so that _everything_ is treated as hot-plugged actually makes things easier since you no longer has to handle two separate cases. And that is what I consider broken. I know it is not going to change but I pain for all the users (and myself) that will (and already have been) get hit by problems caused by it. Then why not start working on a solution? There are several distros running udev, surely it would be possible to build a database of common problems and find solutions? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Wouter Verhelst [EMAIL PROTECTED] writes: On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote: On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote: Just like the kernel always did prior to udev. You're missing a very important thing. This is _NOT_ a udev vs. pre-udev question. This is a new kernel hotplug behavior vs. old kernel hotplug behavior question. The fact is that the kernel behavior changed fundamentally in the early 2.6.x series compared to 2.4.x, and userspace did not follow that change ever since. udev simply exposes how the kernel really works. Not using udev solves NOTHING since it's not udev that is broken: it is the general userspace assumption about how the kernel works what is broken. This is pure crap. Install udev on my system - things break randomly and unreproducibly, due to race conditions all over the place. Install hotplug on my system, and make sure udev is not installed - things Just Work(TM). That is because udev is slower so the window of the race condition gets increased many many times. Without udev you don't have to wait for the mknod call to complete. And for most hardware that actualy makes the race condition disapear. Just broken stuff like usb that has asynchronous device detection it still breaks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cleaning up lib*-dev packages?
Goswin von Brederlow [EMAIL PROTECTED] writes: Then I had the idea that I could just as well convert Sources files to create pseudo packages for sources that depend on all the Build-Depends. So I create a dummy deb without contents and converted the Sources file to have src-foobar as package name for foobar, the Build-Depends as Depends and the empty dummy deb as Filename entry. After that I could just do apt-get install src-foobar and it pulls in all the Build-Depends for foobar. The best thing is that, if the Build-Depends of a package change, the next apt-get update/dist-upgrade will pull in the new Build-Depends since the Sources file gets converted on each fresh donwload and the src-foobar package then gets updated. I think a more elegant solution would be if aptitude had a command to install build-depends. It could attach a new flag to a package that causes aptitude to treat build-depends just like depends of that package. This way aptitude would mark build-depends as automatically installed and remove them if they are not needed anymore. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Gabor Gombas [EMAIL PROTECTED] writes: And that is what I consider broken. I know it is not going to change but I pain for all the users (and myself) that will (and already have been) get hit by problems caused by it. Then why not start working on a solution? There are several distros running udev, surely it would be possible to build a database of common problems and find solutions? Gabor Because the only _solution_ with current userspace is to kill the kernels hotplug design and go back to synchronous handling. And that is not going to happen. Anything else is just a work around that tries to hide the race conditions in current userspace environments. The only other solution that keeps the asynchronisity is what Joey suggested at the start: Instead of waiting/polling for udev events to finish move the code into udev rules that get called asynchronously when the devices appear. That means overhauling the complete boot concept of Debian. Not something I would do lightly. And not always easy. E.g. how do you convert startx into an udev rule so it can load the mouse modules savely? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Wouter Verhelst [EMAIL PROTECTED] writes: On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Have you considered employing the alternatives system (or something similar)? What I'm suggesting is that you'd basically get a /bin64 and a /bin32, where binaries install themselves in /bin by default but divert to the /binXX when both versions are installed, and use symlinks in an update-alternatives way to select the default. Each package that deems it neccessary can choose to do so. That's not what I meant, really. I imagine the count to be near 0. Certainly nothing dpkg should handle automagicaly for all debs. Why not? Extra complexity with extra risk of breaking for no practical gain. That could technically be said about all of multiarch... I see a big gain in having a 32bit OOo for amd64 or being able to run any of the old 32bit software. I see no gain in having both a 32bit and 64bit make for example. Also don't forget that you can have more than 2 archs but dpkg can't have more than 2 diversions. Err, okay. I guess I shouldn't have mentioned alternatives, because that clearly confused you. The alternative is not the problem. The diversion is. What I meant to say is that you could have dpkg set up things so that if multiarch is in effect, files would be installed in /multiarch/i386/bin rather than in /bin (or some such), and that symlinks would be made to /bin so that the entire process would be transparent to a package. Alternatively, you could also set it up so that files would be installed in /bin by default, but then moved to /multiarch if the same package, but compiled for a different architecture, would be installed. Next, you would create some program to manage those symlinks. If you prefer to run firefox in 32bit mode by default, you could say update-multiarch --config firefox i386, and it would move symlinks around so that /usr/bin/firefox, and all files from that package with it, refer to the i386 version of firefox rather than the amd64 version, or the ia64 one, or what have you. Note that this would require some packages to use the arch specific binaries. E.g. mkinitramfs or debian-installer need the right arch for their binaries. With the arch/bin dirs being optional those packages then have to support both ways. Another complication. With only one arch per binary only the Depends/Build-Depends have to be arch specific and not the scripts itself. I mentioned the alternatives system because it already exists and it does something similar to what I'm proposing; not because I'm proposing you use exactly that to fix these issues. The whole point really is why not use symlinks? and We've already fixed a similar problem with symlinks, not use the alternatives system. The alternatives system is the exact and perfect solution to this problem and is already existing and working. Not using it just means you are duplicating its functionality. The only difference is that packages use alternatives manualy while you want dpkg to automagicaly add alternatives. The problem lies in this magic instead of the handfull of packages that would even need 32/64 bit implementing it themself. The only currently known case where users might want 32bit and 64bit of the same binary are browsers. And even for that there is no good reason why just 32bit isn't enough. 64bit is just wanted for the slight speed increase. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Section of -dev packages
Christoph Berg [EMAIL PROTECTED] writes: Re: Kevin B. McCarty 2006-05-17 [EMAIL PROTECTED] In case anyone is interested in filing mass bug reports (I am not sufficiently interested, sorry), here are the -dev packages in unexpected sections, obtained as follows: Isn't that more a matter of updating the override files? Christoph Sources say what section gets put into the deb. Overrides say what section gets put into the Packages files. Both have to change. Mismatches result in a nag mail when uploading a package and shows up on packages.qa.d.o. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On May 18, Goswin von Brederlow [EMAIL PROTECTED] wrote: The only other solution that keeps the asynchronisity is what Joey suggested at the start: Instead of waiting/polling for udev events to finish move the code into udev rules that get called asynchronously when the devices appear. That means overhauling the complete boot This is what distributions like SuSE did, BTW. concept of Debian. Not something I would do lightly. And not always easy. E.g. how do you convert startx into an udev rule so it can load the mouse modules savely? You teach X about hotpluggable devices, which I understand is something that has been already planned. -- ciao, Marco signature.asc Description: Digital signature
Re: cleaning up lib*-dev packages?
Matthias Julius [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Then I had the idea that I could just as well convert Sources files to create pseudo packages for sources that depend on all the Build-Depends. So I create a dummy deb without contents and converted the Sources file to have src-foobar as package name for foobar, the Build-Depends as Depends and the empty dummy deb as Filename entry. After that I could just do apt-get install src-foobar and it pulls in all the Build-Depends for foobar. The best thing is that, if the Build-Depends of a package change, the next apt-get update/dist-upgrade will pull in the new Build-Depends since the Sources file gets converted on each fresh donwload and the src-foobar package then gets updated. I think a more elegant solution would be if aptitude had a command to install build-depends. It could attach a new flag to a package that causes aptitude to treat build-depends just like depends of that package. This way aptitude would mark build-depends as automatically installed and remove them if they are not needed anymore. Matthias That wouldn't work well with dpkg, apt-get, deborphan, debfoster. I would also think that aptitude uses /var/lib/dpkg/status for the list of installed packages and the build-depends would not show up there. Aptitude would need its own list of imaginaryinstalled sources to keep track of them. With pseudo packages you can run dpkg --purge src-foobar and the next time aptitude runs it would suggest cleaning up. I'm also thinking of actualy populating the source packages with the actual source. apt-get install src-foo would then install all the build-depends and put the source files into /usr/src. So if you want to work on a package you could do: apt-get install src-foobar dpkg-source -x /usr/src/foobar*.dsc cd foobar*/ sensible-editor debuild But I'm not so sure how usefull that would actualy be. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote: That is because udev is slower so the window of the race condition gets increased many many times. Without udev you don't have to wait for the mknod call to complete. I think you got the speed comparison wrong: udev does the mknod() from a C program running as a daemon, while hotplug means forking a new shell for every event. That should be several magnitudes slower. And for most hardware that actualy makes the race condition disapear. Just broken stuff like usb that has asynchronous device detection it still breaks. No, you're mixing things up. It seems that what you have a problem with is the dynamic /dev. Since hotplug does not provide a dynamic /dev, programs that assume /dev nodes are always there will of course work. Try adding UDEV_DISABLED=yes to /etc/udev.conf to disable the dynamic /dev (sorry, Marco :-) IMHO if you build a kernel with devfs or ndevfs enabled you'll have exactly the same races with hotplug than you have with udev. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
The only other solution that keeps the asynchronisity is what Joey
suggested at the start: Instead of waiting/polling for udev events to
finish move the code into udev rules that get called asynchronously
when the devices appear.
Yep, that's the fix.
That means overhauling the complete boot concept of Debian.
Yes, it's just about time.
Not something I would do lightly. And not always easy.
Nobody said it will be. But somebody should start it.
E.g. how do you convert startx into an udev rule so it can load
the mouse modules savely?
By the time the user types his/her password and starts startx the mouse
will be surely detected (unless it is a broken USB device you said you
do not want to care about).
In case of {x|g|k}dm, by the time you sort out the boot process Xorg
will have input device hotplug so you can start it from the fbdev rule,
and the X server will start using the mouse automatically when it is
detected. In the mean time adding sleep 10 to /etc/init.d/{x|g|k}dm is
an acceptable workaround.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3: http://www.lpds.sztaki.hu
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 07:45:01PM +0200, Marco d'Itri wrote: On May 18, Goswin von Brederlow [EMAIL PROTECTED] wrote: The only other solution that keeps the asynchronisity is what Joey suggested at the start: Instead of waiting/polling for udev events to finish move the code into udev rules that get called asynchronously when the devices appear. That means overhauling the complete boot This is what distributions like SuSE did, BTW. concept of Debian. Not something I would do lightly. And not always easy. E.g. how do you convert startx into an udev rule so it can load the mouse modules savely? You teach X about hotpluggable devices, which I understand is something that has been already planned. There's already a massively improved evdev driver written by our own Zephaniah E. Hull which allows this. There's been further work done by both Zephaniah and (also our own) Daniel Stone to implement this in the server. The new evdev driver is available and I'll be shipping it with 7.1 (possibly even before) while Daniel's patch is currently undergoing review and should be made available soon. Either way, the work is in progress and I'm personally really excited about it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GConf rant
I've just seen this in the gnome-applets package's postinst:
if [ $1 = configure ]; then
SCHEMA_LOCATION=/usr/share/gconf/schemas
GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
HOME=/root \
gconftool-2 --direct --config-source=${GCONF_CONFIG_SOURCE}
--load ${SCHEMA_LOCATION}/mc-default-macros.entries /dev/null
kill -s HUP `pidof gconfd-2` /dev/null 21 || true
fi
DO NOT *EVER* THINK AGAIN OF DOING SUCH THINGS, ANYONE !
Given the size of /etc/gconf/gconf.xml.defaults this is far from being
the only package to do that.
There is no way to clean properly these additions to the GConf default
source. Furthermore they will overwrite changes from the system
administrator.
If you want to override default values from upstream, please read the
dh_gconf manual page.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: debian and UDEV
Gabor Gombas [EMAIL PROTECTED] writes: On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote: That is because udev is slower so the window of the race condition gets increased many many times. Without udev you don't have to wait for the mknod call to complete. I think you got the speed comparison wrong: udev does the mknod() from a C program running as a daemon, while hotplug means forking a new shell for every event. That should be several magnitudes slower. With a static dev there is no mknod syscall to wait for. That's what I was refering too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote: On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote: Just like the kernel always did prior to udev. You're missing a very important thing. This is _NOT_ a udev vs. pre-udev question. This is a new kernel hotplug behavior vs. old kernel hotplug behavior question. The fact is that the kernel behavior changed fundamentally in the early 2.6.x series compared to 2.4.x, and userspace did not follow that change ever since. udev simply exposes how the kernel really works. Not using udev solves NOTHING since it's not udev that is broken: it is the general userspace assumption about how the kernel works what is broken. This is pure crap. Install udev on my system - things break randomly and unreproducibly, due to race conditions all over the place. Install hotplug on my system, and make sure udev is not installed - things Just Work(TM). That is because udev is slower so the window of the race condition gets increased many many times. Without udev you don't have to wait for the mknod call to complete. Which is a bad thing, why? And for most hardware that actualy makes the race condition disapear. Exactly. So there. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Section of -dev packages
Goswin von Brederlow wrote: Christoph Berg [EMAIL PROTECTED] writes: Re: Kevin B. McCarty 2006-05-17 [EMAIL PROTECTED] In case anyone is interested in filing mass bug reports (I am not sufficiently interested, sorry), here are the -dev packages in unexpected sections, obtained as follows: Isn't that more a matter of updating the override files? Christoph Sources say what section gets put into the deb. Overrides say what section gets put into the Packages files. Both have to change. Mismatches result in a nag mail when uploading a package and shows up on packages.qa.d.o. I don't really understand the reason for this redundancy. Maybe back in the good old days when the archive really was organized by package sections, it had its uses. Nowadays it just seems like a pain in the neck for maintainers who want to update the sections of their packages (most commonly, I would imagine, to oldlibs) as well as a hassle for the people with the power to update the overrides (the FTP-masters, I guess). Could the archive infrastructure be updated to synch the override file with what's in the .debs automatically? regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
On Thu, May 18, 2006 at 08:05:35PM +0200, Gabor Gombas wrote: On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote: That is because udev is slower so the window of the race condition gets increased many many times. Without udev you don't have to wait for the mknod call to complete. I think you got the speed comparison wrong: udev does the mknod() from a C program running as a daemon, while hotplug means forking a new shell for every event. That should be several magnitudes slower. The difference being that hotplug doesn't even *attempt* to do an mknod() in its default configuration. Udev does do so, for everything. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Gabor Gombas [EMAIL PROTECTED] writes:
On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
E.g. how do you convert startx into an udev rule so it can load
the mouse modules savely?
By the time the user types his/her password and starts startx the mouse
will be surely detected (unless it is a broken USB device you said you
do not want to care about).
Why should it be? Using the old style module loading on demand instead
of preloading everything with discover or friends there will be no
mouse device loaded. In that case X loads the mouse modules on start.
Before a sleep was added this always failed because of the race
condition between insmod and open of the device and udev creating the
device node.
In case of {x|g|k}dm, by the time you sort out the boot process Xorg
will have input device hotplug so you can start it from the fbdev rule,
and the X server will start using the mouse automatically when it is
detected. In the mean time adding sleep 10 to /etc/init.d/{x|g|k}dm is
an acceptable workaround.
It is a long way to go.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Cheers, aj signature.asc Description: Digital signature
Re: Sun Java available from non-free
On 5/18/06, Anthony Towns aj@azure.humbug.org.au wrote: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. But I guess the question should be answered by the license, not by the FAQ. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Who?
Re: Section of -dev packages
Kevin B. McCarty [EMAIL PROTECTED] writes: Could the archive infrastructure be updated to synch the override file with what's in the .debs automatically? regards, Better to just remove the sections from override altogether. Just keep what the package says. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow: Because the only _solution_ with current userspace is to kill the kernels hotplug design and go back to synchronous handling. Another solution might be to dynamically attach to udev events. This is how in-kernel async device discovery is handled and correctly done, this is without race conditions: * register a function/program for new devices of your choice * load the proper module * your previously registers function will be run Don't know if this is already possible with udev alone. The current scheme to install files to run rules is too static than what many programs might need. The registration could be something like dbus or the like. The world is not synchronous and predictable. A fake synchronous thing in the kernel would only be a work-around, too. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Hendrik Sattler [EMAIL PROTECTED] writes: Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow: Because the only _solution_ with current userspace is to kill the kernels hotplug design and go back to synchronous handling. Another solution might be to dynamically attach to udev events. This is how in-kernel async device discovery is handled and correctly done, this is without race conditions: * register a function/program for new devices of your choice * load the proper module * your previously registers function will be run But how do you detect when there is no device to be found to call the function? Say you have a scsi controler with no harddisks attached. You boot, you register a continue booting function for the scsi disks, load the scsi modules and then you hang. Bugger. So you have to add a timeout again which means a race condition or too long delay. You end up with polling and displaying waiting for / in a loop. People are saying this is a good thing because then you can hotplug your scsi disk or usb stick that has your / on it and it will continue booting. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cleaning up lib*-dev packages?
I demand that Matthias Julius may or may not have written... [snip] I think a more elegant solution would be if aptitude had a command to install build-depends. AOL. It could attach a new flag to a package that causes aptitude to treat build-depends just like depends of that package. [...] Maybe... just installing the build-depends with any necessary marking as automatically installed would be good enough - possibly regardless of whether they're explicitly mentioned as build-dependencies? -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE. The star of riches is shining upon you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Making init scripts use dash
During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts There are arguments for and against both of them. I'm summarizing what I've gathered during Debconf, but I do want to hear other people's opinions. Option (1) implies making dash base and Essential: yes (currently dash is optional), and that would imply that until no Essential package depends on bash, we would have two shells in Essential. Moving bash out of Essential would probably imply two release cycles (i.e. it couldn't be out of Essential until etch+2). This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. Option (2), on the other hand, implies that package maintainers have to manually edit init scripts (or apply patches) and add the correct dependency. This would mean quite a number of uploads, that might take quite a lot of time. Even though this second option is less disruptive than the first one, if we afterwards decide to move /bin/sh to /bin/dash, it would mean changing all this yet again, so it would be quite a lot of duplicate work. There might be a third option, and that would be make bash run faster. I still need to talk about this with bash's maintainer, but I'm not sure if it can be done without removing any functionalities. Also, I've heard other options being posed, such as writing all init scripts (including /etc/init.d/rc) in python. But I do want to concentrate on what's possible to do for etch or etch+1. So, mainly the question that I want to ask of the rest of the Debian community is if there are more arguments for or against these options, and what do you think would be the best route on implementing this. -- Besos, Marga
Re: debian and UDEV
Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow: Hendrik Sattler [EMAIL PROTECTED] writes: Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow: Because the only _solution_ with current userspace is to kill the kernels hotplug design and go back to synchronous handling. Another solution might be to dynamically attach to udev events. This is how in-kernel async device discovery is handled and correctly done, this is without race conditions: * register a function/program for new devices of your choice * load the proper module * your previously registers function will be run But how do you detect when there is no device to be found to call the function? That's of absolutely no interest because in this case, you cannot go on, having synchronous events or not. However, you might have alternatives for a root partition that are fulfilled with another function call. The point is that to keep the goal in mind: you want to achieve something e.g. by probing many different possibilities. Lets say you want to find a scanner: you probe SCSI busses, spawn a thread that test the parallel bus and another one for USB and whatever else. You only want to find one. You don't synchronize on any of those specific events but on the result: that a scanner is found. Sure, you need a timeout, but it is unrelated to a specific probing method Say you have a scsi controler with no harddisks attached. You boot, you register a continue booting function for the scsi disks, load the scsi modules and then you hang. Bugger. So you have to add a timeout again which means a race condition or too long delay. Just because you need synchronisation points does not mean that you have to do everything synchronously. The situation in userspace is completely the same as in kernel-space and also the solutions are the same. You end up with polling and displaying waiting for / in a loop. Yes. Why not. In fact, that's what your are interested in. You are NOT interested in finding all SCSI disks on the bus but only the device with the root partition. This is found at some time, but the bus scan might not be over, yet. And since you have your / now, you can go on without waiting for the bus scan to be finished. People are saying this is a good thing because then you can hotplug your scsi disk or usb stick that has your / on it and it will continue booting. But you only wait for the real goal. It is not a specific device file, that you are interested in but the root file system in a mounted state. This discussion is like explaining the principles of parallelism with threads and object oriented programming to a PASCAL programmer. HS pgpuIpw1J5YJQ.pgp Description: PGP signature
Re: Making init scripts use dash
On 5/18/06, Margarita Manterola [EMAIL PROTECTED] wrote: During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts There are arguments for and against both of them. I'm summarizing what I've gathered during Debconf, but I do want to hear other people's opinions. Option (1) implies making dash base and Essential: yes (currently dash is optional), and that would imply that until no Essential package Can't you only change the symlink if/when dash is installed? depends on bash, we would have two shells in Essential. Moving bash out of Essential would probably imply two release cycles (i.e. it couldn't be out of Essential until etch+2). This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. Option (2), on the other hand, implies that package maintainers have to manually edit init scripts (or apply patches) and add the correct dependency. This would mean quite a number of uploads, that might take quite a lot of time. Even though this second option is less disruptive than the first one, if we afterwards decide to move /bin/sh to /bin/dash, it would mean changing all this yet again, so it would be quite a lot of duplicate work. Why would all this have to be changed again? /bin/dash would still continue to work, right?
Re: Making init scripts use dash
Le Jeudi 18 Mai 2006 22:31, Olaf van der Spek a écrit : On 5/18/06, Margarita Manterola [EMAIL PROTECTED] wrote: During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts There are arguments for and against both of them. I'm summarizing what I've gathered during Debconf, but I do want to hear other people's opinions. Option (1) implies making dash base and Essential: yes (currently dash is optional), and that would imply that until no Essential package Can't you only change the symlink if/when dash is installed? [...] Why no managing /bin/sh link with update-alternatives ? -- Florent pgp5nRdZzc6bs.pgp Description: PGP signature
Re: cleaning up lib*-dev packages?
Darren Salt [EMAIL PROTECTED] writes: I demand that Matthias Julius may or may not have written... [snip] I think a more elegant solution would be if aptitude had a command to install build-depends. AOL. It could attach a new flag to a package that causes aptitude to treat build-depends just like depends of that package. [...] Maybe... just installing the build-depends with any necessary marking as automatically installed would be good enough - possibly regardless of whether they're explicitly mentioned as build-dependencies? Then they get removed the next time you run aptitude and not when you stop using the source. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
Margarita Manterola [EMAIL PROTECTED] writes: During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash That would mean having 2 shells since some scripts need bash. What a waste on small systems. 2. Change #!/bin/sh for #!/bin/dash in the scripts 3. Make sh an alternative MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Thu, 18 May 2006, Anthony Towns wrote: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. Unfortunatly, in this case the FAQ claims that the license says something which the license doesn't actually say. The licence specifies that you're indemnifying Sun for problems in Debian, or problems that result from the interaction or use of Debian with the covered code. Obvioiusly, without using Debian, it would not be possible for someone to use the JDK with Debian. Thus, the clause applies (the FAQ's holding to the contrary notwithstanding) even when the problem is actually an issue or assumption present in Sun's code. This is why ignoring the FAQ is almost always the only conservative method of reading the license. Don Armstrong -- It has always been Debian's philosophy in the past to stick to what makes sense, regardless of what crack the rest of the universe is smoking. -- Andrew Suffield in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Making init scripts use dash
Em Qui, 2006-05-18 às 17:27 -0300, Margarita Manterola escreveu: During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). Nice... To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. A tool searching for bashisms in init scripts and maintainer scripts could help a lot on this... 2. Change #!/bin/sh for #!/bin/dash in the scripts This would have quite the same effect of having two shells with Essential: yes... Also, I've heard other options being posed, such as writing all init scripts (including /etc/init.d/rc) in python. But I do want to concentrate on what's possible to do for etch or etch+1. I don't think it's a good idea at all, as a shell will always be required in the base system and will always be essential. And... if it was to move to a higher-level language (which I don't think as needed), why not Perl? which is already in the base system and is already an essential package? So, mainly the question that I want to ask of the rest of the Debian community is if there are more arguments for or against these options, and what do you think would be the best route on implementing this. /bin/sh is not /bin/bash, so any bashism in a script run with /bin/sh is a bug. I really think using a more lightweight shell as essential is a good thing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Thu, May 18, 2006 at 06:10:06PM -0300, Daniel Ruoso wrote: This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. A tool searching for bashisms in init scripts and maintainer scripts could help a lot on this... IIRC lintian does this already. gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Elvis Presley: Paralyzed signature.asc Description: Digital signature
Re: Sun Java available from non-free
Hi *DPL*, Anthony Towns aj@azure.humbug.org.au writes: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. The problem is that the FAQ itself says that it *has* no legal value, so we can simply ignore it when checking the license. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Could the person responsible for checking the license please come out and explain why the concerns several people have raised are not a problem for the distribution of the sun java package? I mean, I'd love if we would be able to distribute Sun's Java, but not under these circumstances. And, BTW, I'm not at all impressed by your way of dealing with concerns of other DDs. Marc -- BOFH #199: the curls in your keyboard cord are losing electricity. pgpQCICNRBAZG.pgp Description: PGP signature
Re: Making init scripts use dash
On May 18, Margarita Manterola [EMAIL PROTECTED] wrote: To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts We have an even simpler choice which already works and does not require changes in any package: interested people can divert the /bin/sh symlink to bash and create a new symlink to dash. This is even documented in /usr/share/doc/bash/README.Debian.gz . Alternatives are not a good idea because if they break (and they do, often) for /bin/sh then everything will break, badly. Making dash the default /bin/sh would probably break too many non-debian packages and changing all init scripts to use dash would mean adding a new dependency for no good reason. This is a non-problem. -- ciao, Marco signature.asc Description: Digital signature
Re: Making init scripts use dash
On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote: During some tests I've performed, I've found that making the init scripts run with dash as default shell instead of bash makes the boot time a 10% faster (6 seconds in a 60 second boot). To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts There are arguments for and against both of them. I'm summarizing what I've gathered during Debconf, but I do want to hear other people's opinions. Option (1) implies making dash base and Essential: yes (currently dash is optional), and that would imply that until no Essential package depends on bash, we would have two shells in Essential. Moving bash out of Essential would probably imply two release cycles (i.e. it couldn't be out of Essential until etch+2). This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. It's also influencing the whole system, including any #!/bin/sh scripts that anyone might have installed locally. It's very easy to make a bashism that then will fail to work with /bin/sh, I think the risk of breaking things of users is way too high for me to consider this. Bash is a very decent all-round shell. Option (2), on the other hand, implies that package maintainers have to manually edit init scripts (or apply patches) and add the correct dependency. This would mean quite a number of uploads, that might take quite a lot of time. initscripts are only a very small subset of shellscripts anywhere, and especially a controllable and overseeable subset. Despite the fact that it requires changes to all packages having init scripts, I think this is worth the effort. It ensures that these tweaks for startup improvements are really confined to the init scripts, and also, bugs will be found very quickly this way, because everyone will be using dash for those scripts then. Of course, all the packages in question must then depend on dash, but that's not really a problem IMHO. The only problem I do see is that dash currently asks a question upon installation, which I think it should simply stop doing so, administrators who want this change can really do update-alternatives themselves, the default is IMHO sane (keep bash as /bin/sh). For most applications the speed improvement is neglectable anyway, and IMHO we should only optimise where a speed gain is really significantly present (as in this case). So, mainly the question that I want to ask of the rest of the Debian community is if there are more arguments for or against these options, and what do you think would be the best route on implementing this. Afaik, there isn't really a widely recognised decision of any sort on this. I think what should happen now is for you to publish on this list your benchmark results about the speed gain w.r.t. dash, and consequently getting policy changed to get it to state that init scripts should use #!/bin/dash. Then lintian can gain a warning about scripts not complying, and bugs with patches can be filed on all relevant packages, and eventually NMUd where needed (but I don't think it'll be often needed once the policy change is accepted by the policy making process). Your alternative (1) proposal is also more complicated to get done, and does not allow users to have bash as /bin/sh, but still the bootup time improvements. Without this possibility, I'm myself at least not in favour of going this way at all. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, 17 May 2006 23:09:30 -0700 Don Armstrong wrote: Executive Summary: [...] I'd recommend that ftp-masters consider pulling this package from non-free until these issues are resolved (or at least understood.) Agreed. [...] 2. License Grant. Subject to the terms and conditions of this Agreement, [...] provided that: (a) the Software and any proprietary legends or notices are complete and unmodified; This seems to cause a problem with actually packaging the software unless the Debian package counts as the Software... this seems to mean that any time that the package should be changed the maintainers need Sun to actually distribute the software to them (or otherwise grant them the ability to modify the software.) You're right: this is another major issue. (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; non-free is not part of Debian so we definetly don't distribute it as part of the Operating system. Right! I hadn't noticed this point before. I hereby retract my statement about 2(b) not being violated by Debian. It seems that the Debian Project is indeed violating this clause too. (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; This means that we can't distribute eclispse or anything else which implements part of the Java API (or if you're going to read this clause as broadly as possible,[1] things like perl which implement similar functionality in that perl is an implementation of a cross platform language Perl.) Exactly. (d) you do not remove or modify any included license agreement or impede or prevent it from displaying and requiring acceptance; We may need to modify debconf preseeding to make sure that the user can't prevent the agreement from being shown... And that's another problem, thanks for catching it up. (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. I'm really not entirely sure what this clause is getting at, but it seems that the intention is that Debian needs to indemnify Sun for any litigation resulting by users of the package of Sun's JDK which Debian has distributed, even if Sun is grossly negligent.[2] Maybe... 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun or a licensee of the Software (under section 4(b)) notifies you that there are compatibility issues [...] caused by the interaction of the Software with your Operating System, then within ninety (90) days you must either: (a) modify the Operating System in a way that resolves the compatibility issue (as determined by Sun) and make a patch or replacement version available [...] Oh, right... so if the Sun JDK is buggy, we have to modify our operating system to make it unbuggy in some way that makes Sun happy. Makes sense to me. [...] As I already said, we are in chains... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpf3FXlUc6lH.pgp Description: PGP signature
Re: Making init scripts use dash
On 5/18/06, Marco d'Itri [EMAIL PROTECTED] wrote: On May 18, Margarita Manterola [EMAIL PROTECTED] wrote: To make this speed up available to everyone, we have 2 main choices: 1. Make /bin/sh point to /bin/dash 2. Change #!/bin/sh for #!/bin/dash in the scripts We have an even simpler choice which already works and does not require changes in any package: interested people can divert the /bin/sh symlink to bash and create a new symlink to dash. This is even documented in /usr/share/doc/bash/README.Debian.gz . Alternatives are not a good idea because if they break (and they do, often) for /bin/sh then everything will break, badly. Good, but i think interested people here are all our users, so what we're going to do with the 10% performance hit for use bash? I think Margarita is interested in a solution suitable for Etch and/or Etch+1. Making dash the default /bin/sh would probably break too many non-debian packages and changing all init scripts to use dash would mean adding a new dependency for no good reason. This is a non-problem. I think making dash the default /bin/sh for Etch now would probably be insane yes, but we should focus on solve problems for our next release (Etch) and what we can do now to prepare a even better Etch+1. This is the real problem, i'm not talking only about the 'dash' issue. regards, -- stratus
Re: cleaning up lib*-dev packages?
I demand that Goswin von Brederlow may or may not have written... Darren Salt [EMAIL PROTECTED] writes: I demand that Matthias Julius may or may not have written... [snip] I think a more elegant solution would be if aptitude had a command to install build-depends. AOL. It could attach a new flag to a package that causes aptitude to treat build-depends just like depends of that package. [...] Maybe... just installing the build-depends with any necessary marking as automatically installed would be good enough - possibly regardless of whether they're explicitly mentioned as build-dependencies? Then they get removed the next time you run aptitude and not when you stop using the source. Well, yes. Perhaps I should have explicitly qualified that - but only if they're depended upon by other build dependencies - but any necessary marking seemed to cover it. Marking them all would indeed be daft. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Steer clear of incorrect forms of verbs that have snuck in the language. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Thu, 18 May 2006 22:38:08 +0200, Goswin von Brederlow wrote: [...] 3. Make sh an alternative dash already optionally diverts it. Isn't it good enough? -- Michał Politowski Talking has been known to lead to communication if practiced carelessly.
Bug#367959: ITP: otrs2 -- Open Ticket Request System version 2
Package: wnpp Severity: wishlist Owner: Torsten Werner [EMAIL PROTECTED] Package name: otrs2 Version : 2.0.4 Upstream Author : OTRS GmbH URL : http://www.otrs.org/ License : GPL Description : Open Ticket Request System version 2 OTRS is an Open source Ticket Request System (also well known as trouble ticket system) with many features to manage customer telephone calls and e-mails. The system is built to allow your support, sales, pre-sales, billing, internal IT, helpdesk, etc. department to react quickly to inbound inquiries. For a detailed documentation see package otrs-doc. . This package ships version 2 of OTRS. Note that there is no fully automatic upgrade path from version 1.3, please consult /usr/share/doc/otrs2/README.Debian.gz for more information about that. Rationale: I am the primary maintainer of OTRS. OTRS cannot be easily upgraded from version 1.3 to version 2. That is why I am planning to package version 2 in a seperate package providing a half automatic upgrade script. The current version of otrs in unstable will be rolled back to version 1.3.3 after uploading otrs2. Please don't forget to Cc: any replies to me. Regards, Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Anthony Towns schrieb am Donnerstag, den 18. Mai 2006: On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. This is not the way a DPL should answer, we were asking important questions and its our right to get sane answers. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. I give nothing about an analysis I haven't seen from somebody I dont know. Uploading such a package with such a license without any discussion is a shame for Debian. Some not mentioned ftp-master waved the package (as the only package) through after a few hours, beside that this ftp-master didn't processed NEW for a long time. This all really smells strong and after reading the license carefully and talked with several other people I came to the conclusion that I have to do anything that I can to get this out of debian again. This is not the freedom I'm standing for. And after all thats not the way I wanted a project I'm working in to act, I see this way of acting as a personal affront to me and my Debian work... This really went wrong and I want to have some _good_ explanations or we will have to bear the consequences. Alex signature.asc Description: Digital signature
The necessity of running depmod at boot time
Continuing on the goal of optimizing boot time, quite a number of seconds (specially in old machines) can be saved by not running depmod at boot time. Currently it is run by these packages' postinst: * kernel/linux-image-* * module-init-tools * powermgt-base * zaptel * lirc * toshutils * thinkpad-base * rng-tools * lm-sensors-* * ipx * evms * dumputils * debian-edu-config * loop-aes-* * pcmcia-modules-* * pwc-modules-* * ndiswrapper-modules-* * linux-wlan-ng-modules-* * spca5xx-modules-* * kernel-pcmcia-modules-* * hostap-modules-* * alsa-modules-* * pwc-modules-* * linux-wlan-ng-modules-* * ieee80211softmac-modules-* * misdn-modules-* * unionfs-modules-* It looks like it's quite safe to stop running depmod during boot time, since both new kernels and new modules run it at install time. If there are modules that don't run depmod on installation, they should do it. Opinions about this are welcome. -- Besos, Marga
Re: Making init scripts use dash
On May 18, Gustavo Franco [EMAIL PROTECTED] wrote: Good, but i think interested people here are all our users, so what we're going to do with the 10% performance hit for use bash? I think Nothing. A 10% optimization of init scripts which we already know are highly suboptimal is not worth pursuing. Try benchmarking again the shells after enabling parallel processing of init scripts and let's see how much time dash would save in that situation. Making dash the default /bin/sh would probably break too many non-debian packages and changing all init scripts to use dash would mean adding a new dependency for no good reason. I think making dash the default /bin/sh for Etch now would probably be insane yes, but we should focus on solve problems for our next release (Etch) and what we can do now to prepare a even better Etch+1. This is the real problem, i'm not talking only about the 'dash' issue. bashisms in the wild is not something which will be solved by the rest of the world after etch. Time will not help much. -- ciao, Marco signature.asc Description: Digital signature
Re: The necessity of running depmod at boot time
On May 19, Margarita Manterola [EMAIL PROTECTED] wrote: Continuing on the goal of optimizing boot time, quite a number of seconds (specially in old machines) can be saved by not running depmod at boot time. If we can agree that it's not needed anymore (i.e. mandate by policy that packages need to run depmod on their own) then I will be happy to remove it from the m-i-t init script. -- ciao, Marco signature.asc Description: Digital signature
Re: The necessity of running depmod at boot time
On Thu, May 18, 2006 at 07:21:33PM -0300, Margarita Manterola [EMAIL PROTECTED] wrote: Continuing on the goal of optimizing boot time, quite a number of seconds (specially in old machines) can be saved by not running depmod at boot time. (...) It looks like it's quite safe to stop running depmod during boot time, since both new kernels and new modules run it at install time. If there are modules that don't run depmod on installation, they should do it. Opinions about this are welcome. Last time I took a look to that boot depmod, it was supposed to be launched by the script only if necessary, but for some reason, just was launched at every single boot. Never figured out why, and forgot to file a bug. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The necessity of running depmod at boot time
Marco d'Itri wrote: If we can agree that it's not needed anymore (i.e. mandate by policy that packages need to run depmod on their own) then I will be happy to remove it from the m-i-t init script. A while back Debian would only run depmod on boot if it had not been run before since the last kernel upgrade. Could you refresh my memory about why that optimisation was dropped? -- see shy jo signature.asc Description: Digital signature
Re: The necessity of running depmod at boot time
On Thu, May 18, 2006 at 07:21:33PM -0300, Margarita Manterola wrote: Continuing on the goal of optimizing boot time, quite a number of seconds (specially in old machines) can be saved by not running depmod at boot time. Currently it is run by these packages' postinst: * [long list] It looks like it's quite safe to stop running depmod during boot time, since both new kernels and new modules run it at install time. If there are modules that don't run depmod on installation, they should do it. I think one of the issues here is that it depends on what kernel you currently use, and iirc there can be a situation where one does not want to run depmod at installation time, or when that might give wrong results. What I think would be best is to have every packages that now requires running depmod at boot time, will touch a file in /lib/modules/kernel-api when it has changed the kernel (or modules) significantly so that it is needed to be run, and at boot time only run depmod if that touched file exists (and have the file removed after having run depmod succesfully). This way, depmod at boot is only run after changes in kernel or modules once for each given kernel API that's booted. If the package code in each package for this (for the bit to conditionally run depmod at installation time too) is not trivial, it might be worth having a bit about this in some dh_* script, so that the code in question is only written once. I'm not sure here though, I don't think it's needed as the majority of the code can be in the package providing depmod. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The necessity of running depmod at boot time
Margarita Manterola wrote: Currently it is run by these packages' postinst: * kernel/linux-image-* This takes care to run depmod -F system.map version, which should make the depmod work even though that kernel isn't running yet. * pwc-modules-* * ndiswrapper-modules-* * linux-wlan-ng-modules-* * spca5xx-modules-* * kernel-pcmcia-modules-* * hostap-modules-* * alsa-modules-* * pwc-modules-* * linux-wlan-ng-modules-* * ieee80211softmac-modules-* * misdn-modules-* * unionfs-modules-* I've checked a few of these as well as dh_installmodules and none I've checked bother with -F or the kernel version, so installing a new version of the kernel, and then third party modules that use it, then rebooting into the new kernel, will not make the modules available if the depmod on boot is not run at least the first time booting a new kernel. Of course, all of these could be fixed to run depmod correctly, although adding that to dh_installmodules will require some way to determine the kernel version the modules are built for. -- see shy jo signature.asc Description: Digital signature
Re: The necessity of running depmod at boot time
Jeroen van Wolffelaar wrote: I think one of the issues here is that it depends on what kernel you currently use, and iirc there can be a situation where one does not want to run depmod at installation time, or when that might give wrong results. FWIW, d-i currently runs depmod at image build time, when a different kernel is generally running than the one on the image being built, and we've not had any problems with it since at least the sarge release. IIRC there were some bugs with it a few years ago. -- see shy jo signature.asc Description: Digital signature
Re: Making init scripts use dash
On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote: Also, I've heard other options being posed, such as writing all init scripts (including /etc/init.d/rc) in python. But I do want to concentrate on what's possible to do for etch or etch+1. If you're going to use a real scripting language to implement initscripts, why not use one that is Essential: yes already? Try 'apt-cache show perl-base|grep Essential'. You'd still have to move it to /bin rather than /usr/bin, though. Also, I'm not sure whether moving away from bash and towards another scripting language is going to really make it be faster. Anyway. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Thu, May 18, 2006 at 11:29:47PM +0200, Jeroen van Wolffelaar wrote: On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote: This option also might imply some extra bugs, but it's believed that not so many, since there are already quite a number of people with /bin/sh - /bin/dash, and they do file bugs when bashisms appear. It's also influencing the whole system, including any #!/bin/sh scripts that anyone might have installed locally. It's very easy to make a bashism that then will fail to work with /bin/sh, I think the risk of breaking things of users is way too high for me to consider this. Bash is a very decent all-round shell. Many non-Linux systems don't even have bash *installed* by default. FreeBSD, for example, comes with a POSIX-compatible /bin/sh which is not bash. Since bash does enable some features that are not specified in POSIX, even when called as /bin/sh, I don't see what the problem would be of installing something else as our default /bin/sh (ignoring the fact that only bash is Essential: yes for a second). It would greatly improve portability of said non-Debian scripts. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The necessity of running depmod at boot time
On May 19, Joey Hess [EMAIL PROTECTED] wrote: A while back Debian would only run depmod on boot if it had not been run before since the last kernel upgrade. Could you refresh my memory about why that optimisation was dropped? I think because depmod --quick is supposed to be about as fast as find. A second reason for which I would like to remove the depmod call is that -w does not actually work to test if / is mounted read only, so to fix the script I would need to touch /lib/modules at every boot (#358239). -- ciao, Marco signature.asc Description: Digital signature
Re: Making init scripts use dash
On May 19, Wouter Verhelst [EMAIL PROTECTED] wrote: Since bash does enable some features that are not specified in POSIX, even when called as /bin/sh, I don't see what the problem would be of installing something else as our default /bin/sh (ignoring the fact That it would break all these non-portable scripts (do you really suggest that our users should debug bashisms in other people's autoconf scripts?). that only bash is Essential: yes for a second). It would greatly improve portability of said non-Debian scripts. I doubt that the rest of the world would notice, at least for the first few years, and we can be sure that it would greatly raise frustration in our users. -- ciao, Marco signature.asc Description: Digital signature
Re: debian and UDEV
Hendrik Sattler [EMAIL PROTECTED] writes: Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow: Hendrik Sattler [EMAIL PROTECTED] writes: Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow: Because the only _solution_ with current userspace is to kill the kernels hotplug design and go back to synchronous handling. Another solution might be to dynamically attach to udev events. This is how in-kernel async device discovery is handled and correctly done, this is without race conditions: * register a function/program for new devices of your choice * load the proper module * your previously registers function will be run But how do you detect when there is no device to be found to call the function? That's of absolutely no interest because in this case, you cannot go on, having synchronous events or not. However, you might have alternatives for a root partition that are fulfilled with another function call. The point is that to keep the goal in mind: you want to achieve something e.g. by probing many different possibilities. Lets say you want to find a scanner: you probe SCSI busses, spawn a thread that test the parallel bus and another one for USB and whatever else. You only want to find one. You don't synchronize on any of those specific events but on the result: that a scanner is found. Sure, you need a timeout, but it is unrelated to a specific probing method So you mean you register a function for block device found and then scan all the ide, sata, scsi, usb, ... drivers from the initrd and for every disk and partition the function gets called. When it gets called with the partition with the right signature (label or uuid for example) it mounts / and continues. Not a function for scsi disk ID 0 on scsi0 (3ware) found. I see what you mean. Keeping the function abstract enough allows removing a disk and plug it in somewhere else, e.g. change the scsi ID. Say you have a scsi controler with no harddisks attached. You boot, you register a continue booting function for the scsi disks, load the scsi modules and then you hang. Bugger. So you have to add a timeout again which means a race condition or too long delay. Just because you need synchronisation points does not mean that you have to do everything synchronously. The situation in userspace is completely the same as in kernel-space and also the solutions are the same. You end up with polling and displaying waiting for / in a loop. Yes. Why not. In fact, that's what your are interested in. You are NOT interested in finding all SCSI disks on the bus but only the device with the root partition. This is found at some time, but the bus scan might not be over, yet. And since you have your / now, you can go on without waiting for the bus scan to be finished. People are saying this is a good thing because then you can hotplug your scsi disk or usb stick that has your / on it and it will continue booting. But you only wait for the real goal. It is not a specific device file, that you are interested in but the root file system in a mounted state. This discussion is like explaining the principles of parallelism with threads and object oriented programming to a PASCAL programmer. HS Yeah, sorry. I wasn't thinking abstract enough. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
Michal Politowski [EMAIL PROTECTED] writes: On Thu, 18 May 2006 22:38:08 +0200, Goswin von Brederlow wrote: [...] 3. Make sh an alternative dash already optionally diverts it. Isn't it good enough? When I upload my fash (fast shell) package that would want to divert sh too and then could conflict with dash if they both try to divert. Alternatives are more suited for cases where one binary is provided by multiple packages. Currently we have bash, dash, sash, posh. Anything else? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cleaning up lib*-dev packages?
Darren Salt [EMAIL PROTECTED] writes: I demand that Goswin von Brederlow may or may not have written... Darren Salt [EMAIL PROTECTED] writes: I demand that Matthias Julius may or may not have written... [snip] I think a more elegant solution would be if aptitude had a command to install build-depends. AOL. It could attach a new flag to a package that causes aptitude to treat build-depends just like depends of that package. [...] Maybe... just installing the build-depends with any necessary marking as automatically installed would be good enough - possibly regardless of whether they're explicitly mentioned as build-dependencies? Then they get removed the next time you run aptitude and not when you stop using the source. Well, yes. Perhaps I should have explicitly qualified that - but only if they're depended upon by other build dependencies - but any necessary marking seemed to cover it. Marking them all would indeed be daft. Packages that something depends on don't get removed anyway. Automatic or not. The only intresting bits are those without anything depending on them. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The necessity of running depmod at boot time
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: I think one of the issues here is that it depends on what kernel you currently use, and iirc there can be a situation where one does not want to run depmod at installation time, or when that might give wrong results. That used to be the case but for a while now that has been fixed. It is just a matter of having all packages call depmod properly. (see other mails). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
