release status update
I wrote: > We're still on track for release on the 15th. Here's a schedule up to > then: > > March 3rd No changes to libraries past this point. > March 6th Final code changes for i386 enter the archive. > (except new udebs and possibly partman) > March 7th All udebs to be copied from unstable to testing. > First possibly final i386 CDs built; testing. > String freeze begins. > March 10th String feeeze ends. > March 14th Final changes to udebs in archive. > Final image and CD builds. > March 15thRelease. We're about a day behind on this schedule at the moment. The set of udebs in unstable was copied to testing on Saturday, which gives me something to fall back on if changes unexpectedly break something. The March 7th cd images were not final quality, due to some initrd bloating, and some new stuff not getting on in time. It's possible that today or tomorrow's images will be something close to final release quality for i386. The string freeze has not quite started, since a few strings were changed today. Hopefully we've seen the last of that, and at least the translators are doing well, with several languages already at 100% and many > 90%. Also, the alioth move caused some problems. We'll push the end of the string freeze back to the 12th because of this late start. The 14th is still the last day for changes to udebs, and the 13th is a more practical deadline. > Here, again is a checklist for what needs to be done for an architecture > before release: > > 1. CD images builds should be working (if applicable) AFAIK, this is currently true for alpha, hppa, i386, ia64, and powerpc. We need sparc and m68k CDs, I think work is in progress for m68k, but I have heard nothing about sparc. > 2. images must be in debian archive Currently it's a bit of a mess: - i386 is ok - sparc images autobuilt for the first time today. Good job guys! - powerpc continues to build every time w/o fail. - hppa failed to build due to a missing build dep; trying that again. - ia64 failed to build due to external breakage; trying that again. - m68k failed to build due to using the wrong kernel; trying that again. - mips succeeded with the previous version 3 days ago, but has not started/finished the latest version. It would help if more porters could watch http://buildd.debian.org/build.php?arch=&pkg=debian-installer and fix problems as they show up. I appreciate those of you who do. No other arches are being autobuilt at this time. If we want s390 or something to be included in this release, it needs to be added to debian/control ASAP. > 3. at least one successful installation report per boot method I have not had time to track installation reports. Could someone take a pass through the list of recent reports and post a summary to the list please? My vague impressions: - i386 is generally working ok - powerpc is working ok the subarches that worked last time - once again we are almost out of time on including any more powerpc subarches - s390 is working up to partitioning, and that is probably the only serious issue there - m68k is working on amiga - mips ??? haven't seen anything lately - hppa ??? no activity lately, probably won't release - ia64 ??? - sparc is working, mostly. May have some bad debs in testing though. - arm is being worked on, but will not make this release (prove me wrong, please) > Here is a short list of things that need to be done still before release: And an update, as if you can't read the top of TODO yourselves. :-) - partman - testing! - clean up lvmcfg UI issue - probably go for i386, powerpc; other arches unknown - i18n: - bterm-unifont reloading. Bug#232397 - lowmem package must enter archive - Check archive for udebs that need to be built on various arches; make sure everything is up-to-date. Also, make sure that eg, appropriate kernel debs have entered the archive on each architecture. - Write a release announcement. -- see shy jo signature.asc Description: Digital signature
release status update
I've submitted what I hope will be the final debian-installer build to the autobuilders, but it seems that recent dependency breakage in newt will cause some of the builds to fail. I hope I can ask the autobuilders to retry, but this will likely delay things for a few days. At this point it's probably too late to get any changes into udebs in the initrds, and there are probably only a few days left to make changes to other udebs. Any changes will be synced to testing on a per-udeb basis again until we release, so you have to give me a very good reason to put in a change. In the meantime, the daily built images (but still the sid_d-i CDs, not sarge_d-i) are very close to what we will release, so please test them as much as you can, and update installer/doc/checklist. I'm mailing everyone in doc/testers.txt to try to get some broader testing. I still don't know if this release should be called beta5 or rc1, and I think the best way to decide is to see how well it gets tested and how many errata-level problems we find. There is also a DRAFT release announcement in installer/doc. Maybe I forgot some noteworthy features, please check. -- see shy jo signature.asc Description: Digital signature
release status update
Today's the last day of the string freeze, leaving this left in the timeline for release: 23 aprilupload translated udebs to archive 23 aprilwrite release announcement 24 aprillast possible changes to udebs on initrds 25 aprilinitrd builds 26 aprilinitrd builds continue (slow autobuilders) 27 aprilcd building, testing 28 aprilrelease beta 4 I'm trying to track status of various architectures at the top of TODO, here is what I have so far. - s390: FTBFS, still no success installing - hppa: Hangs at discrete points during install, different on different machines, needs to be investigated (bdale). - arm: ? - mips: reported ok - mipsel: looks good - powerpc: need list of working subarches (oldworld?) - ia64: There is a devpts/sysvinit/glibc file conflict of some sort that breaks debootstrap. Need a bug #. (Might be related to #230857) - alpha: still SCSI cd problems? - m68k: need list of working subarches - sparc: need successful install reports from cdrom, both subarches - i386: Broken discover in testing makes installed system problimatic. Needs new discover stuff propigated in. Please let me know of any other issues or corrections. At the moment s390 is looking unlikely to be part of this release, while hppa should be, and arm and mipsel are certian. The most worrying things at the moment are the discover problem, and the file conflict; if testing is not in a releasable state, we can't release d-i. We need to begin doing final testing now, to make sure all arches are working with no regressions. We also need to do better testing of full CD images this time around, not just netinst CDs. A draft release announcement is now in subversion. -- see shy jo signature.asc Description: Digital signature
Re: release status update
On Mon, Mar 08, 2004 at 10:29:28PM -0500, Joey Hess wrote: > > 3. at least one successful installation report per boot method > > I have not had time to track installation reports. Could someone take > a pass through the list of recent reports and post a summary to the list > please? My vague impressions: > > - i386 is generally working ok > - powerpc is working ok the subarches that worked last time > - once again we are almost out of time on including any more powerpc > subarches No, this is not quite exact. chrp, chrp-rs6k and prep will be working this time around, i think everything is there, but i need to fiddle the build system for it still to build the initrd images, but i do this already by hand, and everything is in place for it. This would use the powerpc netboot initrd. the cdrom initrd is too big though, i will not have time to fix the kernel for this, so maybe building a new specialized initrd image with all the apple stuff removed would do, not sure though. The powerpc-small floppy target will probably not be on time. Jeremie is working on the miboot upload, and once that reaches the archive, the build system can be fixed. power3 and power4/G5 kernels and initrd are not yet done, but i will have a go at them this week, so hopefully that will be ok. Kernels for G5 powerpmac have not been tested, despite my call for volunteer, but if they don't work out, 2.6 kernels will be needed. It needs linux-kernel-di support for the modules, which i hear is problematic, and some volunteer to test them. > > Here is a short list of things that need to be done still before release: > > And an update, as if you can't read the top of TODO yourselves. :-) > > - partman > - testing! > - clean up lvmcfg UI issue > - probably go for i386, powerpc; other arches unknown I tested it on powerpc, altough couldn't do much tests. My disk has vital information i cannot afford to loose. More to this in a separate mail. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
On Mon, Mar 08, 2004 at 10:29:28PM -0500, Joey Hess wrote: [...] > The string freeze has not quite started, since a few strings were > changed today. Hopefully we've seen the last of that I also just rewrote most of the strings for the cdebconf text frontend. They should certainly be reviewed by a native English speaker though, one only has to commit changes in cdebconf-text-udeb.templates as usual, and I will patch source files accordingly. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
Sven Luther wrote: > chrp, chrp-rs6k and prep will be working this time around, i think > everything is there, but i need to fiddle the build system for it still > to build the initrd images, but i do this already by hand, and > everything is in place for it. This would use the powerpc netboot > initrd. > > the cdrom initrd is too big though, i will not have time to fix the > kernel for this, so maybe building a new specialized initrd image with > all the apple stuff removed would do, not sure though. > > The powerpc-small floppy target will probably not be on time. Jeremie is > working on the miboot upload, and once that reaches the archive, the > build system can be fixed. > > power3 and power4/G5 kernels and initrd are not yet done, but i will > have a go at them this week, so hopefully that will be ok. Kernels for > G5 powerpmac have not been tested, despite my call for volunteer, but if > they don't work out, 2.6 kernels will be needed. > > It needs linux-kernel-di support for the modules, which i hear is > problematic, and some volunteer to test them. Unless I see patches in the archive in the next day or two for the above, I can't imagine you'll make it. -- see shy jo signature.asc Description: Digital signature
Re: release status update
On Thu, Jul 29, 2004 at 03:11:11PM -0400, Joey Hess wrote:
> I've submitted what I hope will be the final debian-installer build to the
> autobuilders, but it seems that recent dependency breakage in newt will
> cause some of the builds to fail. I hope I can ask the autobuilders to
> retry, but this will likely delay things for a few days.
>
> At this point it's probably too late to get any changes into udebs in
> the initrds, and there are probably only a few days left to make changes
> to other udebs. Any changes will be synced to testing on a per-udeb
> basis again until we release, so you have to give me a very good reason
> to put in a change.
Please consider including the base-installer 1.01 and the nobootloader 0.17
.udebs i uploaded today. The 1.01 base-installer include a nicer way to handle
powerpc kernels with builtin initrd, and also makes sure that kernel upgraded
after the install will be functional.
The nobootloader change include giving exacter booting instructions for the
powerpc/chrp_pegasos (a thing which could be cloned for other arches without
boot loader but with known boot procedures), as well as add the logic for the
generic case. Ideally, a string change would be needed to tell the user about
the partition in which to find the kernel in the generic case, but this can
wait for after the beta5/rc1 release, but it would look nicer. The string
change is not a sever one though, just adding "on partition ${BOOT}" in the
boot instruction to know where the kernel is.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
On Thu, Apr 22, 2004 at 12:55:06PM -0400, Joey Hess wrote: > - m68k: need list of working subarches mac and amiga are fully supported. I hope to have support for the rest in the next couple of weeks or so, but if they aren't ready for release, so be it. -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: release status update
* Joey Hess <[EMAIL PROTECTED]> [2004-04-22 12:55]: > - mipsel: looks good I just did a successful installation on a DECstation 5000/133 via the serial console. Everything worked fine, apart from one thing: both colo-installer and delo-installer got loaded, and colo-installer was executed instead of delo-installer. I have no idea why colo-installer was loaded since it has a different sub-architecture (however, iirc, delo-installer is also loaded on Cobalt, so I assume sub-arch handling is broken). p2 said that bogl crashes when he tries a DECstation install with a video card, but it worked for Karsten recently. I asked Karsten to see if it works for him. In any case, d-i definitely works on DECstation via the serial console and is ready for beta4. That is, mipsel/r3k-kn02 and mipsel/r4k-kn04 (DECstation with R3000 and R4000 CPUs). mipsel/cobalt also works. The only problem is that you (currently) need an existing Linux installation in order to boot d-i. This will be fixed after beta4 (I'm waiting for the upstream author of colo to implement net booting). Apart from this, Cobalt installations work. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
* Joey Hess <[EMAIL PROTECTED]> [2004-04-22 12:55]: > I'm trying to track status of various architectures at the top of TODO, > here is what I have so far. > > - arm: ? arm/netwinder most definitely works. It worked recently and there is afaict nothing that broke it in the meantime. arm/bast and arm/riscstation probably work as well. I hope I can do a test on arm/netwinder tomorrow to confirm. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
Martin Michlmayr wrote: > I just did a successful installation on a DECstation 5000/133 via the > serial console. Everything worked fine, apart from one thing: both > colo-installer and delo-installer got loaded, and colo-installer was > executed instead of delo-installer. I have no idea why colo-installer > was loaded since it has a different sub-architecture (however, iirc, > delo-installer is also loaded on Cobalt, so I assume sub-arch handling > is broken). Argh, not again. libdebian-installer 0.22 went into the archive today with some fixes for subarch handling, in particular #243692. Was that version on your image? -- see shy jo signature.asc Description: Digital signature
Re: release status update
* Joey Hess <[EMAIL PROTECTED]> [2004-04-22 22:15]: > > was loaded since it has a different sub-architecture (however, iirc, > > delo-installer is also loaded on Cobalt, so I assume sub-arch handling > > is broken). > > Argh, not again. libdebian-installer 0.22 went into the archive today > with some fixes for subarch handling, in particular #243692. Was that > version on your image? No, I had 0.21.1. I'll test with 0.22 tonight; thanks for pointing this out. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
* tbm <[EMAIL PROTECTED]> [2004-04-23 01:43]: > > - arm: ? > > arm/netwinder most definitely works. It worked recently and there is It works; the only problem I had was that the wrong kernel was installed. For some reason, debian-installer/kernel/subarchitecture was not set. Unfortunately, I cannot quite figure out why. (I just tried on mipsel and it definitely gets set there.) -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
Martin Michlmayr wrote: > * tbm <[EMAIL PROTECTED]> [2004-04-23 01:43]: > > > - arm: ? > > > > arm/netwinder most definitely works. It worked recently and there is > > It works; the only problem I had was that the wrong kernel was > installed. For some reason, debian-installer/kernel/subarchitecture > was not set. Unfortunately, I cannot quite figure out why. (I just > tried on mipsel and it definitely gets set there.) Does archdetect show the correct output for netwinder? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
* Thiemo Seufer <[EMAIL PROTECTED]> [2004-04-23 16:32]: > Does archdetect show the correct output for netwinder? Yes. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
* Joey Hess <[EMAIL PROTECTED]> [2004-04-22 22:15]: > Argh, not again. libdebian-installer 0.22 went into the archive today > with some fixes for subarch handling, in particular #243692. Was that > version on your image? I tried it with 0.22 now and still see the same... it's quite strange. Just for reference: colo-installer is for mipsel/cobalt while delo-installer is for mipsel/r3k-kn02 and mipsel/r4k-kn04. On mipsel/r3k-kn02, it installs colo-installer and delo-installer, but on mipsel/cobalt it only installs colo-installer. Looking at the logs, I get this on mipsel/r3k-kn02 (egrep -n "(colo|delo)-install" syslog): 396:Apr 23 18:30:52 (none) user.debug anna[825]: DEBUG: install delo-installer, priority >= standard 452:Apr 23 18:30:53 (none) user.debug anna[825]: DEBUG: search for package resolving kernel-installer, dependency from delo-installer 453:Apr 23 18:30:53 (none) user.debug anna[825]: DEBUG: install di-utils-mapdevfs, dependency from delo-installer 482:Apr 23 18:30:53 (none) user.debug anna[825]: DEBUG: install colo-installer, dependency from prebaseconfig 498:Apr 23 18:30:53 (none) user.debug anna[825]: DEBUG: search for package resolving kernel-installer, dependency from colo-installer 499:Apr 23 18:30:53 (none) user.debug anna[825]: DEBUG: install di-utils-mapdevfs, dependency from colo-installer 566:Apr 23 18:34:30 (none) user.debug main-menu[145]: DEBUG: search for package resolving kernel-installer, dependency from colo-installer 569:Apr 23 18:34:30 (none) user.info main-menu[145]: INFO: Falling back to the package description for colo-installer ... On mipsel/cobalt, I get: 417:Jan 1 00:01:09 (none) user.debug anna[924]: DEBUG: install colo-installer, priority >= standard 487:Jan 1 00:01:09 (none) user.debug anna[924]: DEBUG: search for package resolving kernel-installer, dependency from colo-installer 488:Jan 1 00:01:09 (none) user.debug anna[924]: DEBUG: install di-utils-mapdevfs, dependency from colo-installer 531:Jan 1 00:01:09 (none) user.debug anna[924]: DEBUG: search for package resolving kernel-installer, dependency from colo-installer 532:Jan 1 00:01:09 (none) user.debug anna[924]: DEBUG: install di-utils-mapdevfs, dependency from colo-installer 596:Jan 1 00:02:26 (none) user.debug main-menu[143]: DEBUG: search for package resolving kernel-installer, dependency from colo-installer 599:Jan 1 00:02:26 (none) user.info main-menu[143]: INFO: Falling back to the package description for colo-installer 667:Jan 1 00:02:44 (none) user.debug main-menu[143]: DEBUG: search for package resolving kernel-installer, dependency from colo-installer ... AFAICT, the packages are done properly: Package: delo-installer Version: 0.003 Section: debian-installer Priority: standard Architecture: mipsel Depends: cdebconf-udeb, kernel-installer, di-utils-mapdevfs Provides: bootable-system Installed-Size: 44 Maintainer: Debian Install System Team <[EMAIL PROTECTED]> Description: Install Delo on a hard disk This udeb will install Delo on the hard disk. installer-menu-item: 73 subarchitecture: r3k-kn02 r4k-kn04 and: Package: colo-installer Version: 0.02 Section: debian-installer Priority: standard Architecture: mipsel Depends: cdebconf-udeb, kernel-installer, di-utils-mapdevfs Provides: bootable-system Installed-Size: 24 Maintainer: Debian Install System Team <[EMAIL PROTECTED]> Description: Install the Cobalt boot loader on your disk This udeb will install the Cobalt loader colo on your hard disk. installer-menu-item: 73 subarchitecture: cobalt Any idea what's going on? -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
On Thu, Apr 22, 2004 at 12:55:06PM -0400, Joey Hess wrote: > I'm trying to track status of various architectures at the top of TODO, > here is what I have so far. > - ia64: There is a devpts/sysvinit/glibc file conflict of some > sort that breaks debootstrap. Need a bug #. (Might be > related to #230857) This is bug #238963, which also affects alpha; it has been (hopefully) fixed by the recent -12 upload of glibc, which is currently in unstable but not in testing. > - alpha: still SCSI cd problems? I've just seen that this is fixed in version 2.4.25-3 of the kernel-image-2.4.25-1-generic package. I can do a rebuild of the d-i kernel package this evening (~3hrs), or if anyone else is willing and able to get this uploaded sooner, feel free. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: release status update
On Thu, Apr 22, 2004 at 12:55:06PM -0400, Joey Hess wrote: > - alpha: still SCSI cd problems? > Please let me know of any other issues or corrections. Other major issues on alpha, both apparently kernel related: - qlogicisp driver doesn't work right with many (most?) SCSI cards; bug #238593 et al. - both the de4x5 and the tulip drivers fail to work with many DECChip-based ethernet cards in the 2.4.2x series alpha kernels; bug #228654. Both of these may be related to bugs in general PCI support (particularly relating to PCI bridges), and may already be fixed in 2.6. Unfortunately, I have no experience yet with 2.6 -- if I find that it fixes these problems on my hardware, I may try to put together a 2.6 d-i variant for alpha in time for beta5. It also seems fairly certain that the netboot images don't work on alpha (unless they were fixed while I wasn't looking). I don't seem to have a way to test these anyway, as telling SRM to boot from ethernet generates no network traffic here. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: release status update
Steve Langasek wrote: > - qlogicisp driver doesn't work right with many (most?) SCSI cards; > bug #238593 et al. > - both the de4x5 and the tulip drivers fail to work with many > DECChip-based ethernet cards in the 2.4.2x series alpha kernels; > bug #228654. Both of these sound like reasonable candidates for errata if they're not fixed, and not release blockers. Do you want them in the errata? > It also seems fairly certain that the netboot images don't work on alpha > (unless they were fixed while I wasn't looking). I don't seem to have a > way to test these anyway, as telling SRM to boot from ethernet generates > no network traffic here. Right, I see that's marked as being nonfunctonal on the ports status page. -- see shy jo signature.asc Description: Digital signature
Re: release status update
> > - both the de4x5 and the tulip drivers fail to work with many > > DECChip-based ethernet cards in the 2.4.2x series alpha kernels; > > bug #228654. > Both of these sound like reasonable candidates for errata if they're not > fixed, and not release blockers. Do you want them in the errata? does this bug affect the onboard tulip ethernet that comes with most of the alpha hardware? if so, its a real bad bug. elijah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
On Sat, Apr 24, 2004 at 12:54:18PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > - qlogicisp driver doesn't work right with many (most?) SCSI cards; > > bug #238593 et al. > > - both the de4x5 and the tulip drivers fail to work with many > > DECChip-based ethernet cards in the 2.4.2x series alpha kernels; > > bug #228654. > Both of these sound like reasonable candidates for errata if they're not > fixed, and not release blockers. Do you want them in the errata? Yes, please. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: release status update
On Sat, Apr 24, 2004 at 12:16:44PM -0500, elijah wright wrote: > > > - both the de4x5 and the tulip drivers fail to work with many > > > DECChip-based ethernet cards in the 2.4.2x series alpha kernels; > > > bug #228654. > > Both of these sound like reasonable candidates for errata if they're not > > fixed, and not release blockers. Do you want them in the errata? > does this bug affect the onboard tulip ethernet that comes with most of > the alpha hardware? if so, its a real bad bug. It affects many (I don't know if we can say most) onboard tulip chips that came with alphas. There are actually a wide range of chips covered by the tulip and de4x5 drivers that were distributed by Digital; I don't know yet if there's a clear pattern of which chips are affected, or if the problem has more to do with the associated hardware (such as PCI configuration and chipsets). It is a very bad bug, but I don't know that it's feasible to do much about it in the 2.4 kernel series in time for sarge. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: release status update
Il gio, 2004-04-22 alle 18:55, Joey Hess ha scritto: [...] > - powerpc: need list of working subarches (oldworld?) I would like to have powerpc release only after having kernel-image-2.4.25-powerpc-* version 2.4.25-8 in testing because of #245012. A second problem I understand only now is that the powerpc discover we have in testing now is broken: every time I switch on my laptop (powerbook g4, 15", 867Mhz) it hangs when discover run and probe for parallel port devices. This means that I have to press the keyboard combination to reset the machine. The problem appear *only* when the machine is powered on, and it's not appearing when I reboot it. When it hangs, the keyboard isn't working and the led (the only one this machine has) is on. Now I am upgrading the machine and it is downloading the new discover 2.0.4-3 with discover-data 2.2004.04.09-1, so this might be changed. I will let you know. Bye, Giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
[Giuseppe Sacco] > A second problem I understand only now is that the powerpc discover > we have in testing now is broken: every time I switch on my laptop > (powerbook g4, 15", 867Mhz) it hangs when discover run and probe for > parallel port devices. This means that I have to press the keyboard > combination to reset the machine. I believe this is fixed in the version of discover1 that went into sarge last night. Discover was instructed to not probe paralell and serial ports at boot time, but there was a bug making it ignore this instruction. Please test if this is fixed or not, and add info to bug #237603 (and possibly #214790). > Now I am upgrading the machine and it is downloading the new > discover 2.0.4-3 with discover-data 2.2004.04.09-1, so this might be > changed. I will let you know. I do not know if this is fixed in version 2 of discover. I suspect it is not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update
Giuseppe Sacco wrote: > I would like to have powerpc release only after having > kernel-image-2.4.25-powerpc-* version 2.4.25-8 in testing > because of #245012. If I'm expanding yuor wildcard correctly, they seem to go in tonight/tomorrow. Anyway, you have several days to get them in, but this does not feel like a release blocker to me if they do not make it. -- see shy jo signature.asc Description: Digital signature
Bug#237603: release status update
I just upgraded to discover 2.0.4-3 with discover-data 2.2004.04.09-1 and it seems that the problem is fixed. Bye, Giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release status update (grub notes)
> - lowmem package must enter archive > - Check archive for udebs that need to be built on various arches; >make sure everything is up-to-date. Also, make sure that eg, >appropriate kernel debs have entered the archive on each >architecture. one thing I noticed with a recent daily build (March 3 I believe is that the GRUB installer does NOT seem to offer the option of putting in other bootable entries, much like the lilo installer in woody would offer the user > - Write a release announcement. > > -- > see shy jo > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Etch Beta 3 release - status update
On Thursday 22 June 2006 22:29, Frans Pop wrote: > I will post a more detailed release plan as soon as it is clear when > the 2.6.16 kernel packages will migrate to testing. Some information > about Beta 3 is already available from [1]. As this has not yet happened, there is no real progress on the release, although a lot of general preparation has been done. There is some activity to resolve the issues around 2.6.16, but there is also a real chance that the migration will not happen and that we will have to cancel Beta 3. pgpiX6EqLhWHG.pgp Description: PGP signature
Re: Etch Beta 3 release - status update
Quoting Frans Pop ([EMAIL PROTECTED]): > There is some activity to resolve the issues around 2.6.16, but there is > also a real chance that the migration will not happen and that we will > have to cancel Beta 3. Does this mean that Etch would be released with 2.6.15? Or cancelling Beta3 is more postponing it? I suspect an issue that could affect the whole release process. Am I wrong? -- signature.asc Description: Digital signature
Re: Etch Beta 3 release - status update
On Friday 07 July 2006 00:01, Frans Pop wrote: > On Thursday 22 June 2006 22:29, Frans Pop wrote: > > I will post a more detailed release plan as soon as it is clear when > > the 2.6.16 kernel packages will migrate to testing. Some information > > about Beta 3 is already available from [1]. > > As this has not yet happened, there is no real progress on the release, > although a lot of general preparation has been done. > > There is some activity to resolve the issues around 2.6.16, but there > is also a real chance that the migration will not happen and that we > will have to cancel Beta 3. I'm a bit more positive although things are still moving slowly. There is now a new source package that provides the needed kernel meta packages waiting in NEW for testing-proposed-updates. A further delay will be caused by the two major kernel security issues published this week which means a new linux-2.6.16 is needed. We will need to also update the kernel udebs after that. I still intend to post a more detailed release plan when the kernel is ready to migrate. As the past month has shown, it is useless to do so before that time. Cheers, FJP pgpC5myFdnXCT.pgp Description: PGP signature
discover on powerbook [was: Re: release status update]
Il dom, 2004-04-25 alle 00:13, Petter Reinholdtsen ha scritto: > [Giuseppe Sacco] > > A second problem I understand only now is that the powerpc discover > > we have in testing now is broken: every time I switch on my laptop > > (powerbook g4, 15", 867Mhz) it hangs when discover run and probe for > > parallel port devices. This means that I have to press the keyboard > > combination to reset the machine. > > I believe this is fixed in the version of discover1 that went into > sarge last night. Discover was instructed to not probe paralell and > serial ports at boot time, but there was a bug making it ignore this > instruction. Please test if this is fixed or not, and add info to bug > #237603 (and possibly #214790). > > > Now I am upgrading the machine and it is downloading the new > > discover 2.0.4-3 with discover-data 2.2004.04.09-1, so this might be > > changed. I will let you know. > > I do not know if this is fixed in version 2 of discover. I suspect it > is not. the upgrade was from testing 2004-04-17 to 2004-04-24 and discover changed from 1.5-2 to 2.0.4-3. The problem seems fixed, but I only tried once. I will do some more tests and I'll update the bug reports. Bye, Giuseppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
