Call for testing yarnpkg 4 (Re: RFS: node-yarnpkg (update))
On 13/10/23 8:26 PM, Israel Galadima wrote: On Fri, 13 Oct 2023 at 13:57, Pirate Praveen <mailto:prav...@onenetbeyond.org>> wrote: I think I use coma separated list, but probably the other option work too. Thanks, I've fixed everything. Thanks to great work by Israel and other outreachy interns in the past, we have a yarnpkg in the archive that is built with well maintained build and runtime dependendencies (we can finally get rid of obsolete node-request from the archive). We can also stop maintaining patches to make it build with newer build depends like babel 7. We also have corepack, which is kind of a meta package manager - package manager to install package managers!! (no surprise to people who know nodejs). corepack can install npm, yarn or pnpm. Currently yarnpkg 4 is in experimental, I would like these things completed before we upload it to unstable. 1. Test the yarnpkg from experimental a bit, for example try to use it in gitlab 2. Document how to use corepack yarn or node_modules plugin to get yarn 1.x 3. Create a NEWS file in yarnpkg to mention how to get yarn 1 behavior, either by using corepack or by enabling node_modules plugin. So please test yarnpkg from experimental and report any problems you notice. Regards.
Bug#1033374: pre-unblock: ruby-rack/2.2.6.4-1
Control: tags -1 -moreinfo
Control: retitle -1 unblock: ruby-rack/2.2.6.4-1
On Fri, Mar 24 2023 at 06:45:30 PM +01:00:00 +01:00:00, Sebastian
Ramacher wrote:
Control: tags -1 moreinfo
On 2023-03-24 01:50:25 +0530, Pirate Praveen wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ruby-r...@packages.debian.org
Control: affects -1 + src:ruby-rack
Please see these changes for ruby-rack (I have not uploaded yet) is
ok.
Please go ahead and let us know once the package is available in
unstable.
Uploaded ruby-rack/2.2.6.4-1 to unstable.
Cheers
[ Reason ]
It fixes two CVEs (though it includes some other bug fixes too)
[ Impact ]
Some of the changes included in this release are already included
in the
debian package as patches, this just reduces maintenance effort.
[ Tests ]
Upstream testsuite passes, gitlab is already using the 2.2.6.4
version.
[ Risks ]
If this is not unblocked, two CVEs would have to be backported to
2.2.4
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock ruby-rack/2.2.6.4-1
diff -Nru ruby-rack-2.2.4/CHANGELOG.md
ruby-rack-2.2.6.4/CHANGELOG.md
--- ruby-rack-2.2.4/CHANGELOG.md 2022-07-01 03:48:29.0 +0530
+++ ruby-rack-2.2.6.4/CHANGELOG.md 2023-03-13 23:37:51.0
+0530
@@ -2,6 +2,33 @@
All notable changes to this project will be documented in this
file. For info on how to format all future additions to this file
please reference [Keep A
Changelog](https://keepachangelog.com/en/1.0.0/).
+## [2.2.6.4] - 2023-03-13
+
+- [CVE-2023-27539] Avoid ReDoS in header parsing
+
+## [2.2.6.3] - 2023-03-02
+
+- [CVE-2023-27530] Introduce multipart_total_part_limit to limit
total parts
+
+## [2.2.6.2] - 2022-01-17
+
+- [CVE-2022-44570] Fix ReDoS in Rack::Utils.get_byte_ranges
+
+## [2.2.6.1] - 2022-01-17
+
+- [CVE-2022-44571] Fix ReDoS vulnerability in multipart parser
+- [CVE-2022-44572] Forbid control characters in attributes (also
ReDoS)
+
+## [2.2.6] - 2022-01-17
+
+- Extend `Rack::MethodOverride` to handle
`QueryParser::ParamsTooDeepError` error.
([#2011](https://github.com/rack/rack/pull/2011),
[@byroot](https://github.com/byroot))
+
+## [2.2.5] - 2022-12-27
+
+### Fixed
+
+- `Rack::URLMap` uses non-deprecated form of `Regexp.new`.
([#1998](https://github.com/rack/rack/pull/1998),
[@weizheheng](https://github.com/weizheheng))
+
## [2.2.4] - 2022-06-30
- Better support for lower case headers in `Rack::ETag`
middleware. ([#1919](https://github.com/rack/rack/pull/1919),
[@ioquatix](https://github.com/ioquatix))
diff -Nru ruby-rack-2.2.4/debian/changelog
ruby-rack-2.2.6.4/debian/changelog
--- ruby-rack-2.2.4/debian/changelog 2023-02-09 16:17:17.0
+0530
+++ ruby-rack-2.2.6.4/debian/changelog 2023-03-24
01:32:43.0 +0530
@@ -1,3 +1,10 @@
+ruby-rack (2.2.6.4-1) unstable; urgency=medium
+
+ * Team Upload
+ * New upstream version 2.2.6.4 (Fixes: CVE-2023-27530,
CVE-2023-27539)
+
+ -- Pirate Praveen Fri, 24 Mar 2023 01:32:43
+0530
+
ruby-rack (2.2.4-3) unstable; urgency=high
* Team upload
diff -Nru
ruby-rack-2.2.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch
ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch
---
ruby-rack-2.2.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch 2023-02-09
16:17:17.0 +0530
+++
ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch 1970-01-01
05:30:00.0 +0530
@@ -1,26 +0,0 @@
a/lib/rack/utils.rb
-+++ b/lib/rack/utils.rb
-@@ -348,17 +348,18 @@
- return nil unless http_range && http_range =~
/bytes=([^;]+)/
- ranges = []
- $1.split(/,\s*/).each do |range_spec|
--return nil unless range_spec =~ /(\d*)-(\d*)/
--r0, r1 = $1, $2
--if r0.empty?
-- return nil if r1.empty?
-+return nil unless range_spec.include?('-')
-+range = range_spec.split('-')
-+r0, r1 = range[0], range[1]
-+if r0.nil? || r0.empty?
-+ return nil if r1.nil?
- # suffix-byte-range-spec, represents trailing suffix of
file
- r0 = size - r1.to_i
- r0 = 0 if r0 < 0
- r1 = size - 1
- else
- r0 = r0.to_i
-- if r1.empty?
-+ if r1.nil?
- r1 = size - 1
- else
- r1 = r1.to_i
diff -Nru
ruby-rack-2.2.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch
ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch
---
ruby-rack-2.2.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch 2023-02-09
16:17:17.0 +0530
+++
r
Bug#1033374: pre-unblock: ruby-rack/2.2.6.4-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ruby-r...@packages.debian.org
Control: affects -1 + src:ruby-rack
Please see these changes for ruby-rack (I have not uploaded yet) is ok.
[ Reason ]
It fixes two CVEs (though it includes some other bug fixes too)
[ Impact ]
Some of the changes included in this release are already included in
the debian package as patches, this just reduces maintenance effort.
[ Tests ]
Upstream testsuite passes, gitlab is already using the 2.2.6.4 version.
[ Risks ]
If this is not unblocked, two CVEs would have to be backported to 2.2.4
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock ruby-rack/2.2.6.4-1
diff -Nru ruby-rack-2.2.4/CHANGELOG.md ruby-rack-2.2.6.4/CHANGELOG.md
--- ruby-rack-2.2.4/CHANGELOG.md 2022-07-01 03:48:29.0 +0530
+++ ruby-rack-2.2.6.4/CHANGELOG.md 2023-03-13 23:37:51.0 +0530
@@ -2,6 +2,33 @@
All notable changes to this project will be documented in this file. For info on how to format all future additions to this file please reference [Keep A Changelog](https://keepachangelog.com/en/1.0.0/).
+## [2.2.6.4] - 2023-03-13
+
+- [CVE-2023-27539] Avoid ReDoS in header parsing
+
+## [2.2.6.3] - 2023-03-02
+
+- [CVE-2023-27530] Introduce multipart_total_part_limit to limit total parts
+
+## [2.2.6.2] - 2022-01-17
+
+- [CVE-2022-44570] Fix ReDoS in Rack::Utils.get_byte_ranges
+
+## [2.2.6.1] - 2022-01-17
+
+- [CVE-2022-44571] Fix ReDoS vulnerability in multipart parser
+- [CVE-2022-44572] Forbid control characters in attributes (also ReDoS)
+
+## [2.2.6] - 2022-01-17
+
+- Extend `Rack::MethodOverride` to handle `QueryParser::ParamsTooDeepError` error. ([#2011](https://github.com/rack/rack/pull/2011), [@byroot](https://github.com/byroot))
+
+## [2.2.5] - 2022-12-27
+
+### Fixed
+
+- `Rack::URLMap` uses non-deprecated form of `Regexp.new`. ([#1998](https://github.com/rack/rack/pull/1998), [@weizheheng](https://github.com/weizheheng))
+
## [2.2.4] - 2022-06-30
- Better support for lower case headers in `Rack::ETag` middleware. ([#1919](https://github.com/rack/rack/pull/1919), [@ioquatix](https://github.com/ioquatix))
diff -Nru ruby-rack-2.2.4/debian/changelog ruby-rack-2.2.6.4/debian/changelog
--- ruby-rack-2.2.4/debian/changelog 2023-02-09 16:17:17.0 +0530
+++ ruby-rack-2.2.6.4/debian/changelog 2023-03-24 01:32:43.0 +0530
@@ -1,3 +1,10 @@
+ruby-rack (2.2.6.4-1) unstable; urgency=medium
+
+ * Team Upload
+ * New upstream version 2.2.6.4 (Fixes: CVE-2023-27530, CVE-2023-27539)
+
+ -- Pirate Praveen Fri, 24 Mar 2023 01:32:43 +0530
+
ruby-rack (2.2.4-3) unstable; urgency=high
* Team upload
diff -Nru ruby-rack-2.2.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch
--- ruby-rack-2.2.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch 2023-02-09 16:17:17.0 +0530
+++ ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch 1970-01-01 05:30:00.0 +0530
@@ -1,26 +0,0 @@
a/lib/rack/utils.rb
-+++ b/lib/rack/utils.rb
-@@ -348,17 +348,18 @@
- return nil unless http_range && http_range =~ /bytes=([^;]+)/
- ranges = []
- $1.split(/,\s*/).each do |range_spec|
--return nil unless range_spec =~ /(\d*)-(\d*)/
--r0, r1 = $1, $2
--if r0.empty?
-- return nil if r1.empty?
-+return nil unless range_spec.include?('-')
-+range = range_spec.split('-')
-+r0, r1 = range[0], range[1]
-+if r0.nil? || r0.empty?
-+ return nil if r1.nil?
- # suffix-byte-range-spec, represents trailing suffix of file
- r0 = size - r1.to_i
- r0 = 0 if r0 < 0
- r1 = size - 1
- else
- r0 = r0.to_i
-- if r1.empty?
-+ if r1.nil?
- r1 = size - 1
- else
- r1 = r1.to_i
diff -Nru ruby-rack-2.2.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch
--- ruby-rack-2.2.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch 2023-02-09 16:17:17.0 +0530
+++ ruby-rack-2.2.6.4/debian/patches/Fix-ReDoS-vulnerability-in-multipart-parser.patch 1970-01-01 05:30:00.0 +0530
@@ -1,11 +0,0 @@
a/lib/rack/multipart.rb
-+++ b/lib/rack/multipart.rb
-@@ -18,7 +18,7 @@
- VALUE = /"(?:\\"|[^"])*"|#{TOKEN}/
- BROKEN = /^#{CONDISP}.*;\s*filename=(#{VALUE})/i
- MULTIPART_CONTENT_TYPE = /Content-Type: (.*)#{EOL}/ni
--MULTIPART_CONTENT_DISPOSITION = /Content-Disposition:.*;\s*name=(#{VALUE})/ni
-+MULTIPART_CONTENT_DISPOSITION
Re: Update on packaging corepack
On Tue, Mar 21 2023 at 09:06:41 PM +01:00:00 +01:00:00, Paul Gevers wrote: Hi Pirate, Thanks for reaching out. On 20-03-2023 16:44, Pirate Praveen wrote: I request bookworm-ignore tags for these bugs (as such there is no immediate breakage, just unmaintained upstreams for these packages). > yarnpkg: 980316,958686, 1002902, 980316 > node-har-validator: 1024575 > node-request: 956423 > node-request-capture-har: 1002901 As the packages in question are key packages, we can't easily remove them. Hence adding a bookworm-ignore tag doesn't really change the situation in bookworm in any way. Hence, the question is whether fixing it now and adding an exception is better or worse than letting the bug ship in bookworm. If I understand correctly, than the required change would mean a new complex package (corepack) which (again, if I understand correctly) is considered also by you as inappropriate at this time. If you confirm my understanding, I agree that those bugs can be marked bookworm-ignore (I already marked them as bookworm-can-defer, which is less strong and less official). We won't be able to complete corepack in a few weeks or months. So we have to ship bookworm with these bugs and get this fixed in time for trixie. Paul
Re: Update on packaging corepack
On Thu, 16 Mar 2023 10:23:53 +0100 Israel Galadima
wrote:
> Hi,
>
> Michael and I have done some packaging work for corepack.
> Of note, we have updated clipanion and packaged some dependencies of
> proxy-agent.
>
> Although, some of our work is awaiting uploads because of the freeze.
>
> Regards.
We tried to update yarnpkg as part of an outreachy project (in two
rounds), but we could not complete it in time for bookworm. As shared
by Israel, we made some good progress and we hope to be able to do it
in trixie. I request bookworm-ignore tags for these bugs (as such there
is no immediate breakage, just unmaintained upstreams for these
packages). Hopefully we can handle any security updates ourselves.
Additionally, even though yarnpkg itself is old, the presence of the
package makes it easy to obtain a newer yarnpkg. In gitlab, I already
use the packaged yarnpkg command to install a newer yarnpkg[1]. It is
also very common in nodejs world to use specific version of yarnpkg for
each project, these are typically installed in .yarn directory for each
project.
yarnpkg: 980316,958686, 1002902, 980316
node-har-validator: 1024575
node-request: 956423
node-request-capture-har: 1002901
[1]
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/rake-tasks.sh#L44
runuser -u ${gitlab_user} -- sh -c 'yarnpkg set version berry'
Bug#1033218: unblock: ruby-kubeclient/4.9.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ruby-kubecli...@packages.debian.org Control: affects -1 + src:ruby-kubeclient Please unblock package ruby-kubeclient [ Reason ] Fixes ftbfs/rc bug #1032551 [ Impact ] package ftbfs [ Tests ] Upstream tests passed. [ Risks ] This was discussed with upstream and it is safe to ignore these failures. https://github.com/ManageIQ/kubeclient/issues/609 [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock ruby-kubeclient/4.9.3-2 diff -Nru ruby-kubeclient-4.9.3/debian/changelog ruby-kubeclient-4.9.3/debian/changelog --- ruby-kubeclient-4.9.3/debian/changelog 2022-08-21 16:34:09.0 +0530 +++ ruby-kubeclient-4.9.3/debian/changelog 2023-03-20 12:34:36.0 +0530 @@ -1,3 +1,9 @@ +ruby-kubeclient (4.9.3-2) unstable; urgency=medium + + * Disable tests that checks expired certificates (Closes: #1032551) + + -- Pirate Praveen Mon, 20 Mar 2023 12:34:36 +0530 + ruby-kubeclient (4.9.3-1) unstable; urgency=medium [ vinay-keshava ] diff -Nru ruby-kubeclient-4.9.3/debian/patches/disable-expired-certs-test.patch ruby-kubeclient-4.9.3/debian/patches/disable-expired-certs-test.patch --- ruby-kubeclient-4.9.3/debian/patches/disable-expired-certs-test.patch 1970-01-01 05:30:00.0 +0530 +++ ruby-kubeclient-4.9.3/debian/patches/disable-expired-certs-test.patch 2023-03-20 12:34:36.0 +0530 @@ -0,0 +1,16 @@ +These are expired certificates and regenrating them currently require creating +a k0s cluster. + +Forwarded: https://github.com/ManageIQ/kubeclient/issues/609 + +--- a/test/test_config.rb b/test/test_config.rb +@@ -232,7 +232,7 @@ + if custom_ca + # When certificates expire one way to recreate them is using a k0s single-node cluster: + # test/config/update_certs_k0s.rb +-assert(context.ssl_options[:cert_store].verify(context.ssl_options[:client_cert])) ++#assert(context.ssl_options[:cert_store].verify(context.ssl_options[:client_cert])) + end + else + assert_nil(context.ssl_options[:client_cert]) diff -Nru ruby-kubeclient-4.9.3/debian/patches/series ruby-kubeclient-4.9.3/debian/patches/series --- ruby-kubeclient-4.9.3/debian/patches/series 2022-08-21 16:34:09.0 +0530 +++ ruby-kubeclient-4.9.3/debian/patches/series 2023-03-20 12:34:36.0 +0530 @@ -1,2 +1,3 @@ remove-bundler.patch remove-git-in-gemspec.patch +disable-expired-certs-test.patch
Bug#1033216: unblock: ruby-globalid/0.6.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ruby-globa...@packages.debian.org
Control: affects -1 + src:ruby-globalid
Please unblock package ruby-globalid
[ Reason ]
Fixes CVE-2023-22799/#1029851
[ Impact ]
Security issue
[ Tests ]
Upstream test suite passing.
[ Risks ]
Patch backported from upstream and applies cleanly.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock ruby-globalid/0.6.0-2
diff -Nru ruby-globalid-0.6.0/debian/changelog ruby-globalid-0.6.0/debian/changelog
--- ruby-globalid-0.6.0/debian/changelog 2021-11-30 09:42:23.0 +0530
+++ ruby-globalid-0.6.0/debian/changelog 2023-03-19 17:58:06.0 +0530
@@ -1,3 +1,17 @@
+ruby-globalid (0.6.0-2) unstable; urgency=medium
+
+ * Team Upload
+
+ [ Debian Janitor ]
+ * Remove constraints unnecessary since buster (oldstable):
++ Build-Depends: Drop versioned constraint on ruby-activesupport.
+
+ [ Pirate Praveen ]
+ * Fix CVE-2023-22799 (Closes: #1029851)
+ * Bump Standards-Version to 4.6.2 (no changes needed)
+
+ -- Pirate Praveen Sun, 19 Mar 2023 17:58:06 +0530
+
ruby-globalid (0.6.0-1) unstable; urgency=medium
* Team upload.
diff -Nru ruby-globalid-0.6.0/debian/control ruby-globalid-0.6.0/debian/control
--- ruby-globalid-0.6.0/debian/control 2021-11-30 09:42:23.0 +0530
+++ ruby-globalid-0.6.0/debian/control 2023-03-19 17:58:06.0 +0530
@@ -6,9 +6,9 @@
Build-Depends: debhelper-compat (= 13),
gem2deb,
rake,
- ruby-activesupport (>= 2:5.0),
+ ruby-activesupport,
ruby-rails
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
Vcs-Git: https://salsa.debian.org/ruby-team/ruby-globalid.git
Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-globalid
Homepage: https://github.com/rails/globalid
diff -Nru ruby-globalid-0.6.0/debian/patches/CVE-2023-22799.patch ruby-globalid-0.6.0/debian/patches/CVE-2023-22799.patch
--- ruby-globalid-0.6.0/debian/patches/CVE-2023-22799.patch 1970-01-01 05:30:00.0 +0530
+++ ruby-globalid-0.6.0/debian/patches/CVE-2023-22799.patch 2023-03-19 17:58:06.0 +0530
@@ -0,0 +1,48 @@
+From 3bc4349422e60f2235876a59dd415e98b072eb2b Mon Sep 17 00:00:00 2001
+From: Aaron Patterson
+Date: Tue, 17 Jan 2023 13:32:28 -0800
+Subject: [PATCH] Fix ReDoS vulnerability in name parsing
+
+Thanks to @ooo_q for the patch!
+
+[CVE-2023-22799]
+---
+ lib/global_id/uri/gid.rb | 11 ---
+ 1 file changed, 4 insertions(+), 7 deletions(-)
+
+--- a/lib/global_id/uri/gid.rb
b/lib/global_id/uri/gid.rb
+@@ -123,9 +123,6 @@
+ private
+ COMPONENT = [ :scheme, :app, :model_name, :model_id, :params ].freeze
+
+- # Extracts model_name and model_id from the URI path.
+- PATH_REGEXP = %r(\A/([^/]+)/?([^/]+)?\z)
+-
+ def check_host(host)
+ validate_component(host)
+ super
+@@ -145,11 +142,11 @@
+ end
+
+ def set_model_components(path, validate = false)
+-_, model_name, model_id = path.match(PATH_REGEXP).to_a
+-model_id = CGI.unescape(model_id) if model_id
+-
++_, model_name, model_id = path.split('/', 3)
+ validate_component(model_name) && validate_model_id(model_id, model_name) if validate
+
++model_id = CGI.unescape(model_id) if model_id
++
+ @model_name = model_name
+ @model_id = model_id
+ end
+@@ -162,7 +159,7 @@
+ end
+
+ def validate_model_id(model_id, model_name)
+-return model_id unless model_id.blank?
++return model_id unless model_id.blank? || model_id.include?('/')
+
+ raise MissingModelIdError, "Unable to create a Global ID for " \
+ "#{model_name} without a model id."
diff -Nru ruby-globalid-0.6.0/debian/patches/series ruby-globalid-0.6.0/debian/patches/series
--- ruby-globalid-0.6.0/debian/patches/series 2021-11-30 09:42:23.0 +0530
+++ ruby-globalid-0.6.0/debian/patches/series 2023-03-19 17:58:06.0 +0530
@@ -1 +1,2 @@
fix_test_helper.patch
+CVE-2023-22799.patch
Bug#1033194: unblock: ruby-asciidoctor-include-ext/0.4.0-2
On Sun, Mar 19 2023 at 02:31:02 PM +01:00:00 +01:00:00, Sebastian Ramacher wrote: This type of change is not acceptable during hard freeze. Please revert. ok then we can just remove the version currently in testing.
Bug#1033194: unblock: ruby-asciidoctor-include-ext/0.4.0-2
Control: tags -1 -moreinfo
On Sun, Mar 19 2023 at 01:40:57 PM +01:00:00 +01:00:00, Sebastian
Ramacher wrote:
Control: tags -1 moreinfo
Please provide a debdiff
debdiff attached.
diff -Nru ruby-asciidoctor-include-ext-0.3.1/asciidoctor-include-ext.gemspec ruby-asciidoctor-include-ext-0.4.0/asciidoctor-include-ext.gemspec
--- ruby-asciidoctor-include-ext-0.3.1/asciidoctor-include-ext.gemspec 2019-08-22 14:40:31.0 +0530
+++ ruby-asciidoctor-include-ext-0.4.0/asciidoctor-include-ext.gemspec 2022-05-06 12:42:42.0 +0530
@@ -1,4 +1,4 @@
-require File.expand_path('../lib/asciidoctor/include_ext/version', __FILE__)
+require File.expand_path('lib/asciidoctor/include_ext/version', __dir__)
Gem::Specification.new do |s|
s.name= 'asciidoctor-include-ext'
@@ -9,24 +9,22 @@
s.license = 'MIT'
s.summary = "Asciidoctor's standard include::[] processor reimplemented as an extension"
- s.description = <= 1.5.6', '< 3.0.0'
- s.add_development_dependency 'corefines', '~> 1.11'
- s.add_development_dependency 'kramdown', '~> 1.16'
- s.add_development_dependency 'rake', '~> 12.0'
+ s.add_development_dependency 'kramdown', '~> 2.0'
+ s.add_development_dependency 'rake', '~> 13.0'
s.add_development_dependency 'rspec', '~> 3.7'
s.add_development_dependency 'rubocop', '~> 0.51.0'
s.add_development_dependency 'simplecov', '~> 0.15'
diff -Nru ruby-asciidoctor-include-ext-0.3.1/debian/changelog ruby-asciidoctor-include-ext-0.4.0/debian/changelog
--- ruby-asciidoctor-include-ext-0.3.1/debian/changelog 2019-09-04 13:58:01.0 +0530
+++ ruby-asciidoctor-include-ext-0.4.0/debian/changelog 2023-03-19 17:22:18.0 +0530
@@ -1,3 +1,36 @@
+ruby-asciidoctor-include-ext (0.4.0-2) unstable; urgency=medium
+
+ * Team Upload
+ * Reupload to unstable (gitlab is only reverse dependency, which is not in
+testing)
+ * Bump Standards-Version to 4.6.2 (no changes needed)
+ * Switch to ${ruby:Depends} for ruby dependencies
+
+ -- Pirate Praveen Sun, 19 Mar 2023 17:22:18 +0530
+
+ruby-asciidoctor-include-ext (0.4.0-1) experimental; urgency=medium
+
+ * Team upload
+
+ [ Debian Janitor ]
+ * Bump debhelper from old 11 to 12.
+ * Set debhelper-compat version in Build-Depends.
+ * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
+Repository-Browse.
+ * Update standards version to 4.5.0, no changes needed.
+ * Update watch file format version to 4.
+ * Remove constraints unnecessary since buster:
++ Build-Depends: Drop versioned constraint on ruby-asciidoctor.
++ ruby-asciidoctor-include-ext: Drop versioned constraint on
+ ruby-asciidoctor in Depends.
+
+ [ Pirate Praveen ]
+ * New upstream version 0.4.0
+ * Bump Standards-Version to 4.6.1 (no changes needed)
+ * Bump debhelper compatibility level to 13
+
+ -- Pirate Praveen Sun, 26 Jun 2022 22:48:20 +0530
+
ruby-asciidoctor-include-ext (0.3.1-2) unstable; urgency=medium
* Team upload
diff -Nru ruby-asciidoctor-include-ext-0.3.1/debian/compat ruby-asciidoctor-include-ext-0.4.0/debian/compat
--- ruby-asciidoctor-include-ext-0.3.1/debian/compat 2019-09-04 13:58:01.0 +0530
+++ ruby-asciidoctor-include-ext-0.4.0/debian/compat 1970-01-01 05:30:00.0 +0530
@@ -1 +0,0 @@
-11
diff -Nru ruby-asciidoctor-include-ext-0.3.1/debian/control ruby-asciidoctor-include-ext-0.4.0/debian/control
--- ruby-asciidoctor-include-ext-0.3.1/debian/control 2019-09-04 13:58:01.0 +0530
+++ ruby-asciidoctor-include-ext-0.4.0/debian/control 2023-03-19 17:22:18.0 +0530
@@ -1,13 +1,13 @@
Source: ruby-asciidoctor-include-ext
Section: ruby
Priority: optional
-Maintainer: Debian Ruby Extras Maintainers
+Maintainer: Debian Ruby Team
Uploaders: Sruthi Chandran
-Build-Depends: debhelper (>= 11~),
+Build-Depends: debhelper-compat (= 13),
gem2deb,
ruby-asciidoctor (<< 3.0.0),
- ruby-asciidoctor (>= 1.5.6)
-Standards-Version: 4.3.0
+ ruby-asciidoctor
+Standards-Version: 4.6.2
Vcs-Git: https://salsa.debian.org/ruby-team/ruby-asciidoctor-include-ext.git
Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-asciidoctor-include-ext
Homepage: https://github.com/jirutka/asciidoctor-include-ext
@@ -18,9 +18,7 @@
Package: ruby-asciidoctor-include-ext
Architecture: all
XB-Ruby-Versions: ${ruby:Versions}
-Depends: ruby | ruby-interpreter,
- ruby-asciidoctor (<< 3.0.0),
- ruby-asciidoctor (>= 1.5.6),
+Depends: ${ruby:Depends},
${misc:Depends},
${shlibs:Depends}
Description: Asciidoctor's standard include::[] processor reimplemented as an extension
diff -Nru ruby-asciidoctor-include-ext-0.3.1/debian
Bug#1033194: unblock: ruby-asciidoctor-include-ext/0.4.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ruby-asciidoctor-include-...@packages.debian.org Control: affects -1 + src:ruby-asciidoctor-include-ext Please unblock package ruby-asciidoctor-include-ext [ Reason ] This fixes a security issue CVE-2022-24803/#1009035 though it also includes an upstream update. This was uploaded to experimental on 2022-06-26 but missed reuploading to unstable as gitlab was using the versions directly from experimental (it was uploaded to experimental to not break the previos gitlab version before it switched to 0.4 version). Noticed this today in the rc bug list. [ Impact ] Only reverse dependency is gitlab so it should not impact any other package in bookworm. [ Tests ] gitlab in experimental was using it already for quite some time (upstream gitlab tests are fine) [ Risks ] For bookworm it is a leaf package (only used by gitlab which is in unstable/experimental only) [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] Since it has some other upstream changes, I have not included the debdiff. unblock ruby-asciidoctor-include-ext/0.4.0-2
Bug#1033070: unblock: node-babel7/7.20.15+ds1+~cs214.269.168-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: node-bab...@packages.debian.org Control: affects -1 + src:node-babel7 Please unblock package node-babel7 [ Reason ] This prevents breaking partial upgrades by updating minimum version of node-regexpu-core [ Impact ] gitlab partial upgrade from bullseye to bookworm is found to break when node-regexpu-core is not upgraded. https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192 [ Tests ] No upstream code changed, only minimum version of dependency is updated. [ Risks ] No upstream code changed, only minimum version of dependency is updated. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock node-babel7/7.20.15+ds1+~cs214.269.168-2 diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog --- node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 2023-02-17 13:35:54.0 +0530 +++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog 2023-03-16 17:52:46.0 +0530 @@ -1,3 +1,11 @@ +node-babel7 (7.20.15+ds1+~cs214.269.168-2) unstable; urgency=medium + + * Update minimum version of node-regexpu-core to 5.2.1~. +packages/babel-helper-create-regexp-features-plugin/package.json has +"regexpu-core": "^5.2.1" and not adding it breaks partial upgrades. + + -- Pirate Praveen Thu, 16 Mar 2023 17:52:46 +0530 + node-babel7 (7.20.15+ds1+~cs214.269.168-1) unstable; urgency=medium * Team upload diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/control node-babel7-7.20.15+ds1+~cs214.269.168/debian/control --- node-babel7-7.20.15+ds1+~cs214.269.168/debian/control 2023-02-17 13:35:54.0 +0530 +++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/control 2023-03-16 17:52:20.0 +0530 @@ -108,7 +108,7 @@ , node-make-dir , node-quick-lru , node-regenerator-transform (>= 0.14~) - , node-regexpu-core + , node-regexpu-core (>= 5.2.1~) , node-resolve , node-semver (>= 7.0~) , node-slash
Bug#1032962: unblock: node-regexpu-core/5.2.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: node-regexpu-c...@packages.debian.org
Control: affects -1 + src:node-regexpu-core
Please unblock package node-regexpu-core
[ Reason ]
This ensure required node-unicode-match-property-ecmascript is used
during upgrades
from bullseye.
This minimum version requirement is already mentioned in package.json
by upstream
but missed when preparing the package.
[ Impact ]
This was noticed when testing gitlab upgrade from bullseye-fasttrack to
bookworm-fasttrack
https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192#note_9747
If this is not accepted, either gitlab will have to add this version
constraint
or the user will have to update this package manually. Gitlab being
very brittle
about its large dependency chains, directly running a dist-upgrade may
not be the
best method of upgrade. So it is recommended to upgrade gitlab first
and then do
the dist-upgrade.
[ Tests ]
No change in upstream code only and implicit dependency made explicit.
[ Risks ]
This only changes minimum version of a dependency which is already
satisfied in
bookworm but not in bullseye.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock node-regexpu-core/5.2.2-3
diff -Nru node-regexpu-core-5.2.2/debian/changelog node-regexpu-core-5.2.2/debian/changelog
--- node-regexpu-core-5.2.2/debian/changelog 2022-11-30 22:02:03.0 +0530
+++ node-regexpu-core-5.2.2/debian/changelog 2023-03-14 15:01:43.0 +0530
@@ -1,3 +1,12 @@
+node-regexpu-core (5.2.2-3) unstable; urgency=medium
+
+ * Team upload
+ * Update node-unicode-match-property-ecmascript minimum version to (>= 2.0~)
+(This is required to fix breakage in babel-loader when upgrading from
+bullseye)
+
+ -- Pirate Praveen Tue, 14 Mar 2023 15:01:43 +0530
+
node-regexpu-core (5.2.2-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru node-regexpu-core-5.2.2/debian/control node-regexpu-core-5.2.2/debian/control
--- node-regexpu-core-5.2.2/debian/control 2022-11-30 22:02:03.0 +0530
+++ node-regexpu-core-5.2.2/debian/control 2023-03-14 15:01:43.0 +0530
@@ -13,7 +13,7 @@
node-regjsgen,
node-regjsparser (>= 0.6.4~),
node-unicode-15.0.0,
- node-unicode-match-property-ecmascript,
+ node-unicode-match-property-ecmascript (>= 2.0~),
node-unicode-match-property-value-ecmascript (>= 2.1~),
dh-sequence-nodejs
Standards-Version: 4.6.1
@@ -28,7 +28,7 @@
node-regenerate-unicode-properties (>= 10.1~),
node-regjsgen,
node-regjsparser (>= 0.6.4~),
- node-unicode-match-property-ecmascript,
+ node-unicode-match-property-ecmascript (>= 2.0~),
node-unicode-match-property-value-ecmascript (>= 2.1~),
${misc:Depends}
Multi-Arch: foreign
Bug#1021482: nmu: ruby-pg-query_2.1.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ruby-pg-query_2.1.0-2 . ANY . experimental . -m "Rebuild with ruby 3.1"
Bug#1021128: nmu: grpc_1.44.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Control: block 1021113 by -1 nmu grpc_1.44.0-3 . ANY . experimental . -m "Rebuild with libabsl20220623"
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu ൽ എഴുതി >On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon wrote: >> Yes, that's the error. "String.matchAll is only available from Node.js >> 12.0 onwards", according to >> https://stackoverflow.com/questions/58558257/string-matchall-is-undefined >> , which also says that String.match is available. I didn't put any >> effort into working around it (either backporting a newer nodejs or >> replacing all String.matchAlls with something else), since I wanted to >> get chromium shipped for bullseye. > >Thanks for your confirmation! >So we're on the same page. >I tried to backport nodejs 12 from bullseye to buster, but seems >nodejs 12 cannot coexist with nodejs 10, which means unless I backport >all the nodejs related packages, which has quite a long list ... >That's out of my capacity, so I give up. I think using babel (already packaged) to transpile the js to run on nodejs 10 could be another option. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#992206: bullseye-pu: package ruby-rqrcode-rails3/0.1.7-1.1
Control: tags -1 -moreinfo 2021, സെപ്റ്റംബർ 4 3:24:42 PM IST, Jonathan Wiltshire ൽ എഴുതി >Control: tag -1 confirmed moreinfo > >On Mon, Aug 16, 2021 at 01:02:42AM +0530, Pirate Praveen wrote: >> This rc bug was detected very late in freeze so it could not get into >> bullseye. >> >> [ Reason ] >> This package was broken with ruby-rqrcode 1.0 update. See #992040 > >Please go ahead, and remove this bug's moreinfo tag when uploaded. Uploaded and tag removed. Thanks! >Thanks, > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#992206: bullseye-pu: package ruby-rqrcode-rails3/0.1.7-1.1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
This rc bug was detected very late in freeze so it could not get into
bullseye.
[ Reason ]
This package was broken with ruby-rqrcode 1.0 update. See #992040
[ Impact ]
They will have an incompatible and broken package.
[ Tests ]
This was found when testing 2FA authentication in gitlab package and
the fix was tested in gitlab and the 2FA feature was working in the
fixed versions.
[ Risks ]
gitlab is its only reverse dependency which is not in bullseye.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
API is adjusted to work with ruby-rqrcode shipped with bullseye.
[ Other info ]
The patch was taken from an upstream issue (though upstream is not very
active)
diff -Nru ruby-rqrcode-rails3-0.1.7/debian/changelog ruby-rqrcode-rails3-0.1.7/debian/changelog
--- ruby-rqrcode-rails3-0.1.7/debian/changelog 2021-01-05 20:52:02.0 +0530
+++ ruby-rqrcode-rails3-0.1.7/debian/changelog 2021-08-16 00:40:15.0 +0530
@@ -1,3 +1,10 @@
+ruby-rqrcode-rails3 (0.1.7-1.1+deb11u1) bullseye; urgency=medium
+
+ * Fix for ruby-rqrcode 1.0 compatibility (Thanks to Florence Foo)
+(Closes: #992040)
+
+ -- Pirate Praveen Mon, 16 Aug 2021 00:40:15 +0530
+
ruby-rqrcode-rails3 (0.1.7-1.1) unstable; urgency=medium
* Non maintainer upload by the Reproducible Builds team.
diff -Nru ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch
--- ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch 1970-01-01 05:30:00.0 +0530
+++ ruby-rqrcode-rails3-0.1.7/debian/patches/rqrcode-1.x-compat.patch 2021-08-16 00:20:04.0 +0530
@@ -0,0 +1,36 @@
+https://github.com/samvincent/rqrcode-rails3/compare/master...pandamouse:rqrcode-core-0.1.1.patch
+
+From bc86ea646010ab0e6d089d80f1533b7836315776 Mon Sep 17 00:00:00 2001
+From: Florence Foo
+Date: Thu, 2 Jan 2020 17:07:55 +1100
+Subject: [PATCH 1/2] RQRCode.render_qrcode raises NoMethodError #21
+
+- use RQRCodeCore
+ - is_dark? -> dark?
+---
+ lib/rqrcode-rails3.rb | 2 +-
+ lib/rqrcode-rails3/renderers/svg.rb | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/lib/rqrcode-rails3.rb
b/lib/rqrcode-rails3.rb
+@@ -15,7 +15,7 @@
+ size = options[:size] || RQRCode.minimum_qr_size_from_string(string)
+ level = options[:level] || :h
+
+-qrcode = RQRCode::QRCode.new(string, :size => size, :level => level)
++qrcode = RQRCodeCore::QRCode.new(string, :size => size, :level => level)
+ svg= RQRCode::Renderers::SVG::render(qrcode, options)
+
+ if format && format == :svg
+--- a/lib/rqrcode-rails3/renderers/svg.rb
b/lib/rqrcode-rails3/renderers/svg.rb
+@@ -28,7 +28,7 @@
+ y = c*unit + offset
+ x = r*unit + offset
+
+- next unless qrcode.is_dark(c, r)
++ next unless qrcode.checked?(c, r)
+ tmp << %{}
+ end
+ result << tmp.join
diff -Nru ruby-rqrcode-rails3-0.1.7/debian/patches/series ruby-rqrcode-rails3-0.1.7/debian/patches/series
--- ruby-rqrcode-rails3-0.1.7/debian/patches/series 1970-01-01 05:30:00.0 +0530
+++ ruby-rqrcode-rails3-0.1.7/debian/patches/series 2021-08-16 00:20:04.0 +0530
@@ -0,0 +1 @@
+rqrcode-1.x-compat.patch
Bug#990550: [Pre-Approval] unblock: node-babel-plugin-add-module-exports/1.0.4+dfsg1~cs5.8.0-2
Control: retitle -1 unblock autosize.js/4.0.2~dfsg1-7 On Sat, 03 Jul 2021 17:47:29 +0530 Pirate Praveen wrote: > On Thu, 01 Jul 2021 23:28:12 +0530 Pirate Praveen > wrote: > > I'd like to check if we can unblock package > > node-babel-plugin-add-module-exports (currently in experimental) with > > its reverse build dependencies. > > Looks like this update does not actually fix the issue with > libjs-autosize build. So I will keep this bug open for a few days as I > test other options, but we don't need to unblock this for now. Fixed libjs-autosize by switching to rollup and removing node-babel-plugin-add-module-exports build dependency. So I'd like to change this to an unblock request for autosize.js
Bug#990550: [Pre-Approval] unblock: node-babel-plugin-add-module-exports/1.0.4+dfsg1~cs5.8.0-2
On Thu, 01 Jul 2021 23:28:12 +0530 Pirate Praveen wrote: > I'd like to check if we can unblock package > node-babel-plugin-add-module-exports (currently in experimental) with > its reverse build dependencies. Looks like this update does not actually fix the issue with libjs-autosize build. So I will keep this bug open for a few days as I test other options, but we don't need to unblock this for now.
Bug#988012: Bug#988190: unblock: diaspora-installer/0.7.14.0+debian2
On 2021, മേയ് 15 11:42:16 AM IST, Paul Gevers wrote: >Hi Pirate, > >On 14-05-2021 12:46, Pirate Praveen wrote: >> (There was comment on the bug before the update, so not sure if the bug >pings are actually working) > >I pinged the bug yesterday and I see today that the autoremoval has been >delayed. All seems as intended. Thanks. >Paul > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#988012: Bug#988190: unblock: diaspora-installer/0.7.14.0+debian2
On 2021, മേയ് 8 1:00:01 AM IST, Paul Gevers wrote: >Hi Pirate, Jan, > >On 07-05-2021 11:37, Pirate Praveen wrote: >> Please unblock package diaspora-installer > >diaspora-installer is not blocked, nothing to do. Tracker says it will be auto removed by May 25 and 15 more days are needed for migration. Does it mean, this missed bullseye? action needed Marked for autoremoval on 25 May: #986286 high Version 0.7.14.0+debian2 of diaspora-installer is marked for autoremoval from testing on Tue 25 May 2021. It is affected by #986286. You should try to prevent the removal by fixing these RC bugs. Created: 2021-04-09 Last update: 2021-05-12 14:06 (There was comment on the bug before the update, so not sure if the bug pings are actually working) >Paul > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#988190: unblock: diaspora-installer/0.7.14.0+debian2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package diaspora-installer [ Reason ] This fixes rc bug #986286 [ Impact ] This is a grave bug and diaspora-installer installation itself breaks. [ Tests ] Manually tested the changes. [ Risks ] No risks as current package does not work. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] There was an nmu that fixes it with a patch, but that adds extra maintenance burden and switching to the fixed upstream version is easy to maintain. unblock diaspora-installer/0.7.14.0+debian2 diff -Nru diaspora-installer-0.7.14.0+debian2/debian/changelog diaspora-installer-0.7.15.0+debian/debian/changelog --- diaspora-installer-0.7.14.0+debian2/debian/changelog 2020-10-05 22:33:21.0 +0530 +++ diaspora-installer-0.7.15.0+debian/debian/changelog 2021-05-07 14:13:07.0 +0530 @@ -1,3 +1,12 @@ +diaspora-installer (0.7.15.0+debian) unstable; urgency=medium + + * Fix diaspora-sidekiq.service (make it part of gitlab.service) + * Update README and add details of systemd service files + * Mention debian specific documentation location at the end of installation + * Install diaspora 0.7.15 (Closes: #986286) + + -- Pirate Praveen Fri, 07 May 2021 14:13:07 +0530 + diaspora-installer (0.7.14.0+debian2) unstable; urgency=medium * Include changelog from experimental branch diff -Nru diaspora-installer-0.7.14.0+debian2/debian/diaspora-common.diaspora-sidekiq.service diaspora-installer-0.7.15.0+debian/debian/diaspora-common.diaspora-sidekiq.service --- diaspora-installer-0.7.14.0+debian2/debian/diaspora-common.diaspora-sidekiq.service 2020-10-05 22:33:21.0 +0530 +++ diaspora-installer-0.7.15.0+debian/debian/diaspora-common.diaspora-sidekiq.service 2021-05-07 14:13:07.0 +0530 @@ -4,7 +4,7 @@ Requires=redis-server.service Wants=postgresql.service After=redis-server.service postgresql.service -PartOf=gitlab.service +PartOf=diaspora.service ReloadPropagatedFrom=diaspora.service [Service] diff -Nru diaspora-installer-0.7.14.0+debian2/diaspora-common.conf diaspora-installer-0.7.15.0+debian/diaspora-common.conf --- diaspora-installer-0.7.14.0+debian2/diaspora-common.conf 2020-10-05 22:33:21.0 +0530 +++ diaspora-installer-0.7.15.0+debian/diaspora-common.conf 2021-05-07 14:13:07.0 +0530 @@ -1,5 +1,5 @@ # If diaspora_version is changed, update sha256sums as well -export diaspora_version=0.7.14.0 +export diaspora_version=0.7.15.0 # possible values branch, tag export diaspora_release_type=tag export github_archive_url=https://github.com/diaspora/diaspora/archive diff -Nru diaspora-installer-0.7.14.0+debian2/rake-tasks.sh diaspora-installer-0.7.15.0+debian/rake-tasks.sh --- diaspora-installer-0.7.14.0+debian2/rake-tasks.sh 2020-10-05 22:33:21.0 +0530 +++ diaspora-installer-0.7.15.0+debian/rake-tasks.sh 2021-05-07 14:13:07.0 +0530 @@ -13,8 +13,6 @@ echo "And reload nginx, run # /etc/init.d/nginx reload" fi -echo "To stop diaspora, run # /etc/init.d/diaspora stop" -echo "To see the service status, run # /etc/init.d/diaspora status" -echo "To start diaspora service, run # /etc/init.d/diaspora start" +echo "Debian specific documentation is available at /usr/share/doc/diaspora-common/README" echo "Visit your pod at $ENVIRONMENT_URL" diff -Nru diaspora-installer-0.7.14.0+debian2/README diaspora-installer-0.7.15.0+debian/README --- diaspora-installer-0.7.14.0+debian2/README 2020-10-05 22:33:21.0 +0530 +++ diaspora-installer-0.7.15.0+debian/README 2021-05-07 14:13:07.0 +0530 @@ -18,6 +18,8 @@ - contains the database configuration and diaspora configuration yml files which are copied to (/usr/share/diaspora) - contains the init script (which will be copied to /etc/init.d/diaspora) +- contains systemd unit files (diaspora.service, diaspora-sidekiq.service and + diaspora-unicorn.service) - contains diaspora.conf that is used during the setup - contains other scripts (adduser, grantpriv, explained later) @@ -29,13 +31,13 @@ - adduser.sh, grantpriv.sh, set-env-nginx.sh are put in /usr/lib/diaspora-common/scripts - diaspora-common.init becomes the /etc/init.d/diaspora +- systemd unit files are installed in /lib/systemd/system/ The "config" file gets run and -- sets all the variables required in /etc/diaspora.conf +- sets all the variables required in /etc/diaspora/diaspora.conf - copies nginx.conf.example to /etc/nginx-sites-available/ and symlinks in sites-enabled - diaspora-common postinst does the following: - runs adduser.sh to create 'diaspora' user with no login possible. - runs grantpriv.sh to set diaspora_production database's owner to diaspora. @@ -44,9 +46,11 @@ metadata d
Re: [Pkg-javascript-devel] Bug#982766: Bug#982766: node-webpack: remove dependency on node-uglifyjs-webpack-plugin
[Ccing debian-release] On Wed, 17 Feb 2021 14:01:40 + Julian Gilbey wrote: > On Sun, Feb 14, 2021 at 02:26:30PM +0100, Jonas Smedegaard wrote: > > I still recommend to request release team to ignore for this release > > instead of lowering sverity, but don't care anough about this particular > > mess to discuss further... > > Has the release team been contacted yet? Once it is dropped from > testing, it will not be reaccepted for bullseye. > 1. It is not marked for auto removal in tracker, so it will need a manual action from release team and they will see this bug before they remove. 2. Yadd already discussed about node-uglifyjs-webpack-plugin with release team. So in my understanding this package will be in bullseye. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: ruby-vcr: DFSG violation (Hippocratic license)
On 2021, മാർച്ച് 8 1:24:48 AM IST, Antonio Terceiro wrote: >On Sun, Mar 07, 2021 at 11:01:16PM +0530, Pirate Praveen wrote: >> [adding release team] >> >> On Sun, Mar 7, 2021 at 10:49 pm, Utkarsh Gupta wrote: >> > Hi Praveen, >> > >> > On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen >> > wrote: >> > > It looks like we will have to remove ruby-vcr and we will have to >> > > disable tests for the following packages. I don't think there is >> > > another way, thoughts? >> > >> > Maybe worth opening an issue upstream and discuss the cons of this >> > change or something? Or if that doesn't work out >> > and we need this >> >> I doubt discussing with upstream will yield any possitive outcome as this is >> a specific philosophical movement. >> >> See https://github.com/vcr/vcr/pull/792 >> and >> https://github.com/vcr/vcr/issues/804 >> >> > package or something, would forking be an option? >> >> https://github.com/vcr/vcr/blob/master/CHANGELOG.md#510-feb-5-2020 >> >> We will have to go back to 5.0 and someone will have to maintain it >> independently. >> >> Hi Release team, >> >> Do you think this needs to be fixed before bullseye? If yes, do you agree to >> change the reverse dependencies listed in my previous message to this bug? > >I don't think that will be needed. I reverted to 5.0.0 locally, added a >few patches, and at least all of our reverse dependencies seem to pass >their tests with it: > > >= Testing reverse (build) dependencies > > >rebuild nanoc ... PASS >rebuild ruby-coveralls ... PASS >autopkgtest ruby-faraday... PASS >rebuild ruby-graphlient ... PASS >rebuild ruby-mixlib-install ... PASS >rebuild ruby-octokit... PASS > >So in principle we could fix this issue without touching anything else. Thanks. Are you waiting for an ack from release team to upload it? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: ruby-vcr: DFSG violation (Hippocratic license)
[adding release team] On Sun, Mar 7, 2021 at 10:49 pm, Utkarsh Gupta wrote: Hi Praveen, On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen wrote: It looks like we will have to remove ruby-vcr and we will have to disable tests for the following packages. I don't think there is another way, thoughts? Maybe worth opening an issue upstream and discuss the cons of this change or something? Or if that doesn't work out and we need this I doubt discussing with upstream will yield any possitive outcome as this is a specific philosophical movement. See https://github.com/vcr/vcr/pull/792 and https://github.com/vcr/vcr/issues/804 package or something, would forking be an option? https://github.com/vcr/vcr/blob/master/CHANGELOG.md#510-feb-5-2020 We will have to go back to 5.0 and someone will have to maintain it independently. Hi Release team, Do you think this needs to be fixed before bullseye? If yes, do you agree to change the reverse dependencies listed in my previous message to this bug? Thanks Praveen
Bug#980032: [Pkg-javascript-devel] Bug#980032: RM: node-request/2.88.1-5
On Wed, Jan 13, 2021 at 12:22 pm, Xavier wrote: CC to pkg-javascript-devel for node-yarnpkg elements We can try to update yarnpkg to version 2 by building corepack [1]. I need help with these packages, New modules: clipanion terser-webpack-plugin ts-loader @zkochan/cmd-shim Update terser to 4.8 at least I'm currently trying to update node-babel7 in buster-backports and it can take some more time before I can get to these. We can embed a copy of request in yarnpkg as a last resort. [1] https://github.com/nodejs/corepack
Bug#971571: transition: libgit2
On Tue, 8 Dec 2020 11:00:40 +0100 Sebastian Ramacher wrote: > Filed #976820 against gitaly. I will follow it up with upstream. > In any case, I'll remove golang-gopkg-libgit2-git2go.v28 and > gitaly from testing to unblock this transition. gitaly is blocked by > ruby-faraday which is currently causing a bunch of autopkgtest > regressions. ruby-faraday will be unblocked if ruby-puppet-forge is removed from testing (the other two packages failing autopkgtest are already removed from unstable)
Bug#976344: RM: ruby-diaspora-federation/0.2.6-2
On Thu, Dec 3, 2020 at 19:26, Paul Gevers wrote: What I'm saying is that it helps to include such details in the original request. I already mentioned this, "Both diaspora and ruby-diaspora-federation-rails is not in testing (because they don't work with rails version 6)". I thought that was enough to convey ruby-diaspora-federation is not really useful being in testing.
Bug#976344: RM: ruby-diaspora-federation/0.2.6-2
On Thu, Dec 3, 2020 at 19:13, Paul Gevers wrote: Which is uploaded today. What's the hurry that you can't just fix ruby-diaspora-federation or wait for its autoremoval? You're one of it's uploaders. Because I don't think diaspora will be ready for bullseye (may be in bullseye-backports or bullseye-fasttrack), since it does not work with rails 6, so there is no incentive to fix ruby-diaspora-federation for bullseye. I don't think there is any point to delay ruby-faraday 1.0 migration for a package that is not really needed in bullseye. Are you saying we should not be proactively helping packages to migrate to testing?
Bug#976344: RM: ruby-diaspora-federation/0.2.6-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm This package is blocking ruby-faraday 1.0 migration to testing (#976343). Its only reverse dependency is ruby-diaspora-federation-rails, which in turn has only one other reverse dependency diaspora. Both diaspora and ruby-diaspora-federation-rails is not in testing (because they don't work with rails version 6). Please remove this package from testing to allow migration of ruby-faraday 1.0 to testing. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#969912: buster-pu: package diaspora-installer/0.7.6.1+debian1
Control: tags -1 - moreinfo
On Tue, Sep 8, 2020 at 22:49, Pirate Praveen
wrote:
On 2020, സെപ്റ്റംബർ 8 10:41:40 PM IST, "Adam D.
Barratt" wrote:
Control: tags -1 + moreinfo
On Tue, 2020-09-08 at 22:31 +0530, Pirate Praveen wrote:
This fixes upgrading from stretch-backports. Attaching the debdiff.
I noticed these issues when upgrading production instance at
https://diasp.in
Judging from the changelog, it looks like this change hasn't been
applied to the package in unstable yet. Is that correct?
Yes, that is correct.
I found the problem in stretch-backports and fixed that first. Then
moved to fixing buster. I intend to fix unstable too. If you want to
wait for fix in unstable, that'd be fine too.
These changes are now part of unstable (0.7.14.0+debian) and I included
one more important bug fix #926968 in the update (which was found when
upgrading from stretch-backports to buster). See the updated debdiff.
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/changelog diaspora-installer-0.7.6.1+debian1+deb10u1/debian/changelog
--- diaspora-installer-0.7.6.1+debian1/debian/changelog 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/changelog 2020-09-09 01:27:58.0 +0530
@@ -1,3 +1,12 @@
+diaspora-installer (0.7.6.1+debian1+deb10u1) buster; urgency=medium
+
+ * Use --frozen option to bundle install to use upstream Gemfile.lock
+ * Don't exclude Gemfile.lock during upgrades
+ * Don't overiwrite config/oidc_key.pem during upgrades
+ * Make config/schedule.yml writeable (Closes: #926968)
+
+ -- Pirate Praveen Wed, 09 Sep 2020 01:27:58 +0530
+
diaspora-installer (0.7.6.1+debian1) unstable; urgency=medium
* Use system bundler (Closes: #919978)
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/diaspora-common.links diaspora-installer-0.7.6.1+debian1+deb10u1/debian/diaspora-common.links
--- diaspora-installer-0.7.6.1+debian1/debian/diaspora-common.links 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/diaspora-common.links 2020-09-09 01:27:29.0 +0530
@@ -2,6 +2,8 @@
var/lib/diaspora/public usr/share/diaspora/public
var/lib/diaspora/app-assets usr/share/diaspora/app/assets
var/lib/diaspora/.bundle usr/share/diaspora/.bundle
-var/lib/diaspora/Gemfile.lock usr/share/diaspora/Gemfile.lock
+#We use upstream Gemfile.lock for diaspora-installer so move this to diaspora
+#var/lib/diaspora/Gemfile.lock usr/share/diaspora/Gemfile.lock
var/lib/diaspora/oidc_key.pem usr/share/diaspora/config/oidc_key.pem
+var/lib/diaspora/schedule.yml usr/share/diaspora/config/schedule.yml
var/log/diaspora usr/share/diaspora/log
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/postinst diaspora-installer-0.7.6.1+debian1+deb10u1/debian/postinst
--- diaspora-installer-0.7.6.1+debian1/debian/postinst 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/postinst 2020-09-09 00:27:27.0 +0530
@@ -41,8 +41,7 @@
echo "Installing gems with rubygems ..."
su ${diaspora_user} -s /bin/sh -c "mkdir -p ~/vendor/bundle"
- su ${diaspora_user} -s /bin/sh -c "touch ~/Gemfile.lock && truncate -s 0 ~/Gemfile.lock"
- su ${diaspora_user} -s /bin/sh -c "bundle install --path vendor/bundle --with ${BUNDLE_WITH} --without development test"
+ su ${diaspora_user} -s /bin/sh -c "bundle install --frozen --path vendor/bundle --with ${BUNDLE_WITH} --without development test"
# Fix permissions (see #847286, #866862)
su ${diaspora_user} -s /bin/sh -c "find ${diaspora_user_home}/vendor/bundle -type f -exec chmod go-w {} \;"
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/postrm diaspora-installer-0.7.6.1+debian1+deb10u1/debian/postrm
--- diaspora-installer-0.7.6.1+debian1/debian/postrm 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/postrm 2020-09-09 01:27:29.0 +0530
@@ -13,7 +13,7 @@
diaspora_home=/usr/share/diaspora
# Keep it in sync with preinst
-diaspora_symlinks_list="Gemfile.lock log tmp public app/assets bin/bundle vendor/bundle config/database.yml config/diaspora.yml config/oidc_key.pem"
+diaspora_symlinks_list="Gemfile.lock log tmp public app/assets bin/bundle vendor/bundle config/database.yml config/diaspora.yml config/oidc_key.pem config/schedule.yml"
diaspora_symlinks_dirs="app bin vendor db config"
case "$1" in
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/preinst diaspora-installer-0.7.6.1+debian1+deb10u1/debian/preinst
--- diaspora-installer-0.7.6.1+debian1/debian/preinst 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/preinst 2020-09-09 01:27:29.0 +0530
@@ -4,7 +4,7 @@
diaspora_home=/usr/share/diaspora
# Keep it in sync with postrm
-diaspora_symlinks_list="Gemfile.lock log tmp public app/assets
Bug#969912: buster-pu: package diaspora-installer/0.7.6.1+debian1
On 2020, സെപ്റ്റംബർ 8 10:41:40 PM IST, "Adam D. Barratt" wrote: >Control: tags -1 + moreinfo > >On Tue, 2020-09-08 at 22:31 +0530, Pirate Praveen wrote: >> This fixes upgrading from stretch-backports. Attaching the debdiff. >> >> I noticed these issues when upgrading production instance at >> https://diasp.in >> > >Judging from the changelog, it looks like this change hasn't been >applied to the package in unstable yet. Is that correct? Yes, that is correct. I found the problem in stretch-backports and fixed that first. Then moved to fixing buster. I intend to fix unstable too. If you want to wait for fix in unstable, that'd be fine too. >Regards, > >Adam > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#969912: buster-pu: package diaspora-installer/0.7.6.1+debian1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
This fixes upgrading from stretch-backports. Attaching the debdiff.
I noticed these issues when upgrading production instance at
https://diasp.in
(I hope I don't have to a file a bug).
Let me know if I can upload it.
-- System Information:
Debian Release: 10.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/changelog diaspora-installer-0.7.6.1+debian1+deb10u1/debian/changelog
--- diaspora-installer-0.7.6.1+debian1/debian/changelog 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/changelog 2020-09-08 21:05:18.0 +0530
@@ -1,3 +1,11 @@
+diaspora-installer (0.7.6.1+debian1+deb10u1) buster; urgency=medium
+
+ * Use --frozen option to bundle install to use upstream Gemfile.lock
+ * Don't exclude Gemfile.lock during upgrades
+ * Don't overiwrite config/oidc_key.pem during upgrades
+
+ -- Pirate Praveen Tue, 08 Sep 2020 21:05:18 +0530
+
diaspora-installer (0.7.6.1+debian1) unstable; urgency=medium
* Use system bundler (Closes: #919978)
diff -Nru diaspora-installer-0.7.6.1+debian1/debian/postinst diaspora-installer-0.7.6.1+debian1+deb10u1/debian/postinst
--- diaspora-installer-0.7.6.1+debian1/debian/postinst 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/debian/postinst 2020-09-08 21:04:25.0 +0530
@@ -41,8 +41,7 @@
echo "Installing gems with rubygems ..."
su ${diaspora_user} -s /bin/sh -c "mkdir -p ~/vendor/bundle"
- su ${diaspora_user} -s /bin/sh -c "touch ~/Gemfile.lock && truncate -s 0 ~/Gemfile.lock"
- su ${diaspora_user} -s /bin/sh -c "bundle install --path vendor/bundle --with ${BUNDLE_WITH} --without development test"
+ su ${diaspora_user} -s /bin/sh -c "bundle install --frozen --path vendor/bundle --with ${BUNDLE_WITH} --without development test"
# Fix permissions (see #847286, #866862)
su ${diaspora_user} -s /bin/sh -c "find ${diaspora_user_home}/vendor/bundle -type f -exec chmod go-w {} \;"
diff -Nru diaspora-installer-0.7.6.1+debian1/diaspora-download.sh diaspora-installer-0.7.6.1+debian1+deb10u1/diaspora-download.sh
--- diaspora-installer-0.7.6.1+debian1/diaspora-download.sh 2019-05-01 18:45:53.0 +0530
+++ diaspora-installer-0.7.6.1+debian1+deb10u1/diaspora-download.sh 2020-09-08 21:04:58.0 +0530
@@ -36,7 +36,8 @@
echo "diaspora archive to copy: ${diaspora_archive}"
-rsync -a ${diaspora_cache}/${diaspora_archive}/* ${diaspora_home} --exclude tmp --exclude log --exclude app/assets --exclude public --exclude Gemfile.lock
+# Exclude user generated or files or directories
+rsync -a ${diaspora_cache}/${diaspora_archive}/* ${diaspora_home} --exclude tmp --exclude log --exclude db/schema.rb --exclude app/assets --exclude public --exclude config/oidc_key.pem
cp -r ${diaspora_cache}/${diaspora_archive}/app/assets/* ${diaspora_user_home}/app-assets
cp -r ${diaspora_cache}/${diaspora_archive}/public/* ${diaspora_user_home}/public
chown -R ${diaspora_user}: ${diaspora_user_home}/public
Bug#969211: RM: redmine/4.0.7-1
On 2020, സെപ്റ്റംബർ 2 1:44:20 AM IST, Paul Gevers wrote: >Dear Pirate, > >On 29-08-2020 12:54, Pirate Praveen wrote: >> redmine is not compatible with rails 6 (#969206). This is blocking >> migration of rails 6 to testing. Please remove redmine from testing to >> allow rails 6 to migrate to testing. > >That redmine bug was filed just before you requested the removal here >(why did you wait so long with informing the maintainers?). Please give >the maintainers some time to fix the issue. A couple of weeks is not >unreasonable. Or are there pressing issues why rails should migrate quicker? They are aware of the issue[1][2], it needs support from upstream and that will take some time. We have been discussing rails 6 transition in ruby team meetings for many months. We also discussed this recently in ruby team bof at debconf 20. [1] https://people.debian.org/~praveen/rails6-meta-build/ (all packages failing with rails 6) this was shared even before upload to unstable in debian-ruby list. [2] https://salsa.debian.org/ruby-team/rails/-/wikis/Transition-to-Rails-6-for-Debian-Bullseye >Paul -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#969211: RM: redmine/4.0.7-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm redmine is not compatible with rails 6 (#969206). This is blocking migration of rails 6 to testing. Please remove redmine from testing to allow rails 6 to migrate to testing. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#969168: RM: ruby-has-scope/0.7.2-2 ruby-inherited-resources/1.11.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm FTBFS with rails 6 (#969166) and blocking testing migration of rails 6. It has a leaf package as reverse dependency: ruby-inherited-resources/1.11.0-4 So please remove both packages to allow migration of rails 6 to testing. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#969161: RM: ruby-diaspora-federation-rails/0.2.6-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm This package is not yet compatible with rails 6 (#969157) and is blocking migration of rails 6 to testing. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#934927: transition: libgit2
On Sat, 16 Nov 2019 01:18:53 +0530 Pirate Praveen wrote: > I missed the message that gave a go ahead. Today I rebuilt julia with > libgit2 0.28 and realized it was already passing. So I will upload > libgit2 to unstable now. Uploaded to unstable.
Bug#934927: transition: libgit2
On Tue, 29 Oct 2019 21:19:44 +0100 Paul Gevers wrote: > Hi, > > On Sat, 12 Oct 2019 17:30:27 +0200 Emilio Pozuelo Monfort > wrote:> With only libgit-raw-perl and julia > remaining, which aren't key packages have > > one and none (resp) rdeps, and with all the time that has passed since their > > bugs were reported with no action from the maintainers so far, I think we > > can go > > ahead with this and have those removed from testing if necessary. > > Is there any intent to start the libgit2 transition soon? If not, I'd > like to start an other transition, but I don't want the two to intermix. I missed the message that gave a go ahead. Today I rebuilt julia with libgit2 0.28 and realized it was already passing. So I will upload libgit2 to unstable now.
Bug#934927: Status update request
On Sun, Sep 29, 2019 at 21:53, Paul Gevers wrote: Could you please next time provide more context than only the bug number. It's annoying to need to look it up if all you need to do is add "libgit2 transition" somewhere. ok. That said, are you aware of any progress on the julia front? I have pinged on the bug again. Paul
Bug#934927: Status update request
Are we blocked by some other transitions? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)
[Resending because I got some bounces] On 2019, ഓഗസ്റ്റ് 29 7:50:00 PM IST, Dan Clery wrote: >Isn't this the sort of problem that things like flatpack or snap were >created for? In those solutions either security updates have to handled by each flatpack or snap instead of sharing it (duplication) or all flatpacks or snaps may not be receiving security updates in time. Fast Track repo works exactly like current backports except the packages are added from unstable (or experimental during transitions and freeze) as they cannot go to testing and hence to current backports. As Paul noted earlier, backports team is not interested to change current backports criteria. >On Thu, Aug 29, 2019 at 9:57 AM Abhijith PA >wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> >> Hi, >> >> On 29/08/19 6:47 pm, Paul Gevers wrote: >> > Hi >> > >> > On 29-08-2019 14:28, Raphael Hertzog wrote: >> >> (Note: pkg-security@tracker.d.o is not a valid email, dropped) >> >> >> >> Hi, >> >> >> >> On Thu, 29 Aug 2019, Holger Levsen wrote: >> In general, we (Debian) don't have a good answer to this >> problem and virtualbox is clearly a bad precedent. We really >> need to find a solution to this in concertation with the >> release managers. >> >>> so I've added them to this thread. >> >>> >> >>> youtube-dl is in the same boat... >> > Wasn't Pirate already working on a solution? How is that faring? I >> > know it doesn't have all the properties you are seeking, but ... >> > >> >> Yes, the http://fasttrack.debian.net/ is started for handling similar >> issue. Last time I checked the work is almost done and will be >> deployed soon. >> >> >> - --abhijith >> -BEGIN PGP SIGNATURE- >> >> iQIzBAEBCgAdFiEE7xPqJqaY/zX9fJAuhj1N8u2cKO8FAl1n1cwACgkQhj1N8u2c >> KO8TsQ//dy0Xff6X1422Ypr2HQHAVu/3rf4VXBQI8a5yo/nWVhvlvbrU65pyyRND >> tS3fDpc3m/nRJ82vAhXCxzU0mW7zIRiq3lyBc7V11BC81Fn50b4C8mDBj+XasY6/ >> PXgCoW1B8b+7LoD9M85RWHV25OLEar9bNFbQTi7YrINxyWNIK4J5fZoRk5zD+wLs >> KShKCl4NGYNUYiwc9O5w8fDuA5Ty9Fgxop8xB0rk6kzWlRLIhnMC84aEwWs5EUq1 >> lXcr7ONa5M9GnzIF2WsAfbHQVqplL5yMPVNlj4mkEtADb/gm0JWIC2Ye92UHdAL3 >> BDV8gJjRs6DBg3vGMXXLkwzO8twe5zezoglrTC0MMNi+SnahTti7WU6yTzpomGqS >> vzx8haRtST2kC3xLg9y4P6dQC7dQGpzvmNDCPhpXADsb9C+9x6oGC3AqsTKOKkSS >> PtH0/7ME9QjlUFSIgA7no5hc74AR0wYTyi4qaF4Uv0zOJilbPaF4ExCcT2W3P85P >> 5LOp+tHqu1H08vxt7WprNnFWTkBRwyXYn3L5eH4aIjWy+WQg3hSkKaBMB4xDDpao >> of5vyTkyFhR36gBd82DzB7TJgw3gfuS/mCoG8QAmsm5pqwKVoDwacuPV9RXrKC5b >> CwRAvmwfN51S5LH6iKnlaSbcypNEkhRmngJqfkR5WHIA2SVeiJs= >> =jWMw >> -END PGP SIGNATURE- >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)
[Resending because I got some bounces] On 2019, ഓഗസ്റ്റ് 29 7:10:38 PM IST, Abhijith PA wrote: > >Hi, > >On 29/08/19 6:47 pm, Paul Gevers wrote: >> Hi >> >> On 29-08-2019 14:28, Raphael Hertzog wrote: >>> (Note: pkg-security@tracker.d.o is not a valid email, dropped) >>> >>> Hi, >>> >>> On Thu, 29 Aug 2019, Holger Levsen wrote: > In general, we (Debian) don't have a good answer to this > problem and virtualbox is clearly a bad precedent. We really > need to find a solution to this in concertation with the > release managers. so I've added them to this thread. youtube-dl is in the same boat... >> Wasn't Pirate already working on a solution? How is that faring? I >> know it doesn't have all the properties you are seeking, but ... >> > >Yes, the http://fasttrack.debian.net/ is started for handling similar >issue. Last time I checked the work is almost done and will be >deployed soon. The repository is already working with gitlab package available there. Cron jobs and email notifications are not setup yet. Follow progress via #debian-fasttrack on oftc irc. > >--abhijith -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bits from the Release Team: ride like the wind, Bullseye!
On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers wrote: >I can already trigger all the autopkgtests in unstable for packages >that >are in experimental, so if you interested in this, please contact me. >This would enable library maintainers to at least have an overview of >what would happen. I could even activate this by default. Yes, please do this by default so we can have a better picture of the transition. Though for many libraries we also need to rebuild reverse build dependencies. I have been using salsa.debian.org/ruby-team/meta/build for this. Right now I'm interested in libgit2, grpc and protobuf transitions. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#928387: ping
Just in case this request was over looked because of a similar request earlier. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#928000: unblock: diaspora-installer/0.7.6.1+debian
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package diaspora-installer
Fixes rc bug #919978
$ debdiff diaspora-installer_0.7.6.1.dsc diaspora-installer_0.7.6.1+debian.dsc
dpkg-source: warning: extracting unsigned source package
(/home/pravi/forge/debian/git/ruby-team/diaspora-installer_0.7.6.1.dsc)
diff -Nru diaspora-installer-0.7.6.1/debian/changelog
diaspora-installer-0.7.6.1+debian/debian/changelog
--- diaspora-installer-0.7.6.1/debian/changelog 2018-11-14 18:24:44.0
+0530
+++ diaspora-installer-0.7.6.1+debian/debian/changelog 2019-04-26
14:08:20.0 +0530
@@ -1,3 +1,9 @@
+diaspora-installer (0.7.6.1+debian) unstable; urgency=medium
+
+ * Install bundler 1.x (Closes: #919978)
+
+ -- Pirate Praveen Fri, 26 Apr 2019 14:08:20 +0530
+
diaspora-installer (0.7.6.1) unstable; urgency=medium
[ Gianfranco Costamagna ]
diff -Nru diaspora-installer-0.7.6.1/debian/postinst
diaspora-installer-0.7.6.1+debian/debian/postinst
--- diaspora-installer-0.7.6.1/debian/postinst 2018-11-14 18:24:44.0
+0530
+++ diaspora-installer-0.7.6.1+debian/debian/postinst 2019-04-26
14:08:03.0 +0530
@@ -37,8 +37,8 @@
. /usr/lib/diaspora-common/scripts/set-env-diaspora.sh
export RAILS_ENV=$RAILS_ENV BUNDLE_WITH=${BUNDLE_WITH}
DB_NAME=${DB_NAME} ENVIRONMENT_URL=$ENVIRONMENT_URL
-echo "Installing latest version of bundler..."
- gem install bundler
+echo "Installing bundler 1.x..."
+ gem install -v 1.17.3 bundler
echo "Installing gems with rubygems ..."
su ${diaspora_user} -s /bin/sh -c "mkdir -p ~/vendor/bundle"
unblock diaspora-installer/0.7.6.1+debian
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#924726: unblock: ruby-mobile-fu/1.4.0+github-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ruby-mobile-fu
This package was depending on rails which also installed many development
packages not useful in a production system. This was fixed in last upload of
rails. So this package now depends on ruby-rails instead of rails.
$ debdiff ruby-mobile-fu_1.4.0+github-1.dsc ruby-mobile-fu_1.4.0+github-2.dsc
dpkg-source: warning: extracting unsigned source package
(/home/pravi/forge/debian/git/ruby-team/ruby-mobile-fu_1.4.0+github-1.dsc)
dpkg-source: warning: extracting unsigned source package
(/home/pravi/forge/debian/git/ruby-team/ruby-mobile-fu_1.4.0+github-2.dsc)
diff -Nru ruby-mobile-fu-1.4.0+github/debian/changelog
ruby-mobile-fu-1.4.0+github/debian/changelog
--- ruby-mobile-fu-1.4.0+github/debian/changelog2018-09-28
00:34:13.0 +0530
+++ ruby-mobile-fu-1.4.0+github/debian/changelog2019-03-06
17:13:39.0 +0530
@@ -1,3 +1,10 @@
+ruby-mobile-fu (1.4.0+github-2) unstable; urgency=medium
+
+ * Change dependency rails -> ruby-rails
+ * Bump Standards-Version to 4.3.0 (no changes needed)
+
+ -- Pirate Praveen Wed, 06 Mar 2019 17:13:39 +0530
+
ruby-mobile-fu (1.4.0+github-1) unstable; urgency=medium
* Team upload
diff -Nru ruby-mobile-fu-1.4.0+github/debian/control
ruby-mobile-fu-1.4.0+github/debian/control
--- ruby-mobile-fu-1.4.0+github/debian/control 2018-09-28 00:34:13.0
+0530
+++ ruby-mobile-fu-1.4.0+github/debian/control 2019-03-06 17:13:39.0
+0530
@@ -8,10 +8,10 @@
rake,
ruby-json,
ruby-httparty,
- rails,
+ ruby-rails,
ruby-rack-mobile-detect,
ruby-mocha
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
Vcs-Git: https://salsa.debian.org/ruby-team/ruby-mobile-fu.git
Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-mobile-fu
Homepage: https://github.com/benlangfeld/mobile-fu
@@ -21,8 +21,8 @@
Package: ruby-mobile-fu
Architecture: all
XB-Ruby-Versions: ${ruby:Versions}
-Depends: rails,
- ruby | ruby-interpreter,
+Depends: ruby | ruby-interpreter,
+ ruby-rails,
ruby-rack-mobile-detect,
${misc:Depends},
${shlibs:Depends}
unblock ruby-mobile-fu/1.4.0+github-2
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#922310: unblock: ruby-jquery-ui-rails/6.0.1+dfsg-3 (and 922316)
On Thu, 14 Feb 2019 21:26:34 +0530 Pirate Praveen wrote: > On Thu, 14 Feb 2019 16:35:22 +0100 Paul Gevers wrote: > > Hi > > > > On 14-02-2019 14:36, Utkarsh Gupta wrote: > > > The autopkgtest regression in testing was due to ruby-capybara[2], which > > > was not in testing, which was blocked by an RC bug in puma[3]. > >^ > > which is bug #900156 which was filed on 26 May 2018 and didn't see a fix > > until 2 days before the soft freeze. > > > > rails 5 transition took longer than we expected. Without rails 5 in testing, > we did not have any chance to get diaspora or redmine to buster. Once we got > rails 5 to buster, we focused on the dependencies and noticed puma was > blocking ruby-capybara. > Also ruby-capybara started depending on puma only from 3.12.0, which was uploaded on 2019-01-07 only (because rails recommends ruby-capybara >= 2.15). At this point only I started caring about puma and realized its original uploader was no longer in the uploaders list. So I added myself as an uploader for puma and fixed the bug with a patch from upstream. Then there was a new rc bug appearing only on single CPU machines, which was fixed the very next day. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#922310: unblock: ruby-jquery-ui-rails/6.0.1+dfsg-3 (and 922316)
On Thu, 14 Feb 2019 16:35:22 +0100 Paul Gevers wrote: > Hi > > On 14-02-2019 14:36, Utkarsh Gupta wrote: > > The autopkgtest regression in testing was due to ruby-capybara[2], which > > was not in testing, which was blocked by an RC bug in puma[3]. >^ > which is bug #900156 which was filed on 26 May 2018 and didn't see a fix > until 2 days before the soft freeze. > rails 5 transition took longer than we expected. Without rails 5 in testing, we did not have any chance to get diaspora or redmine to buster. Once we got rails 5 to buster, we focused on the dependencies and noticed puma was blocking ruby-capybara. As discussed in #debci, ruby-jquery-ui-rails and ruby-leaflet-rails were eligible for testing migration in 2 days with autopkgtest passing in unstable, but it was not considered (posdibly because autopkgtest recorded failure in testing). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Rails 5 transition plan - help needed
On ചൊ, ഫെബ്രു 5, 2019 at 4:10 വൈകു, Emilio Pozuelo Monfort wrote: On 05/02/2019 03:52, Pirate Praveen wrote: Hi Release team, I have filed removal requests for blocking packages. Can you process those and help get rails to testing? Done: rails | 2:5.2.2+dfsg-1| testing| source, all rails | 2:5.2.2+dfsg-1| unstable | source, all Emilio Hi Emilio, Thanks for the help. It was a long transition, happy to see it in buster. Thanks also to everyone in the ruby team who contributed. Cheers Praveen
Re: Re: Rails 5 transition plan - help needed
Hi Release team, I have filed removal requests for blocking packages. Can you process those and help get rails to testing? Thanks Praveen -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#921051: RM: ruby-facebox-rails/0.2.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm This package is no longer required but since diaspora 0.6 still depends on it, this cannot be removed before diaspora is updated to 0.7 (#920814). But diaspora update is still in progress, so to facilitate rails 5 migration to testing, please remove this from testing. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#921050: RM: ruby-protected-attributes/1.1.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm This package is not compatible with rails 5, but redmine 3 still depends on it, so it cannot be removed from unstable till redmine is updated (which is still in progress). Since this is blocking rails 5 migration to testing, it should be removed from testing to facilitate this migration. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#921049: RM: redmine/3.4.6-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove redmine from testing to facilitate migration of rails 5. redmine 4 is being prepared which is compatible with rails 5 but it is not ready yet. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Rails 5 transition plan - help needed
On ചൊ, ജനു 29, 2019 at 6:17 വൈകു, Emilio Pozuelo Monfort wrote: On 29/01/2019 13:14, Pirate Praveen wrote: [adding debian-release] On തി, ജനു 21, 2019 at 10:08 രാവിലെ, Pirate Praveen wrote: pcs is not blocking anymore, but #919174 is blocking ruby-sinatra, which blocks ruby-rack and which blocks rails. This bug is fixed, but rails is still not migrating. I can't find the blocker from tracker.debian.org Does anyone know what is blocking rails? trying: ruby-arel rails ruby-rails-dom-testing ruby-rack ruby-sinatra -ruby-rack-protection ruby-web-console skipped: ruby-arel rails ruby-rails-dom-testing ruby-rack ruby-sinatra -ruby-rack-protection ruby-web-console (100, 31, 25) got: 28+0: a-1:a-0:a-0:a-0:i-24:m-1:m-0:m-1:p-0:s-1 * i386: redmine, ruby-actionpack-xml-parser, ruby-activerecord-session-store, ruby-cucumber-rails, ruby-facebox-rails, ruby-protected-attributes Looking at e.g. ruby-cucumber-rails: Depends: [...], ruby-railties (<< 2:5), ruby-railties (>= 2:3) But ruby-railties is being updated as part of rails to 2:5.2.2+dfsg-1 You need to either fix those packages to work with the new rails, or get them removed from unstable. Thanks for the answer. I think redmine, ruby-prtected-attributes, ruby-facebox-rails should be removed from testing. Newer versions of redmine that works with rails 5 is being prepared. ruby-protected-attributes have only redmine as dependency. ruby-facebox-rails is not required any more (but diaspora 0.7 should be uploaded before it can be removed from unstable) Other 3 fixed.
Re: Rails 5 transition plan - help needed
[adding debian-release] On തി, ജനു 21, 2019 at 10:08 രാവിലെ, Pirate Praveen wrote: pcs is not blocking anymore, but #919174 is blocking ruby-sinatra, which blocks ruby-rack and which blocks rails. This bug is fixed, but rails is still not migrating. I can't find the blocker from tracker.debian.org Does anyone know what is blocking rails?
Re: Bug#918388: fixed in nodejs 10.15.0~dfsg-8
[asking -release] On 1/6/19 5:31 PM, Pirate Praveen wrote: > Control: reopen -1 > > On Sun, 06 Jan 2019 10:34:48 + =?utf-8?b?SsOpcsOpbXkgTGFs?= > wrote: >>* Suggests npm - because nodejs must not be blocked by it. >> Closes: #918388. > > I don't think this reasoning is correct. gitlab recommends gitaly with > the expectation that gitaly andd gitlab could be on different machines. > ruby-rails currently recommends packages not even in the archive > currently and it is not marked for auto removals for that. > > I'd be happy to be proven wrong. > Hi Release team, Can you confirm if an rc bug in a packaged listed in recommends will block testing migration of a package? (in this specific case, the fear is that rc bug in npm will block nodejs testing migration). Thanks Praveen signature.asc Description: OpenPGP digital signature
Re: Proposal: Repository for fast-paced package backports
On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer wrote: >Pirate Praveen: >> On 12/28/18 11:06 AM, Thomas Goirand wrote: >>> If the problem is hardware and connectivity, then IMO you can easily >>> find a sponsor for it. My company could well offer it for example >>> (hosted in Geneva with very nice connectivity to almost everywhere). >>> >>> Setting-up a repository isn't hard. And for a start, I don't think >you >>> really need a buildd network, just amd64 is ok-ish. >> >> I'd like go ahead with this offer and create rolling.debian.net (as >> someone suggested already to avoid reusing volatile). I think we can >> take the setup discussions offlist. > >Please don't name it 'rolling'. This term is used a lot in the sense of >'rolling releases' by other distributions, and also in discussions >about >constantly usable testing. Well, it only makes things clear as the packages in this repo will be rolling. >From all names that got suggested so far, 'fastpaced' is the only one >that doesn't have a special meaning in Debian context yet, at least to >my knowledge. That's why I would prefer that one. > >Thanks for pushing that effort, Nik and Pirate! I really like the idea >of having a repository that provides newer releases of fast-moving >software built for stable. > >Cheers, > jonas -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Proposal: Repository for fast-paced package backports
On 12/28/18 11:06 AM, Thomas Goirand wrote:
> If the problem is hardware and connectivity, then IMO you can easily
> find a sponsor for it. My company could well offer it for example
> (hosted in Geneva with very nice connectivity to almost everywhere).
>
> Setting-up a repository isn't hard. And for a start, I don't think you
> really need a buildd network, just amd64 is ok-ish.
I'd like go ahead with this offer and create rolling.debian.net (as
someone suggested already to avoid reusing volatile). I think we can
take the setup discussions offlist.
>> If you know how to start with a new service at
>> {volatile,fastpaced,whatever}.debian.net without having to reinvent the
>> wheel for acceptign uploads, getting packages built, etc., please
>> enlighten me.
>
> Setting-up reprepro, or even Dak, isn't that hard.
I already use reprepro
https://people.debian.org/~praveen/gitlab/
and will continue to use the same (as the number of packages would be
small and it is pretty simple to setup).
signature.asc
Description: OpenPGP digital signature
Re: Proposal: Repository for fast-paced package backports
On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George wrote: >No. The dpendencies of gitlab not being accepted into backports right >now is an entirely different issue. I am repeating myself: This >proposal >is not intended to ease the life of maintainers whose packages qulify >for -backports. The only difference between -backports and -volatile in >this draft proposal is that -volatile can take packages that are not in >testing due to the exact one reason that hey have a shorter lifespan. >No >single other thing qualifies a package for -volatile if it is not >qualified for -backports. > >If there are other issues to solve than the lifespan of the package >version, they must be solved in another way. I agree with you, it is the best outcome. But when people with power (-backports ftp masters) are not willing to consider it, we have to go with plan B, which is less than ideal, but can move things forward. >On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: >> As I said, gitlab was not about manpower. This new repo is completly >against >> our vision of what backports is. Therefore we don't want it within >the >> backports suite. > If people argue both ways, how can we answer? Either it adds more work for -backports team or it does not. Some people say its not fair to add more load while ftp masters say its not about load. If it does not add extra load, then I don't see why it can be kept out of -backports when it qualifies except for being a dependency of -volatile. They say it does not match with their vision. So what option is left for us? We have to take their word for it and move forward without inconveniencing them. I don't think -backports ftp masters is going to accept this proposal (from the responses we already received), so I can live with all dependencies in -volatile. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Proposal: Repository for fast-paced package backports
On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George wrote: >Heisann, alle sammen, > >as announced in the recent thread about maintaining, I hereby propose a >repository that allows making “backports” of packages available to >users >of the stable distribution, if those packages cannot be maintained in >testing and backported in the usual way. If you are interested in what >lead up to that, please see bug #915050. I will give a short summary of >it here. > > >Reasons for having a special place for some packages > > >(You may want to skip this part if you are familiar with the >situation.) > >As all developers know (but passers-by may not), for software to enter >the Debian archive, it is always uploaded to the unstable distribution, >then migrates to testing (hopefully ;)), which is at some point >snapshot >and made the new stable release. From there on, maintainers have two >obligations: Firstly, keep the package in stable good and secure, e.g. >by uploading security fixes for it once they become available upstream, >or even backport fixes themselves. Secondly, provide the package in >unstable with updates and ensure its migration, to keep it ready for >the >next stable release. > >Now, for some software packages, this process is problematic, because >upstream may have another idea about software lifecycles. Concerning >the >GitLab example, upstream provides security fixes for three months for >their stable releases. Backporting fixes from newer versions is very >hard or impossible because the massive amounts of changes to the >software in every new versions. This is something that also affects >other packages, like Mozilla Firefox, which has a firefox package in >unstable, and a separate firefox-esr package, with the ESR version of >Firefox. Only the latter migrates to testing. > >Users of Debian honour it for its stability, but as an agile software >lifecycle is adapted by more and more very popular software packages, >not being able to install these packages in the trusted, well-known >fashion through the official apt repositories is becoming more and more >of a drawback. > >It can easily be assumed that the normal release and maintenance cycle >of Debian stable will not change, which is very good, so we should find >a way to still provide such software as described above to users. > > >Why backports is not enough >=== > >This also is well-known, but for completeness: Formal backports in >stable-backports are required to be direct backports from testing, and >are a stepping stone within the upgrade from stable to stable+1. Thus, >a >version of a package that is not in testing can never be in >stable-backports. > > >Name of the new repository >== > >In the past, the name “volatile” was used for a similar repository, but >with a different scope (limited to data packages for things like virus >scanners). I will thus use the working title volatile throughout this >proposal, although this may change. > >Other ideas: fastlane, unsupported > >(Please feel free to add other ideas.) > > >Requirements for a package to go into stable-volatile >= > >The new volatile proposal is not intended to ease life for package >maintainers who want to bypass the migration and QA requirements of the >regular stable lifecycle, so special need must be taken to ensure only >packages that need it go into volatile. I want to summarise the >requirements like so: > >- The package must be maintained in unstable, like every other package. > - The package must not be in testing, and care must be taken for the > package not to migrate to testing. > - Regular maintenance for the lifetime of stable must be impossible > or unnecessarily hard, and this requirement should be assessed in > a verifiable manner, e.g. referring to upstream’s lifecycle model. > - There must be notable need for the package. Like for backports, user > requests might be an indicator. > - Should the package be removed from unstable, it must also be removed > from volatile. > - Should the package begin to migrate to testing again, it must > be moved to stable-backports. > >Before starting to maintain a volatile package, the maintainer shall >seek consent (or doubt) on debian-devel. > > >Building packages and package dependencies >== > >Packages for volatile are built the same way as formal backports, only >that the source is taken from unstable rather than testing. In >particular: > > - Changes shall be kept as small as possible. > - The package is rebuilt against stable. >- The package may depend on packages in stable, stable-backports or >stable-volatile. > >Dependencies on other packages in volatile should be avoided if >possible. Especially, dependencies of the package that also need >backporting must not be added to volatile just because they are >dependencies —
Bug#901015: transition: protobuf
On 10/24/18 3:54 PM, Mattia Rizzolo wrote: > If "a rebuild is required to make them compatible", you should add > Breaks against those versions, as it maeans the new protobuf is not > compatible to them and coinstallation should be prevented. > That would also hint britney to trigger autopkgtest with both the new > rebuilt rdep and the new protobuf, and migrate them in lockstep. > This was suggested earlier but rejected by protobuf maintainer. "1) Can libprotobuf10 and libprotobuf17 installed together and independent packages working correctly with these libraries? Yes, these are possible. I don't see the need to break the old libprotobuf10 package. 2) Packages that depend on each other, need to be compiled with the same ProtoBuf version. This should be expressed in those package dependencies." https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910964#29 Though the suggestion by protobuf maintainer was not acceptable to ignition-msgs maintainer https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900429#36 signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
Hi Emilio, I think these regressions should not add a delay to testing migration as autopkgtests are passing in unstable and a rebuild is required to make them compatible with new protobuf version. autopkgtest for gazebo/9.0.0+dfsg5-4.2: amd64: Regression ♻ autopkgtest for ignition-msgs/1.0.0+dfsg1-5: amd64: Regression ♻ autopkgtest for ignition-transport/4.0.0+dfsg-4: amd64: Regression ♻ autopkgtest for ola/0.10.7.nojsmin-1: amd64: Regression ♻ Required age increased by 18 days because of autopkgtest signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On 2018, ഒക്ടോബർ 12 12:36:45 PM IST, "László Böszörményi (GCS)" wrote: > Uploaded ProtoBuf with the latest gRPC to Sid. Thanks a lot for your work! I hope to upload them to stretch-backports as soon as they enter testing (I have rebuilt them for my personal repo before). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#909315: RM: gitlab/stable -- ROM; open security issues, hard to backport fixes
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-release@lists.debian.org We backported some security fixes, but it has become much harder as upstream has diverged a lot. We are trying to provide a newer version via stretch-backports. signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Tue, 11 Sep 2018 09:51:07 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > The last package which fails is gazebo which seems to be team > maintained but it has two NMUs already. There's no bug reported here > for the protobuf update but upstream aware of it and has a patch[1]. > This one is not yet tested by me, but the upstream BTS contains a > comment that's a working fix for gazebo 7.x and the original bug > report[2] states that the fix is in place for the 8.x and 9.x versions > as well. If you have time, please file a bug for this to the gazeboo > source package - but as noted its Debian maintainers are not very > active. I have reported it as #908854 and it is already fixed upstream in 9.2 version. I think we can upload protobuf now and raise severity of the gazebo bug to serious. signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Fri, 17 Aug 2018 10:21:41 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > On Tue, Aug 14, 2018 at 6:53 AM Robert Edmonds wrote: > > I've released a new upstream version of protobuf-c that fixes the FTBFS > > issue with protobuf 3.6, which fixes #900621. I will upload it to > > unstable shortly. > To whom it may concern, a status update. > Robert released and uploaded an updated protobuf-c version. It built > fine with protobuf 3.0.0 and I could build it with 3.6.0.1 as well. > Google released a new protobuf release with 3.6.1 version number. I've > packaged it and due to a new soname version it had to go through NEW. > Then it had a new grpc release which was packaged and uploaded as > well. > The new protobuf -> protobuf-c / grpc chain compiles now on all > release architectures. Due to the mentioned protobuf soname change, I > have to restart building of all other dependent packages. I'll be off > the grid for the weekend, but will do it next week. Any update on this? > Regards, > Laszlo/GCS > > signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
[Copying Emilio] On Thu, 12 Jul 2018 10:27:58 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > [Removed the Security Team Cc, they were relevant for backporting > protobuf to Stretch, not for updating it in Sid.] > > On Thu, Jul 12, 2018 at 10:14 AM Pirate Praveen > wrote: > > On Fri, 6 Jul 2018 10:55:03 +0200 > > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= > > wrote: > > > The most problematic point is the protobuf-c dependency package. It > > > was developed (and packaged) by one of us (an other DD), Robert S. > > > Edmonds. It is the most complete C language implementation of Protocol > > > Buffers. While it has a newer upstream release in Git than the > > > packaged version, it's still not compatible with protobuf 3.6.0.1 > > > which is in experimental. > [...] > > What do you think about providing protobuf3.0 in parallel to updating > > protobuf to 3.6? That way we can move ahead with gitlab and provide more > > time for either updating protobuf-c or porting packages to protobluff. > > We can drop protobuf3.0 when protobuf-c issue is resolved. > Actually I would like to investigate every possibility. > 1) Check the list of protobuf-c main contributors[1] if any of them > can / want to continue its development. > 2) Try to update protobuf-c for version 3.6 of protobuf, but I can't > be its upstream developer on the long run. > 3) Patch protobuf-c to use the implementation of scoped_array in Boost. > 4) At least check the required porting needs of dependencies to > protobluff. Ask their maintainers if they want / can do the porting. > Maybe they know other alternatives. > > If these fail and RMs ACK to carry two versions of protobuf then of > course, do it. Emilio? Hi Emilio, Can you comment? > How quick do you need to solve this GitLab update? I guess, quick. > > Cheers, > Laszlo/GCS > [1] https://github.com/protobuf-c/protobuf-c/graphs/contributors > > signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Thursday 12 July 2018 01:57 PM, László Böszörményi (GCS) wrote: > How quick do you need to solve this GitLab update? I guess, quick. We are not able to backport some complex security fixes to gitlab 8.13 in stretch. Security team wants to remove gitlab 8.13 from stable and I'd like to provide an update path via stretch-backports before it is removed. So the sooner we can provide, the better :) signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On Fri, 6 Jul 2018 10:55:03 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > The most problematic point is the protobuf-c dependency package. It > was developed (and packaged) by one of us (an other DD), Robert S. > Edmonds. It is the most complete C language implementation of Protocol > Buffers. While it has a newer upstream release in Git than the > packaged version, it's still not compatible with protobuf 3.6.0.1 > which is in experimental. > Main reason is that scoped_array (a class template to store pointers > to a dynamically allocated array) is removed from newer protobuf > releases, still protobuf-c still would like to use it. While Boost has > a similar (same?) scoped_array implementation since its 1.49 version, > I highly doubt protobuf-c should be altered to use that. As I can't > reach Robert for about nine months and I don't see any life sign from > him either, protobuf-c definitely needs a new upstream maintainer with > internal protobuf knowledge. > > Of course, several other C implementation of protobuf exist. > PBC[1] seems to be dead for more than a year now and does _not_ have a > code generator. > Nanopb[2] is a trim down version for 32 bits and microcontrollers only. > protobluff[3] seems to be the most viable alternative. It's modular, > seems to be in development and integrates with the upstream code > generator. > None of these are packaged as I know. > > But why is all the fuzz you may ask. The protobuf-c library is used by > several big / important projects. Like Knot DNS (a high-performance > DNS server, knot), CRIU (Checkpoint/Restore In Userspace, criu) and > PostGIS (geographic objects support for PostgreSQL, postgis) - > maintained by people like Ondřej Surý and Carnil (Salvatore > Bonaccorso), ones that I bow before them for their knowledge. These > packages and others would break with starting the protobuf transition > without protobuf-c being updated. Porting these to protobluff might be > an even bigger task. László, What do you think about providing protobuf3.0 in parallel to updating protobuf to 3.6? That way we can move ahead with gitlab and provide more time for either updating protobuf-c or porting packages to protobluff. We can drop protobuf3.0 when protobuf-c issue is resolved. Thanks Praveen signature.asc Description: OpenPGP digital signature
Bug#901011: transition: libgit2
On Wed, 11 Jul 2018 09:51:42 +0200 Emilio Pozuelo Monfort wrote: > Sorry for the delay, I never got the original message so I wasn't aware of > this > transition request until this follow-up. Things look ready now. Please go > ahead. Uploaded. signature.asc Description: OpenPGP digital signature
Bug#901015: transition: protobuf
On July 6, 2018 2:25:03 PM GMT+05:30, "László Böszörményi (GCS)" wrote: >Praveen, as I saw you even talked to the Security Team about >backporting protobuf and grpc packages to Stretch for GitLab >issues[4]. Please do so with caution about protobuf-c for the reasons >mentioned above. In the future pretty please at least Cc me for >transition requests for packages that I maintain. It's much harder to >learn that it's already filed by someone else who may not know all the >consequences. I notified you as soon as I filed this here, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855034#60 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: gitlab / stretch
[adding debian-release to cc] On Thursday 05 July 2018 01:46 AM, Moritz Mühlenhoff wrote: > On Tue, Jul 03, 2018 at 03:37:11PM +0530, Pirate Praveen wrote: >> On Tuesday 03 July 2018 03:10 PM, Moritz Mühlenhoff wrote: >>> Shall we remove from stable it in the upcoming 9.5 point release? >>> >> >> I'd prefer we provide an upgrade path via stretch-backports. But it is >> blocked by 3 migrations >> https://salsa.debian.org/ruby-team/gitlab/wikis/stretch-backports :( >> >> I have everything ready in my personal repo, >> https://people.debian.org/~praveen/gitlab/ >> >> But not sure if recommending a personal repo as upgrade path is a good >> thing. >> >> I see these options, >> >> 1. Wait till gitlab 10.7.6 is available in stretch-backports (but it can >> take some time) >> 2. Recommend update via https://people.debian.org/~praveen/gitlab/ and >> remove >> 3. Just remove without mentioning my repo if we really have to do it. > > I'm not comfortable with pointing people to a private repo, so I'd say > let's postpone this until gitlab is in stretch-backports. Thanks! Release Team, Would it be possible to fast track libgit2, protobuf and grpc migrations so I can get gitlab to testing and stretch-backports soon? This will help in providing an upgrade path via stretch-backports to current users of gitlab as providing security updates is becoming hard. > Could you prepare an update for the remaining issues in the mean time? > > https://security-tracker.debian.org/tracker/source-package/gitlab I will try, as some of those are really complex patches to backport. I have not evaluated the complexity of recent issues, I will look into it. > Cheers, > Moritz > > > signature.asc Description: OpenPGP digital signature
Bug#869667: stretch-pu: package xkeyboard-config/2.19-1
On വ്യാഴം 24 ആഗസ്റ്റ് 2017 11:36 വൈകു, Adam D. Barratt wrote: > There appears to be some confusion here. > > stretch/updates is in the security archive and therefore irrelevant to > this discussion. > > Before the point release, your upload will be in proposed-updates. > Packages in proposed-updates are available once a member of the Release > Team has accepted them from the stable-new queue. That still requires > users consuming proposed-updates, which most don't. > > Finally, stretch-updates is a special distribution which the Release > Team can push packages from proposed-updates to under some > circumstances. That still requires the package to have been accepted > into proposed-updates first as per the above, and I'm not convinced that > this upload would meet the criteria for such a release. Sorry for the confusion and thanks for clarifying. I was hoping for stretch-updates, but I'll have to live with a point release. In that case, I understand the delay. signature.asc Description: OpenPGP digital signature
Bug#869667: stretch-pu: package xkeyboard-config/2.19-1
On വ്യാഴം 24 ആഗസ്റ്റ് 2017 09:46 വൈകു, Cyril Brulebois wrote: > Great thing that point releases usually happen once every 3 months, right? > > Anyway: right now, D-I Buster Alpha 1 has the priority; point release > material can definitely wait. But it is blocking everyone, as it can't go into updates without your ack. Packages in stretch/updates are available immediately to users once it enters the archive. signature.asc Description: OpenPGP digital signature
Bug#869667: stretch-pu: package xkeyboard-config/2.19-1
On Sun, 30 Jul 2017 23:10:45 +0100 "Adam D. Barratt" wrote:> As the package produces a udeb, this will need an ack from the d-i RM as > well; CCing appropriately. Its already 3 weeks without a response. I tried pinging them on irc as well. signature.asc Description: OpenPGP digital signature
Bug#869667: stretch-pu: package xkeyboard-config/2.19-1
Control: tags -1 - moreinfo On ചൊവ്വ 25 ജൂലൈ 2017 08:31 വൈകു, Adam D. Barratt wrote: > The metadata for that bug is rather confused, not least because its > found and fixed lists apply to completely separate packages. Please fix > it so that it's clear which versions of which source packages are > actually affected by the issue. Updated the bug metadata. It is found in 2.19-1 and fixed in 2.19-1.1 signature.asc Description: OpenPGP digital signature
Bug#869667: stretch-pu: package xkeyboard-config/2.19-1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This fixes serious bug #865316 (all Indic language users were unable to select their keyboard layouts in stretch introducing a regression. This was caused by an earlier commit upstream which blacklisted Indic keyboard layouts, upstream was convinced it was a mistake and reverted the blacklist. This update applies that patch to debian package so stretch users can type using Indic language keyboards again). debdiff attached. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8) Init: systemd (via /run/systemd/system) diff -u xkeyboard-config-2.19/debian/changelog xkeyboard-config-2.19/debian/changelog --- xkeyboard-config-2.19/debian/changelog +++ xkeyboard-config-2.19/debian/changelog @@ -1,3 +1,12 @@ +xkeyboard-config (2.19-1.1+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * Revert blacklisting of Indic layouts (Closes: #865316) +Now Indic keyboards can be selected from list of available keyboard layouts +like in previous stable releases. This was reverted upstream as well. + + -- Pirate Praveen Tue, 18 Jul 2017 13:08:55 +0530 + xkeyboard-config (2.19-1) unstable; urgency=medium * New upstream release. diff -u xkeyboard-config-2.19/debian/patches/series xkeyboard-config-2.19/debian/patches/series --- xkeyboard-config-2.19/debian/patches/series +++ xkeyboard-config-2.19/debian/patches/series @@ -2,0 +3 @@ +revert-indic-blacklist.diff only in patch2: unchanged: --- xkeyboard-config-2.19.orig/debian/files +++ xkeyboard-config-2.19/debian/files @@ -0,0 +1 @@ +xkeyboard-config_2.19-1.1_source.buildinfo x11 extra only in patch2: unchanged: --- xkeyboard-config-2.19.orig/debian/patches/revert-indic-blacklist.diff +++ xkeyboard-config-2.19/debian/patches/revert-indic-blacklist.diff @@ -0,0 +1,756 @@ +From bba001a451ae79a983b3ecac40ff86c4121c83c8 Mon Sep 17 00:00:00 2001 +From: Akshay S Dinesh +Date: Wed, 21 Jun 2017 18:19:18 +0530 +Subject: Whitelist Indian keyboard layouts. #101532 + +Indian keyboard layouts were moved into extras in #96418. +This was not necessary as it was indeed possible to type complex +characters of Indian scripts using these layouts. + +Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=101532 + +Signed-off-by: Akshay S Dinesh + +--- a/rules/base.xml.in b/rules/base.xml.in +@@ -1805,6 +1805,27 @@ + + + ++bd ++ ++<_shortDescription>bn ++<_description>Bangla ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++probhat ++<_description>Bangla (Probhat) ++ ++ ++ ++ ++ ++ + in + + <_shortDescription>in +@@ -1813,6 +1834,286 @@ + + + ++ben ++ ++<_shortDescription>bn ++<_description>Bangla (India) ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++ben_probhat ++ ++<_shortDescription>bn ++<_description>Bangla (India, Probhat) ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++ben_baishakhi ++<_description>Bangla (India, Baishakhi) ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++ben_bornona ++<_description>Bangla (India, Bornona) ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++ben_gitanjali ++<_description>Bangla (India, Uni Gitanjali) ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++ben_inscript ++<_description>Bangla (India, Baishakhi Inscript) ++ ++ ben ++ ++ sat ++ ++ ++ ++ ++ ++eeyek ++<_description>Manipuri (Eeyek) ++ ++ mni ++ ++ ++ ++ ++ ++guj ++ ++<_shortDescription>gu ++<_description>Gujarati ++ ++ guj ++ ++ ++ ++ ++ ++
Re: Bug#857986: [Pkg-javascript-devel] Bug#857986: npm: This pakcage is 3 years old? (consider removal)
On തിങ്കള് 22 മെയ് 2017 06:41 വൈകു, Jonas Smedegaard wrote: > ...for the _initial_ packaging work. > > We are package *maintainers*. If you have not realized, we are discussing about maintaining an existing package. I think you have also not realized the meaning of team maintained packages. The person who did the initial package need not be the maintainer of the packager for ever. When there is enough interest in the package, it will remain maintained else it gets removed. signature.asc Description: OpenPGP digital signature
Re: [Pkg-javascript-devel] Bug#857986: npm: This pakcage is 3 years old? (consider removal)
On വെള്ളി 19 മെയ് 2017 03:45 വൈകു, Jérémy Lal wrote: > There are complications to distributing npm: it depends on a LOT of > modules, which > means it requires a lot of debian-maintainer time to package, and update. https://wiki.debian.org/Javascript/Nodejs/Tasks/npm ie, roughly about 78 new modules to package. If one person were to work full time, I think about 10-15 days time. signature.asc Description: OpenPGP digital signature
Bug#858163: unblock: gitlab/8.13.11+dfsg-6
On Friday 21 April 2017 05:11 PM, Niels Thykier wrote:
> Apparently "[ -d ${foo} ]" returns 0 even if foo is unset. Fortunately,
> there are no "standard" directories in the list of dirs being removed,
> but I would prefer if the next upload had an explicit check for
> "${gitlab_data_dir}" being non-empty. Just to be future-proof.
Added it in git repo. Will upload once current version migrates.
diff --git a/debian/postrm b/debian/postrm
index 87340ef6..b563faed 100644
--- a/debian/postrm
+++ b/debian/postrm
@@ -58,9 +58,11 @@ case "$1" in
# Check if we should remove data?
db_get gitlab/purge_data
if [ "${RET}" = "true" ]; then
-if [ -d ${gitlab_data_dir} ]; then
+if [ -n "${gitlab_data_dir}" ] && [ -d ${gitlab_data_dir} ]; then
for i in shared public db repositories secrets.yml
Gemfile.lock; do
-if [ -e ${gitlab_data_dir}/$i ]; then rm -rf
${gitlab_data_dir}/$i; fi
+if [ -e ${gitlab_data_dir}/$i ]; then
+ echo "Removing: ${gitlab_data_dir}/$i"
+ rm -rf ${gitlab_data_dir}/$i; fi
done
fi
for i in ${gitlab_log_dir} ${gitlab_cache_path} ${gitlab_pid_path} \
> I will unblock with an ageing of 5 days to give other people a chance to
> review it and provide comments before it migrates. Again, this is not
> my strongest suit.
But tracker.debian.org is showing 10 days still.
signature.asc
Description: OpenPGP digital signature
Bug#858163: unblock: gitlab/8.13.11+dfsg-6
Control: retitle unblock: gitlab/8.13.11+dfsg1-2
On Friday 21 April 2017 01:13 PM, Ansgar Burchardt wrote:
> I believe maintainer scripts (and various other parts) should use
> `runuser` instead of `su`. It does not open PAM sessions which seems
> to sometimes cause problems.
>
> `/sbin/runuser` is already available in Jessie, so there should be no
> issues with using it.
>
> (Maybe one should add something to Policy about `runuser`?)
>
> Ansgar
>
I have now switched to using runuser. I have also switched to using
dbconfig-common to fix #859200.
diff -Nru gitlab-8.13.11+dfsg1/debian/changelog
gitlab-8.13.11+dfsg1/debian/changelog
--- gitlab-8.13.11+dfsg1/debian/changelog 2017-04-20 11:47:49.0
+0530
+++ gitlab-8.13.11+dfsg1/debian/changelog 2017-04-21 13:16:43.0
+0530
@@ -1,3 +1,12 @@
+gitlab (8.13.11+dfsg1-2) unstable; urgency=medium
+
+ * Integrate dbconfig-common (Closes: #859200)
+ * Don't set default gitlab user in postinst
+ * Change template name from purge to purge_data
+ * Switch to runuser from su (runuser correctly handles PAM sessions)
+
+ -- Pirate Praveen Fri, 21 Apr 2017 13:16:43 +0530
+
gitlab (8.13.11+dfsg1-1) unstable; urgency=medium
[ Balasankar C ]
diff -Nru gitlab-8.13.11+dfsg1/debian/config gitlab-8.13.11+dfsg1/debian/config
--- gitlab-8.13.11+dfsg1/debian/config 2017-04-20 11:47:49.0 +0530
+++ gitlab-8.13.11+dfsg1/debian/config 2017-04-21 13:16:43.0 +0530
@@ -42,3 +42,16 @@
# Do you want to change gitlab user?
db_input high gitlab/user || true
db_go
+db_get gitlab/user
+gitlab_user=$RET
+
+# source dbconfig-common shell library, and call the hook function
+if [ -f /usr/share/dbconfig-common/dpkg/config ]; then
+ . /usr/share/dbconfig-common/dpkg/config
+
+ dbc_dbtypes="pgsql"
+ dbc_dbname="gitlab_production"
+ dbc_dbuser="$gitlab_user"
+
+ dbc_go $gitlab_user "$@"
+fi
diff -Nru gitlab-8.13.11+dfsg1/debian/control
gitlab-8.13.11+dfsg1/debian/control
--- gitlab-8.13.11+dfsg1/debian/control 2017-04-20 11:47:49.0 +0530
+++ gitlab-8.13.11+dfsg1/debian/control 2017-04-21 13:16:43.0 +0530
@@ -22,6 +22,7 @@
rake,
bundler,
postgresql-client,
+ dbconfig-pgsql | dbconfig-no-thanks,
adduser (>= 3.34~),
bc,
postgresql-contrib,
diff -Nru gitlab-8.13.11+dfsg1/debian/gitlab-check.sh
gitlab-8.13.11+dfsg1/debian/gitlab-check.sh
--- gitlab-8.13.11+dfsg1/debian/gitlab-check.sh 2017-04-20 11:47:49.0
+0530
+++ gitlab-8.13.11+dfsg1/debian/gitlab-check.sh 2017-04-21 13:16:43.0
+0530
@@ -10,4 +10,4 @@
# Check gitlab is configured correctly
printf "Check if Gitlab is configured correctly...\n"
-su ${gitlab_user} -s /bin/sh -c 'bundle exec rake gitlab:check'
+runuser -u ${gitlab_user} -- sh -c 'bundle exec rake gitlab:check'
diff -Nru gitlab-8.13.11+dfsg1/debian/gitlab.templates
gitlab-8.13.11+dfsg1/debian/gitlab.templates
--- gitlab-8.13.11+dfsg1/debian/gitlab.templates2017-04-20
11:47:49.0 +0530
+++ gitlab-8.13.11+dfsg1/debian/gitlab.templates2017-04-21
13:16:43.0 +0530
@@ -58,7 +58,7 @@
certificates must be renewed manually after 3 months, when current
letsencrypt certificate expire.
-Template: gitlab/purge
+Template: gitlab/purge_data
Type: boolean
Default: true
_Description: Remove all data?
diff -Nru gitlab-8.13.11+dfsg1/debian/grantpriv.sh
gitlab-8.13.11+dfsg1/debian/grantpriv.sh
--- gitlab-8.13.11+dfsg1/debian/grantpriv.sh2017-04-20 11:47:49.0
+0530
+++ gitlab-8.13.11+dfsg1/debian/grantpriv.sh1970-01-01 05:30:00.0
+0530
@@ -1,25 +0,0 @@
-#!/bin/sh
-set -e
-
-dbname=gitlab_production
-
-# Take gitlab_user from envornment variable or use gitlab
-gitlab_user=${gitlab_user:-gitlab}
-
-# If gitlab user cannot access gitlab_production,
-# then it means the gitlab role does not exist
-if ! su ${gitlab_user} -c 'psql gitlab_production -c ""'
-then
- echo "Create ${gitlab_user} user with create database privillege..."
- su postgres -c "psql -c \"CREATE USER ${gitlab_user} CREATEDB;\""
-fi
-
-# By default the gitlab_prodcution is not owned by gitlab user
-echo "Make ${gitlab_user} user owner of $dbname database..."
-su postgres -c "psql -c \"ALTER DATABASE $dbname OWNER to ${gitlab_user};\""
-
-echo "Grant all privileges to ${gitlab_user} user..."
-su postgres -c "psql -c \"GRANT ALL PRIVILEGES ON DATABASE template1 to
${gitlab_user};\""
-
-# enable the pg_trgm extension
-su postgres -c "psql -d $dbname -c \"CREATE EXTENSION IF NOT EXISTS pg_trgm;\""
diff -Nru gitlab-8.13.11+dfsg1/debian/install
gitlab-8.13.11+dfsg1/debian/install
--- gitlab-8.13.11+dfsg1/debian/install 2017-04-20 11:47:49.0 +0530
+++ gitlab-8.13.11+dfsg1/debian/install 2017-04-21 13:16
Bug#858163: unblock: gitlab/8.13.11+dfsg-6
config (important/RC bug):
>
> The config file uses the debconf database as a registry. It should
> "pre-seed" itself with the defaults from the configuration files. See
> "man 8 debconf-devel" under "config file handling":
>
> https://manpages.debian.org/jessie/debconf-doc/debconf-devel.7.en.html#ADVANCED_PROGRAMMING_WITH_DEBCONF
>
all variables are now seeded from config file.
> * debian/postinst (RC bug):
>
> """
> # Override User for systemd services
> for service in mailroom unicorn sidekiq workhorse; do
> path=/etc/systemd/system/gitlab-${service}.service.d
> mkdir -p $path
> printf "[Service]\nUser=${gitlab_user}\n" > $path/override.conf
> done
> """
>
> This part appears to override
> "/etc/systemd/system/gitlab-${service}.service.d/override.conf"
> completely, disregarding an existing file the admin may have created.
> AFAICT, this happens on "configure" (i.e. it will also apply to
> upgrades) - but even if it only happened on first install, it would
> break admins who use puppet to push out a config file before installing
> gitlab.
Now it checks if the file already exist before writing it.
> There is a similar snippet in the postrm, but it occurs only on purge,
> so that should be fine.
>
> * debian/postinst (minor <-> RC bug, not sure):
>
> If the postinst script is rerun with a new gitlab user, then the
> references in "${gitlab_debian_conf_private}" and
> "${gitlab_yml_private}" is not updated. I suspect we are in the "RC
> Bug" level because that means the postinst will use the wrong user when
> using ucf to compare the "${gitlab_yml_private}" config with the actual
> config.
Now private copies are also updated.
> * debian/{postinst,postrm} (possible RC bug):
>
> I am not entirely confident that the handling of gitlab user is sound in
> case the admin uses a non-standard gitlab user and removes the config
> file prior to purging. AFAICT, it will cause the postrm to attempt to
> remove the "gitlab" user (which is the default name) rather than the
> actual user.
No, gitlab user is only defined in the config file (it is not in defaults).
> Even if the postrm would gracefully handle that the default user does
> not exist, then we still leave the system with an open system account
> that should have been locked/deleted.
I don't think we can do anything about an admin removing a config file
and still expecting everything to work.
> I wish I could say I had a proper solution for that, but I don't. I am
> really not sure how to handle that gracefully AND correctly at the same
> time. Worst case, the best/only option may be to undo making the gitlab
> user name customizable. At the very least, it is a lot more complex
> than we initially thought.
Since this is a user facing option (it becomes part of the ssh url git@
or gitlab@), I'd like to keep it selectable.
> * debian/README.Debian (minor):
>
> This file uses "export $(cat /etc/gitlab/gitlab-debian.conf)" in at
> least 4 places, which will fail if there are comments in the config
> file. It would be nice if those were fixed to source the file instead
> like the maintainer scripts does.
Updated.
>
>
> I must admit, I am not entirely confident that I found all the possible
> issues in the maintainer scripts. I would highly recommend a review
> from another person once the above have been fixed.
ok.
In addition to the changes mentioned above, it also fixes the rc bug #858725
diff -Nru gitlab-8.13.11+dfsg/debian/changelog
gitlab-8.13.11+dfsg1/debian/changelog
--- gitlab-8.13.11+dfsg/debian/changelog2017-03-23 17:16:50.0
+0530
+++ gitlab-8.13.11+dfsg1/debian/changelog 2017-04-20 11:47:49.0
+0530
@@ -1,3 +1,20 @@
+gitlab (8.13.11+dfsg1-1) unstable; urgency=medium
+
+ [ Balasankar C ]
+ * Repack source to remove fuzzaldrin-plus.js (Closes: #858725)
+
+ [ Pirate Praveen ]
+ * debian/postrm: Make checks idempotent (use if in place of &&)
+ * debian/postrm: Check variables are defined before using them
+ * debian/config: pre-seed variables to debconf db from config files
+ * debian/postinst:
+ - make sure all required variables are present in the config file
+ - handle reconfiguration correctly by reapplying variables from debconf db
+ to config files
+ - Don't touch systemd override.conf if already exist
+
+ -- Pirate Praveen Thu, 20 Apr 2017 11:47:49 +0530
+
gitlab (8.13.11+dfsg-8) unstable; urgency=medium
* Don't fail if gitlab-debian.defaults not found (to support upgrading
diff -Nru gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.exam
Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2
On Saturday 25 March 2017 10:46 PM, Ivo De Decker wrote: > Hi, > > On Fri, Mar 24, 2017 at 10:52:44AM +0530, Pirate Praveen wrote: >> I don't understand why diaspora-installer was removed from testing. #858521 >> was >> only affecting unstable. > > There are serious doubts whether this package is suitable for a stable > release. The version that was in testing clearly wasn't (#856720 was the > trigger for the original request in this unblock bug). Previous attempts to > fix the issues weren't successful, and a review of the latest changes, > combined with the filing of #858521 (which was found by piuparts testing), > raises serious concerns about the quality of the package. For it to be allowed > back into testing, a thorough review of the entire packaging would be needed, > and I don't know it that's realistic for stretch. I believe this is arbitrary, unfair and de-motivating. I can understand packages getting removed when it has long standing rc bugs and there was no activity from the maintainer. Here I have always responded quickly to any rc bugs and currently it has no pending rc bugs. #856720 caused marking for auto-removal, but it was already fixed (its auto removal date was not reached). #858521 was also fixed quickly. I agree it was a big mistake, it happened because I was focusing on diaspora-installer binary package for testing and purging of diaspora-common binary was slipped. It was indeed a regression, but having a single critical regression which was fixed soon does not qualify (is not enough) for a removal. I hope you'll reconsider your decision. > Cheers, > > Ivo > > signature.asc Description: OpenPGP digital signature
Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2
I don't understand why diaspora-installer was removed from testing. #858521 was only affecting unstable. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2
Control: retitle -1 unblock: diaspora-installer/0.6.3.0+debian3
On Tuesday 21 March 2017 06:14 PM, Pirate Praveen wrote:
> Attaching debdiff.
piuparts found another regression (I was testing only diaspora-installer
extensively, but missed testing diaspora-common).
diff -Nru diaspora-installer-0.6.3.0+debian3/debian/changelog
diaspora-installer-0.6.3.0+debian4/debian/changelog
--- diaspora-installer-0.6.3.0+debian3/debian/changelog 2017-03-20
18:45:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian4/debian/changelog 2017-03-23
13:57:10.0 +0530
@@ -1,3 +1,9 @@
+diaspora-installer (0.6.3.0+debian4) unstable; urgency=medium
+
+ * Fix regression in diaspora-common.postrm which removes /bin by mistake
+
+ -- Pirate Praveen Thu, 23 Mar 2017 13:57:10 +0530
+
diaspora-installer (0.6.3.0+debian3) unstable; urgency=medium
* Remove data during purge after user confirmation
diff -Nru diaspora-installer-0.6.3.0+debian3/debian/diaspora-common.postrm
diaspora-installer-0.6.3.0+debian4/debian/diaspora-common.postrm
--- diaspora-installer-0.6.3.0+debian3/debian/diaspora-common.postrm
2017-03-20 18:45:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian4/debian/diaspora-common.postrm
2017-03-23 13:57:10.0 +0530
@@ -52,15 +52,18 @@
ucf --purge /etc/dbconfig-common/diaspora-common.conf
ucfr --purge diaspora-common
/etc/dbconfig-common/diaspora-common.conf
fi
-rm -rf ${diaspora_user_home}/public
-rm -rf ${diaspora_user_home}/app-assets
-rm -rf ${diaspora_user_home}/Gemfile.lock
-rm -rf ${diaspora_user_home}/.bundle
-rm -rf ${diaspora_user_home}/vendor
-rm -rf ${diaspora_home}/app/assets
-rm -rf ${diaspora_home}/db
-rm -rf ${diaspora_home}/bin
-rm -rf /var/cache/diaspora /var/log/diaspora
+diaspora_user_home=/var/lib/diaspora
+if [ -d ${diaspora_user_home} ]; then
+ for i in public app-assets Gemfile.lock .bundle vendor; do
+test -e ${diaspora_user_home}/$i && rm -rf ${diaspora_user_home}/$i
+ done
+fi
+diaspora_home=/usr/share/diaspora
+if [ -d ${diaspora_home} ]; then
+ for i in db bin app/assets; do
+test -e ${diaspora_home}/$i && rm -rf ${diaspora_home}/$i
+ done
+fi
echo "Removing user: diaspora"
id -u diaspora && userdel -r diaspora
fi
signature.asc
Description: OpenPGP digital signature
Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2
Attaching debdiff. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. diaspora-installer_0.6.3.0+debian1.dsc..diaspora-installer_0.6.3.0+debian3.dsc.debdiff Description: Binary data
Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2
control: retitle -1 unblock: diaspora-installer/0.6.3.0+debian3
On 2017, മാർച്ച് 20 3:15:18 AM IST, Emilio Pozuelo Monfort
wrote:
>On 19/03/17 14:49, Pirate Praveen wrote:
>
>> +for i in vendor,app,bin,db,config; do
>> + mkdir ${diaspora_home}/$i
>> +done
>
>That's going to create one folder names 'vendor,app,bin,db,config'...
>which
>makes me wonder whether you actually tested this change?
I was not very thorough last time. I have fixed this and also tested things
more thoroughly this time.
Purging has been made more robust now.
>Also for these kind of changes, you should probably wait a bit longer
>before
>requesting an unblock - so that you don't have to request it several
>times if
>you end up needing additional changes.
>
I saw piuparts installed it successfully. But looking back there it only tests
diaspora-common.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#858180: unblock: diaspora-installer/0.6.3.0+debian2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package diaspora-installer
This fixes RC bug #856720
migrate-to-0.6.3.0.sh is just used as a note, its not used anywhere and
its not installed.
unblock diaspora-installer/0.6.3.0+debian2
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru diaspora-installer-0.6.3.0+debian1/debian/changelog
diaspora-installer-0.6.3.0+debian2/debian/changelog
--- diaspora-installer-0.6.3.0+debian1/debian/changelog 2017-01-26
04:39:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian2/debian/changelog 2017-03-17
11:43:04.0 +0530
@@ -1,3 +1,12 @@
+diaspora-installer (0.6.3.0+debian2) unstable; urgency=medium
+
+ * Change section to net (Closes: #832219)
+ * Crete public/source.tar.gz only if the file is missing
+ * Fix diaspora backup logic for updates (to remove files removed upstream)
+(Closes: #856720)
+
+ -- Pirate Praveen Fri, 17 Mar 2017 11:43:04 +0530
+
diaspora-installer (0.6.3.0+debian1) unstable; urgency=medium
* Install 0.6.3.0 version
diff -Nru diaspora-installer-0.6.3.0+debian1/debian/control
diaspora-installer-0.6.3.0+debian2/debian/control
--- diaspora-installer-0.6.3.0+debian1/debian/control 2017-01-26
04:39:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian2/debian/control 2017-03-15
10:12:32.0 +0530
@@ -1,5 +1,5 @@
Source: diaspora-installer
-Section: ruby
+Section: net
Priority: optional
Maintainer: Debian Ruby Extras Maintainers
Uploaders: Pirate Praveen
@@ -15,7 +15,7 @@
Package: diaspora-installer
Architecture: all
-Section: contrib/ruby
+Section: contrib/net
XB-Ruby-Versions: ${ruby:Versions}
Depends: build-essential,
diaspora-common (= ${source:Version}),
diff -Nru diaspora-installer-0.6.3.0+debian1/debian/postinst
diaspora-installer-0.6.3.0+debian2/debian/postinst
--- diaspora-installer-0.6.3.0+debian1/debian/postinst 2017-01-26
04:39:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian2/debian/postinst 2017-03-17
11:12:41.0 +0530
@@ -56,8 +56,9 @@
echo "Precompiling assets..."
su diaspora -s /bin/sh -c 'bundle exec rake tmp:cache:clear
assets:precompile'
+# preinst creates backup (to be able to remove files removed upstream)
echo "Remove backup..."
-rm -rf ${diaspora_home}-backup.*
+rm -rf ${diaspora_home}/.backup.*
# Starting diaspora
service diaspora start
diff -Nru diaspora-installer-0.6.3.0+debian1/debian/preinst
diaspora-installer-0.6.3.0+debian2/debian/preinst
--- diaspora-installer-0.6.3.0+debian1/debian/preinst 2017-01-26
04:39:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian2/debian/preinst 2017-03-17
11:12:41.0 +0530
@@ -2,6 +2,7 @@
set -e
diaspora_home=/usr/share/diaspora
+diaspora_symlinks_list="Gemfile.lock log tmp app/assets bin/bundle
vendor/bundle db/schema.rb config/database.yml config/diaspora/yml"
# Fix bin symlink set by earlier versions
if test -L ${diaspora_home}/bin
@@ -10,20 +11,21 @@
fi
# Backup the previous version
-# Just keep the config and vendor/bundle
+# Just keep the modified files/directories
+# We need this to remove files removed upstream
backup() {
-cp -r ${diaspora_home}/config ${diaspora_home}-config
-cp -r ${diaspora_home}/vendor/bundle ${diaspora_home}-vendor-bundle
-cp -r ${diaspora_home}/.bundle ${diaspora_home}.bundle
backup_suffix=$(openssl rand -hex 4)
-mv ${diaspora_home} ${diaspora_home}-backup.${backup-suffix}
-mkdir ${diaspora_home}
-mkdir ${diaspora_home}/vendor
-mv ${diaspora_home}-config ${diaspora_home}/config
-mv ${diaspora_home}-vendor-bundle ${diaspora_home}/vendor/bundle
-mv ${diaspora_home}.bundle ${diaspora_home}/.bundle
-mv ${diaspora_home}-backup.${backup-suffix}/public ${diaspora_home}/public
-
+backup_dir=${diaspora_home}/.backup.${backup_suffix}
+mkdir ${backup_dir}
+mv ${diaspora_home}/* ${backup_dir}
+
+for i in vendor,app,bin,db,config; do
+ mkdir ${diaspora_home}/$i
+done
+
+for i in ${diaspora_symlinks_list}; do
+ mv ${backup_dir}/$i ${diaspora_home}/$i
+done
}
case "$1" in
diff -Nru diaspora-installer-0.6.3.0+debian1/diaspora-download.sh
diaspora-installer-0.6.3.0+debian2/diaspora-download.sh
--- diaspora-installer-0.6.3.0+debian1/diaspora-download.sh 2017-01-26
04:39:32.0 +0530
+++ diaspora-installer-0.6.3.0+debian2/diaspora-download.sh 2017-03-17
11:00:01.0 +0530
@@ -33,7 +33,7 @@
e
Bug#858163: unblock: gitlab/8.13.11+dfsg-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gitlab
This fixes RC bug #857967. Also sine the version in stretch is currently
not installable, please reduce the age.
debdiff with 8.13.11+dfsg-5 attached (changes upto this version is
already approved)
unblock gitlab/8.13.11+dfsg-6
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gitlab-8.13.11+dfsg/debian/changelog
gitlab-8.13.11+dfsg/debian/changelog
--- gitlab-8.13.11+dfsg/debian/changelog2017-03-14 17:21:21.0
+0530
+++ gitlab-8.13.11+dfsg/debian/changelog2017-03-17 22:29:40.0
+0530
@@ -1,3 +1,9 @@
+gitlab (8.13.11+dfsg-6) unstable; urgency=medium
+
+ * Improve configuration file parsing by using source (Closes: #857967)
+
+ -- Pirate Praveen Fri, 17 Mar 2017 22:29:40 +0530
+
gitlab (8.13.11+dfsg-5) unstable; urgency=medium
* Move variables used only in maintainer scripts to /usr/lib from /etc
diff -Nru gitlab-8.13.11+dfsg/debian/conf/gitlab
gitlab-8.13.11+dfsg/debian/conf/gitlab
--- gitlab-8.13.11+dfsg/debian/conf/gitlab 2017-03-14 17:21:21.0
+0530
+++ gitlab-8.13.11+dfsg/debian/conf/gitlab 2017-03-17 18:05:51.0
+0530
@@ -7,9 +7,8 @@
# Normal values are "production", "test" and "development".
RAILS_ENV="production"
-# Read and export debian specific configuration
-# Only exported variables will be passed on to gitlab app
-export $(cat /etc/gitlab/gitlab-debian.conf)
+# Read debian specific configuration
+. /etc/gitlab/gitlab-debian.conf
# app_user defines the user that GitLab is run as.
# The default is "git".
diff -Nru gitlab-8.13.11+dfsg/debian/gitlab-check.sh
gitlab-8.13.11+dfsg/debian/gitlab-check.sh
--- gitlab-8.13.11+dfsg/debian/gitlab-check.sh 2017-03-14 17:21:21.0
+0530
+++ gitlab-8.13.11+dfsg/debian/gitlab-check.sh 2017-03-17 21:42:48.0
+0530
@@ -2,12 +2,12 @@
set -e
-# Read and export debian specific configuration
-# Only exported variables will be passed on to gitlab app
-export $(cat /etc/gitlab/gitlab-debian.conf)
+# Read debian specific configuration
+. /etc/gitlab/gitlab-debian.conf
+export DB RAILS_ENV
+
cd /usr/share/gitlab
# Check gitlab is configured correctly
printf "Check if Gitlab is configured correctly...\n"
-su ${gitlab_user} -s /bin/sh -c 'bundle exec rake gitlab:check
RAILS_ENV=production'
-
+su ${gitlab_user} -s /bin/sh -c 'bundle exec rake gitlab:check'
diff -Nru gitlab-8.13.11+dfsg/debian/postinst
gitlab-8.13.11+dfsg/debian/postinst
--- gitlab-8.13.11+dfsg/debian/postinst 2017-03-14 17:21:21.0 +0530
+++ gitlab-8.13.11+dfsg/debian/postinst 2017-03-17 21:58:12.0 +0530
@@ -40,19 +40,19 @@
# `abort-remove' or `abort-deconfigure'.
###
-# Read and export debian specific configuration
-# Only exported variables will be passed on to gitlab app
+# Read debian specific configuration
###
# Bootstrap config file - first try
-export $(cat ${gitlab_debian_conf_example})
+. ${gitlab_debian_conf_example}
# second try
test -f ${gitlab_debian_conf_private} || \
cp ${gitlab_debian_conf_example} ${gitlab_debian_conf_private}
-export $(cat ${gitlab_debian_conf_private})
+. ${gitlab_debian_conf_private}
# If /etc/gitlab/gitlab-debian.conf is already present, use it
-test -f ${gitlab_debian_conf} && export $(cat ${gitlab_debian_conf})
+test -f ${gitlab_debian_conf} && . ${gitlab_debian_conf}
+export DB RAILS_ENV
# Read default values (we cannot do this before gitlab-debian.conf is exported
# as we want to override variables set by gitlab-debian.conf in earlier gitlab
@@ -76,7 +76,7 @@
###
# update Gemfile.lock, always
###
-su ${gitlab_user} -s /bin/sh -c 'truncate -s 0 ${gitlab_data_dir}/Gemfile.lock'
+su ${gitlab_user} -s /bin/sh -c "truncate -s 0 ${gitlab_data_dir}/Gemfile.lock"
cd ${gitlab_app_root}
if ! su ${gitlab_user} -s /bin/sh -c 'bundle --local --quiet'; then
if [ "$1" = "triggered" ]; then
diff -Nru gitlab-8.13.11+dfsg/debian/postrm gitlab-8.13.11+dfsg/debian/postrm
--- gitlab-8.13.11+dfsg/debian/postrm 2017-03-14 17:21:21.0 +0530
+++ gitlab-8.13.11+dfsg/debian/postrm 2017-03-17 18:08:07.0 +0530
@@ -17,8 +17,8
Bug#854658: unblock pre-approval request for gitlab
On വെള്ളി 24 ഫെബ്രുവരി 2017 08:19 വൈകു, Balasankar C wrote: > Should I share the source debdiff of both these uploads to this issue or is a > separate issue necessary for gitlab-shell (The change is exactly the one > mentioned for gitlab. Not using /usr/share/gitlab-shell/doc ) ? > Attaching the source debdiffs. diff -Nru gitlab-8.13.11+dfsg/debian/changelog gitlab-8.13.11+dfsg/debian/changelog --- gitlab-8.13.11+dfsg/debian/changelog2017-02-16 17:35:29.0 +0530 +++ gitlab-8.13.11+dfsg/debian/changelog2017-02-24 17:06:52.0 +0530 @@ -1,3 +1,18 @@ +gitlab (8.13.11+dfsg-4) unstable; urgency=medium + + [ Balasankar C ] + * Update description to specify that the package is non-omnibus, unlike the +official one from GitLab. + * Remove database on purge only if necessary commands are available +(Closes: #855579) + + [ Pirate Praveen ] + * Use /usr/lib/gitlab/templates for config file templates used in postinst +(See 854658#34) + * Add more checks in postrm to avoid failures which can be ignored + + -- Balasankar C Fri, 24 Feb 2017 17:06:52 +0530 + gitlab (8.13.11+dfsg-3) unstable; urgency=medium * Allow choosing gitlab user (Closes: #854617) diff -Nru gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example --- gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example 2017-02-16 17:35:29.0 +0530 +++ gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example 2017-02-20 18:08:33.0 +0530 @@ -4,13 +4,13 @@ gitlab_data_dir=/var/lib/gitlab gitlab_cache_path=/var/cache/gitlab gitlab_scripts=/usr/lib/gitlab/scripts -gitlab_yml_example=/usr/share/doc/gitlab/gitlab.yml.example +gitlab_yml_example=/usr/lib/gitlab/templates/gitlab.yml.example gitlab_yml_private=/var/lib/gitlab/gitlab.yml gitlab_yml=/etc/gitlab/gitlab.yml -gitlab_debian_conf_example=/usr/share/doc/gitlab/gitlab-debian.conf.example +gitlab_debian_conf_example=/usr/lib/gitlab/templates/gitlab-debian.conf.example gitlab_debian_conf_private=/var/lib/gitlab/gitlab-debian.conf gitlab_debian_conf=/etc/gitlab/gitlab-debian.conf -gitlab_shell_config_example=/usr/share/doc/gitlab-shell/config.yml.example +gitlab_shell_config_example=/usr/lib/gitlab-shell/config.yml.example gitlab_shell_config_private=/var/lib/gitlab/gitlab-shell-config.yml gitlab_shell_config=/etc/gitlab-shell/config.yml gitlab_nginx_log=/var/log/gitlab @@ -19,10 +19,10 @@ gitlab_shell_log=/var/log/gitlab-shell gitlab_log_dir=/var/log/gitlab gitlab_pid_path=/run/gitlab -gitlab_tmpfiles_example=/usr/share/doc/gitlab/tmpfiles.d/gitlab.conf.example +gitlab_tmpfiles_example=/usr/lib/gitlab/templates/tmpfiles.d/gitlab.conf.example gitlab_tmpfiles_private=/var/lib/gitlab/tmpfiles.d-gitlab.conf gitlab_tmpfiles=/usr/lib/tmpfiles.d/gitlab.conf nginx_user=www-data -nginx_conf_example=/usr/share/doc/gitlab/nginx.conf.example -nginx_ssl_conf_example_gz=/usr/share/doc/gitlab/nginx.ssl.conf.example.gz +nginx_conf_example=/usr/lib/gitlab/templates/nginx.conf.example +nginx_ssl_conf_example=/usr/lib/gitlab/templates/nginx.ssl.conf.example nginx_site_private=/var/lib/gitlab/nginx.conf diff -Nru gitlab-8.13.11+dfsg/debian/control gitlab-8.13.11+dfsg/debian/control --- gitlab-8.13.11+dfsg/debian/control 2017-02-16 17:35:29.0 +0530 +++ gitlab-8.13.11+dfsg/debian/control 2017-02-20 19:54:52.0 +0530 @@ -31,7 +31,7 @@ postfix | exim4 | mail-transport-agent, openssh-client, ucf, - gitlab-shell (>= 3.6.6-3~), + gitlab-shell (>= 3.6.6-4~), gitlab-workhorse (>= 0.8.5~), ruby-rails (>= 2:4.2.7~), ruby-rails (<< 2:5), @@ -241,8 +241,11 @@ libjs-graphael, libjs-fuzzaldrin-plus (>= 0.3.1+git.20161008.da2cb58+dfsg-4~) Recommends: certbot -Description: git powered software platform to collaborate on code +Description: git powered software platform to collaborate on code (non-omnibus) gitlab provides web based interface to host source code and track issues. It allows anyone for fork a repository and send merge requests. Code review is possible using merge request workflow. Using groups and roles project access can be controlled. + . + Unlike the official package from GitLab Inc., this package does not use + omnibus. diff -Nru gitlab-8.13.11+dfsg/debian/gitlab.docs gitlab-8.13.11+dfsg/debian/gitlab.docs --- gitlab-8.13.11+dfsg/debian/gitlab.docs 2017-02-16 17:35:29.0 +0530 +++ gitlab-8.13.11+dfsg/debian/gitlab.docs 2017-02-20 16:56:50.0 +0530 @@ -1,4 +1,2 @@ README.md debian/README.Debian -debian/conf/nginx.conf.example -debian/conf/nginx.ssl.conf.example diff -Nru gitlab-8.13.11+dfsg/debian/install gitlab-8.13.11+dfsg/debian/install --- gitlab-8.13.11+dfsg/debian/install 2017-02-16 17:35:29.0 +0530 +++ gitlab-8.13.11+dfsg/debian/install 2017-02-20 16:56:47.0 +0530 @@ -1,12 +1,14 @@ debian/conf/gitlab etc/default debian/conf/unicorn.rb etc/gitlab de
Re: Bug#704303: violates Debian Policy 2.3 Copyright considerations
On Sun, 19 Feb 2017 12:43:30 +0530 Pirate Praveen wrote: > On Sun, 1 Jan 2017 16:55:52 +0500 Andrey Rahmatullin > wrote: > > Note that since Policy 3.9.9 MPL should be in common-licenses. > > Reassigning to firefox, which also has the same issue. When is Policy > 3.9.9 expected to be released, would it be before stretch release? > since this will not be an issue after debian-policy 3.9.9 release, can this get a stretch-ignore tag?
Bug#854658: unblock pre-approval request for gitlab
On ഞായര് 19 ഫെബ്രുവരി 2017 02:17 വൈകു, Andreas Beckmann wrote: > On Fri, 17 Feb 2017 12:24:53 +0530 Pirate Praveen wrote: >> +gitlab_tmpfiles_example=/usr/share/doc/gitlab/tmpfiles.d/gitlab.conf.example > If this file gets used from the maintainer scripts, > it must be moved to /usr/share/gitlab instead, see > Policy 12.3: "Packages must not require the existence of any > files in /usr/share/doc/ in order to function." > > Andreas but /usr/share/gitlab is upstream files and I'm reluctant to add these debian specific files there, how about /usr/lib/gitlab/templates? signature.asc Description: OpenPGP digital signature
Bug#854658: unblock pre-approval request for gitlab
On വെള്ളി 17 ഫെബ്രുവരി 2017 12:24 വൈകു, Pirate Praveen wrote: > Attaching the debdiff (I'll upload it once current version in unstable > migrates to testing). gitlab 8.13.11+dfsg-3 is in unstable now. signature.asc Description: OpenPGP digital signature
Bug#854658: unblock pre-approval request for gitlab
On ഞായര് 12 ഫെബ്രുവരി 2017 12:24 രാവിലെ, Niels Thykier wrote:
> The two patches in the bug looks ok; assuming only a changelog entry on
> top of that, then it is a approved.
>
> For future requests: Could you please provide a source debdiff? It makes
> it easier for us for us to figure out what will be approved (which will
> hopefully also give you faster response times from us).
Attaching the debdiff (I'll upload it once current version in unstable
migrates to testing).
I just wanted to check if such changes will be accepted before starting
the work on it.
diff -Nru gitlab-8.13.11+dfsg/debian/adduser.sh
gitlab-8.13.11+dfsg/debian/adduser.sh
--- gitlab-8.13.11+dfsg/debian/adduser.sh 2017-02-07 11:24:36.0
+0530
+++ gitlab-8.13.11+dfsg/debian/adduser.sh 2017-02-16 17:35:29.0
+0530
@@ -8,9 +8,9 @@
# Create gitlab user with home in /var/lib
echo "Creating/updating ${gitlab_user} user account..."
-adduser --system --home /var/lib/${gitlab_user} --gecos "${gitlab_user} user"
--shell /bin/sh \
+adduser --system --home ${gitlab_data_dir} --gecos "${gitlab_user} user"
--shell /bin/sh \
--quiet --disabled-password --group ${gitlab_user} || {
echo "Proceeding with existing ${gitlab_user} user..."
}
-echo "Making ${gitlab_user} owner of /var/lib/${gitlab_user}..."
-chown -R ${gitlab_user} /var/lib/${gitlab_user}
+echo "Making ${gitlab_user} owner of ${gitlab_data_dir}..."
+chown -R ${gitlab_user} ${gitlab_data_dir}
diff -Nru gitlab-8.13.11+dfsg/debian/changelog
gitlab-8.13.11+dfsg/debian/changelog
--- gitlab-8.13.11+dfsg/debian/changelog2017-02-07 11:24:36.0
+0530
+++ gitlab-8.13.11+dfsg/debian/changelog2017-02-16 17:35:29.0
+0530
@@ -1,3 +1,14 @@
+gitlab (8.13.11+dfsg-3) unstable; urgency=medium
+
+ * Allow choosing gitlab user (Closes: #854617)
+ * Optionally remove all data on purge (Closes: #821087, #839929)
+
+ [ Johannes Schauer ]
+ * Amend the README.Debian with instructions of how to upgrade from
+non-Debian installations (Closes: #823743)
+
+ -- Pirate Praveen Thu, 16 Feb 2017 17:35:29 +0530
+
gitlab (8.13.11+dfsg-2) unstable; urgency=medium
* Use upstream patch for git 2.11 support (Closes: #853251)
diff -Nru gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example
gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example
--- gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example 2017-02-07
11:24:36.0 +0530
+++ gitlab-8.13.11+dfsg/debian/conf/gitlab-debian.conf.example 2017-02-16
17:35:29.0 +0530
@@ -1,6 +1,5 @@
RAILS_ENV=production
DB=postgres
-gitlab_user=gitlab
gitlab_app_root=/usr/share/gitlab
gitlab_data_dir=/var/lib/gitlab
gitlab_cache_path=/var/cache/gitlab
@@ -20,6 +19,9 @@
gitlab_shell_log=/var/log/gitlab-shell
gitlab_log_dir=/var/log/gitlab
gitlab_pid_path=/run/gitlab
+gitlab_tmpfiles_example=/usr/share/doc/gitlab/tmpfiles.d/gitlab.conf.example
+gitlab_tmpfiles_private=/var/lib/gitlab/tmpfiles.d-gitlab.conf
+gitlab_tmpfiles=/usr/lib/tmpfiles.d/gitlab.conf
nginx_user=www-data
nginx_conf_example=/usr/share/doc/gitlab/nginx.conf.example
nginx_ssl_conf_example_gz=/usr/share/doc/gitlab/nginx.ssl.conf.example.gz
diff -Nru gitlab-8.13.11+dfsg/debian/conf/gitlab.yml.example
gitlab-8.13.11+dfsg/debian/conf/gitlab.yml.example
--- gitlab-8.13.11+dfsg/debian/conf/gitlab.yml.example 2017-02-07
11:24:36.0 +0530
+++ gitlab-8.13.11+dfsg/debian/conf/gitlab.yml.example 2017-02-16
17:35:29.0 +0530
@@ -46,7 +46,7 @@
# relative_url_root: /gitlab
# Uncomment and customize if you can't use the default user to run GitLab
(default: 'git')
-user: gitlab
+user: GITLAB_USER
user_home: /var/lib/gitlab
## Date & Time settings
diff -Nru gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf
gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf
--- gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf 2017-02-07
11:24:36.0 +0530
+++ gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf 1970-01-01
05:30:00.0 +0530
@@ -1,2 +0,0 @@
-d /run/gitlab 2750 gitlab www-data -
-L /run/gitlab/cache - - - - /var/cache/gitlab
diff -Nru gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf.example
gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf.example
--- gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf.example
1970-01-01 05:30:00.0 +0530
+++ gitlab-8.13.11+dfsg/debian/conf/tmpfiles.d/gitlab.conf.example
2017-02-16 17:35:29.0 +0530
@@ -0,0 +1,2 @@
+d /run/gitlab 2750 GITLAB_USER www-data -
+L /run/gitlab/cache - - - - /var/cache/gitlab
diff -Nru gitlab-8.13.11+dfsg/debian/config gitlab-8.13.11+dfsg/debian/config
--- gitlab-8.13.11+dfsg/debian/config 2017-02-07 11:24:36.0 +0530
+++ gitlab-8.13.11+dfsg/debian/config 2017-02-16 17:35:29.0 +0530
@@ -24,3 +2
Bug#854540: Please unblock package gitlab
Control: reopen -1 On വെള്ളി 10 ഫെബ്രുവരി 2017 11:37 വൈകു, Jonathan Wiltshire wrote: > And an uploader, but ok. > > Unblocked. Hi Can you reduce the age too as its a grave bug? signature.asc Description: OpenPGP digital signature
Bug#854540: Please unblock package gitlab
Control: tags -1 - moreinfo Jonathan Wiltshire wrote: > If I read the diff right (and I'm happy to be corrected), you're patching > files in debian/ with a patch in debian/patches/ ? Seems an odd way to go > about things to me. The previous patch was incomplete and added a regression. Since upstream did not promise a timeline for the backport, I did the backport, but that missed some changes. This new patch is backported by upstream and tested to make sure the regression is gone. > Not all of your changes have entries in debian/changelog, please be careful > to document them thoroghly. only lintian warnings were updated, I will be more thorough in future updates.
Bug#851887: unblock: gitlab/8.13.11+dfsg-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gitlab
This fixes a grave bug #851714 (cannot push to default branch with git
2.11). This is a core feature of gitlab.
8.13.6 -> 8.13.11 is a patch update without any new features. All
enabled tests are passing
Finished in 40 minutes 7 seconds (files took 11.89 seconds to load)
4938 examples, 0 failures, 8 pending
Full log
https://ci.debian.net/data/packages/unstable/amd64/g/gitlab/latest-autopkgtest/log.gz
This would need unblocking the following packages too.
gitlab-shell: 3.6.6-2 (required for git 2.11 support for #851714)
ruby-turbolinks: 2.5.3-3 (adds backported patches from newer releases)
ruby-github-markup 1.5.1+dfsg-1 (patch update)
(include/attach the debdiff against the package in testing)
unblock gitlab/8.13.11+dfsg-1
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rw-r--r-- root/root /usr/share/gitlab/lib/gitlab/git/rev_list.rb
-rw-r--r-- root/root
/usr/share/gitlab/spec/controllers/search_controller_spec.rb
-rw-r--r-- root/root
/usr/share/gitlab/spec/features/projects/blobs/edit_spec.rb
-rw-r--r-- root/root
/usr/share/gitlab/spec/fixtures/api/schemas/user/login.json
-rw-r--r-- root/root
/usr/share/gitlab/spec/fixtures/api/schemas/user/public.json
-rw-r--r-- root/root
/usr/share/gitlab/spec/lib/gitlab/checks/force_push_spec.rb
-rw-r--r-- root/root /usr/share/gitlab/spec/lib/gitlab/git/rev_list_spec.rb
-rw-r--r-- root/root /usr/share/gitlab/spec/requests/api/helpers_spec.rb
-rw-r--r-- root/root
/usr/share/gitlab/vendor/assets/javascripts/jquery.turbolinks.js
Files in first .changes but not in second
-
-rw-r--r-- root/root /usr/share/gitlab/spec/requests/api/api_helpers_spec.rb
Control files: lines which differ (wdiff format)
Depends: debconf (>= 0.5) | debconf-2.0, init-system-helpers (>= 1.18~), ruby |
ruby-interpreter, lsb-base (>= 3.0-6), git (>= 1:2.7.3~), rake, bundler,
postgresql-client, adduser (>= 3.34~), bc, postgresql-contrib, redis-server (>=
2:2.8~), nodejs (>= 4~), nginx | httpd, postfix | exim4 | mail-transport-agent,
openssh-client, ucf, gitlab-shell (>= [-3.6.6~),-] {+3.6.6-2~),+}
gitlab-workhorse (>= 0.8.5~), ruby-rails (>= 2:4.2.7~), ruby-rails (<< 2:5),
ruby-rails-deprecated-sanitizer (>= 1.0.3~), ruby-responders (>= 2.0~),
ruby-sprockets (>= 3.6~), ruby-sprockets-es6 (>= 0.9.2~),
ruby-default-value-for (>= 3~), ruby-pg (>= 0.18.4~), ruby-devise (>= 4.2~),
ruby-doorkeeper (>= 4.0~), ruby-omniauth (>= 1.3.1~), ruby-omniauth-auth0 (>=
1.4.1~), ruby-omniauth-azure-oauth2 (>= 0.0.6~), ruby-omniauth-bitbucket (>=
0.0.2~), ruby-omniauth-cas3 (>= 1.1.2~), ruby-omniauth-facebook (>= 4.0~),
ruby-omniauth-github (>= 1.1.1~), ruby-omniauth-gitlab (>= 1.0.2~),
ruby-omniauth-google-oauth2 (>= 0.4.1~), ruby-omniauth-kerberos (>= 0.3.0-3~),
ruby-omniauth-saml (>= 1.7.0~), ruby-omniauth-shibboleth (>= 1.2.0~),
ruby-omniauth-twitter (>= 1.2.0~), ruby-omniauth-crowd (>= 2.2.0~),
ruby-rack-oauth2 (>= 1.2.1~), ruby-recaptcha (>= 3.0~), ruby-akismet,
ruby-devise-two-factor (>= 3.0~), ruby-rqrcode-rails3 (>= 0.1.7~),
ruby-attr-encrypted (>= 3.0~), ruby-u2f, ruby-browser (>= 2.2~),
ruby-gitlab-git (>= 10.7~), ruby-omniauth-ldap (>= 1.0.4~), ruby-gollum-lib (>=
4.2.1+debian~), ruby-github-linguist (>= 4.7.0~), ruby-grape (>= 0.16.2-2~),
ruby-grape-entity (>= 0.6~), ruby-rack-cors (>= 0.4.0~), ruby-kaminari (>=
0.17~), ruby-hamlit (>= 2.7~), ruby-carrierwave (>= 0.9~),
ruby-dropzonejs-rails (>= 0.7.1~), ruby-fog-aws (>= 0.9~), ruby-fog-azure,
ruby-fog-core (>= 1.40~), ruby-fog-local (>= 0.3~), ruby-fog-google (>= 0.3~),
ruby-fog-openstack (>= 0.1~), ruby-fog-rackspace, ruby-unf (>= 0.1.4-2~),
ruby-six (>= 0.2.0-3~), ruby-seed-fu (>= 2.3.5~), ruby-htmlentities (>=
4.3.3~), ruby-html-pipeline (>= 1.11.0), ruby-task-list (>= 1.0.5~),
ruby-github-markup (>= [-1.5~),-] {+1.5.1~),+} ruby-redcarpet (>= 3.3.4~),
ruby-redcloth (>= 4.3.2-2~), ruby-org (>= 0.9.12-2~), ruby-creole (>= 0.5.0~),
ruby-wikicloth (>= 0.8.1~), asciidoctor (>= 1.5.2~), ruby-rouge (>= 2.0~),
ruby-truncato, ruby-nokogiri (>= 1.6.7.2~), ruby-diffy (>= 3.0.3~), unicorn (>=
5.1~), ruby-unicorn-worker-killer (>= 0.4.4~), ruby-state-machines-activerecord
(>= 0.4.0~), ruby-after-commit-queue, ruby-acts-as-taggable-on (>= 4.0~),
ruby-sinatra (>= 1.
Re: Bug#847044: allow gitlab 8.13.6+dfsg2-1 to migrate testing
On വെള്ളി 09 ഡിസംബര് 2016 01:45 വൈകു, Emilio Pozuelo Monfort wrote: > The hint was there, it's just that since this is a new kind of hint, it hadn't > been enabled in the configuration and so britney was ignoring it. > > I have fixed that now and urgented gitlab so it doesn't have to wait until it > is > 10 days old. With those two hints, it should migrate to testing in a couple of > hours. Do I have to request unblock for every upload? Because the last upload (8.13.6+dfsg2-2) is also rejected by piuparts. signature.asc Description: OpenPGP digital signature
Bug#847827: unblock: ruby-jquery-ui-rails/6.0.1-1
On Mon, 12 Dec 2016 11:45:36 +0530 Pirate Praveen wrote: > Please unblock package ruby-jquery-ui-rails 6.0.1-1 was FTBFS (#847808), this is now fixed. signature.asc Description: OpenPGP digital signature
