Re: Experimental ddeb support in debhelper and lintian
On 2015-04-11 07:14, Niels Thykier wrote: > [...] > >> Stretch is a two year time frame though, which makes me kinda sad. Thanks >> for you effort though, keep up the amazing work! If I understand correctly, >> if >> it would have been something for stretch, either A or B would have been >> decided already and partly implemented, right? > > I believe we can implement this for Stretch if we wanted to. Unlike > multi-arch, build-profiles (etc.), ddebs are already supported by our > (14-days-from-now-new) stable release. Namely, > > * All the groundwork requirements (pkg:arch dependencies etc.) are >already covered by previous efforts. >- I.e. everything that would require a full-cycle for support are > already done in time for Jessie > Hah, I take that inside the parentheses back. It seems that APT is *not* very happy with the generated "pkg:arch" dependencies. Fortunately, this syntax is not required for ddebs. > [...] > * Known list of tools where support is (very) "nice-to-have", but not a >strict blocker. >- lintian - though people on d-mentors might disagree. ;) >- reprepro and similar >- others? > [...] As noted on IRC, mentors.debian.net / debexpo will probably need to be updated too (at least if we go the "ddebs" route). Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5528cb44.4030...@thykier.net
Bug#782375: ITP: python-sphinx-patchqueue -- Sphinx extension for embedding sequences of file alterations
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: python-sphinx-patchqueue Version: 1.0 Upstream Author: Xavier Morel License: BSD-2-clause URL: https://pypi.python.org/pypi/sphinx-patchqueue Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/python-sphinx-patchqueue.git Description: Sphinx extension for embedding sequences of file alterations Sphinx-Patchqueue is a sphinx extension for displaying and formatting file evolution (captured as a patch queue or patch series) in a sphinx document, for tutorials and other similar pieces of text using sequences of alterations made to files. It's known to work with both Quilt and Mercurial Queues patch series. "python-sphinx-patchqueue" is a dependency of Odoo. -- All the best, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#782408: ITP: bruce -- Producer daemon for Apache Kafka
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: bruce Version : 1.0.12 Upstream Author : Dave Peterson, et al. * URL : https://github.com/tagged/bruce/ * License : Apache Programming Lang: C++ Description : Producer daemon for Apache Kafka Bruce is a producer daemon for Apache Kafka. Bruce simplifies clients that send messages to Kafka, freeing them from the complexity of direct interaction with the Kafka cluster. Specifically, it handles the details of: . - Routing messages to the proper brokers, and spreading the load evenly across multiple partitions for a given topic - Waiting for acknowledgements, and resending messages as necessary due to communication failures or Kafka-reported errors Buffering messages to handle transient load spikes and Kafka-related problems - Tracking message discards when serious problems occur; Providing web-based discard reporting and status monitoring interfaces Batching and compressing messages in a configurable manner for improved performance - Optional rate limiting of messages on a per-topic basis. -- ChangZhuo Chen (陳昌倬) http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Bug#782410: ITP: python-requests-cache -- persistent cache for requests library
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: python-requests-cache Version : 0.4.9 Upstream Author : Roman Haritonov * URL : https://github.com/reclosedev/requests-cache * License : BSD Programming Lang: Python Description : persistent cache for requests library Requests-cache is a transparent persistent cache for requests library. This package is required by tvdb-api v1.10 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150411174744.31088.83161.report...@oracle.matrix.int
Bug#782413: ITP: mahimahi -- tools for network emulation and analysis
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: mahimahi Version : 0.90 Upstream Author : Keith Winstein * URL : https://github.com/keithw/mahimahi * License : GPL-3+ Programming Lang: C++ Description : tools for network emulation and analysis Mahimahi is a suite of user-space tools for network emulation and analysis. Each mahimahi tool spawns a lightweight container, generally connected to the outside via a synthetic network device that observes packets in transit or emulates a desired behavior. The tools are composable so that a series of emulated network effects can be chained together, with mahimahi containers nested inside each other. Each tool takes an optional command to execute, so it is possible to create a series of nested containers with one command line -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150411185609.25452.98615.report...@luke-microkernel.zulip.net
Re: Minified javascripts in packages
On Fri, Apr 10, 2015 at 11:44 PM, Marco d'Itri wrote: > What is mandatory is being able to rebuild everything from source with > tools available in Debian (main) Unfortunately we don't have any consistent way to manually or automatically verify that we can do this. I expect we would need Build-Depends-Extra and debian/rules distclean to make that happen. Thoughts? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6etzjk986dkxzhu5oqn4xa9ysqzgbmwrmhucr4voqg...@mail.gmail.com
Re: Experimental ddeb support in debhelper and lintian
On Sat, Apr 11, 2015 at 3:20 PM, Niels Thykier wrote: > As noted on IRC, mentors.debian.net / debexpo will probably need to be > updated too (at least if we go the "ddebs" route). debexpo needs a rewrite to a non-deprecated framework so support for ddebs is probably a long way off. Support for ddebs is also not necessary since mentors is mainly a source package based thing and an easy workaround is available (uploading only the source). -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6G_oNp1Gnd3vDHN1VYguxxnA=tnsajuz5ywv-u8if8...@mail.gmail.com
Using build profiles to specify extra build dependencies (was: Re: Minified javascripts in packages)
Hi, Quoting Paul Wise (2015-04-12 05:14:22) > On Fri, Apr 10, 2015 at 11:44 PM, Marco d'Itri wrote: > > What is mandatory is being able to rebuild everything from source with > > tools available in Debian (main) > > Unfortunately we don't have any consistent way to manually or > automatically verify that we can do this. > > I expect we would need Build-Depends-Extra and debian/rules distclean to make > that happen. Thoughts? I guess instead of a new field you could use build profiles to mark some build dependencies as only being needed for running certain targets in debian/rules. Then a environment variable like DEB_BUILD_OPTIONS=distclean could be used to instruct dpkg-buildpackage to set the right build profile options (leading to more build dependencies) and call the right targets in debian/rules. Going down that road makes me think about more things: - should dpkg-buildpackage set a build profile in certain circumstances (a certain DEB_BUILD_OPTIONS like nocheck or nodoc being set or host-arch != build-arch) or should the user invoking dpkg-buildpackage in a certain way set the build profiles they want? - could the Build-Depends-Indep and Build-Depends-Arch fields replaced by build profiles in the long term in a similar manner? cheers, josch signature.asc Description: signature
Re: Experimental ddeb support in debhelper and lintian
Hi, Quoting Niels Thykier (2015-04-11 09:20:36) > On 2015-04-11 07:14, Niels Thykier wrote: > > [...] > > > >> Stretch is a two year time frame though, which makes me kinda sad. Thanks > >> for you effort though, keep up the amazing work! If I understand > >> correctly, if > >> it would have been something for stretch, either A or B would have been > >> decided already and partly implemented, right? > > > > I believe we can implement this for Stretch if we wanted to. Unlike > > multi-arch, build-profiles (etc.), ddebs are already supported by our > > (14-days-from-now-new) stable release. Namely, > > > > * All the groundwork requirements (pkg:arch dependencies etc.) are > >already covered by previous efforts. > >- I.e. everything that would require a full-cycle for support are > > already done in time for Jessie > > > > Hah, I take that inside the parentheses back. It seems that APT is > *not* very happy with the generated "pkg:arch" dependencies. > Fortunately, this syntax is not required for ddebs. this might be #60 which is fixed in apt in experimental. cheers, josch signature.asc Description: signature
