Bug 1343977 - Review Request: rubygem-asciidoctor-mallard - A Project Mallard converter for AsciiDoc [NEEDINFO]
Summary: Review Request: rubygem-asciidoctor-mallard - A Project Mallard converter fo...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: FE-NEEDSPONSOR
Blocks: 1346060
TreeView+ depends on / blocked
 
Reported: 2016-06-08 12:28 UTC by Tummala Dhanvi (c0mrad3)
Modified: 2020-07-10 00:54 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
package-review: needinfo? (dhanvicse)


Attachments (Terms of Use)

Comment 1 Mario Blättermann 2016-07-10 19:53:11 UTC
The spec file location is 404.

Comment 2 Tummala Dhanvi (c0mrad3) 2016-07-15 17:02:26 UTC
The Spec URL is now not showing a 404, just to be sure I have added them else where 


Spec URL : https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/asciidoctor-mallard.spec 

SRPM URL : https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/rubygem-asciidoctor-mallard-0.1.0.dev-1.fc24.src.rpm 

Description: An extension for Asciidoctor that converts AsciiDoc documents to Mallard 1.0

Fedora Account System Username: dhanvi

Comment 3 Vít Ondruch 2016-09-16 13:39:09 UTC
Hi Tummala,

This looks to be output of gem2rpm without any modification. Unfortunately, this is not acceptable for official review and I can spot several issues on the first look:

1. The .spec file naming.
2. Test suite is not executed.
3. License is not marked by %license macro.
4. License file is not included in the main package.

I'd appreciate if you can try to do package self review prior sending package for official review [1].

Actually, it does not look you are sponsored into package group yet, so I suggest you to follow these instructions [2], where you can find plenty of useful links.



[1] http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
[2] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Comment 4 William Moreno 2016-10-10 23:07:00 UTC
Hi dhanvi, there is a lot of time since last update, do you want to continue with this review? If not I can take care of it.

Please remenber than acording to the Stalle Package Review process(0) if you do not reponse in one week I can close this review a open a new one.

Regards

0: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

Comment 5 Tummala Dhanvi (c0mrad3) 2016-10-14 13:26:27 UTC
(In reply to William Moreno from comment #4)
> Hi dhanvi, there is a lot of time since last update, do you want to continue
> with this review? If not I can take care of it.

Hello William, I would like to continue with this review, but I might need your help for the same.

> 
> Please remenber than acording to the Stalle Package Review process(0) if you
> do not reponse in one week I can close this review a open a new one.

I will update the spec file and continue with the feedback process before the end of this week 

> 
> Regards
> 
> 0: https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

Comment 7 Vít Ondruch 2016-10-25 16:05:02 UTC
(In reply to Tummala Dhanvi (c0mrad3) from comment #6)
Thx, but I still can't see any test suite executed. Is there some reason for that? Please note that in case of Ruby packages, the test suite is the only thing which can assure that the package works. There is no compiler which would at least partly cover your back ...

Comment 8 Tummala Dhanvi (c0mrad3) 2016-11-07 12:58:22 UTC
I have added the testing part by adding this line 

ruby -Ilib -e 'Dir.glob "./test/*.rb"' 

Hope it should do it. 


Updated packages here https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/

Comment 9 Vít Ondruch 2016-11-08 11:01:37 UTC
* Source of the gem?
  - Where did you get the source gem? It is not available on rubygems.org as far
    as I can tell, neither you documented anywhere how you obtained it.

* Package naming
  - Please rename the .spec file to rubygem-asciidoctor-mallar.spec to be in
    line with the guidelines [1].

* Package version
  - Please use proper version scheme. The package version should be probably
    just "0.1.0" while the release should be "0.1.dev".
  - The versioning is documented in detail here [2].

* Duplicated license
  - You should not include the "%license LICENSE.adoc". Please keep just "%doc
    %{gem_instdir}/LICENSE.adoc" in the main package (and change the %doc to
    %license of course).

* Unneeded requires
  - You probably don't need to include "Requires: rubygem-thread_safe". Runtime
    requires should be autogenerated during build process.
  - Not sure what is the "pintail" good for. Some explaining hint above would
    come handy.

* Doc subpackage
  - It is good habit to keep the documentation in -doc subpackage.

* Test suite
  - Well, the line you used is just part of the story. You can see that there
    is nothing which would indicated, that the test suite was executed. You
    should use following line:

```
ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
```

  - Unfortunately, there seems to be dependency on asciidoctor-doctest, which
    is not in Fedora yet. Since it has quite lot of dependencies, it is
    probably not worth of packaging ATM, but all this should be documented.
  - Instead of execution of test suite, you should consider to provide at least
    some sanity test, e.g. try to convert some document from AsciiDoc to
    Mallard using the %{gem_instdir}/bin/asciidoctor-mallard

* Bump release between review iteration
  - It is good habit to bump the package release each review iteration.



[1] https://fedoraproject.org/wiki/Packaging:Ruby#Naming_Guidelines
[2] https://fedoraproject.org/wiki/Packaging:Versioning#Pre-Release_packages

Comment 10 Tummala Dhanvi (c0mrad3) 2016-11-11 15:32:31 UTC
(In reply to Vít Ondruch from comment #9)
> * Source of the gem?
>   - Where did you get the source gem? It is not available on rubygems.org as
> far
>     as I can tell, neither you documented anywhere how you obtained it.
The spec file contained the url of the github repo https://github.com/asciidoctor/asciidoctor-mallard

I have built the gem my self using `gem build *.gemspec`
> 
> * Package naming
>   - Please rename the .spec file to rubygem-asciidoctor-mallar.spec to be in
>     line with the guidelines [1].
Updated
> 
> * Package version
>   - Please use proper version scheme. The package version should be probably
>     just "0.1.0" while the release should be "0.1.dev".
>   - The versioning is documented in detail here [2].
I upstream had it versioning like that https://github.com/asciidoctor/asciidoctor-mallard/blob/master/lib/asciidoctor-mallard/version.rb

but I have updated it to 0.1.dev
> 
> * Duplicated license
>   - You should not include the "%license LICENSE.adoc". Please keep just
> "%doc
>     %{gem_instdir}/LICENSE.adoc" in the main package (and change the %doc to
>     %license of course).

Done

> * Unneeded requires
>   - You probably don't need to include "Requires: rubygem-thread_safe".
> Runtime
>     requires should be autogenerated during build process.

Done

>   - Not sure what is the "pintail" good for. Some explaining hint above would
>     come handy.
pintail is actually not required

Pintail is a tool to convert mallard to html (https://github.com/projectmallard/pintail)

This package converts asciidoc to mallard  
> 
> * Doc subpackage
>   - It is good habit to keep the documentation in -doc subpackage.
Done
> 
> * Test suite
>   - Well, the line you used is just part of the story. You can see that there
>     is nothing which would indicated, that the test suite was executed. You
>     should use following line:
> 
> ```
> ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
> ```
> 
>   - Unfortunately, there seems to be dependency on asciidoctor-doctest, which
>     is not in Fedora yet. Since it has quite lot of dependencies, it is
>     probably not worth of packaging ATM, but all this should be documented.
>   - Instead of execution of test suite, you should consider to provide at
> least
>     some sanity test, e.g. try to convert some document from AsciiDoc to
>     Mallard using the %{gem_instdir}/bin/asciidoctor-mallard
> 
Can you please explain me a bit more about how to get it right ? 

URL: https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/

Comment 11 Vít Ondruch 2016-11-14 14:15:01 UTC
(In reply to Tummala Dhanvi (c0mrad3) from comment #10)
> (In reply to Vít Ondruch from comment #9)
> > * Source of the gem?
> >   - Where did you get the source gem? It is not available on rubygems.org as
> > far
> >     as I can tell, neither you documented anywhere how you obtained it.
> The spec file contained the url of the github repo
> https://github.com/asciidoctor/asciidoctor-mallard
> 
> I have built the gem my self using `gem build *.gemspec`

There are two things here:

1. If you do something special, mainly if the SourceX tag is not link, it is always good idea to describe in comment what you actually did. Some people even prefer to provide script preparing the packages (isn't this documented somewhere in guidelines? Not sure)

2. More importantly, I don't think this is required and that this is right approach here. I would suggest to get the tarball from the GH [1], expand it using %setup macro and that should be everything you have in %prep section. The rest of the package would be the same.

As soon as there is stable version of the gem available on rubygems.org, then you would change the package to use the .gem as a source.



> > * Package version
> >   - Please use proper version scheme. The package version should be probably
> >     just "0.1.0" while the release should be "0.1.dev".
> >   - The versioning is documented in detail here [2].
> I upstream had it versioning like that
> https://github.com/asciidoctor/asciidoctor-mallard/blob/master/lib/
> asciidoctor-mallard/version.rb
> 
> but I have updated it to 0.1.dev

Please read the [2] carefully. You have to ensure update path. E.g. the original VR you used was "0.1.0.dev-1". If the upstream released stable version "0.1.0", your VR would become "0.1.0.dev-1" and this is what RPM thinks about the versions:

```
$ rpmdev-vercmp 0.1.0.dev-1 0.1.0-1
0.1.0.dev-1 > 0.1.0-1
```

That means the newer version would never get installed. Hence I suggested to use just "0.1.0" while the release should be "0.1.dev". In the .spec file, it would look like:

```
Version: 0.1.0
Release: 0.1.dev%{?dist}
```

Which makes the upgrade path correct:

```
$ rpmdev-vercmp 0.1.0-0.1.dev 0.1.0-1
0.1.0-0.1.dev < 0.1.0-1
```

Again, please read the [2] carefully (although I admit it is not easy read, but hopefully this will get simplified in the future).

> > * Test suite
> >   - Well, the line you used is just part of the story. You can see that there
> >     is nothing which would indicated, that the test suite was executed. You
> >     should use following line:
> > 
> > ```
> > ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
> > ```
> > 
> >   - Unfortunately, there seems to be dependency on asciidoctor-doctest, which
> >     is not in Fedora yet. Since it has quite lot of dependencies, it is
> >     probably not worth of packaging ATM, but all this should be documented.
> >   - Instead of execution of test suite, you should consider to provide at
> > least
> >     some sanity test, e.g. try to convert some document from AsciiDoc to
> >     Mallard using the %{gem_instdir}/bin/asciidoctor-mallard
> > 
> Can you please explain me a bit more about how to get it right ? 
> 
> URL: https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/

My idea was to do something as simple as shipping some simple AsciiDoc file as Source1 and trying the conversion, e.g. the %check section could look like:

```
%check
pushd .%{gem_instdir}
# There is no rubygem-asciidoctor-doctest in Fedora yet, which is needed
# for test suite.
# ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'

bin/asciidoctor-mallard %{SOURCE1} -o test.output
popd

```

This is the simplest test you can do, since if the conversion fails for whatever reason, the build should break.

On top of that, you can check for the consistency of the output by calculating hash of the output, e.g. you can add the following line there:

```
sha256sum test.output | grep "870474333c6f4e41238f923f1d27c7688c86b6463db39725e076fc5f05fe2520" 
```

Of course you have to use correct hash, based on the content of the %{SOURCE1} file you are going to use. Or you can choose to test any other bit of the file content, if you consider it important.


BTW just running "bin/asciidoctor-mallard" will fail the build ATM, since there is apparently some bug (undefined method `size' for nil:NilClass).


[1] https://fedoraproject.org/wiki/Packaging:SourceURL#Commit_Revision
[2] https://fedoraproject.org/wiki/Packaging:Versioning#Pre-Release_packages

Comment 12 Tummala Dhanvi (c0mrad3) 2016-11-20 10:50:00 UTC
> 
> 
> > > * Package version
> > >   - Please use proper version scheme. The package version should be probably
> > >     just "0.1.0" while the release should be "0.1.dev".
> > >   - The versioning is documented in detail here [2].
> > I upstream had it versioning like that
> > https://github.com/asciidoctor/asciidoctor-mallard/blob/master/lib/
> > asciidoctor-mallard/version.rb
> > 
> > but I have updated it to 0.1.dev
> 
> Please read the [2] carefully. You have to ensure update path. E.g. the
> original VR you used was "0.1.0.dev-1". If the upstream released stable
> version "0.1.0", your VR would become "0.1.0.dev-1" and this is what RPM
> thinks about the versions:
> 
> ```
> $ rpmdev-vercmp 0.1.0.dev-1 0.1.0-1
> 0.1.0.dev-1 > 0.1.0-1
> ```
> 
> That means the newer version would never get installed. Hence I suggested to
> use just "0.1.0" while the release should be "0.1.dev". In the .spec file,
> it would look like:
> 
> ```
> Version: 0.1.0
> Release: 0.1.dev%{?dist}
> ```
> 
> Which makes the upgrade path correct:
> 
> ```
> $ rpmdev-vercmp 0.1.0-0.1.dev 0.1.0-1
> 0.1.0-0.1.dev < 0.1.0-1
> ```
> 
> Again, please read the [2] carefully (although I admit it is not easy read,
> but hopefully this will get simplified in the future).
Got it right this time!
> 
> > > * Test suite
> > >   - Well, the line you used is just part of the story. You can see that there
> > >     is nothing which would indicated, that the test suite was executed. You
> > >     should use following line:
> > > 
> > > ```
> > > ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
> > > ```
> > > 
> > >   - Unfortunately, there seems to be dependency on asciidoctor-doctest, which
> > >     is not in Fedora yet. Since it has quite lot of dependencies, it is
> > >     probably not worth of packaging ATM, but all this should be documented.
> > >   - Instead of execution of test suite, you should consider to provide at
> > > least
> > >     some sanity test, e.g. try to convert some document from AsciiDoc to
> > >     Mallard using the %{gem_instdir}/bin/asciidoctor-mallard
> > > 
> > Can you please explain me a bit more about how to get it right ? 
> > 
> > URL: https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/
> 
> My idea was to do something as simple as shipping some simple AsciiDoc file
> as Source1 and trying the conversion, e.g. the %check section could look
> like:
> 
> ```
> %check
> pushd .%{gem_instdir}
> # There is no rubygem-asciidoctor-doctest in Fedora yet, which is needed
> # for test suite.
> # ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
> 
> bin/asciidoctor-mallard %{SOURCE1} -o test.output
> popd
> 
> ```
> 
> This is the simplest test you can do, since if the conversion fails for
> whatever reason, the build should break.
> 
> On top of that, you can check for the consistency of the output by
> calculating hash of the output, e.g. you can add the following line there:
> 
> ```
> sha256sum test.output | grep
> "870474333c6f4e41238f923f1d27c7688c86b6463db39725e076fc5f05fe2520" 
> ```
done it using the example given in the README
> 
> Of course you have to use correct hash, based on the content of the
> %{SOURCE1} file you are going to use. Or you can choose to test any other
> bit of the file content, if you consider it important.
> 
> 
> BTW just running "bin/asciidoctor-mallard" will fail the build ATM, since
> there is apparently some bug (undefined method `size' for nil:NilClass).
> 
This might be due to the requirements of rubygem-asciidoctor which I missed, also 

`
ruby ./bin/asciidoctor-mallard
`

works.

URL: https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/

Comment 13 Vít Ondruch 2016-12-06 09:28:09 UTC
(In reply to Tummala Dhanvi (c0mrad3) from comment #12)
> > 
> > 
> > > > * Package version
> > > >   - Please use proper version scheme. The package version should be probably
> > > >     just "0.1.0" while the release should be "0.1.dev".
> > > >   - The versioning is documented in detail here [2].
> > > I upstream had it versioning like that
> > > https://github.com/asciidoctor/asciidoctor-mallard/blob/master/lib/
> > > asciidoctor-mallard/version.rb
> > > 
> > > but I have updated it to 0.1.dev
> > 
> > Please read the [2] carefully. You have to ensure update path. E.g. the
> > original VR you used was "0.1.0.dev-1". If the upstream released stable
> > version "0.1.0", your VR would become "0.1.0.dev-1" and this is what RPM
> > thinks about the versions:
> > 
> > ```
> > $ rpmdev-vercmp 0.1.0.dev-1 0.1.0-1
> > 0.1.0.dev-1 > 0.1.0-1
> > ```
> > 
> > That means the newer version would never get installed. Hence I suggested to
> > use just "0.1.0" while the release should be "0.1.dev". In the .spec file,
> > it would look like:
> > 
> > ```
> > Version: 0.1.0
> > Release: 0.1.dev%{?dist}
> > ```
> > 
> > Which makes the upgrade path correct:
> > 
> > ```
> > $ rpmdev-vercmp 0.1.0-0.1.dev 0.1.0-1
> > 0.1.0-0.1.dev < 0.1.0-1
> > ```
> > 
> > Again, please read the [2] carefully (although I admit it is not easy read,
> > but hopefully this will get simplified in the future).
> Got it right this time!


Yep, LGTM!

But you still should work on the Source package I mentioned in previous step. Please study this [1] to get yourself familiar with git snapshots. This is something I come up with:

```
--- rubygem-asciidoctor-mallard.spec.orig	2016-12-05 14:57:16.684010918 +0100
+++ rubygem-asciidoctor-mallard.spec	2016-12-06 10:23:44.589045687 +0100
@@ -1,14 +1,26 @@
 %global gem_name asciidoctor-mallard
 
+%global commit0 cf5a2a8baf8f54f64af4d0f3eac763e1ca47c917
+%global shortcommit0 %(c=%{commit0}; echo ${c:0:7})
+
+%global	prever .dev
+%global	prerpmver %(echo "%{?prever}" | sed -e 's|\\.||g')
+
+# Modify the standard if we are packaging pre-release version.
+%global gem_instdir %{gem_dir}/gems/%{gem_name}-%{version}%{?prever}
+%global gem_cache %{gem_dir}/cache/%{gem_name}-%{version}%{?prever}.gem
+%global gem_spec %{gem_dir}/specifications/%{gem_name}-%{version}%{?prever}.gemspec
+%global gem_docdir %{gem_dir}/doc/%{gem_name}-%{version}%{?prever}
+
 Name: rubygem-%{gem_name}
 Version: 0.1.0
-Release: 0.1.dev%{?dist}
+Release: %{?prever:0.}1%{?prever:.%{prerpmver}}%{?dist}
 Summary: Converts AsciiDoc documents to Project Mallard format
 
 Group: Development/Languages
 License: MIT
 URL: https://github.com/asciidoctor/asciidoctor-mallard
-Source0: %{gem_name}-%{version}.gem 
+Source0: https://github.com/asciidoctor/asciidoctor-mallard/archive/%{commit0}.tar.gz#/%{name}-%{shortcommit0}.tar.gz
 
 BuildArch: noarch
 BuildRequires: ruby
@@ -30,17 +42,20 @@
 Documentation for %{name}
 
 %prep
-gem unpack %{SOURCE0}
-
-%setup -q -D -T -n  %{gem_name}-%{version}
+%setup -n %{gem_name}-%{commit0}
 
-gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec
+# We don't have git repository, so just collect everything available,
+# except the .gemspec (which is modified by this command and the gem itself.
+sed -i '/s.files/a    \
+  s.files = Dir["**/*"] - ["asciidoctor-mallard-#{Asciidoctor::Mallard::VERSION}.gem", "asciidoctor-mallard.gemspec"]' \
+  asciidoctor-mallard.gemspec
 
 %build
 # Create the gem as gem install only works on a gem file
 gem build %{gem_name}.gemspec
 
-%gem_install
+# NOTE: The '-n ...' can be dropped when stable version is available.
+%gem_install -n %{gem_name}-%{version}%{?prever}.gem
 
 %install
 mkdir -p %{buildroot}%{gem_dir}
@@ -93,8 +108,10 @@
 
 %files doc
 %{gem_docdir}
+%{gem_instdir}/Gemfile
 %{gem_instdir}/README.adoc
 %{gem_instdir}/Rakefile
+%{gem_instdir}/WORKLOG.adoc
 %{gem_instdir}/test
 
 %changelog
```


> > 
> > > > * Test suite
> > > >   - Well, the line you used is just part of the story. You can see that there
> > > >     is nothing which would indicated, that the test suite was executed. You
> > > >     should use following line:
> > > > 
> > > > ```
> > > > ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
> > > > ```
> > > > 
> > > >   - Unfortunately, there seems to be dependency on asciidoctor-doctest, which
> > > >     is not in Fedora yet. Since it has quite lot of dependencies, it is
> > > >     probably not worth of packaging ATM, but all this should be documented.
> > > >   - Instead of execution of test suite, you should consider to provide at
> > > > least
> > > >     some sanity test, e.g. try to convert some document from AsciiDoc to
> > > >     Mallard using the %{gem_instdir}/bin/asciidoctor-mallard
> > > > 
> > > Can you please explain me a bit more about how to get it right ? 
> > > 
> > > URL: https://dhanvi.fedorapeople.org/packages/asciidoctor-mallard/
> > 
> > My idea was to do something as simple as shipping some simple AsciiDoc file
> > as Source1 and trying the conversion, e.g. the %check section could look
> > like:
> > 
> > ```
> > %check
> > pushd .%{gem_instdir}
> > # There is no rubygem-asciidoctor-doctest in Fedora yet, which is needed
> > # for test suite.
> > # ruby -Ilib -e 'Dir.glob "./test/*_test.rb", &method(:require)'
> > 
> > bin/asciidoctor-mallard %{SOURCE1} -o test.output
> > popd
> > 
> > ```
> > 
> > This is the simplest test you can do, since if the conversion fails for
> > whatever reason, the build should break.
> > 
> > On top of that, you can check for the consistency of the output by
> > calculating hash of the output, e.g. you can add the following line there:
> > 
> > ```
> > sha256sum test.output | grep
> > "870474333c6f4e41238f923f1d27c7688c86b6463db39725e076fc5f05fe2520" 
> > ```
> done it using the example given in the README
> > 
> > Of course you have to use correct hash, based on the content of the
> > %{SOURCE1} file you are going to use. Or you can choose to test any other
> > bit of the file content, if you consider it important.
> > 
> > 
> > BTW just running "bin/asciidoctor-mallard" will fail the build ATM, since
> > there is apparently some bug (undefined method `size' for nil:NilClass).
> > 
> This might be due to the requirements of rubygem-asciidoctor which I missed,
> also 
> 
> `
> ruby ./bin/asciidoctor-mallard
> `
> 
> works.

Wonderful! Thx.

* Please drop the "Requires: rubygem-asciidoctor". This require is autogenerated, you don't need to specify this dependency explicitly.


[1] https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services

Comment 14 Package Review 2020-07-10 00:54:48 UTC
This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.


Note You need to log in before you can comment on or make changes to this bug.