Re: glibc_2.3.6-7_i386.changes REJECTED
On Fri, Apr 14, 2006 at 03:03:31AM -0700, Jeroen van Wolffelaar wrote: > Hi maintainers, > > Sorry, but I'm going to reject this package. > > 1) You're adding a new package directly to unstable, instead of first to >experimental. The first point has already been discussed, let's see other ones. > 2) Glibc is currently RC buggy, and it'd really really be better to just get >an RC bugfree glibc in testing asap without all kinds of new changes Which RC bug? The one that was triggered by a change in libstdc++ and could have been reassigned to it? Or the one about locales that became RC today? > 3) The locales-all package is 52MB, 275MB installed size. That's a factor 10 >more than the wishlist (!) bug requestiong the package says. To top this >off, it's also arch:any, so multiplying the required archive space by quite >a factor. I'd encourage you to ensure the binary blogs in question are >architecture neutral, and also look critically at why this package needs to >be so huge, for 'just' the compiled locales. There are 380 locales >supported in unstable atm, and the text representations take 6.8M? An easy >optimalisation is already making sure the 850kB or so LC_COLLATE files of >utf-8 locales to be shared amongst each of the UTF-8 locales. Fixed in SVN, here is the relevant changelog entry: * Preserve hard links when compiling the locales-all package, this reduces package size by a factor of 3. Thanks to Jeroen van Wolffelaar for noticing. > 4) You ask packages which previously depend on locales to now depend on >locales|generated-locales, why not simply let locales-all provide locales? Fixed in SVN, here is the relevant changelog entry: * Let locales-all Provides: locales instead of a virtual generated-locales package. This is requested by Jeroen van Wolffelaar to allow this new package enter unstable. Packages which Build-Depends on locales are likely to FTBFS if locales-all is installed, this dependency will be fixed in a later release. Please let me know if something else needs to be fixed. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glibc_2.3.6-7_i386.changes REJECTED
Hi maintainers, Sorry, but I'm going to reject this package. 1) You're adding a new package directly to unstable, instead of first to experimental. 2) Glibc is currently RC buggy, and it'd really really be better to just get an RC bugfree glibc in testing asap without all kinds of new changes 3) The locales-all package is 52MB, 275MB installed size. That's a factor 10 more than the wishlist (!) bug requestiong the package says. To top this off, it's also arch:any, so multiplying the required archive space by quite a factor. I'd encourage you to ensure the binary blogs in question are architecture neutral, and also look critically at why this package needs to be so huge, for 'just' the compiled locales. There are 380 locales supported in unstable atm, and the text representations take 6.8M? An easy optimalisation is already making sure the 850kB or so LC_COLLATE files of utf-8 locales to be shared amongst each of the UTF-8 locales. 4) You ask packages which previously depend on locales to now depend on locales|generated-locales, why not simply let locales-all provide locales? --Jeroen === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-7_i386.changes REJECTED
On Fri, Apr 14, 2006 at 12:37:20PM +0200, Aurelien Jarno wrote: > On Fri, Apr 14, 2006 at 03:03:31AM -0700, Jeroen van Wolffelaar wrote: > > Hi maintainers, > > > > Sorry, but I'm going to reject this package. > > > > 1) You're adding a new package directly to unstable, instead of first to > >experimental. > > Is it a new requirement? I wasn't aware of that. It isn't a requirement, but something I'd strongly advice for such an important package like glibc. Anyway, this certainly wasn't the strongest reason to reject, and I might not have rejected it if the other 3 points didn't exist. > More seriously, I can understand that for libc-bin, but not for package > that you are not obliged to install. > > I plan to add libc6-mipsn32 and libc6-mipsn64 soon. Should they also go > thru experimental first? As long as glibc is out of sync unstable vs testing and there are multiple RC bugs in unstable, definitely. Currently amd64 in testing is blocking on glibc being out of sync, so we'd really like to get glibc into a testing-worthy version as soon as possible. I don't have a strong opinion on this otherwise, it's more like "not to unstable right now, in this form" than "must be to experimental first", also taking into account the other issues you list with using experimental for this. I hope this clarifies my position adequately. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-7_i386.changes REJECTED
On Fri, Apr 14, 2006 at 03:03:31AM -0700, Jeroen van Wolffelaar wrote: > Hi maintainers, > > Sorry, but I'm going to reject this package. > > 1) You're adding a new package directly to unstable, instead of first to >experimental. Is it a new requirement? I wasn't aware of that. More seriously, I can understand that for libc-bin, but not for package that you are not obliged to install. I plan to add libc6-mipsn32 and libc6-mipsn64 soon. Should they also go thru experimental first? If yes, please either allow two different versions of a package in experimental or please remove glibc 2.4 from it. Also note that experience prooved that almost nobody tests glibc packages from experimental... Or at least they don't report the bugs they found... Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
