Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
Le 06/12/2015 13:01, David Kalnischkies a écrit :
> On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote:
>> Will it still be possible to update just the apt-file index, separately
>> from updating the main package index? I see no indication in the current
>> apt(8) man page of a way to tell apt to do this.
>
> You can't update individual indexes at the moment. The question is why
> you would want to as from my point of view that was a pretty annoying
> technical detail that I had to run two (or three [debtags] or more)
> commands to get all the metadata.
On most of my systems, I use i386 in addition to amd64. On my main
laptop, I even use armel and mipsel as I need cross-compilers for some
teaching exercises. Moreover, to be able to easily install packages
from various suite, I've stable, testing, unstable, sid and experimental
in my sources.list (and a few more such as various security, backport, ...)
I use "apt-file search" very sporadically. And even when I use it,
most of the time, it is to find a package containing a header file,
so I do not need its database to be up-to-date. So I update it only
when the result from the first run is not good.
Now, each apt{-get} update will update all Contents-Files for
*all architectures* and *all suites*. I do not want that. It takes
too long for data I do not need. It is especially annoying when I'm
traveling, that I've only a limited (speed and/or size) data link
and that I must upgrade/install a package.
I will try to find a setup so that "apt-get update" does not
download Contents-Files (should be just commenting out the new
config file if I correctly read this thread) and create a
"apt-file-update" script that will download Contents-Files, perhaps
trying here to restrain the architectures and/or the suite (can be
a bit more tricky but probably only a matter of passing -o options
to apt-get update)
The current default setup is a no-go for me.
Regards,
Vincent
--
Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: dbconfig-common: near future change in dependency stack
Le 06/12/2015 20:48, Paul Gevers a écrit : > I am totally flabbergasted. dbconfig-common goes through a lot of hoops > just to make sure this is not true. Sure, the *default* questions and > answers are geared towards local database servers. But by either > (re-)configuring dbconfig-common to raise the priority level of remote > questions by default, or by raising the priority level during package > configuring will get you the questions needed to configure your remote > database. (Of course we can discuss what the proper priorities are but I > really hope no DD will think (anymore) that dbconfig-common assumes > local databases.) When local configuration does not work or when local databases cannot be reached or when local database server packages are not installed the priority of dbconfig-common question about remote database should be modified so that the user can configure a remote database without failing the current installation. I know I already talked about that. I do not remember if this is already implemented or not. Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: dbconfig-common: near future change in dependency stack
* Paul Gevers: " dbconfig-common: near future change in dependency stack" (Sun, 06 Dec 2015 14:23:07 +0100): Hi Paul, > TL;DR;1 if your package depends on dbconfig-common please update your > dependencies when my version 2.0.0 hits the archive (I expect in two > weeks). > TL;DR;2 should the new dbconfig- packages recommend or suggest > the database server packages? Suggest. > Since I took over the dbconfig-common package I have worked on the > following feature in the dbconfig-common framework: binary packages to > specify in the dependency chain which database types a package supports. > > The idea is the following. Each package that used the dbconfig-common > framework to set up databases, should depend on dbconfig- | > dbconfig-no-thanks instead of depending on dbconfig-common (as used to > be the case and still works). What this solves is multiple issues: > > 0) Bug: 353617¹ > > 1) Because there is an alternative, dbconfig- can depend on the > command-line client for dbtype, instead of recommending > it. Thus properly signifying the hard requirement of dbconfig-common to > have the command-line client available. > > 2) For multiple dbtype supported packages the system administrator now > has a way outside of debconf to select which dbtype he wants by > installing the right dbconfig- package. Currently the question > will still be asked though. > > 3) The system administrator now has a way to say no-thanks to > dbconfig-common (by installing the dbconfig-no-thanks package) on the > system level, rather than per package via debconf. > > As a bonus, I can now add the database server packages to recommends, > which should make life of the less experienced user easier. Do you think > I should do this, or should I leave the database server package at the > suggests level? > > Anyways, so what do you need to do? If your package depends on > dbconfig-common (dd-list attached), the only thing you need to do² is > revisit your dependencies/recommends/suggest. If you properly followed > the dbconfig-common documentation, you have a dependency on > dbconfig-common and at least a recommends (but probably a depends) on > the command-line client(s) for the database type(s) you support. You > should replace these with a depends on dbconfig- | > dbconfig-no-thanks. Two examples. > > a) your package supports PostgreSQL, your dependencies now are > Depends: dbconfig-pgsql | dbconfig-no-thanks > > b) your package supports sqlite3 or sqlite, your dependencies now are > Depends: dbconfig-sqlite3 | dbconfig-sqlite | dbconfig-no-thanks Some questions for Tryton server: The situation is - Tryton server runs out of the box without configuration with a SQLite database - The (strongly) recommended database is PostgreSQL, but there is also support for MySQL (and beta for Oracle) - There is a standalone package called Neso (Tryton Neso), that provides a simple combined setup of Tryton client and server (using SQLite), depending on those two. Would it be possible for the last point to skip completely the database configuration (e.g. dbconfig* not jumping in at all, when tryton-neso pulls in tryton-server)? What would be the best way to handle the strong preference for PostgreSQL? MySQL is supported for Tryton, but fails to complete some tests due to missing Standard SQL compliance. So I dislike generally the idea to install a client package for MySQL on a default system. The solution would probably be to not implement at all the option for MySQL, right? Since the production use of tryton-server usually needs some other tweaking to be done in the configuration file, the use of dbconfig* for Tryton is limited anyway. I prefer until now to provide a detailed configuration file and README, but of course I am open to suggestions. Thanks, Mathias > For those of you that backport their packages via the Debian backports > achive, I will provide a backport of dbconfig-common once version 2.0.0 > reaches testing. > > Please speak up now if you think this is a ridiculous idea, if you have > suggestions on improvements, if you have questions or otherwise. > > If people want to see how it all works for discussion, I am open to > upload to experimental. > > And as always, please report bugs as you find them including wish bugs. > > Paul > > ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353617 > ² Be aware, if your package supports multiple databases, you still need > to set the dbc_dbtypes variable in you config script. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 pgphSLW4xPmDE.pgp Description: Digitale Signatur von OpenPGP
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
]] Marvin Renich > * Tollef Fog Heen [151207 00:17]: > > ]] David Kalnischkies > > > > > [And before someone complains about PDiff being slow in apt based on > > > some years old experience: The PDiff handling was changed nearly two > > > years ago… – and apt-file was using PDiffs before already, so no real > > > change there] > > > > Does this mean apt now will only download a single file, regardless of > > whether it's grabbing the updates a pdiff or full packages file? In the > > past, the problem for me has been that you end up being latency-bound, > > rather than bandwidth-bound. > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why > this (or something near this) wasn't the default from the start, I don't > know. The current default is an extremely poor choice. Perhaps someone > should file a bug (serverity critical :-P) to get the default changed. I believe this has already been discussed, but what you really want is to do reverse diffs from today to dates in the past, not incremental diffs in the other direction. This will ensure that a end user never needs to download more than a single file (either a pdiff or the full Packages file). Downside is more churn on those files on the mirrors, but IMO that's acceptable. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
* Vincent Danjean [151208 03:17]:
> Le 06/12/2015 13:01, David Kalnischkies a écrit :
> > You can't update individual indexes at the moment. The question is why
> > you would want to as from my point of view that was a pretty annoying
> > technical detail that I had to run two (or three [debtags] or more)
> > commands to get all the metadata.
>
> I use "apt-file search" very sporadically. And even when I use it,
> most of the time, it is to find a package containing a header file,
> so I do not need its database to be up-to-date. So I update it only
> when the result from the first run is not good.
>
> Now, each apt{-get} update will update all Contents-Files for
> *all architectures* and *all suites*. I do not want that. It takes
> too long for data I do not need. It is especially annoying when I'm
> traveling, that I've only a limited (speed and/or size) data link
> and that I must upgrade/install a package.
I agree completely. I only use apt-file once in a while, and I don't
mind running a separate command to update to Contents files, and I don't
think I have ever used apt-file when I was interested in anything other
than amd64/testing, though I have other archs/suites in my sources.list.
On the other hand, I run apt-get at least once a day. I do not want to
have to wait for the Contents files every time I update my Packages
files.
If this is configurable, that's great, but I think the default (as I
interpret this thread) is a regression. The default should be to not
download Contents, but describe (or point to a description elsewhere) in
the apt-file man page how to change the configuration so that Contents
are downloaded automatically on every apt-get update.
...Marvin
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
* Tollef Fog Heen [151208 04:33]: > ]] Marvin Renich > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why > > this (or something near this) wasn't the default from the start, I don't > > know. The current default is an extremely poor choice. Perhaps someone > > should file a bug (serverity critical :-P) to get the default changed. > > I believe this has already been discussed, Oh, I missed that discussion. Was changing the default rejected, or is it on the todo list, or was there no resolution? > but what you really want is > to do reverse diffs from today to dates in the past, not incremental > diffs in the other direction. That may be a better solution, but if mirror operators are not willing to put up with the churn, then changing the default FileLimit seems like the right (and obvious) compromise. I don't see any downside to changing the default, and it will give significant benefit. If the idea was rejected, I would really like to know why. I've changed my config, so it is not really bothering me, personally. But I would like the default to give the majority of Debian users the best experience; the current setup does not. ...Marvin
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On Sun, Dec 06, 2015 at 08:50:55AM -0500, The Wanderer wrote: > On 2015-12-06 at 07:01, David Kalnischkies wrote: > > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote: > > (as I am sightly lying, it is actually possible – just not very > > accessible for a user and it would have issues so I am not going to > > say how here) > > In public, where it can be discovered later by people who won't know or > be in a position to even judge (much less handle) those issues, you > mean? I am not going to mention it because that makes people end up using it because "its faster" or other non-sense. They will eventually find it anyway in a posting by some 'experts' on the interwebs like it is with other topics involving "downloading stuff" but if all the security bugs eventually catch up to them I at least can honestly say I had nothing to do with it… Anyway: It isn't too hard to figure it out by yourself if someone really wants to, but if this someone isn't motivated enough to figure it out, it is unlikely to be a good idea: The problem is in various short-cuts apt is using to avoid costly hashsum calculations: If it has an 'old' Release file on disk and is asked to download the Contents file for amd64, it opens the old Release file and compares with the already downloaded new Release file: If the hashsums match apt doesn't bother asking the server for the Contents file as even in the best case it would just get a "you already have the newest file" response from the server (and some servers do not support this, so they send us the entire content again, which we have to deal with and in the end discard – total waste of time and bandwidth). The same happens for all the other files, like Packages, Sources, Translations, … If you disable one of these indexes temporarily (and disable list cleaning) [and yes, that is the "solution" blueprint], the next run in which the index is enabled again will believe that the index file is as up-to-date as the Release file is – which isn't correct, so that you have after an update not the latest of all files but some strange mixture until the files change again. That could take a while and confuse the heck out of pdiff – and if this not-really-uptodate happens to effect security updates you are unprotected for longer than it would be needed… Beside the obvious fix (calculating hashes all the time which kills performance) we could invent other ways of dealing with this, but that is a bunch of design and code work – which, personally, I would like to avoid if there isn't a good reason for it as that time could be invested in other more pressing bugs/features. The rest, others have hopefully answered to your satisfaction. I just have to add that while conceptually similar, it isn't via hooks, but src:apt >= 1.1~ allows other packages to declare that they want libapt-based front-ends to acquire files for them. apt-file is just the first example. DEP11 software is likely to follow 'shortly'. Technical details can be found here: https://anonscm.debian.org/cgit/apt/apt.git/tree/doc/acquire-additional-files.txt (please, before anyone commenting on this, read the doc first – its very likely the problem you see with it is not only covered in the docs but also not existing in reality due to practical limitations of what apt can be told to acquire). The point is that apt-file (and all other tools requiring Debian metadata) can drop all of its code responsible for getting files from a Debian repository over potentially very hostile channels, which isn't an easy task – even if you ignore security aspects as apt-file did – and instead outsource it to libapt who needs to do that anyway and has decades of features and experience with it already. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On Tue, Dec 08, 2015 at 10:32:52AM +0100, Tollef Fog Heen wrote: > ]] Marvin Renich > > * Tollef Fog Heen [151207 00:17]: > > > ]] David Kalnischkies > > > > [And before someone complains about PDiff being slow in apt based on > > > > some years old experience: The PDiff handling was changed nearly two > > > > years ago… – and apt-file was using PDiffs before already, so no real > > > > change there] > > > > > > Does this mean apt now will only download a single file, regardless of > > > whether it's grabbing the updates a pdiff or full packages file? In the > > > past, the problem for me has been that you end up being latency-bound, > > > rather than bandwidth-bound. > > > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why > > this (or something near this) wasn't the default from the start, I don't > > know. The current default is an extremely poor choice. Perhaps someone > > should file a bug (serverity critical :-P) to get the default changed. Of course, setting it to 3 makes sense only for people who run 'apt update' at least every 24 hours (3 files = 3 dinstall runs, each run is currently 6 hours apart) as otherwise apt would be forced to download the entire file again. And even for those it makes probably no sense at all, but okay lets see: I somehow can't believe that downloading a few kilobytes split into multiple files is slower than downloading the entire file and I said that multiple times already on public record – the last time I even presented it live in my debconf talk where I was downloading 2+1 releases (sid and testing which have pdiff, stable which hasn't) * 4 architectures * ~ 3 days of no updates (aka ~12 pdiffs per file) amounting to ~150 pdiffs files first with pdiffs and a second time without and pdiff was still 10% faster (beside saving a whole lot of bandwidth and traffic of course). And that just involved small files like Packages – Contents are roughly 10x bigger, so you must have got a pretty great network, sir, as I believed the DebConf network was already pretty great with its local mirror on site to download everything from… btw: The default for apt-file which wasn't effected by this apt setting at all [of course] was 50 – that is close to two weeks of pdiffs. Somehow, that seemed to be fine for you. Just saying. If I had any gamble money I would put an unholy amount of it on "I tried pdiffs many years ago and assume nothing has changed since then"… That idea is right on par with the idea that "apt and aptitude are incompatible": Utter nonsense of course, but an invincible zombie-idea and the reason why I made that initial []-comment. > I believe this has already been discussed, but what you really want is > to do reverse diffs from today to dates in the past, not incremental > diffs in the other direction. Good news then: apt-file didn't support this at all, apt does just fine since ever. The problem with server-merging is just that the server has to do it, which is why apt is doing client-merging for nearly two years now (apt-file did it since ever) by default, but apt happily works with server-merged as well, just add "X-Patch-Precedence: merged" to your .diff/Index file [reprepro is the only server tooling I knew of which did server-merge and used that field to indicate it]. From the client side, I would like to get pipelining back for pdiffs, which currently is auto-disabled for them as apt can't detect pipeline messups without hashsums and pdiffs currently haven't [0], but if we have it, it should help in high latency situations (beside improving security which is the real reason I want it). If you have other ideas feel free to suggest them. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
On Tue, Dec 08, 2015 at 09:16:33AM +0100, Vincent Danjean wrote:
> Le 06/12/2015 13:01, David Kalnischkies a écrit :
> > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote:
> >> Will it still be possible to update just the apt-file index, separately
> >> from updating the main package index? I see no indication in the current
> >> apt(8) man page of a way to tell apt to do this.
> >
> > You can't update individual indexes at the moment. The question is why
> > you would want to as from my point of view that was a pretty annoying
> > technical detail that I had to run two (or three [debtags] or more)
> > commands to get all the metadata.
>
> On most of my systems, I use i386 in addition to amd64. On my main
> laptop, I even use armel and mipsel as I need cross-compilers for some
> teaching exercises. Moreover, to be able to easily install packages
> from various suite, I've stable, testing, unstable, sid and experimental
> in my sources.list (and a few more such as various security, backport, ...)
I have a pretty similar setup actually. You might want to look into
sources.list manpage and especially the 'Targets' option to finetune for
which sources [and potentially which architectures] Contents files are
acquired. You hadn't really a choice with apt-file before and that
always annoyed me, so having this highly (and relatively easy)
configureable for a user was a high priority for me (it at least sounds
a bit like if you wanted that to implement further down by hand in your
apt-file-update script). Feel free to suggest something if you have
further ideas!
> Now, each apt{-get} update will update all Contents-Files for
> *all architectures* and *all suites*. I do not want that. It takes
> too long for data I do not need. It is especially annoying when I'm
> traveling, that I've only a limited (speed and/or size) data link
> and that I must upgrade/install a package.
While the intial cost of getting the Contents files is enormous, keeping
them up-to-date is a matter of a few kilobytes. Most websites you will
visit on the go have a (much) larger footprint on their frontpage, so
I would suggest trying it out first if it really has the problems in
practice you envision it to have before rushing into action.
> I will try to find a setup so that "apt-get update" does not
> download Contents-Files (should be just commenting out the new
> config file if I correctly read this thread) and create a
It is a matter of having a config file with:
Acquire::IndexTargets {
deb::Contents-deb::DefaultEnabled "false";
deb-src::Contents-dsc::DefaultEnabled "false";
};
to have downloads for apt-file disabled by default.
You could then enable it for specific sources in sources.list with the
already mentioned Targets option.
I wouldn't advice mixing apt runs with the option globally disabled and
enabled as the cleanup will garbage collect files from the download
cache apt hasn't downloaded in the current run – and why the cleanup
shouldn't be disabled I mentioned in another reply in this thread:
<20151208123546.GA11777@crossbow>
The cleanest solution if you really want to go this way is probably
a virtual environment in which the sources.list includes only Contents
sources. I guess apt-venv could do that, but I haven't used that. I tend
to set up such environments via apts test framework…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
(adding the missing reference to online resources) On Tue, Dec 08, 2015 at 01:35:59PM +0100, David Kalnischkies wrote: > messups without hashsums and pdiffs currently haven't [0], but if we [0] https://lists.debian.org/debian-dak/2015/08/msg00012.html and my followup https://lists.debian.org/debian-dak/2015/10/msg00010.html Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#807405: ITP: python-senlinclient -- OpenStack Clustering API Client Library
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-senlinclient Version : 0.1.8 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/python-senlinclient * License : Apache-2.0 Programming Lang: Python Description : OpenStack Clustering API Client Library This is a client library for Senlin built on the Senlin clustering API. It provides a Python API (the senlinclient module) and a command-line tool (senlin). This is a new dependency for Heat: the autoscalling server of OpenStack.
Bug#807412: ITP: python-protobix -- Python implementation of Zabbix Sender protocol
Package: wnpp Severity: wishlist Owner: Jean Baptiste Favre -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-protobix Version : 0.0.9 Upstream Author : Jean Baptiste Favre * URL : https://github.com/jbfavre/python-protobix * License : GPL Programming Lang: Python Description : Python implementation of Zabbix Sender protocol This module implements Zabbix Sender Protocol. It allows one to build list of items and send items and send them as trapper. It currently supports items as well as Low Level Discovery. I'm the author of the module and use it on a daily basis. I'm also already packaging it at work. Maintenance will be done through Debian Python Modules Team I'll need a sponsor to get package uploaded. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJWZuS1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc33BMQAIiLp1pqUF73RPCBXJFmXYRW 9WnKPFe0O45WiiRpfpEB9o2bX1qU9vVswbbVgyOAdxveD2vuXtRxXwrysoUvgTa3 y2F62YWHcTkqctPoVd9C8uGdZSI8GBhrH17ZTEwLX1fA/TJ8vqFszESSOF1znlbi gT1x0mIv1GLxFwuPULMbvEwi+D5BkCKEVuYt9idqsXETBTp6xu5pGwNDTVLe0mK7 CpDhEa526hBRISYPqWBTEHseUuaKvsOyRdouMdHLegbN3oGYVYspZO4dabgSktsf OcGvNxfhzP2vF4hbwcRxnnI0573jaDpgcRRymK4SgkjdT87DAd4HfWlK/9wb9vEZ Ll0P8oZljCP51Xvb0h9ZInUWp4XFqB+3GPlOHF+Frl/NkWM5OR3pwnQcgdI9S6dE Q9D4PgN+MIYZ7WHJX6NVdPjRsV8k/6EHVFPzR0zalUgpPDHSl+PmNZIkBZvEzSAs SoATkBtDkNE1Ry6niX4/71Z3qf4khD7bdeD6EXkK1y16eflUHj5eIqLbwo+EWM/4 U1G2P+r/UWyA/RBtqKQPUjwuN6DOm5eXie/fVZYC7G/9FMrmeQFJ4g2svpgFlcsG t1Lx/AWBDoBjQZnhX8Jp3JAw2axunfRqPbb5B6IHPo1e4UVEKQrbxjnolnkTFhOz Lyy3AQDRitoyP6C0XD+A =pm+X -END PGP SIGNATURE-
Re: Upcoming version of apt-file - using apt-acquire and incompatibilities
* David Kalnischkies [151208 07:36]: > On Tue, Dec 08, 2015 at 10:32:52AM +0100, Tollef Fog Heen wrote: > > ]] Marvin Renich > > > * Tollef Fog Heen [151207 00:17]: > > > > ]] David Kalnischkies > > > > > [And before someone complains about PDiff being slow in apt based on > > > > > some years old experience: The PDiff handling was changed nearly two > > > > > years ago… – and apt-file was using PDiffs before already, so no real > > > > > change there] > > > > > > > > Does this mean apt now will only download a single file, regardless of > > > > whether it's grabbing the updates a pdiff or full packages file? In the > > > > past, the problem for me has been that you end up being latency-bound, > > > > rather than bandwidth-bound. > > > > > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why > > > this (or something near this) wasn't the default from the start, I don't > > > know. The current default is an extremely poor choice. Perhaps someone > > > should file a bug (serverity critical :-P) to get the default changed. > > I somehow can't believe that downloading a few kilobytes split into > multiple files is slower than downloading the entire file and I said Okay, if pdiff handling has improved considerably since it was first released, this could be true. I have had FileLimit in my config since soon after I first saw the feature. All I know is that when I first saw this, my updates started taking considerably longer, and the time was spent mostly "connecting to...", not downloading. I saw somebody suggest FileLimit, tried it, and my update time reverted back to where it had been, perhaps even less. (My laptop is the only machine I update daily; I have several other machines that are updated much less frequently, and my experience with pdiffs was across the board.) I never meant to say that pdiffs is not a good feature. On the contrary, I think it is great. My experience, though, was that too many pdiffs took longer elapsed time than downloading the original file. And thanks go to you and the rest of the apt team for all the work you do to make apt better, by far, than any other distribution's packaging system. ...Marvin
Bug#807415: ITP: gwamar -- genome-wide assessment of mutations associated with drug resistance in bacteria
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: gwamar Version : 1.15.1 Upstream Author : Michał Woźniak * URL : http://bioputer.mimuw.edu.pl/gwamar/ * License : GPL Programming Lang: Python Description : genome-wide assessment of mutations associated with drug resistance in bacteria GWAMAR is a tool for detecting of drug resistance-associated mutations in bacteria through comparative analysis of whole-genome sequences. The pipeline of GWAMAR comprises several steps. First, for a set of closely related bacterial genomes, it employs eCAMBer to identify homologous gene families. Second, based on multiple alignments of the gene families, it identifies mutations among the strains of interest. Third, it calculates several statistics to identify which mutations are the most associated with drug resistance.
debian.org mail forwarding, SPF and Postfix
I have the Postfix package on jessie with SPF checks on incoming mail. I'm have trouble receiving mail forwarded from the poc...@debian.org email address. >From main.cf, these lines mention spf: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf policyd-spf_time_limit = 3600 Can anybody comment on the recommended way to allow mail forwarded from debian.org mail servers? People receive bounces like this: dan...@pocock.pro SMTP error from remote mail server after RCPT TO:: host mail.trendhosting.net [2001:67c:1388:1000::5]: 550 5.7.1 : Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=mfrom;id=.. I saw this: http://www.openspf.org/Best_Practices/Forwarding but it doesn't say anything about Postfix.
Bug#807426: ITP: elpa-aggressive-indent-mode -- Emacs minor mode that reindents code after every change
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: elpa-aggressive-indent-mode Version : 1.4.2 Upstream Author : Artur Malabarba * URL : https://github.com/Malabarba/aggressive-indent-mode * License : GPL-2+ Programming Lang: Emacs Lisp Description : Emacs minor mode that reindents code after every change Emacs minor mode that reindents code after every change. Very useful for writing LISP. I intend to package this using dh_elpa from the Emacsen team.
Re: dbconfig-common: near future change in dependency stack
Hi Vincent, On 08-12-15 09:49, Vincent Danjean wrote: > When local configuration does not work or when local databases cannot > be reached or when local database server packages are not installed > the priority of dbconfig-common question about remote database should > be modified so that the user can configure a remote database without > failing the current installation. I know I already talked about that. > I do not remember if this is already implemented or not. I never heard of it, nor is it implemented, unless you mean this in the context of error recovery. In case of ANY error, the priority level of all questions is raised, which allow you to see the all the questions if you hit "Retry" (without the "(skip questions)"). Paul signature.asc Description: OpenPGP digital signature
Re: dbconfig-common: near future change in dependency stack
Hi Mathias, On 08-12-15 10:16, Mathias Behrle wrote: > Would it be possible for the last point to skip completely the database > configuration (e.g. dbconfig* not jumping in at all, when tryton-neso pulls in > tryton-server)? I believe this is something that you would need to implement inside the configuration of tryton-neso/server maintainer scripts. I.e. don't call the dbconfig-common dbc_go commands in the tryton-server maintainer scripts when it detects (non-trivial) that also tryson-neso is (about to be) installed. > What would be the best way to handle the strong preference for PostgreSQL? > MySQL is supported for Tryton, but fails to complete some tests due to missing > Standard SQL compliance. So I dislike generally the idea to install a > client package for MySQL on a default system. The solution would probably be > to > not implement at all the option for MySQL, right? I assume you don't like the dbconfig-pgsql | dbconfig-mysql | dbconfig-no-thanks dependency alternatives? By default the user will then get pgsql. Then I believe your option is to not activate the MySQL support in your package. > Since the production use of tryton-server usually needs some other tweaking to > be done in the configuration file, the use of dbconfig* for Tryton is limited > anyway. I prefer until now to provide a detailed configuration file and > README, > but of course I am open to suggestions. Sounds reasonable, but if the db support can be handled, why not. What would you say you are missing from dbconfig-common? Paul signature.asc Description: OpenPGP digital signature
Re: debian.org mail forwarding, SPF and Postfix
On Dec 08, Daniel Pocock wrote: > Can anybody comment on the recommended way to allow mail forwarded from > debian.org mail servers? You whitelist them from your SPF checks, because SPF is the kind of FUSSP which requires the whole Internet to modify their servers to support forwarding. -- ciao, Marco signature.asc Description: PGP signature
Re: debian.org mail forwarding, SPF and Postfix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/12/15 20:43, Marco d'Itri wrote: > On Dec 08, Daniel Pocock wrote: > >> Can anybody comment on the recommended way to allow mail >> forwarded from debian.org mail servers? > You whitelist them from your SPF checks, because SPF is the kind of > FUSSP which requires the whole Internet to modify their servers to > support forwarding. > But what exactly does somebody need to whitelist to allow mail forwarded from a debian.org address? Should check_helo_access be used with a domain or IP or some other value specific to mail forwarded by Debian's MTA? http://www.postfix.org/postconf.5.html#check_helo_access -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWZza8AAoJEOm1uwJp1aqDGUcP/3LJitI8yhR7QBpz/FcyeKf4 epKzTAbu4BIerUH7M05ZML3y6Z0AgvkUyTp0JdkOZYfp0UvlmaKEPAaZx3YZx8P9 MP4/3M3uaywAZH/rl4AnqqCUeJfwCI2yBYSFYWHFcjz2PxjDFCi+AvEe7Al6Z3Wt EzIOMjCqQAWgW5gWOUSE9OFIr0XRNipO9Ust+ywSKRDfbZVoJ3rLDP9dwZgZTDct BmA9Qodo4TnifcqRskmJPZ3baSh/vew/hLehwHo2jWXgHONk5AXk9VdjGFJxwKBf /sUdbkctJUTqIDQ92QYplGjkxMnZGjf3s8Mju4YpViEyVUfuie+h2fAAdv1bPxAT UTUYId/P3S5AWM/QA8li5XF4kpTaw2JHf3sRNIA7gAJXnhtRvC5mCxg4cz2J7Hx4 6aqSuzyzu/+fGZT+YW6EVbXJwSgk1h2JfgGZN/6AJ5Hl1GSd8xm5k/6465ljwYTE fiUFHbvKbabuDdZnmmReP7FS4xfqg9xtRcTzbntQf6MZGQSS0XINEvyyvmmgN1q2 hEBoN5YBJ6CcUsvR9e0fBcfldvNRywGmoNtXyTSHDkE+drSUFCJnyNQlJIY4DeRf fitPXe7ORG8MZWZQgK5c1UyWu3NDO7Cahz9UI/P2b0l3J20pLpsFqGOYkfYzj5Nf Uu7tkdPuaQpqT6aX8vS9 =pSqW -END PGP SIGNATURE-
Re: dbconfig-common: near future change in dependency stack
Le 08/12/2015 20:25, Paul Gevers a écrit : > I assume you don't like the dbconfig-pgsql | dbconfig-mysql | > dbconfig-no-thanks dependency alternatives? By default the user will > then get pgsql. Not if the user has dbconfig-mysql or dbconfig-no-thanks already installed (probably due to other packages). Dependency alternatives are rarely a good hint for preference, but if the system is installing for the first time (as in autobuilder) Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: dbconfig-common: near future change in dependency stack
Le 08/12/2015 20:14, Paul Gevers a écrit : > Hi Vincent, > > On 08-12-15 09:49, Vincent Danjean wrote: >> When local configuration does not work or when local databases cannot >> be reached or when local database server packages are not installed >> the priority of dbconfig-common question about remote database should >> be modified so that the user can configure a remote database without >> failing the current installation. I know I already talked about that. >> I do not remember if this is already implemented or not. > > I never heard of it, nor is it implemented, unless you mean this in the > context of error recovery. In case of ANY error, the priority level of > all questions is raised, which allow you to see the all the questions if > you hit "Retry" (without the "(skip questions)"). Yes, I was thinking to that feature. > Paul > -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: debian.org mail forwarding, SPF and Postfix
On December 8, 2015 2:59:57 PM EST, Daniel Pocock wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > > > >On 08/12/15 20:43, Marco d'Itri wrote: >> On Dec 08, Daniel Pocock wrote: >> >>> Can anybody comment on the recommended way to allow mail >>> forwarded from debian.org mail servers? >> You whitelist them from your SPF checks, because SPF is the kind of >> FUSSP which requires the whole Internet to modify their servers to >> support forwarding. >> > >But what exactly does somebody need to whitelist to allow mail >forwarded from a debian.org address? > >Should check_helo_access be used with a domain or IP or some other >value specific to mail forwarded by Debian's MTA? The easiest way to do it, assuming you're using postfix-policyd-spf-python, is within the policy server. See man 5 policyd-spf. There are several whitelist options. I think PTR whitelist on bendel.debian.org will probably do it. Scott K
Bug#807449: ITP: klaus -- simple easy-to-set-up Git web viewer
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: klaus Version : 0.7.1 Upstream Author : Jonas Haag * URL : https://github.com/jonashaag/klaus * License : MIT Programming Lang: Python Description : simple easy-to-set-up Git web viewer Klaus is a simple web viewer for Git repositories, which can display history, tree contents and file contents (including syntax highlighting). It also allows retrieval of archive contents as well as pulling and pushing repositories using the Git smart server protocol.
Bug#807450: TP: libperinci-sub-util-perl -- Perl module that is a helper to write functions
Package: wnpp Owner: Lucas Kanashiro Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libperinci-sub-util-perl Version : 0.42 Upstream Author : perlancar * URL : https://metacpan.org/release/Perinci-Sub-Util * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module that is a helper to write functions Perinci::Sub::Util is a helper to write functions. This module could help with handling errors, where the application can be killed or just throw some warn, generate stub functions and be used as a caller. The package will be maintained under the umbrella of the Debian Perl Group. signature.asc Description: PGP signature
