Re: Dependencies of metapackages
> Wolodja Wentland writes: > is there a specific reason why metapackages depend rather then > recommend packages they are meant to pull in? > The rationale behind this question is [0] that we see a plethora of > users in #debian who ask questions like: "Why did apt remove all my > system??⸘one!one!eleven!" > and we have to explain to them that it is because they decided to > remove one of (typically) gnome's dependencies, which caused the > metapackage to be removed as well. The solution is then to either > mark all other dependencies as manually installed, install a smaller > metapackage or a combination of those. Since turning these dependencies into Recommends: is apparently infeasible, it may be useful to amend APT to automatically mark the metapackage's dependencies as manually installed if the metapackage itself is so marked. Or do I miss something obvious with this approach? (Sorry, I'm not familiar with the subject. Beyond knowing to avoid metapackages at all costs, i. e.) […] -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- 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/867h5qamdt@gray.siamics.net
checking if .deb's match Packages
> Henrique de Moraes Holschuh writes:
[…]
> The Debian mirror in mirrors.kernel.org, on the other hand... While
> the apt signature will protect users downloading packages through the
> package manager, users that get binary packages directly are not
> protected.
FWIW, personally, I download both the binary packages /and/ the
signed lists.
[…]
> Do we have a automated way to signature-check every binary and source
> package in a repository against the hashes in the signed release
> files?
sha1sum(1) and sha256sum(1) will do. As for the input format
conversion, the following GNU Awk bit may help:
--cut: packages2sha256.awk --
! /./ {
if (fn != "" && sha256 != "") {
print sha256, "*" fn;
}
fn = ""; sha256 = "";
}
/^Filename: / { fn = $2; next; }
/^SHA256: / { sha256 = $2; next; }
--cut: packages2sha256.awk --
It may also be combined with grep-dctrl(1) to check a subset of
packages, like:
$ find dists/wheezy/ \
-type f -name Packages.bz2 -exec bzcat -- {} + \
| grep-dctrl -s Filename,SHA256 \
-F Priority --regex --pattern=required\\\|important \
| gawk packages2sha256.awk \
| sha256sum -c
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)
--
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/86bov2amq8.fsf...@gray.siamics.net
Re: Dependencies of metapackages
* Josselin Mouette [2011-09-01 09:52 +0200]: > I think we could solve a lot of those problems by treating metapackages > specially in APT. Ubuntu has a section "metapackages", introducing such a section in Debian could be the first step to treat metapackages specially. Carsten -- 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/20110902165452.ga26...@furrball.stateful.de
Re: kernel.org compromised
On Fri, 02 Sep 2011, Philipp Kern wrote: > On 2011-09-02, Henrique de Moraes Holschuh wrote: > > On Fri, 02 Sep 2011, Bastian Blank wrote: > >> On Thu, Sep 01, 2011 at 06:05:01PM -0300, Henrique de Moraes Holschuh > >> wrote: > >> > Our kernels are not a problem. The Debian mirror in mirrors.kernel.org, > >> > on the other hand... While the apt signature will protect users > >> > downloading packages through the package manager, users that get binary > >> > packages directly are not protected. > >> The connection is not authenticated, so it makes no difference if you > >> get modified stuff or if it is modified in transit. > > Yeah, yeah. We've beaten that horse to death, and our side lost. I also > > advocate that all debs should be signed, but that was not the will of the > > ftp-masters the last time the issue was up for discussion. > > And we should get the archive signing key into a HSM. We actually could if we wanted to, it is not that expensive. Whether it would really help overall security or not is something that is not obvious. Good two-factor autentication for logins would be a better first step, though. As long as we ask the Fedora guys how well it is working for them, first... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110902164443.gb4...@khazad-dum.debian.net
Bug#640118: ITP: rdkit -- Collection of cheminformatics and machine-learning software
Package: wnpp Severity: wishlist Owner: Michael Banck * Package name: rdkit Version : 201106 Upstream Author : Greg Landrum and Julie Penzotti * URL : http://www.rdkit.org/ * License : BSD Programming Lang: C++, Python Description : Collection of cheminformatics and machine-learning software RDKit is a Python/C++ based cheminformatics and machine-learning software environment. Features Include: . * Chemical reaction handling and transforms * Substructure searching with SMARTS * Canonical SMILES * Molecule-molecule alignment * Large number of descriptors * Fragmentation using RECAP rules * 2D coordinate generation and depiction * 3D coordinate generation using geometry embedding * UFF forcefield * Calculation of (R/S) stereochemistry codes * Pharmacophore searching * Calculation of shape similarity * Atom pairs and topological torsions fingerprints * Feature maps and feature-maps vectors * Machine-learning algorithms * Gasteiger-Marsili partial charge calculation . File formats RDKit supports include MDL Mol, SDF, TDT, SMILES and RDKit binary format. Michael -- 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/20110902142352.ga22...@nighthawk.chemicalconnection.dyndns.org
e2dis status update
> Steve McIntyre writes: > Ivan Shmakov wrote: >> It was my understanding that Jigdo's .template cannot associate one >> SHA-1 with such a non-contiguous chunk. > Correct. That could be added as a feature, maybe - we could add > extent-mapping. The format seemed to me a bit ad hoc, so I've used SQLite3 instead. The news is that both the disassembly (e2dis) and reassembly (imrt) tools are now working (but read below for a caution) and available from their public Git repository [1] at Gitorious! [1] https://gitorious.org/e2dis/e2dis-devel The performance of e2dis itself is apparently out of concern: $ tail -n7 -- \ +nohup.out-1314862288 \ +nohup.out-1314881076 ==> +nohup.out-1314862288 <== I: inode: ino=393214, blocks=0, size=0 I: inode: ino=393215, blocks=0, size=0 I: inode: ino=393216, blocks=0, size=0 I: filesystem: payload_blocks=286523 sqlite3_exec (db, `END;', 0, 0, => `(null)') => 0 108.10user 10.19system 2:34.25elapsed 76%CPU (0avgtext+0avgdata 0maxresident)k 8395040inputs+72outputs (7major+1229minor)pagefaults 0swaps ==> +nohup.out-1314881076 <== I: inode: ino=131071, blocks=0, size=0 I: inode: ino=131072, blocks=0, size=0 I: filesystem: payload_blocks=476432 Unknown code ext2 47 #0 for Payload blocks bitmap Unknown code ext2 47 #0 for block bitmap for /dev/stdin 24.90user 3.90system 0:36.49elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k 1044670inputs+32outputs (3major+1203minor)pagefaults 0swaps $ The respecitve filesystems' sizes are as follows: Filesystem 1K-blocks Used Available Use% FILESYSTEM-1 3096336 1146168 1792884 39% FILESYSTEM-2507748477089 4445 100% And the sizes of the resulting indices are: 11054080 (3.5%) 0bca32a2-d46c-11e0-935b-001966aaa0b6.db 6078464 (1.2%) 105f858e-d498-11e0-935b-001966aaa0b6.db (No data in the indices beyond, roughly, the offsets, the hashes, and the inode numbers.) Unfortunately, the performance of the image reassembly tool (imrt) is extremly poor for the filesystems of more than a few MiB's size. (And it seems that there may be subtle bugs, too.) As with jigdo-file(1), imrt doesn't rely on filenames, and instead “guesses” the output chunks the files passed to it correspond by comparing the hashes (SHA-1 and SHA256 as of a726267a.) However, such a comparison is currently implemented in a straightforward yet suboptimal (as in: totally dumb) way, leading to the problem. I still hope to rewrite the respective part of the code and reach a better reassembly rate, and will report to the list. > I'm also thinking of adding code to say "this file from within this > .deb", so we could maybe support jigdo for live images too... That doesn't seem to be necessary: jigdo-file(1) relies on hashes, not filenames; and jigdo-lite(1) could be taught to recognize .deb's and unpack them into a temporary directory, for jigdo-file(1) to pick up the contents. -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- 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/86k49r9f28.fsf...@gray.siamics.net
Re: e2dis: a Jigdo-like tool for Ext2+ FS images
Ivan Shmakov wrote: > > It was my understanding that Jigdo's .template cannot associate > one SHA-1 with such a non-contiguous chunk. Correct. That could be added as a feature, maybe - we could add extent-mapping. I'm also thinking of adding code to say "this file from within this .deb", so we could maybe support jigdo for live images too... -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- 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/e1qzudy-0006zl...@mail.einval.com
Re: kernel.org compromised
On 2011-09-02, Henrique de Moraes Holschuh wrote: > On Fri, 02 Sep 2011, Bastian Blank wrote: >> On Thu, Sep 01, 2011 at 06:05:01PM -0300, Henrique de Moraes Holschuh wrote: >> > Our kernels are not a problem. The Debian mirror in mirrors.kernel.org, >> > on the other hand... While the apt signature will protect users >> > downloading packages through the package manager, users that get binary >> > packages directly are not protected. >> The connection is not authenticated, so it makes no difference if you >> get modified stuff or if it is modified in transit. > Yeah, yeah. We've beaten that horse to death, and our side lost. I also > advocate that all debs should be signed, but that was not the will of the > ftp-masters the last time the issue was up for discussion. And we should get the archive signing key into a HSM. Kind regards Philipp Kern -- 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/slrnj61olv.nu6.tr...@kelgar.0x539.de
Bug#640110: ITP: ruby-ascii85 -- Ruby library to encode/decode the Ascii85 format
Package: wnpp Severity: wishlist Owner: "Cédric Boutillier" This library is one of the dependencies of a new version of libprawn-ruby (soon to be renamed ruby-prawn). It is therefore needed to get a newer version of ruby-prawn into Debian. * Package name: ruby-ascii85 Version : 1.0.1 Upstream Author : Johannes Hozfuß * URL : http://rubyforge.org/projects/ascii85/ * License : Expat Programming Lang: Ruby Description : Ruby library to encode/decode the Ascii85 format Ascii85 (also called "Base85") is a form of binary-to-text encoding, wich is mainly used in Adobe's PostScript and PDF format. This package provides a ruby library to encode/decode Ascii85. It ships also a command line utility, which can encode/decode files to the standard output. Best wishes, Cédric signature.asc Description: Digital signature
Re: kernel.org compromised
On Fri, 02 Sep 2011, Bastian Blank wrote: > On Thu, Sep 01, 2011 at 06:05:01PM -0300, Henrique de Moraes Holschuh wrote: > > Our kernels are not a problem. The Debian mirror in mirrors.kernel.org, > > on the other hand... While the apt signature will protect users > > downloading packages through the package manager, users that get binary > > packages directly are not protected. > > The connection is not authenticated, so it makes no difference if you > get modified stuff or if it is modified in transit. Yeah, yeah. We've beaten that horse to death, and our side lost. I also advocate that all debs should be signed, but that was not the will of the ftp-masters the last time the issue was up for discussion. So what if data could also be changed on transit: that's still a lot less likely than it being changed in-place on a compromised system, so it really doesn't make the case for verifying the data in mirrors.k.o any weaker. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110902131512.ga4...@khazad-dum.debian.net
Re: kernel.org compromised
On Thu, Sep 01, 2011 at 06:05:01PM -0300, Henrique de Moraes Holschuh wrote: > Our kernels are not a problem. The Debian mirror in mirrors.kernel.org, > on the other hand... While the apt signature will protect users > downloading packages through the package manager, users that get binary > packages directly are not protected. The connection is not authenticated, so it makes no difference if you get modified stuff or if it is modified in transit. Bastian -- Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3 -- 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/20110902094857.ga14...@wavehammer.waldi.eu.org
