Avogadro 1.0.1 tagging - Tuesday April 27

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to go in
before I tag - I just fixed a few issues and as far as I can see everything
looks good. Remember that this is bug fix only (ideally), and I would rather be
given commits to merge so that I can check them over.

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few fixes in
1.0.1 that fix a few bugs. This has been many years in the making, and it is a
very positive move to see Kalzium move away from a snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus

25.04.10, 15:24, “Marcus D. Hanwell” marcus@cryos.org:

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to go in
before I tag - I just fixed a few issues and as far as I can see everything
looks good. Remember that this is bug fix only (ideally), and I would rather be
given commits to merge so that I can check them over.

I think avopkg improvements from my git could be merged:

3cd1f6775342ba6a3ec94ba06b5cf8d83876ade1
771c4e80ef928ac34dd3a9eaa79b5887315969a6
23af0f5001d8e3d21b241fe5fac335757c7d299f
e1f910790f98ae0a87ae2cf11dafcc562cd43780
d6da4e1d48cadbba6272ac3feca60e0f43ad2256
1ca8cc6e37cad3738afb40e99424dc1b8049b0d8
dd15c0fbc80180e4f2ceefab5c8c9197a287ced7
8be117e080bef2e0faf1574d3da41a630acceee8
5a8c7c7337bd57f36726ef7f6e75e38f3a2b924c
c954424652e090f5fd08aa0f8344904224ef0f3a
e27f58d946c82b8e526a73ccab0811958ea981a1

(however, it’s getting complex and probably needs some testing)

Also,
33dc7364620ca191129716c9c24538bf773ba971
d5a2c808a65942f240aad1abf2db250d46fd2852
(network fetch)

Maybe, additional flags for Intel compiler could be merged
ce2152f7033a4d88dcecc78b35c34dd08e8dd45e
0da67845cc674f900b25e82409e7e5506e5803a0
95efd45adfefea2014082d011f6bb14d5cf92dbe
a91c36a7d424250716818ecea4ceb57a191fed18
50466402a0affb90acf6b93df4d3344775eb7b1d

Also
22dba694cc158152e573f5d5865f9934a6528976

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few fixes in
1.0.1 that fix a few bugs. This has been many years in the making, and it is a
very positive move to see Kalzium move away from a snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus



Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options


Regards,
Konstantin

Also, I’ll try to finalize binary Linux build with GUI installer (but, of course, it could be released later)


Regards,
Konstantin

On Sunday 25 April 2010 15:57:39 Konstantin Tokarev wrote:

25.04.10, 15:24, “Marcus D. Hanwell” marcus@cryos.org:

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to
go in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally),
and I would rather be given commits to merge so that I can check them
over.

I think avopkg improvements from my git could be merged:

3cd1f6775342ba6a3ec94ba06b5cf8d83876ade1
771c4e80ef928ac34dd3a9eaa79b5887315969a6
23af0f5001d8e3d21b241fe5fac335757c7d299f
e1f910790f98ae0a87ae2cf11dafcc562cd43780
d6da4e1d48cadbba6272ac3feca60e0f43ad2256
1ca8cc6e37cad3738afb40e99424dc1b8049b0d8
dd15c0fbc80180e4f2ceefab5c8c9197a287ced7
8be117e080bef2e0faf1574d3da41a630acceee8
5a8c7c7337bd57f36726ef7f6e75e38f3a2b924c
c954424652e090f5fd08aa0f8344904224ef0f3a
e27f58d946c82b8e526a73ccab0811958ea981a1

There are some issues with several of these patches where the commits are
large, commit messages do not always describe whether these are new features,
bug fixes, trailing whitespace added, etc. Also, they have email addresses such
as “kostya@localhost.localdomain”, which I doubt are correct. I don’t want to
be overly prescriptive, but do want to keep the quality of our history as good
as possible.

I would love to see contributors develop in feature branches, and merge from
feature branches some day. Not sure if this might raise the barrier to entry a
little too high, but our git workflow has been a little lax at times.

(however, it’s getting complex and probably needs some testing)

How well tested is it? How much feedback have you had from users? I have not
had time to really look into it as yet, but looking at the man page am not
sure what I am supposed to do with it. Is it intended for end users,
developers, both? Typing avopkg it seems to try to do stuff and fail here,
shouldn’t it check its input first?

marcus@cryos:~/src/avogadro master$ avopkg
Avopkg v1.0
Unpacking …
tar (child): …/: Cannot read: Is a directory
tar (child): At beginning of tape, quitting now
tar (child): Error is not recoverable: exiting now

gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error is not recoverable: exiting now
is not an Avogadro plugin package!
Installation failed.

Also,
33dc7364620ca191129716c9c24538bf773ba971
d5a2c808a65942f240aad1abf2db250d46fd2852
(network fetch)

So these went from SDF, to smiles, to 3D SDF (getting rid of the smiles
again)? If there are high quality 3D structures available it certainly makes
sense to use them. I know the SDFs sometimes needed optimization before they
were useful, and was meaning to take a look at this.

Maybe, additional flags for Intel compiler could be merged
ce2152f7033a4d88dcecc78b35c34dd08e8dd45e
0da67845cc674f900b25e82409e7e5506e5803a0
95efd45adfefea2014082d011f6bb14d5cf92dbe
a91c36a7d424250716818ecea4ceb57a191fed18
50466402a0affb90acf6b93df4d3344775eb7b1d

I don’t use that compiler, but they all look nicely isolated to the Intel
compiler, and so safe to merge.

Also
22dba694cc158152e573f5d5865f9934a6528976

Looks good. Thanks for all the patches and hard work, I will cherry-pick once
I have done a little more testing. Once 1.0.1 is out it would be nice to figure
out a timeline for the first 1.1.z release (which will depend on OB). I have
also been doing a lot of work with the new external project support in CMake
2.8, it is probably a better route than the super project approach to
build/package Avogadro with all of its dependencies. There are even recipes
for building Qt and Python.

Thanks,

Marcus

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few
fixes in 1.0.1 that fix a few bugs. This has been many years in the
making, and it is a very positive move to see Kalzium move away from a
snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus

So these went from SDF, to smiles, to 3D SDF (getting rid of the smiles
again)? If there are high quality 3D structures available it certainly makes
sense to use them. I know the SDFs sometimes needed optimization before they
were useful, and was meaning to take a look at this.

I thought about this again – I made the suggestion to try the 3D SDF. We should fall back to SMILES or 2D SDF if the 3D SDF fails. IIRC, the 3D coordinates are not available for the entire PubChem yet.

Cheers,
-Geoff

25.04.10, 16:39, “Marcus D. Hanwell” marcus@cryos.org:

On Sunday 25 April 2010 15:57:39 Konstantin Tokarev wrote:

25.04.10, 15:24, “Marcus D. Hanwell” :

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to
go in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally),
and I would rather be given commits to merge so that I can check them
over.

I think avopkg improvements from my git could be merged:

3cd1f6775342ba6a3ec94ba06b5cf8d83876ade1
771c4e80ef928ac34dd3a9eaa79b5887315969a6
23af0f5001d8e3d21b241fe5fac335757c7d299f
e1f910790f98ae0a87ae2cf11dafcc562cd43780
d6da4e1d48cadbba6272ac3feca60e0f43ad2256
1ca8cc6e37cad3738afb40e99424dc1b8049b0d8
dd15c0fbc80180e4f2ceefab5c8c9197a287ced7
8be117e080bef2e0faf1574d3da41a630acceee8
5a8c7c7337bd57f36726ef7f6e75e38f3a2b924c
c954424652e090f5fd08aa0f8344904224ef0f3a
e27f58d946c82b8e526a73ccab0811958ea981a1

There are some issues with several of these patches where the commits are
large, commit messages do not always describe whether these are new features,
bug fixes, trailing whitespace added, etc. Also, they have email addresses such
as “kostya@localhost.localdomain”, which I doubt are correct. I don’t want to
be overly prescriptive, but do want to keep the quality of our history as good
as possible.

I would love to see contributors develop in feature branches, and merge from
feature branches some day. Not sure if this might raise the barrier to entry a
little too high, but our git workflow has been a little lax at times.

(however, it’s getting complex and probably needs some testing)

How well tested is it? How much feedback have you had from users?

Currently no. But I didn’t release any packages yet, and AFAIK nobody does

I have not
had time to really look into it as yet, but looking at the man page am not
sure what I am supposed to do with it. Is it intended for end users,
developers, both?

Both. It can create, install and remove packages.

Typing avopkg it seems to try to do stuff and fail here,
shouldn’t it check its input first?

It checks. Maybe, I didn’t list all patches - you can copy avopkg.in from my git and see diff

marcus@cryos:~/src/avogadro master$ avopkg
Avopkg v1.0
Unpacking …
tar (child): …/: Cannot read: Is a directory
tar (child): At beginning of tape, quitting now
tar (child): Error is not recoverable: exiting now

Something goes wrong… It works for me (at least with bash and dash as /bin/sh). Tested on Ubuntu, Debian and CentOS, can’t reproduce
Note: avopkg should be run in writable directory

gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error is not recoverable: exiting now
is not an Avogadro plugin package!
Installation failed.

Also,
33dc7364620ca191129716c9c24538bf773ba971
d5a2c808a65942f240aad1abf2db250d46fd2852
(network fetch)

So these went from SDF, to smiles, to 3D SDF (getting rid of the smiles
again)? If there are high quality 3D structures available it certainly makes
sense to use them. I know the SDFs sometimes needed optimization before they
were useful, and was meaning to take a look at this.

Maybe, additional flags for Intel compiler could be merged
ce2152f7033a4d88dcecc78b35c34dd08e8dd45e
0da67845cc674f900b25e82409e7e5506e5803a0
95efd45adfefea2014082d011f6bb14d5cf92dbe
a91c36a7d424250716818ecea4ceb57a191fed18
50466402a0affb90acf6b93df4d3344775eb7b1d

I don’t use that compiler, but they all look nicely isolated to the Intel
compiler, and so safe to merge.

Also
22dba694cc158152e573f5d5865f9934a6528976

Looks good. Thanks for all the patches and hard work, I will cherry-pick once
I have done a little more testing. Once 1.0.1 is out it would be nice to figure
out a timeline for the first 1.1.z release (which will depend on OB). I have
also been doing a lot of work with the new external project support in CMake
2.8, it is probably a better route than the super project approach to
build/package Avogadro with all of its dependencies. There are even recipes
for building Qt and Python.

Cool! Unfortunately, I’ve already build it all by hands, and even have some scripts :slight_smile:

Thanks,

Marcus

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few
fixes in 1.0.1 that fix a few bugs. This has been many years in the
making, and it is a very positive move to see Kalzium move away from a
snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

I would love to see contributors develop in feature branches, and merge from
feature branches some day. Not sure if this might raise the barrier to entry a
little too high, but our git workflow has been a little lax at times.

Sorry, I’m not a Git wizard, and used to work ‘SVN way’. Also, avopkg is actually one file (+ some hacks in cmake, but they don’t depend on it’s implementation)

(however, it’s getting complex and probably needs some testing)

How well tested is it? How much feedback have you had from users? I have not
had time to really look into it as yet, but looking at the man page am not
sure what I am supposed to do with it.

http://avogadro.openmolecules.net/wiki/Avopkg


Regards,
Konstantin

Anyway, you can keep avopkg version which is already in 1.0 - it also can pack and install packages (but doesn’t track installed files/packages)


Regards,
Konstantin

I don’t use that compiler, but they all look nicely isolated to the Intel
compiler, and so safe to merge.

It generates more sensible and understandable warnings and errors, and optimizes better


Regards,
Konstantin

On Sunday 25 April 2010 15:24:06 Marcus D. Hanwell wrote:

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to go
in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally), and I
would rather be given commits to merge so that I can check them over.

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few fixes
in 1.0.1 that fix a few bugs. This has been many years in the making, and
it is a very positive move to see Kalzium move away from a snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus

Consider it tagged, I was fairly conservative in what I pulled in but I think
it fixes quite a few bugs. I will try to ensure I make more time for regular
releases, and have already pushed the tag. If no one spots issues I will make
and upload tarballs this evening, and then push out some announcements.

Thanks,

Marcus

Please look through
70d6399878a9042bdf064fabed786fa4e063c319
2e518ea20863ad0eeddcc83a3323d2f7b7fadb70
675b3dcb9ddd3d43b169ce14e9b40975c169b07f
68f2e479c3fb5e11b149c766553b7abb16e3f680
474613065b79d03fc849b8366dce1dab9a168f8f
e72d3fd478669dfbb2ad727074bd05b40be0992f
da07a140d7c6c5bcc8b7db17291db208f175702d
36ed35c69ad991154fbd150b57f372bd0730cdf6
ad4b59a36f29d6f7ea4208b0201ed0d01d86c017
50466402a0affb90acf6b93df4d3344775eb7b1d
ef77cbf1c571877798eaacd62b5905ee7acaf02d
e24d68e8c7a78008777c12a682812a6198a9119e

Maybe also 38178e8a8a79d24d1f3345009216e6a8500e67f6

28.04.10, 13:12, “Marcus D. Hanwell” marcus@cryos.org:

On Sunday 25 April 2010 15:24:06 Marcus D. Hanwell wrote:

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to go
in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally), and I
would rather be given commits to merge so that I can check them over.

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few fixes
in 1.0.1 that fix a few bugs. This has been many years in the making, and
it is a very positive move to see Kalzium move away from a snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus

Consider it tagged, I was fairly conservative in what I pulled in but I think
it fixes quite a few bugs. I will try to ensure I make more time for regular
releases, and have already pushed the tag. If no one spots issues I will make
and upload tarballs this evening, and then push out some announcements.

Thanks,

Marcus



Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options


Regards,
Konstantin

Здесь спама нет http://mail.yandex.ru/nospam/sign

Also
54a8ee52ddfbb0755c7262d875a1af2219cb2951
f583c2fa916a0034ba35a8bcd523af9119c46b6b
d6cb30819aed7551c0d1fc951bd07f3b0cd8588f

P.S. I’ve accidentally mentioned patch with manpages, which are already in 1.0. Sorry

28.04.10, 13:12, “Marcus D. Hanwell” marcus@cryos.org:

On Sunday 25 April 2010 15:24:06 Marcus D. Hanwell wrote:

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to go
in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally), and I
would rather be given commits to merge so that I can check them over.

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few fixes
in 1.0.1 that fix a few bugs. This has been many years in the making, and
it is a very positive move to see Kalzium move away from a snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus

Consider it tagged, I was fairly conservative in what I pulled in but I think
it fixes quite a few bugs. I will try to ensure I make more time for regular
releases, and have already pushed the tag. If no one spots issues I will make
and upload tarballs this evening, and then push out some announcements.

Thanks,

Marcus



Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

Also, don’t forget to update translations (I’ve made some changes today), and don’t forget to include Qt’s translations into Windows build (as in 1.0.0)

28.04.10, 13:12, “Marcus D. Hanwell” marcus@cryos.org:

On Sunday 25 April 2010 15:24:06 Marcus D. Hanwell wrote:

Hi,

I think that this is long overdue - I plan on tagging Avogadro 1.0.1 on
Tuesday, April 27. Please let me know if there is anything that needs to go
in before I tag - I just fixed a few issues and as far as I can see
everything looks good. Remember that this is bug fix only (ideally), and I
would rather be given commits to merge so that I can check them over.

Kalzium in KDE 4.5 will depend on Avogadro 1.0.0, but there are a few fixes
in 1.0.1 that fix a few bugs. This has been many years in the making, and
it is a very positive move to see Kalzium move away from a snapshot.

I cannot change the topic in the IRC channel at present. I think we need
Donald to confer superpowers on to myself and a few others.

Marcus

Consider it tagged, I was fairly conservative in what I pulled in but I think
it fixes quite a few bugs. I will try to ensure I make more time for regular
releases, and have already pushed the tag. If no one spots issues I will make
and upload tarballs this evening, and then push out some announcements.

Thanks,

Marcus



Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options


Regards,
Konstantin

Здесь спама нет http://mail.yandex.ru/nospam/sign

Moin

I guess you are also getting a million compiler-warnings like this?

=======================================================================
warning: invoking macro EIGEN_CAT argument 2: empty macro arguments are
undefined in ISO C90 and ISO C++98

Carsten

Will update manager still be disabled for Linux by default? I didn’t see any crashes caused by it.


Regards,
Konstantin

I have
also been doing a lot of work with the new external project support in CMake
2.8, it is probably a better route than the super project approach to
build/package Avogadro with all of its dependencies. There are even recipes
for building Qt and Python.

Out of curiosity, what are the benifits of this approach compared to simple build invocation from shell script?


Regards,
Konstantin

Moin

I am getting this when I am compiling git HEAD (Marcus’ branch):

/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp: In static
member function ‘static PyObject*
Vector3x_to_python_array::innerclass::convert(const Vector3x&)’:
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:47: error:
‘npy_intp’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:47: error:
expected ‘;’ before ‘dims’
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:50: error:
‘dims’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:50: error:
‘NPY_INT’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:50: warning:
there are no arguments to ‘PyArray_SimpleNew’ that depend on a template
parameter, so a declaration of ‘PyArray_SimpleNew’ must be available
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:52: error:
‘dims’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:52: error:
‘NPY_FLOAT’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:52: warning:
there are no arguments to ‘PyArray_SimpleNew’ that depend on a template
parameter, so a declaration of ‘PyArray_SimpleNew’ must be available
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:54: error:
‘dims’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:54: error:
‘NPY_DOUBLE’ was not declared in this scope
/home/carsten/svn/avogadro/libavogadro/src/python/eigen.cpp:54: warning:
there are no arguments to ‘PyArray_SimpleNew’ that depend on a template
parameter, so a declaration of ‘PyArray_SimpleNew’ must be available

Is that known?

Carsten

On Friday 30 April 2010 08:56:59 Konstantin Tokarev wrote:

Will update manager still be disabled for Linux by default? I didn’t see
any crashes caused by it.

No - after talking with several distro people we felt it wasn’t right. It
could be enabled for binaries we release though.

Marcus

On Friday 30 April 2010 14:28:17 Konstantin Tokarev wrote:

I have

also been doing a lot of work with the new external project support in
CMake 2.8, it is probably a better route than the super project
approach to build/package Avogadro with all of its dependencies. There
are even recipes for building Qt and Python.

Out of curiosity, what are the benifits of this approach compared to simple
build invocation from shell script?

The scripting is cross platform (no bash/Windows batch file dep), you can
download source tarballs, and compile them in place. One set of build files,
they can also control the build of things like Qt that do not use CMake. It
allows you to build each dep automatically on the system using the same
compiler/flags etc.

It is a new feature, and I have been involved in deploying it in a cross
platform project at Kitware. For Linux it means we can require/use more recent
dependencies than the developers distro provide, for Windows it means we can
automatically build all required deps. CMake options allow you to optionally
use system libraries too.

There are still a few bugs to work out, but I would say it is a good approach.
One project I work on optionally builds Qt, Boost and VTK for exmaple, among
other dependencies.

Marcus

02.05.10, 13:34, “Marcus D. Hanwell” marcus@cryos.org:

On Friday 30 April 2010 14:28:17 Konstantin Tokarev wrote:

I have

also been doing a lot of work with the new external project support in
CMake 2.8, it is probably a better route than the super project
approach to build/package Avogadro with all of its dependencies. There
are even recipes for building Qt and Python.

Out of curiosity, what are the benifits of this approach compared to simple
build invocation from shell script?

The scripting is cross platform (no bash/Windows batch file dep), you can
download source tarballs, and compile them in place. One set of build files,
they can also control the build of things like Qt that do not use CMake. It
allows you to build each dep automatically on the system using the same
compiler/flags etc.

What if I want to use different? E.g., compile boost, Avogadro and OB with Intel and Python with GCC (there are some problems)

It is a new feature, and I have been involved in deploying it in a cross
platform project at Kitware. For Linux it means we can require/use more recent
dependencies than the developers distro provide, for Windows it means we can
automatically build all required deps. CMake options allow you to optionally
use system libraries too.

There are still a few bugs to work out, but I would say it is a good approach.
One project I work on optionally builds Qt, Boost and VTK for exmaple, among
other dependencies.

Marcus


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign