Re: RFC: graph of Debian package cycle
Hi Martin, On Sat, Feb 12, 2005 at 04:47:27PM +0100, martin f krafft wrote: > Based on the work of Kevin Mark (URL not available, sorry), I have http://kmark.home.pipeline.com/debian.png http://kmark.home.pipeline.com/debian.fig > made a graph of the life cycle of a Debian package for inclusion in > my forthcoming book (http://debianbook.info). You can find the > sources and generated files at > > http://people.debian.org/~madduck/graphs/package-cycle/en/ > > Additional information is available at > > http://people.debian.org/~madduck/graphs/package-cycle/ABOUT > > The graph is herewith released under the Artistic Licence. Thanks > to Goswin Brederlow, Bernhard Link, and Kenshi Muto, as well as > Kevin Mark, Sven Müller, and Martin Schulze for the original work. > > Please send any comments or corrections my way. hmm! I think I will try to update mine! cheers, -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: please post listing and status of NEW queue
[Adeodato Simó] > That is, a diff of the list of binary packages. Perhaps, one could > colour red removed packages, and blue added ones. Be carefull with using only color coding. This make it harder for color blind and blind people to read the information. While we are on the feature wishlist, it would be nice if the bug numbers had some tag indicating the bugs severity. At least all RC bugs should be highlighted in some way. Or perhaps all non-RC bugs should be tagged? Something like '(#134421)' for RC-bugs, and '#123452' for RC bugs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Sat, 2005-02-12 at 18:59 -0600, David Moreno Garza wrote: > On Sat, 2005-02-12 at 22:52 +0100, Thomas Hood wrote: > > It would be nice if the page indicated which of the binary packages is new. > > The binary column indicates those created within the source package. > Every source package on the summary is new, that's why it is on the NEW > queue. Not every source package is new to the archive. Some of the source packages are already present in the archive but are in the queue because they contain binary packages that are not already present in the archive. It would be nice if the page indicated which of the _binary_ packages is new. -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Sun, Feb 13, 2005 at 12:07:06PM +1100, Paul Hampson wrote: > > So what if we had two editions of libmysqlclient, one of them > > ssl-enabled and the other - as currently - not? That would allow > > using ssl whenever possible. I think that could be done, without > > breaking things. > > That's funny. Didn't we spend all that time since Woody merging > lib-*-ssl back into lib-*? > That was perfecly reasonable at the time of libmysqlclient10, when it was LGPL. Unfortunately the change in the license was not among the possibility considered for the near future... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: graph of Debian package cycle
On Sat, Feb 12, 2005 at 07:08:49PM +0100, Florian Weimer wrote: > * martin f. krafft: > > > Based on the work of Kevin Mark (URL not available, sorry), I have > > made a graph of the life cycle of a Debian package for inclusion in > > my forthcoming book (http://debianbook.info). You can find the > > sources and generated files at > > > > http://people.debian.org/~madduck/graphs/package-cycle/en/ > > Interesting, thanks. I believe the --->O arrays are confusingly > labled. "package installation" is probably a better choice. The > difference between "package propagation" and "package upload" is not > clear, at least to me. Hi Florian, I think 'package propagation' is machine initiated (via tags) and 'package upload' is human initiated. > > I suppose you should split the diagram in two because the > before-incoming part and the after-incoming part are not too strongly > connected, and the result would be more readable. > This is something about which I will think. -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Babelbox documentation is available
(reply to -devel unless answering on a topic more appropriate to one of the other lists) Several people have heard of my "Babelbox" demo machine which was featured for the first time at Solutions Linux expo in Paris. This demo machine is a Debian Installer demo which runs over and over, changing the installation language at each run. This is a quite nice demo of the installer automation capabilities and a good eyecatcher for a Debian booth. At Solutions Linux, the demo ran 54 successive installs (being limited by power outage during nights), but I already ran up to 300 successive installs while testing it. The demo installs a complete desktop system with the default "desktop" task from tasksel (the one with Gnome AND KDE), then opens a Gnome session which include a "welcome" sound in the current language. Most of these sounds have been contributed by Debian-women contributors as well as D-I translators. Some people have requested me to make the demo material available so that they can build their own Babelbox demo and possibly make it better. So, I have put on http://people.debian.org/~bubulle/babelbox.tar.bz2 the whole material needed for Babelbox (including sounds...which make the file quite big) as well as the needed documentation. I hope you'll enjoy it and certainly will make it even better. I'd like to publicly thank here my employer, the French Aeronautics and Space Reseach Center, as well as François Mescam, my boss, for allowing me so build and test this demo on our equipments as well as invest some on my work time on automated Debian installs in the demo setup. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Verify debian-devel@lists.debian.org for Francois.Mescam@onera.fr
Bonjour, Votre message a bien été reçu, mais il ne m'a pas encore été délivré car je n'ai pas encore noté que vous m'envoyez des messages depuis cette adresse. J'ai besoin de vérifier que cette adresse vous correspond bien. Aussi je vous prie de bien vouloir faire "reply" sur ce message et me renvoyer cette réponse, ainsi le message précédent ainsi que tous ceux à venir me seront délivrés. Merci de votre compréhension. Hi! Your message has been received, but it hasn't been delivered to me yet. Since I don't have any record of your sending me mail from this address before, I need to verify that you're not a spammer. Please just hit 'Reply' and send this message back to me, and your previous message will be delivered, as will all your future messages. Thanks, and sorry for the inconvenience - -- Francois Mescam Tel:+33 1 46 73 44 06 Fax:+33 1 46 73 41 50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: graph of Debian package cycle
also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.02.12.1908 +0100]: > Interesting, thanks. I believe the --->O arrays are confusingly > labled. "package installation" is probably a better choice. The > difference between "package propagation" and "package upload" is > not clear, at least to me. okay for the first. the difference between propagation and upload is whether it happens automatically by the archive scripts, or has to be manually instigated by the developer (uploaded). do you have a suggestion how to improve this? > I suppose you should split the diagram in two because the > before-incoming part and the after-incoming part are not too > strongly connected, and the result would be more readable. well, i guess you are somewhat right, although the split will be difficult. i guess just leaving out the incoming part altogether at the risk of not being absolutely correct may be an option. anyway, i am tempted to leave it as complex as it is and to add a note that it's not supposed to be any more overwhelming than reality is. :) upon careful study, the graph *can* be used to extract information, no? also sprach Kevin Mark <[EMAIL PROTECTED]> [2005.02.13.1031 +0100]: > > I suppose you should split the diagram in two because the > > before-incoming part and the after-incoming part are not too > > strongly connected, and the result would be more readable. > > This is something about which I will think. Yes, me too. If you have any suggestions on how to split, I would love to hear them. Kevin: I hope I did not step on your feet, but I was in a rush to get some version done, so I did not contact you. You are cordially invited to work from my sources, or we can maintain in parallel. In any case, I hope you are okay with the attribution I gave. Otherwise, please let me know. also sprach Otavio Salvador <[EMAIL PROTECTED]> [2005.02.12.1947 +0100]: > mfk> Given that incoming contains the source package (unless orig.tar.gz > mfk> is pulled from unstable, should add that), the buildds really don't > mfk> deal with the upstream sources or the unpacked source tree > mfk> maintained by the developer. > > Buildds deal with source package and not binary package. I thought > you mean with package source the .dsc, .diff.gz and .orig.tar.gz > files. Right, and incoming also contains them. The "sources" item is really supposed to be the upstream sources or the directory on the developer's machine holding the stuff, but inaccessible as such to the buildds. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#295006: debian-policy: Virtual package: change mp3-encoder with music-encoder
On Sun, Feb 13, 2005 at 01:22:20AM +0200, Jesus Climent wrote: > Package: debian-policy > Version: 3.6.1.1 > Severity: wishlist > > Having no mp3 encoder in the archive, due to possible patent problems, i > believe it would be a wiser idea to have "music-encoder" as a virtual package > than "mp3-encoder". What would the interface provided by such a virtual package be? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
First line in /etc/hosts
Current d-i writes the following line to the beginning of /etc/hosts: 127.0.0.1localhost.localdomain localhost Traditionally, this confuses some programs; at least pvm used to have problems with this, and I'm fairly sure cfengine2 doesn't like it either, so we've changed to 127.0.0.1. localhost However, now we've suddenly discovered that _other_ programs get confused by this! In particular, if you use an NFSv4-patched mount, it does a gethostname() and resolves that, which returns 127.0.0.1, which in turn makes it happily use that as a client identifier to the remote server. (This breaks when two or more such clients connect, obviously.) So, one program has to be buggy here, but which? :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Feb 13, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > So, one program has to be buggy here, but which? :-) The first ones. 127.0.0.1 IS localhost. -- ciao, Marco signature.asc Description: Digital signature
Moin 1.3.x: Status of the package moin
Hi Jonas, I'm writing you again after my last email was not answered. I would like to help you out packaging moin 1.3.x. Could you please contact me on furter development of MoinMoin for Debian? If not I will start creating a NMU. -- Raphael Bossek pgpgVD86x0i5X.pgp Description: PGP signature
Re: First line in /etc/hosts
On Sun, 13 Feb 2005 13:30:11 +0100, Steinar H. Gunderson wrote: > Current d-i writes the following line to the beginning of /etc/hosts: > >127.0.0.1localhost.localdomain localhost This is correct. > Traditionally, this confuses some programs; at least pvm used to have > problems with this, and I'm fairly sure cfengine2 doesn't like it either What problems? If there are problems then they probably arise from a faulty _combination_ of /etc/hosts, hostname, /etc/nsswitch.conf and /etc/resolv.conf settings. > so we've changed to > >127.0.0.1. localhost > > However, now we've suddenly discovered that _other_ programs get confused by > this! So revert the change? > In particular, if you use an NFSv4-patched mount, it does a > gethostname() and resolves that, which returns 127.0.0.1, which in turn makes > it happily use that as a client identifier to the remote server. (This breaks > when two or more such clients connect, obviously.) Make your /etc/hosts look like this: 127.0.0.1localhost.localdomain localhost w.x.y.z . Make w.x.y.z either the permanent IP address of your machine's permanently connected network adapter, or, if it does not have one of those, "127.0.1.1". -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 01:25:15PM +0100, Steinar H. Gunderson wrote: > However, now we've suddenly discovered that _other_ programs get confused by > this! In particular, if you use an NFSv4-patched mount, it does a > gethostname() and resolves that, which returns 127.0.0.1, which in turn makes > it happily use that as a client identifier to the remote server. (This breaks > when two or more such clients connect, obviously.) This also causes problems for NIS servers, for the same reason - NIS needs to hand out the IP address of the machine in some circumstances and 127.0.0.1 is inappropriate. Resolving the hostname is a standard method for obtaining an IP address for the machine and it would be helpful if it could be reverted since I imagine other programs are also going to run into the same issue. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteering to help development
to, 2005-02-10 kello 18:23 -0800, Frederico Rodrigues Abraham kirjoitti: > hi. i want to help developing for debian. > how should i proceed? > i have experience with computer graphics and mathematical tools > programming, but most interested in the computer graphics field, in > which i'm completing my master thesis. The simple first step could be to look at http://bugs.debian.org and look for bugs that you can fix, possibly in packages that interest you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-policy: Virtual package: change mp3-encoder with music-encoder
su, 2005-02-13 kello 01:22 +0200, Jesus Climent kirjoitti: > Having no mp3 encoder in the archive, due to possible patent problems, i > believe it would be a wiser idea to have "music-encoder" as a virtual package > than "mp3-encoder". Wouldn't it be necessary for this to work for all music encoders to have the same command line interface? I haven't used MP3 encoders for many years, but in their simple forms, I vaguely recall them to have been at least somewhat similar in their command line syntax. They also produce the same type of output. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
Mark Brown writes: > ...NIS needs to hand out the IP address of the machine... Machines don't have IP numbers. Interfaces have IP numbers. Every machine with one or more external interfaces has at least two: 127.0.0.1 for the loopback interface and one for each external interface. > Resolving the hostname is a standard method for obtaining an IP address > for the machine... Every machine with more than one interface has at least two hostnames: localhost on network 127 and something else on the external networks. Routers often have different hostnames on different external interfaces. I think there are two problems here: some packages make assumptions about *the* IP number and/or *the* hostname, and /etc/hosts gets misconfigured either by buggy software or the admin. The purpose of /etc/hosts is to associate IP numbers with hostnames. I can see no good reason to associate 127.0.0.1 with any name other than localhost. It is also not always necessary for all of a machine's IP numbers and/or hostnames to appear in /etc/hosts. (I'm sure you know all this, Mark, but I'm not sure everyone else in the thread does. I *am* sure that some people writing Linux programs don't.) -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
runlevel and sequence point for gfs cluster infrastructure
Hi folks I currently try to get gfs and the cluster infrastructure into a usable state. One of the problems are the runlevel and sequence point settings for each step. The whole thing should start before the daemons, bus this will make it impossible to login into the system if the cluster is not quorate (i.e. have enough active members) at startup, as ssh and inetd are started with the other daemons. Possiblities: * start before general daemons: - cluster manager: will timeout if it can't join the cluster - io fencing: will block if cluster is not quorate * start after daemons - daemons which needs access to such a fs needs to be started later. * use a system similar to dbus: - it is possible to handle timeouts properly and just leave the fs unmounted if the preconditions are not met. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3 signature.asc Description: Digital signature
Re: First line in /etc/hosts
In article <[EMAIL PROTECTED]> you wrote: > Resolving the hostname is a standard method for obtaining an IP address > for the machine And pretty broken in a lot of the cases :) It is much better to retrieve the local current IP address of the connection you are going to send the ip (if it is needed). This works at least for TCP. For UDP it should be configurable, a lookup by name is of course a possible default. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verify debian-devel@lists.debian.org for Francois.Mescam@onera.fr
On Sun, Feb 13, 2005 at 12:17:08PM +0100, [EMAIL PROTECTED] wrote: > Your message has been received, but it hasn't been delivered to me yet. Since > I > don't have any record of your sending me mail from this address before, I need > to verify that you're not a spammer. Please just hit 'Reply' and send this > message back to me, and your previous message will be delivered, as will all > your future messages. > > Thanks, and sorry for the inconvenience - Why do people think it's acceptable for their stupid anti-spam measures to inconvenience others? (Seems more like an "anti-anyone-mailing-me-at-all" measure, really. Why would anyone put up with this?) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295122: RFA: iproute -- Professional tools to control the networking in Linux kernels
Package: wnpp Hi, anyone who wants to work on iproute is greatly welcome, perhaps also as co-maintainer (and I'm also willing to sponsor people). The reason I intend to give the package away is that I'm not really the great networking guy, but I'll try to give the package a warm home till I can pass it over to someone else -- and as iproute is quite vital for some purposes, I'll do some checks before giving the package away. It is _not_ orphaned, I'm "only" looking for somebody else for maintaining. The description is: This is `iproute', the professional set of tools to control the networking behavior in kernels 2.2.x and later. . At least, the options CONFIG_NETLINK and CONFIG_NETLINK_DEV (or CONFIG_RTNETLINK) must be compiled into the running kernel. . This package is also known as iproute2 upstream and in some documentation. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: > Mark Brown writes: > > ...NIS needs to hand out the IP address of the machine... > Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, 13 Feb 2005, Mark Brown wrote: > On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: > > Mark Brown writes: > > > > ...NIS needs to hand out the IP address of the machine... > > > Machines don't have IP numbers. Interfaces have IP numbers. Every machine > > Actually, that's not quite the case (as a number of users of Linux's ARP > implementation have found), though it's a good approximation. Indeed. For Linux, nodes have IP *numbers* which are all equal, and you have to take great pains to make sure it behaves in any different way. iproute2, arptables and the relative black magic of arp_filter are your only ways to try to influence that. Usual route, ifconfig, etc are useless. BTW, as a corolary, always firewall off 127.0.0.1 to any non-lo traffic, even when interface forwarding is disabled. You Have Been Warned. -- "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: please post listing and status of NEW queue
* Petter Reinholdtsen [Sun, 13 Feb 2005 09:34:01 +0100]: > [Adeodato Simó] > > That is, a diff of the list of binary packages. Perhaps, one could > > colour red removed packages, and blue added ones. > Be carefull with using only color coding. This make it harder for > color blind and blind people to read the information. Yes, definitely. In case colour was used, the +/- prefix should still be present. Thanks for pointing out. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Kiko Veneno - Veneno When you don't know what to do, walk fast and look worried. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295127: ITP: dvbsnoop -- DVB / MPEG stream analyzer
Package: wnpp Severity: wishlist Owner: Cedric Delfosse <[EMAIL PROTECTED]> * Package name: dvbsnoop Version : 1.3.77 Upstream Author : Rainer Scherg <[EMAIL PROTECTED]> * URL : http://dvbsnoop.sf.net * License : GPL Description : DVB / MPEG stream analyzer This sniffer program can monitor, analyze, debug, dump or view DVB / MPEG / DSM-CC / MHP stream informations: * ISO/DVB basic sections: BAT, PAT, SDT, NIT, ... * DSM-CC: INT, MPE, MPE FEC, Datagram, ... * TS (Transport Stream), PS (Program Stream), PES (Packetized Elementary Stream) . Input can be a live stream from a DVB card, or a recorded stream. . For DVB cards, it can also dump frontend informations and status, and make a PID scan. . Homepage: http://dvbsnoop.sf.net I don't own myself a DVB card, but I often work for a customer that has DVB-T cards. Maybe this package should be takeover by the Debian VDR Team. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mirror the Packages files _after_ the packages!
On Wed, Feb 09, 2005 at 09:51:44AM +0800, Dan Jacobson wrote: > I know you Debian people think it's just hilarious when users try to > apt-get upgrade during the period after when the Packages files > arrive on the mirrors, but before the packages they describe have > fully arrived. > "Haw haw haw, try again later", you say, never thinking that maybe > writing the Packages files last would be the right thing to do. > "The problem can't persist more then a couple of hours, what's the big > deal?" You've been told this before -- *debian-devel does not control the mirroring implementation used by arbitrary Debian mirrors*. Either talk to the mirror team and give them enough information to track this down, or -- since you know him well enough to be kept in the loop about his vacation schedule -- talk to your local mirror operator directly and get him to stop using broken mirroring scripts. > I can't think of any other case in Computer Science where one updates > a descriptor before updating the thing described!!! How can you defend > that??? No smug remarks can defend that! And no amount of moronic, misdirected ranting will get it fixed. > Err http://xx.linux.org.xx sid/main 404 Not Found > Failed to fetch http://xx.linux.org.xx/debian/pool/main/x > Fetched 26.6MB in 2m39s (167kB/s) > E: Some files failed to download > Error 100 Yeah, real helpful of you to blot out the only potentially useful bit of information in your post... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Xsession doesn't use umask setting from /etc/login.defs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alban browaeys skrev: | In october you told: | |> Searching Google for "xsession umask" will give you some hints. |> |> |> |>> /etc/login.defs explicitly indicates that it is |>> "Configuration control definitions for the login package", |>> and many of its parameters are inapplicable to display |>> managers, or already implemented in parallel (e.g., how long |>> do wait after a failed login before displaying the |>> prompt/greeter again?). | | |> I believe that /etc/login.defs _is_ the right place to define |> the default umask property. | | | I strongly disagree. Google is not a reference by itself and the | few example (gdm and kde session scripts) have been fixed (gdm no | longer import login.defs) upstream or are mere hints for the | user to have a quick fix (kde Xsession hacks). I'm glad to hear that gdm and kdm have been fixed. And how does these fixes improve the issue of a reasonable default umask? | Though login.defs is still sourced by "login" program, half of | its settings are already overridden by pam defaults one. The few | remaining usefull one (ENV_PATH ENVSU_PATH mostly) are overriden | by most shell "profile" too because they disagree with it. PAM is good. The fact remains, it doesn't handle default umask. | It confuse beginners who read manual carefully and up wondering | why their settings are not working. The sooner it it emptied of | system wide environment settings the better. So exactly where, according to you, is the proper place for a system wide default umask property, if not /etc/login.defs? Regards - -- Tomas Fasth <[EMAIL PROTECTED]> GnuPG 0x9FE8D504 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCD89wwYdzVZ/o1QQRAt3ZAJ0crhms5ydte0zEL8am+OHyxlELzgCfXi8O nJHVLsLr7eiLuFcMYUXF88U= =9Afz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294491: RFA: povray -- Persistence of vision raytracer
> "Brian" == Brian May <[EMAIL PROTECTED]> writes: One question: Brian> I asked about this a while ago on debian-devel and was told Brian> (IIRC) that a major rewrite was happening in order to make Brian> Povray DFSG compliant. Brian> Is this still the case? Two answers: > "Jeroen" == Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: Jeroen> No, not really, upstream seems to really want to keep Jeroen> development closed and the license too, in fear of rough Jeroen> versions/ripoffs of POV-Ray to be used without proper Jeroen> acknowledgements, and to prevent any commercial use of the Jeroen> software the authors wrote. Jeroen> See the POV-Ray newsgroups for more information. > "Miles" == Miles Bader <[EMAIL PROTECTED]> writes: [...] Miles> 2) Acording to their FAQ, they'd actually rather _like_ Miles> to be free-software, but large quantities of their Miles> source-base were developed before they had any such Miles> concept, and contributor is so muddled that they couldn't Miles> easily just relicense everything. Miles> 3) There's a suggestion that they may try to change their Miles> license to something free after the next big rewrite, Miles> planned for the vague medium-term future. Curious; maybe the FAQ is wrong? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: runlevel and sequence point for gfs cluster infrastructure
On Sunday 13 February 2005 18:47, Bastian Blank wrote: > I currently try to get gfs and the cluster infrastructure into a usable > state. One of the problems are the runlevel and sequence point settings > for each step. Take a look at the NFS packages, while I'd venture that PCMCIA NICs are irrelevant for GFS Clusters, the main question is whether you need GFS for mounting /usr. If you do, the node will be unusable anyways, if you don't GFS can be started late. Other services depending on CMS and GFS have to be brought online later anyways. Regards, David PS: have you received my private inquiry regarding the status of your packages I sent you two weeks ago? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is /.udev for ?
> "Ron" == Ron Johnson <[EMAIL PROTECTED]> writes: Ron> Rules to live by: Ron> Look before you leap. Isn't the modern version: "Leap before you look..." (and then contact your lawyer[1]...) Ron> Measure twice, cut once. Cut twice, measure once. Ron> Google it! Loose it! Notes: [1] I was debating putting a smiley face here, but then remembered some recent court cases... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: Goswin> zsync has the option of looking into gziped files and Goswin> rsync them as if they would be ungziped (while still just Goswin> downloading chunks of the gziped file). Its a bit more Goswin> complex algorithm but works even better than rsyncable Goswin> files and rsync. zsync looks suspiciously like it might have similar patent issues which killed the rproxy project. Then again I am no expert; Please tell me I am wrong... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295155: ITP: steam -- environment for cooperative knowledgemanagment
Package: wnpp Severity: wishlist Owner: Alain Schroeder <[EMAIL PROTECTED]> * Package name: steam Version : 1.5.12 Upstream Author : open sTeam-Team <[EMAIL PROTECTED]> * URL : http://www.open-steam.org/ * License : GPL Description : environment for cooperative knowledgemanagment sTeam provides a technical platform which allows groups of students, lecturers and any other groups to construct and arrange their individual and cooperative learning and working space. sTeam consists of an object-oriented server connected to a database and Web, Java and other (ftp, irc, ...) clients. The server is event-driven and manages all user objects as well as the communication between the connected clients. Different from most other cooperation tools is the novel possibility of self-organisation and self-administration by the members within the virtual environment. In the core, the system provides the following self-administrating functions: * creation of rooms * granting of admission or access authorisations * administration and processing of objects or references to objects and documents located on other servers * carrying objects and passing them on to other users * use of rooms as cooperative media (e.g. Shared Whiteboard) a more detailed description can be found on the website: http://www.open-steam.org/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10marvin+skas-skas3-v7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294491: RFA: povray -- Persistence of vision raytracer
Brian May <[EMAIL PROTECTED]> writes: > Curious; maybe the FAQ is wrong? It's been a while since I looked at it; maybe the maintainers, and thus attitudes, have changed (for the worse). Alternatively, perhaps the loudest mouths on the mailing list are not representative of the project's long-term goals. However, I've not followed the povray groups for a while (in large part because I was so annoyed by the anti-debian attitude I saw), so I can only assume that Jeroen's impression is more accurate. :-( It's disheartening because while there seem to be other free ray-tracers out there with even better rendering quality than povray, I've not found one with anything like povray's wonderfully expressive input language -- most other projects seem to follow the "all input is giant lists of primitives output by modelling programs" method. Anyone know of a similarly expressive alternative to povray? -Miles -- Quidquid latine dictum sit, altum viditur. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Старые кинопленки?
все кулики и кулички без исключения бегают очень No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/02/2005
Bug#295171: ITP: libformatr-ruby -- perl-like formats for ruby
Package: wnpp Severity: wishlist Owner: David Nusinow <[EMAIL PROTECTED]> * Package name: libformatr-ruby Version : 1.09 Upstream Author : Paul Rubel <[EMAIL PROTECTED]> * URL : http://formatr.sourceforge.net/ * License : GPL or Ruby's other licensing terms (see ruby package) Description : perl-like formats for ruby This library provides an easy way to create output with similar formatting but changing values. It is styled after perl's built-in format capablities. This package is basically done as far as I can tell. It's located at http://people.debian.org/~dnusinow/libformatr-ruby/ for those who want to try it out. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Brian May <[EMAIL PROTECTED]> writes: >> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: > > Goswin> zsync has the option of looking into gziped files and > Goswin> rsync them as if they would be ungziped (while still just > Goswin> downloading chunks of the gziped file). Its a bit more > Goswin> complex algorithm but works even better than rsyncable > Goswin> files and rsync. > > zsync looks suspiciously like it might have similar patent issues > which killed the rproxy project. > > Then again I am no expert; Please tell me I am wrong... > -- > Brian May <[EMAIL PROTECTED]> zsync uses the algorithm described in the rsync technical paper afaik. Does rsync have a patent issue? Do we realy care about some stupid countries patents? Maybe non-us isn't ready to die yet, changing from crypto to patented software. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verify debianhttp://www.perrier.eu.org/debian/voices/-devel@lists.debian.org for Francois.Mescam@onera.fr
> Why do people think it's acceptable for their stupid anti-spam measures > to inconvenience others? I am indirectly responsible for M. Mescam message. He was BCC'ed to my original mail annoucing Babelbox documentation (I had my own reasons for the BCC). However, as I did setup the Reply-To field to the mailing list AND as he never received mails from my Debian address first, his automated greylisting system automatically answered and did so using the Reply-To field. So, finally, the request which was supposed to go to me finally went to the list..:-) I was aware of his greylisting system and I should have imagined this when sending my mail. Apologies to list subscribers for that. About the "stupid" antispam system, I guess he knows this is not a perfect system, but please imagine the amount of unsollicited mail (not really spam...mostly "targeted" emails) received by a big organisation IT director on a email address he wants to keep very clean. I'll try help him improving this system for avoiding cases like this one, probably by making it NOT respect Reply-To fields at first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verify debianhttp://www.perrier.eu.org/debian/voices/-devel@lists.debian.org for Francois.Mescam@onera.fr
On 20050214T071408+0100, Christian Perrier wrote: > Debian address first, his automated greylisting system automatically > answered and did so using the Reply-To field. Then it is broken. Automatic mails should be sent to the envelope sender, unless explicitly asked otherwise. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
