Re: D-I - Hint requests for RC1
On Monday 16 October 2006 19:14, Frans Pop wrote: Open season for udeb hints again... The list below is the major migration in preparation for RC1. General request to RMs: please do not hint any packages with udebs from now on without checking with me. Thanks, FJP pgpKOUJTZPno5.pgp Description: PGP signature
D-I RC1 - release planning - soft freeze for changes in SVN
Things are finally starting to come together for RC1. - We've found a good work-around for the bug in g-i where selected lines in multi-select lists would not be shown. We need new versions of some gtk packages for that, but these have now been uploaded. Thanks especially to Loïc Minier for his fast packaging work! - The last important open TODO items were done during the past week: - 2.6 floppy support for i386 - partman-auto-raid (only through preseeding) We currently still have some blocking bugs: - regression in the progress bar in the newt frontend (#391676) - incorrect display for CJK languages (newt/slang: #392942/392987) - keyboard support on mips SGI Indigo2 (#382983) - floppies too big for powerpc (should be possible to resolve using new infrastructure by Sylvain Ferriol) The release preparation page on the wiki [1] is mostly up-to-date with regards to issues and TODO items before the release. The page also lists the changes implemented since Beta 3 which will be used as basis for the release notes; let me know if you miss items. Soft freeze for commits === We should now stop making structural changes in the installer, but bug fixing is still possible. If you have doubts if a commit is OK, please contact me. Also, please contact me before uploading if you have any doubts. Please start testing the installer for all architectures NOW All udebs with functional changes have now been uploaded, so this is an excellent time to test different architectures using *daily* images! We can now still make changes. Please don't wait until the last moment to test and find out there are architecture specific issues. Release planning The schedule was becoming too complex as there are two sets of migrations to testing: an initial one for current state and a final one with fixes and translation updates. I have therefore split it into two separate and partially overlapping schedules. It is also somewhat optimistic, so some slippage is likely. If there is slippage, is is likely to be a full week. If we switch to 2.6.18 before RC1, that will also likely cause a weeks delay. I have not planned very long periods for testing. I'd rather use RC1 itself for extensive testing and fix remaining issues in RC2. INITIAL UPLOAD -- NowString freeze; soft freeze for commits, bug fixing OK 16Oct Start migrating current udebs to testing 16-22 Oct Architecture tests based on daily images; fix where needed !!! 20/21 Oct First upload of debian-installer 21/22 Oct Implement necessary changes in debian-cd 25Oct Weekly full CD build for new installer 26-29 Oct Testing and fixes for full CDs FINAL UPLOAD 22Oct End of string freeze; full freeze for udebs 23Oct Upload all udebs with translation updates or pending changes 25/26 Oct Most udebs should have migrated to testing 26Oct Final build and upload of d-i 27Oct Switch daily links to etch_d-i 27-30 Oct Final testing using daily images 30Oct Weekly full CD build 1- 4 Nov Further testing 1- 4 Nov Preparation of release notes, errata, etc. 5Nov Migration of d-i to testing 3/ 4 Nov CD builds 5Nov Release P.S. I have accepted an invitation to participate in a workshop to develop a customized installer/distribution in Bhutan (thanks to Christian). I will be gone from 5-22 November, but will still be able to work on release issues part-time while there. [1] http://wiki.debian.org/DebianInstaller/EtchRC1Prep pgpZKGV6XaQvS.pgp Description: PGP signature
D-I - Hint requests for RC1
Hi folks, Open season for udeb hints again... The list below is the major migration in preparation for RC1. I will follow up with some more specific migrations, especially for the graphical installer. These may need some urgent hints. TIA, FJP Hints to be set by Release Managers --- unblock libdebian-installer/0.45 unblock os-prober/1.14 unblock user-setup/1.6 unblock atk1.0/1.12.3-1 unblock cdebootstrap/0.3.13 unblock console-data/2:1.0-5 unblock glib2.0/2.12.4-1 unblock nano/1.9.99pre2-1 unblock openssh/1:4.3p2-5 unblock reiser4progs/1.0.5-2 # Too young, but should go with rest of release # Last upload was trivial dependency fix unblock installation-report/2.20 urgent installation-report/2.20 # These are currently too young, but safe to migrate when aged unblock libsdl1.2/1.2.11-4 unblock loop-aes-utils/2.12r-14 Udebs to be migrated by Jeroen -- Note: this needs to wait until libdebian-installer from list above can be migrated too. linux-kernel-di-alpha-2.6 linux-kernel-di-amd64-2.6 linux-kernel-di-arm-2.6 linux-kernel-di-hppa-2.6 linux-kernel-di-i386-2.6 linux-kernel-di-ia64-2.6 linux-kernel-di-m68k-2.6 linux-kernel-di-mips-2.6 linux-kernel-di-mipsel-2.6 linux-kernel-di-powerpc-2.6 linux-kernel-di-s390-2.6 linux-kernel-di-sparc-2.6 linux-modules-di-alpha-2.6 linux-modules-di-amd64-2.6 linux-modules-di-arm-2.6 linux-modules-di-hppa-2.6 linux-modules-di-i386-2.6 linux-modules-di-ia64-2.6 linux-modules-di-mipsel-2.6 linux-modules-di-powerpc-2.6 linux-modules-di-sparc-2.6 debian-installer-utils apt-setup auto-install autopartkit base-installer cdrom-checker cdrom-detect choose-mirror clock-setup hw-detect iso-scan kbd-chooser lilo-installer lowmem lvmcfg main-menu mdcfg mountfloppy netcfg network-console nobootloader partconf pkgsel preseed rescue tzsetup flash-kernel glantank oldsys-preseed pgpmVh4tpdblr.pgp Description: PGP signature
Re: D-I - Hint requests for RC1
On Monday 16 October 2006 19:42, Stephen Gran wrote: Just since I saw this flying by me - I just uploaded a new hdparm (6.8-1) - there's no urgency for it to go in, but would it be a problem for it to migrate when it's ready? No, I will request migration for all packages producing udebs almost automatically when they are old enough and if there are no RC issues. It's just that I want to avoid unexpected (for me) migrations. Hmm. I even see that I missed it in my original mail; at 9 days old hdparm could go in tomorrow. Please add: unblock hdparm/6.7-1 pgpQq30utHbYG.pgp Description: PGP signature
Re: Bug#363377: Raise severity
retitle 363377 Inform users that HostAP is merged in recent kernels thanks control Hi, Moritz Muehlenhoff wrote: Etch will only ship a 2.6.18 kernel, please update have it. This bug isn't actually a FTBFS, since hostap-source isn't needed in recent kernels. The driver was merged in mainline 2.6.14 and the package exists to serve users of older kernels. It definitely should be kept out of testing (CCing release team) and it should be noted (in the package description and in the build log) that users don't have to build the modules anymore. Release team, could you add a hint so we don't have to keep this bug open to keep the package out of testing? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please hint tetex-base into testing
Hi, currently, tetex-base is not going into testing because it has RC bugs, and britney believes the number of RC bugs is equal in testing and sid. This is technically true, however, all the RC bugs that have a etch-ignore tag also have a part that actually is RC, and which has been fixed in versions 3.0.dfsg.1-1 or 3.0.dfsg.2-1 (and thus are unfixed in etch). The only non-etch-ignore RC bug is present in both distributions. Therefore etch would be much better if the current sid version migrated soon. An upload to fix the remaining RC bug is in preparation, but creation and check-in of a new upstream tarball requires that I have some calm time to work on that, so it might take two or three days more. Thanks in advance, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Sun, 17 Sep 2006, Steve Langasek wrote: buildds: 19 There are 19 buildds actively uploading packages for m68k (Aug 20 to present). This indicates that individual buildds are roughly an order of magnitude slower than those for other architectures, which makes m68k a limiting factor for time-critical builds such as security updates. So with three months remaining until the scheduled release of etch, the release team does not believe it's possible for m68k to close the gap on these issues. This will always be a killer argument against supporting slower ports. :-( As a result, the bts is already ignoring m68k in calculating a bug's applicability for the testing distribution, at the release team's request. As someone who has recently looked at and fixed many problems, I must say the release team has done m68k no service by doing this and actually sabotaged m68k in its ability to catch up again. Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. It's one thing to expect from m68k not to hold up other ports, but it's a different thing to take from m68k the means to catch up again. We have also asked about removing m68k from testing since it is not currently a release candidate; Anthony Towns has indicated his preference to defer this until another solution can be implemented for m68k's needs. This raises the question again of what such a structure should look like; I think it would be a good idea for us to begin to tackle this question, so that the m68k team might, e.g., be able to do their own partial release for etch similar to what amd64 did for sarge. So the situation is now that m68k gets kicked out without no alternative in place? Once the current building frenzy calms down, the situation shouldn't look too bad and if bugs for which fixes exists in the BTS where actually fixed, m68k could be released with just a few packages less. Not releasing m68k could have far worse consequences and should be absolutely the last resort, e.g. it makes it difficult to upgrade between stable releases, which might become a real issue, as m68k is likely to need an ABI change for TLS support. What are the alternatives for m68k _now_? To me it looks like the release team is expecting a miracle. It's a fact that m68k is a slow port and as long as the release team is insisting on fixing this, m68k is doomed. :-( bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote: As a result, the bts is already ignoring m68k in calculating a bug's applicability for the testing distribution, at the release team's request. As someone who has recently looked at and fixed many problems, I must say the release team has done m68k no service by doing this and actually sabotaged m68k in its ability to catch up again. Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. I suggest you read section 5.10 of the developers reference, and do porter/non-maintainer source uploads if you think it's holding up things and the maintainer isn't very responsive. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel [EMAIL PROTECTED] writes: Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. Does this explain why guile-1.6 is still not compiled for m68k? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: remove kernel-patch-lkcd
On Mon, Oct 16, 2006 at 09:57:40AM -0600, Troy Heber wrote: Please remove kernel-patch-lkcd from unstable, it is unused and will not apply to the 2.6.18 kernel (Bug#393286). I'm also CC'ing debian-release to request the removal from testing as well. Tagged for removal from testing. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I - Hint requests for RC1
On Mon, Oct 16, 2006 at 07:30:35PM +0200, Frans Pop wrote: On Monday 16 October 2006 19:14, Frans Pop wrote: Open season for udeb hints again... The list below is the major migration in preparation for RC1. General request to RMs: please do not hint any packages with udebs from now on without checking with me. Acked for my part. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363377: Raise severity
On Mon, Oct 16, 2006 at 09:46:40PM +0300, Faidon Liambotis wrote: Moritz Muehlenhoff wrote: Etch will only ship a 2.6.18 kernel, please update have it. This bug isn't actually a FTBFS, since hostap-source isn't needed in recent kernels. The driver was merged in mainline 2.6.14 and the package exists to serve users of older kernels. It definitely should be kept out of testing (CCing release team) and it should be noted (in the package description and in the build log) that users don't have to build the modules anymore. Release team, could you add a hint so we don't have to keep this bug open to keep the package out of testing? Tagged for removal. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
permission to upload mdadm 2.5.5
mdadm upstream is releasing 2.5.5 really soon now, and it fixes #393314 (FTBFS on sparc/ia64/arm). I've closely cooperated on both 2.5.4 and 2.5.5. All patches between 2.5.3 (which is currently in testing) and 2.5.5 are true bug fixes and no drastic changes have been introduced which would affect the use of mdadm by d-i. I would like to see 2.5.5 in etch. Do I have permission to upload? (I am specifically asking because with the 2.5.4-1 upload I kind of violated the rules)... Cheers, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems logik ist analsadismus: gedanken werden gewaltsam durch einen engen gang gepreßt. -- frei nach lacan signature.asc Description: Digital signature (GPG/PGP)
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: Roman Zippel [EMAIL PROTECTED] writes: Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. Does this explain why guile-1.6 is still not compiled for m68k? I'm not sure what you intent with this question. The patch is not that old yet, but it's there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905 bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel [EMAIL PROTECTED] writes: On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: Roman Zippel [EMAIL PROTECTED] writes: Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. Does this explain why guile-1.6 is still not compiled for m68k? I'm not sure what you intent with this question. The patch is not that old yet, but it's there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905 Wow, that's rich. The patch was posted to the bug log all of THIRTY MINUTES before your message here, and AFTER my email. So this nonsense of fixes are just stuck in the BTS is still nonsense. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel [EMAIL PROTECTED] writes: On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: I'm not sure what you intent with this question. The patch is not that old yet, but it's there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905 Wow, that's rich. The patch was posted to the bug log all of THIRTY MINUTES before your message here, and AFTER my email. So this nonsense of fixes are just stuck in the BTS is still nonsense. Look closer, so your whole intention was to distract from the real issues and just insult whose who want to help? Indeed, that's rich. :-( You claimed that it's a bad idea to drop m68k as a release candidate, because the only way bugs will get fixed is if maintainers are forced to include patches. In fact, the one m68k porting problem that affects packages I am concerned with has lied dormant for a year, until today. Your message was deliberately misleading, designed to suggest that there had been a fix in for a while (even if not that old yet), when in fact, the patch was posted *after* my message. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Mon, Oct 16, 2006 at 10:57:00PM +0200, Kurt Roeckx wrote: On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote: As a result, the bts is already ignoring m68k in calculating a bug's applicability for the testing distribution, at the release team's request. As someone who has recently looked at and fixed many problems, I must say the release team has done m68k no service by doing this and actually sabotaged m68k in its ability to catch up again. Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. I suggest you read section 5.10 of the developers reference, and do porter/non-maintainer source uploads if you think it's holding up things and the maintainer isn't very responsive. Would the 0 day NMU policy apply to m68k specific bugs ? At least this would allow porter/non-maintainer source uploads. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel [EMAIL PROTECTED] writes: Your message was deliberately misleading, designed to suggest that there had been a fix in for a while (even if not that old yet), when in fact, the patch was posted *after* my message. What the hell is your problem? Yes, the patch is _one_ day old and instead of thanking me for finally fixing this problem, I get this? I have no idea if you have fixed the problem or not; I'm not the package maintainer and I haven't examined the patch. But you attempted to trick people, by pretending that the patch was already there before my email. You wanted to make me look bad, as if I was bringing up an example where there was a patch in the bug-log. Since your claim is that m68k suffers because maintainers ignore patches in the bug logs, you concocted an example right away. Your message gave no hint that you in fact posted the patch in *response* to my message, and indeed, since you're trying to blame maintainers for ignoring m68k patches, it fits right in line with your general attack to concoct just such a case, when in fact, the opposite was the case. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote: Hi, On Sun, 17 Sep 2006, Steve Langasek wrote: buildds: 19 There are 19 buildds actively uploading packages for m68k (Aug 20 to present). This indicates that individual buildds are roughly an order of magnitude slower than those for other architectures, which makes m68k a limiting factor for time-critical builds such as security updates. So with three months remaining until the scheduled release of etch, the release team does not believe it's possible for m68k to close the gap on these issues. s/release team/release-minus-m68k team/ then. This will always be a killer argument against supporting slower ports. :-( We could build packages on eight aranym instances running on amd64 octocores with 24Gb of RAM. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Bill Allombert wrote: On Mon, Oct 16, 2006 at 10:57:00PM +0200, Kurt Roeckx wrote: On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote: As a result, the bts is already ignoring m68k in calculating a bug's applicability for the testing distribution, at the release team's request. As someone who has recently looked at and fixed many problems, I must say the release team has done m68k no service by doing this and actually sabotaged m68k in its ability to catch up again. Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. I suggest you read section 5.10 of the developers reference, and do porter/non-maintainer source uploads if you think it's holding up things and the maintainer isn't very responsive. Would the 0 day NMU policy apply to m68k specific bugs ? At least this would allow porter/non-maintainer source uploads. FWIW, a 10 day NMU policy allows this too. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Roman Zippel [EMAIL PROTECTED] writes: was your initial phrase 'Please let the release team know how we can be of assistance to you in setting and meeting goals for an m68k release' just a hollow phrase... I never said anything of the kind. If the m68k team can make the port happen without messing up the rest of Debian, great. But from my perspective the huge delays on the autobuilders are a disaster. Without actually fixing this, we cannot permit an architecture that is unable to keep up with autobuilds to slow everything else down. For example, the inattention of the porting team to the guile-1.6 bug means that gnucash is at 2.0.2 on every architecture except m68k, where it is version *1.8.10*. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Mon, Oct 16, 2006 at 04:20:56PM -0700, Thomas Bushnell BSG wrote: Roman Zippel [EMAIL PROTECTED] writes: On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: Roman Zippel [EMAIL PROTECTED] writes: Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. Does this explain why guile-1.6 is still not compiled for m68k? I'm not sure what you intent with this question. The patch is not that old yet, but it's there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905 Wow, that's rich. The patch was posted to the bug log all of THIRTY MINUTES before your message here, and AFTER my email. Thirty minutes to fix that bug ? Roman you rock! So this nonsense of fixes are just stuck in the BTS is still nonsense. You did not ask Roman to provide examples of fixes are just stuck in the BTS, you picked your own bug and then complains it is not a good example ? Is not that non-sense ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: I'm not sure what you intent with this question. The patch is not that old yet, but it's there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905 Wow, that's rich. The patch was posted to the bug log all of THIRTY MINUTES before your message here, and AFTER my email. So this nonsense of fixes are just stuck in the BTS is still nonsense. Look closer, so your whole intention was to distract from the real issues and just insult whose who want to help? Indeed, that's rich. :-( bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: You claimed that it's a bad idea to drop m68k as a release candidate, because the only way bugs will get fixed is if maintainers are forced to include patches. I didn't say anything about forcing, that's your conclusion. In fact, the one m68k porting problem that affects packages I am concerned with has lied dormant for a year, until today. You pick a single example and draw general conclusions from it and you accuse me of deliberately misleading? Your message was deliberately misleading, designed to suggest that there had been a fix in for a while (even if not that old yet), when in fact, the patch was posted *after* my message. What the hell is your problem? Yes, the patch is _one_ day old and instead of thanking me for finally fixing this problem, I get this? bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: But you attempted to trick people, by pretending that the patch was already there before my email. You wanted to make me look bad, as if I was bringing up an example where there was a patch in the bug-log. Since your claim is that m68k suffers because maintainers ignore patches in the bug logs, you concocted an example right away. You're the one who mentioned guile-1.6, it's not my example. Your message gave no hint that you in fact posted the patch in *response* to my message, and indeed, since you're trying to blame maintainers for ignoring m68k patches, it fits right in line with your general attack to concoct just such a case, when in fact, the opposite was the case. Get your facts straight, I posted the patch _yesterday_ night, _before_ you mentioned it. You're still distracting from the real issue by running a personal attack based on incorrect conclusions. :-( Do you even have any interest in discussing the status of the m68k port or was your initial phrase 'Please let the release team know how we can be of assistance to you in setting and meeting goals for an m68k release' just a hollow phrase, hoping m68k could never fix many of the remaining bugs? I may have missed something, but I haven't seen anything from you, which might indicate something otherwise... bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Hi, On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote: Roman Zippel [EMAIL PROTECTED] writes: was your initial phrase 'Please let the release team know how we can be of assistance to you in setting and meeting goals for an m68k release' just a hollow phrase... I never said anything of the kind. The way you reacted to my mail, I assumed you were part of the release team and were somehow offended by it, I apologize for the confusion. If the m68k team can make the port happen without messing up the rest of Debian, great. But from my perspective the huge delays on the autobuilders are a disaster. Without actually fixing this, we cannot permit an architecture that is unable to keep up with autobuilds to slow everything else down. For example, the inattention of the porting team to the guile-1.6 bug means that gnucash is at 2.0.2 on every architecture except m68k, where it is version *1.8.10*. This could mean as well, that gnucash won't be part of the m68k release, although now that guile is fixed this could look as well quite different. It's still quite a leap in conclusion here to get from problems with a few packages to declaring m68k not releaseable at all. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Mon, Oct 16, 2006 at 10:39:26PM +, Bill Allombert wrote: On Mon, Oct 16, 2006 at 10:57:00PM +0200, Kurt Roeckx wrote: On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote: As a result, the bts is already ignoring m68k in calculating a bug's applicability for the testing distribution, at the release team's request. As someone who has recently looked at and fixed many problems, I must say the release team has done m68k no service by doing this and actually sabotaged m68k in its ability to catch up again. Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. I suggest you read section 5.10 of the developers reference, and do porter/non-maintainer source uploads if you think it's holding up things and the maintainer isn't very responsive. Would the 0 day NMU policy apply to m68k specific bugs ? At least this would allow porter/non-maintainer source uploads. The 0-day NMU policy promulgated by the release team has as its express purpose to improve the release-readiness of testing, so m68k-specific fixes wouldn't be covered by this. But porters are allowed to do NMUs on their own authority, and I know that some porters have done 0-day NMUs when they considered it necessary. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I - Hint requests for RC1
On Mon, Oct 16, 2006 at 07:52:41PM +0200, Frans Pop wrote: On Monday 16 October 2006 19:42, Stephen Gran wrote: Just since I saw this flying by me - I just uploaded a new hdparm (6.8-1) - there's no urgency for it to go in, but would it be a problem for it to migrate when it's ready? No, I will request migration for all packages producing udebs almost automatically when they are old enough and if there are no RC issues. It's just that I want to avoid unexpected (for me) migrations. Hmm. I even see that I missed it in my original mail; at 9 days old hdparm could go in tomorrow. Please add: unblock hdparm/6.7-1 Superseded by a newly-uploaded 6.8-1. Should we assume that one will also be release-worthy in 10 days, or wait and see? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hppa libggi binNMU (was: Bug#390000: libggi-target-aa: empty package on hppa)
On Sun, Oct 08, 2006 at 11:01:37AM +1000, Anibal Monsalve Salazar wrote: Someone please queue the hppa libggi binNMU. Steve McIntyre agrees that a binNMU is needed. Please read #39. Best Regards, Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Bug#390000: libggi-target-aa: empty package on hppa
On Sun, Oct 08, 2006 at 11:01:37AM +1000, Aníbal Monsalve Salazar wrote: Someone please queue the hppa libggi binNMU. On Sun, Oct 08, 2006 at 12:10:19AM +0200, Julien Louis wrote: Package: libggi-target-aa Version: 1:2.2.1-4 Severity: important as seen on packages.debian.org [1], the libggi-target-aa package is empty on hppa. Looking at the build log, the aa target is disabled at configure time: checking aalib.h usability... yes checking aalib.h presence... yes checking for aalib.h... yes checking for aa_autoinit in -laa... no [...] checking if we should build aa target... no Maybe this is an aalib/hppa problem? If the package was supposed to build for aalib, why did the build not fail as soon as it discovered an aalib/hppa problem? The failure of the source package to bail out, instead of building an empty package, is a sourceful bug; could you please upload a sourceful fix for this instead? The bug should really be 'grave' as well, since an empty libggi-target-aa package is certainly unusable. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please hint ltsp 0.99debian5 into etch
please consider hinting ltsp 0.99debian5 into etch, which is (presumably) held up by the ltsp-client-builder udeb. it fixes copyright issues, missing dependencies, and a few other things needed by debian-edu (and possibly other projects). thanks yet again! live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote: It's with some regret that I have to confirm that m68k is not going to be a release architecture for etch. We have also asked about removing m68k from testing since it is not currently a release candidate; Anthony Towns has indicated his preference to defer this until another solution can be implemented for m68k's needs. This raises the question again of what such a structure should look like; I think it would be a good idea for us to begin to tackle this question, It's just short of a month since Steve posted this, with, as far as I've seen, no concrete suggestions on what the m68k porters want to do about this. I expect we'll be dropping m68k from etch fairly shortly, unless someone comes up with a plan for supporting a Debian 4.0-m68k release in the next few days. I'm not sure if that's necessarily a good idea though -- from what I've seen it might be more useful just to come up with a plan for supporting a Debian testing-m68k variant instead; in which case it won't much matter if m68k gets dropped from etch; testing can get reconstructed from unstable relatively easily. Cheers, aj signature.asc Description: Digital signature
Re: D-I RC1 - release planning - soft freeze for changes in SVN
On Oct 16, 2006, at 12:01 PM, Frans Pop wrote: Please start testing the installer for all architectures NOW All udebs with functional changes have now been uploaded, so this is an excellent time to test different architectures using *daily* images! Hmmm... The daily images directory http://cdimage.debian.org/cdimage/daily- builds/daily/arch-latest/powerpc/iso-cd/ is empty and seems to have been that way since October 9th. Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please hint tetex-base into testing
On Mon, Oct 16, 2006 at 12:38:45PM +0200, Frank Küster wrote: currently, tetex-base is not going into testing because it has RC bugs, and britney believes the number of RC bugs is equal in testing and sid. This is technically true, however, all the RC bugs that have a etch-ignore tag also have a part that actually is RC, and which has been fixed in versions 3.0.dfsg.1-1 or 3.0.dfsg.2-1 (and thus are unfixed in etch). The only non-etch-ignore RC bug is present in both distributions. Therefore etch would be much better if the current sid version migrated soon. Understood, hint added. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k not a release arch for etch; status in testing, future plans?
Bill Allombert [EMAIL PROTECTED] writes: You did not ask Roman to provide examples of fixes are just stuck in the BTS, you picked your own bug and then complains it is not a good example ? Is not that non-sense ? No, what I did was I asked how his claim relates to a particular bug in a package affecting me, and he responded by saying that the bug was an example of his claim, when, in fact, it wasn't. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
