Re: broken links in the woody install documentation
James A. Treacy [EMAIL PROTECTED] writes: On Fri, Mar 15, 2002 at 11:09:07AM -0500, Adam Di Carlo wrote: I've fixed a number of broken links in latest CVS. i386 was referring to a wrong flavor. You have some note on other arches having bad flavors too, I'll check that out this weekend. Any idea how long it will be before this gets to the web pages? I'd like to wait on the next urlcheck run until you updates are available. Don't know. I thought that the install manual on the web site was built from the install manual by Josip nightly but it doesn't look like it is. For instance, URL:http://www.debian.org/releases/woody/i386/install has a last mod date of March 5th. Perhaps it only gets updated when a new version of the manual is installed? That seems a bit suboptimal to me... -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: woody install manual and www.d.o/releases/woody/
Josip Rodin [EMAIL PROTECTED] writes: On Wed, Nov 21, 2001 at 02:17:57AM -0500, Adam Di Carlo wrote: However, the potato version isn't, it seems :( Please see /org/www.debian.org/bf/potato/boot-floppies/make.log I checked for conflicts this time :) and didn't find any. That's so wierd. Can you try 'make clean' and the build it again? I tried it, it didn't help. In your repository, where is the Configure-the-Base-System entity defined? It's autodefined using the files in utilities/dbootstrap/po/* The script po2sgml does this. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: woody install manual and www.d.o/releases/woody/
Josip Rodin [EMAIL PROTECTED] writes: However, the potato version isn't, it seems :( Please see /org/www.debian.org/bf/potato/boot-floppies/make.log I checked for conflicts this time :) and didn't find any. That's so wierd. Can you try 'make clean' and the build it again? I just built the latest from the potato branch on klecker, no problems. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: woody install manual and www.d.o/releases/woody/
Josip Rodin [EMAIL PROTECTED] writes: Not for me :( Please look at /org/www.debian.org/bf/woody/boot-floppies/make.log on klecker. You have a CVS conflict in your local documentation/defaults.ent . Please make sure you are fully in sync with the CVS head and try again. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: woody install manual and www.d.o/releases/woody/
Josip Rodin [EMAIL PROTECTED] writes: Adam wrote: I'd like to get the woody installation manual online at www.d.o/releases/woody/. This involves both getting that in place and also WML revisions to the releases/woody area. Regarding building the manual, Josip has been doing that historically. It's aprocess of doing 'make doc-web; make mirror-to-master' off the boot-floppies CVS (HEAD). I believe Josip has a cron job running to do that --- is that true? Is it running? Can you have it CC me on any failure messages so we can keep this functioning on an ongoing basis? It's not running, I thought you saw my last mails. The compilation breaks for some reason. No, I haven't gotten any mail from you recently (unless it was subject to filtering). It's fine to have the script send the log to me whenever it fails, btw. Anyhow, the head builds for me now, I've fixed some problems. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
woody install manual and www.d.o/releases/woody/
I'd like to get the woody installation manual online at www.d.o/releases/woody/. This involves both getting that in place and also WML revisions to the releases/woody area. Regarding building the manual, Josip has been doing that historically. It's aprocess of doing 'make doc-web; make mirror-to-master' off the boot-floppies CVS (HEAD). I believe Josip has a cron job running to do that --- is that true? Is it running? Can you have it CC me on any failure messages so we can keep this functioning on an ongoing basis? Regarding the WML revisions needed, is anyone maintaining that area? It doesn't seem like anyone is. We need to get on this. Having it in good shape would help Debian woody install testers since it provides current information and online help. We should copy stuff over from the releases/potato area rather than start from scratch, IMHO. There's scripts to produce links to all the versions of the documentation. Can anyone get that? I _could_ do it (after the manuals are put in place) but I'm a bit busy with boot-floppies maintenance. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Bug#114348: www.debian.org: some items in the site map appearing in the wrong language
James A. Treacy [EMAIL PROTECTED] writes: Apache closely follows the http/1.1 spec. This means an 'en' variant will not be returned when 'en-us' is requested. On the other hand, an 'en-whatever' variant can be returned when 'en' is requested. Go figure. While apache is technically correct, it is completely unintuitive and causes problems when using content negotiation with every browser that uses country codes by default (which is a lot - even though the http spec cautions against this). Ah, it' s funny. I remember reading your stuff on this before. I guess if you want you can leave this closed, on the argument that Gerfried made, of technical correctness. However, I think that is short-sighted and unfriendly to users. I personally still think it's a (non-major) problem with www.debian.org. After all, the browser as shipped comes with en_US enabled (I believe) and this does cause some problems when seeing that particular page (why that one and not others I dunno). It doesn't seem to be right that in Debian, the mozilla browser as shipped causes problems with viewing www.debian.org itself! Perhaps it's a mozilla bug if it really does come shipped this way. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Bug#114348: www.debian.org: some items in the site map appearing in the wrong language
Package: www.debian.org Version: N/A; reported 2001-10-03 Severity: normal When I bring up URL:http://www.debian.org/sitemap I see a few titles appearing in the wrong lanuage: Kontak Sumbangan ke Software in the Public Interest Cari Arsip milis debian-user ... (more Arsip milis) Bug Kritikal -- System Information Debian Release: testing/unstable Architecture: sparc Kernel: Linux arroz 2.2.19 #1 Wed May 16 12:39:42 EDT 2001 sparc64 Locale: LANG=C, LC_CTYPE=C
Bug#99196: searching list archives doesn't work
Package: listarchives Version: N/A; reported 2001-05-29 Severity: important From URL:http://lists.debian.org/search.html, doing any search results in a page that tells me: You have to search for something! Bad search system! It seems really broken, in that list searching doesn't work at all, thus the severity of this bug. I tried different checkboxes on an off and different lists, no change. -- System Information Debian Release: testing/unstable Architecture: sparc Kernel: Linux arroz 2.2.18pre21 #1 Wed Nov 22 17:12:06 EST 2000 sparc64 Locale: LANG=C, LC_CTYPE=C
Re: slang, boot-floppies, and wide character support
Edmund GRIMLEY EVANS [EMAIL PROTECTED] writes: Please note that the patched slang1 is not binary compatible with the unpatched slang1. Making it binary compatible would be a horrible hack as the slang API exposes the internal representation of the contents of a screen cell as a 32-bit word. I have no idea whether the current patched slang is usable for Japanese; I have only used it for UTF-8. However, there's a good chance it might work for Japanese encodings. With glibc-2.2's wide character support it is possible to use the same code for UTF-8 as for Japanese character encodings. So it would nice if someone Japanese could try it or have a look. Its sounding more and more like we should probably use slang1-ja...? If we could patch slang1 so that it works with glibc-2.2 in UTF-8 or CJK encodings, but isn't binary-compatible with the unpatched slang1, would that be an acceptable solution for boot-floppies? Well, one thing you have to understand, whatever patching we do should be available in a Debian package. That is to say, I don't want to be dragging around diffs. I need these changes to propogate into the packages themselves. You seem to be avoiding the question here -- patch slang1, use slang1-ja, or make a new slang1-wide package with these patches? Do you have a check list of the programs that will be linked against slang in boot-floppies? No, sorry. I don't know what's happening about slang2, but I assume it won't be ready in time for Woody. (There are parts of the slang API which I think should be redesigned to cope better with combining characters - needed in Thai, for example. We really need John Davis to contribute to updating the API for slang2.) I would presume it won't be ready. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onshored.com/
slang, boot-floppies, and wide character support
We need wide character support in slang for the boot-floppies so that
the install program can display wide characters, such as Japanese or
Chinese (Big5 *and* GB2312 encoding).
I have a patch from the boot-floppies archives to give slang wide
character support. I've attached that patch.
I need to know if this patch is still needed (or alternatively, if I
should use slang1-ja instead), and if so, we need to file a bug
against the appropriate package to apply this. Actually the patch is
against 1.4.0 rather than the newest 1.4.4, but it should probably
adapt pretty easily.
Any help, advice, bug filing, etc., would be appreciated. Without
this, I cannot ship internationalized boot-floppies in Woody.
--
.Adam Di [EMAIL PROTECTED]URL:http://www.onshored.com/
Index: src/slang.h
===
RCS file: /usr/local/cvsroot/projects/slang14/src/slang.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- src/slang.h 2000/01/09 19:38:31 1.1.1.1
+++ src/slang.h 2000/03/18 15:17:20 1.2
@@ -1213,10 +1213,11 @@
extern int SLtt_Msdos_Cheap_Video;
#endif
-typedef unsigned short SLsmg_Char_Type;
-#define SLSMG_EXTRACT_CHAR(x) ((x) 0xFF)
-#define SLSMG_EXTRACT_COLOR(x) (((x)8)0xFF)
-#define SLSMG_BUILD_CHAR(ch,color) (((SLsmg_Char_Type)(unsigned char)(ch))|((color)8))
+typedef int SLsmg_Char_Type;
+#define SLSMG_EXTRACT_CHAR(x) ((x) 0xFF)
+#define SLSMG_EXTRACT_COLOR(x) (((x)24)0xFF)
+#define SLSMG_BUILD_CHAR(ch,color) (((SLsmg_Char_Type)(wchar_t)(ch))|((color)24))
+#define SLSMG_NOCHAR 1
extern int SLtt_flush_output (void);
extern void SLtt_set_scroll_region(int, int);
@@ -1301,7 +1302,7 @@
/*{{{ SLsmg Screen Management Functions */
-extern void SLsmg_fill_region (int, int, unsigned int, unsigned int, unsigned char);
+extern void SLsmg_fill_region (int, int, unsigned int, unsigned int, wchar_t);
extern void SLsmg_set_char_set (int);
#ifndef IBMPC_SYSTEM
extern int SLsmg_Scroll_Hash_Border;
@@ -1318,8 +1319,9 @@
extern void SLsmg_vprintf (char *, va_list);
extern void SLsmg_write_string (char *);
extern void SLsmg_write_nstring (char *, unsigned int);
-extern void SLsmg_write_char (char);
+extern void SLsmg_write_char (wchar_t);
extern void SLsmg_write_nchars (char *, unsigned int);
+extern void SLsmg_write_nwchars (wchar_t *, unsigned int);
extern void SLsmg_write_wrapped_string (char *, int, int, unsigned int, unsigned int, int);
extern void SLsmg_cls (void);
extern void SLsmg_refresh (void);
Index: src/slcurses.c
===
RCS file: /usr/local/cvsroot/projects/slang14/src/slcurses.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- src/slcurses.c 2000/01/09 19:38:32 1.1.1.1
+++ src/slcurses.c 2000/03/18 15:18:04 1.2
@@ -452,10 +452,11 @@
return 0;
}
-int SLcurses_waddch (SLcurses_Window_Type *win, SLtt_Char_Type attr)
+static int SLcurses_waddch1 (SLcurses_Window_Type *win,
+ wchar_t ch, int color)
{
- SLsmg_Char_Type *b, ch;
- SLsmg_Char_Type color;
+ SLsmg_Char_Type *b, *bmin, *bmax, *c;
+ int k;
if (win == NULL) return -1;
@@ -468,21 +469,6 @@
win-modified = 1;
- ch = SLSMG_EXTRACT_CHAR(attr);
-
- if (attr == ch)
- color = win-color;
- else
- {
- /* hack to pick up the default color for graphics chars */
- if (((attr A_COLOR) == 0) ((attr A_ALTCHARSET) != 0))
- {
- /* FIXME: priority=medium: Use SLSMG_?? instead of */
- attr |= win-color 8;
- }
- color = map_attr_to_object (attr);
- }
-
if (ch ' ')
{
if (ch == '\n')
@@ -508,17 +494,69 @@
/* HACK HACK */
if (ch == '\t') ch = ' ';
}
+
+ k = wcwidth(ch);
+
+ if (!k)
+ return 0; /* ignore combining characters for now */
- if (win-_curx = win-ncols)
+ if (k win-ncols)
+ return 0; /* character wider than window */
+
+ if (win-_curx + k win-ncols) {
+ if (win-_curx win-ncols)
+ SLcurses_wclrtoeol(win);
do_newline (win);
+ }
+
+ bmin = win-lines[win-_cury];
+ b = bmin + win-_curx;
+ bmax = bmin + win-ncols;
+
+ /* Remove overwritten chars to left */
+ if (*b == SLSMG_NOCHAR) {
+ for (c = b - 1; c = bmin *c == SLSMG_NOCHAR; c--)
+ *c = SLSMG_BUILD_CHAR(' ',SLSMG_EXTRACT_COLOR(*c));
+ if (c = bmin)
+ *c = SLSMG_BUILD_CHAR(' ',SLSMG_EXTRACT_COLOR(*c));
+ }
- b = win-lines[win-_cury] + win-_curx;
*b = SLSMG_BUILD_CHAR(ch,color);
- win-_curx++;
+ win-_curx += k;
+ while (--k 0)
+ *++b = SLSMG_NOCHAR;
+
+ /* Remove overwritten chars to right */
+ for (c = b + 1; c bmax *c == SLSMG_NOCHAR; c++)
+ *c = SLSMG_BUILD_CHAR(' ',SLSMG_EXTRACT_COLOR(*c));
return 0;
}
+int SLcurses_waddch (SLcurses_Window_Type *win, SLtt_Char_Type attr)
+{
+ SLsmg_Char_Type ch, color;
+
+ if (win == NULL) return -1;
+
+ ch = SLSMG_EXTRACT_CHAR(attr);
+
+ if (attr == ch)
+
Re: [paul@miraclefish.com: Missing page on debian.org?]
Josip Rodin [EMAIL PROTECTED] writes: http://www.debian.org/releases/2.2/i386/cfdisk.txt is blank (and referenced as required reading for 1st time installers:( The problem was using a sparc util-linux which doens't have that file. Fixed. I've updated www-master with a new version. Could someone please check that, espcially the internationalized PDFs and such? I built this one on klecker rather than my rather slow home box, so I'm not sure if it's kosher, really. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
new install manual/release notes propogated to master
I've uploaded updated Release Notes and Installation Manual for Potato to master.d.o. The main feature here is updates, especially in the French, Croatian, Polish, and Czech translations. I've had to disable the Russian PDF since it won't run for me anymore. I'd appreciate any testing of bad links especially on the English translation. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: stop sending spam
Marcin Owsiany [EMAIL PROTECTED] writes: http://bugs.debian.org/spam revealed that you seem to be the only person who knows of such method of reporting spam :-) Well, look at archived/closed bugs. Other people have used this. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: potato release notes missing
Josip Rodin [EMAIL PROTECTED] writes:
On Fri, Aug 18, 2000 at 04:27:14PM -0400, Adam Di Carlo wrote:
I disagree, it's useful, having directories without index.html is bad.
I deny it is actually useful. All of its information is more
completely and clearly stated at
http://www.debian.org/releases/potato/index.*.html.
That page references ${arch}/. If we remove that link, then we could remove
the ${arch}/index.html files, too... nothing else links there AFAICT.
No, it doesn't. It references, e.g.,
http://www.debian.org/releases/stable/sparc/release-notes/ and
http://www.debian.org/releases/stable/sparc/install
--
.Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Bad links in the install documents on the website
James A. Treacy [EMAIL PROTECTED] writes: As one of the webmasters for the Debian web site, I run a urlchecker over the site. There are a lot of broken links in the install documentation. It is not a priority to fix the broken links for previous releases, but the ones for potato should be fixed before the release. I've checked the English documentation (with checkbot) and there are no bad links on the updated stuff. Which is getting pushed up to master right now. I cannot be responsible for the translation lags of the porters or bad links in their documents. It's just not feasible. Sorry. BTW, the urlchecker has many problems and a new python script will be used after www.d.o is upgraded to potato. If you find a listed link is valid, just blame the urlchecker. :) I use checkbotworks fine. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Help fix bad links on the web site
Josip Rodin [EMAIL PROTECTED] writes: Actually, there's a problem with the textual files. There are no release-notes.*.txt files for languages other than English on master under /org/www.debian.org/debian.org/releases/slink, for some reason. The English ones were placed in a different location that a href's use, even. Adam, can you build them? I didn't find any makefiles in source/, and the build system seems to differ from the current one, so I'm wary, I don't want to break anything. Hmm Just the slink text files for non-English? I can probably do that. I dont' think building this from a potato box would hurt things. We'll see. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Bug#61702: german installation instrauctions not for sparc but x86
Ingo Saitz [EMAIL PROTECTED] writes: The german instructions on http://www.debian.org/releases/slink/#new-inst always point to installation instructions for x86 architecture, even if you select another architecture. Um, yes, well, that's because the German translation is old and faulty. Should I ruin the nice elegance of that table by removing German from the list and adding it below, i386 only? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: [Adam Di Carlo adam@onshore.com] [RFC] DDP and www.debian.org merger
Umm.. I know this is not that much integrated into wml but.. ¿have you looked at the perl script made by Paolo Molaro, and modified by Christophe Le Bars and myself? (the spanish version is in w.d.o/international/spanish). The idea of this is to have a Perl database (using hash arrays gives a lot of possible uses) that has an entry for each documents. It is quite powerful and Chris and me use it to keep track of translations. That way you can do things like : PERL do 'ltcp.pl'; update_db_format(); dump_html(0); /PERL Which dumps all documents marked as 'unavailable' (0). Of course this can be cleaned up a bit and made more 'developer-friendly' :) This sounds like what we're looking for. .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: [Adam Di Carlo adam@onshore.com] [RFC] DDP and www.debian.org merger
Josip Rodin [EMAIL PROTECTED] writes: The index page for DDP documents needs to be implemented with a bit of WML magic, with .wml and .wmh files. From what I managed to observe in the last half an hour or so, all we need is some modification of webwml/english/template/debian/install_manual.wml to something less specific to install manuals etc, and better adjusted for this purpose, and a few lines of WML code to invoke the functions which generate the page. Any comments or even better concrete help would be highly appreciated :) I suggest rather a set of metadata files; these files can be the basis for a little sort of metadata database, so we could say: make-doc-index state=released to get an nice HTML index of the released documents, or make-doc-index state=in-progress to see rough documents which aren't ready yet. The metadata files would include a title, author, relative URL, release state, package if any it appears in. Um... maybe other data too. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: `boot-floppies' documentation naming conventions?
James A. Treacy [EMAIL PROTECTED] writes: I'll try pointing the urlchecker at http://www.debian.org/releases/potato and see what happens. Oh, I don't have the documentation up there yet. I was asking more about the slink stuff. You were saying you'd go thru that ... It would help me not to have to go back and fix that stuff up but I can if I need to. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: More about 'releases'
James A. Treacy [EMAIL PROTECTED] writes: You are speaking specifically of the releases pages. That involves only the boot floppies people. I was being more general. There are docs, such as the FAQ, which we have on the web. We receive complaints about the docs and sending them to debian-doc never gets a response(*). We need a better method of communicating with the other groups that create content for the web pages. One solution would be if we had access to the source so we could simply fix problems ourselves. (*)Someone on the doc mailing list may claim they haven't seen any reports of bad links in the last year. That's simply because I stopped sending them. FYI, I sent a proposal a *long* time ago about better integration between the DDP and the debian Web pages. I can track this down if someone wants a copy, or resend. I am the current DDP leader but as I'm also the boot-floppies leader, I shan't really have time to get stuff done until after potato release -- Joey Hess will be taking over as boot-floppies leader at that point. Regarding maint of the release/... area, I do not mind at all if folks make corrections and such. The install manual and release notes, however, should not be correct in place as the source for those are not the Debian Web CVS area but rather the boot-floppies CVS area, so if you wanna work on that stuff, work out of the boot-floppies CVS. Hope this clarifies -- sorry for the non-responsiveness. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
[Adam Di Carlo adam@onshore.com] [RFC] DDP and www.debian.org merger
Here's a reposting of my thoughts regarding smoother DDP/www.debian.org integration. I am currently soliciting volunteers who know SGML/CVS/Make/WML to help with this integration. ---BeginMessage--- The following is my plan on why and how to merge the DDP area with www.debian.org, specifically, the Debian WML CVS area. Comments are appreciated. Overview: * merge DDP web pages with Debian WML CVS area, devel/ddp * retain existing manual sources in DDP CVS area * setup autobuild of DDP working copies to devel/ddp/working-copies Rationale: * promote DDP web pages to standard www.debian.org makes the DDP less of a marginalized splinter project * exploit www.debian.org mirrors * exploit current translation efforts on web pages * use WML in conjunction with small doc description files to produce a list of manuals and their locations which is much easier to maintain Description: The DDP Web pages are currently maintained from the DDP CVS area; they can be found at the web at http://www.debian.org/~elphick/ddp/. The DDP CVS area currently has the following structure: ddp/ webpages/ -- DDP web materials manuals.sgml/ -- Makefile -- top level Makefile developers-reference/ -- document module, in debiandoc-sgml dictionary/ intro-i18n/ ... * DDP Web Pages The function of the DDP web pages are to facilitate communication between Debian documenters. It tracks status of manuals which are released, being written, and tracks proposals for new manuals. It describes how to access the DDP CVS area, policies and guidelines for documenters. Working versions of manuals are presented. Basically -- a clearing-house of information for Debian documenters. Essentially, what I propose to do is eliminate ddp/webpages/* and merge that into wml/english/devel/ddp/ . Making this move, I will create small language neutral document.wmh files which will contain status information which can be shared across translated languages. **PROPOSED LOCATION OF THESE FILES REQUESTED FROM Debina WML GURUS** This will make the status tracking aspect of the web pages much more maintable, eliminating the treble-keying of manuals we currently have: [EMAIL PROTECTED]:webpages grep Developer's Reference *.html index.html: lia href=manuals.html#devrefDebian Developer's Reference/a manuals.html: lia href=#devrefDebian Developer's Reference/a/li manuals.html: name=devrefDebian Developer's Reference/a/h2 Disadvantage: disjunction between DDP and WML CVS areas; documenters able to maintain manuals not able to update status. Practically, however, this rarely happens. * DDP Working Copies Oliver, the past DDP leader, has his own cron-driven autobuilder scripts which produce the HTML version of the manuals from their DebianDoc-SGML sources. The top-level Makefile is very modular; all subdirs recognize a special 'publish' target which builds HTML and installs it according to the PUBLISHDIR target. This system works very well; thus I propose to retain it. I would move the autobuilder to master.debian.org (where www.debian.org is mirrored from) and run a nightly 'cvs update -d' and 'make PUBLISHDIR=/org/www.debian.org/debian.org/devel/ddp/working-copies publish' (basically just Olly's modified cron script). The cron script is run from a checked out copy. Since CVS now support multiple CVSROOTs in one tree, I could also check out non-DDP CVS modules such as Debian Policy and automatically publish that as well. The benefits of this system is basically easy-to-access source and built versions of unreleased manuals. * Official Versions of Manuals I do *not* propose to autobuild to official location on www.debian.org, such as doc/ . This is definately doable, the only problem is release management -- distinguishing between working copies and released copies. The only way I can think of to do this automatically would require the use of CVS tagging (such as cvs-buildpackage style) and building from tagged CVS source. Even so, there is a risk of divergance against the packaged manuals. [ Other archive administrators (Guy) have proposed that dinstall be modified to recognize certain 'ByHand' entries automatically and do the right thing. ] However, that area *could* be rationalized in its structure to mirror the devel/ddp/working-copies structure. Moreover, the document.wmh files could be used to provide a managable list of documentation. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ ---End Message--- -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Available Documentation in the Debian's WWW/FTP mirrors/CDs
Javier Fdz-Sanguino Pen~a [EMAIL PROTECTED] writes: Well.. I could but since the last I have checked there has been no talk whatsoever since last year on this topic. Debian-doc is not such a 'light' Mailing list. I have, however, gone through all the information of the last two years and gathered some ideas on how it is currently, as James said: a big mess. Neither the DDP pages are up to date nor the work that people in the mailing list said it would be done has been done. Are you volunteering? The tough work (deciding the route to take) has been completed. See my recent post with the road map. I simply won't have time to do this probably for another month. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: `boot-floppies' documentation naming conventions?
Adam Di Carlo [EMAIL PROTECTED] writes: The current state is that translations are relying on the existance of www.es.debian.org and www.br.debian.org, both of which are not very reliable. In fact, neither is currently accessable. This isn't very robust. Well, lets just have it all point, for web pages, to www.debian.org. Go ahead and change that in slink, I'll hack it for potato. For downloads, should we point to http.us.debian.org or is there something better? James, if you don't have time to fix the broken links, could you at least send the list of broken links to the debian-boot mail list? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Bug#61107: releases/ symlink changes needed
Package: www.debian.org Version: 25-Mar-2000 Severity: important I don't have permissions, so the following commands should be run in /debian2/web/debian.org/releases: rm unstable # old symlink ln -s potato frozen ln -s potato 2.2 ln -s woody unstable Corresponding changes has already been made to releases/index.wml and the Makefile. Thanks. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: [Adam Di Carlo adam@onshore.com] [RFC] DDP and www.debian.org merger
Since we've talked about this in IRC, I assume I've answered your questions. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: `boot-floppies' documentation naming conventions?
Where is the install doc source for slink? I'd like to get rid of as many of the broken links in it as possible. If the install docs aren't going to be updated ever again, I could simply make the changes in the current .html. Don't do that. Oh, Ick. Use the included CVS instructions. Use the slink branch of CVS. In looking through the doc source for potato, I notice that www-debian-org can be replaced in each language by their choice of site. This is not a good idea since it assumes that people speaking that language have good connectivity to that site. For example, I know a lot of people in Quebec that would not like being pushed over to www.fr.debian.org simply because they chose French as the default language for their browser. Seems like a decent heuristic to me. Of course, nothing is certain. If it is necessary to use an absolute URL for the Debian site, It is... Users may have the documentation on a CD or from the web. Links off the document onto the www.debian.org site must be absolute. For potato, it's pretty easy to set some vars different for the version which is destined for www.debian.org. either point to www.debian.org or list all the official mirrors. All links to documents that can be found locally should be relative. Once a user chooses a site, they should be able to stay on that site. Uh... As for listing the official mirrors, I'd rather not. It would be nice if there was a CGI where I could point to a special URL and it would list all possible mirrors and give the user a cookie or something so they use that in the future. Like TUG or perl.org does. But I can't count on such counter-factual scenarios. I have to deal with reality as it is. I wouldn't put too much structural effort like this into slink but rather focus on potato. .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: `boot-floppies' documentation naming conventions?
The current state is that translations are relying on the existance of www.es.debian.org and www.br.debian.org, both of which are not very reliable. In fact, neither is currently accessable. This isn't very robust. Well, lets just have it all point, for web pages, to www.debian.org. Go ahead and change that in slink, I'll hack it for potato. For downloads, should we point to http.us.debian.org or is there something better? .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: `boot-floppies' documentation naming conventions?
James A. Treacy [EMAIL PROTECTED] writes:
On a related note, is boot-floppies responsible for the files in
releases/{slink,potato}/? There are a number of problems with links there
and I need to know who to forward problems/bugs to (and there are currently
a LOT of broken links). If I had access to the source, I'd even be willing
to fix problems with the links.
Yes, I did 'make all-lang-arch-docs' to populate the slink
documentation. The rest is in WML.
I haven't had a chance to populate the potato data yet. So any broken
links there are purely WML problems.
Oh, and for slink, I copies the boot-floppies materials into the
webroot for mirroring, which was a quick-hack decision but nasty
nasty. For potato, at least theoretically, we just set the
boot-floppies archive URL, say, to
http.us.debian.org/dists/potato/main/ or something, and then we don't
have to have all those megs and megs of data in place for downloading
off the web to work.
Are you volunteering to help with the getting the potato documentation
fully web ready? That would be great. I can give you CVs
instructions.
--
.Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: `boot-floppies' documentation naming conventions?
Ah. Finnally someone said something concrete about this. :) So all the boot-floppies does to the web pages is generate the installation manual, dselect tutorial, and the release notes, and put it in the right place. Right? Right. .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Raul's banners etc
[Thought I had sent this before] Someone might take a look at URL:http://devel.onShore.com/gnu_art/ and see if we wanna grab some of this for the logos page or for use as banners. Also, Raul was asking me what license he should put the images under. Is GPL appropriate? Or is just Public Domain the best for this stuff? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Bug#50249: Wrong logo images
Philip Hands [EMAIL PROTECTED] writes: The version at the URL I mentioned: http://www.hands.com/~phil/debian/logo/ has been tidied up, without actually affecting the postscript code. Raul should probably be made aware of this. Ok -- I've made him aware (forwarded his message). Things have been a bit hectic at onShore but hopefully we'll have the logos fixed soon. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Debian-List HOWTO
Jason Gunthorpe [EMAIL PROTECTED] writes: Is there any place on the web site for documents like this? I know we have a couple already and we really should have more (like something about GnuPG) I have proposed an integration of the DDP (which collects status and pointers to Debian documentation) with the website. No comments nor volunteers thus far. I believe that integration would make it easier to present, maintain, and package the information. I include that message again. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/ The following is my plan on why and how to merge the DDP area with www.debian.org, specifically, the Debian WML CVS area. Comments are appreciated. Overview: * merge DDP web pages with Debian WML CVS area, devel/ddp * retain existing manual sources in DDP CVS area * setup autobuild of DDP working copies to devel/ddp/working-copies Rationale: * promote DDP web pages to standard www.debian.org makes the DDP less of a marginalized splinter project * exploit www.debian.org mirrors * exploit current translation efforts on web pages * use WML in conjunction with small doc description files to produce a list of manuals and their locations which is much easier to maintain Description: The DDP Web pages are currently maintained from the DDP CVS area; they can be found at the web at http://www.debian.org/~elphick/ddp/. The DDP CVS area currently has the following structure: ddp/ webpages/ -- DDP web materials manuals.sgml/ -- Makefile -- top level Makefile developers-reference/ -- document module, in debiandoc-sgml dictionary/ intro-i18n/ ... * DDP Web Pages The function of the DDP web pages are to facilitate communication between Debian documenters. It tracks status of manuals which are released, being written, and tracks proposals for new manuals. It describes how to access the DDP CVS area, policies and guidelines for documenters. Working versions of manuals are presented. Basically -- a clearing-house of information for Debian documenters. Essentially, what I propose to do is eliminate ddp/webpages/* and merge that into wml/english/devel/ddp/ . Making this move, I will create small language neutral document.wmh files which will contain status information which can be shared across translated languages. **PROPOSED LOCATION OF THESE FILES REQUESTED FROM Debina WML GURUS** This will make the status tracking aspect of the web pages much more maintable, eliminating the treble-keying of manuals we currently have: [EMAIL PROTECTED]:webpages grep Developer's Reference *.html index.html: lia href=manuals.html#devrefDebian Developer's Reference/a manuals.html: lia href=#devrefDebian Developer's Reference/a/li manuals.html: name=devrefDebian Developer's Reference/a/h2 Disadvantage: disjunction between DDP and WML CVS areas; documenters able to maintain manuals not able to update status. Practically, however, this rarely happens. * DDP Working Copies Oliver, the past DDP leader, has his own cron-driven autobuilder scripts which produce the HTML version of the manuals from their DebianDoc-SGML sources. The top-level Makefile is very modular; all subdirs recognize a special 'publish' target which builds HTML and installs it according to the PUBLISHDIR target. This system works very well; thus I propose to retain it. I would move the autobuilder to master.debian.org (where www.debian.org is mirrored from) and run a nightly 'cvs update -d' and 'make PUBLISHDIR=/org/www.debian.org/debian.org/devel/ddp/working-copies publish' (basically just Olly's modified cron script). The cron script is run from a checked out copy. Since CVS now support multiple CVSROOTs in one tree, I could also check out non-DDP CVS modules such as Debian Policy and automatically publish that as well. The benefits of this system is basically easy-to-access source and built versions of unreleased manuals. * Official Versions of Manuals I do *not* propose to autobuild to official location on www.debian.org, such as doc/ . This is definately doable, the only problem is release management -- distinguishing between working copies and released copies. The only way I can think of to do this automatically would require the use of CVS tagging (such as cvs-buildpackage style) and building from tagged CVS source. Even so, there is a risk of divergance against the packaged manuals. [ Other archive administrators (Guy) have proposed that dinstall be modified to recognize certain 'ByHand' entries automatically and do the right thing. ] However, that area *could* be rationalized in its structure to mirror the devel/ddp/working-copies structure. Moreover, the document.wmh files could be used to provide a managable list of documentation. -- .Adam Di [EMAIL
Re: Suggestion: Man Pages on Web Install Disks
Martin Schulze [EMAIL PROTECTED] writes: Goswin Brederlow wrote: Ken Hendrickson [EMAIL PROTECTED] writes: Suggestions for Improvement: * Put complete man pages for every package on www.Debian.org. o (Note that OpenBSD does this.) * Put complete /usr/doc and /usr/info documentation for every package on www.Debian.org, with the appropriate HTML cgi readers. Can you consider this? Should be possible in connection with packages. debian.org, or not? Hmmm I don't think it's a bad idea, but I don't see why we could just have a separate docs.debian.org for this, perhaps using dwww or dhelp. Delegate this out to someone who can keep a stable box going. That way it's not a ton and ton of work for webmasters. I don't see why we would also need a commitment to serve up unstable docs as well. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
search engine to web pages? Re: no link to the y2k page?
This apparently got buried in the thread but it's important... Wichert Akkerman [EMAIL PROTECTED] writes: On a related note: Cistron (the people hosting www.nl.debian.org) appears to be willing to setup a searchengine for the website. Is there any interest in this? I think this would be great... Are there any reservations? If so, what are they? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
[RFC] DDP and www.debian.org merger
The following is my plan on why and how to merge the DDP area with www.debian.org, specifically, the Debian WML CVS area. Comments are appreciated. Overview: * merge DDP web pages with Debian WML CVS area, devel/ddp * retain existing manual sources in DDP CVS area * setup autobuild of DDP working copies to devel/ddp/working-copies Rationale: * promote DDP web pages to standard www.debian.org makes the DDP less of a marginalized splinter project * exploit www.debian.org mirrors * exploit current translation efforts on web pages * use WML in conjunction with small doc description files to produce a list of manuals and their locations which is much easier to maintain Description: The DDP Web pages are currently maintained from the DDP CVS area; they can be found at the web at http://www.debian.org/~elphick/ddp/. The DDP CVS area currently has the following structure: ddp/ webpages/ -- DDP web materials manuals.sgml/ -- Makefile -- top level Makefile developers-reference/ -- document module, in debiandoc-sgml dictionary/ intro-i18n/ ... * DDP Web Pages The function of the DDP web pages are to facilitate communication between Debian documenters. It tracks status of manuals which are released, being written, and tracks proposals for new manuals. It describes how to access the DDP CVS area, policies and guidelines for documenters. Working versions of manuals are presented. Basically -- a clearing-house of information for Debian documenters. Essentially, what I propose to do is eliminate ddp/webpages/* and merge that into wml/english/devel/ddp/ . Making this move, I will create small language neutral document.wmh files which will contain status information which can be shared across translated languages. **PROPOSED LOCATION OF THESE FILES REQUESTED FROM Debina WML GURUS** This will make the status tracking aspect of the web pages much more maintable, eliminating the treble-keying of manuals we currently have: [EMAIL PROTECTED]:webpages grep Developer's Reference *.html index.html: lia href=manuals.html#devrefDebian Developer's Reference/a manuals.html: lia href=#devrefDebian Developer's Reference/a/li manuals.html: name=devrefDebian Developer's Reference/a/h2 Disadvantage: disjunction between DDP and WML CVS areas; documenters able to maintain manuals not able to update status. Practically, however, this rarely happens. * DDP Working Copies Oliver, the past DDP leader, has his own cron-driven autobuilder scripts which produce the HTML version of the manuals from their DebianDoc-SGML sources. The top-level Makefile is very modular; all subdirs recognize a special 'publish' target which builds HTML and installs it according to the PUBLISHDIR target. This system works very well; thus I propose to retain it. I would move the autobuilder to master.debian.org (where www.debian.org is mirrored from) and run a nightly 'cvs update -d' and 'make PUBLISHDIR=/org/www.debian.org/debian.org/devel/ddp/working-copies publish' (basically just Olly's modified cron script). The cron script is run from a checked out copy. Since CVS now support multiple CVSROOTs in one tree, I could also check out non-DDP CVS modules such as Debian Policy and automatically publish that as well. The benefits of this system is basically easy-to-access source and built versions of unreleased manuals. * Official Versions of Manuals I do *not* propose to autobuild to official location on www.debian.org, such as doc/ . This is definately doable, the only problem is release management -- distinguishing between working copies and released copies. The only way I can think of to do this automatically would require the use of CVS tagging (such as cvs-buildpackage style) and building from tagged CVS source. Even so, there is a risk of divergance against the packaged manuals. [ Other archive administrators (Guy) have proposed that dinstall be modified to recognize certain 'ByHand' entries automatically and do the right thing. ] However, that area *could* be rationalized in its structure to mirror the devel/ddp/working-copies structure. Moreover, the document.wmh files could be used to provide a managable list of documentation. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Bug#46799: add makedev to notes on running slink with kernel 2.2.x
[EMAIL PROTECTED] (Raj Manandhar) writes: So the bottom line is: one needs a newer makedev. The current stable one works, for example. Perhaps there are similar problems for other packages that made it onto older slink CDs, too, so it might be a good idea to add the FTP site to /etc/apt/sources.list and do an `apt-get update; apt-get upgrade' before trying the 2.2.x kernels. This doesn't help people without Internet access, though. Yes, but the running slink with kernel 2.2 page *assumes* you are running a fully up-to-date slink. So mentioning 'makedev' explicitly doesn't make sense if it's already fixed in 2.1r3. All you are saying AFAICT is that you want to make sure you're all the way up-to-date. I could add a para to this effect at the top. Would that be sufficient? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: web site license
James A. Treacy [EMAIL PROTECTED] writes: On Wed, Sep 29, 1999 at 02:40:09PM -0700, Joey Hess wrote: I'd rather we took advantage of DFSG point #4 and added something like: You may change this document, but all derived works must state that they are not part of the Debian web site. I think this has basically the same effect, while giving people more freedom to derive things from the web site. Is everyone happy with what Joey has written? Sounds good to me, but I'm not a lawyer. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Help fix bad links in the web pages
It would be nice if there was a stable, unchanging link which always showed current bad links, i.e., redone nightly right after the WML update. Is this possible? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Bad links in the install docs
James A. Treacy [EMAIL PROTECTED] writes: There are a number of files missing from the releases/ directory which are causing links to fail. The list which follows is quite long, but it looks like a lot of them are related so a few changes should get rid of most of them: Yes, it's a comedy of errors. Sorry. Looking into http://localhost/releases/slink/ http://localhost/releases/slink/sparc/release-notes/index.cz.txt : error 404 Not Found The two letter country code for Czech is cs. Duh. Fixed in languages.wml. http://localhost/releases/slink/sparc/release-notes/index.en.pdf : error 404 Not Found We don't make PDFs for the release notes. Duh. Looking into http://localhost/releases/slink/i386/reports http://insite.verisim.com/search/debian/simple : error 500 Can't connect to insite.verisim.com:80 (Bad hostname 'insite.verisim.com') Huh.. That's John Lapreve's (sp?) pages. Looking into http://localhost/releases/slink/running-kernel-2.2 http://www.debian.org/Packages/unstable/net/dhcp-client-beta.html : error 404 Not Found http://lore.ece.utexas.edu/~bgrayson/xosview.html : error 500 Can't connect to lore.ece.utexas.edu:80 (Connection refused) http://www.debian.org/Bugs/db/33/33795.html : error 404 Not Found Ew, I'll fix. Looking into http://localhost/releases/slink/index.sv.html Bump this to the translator for Swedish. Looking into http://localhost/releases/slink/sparc/ch-install-methods.en.html http://localhost/releases/slink/sparc/base2_1.tgz : error 404 Not Found Feh. Fixed on master. We gotta have a better way -- probably redirect to http.us.debian.org or some such? Looking into http://localhost/releases/slink/sparc/ch-administrivia.hr.html http://www.geog.ubc.ca/s_linux/howto/netboot.html : error 404 Not Found ... These seem to be errors in the SGML itself. Will look into next week, perhaps. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: document matrix generation in releases/slink/
James A. Treacy [EMAIL PROTECTED] writes:
Any objection to the following change?
It simply makes sure that the files exist so we don't have
broken links.
Seems ok to me... go for it.
Thanks James.
+ @cur_dir = split('/', '$(WML_SRC_DIRNAME)');
+ $release = pop @cur_dir;
foreach $arch (keys %arches) {
$ctr++;
my $first = 1;
foreach $ext (keys %formats) {
+ # assume that an extension doesn't exist if there is no English
version.
+ # English-centric, but anyone got a better idea?
+ if (!-f $(HTMLDIR)/releases/$release/$arch/$file.en.$ext) {
+ next;
+ }
# alternate the row color
if ( $ctr % 2 ) {
print \ntr\n;
} else {
print \ntr bgcolor=\$altcolor\\n;
}
# only print the arch name on the first row
if ( $first == 1 ) {
print td align=\left\a href=\$arch/$file\ .
$arches{$arch} . /a/td\n;
$first = 0;
} else {
print tdnbsp;/td\n;
}
print td align=\left\ . $formats{$ext} . /td\n;
# permute over languages
print td;
foreach $lang (@langs) {
- print a href=\./$arch/$file. . $langs{$lang} . .$ext\;
- # sometimes the language name isn't properly defined yet
- my $workaroundlang = $trans{$CUR_ISO_LANG}{$lang};
- ( $workaroundlang = $lang ) =~ s/^(.)/\U$1/
- unless $workaroundlang;
- print $workaroundlang . /a \n;
+ $file_version = ./$arch/$file. . $langs{$lang} . .$ext;
+ if (-f $(HTMLDIR)/releases/$release/$file_version) {
+ # all languages should be defined in %trans. Add missing
entries
+ # in English if this is not the case
+ print a href=\$file_version\ .
$trans{$CUR_ISO_LANG}{$lang} . /a \n;
+ }
}
print /td;
print /tr\n;
}
Also, is there a reason that index is added to some of the directory links
in files under releases/? It is superfluous.
Yeah, that could be removed if its not necessary. But we don't want to add
releases/.en.html type links do we?
--
.Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: document matrix generation in releases/slink/
James A. Treacy [EMAIL PROTECTED] writes: On Fri, Sep 24, 1999 at 12:59:02PM -0400, Adam Di Carlo wrote: No offense, but slice sucks. Why? I dunno -- why use it when you could just switch on the current language in Perl itself? The code is Perl. Mixing two languages in this case is unnecessary and make the code difficult to understand and read. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: new developer's corner
Jason Gunthorpe [EMAIL PROTECTED] writes: It looks like we can move this over to db.debian.org where it will be much more usefull with quite broad search capabilities. Hopefully by next week. Does this have secure login yet? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: new developer's corner
James A. Treacy [EMAIL PROTECTED] writes: We can remove the link to the Japanese version of the policy manual as it can be (is?) linked from the Japanese version of the page. Of course, the policy manual should be available in multiple langs using content negotiation alongside the english version (I haven't checked, maybe it is). The debian-doc group could use some help along these lines. Yes... I agree. I wonder if the Debian Policy l10n'd versions are in CVS along with Policy itself? Hmm... I'll check that out. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
document matrix generation in releases/slink/
In www.debian.org/releases/slink/ you will now see a nice document
matrix. This lists all the translations and formats for the various
versions of the Install Manual.
The tables are dynamically generated by a little Perl procedure:
permute_as_matrix('install', 'english', 'croatian', 'czech', ..)
In order to implement this properly, I used wml::debian::languages.
However, I had to add the following languages:
$langs{'russian'} = 'ru';
$langs{'czech'} = 'cz';
As well, I use $trans{$CUR_ISO_LANG}{$lang}, although, again
I had to workaround in some cases where this array didn't have
entries I needed:
my $workaroundlang = $trans{$CUR_ISO_LANG}{$lang};
( $workaroundlang = $lang ) =~ s/^(.)/\U$1/
unless $workaroundlang;
I don't know if it's kosher for me to modify languages.wml instead of
working around this way.
I include below the permute_as_matrix() procedure. It is Install
Manual centric since it presupposes hashes %formats and %arches
defined. However, I could possibly generalize this. It might be
valuable as more and more non-WML stuff (i.e., SGML stuff) is
translated (i.e., developers-reference etc).
--
.Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
#
# emits an HTML table matrix:
# | arch | format | lang1, lang2, lang3 |
#
sub permute_as_matrix {
my($file, @langs) = @_;
my($ext, $arch, $lang);
my $altcolor = 'white';
my $ctr = 0;
foreach $arch (keys %arches) {
$ctr++;
my $first = 1;
foreach $ext (keys %formats) {
# alternate the row color
if ( $ctr % 2 ) {
print \ntr\n;
} else {
print \ntr bgcolor=\$altcolor\\n;
}
# only print the arch name on the first row
if ( $first == 1 ) {
print td align=\left\a href=\$arch/$file\ .
$arches{$arch} . /a/td\n;
$first = 0;
} else {
print tdnbsp;/td\n;
}
print td align=\left\ . $formats{$ext} . /td\n;
# permute over languages
print td;
foreach $lang (@langs) {
print a href=\./$arch/$file. . $langs{$lang} . .$ext\;
# sometimes the language name isn't properly defined yet
my $workaroundlang = $trans{$CUR_ISO_LANG}{$lang};
( $workaroundlang = $lang ) =~ s/^(.)/\U$1/
unless $workaroundlang;
print $workaroundlang . /a \n;
}
print /td;
print /tr\n;
}
}
}
Re: For the Abolishment of Ports
James A. Treacy [EMAIL PROTECTED] writes: Writing perl is not the problem. Ideally, all the 'ports' would be in sync so a single page could be used for every package. As it stands, there is too much version skew to allow this without making the pages overly large and complicated. Disagree? I do. Dependencies, for example, change between versions more frequently than you'd imagine. It turns out that you can't depend on any of the information on the page not changing between version, except the package name (if that changes, it gets a new page). This makes it really hard to design a nice clean page. Irrelevant. There is only one source package in the archive by definition. We should exploit this. The only possible missing material (lagged port) would be the .deb file. In this case, we have two possible alternatives: tell the user that it's not yet available on their platform, or else use a heuristic to find the newest version. There are 2 alternatives. One is to have separate pages for each port. This would use a lot of disk space and require significant bandwidth for the daily mirror updates. Icky. The second is to use dynamically generated pages. The problem with dynamically generated pages is that many parts of the world do not have very good connections to www.debian.org (or master for that matter which is where the cgi scripts would likely be located). Icky. I think there's a third alternative: Stick with static pages, but allow the user to select their platform (either via a switch or a cookie, even). For mature ports which were released, 90% or better of the binary packages are up-to-date. Source packages are in sync by definition. I don't see what the big problem is... -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
new logo announcement
Debian hasn't yet made any official announcement about the new logo. Nor has onShore (who paid for Raul's time to make the logo). We at least would like to make a press release about the new logo, and we were wonder if perhaps we could make a shared press release, or else if Debian would like to review onShore's press release before we make it public. I assume all the issues with the logo are settled, right? I also assume the primary logo which will get branded is the swirl, where as the official logo (the bottle) will be used as a stamp of approval and controlled by the group centrally somewhere, rather akin to a Debian certified stamp of approval. Right? Let me know your thoughts on this. I hope you don't think onShore's trying to exploit Debian here -- we're just very excited and pleased to be able to help out this way. Please retain the CC to the onShore folks and myself, since I'm on neither the publicity or WWW lists. If there already is someone working on the PR, I'd like to get in touch with them as well. Thanks! .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: bug while downloading 'linux' with netscape.
Jon Harris [EMAIL PROTECTED] writes: Hi there, Hi Jon. Sorry, I didn't read this for a while. I missed your message somehow. I just thought I'd inform you that the 'linux' file from the page: http://www.debian.org/releases/2.1/i386/ch-install-methods.en.html does not download correctly with Netscape Navigator under Windows 98/NT. Even holding down the shift key, netscape thinks the 'linux' file should be 'linux.html', and 2 extra bytes are added to the file which results in the install.bat failing reporting that the file is not a kernel image. Thanks for telling us. This is a web server configuration issue I think. Webmaster, do you have any thoughts? Is this something we need to try to fix in the documentation, i.e, link to a ftp file instead? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: link to devel/release_info
James == James A Treacy [EMAIL PROTECTED] writes: James The link to devel/release_notes has been deleted from the main James web page. devel/release_notes provides information that is James frequently requested; primarily what version of the kernel and James X are included in the next (or current if appropriate) release. Actually, that page is flawed for even this purpose: the kernel used is reported as 2.0.36. That is x86-specific and incorrect. For instance, for Debian/Sparc on the Sun4u architecture, you *have* to use 2.2.x (currently, 2.2.1). For m68k, they use 2.0.35. The X version is part of the release notes. I could easily add the default kernel version as well (I already have the data for all platforms). James Although I understand the reasoning behind removing the link, James as the person who answers most of the mail sent to webmaster, James I'm not happy it. Perhaps the information mentioned above can James be added to the release notes under releases/stable. Will do. Most of it is already there. Maybe I'll try to make it more prominent. James There really is a bigger issue here. How do users easily find James out what is (will be) available in current (future) releases? James The release-notes available with 2.1 answer most of the FAQs, James but not all. What document should be used for distributing James information on an upcoming release? Should this document James contain information on long term goals? (almost certainly yes) James Finally the clincher: who will maintain this page? I specifically added the release notes to the boot-floppies CVS area so the release team (if it's ever formed) can have easy access to it. Until then, Bob and I will maintain it. James I'd like to see something that is managed by the release James manager. They should have a grasp on both where Debian is and James where it is going. The release notes included with each release James can then be generated from the information on this page. I think it should be managed by the release *team*. The actual release manager (Guy or Brian, if he hasn't already left) will be too busy to much with this document and track all the platforms. I know the whole release team concept is still vapor, but still it's the only viable alternative I can see. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
