Re: Looking for ideas for merging a micro package...
Neil McGovern debian.org> writes: > > > > I absolutely do not want to see anything related to ruby on my > > > > systems. > > SC#4 and not forcing bad things on users. > Fantastic. In that case I propose we remove mksh from the archive as >From my system ≠ from the archive. I don’t say everyone MUST use it. In fact, I even demoted it from Recommends to Suggests on a package because many people still run with install-recommends=true and it was not strictly needed. Honestly, dealing with you makes me want to go [VAC] often enough. Stop turning around my words to suit you instead of reading what I actually tried to say. (And to think I was looking forward going to Cambridge…) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130906t093901-...@post.gmane.org
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Thu, Sep 5, 2013 at 11:34 PM, Philipp Kern wrote: > On 2013-09-05 11:15, David Kalnischkies wrote: > [ Provides/Replaces up thread ] > >> The policy defines two uses of Replaces: > > […] > >> So my simple question is, which combination of relations should that >> be that tells a smart package manager to upgrade pkgA to pkgB ? > > > What about pkgB replacing and providing pkgA? Because its usually an error to just replace a package without breaking/conflicting against it in which case it looks suspiciously like 7.6.2 – also just take the examples I mentioned and think about what happens: For example, you made mplayer2 now an upgrade for mplayer. I am not sure that is what their maintainers/upstreams intend. (maybe it is, but I am not keen on letting foo2/foo-ng maintainer decide what is a good upgrade path for foo – that should really be decided by foo maintainer). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fd+bkrjnprzcdssgq3ar0z205o3h4eqpryi9zn0y_5...@mail.gmail.com
Bug#721964: ITP: r-bioc-annotationdbi -- GNU R Annotation Database Interface for BioConductor
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-annotationdbi Version : 1.22.6 Upstream Author : Herve Pages, Marc Carlson, Seth Falcon, Nianhua Li * URL : http://www.bioconductor.org/packages/release/bioc/html/AnnotationDbi.html * License : Artistic-2.0 Programming Lang: R Description : GNU R Annotation Database Interface for BioConductor This BioConductor module provides user interface and database connection code for annotation data packages using SQLite data storage. This is also a precondition for r-bioc-cummerbund and maintained at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-annotationdbi/trunk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906093335.17501.8754.report...@mail.an3as.eu
Re: Looking for ideas for merging a micro package...
On Fri, Sep 6, 2013 at 9:41 AM, Thorsten Glaser wrote: > In fact, I even demoted it from Recommends to Suggests on a package > because many people still run with install-recommends=true and it > was not strictly needed. Thanks for fixing a bug in your package. Just don't blame other people for your bugs next time. I "recommend" reading debian-policy (§7.2). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fc2vyjohizmar03yhrbuqsjt764vht0tl6vdai-vjl...@mail.gmail.com
Bug#721969: ITP: interfacetable-v3t -- Nagios / Icinga plugin to monitor network interfaces via SNMP
Package: wnpp Severity: wishlist Owner: Markus Frosch * Package name: interfacetable-v3t Version : 0.05 Upstream Author : Yannick Charton * URL : http://www.tontonitch.com/tiki/tiki-index.php?page=Nagios%20plugins%20-%20interfacetable_v3t * License : GPL2+ Programming Lang: Perl and some PHP and JS Description : Nagios / Icinga plugin to monitor network interfaces via SNMP Interfacetable_v3t (formerly check_interface_table_v3t) is a Nagios / Icinga addon that allows you to monitor the network interfaces of a node (e.g. router, switch, server) without knowing each interface in detail. Only the hostname (or ip address) and the snmp community string are required. It generates a html page gathering some info on the monitored node and a table of all interfaces/ports and their status. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906110623.27702.36980.report...@frosch-nb.lazyfrosch.de
Re: Less dinstall FTW?
Thanks for your explanations! On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote: > As this suite is much smaller than the full archive, updating it can be > done with much less overhead and is done with every cron.unchecked > run. Packages.gz (amd64) is just 98 kb, Sources.gz is 180 kb compared to > 8.5 MB each for the main archive. There are also no Contents indices. One aspect I couldn't find in the discussion so far is reduction of bandwidth on *my* end. Let us for a moment consider a user to run sid with incoming enabled and the dinstall frequency cut in half. Are the following conclusions correct? * The user would not receive packages any later than in the old setup (assuming a recent apt-get update). * If PDiffs are disabled, the user would be wasting less bandwidth for package lists, because the big package lists are now downloaded with half the frequency and the other lists are small. So less bandwidth is used here. * If PDiffs are enabled, I assume that incoming would not support PDiffs for its rapid rate of change. With PDiffs the number of diffs is interesting, because processing them usually is the limiting factor here. The number of PDiffs would be halved as well here, so the update would usually go faster. For both download variants the effect is multiplied when using foreign architectures. Who hasn't disabled PDiffs, because they take way too long when the network is fast? >From this very limited POV the proposal appears to be an improvement. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906130213.ga8...@alf.mars
Re: Less dinstall FTW?
On 2013-09-06 15:02, Helmut Grohne wrote: > Thanks for your explanations! > > On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote: >> As this suite is much smaller than the full archive, updating it can be >> done with much less overhead and is done with every cron.unchecked >> run. Packages.gz (amd64) is just 98 kb, Sources.gz is 180 kb compared to >> 8.5 MB each for the main archive. There are also no Contents indices. > > One aspect I couldn't find in the discussion so far is reduction of > bandwidth on *my* end. Let us for a moment consider a user to run sid > with incoming enabled and the dinstall frequency cut in half. Are the > following conclusions correct? > > * [...] > * If PDiffs are enabled, I assume that incoming would not support >PDiffs for its rapid rate of change. With PDiffs the number of diffs >is interesting, because processing them usually is the limiting >factor here. The number of PDiffs would be halved as well here, so >the update would usually go faster. > > [...] > > Who hasn't disabled PDiffs, because they take way too long when the > network is fast? > Well, most of the problem with PDiffs could actually go away if made a (to me seemly) minor change their index files. If it is possible to determine the "outcome" of applying a PDiff, APT could apply the diffs in a much more efficient manner. Currently, apt-file does this by making assumptions (which holds for DAK produced PDiffs atm, but not for - I think - reprepro). So if "runtime of using PDiff" is your concern, I think "fixing" PDiffs would be a much more interesting solution than working around it by halfing the number of dinstalls (although, I don't have particularly strong opinions in regards 2 vs 4 dinstalls per day). For those interested, I believe #703366 might be worth a read on that topic[1]. >>From this very limited POV the proposal appears to be an improvement. > > Helmut > > ~Niels [1] e.g. <201303201830.32577...@sfritsch.de> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5229d53c.4020...@thykier.net
Bug#721981: ITP: python-pystache -- Mustache for Python
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-pystache Version : 0.5.3 Upstream Author : Chris Jerdonek * URL : https://github.com/defunkt/pystache * License : MIT Programming Lang: Python Description : Mustache for Python Pystache is a Python implementation of Mustache (see: http://mustache.github.com/>). Mustache is a framework-agnostic, logic-free templating system inspired by ctemplate (see: http://code.google.com/p/google-ctemplate/ and http://www.ivan.fomichev.name/2008/05/erlang-template-engine-prototype.html. Like ctemplate, Mustache "emphasizes separating logic from presentation: it is impossible to embed application logic in this template language". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906083242.30709.86465.report...@buzig.gplhost.com
Bug#721985: ITP: kytea -- morphological analysis system with pointwise predictors
Package: wnpp Severity: wishlist Owner: Koichi Akabe * Package name: kytea Version : 0.4.6 Upstream Author : Graham Neubig * URL : http://www.phontron.com/kytea/ * License : Apache-2.0 Programming Lang: C++ Description : morphological analysis system with pointwise predictors KyTea is morphological analysis system based on pointwise predictors. It separetes sentences into words, tagging and predict pronunciations. The pronunciation of KyTea is same as cutie. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906142444.4202.88014.reportbug@vbk27182818
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 06/09/13 10:17, David Kalnischkies wrote:
> For example, you made mplayer2 now an upgrade for mplayer.
> I am not sure that is what their maintainers/upstreams intend.
> (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
> decide what is a good upgrade path for foo – that should really
> be decided by foo maintainer).
In controversial cases, can't we avoid this by social pressure ("don't
do that, it's rude")?
At the moment, the way to "force" an package to be superseded is a
transitional package built by foo2 that "takes over" a binary package
name from foo1. It would be entirely possible for the systemd
maintainers to upload src:systemd with a transitional sysvinit package
that depends on systemd-sysv, for instance. They don't do that, of
course, because it would be unwelcome - but it is technically possible.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5229e3c2.5090...@debian.org
Bug#721983: ITP: lconf -- LDAP based configuration system for Icinga and Nagios
Package: wnpp Severity: wishlist Owner: Markus Frosch * Package name: lconf Version : 1.3.0 Upstream Author : NETWAYS GmbH * URL : https://www.netways.org/projects/lconf * License : GPL-2 Programming Lang: Perl Description : LDAP based configuration system for Icinga and Nagios LConf allows one to maintain the configuration and the hierarchy of the monitoring environment in a LDAP tree. Supporting inheritance of attributes and templates (by linking other LDAP OUs) LConf uses it's own way to resolve the configuration in constrast to classical Icinga / Nagios configuration tricks and best-practises. The configuration itself is created by Perl export scripts that create a plain text configuration for Icinga and Nagios. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906142201.3268.55532.report...@frosch-nb.lazyfrosch.de
Bug#721994: ITP: lconf-icinga-mod -- LConf web interface as a module for Icinga Web
Package: wnpp Severity: wishlist Owner: Markus Frosch * Package name: lconf-icinga-mod Version : 1.3.2 Upstream Author : NETWAYS GmbH * URL : https://www.netways.org/projects/lconf-for-icinga * License : GPL-2 Programming Lang: PHP, JS Description : LConf web interface as a module for Icinga Web LConf allows one to maintain the configuration and the hierarchy of the monitoring environment in a LDAP tree. Supporting inheritance of attributes and templates (by linking other LDAP OUs) LConf uses it's own way to resolve the configuration in constrast to classical Icinga / Nagios configuration tricks and best-practises. The configuration itself is created by Perl export scripts that create a plain text configuration for Icinga and Nagios. This package contains the web interface, integrated into Icinga Web. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130906160615.12500.79161.report...@frosch-nb.lazyfrosch.de
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 6, 2013 at 4:16 PM, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
>> For example, you made mplayer2 now an upgrade for mplayer.
>> I am not sure that is what their maintainers/upstreams intend.
>> (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
>> decide what is a good upgrade path for foo – that should really
>> be decided by foo maintainer).
>
> In controversial cases, can't we avoid this by social pressure ("don't
> do that, it's rude")?
I should have noted that this was a bonus – the key point is that there
must be a way for foo2/foo-ng maintainers to declare that they provide
a (more or less) feature compatible replacement, and they do it with
exactly those relations as this is how debian-policy defines them, so
they can't be reinterpreted.
As we saw in "Debian Cosmology": You can easily change an init
system, but don't you dare to change a package manager …
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fdr8-oz0yfc6kqagmtmgi+a_5f+bc9fucwqtblnjs7...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 06, 2013 at 03:16:34PM +0100, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
> > For example, you made mplayer2 now an upgrade for mplayer.
> > I am not sure that is what their maintainers/upstreams intend.
> > (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
> > decide what is a good upgrade path for foo – that should really
> > be decided by foo maintainer).
> In controversial cases, can't we avoid this by social pressure ("don't
> do that, it's rude")?
The issue David is raising is that this is a semantic change; while many
packages would work fine by interpreting Replaces+Provides the way you
describe, there are some that wouldn't, and under Policy these packages are
not "wrong" today. How do we transition to this new behavior on the part of
apt without inconveniencing users with wrong results?
Now, maybe apt could consider a package a replacement only if pkgA
Replaces/Provides pkgB, *and* pkgB is no longer available. Are there cases
where that would give the wrong result? Is it practical to implement?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 6, 2013 at 7:05 PM, Steve Langasek wrote: > Now, maybe apt could consider a package a replacement only if pkgA > Replaces/Provides pkgB, *and* pkgB is no longer available. Are there cases > where that would give the wrong result? Is it practical to implement? Depends I guess on how much you value slight derivations from the norm. APT detects "obsolete" packages in its ProblemResolver and gives those a small penalty in conflict resolution, but I am not sure its a good idea to not only increase the penalty but let it cause actions by itself: Many people have multiple releases in their sources.list, so a package is not really disappearing – or takes quiet a while until it disappears. On the other hand packages sometimes disappear "temporarily" in testing. Also, sometimes packages disappear from stable – so while its a good idea to do something about those, I would say this is the wrong way of doing it as such an automated change contradicts stable. (and it doesn't work for the more common cases of packages which disappear, but have no replacement as such) What MIGHT (I haven't really though about it yet) work is limiting it to provides+replaces(+breaks) in the same source package, but I am not sure it makes that much sense to introduce complex rules for dependency relations if the current "simple" rules are already not understood by everyone (like breaks vs. conflicts). Personally, I would say we need a hints file just like britney and co have, but for package managers which tells them that this package is gone and a) can be replaced automatic by foo b) the user should decide between foo, bar, baz (this info is usually available in prosa in the RoM/RoQA bugreport) c) has no (free) replacement d) is no longer needed … Not that this would make the life of a maintainer necessarily easier, but it at least frees the user (and the package manager) from deciding if this remove requires user-attention or is just boring house-keeping. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fatnijufhoosqmencpjuozc-83mp7dmwmguzlajwdj...@mail.gmail.com
Bug#722049: ITP: python-mox3 -- Mock object framework
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-mox3 Version : 0.7.0 Upstream Author : OpenStack infra * URL : https://pypi.python.org/pypi/mox3 * License : Apache-2.0 Programming Lang: Python Description : Mock object framework Mox3 is an unofficial port of the Google mox framework (see http://code.google.com/p/pymox/) to Python 3. It was meant to be as compatible with mox as possible, but small enhancements have been made. The library was tested on Python version 3.2, 2.7 and 2.6. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130907030815.811.14358.report...@buzig.gplhost.com
Bug#722051: ITP: python-dogpile.cache -- caching front-end based on the Dogpile lock
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-dogpile.cache Version : 0.5.0 Upstream Author : Mike Bayer * URL : http://bitbucket.org/zzzeek/dogpile.cache * License : BSD Programming Lang: Python Description : caching front-end based on the Dogpile lock A caching API built around the concept of a "dogpile lock", which allows continued access to an expiring data value while a single thread generates a new value. . dogpile.cache builds on the dogpile.core locking system (see http://pypi.python.org/pypi/dogpile.core), which implements the idea of "allow one creator to write while others read" in the abstract. Overall, dogpile.cache is intended as a replacement to the Beaker (see http://beaker.groovie.org) caching system, the internals of which are written by the same author. All the ideas of Beaker which "work" are re-implemented in dogpile.cache in a more efficient and succinct manner, and all the cruft (Beaker's internals were first written in 2005) relegated to the trash heap. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130907040848.4868.92273.report...@buzig.gplhost.com
Bug#722052: ITP: python-mox3 -- Mock object framework
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-mox3 Version : 0.7.0 Upstream Author : OpenStack * URL : https://pypi.python.org/pypi/mox3 * License : Apache-2.0 Programming Lang: Python Description : Mock object framework Mox3 is an unofficial port of the Google mox framework (see http://code.google.com/p/pymox/) to Python 3. It was meant to be as compatible with mox as possible, but small enhancements have been made. The library was tested on Python version 3.2, 2.7 and 2.6. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130907042045.6450.74086.report...@buzig.gplhost.com
Bug#722053: ITP: python-jsonpath-rw -- extended implementation of JSONPath
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-jsonpath-rw Version : 1.2.0 Upstream Author : Kenneth Knowles * URL : https://github.com/kennknowles/python-jsonpath-rw * License : Apache-2.0 Programming Lang: Python Description : extended implementation of JSONPath This library provides a robust and significantly extended implementation of JSONPath for Python. It is tested with Python 2.6, 2.7, 3.2, and 3.3. . This library differs from other JSONPath implementations in that it is a full language implementation, meaning the JSONPath expressions are first class objects, easy to analyze, transform, parse, print, and extend. . The JSONPath syntax supported by this library includes some additional features and omits some problematic features (those that make it unportable). In particular, some new operators such as "|" and "where" are available, and parentheses are used for grouping not for callbacks into Python, since with these changes the language is not trivially associative. Also, fields may be quoted whether or not they are contained in brackets. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130907042522.6640.921.report...@buzig.gplhost.com
