Re: Release Plans (1999-05-10)
Oleg Krivosheev wrote: is there REALLY plans to release something around June 6? No, and there never were. Maybe they mean snapshots of unstable? Richard Braakman
Re: Release Plans (1999-05-10)
Richard Braakman [EMAIL PROTECTED] writes: Adam Di Carlo wrote: I'd like to point out that expecting freeze to be shorter than 10 weeks is lunacy. We have 5 architectures now Consider that archive changes at any point in freeze imply changes in boot floppies (well, for anything in base) and in the CD system. From freeze to release, one month. We won't freeze at all until we have a plan that allows this. The plan must have room for delays, and the ripple effects caused by changes. Huh? Why do you say this? As long as I've been with Debian, I've never seen anything shorter than a 2 month freeze. How do you propose to shorten it? I think the Release Maillist idea will help, but I can't see how we're going to avoid a bug shake-out period (esp. for boot-floppies and debian-cd, not to mention all the pkgs with release critical bugs). I assume we *are* planning to release potato sometime in 1999? -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Release Plans (1999-05-10)
[EMAIL PROTECTED] (Darren O. Benham) wrote on 16.05.99 in [EMAIL PROTECTED]: On Sun, May 16, 1999 at 08:09:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (David Bristel) wrote on 14.05.99 in Pine.LNX.3.96.= [EMAIL PROTECTED]: =20 abandon those who run slink. Note that if linus did that, the 2.2.7 and 2.2.8 would never have come out because work had already begun on the 2= .3 kernels. =20 Umm, may I point out that 2.3.0 =3D=3D 2.2.8? The difference is exactly t= he =20 number. =20 MfG Kai =20 But it won't remain that way for long I wasn't aware that not long can mean forever. Linus is not in the habit of changing past versions. In any case, the claim was that 2.2.7 and 2.2.8 wouldn't have come out because 2.3 kernels were already begun, and that's just plain wrong. If you want to point to maintaining old kernels, point to 2.0.36 and friends instead. MfG Kai
Re: Release Plans (1999-05-10)
On 17 May 1999, Adam Di Carlo wrote: Richard Braakman [EMAIL PROTECTED] writes: Adam Di Carlo wrote: I'd like to point out that expecting freeze to be shorter than 10 weeks is lunacy. We have 5 architectures now Consider that archive changes at any point in freeze imply changes in boot floppies (well, for anything in base) and in the CD system. From freeze to release, one month. We won't freeze at all until we have a plan that allows this. The plan must have room for delays, and the ripple effects caused by changes. Huh? Why do you say this? As long as I've been with Debian, I've never seen anything shorter than a 2 month freeze. [...] IMHO, just because we have made the mistake of freezing too early in the past does not mean we have to repeat it over and over again. Thanks. -- 0a2362076d7148344ac2f0ff503b0e54 (a truly random sig)
Re: Release Plans (1999-05-10)
Gentlemen, that is what i got today Today, May 3, is last day for Pre-Reg Savings. Register at http://www.usenix.org/events/usenix99 1999 USENIX ANNUAL TECHNICAL CONFERENCE June 6-11, 1999 Monterey Conference Center, Monterey, California NEW *BSD AND DEBIAN LINUX RELEASES GIVEN AWAY USENIX is providing grants to the OpenBSD, FreeBSD, NetBSD, and Debian Linux development projects, to support each of them in issuing new releases. The releases-OpenBSD 2.5, FreeBSD 3.2, NetBSD 1.4 and Debian 2.2-will be distributed through usual channels, and, as a bonus, will be given to Annual Conference technical session attendees. is there REALLY plans to release something around June 6? regards OK
Re: Release Plans (1999-05-10)
Anthony Towns wrote: Could you please add IPv6 Support as a Release Goal? I'm willing to act as a sponsor for this (especially since it looks like everyone else is more than happy to do the actual work :). Certainly. How much time do you expect this to take? We're aiming, more or less, to get the base system IPv6 capable for potato, and, I guess, most of the networky programs of priority Standard or higher for woody [0]. It's the first part that interests me, of course :) How do you define the base system? Still to do for potato: * ftp, ftpd * finger, fingerd * identd * tcpdump * lynx * ssh This looks like a rather large base system, you see. Which parts would be the release goal for potato? Richard Braakman
Re: Release Plans (1999-05-10)
Brian Almeida wrote: On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote: Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. Perhaps you aren't using anything that uses unix98 ptys? Not everything uses them by default, you know. Sometimes patches are required. Try ssh'ing to localhost, or install Eterm, or grab some of the packages from ftp.espy.org/pub/debian (I think that's the correct path). In there is patched packages for screen, telnet, etc to use Unix98 ptys. Ah, I was using old xterms. The new ones do use /dev/pts. Thanks for clearing up my confusion :) Richard Braakman
Re: Release Plans (1999-05-10)
Adam Di Carlo wrote: David Bristel [EMAIL PROTECTED] writes: there's been a major package release since the dist went frozen. If the developer wants to make a slink version, because of either personal reasons, or because of requests, then, once the new package(s) have been tested, let them be added into updates. Um, we already have this. It's called 'stable-updates' or 'proposed-updates'. Not really. Packages are rejected from there, if they are not accepted for stable. It's not a permanent repository for unstable packages compiled for stable. Richard Braakman
Re: Release Plans (1999-05-10)
Adam Di Carlo wrote: Richard Braakman [EMAIL PROTECTED] writes: We have a long history of overly optimistic freeze dates :-) I'd like to try something else this time. I note, though, that if we do manage to freeze on July 1, we'll be able to have a release in time for the Linuxworld Expo in August. That would be cool. I'd like to point out that expecting freeze to be shorter than 10 weeks is lunacy. We have 5 architectures now Consider that archive changes at any point in freeze imply changes in boot floppies (well, for anything in base) and in the CD system. From freeze to release, one month. We won't freeze at all until we have a plan that allows this. The plan must have room for delays, and the ripple effects caused by changes. Richard Braakman
Re: Release Plans (1999-05-10)
[EMAIL PROTECTED] (David Bristel) wrote on 14.05.99 in [EMAIL PROTECTED]: abandon those who run slink. Note that if linus did that, the 2.2.7 and 2.2.8 would never have come out because work had already begun on the 2.3 kernels. Umm, may I point out that 2.3.0 == 2.2.8? The difference is exactly the number. MfG Kai
Re: Release Plans (1999-05-10)
On Sun, May 16, 1999 at 08:09:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (David Bristel) wrote on 14.05.99 in [EMAIL PROTECTED]: abandon those who run slink. Note that if linus did that, the 2.2.7 and 2.2.8 would never have come out because work had already begun on the 2.3 kernels. Umm, may I point out that 2.3.0 == 2.2.8? The difference is exactly the number. MfG Kai But it won't remain that way for long -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgp2c1sX8IfIT.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
Gordon Deane [EMAIL PROTECTED] writes: I think Debian should have high quality Slink gnome binaries, because not everyone can afford to run unstable and building from source is quite a lot of work. Also, Redhat have this shipped :-) We don't add new upstream versions into stable after release, generally, unless they are required for critical security issues. People, however, can provide well-advertised (but not part of official Debian) .debs for Gnome on slink if they like -- no one is stopping them. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 09:07:14AM -0700, Brent Fulgham wrote:
I think you should look in http://va.debian.org/~bfulgham/ and download
the version of mozilla that is (hopefully) still there. If it works, and
if more people agree with it, I'll put it in potato.
The only problem I had with the versions in my home directory
is that they were somewhat slow. They were not built using
optimization, so they suffer some performance hits.
Okay. I'll download the thing in your directory, and if it works,
I'll rebuild it, sign it, and move it to Incoming.
Everything seems to build fine according to Tinderbox. Let's
try another build Josip and see how it works out. If we can't
get it to build cleanly, I will pull CVS over my phone line at
home and try building on my Potato system there...
Currently, I'm having trouble with libIDL, since I needed to 'backport'
the potato orbit packages to slink, so that admins can install it on va.
I'm going to check now, and if they did, I see no reason for newer
builds to fail anymore.
I will also try building with `$(MAKE) -f config/client.mk` since
apparently everyone else (from mozilla-{builds,unix}) is doing that...
--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
On Fri, May 14, 1999 at 12:00:24PM +0200, Josip Rodin wrote:
On Thu, May 13, 1999 at 09:07:14AM -0700, Brent Fulgham wrote:
I think you should look in http://va.debian.org/~bfulgham/ and download
the version of mozilla that is (hopefully) still there. If it works, and
if more people agree with it, I'll put it in potato.
The only problem I had with the versions in my home directory
is that they were somewhat slow. They were not built using
optimization, so they suffer some performance hits.
Okay. I'll download the thing in your directory, and if it works,
I'll rebuild it, sign it, and move it to Incoming.
Everything seems to build fine according to Tinderbox. Let's
try another build Josip and see how it works out. If we can't
get it to build cleanly, I will pull CVS over my phone line at
home and try building on my Potato system there...
Currently, I'm having trouble with libIDL, since I needed to 'backport'
the potato orbit packages to slink, so that admins can install it on va.
I'm going to check now, and if they did, I see no reason for newer
builds to fail anymore.
I will also try building with `$(MAKE) -f config/client.mk` since
apparently everyone else (from mozilla-{builds,unix}) is doing that...
What about non i386 builds ?
Friendly,
Sven LUTHER
Re: Release Plans (1999-05-10)
On Fri, May 14, 1999 at 12:02:32PM +0200, Sven LUTHER wrote:
Everything seems to build fine according to Tinderbox. Let's
try another build Josip and see how it works out. If we can't
get it to build cleanly, I will pull CVS over my phone line at
home and try building on my Potato system there...
Currently, I'm having trouble with libIDL, since I needed to 'backport'
the potato orbit packages to slink, so that admins can install it on va.
I'm going to check now, and if they did, I see no reason for newer
builds to fail anymore.
I will also try building with `$(MAKE) -f config/client.mk` since
apparently everyone else (from mozilla-{builds,unix}) is doing that...
What about non i386 builds ?
What about them? The upload will contain source, and you'll be perfectly
free to recompile it :)
--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
On Fri, May 14, 1999 at 12:17:36PM +0200, Josip Rodin wrote:
On Fri, May 14, 1999 at 12:02:32PM +0200, Sven LUTHER wrote:
Everything seems to build fine according to Tinderbox. Let's
try another build Josip and see how it works out. If we can't
get it to build cleanly, I will pull CVS over my phone line at
home and try building on my Potato system there...
Currently, I'm having trouble with libIDL, since I needed to 'backport'
the potato orbit packages to slink, so that admins can install it on va.
I'm going to check now, and if they did, I see no reason for newer
builds to fail anymore.
I will also try building with `$(MAKE) -f config/client.mk` since
apparently everyone else (from mozilla-{builds,unix}) is doing that...
What about non i386 builds ?
What about them? The upload will contain source, and you'll be perfectly
free to recompile it :)
Yes, ...
but mozilla is pretty big, 17MB i think, so the compile will use lots of disk
space and compile time, so i prefer to know if it should work, or if there
should be major problems to it, and not discover after a night's compile time
what went wrong. Also a list of source dependencies would be nice.
Or even to know before i start downloading and compiling that it will not work
anyway.
Also the mozilla web pages are not very informative about non-i386
compilability, but then maybe i didn't search in the right place ...
Friendly,
Sven LUTHER
Re: Release Plans (1999-05-10)
On Fri, May 14, 1999 at 12:23:14PM +0200, Sven LUTHER wrote: What about non i386 builds ? What about them? The upload will contain source, and you'll be perfectly free to recompile it :) Yes, ... but mozilla is pretty big, 17MB i think, so the compile will use lots of disk space and compile time, so i prefer to know if it should work, or if there should be major problems to it, and not discover after a night's compile time what went wrong. Also a list of source dependencies would be nice. Or even to know before i start downloading and compiling that it will not work anyway. Also the mozilla web pages are not very informative about non-i386 compilability, but then maybe i didn't search in the right place ... I don't know much about porting, but I do know that it works on Solaris, and some versions worked on AIX and HP-UX... since those OSs run on different architectures, I'd say it could work. Good luck :) -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
Also the mozilla web pages are not very informative about non-i386 compilability, but then maybe i didn't search in the right place ... I don't know much about porting, but I do know that it works on Solaris, and some versions worked on AIX and HP-UX... since those OSs run on different architectures, I'd say it could work. Good luck :) For powerpc: the composer mode works. The normal mode (with menus) not. Thnx, Hartmut
RE: Release Plans (1999-05-10)
Title: RE: Release Plans (1999-05-10) Yes, ... but mozilla is pretty big, 17MB i think, so the compile will use lots of disk space and compile time, so i prefer to know if it should work, or if there should be major problems to it, and not discover after a night's compile time what went wrong. Also a list of source dependencies would be nice. Or even to know before i start downloading and compiling that it will not work anyway. Also the mozilla web pages are not very informative about non-i386 compilability, but then maybe i didn't search in the right place ... Friendly, Sven LUTHER Yes -- it took nearly 3 hours over a 33.3 phone connection to download CVS. A tarball would have been much faster. It actually builds fairly quickly -- on the order of 40 minutes on my K6-2. I could attempt to build it on faure and see what happens. If we can get the configuration scripts to work cleanly (they are pretty close now) we should be able to let the various build daemons do the boring work later. -Brent
Re: Release Plans (1999-05-10)
My own reasons for wanting these updates in there is that we go frozen, and then a major release comes out. Suddenly, Debian may be more stable, but MAJOR packages are out of date. If we have the updated section available on the ftp site, we can have these packages there for people to install, without ruining the integrity of the stable release. It also gives people a feeling of not needing to wait for the next major release for new software. Sure, once the new version comes out, it wouldn't make sense to build for the OLD versions, but potato isn't out. Because of that, we shouldn't abandon those who run slink. Note that if linus did that, the 2.2.7 and 2.2.8 would never have come out because work had already begun on the 2.3 kernels. Dave Bristel On Wed, 12 May 1999, Branden Robinson wrote: Date: Wed, 12 May 1999 23:29:10 -0400 From: Branden Robinson [EMAIL PROTECTED] To: David Bristel [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: Re: Release Plans (1999-05-10) On Wed, May 12, 1999 at 02:06:24PM -0700, David Bristel wrote: It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. I am perfectly willing to package a version of XFree86 3.3.3.1 for slink (and thus built against glibc 2.0), if I can get assurance that these will be accepted. Except for the Unix98 pty problem which just popped up with xterm, and some kind of strangeness with detecting a particular IBM RAMDAC chip in the I128 X server, reports appear to be that the potato 3.3.3.1 packages are better than the 3.3.2.3 ones in slink in every respect. Namely, there are several packaging-level bugs that I have fixed in the potato version of X. None of these are security matters, however, and that is typically the sole criterion upon which packages for stable-updates are judged. I've been told that this is pretty much Christian Hudon's decision. Perhaps an exception could be made for X, given that it is so huge and onerous to download, and requires gargantuan amounts of space and time to build. But my feelings won't be hurt if he decides against it. In the meantime, Johnie Ingram has been making glibc 2.0 versions of my potato XFree86 packages available at http://www.netgod.net/x/. -- G. Branden Robinson |Yesterday upon the stair, Debian GNU/Linux |I met a man who wasn't there. [EMAIL PROTECTED] |He wasn't there again today, cartoon.ecn.purdue.edu/~branden/ |I think he's from the CIA. pgpi8xY1E17Q1.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
This is why I suggested the new area, apart from main, non-free, and contrib. People who want the updates should have a nice, easily accessable place to find these packages. From a system administration standpoint, it's nice to know EXACTLY where to go to update the entire distribution automatically(via apt-get), if there's been a major package release since the dist went frozen. If the developer wants to make a slink version, because of either personal reasons, or because of requests, then, once the new package(s) have been tested, let them be added into updates. Dave Bristel On Wed, 12 May 1999, Aaron Van Couwenberghe wrote: Date: Wed, 12 May 1999 19:03:29 -0700 From: Aaron Van Couwenberghe [EMAIL PROTECTED] To: Branden Robinson [EMAIL PROTECTED], Debian Development debian-devel@lists.debian.org Subject: Re: Release Plans (1999-05-10) Resent-Date: 13 May 1999 04:42:00 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; On Wed, May 12, 1999 at 11:29:10PM -0400, Branden Robinson wrote: I've been told that this is pretty much Christian Hudon's decision. Perhaps an exception could be made for X, given that it is so huge and onerous to download, and requires gargantuan amounts of space and time to build. But my feelings won't be hurt if he decides against it. In the meantime, Johnie Ingram has been making glibc 2.0 versions of my potato XFree86 packages available at http://www.netgod.net/x/. Which work quite well, by the way ;P. I was forced to get them for my laptop. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
I agree, I would like to see a system where major releases and minor releases exist. (No, we really do not have this as I envision it). The major releases would be the base system and libraries (libc, X, kernel, compilers, etc) and the minor releases would be much more frequent and only be non critical stuff (window managers, apps). This would alow work on the next major systrem with the latest copies of everything, but still allow users sticking with stable to have the (almost) latest versions of things. Right now, it seems a new freeze allows just about anything to be upgraded (glibc 2.1, X, kernel). These are bing complicated things, and take a lot more work to make stable than say window maker. This type of statagy is similar to what is used in the kernel (unstable branch with new fetures and stable branch with just updates). Andrew Lenharth On Fri, 14 May 1999, David Bristel wrote: My own reasons for wanting these updates in there is that we go frozen, and then a major release comes out. Suddenly, Debian may be more stable, but MAJOR packages are out of date. If we have the updated section available on the ftp site, we can have these packages there for people to install, without ruining the integrity of the stable release. It also gives people a feeling of not needing to wait for the next major release for new software. Sure, once the new version comes out, it wouldn't make sense to build for the OLD versions, but potato isn't out. Because of that, we shouldn't abandon those who run slink. Note that if linus did that, the 2.2.7 and 2.2.8 would never have come out because work had already begun on the 2.3 kernels. Dave Bristel
Re: Release Plans (1999-05-10)
David Bristel [EMAIL PROTECTED] writes: This is why I suggested the new area, apart from main, non-free, and contrib. People who want the updates should have a nice, easily accessable place to find these packages. From a system administration standpoint, it's nice to know EXACTLY where to go to update the entire distribution automatically(via apt-get), if there's been a major package release since the dist went frozen. If the developer wants to make a slink version, because of either personal reasons, or because of requests, then, once the new package(s) have been tested, let them be added into updates. Um, we already have this. It's called 'stable-updates' or 'proposed-updates'. In sources.list speak: deb http://http.us.debian.org/debian dists/proposed-updates/ Maybe this should be publicized more. It's pretty much a buyer beware area. If anyone uploads to stable, it gets moved into there. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Release Plans (1999-05-10)
On Fri, 14 May 1999, David Bristel wrote: My own reasons for wanting these updates in there is that we go frozen, and then a major release comes out. Suddenly, Debian may be more stable, but MAJOR packages are out of date. Andrew D Lenharth wrote: I agree, I would like to see a system where major releases and minor releases exist. (No, we really do not have this as I envision it). The major releases would be the base system and libraries (libc, X, kernel, compilers, etc) and the minor releases would be much more frequent and only be non critical stuff (window managers, apps). This is quite different. David said he wanted MAJOR packages included in the updates (e.g. X). You said you agreed, yet you talked of _only_ minor apps being upgraded. I be happier seeing a new X in proposed-updates if it's package maintainer were happier with it than the one currently in stable. Peter
Re: Release Plans (1999-05-10)
Peter S Galbraith [EMAIL PROTECTED] wrote: This is quite different. David said he wanted MAJOR packages included in the updates (e.g. X). You said you agreed, yet you talked of _only_ minor apps being upgraded. It's probably a good idea to make post-freeze major packages available, but not as an official part of that debian release. We already offer other unofficial supplements to debian (contrib comes to mind), and such things are probably useful to a large number of debian users. However, it's almost guaranteed that such packages will be bad for some systems. And package integration (where external packages have dependencies on some part of the major package) isn't going to be all that great. This even would seem to codify existing practice: (a) we tend to make recent good linux kernels available even though related packages (lsof, pcmcia, ...) aren't ready for it. (b) there are a lot of aptable references floating around, for stuff that's not quite ready for prime time. I'm just suggesting that there should be something between a and b. -- Raul
Re: Release Plans (1999-05-10)
This is quite different. David said he wanted MAJOR packages included in the updates (e.g. X). You said you agreed, yet you talked of _only_ minor apps being upgraded. I be happier seeing a new X in proposed-updates if it's package maintainer were happier with it than the one currently in stable. I meant I agreed with the general idea. I too would like to see major packages (X) make it in, but I am not self contradictory. the X (in this case) is a minor version upgrade. If xfree 4.0 was out would you want that put in stable? No. it would go in unstable till the next major release. Hence minor kernel upgrades may be able to go in minor updates, but the 2.0 - 2.2 jump would have waited till a major release. This is sort of a two teir release system. Base system and libraries at the major release level (except minor upgrades to them that don't break stuff) and non-critical suff at the minor release level (a bad window manager does not render my computer unusable). The advantage to this scheme is there is not a rush to get stuff in frozen. You know another minor release will be out in just a couple months. Also, minor upgrades would then be small (depending on how much of what is upgraded ou have installed) and would be known to be mostly safe (and easy to back out). Andrew Lenharth
Re: Release Plans (1999-05-10)
Wichert Akkerman [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] Previously Martin Bialasinski wrote: Do I have access to the net within that environment? I just have some pre-release slink CDs, so I have to upgrade to the current point release by ftp (by an ISDN line - it is accessed like a NIC). Sure. You are just using the same system, only the root of the filesystem is changed for processes running in the chroot-environment. Do I have access to $DISPLAY somehow and can I use startx, so I can test X packages directly? If you use localhost:0.0 you can use the same display (note that :0.0 doesn't work since the X-socket is in a location the chroot-environment cannot access). If you want to do startx you have to use a different display since X is already running. You also have to mount a seperate copy of proc in the chrooted environment. Be careful of pre/post install scripts they may stop daemons and restart them in the chrooted environment. (I usually run all the inetd stuff in one environment and ssh in the other, so normal users can easily access it.) Steve [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
Ian Lynagh wrote: In article [EMAIL PROTECTED], Richard Braakman [EMAIL PROTECTED] writes These are installed now. I assume the delay with libgtop1 was that it was a new package? If so, please remove libgtop0. Yes... I'll get around to that later :-) Richard Braakman
Re: Release Plans (1999-05-10)
[Please restrict your line length to around 70-72 characters, as otherwise it overruns 80 chars when quoted.] It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. Yes, and these patches live in the unstable distribution. How do you know that a patch won't (a) cause some other part of the program to fall over, or (b) cause some other program to fall over (due to some unforeseen interaction)? That's why patches and updates only go into the unstable distribution. (The sole exception to this is security updates or other critical bugs which are allowed into stable because of the serious damage the problem might otherwise cause.) This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. Who's everyone? I'm quite happy with 3.3.2.3a-11 here. But if you *must* have 3.3.3, then you can either compile it yourself or move to unstable. But with XFree86 being the huge beast which it is, how do you know whether 3.3.3 might interact in bad ways with other pieces of software? That's the purpose of unstable. Also, for potato, since it WILL be glibc 2.1 based, I suspect a large number of people would want versions of XFree, gnome, and other packages without having to upgrade their systems. By setting up an Should we provide libc5 versions as well for those who are still running Debian versions pre-2.0? (My department have machines running 1.2 and 1.3 and are now planning to upgrade to Red Hat 5.2 :-( . And they wanted XFree86 3.3.3, so they downloaded it and compiled it themselves.) I think that it is quite enough work for the developers to ensure that two versions work as well as possible (stable and unstable, and even sometimes frozen), without expecting them to work on a random mix of packages from different versions. GNOME has been discussed in other mails, but for the other stuff, it seems quite reasonable to expect those people who are desperate to download the binaries directly from XFree86's site, for example. extension to our current directory structure for updates, we make it VERY simple for people to add these in. I THINK it might also make it easier to release maintenance releases in this manner. Simply have all the updated packages in the updates section. If apt and dselect do their jobs, it should grab the proper NEWer version of the package. Yes, it would make it much easier to have interim releases, but the stability is guaranteed to suffer. And as the stated purpose of stable is to be just that: stable, it is not reasonable to put routine upgrades of individual packages in stable. There is a new release of Debian approximately every six months: those people who cannot wait that long are welcome to live on the unstable distribution. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 02:06:24PM -0700, David Bristel wrote: It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. I am perfectly willing to package a version of XFree86 3.3.3.1 for slink (and thus built against glibc 2.0), if I can get assurance that these will be accepted. Except for the Unix98 pty problem which just popped up with xterm, and some kind of strangeness with detecting a particular IBM RAMDAC chip in the I128 X server, reports appear to be that the potato 3.3.3.1 packages are better than the 3.3.2.3 ones in slink in every respect. Namely, there are several packaging-level bugs that I have fixed in the potato version of X. None of these are security matters, however, and that is typically the sole criterion upon which packages for stable-updates are judged. I've been told that this is pretty much Christian Hudon's decision. Perhaps an exception could be made for X, given that it is so huge and onerous to download, and requires gargantuan amounts of space and time to build. But my feelings won't be hurt if he decides against it. In the meantime, Johnie Ingram has been making glibc 2.0 versions of my potato XFree86 packages available at http://www.netgod.net/x/. -- G. Branden Robinson |Yesterday upon the stair, Debian GNU/Linux |I met a man who wasn't there. [EMAIL PROTECTED] |He wasn't there again today, cartoon.ecn.purdue.edu/~branden/ |I think he's from the CIA. pgpasgYQtHADR.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 11:29:10PM -0400, Branden Robinson wrote: I've been told that this is pretty much Christian Hudon's decision. Perhaps an exception could be made for X, given that it is so huge and onerous to download, and requires gargantuan amounts of space and time to build. But my feelings won't be hurt if he decides against it. In the meantime, Johnie Ingram has been making glibc 2.0 versions of my potato XFree86 packages available at http://www.netgod.net/x/. Which work quite well, by the way ;P. I was forced to get them for my laptop. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Release Plans (1999-05-10)
On Wed, 12 May 1999, Joel Klecker wrote: At 15:14 +0200 1999-05-12, Sven LUTHER wrote: I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. For power macs, we don't need to worry about bootable CDs, most of them have Open Firmware that is too broken to even be capable of booting from either a cdrom drive or a iso9660 filesystem. The few macs that have reasonable OF should be able to boot from an arbitrary executable residing anywhere on the filesystem. The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. -- Matt Porter [EMAIL PROTECTED] This is Linux Country. On a quiet night, you can hear Windows reboot.
Re: Release Plans (1999-05-10)
On Wed, 12 May 1999, Matt Porter wrote: The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. that reminds me, now that i have my home email working again. (yeah, i'm baack. head for the hills while you can.;) does anybody actually have a list of non-MCG/non-IBM/non-Apple PowerPC CHRP/PReP boards? I'm trying to hunt those little buggers down. Me, being the crazy little bastard I am, plan to get those suckers booting somehow. (Don't ask how; I really dunno yet. Probably hack up lilo or something.:) Also, for those of you who aren't subscribed to debian-powerpc, and have RS/6000's - I am working on bootable kernel images, both UP and SMP, for every RS/6000 that I currently have *REASONABLY* stable. The problem is that I *have* to use 2.2.x kernels, due to the fact that, well, 2.0.x kernels are just quite unsuitable for use on RS/6000's. Too many various issues that I've run into. I'm having some.. ISSUES *grumble*.. with kpkg still, but I'll be sure and let everyone know when they're done. I bugged up gcc again, so it'll be a few days probably. -Phillip R. Jaenke, Head Unix Guru, Unicent Telecom 216-344-2603 / 9a-~5p Eastern - Pester me!
Re: Release Plans (1999-05-10)
On May 12, Matt Porter wrote: The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. IMHO there's no point in making the APUS installer boot from CD... people will need to select video cards, etc. Besides which, most Amigas can't boot from CD anyway... Guess that narrows it to PReP ;-) Chris -- = | Chris Lawrence | Visit my home page! | |[EMAIL PROTECTED] | http://www.lordsutch.com/chris/ | | | | | Amiga A4000 604e/233Mhz | Visit the Amiga Web Directory | | with Linux/APUS 2.2.3 | http://www.cucug.org/amiga.html | =
Re: Release Plans (1999-05-10)
Hi, everyone. I've successfully built most of Gnome on a stock Slink system. Three cheers for the Gnome project and the packaging team! On 12 May 1999 15:41:04 +0200, Martin Bialasinski wrote : BTW: compiling gnome is a pain. We _need_ source dependencies Hear, hear. Just for flavour, the gotchas I've found include: - Need to upgrade autoconf, automake, libtool and debhelper - Make sure libjpeg62-dev and not libjpeg6a-dev is installed, or Imlib builds linked against both, and weird stuff happens. - There are a number of minor build breaks or hassles which I don't have time to reproduce and document. An autobuilder would have a lot of trouble just right now. Eg. bug #37226 and more. I think Debian should have high quality Slink gnome binaries, because not everyone can afford to run unstable and building from source is quite a lot of work. Also, Redhat have this shipped :-) Good luck, Gordon Musing Building Gnome is pretty mind-blowing: tens of megabytes of code and data wrapped in two-million, five hundred thousand tonnes of spinning build-script... PS: Can debian-gtk-gnome be web-archived? -- We knew we were in trouble when we needed the seventh power-board for the coffee machines. // Gordon Deane // Engineering/Maths // Aust. Nat. Uni //
Re: Release Plans (1999-05-10)
The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? Thnx, Hartmut
Re: Release Plans (1999-05-10)
Josip Rodin wrote: On Mon, May 10, 1999 at 08:55:44PM +0200, Hartmut Koptein wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. Richard Braakman
Re: Release Plans (1999-05-10)
Hartmut Koptein wrote: Hi, BTW, I think it's good to set an *optimistic* freeze date, so people aren't shocked. I would set it at July 1, or maybe Bastille day (Debian pomme de terre?). We have a long history of overly optimistic freeze dates :-) I'd like to try something else this time. I note, though, that if we do manage to freeze on July 1, we'll be able to have a release in time for the Linuxworld Expo in August. That would be cool. For slink update or for potato? For potato we new min. two months and only if we start now working very hard (all maintainers, not only 10 people or so) on bad packages boot-floppies cd-images. Two months means fixing 2 release-critical bugs per day, starting now. I may have to re-evaluate a few... In any case, my next step will be to mark the packages that I plan to remove from frozen if they aren't fixed at freeze time. This way, their maintainers have advance warning, and the bughunters can concentrate on bugs that will actually delay the freeze. The QA-team must then also have the power to do massive NMU's. How many open bugs have we, more then 7000? This must be down to ~1000. Wow, you're more ambitious than I am :-) I'll be happy enough if we can get the release-critical bugs under control. The rest are, well, not critical to the release, and I'll let someone else worry about them. That said, though, I would like to encourage maintainers to fix up existing packages, rather than packaging more and more new ones. I don't think we can ever reduce the number of bugs unless the ratio of maintainers to packages goes up. Richard Braakman
Re: Release Plans (1999-05-10)
Joel Klecker wrote: At 19:06 +0200 1999-05-10, Richard Braakman wrote: * glibc 2.1 upgrade As far as I know, this project is largely complete. There are one or two bugs left in the backward compatibility code, and there's the question of what to do with /dev/pts. No there isn't, /dev/pts is taken care of. Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. * glibc 2.1 source compatibility A larger task is to ensure that all packages still compile on a glibc 2.1 development system. The sparc people may have a list of problem packages. Most problems in this area have been fixed by the combined effort of the sparc, arm, and powerpc porters. However, many of the patches are sitting in the BTS and have yet to be applied. That is what I meant, actually. We should get those patches into the packages. The issue was delayed during the slink release, I don't think we can in good conscience delay it again. Debian packages should compile from source! Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. powerpc wishes to try for potato. Excellent. Would someone like to be a sponsor for that, in the sense that I described last March? : * Don't try to keep track of everything. Find a sponsor for each : release goal, who keeps track of progress, makes sure it happens, and : gives advance warning of any problems. That way the release manager : only has to stay in touch with the sponsor. Richard Braakman
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 01:13:10PM +0200, Richard Braakman wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. I was kidding - newer mozilla *does* work, just not the versions people expect from us. We had it working just fine in versions 19990323 and 19990402 (ask Brent Fulgham, maybe there were more), but since then they (the mozilla.org guys) released the fourth and fifth milestone (that's their way of calling the big public releases), and everybody expects us (Debian) to package them. Unfortunately, M4 instantly coredumps on every fscking computer we've tried it on, and I can't even build M5 :( I'm trying to build some newer versions right now, actually. What more can I say - we'll just keep trying. If we don't manage to do it before freeze, then I'll file a bug against ftp.debian.org, asking for mozilla package to be removed. -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 01:53:11PM +0200, Josip Rodin wrote: On Thu, May 13, 1999 at 01:13:10PM +0200, Richard Braakman wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. I was kidding - newer mozilla *does* work, just not the versions people expect from us. We had it working just fine in versions 19990323 and 19990402 (ask Brent Fulgham, maybe there were more), Would it be possible to at least have one of those in potato? I was using Mozilla 19981008 for a while with some happiness, but eventually got annoyed by some of its bugs and that it wasn't getting updated. :-/ It'd be nice to have a free, frames java such -capable browser to install, without having to wrestle with the big green dragon... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpPKmHspPVJQ.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 10:12:46PM +1000, Anthony Towns wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. I was kidding - newer mozilla *does* work, just not the versions people expect from us. We had it working just fine in versions 19990323 and 19990402 (ask Brent Fulgham, maybe there were more), Would it be possible to at least have one of those in potato? Maybe. Question is - do we want another five thousand wishlist bug reports from users screaming for something 'better'? ;( I think you should look in http://va.debian.org/~bfulgham/ and download the version of mozilla that is (hopefully) still there. If it works, and if more people agree with it, I'll put it in potato. I was using Mozilla 19981008 for a while with some happiness, but eventually got annoyed by some of its bugs and that it wasn't getting updated. :-/ It'd be nice to have a free, frames java such -capable browser to install, without having to wrestle with the big green dragon... I'm all for it, but it ain't so easy :) BTW is there a fast potato i386 machine somewhere on the net for us developers to use? I'm sick of mailing debian-admin to install one-thousand-and-one little library from potato for building mozilla... -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
Sorry it took me so long to reply, life decided to give me my yearly supply of 'fun' in a small amount of time, and I had deleted the message I was replying to.. I'm also sorry about how I jumped, I over reacted a bit, as I said, this has been a very interesting week... On Tue, May 11, 1999 at 07:51:31AM +0200, Raphael Hertzog wrote: Le Mon, May 10, 1999 at 07:12:55PM -0400, Zephaniah E. Hull écrivait: I highly question your ability to fill this role as it is quite clear that you have not been following the perl5.005 stuff, specificly the debian-perl list and the massages on -devel before -perl existed about how to attack it.. I've read everything, I'm subscribed to -perl. I know that Darren is working hard on the perl package. What do you have against me ? I'm ready for helping and you criticize me. If you want to do the job, it's ok for me. The current plan cleanly addresses the case of things ending up broken, and the perl maintainer is a bit busy but spending his time working on it instead of jumping up every thread where incorrect info is mentioned. What was wrong in the message you're replying to ? Specificly the path issues and the mention of the bug reports.. (From the message I replied to in the first place) Many of them were only paths problems (that may not appear with the official perl5.005 package). And I've already filled some bugs against netbase and netstd so that the packages do not break when perl5.005 is uploaded. This gives the impression that you are quite unaware that perl5.005 should have little to no effect on ANY packages which are currently in use, as perl5.004 will continue to be used by things.. (There are a few minor issues which still need to be worked out, for instance perl-base and deciding which perl will become essential, however the basic upgrade path is that NOTHING breaks as perl5.004 continues to be used by things) As far as the coordinator position, I don't think I'm up to keeping track of everything, but I would definitely like to stay just a little off to the side of the middle... Once again, sorry for snapping at you, hopefully I'll still be living here tomorrow, and be in a state to do anything. (Don't ask, unless you really want a nice long rant about things) Zephaniah E. Hull.. Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/ -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. pgp065hyL6CwB.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
Hi Richard, On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote: Excellent. Would someone like to be a sponsor for that, in the sense that I described last March? : * Don't try to keep track of everything. Find a sponsor for each : release goal, who keeps track of progress, makes sure it happens, and : gives advance warning of any problems. That way the release manager : only has to stay in touch with the sponsor. Could you please add IPv6 Support as a Release Goal? I'm willing to act as a sponsor for this (especially since it looks like everyone else is more than happy to do the actual work :). We're aiming, more or less, to get the base system IPv6 capable for potato, and, I guess, most of the networky programs of priority Standard or higher for woody [0]. We're currently at the point where: In potato: * bind supports records (and has for ages) * netbase supports IPv6 interfaces, has a working ping6, and traceroute6 In progress: [1] * telnet/telnetd (support for both IPv6 and IPv4 in one binary) * inetd, tcp-wrappers * apache * zmailer * radvd Under consideration: (working packages aren't available yet) * Exim Mark Baker [EMAIL PROTECTED] (the exim.deb maintainer) * GNU Zebra Matthew Schlegel [EMAIL PROTECTED] (tentative intent to package) Craig Sanders [EMAIL PROTECTED]) (from the WNPP) * apt Remco van de Meent [EMAIL PROTECTED] (currently just trying things out) Still to do for potato: * ftp, ftpd * finger, fingerd * identd * tcpdump * lynx * ssh We're also working on getting a 6-bone subnet (or something similar) to help testing all this. Cheers, aj [0] ...or whatever. [1] Packages have been made, and are available for testing from either of: deb http://www.debian.org/~ajt/ipv6 ipv6 unstable deb ftp://ftp.ipv6.nl/pub debian/ The sites are more or less synced; they're also i386 only at the moment. All packages in the staging area *need* testing, btw: if you try one and it does/doesn't work, please send a mail to the -ipv6 list so we know when things are ready to be mashed into potato. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpL91bHvu2CW.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
At 13:02 +0200 1999-05-13, Richard Braakman wrote: Joel Klecker wrote: At 19:06 +0200 1999-05-10, Richard Braakman wrote: * glibc 2.1 upgrade As far as I know, this project is largely complete. There are one or two bugs left in the backward compatibility code, and there's the question of what to do with /dev/pts. No there isn't, /dev/pts is taken care of. Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. Most programs do not use UNIX98 ptys, is that what you meant about what to do with it? Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. powerpc wishes to try for potato. Excellent. Would someone like to be a sponsor for that, in the sense that I described last March? I am willing to be the sponsor for the powerpc release. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
At 10:25 +0200 1999-05-13, Hartmut Koptein wrote: The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Linus' tree is fine on pmac, from what I hear. The only patches pmac would need is stuff for the iMac and Blue G3, hopefully OHCI will start to work in the in-kernel USB driver soon, then I will have just the Blue G3 stuff to deal with. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
At 22:10 -0700 1999-05-12, Matt Porter wrote: The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. No, CHRP boards tend to have good OF. Most of the Macs had such broken OF because Apple did not rely on it for booting Mac OS (it only had to be enough to boot up and hand control to the Mac ROM). In the new world architecture introduced with the iMac, Apple finally began relying on OF to boot Mac OS, thus it has to be stable. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote: Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. Perhaps you aren't using anything that uses unix98 ptys? Not everything uses them by default, you know. Sometimes patches are required. Try ssh'ing to localhost, or install Eterm, or grab some of the packages from ftp.espy.org/pub/debian (I think that's the correct path). In there is patched packages for screen, telnet, etc to use Unix98 ptys. Brian
RE: Release Plans (1999-05-10)
(ask Brent Fulgham, maybe there were more), Would it be possible to at least have one of those in potato? Maybe. Question is - do we want another five thousand wishlist bug reports from users screaming for something 'better'? ;( I think you should look in http://va.debian.org/~bfulgham/ and download the version of mozilla that is (hopefully) still there. If it works, and if more people agree with it, I'll put it in potato. The only problem I had with the versions in my home directory is that they were somewhat slow. They were not built using optimization, so they suffer some performance hits. Everything seems to build fine according to Tinderbox. Let's try another build Josip and see how it works out. If we can't get it to build cleanly, I will pull CVS over my phone line at home and try building on my Potato system there... -Brent
Re: Release Plans (1999-05-10)
Le Thu, May 13, 1999 at 09:16:11AM -0400, Zephaniah E. Hull écrivait: Specificly the path issues and the mention of the bug reports.. About the bugs, here they are : http://www.debian.org/Bugs/db/35/35236.html http://www.debian.org/Bugs/db/35/35446.html And there are path problems IF perl5.005 is used and IF perl5.005 is compiled without /usr/lib/perl5 in @INC. But with the solutions proposed in those bug reports, there won't be any problems at all (with perl5.004 or perl5.005 and any further version). This gives the impression that you are quite unaware that perl5.005 should have little to no effect on ANY packages which are currently in use, as perl5.004 will continue to be used by things.. This is true if perl5.004 will still be used, but as you know, perl5.005 has some binary incompatiblity for binary modules. And actual binary modules will be replaced by newly compiled ones and will depend on perl5.005. So if you have one binary module on your system and if people upgrade it, perl5.005 will be automatically installed. And /usr/bin/perl will be changed. And then the problems may arise. And last I talked with Darren, he said that he will need to add /usr/lib/perl5 to @INC at least for potato (woody's perl may get rid of it) in order not to have to conflict with specific version of netstd and/or netbase. Because actually there are postinst script that do NOT run if you use perl5.005 without /usr/lib/perl5 in @INC. Look at netstd's and netbase's postints. BTW, I think there's a similar problem for the PDL package. (There are a few minor issues which still need to be worked out, for instance perl-base and deciding which perl will become essential, however the basic upgrade path is that NOTHING breaks as perl5.004 continues to be used by things) That's ok, as long as you do not upgrade binary perl modules. Cheers, -- Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: Release Plans (1999-05-10)
[ I'm responding to myself in order to precise things, there was some informations missing in the previous message ] [ Followup on debian-perl, please ] Le Thu, May 13, 1999 at 06:32:00PM +0200, Raphael Hertzog écrivait: This is true if perl5.004 will still be used, but as you know, perl5.005 has some binary incompatiblity for binary modules. And actual binary modules will be replaced by newly compiled ones and will depend on perl5.005. So if you have one binary module on your system and if people upgrade it, perl5.005 will be automatically installed. And /usr/bin/perl will be changed. And then the problems may arise. In fact, we must agree to use the latest perl. Because there's the same problem with non-binary perl modules. If they are built with the latest perl, they'll be installed in a versionned directory and therefore they will have to depend on perl5.005 Zephaniah, you must understand that the fact we decided to have multiple perls do not ONLY have to do to the fact that we want a smooth upgrade but also that we do want to make multiple perl available so that we can use #!/usr/lib/perl5.004 in script that do specifically need such a perl. And we CAN have a smooth upgrade even with perl5.005 as the default perl. The important point is that all modules in Debian must have been built with the same perl version and that perl keeps /usr/lib/perl5 in @INC (only for potato release, after that we'll get rid of it because the scripts that would break will already be corrected). And I do not want to minimize the importance of the perl5.005 upgrade, there are many little issues affecting MANY packages : - of course perl modules must be rebuilt - postint scripts of some packages must be corrected - all package depending on perl will have to depend on perl5. If they need a specific version of perl, they'll have to set a dependency to perl5.XXX. This is not mandatory, but should be done for consistency, because the perl package will only be a fake package (like xbase was) depending on perl5.004. BTW, I think that perl should depend on perl5.004 | perl5.005 ... otherwise with perl5.005 installed, a package depending on perl would have dependencies problems. :-) Cheers, -- Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: Release Plans (1999-05-10)
On Thu, 13 May 1999, Hartmut Koptein wrote: The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. assuming it's similar to openboot, set boot-device disk setenv autoboot true are you getting any specific errors reading from floppy? Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? no offense intended, but you'd probably be best holding off till i get my images/source done for the rs/6000 against 2.2.6 or 2.2.8. 2.2.8 after looking at the code, will *not* boot on any rs64 (i had 2.2.6 booting on single rs64 in 32bit mode). the problem is in cort's code; it's simply not rs64 ready. and barely 604e rs/6k ready. i will HOPEFULLY have this done by the end of tomorrow. i broke gcc early last week, and finally got it fixed today, so soon. very soon. as to chrp/prep, most are neither. s70's are chrp, but s70 advanced servers don't appear to be. h70's are chrp as well. f50's i still haven't figured out. *some* f40's are chrp. (only single cpu f40's from what i can tell so far.) what i really need is *physical* access to rs/6000's to tell. gotta get into the openfirmware via aix to figure out what platform it is. and then from there, it's generally very easy. btw, i am working on smp support.. i have dual on f40 non-chrp, but single on everything else still. give me a few months on that. ;) -Phillip R. Jaenke, Head Unix Guru, Unicent Telecom 216-344-2603 / 9a-~5p Eastern - PESTER ME!
Re: Release Plans (1999-05-10)
Richard Braakman [EMAIL PROTECTED] writes: We have a long history of overly optimistic freeze dates :-) I'd like to try something else this time. I note, though, that if we do manage to freeze on July 1, we'll be able to have a release in time for the Linuxworld Expo in August. That would be cool. I'd like to point out that expecting freeze to be shorter than 10 weeks is lunacy. We have 5 architectures now Consider that archive changes at any point in freeze imply changes in boot floppies (well, for anything in base) and in the CD system. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 09:08:08PM +0200, Hartmut Koptein wrote: The best list is [EMAIL PROTECTED] The main problem we are facing is our official 2.2.x kernels are huge, and there's no way to put the kernel and the root.bin image on a single floppy. The proposed solution is building a modularized kernel, and loading the needed modules using an initrd image, but AFAICT, there's nobody working on that. What about the ramdisk/root.bin (and then also for the netboot-ramdisk)? They are also very huge now. Floppies with 1.7MB isn't good ... Anybody remember the old slackware adage? The kernel can load its root FS (compressed or not) from a separate floppy. this would bring us up to a measly three floppies for floppy install. Besides, most ppl will be doing CD boots anway -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 02:22:10PM -0500, Ossama Othman wrote: It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. I can do this, albeit gradually. Um, to set a time frame, I'd say I could have the majority of the gnome packages built on slink (if everything works smoothly) within a week or so. But first, I don't quite understand the 'proposed-updates' process. someone will need to explain this to me... -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Release Plans (1999-05-10)
*Aaron Van Couwenberghe wrote: Anybody remember the old slackware adage? The kernel can load its root FS (compressed or not) from a separate floppy. this would bring us up to a measly three floppies for floppy install. Besides, most ppl will be doing CD boots anway I wouldn't mind installing from 2 or three floppies. I think if it has advantages, it's a good idea. There have been times when, for one reason or another, CD and network installs were giving me problems, and I said 'screw it' and made 7 floppies from a neighboring DOS machine and installed from them. For a single machine it is relatively painless. John -- John Lapeyre [EMAIL PROTECTED], [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Release Plans (1999-05-10)
AVC == Aaron Van Couwenberghe [EMAIL PROTECTED] writes: [ GNOME rebuild for slink ] AVC I can do this, albeit gradually. Um, to set a time frame, I'd say AVC I could have the majority of the gnome packages built on slink AVC (if everything works smoothly) within a week or so. Not to double effords: I installed slink in an vmware environment on my main box yesterday, and started rebuilding. It is a PII 300 with 128 MB Ram, so compiling is much faster than on my dedicated P90 48 MB slink box. So far, I have Contact me per mail, so we can coordinate on this (and further discussion should be on debian-gtk-gnome). The vmware environment is great. Finally a way to compile for slink on a potato box. And it is great for testing. You can test installations (and take screenshots), test upgrade paths and discard the changes made during the session, so you can try again from the same point etc. It is bloody non-free, so most likely I get kicked in the ass for this :-), but how about asking them, if they could donate some of the final products for developement of debian? I know, I could make some space on the disk for a seperate partition, but vmware still has some advantages (no repartitioning, growing diskusage as it is needed, ability to discard changes, runs as a window in a controlled environment). AVC But first, I don't quite understand the 'proposed-updates' AVC process. someone will need to explain this to me... The upload should go into the slink staging area first, so it can be tested. www.debian.org/~jim has a readme how to do this. Ciao, Martin
Re: Release Plans (1999-05-10)
MB == Martin Bialasinski [EMAIL PROTECTED] writes: Aargh, send too early... MB So far, I have imlib, orbit, gtop, gtk-engines and I am building bone-libs right now. In the FAQ on the gnome site, there is info anout the sequence you have to use. Ciao, Martin
Re: Release Plans (1999-05-10)
Previously Martin Bialasinski wrote: The vmware environment is great. Finally a way to compile for slink on a potato box. And it is great for testing. You can test installations (and take screenshots), test upgrade paths and discard the changes made during the session, so you can try again from the same point etc. But vmware is non-free while there is a perfect method to do the same without vmware: simply create a chroot slink environment and work in there. The simplest way to do that is to extract the base system somewhere and as root cd into it and to chroot bin/sh. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgp7ItpC9IoGN.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 01:16:07PM -0700, Matt Porter wrote: On Mon, 10 May 1999, Hartmut Koptein wrote: There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... Friendly, Sven LUTHER
Re: Release Plans (1999-05-10)
There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. Thnx, Hartmut
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 03:09:02PM +0200, Hartmut Koptein wrote: There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). A bootable CD for PReP will need a special layout as well. prep image + isofs...looks like we need multiple powerpc binary cd images. And i guess this will be the same for apus systems, ... No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. Friendly, Sven LUTHER
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 12:20:15PM +0200, Martin Bialasinski wrote: MB == Martin Bialasinski [EMAIL PROTECTED] writes: Aargh, send too early... MB So far, I have imlib, orbit, gtop, gtk-engines and I am building bone-libs right now. In the FAQ on the gnome site, there is info anout the sequence you have to use. Ok, um, then I will write some scripts today for a slink-gnome-stage-area. ;) Stay tuned. Ciao, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Release Plans (1999-05-10)
WA == Wichert Akkerman [EMAIL PROTECTED] writes: WA But vmware is non-free while there is a perfect method to do the WA same without vmware: Looks like the thing I was looking for. For compilation, this should work, I will try it. WA simply create a chroot slink environment and work in there. WA The simplest way to do that is to extract the base system WA somewhere and as root cd into it and to chroot bin/sh. I never done this, so some additional questions: Do I have access to the net within that environment? I just have some pre-release slink CDs, so I have to upgrade to the current point release by ftp (by an ISDN line - it is accessed like a NIC). Do I have access to $DISPLAY somehow and can I use startx, so I can test X packages directly? Ciao, Martin
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 01:43:57PM +0200, Martin Bialasinski wrote: WA == Wichert Akkerman [EMAIL PROTECTED] writes: WA But vmware is non-free while there is a perfect method to do the WA same without vmware: Looks like the thing I was looking for. For compilation, this should work, I will try it. WA simply create a chroot slink environment and work in there. WA The simplest way to do that is to extract the base system WA somewhere and as root cd into it and to chroot bin/sh. not entirely sure about this, but i think a chrooted environment is exactly like you booted from the environment you chrooted to. Friendly, Sven LUTHER
Re: Release Plans (1999-05-10)
Previously Martin Bialasinski wrote: Do I have access to the net within that environment? I just have some pre-release slink CDs, so I have to upgrade to the current point release by ftp (by an ISDN line - it is accessed like a NIC). Sure. You are just using the same system, only the root of the filesystem is changed for processes running in the chroot-environment. Do I have access to $DISPLAY somehow and can I use startx, so I can test X packages directly? If you use localhost:0.0 you can use the same display (note that :0.0 doesn't work since the X-socket is in a location the chroot-environment cannot access). If you want to do startx you have to use a different display since X is already running. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpfqOKeRbVNJ.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
On Wed, 12 May 1999, Sven LUTHER wrote: On Wed, May 12, 1999 at 03:09:02PM +0200, Hartmut Koptein wrote: No! Only one (2) cd for all powerpc systems. Please think about a wrapper for this or special boot-arguments ... but not 5 different powerpc-images. I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. Exactly. For a PReP bootable CD (which would be nice), you have to lay the first track as a raw PReP bootable image. The second track has your fs in whatever format you want dos/iso/etc. Although this CD will work on other architectures, it will not be bootable unless they have boot schemes which don't conflict with PReP. The problem is that each subarch is too different to have a full-featured unified CD. If we want a unified official CD then it will have to go to the lowest common denominator. Of course, a PPC user can't boot from CD then they have to resort to floppy or network which means we've got to split the rescue disk or fix the libc hack so we can squeeze on one floppy. How hard is maintaining separate bootable CD images for each subarch that can handle booting from CD? We have apus - ? chrp - ? pmac - supports CD booting - how? prep - supports CD booting - as I described. Everything on the fs will be the same at least between subarchs. -- Matt Porter [EMAIL PROTECTED] This is Linux Country. On a quiet night, you can hear Windows reboot.
Re: Release Plans (1999-05-10)
AVC == Aaron Van Couwenberghe [EMAIL PROTECTED] writes: AVC Ok, um, then I will write some scripts today for a AVC slink-gnome-stage-area. ;) There is one already. See the readme master.debian.org/~jim/gnome BTW: compiling gnome is a pain. We _need_ source dependencies ... Everytime I thought I have all the needed stuff, it bombs somewhere (currently it doesn't find the docbook stylesheets - of cause this is reported after all the stuff has been build...) Ciao, Martin
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 08:08:06AM -0700, Matt Porter wrote: apus - supports CD booting, but don't know how ? chrp - ? pmac - supports CD booting - how? prep - supports CD booting - as I described. but would it not be nice to but the boot stuff for everyone of this system on one partition and the common stuff on the rest of the CD. Also, we have already two binary cds, maybe it will even grow to three, there is nothing stoping us from making binary-cd1 bootable for prep, the other for pmac and apus, or some other combination ... Friendly, Sven LUTHER
Re: Release Plans (1999-05-10)
At 15:14 +0200 1999-05-12, Sven LUTHER wrote: I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. For power macs, we don't need to worry about bootable CDs, most of them have Open Firmware that is too broken to even be capable of booting from either a cdrom drive or a iso9660 filesystem. The few macs that have reasonable OF should be able to boot from an arbitrary executable residing anywhere on the filesystem. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
Ossama Othman wrote: GNOME has been copied from the staging area into potato. I believe that just about all of the GNOME packages that I copied into Incoming have been installed into the archive. However, at least two packages should get into the archive before the freeze libgtop1 and libghttp1. These are installed now. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Richard Braakman
Re: Release Plans (1999-05-10)
Hi Richard, I'm cross-posting to debian-gtk-gnome since we are trying to organize an effort to update GNOME for slink. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Release Plans (1999-05-10)
Richard Braakman [EMAIL PROTECTED] writes: Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. The current plan, as I understand it, is to build GNOME 1.0 debs for slink, and turn them over to the GNOME folks for distribution from ftp.gnome.org. This was, in fact, one of the original motivations for setting up the slink staging area. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 02:42:16PM -0500, Ossama Othman wrote: Hi Richard, I'm cross-posting to debian-gtk-gnome since we are trying to organize an effort to update GNOME for slink. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? Opinion: probably not. That's what a release is.. that's what next versions of releases are for... Security fixes are a special issue but 'the next/latest/newest widgit' are not.. -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgpu1f4QXZTjf.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
Hi Darren, On 12 May, Darren O. Benham wrote: On Wed, May 12, 1999 at 02:42:16PM -0500, Ossama Othman wrote: Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? Opinion: probably not. That's what a release is.. that's what next versions of releases are for... Security fixes are a special issue but 'the next/latest/newest widgit' are not.. No problem here. Will we then just make the debs available to the GNOME for folks to distribute, as Chris mentioned? -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: Release Plans (1999-05-10)
It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. Also, for potato, since it WILL be glibc 2.1 based, I suspect a large number of people would want versions of XFree, gnome, and other packages without having to upgrade their systems. By setting up an extension to our current directory structure for updates, we make it VERY simple for people to add these in. I THINK it might also make it easier to release maintenance releases in this manner. Simply have all the updated packages in the updates section. If apt and dselect do their jobs, it should grab the proper NEWer version of the package. Dave On Wed, 12 May 1999, Darren O. Benham wrote: Date: Wed, 12 May 1999 13:10:53 -0700 From: Darren O. Benham [EMAIL PROTECTED] To: debian-devel@lists.debian.org, debian-gtk-gnome@lists.debian.org Subject: Re: Release Plans (1999-05-10) Resent-Date: 12 May 1999 20:13:09 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; On Wed, May 12, 1999 at 02:42:16PM -0500, Ossama Othman wrote: Hi Richard, I'm cross-posting to debian-gtk-gnome since we are trying to organize an effort to update GNOME for slink. It'd also be nice to get GNOME for slink out too. All that really needs to be done is to build all of the packages we built for potato for slink. The current GNOME slink packages are not all up-to-date with the potato packages. Many of us don't have slink installed or don't have a chrooted slink setup so any help with getting GNOME slink up-to-date would be greatly appreciated. Do you mean make GNOME 1.0 available for slink, separately? It's far too large a change to be part of a stable revision. Hmm. I didn't think of it that way. I've just been going with the flow in terms of what I thought most people felt. However, what you say makes sense. What do you suggest we do? How should we go about making GNOME available for slink? Do we _not_ want to do that? Opinion: probably not. That's what a release is.. that's what next versions of releases are for... Security fixes are a special issue but 'the next/latest/newest widgit' are not.. -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgpSKcGqpXzkD.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 02:06:24PM -0700, David Bristel wrote: It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. Also, for potato, since it WILL be glibc 2.1 based, I suspect a large number of people would want versions of XFree, gnome, and other packages without having to upgrade their systems. By setting up an extension to our current directory structure for updates, we make it VERY simple for people to add these in. I THINK it might also make it easier to release maintenance releases in this manner. Simply have all the updated packages in the updates section. If apt and dselect do their jobs, it should grab the proper NEWer version of the package. Propose it on -Policy and be sure the cc' the ftpmasters. An issue to consider is manpower. Since most of the maintainers will up to Potato, who'll compile these new packages/updates for slink? -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgptqq525NlVx.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
In article [EMAIL PROTECTED], Richard Braakman [EMAIL PROTECTED] writes Ossama Othman wrote: GNOME has been copied from the staging area into potato. I believe that just about all of the GNOME packages that I copied into Incoming have been installed into the archive. However, at least two packages should get into the archive before the freeze libgtop1 and libghttp1. These are installed now. I assume the delay with libgtop1 was that it was a new package? If so, please remove libgtop0. Thanks -- Ian Lynagh - [EMAIL PROTECTED] http://www.lynagh.demon.co.uk/ Just because you're paranoid, it doesn't mean they're not out to get you.
Re: Release Plans (1999-05-10)
Hi, On 12 May, Ian Lynagh wrote: I assume the delay with libgtop1 was that it was a new package? If so, please remove libgtop0. Right. That's what Guy told me. You should probably e-mail the ftp masters about your desire to remove libgtop0 from the archive. -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Slink compiles [was: Re: Release Plans (1999-05-10)]
On Wed, May 12, 1999 at 02:40:33PM -0700, Darren O. Benham wrote: Propose it on -Policy and be sure the cc' the ftpmasters. An issue to consider is manpower. Since most of the maintainers will up to Potato, who'll compile these new packages/updates for slink? Can't autobuilders do it (with a source-only upload)? -=- James Mastros -- First they came for the fourth amendment, but I said nothing because I wasn't a drug dealer. Then they came for the sixth amendment, but I kept quiet because I wasn't guilty. Finally they came for the first amendment, and by then it was too late to say anything at all. -=- Nancy Lebowitz cat /dev/urandom|james --insane=yes http://www.rtweb.net/theorb/ ICQ: 1293899 AIM: theorbtwo YPager: theorbtwo
Re: Release Plans (1999-05-10)
I'm sorry about the tone, but I'm getting very sick of repeating myself over and over. On Mon, May 10, 1999 at 08:26:19PM +0200, Raphael Hertzog wrote: snip I've been working with the previous perl5.005 package (the one that had been uploaded to slink and retracted after) and I did not have many problems. Many of them were only paths problems (that may not appear with the official perl5.005 package). And I've already filled some bugs against netbase and netstd so that the packages do not break when perl5.005 is uploaded. Some other packages may need little changes but that would not be a problem. I'll propose myself as coordinator for the perl5.005 upgrade (you did explain that you wanted a coordinator for each release goal). I highly question your ability to fill this role as it is quite clear that you have not been following the perl5.005 stuff, specificly the debian-perl list and the massages on -devel before -perl existed about how to attack it.. The current plan cleanly addresses the case of things ending up broken, and the perl maintainer is a bit busy but spending his time working on it instead of jumping up every thread where incorrect info is mentioned. You may still be someone who could handle it, but PLEASE read the archives first? Zephaniah E. Hull.. snip Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. pgpGXv9sQcRRf.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
Le Mon, May 10, 1999 at 07:12:55PM -0400, Zephaniah E. Hull écrivait: I highly question your ability to fill this role as it is quite clear that you have not been following the perl5.005 stuff, specificly the debian-perl list and the massages on -devel before -perl existed about how to attack it.. I've read everything, I'm subscribed to -perl. I know that Darren is working hard on the perl package. What do you have against me ? I'm ready for helping and you criticize me. If you want to do the job, it's ok for me. The current plan cleanly addresses the case of things ending up broken, and the perl maintainer is a bit busy but spending his time working on it instead of jumping up every thread where incorrect info is mentioned. What was wrong in the message you're replying to ? Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: Release Plans (1999-05-10)
On May 10, Hartmut Koptein wrote: There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I asked Steve to use the HFS options for PowerPC too (so the code's already there...) Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || |Amiga A4000 604e/233Mhz | This address has been spam-proofed.| | with Linux/APUS 2.2.3| All spam goes to your postmaster. | =
Re: Release Plans (1999-05-10)
For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I asked Steve to use the HFS options for PowerPC too (so the code's already there...) Great! One point i can strike off from my todo list. Thanks.
Re: Release Plans (1999-05-10)
Raphael Hertzog writes: There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Agreed. Help on this aspect gratefully received... Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. Really? If you have a list, I'd love to see it... -- Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED] a href=http://www.rpg-soc.ucam.org/curs/CURS home page/a Can't keep my eyes from the circling sky, +-- Tongue-tied twisted, Just an earth-bound misfit, I... |Finger for PGP key
Re: Release Plans (1999-05-10)
Chris Lawrence writes: slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I asked Steve to use the HFS options for PowerPC too (so the code's already there...) Yep, you're correct. -- Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED] a href=http://www.rpg-soc.ucam.org/curs/CURS home page/a Can't keep my eyes from the circling sky, +-- Tongue-tied twisted, Just an earth-bound misfit, I... |Finger for PGP key
Re: Release Plans (1999-05-10)
Adam Di Carlo writes: Debian-CD has a number of problems that need fixing; see the Bugs against the package. Join debian-cd to help. That would be useful. I _am_ working on things when I get a chance, even if I have been a little quiet of late. Are we going to go ahead and try out my new Release Team concept? If so, let's make the mailing list and troll the right people to join. Count me in... -- Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED] a href=http://www.rpg-soc.ucam.org/curs/CURS home page/a Can't keep my eyes from the circling sky, +-- Tongue-tied twisted, Just an earth-bound misfit, I... |Finger for PGP key
Re: Release Plans (1999-05-10)
On 10/05, Richard Braakman wrote: | * glibc 2.1 upgrade | As far as I know, this project is largely complete. There are one or two | bugs left in the backward compatibility code, and there's the question | of what to do with /dev/pts. Not largely complete on Sparc (we still have problems with Sun4m), but Ben Collins is actively working on fixing this :)
Re: Release Plans (1999-05-10)
On Mon, May 10, 1999 at 07:06:58PM +0200, Richard Braakman wrote: [...] A number of release goals have been proposed. I don't intend to start the freeze until all release goals are in place. [...] * Working disk sets for all released architectures. I don't know much about the plans for the boot-floppies yet. Could someone volunteer as a contact person, or tell me the best list to read? The best list is [EMAIL PROTECTED] The main problem we are facing is our official 2.2.x kernels are huge, and there's no way to put the kernel and the root.bin image on a single floppy. The proposed solution is building a modularized kernel, and loading the needed modules using an initrd image, but AFAICT, there's nobody working on that. -- Enrique Zanardi[EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
I think that Power PC will be included in potato. Am I wrong? Have a nice day,Paulo Henrique Quoting Ossama Othman ([EMAIL PROTECTED]): Hi, On 10 May, Richard Braakman wrote: * GNOME I wasn't there to see it, but I hear that the GNOME staging area has now been folded into potato and is ready for the freeze. It has. However, there are still some packages that may not have made it in to the archive that need to be in there (e.g. libgtop1, libghttp1). I posted to the debian-gtk-gnome list about this issue but haven't received a response yet. Return of the Revenge of Slink: A Debian 2.1r3 release should be made soon, to fix a number of outstanding bugs. I'll write a separate mail about this. It would be nice to get a GNOME update for slink, too. However, I'm not sure where GNOME for slink stands. The last I heard, we are not in synch with potato's GNOME yet. -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
Samuel Tardieu [EMAIL PROTECTED] writes: On 10/05, Richard Braakman wrote: | * glibc 2.1 upgrade | As far as I know, this project is largely complete. There are one or two | bugs left in the backward compatibility code, and there's the question | of what to do with /dev/pts. Not largely complete on Sparc (we still have problems with Sun4m), but Ben Collins is actively working on fixing this :) I believe the problem is known and we have a fix. I'm just waiting for a stock Linus kernel to show up with the appropriate patches in it, so we can add it to potato. Same thing with X 3.3.3.1. We need a late kernel for Creator and Mach64 systems (and, perhaps, LEO systems). Steve [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
On May 10, Paulo Henrique Baptista de Oliveira wrote: I think that Power PC will be included in potato. It will be definitly.
Re: Release Plans (1999-05-10)
At 19:06 +0200 1999-05-10, Richard Braakman wrote: * glibc 2.1 upgrade As far as I know, this project is largely complete. There are one or two bugs left in the backward compatibility code, and there's the question of what to do with /dev/pts. No there isn't, /dev/pts is taken care of. * glibc 2.1 source compatibility A larger task is to ensure that all packages still compile on a glibc 2.1 development system. The sparc people may have a list of problem packages. Most problems in this area have been fixed by the combined effort of the sparc, arm, and powerpc porters. However, many of the patches are sitting in the BTS and have yet to be applied. Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. powerpc wishes to try for potato. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
Le Mon, May 10, 1999 at 07:06:58PM +0200, Richard Braakman écrivait: * perl 5.005 I've been assured that a working upgrade plan now exists and is being worked on, one that will not involve recompiling a lot of packages. I'll still be happier if perl 5.005 is introduced at the start of the next release cycle, though. There's a lot of perl code in Debian that hasn't been tested with the new version. I've been working with the previous perl5.005 package (the one that had been uploaded to slink and retracted after) and I did not have many problems. Many of them were only paths problems (that may not appear with the official perl5.005 package). And I've already filled some bugs against netbase and netstd so that the packages do not break when perl5.005 is uploaded. Some other packages may need little changes but that would not be a problem. I'll propose myself as coordinator for the perl5.005 upgrade (you did explain that you wanted a coordinator for each release goal). debian-release mailing list: I think this is a good idea, and I will certainly join such a list. I'll join too. A Debian 2.1r3 release should be made soon, to fix a number of outstanding bugs. I'll write a separate mail about this. I hope that you'll include my NMU of dpkg. It didn't get installed into stable-updates so far ... Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: Release Plans (1999-05-10)
Enrique Zanardi [EMAIL PROTECTED] writes: On Mon, May 10, 1999 at 07:06:58PM +0200, Richard Braakman wrote: * Working disk sets for all released architectures. I don't know much about the plans for the boot-floppies yet. Could someone volunteer as a contact person, or tell me the best list to read? The best list is [EMAIL PROTECTED] The main problem we are facing is our official 2.2.x kernels are huge, and there's no way to put the kernel and the root.bin image on a single floppy. The proposed solution is building a modularized kernel, and loading the needed modules using an initrd image, but AFAICT, there's nobody working on that. Yes... I am troubled by this. I'd like to go into freeze with a mildly functional boot-floppies. Unfortunately, I'm too busy to hack code for this. Anyhow, so this is a big concern for potato. However, I think we should just start by basically zoinking the RedHat initrd stuff, as much as we can. I know Corel is interested in this too. Richard, you forgot a number of other items: What architectures will be in potato? Clearly, all the slink ones -- will PowerPC be ready too? Hurd-i386? (good god, I don't want to even *think* about what we'll need for Hurd boot-floppies -- *shudder*) Debian-CD has a number of problems that need fixing; see the Bugs against the package. Join debian-cd to help. Are we going to go ahead and try out my new Release Team concept? If so, let's make the mailing list and troll the right people to join. BTW, I think it's good to set an *optimistic* freeze date, so people aren't shocked. I would set it at July 1, or maybe Bastille day (Debian pomme de terre?). -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Release Plans (1999-05-10)
Moin all, * Working disk sets for all released architectures. I don't know much about the plans for the boot-floppies yet. Could someone volunteer as a contact person, or tell me the best list to read? A minimum is two months for this -- if we start now to work on this. * glibc 2.1 source compatibility A larger task is to ensure that all packages still compile on a glibc 2.1 development system. The sparc people may have a list of problem packages. The packages must work for glibc-2.1 _and_ linux-2.2, this is important. I think we have more then 100 release-critical bugs, not all such bugs are marked as critical. I've put my autobuilder logfiles (for bad packages) on http://master.debian.org/~koptein -- please have a look at it. This are not all glibc-2.1, linux or dpkg bugs, but mainly. Timescale: The freeze is at least one month away, and possibly a lot more than that. I'm not going to set a date until the number of release-critical bugs has been reduced considerably. Correct. Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. + PowerPC The biggest showstopper are the boot-floppies -- for all architectures! Other topics: language support for boot-floppies (and then also cd-images) and dpkg dselect (and newer apt-get versions). mozilla should work for potato Thnx, Hartmut
Re: Release Plans (1999-05-10)
Le Mon, May 10, 1999 at 07:06:58PM +0200, Richard Braakman écrivait: * Working disk sets for all released architectures. I don't know much about the plans for the boot-floppies yet. Could someone volunteer as a contact person, or tell me the best list to read? There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: Release Plans (1999-05-10)
Hi, BTW, I think it's good to set an *optimistic* freeze date, so people aren't shocked. I would set it at July 1, or maybe Bastille day (Debian pomme de terre?). For slink update or for potato? For potato we new min. two months and only if we start now working very hard (all maintainers, not only 10 people or so) on bad packages boot-floppies cd-images. The QA-team must then also have the power to do massive NMU's. How many open bugs have we, more then 7000? This must be down to ~1000. Thanks, Hartmut
Re: Release Plans (1999-05-10)
The best list is [EMAIL PROTECTED] The main problem we are facing is our official 2.2.x kernels are huge, and there's no way to put the kernel and the root.bin image on a single floppy. The proposed solution is building a modularized kernel, and loading the needed modules using an initrd image, but AFAICT, there's nobody working on that. What about the ramdisk/root.bin (and then also for the netboot-ramdisk)? They are also very huge now. Floppies with 1.7MB isn't good ... Regards, Hartmut
Re: Release Plans (1999-05-10)
There's also another thing that need to be worked on, the CDs. The script creating the images is not smart enough to select just the good number of packages for each CDs. Currently, the two binary CDs can still be generated for potato but not the source images (they are too big). And many dependencies on the first CD are not met. For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs).
