Re: Debian on the Desktop - plans for Lenny?
On Thu, Aug 09, 2007, Tim Hull wrote: > Update: it works with libxine1-ffmpeg installed. Evidently totem-xine is > installed by default - at least if you install Etch and upgrade to Lenny. > Is this by design, or just an issue with Etch to Lenny transitions. I'm > going to install totem-gstreamer now and compare performance (the audio on > some trailers didn't work with xine). It's probably an issue with your package manager not enforcing Recommends yet as totem-xine now Recommends libxine1-ffmpeg. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out of the box CPU frequency scaling
[manphiz]
> As in my case it didn't work because the cpufreq related modules
> were not loaded automatically, I had to explicitly write them down
> in /etc/modules, then everything is fine.
The /etc/init.d/loadcpufreq script is supposed to load the cpufreq
related modules automatically. If this do not work for your machine,
please submit a bug report and if possible, explain why it failed.
> Why? Powernowd is simply another scaling governor daemon along side
> cpufreq{d,utils} regardless of cpu type, which works well on my
> Intel box.
Because the kernel with ondemand governor does a better job for Intel
CPUs, according to the Intel engineer writing the powertop utililty.
See http://www.bughost.org/pipermail/power/2007-May/90.html>
some background info.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Thu, Aug 09, 2007 at 08:17:13AM +0200, Mike Hommey wrote: > On Thu, Aug 09, 2007 at 08:00:00AM +0200, Christian Perrier <[EMAIL > PROTECTED]> wrote: > > > No, we should use the liberation fonts, which are designed to replace > > > the MS fonts. > > > > Have their licensing issues been solved? > > Which ones ? 1. It claims to use GPLv2, yet it has an incompatible anti-Tivo clause; it's debatable whether it's DFSG-free. I would say it isn't, but it's not up to me to decide. The clause is clearly marked as an "exception", so, while obviously non-GPL-compatible, it's a valid license, distributable and so on. 2. It has a separate rename clause, where making ANY modification, even as small as adding a debian/ dir, requires you to drop the "Liberation" name. There's no exception to the GPL which would allow distribution while that clause is there... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436878: ITP: gconf-cleaner -- GConf database cleaner
Package: wnpp Severity: wishlist Owner: Julien Valroff <[EMAIL PROTECTED]> * Package name: gconf-cleaner Version : 0.0.3 Upstream Author : Akira TAGOH <[EMAIL PROTECTED]> * URL : http://code.google.com/p/gconf-cleaner/ * License : GPL Programming Lang: C Description : GConf database cleaner GConf Cleaner is a tool to clean your GConf database up that is possibly cluttered with unnecessary or invalid keys. You may want to keep a clean your GConf database. this tool might help you in this case. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Updating NEWS.Debian
I have seen some packages lately, most prominently apache2, that replace the entire NEWS.Debian file when they have some news to report. That way, older news are lost, and users who don't upgrade to every intermediate version (say, those who upgrade only between stable releases) are left in the dark. So if you have been doing that, please don't, and put the old news entries back at the bottom of the file. Bugs should probably be submitted about that kind of misuse. The Developer's Reference doesn't make this point entirely clear. Maybe that ought to be improved as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: > Additionally, it should be noted that a desktop task has nothing with > multimedia (means: surprise, you can use a desktop without music and > movies). I think we need to have multiple desktop tasks. One desktop-simple, desktop-multimedia-support, etc This would also simplify the use of tasks to enhance the desktop, like desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Thu, Aug 09, 2007 at 10:55:13AM +0200, Adam Borowski wrote: > On Thu, Aug 09, 2007 at 08:17:13AM +0200, Mike Hommey wrote: > > On Thu, Aug 09, 2007 at 08:00:00AM +0200, Christian Perrier <[EMAIL > > PROTECTED]> wrote: > > > > No, we should use the liberation fonts, which are designed to replace > > > > the MS fonts. > > > > > > Have their licensing issues been solved? > > > > Which ones ? > > 1. It claims to use GPLv2, yet it has an incompatible anti-Tivo clause; it's > debatable whether it's DFSG-free. I would say it isn't, but it's not up to > me to decide. > The clause is clearly marked as an "exception", so, while obviously > non-GPL-compatible, it's a valid license, distributable and so on. Ugh, bad me. I looked only at the license itself, the debian-legal consensus seems to be that additional restrictions over the GPL are illegal (http://www.mail-archive.com/[EMAIL PROTECTED]/msg36584.html). > [...] -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating NEWS.Debian
On Thu, Aug 09, 2007 at 11:08:46AM +0200, Peter Eisentraut wrote: > I have seen some packages lately, most prominently apache2, that replace the > entire NEWS.Debian file when they have some news to report. That way, older > news are lost, and users who don't upgrade to every intermediate version > (say, those who upgrade only between stable releases) are left in the dark. > So if you have been doing that, please don't, and put the old news entries > back at the bottom of the file. Bugs should probably be submitted about that > kind of misuse. I believe it is entirely appropriate to delete versions that never made it to a stable release, having the NEWS.Debian file contain an entry for each stable release and for the current release candidate version (generally, the current version in unstable); obviously, any of these may be missing if there is no news to report. The current version should contain all news that affect upgrades from the latest stable release to the current version. The reason? It's counterproductive and silly, when upgrading from oldstable to stable, to get lots of news that was ever relevant only for sid-to-sid upgrades. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Seeking new maintainer(s) for HPLIP and amavisd-new
Hello, On Wed, Aug 08, 2007 at 11:11:24PM -0300, Henrique de Moraes Holschuh wrote: > [...] > The requirements for amavisd-new is a good grasp of perl and email > infrastructure, and the usual careful attitude one should have when dealing > with packages that are often mission-critical. Upstream is very helpful, > active, and friendly. > > If anyone is interested, please send me your alioth logins. I use amavisd-new on a lot of mail servers some years ago. I'm interested to help to maintain it. I think the first TODOs are preparing new packages with new upstream release and working on BTS (there are 1 RC-bug and some bugs with patch). My alioth login is 'reg-guest' (note that I'm not DD). Regards, -- Gregory Colpart <[EMAIL PROTECTED]> GnuPG:1024D/C1027A0E Evolix - Informatique et Logiciels Libres http://www.evolix.fr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Arch-independent parts of binary modules of interpreted languages
(Please don't start a debate over what an interpreted language is, I just tried to generalize the subject.) Perl XS module packages usually install all their code under /usr/lib/perl5 - not just the shared library that implements the external subroutine, but also at least one ordinary module, which interfaces with the shared library using DynaLoader and perhaps provides additional subroutines. These ordinary modules are not architecture-specific in themselves. I don't know that much about Python - IIUC the interpreter can directly load shared libraries that implement the right interface, but python2.4 and python2.5 at least install .py files in /usr/lib/python. What's the rationale behind not strictly separating architecture-independent and architecture-specific code? I'm trying to find out if I can apply the same rationale to the pike packages, which I'm adopting. There the files are separated, with symlinks from /usr/lib/pike to the corresponding location under /usr/share/pike. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) "Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack)" -- Dave Evans pgpcTF41T85be.pgp Description: PGP signature
Bug#436902: ITP: digiband -- full home version drumming/guitar simulator
Package: wnpp Severity: wishlist Owner: Miriam Ruiz <[EMAIL PROTECTED]> * Package name: http://www.digiband.net/ Version : 1.0 Upstream Author : Joe Wall * URL : http://www.digiband.net/ * License : LGPL Programming Lang: C++ Description : full home version drumming/guitar simulator DigiBand is a full home version Drumming/Guitar simulator. It isn't just intended to be a simulator, but a uniquely refreshing new experience. It is much different than simulators already out there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Arch-independent parts of binary modules of interpreted languages
On Thu, 09 Aug 2007, Magnus Holmgren wrote: > (Please don't start a debate over what an interpreted language is, I just > tried to generalize the subject.) > > Perl XS module packages usually install all their code under /usr/lib/perl5 - > not just the shared library that implements the external subroutine, but also > at least one ordinary module, which interfaces with the shared library using > DynaLoader and perhaps provides additional subroutines. These ordinary > modules are not architecture-specific in themselves. I don't know that much > about Python - IIUC the interpreter can directly load shared libraries that > implement the right interface, but python2.4 and python2.5 at least > install .py files in /usr/lib/python. > > What's the rationale behind not strictly separating architecture-independent > and architecture-specific code? The rationale is simply that it's not always easily doable while using the official installation methods, and that changing it manually is error-prone and can be confusing in some cases. While it's important that all files in /usr/share be arch-independent (because one might want to share that between several machines), it's not that important that /usr/lib contains only arch-dependent stuff. In fact, in most cases it's convenient (if not required) to have the arch-indep glue around the binary part in the same directory than the binary part. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Thu, Aug 09, 2007 at 10:27:40AM +0100, Luis Matos wrote: > Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: > > Additionally, it should be noted that a desktop task has nothing with > > multimedia (means: surprise, you can use a desktop without music and > > movies). > > I think we need to have multiple desktop tasks. One desktop-simple, > desktop-multimedia-support, etc > This would also simplify the use of tasks to enhance the desktop, like > desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel As long as those are not exposed to the user at installation - fine; for installation, we should have exactly one desktop task per environment, and that should installed whatever is needed to give a rather complete desktop experience, IMHO. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qui, 2007-08-09 às 14:10 +0200, Michael Banck escreveu: > On Thu, Aug 09, 2007 at 10:27:40AM +0100, Luis Matos wrote: > > Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: > > > Additionally, it should be noted that a desktop task has nothing with > > > multimedia (means: surprise, you can use a desktop without music and > > > movies). > > > > I think we need to have multiple desktop tasks. One desktop-simple, > > desktop-multimedia-support, etc > > This would also simplify the use of tasks to enhance the desktop, like > > desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel > > As long as those are not exposed to the user at installation - fine; for > installation, we should have exactly one desktop task per environment, > and that should installed whatever is needed to give a rather complete > desktop experience, IMHO. i think that beside the expansion of tasks, the "after install" tasksel should be improved. if we can install a simple desktop and then have some place that the user can access to install more stuff and easily expand it's environment. having a console tasksel is not enough ... someone was developing a gtk+ front end ... right? > > > Michael > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
* Simplify installation of out-of-tree kernel modules, possibly by adapting Ubuntu's Restricted Manager to work with m-a. Non-free drivers would *only* be displayed if non-free is in the sources.list. No plans AFAIK. Working on this should not be difficult and should be appreciated, either by improving m-a or by writing something new. In particular, solving the problem described in #299727 and/or creating a GUI would help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Seeking new maintainer(s) for HPLIP and amavisd-new
On Thu, 09 Aug 2007, Gregory Colpart wrote: > On Wed, Aug 08, 2007 at 11:11:24PM -0300, Henrique de Moraes Holschuh wrote: > > [...] > > The requirements for amavisd-new is a good grasp of perl and email > > infrastructure, and the usual careful attitude one should have when dealing > > with packages that are often mission-critical. Upstream is very helpful, > > active, and friendly. > > > > If anyone is interested, please send me your alioth logins. > > I use amavisd-new on a lot of mail servers some years ago. > I'm interested to help to maintain it. I think the first TODOs are > preparing new packages with new upstream release and working on > BTS (there are 1 RC-bug and some bugs with patch). Refer to the messages I just sent to the amavisd-new-debian-devel ML, please. Also be very conservative and careful with any patches, no matter where they came from. With mission-critical stuff like amavisd-new, doing it right is much more important than anything else. amavisd-new is not a package I consider "easy" to maintain because of just that. > My alioth login is 'reg-guest' (note that I'm not DD). Since I had two DDs join already in the last 24h, and I have no previous knowledge of your work (sorry about that, this is no fault of yours, it is just a fact), I will ask that you send an email to amavisd-new-debian-devel introducing yourself and your experience with amavisd-new and Debian packaging. (also please read its archives and subscribe to it if you didn't do it already) Then, after you do some work over the mailing-list (with five people listening to it and with commit access, even if two of them are mostly inactive and I don't have much time, it won't take long for accepted patches to hit the tree), we can see about adding write rights to you for the SCM tree in alioth. Would you be confortable working under these conditions? I'd suggest that whichever one of the (very welcome!) three new amavisd-new-debian developers has more time to spend in amavisd-new in the next few days, and experience with Debian packaging and CVS, clean up the trunk and prepare 2.4.3-1. After that, regardless of whether you decide to upload 2.4.3-1 or go straight to the newest upstream, it will be much easier for you guys to work on it. -- "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: Seeking new maintainer(s) for HPLIP and amavisd-new
On Wed, 08 Aug 2007, Henrique de Moraes Holschuh wrote: > So, this mail is a request for new maintainers for both hplip and > amavisd-new. I've already had three people (two DDs and a non-DD) join in for amavisd-new work. So it looks like it will be well-cared for in the future. But what about HPLIP? No volunteers for it? It is a very visible package, with a lot of users (popcon stats are: 28k installs, 18k votes, 8k recent upgrades for hplip, and 33k installs, 5k votes and 13k recent upgrades for hpijs). It deserves a lot of love I can't give to it, right now. -- "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: Updating NEWS.Debian
On Thu, 09 Aug 2007, Antti-Juhani Kaijanaho wrote: > The reason? It's counterproductive and silly, when upgrading from > oldstable to stable, to get lots of news that was ever relevant only for > sid-to-sid upgrades. Better to do that cleanup near the freeze, if at all. Otherwise, once could easily be causing trouble for the people following unstable and testing. -- "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]
Bug#436921: ITP: phpformgenerator -- create web forms easier
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho <[EMAIL PROTECTED]> * Package name: phpformgenerator Version : 3.0 Upstream Author : Musawir Ali <[EMAIL PROTECTED]> * URL : http://phpformgen.sourceforge.net * License : GPL Description : create web forms easier phpFormGenerator is a an easy online tool to create web forms in a snap. No programming of any sort is required. phpFormGenerator generates the html code, the form processor code (PHP) and the field validation code via an easy point-and-click interface. phpFormGenerator provides several delivery formats. You can choose to have your form results delivered via email, sent to a MySQL database and written to a data file (which you can then open in OpenOffice.Org Calc and other programs). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Wed, Aug 01, 2007 at 09:36:39PM -0400, Joey Hess <[EMAIL PROTECTED]> was heard to say: > Neil Williams wrote: > > And a script to implement that in every box I have to install. Again > > and Again and Again and > > > > You almost forcing me into maintaining a fork of apt that restores the > > current behaviour from the very start. > > Forking apt and putting a line in a config file seem two quite > dissimilar levels of work. YMMV I guess. You don't even need to edit a configuration file in a script; just drop a file into /etc/apt/apt.conf.d containing the appropriate configuration option and apt will include it. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Wed, Aug 01, 2007 at 09:58:30PM +0200, Bernd Zeimetz <[EMAIL PROTECTED]> was heard to say: > > > No - because the default is already in place in aptitude which is WHY I > > don't use aptitude. If apt goes the same way, the default configuration > > of each offers no choice. > > > > By the time I get a chance to switch that option off, the installation > > has added loads of JUNK that I do NOT want. > > but when aptitude came up with that setting a lot of Recommends: should > have been in Suggests: instead. Just to clarify, aptitude didn't "come up" with anything. This was the standard behavior in Debian at the time (dselect was far more draconian about forcing you to install recommended packages), and one of the top complaints I got was that aptitude mishandled Recommends by not installing them! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating NEWS.Debian
Please don't CC me, as I read the list. On Thu, Aug 09, 2007 at 10:49:33AM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 09 Aug 2007, Antti-Juhani Kaijanaho wrote: > > The reason? It's counterproductive and silly, when upgrading from > > oldstable to stable, to get lots of news that was ever relevant only for > > sid-to-sid upgrades. > > Better to do that cleanup near the freeze, if at all. Otherwise, once could > easily be causing trouble for the people following unstable and testing. As long as you actually do that cleanup before the freeze, that's OK :) But if there's a chance you won't have the opportunity, do it now. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Debian on the Desktop - plans for Lenny?
> Well, when you started this thread I was fearing a quite long flame > with everybody jumping at you with "if you don't like you're > free to some and help improving it"which is definitely what > happens too frequently when some users report issues that can't often > be pointed to a given package. > > Indeed, the thread is really interesting to follow and already shows > that big efforts are made to improve those parts who are still not as > polished as they could be (or "appear" polishedmany things you > pointed to be user-friendly in Ubuntu could perfectly be very dirty > hacks..:-)) I must say I've been pleasantly surprised as well. Debian developers have been quite responsive to my concerns... I must say that this is one area Debian definitely outshines Ubuntu - the developers are FAR more responsive. The choice seems really quite simple for someone who has an interest in improving the system - and it's really the opposite of what I expected. For Ubuntu, the user community/MOTU may be quite open, but core development takes place in a very closed-source-like fashion... Debian, however, is open and free in every sense of the word - thank you for staying that way. Well, we should ask users of testing but my feeling is that this goal > is kinda well achieved. I have been using testing, and I figured I'd offer my comment on this. While testing works pretty well, there is still no security updates. I've since gone to unstable, though, to stay up on Debian development to date...
Re: Debian on the Desktop - plans for Lenny?
Quoting Mike Hommey ([EMAIL PROTECTED]): > On Thu, Aug 09, 2007 at 08:00:00AM +0200, Christian Perrier <[EMAIL > PROTECTED]> wrote: > > > No, we should use the liberation fonts, which are designed to replace > > > the MS fonts. > > > > Have their licensing issues been solved? > > Which ones ? Restrictions of modification, IIRC. See -legal a few weeks ago. I was asked to sponsor an upload of ttf-liberation but, after reading the fonts license, I asked the maintainer to take -legal advice.and, IIRC, the conclusion was that soem restrictions pu tin the license were not making the font entirely DFSG-compliant. signature.asc Description: Digital signature
Re: Simplify installation of non-free? (was: Debian on the Desktop - plans for Lenny?)
On Aug 09, Tim Hull <[EMAIL PROTECTED]> wrote: > It's actually not just ATI/nVidia - most wireless drivers are at least in > part non-free. In my case, it's the madwifi drivers with their binary HAL. > There's also the ipw2100/2200/3945/etc with the non-free firmware. Without The firmwares are not part of the drivers, please do not taint the reputation of perfectly free drivers. -- ciao, Marco signature.asc Description: Digital signature
Re: Debian on the Desktop - plans for Lenny?
Am Mittwoch 08 August 2007 23:02 schrieb Petter Reinholdtsen: > [Julian Andres Klode] > > > We should try to use binary packages provided by linux-modules-* or > > other modules packages by default and fallback to m-a. > > You might want to check out the recent changes to discover and > discover-data. It already had support for installing hardware > specific packages using the discover-pkginstall script, and I added > code to run module-assistant to build the kernel module if the > hardware specific package is supported by module-assistant. I hope it > bring us at least one step closer to automatic driver activation for > out-of-tree kernel modules. Is discover still installed by default on new installs? If yes, is this activated by default? I ask because I would like to get a "no" for both question and a big "NO" if the first question is answered with "yes". HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Luis Matos wrote: > having a console tasksel is not enough ... someone was developing a gtk+ > front end ... right? DEBIAN_FRONTEND=gnome tasksel ? -- see shy jo signature.asc Description: Digital signature
Re: Installation of Recommends by default on October 1st
On Wed August 8 2007 10:01:40 am Daniel Burrows wrote: > Just to clarify, aptitude didn't "come up" with anything. This was > the standard behavior in Debian at the time (dselect was far more > draconian about forcing you to install recommended packages), and one > of the top complaints I got was that aptitude mishandled Recommends > by not installing them! dselect doesn't force you to install recommended packages; for as long as I can remember (since Bo) it has given you a list with the recommends preselected, and a simple keypress is all that is needed to decline them. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
should texmacs on ia64 be removed?
Hi, Currently texmacs depends upon guile-1.8-libs . However guile-1.8 FTBFS on ia64 architecture [1]. According to [2] it is not going to be fixed anytime in the near future. Lilypond, a package which also depends upon guile-1.8-libs faced the same problem. It was removed from ia64 architecture [3] at the request of the maintainer. I am wondering if we should follow the same procedure for texmacs package as well? Another option is to reduce the dependency from guile-1.8-libs to guile-1.6-libs. According to discussion at [4], we do not loose any functionality due to this. What do you say? raju [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401400 [2] http://lists.debian.org/debian-ia64/2006/12/msg00013.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401498 [4] http://lists.texmacs.org/wws/arc/texmacs-users/2007-08/msg0.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
Bruce Sass <[EMAIL PROTECTED]> wrote: > dselect doesn't force you to install recommended packages; for as long > as I can remember (since Bo) it has given you a list with the > recommends preselected, and a simple keypress is all that is needed to > decline them. I'm afraid your memory is not serving you well here. I've been using Debian since the time where slink was in "frozen" state, and I remember very well that I had to wait a few years before being able not to install Recommends. Looking at the changelog, it seems the change (in dpkg trunk, not in stable releases!) dates from November 1999: Sun Nov 28 21:56:32 CET 1999 Wichert Akkerman <[EMAIL PROTECTED]> * dselect/pkgdepcon.cc: don't treat recommends like (pre-)depends. Instead make it similar to suggests but default to selecting the package. For the sake of History, ;-) -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should texmacs on ia64 be removed?
On Thu, Aug 09, 2007 at 01:38:42PM -0400, Kamaraju Kusumanchi wrote: > Another option is to reduce the dependency from guile-1.8-libs to > guile-1.6-libs. According to discussion at [4], we do not loose any > functionality due to this. What do you say? You could use something like: Build-Depends: ..., guile-1.8-dev [!ia64], guile-1.6-dev [ia64], ... Cheers, -- Jeremie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On 8/9/07, Michael Banck <[EMAIL PROTECTED]> wrote: > On Thu, Aug 09, 2007 at 10:27:40AM +0100, Luis Matos wrote: > > Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: > > > Additionally, it should be noted that a desktop task has nothing with > > > multimedia (means: surprise, you can use a desktop without music and > > > movies). > > > > I think we need to have multiple desktop tasks. One desktop-simple, > > desktop-multimedia-support, etc > > This would also simplify the use of tasks to enhance the desktop, like > > desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel > > As long as those are not exposed to the user at installation - fine; for > installation, we should have exactly one desktop task per environment, > and that should installed whatever is needed to give a rather complete > desktop experience, IMHO. That's what we've with desktop, kde-desktop and xfce-desktop and we don't need a pile of new tasks on the installer, yes. Some new tasks to be installed using gnome-app-install or synaptic? Probably, but should be evaluated - wishlist bugs against tasksel with a rationale and list of packages is welcome. Btw, desktop-c-gtk-devel and desktop-python-gtk-devel makes no sense, IMHO. It's too specific that we will need desktop-$every_language_in_debian-gtk-devel. What a task like desktop-php-devel will contain, vim? For those who like emacs are we going to add desktop-php-emacs-devel? Please think about needed use cases (ask debian-user, check popcon, ...) and set of packages that should satisfy that, not some cool random task names. regards, -- stratus http://stratusandtheswirl.blogspot.com get debian @ http://get.debian.net/
Re: Debian on the Desktop - plans for Lenny?
On 8/9/07, Luis Matos <[EMAIL PROTECTED]> wrote: > Qui, 2007-08-09 às 14:10 +0200, Michael Banck escreveu: > > On Thu, Aug 09, 2007 at 10:27:40AM +0100, Luis Matos wrote: > > > Qua, 2007-08-08 às 20:30 +0200, Hendrik Sattler escreveu: > > > > Additionally, it should be noted that a desktop task has nothing with > > > > multimedia (means: surprise, you can use a desktop without music and > > > > movies). > > > > > > I think we need to have multiple desktop tasks. One desktop-simple, > > > desktop-multimedia-support, etc > > > This would also simplify the use of tasks to enhance the desktop, like > > > desktop-c-gtk-devel, desktop-python-gtk-devel, desktop-php-devel > > > > As long as those are not exposed to the user at installation - fine; for > > installation, we should have exactly one desktop task per environment, > > and that should installed whatever is needed to give a rather complete > > desktop experience, IMHO. > > i think that beside the expansion of tasks, the "after install" tasksel > should be improved. > > if we can install a simple desktop and then have some place that the > user can access to install more stuff and easily expand it's > environment. > > having a console tasksel is not enough ... someone was developing a gtk+ > front end ... right? gnome-tasksel was ancient code that I've adopted and asked its removal. You've the tasksel GNOME debconf frontend as cited by Joey Hess and synaptic. I think that the synaptic UI for tasks should be better, but I would like to focus on some task changes before jump on that or even add task support into gnome-app-install that would look cool if we attribute icons for every task (#376635) in a way that it will work for g-a-i, synaptic, and GNOME debconf frontend including d-i. regards, -- stratus http://stratusandtheswirl.blogspot.com get debian @ http://get.debian.net/
Re: Debian on the Desktop - plans for Lenny?
On 8/9/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > Am Mittwoch 08 August 2007 23:02 schrieb Petter Reinholdtsen: > > [Julian Andres Klode] > > > > > We should try to use binary packages provided by linux-modules-* or > > > other modules packages by default and fallback to m-a. > > > > You might want to check out the recent changes to discover and > > discover-data. It already had support for installing hardware > > specific packages using the discover-pkginstall script, and I added > > code to run module-assistant to build the kernel module if the > > hardware specific package is supported by module-assistant. I hope it > > bring us at least one step closer to automatic driver activation for > > out-of-tree kernel modules. > > Is discover still installed by default on new installs? If yes, is this > activated by default? > I ask because I would like to get a "no" for both question and a big "NO" if > the first question is answered with "yes". You've no for both questions with the exception that 'desktop' task installs discover1 we've 2 already packaged. Petter, couldn't we replace discover1 with discover (2) into the desktop task ? Is this a list of supported hardware issue, something else or there's no issue? Btw, it seems that xdebconfigurator already support discover (2) or discover1 but xserver-xorg recommends is on 'discover1 | discover' and in ltsp-client-core we depend on discover1 (not desktop task related though) regards, -- stratus http://stratusandtheswirl.blogspot.com get debian @ http://get.debian.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Thu August 9 2007 12:08:05 pm Florent Rougon wrote: > Bruce Sass <[EMAIL PROTECTED]> wrote: > > dselect doesn't force you to install recommended packages; for as > > long as I can remember (since Bo) it has given you a list with the > > recommends preselected, and a simple keypress is all that is needed > > to decline them. > > I'm afraid your memory is not serving you well here. I've been using > Debian since the time where slink was in "frozen" state, and I > remember very well that I had to wait a few years before being able > not to install Recommends. Looking at the changelog, it seems the > change (in dpkg trunk, not in stable releases!) dates from November > 1999: > > Sun Nov 28 21:56:32 CET 1999 Wichert Akkerman <[EMAIL PROTECTED]> > > * dselect/pkgdepcon.cc: don't treat recommends like (pre-)depends. > Instead make it similar to suggests but default to selecting the > package. > > For the sake of History, ;-) I guess my memory doesn't really go back as far as I thought. Thanks for the correction. :) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
[Hendrik Sattler] > Is discover still installed by default on new installs? Not sure. I suspect it depend on the task being installed. It is currently used to detect which X driver to activate, but that need will go away in the future when X.org manage to configure itself automatically. :) > If yes, is this activated by default? The automatic kernel module source build feature was added to discover a few days ago, so it is to activated anywhere yet. :) > I ask because I would like to get a "no" for both question and a big > "NO" if the first question is answered with "yes". Why? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
[Gustavo Franco] > Petter, couldn't we replace discover1 with discover (2) into the > desktop task ? Actually, we (Otavio an me) plan to replace discover1 with discover for Lenny, so that every user with discover1 will upgrade automatically to discover. > Is this a list of supported hardware issue, something else or > there's no issue? There are two minor issues. One is the lack of architecture specific overrides for a given hardware device, and the other is lack of sbus support. But discover is no longer very useful for loading kernel modules (the programs using the info in /lib/modules/ are doing a better job), so it is not that problematic any more. > Btw, it seems that xdebconfigurator already support discover (2) or > discover1 but xserver-xorg recommends is on 'discover1 | discover' > and in ltsp-client-core we depend on discover1 (not desktop task > related though) I asked the X team to switch to discover v2 before Etch was released, but they decided to postpone it. I hope they are ok with doing it now. I suspect ltsp can switch too. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Simplify installation of non-free? (was: Debian on the Desktop - plans for Lenny?)
I demand that Marco d'Itri may or may not have written... > On Aug 09, Tim Hull <[EMAIL PROTECTED]> wrote: >> It's actually not just ATI/nVidia - most wireless drivers are at least in >> part non-free. In my case, it's the madwifi drivers with their binary >> HAL. There's also the ipw2100/2200/3945/etc with the non-free firmware. > The firmwares are not part of the drivers, please do not taint the > reputation of perfectly free drivers. You want iwl3945. Newer firmware is needed, but you can throw away that user-space daemon. :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output *more* particulate pollutants. BUFFER AGAINST GLOBAL WARMING. Survival of the species is everyone's business. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Am Donnerstag 09 August 2007 21:23 schrieb Petter Reinholdtsen: > [Hendrik Sattler] > > > Is discover still installed by default on new installs? > > Not sure. I suspect it depend on the task being installed. It is > currently used to detect which X driver to activate, but that need > will go away in the future when X.org manage to configure itself > automatically. :) As long as "automatic" doesn't take more time than "using manual settings", that's fine. I doubt that they can detect some of the settings (keyboard layout, driver options), though ;) I appreciate the efforts a lot though, especially a better cooperation of kernel drivers and X, and runtime screens and input device detection. > > If yes, is this activated by default? > > The automatic kernel module source build feature was added to discover > a few days ago, so it is to activated anywhere yet. :) > > > I ask because I would like to get a "no" for both question and a big > > "NO" if the first question is answered with "yes". > > Why? There are still people that like it bit more control. Udev is ok for me but discover goes to far if it automatically installs stuff. You have to draw the line somewhere and that's definitely such a line, at least for me. If it doesn't take any time at boot time and doesn't change my package list, I'll happily try it again. :) Actually I just did and there is not init script installed by default?! Additionally, it probably would reduce detection time if the stuff that udev can handle is skipped. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436982: ITP: ulex0.8 -- OCaml lexer generator with Unicode support - CamlP5 version
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> * Package name: ulex0.8 Version : 0.8 Upstream Author : Alain Frisch <[EMAIL PROTECTED]> * URL : http://www.cduce.org/download.html * License : LGPL Programming Lang: OCaml Description : OCaml lexer generator with Unicode support - CamlP5 version ulex is a lexer generator for the Objective Caml (OCaml) programming language. . It is implemented as a Camlp4 syntax extension: lexer specifications are embedded in regular OCaml code. . Generated lexers work with a new kind of "lexbuf" that supports Unicode; a single lexer can work with arbitrary encodings of the input stream. . This package ships the latest release of ulex compatible with Camlp4 pre OCaml 3.10 (now called CamlP5). Applications which need both ulex and the legacy version of Camlp4 might need to use this package instead of ocaml-ulex (the latter shipping the latest available ulex release which requires Camlp4 >= 3.10)). The package is a repacking of the ulex package which is currently in unstable. For the transition period from OCaml 3.09 to OCaml 3.10, developers are likely to need both the new version of ulex (1.0, which is already in experimental) and the new one (the subject of this ITP). Moreover, some packages which are currently in Debian will FTBFS with OCaml 3.10 without this precise version of ulex, built against camlp5. Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
[Hendrik Sattler] > As long as "automatic" doesn't take more time than "using manual > settings", that's fine. I doubt that they can detect some of the > settings (keyboard layout, driver options), though ;) I appreciate > the efforts a lot though, especially a better cooperation of kernel > drivers and X, and runtime screens and input device detection. discover is used to feed default values into the debconf questions asked about X configuration when the xserver-xorg package is installed. The keyboard layout, driver options etc, are not using values fetched from discover. There is work going on to let the X drivers themself expose information on their supported hardware, and use this information to automatically configure X. It will make the X config use of discover obsolete. > There are still people that like it bit more control. Udev is ok for > me but discover goes to far if it automatically installs stuff. You > have to draw the line somewhere and that's definitely such a line, > at least for me. Why? Tasksel install a lot of stuff automatically during the system installation. Is it bad too? > If it doesn't take any time at boot time and doesn't change my > package list, I'll happily try it again. :) Actually I just did and > there is not init script installed by default?! Additionally, it > probably would reduce detection time if the stuff that udev can > handle is skipped. I get the impression that you are talking about boot time? I am talking about the Debian installer and behavior at install time. discover is not used at boot time, and have not been providing a init.d script since before Etch was released. Kernel module loading at boot time is better left to the systems reading /lib/modules/ (udev at the moment), so that part was disabled in discover. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Wed, 2007-08-08 at 11:20 -0400, Tim Hull wrote: > > We already have this on the desktop, from what I can > see (there is evidence of a > scaling-module-loading-thingummy running on boot) > > Yes, it loads, but the default scaling governor is set to "userspace". > As powernowd isn't included in the desktop task, this effectly means > no CPU scaling by default. laptop-mode sets the CPU frequency, but it only switches based on whether you have AC power, not based on how busy the CPU is. "ondemand" would be more useful. I don't know whether the correct scaling driver is loaded automatically; I fear not. This might be a job for discover. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Re: Simplify installation of non-free? (was: Debian on the Desktop - plans for Lenny?)
On 09/08/07, Don Armstrong <[EMAIL PROTECTED]> wrote:
>
> The objection is making it a priority over supporting free drivers or
> diverting people working on supporting vendors who provide DFSG free
> drivers by making it a distribution wide priority.
The free drivers are perfectly well supported as they are, and are
excellently maintained by a vast number of talented people from many
projects. The non-free ones are god-awful as a simple result of them being
closed source, and their installation and use can be calamatous for many,
and hence they require special coddling, methinks I am not in favour of
favouring anything over free software - if it were up to me, I'd just buy
one of Intel's excellent and proper-game-capable GPUs (which obviously I
can't, because they don't make any) - but once we have got over the fairly
simple hurdle of enforced freedom the issue just turns into a question of
how to make non-free drivers less nightmarish to install.
Since you appear to be interested in it quite a bit, you'd be well served by
> making it your priority.
I'm grossly underqualied in that respect, I fear. I can outline precisely
what needs to be done to make nvidia-glx, for example, bearable[1] (and it
does not involve a specialised GUI, god forbid) but am in no position at all
to do so :(
--
Ben Goodger
B.F. Goodger, Age 16½
[1] metapackage "nvidia-graphics-nonfree" or similar to not conflict with
the similarly named source package, to depend on nvidia-glx and the current
nvidia-kernel-{uname -r} and other appropriate packages, and a moderately
intelligent post-install script to parse /etc/X11/xorg.conf for the
appropriate settings and flag suspicious lines, with references to
appropriate wiki/man pages... eventually, this should become an "aptitude
install nvidia-graphics-nonfree" situation, without manual
xorg.conffiddling, and without bludgeoning the entire system
Automatix-style (may
require many weeks of tedious regexen, but it would IMO be worth it to Do
Things Properly, as is the Debian way.)
Re: Debian on the Desktop - plans for Lenny?
On 8/9/07, Ben Hutchings <[EMAIL PROTECTED]> wrote: > On Wed, 2007-08-08 at 11:20 -0400, Tim Hull wrote: > > > > We already have this on the desktop, from what I can > > see (there is evidence of a > > scaling-module-loading-thingummy running on boot) > > > > Yes, it loads, but the default scaling governor is set to "userspace". > > As powernowd isn't included in the desktop task, this effectly means > > no CPU scaling by default. > > > laptop-mode sets the CPU frequency, but it only switches based on > whether you have AC power, not based on how busy the CPU is. "ondemand" > would be more useful. I don't know whether the correct scaling driver > is loaded automatically; I fear not. This might be a job for discover. Hi Ben, laptop-mode-tools conf uses 'ondemand' (1.34-1, but I think it was already in etch), and my ibook g4 using the default desktop environment task and laptop task scales well. What's missing for yours or we've different default configuration for some strange reason? regards, -- stratus http://stratusandtheswirl.blogspot.com get debian @ http://get.debian.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On 09/08/07, Luis Matos <[EMAIL PROTECTED]> wrote: > > having a console tasksel is not enough ... someone was developing a gtk+ > front end ... right? running "tasksel --new-install" gets you a debconf window, which is either curses, gtk, qt etc depending on your debconf conf. -- Ben Goodger B.F. Goodger, Age 16½
Re: Debian on the Desktop - plans for Lenny?
Petter Reinholdtsen schrieb: > > I get the impression that you are talking about boot time? I am > talking about the Debian installer and behavior at install time. > discover is not used at boot time, and have not been providing a > init.d script since before Etch was released. Kernel module loading > at boot time is better left to the systems reading /lib/modules/ (udev > at the moment), so that part was disabled in discover. Which sounds like a sane behaviour for discover(2) as I always felt that udev and discover(1) had quite a overlap and it was one of the first packages I uninstalled. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Simplify installation of non-free? (was: Debian on the Desktop - plans for Lenny?)
On Thu, 09 Aug 2007, Ben Goodger wrote: > I can outline precisely what needs to be done to make nvidia-glx, > for example, bearable[1] (and it does not involve a specialised GUI, > god forbid) but am in no position at all to do so :( Sure you are! Outlining exactly what needs to be done and filing bugs with suggested implementations on the involved packages, and then working on actually getting those changes made and submitting packages that make them to the limit of your ability (and then extending your ability) is exactly the position you are in. Don Armstrong -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Thu, 2007-08-09 at 18:37 -0300, Gustavo Franco wrote: > On 8/9/07, Ben Hutchings <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-08-08 at 11:20 -0400, Tim Hull wrote: > > > > > > We already have this on the desktop, from what I can > > > see (there is evidence of a > > > scaling-module-loading-thingummy running on boot) > > > > > > Yes, it loads, but the default scaling governor is set to "userspace". > > > As powernowd isn't included in the desktop task, this effectly means > > > no CPU scaling by default. > > > > > > laptop-mode sets the CPU frequency, but it only switches based on > > whether you have AC power, not based on how busy the CPU is. "ondemand" > > would be more useful. I don't know whether the correct scaling driver > > is loaded automatically; I fear not. This might be a job for discover. > > Hi Ben, > > laptop-mode-tools conf uses 'ondemand' (1.34-1, but I think it was > already in etch), and my ibook g4 using the default desktop > environment task and laptop task scales well. What's missing for yours > or we've different default configuration for some strange reason? My information is based on an earlier version when I uninstalled when I realised it was useless. The current version is indeed better. However, it still has some bad defaults, in my opinion: ENABLE_LAPTOP_MODE_ON_AC=0 BATT_CPU_MAXFREQ=medium NOLM_AC_CPU_GOVERNOR=performance This means that when draining the battery we do not allow the CPU to run at full speed, so CPU-bound tasks take longer. This tends to extend battery life but reduces the processing work derived from the battery, since other components then take a higher share of power. And when running on AC, we just waste power, though with a slight performance gain. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Re: Debian on the Desktop - plans for Lenny?
Qui, 2007-08-09 às 15:24 -0300, Gustavo Franco escreveu: > Btw, desktop-c-gtk-devel and desktop-python-gtk-devel makes no sense, > IMHO. It's too specific that we will need > desktop-$every_language_in_debian-gtk-devel. What a task like > desktop-php-devel will contain, vim? For those who like emacs are we > going to add desktop-php-emacs-devel? Please think about needed use > cases (ask debian-user, check popcon, ...) and set of packages that > should satisfy that, not some cool random task names. this was discussed a long time ago ... i am going to make a proposal. these tasks are useful for inexperienced developers, because not all developers have skills to search for a good IDE for some language. I want to propose sometime during lenny development cycle some developer oriented tasks. something like an apt-get install gnome-devel but ina task sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Qui, 2007-08-09 às 10:42 -0700, Joey Hess escreveu: > Luis Matos wrote: > > having a console tasksel is not enough ... someone was developing a gtk+ > > front end ... right? > > DEBIAN_FRONTEND=gnome tasksel ? > that's a pretty hack ... why does tasksel does not get the debconf option on which front end to use? ... but anyway, this tasksel ould be improved with some extra options ... i know, however that that's not easy to expand the tasksel because it is based in debconf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Simplify installation of non-free?
On Fri, 2007-08-10 at 10:00 +1000, Ben Finney wrote: > If any person wants to spend their efforts to work on particular > software, the Debian project should not throw obstacles in their way, > but asking the Debian project to actively help is going too far. And even way more far is to asking the Debian project to do it completely. -- David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/ Respeto a Nicaragua y a la lucha sandinista. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Simplify installation of non-free? (was: Debian on the Desktop - plans for Lenny?)
On Thu, Aug 09, 2007 at 10:34:01PM +0100, Ben Goodger wrote: >I'm grossly underqualied in that respect, I fear. I can outline precisely >what needs to be done to make nvidia-glx, for example, bearable[1] (and it >does not involve a specialised GUI, god forbid) but am in no position at >all to do so :( You'd be much more useful if you put some work in to helping get nouveau in to Debian. The many people who've volunteered to help on it have totally failed to move on it in any visible way. As for being in no position to do so, if you want to get started, the XSF is ready to offer any sort of assistance that we can to make it happen, so you're in as much a position as anyone else with Nvidia hardware to make a Free 3D driver for Nvidia cards enter Debian. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Simplify installation of non-free?
"Ben Goodger" <[EMAIL PROTECTED]> writes: > On 09/08/07, Don Armstrong <[EMAIL PROTECTED]> wrote: > > The objection is making it a priority over supporting free drivers > > or diverting people working on supporting vendors who provide DFSG > > free drivers by making it a distribution wide priority. > > The free drivers are perfectly well supported as they are, and are > excellently maintained by a vast number of talented people from many > projects. The non-free ones are god-awful as a simple result of them > being closed source, and their installation and use can be > calamatous for many, and hence they require special coddling, > methinks None of this is an argument for making non-free software any kind of priority for the Debian project. It merely highlights the situation non-free developers and users have chosen for themselves. If any person wants to spend their efforts to work on particular software, the Debian project should not throw obstacles in their way, but asking the Debian project to actively help is going too far. -- \"Choose mnemonic identifiers. If you can't remember what | `\ mnemonic means, you've got a problem." -- Larry Wall | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
On Thu, Aug 09, 2007 at 09:08:00PM +0200, Petter Reinholdtsen wrote: > [Gustavo Franco] > > Btw, it seems that xdebconfigurator already support discover (2) or > > discover1 but xserver-xorg recommends is on 'discover1 | discover' > > and in ltsp-client-core we depend on discover1 (not desktop task > > related though) > > I asked the X team to switch to discover v2 before Etch was released, > but they decided to postpone it. I hope they are ok with doing it > now. I suspect ltsp can switch too. We're in the process of getting rid of the X server's need for discover right now. I'm almost positive that this will be ready for lenny, so whatever decisions you want to be made wrt discover won't have to take the X server in to account. Similarly, xdebconfigurator should almost certaintly go away for lenny. The X server should already do autoconfig without an xorg.conf in most situations better than anything xdebconfigurator is likely to come up with, and by the time lenny ships we'll be kicking the old statically generated xorg.confs like nobody's business. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, 2007-08-07 at 05:04 +0200, David Lopez Zajara (Er_Maqui) wrote: > xmms have 11000+ popcon installations reported. The total reports of > popcon are 57000+. This is aprox 20% of users. Now, are talking for > removal an application for those users?... > > I've read the buglist of xmms, and i think who more than one and two > bugs can be removed. Example of this can are #244984, #260754, #161702. > A lot of these bugs are already opened because the version doesn't have > changed (Are revised). I think who can be interesting revise the xmms > buglist and close the outdated bugs, for a real information of > application problems. > > > I've read in this thread, this is for a orphan package. If this is the > reason, doesnt have much more for talk, another mantainer will become. > xmms its a very popular package. I think who an orphan isn't a reason at > all for removal from arch. It clearly seems that you haven't read the whole thread. Your understanding of the only argument for removing xmms being that it's orphaned and your understanding of the only argument for keeping xmms being that it's popular clearly shows your misread of the whole log on the discussion. -- David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/ Le dije "man, ya estás muy pasado".
Re: Debian on the Desktop - plans for Lenny?
On Thu, Aug 09, 2007 at 10:45:32PM +0200, Hendrik Sattler wrote: > Am Donnerstag 09 August 2007 21:23 schrieb Petter Reinholdtsen: > > Not sure. I suspect it depend on the task being installed. It is > > currently used to detect which X driver to activate, but that need > > will go away in the future when X.org manage to configure itself > > automatically. :) > > As long as "automatic" doesn't take more time than "using manual settings", > that's fine. I doubt that they can detect some of the settings (keyboard > layout, driver options), though ;) Obviously we can't automatically do everything or else there wouldn't be a need for options. But we should do a good enough job to get you up and running and let you configure what you need from there. It might take slightly more time in some cases, but the idea would be to optimize it so that it runs just as fast as currently, or better. Generally, the stuff you're waiting for when the X server starts are going to happen whether or not you're parsing a static xorg.conf, so you shouldn't really lose much by switching to something fully dynamic. It's something I'm thinking about a bit, but my goal is to take care of doing autoconfig properly first, and then optimize it later. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've read the complete thread, and i understand who the main reason from the mantainers are these. But, in the other hand, have the reason of gtk1.2 removal porposal. I understand this, but, i say who of the given reasons are incorrect. Too, i say who the package are really popular, and doesnt exist an real replace for this, because the similar packages are too new packages. Simply you can read this thread and can find a report of audacious (main candidate for xmms replace) crashing on a max time of 2 minutes running. And, the another candidates, are for example, xmms2, a stream server who in debian only have a VERY simply interface (without really functionality in comparation of xmms), or the console-client, who doesn't are a replace at all. David Moreno Garza wrote: > On Tue, 2007-08-07 at 05:04 +0200, David Lopez Zajara (Er_Maqui) wrote: >> xmms have 11000+ popcon installations reported. The total reports of >> popcon are 57000+. This is aprox 20% of users. Now, are talking for >> removal an application for those users?... >> >> I've read the buglist of xmms, and i think who more than one and two >> bugs can be removed. Example of this can are #244984, #260754, #161702. >> A lot of these bugs are already opened because the version doesn't have >> changed (Are revised). I think who can be interesting revise the xmms >> buglist and close the outdated bugs, for a real information of >> application problems. >> >> >> I've read in this thread, this is for a orphan package. If this is the >> reason, doesnt have much more for talk, another mantainer will become. >> xmms its a very popular package. I think who an orphan isn't a reason at >> all for removal from arch. > > It clearly seems that you haven't read the whole thread. Your > understanding of the only argument for removing xmms being that it's > orphaned and your understanding of the only argument for keeping xmms > being that it's popular clearly shows your misread of the whole log on > the discussion. > > -- > David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/ > Le dije "man, ya estás muy pasado". > > > - -- [EMAIL PROTECTED] || http://maqui.darkbolt.net Linux registered user number: #363219 PGP key avaliable at KeyServ. KeyID: 0x4233E9F2 - -- Los hombres somos esclavos de la historia -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGu9IHfFjA4EIz6fIRAh8fAKCQ9h7esLVSihWyePKF+fYYI0IYmwCdHBcG inOc7kCnaDr1Op/qLAGr94Q= =PoDD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Ben Hutchings <[EMAIL PROTECTED]> wrote: > This means that when draining the battery we do not allow the CPU to run > at full speed, so CPU-bound tasks take longer. This tends to extend > battery life but reduces the processing work derived from the battery, > since other components then take a higher share of power. And when > running on AC, we just waste power, though with a slight performance > gain. If you're using the computer at all, it's not even likely to increase battery life. A CPU at 600MHz and in C0 will draw significantly more power than a CPU at 1.2GHz but in C4. It's more important to finish whatever the CPU is doing quickly than it is to keep it at a low speed. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Aug 10, 2007
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 387 (new: 7) Total number of packages offered up for adoption: 76 (new: 1) Total number of packages requested help for: 38 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: dlisp (#435896), orphaned 6 days ago Description: Simplistic lisp type file parser Reverse Depends: dmachinemon dmachinemon-master dmachinemon-servent dmachinemon-treeview libdlisp0-dev libdmsocket-0.32.5-0 libdmsocket-0.32.5-0-dev libdnas-application-0.32.5-0 libdnas-application-0.32.5-0-dev libdnas-core-0.32.5-0 (2 more omitted) Installations reported by Popcon: 79 eagle-usb (#436036), orphaned 5 days ago Description: Data for Eagle USB ADSL modems Reverse Depends: eagle-usb-utils Installations reported by Popcon: 27 elpoint (#436426), orphaned 2 days ago Description: Yet another presentation tool on Emacsen Installations reported by Popcon: 47 qemacs (#435947), orphaned 5 days ago Description: Small emacs clone editor with HTML and DocBook editing support Installations reported by Popcon: 135 update-cluster (#435897), orphaned 6 days ago Description: System to update configuration files for clusters automatically Reverse Depends: update-cluster-hosts Installations reported by Popcon: 91 xphoon (#435898), orphaned 6 days ago Description: sets the root window to a picture of the moon Installations reported by Popcon: 140 xzoom (#435900), orphaned 6 days ago Description: magnify part of X display, with real-time updates Installations reported by Popcon: 273 380 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: clig (#436077), offered 4 days ago Description: Command Line Interpreter Generator Installations reported by Popcon: 65 75 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] mol (#436450), requested 2 days ago Description: The Mac-on-Linux emulator Reverse Depends: mol-drivers-linux mol-drivers-macos mol-drivers-macosx mol-modules-source Installations reported by Popcon: 61 aboot (#315592), requested 777 days ago Description: Alpha bootloader: Looking for co-maintainers Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core Installations reported by Popcon: 102 apt-build (#365427), requested 467 days ago Description: Need new developer(s) Installations reported by Popcon: 811 apt-cacher (#403584), requested 234 days ago Description: caching proxy system for Debian package and source files Installations reported by Popcon: 351 apt-show-versions (#382026), requested 366 days ago Description: lists available package versions with distribution Installations reported by Popcon: 2783 athcool (#278442), requested 1017 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 279 cvs (#354176), requested 532 days ago Description: Concurrent Versions System Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (17 more omitted) Installations reported by Popcon: 18838 dpkg (#282283), requested 992 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc build-essential bzr-builddeb clamsmtp crosshurd (87 more omitted) Installations reported by Popcon: 57518 dsniff (#430162), requested 48 days ago Description: Various tools to sniff network traffic for cleartext insecurities Installations reported by Popcon: 963 elvis (#432298), requested 31 days ago Description: powerful clone of the vi/ex text editor (with X11 support) Reverse Depends: elvis elvis-console elvis-tools Installations reported by Popcon: 264 gentoo (#422498), requested 95 days ago Description: a fully GUI-configurable, two-pane X file manager Installations reported by Popcon: 257 grub (#248397), requested 1186 days ago Description: GRand Unified Bootloader Reverse Depends: dfsbuild replicator Installations reported by Popcon:
conflicting gssapi libraries
[4 letter words deleted] === cut === # sudo dpkg -i libgssapi2-heimdal_1.0.1-1_i386.deb ──(Fri,Aug10)─┘ Selecting previously deselected package libgssapi2-heimdal. (Reading database ... 188542 files and directories currently installed.) Unpacking libgssapi2-heimdal (from libgssapi2-heimdal_1.0.1-1_i386.deb) ... dpkg: error processing libgssapi2-heimdal_1.0.1-1_i386.deb (--install): trying to overwrite `/usr/lib/libgssapi.so.2.0.0', which is also in package libgssapi2 Errors were encountered while processing: libgssapi2-heimdal_1.0.1-1_i386.deb === cut === [more 4 letter words deleted] This wasn't a problem until just recently because it use to be libgssapi.so.1.0.0 in Heimdal. Solution? -- Brian May <[EMAIL PROTECTED]>
