Processed: gnucap-python: please stop build-depending on python3.6

2019-01-13 Thread Debian Bug Tracking System
Processing control commands:

> block 916817 by -1
Bug #916817 [release.debian.org] transition: remove python3.6
916817 was blocked by: 917369 917628 917626 916820 914147 917781
916817 was not blocking any bugs.
Added blocking bug(s) of 916817: 919255

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



Crie seus sistemas - Gerador de sistemas + 4 SISTEMAS COMPLETOS

2019-01-13 Thread GERADOR DE SISTEMAS


Convidamos você a adquirir o melhor Gerador de Sistemas do mercado com PREÇO DE 
CUSTO.

Crie sistemas SEM PRECISAR SABER PROGRAMAR.

Você poderá adquirir o Logic Line por SOMENTE R$ 198 até 15/01/2019 e receber:

- Logic Line - Gerador de sistemas e ferramenta de desenvolvimento completa
- 4 sistemas completos, que você pode modificar a até comercializar.
. Sistema de vendas integrado com estoque e contas a pagar e a receber.
. Sistema de telemensagens.
. Sistema de imobiliária.
. Sistema com múltiplos exemplos de desenvolvimento.
- O Logic Line e os sistemas gerador rodam em todos os Windows (32-bit e 64-bit)
- Manuais e exemplos completos de utilização.
- Suporte gratuito por 1 ano.

Você pode fazer uma transferência Santander ou TED/DOC do seu banco:

Banco : Santander (033)
Agência : 3216
onta Corrente : 01005821-9
Titular : Ulisses Teixeira Corbett
CPF: 038.839.887-66
Valor: R$ 198 - Logic Line 1.9 completo + 4 sistemas


ALGUMAS CARACTERÍSTICAS DO LOGIC LINE:

- O Logic Line é uma linguagem visual e interativa, de forma
que você não utiliza nenhuma outra linguagem com ele. Basta
aprender os recursos do Logic Line para desenvolver qualquer
sistema. O Logic Line gera os .EXE(executáveis) dos sistemas
diretamente.
- O Logic Line roda em qualquer computador do mercado, em
qualquer Windows, do Windows 95 ao Windows 10, assim como
todos os sistemas criados com ele.
- Todos os sistemas feitos com o Logic Line rodam automaticamente
em rede, sendo que também existem comandos específicos no Logic Line
para a manipulação dos sistemas em rede.
- Os executáveis(.EXE) dos sistemas gerados pelo Logic Line
são de propriedade do usuário do Logic Line. Por isso, você pode
distribuir e comercializar livremente os sistemas desenvolvidos,
sem precisar pagar nada.
- Com o Logic Line, você pode se comunicar com qualquer outra
aplicação, através da importação e exportação de arquivos texto,
em qualquer formato.
- Cada sistema pode ter até 64.000 arquivos. Cada arquivo pode ter até
4 BILHÕES de registros, sem perda de performance.
- Qualquer combinação de relacionamento de arquivos pode ser feita
utilizando o Logic Line, sem limitações.
- O Logic Line possui dezenas de recursos multimídia para os sistemas,
como fotos, vídeos, músicas e outros, inclusive ligados aos bancos de dados.
- O Logic Line possui alteração automática de base de dados no cliente final
em caso de alteração de estrutura dos dados, sem precisar desenvolver programas
de conversão de dados.
- Não há necessidade de reindexação dos arquivos em caso de queda de luz ou
outros problemas, porque a tecnologia dos arquivos de dados mantém os índices
no mesmo arquivo físico dos dados, com total garantia de integridade.
- O Logic Line possui criação visual de janelas, inputs, botões, gráficos
estatísticos (linha, barra, pizza, área, etc), molduras, consultas por listas
(browses) e muitos outros objetos. Ele também possui criação rápida e visual
de relatórios e etiquetas, bem como de qualquer outro processamento no sistema.
- O Logic Line traz a possibilidade de criação de novos recursos, com
combinação infinita dos recursos existentes.
- O Logic Line permite a comunicação com qualquer hardware externo,
como impressoras fiscais, leitores e impressoras de código de barra, etc.
- O Logic Line permite a chamada de programas externos por dentro dos
sistemas desenvolvidos, tornando as aplicações ainda mais abrangentes.
- Muitos outros recursos.
Você terá a melhor ferramenta de criação de sistemas, com o melhor preço,
e o melhor atendimento.
facilitando o aprendizado rápido.


Após o depósito, envie-nos um email com os seguintes dados:

---
Nome ou Razão Social :
Endereço :
Bairro   :
Cidade   :
Estado(UF)   :
CEP  :
Telefone :
Telefone 2(opcional) :
Email:
Email 2(opcional):
Pessoa para contato  :
Data do depósito: __/__/2019
---

Conte sempre com a gente.

Abraços dos amigos da


Corbett Software
Os melhores programas desde 1998

WhatsApp/Telefone:
22-99788-1694
Skype:
corbettsoftware



Crie seus sistemas - Gerador de sistemas + 4 SISTEMAS COMPLETOS

2019-01-13 Thread GERADOR DE SISTEMAS


Convidamos você a adquirir o melhor Gerador de Sistemas do mercado com PREÇO DE 
CUSTO.

Crie sistemas SEM PRECISAR SABER PROGRAMAR.

Você poderá adquirir o Logic Line por SOMENTE R$ 198 até 15/01/2019 e receber:

- Logic Line - Gerador de sistemas e ferramenta de desenvolvimento completa
- 4 sistemas completos, que você pode modificar a até comercializar.
. Sistema de vendas integrado com estoque e contas a pagar e a receber.
. Sistema de telemensagens.
. Sistema de imobiliária.
. Sistema com múltiplos exemplos de desenvolvimento.
- O Logic Line e os sistemas gerador rodam em todos os Windows (32-bit e 64-bit)
- Manuais e exemplos completos de utilização.
- Suporte gratuito por 1 ano.

Você pode fazer uma transferência Santander ou TED/DOC do seu banco:

Banco : Santander (033)
Agência : 3216
onta Corrente : 01005821-9
Titular : Ulisses Teixeira Corbett
CPF: 038.839.887-66
Valor: R$ 198 - Logic Line 1.9 completo + 4 sistemas


ALGUMAS CARACTERÍSTICAS DO LOGIC LINE:

- O Logic Line é uma linguagem visual e interativa, de forma
que você não utiliza nenhuma outra linguagem com ele. Basta
aprender os recursos do Logic Line para desenvolver qualquer
sistema. O Logic Line gera os .EXE(executáveis) dos sistemas
diretamente.
- O Logic Line roda em qualquer computador do mercado, em
qualquer Windows, do Windows 95 ao Windows 10, assim como
todos os sistemas criados com ele.
- Todos os sistemas feitos com o Logic Line rodam automaticamente
em rede, sendo que também existem comandos específicos no Logic Line
para a manipulação dos sistemas em rede.
- Os executáveis(.EXE) dos sistemas gerados pelo Logic Line
são de propriedade do usuário do Logic Line. Por isso, você pode
distribuir e comercializar livremente os sistemas desenvolvidos,
sem precisar pagar nada.
- Com o Logic Line, você pode se comunicar com qualquer outra
aplicação, através da importação e exportação de arquivos texto,
em qualquer formato.
- Cada sistema pode ter até 64.000 arquivos. Cada arquivo pode ter até
4 BILHÕES de registros, sem perda de performance.
- Qualquer combinação de relacionamento de arquivos pode ser feita
utilizando o Logic Line, sem limitações.
- O Logic Line possui dezenas de recursos multimídia para os sistemas,
como fotos, vídeos, músicas e outros, inclusive ligados aos bancos de dados.
- O Logic Line possui alteração automática de base de dados no cliente final
em caso de alteração de estrutura dos dados, sem precisar desenvolver programas
de conversão de dados.
- Não há necessidade de reindexação dos arquivos em caso de queda de luz ou
outros problemas, porque a tecnologia dos arquivos de dados mantém os índices
no mesmo arquivo físico dos dados, com total garantia de integridade.
- O Logic Line possui criação visual de janelas, inputs, botões, gráficos
estatísticos (linha, barra, pizza, área, etc), molduras, consultas por listas
(browses) e muitos outros objetos. Ele também possui criação rápida e visual
de relatórios e etiquetas, bem como de qualquer outro processamento no sistema.
- O Logic Line traz a possibilidade de criação de novos recursos, com
combinação infinita dos recursos existentes.
- O Logic Line permite a comunicação com qualquer hardware externo,
como impressoras fiscais, leitores e impressoras de código de barra, etc.
- O Logic Line permite a chamada de programas externos por dentro dos
sistemas desenvolvidos, tornando as aplicações ainda mais abrangentes.
- Muitos outros recursos.
Você terá a melhor ferramenta de criação de sistemas, com o melhor preço,
e o melhor atendimento.
facilitando o aprendizado rápido.


Após o depósito, envie-nos um email com os seguintes dados:

---
Nome ou Razão Social :
Endereço :
Bairro   :
Cidade   :
Estado(UF)   :
CEP  :
Telefone :
Telefone 2(opcional) :
Email:
Email 2(opcional):
Pessoa para contato  :
Data do depósito: __/__/2019
---

Conte sempre com a gente.

Abraços dos amigos da


Corbett Software
Os melhores programas desde 1998

WhatsApp/Telefone:
22-99788-1694
Skype:
corbettsoftware



Bug#918987: transition: ode

2019-01-13 Thread Leopold Palomo-Avellaneda
El 13/1/19 a les 15:52, Emilio Pozuelo Monfort ha escrit:
> On 11/01/2019 18:09, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>>
>> On 11/01/2019 15:17, Leopold Palomo-Avellaneda wrote:
>>> Subject: transition: ode
>>> Package: release.debian.org
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> Severity: normal
>>>
>>> Dear release team,
>>>
>>> I would like to ask a transition slot for the ode library. Upstream 
>>> published a
>>> new version with a soname bump. The affected packages can be build without 
>>> any
>>> problem with the new version (I did it in an pbuilder environment).
>>>
>>> Please accept with transition slot. I know that is too close to Buster 
>>> freeze.
>>
>> Go ahead.
> 
> And your package fails (and was already failing) to build on several release
> architectures. You should have fixed that before requesting a transition slot.
> 
> Please look at those failures:
> 
> https://buildd.debian.org/status/package.php?p=ode
> 

First of all I'm so sorry. I didn't check the build of the package
because I thought that it was built. I was more worried about the
dependencies than the package itself. Upstream told me the there was no
important changes. I check specially ABI changes.

In any case, after I notice the problem I worked on. In some archs there
was a problem in autotest, and in others an assert that for an check
from upstream. The problem was in non common archs.

I pushed a new version of the package yesterday night solving the issue
in some archs and this morning I have pushed another version of the
package with the patches sent by upstream. Also, some people in
#debian-mentors helped me in this issue.

Now, it builds in all the archs expect ia64 because some dependencies,
not the package itself.

I can only say this...


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature


Bug#918308: transition: botan

2019-01-13 Thread GCS
Hi Emilio,

On Mon, Jan 7, 2019 at 6:08 PM Emilio Pozuelo Monfort  wrote:
> On 04/01/2019 23:08, Laszlo Boszormenyi (GCS) wrote:
> > It's a small transition with only three packages: biboumi,
> > libqtshadowsocks and qtcreator. All three build fine with
> > this botan release as well.
>
> Go ahead.
 Uploaded and even migrated to Buster, but just realized that I don't
see the binNMUs.
Meanwhile botan 2.9.0 was released[1], packaged and uploaded to
experimental as it contains a soname change again and fixes a security
issue. Also contain many other fixes to prevent side channel attacks.
Of course, the dependencies still build fine with this release as
well.
Is it allowed to further update an ongoing transition?

Regards,
Laszlo/GCS
[1] https://botan.randombit.net/news.html#version-2-9-0-2019-01-04



Processed: Reopen Bug 915667

2019-01-13 Thread Debian Bug Tracking System
Processing control commands:

> reopen -1
Bug #915667 {Done: Boyuan Yang } [release.debian.org] 
stretch-pu: package pdns-recursor/4.0.4-1+deb9u4
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions fcitx5/0~20181128+ds1-1~exp1.

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



Bug#915667: Reopen Bug 915667

2019-01-13 Thread Boyuan Yang
Control: reopen -1

Sorry for closing this bug by mistake. Reopening it now.

--
Regards,
Boyuan Yang



Bug#919218: non-transition: libqt5gui5-gles

2019-01-13 Thread Dmitry Shachnev
Package: release.debian.org

Dear Release team,

In Qt/KDE team, we have recently been working on Qt packages built
with OpenGL ES support. This is what most participants of the Qt OpenGL
thread [1] expressed their wish for.

The main idea is that there is now a libqt5gui5-gles package (and,
in future, libqt5quick5-gles and some others) that can be installed
instead of their non-gles equivalents and provide mostly the same API.
It is described in more details in README.Debian [2].

However, in order for this scheme to work properly, we need to rebuild
all packages depending on libqt5gui5 to gain a new dependency on
libqt5gui5 | libqt5gui5-gles (they will get it automatically from the
symbols file if they do not use any desktop OpenGL specific ABI).

This is not a regular transition because the packages can be rebuilt
at any time, in any order, and there are no testing migrations involved.

Would such a rebuild be possible? If yes, can we plan for it to happen
after the freeze? Or maybe it's even possible to do it now?

Ben file:

title = "libqt5gui5-gles";
is_affected = .depends ~ "libqt5gui5";
is_good = .depends ~ "libqt5gui5-gles";
is_bad = .depends ~ "libqt5gui5" & ! .depends ~ "libqt5gui5-gles";

[1]: https://lists.debian.org/debian-arm/2018/11/msg00021.html
[2]: 
https://salsa.debian.org/qt-kde-team/qt/qtbase/blob/gles/master/debian/README.Debian

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#915667: marked as done (stretch-pu: package pdns-recursor/4.0.4-1+deb9u4)

2019-01-13 Thread Debian Bug Tracking System
Your message dated Sun, 13 Jan 2019 20:10:37 +
with message-id 
and subject line Bug#915667: fixed in fcitx5 0~20181128+ds1-1~exp1
has caused the Debian Bug report #915667,
regarding stretch-pu: package pdns-recursor/4.0.4-1+deb9u4
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.)


-- 
915667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915667
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Team,

I've prepared an update for pdns-recursor, which fixes some CVE issues.
As they are not critical bugs, security and me have agreed to do this via
a normal stable update, if that's okay with you too.

Sec bug: #913162

Thanks,
Chris

diff -Nru pdns-recursor-4.0.4/debian/changelog 
pdns-recursor-4.0.4/debian/changelog
--- pdns-recursor-4.0.4/debian/changelog2017-12-07 12:40:02.0 
+
+++ pdns-recursor-4.0.4/debian/changelog2018-11-10 16:05:33.0 
+
@@ -1,3 +1,9 @@
+pdns-recursor (4.0.4-1+deb9u4) stretch-security; urgency=high
+
+  * Security upload for CVE-2018-10851 CVE-2018-14626 CVE-2018-14644 (Closes: 
#913162).
+
+ -- Chris Hofstaedtler   Sat, 10 Nov 2018 16:05:33 +
+
 pdns-recursor (4.0.4-1+deb9u3) stretch-security; urgency=high
 
   * Security upload, including fix for CVE-2017-15120.
diff -Nru pdns-recursor-4.0.4/debian/patches/CVE-2018-10851-rec-4.0.8.patch 
pdns-recursor-4.0.4/debian/patches/CVE-2018-10851-rec-4.0.8.patch
--- pdns-recursor-4.0.4/debian/patches/CVE-2018-10851-rec-4.0.8.patch   
1970-01-01 00:00:00.0 +
+++ pdns-recursor-4.0.4/debian/patches/CVE-2018-10851-rec-4.0.8.patch   
2018-11-10 16:05:33.0 +
@@ -0,0 +1,396 @@
+diff -ru pdns-recursor-4.0.8.orig/dnsparser.cc pdns-recursor-4.0.8/dnsparser.cc
+--- pdns-recursor-4.0.8.orig/dnsparser.cc  2017-12-11 11:38:52.0 
+0100
 pdns-recursor-4.0.8/dnsparser.cc   2018-10-10 10:29:54.182145934 +0200
+@@ -121,54 +121,42 @@
+   return ret;
+ }
+ 
+-DNSRecordContent* DNSRecordContent::mastermake(const DNSRecord , 
+-   PacketReader& pr)
++std::shared_ptr DNSRecordContent::mastermake(const 
DNSRecord , 
++   PacketReader& 
pr)
+ {
+   uint16_t searchclass = (dr.d_type == QType::OPT) ? 1 : dr.d_class; // class 
is invalid for OPT
+ 
+   typemap_t::const_iterator i=getTypemap().find(make_pair(searchclass, 
dr.d_type));
+   if(i==getTypemap().end() || !i->second) {
+-return new UnknownRecordContent(dr, pr);
++return std::make_shared(dr, pr);
+   }
+ 
+   return i->second(dr, pr);
+ }
+ 
+-DNSRecordContent* DNSRecordContent::mastermake(uint16_t qtype, uint16_t 
qclass,
+-   const string& content)
++std::shared_ptr DNSRecordContent::mastermake(uint16_t 
qtype, uint16_t qclass,
++   const string& 
content)
+ {
+   zmakermap_t::const_iterator i=getZmakermap().find(make_pair(qclass, qtype));
+   if(i==getZmakermap().end()) {
+-return new UnknownRecordContent(content);
++return std::make_shared(content);
+   }
+ 
+   return i->second(content);
+ }
+ 
+-std::unique_ptr DNSRecordContent::makeunique(uint16_t 
qtype, uint16_t qclass,
+-   const string& content)
+-{
+-  zmakermap_t::const_iterator i=getZmakermap().find(make_pair(qclass, qtype));
+-  if(i==getZmakermap().end()) {
+-return std::unique_ptr(new 
UnknownRecordContent(content));
+-  }
+-
+-  return std::unique_ptr(i->second(content));
+-}
+-
+-
+-DNSRecordContent* DNSRecordContent::mastermake(const DNSRecord , 
PacketReader& pr, uint16_t oc) {
++std::shared_ptr DNSRecordContent::mastermake(const 
DNSRecord , PacketReader& pr, uint16_t oc) {
+   // For opcode UPDATE and where the DNSRecord is an answer record, we don't 
care about content, because this is
+   // not used within the prerequisite section of RFC2136, so - we can simply 
use unknownrecordcontent.
+   // For section 3.2.3, we do need content so we need to get it properly. But 
only for the correct Qclasses.
+   if (oc == Opcode::Update && dr.d_place == DNSResourceRecord::ANSWER && 
dr.d_class != 1)
+-return new UnknownRecordContent(dr, pr);
++return std::make_shared(dr, pr);
+ 
+   uint16_t searchclass = (dr.d_type == QType::OPT) ? 1 : dr.d_class; // class 
is invalid for OPT
+ 
+   typemap_t::const_iterator 

Bug#915721: transition: opencv

2019-01-13 Thread Emilio Pozuelo Monfort
On 06/01/2019 05:46, Mo Zhou wrote:
> Hi,
> 
> Any updates? Transition freeze is close. The current version of OpenCV
> (3.2.0) in Sid is quite ancient (Dec 23, 2016).
> 
> mips{,64}el buildd are again lagging behind the other architectures for
> the last binNMU. And before any ack I'm not going to manually build it
> again on mips box since I'm not buildd.
> 
> Builds for 3.4.5+dfsg-1~exp1 were successful so I don't expect any
> problem for 3.4.5+dfsg-1~exp1+b1 .

What is the status with the rdeps? I looked at two bugs and they worry me:

#915544 suggests the OpenCV C API is broken, and ffmpeg solved it by disabling
ffmpeg support altogether.

#915709 seems to point to the same brokenness.

The way it looks, I don't think we can go ahead with this at this stage.

Cheers,
Emilio



Bug#918308: transition: botan

2019-01-13 Thread Emilio Pozuelo Monfort
On 13/01/2019 18:52, László Böszörményi (GCS) wrote:
> Hi Emilio,
> 
> On Mon, Jan 7, 2019 at 6:08 PM Emilio Pozuelo Monfort  
> wrote:
>> On 04/01/2019 23:08, Laszlo Boszormenyi (GCS) wrote:
>>> It's a small transition with only three packages: biboumi,
>>> libqtshadowsocks and qtcreator. All three build fine with
>>> this botan release as well.
>>
>> Go ahead.
>  Uploaded and even migrated to Buster, but just realized that I don't
> see the binNMUs.

Oh, I missed those.

> Meanwhile botan 2.9.0 was released[1], packaged and uploaded to
> experimental as it contains a soname change again and fixes a security
> issue. Also contain many other fixes to prevent side channel attacks.
> Of course, the dependencies still build fine with this release as
> well.
> Is it allowed to further update an ongoing transition?

Normally that would be a different transition but since I haven't scheduled the
binNMUs and due to the security fixes and to the good package state, let's go
ahead with 2.9.0.

Emilio



Bug#918750: transition: simbody

2019-01-13 Thread Emilio Pozuelo Monfort
On 12/01/2019 21:13, Jose Luis Rivero wrote:
> simbody 3.6.1+dfsg-5 has been uploaded to unstable.

It is failing on mips as some tests are timing out.

https://buildd.debian.org/status/package.php?p=simbody

Cheers,
Emilio

> 
> On Thu, Jan 10, 2019 at 3:30 PM Jose Luis Rivero 
> wrote:
> 
>> Hello Emilio:
>>
>> There were a couple of patches: one to fix the architecture detection
>> which fixed most of the BSD and ppc friends. The other, as you said, is not
>> properly a patch but it tries to workaround about problems (most of them on
>> i386) that I'm unable to diagnostic and will require my interaction with
>> upstream. Note that i386 is still failing so the workaround does not change
>> too much the status of the ports. I agree with your conclusions, the change
>> improves current situation in sid but the whole thing needs more work.
>>
>> With respect to gazebo, I launched ratt against this new version and seems
>> to be happy:
>>
>> https://build.osrfoundation.org/job/debian-ratt-builder/19/consoleFull#console-section-8
>>
>> Thanks,
>>  Jose.
>>
>> On Thu, Jan 10, 2019 at 1:58 PM Emilio Pozuelo Monfort 
>> wrote:
>>
>>> Control: tags -1 confirmed
>>>
>>> On 10/01/2019 12:16, Jose Luis Rivero wrote:
 On Wed, Jan 9, 2019 at 10:11 AM Emilio Pozuelo Monfort <
>>> po...@debian.org>
 wrote:

> On 09/01/2019 01:27, Jose Luis Rivero wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Dear release team:
>>
>> simbody 3.6.1+dfsg-1 is now in experimental, we can start the
>>> transition
>> for the existing package in the archive currently using it.
>> The following source package need to be rebuild:
>>
>> gazebo 9.6.0-1
>>
>> I think that in terms of 'ben' lingo, the transition has the following
>> parameters:
>>
>> Affected: .depends ~
> /\b(libsimbody3\.6|libsimbody3\.5v5|libsimbody3\.5v5\-dbg)\b/
>> Good: .depends ~ /\b(libsimbody3\.6)\b/
>> Bad: .depends ~ /\b(libsimbody3\.5v5|libsimbody3\.5v5\-dbg)\b/
>>
>> Sorry for sending this close to the freeze but it will kill the 2 RC
> bugs pending on Simbody.
>> Please schedule binNMUs for gazebo packages on all architectures.
>
> simbody failed to build on several architectures:
>
>
>>> https://buildd.debian.org/status/package.php?p=simbody=experimental
>
> Please fix that before we consider starting the transition.


 I've upload simbody 3.6.1+dfsg-3 which:
  - fixed: all, mips, powerpc, powerpcspe, ppc64el, ppc64
  - waiting but probably fixed: mipsel, mips64el, kfreebad-amd64
  - still failing: i386, hurd-i386

 The build is failing on i368 (will require a bit more of work) but it is
 already failing on unstable so there is a big gain on architectures
 supported (+6 at least) and no regression as far as I can say.
>>> My concern here is that the way to fix the build on all those
>>> architectures was
>>> by ignoring the failing tests. If the test cases themselves are buggy then
>>> that's fine (though it'd be good to forward that upstream and get the
>>> tests
>>> fixed). However the tests may be failing due to bugs in the underlying
>>> library
>>> code, in which case ignoring them is not really a fix.
>>>
>>> In any case the situation in sid is bad too as you said and I imagine
>>> that the
>>> version in testing (which seems quite similar to the one in sid) would be
>>> affected by these build failure problems too, so I guess we should go
>>> ahead with
>>> this version.
>>>
>>> BTW I assumed that gazebo builds fine against this new simbody, is that
>>> right?
>>> If not, that is obviously a blocker. If it builds fine, then go ahead and
>>> look
>>> into the remaining build issues.
>>>
>>> Cheers,
>>> Emilio
>>>
>>
> 



Bug#919022: marked as done (is it a transition if the only rdep is already broken: libgpuarray)

2019-01-13 Thread Debian Bug Tracking System
Your message dated Sun, 13 Jan 2019 15:50:36 +0100
with message-id <42e0b8e6-75fb-23cb-b001-39cd6b75c...@debian.org>
and subject line Re: Bug#919022: is it a transition if the only rdep is already 
broken: libgpuarray
has caused the Debian Bug report #919022,
regarding is it a transition if the only rdep is already broken: libgpuarray
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.)


-- 
919022: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919022
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I have just been given permission to take over libgpuarray.

I would like to update it from 0.6.9 to 0.7.6, which bumps SONAME from 2 
to 3 and is described by upstream as including API changes [0].


The only other Debian package that (optionally) uses libgpuarray is 
theano.  This part of theano *only* works with the *new* libgpuarray, 
i.e. is currently broken [1].


libgpuarray is currently not in testing because it is RC buggy, but that 
can and will be fixed with or without going to the new upstream version.


I can prepare this tonight, but not necessarily upload it as I am only a 
DM and don't have rights for this package.


theano uses the Python interface to libgpuarray, so it will not need to 
be binNMUd and there is no real point in having a formal transition tracker.


[0] https://github.com/Theano/libgpuarray/releases
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901487
--- End Message ---
--- Begin Message ---
On 11/01/2019 21:28, Rebecca N. Palmer wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I have just been given permission to take over libgpuarray.
> 
> I would like to update it from 0.6.9 to 0.7.6, which bumps SONAME from 2 to 3
> and is described by upstream as including API changes [0].
> 
> The only other Debian package that (optionally) uses libgpuarray is theano. 
> This part of theano *only* works with the *new* libgpuarray, i.e. is currently
> broken [1].
> 
> libgpuarray is currently not in testing because it is RC buggy, but that can 
> and
> will be fixed with or without going to the new upstream version.
> 
> I can prepare this tonight, but not necessarily upload it as I am only a DM 
> and
> don't have rights for this package.
> 
> theano uses the Python interface to libgpuarray, so it will not need to be
> binNMUd and there is no real point in having a formal transition tracker.

With no rdeps and not being in testing, there's nothing for us to do here. Just
go ahead as there's no effective transition.

Emilio--- End Message ---


Processed: Re: Bug#918954: transition: yaz

2019-01-13 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 confirmed
Bug #918954 [release.debian.org] transition: yaz
Added tag(s) confirmed.

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



Bug#918954: transition: yaz

2019-01-13 Thread Emilio Pozuelo Monfort
Control: tags -1 confirmed

On 12/01/2019 08:36, Hugh McMaster wrote:
> On Fri, 11 Jan 2019 14:05:46 +0100, Emilio Pozuelo Monfort wrote:
>> So how did that rdep testing go?
> 
> I retested the small number of reverse build dependencies this
> afternoon. All built successfully with yaz 5.27.1 from experimental.

Go ahead then.

Emilio



Bug#918987: transition: ode

2019-01-13 Thread Emilio Pozuelo Monfort
On 11/01/2019 18:09, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 11/01/2019 15:17, Leopold Palomo-Avellaneda wrote:
>> Subject: transition: ode
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Severity: normal
>>
>> Dear release team,
>>
>> I would like to ask a transition slot for the ode library. Upstream 
>> published a
>> new version with a soname bump. The affected packages can be build without 
>> any
>> problem with the new version (I did it in an pbuilder environment).
>>
>> Please accept with transition slot. I know that is too close to Buster 
>> freeze.
> 
> Go ahead.

And your package fails (and was already failing) to build on several release
architectures. You should have fixed that before requesting a transition slot.

Please look at those failures:

https://buildd.debian.org/status/package.php?p=ode

Emilio



Processed: tagging 919148

2019-01-13 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 919148 + stretch
Bug #919148 [release.debian.org] RM: calendar-exchange-provider/3.9.0-4
Added tag(s) stretch.
> thanks
Stopping processing here.

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



Bug#915721: transition: opencv

2019-01-13 Thread M. Zhou
Hi pochu,

To make things explicit, do I still have chance to continue with the
opencv transition after the gdal one? And do I need to apply for
freeze exception for opencv?



Bug#919148: RM: calendar-exchange-provider/3.9.0-4

2019-01-13 Thread Mechtilde Stehmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

This version doesn't work with TB 60 which is in stable now.

There is a new package prepared for the next stable release: webext-tbsync

This package should be use now to connect to an Exchange Server with Tb
> 60.

---
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature