7.5.1 Overwriting files in other packages
Is this always true? 7.5.1 Overwriting files in other packages Firstly, as mentioned before, it is usually an error for a package to contain files which are on the system in another package, though currently the --force-overwrite flag is enabled by default, downgrading the error to a warning,
[policy] orig.tar.gz unpacking to surprisingly named subdir! (Re: orig.tar.gz)
[ObCrossposts: We should decide what list to discuss this on.] Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes: Henrique On Sat, 09 Dec 2000, Hamish Moffatt wrote: On Fri, Dec 08, 2000 at 11:33:05PM -0200, Henrique M Holschuh wrote: Should I be filling a wishlist bug against lintian, or is it ok (although not optimal) to have .orig.tar.gz files unpacking at foo-1.2.3 instead of foo-1.2.3.orig ? The tools give warnings, but it really doesn't matter. Quite a lot Henrique I didn't receive warnings from any tools (otherwise it wouldn't have taken Henrique months for me to notice the problem). IMO they should be fatal errors, not warnings. of my packages have .orig.tar.gz which unpack into directories with no version number at all, and sometimes even a different name. eg geda-gschem unpacks just as 'gschem/'. Henrique I thought that would be the case (many .origs not unpacking to Henrique foo-1.2.3.orig). This is very bad. What if I have (and I do have something like...) The toplevel dir for all packages built from the killer-app source: srcdir/PKG/woody/main/killer-app The debian/* stuff out of my personal CVS repository: .../killer-app/debian.killer-app The source checked out of upstream CVS: .../killer-app/killer-app The symlink I use during development builds: .../killer-app/killer-app/debian - ../debian.killer-app ... and then when I do a release, it creates the orig.tar.gz etc. without using the version number for some reason... somebody else has a similar setup, tracking upstream CVS and my debian.killer-app/ stuff... and they run an `apt-get source killer-app' there to get my latest release's debian/* stuff to vendor track me. It might blow away yet-to-be-submitted patches they have in the code by untarring to killer-app. The version number is important inside .orig.tar.gz for this reason!! -- mailto: Karl M. Hegbloom [EMAIL PROTECTED] http://people.debian.org/~karlheg/
Categorization, relating email threads, ditch tasksel and extend capt? (Re: cleaning up our task packages)
Dirk == Dirk Eddelbuettel [EMAIL PROTECTED] writes: Dirk Interesting timimg :) I've noticed it too. I just got back on list, had ideas, and after reading farther, found other threads about similar topics. Neat. It's good to be back on debian-devel... that's iff I can keep up with the traffic. Dirk I finally got a go-ahead from the previous task-science maintainer to adopt Dirk his package, which I found muddled (and buggy where it intersected with some Dirk of my packages). I posted a suggestion for a new one to d-devel last night, Dirk and so far only heard break it up further into task-numerical-analyis and Dirk task-data-analysis. kmh-subtopic key=email user agents threading relating threads /grin reason=clever use of XML Noted... Uh, how can we combine two threads like this logically somehow? Can the various email user agents deal with it in some way? (they should) Can our web interface deal with it? Who marks them as combine or related? How can that data be propagated to everyone on this list? Control mails in the channel or out of band? ... then our user agent software picks that up and edits headers in personal archive so threads are displayed as related? What would be good interface? How can we make it so that it's easier to build a thread summary, without needing to spend an extra two hours at it? (Think DWN, Kernel Cousin reports, or pulling together threads into a summary and using that to build up an RFC document, etc. etc...) /kmh-subtopic kmh-subtopic key=configurable limits on CC's The mailing list software ought to let us configure (per list with a global fallback) whether we want our name stripped from the To and CC headers of email remailed by the listserv. This way, replies don't include you in the CC for lists you are a subscriber to. /kmh-subtopic kmh-subtopic key=listserv pulls out and routes subtopics What if tags like that got the listserv to route subtopic segments to the right people's suggestion box? /kmh-subtopic Dirk I'm of a divided opinion. I think Joey is right in limiting Dirk tasksel at its [...] Hmmm. Similar ideas occured to me. We're on the similar wavelength today. `capt' ought to support this also... it's analagous to the interpreter vs compiler thing... one does it at runtime, the other at compile time. Here's what I mean by that. `capt' can use information from the apt-cache to build the data structures it needs for selective display. It can do that dynamicly, at runtime, and the selective display can be switched to any of several modes. Filters, sorts, etc. `tasksel' though, must be a smaller program so it will fit on a boot floppy, boot CD, bootp/tftp, or netfetch setup where media size, ram size, or bandwidth issues are prevalent. It can be data driven though, by a file that is essentially a compilation of the relevant data parsed from an apt cache matching the Packages for that release du jour. You'd run a tool that creates its data file. Here we have a consistency issue - that tasksel data must match the actual Packages, etc. (This is disjoint from the consistency issue with kernel version and modules.) That data file, since it must be generated anyway under this scheme, could even be binary, designed to be mmapped in by tasksel. Byte sex would not matter, since for each arch, there would need to be a different set of installer boot images anyway. -- mailto: Karl M. Hegbloom [EMAIL PROTECTED] http://people.debian.org/~karlheg/
Compressed HTML, Apache MultiViews for /doc/, new doc-base option ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 X-Archive-Search-Keywords: apache doc-base compress gzip multiviews doc-base apache boa dhttpd dhelp dwww policy I've been hard at work on a new-fangled packaging setup for the XEmacs-21.2-Beta, and have created a `doc-html' package for it, using `texi2html'. I would really like to compress all of those HTML files, as well as the rest of the HTML in /usr/doc, just to save space. It can make a huge difference on a small laptop, freeing precious hard disk space for several CVS checkouts, for instance. I've learned that with Apache, you can set the MultiViews option, and it will serve the document.html.gz when the document.html is not found. I notice that by default, our Apache does not have the MultiViews option enabled in /doc/. I think that it should. Presumably, the other HTTP daemons can be modified to behave in a similar fashion, if they don't already deal with this. I'm less concerned about whether the data is uncompressed prior to service or sent with an application/x-gzip content-encoding than I am with that it will find document.html.gz when document.html is requested but doesn't exist anymore. (Of course, if it sends gzip encoded data, it needs to report that to the browser...) We should *not* have to stream-edit outgoing HTML to fix up the links inside it. It would be nice to make it so that if a browser cannot accept gzip encoded content, the document is uncompressed prior to service, and if it does, it's sent compressed. Johnie? Does Apache deal with that? I would like `doc-base' to be modified[1] so that, at local option, all HTML documentation gets compressed after installation. I have written some preliminary code to handle that. I would like folks who understand `dpkg' well to look it over and see if it's correctly implemented, and if so, we can roll it into `doc-base' somehow. Please don't try this on a production system, etc. etc... and RTFS before you run it. I've not looked at it in 5 or 6 months. I think it used to work... Mainly, I want folks to look at it and see if they like the idea. Should I pursue this? Would yous like that? http://bittersweet.inetarena.com/cgi-bin/viewcvs.cgi/doczipper/ CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvs/debian Blank password, module doczipper. It edits the /var/lib/dpkg/info/package.list databases so that when a package is removed, purged, or upgraded the renamed HTML documents are properly tracked and dealt with. Footnotes: [1] I'm willing to take on this task. - -- We should not penalize the conscientious to coddle those who run brain-dead software. I am karlheg, of deB.ORG. You will be freed. Resistance is useful. mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.debian.org/~karlheg - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard http://www.gnupg.org/ mQGiBDd9FHERBACPLkybc3h39HQyzCEYtljMnrOjDg1KY2BXDwC4vC4m6zQ4w2Kr 72YEZ4+rwGa6lluPpf+cmeRYAHvxO0sgRysWD1qyer0+wash7y9G/QG6+XIWlZ45 X11EduAr9G5n99SjaK67a6vqe9rplZrJgp0TrkKXrZo46Plyr4OVIo588wCgnc6r a8K6fxVfUc2iqxvL8pYK+z0D/04ZN10kC2W1mxMdvbNBT+aB/jMFu9GsnP5kJJSu n7IqNUMHQVylIxUeKeNO0FlKJ4tE0ZWXi1CFV02+BdW9sSzevbP45TgzPXwkehK5 XXaKrWBS3eZOTJ5Z23qBaM9VmuFywSN7t6ptKld6MjaKCvbVE57vVT1is5gIuR4C qhgvA/4z2xrYq7tB5FHAnupoHHWotFKvI+8rsRIvme9l7h7YMEvH7EJEYwtkZD8a Z2bAr52Oe/NShkRtj0XuGqStJ6ifu0TCSs/wKzNqmXfH8xCYqjeOQ/rC8QqyevvD dxC6UGt3YwAoNqKD7AKnNr188VGNyPhhYyiu4gvYeESK3mG+l7QlS2FybCBNLiBI ZWdibG9vbSA8a2FybGhlZ0BkZWJpYW4ub3JnPohVBBMRAgAVBQI3fRRxAwsKAwMV AwIDFgIBAheAAAoJELSFmU7xzGp6ghgAmgLuY5rkZ6J42nvp1QOpklB4hyUvAJ0b aAusbYsyfYh1Wb+2oiozBap1Q4kBFQIFEDi11CSMRdyqIb5RyQEBKccH/i1oMjpX ITgU1cnJTGUh68uWyaiOGyzbEykveHX/Z5UpuaCc+i7jefT8fyXbWluWZ5C+teJI kpHM7Z8fGgqWSe5hWbLBz7zkP/+9Ii9aOv4e/rvh/9OTnAUmgUgJjMIziUob2dGY cvVKBSQma1caqBDSwoZuPDSFnhkkxnn+q3l1zvTl/VPoVIHXCtxYG/4x8y1oYZ5S pJg+qIm5eikVXKJjhEj8izsVJBJbI0yONOUa+fOCUIc1e0MPy8Ant3TGPbR8FbMG TapnKEUtppN3XmOtkLOeq5YHQHE95nCU9bR/+HGRy2Dm1kN4jk8QCaJV0Sf+OK20 LVUmsWEKAaUrjuq0O0thcmwgTS4gSGVnYmxvb20gKEhvbWUpIDxrYXJsaGVnQGJp dHRlcnN3ZWV0LmluZXRhcmVuYS5jb20+iFYEExECABYFAjh+7DYECwoEAwMVAwID FgIBAheAAAoJELSFmU7xzGp6iccAn1iKWD278Y3tMK3IjD5CcPtTf38cAJ424aOf Sa3C0fYYXMN7cK9mXF7VB4kBFQIFEDi11FKMRdyqIb5RyQEBFRAH/3LmrMjIQafO w6fc+wWLhHCxpJPQuxh6CGjWr79Eg3lt4Yo7VYsY6VoxHoGi230f+jcLqRN6sMce HxBgTYjc+Ap8Quud0LRTC91jjI7nt6rpA/2hnqAmZyyK9MfMaZzvFDQMZwtrskbk 8tcy7Qtqh0iOMUvLdVDI4wogoCih6wJr127Vmr6A8FHIR9iLisQArl7TKb4hNUXg y4blNY3iJsl0LI2Mb7Jd5j1E++vt4O6KMNTpNu5R84DWgzt1uE97aGWVwG/rtLYH dJ/woR1PZruAH8ce8ZuItkZQMZmO86ip2sjGn4JJVUQCZ94qK/km2g0HmbNAn74h 1hxEgOk1Qba5AQ0EN30UixAEAP/qZtKCaMmIONxOL1bxQvVNjEWav6stWDkpkVTa uFUsHZvfSWXrNqhho5/Keo1teJ+aEpGqUTPs2wx0qM+8pzlCsF+UFHfpdfHwOFJ+ vifRhUhPaAu0d+y86S5AIp1L0kwGzFBlbUlcRFvn7NGi5tVHnTI+1RHIGsXgn63r D9SfAAMFBAD/cYqwCb/MvcDQ76w58GojpV6gLGIw4lGycXzNtClL0nnHNMzEBfjn Bxi4bLbMqwR/zEqpVvsJ7xF3M76FKAQ0ei/MqH23A9Efq96jdCJzgokClguqFf2I
Bug#41113: lang-lib-foo: Seconded.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a winner of an idea. I think they ought to be named like lang-foo-lib, so that they will sort by language, then by lib, or extenditsome, then by foo (the name of the library or extenditsome). -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard http://www.gnupg.org/ iD8DBQE41yY5tIWZTvHManoRAlyaAJ0UpayYvc8SoyyzE7vm2kCKLHzuXwCfSXmI 2QC8Pc/ST8o7AGjcf2lQ2Yk= =+AH2 -END PGP SIGNATURE-
Bug#43077: configuration=arch-vendor-os: Seconded.
Several programs I've built, includeing XEmacs-21.2-devel (CVS)[1]
will accept only three part `configuration' strings in the form
arch-vendor-os. I think it's best that we put debian in
the vendor field in all builds we do. Several prominent members of
the XEmacs Development Team are in agreement; they have advised me to
try and influence Debian Policy in this direction.
I offer to try and write that section of the Policy Manual if folks
all agree that this change should be made.
Arch needs to be normalized to i386 for the x86 architecture, and
the CFLAGS must be set for i386 compilation, unless we decide to
create an i{5,6}86 binary release also, which some of us would like
to do, I think. (How much of a performance improvement does building
everything from the kernel up with -mpentiumpro or whatever buy us?
I have not researched this issue.)
Footnotes:
[1] Which I've begun a packaging scheme for... ask if you would like
to see it.
[Stephen J. Turnbull turnbull@sk.tsukuba.ac.jp] Re: [configure: feature request] Support configuration like `i386-linux'.
---BeginMessage--- [EMAIL PROTECTED] (Karl M. Hegbloom) writes: I would like if I could say `configure i386-linux', rather than `configure i386-debian-linux'. Here's why (one paragraph at top of page): URL:http://www.debian.org/doc/debian-policy/ch5.html I think you're missing the point. See Chapter One: Debian 1.1 Scope Debian This manual describes the policy requirements for the Debian Debian GNU/Linux distribution. This includes the structure Debian and contents of the Debian archive, several design issues Debian of the operating system, as well as technical requirements Debian that each package must satisfy to be included in the Debian distribution. This is instructions to _Debian package maintainers_, not to the upstream development organization. So the architecture spec string is NOT something that XEmacs.org is under any pressure from Debian to change. Rather, _you_ (AFAIK you are the DPM in question) should fix (if fix it is) this in $XEMACS_SRC/debian. If a configure wizard wants to help you with that, OK. But as Kyle ([EMAIL PROTECTED]) points out, making this change means that Debian autoconfs are going to always be broken with respect to everything else in the GNU world; I think this policy is going to have to get clarified. I think you should ask the Debian cabal if they really meant what they seem to mean, or if they meant another idea by the same expression. Have you checked other GNU autoconf-using programs in the Debian distribution to see how this is handled? Jan == Jan Vroonhof [EMAIL PROTECTED] writes: Jan That idea seems broken to me. Configure machine types always Jan have been been triples. I agree. God save us all if we had no way to identify vendor when vendor == Red Hat.[1] But the principle is the same with all distributions; they all patch their libs, they all provide different features in different ways, and that vendor ID is useful. Debian Note, that we don't want to use `arch-debian-linux' to Debian apply to the rule `architecture-vendor-os' since this Debian would make our programs incompatible to other Linux Debian distributions. But some of them are, anyway, due to differences in compliance to say the FHS or placement of configuration files, etc. Note that they proceed to give the whole game away by admitting that they think vendor == unknown does not look very good. That's a terrible reason to break standard on something that is behind the scenes in any case. Footnotes: [1] Well, at least as of late 1997. They may have gotten their act together since then. -- University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _ _ _ _ What are those straight lines for? XEmacs rules. ---End Message---
Re: [Jan Vroonhof vroonhof@math.ethz.ch] Re: [configure: feature request] Support configuration like `i386-linux'.
Any comments on this?
Re: [configure: feature request] Support configuration like `i386-linux'.
Kyle == Kyle Jones [EMAIL PROTECTED] writes: Kyle Karl M. Hegbloom writes: I would like if I could say `configure i386-linux', rather than `configure i386-debian-linux'. Here's why (one paragraph at top of page): Kyle This makes no sense to me. Including the vendor type does Kyle nothing prevent applications from wildcarding matches Kyle against that field. Changing the string from three Kyle components to two will break code. If you want to type Kyle less, just type 'configure' and leave off the other stuff. Did you follow the link I posted and read the paragraph about it? I'm not the one who made that policy. I don't know why they decided that. It really doesn't matter to me, personally, what goes in that string as long as XEmacs builds and I can edit, read, and do other neat things with it. I will just use i386-debian-linux.
`dhelp' documentation heirarchy
I think we should begin to standardize the orginization of our documentation heirarchy. It would be good if the same basic organization applied to both the dhelp docs and to the info directory... For instance, I'd like it if, instead of a bunch of python module documents under Programming, there was a sublevel under Programming for Python, then under that, a sublevel for python extension modules/libraries. It would clean up the pages some, and give some indication of what shipped with Python proper and what shipped with the lib-whatever-python packages. We should all look over the tree in http://localhost/doc/HTML (/doc/ defined as /usr/share/doc/) and see what other changes could be applied. Are there more categories than required? Any package can define an arbitrary category. I guess that's ok, but perhaps it's best if there are a standard set of them to choose from. It's like the menus.
[3.0.0.0] Policy manual copyright notice.
I just updated to the newest version of `debian-policy', and noticed that the copyright date is `1998'. Shouldn't that be updated?
Re: Editor and sensible-editor
IMHO, any serious Linux user learns to use the emacs, falling back on vi. Pico is silly.
Re: Bug#37713: [PROPOSED] separate menu policy (like virtual package list)
Chris == Chris Waters [EMAIL PROTECTED] writes: Chris [EMAIL PROTECTED] (Karl M. Hegbloom) writes: What about standard `info' and `dhelp' categories? Chris Hmm, at first I thought you meant that you wanted these Chris added as categories to the existing menu hierarchy. Surely Chris that's not what you mean -- please tell me that's not what Chris you mean! Chris If you mean (as I hope) that we should create standard Chris categories for use *within* the info and dhelp systems (and Chris don't forget dwww), that's not a bad idea, but it's Chris unrelated to #37713. Come up with an actual proposal, and Chris if it's a good one, you'll have my support. Yes, that's what I was thinking of when I tapped that one down. I'll put it on my ToDo list. (Right this minute I've really got to get back to SICP.)
Re: Bug#37713: [PROPOSED] separate menu policy (like virtual package list)
What about standard `info' and `dhelp' categories? I think in `dhelp', there ought to be a subcategory for `python', `scheme', `sql', and `perl', etc. Perhaps under `programming/languages'? -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Re: dialout, dip, uucp groups.
Philip == Philip Hands [EMAIL PROTECTED] writes: Philip [EMAIL PROTECTED] (Karl M. Hegbloom) writes: /dev/ttySx ought to be group owned by `dialout'. The directories where the `uucp' programs need writes ought to be owned by a `uucp' user and group `uucp'. The `uucp' user should be put into the `dialout' group. Where does `dip' fit in? Philip Dialing out using minicom, and dialing out (or in) using Philip pppd have different security implications (especially if Philip routing is enabled on your host), so you might want to Philip restrict people to being allowed to do just one of these Philip things. Ok. So `Dialup IP' (dip) ought to be a different group from `dialout' then, as it is now. -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Bug#37999: PROPOSED]: A pre-install required space checking mechanism for Debian packages
I don't understand this discussion... Why, when I use `apt-get install package', does it tell me how much space will be used after installation, if that's a thing we need to add to the package tools? -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Re: utmp group proposal
Marco == Marco d'Itri [EMAIL PROTECTED] writes: Marco On May 20, Karl M. Hegbloom [EMAIL PROTECTED] Marco wrote: I've noticed that there is currently a `uucp' group, a `dip' group, and a `dialout' group. Do we really need all three? What is the Marco Yes. uucp is used by the UUCP program, dialout owns the Marco modem device and dip can start pppd and dip. `minicom' is group owned by `uucp'. Marco This is wrong. BTW, it's not even sgid, so I see no reason Marco to chown the binary to the uucp group. Should it be `chgrp dialout', with o-x? Or root.root, o+x, and rely on device permissions for access control, so that a machine could have perhaps a ttyS for a serial line, and another for a dialout modem or something? Is that real? The question is, do we really need `dialout', `dip' AND `uucp'? You tell me and we'll both know. I'll listen to more experienced advice. -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Bug#37999: PROPOSED]: A pre-install required space checking mechanism for Debian packages
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Karl M. Hegbloom wrote: I don't understand this discussion... Why, when I use `apt-get install package', does it tell me how much space will be used after installation, if that's a thing we need to add to the package tools? Joey Apt can only tell total space used. It can't tell that Joey although you have 500 mb free on your /usr partition this Joey package happens to use 2 mb in / which only has 1 mb Joey free. The only way to allow it to tell such things is to Joey provide it with output similar to du run on the package. Ahh... Ok, now it makes sense. It needs information about disk usage per directory the package will install files in, so that it can do a breakdown and size check on each mounted partition at the installation site. Hmmm. I'm interested in seeing how this problem will be solved. -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
dialout, dip, uucp groups.
/dev/ttySx ought to be group owned by `dialout'. The directories where the `uucp' programs need writes ought to be owned by a `uucp' user and group `uucp'. The `uucp' user should be put into the `dialout' group. Where does `dip' fit in? -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Bug#37999: PROPOSED]: A pre-install required space checking mechanism for Debian packages
M Look at this script:
OK... Thank you for the Perl example. I've just begun to learn the
language... I have a question that no doubt I can answer on my own
after actually readin ALL of the perl manuals (I have the `info'
version, and have read part of it, and all of the camel book, as well
as some of a few other books on Perl...)...
Why must you call `print_du' like that... Let's see. The ('Size
Data' = $data) constructs a reference to a hash with one key, Size
Data. Why can't you just do something more like:
my $data = check_du();
print_du($data);
... then in print_du, assign `my %params' as `my $data = $_[1]'?
I'll go ahead and mail this anyway, then hit the info's.
sub print_du {
my %params = @_;
croak(Need argument 'Size Data') unless defined $params{'Size Data'};
for (sort keys %{$params{'Size Data'}}) {
next unless $params{'Size Data'}{$_}{'Size'};
printf %10d %s\n, $params{'Size Data'}{$_}{'Size'},
$params{'Size Data'}{$_}{'Name'};
}
}
sub test_du {
my $data = check_du();
print_du('Size Data' = $data);
}
--
mailto:[EMAIL PROTECTED] (Karl M. Hegbloom)
mailto:[EMAIL PROTECTED] (Karl M. Hegbloom)
Portland, OR USA
Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Re: utmp group proposal
I'll second on official creation of the `utmp' group, even if none of the other major Linux distributions are also doing this... though I wonder if they are, and if they also call the group `utmp'. We ought to use the same group name, even if not all use the same standard GID for that group. Is the Linux Standards Base project still alive? Along these same lines... I've noticed that there is currently a `uucp' group, a `dip' group, and a `dialout' group. Do we really need all three? What is the intended use of each group? Shouldn't they all just be consolidated under `dialout'? `minicom' is group owned by `uucp'. My ttyS1 is owned by group `dialout', and `pppd' is owned by group `dip'. I don't see the need for all three groups. Is there a reason for that that I've not thought of? -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Re: md5sum proposal
Piotr == Piotr Roszatycki [EMAIL PROTECTED] writes: Piotr Maybe dpkg should have own verification system? As I known Piotr RPM can verify its package database. Does anyone know offhand how `rpm' performs that operation? We ought to investigate. -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) Portland, OR USA Debian GNU Potato Linux 2.2 AMD K6-233(@266) XEmacs-21.2beta
Re: Bug#37532: coda-doc: HTML files gzipped
I've recently uploaded a package called `doczipper' that compresses the HTML documentation in /usr/doc... It comes with documentation explaining how to configure `apache' to use mod_rewrite and a service script that decompresses the document as it is streamed to the net. It was destined for `experimental', but is stuck in Incoming right now, the REJECT message says my PGP key is not in the keyring... I've just changed it, and am awaiting having it signed by another Debian developer. Go ahead and grab it from there if you like; I'll leave it for a few days. Please at least read its manual. DON'T just run it without reading its manual. Yous might like to look it over. Note that it's currently a little broken; I got the dependancies wrong, and there's NOT a script to decompress the HTML after it's been compressed. That's why it's going in EXPERIMENTAL for now. Please at least read the manual, and give me a little feedback. Try it if you like; after you've read my Perl code and feel comfortable running it. Note the commandline switches for telling it what directory to run on and such... you can experiment with a copy of one of the /usr/doc directories. I may require reading some of the Apache documentation. It's not going to just work yet. Please send me comments, ideas and feedback. Tell me if I've done the `dpkg' locking thing right.
Bug#37233: PROPOSAL] FORMAL structure for DEBIAN-POLICY debate
A FLIPPANT OFFTOPIC POSTING is one such as the one I mailed earlier this week that probably has no place here. I will try and refrain from doing so in the future. This is a serious forum, and we ought to stick to business.
Bug#37233: PROPOSAL] FORMAL structure for DEBIAN-POLICY debate
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj I hereby formally object to this proposal, as I think this Manoj is something that merely add bureaucracy to the list, and Manoj shall do little to actually increase throughtput. Not to mention there isn't (yet?) a Gnus `message' minor mode for editting such things...
Re: Software in main that is throughly useless without non-free software
Divide and conquer?
Re: PROPOSAL: libtool archive (`*.la) files in `-dev' packages
Ossama == Ossama Othman [EMAIL PROTECTED] writes: Ossama Hi, Where do we stand on my proposal to include `.la' Ossama files in `-dev' packages? I thought it sounded like a good idea, but refrained from seconding since I don't feel qualified... I was hoping folks with more expertise and experience than I currently have would look it over and decide. Ask me again in two years though...
Bug#37342: debian-policy: [PROPOSED] move to logrotate
bazsi == bazsi [EMAIL PROTECTED] writes:
bazsi Here is a good example for a logrotate config file
bazsi (for more information see logrotate(8)):
bazsi /var/log/apache/* {
bazsi[...]
bazsikill -HUP `cat /var/run/apache.pid`
bazsiendscript
bazsi }
bazsi Which rotates all files under `/var/log/apache', saves
bazsi 12 compressed generations, and sends a HUP signal at
bazsi the end of rotation.
Shouldn't that use `/etc/init.d/apache reload' instead? Most things,
as far as I know, will work that way, sed -e 's/apache/$DAEMON/'. I
think it would be good to display the /etc/init.d/* method in this
policy item, as a way of documenting that feature of the sysvinit
scripts, which provide a standard interface to reloading any daemon.
Bug#37342: debian-policy: [PROPOSED] move to logrotate
Balazs == Balazs Scheidler [EMAIL PROTECTED] writes: Balazs So the line kill -HUP `cat /var/run/apache.pid` should Balazs read: Balazs /etc/init.d/apache restart Yes, I think so. See that others concur.
Installing things into run-parts or .d directories.
What if a package is installed, and puts a script in a run-parts directory or into a .d directory, but isn't configured due to a missing dependancy? The newbie sysadmin doesn't know to look for it, and leaves it there, then gets email from cron. Per sends off a tech support question. This could be prevented by having a place (/etc/cron.scripts, or /etc/cron.d/crontabs) to install things to, then require that the postinst create a symlink during configuration. Hmmm... /etc/crontabs /etc/crontabs/crontab /etc/crontabs/cron.d/ /etc/crontabs/pkg_blah_script ...
Re: Email in debian-policy that is throughly useless without non-free software and chip features.
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Unfortunately, we do not live in a world where all software Manoj is free. Neither are all protocols. Sometimes, some Manoj communication protocols gain popularity with the masses Manoj that have no free implementations. We freed software (and tuition)! I want to WRITE protocols, not just steal them from GNU and shrink wrap them binary-only ported to the wonder$ of new and improved MT service pack v199.200.1 for only $29.99 a copy on a 50 cent CD. Manoj Imagine when a group of people say Hey, call us using Manoj foo-grubble, and we can have a neat game. And we have to Manoj say, sorry, no can do, I use linux, and I am unable to do Manoj that. Sorry, I'm too into Linux to waste my time playing foo-grubble Y2K brand sex scandal chat with a bunch of AOL'ers on windoze pay'n. I don't even have time for Internet phi-ed. Besides, who's got $199.20 to spend on a foo-grubble Y2K brand sex scandal chat client anyway? Or time to use a freed one with code to read! I'd much rather watch a program... I can't even afford tuition and rent, and the world's about to end because somebody flamed me in an email about saying blah about non-free foof in a public forum! And there was typos too. Manoj At that point, the impression is that we are running a less Manoj capable system. Hmmm. A non-cognostatic impression of foo-grubble inadequacies amoung %99.9 of egg-sitting penguins? My lored! Reinstall! Reboot! Run down to egghead! Tell those overqualified hippies to send us another GD espresso java service pack, STAT! Change the advertisements under my icey cage! Bread and circuses! More! Better! Faster! Good enough! Sell it! (not (english We need lotz more quake attack drive the droid VR games around here too. cigar slides to other side of mouth A war overseas isn't REAL enough! Let's make robocarbombs like REAL warboughten flatbrow pseudo engineers! We'll drive them around in pretend-it's-really VR and blow up things on live TV, dude!)) == Yow! Like totaly Back in Black, ya 2 know? If I disappear, you'll all know why. Karl M. Hegbloom(Private citizen living in USA) I live on $550.00 a month.
Re: Software in main that is throughly useless without non-free software
Luis I've been snooping on this list and thread for quite some Luis time, but this one finally made me need to respond. Welcome, Luis. Luis On 4 May 1999, Manoj Srivastava wrote: Unfortunately, we do not live in a world where all software is free. Neither are all protocols. Sometimes, some communication protocols gain popularity with the masses that have no free implementations. Luis Sometimes, some *operating system* standards gain Luis popularity with the masses that have no free Luis implementation. Luis I for one don't think that's a sufficient reason to use that Luis OS- do you? What're the reasons for not using that store-bought OS to which you refer? It's not the monetary price of it is it? Are the issues related to engineering philosopy and source code availability + modifiableness, or to economic philosopy and marketting challenges? Imagine when a group of people say Hey, call us using foo-grubble, and we can have a neat game. And we have to say, sorry, no can do, I use linux, and I am unable to do that. Luis Imagine when a group of people say Hey, *I'll send you the Luis doc in Word98 format.* And we have to say, sorry, no can Luis do, I use linux, and I am unable to do that. Imagine everyone spending the time it takes to really learn to use LaTeX markup or an SGML. Luis I imagine that, and have it happen to me every day. So what? Luis I knew that was a problem when I switched to Linux, and I Luis deal. Ooohhh... a dealer. Cool. 8-) Psst... Ya got any good Java, man? At that point, the impression is that we are running a less capable system. Luis Well, in some ways we *are* running a less capable Luis system. Practically speaking, if we don't force people to Luis write alternatives, we will never have a more capable Luis system. dpkg-autocodegen --force-alternatives pennyless-studenti.dtc [1] I'm thinking of re-reading the GNU Manifesto and .../src/xemacs-21.2/etc/MOTIVATION again... Luis If stamping a product non-free will motivate people to Luis write a replacement, then this is a necessary Luis step. Certainly, saying it is completely free (which it Luis obviously is not) will not do much to motivate that Luis development. motivate that development means what? I need to put food on my plate, and would love to afford college tuition and rent. It would be nice to have a few days and a few dollars to play also... and to attract a mate with. (They like men who put food on the table.) When some one creates a client side of that protocol, using totally free software, and empowers our users with the ability to particiapte; that is a good thing. We have added capability to our system. Luis Again, I think I speak for many of us in saying that Luis capability is NOT the only important thing. If that were the Luis case, many of us would be using Office on our MS98 Luis systems. Like it or not, by choosing Linux we are choosing Luis reduced functionality, which may or may not improve with Luis time. Blah. Will improve as those of us who are committed to sitting on our penguin egg (while reading) learn to code great applications. Let's hope that the folks at Microsoft and other software companies who've written some very good libraries and applications will see the light and hand it down to us without forcing an NDA for every Byte. It would be kind of neat to see serious MS library and application sources on public FTP servers... Someday I might be able to see for myself and answer the questions about whether, for instance, OLE is a better engineered approach to whatever it does than brand X openbuzzword. Of course, it would be nice if we had free server software too. That shall come with time. But turning away free software cause it talks to non free software on *ANOTHER MACHINE*, hurts the free software community. Luis That shall come with time is a very passive attitude. I'd Luis venture to say that very little that this movement has Luis achieved has come because someone said oh, we'll just use Luis the non-free version- someone else will fix it later. You're right Luis. It's more of a take off the watch and push the buttons / turn the pages kind of thing. It's a I'd send a patch if I could, but you know the system better than I do; please show me what you did to fix it., said the baby gnu. situation. Luis Rather, someone said Even though this works right, it is Luis *wrong* in a deeper sense. I will fix that problem by doing Luis it myself. That is how things get done in Free Luis Software. Being satisfied just because something is Luis functional is what hurts the community, and that is what Luis we are doing if packages like this go in main.
Re: Software in main that is throughly useless without non-free software
Remco == Remco Blaakmeer [EMAIL PROTECTED] writes: Remco Now, I ask the same question again but with a little Remco difference: Since Policy defines which packages can go into Remco 'main' and which can't, can somebody please point out which Remco part of Policy these programs fail? I have read the Remco requirements for packages that want to go into main. I Remco don't see what's wrong with free packages that talk Remco proprietary protocols for which is no free 'other end' Remco available, as far as Policy is concerned. We've accepted that the Linux kernel itself can go into main, even though it's got support for non-freed proprietary filesystems. So why not a reader for Word documents?
Re: Software in main that is throughly useless without non-free software
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj [...], so someday we may have all free systems Hmmm... `freed systems'?
Re: Software in main that is throughly useless without non-free software
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony [...] people who run Debian who want a functional system, Anthony in spite of some alleged impurities? ^^ What?! Cruft in Debian? No way; I'll never believe it. Anthony [...] people who run Debian who obsess about freedom and Anthony stuff? Are they real, realists, and really anything resembling an informed majority? Most of us, I get the impression, are computer professionals, serious students, hobbyists, engineers, or scientists. Do we really have the time to obsess about anything but our science or our Very Own MIS dept? Let's share our code so we spend less time re-inventing it! Let's pool our efforts and make it better for the common goo^hd. Lets make our systems interoperate and co-operate so we don't indepenantly run six deisel burning semi trucks across the state to haul one cardboard box each. That's GNU.
Re: let's be practical [Re: Software in main etc.]
rough I propose that we say that software that can read a proprietary file format or network protocol is Ok for main, as long as it's linked (ln) to libraries that can go in main, and the company or person who wrote the original protocol or file format doesn't object to our using it (or the algorithm required to read or translate it) by way of having stipulated that it's forbidden to in the software licence to their version of the client, or by coming on our public mailing lists and saying we can't do that. (Q:should we ask them for permission in some or all cases?) rational We allow the kernel's filesystems and lilo which depends on a binary-only BIOS, (other examples anyone?) so by this we must also allow Word2x and tic./ This ought to be put into nicer words in the policy document, to clarify things so that the argument won't be resurected six months after we finally declare it moot. /rough -- Am I forbidden to tic but not to toc?
Re: PROPOSAL: libtool archive (`*.la) files in `-dev' packages
Joel == Joel Klecker [EMAIL PROTECTED] writes: Joel I suggest not using the term versioning to refer to sonames, Joel it is too easy to confuse it with symbol versioning. Where may we read about symbol versioning and things of that nature, please?
Re: Hey! Why does everybody love flaming so much? [was: `pure']
comment I guess `contrib' or `non-free' is no big deal to a student or hobbyist, but to a professional, it is, since that means you might have to pay someone for a licence if you base your product on that `non-free' library or whatever. /comment
Re: Hey! Why does everybody love flaming so much? [was: `pure']
Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus The question is if we can continue to get stronger Marcus indefinitely by embracing the proprietary world, or if it Marcus is time at one point to actively go against proprietary Marcus protocols and software patents. The other question is when Marcus the time has come if it is time to fight. I hear they have paying jobs. Why fight it? Let's share the tools.
Re: Email in debian-policy that is throughly useless without non-free software and chip features.
I apologize to the harumpfers who can't tolerate my ocasional flippant episodes...
Re: Menu-policy (was Re: Policy Weekly for May 1)
Chris == Chris Waters [EMAIL PROTECTED] writes: Chris proposed amendment text: ChrisTetris-like - games involving falling blocks ChrisToys - amusements, eye-candy, etc. Chris + Help - programs that provide user documentation Chris Screen - programs that affect the whole screen ChrisLock - programs to lock the screen Chris I think the idea of a top-level Help section has enough Chris buy-in that there's no real need to wait on it. I don't Chris think that's true of any of the other proposals I've seen Chris (even my own). I concur.
Re: Unidentified subject! (fwd)
Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes: Anthony On Fri, Sep 11, 1998 at 05:18:18PM +0200, Anthony Anthony C. Zboralski wrote: hey is there an easy way to print info manuals? Anthony No. In order to have acceptable quality output, you have Anthony to use the TeXinfo source files. for manuals like libg++ i am not going to print everypages manually; maybe i am stupid and there is an easier way to do this but when i need to print a texinfo manual, i have to grab the package source, run configure and make dvi. Anthony You could try getting policy extended to have .texi Anthony sources (in a form suitable for texi2dvi) included in the Anthony package (or in a separate documentation package) - Anthony propose it on debian-policy@lists.debian.org I think that the .texi source belongs in the package source. Why make yet another package out of things when it's already there? Perhaps there ought to be (ie, suggested by, but not required by policy) a debian/rules target for creating the .dvi or .ps, whenif the upstream Makefile doesn't perform that task adequately. muse It sure would be nice if someone would extend `gv' to have `Lectern' like keybinds, with searching and everything... and maybe some `info' keys too. sigh I've got a book about postscript, but haven't read it yet, and don't know C and X programming well enough to take it on yet. grin /muse
Re: Call for Seconds, Take II
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hi Karl == Karl M Hegbloom [EMAIL PROTECTED] writes: Karl Also, ChangeLog files are named with capital `C' and `L' Karl when you use `C-x 4 a' with `add-log' in the emacsen. I Karl think we should permit that spelling, which is very standard Karl and more common than all lowercase, rather than symlinking Karl or renaming. I like it capitalized since that makes it sort Karl near the top of a directory listing in `dired' (or any other Karl file manager). Manoj Are you proposing this as an amendment to the Manoj proposal? Sure. Will anyone second? Another thing I've been doing... I use `pcl-cvs' (a recent beta, in XEmacs 21.2 beta; you can grab an _unofficial_ version and try it if you like, off my http site. It is greatly improved over the older version, and needs to be tested by someone who uses GNU Emacs, rather than XEmacs.), and have `change-log-default-name' customized to ChangeLog.local. When I make a changelog entry with `C-x 4 a', it puts that entry in my local changelog file, so that later joins with upstream sources don't create the inevitable conflicts in ChangeLog. I also put that ChangeLog.local into the doc directory... I only log packageing type changes in the Debian changelog, and code mods are in the ChangeLog.local file, since that works better with `pcl-cvs' and `add-log'. I guess the name could be other than *.local; leaving `local' for users who are CVS tracking the Debian version of a source ball? Hmmm. Any suggestions? -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 2.0 Linux 2.0.35 AMD K6-233 XEmacs-21.2beta
Re: {PROPOSAL} #7890: Policy manual contradicts itself about including docs
Adam == Adam P Harris [EMAIL PROTECTED] writes: Adam Manoj Srivastava [EMAIL PROTECTED] writes: I also further stated: I was not really suggesting replacing the info documentation (or the man pages, for that matter), I meant in addition to. The policy *does* say that HTML is our preferred format, so it should also be provided Adam Yes, I mostly agree. The *source* of the documentation Adam should also be shipped if possible (i.e., SGML, TeX). This Adam enables people to patch documenatation and send in diffs; it Adam also enables them to possibly format the source into Adam whatever media they like. The source is available in the source package.
Re: Finding a source package
John == John Lapeyre [EMAIL PROTECTED] writes:
John On Mon, 21 Sep 1998, Jason Gunthorpe wrote:
jgg
jgg We have rather a bit of a problem.. As it stands it is not
jgg possible to locate the source tar.gz and .dsc without
jgg searching in all cases,
There's so many packages now I end up searching using the CGI site
or `locate' on master anyhow. :-)
John I also sometimes wonder about the fact that, while we
John encourage people to look at the source, it is in fact kind
John of difficult to wade through the documents to find how to
John get and unpack debian source files. I hope apt-get source
John remedies this.
@drifting{
It just occured to me that perhaps it would be good to have a master
CVS archive of Debian, and the package source could be downloaded and
installed as now, using ftp or the new `apt-get'... I guess that
would also perform a `dpkg-source -x'. The source packages could
contain `CVS' directories that would link them back to the canonical
Debian anon ro-CVS, so folks could `cvs update' and `cvs diff'.
@offtopic{
I've tried to build Modula 3, (thinking of the fabled `cvsup'.) but
it bombed trying to build `m3gdb'. I've not tried to find out what's
wrong yet. It's huge; I think too big for a guy on the wrong end of
a modem connection to really do right. I think a small team at a
university ought to do this one. It looks like a neat language; very
archane syntax, perhaps, but good features, and LOTS of great example
code to learn from.}}
Re: Call for Seconds, Take II
Zed == Zed Pobre [EMAIL PROTECTED] writes: Zed + If the upstream changelog Zed + files do not already conform to this naming convention, Zed then this may Zed + be achieved by either renaming the files or adding a Zed symbolic link at Zed + the packaging developer's discretion. `libguile3' (development snapshot) has _several_ ChangeLog files. I've got them suffixed with the source subdirectory they are from. The upstream source ships with some older ChangeLog files that they've suffixed with a dash and the name of a subdirectory that's been merged with libguile/. I also copy those into /usr/doc/libguile3. The NEWS file is also present, and it contains a summary of the changes between releases. Also, ChangeLog files are named with capital `C' and `L' when you use `C-x 4 a' with `add-log' in the emacsen. I think we should permit that spelling, which is very standard and more common than all lowercase, rather than symlinking or renaming. I like it capitalized since that makes it sort near the top of a directory listing in `dired' (or any other file manager). I've created symlinks to most of the files in /usr/doc/libguile3/ from /usr/doc/guile3/ and /usr/doc/libguile3-dev/, since otherwise they would be duplicates, and both of those packages depend on `libguile3' being installed. I believe this is the sort of thing the symlinks are Ok clause is meant to cover.
Re: Call for Seconds, Take II
Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago On Mon, 14 Sep 1998, Zed Pobre wrote: + this string is reserved for the GNU Hurd operating system. Santiago GNU/Hurd Santiago [ I think everyone will agree on this ]. Yes... Why gnu rather than hurd though?
Re: Call for seconds: Policy modifications
Richard == Richard Braakman [EMAIL PROTECTED] writes: Richard I would find an architecture string with hurd to be far Richard more consistent. I agree.
? symlinks from doc/libpkg-dev to doc/libpkg
Is it ok to make the doc/libpkg-dev directory be a symlink to the doc/libpkg directory, since libpkg-dev cannot be installed without libpkg? I think this practice ought to be acceptable, to avoid duplicate files in doc/**.
Re: conffiles
Here's a good thing about having the conffiles listed the way they are: conffiles-backups Description: Binary data
Re: conffiles versus configuration files
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Kai /usr/X11R6/lib/X11/app-defaults/XCal.help Kai /usr/X11R6/lib/X11/app-defaults/XEarth Manoj 4.7. Programs for the X Windows system [...] uhh, /etc/X11/Xresources.d ? :-) Kai /usr/sbin/faxrunqd Manoj This is really bad programming style, if it expects one to Manoj edit a script for configuration. This is quite user Manoj unfriendly, and, moreevr, it means that changes can't be Manoj saved merely by backing up /etc. It seems to me it would also make it more difficult to create a `gui' style interface for configuring such a program. Kai /var/list/.bin/mimencap.local /var/list/.etc/archive.txt Kai /var/list/.etc/help.txt /var/list/.etc/rc.archive Kai /var/list/.etc/rc.custom /var/list/.etc/rc.main Kai /var/list/.etc/rc.post /var/list/.etc/rc.request Kai /var/list/.etc/rc.submit /var/list/.etc/subscribe.txt Kai /var/list/.etc/unsubscribe.txt Manoj What on earth are these files? If they are user Manoj configurable, how come they are in hidden directories? Why Manoj are they not in a subdir of /etc, with a symlink as needed? Manoj This seems like a bug to me. Those are for `smartlist'. They are `procmailrc' files. I like them where they are, since they can be backed up as a set, separate from /etc/. Kai /var/news/WELCOME Again, this can be made a backup set. (perhaps a low priority one at that.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: Extrafiles (was Re: Conffiles...)
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony (as it stands, things like `dpkg --search /etc/passwd' Anthony results in `dpkg: /etc/passwd not found.' Personally I Anthony consider this alone a little disconcerting) ... and it takes forever and a day of disk ggzztting to give you the result too. I will be glad when the contents of some future and quick database have been worked out, and that database gets built. `dpkg' could be as fast as `rpm' then. SQL? DB? NoSQL? What? How? How will the Debian GNU/Linux registry database work? What will go in it? What will be its interface? Will I be able to back up the conffiles and extrafiles as simply as I do now? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: Extrafiles (was Re: Conffiles...)
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian However, I disagree with the proposed syntax for the Ian extrafiles control area file. I think the file should Ian contain plain glob patterns a la fnmatch(3) (with * matching Ian /). The patterns should all start with /. Please also allow brace expansion then, of course. (I really like zsh style globbing, with the alternation and character classes. It might be good for glibc to obtain that.) Ian Should dpkg --purge automatically remove such files, as it Ian does for conffiles ? I think not. It implies a reference count, then, doesn't it? ... or grepping for it in every extrafiles list each time `dpkg --purge something' is run. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: Extrafiles (was Re: Conffiles...)
muse We could combine conffiles and extrafiles into one file, with a set of flags, like how `ls -l' is. Each file's record will have attributes attached to it, for `conffile', `extrafile' or maybe even both. Here by conffile, I mean one that's in the data.tar.gz, and `extrafile' one that's created by the postinst or the program itself. How would globbing of extrafiles be done then? /muse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
here
Just letting yous know I'm reading this list. There's about a 500 message backlog in this mailslot, so it will take a while. I will start at the end. I've been very busy; there's so much I need to learn. I will try and take a day later this week for nothing but Debian stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: defining a new runlevel, 4
I agree as well. I've a question. What are the `on demand' runlevels meant to be used for? (the a b c runlevels you can `telinit')? Is anyone using them for anything? What? I'd like to hear about it. Could they be used for bringing networking up and down? Or should they be left for local configuration? What if we decide to use them... how difficult would it be to add a few more on demand runlevels like that to init, to leave for local configurations? 0 - reboot 1 - Single User (sulogin) 2 - Local mode, no net, no X, 2 VC's, with `kbd request' bound to: # Action on special keypress (ALT-UpArrow).[1] kb::kbrequest:/bin/open -su 3 - Networked, start servers etc... 4 - XDM and networked? 5 - ? The `armadillo book' says that runlevel 5 is a `firmware state', if I remember right...[2] We don't need that. hmm... a - start networking b - stop networking c - ? 4 - Local only, no net, XDM 5 - XDM + Networked. ... ppp doesn't count as networked? Or does it? ppp always on might be, but `diald' might not... though the anti-spoof ipfwadm stuff should be run always, anytime a net link is going to be made. Footnotes: [1] This is supported in the /etc/kbd/default.map I'm using, which is the m4 output of the `hypermap.m4' from the kbd package. [2] I sold the book back for groceries a couple months ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PW#5-12: New upload procedure
Christian == Christian Schwarz [EMAIL PROTECTED] writes: Which term do the others prefer? How about: * file.c (function): The change I made. [Bug#] * file2: Another change here. [Bug#] -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU pre-2.0 Linux 2.0.33 AMD K5 PR-133 XEmacs-20.5b23 The Greenhouse behind the bazaar in Sanctuary.
Re: PW#5-16: Use of /usr/src
I propose that perhaps source code distributed in .deb packages, such as kernel sources, be unpacked directly inside /usr/src, and that the /usr/src/debian directory be designated for opening .dsc/.orig.tar.gz/tar.gz/diff.gz source sets. It occurs to me that this would be more of a convention than something imposed by the source handling tools. /usr/src/debian/Work/ could contain a developers CVS working directories, and /usr/src/debian/Build/ could be where the export/build/dupload cycle can take place. I think that someone with more experience than I have ought to give Red Hat's system a good looking over. I'm not qualified --- You tell me and we'll both know. I must follow the more experienced programmers' advice, of course. -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU pre-2.0 Linux 2.0.33 AMD K5 PR-133 XEmacs-20.5b23 The Greenhouse behind the bazaar in Sanctuary.
Re: PW#5-3: How packages can register cron jobs
Santiago == Santiago Vila [EMAIL PROTECTED] writes: * configuration files for which it is impossible to find a common file that works for every user should not be part of the filesystem archive inside the .deb package, so that dpkg will not prompt the user again and again when upgrading the package: Examples: /etc/X11/XF86Config, /etc/papersize, /etc/passwd... The idea is that once that you have the optimal configuration file, you don't want dpkg to ask about it on upgrades anymore. What about when the `base-passwd' package is upgraded, and some new base Debian-wide entries have been added? Am I expected to use `ediff' on the files, or will a perl script edit it for me?
Re: new policy topic --- syslog() [was Re: syslog facilities]
Some more facilities should be hacked into syslogd, I think. Hmmm... fax, ppp, www, isdn(?), uhhmmm... what else?
Re: suidmanager
Tommi == Tommi Virtanen [EMAIL PROTECTED] writes: BTW, I hope lintian will check that all the suid files are registered with suidmanager.. An issue then being that `suidmanager' must be one of the first things to get installed. Should it then be part of the base set?
Re: [Various] Mailcrypt - EMACS package maintainers please read this message.
Rob == Rob Browning [EMAIL PROTECTED] writes: Note that this indicates that in these cases it's up to the maintainer to determine when performance is an issue. For example, if there's only one .el file, and it just contains (setq load-path (cons /some/load/dir) load-path) Then I don't think byte-compiling's worth the effort. It's almost always worth the effort to byte compile the code. It will alway result in a performance gain. Often the code uses lisp macros, which run much faster when byte compiled, since they get expanded once at compile time, rather than each time they are read.
Re: RFC: New bug severity level fixed
Santiago == Santiago Vila [EMAIL PROTECTED] writes: I can think of an intermediate solution, to save space: Whenever a bug is closed, the entire history of the bug is replaced by a short history. Maybe a script could create a MIME email digest, gzip and base64 it, and make it an attachment to the bug closing message?
[Hrvoje Niksic hniksic@srce.hr] Re: [Various] Mailcrypt - EMACS package maintainers please read this message.
---BeginMessage--- [EMAIL PROTECTED] (Karl M. Hegbloom) writes: [ forwarded to xemacs-beta courtesy Karl ] Date: Thu, 22 Jan 1998 17:48:04 +0100 (CET) From: Christian Schwarz [EMAIL PROTECTED] To: Rob Browning [EMAIL PROTECTED] cc: debian-policy@lists.debian.org Subject: Re: Mailcrypt - EMACS package maintainers please read this message. Message-ID: [EMAIL PROTECTED] On 18 Jan 1998, Rob Browning wrote: [snip] 4) This one isn't directly related to your proposal, anyway, since we're going to update policy: could we add a note to emacs add-on package maintainers telling them to use (autoload ) forms rather than (load ) ones under /etc/emacs/site-start.d/? (Rationale: you don't want to automatically load something you may not use, especially in a site wide file.) [Currently debview has (load deb-view) in /etc/emacs/site-start.d/50debview.el; should I file a bug report?] That sounds like a good idea. Since I seem to be making the big emacs policy document I'll stick it in as a recommendation. BTW, should we keep the tiny section `4.7 Emacs lisp programs' in the Policy Manual or is this already contained in our new document: - ---cut-here 4.7 Emacs lisp programs Generally, if a package includes an elisp helper file, it probably doesn't need to be byte-compiled. If the package is written primarily in emacs, it is probably complex enough that speed is an issue and should be byte compiled. - ---cut-here I think this is a very wrong thing to recommend. Elisp packages should normally run byte-compiled, and this is not only about speed of compiled-vs.-uncompiled code. The code that makes heavy use of macros (e.g. using `cl' extensions) will literally *drag* when uncompiled. -- Hrvoje Niksic [EMAIL PROTECTED] | Student at FER Zagreb, Croatia + Which is worse: ignorance or apathy? Who knows? Who cares? ---End Message---
Re: dhelp/dwww: document.htmlgz, Apache mod_rewrite, mod_actions
I've made some minor modifications to `dwww' that allow you to gzip the html documentation, provided you run `Apache' with mod_rewrite and mod_actions. What it does is have `dwww' return a redirect URL, rather than try to access the HTML on its own. The redirect sends the browser to http://localhost/doc/blahblah/ and in /usr/doc/blahblah, the html files are gzipped, and renamed to file.htmlgz. There is a /usr/doc/.htaccess file that looks like this: .htaccess Description: Binary data And in `cgi-bin', I've got simple scripts that just print the Content-type: header and `zcat' or `bunzip2' the data to the net. The server has been configured, in /etc/apache/srm.conf, with: DirectoryIndex index.html index.htmlgz index.htmlbz2 AddEncoding x-compress Z AddEncoding x-gzip gz AddEncoding x-bzip2 bz2 AddType text/x-html-gzip htmlgz AddHandler x-html-gzip htmlgz Action x-html-gzip /cgi-bin/zcat-html AddType text/x-plain-gzipped .gz AddHandler x-plain-gzipped .gz Action x-plain-gzipped /cgi-bin/zcat-plain # ... or bzip2 them. AddType text/x-html-bzip2 htmlbz2 AddHandler x-html-bzip2 htmlbz2 Action x-html-bzip2 /cgi-bin/bz2cat-html AddType text/x-plain-bzip2ed .bz2 AddHandler x-plain-bzip2ed .bz2 Action x-plain-bzip2ed /cgi-bin/bz2cat-plain I've written a simple cron job that runs once a week and ensures that all of the newly installed .html files get gzipped and overwrite the old .htmlgz's from before the upgrade. I'd like it if the package installation tools would do that if the option is set for that. The URL's inside the documents don't need to be adjusted, since the sendmailish mod_rewrite rules handle that. I suppose that `boa' could implement a similar thing without too much bloat, and could perhaps perform the decompression itself. It could also be modified to send that data as is, with the right Content-type: and Transfer-encoding: for a gzip enabled browser to uncompress at the user's end... and perhaps only do that when `HTTP_USER_AGENT' is not =~ m/Win95|WinNT|Macintosh/, but unzip at the server when the other end cannot simply upgrade to GNU. The `dwww' patch is viewable from my `cvsweb'... I'll tell you the URL, maybe, if you write, and you're a Linux developer.[1] I have mailed it to Jim Pick; I don't know if he's had time to do anything with it or not. Footnotes: [1] I don't want to publish it to the search engines... I live on a modem connection. -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.3.1+hamm Linux 2.0.33 AMD K5 PR-133 Will work for food, books, computer parts, and ski trips. pgpzJimZHbm2p.pgp Description: PGP signature
Re: splitting debian-devel-changes
Santiago == Santiago Vila [EMAIL PROTECTED] writes: Well, now that the Debian ports generate a lot of postings in debian-devel-changes, I think it is time to split that list by architecture. Why not just use scoring in Gnus?
Re: Implementation of Developer's DB
Martin == Martin Schulze [EMAIL PROTECTED] writes: On Fri, Jan 09, 1998 at 03:16:00PM +, Ian Jackson wrote: Some people might want to be able to prefilter their mail into folders for different packages, and so encode the package into the email address. They should use `plussed' addresses for that, perhaps. eg: [EMAIL PROTECTED]'. There is support for this in `sendmail', and I would assume that `qmail' can deal with it.
Re: PW#5-10: System-wide environment variables used for program config
Kai == Kai Henningsen [EMAIL PROTECTED] writes: If program foo expects the environment variable BAR=/var/lib/fubar, an easy way to make it comply to this policy is to rename foo to foo-real, and write a wrapper shell script #! /bin/sh BAR=/var/lib/fubar foo-real $@ [I hope I got that right!] NOTE: This may not work if the program decides what to do based on the name it is called with. Fortunately, this is rare. Bash-2.0 `help exec' reads: exec: exec [-cl] [-a name] file [redirection ...] Exec FILE, replacing this shell with the specified program. If FILE is not specified, the redirections take effect in this shell. If the first argument is `-l', then place a dash in the zeroth arg passed to FILE, as login does. If the `-c' option is supplied, FILE is executed with a null environment. The `-a' option means to make set argv[0] of the executed process to NAME. If the file cannot be executed and the shell is not interactive, then the shell exits, unless the shell option `execfail' is set. ... is the `-a' a POSIX feature?
Re: Implementation of Developer's DB
Philip == Philip Hands [EMAIL PROTECTED] writes: I thought that the convention was to use ``minused'' addresses for this: [EMAIL PROTECTED] That's certainly the qmail way of doing things, and I seem to remeber a discussion on djb-qmail that concluded that someone who was using plussed addresses was doing so just to be different. Of course qmail can handle plusses too, but minusses are the default. Here's a paste-in of the `sendmail-8.8.8' ruleset 5. The part after the plus is essentially ignored when it figures out who to deliver the mail to, so your tosser (procmail or Gnus) can match on the part between the plus and the at. Like it says, this happens *after* the /etc/aliases lookup happens, so you can do things like: root: wecoyote+root ... and then `wecoyote' could have a ~/.procmailrc file that tosses everything with the `+root' into the root inbox, or a Gnus `nnmail- split-fancy' SPLIT to do the similar. A minus would make it be a different delivery address, and so that would have to be handled in either aliases, with specific aliases there for each minused address, or in a rule you wrote yourself especially for some ad-hoc purpose, perhaps implemented with a berkeley database table lookup or something. You can hook into the rewrite rule chain all over the place in `sendmail', a lot like you can with SmartList runcontrol setups. I suppose you could hack ruleset 5 to use `-', but then you'd not be able to have a user with a `-' in the login_id, which I think is fairly common. The `op.txt' in /usr/doc/sendmail/ says: You may want to use it for special per user extensions. For example, in the address [EMAIL PROTECTED]; the +foo part is not part of the user name, and is passed to the local mailer for local use. ### ### Ruleset 5 -- special rewriting after aliases have been expanded ### ### S5 # deal with plussed users so aliases work nicely R$+ + * $#local $@ $h $: $1 R$+ + $*$#local $@ + $2 $: $1 + * # prepend an empty forward host on the front R$+ $: $1 # send unrecognized local users to a relay host #R $+$: $L . $( user $1 $) look up user #R $* $+ $* $: $2 $3found; strip $L #R $* . $+ $: $1 $2strip extra dot # see if we have a relay or a hub R $+ $: $H $1try hub R $+ $: $R $1try relay R $+ $:$1 $(dequote $h $)nope, restore +detail R $+ + $* $* $1 + $2 $3 find the user part R $+ + $*$#local $@ $2 $: @ $1 strip the extra + R $+ $@ $1 no +detail R$+ $: $1 $(dequote $h $) add +detail back in R local : $* $* $: $95 local : $1 $2 no host extension R error : $* $* $: $95 error : $1 $2 no host extension R $- : $+ $+ $: $95 $1 : $2 $3 @ $2 R $+ $+ $@ $95 $1 $2 @ $1 It's either modem noise or SNOBOL... :-)
Re: Rationale for /etc/init.d/* being conffiles?
Perhaps they should be conffiles, and folks should be told about `ediff' editting with emacs. I usually say N when it asks, then go to an XEmacs and do [Tools | Compare | Two Files...] and merge the new into the old, if appropriate. If you want a one button computer, buy a Mac. What's it like to upgrade several systems? Are conffiles often the same, or would it require editting this way on every box?
