Re: debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Utkarsh Gupta]

On Tue, Feb 11, 2020 at 7:24 PM Georg Faerber  wrote:
> Works for me (using 0.45), if it doesn't for you, we should investigate,
> maybe there is a bug lurking, somewhere.

I am using the latest version. 1.0.4.
Maybe this should help us now \o/


Best,
Utkarsh

Re: debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Georg Faerber]

On 20-02-11 19:12:45, Utkarsh Gupta wrote:
> When packaging a new gem, using gem2deb doesn't create a
> debian/salsa-ci.yml file.
> For instance, gem2deb dry-types. This will not yield a salsa-ci.yml
> file, whilst it should.

Works for me (using 0.45), if it doesn't for you, we should investigate,
maybe there is a bug lurking, somewhere.

redmine 4.0.6-1 failing debci (blocking the testing migration) because of depending on i18n ~> 1.5.3

[Daniel Leidert]

Hi Marc,

you worked on redmine. It seems the patch for redmine to increase the allowed
i18n version is maybe too strict. Is there a reason to depend on i18n ~>1.5.3
instead of "just" ~>1.5? The current version of ruby-i18n in unstable is 1.8.2
atm.

https://ci.debian.net/data/autopkgtest/unstable/amd64/r/redmine/4244721/log.gz

If I use

gem "i18n", "~> 1.5"

(or why not ">= 0.7", "< 2"?) the build and tests seem to succeed. Do you want
to have a look or shall I submit the change and re-upload?

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: gem2deb: salsa-ci.yml vs. .gitattributes [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Utkarsh Gupta]

Hi Georg,

On Tue, Feb 11, 2020 at 7:10 PM Georg Faerber  wrote:
> > JFTR: It is also missing debian/.gitattributes - probably for the same
> > reason.
>
> I just did a test: debian/salsa-ci.yml is created correctly, but
> debian/.gitattributes is not. I guess the current code doesn't handle
> files with a dot in the beginning, but I didn't check.

I remember we reproduced the gem2deb-not-creating-salsa-ci.yml issue
on Antonio's system.
And also on Samyak's (few hours ago).


Best,
Utkarsh

Re: debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Utkarsh Gupta]

Hi Georg,

On Tue, Feb 11, 2020 at 6:41 PM Georg Faerber  wrote:
> > Whilst there's debian/salsa-ci.yml in the template, it still doesn't
> > seem to work.
> > It didn't work for me either. And Antonio is aware of this.
>
> I'm not aware, mind to elaborate? What does not work, specifically?

When packaging a new gem, using gem2deb doesn't create a
debian/salsa-ci.yml file.
For instance, gem2deb dry-types. This will not yield a salsa-ci.yml
file, whilst it should.


Best,
Utkarsh

gem2deb: salsa-ci.yml vs. .gitattributes [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Georg Faerber]

Hi,

On 20-02-12 00:50:58, Daniel Leidert wrote:
> JFTR: It is also missing debian/.gitattributes - probably for the same
> reason.

I just did a test: debian/salsa-ci.yml is created correctly, but
debian/.gitattributes is not. I guess the current code doesn't handle
files with a dot in the beginning, but I didn't check.

Cheers,
Georg

Re: RM request for coquelicot and its reverse deps?

[Daniel Leidert]

Am Dienstag, den 11.02.2020, 23:42 + schrieb Georg Faerber:
> On 20-02-12 00:29:55, Daniel Leidert wrote:
> > can we file RM requests for coquelicot and its reverse dependencies
> > like ruby- haml-magic-translations? Both are dead upstream and have RC
> > bugs. ruby-haml- magic-translations further (build-)depends on a
> > non-available ruby-haml version and is not trivial to fix to work with
> > ruby-haml 5 (I just tried; or maybe it's just the tests which need
> > fixing?). So IMHO if we keep these packages we actually become the new
> > upstream for these packages. coquelicot has just two installations
> > according to popcon.
> > 
> > Can we agree on filing RM requests?
> 
> Not yet please -- I would like to check with some people before doing
> so.

Sure. I've pushed what I already did for ruby-haml-magic-translations. Maybe it
helps. The patch needs more work. Many tests fail atm.

HTH and regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: RFS: ruby-wisper and ruby-necromancer

[Daniel Leidert]

Am Mittwoch, den 12.02.2020, 05:04 +0530 schrieb Utkarsh Gupta:
> Hiya,
> 
> On Wed, Feb 12, 2020 at 4:51 AM Georg Faerber  wrote:
> > Another note: Both (and ruby-tty-spinner) lacked debian/salsa-ci.yml.
> > That is fixed now.
> > 
> > Did you create all of them with the help of gem2deb?
> 
> Whilst there's debian/salsa-ci.yml in the template, it still doesn't
> seem to work.

JFTR: It is also missing debian/.gitattributes - probably for the same reason.

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: RM request for coquelicot and its reverse deps?

[Georg Faerber]

Hi,

On 20-02-12 00:29:55, Daniel Leidert wrote:
> can we file RM requests for coquelicot and its reverse dependencies
> like ruby- haml-magic-translations? Both are dead upstream and have RC
> bugs. ruby-haml- magic-translations further (build-)depends on a
> non-available ruby-haml version and is not trivial to fix to work with
> ruby-haml 5 (I just tried; or maybe it's just the tests which need
> fixing?). So IMHO if we keep these packages we actually become the new
> upstream for these packages. coquelicot has just two installations
> according to popcon.
> 
> Can we agree on filing RM requests?

Not yet please -- I would like to check with some people before doing
so.

I'll keep you posted,
cheers,
Georg

debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Georg Faerber]

On 20-02-12 05:04:53, Utkarsh Gupta wrote:
> Whilst there's debian/salsa-ci.yml in the template, it still doesn't
> seem to work.
> It didn't work for me either. And Antonio is aware of this.

I'm not aware, mind to elaborate? What does not work, specifically?

RM request for coquelicot and its reverse deps?

[Daniel Leidert]

Hi all,

can we file RM requests for coquelicot and its reverse dependencies like ruby-
haml-magic-translations? Both are dead upstream and have RC bugs. ruby-haml-
magic-translations further (build-)depends on a non-available ruby-haml version
and is not trivial to fix to work with ruby-haml 5 (I just tried; or maybe it's
just the tests which need fixing?). So IMHO if we keep these packages we
actually become the new upstream for these packages. coquelicot has just two
installations according to popcon.

Can we agree on filing RM requests?

Regards, Daniel


signature.asc
Description: This is a digitally signed message part

Re: RFS: ruby-wisper and ruby-necromancer

[Utkarsh Gupta]

Hiya,

On Wed, Feb 12, 2020 at 4:51 AM Georg Faerber  wrote:
> Another note: Both (and ruby-tty-spinner) lacked debian/salsa-ci.yml.
> That is fixed now.
>
> Did you create all of them with the help of gem2deb?

Whilst there's debian/salsa-ci.yml in the template, it still doesn't
seem to work.
It didn't work for me either. And Antonio is aware of this.
But I think none of us got time to figure out this.
So it is essentially a TODO (and up for grabs) ;)


Best,
Utkarsh

Re: RFS: ruby-wisper and ruby-necromancer

[Georg Faerber]

Hi,

Another note: Both (and ruby-tty-spinner) lacked debian/salsa-ci.yml.
That is fixed now.

Did you create all of them with the help of gem2deb?

Cheers,
Georg

Re: RFS: ruby-wisper and ruby-necromancer

[Georg Faerber]

Hi,

On 20-02-10 22:01:35, Gabriel Filion wrote:
> I've pushed a bit more in my packaging work (and comprehension, thanks
> all for the help on the IRC channel!) and I now have two more packages
> that are ready: ruby-wisper and ruby-necromancer.
> 
> Can someone please review my work in the salsa repos of the same
> names?

Both uploaded to NEW, all in all pretty good! Some quick comments:

- I did run wrap-and-sort -abt on both. (Could we please make this team
  policy, and let gem2deb run it by default?)

- I improved the description of ruby-wisper slightly.

- Regarding patches in general: please use a .patch extension. Also, not
  that important if there is only one, but helps in case one needs to
  handle more patches: adding a number in front, something like
  0001-name-of-your.patch.

> I've had to add a build-dep to ruby-wisper since the spec_helper.rb
> file unconditionally "require"s the coveralls library but it's not
> marked as a development requirement in the gemspec.
> 
> I've reported this upstream:
> https://github.com/krisleech/wisper/issues/182

Great!

> Also, the necromancer library doesn't ship its .rspec file in the
> published gem as a choice they made to avoid clutter in the releases.
> 
> For now I've added a patch in debian/patches/ that re-adds the file
> back in so that tests pass. However, upstream recommended that I build
> with code from github.
> I'm not sure if I should keep that patch in the debian package, or if
> I should change how upstream releases are downloaded, instead, so that
> I get the .rspec file with the rest of the upstream files.

That's an easy patch, but in general, I would recommend to try to reduce
the number of required patches to a minimum, ideally, to zero. I agree
with upstream that in this case, pulling the tarball from GitHub makes
sense, see ruby-gpgme for an example which does this.

Thanks again for your work!

Cheers,
Georg

Re: RFS: ruby-tty-cursor and ruby-tty-spinner

[Georg Faerber]

Hi,

On 20-02-10 16:41:12, Gabriel Filion wrote:
> ah! nice thanks for catching those. I've sent corrections to both
> repos.

Thanks for your work; ruby-tty-cursor was uploaded by Sebastien,
ruby-tty-spinner by me.

> I'm not sure that I know what this means. Just to confirm whether my
> understanding here is ok or not: do you mean that we should use some
> other method for fetching upstream code directly from tar archives
> published on github instead of getting the gem with gem2deb?

Yes, please pull tarballs from GitHub. If in doubt, have a look at
ruby-gpgme, which does this.

> fwiw, for both ruby-tty-cursor and ruby-tty-spinner, I didn't get
> errors while running tests. but maybe "gbp buildpackage" is doing
> something different on my laptop than on salsa-ci?

Well -- it doesn't error out, still it reports "Run tests for ruby2.5:
no test suite!". 

Cheers,
Georg

Re: RC bugs against your packages

[Utkarsh Gupta]

Hi all,

On Sun, Feb 9, 2020 at 7:54 PM Daniel Leidert  wrote:
> Am Montag, den 10.02.2020, 01:13 +0100 schrieb Daniel Leidert:
> [..]
> > Add ruby-dep-selector to the list. RC-buggy and no reverse dependencies
> > except as berkshelf's build-dep.
>
> and ruby-grape-msgpack.


The following RM bugs have been filed:

ruby-websocket-parser (#951129)
reel (#951130)
berkshelf-api (#951131)
ruby-berkshelf-api-client (#951132)
berkshelf (#951133)
ruby-dep-selector (#951172)
ruby-grape-msgpack (#951174)

Thank you for all your work and help.


Best,
Utkarsh

Re: RM chef?

[Utkarsh Gupta]

Hi Christopher,

On Tue, Feb 11, 2020 at 5:39 AM Christopher Huhn  wrote:

 > Given we discussed about the condition of chef during the sprints (the
>  > "crazy" renaming of licensing + can be replaced with "tinc"), is it a
>  > good idea (and time) to file an RM bug for it?
>
> I'd have strong wish to keep the chef-client as an official Debian
> package and not be required to `gem install chef`, build my own package
> or roll out some crazy omnibus stuff (and pay the ridiculous license fee).
>

Ah, of course. I respect that wish of yours. Would you be willing to help
us maintain that?
I wrote the things that need help with chef below (where you asked).


> Do you mean cinc(https://cinc-project.gitlab.io/) when you write tinc?
>

Oh, yes. My bad. I meant cinc.
Would it make sense to replace chef with cinc? Does that work for you?

> (it also fails to build against Ruby 2.7)
>
> The chef developers are actively working on this:
> https://github.com/chef/chef/issues/9227
>

That is good to know, thanks!

What would be the best way for me to help keep chef or cinc in Debian?
>

For chef,
You could help us by updating the package and its reverse dependencies so
they don't fail against Ruby2.7.
You might also want to keep the package updated (there's 16.0.58 out, while
we're at 13.8.7).
Another help would be to fix chef on arm64 as it fails with the latest
version of bundler. See the logs at [1].

Antonio mentioned some problem with the licensing part so you'd probably
need to check that, too.
Also, I guess we can replace chef with cinc, maybe? Or d'you need both?

For cinc,
You'd need to package its dependencies and then package cinc itself.
(I am assuming it hasn't been packaged yet. I cannot see it on tracker, at
least.)


Best,
Utkarsh
---
[1]:
https://ci.debian.net/data/autopkgtest/testing/arm64/c/chef/4252454/log.gz

rails 5.2.3+dfsg-2 debci failure (was: rails_5.2.3+dfsg-2_source.changes ACCEPTED into unstable)

[Utkarsh Gupta]

Hi Sruthi,

> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Fri, 07 Feb 2020 11:55:23 +0100
> Source: rails
> Architecture: source
> Version: 2:5.2.3+dfsg-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Ruby Extras Maintainers  lists.alioth.debian.org 
> >
> Changed-By: Sruthi Chandran  >
> Changes:
>  rails (2:5.2.3+dfsg-2) unstable; urgency=medium
>  .
>* Team upload
>* Relax dependency on bundler

This doesn't seem to work :/
There are some debci failures (see tracker.d.o/rails).

There's a patch update (that is, 5.2.4.1) out. While we're at it, it
might make sense for us to update to that.
Would you be willing to take care of the patch update, too?

Or for now, could you please help and fix the present failures so that
bundler can happily migrate to testing?


Best,
Utkarsh

Re: RM chef?

[Christopher Huhn]

Dear Debian Ruby Maintainers,

> Given we discussed about the condition of chef during the sprints (the
> "crazy" renaming of licensing + can be replaced with "tinc"), is it a
> good idea (and time) to file an RM bug for it?

I'd have strong wish to keep the chef-client as an official Debian 
package and not be required to `gem install chef`, build my own package 
or roll out some crazy omnibus stuff (and pay the ridiculous license fee).


Do you mean cinc(https://cinc-project.gitlab.io/) when you write tinc?


(it also fails to build against Ruby 2.7)


The chef developers are actively working on this:
https://github.com/chef/chef/issues/9227

What would be the best way for me to help keep chef or cinc in Debian?

Kind regards

Christopher


--
Christopher Huhn
HPC group
IT department

GSI Helmholtzzentrum fuer Schwerionenforschung GmbH
Planckstr. 1, 64291 Darmstadt, http://www.gsi.de/

Gesellschaft mit beschraenkter Haftung

Sitz der Gesellschaft / Registered Office:Darmstadt
Handelsregister   / Commercial Register:
Amtsgericht Darmstadt, HRB 1528

Geschaeftsfuehrung/ Managing Directors:
 Professor Dr. Paolo Giubellino, Joerg Blaurock

Vorsitzender des GSI-Aufsichtsrates /
  Chairman of the Supervisory Board:
  Ministerialdirigent Dr. Volkmar Dietz