Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. The underlying technical issue that volatile is working around is that the stable release manager isn't interested in ensuring that a stable release is both functional and secure (btw: has anyone asked him to confirm this?; I'm just working on the 'general assumptions' here). These goals are not inherently opposed to each other. I'd rather work through the existing stable release process first, then resort to a work-around. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
[ debian-volatile dropped ] Hi Daniel, On Mon, Feb 06, 2006 at 11:41:26PM -0500, Daniel Jacobowitz wrote: On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). It would be good to hear from the glibc maintainers if there are any issues addressing bugs such as: 345479, 351049 with an update for stable. It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. Well, perhaps a first start is creating the package for stable-updates; would it be easier for you if I created a diff or would you rather do it yourself? Once a package is available we can start talking to the stable release manager to see what his position is. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. You mean, we better don't do anything than to accept packages into a repository that is actually in apt.sources on a lot of machines, even on the debian.org-machines? As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. You mean, like accepting a new locale package into volatile? Ah, that's you who don't like it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
2006/2/7, Anand Kumria [EMAIL PROTECTED]: It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. Well, perhaps a first start is creating the package for stable-updates; would it be easier for you if I created a diff or would you rather do it yourself? The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ It's quite clear it's not a security bug. Whether it leads to critical data loss or an overly unusable system is debatable. It's just that the clock will be off by an hour for a few weeks. Hardly the end of the world, people run with the clocks on their machines off by months and it doesn't seem to break anything critical. ISTM the d-volatile is the right place for this. However, in the mean time I think someone should send a message to debian-announce that anyone running a debian machine with an Australian (or other affected) timezone needs to get updated zone files from $location. Past policy has been that stable updates don't cover things that arn't critical, even if it makes us look out of date compared to other distributions. A change to that policy should be carefully considered before doing it... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: timezone data packaged separately and in volatile?
* Martijn van Oosterhout ([EMAIL PROTECTED]) [060207 14:09]: ISTM the d-volatile is the right place for this. However, in the mean time I think someone should send a message to debian-announce that anyone running a debian machine with an Australian (or other affected) timezone needs to get updated zone files from $location. Well, if we *have* files at $location that can be used for this, and that allow updates to etch, these files can directly be put into volatile. The round-trip time for such an update is less than 24 hours, if all relevant people (in this case: the glibc people) agree on how to do it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Martijn van Oosterhout writes (Re: timezone data packaged separately and in volatile?): The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). That seems to be true in this case. I think a system which gets the clock wrong in this way is `overly broken'. There doesn't seem to be anything in those rules which allows for an analysis of the risk, so that it can be compared to the benefit. (Perhaps that's implicit, although it's not stated.) A timezone update, carefully built against the right dependencies, could be diffed (that is, the .deb could be diffed) against the old version and carefully tested, which would provide us with confidence that the new package is right to install. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Hi Daniel, On Monday, 06 Feb 2006, you wrote: On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: But that doesn't mean that we can issue an update to a stable package. Currently they are mainly done for security purposes -- but stable updates should not be confined to only that. They should be done to keep the system functional. I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). It would be good to hear from the glibc maintainers if there are any issues addressing bugs such as: 345479, 351049 with an update for stable. It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. I talked to Joey another day, and he said, we should mail him about, and he will decide if this could go in via a point release. I hearby mail him (CC). Lets see what happens. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.3.6
Last one. mips-bits-syscall.diff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
r1161 - in glibc-package/trunk/debian: . patches
Author: schizo Date: 2006-02-08 03:39:03 + (Wed, 08 Feb 2006) New Revision: 1161 Removed: glibc-package/trunk/debian/patches/amd64-semtrywait-weakalias.diff glibc-package/trunk/debian/patches/glibc235-alpha-divqu.diff glibc-package/trunk/debian/patches/glibc235-binutils216-ia64.diff glibc-package/trunk/debian/patches/glibc235-execvp-fix.diff glibc-package/trunk/debian/patches/glibc235-gcc4-ia64-profile.diff glibc-package/trunk/debian/patches/glibc235-gcc4-jis0208.diff glibc-package/trunk/debian/patches/glibc235-gcc4-ppc-procfs.diff glibc-package/trunk/debian/patches/glibc235-gcc4-s390-inline.diff glibc-package/trunk/debian/patches/glibc235-hppa-fpu.diff glibc-package/trunk/debian/patches/glibc235-leapsecond.diff glibc-package/trunk/debian/patches/ia64-binutils-libm.diff glibc-package/trunk/debian/patches/strfry-segv.diff Modified: glibc-package/trunk/debian/changelog glibc-package/trunk/debian/patches/glibc235-gcc4-arm-inline.diff glibc-package/trunk/debian/patches/series Log: - Delete several hunks from glibc235-gcc4-arm-inline.diff - Remove glibc235-gcc4-s390-inline.diff Modified: glibc-package/trunk/debian/changelog === --- glibc-package/trunk/debian/changelog2006-02-06 23:59:42 UTC (rev 1160) +++ glibc-package/trunk/debian/changelog2006-02-08 03:39:03 UTC (rev 1161) @@ -80,6 +80,8 @@ - Delete several hunks from glibc235-gcc4-sparc-inline.diff - Remove hurd-libpthread-indirect-loading.diff - Remove glibc235-gcc4-hurd.diff +- Delete several hunks from glibc235-gcc4-arm-inline.diff +- Remove glibc235-gcc4-s390-inline.diff -- Clint Adams [EMAIL PROTECTED] Wed, 1 Feb 2006 20:52:13 -0500 Deleted: glibc-package/trunk/debian/patches/amd64-semtrywait-weakalias.diff === --- glibc-package/trunk/debian/patches/amd64-semtrywait-weakalias.diff 2006-02-06 23:59:42 UTC (rev 1160) +++ glibc-package/trunk/debian/patches/amd64-semtrywait-weakalias.diff 2006-02-08 03:39:03 UTC (rev 1161) @@ -1,41 +0,0 @@ -#! /bin/sh -e - -# All lines beginning with `# DP:' are a description of the patch. -# DP: Description: Fix sem_trywait on amd64 -# DP: Related bugs: -# DP: Dpatch author: Clint Adams -# DP: Patch author: Upstream CVS -# DP: Upstream status: Committed -# DP: Status Details: -# DP: Date: 2005-12-16 - -PATCHLEVEL=0 - -if [ $# -ne 2 ]; then -echo 2 `basename $0`: script expects -patch|-unpatch as argument -exit 1 -fi -case $1 in --patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;; --unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;; -*) -echo 2 `basename $0`: script expects -patch|-unpatch as argument -exit 1 -esac -exit 0 - -# append the patch here and adjust the -p? flag in the patch calls. - nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S~ 2003-05-10 16:37:38.0 -0400 -+++ nptl/sysdeps/unix/sysv/linux/x86_64/sem_trywait.S 2005-10-24 16:50:36.0 -0400 -@@ -1,4 +1,4 @@ --/* Copyright (C) 2002, 2003 Free Software Foundation, Inc. -+/* Copyright (C) 2002, 2003, 2005 Free Software Foundation, Inc. -This file is part of the GNU C Library. -Contributed by Ulrich Drepper [EMAIL PROTECTED], 2002. - -@@ -56,4 +56,3 @@ - orl $-1, %eax - retq - .size sem_trywait,.-sem_trywait -- versioned_symbol(libpthread, __new_sem_trywait, sem_trywait, GLIBC_2_1) Deleted: glibc-package/trunk/debian/patches/glibc235-alpha-divqu.diff === --- glibc-package/trunk/debian/patches/glibc235-alpha-divqu.diff 2006-02-06 23:59:42 UTC (rev 1160) +++ glibc-package/trunk/debian/patches/glibc235-alpha-divqu.diff 2006-02-08 03:39:03 UTC (rev 1161) @@ -1,67 +0,0 @@ -#! /bin/sh -e - -# All lines beginning with `# DP:' are a description of the patch. -# DP: Description: Fix alpha divqu/remqu that does not return the correct -# result when their dividend and divisor are same and 63bit -# is 1. -# DP: Related bugs: #324455 -# DP: Dpatch author: GOTO Masanori [EMAIL PROTECTED] -# DP: Patch author: GOTO Masanori [EMAIL PROTECTED] -# DP: Upstream status: Will be Submitted -# DP: Status Details: -# DP: Date: 2005-08-25 - -PATCHLEVEL=0 - -if [ $# -ne 2 ]; then -echo 2 `basename $0`: script expects -patch|-unpatch as argument -exit 1 -fi -case $1 in --patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;; --unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;; -*) - echo 2 `basename $0`: script expects -patch|-unpatch as argument - exit 1 -esac -exit 0 - -# append the patch here and adjust the -p? flag in the patch calls. -2005-08-23 GOTO Masanori [EMAIL PROTECTED] - - * sysdeps/alpha/remqu.S: Return the correct result when the same -
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 09:57:54AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: I also think volatile is precisely the wrong place to put this kind of data -- it isn't part of the default apt.sources for one thing; and it places an extra burden on the maintainer(s) (who know have to track three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. You mean, we better don't do anything than to accept packages into a repository that is actually in apt.sources on a lot of machines, even on the debian.org-machines? I don't understand your English, perhaps you could rephrase or clarify? As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. You mean, like accepting a new locale package into volatile? Ah, that's you who don't like it. Again, those statements don't make any sense to me. Either by themselves or in the context my what you've quoted. Could you rephrase or clarify. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#12411: 08-Feb-2006 Latest
Dear 12411, We have an online jewelry store located at http://www.bodywings.com We have visited your site 'debian.org' and think that the content could be of interest to our web site visitors. I have already placed a link to your site along with a description at http://www.bodywings.com/nlink.html If you agree for the link exchange program, please add our link details as follows: Title: Body Jewelry Piercing Silver Jewelry Direct Manufacturer Description: Direct Supplier of all kinds of Body Jewelry Piercing, Body Jewelry Wholesale and 925 Sterling Silver Jewelry, Silver Jewelry Wholesale at manufacture price. Url: http://www.bodywings.com Kindly inform us the reciprocal webpage after you have added our link. We would appreciate if you placed a link back to our site. Best Regards, Veena Bodywings.com Co., Ltd. [If you do no want to receive emails from us, please reply with the word 'Unsubscribe' in the subject] --- Body Silver Jewelry Online Store http://www.bodywings.com http://stores.ebay.com/bodywingscomgemnjewelry Gems Online Store http://stores.ebay.com/Blissgem Online Catalog - Gold Sterling Silver Jewelry http://www.eurostarcreations.com/oncat/index.html --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
