Re: name transition of an application implemented in Ruby
On Tue, 17 Oct 2023 19:55:45 -0300 Antonio Terceiro wrote: > On Mon, Oct 16, 2023 at 08:25:30PM +0200, Norwid Behrnd wrote: > > Dear Antonio, > > > > Initially, package `ruby-gem` was assembled by `gem2deb` which is why I > > assume > > it were acceptable to retain a name reflecting the language of > > implementation > > in the name of the repository. Meanwhile, the RFS on mentors provides a > > .deb > > which yields a package by name of `mdl` only. The syntax engaged relies on > > the > > example of Debian's Policy Manual (section 7.6.2) to remove (if existing) > > earlier versions of the package on the fly with the elder name by a pattern > > of > > > > ``` > > Provides: new_name > > Conflicts: old_name > > Replaces: old_name > > ``` > > > > in file /debian/control. > > > > As far as currently understood, this lifts the need need to rename many > > files/the repository, or to submit the package for review as an entirely new > > one your suggestion would require. > > > > Do you think the package qualifies now as fit for upload? > > Any new package, source or binary, requires a pass through NEW. i.e. if > you keep the source package name (ruby-mdl), but add a new binary > package (mdl), it has to go through NEW anyway. > > IMO it's better to save everyone's time and do that a single time; this > is why I'm suggesting to just uploading a single new source package that > provides both the new binary and the transitional package to supersede > the old binary package. Now that I see the point I agree with you. The syntax checker was split a into transition / dummy package of old name `ruby-mdl` https://mentors.debian.net/package/ruby-mdl/ https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.12.0-4.dsc to relay to a new and separate `mdl` https://mentors.debian.net/package/mdl/ https://mentors.debian.net/debian/pool/main/m/mdl/mdl_0.13.0-1.dsc -- only the later to contain the additional/new functionality.
Re: RFS: ruby-health-check 3.1.0
Hi, On Sun, 8 Oct 2023 15:07:10 +0100 Oyindamola Olatunji wrote: > Hi, > > The following packages are ready to be uploaded (I also verified the > points listed on > http://wiki.debian.org/Teams/Ruby/Packaging#Requesting_Sponsorship). > > The current version is 3.0.0 > Could you please sponsor them? > > ruby-health-check 3.1.0 > My salsa repo: https://salsa.debian.org/ikeadeoyin/ruby-health-check > > Thank you! > Oyindamola Olatunji is there a particular reason why your contribution (so far) does not show up on mentors.debian.net? This yields a brief summary about checks run automatically which can be both useful for you (sometimes, an update requires multiple increments [and hence intermediate uploads]) to eventually obtain a package good enough; hence, you obtain early a feedback when items once marked as red errors, or yellow warnings eventually turn «green». And potential sponsors can assist you by comments, too. As an example currently seeking a review, see my RFS on https://mentors.debian.net/package/ruby-mdl/ Regards, Norwid
name transition of an application implemented in Ruby
Dear subscribers,
I seek assistance to rename an application in Ruby, especially the sequence to
file a RFS.
Just prior to the freeze of Debian bookworm, I packaged `ruby-mdl` from
rubygems with `gem2deb`. Though it was accepted, Daniel Leidert and one
sponsor of the package recommended to to consider a different name of the
package because it isn't a library, but an application; a task better
postponed for the time after the release of `bookworm`.
There are two questions building on top of each other:
+ Because a new version 0.13.0 was released on rubygems, I started to prepare a
new package for Debian[1] and equally wish to improve this detail now. Based
on repology.org,[2] plain `mdl` seems to be a name suitable. Reading about
the documented «Transition package method»,[3] I would have to replace the
currently used file `/debian/control` (copied below) by a new one (copied
below) for one RFS, commit the changes to salsa, build, sign, dput as usual.
Once this hurdle is taken, I would file a subsequent separate RFS for a dummy
package. Any objections for this part?
+ Second, I found `equivs` described elsewhere[4] to prepare a dummy package
and I am able to replicate their example with their control file (`equivs`
version 2.3.1). However, a copy my dummy control file as a plain file in a
separate empty folder only yields
```shell
$ equivs-build ./control
syntax error in control file: This is a transitional package. It can safely be
removed. ```
To me, `Depends: mdl, ${misc:Depends}` reads like I should thus i) await
a successful RFS of `ruby-mdl` 0.13.0 as `mdl` to then ii) copy my control
file as `/debian/control` into the folder which was used to prepare the
package `mdl`. Really this simple (no commit to salsa.debian.org, but sign
and dput to mentors.debian.net as usual)?
With regards,
Norwid Behrnd
[1] https://mentors.debian.net/package/ruby-mdl/
[2] https://repology.org/project/mdl-markdownlint/packages
[3] https://wiki.debian.org/RenamingPackages
[4] https://wiki.debian.org/Packaging/HackingDependencies
+ `/debian/control` as used so far:
```
Source: ruby-mdl
Section: text
Priority: optional
Maintainer: Norwid Behrnd
Build-Depends: debhelper-compat (= 13),
gem2deb (>= 1),
ruby (>= 2.7),
ruby-kramdown (>= 2.3),
ruby-kramdown-parser-gfm (>= 1.1),
ruby-mixlib-cli (<< 2.2),
ruby-mixlib-cli (>= 2.1.1),
ruby-mixlib-config (<< 4),
ruby-mixlib-config (>= 2.2.1),
ruby-mixlib-shellout
Standards-Version: 4.6.2
Vcs-Git: https://salsa.debian.org/nbehrnd/ruby-mdl/ruby-mdl.git
Vcs-Browser: https://salsa.debian.org/nbehrnd/ruby-mdl
Homepage: https://github.com/markdownlint/markdownlint
Testsuite: autopkgtest-pkg-ruby
Rules-Requires-Root: no
Package: ruby-mdl
Architecture: all
Depends: ${misc:Depends},
${ruby:Depends},
${shlibs:Depends}
Description: Markdown lint tool
ruby-mdl checks an individual markdown file, or a directory of markdown
files against a set of 42 rules for syntax consistency. In its report back
to the CLI, the Ruby based implementation reports the line(s) with an issue
identified and how to improve it.
```
+ `/debian/control` which would be used to transition to a new name
```
Source: ruby-mdl
Section: text
Priority: optional
Maintainer: Norwid Behrnd
Build-Depends: debhelper-compat (= 13),
gem2deb (>= 1),
ruby (>= 2.7),
ruby-kramdown (>= 2.3),
ruby-kramdown-parser-gfm (>= 1.1),
ruby-mixlib-cli (<< 2.2),
ruby-mixlib-cli (>= 2.1.1),
ruby-mixlib-config (<< 4),
ruby-mixlib-config (>= 2.2.1),
ruby-mixlib-shellout
Standards-Version: 4.6.2
Vcs-Git: https://salsa.debian.org/nbehrnd/ruby-mdl/ruby-mdl.git
Vcs-Browser: https://salsa.debian.org/nbehrnd/ruby-mdl
Homepage: https://github.com/markdownlint/markdownlint
Testsuite: autopkgtest-pkg-ruby
Rules-Requires-Root: no
Package: mdl
Replaces: ruby-mdl (<< 0.12.0-3)
Breaks: ruby-mdl (<< 0.12.0-3)
Architecture: all
Depends: ${misc:Depends},
${ruby:Depends},
${shlibs:Depends}
Description: Markdown lint tool
mdl checks an individual markdown file, or a directory of markdown
files against a set of 42 rules for syntax consistency. In its report back
to the CLI, the Ruby based implementation reports the line(s) with an issue
identified and how to improve it.
```
+ `debian/control` as so far understood to prepare the dummy package
```
Package: ruby-mdl
Depends: mdl, ${misc:Depends}
Architecture: all
Priority: optional
Section: oldlibs
Description: transitional package
This is a transitional package. It can safely be removed.
```
END
RFH: reliable renaming `ruby-mdl` to `markdownlint
Dear subscribers, for `ruby-mdl` accepted into branch `testing`, while retaining the commit log to Debian, my aim is to adjust its package name into `markdownlint` because this corresponds better its character as an application. I seek advice form here if the following approach (so far neither commited to salsa, nor uploaded to the debian.mentors page) is + permissible now, on top of other adjustments in /debian/upstream/metadata, or debian/upstream/metadata, for example, or better is submitted as a separate subsequent release to Debian. There already is an upload to mentors about the changes to the files around `markdownlint` *excluding* the name change, thus I can file a RFS to account only on these "internal adjustments" only, too. + how the provision of a new name for the .deb eventually built can be improved Because it is about an application implemented in Ruby, I assumed this mailing list might be more appropriate than the one of debian.mentors. If wrong with this line of thought, I can transfer the question to the other address. Ad rem. Based on a presentation by Sebastian Reichel, I infer the new entry in `/debian/changelog` has to mention `markdownlint` instead the `ruby-mdl` used so far. Simultaneously, `package` in file `/debian/control/` has to carry the new name, too. Contrasting to my anticipation, a new run with `dpkg-buildpackage` fails reporting ``` $ dpkg-buildpackage [...] dpkg-source: error: source package has two conflicting values - ruby-mdl and markdownlint dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 255 ``` In what appears to me as problematic approach *potentially* unkowinly breaking some stuff, I then altered `source` in /debian/control to `markdownlint`, copy- pasted `ruby-mdl_0.12.0.orig.tar.gz` as `markdownlint_0.12.0.orig.tar.gz`, removed `debian/ruby-mdl/usr/share/man/man1/mdl.1.gz` as well as `debian/ruby-mdl/usr/share/doc/ruby-mdl/changelog.Debian.gz`. For an already existing `/debian/mdl.1` I created a copy as `/debian/markdownlint.1`, and the same for `debian/ruby-mdl.manpages` as `debian/markdownlint.manpages`, the later adjusted to indicate the new path (`debian/markdownlint.1`). After a run of `dpkg-buildpackage` and `lintian`, file `debian/ruby-mdl.substvars` was removed (because of lintian's report). From what I can see by now, `dpkg-buildpackage` is able to generate the usual files ``` $ ls markdown* markdownlint_0.12.0-3_all.deb markdownlint_0.12.0-3.debian.tar.xz markdownlint_0.12.0-3_amd64.buildinfo markdownlint_0.12.0-3.dsc markdownlint_0.12.0-3_amd64.changesmarkdownlint_0.12.0.orig.tar.gz ``` and the .deb is functional both for an installation on a spare partition of Xubuntu 22.04.1 (not used for the packaging) then appearing as `markdownlint` in `synaptic` as well as for ``` $ dpkg --info markdownlint_0.12.0-3_all.deb new Debian package, version 2.0. size 18892 bytes: control archive=1240 bytes. 691 bytes,14 lines control 1833 bytes,19 lines md5sums Package: markdownlint Version: 0.12.0-3 Architecture: all Maintainer: Norwid Behrnd Installed-Size: 86 Depends: ruby, ruby-kramdown (>= 2.3), ruby-kramdown-parser-gfm (>= 1.1), ruby-mixlib-cli (>= 2.1.1), ruby-mixlib-config (>= 2.2.1), ruby-mixlib-config (<< 4), ruby-mixlib-shellout Section: devel Priority: optional Homepage: https://github.com/markdownlint/markdownlint Description: Markdown lint tool Markdownlint checks an individual markdown file, or a directory of markdown files against a set of 47 rules for syntax consistency. In its report back to the CLI, the Ruby based implementation reports the line(s) with an issue identified and how to improve it. ``` in Debian. On the other hand, `lintian` newly states ``` markdownlint: no-manual-page [usr/bin/mdl] ``` as warning though there is a man page included (`markdownlint.1.gz`): ``` $ dpkg -c ./markdownlint_0.12.0-3_all.deb drwxr-xr-x root/root 0 2023-01-28 16:54 ./ drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/ drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/bin/ -rwxr-xr-x root/root 521 2023-01-28 16:54 ./usr/bin/mdl drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/share/ drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/share/doc/ drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/share/doc/markdownlint/ -rw-r--r-- root/root 267 2023-01-28 16:54 ./usr/share/doc/markdownlint/changelog.Debian.gz -rw-r--r-- root/root 4456 2022-12-30 23:43 ./usr/share/doc/markdownlint/copyright drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/share/man/ drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/share/man/man1/ -rw-r--r-- root/root 1462 2023-01-28 16:54 ./usr/share/man/man1/markdownlint.1.gz drwxr-xr-x root/root 0 2023-01-28 16:54 ./usr/share/rubygems-integration/ drwxr-xr-x root/root 0 2023-01-28 16:54 ./u
Re: adjustment for `ruby-mdl`
@Daniel with additional reflection, I assume one could proceed in the sequence outlined below. It aims to balance Debian Team Ruby's focus to revise its packages prior to the freeze of `bookworm`, with some progress for `ruby-mdl`. * With the source-only upload in preparation, `ruby-mdl` could advance into `testing` on condition I edit entry `maintainer` (for the Debian package), at least for now replace `Debian Ruby Team` by me. Then, the package no longer is frozen in `unstable` where -- as by today -- it is for 12 days. * The rename of the package,[1] maybe with the split into a binary and a libary you suggested, then is postponed for a package `0.12.0-3` (likely) for the time *after* February. Objections by anyone? Regards, Norwid [1] https://wiki.debian.org/RenamingPackages, Transition package method
Re: adjustment for `ruby-mdl`
Hello Daniel, thank your for your note I like to reply to. * To name "the thing". Thankfully, there is `gem2deb` to collect and organize the relevant data from rubygems and `ruby-mdl` is the name suggested by this implementation. I don't mind the result by `gem2deb` requires additional edit (some of the points addressed by the documentation), perhaps including a new name *of the package* in Debian. (E.g., in its documentation, the validator `pytest` for Python is called by `pytest`. With the advent of Python 3, Debian & Ubuntu family currently name it `python3-pytest` as package, and the call from the CLI is `pytest-3` regardless if there (still) is some remain of Python 2 in the hosting installation, or not.) Open to an adjustment, I like `ruby-mdl` as package name because it states the language of implementation, hence a pattern which allows others an implementation in their language of choice (e.g., `python3-markdownlint`). It equally is a short name and `mdl` already shows the call sign from the CLI. On the other hand, `markdownlinter` would introduce a name different to the project's name .and. part of the address on GitHub. * Split into a binary part and a library part. Because `ruby-mdl` is the first time I package a .deb, this exceeds my expertise. Do you recommend a particular resource to get familiar with this procedure? Likely related to this suggest is the information (i.e., low severity) `application-in-library-section` broadcast by `lintian`, prior signing the changes file and to engaging `dput mentors`. * Joining the Debian Ruby team. OK, it is convincing this could facilitate much; possibly including an adjustment of the name space (if it is an issue). I file a separate petition of admission to the group (*beyond* the subscription to the mailing list). * The copyright issue. For one I assume each contribution to `markdownlint` recognizes the choice for MIT because the pick for a license known to GitHub simultaneously adds the tag to the web site .and. a `LICENSE.txt` to the project for you. For two, the project discerns between contributors and maintainers (to `markdownlint`; three considered active [Mark Harrison no longer is one of them]) without an explicit note I spot (so far) "for any contribution to us, you transfer your copyright to us" as with publishers. Because copyright may differ by locale, I assumed it were better to err and to list all, than omitting one. (Because the relevant git archaeology was/is relayed to two scripts to put elsewhere, the extraction doesn't take much time, either.) Regards, Norwid
adjustment for `ruby-mdl`
Dear subscribers, recently, I packaged `markdownlint`,[1] a syntax checker for markdown implemented in Ruby, for Debian as `ruby-mdl`. Thanks to a sponsor, there was an initial upload to Debian's package tracker,[2] too. A new upload (source-only upload) was prepared[3] and as Bastian Germann suggests, it possibly were better to move the relevant data from https://salsa.debian.org/nbehrnd/ruby-mdl to an address like e.g., https://salsa.debian.org/ruby-team/ruby-mdl With the manual about packaging Ruby gems for Debian[4] and gem2deb,[5] I request advice how to proceed for such an adjustment, i.e. a merge into your git repository? Or, does it suffice to share the knowledge with you that there is a .deb `ruby-mdl` to prevent an other of you prepares a .deb of this name, and then to continue hosting the relevant data in the salsa instance under my name? In retrospect, there equally are two questions: * Because `ruby-mdl` is my first contribution leading to a .deb on Debian, I'm an uploader. Does assembling the necessary data equate that a maintainer of this .deb, i.e. should I/should I equally adjust this entry for the Debian package tracker? * GitHub's project page about `markdownlint` counts 52 contributors to `markdownlint`. To extract their names and the first year of contribution, I wrote two small scripts to assist the adjustment of file `/debian/copyright`. Now, though `gem2deb` creates the three git branches of `master`, `pristine-tar`, and `upstream`, does the creation of an extra branch interfere badly with the intended layout of Ruby gem packages for Debian? Because it does not change the source code of the Ruby code (compared to what `gem2deb` fetches from the rubygems database) it does not appear like a bug fix `upstream` should include before merging the results into `master`. On the other hand, I would welcome if the repository to package `markdownlint` as `ruby-mdl` for Debian would include these two short extra codes (e.g., an other user might be interested to build the package when `markdownlint` on rubygems has been updated). What would be your advise on this point? With regards, Norwid Behrnd [1] https://github.com/markdownlint/markdownlint/ [2] https://tracker.debian.org/pkg/ruby-mdl [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029033 [4] https://wiki.debian.org/Teams/Ruby/Packaging#Packaging_new_gems_from_scratch [4]https://wiki.debian.org/Teams/Ruby/Packaging/gem2deb
landing page, perhaps a missing cross-link
Dear maintainer of the web site https://wiki.debian.org/Teams/Ruby#Packaging section 3.5 Packaging. The bold introduction reads "Workflow about packaging new Ruby based software for Debian can be found here." where "here" offers a cross-link. In the next section "Maintaining", the last phrase is "To know about updating a package and uploading it, visit here." as if "here" once was intended to equally redirect to an other web page. At present, "here" however does not link (any more) to an other resource. Maybe it was https://wiki.debian.org/Teams/Ruby/Packaging currently used in the phrase above, or the edit of the text is incomplete. The observation refers to the page in the modification by 2021-06-19 14:38:31. Regards, --- Norwid Behrnd
Building with gem2deb points to a removed package
Dear authors of guide «Bulidng with gem2deb»,[1] the lower part of this guide (last revision by 2022-06-17) recommends to check if the copyright information is set correctly and points to package `license-reconcile`. However, according to the package tracker,[2] this very package no longer is available for Debian 12/bookworm (testing), nor unstable for more than one year. Apparently, with `gem2deb`, `dpkg-buildpackage`, and `lintian`, there already is a check in place. Can the guide be updated accordingly? With regards, Norwid [1] https://wiki.debian.org/Teams/Ruby/Packaging/gem2deb [2] https://tracker.debian.org/pkg/license-reconcile
adjustments after running gem2deb
Dear subscribers, while preparing the submission of a Ruby application[1] as a .deb (prepared by gem2deb), I would like to clarify a few details in the files one has to adjust. At present, the application (MIT license) got 52 contributors; among them, there are four current and two past maintainers. The initial contributor is one of the past maintainers. After reading two guides[2, 3], my three questions are: + file /debian/copyright, entry upstream-contact: The script based generation entered the email of the initial contributor of the project; maybe this was a piece of information extracted from the project's already existing copyright file. However, wouldn't it be more useful to insert either + a contact to one of the current maintainers, + a maintainer of the entry on https://rubygems.org/gems/mdl gem2deb uses, or + the address of the person submitting the .deb package to Debian, because file /debian/control includes an entry uploaders? + file /debian/copyright, entry copyright: The pattern suggested is ``` ``` Does it suffice to sort this list in ascending order of the year of each contributor's first contribution? + file /debian/control, entry maintainer: By default, the Debian Ruby Team is added. Should I substitute this by name and email address of the four current maintainers of the project? With regards, Norwid [1] https://github.com/markdownlint/markdownlint/ [2] https://wiki.debian.org/Teams/Ruby/Packaging [3] https://wiki.debian.org/Teams/Ruby/Packaging/gem2deb
