Re: And now for something completely different... etch!
Andreas Gredler <[EMAIL PROTECTED]> writes: > On Sun, Jun 12, 2005 at 02:17:08PM +1000, Russell Coker wrote: >> On Sunday 12 June 2005 09:14, Frans Pop <[EMAIL PROTECTED]> wrote: >> > Some older BIOSes don't allow booting from CD-ROM, let alone netbooting or >> >> It's easy to solve the problem of a BIOS that doesn't support booting from >> CD-ROM. You have a boot loader on a floppy disk that loads the kernel and >> initrd from CD. > > This is of course a good workaround. But this floppies have to be > available. Does debian have such floppies? > >> People who have really old hardware should ask at their local LUG if someone >> has any unused computers that they don't need. I've offered quite a few old >> computers for free to members of my LUG. Recently I offered a P3-800 >> machine >> with broken PSU and a Pentium 200 machine that was fully operational and >> found no-one who wanted them. It seems that at my LUG there's no-one who >> has >> lesser hardware. > > I've seen a lot of servers for small companies, which are older ;-( > > greets Jimmy The i386 CD images contain a floppy image of the smart boot manager (sbm) that allows you to boot cdroms on hardware that doesn't. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Steve Greenland([EMAIL PROTECTED])@2005-06-09 10:06: > I suspect that the problem is that you're confusing "obsolete" with > "not current". "Obsolete" caries the connotation of "useless except for > entertainment/hobbiest purposes". For example, steam engine cars are > obsolete. The 1999 Toyota Camry is not. Of course, one should remember that obsolescence is subjective. Some might argue that the 1999 Toyota Camry was obsolete at birth while a steam engine car is still an attractive proposition :-) Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Sun, 12 Jun 2005, Wesley J. Landaker wrote: > > The basics of the new format are: > > * Multiple upstream tarballs are supported: > > * The "Debian Diff" may be replaced by the "Debian Tar": > > * Bzip2 compression is supported as an alternative to gzip. > > As a practical matter, how soon will these really be supported in Debian? Is > dpkg change all that is needed? i.e. Could I upload a new revision of a > package that has multiple upstream tarballs, and a debian.tar.bz2 right > now, or are there a lot of other things that have to change first? Historically we always wanted to be able to use all the source in the archive with the tools available in stable. If that policy is still true you would be able to use the new features by the time edge releases with the new dpkg. That is in some 10 to 18 months :) -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312897: ITP: texlive -- The TeXlive system packaged for debian
Christoph Berg <[EMAIL PROTECTED]> wrote: > Re: Norbert Preining in <[EMAIL PROTECTED]> >> * Package name: texlive >> Description : The TeXlive system packaged for debian >> >> TeX Live is an easy way to get up and running with TeX. It includes all >> major freely-available TeX-related programs, macro packages, and fonts, >> including support for many languages around the world. > > The website looks like that's a "live" tex CD. What's the difference > to a normal "apt-get install tetex-extra" installation on Debian? Let me add some comments from my point of view (Debian teTeX maintainer). There is a significant difference between texlive and teTeX, and I think that Debian users, as well as developers, will benefit from texlive being packaged. First of all, texlive is much more comprehensive than teTeX, it contains virtually the complete CTAN archive as far as the software is DFSG-free (yes, the texlive team specifically uses the DFSG), whereas teTeX contains only a subset of the more popular - or more traditional, in some cases - (La)TeX packages. Second, texlive has a very elaborate structure of subpackages that allow to install exactly what you need, whereas teTeX is one monolithic piece of data, and has been split into -bin, -base, -extra, and -doc only by the Debian maintainers. And this splitting is by no means satisfying; people always asked for finer splitting, but this is hard to do, and in fact parts of -extra should be put back into -base because they belong to a LaTeX Base Distribution. Finally, texlive has a promised, and, as far as I know, always fulfilled release schedule of "once per year", whereas teTeX is released not only "when it is ready", but also "when the upstream author has time and thinks it is necessary". Taking things together, I think that texlive will be the much better choice for users who install a TeX system on their home box to actually write LaTeX (or ConTeXt) documents, and who perhaps use testing, anyway. On the other hand, an admin on a multi-user box might better stick to teTeX, and specifically for the buildd's teTeX will provide a more conservative environment. This point is particularly important from my point of view. teTeX 3.0 came out in February this year, and we were never sure whether we should try to put it into sarge: Uploading it (or the release candidates) to unstable during the past year would have caused havoc for the buildd's, I'm sure, revealing tons of RC bugs in package documentation and documentation systems. On the other hand, teTeX 2.0 from 2003 is pretty useless for users who expect support from the LaTeX community, or for LaTeX developers - and this is going to get worse during the lifetime of sarge. If we had texlive in Debian, there wouldn't be such pressure. teTeX would be updated to the current version shortly after a release, and then would stick to that upstream version no matter what happened until the next release. And the buildds and package maintainers would be happy. Regards, Frank P.S. please Cc me on replies, I'm not subscribed to -devel currently. -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bits from the dpkg maintainer
ma, 2005-06-13 kello 10:10 +0200, Peter Palfrader kirjoitti: > Historically we always wanted to be able to use all the source in the > archive with the tools available in stable. If that policy is still > true you would be able to use the new features by the time edge releases > with the new dpkg. That is in some 10 to 18 months :) Unless we update sarge with a new version of dpkg that can handle the new source format, of course. ;-) That is, however, probably a bad idea. dpkg it too critical a piece for a Debian system for us to muck about it more than we have to, in a stable release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Inconsistent handling of sourceless packages in main
On Sat, Jun 11, 2005 at 07:12:52AM +0200, Goswin von Brederlow wrote: > Eduard Bloch <[EMAIL PROTECTED]> writes: > > > Moin Goswin! > > Goswin von Brederlow schrieb am Donnerstag, den 19. Mai 2005: > > > >> IMHO debian-installer in unacceptable as it causes GPL violations. > >> Interlocking the debian-installer builds with the exact source > > ... > >> Any ideas? Comments? Solutions? > > > > Relax, there is no problem. (The same was as there is no problem with > > boot-floppies, beeing in Woody without the correct source. Nobody did > > care in the last 3 years). > > > > Regards, > > Eduard. > > -- > > In the beginning was the word, and the word was content-type: text/plain > > I do care. But I also have no evil intention and won't sue. > > I mainly care for the bloat for ia32-libs and similar > packages. Creating a 300MB ia32-OOo package and uploading that on each > change was/is insane enough to release amd64/ia64 without it. > > But I can't in good faith fight for doing it the debian-installer way > and build debs that will regulary be without source. It would be hard > to convince ftp-master to do the "wrong" thing after they already > decided to do the "right" thing anyway. > > That's why I'm looking for any idea to have binaries rebuild from debs > in debian without risking them being sourceless. Maybe a patch for the > DAK and an extra entry in the control file? Come on, spin your minds, > think of something. :) The above is a bit sparce on details of what exactly is the issue here. debian-installer builds use udeb's, and work is underway to not only keep those udeb's used last, but the udeb's for all d-i builds on the mirror network. If a udeb or deb is on the mirrors, the corresponding source is too, that's already ensured. So what is exactly the problem? Are you referring to libraries taken from regular .deb's, mangled and used in the initrd's? That's indeed a point, but not (much) different from the static linking issue we're already facing with any normal library in Debian -- there is a copy-on-compile, so the library that was staticly linked to, might move on and gain new source lines/drop them. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Miles Bader <[EMAIL PROTECTED]> writes: > astronut <[EMAIL PROTECTED]> writes: >> I agree. The type of user who is likely to be using the ifconfig >> command on a regular basis is the type of user who probably already >> has sbin in their path. (Power user, sysadmin's nonprivleged >> account, etc.). > > Yes. The great majority of users don't want to know about stuff > like ifconfig, and those that _do_ can either put /sbin in their > path themselves or just type the damn path when they run the > command. > > I've no clue why some people whine so much about this. It causes (at least) two types of trivial irritation: 1) on each new system I have to add sbin to my path, usually at the point where I'm involved in the already irritating exercise of debugging a network problem 2) when helping someone out, if you ask them to report what 'ifconfig' says then the answer is: -bash: ifconfig: command not found If there was a clear benefit to having ifconfig in sbin then these might be less annoying. But I've yet to hear of one. There is a small benefit to having a separate sbin at all, in that it takes a few things out of the namespace for tab completion. Personally I don't think that outweighs the inconvenience of people wrongly putting commands like ifconfig and (historically) traceroute in it. -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Inconsistent handling of sourceless packages in main
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > The above is a bit sparce on details of what exactly is the issue here. > debian-installer builds use udeb's, and work is underway to not only > keep those udeb's used last, but the udeb's for all d-i builds on the > mirror network. If a udeb or deb is on the mirrors, the corresponding > source is too, that's already ensured. How will you do that? Will that include the files copied from the build system into the D-I images? Can the same mechanism be used for ia32-libs and similar? > So what is exactly the problem? Are you referring to libraries taken > from regular .deb's, mangled and used in the initrd's? That's indeed a > point, but not (much) different from the static linking issue we're > already facing with any normal library in Debian -- there is a > copy-on-compile, so the library that was staticly linked to, might move > on and gain new source lines/drop them. The point is that anything using prebuild binaries to build debs can end up without source. I previously mentioned the D-I images, ia32-libs and kernel-images / modules. Now you added static libs to it. Kernel-source takes great care to preserve old sources in new uploads so they are fine, D-I just becomes sourcesless and ia32-libs has to carry all sources and debs it uses insite its tar.gz. If you are working on something to fix this for D-I then please share some details and hopefully this is general enough to be used for more than just D-I. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313369: RFH: mwavem -- Mwave/ACP modem support software
Package: wnpp Severity: normal I request assistance with maintaining the mwavem package. I own a ThinkPad 600 with an Mwave modem inside and I use this to test the mwavem packages that I prepare. However, I do not use the machine on a daily basis. If possible I would like help from someone who does use mwavem regularly. The package description is: The Mwave modem support software implements a Hayes-compatible V.90 modem in the 3780i Mwave/ACP DSP chip which is built in to several discontinued IBM ThinkPad laptop computers, including the ThinkPad 600, 600E and 770 models. . In addition to the programs included in this package, a driver is required for the Mwave device. Source code for the driver, built as a module called 'mwave.o' or 'mwave.ko', is included in the latest 2.4 and 2.6 Linux kernel sources. To build the module, set "ACP/Mwave Modem support" to "m" at kernel configuration time. This module must be loaded before the Mwavem modem support program can be started. . This package is in the non-free section of the archive because it contains program binaries for the 3780i chip that have been furnished by IBM without source code. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (800, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 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: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
On 13 Jun 2005 10:11:52 +0100, Richard Kettlewell <[EMAIL PROTECTED]> wrote: > Miles Bader <[EMAIL PROTECTED]> writes: > > astronut <[EMAIL PROTECTED]> writes: > > Yes. The great majority of users don't want to know about stuff > > like ifconfig, and those that _do_ can either put /sbin in their > > path themselves or just type the damn path when they run the > > command. > > > > I've no clue why some people whine so much about this. Probably because there's no solid reason against a symlink. > It causes (at least) two types of trivial irritation: > 1) on each new system I have to add sbin to my path, usually at the >point where I'm involved in the already irritating exercise of >debugging a network problem > 2) when helping someone out, if you ask them to report what >'ifconfig' says then the answer is: > -bash: ifconfig: command not found > > If there was a clear benefit to having ifconfig in sbin then these > might be less annoying. But I've yet to hear of one. I guess in situations where /sbin is available but /bin isn't (for whatever reason). > There is a small benefit to having a separate sbin at all, in that it > takes a few things out of the namespace for tab completion. On my system, if* matches only if as non-root user. I doubt namespace 'pollution' is an issue. > Personally I don't think that outweighs the inconvenience of people > wrongly putting commands like ifconfig and (historically) traceroute > in it. > > -- > http://www.greenend.org.uk/rjk/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
What IS OEM software and why do you care?
Get latest version, cds and download under $99 http://qkbl.wl0tzvw7bow3bfw.honeyedlyfm.com A woman without a man is like a fish without a bicycle. The past is but the past of a beginning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: co-maintainers sought
On Sun, 12 Jun 2005 15:01:37 +0200 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > - [RFA] bcm4400-source - module source for Broadcom's bcm4400 > > ethernet driver > > : http://packages.qa.debian.org/b/bcm4400-source.html > > What problems do you see with the in-kernel b44 driver that you still > need bcm4400? Unfortunately there are some Dells at work that I maintain that need bcm4400. They use some of the first bcm4400 chips I saw and will not work with the b44 driver. The b44 driver can see them and will claim it has them working with the assigned ip/netmask, etc. but they act dead. Ifconfig down, rmmod b44, modprobe bcm4400 and they work perfectly. Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On 2005-06-12, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > The best way to make multi floppy boot work would be to use initramfs > with a static C binary linked against klibc that does the prompting > and loading of the 2nd/3rd/... floppy. That way you can save as much > space as possible for kernel and modules (or similar with initrd for > 2.4.x). I don't know anything about klibc, but I would like to add that you don't necessarily need to link against any libc in order to prompt and load more as long as you only use kernel syscalls. One good example of this are the initrd's created by loop-aes's build-initrd.sh which only use syscalls to mount another partition; it then uses a trick to mount this second partition as /lib so you can have there a full glibc and any other libraries, binaries and/or modules. This gives you a nice 2KiB initrd. (Recent versions of build-initrd.sh link against dietlibc, but don't initialize it, the reason for this is to allow parameter passing to init, but it still delivers a nice small 2-3KiB initrd) -- Greetings from Oostende (BE) -*- Danny Cautaert (DaCa) Write me in Dutch, French or English * GnuPG preferred Meet me at LinuxTag * 22-25 June 2005 * Karlsruhe (DE) or at DebConf 5 * 10-17 July 2005 * Helsinki (FI) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Saturday 11 June 2005 08:34 am, David Weinehall wrote: > 2.6.25?! The current release pace for the 2.6-kernel is somewhere along > 2-3 months / kernel. The kernel version now is 2.6.11, but 2.6.12 is > out any day now, hopefully. Unless there are some radical changes, > there won't be more than 6-8 new kernels released 18 months from now. > So we're more looking at 2.6.20. Yes, and how overdue was Sarge? I think it's laughable to say what "will" happen. 2.6.25 may be a conservative estimate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: namespace conflict != package Conflict?
On 12-Jun-05, 02:27 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: > > You need to convince either git or GNU Interactive Tools > to change its name upstream then. Since git is the newcomer > and its name is already taken (by a GNU project no less!) > perhaps you could start there. The existence of the GNU Interactive Tools was noticed when Linus picked the name 'git'. The discussion then noted that this previous use of the name was more-or-less dead upstream, and not widely used. > >From my reading of your package description for cogito, > the name GIT (the version control system) doesn't seem to > mean anything in particular. So renaming it would not be a big loss. The upstream name isn't going to change. There are probably already more users of GIT-the-VCS than GIT-the-tools. So if you rename git for Debian, we are very likely going to to be incompatible. Just Conflict with the git package. The overlapping user base is likely to be nil. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Inconsistent handling of sourceless packages in main
On Mon, Jun 13, 2005 at 12:34:21PM +0200, Goswin von Brederlow wrote: > Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > > > The above is a bit sparce on details of what exactly is the issue here. > > debian-installer builds use udeb's, and work is underway to not only > > keep those udeb's used last, but the udeb's for all d-i builds on the > > mirror network. If a udeb or deb is on the mirrors, the corresponding > > source is too, that's already ensured. > > How will you do that? Will that include the files copied from the > build system into the D-I images? Can the same mechanism be used for > ia32-libs and similar? Nothing decided yet, thinking about the raw-installer upload hook to do something terribly d-i specific to keep all the needed udeb's for the installed d-i images around in some special 'fake' suite. > > So what is exactly the problem? Are you referring to libraries taken > > from regular .deb's, mangled and used in the initrd's? That's indeed a > > point, but not (much) different from the static linking issue we're > > already facing with any normal library in Debian -- there is a > > copy-on-compile, so the library that was staticly linked to, might move > > on and gain new source lines/drop them. > > The point is that anything using prebuild binaries to build debs can > end up without source. > > I previously mentioned the D-I images, ia32-libs and kernel-images / > modules. Now you added static libs to it. > > Kernel-source takes great care to preserve old sources in new uploads > so they are fine, D-I just becomes sourcesless and ia32-libs has to > carry all sources and debs it uses insite its tar.gz. > > If you are working on something to fix this for D-I then please share > some details and hopefully this is general enough to be used for more > than just D-I. Quite likely not. d-i can also really diverge from the archive, while for other stuff, this shouldn't happen, and also, a rebuild should always be harmless and not change functionality -- while a d-i rebuild with uptodate udeb's really *can* change functionality in a very significant way. All above mentioned cases are quite unique, in fact... --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: namespace conflict != package Conflict?
Steve Greenland <[EMAIL PROTECTED]> wrote: > On 12-Jun-05, 02:27 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: > > >From my reading of your package description for cogito, > > the name GIT (the version control system) doesn't seem to > > mean anything in particular. So renaming it would not be a big loss. > > The upstream name isn't going to change. There are probably already > more users of GIT-the-VCS than GIT-the-tools. So if you rename git for > Debian, we are very likely going to to be incompatible. > > Just Conflict with the git package. The overlapping user base is likely > to be nil. There is at least one user that wants both... I got a bug report about this before I made cogito.deb Conflict with git.deb. (Then of course I was told that that was the wrong approach, so I _removed_ cogito's /usr/bin/git and removed the Conflict with git.deb.) But I agree totally with you. I'd much rather conflict with GNU Interactive Tools and have git-the-vcs be compatible with non-debian universe. That seems like the lesser of two evils. But everyone else on debian-devel seems to want it the other way so I gave in for now. -- Sebastian Kuzminsky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: namespace conflict != package Conflict?
On Mon, Jun 13, 2005 at 09:46:27AM -0600, Sebastian Kuzminsky wrote: > Steve Greenland <[EMAIL PROTECTED]> wrote: > > On 12-Jun-05, 02:27 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: > > > >From my reading of your package description for cogito, > > > the name GIT (the version control system) doesn't seem to > > > mean anything in particular. So renaming it would not be a big loss. > > > > The upstream name isn't going to change. There are probably already > > more users of GIT-the-VCS than GIT-the-tools. So if you rename git for > > Debian, we are very likely going to to be incompatible. > > > > Just Conflict with the git package. The overlapping user base is likely > > to be nil. > > There is at least one user that wants both... I got a bug report about > this before I made cogito.deb Conflict with git.deb. (Then of course > I was told that that was the wrong approach, so I _removed_ cogito's > /usr/bin/git and removed the Conflict with git.deb.) > > But I agree totally with you. I'd much rather conflict with GNU > Interactive Tools and have git-the-vcs be compatible with non-debian > universe. That seems like the lesser of two evils. But everyone else > on debian-devel seems to want it the other way so I gave in for now. More importantly, the policy forbids it, as was already noted before in this very same thread. This thread is running in circles... I hope everything has been said by now so people can move on with the C++ transition and such :)? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Structured (XML-like) input/output for shell apps?
Hi, On Sat, Jun 11, 2005 at 07:40:10PM +0200, Olaf van der Spek wrote: > Many shell apps/scripts output data in tables, for example ls -l, ps > aux, top, netstat, etc. > At the moment, most of these apps use fixed-width columns with a > variable-width last-column. > This results in (unnecessary) truncation, for example: > Debian- 11918 0.0 0.1 4428 1464 ?Ss Jun05 0:00 > /usr/sbin/exim4 -bd -q30m > tcp 0 0 TC218-187-80-45.2:35589 bananensaft.inline.:www ESTABLISHEDproxy > 153239 > > Also, because the output isn't structured (in way easily readable by > machines), using the data in a script isn't (very) easy and is likely to > break due to strict dependency on the syntax. > > Are there already any plans to solve these issues? Yes. The commands you mention were designed for _human_ consumption. Do not use them in scripts without good reasons. There are a lot of commands to get well-formatted output without truncation. For example, ls has a "-n" option for exactly this reason; stat(1) can be used instead of "ls -l" to avoid clipping; ps has a _lot_ of formatting options itself and all the data can be found under /proc in an easily parseable format etc. You just have to select the right tool for the job (that also includes using more powerful scripting languages if the task is complicated). > I was thinking, using structured output (and maybe input) in an XML-like > way would solve these and allow neat post-processing. XML is just _terrible_ for human input/output. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, GOMBAS Gabor <[EMAIL PROTECTED]> wrote: > > Are there already any plans to solve these issues? > > Yes. The commands you mention were designed for _human_ consumption. Do > not use them in scripts without good reasons. There are a lot of The maintainer of netstat didn't want to change the layout (by default) because scripts might get broken. What's the solution here? > commands to get well-formatted output without truncation. For example, > ls has a "-n" option for exactly this reason; stat(1) can be used > instead of "ls -l" to avoid clipping; ps has a _lot_ of formatting > options itself and all the data can be found under /proc in an easily > parseable format etc. You just have to select the right tool for the job > (that also includes using more powerful scripting languages if the task > is complicated). > > I was thinking, using structured output (and maybe input) in an XML-like > > way would solve these and allow neat post-processing. > > XML is just _terrible_ for human input/output. It's not meant for human IO, it's meant for IO to the next chain. The final chain would then process it to normal text output.
Re: Structured (XML-like) input/output for shell apps?
* Gabor :: > Hi, > > On Sat, Jun 11, 2005 at 07:40:10PM +0200, Olaf van der Spek wrote: > > > Many shell apps/scripts output data in tables, for example ls > > -l, ps aux, top, netstat, etc. At the moment, most of these > > apps use fixed-width columns with a variable-width last-column. > > This results in (unnecessary) truncation, for example: Debian- > > 11918 0.0 0.1 4428 1464 ?Ss Jun05 0:00 > > /usr/sbin/exim4 -bd -q30m tcp 0 0 TC218-187-80-45.2:35589 > > bananensaft.inline.:www ESTABLISHEDproxy 153239 > > > > Also, because the output isn't structured (in way easily > > readable by machines), using the data in a script isn't (very) > > easy and is likely to break due to strict dependency on the > > syntax. > > > > Are there already any plans to solve these issues? > > Yes. The commands you mention were designed for _human_ > consumption. Do not use them in scripts without good reasons. > There are a lot of commands to get well-formatted output without > truncation. For example, ls has a "-n" option for exactly this > reason; stat(1) can be used instead of "ls -l" to avoid clipping; > ps has a _lot_ of formatting options itself and all the data can > be found under /proc in an easily parseable format etc. You just > have to select the right tool for the job (that also includes > using more powerful scripting languages if the task is > complicated). > > > I was thinking, using structured output (and maybe input) in an > > XML-like way would solve these and allow neat post-processing. > > XML is just _terrible_ for human input/output. What Olaf *really* seems to want is a resource like the new (vapor?) Monad shell from MS. Which can be a good thing, if done right, but is generally a waste of CPU and memory, if you ask me. As you said, there is not a lot of difference between ls *.ab | fields name, size | table in Monad and printf "%-50.50s %d\n", $_, -s $_ for <*.ab> in Perl. The domain is necessary anyway, ie, you have to know Monad to understand the first, you have to know perl to grok the second. * Olaf :: > > XML is just _terrible_ for human input/output. > > It's not meant for human IO, it's meant for IO to the next chain. > The final chain would then process it to normal text output. Even so; imagine a long (6 links) chain of things. Each of them would have to unserialize the input and serialize the output (XML no less! big overhead!), besides trying to know if its input is xml or not, if its output should be xml or not. In the Monad case, it *seems* that what is passed around are (DCOM?) objects, lowering the overhead a litlle bit, but there is a lot of overhead nonetheless. And it's still easier to use a tool (like Perl, Python or Ruby for instance) that can do the job you want (look my example above) IOW, I don't think Monad is such a hot idea. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313416: general: fail to print documents with 2 "pages per sheet"
Package: general Severity: normal when i try to print some pdfs, websites, docs and other stuff with 2 "pages per sheet" activated the printer does do its job; just stay "inactive". at http://localhost:631 in section "completed jobs" the status of those jobs appears "aborted". if i use 1 "pages per sheet" it works normally. i'm using: hp deskjet 690C c.u.p.s thank you. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312897: ITP: texlive -- The TeXlive system packaged for debian
On Monday 13 June 2005 09.41, frank wrote: [texlive vs. teTeX] > Let me add some comments from my point of view (Debian teTeX > maintainer). Sounds like packaging texlive and trying to get it really stable would be the thing to do, with the goal of phasing out teTeX for etch+1 Not becuase I don't value your work, Frank, but from what you said it sounds like texlive is a better maintained superset of teTeX - or are there reasons why somebody specifically would want to stick to teTeX (assuming a transition plan etc. etc. to solve "all" Debian/packaging specific issues.) greetings -- vbi [pity you couldn't make it on Saturday.] -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 pgpym8LkgyMAx.pgp Description: PGP signature
Re: kernel security bug #307900
Hi, On Friday 10 June 2005 04:02, Adam Majer wrote: > > > woody's kernels are vulnerable to CAN-2004-1235, a uselib() race > > condition. > > Will this be fixed for Woody? > > I thought the plan was to provide security support for Woody for > > another year? > AFAIK, there is no security support for Woody kernels for some time now. > Use kernel.org and compile your kernels for security sensitive machines. If this is true, this should be properly documented somewhere. regards, Holger pgpRtFFh6zwaN.pgp Description: PGP signature
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > What Olaf *really* seems to want is a resource like the new (vapor?) > Monad shell from MS. Which can be a good thing, if done right, but > is generally a waste of CPU and memory, if you ask me. As you said, > there is not a lot of difference between > > ls *.ab | fields name, size | table > > in Monad and > > printf "%-50.50s %d\n", $_, -s $_ for <*.ab> > > in Perl. The domain is necessary anyway, ie, you have to know Monad > to understand the first, you have to know perl to grok the second. Except that in Perl you have hard-coded the size of the name field and hard-coded sizes are almost never optimal (either too large or too small in most of the cases). > > > XML is just _terrible_ for human input/output. > > > > It's not meant for human IO, it's meant for IO to the next chain. > > The final chain would then process it to normal text output. > > Even so; imagine a long (6 links) chain of things. Each of them > would have to unserialize the input and serialize the output (XML no > less! big overhead!), besides trying to know if its input is xml or Note that I said structured (XML-like) IO. I didn't say XML. I'm sure an implementation without big overhead is possible. > not, if its output should be xml or not. In the Monad case, it > *seems* that what is passed around are (DCOM?) objects, lowering the > overhead a litlle bit, but there is a lot of overhead nonetheless. > And it's still easier to use a tool (like Perl, Python or Ruby for > instance) that can do the job you want (look my example above)
Re: And now for something completely different... etch!
I demand that Marco d'Itri may or may not have written... > On Jun 12, Frans Pop <[EMAIL PROTECTED]> wrote: >> I have a very nice Pentium I (my internet gateway) that has a broken >> CD-drive and no USB (and certainly wouldn't boot from USB even if it had) >> but that installs perfectly from floppy. > You said it: it's *broken*. > Expecting to support some old hardware is OK, expecting to support old and > broken hardware is not. In that case, replace the CD-ROM drive. ;-) >> There are also other platforms that only do floppy boots (older macs, >> probably m68k too). > Looks like they should use floppy + netboot then. An install on a Risc PC can be done without any removable installation media, although it's possible that the newer or less common Ethernet cards aren't supported. -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Oh my! Another kludge! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
I demand that Andreas Gredler may or may not have written... > On Thu, Jun 09, 2005 at 07:58:11PM -0400, Joey Hess wrote: [snip] >> Since d-i currently puts the initrd that reads the second floppy (or >> other USB media) on the boot floppy with the kernel, we either have to >> shoehorn that initrd, which is currently 644k, onto the same floppy, >> reducing its size by 414k somehow. > I have to take a look at the initrd. 414k sounds much to me :-( ISTM that a non-standard disk format (21 sectors per track and/or more tracks) would help - or would this just cause too many problems? [snip] -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Say NO to software patents Academy: A modern school where football is taught. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
In article <[EMAIL PROTECTED]> you wrote: > Probably because there's no solid reason against a symlink. Yes, and since ip puts one, too, I can do the same. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Structured (XML-like) input/output for shell apps?
* Olaf :: > On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> > wrote: > > printf "%-50.50s %d\n", $_, -s $_ for <*.ab> > > > > in Perl. The domain is necessary anyway, ie, you have to know > > Monad to understand the first, you have to know perl to grok the > > second. > > Except that in Perl you have hard-coded the size of the name field > and hard-coded sizes are almost never optimal (either too large or > too small in most of the cases). Not necessarily. Just as you have "tableout" as an external command (built-in or not) in Monad, you can have a Perl module to print things in a tabular manner, expanding the column sizes as needed (based on HTML::Format::Table or somesuch) > > > > > XML is just _terrible_ for human input/output. > > > > > > It's not meant for human IO, it's meant for IO to the next > > > chain. The final chain would then process it to normal text > > > output. > > > > Even so; imagine a long (6 links) chain of things. Each of them > > would have to unserialize the input and serialize the output > > (XML no less! big overhead!), besides trying to know if its > > input is xml or > > Note that I said structured (XML-like) IO. I didn't say XML. I'm > sure an implementation without big overhead is possible. Yes, and I withdraw :-) what I said about XML. But *any* serialization / deserialization necessary for this scheme to work would add (unnecessary) overhead. This and the fact that you would create incompatibilities with other Unices ... Those are indications that this won't be done. Obviously, some Monad clone can be done with its entire toolchain (monad-ls, monad-tableout) ... -- HTH, Massa
wiki.debian.net brokenness?
Hi, I've discovered that I can no longer log into wiki.debian.net. When visiting pages, it informs me that I'm AnonymousUser; when I try to edit a page, it tells me that the web page doesn't not allow anonymous editing. However, it doesn't provide a link to log in (or maybe I'm just missing the link?). This makes it rather difficult to actually update wikis. While on the topic, the wiki's revision comparison behavior is rather suboptimal; I can't arbitrarily diff between edits/commits (which means when people can do several large edits, it's hard to tell if information might've gotten lost). Had I know about this earlier, I wouldn't have used the debian.net wiki for KernelFirmwareLicensing. I emailed [EMAIL PROTECTED] a few weeks ago about helping w/ the wiki, and possibly upgrading to one that supports such functionalty, but I have not yet received a response. So is it time for me to just move the page to a wiki that I host, and tell people to use that, or are the wiki.debian.net folks awake? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Sun, 12 Jun 2005 21:05:56 +0100, Scott James Remnant wrote: [...] > > * The "Debian Diff" may be replaced by the "Debian Tar": > Instead of placing your changes and Debian directory as a patch against > the upstream tarball in a diff.gz, you may instead ship the Debian > directory as a debian.tar.gz. This is unpacked into the debian > sub-directory of the source. > This is beautiful. I can't count the number of times I've looked at a random package that has multiple fixes and enhancement all in the diff.gz, with no way of knowing what bugs in the BTS they fix, which hunks are are logically separate, etc. Even worse are the packages which include broken out patches in the debian directory which are out of date or incomplete, and no longer match what's in the diff.gz. It's analogous to programs which have no documentation, incomplete documentation, or worse yet, completely incorrect documentation. I'm sure people will still find ways to make other DDs lives difficult in this manner (everything being in one big patch, including fixes in the orig tarball, or something equally as stupid), but this seems like this will go a long way to encourages people to separate out upstream enhancement/fixes. As an added bonus, this is how I typically do development (which is similar to how HCT does stuff under the hood, from what I've seen), so that debian-directory-specific baz/git/$RCS branch will now map directly to a tarball, and individual patches in debian/patches will map to their respective branches. /me wipes a tear of joy from his eye -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312897: ITP: texlive -- The TeXlive system packaged for debian
Adrian von Bidder <[EMAIL PROTECTED]> wrote: > On Monday 13 June 2005 09.41, frank wrote: > [texlive vs. teTeX] >> Let me add some comments from my point of view (Debian teTeX >> maintainer). > > Sounds like packaging texlive and trying to get it really stable would be > the thing to do, with the goal of phasing out teTeX for etch+1 > > Not becuase I don't value your work, Frank, but from what you said it sounds > like texlive is a better maintained superset of teTeX - or are there > reasons why somebody specifically would want to stick to teTeX (assuming a > transition plan etc. etc. to solve "all" Debian/packaging specific issues.) TeX-Live exists for a couple of years now, and while it might gain some teTeX users, teTeX upstream is by no means dead. So for these users, there must be a reason to use teTeX. I don't know these reasons; but one might be that with teTeX you get a TeX system that contains all the essential stuff without much bloat. You can have the same with tex-live, by selecting and deselecting the appropriate sub-packages (binary packages when provided by Debian). But personally I find it easier to start with teTeX's choices and add some specific packages from CTAN if I really need them. I also wouldn't say that tex-live is better maintained. It's just the style that differs: A team effort with a yearly release schedule for tex-live, the work of one very experienced TeX guru for teTeX (who bases his decisions more on the development of TeX tools and programs than on the release schedule of Debian, that's why I made that remark about "releasing when he thinks it is time"). By the way, Thomas Esser and the tex-live team work closely together, and for sure he has quite some influence on them; but as long as he does not stop teTeX, I see no reason for us to stop it. One other thing is that texlive's focus is on personal computers - Windows, Mac, and i386-Linux, while teTeX is a distribution for UNIX-like operating systems. I'm not an architecture expert, but I can imagine that there might be issues in the sources that can be solved in a satisfying way _either_ for i386-Linux, Mac, and Windows, _or_ for GNU/Linux, GNU/Hurd, Whatever/Unixoid (all on a variety of different architectures). In this case we might be glad to have teTeX packages for all (released and however-they-are-called) architectures, not just texlive for a small subset, or alternatively a hell of patches. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > Not necessarily. Just as you have "tableout" as an external command > (built-in or not) in Monad, you can have a Perl module to print > things in a tabular manner, expanding the column sizes as needed > (based on HTML::Format::Table or somesuch) But I doubt that'd be as simple as things are now. > Yes, and I withdraw :-) what I said about XML. But *any* > serialization / deserialization necessary for this scheme to work > would add (unnecessary) overhead. This and the fact that you would > create incompatibilities with other Unices ... Those are indications > that this won't be done. What kind of incompatibilities? > Obviously, some Monad clone can be done with its entire toolchain > (monad-ls, monad-tableout) ... Why not ls --monad?
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > Yes, and I withdraw :-) what I said about XML. But *any* > serialization / deserialization necessary for this scheme to work > would add (unnecessary) overhead. This and the fact that you would Well, if you can do it with Perl without overhead, you can of course also do it without Perl without overhead. In that case the 'structured' support would be included in the utility itself.
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 09:25:22AM +1000, Matthew Palmer wrote: > On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña > wrote: > > to find their own (sometimes flawed) solution to a very common problem. > > Years using Linux: 10. > > Times I've absolutely needed an X-less boot when an XDM was installed: 0. > > How common was that problem you were trying to solve, again? Years using linux: 11 (argh, or 12, i cannot even remember) Times I needed the above discussed feature: several. That common is common enough? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Problem? I haven't got a problem. I've got fucking problems. Plural. --Ted the Bellhop (Four Rooms) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: reassign
Processing commands for [EMAIL PROTECTED]: > reassign 313416 cupsys Bug#313416: general: fail to print documents with 2 "pages per sheet" Bug reassigned from package `general' to `cupsys'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Structured (XML-like) input/output for shell apps?
* Olaf :: > On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> > wrote: > > Yes, and I withdraw :-) what I said about XML. But *any* > > serialization / deserialization necessary for this scheme to > > work would add (unnecessary) overhead. This and the fact that > > you would > > Well, if you can do it with Perl without overhead, you can of > course also do it without Perl without overhead. In that case the > 'structured' support would be included Not exactly. Don't get me wrong, object component technology is a great thing, standing just next to sliced bread in the list of great things, but (just like sliced bread) it does not cure cancer. When I do my example inside of Perl, I am supposing whatever objects or handles the Perl interpreter has stay inside the interpreter's process; when you do a pipe like monad-ls *.ab | monad-fields name, size | monad-tableout you are implying the existence of 3 processes, two of them making serialization of their (internal) objects for output, two or them making de-serialization of their inputs to (internal) objects, all of them analyzing (or receiving a hint from the shell, that had to analyze for them all) to see if their input came from an object pipe and if their output goes to an object pipe. At least two of those process have to read all of their input to memory before spitting any output (ls -- because it sorts the filenames -- and tableout -- because it dimensions the columns beautifully). This is a *lot* of overhead -- normal overhead, contention overhead (ls blocks the other two processes until it starts spitting its output), and synch overhead (any object read in the input must be perfectly synchronized to be a valid IPC object), and it's a lot of overhead independently of the IPC mechanism utilized. In the case of my Perl example, verbosely made to use a hypotetical text::table: use Text::Table; $t=new Text::Table; $t->addline($_, -s $_) for <*.ab>; print $t->as_text You still have some contention inherent to the operation you want to convey (sorting *.ab, determining optimal column width), but none of the (really expensive) freeze-serialize/deserialize-thaw cycles the monad version has, nor the (expensive, complex, and even with security implications(*)) input-format, input-synch, etc issues. (*) security implications because when you make a pipe component like monad-fields that can receive an arbitrary object as its input, you have to have in mind that said object can have security bugs in its methods, either on purpose or not. Imagine a malicious-ls that spits objects whose "get-name" method (property getter) copies the .ssh directory of the current user to another, publically-readable locale. This can be installed in someplace in the net and you can convince people that your ls is better and 0wn the poor bastards... This *will* certainly happen in an environment like this because, well, there will be a point in time where it will be too much trouble to check all those distributed objects... Not unlike a lot of websites install spyware via ActiveX in the poor IE-using folk. -- HTH, Massa
Re: Structured (XML-like) input/output for shell apps?
> On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> > wrote: > > Not necessarily. Just as you have "tableout" as an external > > command (built-in or not) in Monad, you can have a Perl module > > to print things in a tabular manner, expanding the column sizes > > as needed (based on HTML::Format::Table or somesuch) > > But I doubt that'd be as simple as things are now. > As I said in my other answer, things will *never* be simpler as they are right now. Any other stuff will tend to complicate instead of simplify things. > > Yes, and I withdraw :-) what I said about XML. But *any* > > serialization / deserialization necessary for this scheme to > > work would add (unnecessary) overhead. This and the fact that > > you would create incompatibilities with other Unices ... Those > > are indications that this won't be done. > > What kind of incompatibilities? > There are a lot of scripts today in production use that use the output of ls, ps, in a text-way. If you want to put another command, or another switch to "ls", ok, but the fact that you *can* do it does not mean that you *should* do it. (see below) > > Obviously, some Monad clone can be done with its entire > > toolchain (monad-ls, monad-tableout) ... > > Why not ls --monad? If you want to fork and maintain forever util-linux, I have nothing to say about that. But I *will* leave you (I'm going home from work now) with Occam's razor: Entia non sunt multiplicanda praeter necessitem. (Things shouldn't be multiplied without necessity) IOW: if it's not broken, don't fix it. -- HTH, Massa
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > > Well, if you can do it with Perl without overhead, you can of > > course also do it without Perl without overhead. In that case the > > 'structured' support would be included > > Not exactly. Don't get me wrong, object component technology is a > great thing, standing just next to sliced bread in the list of great > things, but (just like sliced bread) it does not cure cancer. > > When I do my example inside of Perl, I am supposing whatever objects > or handles the Perl interpreter has stay inside the interpreter's > process; when you do a pipe like > > monad-ls *.ab | monad-fields name, size | monad-tableout If you do a pipe like that. But the functionality you showed in Perl could also be done completely inside ls itself.
Re: Structured (XML-like) input/output for shell apps?
On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > There are a lot of scripts today in production use that use the > output of ls, ps, in a text-way. If you want to put another command, > or another switch to "ls", ok, but the fact that you *can* do it > does not mean that you *should* do it. (see below) Didn't you say (or someone else) say the output of these commands was (only) for human consumption? > > > Obviously, some Monad clone can be done with its entire > > > toolchain (monad-ls, monad-tableout) ... > > > > Why not ls --monad? > > If you want to fork and maintain forever util-linux, I have nothing > to say about that. Why fork and not just change the 'real' util-linux? ;-> > But I *will* leave you (I'm going home from work now) with Occam's > razor: > > Entia non sunt multiplicanda praeter necessitem. > > (Things shouldn't be multiplied without necessity) > IOW: if it's not broken, don't fix it. If only it wasn't broken. Netstat for example suffers from truncation.
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 01:18:39PM +0200, Josselin Mouette wrote: > > How would these runlevels be "wasted"? We're only talking about the > default configuration, not about something a system administrator > couldn't change. Exactly my point, what impedes an admin to set some defaults wether the system comes as it comes now or with some predefined options and settings? -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 This is ridiculous. It's crazy. I feel like I'm babysitting, except I'm not getting paid. --Stef (The Goonies) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.net brokenness?
Andres Salomon <[EMAIL PROTECTED]> writes: > I've discovered that I can no longer log into wiki.debian.net. When > visiting pages, it informs me that I'm AnonymousUser; when I try to edit a > page, it tells me that the web page doesn't not allow anonymous editing. > However, it doesn't provide a link to log in (or maybe I'm just missing > the link?). This makes it rather difficult to actually update wikis. AFAICT, you just need to follow the link labeled AnonymousUser and enter some other username... -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
On Fri, Jun 10, 2005 at 01:24:43PM +0200, Marco d'Itri wrote: > And anyway ifconfig is deprecated, everybody should always use iproute > which *is* in /bin. Why is so? J PS: You keep on impressing me how gratiously you use the language: "Linux kernel 2.4 is obsolete" "ifconfig is deprecated" Please, stop spreading *your* FUD. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Personal note: When I was little my mother told me not to stare into the sun, so when I was six I did. --Maximillian Cohen (Pi) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote: > Hello. > > - - Early start of X, while some other stuff is still loading on the bg. - get rid of hotplug in its actual incarnation. Is hell of slow and painful. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Coffee and cigarettes. That's like the breakfast of champions. --Bob (Blue in the Face) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
On Sun, 2005-06-12 at 16:25 -0700, Erik Steffl wrote: >why is there a link to logs in /etc? > >/etc/postgresql/7.4/main/log is a link to > /var/log/postgresql/postgresql-7.4-main.log > >/etc is supposed to be for configuration files that are static, the > link to log violates both (yes, it's only a link so it doesn't change > but points to a file that changes and is definetely not a configuration > file). > >is this a bug? Or is this somehow valid? Policy says that conffiles should be in /etc, or, if that is not feasible, that there should be a link to /etc. (Policy 10.7.2) Policy also states that packages must conform to the FHS. The FHS states that site-specific configuration files should be in /etc and that binaries should not be. It also says that log files should usually be under /var/log. It is not stated that other types of file must not be put in /etc, still less that there should be no links to such files. By analogy with 10.7.2, it seems reasonable to allow a link if it is not feasible to do without it. >btw I am not sure which package is this part of, can't find it using > dpkg -S, not even when I dpkg -L all postgresql packages I have > installed (I guess it was created by postinst sript or something like that). The name indicates that it is created by postgresql-common (/usr/bin/pg_createcluster) in relation to a database whose server is postgresql-7.4 -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA Do you want to know God? http://www.lfix.co.uk/knowing_god.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
On Mon, 13 Jun 2005, Oliver Elphick wrote: > On Sun, 2005-06-12 at 16:25 -0700, Erik Steffl wrote: > >why is there a link to logs in /etc? > > > >/etc/postgresql/7.4/main/log is a link to > > /var/log/postgresql/postgresql-7.4-main.log > > > >/etc is supposed to be for configuration files that are static, the > > link to log violates both (yes, it's only a link so it doesn't change > > but points to a file that changes and is definetely not a configuration > > file). > > > >is this a bug? Or is this somehow valid? > > Policy says that conffiles should be in /etc, or, if that is not > feasible, that there should be a link to /etc. (Policy 10.7.2) Configuration files, not conffiles, should be in /etc. And, it's a link *in* /etc, *to* the file located elsewhere. > It is not stated that other types of file must not be put in /etc, still > less that there should be no links to such files. By analogy with > 10.7.2, it seems reasonable to allow a link if it is not feasible to do > without it. That's a stupid argument. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
On 6/13/05, Adam Heath <[EMAIL PROTECTED]> wrote: > That's a stupid argument. It's not that stupid. If other files shouldn't be there, the specs should explicitly state that.
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
On Mon, 13 Jun 2005, Olaf van der Spek wrote: > On 6/13/05, Adam Heath <[EMAIL PROTECTED]> wrote: > > That's a stupid argument. > > It's not that stupid. But it is. > If other files shouldn't be there, the specs should explicitly state that. Use just a *little* bit of common sense. Oh, wait, common sense doesn't exist in Debian. Ok, I guess this means it's open season to do whateverthefuckyouwantandignoreallstandardswhenmakingpackages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
ma, 2005-06-13 kello 23:56 +0200, Olaf van der Spek kirjoitti: > On 6/13/05, Adam Heath <[EMAIL PROTECTED]> wrote: > > That's a stupid argument. > > It's not that stupid. > If other files shouldn't be there, the specs should explicitly state that. The Debian Policy does not, and cannot, have a rule for every case where some judgement is to be applied while making Debian packages. Such a document would be much too big and complicated to be useful. Therefore, we rely on package maintainers applying common sense to keep things working, sensible, and tidy. That said, the Debian Policy document does mandage use of the Filesystem Hierarchy Standard (FHS), which in turn describes /etc like this: "/etc contains configuration files and directories that are specific to the current system". This cannot reasonably be interpreted to mean anything than "configuration stuff only". When I say reasonably, I mean that a sharp lawer-like mind might interpret it in whatever way they wish, on a larch, but that is not useful for building an operating system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Jesus Climent writes: > Exactly my point, what impedes an admin to set some defaults wether the > system comes as it comes now or with some predefined options and > settings? Nothing, except for the fact that most "admins" haven't the foggiest idea how to do that. Thus the suggestion that the default runlevels be what most people expect them to be. And it _does_ come with "predefined options and settings": ones unique to Debian. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312897: ITP: texlive -- The TeXlive system packaged for debian
On Mon, Jun 13, 2005 at 09:41:47AM +0200, frank wrote: > > If we had texlive in Debian, there wouldn't be such pressure. teTeX > would be updated to the current version shortly after a release, and > then would stick to that upstream version no matter what happened until > the next release. And the buildds and package maintainers would be happy. Not too sure about that. It seems likely that teTeX and TeX-live packages will have to conflict with each others. This mean that in order to build a Debian package, you might need to remove you TeX installation and install another one. This is likely to be painful. OTOH, TeX having a very high level of internal compatibility, it might be possible to mix and match, but that might require to split teTeX debian packages in smaller chunk. So does the plan handle that ? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 CDs and DVDs released
On Tue, Jun 14, 2005 at 12:33:42AM +0200, Santiago Garcia Mantinan wrote: > > As AMD64 is unofficial, the URL for downloading the images is slightly > different to that used for the officially-released sarge > architectures: How exactly AMD64 is unofficial (apart for the use of uppercase) ? Did not the security team and the SRM just agreed to support it ? Is it not sufficient for the official label ? Puzzled, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 CDs and DVDs released
On Tue, 14 Jun 2005, Santiago Garcia Mantinan wrote: > Hi! > > A little later than the rest of the architectures, we are now ready to > announce the availability of CDs (businesscard, netinst and full) and > DVDs for AMD64. > > As AMD64 is unofficial, the URL for downloading the images is slightly > different to that used for the officially-released sarge > architectures: > > http://cdimage.debian.org/cdimage/unofficial/sarge-amd64/ > > These CDs and DVDs have been built by the same team that built the > official sarge CDs and DVDs, using the same software. They are > therefore available in the same formats as for the official > architectures (jigdo, isos, torrents) and should also have the same > quality and bugs. > > The vast majority of binary packages in the AMD64 release were built > from exactly the same sources as the packages for the other > architectures. There were a small number of exceptions, however. To > make life easier for distributors of AMD64 discs, the extra sources > needed for those packages have been added to the last binary disc in > each AMD64 set (i.e. CD#13 and DVD#2). Source requirements can > therefore be met easily for AMD64. I've updated the bittorrent tracker with the new torrents. We now just need seeders. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 CDs and DVDs released
Bill Allombert wrote: >On Tue, Jun 14, 2005 at 12:33:42AM +0200, Santiago Garcia Mantinan wrote: >> >> As AMD64 is unofficial, the URL for downloading the images is slightly >> different to that used for the officially-released sarge >> architectures: > >How exactly AMD64 is unofficial (apart for the use of uppercase) ? >Did not the security team and the SRM just agreed to support it ? >Is it not sufficient for the official label ? Security.d.o may have been promised, but sarge/amd64 will not be hosted within the official archive - Debian did not release amd64 with sarge. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AMD64 CDs and DVDs released
On Tue, Jun 14, 2005 at 01:10:47AM +0100, Steve McIntyre wrote: > > Security.d.o may have been promised, but sarge/amd64 will not be > hosted within the official archive - Debian did not release amd64 with > sarge. > Good work, Steve. Just building the DVD's now, having downloaded the jigdo files :) Someone at work was telling me how impressed he was, having moved to Sarge on his dual Opteron over the weekend - now I can give him the media so that he can install it for everyone else :) As ever, your CD/DVD provision rocks :) Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
In article <[EMAIL PROTECTED]> you wrote: > That said, the Debian Policy document does mandage use of the Filesystem > Hierarchy Standard (FHS), which in turn describes /etc like this: "/etc > contains configuration files and directories that are specific to the > current system". This cannot reasonably be interpreted to mean anything > than "configuration stuff only". When I say reasonably, I mean that a > sharp lawer-like mind might interpret it in whatever way they wish, on a > larch, but that is not useful for building an operating system. Not that I like it, but a link in etc to the log direcoty is as good as a config gile containing "logdir=". Only that the former is easier to use. And since debian does place a lot of (alternative) links in etc it is a well accepted config method. However I am not sure if it is used that way in the package. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
On Tue, Jun 14, 2005 at 02:55:09AM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > That said, the Debian Policy document does mandage use of the Filesystem > > Hierarchy Standard (FHS), which in turn describes /etc like this: "/etc > > contains configuration files and directories that are specific to the > > current system". This cannot reasonably be interpreted to mean anything > > than "configuration stuff only". When I say reasonably, I mean that a > > sharp lawer-like mind might interpret it in whatever way they wish, on a > > larch, but that is not useful for building an operating system. > Not that I like it, but a link in etc to the log direcoty is as good as a > config gile containing "logdir=". Only that the former is easier to use. And > since debian does place a lot of (alternative) links in etc it is a well > accepted config method. However I am not sure if it is used that way in the > package. That also means the program is looking for its logfiles under /etc by default, which FHS-compliant software is not supposed to do. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
Oliver Elphick wrote: On Sun, 2005-06-12 at 16:25 -0700, Erik Steffl wrote: why is there a link to logs in /etc? /etc/postgresql/7.4/main/log is a link to /var/log/postgresql/postgresql-7.4-main.log /etc is supposed to be for configuration files that are static, the link to log violates both (yes, it's only a link so it doesn't change but points to a file that changes and is definetely not a configuration file). is this a bug? Or is this somehow valid? Policy says that conffiles should be in /etc, or, if that is not feasible, that there should be a link to /etc. (Policy 10.7.2) Policy also states that packages must conform to the FHS. The FHS states that site-specific configuration files should be in /etc and that binaries should not be. It also says that log files should usually be under /var/log. It is not stated that other types of file must not be put in /etc, still less that there should be no links to such files. By analogy with 10.7.2, it seems reasonable to allow a link if it is not feasible to do without it. isn't the reasonable interpretation of FHS that only what is supposed to be in a particular directory is supposed to be there, i.e. that ONL:Y static config files should be in /etc tree? Reading FHS it seems the only reasonable interpretation, otherwise one could claim to be FHS compliant while having junk file all over the place. I mean regardless of details of interpretation - is there any rationale for link to log to be in /etc? If there's none it simply shouldn't be there, IMO (otherwise you guys (I'm not a dd) are creating a mess of a system with unneccessary illogical links/files all over the place). btw I am not sure which package is this part of, can't find it using dpkg -S, not even when I dpkg -L all postgresql packages I have installed (I guess it was created by postinst sript or something like that). The name indicates that it is created by postgresql-common (/usr/bin/pg_createcluster) in relation to a database whose server is postgresql-7.4 it's a bit off topic but could you please explain how does the name /etc/postgresql/7.4/main/log indicate it was created by postgresql-common (as opposed to any other postgrsql-* packages, e.g. postgresql-7.4 seems like a good candidate as well)? What does /usr/bin/pg_createcluster have to do with anything? OK, so I looked at it and the script actually creates that link (/etc/postgresql/7.4/main/log), seems pretty evil. Any ideas why would anybody do it? erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313505: ITP: gekkoware -- web content management system with expansion in mind
Package: wnpp Severity: wishlist Owner: David Moreno Garza <[EMAIL PROTECTED]> * Package name: gekkoware Version : 0.4.1.8 Upstream Author : José Carlos Nieto Jarquín <[EMAIL PROTECTED]> * URL : http://gekkoware.sourceforge.net/ * License : GPL Description : web content management system with expansion in mind Web content management system written in PHP and MySQL. It has a vast variety of useful characteristics to develop everything from small websites to big communities in a small period of time. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Re: And now for something completely different... etch!
On Tuesday 14 June 2005 02:32, Darren Salt <[EMAIL PROTECTED]> wrote: > ISTM that a non-standard disk format (21 sectors per track and/or more > tracks) would help - or would this just cause too many problems? AFAIK it's not possible for the BIOS to boot from a 21 sector track. I have heard of people formatting track 0 as 18 sectors and giving it the code needed to switch to 21 sector mode for the other tracks. It's an ugly hack and difficult to produce. For floppy disks to be widely usable we want them to be writable on random machines. In the past I've used Windows, DOS, and OS/2 machines to write Linux disks. A disk with different numbers of sectors on different tracks would probably only be writable on Linux. 21 sector track disks can be written on DOS and used to be writable on Windows (not sure how they work with NT). Having an initial disk in 18 sector mode that then loads from 21 sector disks might be viable. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ongoing Firefox (and Thunderbird) Trademark problems
Hi, Now that sarge has been released it's time to revisit this problem. Most of the problems revolve around this document: http://www.mozilla.org/foundation/trademarks/policy.html From my reading of this, I'm not permitted to do such necessary things such as security patches, and retain the name Firefox. This has been brought up with Gervase Markham (who seems to be the Mozilla point of contact on these issues) before on debian-legal: http://lists.debian.org/debian-legal/2005/01/msg6.html http://lists.debian.org/debian-legal/2005/01/msg00023.html http://lists.debian.org/debian-legal/2005/01/msg00503.html Now, the Mozilla Foundation is willing to give us permission to use the marks, but only to Debian specifically. To me, this feels like a violation (at least in spirit) of DFSG #8. It's now nearly six months since the debian-legal threads, sarge is out the door, so it's time to do something about this. As I see it, we have the following options: 1. Completely ignore their Trademark Policy document and let MoFo come to us if they're not happy with our use of the marks. 2. Rename Firefox and strip all trademarks out. 3. Accept MoFo's offer of Debian-specific trademark usage. 4. Try to negotiate some other arrangement with MoFo. I don't believe we can really do #1 in good conscience. I don't believe #3 is acceptable under the DFSG. It's been 6 months with no real progress towards a resolution that I can see, so #4 seems to be stalled, but again I invite Gervase to restart discussions. That lives #2 as an unappealing solution, but perhaps the only way to go. So for hopefully the last time I'd like to get people's opinion on this before I take any action. Am I being too pedantic? I'd also love to hear how Ubuntu is handling this (not to fan the flames, just to get a different perspective). -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: And now for something completely different... etch!
[Darren Salt] > ISTM that a non-standard disk format (21 sectors per track and/or > more tracks) would help - or would this just cause too many problems? I think it's safe to assume anyone can boot and read a 1600 kB floppy. 1743 kB is common but possibly problematic. signature.asc Description: Digital signature
