Re: [U-Boot] [T-Engine] UBoot configuration for T-Engine/SH7727 MS7727CP02 DevKit
Hi Nobuhiro Iwamatsu, Now I'm porting USB on board T-Engine(SH7727) - My configure following : #define CONFIG_CMD_USB #define CONFIG_USB_OHCI_NEW 1 #define CONFIG_USB_STORAGE 1 #define CFG_USB_OHCI_REGS_BASE 0x04000400 #define CFG_USB_OHCI_SLOT_NAME "s3c2400" #define CFG_USB_OHCI_MAX_ROOT_PORTS 15 #define CONFIG_DOS_PARTITION1 #define CONFIG_SYS_CLK_FREQ #define TMU_CLK_DIVIDER 4 /* 4 (default), 16, 64, 256 or 1024 */ #define CFG_HZ (CONFIG_SYS_CLK_FREQ / TMU_CLK_DIVIDER) - And in lowlevel_init.S, I change USB clock following: UCLKCR_A: .long 0xA40A0008 UCLKCR_D: .long 0xA5C0 mov.l UCLKCR_A,r1 mov.l UCLKCR_D,r0 mov.w r0,@r1 - When I'm starting board with above configue, I see the led of USB device is blinking. Then I run command "usb start", the led turn off and u-belopment we might schedule a longer period to allow for more ambitious work. Release cycle - Each release cycle will be split into three periods, each lasting roughly one-third of the cycle: Phase one: feature proposal ~~~ The first phase of the release process will be devoted to figuring out what features to include in the next version. This should include a good deal of preliminary work on those features -- working code trumps grand design. At the end of part one, the core developers will propose a feature list for the upcoming release. This will be broken into: * "Must-have": critical features that will delay the release if not finished * "Maybe" features: that will be pushed to the next release if not finished * "Not going to happen": features explicitly deferred to a later release. Anything that hasn't got at least some work done by the end of the first third isn't eligible for the next release; a design alone isn't sufficient. Phase two: development ~~ The second third of the release schedule is the "heads-down" working period. Using the roadmap produced at the end of phase one, we'll all work very hard to get everything on it done. At the end of phase two, any unfinished "maybe" features will be postponed until the next release. Though it shouldn't happen, any "must-have" features will extend phase two, and thus postpone the final release. Phase two will culminate with an alpha release. Phase three: bugfixes ~ The last third of a release is spent fixing bugs -- no new features will be added during this time. We'll release a beta release about halfway through, and an rc complete with string freeze two weeks before the end of the schedule. Bug-fix releases After a minor release (i.e 1.1), the previous release will go into bug-fix mode. A branch will be created of the form "/branches/releases/1.0.X" to track bug-fixes to the previous release. When possible, bugs fixed on trunk must *also* be fixed on the bug-fix branch; this means that commits need to cleanly separate bug fixes from feature additions. Each bug-fix branch will have a maintainer who will work with the committers to keep them honest on backporting bug fixes. Micro releases (i.e. 1.0.1) will happen roughly half-way between minor releases -- or earlier, if enough bugs have been fixed to warrant a release. After the *next* minor release (i.e. 1.2), the previous bug-fix release will enter security-fix mode: only security fixes will be applied to the micro-branch, and new releases will only be done for those fixes. Feature branches Development of major features between versions will be done on branches. See the branch policy (http://docs.djangoproject.com/en/dev/internals/contributing/#branch-policy) for details. [I'll be updating this policy shortly to indicate new procedures for branches, including the use of DVCS tools --JKM]. How this all fits together -- Let's look at a hypothetical example for how this all first together. Imagine, if you will, a point about halfway between 1.1 and 1.2. At this point, development will be happening in a bunch of places: * On trunk, development towards 1.2 proceeds with small additions, bugs fixes, etc. being checked in daily. * On the branch "/branches/releases/1.1.X", bug fixes found in the 1.1 release are checked in as needed. At some point, this branch will be released as "1.1.1", "1.1.2", etc. * On the branch "/branches/releases/1.0.X", security fixes are made if needed and released as "1.0.2", "1.0.3", etc. * On features branches, development of major features is done. These branches will be merged into trunk before the end of phase two. Again, feedback is welcome. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PR
Re: ANN: Trunk freeze and 1.0rc1
On Tue, Sep 2, 2008 at 5:15 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Hi folks -- > > We're about to push out 1.0rc1. Check the blog for the announcement. > Things to know > > #8669 is the only known code bug. Malcolm or I will fix it tonight or > tomorrow morning. Hi, http://code.djangoproject.com/ticket/3094 is marked as post-1.0 but it is really 1.0. Please do not release 1.0 with this XMLField documented as working while it is not. Thanks for your time --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: initial data for inlineformset_factory
On Aug 19, 2:22 pm, "Brian Rosner" <[EMAIL PROTECTED]> wrote: > I guess I am failing to see how this is useful?initialdatain an > inline model formset is based on the queryset such as it is a subclass > of model formset. Could you provide a use case where it might be worth > it to also provideinitialdatafor an inline model formset? It would > seem that a default value on a model field would be sufficient. Seems > a bit overkill for the general case due to the unknown size of the > queryset. > > -- > Brian Rosnerhttp://oebfare.com I guess my question would be, how can it not be useful? If it was considered worthwhile for a regular formset to be able to have dynamic field values via the initial argument why wouldn't it be useful for a model formset? Whether or not the data is saved in a database seems irrelevant to the usefulness of being able to provide dynamic initial values. You seem to be thinking of initial data in terms of overriding existing instances but where it comes in handy is for providing defaults for potential new instances. As a use case consider a restaurant. When a customer wants to buy something they create an order and add one or more menu items to it, say 2 hot dogs, 4 hamburgers, and 1 large drink. It would be nice the next time the customer comes back to provide those as the defaults for a new order. In that way they could just get the usual. Or if the menu were small it might be best to always display all menu items and just have customers enter the quantity for anything they want. In this case you would override the validation and save methods so that only records with a quantity provided were saved into your database, similar to the way the core option used to work for model fields. I really can't think of a common use case where initial would be used to override existing instances. However, I think it would be helpful if a model formset displayed existing instances supplied by the underlying queryset, new instances populated with data from an initial argument, and blank instances defined by extra. Extra already operates as I would expect initial to, but it takes its values from the fields rather than allowing you to pass them in dynamically. If extra is worthwhile to have it seems initial would be too. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ANNOUNCE: Security updates for Django trunk, 0.96, 0.95 and 0.91
In accordance with our security policy[1], today the Django project is issuing a set of releases to fix a security vulnerability reported to us. This message contains a description of the vulnerability, a description of the changes made to fix it, and pointers to the patches for each supported version of Django. Description of vulnerability The Django administration application, as a convenience for users whose sessions expire, will attempt to preserve HTTP POST data from an incoming submission while re-authenticating the user, and will -- on successful authentication -- allow the submission to continue without requiring data to be re-entered. Django developer Simon Willison has presented the Django development team with a proof-of-concept cross-site request forgery (CSRF) which exploits this behavior to perform unrequested deletion/modification of data. This exploit has been tested and verified by the Django team, and succeeds regardless of whether Django's bundled CSRF-protection module is active. Affected versions = * Django development trunk * Django 0.96 * Django 0.95 * Django 0.91 Resolution == As it represents a persistent vector for CSRF attacks, this behavior is being removed from Django; henceforth, attempted posts from users whose sessions have expired will be discarded and the data will need to be re-entered. This is, then, backwards-incompatible with existing behavior and may be considered a feature removal; however, the Django team feel that the security risks of this feature outweigh its minor utility. The fix for this issue was applied to the Django repository in changeset 8877, which contains the relevant changes for each affected version:: http://code.djangoproject.com/changeset/8877 Based on these changes, the Django team is issuing three new releases: * Django 0.96.3: http://www.djangoproject.com/download/0.91.3/tarball/ * Django 0.95.4: http://www.djangoproject.com/download/0.95.4/tarball/ * Django 0.91.3: http://www.djangoproject.com/download/0.96.3/tarball/ The relevant patch has been applied to Django trunk as well, and so will be included in the forthcoming Django 1.0 release candidate (to be issued later today) and the final Django 1.0 release. All users of affected Django versions are encouraged to upgrade immediately. A file containing the MD5 and SHA1 checksums of the new release packages has been placed on the ``djangoproject.com`` server:: http://media.djangoproject.com/pgp/django-security-releases-20080901.checksums.txt This file is PGP-signed with the Django release manager's public key. This key has the fingerprint ``0x8C8B2AE1`` and can be obtained from, e.g., the MIT PGP keyserver:: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8C8B2AE1 Release manager's note == If you are currently maintaining and distributing a packaged version of Django (e.g., for a Linux or other Unix distribution), or if you are a hosting company which officially supports Django as an option for customers, and you did **not** receive an advance notification of this issue, please contact Django's release manager (James Bennett, james at b-list dot org) as soon as possible so that you can be added to the list of known distributors who receive such notifications. [1] http://www.djangoproject.com/documentation/contributing/#reporting-security-issues -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ANN: Trunk freeze and 1.0rc1
Hi folks -- We're about to push out 1.0rc1. Check the blog for the announcement. Things to know #8669 is the only known code bug. Malcolm or I will fix it tonight or tomorrow morning. Other than that, we're on total trunk freeze. I need everyone's help to quickly triage incoming tickets and separate anything BIG -- data loss, crashes, etc -- from, well, everything else. I'll be focusing on docs until the final release, so feel free to put any doc patches filed into the 1.0 milestone. Ditto translations. Anything else needs to be pushed post-1.0. I suspect I'll be making a lot of BDFL post-1.0 pushes on incoming stuff; please try to give me the benefit of the doubt, but don't be shy if I fuck up. If you're a partial committer, please check with a core committer before you commit anything. Again, the exception is for docs and translations. We'll do the final release as soon as we feel comfortable. With luck, that'll be really soon. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Template system ported to C based language?
Is anyone aware of any projects to port Django's template system to a C based language? I found a project that's porting to PHP, but I'm wondering if anyone has started a C based port. C, Objective-c, or C+ +? Thanks, Jesse Grosjean --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: forms.BooleanField(widget=forms.HiddenInput) broken on MySQL
> > Time to open a new issue which focuses solely on the Hidden Boolean > issue in stead of #7190? > > Ps: I still feel that exposing the fact that MySQL does not support > booleans is a mistake exactly because it creates two new paths > in Django. One where booleans are mapped to and one where > they are mapped to . > There have been problems with the tests on MySQL because of this too. > Besides it feels like python < 2.3 ;) > > Pim. I have to agree here. I just had an interesting failure mode in my functional/unit testing due to this "feature". How much database independence is django offering? This bit of behavior is not too helpful, and it isn't documented (Opened http://code.djangoproject.com/ticket/8802 for this). I realize that I need to re-test between databases, but it comes down to how much django is abstracting the DB. -Dave --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
One use case for Composite Primary Keys is for setting up database partitions. In my case I am using Range-Hash partitions with the range determined by an IntegerField called "ISOweek" and the hash working off of the "id" field supplied by Django. To allow this partitioning to work, the primary key must be a composite primary key incorporating the "ISOweek" and the "id" fields. My versions of the sqlreset and reset management functions do this while also ensuring that "id" is marked as unique even though it is not the primary key. This allows a ForeignKey pointed at my partitioned model to work correctly by setting "id" as the to_field. (If "id" is not set as unique, Django and/or the database will fail in its' attempt to set up the full foreign key relationship.) The initial version of Composite Primary Keys should not preclude this scenario, however full support for setting up and managing partitioned models need not be included at this time. (I plan to help add that later.) The interesting point is that support for related fields for the Composite Primary Key is not required in order to support this particular use case. Rock On Aug 28, 8:05 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > I'm not quite sure how that relates to Composite Primary Keys? > > A ForeignKey would point to multiple internal fields, but it should look > like it's a single field. At the same time, this would open up the > possibility for Composite Foreign Keys, which would mean it could point to > multiple public fields. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Search facility for new documentation
Hi Jacob, On Tue, Sep 2, 2008 at 5:06 PM, Jacob Kaplan-Moss wrote: > Yeah, I'd love to see it; if it integrates better -- the custom search > looks like shit, frankly -- it might be worth the money. See here: http://code.unicoders.org/wiki/DjangoGoogleSearch There's some documentation now, although this is of course not a proper public release. I've been using this code in production for a while now and it hasn't crashed on me yet, but of course your mileage may vary. I've been using it in production here for about five months now, without any major issues: http://mytech.it/search/?q=test HTH, -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Search facility for new documentation
On Tue, Sep 2, 2008 at 9:13 AM, Antonio Cavedoni <[EMAIL PROTECTED]> wrote: > FWIW: I have an almost finished (only needs packaging and some > documentation) reusable Django app that wraps around Google Business > Search. It's basically the same thing as the Google Custom Search > that's currently in place, only it doesn't work off an iframe and > doesn't have any ads. > > The downside is that it's for pay, about $100 a year IIRC. > > My app would be free anyway. If there's interest I can package and release it. /me raises hand :) Yeah, I'd love to see it; if it integrates better -- the custom search looks like shit, frankly -- it might be worth the money. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: from beta to 1.0?
On Sep 2, 3:04 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > That's what we'll be doing. Sorry we haven't updated the roadmap or > this list; we're all busy, you know, getting 1.0 done. Watch for the > announcement later today. thanks for info. Aljosa --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Search facility for new documentation
On Sun, Aug 31, 2008 at 1:53 PM, Fraser Nevett <[EMAIL PROTECTED]> wrote: > Sphinx's search could be useful if you're working with an offline copy > of the docs, but Google seem to give much better results so is > probably preferable for the docs web site. FWIW: I have an almost finished (only needs packaging and some documentation) reusable Django app that wraps around Google Business Search. It's basically the same thing as the Google Custom Search that's currently in place, only it doesn't work off an iframe and doesn't have any ads. The downside is that it's for pay, about $100 a year IIRC. My app would be free anyway. If there's interest I can package and release it. Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: from beta to 1.0?
On Tue, Sep 2, 2008 at 7:57 AM, Aljosa Mohorovic <[EMAIL PROTECTED]> wrote: > since everybody is talking about django 1.0 release today and i was > looking at http://code.djangoproject.com/wiki/VersionOneRoadmap > (schedule not updated) it's not clear to me why nobody thinks that > releasing rc1 and waiting a few days more to see if everything is > actually working is a possible option? That's what we'll be doing. Sorry we haven't updated the roadmap or this list; we're all busy, you know, getting 1.0 done. Watch for the announcement later today. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
from beta to 1.0?
since everybody is talking about django 1.0 release today and i was looking at http://code.djangoproject.com/wiki/VersionOneRoadmap (schedule not updated) it's not clear to me why nobody thinks that releasing rc1 and waiting a few days more to see if everything is actually working is a possible option? after waiting for so long what's 2-3 days more? Aljosa Mohorovic --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: primary_key for ImageField does not work any more
This sounds like a bug. I would submit a ticket for it.
On Sep 1, 6:42 am, Jochen Voss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> with Django 0.96 I used a model which contained the following field:
>
> class ImageFile(models.Model):
> [...]
> fname = models.ImageField(upload_to="images", primary_key=True,
> width_field="width", height_field="height")
> [...]
>
> When trying to convert this to the current version of Django, I got the
> following error message for this line:
>
> [...]
> File "/home/voss/s2/s2/images/models.py", line 96, in
> class ImageFile(models.Model):
> File "/home/voss/s2/s2/images/models.py", line 107, in ImageFile
> width_field="width", height_field="height")
> File
> "/var/lib/python-support/python2.5/django/db/models/fields/files.py", line
> 240, in __init__
> FileField.__init__(self, verbose_name, name, **kwargs)
> File
> "/var/lib/python-support/python2.5/django/db/models/fields/files.py", line
> 129, in __init__
> raise TypeError("'%s' is not a valid argument for %s." % (arg,
> self.__class__))
> TypeError: 'primary_key' is not a valid argument for 'django.db.models.fields.files.ImageField'>.
>
> It seems that primary_key=True is no longer allowed for ImageField
> fields. I looked
> athttp://code.djangoproject.com/wiki/BackwardsIncompatibleChanges
> but did not find any information about this.
>
> I am not sure whether this change is intended or a bug, but I think it
> should either be mentioned in the list of backward incompatible
> changes or should be allowed again.
>
> I hope this helps,
> Jochen
> --http://seehuhn.de/
>
> signature.asc
> < 1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
