RFS: ruby-tty-screen, ruby-tty-reader and ruby-tty-prompt
Hello, I've just sent three more packages to salsa: ruby-tty-screen, ruby-tty-reader and ruby-tty-prompt. Could someone please review my work to make sure I haven't done something wrong or forgotten details? With those three, the list of "easy" packages in my project of getting puppet-development-kit in debian will be exhausted. For the next steps I will have to ask some questions to the team. Still, if the current three can get all cleaned up and readied up for the debian archive, we will have 11 of the 18 required new packages! (thanks to Cédric for sending out the first four of those. it gave me the motivation I needed to jump in :) ) Thanks! signature.asc Description: OpenPGP digital signature
Re: RM chef?
Hello, On Sun, Feb 09, 2020 at 02:04:45AM -0500, Utkarsh Gupta wrote: > Hi all, > > 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? > (it also fails to build against Ruby 2.7) > > If chef is removed, the following packages can be safely RM'ed, too: > - foodcritic > - ruby-cheffish > - ruby-knife-acl > - ruby-comat-resource I and Stefano (added to cc:) have been maintaining chef during the last few years. At some point we will have to figure out what to do with it going forward with it, but I don't think we want it to be removed. Even if we do end up packaging cinc (tinc is something else it seems), "chef" will be a transition package to that at least for bullseye. It currently has RC bugs so should be removed from testing at some point if we aren't able to do something about it soon enough, and it won't block anything eles then. signature.asc Description: PGP signature
Re: debian/salsa-ci.yml created by gem2deb
Am Mittwoch, den 12.02.2020, 16:11 + schrieb 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!
Unfortunately it doesn't work. It seems we can only create .gitattributes in
create_debian_boilerplates(). But I don't see a way to ship it, because its
contents will prevent it and salsa-ci.yml from being exported.
Maybe something like for create_debian_boilerplates():
unless File.exist?('debian/.gitattributes')
File.write("debian/.gitattributes", [".gitattributes", "gbp.conf",
"salsa-ci.yml"].map { |f| "#{f} export-ignore" }.join("\n"))
end
If you have a better idea please let me know.
Regards, Daniel
signature.asc
Description: This is a digitally signed message part
Re: debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]
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!
AW:debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]
Hi guys,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 :)Regards, Daniel Ursprüngliche Nachricht Von: Utkarsh Gupta Datum: Mi., 12. Feb. 2020, 01:27An: debian-ruby Betreff: Re: debian/salsa-ci.yml created by gem2deb [was: Re: RFS: ruby-wisper and ruby-necromancer]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: RM request for coquelicot and its reverse deps?
Hi! On 12/02/2020 00:42, Georg Faerber wrote: > 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 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. 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. Thanks for all your work, Lunar
