[DRE-maint] ruby-fakeweb 1.3.0+git20170806+dfsg1-1.1 MIGRATED to testing
FYI: The status of the ruby-fakeweb source package in Debian's testing distribution has changed. Previous version: 1.3.0+git20170806+dfsg1-1 Current version: 1.3.0+git20170806+dfsg1-1.1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] test-kitchen is marked for autoremoval from testing
test-kitchen 1.23.2-2 is marked for autoremoval from testing on 2019-05-24 It (build-)depends on packages with these RC bugs: 926827: ruby-vcr: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-guard-shell is marked for autoremoval from testing
ruby-guard-shell 0.7.1-2 is marked for autoremoval from testing on 2019-05-24 It (build-)depends on packages with these RC bugs: 926826: ruby-guard: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-kitchen-salt is marked for autoremoval from testing
ruby-kitchen-salt 0.4.0-2 is marked for autoremoval from testing on 2019-05-24 It (build-)depends on packages with these RC bugs: 926827: ruby-vcr: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-concurrent 1.0.5-3 MIGRATED to testing
FYI: The status of the ruby-concurrent source package in Debian's testing distribution has changed. Previous version: 1.0.5-2 Current version: 1.0.5-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-vcr is marked for autoremoval from testing
ruby-vcr 4.0.0-1 is marked for autoremoval from testing on 2019-05-24 It is affected by these RC bugs: 926827: ruby-vcr: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-kitchen-docker is marked for autoremoval from testing
ruby-kitchen-docker 2.7.0-1 is marked for autoremoval from testing on 2019-05-24 It (build-)depends on packages with these RC bugs: 926827: ruby-vcr: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-mixlib-install is marked for autoremoval from testing
ruby-mixlib-install 3.11.7-1 is marked for autoremoval from testing on 2019-05-24 It (build-)depends on packages with these RC bugs: 926827: ruby-vcr: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] ruby-guard is marked for autoremoval from testing
ruby-guard 2.15.0-2 is marked for autoremoval from testing on 2019-05-24 It is affected by these RC bugs: 926826: ruby-guard: FTBFS (failing tests) ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#927297: gitlab: Update browser cache after upgrade
On 2019, ഏപ്രിൽ 17 9:35:13 PM IST, p...@disroot.org wrote: >Package: gitlab >Version: 11.5.10+dfsg-1~bpo9+1 >Severity: wishlist > >Dear Maintainer, > * What led up to the situation? > Upgrade to newer version > * What exactly did you do (or not do) that was effective (or > ineffective)? > Opening issue thread after the upgrade > * What was the outcome of this action? > The outcome is broken input and edit options > * What outcome did you expect instead? > Proper input and edit options at issue comments. > * How could this issue be solved? > Please find a way to clear the browser cache or ask the user to do so > via a notice. Thanks pavi. We'll check if there is way to trigger cache reloads or at least document it properly. Would you like to send a merge request to the README.Debian file? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#927297: gitlab: Update browser cache after upgrade
Package: gitlab Version: 11.5.10+dfsg-1~bpo9+1 Severity: wishlist Dear Maintainer, * What led up to the situation? Upgrade to newer version * What exactly did you do (or not do) that was effective (or ineffective)? Opening issue thread after the upgrade * What was the outcome of this action? The outcome is broken input and edit options * What outcome did you expect instead? Proper input and edit options at issue comments. * How could this issue be solved? Please find a way to clear the browser cache or ask the user to do so via a notice. ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Processed: Re: Bug#853244: ruby-sshkit: Non-determistically FTBFS due to unreliable timing in tests
Processing commands for cont...@bugs.debian.org: > tags 853244 + patch Bug #853244 [src:ruby-sshkit] ruby-sshkit: Non-determistically FTBFS due to unreliable timing in tests Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 853244: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853244 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#853244: ruby-sshkit: Non-determistically FTBFS due to unreliable timing in tests
tags 853244 + patch
thanks
On Mon, 6 Feb 2017, Chris Lamb wrote:
> The problem is that this package would need a *specific* note/mention
> that it should be ignored. Whilst we could certainly add that for
> Reproducible Builds, what happens, for example, when the next person
> runs a rebuild across the archive to test for something else (etc. etc.)
Hi. I'm afraid I'm such next person...
This package FTBFS randomly for me on START1-S / DEV1-S instances from
Scaleway, and the failure rate is around 30% there.
I've put a bunch of build logs here:
https://people.debian.org/~sanvila/build-logs/ruby-sshkit/
and I've setup a Jenkins job here in case you want to see it failing
in real time:
https://jenkins-2.reliable-builds.org/job/ruby-sshkit/
Even if our packages are built "officially" on buildd.debian.org,
this does not mean that it is a good idea to "target" the specific
(or even approximate) CPU speed of buildd.debian.org autobuilders.
The end user must be able to build packages without failures as well,
because, after all, we don't just provide binary packages, we also
provide the freedom to modify them at will.
This is the reason why I would consider this bug "serious" as well.
In fact, imagine what happened if I wanted to build all packages from
source and all upstream authors did the same (i.e. target a specific
CPU speed which makes the package to FTBFS 30% of the time in some
systems). From 3 source packages I would have to retry on 9000 of
them. From those, 2700 would fail again in the second try, and I would
still have to retry in a geometrical decreasing way until all packages
are successfully build. This certainly does not scale.
Anyway, let's see if we can improve the status of this problem in buster:
There are four tests which fail over and over again in my setup. If I
grep for "FAIL" in the build logs above and count occurrences, this is
what I get:
23 test_the_connection_manager_can_run_things_with_custom_runner_configs
21 test_the_connection_manager_can_run_things_in_groups
15 test_the_connection_manager_can_run_things_in_custom_runner
10 test_the_connection_manaager_runs_things_in_parallel_by_default
So, I strongly suggest disabling those tests for buster, since they
seem to be the ones that fail most.
The patch below (warning: untested) may help.
Thanks.
--- a/test/unit/test_coordinator.rb
+++ b/test/unit/test_coordinator.rb
@@ -43,12 +43,6 @@ module SSHKit
assert_equal "Command: echo 1.example.com\n", actual_output_commands.last
end
-def test_the_connection_manaager_runs_things_in_parallel_by_default
- Coordinator.new(%w{1.example.com 2.example.com}).each(_time)
- assert_equal 2, actual_execution_times.length
- assert_within_10_ms(actual_execution_times)
-end
-
def test_the_connection_manager_can_run_things_in_sequence
Coordinator.new(%w{1.example.com 2.example.com}).each in: :sequence,
_time
assert_equal 2, actual_execution_times.length
@@ -68,46 +62,6 @@ module SSHKit
end
end
-def test_the_connection_manager_can_run_things_in_custom_runner
- begin
-$original_runner = SSHKit.config.default_runner
-SSHKit.config.default_runner = MyRunner
-
-Coordinator.new(%w{1.example.com 2.example.com}).each(_time)
-assert_equal 2, actual_execution_times.length
-assert_within_10_ms(actual_execution_times)
-assert_match(/custom runner out/, @output)
- ensure
-SSHKit.config.default_runner = $original_runner
- end
-end
-
-def test_the_connection_manager_can_run_things_with_custom_runner_configs
- begin
-$original_runner = SSHKit.config.default_runner
-SSHKit.config.default_runner = :groups
-$original_runner_config = SSHKit.config.default_runner_config
-SSHKit.config.default_runner_config = { limit: 2, wait: 5 }
-
-Coordinator.new(
- %w{
-1.example.com
-2.example.com
-3.example.com
-4.example.com
- }
-).each(_time)
-assert_equal 4, actual_execution_times.length
-assert_within_10_ms(actual_execution_times[0..1])
-assert_within_10_ms(actual_execution_times[2..3])
-assert_at_least_5_sec_apart(actual_execution_times[0],
actual_execution_times[2])
-assert_at_least_5_sec_apart(actual_execution_times[1],
actual_execution_times[3])
- ensure
-SSHKit.config.default_runner = $original_runner
-SSHKit.config.default_runner_config = $original_runner_config
- end
-end
-
def test_the_connection_manager_can_run_things_in_sequence_with_wait
start = Time.now
Coordinator.new(%w{1.example.com 2.example.com}).each in: :sequence,
wait: 10, _time
@@ -115,25 +69,6 @@ module SSHKit
assert_operator(stop - start, :>=, 10.0)
end
-def test_the_connection_manager_can_run_things_in_groups
- Coordinator.new(
-%w{
-
