Bug#848859: FTBFS randomly (failing tests)

[Ole Streicher]

Hi Santiago,

On 04.01.2017 01:41, Santiago Vila wrote:
> On Tue, 27 Dec 2016, Ole Streicher wrote:
> Hello Ole. Thanks for your reply. Please don't forget to Cc: me if you
> expect your message to be read.

OK, however I usually assume that a bug submitter actually reads the
messages for his submitted bugs.

>>> In particular, if something happens 1 every 20 times on average, the
>>> fact that it did not happen when you try 10 times does not mean in any
>>> way that it may not happen.
>>
>>
>> I must however say that I don't see why a package that fails to build
>> once in 20 builds would have a release critical problem:
> 
> It's in Release Policy: Packages *must* autobuild *without* failure.
> 
> If a package fails to build from time to time, that's a failure.

Packages actually *do* fail from time to time, when I look into my
autobuilder. Not due to the package, but due to glitches within the
buildd infrastructure. Would you consider this a failure?

>> I totally agree that catching random failures
>> is a good quality measure, but this is IMO severity "important" at maximum.
> 
> Well, would you say it's RC if it fails 99% of the time?
> I guess you would.

I would consider a bug RC if it actually doesn't build on our buildds.

>> And it would be nice to have this QA test not just before the release,
>> but already early in the release cycle. This would help a lot to avoid
>> stressful bugfixes just before the freeze.
> 
> Well, if you see my list of FTBFS-randomly bug here:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org
> 
> you will see that I started to report FTBFS-randomly bugs several
> months ago, not last week, and not last month.
> 
> What would really help is to have somebody else reporting these bugs,
> because apparently very few people want to report them.
> 
> Also, you can't seriously "complain" that a bug reporter didn't not
> report something earlier! Of course that it would be nice to do this
> kind of QA stuff at every point in the release cycle, but as the same
> software that we maintain, my bug reports come with no warranty, not
> even the warranty that the bug is reported "as soon as it exists"! :-)

What I do complain about is that doing this just before the release adds
additional pressure to the package maintainers: The problem for us
ordinary people is that most of the time my packages look fine, without
serious problems, and just before the release all those RC bugs pop up
in bunches, with quite some time pressure to solve them. If the RC bugs
were randomly distributed over time, it would be more time to solve
them, and the quality of the fixes would be better: for example, in the
moment, I would just disable build time tests that randomly fail, while
usually I would try to see why they fail and fix that. In the moment,
there is no time for this.

Doing release QA just before the release leads to quick hacks to keep
things there, while a continious QA really solves them.

Best regards

Ole

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

statsmodels is marked for autoremoval from testing

[Debian testing autoremoval watch]

statsmodels 0.8.0~rc1+git43-g1ac3f11-1 is marked for autoremoval from testing 
on 2017-01-29

It is affected by these RC bugs:
841610: statsmodels: FTBFS: TypeError: cannot sort an Index object in-place, 
use sort_values instead

It (build-)depends on packages with these RC bugs:
848771: numexpr: FTBFS: Test failures


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

sagemath is marked for autoremoval from testing

[Debian testing autoremoval watch]

sagemath 7.4-4 is marked for autoremoval from testing on 2017-02-02

It (build-)depends on packages with these RC bugs:
840823: execnet: 
testing/test_gateway.py::TestBasicGateway::test_gateway_status_busy[thread-popen]
 FAILED
846951: execnet: 
testing/test_gateway.py::TestTracing::test_popen_stderr_tracing FAILED
846952: execnet: testing/test_channel.py::TestStringCoerce::test_2to3 FAILED
848748: blockdiag: FTBFS: E: Build killed with signal TERM after 150 minutes of 
inactivity
849220: ipykernel: FTBFS (failing tests)


-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Fyi

[Teresa Danuta]

Hello , 



My name is Teresa Danuta I am a financial consultant , I got your contact

details in my search for a reliable and neutral company or individual to partner

with for profitable Return on Investment (ROI). I know that this mail might come

to you as surprise because we neither know each other nor has ever met but

accept it with an open and positive mind.



We want to partner with you to receive and place an investment funds into viable

business ventures in your country that can guarantee a good Return on Investment

(ROI) which will be under your control and management. 

We have obtained certificate of Incumbancy and Certificate of Good  Standing

for AMIC which are enclosed herewith. We shall firm up our approach on opening of

account once I have obtained necessary clarrification of Name of the Bank and

Depository of IGE Resources, issuer of shares. I expect to have this information

available beginning of Feb.



Details of the investment and funding will be furnished to you when I receive

your positive response which will also facilitate face to face meeting with the

investor. 



Yours Sincerely,



Teresa Danuta

​



























-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 846116 important
Bug #846116 [src:libhamcrest-java] libhamcrest-java: FTBFS randomly (error: 
cannot access Description)
Severity set to 'important' from 'serious'
> severity 680038 important
Bug #680038 [src:kyotocabinet] kyotocabinet: FTBFS randomly (failing test)
Severity set to 'important' from 'serious'
> severity 828929 important
Bug #828929 [src:cairocffi] cairocffi: FTBFS randomly
Severity set to 'important' from 'serious'
> severity 834686 important
Bug #834686 [src:ruby-httpclient] ruby-httpclient: FTBFS randomly (failing 
tests)
Severity set to 'important' from 'serious'
> severity 834962 important
Bug #834962 [src:ruby-diaspora-vines] ruby-diaspora-vines: FTBFS randomly 
(failing tests)
Severity set to 'important' from 'serious'
> severity 842836 important
Bug #842836 [src:golang-github-mxk-go-flowrate] golang-github-mxk-go-flowrate: 
FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 844083 important
Bug #844083 [src:openhft-lang] openhft-lang: FTBFS randomly 
(DataValueGeneratorTest.testGenerateInterfaceWithDateNativeInstace fails)
Severity set to 'important' from 'serious'
> severity 844088 important
Bug #844088 [src:conversant-disruptor] conversant-disruptor: FTBFS randomly 
(failing tests)
Severity set to 'important' from 'serious'
> severity 844571 important
Bug #844571 [src:uncertainties] uncertainties: FTBFS randomly (ERROR: 
Comparison between function derivatives and numerical derivatives)
Severity set to 'important' from 'serious'
> severity 845164 important
Bug #845164 [src:ruby-spy] ruby-spy: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 846021 important
Bug #846021 [src:ruby-webmock] ruby-webmock: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 846115 important
Bug #846115 [src:jekyll] jekyll: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 846300 important
Bug #846300 [src:ruby-distribution] ruby-distribution: FTBFS randomly (failing 
tests)
Severity set to 'important' from 'serious'
> severity 846318 important
Bug #846318 [src:automake-1.15] automake-1.15: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 848054 important
Bug #848054 [src:debci] debci: FTBFS randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 848055 important
Bug #848055 [src:golang-github-go-chef-chef] golang-github-go-chef-chef: FTBFS 
randomly (failing tests)
Severity set to 'important' from 'serious'
> severity 848403 important
Bug #848403 [src:diffoscope] diffoscope: FTBFS randomly (Fatal Python error: 
deallocating None)
Severity set to 'important' from 'serious'
> severity 849775 important
Bug #849775 [src:emacs24] emacs24: FTBFS randomly (Wrong type argument: 
number-or-marker-p, nil)
Severity set to 'important' from 'serious'
> severity 849217 important
Bug #849217 [src:jruby] jruby: FTBFS randomly (sbuild hangs)
Severity set to 'important' from 'serious'
> severity 832865 important
Bug #832865 [src:telepathy-python] telepathy-python: FTBFS: will not overwrite 
just-created 
'/«PKGBUILDDIR»/debian/python-telepathy//usr/lib/python2.7/dist-packages/telepathy/_generated/errors.py'
 with '_generated/errors.py'
Ignoring request to change severity of Bug 832865 to the same value.
> severity 837067 important
Bug #837067 [src:libsecret] libsecret: FTBFS - /collection/delete-sync failure
Ignoring request to change severity of Bug 837067 to the same value.
> severity 848063 important
Bug #848063 [src:ri-li] ri-li: FTBFS randomly (Impossible d'initialiser 
SDL:Couldn't open X11 display)
Ignoring request to change severity of Bug 848063 to the same value.
> severity 849363 important
Bug #849363 [src:libtime-format-perl] libtime-format-perl: FTBFS randomly (race 
condition in t/time.t)
Ignoring request to change severity of Bug 849363 to the same value.
> severity 846026 important
Bug #846026 [src:strongswan] strongswan: FTBFS randomly (failing tests)
Ignoring request to change severity of Bug 846026 to the same value.
> severity 841904 important
Bug #841904 [src:swift] swift: FTBFS randomly (failing tests)
Severity set to 'important' from 'normal'
> severity 847288 important
Bug #847288 [src:libdbd-firebird-perl] libdbd-firebird-perl: FTBFS randomly 
(failing tests)
Severity set to 'important' from 'normal'
> severity 848859 important
Bug #848859 [src:getfem++] getfem++: FTBFS randomly (failing tests)
Severity set to 'important' from 'minor'
> severity 841098 important
Bug #841098 [src:rygel] rygel: FTBFS (rygel-media-engine-test fails)
Severity set to 'important' from 'wishlist'
> severity 843038 important
Bug #843038 [src:elki] elki: FTBFS randomly (failing tests)
Severity set to 'important' from 'wishlist'
> severity 848409 important
Bug #848409 [src:libchi-driver-redis-perl] libchi-driver-redis-perl: FTBFS 
randomly (failing tests)
Severity set 

Bug#848859: (no subject)

[Santiago Vila]

severity 846116 important
severity 680038 important
severity 828929 important
severity 834686 important
severity 834962 important
severity 842836 important
severity 844083 important
severity 844088 important
severity 844571 important
severity 845164 important
severity 846021 important
severity 846115 important
severity 846300 important
severity 846318 important
severity 848054 important
severity 848055 important
severity 848403 important
severity 849775 important
severity 849217 important
severity 832865 important
severity 837067 important
severity 848063 important
severity 849363 important
severity 846026 important
severity 841904 important
severity 847288 important
severity 848859 important
severity 841098 important
severity 843038 important
severity 848409 important
severity 710696 important
thanks

Hello.

I'm setting the severity of this bug to "important" not because
I don't think it is not RC (as Release Policy still says that
packages must autobuild *without* failure), but because the
Release Managers are considering to decide about RC-ness
of this kind of bugs based on the probability of failure.

We don't know what kind of threshold there will be for stretch, so I
strongly recommend that you act as if this bug was serious and RC,
especially if the failures happen very often on any kind of
autobuilder which is not misconfigured.

Thanks.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Tue, 27 Dec 2016, Ole Streicher wrote:

> Hi Santiago,

Hello Ole. Thanks for your reply. Please don't forget to Cc: me if you
expect your message to be read.

> > In particular, if something happens 1 every 20 times on average, the
> > fact that it did not happen when you try 10 times does not mean in any
> > way that it may not happen.
> 
> 
> I must however say that I don't see why a package that fails to build
> once in 20 builds would have a release critical problem:

It's in Release Policy: Packages *must* autobuild *without* failure.

If a package fails to build from time to time, that's a failure.

> There is nothing in our policy that requires a reproducible or even a
> always successful build.

Please don't mix "reproducible" with "always successful build".

They are different things and nobody is making "reproducible builds"
policy yet.

But "always successful" has always been release policy:

https://release.debian.org/stretch/rc_policy.txt

Please read the paragraph saying "packages must autobuild without
failure". That paragraph is the very reason FTBFS bugs are serious
since a lng time.

> I totally agree that catching random failures
> is a good quality measure, but this is IMO severity "important" at maximum.

Well, would you say it's RC if it fails 99% of the time?
I guess you would.

Would you say it's RC if it fails 0.001% of the time?
I guess you would not, since you have just said that 0.05% does not
deserve to be serious.

So, you are implicitly saying that packages which FTBFS with a
low probability does not deserve a serious bug.

However, there is no threshold at all in policy, and if you think
about it, any such threshold would be quite arbitrary indeed:
Why would 50% of failure be RC while 49% of failure is not?

[ To me, the mere fact that we are able to *measure* the probability
  of failure already means that it is too high ].


Anyway, there will be plenty of time to discuss about this because I'm
going to downgrade all the FTBFS-randomly bugs I've detected until
Release Managers say something about the subject.

Then I expect most (if not all) of them will become serious and RC
again.

> And it would be nice to have this QA test not just before the release,
> but already early in the release cycle. This would help a lot to avoid
> stressful bugfixes just before the freeze.

Well, if you see my list of FTBFS-randomly bug here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org

you will see that I started to report FTBFS-randomly bugs several
months ago, not last week, and not last month.

What would really help is to have somebody else reporting these bugs,
because apparently very few people want to report them.

Also, you can't seriously "complain" that a bug reporter didn't not
report something earlier! Of course that it would be nice to do this
kind of QA stuff at every point in the release cycle, but as the same
software that we maintain, my bug reports come with no warranty, not
even the warranty that the bug is reported "as soon as it exists"! :-)

Thanks.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)

[Paul Gevers]

Hmmm,

On 03-01-17 22:07, Paul Gevers wrote:
> On 03-01-17 21:21, PICCA Frederic-Emmanuel wrote:
>> I just try to use dbconfig-common like I did before, 
>> (create the tango database, populate it with a few values and create some 
>> procedures.)
>>
>> What is strange to me is that with dbconfig-common (jessie version), I end 
>> up with procedure owned by
>> root @ localhost
>>
>> but when I use the dbconfig-common of stretch, the procedure are owned by 
>> tango @ localhost 5which is right)
>>
>> I always used the non dbadmin script in order to configure my database.
>> This is why I do not understand why the mysqldump does not work anymore.
>> Does the dump changed between the jessie and strecth dbconfig-common ?
>>
>> By change I mean.
>>
>> In jessie it is run as root, but on stretch it is run as tango ?
> 
> Let me check the (huge) delta between jessie and stretch (hopefully
> tomorrow). I made major improvements in the code, but I don't
> specifically remember anything related to this issue. Furthermore, I
> don't rule out that this is indeed MySQL/MariaDB related. We/you could
> also ask the maintainers list of those packages if the current behavior
> rings a bell. Additionally, trying to do the tests as you did so far but
> sticking to MySQL instead of moving over to MariaDB would be an
> interesting and insightful exercise.

I am suspecting that this commit may be related to the current behavior:
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=acdb99d61abfff54630c4cfba6e4452357a83fb9

I believe I implemented there that the drop of the database is performed
with the user privileges instead of the dbadmin privileges because I
believed one should always have the rights to drop the db. Apparently I
was wrong. We may need to clone or reassign this bug to dbconfig, but
I'm not sure yet if there aren't more things, or if tango-db should work
around the issue (which may be created by buggy dbconfig-common behavior
of the past).

Out of time now.

Paul



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)

[Paul Gevers]

Hi Frederic-Emmanuel,

On Tue, 3 Jan 2017 15:02:08 + PICCA Frederic-Emmanuel
 wrote:
> 1) On Jessie 
> 
> with the tango account
> 
> mysql> use tango;
> mysql> show create procedure class_att_prop\G
> 
> I got  "Create Procedure": NULL
> 
> But If I use the root account (mysqladmin)
> 
> CREATE DEFINER=`root`@`localhost` PROCEDURE `class_att_prop` (IN class_name 
> VARCHAR(255), INOUT res_str BLOB)
> 
> which shows clearly that on jessie the procédure where created with the admin 
> account
> 
> 2) On stretch
> 
> with the tango account
> 
> > CREATE DEFINER=`tango`@`localhost` PROCEDURE `class_att_prop` (IN 
> > class_name VARCHAR(255), INOUT res_str MEDIUMBLOB)
> 
> Which shows that the procedures were created with the right tango account.
> 
> Now the question is how can we fix this ?

I am not sure that I follow what you are doing, but if you need the code
to be run with the dbadmin privileges, you should put the code in:
/usr/share/dbconfig-common/data/PACKAGE/upgrade-dbadmin/DBTYPE/VERSION
instead of in:
/usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION

Please consult the documentation here:
https://www.debian.org/doc/manuals/dbconfig-common/ch-develguide.html#s-updates
and (describing the difference):
https://www.debian.org/doc/manuals/dbconfig-common/ch-develguide.html#s-bootstrap

Paul



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

debian-science-maintainers@lists.alioth.debian.org邮件系统备案提醒！

[postmaster]

这是一封 HTML 格式的邮件，请以网页方式查看邮件。
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

pybind11_2.0.0-1_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 03 Jan 2017 15:44:46 +
Source: pybind11
Binary: pybind11-dev pybind11-doc python-pybind11 python3-pybind11
Architecture: source
Version: 2.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Ghislain Antony Vaillant 
Description:
 pybind11-dev - seamless operability between C++11 and Python
 pybind11-doc - documentation for pybind11
 python-pybind11 - pybind11 helper module for Python 2
 python3-pybind11 - pybind11 helper module for Python 3
Changes:
 pybind11 (2.0.0-1) unstable; urgency=medium
 .
   * Remove gbp configuration in favor of git-dpm
   * Mangle upstream development versions
   * New upstream release
   * Add support for the nocheck build profile
 - Add versioned dependency on dpkg-dev
 - Mark build dependencies specific to testing as !nocheck
 - Do not build the test suite if nocheck is requested
   * Add support for the nodoc build profile
 - Mark build dependencies specific to the documentation as !nodoc
 - Add build dependency on sphinx-common for dh_sphinxdoc
 - Do not build the documentation if nodoc is requested
Checksums-Sha1:
 3a26bdff430f5852f7a3e7a28212e7d91f27496b 2531 pybind11_2.0.0-1.dsc
 1583b3c1d015762845995d99a9101b3f595a4cd7 398189 pybind11_2.0.0.orig.tar.gz
 427d419923451fa5397b8704fecb816b811069f2 5156 pybind11_2.0.0-1.debian.tar.xz
Checksums-Sha256:
 f5afc975b8578743eb95c4f6eaacde09a316a8fcf831191ac5930e5fa9e625f0 2531 
pybind11_2.0.0-1.dsc
 5b8c599416941e62f2452111c9274c22bb1b5fa65bb7fdfd0c405332af656e9a 398189 
pybind11_2.0.0.orig.tar.gz
 9c401600137dc5a22244e324612b249f13b2a4ff8d630d558392489fd87a7593 5156 
pybind11_2.0.0-1.debian.tar.xz
Files:
 a545f9df0bbc14dde505e450f863c8a2 2531 libs optional pybind11_2.0.0-1.dsc
 d643ddc89dc0f660c4bc19bcc93b4421 398189 libs optional 
pybind11_2.0.0.orig.tar.gz
 37f0c144efdbaa6e605557118564c920 5156 libs optional 
pybind11_2.0.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAlhr5/QACgkQ0+Fzg8+n
/wYveg/+KdDihAvL6MN7osGJ3CkRuzvAMFKbzsuC3tnYq4qhcQneTzaZOujq3QtQ
8S89aZf0aJ5Fm/XJ7ez5chanAiGq3p2jlk7YgqDjJsfwEqGFtbTf/E3sfQOznrk/
w2m7AlS4GFC08b4s/IOMwJgDnEhpsM7H5pigUuRcXgIIQwIKdjmNrAJduc9ct2Sh
6sb74VInDAKYr8Rdue0ZotVL4Qmux/R4S68YKxba08IOv59lDyusctxOiIowXvxz
I3G1jwmNuOUQLyo2/5+3KFnrPab131sWhruakpfbjf8KDR4Xl0Y+zOLqmBxMgJTL
BnJBvBABSS7H12GfBhSs0IdAQqgJ3stMmlg1Wv7rZzIB6Cbty0YGQ8pKf4qEBCky
m3TWh+HZJg9DOlSr7ewCl9PkS/QUufv8J4Mt1ujX0X95gNaK1Nci00LNHl4Ky8Db
5YoVDf8lgqGiN1KSbxdh96hSsUe9AJwfT6SB8CoTK63skTJiaGRrlcP15LamuPcS
2XCaR8fs21m97as4aM0rw5HxcKPkrRvwZA2qYAa4t8N9NBG/Qz6R+sfPJ8pF6NNN
/1W086y31JYNa+/S7tFYwGc9aE7UKVUgFKUjKYh6M2/oIv99VcqGPMW1gUN/f+57
VWfvfTOzdcuuCSEfxlLNHmvNScfTV0UUTGCQP8geTlRzxgqh0ks=
=oewj
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850065: openfoam: Build runs way more parallel processes than specified by DEB_BUILD_OPTIONS

[Daniel Schepler]

Source: openfoam
Version: 4.1+dfsg1-1
Severity: important

When I try building openfoam under pbuilder (on amd64), with
DEB_BUILD_OPTIONS="parallel=8", it swaps heavily.  By running top I see at
least about 30 cc1plus processes trying to run at the same time (it's hard
to get an exact count since the swapping makes doing anything painfully
slow).
-- 
Daniel Schepler
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Processing of pybind11_2.0.0-1_source.changes

[Debian FTP Masters]

pybind11_2.0.0-1_source.changes uploaded successfully to localhost
along with the files:
  pybind11_2.0.0-1.dsc
  pybind11_2.0.0.orig.tar.gz
  pybind11_2.0.0-1.debian.tar.xz

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

sagemath 7.4-4 MIGRATED to testing

[Debian testing watch]

FYI: The status of the sagemath source package
in Debian's testing distribution has changed.

  Previous version: (not in testing)
  Current version:  7.4-4

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

eigen3 3.3.1-2 MIGRATED to testing

[Debian testing watch]

FYI: The status of the eigen3 source package
in Debian's testing distribution has changed.

  Previous version: 3.3.0-1
  Current version:  3.3.1-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848137: Info received (problem with the upgrade of tango-db)

[PICCA Frederic-Emmanuel]

Thanks to reynald

1) On Jessie 

with the tango account

mysql> use tango;
mysql> show create procedure class_att_prop\G

I got  "Create Procedure": NULL

But If I use the root account (mysqladmin)

CREATE DEFINER=`root`@`localhost` PROCEDURE `class_att_prop` (IN class_name 
VARCHAR(255), INOUT res_str BLOB)

which shows clearly that on jessie the procédure where created with the admin 
account

2) On stretch

with the tango account

> CREATE DEFINER=`tango`@`localhost` PROCEDURE `class_att_prop` (IN class_name 
> VARCHAR(255), INOUT res_str MEDIUMBLOB)

Which shows that the procedures were created with the right tango account.

Now the question is how can we fix this ?
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848137: problem with the upgrade of tango-db

[PICCA Frederic-Emmanuel]

Hello, I would like to discuss about this bug [1]

I tryed to reproduce the scenary of piuparts in a virtual machine (gnome-box)

installed in 3 steps:
   jessie base system
   mysql-server (I need a working database)
   tango-db (daemon)


It works ok, I have a running tango-db daemon (ps aux | grep tango)

then

replace jessie by stretch in the sources.list

apt-get update
apt-get install mysql-server (5.5 -> 5.6)

the tango-db is still working.


Now I installed the new default-mysql-server


apt-get install default-mysql-server (5.6 -> mariadb 10.1)

the tango-db daemon is still working.

Now I upgrade tango-db

apt-get install tango-db (tango8 -> tango9)

and during this upgrade I have a problem of right that you can see in the bug 
report.

I would like to know how to debug this problem, I tryed to export dbc_debug=1, 
But I got no real information about the failing mysqldump.

I would say that I know almost nothing about sql, but I can learn.

What is strange from mmy point of view, is that I created the table and 
populate it only with dbconfig-common.
So I find strange that the dump can not work.

Maybe this is a problem of compatibility between mysql/mariadb, because the 
dabatase was first created with mysql 5.5 and the upgrade is done via mariadb.

Are you aware of problem of right due to mariadb ?


thanks for your help


Fred

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848137


please CC me I am not on the mailing list

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Ghislain Vaillant]

Hi Erik, thanks for reporting this issue,

freeimage/3.17.0+ds1-4 fixed an issue with the patch used to remove the
vendored dependencies and use the system one instead. See #841089 [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841089

The updated patch introduces a null-node for plugins which have been
disabled (here the G3 fax format). Before this patch, all nodes stored
in the plugin map were guaranteed to be non-null but all plugins with
IDs over FIF_FAXG3 were wrongly indexed.

A fix for your issue in rviz would be to filter the plugin map from
non-null nodes prior to registering the codecs.

Hope this helps,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 849945 + patch
Bug #849945 [src:evolver] evolver: FTBFS on ppc64el - error: initializer 
element is not constant
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
849945: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849945
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Erik Andresen]

Package: libfreeimage3
Version: 3.17.0+ds1-3
Severity: important

Hi,

the recent libfreeimage update from 3.17.0+ds1-3 to to 3.17.0+ds1-4
breaks rviz. The application fails to start with:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
  zsh: abort  rviz

reverting freeimage to ds1-3 fixes the problem. Relevant upstream rviz
bug is:
https://github.com/ros-visualization/rviz/issues/1071

greetings,
Erik

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#846436: marked as done (librsl: add libfl-dev to Build-Depends)

[Debian Bug Tracking System]

Your message dated Tue, 03 Jan 2017 09:49:39 +
with message-id 
and subject line Bug#846436: fixed in librsl 1.43-1.1
has caused the Debian Bug report #846436,
regarding librsl: add libfl-dev to Build-Depends
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
846436: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846436
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: librsl
Severity: important
User: helm...@debian.org
Usertags: libfldep

librsl will soon fail to build from source, beause flex drops its
dependency on libfl-dev. Since librsl uses parts of libfl-dev (e.g.
libl.a, libfl.a or FlexLexer.h), it should add libfl-dev to its
Build-Depends. This change was previously announced[1] to
debian-devel in accordance with DevRef 7.1.1. Please add the missing
dependency.

Helmut

[1] https://lists.debian.org/debian-devel/2016/03/msg00162.html 
--- End Message ---
--- Begin Message ---
Source: librsl
Source-Version: 1.43-1.1

We believe that the bug you reported is fixed in the latest version of
librsl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 846...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrey Rahmatullin  (supplier of updated librsl package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 03 Jan 2017 14:27:17 +0500
Source: librsl
Binary: librsl1 librsl-dev librsl-doc
Architecture: source
Version: 1.43-1.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Andrey Rahmatullin 
Description:
 librsl-dev - Development files for RSL
 librsl-doc - HTML documentation for RSL
 librsl1- TRMM Radar Software Library
Closes: 846436
Changes:
 librsl (1.43-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add Build-Depends: libfl-dev (Closes: #846436).
Checksums-Sha1:
 ba09308585a6601ad7d062c1297882b22736b18e 2108 librsl_1.43-1.1.dsc
 74505d0a1b0fb27e16cb732cccda0800782bb669 7492 librsl_1.43-1.1.debian.tar.xz
Checksums-Sha256:
 2ec8f4c5d234ce354a9fbf662067f85de0bc9978cacc03631d7bbebc466c5f16 2108 
librsl_1.43-1.1.dsc
 36b4ef2c10980067ac72ae5c08d19236399c7f80073ab5261df2a8bc668d7db5 7492 
librsl_1.43-1.1.debian.tar.xz
Files:
 5a072b889596f45f450614303824275f 2108 science extra librsl_1.43-1.1.dsc
 49b4fb08e47234af655e80089ffb4047 7492 science extra 
librsl_1.43-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAlhrb4UACgkQM2L3AxpJ
kuFC5w/7B9f5sasvwahZn8/krCNFIQhtn8wprsl9FdE90cjLOfpXw+MLvNls9lgy
VdKWTH1E/aHiR4y3TDkinxq33Y67YNXdqNW466v54EihIj+SZ4uMEyb34AHi6zfC
UqCWUTGIkNiWEdnfCkJ//y5TZtHymxmshJnv/d8L6QvxbqHbuYR795bFSsg6XRdt
YYw5gnPU1eHDX96Etq2yn1y9CJUbK6uH30gMaZW25ZICr5gym/bl0cZO4b6mqpyR
DiTD+4TWib2QPzNx9SxZFJSSfN4A3RZZhiLGJZjOMmOlCNbPLiTdyOWcRjP85wE4
2AYwDMIC5gI/RkuAMkPNingX38zuMuWpSkmHazHiwp7EY2cYj+XnMialk1cCJg0s
TlnsJZNPVMo94Q1CxDm2iXTbNw3qsrvdC7GMUi1a+tUoeG8mzoS7vIMo6+S+z4RQ
3uTbggVB7f13LFciNYrwwNTM9MQ6NLan1bOw6yftsnzFEdq3TO78esaVsXx/wys0
LqhK13nXVMQ9lupbPr5qyNUp2KdK2ALCJeLxh6FKm7BmYJMjqWftbY9CFVP0YdbJ
yfpF3KKLHiz8PeM0qTwjWWE8U0V51nagewNF3yrbx9cYXK+tQJQoKIDzk5TQ+/l0
/UKJuo/v9RO6kjiMZYCwX2hg6tQ4+Ohip9J8RNSriXmG+OUsmDQ=
=cc22
-END PGP SIGNATURE End Message ---
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850026: vmtk: transitive B-D on both libssl-dev and libssl1.0-dev

[Andreas Beckmann]

Source: vmtk
Version: 1.3+dfsg-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

vmtk cannot be built any longer, since it transitively Build-Depends on
both libssl-dev and libssl1.0-dev which conflict with each other.


Andreas

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

librsl_1.43-1.1_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 03 Jan 2017 14:27:17 +0500
Source: librsl
Binary: librsl1 librsl-dev librsl-doc
Architecture: source
Version: 1.43-1.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Andrey Rahmatullin 
Description:
 librsl-dev - Development files for RSL
 librsl-doc - HTML documentation for RSL
 librsl1- TRMM Radar Software Library
Closes: 846436
Changes:
 librsl (1.43-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add Build-Depends: libfl-dev (Closes: #846436).
Checksums-Sha1:
 ba09308585a6601ad7d062c1297882b22736b18e 2108 librsl_1.43-1.1.dsc
 74505d0a1b0fb27e16cb732cccda0800782bb669 7492 librsl_1.43-1.1.debian.tar.xz
Checksums-Sha256:
 2ec8f4c5d234ce354a9fbf662067f85de0bc9978cacc03631d7bbebc466c5f16 2108 
librsl_1.43-1.1.dsc
 36b4ef2c10980067ac72ae5c08d19236399c7f80073ab5261df2a8bc668d7db5 7492 
librsl_1.43-1.1.debian.tar.xz
Files:
 5a072b889596f45f450614303824275f 2108 science extra librsl_1.43-1.1.dsc
 49b4fb08e47234af655e80089ffb4047 7492 science extra 
librsl_1.43-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAlhrb4UACgkQM2L3AxpJ
kuFC5w/7B9f5sasvwahZn8/krCNFIQhtn8wprsl9FdE90cjLOfpXw+MLvNls9lgy
VdKWTH1E/aHiR4y3TDkinxq33Y67YNXdqNW466v54EihIj+SZ4uMEyb34AHi6zfC
UqCWUTGIkNiWEdnfCkJ//y5TZtHymxmshJnv/d8L6QvxbqHbuYR795bFSsg6XRdt
YYw5gnPU1eHDX96Etq2yn1y9CJUbK6uH30gMaZW25ZICr5gym/bl0cZO4b6mqpyR
DiTD+4TWib2QPzNx9SxZFJSSfN4A3RZZhiLGJZjOMmOlCNbPLiTdyOWcRjP85wE4
2AYwDMIC5gI/RkuAMkPNingX38zuMuWpSkmHazHiwp7EY2cYj+XnMialk1cCJg0s
TlnsJZNPVMo94Q1CxDm2iXTbNw3qsrvdC7GMUi1a+tUoeG8mzoS7vIMo6+S+z4RQ
3uTbggVB7f13LFciNYrwwNTM9MQ6NLan1bOw6yftsnzFEdq3TO78esaVsXx/wys0
LqhK13nXVMQ9lupbPr5qyNUp2KdK2ALCJeLxh6FKm7BmYJMjqWftbY9CFVP0YdbJ
yfpF3KKLHiz8PeM0qTwjWWE8U0V51nagewNF3yrbx9cYXK+tQJQoKIDzk5TQ+/l0
/UKJuo/v9RO6kjiMZYCwX2hg6tQ4+Ohip9J8RNSriXmG+OUsmDQ=
=cc22
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Processing of librsl_1.43-1.1_source.changes

[Debian FTP Masters]

librsl_1.43-1.1_source.changes uploaded successfully to localhost
along with the files:
  librsl_1.43-1.1.dsc
  librsl_1.43-1.1.debian.tar.xz

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#846436: librsl: diff for NMU version 1.43-1.1

[Andrey Rahmatullin]

Control: tags 846436 + patch

Dear maintainer,

I've prepared an NMU for librsl (versioned as 1.43-1.1). The diff
is attached to this message.

Regards.

-- 
WBR, wRAR
diff -Nru librsl-1.43/debian/changelog librsl-1.43/debian/changelog
--- librsl-1.43/debian/changelog	2013-06-20 15:52:44.0 +0600
+++ librsl-1.43/debian/changelog	2017-01-03 14:27:17.0 +0500
@@ -1,3 +1,10 @@
+librsl (1.43-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Build-Depends: libfl-dev (Closes: #846436).
+
+ -- Andrey Rahmatullin   Tue, 03 Jan 2017 14:27:17 +0500
+
 librsl (1.43-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru librsl-1.43/debian/control librsl-1.43/debian/control
--- librsl-1.43/debian/control	2013-06-20 15:45:10.0 +0600
+++ librsl-1.43/debian/control	2017-01-03 14:27:17.0 +0500
@@ -2,7 +2,7 @@
 Priority: extra
 Maintainer: Debian Science Maintainers 
 Uploaders: Andy Spencer 
-Build-Depends: debhelper (>= 9), dh-autoreconf, libhdf4-dev, libjpeg-dev, flex
+Build-Depends: debhelper (>= 9), dh-autoreconf, libhdf4-dev, libjpeg-dev, flex, libfl-dev
 Standards-Version: 3.9.4
 Section: science
 Homepage: http://trmm-fc.gsfc.nasa.gov/trmm_gv/software/rsl/


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Processed: librsl: diff for NMU version 1.43-1.1

[Debian Bug Tracking System]

Processing control commands:

> tags 846436 + patch
Bug #846436 [src:librsl] librsl: add libfl-dev to Build-Depends
Added tag(s) patch.

-- 
846436: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846436
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#836844: fixed in eigen3 3.3.1-2

[TFAUCK]

Sounds working fine  - thanks
-- 

__
thf - Thierry Fauck - tfa...@free.fr>
/pubkey: 4096R/FCC181CE/
/fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers