On Sat, Nov 15, 2008 at 04:30:06PM -0800, Danek Duvall wrote:
> I didn't think so, but I thought I saw some of our messages translated in
> the l10n code drops.
Indeed, the message I'm removing is in fact in the .po files.
Danek
___
pkg-discuss mailing
On Sat, Nov 15, 2008 at 04:16:55PM -0800, [EMAIL PROTECTED] wrote:
>> Given that this is a message change, is there an issue in changing it so
>> late? Or will there be a final message delivery after 10am Monday?
>
> Do you mean for translation? Do we even have pkg(5) being translated
> right no
> Given that this is a message change, is there an issue in changing it so
> late? Or will there be a final message delivery after 10am Monday?
Do you mean for translation? Do we even have pkg(5) being translated
right now?
dsc
___
pkg-discuss mailing
David,
Given that this is a message change, is there an issue in changing it so
late? Or will there be a final message delivery after 10am Monday?
Danek
___
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listin
Shawn Walker wrote:
> Danek Duvall wrote:
>
>> On Sat, Nov 15, 2008 at 12:55:07AM -0600, Shawn Walker wrote:
>>
>>
>>> line 1549: the wording could be clearer here, what about: "only one
>>> authority name may be specified"
>>>
>> Sure.
>>
>>
>>> line 1778: for consistency,
Looks much better.
Cheers,
Jim
Shawn Walker wrote:
> Danek Duvall wrote:
>> On Sat, Nov 15, 2008 at 12:55:07AM -0600, Shawn Walker wrote:
>>
>>> line 1549: the wording could be clearer here, what about: "only one
>>> authority name may be specified"
>> Sure.
>>
>>> line 1778: for consistency
Danek Duvall wrote:
> On Sat, Nov 15, 2008 at 12:55:07AM -0600, Shawn Walker wrote:
>
>> line 1549: the wording could be clearer here, what about: "only one
>> authority name may be specified"
>
> Sure.
>
>> line 1778: for consistency, there should be a ':' after unset-property
>
> Fixed.
On Sat, Nov 15, 2008 at 12:55:07AM -0600, Shawn Walker wrote:
> line 1549: the wording could be clearer here, what about: "only one
> authority name may be specified"
Sure.
> line 1778: for consistency, there should be a ':' after unset-property
Fixed.
Webrev updated.
Thanks,
Danek
_
Danek Duvall wrote:
> http://cr.opensolaris.org/~dduvall/pkg-bug5098/
>
> makes a few small tweaks to some usage messages. I've targeted this for
> Monday, since it's low risk and a nice cosmetic touch-up, but it's not a
> blocker by any means.
client.py:
line 1549: the wording could be c
http://cr.opensolaris.org/~dduvall/pkg-bug5098/
makes a few small tweaks to some usage messages. I've targeted this for
Monday, since it's low risk and a nice cosmetic touch-up, but it's not a
blocker by any means.
Danek
___
pkg-discuss mailing lis
[EMAIL PROTECTED] wrote:
> Looks fine to me. However, I don't think this will stop us from running
> into bugs like 4277. In that particular case, we're just going to have
> to remember that we created the file with a more restrictive mode, and
> must change it back when the file is renamed to th
Looks fine to me. However, I don't think this will stop us from running
into bugs like 4277. In that particular case, we're just going to have
to remember that we created the file with a more restrictive mode, and
must change it back when the file is renamed to the working copy. None
of this is
http://cr.opensolaris.org/~barts/166/
This one works around the problem by setting umask explicitly;
a fix to avoid this would change lots more code, inappropriate
at this point in the release as the same umask issue affects
all callers of file(..., "w") as well.
-= Bart
--
Bart Smaalders
Ah, rats. I sent a reply before I saw this. :(
-j
On Wed, Oct 29, 2008 at 04:44:19PM -0500, Tom Mueller wrote:
> Please ignore. I sent this message before I saw that 4323 was filed.
>
> Tom
>
> Tom Mueller (pkg-discuss) wrote:
>> While this eliminates the traceback, it doesn't provide any clue
> Do you have examples of what the new output looks like with this change?
Here's some example output:
$ pkg image-create -F -a
sidewinder=https://sidewinder.red.iplanet.com/dev/promoted/solaris-sparc
$PKG_IMAGE
pkg: 0/1 catalogs successfully updated:
Could not retrieve catalog from 'sidewi
Please ignore. I sent this message before I saw that 4323 was filed.
Tom
Tom Mueller (pkg-discuss) wrote:
While this eliminates the traceback, it doesn't provide any clue to the
user as to what to do next, especially if this is a case where the
problem is that the user has not provided a cert/
While this eliminates the traceback, it doesn't provide any clue to the
user as to what to do next, especially if this is a case where the
problem is that the user has not provided a cert/key and one is
required. That was the intent when the issue was filed.
Do you have examples of what the n
[EMAIL PROTECTED] wrote:
> Folks,
> I have an easy code review that fixes a stack trace in the transport
> path. This occurs because we catch sslerror execptions and then throw a
> RuntimeError. The code that caught the RuntimeError has gone away, so
> this escapes to the top level, causing a sta
Looks fine to me.
-Brad
On Wed, Oct 29, 2008 at 02:24:00PM -0700, [EMAIL PROTECTED] wrote:
> Folks,
> I have an easy code review that fixes a stack trace in the transport
> path. This occurs because we catch sslerror execptions and then throw a
> RuntimeError. The code that caught the RuntimeEr
Folks,
I have an easy code review that fixes a stack trace in the transport
path. This occurs because we catch sslerror execptions and then throw a
RuntimeError. The code that caught the RuntimeError has gone away, so
this escapes to the top level, causing a stack trace.
The solution is to remov
> This could also be written somewhat more compactly as:
>
> def gen_actions_by_type(self, type):
> """Generate actions in the manifest of type "type"."""
>
> return (a for a in self.actions_bytype.get(type,[]))
Good call. I didn't realize that mapping types su
[EMAIL PROTECTED] wrote:
> Folks,
> I finally have a fix for 3505. This reduces the amount of time we spend
> processing manifests and actions before and during the evaluate stage.
>
> In the performance tests that I ran, this took 10 seconds off the
> evaluate time, reduced user cpu time by 8-10
On Fri 03 Oct 2008 at 12:16PM, [EMAIL PROTECTED] wrote:
> I updated the bug report with these numbers too. They all show
> improvement.
That helps a ton, thanks.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
In this case, the keys are strings. I'm assuming the hash function is
pretty fast. There should only be about 10 keys max, though.
-j
On Thu, Oct 02, 2008 at 05:41:59PM -0700, Dan Price wrote:
> On Thu 02 Oct 2008 at 07:34PM, Shawn Walker wrote:
> > In the case that you had a lot of items, I co
I updated the bug report with these numbers too. They all show
improvement.
-j
On Thu, Oct 02, 2008 at 05:37:57PM -0700, Dan Price wrote:
> On Thu 02 Oct 2008 at 05:32PM, [EMAIL PROTECTED] wrote:
> > > It helps to know "10 seconds out of how many?" Can you post some
> > > before-and-after compa
> manifest.py:
>line 97: is there any reason to not make this private? i.e.
> __actions_bytype
I kept it public since actions is still public. That gets used in many places
outside of manifest. I don't really care either way, but thought we
might want to be consistent.
> General Questions
On Thu 02 Oct 2008 at 07:34PM, Shawn Walker wrote:
> In the case that you had a lot of items, I could see the try/except
> being faster since you wouldn't incur the lookup expense. In initial
> attempts, I could see the exception overhead slowing things down.
That has been my observation in the
On Thu 02 Oct 2008 at 05:32PM, [EMAIL PROTECTED] wrote:
> > It helps to know "10 seconds out of how many?" Can you post some
> > before-and-after comparisons of e.g. 'install -nv' and
> > 'image-update -nv' using ptime?
>
> I included those numbers in the bug report.
>
> http://defect.opensolari
[EMAIL PROTECTED] wrote:
> Folks,
> I finally have a fix for 3505. This reduces the amount of time we spend
> processing manifests and actions before and during the evaluate stage.
>
> In the performance tests that I ran, this took 10 seconds off the
> evaluate time, reduced user cpu time by 8-10
> It helps to know "10 seconds out of how many?" Can you post some
> before-and-after comparisons of e.g. 'install -nv' and
> 'image-update -nv' using ptime?
I included those numbers in the bug report.
http://defect.opensolaris.org/bz/show_bug.cgi?id=3505
> > doesn't appear to have any negative
On Thu 02 Oct 2008 at 05:11PM, [EMAIL PROTECTED] wrote:
> Folks,
> I finally have a fix for 3505. This reduces the amount of time we spend
> processing manifests and actions before and during the evaluate stage.
>
> In the performance tests that I ran, this took 10 seconds off the
> evaluate time
Folks,
I finally have a fix for 3505. This reduces the amount of time we spend
processing manifests and actions before and during the evaluate stage.
In the performance tests that I ran, this took 10 seconds off the
evaluate time, reduced user cpu time by 8-10 seconds correspondingly.
It also red
On Fri, Feb 22, 2008 at 9:44 AM, Danek Duvall <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 09:40:29AM +, Trevor Watson wrote:
>
> > I don't know how you managed to figure that out, but Danek's 'AWESOME' does
> > not do it justice!
>
> Seriously, is there something wrong with this lis
On Fri, Feb 22, 2008 at 03:52:41PM +, Trevor Watson wrote:
> Maybe the real cause of this is that your name has a strong gravitiational
> field Danek?
Nah, it's probably just me being evil again, taking on a network duality
and subsuming "Dan Price". That now means I'll soon be able to eat
Oops, sorry Danek and Dan - I got the two of you muddled, although in my
defence I would say I was completely wiped out this morning, and through
blurry eyes, "Danek" and "Dan" bear some resemblance.
Maybe the real cause of this is that your name has a strong gravitiational
field Danek?
Anyw
On Fri, Feb 22, 2008 at 09:40:29AM +, Trevor Watson wrote:
> I don't know how you managed to figure that out, but Danek's 'AWESOME' does
> not do it justice!
Seriously, is there something wrong with this list, that every message
appears to come from me?
That would have made the argument the
I don't know how you managed to figure that out, but Danek's 'AWESOME' does
not do it justice!
Bl**dy good job, as we say in Blighty :)
[EMAIL PROTECTED] wrote:
Folks,
I've got a 1-line code review for bug 289.
This is the CR:
http://defect.opensolaris.org/bz/show_bug.cgi?id=289
I'm attachin
On Thu, Feb 21, 2008 at 6:32 PM, Dan Price <[EMAIL PROTECTED]> wrote:
> On Thu 21 Feb 2008 at 04:05PM, [EMAIL PROTECTED] wrote:
>
> > diff -r b3b7592412ec src/modules/catalog.py
> > --- a/src/modules/catalog.py Tue Feb 19 11:28:03 2008 -0800
> > +++ b/src/modules/catalog.py Thu Feb 21 16:00:34
On Thu, Feb 21, 2008 at 7:47 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-02-22 01:42]:
>
> > > What, it wasn't obvious in the twisted maze of Python documentation? :)
> > >
> > > http://www.python.org/doc/2.4.4/ref/customization.html
> >
> >
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-02-22 01:42]:
> > What, it wasn't obvious in the twisted maze of Python documentation? :)
> >
> > http://www.python.org/doc/2.4.4/ref/customization.html
>
> *gag* Yes, this is pretty convoluted. I think I finally managed to
> figure some of the
> What, it wasn't obvious in the twisted maze of Python documentation? :)
>
> http://www.python.org/doc/2.4.4/ref/customization.html
*gag* Yes, this is pretty convoluted. I think I finally managed to
figure some of the object protocol out, though.
The dbm module implements PyMappingMethods
On Thu, Feb 21, 2008 at 05:00:38PM -0800, [EMAIL PROTECTED] wrote:
> > Yeah. Looks like __len__() is called if __nonzero__() is not defined for
> > an object, and I bet that dbm objects don't define the latter. Not that
> > this helps us directly, but it might be the way for the python folks to
> Yeah. Looks like __len__() is called if __nonzero__() is not defined for
> an object, and I bet that dbm objects don't define the latter. Not that
> this helps us directly, but it might be the way for the python folks to fix
> it.
Thanks for looking into that. Where did you find this document
On Thu, Feb 21, 2008 at 04:44:54PM -0800, [EMAIL PROTECTED] wrote:
> > Um, other than this will make Dan smack me around, it looks good.
>
> Right. Of course you did this on purpose, just to be an evil Danek.
I don't need to do silly things like that to be an evil Danek. Sheesh.
> > I'm curio
> Um, other than this will make Dan smack me around, it looks good.
Right. Of course you did this on purpose, just to be an evil Danek.
> I'm curious -- does bool(self.searchdb) trigger the same bad behavior?
I think anything that requires us to evaluate the contents of
self.searchdb will trigg
> But, PLEASE, also file a bug against python. MY GOD that is broken.
Done. Filed this as issue 2159 over at bugs.python.org.
Thanks for the review, sir.
-j
___
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman
On Thu, Feb 21, 2008 at 04:05:02PM -0800, [EMAIL PROTECTED] wrote:
> Folks,
> I've got a 1-line code review for bug 289.
>
> This is the CR:
> http://defect.opensolaris.org/bz/show_bug.cgi?id=289
Um, other than this will make Dan smack me around, it looks good.
I'm curious -- does bool(self.s
On Thu 21 Feb 2008 at 04:05PM, [EMAIL PROTECTED] wrote:
> diff -r b3b7592412ec src/modules/catalog.py
> --- a/src/modules/catalog.py Tue Feb 19 11:28:03 2008 -0800
> +++ b/src/modules/catalog.py Thu Feb 21 16:00:34 2008 -0800
> @@ -339,7 +339,7 @@ class Catalog(object):
>
> ne
Folks,
I've got a 1-line code review for bug 289.
This is the CR:
http://defect.opensolaris.org/bz/show_bug.cgi?id=289
I'm attaching a diff instead of using webrev, since this is so small.
Thanks,
-j
diff -r b3b7592412ec src/modules/catalog.py
--- a/src/modules/catalog.pyTue Feb 19 11:28:03
49 matches
Mail list logo
