[Bf-committers] Testing bf-committers, please ignore

[Dan McGrath via Bf-committers]

Just a quick test after a report of this list not existing. Please ignore!

-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] move prebuilt libs from svn to git?

[Dan McGrath via Bf-committers]

Just a heads-up that Ray and I took a packet capture on both ends for me.

Thanks to his capture, I noticed that the SVN server host was not sending
TCP window scale or SACK options. Ultimately this turned out to be due to
that host using the PF firewall "synproxy" state option, which apparently
was causing the TCP header options to be removed, which limited the window
size to 64k.

I have corrected this change to match the www host, and we did observe some
improvements that were hidden from me before due to my and the studio IPs
special treatment that bypassed this feature.

While it should help, I also tuned a few sysctl settings for send and
receive buffers. In addition, I noticed that the SVN server is also not
sending gzip/deflate accept headers for the files. No doubt this is going
to be a factor. However, there was a note from 2016 from myself explaining
that Brecht asked for the SVN compression to be disabled due to some client
problems. So, this will require some research, perhaps next week.

Anyway, hopefully it helps a bit until I can review some more settings.

Enjoy your weekend everyone!


Dan

On Fri, Jun 17, 2022, 2:22 PM Ray Molenkamp via Bf-committers <
bf-committers@blender.org> wrote:

> =8<==[Editors note]=8<==
> I'll be honest I'm 100% convinced mailinator will ruin
> the little formatting I have done, I put a copy of this
> email on https://developer.blender.org/P3014.
> =8<8<8<8<==
>
> How much as I like the sentiment of "lets move to git will it
> solve all these problems" lets be honest here, git.blender.org's
> speed is nothing to write home about either it may or may not be
> as glitchy as svn, but it still wouldn't be fast.
>
> from my 300mbit connection in western Canada
>
> Receiving objects:   6% (135931/2078159), 33.34 MiB | 458.00 KiB/s
>
> total time for a clone off git.blender.org 27m39s
>
> Cloning off https://github.com/blender/blender.git however
>
> total time for a clone off github.com 1m 52s
>
> Now amount of finger pointing to client settings will convince me
> it's a client setting at this point, but I'll be honest, I am all
> the way in western Canada and that could definitely be a factor.
>
> so, lets investigate!
>
> Let’s spin up an AWS EC2 instance in London, I'd say that be close
> enough to Amsterdam, and let’s rule out any other CPU or Bandwidth
> related factors as well, I threw a few dollars at it and got a
> cn5.18xlarge instance (72 CPU’s 192gb memory, 100gbit ethernet)
> overkill to do a git/svn test? yes.. yes indeed
>
> first to rule out the blender.org servers lets grab a ubuntu iso
> off an .nl mirror (
> https://mirror.nl.datapacket.com/ubuntu-releases/22.04/ )
>
> 2022-06-17 17:13:21 (232 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved
> [3654957056/3654957056]
>
> all right bandwidth is NOT going to be an issue on this box!
>
> On to blender stuff:
>
> cloning from git.blender.org  2m32.895s
> svn checkout of lib/win64_vc15 2m56.388s (iftop said 65Mbit peak rate)
>
> yowza!
>
> All right, so in London, safe to say all is well
>
> lets move closer to my location, us-east-2 Ohio (same instance type and os)
>
> grabbing ubuntu from that same mirror
>
> 2022-06-17 17:31:00 (29.5 MB/s) - ‘ubuntu-22.04-desktop-amd64.iso’ saved
> [3654957056/3654957056]
>
> all right, that has lost quite a bit of steam, but it's
> still nothing to sneeze at, just to be sure lets grab
> an iso off the Princeton university mirror 120MB/s ok..
> good enough...
>
> onto cloning blender
>
> Receiving objects:   5% (104235/2078173), 25.44 MiB | 692.00 KiB/s
>
> well... that's not looking promising... lets wait it out
>
> cloning from git.blender.org  17m23.449s
>
> sadface... lets try svn next, i lost patience and did not let
> it finish.. iftop reported a top RX of 5.59Mbit though..
>
> To summarize:
>
> Ubuntu iso from mirror.nl.datapacket.com (Speed taken from wget)
> My home - western Canada - 1.3  MB/s
> AWS - London - 232  MB/S
> AWS - Ohio   - 29.5 MB/s
>
> Clone of git.blender.org (time taken from linux time command)
> My home - western Canada - 27m39
> AWS - London -  2m32
> AWS - Ohio   - 17m23
>
> SVN Clone: (peak RX bitrate taken from iftop)
> My home - western Canada -  1.5 Mbit/s
> AWS - London -   64 Mbit/s
> AWS - Ohio   - 5.59 Mbit/s
>
> Think the only thing we really can conclude is
> that being further from the server is leading
> to an "unhappy" time for the developer. Given
> the fact the EC2 instances were 100% identical
> between London and Ohio, it's unlikely to be a
> client configuration issue.
>
> --Ray
>
>

Re: [Bf-committers] move prebuilt libs from svn to git?

[Dan McGrath via Bf-committers]

Hi,

Really, I would need to see a capture from both sides to dig into it. I
need to see what is being sent, and what is received on each side. There
could be some weird firewall stuff happening that is causing fragmentation
or blocking TCP options, or window scaling issues, etc.

As for the default settings for tortoisesvn, the connection stuff I was
referring to was about TCP/IP behaviour, rather than an application
setting. Either way, I need to see what is actually happening. The fact
that I can pull 5-8MB/sec (~40mbit) from Canada and not have a single
interruption is telling. Granted, the host only has around 100 or 200mbit
allocated, iirc. Multiply that by a few dozen people and you have a problem.

For a simpler test, maybe try a large svn check, perhaps some old FreeBSD
ports svn repo if you can find one, something also in .NL, and see how it
goes, just to help eliminate your PC/firewall. Worst case scenario, you can
also poke me in chat and we can try some server side and client side
captures.

TBH though, 1gig uplink just isn't a whole lot to serve our user base ;)

On Fri, Jun 17, 2022 at 11:45 AM Tom M  wrote:

> On Fri, Jun 17, 2022 at 5:20 AM Dan McGrath 
> wrote:
> >
> > Hi Tom,
> >
> > Long time no see :)
> >
> > I did some tests from home and found that, aside from slow speeds, I was
> able to checkout at least 5 or 6 gig of the bf-blender repo without error
> or having to retransmit.
>
> Yeah, looks like I was mistaking really slow download of the larger
> (.7 GB) libraries as freezing.  I was averaging about .3 MB/s.  I used
> a different SVN client and saw that it was indeed downloading (the
> sliksvn doesn't provide any feedback on files in progress, only once a
> file completes) - It was taking about 40 minutes for each of the
> larger files.  It did complete eventually after about 5 hours.
>
> > I took the liberty of packet capturing the stream from my PC's POV, and
> placed them in the ftp download area[1], if you care to take a look.
> >
> > The gist is that I was able to get around 5MB/sec for at least 5G of the
> checkout, before I cancelled it.
> >
> Interesting, I usually get up to 3 MB/s download here normally from
> other sources, but was typically getting .3 MB/s, with occasional
> bursts of higher speed to a max of .8 MB/s when it wasn't downloading
> the large files.
>
> > Now, my IP is a bit of a special case, so I am wondering if you are just
> hitting the server so hard with http requests in separate sockets, or
> something extreme, that is causing the system to block you for a period of
> time. For comparison, my PC only had about 4 sockets open to the server for
> the transfer. I would be curious to know if you are doing pipelining, or
> sending each request in a separate connection.
> >
> Whatever the sliksvn and tortoisesvn defaults are, I'd assume they are
> setup for typical usage.
>
> > If you can, the next time it happens, see if you are unable to visit
> Phabricator or resume the svn checkout process. It may not be a firewall
> issue, but without seeing some packet captures, I wouldn't be able to
> really guess. Ideally, try to capture a few packets, until failure. At the
> very least, you will need to snap 20b+20b=40b for IP+TCP headers, but I
> would suggest a tad higher, maybe 64b.
> >
> > Cheers,
> >
> > Dan
> >
> > [1] - https://download.blender.org/ftp/dan/svn-checkout/
> >
> >
> >
> > On Thu, Jun 16, 2022 at 2:43 PM Tom M via Bf-committers <
> bf-committers@blender.org> wrote:
> >>
> >> When checking out the libraries from SVN following the directions on
> >>
> >> https://wiki.blender.org/wiki/Building_Blender/Windows
> >>
> >> The svn checkout of the libraries fails with significant frequency,
> >>
> >> if you google you might stumble across using make svnfix
> >>
> >> https://www.mail-archive.com/bf-blender-cvs@blender.org/msg151996.html
> >>
> >> Even after using it, I'm still having to do Ctrl C, and then make
> >> svnfix repeatedly (it downloads some files, than randomly freezes,
> >> sometimes after 20-50 files, sometimes after 100's of files).
> >>
> >> Git doesn't seem to have any problems, though.
> >>
> >> So might we consider migrating the libs to git, rather than using SVN?
> >>
> >> LetterRip
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> List details, subscription details or unsubscribe:
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
> >
> > --
> > Ch

Re: [Bf-committers] move prebuilt libs from svn to git?

[Dan McGrath via Bf-committers]

Hi Tom,

Long time no see :)

I did some tests from home and found that, aside from slow speeds, I was
able to checkout at least 5 or 6 gig of the bf-blender repo without error
or having to retransmit.

I took the liberty of packet capturing the stream from my PC's POV, and
placed them in the ftp download area[1], if you care to take a look.

The gist is that I was able to get around 5MB/sec for at least 5G of the
checkout, before I cancelled it.

Now, my IP is a bit of a special case, so I am wondering if you are just
hitting the server so hard with http requests in separate sockets, or
something extreme, that is causing the system to block you for a period of
time. For comparison, my PC only had about 4 sockets open to the server for
the transfer. I would be curious to know if you are doing pipelining, or
sending each request in a separate connection.

If you can, the next time it happens, see if you are unable to visit
Phabricator or resume the svn checkout process. It may not be a firewall
issue, but without seeing some packet captures, I wouldn't be able to
really guess. Ideally, try to capture a few packets, until failure. At the
very least, you will need to snap 20b+20b=40b for IP+TCP headers, but I
would suggest a tad higher, maybe 64b.

Cheers,

Dan

[1] - https://download.blender.org/ftp/dan/svn-checkout/



On Thu, Jun 16, 2022 at 2:43 PM Tom M via Bf-committers <
bf-committers@blender.org> wrote:

> When checking out the libraries from SVN following the directions on
>
> https://wiki.blender.org/wiki/Building_Blender/Windows
>
> The svn checkout of the libraries fails with significant frequency,
>
> if you google you might stumble across using make svnfix
>
> https://www.mail-archive.com/bf-blender-cvs@blender.org/msg151996.html
>
> Even after using it, I'm still having to do Ctrl C, and then make
> svnfix repeatedly (it downloads some files, than randomly freezes,
> sometimes after 20-50 files, sometimes after 100's of files).
>
> Git doesn't seem to have any problems, though.
>
> So might we consider migrating the libs to git, rather than using SVN?
>
> LetterRip
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Handling of user data.

[Dan McGrath via Bf-committers]

Hi,



On Tue, May 17, 2022 at 8:27 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:

> Dan, That's an interesting suggestion about warning users ahead of time,
> but it isn't the fake users that will get discarded, it's those that
> aren't marked with fake user (and don't have any real users).  What you
> say would probably work for the first time you unlink a data-block though
> :)
>

Ah yes, sorry. I meant the unlinked stuff, not fake users. You know what I
mean ;)


> I too agree that some simple indications would be much better than
> rewriting the garbage collection system and I think that even just
> warning the users and providing a link to documentation would be a huge
> help; I don't think you would even need to include a Manage Data button
> in the first iteration to see a large increase in usability.
>

I suppose the question really comes down to what the exact problem is: the
user being forgetful, or not aware of impending loss of data upon reload.

Dialogs would certainly help in the former case, but in the latter case, I
think a safety net might be more beneficial. As an example, you could have
some form of one time, dismissible dialog that goes into the preferences,
but I'm not sure the concept of updating preferences constantly with
booleans on which tooltips are dismissed would be ideal. Power users would
no doubt be annoyed.

I honestly wasn't going to waste any more of the thread's time on this, but
a thought did cross my mind that I figured I would toss it out there for
the guru's to consider, taken (conceptually) from about every OS out there:
the recycle bin.

The Idea being to put all of the unlinked stuff into some trash can of
sorts, GUI representation I leave to your imagination, that will collect
and save all unlinked objects in it, perhaps even sorted or grouped by
type. From there, you could maybe implicitly save it by default with the
blend file, based on a default preference so that power users could easily
turn it off. Then you just need a button or action to "empty" the trash
can. It would even have the secondary benefit of not requiring a full file
reload to remove the unlinked options (is this already a command yet?),
which I'm sure power users would love.

Anyway, just some thoughts. Take care o/
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Handling of user data.

[Dan McGrath via Bf-committers]

Hi,

Perhaps you could add a count of things to be tossed out during quit in the
save dialog, such as "If you quit, you will lose XXX number of fake user
objects!".

Or maybe, similar to how you warn about unsafe python scripts during start,
you could give users a one time "WARNING! Fake users will be lost on quit
or crash!" when they create the first fake user object.

Neither are great for forgetful users, but it sounds like some indications
could go a long way here, compared to rewriting the garbage collection
system.

On Mon, May 16, 2022 at 4:59 PM Zack Brown via Bf-committers <
bf-committers@blender.org> wrote:

> Hi again,
>
> I feel like I have a better understanding of the debate now. On the one
> hand, we want to protect user data; and on the other hand, we have a
> garbage collector that eliminates data that the user in theory doesn't care
> about. And in the grey zone, we have data that the user *does* care about,
> but that gets garbage collected anyway. And the problem is, how to prevent
> the user from losing data they want to keep, while avoiding keeping data
> the user doesn't want to keep.
>
> It seems like one primary suggestion is to simply throw out the garbage
> collector -- no more garbage collector, no more problem. If the user
> doesn't want a piece of data in their file, they would delete it by hand.
> The counter-argument being that the garbage collector is actually really
> great and helps us keep our blend files clean and useful.
>
> Another primary suggestion seems to be issuing a warning if the user tries
> to quit blender with data that will be garbage collected. The counter
> argument being that it would be complicated and bizarre to present the user
> with a potentially dizzying array of data and options for that data before
> they could quit the software.
>
> It's a fascinating problem, in a piece of software that seems to specialize
> in presenting the most unbelievably brilliant solutions for apparently
> unsolvable problems, like how to render 3D images in glorious detail in
> real time. Obviously impossible. Yet there it is!
>
> Here's a suggestion from a  non-expert who knows nuttin about nuttin: Don't
> kill the garbage collector, and don't warn on exit. Instead, why not give
> all orphaned data their own prominent collection in the outliner? Maybe
> something called "Garbage Data". With a nice set of tooltips that appear
> when the user hovers over the various relevant bits. Things that say
> something like "Data in this collection has no user and will be deleted
> when you exit blender. To prevent deletion, follow the instructions at
> http://usefuldocs.blender.org/garbage_data.php to give the data a 'fake
> user'."
>
> But I'm sure you guys will figure out something 100x better than that idea.
> Can't wait to see it!
>
> Be well,
> Zack
>
>
>
>
>
> On Mon, May 16, 2022 at 6:40 PM Jacob Merrill via Bf-committers <
> bf-committers@blender.org> wrote:
>
> > What about popping up the outliner / orphan data window in quit, and
> > showing exclamation icon somewhere if there is a orphan
> >
> > On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers <
> > bf-committers@blender.org> wrote:
> >
> > > I’d love to have someone flesh out this “warning on quit” idea,
> because I
> > > can’t imagine it actually
> > > working in practice.  Mostly because of confusion on what “saving”
> really
> > > means. Users should
> > > rightfully only consider that “saving their data” does exactly that,
> not
> > > that some of their data might
> > > differ and have to be “saved” in different ways.
> > >
> > > As its simplest, imagine that you have no unsaved changes in your file
> > (you
> > > just did a File/Save)
> > > yet there is orphaned data at the time you select “Quit”.  What exactly
> > > does the warning say?
> > > “You have unlinked data that will be lost”?  How do you communicate to
> > the
> > > user what they should
> > > do now?  Is there a way to offer to do it for them somehow, or is this
> > > warning going to just have an
> > > “Ignore” and “Cancel” button? Text that says “please mark anything you
> > want
> > > to keep by marking
> > > the data with ‘fake user’”? That will not help a typical person being
> > > caught out by this
> > >
> > > Now imagine there are both unsaved changes and orphan data at the point
> > of
> > > “quit”.  We now
> > > have to warn about unsaved changes that can be “saved” and there are
> > other
> > > things that should
> > > be “saved” in a different way before you “save” so that they are
> actually
> > > “saved”. So we have a
> > > button to cancel, one to save the unsaved changes while ignoring orphan
> > > data, and what else
> > > is on the dialog?
> > >
> > > I'm not sure there is sufficient lipstick that can be put on this pig.
> > >
> > > Harley
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > List details, subscription details or unsubscribe:
> > > 

Re: [Bf-committers] Blender 2.93 Released!

[Dan McGrath via Bf-committers]

Also, maybe of interest: SLSA

https://thehackernews.com/2021/06/google-releases-new-framework-to.html

On Thu, Jun 17, 2021, 11:57 PM Dan McGrath  wrote:

> Hi,
>
> Just a thought, assuming only non commercial add-ons, but is there any use
> in pushing such a add-on system into the python pip repos?
>
> As long as you own the namespace, like blender-*, for example, you would
> at least be able to offload the hosting burden to pip, as well as benefit
> from their battle hardened system.
>
> On Thu, Jun 17, 2021, 9:23 PM Brecht Van Lommel 
> wrote:
>
>> There are certainly challenges implementing such a system, though it's
>> been done many times in other applications. It's too early to go into such
>> details, it's not clear this will even happen or when.
>>
>> On Thu, Jun 17, 2021 at 10:14 PM Dan McGrath 
>> wrote:
>>
>>> Hi,
>>>
>>> For an official online repository that is integrated into Blender, users
>>>> would not notice much difference compared to bundled add-ons. I think it
>>>> would be valuable to have a way for more developers to share their
>>>> add-ons
>>>> in the same way.
>>>>
>>>
>>> Out of curiosity, where and how were you thinking of hosting this
>>> repository? I would suggest our Google workspace area, due to the ACL,
>>> accountability and immutability of their system, but I don't know that the
>>> team would prefer that over S3 or self hosting.
>>>
>>> If self hosted, what about the security of this? A compromise of a
>>> binary is trickier; the binary rarely changes, has well known checksums, is
>>> signed (on Win/Mac) and at least goes through mirrors and Microsoft which
>>> surely have excellent monitoring for unusual behaviour and known malware.
>>> If you start self-hosting auto-updating python code, files are directly
>>> uploaded into users' networks and devices. You bypass a lot of that built
>>> in security in our delivery pipeline in a way I don't know you can easily
>>> compensate for, not to mention all of the bandwidth costs which are already
>>> a challenge to our gigabit link.
>>>
>>> --
>>> Cheers,
>>> Danny
>>>
>>> --
>>> Danny McGrath - danmcgrath...@gmail.com
>>> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>>>
>>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.93 Released!

[Dan McGrath via Bf-committers]

Hi,

Just a thought, assuming only non commercial add-ons, but is there any use
in pushing such a add-on system into the python pip repos?

As long as you own the namespace, like blender-*, for example, you would at
least be able to offload the hosting burden to pip, as well as benefit from
their battle hardened system.

On Thu, Jun 17, 2021, 9:23 PM Brecht Van Lommel 
wrote:

> There are certainly challenges implementing such a system, though it's
> been done many times in other applications. It's too early to go into such
> details, it's not clear this will even happen or when.
>
> On Thu, Jun 17, 2021 at 10:14 PM Dan McGrath 
> wrote:
>
>> Hi,
>>
>> For an official online repository that is integrated into Blender, users
>>> would not notice much difference compared to bundled add-ons. I think it
>>> would be valuable to have a way for more developers to share their
>>> add-ons
>>> in the same way.
>>>
>>
>> Out of curiosity, where and how were you thinking of hosting this
>> repository? I would suggest our Google workspace area, due to the ACL,
>> accountability and immutability of their system, but I don't know that the
>> team would prefer that over S3 or self hosting.
>>
>> If self hosted, what about the security of this? A compromise of a binary
>> is trickier; the binary rarely changes, has well known checksums, is signed
>> (on Win/Mac) and at least goes through mirrors and Microsoft which surely
>> have excellent monitoring for unusual behaviour and known malware. If you
>> start self-hosting auto-updating python code, files are directly uploaded
>> into users' networks and devices. You bypass a lot of that built in
>> security in our delivery pipeline in a way I don't know you can easily
>> compensate for, not to mention all of the bandwidth costs which are already
>> a challenge to our gigabit link.
>>
>> --
>> Cheers,
>> Danny
>>
>> --
>> Danny McGrath - danmcgrath...@gmail.com
>> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.93 Released!

[Dan McGrath via Bf-committers]

Hi,

For an official online repository that is integrated into Blender, users
> would not notice much difference compared to bundled add-ons. I think it
> would be valuable to have a way for more developers to share their add-ons
> in the same way.
>

Out of curiosity, where and how were you thinking of hosting this
repository? I would suggest our Google workspace area, due to the ACL,
accountability and immutability of their system, but I don't know that the
team would prefer that over S3 or self hosting.

If self hosted, what about the security of this? A compromise of a binary
is trickier; the binary rarely changes, has well known checksums, is signed
(on Win/Mac) and at least goes through mirrors and Microsoft which surely
have excellent monitoring for unusual behaviour and known malware. If you
start self-hosting auto-updating python code, files are directly uploaded
into users' networks and devices. You bypass a lot of that built in
security in our delivery pipeline in a way I don't know you can easily
compensate for, not to mention all of the bandwidth costs which are already
a challenge to our gigabit link.

--
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Looking into mail problem (test)

[Dan McGrath via Bf-committers]

One last follow up:

I did notice that spamassassin was tossing some occasional errors, and have
restarted the service. It indeed could have been a cause for some, but not
all users, being problematic with delivery.

On Mon, Jun 14, 2021 at 3:44 PM Dan McGrath  wrote:

> So,
>
> Aaron and I did some quick tests, but for some reason it just started
> working again, even after he updated his settings back. I did resave the
> filter page for the list, which could have corrected something perhaps, but
> other than over the weekend when Ton and Francesco poked at the lists,
> nothing has changed in at least weeks since Aaron last mailed on June 4.
>
> TL;DR: Something could have accidentally broken over the last few days,
> but possibly worked itself out. Poke you have problems sending to the lists!
>
> Thank you!
>
> On Mon, Jun 14, 2021 at 3:25 PM Dan McGrath 
> wrote:
>
>> Hi,
>>
>> Indeed, the mailing list mime vs plain text appears to be at the root of
>> the problem.
>>
>> Will see if I can figure out exactly why! In the meantime, you may want
>> to update your settings to MIME instead of plain text.
>>
>> On Mon, Jun 14, 2021 at 3:23 PM Aaron Carlisle via Bf-committers <
>> bf-committers@blender.org> wrote:
>>
>>> Test using MIME
>>>
>>> On Mon, Jun 14, 2021 at 3:10 PM Dan McGrath via Bf-committers <
>>> bf-committers@blender.org> wrote:
>>>
>>> > Sorry for the noise, just checking into some potential mailing list
>>> > delivery problem from external users. So far it seems to be gmail
>>> > users, but not all the details are known yet.
>>> >
>>> > There may be a small handful of these, mind the noise!
>>> >
>>> > --
>>> > Cheers,
>>> > Danny
>>> >
>>> > --
>>> > Danny McGrath - danmcgrath...@gmail.com
>>> > GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>>> > ___
>>> > Bf-committers mailing list
>>> > Bf-committers@blender.org
>>> > List details, subscription details or unsubscribe:
>>> > https://lists.blender.org/mailman/listinfo/bf-committers
>>> >
>>>
>>>
>>> --
>>> Aaron Carlisle
>>>
>>> Project administrator for the Blender 3D Documentation Project
>>> Email: carlisle@gmail.com
>>> Website: https://blendify.github.io
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> List details, subscription details or unsubscribe:
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> --
>> Cheers,
>> Danny
>>
>> --
>> Danny McGrath - danmcgrath...@gmail.com
>> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>>
>
>
> --
> Cheers,
> Danny
>
> --
> Danny McGrath - danmcgrath...@gmail.com
> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>


-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Looking into mail problem (test)

[Dan McGrath via Bf-committers]

So,

Aaron and I did some quick tests, but for some reason it just started
working again, even after he updated his settings back. I did resave the
filter page for the list, which could have corrected something perhaps, but
other than over the weekend when Ton and Francesco poked at the lists,
nothing has changed in at least weeks since Aaron last mailed on June 4.

TL;DR: Something could have accidentally broken over the last few days, but
possibly worked itself out. Poke you have problems sending to the lists!

Thank you!

On Mon, Jun 14, 2021 at 3:25 PM Dan McGrath  wrote:

> Hi,
>
> Indeed, the mailing list mime vs plain text appears to be at the root of
> the problem.
>
> Will see if I can figure out exactly why! In the meantime, you may want to
> update your settings to MIME instead of plain text.
>
> On Mon, Jun 14, 2021 at 3:23 PM Aaron Carlisle via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> Test using MIME
>>
>> On Mon, Jun 14, 2021 at 3:10 PM Dan McGrath via Bf-committers <
>> bf-committers@blender.org> wrote:
>>
>> > Sorry for the noise, just checking into some potential mailing list
>> > delivery problem from external users. So far it seems to be gmail
>> > users, but not all the details are known yet.
>> >
>> > There may be a small handful of these, mind the noise!
>> >
>> > --
>> > Cheers,
>> > Danny
>> >
>> > --
>> > Danny McGrath - danmcgrath...@gmail.com
>> > GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > List details, subscription details or unsubscribe:
>> > https://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>> --
>> Aaron Carlisle
>>
>> Project administrator for the Blender 3D Documentation Project
>> Email: carlisle@gmail.com
>> Website: https://blendify.github.io
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> List details, subscription details or unsubscribe:
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
> --
> Cheers,
> Danny
>
> --
> Danny McGrath - danmcgrath...@gmail.com
> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>


-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Looking into mail problem (test)

[Dan McGrath via Bf-committers]

Hi,

Indeed, the mailing list mime vs plain text appears to be at the root of
the problem.

Will see if I can figure out exactly why! In the meantime, you may want to
update your settings to MIME instead of plain text.

On Mon, Jun 14, 2021 at 3:23 PM Aaron Carlisle via Bf-committers <
bf-committers@blender.org> wrote:

> Test using MIME
>
> On Mon, Jun 14, 2021 at 3:10 PM Dan McGrath via Bf-committers <
> bf-committers@blender.org> wrote:
>
> > Sorry for the noise, just checking into some potential mailing list
> > delivery problem from external users. So far it seems to be gmail
> > users, but not all the details are known yet.
> >
> > There may be a small handful of these, mind the noise!
> >
> > --
> > Cheers,
> > Danny
> >
> > --
> > Danny McGrath - danmcgrath...@gmail.com
> > GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > List details, subscription details or unsubscribe:
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
> --
> Aaron Carlisle
>
> Project administrator for the Blender 3D Documentation Project
> Email: carlisle@gmail.com
> Website: https://blendify.github.io
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Looking into mail problem (test)

[Dan McGrath via Bf-committers]

Sorry for the noise, just checking into some potential mailing list
delivery problem from external users. So far it seems to be gmail
users, but not all the details are known yet.

There may be a small handful of these, mind the noise!

-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Test mail, please disregard

[Dan McGrath via Bf-committers]

Hi,

Sorry for the spam, but there is a report of a user that they are not able
to send mail to the list. There may be several test messages from people,
if needed, so apologies for any inconvenience!

-- 
-- 
Cheers,
Dan

--
Danny McGrath - d...@blender.org
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] APCu installed in Phabricator for speed up

[Dan McGrath via Bf-committers]

Hi,

It would appear that all these years since the APC addon was deprecated and
replaced with pecl-APCu, which the phabricator was complaining about,
actually turned out to possibly be the root of some serious performance
problems (it was silenced a while back).

I added it to the system and can notice an improvement here. As always,
keep an eye out for anything bad, or if those page timeouts go away.
Hopefully it "just works (tm)"!

-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Server update and reboot affecting mail and store

[Dan McGrath via Bf-committers]

Hi,

Just a heads up that in the next  few minutes there will be a server outage
for some updates that will affect mail and the store.

The outage should take between 30 and 60 minutes, if all goes well.

Sorry for any inconvenience!

-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Mailman 3 thread on FreeBSD list

[Dan McGrath via Bf-committers]

Hi,

And of course, the url to the thread:

https://lists.freebsd.org/pipermail/freebsd-ports/2020-April/118351.html

Thanks to Aaron for pointing that out, but I was merely testing to see who
was paying attention! ☺️

On Tue, Apr 28, 2020, 8:01 PM Dan McGrath  wrote:

> Hi,
>
> Just cross posting an interesting thread on MM3 over on the FreeBSD lists,
> as it will be applicable to us before the end of the year when Python 2.7
> is forced out of ports, along with the broken mail hooks for our svn.
>
> --
> Cheers,
> Danny
>
> --
> Danny McGrath - danmcgrath...@gmail.com
> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Mailman 3 thread on FreeBSD list

[Dan McGrath via Bf-committers]

Hi,

Just cross posting an interesting thread on MM3 over on the FreeBSD lists,
as it will be applicable to us before the end of the year when Python 2.7
is forced out of ports, along with the broken mail hooks for our svn.

-- 
Cheers,
Danny

--
Danny McGrath - danmcgrath...@gmail.com
GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Wiki maintenance today

[Dan McGrath]

Hi,

It would appear that the upgrade went just fine, but please keep an eye out
for anything that appears broken.

One of the changes that I made was to move away from a git checkout of
the SyntaxHighlight_GeSHi extension, and switch to the now shipped one from
the port that we use for Mediawiki. This should hopefully simplify things a
bit on the back end, but keep an eye out for pages with missing color
highlighting. If needed, you can try purge the page yourself by appending
"?action=purge" to the URL, although I should really just purge the entire
cache locally ;)

I still would like to tune some of the Apache settings on the server, but
this shouldn't be anything that you should notice. We did appear to have
unusually heavy load, borderline abusive, yesterday on the www.blender.org
server, and then later that night the wiki was knocked into a 500, so there
may be something in need of a closer look (part of the reason for the
upgrade), but otherwise I guess you are safe to start editing the wiki
again!


Cheers,

Danny McGrath

On Tue, Mar 3, 2020 at 11:37 AM Dan McGrath  wrote:

> Hi,
>
> Just a heads up that I will be poking around in the wiki today, trying to
> clean up some of the extension locations, move them around, upgrade them,
> as well as upgrade the wiki itself.
>
> Expect there to be some outages which should show up in the form of
> "Maintenance" pages, but I will try keep things online as much as possible,
> if only in a read only fashion. It's probably a good idea to save your
> changes locally.
>
> I will post a reply here when all of the work is complete so that you can
> go on with your business.
>
>
> Cheers,
>
> Danny McGrath
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Wiki maintenance today

[Dan McGrath]

Hi,

Just a heads up that I will be poking around in the wiki today, trying to
clean up some of the extension locations, move them around, upgrade them,
as well as upgrade the wiki itself.

Expect there to be some outages which should show up in the form of
"Maintenance" pages, but I will try keep things online as much as possible,
if only in a read only fashion. It's probably a good idea to save your
changes locally.

I will post a reply here when all of the work is complete so that you can
go on with your business.


Cheers,

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

[Bf-committers] developer.blender.org maintenance

[Dan McGrath]

Hi,

Just a heads up that we are going to attempt an upgrade of the Phabricator
software to 2020Q1.

Hopefully it shouldn't be long, maybe 5 minutes, but depends on what we
need to do with mysql. Either way, go enjoy some fresh air and stop
submitting bugs :)


Cheers,

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

[Bf-committers] Upgrade to mail server on blender.org

[Dan McGrath]

Hi,

Just a heads up that I am going to be performing a quick upgrade to 2020Q1
for our primary mail server, which also hosts our mailing list.

The upgrade shouldn't be more than a few minutes of downtime, at which
point any sent mail from our services is likely to sit on the backup MX
server, and should eventually be flushed once the primary MX comes back
online.


Cheers,

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

[Bf-committers] Software upgrades to git/svn servers

[Dan McGrath]

Hi,

Just a heads up today that there will be some (hopefully) brief outages
today to git.blender.org and svn.blender.org while I upgrade them to the
latest quarterly FreeBSD ports branches.


Cheers,

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

Re: [Bf-committers] Rack denial of service

[Dan McGrath]

Our ISP responded and confirmed they blocked the attack and turned off all
access to our www IP:

Hi,
> A DDoS targetting 82.94.226.104 started at 15:30 Amsterdam time. We tried
> to contact you but there was no response. When my last colleague went home
> at 17:12 we set a discard on all traffic to 82.94.226.104. 21:30 (8 minutes
> ago) the DDoS stopped. I have just removed the discard route but will keep
> monitoring your traffic. If the DDoS continues I will again place a discard
> on the target IP on our edge routers.
> The DDoS was about 3-4Gbit in size, enough to fill your 1Gbit uplink.
>
> Regards,
> Team Colocation


It's not clear whom/how they tried to contact us, however, nor why they
were unable to block access from the particular IP (or even entire attacker
netblock) from talking to us, rather than turning off the entire Blender
IP, but it is certainly understandable that investigating such incidents
can be time consuming and error prone, and are generally not from a single
attacker.

But, another attack started, and they've yet again blocked the traffic to
our www IP, but otherwise we are semi-online. I have sent another email to
them to inquire about any more specifics they may have on the attack, as
some initial investigations suggest that the attacker wasn't hitting the
web server directly, or at least not with any particular requests that
stand out in the logs. Most likely it was something like a ping flood, or
similar, that targeted our IP address with traffic not destined for a
particular service like HTTP.

If the situation changes in any particularly important way, I will of
course mention it, but otherwise I hate to waste your time with boring
details. Just keep an eye on the site, and hope for the best! :)


Cheers,

Danny McGrath


On Thu, Jan 30, 2020 at 10:03 AM Dan McGrath 
wrote:

> Hi,
>
> It seems that at, or around 9:25am EST, one of our servers started to
> experience a large number of connections. Shortly after the rack appears to
> have at least its inbound bandwidth (gigabit) saturated to the point where
> almost nothing is making it to the servers, although outbound in some
> established connections does at least appear to be making it out here and
> there just fine.
>
> Not much we can do about it atm, other than wait it out. By the time you
> receive this email, odds are it was either lucky, or it worked itself out,
> and thus is acting as explanation after the fact.
>
>
> Cheers!
>
>
> Dan McGrath
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Rack denial of service

[Dan McGrath]

Hi,

It seems that at, or around 9:25am EST, one of our servers started to
experience a large number of connections. Shortly after the rack appears to
have at least its inbound bandwidth (gigabit) saturated to the point where
almost nothing is making it to the servers, although outbound in some
established connections does at least appear to be making it out here and
there just fine.

Not much we can do about it atm, other than wait it out. By the time you
receive this email, odds are it was either lucky, or it worked itself out,
and thus is acting as explanation after the fact.


Cheers!


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

[Bf-committers] Subversion client version bumped to 1.10.0

[Dan McGrath]

Hi,

We have bumped the minimum version requirements to access the bf-blender
SVN repo from client version 1.9.0 to 1.10.0 after performing an svnadmin
upgrade on the repository after reports of some slowdowns.

You can find more information here:

  https://subversion.apache.org/docs/release-notes/1.10.html


Cheers,

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

Re: [Bf-committers] Blender server upgrades

[Dan McGrath]

Hi,

It seems I found a few things of concern while digging relating to file
permissions in the file system:


https://download.blender.org/ftp/dan/admin/phab_permissions/Screenshot_2020-01-20_15-41-51.png

Apparently there are some root owned files and directories, one of which
was that object file, as well as it's directories. Likely the permissions
are blocking things, and should be reset to www:www.

That said, it's possible that some cron based tool in the system could also
be generating root owned files, but anything invoked from the webserver
would most certainly need to be owned by www. If root files are an issue,
we should be able to solve via a umask in the system.
That said, we may need to go through and just verify that there were no
repo corruptions from being unable to pack files, but I am not sure that is
a problem with these particular files in git.

A quick check on file timestamps suggests that the problem may have
actually started around January 9th, or earlier, which is before the
upgrades happened. Most likely the two had nothing to do with each other,
which is good to know:


https://download.blender.org/ftp/dan/admin/phab_permissions/Screenshot_2020-01-20_15-49-50.png

https://download.blender.org/ftp/dan/admin/phab_permissions/Screenshot_2020-01-20_16-06-54.png

Anyway, I will probably avoid touching this personally, pending approval of
Sergey and folks, but we at least know where the problem lies now.


Cheers,

Dan McGrath

On Mon, Jan 20, 2020 at 3:15 PM Dan McGrath  wrote:

> Hi,
>
> Just another heads up that today it was reported that there was still some
> delay on the time between when the commits happen, and when they get
> processed and finally sent out.
>
> It was said that the CVS mailing list mails that happen when the commit is
> received by git were happening, so it is most likely a delay in the
> polling, and/or processing of the commit itself from the repo.
>
> I can take a look into a few more things shortly here, but Sergey won't
> have a look until at least tomorrow. In the meantime, I have restarted the
> PHD scripts that process commits, but expect 10-20 minute delays in the
> time between your commits and the time that Phabricator sees them.
>
> Sorry for the inconvenience!
>
>
> Cheers,
>
> Dan McGrath
>
> On Sat, Jan 18, 2020 at 2:42 PM Dan McGrath 
> wrote:
>
>> Hi,
>>
>> We were looking into it on the blender chat, and nobody touched anything
>> then suddenly a few mails arrived. Checking the mail logs on the
>> Phabricator system shows they didn't even queue until 10 minutes after the
>> commit, so maybe something a little lagged in the system. At least know it
>> wasn't the mail system, just based on the logs.
>>
>> I can only guess that git or svn was under some traffic or phab was busy
>> on processing or something for 10 minutes? Anywho, seems fine now, but
>> maybe Sergey can dig deeper. PHD's were/are running fine afaict.
>>
>>
>> Cheers,
>>
>> Dan
>>
>> On Sat, Jan 18, 2020 at 2:12 PM Ray Molenkamp  wrote:
>>
>>> not sure what changed but phab is either no longer or real slow picking
>>> up on git commits
>>>
>>> --Ray
>>>
>>> On 2020-01-17 1:01 p.m., Dan McGrath wrote:
>>> > Hi,
>>> >
>>> > Just a heads up that I will be attempting to upgrade some of the
>>> FreeBSD
>>> > servers and packages tonight, so there will be reboots.
>>> >
>>> > So, go out, enjoy your Friday night, and get off the internet so I can
>>> poke
>>> > at things :) o/
>>> >
>>> >
>>> > Cheers,
>>> >
>>> > Dan McGrath
>>> > ___
>>> > 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
>>>
>>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender server upgrades

[Dan McGrath]

Hi,

Just another heads up that today it was reported that there was still some
delay on the time between when the commits happen, and when they get
processed and finally sent out.

It was said that the CVS mailing list mails that happen when the commit is
received by git were happening, so it is most likely a delay in the
polling, and/or processing of the commit itself from the repo.

I can take a look into a few more things shortly here, but Sergey won't
have a look until at least tomorrow. In the meantime, I have restarted the
PHD scripts that process commits, but expect 10-20 minute delays in the
time between your commits and the time that Phabricator sees them.

Sorry for the inconvenience!


Cheers,

Dan McGrath

On Sat, Jan 18, 2020 at 2:42 PM Dan McGrath  wrote:

> Hi,
>
> We were looking into it on the blender chat, and nobody touched anything
> then suddenly a few mails arrived. Checking the mail logs on the
> Phabricator system shows they didn't even queue until 10 minutes after the
> commit, so maybe something a little lagged in the system. At least know it
> wasn't the mail system, just based on the logs.
>
> I can only guess that git or svn was under some traffic or phab was busy
> on processing or something for 10 minutes? Anywho, seems fine now, but
> maybe Sergey can dig deeper. PHD's were/are running fine afaict.
>
>
> Cheers,
>
> Dan
>
> On Sat, Jan 18, 2020 at 2:12 PM Ray Molenkamp  wrote:
>
>> not sure what changed but phab is either no longer or real slow picking
>> up on git commits
>>
>> --Ray
>>
>> On 2020-01-17 1:01 p.m., Dan McGrath wrote:
>> > Hi,
>> >
>> > Just a heads up that I will be attempting to upgrade some of the FreeBSD
>> > servers and packages tonight, so there will be reboots.
>> >
>> > So, go out, enjoy your Friday night, and get off the internet so I can
>> poke
>> > at things :) o/
>> >
>> >
>> > Cheers,
>> >
>> > Dan McGrath
>> > ___
>> > 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
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender server upgrades

[Dan McGrath]

Hi,

We were looking into it on the blender chat, and nobody touched anything
then suddenly a few mails arrived. Checking the mail logs on the
Phabricator system shows they didn't even queue until 10 minutes after the
commit, so maybe something a little lagged in the system. At least know it
wasn't the mail system, just based on the logs.

I can only guess that git or svn was under some traffic or phab was busy on
processing or something for 10 minutes? Anywho, seems fine now, but maybe
Sergey can dig deeper. PHD's were/are running fine afaict.


Cheers,

Dan

On Sat, Jan 18, 2020 at 2:12 PM Ray Molenkamp  wrote:

> not sure what changed but phab is either no longer or real slow picking up
> on git commits
>
> --Ray
>
> On 2020-01-17 1:01 p.m., Dan McGrath wrote:
> > Hi,
> >
> > Just a heads up that I will be attempting to upgrade some of the FreeBSD
> > servers and packages tonight, so there will be reboots.
> >
> > So, go out, enjoy your Friday night, and get off the internet so I can
> poke
> > at things :) o/
> >
> >
> > Cheers,
> >
> > Dan McGrath
> > ___
> > 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blender server upgrades

[Dan McGrath]

Hi,

Just a heads up that I will be attempting to upgrade some of the FreeBSD
servers and packages tonight, so there will be reboots.

So, go out, enjoy your Friday night, and get off the internet so I can poke
at things :) o/


Cheers,

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

Re: [Bf-committers] Screenshots for release log 2.81

[Dan McGrath]

Hi Nathan,

I allowed mp4/mkv/webm extensions now, as well as enabled the EmbedVideo
extension in the wiki. Try again?


Dan

On Sun, Nov 17, 2019 at 6:02 AM Nathan Craddock 
wrote:

> > Please use video files (MP4/h.264 or WebM/VP9)
>
> That makes sense. I put together a short video for the Outliner that covers
> most of the changes but I could not upload it (in either format) to the
> wiki, it seems that the file formats are not supported. There also doesn't
> seem to be a method of embedding a YouTube video as far as I can tell. I
> recall the old wiki supported embedded videos, is there a way to do this,
> or should I just leave a link on the page?
>
> Nathan Craddock
>
> On Wed, Nov 13, 2019 at 2:25 AM Sybren A. Stüvel 
> wrote:
>
> > On 13-11-19 06:07, Nathan Craddock wrote:
> > > Most of the new features there would be best shown with a video or GIF
> > though.
> >
> > Please use video files (MP4/h.264 or WebM/VP9), GIF has a horrible
> > compression ratio for video (among other downsides).
> >
> >
> > --
> > dr. Sybren A. Stüvel
> >
> > Blender Software Developer
> >
> > https://blender.org/
> > https://cloud.blender.org/
> >
> > ___
> > 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows lib changes

[Dan McGrath]

Hi,

I believe Sergey was poking the NUC's here this week for some signing
stuff. Probably still offline.

Dan

On Sat, Nov 9, 2019 at 3:12 AM Ray Molenkamp  wrote:

> fixed make_update.py ! however the mac and windows buildbots seem to have
> gone awol so can't test.
>
> --Ray
>
> On 2019-11-08 4:26 p.m., Brecht Van Lommel wrote:
> > The buildbot can probably be fixed by updating the lib folder name in
> > build_files/utils/make_update.py.
> >
> > On Fri, Nov 8, 2019 at 5:16 PM Ray Molenkamp  wrote:
> >
> >> So... that broke the windows build bot, if anyone with access
> >> to the windows bot could check out the libs that be great!
> >>
> >>  --Ray
> >>
> >> On 2019-11-08 9:02 a.m., Ray Molenkamp wrote:
> >>> All,
> >>>
> >>> Since the beginning of time we have always used a
> >>> weird mix of using the static C runtime for some
> >>> parts of blender while using the dynamic runtime
> >>> for others.
> >>>
> >>> No-one exactly remembers how this came to be, but
> >>> what was clear that mixing runtimes is 'not great'
> >>> and that it eventually would cause issues, which
> >>> it recently did [1]
> >>>
> >>> Today I'm cleaning it up and switching blender
> >>> over to the dynamic runtime on windows.
> >>>
> >>> Now sadly this requires a whole new library set
> >>> so if you are building blender on windows you may
> >>> have some hiccups and unfortunately a large download.
> >>>
> >>> Ideally you'd run 'make update' *twice* and it will
> >>> sort it self out. (Once to get the updated make.bat
> >>> that knows about the new libs, and a second time to
> >>> actually grab them)
> >>>
> >>> However there are some side cases where people
> >>> did not follow our building guide and/or systems
> >>> where cmake just behaved oddly, so here is a list of
> >>> oddities you may run into and how to resolve them.
> >>>
> >>> 1) I get a build error along the lines of:
> >>>
> >>> Windows requires pre-compiled libs at:
> >> 'c:/blender-git/blender/../lib/win64_vc15'.
> >>> Please run make update in the blender source folder to obtain them.
> >>>
> >>> Solution:
> >>>
> >>> Do what it says, if "make update" does not work for you, see 2
> >>>
> >>> 2) I checked out the libraries my self, I don't have SVN
> >>> in my path and/or "make update" does not work for me.
> >>>
> >>> It happens, not everybody is following our building
> >>> instructions [2] for various reasons, and some environments
> >>> just don't seem to play nice with our scripts.
> >>>
> >>> Solution:
> >>>
> >>> You can check out the new set of libraries manually from
> >>>
> >>> https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15
> >>>
> >>> just make sure they and up in the next to the win64_vc14 folder
> >>> you currently have and it should work.
> >>>
> >>> 3) I have a linker error mentioning a RuntimeLibrary mismatch
> >>>
> >>> These generally come in the form of:
> >>>
> >>> 'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value
> >> 'MDd_DynamicRelease' in [somefile]
> >>> This seems to be coming from CMake not always picking
> >>> up on changes in the platform settings.
> >>>
> >>> Solution:
> >>>
> >>> Remove your build folder and start a fresh build
> >>>
> >>> 4) MSVC 2015
> >>>
> >>> MSVC2015 has been superseded by 2 newer versions both
> >>> available for free, 2015 support will be dialed back
> >>> to the same level as 32 bit support. We don't test it
> >>> nor supply libraries for it anymore, however if you
> >>> have your own set of libraries and have patches that
> >>> help with vs2015 specific issues you are always
> >>> welcome to submit those.
> >>>
> >>> Solution: Update to vs2017 or vs2019
> >>>
> >>> 5) I have a branch that has not merged this change yet.
> >>>
> >>> That's OK, the static vc14 libraries will be available
> >>> for some time. However no further updates will be done
> >>> to them.
> >>>
> >>> Special acknowledgments:
> >>>
> >>> Thanks to @Harleya and @deadpin on chat for helping test
> >>> so we could have an as smooth as possible transition to
> >>> the new libs.
> >>>
> >>> [1] https://developer.blender.org/D5387#122165
> >>> [2] https://wiki.blender.org/wiki/Building_Blender/Windows
> >>>
> >>> ___
> >>> 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
> >>
> > ___
> > 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
>
___
Bf-committers mailing list
Bf-committers@blender.org

Re: [Bf-committers] BF coordination meeting notes - 2019.08.12

[Dan McGrath]

Hi,

On Mon, Aug 12, 2019 at 8:00 AM Brecht Van Lommel 
wrote:

> The idea would be to have a flow like this for example. I think it
> would help to get better quality reports, or to help users find
> solutions themselves in some cases.
>
> https://docs.google.com/document/d/1gxuBv6aeZjKgzMQmGYdaERKbd7VnllSa9s_ejl2hMGo/edit#bookmark=id.83ndneimph3m


Regarding the "Buildbot" section from the above Google doc:

> It would be good if a serious bug is introduced, we have an easy way to
> pin the buildbot download page to an earlier version without that bug until
> it is fixed.


Actually, this could potentially be possible using ZFS snapshots. The
directory is already available to the jail itself, so it would be a matter
of just rsync'ing back over the current contents of the download directory
-- which is what the PHP script enumerates, IIRC -- with the contents of
one of the snapshots. This could be done by had, or programatically, as
needed. Of course, the downside to merely rsync'ing back over top of the
current files, is that the next build bot run will replace the files again,
but this could possibly be the easiest to implement a "temp fix" by just
sym linking the broken file(s) to their /.zfs/snapshots/ alternative,
submitting the patch in advance, and then letting the next buildbot run
replace it. Not exactly the best solution, when you don't have strict
control to prevent builds from rolling out, mind you.

I would suggest at least creating a dataset in ZFS for just those files,
and modifying the current site to use symbolic links to point to an
alternate location, for as long as is needed. This might require some
tweaks to the PHP file that we use now (to ensure it follows the sym link),
but I don't see why this couldn't work. It also has the benefit of not
requiring extra permissions to the jail itself, just a one time creation of
a new dataset.

There is also the possibility of allowing for the ZFS dataset to be
manipulated from within the jail itself, thus allowing a script to say,
create or delete snapshots on the download directory, but I would generally
recommend against this, at least with the current design that we have for
jail configuration.


Cheers,

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

Re: [Bf-committers] Blender 2.80 Release Candidate - master frozen

[Dan McGrath]

Hi,

Huh, well that worked out well:

https://twitter.com/TheHackersNews/status/1153694205358645249?s=09


Dan

On Fri, Jul 19, 2019, 11:58 AM Brecht Van Lommel, 
wrote:

> And to be even more clear, the public Blender ftp incoming/ folder is
> a place for people to exchange files. We don't link to it from
> blender.org for users to download files from.
>
> That said we should indeed disable it, there is no good reason to
> justify having it at all.
>
>
> On Fri, Jul 19, 2019 at 5:04 PM Brecht Van Lommel
>  wrote:
> >
> > To be clear, there is no virus in the Blender release folder. The
> > checksums for the release builds match what the was reported by those
> > who made the releases.
> >
> > What happened is that someone put something on the public Blender ftp
> > folder, but it never affected the actual release.
> >
> > On Fri, Jul 19, 2019 at 4:37 PM Dan McGrath 
> wrote:
> > >
> > > Hi,
> > >
> > > It would appear that a windows virus "info.zip:
> > > Win.Trojan.Coinminer-6622864-0 FOUND" was uploaded to another file in
> this
> > > directory at the same time that you uploaded the windows RC.
> > >
> > > I reported the issue in blender.chat, where some discussion was held
> by at
> > > least some of the devs, but I would like to bring the matter to your
> > > attention here, as well. With release around the corner, and our
> binaries
> > > being a valuable target, that clearly was timed to happen during this
> > > upload, I would advise that you at least verify the checksums of the
> file
> > > that you uploaded, and that we immediately stop using a world writable
> FTP
> > > for our release.
> > >
> > > My recommendation is to immediately disable and remove FTP from our
> server,
> > > and find alternative and secure means for the developers to share
> files.
> > > The idea of sftp/scp only accounts on download.blender.org would even
> be an
> > > improvement. In the long term, even this should be frowned upon
> though, as
> > > a compromise of our web server (which should be considered to be
> untrusted,
> > > and in a DMZ), would be a disaster on its own, but less so if we could
> at
> > > least verify the integrity of the files (Mac/Win at least can be
> signed).
> > >
> > > I would also strong advise that one of the developers create a GPG key
> that
> > > is stored safely ofline, which can be used to officially sign the
> MD5/SHA
> > > checksum files, and go through and retroactively sign and checksum our
> > > entire archive as a precaution. This would also allow our users to
> verify
> > > our downloads via mirror, as right now there is absolutely no way for
> > > people to verify the integrity of non signed files that are acquired
> over
> > > non secure (HTTPS) means directly from us, let alone files that have
> been
> > > altered from an infection.
> > >
> > >
> > > Cheers,
> > >
> > > Dan
> > >
> > > On Fri, Jul 19, 2019 at 10:06 AM Brecht Van Lommel <
> > > brechtvanlom...@gmail.com> wrote:
> > >
> > > > Hey all,
> > > >
> > > > Release candidate 2 is now available for download on blender.org.
> > > >
> > > > Last week a lot of fixes were done still. From this point on we will
> > > > only move over critical fixes to the release branch, it helps to
> > > > mention in the commit log if you want this to happen.
> > > >
> > > > Thanks,
> > > > Brecht.
> > > >
> > > > On Wed, Jul 17, 2019 at 6:40 PM Brecht Van Lommel
> > > >  wrote:
> > > > >
> > > > > Hey all,
> > > > >
> > > > > We're planning to do the ahoy for the release candidate 2 tomorrow
> > > > > July 18, around 16:00 CEST.
> > > > >
> > > > > That's when all the critical fixes should be in, let me know if
> > > > > there's something that's not going to make it in time.
> > > > >
> > > > > Thanks,
> > > > > Brecht.
> > > > >
> > > > > On Thu, Jul 11, 2019 at 7:37 PM Brecht Van Lommel
> > > > >  wrote:
> > > > > >
> > > > > > Hey everyone,
> > > > > >
> > > > > > We had some additional issues to solve. The release candidate
> builds
> > > > > > are ready now, but we'll 

Re: [Bf-committers] FTP access to download.b.o (was: Blender 2.80 Release Candidate - master frozen)

[Dan McGrath]

Hi,

On Fri, Jul 19, 2019 at 11:59 AM dr. Sybren A. Stüvel 
wrote:

> I agree with Dan. FTP is a old, insecure protocol, and we don't need
> anonymous uploads at all. Platform maintainers can use their SSH key to
> gain access to the file storage.
>

Agreed! Debian has also deprecated FTP. I was speaking with Brecht as well,
and given the go ahead to disable our FTP server indefinitely. While the
directory for "ftp" still exists, note that the actual ftp:// protocol
access to our download.blender.org server is considered disabled.


> I would recommend using a Yubikey for this, stored in a safe at the
> Blender Institute. Getting the right key is easy once it's poured into
> hardware.
>

Aye, in fact I was mentioning to Brecht that I use a Yubikey my SSH,
signing etc, for years now for access to the rack. They are very nice 2FA
devices, in addition to their signing abilities. While I can't speak for
Mac or Windows use, I know that Linux can use these very well. They would
also be good for 2FA for some of our other services, such as Wordpress, but
that is another topic.
On a side note, my apologies for not clarifying things more! The specific
situation was that, after not having a virus uploaded to our ftp/incoming/
folder in nearly a year (September 2019), one suddenly happened at nearly
the exact same time as our releases were starting to be populated. As a bit
of a panic'd reflex, I made the call to alert the blender.chat coders
channel, and after not getting responses from some core folks, I wrote the
email, as a precaution!

The specific situation details is that we used to allow FTP uploads to the
"incoming" area, which is how people generally put files into the server
for us. While we never allowed removing, appending, renaming, or
downloading of files via FTP, an attacker could very well have taken
advantage of this fact by colliding the filenames used for release. In this
particular case, the filename was info.zip, and was detected by the system
and moved out of the way, but you can imagine that this process is only so
effective. And while FTP never allowed downloads, people (such as eager
Blender users!) could always download the files via HTTP/HTTPS, if they
merely visited the well known url that we have historically used as a
community "drop box" of sorts. You can see my concerns!

Anyway, clearly I over reacted a bit, and ruffled some feathers! My
apologies! Glad to see the security issue finally getting kick started
though! I look forward to a Yubikey discussion! :)


Cheers,

Dan



>
> --
> Sybren A. Stüvel
>
> https://stuvelfoto.nl/
> https://stuvel.eu/
>
> ___
> 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] Blender 2.80 Release Candidate - master frozen

[Dan McGrath]

Hi,

It would appear that a windows virus "info.zip:
Win.Trojan.Coinminer-6622864-0 FOUND" was uploaded to another file in this
directory at the same time that you uploaded the windows RC.

I reported the issue in blender.chat, where some discussion was held by at
least some of the devs, but I would like to bring the matter to your
attention here, as well. With release around the corner, and our binaries
being a valuable target, that clearly was timed to happen during this
upload, I would advise that you at least verify the checksums of the file
that you uploaded, and that we immediately stop using a world writable FTP
for our release.

My recommendation is to immediately disable and remove FTP from our server,
and find alternative and secure means for the developers to share files.
The idea of sftp/scp only accounts on download.blender.org would even be an
improvement. In the long term, even this should be frowned upon though, as
a compromise of our web server (which should be considered to be untrusted,
and in a DMZ), would be a disaster on its own, but less so if we could at
least verify the integrity of the files (Mac/Win at least can be signed).

I would also strong advise that one of the developers create a GPG key that
is stored safely ofline, which can be used to officially sign the MD5/SHA
checksum files, and go through and retroactively sign and checksum our
entire archive as a precaution. This would also allow our users to verify
our downloads via mirror, as right now there is absolutely no way for
people to verify the integrity of non signed files that are acquired over
non secure (HTTPS) means directly from us, let alone files that have been
altered from an infection.


Cheers,

Dan

On Fri, Jul 19, 2019 at 10:06 AM Brecht Van Lommel <
brechtvanlom...@gmail.com> wrote:

> Hey all,
>
> Release candidate 2 is now available for download on blender.org.
>
> Last week a lot of fixes were done still. From this point on we will
> only move over critical fixes to the release branch, it helps to
> mention in the commit log if you want this to happen.
>
> Thanks,
> Brecht.
>
> On Wed, Jul 17, 2019 at 6:40 PM Brecht Van Lommel
>  wrote:
> >
> > Hey all,
> >
> > We're planning to do the ahoy for the release candidate 2 tomorrow
> > July 18, around 16:00 CEST.
> >
> > That's when all the critical fixes should be in, let me know if
> > there's something that's not going to make it in time.
> >
> > Thanks,
> > Brecht.
> >
> > On Thu, Jul 11, 2019 at 7:37 PM Brecht Van Lommel
> >  wrote:
> > >
> > > Hey everyone,
> > >
> > > We had some additional issues to solve. The release candidate builds
> > > are ready now, but we'll wait until tomorrow (July 12) to make them
> > > available and update blender.org.
> > >
> > > Thanks,
> > > Brecht.
> > >
> > > On Wed, Jul 10, 2019 at 5:22 PM Brecht Van Lommel
> > >  wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > We have entered the 2.80 release candidate phase now. That means
> > > > master will be mostly frozen, only important bugfixes should go in.
> > > > Please ensure commits are reviewed by another developer, and don't
> > > > make risky changes.
> > > >
> > > > Sergey will do the branching & tagging, after which platform
> > > > maintainers can make the release candidate builds. If all goes well
> > > > these builds go up on blender.org tomorrow, July 11.
> > > >
> > > > The final release is then planned for July 18, depending if any
> > > > critical issues come up that require more time. After this master
> will
> > > > be open for the 2.81 release cycle.
> > > >
> > > > Thanks,
> > > > Brecht.
> ___
> 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] blender developer documentation

[Dan McGrath]

And translators!


Dan

On Wed, Jul 17, 2019 at 8:33 AM Howard Trickey 
wrote:

> I was wondering: with the Epic grant, which Ton says, in part, will help
> onboarding new developers: if the development fund gets to be big enough to
> allow it, what about hiring a full-time technical writer to make really
> great developer documentation?
>
> I think a possible dream project would be a book like LInux Kernel
> Development
> <
> https://www.amazon.com/Linux-Kernel-Development-Robert-Love/dp/0672329468/ref=as_li_ss_tl?ie=UTF8=roblov-20
> >,
> giving a readable and comprehensive description of the architecture, data
> structures, development practices, etc.  Of course the downside to that
> would be that such a book will almost immediately start to be inaccurate.
> So part of the dream would be to keep it constantly updated. But even if
> that didn't happen, I think there are large swaths of design and data
> structures that will likely stay current for a number of years.
>
> Failing that, just doing a rewrite of all of the documentation that was in
> the old wiki would be very useful.
> ___
> 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

[Bf-committers] Datacenter maintenance for Blender.org

[Dan McGrath]

Hi,

As some of you may be aware, we planned on upgrading some of the RAM in our
servers today. The hope is to start in about 3 hours from now at, or
around, 4am EST (10am CEST), or sometime shortly thereafter.

We hope to have the 2 machines involved go down for about 20 minutes each.
There are other servers affected, but they are able to live migrate
servers, and are mostly running internal services and test VM's.

I am also putting Devtalk into read-only for an upgrade, as well as keeping
it so until after the upgrades are completed, to avoid people getting cut
of mid post, among other things.

Barring the Russian dropping a server, or snapping off a DIMM, we should
hopefully be done in an hour or so. I may also need to reboot the switch to
enable some jumbo frame support, so expect a possible 2min full outage to
kick things off. :)


Cheers,

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

Re: [Bf-committers] developer.blender.org maintenance/outage

[Dan McGrath]

Hi,

It would appear that the speed up that we had from the previous tweaks,
which were great, also caused the crawling effect on the site to amplify.
This, however, has the negative effect of bringing an old TODO/BUG in the
MySQL setup that causes it to slowly bleed memory into swap (despite having
`--memlock`). It is unknown to me why this happens, but just recently it
caused that server to put itself into swap again.

I had to reboot the server and tweak some settings for MySQL to try curb
it's usage a bit, so we will see how it goes. I would like to disable swap
entirely, but i fear that the system will end up killing some critical
service in an OOM killer fashion while nobody is around. In the meantime,
we poked the higher powers about some much needed RAM for this server! If
you can't make SQL behave, than make it's working set fit in RAM, damnit! :D


Cheers,

Dan

On Tue, Jun 18, 2019 at 11:04 PM Dan McGrath 
wrote:

> Hi,
>
> Just giving you all an update on the issue from earlier today on the
> developer.blender.org slow downs and outages.
>
> First of all, the reports of our assimilation into the B.ORG collective
> have been greatly exaggerated! :D As I am not one for writing big fancy
> professional reports, I will try keep it short, and to the point.
>
> Yesterday, Phabricator started to experience slowdown, which was hard to
> properly look into, as I was already busy prepping the night before to
> replace a server in the data center, which only slowed things down more. A
> quick look into the issue showed that the hard drives were being exhausted
> with writes. Looking into it a bit more, it seemed that when people visit
> the site, the site invokes `git --log` on the commits so that it can be
> rendered and displayed to the user. The actual problem would appear to be
> that these files go to a directory on disk (synchronously?), which created
> the write IOP starvation that we saw.
>
> As a workaround, I have changed the ZFS `sync` setting on this dataset to
> disabled, which appears to have relaxed the storm a bit. The directory
> these uploads go to is a double hashed directory (./AA/AA/, ./AB/AA/,
> ./AC/AA, etc.) which totals about 64k directories (OH MY GOD), so even
> doing a `find ./` takes 20 minutes on these systems. We can try to
> experiment with putting those files on their own dataset in ZFS, with tuned
> recordsizes and properties, but this may not help as much as an SSD, and
> more RAM.
>
> For now, I will leave the sync in the disabled state so that Phabricator
> isn't bogged down. The problem is that the server it's on, with it's
> current setup, can't just have it's drives replaced unless the new drives
> are exactly the same, or bigger, than the 2TB HDD's (without reinstall),
> and 2TB SSD's aren't exactly ideal on that old clunker of a box! Worse, to
> move stuff off there is tricky as it is also our some of our Bacula
> storage, which has nowhere to go without moving a lot of stuff around and
> maybe adding more hard drives to Proxmox, which takes time to setup.
>
> Anyway, that is all details for me and the crew to bang out. We will try
> keep an eye on things. Sorry for the delays in your bug reports!
>
>
> Cheers,
>
> Dan McGrath
>
> On Tue, Jun 18, 2019 at 3:35 AM Dan McGrath 
> wrote:
>
>> Hi,
>>
>> It seems that a few hours ago that developer.blender.org became horribly
>> slow and unusable. While the exact cause is still to be determined, the
>> HTTP logs were tossing an excessive amount of errors about unsafe strings.
>>
>> Sergey is en route to the data center for some planned maintenance
>> (replace a server), but has already queued up some git commits to help
>> address some of the issues with the PHP errors, and plans to poke at it
>> some more once we get things sorted out.
>>
>> Sorry for the inconvenience!
>>
>>
>> Cheers,
>>
>> Dan McGrath
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] developer.blender.org maintenance/outage

[Dan McGrath]

Hi,

Just giving you all an update on the issue from earlier today on the
developer.blender.org slow downs and outages.

First of all, the reports of our assimilation into the B.ORG collective
have been greatly exaggerated! :D As I am not one for writing big fancy
professional reports, I will try keep it short, and to the point.

Yesterday, Phabricator started to experience slowdown, which was hard to
properly look into, as I was already busy prepping the night before to
replace a server in the data center, which only slowed things down more. A
quick look into the issue showed that the hard drives were being exhausted
with writes. Looking into it a bit more, it seemed that when people visit
the site, the site invokes `git --log` on the commits so that it can be
rendered and displayed to the user. The actual problem would appear to be
that these files go to a directory on disk (synchronously?), which created
the write IOP starvation that we saw.

As a workaround, I have changed the ZFS `sync` setting on this dataset to
disabled, which appears to have relaxed the storm a bit. The directory
these uploads go to is a double hashed directory (./AA/AA/, ./AB/AA/,
./AC/AA, etc.) which totals about 64k directories (OH MY GOD), so even
doing a `find ./` takes 20 minutes on these systems. We can try to
experiment with putting those files on their own dataset in ZFS, with tuned
recordsizes and properties, but this may not help as much as an SSD, and
more RAM.

For now, I will leave the sync in the disabled state so that Phabricator
isn't bogged down. The problem is that the server it's on, with it's
current setup, can't just have it's drives replaced unless the new drives
are exactly the same, or bigger, than the 2TB HDD's (without reinstall),
and 2TB SSD's aren't exactly ideal on that old clunker of a box! Worse, to
move stuff off there is tricky as it is also our some of our Bacula
storage, which has nowhere to go without moving a lot of stuff around and
maybe adding more hard drives to Proxmox, which takes time to setup.

Anyway, that is all details for me and the crew to bang out. We will try
keep an eye on things. Sorry for the delays in your bug reports!


Cheers,

Dan McGrath

On Tue, Jun 18, 2019 at 3:35 AM Dan McGrath  wrote:

> Hi,
>
> It seems that a few hours ago that developer.blender.org became horribly
> slow and unusable. While the exact cause is still to be determined, the
> HTTP logs were tossing an excessive amount of errors about unsafe strings.
>
> Sergey is en route to the data center for some planned maintenance
> (replace a server), but has already queued up some git commits to help
> address some of the issues with the PHP errors, and plans to poke at it
> some more once we get things sorted out.
>
> Sorry for the inconvenience!
>
>
> Cheers,
>
> Dan McGrath
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] developer.blender.org maintenance/outage

[Dan McGrath]

Hi,

It seems that a few hours ago that developer.blender.org became horribly
slow and unusable. While the exact cause is still to be determined, the
HTTP logs were tossing an excessive amount of errors about unsafe strings.

Sergey is en route to the data center for some planned maintenance (replace
a server), but has already queued up some git commits to help address some
of the issues with the PHP errors, and plans to poke at it some more once
we get things sorted out.

Sorry for the inconvenience!


Cheers,

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

Re: [Bf-committers] Potentially moving from IRC to Blender.Chat

[Dan McGrath]

Hi,

Maybe a good feature to have handy is the ability to ban email domains,
possibly based on a regex, similar to how the mailing lists and postfix etc
allow. Otherwise what happens is people will start to find free mail hosts,
aside from Gmail and ones that have fairly good security already, and mass
sign up.


Dan

On Tue, Apr 30, 2019 at 10:50 AM dr. Sybren A. Stüvel 
wrote:

> On 30-04-19 16:18, Ton Roosendaal wrote:
> > - Are there good options to manage trolls and bans?
>
> Yes. We can ban user accounts on Blender.chat, and it's also harder to
> create a new account on Blender ID than it is on FreeNode (you need
> email verification). If it turns out to be necessary we can also invest
> some time into adding Captchas and blocking of IP ranges to Blender ID.
>
> --
> Sybren A. Stüvel
>
> https://stuvelfoto.nl/
> https://stuvel.eu/
>
> ___
> 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

[Bf-committers] Phabricator upgrade outage

[Dan McGrath]

Hi,

The developer.blender.org host will be going down for a minor package
upgrade. The downtime should be less than 5 minutes and will start at
8:10am EDT (2:10pm CST).


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

Re: [Bf-committers] Maintenance tonight

[Dan McGrath]

Hi,

Well, that should be it for tonight (catching a few hosts up to last
updates for quarter). Bigger updates later this week. Let me know is
anything seems off, thanks!


Dan

On Sat, Apr 13, 2019 at 9:50 PM Dan McGrath  wrote:

> Hi,
>
> Just a heads up that I am currently, and will be for a while, upgrading
> and doing some all around maintenance and upgrades on the rack tonight.
> Outages should hopefully be brief and spread out, but things happen!
>
> Worst case, I am on IRC if you feel that I need to be contacted about some
> emergency, but I would appreciate not being distracted while I tackle the
> work.
>
> Thanks!
>
>
> Dan McGrath
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Maintenance tonight

[Dan McGrath]

Hi,

Just a heads up that I am currently, and will be for a while, upgrading and
doing some all around maintenance and upgrades on the rack tonight. Outages
should hopefully be brief and spread out, but things happen!

Worst case, I am on IRC if you feel that I need to be contacted about some
emergency, but I would appreciate not being distracted while I tackle the
work.

Thanks!


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

[Bf-committers] Rack is under a moderate DoS

[Dan McGrath]

Hi,

Just a heads up for some that maybe aren't in the know that today, off an
on, there has been a steady 80-100Mbit worth of unsolicited UDP traffic
targeting our www server IP address on a closed port from, mainly one IP,
but also some random bursts from other IP's that peg our bandwidth at 1Gbit
for brief [1] moments.

Unfortunately, being UDP and to an already closed port, there is really
nothing that we can do other than talk to our upstream about monitoring and
blocking traffic to these obvious ports. But as we all know with games of
whack-a-troll, they will likely just switch to something less obvious and
more drastic.

So I guess just keep this is mind when you go to access the site that some
slow down may occur until the ISP can put some blocks in place upstream.


Cheers,

Dan

[1]
https://download.blender.org/ftp/dan/admin/Screenshot_2019-03-04_14-41-06.png
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Mailman outage from bad compile option

[Dan McGrath]

Hi,

Just a heads up that earlier a repo replacement for the mail server ended
up replacing our mailman binary with one that wasn't setup for postfix that
ended up breaking the delivery of mail to our mailing lists.

If you are receiving this email, it probably means that things are fine!
Thanks to rboxman on IRC for reporting the issue.


Cheers,

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

[Bf-committers] Server upgrades for www/wiki/download.b.o

[Dan McGrath]

Just a heads up that I will have to take http://www.blender.org ,
http://wiki.blender.org  and http://download.blender.org  offline for some
upgrades that have been pilling up! This will impact the Blender ID logins,
sorry!


Cheers,

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

Re: [Bf-committers] documentation commit issue ?

[Dan McGrath]

Hi Julien,

Ah, seems I had the py36-subversion installed, which of course that script
did NOT fancy! :D

I have installed the py27 version that mailer.py needed, and it at least
doesn't throw an error message any more in the CLI. Try again, please!


Cheers,

Dan

On Tue, Feb 5, 2019 at 3:23 PM Julien Duroure 
wrote:

> Hello Dan,
>
> You're right, I can now see my commit.
> I just did another one, and this time, I have to following error:
> (same again, after propagation, so commit is OK, I received the email and
> can see my commit) :
>
> post-commit hook failed (exit code 1) with output:
> > Traceback (most recent call last):
> >   File "/usr/local/share/subversion/hook-scripts/mailer/mailer.py", line
> > 74, in 
> > import svn.fs
> > ImportError: No module named svn.fs
> >
>
> Cheers,
>
> Julien
>
> On Tue, Feb 5, 2019 at 9:13 PM Dan McGrath 
> wrote:
>
> > Hi,
> >
> > Seems that mailer.py was dependant on python 2.7, which we removed in an
> > attempt to switch to only 3.6. I have reinstalled Python 2.7 in the
> > meantime, so this shouldn't happen again. Also, I see that your change it
> > in Phabricator (it takes a bit to show up). See
> > https://developer.blender.org/rBM4566
> >
> > Thanks for the heads up!
> >
> >
> > Cheers,
> >
> > Dan
> >
> > On Tue, Feb 5, 2019 at 3:07 PM Julien Duroure 
> > wrote:
> >
> > > Hello,
> > >
> > > I just commit my first documentation update, and I got the following
> > > message:
> > >
> > > Envoi  manual/addons/index.rst
> > > > Ajout  manual/addons/io_gltf2.rst
> > > > Ajout   (bin)  manual/images/addons_io-gltf2-material-principled.png
> > > > Ajout   (bin)  manual/images/addons_io-gltf2-material-unlit.png
> > > > Transmission des données done
> > > > Transaction de propagation...
> > > > Révision 4566 propagée.
> > > >
> > >
> > > So seems revision 4566 is correctly propagated, but ...
> > >
> > > post-commit hook failed (exit code 127) with output:
> > > > /data/svn/repos/bf-manual/hooks/post-commit:
> > > > /usr/local/share/subversion/hook-scripts/mailer/mailer.py: not found
> > > >
> > >
> > > And I can't see my commit here:
> > > https://developer.blender.org/diffusion/BM/history/trunk/blender_docs
> > >
> > > Is there something I did wrong?
> > >
> > > Cheers,
> > >
> > > Julien
> > > ___
> > > 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
> >
> ___
> 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] documentation commit issue ?

[Dan McGrath]

Hi,

Seems that mailer.py was dependant on python 2.7, which we removed in an
attempt to switch to only 3.6. I have reinstalled Python 2.7 in the
meantime, so this shouldn't happen again. Also, I see that your change it
in Phabricator (it takes a bit to show up). See
https://developer.blender.org/rBM4566

Thanks for the heads up!


Cheers,

Dan

On Tue, Feb 5, 2019 at 3:07 PM Julien Duroure 
wrote:

> Hello,
>
> I just commit my first documentation update, and I got the following
> message:
>
> Envoi  manual/addons/index.rst
> > Ajout  manual/addons/io_gltf2.rst
> > Ajout   (bin)  manual/images/addons_io-gltf2-material-principled.png
> > Ajout   (bin)  manual/images/addons_io-gltf2-material-unlit.png
> > Transmission des données done
> > Transaction de propagation...
> > Révision 4566 propagée.
> >
>
> So seems revision 4566 is correctly propagated, but ...
>
> post-commit hook failed (exit code 127) with output:
> > /data/svn/repos/bf-manual/hooks/post-commit:
> > /usr/local/share/subversion/hook-scripts/mailer/mailer.py: not found
> >
>
> And I can't see my commit here:
> https://developer.blender.org/diffusion/BM/history/trunk/blender_docs
>
> Is there something I did wrong?
>
> Cheers,
>
> Julien
> ___
> 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

[Bf-committers] Outage with SVN commits related to Phabricator update

[Dan McGrath]

Hi,

Just a heads up that it would appear that a recent update to Phabricator to
hide certain activity from being displayed on our recent activity section,
also inadvertently broke our SVN account synchronisation.

Reads (anonymous) should be just fine, but expect to not be able to commit
to any SVN until this issue is resolved.

Sorry for the inconvenience!


Cheers,

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

Re: [Bf-committers] Fwd: Re: Error after Updates to developer/git/svn/buildbot

[Dan McGrath]

Hey,

Awesome, ty Basiten!

Dan

On Sat, Feb 2, 2019 at 4:28 PM Bastien Montagne 
wrote:

>
>
>
>  Forwarded Message 
> Subject:Re: [Bf-committers] Error after Updates to
> developer/git/svn/buildbot
> Date:   Sat, 2 Feb 2019 22:27:29 +0100
> From:   Bastien Montagne 
> To: Dan McGrath 
>
>
>
> Yep, seems to be working fine again, thanks! :)
>
> On 02/02/2019 22:20, Dan McGrath wrote:
> > Hey,
> >
> > Ah, sorry about that! A last minute change I replaced py27-gitsosis with
> > py36-gitosis. I reverted it to py27 for now. Try again!
> >
> >
> > Dan
> >
> > On Sat, Feb 2, 2019 at 1:58 PM Sergey Sharybin 
> wrote:
> >
> >> Ah, indeed need to be non-anonymous to see the issue.
> >>
> >> Tried to quickly poke the code to convert the octal values to a proper
> >> Python3 notation, and then also needed to tweak exception handling
> syntax..
> >> But that just opens a bigger rabbit hole to hell: more and more areas of
> >> Gitosis seems to be incompatible with Python3.
> >>
> >> Python2 seems to be unavailable on that host anymore. Restoring it
> probably
> >> is easier/faster.
> >>
> >> P.S. I am also not quite sure why we are still on Gitosis and not on
> >> Gitolite. The former is no longer maintained, the latter one is what
> Linux
> >> distors are providing. So can not expect Gitosis to be ported to
> Python3.
> >>
> >> On Sat, Feb 2, 2019 at 7:09 PM Bastien Montagne 
> >> wrote:
> >>
> >>> Can confirm same issue here as well (debian64 testing).
> >>>
> >>> On 02/02/2019 18:36, Ray Molenkamp wrote:
> >>>> Same issue here,
> >>>>
> >>>> anonymous usage seems to work
> >>>>
> >>>> git clone git://git.blender.org/blender.git
> >>>>
> >>>> works, however authenticated users
> >>>>
> >>>> git clone g...@git.blender.org:blender.git
> >>>>
> >>>> fail with the error mentioned earlier
> >>>>
> >>>> --Ray
> >>>>
> >>>>
> >>>> On 2/2/2019 10:30 AM, Howard Trickey wrote:
> >>>>> Happens for me too. git pull from origin/master of blender repository
> >>>>>
> >>>>>
> >>>>> On Sat, Feb 2, 2019 at 12:14 PM Sergey Sharybin <
> sergey@gmail.com
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> util.mkdir(p, 0750)
> >>>>>> AFAIK, this should be 0o750 for Python3. The code seems to be from
> >>>>>> gitsosis, which we use from an upstream.
> >>>>>>
> >>>>>> What is more weird is that for me `git pull` works fine. Does this
> >>> still
> >>>>>> happen for you? Which exact repo causes the issue?
> >>>>>>
> >>>>>> On Sat, Feb 2, 2019 at 5:15 PM blendergit 
> >>> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Not sure if you have completed the update, but today when I try to
> >> run
> >>>>>>> “git pull”, I get this:
> >>>>>>>
> >>>>>>> $ git pull
> >>>>>>> Traceback (most recent call last):
> >>>>>>>  File "/usr/local/bin/gitosis-serve", line 11, in 
> >>>>>>>load_entry_point('gitosis==0.2', 'console_scripts',
> >>>>>> 'gitosis-serve')()
> >>>>>>>  File
> >>>>>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>>>>> line   487, in load_entry_point
> >>>>>>>    return get_distribution(dist).load_entry_point(group, name)
> >>>>>>>  File
> >>>>>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>>>>> line   2728, in
> load_entry_point
> >>>>>>>return ep.load()
> >>>>>>>  File
> >>>>>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>>>>> line   2346, in load
> >>>

Re: [Bf-committers] Error after Updates to developer/git/svn/buildbot

[Dan McGrath]

Hey,

Ah, sorry about that! A last minute change I replaced py27-gitsosis with
py36-gitosis. I reverted it to py27 for now. Try again!


Dan

On Sat, Feb 2, 2019 at 1:58 PM Sergey Sharybin  wrote:

> Ah, indeed need to be non-anonymous to see the issue.
>
> Tried to quickly poke the code to convert the octal values to a proper
> Python3 notation, and then also needed to tweak exception handling syntax..
> But that just opens a bigger rabbit hole to hell: more and more areas of
> Gitosis seems to be incompatible with Python3.
>
> Python2 seems to be unavailable on that host anymore. Restoring it probably
> is easier/faster.
>
> P.S. I am also not quite sure why we are still on Gitosis and not on
> Gitolite. The former is no longer maintained, the latter one is what Linux
> distors are providing. So can not expect Gitosis to be ported to Python3.
>
> On Sat, Feb 2, 2019 at 7:09 PM Bastien Montagne 
> wrote:
>
> > Can confirm same issue here as well (debian64 testing).
> >
> > On 02/02/2019 18:36, Ray Molenkamp wrote:
> > > Same issue here,
> > >
> > > anonymous usage seems to work
> > >
> > > git clone git://git.blender.org/blender.git
> > >
> > > works, however authenticated users
> > >
> > > git clone g...@git.blender.org:blender.git
> > >
> > > fail with the error mentioned earlier
> > >
> > > --Ray
> > >
> > >
> > > On 2/2/2019 10:30 AM, Howard Trickey wrote:
> > >> Happens for me too. git pull from origin/master of blender repository
> > >>
> > >>
> > >> On Sat, Feb 2, 2019 at 12:14 PM Sergey Sharybin  >
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>>> util.mkdir(p, 0750)
> > >>> AFAIK, this should be 0o750 for Python3. The code seems to be from
> > >>> gitsosis, which we use from an upstream.
> > >>>
> > >>> What is more weird is that for me `git pull` works fine. Does this
> > still
> > >>> happen for you? Which exact repo causes the issue?
> > >>>
> > >>> On Sat, Feb 2, 2019 at 5:15 PM blendergit 
> > wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> Not sure if you have completed the update, but today when I try to
> run
> > >>>> “git pull”, I get this:
> > >>>>
> > >>>> $ git pull
> > >>>> Traceback (most recent call last):
> > >>>>File "/usr/local/bin/gitosis-serve", line 11, in 
> > >>>>  load_entry_point('gitosis==0.2', 'console_scripts',
> > >>> 'gitosis-serve')()
> > >>>>File
> > >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > >>>> line   487, in load_entry_point
> > >>>>  return get_distribution(dist).load_entry_point(group, name)
> > >>>>File
> > >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > >>>> line   2728, in load_entry_point
> > >>>>  return ep.load()
> > >>>>File
> > >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > >>>> line   2346, in load
> > >>>>  return self.resolve()
> > >>>>File
> > >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > >>>> line   2352, in resolve
> > >>>>  module = __import__(self.module_name, fromlist=['__name__'],
> > level=0)
> > >>>>File "/usr/local/lib/python3.6/site-packages/gitosis/serve.py",
> > line
> > >>> 142
> > >>>>  util.mkdir(p, 0750)
> > >>>>   ^
> > >>>> SyntaxError: invalid token
> > >>>> fatal: Could not read from remote repository.
> > >>>>
> > >>>> Please make sure you have the correct access rights
> > >>>> and the repository exists.
> > >>>>
> > >>>> I’m running on Windows 10.
> > >>>>
> > >>>> Regards,
> > >>>> Antonio Vázquez
> > >>>>
>

[Bf-committers] Updates to developer/git/svn/buildbot

[Dan McGrath]

Hi,

Just a heads up that today I upgraded the following sites to the latest
2019Q1 ports in FreeBSD:

  - developer.blender.org
  - git.blender.org
  - svn.blender.org
  - builder.blender.org

As well, the Phabricator (developer.b.o) PHP was upgraded from PHP 5.6 to
7.2. Overall the site seems nice and zippy when doing cached pages, but
otherwise, keep an eye out for horrible stuff!

Also, if it's good, nice! But if it breaks, it wasn't me that touched
anything, and is all Sergey Sharybin's fault! ><

At some point the host will go down for a FreeBSD upgrade from 11 to 12.
Probably on Monday or so, I will let you know here.


Cheers,

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

Re: [Bf-committers] Upgrade and reboot for code services

[Dan McGrath]

Hi,

I don't think so, no. The date of the Linux stuff there was 31st of
October. The changes I made were after that. Sergey deals with the buildbot
configuration, he would know best here.


Dan

On Sun, Nov 4, 2018 at 5:29 AM Knapp  wrote:

> Is this why https://builder.blender.org/download/ linux builds are still
> from last month?
>
> On Sat, Nov 3, 2018 at 8:08 PM Dan McGrath 
> wrote:
>
> > Hi,
> >
> > Seems that things are back again. Was only minor updates
> (11.2p0->p4/Q3-Q4)
> > so everything should be fine. But I am also a nubcake, so yell at me if I
> > missed something important :D o/
> >
> >
> > Cheers,
> >
> > Dan
> >
> > On Sat, Nov 3, 2018 at 2:38 PM Dan McGrath 
> > wrote:
> >
> > > Hi,
> > >
> > > Just a heads up that at 2:45pm EST (7:45pm CEST/6:45pm UTC) I will do a
> > > quick BSD upgrade (2018Q3 -> 2018Q4 stuff is already done). This will
> > > affect the following sites:
> > >
> > >   - git.blender.org
> > >   - svn.blender.org
> > >   - builder.blender.org
> > >   - developer.blender.org
> > >
> > > The downtime shouldn't be more than 30 minutes.
> > >
> > >
> > > Cheers,
> > >
> > > Danny McGrath
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
> --
> Douglas E Knapp, MSAOM, LAc.
> ___
> 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] Upgrade and reboot for code services

[Dan McGrath]

Hi,

Seems that things are back again. Was only minor updates (11.2p0->p4/Q3-Q4)
so everything should be fine. But I am also a nubcake, so yell at me if I
missed something important :D o/


Cheers,

Dan

On Sat, Nov 3, 2018 at 2:38 PM Dan McGrath  wrote:

> Hi,
>
> Just a heads up that at 2:45pm EST (7:45pm CEST/6:45pm UTC) I will do a
> quick BSD upgrade (2018Q3 -> 2018Q4 stuff is already done). This will
> affect the following sites:
>
>   - git.blender.org
>   - svn.blender.org
>   - builder.blender.org
>   - developer.blender.org
>
> The downtime shouldn't be more than 30 minutes.
>
>
> Cheers,
>
> Danny McGrath
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Upgrade and reboot for code services

[Dan McGrath]

Hi,

Just a heads up that at 2:45pm EST (7:45pm CEST/6:45pm UTC) I will do a
quick BSD upgrade (2018Q3 -> 2018Q4 stuff is already done). This will
affect the following sites:

  - git.blender.org
  - svn.blender.org
  - builder.blender.org
  - developer.blender.org

The downtime shouldn't be more than 30 minutes.


Cheers,

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

Re: [Bf-committers] Outage for blender.org

[Dan McGrath]

Hi,

Seems like not long after I sent this email, things started to come back.
Not sure about much else yet, but I'm sure you will notice if the site goes
out again ;)


Cheers,

Dan

On Sun, Oct 14, 2018 at 3:01 AM Dan McGrath  wrote:

> Hi,
>
> Just a heads up that it seems that the ISP suddenly decided to ignore all
> ARP packets on our servers except for 2, which is affecting multiple hosts.
> Sintel and Franky appear to be doing ARP fine, but the ISP is asking us to
> ARP for our other IP's dozens of times per second, but is completely
> ignoring our replies for some reason. Nothing on our end changed, so I can
> only assume the problem is upstream.
>
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Outage for blender.org

[Dan McGrath]

Hi,

Just a heads up that it seems that the ISP suddenly decided to ignore all
ARP packets on our servers except for 2, which is affecting multiple hosts.
Sintel and Franky appear to be doing ARP fine, but the ISP is asking us to
ARP for our other IP's dozens of times per second, but is completely
ignoring our replies for some reason. Nothing on our end changed, so I can
only assume the problem is upstream.


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

Re: [Bf-committers] git warning?

[Dan McGrath]

Hi,

Oh? Hmm that's odd, the blender_multimail pyc file is still old, so it
would appear that one wasn't called yet, or it's pyc file would have been
recreated after I edited the py file:

  -rwxr-xr-x  1 git  git  85296 Aug 20 06:01 blender_multimail.py*
  -rw-r--r--  1 git  git  78850 Jun  8  2016 blender_multimail.pyc

Unless it's meant to be git_daemon instead of git id, which is quite
possible since git_daemon is the process it's running as. Let me make the
dir group writable and see if it gets created as git_daemon, and could
explain why the daemon process can't recreate the file, but could always
run/read it.

Ah, I also see the hoot/update and similar files for bf repo have an old
python2 env shebang. Let me update that and then track down all the old
ones.

At a glance it seems that some are bash, but most are python2:

#> find ./ -type f -name post-receive -exec head -n1 '{}' + | grep python2
==> ./blender-addons.git/hooks/post-receive <==
#!/usr/bin/env python2
==> ./blender-translations.git/hooks/post-receive <==
#!/usr/bin/env python2
==> ./blender.git/hooks/post-receive <==
#!/usr/bin/env python2
==> ./gitosis-admin.git/hooks/post-receive <==
#!/usr/bin/env python2
==> ./blender-addons-contrib.git/hooks/post-receive <==
#!/usr/bin/env python2
==> ./phabricator.git/hooks/post-receive <==
#!/usr/bin/env python2

Okay, I changed those few files to python2.7. Also, a `grep 'python2'
*/hooks/*` now shows only:

  blender-addons-contrib.git/hooks/post-receive:#!/usr/bin/env python2.7
  blender-addons.git/hooks/post-receive:#!/usr/bin/env python2.7
  blender-translations.git/hooks/post-receive:#!/usr/bin/env python2.7
  blender.git/hooks/post-receive:#!/usr/bin/env python2.7
  gitosis-admin.git/hooks/post-receive:#!/usr/bin/env python2.7
  phabricator.git/hooks/post-receive:#!/usr/bin/env python2.7


So hopefully that is fixed now. Also, sorry for the hassle! These old
systems collect dust ;)

Note: $5 says we break mail again when I remove 2.7 :D



Dan

On Mon, Aug 20, 2018 at 12:39 AM Joshua Leung  wrote:

> Nope, emails still don't seem to be getting sent, but I also didn't see any
> warnings about python2 when pushing, so at least we're seeing some progress
> now ;)
>
> On Mon, Aug 20, 2018 at 4:07 PM Dan McGrath 
> wrote:
>
> > Hi Joshua,
> >
> > Ah, that's probably the cause then. I was wondering why git wasn't
> > relinking properly. Sure enough, the shebang for the mailhook blender
> uses
> > had `env python2` instead of `python2.7`. I've updated the mailhook for
> > now. Try a commit and see how that goes?
> >
> > The more modern approach I think would be to use the one found in
> > /usr/local/share that ships with svn (I test/use it now for the manual
> > commits), but it's possibly lacking some of the output compared to the
> one
> > we have in use now from like 15 years ago :p
> >
> >
> > Dan
> >
> > On Sun, Aug 19, 2018 at 11:58 PM Joshua Leung 
> wrote:
> >
> > > Hi Dan,
> > >
> > > Hmm... interesting. Maybe this is why most commit messages from the
> last
> > > day or so don't seem to have been coming through on the mailing list.
> > The
> > > last ones were from Aug 18th.
> > >
> > > Regards,
> > > Joshua
> > >
> > > On Mon, Aug 20, 2018 at 3:52 PM Dan McGrath 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Try again? Recently switched from py2.7 to py3.6 in there, but
> > apparently
> > > > it still thinks git should be linked to 2.7 for some reason. Worst
> > case I
> > > > can symlink, but lets see if reinstalling ports helps. Let me know,
> > > thanks.
> > > >
> > > >
> > > > Dan
> > > >
> > > > On Sun, Aug 19, 2018 at 8:08 PM Ray Molenkamp 
> > wrote:
> > > >
> > > > > All,
> > > > >
> > > > > Not sure who to poke for this, but since a few days when committing
> > > > > through git push
> > > > >
> > > > > git it now spits back a python related warning/error
> > > > >
> > > > > k:\BlenderGit\blender>git push
> > > > > Counting objects: 6, done.
> > > > > Delta compression using up to 8 threads.
> > > > > Compressing objects: 100% (6/6), done.
> > > > > Writing objects: 100% (6/6), 696 bytes | 696.00 KiB/s, done.
> > > > > Total 6 (delta 5), reused 0 (delta 0)
> > > > > remote: env: python2: No such file or directory
> > > > > To git.blender.org:blender.git
> > > > >b6b6eab6ae9..2349273ade5  m

Re: [Bf-committers] git warning?

[Dan McGrath]

Hi,

Try again? Recently switched from py2.7 to py3.6 in there, but apparently
it still thinks git should be linked to 2.7 for some reason. Worst case I
can symlink, but lets see if reinstalling ports helps. Let me know, thanks.


Dan

On Sun, Aug 19, 2018 at 8:08 PM Ray Molenkamp  wrote:

> All,
>
> Not sure who to poke for this, but since a few days when committing
> through git push
>
> git it now spits back a python related warning/error
>
> k:\BlenderGit\blender>git push
> Counting objects: 6, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (6/6), done.
> Writing objects: 100% (6/6), 696 bytes | 696.00 KiB/s, done.
> Total 6 (delta 5), reused 0 (delta 0)
> remote: env: python2: No such file or directory
> To git.blender.org:blender.git
>b6b6eab6ae9..2349273ade5  master -> master
>
> The commits still go through, anyhow, someone should probably look at that?
>
> --Ray
>
>
>
>
>
> ___
> 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] DoS against blender.org

[Dan McGrath]

Hi,

Okay, it seems that they gave up. It was just blind port 53 traffic being
blasted at us, despite the fact that we don't even run DNS on the rack.
While it may have stopped now, this was one of several attacks today
against the servers. Hopefully it's done with though!

A pretty picture for the curious:

http://pasteall.org/pic/show.php?id=2907a8d5c51a7ad50fda2eefa16f4caa


Cheers,

Dan

On Mon, Jul 30, 2018 at 11:19 PM Dan McGrath 
wrote:

> Hi,
>
> Well the subject pretty much says it all, but atm we are currently getting
> hit with a full gigabit per second towards the server hosting www.
>
> Not a whole lot to be done, but code related services may at least get
> some packets out of the network.
>
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] DoS against blender.org

[Dan McGrath]

Hi,

Well the subject pretty much says it all, but atm we are currently getting
hit with a full gigabit per second towards the server hosting www.

Not a whole lot to be done, but code related services may at least get some
packets out of the network.


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

Re: [Bf-committers] Phabricator downtime

[Dan McGrath]

Hi,

Things should be back to normal, albeit a tad slow while the caches prime,
and the current MySQL checks run. Some of you may have visited the site
during this maintenance window and been redirected to a /maintenance.php
url. Sadly this horrible system leaves you stuck on this url (/me slaps the
russian who will remain unnamed), so just remove this filename from the url
and reload your page!


Cheers,

Dan

On Thu, Jul 26, 2018 at 8:51 PM Dan McGrath  wrote:

> Hi,
>
> I will be taking the MySQL for Phabricator (developer.blender.org) down
> tonight around 9pm EST (3am CEST) to migrate the files to a more optimised
> ZFS dataset.
>
> The outage should be between 30-60 minutes. Live rsync tests showed about
> 40 minutes, but there will be some extra time needed to verify things, etc.
>
>
> Cheers,
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Phabricator downtime

[Dan McGrath]

Hi,

I will be taking the MySQL for Phabricator (developer.blender.org) down
tonight around 9pm EST (3am CEST) to migrate the files to a more optimised
ZFS dataset.

The outage should be between 30-60 minutes. Live rsync tests showed about
40 minutes, but there will be some extra time needed to verify things, etc.


Cheers,

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

[Bf-committers] Mail outage for blender.org

[Dan McGrath]

Hi,

Just noticed that there was a lack of mail due to a misconfiguration of
postfix for a few hours tonight from me attempting to deal with a spammer.
My apologies for any disruption, and the mail should be working again now.


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

[Bf-committers] Server maintenance

[Dan McGrath]

Hi,

Just a heads up that I will be doing a quick upgrade shortly today around
8:30PM CEST / 2:30pm EST that will affect the following services: git, svn,
phabricator and buildbot.

The downtime shouldn't be more than 20-30minutes.


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

Re: [Bf-committers] Wiki pygments throwing exceptions

[Dan McGrath]

Also, a big thanks to da_wunder from #symfony on Freenode for help
troubleshooting things!

On Fri, Jun 22, 2018 at 1:31 PM Dan McGrath  wrote:

> Hi,
>
> Just a heads up that there was some progress made with GeSHi syntax
> highlighting today for the wiki.
>
> Originally we were using a system wide pygmentize, due to not having php
> composer installed (or aware of what it did, even!). Now, I have switched
> to the proper upstream pygmentize, ran the updates from it to pull down its
> dependencies, and try use that.
>
> At first it we still spitting out some broken pages, but these were
> clearly just cached pages. I have since purged the memcached and all of the
> past broken pages that I noticed appear to work now. So I guess try using
> proper  syntax again on the wiki, but let me know if you
> run into any broken pages so that we can ensure that the problem was
> related to the system installed pygmentize without full dependencies, being
> the problem.
>
>
> Dan
>
> On Sun, Jun 17, 2018 at 10:48 AM Dan McGrath 
> wrote:
>
>> Hi,
>>
>> Just a heads up that I noticed that a small handful of pages were
>> throwing MW exceptions on the wiki when using syntax highlighting. An
>> example is:
>>
>>   https://wiki.blender.org/wiki/Tools/Git
>>
>> If you edit this page and change the very first  back
>> to , it will throw an exception in the GeSHI syntax
>> highlight extension, which uses pygmentize. I don't know much more than
>> this, so if you see an MW exception when trying to view a page, I would
>> suggest to try change some/all of the lang's from bash to sh for now.
>>
>> On a side note, I have noticed that there are no redirects for the now
>> removed namespaces (eg: Dev:Doc) where some old pages used to reside, but
>> have been moved. I believe the proper way to migrate such pages is to put
>> it in the original place (Dev:Doc/Foobar) and then move it to the new
>> location (/Foobar), so that a redirect is placed for people using the old
>> URLs. See https://www.mediawiki.org/wiki/Help:Redirects for more info.
>> Long story short: if you moved a page from the old wiki, visiting the same
>> wiki.blender.org URL that it used to be should at least take you right
>> back to the old location.
>>
>>
>> Dan
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Wiki pygments throwing exceptions

[Dan McGrath]

Hi,

Just a heads up that there was some progress made with GeSHi syntax
highlighting today for the wiki.

Originally we were using a system wide pygmentize, due to not having php
composer installed (or aware of what it did, even!). Now, I have switched
to the proper upstream pygmentize, ran the updates from it to pull down its
dependencies, and try use that.

At first it we still spitting out some broken pages, but these were clearly
just cached pages. I have since purged the memcached and all of the past
broken pages that I noticed appear to work now. So I guess try using proper
 syntax again on the wiki, but let me know if you run into
any broken pages so that we can ensure that the problem was related to the
system installed pygmentize without full dependencies, being the problem.


Dan

On Sun, Jun 17, 2018 at 10:48 AM Dan McGrath 
wrote:

> Hi,
>
> Just a heads up that I noticed that a small handful of pages were throwing
> MW exceptions on the wiki when using syntax highlighting. An example is:
>
>   https://wiki.blender.org/wiki/Tools/Git
>
> If you edit this page and change the very first  back to
> , it will throw an exception in the GeSHI syntax
> highlight extension, which uses pygmentize. I don't know much more than
> this, so if you see an MW exception when trying to view a page, I would
> suggest to try change some/all of the lang's from bash to sh for now.
>
> On a side note, I have noticed that there are no redirects for the now
> removed namespaces (eg: Dev:Doc) where some old pages used to reside, but
> have been moved. I believe the proper way to migrate such pages is to put
> it in the original place (Dev:Doc/Foobar) and then move it to the new
> location (/Foobar), so that a redirect is placed for people using the old
> URLs. See https://www.mediawiki.org/wiki/Help:Redirects for more info.
> Long story short: if you moved a page from the old wiki, visiting the same
> wiki.blender.org URL that it used to be should at least take you right
> back to the old location.
>
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Wiki pygments throwing exceptions

[Dan McGrath]

Hi,

Just a heads up that I noticed that a small handful of pages were throwing
MW exceptions on the wiki when using syntax highlighting. An example is:

  https://wiki.blender.org/wiki/Tools/Git

If you edit this page and change the very first  back to
, it will throw an exception in the GeSHI syntax
highlight extension, which uses pygmentize. I don't know much more than
this, so if you see an MW exception when trying to view a page, I would
suggest to try change some/all of the lang's from bash to sh for now.

On a side note, I have noticed that there are no redirects for the now
removed namespaces (eg: Dev:Doc) where some old pages used to reside, but
have been moved. I believe the proper way to migrate such pages is to put
it in the original place (Dev:Doc/Foobar) and then move it to the new
location (/Foobar), so that a redirect is placed for people using the old
URLs. See https://www.mediawiki.org/wiki/Help:Redirects for more info. Long
story short: if you moved a page from the old wiki, visiting the same
wiki.blender.org URL that it used to be should at least take you right back
to the old location.


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

Re: [Bf-committers] Wiki is now read only

[Dan McGrath]

Hi,

I am not sure if this was a question or a statement, but yes, the new wiki
has become an exclusive club of only authorised accounts, specifically
developers, and that people looking for access should speak to one of the
developers, such as Campbell. I personally avoid such a task as I am not up
on who is meant to be creating documents on the new wiki. That I leave to
the devs!


Dan

On Sat, Jun 16, 2018 at 9:52 AM Ton Roosendaal  wrote:

> Hi,
>
> Apparently the new wiki accounts were manually added - to prevent we add
> accounts of spammers.
> If your account needs to be added again, notify Campbell?
>
> Thanks,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> <https://maps.google.com/?q=Buikslotermeerplein+161,+1025+ET+Amsterdam,+the+Netherlands=gmail=g>
>
> > On 15 Jun 2018, at 17:22, Dan McGrath  wrote:
> >
> > Hi,
> >
> > It would seem that the new wiki is up and running in place of the old one
> > at https://wiki.blender.org/ with the old wiki still (temporarily left
> > running up at https://en.blender.org/
> >
> > I also placed some dumpBackup.php outputs at
> > https://download.blender.org/oldwiki/ for users to access, along with a
> > tarball dump of the uploads folder. This should, in theory, be all that
> is
> > needed to access the old content after the old wiki is remove in a few
> > weeks.
> >
> >
> > Dan
> >
> > On Fri, Jun 15, 2018 at 5:42 AM Dan McGrath 
> wrote:
> >
> >> Hi,
> >>
> >> Just a heads up that the old wiki is now read only. The plan is to swap
> >> en.b.o with wiki.b.o, so there will be a slight disruption as we are
> >> changing web servers (lighttpd -> apache), not just docroot locations in
> >> the configuration.
> >>
> >> So, relax, everything will be fine! <(o.O)>
> >>
> >>
> >> Dan
> >>
> > ___
> > 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Wiki is now read only

[Dan McGrath]

Hi Ray,

Please email the developer list for wiki changes. I am not sure why you are
personally mailing me about wiki edits. I have forwarded this to the
developer list in case you are unaware of the address!


Dan

On Sat, Jun 16, 2018, 12:38 AM Ray Molenkamp  wrote:

> [offlist reply]
>
> The Windows build instructions redirect to the mac build instructions
>
> and it doesn't look like my account made it to the new system so
>
> i can't fix it, so if you please would be so kind to fix the link that be
>
> great.
>
> Greetings,
>
> --Ray
>
>
> On 6/15/2018 9:22 AM, Dan McGrath wrote:
> > Hi,
> >
> > It would seem that the new wiki is up and running in place of the old one
> > at https://wiki.blender.org/ with the old wiki still (temporarily left
> > running up at https://en.blender.org/
> >
> > I also placed some dumpBackup.php outputs at
> > https://download.blender.org/oldwiki/ for users to access, along with a
> > tarball dump of the uploads folder. This should, in theory, be all that
> is
> > needed to access the old content after the old wiki is remove in a few
> > weeks.
> >
> >
> > Dan
> >
> > On Fri, Jun 15, 2018 at 5:42 AM Dan McGrath 
> wrote:
> >
> >> Hi,
> >>
> >> Just a heads up that the old wiki is now read only. The plan is to swap
> >> en.b.o with wiki.b.o, so there will be a slight disruption as we are
> >> changing web servers (lighttpd -> apache), not just docroot locations in
> >> the configuration.
> >>
> >> So, relax, everything will be fine! <(o.O)>
> >>
> >>
> >> Dan
> >>
> > ___
> > 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] Wiki is now read only

[Dan McGrath]

Hi,

It would seem that the new wiki is up and running in place of the old one
at https://wiki.blender.org/ with the old wiki still (temporarily left
running up at https://en.blender.org/

I also placed some dumpBackup.php outputs at
https://download.blender.org/oldwiki/ for users to access, along with a
tarball dump of the uploads folder. This should, in theory, be all that is
needed to access the old content after the old wiki is remove in a few
weeks.


Dan

On Fri, Jun 15, 2018 at 5:42 AM Dan McGrath  wrote:

> Hi,
>
> Just a heads up that the old wiki is now read only. The plan is to swap
> en.b.o with wiki.b.o, so there will be a slight disruption as we are
> changing web servers (lighttpd -> apache), not just docroot locations in
> the configuration.
>
> So, relax, everything will be fine! <(o.O)>
>
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Wiki is now read only

[Dan McGrath]

Hi,

Just a heads up that the old wiki is now read only. The plan is to swap
en.b.o with wiki.b.o, so there will be a slight disruption as we are
changing web servers (lighttpd -> apache), not just docroot locations in
the configuration.

So, relax, everything will be fine! <(o.O)>


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

Re: [Bf-committers] Plaintext password in membership reminder

[Dan McGrath]

Hi Torsten,

I am aware of your concern. Unfortunately, I did not write Mailman :(
AFAIK, there are only 3rd party addon's to do such things, but I believe
that the situation comes down to it being a known issue, with the
recommendation being for you to not use important passwords for the
service, and also to disable the feature that mails you a password back, in
case someone else can read your email (we do use SSL transport during
delivery, and require HTTPS for the website).

Please refer to these urls:

https://mail.python.org/pipermail/mailman-users/2010-July/069843.html
http://www.list.org/mailman-member/node15.html
http://www.list.org/mailman-member/node18.html

At some point, Mailman 3 will do away with these, but as of yet I don't
believe it is stable. This software is about as old as the internet, and
unfortunately, it does assume a little too much for the user. To be fair
though, you are warned very clearly about this during the creation of the
account:

  http://pasteall.org/pic/show.php?id=a310d07569563858a1483c7b4a96430c

Gotta love old legacy systems. Also, gotta love volunteering to maintain
legacy systems. If you would like to sponsor a few thousand dollars to me
to upgrade to mailman 3, perhaps I could put a rush on things, otherwise,
sorry!


Cheers,

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

Re: [Bf-committers] Plaintext password in membership reminder

[Dan McGrath]

Hi,

This will simply stop you from receiving the plain text password. As I have
mentioned several times in private mails, the version of Mailman that we
use is not capable of hashing passwords (at least out of the box, iirc).
The upcoming version 3 was an overhaul which should address this problem.
That said, it is clearly stated when you subscribe to the list that you
should not use an important password as it will be mailed back to you etc.

My advice is to generate a simple unique password, and set your mail
preferences to not email them back to you, as well as to change your
password if this all comes as a surprise to you. Also, to sign your emails
with GPG/GNUPG if you require accountability and are concerned that someone
sniffed your password from your email. But we do sent and receive mail via
TLS, when possible, so the odds of the mail being intercepted and sniffed
are relatively low.

I hope this helps! I believe that mailman 3 is finally in the ports tree,
but when we will actually use it, who knows.


Cheers,

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

Re: [Bf-committers] Slow disk IO on some coder services

[Dan McGrath]

Hey,

The download.blender.org backup (hundreds of gigs for a full backup) was
running the ZFS pool into the ground, and had several fulls around taking
up a TB of space. Cleaned up things a bit and should at least allow the
system to be usable again. Sorry about that! As you were.

Dan

On Mon, Jun 4, 2018 at 2:04 AM Dan McGrath  wrote:

> Hey,
>
> Just a heads up that Koro's HDD's are taking a beating from the full
> backup. As a result, git, svn, buildbot and phabricator are extremely slow.
> As well, I am in the process of restarting the mysql for Phabricator to
> help free some resources, so this is entirely offline for a bit. Still,
> expect svn and git to be slow for a while yet. Thankfully, this is only a
> monthly, so I would rather let it pass and reconfigure things later.
>
> Apologies!
>
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Slow disk IO on some coder services

[Dan McGrath]

Hey,

Just a heads up that Koro's HDD's are taking a beating from the full
backup. As a result, git, svn, buildbot and phabricator are extremely slow.
As well, I am in the process of restarting the mysql for Phabricator to
help free some resources, so this is entirely offline for a bit. Still,
expect svn and git to be slow for a while yet. Thankfully, this is only a
monthly, so I would rather let it pass and reconfigure things later.

Apologies!


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

Re: [Bf-committers] Plaintext password in membership reminder

[Dan McGrath]

Hi Thomas,

To disable this, as it is a per user configuration choice, log into your
account and turn off password reminders. You can set this globally for all
lists, or on a per list basis.


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

Re: [Bf-committers] Blender 2.79b Release AHOY

[Dan McGrath]

>the ftp server seems determined to keep deleting my md5.txt file (someone
please look at this?)
>
>but here they are just to be safe
>
>4365E022748E5FBC694D0C2981446EE6  blender-2.79b-windows32.msi
>7518551D8D82D39D087DD6A5FDC4F9FF  blender-2.79b-windows32.zip
>C496DAF71511246BC84A97A94939C15D  blender-2.79b-windows64.msi
>FB904EE151E1B9C4D942E96B3259CD5C  blender-2.79b-windows64.zip
>
>--Ray

Sorry about that Ray. It's just an historical oddity with the FTP that, to
prevent abuse, it periodically blows away files so that our server isn't
used for porn/mp3/etc. Worst case, arrangements can be made for more a user
account with access to your own FTP directory, where this does not happen.


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

Re: [Bf-committers] Probe Message Privacy Issue

[Dan McGrath]

= (Dalai) =

> > For bf-committers, that option is off btw.
> Yup, but even for bf-cycles this option is on.
>
> So let's just close them all and move on?

Sounds good to me. I will take a look at this on the weekend or perhaps
later tonight.

> I also got the "probe" email by the way. But again, if it exposes only the
> email of list members that have posted (or tried to post) something, it is
> ok-ish.
>
> Cheers,
> Dalai

I believe those are the VERP probes that you were referring to. There are a
spammer that manually subscribed himself to the list to send a spam
yesterday from an @yahoo.com email address, and as a result, triggered
that. I've since removed and blocked him from our lists. (Don't these guys
have anything else better to do with their lives than waste mine/ours?)

= (Ton) =

> I don't know what you mean with this. How?
> No list should expose its subscribers to everyone, and I never configured
this in the past to allow that.

It's very likely that it is the default than, to allow people to see the
list members. Since each list has it's own unique options, it could be non
uniformly set across our lists. In all honesty, Dalai brings up a good
point in that it is ok'ish; the reason is simple: it's a public list, and
bots could just as easily compile a list of members by scraping the list
archives in minutes. IIRC, you have to subscribe to the list in order to
see it (by default?), so a bot already has to jump through a bunch of hops.
It's probably just easier to scrap the archive.

I suspect that this whole issue of having the members visible is just being
overblown, honestly, but true that someone who wants to watch "in secret"
and not post, would be exposed in such a query.

> For bf-committers, that option is off btw.
>
> What we DO expose is the mail address of someone who mails to this this
list,
> That's something I really prefer to keep.
>
> -Ton-


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

Re: [Bf-committers] Probe Message Privacy Issue

[Dan McGrath]

>Gotta love mailman :)

I know, right! It's such a horribly old system. I just had to answer
someone about it mailing back clear text passwords, because mailman ;p

> Mailing list subscribers are already exposed on the list member page on
> lists.blender.org. I am unsure if they page is protected by a script, but
> they are available to anyone to see in a browser.

I have no idea who originally configured our mailing lists, and each list
could have potentially been configured by a different person.  Keep in mind
that these lists go back over a decade in some cases.  In general, it was
likely configured either by Marco Walraven (former admin I took over from),
Nathan Letwory (former admin), or even Ton (Ton is Ton!) himself.  Whomever
it was, didn't close off the subscribers list to the public, but for
unknown reasons.

There may have been reasons that the members list was opened that are since
lost to the archives of time. Personally, I think it should be closed to
anyone other than staff (admins/moderators), but Ton, in general, tends to
like things to be open and free and less policed etc., so perhaps he wants
it to be this way? Who would I be to reverse such a decision! If it's okay
with Ton, I think it wouldn't be a big deal to go through and disable this
feature for all of our lists (honestly, it is a horrible privacy concern,
IMHO).



Yours,

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

Re: [Bf-committers] Server maintenance

[Dan McGrath]

Aaron,

I upgraded to the requirements:

#> pip freeze
alabaster==0.7.10
appdirs==1.4.3
Babel==2.5.3
certifi==2018.1.18
chardet==3.0.4
click==6.7
docutils==0.14
idna==2.6
imagesize==1.0.0
Jinja2==2.10
MarkupSafe==1.0
packaging==16.8
Pygments==2.2.0
pyparsing==2.2.0
pytz==2018.3
requests==2.18.4
six==1.11.0
snowballstemmer==1.2.1
Sphinx==1.7.0
sphinx-intl==0.9.10
sphinx-rtd-theme==0.2.5b2
sphinxcontrib-websupport==1.0.1
typing==3.6.4
urllib3==1.22


Cheers,

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

Re: [Bf-committers] Server maintenance

[Dan McGrath]

Okie, should all be done now. Sorry for the hassle!

Dan

On Tue, Feb 20, 2018 at 6:51 AM Dan McGrath <danmcgrath...@gmail.com> wrote:

> Hi,
>
> Just a heads up that git, svn, phabricator and buildbot will be going down
> for a quick upgrade in the next minutes. Hoping that things don't go more
> than an hour.
>
> Dan
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Server maintenance

[Dan McGrath]

Hi,

Just a heads up that git, svn, phabricator and buildbot will be going down
for a quick upgrade in the next minutes. Hoping that things don't go more
than an hour.

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

Re: [Bf-committers] Adding 360 Video Tools to VSE

[Dan McGrath]

I created your Wiki account. Hopefully you should have received an email
with the info.

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

Re: [Bf-committers] Discourse forum testers needed

[Dan McGrath]

Hi Sybren,

I was wondering about that stuff, but figure we need to arrange some
credentials to authorise the actual requests on our end first. Sounds like
fun! I did skim the page, and it does indeed look like were going to need
to code up an endpoint. See you on discourse, I guess.


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

[Bf-committers] Discourse forum testers needed

[Dan McGrath]

Hey,

I opened up a beta of the discourse forum to the public at
https://devtalk.blender.org/ for people to poke around in. I don't know
this will be the final install, or even the domain name that we stick with,
but hop on and take a peek I guess.


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

Re: [Bf-committers] Changes to Windows Compiler Support.

[Dan McGrath]

Hi,

> 6) 32 bit support
>
> I spend a fair amount of time building the blender deps in various
formats, x86
> it starting to cost more and more time since a few of the projects just
seem
> to test on linux, sometimes on windows/x64 but rarely on x86 leading to
all kinds
> of obscure (usually sse) related build errors. This is starting to take
up a
> significant amount of my time for only a small percentage of end users
(last
> time I asked ~15% of the blender downloads were for 32 bit users) and by
the
> time we release 2.8 this number will probably have dropped even further.

Out of curiosity, I parsed all of our download.blender.org logs since near
the end of 2014, right up until today and stored them in an sqlite3
database for people to check. You can download the file at:

  https://download.blender.org/ftp/dan/admin/blender_logs.sqlite.bz2

I specifically limited the list to 200 status files and only valid
filenames. The schema is:

sqlite> .schema
CREATE TABLE logs (log_date date NOT NULL, url text NOT NULL, filename text
NOT NULL, blender_version varchar(10) NULL, bits integer);
CREATE INDEX idx_bits on logs(bits);
CREATE INDEX idx_filename on logs(filename);
CREATE INDEX idx_url on logs(url);
sqlite> select * from logs limit 3;
26/Mar/2014|/release/Blender2.49b/blender-2.49b-windows.exe|blender-2.49b-windows.exe|2.49b|0
26/Mar/2014|/release/Blender2.70/blender-2.70-OSX_10.6-x86_64.zip|blender-2.70-OSX_10.6-x86_64.zip|2.70|64
26/Mar/2014|/release/Blender2.69/blender-2.69-windows32.exe|blender-2.69-windows32.exe|2.69|32
sqlite> select count(*) from logs;
304113
sqlite> select count(*) from logs where bits = 32;
101756
sqlite> select count(*) from logs where bits = 64;
175647

(bits = 0 is for unknown bit size)

Anyway, for those who were maybe interested, have fun!


Cheers,

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

Re: [Bf-committers] Changes to list digest options

[Dan McGrath]

Hi,

I am sorry that I didn't get back to you sooner, but I didn't notice your
reply in the list until now INTERLICHTSPIELHAUS. There was an unfortunate
second problem that stopped mail from being digested (burp :). Seems that
not only were all of the original lists configured to only send digests
monthly, but when I migrated the lists to newer software, I disabled the
cron service and forgot to enable it. The service has been enabled for
about a week now, and I have been receiving daily digests just fine. I
assume that you are too now? Let me know otherwise, thanks!


Cheers,

Dan

> Hi,
>
>
> I still haven't received a digest since you sent this mail.
>
>
> Dan McGrath wrote:
>
>
> > Hi,
> >
> > It seems that a user noticed that digests were defaulted to monthly and
> > poked us. As a result, I went through and changed the digest mails to be
> > daily now, and standardised the lists to a size of 1MB for
> > the digest_size_threshhold, which should cause the list to send out a
> > digest early at this size and avoid sending too large of a digest that
> > could potentially be blocked by some mail providers.
> >
> >
> > Cheers,
> >
> > Danny McGrath
> >
> >
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Changes to list digest options

[Dan McGrath]

Hi,

It seems that a user noticed that digests were defaulted to monthly and
poked us. As a result, I went through and changed the digest mails to be
daily now, and standardised the lists to a size of 1MB for
the digest_size_threshhold, which should cause the list to send out a
digest early at this size and avoid sending too large of a digest that
could potentially be blocked by some mail providers.


Cheers,

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

Re: [Bf-committers] Blender accepted for GSoC 2017!

[Dan McGrath]

Cool, congratulations! Had an awesome day today, now this great news! :p


Dan

On Mon, Feb 27, 2017, 1:41 PM Ton Roosendaal  wrote:

> Hi all,
>
> We're in! Here is the list of accepted orgs this year:
> https://summerofcode.withgoogle.com/organizations/
>
> In three weeks students will start sending in applications.
> Blender developers who want to become mentor can contact me, Sergey
> Sharybin or Bastien Montagne.
>
> Will keep you informed,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>
>
> ___
> 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] Blender 101 / workflow project

[Dan McGrath]

Heya!

Welcome back man, long time! o/


Dan

On Thu, Feb 23, 2017 at 10:15 AM Jonathan Williamson 
wrote:

> Welcome back Campbell!
>
> --
> Jonathan Williamson
>
> On February 23, 2017 at 8:58:17 AM, Thomas Beck (
> softw...@plasmasolutions.de(mailto:softw...@plasmasolutions.de)) wrote:
>
> >
> > Hey Campbell,
> >
> > Welcome back, great to have you on board again!
> >
> > Cheers, Thomas
> >
> > On Thu, Feb 23, 2017, 15:32 Julian Eisel  wrote:
> >
> > > Hey!
> > >
> > > This is great! Looking forward to have you on board for new adventures
> ;)
> > >
> > > Cheers,
> > > - Julian -
> > >
> > > On 23 February 2017 at 15:04, Bastien Montagne 
> > > wrote:
> > > > Hey Campbell,
> > > >
> > > > That’s great news, welcome back! Will be much happy to work with you
> > > > again. :)
> > > >
> > > > Cheers,
> > > > Bastien
> > > >
> > > >
> > > > Le 23/02/2017 à 14:59, Campbell Barton a écrit :
> > > > > Hi, after a 7 months away I'm happy to announce I'll be working for
> > > > > the Blender-Foundation again!
> > > > > It's work from home, on a per-project basis.
> > > > >
> > > > > I'll be focusing on the Blender-101 and work-flow improvements
> starting
> > > March.
> > > > > Also some time on code-review and fixing bugs in UI/workflow
> related
> > > > > areas so as not to put too much pressure on existing maintainers.
> > > > >
> > > > > Noticed new developers getting involved and 2.8x progress is great
> to
> > > see :)
> > > > >
> > > > > Regards,
> > > > > - Campbell
> > > > > ___
> > > > > 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
> > > ___
> > > 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
> ___
> 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

[Bf-committers] Replacing server for git/svn/phab/builder

[Dan McGrath]

Hi,

Just another heads up that we will have yet more downtime today to replace
the server that runs git/svn/phabricator/buildbot. Yesterday when we tried
to reset the DRAC that went unresponsive, we found it never came back and
appears DOA. We also have concerns about an unusually high RPM fan in the
PSU. As a precaution, we are just going to replace the machine with an
identical one. In theory, it should be as quick as replacing the drives,
but of course life never is easy ;)

Probably somewhere in the hour'ish range, give or take? We will also be
continuing the rewire, so other services will see brief disruptions while
Sergey chips away at it.


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

[Bf-committers] Blender.org outages today

[Dan McGrath]

Hey,

Just a heads up that Sergey is at the datacenter today doing some rewiring.
We also need to power down one of the servers to drain its power and reset
the drac which will be happening by the time you get this. This will affect
git, svn, phabricator and buildbot.


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

[Bf-committers] Phabricator workers temporarily stopped

[Dan McGrath]

Hey,

Just a heads that that the Phabricator daemons (PHD) that are responsible
for polling the repositories will be disabled for a few hours tonight to
help look into an issue with MySQL sucking up swap faster than a black hole
orbiting the server :) This shouldn't do much other than delay updates in
the website.


Cheers,

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

Re: [Bf-committers] Stepping away from Blender development

[Dan McGrath]

Hi,

The honour was all ours! Well I hope you have a good one, you will be
missed. Take care bud! o7


Cheers


Dan

On Mon, Aug 1, 2016 at 8:51 AM Campbell Barton  wrote:

> Hi, writing this mail to say that I'll be taking time away from
> Blender development,
> I'm stepping down as maintainer/module owner.
>
> I'll be taking an extended period of time off, to work on my own
> projects for a while, explore new horizons!
>
> It's been an honour to work on the open projects with talented artists
> & developers.
> All the best,
>
> --
> - Campbell
> ___
> 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] Meeting in about 3 hours

[Dan McGrath]

Hi,

While I am not someone that has any direct involvement in the meetings, I
thought I would chime in on a few things.

For one, I agree that the old approach was better when it was always just 1
day (Sunday), than this new setup where it's some random day and time. In
fact, I don't think I've bothered to catch a single meeting since the
change (again, not exactly a big deal as I am not a dev), if only because
you have to pay attention to the day and not the day of the week.

I do wonder though if Sunday was the best day to be doing the meetings in
the first place? The way I see it, Ton has been doing this stuff for a very
long time, and has basically given up his Sunday for over a decade now. I
do recall him being rather happy to finally get a Sunday off and not have
to be on IRC or at the office, etc. To go back to Sunday now seems like it
would be taking Sunday back from him. Maybe it's fine to him and everyone
else though, but just to put it out there, have you considered the
possibility of a different day, like a Monday, instead? Or perhaps a
Saturday? Friday I assume isn't ideal since some like to go out and party a
bit, and Saturday may not be ideal because, well, hangovers and long Friday
nights :)

Anyway, just putting it out there in case Sunday isn't great for people,
and deep down, maybe nobody else wants to bring up that they may not
actually want Sundays to be partial work days.

Cheers o/


Dan

On Sun, Jul 10, 2016 at 12:02 PM Thomas Beck 
wrote:

> I would love to go back to the old schedule as well. Could not attend one
> single meeting from the new schedule. And I agree with Bastien: earlier
> would be no problem, later would be 7pm the latest for me.
>
> Greetings, Thomas
>
> Bastien Montagne  schrieb am So., 10. Juli 2016
> 17:40:
>
> > Would also vote to go back to sunday meetings, for same reasons as
> > already exposed in previous mails. Not sure about a 4hours shift, but
> > may 2hours sooner (14h Amsterdam time) would work? A bit early for LA
> > guys though. :/
> >
> >
> > Le 10/07/2016 à 08:26, Campbell Barton a écrit :
> > > While well intended, agree its not working out.
> > > Though ~4hrs before or after the regular Sunday meeting time would be
> > > much more convenient for me personally (around ~midday or ~8pm NL
> > > time).
> > >
> > > On Sun, Jul 10, 2016 at 1:52 AM, Jonathan Williamson
> > >  wrote:
> > >> I tend to agree. I really like the 10th meeting each month, simply
> > because it’s easier for me, but I have a hard time keeping track of the
> > other meetings. I will also echo the concern Ton brought up, which is
> that
> > each meeting seems a bit more silo’d and so there’s less cohesion.
> > >>
> > >> It was a nice experiment, though :)
> > >>
> > >> --
> > >> Jonathan Williamson
> > >>
> > >> On July 9, 2016 at 10:50:47 AM, Thomas Dinges (blen...@dingto.org)
> > wrote:
> > >>
> > >> I agree, back to Sunday. I forgot to attend most meetings in the new
> > >> schedule, the Sunday thing was easy to remember and schedule.
> > >>
> > >> Thomas
> > >>
> > >> Am 09.07.2016 um 17:42 schrieb Martijn Berger:
> > >>> Hi,
> > >>>
> > >>> I could not agree more. Sunday afternoon is not ideal but to me this
> > new
> > >>> and improved thing is almost impossible.
> > >>>
> > >>>
> > >>> On Sat, Jul 9, 2016 at 5:37 PM, Sergey Sharybin <
> sergey@gmail.com>
> > >>> wrote:
> > >>>
> >  Hi,
> > 
> >  Personally i think Sundays were working much better -- more
> > predictable
> >  schedule, more predicable who's attending those meetings.
> > 
> >  Only unfortunate is that it is hassle for Campbell since 16:00 in
> > A-dam is
> >  like 2:00 in the night. We might try finding better time during
> Sunday
> >  perhaps?
> > 
> >  On Sat, Jul 9, 2016 at 3:49 PM, Ton Roosendaal 
> > wrote:
> > 
> > > Hi all,
> > >
> > > The thrice-monthly cycle starts again with a LA 10 AM meeting.
> > > For your time, check https://blendercoders.xyz/
> > >
> > > I would like to review this schedule. And either confirm it, or
> > decide on
> > > another scheme this month.
> > >
> > > There is mixed experiences with the new meeting cycle. Several
> > meetings
> > > even never happened. I miss the continuity, each meeting now is
> like
> > an
> > > independent gathering of people - making the decision procedure
> > fuzzy and
> > > not facilitating progress much.
> > >
> > > The meetings were also split to reach out to people in American and
> > Asian
> > > timezones. I've only seen minimal results of that.
> > >
> > > In my opinion the old (Sunday 16h) schedule functioned much better.
> > Even
> > > though it's not a nice time for the Americas or Asia, at least you
> > always
> > > knew that there was a weekly review of topics, a weekly check on
> > progress
> > > and planning, a 

[Bf-committers] Short downtime for code related services

[Dan McGrath]

Hi,

Just a heads up that shortly git, svn, buildbot and phabricator will be
going down for a quick update and reboot. Things shouldn't be down more
than about 10 minutes. Sorry for the inconvenience!

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

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

[Dan McGrath]

Sergey,

Thanks :)

No doubt though. But it sounded like some of the concerns in the thread(s)
were people mistakenly thinking that we were going to completely get rid of
the wiki altogether or something similar. Either way I am sure a clean wiki
install should be done soon so we can at least get it usable again (and get
rid of that /index.php/ url part).

Dan

On Sun, Feb 28, 2016 at 6:16 AM Sergey Sharybin 
wrote:

> Dan,
>
> Well, it's definitely faster than my laptop. So screw it, gonna to sell my
> laptop on ebay and buy two r210 for the same amount of money. One i'll
> donate to you ;)
>
> Back to serious tho.
>
> Think we were not talking about putting manual back in there. That would
> piss some contributors off even more. Dont' want that to happen. We've been
> mainly talking about preventing further split of documentation any further.
> So current manual will stay as it is now, but rest of docs will stay in
> wiki.
>
> With a new wiki installed we can simply do the same as we did with manual:
> instead of 1-to-1 data migration only migrate needed paged, fix links on
> them and so on. Surely it's some work to be done, but that's still simpler
> than fixing pages AND moving them to another system AND setting up another
> system.
>
>
> On Sun, Feb 28, 2016 at 3:00 AM, Trouble Daemon 
> wrote:
>
> > 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 <
> sergey@gmail.com>
> > > 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
> >
>
>
>
> --
>