DjangoBot: #django-dev

Ok, works for me

thanks

morning all, since when do we have a CLA?

?

on the donations page there's a link to a CLS

CLA

I suppose jacob is about to announce it ;)

Backing it up with a link:

does the cla@ email address already work?

jacobkm, hi :-) quick question: does the cla@ email address already work?

zerok: yup

jacobkm, ok, tnx :-) just wanted to make sure my mail didn't reach the end of the internet before getting sucked into a black hole or something :-)

zerok: nope, I've got it right here -- thanks :)

np :-)

imo everyone signing that should receive a t-shirt :-P

zerok: we have over 300 contributors -- that's a lot of t-shirts to send out!

;-)

zerok: How's aobut instead everyone who signs gets a free web framework?

<grin>

"and in green" <3

No, I got you totally; still, it would really be awesome to be able to send thank-you gifts to all our contributors

sure, but everyone should be happy enough with having done something for the project and therefor made other people's life much easier :-)

Yup

jacobkm, we'd got a discussion on #django-fr about the scope of the cla, what about people who translate the documentation?

in other words, is it restricted to AUTHORS file?

david`bgk: no, we need to get CLAs from everyone who's contributed more than like a typo fix, so definitely translators.

We'll be doing a more formal call for CLAs like this week or next -- we need to audit the SVN history and gather a list of everyone we need CLAs from.

But of course anyone who wants to help us get started quickly can start doing 'em now.

translators of django internal and/or translators of the documentation? because we translated a lot of the documentation: http://www.django-fr.org/documentation/

david`bgk: so since that documentation hasn't yet made it back into Django (which is mostly my fault... sorry!) you don't need a CLA for it -- we only need CLAs to cover work that we're (i.e. the foundation) distributing.

ok thanks, that's clear now :)

Cool - thanks

This is one of those annoying legal things... I really wish we could just write code and not have to worry about sily stuff like this :)

but basically everonye on a localized-docs-project who doesn't sign the cla will hold back the project from inclusion in the core distribution, right?

Yeah, going forward basically any checkin to Django will need to be covered -- you don't need new documents for each contribution, though, so as long as all the authors of whatever's going in (code, docs, whatever) have clas on file, that's fine.

in this case .... /me goes slapping some people around in #django-de :P

david`bgk: Hi. Sorry for bothering you again with this issue (the test suite failure when trsting loading of templates from eggs). I've pasted here http://dpaste.com/65101/ a standalone version of the code with some debugginf output and a more granular implementation, would you be so kind to execute it and dpaste back the output?

cramm, sure

cramm, here is the result: http://dpaste.com/65102/

whome should i nudge for some triage on a localflavor addition ticket?

david`bgk: Thanks!. So, the script isn't failing. Now I'm really at lost why the test (that does the same thing) fails :(

*at loss

re #7560, the current patch is failing a test now

django/db/models/fields/__init__.py", line 456, in get_db_prep_lookup

value = [int(v) for v in value]

TypeError: 'Query' object is not iterable

so, looks like the value parameter to get_db_prep_lookup can also be a Query object

hi jacobkm: you got my CLA also?

telenieko: indeed

then, should every get_db_prep_lookup method check for that case as the base Field.get_db_prep_lookup does?

fine ;)

to me, that would look like a lot of code repetition

cramm, can I help you more?

david`bgk: hrm, so you can confirm the test is still failing? (you can run it with runtsts.py templates)

hmm, should I come back after 1.0alpha with this backend-related issues?

looks like the focus is not there now (quite reasonable btw)

cramm, yes even with os.path.normpath patch

david`bgk: there have been reports from other OS X users here for which the test don't fail

david`bgk: oly think I can think of is inserting some debugging print's in django/template/loaders/eggs.py and re-run the Django tests

david`bgk: maybe commenting the except+pass at lines 22 and 23

cramm, it doesn't raise any error if I comment those lines and just return (resource_string...

david`bgk: wird because the test is failing by the raise at line 24, isn't it?

omg, it works. I'm so sorry :/

just a moment I verify

yes it works even without os.path.normpath

I imported my "clean" version of django after import django.contrib as contrib in runtests so it wasn't used :(

what about this line in runtests in order to avoid my mistake: sys.path = [os.path.join(os.getcwd(), '../')] + sys.path ?

this way you are sure that you test your current django

sanity check: is the current test count ~363?

i'm prepping for the sprint, and want to avoid a late discovery that my environment is messed up.

buildbot says 367

thanks

I'm guessing your SVN rev is out of date

it was. running tests again now.

david`bgk: (sorry, had to rush to a meeting I had forgot about), so it leavs us just with the problem under win32 :-). Thank you very much for your patience!

cramm, well I'm a bit confused, I hope you hadn't spent too much time on the osx issue :/

cramm, what do you think of my proposition about sys.path?

on another topic, it seems that the documentation build with sphinx is no longer possible: http://dpaste.com/65137/

david`bgk: sounds like a good idea, but I don't have enough understanding of the etstin infastrecture. Maybe freakboy3742 could give a more useful and authoritative opinion?

Rakennamme mielell� r��ydyn sivuston k�t� ty�uja jotka mahdollistavat tuomaan esiin sivun keskeinen asia, kuvagallerian.

sorry

where's the block template tag defined in Django source?

I'd like to implement an appendblock tag to be able to append to a block multiple times in a single template

or blockappend

found it

RaceCondition: seems to be in django/template/loader_tags.py:do_block()

oops :)

parser.__loaded_blocks is an array.. hmm. wouldn't a hash/set be faster?