Bug#1033831: marked as done (RFS: importlab/0.8-1 -- Library to calculate Python dependency graphs)

[Debian Bug Tracking System]

Your message dated Tue, 4 Apr 2023 23:44:29 +0200
with message-id 
and subject line Re: RFS: importlab/0.8-1 [ITA] -- Library to calculate Python 
dependency graphs
has caused the Debian Bug report #1033831,
regarding RFS: importlab/0.8-1 -- Library to calculate Python dependency graphs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033831: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033831
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "importlab":

* Package name : importlab
   Version  : 0.8-1
   Upstream contact : Google 
* URL  : https://github.com/google/importlab
* License  : Apache-2.0
* Vcs  : https://salsa.debian.org/python-team/packages/importlab
   Section  : python

The source builds the following binary packages:

  python3-importlab - Library to calculate Python dependency graphs

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/importlab/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/i/importlab/importlab_0.8-1.dsc

Changes since the last upload:

importlab (0.8-1) UNRELEASED; urgency=medium--- End Message ---

Bug#1033831: RFS: importlab/0.8-1 [ITA] -- Library to calculate Python dependency graphs

[Lev Borodin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "importlab":

* Package name : importlab
   Version  : 0.8-1
   Upstream contact : Google 
* URL  : https://github.com/google/importlab
* License  : Apache-2.0
* Vcs  : https://salsa.debian.org/python-team/packages/importlab
   Section  : python

The source builds the following binary packages:

  python3-importlab - Library to calculate Python dependency graphs

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/importlab/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/i/importlab/importlab_0.8-1.dsc

Changes since the last upload:

importlab (0.8-1) UNRELEASED; urgency=medium

Bug#1009247: marked as done (RFS: importlab/0.7-1 [ITP] -- Library to calculate Python dependency graphs)

[Debian Bug Tracking System]

Your message dated Wed, 13 Apr 2022 11:28:15 +0200
with message-id <20220413112815.42b42...@vip.jcf.pm>
and subject line Re: Bug#1009247: RFS: importlab/0.7-1 [ITP] -- Library to 
calculate Python dependency graphs
has caused the Debian Bug report #1009247,
regarding RFS: importlab/0.7-1 [ITP] -- Library to calculate Python dependency 
graphs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1009247: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009247
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "importlab":

 * Package name: importlab
   Version : 0.7-1
   Upstream Author : Google 
 * URL : https://github.com/google/importlab
 * License : Apache2
 * Vcs : https://salsa.debian.org/faunris/importlab
   Section : python

The source builds the following binary packages:

  python3-importlab - Library to calculate Python dependency graphs

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/importlab/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/i/importlab/importlab_0.7-1.dsc

Changes for the initial release:

 importlab (0.7-1) UNRELEASED; urgency=low
 .
   * Initial release (Closes: #1009141)

Regards,
--
  Lev Borodin



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
--- Begin Message ---
Uploaded with a minor change, see attached diff. Please import into
git and (re)tag as necessary.
diff --git a/debian/changelog b/debian/changelog
index d7b2dd2..70e8944 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,4 +2,4 @@ importlab (0.7-1) unstable; urgency=low
 
   * Initial release (Closes: #1009141)
 
- -- Lev Borodin   Fri, 08 Apr 2022 14:04:29 +
+ -- Lev Borodin   Wed, 13 Apr 2022 08:37:40 +
diff --git a/debian/copyright b/debian/copyright
index 5ccfa91..092295d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -4,7 +4,7 @@ Upstream-Contact: Google 
 Source: https://github.com/google/importlab
 
 Files: *
-Copyright: 2017 Google 
+Copyright: 2017 Google Inc. 
 License: Apache-2.0
 
 Files: debian/*


pgp6EfAQdmCdk.pgp
Description: OpenPGP digital signature
--- End Message ---

Bug#1009247: RFS: importlab/0.7-1 [ITP] -- Library to calculate Python dependency graphs

[Lev Borodin]

Control: tags -1 - moreinfo

> 12 апр. 2022 г., в 22:37, Jeroen Ploemen  wrote:
> 
> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.

Hi Jeron,

thank you for review, that was very helpful!

You can see diff:
 
https://salsa.debian.org/faunris/importlab/-/compare/00367a3651968b2c437119d584ed3c0a3a8424c9...9400c104bc13c35b7893402a9b1551c6332aafb8?from_project_id=69256
 


Pipelines:
https://salsa.debian.org/faunris/importlab/-/pipelines 


New package deployed to:
https://mentors.debian.net/package/importlab/ 




signature.asc
Description: Message signed with OpenPGP

Bug#1009247: RFS: importlab/0.7-1 [ITP] -- Library to calculate Python dependency graphs

[Jeroen Ploemen]

Control: tags -1 moreinfo

On Sun, 10 Apr 2022 02:36:55 +0500
Lev Borodin  wrote:

> I am looking for a sponsor for my package importlab:

hi Lev,

as mentioned on irc, really solid work! A few comments and
suggestions:

Copyright:
* incorrect year for the upstream copyright (sources mention 2017);
* please use standard license shortnames (missing dash, see [1]);
* the standalone license paragraph should include the license headers
  instead of just a  oneliner.

Rules:
consider using debian/clean respectively execute_before_dh_installman
instead of the two overrides. This would make the rules file even
easier to read and avoid the repeated hardcoding of the buildsystem.

Tests: the upstream testsuite looks very usable as a non-trivial
autopkgtest (replacing the trivial autopkgtest-pkg-python). The
general approach for a python package such as this is to copy the
tests and testdata to an empty directory, then loop over all
supported python versions; see [2] for a well written example.

And lastly, please enable the CI on salsa: it's a great quality
control tool and a real timesaver for reviewers too.

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
[2] https://sources.debian.org/src/pyliblo/0.10.0-5/debian/tests/


Please remove the moreinfo tag (and CC me directly) once you have an
updated package ready.


pgpwdTJ0O7QxM.pgp
Description: OpenPGP digital signature

Bug#1009247: RFS: importlab/0.7-1 [ITP] -- Library to calculate Python dependency graphs

[Lev Borodin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "importlab":

 * Package name: importlab
   Version : 0.7-1
   Upstream Author : Google 
 * URL : https://github.com/google/importlab
 * License : Apache2
 * Vcs : https://salsa.debian.org/faunris/importlab
   Section : python

The source builds the following binary packages:

  python3-importlab - Library to calculate Python dependency graphs

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/importlab/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/i/importlab/importlab_0.7-1.dsc

Changes for the initial release:

 importlab (0.7-1) UNRELEASED; urgency=low
 .
   * Initial release (Closes: #1009141)

Regards,
--
  Lev Borodin



signature.asc
Description: Message signed with OpenPGP

Re: How to resolve unsatisfied dependency (verisoned) after ftpmaster acception

[Paul Wise]

On Fri, 2022-01-21 at 10:06 +0100, Markus Blatt wrote:

> I assume that this version dependency was added when the packages
> were built some time ago.

Correct, see the dh_shlibdeps, dpkg-shlibdeps, deb-shlibs,
deb-symbols and dpkg-gensymbols manual pages for details.

> What is the recommend way to resolve this?

In addition to the unsatisfiable dependency, the binaries in unstable
haven't been built on a buildd, so they won't be accepted into testing.

https://qa.debian.org/excuses.php?package=opm-common

Rebuilding the package (either via a package update or a binNMU) will
rebuild the binary, which will pick up the new libfmt dependency.
If you elect for a binNMU that will solve the buildd binaries issue.
If you elect for a package update, you just need to ensure your sponsor
does a source-only upload so builds will happen on built on buildds.

https://wiki.debian.org/binNMU
https://wiki.debian.org/SourceOnlyUpload

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: lib package name of dependency changed after ftpmaster acceptance (was Re: How to resolve unsatisfied dependency (verisoned) after ftpmaster acception)

[Andrey Rahmatullin]

On Fri, Jan 21, 2022 at 10:31:38AM +0100, Markus Blatt wrote:
> > When I look at the package tracker https://tracker.debian.org/pkg/opm-common
> > I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking
> > migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2.
> 
> And the current library package of libfmt source package is called libfmt8
> and not libfmt7.
> 
> To resolve this I guess the package needs to be rebuilt. Does that require 
> reuploading
> or is there another way?
You need to rebuild it anyway for it to migrate (and the excuses say that).
And a reupload is the only way as it includes arch:all subpackages,
otherwise it would be possible to binNMU it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

How to resolve unsatisfied dependency (verisoned) after ftpmaster acception

[Markus Blatt]

Hi,

I have created a new Debian package that finally got accepted into unstable
by ftpmaster. Thanks a lot. This is really great.

When I look at the package tracker https://tracker.debian.org/pkg/opm-common
I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking
migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2.

As debian/control does only specify a dependency on libfmt-dev without a 
version,
I assume that this version dependency was added when the packages were built
some time ago.

What is the recommend way to resolve this?

Cheers,

Markus

lib package name of dependency changed after ftpmaster acceptance (was Re: How to resolve unsatisfied dependency (verisoned) after ftpmaster acception)

[Markus Blatt]

Hi

Am Fri, Jan 21, 2022 at 10:06:22AM +0100 schrieb Markus Blatt:

When I look at the package tracker https://tracker.debian.org/pkg/opm-common
I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking
migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2.


And the current library package of libfmt source package is called libfmt8
and not libfmt7. 


To resolve this I guess the package needs to be rebuilt. Does that require 
reuploading
or is there another way?

Markus

Bug#994420: RFS: opendnssec/1:2.1.10-1 -- dependency package to install full OpenDNSSEC suite

[Mat]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "opendnssec":

 * Package name: opendnssec
   Version : 1:2.1.10-1
 * URL : https://www.opendnssec.org/
 * License : OLD-BSD, BSD-IBM-ISC, BSD-2-clause, GPL-2
 * Vcs : https://salsa.debian.org/debian/opendnssec
   Section : admin

It builds those binary packages:

  opendnssec-common - common configuration files for OpenDNSSEC suite
  opendnssec - dependency package to install full OpenDNSSEC suite
  opendnssec-doc - documentation for OpenDNSSEC suite
  opendnssec-enforcer - tool to prepare DNSSEC keys (common package)
  opendnssec-enforcer-mysql - tool to prepare DNSSEC keys (MySQL
  backend)
  opendnssec-enforcer-sqlite3 - tool to prepare DNSSEC keys (sqlite3
  backend)
  opendnssec-signer - daemon to sign DNS zone files periodically
  libhsm-bin - library for interfacing PKCS#11 Hardware Security
  Modules

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/opendnssec/

Alternatively, one can download the package with dget using this
command:

  dget -x
  
https://mentors.debian.net/debian/pool/main/o/opendnssec/opendnssec_2.1.10-1.dsc

Changes since the last upload:

 opendnssec (1:2.1.10-1) unstable; urgency=medium
 .
   * New upstream version 2.1.10
   * control: bump policy to 4.6.0, no code change
   * lintian-overrides: remove obsolete overrides

Regards,


-- 
Mat 


signature.asc
Description: Digital signature

Bug#968576: marked as done (RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0)

[Debian Bug Tracking System]

Your message dated Mon, 23 Aug 2021 21:27:19 +0530
with message-id 
and subject line Re: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- 
dependency of aerc 0.4.0
has caused the Debian Bug report #968576,
regarding RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of 
aerc 0.4.0
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
968576: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968576
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-emersion-go-message-dev",
found on salsa [1]. I've submitted a merge request [2], and would like 
to request

Maintainer access to the salsa repo as well (for future updates).

This package is a required dependency of aerc 0.4.0 [3].

Changelog:

golang-github-emersion-go-message (0.12.0-1) unstable; urgency=medium

  * New upstream version

 -- Ben Fiedler   Sat, 15 Aug 2020 21:32:15 
+0200



Regards,
Ben Fiedler

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message
[2]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message/-/merge_requests/2

[3]: https://aerc-mail.org
--- End Message ---
--- Begin Message ---
I updated and uploaded
https://tracker.debian.org/news/1250745/accepted-golang-github-emersion-go-message-0120-1-source-into-unstable/

Nilesh


signature.asc
Description: PGP signature
--- End Message ---

Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0

[Sai Karthik]

Yes, If anyone is interested, Please take up this package.

On 18/08/21 6:43 pm, Nilesh Patra wrote:

On Tue, 01 Jun 2021 08:02:43 +0200 Tobias Frost  wrote:

On Fri, 9 Apr 2021 00:41:35 +0530 Nilesh Patra  wrote:

Hi Ben,

(...)

It has been a while, but do you still need sponsoring for this? If yes,
I'm willing to do so.

PS: aerc is out of testing for this release unfortunately :/
Nevertheless, lets target the next one


Pinging Ben explictly… Maybe he missed that mail.
(Otherwise I'll mark the bugs moreinfo in a few weeks, as they are not
actionable without Ben's feedback; this includes the other golang RFS-bugs as
well…)


Few weeks earlier, I saw a message from the other manitainer of aerc
(Karthik in CC) in
a common channel saying that both him and Ben do not have the time and
enrgy to maintain this.
Maybe someone really will have to take over the maintainance. I'll try
reaching out meanwhile to ben but Ben does not seem active either.

@Karthik, can you confirm that this is right? And if yes, can you please
send in an email to the list if someone wants to take over the
maintainance, if not, could you please file in a RFA bug?

It still has RC bugs open, version lags behind, and folks are interested
in the package as well, so this is kinda important.
Hope that's fine

Nilesh



--
https://kskarthik.gitlab.io/


OpenPGP_0xF5B9A961BF6EAF0E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0

[Nilesh Patra]

On Tue, 01 Jun 2021 08:02:43 +0200 Tobias Frost  wrote:
> On Fri, 9 Apr 2021 00:41:35 +0530 Nilesh Patra  wrote:
> > Hi Ben,
> (...)
> > It has been a while, but do you still need sponsoring for this? If yes,
> > I'm willing to do so.
> > 
> > PS: aerc is out of testing for this release unfortunately :/
> > Nevertheless, lets target the next one
> 
> Pinging Ben explictly… Maybe he missed that mail.
> (Otherwise I'll mark the bugs moreinfo in a few weeks, as they are not
> actionable without Ben's feedback; this includes the other golang RFS-bugs as
> well…)

Few weeks earlier, I saw a message from the other manitainer of aerc
(Karthik in CC) in
a common channel saying that both him and Ben do not have the time and
enrgy to maintain this.
Maybe someone really will have to take over the maintainance. I'll try
reaching out meanwhile to ben but Ben does not seem active either.

@Karthik, can you confirm that this is right? And if yes, can you please
send in an email to the list if someone wants to take over the
maintainance, if not, could you please file in a RFA bug?

It still has RC bugs open, version lags behind, and folks are interested
in the package as well, so this is kinda important.
Hope that's fine

Nilesh


signature.asc
Description: PGP signature

Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0

[Tobias Frost]

On Fri, 9 Apr 2021 00:41:35 +0530 Nilesh Patra  wrote:
> Hi Ben,
(...)
> It has been a while, but do you still need sponsoring for this? If yes,
> I'm willing to do so.
> 
> PS: aerc is out of testing for this release unfortunately :/
> Nevertheless, lets target the next one

Pinging Ben explictly… Maybe he missed that mail.
(Otherwise I'll mark the bugs moreinfo in a few weeks, as they are not
actionable without Ben's feedback; this includes the other golang RFS-bugs as
well…)

--
cheers,
tobi

Re: Resolve circular dependency of a Python package

[Andrey Rahmatullin]

On Thu, May 20, 2021 at 07:32:53AM +0200, Jan Gru wrote:
> Those are de-facto runtime dependencies, but ~pcodedmp~ is required by
> ~oletools~ to run the `python setup.py tests` during the build of oletools,
> so it is kind of a build dependency, too. I assume disabling those tests
> selectively, which require ~pcodedmp~ would be a viable solution, since the
> policy suggests to break the loop by utilizing Debian tooling [4]. Is this
> correct?
Yes, assuming it's indeed not needed for the build process.

> If so, I have a practical question about realizing it:  I consulted the
> documentation of pybuild [5] and am able to disable all tests, which might
> not be an apt solution. Therefore I tried to `export
> PYBUILD_TEST_ARGS=-k-test_to_skip` in the rules file, which should disable
> only the test(s) in question. Unfortunately this does not work as I get the
> error error:
> 
> `I: pybuild base:232: python3.9 setup.py test -k-test_to_skip [...snip...]
> error: option -k not recognized`
-k is indeed a pytest option, and the doc you used mentions that.
I'd just disable all tests.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Resolve circular dependency of a Python package

[Jan Gru]

Dear mentors,


I want to ask a question on resolving circular dependencies of Python 
packages, which use distutils to build, as I am trying to package 
oletools, for which a RFP-bug has been filed [1].


~oletools~ has a circular dependency inside its seup.py [2] to ~pcodedmp~

#+BEGIN_SRC

    install_requires=[

           ...

   'pcodedmp>=1.2.5',
    ],

#+END_SRC

In turn ~pcodedmp~has a dependency on ~oletools~ in its setup.py [3]


#+BEGIN_SRC

INSTALL_REQUIRES = [
    'oletools>=0.54',
    ...
]

#+END_SRC

Those are de-facto runtime dependencies, but ~pcodedmp~ is required by 
~oletools~ to run the `python setup.py tests` during the build of 
oletools, so it is kind of a build dependency, too. I assume disabling 
those tests selectively, which require ~pcodedmp~ would be a viable 
solution, since the policy suggests to break the loop by utilizing 
Debian tooling [4]. Is this correct?


If so, I have a practical question about realizing it:  I consulted the 
documentation of pybuild [5] and am able to disable all tests, which 
might not be an apt solution. Therefore I tried to `export 
PYBUILD_TEST_ARGS=-k-test_to_skip` in the rules file, which should 
disable only the test(s) in question. Unfortunately this does not work 
as I get the error error:


`I: pybuild base:232: python3.9 setup.py test -k-test_to_skip 
[...snip...] error: option -k not recognized`


Do you have an idea on how to resolve this and where the problem 
resides? Is the pybuild-documentation misleading in this regard or is it 
my fault?



Thanks already in advance for your help!


Best regards,

Jan

---

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939464

[2] https://github.com/decalage2/oletools/blob/master/setup.py

[3] https://github.com/bontchev/pcodedmp/blob/master/setup.py

[4] 
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends 



[5] See https://wiki.debian.org/Python/Pybuild

Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0

[Nilesh Patra]

Hi Ben,

On Mon, 17 Aug 2020 23:19:44 +0200 Ben Fiedler  
wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package 
> "golang-github-emersion-go-message-dev",
> found on salsa [1]. I've submitted a merge request [2], and would like 
> to request
> Maintainer access to the salsa repo as well (for future updates).
> 
> This package is a required dependency of aerc 0.4.0 [3].
> 
> Changelog:
> 
> golang-github-emersion-go-message (0.12.0-1) unstable; urgency=medium
> 
>* New upstream version
> 
>   -- Ben Fiedler   Sat, 15 Aug 2020 21:32:15 
> +0200

It has been a while, but do you still need sponsoring for this? If yes,
I'm willing to do so.

PS: aerc is out of testing for this release unfortunately :/
Nevertheless, lets target the next one

Nilesh


signature.asc
Description: PGP signature

Bug#973371: RFS: pytest-dependency/0.5.1-1 [ITP] -- Manages dependencies of pytest test cases

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pytest-dependency":

 * Package name    : pytest-dependency
   Version : 0.5.1-1
   Upstream Author : Rolf Krahl 
 * URL : https://github.com/RKrahl/pytest-dependency
 * License : Apache-2.0
   Section : python
 * Vcs: https://salsa.debian.org/python-team/packages/pytest-dependency

It builds those binary packages:

  python-pytest-dependency-doc - Manages dependencies of pytest test
cases (common documentation)
  python3-pytest-dependency - Manages dependencies of pytest test cases
(Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pytest-dependency/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/pytest-dependency/pytest-dependency_0.5.1-1.dsc

Changes for the initial release:

 pytest-dependency (0.5.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #972718)

Regards,
Bastian

Re: libdatetime-perl BD-Uninstallable although dependency is satisfied (?)

[Andrius Merkys]

On 2020-08-25 10:48, Andrey Rahmatullin wrote:
> On Tue, Aug 25, 2020 at 10:39:50AM +0300, Andrius Merkys wrote:
>> Buildd status page for libdatetime-perl [1] says that on kfreebsd-* its
>> build dependencies are uninstallable, citing the following dependency
>> tree (for kfreebsd-amd64, for example):
>>
>> libdatetime-perl build-depends on:
>> - libdatetime-locale-perl:kfreebsd-amd64 (>= 1:1.06)
>> libdatetime-locale-perl depends on:
>> - libnamespace-autoclean-perl:kfreebsd-amd64
>> libnamespace-autoclean-perl depends on:
>> - libnamespace-clean-perl:kfreebsd-amd64
>> libnamespace-clean-perl depends on:
>> - libsub-name-perl:kfreebsd-amd64
>> libsub-name-perl depends on missing:
>> - perlapi-5.28.1:kfreebsd-amd64
>>
>> libdatetime-locale-perl 1:1.26-1 is in unstable as arch:all, thus I do
>> not understand how can it be uninstallable. 
> A package can be present in unstable yet be uninstallable, or what do you
> mean? I didn't check if perlapi-5.28.1:kfreebsd-amd64 is indeed
> unavailable but it seems like a valid reason.

Indeed, libsub-name-perl:kfreebsd-amd64 was built in unstable using
perl, but since then perl FTBFS on kfreebsd-amd64, thus
libsub-name-perl:kfreebsd-amd64 is uninstallable.

Thanks for pointing out!
Andrius

Re: libdatetime-perl BD-Uninstallable although dependency is satisfied (?)

[Andrey Rahmatullin]

On Tue, Aug 25, 2020 at 10:39:50AM +0300, Andrius Merkys wrote:
> Buildd status page for libdatetime-perl [1] says that on kfreebsd-* its
> build dependencies are uninstallable, citing the following dependency
> tree (for kfreebsd-amd64, for example):
> 
> libdatetime-perl build-depends on:
> - libdatetime-locale-perl:kfreebsd-amd64 (>= 1:1.06)
> libdatetime-locale-perl depends on:
> - libnamespace-autoclean-perl:kfreebsd-amd64
> libnamespace-autoclean-perl depends on:
> - libnamespace-clean-perl:kfreebsd-amd64
> libnamespace-clean-perl depends on:
> - libsub-name-perl:kfreebsd-amd64
> libsub-name-perl depends on missing:
> - perlapi-5.28.1:kfreebsd-amd64
> 
> libdatetime-locale-perl 1:1.26-1 is in unstable as arch:all, thus I do
> not understand how can it be uninstallable. 
A package can be present in unstable yet be uninstallable, or what do you
mean? I didn't check if perlapi-5.28.1:kfreebsd-amd64 is indeed
unavailable but it seems like a valid reason.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

libdatetime-perl BD-Uninstallable although dependency is satisfied (?)

[Andrius Merkys]

Hello,

Buildd status page for libdatetime-perl [1] says that on kfreebsd-* its
build dependencies are uninstallable, citing the following dependency
tree (for kfreebsd-amd64, for example):

libdatetime-perl build-depends on:
- libdatetime-locale-perl:kfreebsd-amd64 (>= 1:1.06)
libdatetime-locale-perl depends on:
- libnamespace-autoclean-perl:kfreebsd-amd64
libnamespace-autoclean-perl depends on:
- libnamespace-clean-perl:kfreebsd-amd64
libnamespace-clean-perl depends on:
- libsub-name-perl:kfreebsd-amd64
libsub-name-perl depends on missing:
- perlapi-5.28.1:kfreebsd-amd64

libdatetime-locale-perl 1:1.26-1 is in unstable as arch:all, thus I do
not understand how can it be uninstallable. I assume that buildd
reevaluates BD-Uninstallable packages from time to time, but please let
me know if I am wrong here.

[1]
https://buildd.debian.org/status/package.php?p=libdatetime-perl=sid

Best,
Andrius

Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0

[Ben Fiedler]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-emersion-go-message-dev",
found on salsa [1]. I've submitted a merge request [2], and would like 
to request

Maintainer access to the salsa repo as well (for future updates).

This package is a required dependency of aerc 0.4.0 [3].

Changelog:

golang-github-emersion-go-message (0.12.0-1) unstable; urgency=medium

  * New upstream version

 -- Ben Fiedler   Sat, 15 Aug 2020 21:32:15 
+0200



Regards,
Ben Fiedler

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message
[2]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message/-/merge_requests/2

[3]: https://aerc-mail.org

Bug#951392: dependency on Python2

[Eric Desrochers]

Hi Adam,

I have dropped the py2 dependency out of the sosreport 3.9-1 debian
package, it is no longer needed. This runtime dependency was a left over.

If you want to give a second review. I have dropped the py Depends in my
curren upload of version "3.9-2"

https://mentors.debian.net/package/sosreport

Thanks in advance !

Regards,
Eric

Behaviour of a dependency

[Tommi Höynälänmaa]

Actually the Depends field in debian/control is:
---
Depends: guile-${guile-version}, guile-${guile-version}-dev,
 libthemedsupport (= ${binary:Version}),
 th-scheme-utilities (= ${source:Version}),
 ${misc:Depends}
---

 - Tommi Höynälänmaa

Behaviour of a dependency

[Tommi Höynälänmaa]

Hello

I have the following field in package theme-d-rte:
---
Depends: guile-2.2, guile-2.2-dev, libthemedsupport (= 1.4.1-1), th-
scheme-utilities (= 1.4.1-1)
---

Now dpkg still allows me to upgrade package libthemedsupport from
1.4.1-1 to version 1.4.1-2. Why is this so?

 - Tommi Höynälänmaa

Re: 'Architecture: all' with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all

[Chris Knadle]

Patrick Schleizer:
> I am maintaining two Debian derivatives distributions, Whonix and
> Kicksecure. (Open Source) I hope you don't mind my question.
> 
> I am trying to build a custom meta package with 'Architecture: all' that
> has an architecture specific dependency:
> hardened-malloc [amd64]

As best I can tell at the moment, from the point of view of dh and/or dpkg with
this would be "for all architectures install the following, including
hardened-malloc [amd64]" -- i.e. I think this logic is interpreted as a request
to install an amd64 package regardless of the local architecture.

I've been having a read through section 7.1. of Debian Policy concerning
architecture-specific entries in control fields:

https://www.debian.org/doc/debian-policy/ch-relationships

and this paragraph describes the problem -- the architecture-specific entries
are only allowed on build relationship fields:

   "For binary relationship fields and the Built-Using field, the
architecture restriction syntax is only supported in the source
package control file debian/control. When the corresponding binary
package control file is generated, the relationship will either be
omitted or included without the architecture restriction based on
the architecture of the binary package. This means that architecture
restrictions must not be used in binary relationship fields for
architecture-independent packages"

P.S. Thanks very much for your work on whonix  :)

  -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



signature.asc
Description: OpenPGP digital signature

'Architecture: all' with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all

[Patrick Schleizer]

I am maintaining two Debian derivatives distributions, Whonix and
Kicksecure. (Open Source) I hope you don't mind my question.

I am trying to build a custom meta package with 'Architecture: all' that
has an architecture specific dependency:
hardened-malloc [amd64]

Package hardened-malloc is only available for amd64 and cannot be
trivially ported. (Would require source code level changes which I am
unable to contribute.) That package is not all that important. We want
it pre-installed on amd64 but at the same time it shouldn't be a blocker
for ports to let's say arm64.

(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)

Here is a simplified example.

Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
 pkg1,
 pkg2,
 ...,
 hardened-malloc [amd64],
 ${misc:Depends}
Description: Dependencies for hardened systems CLI
 A metapackage, which installs command line interface (CLI) packages
which should be installed on hardened systems.


debhelper fails with the following error message

>dh_gencontrol
> dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package is architecture all
> dh_gencontrol: dpkg-gencontrol -pkicksecure-dependencies-cli
-ldebian/changelog -Tdebian/kicksecure-dependencies-cli.substvars
-Pdebian/kicksecure-dependencies-cli -UMulti-Arch returned exit code 255
> dh_gencontrol: Aborting due to earlier error
> make: *** [debian/rules:9: binary] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2


'Recommends:' does not fit either since we're using apt with
'--no-install-recommends' during the build process to have tighter
control about which packages get installed.

Can I somehow hack or work around that limitation?

I could use 'Architecture: any' but then that meta package would be
build and added to the repository as 'amd64', although it's "mostly"
just a 'Architecture: all' package, except for the "optional dependency".

This would mean that either,

- architecture users other than amd64 couldn't simply install our meta
package by simply adding our third party repository and apt installing
from it, or

- I'd have to build that package for all platforms and add to
repository. That's doable in theory but would require a lot of
cowbuilder chroots, disk space and build time.

("99%" of our packages are "really" 'Architecture: all', i.e. just
configuration packages, bash or python.)

Hence, I am looking for a simpler fix. Any idea?

Kind regards,
Patrick

'Architecture: all' with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all

[Patrick Schleizer]

I am maintaining two Debian derivatives distributions, Whonix and
Kicksecure. (Open Source) I hope you don't mind my question.

I am trying to build a custom meta package with 'Architecture: all' that
has an architecture specific dependency:
hardened-malloc [amd64]

Package hardened-malloc is only available for amd64 and cannot be
trivially ported. (Would require source code level changes which I am
unable to contribute.) That package is not all that important. We want
it pre-installed on amd64 but at the same time it shouldn't be a blocker
for ports to let's say arm64.

(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)

Here is a simplified example.

Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
 pkg1,
 pkg2,
 ...,
 hardened-malloc [amd64],
 ${misc:Depends}
Description: Dependencies for hardened systems CLI
 A metapackage, which installs command line interface (CLI) packages
which should be installed on hardened systems.


debhelper fails with the following error message

>dh_gencontrol
> dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package is architecture all
> dh_gencontrol: dpkg-gencontrol -pkicksecure-dependencies-cli
-ldebian/changelog -Tdebian/kicksecure-dependencies-cli.substvars
-Pdebian/kicksecure-dependencies-cli -UMulti-Arch returned exit code 255
> dh_gencontrol: Aborting due to earlier error
> make: *** [debian/rules:9: binary] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2


'Recommends:' does not fit either since we're using apt with
'--no-install-recommends' during the build process to have tighter
control about which packages get installed.

Can I somehow hack or work around that limitation?

I could use 'Architecture: any' but then that meta package would be
build and added to the repository as 'amd64', although it's "mostly"
just a 'Architecture: all' package, except for the "optional dependency".

This would mean that either,

- architecture users other than amd64 couldn't simply install our meta
package by simply adding our third party repository and apt installing
from it, or

- I'd have to build that package for all platforms and add to
repository. That's doable in theory but would require a lot of
cowbuilder chroots, disk space and build time.

("99%" of our packages are "really" 'Architecture: all', i.e. just
configuration packages, bash or python.)

Hence, I am looking for a simpler fix. Any idea?

Kind regards,
Patrick

Re: Guidance with using system-installed dependency

[merkys]

Hello,

On 2019-07-04 03:58, he...@shayandoust.me wrote:
> Even though I had verbosity set, the message still didn't make sense. I tried 
> to copy out the project from my working (root) directory and try to "cmake ." 
> it manually with the build dependencies installed on my system, and it seems 
> like the reason was down to CMake complaining that "include could not find 
> load file GatbCore". I'm not strong with CMake at all and any guidance would 
> be much appreciated! Hopefully I covered any needed messages and reproducible 
> steps as this is my first package and first message on a mailing list with a 
> wide audience. 

The problem seems to be related with the included CMakefile of
gatb-core, which seems to be relevant only for building the gatb-core
from source. I suspect that this method is used to build dependencies
prior to the actual package source. As gatb-core is in Debian, there is
no need to build it, its library can readily be taken from system-wide
location. So the patch would be to ignore the 'include (GatbCore)'
instruction in CMakeLists.txt.

Hope this helps,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: Guidance with using system-installed dependency

[Paul Wise]

On Thu, Jul 4, 2019 at 9:09 AM  Shayan Doust wrote:

> I have created a patch file that is "meant" to use the system-installed 
> libgatbcore-dev instead of a submodule that comes with the project on github.

If you haven't already, please try to get the patch or something
similar included upstream. Personally, I would try to also get them to
remove the submodule and only use the system version, they might not
want to do that though.

> CMake complaining that "include could not find load file GatbCore"

Is libgatbcore-dev present in your Build-Depends in debian/control?

$ apt-file search GatbCore
libgatbcore-dev: /usr/lib/x86_64-linux-gnu/cmake/GatbCore.cmake

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Guidance with using system-installed dependency

[hello]

Hello,

I am a newcomer for package maintaining. I'm currently working on packaging a 
program [1] that uses CMake and requires some build dependencies, in this case 
both cmake and gatb-core which has fortunately been already packaged as 
libgatbcore-dev. I have created a patch file that is "meant" to use the 
system-installed libgatbcore-dev instead of a submodule that comes with the 
project on github. The issue comes when I try building inside a pbuilder 
environment. The builder will complain with something like this:

 ...
Feature record: CXX_FEATURE:0cxx_user_literals
Feature record: CXX_FEATURE:0cxx_variable_templates
Feature record: CXX_FEATURE:0cxx_variadic_macros
Feature record: CXX_FEATURE:0cxx_variadic_templates
dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 1
make: *** [debian/rules:21: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package

Even though I had verbosity set, the message still didn't make sense. I tried 
to copy out the project from my working (root) directory and try to "cmake ." 
it manually with the build dependencies installed on my system, and it seems 
like the reason was down to CMake complaining that "include could not find load 
file GatbCore". I'm not strong with CMake at all and any guidance would be much 
appreciated! Hopefully I covered any needed messages and reproducible steps as 
this is my first package and first message on a mailing list with a wide 
audience. 

Thanks,
Shayan Doust

[1]: https://salsa.debian.org/med-team/mindthegap

Re: Meaning of "Checking build-dependency (indep) on amd64" excuse

[Paul Gevers]

Hi Feri,

Please CC me on reply.

>> I think I understand the rest, although I don't know whether the
>> autopkgtest regression blocks migration indefinitely.  That would be
>> unfortunate, because unstable pcs needs unstable pacemaker, so they
>> deadlock...
>
> I think you will need to ask the release team to hint them in
> together.

Yes, they will block unless overridden by the release team, or better,
when you change your package relations such that the migration software
figures out that they need to be tested together. (The release team and
I can do the latter manually, but that is not really sustainable.)

With the current code your options are:
- *versioned* depends on one of the binary packages from the source you
want from unstable in any of the binary packages that is going to be
taken from unstable already
- *versioned* breaks or conflicts on the binary packages from the source
you want from unstable in any of the binary packages that is going to be
taken from unstable
- *versioned* test dependency in the package that is used for
autopkgtest (only helps if the version that is tested is already taken
from unstable). The version of the test dependency will NOT be added to
the triggers, but if the version of the autopktest is going to be taken
from unstable already due to other considerations, with the current
settings of ci.d.n and autopkgtest the required version will be installed.

Mind you, if the migration software asks for a test with multiple
packages from unstable (visible in the triggers string) a PASS will be
used for all those packages, so you only need to "fix" this in one package.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Meaning of "Checking build-dependency (indep) on amd64" excuse

[Paul Wise]

On Wed, Jan 16, 2019 at 12:07 AM Ferenc Wágner wrote:

> Thanks, Paul, it makes sense indeed and I agree it's reasonable to do,
> but how/why is this an excuse?  Is there any problem with that?

No idea, you would have to ask the release team about this.

> That gives 404 to me.

https://salsa.debian.org/release-team/britney2/blob/master/britney2/policies/policy.py#L916

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/

Re: Meaning of "Checking build-dependency (indep) on amd64" excuse

[Ferenc Wágner]

Paul Wise  writes:

> On Tue, Jan 15, 2019 at 7:06 PM  wrote:
>
>> Could somebody please explain me the meaning of the "Checking
>> build-dependency (indep) on amd64" migration excuse as seen on
>> https://qa.debian.org/excuses.php?package=pacemaker?
>
> Looking at the code, I think it means that the migration scripts are
> verifying the Build-Depends-Indep packages are installable on amd64
> and probably ignoring installability on other arches. This is
> reasonable since all of Debian's arch:all buildds use amd64 right now.

Thanks, Paul, it makes sense indeed and I agree it's reasonable to do,
but how/why is this an excuse?  Is there any problem with that?

> https://salsa.debian.org/release-team/britney2/blob/britney2/policies/policy.py#L916

That gives 404 to me.

>> I think I understand the rest, although I don't know whether the
>> autopkgtest regression blocks migration indefinitely.  That would be
>> unfortunate, because unstable pcs needs unstable pacemaker, so they
>> deadlock...
>
> I think you will need to ask the release team to hint them in together.

OK, will do.
-- 
Regards,
Feri

Re: Meaning of "Checking build-dependency (indep) on amd64" excuse

[Paul Wise]

On Tue, Jan 15, 2019 at 7:06 PM  wrote:

> Could somebody please explain me the meaning of the "Checking
> build-dependency (indep) on amd64" migration excuse as seen on
> https://qa.debian.org/excuses.php?package=pacemaker?

Looking at the code, I think it means that the migration scripts are
verifying the Build-Depends-Indep packages are installable on amd64
and probably ignoring installability on other arches. This is
reasonable since all of Debian's arch:all buildds use amd64 right now.

https://salsa.debian.org/release-team/britney2/blob/britney2/policies/policy.py#L916

> I think I understand the rest, although I don't know whether the
> autopkgtest regression blocks migration indefinitely.  That would be
> unfortunate, because unstable pcs needs unstable pacemaker, so they
> deadlock...

I think you will need to ask the release team to hint them in together.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Meaning of "Checking build-dependency (indep) on amd64" excuse

[wferi]

Hi,

Could somebody please explain me the meaning of the "Checking
build-dependency (indep) on amd64" migration excuse as seen on
https://qa.debian.org/excuses.php?package=pacemaker?

I think I understand the rest, although I don't know whether the
autopkgtest regression blocks migration indefinitely.  That would be
unfortunate, because unstable pcs needs unstable pacemaker, so they
deadlock...
-- 
Thanks,
Feri

Re: Build dependency

[Leopold Palomo-Avellaneda]

Hi

El 31/10/18 a les 1:52, gregor herrmann ha escrit:
> On Tue, 30 Oct 2018 23:52:11 +0100, Adam Borowski wrote:
> 
>>> reverse-depends -b packageX
>>> (reverse-depends is in ubuntu-dev-tools)
>> build-rdeps packageX
>> (needs just regular devscripts, although you want dose-extra to handle B-Dep
>> on Dep chains)
> 
> Interesting, I admit that I didn't know (or didn't remember)
> build-rdeps. But:

[...]
> 
> % reverse-depends -b libdatetime-timezone-perl 

[...]

> 
> % build-rdeps libdatetime-timezone-perl 

[...]



> % build-rdeps --old libdatetime-timezone-perl 

[...]

maybe it should be nice to have documented all of this functions in someplace.
For instance, in the library migration page, it would be useful.

In any case, thanks a lot for all the info.

Cheers,

Leopold

-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature

Re: Build dependency

[gregor herrmann]

On Tue, 30 Oct 2018 23:52:11 +0100, Adam Borowski wrote:

> > reverse-depends -b packageX
> > (reverse-depends is in ubuntu-dev-tools)
> build-rdeps packageX
> (needs just regular devscripts, although you want dose-extra to handle B-Dep
> on Dep chains)

Interesting, I admit that I didn't know (or didn't remember)
build-rdeps. But:

% reverse-depends -b libdatetime-timezone-perl 
Reverse-Build-Depends-Indep
===
* libcatalyst-plugin-scheduler-perl
* libdatetime-format-dateparse-perl
* libdatetime-format-flexible-perl
* libdatetime-format-ical-perl
* libdatetime-format-natural-perl
* libdatetime-format-pg-perl
* libdatetime-format-strptime-perl
* libdatetime-format-w3cdtf-perl
* libmoosex-types-datetime-perl
* libmoosex-types-iso8601-perl
* libpgobject-type-datetime-perl
* libpoe-component-schedule-perl
* libxml-atom-perl
* pinto
* sqitch
* xmltv

Reverse-Build-Depends
=
* libatompub-perl
* libdatetime-perl
* librdf-closure-perl
* libtypes-datetime-perl


% build-rdeps libdatetime-timezone-perl 
Reverse Build-depends in main:
--

Fatal error in module common/format822.ml: 
 character 0-1: RFC 822 error.
No reverse build-depends found for libdatetime-timezone-perl.

Reverse Build-depends in contrib:
--

Fatal error in module common/format822.ml: 
 character 0-1: RFC 822 error.
No reverse build-depends found for libdatetime-timezone-perl.

Reverse Build-depends in non-free:
--

Fatal error in module common/format822.ml: 
 character 0-1: RFC 822 error.
No reverse build-depends found for libdatetime-timezone-perl.


(dose-extra is installed. Am I missing something else?)


Oh, and:

% build-rdeps --old libdatetime-timezone-perl 
Reverse Build-depends in main:
--

libdatetime-format-pg-perl
xmltv
libmoosex-types-iso8601-perl
libdatetime-format-w3cdtf-perl
librdf-closure-perl
sqitch
libdatetime-format-flexible-perl
libdatetime-format-strptime-perl
libdatetime-perl
pinto
libxml-atom-perl
libmoosex-types-datetime-perl
libatompub-perl
libdatetime-format-ical-perl
libpgobject-type-datetime-perl
libpoe-component-schedule-perl
libcatalyst-plugin-scheduler-perl
libdatetime-format-natural-perl
libdatetime-format-dateparse-perl
libtypes-datetime-perl

Found a total of 20 reverse build-depend(s) for libdatetime-timezone-perl.

Reverse Build-depends in contrib:
--

No reverse build-depends found for libdatetime-timezone-perl.

Reverse Build-depends in non-free:
--

No reverse build-depends found for libdatetime-timezone-perl.



Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Derek Patton: Apes in the Rotunda


signature.asc
Description: Digital Signature

Re: Build dependency

[Adam Borowski]

On Mon, Oct 29, 2018 at 01:09:54AM +0100, gregor herrmann wrote:
> On Mon, 29 Oct 2018 00:25:35 +0100, Leopold Palomo-Avellaneda wrote:
> 
> > I know that
> > apt-cache rdepends packageX
> > show me the list of the packages that depends of packageX. But, how can
> > I obtain the list of packages that build-depends of packageX?
> 
> reverse-depends -b packageX
> 
> (reverse-depends is in ubuntu-dev-tools)

build-rdeps packageX

(needs just regular devscripts, although you want dose-extra to handle B-Dep
on Dep chains)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: Build dependency

[gregor herrmann]

On Mon, 29 Oct 2018 00:25:35 +0100, Leopold Palomo-Avellaneda wrote:

> I know that
> apt-cache rdepends packageX
> show me the list of the packages that depends of packageX. But, how can
> I obtain the list of packages that build-depends of packageX?

reverse-depends -b packageX

(reverse-depends is in ubuntu-dev-tools)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Supertramp: If Everyone Was Listening


signature.asc
Description: Digital Signature

Build dependency

[Leopold Palomo-Avellaneda]

Hi,


I know that

apt-cache rdepends packageX


show me the list of the packages that depends of packageX. But, how can
I obtain the list of packages that build-depends of packageX?

Leopold


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

control: tag -1 -moreinfo

Hi Adam,

Intel has fixed the AMD CPU test failure.
https://github.com/intel/mkl-dnn/issues/291

Let's upload the latest snapshot to experimental?
https://mentors.debian.net/debian/pool/main/m/mkl-dnn/mkl-dnn_0.16+git20180820.f51304a-1.dsc

PPA: https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages
Dom: 
http://debomatic-amd64.debian.net/distribution#experimental/mkl-dnn/0.16+git20180820.f51304a-1/buildlog
Salsa: https://salsa.debian.org/science-team/mkl-dnn

Thanks!

On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote:
> On Thu, Aug 09, 2018 at 10:16:17AM +, Lumin wrote:
> >  * Package name: mkl-dnn
> >Version : 0.15+git20180803.3f58c16-1
> >Upstream Author : intel
> 
> Alas, the build flags use -march=native -mtune=native which is a big no-no.
> The first makes the package crash on any processor lacking an extension that
> was present on the build machine and was used by the compiler; unless some
> kind of runtime detection is used, packages are allowed only the baseline
> ISA for the architecture.  As for -mtune=native, it makes the package build
> unreproducibly, differing based on where it was compiled.
 
Fixed in the updated package.

> The second problem is that in the testsuite, test_convolution_format_any
> fails (0/5 sub-tests).  This might be related to my machine being:
> vendor_id : AuthenticAMD
> model name: AMD Phenom(tm) II X6 1055T Processor
> 
> Log of the FTBFS attached.
 
Fixed by Intel.

> 
> Meow!
> -- 
> ⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
> ⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
> ⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
> ⠈⠳⣄ adjectives to use for the dish's name.

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

control: tag -1 +moreinfo

On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote:
> On Thu, Aug 09, 2018 at 10:16:17AM +, Lumin wrote:
> >  * Package name: mkl-dnn
> >Version : 0.15+git20180803.3f58c16-1
> >Upstream Author : intel
> 
> Alas, the build flags use -march=native -mtune=native which is a big no-no.
> The first makes the package crash on any processor lacking an extension that
> was present on the build machine and was used by the compiler; unless some
> kind of runtime detection is used, packages are allowed only the baseline
> ISA for the architecture.  As for -mtune=native, it makes the package build
> unreproducibly, differing based on where it was compiled.

My bad, I overlooked the two flags. The cmake files have been patched
in master branch of packaging repo.

https://salsa.debian.org/science-team/mkl-dnn/commit/6e0a9bea677d398ee23ac9c2f84c3551d100a6d4
http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog
 
> The second problem is that in the testsuite, test_convolution_format_any
> fails (0/5 sub-tests).  This might be related to my machine being:
> vendor_id : AuthenticAMD
> model name: AMD Phenom(tm) II X6 1055T Processor

Well, I have been waiting for intel to fix test failures for a long
time. Finally the snapshot 0.15+git20180803.3f58c16 doesn't fail
any test on dom-amd64 (E5 2699v?) and my I5-7440HQ, but now it failed
on AMD cpu ...

> Log of the FTBFS attached.

Thanks for the log, I've forwarded it to upstream.
https://github.com/intel/mkl-dnn/issues/291

I shouldn't let any test failure from mkl-dnn pass, so we have to wait
for upstream to fix the problem. Fortunately, TensorFlow can be compiled
with or without mkl-dnn. It doesn't matter if the initial upload of
TensorFlow is not linked against mkl-dnn. The difference that mkl-dnn
would bring to TensorFlow is computation speed-up.

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Adam Borowski]

On Thu, Aug 09, 2018 at 10:16:17AM +, Lumin wrote:
>  * Package name: mkl-dnn
>Version : 0.15+git20180803.3f58c16-1
>Upstream Author : intel

Alas, the build flags use -march=native -mtune=native which is a big no-no.
The first makes the package crash on any processor lacking an extension that
was present on the build machine and was used by the compiler; unless some
kind of runtime detection is used, packages are allowed only the baseline
ISA for the architecture.  As for -mtune=native, it makes the package build
unreproducibly, differing based on where it was compiled.

The second problem is that in the testsuite, test_convolution_format_any
fails (0/5 sub-tests).  This might be related to my machine being:
vendor_id   : AuthenticAMD
model name  : AMD Phenom(tm) II X6 1055T Processor

Log of the FTBFS attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
⠈⠳⣄ adjectives to use for the dish's name.


mkl-dnn_0.15+git20180803.3f58c16-1_amd64.build.xz
Description: application/xz

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

Package: sponsorship-requests
Severity: wishlist

Disclaimer:

  Intel made some confusing naming. I should point out that mkl-dnn is
  a free software, which can be independently compiled and used without
  any component from intel-mkl . Without linking against intel-mkl, we
  would get a suboptimal performance, but intel claimed that they are
  trying to reduce the performance gap.

  1. [Apache-2.0] mkl-dnn: Intel Math Kernel Library - Deep Neural Network

  2. [non-free] intel-mkl: Intel Math Kernel Library
 intel-mkl contains another set of dnn api (mkl_dnn.h) but let's ignore it.

Dear mentors,

  I am looking for a sponsor for my package "mkl-dnn"

 * Package name: mkl-dnn
   Version : 0.15+git20180803.3f58c16-1
   Upstream Author : intel
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libmkldnn-dev - Math Kernel Library for Deep Neural Networks (dev)
libmkldnn-doc - Math Kernel Library for Deep Neural Networks (doc)
libmkldnn0 - Math Kernel Library for Deep Neural Networks (lib)

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/mkl-dnn


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/m/mkl-dnn/mkl-dnn_0.15+git20180803.3f58c16-1.dsc

  More information about hello can be obtained from 

  
http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog

  Changes since the last upload:

mkl-dnn (0.15+git20180803.3f58c16-1) unstable; urgency=low

  * Initial release. (Closes: #894411)

Bug#905582: marked as done (RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency)

[Debian Bug Tracking System]

Your message dated Mon, 6 Aug 2018 19:48:58 +0200
with message-id <20180806174858.7mfukvjd2536z...@angband.pl>
and subject line Re: Bug#905582: RFS: nsync/1.20.1-1 [ITP] -- tensorflow 
dependency
has caused the Debian Bug report #905582,
regarding RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
905582: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905582
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "nsync", which is a
  tensorflow dependency.

 * Package name: nsync
   Version : 1.20.1-1
   Upstream Author : google
 * URL : [fill in URL of upstreams web site]
 * License : Apache-2
   Section : science

  It builds those binary packages:

libnsync-cpp1 - C library that exports various synchronization primitives 
(C++ li
libnsync-dev - C library that exports various synchronization primitives 
(dev)
libnsync1  - C library that exports various synchronization primitives (C 
lib)

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/nsync

  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-1.dsc

  More information about hello can be obtained fro

  
http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-1/buildlog

  Changes since the last upload:

nsync (1.20.1-1) unstable; urgency=low

  * Initial release. (Closes: #904440)
--- End Message ---
--- Begin Message ---
On Mon, Aug 06, 2018 at 04:15:34PM +, Lumin wrote:
>  * Package name: nsync
>Version : 1.20.1-1

>   It builds those binary packages:
> 
> libnsync-cpp1 - C library that exports various synchronization primitives 
> (C++ li
> libnsync-dev - C library that exports various synchronization primitives 
> (dev)
> libnsync1  - C library that exports various synchronization primitives (C 
> lib)

> nsync (1.20.1-1) unstable; urgency=low
> 
>   * Initial release. (Closes: #904440)

In NEW.


I hate hate hate platform zoology, such as the platform/ dir in this
package, but the set of ones they bothered to enumerate is... weird.
If wonder if they actually tested this code on Vax and Tru64...



喵!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.--- End Message ---

Bug#905582: RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency

[Lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "nsync", which is a
  tensorflow dependency.

 * Package name: nsync
   Version : 1.20.1-1
   Upstream Author : google
 * URL : [fill in URL of upstreams web site]
 * License : Apache-2
   Section : science

  It builds those binary packages:

libnsync-cpp1 - C library that exports various synchronization primitives 
(C++ li
libnsync-dev - C library that exports various synchronization primitives 
(dev)
libnsync1  - C library that exports various synchronization primitives (C 
lib)

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/nsync

  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-1.dsc

  More information about hello can be obtained fro

  
http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-1/buildlog

  Changes since the last upload:

nsync (1.20.1-1) unstable; urgency=low

  * Initial release. (Closes: #904440)

Re: Packaging work is done for php-db-dataobject (a dependency for GNU Social)

[Gianfranco Costamagna]

Hello,

>suggestions and uploaded to mentors[1]. There was a sponsor in 2016, but
>he is not responding now. Can anyone look into this package!. Thank you.


done now

G.

Packaging work is done for php-db-dataobject (a dependency for GNU Social)

[Rajasekhar Ponakala]

Hello Team,

This pkg is the last dependency for GNU- Social pkg.This was once under
the upload queue and removed by the ftp-masters. They suggested some
changes for re-upload. I've changed everything according to their
suggestions and uploaded to mentors[1]. There was a sponsor in 2016, but
he is not responding now. Can anyone look into this package!. Thank you.

[1].https://mentors.debian.net/package/php-db-dataobject

Regards --

Rajasekhar Ponakala

Bug#860804: marked as done (RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library)

[Debian Bug Tracking System]

Your message dated Tue, 25 Apr 2017 07:44:15 +0200
with message-id <20170425054415.bzelvnbf5kjqu...@angband.pl>
and subject line Re: Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] 
-- tensorflow dependency library
has caused the Debian Bug report #860804,
regarding RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency 
library
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
860804: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860804
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "highwayhash"

 * Package name: highwayhash
   Version : 0~20170419-g1f4a24f-1
   Upstream Author : google
 * URL : https://github.com/google/highwayhash
 * License : Apache-2.0
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/highwayhash


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

  Changes since the last upload:

highwayhash (0~20170419-g1f4a24f-1) experimental; urgency=medium

  * Initial release. (Closes: #848885)
--- End Message ---
--- Begin Message ---
On Tue, Apr 25, 2017 at 04:48:00AM +, Lumin wrote:
> > It does look uploadable, yeah, even though there's a bunch of issues.  It's
> > up to you whether you want to get it good first or to upload present state
> > then improve it incrementally.  Please say what you prefer.
> 
> I updated the package again with the following changes:
> 
>  * changed Multi-Arch of the lib package to same
>  * detect architecture in rules to privide HH_AARCH64 and HH_POWER
> flag to upstream makefile,
> which is possible to fix the arm64 and ppc64el builds. (oops, I
> have no such machines to test)

Alas, it failed on arm64 because of symbols file.  But then, C++ symbols are
so unpredictable I know of no better way than to run test builds and gather
the output.  This could be done on porterboxes but it takes less human time
to abuse the buildds.  This package is no libreoffice nor acl2, so the
burden on Debian infrastructure is negligible.

I didn't test on ppc* but it's probably same.

>  * added manpage highwayhash.3 (modified based on your snippet)
>  * added autopkgtest script (using modified version of your sanity test code)

> I think this package can be uploaded now. Further fix will be added
> incrementally.

Uploading something that works on amd64 allows packaging whatever you want
this library for, so let's get it past NEW then port it later.

> > On other architectures, the closest it came on x32 (a non-release arch) --
> > builds ok, fails only at dpkg-gensymbols due to symbol mismatches.
> > One warning: left shift count >= width of type [-Wshift-count-overflow]
> > sounds like it might be broken, though[1].
> >
> > On arm64 it fails with:
> > g++: error: unrecognized command line option '-mavx2'
> >
> > On armhf there's both the shift width issue, and:
> > error: #error "Port"
> >
> > On i386, all of the above, plus:
> > error: '_mm_cvtsi64_si128' was not declared in this scope
> 
> The HH_POWER and HH_AARCH64 flags are possible to fix the ppc64{,el} build and
> arm64 build. However, I'm not clear on upstream's attitude towards
> 32-bit architectures.
> 
> Actually I think 32-bit architectures are not my priority too, since
> upstreams of my deep learning packages don't put much attention on 32-bit
> architectures.

M'kay.  Unlike that deep learning thing, an universal hash is useful for
everyone, but it's not mandatory to do the porting.

> So I think this package can be uploaded now.

It's in NEW.

> Thank you for the manpage snippet, I've completed the manpage and
> added it to the -dev package.

I guess you gave me too much credit, I barely started it, copying in the
prototypes.


That's it for now, let's do a round 2 once the symbols files come in.

ᛗᛖᛟᚹ!
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!--- End Message ---

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Lumin]

Hi Adam,

> It does look uploadable, yeah, even though there's a bunch of issues.  It's
> up to you whether you want to get it good first or to upload present state
> then improve it incrementally.  Please say what you prefer.

I updated the package again with the following changes:

 * changed Multi-Arch of the lib package to same
 * detect architecture in rules to privide HH_AARCH64 and HH_POWER
flag to upstream makefile,
which is possible to fix the arm64 and ppc64el builds. (oops, I
have no such machines to test)
 * added manpage highwayhash.3 (modified based on your snippet)
 * added autopkgtest script (using modified version of your sanity test code)

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

I think this package can be uploaded now. Further fix will be added
incrementally.

> The bad news is, it succeeded only on amd64.
>
> On other architectures, the closest it came on x32 (a non-release arch) --
> builds ok, fails only at dpkg-gensymbols due to symbol mismatches.
> One warning: left shift count >= width of type [-Wshift-count-overflow]
> sounds like it might be broken, though[1].
>
> On arm64 it fails with:
> g++: error: unrecognized command line option '-mavx2'
>
> On armhf there's both the shift width issue, and:
> error: #error "Port"
>
> On i386, all of the above, plus:
> error: '_mm_cvtsi64_si128' was not declared in this scope

The HH_POWER and HH_AARCH64 flags are possible to fix the ppc64{,el} build and
arm64 build. However, I'm not clear on upstream's attitude towards
32-bit architectures.

Actually I think 32-bit architectures are not my priority too, since
upstreams of my
deep learning packages don't put much attention on 32-bit architectures.

So I think this package can be uploaded now.

> I assume you neither have access to porterboxes nor an array of hardware at
> home (and qemu can be tricky), so it might be easiest for you to abuse the
> buildds or someone who can test.

I have only an amd64 machine, so I plan to abuse the buildd.

> Other issues:
>
> Please add:
> Multi-Arch: same
> to libhighwayhash0's section in the control file.  You install stuff to the
> proper paths so there's no reason for it to be not coinstallable.

Done.

> Some simple docs would be nice -- RTFSing the headers is not pretty.
> This could work:

Thank you for the manpage snippet, I've completed the manpage and
added it to the -dev package.

> Manually mucking with optimization variant selection provides only a very
> minor speedup, so I wouldn't bother describing those.  Especially that with
> gcc-6 per-ISA variants can be bound at library load time -- if the library
> uses that functionality it could eliminate the overhead altogether.  That's
> a matter for the upstream, though.

I have no intention to make a exhaustive list of interfaces in the
manpage, neither.
Four examples from upstream README should be enough for the manpage use.
(see highwayhash.3)

> Lemme share a sanity test I used:

The snippet is modified and used as autopkgtest :-)

Thank you for the suggestions which make the package in a better quality!

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Adam Borowski]

On Fri, Apr 21, 2017 at 04:20:24AM +, Lumin wrote:
> Updated package was uploaded to mentors:
> https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc
> 
> Changes:
> * fixed the mistaken /lib//libxxx.a install path.
> The static library didn't drop
>   sip_tree_hash.o object.
> * patched upstream makefile to produce a shared object file
> (sip_tree_hash.o is dropped from so file)
> * added symbols control file
> * override dh_auto_test to run upstream test binaries (except for the
> "benchmark").
> 
> Is it acceptable now?

It does look uploadable, yeah, even though there's a bunch of issues.  It's
up to you whether you want to get it good first or to upload present state
then improve it incrementally.  Please say what you prefer.

The bad news is, it succeeded only on amd64.

On other architectures, the closest it came on x32 (a non-release arch) --
builds ok, fails only at dpkg-gensymbols due to symbol mismatches.
One warning: left shift count >= width of type [-Wshift-count-overflow]
sounds like it might be broken, though[1].

On arm64 it fails with:
g++: error: unrecognized command line option '-mavx2'

On armhf there's both the shift width issue, and:
error: #error "Port"

On i386, all of the above, plus:
error: '_mm_cvtsi64_si128' was not declared in this scope


I assume you neither have access to porterboxes nor an array of hardware at
home (and qemu can be tricky), so it might be easiest for you to abuse the
buildds or someone who can test.


Other issues:

Please add:
Multi-Arch: same
to libhighwayhash0's section in the control file.  You install stuff to the
proper paths so there's no reason for it to be not coinstallable.

Some simple docs would be nice -- RTFSing the headers is not pretty.
This could work:
.--[ highwayhash.3 ]
.TH highwayhash 3
.SH NAME
highwayhash \- fast strong 64-bit hash functions
.SH SYNOPSIS
.B #include 

uint64_t SipHashC(const uint64_t* key, const char* bytes, const uint64_t size);

uint64_t SipHash13C(const uint64_t* key, const char* bytes, const uint64_t 
size);

uint64_t HighwayHash64(const HHKey key, const char* bytes, const uint64_t size);

.SH DESCRIPTION
blah blah blah, SipHash wants an uint64_t[2] key while HighwayHash
uint64_t[4]
`
(with blah blah replaced with the prose)

The C interface looks more comfortable to use even from C++, so I'd describe
it first (or even exclusively for now).

Manually mucking with optimization variant selection provides only a very
minor speedup, so I wouldn't bother describing those.  Especially that with
gcc-6 per-ISA variants can be bound at library load time -- if the library
uses that functionality it could eliminate the overhead altogether.  That's
a matter for the upstream, though.



Lemme share a sanity test I used:
.--
#include 
#include 
#include 

static const uint64_t shkey[2]={0xdeadbeef,0xcafebabe};
static const HHKey hhkey={3,14,15,926}; // 4×uint64_t

int main()
{
printf("%016"PRIx64"\n", SipHashC(shkey, "meow", 4));
printf("%016"PRIx64"\n", SipHash13C(shkey, "meow", 4));
printf("%016"PRIx64"\n", HighwayHash64(hhkey, "meow", 4));
return 0;
}
 produces:
af0a25067c014659
600708416bfbe7ad
01aeb7e482f04c46
`


[1]. Such shifts produce only a warning, but are notorious for giving wrong
results:
int lines = 32;
u32 mask = (1 << lines) - 1;//  on x86
u32 mask = (1 << lines) - 1;//  on arm (32)
u32 mask = (1 << lines) - 1;//  on arm64
u32 mask = (1ULL << lines) - 1; //  everywhere
-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Lumin]

Hi Adam,

Thank you for reviewing this package!

Updated package was uploaded to mentors:
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

and debomatic:
http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

Changes:
* fixed the mistaken /lib//libxxx.a install path.
The static library didn't drop
  sip_tree_hash.o object.
* patched upstream makefile to produce a shared object file
(sip_tree_hash.o is dropped from so file)
* added symbols control file
* override dh_auto_test to run upstream test binaries (except for the
"benchmark").

Is it acceptable now?
:-)

On 20 April 2017 at 16:08, Adam Borowski  wrote:
> On Thu, Apr 20, 2017 at 10:35:41AM +, Lumin wrote:
>>   I am looking for a sponsor for my package "highwayhash"
>>
>>  * Package name: highwayhash
>>Upstream Author : google
>>  * URL : https://github.com/google/highwayhash
>
>>   It builds those binary packages:
>>
>> libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash
>
> You install the .a file into /lib, that's a place for important boot-time
> shared libraries, not for stuff that's used only during compilation.
>
> I see no shared library at all -- why do you provide only a static version?
> That's useful only for limited special uses, unfit for a general purpose
> library.  Static libs might sort-of work for Google's internal projects, as
> they have a centralized tightly managed infrastructure so "recompile world"
> for every single bug fix is doable, but in a loose ecosystem such as a
> distribution it's unfeasible.  You might get away with static libs if you
> closely cooperate with all of your reverse dependencies, but that's
> pointless for a library meant for wide use, such as hashes.
>
> Also, the SipTreeHash runs only a small set of CPUs and thus is useless for
> an universal distibution.  The other two hashes provide portable versions
> that work on every CPU of every arch, but as SipTreeHash gives a different
> output, its inclusion is kind of pointless.
>
>
> Your choices may differ, but I'd make the following changes:
> * provide a shared library
> * drop the static one -- or at least move it into the proper place
> * disable SipTreeHash, as failing at compile time rather than runtime is
>   nicer to users
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ Meow!
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
> ⠈⠳⣄ preimage for double rot13!



-- 
Best,
Lumin

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Adam Borowski]

On Thu, Apr 20, 2017 at 10:35:41AM +, Lumin wrote:
>   I am looking for a sponsor for my package "highwayhash"
> 
>  * Package name: highwayhash
>Upstream Author : google
>  * URL : https://github.com/google/highwayhash

>   It builds those binary packages:
> 
> libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash

You install the .a file into /lib, that's a place for important boot-time
shared libraries, not for stuff that's used only during compilation.

I see no shared library at all -- why do you provide only a static version? 
That's useful only for limited special uses, unfit for a general purpose
library.  Static libs might sort-of work for Google's internal projects, as
they have a centralized tightly managed infrastructure so "recompile world"
for every single bug fix is doable, but in a loose ecosystem such as a
distribution it's unfeasible.  You might get away with static libs if you
closely cooperate with all of your reverse dependencies, but that's
pointless for a library meant for wide use, such as hashes.

Also, the SipTreeHash runs only a small set of CPUs and thus is useless for
an universal distibution.  The other two hashes provide portable versions
that work on every CPU of every arch, but as SipTreeHash gives a different
output, its inclusion is kind of pointless.


Your choices may differ, but I'd make the following changes:
* provide a shared library
* drop the static one -- or at least move it into the proper place
* disable SipTreeHash, as failing at compile time rather than runtime is
  nicer to users

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "highwayhash"

 * Package name: highwayhash
   Version : 0~20170419-g1f4a24f-1
   Upstream Author : google
 * URL : https://github.com/google/highwayhash
 * License : Apache-2.0
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/highwayhash


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/highwayhash/0~20170419-g1f4a24f-1/buildlog

  Changes since the last upload:

highwayhash (0~20170419-g1f4a24f-1) experimental; urgency=medium

  * Initial release. (Closes: #848885)

Re: Bug#860690: crac: FTBFS on i386: build-dependency not installable: libjellyfish-2.0-dev

[Lucas Nussbaum]

On 19/04/17 at 11:28 +0200, Andreas Tille wrote:
> Hi Lucas,
> 
> could you please be more verbose why this is a RC bug?  Crac was never
> Build on i386 (neither was it on any other arch than amd64) exactly
> because this not installable Build-Dependency.  As far as I know there
> is no point in restricting the Build-Architectures explicitly since once
> the Build-Dependency would become available on some architecture several
> package might needed edits (may be several times for different
> architectures).
> 
> Am I missing something?

No, and I probably agree; see
https://lists.debian.org/debian-release/2017/04/msg00751.html

Lucas

Re: Bug#860690: crac: FTBFS on i386: build-dependency not installable: libjellyfish-2.0-dev

[Andreas Tille]

Hi Lucas,

could you please be more verbose why this is a RC bug?  Crac was never
Build on i386 (neither was it on any other arch than amd64) exactly
because this not installable Build-Dependency.  As far as I know there
is no point in restricting the Build-Architectures explicitly since once
the Build-Dependency would become available on some architecture several
package might needed edits (may be several times for different
architectures).

Am I missing something?

Kind regards

 Andreas.

On Wed, Apr 19, 2017 at 09:14:18AM +0200, Lucas Nussbaum wrote:
> Source: crac
> Version: 2.5.0+dfsg-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170418-i386 qa-ftbfs
> Justification: FTBFS in stretch on i386
> 
> Hi,
> 
> During a rebuild of all packages in stretch (in a stretch chroot, not a
> sid chroot), your package failed to build on i386.
> 
> Relevant part (hopefully):
> > +--+
> > | Install package build dependencies
> >|
> > +--+
> > 
> > 
> > Setup apt archive
> > -
> > 
> > Merged Build-Depends: debhelper (>= 9), dh-autoreconf, zlib1g-dev, 
> > libhts-dev, libjellyfish-2.0-dev, libgzstream-dev, libgkarrays-dev, 
> > pkg-config
> > Filtered Build-Depends: debhelper (>= 9), dh-autoreconf, zlib1g-dev, 
> > libhts-dev, libjellyfish-2.0-dev, libgzstream-dev, libgkarrays-dev, 
> > pkg-config
> > dpkg-deb: building package 'sbuild-build-depends-crac-dummy' in 
> > '/<>/resolver-s9bqGV/apt_archive/sbuild-build-depends-crac-dummy.deb'.
> > dpkg-scanpackages: warning: Packages in archive but missing from override 
> > file:
> > dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
> > sbuild-build-depends-crac-dummy
> > dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
> > Ign:1 copy:/<>/resolver-s9bqGV/apt_archive ./ InRelease
> > Get:2 copy:/<>/resolver-s9bqGV/apt_archive ./ Release [963 B]
> > Ign:3 copy:/<>/resolver-s9bqGV/apt_archive ./ Release.gpg
> > Get:4 copy:/<>/resolver-s9bqGV/apt_archive ./ Sources [542 B]
> > Get:5 copy:/<>/resolver-s9bqGV/apt_archive ./ Packages [623 B]
> > Fetched 2128 B in 0s (0 B/s)
> > Reading package lists...
> > W: No sandbox user '_apt' on the system, can not drop privileges
> > Reading package lists...
> > 
> > Install crac build dependencies (apt-based resolver)
> > 
> > 
> > Installing build dependencies
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > 
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-crac-dummy : Depends: libjellyfish-2.0-dev but it is 
> > not installable
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.
> 
> The full build log is available from:
>http://aws-logs.debian.net/2017/04/18/crac_2.5.0+dfsg-1_testing-i386.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Re: Move from asciidoc to asciidoc-base as build dependency

[Joseph Herlant]

Hi,

Another solution would be to do another change to the way the package
is split before the final release and make asciidoc be a metapackage
for asciidoc-base and not asciidoc-dblatex as proposed in #850301.

The caveat to that is that end users that were installing previous
versions of asciidoc (with the Recommends) will have to switch to
asciidoc-dblatex to keep the dblatex dependency.

Do you think it would be a better solution and generate less work for everybody?

Note that the split happened because several users were unhappy about
this dependency.

Thanks
Joseph

Re: Move from asciidoc to asciidoc-base as build dependency

[Gianfranco Costamagna]

Hi,

>I'm thinking how to make the Build-Depends fits both sid/stretch and

>jessie-backports.
>Whether the following is good enough? or appending the version is better?
>
>Build-Depends: asciidoc-base | asciidoc


backporting asciidoc should be the right solution here
(or reverting the change for backports, but since the affected packages
are many, I think a backport is preferred)

Alternative dependencies are not evaluated in Debian build machines.

G.

Move from asciidoc to asciidoc-base as build dependency

[Roger Shimizu]

[ CC mentors list ]

Dear Joseph,

I find this change affects many packages, so I CC mentors.

On Fri, Jan 6, 2017 at 1:17 PM, Joseph Herlant  wrote:
> Package: shadowsocks-libev
> Severity: wishlist
>
> Dear Maintainer,
>
> Asciidoc has been split in different packages in #637006 and #729242.
> This split has arrived in Testing.
>
> To lower the number of dependencies to install during the build, could
> you evaluate the switch of the build-depends from asciidoc to
> asciidoc-base instead of asciidoc please?
>
> asciidoc-base is enough to build manpages and html pages.

I'm thinking how to make the Build-Depends fits both sid/stretch and
jessie-backports.
Whether the following is good enough? or appending the version is better?

Build-Depends: asciidoc-base | asciidoc

Thanks!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: weird dependency-installbility problem of buildd

[Jakub Wilk]

* Lumin <cdlumin...@gmail.com>, 2016-07-28, 12:06:
Package caffe-contrib_1.0.0~rc3-2 [1][2] build-deps on CUDA 7.5.18, 
which is currently available for sid. This package passed the 
debomatic-amd64 build [3], however when buildd is working on this 
package it says there is "dependency installbility problem" [4].


But how can the existing "nvidia-cuda-toolkit_7.5.18-2" 
(sid/non-free)[5] be missing?


Does anyone know what happened there? Is this a bug?


Auto-building packages with non-free build-dependencies is not 
supported at this time: #690282


--
Jakub Wilk

weird dependency-installbility problem of buildd

[Lumin]

Hi mentors,

Package caffe-contrib_1.0.0~rc3-2 [1][2] build-deps on CUDA 7.5.18,
which is currently available for sid. This package passed
the debomatic-amd64 build [3], however when buildd is working on
this package it says there is "dependency installbility problem" [4].

But how can the existing "nvidia-cuda-toolkit_7.5.18-2" (sid/non-free)[5]
be missing?

Does anyone know what happened there? Is this a bug? Thanks.

[1] https://tracker.debian.org/pkg/caffe-contrib
​[2]
http://anonscm.debian.org/cgit/debian-science/packages/caffe-contrib.git/​
​[3]
http://debomatic-amd64.debian.net/distribution#experimental/caffe-contrib/1.0.0~rc3-2/buildlog
​
​[4]
https://buildd.debian.org/status/package.php?p=caffe-contrib=experimental
​
​[5]
https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit=sid
​


-- 
Best,
Lumin

Bug#829208: [PATCH] evil-paredit: relax dependency on paredit

[Dmitry Bogatov]

Hello!

I am now packaging your library evil-paredit for Debain. It declares
dependency on paredit "25beta", but

 * paredit-25beta upstream consider it unstable and advices aganist beeing 
packaged
 * seems evil-paredit works fine with paredit-24
 * seems commits 86d8ab33c, 6eea8638a explicitly add support for older versions 
of paredit

So, please consider patch inlined, that relaxes depedency on paredit till 24.

Also, git-tag'ing releases greatly simplify my work, consider making more tags.

From: Dmitry Bogatov <kact...@gnu.org>
Date: Sat, 2 Jul 2016 03:01:58 +0300
Subject: Relax dependency on paredit

25beta advices aganist distribution by APT, but 24 is good enough.
Forwarded: yes
---
 evil-paredit.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/evil-paredit.el b/evil-paredit.el
index 0df87be..99bbe01 100644
--- a/evil-paredit.el
+++ b/evil-paredit.el
@@ -14,7 +14,7 @@

 ;; URL: https://github.com/roman/evil-paredit

-;; Package-Requires: ((evil "1.0.9") (paredit "25beta"))
+;; Package-Requires: ((evil "1.0.9") (paredit "24"))

 ;;; Code:

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Paul Wise]

On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:

> 1) Use the nocheck build profile to build and upload f-el without
>running its tests.  Then build and upload shut-up and undercover.
>Then build and upload a full version of f-el.
>
> 2) Use the nocheck build profile to build and upload shut-up without
>running its tests.  Then build and upload f-el and undercover.
>Then build and upload a full version of shut-up.

I don't think you can upload binary packages using non-default build
profiles to the archive?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Jakub Wilk]

* Paul Wise , 2015-12-15, 18:43:

On Tue, Dec 15, 2015 at 6:09 AM, Sean Whitton wrote:

1) Use the nocheck build profile to build and upload f-el without 
running its tests.  Then build and upload shut-up and undercover. Then 
build and upload a full version of f-el.


2) Use the nocheck build profile to build and upload shut-up without 
running its tests.  Then build and upload f-el and undercover. Then 
build and upload a full version of shut-up.


I don't think you can upload binary packages using non-default build 
profiles to the archive?


You shouldn't upload them, but AFAICS dak wouldn't reject such an 
upload.


Perhaps we should add Lintian check for the Built-For-Profiles field, 
and ask ftp-masters to add the tag to the auto-reject list.


That said, the nocheck profile is supposed to have no effect on 
resulting binary packages, so probably uploading packages built with 
this profile activated wouldn't be a big deal...


--
Jakub Wilk

Re: f.el dependency loop (was: Re: Cask & dependencies)

[David Bremner]

Sean Whitton  writes:

>
> 3) Disable running f-el's test suite at package build time, but supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> 4) Disable running undercover.el's test suite at package build time, but 
> supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> What would be best?  Options (3) and (4) avoid introducing a new
> bootstrapping loop into the Debian archive.  But on the other hand maybe
> such a bootstrapping loop is okay because all these packages are
> architecture independent.

My initial opinion is to avoid a bootstrapping loop. That might be
partially because I've never really used build profiles before, but also
it seems to more or less double the number of sponsored uploads you'd
need.

d

Re: f.el dependency loop (was: Re: Cask & dependencies)

[Sean Whitton]

On Mon, Dec 14, 2015 at 09:04:00PM -0400, David Bremner wrote:
> My initial opinion is to avoid a bootstrapping loop. That might be
> partially because I've never really used build profiles before, but also
> it seems to more or less double the number of sponsored uploads you'd
> need.

I've dug a little deeper.  It turns out the circular chain of
dependencies are not actually required to run f's unit tests.  They are
only required for f.el's upstream continuous integration testing setup
(a setup not compatible with Debian CI, so far as I know).  I've been
able to use a quilt patch to scrub the dependency chain.

Sean


signature.asc
Description: Digital signature

f.el dependency loop (was: Re: Cask & dependencies)

[Sean Whitton]

Hello,

As I mentioned there's a dependency loop in building f-el [1].  This is
a library that a lot of Emacs addons depend on.  If we could get this
into the archive we would have dash-el, s-el and f-el all in Debian and
future dependency resolution would be much easier.

The problem is that f-el's test suite depends on undercover.el [2], which
depends on shut-up.el [3], but shut-up.el's test suite depends on f.el.

So far as I understand it, there are four options.

1) Use the nocheck build profile to build and upload f-el without
   running its tests.  Then build and upload shut-up and undercover.
   Then build and upload a full version of f-el.

2) Use the nocheck build profile to build and upload shut-up without
   running its tests.  Then build and upload f-el and undercover.
   Then build and upload a full version of shut-up.

3) Disable running f-el's test suite at package build time, but supply a
   autopkgtest so the tests will still get run in ci.debian.org.

4) Disable running undercover.el's test suite at package build time, but supply 
a
   autopkgtest so the tests will still get run in ci.debian.org.

What would be best?  Options (3) and (4) avoid introducing a new
bootstrapping loop into the Debian archive.  But on the other hand maybe
such a bootstrapping loop is okay because all these packages are
architecture independent.

Thanks.

Sean

[1] https://github.com/rejeep/f.el
[2] https://github.com/sviridov/undercover.el
[3] https://github.com/cask/shut-up


signature.asc
Description: Digital signature

Re: conditionally require dependency

[Nico Schlömer]

Thanks again, Josch!

The least painful thing for us to maintain is certainly the templating
idea. I now created a control.in, rules.in, ready to serve as templates for
the generation of the proper rules, control files. envsubst helps in
getting the templates values in [1].

Cheers,
Nico

[1]
https://bitbucket.org/fathomteam/moab/pull-requests/137/clean-up-debian-folder/diff#chg-debian/GNUmakefile



On Mon, Oct 26, 2015 at 8:55 AM Johannes Schauer <jo...@debian.org> wrote:

> Hi Nico,
>
> Quoting Nico Schlömer (2015-10-26 00:47:54)
> > particularly those which have been released a while ago and are closed
> > to adding now packages now.
>
> packages can be added via backports.
>
> > > - if you were talking about a *build* dependency, then you can generate
> > these
> > >   before building by having a debian/control.in and turning that into
> the
> > >   right debian/control depending on what you want to build
> >
> > Good idea. I'll look into it.
>
> remember that the other way I mentioned, having different git branches for
> different target distributions would also apply for your use case.
>
> > >  - alternatively, if you were talking about a *build* dependency you
> > could use
> > >build profiles to selectively enable or disable build dependencies
> >
> > Never heard of it. I'll check it out as well.
>
> This would work technically but there is no accepted way to do this in
> practice
> yet in Debian or Ubuntu. Build profiles allow you to select or unselect
> build
> dependencies depending on conditions you specify in the Build-Depends
> line. So
> technically it would be possible to say that a build dependency should
> only be
> used if the profiles "debian" and "unstable" are active and then when you
> build
> your source package you would have to take care to have the right profiles
> active per build with the DEB_BUILD_PROFILES environment variable or with
> the
> -P option to dpkg-buildpackage. There is more info on
> https://wiki.debian.org/BuildProfileSpec But remember that at this point
> this
> would just be another hack! While build profiles can be used this way to
> support multiple distributions and releases with a single debian/control
> file,
> there is not yet any decision (or even the attempt to have it) of how the
> build
> profiles should be named for this use case.
>
> cheers, josch
>

Re: conditionally require dependency

[Johannes Schauer]

Hi Nico,

Quoting Nico Schlömer (2015-10-26 00:47:54)
> particularly those which have been released a while ago and are closed
> to adding now packages now.

packages can be added via backports.

> > - if you were talking about a *build* dependency, then you can generate
> these
> >   before building by having a debian/control.in and turning that into the
> >   right debian/control depending on what you want to build
> 
> Good idea. I'll look into it.

remember that the other way I mentioned, having different git branches for
different target distributions would also apply for your use case.

> >  - alternatively, if you were talking about a *build* dependency you
> could use
> >build profiles to selectively enable or disable build dependencies
> 
> Never heard of it. I'll check it out as well.

This would work technically but there is no accepted way to do this in practice
yet in Debian or Ubuntu. Build profiles allow you to select or unselect build
dependencies depending on conditions you specify in the Build-Depends line. So
technically it would be possible to say that a build dependency should only be
used if the profiles "debian" and "unstable" are active and then when you build
your source package you would have to take care to have the right profiles
active per build with the DEB_BUILD_PROFILES environment variable or with the
-P option to dpkg-buildpackage. There is more info on
https://wiki.debian.org/BuildProfileSpec But remember that at this point this
would just be another hack! While build profiles can be used this way to
support multiple distributions and releases with a single debian/control file,
there is not yet any decision (or even the attempt to have it) of how the build
profiles should be named for this use case.

cheers, josch


signature.asc
Description: signature

Re: conditionally require dependency

[Johannes Schauer]

Hi Nico,

Quoting Nico Schlömer (2015-10-24 20:04:19)
> In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) depend on
> a rather new version of the [Metis](https://packages.debian.org/sid/metis)
> package, and that's what's enforced in our debian/control, too.

I cannot see any (build-)dependency on metis in your debian/control:

https://bitbucket.org/fathomteam/moab/src/HEAD/debian/control?at=master

> Now, we would like to provide MOAB for older versions of Debian/Ubuntu as
> well, and for those older distros would drop the optional Metis dependency.

Runtime dependency or build dependency?

> How is this situation best handled?

The best way to do this is to get your package into Debian. In that case the
content of debian/control will be different in testing/unstable as well as in a
backport that you can do for the current stable or oldstable.

Your problem arises because you want a one-size-fits-all of your upstream
debian/control. Such a one-size-fits-all often doesn't exist but having a
one-size-fits all is also usually not required because the packaging data
including debian/control between different Debian releases can be (and mostly
is) different.

If you do not want to get your package into Debian (and through there into
Ubuntu) but instead provide Debian/Ubuntu packages yourself as the upstream
project, I see these options:

 - have one git branch for every Debian/Ubuntu release you want to support and
   let them have different debian/control content depending on what is required

 - if you were talking about a *runtime* dependency earlier then you could just
   make it a Recommends

 - if you were talking about a *runtime* dependency but need a *strict*
   dependency then you can generate this dependency during package build time
   using a substvar (see man deb-substvars) in your Depends line

 - if you were talking about a *build* dependency, then you can generate these
   before building by having a debian/control.in and turning that into the
   right debian/control depending on what you want to build

 - alternatively, if you were talking about a *build* dependency you could use
   build profiles to selectively enable or disable build dependencies

Note, that all of these suggestions are *not* the right way to do things in
case your package is in Debian or Ubuntu itself. In this case your problem
doesn't arise in the first plae.

cheers, josch


signature.asc
Description: signature

Re: conditionally require dependency

[Jakub Wilk]

* Nico Schlömer , 2015-10-24, 18:04:
In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) 
depend on a rather new version of the 
[Metis](https://packages.debian.org/sid/metis) package, and that's 
what's enforced in our debian/control, too.


I don't see any mention of metis here:
https://bitbucket.org/fathomteam/moab/src/master/debian/control

--
Jakub Wilk

Re: conditionally require dependency

[Vijay S. Mahadevan]

Jakub, the necessary changes are part of PR# 137 in the MOAB repo [1].

Vijay

[1]
https://bitbucket.org/fathomteam/moab/pull-requests/137/clean-up-debian-folder
On Oct 25, 2015 4:52 PM, "Jakub Wilk"  wrote:

> * Nico Schlömer , 2015-10-24, 18:04:
>
>> In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally)
>> depend on a rather new version of the [Metis](
>> https://packages.debian.org/sid/metis) package, and that's what's
>> enforced in our debian/control, too.
>>
>
> I don't see any mention of metis here:
> https://bitbucket.org/fathomteam/moab/src/master/debian/control
>
> --
> Jakub Wilk
>

Re: conditionally require dependency

[Nico Schlömer]

Hi Josch,

Thanks a lot for your suggestions!

The reason why we want different build dependencies (which is indeed
what it is) for different versions is that we'd ideally like to
support older releases of Debian/Ubuntu from one code base,
particularly those which have been released a while ago and are closed
to adding now packages now.

> - if you were talking about a *build* dependency, then you can generate
these
>   before building by having a debian/control.in and turning that into the
>   right debian/control depending on what you want to build

Good idea. I'll look into it.

>  - alternatively, if you were talking about a *build* dependency you
could use
>build profiles to selectively enable or disable build dependencies

Never heard of it. I'll check it out as well.

Cheers,
Nico

On Sun, Oct 25, 2015 at 12:12 PM Johannes Schauer <jo...@debian.org> wrote:

> Hi Nico,
>
> Quoting Nico Schlömer (2015-10-24 20:04:19)
> > In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally)
> depend on
> > a rather new version of the [Metis](
> https://packages.debian.org/sid/metis)
> > package, and that's what's enforced in our debian/control, too.
>
> I cannot see any (build-)dependency on metis in your debian/control:
>
> https://bitbucket.org/fathomteam/moab/src/HEAD/debian/control?at=master
>
> > Now, we would like to provide MOAB for older versions of Debian/Ubuntu as
> > well, and for those older distros would drop the optional Metis
> dependency.
>
> Runtime dependency or build dependency?
>
> > How is this situation best handled?
>
> The best way to do this is to get your package into Debian. In that case
> the
> content of debian/control will be different in testing/unstable as well as
> in a
> backport that you can do for the current stable or oldstable.
>
> Your problem arises because you want a one-size-fits-all of your upstream
> debian/control. Such a one-size-fits-all often doesn't exist but having a
> one-size-fits all is also usually not required because the packaging data
> including debian/control between different Debian releases can be (and
> mostly
> is) different.
>
> If you do not want to get your package into Debian (and through there into
> Ubuntu) but instead provide Debian/Ubuntu packages yourself as the upstream
> project, I see these options:
>
>  - have one git branch for every Debian/Ubuntu release you want to support
> and
>let them have different debian/control content depending on what is
> required
>
>  - if you were talking about a *runtime* dependency earlier then you could
> just
>make it a Recommends
>
>  - if you were talking about a *runtime* dependency but need a *strict*
>dependency then you can generate this dependency during package build
> time
>using a substvar (see man deb-substvars) in your Depends line
>
>  - if you were talking about a *build* dependency, then you can generate
> these
>    before building by having a debian/control.in and turning that into the
>right debian/control depending on what you want to build
>
>  - alternatively, if you were talking about a *build* dependency you could
> use
>build profiles to selectively enable or disable build dependencies
>
> Note, that all of these suggestions are *not* the right way to do things in
> case your package is in Debian or Ubuntu itself. In this case your problem
> doesn't arise in the first plae.
>
> cheers, josch
>

conditionally require dependency

[Nico Schlömer]

Hi everyone,

In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) depend
on a rather new version of the [Metis](https://packages.debian.org/sid/metis)
package, and that's what's enforced in our debian/control, too. Now, we
would like to provide MOAB for older versions of Debian/Ubuntu as well, and
for those older distros would drop the optional Metis dependency.

How is this situation best handled?

Cheers,
Nico

RE:python-fabio circular dependency

[PICCA Frederic-Emmanuel]

> https://wiki.debian.org/PackageTransition

I know about this wiki page (very valuable), but my case is not described in 
here.


Cheers

Fred

Re: python-fabio circular dependency

[Gianfranco Costamagna]

Hi, 


Does this page help you?

https://wiki.debian.org/PackageTransition

unfortunately I don't know how to best solve this issue


cheers,

Gianfranco

Re: python-fabio circular dependency

[Jakub Wilk]

* PICCA Frederic-Emmanuel <frederic-emmanuel.pi...@synchrotron-soleil.fr>, 
2015-09-28, 20:12:
I want during the upgrade (python-fabio N)  -> python-fabio N+1 to 
install also the fabio_viewer. this way the user has the same amount of 
services on it system.

(python-fabio n contains also the scripts)

so I added a DEpends on fabio_viewer to pyton-fabio (n+1)

and now I have

fabio_viewer -> python-fabio -> fabio_viewer  and I got a bug report :)


This is #794153.


So what is the best way to solve my problem.

upgrade with same functionnality but without this circulardependency.
Indeed fabio_viewer MUST depends on python-fabio.


Demote the python-fabio -> fabio-viewer dependency to Recommends.

--
Jakub Wilk

python-fabio circular dependency

[PICCA Frederic-Emmanuel]

Hello, I would like to solve a circular dependency with the python-fabio package

before (N) binaries

python-fabio

after (N+1) binaries

fabio_viewer
python-fabio
python-fabio-dbg
python3-fabio
python3-fabio-dbg


for this new version, I move the /usr/bin files from python-fabio (N) into 
fabio_viewer (N+1).
So I did a split (script + python-module) of python-fabio (N) in two separate 
binary packages (fabio_viewer + python-fabio N+1)

Here is my problem

I want during the upgrade (python-fabio N)  -> python-fabio N+1 to install also 
the fabio_viewer.
this way the user has the same amount of services on it system.
(python-fabio n contains also the scripts) 

so I added a DEpends on fabio_viewer to pyton-fabio (n+1)

and now I have

fabio_viewer -> python-fabio -> fabio_viewer  and I got a bug report :)

So what is the best way to solve my problem.

upgrade  with same functionnality but without this circulardependency.
Indeed fabio_viewer MUST depends on python-fabio.


Thanks for your help

Frederic

Re: Bug#796917: snappy1.0.3-java: dependency on libsnappy1

[Gianfranco Costamagna]

Hi Andreas,


> libsnappy1 is being replaced by libsnappy1v5.
>  Your arch:all package has

>a hardcoded dependency on the former (how does that even work?).>
>
>Before I simply add a hardcoded libsnappy1v5 I would like to ask for
>comments whether there is some better way to solve this.


Well, I'm not a java expert, but in general this approach is wrong.

however snappy-java code seems smart enough to understand where to find the 
library
at runtime (this isn't a build-time dependency, but a runtime one) and use it.


I'm not sure there is a smarter approach, to let shlibs to its job, because 
snappy is
used as a plugin in this particular case, so hardcoding the libsnappy1v5 might 
be
the best way to do the trick.

Did you try if the package works on different architectures?

cheers,

G.

Re: Bug#796917: snappy1.0.3-java: dependency on libsnappy1

[Andreas Tille]

Hi,

I guess the current dependency was injected due to the fact that the original
upstream source contained a copy if libsnappy.so and

  src/main/java/org/xerial/snappy/LoadSnappy.java

says:

 * This class loads a native library of snappy-java (snappyjava.dll,
 * libsnappy.so, etc.) according to the user platform (os.name and
 * os.arch). The natively compiled libraries bundled to snappy-java
 * contain the codes of the original snappy and JNI programs to access Snappy.
 *
 * In default, no configuration is required to use snappy-java, but you can load
 * your own native library created by 'make native' command.
 * 
 * LoadSnappy searches for native libraries (snappyjava.dll, libsnappy.so, etc.)
 * in the following order:
 * 
 * (System property: org.xerial.snappy.lib.path)/(System property:
 * org.xerial.lib.name)
 * One of the libraries embedded in snappy-java-(version).jar extracted into
 * (System property: java.io.tempdir or if
 * org.xerial.snappy.tempdir is set, use this folder.)
 * Folders in LD_PATH environment variable (This is the default path that
 * JVM searches for native libraries)
 * 
 * 
 * 
 * If you do not want to use folder java.io.tempdir, set the System
 * property org.xerial.snappy.tempdir. For example, to use
 * /tmp/leo as a temporary folder to copy native libraries, use -D option


On Tue, Aug 25, 2015 at 09:50:30PM +0200, Julien Cristau wrote:
> Source: snappy1.0.3-java
> Version: 1.0.3-rc3~dfsg-5
> Severity: serious
> 
> libsnappy1 is being replaced by libsnappy1v5.  Your arch:all package has
> a hardcoded dependency on the former (how does that even work?).


Before I simply add a hardcoded libsnappy1v5 I would like to ask for
comments whether there is some better way to solve this.

Kind regards

   Andreas.

-- 
http://fam-tille.de

build dependency range

[Ole Streicher]

Hi,

I have a package (cpl) that in the past did build-depend from
libcfitsio3-dev, but now depends on libcfitsio-dev. I want to keep the
dependency from libcfitsio3-dev for easier backports.

The minimal version needed by cpl is 3.310.

The transition between libcfitsio-dev and libcfitsio3-dev was between
releases 3.340-3 and 3.370-1.

How do I specify this build dependency?

I tried:

Build-Depends: libcfitsio-dev (= 3.310)
 | libcfitsio3-dev (= 3.310)  libcfitsio3-dev ( 3.370-1)

and

Build-Depends: libcfitsio-dev (= 3.310)
 | (libcfitsio3-dev (= 3.310), libcfitsio3-dev ( 3.370-1))

and

Build-Depends: libcfitsio-dev (= 3.310) | libcfitsio3-dev (= 3.310,  3.370)

but all produce the error

dpkg-source: error: error occurred while parsing Build-Depends

So what should I set here?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878udglb9d@news.ole.ath.cx

Re: build dependency range

[Rebecca N. Palmer]

The valid way to specify libcfitsio-dev (= 3.310) or libcfitsio3-dev 
(= 3.310,  3.370) would be to use A|(BC) = (A|B)(A|C):


libcfitsio-dev (= 3.310) | libcfitsio3-dev (= 3.310), libcfitsio-dev 
(= 3.310) | libcfitsio3-dev ( 3.370)


but you probably don't actually need that: as libcfitsio3-dev = 3.370 
is an empty package depending on libcfitsio-dev,


libcfitsio-dev (= 3.310) | libcfitsio3-dev (= 3.310)

should be sufficient.

Note that libcfitsio-dev needs to be first as buildds only look at the 
first alternative.  I do not know if this rule also applies to 
backports, but given that jessie has 3.370 and wheezy 3.300, it won't be 
an issue for Debian backports anyway.



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553b88e2.2050...@zoho.com

Re: How to resolve circular build dependency?

[Thibaut Paumard]

Le 14/09/2014 06:32, hero...@gentoo.org a écrit :
 The concern of casacore{,-data} being out of sync might be resolved with
 two tarballs supported by quilt 3.0 format[2].  I am not sure how to
 implement it in a clean way by git-buildpackage.  Any examples
 available?

Dear Benda,

If you do that, each time one of the two packages is updated, the other
will also need to be needlessly re-built (on every single arch, for
casacore), re-uploaded to the archive (and its many mirrors), and
re-upgraded by every user. That's a lot of wasted CPU, bandwidth, and
hard-drive space.

Better to just use the bootstrapping scenario and leave the circular
build-dependency.

Kind regards, Thibaut.




signature.asc
Description: OpenPGP digital signature

How to resolve circular build dependency?

[Ole Streicher]

Dear mentors,

in debian-astro, we have a problem with a circular dependency on two
packages that are currently prepared [1], [2]:

- the casacore needs the casacore-data package for unit tests

- the casacore-data needs casacore to be build from the source data.

The source data of casacore-data are actually independent of casacore,
so it does not make sense to put both into one common package.

How can this problem be solved?

Best regards

Ole


[1] https://lists.debian.org/debian-astro/2014/09/msg8.html
[2] https://lists.debian.org/debian-astro/2014/09/msg9.html


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5414401a.30...@liska.ath.cx

Re: How to resolve circular build dependency?

[Alexander Wolf]

Hi!

2014-09-13 20:01 GMT+07:00 Ole Streicher debian-de...@liska.ath.cx:

 Dear mentors,

 in debian-astro, we have a problem with a circular dependency on two
 packages that are currently prepared [1], [2]:

 - the casacore needs the casacore-data package for unit tests

 - the casacore-data needs casacore to be build from the source data.

 The source data of casacore-data are actually independent of casacore,
 so it does not make sense to put both into one common package.

 How can this problem be solved?


A separate casacore-data on two packages - casacore-data 
casacore-tests?


-- 
With best regards, Alexander

Re: How to resolve circular build dependency?

[Mattia Rizzolo]

On Sep 13, 2014 3:01 PM, Ole Streicher debian-de...@liska.ath.cx wrote:

 Dear mentors,

 in debian-astro, we have a problem with a circular dependency on two
 packages that are currently prepared [1], [2]:

 - the casacore needs the casacore-data package for unit tests

 - the casacore-data needs casacore to be build from the source data.

 The source data of casacore-data are actually independent of casacore,
 so it does not make sense to put both into one common package.

 How can this problem be solved?


What's about upload casacore with the tests disabled, then upload
casacore-data, then re-upload casacore with the tests re-enabled?

Re: How to resolve circular build dependency?

[Ole Streicher]

Am 13.09.2014 um 15:09 schrieb Mattia Rizzolo:
 On Sep 13, 2014 3:01 PM, Ole Streicher debian-de...@liska.ath.cx wrote:
 - the casacore needs the casacore-data package for unit tests
 - the casacore-data needs casacore to be build from the source data.
 
 What's about upload casacore with the tests disabled, then upload
 casacore-data, then re-upload casacore with the tests re-enabled?

Still, the packages would have a circular build dependency, which I think 
should be avoided, right?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/541444a4.30...@liska.ath.cx

Re: How to resolve circular build dependency?

[Johannes Schauer]

Hi,

Quoting Ole Streicher (2014-09-13 15:20:36)
 Am 13.09.2014 um 15:09 schrieb Mattia Rizzolo:
  On Sep 13, 2014 3:01 PM, Ole Streicher debian-de...@liska.ath.cx wrote:
  - the casacore needs the casacore-data package for unit tests
  - the casacore-data needs casacore to be build from the source data.
  
  What's about upload casacore with the tests disabled, then upload
  casacore-data, then re-upload casacore with the tests re-enabled?
 
 Still, the packages would have a circular build dependency, which I think 
 should be avoided, right?

It is indeed nice to bootstrappers if circular build dependencies are avoided.
This is especially the case if a package has many reverse (build-)dependencies.

But there are two bootstrapping scenarios to consider. One is the one where
somebody wants to bootstrap a new architecture. The casacore-data binary
package sounds as if it is Architecture:all? In that case you should not worry
about circular build dependencies during bootstrapping for a new architecture
because the bootstrapper can just take an existing casacore-data binary package
to build first src:casacore and then src:casacore-data.

The other scenario is bootstrapping from nothing just for the sake of checking
bootstrappability of the archive including bootstrapping Architecture:all
packages. To be nice to bootstrappers you have several options:

 1. split the source package as Alexander Wolf suggested so that the unit tests
are in their own package and cascore can be built without cascore-data. You
could still run tests by using the cascore-unit-tests package as a
autopkgtest
 2. join src:casacore-data and src:casacore into a single source package and
handle bootstrapping of both via debian/rules
 3. make it such that src:casacore can be cross compiled from an existing
architecture so that src:casacore-data can be compiled natively after which
src:casacore can be compiled natively
 4. use build profiles once Jessie is released. Once Jessie is released, you
can 'tag' the build dependency of src:casacore on casacore-data with
!nocheck and then the build dependency would not be required when being
built with the nocheck profile active

Options 1-3 might make maintaining src:casacore and src:casacore-data very
difficult, so that together with the fact that neither is currently in Debian
and thus there are no reverse (build-)dependencies on it, you might want to
wait until Jessie is released and then use build profiles. Until you can use
build profiles, just write down in README.Source of both packages that this
build dependency cycle exists and how to best break it manually.

cheers, josch


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140913135312.3685.17954@hoothoot

Re: How to resolve circular build dependency?

[Mattia Rizzolo]

On Sep 13, 2014 3:20 PM, Ole Streicher debian-de...@liska.ath.cx wrote:
 Still, the packages would have a circular build dependency, which I think
should be avoided, right?


Well, compilers often build-depend on them own, which is even worse.
If a circular dependency could be avoided, better, but I don't care that
much.

I also guess the -data package is arch: all, so it wouldn't cause any issue
during bootstraps and the like (yet it would cause a issue to some
derivatives (guess which one) that rebuild all packages, but I wouldn't
care that much, a 5 minutes work on the package and then a manual sync it's
enough)

Re: How to resolve circular build dependency?

[Tomasz Buchert]

On 13/09/14 15:01, Ole Streicher wrote:
 Dear mentors,
 
 in debian-astro, we have a problem with a circular dependency on two
 packages that are currently prepared [1], [2]:
 
 - the casacore needs the casacore-data package for unit tests
 
 - the casacore-data needs casacore to be build from the source data.
 
 The source data of casacore-data are actually independent of casacore,
 so it does not make sense to put both into one common package.
 
 How can this problem be solved?
 
 Best regards
 
 Ole
 
 
 [1] https://lists.debian.org/debian-astro/2014/09/msg8.html
 [2] https://lists.debian.org/debian-astro/2014/09/msg9.html


Hi guys,
if I get this right, this is only build-time dependency, right?
What about merging both upstream sources into one source
package and build them at the same time into whatever binary
packages you want to have?

Cheers,
Tomasz


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140913163117.ga9...@buchert.pl

Re: How to resolve circular build dependency?

[heroxbd]

Hi Alexander,

Alexander Wolf alex.v.w...@gmail.com writes:

 Hi!

 A separate casacore-data on two packages - casacore-data 
 casacore-tests?

I don't see it feasible to separate. all the present contents of
casacore-data are needed for the test.

Cheers,
Benda


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/86egvex287@moguhome00.in.awa.tohoku.ac.jp

Re: How to resolve circular build dependency?

[heroxbd]

Hi Gijs and Tomasz,

Gijs Molenaar gijsmolen...@gmail.com writes:

 i don't think that would work, the releases of casacore-data and
 casacore are not in sync.

 2014-09-13 18:31 GMT+02:00 Tomasz Buchert tomasz.buch...@inria.fr:

 Hi guys,
 if I get this right, this is only build-time dependency, right?
 What about merging both upstream sources into one source
 package and build them at the same time into whatever binary
 packages you want to have?

This is a good idea, also covered by Johannes Schauer on debian-mentors[1]

  2. join src:casacore-data and src:casacore into a single source package and
 handle bootstrapping of both via debian/rules

The concern of casacore{,-data} being out of sync might be resolved with
two tarballs supported by quilt 3.0 format[2].  I am not sure how to
implement it in a clean way by git-buildpackage.  Any examples
available?

Cheers,
Benda

1. https://lists.debian.org/debian-mentors/2014/09/msg00267.html
2. 
http://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/867g16x1n4@moguhome00.in.awa.tohoku.ac.jp

Re: How to resolve circular build dependency?

[heroxbd]

Alexander Wolf alex.v.w...@gmail.com writes:

 A separate casacore-data on two packages - casacore-data 
 casacore-tests?

Sorry Alexander, I misunderstood your point at the first sight.

As later Johannes Schauer put more precisely,

 1. split the source package as Alexander Wolf suggested so that the
 unit tests are in their own package and cascore can be built without
 cascore-data. You could still run tests by using the
 cascore-unit-tests package as a autopkgtest

spliting out test suits from casacore would work.  I expect merging
tarballs would be easier than splitting (single-point-of-truth?[1]), so I
will test out the single source package solution first.

Thanks for the suggestion.

Cheers,
Benda

1. http://en.wikipedia.org/wiki/Single_Source_of_Truth

   The testsuit is written in ctest together with cmake, decoupling it
   might be hard.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8638bux0ld@moguhome00.in.awa.tohoku.ac.jp

Re: Bug#761134: [Help] strange 'missing-dependency-on-perlapi' lintian warning

[Jakub Wilk]

* Andreas Tille andr...@an3as.eu, 2014-09-11, 22:31:
I would like to upload libsbml5 but despite the fact that 
${perl:Depends} is specified and dh calls dh_perl automatically this 
lintian error occures.  To enable easy inspection I have uploaded the 
preliminary packages to


  https://people.debian.org/~tille/packages/libsmbl5/


dh_perl can't find the Perl modules, because they were installed into 
wrong directory:


$ dpkg -c libsbml5-perl_5.10.0+dfsg-1_amd64.deb | grep -E '[.](pm|so)$'
-rw-r--r-- root/root  14460736 2014-09-11 13:31 
./usr/lib/perl5/site_perl/5.20.0/x86_64-linux-gnu-thread-multi/auto/libSBML/LibSBML.so
-rw-r--r-- root/root   2688864 2014-09-11 12:22 
./usr/lib/perl5/site_perl/5.20.0/x86_64-linux-gnu-thread-multi/LibSBML.pm

But the correct place to install arch-specific Perl modules is:

$ perl -MConfig -E'say $Config{vendorarch}'
/usr/lib/x86_64-linux-gnu/perl5/5.20

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912084058.ga9...@jwilk.net

Re: [Debian-med-packaging] Bug#761134: [Help] strange 'missing-dependency-on-perlapi' lintian warning

[Ivo Maintz]

Jakub Wilk jw...@debian.org schrieb :

 * Andreas Tille andr...@an3as.eu, 2014-09-11, 22:31:
 I would like to upload libsbml5 but despite the fact that 
 ${perl:Depends} is specified and dh calls dh_perl automatically this 
 lintian error occures.  To enable easy inspection I have uploaded
 the preliminary packages to
 
https://people.debian.org/~tille/packages/libsmbl5/
 
 dh_perl can't find the Perl modules, because they were installed into 
 wrong directory:
 
 $ dpkg -c libsbml5-perl_5.10.0+dfsg-1_amd64.deb | grep -E
 '[.](pm|so)$' -rw-r--r-- root/root  14460736 2014-09-11
 13:31 
 ./usr/lib/perl5/site_perl/5.20.0/x86_64-linux-gnu-thread-multi/auto/libSBML/LibSBML.so
 -rw-r--r-- root/root   2688864 2014-09-11
 12:22 
 ./usr/lib/perl5/site_perl/5.20.0/x86_64-linux-gnu-thread-multi/LibSBML.pm
 
 But the correct place to install arch-specific Perl modules is:
 
 $ perl -MConfig -E'say $Config{vendorarch}'
 /usr/lib/x86_64-linux-gnu/perl5/5.20
 
Thanks for the hint, I'll try to fix this soon.

Ivo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912113447.57988a57@orm

Re: [Debian-med-packaging] Bug#761134: [Help] strange 'missing-dependency-on-perlapi' lintian warning (Was: Bug#761134: libsbml5-perl: Depends on libperl5.18 but should be libperl5.20 now)

[Ivo Maintz]

Hi,

Eriberto eribe...@eriberto.pro.br schrieb :

 Hi Andreas,
 
 I didn't see the package. However, it can be a false positive from new
 Lintian. I already had three false positives from new checks.
 
 Please, see the bugs of the Lintian in BTS to identify if it is or not
 a false positive.

If I look into the package, it seems, lintian is right. In the package
libsbml5-perl_5.10.0+dfsg-1_amd64.deb DEBIAN/control misses an entry for
perlapi-$Config{version}.

$LIBSBML_SOURCES/debian/control contains

Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}

And in the build logs I can see the dh_perl call:
[...]
make[1]: Leaving directory '/«BUILDDIR»/libsbml-5.10.0+dfsg'
   dh_install -a -O--with-python2 -O--dbg-package=libsbml5-dbg
   dh_installdocs -a -O--with-python2 -O--dbg-package=libsbml5-dbg
   dh_installchangelogs -a -O--with-python2 -O--dbg-package=libsbml5-dbg
   dh_perl -a -O--with-python2 -O--dbg-package=libsbml5-dbg
[...]

https://lintian.debian.org/tags/missing-dependency-on-perlapi.html
says, that this should be sufficient to get the right entry.

I'm shure, this error is quite new.

 I hope this help.
 
 Cheers,
 
 Eriberto
 
 
 2014-09-11 17:31 GMT-03:00 Andreas Tille andr...@an3as.eu:
  Hi,
 
  I would like to upload libsbml5 but despite the fact that
  ${perl:Depends} is specified and dh calls dh_perl automatically this
  lintian error occures.  To enable easy inspection I have uploaded
  the preliminary packages to
 
 https://people.debian.org/~tille/packages/libsmbl5/
 
  Any help to fix this lintian problem is welcome
 
  Andreas.
 
  On Thu, Sep 11, 2014 at 09:27:39AM -0700, Steve Lane wrote:
  Thanks very much.  Now I guess I wait for it to show up on the
  webpage and in the repo, yes..?
 
  Best,
 
  --
  Steve Lane
 
  On Sep 11 09:24, Andreas Tille wrote:
   Hi,
  
   I think a package rebuild should be sufficient to close this bug.
   Thus I commited
  
 * rebuild with latest libperl
   Closes: #761134
  
   to the changelog.
  
   Ivo,  it is *really* high time to upload libsbml if we want to
   deliver it in Jessie.  Do you have any idea why the current
   state of SVN does not build on other machines.  Please
   communicate your problems or lets consult debian-mentors.  We
   are really short in time before the freeze (2014-11-05).
  
   Kind regards
  
Andreas.
  
 
 
 
  --
  http://fam-tille.de
 
 
  --
  To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
  with a subject of unsubscribe. Trouble? Contact
  listmas...@lists.debian.org Archive:
  https://lists.debian.org/20140911203113.ga30...@an3as.eu
 
 
 ___
 Debian-med-packaging mailing list
 debian-med-packag...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912113313.5bdbaef4@orm

Re: [Debian-med-packaging] Bug#761134: [Help] strange 'missing-dependency-on-perlapi' lintian warning

[Ivo Maintz]

Hi Gregor,

gregor herrmann gre...@debian.org schrieb :

 Control: tag -1 + patch
[...]
 That's usually caused by a build system which uses INSTALLDIRS=site,
 which should be vendor ... And in practice left out in Debian since
 our toolery sets it.
 
 Here we are:
 
 % grep -ir installdirs *
 [..]
 src/bindings/perl/Makefile.PL.in:  INSTALLDIRS = site,
 
 
 Oh, and then we have
 
 src/bindings/perl/CMakeLists.txt:  set(PERL_PACKAGE_INSTALL_DIR
 ${CMAKE_INSTALL_LIBDIR}/perl5/site_perl/${PERL_VERSION}/${PERL_PLATFORM})
 
 Ouch!
 
 
 I'm attaching two patches (the first being hacky and without DEP3
 headers) that seem to work, as in place the perl modules into the
 right directory and getting the dependencies on perl(api) right.

These patches fixes it, thanks for your help.

Cheers,

Ivo


signature.asc
Description: PGP signature

Re: [Help] strange 'missing-dependency-on-perlapi' lintian warning (Was: Bug#761134: libsbml5-perl: Depends on libperl5.18 but should be libperl5.20 now)

[Dominic Hargreaves]

On Thu, Sep 11, 2014 at 09:45:07PM +0100, Daniel Lintott wrote:
 On 11/09/14 21:31, Andreas Tille wrote:
  Hi,
  
  I would like to upload libsbml5 but despite the fact that
  ${perl:Depends} is specified and dh calls dh_perl automatically this
  lintian error occures.  To enable easy inspection I have uploaded the
  preliminary packages to
  
 https://people.debian.org/~tille/packages/libsmbl5/
  
  Any help to fix this lintian problem is welcome

The package is installing files into 

/usr/lib/perl5/site_perl/5.20.0/x86_64-linux-gnu-thread-multi/

This is not the correct path to be installing perl XS modules[1]
(and never was; I can't see why this has changed from [2] though).
As a result dh_perl doesn't find the modules.

Instead, please install to the path printed by:

perl -MConfig -e 'print $Config{vendorarch}'

Something like the attached, completely untested patch might work.

Cheers,
Dominic.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748380
[2] https://packages.debian.org/sid/i386/libsbml5-perl/filelist
--- src/bindings/perl/CMakeLists.txt	2014-04-09 07:22:46.0 +
+++ src/bindings/perl/CMakeLists.txt.new	2014-09-13 00:28:54.0 +
@@ -162,13 +162,13 @@
   string(REPLACE ;  PERL_VERSION ${PERL_VERSION})
   string(REPLACE version=  PERL_VERSION ${PERL_VERSION})
   string(REPLACEPERL_VERSION ${PERL_VERSION})
-  execute_process(COMMAND ${PERL_EXECUTABLE} -V:archname
-OUTPUT_VARIABLE PERL_PLATFORM OUTPUT_STRIP_TRAILING_WHITESPACE)
-  string(REPLACEPERL_PLATFORM ${PERL_PLATFORM})
-  string(REPLACE '  PERL_PLATFORM ${PERL_PLATFORM})
-  string(REPLACE ;  PERL_PLATFORM ${PERL_PLATFORM})
-  string(REPLACE archname=  PERL_PLATFORM ${PERL_PLATFORM})
-  set(PERL_PACKAGE_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR}/perl5/site_perl/${PERL_VERSION}/${PERL_PLATFORM})
+  execute_process(COMMAND ${PERL_EXECUTABLE} -V:vendorarch
+OUTPUT_VARIABLE PERL_VENDORARCH OUTPUT_STRIP_TRAILING_WHITESPACE)
+  string(REPLACEPERL_VENDORARCH ${PERL_VENDORARCH})
+  string(REPLACE '  PERL_VENDORARCH ${PERL_VENDORARCH})
+  string(REPLACE ;  PERL_VENDORARCH ${PERL_VENDORARCH})
+  string(REPLACE vendorarch=  PERL_VENDORARCH ${PERL_VENDOARCH})
+  set(PERL_PACKAGE_INSTALL_DIR ${PERL_VENDOARCH})
   set(PERL_PACKAGE_INSTALL_BIN_DIR ${PERL_PACKAGE_INSTALL_DIR}/auto/libSBML)
 else()
   set(PERL_PACKAGE_INSTALL_DIR ${MISC_PREFIX}bindings/perl)