troca de chave gpg

[Herbert Fortes]

Olá,

Ontem decidi revogar minha chave gpg por acreditar
que ela não é mais segura e gerar uma nova.

https://pgp.key-server.io/pks/lookup?search=Herbert+Parentes+Fortes+Neto=on=vindex

Moro no Rio de Janeiro - RJ. Se alguém passar por
aqui e puder fazer a troca de assinatura de chaves
por favor entre em contato.



Abraço,
Herbert

Re: salsa.debian.org: merge requests and such

[Herbert Fortes]

On 12/11/2018 13:02, Ian Jackson wrote:

Colin Watson writes ("Re: salsa.debian.org: merge requests and such"):

Honestly, I think it's better for Debian as a whole that people should
be able to do that kind of bulk cleanup with absolutely minimal
friction,


I absolutely agree.

The disruption from this kind of thing is minimal, and clearly IMO
outweighs the benfit.

Ultimately whether to allow this is a matter for the maintainer but I
think maintainers shoudl be encouraged to allow it - even, to
encourage it.

And there should be clear guidance for other DDs on when and how to
exercise this authority.  That should include the level of confidence
that a DD should have before making such a commit; whether there
should be a `mass commit' d-devel review process; and whether such
changes should be accompanied by a changelog entry.



When I run 'gbp dch' everything goes to debian/changelog anyway.

But no problem. I am OK to 'Debian as a whole'.



Regards,
Herbert

Re: salsa.debian.org: merge requests and such

[Herbert Fortes]

On 10/11/2018 17:18, Phil Morrell wrote:

On Sat, Nov 10, 2018 at 10:36:53AM -0200, Herbert Fortes wrote:

On 09/11/2018 20:26, Colin Watson wrote:

I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)


The fix is good.

But why the new debian/changelog? It is a honest question.


It's just an alternative personal style. 


I have the same opinion.

I also think that if a package has a maintainer the maintainer's
personal style should be respected. That is the social thing
said before.

Do a fix is collab maint. Set my personal style in many other
packages that I am not directly responsible for is not.

I understand a minor cleanup that is done directly in the repository.
But doing a patch you pay attention to the fix.

Re: salsa.debian.org: merge requests and such

[Herbert Fortes]

On 09/11/2018 20:26, Colin Watson wrote:

On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:

Ian Jackson  writes:

Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):

Colin Watson  writes:

This seems like a little bit of an overreaction to somebody removing a
single redundant line from a control file, though.  Is moving it really
worth the added friction?


It's more a reaction to the "if you didn't want random commits onto
master, you shouldn't have put it under debian/" policy. I don't, so I
shouldn't have.


We're not talking about "random" commits, though, are we ?  We're
talking about a commit that a DD thought was very likely a good idea.
Were they wrong ?  It would be nice to have a proper reference.


The particular commit was fine (and had it come as a MR or bug report or
whatever I'd have had no problem with it at all).


I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)


The fix is good.

But why the new debian/changelog? It is a honest question.



Regards,
Herbert

Re: Please remove your obsolete repos from alioth *NOW*

[Herbert Fortes]

Em 31-05-2018 14:50, Alexander Wirt escreveu:

On Thu, 31 May 2018, Herbert Fortes wrote:


Hi,


On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote:

On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:

There it doesn't make sense to keep anything on alioth which is also on
salsa. Everything else gets archived for historical purposes.
Every repo that is on salsa and alioth will just waste ressources on the
archive host.


I did a QA for pygresql and put it on salsa[0]. But when
I tried to ssh git.debian.org I got a warning and "Permission
denied".

[0] - https://salsa.debian.org/debian/pygresql

git.debian.org is no more, you can access the remaining stuff of the host at
moszumanska.debian.org

Alex



Thanks

Re: Please remove your obsolete repos from alioth *NOW*

[Herbert Fortes]

Hi,


On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote:

On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:

There it doesn't make sense to keep anything on alioth which is also on
salsa. Everything else gets archived for historical purposes.
Every repo that is on salsa and alioth will just waste ressources on the
archive host.


I did a QA for pygresql and put it on salsa[0]. But when
I tried to ssh git.debian.org I got a warning and "Permission
denied".

[0] - https://salsa.debian.org/debian/pygresql



Regards,
Herbert

Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

Em 16-04-2018 17:16, Helmut Grohne escreveu:
> On Mon, Apr 16, 2018 at 04:14:21PM -0300, Herbert Fortes wrote:
>> Package python3-dj-static is on the dd-list. But I can import it.
>>
>> # on a bananapi
>>
>> $ python3
>> Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
>> [GCC 6.3.0 20170124] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import static # dependency
>>>>> import dj_static  # module
>>>>>
> 
> For most of these bug reports there exists a setting in which the
> modules can be imported. E.g. a significant chunk of them becomes
> importable after installing python3-pkg-resources.
> 
>> If I understood correct (about the test), please note the diff:
>>
>> python3-dj-static  # Debian package
>> dj_static  # module
>>
>> The package name uses '-' and the module '_'.
> 
> In my initial mail there is a draft.gz that contains the proposed bug
> reports. Searching for python3-dj-static yields:
> 
> | After installing python3-dj-static importing the module dj_static
> | into a python interpreter fails with the following error:
> | 
> | Traceback (most recent call last):
> |   File "", line 1, in 
> |   File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in 
> | from django.conf import settings
> | ModuleNotFoundError: No module named 'django'
> 
> So my heuristic did select the right module and it failed to import,
> because no dependency on python3-django was declared. Thus the bug
> report seems legitimate to me.
> 
-1 bug report. :)

running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Uploading dj-static_0.0.6-5.dsc
Uploading dj-static_0.0.6.orig.tar.gz
Uploading dj-static_0.0.6-5.debian.tar.xz
Uploading dj-static_0.0.6-5_amd64.buildinfo
Uploading dj-static_0.0.6-5_amd64.changes

Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

> 
> In my initial mail there is a draft.gz that contains the proposed bug
> reports. Searching for python3-dj-static yields:
> 
> | After installing python3-dj-static importing the module dj_static
> | into a python interpreter fails with the following error:
> | 
> | Traceback (most recent call last):
> |   File "", line 1, in 
> |   File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in 
> | from django.conf import settings
> | ModuleNotFoundError: No module named 'django'
> 
> So my heuristic did select the right module and it failed to import,
> because no dependency on python3-django was declared. Thus the bug
> report seems legitimate to me.
> 

That is true. The package does not make sense without Django. It is
a Django middleware. 

I also checked manually in a chroot without Django and got an 'ImportError'.

I will fix the dependency.



Regards,
Herbert

Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

Hi,

Em 15-04-2018 15:56, Helmut Grohne escreveu:
> Hi,
> 
> I was surprised to find a python module that failed to import thinking
> that our qa would catch this. So I wondered how many other python
> modules would fail to import and started a little yak shaving journey.
> 
> It turns that this happens for 251 python modules. Since failure to
> import the main module of a python library indicates that the modules
> doesn't work at all, I propose to file this at severity serious.
> 
> Actually, there is autodep8 at ci.debian.net testing this already. It
> has a whitelist
> (https://salsa.debian.org/ci-team/debian-ci-config/blob/master/cookbooks/debci/files/default/whitelist-python.txt)
> of around 800 packages opting in to import testing. Unfortunately, the
> results do not seem to be synced into tracker.d.o. The main difficulty
> is determining the name of the python module. Sometimes capitalization
> differs from the package name. Other times a completely different name
> is used. Thus I am attaching a genlist.py that tries to compute the
> module name and it succeeds in about 4300 packages.
> 
> Thus I tried installing and importing all of these and figured that 251
> packages would fail. The process of installing and importing is rather
> simple and implemented in autodep8 already, so I'm not attaching my
> crude hacks here. Nonetheless I am attaching a draft of the proposed bug
> reports since each of them includes a specific error. I also include a
> dd-list of affected packages.
> 
> The most common issues is missing dependencies. Very often,
> pkg_resources is missing. Also six, numpy, tkinter and distutils are
> missing several times. A fair number of strange exceptions is included
> as well. When dealing with C extensions, we are faced with two
> segmentation faults, one assertion failure and three missing symbols.
>

Package python3-dj-static is on the dd-list. But I can import it.

# on a bananapi

$ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import static # dependency
>>> import dj_static  # module
>>> 

If I understood correct (about the test), please note the diff:

python3-dj-static  # Debian package
dj_static  # module

The package name uses '-' and the module '_'.

Re: Curitiba sediará a DebConf19

[Herbert Fortes]

Em 28-01-2018 15:59, Paulo Henrique de Lima Santana escreveu:
> Olá,
> 
> Na última quinta-feira (25/01/18) foi confirmado que Curitiba sediará a 
> DebConf19 - Conferência Mundial dos(as) Desenvolvedores(as) do Projeto 
> Debian, em 2019.
> A data ainda será confirmada, mas a previsão é que aconteça em julho no 
> campus central da UTFPR - Universidade Tecnológica Federal do Paraná.
> 
> Esta será a segunda vez que o Brasil sedia uma edição da DebConf. A quinta 
> edição (DebConf4) aconteceu de 26 de maio a 2 de junho de 2004 em Porto 
> Alegre.
> 
> Ontem (27/01) fizemos um encontro para começar a discutir a organização. 
> Esperamos no futuro contar com a ajuda de mais pessoas, mesmo que a 
> distância, para que possamos fazer um grande evento!
> https://imgur.com/a/pKFCv
> 
> Se você quiser conhecer o local onde acontecerá a DebConf19 venha para a 
> MiniDebConf Curitiba 2018 que acontecerá de 11 a 14 de abril :-)
> https://minidebconf.curitiba.br
> 
> Abraços,
> 

Parabéns!

dj-database-url

[Herbert Fortes]

# Originaly from 06-18-2017
# Today Cc: debian-devel

Hi Marco Bardelli,

Are you still packaging dj-database-url for
Debian ?

I put dj-database-url on Debian some days ago as 
a NEW package and today, I was doing the repository for
it. But the repository already exists. And your name is the 
last one that did a 'git push'. You can check here[0]:

https://anonscm.debian.org/cgit/collab-maint/dj-database-url.git/

How is the situation nowadays? The package I did was
accepted[1], but maybe it already exists on Debian.

[1] - https://packages.qa.debian.org/d/dj-database-url.html

Can I use the repository ?



Regards,
Herbert

Re: últimos DM e DDs brasileiros

[Herbert Fortes]

Olá,

O Giovani Jova2 teve 'am approved' a uns dez dias atrás.

https://nm.debian.org/public/process/giovani

Daqui a pouco deve ser criada a conta dele.



Abraço,
Herbert

Re: Res: bug squashing party virtual no Debian Day

[Herbert Fortes]

> 
> > Em 29 de julho de 2016 14:47, Antonio Terceiro  
> > escreveu:
> > > o Debian Day é no dia 13 de agosto.
> > > 
> > > https://wiki.debian.org/BSP
> > > https://wiki.debian.org/BSP/BeginnersHOWTO
> > > https://wiki.debian.org/HostingBSP
> > > 
> > > a idéia inicial seria fazer entre 10:00 e 16:00, coordenando via IRC, no
> > > #debian-devel-br (historicamente ficamos nesse canal, mas
> > > não-brasileiros são mais do que bem-vindos!)
> > > 
> > > eu estarei disponível durante nesse tempo todo pra revisar
> > > pacotes/patches (idealmente consertando bugs, RC de preferência) em
> > > "tempo real", via IRC e/ou outra forma que não envolva software
> > > não-livre, e fazer uploads. Outros com permissão de upload podem e devem
> > > ajudar.
> > > 
> > > quem estiver numa cidade que tenha algum evento no Debian Day poderia
> > > incluir isso na programação, e incentivar pessoas interessadas em
> > > participar. ou se ainda não tem programação de Debian Day, pode
> > > organizar um nó local da BSP como sendo _o_ evento do Debian Day, ao
> > > invés de um dia inteiro das boas e velhas palestras manjadas. ;-)
> > > 
> > > quem estiver isolado no mapa pode participar de casa também.
> > > 
> > > quem topa?
> > > 

Também gostei da ideia.



abraço,
-- Herbert Parentes Fortes Neto (hpfn)
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: ITA: lostirc -- simple gtk-based IRC client

[Herbert Fortes]

> > P: lostirc source: debian-watch-may-check-gpg-signature
> > E: lostirc: binary-or-shlib-defines-rpath usr/bin/lostirc 
> > /usr/lib/x86_64-linux-gnu
> > I: lostirc: hardening-no-fortify-functions usr/bin/lostirc
> > 
> > Sobre o hardening-no-fortify-functions, o 'blhc --all'
> > não retorna nada. E o config.log tem:
> > 
> > ac_cv_env_CPPFLAGS_value='-Wdate-time -D_FORTIFY_SOURCE=2'
> > 
> > Acho que não tem problema. Um lintian-overrides pode
> > ser usado.
> 
> Se o binário final não tem as features de hardening, tem alguma coisa
> quebrada no build system que está impedindo as flags certas de chegarem
> na linha de comando do compilador. a não ser que a feature esteja lá e
> seja um bug do lintian por não conseguir detectar que o binário na
> verdade _tem_ todas as features de hardening, adicionar um override pra
> calar a boca do lintian não é certo (se de fato fosse um bug no lintian,
> você até poderia colocar um override, mas só depois de reportar um bug
> contra o lintian).

O blhc não reclama, mas o hardening-check sim.

Não sei se é válido, mas fiz o seguinte:

$ grep g++ *.build | grep -v FORTIFY


/bin/bash ../../libtool --mode=link g++  -g -O2 -fPIE -fstack-protector-strong 
-Wformat -Werror=format-security -Wall  -fPIE -pie -Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed -o lostirc  main.o
MainWindow.o MainNotebook.o Tab.o Prefs.o ServerWindow.o GuiCommands.o Entry.o 
StatusBar.o TextWidget.o NickList.o DCCList.o ../libirc/libirc.a -lgtkmm-2.4 
-lgtk-x11-2.0 -lgdkmm-2.4 -lgiomm-2.4 -lgtk-
x11-2.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lfontconfig 
-lfreetype -latkmm-1.6 -latk-1.0 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 
-lsigc-2.0 -lpangocairo-1.0 -lpango-1.0
-lgobject-2.0 -lglib-2.0 -lcairo 
g++ -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-Wall -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -o lostirc 
main.o MainWindow.o MainNotebook.o Tab.o Prefs.o
ServerWindow.o GuiCommands.o Entry.o StatusBar.o TextWidget.o NickList.o 
DCCList.o  ../libirc/libirc.a -lgtkmm-2.4 -lgdkmm-2.4 -lgiomm-2.4 -lgtk-x11-2.0 
-lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lgio-2.0
-lpangoft2-1.0 -lfontconfig /usr/lib/x86_64-linux-gnu/libfreetype.so 
-latkmm-1.6 -latk-1.0 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 
-lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0
-lcairo -Wl,--rpath -Wl,/usr/lib/x86_64-linux-gnu -Wl,--rpath 
-Wl,/usr/lib/x86_64-linux-gnu

-D_FORTIFY_SOURCE=2 não aparece em dois momentos.



abraço,
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: ITA: lostirc -- simple gtk-based IRC client

[Herbert Fortes]

Olá,

> P: lostirc source: debian-watch-may-check-gpg-signature
> E: lostirc: binary-or-shlib-defines-rpath usr/bin/lostirc 
> /usr/lib/x86_64-linux-gnu
> I: lostirc: hardening-no-fortify-functions usr/bin/lostirc
> 
> Sobre o hardening-no-fortify-functions, o 'blhc --all'
> não retorna nada. E o config.log tem:
> 
> ac_cv_env_CPPFLAGS_value='-Wdate-time -D_FORTIFY_SOURCE=2'
> 
> Acho que não tem problema. Um lintian-overrides pode
> ser usado. Alguém mais experiente pode dizer algo
> mais.
> 

O blhc --all do xmlrpc-c retorna alguma coisa e o
hardening=+all dá erro. Então fiz uns patches.

O xmlrpc-c usa um arquivo common.mk e acabei fazendo
um patch para ele para implementar o hardening. Não
consegui de outra forma. Acabei fazendo outro patch
para um subdiretório. Ainda falta o 'hardening-no-pie',
que dá erro com relação a 'fPIC'.

Não acho que seja o caso do lostirc. Mais pela
curiosidade.



abraço,
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: ITA: lostirc -- simple gtk-based IRC client

[Herbert Fortes]

Olá,

Em Sex, 2016-07-22 às 15:41 -0300, Samuel Henrique escreveu:
> Olá pessoal,
> 
> Acredito que o problema de hardening [I: lostirc: 
> hardening-no-fortify-functions usr/bin/lostirc], seja algo no Makefile, 
> baixei o pacote aqui e não encontrei nada numa rápida verificação, talvez
> analisando melhor o problema apareça.
> 
> O Eriberto escreveu um guia para lidar com alguns problemas de hardening 
> desse tipo, acredito que você já conheça, mas irei colocá-lo aqui[1], para 
> futura referência.
> 
> Imagino que alguma coisa no Makefile esteja alterando alguma flag repassada, 
> você já verificou essa possibilidade?
> 
> [1]http://eriberto.pro.br/blog/?p=

Não estou conseguindo acessar o blog. Estou com umas
dúvidas em outro pacote.

[...]

> > Vou subir para o mentors para que possa ver o que já foi feito.
> > 
> > Obrigado.
> > 
> > subindo 
> > 
> > https://mentors.debian.net/debian/pool/main/l/lostirc/lostirc_0.4.6-5.dsc
> > 

Dei uma primeira olhada agora. Tem esses lintian:

P: lostirc source: debian-watch-may-check-gpg-signature
E: lostirc: binary-or-shlib-defines-rpath usr/bin/lostirc 
/usr/lib/x86_64-linux-gnu
I: lostirc: hardening-no-fortify-functions usr/bin/lostirc

Sobre o hardening-no-fortify-functions, o 'blhc --all'
não retorna nada. E o config.log tem:

ac_cv_env_CPPFLAGS_value='-Wdate-time -D_FORTIFY_SOURCE=2'

Acho que não tem problema. Um lintian-overrides pode
ser usado. Alguém mais experiente pode dizer algo
mais.

Estou com algumas dúvidas sobre hardening também. Em
outro pacote. Amanhã falo sobre isso.



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: DebConf 2017

[Herbert Fortes]

Em Qui, 2016-07-21 às 15:22 -0300, Antonio Terceiro escreveu:
> On Thu, Jul 21, 2016 at 03:15:05PM -0300, Herbert Fortes wrote:
> > Olá,
> > 
> > Legal a idéia. Enquanto ela amadurece, vamos vendo se 
> > o Meirelles[0] deixa.
> > 
> > [0] - https://pt.wikipedia.org/wiki/Henrique_Meirelles
> > 
> > Como ver as acomodações ?
> 
> quem é colaborador do debian normalmente não precisa se preocupar com
> isso, pq a hospedagem e a alimentação são patrocinadas (i.e. grátis),
> bastando preencher os campos correspondentes na inscrição, quando chegar
> a época.

Então Montreal é logo ali.



regards,
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: ITA: lostirc -- simple gtk-based IRC client

[Herbert Fortes]

Olá Kretcheu,

> 
> estou adotando o pacote lostirc e estou com umas dúvidas e dificuldades, 
> alguém pode dar uma força?
> 
> O problema inicial é que o pacote não usa quilt e estou tentando converter.
> segui os procedimentos indicados em [1], mas o diff existente tem alterações 
> tanto no upstream como no diretório debian.
> [ meio confuso isso ] segundo as orientações devo separar as alterações.
> 
> Alguém tem uma dica de como fazer isso sem sofrimentos?
> 

Baixei o pacote para ver.

Acho que a parte de debian/ não tem com que
se preocupar (em termos de patch). Mas o debian/rules
é antigo.

A parte do upstream tem uns patches para fazer,
não deve ter como driblar isso.

Pode esclarecer mais a dúvida ?



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: DebConf 2017

[Herbert Fortes]

Olá,

Legal a idéia. Enquanto ela amadurece, vamos vendo se 
o Meirelles[0] deixa.

[0] - https://pt.wikipedia.org/wiki/Henrique_Meirelles

Como ver as acomodações ?



abraços,
-- Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: novo nome de projeto antigo

[Herbert Fortes]

> > > Atualiza para última versão de django-n* ? Ou
> > > deixa quieto ?
> > 
> > Enviei um email para o upstream domingo e estou
> > aguardando resposta.
> 
> eu acho que quando vc tiver essa reposta vc já pode subir o pacote você
> mesmo? ;-)
> 
> $ finger h...@db.debian.org
> uid=hpfn,ou=users,dc=debian,dc=org
> First name: Herbert Parentes
> Last name: Fortes Neto
> Email: Herbert Parentes Fortes Neto 
> Fingerprint: 6E2261AF92C150918518F94255256F28AC60611A
> Key block: finger hpfn/k...@db.debian.org


:)

signature.asc
Description: This is a digitally signed message part

Re: novo nome de projeto antigo

[Herbert Fortes]

> > 
> > nesse caso, a não ser que eu quisesse realmente adotar o pacote e não só
> > "fazer um QA", eu não faria isso. renomear um pacote é algo bem
> > intrusivo.
> > 
> > você pode fazer um NMU normal, só consertando a falha.
> 
> Ok. O pacote tem como dependência apenas
> python <<2.8. Vou dar uma olhada e ver o
> que posso fazer.
> 
> Além do bug aberto tem uns lintians que
> vou tentar tirar, já que o pacote está
> órfão.

Fiz a revisão. Vou dar a última olhada amanhã.
O debian/changelog está assim:

django-notification (0.1.5-4) UNRELEASED; urgency=medium

  * QA upload.
  * DH_LEVEL: 9
  * debian/copyright:
      - format 1.0
      - updated
  * debian/control:
  - Build-Depends-Indep field removed.
  - python-all added to Build-Depends.
  - dh-python added to Build-Depends.
  - using X-Python-Version: >= 2.5
  - bump Standards-Version from 3.9.3 to 3.9.8
  - Vcs-* updated and using https.
  * debian/rules:
  - override_dh_clean added. (Closes: #681825)
  * debian/watch:
  - the project has a new name now. There is no need to create an
operational debian/watch file. Just putting an information that
the project has a new name.


Mas tem um problema. Deixei o debian/copyright para 
o fim. Ele informa que pegou o source em um endereço
diferente da homepage informada no debian/control.

Pela homepage[0] do projeto é informado o novo[1] nome
do projeto e não tem nada em releases. Pelo endereço
do debian/copyright[2] existem mais 9 releases após essa
do pacote Debian. Releases django-notifications

[0] - http://github.com/jtauber/django-notification/
[1] - https://github.com/pinax/pinax-notifications
[2] - https://pypi.python.org/pypi/django-notification/

Baixei a última versão de django-notification (2015-02-24)
e duas de pinax-notifications (12 Feb 2015 - 10 Dec 2015 última).
Veja que django-n* tem release 12 dias após pinax-n*. E pinax-n*
tem versão em 2013.

# Muito próximas as datas de release
$diff -Nau django-notification-1.3.3/AUTHORS pinax-notifications-1.3.1/AUTHORS
nada

diff -Nau django-notification-1.3.3/AUTHORS pinax-notifications-3.0.1/AUTHORS 
--- django-notification-1.3.3/AUTHORS   2015-02-10 21:20:13.0 -0200
+++ pinax-notifications-3.0.1/AUTHORS   2015-12-10 20:22:26.0 -0200
@@ -18,4 +18,4 @@
 * Sławek Ehlert
 * neelesh
 * Gaël Le Mignot
-* Eduardo O. Padoan
\ Falta o caracter nova linha no final do arquivo
+* Eduardo O. Padoan

Atualiza para última versão de django-n* ? Ou
deixa quieto ?



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: novo nome de projeto antigo

[Herbert Fortes]

Em Sáb, 2016-06-18 às 09:49 -0300, Antonio Terceiro escreveu:
> On Fri, Jun 17, 2016 at 03:46:03PM -0300, Herbert Fortes wrote:
> > Olá,
> > 
> > Escolhi fazer um QA para o pacote
> > django-notification[0]. Era apenas a
> > falhar de não construir duas vezes
> > seguidas. Último upload 2014. Mas o
> > projeto mudou de nome[1].
> > 
> > [0] - https://packages.qa.debian.org/d/django-notification.html
> > [1] - https://github.com/pinax/pinax-notifications
> > 
> > O certo é fazer um pacote do zero, com o 
> > debian/changelog contendo 'initial release' 
> > e o debian/control com 'Replaces|Breaks' ?
> > Seria um ITP ?
> 
> em princípio não precisaria, na verdade o ITP é só um mecanismo de
> controle de concorrência, ele é sempre recomendado, mas não é
> _obrigatório_.
> 
> nesse caso, a não ser que eu quisesse realmente adotar o pacote e não só
> "fazer um QA", eu não faria isso. renomear um pacote é algo bem
> intrusivo.
> 
> você pode fazer um NMU normal, só consertando a falha.

Ok. O pacote tem como dependência apenas
python <<2.8. Vou dar uma olhada e ver o
que posso fazer.

Além do bug aberto tem uns lintians que
vou tentar tirar, já que o pacote está
órfão.



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

signature.asc
Description: This is a digitally signed message part

Re: RFS: tzc -- Trivial Zephyr Client - NMU

[Herbert Fortes (hpfn)]

Em 11/06/2016 20:40, Antonio Terceiro escreveu:

On Sat, Jun 11, 2016 at 08:32:47PM -0300, Antonio Terceiro wrote:

On Fri, Jun 10, 2016 at 03:11:30PM -0300, Herbert Fortes wrote:

Mentors:
https://mentors.debian.net/package/tzc
https://mentors.debian.net/debian/pool/main/t/tzc/tzc_2.6.15-5.4.dsc


estou olhando


upload feito



Obrigado.



abraço,
Herbert

Re: RFS: tzc -- Trivial Zephyr Client - NMU

[Herbert Fortes]

Olá,

> Não consegui usar o cowbuilder. Mesmo recriando a
> imagem tenho esse erro: (em outro pacote o mesmo
> erro):

Resolvido. cowbuilder ok.



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

Re: pacote tzc

[Herbert Fortes]

Olá Fernando,

> Bom dia, Herbert.
> 
> Desculpe pela intromissão, mas dei uma pesquisada na sua dúvida.

Obrigado pela ajuda.

> 
> 
> On 06/07/2016 05:11 PM, Herbert Fortes (hpfn) wrote:
> > Olá,
> >
> > Estou preparando um NMU para o pacote tzc. Último
> > upload do mantenedor em 2005. Este é o quarto.
> >
> > Tem dois lintian sobre hardening. Se colocar
> > hardening=+all no debian/rules o pacote não
> > constrói. Então fiz:
> >
> >   - bindnow. Tirei colocando no debian/rules:
> > export DEB_BUILD_MAINT_OPTIONS := hardening=+bindnow
> >   - pie: Alterei o Makefile adicionando as opções:
> >  -fPIE -pie -O2 -fstack-protector-strong -Wformat
> >
> > Assim o pacote constrói sem os dois lintians. O complemento
> > '-O2 -fstack-protector-strong -Wformat' é porque o 'blhc' reclama.
> > Ele ainda reclama de '-Werror=format-security', mas se isso
> > for adicionado o pacote não constroi:
> >
> > gcc -g -O -Wall -DINTERREALM-fPIE -pie -O2 -fstack-protector-strong 
> > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o 
> > tzc.o tzc.c
> > tzc.c: In function ‘check’:
> > tzc.c:390:7: error: format not a string literal and no format arguments 
> > [-Werror=format-security]
> > com_err(__FILE__, e, s);
> > ^
> > tzc.c: In function ‘warn’:
> > tzc.c:398:7: error: format not a string literal and no format arguments 
> > [-Werror=format-security]
> > com_err(__FILE__, e, s);
> > ^
> > tzc.c: In function ‘send_zgram_to_one’:
> > tzc.c:713:33: error: format not a string literal and no format arguments 
> > [-Werror=format-security]
> > com_err(__FILE__, retval, bfr);
> >   ^
> > cc1: some warnings being treated as errors
> > : recipe for target 'tzc.o' failed
> >
> > Acho que 'com_err' é do pacote comerr-dev.
> >
> > Tem solução ? Li isso[0], mas o arquivo é de outro
> > pacote.
> >
> > [0] -https://fedoraproject.org/wiki/Format-Security-FAQ
> Aparentemente é mesmo o que está descrito nesse FAQ. A segunda resposta 
> para esta pergunta do stackoverflow [1] dá um bom exemplo dessa prática.
> 
> [1] 
> http://stackoverflow.com/questions/9707569/c-array-warning-format-not-a-string-literal
> 
> Nesse caso específico, em `man com_err`:
> void com_err (const char *whoami, long code, const char *format, ...);
> 
> Baseado na descrição:
> "(...) and  a  string produced using the format string and any following 
> arguments, in the same style as fprintf(3)."
> 
> Eu fiz alguns testes colocando o terceiro argumento de com_err das 
> seguintes formas:
> - string literal:
>  com_err(__FILE__, e, "This is an error with string literal");
> 
> - string de formatação
>  com_err(__FILE__, e, "%s", s);
> 
> Código do teste:
> 
> //test_file.c
> #include 
> #include 
> #include 
> 
> int main (){
>  char s[20];
>  int e = 0;
> 
>  strcpy( s, "This is an error");
> 
>  com_err(__FILE__, e, "%s", s);
>  com_err(__FILE__, e, "This is an error with string literal");
> }
> 
> Compilação e execução (não houve erros ou warnings):
> 
> $ gcc -g -O2 -Wall -fPIE -pie -fstack-protector-strong -Wformat 
> -Werror=format-security -lcom_err test_file.c -o test_file
> $ ./test_file
> test_file.c: This is an error
> test_file.c: This is an error with string literal
> 
> Concluindo, creio que no caso do tzc, uma saída viável seria implementar 
> a utilização do com_err com a formatação.

Vou ver aqui agora. Mas estou meio em dúvida. Tive uma
situação semelhante, com o libgphoto2, tempos atrás. E
o upstream contornou de forma diferente. Fez dois patches[0]
de tamanhos considerável. (caso tenha interesse - no_sprintf_chdk*)

[0] - 
https://anonscm.debian.org/cgit/pkg-phototools/libgphoto2.git/commit/?id=14e8b99a0872a2e4d89ca278a4ab6778f790b80f

> 
> > O debian/rules:
> > #!/usr/bin/make -f
> >
> > #export DH_VERBOSE=1
> >
> > export DEB_BUILD_MAINT_OPTIONS := hardening=+bindnow #,+pie
> >
> > ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
> > CFLAGS += -g
> > endif
> > ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
> > INSTALL_PROGRAM += -s
> > endif
> >
> > %:
> > dh $@
> >
> > Para onde vai a 'INSTALL_PROGRAM' ? O pacote não
> > tem repositório, mas ela não aparece em nenhum outro
> > lugar.
> Eu não encontrei nada muito relevante com relação a isso :(

Obrigado mesmo assim.



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

RFS: tzc -- Trivial Zephyr Client - NMU

[Herbert Fortes]

Olá,

> > ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
> > CFLAGS += -g
> > endif
> > ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
> > INSTALL_PROGRAM += -s
> > endif
> > 
> > %:
> > dh $@
> > 
> > Para onde vai a 'INSTALL_PROGRAM' ? O pacote não
> > tem repositório, mas ela não aparece em nenhum outro
> > lugar.
> 
> INSTALL_PROGRAM é uma variável que é definida no Makefile de projetos
> que usam autoconf/automake, que normalmente contém simplesmente
> 'install'. talvez uma versão mais antiga dessa pacote usasse
> autoconf/automake, mas do jeito que ele está hoje _eu acho_ que nenhum
> desses 2 ifs está servindo pra nada.
> 
> além disso hoje em dia o dh lida com debug e nostrip automaticamente pra
> você por baixo dos panos.

Obrigado.

Pedido de sponsors para o pacote TZC. NMU, fecha um
bug (atualizar debhelper).

debian/changelog(com data de hoje):

  * Non-maintainer upload.
  * Updated DH_LEVEL from 3 to 9. (Closes: #800220)
  * debian/control:
  - Build-Depends field:
  - debhelper >= 9.
  - tzc Depends:
  - ${misc:Depends} added.
  * debian/dirs removed.
  * debian/install created:
  - using the file to install the command binary.
  * dir debian/man created.
  - to put tzc.1 in there. Was in tzc*.diff.gz.
  * debian/manpages created.
  * debian/patches: (quilt)
  - split up tzc*.diff.gz archive. Three patch files.:
  - add_ZCkAuth_file.patch. Create the ZCkAuth.c file completely.
  - makefile-fixes.patch:
  - to stop lintian about 'no-pie':
  - add some options to CFLAGS.
  - add $(CFLAGS) to tzc target.
  - entries to install manpage and the command binary removed.
  - fixes-tzc-c.patch.
  - '%s' added to com_err(). Three times. Fernando Seiti Furusato
helped.
All patches needed 'quilt refresh --strip-trailing-whitespace'.
  * debian/rules:
  - new format
  - hardening+=bidnow added.
  - lines about debug and nostrip were removed.

Não consegui usar o cowbuilder. Mesmo recriando a
imagem tenho esse erro: (em outro pacote o mesmo
erro):

Unpacking libicu55:amd64 (55.1-7) ...
dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
data is corrupt
dpkg-deb: error: subprocess  returned error exit status 2
dpkg: error processing archive 
/var/cache/apt/archives/libicu55_55.1-7_amd64.deb (--unpack):
 cannot copy extracted data for './usr/lib/x86_64-linux-gnu/libicudata.so.55.1' 
to '/usr/lib/x86_64-linux-gnu/libicudata.so.55.1.dpkg-new': unexpected end of 
file or stream

E aí, no final: 'Errors were encountered while processing:' 
vários pacotes.

Mentors:
https://mentors.debian.net/package/tzc
https://mentors.debian.net/debian/pool/main/t/tzc/tzc_2.6.15-5.4.dsc



abraço,
-- 
Herbert Parentes Fortes Neto (hpfn)

Re: RFS: vpim -- Ruby support for vCard and iCalendar [NMU]

[Herbert Fortes (hpfn)]

Em 28/05/2016 11:53, Antonio Terceiro escreveu:

On Sat, May 28, 2016 at 09:35:04AM -0300, Herbert Fortes wrote:

Mentors:
https://mentors.debian.net/package/vpim
https://mentors.debian.net/debian/pool/main/v/vpim/vpim_0.695-1.5.dsc


sucesso; acabei de fazer o upload.



Obrigado.



abraço,
Herbert

Re: pacote bogofilter - bug RC - QA

[Herbert Fortes (hpfn)]

Em 17-04-2016 18:52, Eriberto escreveu:

Oi Herbert,

Legal você ter encontrado a solução. Às vezes eu levo dias para chegar
a uma conclusão também.

Comecei a olhar o pacote que você enviou hoje e, pelo changelog, vi
que ainda não está pronto. Assim sendo, vamos esperar um aviso seu
para a revisão. Eu ou o Terceiro, ajudados pelo pessoal da lista,
faremos a revisão.



Ok.

Falta uma limpeza no debian/rules e fazer o debian/copyright.



abraço,
Herbert

Re: duc: falha na construção em hurd-i386

[Herbert Fortes (hpfn)]

Olá,


eu criei uma máquina virtual no qemu/kvm. Usando libvirt [1]

Baixei o CD de instalação: debian-sid-hurd-i386-CD-1.iso em [2]

Bootei a máquina virtual com esse CD e instalei o Debian GNU/Hurd.

usei os procedimentos do guia de empacotamento do Eriberto [3]

[1] https://wiki.debian.org/KVM
[2] https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/
[3] http://eriberto.pro.br/debian/guia_empacotamento_debian_2.10.pdf

A partir daí empacotei como sempre fazemos na jaula.



Instalei o kvm hoje.

 - se estiver usando a testing, o pacote é libvirt-daemon-system e
   não libvirt-bin.
 - atenção com as permissões. Editei o /etc/group para kvm e 
libvirt-qemu (acho). E rmmod - modprobe

 - libvirtd e virtlogd rodando para criar a imagem. :)

Consultei o debian-handbook. https://debian-handbook.info/browse/stable/
É para stable, mas serve também.

É o que lembro.



abraço,
Herbert

Re: duc: falha na construção em hurd-i386

[Herbert Fortes (hpfn)]

Oi Kretcheu,

Em 02-04-2016 19:30, Paulo escreveu:

Opa,

me deu mais um ótimo motivo para (re)fazer minha jaula hurd.

Estou preparando a jaula aqui e assim que tiver notícias aviso.



Ok.


abraço,