Re: Packages of "standard" priority in a fresh cdebootstrapped system as dependencies of packages with higher priorities.
Thank you, now I understand. -- 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/55b33430.7030...@gmail.com
Bug#793404: massive waste of CPU time in debian/rules by inline commands
On 2015-07-24 12:19, Jakub Wilk wrote:
> * Jonas Smedegaard , 2015-07-23, 21:40:
>>> One mistake boost makes is using ":=" instead of plain "=". Contrary
>>> to popular belief, the former almost always causes more evaluation of
>>> $(shell) stuff, specially when dh is involved.
>> Could you elaborate on that?
>
> dpkg-buildpackage -B will run debian/rules 4 times: once to determine if
> build-arch exist, and once for every target: clean, build(-arch),
> binary-arch.
>
> dh adds even more debian/rules invocations. It runs it once every target
> (clean, build(-arch), binary-arch), and once for every override.
>
Indeed - though hardly the common use for override targets, you /can/
exclude a command for free by declaring a /completely/ empty target.
Have a look at:
$ dh binary --no-act | grep debian/rules | wc -l
$ dh clean --no-act | grep debian/rules | wc -l
Which should tell you how many override non-empty targets you have.
Output (of dh --no-act) is something like:
dh_testdir
debian/rules override_dh_auto_configure
dh_auto_build
[...]
dh_installdirs
debian/rules override_dh_auto_install
[...]
If your override target is completely empty, the command/target simply
disappears from the list. Though it does not account for the extra
overhead from dpkg-buildpackage calling build{,-arch,-indep} first in a
separate step.
> So your ":=" variable will be evaluated 4 times, or 7+N times if you use
> dh.
>
> [...]
>
It should be doable to reduce the dh side of it to 1+N by caching the
result of make (in a file-based cache).
~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/55b34861.6040...@thykier.net
Bug#793578: ITP: ruby-climate-control -- library to easily manage environment variables
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-climate-control Version : 0.0.3 Upstream Author : Joshua Clayton * URL : https://github.com/thoughtbot/climate_control * License : Expat Programming Lang: Ruby Description : library to easily manage environment variables -- 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/20150725094941.31723.45145.reportbug@sasalam
Bug#793585: ITP: ea-utils -- command-line tools for processing biological sequencing data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: ea-utils Version : 1.1.2 Upstream Author : Erik Aronesty * URL : https://code.google.com/p/ea-utils/ * License : MIT Programming Lang: C Description : command-line tools for processing biological sequencing data i Ea-utils provides a set of command-line tools for processing biological sequencing data, barcode demultiplexing, adapter trimming, etc. . Primarily written to support an Illumina based pipeline - but should work with any FASTQs. . Main Tools are: . * fastq-mcf Scans a sequence file for adapters, and, based on a log-scaled threshold, determines a set of clipping parameters and performs clipping. Also does skewing detection and quality filtering. * fastq-multx Demultiplexes a fastq. Capable of auto-determining barcode id's based on a master set fields. Keeps multiple reads in-sync during demultiplexing. Can verify that the reads are in-sync as well, and fail if they're not. * fastq-join Similar to audy's stitch program, but in C, more efficient and supports some automatic benchmarking and tuning. It uses the same "squared distance for anchored alignment" as other tools. * varcall Takes a pileup and calculates variants in a more easily parameterized manner than some other tools. This package was prepared by Tim Booth for BioLinux to update the qiime package. It is taken over into the Debian Med team and will be maintained at git://anonscm.debian.org/debian-med/ea-utils.git -- 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/20150725102322.6843.96528.report...@mail.an3as.eu
Bug#793617: ITP: ruby-parse-cron -- parse cron expressions and calculates the next job occurence
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org pkg-ruby-extras-maintain...@lists.alioth.debian.org Package name: ruby-parse-cron Version: 0.1.4 Upstream Author: Michael Siebert License: Expat URL: https://github.com/siebertm/parse-cron Vcs-Browser: https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-parse-cron.git Description: parse cron expressions and calculate occurrence of next job "parse-cron" parses crontab timing specification and determine when the next scheduled job should be run. --- This package is a dependency of Opennebula-4.x. -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Re: Facilitating external repositories
On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote: > - Apt will try to download it from a default location in the repository > (or perhaps a location specified in the deb822 sources.list file > itself). What the heck is "it" in this sentence? I envision "deb822 sources.list" file, but reading the location of the file from the file itself seems a bit hard to pull of in practice… > - It may be GPG-signed by one or more keys. Apt should have a way of > configuring GPG keys that may be allowed to sign sources.list files, > preloaded with the set of keys in the Debian keyring. This will allow > system administrators in large environments to specify their own set > of keys allowed to sign repositories, as well as allowing downstreams > to add its own ways of trusting repositories. Using the Debian keyring as a preload means a) a big package pushed into the default set of installed packages and b) the update state of this package: The package can happily contain revoked/expired keys (if everyone follows the <2 years expire recommendation every key will be expired well before the end of security support – not even mentioning LTS and apt can't just --refresh-keys as it can't verify the result). No longer DDs. Will not include new DDs. Same for DMs were the active state can vary faster based on the ping. There is of course the general problem of if a signature by a 'random' DD actually assures anything. I mean, I have a key signed by a few DDs, does that mean I can repropose my key now for an archive? Sounds about right to me at least. So much for "a trusted path from Debian to [your] repository" as it is now my man-in-the-middled repository. (Did I say "I repropose"? That was the blackhat stealing my key of course) Or did you mean that the DD signs the sources.list file directly? Well, then my key isn't usable for that right now, but in exchange the DD might have a slight problem in assuring the correctness of what he is signing: I am the owner of example.org/debian. Trust me. If you thought the default CA trust store in a browser is (too) large, I am not sure what a 1000+ key trust store would be. Sounds for me like the wet dream of security folks (not)… Oh, and given that I got you to sign my example.org repo for me, does that mean you are endorsing my endeavor? I mean, pornview is a normal image viewer, hotbabe a good cpu monitor and sex my preferred input method (as a text editor). Any objections? And god forbit that I might turn (even more) evil. Or the person I am selling the domain to in three months… (Or should I say the blackhat who did a hostile take over of my domain and now ships trojans to everyone with a sources.list signed by you). But yeah, you are not endorsing me, you just signed a document to give me root access on every machine you happen to be a trusted signer on – that is totally different. Some of this is a problem for an archive signing key as well, but the difference is that an archive signing key is signing a Release file which regularly changes, but a sources.list file hardly changes. It especially doesn't change in the last example with a domain takeover and there is no poor man's repository version of the web of trust. If you are adding archive signing keys it must be hundred percent bullet proof or all of apt-secure is broken. Sure, you are basically automating what is currently done by hand by many users, but as long as they do it by hand its their own fault – if you automate it to one-click they will rightly expect it to be secure. > - It may possibly add a limitation on the packages that can be > downloaded from the given repository (so that a package repository > cannot suddenly acquire a package "libc6", accidentally or otherwise). > This should allow for wildcards (e.g., in my specific situation this > field would contain "libbeid*, eid-*, beid-*") While a nice feature, hardly a security one as for an attacker it is only important to know which package to infect. libc6 is of course installed by everyone, so an "upgrade" in a bugged repository has the desired effect, but any person with your repository active will also have one of your packages installed – otherwise they wouldn't have the repository in the first place, right – so that feature gives a warm fuzzy feeling at best. Who cares in the end if the package I run my evil maintainer script with is called 'libc6' or 'eid' … btw: Who is controlling that whitelist? Lets imagine that your tool needs in version 2 two new obscure libraries: You will have a hard time convincing John Doe that he should update the list by hand after apt-get crapped out with an error message saying that much – on the other hand Jane Doe will be disappointed if you let apt-get change the list based on the wishes of the repository. And lets face it: Nobody will be happy if apt-get is asking a question about this as everyone will be trained to press 'yes' pretty quickly. Oh, and what about eid-libc6
Bug#793644: ITP: hadoop -- Apache Hadoop distributed processing framework
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: hadoop Version : 2.6.0 Upstream Author : The Apache Software Foundation * URL : http://hadoop.apache.org * License : Apache-2.0 Programming Lang: Java Description : Apache Hadoop distributed processing framework Apache Hadoop is a framework for running applications on large cluster built of commodity hardware. It transparently provides applications both reliability and data motion. Hadoop implements a computational paradigm named Map/Reduce, where the application is divided into many small fragments of work, each of which may be executed or re-executed on any node in the cluster. In addition, it provides a distributed file system (HDFS) that stores data on the compute nodes, providing very high aggregate bandwidth across the cluster. Both MapReduce and the Hadoop Distributed File System are designed so that node failures are automatically handled by the framework. -- 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/20150725211011.10861.2382.report...@icare.ariane-software.com
