Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

Hi Gianfranco,

Thanks for sponsoring the binNEW upload of twinkle.

I had a closer look at the lintian warning issued by debomatic:

  X: twinkle source: maybe-not-arch-all-binnmuable twinkle -> twinkle-common
  N: 
  N:Tag to attempt to measure the number of packages that might have an
  N:issue with arch:all binNMUs.
  N:
  N:At this time, please do  attempt to "fix" the problem. It is not
  N:clear what the solution is (if any at all). Nor is it clear that this is
  N:something that will be supported.
  N:
  N:Severity: wishlist, Certainty: possible
  N:
  N:Check: version-substvars, Type: source
  N:
  N:This tag is marked experimental, which means that the code that
  N:generates it is not as well-tested as the rest of Lintian and might
  N:still give surprising results. Feel free to ignore experimental tags
  N:that do not seem to make sense, though of course bug reports are always
  N:welcome.
  N: 

This experimental check not only flags twinkle but all packages that
have a "Depends: foo (= ${source:Version})" on an arch:all package.
As stated, there is nothing that can be done to solve that at the
moment, since neither ${binary:Version} nor ${source:Version} would
be appropriate for the case of an arch:all binNMU.

Peter

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Sergio Durigan Junior]

On Tuesday, June 28 2016, Dmitry Bogatov wrote:

> Dear mentors,
>
> I am looking for a sponsor for my package "elisp-slime-nav-el"
>
> * Package name: elisp-slime-nav-el
>   Version : 0.9-1
>   Upstream Author : Steve Purcell 
> * Url : https://github.com/purcell/elisp-slime-nav
> * Licenses: GPL-3+
>   Section : lisp

Hey Dmitry,

Thanks for the package.  Just a quick review because I'm not at my
Debian machine right now.

A few things pop out when I looked at the mentors.d.n for your package.

1) The links listed on the Vcs-* fields are not valid, so perhaps you
may want to (a) push your git repo temporarily at another URL, or (b)
create the repo under collab-maint/ and push your things there.

2) It seems you forgot to set the distribution to 'unstable' on your
debian/changelog file.

3) Any reason why you're using debhelper version 10?  It's still
experimental, so you probably should be using version 9.

For now, that's all I have.  I will try to look at the package later and
see if I have any more comments about it.

Thanks!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elisp-slime-nav-el"

* Package name: elisp-slime-nav-el
  Version : 0.9-1
  Upstream Author : Steve Purcell 
* Url : https://github.com/purcell/elisp-slime-nav
* Licenses: GPL-3+
  Section : lisp

It builds those binary packages:

elpa-elisp-slime-nav -- Emacs extension that provide Emacs Lisp code 
navigation

To access futher information about this package, visit the following URL:

http://mentors.debian.net/package/elisp-slime-nav-el

Alternatively, one can download the package with dget using this command:


http://mentors.debian.net/debian/pool/main/e/elisp-slime-nav-el/elisp-slime-nav-el_0.9-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/elisp-slime-nav.git

More information about elisp-slime-nav-el can be obtained from 
https://github.com/purcell/elisp-slime-nav

Changes since last upload:

  * Initial release (Closes: #828885)

Regards,
  Dmitry Bogatov

Bug#827333: RFS: newlisp/10.7.0-1 [ITP]

[Sergio Durigan Junior]

On Monday, June 20 2016, Andrey Rahmatullin wrote:

> On Mon, Jun 20, 2016 at 03:37:55PM -0400, Sergio Durigan Junior wrote:
>> > I've uploaded the package, thanks for your contribution to Debian :)
>> Thank you!  I guess I will ping you again when the package has been
>> accepted, so that you can allow me to make further uploads as a DM,
>> right?
> OK.

Hi Andrey,

The package has been accepted into the archives yesterday, so if you
could please give me DM access to it I'd appreciate!

Thank you very much!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#828700: marked as done (RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone)

[Debian Bug Tracking System]

Your message dated Tue, 28 Jun 2016 18:34:09 + (UTC)
with message-id <2111837213.5042173.1467138849062.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#828700: RFS: 
twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet 
Protocol (VoIP) SIP Phone
has caused the Debian Bug report #828700,
regarding RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice 
over Internet Protocol (VoIP) SIP Phone
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.)


-- 
828700: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828700
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "twinkle":

  git clone https://anonscm.debian.org/git/pkg-voip/twinkle.git
  cd twinkle && pristine-tar checkout 
../twinkle_1.9.0+git20160520.0.be8b8df+dfsg.orig.tar.xz

For verification, these are the current branch heads:

  git show-ref --heads
  40d6c98b0a34ca0b331e1e9a05351b66a3d09df4 refs/heads/master
  9b3e492fbc6e923b7fddd9a320abfc8eba57eb03 refs/heads/pristine-tar
  ef9654f270da62ba87a112e2a9724ca3fe5466a4 refs/heads/upstream

It builds these binary packages:

  twinkle - Voice over Internet Protocol (VoIP) SIP Phone

Changes since the last upload:

twinkle (1:1.9.0+git20160520.0.be8b8df+dfsg-1) unstable; urgency=medium

  * New upstream snapshot
  * Rewrite Description in a succinct style
  * Move twinkle-console to separate package
  * Install upstream man page
  * Add debian/gbp.conf for pristine-tar

 -- Peter Colberg   Sun, 26 Jun 2016 19:13:17 -0400

If you decide to sponsor this package, please upload the source only
so that buildd logs are available for all archs. I will push a release
tag to the git repository after the package has been uploaded.

Regards,
Peter


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Hi,


>I pushed another commit that removes ${shlibs:Depends} from twinkle-common.


fine, sponsoring soon!

G.--- End Message ---

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

I pushed another commit that removes ${shlibs:Depends} from twinkle-common.

Peter

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

Hi Gianfranco,

On Tue, Jun 28, 2016 at 09:21:51AM +, Gianfranco Costamagna wrote:
> Hi, lintian is not too happy with your changes
> http://debomatic-amd64.debian.net/distribution#unstable/twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1/lintian

The above report seems to be generated using an outdated version
of lintian. I verified with lintian 2.5.45 and did not find any
new lintian warnings compared to the previous versions.

I tested arch-all-only using `sbuild --debbuildopts=-A`.

Regards,
Peter

Re: How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Christian Seiler]

On 06/28/2016 11:01 AM, Andreas Tille wrote:
> I admit I can not answer the question asked by upstream.  The package in
> question is iqtree[1] and they said that they have different
> computational kernels implemented to respect different hardware.
> Current Git[1] does not even build - may be due to some fine tuning of
> gcc options needed???

I've looked at this, and there are a couple of things going on here:

0. Debian's build flags by default assume a generic architecture, so
you don't have to do anything by yourself.

1. Upstream's build system supports multiple options for the entirety
of the code. So you can compile the entire code with the AVX or FMA
instruction set. You patch that out completely from the CMakeLists.txt
in sse.patch, but that isn't actually required. (IQTREE_FLAGS would
have to be explicitly set to enable this.)

2. Furthermore, upstream's build system provides SSE and AVX kernels
for regardless of the build flags of the rest of the code, and they are
always compiled. (Well, you can disable compilation of the AVX kernel
if you add "novx" to IQTREE_FLAGS, but there's no reason to.) This
should work out of the box.

That said, the code doesn't support non-SSE at all, because it hard-
codes at least SSE2 intrinsics in a lot of platces (and the one part
where it hardcodes SSE3, you already have a patch for). The code can
therefore not be compiled without SSE support enabled, unfortunately,
even on i386. If you want to support non-SSE at all on i386, upstream
(or yourself) needs to implement the routines in the vectorclass/
directory (and possibly others) for non-SSE systems. (The kernel that
optionally uses AVX also exists in a non-SSE variant, so upstream is
not completely wrong about that, but there's a lot of _other_ code that
forces at least SSE2.

3. pll/ has a bug that it calls posix_memalign with PLL_BYTE_ALIGNMENT.
However, according to the manpage, the alignment must be a multiple of
sizeof(void *) for posix_memalign to work (and a power of 2), but
PLL_BYTE_ALIGNMENT is 1 if SSE3 is not used. If you explicitly set it
to 8 (to catch both 32bit and 64bit), posix_memalign will not fail and
the program won't segfault anymore. (posix_memalign with wrong align
argument will just return without a possibility to check for an error,
but also not allocating a buffer, leaving it empty.)

Note though that if you don't compile with sse3 flags enabled, pll will
not use SSE code at all (other than that which the compiler generates),
which is probably slower. But it does work, though. (A grep for __SSE3
shows though that porting this would be a LOT of work.)

Irrespective of the SSE-stuff, two things:

1. Your debian/rules calls dh_auto_clean/configure/build in
   override_dh_auto_build to build two variants. This can be done in a
   more elegant way, because CMake does support out of tree builds, and
   you can have debhelper use a specific build directory by specifying
   -Bdirname to dh_auto_*.

2. You might want to add --parallel to your dh call in debian/rules.
   CMake-based projects tend to support paralle builds, and iqtest is
   no exception to that rule. Would speed up build times quite a bit.

3. If you want to test the -omp binary as you do in debian/rules
   currently, you have to pass -redo, otherwise the second call will
   simply fail.

I've update your sse.patch to include the SSE-related fixes, and have
updated debian/rules to incorporate the two other things. Attached both
to this email. The package now builds on amd64 and i386 (and probably
will build on the kfreebsd and hurd variants thereof, though I haven't
checked) and the test suite runs. The AVX/FMA checks in CMakeLists.txt
are now not removed, because debian/rules never sets IQTEST_FLAGS to
fma or avx. (On amd64 the avx kernel is built with -mavx regardless
separately by the build system, so that's also OK; and on my Haswell
system the AVX detection works. On i386 the AVX kernel is never built,
as per what the upstream build system decided.) However, even on i386,
SSE2 support is required for this to work, otherwise the program will
crash with either illegal instruction or a segfault at start. (I can
provide you with a preinst script that checks for SSE2 support to show
a nice error message at package installation time, if you so wish.)

Additionally (what I've NOT done): please check the lintian info and
pedantic messages of the package:

 - out-of-date-standards-version 3.9.7
 - a couple of spelling-error-in-binary
 - hardening-no-pie/hardening-no-bindnow: consider enabling all
   hardening flags (if that works, haven't checked)
 - copyright-refers-to-symlink-license: you should refer to
   /usr/share/common-licenses/GPL-3 and not .../GPL in the GPL-3
   block of debian/copyright

Hope that helps.

Regards,
Christian
#!/usr/bin/make -f

# DH_VERBOSE := 1

pkg := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p')
version=$(shell dpkg-parsechangelog -ldebian/changelog | grep Version: | cut 
-f2 -d' ' | cut 

Bug#828863: marked as done (RFS: gmp-ecm/7.0.2+ds-1 [RC] -- Factor integers using the Elliptic Curve Method)

[Debian Bug Tracking System]

Your message dated Tue, 28 Jun 2016 16:20:11 + (UTC)
with message-id <1258845587.5003950.1467130811635.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#828863: RFS: gmp-ecm/7.0.2+ds-1 [RC] -- Factor 
integers using the Elliptic Curve Method
has caused the Debian Bug report #828863,
regarding RFS: gmp-ecm/7.0.2+ds-1 [RC] -- Factor integers using the Elliptic 
Curve Method
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.)


-- 
828863: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828863
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important

Dear Sponsors,

I am looking for sponsorship for the package gmp-ecm. This package 
brings
the lastest patch version of [gmp-]ecm that fixes some tests failures
encountered on some 32bit architectures (#828717).

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/gmp-ecm.git

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
Hi,

>I am looking for sponsorship for the package gmp-ecm. This package brings
>the lastest patch version of [gmp-]ecm that fixes some tests failures
>encountered on some 32bit architectures (#828717).


LGTM

sponsored,
G.--- End Message ---

Bug#828863: RFS: gmp-ecm/7.0.2+ds-1 [RC] -- Factor integers using the Elliptic Curve Method

[Jerome Benoit]

Package: sponsorship-requests
Severity: important

Dear Sponsors,

I am looking for sponsorship for the package gmp-ecm. This package 
brings
the lastest patch version of [gmp-]ecm that fixes some tests failures
encountered on some 32bit architectures (#828717).

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/gmp-ecm.git

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: Next autoconf problem for today libdisorder

[Christian Seiler]

On 06/27/2016 10:49 PM, Andreas Tille wrote:
>>  - if you use autoconf/automake, you don't need to use d-moveshlibs
>>for multiarch, dh_auto_configure / dh_auto_build / dh_auto_install
>>will do all the heavy lifting for you (just create proper .install
>>files for the packages, and use /usr/lib/*/filename to select the
>>proper file names) That's a matter of taste, of course.
> 
> I agree that its not necessary to copy files around.  However, I like
> d-shlibs to ensure that debian/control is properly designed.

It does appear to not fully support all architectures though, if
you look at the buildd results:
https://buildd.debian.org/status/package.php?p=libdisorder

It would be great if you could report that as a bug against
d-shlibs, assuming nobody else has done so yet. (Maybe wait
until all other platforms are either built or failed, to have
a complete list.)

Regards,
Christian

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

On Tue, Jun 28, 2016 at 03:42:21PM +0200, Christian Seiler wrote:
> 
> (Btw. you still didn't update debian/control in git. ;-))

Ahhh, thanks for noticing ...
 
> Well, but the reason you get help here is so you can learn from
> it. ;-) And you don't have to be an expert in the autotools (while I
> do know quite a bit, I certainly am not), but if you're packaging
> stuff that uses autotools in Debian (and you're packaging quite a
> lot of packages that fall in that category), it is really helpful to
> have an idea about the basics.
> 
> I would therefore really encourage you to do at least a bit of
> reading on that topic.

I fully agree but there is similarly important documentation I would
need to read as well.
 
> > The manpage is not installed since it has zero bytes.  (I actially
> > had a debian/manpages file written but removed it afterwards.)
> 
> Oh, I didn't check that. Funny that upstream ships it then. In
> that case, I do agree with your decision not to include it. ;-)

:-)

Thanks again

  Andreas.

-- 
http://fam-tille.de

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> On Mon, Jun 27, 2016 at 05:32:32PM +0300, Dmitry Bogatov wrote:
> > 2. In d/copyright, I think you need to specify copyright years for the
> > copyright holders.  Just their names is not enough, since on a desert
> > island ~60 years from now with no newer versions of evil available for
> > download, the code would become public domain :) (well, I guess the
> > old version of the code would be public domain on the mainland too)
> > 
> > Unfortunately, upstream maintains only list of contributors. So seems
> > best thing we can do is to count 60 years from last debian upload.
> 
> I'm not sure whether this is likely to be acceptable to the ftp-masters
> or not.  Perhaps someone more experienced on debian-mentors can chime
> in.

Gianfranco, your opinion?

> > > 3. Any particular reason you are using gz and not xz compression in
> > >gbp.conf?  Also, it might be a good idea to check the tarball into
> > >git with pristine-tar so that a sponsor has exactly the same one (I
> > >generated my own for testing).
> > No. Moved to xz.
> I still don't see a pristine-tar branch :)

Do not understand. I alread have tarball content, as I downloaded
it at 'upstream/1.2.12'. What more we need?

> > 4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
> >the tests for you, though you'll probably need to give it some hints.
> >See dh_elpa_test(1) for how to do this: basically, raise to compat
> >level 10 and then set DH_ELPA_TEST_* env vars.
> > 
> > Tests want tty on stdin. Added note and disabled tests. Any good
> > ideas, how to run them in background?

> It's unlikely that the tty issue is the problem: ERT tests are supposed
> to be runnable in batch mode.  Although perhaps evil is different.

> First, though, we need to fix your dh_elpa_test usage.  You don't need
> DH_ELPA_TEST_ERT_EVAL: dh_elpa_test will automatically load that file
> because it contains ERT test definitions.  Instead, you need to use
> DH_ELPA_TEST_ERT_HELPER to call `evil-test-initialise' as upstream's
> Makefile does.

Here is script, that does same as dh_elpa_test:

emacs -batch -Q -L . --eval "(require 'evil)" -l package \
  --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" \
  --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa-src\")" \
  -f package-initialize \
  -L . \
  -l evil-tests.el \
  -l lib/ert.el \
  -L lib \
  -f evil-tests-initialize

It reports 22 failures. If I replace -batch with -nw, all tests
passes. So seems tty is really needed, but I do not understand why.

> > 5. Please add a d/watch.
> > 
> > Problem. Mercurial upstream repository, and tarballs are named not
> > after version, but after hashes. I fail to extract anything useful
> > from this page: [1]
> > 
> > [1] https://bitbucket.org/lyro/evil/downloads
> Ah.  Seems that we're out of luck: uscan can't do Mercurial tags.

Jakub Wilk found solution. Now we have another way to
get tarball.

> > > The function `evil-mode' doesn't seem to be properly autoloaded.
> > > I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> > > evil-mode is not available.  However, if I type M-x describe-function
> > > RET evil-mode RET it works.  Something is going wrong with the
> > > autoloading.
> >
> > I think I fixed it. Please, check.
>
> It seems it wasn't enough.  If I move my .emacs.d out of the way and
> then run it, and M-x evil-mode, I get this:
>
> Error in post-command-hook (evil-repeat-post-hook): (void-function 
> evil-repeat-post-hook)
> Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
> evil-repeat-pre-hook)

Patched it. Check again.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Next autoconf problem for today libdisorder

[Christian Seiler]

(Merging replies.)

On 06/28/2016 08:35 AM, Andreas Tille wrote:
> On Mon, Jun 27, 2016 at 11:57:12PM +0200, Christian Seiler wrote:
>> [Multi-Arch]
>> In your package, that's already the case, so you can just add the header
>> to debian/control.
> 
> A, well, yes - I simply forgot this.  In my initial question I assumed
> something more on the Build-System would be needed.

Well, even if the build system doesn't support --libdir= or similar, you
can still install the files in the proper locations manually (via
debian/rules directly, .install files, d-shlibmove, or similar); only
for very, very few packages does Multi-Arch actually affect the upstream
code itself. (Think compilers etc.)

(Btw. you still didn't update debian/control in git. ;-))

>> Anyway: in case you want to know more about autoconf/automake etc.
>> I would really recommend  in
>> addition to the official documentation of that ecosystem ([1],
>> [2], [3], [4]).
> 
> I know I should know more about these tools but I need to quite rarely
> and the good thing on Debian Mentors is that you (obviously) get
> brilliant help if needed.  While beeing really great this on the other
> hand decreases the motivation to learn everything be heart. ;-)

Well, but the reason you get help here is so you can learn from
it. ;-) And you don't have to be an expert in the autotools (while I
do know quite a bit, I certainly am not), but if you're packaging
stuff that uses autotools in Debian (and you're packaging quite a
lot of packages that fall in that category), it is really helpful to
have an idea about the basics.

I would therefore really encourage you to do at least a bit of
reading on that topic.

> On Mon, Jun 27, 2016 at 10:41:28PM +0200, Christian Seiler wrote:
>> On 06/27/2016 07:49 PM, Christian Seiler wrote:
>>> Other comments regarding the package:
>>
>> Oh btw. I just noticed that you don't install the manpage for
>> the library function in the -dev package (because d-shlibmove
>> doesn't care about manpages, and you don't have an .install
>> file for that package). Since upstream includes the manpage,
>> I would recommend also shipping it.
> 
> The manpage is not installed since it has zero bytes.  (I actially
> had a debian/manpages file written but removed it afterwards.)

Oh, I didn't check that. Funny that upstream ships it then. In
that case, I do agree with your decision not to include it. ;-)

Regards,
Christian

Bug#828841: marked as done (RFS: yamllint/1.3.2-1)

[Debian Bug Tracking System]

Your message dated Tue, 28 Jun 2016 12:25:50 + (UTC)
with message-id <2116826129.4691041.1467116750857.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#828841: RFS: yamllint/1.3.2-1
has caused the Debian Bug report #828841,
regarding RFS: yamllint/1.3.2-1
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.)


-- 
828841: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828841
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "yamllint"

* Package name: yamllint
  Version : 1.3.2-1
  Upstream Author : Adrien Vergé 
* URL : https://github.com/adrienverge/yamllint
* License : GPL-3+
  Section : devel

It builds this binary package:

  yamllint   - Linter for YAML files

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/yamllint

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/y/yamllint/yamllint_1.3.2-1.dsc


Changes since the last upload:

  * Allow disabling yamllint checks using comments
  * Detect user config using `os.path.expanduser()`
  * Fix non-ASCII comments bug and add tests
  * Update standards version to 3.9.8

Regards,
 Adrien Vergé
--- End Message ---
--- Begin Message ---
Hi,
>I am looking for a sponsor for my package "yamllint"


sponsored, but please next time try to use a better changelog wording.
e.g. some entries are related to bugs fixed in the new upstream release,
this way they should belong in that section
e.g.
* Allow disabling yamllint checks using comments
* Detect user config using `os.path.expanduser()`
* Fix non-ASCII comments bug and add tests
* Update standards version to 3.9.8


you should have written something like

* New upstream release

  - Allow disabling yamllint checks using comments
  - Detect user config using `os.path.expanduser()`
  - Fix non-ASCII comments bug and add tests
* Update standards version to 3.9.8

that would make better to understand which bugs are fixed by upgrading, and
which bugs are fixed in Debian packaging.

Anyway, signed and uploaded!

G.--- End Message ---

Bug#828841: RFS: yamllint/1.3.2-1

[Adrien Vergé]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "yamllint"

* Package name: yamllint
  Version : 1.3.2-1
  Upstream Author : Adrien Vergé 
* URL : https://github.com/adrienverge/yamllint
* License : GPL-3+
  Section : devel

It builds this binary package:

  yamllint   - Linter for YAML files

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/yamllint

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/y/yamllint/yamllint_1.3.2-1.dsc


Changes since the last upload:

  * Allow disabling yamllint checks using comments
  * Detect user config using `os.path.expanduser()`
  * Fix non-ASCII comments bug and add tests
  * Update standards version to 3.9.8

Regards,
 Adrien Vergé

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> * Dmitry Bogatov , 2016-06-27, 17:32:
> >Mercurial upstream repository, and tarballs are named not after 
> >version, but after hashes. I fail to extract anything useful from this 
> >page: [1]
> >
> >[1] https://bitbucket.org/lyro/evil/downloads

> This seems to work for me:
> version=3
> https://bitbucket.org/lyro/evil/downloads .*/get/([0-9.]+)[.]tar[.]gz

Thanks a lot. Pushed.

In general, do we have any script, that automates process of writing
watch files? Every time I need to write watch file for github, I
copy-and-paste from comments in /usr/bin/uscan.

If not, it may be useful addition to devscripts.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Henrique de Moraes Holschuh]

On Tue, 28 Jun 2016, Andreas Tille wrote:
> I admit I can not answer the question asked by upstream.  The package in
> question is iqtree[1] and they said that they have different
> computational kernels implemented to respect different hardware.
> Current Git[1] does not even build - may be due to some fine tuning of
> gcc options needed???
> 
> Any help is welcome

Well, for Debian unstable/next stable, we will have gcc 6, where you can
actually use FMV to fix this kind of issue sort of "automatically".  But
it is unbackportable (without a full backport of glibc and gcc 6).

https://lwn.net/Articles/691932/

But apparently iqtree is already capable of doing something like FMV on
its own, so you would not need to do the above, and the issue is with
the build tooling.

gcc doesn't much care if the build machine has the same subarch,
instruction set, or even architecture as the code it is compiling, so
you could build SSE3 binaries on a box without SSE3 support easily.

However, that only works when the *build scripts* do not try to run any
code they compiled in the build machine, or when they clearly separate
building build-tools (which will be run in the build machine during the
build) from the build-targets (which are going to be run only when
installed in the target system) and let you use different gcc and
C/LD/CXX/CPPFLAGS for each situation (i.e. are cross-compilation safe).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Dmitry Bogatov , 2016-06-27, 17:32:
Mercurial upstream repository, and tarballs are named not after 
version, but after hashes. I fail to extract anything useful from this 
page: [1]


[1] https://bitbucket.org/lyro/evil/downloads


This seems to work for me:

version=3
https://bitbucket.org/lyro/evil/downloads .*/get/([0-9.]+)[.]tar[.]gz

--
Jakub Wilk

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi, lintian is not too happy with your changes
http://debomatic-amd64.debian.net/distribution#unstable/twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1/lintian


please fix the above if possible,

Gianfranco


Il Martedì 28 Giugno 2016 5:21, Peter Colberg  ha scritto:
I have pushed two minor commits:

git show-ref --heads
76e884d7cc340d88924a51505521a5c6d7b7f1b3 refs/heads/master
9b3e492fbc6e923b7fddd9a320abfc8eba57eb03 refs/heads/pristine-tar
ef9654f270da62ba87a112e2a9724ca3fe5466a4 refs/heads/upstream


Peter

How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Andreas Tille]

Hi,

I admit I can not answer the question asked by upstream.  The package in
question is iqtree[1] and they said that they have different
computational kernels implemented to respect different hardware.
Current Git[1] does not even build - may be due to some fine tuning of
gcc options needed???

Any help is welcome

Andreas.

On Sat, Mar 12, 2016 at 07:33:48PM +0100, Tung Nguyen wrote:
> >
> > That's perfect.  A runtime detection is always the best way to go.  The
> > only problem might be that some architectures do not know SSE3 at build
> > time and the code needs to compile also under this conditions.
> >
> >
> Dear Andreas,
> 
> Is it possible to specify a generic architecture to GCC when you compile
> the code so that all 3 computational kernels  (non-SSE, SSE3, AVX) get
> compiled? Then during runtime IQ-TREE will automatically detect which
> kernel it should use, depending on the architecture. I assume that the
> non-SSE kernel should run fine on most x86 architecture. If this approach
> does not work, then we will provide a flag to exclude the compilation of
> the SSE3 and AVX kernels.


[1] https://anonscm.debian.org/git/debian-med/iqtree.git

-- 
http://fam-tille.de

Bug#828792: marked as done (RFS: yamllint/1.3.0-1)

[Debian Bug Tracking System]

Your message dated Tue, 28 Jun 2016 09:57:09 +0200
with message-id 

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 11:57:12PM +0200, Christian Seiler wrote:
> 
> Well, autoconf in and by itself doesn't support testing, automake does,
> which fortunately you're also using.
> 
> I've added a very trivial test from the way I understand how the program
> you're using works, and attached an updated patch to this email. (I've
> also updated the autoconf/automake prerequisites, see my last email.)
> It's actually quite trivial: write a shell script that returns
> successfully (exit code 0) or not. (You can run a C program directly if
> it does return 0 or not depending on the test results, but that doesn't
> apply to ropy directly.) My test applies ropy to the COPYING file
> containing the text of the GPL and checks if the result matches the
> expectations. Feel free to extend/change that to your liking, but as a
> basic functionality check I think that is already useful.

Great.  I applied the patch in Git.
 
> Beware though that if "make check" fails, the package build will also
> fail by default.

Yes.  That's what a test is for. :-)

> (I consider that to be a good thing, just something to
> keep in mind.) I did some test builds on amd64, i386, x32, and arm64,
> and the simple test I created succeeds on all of these platforms.

Thanks for the thorough checking!
 
> Well, in general I would consider pkg-config to be good thing for
> libraries, but I'm not sure here, especially if the circle of consumers
> is a very small circle and they don't appear to be using pkg-config so
> far anyway, so it's probably a waste of time here.

Good to know that you have the same feeling as I had.
 
> In your package, that's already the case, so you can just add the header
> to debian/control.

A, well, yes - I simply forgot this.  In my initial question I assumed
something more on the Build-System would be needed.

> Another thing I noticed: your configure.ac checks for a C++
> compiler, which is unnecessary here, as this is a pure C library.
> You can simply drop the C++ checks and save computing resources.
> I've done that in the updated autoconf.patch I've attached (that
> also contains the unit test).

Cool, thanks.
 
> Anyway: in case you want to know more about autoconf/automake etc.
> I would really recommend  in
> addition to the official documentation of that ecosystem ([1],
> [2], [3], [4]).

I know I should know more about these tools but I need to quite rarely
and the good thing on Debian Mentors is that you (obviously) get
brilliant help if needed.  While beeing really great this on the other
hand decreases the motivation to learn everything be heart. ;-)

Thanks a lot for your very verbose and helpful hints

  Andreas.

-- 
http://fam-tille.de

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 10:41:28PM +0200, Christian Seiler wrote:
> On 06/27/2016 07:49 PM, Christian Seiler wrote:
> > Other comments regarding the package:
> 
> Oh btw. I just noticed that you don't install the manpage for
> the library function in the -dev package (because d-shlibmove
> doesn't care about manpages, and you don't have an .install
> file for that package). Since upstream includes the manpage,
> I would recommend also shipping it.

The manpage is not installed since it has zero bytes.  (I actially
had a debian/manpages file written but removed it afterwards.)

Thanks for the hint anyway

 Andreas.

-- 
http://fam-tille.de