Re: [Bf-committers] Mac BuildBot down

[Trouble Daemon]

Logs show it last cycled the cert on the 17th anyway, so I guess probably
not. Nevermind then.

On Tue, Dec 27, 2016, 1:13 PM Sergey Sharybin <sergey@gmail.com> wrote:

> In theory yes. In practice -- not sure since windows and linux builds are
> running fine.
>
> On Tue, Dec 27, 2016 at 6:41 PM, Trouble Daemon <troubledae...@gmail.com>
> wrote:
>
> > Could it be letsencrypt cert cycling related?
> >
> > On Tue, Dec 27, 2016, 12:36 PM Sergey Sharybin <sergey@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Piece of crap svn client on that machine decided it's fun to discard
> our
> > > server's certificate, which made buildbot to unable to update libraries
> > > folder.
> > >
> > > Gave it a poke, so there should be a new build available soon.
> > >
> > >
> > > On Tue, Dec 27, 2016 at 5:22 PM, Ton Roosendaal <t...@blender.org>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > The system is here in the studio, and it's on.
> > > > It is managed by Sergey or Francesco, both are on holidays :) They
> can
> > > > login remote though. Maybe they read this mail.
> > > >
> > > > Otherwise the bot will be back 2 January latest.
> > > >
> > > > Laters,
> > > >
> > > > -Ton-
> > > >
> > > > 
> > > > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > > > Chairman Blender Foundation, Director Blender Institute
> > > > Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> > > >
> > > >
> > > >
> > > > > On 26 Dec 2016, at 14:13, Joel Godin <joelgo...@ymail.com> wrote:
> > > > >
> > > > > Mac version not updated since Dec 17.
> > > > > not sure where else to post this.
> > > > > thanks
> > > > > ___
> > > > > Bf-committers mailing list
> > > > > Bf-committers@blender.org
> > > > > https://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > https://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards, Sergey Sharybin
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Mac BuildBot down

[Trouble Daemon]

Could it be letsencrypt cert cycling related?

On Tue, Dec 27, 2016, 12:36 PM Sergey Sharybin  wrote:

> Hi,
>
> Piece of crap svn client on that machine decided it's fun to discard our
> server's certificate, which made buildbot to unable to update libraries
> folder.
>
> Gave it a poke, so there should be a new build available soon.
>
>
> On Tue, Dec 27, 2016 at 5:22 PM, Ton Roosendaal  wrote:
>
> > Hi,
> >
> > The system is here in the studio, and it's on.
> > It is managed by Sergey or Francesco, both are on holidays :) They can
> > login remote though. Maybe they read this mail.
> >
> > Otherwise the bot will be back 2 January latest.
> >
> > Laters,
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > Chairman Blender Foundation, Director Blender Institute
> > Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> >
> >
> >
> > > On 26 Dec 2016, at 14:13, Joel Godin  wrote:
> > >
> > > Mac version not updated since Dec 17.
> > > not sure where else to post this.
> > > thanks
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Git repository is very slow again

[Trouble Daemon]

Hi,

What I was trying to say is that the pf firewall is tracking the total
number of IP States that you have open. This would include connections to a
few of our sites that run on that machine. If you happened to be opening a
few to buildbot for a file download (some clients do ranged fetches of
multiple chunks in parallel iirc), something like a git pull while you
still had a bunch of open connection states from downloading from buildbot
could push you over the limit and block you temporarily.

Perhaps this isn't the case this particular time, but more often than not
it is this. Feel free to test this if you like, you won't hurt the servers
feelings 

Worst case you can poke me on irc later if you can reproduce the problem
and I can look more closely at things, maybe even put some limits on
buildbots web server to help avoid this, assuming it's the firewall problem
and not something else, of course.

Dan

On Fri, Mar 25, 2016, 11:42 PM PerfectionCat <sindra1961reb...@yahoo.co.jp>
wrote:

> Hi.
>
>
> I only started bat command with a command console in a usual procedure.
> I do not do the git operation elsewhere.
> I felt that this processing advances when a stage of linux buildbot is
> updated, but will there be this and the relations?
>
>
> PerfectionCat
> Best Regard.
>
>
>
> - Original Message -
> >From: Trouble Daemon <troubledae...@gmail.com>
> >To: PerfectionCat <sindra1961reb...@yahoo.co.jp>; bf-blender developers <
> bf-committers@blender.org>
> >Date: 2016/3/26, Sat 12:19
> >Subject: Re: [Bf-committers] Git repository is very slow again
> >
> >
> >Hi,
> >
> >
> >Server seems to be idle here in the last 30min or so. If you were doing a
> bunch of back to back git operations and web stuff at the same time, it's
> quite possible you got blocked by the firewall for a bit though for going
> over the state limits. If developer.blender.org also stops responding
> when the git slow down happens, this is most certainly the case.
> >
> >
> >
> >
> >Dan
> >
> >On Fri, Mar 25, 2016 at 10:46 PM PerfectionCat <
> sindra1961reb...@yahoo.co.jp> wrote:
> >
> >Hello Devs.
> >>
> >>I cannot update Git repository.
> >>Processing seems to stop.
> >>
> >>PerfectionCat
> >>Best Regard.
> >>___
> >>Bf-committers mailing list
> >>Bf-committers@blender.org
> >>http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Git repository is very slow again

[Trouble Daemon]

Hi,

Server seems to be idle here in the last 30min or so. If you were doing a
bunch of back to back git operations and web stuff at the same time, it's
quite possible you got blocked by the firewall for a bit though for going
over the state limits. If developer.blender.org also stops responding when
the git slow down happens, this is most certainly the case.


Dan

On Fri, Mar 25, 2016 at 10:46 PM PerfectionCat 
wrote:

> Hello Devs.
>
> I cannot update Git repository.
> Processing seems to stop.
>
> PerfectionCat
> Best Regard.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting minutes - February 27, 2016

[Trouble Daemon]

Sergey,

My point was that our R210 server where the docs are built is probably
pretty similar to many users home machines, as far as full build time
estimates are concerned.

As for wiki, I agree it would be nice to reinstall it into a fresh MW setup
and clean things up. I worry though that there would be a lot of work to
put the manual back into the wiki, not to mention the hundreds of man hours
put in sphinx that would be thrown out. Plus to use the wiki as the manual
again would mean old organization and layout headaches for versioning and
localization URL schemes that plagued the old setup, not to mention poor MW
search system that returns wiki markup that people didn't think kindly of.

Dan

On Sat, Feb 27, 2016, 8:34 PM Campbell Barton  wrote:

> On Sun, Feb 28, 2016 at 11:48 AM, Sergey Sharybin 
> wrote:
> > Dan, i'm not talking about compilation on server, talking about
> compilation
> > on my laptop and desktop.
> >
> > Campbell, I don't follow IRC that much, but happened few times there.
> >
> > As for timing, while it's not exact 30min (at least not with latest
> sources
> > etc), it's an order of magnitude more on my core i7 desktop, took almost
> > 10min to do a rebuilt. After doing simple modifications it's in average
> > 5sec.
> >
> > While content was based on existing wiki, remember how much effort was
> put
> > to fix missing pages and broken libraries.
> >
> > In any case, we can compare who's machine is faster, it's all not gonna
> to
> > make things faster here and it's not what's the thread originally was
> about.
> >
> > Let me summarize and stop wasting time and energy in this discussion.
> >
> > - I am an opponent of increasing offline-factor of documentation, it just
> > adds extra complexity without solving any real issues, or will have the
> > same technical aspect issues if they're becoming any more popular for
> > editors.
> > - I am also an opponent of using dev.b.o's wiki: it is a limited wiki
> > engine, it would have more issues as any stand-alone wiki, it wouldn't
> > really be any more sustainable to abuse that the current wiki.b.o and i
> do
> > not want dev.b.o being abused in any way.
> > - I do agree with the fact that we should fresh install wiki and not have
> > any piss-poor hacks in it, and keep it maintainable, accessible by the
> > community.
> > - I do believe with freshly installed and properly configured wiki we can
> > avoid splitting of any documentation further, and to keep documentation
> in
> > an actual non-broken state we'll need a strong editor team (we'll need it
> > with any underlying tool for docs/manual, it's not something new, it is
> > just something current wiki is lacking completely).
>
> +1 this has been the plane for some time anyway, closed T47563.
>
> In the future it would be good if we could discuss topics without knee
> jerk reactions and mixing up multiple topics.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting minutes - February 27, 2016

[Trouble Daemon]

Sergey,

Sure, I think cached php can be fast enough, but caching has it's own
problems sometimes, as you are well aware.

As for build times, it only takes one of the R210's about 5-10min to do a
full build (8 core xeon @2.4ghz iirc).

Dan

On Sat, Feb 27, 2016 at 6:27 PM Sergey Sharybin 
wrote:

> As for instructions -- it's somewhat depends. Sometimes instructions work,
> sometimes they don't We still have users who followed those instructions
> and had issues getting manual fully built. Surely it's something caused by
> a particular setup on that machine, but it is just wrong claiming that
> everything works just fine and leaving contributors all alone with those
> issues.
>
> Julien, i recon it bullshit to wait 30min for the manual to be compiled
> when you only need to fix single typo. Surely you can commit stuff directly
> without local check, but that's only asking for even bigger problems.
>
> Brecht, Thomas, the quality of those docs are not increased by Sphinx
> itself, it's just because people invested fewzillion effort to re-do manual
> from scratch. Same could have been easily done with existing Wiki manual.
>
> Dan, i bet we can configure new wiki in the way it works reliable and fast
> enough.
>
> If we have strong coordination work happening around documentation, i do
> not see any reason to commit to any global changes and diverge things and
> raise the entry barrier any further. That coordination could easily happen
> inside of wiki (assuming it gets re-installed and updated to all latest
> versions of everything and cleaned up all the configs).
>
>
> On Sat, Feb 27, 2016 at 11:46 PM, Julian Eisel 
> wrote:
>
> > Spent some time thinking about this (wiki vs Sphinx) and after all I
> > agree with Brecht & Thomas as well.
> >
> > On a first look, the instructions for building the manual might make
> > the appearance as if there was quite some work needed, but this really
> > isn't the case. It's mostly a matter of copy-pasting 3-6 commands
> > (including cd commands).
> > Don't remember how long the build time was, but I doubt it would take
> > anyone longer than ~30 mins to get everything set up.
> > Again I think it is much easier than it may seem. Maybe some video
> > tutorials could illustrate this a bit better.
> >
> > Sphinx isn't no magic bullet, but I don't think wiki is either. And
> > regardless of the amount of individual contributors, I think the
> > manual is in a pretty good shape now :)
> >
> > Just my two cents.
> >
> > Cheers,
> > - Julian -
> >
> > On 27 February 2016 at 23:35, Dan McGrath 
> wrote:
> > > Lets not forget the fact that the new manual ultimately is a bunch of
> > plain
> > > html (well, not all, but static at least) files here, no php to crash,
> > > hack, upgrade blah blah. Speed-wise, it's hard to beat the performance
> > for
> > > this type of setup.
> > >
> > > Dan
> > >
> > > On Sat, Feb 27, 2016 at 4:52 PM Thomas Dinges 
> > wrote:
> > >
> > >> I agree with Brecht here.
> > >>
> > >> The entry barrier is a bit technical, agreed. But following the steps
> on
> > >> how to set it up in the Manual, it was a 5 minute job.
> > >> After that it's not difficult anymore. Visually the new manual is much
> > >> better and well structured, I missed that in the old wiki.
> > >>
> > >> Best regards,
> > >> Thomas
> > >>
> > >> Am 27.02.2016 um 22:48 schrieb Brecht Van Lommel:
> > >> > I'm a bit surprised that the manual is coming up as an issue now,
> > >> > there's been a lot of good work done there in the past few months.
> > >> >
> > >> > Even if it's just a few people doing most of the work, in my opinion
> > >> > that's just how most open source projects work. A small dedicated
> core
> > >> > and then smaller contributions from other. And I see commits from
> > >> > developers like Bastien, Thomas, Dalai, Gaia, Julian, Tamito and
> > >> > contributions from other people too. I don't think the wiki manual
> was
> > >> > more active?
> > >> >
> > >> > It would be good if the barrier could be lowered, maybe including
> > >> > sphinx python modules in the svn report, a Blender addon to help, I
> > >> > don't know. And certainly I would like all developers to document
> > >> > their work in the manual directly.
> > >> >
> > >> > But in my opinion the result is already much better than what we had
> > >> > in the wiki, without so much wrong information, broken links,
> warnings
> > >> > about reorganizations that never happen, etc.
> > >> >
> > >> >
> > >> >
> > >> > On Sat, Feb 27, 2016 at 9:02 PM, Campbell Barton <
> > ideasma...@gmail.com>
> > >> wrote:
> > >> >> On Sun, Feb 28, 2016 at 2:45 AM, Sergey Sharybin <
> > sergey@gmail.com>
> > >> wrote:
> > >> >>> So the actual issue is a lack of coordination work for
> contributors
> > >> and the
> > >> >>> reason why Manual is still in a reasonable shape is simply only
> > >> because all
> > >> >>> the contributors are 

Re: [Bf-committers] Installer for Windows is not signed

[Trouble Daemon]

And then there is the fact that anything that isn't stored in a smart card
offers no accountability whatsoever as the cert can and will be mailed
around with little to no regard for security (ie, not gpg signed nor
encrypted, etc.), which means the signed binary has no meaning and only is
being used to silence a windows warning.

Being realistic, I can't see signing happening unless it becomes mandatory
to run apps, or if someone pays for the cert and the process isn't terribly
time consuming to the windows (and osx?) Devs. Heck, gpg is free, as is md5
and sha unix tools, and we don't even make signed checksum files available
along side the downloads!

Dan

On Fri, Oct 16, 2015, 1:16 AM Martijn Berger 
wrote:

> No they where never signed. The issue is getting a cert. Once we have that
> singing is trivial.
> On 16 Oct 2015 03:11, "Mike Erwin"  wrote:
>
> > Weren't other recent releases signed though? It is kind of unnerving when
> > Windows pops up a "Do you trust this Unknown Developer?" alert during
> > installation.
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Thu, Oct 15, 2015 at 7:34 PM, Aaron Carlisle <
> > carlisle.aaro...@gmail.com>
> > wrote:
> >
> > > Yes Blender is a safe program
> > >
> > > On Thu, Oct 15, 2015 at 10:07 AM, Yury Baranov 
> > > wrote:
> > >
> > > > Hi. I just mentioned that installer is not signed by developer. Is it
> > OK?
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Withdrawal

[Trouble Daemon]

What about using git notes?

  https://kernel.org/pub/software/scm/git/docs/git-notes.html

Dan

On Mon, Sep 15, 2014 at 10:10 PM, Campbell Barton ideasma...@gmail.com
wrote:

 To follow up on a related point.

 Making this list of bugfixes is quite time consuming and unless you
 read the commit logs daily _and_ know the code, its quite hard to tell
 which issues to include in the release log.

 It would be good if there was some indication from a commit to know if
 the bug is from some recent change, or if its a bug in the previous
 release.


 Suggest we could indicate this in the subject:

 - Fix T1234: Some Text
 - WIP Fix T1234: Some Text
 - Regression Fix T1234: Some Text


 Meaning:

 - Fix - regular fix for a bug existed in last release.
 - WIP Fix - fix for change in new code (never in a release)
 - Regression Fix - fix for bug introduced in a release.


 Many fixes would be WIP, so at a glance we can tell not to include
 (its useful for reading commit logs too).
 Often I write something like Fix for recent change in ... so typing
 'WIP' is less hassle.

 Although I'm not sure its practical to enforce this long-term (we
 attempted complicated conventions before and ended up not using).

 Any suggestions?

 On Mon, Sep 15, 2014 at 5:08 AM, Gavin Howard gavin.d.how...@gmail.com
 wrote:
  Well, if I don't get it done, you have to. The time constraint was so
  you could expect it done before having to work on it yourself.
 
  On Sun, Sep 14, 2014 at 1:04 PM, Sergey Sharybin sergey@gmail.com
 wrote:
  Sounds cool, only not sure why to define such a time constraints?
 
  On Mon, Sep 15, 2014 at 12:59 AM, Gavin Howard 
 gavin.d.how...@gmail.com
  wrote:
 
  In reality, Ton, I sent that email only to you; I didn't know Sergey's
  address, I didn't want to spam the mailing list, and I was already too
  embarrassed. (So much for that.) So it's not Sergey's fault. And
  neither is it yours; I know you're busy, so I was planning on
  resending the email today anyways. But I should have sent it to the
  whole list. Yet another mistake. Sorry.
 
  The truth is that I'm not frustrated with you all. What did me in was
  going back through and trying to clean up the fixes as Sergey said. I
  thought I understood what he said, and I realized that I didn't. Like
  I said, it was my own incompetence at following simple instructions.
  Just to be clear, I never thought I was insulted. I simply get
  frustrated with myself quite easily, especially after last summer.
 
  Sergey, your clarifications helped. (I think.) Give me 24 hours to go
  back through and get it up to standard.
 
  God Bless,
  Gavin Howard
 
  On Sun, Sep 14, 2014 at 9:31 AM, Sergey Sharybin sergey@gmail.com
 
  wrote:
   I didn't actually see your mail from monday. Either it got lost
 somewhere
   in my client or i dunno.
  
   As for the fixed bugs section it's not that bad actually, the stuff
 Ton
   mentioned in the minutes are just guidelines for that page to make it
   maintainable. It doesn't mean it's fully wrong or so. Main issue
 with the
   page is that it lacks information about the revision range it's valid
  for.
   So if you suddenly becomes busy and i (or cambo or whoever else) need
   finish it -- it'll be rather tricky to figure out where to start. To
  avoid
   such issues, we put on the top of the page:
  
 Changes from revision AAA up to BBB
  
   It should be really easy for you to add information about revision
 your
   list is updated to.
  
   Other issue is that i saw quite a few fixes which were a fixes for
 new
   stuff added to 2.72. We don't mention that in the change log. It
 should
  be
   easy for you again to just ignore such fixes for the rest of the
  revisions
   from now on up to the very release. We'll need to clean up existing
 list
   from those fixes, but for that you can have at least mine help, and
 as
  max
   -- there could be more volunteers to help cleaning stuff up.
  
   And the structure issue is also not that difficult to solve. It's
 just
   matter of using old structure and copy-pasteing new fixes to it. Or
   renaming the sections, so Modeling is more like a Mesh Editing,
  Compositor
   is Node / Compositor and such. Sticking to some standard template
 is
  good
   for the readability of changes imo. And for this you can also use my
 help
   or help from someone else in the community.
  
   So to summarize, there is some clean up to be done on the fixes
 page, but
   it's not that much of work and it doesn't mean you need to do it all
  (we'll
   for sure help with the cleanups and so). And consider information
 from
   Ton's mail about fixed bugs section as a guideline for the future
 work on
   that section. Do not consider it as an insult on your work, we really
   appreciate your help.
  
   On Sun, Sep 14, 2014 at 9:11 PM, Ton Roosendaal t...@blender.org
 wrote:
  
   Hi Gavin,
  
   Sorry, it's unfortunate that nobody replied to your mail from last
  monday.
   I had no time 

Re: [Bf-committers] GIT connection problem in release/scripts/ addons_contrib

[Trouble Daemon]

Hi Vicente,

Replies inline.

On Sun, Jun 22, 2014 at 7:00 AM, Vicente vicenteca...@gmail.com wrote:

 Yes, I can browse in git.blender.org without problems, I can see the
 commits and even the diffs.


Well that is good in that it shows you can make the actual connection to
the server via TCP, and aren't being firewalled (at least not initially). I
did see your requests in the logs for your browser. It doesn't sound like a
problem with firewall as you wouldn't be able to do anything with git (http
or otherwise), or ping the machine if it blocked you. A good test would be
to try ping or visit the git repo in a web browser immediately after you
try a git pull.


 But happens that sometimes I get an error loading blender.org, like if
 the timeout were too low. So if it didn’t respond in 5 secs, then I get
 an error page. I don't know but maybe is related.


The blender.org server is a different machine and occasionally goes down.
This last week it was down for a bit due to an unplanned upgrade (a lib got
upgraded separately from the web server and broke its restart). It also
would have been restarted a bunch of times (quick second/sub-second
restarts to reload the fast cgi process) for Francesco's work on an
upcoming blender web service, but otherwise should be up.


 Oh and my connection is 100/100 optic fiber, so speed should not be the
 problem. But I'm in Iceland and sometimes the ping can be high (right
 now the ping to git.blender is 50ms, nothing special).


That is actually a great ping (better than I get from Canada). I wonder if
the speed and latency of your connection is just hitting the services too
fast for the firewalls taste. Many of the rules are relics from some of the
initial installs for blender.org servers and could probably stand to have
some of their limits raised a bit. It is a little tricky though without
monitoring everything at a forensic level so they we can numerically define
the difference between normal and abuse, with regards to TCP connections.



 And here my config.
 $ cat .git/config
 [core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
 [remote origin]
  url = http://git.blender.org/blender.git
  fetch = +refs/heads/*:refs/remotes/origin/*
 [branch master]
  remote = origin
  merge = refs/heads/master
 [submodule release/datafiles/locale]
  url = http://git.blender.org/blender-translations.git
 [submodule release/scripts/addons]
  url = http://git.blender.org/blender-addons.git
 [submodule release/scripts/addons_contrib]
  url = http://git.blender.org/blender-addons-contrib.git
 [submodule scons]
  url = http://git.blender.org/scons.git

 But yesterday before sending the email report  I changed all the git
 protocols by  http, just to try. But the error is the same.
 I have to add that sometimes other parts of the repository are
 unresponsive but if I retry a few times they work, except addons_contrib.


Strange indeed. Having your neighbours have problems doesn't sound right.
There isn't anything I can think of at the IP level that would affect only
addons-contrib.git though; you would either be able to connect to the
server, or you wouldn't be. As mentioned above though, if you were making
new TCP connections too quickly, the server might have blocked you for a
period of time. Perhaps this is what is happening. At worst, if you could
pop on irc for something more realtime, I can probably track the state of
your IP better while getting you to run some test connections.


 I send you my IP in a private message.


Thanks. Unfortunately I couldn't see anything that would answer this
problem on that IP. I made a few tweaks to the firewall to ease things for
git. I guess give it another shot and see if that helps. Please let me know
if there is still a problem.


Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] DNS down again...

[Trouble Daemon]

Those IP's are fine. Worth mentioning is that on windows you have to edit
the file:

  C:\WINDOWS\system32\drivers\etc\hosts

However the file needs to be edited with an administrator account. In the
start menu you can find notepad and right click it, and then click Run as
Administrator, then browse to the file above and add the IP's.

Out of convenience here is a list of the most common hosts:

82.94.213.213  builder.blender.org
82.94.213.217  svn.blender.org
82.94.213.218  wiki.blender.org
82.94.213.221  download.blender.org
82.94.226.99cloud.blender.org
82.94.226.100  developer.blender.org
82.94.226.104  www.blender.org gooseberry.blender.org
82.94.226.105  git.blender.org

As nice as it is to have static entries for DNS in your hosts file though,
I _strongly_ advise you not to use them unless needed. Hosts entries have a
habit of making you oblivious to DNS problems, as well as causing headaches
for people trying to troubleshoot problems when we change the IP addresses
(although rare, it does happen without warning).


Dan


On Sun, Apr 13, 2014 at 7:41 AM, Ton Roosendaal t...@blender.org wrote:

 Hi,

 For the record, if DNS goes down again, here's the IPs you can set in your
 hosts file. The unix gurus here can tell if that's true though :)

 git.blender.org (82.94.226.105)
 developer.blender.org (82.94.226.100)

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute
 Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



 On 13 Apr, 2014, at 4:28, Dan McGrath wrote:

 
  Just a heads up that for the past few hours that our DNS provider,
 PowerDNS.net, appears
  to be down again. While some sites may still work fine due to our 24
 hour TTL (cache)
  on host names that you have recently done DNS lookups on, this will
 eventually expire
  and leave you unable to contact the various blender.org servers.
 
  Hopefully it doesn't last much longer, but you will probably know it is
 working again when
  all of the email from normal mailing list trafic starts to get through
 (aside from this email
  which was sent from the server itself).
 
  I should also mention that our ISP has warned us about a brief network
 disruption on April 15
  at 11am or so for a few minutes, but this should be over quickly enough
 that most people
  probably wont notice.
 
 
  Dan McGrath
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bundling Python `requests` module for 2.70

[Trouble Daemon]

Hey,

I did a local pip install of the requests file to take a look at the
cacert.pem file. It would appear that it is a copy of all the main
certificate authorities for use with SSL, so it would be rather large.

I was a little concerned to see other posts online (
https://mail.python.org/pipermail/python-dev/2013-October/129755.html) that
mentioned things like being slightly out of date, ignoring checks for
revoked certs, and what not, so they seem a little on the slow on the
update end of things.

I can't (won't) verify the actual authenticity of all of those certs to
prove that they aren't fake or anything, but probably minor since only
HTTPS requests using this lib would be able to be MITM'd if there were some
fakes in there (unless they found a way to install into your browser
storage via another script since users generally have full access to their
own browser settings, for example).

Personally I wish they would set this up to point at the system maintained
certs, but these paths vary too much on the OS's and would require root
access. If you ask me, it is a can of worms to install CA files on to a
users system as that is half of the attack (getting the file on someones
computer, the second being to install it in the proper place and MITM a
users connection). Wouldn't it be better to leave out and tell the user
that if they want SSL, they should configure the library to point at the
system wide certs instead?


Dan



On Mon, Feb 17, 2014 at 10:35 PM, Campbell Barton ideasma...@gmail.comwrote:

 This is coming a bit late in the release cycle, but I've been asked to
 review an addon for Sketchfab, to see if we can include in 2.70.

 The addon its self is quite small and wont be enabled by default,
 however its using a python module called `requests`.

 Most likely this can be used by other scripts too since its a popular
 module.

 Bundling this isn't such a problem since this is pure python (just zip
 it up and include in lib/ for OSX, MS-Windows, Linux can copy from
 from Python's install dir).

 However this will take some work to update scons and cmake, and
 testing it works.

 Theres the issue of incresed size, did a quick test and it bzip2's
 down to 342kb,
 Though much of the space is used by `cacert.pem`,  without that file its
 180kb

 I did a quick check and seems that file is optional since you can use
 cacerts provided by the system instead (but not totally sure at the
 point).


 So I'm proposing to include the Python module,
 I'll setup SCons and CMake for Linux and Windows and upload requests
 archive to lib/, but will need someone else to handle OSX or at least
 test it works ok.


 To be clear, Blender wont execute anything extra by default on
 startup, this just makes a Python module available for scripts to use
 if they need, and increases Blender's download size.

 ---

 Extra info.

 Addon URL if anyones interested:
 https://developer.blender.org/D321

 Requests website:
 http://requests.readthedocs.org
 --
 - Campbell
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] sdl/glfw based GUI toolkit for Blender

[Trouble Daemon]

 To write the conventions and rules of code, for later widget developers, I
 still need to implement a small part of the code. If you have ever used
 Delphi or Lazarus, you will get the idea of how it will be. The difference
 is that to someone connect an signal, instead of do the following:


Ah, I thought that TApplication and other T references in your previous
post looked suspiciously familiar! Another Pascal user \o/ :)


Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender soft select feature

[Trouble Daemon]

It sounds like you are looking for the proportional editing feature? Try
press O while in edit mode and adjust with the wheel mouse.

That being said, keep in mind that this list is more for coding than
tutorials or general questions about how to use blender :)

Anyways, hope this helps?


Dan


On Tue, Nov 26, 2013 at 8:14 AM, Crs Mrn mahri...@gmail.com wrote:

 Hi. I have some questions. Does Blender have something similar to soft
 selection in Maya? That feature is very useful, especially for morphs. Soft
 selection is something like that: you click a vertex, and all the vertices
 around get some colours.(usually yellow red and black). If you translate
 the vertex, the yellow vertices around move with it, red move a little and
 black very little. By holding the B key, you can get the fallof circle
 radius bigger or smaller. The soft select can be customized with a feature
 named falloff curve. I think that soft select is a great tool for morphs or
 for precision sculpting. Does Blender have something similar? I miss that
 tool.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Are our git tags out of date?

[Trouble Daemon]

Hey,

I see. Well, from local tests here, the problem will go away the next time
a `git tag -a` is run:

  dan@wks:~/blender-build/testgit$ git describe master
  v2.70-1-g4eac1c8
  dan@wks:~/blender-build/testgit$ vim GNUmakefile
  dan@wks:~/blender-build/testgit$ git commit -a
  [master fcafbfd] Undo last test commit
   1 file changed, 1 deletion(-)
  dan@wks:~/blender-build/testgit$ git describe master
  v2.70-2-gfcafbfd

Interesting that it has a handy auto increment field between the tag name
and the hash. While we are on the topic of tags though, I was wondering
when the tags will be applied. My assumption is that the next RC will be
the start of this? Also, once the tags are back working again, will we
switch to using this describe output as the splash screens version number?


Dan



On Sun, Nov 24, 2013 at 9:11 AM, Sergey Sharybin sergey@gmail.comwrote:

 git describe master gives latest tag which is reachable from the HEAD
 of master branch. And the thing is: in svn we've created a tag from
 trunk and backported several commits there before actual release.

 What happened during svn-git converts is that every release have own
 branch created at the same moment as tag happend in svn. Then all the
 revision were backported to git branch. Tag was created in git branch
 and it totally corresponds state of svn state.

 Such tags for sure are not reachable from the master branch and that's
 why you can not see them with git describe. Not a bug, just different
 in how tags are handled in svn and git. Nothing to worry about i'd
 say.

 On Sat, Nov 23, 2013 at 6:52 PM, Dan McGrath danmcgrath...@gmail.com
 wrote:
  While watching an advanced git video (which btw, is a nice follow up to
 the
  Git video by Scott from the other day):
 
https://www.youtube.com/watch?v=ig5E8CcdM9g
 
  I noticed that when he got to the section on tags vs. annotated tags
 (~30+
  minutes in, iirc), that the command:
 
git describe master
 
  gave the output:
 
v2.66-6202-g2cb6348
 
  This got me to thinking that maybe we are missing a few annotated tags
 (git
  tag -a rev) in the repo?
 
  Anyways, just something I noticed and thought that I would inquire about,
  and also to point out an amazing advanced git video! o/
 
 
  Dan
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers



 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] SVN server issues

[trouble daemon]

Apparently the server is playing early April fools jokes on the devs ;)


On Sun, Mar 31, 2013 at 7:16 PM, Thomas Dinges blen...@dingto.org wrote:

 Hi,
 just a quick note, SVN server has some issues currently, according to
 Campbell the disk is full.
 Therefore SVN up and commit does not work atm.

 Best regards,
 Thomas

 --
 Thomas Dinges
 Blender Developer, Artist and Musician

 www.dingto.org

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particle system / Material choice / implementation of do_versions : problem with preview.blend

[trouble daemon]

Hi!

First of all, I love the idea of finally replacing silly numbers with
actual names of materials! Surely this has been a feature request of
everyone that uses blender since they were added :)

But what I question is why you would need a do_versions? Would it not make
more sense to leave the underlying value as a number, but just change the
display to be a looked up value from some py dict or enum or something?
This would allow it to just work.

Anyways, forgive my ignorance as I am not aware of what the typical
approach to this would be in blender. And thanks again for working on this
type of number - string mapping! :)


Dan


On Sat, Mar 30, 2013 at 8:46 AM, Julien Duroure julien.duro...@gmail.comwrote:

 Hi all,

 I implemented some code to replace, in particle render section, the
 material index ( 1, 2 or 3 for example ), by a direct material choice (
 Material, Material.001, etc...)

 Code is now OK, but I am currenly working on do_versions, to be able to
 open old files with this new feature.

 I try to implement this kind of code : http://pastebin.com/Czy3rfqZ
 But I have a segfault when access on part-omat.
 It seems to be linked to preview.blend objects.
 GDB said that psys-part adresse can't be access.

 I don't know how preview exactly works : is there someome can explain me
 why I have this problem and how to correct it ?

 Thanks  Regards,

 Julien
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Particle system / Material choice / implementation of do_versions : problem with preview.blend

[trouble daemon]

Hi,

While I don't know the how the blender devs usually tackle this problem, I
can say that in many other areas of computers, this is pretty common
practice.

Some examples where this is done would be web forms and databases. In web
forms, you might pass a list of items with some numerical, or abbreviated
form of a value, along with a textual representation. eg., 1 - Canada,
2 - USA, etc.

In databases, this value would be the primary key. While it isn't unheard
of to use the string value itself (natural key) as a primary key, many
schema use a numeric auto-increment value, which iirc is called a surrogate
key when used in this number-name fashion, if only since many libraries
and frameworks that work with databases depend on only numeric values for
easy mapping for their ORM. See
http://en.wikipedia.org/wiki/Surrogate_keyfor more.

In the case of blender, sticking to using a number only would avoid
breaking any existing files (since it would use the current value still),
and would be smaller to store a number versus storing text, in addition to
avoiding a do_versions requirement. I guess I am wondering why a if up of
the current name by passing the material slot number to a function is hard
to do in blender?


Dan


On Sat, Mar 30, 2013 at 12:11 PM, Julien Duroure
julien.duro...@gmail.comwrote:

 Hello,

 I don't think it a good idea to display material, and to store only
 integer. I think ( but I am not a regular blender dev ) it must be
 consistent between what we see and what we store.
 That's why In my current implementation, I replace Integer Material Index
 by a material' pointer.

 In do_versions, I only have to retrieve material corresponding to each
 index, using give_current_material
 But I have the problem I explain in my previous email...

 Regards,

 Julien

 On Sat, Mar 30, 2013 at 2:46 PM, trouble daemon troubledae...@gmail.com
 wrote:

  Hi!
 
  First of all, I love the idea of finally replacing silly numbers with
  actual names of materials! Surely this has been a feature request of
  everyone that uses blender since they were added :)
 
  But what I question is why you would need a do_versions? Would it not
 make
  more sense to leave the underlying value as a number, but just change the
  display to be a looked up value from some py dict or enum or something?
  This would allow it to just work.
 
  Anyways, forgive my ignorance as I am not aware of what the typical
  approach to this would be in blender. And thanks again for working on
 this
  type of number - string mapping! :)
 
 
  Dan
 
 
  On Sat, Mar 30, 2013 at 8:46 AM, Julien Duroure 
 julien.duro...@gmail.com
  wrote:
 
   Hi all,
  
   I implemented some code to replace, in particle render section, the
   material index ( 1, 2 or 3 for example ), by a direct material choice (
   Material, Material.001, etc...)
  
   Code is now OK, but I am currenly working on do_versions, to be able to
   open old files with this new feature.
  
   I try to implement this kind of code : http://pastebin.com/Czy3rfqZ
   But I have a segfault when access on part-omat.
   It seems to be linked to preview.blend objects.
   GDB said that psys-part adresse can't be access.
  
   I don't know how preview exactly works : is there someome can explain
 me
   why I have this problem and how to correct it ?
  
   Thanks  Regards,
  
   Julien
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OpenGL Dependency Report and Script

[trouble daemon]

50/50 offtopic/related to another post /warning

Actually, I thought it was fine, other then the odd extraneous print
here, or function param there ;) Still, neat stuff. I don't know
python, but thought your code seemed to nicely cover enough key areas
that it interested me.

I was wondering though if you caught the message here earlier about
the clang reports? After glimpsing your code, it seemed like it had
all the parts one would really need to use to parse the clang reports
for differences.

Anyways, very cool and thanks for sharing/inspiring :)

On Thu, Apr 26, 2012 at 12:41 AM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
 In preparation for SoC I have started to study how Blender uses OpenGL

 Here is a report I generated:
 http://www.pasteall.org/31251/

 Here is the script I used to generate it:
 http://www.pasteall.org/31252/python

 You need to download a full glew to run it (and edit the file paths
 inside the script).  I'm a novice python user, so please don't mind
 how primitive my code is ;)

 There are some obvious problems, the main one is that I assume each
 token belongs to exactly one opengl extension, which I do not think is
 true at all.  The other is that some tokens inside Blender mimic
 OpenGL symbols.  I think one of my first tasks will be to find those
 fake opengl symbols, like glMats, and rename them.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Status of 2.63 release

[trouble daemon]

Okay, here are yer regression results, test on 64bit ubuntu 11.10 r45976:

animation/cubesphere.blend:
 - speed[0] red/broken, making timeline scrub have no effect
 - console: Failed to resolve data path: ('.speed',)

animation/timeline.blend:
 - file is fine itself, but noticed that multiple markers raise when
in close proximity to the current frame. Problem being that if you
have a large number in a small area and the time line is zoomed out,
you get a blur of text for the marker names as seen in the following
pics:

 http://www.pasteall.org/pic/30817  and  http://www.pasteall.org/pic/30818

compositing/zmask_compo.blend:
 - The zmask seems to be fine, but something changed with the grass
particles; it lost its curves and is straight up/taller than it shows
in the shipped render result

 http://www.pasteall.org/pic/30819

gameengine_bullet_softbody/webskategirl_bullet.blend:
 - Needs an svn up back to previous version, was accidentally
overwritten with previous file torus_complex.blend

gameengine_logic/actuators/property1.blend:
 - TODO: Should probably start in game engine render mode, and have
debug properties enabled to verify the numbers work as expected,
otherwise works fine

gameengine_logic/actuators/property2.blend
 - TODO: Investigate why doors don't do anything

gameengine_logic/actuators/sound.blend:
 - Sound doesn't coincide with impacts, and possibly a click/stutter
that cuts off one of the sounds as well (OpenAL)

gameengine_physics/2Dexample.blend:
 - Game seems to work (cept periodic stutter), but has some console errors:
  Python script error - object 'Cube', controller 'cont4':
  Traceback (most recent call last):
 File Main, line 7, in module
  NameError: name 'GameLogic' is not defined

gameengine_physics/genericConstraintSpringLimitMotor.blend:
 - Seems to run, but has some console errors:
  Python script error - object 'CubeChild.002', controller 
'cont':
  Traceback (most recent call last):
 File rotationalMotor, line 17, in module
  AttributeError: 'SCA_PythonController' object has no 
attribute 'getOwner'

gameengine_visual/screenspace.blend:
 - Doesn't seem to do anything anymore, assume out of date py script


[Skipping all io_tests]


modifier_stack/array3.blend:
 - _horrible_ 5fps frame rate now, even in wireframe mode (use to run
beautifully, pre bmesh or so), but runs great if I disable the second
array
 - console error on render: node_composit_exec_viewer error

paint/lockingTest.blend:
 - Runs just fine, but noticed an insane amount of console printf's to
inform me of locking (one line per brush stroke increment or so)

particles_and_hair/particle_dupligroups.blend:
 - Seems to render fine, but a bunch of console errors (5 in total,
and 5 objects missing in render, smells like it's related to cookie
challange!):
  Dependency cycle detected:
 Mball depends on Cube.014 through Particle Object 
Visualisation.
 Cube.014 depends on Mball through Particle Object 
Visualisation.

particles_and_hair/softhairtest.blend:
 - Something broke hair, doesn't seem to sway like it used to any more

physics/softbodytest.blend:
 - Seems to run fine, but file should be fixed later:
  Sphere depends on Sphere.001 through Field Collision.
  Sphere.001 depends on Sphere through Field Collision.

rendering/cycles/bmps.blend:
 - Seems fine, but some console cyclic errors that someone may want to
double check:
  cyclic OBCamera.001
  cyclic OBCircle.001
  cyclic OBCircle
  cyclic OBLightBackBig.001
  cyclic OBLightPlaneBig.001

ui_tests/space_headers.blend:
 - Console errors:
  /d/blender_dev/code/lib/tests/ui_tests/: No such file or 
directory

ui_tests/space_types.blend:
 - Console error when switching to File Browser screen in linux:
  /c/: No such file or directory


On Thu, Apr 26, 2012 at 5:26 AM, Campbell Barton ideasma...@gmail.com wrote:
 Thanks! that'd be great, I'm not so worried about testing the
 regressions on all OS's - most of the BMesh integration issues are not
 64bit spesific.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] PVS-Studio Static Analysis

[trouble daemon]

Interesting problem you have here. While I don't understand all the
errors themselves per se, I did take a look at the root web page and a
few samples of reports, along with a glimpse at the html it generated.

My initial thought would be some sort of regex like parser that would
be very similar in theory to the perl swatch script, or the
logwatch. To summarize the aspects of these that would relate to this:
swatch lets you setup regex rules to match or ignore entries in any
text file, and can vary the color of the output, ignore it, or perform
some action on a match. While logwatch is similar, it basically has a
list of ignore rules/regex, and has formatting information for all the
different syslog (and friends) log formats that it can parse out the
junk (like timestamps and pid's).

I figure that if someone felt like spending an evening, they could
probably take the 2 key concepts (regex, and ignore rules per file
and/or error) from these two programs and toss them into an html
scraper script, you could probably get something that could alert you
to just the stuff that has changed. For example, looking at a few
different reports, I noticed a trend of the same file to have the same
error on the same line number. Clearly in such a case, this output
should be placed on the ignore list (well, assuming you choose to
ignore it), and only report on changes where there is a new primary
key of sorts, constructed from the uniqueness of the filename, error
type and line number.

The big problem I see with this, would be maintaining the script in
the event that the html of the clang reports changes. This is actually
the type of problem that I ran into when making the blender filesize
chart, namely that over time, the conventions used to name files and
indicate features was different per arch, release and feature set,
thus making it near impossible to script or automate anything without
hand verification.

I suppose the question is, how important would something like this be,
who will write it, how will it be written (perl+dbm, python+sqlite,
etc etc etc), who will maintain it, who will use and benefit from it.
Tbh, it sounds like a can of worms :)

Anyways, felt like chiming in, later guys o/



troubled

On Wed, Apr 25, 2012 at 9:36 PM, Campbell Barton ideasma...@gmail.com wrote:
 While its probably possible to setup some `good enough` solution using
 diff, I tend to agree with Jason - that you need something more
 comprehensive so some minor edits to a file doesn't give you a lot of
 changes to the diff to read through that are in fact only line number
 change or re-ordered functions.

 Even though you could probably skim-read the diff and tell new
 additions from line-number offsets - blenders is changing fast enough
 that doing this every day would become a time waster IMHO.

 Another issue with diff, clang outputs HTML or PList (some apple xml?)
 - so diffing this output needs someone to work on a tool for that
 specifically.

 Checking if number of reports changed was OK until clang started
 crashing in some of our source code, so now it gives different bug
 count every run.
 http://clang.blenderheads.org/trunk/

 (yes, I realize some bug could be added and another removed between
 revisions - so its not foolproof).


 On Thu, Apr 26, 2012 at 8:57 AM, Jason Wilkins
 jason.a.wilk...@gmail.com wrote:
 If the source line changes then diff isn't a good enough tool.  What
 is needed is a that these programs need to maintain a database that
 keeps a signature of each problem that is basically an AST of the area
 affected and is independent of source line and whitespace changes.
 Then you could annotate this database with information about false
 positives instead of your source.  Such a database might even be able
 to keep new false positives from appearing if you duplicate the
 problem exactly in a different source file.

 On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen
 rus...@eecs.qmul.ac.uk wrote:
 Running a second time gives you only the false positives again.
 If some new bug is added to the source you still needed to read over
 the false positives (unless your memory is really good).

 long term we need to have a way to notify us when new errors are added.
 Sounds like a job for diff?

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers



 --
 - Campbell
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Status of 2.63 release

[trouble daemon]

If I am not mistaken, I thought I seen a commit a few revisions ago
today that specifically mentioned something about disabling bevel for
release because of a discussion and/or problems. Not sure if that
answers your question though.

Ah yes, here it was:


r45962 | campbellbarton | 2012-04-25 06:24:31 -0400 (Wed, 25 Apr 2012) | 2 lines

disable bevel for release after discussion with brecht and sergey,
this works far too poorly to be included in release.


On Thu, Apr 26, 2012 at 12:05 AM, Thomas Dinges blen...@dingto.org wrote:
 Hi,
 what is the status now?

 According to sergey yesterday, we wait for a last minute bevel fix
 (patch was sent to Campbell to check) and the Splash.

 Thomas

 --
 Thomas Dinges
 Blender Developer, Artist and Musician

 www.dingto.org

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Numpy integration

[trouble daemon]

+1

I gotta say that I kinda agree with the whole size thing being minor
these days. Besides, the most likely internet access that would have
low caps would be stuff like 3G or similar, but how many people are
going to be downloading blender releases on their cell phones and
iPads?

I think it really depends on if the size increase is justified. If
adding 3MB to the size of the download will allow plugin authors to
add new functionality they couldn't easily do otherwise, or to save a
portion of that through eliminating common repeated code across
multiple addons, then why not?

Not that I am saying size shouldn't be considered in the long run, but
there are plenty of ways to deal with size bloat, including things
like binary diffs or just using existing incremental update systems
like svn. Worst case, just offer diffs between releases for the more
advanced users or something perhaps.

Anyways, my $0.02 :) o/

On Mon, Apr 23, 2012 at 1:53 PM, Knapp magick.c...@gmail.com wrote:
 Given today's 3tb hard drives why are we worried about 10 or less MBs?
 The only problem I could see are people with expensive download rates
 (and I am not sure if they exist any more) or really slow connections.
 I know that bloat is seen as a bad thing at 3 MB but is it really all
 that much bloat given today's computers?

 --
 Douglas E Knapp

 Creative Commons Film Group, Helping people make open source movies
 with open source software!
 http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

 Massage in Gelsenkirchen-Buer:
 http://douglas.bespin.org/tcm/ztab1.htm
 Please link to me and trade links with me!

 Open Source Sci-Fi mmoRPG Game project.
 http://sf-journey-creations.wikispot.org/Front_Page
 http://code.google.com/p/perspectiveproject/
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Fwd: Preparing Blender for GateKeeper

[trouble daemon]

tbh, this sounds like its just chroot + signed applications + apple
reviewed repository (albeit, with a fancy front end!). If so, I don't
see it being that big of a deal. It's pretty much similar to what you
would get from a debian or ubuntu repo, just in a slightly different
and prettier presentation :)

On Fri, Mar 30, 2012 at 6:39 AM, johannes amorosa
johannes.amor...@googlemail.com wrote:
 trollpost
 Is this a next step to kill the personal computer and turning all OSes into
 a shopping channel?
 I'll bet in not too long time, no software will run if you don't use
 gatekeeper.
 /trollpost

 On 30 March 2012 12:19, Ton Roosendaal t...@blender.org wrote:

 HI all,

 See below. I've asked Ernest to send me additional info, like if we can
 get free Developer Program membership, and what the Gatekeeper feature
 actually means for our distribution.

 I don't have time to go over all docs he links below... anyone can give me
 advice on this?

 Thanks,

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

 Begin forwarded message:

  Hello,
 
  This is Ernest Prabhakar from Apple.  I would like to connect with
 whomever on the Blender team produces the Mac download.
 
  As you may know, we have recently announced a new security feature for
 OS X called GateKeeper:
 
        • http://www.apple.com/macosx/mountain-lion/security.html
        •
 http://www.razorianfly.com/2012/02/27/apple-introducing-developer-id/
 
  We would like to make sure your software continues to work well for our
 customers who choose to use GateKeeper.
 
  Is someone on your team already part of the Mac Developer Program?
 
  https://developer.apple.com/programs/mac/
  https://developer.apple.com/support/mac/enrollment.html
 
  Once you're in the program, you can get detailed documentation on
 preparing your app for GateKeeper:
 
  https://developer.apple.com/devcenter/mac/checklist/mountain-lion/
  • Use your Developer ID for Gatekeeper.
  Gatekeeper is a major security feature in Mountain Lion that gives you
 control over which apps can be downloaded and installed on your Mac. Sign
 your OS X Mountain Lion apps with your Developer ID and give users the
 confidence that you are a developer identified with Apple.
 
  Developer ID Tutorial
 
 http://adcdownload.apple.com//Documents/developer_id_tutorial/gettingstartedwithdeveloperid_03.06.pdf
 
  Code Signing Guide
 
 https://developer.apple.com/library/prerelease/mac/#documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005929
 
  App Sandboxing (not required, but strongly encouraged)
  https://developer.apple.com/devcenter/mac/app-sandbox/
 
  Please let me know if there's anything you need that isn't covered in
 those documents.
 
  Also, can you let me know when you're likely to be able to add Developer
 ID support to your Mac download?
 
  Many thanks.
 
  Sincerely,
  Ernie Prabhakar
  Open Source Product Manager
  Apple, Inc.
  +1 (408) 974-3075 US PDT (GMT-7)

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




 --
 ++
 johannes amorosa
 twitter: jamorosa
 http://iamnotamus.de
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Preparing Blender for GateKeeper

[trouble daemon]

On Fri, Mar 30, 2012 at 1:53 PM, Knapp magick.c...@gmail.com wrote:
 I hope GateKeeper is as far as
 they go, that it's not just the first step away from freedom.

 Mike Erwin

 Why do names like GateKeeper make me feel like I am living in some bad
 SF book with a bad ending?

Are you the keymaster? :)

 On the real side, security is very important. I am getting sick of all
 this mafia, china, cia etc type stuff trying to break into our
 computers.

I think we all are!

 Can we find someone that has already paid and let them sign it?

If a developer is going to put their name and reputation on the line
by signing the file, I would assume that they would also be the one to
compile the binaries. I can only imagine how much egg on faces would
go around and hit news sites in the situation where some random
developer with a poorly maintained and virus infected machine started
getting his binaries signed by some other developer and uploaded to
apple servers, giving users a false sense of security and possibly
bring legal action towards the poor guy who was asked to blindly sign
some file.

I guess what I am trying to say is that I would love to see a nice
secure approach to software in general, but if you are going to take
security seriously and get into certificates and digital signatures
etc., then it should be done right from the start by getting someone
well trusted to do the signing, and only on a fresh (format + install
+ updates) and secured (not connected to internet 24/7, restrictive
firewall, strong passwords, etc.) install of the OS of the target
platform. Otherwise the signing is about as (in)effective as a self
signed cert, created and used on a machine that you use for general
internet usage and letting random house guests browse the internet
with. :)

So, if you are going to do it, be sure to do it right! (tm) :)

troubled
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] [Patch] Adding new node anchored to pre-menu mouse position

[trouble daemon]

Hey o/

lukas_t and I were discussing on irc about the annoyance of adding new
nodes in the node editor that causes it to use the location of the
mouse at the point where the operator is called that can result in the
new node being placed off the screen, and brainstormed some possible
interim solutions.

He was kind enough to code up a quick patch that will instead use the
position of the mouse at its pre-menu location, instead of when you
actually click the item. The result is that it will add the node
centered to that location. Then you just need to train yourself to put
the mouse where you want the middle of the node to be, saving you from
having to zoom out to move a node that is off-screen, back into
position.

We debated on anchoring centered vs top left etc, but this patch does
centered, yet still seems okay. We were wondering though, what others
might think of a patch like this being put into trunk for release? He
had some ideas for dragdrop, but that might be something for after
release. Also worth noting is that it currently doesn't add the node
in an ideal location if you use the header menu to add the node, but
we figure this is better than what we have now, and a more typical
method used for adding nodes. ie: better than now :)

Anyways, just curious what others think, and if they had any ideas on
the issue/patch, in hopes of getting this issue at least partially
addressed for the next release. You can find the patch here:

http://www.pasteall.org/30303
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bf-committers Digest, Vol 92, Issue 13

[trouble daemon]

My apologies! My original post got bounced since I inlined the patch.
The reply you got here was only about 1/4 of my post. I will repaste
to clarify some of my points I was trying to make.

Original email:

-
I was messing around with imperial units in blender and found it to be
a pita. I dug around a bit and thought I would offer some ideas.

The patch below, while incomplete (didn't bother to fill the area
structs for the new 1/2, 1/4 etc units for eg.) and proper
english/spelling, seems to be somewhat of a step in the right
direction. Specifically, I think that yards should either always be
hidden, or checkboxes should maybe be added to allow the user to
enable and disable the units he would like to see.  I even thought a
new button on the panel specifically called Architectural that
specifically turns off yards and enabled fractions, would be a good
way to go.

To give you an idea, when I want to work on a blueprint to model
something and create an object 9' long, I don't want to see 3yd, I
want to see 9' :) I also messed with the idea of using 1/2, 1/4, 1/8,
1/16 and 1/32 units and seems to display fine, but needs some more
thought in the area of dealing with the fact that the input box also
allows math in it, so the position of the -1/2 has to be very precise
it seems. Also, I was unable to figure out how to tell blender to not
use fractions in front of the unit type. eg: it shows 1.5-1/2 instead
of 1-1/4.

I think that the most important problem though is that you can't enter
in actual inches or feet etc, when doing transforms. Blender seems to
limit me to only metric like numbers. Just allowing imperial units in
any translations would be very useful (along with disabling yard
displaying perhaps).

Anyways, if any of you coders out there feel bored, please take a
look. I think this is one area where blender is needs a few lines of
TLC :D  Take care o/

http://www.pasteall.org/30003
-

PS - I will reply to the responses in a second post to avoid another
bounced email! Sorry! :)


troubled
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bf-committers Digest, Vol 92, Issue 13

[trouble daemon]

Ok, now for the actual replies! :)


 Sorry if I'm missing something, but switching the units to Imperial in the
 scene panel seems to do exactly what you ask.
 I don't use imperial units, but just tried if it works and I could easily
 scale the default cube to precise values entering yd, ft or in after
 the numeric value and it worked (of course, after switching to imperial in
 the units section of the scene panel)

The main issue I had when trying to work with a blueprint, is that I
didn't like seeing yards at all, and entering yd only works when you
enter it in the panel in say, the dimensions section, of the
properties panel. But when you are trying to do something in edit mode
like move this vertex 1-1/2inches to the left (x axis), then you are
only about to enter in metric or integer only values like 1.5.

Also, you can see now that I reposted the bounced email, that I was
considering another button specifically for architectural type work,
where something like yards is disabled by default, but is otherwise
mostly just imperial with display of fractions enabled as well.


And from Campbell:
 Regarding http://www.pasteall.org/30003

 Rather then adding half-inch, thirtysecond-inch... etc, think it
 would be better to add a flag to inch that it can display as
 fractions.

Agree, but I just needed to fill something in for the time being :) I
think this also covers the fact that sometimes, blender will show
like:

1.5-1/2 instead of 1-1/4, so something needs to be done in the
parser to tell blender to reduce those fractions down better. I just
don't know how myself.

 This is some more work but avoids adding cruft.

 The other thing that is tricky is how to correctly parse this back as
 input, since the buttons can take arithmetic as input, mixed with
 dimensions...
 -1/4\

 would currently translate to...
 -1/4*0.0254

 Its possible that imperial unit display cant be easily parsed (or it
 might have to have a custom parser written)
 this may be harder to solve if we are to keep
 button-display-as-button-input working.

I definetly like the idea of being able to toggle the units, but I
don't know the py menu stuff well enough to even consider adding such
checkboxes, sorry.

As for the aritmetic, I realize it is a problem, but it seems that the
parser works to some degree when it sees something like 1-1/2, for
example. I also noticed in the code that it accepts commas as well, so
perhaps thats a better way. Although, if the artimetic parser could be
changed to only do actual math when there is a space, I think it would
work fine too.

From: Knapp magick.c...@gmail.com
 I know that people used to imperial units have a hard time with metric
 but I really think that people need to change to metric and forcing
 Blender to work with all these strange units is a big waste of time.
 BTW I come from the USA. Being able to enter units in imperial units
 is nice but why not just let the readout be in normal units. I mean
 1/4 and inch is ok but so is .25 and in a lot of ways it is way easier
 to think in the second way. As an American I think having units like 2
 feet 6.25 inches is just fine.

Sure, being able to enter .25 should auto translate to 1/4, but when
you do something like enter blueprints or floor plans or something, it
is nice to see units displayed as you entered them or as they appear
on your plans, rather than some metric units or fractions. Otherwise,
you have to keep doing mental math as you compare your work on screen
to the plans for the sake of double checking your work.


Anyways, sorry for the long post and repost, and thanks for the replies!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Imperial units in architectural context

[trouble daemon]

Sorry, last email got bounced and/or cut off. I pasted patch to
pastbin instead and included the missed part just in case:

...
 I think that the most important problem though is that you can't enter
   in actual inches or feet etc, when doing transforms. Blender seems to
   limit me to only metric like numbers. Just allowing imperial units in
   any translations would be very useful (along with disabling yard
   displaying perhaps).

   Anyways, if any of you coders out there feel bored, please take a
   look. I think this is one area where blender is needs a few lines of
   TLC :D  Take care o/

http://www.pasteall.org/30003
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bf-committers Digest, Vol 92, Issue 11

[trouble daemon]

 - Mesh bevel still needs work. The singular bevel case works (1 new face on 
 edges) but for a smooth bevel (higher subdivision, rounded bevel) we need 
 good code still. *Help wanted!*

Speaking of bevels, I was noticing the other day that a bevel modifier
on an object I made in an svn build that had a UV unwrap applied,
didn't open up properly on the last release build. The unwrap was
offset/incorrect. Even if I just re-unwrapped the face only, it kept
the incorrect offset. Disabling the modifier fixed it.

I don't know if it still happens or if it was fixed, but thought you
might be interested in knowing of a case where svn build files don't
open properly in a release build, and avoiding another bug report from
me ;)


troubled
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] cycles fails to compile with jemalloc

[trouble daemon]

Hey Brecht,

Loving cycles btw :)

I just was noticing the other day that I hadn't yet tried out jemalloc
in the cmake settings. So I grabbed the latest git copy and installed
it. The problem was that blender seemed to fail to compile.

I don't have the compile error handy, but I recall it stopping on
something cycles related, and went away when I disabled jemalloc.

Anyways, just thought you might want a heads up in case you intended
to support this malloc replacement, or at least allow cycles to work
in concert with it.


Cheers,

Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bf-committers Digest, Vol 85, Issue 18

[trouble daemon]

 On Thu, Aug 18, 2011 at 3:22 AM, Nathan Vegdahl ces...@cessen.com wrote:
 What defines a new feature? How big must the impact be
 for it? I mean it's senseless to write a small feature which
 only affects a few lines in some areas to be developed in
 a branch.

 When branches are expensive, yeah, that's true. ?Perhaps that's a good
 argument for switching to a DVCS: it makes it a lot easier to manage
 this kind of a workflow, since anyone can publish their own branch.

 +1; this would be unworkable without DVCS.

My advice would be for more of the dev's to switch now to something
like git with svn support and get used to it. Just use git svn
dcommit's now to your current branch, nobody would even know! If every
dev out there was already using git, switching would probably be easy
as you would already all be used to the new system.

As for which DVCS to use, I think I am biased towards git. Mercurial
is fine too I suppose, although the way you clone to branch is a
little weird in comparison. I personally like how git keeps everything
in one nice little package though.

I am curious as to how something like git and hg are on OS's other
than Linux, as well as support in your favorite IDE's. Although I
would guess that most allow for custom tool commands these days, or
heaven forbid, you manually run shell commands :)

Anyways, just my two cents. I say take a chance! :)


Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers