Re: Distribution
Bill Mitchell writes ("Re: Distribution"):
> I'd suggest DEVELOPMENT, or WORKING, or IN_PROGRESS, or somesuch
> rather than CURRENT if these are to be visible to user-downloaders.
>
> CURRENT is likely not to be taken as bleeding-edge-and-unfinished
> by user-downloaders.
Right. I think `development' vs. `released' is about the right
distinction.
I think capital letters are a bad thing, but others may disagree.
Ian Murdock writes ("Re: Distribution"):
>Date: Sun, 29 Oct 1995 01:21:48 -0700
>From: Bruce Perens <[EMAIL PROTECTED]>
>
>Rather than re-arrange the current released system, let's put the
>new organization in place for the "current" and "1.0" system, and
>leave debian-0.93 where it is now so we don't mess up the mirrors
>again. That'll give us freedom to move things around for a while.
>
> Agreed.
Bruce is right.
So, what we're left with, if you agree with my release strategy, is:
released -> debian-0.93
development -> debian-1.0
debian-0.93/binary [ bugfixes and urgent releases only ]
source
ms-dos
Packages -> binary/Packages
disks
debian-1.0/binary [ most new uploads get put here ]
source
ms-dos
Packages -> binary/Packages
disks
contrib/binary
source
ms-dos
Packages -> binary/Packages
non-free/binary
source
ms-dos
Packages -> binary/Packages
Packages-Master[ Union of released, contrib, non-free ]
tools/
doc/ [ Shouldn't we merge doc/, info/ and some
info/of project/ ? ]
kernel/
private/
experimental/ [ Other stuff only for special purposes ]
README.*
If we decide we need updates directories for people to go scouring if
they had a version from date X then each of released, development,
contrib and non-free needs an `updates' directory with names after the
last 6 quarters (say). New packages get moved into the most recent
one of those (and any duplicates from the older updates directories
removed) as well as into the `binary' directory.
Does this seem good to people ?
Ian.
Re: pre-inst and post-inst scripts that start and stop daemons
Bruce Perens writes ("Re: pre-inst and post-inst scripts that start and stop
daemons "):
> > However, I'm wondering whether a more elegant and simple solution
> > might just be for Bruce to run the cross-installation which a PATH
> > environment variable that ensures that the version of
> > start-stop-daemon it finds is a link to `true'.
>
> Clever. This is made somewhat more sloppy by the fact that the
> script is running in a "chroot" context (dpkg --root, remember), and thus
> I'd have to create the binary directory within the target filesystem.
Sort of true. dpkg doesn't do a chdir, though, so you can refer to
files relative to the current directory. For example,
ln -s /bin/true start-stop-daemon
PATH=:$PATH dpkg --root=...
Ian.
Bug#1779: unclutter - I need -noevents
Package: unclutter Version: 0.8-1 I need to run unclutter with the `-noevents' flag to stop it from causing my window manager (twm) from thinking that the current window has lost the focus and un-highlighting it. I suggest that this be documented (the current description of -noevents implies that it does something which seems to be roughly the opposite of the effect I'm seeing). No doubt this is some X nastiness. It might also be useful to change the default. These comments should probably go to the upstream author. I used to use a very old version of unclutter (0.4), which didn't need this option because it probably didn't have the code to send the offending events. Unfortunately that version was linked against libc.so.2.2.2 (!) which doesn't support DNS queries for hostname lookups ... Ian.
Re: package uploading probs
Bruce Perens writes ("Re: package uploading probs "):
> Regional upload directories make sense. What we really need is a script
> (a hack of the mirror program) to "mirror" all files from a remote system
> and remove the files from the remote once they have been copied sucessfully.
> If we can't do that immediately, we can at least establish the regional
> upload sites and let their local caretakers remove files as appropriate.
> Note that the upload directory should not be part of your Debian mirror
> lest we create a short circuit and blow the main fuse of the Internet :-) .
Right.
> Ian Jackson, can you provide one in Cambridge? Is there someone who can
> provide one in Germany? There are lots of other places that need them as
> well.
chiark.chu.cam.ac.uk:/debian/private/Incoming
Matt, can you mirror this somewhere ?
I have a script that one can run out of cron that uses rcp and rsh
md5sum to upload a file. That might be suitable for use in these
circumstances. Suppose we arrange for users to upload things to the
`local' Incoming, and then rename them into a `togo' or `ok'
directory. Then the script picks them up and rcp's them across,
deleting them a while later.
Hmm, I can do this. In the meantime, Matt, mirror that in a
directory.
Ian.
Re: package uploading probs
Regional upload directories make sense. What we really need is a script (a hack of the mirror program) to "mirror" all files from a remote system and remove the files from the remote once they have been copied sucessfully. If we can't do that immediately, we can at least establish the regional upload sites and let their local caretakers remove files as appropriate. Note that the upload directory should not be part of your Debian mirror lest we create a short circuit and blow the main fuse of the Internet :-) . Ian Jackson, can you provide one in Cambridge? Is there someone who can provide one in Germany? There are lots of other places that need them as well. Thanks Bruce
Re: package uploading probs
On Sun, 29 Oct 1995, Siggy Brentrup wrote: > I hate to follow-up to my own message, but it's only after it was out that I > got > this one in linux-announce: > Heh. Siggy I have both rdist and ssh already running on this ftp server. NOTE: this server doesn't run linux do to hardware contraints it runs FreeBSD. The problem with using rdist and ssh is that "ssh" has a restrictive copyright a I prefer not to use it for that reason. besides I don't like rdist :) (anyone have a Win95 copy I could reall use it) :) Matt
Bug#1777: Source not compiling properly?
Karl Ferguson writes: >Package: source >Version: 1.2.13-5 > >After installing the source package, makeconfigging it to my on needs and >compiling it, an error pops up while trying drivers/net/ppp.c: > >ppp.c: In function `ppp_first_time': >ppp.c:442: warning: assignment from incompatable pointer type >ppp.c:446: warning: assignment from incompatable pointer tpye > > >Now, it wont quit at the point - it goes on to finish. But when booting the >kernel I get this error: > >unregister_netdev: device 'ppp0' unlinked >unregister_netdev: device 'ppp1' unlinked >unregister_netdev: device 'ppp2' unlinked >unregister_netdev: device 'ppp3' unlinked This one comes up in linux-ppp eveey week, they're not errors. pppd-2.2 allocates interfaces dynamically. ~$ cat /proc/net/dev Inter-| Receive | Transmit face |packets errs drop fifo frame|packets errs drop fifo colls carrier lo: 0000014050000 00 eth0:12650520000 1216121000120 dummy0: No statistics available. You won't see this message if it doesn't work :) BTW: should i close the bug report or wait for pppd's maintainer to do it? -- Siggy (the middle S.)
Bug#1777: Source not compiling properly?
Package: source Version: 1.2.13-5 After installing the source package, makeconfigging it to my on needs and compiling it, an error pops up while trying drivers/net/ppp.c: ppp.c: In function `ppp_first_time': ppp.c:442: warning: assignment from incompatable pointer type ppp.c:446: warning: assignment from incompatable pointer tpye Now, it wont quit at the point - it goes on to finish. But when booting the kernel I get this error: unregister_netdev: device 'ppp0' unlinked unregister_netdev: device 'ppp1' unlinked unregister_netdev: device 'ppp2' unlinked unregister_netdev: device 'ppp3' unlinked Of course, once the box has booted I login and cat /proc/net/dev - and there are no pppx's there - soloutions? ...Karl -- | PO Box 828 Office: (09)316-3036 Fax: (09)381-3909 |OWER INTERNET SERVICES Canning Bridge After Hours: 015-779-828 WA, 6153 Sales Support: [EMAIL PROTECTED] Internet Service Providers and Networking Solutions
Bug#1778: Zombies from Cern-Httpd (solved)
Package: cern-httpd Version: 3.0-4 There is an error in the Signal handling of the cern-httpd, which makes zombies hang around, especially on heavy loaded WWW Server. The following Patch may solve this: --- WWW/All/linux/Makefile.include.org Sun Oct 29 07:15:44 1995 +++ WWW/All/linux/Makefile.include Sun Oct 29 07:16:32 1995 @@ -9,7 +9,7 @@ # -DLINUX_FSSTND makes the default log file /var/run/httpd-pid #rather than /tmp/httpd-pid -CFLAGS = -O2 -DPOSIXWAIT -DLINUX_FSSTND +CFLAGS = -DUTS2 -fomit-frame-pointer -O2 -DPOSIXWAIT -DLINUX_FSSTND LFLAGS = -s CC = gcc Greetings Bernd __ Bernd Eckenfels ++49 7257 3817 | 1024/E010B09D __If privacy is outlawed [EMAIL PROTECTED] Karlsruhe | *plush* __/ only Outlaws have privacy [EMAIL PROTECTED] [EMAIL PROTECTED] |__inux_/ http://home.pages.de/~eckes/ G21! d? H@ s+ p0 au+ a- w+ v c+++ UL$ P E? N++ t+ e* u@ h++! f !n y* Y^
Bug#1769: bison files in /usr/share
Daniel Quinlan writes: >Bernd S Brentrup <[EMAIL PROTECTED]> writes: >> bora:~$ dpkg --listfiles bison | grep /usr/share >> /usr/share >> /usr/share/bison.simple >> /usr/share/bison.hairy >> >> In any case the directory /usr/share is certainly the wrong place for the >> files. > >/usr/share is "certainly" a better place. The Bison parser skeletons >are architechure-independent. I apologize for bad wording (english isn't my native language), what I meant to say is don't start cluttering /usr/share before it has been agreed upon. A lot of the stuff that's traditionally located in the /usr/lib subtree is architecture independent and should be moved under /usr/share. -- Siggy (the middle S.)
Bug#1777: Source not compiling properly?
On Sun, 29 Oct 1995, Karl Ferguson wrote: > Now, it wont quit at the point - it goes on to finish. But when booting the > kernel I get this error: > > unregister_netdev: device 'ppp0' unlinked > unregister_netdev: device 'ppp1' unlinked > unregister_netdev: device 'ppp2' unlinked > unregister_netdev: device 'ppp3' unlinked > > Of course, once the box has booted I login and cat /proc/net/dev - and there > are no pppx's there - soloutions? The new ppp dynamically allocates ppp devices. The message you're getting is ppp zapping your old device entries so they can now be dynamically allocated. All _should_ work as before. If it doesn't, you should probably join linux-ppp -- I'm just parroting what I picked up there. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Bug#1776: zless missing
Hello, > Someone else (Ian J?) pointed out earlier that zmore uses whatever > file pager is specified by the PAGER environment variable. of course, but i am used to type zless instead of zmore. The same way i am used to type less and not more. Especially on an GNU System I expect zless as i expect less. I dont think we should require millions of ppl to include an alias into their ._profile if they want the usual behaviour. Greetings Bernd __ Bernd Eckenfels ++49 7257 3817 | 1024/E010B09D __If privacy is outlawed [EMAIL PROTECTED] Karlsruhe | *plush* __/ only Outlaws have privacy [EMAIL PROTECTED] [EMAIL PROTECTED] |__inux_/ http://home.pages.de/~eckes/ G21! d? H@ s+ p0 au+ a- w+ v c+++ UL$ P E? N++ t+ e* u@ h++! f !n y* Y^
Bug#1769: bison files in /usr/share
Date: Sun, 29 Oct 95 10:33 MET From: "Bernd S. Brentrup" <[EMAIL PROTECTED]> >/usr/share is "certainly" a better place. The Bison parser >skeletons are architechure-independent. I apologize for bad wording (english isn't my native language), what I meant to say is don't start cluttering /usr/share before it has been agreed upon. A lot of the stuff that's traditionally located in the /usr/lib subtree is architecture independent and should be moved under /usr/share. I agree completely. We should move everything at once. If we don't, we'll start looking like Slackware. ;) (I remember chuckling when I learned that Slackware included a /usr/share with one file in it...) Don't get me wrong--I'm all for /usr/share, but I agree with Bernd. This should be fixed until we move everything to /usr/share, which will be when the FSSTND tells us to.
Re: Bug#1774: : _PATH_DEFPATH contains `.'
On Sat, 28 Oct 1995, Bill Mitchell wrote: > On Sat, 28 Oct 1995, Michael Alan Dorman wrote: > > > This should read "/usr/local/bin:/bin:/usr/bin", without the "." > > While we're at it, would it be appropriate to have xdm also set this as > > the default path? > Would it need /usr/bin/X11? Nah, let people use explicit paths for all their X binaries. No, really, you are correct. My more general point was that according to xtm(1), the default path is set to ":/bin:/usr/bin:/usr/X11R6/bin:/usr/ucb" which does not include /usr/local/bin (which seems to have just been deemed appropriate), and which does include /usr/ucb which isn't even in the FSSTND. It seems that if we're going to alter libc to remove behavior we consider "wrong", it's not inappropriate to do the same for xdm. This could be done as simply as changing the /etc/X11/xdm/xdm-config file that gets installed. Mike. -- "I'm a dinosaur. Somebody's digging my bones."
Re: pre-inst and post-inst scripts that start and stop daemons
> However, I'm wondering whether a more elegant and simple solution > might just be for Bruce to run the cross-installation which a PATH > environment variable that ensures that the version of > start-stop-daemon it finds is a link to `true'. Clever. This is made somewhat more sloppy by the fact that the script is running in a "chroot" context (dpkg --root, remember), and thus I'd have to create the binary directory within the target filesystem. Bruce
Re: Distribution
Date: Sun, 29 Oct 1995 01:21:48 -0700 From: Bruce Perens <[EMAIL PROTECTED]> Rather than re-arrange the current released system, let's put the new organization in place for the "current" and "1.0" system, and leave debian-0.93 where it is now so we don't mess up the mirrors again. That'll give us freedom to move things around for a while. Agreed. Also, I know better this time than to replace a symbolic link with a directory. :)
Re: Distribution
Rather than re-arrange the current released system, let's put the new organization in place for the "current" and "1.0" system, and leave debian-0.93 where it is now so we don't mess up the mirrors again. That'll give us freedom to move things around for a while. Thanks Bruce
Re: package uploading probs
I hate to follow-up to my own message, but it's only after it was out that I got this one in linux-announce: --[ quoting Thomas Koenig ([EMAIL PROTECTED]) ]--- >I have uploaded another version of rdist to sunsite.unc.edu's Incoming >directory. Rdist is, to quote the mangpage, "a program to maintain >identical copies of files over multiple hosts". This version works >together with ssh, Tatu Ylonen's secure remote login program >available from ftp.cs.hut.fi:/pub/ssh. > >Following is the lsm entry. > >Begin3 >Title: rdist >Version:6.1.0 >Entered-date: 1995-05-05 >Description:remote file distribution client program >Keywords: remote file distribution >Author: [EMAIL PROTECTED] (Michael Cooper) >Maintained-by: Thomas Koenig ([EMAIL PROTECTED]) >Primary-site: sunsite.unc.edu:/pub/Linux/system/Network/file-transfer > rdist-6.1.0-linuxpl2.tar.gz 112146 > MD5-Checksum: cf038aa2c5048963c49ba65d1bc71d66 > rdist-6.1.0-linux.lsm 569 >Original-site: usc.edu:/pub/rdist > rdist-6.1.0.tar.gz 111400 >Copying-policy: BSD >End -- Siggy
Re: Packaging guidelines
Date: Tue, 24 Oct 95 20:45 GMT From: Ian Jackson <[EMAIL PROTECTED]> Since noone is maintaining these, and they *desperately* need updating, I shall do it. Who has the latest version and which format are they in ? I started converting them to Texinfo some time ago, but I never had the time to finish doing that. I didn't really make any changes to the content. I can send you what I have, but it might be easier just to start from the old text copy at ftp.debian.org in /debian/standards/Guidelines.
Re: package uploading probs
On Sun, 29 Oct 1995, Siggy Brentrup wrote: > directory across some sites with good connectivity and use rdist(1) to keep > them > in sync? Major mirror sites might be good canditates for this. > I would probably suggest just mirror as a program to keep them up to date. If there is a SINGLE site then this would not be a problem. I would mirror them into a directory called private/project/incoming-europe I have talked about this before but I beleive that no one was able to come up with a site. Let me know the URL and I will begin an hourly mirror of it, asuming that is OK with the rest of Devel. Matt
package uploading probs
This message is intended in the first place for developers over here in Europe. I wonder if there are others experiencing the same problems that I have when uploading files to ftp.debian.org and are looking out for a solution. Since my account @uni-muenster.de is a rather limited one, I'm working almost exclusively on our tiny Debian/GNU Linux LAN at home and use PPP with dynamic IP addressing to connect to the net. Uploading large files (python* is approx. 4M) even during off-peak hours (0030-0130 UTC seems to be best) is prohibitively slow even with local phone rates (they are at 0.23DM/720s now and will go up to 0.12DM/240s next year). It wouldn't be much of a concern when succeeding on the first try, but I lost track of how many attempts failed for various reasons. The trans-atlantic links being slow as they are, a dual approach to mirroring FTP sites sprang to my mind. What if we are distributing the project's incoming directory across some sites with good connectivity and use rdist(1) to keep them in sync? Major mirror sites might be good canditates for this. Before going into greater detail, I'd like to read your comments. Thanks -- Siggy
Re: Distribution
On Sat, 28 Oct 1995, Matthew Bailey wrote: > AOUT -> RELEASED > ELF -> CURRENT I'd suggest DEVELOPMENT, or WORKING, or IN_PROGRESS, or somesuch rather than CURRENT if these are to be visible to user-downloaders. CURRENT is likely not to be taken as bleeding-edge-and-unfinished by user-downloaders.
Bug#1776: zless missing
On Sun, 29 Oct 1995, eckes wrote: > Package: gzip > > I think a zless is as usefull as zmore. The Slackware-implementation of > zless is: > > --- > #!/bin/sh > for args > do > zcat $args | less > done Someone else (Ian J?) pointed out earlier that zmore uses whatever file pager is specified by the PAGER environment variable. export PAGER=less# in ~/.bash_profile, or other setup file zmore file1 file2 file3 # this will use less, not more
Re: Release management and package announcements
On Sun, 29 Oct 1995, Ian Jackson wrote: > We need to decide what information the package maintainer needs to > supply to the FTP site maintainer for the correct placement of the > package. >[...] > I don't particularly care about how this is represented in the > (machine-readable) dchanges format, and I'd like Bruce to tell Bill > and I how this should be represented. >[...] > Is everyone reasonably happy with the above ? I am. I had sent Ian J. a rough-cut example of a new changes file format growing mainly out of my exchanges with Ian M. on this. It looks similar to format produced by the current dchanges program, with changes generally to better address source packages with multiple .deb files, and to replace the File fields with a Files section at the end which contains the ls and md5sum output requested by Ian M. Regarding the new requirement, I suggest a Distribution field containing a blank-delimited list of distribution destinations, similar to the following: Distribution: 0.93 1.0 dchanges would supply a blank Distribution field, and consider it legal to leave the field blank (Should dchanges complain? A blank field can probably be taken to mean that the package should go into the then-current distribution.) If nobody objects, I'll try to get a replacement dchanges package uploaded soon. I don't expect to be the implementor of the scripts on the distribution site which will need to read the changes file. I'll try to define a file format to make this easy, and to describe it completely enough in a dchanges(5) man page that the implementor of these scripts can work from that. I'd like to know who will be implementing the scripts on the distribution site, so I can discuss any problems with or future changes to the dchanges(5) format with him/her via email. If there are objections, please speak up.
