Bug#839568: ITP: libmojolicious-plugin-renderfile-perl -- "render_file" helper for Mojolicious

2016-10-02 Thread Hideki Yamane 
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: libmojolicious-plugin-renderfile-perl
  Version : 0.10
  Upstream Author : Viktor Turskyi 
* URL : https://metacpan.org/release/Mojolicious-Plugin-RenderFile
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : "render_file" helper for Mojolicious

 Mojolicious::Plugin::RenderFile is a Mojolicious plugin that adds
 "render_file" helper. It does not read file in memory and just streaming it
 to a client.

I'll put this package into Debian repository to introduce openQA 
(http://open.qa/)

Re: Dealing with problematic unit tests from upstream (was: Network access during build)

2016-10-02 Thread Thomas Goirand 
On 09/13/2016 02:44 AM, Zlatan Todoric wrote:
> So, my solution to this would be to first politely talk to our upstream
> and have a statement (that we all together would make it as generic
> letter for outreach to our upstreams) why they  should change tests and
> if we can help them. Who know, maybe they even accept. If they don't, we
> just disable those tests or all tests.

Let's generalize and not just take the case of network access during
build, which is only one case.

What you propose here isn't always practical but sometimes work, at
least in my case (ie: packaging OpenStack). The "politely talk to our
upstream" only works so much if no patch is proposed. The biggest issue
is when we see the same problems over and over on many components of the
project. It may take a huge amount of time to have such discussions. So,
while engaging in a discussion is always good (which I try to do as much
as possible), it often isn't enough. When repeating problems happens
really too often, then I open a thread on the openstack-dev@ list, but
not everyone reads every message (too much traffic). What works best is
to open a CR (Change Request) on Gerrit. It may take a long time to have
it to go through, but that's what upstream prefers. There as well is a
kind of do-o-cratie.

Disabling all unit tests is really not acceptable in my case. There's
just too many moving parts, and quality would drop considerably. So that
really not an option. Disabling *selectively* some problematic unit
tests, knowing they have a low impact, is doable though.

Cheers,

Thomas Goirand (zigo)

Bug#839569: ITP: libselenium-remote-driver-perl -- Perl Client for Selenium Remote Driver

2016-10-02 Thread Hideki Yamane 
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: libselenium-remote-driver-perl
  Version : 1.00
  Upstream Author : Aditya Ivaturi , 
Daniel Gempesaw ,
Emmanuel Peroumalnaïk ,
Luke Closs ,
Mark Stosberg 

* URL : https://metacpan.org/release/Selenium-Remote-Driver
* License : Apache-2.0
  Programming Lang: Perl
  Description : Perl Client for Selenium Remote Driver

 A setup class for all the repetitive things we need to do before running
 tests. First, we're deciding whether the test is in record or replay mode. If
 we're recording, we'll end up writing all the HTTP request/response pairs out
 to /mock_file. If we're replaying, we'll look for our OS-appropriate
 mock_file and try to read from it.
 .
 After we figure that out, we can instantiate our Mock::RemoteConnection with
 the proper constructor arguments and return that as our base_args for use in
 the tests! Finally, on destruction, if we're recording, we make sure to dump
 out all of the request/response pairs to the mock_file.

I'll put this package into Debian repository to introduce openQA 
(http://open.qa/)

Bug#839572: ITP: libtest-time-perl -- Overrides the time() and sleep() core functions for testing

2016-10-02 Thread Hideki Yamane 
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: libtest-time-perl
  Version : 0.04
  Upstream Author : cho45 
* URL : https://metacpan.org/release/Test-Time
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Overrides the time() and sleep() core functions for testing

 Test::Time can be used to test modules that deal with time. Once you use this
 module, all references to time and sleep will be internalized.

I'll put this package into Debian repository to introduce openQA 
(http://open.qa/)

Re: Porter roll call for Debian Stretch

2016-10-02 Thread Jose E. Marchesi 

> As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> support, so even SPARC is getting back into shape which is why I hope
> we can add sparc64 as an official port soon.
[...]

Oracle cares about Solaris on SPARC, not Linux on SPARC.

We certainly _do_ care about GNU/Linux on SPARC.

Confused by autoremoval

2016-10-02 Thread Nikolaus Rath 
Hello,

Can someone explain to me why (according to the email that I've just
received) python-llfuse 1.1.1+dfsg-3 is marked for autoremoval from
testing on 2016-10-24?

The email says that:

It is affected by these RC bugs:
837254: python-llfuse: FTBFS: E: pybuild pybuild:276: test: plugin
distutils failed with: exit code=2: cd
/<>/python-llfuse-1.1.1+dfsg/.pybuild/pythonX.Y_2.7/build;
python2.7 -m pytest --installed "{dir}/test/"


...but 1.1.1+dfsg-3 is exactly the version that fixes the above bug.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Confused by autoremoval

2016-10-02 Thread Christian Seiler 
On 10/02/2016 05:54 PM, Nikolaus Rath wrote:
> Can someone explain to me why (according to the email that I've just
> received) python-llfuse 1.1.1+dfsg-3 is marked for autoremoval from
> testing on 2016-10-24?

Probably , see the thread [1]
from earlier this weekend.

Regards,
Christian

[1] https://lists.debian.org/2958b5e0-07a8-628b-60f7-85a3b4ae9...@xs4all.nl