Re: jessie release goals
Thomas Goirand writes: > Now please, do the same reasoning with some other services, > like Apache, pure-ftpd, or bind, and explain to me why you would > like to have these installed, but not working. As a developer I have often found use for having Apache installed, just so I can start it as a user with an ad hoc configuration. This is useful for testing the code I work on which can be either apache modules or mod_perl applications. For the same reason I have nginx installed, to be able to perform experiments with how nginx needs to be configured to perform different tasks. I don't need any of these packages to start a service listening on port 80 serving some default set of pages. As I don't have any other webserver installed it is not a problem as such that one of them ends up listening on port 80, but I have always found it a bit bothersome that I just get a random deamon listening on port 80. It have never bothered me enough to complain, but if I have been using nginx on port 80 and stuff then suddenly broke after installing apache (and rebooting) I might have been quite a bit irritated. I am not complaining, just describing a scenario for having Apache installed without wanting to use it as the system webserver. I have never experience the same use cases for bind nor pure-ftpd. //Makholm -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehd7cfv2@vps1.hacking.dk
Re: Bug#532532: ITP: libacme-progressbar-perl -- Perl module providing a s simple progress bar
Salvatore Bonaccorso writes: > Package: wnpp > Severity: wishlist > Owner: Salvatore Bonaccorso > > * Package name: libacme-progressbar-perl > Version : 1.125 > Upstream Author : Ricardo SIGNES > * URL : http://search.cpan.org/dist/Acme-ProgressBar/ > * License : Artistic | GPL-1+ > Programming Lang: Perl > Description : Perl module providing a simple progress bar This is a joke, right? Have you read the code? Could we please add something to the perl policy about ITP's of Acme-modules should contain some justification for packaging the module and at least metion that the pacakge description should include a big fat warning about the modul being a joke? Basically this module implements a progress bar by timing the task nad then sleeping the same amount of time 9 times. //Makholm -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Spam-Problem with linux.debian.user.german
Klaus Ethgen <[EMAIL PROTECTED]> writes: > What the hell is that about? I did not post to any mailing list. I did > post to a nntp group. I do not want to subscribe to one another mailing > list when there is a nntp group available. Mailing lists are as bad as > this forum stuff. For all and ever a new account with a new password.[0] But you did try to post to a mailing list even though you tried to do it through a nntp gateway. The linux.debian.* groups are just 'mirrors' of the mailing lists available on lists.debian.org gatewayed trough a server that happens to be located in italy. If you want tomake uses of the services provided by linux.* (which is mostly nntp access to a lot of linux related mailling lists) you'll have to subscribe to the service as the mail you got has told you. ... but I guess this is offtopic for debian-devel. //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New README.source documentation for Debian packages
Daniel Leidert <[EMAIL PROTECTED]> writes: > This is some kind of stupid! You expect every package, that uses quilt > or dpatch to ship the same quilt/dpatch documentation? You did read the part of the proposal saying: This explanation may refer to a documentation file installed by one of the package's build dependencies provided that the referenced documentation clearly explains these tasks and is not a general reference manual. When dpatch provides the standard explanation a dpatch using package could just point to this explanation. //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rebuilding the archive in a dirty chroot: results
Lucas Nussbaum <[EMAIL PROTECTED]> writes: > Of course, the list includes some false positives, but they are > difficult to identify without going through all the debdiff outputs and > build logs manually. One false positive is when one of the builds fails, like ack-grep which fails some times due to some test depending of the order of files in a directory (reported as #451403) //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446521: ITP: ebug-http -- Devel::ebug::HTTP - web front end for the Devel::ebug Perl debugger
Package: wnpp Severity: wishlist Owner: Peter Makholm <[EMAIL PROTECTED]> * Package name: ebug-http Version : 0.31 Upstream Author : Leon Brocard, C<< <[EMAIL PROTECTED]> >> * URL : http://search.cpan.org/dist/Devel-ebug-HTTP/ * License : as Perl itself (GPL or Artistic) Programming Lang: Perl Description : Devel::ebug::HTTP - web front end for the Devel::ebug Perl debugger Devel::ebug is a simple, extensible Perl debugger with a clean API. Using this module, you may easily write a Perl debugger to debug your programs. . This package provides a web front end to Devel::ebug. ebug_http is the command line program to launch the debugger. It will return a URL which you should point a web browser to. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-xen-amd64 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=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 ANSI_X3.4-1968) (ignored: LC_ALL set to en_DK.ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446388: ITP: libexpect-simple-perl -- Expect::Simple - wrapper around the Expect module
Package: wnpp Severity: wishlist Owner: Peter Makholm <[EMAIL PROTECTED]> * Package name: libexpect-simple-perl Version : 0.03 Upstream Author : Diab Jerius ([EMAIL PROTECTED]) * URL : http://search.cpan.org/dist/Expect-Simple/ * License : GPL Programming Lang: Perl Description : wrapper around the Expect module Expect::Simple is a wrapper around the Expect module which should suffice for simple applications. It hides most of the Expect machinery; the Expect object is available for tweaking if need be. This is a dependency for Test::Expect, which is needed to build Devel::ebug. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-xen-amd64 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=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 ANSI_X3.4-1968) (ignored: LC_ALL set to en_DK.ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446387: ITP: libtest-expect-perl -- Test::Expect - Automated driving and testing of terminal-based programs
Package: wnpp Severity: wishlist Owner: Peter Makholm <[EMAIL PROTECTED]> * Package name: libtest-expect-perl Version : 0.30 Upstream Author : Leon Brocard, C<< <[EMAIL PROTECTED]> >> * URL : http://search.cpan.org/dist/Test-Expect/ * License : as perl, GPL or Artistic Programming Lang: Perl Description : Automated driving and testing of terminal-based programs Test::Expect is a module for automated driving and testing of terminal-based programs. It is handy for testing interactive programs which have a prompt, and is based on the same concepts as the Tcl Expect tool. As in Expect::Simple, the Expect object is made available for tweaking. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-xen-amd64 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=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 ANSI_X3.4-1968) (ignored: LC_ALL set to en_DK.ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446066: ITP: libdevel-ebug-perl -- A simple, extensible Perl debugger
Package: wnpp Severity: wishlist Owner: Peter Makholm <[EMAIL PROTECTED]> * Package name: libdevel-ebug-perl Version : 0.48 Upstream Author : Leon Brocard, <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~lbrocard/Devel-ebug-0.48/ * License : as Perl itself (ie. artistic or GPL) Programming Lang: Perl Description : A simple, extensible Perl debugger Devel::ebug is a simple, extensible Perl debugger with a clean API. Using this module, you may easily write a Perl debugger to debug your programs. Alternatively, it comes with an interactive debugger, ebug. [... problems with perl5db.pl ... ] Devel::ebug is aimed at fixing these problems and delivering a replacement debugger which provides a well-tested simple programmatic interface to debugging programs. This makes it easier to build debuggers on top of Devel::ebug, be they console-, curses-, GUI- or Ajax-based. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-xen-amd64 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=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 ANSI_X3.4-1968) (ignored: LC_ALL set to en_DK.ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Targeting RPM and Debian from a Debian box?
"Christian Convey" <[EMAIL PROTECTED]> writes: > Is this something people normally do from the same Debian workstation, > or do they typically fire up a RedHat system to do their .rpm > creation, and use a Debian workstation to do their .deb creation? Never done it myself but I would at least built the rpm in a chroot or vserver with the target distribution installed. //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
Andreas Tille <[EMAIL PROTECTED]> writes: > Everybody can change this to something else. Isn't it better > to implement a >/usr/bin/debian-release > that contains an option to get the real version number that > is hard coded anywhere if /etc/debian_version was changed? Why not just use lsb_release(1)? [EMAIL PROTECTED]:~$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux testing (etch) Release:testing Codename: etch [EMAIL PROTECTED]:~$ But I have no idea where these information come from. According to /etc/debian_version I'm running'lenny/sid'. [... less /usr/bin/lsb_release ... ] Hmmm, lsb_release seems to parse 'apt-cache policy' and hardcodes the 'testing is etch' connection. //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DM vs DD and security
Robert Collins <[EMAIL PROTECTED]> writes: > On Mon, 2007-03-19 at 05:41 -0400, Kevin Mark wrote: >> And if its large, then could this be reduced in some way by having the >> more common tasks be replaced by a web frontend with password access >> and leave fewer tasks that require ssh access. > > > Because ssh is /less/ secure than ssl? Yes, because a well written web frontend for a specific task is more secure than a general purpose shell account. //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404292: ITP: netcat6 -- an advanced netcat clone
Aníbal Monsalve Salazar <[EMAIL PROTECTED]> writes: > Package: wnpp > Severity: wishlist > Owner: Anibal Monsalve Salazar <[EMAIL PROTECTED]> > > * Package name: netcat6 > Version : 1.0 > Upstream Authors: Mauro Tortonesi <[EMAIL PROTECTED]> > Chris Leishman <[EMAIL PROTECTED]> > Simone Piunno <[EMAIL PROTECTED]> > Filippo Natali <[EMAIL PROTECTED]> > * URL : http://deepspace6.net/projects/netcat6.html > * License : GPL > Programming Lang: C > Description : an advanced netcat clone > Netcat6 is a total rewrite of netcat, with several advantages: Allready packaged, even with the latest version in testing. [EMAIL PROTECTED]:~/tmp$ apt-cache search netcat6 netcat6 - TCP/IP swiss army knife with IPv6 support [EMAIL PROTECTED]:~/tmp$ //Peter Makholm
Bug#394249: ITP: inotify-tools -- A set of command-line programs providing a simple interface to inotify
Package: wnpp Severity: wishlist Owner: Peter Makholm <[EMAIL PROTECTED]> * Package name: inotify-tools Version : 2.6 Upstream Author : Rohan McGovern <[EMAIL PROTECTED]> * URL : http://inotify-tools.sourceforge.net/ * License : GPL Programming Lang: C Description : A set of command-line programs providing a simple interface to inotify inotify-tools is a set of command-line programs for Linux providing a simple interface to inotify. These programs can be used to monitor and act upon filesystem events. inotify-tools consists of two utilities: - inotifywait simply blocks for inotify events, making it appropriate for use in shell scripts. - inotifywatch collects filesystem usage statistics and outputs counts of each inotify event. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-xen-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libssh - SSH and SCP library
Junichi Uekawa <[EMAIL PROTECTED]> writes: >> Quite untrue. The LGPL doesn't make any difference between those two >> cases. >> > > But that will disallow one option that should be granted through > the use of LGPL: the option to use GPL. Not really. You can still take libssh and mak a derived work of it using GPL as you license. One thing you have to do is to replace the depencies of openssl with libcrypt. -- Peter Makholm | Sit back and watch the messages. This is actually [EMAIL PROTECTED] | more important than one might think as there is a http://hacking.dk | bug in GNU Mach whereby hitting a key during the | boot process causes the kernel to panic |-- GNU Hurd Installation Guide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Russell Coker <[EMAIL PROTECTED]> writes: > It seems that Red Hat has a lot of programs under /usr/libexec that are > under /usr/lib in Debian. One example is /usr/lib/postfix > vs /usr/libexec/postfix. > > It seems to me that /usr/libexec is a better name for such things, and having > the same directory names used across distributions provides real benefits The File Hierarchy Standard[0] uses /usr/lib for these kinds of things and LSB 2.1 explicitly referes to FHS for how the file hierarchy should be laied out. So unless Red HAt is pushing for the relevant standards to be changed I believe we should stick to the standards just so the same directory names may be used acress distributions. 0) http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Pekka Himanen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador <[EMAIL PROTECTED]> writes: >> I disagree. Forcing the user to spend to much time micromanage which >> stuff he wants is not to the bennefit of the user. Neither for the >> unexperienced user nor the power user. > > More or less. One search show both packages and user can read what > each do. Not so dificult ;-) Not if you're the only one splitting packages unneccesary then it doensn't matter. But you're not the only developer. Unneccessary package splits isn't a problem if they only happends for a single package but on a larger scale the means problems. Micromanagement is bad! >> It is bad practise to split packages just because it is posible to use >> some parts of the package. > > Of course. But one dependence like Emacs is. Many users doesn't want > emacs installed and they should be respected. And you still havn't told us what you didn't understand when James wrote: 'If depending on emacs bothers you, make it a suggests.' They *don't* have to have emacs installed! -- Peter Makholm | Why does the entertainment industry wants us to [EMAIL PROTECTED] | believe that a society base on full surveillance http://hacking.dk | is bad? | Do they have something to hide?
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador <[EMAIL PROTECTED]> writes: > The Social Contract say: The focus is the user. So, to enduser is more > easy provide two packages and he can choice what to do. I disagree. Forcing the user to spend to much time micromanage which stuff he wants is not to the bennefit of the user. Neither for the unexperienced user nor the power user. It is bad practise to split packages just because it is posible to use some parts of the package. -- Peter Makholm | If you can't do any damage as root, are you still [EMAIL PROTECTED] | really root? http://hacking.dk | -- Derek Gladding about SELinux
Re: Quote: Debian and Democracy at Advocato.org
Daniel Ruoso <[EMAIL PROTECTED]> writes: > I think this should be clearly discussed. He calls named people village idiots and morons and acuses peoples of 'poor rhetoric'. I don't think that kind of stuff deserves to be discussed anywhere. And if you want to discusse anyway then please do it on debian-projects og maybe rather debian-couriosa where it belongs. I has nothing to do with developing Debian (the distribution). -- Peter Makholm | Perhaps that late-night surfing is not such a [EMAIL PROTECTED] | waste of time after all: it is just the web http://hacking.dk | dreaming |-- Tim Berners-Lee
Re: Which packages will hold up the release?
Joachim Breitner <[EMAIL PROTECTED]> writes: > Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38: >> - Gnome >> - KDE > > I just wondered how far your understanding of these goes? Only the base > environment, or also those applications that don't really belong to - > for example - the official Gnome distribution, but are needed to make I'm neither a Gnome nor a KDE user so I don't really know what it takes for us to have Gnome or KDE. I use some of the Gnome applications but not Gnome as such. The main point is that I don't think we can just drop anything outside base. People expect something of a general purpose distribution. > Also, please include openoffice in this list. Your list certainly is I think you 'use cases' are right for where do we want to be but I'm not sure if they are appropriate for where can we expect to be at the upcomming release. We didn't have OpenOffice at last release and it doesn't seem to be in unstable yet. 'apt-cache search openoffice' only find myspell dictionaries. It would be nice to have but I don't count is as something people would expect from an general purpose distribution yet. -- Peter Makholm |We constantly have to keep in mind why natural [EMAIL PROTECTED] |languages are good at what they're good at. And to http://hacking.dk | never forget that Perl is a human language first, |and a computer language second
Re: Which packages will hold up the release?
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: >> A script that reads packages I'm interested in and prints out the >> RC-bugs I should try to fix would be usable. Does anyone have such >> script? > > Yup. It's been posted before (it's called rc-alert). I've got a copy here; > if you can't find it in the archives (recently, like < 6 months) e-mail me > and I'll send it to you. Found it. http://people.debian.org/~tbm/rc-alert http://people.debian.org/~tbm/wnpp-alert Of course it assumes that the packages I'm interested in are the same as the pacakges I have installed which isn't always true. But it is usable. -- Peter Makholm | Sit back and watch the messages. This is actually [EMAIL PROTECTED] | more important than one might think as there is a http://hacking.dk | bug in GNU Mach whereby hitting a key during the | boot process causes the kernel to panic |-- GNU Hurd Installation Guide
Which packages will hold up the release?
/* You might ignore this comment... Looking at the list of RC bugs the packages seems to fall in two categories. Packages I don't use and packages I don't feel comfortable in touching (glibc being an example of the latter). I don't know the reason for some packages being marked [REMOVE] but it seems to me that it is not just an 'This package is not essential for a releas an useful distribution'. For an example I don't guess that gkrellm-alltraxclock[0] is in any way a package that people think should really hold up the release. 0) Sorry, just a random pick. */ There are some packages we should have if we want Debian to be a general purpose distribution. I guess we can have a long flamewar about which packages this includes and in the end it is the release manager's decission but it is probally something like: - whatever in the Base Utils-section - Gnome - KDE - nethack - apache - XFree - ssh - Mozilla (some sort of) - Emacs (some sort of) - VI (some sort of) - Perl - LaTeX - ... And then some pacakges I've forgot... And then depencies and build-depancies for these packages is needed too. Has anyone tried to make such list of packages we can't release without and made a list of RC-bugs in excatly those packages? I believe this is the bugs it would be most effective to actack when the packages I'm personally directly interested in. It can be hard to look at the RC-list and decide if the time is better spend fixing libtse3, libvorbisfile3, or fam. A script that reads packages I'm interested in and prints out the RC-bugs I should try to fix would be usable. Does anyone have such script? Is this an egoistic approach to fixing RC-bugs? Yeah, and so what? - it is the best possible motivation I can think of. /* You might as well ignore this comment too... I really shouldn't send this mail. It will probally just (re)start some flamewar. Let me have the illusion that the time spend flaminig wouldn't have been used on real development otherwise. */ -- Peter Makholm | If you can't do any damage as root, are you still [EMAIL PROTECTED] | really root? http://hacking.dk | -- Derek Gladding about SELinux
Re: "non-free" software included in contrib
Pierre Machard <[EMAIL PROTECTED]> writes: > In other words you do not agree with the Debian policy. It's quite > amazing since according to : > > http://nm.debian.org/nmstatus.php?email=yeupou%40gnu.org > > You passed the Philosophy and Procedure. There are many developers not agreing completly with our current policy. There is even a mailling list for those subversive people. It is called debian-policy@lists.debian.org where they constantly discuss changing of the policy. Try look at the archive, quite amazing reading, don't you agree. Many (now formely, I hope) respected developers has raised their voices at that list. -- Peter Makholm | I have no caps-lock but I must scream... [EMAIL PROTECTED] | -- Greg http://hacking.dk |
Re: DebToo: Debian, Gentoo-style
Glenn McGrath <[EMAIL PROTECTED]> writes: > Optimised binaries wont run slower than non-optimised binaries. It actually does happen. One reason can be loop-unrolling and cache-sizes. -- Peter Makholm |'Cause suicide is painless [EMAIL PROTECTED] | It brings on many changes http://hacking.dk |And I can take or leave it if I please |-- Suicide is painless
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Tore Anderson <[EMAIL PROTECTED]> writes: > How many other innocent third parties have you spammed through the use > of this broken program? How many of these are Debian users, do you > think? I think we could just as well remove postfix[0] on this account. I have received a lot of so called bounces because some silly postfix installation believes that I have send mail to some non-existant account. 0) Substitute for any MTA you like or dislike. -- Peter Makholm | Have you ever felt trapped inside a Klein bottle? [EMAIL PROTECTED] | http://hacking.dk |
Re: User Based Init
Wouter Verhelst <[EMAIL PROTECTED]> writes: > One can't start or stop anything that requires a port under 1024 (such > as apache) without root permissions. You'll have to give them those, no > other option. Apache doesn't require a port under 1024. By default it is set up to use port 80 på it is quite common to have Apaches bound to some other ports (8000, 8080, being often used). I have often done this as normal user. -- Peter Makholm |One thing you do is prevent good software from [EMAIL PROTECTED] | being written. Who can afford to do professional http://hacking.dk | work for nothing? | -- Bill Gates
Re: NM non-process
Steve Lamb <[EMAIL PROTECTED]> writes: > On Wed, 6 Aug 2003 10:07:40 -0400 > Matt Zimmerman <[EMAIL PROTECTED]> wrote: >> Not if the projects have different goals. > > If the goal is the same only the process to that goal is broken then it is > a waste of time and effort. Not if a new projects succedes in reaching that goal in a way superior to how the present Debian reaches the goal. Organizing a project from scratch can turn out to be the only way change bureaucracy and infrastructure that may make the goal harder to reach. "Plan to throw one away" can also be a good thing on the organizatoinal level. This is only abstract observations I'm not saying that Debian is in a state where it is necessary. I have no ideas for how to change Debian in a rational way whith the present goal as I see it. -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Peeka Himanen
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Evan Prodromou <[EMAIL PROTECTED]> writes: > PM> How the entertainment industry manages to handle their > PM> copyright has nothing to do with free software. > > You know nothing, pink boy. I know a lot of thing and I know that it is impossible for some people to differenciate between free software and how ever the entertainmen industry handles their given rights. So either we should stop here or do som serious flaming: 'pink boy' you should be better than that, try again. -- Peter Makholm |'Cause suicide is painless [EMAIL PROTECTED] | It brings on many changes http://hacking.dk |And I can take or leave it if I please |-- Suicide is painless
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Evan Prodromou <[EMAIL PROTECTED]> writes: > I've used the script to promote freedom. How the hell does you promote freedom by removing stylesheets from html? -- Peter Makholm | Ladies and gentlemen, take my advice, pull down your [EMAIL PROTECTED] |pants and slide on the ice http://hacking.dk |-- Sidney Freedman
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Emile van Bergen <[EMAIL PROTECTED]> writes: > As soon as we can package the real thing, we should probably rename the > HTML/CSS decss as decss-html and release the real decss using a new > epoch. Whit even more confusion to our users for a weak political statement whit no real relation to the project. Read the Social Contract and stop makin political statements unrelated to free software as such which hurts our users. How the entertainment industry manages to handle their copyright has nothing to do with free software. -- Peter Makholm | Ladies and gentlemen, take my advice, pull down your [EMAIL PROTECTED] |pants and slide on the ice http://hacking.dk |-- Sidney Freedman
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Jim Penny <[EMAIL PROTECTED]> writes: (Cc'ed the bug-report) > Uhh, it is to tweak the international copyright cartel, and the RIAA in > particular. They have written "cease and desist" letters to anyone who > has a file names deCSS on their system. If this is the main reason to include it in Debian I would like to voice my objections too (For what it is worth). Given that the political statement is the reason for having this package I belive it is unnecessary cluttering of the archive and added extra confusion to our users. Our main priorities is Free Software and our users and confusing them for a vauge political statement with no real direct connection to free software is against our Social Contract. Robert, I urge you to retract you ITP of this pacakge unless you can come up with technical arguments for including the package. I know the above is worded rather strong and I would probaly not go any further if you decides to keep you ITP. One package doesn't in itself lead to many problems but I would rather stop it before I should fight a to strong precedence to keep useless political statement out of Debian. -- Peter Makholm | Why does the entertainment industry wants us to [EMAIL PROTECTED] | believe that a society base on full surveillance http://hacking.dk | is bad? | Do they have something to hide?
Re: Future releases of Debian
Scott James Remnant <[EMAIL PROTECTED]> writes: > If your package has a bug affecting arm, login to debussy and fix it. > If your package has a bug affecting mips, login to casals and fix it. > If your package has a bug affecting m68k, login to kullervo and fix it. Have I missed something? I can't just log in and install packages on those machines, right? Multi media programs would also be a pain to debug this way and even single non-text media programs could be a pain. And it is my experience that next to pure toolchain-problems it is this kind of programs having most porting problems. -- Peter Makholm |One thing you do is prevent good software from [EMAIL PROTECTED] | being written. Who can afford to do professional http://hacking.dk | work for nothing? | -- Bill Gates
Re: Debian 10th birthday gear
Sebastian Rittau <[EMAIL PROTECTED]> writes: >> 100 million users >> 1000 installations > > I would recommend to exchange these last two lines. More installations > than users? I was thinking about the same. But at home I have at least 3 installations where I'm the only user and then there is my computers I manage at work where the number of users i more undefined. -- Peter Makholm | Why does the entertainment industry wants us to [EMAIL PROTECTED] | believe that a society base on full surveillance http://hacking.dk | is bad? | Do they have something to hide?
Re: Package Moscow ML and HOL
ZHAO Wei <[EMAIL PROTECTED]> writes: > I intend to package Moscow ML and later HOL theorem prover for Debian. > This is not a fromal ITP because I'm not eager to prevent others from > doing the same. :) I won't compete with you too. There have been many attempts to package Moscow ML. I think the latest attempt was made by JP Secher and he made some packages but never uploaded them due to the licensing issues. JP Sechers's ITP: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111560> Som of the discussion from Debian Legal the last time it was brought up (I think) (includes pointers to older discussions): <http://lists.debian.org/debian-legal/2002/debian-legal-200210/msg00135.html> -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Peeka Himanen
Re: Bug#198190: ITP: upx-ucl-beta -- an efficient live-compressor for executables (beta version)
Robert Luberda <[EMAIL PROTECTED]> writes: > I intend to package an unstable (beta) version of upx. > This version supports compresing of the Linux kernel and thus > can be used by our boot floppies team. Isn't the kernel already compressed? -- Peter Makholm |One thing you do is prevent good software from [EMAIL PROTECTED] | being written. Who can afford to do professional http://hacking.dk | work for nothing? | -- Bill Gates
Re: Returning from "vacation". (MIA?)
Clay Crouch <[EMAIL PROTECTED]> writes: > On Tue, May 13, 2003 at 10:48:45PM -0400, Matt Zimmerman wrote: >> That .sig is problematic beyond just its content; it is 12 lines long and >> adds almost 1kb to each of your messages (probably longer than the contents >> of many messages). > Pleased to meet you > > *plonk* Nice entrance. Let me predict the future. Within a month you have kill-filled anyone in the project who matters more than just maintaining a few packages. And most of us has has given up on you. -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Peeka Himanen
Re: fixed libstdc++5 package
Matthias Klose <[EMAIL PROTECTED]> writes: > Btw, looking at the reports, I see 30 submitted from i386 architectures, > one from a powerpc machine, none from other architectures, although all > architectures are affected. Conclusions? ;-) The general i386-user is so stupid that they can't handle running unstable? -- Peter Makholm | There are 10 kinds of people. Those who count in [EMAIL PROTECTED] |binary and those who don't http://hacking.dk |
Re: Do we need policy changes?
Nikolai Prokoschenko <[EMAIL PROTECTED]> writes: > My problem was: everybody was acting like mad, screaming "at last, > some good fonts for linux!", whereas, as far as I remember, these > fonts lacks many many scripts, starting with the simpliest ones like > Cyrillic. I don't even want to mention double-width characters. The What do you suggest? Shouldn't we package these fonts before they are of use to everybody? > used by me, as I need e.g. both German and Russian. I can as well file > a bug against it, but it wouldn't matter much, as the maintainer would > just say 'it's not supported upstream' and nothing would happen. Other What do you suggest? Well at least the maintainer should probally forward the bug upstream and mark it forwarded. Not that this alone would help very much. The only way to really improve the general situation is if someone who cares does the work. For exampel the IPv6-developers has done a lot of work this way. Finding packages with disabled IPv6-support finding patches and pushing them upward a that kind of stuff. You as utf8-interrested have to do the same to improve the situation. > language environments had been (I'm just speculating) a part of Debian > Policy. In that case, package at least could have been marked as > 'non-functioning under non-latin circumstances' and this could We have the BTS for this kind of information. And why should we pull packages that works 95% of the time? That would be damaging. Please find some way to improve the situation without doing great harm to those statisfied with status quo. If you force people to put a lot of work in something they don't want they are going to be even more resisting changes. > Thank you for your time, and you want to tell me I'm paranoid, don't > bother, it is not worth your time :) Better tell me what I might have > missed in the observing the subject. I doesn't think any of the above counts as paranoia which obvious doesn't mean that you aren't paranoid. What you have missed? Probally some basic facts of how stuff is done with the least damage. -- Peter Makholm | I have no caps-lock but I must scream... [EMAIL PROTECTED] | -- Greg http://hacking.dk |
Re: Why am I receiving still mails from this list?
Joe Drew <[EMAIL PROTECTED]> writes: > Which he obviously did, given that he stated that he unsubscribed once, > apparently successfully, still received mails, and then tried again, and > the list said he wasn't subscribed. And did he then contact [EMAIL PROTECTED] when he had trouble? I guess it is that line Matt was refering to. -- Peter Makholm |I congratulate you. Happy goldfish bowl to you, to [EMAIL PROTECTED] | me, to everyone, and may each of you fry in hell http://hacking.dk | forever | -- The Dead Past
Re: Next Debconf
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > I am planning Debconf 3 to be held in Oslo, from Friday July 18th to > Sunday July 20th. Nice initiative. -- Peter Makholm | I have something to say: It's better to burn in [EMAIL PROTECTED] | hell, than to fade away! http://hacking.dk | -- Kurgan
Re: Packages still in Potato
David Starner <[EMAIL PROTECTED]> writes: > And what makes you think there has been no new upstream versions for all > those packages? Nothing. I commented on you general opinion. -- Emacs er det eneste moderne styresystem der ikke er multitrådet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still in Potato
[EMAIL PROTECTED] (Otto Wyss) writes: > IMO each package should at least once per release upload a status > report. Also there was ample time for the transition of each package to Disagreed. We should make package uploads just to make uploads. If a package works, has no new upstream versions and doesn't get outdated policywise there is no need for a new version of the package just because we're making a new release. (Well it might be impossible for a package in potato not being policywise outdated) -- Emacs er det eneste moderne styresystem der ikke er multitrådet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [kde] and, for my next trick ...
Daniel Stone <[EMAIL PROTECTED]> writes: > Oh, there *appears* to be one? You mean the one I sent this message to, > and the one that I'm subscribed to? Right! Thanks for the information! I > sent it to -devel because not all KDE users are subscribed to -devel. And since when has users generally been subscribed to -devel? If we have a KDE-specific development list then please use that instead of -devel. If you want to reach users -devel is the wrong list anyways. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: 1 package(s) to rebuild on i386/stable
Dominik Kubla <[EMAIL PROTECTED]> writes: > IMHO that should be updated to nfs-utils-1.0 from upstream, if it > only were for the psychological impact of the 1.x version number. 'psychological impact' isn't a valid argument for putting new versions of software in stable. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Relicensing rules (was: Re: BitKeeper)
Branden Robinson <[EMAIL PROTECTED]> writes: > On Thu, Jan 03, 2002 at 01:13:13PM -0800, Thomas Bushnell, BSG wrote: >> OK, perhaps the relicensing rule is not non-free; I'm less sure of >> that. > > I don't think it's obvious from a casual reading of the DFSG that such a > requirement is non-free, but perhaps it should be. I don't think it is obvious from a very through reading of the DFSG that such requirement is non-free. I would judge that it was eiter considered free or never even thought about when the DFSG was written. (probaly the second reason) I don't see any reason for making such requirements non-free. I still got all the freedoms FSF prescribes, I can make modifications and share them. I cannot decide myself under which license my modifications is distributed under but not even GPL allows me to do that. The only reasonable change in this direction I could see for the DFSG is to use some sort of O'Reillys Zeroth Freedom (If I understand him correctly): You should be able to make modifications on you own premisses. No matter how much I like this freedom for my own works I wouldn't like see it in DFSG. It would render GPL and copyleft-licenses in general non-free. Shouldn't we move this to debian-project or debian-legal? -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: BitKeeper
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > OK, perhaps the relicensing rule is not non-free; I'm less sure of > that. But the outright prohibition of certain modifications certainly > kills it. I only talked about the relicensing issues. I'm sorry it wasn't clear by my quoting (I can see that my quotes could easily be misunderstood) > 1) Regardless of whether various legislatures have redefined the word >"terrorism" to include illegal breaking into computers, I don't >accede to their craziness. Wrong, perhaps, but not terrorism. I think I learned the word terrorism in relation to the European terrorism in the 70's. I am quite aware that it has nothing to do with the paranoia of today. You idea reminds me about that kind of terrorism. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: BitKeeper
Junichi Uekawa <[EMAIL PROTECTED]> writes: > Please elaborate. There is nothing in the DFSG saying the a licens can't require you to give the original autor all rights to you changes. So that single part of the license I refered to does not makes it even more or even less non-free. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: BitKeeper
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > Bitkeeper is (as you note) not free. Not only the usage restrictions > are a problem, but also the requirement that changes you make may be > distributed by BitOwner "under any license". Thats not non-free in any way. The Freedom DFSG describes is not freedom for the developers but for the users and such restriction doesn't apply to ordinary users. The NPL (and MPL IIRC) has the same requirements. > One strategy would be to bring down all the Open Logging servers, and > keep them down for six months. Then it reverts to the GPL. :) Please don't even suggest such actions not even in jokes. It would be very sad to see Open Source fanatics use terorism to spread the use of open source. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: What config file for a .pm perl module ?
Eric Van Buggenhaut <[EMAIL PROTECTED]> writes: > The upstream code requires the administrator to introduce the user > data (username, password, port, database, etc.) in the same Password.pm file, > which looks horrible to me. Ok, we've seen some solutions but the real problem remains: The perl modules in question can only be used proberly by users with acess to the configuration file. Why shouldn't normal users be able to use the module in a unrestricted way? Perl programmers should be able to make a config-hash themself and feed that to the module (probaly the constructor for the objects belonging to the module.) -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake 2 sources GPL'd
Branden Robinson <[EMAIL PROTECTED]> writes: > In fact, I would consider it acceptable in general to move everything in > contrib to main as long as it each package was forced to be priority All my messages in this thread have the premise that we want to keep a distinction between contrib and main. When this premise doesn't hold my objections against quake2 in main of course falls. Taking this step back and discussing wether we want to keep that distinction could be interesting. I'm not against merging contrib and main but the merge shouldn't be hidden away behind "This code could be educational"-arguments for each package. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake 2 sources GPL'd
Dale Scheetz <[EMAIL PROTECTED]> writes: > But I wouldn't dream of trying to do such a thing without a game engine to > test it on. How else to you test what you built? Why would you ever build > a game without an engine to run it on? How is preventing you from installing quake from contrib or in any other way? The only thing I think people has said is that as long as there doesn't exists frre levels Quake should go into contrib and not into main. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake2/GPL: At least source should go into main
Erich Schubert <[EMAIL PROTECTED]> writes: > At least the Source _is_ useful for novice programmers that are > interested in 3d game programming. How does Quake differ from any other projects in contrib in this way? Contrib consists of free things where the source is available and therefore can be used as education for interested programmers. The only reason that it isn't in main is that it is unuseable without extra stuff that can't be placed in main. Putting Quake in main would make contrib unneeded. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake 2 sources GPL'd
David B Harris <[EMAIL PROTECTED]> writes: > But with Quake2, you can be pretty damned sure that there will be at > least dozens of people coming up with fully Free stuff that can be used > as quake2-data. When that day comes, then we could move quake2 to main. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake 2 sources GPL'd
Hamish Moffatt <[EMAIL PROTECTED]> writes: > Regarding packaging the Quake sources for educational benefit; If the Quake sources could go into main without any free data then why can't any other package in contrib go into main because the code could potentially be educational. (Sarien for exanple) Bottom line: If Quake goes into main we could as well move everything in contrib into main too. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake 2 sources GPL'd
David B Harris <[EMAIL PROTECTED]> writes: > There's no reason why the engine itself can't be included in Debian, as > far as I'm concerned. It doesn't absolutely *have* to have game data, to But thats is an argument for putting all the stuff in contrib into Debian main. -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: Quake 2 sources GPL'd
Ben Collins <[EMAIL PROTECTED]> writes: > That's not true. If it is possible to create game levels for it that are > free, than it is considered free. It's not like you can't get anything > but id's game data. Are you sure? I have sarien, a interpreter for old Sierra games, in contrib because I havn't found any games I could distribute in main. Should that be moved to main? (The Sarien-package doesn't provide tools to make games youself I don't know if Quake does) -- Når folk spørger mig, om jeg er nørd, bliver jeg altid ilde til mode og svarer lidt undskyldende: "Nej, jeg bruger RedHat". -- Allan Olesen på dk.edb.system.unix
Re: how can Euro symbol be displayed under X [4.0.3]?
Wolfgang Sourdeau <[EMAIL PROTECTED]> writes: > Since ISO-8859-15 is basicall ISO-8859-1+euro+some other characters. > Why is the "@euro" needed ? A few often used chars has changed. So it is important to know which cahrset is used. For example 1/2 and the french oe-ligature seems to be on the same place. I have no idea if there is other differences between the two locales, but you could expect that LC_MONETARY=es_ES and [EMAIL PROTECTED] would give different behaviours from some programs. -- hash-bang-slash-bin-slash-bash
Re: [users] Re: Where's lame
MaD dUCK <[EMAIL PROTECTED]> writes: > package tree. i would like to adopt the lame mp3 encoder as a debian > package and was wondering if there are any objections? is there > already a maintainer? can this packet be debianized? Please read http://www.debian.org/devel/wnpp/unable-to-package Make sure that there is a new situation with respect to the Frauenhoffer patent before proceeding with this. -- hash-bang-slash-bin-slash-bash
Re: Where does iswedish come from?
Mikael Hedin <[EMAIL PROTECTED]> writes: > Anyone knows where the 1.3 source comes from? The content is totally I think it originates from some ftp-server in .uk which had a lot of different ispell dictionaries. > different from the iswedish-1.x at sslug. Any advice on what to do? Get the latest from http://sv.speling.org/filer/ispell-sv-1.3.2.tar.gz Check if it is not much worse than the present iswedish package. (Extract the words that is in the old and not in the new) 1.3.2 should be later than 1.3 in Debian version number. But we could get Jacob Sparre to bump the version numbers if needed. -- hash-bang-slash-bin-slash-bash
Re: LILO 21.6-2
Manoj Srivastava <[EMAIL PROTECTED]> writes: > At the moment, if there is no lilo.conf, the kernel-image > postinst creates a functioanl lilo.conf that takes into account Is this wise? I assume that in a perfect world the lilo package would be better to configure itself than some "random" other package. The lilo package would have more knowledge of which special things to consider, eventually after consulting the user. Consider this: Kernel-image gets installed and finds no lilo.conf and makes a minimal but functional lilo.conf. Then lilo gets installed, it finds a lilo.conf and decides not to touch it (what a nice package). What the user now doesn't know is that the lilo packages configuration of lilo.conf would have given him the oputunity to use a password on lilo or some other fancy feature. Nobody should touch the configuration files belonging to lilo but the local sysadmin and the lilo package itself. And the lilo package should rather be a little less fancy in it's install than destroying existing configurations.
Re: lilo.conf
Russell Coker <[EMAIL PROTECTED]> writes: > boot=/dev/ide/host0/bus0/target0/lun0/disc > root=/dev/ide/host0/bus0/target0/lun0/part3 Don't assume devfs! A lot of us uses it, but before our standard kernel uses it our lilo package shouldn't assume it unless it is very sure that it will work.
Re: What to do about /etc/debian_version
Michael Stone <[EMAIL PROTECTED]> writes: > Move it to /var/lib/dpkg Nope, debian_release is independent on the dpkg used. /var/lib/dpkg/ would be a most unintuitive place to place the version of the distribution as a whole.
Re: Unclean licences
"Pawel Wiecek" <[EMAIL PROTECTED]> writes: >These programs are freeware, which means that they may be distributed >freely. Nope, we should explicitly have the rights to distribute and modify the program.
Re: our broken man package
Lars Wirzenius <[EMAIL PROTECTED]> writes: > On the other hand, we might want to copy the OpenBSD version instead > of maintaining our own man. But I leave that to whoever maintains the > packages. We have alternatives on almost everything but dpkg and man. If someone thinks it's worth the effort to make alternatives for these they should do it. If there is a general agreement that the alternatives is better than the original packages we just switch prioryties. So simple is that.
Re: bugs + rant + constructive criticism (long)
John Galt <[EMAIL PROTECTED]> writes: PLEASE DON'T CC ME. I'M ON THE LIST > FYI 28 (aka RFC 1855) is the standard. Strictly speaking it's is only a standard if it is on the Standard Track and RFC1855 isn't. It is only an informational RFC. PLEASE DON'T CC ME. I'M ON THE LIST
Re: bugs + rant + constructive criticism (long)
Riku Voipio <[EMAIL PROTECTED]> writes: > Which reminds me, why doesn't this list just set: > > reply-to: debian-devel@lists.debian.org Please read "``Reply-To'' Munging Considered Harmful" http://www.unicom.com/pw/reply-to-harmful.html> It should say it all.
Re: bugs + rant + constructive criticism (long)
Jim Lynch <[EMAIL PROTECTED]> writes: Could you please read the Developers Reference section 4.1 second paragraph. > When machines break for whatever reason, sometimes people come to > #debian for help. It's unhelpful to encourage people to break their > mission-critical servers... If Eric wants to do it himself, fine. Call me cynical but if people doesn't read documentation, fine with me. But you can tell me what is hard to understand at http://www.debian.org/release/unstable/: This distribution is currently in ``testing'' phase. That means that things might break if you run it. Anyone running woody is expected to be informed about any volatilities, usually by following developer-oriented mailing lists; But that is an old discussion. > Of course, not many developers like coming to #debian due to its > present noisiness and relative newbishness, or maybe for other If the existence of unstable should be a secret on #debian I understand why others developers doesn't come there anymore.I only shows up on devel once in a while and mostly to see the topic or hear why unstable broke but that is primaly because I don't really wants to waste time on irc.
Re: bugs + rant + constructive criticism (long)
Jim Lynch <[EMAIL PROTECTED]> writes: > If you want to advocate the use of unstable software, please be my guest... > but not on #debian. it changes daily, and can potentially break every Again, what is you right too say so other than it is you oppinion?
Re: test -d /usr/man && mail submit@bugs
Arthur Korn <[EMAIL PROTECTED]> writes: > > for package in dpkg apt libc gpg bplay etc ; do > > sed [...] bug.template | mail ; > > done > > You'd better use [EMAIL PROTECTED], else you need a very > good asbestos suit ... Whatever, the above won't work for other reasons (It just tries to chewck you mail a couple of times. I thought of sendmail(1) where you feed the headers with the mail. and thats why I didn't send explicit to maintonly. Every mass bag submit should be maintonly no matter how you do it technically.
Re: 'testing' & dep conflicts
Sven Burgener <[EMAIL PROTECTED]> writes: > 1. Why are packages kept back like follows? > >$ apt-get update && apt-get upgrade Upgrade will never install new packages. So packages with changed depends-fields will not be upgraded by this command. Read the manual you can read it there.
Re: test -d /usr/man && mail submit@bugs
Chad Miller <[EMAIL PROTECTED]> writes: > I don't suppose there's a easy way to submit a batch of bug reports, eh? Just do a for package in dpkg apt libc gpg bplay etc ; do sed [...] bug.template | mail ; done where sed do the right thing. That is an easy way, right? (say yes!)
Re: What do you wish for in an package manager
Jeffry Smith <[EMAIL PROTECTED]> writes: > download the source, have my machine do the compile, but still have > all the dependencies properly worked out (sort of an expanded apt-get > -b source). I guess you should get both the ordinary depends and the build-depends. I fail to see where there should be problems. It's "just" a depency-check. Ohhh, depencies is placed in debian/control and most of the times it is decided on compile time which packages to depend on. That could be a problem if you only want one download phase. Is there examples of packages where build-depends is available but the newly build package is not instalable on the system? (And should this could happen)
Re: What do you wish for in an package manager?
"Dwayne C . Litzenberger" <[EMAIL PROTECTED]> writes: > So my question is: What do you wish for in a package manager? I agree with Ethan. Start explaining why you want to reinvent the wheel then we maybe has some ideas for things to do when you reinventing for other reasons. The only feature I've ever tried designing a solution for (and mostly because on some interesting technical problems) is delta/diff packages where you only downloads the changes if that would take lesser time (by some measure).
Re: Bug#80384: ITP: coldsync - Palm synchronizer/conduits tool
[EMAIL PROTECTED] (Colin Watson) writes: > It's already in unstable: > > [EMAIL PROTECTED] ~]$ dpkg -p coldsync > Package: coldsync Well, I probally only looked in woody.
Bug#80384: ITP: coldsync - Palm synchronizer/conduits tool
Package: wnpp Serverity: normal Version: N/A I intend to package the following program if nobody is working on it all ready (couldn't find anything at bugs.debian.org/wnpp): Package: coldsync License: Artistic Homepage: http://www.ooblick.com/software/coldsync/ Description: A Palm syncronizer and conduite tool ColdSync is a tool for synchronizing PalmOS devices (PalmPilot, Palm V, Qualcomm PDQ, etc.) with Unix workstations. It defines a protokol for conduites and includes a perl module for making it easy to write conduites in perl.
Re: update excuses.. how to read them
Joey Hess <[EMAIL PROTECTED]> writes: > One easy way would be if you provided a set of web pages by maintainer, > then I could just "subscribe" a lynx --dump cron job to mine.. It would be very nice to get such information automatically but I don't care how I get it so the above would work fine.
Re: ITP hodie
Miros/law `Jubal' Baran <[EMAIL PROTECTED]> writes: > Oh, package it. We have ddate for Discordians (in util-linux), we could > have hodie for Ill^WRome citizens. ;-> I've been convinced that it's not only making a nice latin locale. I'm only trying not to waste hacking time on packaging something allready done. Lat's package everything and the kitchen sink but let us not package anything twice. -- Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WARNING: potato has horrible broken locales
Mirek Kwasniak <[EMAIL PROTECTED]> writes: > Today I've trying (in bash): > > ls /dev/tty[a-z]0 > > and answer has unexpected /dev/ttyI0 and /dev/ttyS0 followed by > /dev/tty[a-z]0 entries. I've seen this comming up a lot of places the past few months. It looks like somebody wants to redefine [a-c] to mean [aAbBcC] instead of [abc]. I don't like this change, but it looks like it's is going to be either posix standard of locale dependent (by posix standard) in the future. It will break scripts, but it doesn't seem like anyone cares about that (Ohhh, I imagine there is a major flamer war going on somewhere). The future proof and locale portable way to do the above is: ls /dev/tty[[:lower:]]0 On pandora I just did the following: $ touch a b c A B C $ echo [[:lower:]] a b c $ echo [[:upper:]] A B C $ echo [a-c] a b c $ -- Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security of Debian SuX0r?
Peter Palfrader <[EMAIL PROTECTED]> writes: > I'ld prefer keeping 755 as a default. I prefer 755 too. Peeking in others configuration files has been one of my best way of learning new programs at uni. I prefer a singel 'users' group for users as standard too, but lets not change the default settings unless we have strong reasons to do so. I have not seen any security related problems with the 755-mode of home directories but I would like to be educated if I'm wrong. -- Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP hodie
"Christian T. Steigies" <[EMAIL PROTECTED]> writes: > What does it do? > It has the same functionality as the date (1) program, only... It > has it in grammatically correct latin. Couldn't this be done with gettext and the normal date comand? -- Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/ITP: everybuddy-cvs
"michael d. ivey" <[EMAIL PROTECTED]> writes: > My current idea is everybuddy-cvs, and make it conflict with everybuddy, > and conflict/replace ebsnap, for the people who may have downloaded > ebsnap. Is that the correct way to proceed? People using unofficial packages should be aware about the dificulties. So I wouldn't mention the unofficial packages in control files for official Debian packages. I also don't like the idea of having special packages for cvs-versions of software. It is cruft. Just my 0.02 of whatever currency you prefere. -- Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security of Debian SuX0r?
Bob Bernstein <[EMAIL PROTECTED]> writes: > So there's a warning? At least MD5 *can* be implemented at install-time. Why > doesn't he mention that Caldera for one doesn't even offer MD5 as an _option_ > at install-time? Next: What Caldera do doesn't matter at all. Neither does it matter what anyone else does. Debian should just be a reliable (securitywise) distibution which is safe to use if you not clueless. I've just helped a friend instaling Debian. He had two comment about the above question. Is it the red or blue button there is active? It is badly marked which button you are about the press. The other comment is something about the wording of two of the questions. The firste question was saying something like "Do you want to keep the standard (less secure) option" and the next question said "Would you use the new (more secure) option". If the user just thinks that he wants the most secure box but not really reading precisly what it says he will say "no" to both questions. (That was what we did). I don't really remember which questions it was, but I'm almost sure one of them was the MD5 password question. -- Peter
Re: Implementing "testing" (was: Re: Potato now stable)
Joey Hess <[EMAIL PROTECTED]> writes: > It's beautiful. I want it now. :-) I couldn't agree more. We could always fine tune it when we know how it works with live data. But I think you'right. Some way of chrash-install into testing would be nice when dealing with root-exploits. -- Peter
Re: WG: Broken bootable SPARC CD#1, and why this happened
[EMAIL PROTECTED] writes: > Not for me... Life is nice isn't it? (And then stop sending this "Not for me"-answers all the time or something bad could happend) -- Peter
Re: Intent To Split: netbase
Andreas Fuchs <[EMAIL PROTECTED]> writes: > Good enough for you? Good enough for anyone? ajt? (-: Bad idea. Then you also want every X11-app to ask if it should install itself in /usr/X386/bin or somewhere else and every game-like app if it should instaal it self in /usr/bin or /usr/games? Either agree on placing the different programs one place og agree to disagree. I have had /sbin and /usr/sbin in my PATH for years neither my sysadm or me have any problems with that. -- Peter
Re: [PROPOSAL] update-binfmts - manages the binfmt_misc kernel module
[EMAIL PROTECTED] writes: >But then again this may be overloading the package system since there >are quite a few kernel modules... But it would be nice with some standard way to specify a "depend" on a kernel-option and a "provide" of options for kernel patches. I don't know any way to check for it but just a field saying "You need this" would be good. -- They say that the Lost Tomb is a bad place to die.
Re: "GNU/Linux" vs. "Linux"
Martin Schulze <[EMAIL PROTECTED]> writes: > http://www.debian.org/doc/FAQ/ch-basic_defs.html#s-gnu I've read that before. I'm to new of a developer to know anything. But isn't the story that Debian started with strong connections to FSF, dropped them and then after a long flamefest reestablished them with the Debian GNU/Linux name? (It's the "we are happy to comply with that request." part I'm not sure about.) Is there a website with the debian-history package online? And does that tell anything in support of my knowledge? Facts not flames, please (Not that you care). -- They say that the Hand of Elbereth can hold up your prayers.
Re: ITP: manpages-da
Paul Slootman <[EMAIL PROTECTED]> writes: > Wouldn't manpages-dk be the correct name? That depends The two letter language code is da and the two letter country code is DK (making the correct locale: LC_ALL=da_DK) There shouldn't be any problem using the manpages in Greenland (ie da_GL) but if you're speaking english in Denmark (en_DK) you shouldn't use them. Making a long story short: I think we should use the language code and not the country code. -- Wish for a master key and open the Magic Memory Vault!
Re: Idea: Debian Developer Information Center
Raphael Hertzog <[EMAIL PROTECTED]> writes: > Hey people ! I posted this mail in order to have some input ... it would > be great if some of you gave their opinion about this proposition I posted > a while ago : Just like everyone else: A great idea to which I have no futher idears right now. If I wasn't to afraid to sound to AOLish I would have posted a "good idea" to the first post. -- A chameleon imitating a mail daemon often delivers scrolls of fire.
ITP: manpages-da
In SSLUG (swedish/danish LUG) we have begun translating man-pages to danish. when we have finished a nice set (like file-utils) I will make a debian package out of it. -- You can get a genuine Amulet of Yendor by doing the following: --More--
Intention to hijack: {i,w}{danish,swedish}
I intent to hijack the danish and swedish ispell dictionary and wordlist. The packages seems unmaintained and have 4 unaknowledged bugs more than 200 days old. I have unsucessfully tried to contact the maintainer but got no respons. If anyone else is willing to do the swedish packages they are welcome, if not I would try taking care of them. If noone objects within a week I will begin to look at the packages and process the bugs and upload new packages to frozen some days after that. -- They say that a neutral character would get either Fire or Frost Brand.
Re: YAPFSR: Yet Another Proposal For Speeding Releases.
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes: > But keeping the RC bug count low. A RC bug will only be permitted to stay > for long if it is related to a release goal. And people must be working for Since we don't have release goals it would even be easy to implement. -- They say that a baby dragon is too small to hurt or help you.
Re: New bug horizon
Richard Braakman <[EMAIL PROTECTED]> writes: > I have set a new "Bug horizon" two weeks from now (March 27th). The > same rules apply. The list of bugs involved is appended to this mail. No it wasn't! At least not in my incarnation of the mail. -- Being digested is a painfully slow process.
Re: ARGH!!! Re: ITP: jnethack
Vincent Renardias <[EMAIL PROTECTED]> writes: > > - All messages were translated to Japanese language. > Can you *PLEASE* try to merge this patch with the upstream version 1st. > If the patch is done correctly, I see no reason the upstream maintainer > should refuse it. (And if he does, why should Debian accept it?) Nethack has no support for multiple languages, and it would take a major rewrite to let it use different languages. I can't think of any easy way to merge japanese messages into the existing nethack code without removing the english. Speaking of Nethack, it has a y2k problem. I hope it's the only one in Debian -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, "The Dead Past"
Re: Problem with the latest potato update
Matthew Vernon <[EMAIL PROTECTED]> writes: > > Latest potato update contains a package, aleph-dev, with a wrong > Priority: > > line which prevents (until manually fixed) the apt update operation, which > > aborts with: > File a critical bug, if no-one has yet done so. There has been filed enough bugs against this problem. And a new aleph packages is waiting in incoming. -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, "The Dead Past"
Re: Conference! - around the world with Debian
Russell Coker <[EMAIL PROTECTED]> writes: > For those of us who attend in multiple countries we could book plane flights > together (hopefully get a good deal), play network Quake in the plane, etc. Then we need a sponsor with a big wallet. Arcording to userfriendly airphones cost 200$ a minute and I can't afford that. -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, "The Dead Past"
Re: GPG trusted signatures, dpkg-buildpackage & gpg
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Perhaps we should change that so gpg will be used by default if > $HOME/.gnupg/secring.gpg exists? Anounce it first and wait some time. I have a $HOME/.gnupg/secring.gpg but my key isn't in the debian keyring (yet). -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, "The Dead Past"
Re: Crazy Idea: debian developer conference
Chris Rutter <[EMAIL PROTECTED]> writes: > Problem is there ain't an `average developer' in terms of location, > as far as I can see -- they're all over the place. ;-) I'd > certainly rather somewhere Scandinavian, probably -- it's nice, > clean, historic, etc. -- and closer to home. I'd like to have this kind of stuff in Scandinavia. But I think it would be nice with a place where some active debian developers i settled. It would make the on-location planning more easy. I havn't seen many Scandinavian developers. But I for sure could be talked into doing some on-location research in Denmark. (But time, my friends...) -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, "The Dead Past"
Re: Crazy Idea: debian developer conference
Joey Hess <[EMAIL PROTECTED]> writes: > Wouldn't it be great if all the debian developers could be flown in to a > convention site, get to meet each other, really tighten up the gpg web of Great idea. And I will attend if my bank let me do it. Orelse I should just begin to attend some of the european conferences and meet fellow debian developers there. -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, "The Dead Past"
Re: Suggestion: new "debian" archive section
Julian Gilbey <[EMAIL PROTECTED]> writes: > I propose that the distribution should have a new "debian" section > which would be the place to put all of the Debian-specific packages, This or some way to make orthogonal sections would be great. -- Peter er den mindst gamle af de gammeldags usenettere, og moderator på den eneste modererede gruppe i dk.*, so there. - citat RockBear
