[RFC] Adding pkg-config to build-essential
Hi, I wonder if nowadays pkg-config would qualify as Build-Essential. We have 2400 source packages listing it as explicit Build-Depends and countless -dev packages pulling in pkg-config. So the list of packages requiring pkg-config during build is potentially much longer. At which point do we consider a package Build-Essential? It's not like every package actually uses gcc or make during build either. Aside from the sheer number of packages requiring pkg-config, adding it to build-essential would be an endorsement of pkg-config as the one right tool to detect dependencies during configure. Thoughts? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#838083: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: metaphlan2 Version : 2.6.0 Upstream Author : Duy Tin Truong, Nicola Segata and Curtis Huttenhower * URL : https://bitbucket.org/biobakery/metaphlan2 * License : MIT Programming Lang: Python Description : Metagenomic Phylogenetic Analysis MetaPhlAn is a computational tool for profiling the composition of microbial communities (Bacteria, Archaea, Eukaryotes and Viruses) from metagenomic shotgun sequencing data with species level resolution. From version 2.0, MetaPhlAn is also able to identify specific strains (in the not-so-frequent cases in which the sample contains a previously sequenced strains) and to track strains across samples for all species. . MetaPhlAn 2.0 relies on ~1M unique clade-specific marker genes (the marker information file can be found at src/utils/markers_info.txt.bz2 or here) identified from ~17,000 reference genomes (~13,500 bacterial and archaeal, ~3,500 viral, and ~110 eukaryotic), allowing: . * unambiguous taxonomic assignments; * accurate estimation of organismal relative abundance; * species-level resolution for bacteria, archaea, eukaryotes and viruses; * strain identification and tracking * orders of magnitude speedups compared to existing methods. * metagenomic strain-level population genomics Remark: The large dataset that is contained in the download archive was split up into a separate package metaphlan2-data since it is shipped in a better compressible format and also will not change that frequently as the code. The package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/metaphlan2.git
Re: [RFC] Adding pkg-config to build-essential
Michael Biebl wrote: > I wonder if nowadays pkg-config would qualify as Build-Essential. > > We have 2400 source packages listing it as explicit Build-Depends and > countless -dev packages pulling in pkg-config. So the list of packages > requiring pkg-config during build is potentially much longer. > > At which point do we consider a package Build-Essential? > It's not like every package actually uses gcc or make during build either. > > Aside from the sheer number of packages requiring pkg-config, adding it > to build-essential would be an endorsement of pkg-config as the one > right tool to detect dependencies during configure. I don't think we should add any more packages to build-essential. If anything, I'd like to see both Essential and build-essential decrease in favor of explicit dependencies, which makes it easier to replace components. I don't think "many packages list it" justifies adding to build-essential. We don't need the minimal size reduction in the Packages file, and I don't think this would remove logical complexity, since you still have to know that build-essential has it. I can't think of anything this would buy us, other than a few bytes in the Packages file.
Re: [RFC] Adding pkg-config to build-essential
Am 17.09.2016 um 12:24 schrieb Josh Triplett: > I can't think of anything this would buy us, other than a few bytes in > the Packages file. It's a valid question. I guess I need to explain what triggered this email. A couple of days ago I uploaded a new version of gtk-doc-tools (to experimental) which dropped the dependency on gnome-common. This dependency has been added a long time ago and is no longer valid today. gnome-common on the other hand pulls in a bunch of other packages, among them pkg-config. Dropping that gnome-common dependency from gtk-doc-tools made quite a few packages FTBFS, because some relied on pkg-config to be pulled in "somehow". Having to add pkg-config as explicit Build-Depends causes churn in this particular case. Given the ubiquituous use of pkg-config I was wondering if we shouldn't just declare it as available. I'm pretty sure there are many more cases where a package needs pkg-config to build but doesn't declare it in Build-Depends because pkg-config is pulled in via transitive dependencies. If that dependency chain is broken at some point this would cause build failures. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#838095: ITP: python-k8sclient -- Kubernetes API python client code
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-k8sclient Version : 0.3.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/python-ks8client * License : Apache-2.0 Programming Lang: Python Description : Kubernetes API python client code K8sclient is the Kubernetes API python client code. This code is generated by swagger-codegen. Kubernetes provide swagger-spec to generate client code for different versions.
Re: Debian does not have customers, but users
On 2016-09-16 21:26, Nicholas D Steeves wrote: > What about the term client? ;-) What about the term "users"? (We use the word already in our social contract and IMHO it serves us well.)
Bug#838101: ITP: python-azure -- Microsoft Azure SDK for Python
Package: wnpp Severity: wishlist Owner: "Iain R. Learmonth" * Package name: python-azure Version : 2.0.0 Upstream Author : Microsoft * URL : https://github.com/lmazuel/azure-sdk-for-python * License : MIT / Apache Programming Lang: Python Description : Microsoft Azure SDK for Python This project provides a set of Python packages that make it easy to access the Microsoft Azure components such as ServiceManagement, Storage, and ServiceBus. - This software is currently available via GitHub as a release candidate. I've been playing with it and it's definitely not polished yet. Ansible has some support for using this SDK though I've not yet managed to make it work. I believe that the SDK has presented Ansible with a moving target recently and that's likely the reason for the breakage. The Git repository contains a number of Python packages, and this bug will either be closed by packaging them all as a single source package or it will track the progress of packaging the individual packages using PyPI as the upstream to Debian. This is dependent on whether or not the upstream author expects that all the packages would be installed at the same version of if releases of packages (in this case, PyPI uploads I guess) would happen independently of other packages once the API is stable.
Re: [RFC] Adding pkg-config to build-essential
Hi! On Sat, 2016-09-17 at 11:26:05 +0200, Michael Biebl wrote: > I wonder if nowadays pkg-config would qualify as Build-Essential. I don't think so. > We have 2400 source packages listing it as explicit Build-Depends and > countless -dev packages pulling in pkg-config. So the list of packages > requiring pkg-config during build is potentially much longer. As a counter example debhelper is used by almost all packages in Debian, yet it's not build-essential (in part because you always need to specify a versioned dependency, but still), I guess there might be other similar examples. > At which point do we consider a package Build-Essential? > It's not like every package actually uses gcc or make during build either. If you had picked g++ that would have been a better example. :) But make is used by all our sources via debian/rules, and gcc is used also by all our sources via dpkg-architecture (both of which are not strong dependencies by dpkg-dev, and should not be). My question would be instead, why should we keep g++ as build-essential? > Aside from the sheer number of packages requiring pkg-config, adding it > to build-essential would be an endorsement of pkg-config as the one > right tool to detect dependencies during configure. I don't think Essential/build-essential are the right tools for this kind of endorsements. Also, from your later message, I see where you are coming from, but then I also think if the dependencies have accidentally become implicit due to something else pulling them, the correct course of action (even if painful!) is to fix those dependencies. Thanks, Guillem
Bug#838121: ITP: msrest - AutoRest swagger generator Python client runtime
Package: wnpp Severity: wishlist Owner: "Antoine R. Dumont" * Package name: python-msrest Version : 0.4.3 Upstream Author : Microsoft * URL : https://github.com/Azure/autorest * License : MIT Programming Lang: Python Description : AutoRest swagger generator Python client runtime. This project provides a tool to generate restful client library for python to access RESTful web services. signature.asc Description: PGP signature
Bug#838122: ITP: msrestazure - Azure-specific autorest swagger generator Python client runtime
Package: wnpp Severity: wishlist Owner: "Antoine R. Dumont" * Package name: python-msrestazure Version : 0.4.2 Upstream Author : Microsoft * URL : https://github.com/Azure/autorest * License : MIT Programming Lang: Python Description : Azure-specific autorest swagger generator Python client runtime. This project provides a tool to generate restful client library for python to access azure's RESTful web services. signature.asc Description: PGP signature
Bug#838123: ITP: tendermint -- simple, secure, scalable Blockchain platform
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: tendermint Version : 0.7.1 Upstream Author : the Tendermin project * URL : http://tendermint.com/ * License : Apache-2.0 Programming Lang: Go Description : simple, secure, scalable Blockchain platform Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine, written in any programming language, and replicates it on many machines. I'm planning to maintain this under the Debian Go packaging team's umbrella.
Bug#838128: ITP: tmsp -- the Tendermint Socket Protocol
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: tmsp Version : Git snapshot Upstream Author : the Tendermint project * URL : http://www.tendermint.com * License : Apache-2.0 Programming Lang: Go Description : Tendermint Socket Protocol TMSP is a socket protocol enabling a blockchain consensus engine, running in one process, to manage a blockchain application state, running in another. Blockchains are a system for creating shared multi-master application state. If one wanted to create a Bitcoin-like system on top of TMSP, Tendermint Core would be responsible for: - Sharing blocks and transactions between nodes - Establishing a canonical/immutable order of transactions (the blockchain) The application will be responsible for: - Maintaining the Unspent Transaction Output (UTXO) database - Validating cryptographic signatures of transactions - Preventing transactions from spending non-existent transactions - Allowing clients to query the UTXO database. I'm planning to maintain this under the Debian Go packaging team's umbrella.
Re: [RFC] Adding pkg-config to build-essential
2016-09-17 14:06 Guillem Jover: On Sat, 2016-09-17 at 11:26:05 +0200, Michael Biebl wrote: At which point do we consider a package Build-Essential? It's not like every package actually uses gcc or make during build either. If you had picked g++ that would have been a better example. :) But make is used by all our sources via debian/rules, and gcc is used also by all our sources via dpkg-architecture (both of which are not strong dependencies by dpkg-dev, and should not be). My question would be instead, why should we keep g++ as build-essential? Would perhaps meta-packages like for example "build-essential-c++" be worth considering? Or do you think that g++ should be taken away and depended upon explicitly in all cases? Aside from the sheer number of packages requiring pkg-config, adding it to build-essential would be an endorsement of pkg-config as the one right tool to detect dependencies during configure. I don't think Essential/build-essential are the right tools for this kind of endorsements. Also, from your later message, I see where you are coming from, but then I also think if the dependencies have accidentally become implicit due to something else pulling them, the correct course of action (even if painful!) is to fix those dependencies. I'm all for fixing this kind of things in the general case, but in the case of Debian, having to do uploads for thousands of packages is the kind of change that it's a real PITA to implement (and if undertaken, takes years to complete, if ever). Cheers. -- Manuel A. Fernandez Montecelo
Re: removal instead of orphaning?
2016-08-28 21:50 Sean Whitton: Hello, On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez Montecelo wrote: I think that one measure to improve the current situation is that, for the people doing NMUs, to orphan the package when the number of NMUs exceeds for example 3 or 5 in a row, or 1 year since the oldest NMU not acked by the maintainers and there are bugs or reasons requiring new intervention. (Exceptions can apply if there are specific reasons to avoid to do that, e.g. keep packages as part of a team). With this, future NMUs will be QA uploads. If there's a general agreement that this is a good thing, and somehow becomes part of the NMU process or similar guidelines [2], it would help to avoid conflicts. If you have time to make this idea into a patch, a bug against developers-reference would be a good place to discuss it. I failed to do this in the last few weeks and it looks like the next will be worse in terms of spare time, so I'll see what I can do, but I cannot promise anything :-/ Also, I hoped to gather some feedback to the message at least, to see if the above looks reasonable to most people. Cheers. -- Manuel A. Fernandez Montecelo
Bug#838150: ITP: itktools -- command line tools based on the ITK, intended for image processing
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: itktools Version : 0.3.2 Upstream Author : Marius Staring, Stefan Klein, David Doria * URL : https://github.com/ITKTools/ITKTools * License : Apache 2.0 Programming Lang: C++ Description : command line tools based on the ITK, intended for image processing Practical command line tools based on the ITK, intended for image processing. These tools are designed to take one or more input image(s) from the command line, perform a single operation, and produce an output image. For example smoothing of an image can be done with the tool pxgaussianimagefilter. Note: these tools (specifically pxcastconvert) are required to run the Elastix test suite.
Bug#838156: ITP: haskell-raaz -- crytographic networking library for Haskell
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: haskell-raaz Version : 0.0.2 Upstream Author : Piyush P Kurur * URL : https://github.com/raaz-crypto/raaz * License : BSD-3-clause Programming Lang: Haskell Description : crytographic networking library for Haskell I'm packaging this as a dependency of keysafe, another ITP of mine, I intend to maintain it as part of the Haskell team. -- Sean Whitton signature.asc Description: PGP signature
Re: removal instead of orphaning?
On Sun, Sep 18, 2016 at 2:53 AM, Manuel A. Fernandez Montecelo wrote: > 2016-08-28 21:50 Sean Whitton: >> On Sun, Aug 28, 2016 at 10:13:44AM +0100, Manuel A. Fernandez Montecelo >> wrote: >>> >>> I think that one measure to improve the current situation is that, for >>> the people doing NMUs, to orphan the package when the number of NMUs >>> exceeds for example 3 or 5 in a row, or 1 year since the oldest NMU not >>> acked by the maintainers and there are bugs or reasons requiring new >>> intervention. (Exceptions can apply if there are specific reasons to >>> avoid to do that, e.g. keep packages as part of a team). With this, >>> future NMUs will be QA uploads. >>> >>> If there's a general agreement that this is a good thing, and somehow >>> becomes part of the NMU process or similar guidelines [2], it would help >>> to avoid conflicts. >> >> >> If you have time to make this idea into a patch, a bug against >> developers-reference would be a good place to discuss it. > > > I failed to do this in the last few weeks and it looks like the next > will be worse in terms of spare time, so I'll see what I can do, but I > cannot promise anything :-/ > > Also, I hoped to gather some feedback to the message at least, to see if > the above looks reasonable to most people. With the BTS version tracking feature, acking NMUs is no longer needed as the BTS tracks changelog heritage IIRC, so I'd not mention that in the description. -- bye, pabs https://wiki.debian.org/PaulWise
