Re: Request for virtual package ircd
> "Michael" == Michael Poole <[EMAIL PROTECTED]> writes: Michael> Why do you think these servers conflict with each other? ... because, generally speaking, the servers will be automatically installed at installation, and if the port is in use, then installation may fail. Also, the server to grab the port first on reboot is largely undefined. Debian really needs infrastructure to manage TCP and UDP ports. Perhaps a bit like update-alternatives, but for ports, not files. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
Mario Iseli <[EMAIL PROTECTED]> writes: > On Thu, Oct 12, 2006 at 12:38:03AM +0200, Hendrik Sattler wrote: >> Wouldn't "relay-chat-server" or "relay-chat-daemon" be a better name. > > I think no, we also call it "httpd" and not "web-server" or > "hypertext-transfer-protocol-server". That's a historical inconsistency which is at odds with the naming scheme used by all the other virtual packages. "relay-chat-server" would fit in with the scheme much better. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgppqvW8Gh1Z0.pgp Description: PGP signature
Re: Starting services in runlevels 0 and 6
Le jeudi 12 octobre 2006 à 20:33 -0700, Jurij Smakov a écrit : > It was pointed out to me, that even the scripts starting with S are > called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc. > However, the reason why it is implemented that way is still not clear. IIRC, it is so that they are executed after the scripts starting with K. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Starting services in runlevels 0 and 6
[Henrique de Moraes Holschuh] > On Thu, 12 Oct 2006, Jurij Smakov wrote: >> It was pointed out to me, that even the scripts starting with S are >> called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc. >> However, the reason why it is implemented that way is still not clear. > > Braindamage inherited from SysV. Yes, historical reasons. And it isn't even required. SuSe for example only store K* type symlinks in those directories, instead of handling them specially. We can do the same, if we switch to a dependency based init.d system, but the current symlinks need to be renamed when that happen. The insserv package provide a script to do this while it reorders the boot sequence based on the LSB header dependency info. It is not enough to just rename them, as all postinst script call update-rc.d with other assumptions, and the shutdown order will be wrong unless the sequence numbers are changed as well. The brave can try to install insserv and run BAD_INSSERV_HACKER=true dpkg-reconfigure insserv to enable the dependency based boot. But remember, if it break you get to keep both the pieces. Running it again and disabling the dependency based boot might be possible, but there is no guarantee. The reason this might break is that several init.d scripts are missing dependency information, so the boot order generated by insserv might be incorrect. insserv include override files for some of these scripts, for the base system and a normal desktop install, but there are probably hundred of init.d scripts without known dependency info. I use it myself on one of my test machines, and it works for me. But I have added override files for the packages I use. :) I would like us to switch to a dependency based boot sequence system after Etch. First all init.d scripts need to include dependency info. Next, we need to locate and fix any dependency loops. Last we can automate the switch to dependency based sequencing, possible only on new installations and when the system administrator decide to convert. The nice thing about documenting dependencies is that we can automatically detect bugs in the current boot sequence. We already found and fixed a few of those with the info currently in the packages. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Build failure: cannot find -lglib-2.0
A number of packages currently fail to build with: /usr/bin/ld: cannot find -lglib-2.0 Can someone please investigate whether this is a bug in those packages or some underlying problem and file bugs. I've put some buid logs at http://people.debian.org/~tbm/logs/glib.bz2 -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-findremovable v0.1 (initial release)
On Sat, 7 Oct 2006 18:32:08 +0200, Michelle Konzack <[EMAIL PROTECTED]> wrote: >Am 2006-10-06 18:06:47, schrieb Mikhail Gusarov: >> Do aptitude checks terminal even for 'aptitude install' or 'aptitude >> search'? > >Good question! The two offending Servers use Monocrom-Graficcards. >Maybe aptitude can not enter a colormode and crash? I thought that you were using ssh? How can the local display of a machine affect incoming ssh sessions? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
On Tue, 10 Oct 2006 13:44:57 +0200, Reinhard Tartler <[EMAIL PROTECTED]> wrote: >If we cannot expect that, perhaps we should advertise the existance of >those README.Debian files better. I would be interested in how exim4 can advertise its README.Debian any better, short paying for google adwords. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
On Tue, 10 Oct 2006 19:30:52 -0700, Don Armstrong <[EMAIL PROTECTED]> wrote: >So have a note in exim4's debconf which tells the users that, and only >display the note if DEBCONF_RECONFIGURE=1 or $1='reconfigure'. That is what I did for the exim4 package uploaded on Tuesday. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
On Tue, 10 Oct 2006 22:05:07 +0200, Frank Küster <[EMAIL PROTECTED]> wrote: >In that case, where the problem is that people do *not* read these >files, and "dpkg-reconfigure exim4" exits silently without doing >anything, it seems to be ideal. Explain that please. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#392721: ITP: pyecm -- Number factorization with the Elliptic Curve Method (ECM)
Package: wnpp Severity: wishlist Owner: Martin Kelly <[EMAIL PROTECTED]> * Package name: pyecm Version : 0.1 Upstream Author : Martin Kelly <[EMAIL PROTECTED]> * URL : http://www.sourceforge.net/projects/pyecm/ * License : GPL Programming Lang: Python Description : Number factorization with the Elliptic Curve Method (ECM) pyecm is a python program to factor numbers using the Elliptic Curve Method (ECM). It is relatively fast in that it can quickly factors numbers up to 50 digits. pyecm seems to be faster than gmp-ecm on many tests and is much more portable (it's written in python). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Response to your ListGuru session [MsgId AA20061012.223301.4]
-- Hello! Unrecognized command -- skipping. Use HELP for assistance. Please have a look at the diggest. Unrecognized command -- skipping. Use HELP for assistance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
Gabor Gombas wrote:
> On Mon, Oct 09, 2006 at 01:44:00AM +0200, Michael Biebl wrote:
>
>> We don't really need the ability to install *multiple* init systems in
>> parallel imho
>
> Yes we do, for the same reason we allow multiple kernel images to be
> installed simultaneously: if the new one does not work, there should be
The kernel is different.
First, they are no conflicting binaries.
Second, the feature set of init is very limited and controlled by the
package maintainer whereas the kernel is much more complex. You can
never know if a user messes up it's .config and e.g. forgets to compile
in the root fs driver.
> a way to boot with the old version to fix things up. Especially if you
> want testers. There's no way I'm personally going to try upstart if I
> see no easy way ('easy' means adding a kernel parameter in the grub
> menu, but definitely no rescue CD or such) to go back to sysvinit in
> case the system fails to boot.
init=/bin/sh?
I know it's not a complete rescue mode, but you'd still be able to boot
the system, mount / rw and fix the problem.
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: how to tell people to dpkg-reconfigure exim4-_CONFIG_?
Marc Haber <[EMAIL PROTECTED]> wrote: > On Tue, 10 Oct 2006 22:05:07 +0200, Frank Küster <[EMAIL PROTECTED]> > wrote: >>In that case, where the problem is that people do *not* read these >>files, and "dpkg-reconfigure exim4" exits silently without doing >>anything, it seems to be ideal. > > Explain that please. I just imagined someone doing # dpkg-reconfigure exim4 # compared to # dpkg-reconfigure exim4 Please use dpkg-reconfigure exim4-config instead! # However, although this looks simple and short, it doesn't take into account the various possible ways to access debconf, and it won't work at all if a package manager has a "reconfigure this package" button. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Request for virtual package ircd
Brian May writes: >> "Michael" == Michael Poole <[EMAIL PROTECTED]> writes: > > Michael> Why do you think these servers conflict with each other? > > ... because, generally speaking, the servers will be automatically > installed at installation, and if the port is in use, then > installation may fail. Also, the server to grab the port first on > reboot is largely undefined. Arguably, starting an IRC server with no user input is a bad idea. For better or worse, IRC servers need a lot of site-local configuration. Otherwise they cannot connect to other servers, the administrator cannot perform oper commands, and so forth. Separately, if port conflicts are worthy of Conflicts:, why do web servers not in general conflict with each other? You can install apache, aolserver, boa, caudium, and probably others on the same machine. On the DNS side, you can install bind, maradns and nsd on the same machine. Given how easy it is to make two IRC, HTTP or DNS servers work sanely side by side, Conflicts between them seem likely to cause more trouble than they save. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
incoming locked?
Hi, I uploaded a version of my roundup package some two days ago which cleans up important bugs. The package page shows the upload on 2006-10-11, but when searching for it on w.d.o/packages, I get only an older version which *has* bugs. Any chance that the fixed version gets into Etch? http://packages.qa.debian.org/r/roundup.html http://packages.debian.org/cgi-bin/search_packages.pl?searchon=sourcenames&version=all&exact=1&keywords=roundup Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning most of my packages
On Fri, Oct 13, 2006 at 01:02:49AM -0400, Anthony DeRobertis wrote: > Steve Greenland wrote: > > Bug#392672: O: positron - synchronization manager for the Neuros Audio > > Computer Python. Probably dead after v1.1. Pierre Habouzit has NMU'd a > > version 1.1 upgrade and support for new python policy, see bug # 380895. > I can confirm that Positron is dead. Not only is it dead, it isn't > compatible with newer Neuros firmware. Sorune (Perl) and NDBM (Java) are > the two not-dead replacements. > > I suggest removal. Agreed. I use NDBM and it has worked better for me than positron since day 1, and it does continue to see updates. It'd be nice to have NDBM packaged for Debian and in the archive (though not critical, since jar files are easy enough to deal with) if someone with java skillz is interested. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
position statement from the kernel team over the current non-free firmware GR vote (Was: Call for votes for "GR: : Handling source-less firmware in the Linux kernel")
Hello, The kernel team consider that neither of the two proposals currently under vote [1] are a good solution to the non-free firmware problem. Furthermore, a consensual proposal has now reached enough seconds [2] to be put to vote, and is much preferable, both in clearness of text as in actual content. The proposal made by Josselin (Choice 2) will have a hard time to pass, as it needs 3:1 supermajority. It gives a longer term exception for firmwares beyond the etch release, which we believe not being necessary, and furthermore, it is an amendment to the original proposal from Steve, now withdrawn, and is thus less clean. The proposal originally from Frederik as amended by Manoj (Choice 1) has serious issues. It doesn't correspond to the wish of the kernel team, as expressed by the position statement at [3] following the kernel team meeting about the firmware issue. This proposal is titled : "Choice 1: Release Etch even with kernel firmware issues" but this is highly misleading, since the actual proposal in many ways contradicts this. The proposal states : 1. It forces us to not release as part of etch those firmwares removed in sarge, which include popular drivers used for installation as tg3 and acenic (Point 3.). 2. It means illegal to distribute firmwares will have to go (good), altough it is silent about the sourceless GPL ones (Point 4.). 3. It means we will not distribute firmwares with non-DFSG free licenses (Point 4.). This is highly confusing, because the distinction is made on the licenses, and not on the actual freeness, and it thus favours firmwares under free licenses, but not respecting the terms of the licenses, over those firmwares whose copyright holder has clarified their licensing, like broadcom did for the tg3 license. Furthermore, the current choice 1, which will allow to ship sourceless GPLed firmwares, should have needed a 3:1 supermajority, as it directly contradicts the DFSG. For all these reasons, the kernel team believes that the solution proposed at [3], and which already reached enough seconds, and will thus be needed to be voted on, is a better solution, and since it is not possible anymore to amend the current ballot, we urge all voters to vote "Further Discussion", and allow for the recast of a new ballot containing the better solution, and possible other amendments (like a rewording of Josselin's proposal on top of the consensual proposal for example). On behalf of the Debian Kernel Team, Friendly, Sven Luther [1] - http://www.debian.org/vote/2006/vote_007 [2] - http://lists.debian.org/debian-vote/2006/10/msg00183.html [3] - http://wiki.debian.org/KernelFirmwareLicensing#head-98e7641feaea08b775f4d5c58d071b77ff172c90 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help offered 2 - opinion wanted about debian.org
HXC wrote: I also wondered what the community finds about the colours and layout used for the website Does it need to be upgraded? Do find a new layout or other colours more appealing? If so what do you have in mind? Or do you think the current theme is just fine? The current theme and colors are superb, excellent, etc. It's one of the best websites I have ever visited. It's not overloaded with colors and images; it doesn't need java or any special plugins just to demonstrate that the developers are capable and that they don't care about users with only the second latest browser technology (or slow internet connections). Most importantly the pages are intuitive, clear, easy to navigate and comply to "Valid HTML 4.01 Strict"! (I really hate all those sites that override my font settings to display all their content in little fonts--even more those that fail to render correctly when I manually increase the font size.) Thanks to the maintainers of the present site. They do an excellent job! Just my opinion, Johannes NB: This doesn't mean that the pages cannot be improved. I guess one could add to the documentation and introduction for new users. If you would like to do some graphics work, you could look at http://www.de.debian.org/CD/artwork/ and work on logos and CD covers for the upcomming etch release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lack of transparency of automatic actions
Hello, This has been bugging me for some time now, and I'd like to see if we can improve the situation. The main problem is that it's not clear how all this media autodection/automounting works. It's not clear how to enable it, it's not clear how the permissions work, and it's not clear how to manage it. Let's start from the worst scenario: a system administrator. Traditionally, to know who can mount a device, you can look at /etc/fstab: if something is marked "user", then a user can mount it. You can also look at the permissions of the entry in /dev to see if a user can access it directly. Now, apparently, if a user is in the plugdev group, then that user could mount it even if it appears nowhere in fstab and even if the user doesn't have access to the /dev entry. But this isn't documented anywhere obvious, certainly. It should be in big capital letters somewhere. Next, what about from the user's perspective? By default, when you add a user, that user is not a member of plugdev, so these things don't work. Gnome warns you that you need to be a member in some cases; KDE doesn't. It would be nice for KDE to do that. It's also not clear how it reacts to devices that are in fstab, or how to make it shut up about stuff. One annoying bug with Gnome was that it would see my cryptsetup partition -- which was accessed on boot, and which had the LVM LVs mounted at boot -- and prompt me for the password to try to access it again. (That one could lead to data corruption.) KDE never did that. But worse -- what if you're not using Gnome or KDE? I can find no way for a user that doesn't use any X applications to take advantage of this automatic support, even if the user is in the plugdev group. I can't even find a way for a user to take advantage of it manually, again even if the user is in plugdev. Why are we restricing this to users of GUIs? Now, what about networking? We have two competing systems: ifupdown and network-manager. ifupdown works fine for static servers or workstations, but it doesn't do any of the automatic network scanning and connecting that network-manager does. It's great to have those network-manager features -- automatically bringing up eth0 when a cable is plugged in, automatically connecting to a known wireless network, etc. But network-manager only works for interfaces that don't have things specified in /etc/network/interfaces. So I can't tell it to run an iwpriv command on my wireless card before scanning for networks. Even worse, you again have to use KDE or Gnome to take advantage of network-manager. Why are we leaving CLI users out in the cold? It is quite possible to use mutt, ssh, and ftp on a laptop. And it's frustrating to know that my network setup will be useless when I'm not running in X. Moreover, it is completely unclear how permissions for taking network devices up and down are managed in this scenario. Ordinarily, only root can do that, but now we're apparently letting anyone. How can we restrict that? But more important than answering the question here is to document all of this in a comprehensive place, obviously visible to users and admins. The bottom line is that I think we have some useful functionality here, but our implementation needs work. It would be very nice to have these issues ironed out before etch. Thanks, -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for virtual package ircd
Russ Allbery writes ("Re: Request for virtual package ircd"):
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > m-t-a's must conflict because they are required by policy to provide a
> > sendmail program at a fixed filesystem location.
>
> I was about to say the same thing earlier, but then realized that we
> *could* deal with that via alternatives. And there's actually some appeal
> to that in some very limited situations.
When I changed from smail to exim on chiark, I used --force-conflicts
to install both, so that smail could empty its queue while exim
handled new messages. This worked rather well.
I have no idea whether it would work nowadays; things are always much
more complicated now ...
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
want to contribute
I am using debian linux for quite some time and quite impress by it. I want to contribute to its development . Please give me some pointers . I looked at website , it not quite clear how to start Arvind
Re: Starting services in runlevels 0 and 6
Hello Jurij, Jurij Smakov <[EMAIL PROTECTED]> wrote: > On Thu, Oct 12, 2006 at 07:34:19PM -0700, Jurij Smakov wrote: >> /etc/rc0.d/S30urandom >> /etc/rc0.d/S35networking >> /etc/rc0.d/S36ifupdown >> /etc/rc0.d/S37sendsigs (start action for this one is a no-op) >> /etc/rc0.d/S48cryptdisks >> /etc/rc0.d/S59cryptdisks-early >> >> and similar stuff in /etc/rc6.d. I cannot find a rational explanation >> for starting services right before shutdown. Is it intentional, or are >> those just bugs? > > It was pointed out to me, that even the scripts starting with S are > called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc. > However, the reason why it is implemented that way is still not clear. Because the S scripts are run after the K scripts. This way it is possible to run special scripts at very last. Bye, Jörg. -- Life can only be understood backwards, but it must be lived forwards. (Soren Kierkegaard) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
On Friday 13 October 2006 09:18, John Goerzen wrote: > Why are we leaving CLI users out in the cold? I would guess that no one has developed the requisite components for a CLI interface. This is clearly something that no developers (Debian or otherwise) have picked up as an important or fun project. I am not sure how much utility having it for the CLI would be considering that pmount is available to do it manually. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: Build failure: cannot find -lglib-2.0
On Fri, Oct 13, 2006 at 11:40:04AM +0100, Martin Michlmayr wrote: > A number of packages currently fail to build with: > /usr/bin/ld: cannot find -lglib-2.0 > > Can someone please investigate whether this is a bug in those packages > or some underlying problem and file bugs. I've put some buid logs at > http://people.debian.org/~tbm/logs/glib.bz2 That would be QtCore.pc having -lglib-2.0 in it. They all have libqt4-dev installed. I'll file a bug. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: incoming locked?
Toni Mueller <[EMAIL PROTECTED]> wrote: > I uploaded a version of my roundup package some two days ago which > cleans up important bugs. The package page shows the upload on > 2006-10-11, but when searching for it on w.d.o/packages, I get only an > older version which *has* bugs. Any chance that the fixed version gets > into Etch? [...] Hello, packages.debian.org is lagging almost a whole day (bug #335011), you should use madison on merkel or "apt-cache show" on a up to date sid system to check the available version. (SID)[EMAIL PROTECTED]:/# apt-cache show roundup | grep ^Version Version: 1.2.1-4 cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Starting services in runlevels 0 and 6
> The reason this might break is that several init.d scripts are missing > dependency information, so the boot order generated by insserv might > be incorrect. insserv include override files for some of these From what I see, having this will not happen for etch. Do you think it could be a release goal for etch+1? With that already decided and widely accepted, it wouldn't probably be very hard to begin a campaign to make packages include dependency information just after we release etch signature.asc Description: Digital signature
Re: want to contribute
On Fri, 13 Oct 2006 10:39:18 -0500, Arvind kumar wrote: > I am using debian linux for quite some time and quite impress by it. I want > to contribute to its development . > Please give me some pointers . I looked at website , it not quite clear how > to start Take a look at http://www.debian.org/devel/join/ - the page is titled "How You Can Help". 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: Beatles signature.asc Description: Digital signature
Load templates with debconf-loadtemplate
Hello,
How I must confugure the locales, from this error
finish.
Best regards,
debian-sarge:~/proftpd-1.2.10# debconf-loadtemplate
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "pt_BR:pt:pt_PT",
LC_ALL = (unset),
LANG = "pt_BR"
are supported and installed on your system.
perl: warning: Falling back to the standard locale
("C").
locale: Cannot set LC_CTYPE to default locale: No such
file or directory
locale: Cannot set LC_MESSAGES to default locale: No
such file or directory
locale: Cannot set LC_ALL to default locale: No such
file or directory
Usage: /usr/bin/debconf-loadtemplate owner file
debian-sarge:~/proftpd-1.2.10#
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale
o discador agora!
http://br.acesso.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
On Fri, Oct 13, 2006 at 10:18:01AM -0500, John Goerzen wrote: > But worse -- what if you're not using Gnome or KDE? I can find no way > for a user that doesn't use any X applications to take advantage of this > automatic support, even if the user is in the plugdev group. I can't > even find a way for a user to take advantage of it manually, again even > if the user is in plugdev. Why are we restricing this to users of GUIs? what about the CLI utility "pmount"? I am using it regularly, as I am neither using KDE nor GNOME, and it does its job (I am able to mount removable devices as long as I am in the plugdev group). -- c u henning signature.asc Description: Digital signature
Re: Lack of transparency of automatic actions
Le vendredi 13 octobre 2006 à 10:18 -0500, John Goerzen a écrit : > But worse -- what if you're not using Gnome or KDE? I can find no way > for a user that doesn't use any X applications to take advantage of this > automatic support, even if the user is in the plugdev group. I can't > even find a way for a user to take advantage of it manually, again even > if the user is in plugdev. Why are we restricing this to users of GUIs? You are looking for ivman, which does the same thing as gnome-volume-manager for the CLI. > The bottom line is that I think we have some useful functionality here, > but our implementation needs work. It would be very nice to have these > issues ironed out before etch. Most people interested in such functionality are also interested in KDE or GNOME, I think this is why things aren't as ironed out otherwise. As for many things in Debian, the best way to see something working is to write the missing pieces yourself. -- .''`. 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
want to adopt craft package
I searched the list of package available for adoption. I am interested in adopting craft package. But I need little help from Mr Hueffner for some time Arvind
Re: Final call for votes for"GR: Re-affirm support to the Debian Project Leader"
a65763d3-b1e2-4530-8ff8-aa5915274eb4 [ 3 ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank [ 2 ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects [ 1 ] Choice 3: Further discussion -- John Hasler pgpDsxaxFVmLJ.pgp Description: PGP signature
Re: Request for virtual package ircd
Hi, On Thu, Oct 12, 2006 at 12:10:51AM +0200, Mario Iseli wrote: > as described in > http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt > I announce here my idea of the virtual package ircd. When I count > correctly are at the moment 7 different IRC-daemons in Debian and they > logically conflict with each other. So I would think an official virtual > package would be a fine solution. There are also IRC services which work > in general with all ircds, so it would be easier if those packages also > could only depend on "ircd". As the (co-)maintainer of 2 IRCd packages and 2 IRC services packages, I completely disagree. Some IRC servers do *not* conflict, so a virtual package is unnecessary. If they conflict, like ircd-hybrid and dancer-ircd, it is up to the maintainer to manage the conflicts. Some services, if not all, are designed to work on a specific IRCd. For instance, hybserv is supposed to only run with ircd-hybrid and dancer-services to only run with dancer-ircd. I do *not* want to undertake the maintenance of a services package on other IRC servers that the one for which it is designed. > I file now the bug against debian-policy and say thank you in advance > for your answer. For what my opinion is worth on the matter, I engage the maintainers of debian-policy to discard this bug. Thanks. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys & Net Admin signature.asc Description: Digital signature
Re: want to contribute
On Fri, Oct 13, 2006 at 10:39:18AM -0500, Arvind kumar wrote: > I am using debian linux for quite some time and quite impress by it. I want > to contribute to its development . It would help if you could narrow down your interest somewhat. Some possible projects are listed at http://www.us.debian.org/devel/todo/ > Please give me some pointers . I looked at website , it not quite clear how > to start http://www.debian.org/devel/ has a good overview the various areas of development. http://www.debian.org/devel/join/ is probably what you should start with. The new maintainers' guide at http://www.debian.org/doc/maint-guide/ should get you started with packaging work, if that interests you. Other than the above, you could check the wiki too, at http://wiki.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: delay of the full etch freeze
On Thu, Oct 12, 2006 at 10:32:24PM -0700, Thomas Bushnell BSG wrote: > > Yes, this is my official position on the question (dunno about Andi's, I'm > > replying to email off-line at the moment and haven't checked with him, but I > > would guess his position is similar). > > The only packages in NEW that I'm inclined to worry about are those that fix > > release-critical bugs. > I think this is unrealistic, because we cannot predict NEW's > behavior. It's true that we can't predict NEW's behavior, but that doesn't make it right to delay the freeze for non-RC bugfixes caught in NEW. The general shape of the etch release should be determined for months now, and we should be in the process of stabilizing for the release -- introducing new packages is definitely not "stabilizing", so I won't be heartbroken if packages not related to release-critical bugs don't make it through the queue in time for etch. > It doesn't follow that somebody "waited that late"; it may > well be instead that they did everything they could, and it was the > processing of NEW that waited a long time. According to http://ftp-master.debian.org/new.html, the oldest package in NEW is 3 weeks old. 3 weeks ago was more than a full month after the original proposed base freeze date for etch[1]. Sorry, no, I'm not going to lose any sleep over such packages not making it into etch before the freeze. -- Steve Langa[Asek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] http://lists.debian.org/debian-devel-announce/2005/10/msg4.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392804: ITP: ipager -- netwm compliant pager
Package: wnpp Severity: wishlist Owner: Francois Fevotte <[EMAIL PROTECTED]> * Package name: ipager Version : 1.1.0 Upstream Author : Sukhanov Vadim <[EMAIL PROTECTED]>, Shashkin Konstantin <[EMAIL PROTECTED]>, Mathias Gumz <[EMAIL PROTECTED]> * URL : http://useperl.ru/ipager/index.en.html * License : MIT Programming Lang: C++ Description : netwm compliant pager IPager is a pager application originally developed for Fluxbox, but it can also be used with other windows managers. It supports the following features: - Zoom on desktop images - Main window transparency - Transparent workspaces icons - Theming - You can send a window from one workspace to another - Application icons -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US.ISO8859-15, LC_CTYPE=en_US.ISO8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#379113: python-soappy: fpconst failure on 64 Bit
Hello, since the last bugfixes/upload for the python-soappy package have been NMUs, I'm posting to debian-devel, too. * #379113 renders the package more or less useless on all 64bit platforms, at least its WSDL part. This should be fixed before etch comes out. * the fpconst URL mentioned in the report does not work, it's avaiable here: http://cheeseshop.python.org/pypi/fpconst/0.7.2 I'm also wondering why fpconst is not included in any default py package or available in it's own package - although packaging a single file sounds like overkill - fpconst provides some useful functions. * I've packaged a version of python-soappy which includes the fix for #379113 - would be good if somebody could look trough it and get it into Debian as I'm no DD. The files are here: http://debian.recluse.de/python-soappy/ Thanks a lot, best regards Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
Am Freitag 13 Oktober 2006 17:18 schrieb John Goerzen: > This has been bugging me for some time now, and I'd like to see if we > can improve the situation. > > The main problem is that it's not clear how all this media > autodection/automounting works. It's not clear how to enable it, it's > not clear how the permissions work, and it's not clear how to manage it. > > Let's start from the worst scenario: a system administrator. > Traditionally, to know who can mount a device, you can look at > /etc/fstab: if something is marked "user", then a user can mount it. > You can also look at the permissions of the entry in /dev to see if a > user can access it directly. That is still the case > Now, apparently, if a user is in the plugdev group, then that user could > mount it even if it appears nowhere in fstab and even if the user > doesn't have access to the /dev entry. But this isn't documented > anywhere obvious, certainly. It should be in big capital letters > somewhere. No, he can only mount it if it is marked as a removable device _and_ if the device file has the proper permissions for the user > Next, what about from the user's perspective? By default, when you > add a user, that user is not a member of plugdev, so these things don't > work. Gnome warns you that you need to be a member in some cases; KDE > doesn't. It would be nice for KDE to do that. Not really, maybe some users are not supposed to able to do that? Shall those be flodded with useless messages? > It's also not clear how it reacts to devices that are in fstab, or how > to make it shut up about stuff. It does. pmount honors the fstab entries, it just does not require them > But worse -- what if you're not using Gnome or KDE? I can find no way > for a user that doesn't use any X applications to take advantage of this > automatic support, even if the user is in the plugdev group. I can't > even find a way for a user to take advantage of it manually, again even > if the user is in plugdev. Why are we restricing this to users of GUIs? There is pmount. > Now, what about networking? We have two competing systems: ifupdown and > network-manager. ifupdown works fine for static servers or > workstations, but it doesn't do any of the automatic network scanning > and connecting that network-manager does. And network-manager is unable to connect to two networks at the same time, e.g. to one via cable and to one via WLAN. Very annoying, especially if only one of them routes to inet. > It's great to have those > network-manager features -- automatically bringing up eth0 when a cable > is plugged in, automatically connecting to a known wireless network, > etc. But network-manager only works for interfaces that don't have > things specified in /etc/network/interfaces. So I can't tell it to run > an iwpriv command on my wireless card before scanning for networks. "man NetworkManagerDispatcher" looks promising > Even worse, you again have to use KDE or Gnome to take advantage of > network-manager. Why are we leaving CLI users out in the cold? Good question. The concept for a cli like this would need many thoughts, though. A GUI makes that a bit easier. > Moreover, it is completely unclear how permissions for taking network > devices up and down are managed in this scenario. Ordinarily, only root > can do that, but now we're apparently letting anyone. How can we > restrict that? A user is a member of group netdev or not. Management goes with d-bus configuration files. HS pgpeezoSYS2QD.pgp Description: PGP signature
Re: Lack of transparency of automatic actions
Hi, On Friday 13 October 2006 17:18, John Goerzen wrote: > Even worse, you again have to use KDE or Gnome to take advantage of > network-manager. Why are we leaving CLI users out in the cold? It is > quite possible to use mutt, ssh, and ftp on a laptop. And it's > frustrating to know that my network setup will be useless when I'm not > running in X. apt-cache show whereami That added, I agree with most of your post. But that doesn't help :) regards, Holger pgpinvy9I3A5r.pgp Description: PGP signature
Bug#392828: ITP: exaile -- a media player written in GTK+
Package: wnpp Severity: wishlist Owner: Francois Fevotte <[EMAIL PROTECTED]> * Package name: exaile Version : 0.2.4 Upstream Author : Adam Olsen <[EMAIL PROTECTED]> * URL : http://www.exaile.org/ * License : GPL Programming Lang: C, Python Description : a media player written in GTK+ Exaile is a media player aiming to be similar to KDE's AmaroK, but for GTK+. It incorporates many of the cool things from AmaroK (and other media players) like automatic fetching of album art, handling of large libraries, lyrics fetching, artist/album information via the wikipedia, last.fm support, optional iPod support (assuming you have python-gpod installed). In addition, Exaile also includes a built in shoutcast directory browser, tabbed playlists (so you can have more than one playlist open at a time), blacklisting of tracks (so they don't get scanned into your library), downloading of guitar tablature from fretplay.com, and submitting played tracks on your iPod to last.fm. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US.ISO8859-15, LC_CTYPE=en_US.ISO8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: delay of the full etch freeze
Le Thu, Oct 12, 2006 at 10:22:43PM +0200, Petter Reinholdtsen a écrit : > [Charles Plessy] > > The rationale is that the 8th is "old freeze deadline minus 10 > > days", so it was not completely unreasonnable to take this day as > > the deadline for having new packages in Etch. > > I find this completely unreasonable. If someone waited that late in > the release process before uploading a package they knew would have to > go through NEW, they can not expect the package to make it into Etch. > New packages should have had at least a few weeks in unstable to allow > problems to be detected before heading for testing. Dear Petter, Your point of view is in my opinion very pessimistic. What if there were some late uploads because people were enthousiastic improving Etch and worked hard until the deadline ? I agree that there needs some testing, but freeze or not, packages without bugs stay in unstable no more than 10 days anyway. There will be one month between the freeze and the release, so this is few weeks of testing anyway. I have the point of view of somebody making packages for simple programs on which other packages usually do not depend. Of course, I do not pretend that one should upload to NEW a major release of a pivotal software suite eleven days before the prospective freeze. Anyway, it was good to have some sort of deadline. I thank the release team for having decided one. In my case, I prioritised my recreational computer activities, putting more Debian stuff in September and less in October. Overall, it helped me to acheive one goal (good coverage of biological sequence alignment tools in Etch). Depending on who will be the fastest between release and the ftp teams, two more packages will make it or not. If they do not, I will send apologies to the upstream author who trusted me when I said that we should be ready a few days before the 8th and explain him that I did not understand how the freeze process works. For the second package, as it has a RC bug hidden under a normal priority, I will ask for an exemption on the debian-release list. Thanks to all the other persons who answered to me. Have a nice weekend, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
On Fri, Oct 13, 2006 at 10:57:37PM +0200, Henning Glawe wrote: > On Fri, Oct 13, 2006 at 10:18:01AM -0500, John Goerzen wrote: > > But worse -- what if you're not using Gnome or KDE? I can find no way > > for a user that doesn't use any X applications to take advantage of this > > automatic support, even if the user is in the plugdev group. I can't > > even find a way for a user to take advantage of it manually, again even > > if the user is in plugdev. Why are we restricing this to users of GUIs? > > what about the CLI utility "pmount"? I am using it regularly, as I am neither > using KDE nor GNOME, and it does its job (I am able to mount removable > devices as long as I am in the plugdev group). OK, that does look like it would address CLI people getting these features. It doesn't address the network features or the permissions issues though. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
On Sat, Oct 14, 2006 at 01:32:42AM +0200, Hendrik Sattler wrote: > > /etc/fstab: if something is marked "user", then a user can mount it. > > You can also look at the permissions of the entry in /dev to see if a > > user can access it directly. > > That is still the case > > > Now, apparently, if a user is in the plugdev group, then that user could > > mount it even if it appears nowhere in fstab and even if the user > > doesn't have access to the /dev entry. But this isn't documented > > anywhere obvious, certainly. It should be in big capital letters > > somewhere. > > No, he can only mount it if it is marked as a removable device _and_ if the > device file has the proper permissions for the user My own experience suggests that this is not the case. I have never made my user have permissions for the SCSI devices that are used when I plug in my iPod, but there is KDE offering to (and succeeding to) mount it just the same. So no, that is not still the case. > > things specified in /etc/network/interfaces. So I can't tell it to run > > an iwpriv command on my wireless card before scanning for networks. > > "man NetworkManagerDispatcher" looks promising To some degree. But it still doesn't really do as much as the GUI tools do, even after hacking. > Good question. The concept for a cli like this would need many thoughts, > though. A GUI makes that a bit easier. Well, one could easily enough forgo the notification of status change but support commands to query and change the status -- just like ifconfig, ifup, and ifdown do. Then all you need is a way to store wifi configs and that should do it. > > restrict that? > > A user is a member of group netdev or not. Management goes with d-bus > configuration files. OK, but this is not documented in any obvious place. This flies in the face of traditional Unix practice, so it is especially important to make a big fat notice about it. Also, what is the first-time Debian user to do? How does this person learn about the need to add someone to netdev? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How should we deal with 'pointless-on-this-arch' packages?
In general debian builds everything for every architecture. This is a very good plan and finds a lot of bugs. However there are some packages which are clearly not sensible on some arches. Numerical analysis software in general on arm is a good example of this class. Arm hardware is generally slow and more seriously has no floating point hardware (except very exceptionally). No-one in their right mind would run numerical analysis on an arm box, for any purpose other than testing that they could. Now in an ideal world we would gratutiously build these packages anyway, just to check that they do build on said architecture, but there is a cost to doing this. Buildd time and archive space. Buildd time particularly, for slow arches, is a resource we don't have a huge abundance of. So, 'is pretty much pointless' has not to date been deemed a reason to mark a package 'not for us'. However, It seems to me that if the porters _and_ the package maintainer agree that there really is no real point in building a package for a particular arch, and it takes signifcant resources to do so, that it is best to mark such packages 'not for us'. However I don't think we should just start doing this unilaterally, so I am posting here to canvass opinion. Should inappropriateness be a criterion for deciding a package is not-for-us? Should we perhaps have a more general mechanism than such ad-hoc marking to indicate innappropriate combinations of package and architecture? An example of this genre is fityk, which currently times out on arm, trying to build large C++ files. It is curve-fitting software. It could probably be built, but one wonders if it is worth the effort. The author is happy to not have it built for arm. I'm sure there are others in the same situation, although I have not done extensive research to try and produce a list. (cc: me - I'm not subscribed) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
