salsa.d.o/ruby-team: please bump my access level

[Georg Faerber]

Dear team,

I would like to change the settings of some of the packages I'm
maintaining, ruby-mail-gpg for example, to modify the location of the
GitLab CI config. However, currently, I'm unable to do so, due to my
"Developer" level.

Accordingly, could someone bump this please? "Maintainer" should be
appropriate.

Thanks in advance,
cheers,
Georg


signature.asc
Description: PGP signature

Re: salsa.d.o/ruby-team: please bump my access level

[Georg Faerber]

Hi all,

On 19-07-21 15:08:00, Georg Faerber wrote:
> I would like to change the settings of some of the packages I'm
> maintaining, ruby-mail-gpg for example, to modify the location of the
> GitLab CI config. However, currently, I'm unable to do so, due to my
> "Developer" level.
> 
> Accordingly, could someone bump this please? "Maintainer" should be
> appropriate.

That's done by now, thanks to kanashiro.

Cheers,
Georg


signature.asc
Description: PGP signature

Re: RFS: ruby-tty-screen, ruby-tty-reader and ruby-tty-prompt

[Georg Faerber]

Hi,

On 20-02-13 02:49:38, Gabriel Filion wrote:
> Could someone please review my work to make sure I haven't done
> something wrong or forgotten details?

I made some changes, see git for details, all uploaded to NEW.

Thanks for pushing pdk!

Cheers,
Georg

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.

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: debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]

[Georg Faerber]

Hi,

On 20-02-12 15:40:23, Daniel Leidert wrote:
>I think I found the culprit and also fixed it. The .gitattributes file
>inside the template directory prevents itself and salsa-ci.yml from
>being exported into the gem2deb source and therefor into the package,
>where both are missing.
>I now added a .gitattributes file into gem2deb's root overriding the
>export-ignore attribute's value for all files inside the template
>directory and the exported source now has both files. So after testing
>it (maybe add a test to check, both are created?) another upload might
>be in order :)

Thanks for debugging and fixing!

Cheers!

Re: RM request for coquelicot and its reverse deps?

[Georg Faerber]

Hi Daniel, all,

On 20-02-11 23:42:11, Georg Faerber wrote:
> 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.

Please go ahead in regards to the removal, and let me know if you need
support, e.g. with filling bug reports, etc.

Cheers,
Georg

Re: RM request for coquelicot and its reverse deps?

[Georg Faerber]

Hi Lunar, all,

On 20-02-12 10:15:23, Jérémy Bobbio wrote:
> I am sorry I dropped the ball like I did. I don't think I'll return to
> developing Coquelicot anytime soon, even if there are still probably
> interesting work to be done. I wouldn't mind RM requests, quite the
> opposite.

By all means: no need to say sorry. I was an avid user of Coquelicot and
Schleuder for years, back then, and still today (only the later): I'm
deeply grateful for the work you've done.

> I've yet to find enough time and resolution to properly orphan my
> former packages and ask for emeritus status. Any help in this
> direction feels great.

Filling bugs against packages to having you removed from Uploaders:
would help, I guess?

A bit sad to see you go,
cheers
Georg

Re: question about licensing for ruby-spdx-licenses

[Georg Faerber]

Hi,

On 20-02-15 19:30:33, Gabriel Filion wrote:
> There's one package that I need to create as a dependency of
> puppet-development-kit for which I had some questions pop to mind
> about licensing: ruby-spdx-licenses
> 
> The code ships a json file that contains information about all of the
> licenses that the library helps with identifying. This json file was
> copied from the SPDX web site:
> 
> https://github.com/domcleal/spdx-licenses#spdx-licenses
> 
> From what I could gather, the website specifies that all content is
> covered by CC-BY 3.0:
> 
> https://spdx.org/Trademark
> https://www.linuxfoundation.org/terms/
> 
> Then, I also found some mentions about some terms related to the use
> of the SPDX name, which would be present in the package name and in
> the description, and this is where I feel like I'm in uncertain waters
> (at least for me):
> 
> https://spdx.org/frequently-asked-questions-faq-0
> 
> "Can I use the SPDX trademark?
> Yes. It is a registered trademark so don't forget the (r)."
> 
> Do I need to add (r) after the name "SPDX" in the description? Is it
> an issue if the name is used in the package name (since it's in the
> name of the gem) ?

As far as I understand, this is about a single json file, which
copyright foo is unclear. I'm by no means an expert in this field,
probably debian-legal@ is able to help.

I guess, personally, I would just get rid of this file via a
Files-Excluded: stanza in debian/copyright and leveraging the repack
feature of debian/watch to repack (to remove said file) the upstream
tarball.

Cheers,
Georg

Re: confirming some package names before creating them (was Re: [Pkg-puppet-devel] in need of a little help for packaing puppet development kit with all dependencies)

[Georg Faerber]

Hi,

On 20-02-15 19:15:34, Gabriel Filion wrote:
> For the following, here's what I'm intending to choose as a package
> name (ITPs still need to ben sent). I think these are more probably OK
> to be named without the "ruby-" prefix:
> 
>  * jgrep
>-> this one seems rather clear to me since the main script can be
> used independantly on the CLI to process any JSON information
>  * facterdb
>-> this one is usually mainly used as a library but it does ship a
> main script that can be used for printing a set of information from the
> library
>  * metadata-json-lint
>-> same situation as facterdb: it's mainly used as a library but it
> does ship a script for running checks on a file independently on the CLI

Let's go with these, then.

> This one is a bit more tricky:
> 
>  * ruby-pathspec
>-> it's mainly used as a lib but it does ship a script for testing
> values on the CLI.
>* I've already sent an ITP for "ruby-pathspec" before I realized it
> was shipping a script. So if I need to change the name, I'll just need
> to know how I can deal with the ITP bug report to avoid issues.. send a
> bts command to re-title, or is there another manipulation necessary?

That's the way to go, probably adding a small comment to the body of the
mail to explain the name change.

>* The script that's shipped is named "pathspec-rb" which differs from
> the gem name "pathspec". Should the package take on the name of that
> script, "pathspec-rb", even though the library itself is called
> "pathspec"? it seems a bit confusing
>* "pathspec" is pretty generic and refers to a concept in the git
> codebase, so I would possibly tend to keep "ruby-pathspec" as the
> package name. what do others think about this?
 
Sounds good to me. Regarding the name of the script, in case this one
gets installed into /usr/bin, I guess it makes sense to use the same
name as well, as 'pathspec' is quite generic.

Cheers,
Georg

Re: question about licensing for ruby-spdx-licenses

[Georg Faerber]

Hi,

On 20-02-29 17:33:40, Gabriel Filion wrote:
> I don't quite know what those feature are, but if I understand
> correctly you mean you would remove the file to avoid the licensing
> issue altogether?

Exactly.

> The problem is that this file is the core of this library's
> functionality, e.g. it parses the json file and then compares the
> license strings you ask it to lookup with the licenses that are listed
> in the json file. So I can't really get rid of it without rewriting
> how the library gets its information.

I see and wasn't aware of the importance of this file. Well, in this
case, probably d-legal@ has an idea how to go forward.

Cheers,
Georg

Bug reports Ruby 2.7 transition: please use usertags

[Georg Faerber]

Hi all,

In case you report bugs related to the Ruby 2.7 transition, please use
usertags, which allow to easily keep track of these bugs.

To do so, add the following to your bug reporting templates:

User pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition

Bugs tagged as such are then available via [1].

Thanks,
cheers,
Georg


[1] 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-ruby-extras-maintain...@lists.alioth.debian.org=ruby2.7-transition

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-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

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?

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

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: Ruby team sprint -- accomodation etc.

[Georg Faerber]

Hi Cédric, all,

I planned to send this mail since quite some time, but failed to do --
sorry for this.

On 19-11-27 10:08:43, Cédric Boutillier wrote:
> I am a bit short on logistic power, and my initial idea of trying to
> find one place to host you all has failed.

Do you need any support? Not only in regards to logistics, but in
general?

> I asked on debian-devel-french@l.d.o if there are some ideas to
> organize the accomodation, and will let you know if something goes out
> from there.
> 
> A possibility I mentionned on IRC a while ago is:
> https://www.citadines.com/fr/france/paris/citadines-austerlitz-paris.html
> which is about 120 euros for two per night. It is relatively close to
> the place of the sprint. It is not the cheapest
> you can find for a hotel room in Paris, but you have a garantee that
> there will be two single beds if needed.
> 
> Depending on the feedback I get from the debian-devel-french@ list, you
> might have to arrange the accomodation by yourself (I can still give you
> some advice if needed), sorry for that.

I've checked the archive, and, as far as I see, there was only one
reply. Did you get any other responses in this regard?

Any further recommendation regarding hosting? Should we indeed organize
for ourselves?

See you soon,
Georg

Re: Joining Ruby team

[Georg Faerber]

Hi Markus,

On 19-12-30 13:55:23, Markus Frosch wrote:
> I'd like to continue my work on my ruby packages.
> 
> So I would like to join the team as DD.
> 
> Please approve my request on salsa:
> https://salsa.debian.org/ruby-team

Welcome back & done.

Cheers,
Georg

Re: Request to (re)join Ruby team

[Georg Faerber]

Hi Utkarsh,

On 19-12-31 03:05:22, Utkarsh Gupta wrote:
> I'd like to migrate my current membership of the Ruby team to use my
> new Salsa login, i.e., utkarsh \o/

*

> Also, many, many thanks to all for your help, guidance, mentorship,
> and sponsorship! It was lovely meeting y'all at DC19, I hope to see
> everyone soon again! :D

You are very welcome, likewise, and thanks to *you* as well.

> P.S. I'd be really happy if I could get the "owner" ACL so that I can
> add new contributors to the team myself in future.

* I've added you accordingly.

Safe travels into 2020 to all of you,
Georg

Re: Should libruby2.x have Provides: ruby-foo (= x.y.z) for the gems it ships?

[Georg Faerber]

Hi Daniel, all,

On 20-04-13 01:03:47, Daniel Leidert wrote:
> What are your thoughts?

Sounds reasonable, and good!

Thanks,
cheers,
Georg

Re: [DRE-maint] Bug#960229: RFP: pdfbeads -- utility to take scanned page images and convert them to a single PDF file

[Georg Faerber]

(Adding the Ruby team to the loop.)

Hi team, Rogério,

On 20-05-11 15:22:04, Rogério Brito wrote:
> On May 10 2020, Georg Faerber wrote:
> > On 20-05-10 17:24:12, Rogério Brito wrote:
> > > Since I don't know much ruby, I guess that it would be best to
> > > have people from the Ruby team maintain and/or package it. I am
> > > even willing to co-maintain it, if necessary, but, again, my
> > > knowledge of Ruby is minimal.
> > 
> > If you're interested in learning (on your own) and improving your
> > Ruby packaging skills, I'm happy to give you any help necessary.
> 
> Thanks for the kind message. I gave it a shot with gem2deb and I
> produced a (very) preliminary package. It is at:
> 
> https://github.com/rbrito/pkg-pdfbeads
> 
> The changelog, in particular, is very cluttered and should be cleaned,
> among other things. Regarding ruby-specific packaging stuff, I would
> love to get comments and/or corrections.
> 
> The package providing jbig2 should, really, be a Recommends instead of
> a Suggests, but since it is not in Debian yet, I left it as is for the
> time being.
> 
> > Let me know in case you're interested.
> 
> While I'm not sure if I am able to maintain this package (let's say
> that some use asks for a new feature), I won't know how to proceed.
> 
> Assistance and opinions is highly appreciated.

I would like to mentor Rogério and help them "learning by doing". To
make this easier, an account on salsa.d.o with (limited) access to the
team and/or the repo makes sense, IMHO.

Thoughts?

Cheers,
Georg

Re: [DRE-maint] Bug#960229: RFP: pdfbeads -- utility to take scanned page images and convert them to a single PDF file

[Georg Faerber]

Hi Rogério,

On 20-05-11 15:22:04, Rogério Brito wrote:
> Thanks for the kind message. I gave it a shot with gem2deb and I
> produced a (very) preliminary package. It is at:
> 
> https://github.com/rbrito/pkg-pdfbeads

Did you import the latest upstream release? The gemspec tells
"2014-01-30", which was quite some time ago.

Did you try to build the package? Did it work?

Cheers,
Georg

Re: I didn't receive mails from alioth list since March 5th

[Georg Faerber]

Hi,

On 20-03-22 23:43:38, Daniel Leidert wrote:
> did you receive any mail from our alioth maintainers list recently?
> The last mail I received is from March 5th, but the alioth
> webinterface shows mails up to March 20th. I am subscribed. My logs
> don't show any delivering attempts from the alioth list since March
> 5th. So it seems the list is not sending any mails.

Works for me -- let me know if you need specific debugging help,
headers, whatever..

Good luck,
cheers,
Georg

Re: RFH: testing Rails 6 reverse dependencies

[Georg Faerber]

Hi,

On 20-05-09 00:02:06, Utkarsh Gupta wrote:
> [...]
>
> 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.

I'm wondering how the help should look like, in detail.. that is: as far
as I'm not mistaken, rails 6 is already in experimental. What about
reducing manual labor involved in this, and leveraging ci.debian.net to
run tests against all of the involved packages. Of course, this only
makes sense for packages which ship autopkgtests, and so far I didn't
check how many of the involved do so, but I would assume lots of them
do.

Afterwards the results could be "looked on" programmatically, assuming
packages with passing autopkgtests good to go, leaving only packages
with failing autopkgtest to look at. And packages without tests,
additionally.

Thoughts?

Cheers,
Georg

Re: Backporting ruby 2.7 for gitlab

[Georg Faerber]

Hi,

On 20-06-30 10:47:53, Antonio Terceiro wrote:
> To be clear: my opinion is that such backport should not be uploaded
> to Debian Backports, at all.

I agree, for the reasons outlined, and personally, I'm not able to
support such an effort.

Cheers,
Georg

Re: rails 6 will be uploaded to unstable in 8 weeks (August first week)

[Georg Faerber]

Hi,

On 20-06-06 15:05:29, Pirate Praveen wrote:
> It has a list of all packages that failed. Now we need to file bugs
> for these packages. Let me know if you like to help filing bugs. Also
> please start fixing the packages that failed.

Thanks for this.

In case you report bugs related to the Ruby 2.7 transition, please use
usertags, which allow to easily keep track of these bugs.

To do so, add the following to your bug reporting templates:

User pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: rails6-transition

Bugs tagged as such are then available via [1].

Cheers,
Georg


[1] 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-ruby-extras-maintain...@lists.alioth.debian.org=rails6-transition

Re: RFS: ruby-spdx-licenses, metadata-json-lint and ruby-pathspec

[Georg Faerber]

Hi,

On 20-12-21 01:57:14, Gabriel Filion wrote:
> I've finally found some time and energy combined and was able to push
> forward a bit in my project of getting puppet-development-kit in
> debian.
> 
> I think I'm done with three more of the dependencies:
> 
>  * metadata-json-lint
>  * ruby-spdx-licenses
>  * ruby-pathspec
> 
> Could someone please sponsor them?

I'll handle these.

Cheers,
Georg

Re: RFS: ruby-spdx-licenses, metadata-json-lint and ruby-pathspec

[Georg Faerber]

Hi,

On 20-12-28 10:23:24, Georg Faerber wrote:
> >  * ruby-pathspec
> 
> I've pushed two fixes regarding description and copyright to the
> master branch.
> 
> However, more important: this fails to build for me.

As per discussion on IRC, this is fixed and the package was uploaded to
NEW as well.

Cheers,
Georg

Re: RFS: jgrep, facterdb, ruby-rspec-puppet-facts

[Georg Faerber]

Hi,

On 20-12-28 01:07:57, Gabriel Filion wrote:
> Could someone please review my work on jgrep, facterdb and
> ruby-rspec-puppet-facts and send the packages for me, or send me
> correction suggestions if needed?

All uploaded to NEW -- I've changed the section of jgrep to devel
(although ruby would have been fine too -- it was more related to a "gut
feeling"), and adjusted some links to use HTTPS instead of HTTP.

Thank you,
cheers,
Georg

Re: RFS: ruby-spdx-licenses, metadata-json-lint and ruby-pathspec

[Georg Faerber]

Hi,

On 20-12-21 01:57:14, Gabriel Filion wrote:
> I think I'm done with three more of the dependencies:
> 
>  * metadata-json-lint
>  * ruby-spdx-licenses

Both uploaded to NEW.

>  * ruby-pathspec

I've pushed two fixes regarding description and copyright to the master
branch.

However, more important: this fails to build for me.

Without having done further investigation, I assume, that initially you
pulled the gem from rubygems.org, and then later on switched to pull the
tarball from GitHub. This makes sense, and is the right thing to do, in
many cases. However, both the pristine-tar and upstream branch still
represent the data of the initial import, which is why my build fails
due to:

dpkg-source: info: local changes detected, the modified files are:
 ruby-pathspec-0.2.1/.rubocop.yml
 ruby-pathspec-0.2.1/.rubocop_todo.yml
 ruby-pathspec-0.2.1/.travis.yml
 ruby-pathspec-0.2.1/Gemfile
 ruby-pathspec-0.2.1/Rakefile
 ruby-pathspec-0.2.1/install_from_source.sh
 ruby-pathspec-0.2.1/pathspec.gemspec
 ruby-pathspec-0.2.1/rspec_all_versions.sh

The Salsa CI uses a different method, and therefore isn't affected.

Could you please fix this? The easiest way might be to copy the debian
directory to a temporary location, starting from scratch, importing the
tarball obtained from GitHub, and then moving the debian directory back
into place.

It might make sense to also delete the repo and recreate it. (If you
want to go this route, and lack permission to do so, feel free to ping
me on IRC.)

Let me know if the above doesn't make sense, or if you run into
problems.

Thanks for your work,
cheers,
Georg

Re: RFS: facterdb and ruby-rspec-puppet-facts

[Georg Faerber]

Hi,

On 21-08-21 19:21:26, Gabriel Filion wrote:
> Today I've worked on fixing tests for autopkgtest for both facterdb
> and ruby-rspec-puppet-facts.
> 
> Since both of them never made it to testing (because of the failing
> autopkgtest), I've also decided to upgrade both of them to the current
> latest upstream release.

Thanks for this.

> Could someone please review my work and help me out with upload to
> debian archive? I'm neither a DD nor a DM so I can't send there
> myself.
> 
>  * https://salsa.debian.org/ruby-team/facterdb
>  * https://salsa.debian.org/ruby-team/ruby-rspec-puppet-facts

It seems that the 'pristine-tar' branches of both projects are not
current: the latest upstream version is missing. Could you push these
accordingly, and ping me afterwards? I'll have a look, then.

Cheers,
Georg

Re: RFS: upgrade ruby-hitimes to 2.0.0

[Georg Faerber]

Hi,

Daniel, as you did the last upload of ruby-hitimes, would you mind to
have a look?

On 21-08-21 19:12:25, Gabriel Filion wrote:
> Since the package I'm working on, puppet-development-kit, requires a
> more recent version of ruby-hitimes I've worked on importing the
> latest upstream release, 2.0.0.
> 
> Since I'm not a debian developer I would need someone to review my
> work before sending it out the debian archive.
> 
> This package was created by someone else than me so I've pushed the
> work on this new upstream release in a fork in my account in order to
> avoid stepping on someone else's toes in the main repository.
> 
> I've created a merge request -- as is stated in the request it would
> also require for the upstream branch to be pulled from my repository:
> 
> https://salsa.debian.org/ruby-team/ruby-hitimes/-/merge_requests/1
> 
> Could someone review my work on this package upgrade and either send
> me comments about things to fix or merge my work?

Cheers,
Georg

Re: RFS: resending vagrant-librarian-puppet to unstable

[Georg Faerber]

Hi,

On 21-08-21 19:41:24, Gabriel Filion wrote:
> One of my packages was bumped out of testing during the freeze because
> of a dependency problem in one of its requirements, ruby-puppet-forge
> (e.g.  #978228)

This bug is still open, and due to its severity blocking migration. If
this is not of concern anymore, please close the bug accordingly.

> I've just looked at the state of things and if I understand correctly,
> the dependency issues were fixed in #976270
> 
> So normally by now we should be able to simply resend the package
> vagrant-librarian-puppet to have it automatically migrate to testing
> again.

We can't 'resend' a package, because it's already there.

What we could do is to upload 0.9.2-3, which would probably be a good
idea anyway, as there are some commits available in the repo which would
be good to make available.

Would you be up to prepare such a new release, and document the changes
in d/changelog? If so, please ping me afterwards, and I'll handle the
upload.

Cheers,
Georg

Re: RFS: facterdb and ruby-rspec-puppet-facts

[Georg Faerber]

Hi,

On 21-09-07 18:43:58, Gabriel Filion wrote:
> oh no, I'm embarrassed to have forgotten this. the "upstream" branch
> was also missing.
> 
> I've pushed both branches to both repositories.

Took a while, but I've uploaded both now to unstable.

Cheers,
Georg

Re: Ruby team BoF at DebConf 22

[Georg Faerber]

Hi all,

On 22-04-11 12:22:24, 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 won't attend, but will read minutes. Have fun!

Cheers,
Georg

Re: Gitlab packaging project funding status changed.

[Georg Faerber]

Hi,

On 22-06-28 18:37:27, Pirate Praveen wrote:
> 

tells:

[...]
Gitlab Inc sponsored work on this project for 6+ years until recently.
Now we are looking for the community to support it

Did GitLab Inc. announce in public that they're not sponsoring this work
anymore? Besides, what's the reasoning of this decision, if any?

Thanks,
Georg

Bug#1009775: ITP: ruby-net-smtp -- library to send Internet mail via SMTP, the Simple Mail Transfer Protocol

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-ruby@lists.debian.org
Control: affects -1 schleuder
Control: block -1 by 1009774

Package name: ruby-net-smtp
Version : 0.3.1
Upstream Author : Yukihiro Matsumoto, Minero Aoki
URL : https://github.com/ruby/net-smtp
License : BSD-2-clause
Programming Lang: Ruby
Description : library to send Internet mail via SMTP, the Simple Mail 
Transfer Protocol

This package will provide functionality to send Internet mail via SMTP,
the Simple Mail Transfer Protocol. It used to be part of the Ruby
standard library before Ruby 3.1, and was extracted to a standalone
package.

It depends on ruby-net-protocol.

This package will be maintained within the Debian Ruby team.

Bug#1009774: ITP: ruby-net-protocol -- Internal class for the other net-* libraries

[Georg Faerber]

Package: wnpp
Owner: Georg Faerber 
Severity: wishlist
X-Debbugs-CC: debian-ruby@lists.debian.org
Control: affects -1 schleuder

Package name: ruby-net-protocol
Version : 0.1.3
Upstream Author : Yukihiro Matsumoto, Minero Aoki
URL : https://github.com/ruby/net-protocol
License : BSD-2-clause
Programming Lang: Ruby
Description : internal class for the other net-* libraries

This package will provide an internal class for the other net-*
libraries, for example ruby-net-smtp. It used to be part of the Ruby
standard library before Ruby 3.1, and was extracted to a standalone
package.

It will become a dependency of ruby-net-smtp.

This package will be maintained within the Debian Ruby team.

RFC: rails: bookworm-pu: ruby-activerecord vs ruby-arel [was: RFC: ruby-arel: obsolete, remove?]

[Georg Faerber]

Dear team,

I recently uploaded rails 2:6.1.7.3+dfsg-2 to unstable [1] with the
following change:

  * debian/control:
- Declare that ruby-activerecord breaks and replaces ruby-arel:
  it was merged five years ago, is therefore obsolete and to be
  removed. (Closes: #1038935)

Please see the bug for details.

I intend to do a bookworm-pu with the same change, to get ruby-arel
removed afterwards.

Is this fine with you? Do you see any potential problems?

Thanks so much in advance,
cheers,
Georg


[1] 
https://tracker.debian.org/news/1439401/accepted-rails-26173dfsg-2-source-into-unstable/

Re: RFC: rails: bookworm-pu: ruby-activerecord vs ruby-arel [was: RFC: ruby-arel: obsolete, remove?]

[Georg Faerber]

Dear team,

Any comments on the mail below?

Thanks,
Georg

On 23-07-29 13:00:20, Georg Faerber wrote:
> Dear team,
> 
> I recently uploaded rails 2:6.1.7.3+dfsg-2 to unstable [1] with the
> following change:
> 
>   * debian/control:
> - Declare that ruby-activerecord breaks and replaces ruby-arel:
>   it was merged five years ago, is therefore obsolete and to be
>   removed. (Closes: #1038935)
> 
> Please see the bug for details.
> 
> I intend to do a bookworm-pu with the same change, to get ruby-arel
> removed afterwards.
> 
> Is this fine with you? Do you see any potential problems?
> 
> Thanks so much in advance,
> cheers,
> Georg
> 
> 
> [1] 
> https://tracker.debian.org/news/1439401/accepted-rails-26173dfsg-2-source-into-unstable/
> 

RFC: ruby-arel: obsolete, remove?

[Georg Faerber]

Hi all,

It seems that #1038935 is happening if ruby-arel is installed.

Looking at ruby-arel:

Upstream tells, since 2018/04/24 [1]:
  
  Arel is now bundled in the Active Record gem, and maintained in the
  rails/rails repository.

It seems it's only still required by ruby-premailer-rails 1.10.3-3, as
present in the archive currently. Upstream doesn't mention it in the
current version 1.12.0 [2].

If ruby-premailer-rails would be updated accordingly, I guess ruby-arel
could be removed -- what do you think?

Cheers,
Georg


[1] https://github.com/rails/arel
[2] 
https://github.com/fphilipe/premailer-rails/blob/v1.12.0/premailer-rails.gemspec