Re: Par ou commencer ??
T'avais commencé par faire quoi, toi ?Le packaging me tente bien, la je termine un truc et apres je vais regarder les liens. Merci de m'avoir aidé Tony P.S : T'es en Licence Pro où ?
Re: Par ou commencer ??
On 11:49 Wed 23 Nov , Tony wrote: T'avais commencé par faire quoi, toi ? Je ne suis pas 'développeur officiel' mais je participe à plusieurs projets tel que l'installeur debian, skolelinux(debian-edu), co-mainteneur de package... Je participe aussi à quelques 'events' style fosdem, linuxtag, rmll, install party et je suis membres de 2 Lugs. Voila en gros ;) **Le packaging me tente bien, la je termine un truc et apres je vais regarder les liens. Sinon il y a aussi du boulot niveau traduction, etc... à toi de voir. Merci de m'avoir aidé Tony P.S : T'es en Licence Pro où ? Strasbourg Amicalement, -- --- Oswald Xavier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Par ou commencer ??
Ben, c'est pas mal quand même! Merci pour les conseils. Tony
Re: I am still on the keyring. With my old key.
On Tue, 22 Nov 2005 21:41:21 +0100, Andreas Schuldei [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005-11-21 23:33:48]: If the DPL team is actually addressing that issue, it is not doing so transparently. That was on purpose. we thought that there was something to be learned from threads on public mailinglists that lead nowhere and wanted to try private mail threads that lead nowhere, instead. What are you trying to do instead? If you might have noticed, we have _just_ _another_ ftpmaster situation _right_ _now_, and from handling of #339686 by a member of the DPL team I don't get the impression that the DPL team actually cares. In fact, how can the message of we don't care about security if it's ftpmaster breaking security features be more official than by the downgrade of that bug to wishlist by a DPL team member? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
* Marc Brockschmidt: Today (or last night, whatever), the dak installation on ftp-master was changed to not accept packages that include more than 3 parts, which are usually the binary version and the compressed control and data tarballs. This means that signed binary packages are rejected. This is a pity. I think dpkg-sig is an important step into the right direction: providing more assurances about package integrity to our users. I'm confused about the status of the dak change, though. The dak mirror on merkel does not show any modifiations of the jennifer script since May 31. The diff at http://cvs.debian.org/dak/jennifer?root=dakr1=1.56r2=1.57 shows that the additional check was *removed*, not *added* more than a week ago. Therefore, the dak CVS does not reflect what's actually in production use. Since there is no way for Debian Developers to review the way Debian packages are created (and it's totally out of question for end users), something that provides DD-to-user package signatures at least in some cases is very desirable indeed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340404: ITP: libemail-valid-loose-perl -- Email::Valid which allows dot before at mark
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] * Package name: libemail-valid-loose-perl Version : 0.04 Upstream Author : Tatsuhiko Miyagawa [EMAIL PROTECTED] * URL : http://search.cpan.org/~miyagawa/Email-Valid-Loose-0.04/ * License : Perl: Artistic/GPL Description : Email::Valid which allows dot before at mark Email::Valid::Loose is a subclass of Email::Valid, which allows dot (.) before at-mark (@). It is invalid in RFC822, but is commonly used in some of mobile phone addresses in Japan (like docomo.ne.jp or jp-t.ne.jp). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Anh vao dia chi nay nhe
Em tim duoc dia chi cuu data cho anh roi, anh goi so may nay nhe: 04- 9875709, o do ho chuyen sua chua may vi tinh va chuyen cuu du lieu day. Day la dia chi website cua ho: http://suachua.vnn.vn anh vao do xem truoc gia ca cuu du lieu va dia chi cu the cua ho nhe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
On Monday 21 November 2005 16:44, Goswin von Brederlow wrote: Frank Küster [EMAIL PROTECTED] writes: Hi, on the debian-tetex-maint mailing list we often have problems to decide which of the thousands of TeX input files should be treated as configuration files - in principle, each of them can be changed in order to change the behavior of the system. We are currently thinking about a solution were there would be hardly any conffiles[1], but a local admin could put copies of any file he likes into subdirectories of /etc/texmf. This would shadow the dpkg-shipped file in /usr/share/texmf and allow configuration. And of course we would document this. What do others think? Would it be acceptable Policy-wise to handle configuration like this? Regards, Frank I think other packages have the same problem, gconf comes to mind, and they should sit together and work out a common solution. Multi-level configuration is definately the way to go when possible IMHO (this was also the conclusion reached at the CDD devcamp last spring). gconf/gnome, KDE, XFCE, and any freedesktop-basedir-spec compliant system already allow multilevel configuration stacking: each has a search path which specifies the locations to look for any config key, for each config key the search path is looked through and the first match is used (the desktop-profiles package provides a general mechanism for managing the search paths of the various DE's) So you can for example have 4 config sets (each in its own location): - one with the upstream default values - one with overrides for upstream settings by maintainer - one with cdd-overrides for the settings - one with admin-overrides for the settings Each party can then change his settings independently of the others, overriding (only) the defaults they care about. There is one major drawback, however: If a file that has a (changed) copy in /etc/texmf is changed in the deb, the user gets no notification. This is at least annoying - but on the other hand, many users have newer or changed versions in /usr/local/share/texmf or in $HOME/texmf, and they face the same problem. It would be nice to notify the user about changes in the default config and give the choice of a diff or 3 way merge. Maybe this is something that could be added to ucf (e.g. option --modified-file=/etc/texmf/foo) and then present the user with the same options and frontend as with normal config files. If (as is the case for KDE, Gnome and XFCE) the granularity when combinying the different configuration settings is per config-key and not config-file any merge problems basically disappear: you just make sure you set the search path to reflect the precedence among the various configuration sets, any changes made by a party whose configuration settings have lower precedence are then used transparently unless you've overriden that specific setting. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpK7UVOT8ijI.pgp Description: PGP signature
There must be bug. But where? (was: Trying to create an Ubuntu repository)
Sent to debian-devel mailing list. BCC to Ola. Am Dienstag, den 22.11.2005, 21:31 +0100 schrieb Daniel Leidert: Am Dienstag, den 22.11.2005, 12:54 +0100 schrieb Ola Lundqvist: On Tue, Nov 22, 2005 at 02:54:15AM +0100, Daniel Leidert wrote: [Creating an Ubuntu repository on a Debian system using debarchiver] dists/breezy/universe/binary-i386/:E: Sub-process gzip returned an error code (100) E: Errors apply to file '/var/lib/debarchiver_ubuntu/dists/breezy/universe/binary-i386/misc/gcu_0.4.7-0dl2ubuntu1_i386.deb' E: Sub-process gzip returned an error code (100) E: Errors apply to file '/var/lib/debarchiver_ubuntu/dists/breezy/universe/binary-i386/libs/libgcu0c2_0.4.7-0dl2ubuntu1_i386.deb' E: Sub-process gzip returned an error code (100) E: Errors apply to file '/var/lib/debarchiver_ubuntu/dists/breezy/universe/binary-i386/libdevel/libgcu-dev_0.4.7-0dl2ubuntu1_i386.deb' 3 files 171kB 0s dists/breezy/universe/binary-all/:E: Sub-process gzip returned an error code (100) E: Errors apply to file '/var/lib/debarchiver_ubuntu/dists/breezy/universe/binary-all/doc/libgcu-doc_0.4.7-0dl2ubuntu1_all.deb' New 34B 1 files 118kB 0s dists/breezy/universe/source/: 1 pkgs in 0s Done Packages, Starting contents. dists/breezy/Contents-i386: 0 files 0B 0s dists/breezy/Contents-all: New 20B 0 files 0B 0s Done. 289kB in 4 archives. Took 0s [..] Isn't this just a simple permission problem somewhere... I don't know. Where? My normal Debian archive runs fine. No problems with debarchiver there. Ok. I now also get this error with my Debian archive, after I tried uploading the current opera-package: dists/experimental/main/binary-i386/: 1 files 2038kB 0s dists/experimental/main/binary-all/: New 34B 0 files 0B 0s dists/experimental/contrib/binary-i386/: 0 files 0B 0s dists/experimental/contrib/binary-all/: New 34B 0 files 0B 0s dists/experimental/non-free/binary-i386/: 0 files 0B 0s dists/experimental/non-free/binary-all/: New 34B 0 files 0B 0s dists/unstable/main/binary-i386/: New 36.4kB 17 files 23.7MB 0s dists/unstable/main/binary-all/: New 3983B 3 files 2274kB 0s dists/unstable/contrib/binary-i386/: New 3150B 2 files 3468kB 0s dists/unstable/contrib/binary-all/: New 9952B 7 files 10.7MB 0s dists/unstable/non-free/binary-i386/:E: Sub-process gzip returned an error code (100) E: Errors apply to file '/var/lib/debarchiver/dists/unstable/non-free/binary-i386/web/opera_8.51-20051114.6_i386.deb' 11 files 56.0MB 0s dists/unstable/non-free/binary-all/: New 34B 0 files 0B 0s dists/stable/main/binary-i386/: 1 files 1550kB 0s dists/stable/main/binary-all/: New 34B 0 files 0B 0s dists/stable/contrib/binary-i386/: 0 files 0B 0s dists/stable/contrib/binary-all/: New 34B 0 files 0B 0s dists/stable/non-free/binary-i386/: 1 files 43.7MB 0s dists/stable/non-free/binary-all/: New 34B 0 files 0B 0s dists/experimental/main/source/: 1 pkgs in 0s dists/experimental/contrib/source/: 0 pkgs in 0s dists/experimental/non-free/source/: 0 pkgs in 0s dists/unstable/main/source/: 11 pkgs in 0s dists/unstable/contrib/source/: 5 pkgs in 0s dists/unstable/non-free/source/: 1 pkgs in 0s dists/stable/main/source/: 1 pkgs in 0s dists/stable/contrib/source/: 0 pkgs in 0s dists/stable/non-free/source/: 0 pkgs in 0s Done Packages, Starting contents. dists/unstable/Contents-i386: New 353kB 29 files 78.9MB 0s dists/experimental/Contents-all: New 20B 0 files 0B 0s dists/unstable/Contents-all: New 50.0kB 10 files 13.0MB 0s dists/stable/Contents-all: New 20B 0 files 0B 0s Done. 143MB in 43 archives. Took 0s I have no idea, what is causing this problem. There is no useful output at all. Running the related apt-ftparchive command via su debarchiver -c ... or as root works. Running the debarchiver script via cron results in the mentioned error. As far as I know, gzip complains about non-existent gzip. Any ideas, where the bug could be? System is an up-to-date Debian Sid. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
Gabor Gombas [EMAIL PROTECTED] writes: On Tue, Nov 22, 2005 at 09:48:53AM +0100, Goswin von Brederlow wrote: Aparently yes. Menu seems to be smart enough for that, see other mails. Bad example, sorry. But manpages certainly aren't. Well, being able to read the documentation (including the man page) of a binary without requiring the binary to be installed is a good thing IMHO. Especially for big and complex software that is likely to be split to pkg and pkg-data... Gabor I prefer to have a 1:1 correlation between binaries and manpages. But that is just me. Other things would be cron jobs, inetd entries, init.d scripts. I'm not sure that putting the init.d script into foo-data is the best idea. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
Ricardo Mones [EMAIL PROTECTED] writes: | foo | foo-data -+--+- foo needs foo-data | Depends: foo-data| Suggests: foo -+--+- foo may use foo-data | Recommends: foo-data | Depends: foo foo-data useless | | Enhances: foo [*] without foo | | -+--+- foo may use foo-data | Recommends: foo-data | Suggests: foo foo-data useful | | Enhances: foo [*] without foo | | The Enhances would add an extra meaning to explain why foo-data package is either Depending or Suggesting foo, which in these cases is not the usual Depend meaning IMHO: the data doesn't really need anything to work :) Sounds good. I thought you ment Enhances even with foo depending. But this way is exatly how I have in mind. This way frontends can offer the choise of installing foo-data when the user selects foo. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
just throwing a quick $0.02 in here,
On Wed, Nov 23, 2005 at 01:51:30PM +0100, Goswin von Brederlow wrote:
Well, being able to read the documentation (including the man page) of a
binary without requiring the binary to be installed is a good thing
IMHO. Especially for big and complex software that is likely to be
split to pkg and pkg-data...
I prefer to have a 1:1 correlation between binaries and manpages. But
that is just me.
i think the idea is that if you have the package providing the binary
installed, you implicitly have the -data package installed. so, does
it matter that if you manually chose to do so, you could have manpages
for binaries not on your system, as long as you could never have
binaries on your system without their manpages?
Other things would be cron jobs, inetd entries, init.d scripts. I'm
not sure that putting the init.d script into foo-data is the best
idea.
there are cases where having these files in a seperate package can
be a good thing. for example, two packages i have direct experience
with (nagios and mysql) both profit from having a single -common
(arch: all) package which shares init scripts, web server
configs, etc between multiple server-providing binary packages
(nagios-{text,mysql,pgsql}, mysql-server-{4.1,5.0}).
the proviso is that a little more care has to be taken to make sure that
some of these things behave in the absence of the binary package.
policy already states that init scripts (9.3.2) and cronjobs (9.5)
must do so, the other stuff is a little more context dependant.
sean
--
signature.asc
Description: Digital signature
Re: Uploading amd64 packages
Steve Langasek [EMAIL PROTECTED] writes: On Tue, Nov 22, 2005 at 08:13:23AM -0600, Ken Bloom wrote: Why not accept the AMD64 binaries, then dump the AMD64 binaries because you don't know what to do with them, but accept the arch:all debs from that upload? Why would ftp-master want to work on special-casing amd64 for this instead of just working on getting amd64 into the archive? Because the former takes 10 minutes while the later takes weeks and coordination with all mirrors. Also the DAK could ignore all !all debs on all uploads and let everything autobuild. No special casing amd64 there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340404: ITP: libemail-valid-loose-perl -- Email::Valid which allows dot before at mark
On Wed, Nov 23, 2005 at 11:06:32AM +0100, Krzysztof Krzyzaniak (eloy) wrote: * Package name: libemail-valid-loose-perl Version : 0.04 Upstream Author : Tatsuhiko Miyagawa [EMAIL PROTECTED] * URL : http://search.cpan.org/~miyagawa/Email-Valid-Loose-0.04/ * License : Perl: Artistic/GPL Description : Email::Valid which allows dot before at mark Email::Valid::Loose is a subclass of Email::Valid, which allows dot (.) before at-mark (@). It is invalid in RFC822, $ perl -MEmail::Valid -le 'print Email::Valid-rfc822(q([EMAIL PROTECTED]))' 1 I think the description needs to be improved; perhaps it means dot (.) immediately before at-mark (@), which *is* invalid in RFC822. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
* Brian May ([EMAIL PROTECTED]) wrote: Are you saying you should bounce SPAM mail??? *I* don't bounce much of anything. Talk to Ian about wanting to generate bounces, it wasn't my idea. What I want is for him to bounce it himself if he feels it needs to be bounced, not make master do it. No, I don't think trying to enforce his policies on master is an option either, sorry. The real point here is that, for mail coming from master, it's *going* to get bounced one way or another, unless Ian decides to try to classify the message himself as 'deserving a bounce' or not. Yes, in this case the mail would bounce anyway, but I think the solution is to improve the SPAM checking on master, and not accept the mail in the first place. Even with better SPAM checking on master it's very unlikely that master's policy will ever agree completely with Ian's (and everyone else's, whose policies are probably different from Ian's..) and so this kind of setup is unlikely to ever actually work (where you're depending on your forwarding hosts to implement the same policy you have). Yes, you could probably make mail from master.debian.org bypass SMTP level SPAM controls, but taken to the extreme, you would have to also do this to every server that forwards you email (perhaps even every mailing list server?). That would be the point, yes. Taken a bit further, you'd have to clasify the mail as SPAM or not yourself and generate a bounce or not as appropriate. It's honestly not all that difficult. Thanks, Stephen signature.asc Description: Digital signature
Secret changes for binNMUs
Hi, recently some changes have been made to the DAK, wanna-build and buildds for binNMUs that probably went unnoticed to most developers. And since binNMUs are rather uncommon you might not notice for the longest time and then despair. So heres a summary: - buildds can recompile a source with a binNMU version This uses the original Debian source and adds a changelog entry stating that it is an automatic recompile before recompiling. - wanna-build can be asked to schedule a binNMU for an arch This means that you don't have to manualy compile binNMUs anymore, which should probably be discouraged from now on. If you think a binNMU is needed for ome reason a request should be send to debian-release and they will deal with it. - binNMU version scheme changed The developer reference _still_ states binNMU should be versioned as 1.2-3.0.1. The DAK will no longer accept this. Instead binNMU versions are now made by adding +b1 (+b2, +b3) to the version and containing a Source: foo (non-NMU version) line. The later makes it possible to reliable associate binNMUs with their source. If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) or at lest look at what sbuild does for a binNMU before attempting your own. Normaly just ask debian-release do schedule one on the buildds for you. I hope that helps you. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Remove
I have also asked to be removed from 'Call Wave'. I am also on Comcast broadband but my Visa card is still being billed.
Re: Secret changes for binNMUs
* Goswin von Brederlow ([EMAIL PROTECTED]) [051123 15:51]: - binNMU version scheme changed The developer reference _still_ states binNMU should be versioned as 1.2-3.0.1. The DAK will no longer accept this. I am sorry that the developers reference is a bit lagging currently. Do you have some new wording available, or do you want till I find time to fix it myself? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated testing - design and interfaces
On Mon, Nov 21, 2005 at 06:22:37PM +, Ian Jackson wrote: Note that it's often better to have a single script run many tests, so you probably want to allow tests to pass back some summary information, or include the last ten lines of its output or similar. Something like: foo FAIL: FAILURE: testcase 231 FAILURE: testcase 289 FAILURE: testcase 314 3/512 test cases failed This is no good because we want the test environment to be able to tell which tests failed, so the test cases have to be enumerated in the test metadata file. Uh, having to have 1000 scripts, or even just 1000 entries in a metadata file, just to run 1000 tests is a showstopper imho. Heck, identifying testcases by number mightn't be particularly desirable in some instances, if a clearer alternative like, say, test case failed: add 1, add 2, del 1, ch 2 is possible. You can't check that the binary works _when the .deb is installed_ without installing it. That's okay. You can't check that the binary works _on the user's system_ without installing it on the user's system either. For Debian's purposes, being able to run the tests with minimal setup seems crucial. Also, a `Restriction' isn't right because if the test has neither of those Restrictions then presumably it can do either but how would it know which ? It would have to not care which; which it could do by expecting the test harness to put the binaries in the PATH, or provide an environment variable like INSTALL_ROOT=$(pwd)/debian/tmp . No, I mean that if the tests live (say) in build/foo-1.0/debian/tests/x then build/foo-1.0/debian/tests/control could say Depends: bar which would mean bar would have to be installed, effectively making it an integration test. Having test case dependencies is fairly useful; in any event the language Even integration tests can be represented like this: if one package's tests Depend on the other's is wrong if tests depend on other packages, not on other package's tests. You'll want Conflicts: as well as Depends: in that case too. It would probably be quite useful to be able to write tests like: for mta in exim4 smail sendmail qmail; do install $mta # actual test uninstall $mta done too, to ensure that packages that depend on one of a number of packages actually work with all of them. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote: * Marc Brockschmidt: Today (or last night, whatever), the dak installation on ftp-master was changed to not accept packages that include more than 3 parts, which are usually the binary version and the compressed control and data tarballs. This means that signed binary packages are rejected. This is a pity. I think dpkg-sig is an important step into the right direction: providing more assurances about package integrity to our users. Personally, I think it's cryptographic snake oil, at least in so far as it relates to Debian. I remain interested in seeing any realistic demonstration of how a Debian user could reasonably rely on them for any practical assurance. since May 31. The diff at http://cvs.debian.org/dak/jennifer?root=dakr1=1.56r2=1.57 shows that the additional check was *removed*, not *added* more than a week ago. Yes; CVS was corrupted in May and hadn't been updated 'til the other week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak Since there is no way for Debian Developers to review the way Debian packages are created (and it's totally out of question for end users), buildd.debian.org gives full logs, to developers or users. something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. Cheers, aj signature.asc Description: Digital signature
Re: I am still on the keyring. With my old key.
* Marc Haber [EMAIL PROTECTED] [2005:11:23 11:07 +0100]: What are you trying to do instead? If you might have noticed, we have _just_ _another_ ftpmaster situation _right_ _now_, and from handling of #339686 by a member of the DPL team I don't get the impression that the DPL team actually cares. What bug number did you mean? In fact, how can the message of we don't care about security if it's ftpmaster breaking security features be more official than by the downgrade of that bug to wishlist by a DPL team member? What? -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: As I'm responsible for most of dpkg-sig's code (and planned to do some more work in the next two months) I'd like to know if anyone cares about using these binary signatures or if I can invest my time into something that's a bit more satisfying (== non-Debian stuff). As the ftp-masters and the dpkg maintainers seem to have no interest in the whole thing, I'm beginning to doubt that it's sensible to work on dpkg-sig. Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. I'm not going to interpret these numbers, as it's close to impossible to do so objectively. --Jeroen [1] Interested DD's can look into merkel:~jeroen/dpkg-sig how I got these numbers -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
On Wed, 23 Nov 2005 11:32:19 -0500, Erinn Clark [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005:11:23 11:07 +0100]: What are you trying to do instead? If you might have noticed, we have _just_ _another_ ftpmaster situation _right_ _now_, and from handling of #339686 by a member of the DPL team I don't get the impression that the DPL team actually cares. What bug number did you mean? Sorry. #340306. I confused these bugs because in the discussion, somebody used #339686 to show that I am doing a job as bad as Mr. Troup. In fact, how can the message of we don't care about security if it's ftpmaster breaking security features be more official than by the downgrade of that bug to wishlist by a DPL team member? What? See #340306. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005 17:34:41 +0100, Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: As I'm responsible for most of dpkg-sig's code (and planned to do some more work in the next two months) I'd like to know if anyone cares about using these binary signatures or if I can invest my time into something that's a bit more satisfying (== non-Debian stuff). As the ftp-masters and the dpkg maintainers seem to have no interest in the whole thing, I'm beginning to doubt that it's sensible to work on dpkg-sig. Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. So, most of the DD's do not care about security at all. Why does Debian have a reputation of being so secure? Otoh, what does the project gain by making 0.19 % of our debs in the archive less secure than they are now? Are we that damager driven that we deliberately reduce our security just to gain an uniform level? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
* Marc Haber [EMAIL PROTECTED] [2005:11:23 18:40 +0100]: On Wed, 23 Nov 2005 17:34:41 +0100, Jeroen van Wolffelaar Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. So, most of the DD's do not care about security at all. Why does Debian have a reputation of being so secure? Yet just today you filed a bug (#340403) for documentation to be included in the package since you were unable to explain dpkg-sig's strengths. How is it possible for you to claim something is more secure when you don't understand it well enough to say how it's different? -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
I am moving this discussion to debian-devel, since I am not sure we are really violating the Policy. Feel free to move it further to debian-policy, if you think it is appropriate. * Bastian Blank [EMAIL PROTECTED] [2005-11-23 13:18]: Package: octave2.9 Version: 2.9.4-6 Severity: serious octave2.9_2.9.4-6_s390.changes: Format: 1.7 Date: Tue, 22 Nov 2005 14:48:51 +0100 Source: octave2.9 Binary: octave2.9-headers octave2.9-info octave2.9-htmldoc octave2.9 octave2.9-emacsen octave2.9-doc Architecture: s390 Version: 2.9.4-6 Distribution: unstable Urgency: low Maintainer: s390 Build Daemon [EMAIL PROTECTED] Changed-By: Debian Octave Group [EMAIL PROTECTED] [...] octave2.9 lists a mailing list as uploader in the changelog. The policy specifies: | 4.4 Debian changelog: debian/changelog [...] | The maintainer name and email address used in the changelog should be | the details of the person uploading this version. They are not | necessarily those of the usual package maintainer. The information here | will be copied to the Changed-By field in the .changes file (see | Changed-By, Section 5.6.4), and then later used to send an | acknowledgement when the upload has been installed. In the debian/changelog for octave2.9 (and all other packages maintained collectively by the Debian Octave Group, the DOG), we do add details about who made the changes, like this: octave2.9 (2.9.3-1) experimental; urgency=low +++ Changes by Colin Ingram * New upstream release [...] +++ Changes by Rafael Laboissiere * The patches applied by dpatch are now done selectively according to the version of Octave. For that, the debian/patches/00list file is now generated when running ./debian/rules maintainer-scripts from the files debian/in/$(PACKAGE)-00list. [...] -- Debian Octave Group [EMAIL PROTECTED] Fri, 4 Nov 2005 10:30:54 +0100 I think this should be enough. As regards the copy of this information into the Changed-By field of the changes file, we are already requiring that the developers of the DOG use the -e option of debuild (cf the DOG Guidelines, at http://pkg-octave.alioth.debian.org/DOG-Guidelines.html#building-and-uploading-packages). and | 5.6.4 Changed-By |=20 | The name and email address of the person who changed the said package. | Usually the name of the maintainer. All the rules for the Maintainer | field apply here, too. A mailing list is no person which can do uploads. This is why there is the Changed-By filed in the changes file. At any rate, it seems that using mailing lists in changelog entries is common practice, like: http://packages.debian.org/changelogs/pool/main/k/kdebase/kdebase_3.4.2-4/changelog I am not claiming that since others have mailing lists in changelog entries we have also the right to do it. I only want to know how we should address the issue. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: As I'm responsible for most of dpkg-sig's code (and planned to do some more work in the next two months) I'd like to know if anyone cares about using these binary signatures or if I can invest my time into something that's a bit more satisfying (== non-Debian stuff). As the ftp-masters and the dpkg maintainers seem to have no interest in the whole thing, I'm beginning to doubt that it's sensible to work on dpkg-sig. I'd be very interested in the whole idea. -- Misha PS I'm not a DD signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005, Marc Haber wrote: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. So, most of the DD's do not care about security at all. Why does Debian have a reputation of being so secure? Ah, you're a gloom-and-doomer. There's been no push. No default. No message saying that it's acceptable and wanted to sign debs. Most people(not just DD) take the defaults, the easy way out. These numbers will increase when the default is to sign. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
On Wed, 23 Nov 2005, Marc Haber wrote: Sorry. #340306. Hmm... wasn't the situation around this bug cleared up in another d-devel thread no more than two or three days ago, and a fix already commited to CVS? -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On 11/23/05, Marc Haber [EMAIL PROTECTED] wrote: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. So, most of the DD's do not care about security at all. Why does Debian have a reputation of being so secure? Security is more than package signatures.
Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005, Anthony Towns wrote: Personally, I think it's cryptographic snake oil, at least in so far A signed deb has a seal of procedence and allows one to track the path it made through the system, and who changed it. It ties a non-trustable timestamp to every singed step in that path, but that has limited use. It allows one to verify against tampering of the data along that path. It does no more. Nobody who really knows what he's talking about claimed that it did. I do claim that a criptographic seal of procedence and non-tampering IS valuable information, and also that dpkg-sig delivers that information in a much more usable and universal way than anything else we have currently. something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. Not in a very useable form, and only for Debian packages uploaded to the official Debian archive. This is hardly good enough. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Marc Haber writes: So, most of the DD's do not care about security at all. I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005, Jeroen van Wolffelaar wrote: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. I'm not going to interpret these numbers, as it's close to impossible to do so objectively. Well, *I* can speak for myself, and all my packages would have been signed had I known I am allowed to upload signed packages to Debian, which I didn't. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Wed, 23 Nov 2005, Goswin von Brederlow wrote: - buildds can recompile a source with a binNMU version We were told about this, although I can't recall if the proper channel (d-d-a) was used. Would you consider posting your message to debian-devel-announce, please? That's where such extremely important messages belong :-) -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Olaf van der Spek writes: Security is more than package signatures. What is your specific proposal? -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005, John Hasler wrote: Olaf van der Spek writes: Security is more than package signatures. What is your specific proposal? Don't go there, or at least start another thread to do so. Olaf is correct, signed packages are not enough and we have reharsed that discursion a lot. This doesn't mean that signed packages are useless, far from it. -- 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On 11/23/05, John Hasler [EMAIL PROTECTED] wrote: Olaf van der Spek writes: Security is more than package signatures. What is your specific proposal? I don't have one. But I don't see how that's relevant.
Re: Spliting packages between pkg and pkg-data
sean finney [EMAIL PROTECTED] writes:
just throwing a quick $0.02 in here,
On Wed, Nov 23, 2005 at 01:51:30PM +0100, Goswin von Brederlow wrote:
Well, being able to read the documentation (including the man page) of a
binary without requiring the binary to be installed is a good thing
IMHO. Especially for big and complex software that is likely to be
split to pkg and pkg-data...
I prefer to have a 1:1 correlation between binaries and manpages. But
that is just me.
i think the idea is that if you have the package providing the binary
installed, you implicitly have the -data package installed. so, does
it matter that if you manually chose to do so, you could have manpages
for binaries not on your system, as long as you could never have
binaries on your system without their manpages?
For one thing you get rid of the lintian warning about a binary
without manpage. :)
Other things would be cron jobs, inetd entries, init.d scripts. I'm
not sure that putting the init.d script into foo-data is the best
idea.
there are cases where having these files in a seperate package can
be a good thing. for example, two packages i have direct experience
with (nagios and mysql) both profit from having a single -common
(arch: all) package which shares init scripts, web server
configs, etc between multiple server-providing binary packages
(nagios-{text,mysql,pgsql}, mysql-server-{4.1,5.0}).
the proviso is that a little more care has to be taken to make sure that
some of these things behave in the absence of the binary package.
policy already states that init scripts (9.3.2) and cronjobs (9.5)
must do so, the other stuff is a little more context dependant.
Exactly. Having it in a different package means more care has to be
taken. Since most people are lazy that shouldn't be done without a
good reason. Overall what does 1K more or less matter. foo-data
packages are for MiB big themes and similar.
sean
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bangladesh Key-Signing completed - Debian Maintiner base can now be extended there.
Matthew Grant wrote: Hi teRHe! One of my dreams for the last 4 years has been to help the Bangladesh IT industry expand and be enhanced by IT workers having the opportunity to join us, and also to enhance Bangla language support in Linux. Thanks for your interest and great effort! I GPG signed and identified 4 people by their passports and other official ID, on the chance that they may want to become maintainers. Two have decided to go ahead, and I mention them here. It would be good if some Mentors got in touch with them. They are: Salahuddin Pasha [EMAIL PROTECTED] Jamil Ahmed [EMAIL PROTECTED] I believe that Salahuddin is an active participant in the Bangla localisation effort for OpenOffice.org (or is it Jamil - please correct me?) It is me. :) I believe they are both already quite active on some Debian mailing lists. Thank you for helping them. I am looking forward to the Debian Community embracing them and encouragin them with open arms. It is good to see another corner of the map soon to have a red dot on it! Some introduction of me: I am Jamil Ahmed from Dhaka, Bangladesh. Professionally I am working in a local software development company. In my spare time I do maintain some activities for Open Source, mainly localization. Currently I am maintaining/working Bengali/Bangla L10n for Debian, Fedora, Mandriva, OpenSUSE, Gnome, Firefox, Thunderbird, OpenOffice.org . I will try my best to work for Debian. I hope I will get necessary assistance from you when required. :) Regards, `Jamil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
This one time, at band camp, Rafael Laboissiere said: I am moving this discussion to debian-devel, since I am not sure we are really violating the Policy. Feel free to move it further to debian-policy, if you think it is appropriate. FWIW, Rafael, at first blush I have to say I agree with you. A maintainer address in Debian is just a way to get in touch with someone when something goes wrong with the package. If the mailing list is a good way to get in touch with people when those packages break, then it seems like a reasonable maintainer address. Bastian, what's the rationale for the filings you've been doing? Do you really think a mailing list address, (where any and all correspondence about the packages is presumably archived and possibly even publicly accessible), is somehow worse than mailing a single person (who hopefully archives their package mail, but maybe not, and can almost be guaranteed not to have publicly browseable archives)? What are you hoping to do here? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Secret changes for binNMUs
Andreas Barth [EMAIL PROTECTED] writes: * Goswin von Brederlow ([EMAIL PROTECTED]) [051123 15:51]: - binNMU version scheme changed The developer reference _still_ states binNMU should be versioned as 1.2-3.0.1. The DAK will no longer accept this. I am sorry that the developers reference is a bit lagging currently. Do you have some new wording available, or do you want till I find time to fix it myself? Cheers, Andi -- http://home.arcor.de/andreas-barth/ I can give it a shot and send you a draft for it. From a technical point I'm unsure how the following version will (sbuild) and should (dak) be handled: old version binNMU version? 1.2 1.2-0+b1 1.2-3.0.1 1.2-3.0.1+b1 I bet the later will confuse wanna-build, sbuild and the dak and just require a new maintainer upload or source NMU instead. But is the former one correct? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
[Henrique de Moraes Holschuh] Hmm... wasn't the situation around this bug cleared up in another d-devel thread no more than two or three days ago, and a fix already commited to CVS? That's what I thought. But the bug is still open. And jvw's reasoning that it is OK for ftp.debian.org to contradict Policy, on the grounds that Policy deals with packages' behavior not with how the archive should behave is still good for a smile. signature.asc Description: Digital signature
Re: Secret changes for binNMUs
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Wed, 23 Nov 2005, Goswin von Brederlow wrote: - buildds can recompile a source with a binNMU version We were told about this, although I can't recall if the proper channel (d-d-a) was used. Would you consider posting your message to debian-devel-announce, please? That's where such extremely important messages belong :-) Feel free to sign and forward the message. I can't. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP: libming -- Library to generate SWF (Flash) Files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist Owner: Mattias Nordstrom [EMAIL PROTECTED] * Package name: libming Version : 0.3beta1+cvs20050827 Upstream Author : Dave [EMAIL PROTECTED] * URL : http://ming.sf.net/ * License : LGPL Description : Library to generate SWF (Flash) Files Ming is an SWF (Flash) file format output library. It is written in C, with wrappers for C++, Perl, Python, PHP and experimental support for Ruby and Java. - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDhMicwKTxHeBrP5cRAi0yAJ90XuQr0jS9F0mVBjA9eSOk+5XFDQCeOpe3 BmvCNp7yNu6LFGgWkoCDlYI= =bxcu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns aj@azure.humbug.org.au writes: On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote: * Marc Brockschmidt: Today (or last night, whatever), the dak installation on ftp-master was changed to not accept packages that include more than 3 parts, which are usually the binary version and the compressed control and data tarballs. This means that signed binary packages are rejected. This is a pity. I think dpkg-sig is an important step into the right direction: providing more assurances about package integrity to our users. Personally, I think it's cryptographic snake oil, at least in so far as it relates to Debian. I remain interested in seeing any realistic demonstration of how a Debian user could reasonably rely on them for any practical assurance. Use 1: I have this deb in my apt-move mirror and I want to know if it was compromised on yesterdays breakin Boot a clean system with debian keyring and check all deb signatures. Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). Use 3: The debian servers were compromised and the security team takes too long to check the archive for my taste Being a normal user I obviously have no mail archive of all the old changes files laying around so that road is closed. But everyone has a Debian stable CD with keyring. See Use 1. Use 4: The Debian Archive Key has expired yet again, like every year or the Release.gpg file is out of sync as so often on some mirrors and I still want to verify debs. Check deb signatures against the keyring instead of the Release.gpg check in apt. Use 1, 3 and 4 rely on a manual signature of each deb. One suggestion is to add this to debsign so the only change for developers is that gpg asks for the passphrase more often. Use 2 would require an automatic signature by the archive. since May 31. The diff at http://cvs.debian.org/dak/jennifer?root=dakr1=1.56r2=1.57 shows that the additional check was *removed*, not *added* more than a week ago. Yes; CVS was corrupted in May and hadn't been updated 'til the other week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak Since there is no way for Debian Developers to review the way Debian packages are created (and it's totally out of question for end users), buildd.debian.org gives full logs, to developers or users. While the log contains the md5sum of each build deb it does not contain any signature against tampering. Same goes for the mail exchange between the buildd and admin for all the admins that sign by mail. Tampered debs can be uploaded by sending a fake mail to the admin and filtering out his responce. A deb signature of the buildd and a subsequent dak check would prevent this. something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. That covers only the sourcefull uploads and the arch specific -changes lists are not archived and therefore useless for non constant monitoring. Cheers, aj MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Marc Haber [EMAIL PROTECTED] wrote: What are you trying to do instead? If you might have noticed, we have _just_ _another_ ftpmaster situation _right_ _now_, and from handling of #339686 by a member of the DPL team I don't get the impression that the DPL team actually cares. (#340306) In fact, how can the message of we don't care about security if it's ftpmaster breaking security features be more official than by the downgrade of that bug to wishlist by a DPL team member? Rejecting signed packages is not equivalent to we don't care about security. You appear to be complaining that a bug that was filed on Tuesday hasn't been fixed on Wednesday. Further, this appears to be a bug that affects a tiny number of people. Expecting it to be prioritised over anything else that people may be working on is insane, and bringing it up in such a hostile manner (not to mention attempting to use it to claim that the DPL team don't care about your particular issue) isn't going to result in it being fixed faster. Instead, it's going to result in people assuming that you're some sort of conspiracy-theory loon. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: There must be bug. But where?
Let me just make the suggestion to better use reprepro. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Goswin von Brederlow [EMAIL PROTECTED] wrote: Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). The answer is all of them, so this one's not very compelling. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
[Erinn Clark] Yet just today you filed a bug (#340403) for documentation to be included in the package since you were unable to explain dpkg-sig's strengths. How is it possible for you to claim something is more secure when you don't understand it well enough to say how it's different? That's unfair and you know it. It seems he *did* educate himself about dpkg-sig: I had to look for a while to find the dpkg-sig FAQ on the web page. It is perfectly reasonable to want users to have easy access to this information, given the rather confusing array of signature-related packages and options in Debian packaging. Not knowing the relative advantages of dpkg-sig versus debsigs is hardly the same thing as being unqualified to speak about the reasons (or lack thereof) to support signed .debs. And, from what I understand, the dak change which proved so contentious broke both equally. (Whether Andreas's script counted packages signed with debsigs as well as those signed with dpkg-sig, I don't know, as I don't have access to it.) I do think a feature comparison and compatibility matrix would be useful to have, between dpkg-buildpackage/debsign (for signing .changes and .dsc files), debsigs (for signing .deb files), dpkg-sig (for signing and verifying .deb files) and debsig-verify (for verifying .deb files). signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
[Goswin von Brederlow] Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). [Matthew Garrett] The answer is all of them, so this one's not very compelling. What? All Ubuntu .deb files went through ftp-master.debian.org at some point? I know you can't actually mean that. Hmmm, perhaps you meant none of them? If so, that's an Ubuntu-specific answer, because even if Ubuntu recompiles all packages, many Debian derivative distributions do not. Or did you mean signatures on individual debs are not useful for this purpose since one could instead simply archive the Packages and Release files for Debian unstable every day between one Ubuntu release and the next? While possible, this has approximately the same absurdity factor as asking users to subscribe to debian-devel-changes and keep enough mail archives around to verify developer signatures *that* way. (Yes, believe it or not, that has actually been proposed!) signature.asc Description: Digital signature
Re: I am still on the keyring. With my old key.
On Wed, 23 Nov 2005 16:14:47 -0200, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 23 Nov 2005, Marc Haber wrote: Sorry. #340306. Hmm... wasn't the situation around this bug cleared up in another d-devel thread no more than two or three days ago, and a fix already commited to CVS? According to the reports of another member of the ftp-master team, the situation was cleared up, but Mr. Troup re-enabled the check that breaks dpkg-sig on purpose after not being amused about HE's rant on here. And productive jennifer is not accessible anywhere, and it is not the version available from dak CVS. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005 17:03:51 -0200, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: This doesn't mean that signed packages are useless, far from it. They are useless at the moment. They cannot be uploaded. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005 12:11:20 -0600, John Hasler [EMAIL PROTECTED] wrote: Marc Haber writes: So, most of the DD's do not care about security at all. I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. dpkg-sig is harly hard to use. Even I learned how to use it in two minutes from reading the man page. And I am known to be stupid. People finding stuff like dpkg-sig and debsigs hard to use do not care about security. Thanks for proving my point. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005 12:09:34 -0600 (CST), Adam Heath [EMAIL PROTECTED] wrote: There's been no push. No default. No message saying that it's acceptable and wanted to sign debs. So Debian doesn't care about security. If we did, we would have an official message saying so. Why do we have the reputation of being so secure? Most people(not just DD) take the defaults, the easy way out. These numbers will increase when the default is to sign. Currently, it is not even an option to sign. Which is a severe degradation compared to last week's state of affairs. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Wed, 23 Nov 2005 12:58:12 -0500, Erinn Clark [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005:11:23 18:40 +0100]: On Wed, 23 Nov 2005 17:34:41 +0100, Jeroen van Wolffelaar Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There are 8 distinct keys used for those 525 .deb's, seven of which correspond to DD's[1]. So, most of the DD's do not care about security at all. Why does Debian have a reputation of being so secure? Yet just today you filed a bug (#340403) for documentation to be included in the package since you were unable to explain dpkg-sig's strengths. The requested documentation is available online, and I have had the opportunity to talk to dpkg-sig's authors and independent security people about its advantages. How is it possible for you to claim something is more secure when you don't understand it well enough to say how it's different? Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). I know this is a contrived use case, but Ubuntu doesn't use any .debs from Debian. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: As I'm responsible for most of dpkg-sig's code (and planned to do some more work in the next two months) I'd like to know if anyone cares about using these binary signatures or if I can invest my time into something that's a bit more satisfying (== non-Debian stuff). As the ftp-masters and the dpkg maintainers seem to have no interest in the whole thing, I'm beginning to doubt that it's sensible to work on dpkg-sig. Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). Of these 283283 debs, only ~1/9 (1 of 11 archs - packages that are arch: all, that's only an assumption, correct me if i'm wrong) are directly uploaded by developers. About 1/4 of the pool should be woody packages (which was released before dpkg-sig). So we get 283283 * 1/9 * 3/4, which gives us about 23606 packages, which means that 525 are about 2.25%. Regarding the fact that dpkg-sig is not actively advertised because support in dak and dpkg is still missing, that's not *too* bad. Marc -- Fachbegriffe der Informatik - Einfach erklärt 25: Multithreaded Wir mußten ein Flußdiagramm malen, um es zu debuggen. (Kristian Köhntopp) pgp7Gj4faAr2l.pgp Description: PGP signature
Re: Automated testing - design and interfaces
On Wed, 2005-11-23 at 18:16 +1000, Anthony Towns wrote: On Mon, Nov 21, 2005 at 06:22:37PM +, Ian Jackson wrote: Note that it's often better to have a single script run many tests, so you probably want to allow tests to pass back some summary information, or include the last ten lines of its output or similar. Something like: foo FAIL: FAILURE: testcase 231 FAILURE: testcase 289 FAILURE: testcase 314 3/512 test cases failed This is no good because we want the test environment to be able to tell which tests failed, so the test cases have to be enumerated in the test metadata file. Replying to two messages here ... I don't think we have to enumerate the tests in advance. Sure the test runner needs to be able to identify and [possibly] categorise the tests, but explicit enumeration is quite orthogonal. A number of python unittest runners will scan directories and classes for their tests, and the report from users is consistently that this is easier to use. Uh, having to have 1000 scripts, or even just 1000 entries in a metadata file, just to run 1000 tests is a showstopper imho. Heck, identifying testcases by number mightn't be particularly desirable in some instances, if a clearer alternative like, say, test case failed: add 1, add 2, del 1, ch 2 is possible. A very nice feature in the xUnit world is that tests can be identified by either their path (inside the language namespace) or by a comment written by the author. At runtime you can choose which to see. I dont think we need the ability for runtime selection, but having a heuristic that works and is overridable would be nice. I.e. by default you might get tests/layout/documentation_in_usr_share_doc.sh: PASS But inside that test you could say: test_name Documentation is installed in /usr/share/doc and the output becomes Documentation is installed in /usr/share/doc: PASS I've written a project that is somewhat related to this: http://www.robertcollins.net/unittest/subunit/ Its a python implementation of a cross process test running protocol. This lets a sub process run 0 to many tests, identify them and provide pass/fail/error status and traceback or other diagnostics. As the driver is python its not appropriate here, but I think the basic protocol/concept might be useful. You can't check that the binary works _when the .deb is installed_ without installing it. That's okay. You can't check that the binary works _on the user's system_ without installing it on the user's system either. For Debian's purposes, being able to run the tests with minimal setup seems crucial. Yup It would probably be quite useful to be able to write tests like: for mta in exim4 smail sendmail qmail; do install $mta # actual test uninstall $mta done too, to ensure that packages that depend on one of a number of packages actually work with all of them. Yes, that would be excellent. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: dpkg-sig support wanted?
I wrote: I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. Marc Haber writes: dpkg-sig is harly hard to use. Please re-read what I wrote. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: I'd like to know if anyone cares about using these binary signatures Before your mail I was completely unaware of the existence of dpkg-sig. Now that I know it, I care about it and would like to start uploading my packages dpkg-sig-ed (being it possible!). I hope the current setting will be fixed soon and I will fill a whishlist bugreport against debuild to support dpkg-sig side by side with debuild. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
* John Hasler [EMAIL PROTECTED] [051123 19:11]: So, most of the DD's do not care about security at all. I think that DD's do not use dpkg-sig and debsigs because they believe them to be hard to use and not supported by the infrastructure or by policy. ... or not even know about them. I haven't heard about HE mentioned them. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
Peter Samuelson [EMAIL PROTECTED] wrote: [Goswin von Brederlow] Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled =20 Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). [Matthew Garrett] The answer is all of them, so this one's not very compelling. [Someone with a horrid, horrid quoting style] What? All Ubuntu .deb files went through ftp-master.debian.org at some point? I know you can't actually mean that. Hmmm, perhaps you meant none of them? If so, that's an Ubuntu-specific answer, because even if Ubuntu recompiles all packages, many Debian derivative distributions do not. I was unclear. All of them are recompiled. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
AUTOREPLY from Firenze.net
== Bellacopia.com - Il servizio italiano online di stesura e revisione testi == Grazie per averci scritto. Sara' nostra cura rispondervi al piu' presto. == Questo e' un messaggio automatico == Per qualsiasi comunicazione vi preghiamo di utilizzare gli indirizzi: [EMAIL PROTECTED] (preventivi) [EMAIL PROTECTED] (informazioni) Cordiali saluti Bellacopia.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). I know this is a contrived use case, but Ubuntu doesn't use any .debs from Debian. One could prove that. :) There are tons of debian spin offs out there and a lot will use Debians debs, esspecially CDD disks. So I still stand by that use. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: As I'm responsible for most of dpkg-sig's code (and planned to do some more work in the next two months) I'd like to know if anyone cares about using these binary signatures or if I can invest my time into something that's a bit more satisfying (== non-Debian stuff). As the ftp-masters and the dpkg maintainers seem to have no interest in the whole thing, I'm beginning to doubt that it's sensible to work on dpkg-sig. Just to provide some statistics about dpkg-sig usage, as I got curious about it too: In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). Of these 283283 debs, only ~1/9 (1 of 11 archs - packages that are arch: all, that's only an assumption, correct me if i'm wrong) are directly uploaded by developers. About 1/4 of the pool should be woody packages (which was released before dpkg-sig). So we get 283283 * 1/9 * 3/4, which gives us about 23606 packages, which means that 525 are about 2.25%. Regarding the fact that dpkg-sig is not actively advertised because support in dak and dpkg is still missing, that's not *too* bad. Marc Subtract all sarge debs as signed debs were unwanted for that in fear of some unknown breakage. Further subtract all packages without upload since sarge. Gosh, the percentage keeps on rising. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Stefano Zacchiroli [EMAIL PROTECTED] writes: On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: I'd like to know if anyone cares about using these binary signatures Before your mail I was completely unaware of the existence of dpkg-sig. Now that I know it, I care about it and would like to start uploading my packages dpkg-sig-ed (being it possible!). I hope the current setting will be fixed soon and I will fill a whishlist bugreport against debuild to support dpkg-sig side by side with debuild. Cheers. Please file that against debsign which debuild uses. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 02:08:17AM +1000, Anthony Towns wrote: On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote: * Marc Brockschmidt: Today (or last night, whatever), the dak installation on ftp-master was changed to not accept packages that include more than 3 parts, which are usually the binary version and the compressed control and data tarballs. This means that signed binary packages are rejected. This is a pity. I think dpkg-sig is an important step into the right direction: providing more assurances about package integrity to our users. Personally, I think it's cryptographic snake oil, at least in so far as it relates to Debian. I remain interested in seeing any realistic demonstration of how a Debian user could reasonably rely on them for any practical assurance. Are you, perchance, interpreting user in Florian's message a little too strictly? I consider myself a user of Debian, as well as a contributor, and I can see a couple of uses for signed binary packages for my own purposes (as well as uses for Debian itself). Maybe I'm raising a too-long-ago-for-my-recollection flamewar, but I can think of the following scenarios (not all of them strictly-Debian, though). I'd be interested in explanations (or pointers to previous discussions) discrediting them, so I can be properly enlightened. 1) A signature added by the originator of a particular binary package (the buildds, typically, within Debian) could provide some identification of the true origin of a binary package. If a buildd were to be deemed to be compromised, all packages signed with that buildd's key could be turfed and rebuilt. (Note that I'm not suggesting using buildd keys as a this package is OK for the archive check, see my comments below). 2) A signature from dinstall saying this package was installed in the Debian archive would provide a means of automatic assurance of the source of a binary package, when I'm putting together custom CDs or package repos. 3) I can verify the provenance of a particular package in my own custom repos at any time (did that come from Debian? Did someone build it internally? What's going on?) I can kinda-sorta do that if I manually sign each binary package I download verify against the Packages-Release chain with a special came from Debian key, and I can verify the source of the source (heh) package via the dsc signature, but having a complete chain of custody on a binary package seems like a nice thing to have. Maybe that's the snake-oil you speak of, aj -- it gives me the warm fuzzies to be able to look at a long list of signatures and say hmm, that looks secure when it shouldn't making me anywhere near as fuzzy. At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. Is your objection to binary-package signing that it is no better than archive signing, or that it is actively *worse* than per-archive signing (again, if both are done properly, whatever we may define that to mean). One scenario, which initially seems compelling, but which I've since rejected, is that of offline signing of binary packages -- the idea that the archive can be authenticated via signatures applied to packages before they hit the archive. The benefit suggested there is that offline signing is more secure than leaving the Release.gpg private key somewhere it can theoretically be stolen and used to sign bogus release files. The problem is that, in general, no automatic signing key is any more secure than any other. In addition, if (for eg) every buildd had it's own automatic key, and that was sufficient for admission to the archive and for checking archive integrity, that you've got less security because there's N keys, spread across a range of machines, any of which can do the job of letting a package into the archive. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
finding the number of people subscribed to a bug
I know that subscribing to a bug can be done by sending an email to [EMAIL PROTECTED] I would like to know if there is a way to find the number of people subscribed to the bug nnn? This could be useful for eg., to see how important a given bug actually is, how many people are worried by it etc., I looked at http://debui.vlsm.org/Bugs/Developer but that does not give any information regarding this problem. Are there any other relevant links? thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Stefano Zacchiroli [EMAIL PROTECTED] writes: [...] I will fill a whishlist bugreport against debuild to support dpkg-sig side by side with debuild. There is already #247825. #247824 is the wishlist bug for dpkg-buildpackage support. Marc -- BOFH #105:#247824 UPS interrupted the server's power pgpEc4Y7SoQjs.pgp Description: PGP signature
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 10:52:52PM +0100, Marc Haber wrote: On Wed, 23 Nov 2005 12:09:34 -0600 (CST), Adam Heath [EMAIL PROTECTED] wrote: There's been no push. No default. No message saying that it's acceptable and wanted to sign debs. So Debian doesn't care about security. If we did, we would have an official message saying so. Why do we have the reputation of being so secure? It's an elaborate hoax we put together in order to see how you would react when you found out it wasn't true. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
GPG keysigning in Bangalore, India, next month
If any Debian developers or prospective developers would like to have their GPG keys signed, I will probably be in Bangalore next month. The keysigning will probably be at the Bangalore LUG meeting, but other arrangements can be made. Email me. http://linux-bangalore.org/blug/meetings/ Forward this email to anyone you think should see it. I have not joined the BLUG lists because they require a Yahoo account to access them. John -- It's not true unless it makes you laugh, but you don't understand it until it makes you weep. Eukleia: John Walther Address: 5690 Pioneer Ave, Burnaby, BC V5H2X6 (Canada) Contact: 604-430-4973 Website: http://reactor-core.org/ Puritan: Purity of faith, Purity of doctrine Puritan: Sola Scriptura, Tota Scriptura Love is a sharp sword. Hold it by the right end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
* Marc Haber [Wed, 23 Nov 2005 18:38:15 +0100]: I confused these bugs because in the discussion, somebody used #339686 to show that I am doing a job as bad as Mr. Troup. 10:18 dato Zugschlus: so. how'd you'd feel if I said that #339686 was a deliberate attempt on your part to consciously drop support of a perfect ok setup, such as shadow-less systems? bugs happen, period. 10:19 dato in adduser, in mutt, and in ftp-master.debian.org. I'll let others decide whether that was to show that you're doing a bad job with your packages, or an analogy/whatever. I can't even be bothered to ask for an apology. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Man: Wow, that woman looks exactly the way Nina is going to look in about ten years... Oh shit, it is Nina. Don't tell her what I said, okay? -- http://www.overheardinnewyork.com/archives/003086.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Patches for the Debian package are welcome, of course. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
Scripsit Steve Langasek [EMAIL PROTECTED] * Don't use other *-config tools. While many libraries these days use pkg-config, there are also other libs which ship their own tools for querying library and header include paths, libs needed for linking, etc. The problem is that all of these tools I've seen are incapable of distinguishing between what's needed for static linking, and what's needed for dynamic linking. Would you recommend against *shipping* such a script when upstream provides it (in addition to a .pc file)? -- Henning Makholm Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: finding the number of people subscribed to a bug
On Wed, 23 Nov 2005, kamaraju kusumanchi wrote: I know that subscribing to a bug can be done by sending an email to [EMAIL PROTECTED] I would like to know if there is a way to find the number of people subscribed to the bug nnn? This could be useful for eg., to see how important a given bug actually is, how many people are worried by it etc., I looked at http://debui.vlsm.org/Bugs/Developer but that does not give any information regarding this problem. Are there any other relevant links? The current implementation of the bug subscription places the subscription lists on a machine separate from bugs.d.o, so they're not trivially available. In the future, it's possible that the number of subscribers will be exposed... but it's not exactly a high item on the todo list (at least, it's not high on mine.) [Not to mention the fact that the number of subscribers won't necessarily indicate the number of people who are interested in a bug or its importance.] Don Armstrong -- Frankly, if ignoring inane opinions and noisy people and not flaming them to crisp is bad behaviour, I have not yet achieved a state of nirvana. -- Manoj Srivastava in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Stephen Gran wrote: This one time, at band camp, Rafael Laboissiere said: I am moving this discussion to debian-devel, since I am not sure we are really violating the Policy. Feel free to move it further to debian-policy, if you think it is appropriate. FWIW, Rafael, at first blush I have to say I agree with you. A maintainer address in Debian is just a way to get in touch with someone when something goes wrong with the package. If the mailing list is a good way to get in touch with people when those packages break, then it seems like a reasonable maintainer address. AFAIU the changelog entry is supposed to bear the name of the uploader, and thus can't be a mailing list. Policy 4.4 seems to support this: The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. Bastian, what's the rationale for the filings you've been doing? Do you really think a mailing list address, (where any and all correspondence about the packages is presumably archived and possibly even publicly accessible), is somehow worse than mailing a single person (who hopefully archives their package mail, but maybe not, and can almost be guaranteed not to have publicly browseable archives)? What are you hoping to do here? It provides a convenient way to find the person who did the final touches before an upload. The uses you are arguing are covered by the Maintainer: field. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Marc Haber wrote: [snip] How is it possible for you to claim something is more secure when you don't understand it well enough to say how it's different? Well, even if I know naught about it, it looks to me that having something signed is better than having the same something not signed. Sorry, but that's a snake oil rationale. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Marc == Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: Marc Brian May [EMAIL PROTECTED] writes: I've never seen dpkg-sig mentioned before, only debsigs, so I'm not familiar with the tool itself, but the concept is one that needs a lot more exposure. I would speculate debsigs got a name change to dpkg-sig. Can somebody confirm or deny? Marc No. dpkg-sig is a completly independent application (though Marc some ideas were taken from debsigs) So, can I conclude we should use dpkg-sig and not debsigs? The reason I haven't uploaded my packages using something like this is: * last time I tried, it got rejected, I didn't know the situation has changed. * confusion over which system to use. * Not integrated with dpkg-buildpackage, debsign, autobuilders, or dak yet. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: possible freetype transition; improved library handling needed for all C/C++ packages
Re: Steve Langasek in [EMAIL PROTECTED] If you maintain a package that's affected by this issue, you can help today; there's no need to wait until your package is hit by a library transition to make the changes described above. Indeed, for packages which depend on libfreetype6, it's important that we begin fixing these as soon as possible to avoid another multi-month transition. A complete list of packages that are potentially affected by the freetype transition can be found at [6]. [6] http://people.debian.org/~vorlon/freetype-without-builddeps.txt Here's that list again, regenerated today with the command from [6], and piped through dd-list. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ Anibal Avelar (Fixxxer) [EMAIL PROTECTED] idesk Laszlo Boszormenyi (GCS) [EMAIL PROTECTED] xsidplay J.H.M. Dassen (Ray) [EMAIL PROTECTED] pstoedit Masayuki Hatta (mhatta) [EMAIL PROTECTED] abiword Moray Allan [EMAIL PROTECTED] libmatchbox matchbox-desktop matchbox-panel matchbox-window-manager Tore Anderson [EMAIL PROTECTED] obconf openbox Ben Armstrong [EMAIL PROTECTED] came Don Armstrong [EMAIL PROTECTED] libimage-imlib2-perl Enrique Robledo Arnuncio [EMAIL PROTECTED] rosegarden4 Julien BLACHE [EMAIL PROTECTED] gphotocoll Thomas Bushnell, BSG [EMAIL PROTECTED] bonobo gal0.x gnucash gtkhtml Sebastien Bacher [EMAIL PROTECTED] evince gtk+2.0 gtkterm totem Michael Banck [EMAIL PROTECTED] exult Romain Beauxis [EMAIL PROTECTED] kshutdown Bradley Bell [EMAIL PROTECTED] kaptain Jon Bernard [EMAIL PROTECTED] libimlib2-ruby Michael Biebl [EMAIL PROTECTED] kdesvn Eduard Bloch [EMAIL PROTECTED] icewm rxvt-unicode Gonéri Le Bouder [EMAIL PROTECTED] klibido Regis Boudin [EMAIL PROTECTED] tellico Chris Boyle [EMAIL PROTECTED] klogic Rob Bradford [EMAIL PROTECTED] anjuta screem Ben Burton [EMAIL PROTECTED] kdeaddons kdeedu kdesdk kile regina-normal Bruno Barrera C. [EMAIL PROTECTED] bbkeys blackbox Giacomo Catenazzi [EMAIL PROTECTED] knapster2 Zack Cerza [EMAIL PROTECTED] kaffeine Cyril Chaboisseau [EMAIL PROTECTED] qgo Volker Christian [EMAIL PROTECTED] synce-kde Paul Cupis [EMAIL PROTECTED] guarddog guidedog Julien Danjou [EMAIL PROTECTED] telak torsmo Debian Edu Developers debian-edu@lists.debian.org kgeography Debian GCC Maintainers debian-gcc@lists.debian.org gcc-snapshot Debian Install System Team debian-boot@lists.debian.org gtk+2.0-directfb Debian OCaml Maintainers debian-ocaml-maint@lists.debian.org advi Debian OpenOffice Team debian-openoffice@lists.debian.org oooqs Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org kdeadmin kdebase kdebindings kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdepim kdeutils kdewebdev koffice Julien Delange [EMAIL PROTECTED] amule Murat Demirten [EMAIL PROTECTED] sim Eric Dorland [EMAIL PROTECTED] mozilla-firefox Benjamin Drieu [EMAIL PROTECTED] prestimel Peter Eisentraut [EMAIL PROTECTED] kmldonkey rekall Free Ekanayaka [EMAIL PROTECTED] creox Rene Engelhard [EMAIL PROTECTED] kover Peter Van Eynde [EMAIL PROTECTED] cl-gd Helen Faulkner [EMAIL PROTECTED] kaquarium kcpuload kfish knetload labplot Bartosz Fenski [EMAIL PROTECTED] adesklets asc pypanel Fabian Franz [EMAIL PROTECTED] qtparted Hans Fugal [EMAIL PROTECTED] csound Sylvain Le Gall [EMAIL PROTECTED] mldonkey David Moreno Garza [EMAIL PROTECTED] tilda Igor Genibel [EMAIL PROTECTED] kexi Daniel Glassey [EMAIL PROTECTED] bibletime Debian QA Group [EMAIL PROTECTED] gfax kbear ksetisaver ksocrat libgtk-perl mysql-navigator okle windowlab Yu Guanghui [EMAIL PROTECTED] fcitx Francois Gurin [EMAIL PROTECTED] kismet Stefan Gybas [EMAIL PROTECTED] kflog Peter Hawkins [EMAIL PROTECTED] libqt-perl Adam Heath [EMAIL PROTECTED] jmagick Andres Seco Hernandez [EMAIL PROTECTED] swscanner Matt Hope [EMAIL PROTECTED] fluxbox Morten Hustveit [EMAIL PROTECTED] kwavecontrol Mark Hymers [EMAIL PROTECTED] kst Masami Ichikawa [EMAIL PROTECTED] bookmarkbridge Teemu Ikonen [EMAIL PROTECTED] imview Alberto Gonzalez Iniesta [EMAIL PROTECTED] hotswap kmyfirewall Aurelien Jarno [EMAIL PROTECTED] keybled kid3 klineakconfig ksensors ksimus quiteinsane quiteinsanegimpplugin Steffen Joeris [EMAIL PROTECTED] score-reading-trainer Joel Johnson [EMAIL PROTECTED] ktorrent Norman Jordan [EMAIL PROTECTED] kdevelop3 Tomohiro KUBOTA [EMAIL PROTECTED] mlterm Zdenek Kabelac [EMAIL PROTECTED] avifile Theodore Karkoulis [EMAIL PROTECTED] kbarcode kxdocker Jean-Michel Kelbert [EMAIL PROTECTED] k3b karamba kbiff komba2 kuake showimg superkaramba Gerd Knorr [EMAIL PROTECTED] motv xawtv
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: On Thu, 24 Nov 2005, Anthony Towns wrote: Personally, I think it's cryptographic snake oil, at least in so far A signed deb has a seal of procedence and allows one to track the path it made through the system, and who changed it. That's what the .changes file is for. something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. Not in a very useable form, and only for Debian packages uploaded to the official Debian archive. This is hardly good enough. Uh, packages not uploaded to the official Debian archive can do whatever they want. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 12:38:37AM +0100, Goswin von Brederlow wrote: I know this is a contrived use case, but Ubuntu doesn't use any .debs from Debian. One could prove that. :) No, one couldn't -- the signatures could just be removed from the debs, no recompilation needed. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote: 2) A signature from dinstall saying this package was installed in the Debian archive would provide a means of automatic assurance of the source of a binary package, when I'm putting together custom CDs or package repos. You can already use release signatures for this. Further, changing the deb after upload would make it much more difficult to check the deb was what was uploaded -- you can no longer just use md5sum, you've instead got to use special tools. 3) I can verify the provenance of a particular package in my own custom repos at any time (did that come from Debian? Did someone build it internally? What's going on?) I can kinda-sorta do that if I manually sign each binary package I download verify against the Packages-Release chain with a special came from Debian key, and I can verify the source of the source (heh) package via the dsc signature, but having a complete chain of custody on a binary package seems like a nice thing to have. Sure; but why do that inside the .deb? You can verify a detached signature just as easily as an inline one (gpgv sig file // gpgv file), and you can verify a signature of a hash just as easily as a signature of a file. If you're worried you might lose the detached, signed information, either keep it with the data it's authenticating (pool/main/f/foo/foo.origin, eg), or keep good backups, or both. At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. Is your objection to binary-package signing that it is no better than archive signing, or that it is actively *worse* than per-archive signing (again, if both are done properly, whatever we may define that to mean). My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps packages unchanged over too long a period for the keys to be guaranteed secure for the lifetime of a package. Additionally, packages can be authenticated both via Packages.gz files and .changes files, which already exist and are usable. One scenario, which initially seems compelling, but which I've since rejected, is that of offline signing of binary packages -- the idea that the archive can be authenticated via signatures applied to packages before they hit the archive. This is what .changes files are for, and it's useful both for recovering from compromises and in a cvs blame sort of sense. Note that they also give more information than a simple signature on the .deb. Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even being mirrored to merkel properly at the moment. That's not so constructive. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: Use 1: I have this deb in my apt-move mirror and I want to know if it was compromised on yesterdays breakin Boot a clean system with debian keyring and check all deb signatures. Find some don't pass because they were signed with keys that have been removed from the keyring. Use 2: I have this Ubuntu CD and want to know which debs are from debian and which got recompiled Look for all debs that have a deb signature of the debian archive (to be added to dinstall at some point). Never to be added, because it would change the .deb from that which was originally uploaded, for no benefit. Use 3: The debian servers were compromised and the security team takes too long to check the archive for my taste Being a normal user I obviously have no mail archive of all the old changes files laying around so that road is closed. But everyone has a Debian stable CD with keyring. See Use 1. And see why it doesn't work. Not to mention keys added since stable released, and packages uploaded by those maintainers. More than just keys removed from the keyring, there's the issue of keys being compromised -- it's not even unknown for developers to post secret keys to mailing lists -- the issue that a package that's once been in the archive may well by now have known security holes (which is why we have security.debian.org after all), and that this is entirely moot anyway since the vast majority of packages can't be verified by dpkg-sig. buildd.debian.org gives full logs, to developers or users. While the log contains the md5sum of each build deb it does not contain any signature against tampering. No, that's what the signed .changes file is for. Tampered debs can be uploaded by sending a fake mail to the admin and filtering out his responce. A deb signature of the buildd and a subsequent dak check would prevent this. So would having the buildd sign the mails to the buildd admin, which would have the benefit of not giving a couple of dozen completely untrustworthy keys special access to the archive. (AIUI, signed mails to the admin are on the TODO list; at present buildds don't have keys of their own at all) something that provides DD-to-user package signatures at least in some cases is very desirable indeed. debian-devel-changes provides this. That covers only the sourcefull uploads and the arch specific -changes lists are not archived and therefore useless for non constant monitoring. Far easier to fix that, than retrofit 150G of debs to a flawed and redundant scheme like this. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 11:54:33AM +1000, Anthony Towns wrote: On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: On Thu, 24 Nov 2005, Anthony Towns wrote: Personally, I think it's cryptographic snake oil, at least in so far A signed deb has a seal of procedence and allows one to track the path it made through the system, and who changed it. That's what the .changes file is for. Only possible if the .changes file is still accessable, and going through the d-d-c archives isn't exactly convenient. On that score, the description for d-d-c says that it includes buildd logs, but a quick scroll through doesn't appear to find any. Are they sent somewhere else now, or am I just going blind? Certainly, if we're going to be verifying binary packages from the .changes files, we need to have all of the buildd .changes files available in an archive *somewhere*. - Matt signature.asc Description: Digital signature
Evolution 2.4 in Sid
Hi, Where can I go to discover it's status? Thanks -- - Ron Johnson, Jr. Jefferson, LA USA Take a drink, / and you'll sink, / to a state of pure inebriation. / You'll be tanked, like the whole Irish nation. Family Guy, Episode 2ACX15 Wasted Talent, the Pure Inebriation song -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 12:30:37PM +1000, Anthony Towns wrote: On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote: 3) I can verify the provenance of a particular package in my own custom repos at any time (did that come from Debian? Did someone build it internally? What's going on?) I can kinda-sorta do that if I manually sign each binary package I download verify against the Packages-Release chain with a special came from Debian key, and I can verify the source of the source (heh) package via the dsc signature, but having a complete chain of custody on a binary package seems like a nice thing to have. Sure; but why do that inside the .deb? You can verify a detached signature just as easily as an inline one (gpgv sig file // gpgv file), and you can verify a signature of a hash just as easily as a signature of a file. If you're worried you might lose the detached, signed information, either keep it with the data it's authenticating (pool/main/f/foo/foo.origin, eg), or keep good backups, or both. Then there's the opposite argument about why not do that inside the .deb?. On the one hand, if I copy a detached-signed .deb around, I need to remember to copy the .origin file around with it. Conversely, if I use in-file sigs, I can no longer rely on the md5sum of the .deb as originally provided to verify original provenance. I think the final judgment in this issue is going to come down to personal taste and needs more than anything else. At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. That's a good point. However, what damage can be done with a bodgy Packages file, if only well-signed .debs are actually accepted for installation on the system? The only thing that comes to mind is wasting some time and bandwidth on downloading dodgy debs (or their equally-dodgy dependencies), but if the system checks the signatures before installing anything, can anything actually be damaged? Is your objection to binary-package signing that it is no better than archive signing, or that it is actively *worse* than per-archive signing (again, if both are done properly, whatever we may define that to mean). My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps packages unchanged over too long a period for the keys to be guaranteed secure for the lifetime of a package. Additionally, packages can be authenticated both via Packages.gz files and .changes files, which already exist and are usable. Don't the same arguments about key longevity apply to checking the signatures on .changes files, too? One scenario, which initially seems compelling, but which I've since rejected, is that of offline signing of binary packages -- the idea that the archive can be authenticated via signatures applied to packages before they hit the archive. This is what .changes files are for, and it's useful both for recovering from compromises and in a cvs blame sort of sense. Note that they also give more information than a simple signature on the .deb. Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even being mirrored to merkel properly at the moment. That's not so constructive. Is there a publically accessable form of queue/done somewhere that people can download the .changes files from? That would be quite handy for people to use to verify binary packages (and would be a darn sight easier to use than trolling d-d-c archives). - Matt
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote: Then there's the opposite argument about why not do that inside the .deb?. Simple answers: unnecessary bloat, unwarranted feeling of security leading to bad decisions. Whenever anyone asks how do you manage the keys, the answer is usually automatically sign by dinstall which means the deb is modified after it leaves the builders system (invalidating existing authentication methods) and usually means changing the deb after its entered the archive (for signatures identifying packages released as part of sarge / etch, or in the case where an old key expires). I think the final judgment in this issue is going to come down to personal taste and needs more than anything else. That's fine for personal repositories, it's not sufficient for Debian's archive. At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. That's a good point. However, what damage can be done with a bodgy Packages file, if only well-signed .debs are actually accepted for installation on the system? Add a Depends: some-random-package that you know has a security hole to dpkg's entry in the Packages and it'll be automatically installed by apt. Add a Conflicts: dpkg to some package's entry and it'll never be installed by apt or aptitude. You can possibly be trickier by pointing apt at a completely different file too, so that the user thinks they're installing foo, but end up with bar instead only noticing if they see dpkg say Unpacking bar (from .../foo_*.deb). IIRC, it's tricky to make that actually work. The only thing that comes to mind is wasting some time and bandwidth on downloading dodgy debs (or their equally-dodgy dependencies), but if the system checks the signatures before installing anything, can anything actually be damaged? There are plenty of packages signed by developers, or that have been included in the archive, that have exploitable security issues. My objection is that it's *useless* for *Debian*. Debian has too many sources for packages for key management to be plausible, and keeps packages unchanged over too long a period for the keys to be guaranteed secure for the lifetime of a package. Additionally, packages can be authenticated both via Packages.gz files and .changes files, which already exist and are usable. Don't the same arguments about key longevity apply to checking the signatures on .changes files, too? Sure, that's why we don't encourage users to worry about them. The advantage is there's no great difficulty to providing new detached certificates with new signatures, if the need arises. The debs only need to be changed if they're actual content needs to change. (Which is also an advantage for users, who correspondingly don't have to worry about redownloading them) Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even being mirrored to merkel properly at the moment. That's not so constructive. Is there a publically accessable form of queue/done somewhere that people can download the .changes files from? No, there isn't anything, apparently the mirroring to merkel got disabled due to the inode usage / rsync time. There's some 700k odd changes files. I think the theory is they'll start getting regularly tar.bz2'ed up and made available with an index file. That would be quite handy for people to use to verify binary packages (and would be a darn sight easier to use than trolling d-d-c archives). No lie. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, 24 Nov 2005 11:54:33 +1000, Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: Not in a very useable form, and only for Debian packages uploaded to the official Debian archive. This is hardly good enough. Uh, packages not uploaded to the official Debian archive can do whatever they want. It would, however, be convenient to be able to upload a package to Debian and to be able to use the same package for different things. Allowing things like these is what makes it possible for some people to work for Debian during their paid time. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: I am still on the keyring. With my old key.
Marc Haber [EMAIL PROTECTED] writes: What are you trying to do instead? If you might have noticed, we have _just_ _another_ ftpmaster situation _right_ _now_, and from handling of #339686 by a member of the DPL team I don't get the impression that the DPL team actually cares. I can't understand what you're referring to here. You are perhaps assuming that we all have context you haven't explained? Bug 339686 was reported with severity important and a patch, and then upgraded to serious by the maintainer, and then closed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Marc Haber [EMAIL PROTECTED] writes: According to the reports of another member of the ftp-master team, the situation was cleared up, but Mr. Troup re-enabled the check that breaks dpkg-sig on purpose after not being amused about HE's rant on here. If this is accurate, it is not reasonable. If HE went and shot Troup's dog, that wouldn't be an excuse for changing the ftp archive behavior. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ssl/crypto
libgnutls-dev is a suitable substitute for libssl-dev when one wants libssl. However, libssl-dev provides *two* libraries; the other is libcrypto. Is there a GPL-compatible replacement for the latter? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 03:48:15PM +1000, Anthony Towns wrote: On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote: I think the final judgment in this issue is going to come down to personal taste and needs more than anything else. That's fine for personal repositories, it's not sufficient for Debian's archive. Well, I think that personal taste is sufficient for Debian's archive, and it seems obvious that Those In The Know have decided that they prefer one taste over another. grin At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. That's a good point. However, what damage can be done with a bodgy Packages file, if only well-signed .debs are actually accepted for installation on the system? Add a Depends: some-random-package that you know has a security hole to dpkg's entry in the Packages and it'll be automatically installed by apt. You're a lot more devious than I am, AJ, as I'd never considered these possibilities. Hrm, I see queue/done (which contains .changes files going back to the dark ages) isn't even being mirrored to merkel properly at the moment. That's not so constructive. Is there a publically accessable form of queue/done somewhere that people can download the .changes files from? No, there isn't anything, apparently the mirroring to merkel got disabled due to the inode usage / rsync time. There's some 700k odd changes files. Ouch. rsync must be *loving* those. - Matt signature.asc Description: Digital signature
Re: ssl/crypto
On Wed, Nov 23, 2005 at 11:43:27PM -0800, Thomas Bushnell BSG wrote: libgnutls-dev is a suitable substitute for libssl-dev when one wants libssl. However, libssl-dev provides *two* libraries; the other is libcrypto. Is there a GPL-compatible replacement for the latter? libgcrypt -- separate source package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Accepted manpages 2.10-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Nov 2005 08:33:40 +0100 Source: manpages Binary: manpages manpages-dev Architecture: source all Version: 2.10-1 Distribution: unstable Urgency: low Maintainer: Martin Schulze [EMAIL PROTECTED] Changed-By: Martin Schulze [EMAIL PROTECTED] Description: manpages - Manual pages about using a GNU/Linux system manpages-dev - Manual pages about using GNU/Linux for development Changes: manpages (2.10-1) unstable; urgency=low . * New upstream release, with the only cosmetical changes Files: 0ba1e130600b15ce80028e315b6103d2 584 doc - manpages_2.10-1.dsc 75c4a273a878cadee88bd7a0a72ee6f5 1058326 doc - manpages_2.10.orig.tar.gz 4ff8155ca248a09b14f473d4adf48a02 44884 doc - manpages_2.10-1.diff.gz eabad30ed89170e7ae18bda6b27b63f1 405390 doc important manpages_2.10-1_all.deb 1ba97e03e9b3ea82cb93052e8b945d60 1104744 doc standard manpages-dev_2.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhB7NW5ql+IAeqTIRAkumAJ9pzI1fKOVLbU6DCIZ5zbNXglksBACgokYX eyZaA04JklrbVSS21rnNKJg= =uRhD -END PGP SIGNATURE- Accepted: manpages-dev_2.10-1_all.deb to pool/main/m/manpages/manpages-dev_2.10-1_all.deb manpages_2.10-1.diff.gz to pool/main/m/manpages/manpages_2.10-1.diff.gz manpages_2.10-1.dsc to pool/main/m/manpages/manpages_2.10-1.dsc manpages_2.10-1_all.deb to pool/main/m/manpages/manpages_2.10-1_all.deb manpages_2.10.orig.tar.gz to pool/main/m/manpages/manpages_2.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openoffice.org-help 2.0.0-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Nov 2005 13:48:25 +0100 Source: openoffice.org-help Binary: openoffice.org-help-cs openoffice.org-help-zh-tw openoffice.org-help-ko openoffice.org-help-es openoffice.org-help-de openoffice.org-help-it openoffice.org-help-zh-cn openoffice.org-help-sv openoffice.org-help-pt-br openoffice.org-help-ja openoffice.org-help-en-us openoffice.org-help-fr Architecture: source all Version: 2.0.0-3 Distribution: unstable Urgency: low Maintainer: Debian OpenOffice Team debian-openoffice@lists.debian.org Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: openoffice.org-help-cs - Czech help for OpenOffice.org openoffice.org-help-de - German help for OpenOffice.org openoffice.org-help-en-us - English_american help for OpenOffice.org openoffice.org-help-es - Spanish help for OpenOffice.org openoffice.org-help-fr - French help for OpenOffice.org openoffice.org-help-it - Italian help for OpenOffice.org openoffice.org-help-ja - Japanese help for OpenOffice.org openoffice.org-help-ko - Korean help for OpenOffice.org openoffice.org-help-pt-br - Portuguese_brazilian help for OpenOffice.org openoffice.org-help-sv - Swedish help for OpenOffice.org openoffice.org-help-zh-cn - Chinese_simplified help for OpenOffice.org openoffice.org-help-zh-tw - Chinese_traditional help for OpenOffice.org Closes: 340269 Changes: openoffice.org-help (2.0.0-3) unstable; urgency=low . * install zh-CN help in .../help-CN instead of .../help-cn. Analogous with zh-TW and pt_BR (closes: #340269) * some minor beautification in debian/rules (don't duplicate tr calls) Files: 61bf78a9679495b9ed26eeb43a3966b4 1279 contrib/doc optional openoffice.org-help_2.0.0-3.dsc 0c7cad1d47f098ab8fb0fedc20cf2ae9 2750 contrib/doc optional openoffice.org-help_2.0.0-3.diff.gz 9389b43113b735fa032d3cee73b7e32c 10923318 contrib/doc optional openoffice.org-help-en-us_2.0.0-3_all.deb 8d0e374b8f4e78eecc8bc2c015d35c09 11489490 contrib/doc optional openoffice.org-help-cs_2.0.0-3_all.deb 64835e4d5a2bf98f5ee658c5d99e06ac 12316428 contrib/doc optional openoffice.org-help-de_2.0.0-3_all.deb 0178d60e559d5ca52be09eea651c1d9e 11730252 contrib/doc optional openoffice.org-help-es_2.0.0-3_all.deb 5a067d95adc0fc9e414388c305bdf58c 11942538 contrib/doc optional openoffice.org-help-fr_2.0.0-3_all.deb e654d8514ba575e53c29d08823cfc520 11743590 contrib/doc optional openoffice.org-help-it_2.0.0-3_all.deb df21fa2f3c9acc2fe9bf2bebac4425c1 12369260 contrib/doc optional openoffice.org-help-ja_2.0.0-3_all.deb 682bf409b4bdf83fb69e940729bf7d8b 11523010 contrib/doc optional openoffice.org-help-ko_2.0.0-3_all.deb bc0d85ddf43f505e871580864303a64a 11654956 contrib/doc optional openoffice.org-help-pt-br_2.0.0-3_all.deb 5b49e576f8f716a797af3ab6e35e1dc4 11450410 contrib/doc optional openoffice.org-help-sv_2.0.0-3_all.deb 38e0c96300c86a043654a2e78bcc16fd 11649792 contrib/doc optional openoffice.org-help-zh-cn_2.0.0-3_all.deb a6446f59d7013b2262ce0108d1ea82fb 11857778 contrib/doc optional openoffice.org-help-zh-tw_2.0.0-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDg6Zw+FmQsCSK63MRAlnZAJ41ZqoabCTGK/AiYJ76hjJB9idEEwCfW53E F5rvPzROpLJRERT4AqPiXuU= =1N6R -END PGP SIGNATURE- Accepted: openoffice.org-help-cs_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-cs_2.0.0-3_all.deb openoffice.org-help-de_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-de_2.0.0-3_all.deb openoffice.org-help-en-us_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-en-us_2.0.0-3_all.deb openoffice.org-help-es_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-es_2.0.0-3_all.deb openoffice.org-help-fr_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-fr_2.0.0-3_all.deb openoffice.org-help-it_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-it_2.0.0-3_all.deb openoffice.org-help-ja_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-ja_2.0.0-3_all.deb openoffice.org-help-ko_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-ko_2.0.0-3_all.deb openoffice.org-help-pt-br_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-pt-br_2.0.0-3_all.deb openoffice.org-help-sv_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-sv_2.0.0-3_all.deb openoffice.org-help-zh-cn_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-zh-cn_2.0.0-3_all.deb openoffice.org-help-zh-tw_2.0.0-3_all.deb to pool/contrib/o/openoffice.org-help/openoffice.org-help-zh-tw_2.0.0-3_all.deb openoffice.org-help_2.0.0-3.diff.gz to pool/contrib/o/openoffice.org-help/openoffice.org-help_2.0.0-3.diff.gz openoffice.org-help_2.0.0-3.dsc to pool/contrib/o/openoffice.org-help/openoffice.org-help_2.0.0-3.dsc -- To UNSUBSCRIBE,
Accepted squidguard 1.2.0-6 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 17 Aug 2005 22:23:56 +0200 Source: squidguard Binary: squidguard Architecture: source i386 Version: 1.2.0-6 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Stefan Fritsch [EMAIL PROTECTED] Description: squidguard - filter, redirector and access controller plug for Squid Closes: 234076 280040 293185 295243 318707 Changes: squidguard (1.2.0-6) unstable; urgency=low . * QA Upload * Add translation of the debconf templates: - German (thanks to Erik Schanze, closes: #280040) - Vietnamese (thanks to Clytie Siddall, closes: #318707) - Czech (thanks to Miroslav Kure, closes: #295243) - Japanese (thanks to Hideki Yamane, closes: #234076) * Use DB4.3 (Closes: #293185) * Bump Standards-Version (no changes needed) * Make time part in timespace declarations optional (Closes #312433) * Remove some cruft from debian-diff Files: 23a7ca25661518c1b7acd0b7948829d4 626 web optional squidguard_1.2.0-6.dsc 8c7144ad0ba5a3fba3e514a82021422c 91336 web optional squidguard_1.2.0-6.diff.gz a55f5781629bcaa2d117c406c5e75b52 135200 web optional squidguard_1.2.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhCU9KN6ufymYLloRAsduAKCkdDQQHpq6U29n4of+pALw5J7eLgCfbXHm WAkVecJufu43NUCcPLPe3no= =EA0x -END PGP SIGNATURE- Accepted: squidguard_1.2.0-6.diff.gz to pool/main/s/squidguard/squidguard_1.2.0-6.diff.gz squidguard_1.2.0-6.dsc to pool/main/s/squidguard/squidguard_1.2.0-6.dsc squidguard_1.2.0-6_i386.deb to pool/main/s/squidguard/squidguard_1.2.0-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted caudium 2:1.4.7-8 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 19 Nov 2005 01:29:41 +0100 Source: caudium Binary: caudium-ultralog caudium-pixsl caudium-perl caudium caudium-dev caudium-modules Architecture: source i386 Version: 2:1.4.7-8 Distribution: unstable Urgency: low Maintainer: Marek Habersack [EMAIL PROTECTED] Changed-By: Marek Habersack [EMAIL PROTECTED] Description: caudium- An extensible WWW server written in Pike caudium-dev - Development files for Caudium caudium-modules - C modules for Caudium caudium-perl - Perl script support for Caudium caudium-pixsl - Pike XSLT module for Caudium caudium-ultralog - Log Parser module for Caudium Changes: caudium (2:1.4.7-8) unstable; urgency=low . * Build-depends on Pike 7.6.51 now Files: 6690f5f526bbbd0986adb51f9a2ba4fb 846 web optional caudium_1.4.7-8.dsc cbb13aa4f9546b29ecd3d3eca4a56841 82830 web optional caudium_1.4.7-8.diff.gz ce7599bdeee6f3a383a3e4a92bd60754 4536774 web optional caudium_1.4.7-8_i386.deb 35b6b66fab8bf7d15c80ee5bb4b94372 57704 web optional caudium-modules_1.4.7-8_i386.deb 7ca20f9129b97495ef04ccc128da99b0 38976 web optional caudium-pixsl_1.4.7-8_i386.deb 638af8bd0aa789ac5246454a63b4e86e 73468 web optional caudium-ultralog_1.4.7-8_i386.deb 8f71d159a4bb530810421c056d3c1f0a 23418 devel optional caudium-dev_1.4.7-8_i386.deb 88a0ac1b25d5dbd0e3ad2c5820ad8111 31690 web optional caudium-perl_1.4.7-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhCzIq3909GIf5uoRAowRAJ90w0+zqEQFHWso62mEwybfPBWH+QCdH3n9 2f+fqcN3e6ololmV5JpUnTk= =/S3U -END PGP SIGNATURE- Accepted: caudium-dev_1.4.7-8_i386.deb to pool/main/c/caudium/caudium-dev_1.4.7-8_i386.deb caudium-modules_1.4.7-8_i386.deb to pool/main/c/caudium/caudium-modules_1.4.7-8_i386.deb caudium-perl_1.4.7-8_i386.deb to pool/main/c/caudium/caudium-perl_1.4.7-8_i386.deb caudium-pixsl_1.4.7-8_i386.deb to pool/main/c/caudium/caudium-pixsl_1.4.7-8_i386.deb caudium-ultralog_1.4.7-8_i386.deb to pool/main/c/caudium/caudium-ultralog_1.4.7-8_i386.deb caudium_1.4.7-8.diff.gz to pool/main/c/caudium/caudium_1.4.7-8.diff.gz caudium_1.4.7-8.dsc to pool/main/c/caudium/caudium_1.4.7-8.dsc caudium_1.4.7-8_i386.deb to pool/main/c/caudium/caudium_1.4.7-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted slgtk 0.5.15.r4-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Nov 2005 09:28:48 +0100 Source: slgtk Binary: slang-gtk Architecture: source i386 Version: 0.5.15.r4-3 Distribution: unstable Urgency: low Maintainer: Debian JED Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: slang-gtk - binds the GIMP Toolkit (GTK) to the S-Lang scripting language Closes: 340276 Changes: slgtk (0.5.15.r4-3) unstable; urgency=low . +++ Changes by Rafael Laboissiere . * debian/control: - Added xbase-clients to Build-Depnends, such that the xauth command is found and the package does not FTBFS (closes: #340276) - Added my e-mail address ([EMAIL PROTECTED]) to the Uploaders list Files: 557b7261229966f8017069ad838c0939 748 interpreters optional slgtk_0.5.15.r4-3.dsc 13304342124891ef2fad90c6da9117a0 4882 interpreters optional slgtk_0.5.15.r4-3.diff.gz fd75812b37627e600ed341df96d3a1f0 506048 interpreters optional slang-gtk_0.5.15.r4-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDhC9Lk3oga0pdcv4RAtRHAJ9uox4IQXDpNmgZ1gY56DdeKV3FYACeKZGh 1OaZb1ZgUHTxZ1YfJSyscVo= =7yo0 -END PGP SIGNATURE- Accepted: slang-gtk_0.5.15.r4-3_i386.deb to pool/main/s/slgtk/slang-gtk_0.5.15.r4-3_i386.deb slgtk_0.5.15.r4-3.diff.gz to pool/main/s/slgtk/slgtk_0.5.15.r4-3.diff.gz slgtk_0.5.15.r4-3.dsc to pool/main/s/slgtk/slgtk_0.5.15.r4-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted festival-it 1.0-10 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Nov 2005 11:54:18 +0100 Source: festival-it Binary: festvox-italp16k festlex-ifd festvox-itapc16k Architecture: source all Version: 1.0-10 Distribution: unstable Urgency: low Maintainer: Debian Italian Maintainers Task Force [EMAIL PROTECTED] Changed-By: Enrico Zini [EMAIL PROTECTED] Description: festlex-ifd - Italian support for Festival festvox-italp16k - Italian female speaker for Festival festvox-itapc16k - Italian male speaker for Festival Closes: 339107 Changes: festival-it (1.0-10) unstable; urgency=low . [ Riccardo Vestrini ] * Removed build-depends on build-essential. Closes: #339107 * Deleted debian/control.in. . [ Enrico Zini ] * Updated README.Debian to explain better how to patch festival while #335845 is open, and how to recode the input to latin1. Files: 10e4080e2d2751602b911a47cf70481d 1126 sound optional festival-it_1.0-10.dsc daaf2801a10f9991e80dd598c46e19d4 4090 sound optional festival-it_1.0-10.diff.gz 2685c83eed6844f5c372eb3b611291ea 3330162 sound optional festlex-ifd_1.0-10_all.deb addd0b55582e6d1074e2e793fcc2a620 4167998 sound optional festvox-itapc16k_1.0-10_all.deb 779d4247d42e585718da18c38a9fc3e1 4831206 sound optional festvox-italp16k_1.0-10_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhDIq9LSwzHl+v6sRAiHWAKCBhXJ1bFGQwHGAmzAI2oIC+xWGBgCcDqS0 NkTWP+Fopy/gLxMRtWvgbDk= =rqpS -END PGP SIGNATURE- Accepted: festival-it_1.0-10.diff.gz to pool/main/f/festival-it/festival-it_1.0-10.diff.gz festival-it_1.0-10.dsc to pool/main/f/festival-it/festival-it_1.0-10.dsc festlex-ifd_1.0-10_all.deb to pool/main/f/festival-it/festlex-ifd_1.0-10_all.deb festvox-italp16k_1.0-10_all.deb to pool/main/f/festival-it/festvox-italp16k_1.0-10_all.deb festvox-itapc16k_1.0-10_all.deb to pool/main/f/festival-it/festvox-itapc16k_1.0-10_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bookmarks 1.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Nov 2005 14:17:07 +0100 Source: bookmarks Binary: bookmarks Architecture: all source Version: 1.2 Distribution: unstable Urgency: low Maintainer: Tobias Toedter [EMAIL PROTECTED] Changed-By: Tobias Toedter [EMAIL PROTECTED] Description: bookmarks - Debian bookmark collection Changes: bookmarks (1.2) unstable; urgency=low . * Updated Standards-Version to 3.6.2, no changes needed * New section Desktop Environments for KDE and GNOME. This closes the bug #301105 on alioth. * Removed the script bookmarks-convert: - Removed the file README.OLD, which documented only bookmarks-convert - Removed paragraph from README.Debian which states that the script will be removed - Rephrased the package description with regard to the provided script * Applied some suggestions from the feature request #301106 on alioth: - Added DistroWatch.com to section Distributions - Removed localized Debian mirror from country specific pages * Added Pablo Perez Benitez to the THANKS file * Cleaned up debian/rules (removed some unnecessary calls and targets) * Some additions, updates, and removals of existing links * Added complete color definitions to the CSS file * Moved xbel2bookmarks from /usr/bin to /usr/share/bookmarks/scripts, because it's intended to be used internally only. In consequence, the man page has been removed and the help text was included in the program. * Don't ship the /usr/bin and /usr/share/man/man1 dirs anymore * Added the homepage URL to the description * Removed the dependency on targets build and install from the target binary-arch Files: 0159b1b6a5ebb3d66dcd21cbcb007604 202028 web optional bookmarks_1.2_all.deb 8026c70c5677ba51aab75f90a57d5954 505 web optional bookmarks_1.2.dsc eca2c6ce7a5ff318fe52b4fa0b4ec961 40559 web optional bookmarks_1.2.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDg7hBwmyXkG1Pxm8RAgoXAJ9Se4PDuKz3Q1uVniwuOtZCW9BquwCfcpQc 9BtAujivm2ecXmqGOGSy2vU= =Tu+O -END PGP SIGNATURE- Accepted: bookmarks_1.2.dsc to pool/main/b/bookmarks/bookmarks_1.2.dsc bookmarks_1.2.tar.gz to pool/main/b/bookmarks/bookmarks_1.2.tar.gz bookmarks_1.2_all.deb to pool/main/b/bookmarks/bookmarks_1.2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
