Re: RFS: ruby-xmlparser 0.7.3-5

[Utkarsh Gupta]

Hey,

On Thu, Aug 15, 2024 at 10:57 AM Piper McCorkle  wrote:
> I would appreciate a sponsor for ruby-xmlparser 0.7.3-5. I fixed
> the FTBFS in [#1075483]. The source package is available on
> [mentors]. You can find a diff of the changes I made on [Salsa].

Thank you, I've sponsored the upload. :)


- u

Re: RFS: ruby-capybara 3.40.0+ds-1

[Utkarsh Gupta]

Hi Leandro,

On Wed, Jun 5, 2024 at 10:00 AM Leandro Cunha  wrote:
> The package has a release critical bug with FTBFS requiring an urgent
> upload, it has no recent upload history (since 2021), it is not
> compatible with version 3.1/3.2 of Ruby (so much so that we have an rc
> bug because fails to compile from source with current version present
> in sid and testing) and I also resolved a double build bug.
>
> Could you sponsor them?

Thank you for your work. I've sponsored the upload. One quick
suggestion is to not do the debian/ tag (often done with `gbp tag`) -
it should be done by the uploader at the upload time. Otherwise,
everything looks great, thank you!


- u

Re: Debian Ruby sprint - Paris February 2023?

[Utkarsh Gupta]

Hi Cédric,

On Sun, Dec 4, 2022 at 3:52 PM Cédric Boutillier  wrote:
> I would like to know if you are interested in joining a Ruby Sprint
> either the week before (January 30 - Feb 3) or after (Feb 6 - Feb 10).
> It would take place in the center of Paris, in the campus of Sorbonne
> Université (same place as last sprint in 2020).

Thanks for organizing this again. \o/

Due to visa complications on my end, I might be _only_ able to join
the sprints after FOSDEM. I've added the same in the poll but
mentioning here for posterity. :)


- u

Re: RFS: ruby-version-gem 1.1.0

[Utkarsh Gupta]

Hey,

On Thu, Sep 22, 2022 at 1:32 PM Ajayi Olatunji O
 wrote:
> Thank you very much.
> But I seem not to find the right homepage after hours of searching,
> kindly point it to me if you don't mind.

The very link you mentioned redirects to another project which has the
very first set of words:
"Ruby OAuth's version_gem has moved to GitLab
Please update references: https://gitlab.com/oauth-xx/version_gem";


- u

Re: RFS: ruby-version-gem 1.1.0

[Utkarsh Gupta]

Hey,

On Wed, Sep 21, 2022 at 9:25 PM Ajayi Olatunji O
 wrote:
> In order to update git lab to version 15.3.0, ruby-oauth2 must be
> updated from version 1.4.4 to version 2.0, and ruby-oauth requires a
> ruby gem version-gem, but because of the absence of version-gem in the
> Debian archive I had to package it for the ruby team.
>
> It is currently at version 1.1.0 and the packaged gem exists at
> https://salsa.debian.org/ruby-team/projects/ruby-version-gem.
>
> Kindly help sponsor it, it is lintian clean.
>
> In case there are any corrections, I am eager to implement them.

The upstream homepage is incorrect. The project has moved to GitLab.
The packaging doesn't include tests as-is in the upstream source.
Could you please pull the source from there and include them? TIA.


- u

Re: [RFS] -- redmine

[Utkarsh Gupta]

Hellu,

On Tue, Sep 13, 2022 at 3:52 PM Utkarsh Gupta
 wrote:
> FWIW, I'll take care of this RFS. I am waiting for rails to settle and
> then take a look at redmine.

I've done a bunch of more stuff in the package and fixed a bunch of
things. Uploaded v5.0.2-2, which will shortly be in testing now! \o/


- u

Re: RFS: ruby-rack-oauth2 1.21.2

[Utkarsh Gupta]

On Tue, Sep 13, 2022 at 11:10 PM Ravi  wrote:
> >  Ravi: can you also take a look at ruby-json-jwt?
> >  ruby-rack-oauth2 is never gonna migrate unless
> > ruby-json-jwt migrates. So before we upload that, I want to make sure
> > that -json-jwt is through.
>
> There is a rc bug in ruby-json-jwt package, right? Was it fixed in the
> new upstream version?

Precisely what I am asking you to do. :)


- u

Re: Redmine ActionView::Template::Error after recent Rails security update

[Utkarsh Gupta]

Hi Sven,

On Tue, Sep 13, 2022 at 12:50 PM Sven Eckelmann  wrote:
>
> On Monday, 12 September 2022 18:54:36 CEST Utkarsh Gupta wrote:
> > I have fixed the regression and uploaded the binaries here:
> > https://people.debian.org/~utkarsh/lts/rails/
>
> Thanks.
>
> > Could either (or both!) of you test this and let me know if this fixes
> > the regression for you?
>
> I have tried them out and at least on first glance, it seems to work
> fine.

Thank you for letting us know. In case you run into any issues, let me know.


- u

Re: [RFS] -- redmine

[Utkarsh Gupta]

Hey,

FWIW, I'll take care of this RFS. I am waiting for rails to settle and
then take a look at redmine.


- u

Re: RFS: ruby-rack-oauth2 1.21.2

[Utkarsh Gupta]

Hiya,

On Mon, Sep 5, 2022 at 6:48 PM Ravi  wrote:
> The following packages are ready to be uploaded (I also verified the
> points listed on
> http://wiki.debian.org/Teams/Ruby/Packaging#Requesting_Sponsorship).

>From IRC:

 Ravi: can you also take a look at ruby-json-jwt?
 ruby-rack-oauth2 is never gonna migrate unless
ruby-json-jwt migrates. So before we upload that, I want to make sure
that -json-jwt is through.


- u

Re: Redmine ActionView::Template::Error after recent Rails security update

[Utkarsh Gupta]

Hi Jude and Sven,

On Tue, Sep 6, 2022 at 10:00 AM Jude Hungerford
 wrote:
> Since then, loading any of our Redmine pages returns the following error:
> """
> Internal error
> An error occurred on the page you were trying to access.
> If you continue to experience problems please contact your Redmine 
> administrator for assistance.
>
> If you are the Redmine administrator, check your log files for details about 
> the error.
> """
>
> Looking in /var/log/redmine/default/production.log, I see the following error 
> message:
>
> """
> Started GET "/redmine/" for 203.221.207.132 at 2022-09-06 10:27:56 +1000
> Processing by WelcomeController#index as HTML
>   Current user: jude (id=4)
>   Rendering welcome/index.html.erb within layouts/base
>   Rendered welcome/index.html.erb within layouts/base (3.5ms)
> Completed 500 Internal Server Error in 19ms (ActiveRecord: 4.9ms)
>
> ActionView::Template::Error (unknown keywords: permitted_classes, aliases):
> 11: <%= favicon %>
> 12: <%= stylesheet_link_tag 'jquery/jquery-ui-1.11.0', 'application', 
> 'responsive', :media => 'all' %>
> 13: <%= stylesheet_link_tag 'rtl', :media => 'all' if l(:direction) == 
> 'rtl' %>
> 14: <%= javascript_heads %>
> 15: <%= heads_for_theme %>
> 16: <%= call_hook :view_layouts_base_html_head %>
> 17: 

I have fixed the regression and uploaded the binaries here:
https://people.debian.org/~utkarsh/lts/rails/

Could either (or both!) of you test this and let me know if this fixes
the regression for you?


- u

Re: RFS: ruby-gpgme 2.0.20-1

[Utkarsh Gupta]

Hey,

On Sun, Aug 14, 2022 at 6:35 AM 'Tunji  wrote:
> Hello, I made recommended changes to this package and it is now Lintian
> clean.

It still lacks the reason. :)


- u

RFS emails missing the actual intent of the request

[Utkarsh Gupta]

Hey,

Thanks for all your work in the past weeks but all (or at least most)
of your emails are missing an important aspect of the RFS mail: the
main intent behind the work. For instance, you say package X is
updated and is lintian clean so here's an RFS, but WHY was this
package X updated in the first place is something that's missing in
your emails. I really suggest adding them as it's very important.

We don't generally update libraries just because there's a new version
available so having that reason behind your RFS mail would actually
help in understanding the ultimate goal of updating the package.

Let me know if you have any questions or concerns.


- u

Re: Subject: RFS: rails

[Utkarsh Gupta]

Hey,

On Wed, Aug 24, 2022 at 1:06 AM Gabriela Pivetta  wrote:
> I've pushed the changes to its salsa repo:
> https://salsa.debian.org/ruby-team/rails
>
> Please consider to review and upload it.

Thank you, uploaded! \o/


- u

Re: Subject: RFS: ruby-selenium-webdriver

[Utkarsh Gupta]

Hey,

On Wed, Aug 24, 2022 at 1:00 AM Gabriela Pivetta  wrote:
> I've pushed the changes to its salsa repo:
> https://salsa.debian.org/ruby-team/ruby-selenium-webdriver
>
> Please consider to review and upload it.

Uploaded, thanks for your help! \o/


- u

Re: RFC: dropping Ruby-Versions fields

[Utkarsh Gupta]

Hey,

On Sat, Aug 20, 2022 at 10:16 PM Antonio Terceiro  wrote:
> Given that 1) we don't really support packages not working with all
> available Ruby versions, 2) multiple ruby versions are only present
> simultaneously during transitions, and 3) we only release with a single
> version, I propose that we drop these entirely, and always build and
> test for all supported Ruby versions. We would then consider packages
> that don't work with all versions to be buggy.

That makes sense. +1 in dropping them. A simple grep shows 1540
packages use the former and 1533 use the latter. A mass commit without
breaking Salsa would be super. I can arrange that. :)


- u

Re: Request to join the team

[Utkarsh Gupta]

Hi Jérôme,

On Mon, Jun 20, 2022 at 4:02 AM Jérôme Charaoui  wrote:
> I would like to request to join the Debian Ruby team. I've submitted the
> request on GitLab.

Granted access, welcome, good sir. :)

> I have prepared an update to the Hiera package, and I also would like to
> help out getting jruby back into shape so we have have puppetserver in
> bookworm.

Awesome. Should you need any help or have questions, please don't
hesitate to reach out here.


- u

Re: Request to join ruby salsa team

[Utkarsh Gupta]

Hi Rajesh,

On Wed, Jun 8, 2022 at 9:21 PM Rajesh Simandalahi
 wrote:
> I'm new to debian and the ruby team and already made some merge
> requests on the salsa repos for ruby-image-processing (CVE patch),
> asciidoctor, and asciiart (upstream imports and patch updates).

Thank you. I've merged in the CVE patch for ruby-image-processing and
uploaded after some minor cleanup.

> Can someone please add me to the ruby team on salsa? And can
> these merge requests be approved and uploaded?

Added to the team, welcome. Should you have any questions, please
don't hesitate to reach out here.

I've uploaded one of the packages as mentioned above. Hopefully,
someone will have time to TAL at the other two. Otherwise, I'll TAL
whenever time allows. TIA.


- u

Re: Proposing to replace ruby-uglifier with ruby-terser and remove ruby-uglifier

[Utkarsh Gupta]

Hi Praveen,

On Wed, Jun 1, 2022 at 1:08 PM Pirate Praveen  wrote:
> We have a long standing rc bug (we have not updated to
> latest upstream for long)
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981224#10
>
> Also it caused autopkgtest regression for node-source-map update
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-uglifier/22232351/log.gz
>
> terser is better maintained fork of uglify-js and ruby-terser its
> gem equivalent.
>
> Anyone wants to keep maintaining ruby-uglifier ?

$ reverse-depends src:ruby-uglifier
Reverse-Recommends
* nanoc (for ruby-uglifier)

Reverse-Depends
* diaspora  (for ruby-uglifier)
* gitlab(for ruby-uglifier)
* obs-api   (for ruby-uglifier)
* rails (for ruby-uglifier)

Packages without architectures listed are reverse-dependencies in:
all, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el,
s390x

$ reverse-depends -b src:ruby-uglifier
Reverse-Build-Depends
* nanoc (for ruby-uglifier)
* open-build-service(for ruby-uglifier)
* rails (for ruby-uglifier)
* ruby-sprockets(for ruby-uglifier)
* ruby-sprockets-rails  (for ruby-uglifier)


As long as nothing breaks here and the transition from ruby-uglifier
to ruby-terser is smooth, it's all good. Whilst at it, you might also
want to open respective upstream issues so that we don't carry this
delta forever.


- u

Re: Ruby team BoF at DebConf 22

[Utkarsh Gupta]

Hello,

On Mon, Apr 11, 2022 at 8:52 PM Lucas Kanashiro  wrote:
> Should we submit our regular BoF to DebConf this year? Are people
> planning to attend in-person? Are there people willing to attend remotely?

I think we should, indeed. I plan to attend and can be co-speaker if need be.


- u

Re: RFC: Revoke membership for janitor bot

[Utkarsh Gupta]

Hi Daniel,

On Sat, Oct 2, 2021 at 8:43 PM Daniel Leidert  wrote:
> I have just been pointed to the folowing documents:
>
http://janitor.debian.net/lintian-fixes/#how-do-i-prevent-the-janitor-from-making-certain-changes
>
https://manpages.debian.org/testing/lintian-brush/lintian-brush.conf.5.en.html

I was about to mention this. You can add the following in
your debian/lintian-brush.conf:
  compat-release = oldstable
like debian-archive-keyring does. And you're good to go then.


- u

Re: RFS: ruby-hkdf 1.0.0 , ruby-slowpoke 0.3.2 , ruby-scarf 0.2.6

[Utkarsh Gupta]

Hiya,

On Tue, Sep 28, 2021 at 6:42 PM Pirate Praveen
 wrote:
> As discussed on matrix [...]

Wherever the conversation is happening, if it's not GitLab
related, moving it to #debian-ruby would be good, I guess.


- u

Ruby Team BoF; Thursday, 26th Aug, 14:00 - 14:45 UTC

[Utkarsh Gupta]

Hello,

We have our BoF scheduled on Thursday, 26th August, from 14:00 - 14:45
UTC. I look forward to seeing everybody there. Please let me (or
Kanashiro) know who all would like to join the Jitsi session and we'd
be happy to share the Jitsi meeting link.


- u

Bug#989037: unblock: rails/2:6.0.3.7+dfsg-1

[Utkarsh Gupta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-ruby@lists.debian.org

Hello,

Rails was recently affected by 3 CVEs (CVE-2021-2290{2,4} and CVE-2021-22885).

I'm attaching a filtered diff for your review; the diff is really
small and minimal which should be clear by looking at it. The only
caveat is that it needs ruby-marcel, which has an unblock request
(#989036) opened a few minutes ago.

rails has been in unstable for around 9 days now[1]; I've done some
testing and it all works OK w/ Bullseye, so it should be good to go.
[1]: https://tracker.debian.org/pkg/rails

The command used to filter the debdiff is as follows:
filterdiff --exclude='*/Gemfile.lock' --exclude='*/CHANGELOG.md'
--exclude='*/gem_version.rb' --exclude='*/package.json'
--exclude='*/test/*' ../rails.debdiff

Let me know if you need any other information from my end. Thanks!

- u


rails_filtered.debdiff
Description: Binary data

Bug#989036: unblock: ruby-marcel/1.0.1+dfsg-2

[Utkarsh Gupta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-ruby@lists.debian.org

Hello,

We had to bump ruby-marcel to a newer version because the mimemagic
dependency - which relies on GPL-licensed mime type data from
freedesktop.org’s shared-mime-info project - is removed. Marcel now
directly uses mime type data adapted from the Apache Tika project,
distributed under the Apache License. This is the only major change
here + some other bug fixes to get everything working.

ruby-marcel has been in unstable for around 9 days now[1]; I've done
some testing and it all works OK w/ Bullseye, so it should be good to
go.
[1]: https://tracker.debian.org/pkg/ruby-marcel

Since this is licensing + bug fix, I believe it'd be a good idea to
have this included in Bullseye; this is also needed for rails to be
unblocked (another separate request).

Attaching a filtered debdiff for your review. The command used to
filter the debdiff is as follows:
filterdiff --exclude='*/APACHE-LICENSE' --exclude='*/.*'
--exclude='*/data/*' --exclude='*/script/*' --exclude='*/test/*'
--exclude='*/Gemfile.lock' --exclude='*/README.md'
../ruby-marcel.debdiff

Let me know if you need any other information from my end. Thanks!


- u


ruby-marcel_filtered.debdiff
Description: Binary data

Re: CVE-2021-28965

[Utkarsh Gupta]

Hi Praveen,

On Fri, Apr 16, 2021 at 3:24 PM Pirate Praveen  wrote:
> I think the separate package was introduced by mistake without seeing
> the copy embedded in ruby. I think the right way is to fix this in ruby
> and remove this separate package. But I'd like someone from ruby team
> to confirm this.

Makes sense. Probably the time to RM ruby-rexml from the archive is *now*?

As for fixing this in src:ruby2.7, see #986742. TL;DR: ruby2.7 2.7.3-1
was uploaded to fix this earlier today.


- u

Re: Bug#986742: unblock: ruby2.7/2.7.3-1

[Utkarsh Gupta]

Hi Sebastian,

On Sat, Apr 17, 2021 at 3:08 PM Sebastian Ramacher  wrote:
> Thanks, please go ahead and remove the moreinfo tag once the version is
> available in unstable.

Uploaded to unstable, thanks. And removed the tag as well.


- u

Re: ruby-vcr: DFSG violation (Hippocratic license)

[Utkarsh Gupta]

On Sun, Mar 7, 2021 at 10:49 PM Utkarsh Gupta  wrote:
> 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
> package or something, would forking be an option?

It looks like they just upgraded to the latest version of the license
they were previously using; cf: https://github.com/vcr/vcr/pull/813. I
didn't read the license but is it realy a problem? If it is, I know
Olle (the upstream dev), maybe we can talk this out and they can
revert to the previous version of the license.


- u

Re: ruby-vcr: DFSG violation (Hippocratic license)

[Utkarsh Gupta]

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
package or something, would forking be an option?


- u

Bug#983113: buster-pu: package ruby-mechanize/2.7.6-1+deb10u1

[Utkarsh Gupta]

Package: release.debian.org
User: release.debian@packages.debian.org
X-Debbugs-Cc: debian-ruby@lists.debian.org
Usertags: pu
Tags: buster
Severity: normal

Hello,

ruby-mechanize was affected by CVE-2021-21289, where the package was
vulnerable to command injection vulnerability.

This has been fixed in sid, bullseye, and stretch.
Here's the debdiff for buster-pu:

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

diff -Nru ruby-mechanize-2.7.6/debian/changelog
ruby-mechanize-2.7.6/debian/changelog
--- ruby-mechanize-2.7.6/debian/changelog2019-01-04 16:57:45.0 +0530
+++ ruby-mechanize-2.7.6/debian/changelog2021-02-19 22:47:27.0 +0530
@@ -1,3 +1,10 @@
+ruby-mechanize (2.7.6-1+deb10u1) buster; urgency=medium
+
+  * Team upload for buster-pu.
+  * Add patch to prevent OS command injection. (Fixes: CVE-2021-21289)
+
+ -- Utkarsh Gupta   Fri, 19 Feb 2021 22:47:27 +0530
+
 ruby-mechanize (2.7.6-1) unstable; urgency=medium

   * Team upload
diff -Nru ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
--- ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
1970-01-01 05:30:00.0 +0530
+++ ruby-mechanize-2.7.6/debian/patches/CVE-2021-21289.patch
2021-02-19 22:46:52.0 +0530
@@ -0,0 +1,260 @@
+From aae0b13514a1a0caf93b1cf233733c50e679069a Mon Sep 17 00:00:00 2001
+From: Katsuhiko YOSHIDA 
+Date: Sat, 20 Jul 2019 11:03:40 +0900
+Subject: [PATCH 1/7] fix(security): prevent command injection in CookieJar
+
+Related to 
https://github.com/sparklemotion/mechanize/security/advisories/GHSA-qrqm-fpv6-6r8g
+---
+ lib/mechanize/cookie_jar.rb   |  4 ++--
+ test/test_mechanize_cookie_jar.rb | 30 ++
+ 2 files changed, 32 insertions(+), 2 deletions(-)
+
+--- a/lib/mechanize/cookie_jar.rb
 b/lib/mechanize/cookie_jar.rb
+@@ -65,7 +65,7 @@
+   class CookieJar < ::HTTP::CookieJar
+ def save(output, *options)
+   output.respond_to?(:write) or
+-return open(output, 'w') { |io| save(io, *options) }
++return ::File.open(output, 'w') { |io| save(io, *options) }
+
+   opthash = {
+ :format => :yaml,
+@@ -119,7 +119,7 @@
+
+ def load(input, *options)
+   input.respond_to?(:write) or
+-return open(input, 'r') { |io| load(io, *options) }
++return ::File.open(input, 'r') { |io| load(io, *options) }
+
+   opthash = {
+ :format => :yaml,
+--- a/test/test_mechanize_cookie_jar.rb
 b/test/test_mechanize_cookie_jar.rb
+@@ -1,4 +1,5 @@
+ require 'mechanize/test_case'
++require 'fileutils'
+
+ class TestMechanizeCookieJar < Mechanize::TestCase
+
+@@ -500,6 +501,35 @@
+ assert_equal(0, @jar.cookies(url).length)
+   end
+
++  def test_prevent_command_injection_when_saving
++url = URI 'http://rubygems.org/'
++path = '| ruby -rfileutils -e \'FileUtils.touch("vul.txt")\''
++
++@jar.add(url, Mechanize::Cookie.new(cookie_values))
++
++in_tmpdir do
++  @jar.save_as(path, :cookiestxt)
++  assert_equal(false, File.exist?('vul.txt'))
++end
++  end
++
++  def test_prevent_command_injection_when_loading
++url = URI 'http://rubygems.org/'
++path = '| ruby -rfileutils -e \'FileUtils.touch("vul.txt")\''
++
++@jar.add(url, Mechanize::Cookie.new(cookie_values))
++
++in_tmpdir do
++  @jar.save_as("cookies.txt", :cookiestxt)
++  @jar.clear!
++
++  assert_raises Errno::ENOENT do
++@jar.load(path, :cookiestxt)
++  end
++  assert_equal(false, File.exist?('vul.txt'))
++end
++  end
++
+   def test_save_and_read_expired_cookies
+ url = URI 'http://rubyforge.org/'
+
+--- a/lib/mechanize.rb
 b/lib/mechanize.rb
+@@ -396,7 +396,7 @@
+ io = if io_or_filename.respond_to? :write then
+io_or_filename
+  else
+-   open io_or_filename, 'wb'
++   ::File.open(io_or_filename, 'wb')
+  end
+
+ case page
+--- a/test/test_mechanize.rb
 b/test/test_mechanize.rb
+@@ -345,6 +345,14 @@
+ end
+   end
+
++  def test_download_does_not_allow_command_injection
++in_tmpdir do
++  @mech.download('http://example', '| ruby -rfileutils -e
\'FileUtils.touch("vul.txt")\'')
++
++  refute_operator(File, :exist?, "vul.txt")
++end
++  end
++
+   def test_get
+ uri = URI 'http://localhost'
+
+--- a/lib/mechanize/download.rb
 b/lib/mechanize/download.rb
+@@ -71,7 +71,7 @@
+ dirname = File.dirname filename
+ FileUtils.mkdir_p dirname
+
+-open filename, 'wb' do |io|
++::File.open(filename, 'wb')do |io|
+   until @body_io.eof? do
+ io.write @body_io.

Re: ruby-cmdparse 3.0.7

[Utkarsh Gupta]

Hi Klaumi,

On Sat, Jan 30, 2021 at 11:31 PM Klaumi Klingsporn  wrote:
> So I think the package is ready for upload, BUT
> the autopkgtest-self initiated by the build-script fails,
> because it's unable to fetch and install an old and
> outdated version of apt-utils: 2.1.11. The
> autopkgtest-self log is attached.
>
> I have no idea how to fix this!
>
> Any ideas?

I am not sure what's wrong, really. Maybe try doing a --fix-missing
and update && upgrade manually from inside the chroot?

Anyway, everything builds fine here and the autopkgtest is passing
(superficially) as well and so I've sponsored your upload! :)

Just BTW, this is how I build the package:
``` sbuild -s --source-only-changes ```

and this is how I run autopkgtest:
``` autopkgtest -B ../*.deb  -- schroot unstable-amd64-sbuild ```



- u

Re: Building ruby 2.7.2 for buster-fasttrack and bundler fails

[Utkarsh Gupta]

Hi Praveen,

On Thu, Feb 4, 2021 at 1:57 AM Pirate Praveen  wrote:
> I have ruby 2.7.1 currently in buster-fasttrack (fasttrack.debian.net)
> and I'm trying to update it to 2.7.2
>
> The build went fine, but bundler (2.1.4-2~bpo10+1) seems broken now. Do
> I need to update bundler as well for this to work?

Try to apply this commit[1]. Should likely fix your problem.

[1]: 
https://salsa.debian.org/ruby-team/rubygems-integration/-/commit/39d3a082f568ec0b6c9acd10e54a4a31a08bd8b5


- u

Re: Packaging-Workflow paper

[Utkarsh Gupta]

Hi Klaumi,

On Sun, Nov 29, 2020 at 1:24 AM Klaumi Klingsporn  wrote:
> O.K.,  if you think it will serve us both and my
> obligations will be limited to the few packages I want to
> maintain, so make me a team member.

Great, I've given you access to the Ruby team's namespace. Welcome aboard! \o/

> Or do I need to do something special to become one? Maybe
> booking some cabin at the Ruby Lake Resort
> (https://www.rubylakeresort.com/) and swimming in the Ruby
> Lake
> (https://www.openstreetmap.org/#map=13/49.7196/-124.0141)
> at sunset?

Nah, just a glass of beer to each Ruby team member in the next
conference (plausibly some DebConf) should suffice ;)


- u

Re: ruby-team.pages.debian.net | added my workflow-paper as CONTRIBUTING page (!1)

[Utkarsh Gupta]

Hey,

On Sat, Nov 28, 2020 at 7:35 AM Daniel Leidert  wrote:
>
> JFTR: The minima theme doesn't know sub-pages or collections by default. 
> We'll have to create something ourselves.

Perhaps we can post this in "parts". Like you did the daily reports
for the sprints. So something similar.
Part 1, Part 2, ... and so on.


- u

Re: ruby-team.pages.debian.net | added my workflow-paper as CONTRIBUTING page (!1)

[Utkarsh Gupta]

Hi Klaumi,

On Fri, Nov 27, 2020 at 5:20 AM Klaumi Klingsporn  wrote:
> should be no problem to split up the text after the
> introduction ("...let's get started!") into 6 separate
> pages at every second level header and to put a table of
> content link-set at the end of the introduction page.
>
> But it depends on how you as team want to have your site
> look like and be organized. So it's not my decision to make.

Why not? :)
You're a contributor, which makes you one of us.

If you think breaking into two or three or six parts would make it
more appealing and fun, then so be it. It's your precious contribution
and I think you should definitely have a say on this! Whenever you're
ready, let us know, we'll be happy to merge this and let it go live!
\o/


- u

Re: ruby-cmdparse

[Utkarsh Gupta]

Hi Klaumi,

On Sat, Nov 14, 2020 at 7:18 PM Klaumi Klingsporn  wrote:
> And again thanks for your help. I made a cheat sheet for
> the workflow and all the tips after all. So hopefully next
> time it will become easier ;-)

That's great! Do you think you can put together this thing in a
markdown style so we can put it on the Ruby Team Pages[1]?

[1]: https://ruby-team.pages.debian.net/


- u

[Reminder] Ruby team meeting today (06-11-2020) at 1630 UTC

[Utkarsh Gupta]

Hi,

We have a Ruby team meeting today, 06th November at 1630 UTC.
This will be held on Jitsi again since it worked out pretty nice last time! :)

Please put the topics that you want to discuss here:
https://wiki.debian.org/Teams/Ruby/IRCMeetings


- u

Bug#972161: buster-pu: package ruby2.5/2.5.5-3+deb10u3

[Utkarsh Gupta]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
X-Debbugs-CC: debian-ruby@lists.debian.org
Severity: normal

Hello,

ruby2.5 was affected by CVE-2020-25613, where WEBrick, a simple HTTP
server bundled with Ruby, had not checked the transfer-encoding header
value rigorously.

This has been fixed in Sid, Bullseye, and Stretch.
Here's the debdiff for buster-pu:

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

diff -Nru ruby2.5-2.5.5/debian/changelog ruby2.5-2.5.5/debian/changelog
--- ruby2.5-2.5.5/debian/changelog2020-07-04 00:07:58.0 +0530
+++ ruby2.5-2.5.5/debian/changelog2020-10-13 18:32:32.0 +0530
@@ -1,3 +1,10 @@
+ruby2.5 (2.5.5-3+deb10u3) buster; urgency=high
+
+  * Add patch to fix a potential HTTP request smuggling
+vulnerability in WEBrick. (Fixes: CVE-2020-25613)
+
+ -- Utkarsh Gupta   Tue, 13 Oct 2020 18:32:32 +0530
+
 ruby2.5 (2.5.5-3+deb10u2) buster-security; urgency=high

   * Non-maintainer upload by the Security Team.
diff -Nru ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch
ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch
--- ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch1970-01-01
05:30:00.0 +0530
+++ ruby2.5-2.5.5/debian/patches/CVE-2020-25613.patch2020-10-13
18:31:51.0 +0530
@@ -0,0 +1,30 @@
+From 8946bb38b4d87549f0d99ed73c62c41933f97cc7 Mon Sep 17 00:00:00 2001
+From: Yusuke Endoh 
+Date: Tue, 29 Sep 2020 13:15:58 +0900
+Subject: [PATCH] Make it more strict to interpret some headers
+
+Some regexps were too tolerant.
+
+--- a/lib/webrick/httprequest.rb
 b/lib/webrick/httprequest.rb
+@@ -226,9 +226,9 @@
+ raise HTTPStatus::BadRequest, "bad URI `#{@unparsed_uri}'."
+   end
+
+-  if /close/io =~ self["connection"]
++  if /\Aclose\z/io =~ self["connection"]
+ @keep_alive = false
+-  elsif /keep-alive/io =~ self["connection"]
++  elsif /\Akeep-alive\z/io =~ self["connection"]
+ @keep_alive = true
+   elsif @http_version < "1.1"
+ @keep_alive = false
+@@ -475,7 +475,7 @@
+   return unless socket
+   if tc = self['transfer-encoding']
+ case tc
+-when /chunked/io then read_chunked(socket, block)
++when /\Achunked\z/io then read_chunked(socket, block)
+ else raise HTTPStatus::NotImplemented, "Transfer-Encoding: #{tc}."
+ end
+   elsif self['content-length'] || @remaining_size
diff -Nru ruby2.5-2.5.5/debian/patches/series
ruby2.5-2.5.5/debian/patches/series
--- ruby2.5-2.5.5/debian/patches/series2020-07-04 00:06:34.0 +0530
+++ ruby2.5-2.5.5/debian/patches/series2020-10-13 18:32:04.0 +0530
@@ -15,3 +15,4 @@
 0015-lib-shell-command-processor.rb-Shell-prevent-unknown.patch
 CVE-2020-10933.patch
 CVE-2020-10663.patch
+CVE-2020-25613.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

- u
---

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[Reminder] Ruby team meeting tomorrow (02-10-2020) at 1630 UTC

[Utkarsh Gupta]

Hi,

We have a Ruby team meeting tomorrow, 02nd October at 1630 UTC.
This will be held on Jitsi again since it worked out pretty nice last time! :)

Please put the topics that you want to discuss here:
https://wiki.debian.org/Teams/Ruby/IRCMeetings


- u

Re: RFS: ruby-js-regex 3.4.0-1

[Utkarsh Gupta]

Hiya,

On Thu, Aug 27, 2020 at 6:31 PM Pirate Praveen  wrote:
> We don't need to package every development dependency, only those required 
> for functional tests need to be packaged. So mutant-rspec may be used in 
> tests, codecov could be ignored. But currently tests are not enabled. You can 
> try to include tests by switching to github tarballs in watch file and then 
> enable tests.

I took a quick look at it and it seems that mutant-rspec needs mutant
and rspec-core. And then mutant furthermore needs a bunch of other
packages and so on.
I think it's best to not take this route here and leave the tests
disabled. I don't think it's worth packaging so many things just to
enable tests.

Please let me know if you have unlike opinion on this.


- u

[Reminder] Ruby team meeting tomorrow (04-09-2020) at 1630 UTC

[Utkarsh Gupta]

Hi,

We have a Ruby team meeting tomorrow, 04th September at 1630 UTC.
This will *not* be *yet another* meeting, we'll try to be more
interactive, perhaps a Jitsi call (with, of course, discussions on IRC
as well for those don't want to join, etc).

Please put the topics that you want to discuss here:
https://wiki.debian.org/Teams/Ruby/IRCMeetings


- u

Re: Ruby Team BoF in DC20?

[Utkarsh Gupta]

Hi all,

On Fri, Aug 14, 2020 at 4:58 PM Utkarsh Gupta  wrote:
> We have our BoF on August 25th, 1600 to 1645 UTC.

Just a reminder that this is happening really soon, in about 70 minutes.


Best,
Utkarsh

Re: Ruby Team BoF in DC20?

[Utkarsh Gupta]

Hi all,

On Sat, Aug 22, 2020 at 11:23 PM Lucas Kanashiro  wrote:
> Thanks for setting up this gobby document Utkarsh! I added some extra
> notes there but the agenda looks good.

Great, thanks!

More importantly, in case someone's willing to join the BoF (& speak
or interact), please contact me or Kanashiro off-list so that we can
send you the Jitsi link.

Otherwise, the BoF will be streamed live, available for everyone to attend! :)


Best,
Utkarsh

Re: RFS: ruby-rspec-parameterized

[Utkarsh Gupta]

Hi Cocoa,

On Fri, Aug 21, 2020 at 1:27 PM Cocoa  wrote:
> Could you please sponsor them?

Wow, very nicely done! Uploaded, thanks!


Best,
Utkarsh

Re: RFS: ruby-proc-to-ast

[Utkarsh Gupta]

Hi Cocoa,

On Fri, Aug 21, 2020 at 12:45 PM Cocoa  wrote:
> The tests for ruby-proc-to-ast were disabled because ruby-proc-to-ast as the 
> following examples were
> failing in the upstream version.
> rspec ./spec/proc_to_ast_spec.rb:78 # Proc#to_ast proc variation inner array
> rspec ./spec/proc_to_ast_spec.rb:145 # Proc#to_source return source code 
> string

Generally, we don't disable tests if it fails for an actual reason. We
try to fix them first.
Here, unfortunately, the upstream is dead and this is ~5 years old
(w/o update). But fortunately, it was a minor change in the syntax as
to how proc and lambda are used.

I've fixed these failing tests and re-enabled them all now.

> Could you please sponsor them?

Done, thank you! \o/


Best,
Utkarsh

Re: RFS: ruby-path-expander 1.1.0-1, ruby-morpher 0.2.6-1, ruby-anima 0.3.1-1, ruby-unparser 0.4.7-1

[Utkarsh Gupta]

Hi Cocoa,

On Sun, Aug 16, 2020 at 7:51 PM Cocoa  wrote:
> The tests for ruby-unparser were disabled because ruby-devtools is currently 
> not packaged
> for Debian, and to do so would require packaging around 7 more packages.

That's the right thing to do. Whilst we do want to run tests but
definitely not at the sake of packaging 7 more dependencies!

>  ruby-path-expander 1.1.0-1

Uploaded!

>  ruby-morpher 0.2.6-1

Uploaded!

>  ruby-anima 0.3.1-1

Uploaded!

>  ruby-unparser 0.4.7-1

Uploaded!


I must admit that these are of excellent quality. I didn't have to
change anything here!
Great work, really! \o/


Best,
Utkarsh

Re: Ruby Team BoF in DC20?

[Utkarsh Gupta]

Hello all,

On Thu, Jun 18, 2020 at 9:52 PM Utkarsh Gupta  wrote:
> Perfect, I have submitted the talk with the note mentioning the
> preferred time and day (Friday).

We have our BoF on August 25th, 1600 to 1645 UTC.

For the preparations, I have created a gobby document (named "ruby",
under debconf20/bof/).
I wrote some points to get things going and pasting the same here..

Please add more points to the gobby doc. Or you can mention them here,
someone will paste to the gobby doc.

==


Ruby Team BoF - DebConf20
=

Tuesday, August 25th at 16:00-16:45 UTC

Link to Jitsi Room TBD, but it will be available on:
https://debconf20.debconf.org/talks/17-ruby-team-bof/

0. Agenda
=

1. Welcome to this BoF! \o/
2. What all happened since the last BoF?
3. The "good" & "bad" Parts of ruby2.7 Transition.
   (& what can we learn from them!?)
4. Rails 6 Transition
   (what's the state, what should we do!?)
5. What we want to achieve for the next release?
   (ruby3.0 for bullseye or bookworm?)
6. Possible sprints in 2020/21.
   (where - any takers? :))
7. Any other business?


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


1. Welcome to this BoF! \o/
===

Thank you for dropping by, we're glad that you could make it.
Please introduce yourself briefly by telling us:

  * What's your name & nick?
  * What do you do in Debian & Ruby team?


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


2. What all happened since the last BoF?


-> A lot of stuff!
-> TODO: mention the important stuff here.


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


3. The "good" & "bad" Parts of ruby2.7 Transition
=

-> I'd like to believe that sprints for ruby2.7 transition
   was really good! And that we should do it again!

-> IMO, 5-day sprint was a good idea, it gave us ample
   amount of time to discuss and fix the key stuff.
   Anything lesser than that would have been very rush-y.
   So I liked the idea of 5-day sprints.

-> TODO: add more..


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


4. Rails 6 Transition
=

-> A big thanks to Praveen for doing almost all the work
   so incredibly well! This was nicely done!

-> TODO: add status and other things.


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


5. What we want to achieve for the next release?


-> ruby3.0 is going to be the next release.
-> Going to be rolled out this December.
-> -preview or -rc release will be out soon-ish.
-> Do we want to "try" it for bullseye?
   * Pros:
 -> ruby3.0 has a lot of amazing features.
 -> and it'd be nice for bullseye to have them.
   * Cons:
 -> given our release cycle, it might get chaotic.
 -> we might not have enough time to get it done (or can we?)

-> TODO: add more..


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


6. Possible sprints in 2020/21
==


-> A sprint would definitely be a good idea.
-> Perhaps a dedicated, online sprint in 2020.
-> In-person sprints in 2021, when the world becomes a better place.
   * Anybody is planning to host?
 -> georg mentioned that he could do so in Germany. Is it still on?
 -> ...

-> TODO: add more..


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


7. Any other business?
==

-> Make the community more "engaging"..
   * TODO: add more..
-> Do we want to continue the monthly meets?
   * or make it bi-monthly?

-> TODO: add more..


8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<


==


Best,
Utkarsh

[Reminder] Ruby team meeting on Friday, 07th August, 2020

[Utkarsh Gupta]

Hello,

The next Ruby team meeting is on Friday, 07th August at 1630 UTC.
(which is tomorrow for most timezones)

Please put the topics that you want to discuss here:
https://wiki.debian.org/Teams/Ruby/IRCMeetings

I look forward to (virtually) seeing y'all! \o/


Best,
Utkarsh

Re: ruby-rails update destroy redmine issue number linking

[Utkarsh Gupta]

Hi Sylvain,

On Mon, Aug 3, 2020 at 6:02 PM Sylvain Beucler  wrote:
> This version is now impacted by new security issues, such as
> CVE-2020-8163, so I would recommend upgrading anyway.  There is no place
> to upload a new version (in particular, not in ELTS where neither rails
> nor redmine are supported), and as far as I understand s.jaekel could
> revert the security fixes manually, nearly a month ago. What are you
> suggesting, more precisely?

What I was suggesting is no more relevant, you explained it in the
above paragraph itself^ :)

With regard to the above conversation(s), I am closing this bug for now.
Please re-open if deemed necessary.

Sylvain,
Thanks for your pro-active work and reply here. Much appreciated!


Best,
Utkarsh

Re: ruby-rails update destroy redmine issue number linking

[Utkarsh Gupta]

Hi Sylvain,

On Mon, Aug 3, 2020 at 5:15 PM Sylvain Beucler  wrote:
> Then I realized that this is about Debian Jessie which reached
> end-of-life a month ago, so the solution is to upgrade to Debian 9.

Whilst I am totally fine by this suggestion, but still asking..
Would it make sense to fix this, since this upload was made just
around the time Jessie was EOL'ed.
Of course, I'd want people to upgrade, for sure, but in case they
can't, I don't want to leave them high and dry.

D'you think there's anything that could be done here?
(or if that's too much to work on, maybe consider reverting the fixes?)


Best,
Utkarsh

Re: ruby-rails update destroy redmine issue number linking

[Utkarsh Gupta]

On 8/3/20 1:56 PM, Utkarsh Gupta wrote:
> On Tue, 07 Jul 2020 09:36:20 +0200 "s.jaekel"  wrote:
>> Package: ruby-rails
>> Version: 2:4.1.8-1+deb8u7
>> Severity: important
>> Tags: upstream
>>
>> I updated the ruby-rails packages last week.
>> Since then i can use the also installed redmine (3.0~20140825-8~deb8u4)
>> no longer link tickets together.
> 
> This was not a regular upload but an upload by the LTS team.
> I've CC'ed Sylvain (& LTS team), so hopefully someone can take a look at it.

I had snipped the bug report while CC'ing respective teams.
Please see #964432 for the entire bug report. It is more verbose.


Best,
Utkarsh



signature.asc
Description: OpenPGP digital signature

Re: ruby-rails update destroy redmine issue number linking

[Utkarsh Gupta]

Hi

On Tue, 07 Jul 2020 09:36:20 +0200 "s.jaekel"  wrote:
> Package: ruby-rails
> Version: 2:4.1.8-1+deb8u7
> Severity: important
> Tags: upstream
> 
> I updated the ruby-rails packages last week.
> Since then i can use the also installed redmine (3.0~20140825-8~deb8u4)
> no longer link tickets together.

This was not a regular upload but an upload by the LTS team.
I've CC'ed Sylvain (& LTS team), so hopefully someone can take a look at it.


Best,
Utkarsh



signature.asc
Description: OpenPGP digital signature

Re: sup-mail package - from Debian Ruby Attic

[Utkarsh Gupta]

Hi Iain,

On Tue, Jul 21, 2020 at 2:10 AM Iain Parris  wrote:
> I've pushed my first commits, and we now for the first time have a
> passing pipeline. :-)
> A review would be very appreciated, because I'm brand new to Debian
> packaging.

Wow, this is good! Thanks :)

> I haven't yet updated debian/changelog - would you like to update it
> yourself, or for me to do it before/after review?

Please do so. You can generate the changelog entry via:
`gbp dch -aR`.
However, let the changelog entry be set to "UNRELEASED" for now.
We'll replace it with "unstable" once the already uploaded package
clears the NEW queue.

> Thank you - I've joined #debian-ruby, my nick is IPv2. You're welcome to
> message me anytime, and I'll normally be able to reply same-day.

\o/

> Thank you for the PR - received. :-) I will review ASAP.

Thanks for the kind review, reverted! \o/

> Thanks again for all your help.

No problem and likewise! \o/


Best,
Utkarsh

Re: sup-mail package - from Debian Ruby Attic

[Utkarsh Gupta]

Hi Iain,

On Mon, Jul 20, 2020 at 5:02 AM Iain Parris  wrote:
> Wow! That was extremely fast. Thank you so much Utkarsh - very much
> appreciated. :-)

Hehe, you're welcome! \o/

> Excerpts from Utkarsh Gupta's message of 2020-07-20 04:28:33 +0530:
> Thank you (x5)! That's wonderful to hear. There are two new upstream
> maintainers (I am one), and we've both previously been using Sup for
> many years before we volunteered to pick up the maintenance, so we're
> planning to maintain upstream for the long term.

That's awesome!

> I would be very happy to help in anyway that I can with the maintenance
> of sup-mail in Debian too, following your lead. For example, would you
> like me to fork in Salsa, and take a look at the failing pipeline, to
> see if we can get to a green build in Debian?

Most certainly!
I have granted you push access to the git repository, which means you
can essentially push commits to ruby-team/sup-mail repository.
(I believe that even if someone messes up somewhere, things can always
be reverted! So just push directly and I'll keep reviewing those changes! \o/)

So the Debian maintenance is a bit different from upstream development.
Here, we have 3 branches: master, upstream, and pristine-tar.
Described in https://wiki.debian.org/Teams/Ruby/Packaging/#Git_workflow.

I can help you quickly understand the basic workflow of packaging.
The best place would be #debian-ruby at OFTC (on IRC).
Please free to join there and ping me, my nick is utkarsh2102.

> And one small initial request: thank you for adding the new build
> dependencies on ruby-optimist and ruby-unicode-display-width. Please
> could you also remove the old build dependency on ruby-trollop?
> (ruby-optimist replaced ruby-trollop.)

Eeks, I should've done that in the first place.
Anyway, since you want to contribute to Debian, would you like to
do that yourself? :)
(now that you have commit access to sup-mail, just clone the repository,
do the changes, commit and push! \o/)

Let me know if you face any problems!?

> > Also, the most important part where you can really help is when I forward
> > some patches/issues upstream, maybe you can take a look at them and
> > provide a fix so it's more easier to maintain the package on the Debian
> > side! :)
>
> Yes definitely, I'm of course very happy to do this. I've subscribed
> myself to this mailing list, so you can reach me here. Or the upstream
> mailing list is .

That's lovely, great!

> Or upstream pull requests and/or issues on GitHub are always very
> welcome: https://github.com/sup-heliotrope/sup/>.

Nice! I'll forward dropping-the-git patch. So hopefully you'll see a PR soon! :)

> Huge thank you again Utkarsh - I wasn't expecting such a friendly
> response. But I can see for myself, you are friendly here, just like you
> said. :-)

You're very welcome! Everyone is ;)


Best,
Utkarsh

Re: sup-mail package - from Debian Ruby Attic

[Utkarsh Gupta]

Hi Iain,

On Mon, Jul 20, 2020 at 3:47 AM Iain Parris  wrote:
> I am a long-time Debian user (running for 12+ years continuously in
> production), but this is my very first post on a Debian mailing list.
> I'd like to say a *huge* thank you for all that you do, from a very
> happy user. :-)

Very happy to know! :)

> The "sup-mail" package was removed from unstable and testing in April,
> due to FTBFS (no Ruby 2.7 compatibility and inactive upstream):
> ,
> .
>
> Upstream is now active again: I and another long-term Sup user are now
> the new upstream Sup maintainers. We released a new upstream version
> last week, including Ruby 2.7 support and other fixes - Sup 1.0.
> Upstream: . (I am @IPv2 on
> GitHub.)

Aha, that's very nice indeed! \o/
Thanks for becoming the new upstream! :)

> The "sup-mail" package is still in stable, and working fine there. It
> would be nice if possible to reintroduce it before the bullseye release,
> to avoid breakage for existing users during the buster to bullseye
> upgrade, when system Ruby is upgraded to version 2.7.

Of course. Now that the upstream is active again, we can sure
re-introduce the package.

> Three questions please:
>
> (1) Is it possible to move sup-mail out of the Attic
>  - who can do
> this?

This is done now!
Repository here: https://salsa.debian.org/ruby-team/sup-mail

> (2) Can we sync sup-mail with upstream, with the goal of reintroducing
> sup-mail package into unstable? Upstream release 1.0:
> .

This is also done :)
I have re-uploaded v1.0 to unstable.
It is in the NEW queue now and will soon be in the archive once it has
been accepted by the FTP masters. So it's just a matter of time now :)

> (3) How can I help? I am prepared to volunteer to do any/all of the
> above. I am likely to need a mentor if I look at this myself,
> because this would be my very first Debian contribution. Who's
> friendly? :-)

Everyone's friendly here, welcome aboard ;)

I am happy to maintain this in Debian (as long as you're active upstream :)).
Besides, if you also want to maintain sup-mail in Debian, I'll be happy
to help you through :)
Let me/us know how can I/us help! \o/

Also, the most important part where you can really help is when I forward
some patches/issues upstream, maybe you can take a look at them and
provide a fix so it's more easier to maintain the package on the Debian
side! :)

> (I am sending this email to Utkarsh as the last committer to
> ,
> and to the wider Debian Ruby Team as per the wiki documentation,
> .)

Thanks for your mail! \o/


Best,
Utkarsh

Re: RFA: ruby-cucumber-wire, ruby-iso8601, ruby-tomlrb

[Utkarsh Gupta]

Hi Stefano,

On Sat, Jul 18, 2020 at 3:38 AM  wrote:
> $ reverse-depends -b src:ruby-iso8601
> No reverse dependencies found
>
> RM?

I kinda need it so added (and uploaded) myself as an uploader!
Thanks for your work so far! \o/


Best,
Utkarsh

Re: supported Ruby packages

[Utkarsh Gupta]

Hi Marc, Praveen,

On Wed, Jul 15, 2020 at 10:38 AM Marc Dequènes (duck)  wrote:
> I'm so glad to hear this. I was trying to reach you through your anger
> but felt I just got things worse and it made me feel really bad.

All good now \o/

> Then it's fine and as you said there's nothing to act upon. Since
> security updates are unplanned then you can redirect people to the team
> when you're overloaded.

Yep, thanks!

> Fortunately this can be fixed. I saw Praveen's mail about the transition
> and failing packages so it means he still do care.

Praveen,
We all appreciate the great work that you do. And I am terribly sorry that
you had to drop yourself because of something that wasn't supposed to
happen in the first place.
But what's done is done. I'd love for you to revert 8a818dd3 and add
yourself back :)
(I'd personally love that!)

But again, it's your call in the end. Just know that you don't have to do
anything that you don't want to. We can still maintain Rails the way we've
been doing so far, which would be very nice!

So all I ask you is to re-consider joining back (not that you ever left in the
first place :)).

> My bad then because I missed your calls. Not that this change my own
> availability though :-/.
> The more I'm overloaded the less I'm properly able to follow
> communication channels, I focus on the packages I know and only (barely)
> talk to people I know well.
> I was very happy to be able to join at the Paris meeting so that I could
> be more in touch with you all, but I guess that would need to be
> reproduced.

No worries & thanks for all your work \o/

> As for assumptions I thought about what you said. I agree there's a lot
> of these and that's not necessary good. But the fact is Debian has a lot
> of history and previous people had their own view about how to build
> this project and it's true there's a strong notion of commitment around
> it. NM people also had a bad time at some point because we had people
> coming to get their little toys in and leaving it to rot and others to
> care. All these bad experiences reinforced these expectations. But I
> think it's changing and that's why teams are now commonplace in Debian.
> Several talks (I really love this one:
> https://www.enricozini.org/blog/2017/debian/consensually-doing-things-together/)
> discuss around this topic. Now I think noone but you can know your
> limits and unless you express them people will still hope/expect you're
> going to do the job. So before I understood the situation my point was
> really about clarifying and notifying others, not pushing people to do
> more. Sorry again for missing the call for help.

No worries, it's alright. Sorry from my end for the heated thread, too.

> Btw thanks for your work around ruby-pg. I hit some problem when working
> on redmine and you were faster than me :-).

\o/

> OMG I love hugs :-)
> Many hugs then!

\o/


Best,
Utkarsh

Re: supported Ruby packages

[Utkarsh Gupta]

Hi Marc,

This thread has taken a turn it shouldn't have.
And I am not going to fight fire by fire. I'll try to be more
empathetic, as we all should.

On Mon, Jul 13, 2020 at 1:14 PM Marc Dequènes (duck)  wrote:
> You are totally twisting my words. I gave you my understanding about how
> things are perceived in Debian.

I hear you. And I am sorry if you think I'm twisting them. I do not intend to.
I am just very upset over the fact that someone had to remove themselves
from the uploaders field because of this whole thread, which shouldn't have
happened in the first place.

> The only thing I think is bad about this
> situation is that there is no information anywhere about your decision
> to only care about unstable. I think users expect the whole of Debian's
> released suites and backports to be taken care of, and I think it's good
> to inform them. I'm not asking you do do more, I think we should inform
> and coordinate better, that's all. Beuc suggested
> debian-security-support and I think that's a very good idea.

This has been previously stated (somewhere) and I'd like to state it again:
I *do* take care of the stable updates of Rails.
I am not sure why people are assuming it's not supported. But since there's
confusion amongst all, I'd like to clear it so that we're on the same page.

I have been taking care of stable and oldstable and oldoldstable update
for Rails. And will continue to do so with the best of my ability (and time
and energy). But please know that they're limited, too.

If people see the tracker page, they'll know that it is being taken care of.
However, I did express that I am a little busy at this moment and might
not be able to take care of this CVE before the -pu window closes.

So TL;DR: no one has to worry about the security support for Rails.
It is being taken care of unless I give up or/and explicitly mention so.

I hope this should resolve the main purpose of this entire thread.

> Why do you say "claim"? Just because I'm not helping in your field of
> interest, or just because I have less energy to give Debian these last
> few years makes me a fraud?

It doesn't. I am sorry if I made you feel so.
Your work is very much appreciated. By me, by the team, and by the
entire (and wider) Debian community.

And so is Praveen's. And perhaps everyone would have guessed it by
now what made me feel very upset. And I still am. Pretty much.

> I think limiting yourself to unstable is really not
> something people would expect. If you decide to limit the field of your
> work without telling your team and users, then it's always going to
> cause misunderstandings.

There seems to be a misunderstanding in understanding the misunderstanding.
There were 3 (thanks to this thread, 2 now) uploaders and care-takers of rails.
Praveen has been doing such an amazing job in maintaining and taking care
of Rails and its transition.

And I do take of other little things and the stable updates.
There are no pending CVEs (except for the new bunch where I expressed
I am busy!).

Perhaps it should help us understand a part of that misunderstanding?
Let me know if I am still not clear.

> One good example is when Antonio took advantage of Debconf to come and
> tell us that it was too much for him and needed several packages off his
> shoulders. He asked kindly and I'm happy that with Kanashiro-kun were
> able to help a little bit. If you feel bad about your 157 packages,
> which is really a lot, then maybe you should consider telling the team.
> If the team as it is is not well staffed for so many packages then
> that's something the team has to solve.

Huh!? I send RFH emails after meetings for rails. Nobody replies to that.
Praveen and I, both have sent several emails that weren't replied to.

So *please* really re-evaluate the condition already :)

> I said I was not aware of this limitation (nor were the other teams
> obviously) and I think we should improve on that. Noone replied to that.
> I suggested we look into debian-security-support and noone replied to
> that either.

Because there seems to be nothing to reply for.
Cleared it above, it is being taken care of as it has been so far.

I don't think there's anything that needs to be done here.

> Here I have no authority whatsoever, I'm not pressuring anyone, just
> expressed my opinion and I got a very aggressive reply in return.

I would still ask you to re-evaluate the situation here.
I am sorry for the "very aggressive" reply, which shouldn't have been
felt and written if the initial mail from your end could have been a little
more empathetic and not costing what it did.
I still feel strongly and sadly about it. So just know that you're not the
only one.

> That's really one good reason why I feel bad in many places in Debian even
> when I'm not involved directly. I was happy to be in this more friendly team
> so far, so maybe there's a way to restore that?

Yes, please. The Ruby team is more like a family. And I'd like to reinstate the
same belo

Re: supported Ruby packages

[Utkarsh Gupta]

Hi,

On 7/7/20 7:36 PM, Marc Dequènes (duck) wrote:
> Well I have to admit I do not agree with Praveen's conception. The
> general acceptance in Debian for as long I've been in is that once
> you're in the maint/uploaders fields you're responsible of the package
> wherever it is in Debian.

Well, this is...bad!
First, I hope you're not forgetting that Debian is run by "volunteers"
and this is all volunteering work.
This also means that if, for any reasons, I don't have time (or even if
I  just don't want to), no one can poke me to do the work. Any kind of work.

If you're not "thankful" for the work one does, please don't be
"thankless" either.
(and even while I hope that wasn't your agenda, yet it has led someone
to remove themselves from the uploaders field!)

Which brings me to the next point..
The package is team maintained which you "claim" to have been a part of
for "quite some time". If it is still not clear yet, I explicitly
welcome your help for rails maintenance.

It's funny how one assumes that they are "accountable" and "responsible"
for all kinds of work for all the packages one maintains. Sigh.
I am in maint/uploaders field for 157 packages at the moment, so I ask
you very clearly here, would you expect me to fix every bug (or say,
CVEs) in Sid, Bullseye, Buster, and Stretch?

Let me know if you think so. I'll be happy to orphan each of them so you
don't hold me "accountable" and "responsible" for the package wherever
it is in Debian, the next time.

> It's very interesting because I've been in this team for quite some time
> and I never knew of this.

...sigh.

> Now for Redmine I do care about fixes and security as much as possible
> (all suites, bpo included), but I clearly cannot be a caretaker for the
> huge dependency tree lying beyond (except for the few bits where I
> decided to be in the maint/uploaders fields).

You might also want to be thankful for the work that other team members
do in taking care of that "huge dependency tree lying beyond".
Otherwise, if someone decides to orphan them all, it'd be ironically sad
for you.


Best,
Utkarsh



signature.asc
Description: OpenPGP digital signature

[Reminder] Ruby team meeting on Friday, 03rd July, 2020

[Utkarsh Gupta]

Hello,

The next Ruby team meeting is on Friday, 03rd July at 1630 UTC.
(which is 2 days from now)

Please put the topics that you want to discuss here:
https://wiki.debian.org/Teams/Ruby/IRCMeetings

I look forward to (virtually) seeing y'all  \o/


Best,
Utkarsh

Re: [RFS] ruby-ast

[Utkarsh Gupta]

Hi Abraham,

On Tue, Jun 30, 2020 at 2:21 AM Abraham Raji  wrote:
> Request for review and sponsorship.

Thanks, uploaded!


Best,
Utkarsh

Re: Ruby Team BoF in DC20?

[Utkarsh Gupta]

Hi,

On Wed, Jun 17, 2020 at 11:45 PM Lucas Kanashiro  wrote:
> >> Moreover, I think with an online BoF we can have more people
> >> participating than usual and collect better feedback. This is also a
> >> good opportunity to see each others' face again (not just IRC :).
> >> However, we need to coordinate this well mostly because of the timezone,
> >> our team is well spread and we'd need to find a suitable time for everyone.
> > And for the timing part, I propose the same time as that of our usual 
> > meeting?
> > That is, 1630 UTC. Is everyone OK with it?
> > Should we do a quick poll instead?
>
> The same time works for me.

Perfect, I have submitted the talk with the note mentioning the
preferred time and day (Friday).
If someone is not available or wants it to be changed, let me know.


Best,
Utkarsh

Re: Ruby Team BoF in DC20?

[Utkarsh Gupta]

Hi all,

Finally, since it has been decided that DC20 will be held online, I am
going to submit this.

> Moreover, I think with an online BoF we can have more people
> participating than usual and collect better feedback. This is also a
> good opportunity to see each others' face again (not just IRC :).
> However, we need to coordinate this well mostly because of the timezone,
> our team is well spread and we'd need to find a suitable time for everyone.

And for the timing part, I propose the same time as that of our usual meeting?
That is, 1630 UTC. Is everyone OK with it?
Should we do a quick poll instead?


Best,
Utkarsh

MOM of (fourth) Ruby team meeting

[Utkarsh Gupta]

Hi everyone,

Thank you to everyone who joined!
And to those who couldn't, we look forward to seeing you in the next one! :)

We had a pretty nice (& a quick) meeting.
Here are the logs:

Minutes: 
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-06-05-16.41.html
Minutes (text):
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-06-05-16.41.txt
Log: 
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-06-05-16.41.log.html

The next meeting is on Friday, July 03rd at 1630 UTC.
Stay safe, see you soon!


Best,
Utkarsh

RFH: #919478 affecting rails (& cloned to gem2deb)

[Utkarsh Gupta]

Hello,

This is a call for help!
Weirdly enough, test failures in rails don't cause FTBFS as it should.
This is reported as #919478.

One could simply reproduce this by building @master from the rails
repository in the ruby-team's namespace.

It'd be very nice if someone could take a look at it and help us
figure out a fix! \o/


Best,
Utkarsh

Bug#962264: stretch-pu: package ruby2.3/2.3.3-1+deb9u8

[Utkarsh Gupta]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
X-Debbugs-CC: debian-ruby@lists.debian.org
Severity: normal

Hello,

ruby2.3 was affected by CVE-2020-10663, which was an unsafe object
creation vulnerability.
This has been fixed in Sid, Bullseye, and Jessie already.

Here's the debdiff for stretch-pu:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

diff -Nru ruby2.3-2.3.3/debian/changelog ruby2.3-2.3.3/debian/changelog
--- ruby2.3-2.3.3/debian/changelog2019-12-15 21:58:25.0 +0530
+++ ruby2.3-2.3.3/debian/changelog2020-06-05 14:25:50.0 +0530
@@ -1,3 +1,11 @@
+ruby2.3 (2.3.3-1+deb9u8) stretch; urgency=high
+
+  * Non-maintainer upload.
+  * Add patch to fix unsafe object creation vulnerability.
+(Fixes: CVE-2020-10663)
+
+ -- Utkarsh Gupta   Fri, 05 Jun 2020 14:25:50 +0530
+
 ruby2.3 (2.3.3-1+deb9u7) stretch-security; urgency=high

   * Non-maintainer upload by the Security Team.
diff -Nru ruby2.3-2.3.3/debian/patches/CVE-2020-10663.patch
ruby2.3-2.3.3/debian/patches/CVE-2020-10663.patch
--- ruby2.3-2.3.3/debian/patches/CVE-2020-10663.patch1970-01-01
05:30:00.0 +0530
+++ ruby2.3-2.3.3/debian/patches/CVE-2020-10663.patch2020-06-05
14:25:21.0 +0530
@@ -0,0 +1,36 @@
+From b379ecd8b6832dfcd5dad353b6bfd41701e2d678 Mon Sep 17 00:00:00 2001
+From: usa 
+Date: Mon, 30 Mar 2020 22:22:10 +
+Subject: [PATCH] merge revision(s) 36e9ed7fef6eb2d14becf6c52452e4ab16e4bf01:
+ [Backport #16698]
+
+backport 80b5a0ff2a7709367178f29d4ebe1c54122b1c27 partially as a
+ securify fix for CVE-2020-10663. The patch was provided by
Jeremy Evans.
+
+git-svn-id:
svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_6@67856
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+
+git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_5@67869
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+Author: Utkarsh Gupta 
+
+--- a/ext/json/parser/parser.c
 b/ext/json/parser/parser.c
+@@ -1739,7 +1739,7 @@
+ } else {
+ json->max_nesting = 100;
+ json->allow_nan = 0;
+-json->create_additions = 1;
++json->create_additions = 0;
+ json->create_id = rb_funcall(mJSON, i_create_id, 0);
+ json->object_class = Qnil;
+ json->array_class = Qnil;
+--- a/ext/json/parser/parser.rl
 b/ext/json/parser/parser.rl
+@@ -723,7 +723,7 @@
+ } else {
+ json->max_nesting = 100;
+ json->allow_nan = 0;
+-json->create_additions = 1;
++json->create_additions = 0;
+ json->create_id = rb_funcall(mJSON, i_create_id, 0);
+ json->object_class = Qnil;
+ json->array_class = Qnil;
diff -Nru ruby2.3-2.3.3/debian/patches/series
ruby2.3-2.3.3/debian/patches/series
--- ruby2.3-2.3.3/debian/patches/series2019-12-15 21:58:25.0 +0530
+++ ruby2.3-2.3.3/debian/patches/series2020-06-05 14:25:01.0 +0530
@@ -4,3 +4,4 @@
 Loop-with-String-scan-without-creating-substrings.patch
 WEBrick-prevent-response-splitting-and-header-inject.patch
 lib-shell-command-processor.rb-Shell-prevent-unknown.patch
+CVE-2020-10663.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<


Best,
Utkarsh
---

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#962256: stretch-pu: package ruby-json/2.0.1+dfsg-3+deb9u1

[Utkarsh Gupta]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
X-Debbugs-CC: debian-ruby@lists.debian.org
Severity: normal

Hello,

ruby-json was affected by CVE-2020-10663, which was an unsafe object
creation vulnerability.
This has been fixed in Sid, Bullseye, and Jessie already.

Here's the debdiff for stretch-pu:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

diff -Nru ruby-json-2.0.1+dfsg/debian/changelog
ruby-json-2.0.1+dfsg/debian/changelog
--- ruby-json-2.0.1+dfsg/debian/changelog2016-12-06 05:03:24.0 +0530
+++ ruby-json-2.0.1+dfsg/debian/changelog2020-06-05 12:33:14.0 +0530
@@ -1,3 +1,10 @@
+ruby-json (2.0.1+dfsg-3+deb9u1) stretch; urgency=high
+
+  * Add patch to fix unsafe object creation vulnerability.
+(Fixes: CVE-2020-10663
+
+ -- Utkarsh Gupta   Fri, 05 Jun 2020 12:33:14 +0530
+
 ruby-json (2.0.1+dfsg-3) unstable; urgency=medium

   * Add Conflicts: ruby-json-pure (Closes: #847141)
diff -Nru ruby-json-2.0.1+dfsg/debian/patches/CVE-2020-10663.patch
ruby-json-2.0.1+dfsg/debian/patches/CVE-2020-10663.patch
--- ruby-json-2.0.1+dfsg/debian/patches/CVE-2020-10663.patch
1970-01-01 05:30:00.0 +0530
+++ ruby-json-2.0.1+dfsg/debian/patches/CVE-2020-10663.patch
2020-06-05 12:32:48.0 +0530
@@ -0,0 +1,36 @@
+From b379ecd8b6832dfcd5dad353b6bfd41701e2d678 Mon Sep 17 00:00:00 2001
+From: usa 
+Date: Mon, 30 Mar 2020 22:22:10 +
+Subject: [PATCH] merge revision(s) 36e9ed7fef6eb2d14becf6c52452e4ab16e4bf01:
+ [Backport #16698]
+
+backport 80b5a0ff2a7709367178f29d4ebe1c54122b1c27 partially as a
+ securify fix for CVE-2020-10663. The patch was provided by
Jeremy Evans.
+
+git-svn-id:
svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_6@67856
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+
+git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_5@67869
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+Author: Utkarsh Gupta 
+
+--- a/ext/json/ext/parser/parser.c
 b/ext/json/ext/parser/parser.c
+@@ -1791,7 +1791,7 @@
+ } else {
+ json->max_nesting = 100;
+ json->allow_nan = 0;
+-json->create_additions = 1;
++json->create_additions = 0;
+ json->create_id = rb_funcall(mJSON, i_create_id, 0);
+ json->object_class = Qnil;
+ json->array_class = Qnil;
+--- a/ext/json/ext/parser/parser.rl
 b/ext/json/ext/parser/parser.rl
+@@ -686,7 +686,7 @@
+ } else {
+ json->max_nesting = 100;
+ json->allow_nan = 0;
+-json->create_additions = 1;
++json->create_additions = 0;
+ json->create_id = rb_funcall(mJSON, i_create_id, 0);
+ json->object_class = Qnil;
+ json->array_class = Qnil;
diff -Nru ruby-json-2.0.1+dfsg/debian/patches/series
ruby-json-2.0.1+dfsg/debian/patches/series
--- ruby-json-2.0.1+dfsg/debian/patches/series2016-12-06
05:03:24.0 +0530
+++ ruby-json-2.0.1+dfsg/debian/patches/series2020-06-05
12:32:29.0 +0530
@@ -1,3 +1,4 @@
 02-fix-fuzz.rb-shebang.patch
 04-fix-tests-path.patch
 0003-Remove-additional-gemspec-files.patch
+CVE-2020-10663.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<


Best,
Utkarsh
---

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#962255: buster-pu: package ruby-json/2.1.0+dfsg-2+deb10u1

[Utkarsh Gupta]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
X-Debbugs-CC: debian-ruby@lists.debian.org
Severity: normal

Hello,

ruby-json was affected by CVE-2020-10663, which was an unsafe object
creation vulnerability.
This has been fixed in Sid, Bullseye, and Jessie already.

Here's the debdiff for buster-pu:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<

diff -Nru ruby-json-2.1.0+dfsg/debian/changelog
ruby-json-2.1.0+dfsg/debian/changelog
--- ruby-json-2.1.0+dfsg/debian/changelog2018-02-25 23:03:06.0 +0530
+++ ruby-json-2.1.0+dfsg/debian/changelog2020-06-05 12:13:54.0 +0530
@@ -1,3 +1,10 @@
+ruby-json (2.1.0+dfsg-2+deb10u1) buster; urgency=high
+
+  * Add patch to fix unsafe object creation vulnerability.
+(Fixes: CVE-2020-10663)
+
+ -- Utkarsh Gupta   Fri, 05 Jun 2020 12:13:54 +0530
+
 ruby-json (2.1.0+dfsg-2) unstable; urgency=medium

   * Team upload.
diff -Nru ruby-json-2.1.0+dfsg/debian/patches/CVE-2020-10663.patch
ruby-json-2.1.0+dfsg/debian/patches/CVE-2020-10663.patch
--- ruby-json-2.1.0+dfsg/debian/patches/CVE-2020-10663.patch
1970-01-01 05:30:00.0 +0530
+++ ruby-json-2.1.0+dfsg/debian/patches/CVE-2020-10663.patch
2020-06-05 12:12:56.0 +0530
@@ -0,0 +1,36 @@
+From b379ecd8b6832dfcd5dad353b6bfd41701e2d678 Mon Sep 17 00:00:00 2001
+From: usa 
+Date: Mon, 30 Mar 2020 22:22:10 +
+Subject: [PATCH] merge revision(s) 36e9ed7fef6eb2d14becf6c52452e4ab16e4bf01:
+ [Backport #16698]
+
+backport 80b5a0ff2a7709367178f29d4ebe1c54122b1c27 partially as a
+ securify fix for CVE-2020-10663. The patch was provided by
Jeremy Evans.
+
+git-svn-id:
svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_6@67856
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+
+git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_5@67869
b2dd03c8-39d4-4d8f-98ff-823fe69b080e
+Author: Utkarsh Gupta 
+
+--- a/ext/json/ext/parser/parser.c
 b/ext/json/ext/parser/parser.c
+@@ -1815,7 +1815,7 @@
+ } else {
+ json->max_nesting = 100;
+ json->allow_nan = 0;
+-json->create_additions = 1;
++json->create_additions = 0;
+ json->create_id = rb_funcall(mJSON, i_create_id, 0);
+ json->object_class = Qnil;
+ json->array_class = Qnil;
+--- a/ext/json/ext/parser/parser.rl
 b/ext/json/ext/parser/parser.rl
+@@ -710,7 +710,7 @@
+ } else {
+ json->max_nesting = 100;
+ json->allow_nan = 0;
+-json->create_additions = 1;
++json->create_additions = 0;
+ json->create_id = rb_funcall(mJSON, i_create_id, 0);
+ json->object_class = Qnil;
+ json->array_class = Qnil;
diff -Nru ruby-json-2.1.0+dfsg/debian/patches/series
ruby-json-2.1.0+dfsg/debian/patches/series
--- ruby-json-2.1.0+dfsg/debian/patches/series2018-02-25
23:03:06.0 +0530
+++ ruby-json-2.1.0+dfsg/debian/patches/series2020-06-05
12:09:39.0 +0530
@@ -2,3 +2,4 @@
 04-fix-tests-path.patch
 0003-Remove-additional-gemspec-files.patch
 0006-Disable-git-usage-during-build-time.patch
+CVE-2020-10663.patch

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--


Best,
Utkarsh
---

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[Reminder] Ruby team meeting on Friday, 05th June, 2020

[Utkarsh Gupta]

Hello,

The next Ruby team meeting is on Friday, 05th June at 1630 UTC.
(which is 1 day from now)

Please put the topics that you want to discuss here:
https://wiki.debian.org/Teams/Ruby/IRCMeetings

I look forward to (virtually) seeing y'all  \o/


Best,
Utkarsh

Re: ruby:Depends and minimum version of gem2deb

[Utkarsh Gupta]

Hi,

On Sun, May 31, 2020 at 6:50 PM Utkarsh Gupta  wrote:
> On Sun, May 31, 2020 at 3:42 PM Pirate Praveen  
> wrote:
> > An error occurred while loading
> > ./spec/jira/resource/user_factory_spec.rb.
> > Failure/Error: require 'pry'
> >
> > ArgumentError:
> >   non-absolute home
> > # ./spec/spec_helper.rb:3:in `'
> > # ./spec/jira/resource/user_factory_spec.rb:1:in `'
>
> It looks like setting `ENV['HOME']` should fix this but I am not sure
> how to do it exactly.
> Whilst I look up on how to get this done, if someone with prior
> experience knows this, it'd be nice to know \o/

I just pushed a patch, can you check if it works for you?


Best,
Utkarsh

Re: ruby:Depends and minimum version of gem2deb

[Utkarsh Gupta]

Hi,

On Sun, May 31, 2020 at 3:42 PM Pirate Praveen  wrote:
> An error occurred while loading
> ./spec/jira/resource/user_factory_spec.rb.
> Failure/Error: require 'pry'
>
> ArgumentError:
>   non-absolute home
> # ./spec/spec_helper.rb:3:in `'
> # ./spec/jira/resource/user_factory_spec.rb:1:in `'

It looks like setting `ENV['HOME']` should fix this but I am not sure
how to do it exactly.
Whilst I look up on how to get this done, if someone with prior
experience knows this, it'd be nice to know \o/


Best,
Utkarsh

Teams/Ruby/IRCMeetings wiki page revived and updated!

[Utkarsh Gupta]

Hi all,

I finally revived and updated our Teams/Ruby/IRCMeetings wiki page.
It now has:
  - details of the meeting (when, where, how).
  - agenda of the upcoming meeting.
  - logs of the previously hosted meeting.

Hope this looks nice and fresh. Feel free to add other details as you see fit :)


Best,
Utkarsh

RFH: testing Rails 6 reverse dependencies

[Utkarsh Gupta]

Hi all,

We had a discussion about Rails 6 transition during the meeting today.
Whilst the status is temporarily blocked, it was bought up that the
testing of reverse dependencies is yet to be done.

Given that the number of reverse-(build-)dependencies are huge, it
would be nice to have some help as this cannot be done by a single
person alone :)

Relevant links can be found here[1][2].
Please help us in getting Rails 6 to Sid & Bullseye, too :)

If you have any questions, please don't hesitate to ask them here or on IRC.


Best,
Utkarsh
---
[1]: 
https://salsa.debian.org/ruby-team/rails/-/wikis/Transition-to-Rails-6-for-Debian-Bullseye
[2]: https://salsa.debian.org/terceiro/mass-rebuild

Re: reducing volument of KGB notifications on IRC

[Utkarsh Gupta]

Hiya,

> As per discussion on IRC, this is now live: KGB notifications for
> commits and CI pipeline stati are now send to #debian-ruby-changes.

I just added the details about #debian-ruby-changes channel to our
Ruby team wiki page :)


Best,
Utkarsh

MOM of (third) Ruby team meeting

[Utkarsh Gupta]

Hi everyone,

Thank you to everyone who joined!
And to those who couldn't, we look forward to seeing you in the next one! :)

We had a pretty nice (& a quick) meeting.
Here are the logs:

Minutes: 
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-05-08-16.53.html
Minutes (text):
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-05-08-16.53.txt
Log: 
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-05-08-16.53.log.html

The next meeting is on Friday, June 5th at 1630 UTC.
Stay safe, see you soon!


Best,
Utkarsh

Re: Ruby Team BoF in DC20?

[Utkarsh Gupta]

Hi all,

On Mon, Mar 2, 2020 at 4:19 AM Utkarsh Gupta  wrote:
> I hope to be around there and willing to facilitate the same.
> Would people be interested? Remotely or otherwise?
>
> Given that we have CfP for DC20 open, I'd be happy to propose this if
> we have a mutual consent over it.

I still haven't proposed a BoF for DC20 yet mostly because:
a) Not sure if DC20 will still happen or not!?
b) I am not sure if my parents are going to let me go :/

Should I still propose a BoF anyway?

Alternatively, we have an online MiniDeb{Camp/Conf}[1] happening from
28th to 31st May.
The CfP for the same is open and I was wondering if we should propose
a BoF there instead?

Let me know what y'all think about this.


Best,
Utkarsh

[Reminder] Ruby Team Meeting on Friday, 08th May

[Utkarsh Gupta]

Hi all,

As the subject makes it very clear, the next Ruby team meeting is on
Friday, 08th May at 1630 UTC.
(which is 1 day from now)

I look forward to (virtually) seeing y'all :)


Best,
Utkarsh

Re: heads up: ruby-thor 0.20.3 will be uploaded to unstable soon

[Utkarsh Gupta]

Hi Praveen,

On Mon, Apr 13, 2020 at 8:00 PM Pirate Praveen  wrote:
> ruby-thor 0.20.3 is required for rails 6 transition and was in
> experimental for a long time. I tested reverse dependencies today and
> found only ruby-coveralls is failing with this version (#956600 filed).

thor 1.0.1 has been out for a while. puppet-beaker requires 1.0.1
version of thor.
There's another library (I don't remember which one), needed the 1.0.1 version.

Any plans to update thor to the latest version?
cf: https://github.com/erikhuda/thor/releases


Best,
Utkarsh

Re: ruby-rack and ruby-http upload to unstable

[Utkarsh Gupta]

Hi all,

On Mon, Apr 6, 2020 at 10:40 PM Utkarsh Gupta  wrote:
> This won't break anything and I hope there's no problem with this.
> I'm sending this to the list so there's no overlapping of work and
> everyone is aware (also read as: head's up for everyone).
>
> Let me know if you want me to delay this bit or have anything to suggest.

This is done.
I've uploaded all the mentioned packages to unstable. Hopefully,
nothing should break.
I'll keep an eye on it, in case there's any kind of regression and
shall take care of it.


Best,
Utkarsh

ruby-rack and ruby-http upload to unstable

[Utkarsh Gupta]

Hi all,

I started working on ruby-http and ruby-rack sometime back and here's
how I plan to upload them to unstable.

ruby-http (4.4.1 to unstable)
==
Once ruby-http-parser clears NEW, I'll upload ruby-http to unstable
with Breaks for ruby-twitter's version in sid (that's the only thing
that breaks).
And at the same time, I'll upload ruby-twitter (7.0.0) to unstable
(which is compatible with 4.4.1).

ruby-rack (2.1.1 to unstable)
==
Once ruby-http (4.4.1) hits the archive, it'll be enough to fix
ruby-webmock's build against ruby-rack. So the only failure will be
ruby-rack-oauth2 (which I've fixed locally in v1.11.0).
So ruby-rack (with breaks) and ruby-rack-oauth2 would be uploaded at
the same time.


This won't break anything and I hope there's no problem with this.
I'm sending this to the list so there's no overlapping of work and
everyone is aware (also read as: head's up for everyone).

Let me know if you want me to delay this bit or have anything to suggest.


Best,
Utkarsh

Re: Fixing pcs which is blocking Ruby 2.7 transition

[Utkarsh Gupta]

Hi Valentin,

On Mon, Apr 6, 2020 at 2:09 AM Valentin Vidić  wrote:
> Yes, I've noticed the warning too, did not know it was related to the
> new Ruby version. I've uploaded a new version of pcs, so it should be
> fixed now.

Thank you very much!
The recent upload, indeed, fixes the problem :)


Best,
Utkarsh

Re: RFS: ruby-gem-isolator

[Utkarsh Gupta]

Hi Kiran,

On Sun, 5 Apr, 2020, 5:15 AM ,  wrote:

> https://salsa.debian.org/hacksk-guest/ruby-gem-isolator
>
> Consider to review and upload it.


Please also enable tests by pulling specs/ from g/h.


Best,
Utkarsh

>

Re: RFS: ruby-ruby-dep

[Utkarsh Gupta]

Hi Kiran,

On Sun, 5 Apr, 2020, 4:18 AM ,  wrote:

> https://salsa.debian.org/hacksk-guest/ruby-ruby-dep


> Consider to review and upload it.
>

Please also enable tests by pulling the specs/ from g/h.


Best,
Utkarsh

>

Fixing pcs which is blocking Ruby 2.7 transition

[Utkarsh Gupta]

Hi Valentin,

Ruby 2.7 has now been made default (previously Ruby 2.5).
We're working on making ruby-defaults migrate to testing which is
being blocked by a couple of packages, out of which, one is pcs.
As per the logs[1], it seems that you just need to add:
Restrictions: allow-stderr in d/tests/control.

Hope you could do this asap and help us get Ruby 2.7 in testing :)
If you're not able to do it on your own, I'll be happy to fix this
myself via an NMU.

Let me know if you have any questions.


Best,
Utkarsh
---
[1]: https://ci.debian.net/data/autopkgtest/testing/amd64/p/pcs/4832376/log.gz

Re: Heads-up: major version update: ruby-http (from 3.3.0-2 to 4.4.1-1)

[Utkarsh Gupta]

Hi Praveen,

On Fri, Apr 3, 2020 at 11:19 AM Pirate Praveen  wrote:
> It'd be better to share the reverse dependencies that fail to give a better 
> idea of the impact.

ruby-twitter and ruby-webmock fail. But I'll take care of them myself
before the upload of ruby-http.

About ruby-twitter,
Recently, ruby-twitter's upstream rolled out a new release 7.0.0
(after 6.2.0 -- which is in the archive).
This release fixes a bunch of stuff, warnings, et al. I did the update
locally and everything went fine.
However, diaspora and rabbiter are the only rev-deps. Out of which,
diaspora will break.
But given diaspora is already broken in unstable, will it be okay to
upload ruby-twitter 7.0.0 to unstable?
Or should it go via experimental (if you want?) or something?


Best,
Utkarsh

Heads-up: major version update: ruby-http (from 3.3.0-2 to 4.4.1-1)

[Utkarsh Gupta]

Hi all,

I've prepared the major version update for ruby-http, that is, from
3.3.0-2 to 4.4.1-1.
I intend to upload this version to unstable (after checking its
rev-deps, of course) as soon as ruby-http-parser clears NEW (uploaded
just a few minutes ago).

Hopefully, this should buy everyone enough time to take care of $things.
This is just a heads up.

Please tell me to wait or put this on hold if you want more time or whatever.


Best,
Utkarsh

Re: RFC: pry 0.13.0 upload to experimental?

[Utkarsh Gupta]

On Thu, Apr 2, 2020 at 2:04 PM Pirate Praveen  wrote:
> >> >I'll upload pry 0.13.0 into unstable.
> >> >Thanks for your commit.
> >> Did you also fix the two broken packages mentioned by Daniel ?
> >I think no need to be special care.
> All these should be uploaded at the same time.

FWIW, ruby-guard and ruby-pry-byebug have been fixed and uploaded.


Best,
Utkarsh

Re: RFC: pry 0.13.0 upload to experimental?

[Utkarsh Gupta]

Hi Praveen,

On Thu, Apr 2, 2020 at 11:54 AM Pirate Praveen  wrote:
> Did you also fix the two broken packages mentioned by Daniel ?

a) pry has "Breaks" for respective packages.
b) ruby-guard has been fixed and uploaded.
c) ruby-pry-byebug is fixed in the git repository. Waiting for your
ack to upload 3.9.0 (from 3.7.0) to unstable. Let me know if gitlab
works fine; if it does, I'll process the upload.


Best,
Utkarsh

[Reminder] Ruby Team Meeting on Friday, 3rd April

[Utkarsh Gupta]

Hi all,

As the subject makes it very clear, we all agreed to meet for the next
Ruby team meeting on Friday, 3rd April at 1630 UTC.
(which is 2 days from now)

I look forward to (virtually) seeing y'all :)


Best,
Utkarsh

Re: planning to upload ruby-excon 0.72 to unstable causing ruby-vcr to ftbfs

[Utkarsh Gupta]

Hi Antonio,

On Mon, 30 Mar, 2020, 6:10 AM Antonio Terceiro,  wrote:

> I just made an upload of ruby-vcr to fix a FTBFS against the new version
> of ruby-webmock (also just uploaded). I couldn't figure out what is
> the problem with the new ruby-excon, so I didn't fix that yet.


The problem with ruby-webmock is that its tests fail against ruby-rack
2.1.1.
See here: https://github.com/bblimke/webmock/issues/879

Ideally, we should also update ruby-http which needs ruby-http-parser.
I intend to work on it (http update) maybe during the coming weekend or
during the meeting.


Best,
Utkarsh

Re: Bug#951806: ruby-serverengine: FTBFS aginst Ruby2.5 and Ruby2.7

[Utkarsh Gupta]

Hi all,

On Sun, Mar 8, 2020 at 1:15 PM Hideki Yamane  wrote:
>  I've investigated it and it seems that failure happens with ruby-rspec
>  3.9.0c1e0m1s2-1, not 3.8.0c0e1m0s0-1 in buster.

Hm, interesting.
Could someone take a look at this whenever free?
I, myself, don't have enough time to take a look -- mostly because of
the havoc created by COVID-19 :/

> > Just FTR, this package has no reverse-dependencies or
> > reverse-build-dependencies. Is it a good sign for it to be filed for
> > removal?
>
>  No, fluentd needs it (ITPed as https://bugs.debian.org/926692 )

Alrighty, then :)
Help in fixing this is very welcomed! \o/


Best,
Utkarsh

Re: [Pkg-javascript-devel] Help with fixing jekyll (wrt src:node-webpack)

[Utkarsh Gupta]

Hi Praveen,

On Sat, Mar 14, 2020 at 4:54 PM Pirate Praveen  wrote:
> I have patched webpack to use uglifyjs-webpack-plugin till
> terser-webpack-plugin is availabel in the archive. I confirmed jekyll
> is building fine, I'll upload it soon.

Thank you very much for your quick fix!
Very much appreciated! \o/


Best,
Utkarsh

Re: RFS: ruby-net-http-persistent

[Utkarsh Gupta]

Hi,

On Sat, Mar 14, 2020 at 4:19 PM Pirate Praveen  wrote:
> How did you run the autopkgtest? I'm still seeing the failure. After 
> bundle-bin-path there should be a testsuite which failed. Can anyone else 
> confirm this?

I can confirm that the testsuite fails. There seems to be an ArguementError.

```
autopkgtest [16:39:02]: test bundle-bin-path: ---]
autopkgtest [16:39:02]: test bundle-bin-path:  - - - - - - - - - -
results - - - - - - - - - -
bundle-bin-path  PASS
autopkgtest [16:39:02]:  summary
testsuiteFAIL non-zero exit status 1
bundle-gem   PASS
smoke-test   PASS
bundle-bin-path  PASS
```


Best,
Utkarsh

Re: RFS: ruby-concord

[Utkarsh Gupta]

Hi,

On Fri, Mar 13, 2020 at 1:23 PM Pirate Praveen  wrote:
> > Consider to review and upload it.
>
> Uploaded and pushed to ruby-team on salsa. I don't think mentioning it
> is a dependency of gitlab in description is useful (it is useful in an
> itp), so removed it.

The extended description is still short.
Kiran, could you please fix it so that it's good in the next upload?

Additionally, it is perhaps the 3rd package where the tests has been
disabled because of the devtools, does it make sense to have devtools
packaged?
How many packages does it additionally require?


Best,
Utkarsh

Help with fixing jekyll (wrt src:node-webpack)

[Utkarsh Gupta]

Hi there,

Currently, Jekyll doesn't build. Here's why:
This commit[1] introduced using webpack. However this command:

```
cd debian/node_modules/livereload-js; webpack --entry ./lib/startup.js \
--output
../../../lib/jekyll/commands/serve/livereload_assets/livereload.js; cd
-
```

fails to run with the following error:

```
/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:281
throw err;
^

Error: Cannot find module 'terser-webpack-plugin'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require 
(/usr/share/nodejs/webpack/node_modules/v8-compile-cache/v8-compile-cache.js:161:20)
at Object.apply
(/usr/share/nodejs/webpack/lib/WebpackOptionsDefaulter.js:302:27)
at WebpackOptionsApply.process
(/usr/share/nodejs/webpack/lib/WebpackOptionsApply.js:467:16)
at webpack (/usr/share/nodejs/webpack/lib/webpack.js:53:48)
at processOptions
(/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:272:16)
at yargs.parse
(/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:364:3)
at Object.parse (/usr/share/nodejs/yargs/yargs.js:611:18)
at /usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:49:8
at Object.
(/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:366:3)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/usr/share/nodejs/webpack/bin/webpack.js:156:2)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)
```

This maps to src:node-webpack. Whilst package.json (of node-webpack)
says to have a dependency on terser-webpack-plugin, however, it isn't
packaged and nor embedded. In fact, there's no mention of
terser-webpack-plugin at all.
This creates a problem with Jekyll (as shown above). I am not sure
what's the best way forward now? Is to embed terser-webpack-plugin
(with it's other dependencies packaged or embedded)? Or to embed
livereload-js into jekyll? Or what?

In any case, this is a bug with src:node-webpack which would be good
to have fixed.


Best,
Utkarsh
---
[1]: 
https://salsa.debian.org/ruby-team/jekyll/-/commit/737def7c142fa252183bef6fa421dbb144f45351

MoM of (first) virtual meeting

[Utkarsh Gupta]

Hi everyone,

Thank you to everyone who joined!
And to those who couldn't, we look forward to seeing you in the next one! :)

We had a pretty nice (& a quick) meeting.
Here are the logs:

Minutes: 
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-03-13-16.35.html
Minutes (text):
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-03-13-16.35.txt
Log: 
http://meetbot.debian.net/debian-ruby/2020/debian-ruby.2020-03-13-16.35.log.html

We also agreed on having meetings on every first Friday of the month,
at 16:30 UTC.
(which means the next meeting is on 3rd April 2020; 16:30 UTC)

Stay safe; see you soon!


Best,
Utkarsh

Re: Reminder for virtual meeting #1 \o/

[Utkarsh Gupta]

Hi everyone,

On Thu, 12 Mar, 2020, 2:26 AM Utkarsh Gupta,  wrote:

> So the results of both the poll bring us to the conclusion that..
>
> The meeting would be held on Friday, 13th March 2020 (consensus at
> [1]) and the time slot would be 1730 to 1830 CET / 1330 to 1430 BRT /
> 2200 to 2300 IST (consensus at [2]).
> I hope to (virtually) see y'all there! \o/
>

Reminding everyone that the meeting is in around 2 hours from now. Looking
forward to see you there.


Best,
Utkarsh

>

Re: Reminder for virtual meeting #1 \o/

[Utkarsh Gupta]

Hi all,

On Mon, Mar 2, 2020 at 2:36 AM Utkarsh Gupta  wrote:
> Right. So after some permutation & combination, I propose the
> following time slots:
>
> 1. 1530 to 1630 CET / 1130 to 1230 BRT / 2000 to 2100 IST
> 2. 1630 to 1730 CET / 1230 to 1330 BRT / 2100 to 2200 IST
> 3. 1730 to 1830 CET / 1330 to 1430 BRT / 2200 to 2300 IST
> 4. 1830 to 1930 CET / 1430 to 1530 BRT / 2300 to  IST
>
> (given that I wasn't sure how to decide this, I'm making another poll)
> Link: https://framadate.org/SWhtCu2bnKHbRANN

So the results of both the poll bring us to the conclusion that..

The meeting would be held on Friday, 13th March 2020 (consensus at
[1]) and the time slot would be 1730 to 1830 CET / 1330 to 1430 BRT /
2200 to 2300 IST (consensus at [2]).
I hope to (virtually) see y'all there! \o/


Best,
Utkarsh
---
[1]: https://framadate.org/ruby-team-virtual-meeting-1
[2]: https://framadate.org/SWhtCu2bnKHbRANN

Re: RFS: ruby-adamantium

[Utkarsh Gupta]

Hi Kiran,

On Tue, Mar 10, 2020 at 12:45 PM  wrote:
> both things are done
> can u review it

Uploaded with a minor fix. Check the last commit.
And thanks for your quick fix!


Best,
Utkarsh
---
ML Guidelines: 
http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquette.pdf

Re: RFS: ruby-abstract-type

[Utkarsh Gupta]

Hi Praveen,

On Tue, Mar 10, 2020 at 10:44 AM Pirate Praveen
 wrote:
>> I think new packages have an exception on this one.
> No exceptions, a source only upload is required to migrate to testing. For 
> tests, it requires at least devtools from git repo, probably more, so I 
> suggested to disable tests.

I am assuming that this is a temporary thingy. I'd love to see the
tests working (but consider this more like a wishlist bug) ;)


Best,
Utkarsh