Warning generated by Panda GateDefender Performa.
16/05/2008 11:10:57 [GMT+0200] Malware has been found in a message that included your e-mail address as the sender of the message! Check if your computer is infected. Hacking tool found: Exploit/iFrame File name: message_attachment3 Sender: debian-devel-italian@lists.debian.org Recipients: [EMAIL PROTECTED] CC: Subject: [Spam detected by Panda G.D.] - Mail Delivery (failure [EMAIL PROTECTED]) Source IP address: 85.94.179.145 -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto unsubscribe. Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
On Thu, May 15, 2008 at 11:30:40PM +0200, Peter Palfrader wrote: On Thu, 15 May 2008, Norbert Preining wrote: On Do, 15 Mai 2008, Mike Hommey wrote: I beg to differ. This particular mail is important enough to be sent to d-d-a instead of d-i-a. I agree, dia is not what I would be subscribed to under normal circumstances, and with all the caos that type of announce is for dda. Which is why the initial mail about the issue went to both. If you read the first mail you will know where to find the rest. If you can't be bothered to read carefully when asked to (and lots can't) then I cannot help you. Asking to (temporarily) subscribe to another list to get the one important mail everyone cares about is not the proper way to do things IMHO. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for May 16, 2008
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 433 (new: 6) Total number of packages offered up for adoption: 104 (new: 6) Total number of packages requested help for: 46 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: harminv (#481035), orphaned 2 days ago Reverse Depends: harminv libharminv-dev libmeep-mpi1 libmeep1 meep meep-mpi Installations reported by Popcon: 69 libctl (#481039), orphaned 2 days ago Reverse Depends: libctl-dev meep meep-mpi mpb mpb-mpi Installations reported by Popcon: 80 meep (#481042), orphaned 2 days ago Reverse Depends: libmeep-dev libmeep-mpi-dev meep meep-mpi Installations reported by Popcon: 27 mpb (#481040), orphaned 2 days ago Reverse Depends: mpb-mpi Installations reported by Popcon: 37 sdcv (#480557), orphaned 5 days ago Description: StarDict Console Version Reverse Depends: stardict-english-czech Installations reported by Popcon: 119 shunit2 (#480558), orphaned 5 days ago Description: A unit test framework for Bourne based shell scripts Installations reported by Popcon: 27 427 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: gpsim-doc (#480466), offered 5 days ago Description: Documentation for gpsim Installations reported by Popcon: 117 gpsim-lcd (#480467), offered 5 days ago Description: LCD module for gpsim Installations reported by Popcon: 205 gpsim-lcd-graphic (#480470), offered 5 days ago Description: LCD module for gpsim Installations reported by Popcon: 155 gpsim-led (#480468), offered 5 days ago Description: LED module for gpsim Installations reported by Popcon: 202 gpsim-logic (#480471), offered 5 days ago Description: logic module for gpsim Installations reported by Popcon: 327 ktechlab (#480465), offered 5 days ago Description: circuit simulator for microcontrollers and electronics Installations reported by Popcon: 553 98 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#470795), requested 63 days ago Description: Co-maintainer wanted Reverse Depends: adzapper ampache apache2 apache2-dbg apache2-mpm-event apache2-mpm-itk apache2-mpm-perchild apache2-mpm-prefork apache2-mpm-worker apache2-prefork-dev (150 more omitted) Installations reported by Popcon: 38499 apt-build (#365427), requested 747 days ago Description: Need new developer(s) Installations reported by Popcon: 1025 ara (#450876), requested 186 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 131 athcool (#278442), requested 1297 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 265 bash-completion (#472468), requested 52 days ago Description: programmable completion for the bash shell Installations reported by Popcon: 6417 cfs (#458061), requested 139 days ago Description: Cryptographic Filesystem Installations reported by Popcon: 122 cvs (#354176), requested 812 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more omitted) Installations reported by Popcon: 24057 dctrl-tools (#448284), requested 201 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies dlocate feta haskell-devscripts hg-buildpackage mlmmj sbuild simple-cdd Installations reported by Popcon: 8174 dpkg (#282283), requested 1272 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc build-essential bzr-builddeb clamsmtp crosshurd (103 more omitted) Installations reported by Popcon: 78784 drscheme (#402589), requested 521 days ago Description: PLT scheme programming environment Reverse Depends: drscheme minlog proofgeneral-minlog Installations reported by Popcon: 408 elvis (#432298), requested 311 days ago Description: powerful clone of the vi/ex text
Re: Sorting out mail-transport-agent mess
On Thu, 15 May 2008, Steve Langasek wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. +1 from me. I have also seen this precise suggestion been made on an Ubuntu list as well since they have postfix as default MTA. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
On Do, 15 Mai 2008, Peter Palfrader wrote: I beg to differ. This particular mail is important enough to be sent to d-d-a instead of d-i-a. I agree, dia is not what I would be subscribed to under normal circumstances, and with all the caos that type of announce is for dda. Which is why the initial mail about the issue went to both. If you read the first mail you will know where to find the rest. If you can't be bothered to read carefully when asked to (and lots can't) then I cannot help you. Come on, should I now subscribe to dia only for one (1!!) email (or maybe 2) which are of general interest?? I did read the email, I saw the remark, and assumed that that was an oversight ... my failure. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- NANHORON (n. medical) A tiny valve concealed in the inner ear which enables a deaf grandmother to converse quite normally when she feels like it, but which excludes completely anything that sounds like a request to help with laying the table. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssh-blacklist for !Debian
On Thu, May 15, 2008 at 03:19:55PM +1200, Martin Langhoff wrote: I am looking at hosts that are runing other linuxen that may have weak keys now, or see those weak keys uploaded inadvertently in the future. Is there a straightforward way to get hosts that are !(Debian|Ubuntu) to use that blacklist? PermitBlacklistedKeys support in openssh-server seems to be a Debian/Ubuntu patch (and can't even find a mention of it in the changelog). I've uploaded the necessary patch to http://people.debian.org/~cjwatson/openssh-blacklist.diff. (I've also sent an earlier version of it upstream, but this is all very recent so don't expect it to be in any releases yet!) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Eugeniy Meshcheryakov, 2008-05-16 02:10:39 +0200 : This can happen if user has 'default-mta' package installed, and it changes (if it is done like with 'gcc' package now). Unless default-mta Depends: exim4 | mail-transport-agent. But that's a bit ugly. Roland. -- Roland Mas Fate always wins... At least, when people stick to the rules. -- in Interesting Times (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Thu, May 15, 2008 at 04:45:19PM -0700, Steve Langasek wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. AOL -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Sorting out mail-transport-agent mess
Steve Langasek [EMAIL PROTECTED] writes: On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote: Noticing among others this bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322751 and observing the many packages depending on $MTA | mail-transport-agent with $MTA having values like postfix, exim, exim4, sendmail, nullmailer and probably others. And some packages just depending on mail-transport-agent without providing a preferred. The latter, just depending on mail-transport-agent, makes apt, at least currently, pick the package first in the alphabet providing m-t-a. (A bit ago, this was courier. now it is citadel). This definately needs fixing, but why not sort everything out while we are at it? I think something needs to be done somewhere. There is several solutions, among others the following: 1) Exim4 is currently the default installed MTA. So any package requiring a MTA should depend on exim4 | mail-transport-agent. Defined by policy and all packages should be fixed to this. 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. Anthony Towns did mention (WRT the inet-superserver virtual package) before the release of etch that there was some ongoing work to do something to specify the default for virtual packages globally (i.e. not needing an alternative dep in each and every package depending on a virtual package). This would make updating the defaults and writing the dependencies much simpler, and reduce any inconsistency between the alternative deps in each package. Does anyone know if there was any progress made on this in the meantime? At that time I did suggest creating a single package (virtual-defaults IIRC) which I prototyped. This implemented defaults for all packages, including the default-mta package (by a slightly different name), but the idea was rejected because (IIRC) of the untidiness of leaving a dummy package around when the reverse deps were removed. http://lists.debian.org/debian-devel/2006/09/msg00735.html (I can't see the replies in the archive, though.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpbPNeXT9wWD.pgp Description: PGP signature
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
Peter Palfrader skrev: On Thu, 15 May 2008, Norbert Preining wrote: On Do, 15 Mai 2008, Mike Hommey wrote: I beg to differ. This particular mail is important enough to be sent to d-d-a instead of d-i-a. I agree, dia is not what I would be subscribed to under normal circumstances, and with all the caos that type of announce is for dda. Which is why the initial mail about the issue went to both. If you read the first mail you will know where to find the rest. If you can't be bothered to read carefully when asked to (and lots can't) then I cannot help you. Yes you can, by resending these mails of general interest to d-d-a. DDs are required to subscribe to d-d-a and read it to keep informed. I don't recall a requirement to subscribe to d-i-a, the Developer's Reference doesn't even mention it. If you want all DDs to be aware of something, send stuff to d-d-a. (I did read that the initial mail said to look to d-i-a, but in that case, I'd rather miss your posts there, and get the information from IRC or something instead, than actually subscribing to yet another ML I don't really feel I need to add to my already way too many mailfolders.) Or, I suppose, you could send an URL to d-i-a's archived post to d-d-a, that might be enough for those who don't have that much interest in d-i-a (including me). (But then again, if you do that, you could as well include the whole post...) Perhaps someone should do that for everyone's benefit? Maybe even me, a relatively peripheral DD? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1571-1] Heimdal
On Thu, May 15, 2008 at 07:53:21AM -0700, Russ Allbery wrote: Guido Günther [EMAIL PROTECTED] writes: On Thu, May 15, 2008 at 03:33:41PM +1000, Brian May wrote: Apparently, Heimdal in Debian also is affected. I am not aware of any solution other then to manually regenerate all keys. Could you give some details here? Password based principals aren't affected? Password-based principals are not affected. No randomness is used in generating those keys; the secure material is the password itself, which is run through a hash algorithm. Only randomly generated keys (generally the keys you put into keytabs, but also randomized user principals if you have any) are affected. O.k., that's what I thought. For those using a keytabs ktutil -k keytab change; ktutil -k purge --age=short is sufficient? That looks right to me, although take that with a grain of salt since I use MIT personally and am not that familiar with the Heimdal ktutil command syntax. Just for completeness: Heimdal also generates these by default: kadmin/admin kadmin/hprop kadmin/changepw changepw/kerberos krbtgt/YOUREALM.FOO If I understand things correctly these must be updated too although they don't necessarily correspond to an exported keytab. This can be done using cpw -r principal within kadmin. Thanks again for the explanation. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481450: ITP: libbiblio-endnotestyle-perl -- Reference formatting using Endnote-like templates
Package: wnpp Severity: wishlist Owner: Vincent Danjean [EMAIL PROTECTED] * Package name: libbiblio-endnotestyle-perl Version : 0.05 Upstream Author : Mike Taylor [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Biblio-EndnoteStyle/ * License : perl (GPL/Artistic) Programming Lang: Perl Description : Reference formatting using Endnote-like templates This small module provides a way of formatting bibliographic references using style templates similar to those used by the popular reference management software Endnote (http://www.endnote.com/). The API is embarrassingly simple: a formatter object is made using the class's constructor, the new() method; format() may then be repeatedly called on this object, using the same or different templates. . (The sole purpose of the object is to cache compiled templates so that multiple format() invocations are more efficient than they would otherwise be. Apart from that, the API might just as well have been a single function.) [This module is needed for koha] -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org/password.html : Why ~/.ssh/id_dsa.pub to setup OpenSSH for RSA
On Fri, May 16, 2008 at 08:41:25AM +0200, Norbert Preining wrote: On Do, 15 Mai 2008, Peter Palfrader wrote: I beg to differ. This particular mail is important enough to be sent to d-d-a instead of d-i-a. I agree, dia is not what I would be subscribed to under normal circumstances, and with all the caos that type of announce is for dda. Which is why the initial mail about the issue went to both. If you read the first mail you will know where to find the rest. If you can't be bothered to read carefully when asked to (and lots can't) then I cannot help you. Come on, should I now subscribe to dia only for one (1!!) email (or maybe 2) which are of general interest?? No. If you are expecting something on the list but do not want to subscribe, the list archives are always available: http://lists.debian.org/debian-infrastructure-announce Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#481471: ITP: octave-tsa -- time series analysis in Octave
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] * Package name: octave-tsa Version : 3.10.6 Upstream Author : Alois Schlögl * URL : http://octave.sourceforge.net/tsa/index.html * License : GPL2+ Programming Lang: Octave Description : time series analysis in Octave The TSA toolbox for Octave is useful for analyzing (uni- and multivariate, stationary and non-stationary) Time Series. An Introductory tour to Time Series Analysis and the Download site can be found here. It can be used for: 1. stochastic signal processing 2. autoregressive model identification 3. matched (inverse) filter design 4. Histogram analysis 5. Calcution of the entropy of a timeseries 6. Non-linear analysis (3rd order statistics) 7. smoothing, prediction, filtering 8. Test for Hurwitz and Unit-Circle Polynomials 9. handles missing values (NaN's) Several criteria (AIC, BIC, FPE, MDL, SBC, CAT, PHI) for the selection of the order of an autoregressivemodel are included. Furthermore includes the toolbox a fast version ifthe Yule-Walker method for estimating Autoregressive parameters, the AutocovarianceFunction (ACovF), Autocorrelation Function (ACF), Partial ACF (PACF),andsome other useful staff. Demo programs can be started with demo or demotsa. Version 2.40 (and higher) provides fast algorithms for testing polynomials; and many functions (e.g. ACovF and the Levinson-Durbin algorithms) are implemented for multiple series. This package will be maintained by the DOG (Debian Octave Group) and will soon appear in the SVN repository at Alioth [1]. [1] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/octave-tsa -- Rafael Laboissiere, on behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? Speaking only for myself, let me comment on some extensive patching. I guess that some of my physics-related packages (cernlib, paw) are among the more heavily patched in Debian. Unfortunately upstream is dead, so there is *no way* to see the patches incorporated there. As other have already pointed out: In this case, it should be considered a fork. And even before they gave up the ghost, they were very conservative, refusing to consider most patches more complicated than trivial changes to fix complete breakage. Open source development does work well only if splitting up the development in different branches or even forks is strongly avoided and done only if it is strictly necessary. IMHO the Debian way of doing things makes it far too easy for package maintainers to diverge from the upstream source. I can't really comment on the examples you have provided, but in general, I feel that Debian has not found the right balance here. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acpid package needs love and an active maintainer
Hello Raphael, Unfortunately I had some personal problems that I was not best to keep this package. I agree with you, if I can not keep then not caught. I am putting the package up for adoption. In respect of other packages I will be updating them. Regards, Jose Carlos 2008/5/15 Raphael Hertzog [EMAIL PROTECTED]: Hello, I just reassigned a bug to acpid and discovered how badly maintained it is. Despite a new maintainer in january this year, the BTS still shows many RC bugs and a bunch with patches. Hopefully this mail will draw some attention to the problem and some volunteers will step up to help maintain this package. http://packages.qa.debian.org/a/acpid.html Jose, I see you have many other packages. Please don't pick up important packages if you don't have the time or the motivation to bring them back in a good shape. And if you see that you don't cope, please look for help and/or orphan some of your packages (I see several with new upstream versions and quite a few that were NMUed, probably due to lack of action on your part). http://qa.debian.org/[EMAIL PROTECTED] Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- []'s José Carlos
Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Hi, Le 16 mai 08 à 13:48, Martin Uecker a écrit : Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? I personally often discuss the patches with my upstream (but then, they're really responsive). Most of the time they apply it to their CVS, and I backport their patch (generally improved over my approach). If a patch fixes a real bug and looks simple enough that's its unlikely to break anything, I think it's useful. Other patches are not supposed to go to upstream, because they are just meant to implement the Debian policy (also I generally tell upstream anyway, to have their opinion). Of course you need to define simple enough, and unlikely (for openssl, you want it to be _very_ unlikely). I agree with you that patching should be kept to a minimum : back-porting bug fixes and implementing Debian policy (even there, I would try to not overdo it, but a must in policy is a must). By the way, Debian policy is not completely silly, so even those patches can often go to upstream and be shared with the other distributions, of be configurable at build time. For instance, my main package, yorick, traditionally expects user files to be in ~/ Yorick/. Those files can be considered configuration or data, that really depends on the user. I've triggered a discussion on the matter that configuration files in a user's home directory should be stored in hidden files or directories (that's from the FHS). Yorick now looks at both ~/.yorick/ and ~/Yorick/, so the user can choose. I was motivated by abiding by Debian policy, but the change was made upstream, to avoid a fork. If upstream had rejected the idea, I'm not sure what I would have chosen. I tend to believe the right thing to do here was to avoid a fork at all cost, but others may disagree. Let's hope this discussion will, in the end, bring good ideas and trigger actual work to improve Debian, and perhaps the free software community at large. Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acpid package needs love and an active maintainer
On Fri, May 16, 2008 at 08:55:34AM -0300, Jose Carlos Medeiros wrote: I agree with you, if I can not keep then not caught. I am putting the package up for adoption. I'd be interested in this package as I have some issues with acpi anyway. I won't be able to look into this before next week though. If anyone else's interested I'd happily be part of a team. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Le vendredi 16 mai 2008 à 14:48 +0200, Thibaut Paumard a écrit : Let's hope this discussion will, in the end, bring good ideas and trigger actual work to improve Debian, and perhaps the free software community at large. Best regards, Thibaut. That'd be great. But please, may I suggest that only matters applying to keys, SSH, SSL be kep in the same Subject in the thread for future archives digging ? Thanks in advance. Best regards, -- Olivier BERGER [EMAIL PROTECTED] (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM Management SudParis (http://www.it-sudparis.eu/), Evry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)
On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote: I don't see your point. I can have libfoo1 and libfoo2 installed and used at the same time so both applications compiled for libfoo1 and libfoo2 can be used at the same time. I can recompile my applications for libfoo2 as I get around to it. When everything is recompiled libfoo1 can be removed. For kernel modules, I have to recompile all the kernel modules in order to move to a new kernel since I can't use a mixture of kernel modules for two different kernel versions since I can only be running one kernel at a time. We were talking about nvidia-graphics-drivers. Prebuilt nvidia LKM packages are already built by dedicated source packages. No, the nvidia package generates nvidia-glx, nvidia-glx-dev, nvidia-kernel-source and such. It does NOT know anything about building modules for specific kernel variants. That is done manually by someone so far (and hence seems to be a bit infrequent). The linux-modules-*-2.6 package makes it possible to simply have the buildd's take care of that job. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481490: ITP: unionfs-fuse -- user-space directory concatenation
Package: wnpp Severity: wishlist Owner: Bernd Schubert [EMAIL PROTECTED] * Package name: unionfs-fuse Version : 0.9.19~hg Upstream Author : Radek Podgorny [EMAIL PROTECTED], Bernd Schubert [EMAIL PROTECTED] * URL : http://podgorny.cz/moin/UnionFsFuse * License : BSD Programming Lang: C Description : Unionfs implementation in userspace (fuse) Unionfs-fuse is a filesystem which overlays one or more directories into a merged hierarchy. Typically this is used to merge a writable filesystem with a shared read-only filesystem to give the appearance of one large writable filesystem. . If you are looking for a kernel-space implementation rather than a user-space, you want to go with unionfs or aufs. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25-kvm Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NewInLenny: stuff that's changed between etch and lenny
I've started http://wiki.debian.org/NewInLenny and would like to invite y'all to populate the page with stuff that's changed between etch and lenny. For now, I suppose just dumping anything to the end of the list is good, we'll categorise later — but that's not to stop anyone who wants to contribute in this way. Cheers, -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems i never go without my dinner. no one ever does, except vegetarians and people like that. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
2008/5/16 Thibaut Paumard [EMAIL PROTECTED]: the topic has already been changed to ssl security desaster, and in my opinion this is precisely what my post is about: what can we learn from this disaster. (More precisely, I'm giving my 2c on what level of patching is acceptable in a Debian package. Since the disaster allegedly originates in abusive patching, this is relevant). I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. It's not a secret that many projects benefit from Debian patches, so there might be something good with them. Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. I think that defending the position of using pristine upstream source code are just a conservative position to guarantee that we can blame upstream or someone else if something like this happens again, not that bugs won't happen. Only those who don't do anything don't make mistakes. The point is to try to avoid mistakes, not to be able to blame upstream. Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing subjects when discussion becomes slightly off-topic - Was: Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Miriam Ruiz [EMAIL PROTECTED] writes: Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Perhaps uploads could come with the diff against the last version (or a link to it)? -- http://www.greenend.org.uk/rjk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster (was: Re: changing subjects when discussion becomes slightly off-topic - Was:Re: SSH keys: DSA vs RSA)
Le 16 mai 08 à 15:41, Miriam Ruiz a écrit : 2008/5/16 Thibaut Paumard [EMAIL PROTECTED]: [...] Maybe there should also be a clasification of packages according to how bad would a bug be in them for the whole system, so that patches in those could be more carefully reviewed. Actually, I seem to remember that the issue of critical packages being maintained by only one person have been pointed out here several times already this year (although I don't remember the particular threads). Certainly, such packages needs a better QA than the rest. By the way, I was under the impression that Ubuntu was claiming a tighter QA for their core system... (tighter than the rest of Ubuntu, perhaps not than Debian). I can see two approaches to deal with critical packages: - enforcing team maintaining, although I'm not sure that would solve the problem: how can we be certain that each members would cross-check each other's work? Perhaps a double signature could be required, so that we are certain that the source actually reached several maintainer's computers before being uploaded? - having a special queue where every upload (to those critical packages) needs to be reviewed by a special task force, but that would delay upgrades and there needs to be provisions for urgent security fixes... Perhaps those critical packages can indeed go directly into the pool, but be automatically marked with an RC bug: needs security review? That may be silly to mark every critical package as RC buggy each time it is uploaded to the archive... But doesn't it make some sense? Of course both approaches require skilled manpower... I can see that the first approach distributes the workload on potentially more people, while the second one may ensure the better reviews... There comes then the question of what packages are critical. At first I was thinking the entire set of required packages should be considered critical, but that may not be necessary. (And certainly, many packages which are _not_ required are critical as well). Hope I'm not talking too much non-sense. Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian patches
On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote: 2008/5/16 Thibaut Paumard [EMAIL PROTECTED]: the topic has already been changed to ssl security desaster, and in my opinion this is precisely what my post is about: what can we learn from this disaster. (More precisely, I'm giving my 2c on what level of patching is acceptable in a Debian package. Since the disaster allegedly originates in abusive patching, this is relevant). I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. It's not a secret that many projects benefit from Debian patches, Do you mean packages instead of projects here? Or can you give an example? so there might be something good with them. Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. I think that one problem is that our patches are too difficult to review. We should make our Debian-specific changes more visible, comment them, etc. We could write a diff2html tool that would help read our diff.gz files by separating packaging changes from changes made to upstream source, and then publish that information on a patches.d.o service, and link it from various places (packages.d.o, PTS). That would probably help convince our users that we make sensible changes, and would also allow upstream developers to browse our changes easily (and comment/merge them). -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to handle Debian patches
[Breaking the thread on purpose to start a new one] On Fri, 16 May 2008, Lucas Nussbaum wrote: On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote: just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. I think that one problem is that our patches are too difficult to review. We should make our Debian-specific changes more visible, comment them, etc. We could write a diff2html tool that would help read our diff.gz files by separating packaging changes from changes made to upstream source, and then publish that information on a patches.d.o service, and link it from various places (packages.d.o, PTS). I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. The source package is an export format of our packaging work and they must highlight our changes so that other people can easily grab our changes and/or review them. [1] In the general case, I do believe that the new source package format 3.0 (quilt) will help as all Debian specific changes will always end up in debian/patches/. Any manual change leads to a new patch that will be associated to the version where it has been introduced so it's easy to look the changelog to find the explanation of the change (if any). And patches directly installed in debian/patches ought to be documented (see below for more on this). Once we switched to this source format, it should be trivial to create patches.debian.org. [2] Add to this that each patch should have some standardized header on top stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe Someone recently posted an example of this. IMO we should write a DEP on patch management and standardize those headers. And probably enforce their usage for patches on sensitive packages (lintian checks?). Cheers, [1] It has a cost but I believe it's worth it. And we need to work on tools that let us handle our changes in topic branches and yet still generate a package which is a plain upstream tarball + a series of patches. [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)
On Thu, 15 May 2008, Steinar H. Gunderson wrote: On Wed, May 14, 2008 at 06:22:37PM -0500, Steve Greenland wrote: Therefore, anyone who had a DSA key has had it compromised... Shouldn't that be anyone who had a DSA key *created by the flawed version of openssl* has had it compromised...? Or are you asserting something stronger? No. Any key who had a single DSA signature created by the flawed version of OpenSSL should be considered compromised. DSA requires a secret, random number as part of the signature process; if someone figures it out, or you use the same number twice, the entire secret key falls. If I understand correctly, it means that if you use a good key with a flawed openssl to connect to an other host using that key, then that key can be considered compromised. But what about using a good key on a host with a good openssl, to connect to a server which use a bad openssl ? regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
extensive patching
[EMAIL PROTECTED] wrote: I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. Buggy patches happen all the time. The question is, how could something as bad as this slip through? And one important reason is IMHO, that splitting up the development/bug fixing/review by creating different software branches is bad. On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. It's not a secret that many projects benefit from Debian patches, so there might be something good with them. Clearly, Debian adds value by its patches. If those patches would be integrated upstream, then the whole free software community would benefit. Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. I would prefer if only security fixes and bugs which might cause data loss would fixed directly in Debian. Everything else should go upstream first. Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. Did you look at the code? This was not exactly a deeply hidden flaw in some obscure looking code. Upstream didn't see the patch. That's exactly the problem. And I doubt that there was any review of this code in all this 2 years. I think that defending the position of using pristine upstream source code are just a conservative position to guarantee that we can blame upstream or someone else if something like this happens again, not that bugs won't happen. Only those who don't do anything don't make mistakes. The point is to try to avoid mistakes, not to be able to blame upstream. I do not think this is true. The criticism comes partly from the outside (for example from me), so this is clearly not motivated in the way you suggest. And I do not blame the developer for his mistake. I blame the processes. Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Checking something extensively is much easier if there is one canonical branch which everybody agrees on. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)
On Fri, May 16, 2008 at 11:26 AM, nicolas vigier [EMAIL PROTECTED] wrote: On Thu, 15 May 2008, Steinar H. Gunderson wrote: No. Any key who had a single DSA signature created by the flawed version of OpenSSL should be considered compromised. DSA requires a secret, random number as part of the signature process; if someone figures it out, or you use the same number twice, the entire secret key falls. If I understand correctly, it means that if you use a good key with a flawed openssl to connect to an other host using that key, then that key can be considered compromised. But what about using a good key on a host with a good openssl, to connect to a server which use a bad openssl ? The reason the former fails is because DSA needs a random number to generate its signature (as Steinar describes). This signature is obviously generated with the local openssl. Connecting to a remote host with a bad openssl doesn't matter as the random number is generated with your local good openssl. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Please Cc [EMAIL PROTECTED] on this thread! Including the full response for the list. also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]: [Breaking the thread on purpose to start a new one] On Fri, 16 May 2008, Lucas Nussbaum wrote: On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote: just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. I think that one problem is that our patches are too difficult to review. We should make our Debian-specific changes more visible, comment them, etc. We could write a diff2html tool that would help read our diff.gz files by separating packaging changes from changes made to upstream source, and then publish that information on a patches.d.o service, and link it from various places (packages.d.o, PTS). I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. The source package is an export format of our packaging work and they must highlight our changes so that other people can easily grab our changes and/or review them. [1] In the general case, I do believe that the new source package format 3.0 (quilt) will help as all Debian specific changes will always end up in debian/patches/. Any manual change leads to a new patch that will be associated to the version where it has been introduced so it's easy to look the changelog to find the explanation of the change (if any). And patches directly installed in debian/patches ought to be documented (see below for more on this). Once we switched to this source format, it should be trivial to create patches.debian.org. [2] Add to this that each patch should have some standardized header on top stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe Someone recently posted an example of this. IMO we should write a DEP on patch management and standardize those headers. And probably enforce their usage for patches on sensitive packages (lintian checks?). Cheers, [1] It has a cost but I believe it's worth it. And we need to work on tools that let us handle our changes in topic branches and yet still generate a package which is a plain upstream tarball + a series of patches. [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems a mathematician is a device for turning coffee into theorems. -- paul erdös digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)
On Fri, May 16, 2008 at 05:26:09PM +0200, nicolas vigier wrote: If I understand correctly, it means that if you use a good key with a flawed openssl to connect to an other host using that key, then that key can be considered compromised. If I have a DSA key, and the client (my machine) has a bad OpenSSL, then I have exposed my secret key. This is because I generate the random data on the client. But what about using a good key on a host with a good openssl, to connect to a server which use a bad openssl ? Since the random data is generated on the client, I have not exposed my key. However, if Diffie-Hellman key exchange is used, the session key is probably insecure, and thus it is easy to sniff the messages. Note that this only applies to DSA. RSA keys only use random data to pad the signature (such as in PKCS #1), and so it is much less likely that you have exposed the secret key. (For the unlikely situation that you have, see Low Encryption Exponent Attack against RSA, Applied Cryptography, p.472). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: extensive patching
Martin Uecker wrote: [EMAIL PROTECTED] wrote: I disagree. The cause of the disaster was not that Debian does its own patching, but the fact that that patch was buggy. Buggy patches happen all the time. The question is, how could something as bad as this slip through? And one important reason is IMHO, that splitting up the development/bug fixing/review by creating different software branches is bad. Different software branches in what respect? Just by nature of having a distro package ? On the whole I think that Debian benefits a lot from custom patches, and in fact many packages would be severely buggy and/or wouldn't integrate properly with the rest of the system without them. It's not a secret that many projects benefit from Debian patches, so there might be something good with them. Clearly, Debian adds value by its patches. If those patches would be integrated upstream, then the whole free software community would benefit. Which brings up at least two issues. Upstream not wanting the patches or dead upstream. Speaking from the games team alone I would bet that 50% or more of the packages have no upstream anymore. Should those packages be removed? Also, obviously, there are changes that make no sense to upstream that are strictly distro specific. Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. I would prefer if only security fixes and bugs which might cause data loss would fixed directly in Debian. Everything else should go upstream first. Sounds good but again, what about unresponsive/dead upstreams. Do you leave your users to suffer ? Is Debian here to service the user community or not? Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. Did you look at the code? This was not exactly a deeply hidden flaw in some obscure looking code. Upstream didn't see the patch. That's exactly the problem. And I doubt that there was any review of this code in all this 2 years. I have seen links where upstream was asked about/notified of the patch so this isn't an entirely true statement. Egos play a big part in all of this as well. snip Of course, the development and checking of the patches should be done as cooperatively with upstream as possible, as upstream might see something we're not seeing, but the way to the solution, in my opinion, is not to avoid patching but to develop a way to check them as extensively as possible. Checking something extensively is much easier if there is one canonical branch which everybody agrees on. Sounds like Utopia but I can't see it happening. Regards, Martin Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Hi Martin, Martin Uecker wrote: Kevin B. McCarty [EMAIL PROTECTED] wrote: If you see packages for which a Debian-specific patch seems unnecessary, please by all means file a bug (severity wishlist) requesting that the patch be either reverted or submitted upstream. Most time the patch is already submitted upstream, but not yet applied or released. If you look into the Debian changelogs you find a lot of drop XXX patch, applied upstream. This is done to bring the fix faster to the user. The question is, is this worth it? Maybe it is, but only for certain patches? Is there a policy? Well, *assuming* the patch is good, a subset of users of the software (i.e. Debian users and users of downstream distributions) benefit from it between the time it's applied in Debian and the time it's applied upstream, and there are no major negatives that I can think of. But that assumption is what you really want to discuss, I guess. As far as I know, Debian policy is silent about when to apply a patch or how to decide if it's good. If upstream is responsive, it might make sense to wait until someone from there reviews the patch and gives a thumbs-up or -down. That supposes it is clear how to get in touch with upstream, which I gather was one of the big mis-communications leading to the current state of affairs [1]. [1] http://advogato.org/person/branden/diary/5.html Speaking only for myself, let me comment on some extensive patching. I guess that some of my physics-related packages (cernlib, paw) are among the more heavily patched in Debian. Unfortunately upstream is dead, so there is *no way* to see the patches incorporated there. As other have already pointed out: In this case, it should be considered a fork. It's really just an argument over semantics. I personally think of a real fork as one where someone purports to have taken over the role of upstream. You're welcome to have a different opinion (clearly you do). The XFree86 4.3.0 that Debian shipped with Sarge was also extremely heavily patched from the upstream version, but I don't believe most people thought of it as a real fork (unlike X.org). And even before they gave up the ghost, they were very conservative, refusing to consider most patches more complicated than trivial changes to fix complete breakage. Open source development does work well only if splitting up the development in different branches or even forks is strongly avoided and done only if it is strictly necessary. IMHO the Debian way of doing things makes it far too easy for package maintainers to diverge from the upstream source. I can't really comment on the examples you have provided, but in general, I feel that Debian has not found the right balance here. At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. [2] http://www.public.asu.edu/~comfort/cernlib.html [3] http://www-zeuthen.desy.de/linear_collider/cernlib/new/cernlib_2005.html [4] http://cernlib.web.cern.ch/cernlib/install/install.html One could certainly envision a distribution that used a Debian-like packaging infrastructure, but had a goal of trying to deviate from upstream's source code as little as possible. I think that such a distribution would either have serious QA problems (think for instance of embedded code copies, a security nightmare) or would be restricted to packaging a much smaller set of software than Debian does. YMMV. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: How to handle Debian patches
2008/5/16 martin f krafft [EMAIL PROTECTED]: Please Cc [EMAIL PROTECTED] on this thread! Done. also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]: Add to this that each patch should have some standardized header on top stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe Someone recently posted an example of this. IMO we should write a DEP on patch management and standardize those headers. And probably enforce their usage for patches on sensitive packages (lintian checks?). Just for the record, I totally agree with Raphael. I guess this would be something very useful to have and quite an improvement on the situation. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
martin f krafft [EMAIL PROTECTED] wrote: [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) I am not convinced that more technological infrastructure is really the solution. Isn't simply the upstream source the right place for collaboration? IMHO the problem is not, that managing and reviewing patches in debian or sharing patches with other is distributions is too hard, but that it is *too easy* to introduce changes into Debian, removing all pressure for close cooperation with the upstream project. Regards, Martin signature.asc Description: Digital signature
Re: extensive patching
Barry deFreese wrote: [...] Buggy patches happen all the time. The question is, how could something as bad as this slip through? And one important reason is IMHO, that splitting up the development/bug fixing/review by creating different software branches is bad. Different software branches in what respect? Just by nature of having a distro package ? By having a large diff against the upstream source with changes unrelated to packaging. [...] Clearly, Debian adds value by its patches. If those patches would be integrated upstream, then the whole free software community would benefit. Which brings up at least two issues. Upstream not wanting the patches or dead upstream. Speaking from the games team alone I would bet that 50% or more of the packages have no upstream anymore. Should those packages be removed? If upstream is dead or unable to do his job well, somebody should fork the project (or take ownership). But this has nothing to do with packaging software and should in my opinion not be intermixed. Also, obviously, there are changes that make no sense to upstream that are strictly distro specific. Requiring distro specific changes feels wrong anyway. Software should be coupled by standardized interfaces. But I might be naive here. What are the distro specific changes we are talking about? Also, I don't think we should always wait for upstream's new releases for adding them if we have them available. It might depend on every case. I think there should be a policy. I propose: I would prefer if only security fixes and bugs which might cause data loss would fixed directly in Debian. Everything else should go upstream first. Sounds good but again, what about unresponsive/dead upstreams. Do you leave your users to suffer ? Is Debian here to service the user community or not? Fork it. But not as part of the packaging work. Maybe there's a problem with the fact that some of those patches are just reviewed by just one person, but then again, I seriously think that it would have been quite difficult to discover that there was a problem with this one. The proof that it wasn't evident is not only that upstream didn't see the problem either, nor any other developer or derivative distribution or independent reviewers in 2 years. Did you look at the code? This was not exactly a deeply hidden flaw in some obscure looking code. Upstream didn't see the patch. That's exactly the problem. And I doubt that there was any review of this code in all this 2 years. I have seen links where upstream was asked about/notified of the patch so this isn't an entirely true statement. Egos play a big part in all of this as well. Upstream answered that it is okay too remove the seeding of the PRNG with uninitialized memory, but the concrete patch which additionally and erranously removed all seeding was never posted on openssl-dev. Regards, Martin signature.asc Description: Digital signature
Re: extensive patching
Hi On Fri, 16 May 2008 19:28:52 +0200 Martin Uecker [EMAIL PROTECTED] wrote: Upstream answered that it is okay too remove the seeding of the PRNG with uninitialized memory, but the concrete patch which additionally and erranously removed all seeding was never posted on openssl-dev. Are you sure? http://thread.gmane.org/gmane.comp.encryption.openssl.devel/10917 -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: How to handle Debian patches
On Fri, May 16, 2008 at 06:54:18PM +0200, Martin Uecker wrote: I am not convinced that more technological infrastructure is really the solution. Isn't simply the upstream source the right place for collaboration? NACK, or better: ACK in theory, but not in practice. Sometime you have wonderful upstreams which are willing to cooperate, reactive, and even share with you the love for $DVCS so that you can already exchange patch freely. But sometimes, most in my experience, this good properties do not hold. At that point you can really benefit in sharing patches across distros. I've been doing it a handful of times with Fedora maintainers which are working on OCaml packaging. They can easily point me to a single place on the web where they have patches. And I've benefited from them, as in the past they benefited from patches of mine. It happens that there are patches that upstream is not willing to take (maybe just because he is unreasonable) but in which more than one distro are interested [1]. On the contrary, as the Debian counterpart I cannot point them to a single unified place where my patches are available. Or better, I can but just because all OCaml packages are stored in a single svn repository, with a clear defined policy of only using debian/patches/ and no patches to upstream sources in .diff.gz. On a Debian-wide scale this kind of uniformity is not there: different $VCS, different policies on what to put in .diff.gz and what not. I think we will benefit a lot from a new unified patches.d.o infrastructure which clearly shows what changes we have made to software. ... and this is not only to ease code review which can diminish the risk of future disasters like openssl, but also for share efforts with others, probably the most important mantra of free software. (i.e. full-ack on Raphael's post) Cheers. [1] if you want an example here is one: the library libcamlrun.so implements the OCaml runtime systems as a shared object, if you have installed OCaml you can find it in `ocamlc -where`. It is linked without -fPIC by upstream which does not want to link it with because it slows down performances (which is of course true). Upstream does not want either to provide an additional library libcamlrun_shared.so linked with -fPIC as it will be an extra lib to maintain. In Debian I'm now applying a patch coming from Fedora which adds an extra library libcamlrun_shared.so as there is software, like Apache modules, which won't work if -fPIC is left aside -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
martin f krafft [EMAIL PROTECTED] writes: Please Cc [EMAIL PROTECTED] on this thread! Including the full response for the list. also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]: Add to this that each patch should have some standardized header on top stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe Someone recently posted an example of this. IMO we should write a DEP on patch management and standardize those headers. And probably enforce their usage for patches on sensitive packages (lintian checks?). It would be nice if dpkg-source would automatically create a header template if missing and fork an editor whenever it changes a patch. Maybe add a comment section with a diffstat of the last changes that will be removed when exiting the editor for quick reference while describing the change. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On 19:51 Fri 16 May , Stefano Zacchiroli wrote: On the contrary, as the Debian counterpart I cannot point them to a single unified place where my patches are available. Or better, I can but just because all OCaml packages are stored in a single svn repository, with a clear defined policy of only using debian/patches/ and no patches to upstream sources in .diff.gz. http://patches.ubuntu.com/by-release/extracted/ contains patches for both Debian and Ubuntu. It's quite useful. Thanks, Donnie PS -- this might not make it to debian-devel if it doesn't allow unsubscribed posters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Hi Kevin! Kevin B. McCarty [EMAIL PROTECTED] wrote: Martin Uecker wrote: [...] Well, *assuming* the patch is good, a subset of users of the software (i.e. Debian users and users of downstream distributions) benefit from it between the time it's applied in Debian and the time it's applied upstream, and there are no major negatives that I can think of. But that assumption is what you really want to discuss, I guess. I think it is problematic even if the patch is good, because having different software branches fragments all kind of bug fixing/development and reviewing work, which could otherwise be shared upstream. As far as I know, Debian policy is silent about when to apply a patch or how to decide if it's good. If upstream is responsive, it might make sense to wait until someone from there reviews the patch and gives a thumbs-up or -down. That supposes it is clear how to get in touch with upstream, which I gather was one of the big mis-communications leading to the current state of affairs [1]. [1] http://advogato.org/person/branden/diary/5.html This might be part of the problem, but there was discussion with other upstream developers on openssl-dev. So the problem was not that there was no communication, but that the actual patch was not forwarded to the upstream developers. [..] As other have already pointed out: In this case, it should be considered a fork. It's really just an argument over semantics. I personally think of a real fork as one where someone purports to have taken over the role of upstream. You're welcome to have a different opinion (clearly you do). The XFree86 4.3.0 that Debian shipped with Sarge was also extremely heavily patched from the upstream version, but I don't believe most people thought of it as a real fork (unlike X.org). I guess you are right, it's not a fork, more like a branch. I could imagine that there are good reasons for having a Debian branch for something like X, but I don't think this is true for many packages. [...] At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. Surely, this is very valuable work and I am not implying at all that you should stop it. But if upstream is dead, then their is no reason not to step in and simply take ownership of the package. Traditionally, if upstream was dead, somebody formally declared ownership of the software and took over development. I think this is the right thing to do, because then there is a new upstream where all other work can be shared. If upstream is incompetent, that somebody can step in and fork the software. Again, with a clear announcement. Then this step can be discussed openly and other users might switch over to the fork. Just integration all changes which are not accepted upstream as part of the packaging work just makes it too easy to diverge from upstream without good reason, without discussion and without an easy way for other users/distributions to see whats going on and to eventually switch over. One could certainly envision a distribution that used a Debian-like packaging infrastructure, but had a goal of trying to deviate from upstream's source code as little as possible. I think that such a distribution would either have serious QA problems (think for instance of embedded code copies, a security nightmare) or would be restricted to packaging a much smaller set of software than Debian does. YMMV. I don't now. I see no reason why all this good work which now ends up in Debian patches can't be seperated from the actual packaging work. Regards, Martin signature.asc Description: Digital signature
Re: How to handle Debian patches
also sprach Donnie Berkholz [EMAIL PROTECTED] [2008.05.16.1853 +0100]: http://patches.ubuntu.com/by-release/extracted/ contains patches for both Debian and Ubuntu. It's quite useful. Lucas Nussbaum threw the idea of having a webpage with posisbly annotated patches for each Debian package on *.debian.org at me the other day, in response to the OpenSSL debacle. I really liked it! It would be making it easy for everyone to look exactly at what we change between upstream and us, and it would certainly help with collaboration and QA. Apologies if this has been mentioned before. I am currently swamped and can't read along. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems perl -e 'print The earth is a disk!\n if ( earth == flat );' digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: extensive patching
Hi Michal! Martin Uecker [EMAIL PROTECTED] wrote: Upstream answered that it is okay too remove the seeding of the PRNG with uninitialized memory, but the concrete patch which additionally and erranously removed all seeding was never posted on openssl-dev. Are you sure? http://thread.gmane.org/gmane.comp.encryption.openssl.devel/10917 I don't see a patch there. This might sound like nitpicking, but a real patch would have provided some context to the two lines. Nevertheless, the right thing in my opinion would have been to propose a patch, wait until it is accepted, and then to package the new upstream version. Regards, Martin signature.asc Description: Digital signature
Re: ssl security desaster
Martin Uecker [EMAIL PROTECTED] writes: I don't now. I see no reason why all this good work which now ends up in Debian patches can't be seperated from the actual packaging work. It's probably worth mentioning somewhere in this discussion that one of the most common, perhaps the most common apart from FHS tweaks and other Debian-specific modifications that upstream does not want, to patch upstream source is to cherry-pick fixes from upstream before upstream has done a new release. That's most of the upstream patches to my packages, for example. A lot of those frequently indicates a close and very fruitful interaction with upstream. Waiting for upstream releases to fix problems when the fix is known is not a great idea, IMO, particularly when the problems are serious, and pulling an untested upstream VCS snapshot with lots of other changes isn't a good idea. I know that isn't the patch case that you were getting at, but it's important, when discussing scenarios around patches, to allow for that one as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote: Add to this that each patch should have some standardized header on top stating: - a description of the patch and its purpose , including pointers to relevant discussions, if any. The idea is that anyone reviewing the patch get easy access to as much relevant info as possible, either if it is at a bug report or elsewhere. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extensive patching
Hi Martin, I'm afraid this will be my last remark in this thread (do I hear cheers from the crowd?) since I really should go do something more productive now :-) Thanks for keeping the tone of discourse civil -- clearly this is a subject you feel strongly about, and the problem that started the thread frazzled all our nerves. Martin Uecker wrote: Barry deFreese wrote: Which brings up at least two issues. Upstream not wanting the patches or dead upstream. Speaking from the games team alone I would bet that 50% or more of the packages have no upstream anymore. Should those packages be removed? If upstream is dead or unable to do his job well, somebody should fork the project (or take ownership). But this has nothing to do with packaging software and should in my opinion not be intermixed. [snip] Fork it. But not as part of the packaging work. It's easy to say somebody should fork it. But not enough people have time or resources to guarantee a new upstream for every dead project (or project with a bad upstream) worth packaging. For an example, after I was no longer able to serve as a good upstream for wmakerconf (since I stopped using Window Maker), it was six months before someone else volunteered to take it over [1]. He made a single upstream release back in April 2007 and then also had to abandon it. Only today did someone (me) even get around to uploading that new release into Debian. And wmakerconf is not a very obscure package -- it has 797 installations in popcon [2], an installation rate of better than 1% among systems reporting to popcon. [1] http://bugs.debian.org/290350 [2] http://qa.debian.org/popcon.php?package=wmakerconf Maintainership in a caretaker mode, building up a large set of patches to keep things working, is often the best that can be expected. But this is a lot better than nothing! The larger the project, the more this is so. Time is unfortunately a scarce commodity in the community. Responding to some of your more recent email: Kevin B. McCarty [EMAIL PROTECTED] wrote: Martin Uecker wrote: At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. Surely, this is very valuable work and I am not implying at all that you should stop it. But if upstream is dead, then their is no reason not to step in and simply take ownership of the package. Traditionally, if upstream was dead, somebody formally declared ownership of the software and took over development. I think this is the right thing to do, because then there is a new upstream where all other work can be shared. I believe that declaring one is the new upstream of a software means taking on a *much* greater responsibility than being the Debian maintainer of a package of that software. In the case of Cernlib and PAW, they are venerable (i.e. obsolete) FORTRAN-based code that, with a big effort, can be forced to work and be policy-compliant on modern Linux systems with gfortran. Among physicists, who are mostly amazingly conservative with respect to software, they still have a following. As Debian maintainer, I only have to care about, and fix bugs for, people using the software on modern Linux/gfortran systems that I'm familiar with. As an upstream maintainer, I would have to care about: - people wanting support for obsolete platforms like HP-UX or SunOS (there are still lots of those old workstations around!) - people wanting support for platforms I don't want to care about, like Cygwin or Mac OS X - people wanting support for proprietary FORTRAN compilers - ensuring that the code works on new platforms (the build system is based on Imake, it is a nightmare!) - future-proofing by porting to autotools, and rewriting lots of code that assumes sizeof(void *) == sizeof(int) and only works on 64-bit platforms by use of ugly hacks And then there is not just the software itself, but also all the project infrastructure which would be expected if a new upstream took over: web pages, online documentation, upstream bug tracking system, mailing lists ... I do not have anything close to the resources that would be needed to do all that for a project the size of Cernlib, it would take a good-sized team of people. If upstream is incompetent, that somebody can step in and fork the software. Again, with a clear announcement. Then this step can be discussed
Re: How to handle Debian patches
Raphael Hertzog wrote: I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe All stuff that you get essentially for free by committing to a VCS. [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) We didn't just complain that Ubuntu's patches were unusable, but that their whole means of communication of them back to upstream, ie Debian, was/is flawed. We [1] complained that automatically publishing patches was not sufficient to get those patches integrated back into Debian because -- a) People cannot be expected to poll a directory somewhere for new patches. (Which Ubuntu has partially addressed, if your proposal does, it's not clear to me specifically how.) b) Monolithic patches that make multiple changes are near-useless. (Which Ubuntu has not satisfactorally addressed, IMHO; I still get automated patch mails with multiple changes in them. Your propsal tries to address this.) c) Patches lacked explanations of why changes were made, beyond the changelog, and it was difficult to figure out more. (Which Ubuntu has not particularly addressed, and I'm not sure your proposal addresses entirely..) d) The best way to get good code is to go out and get in communication with upstream about it, explain the rationalle so that they can fully understand it, and take their advice into account. (Which Ubuntu maintainers generally still fail to do with Debian, and which your proposal doesn't really facilitate Debian doing more than we do now.) I can certianly see some good benefits to the lines that you're thinking, but if this turns into a pile of patches on a website that upstream has to manually go find, and rarely does, and a lot of busywork keeping the patches up-to-date, and maintaining redundant metadata ... then why would I want to use that when I can shoot a mail off to upstream with a git-format-patch in it? -- see shy jo [1] specifically, me signature.asc Description: Digital signature
Re: How to handle Debian patches
Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit : You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. I can do more than insinuating: a VCS does not allow easily browsing and examining patches. It doesn’t prevent it, but solely, it is not sufficient. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: ssl security desaster
Russ Allbery wrote: Martin Uecker [EMAIL PROTECTED] writes: In this case, the security advisory should clearly be updated. And all advise about searching for weak keys should be removed as well, because it leads to false sense of security. In fact, *all* keys used on Debian machines should be considered compromised. All *DSA* keys. RSA keys do not have the same problem, as I understand it. Err, how so?? RSA keys generated with broken OpenSSL need replacing. This means SSL certificates, CA, etc But RSA keys (for SSL, as an example), generated on good OpenSSL but used on Etch servers are ok? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Josselin Mouette wrote: Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit : You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. I can do more than insinuating: a VCS does not allow easily browsing and examining patches. It doesn’t prevent it, but solely, it is not sufficient. Just like a debian/patches is far from sufficient for presenting patches in a generally usable or understandable format, which is why Raphael is suggesting to add extra metadata to it. Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. -- see shy jo [1] I hate using this word, but I think you know what I mean. signature.asc Description: Digital signature
Re: How to handle Debian patches
On Friday 16 May 2008, Joey Hess wrote: Raphael Hertzog wrote: I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. This is true, but not always handy. What you might buy is that the upstream or resp. debian user is not supposed to know for your kind of VCS (having it installed, etc) and where to find your VCS repo -- a ftp'ing of diff.gz or apt-get source pkg should be enough to get the *clearly identified patches* to the upstream source tree. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Friday 16 May 2008, Joey Hess wrote: Josselin Mouette wrote: Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit : You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. I can do more than insinuating: a VCS does not allow easily browsing and examining patches. It doesn’t prevent it, but solely, it is not sufficient. Just like a debian/patches is far from sufficient for presenting patches in a generally usable or understandable format How so ? I have seen several times non-Debian upstream developers downloading diff.gz from packages.debian.org (which is quite popular location) gunzip and patch diff, then having a look at *.patch files, and they know what has been changed to their particular upstream version (unless orig.tar.gz is not orig anymore, which could be the sad part of the story). Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. I personally don't think there is any need for new infrastrutures. We only need to follow some simple rules, i.e. orig.tar.gz should be really the original upstream source; diff.gz (debian/patches/ included) is what the debian developer added to it. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Josselin Mouette wrote: Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit : You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. I can do more than insinuating: a VCS does not allow easily browsing and examining patches. It doesn’t prevent it, but solely, it is not sufficient. git.debian.org Seems very clear to me. Same patch changes as upstream for small projects like Linux. Clear patches are not because of VCS, but because of clear and concisely described changesets. If you have patches with bad descriptions or a giant blob in VCS, then that is useless not because of the failure of VCS, but the failure of the developer. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Adam Majer [EMAIL PROTECTED] writes: Clear patches are not because of VCS, but because of clear and concisely described changesets. If you have patches with bad descriptions or a giant blob in VCS, then that is useless not because of the failure of VCS, but the failure of the developer. And by changeset in this context, referring to Git, you mean a branch? The description part is exactly the part that I don't know how to solve easily using Git unless the solution is to rebase everything and amend commits, which is a really annoying and substandard workflow. If I'm going to do that, I'd rather just use quilt, since then the workflow is the same as quilt and quilt is better at it. The useful part of Git is the merging and branching support; if I'm not going to merge branches, there doesn't seem to be a lot of point. But merges mean that there are no longer simple commits in the Git repository that one can point to. How does upstream easily get the complete description of a change that I have in a Git repository for packaging their software? What should I be doing to help with that? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pwsafe and OpenSSL?
Daniel Burrows wrote: I notice that pwsafe is linked against openssl. Is it affected by the recent debacle and if so, how? Do I need to regenerate all my randomized passwords, or somehow re-encrypt the pwsafe database? I've looked briefly into it: The Blowfish encryption key is constructed from a SHA1 built from an initial random value, two zero bytes and the passphrase. So if an unmodified database created using a broken libssl copy is exposed to an attacker, it's more open to brute forcing attempts, but still safe-guarded by the passphrase. Fortunately the random part is renewed whenever the database is saved. By my understanding - I don't use pwsafe myself - this should happen whever an entry is added or modified. Please double-check that with upstream and send a finalised version to [EMAIL PROTECTED], so that we can add it to http://www.debian.org/security/key-rollover/ once confirmed. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008, Joey Hess wrote: Raphael Hertzog wrote: To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. A VCS surely allows browsing and examining patches. But when I dig in a VCS history, it's because I have something precise to look up, I will rarely check it ouf of curiosity. debian/patches/ on the contrary is something that gets my attention when I unpack a source package. The other part of the problem depends on the workflow used within your VCS. As Russ explained, if you use topic branch to keep logical changes, then you have several relevant commits spread in the middle of multiple upstream commits and you don't have a single description of the branch itself. But don't get me wrong, I'm not opposed to using VCS for package maintainance (I do it!), I just think that we haven't found the perfect workflow yet. Ideally, I'd like something where I maintain my upstream changes in topic branches and the Debian branch would be another topic branch that just adds the debian directory (without debian/patches) and debian/patches/ is auto-generated from the set of topic branches. For this, we probably need to give some hints to the tool that will create the source package. Those hints could be in a file debian/source/patch-generation and would contain the (ordered) list of topic branches with its description and any other required meta-information. I know that it will not always work if we have strong dependencies between the topic branches but I'm not sure we have to optimize for that case as it shouldn't happen to often, and I prefer such a tool that work in 80% of the cases than no tool at all and continue with a package that consist of a giant patch mixing multiple stuff. (Or maybe we'll find a way to make it work in all cases, that would be even better... maybe we have to define and respect some relationship betwen the topic branches, have topic branch B be always based on A, and C on B, etc. so that diff between A-B, and B-C always end up being applicable one after the other) stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe All stuff that you get essentially for free by committing to a VCS. If that's the case, you can auto-generate that information at the same time when you generate the patches corresponding to your various branches. It's great! I can certianly see some good benefits to the lines that you're thinking, but if this turns into a pile of patches on a website that upstream has to manually go find, and rarely does, and a lot of busywork keeping the patches up-to-date, and maintaining redundant metadata ... then why would I want to use that when I can shoot a mail off to upstream with a git-format-patch in it? Certainly patches.d.o is not meant to replace direct interaction with upstream developers but it would be a nice service for upstream developers when the debian maintainer sucks (and it happens...) and also for other distributions that can benefit from our work. But when we give away patches, we also like to get patches from other back so that's why I believe that if we design any patch sharing infrastructure, we must open it from the beginning to other distributions so that we actually benefit from it too. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Raphael Hertzog [EMAIL PROTECTED] writes: But don't get me wrong, I'm not opposed to using VCS for package maintainance (I do it!), I just think that we haven't found the perfect workflow yet. In fact, despite being one of the big quilt advocates in the last round of this discussion, I am at this point pretty much sold on using Git due to its merges and branch support and have started to switch my packages over. However, the one thing discussed on this thread is still the thing I don't know how to do easily in Git. I have each logical change on its own branch, so I can trivially generate patches to feed to upstream with git diff upstream..bug/foo, but I don't know how to maintain a detailed description and status other than keeping a separate file with that information somewhere independent of the branch, or some special file included in the branch. I could do that, but it feels weird. I'd like to have some way to maintain the metadata more natively, but so far I'm having a failure of imagination short of always rebasing my bug branches, which makes merges into master annoying (unless I'm missing some magic rebase workflow, which is possible). Ideally, I'd like something where I maintain my upstream changes in topic branches and the Debian branch would be another topic branch that just adds the debian directory (without debian/patches) and debian/patches/ is auto-generated from the set of topic branches. Yup. For this, we probably need to give some hints to the tool that will create the source package. Those hints could be in a file debian/source/patch-generation and would contain the (ordered) list of topic branches with its description and any other required meta-information. Yeah, I suppose that would work. Certainly patches.d.o is not meant to replace direct interaction with upstream developers but it would be a nice service for upstream developers when the debian maintainer sucks (and it happens...) and also for other distributions that can benefit from our work. It would also be really nice for Debian maintainers who don't suck but who also don't want to go to the work of generating a nice list of patches and putting them on a web page (in case the developer doesn't get to their e-mail quickly or needs them resent) if there's a tool that can do it for us. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
* Martin Uecker | Another problem I have argued about before, not directly related to this | incident, but IMHO another desaster waiting to happen: There is no | way to independetly validate that a debian binary package was | created from the corresponding source. How would you go about doing that? If you just mean «all packages should be built on the buildds», that's fairly easy to do, but if you are talking about actual verification of source = binary which can be done post-mortem, that's much harder. | What bothers me too is the fact that the installer scripts of all | packages have root permissions during installation. While this might | be hard to do, in principle I see no good reason why installer | scripts could not be limited to certain tasks. I believe that postinsts need the flexibility shell (or perl or python or whatever) gives them. If you want to restrict postinsts to only be able to do a limited set of operations, the quality of packages will detoriate quite a bit as they are no longer flexible enough to cater for all packages's needs. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? Or what else are you referring to? Do you have an example or even a general direction of what would be acceptable in your opinion? And really I don't care how you generate those and I think it's best if we can generate those patches out of a VCS in the generic case. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssl security desaster
Tollef Fog Heen [EMAIL PROTECTED] writes: * Martin Uecker | What bothers me too is the fact that the installer scripts of all | packages have root permissions during installation. While this might | be hard to do, in principle I see no good reason why installer | scripts could not be limited to certain tasks. I believe that postinsts need the flexibility shell (or perl or python or whatever) gives them. If you want to restrict postinsts to only be able to do a limited set of operations, the quality of packages will detoriate quite a bit as they are no longer flexible enough to cater for all packages's needs. I've thought for a while that the best solution to this would be to write an interpreter with a *very simple* language that understands the semantics of Debian maintainer scripts and understands how to do the 50 or 100 most common things that people have to do in maintainer scripts. I think that writing a mini-language with very simple semantics, designed to be very easy to parse and analyze with automated tools, that supports 80% of what people do in maintainer scripts would be fairly straightforward (easily within a Google Summer of Code project). Packages could then have the option. Packagers could depend on that interpreter and use the mini-language, or they could fall back to shell or Perl the way that they do now for the complex cases. You'd probably want to skip config, preinst, and postrm support for the first pass until it's proven to be a good idea and one has built justification for making the package essential, but the long-term goal would be to have that interpreter become essential and have it be the default way of handling maintainer scripts. You can then still bail on packages that do things that are just way too hard and maintain that escape to stronger languages, while still gaining all the benefits of a highly restricted and simple language for the vast majority of packages. I of course have absolutely no time to work on this. :) But it's not something that anyone would need permission or approval to start doing. Anyone could do this right now, propose the language design for peer review here on debian-devel, and upload a package that implements it, and people who want to start experimenting with it could have their packages depend on it. (debhelper support would of course be useful at a fairly early stage, since a fairly substantial percentage of our maintainer scripts are generated at least in part by debhelper.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008 22:10:36 +0200, Josselin Mouette [EMAIL PROTECTED] said: Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit : You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. I can do more than insinuating: a VCS does not allow easily browsing and examining patches. It doesn’t prevent it, but solely, it is not sufficient. I am not sure I can agree. I find examining a single patch deep down in a quilt series very hard, unless I learn and use quilt, since the patches are all linearized, and each patch is dependent on th previous patch. diffing the tips of branches in a SCM has been far more friendly. So I find my old and new SCM's preferable to a quilt series -- since any feature can be compared to any other feature, or upstream, independently, and easily; this is terribly hard to do with quilt. manoj -- God is a comedian playing to an audience too afraid to laugh. Voltaire Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008 14:39:56 -0700, Russ Allbery [EMAIL PROTECTED] said: Adam Majer [EMAIL PROTECTED] writes: Clear patches are not because of VCS, but because of clear and concisely described changesets. If you have patches with bad descriptions or a giant blob in VCS, then that is useless not because of the failure of VCS, but the failure of the developer. And by changeset in this context, referring to Git, you mean a branch? The description part is exactly the part that I don't know how to solve easily using Git unless the solution is to rebase everything and amend commits, which is a really annoying and substandard workflow. If I'm going to do that, I'd rather just use quilt, since then the workflow is the same as quilt and quilt is better at it. The useful part of Git is the merging and branching support; if I'm not going to merge branches, there doesn't seem to be a lot of point. But merges mean that there are no longer simple commits in the Git repository that one can point to. How does upstream easily get the complete description of a change that I have in a Git repository for packaging their software? What should I be doing to help with that? Create a submission branch. There are two audiences for your work; one is downstream (which includes the integration branch for Debian), the other is upstream, one audience does not like rebases, the other thrives on it. See http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 for details on this scheme. manoj -- The difference between dogs and cats is that dogs come when they're called. Cats take a message and get back to you. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
2008/5/16 martin f krafft [EMAIL PROTECTED]: Lucas Nussbaum threw the idea of having a webpage with posisbly annotated patches for each Debian package on *.debian.org at me the other day, in response to the OpenSSL debacle. I really liked it! I think it would be a great Idea, but the point would be to be able to automate the process of uploading the patches there somehow from the package source. Combined with the idea of anotating the patches in the source packages, the result might be quite useful. I'm quite afraid that if the process is not automatic, but manual, the amount of extra work and redundancy of uploading the patches twice (once for the package, another one for the patches alone) will lead to very few developers participating, and also to desynchronization between the patches being uploaded and the real patches in the packages. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Manoj Srivastava [EMAIL PROTECTED] writes: Create a submission branch. There are two audiences for your work; one is downstream (which includes the integration branch for Debian), the other is upstream, one audience does not like rebases, the other thrives on it. See http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 for details on this scheme. Oh, huh. Both rebase *and* merge. I didn't even think of that. That would work, although it does... well, not double, but at least increase the work for any branch that also has a submission branch, since any upstream merge conflicts have to be resolved on both branches. Or is there some way to reuse the resolution work done with one of those branches when rebasing/merging the other? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Sat, 17 May 2008 00:19:59 +0300, George Danchev [EMAIL PROTECTED] said: I personally don't think there is any need for new infrastrutures. We only need to follow some simple rules, i.e. orig.tar.gz should be really the original upstream source; diff.gz (debian/patches/ included) is what the debian developer added to it. This is exactly what happened in the openssl case (modulo ./debian/patches). Indeed, this is already the recommendation: use pristine upstream, unless they have added non-dfsg materials, or something, and _all_ debian changes live in the diff.gz. Following this simple rule is what we normally do. manoj -- Leibowitz's Rule: When hammering a nail, you will never hit your finger if you hold the hammer with both hands. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extensive patching
On 11387 March 1977, Martin Uecker wrote: Nevertheless, the right thing in my opinion would have been to propose a patch, wait until it is accepted, and then to package the new upstream version. If you want that - build an own distribution. Or well - an LFS. Because thats *not* what a distribution is about. If we stop fixing stuff ourself we can just stop building our own distribution. -- bye, Joerg AM: Whats the best way to find out if your debian/copyright is correct? NM: Upload package into the NEW queue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008 23:27:03 +0300, George Danchev [EMAIL PROTECTED] said: On Friday 16 May 2008, Joey Hess wrote: Raphael Hertzog wrote: I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. This is true, but not always handy. What you might buy is that the upstream or resp. debian user is not supposed to know for your kind of VCS (having it installed, etc) and where to find your VCS repo -- a I find this to be true for quilt too. How does one extract what the 057th patch does, without examining all the leading patches up to that point? Linearizing features and intermixing integration changes along with feature-sets is something I have always found confusing. ftp'ing of diff.gz or apt-get source pkg should be enough to get the *clearly identified patches* to the upstream source tree. I find a quilt series to not fit the bill very well. On the other hand, creating ./debian/topics/foo/ with a git-format-patch series for each branch in there might be doable -- but then, these individual patches might not apply cleanly over each other. manoj -- Life is a series of rude awakenings. R.V. Winkle Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extensive patching
Hi Dne Fri, 16 May 2008 20:59:44 +0200 Martin Uecker [EMAIL PROTECTED] napsal(a): I don't see a patch there. This might sound like nitpicking, but a real patch would have provided some context to the two lines. Yes there is no context, but it is patch and it is clear that it wants to remove two lines of code. Today all we know that only one of them was relevant to that problem... Nevertheless, the right thing in my opinion would have been to propose a patch, wait until it is accepted, and then to package the new upstream version. Well the problem is that you always don't get response, you simply have to include some patches before they are reviewed/accepted by upstream. If you're lucky, upstream is responsive and you can push all patches directly to them, but from my experience[*] it many times does not work. [*]: I don't have much patched my Debian packages (well I'm upstream for many of them), but I was working for SUSE about 3 years ago and many of patches which were really needed for packaging are still waiting for even review in upstream trackers. You simply can not build distribution without not reviewed patches. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: How to handle Debian patches
On Fri, May 16, 2008 at 05:08:31PM -0500, Manoj Srivastava wrote: I am not sure I can agree. I find examining a single patch deep down in a quilt series very hard, unless I learn and use quilt, since the patches are all linearized, and each patch is dependent on th previous patch. I don't think this (each patch is dependent on the previous patch) is true for even a tiny fraction of Debian patches to upstream sources. Most patches I saw are independent from each other, and only for very involved packages with lots of patches this can become an issue for understanding things. Then again, if one patch depends on another, it should probably be noted in the metadata as well. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Saturday 17 May 2008, Manoj Srivastava wrote: On Fri, 16 May 2008 23:27:03 +0300, George Danchev [EMAIL PROTECTED] said: On Friday 16 May 2008, Joey Hess wrote: Raphael Hertzog wrote: I totally agree that we need to make our changes more visible. In the openssl case, the patch in question is inside the .diff.gz and you don't notice it in the unpacked source package. I tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. This is true, but not always handy. What you might buy is that the upstream or resp. debian user is not supposed to know for your kind of VCS (having it installed, etc) and where to find your VCS repo -- a I find this to be true for quilt too. No and no. I'm not talking about quilt or any particular debian patch system used. Upstream developers and/or random Debian users don't even need to know one to read the diff files supplied by diff.fz they already downloaded from ftp.d.o... and this is the simplest way possible for them to see what changes has been applied to their particular upstream source tree. How does one extract what the 057th patch does, without examining all the leading patches up to that point? Linearizing features and intermixing integration changes along with feature-sets is something I have always found confusing. ftp'ing of diff.gz or apt-get source pkg should be enough to get the *clearly identified patches* to the upstream source tree. I find a quilt series to not fit the bill very well. On the other hand, creating ./debian/topics/foo/ with a git-format-patch series for each branch in there might be doable -- but then, these individual patches might not apply cleanly over each other. Again, I'm not talking partucular patch-sys, as a packager you can use arbitrary VCS to store your packaging, but you can't assume that upstream developers and random debian users to follow you. See above. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Saturday 17 May 2008, Manoj Srivastava wrote: On Sat, 17 May 2008 00:19:59 +0300, George Danchev [EMAIL PROTECTED] said: I personally don't think there is any need for new infrastrutures. We only need to follow some simple rules, i.e. orig.tar.gz should be really the original upstream source; diff.gz (debian/patches/ included) is what the debian developer added to it. This is exactly what happened in the openssl case (modulo ./debian/patches). Not true. openssl packaging didn't and still does not use clearly identified diff files in debian/patches/. Indeed, this is already the recommendation: use pristine upstream, unless they have added non-dfsg materials, or something, and _all_ debian changes live in the diff.gz. Following this simple rule is what we normally do. A large number of packages do not follow that simple rule, but patching the orig.tar.gz instead. Then comes even more, even Ben Laurie (as he writes in his blog) with all his aggression missed to find the debian's pkg-openssl VCS repo [1] unless he has been helped by someone at some point. I'm not against the VCS repo (I myself use some for my packaging), I just claim that you can expect that random upstream developers and random debian users know about it, they need instead extremely simple and stable interfaces to access the changes to their upstream source currently found in Debian archive, and we already have that for years. P.S. Don't get me wrong I don't blame the DD. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)
Le May 16, 2008 09:10:35 am Lennart Sorensen, vous avez écrit : On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote: I don't see your point. I can have libfoo1 and libfoo2 installed and used at the same time so both applications compiled for libfoo1 and libfoo2 can be used at the same time. I can recompile my applications for libfoo2 as I get around to it. When everything is recompiled libfoo1 can be removed. For kernel modules, I have to recompile all the kernel modules in order to move to a new kernel since I can't use a mixture of kernel modules for two different kernel versions since I can only be running one kernel at a time. I still don't see your point. We were talking about nvidia-graphics-drivers. Prebuilt nvidia LKM packages are already built by dedicated source packages. No, the nvidia package generates nvidia-glx, nvidia-glx-dev, nvidia-kernel-source and such. It does NOT know anything about building modules for specific kernel variants. That is done manually by someone so far (and hence seems to be a bit infrequent). The linux-modules-*-2.6 package makes it possible to simply have the buildd's take care of that job. There are several nvidia* source packages. Those that contain modules are dedicated for prebuilt nvidia LKM-s. The nvidia* source packages are included in those shown on http://qa.debian.org/[EMAIL PROTECTED]comaint=yes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extensive patching
On Fri, 16 May 2008, Martin Uecker wrote: Requiring distro specific changes feels wrong anyway. Software should be coupled by standardized interfaces. But I might be naive here. What are the distro specific changes we are talking about? It'd be great[0] if we never had to do distribution specific changes.[1] However, considering the amount of software which is not LSB compliant, FHS compliant, policy compliant, ships internal libraries, has upstreams who don't understand API and ABIs, has slow release cycles, has insane upstreams, or otherwise includes bugs which need to be fixed, that'll only rarely be the case for some very simple packages. Even so, most developers and maintainers actively work to reduce the size of the diff.gz that they ship by sending patches upstream, if for no other reason than doing so means that they don't have to deal with merging back in Debian specific patches later. Those who are concerned about what happened in the ssl case are welcome and encouraged to assist maintainers in examining the patches made to software, and liasing with upstream for useful patches, and discussing questionable packages. [Use Luciano as an example: he actually found a mistake while those of us discussing this thread engage the barn door.] At the end of the day, we're here to make the most technically excellent distribution we can make. That means making changes, and sometimes we make mistakes. Finding and fixing those mistakes and spreading the changes to everyone is what we should be doing. Don Armstrong 0: We could just ship a universal diff.gz that installed a very simple debian/rules file that called dh, and we could spend the rest of our time making macros, drinking arrak, and playing tetrinet! 1: One could argue that if you can't come up with a relatively large list of distribution specific changes that need to be made yourself, you've not done the research to make useful suggestions for radically altering how Debian actually does development. Knowing the problem comes before the knowing answer. -- No amount of force can control a free man, a man whose mind is free [...] You can't conquer a free man; the most you can do is kill him. -- Robert Heinlein _Revolt in 2010_ p54 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Current build status of the mips port
I went again through the mips build problems and collected the appended list which records the current state, with a few annotations added. Thiemo Debian mips port, status 2007-05-16. See also: http://buildd.debian.org/~jeroen/status/architecture.php?suite=unstablea=mipspriority= Architecture-independent problems, failed packages and Dep-waits are not systematically tracked. The mipsel port is only incidentially tracked. == Maybe fixed (TODO: remove when actually ok) --- cacao # CTX_EPC undeclared, patch sent, #449185, #479529, fixed in experimental, reopened root-system # partial patch sent, #434855, fixed differently upstream # - but FTBFS in experimental with new version gddrescue # patch sent, #474426 guile-1.8 # segfaults (ia64 mips mipsel), patch sent, #481378 firebird2.0 # patch sent, #481208 scribus # was disabled for old toolchain bug, re-enable requested, #481441 libflorist # odd gnat-4.1 dep, patch sent, #479075 tightvnc# Needs imake tweak, patch sent, #481444 lasso # botched java check, patch sent, #479737, (mips mipsel s390) soci# patch sent, #481499 Needs retry --- usepackage # not reproducible, (mips mipsel) openarena # not reproducible, (mips) hildon-thumbnail # (mipsel) libhildonfm # (mips) [mipsel needs dep-wait on hildon-thumbnail] hildon-desktop # (sparc) [mips mipsel need dep-wait on libhildonfm] helium # (mipsel powerpc) netatalk# (mips) illuminator # (arm mips mipsel) libgdal-grass # (mips mipsel powerpc) hplip # (mips mipsel) Maybe needs retry (TODO: check) --- -- Qt ABI, fix by waiting for next Qt version -- kde4libs# needs rebuild to fix ABI (or wait for new version) kdebase-runtime merkaartor universalindentgui sailcut psi ktoon # Broken qt ABI -- ghc6 stuff -- washngo # vm exhausted, (arm armel mips mipsel powerpc) haskell-haskell-src # vm exhausted, (mips mipsel alpha) lhs2tex pandoc gtkrsync highlighting-kate haskell-happs-data haskell-happs-ixset haskell-happs-server haskell-happs-state haskell-happs-util haskelldb-hsql-mysql haskelldb-hsql-odbc haskelldb-hsql-postgresql haskelldb-hsql-sqlite3 arch2darcs darcs-buildpackage hpodder -- other -- mlt # (ia64 mips mipsel powerpc) vdr-plugin-live kde-style-qtcurve # not reproducible, but see #462001, (amd64 arm hppa mips powerpc s390 sparc) mozart gpsdrive libgtk-java # needs libcairo-java-dev qtnx# needs libnxcl1 tuxguitar music-applet# needs libxml-parser-perl, (mips mipsel powerpc) mplayer # (hppa mips mipsel powerpc sparc) edenmath.app gnome-chemistry-utils virt-manager gsynaptics ucspi-proxy epiphany-extensions Broken source - -- Bug reported -- monotone# Testsuite too strict, #474280 mklibs # See #445507 xserver-xorg-video-newport # See #402178 g-wrap # See #473085 noteedit# See #474896 libjdic-java# doesn't try to build arch-specific packages, #478943 iaxclient # Needs atomics, #475809 ardour # See #474422 kaffe # perl failure, pending, #479716 xcircuit# creates files in clean, #481460 glob2 # See #479872 gst-editor # See #436324 gnome-cups-manager # See #417209 camelbones # See #447373, removal requested haskell-syb-with-class # template haskell, #469890 -- gcc-4.3 induced bugs, no patch -- insighttoolkit # See #474537, #478950 necpp # See #474838 gpsim # See #474796 ttfm# See #474409 asc # See #478838 qtractor# See #481393 dballe # See #381397 -- bug unreported -- libqglviewer# creates files in clean galax # creates files in clean gigedit # gcc-4.3 gnudatalanguage # gcc-4.3 Should be in in P-a-s (or not-for-us?) -- -- sys/io.h on (mips mipsel powerpc) -- flashrom lcd4linux vbetool libx86 superiotool rovclock -- ocamlopt on !(alpha arm armel hppa ia64 m68k mips mipsel s390) -- ara spamoracle whitelister -- no upstream support for mips/mipsel -- rtai xen-3 virtualbox-ose xserver-xorg-video-intel # x86 only xserver-xorg-video-geode # x86 only libacpi # x86/ia64 only flashplugin-nonfree-extrasound # i386 only eeepc-modules-2.6 # i386 only cpushare# P2P distributed computing client systemtap # needs kprobe umview # UML related? usplash tuxonice-userui # needs libusplash-dev brdesktop-artwork # needs libusplash-dev -- other -- gcj-4.1 # obsolete on mips/mipsel Unported -- Hard to port, porting deferred -- qemu# currently no host support upstream purelibc llvm-gcc-4.2 openmpi openafs -- Maybe needs port (TODO: check) -- freej xenomai lcdproc dphys-kernel-packages ddccontrol
Re: How to handle Debian patches
George Danchev [EMAIL PROTECTED] writes: A large number of packages do not follow that simple rule, but patching the orig.tar.gz instead. I have never seen a package that does this apart from DFSG-freeness issues and a few beginner mistakes. The Debian changes are separated out in our source package format in a *.diff.gz, just as they are and were with the openssl package. windlord:~/tmp lsdiff -z -x '*/debian/*' openssl_0.9.8g-10.diff.gz openssl-0.9.8g/Makefile openssl-0.9.8g/Configure openssl-0.9.8g/Makefile.shared openssl-0.9.8g/config openssl-0.9.8g/Makefile.org openssl-0.9.8g/openssl.ld openssl-0.9.8g/VMS/VMSify-conf.pl openssl-0.9.8g/Netware/do_tests.pl openssl-0.9.8g/apps/s_time.c openssl-0.9.8g/apps/CA.sh openssl-0.9.8g/apps/CA.pl.in openssl-0.9.8g/apps/speed.c openssl-0.9.8g/apps/CA.pl openssl-0.9.8g/os2/backwardify.pl openssl-0.9.8g/engines/Makefile openssl-0.9.8g/engines/openssl.ld openssl-0.9.8g/tools/c_rehash openssl-0.9.8g/tools/c_rehash.in openssl-0.9.8g/ssl/t1_lib.c openssl-0.9.8g/ms/uplink.pl openssl-0.9.8g/demos/tunala/configure.in openssl-0.9.8g/doc/Makefile openssl-0.9.8g/doc/apps/c_rehash.pod openssl-0.9.8g/crypto/Makefile openssl-0.9.8g/crypto/x86cpuid.pl openssl-0.9.8g/crypto/opensslconf.h openssl-0.9.8g/crypto/x86_64cpuid.pl openssl-0.9.8g/crypto/md5/asm/md5-x86_64.pl openssl-0.9.8g/crypto/md5/asm/md5-sparcv9.S openssl-0.9.8g/crypto/sha/sha.h openssl-0.9.8g/crypto/sha/asm/sha1-ia64.pl openssl-0.9.8g/crypto/sha/asm/sha512-sse2.pl openssl-0.9.8g/crypto/sha/asm/sha512-ia64.pl openssl-0.9.8g/crypto/rand/md_rand.c openssl-0.9.8g/crypto/des/asm/desboth.pl openssl-0.9.8g/crypto/rc4/asm/rc4-x86_64.pl openssl-0.9.8g/crypto/perlasm/x86unix.pl openssl-0.9.8g/crypto/perlasm/cbc.pl openssl-0.9.8g/crypto/perlasm/x86_64-xlate.pl openssl-0.9.8g/crypto/pkcs7/pk7_mime.c openssl-0.9.8g/crypto/bn/asm/ppc.pl openssl-0.9.8g/crypto/aes/asm/aes-586.pl openssl-0.9.8g/crypto/asn1/charmap.pl openssl-0.9.8g/util/mkerr.pl openssl-0.9.8g/util/clean-depend.pl openssl-0.9.8g/util/extract-names.pl openssl-0.9.8g/util/pod2man.pl openssl-0.9.8g/util/mkstack.pl openssl-0.9.8g/util/selftest.pl openssl-0.9.8g/util/extract-section.pl openssl-0.9.8g/util/mkdef.pl openssl-0.9.8g/util/pl/netware.pl That's why, when you run dpkg-source -x openssl_0.9.8g-10.dsc, you get output like: dpkg-source: extracting openssl in openssl-0.9.8g dpkg-source: info: unpacking openssl_0.9.8g.orig.tar.gz dpkg-source: info: applying openssl_0.9.8g-10.diff.gz -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acpid package needs love and an active maintainer
On Fri, May 16, 2008 at 02:55:58PM +0200, Michael Meskes wrote: I'd be interested in this package as I have some issues with acpi anyway. I won't be able to look into this before next week though. If anyone else's interested I'd happily be part of a team. Good. I'm already working on acpid fixing its bugs. Before Jose Carlos sent his response to the list, I wrote to him about taking care of acpid and he replied saying me to go ahead and do it. signature.asc Description: Digital signature
Re: How to handle Debian patches
On Sat, 17 May 2008, George Danchev wrote: On Saturday 17 May 2008, Manoj Srivastava wrote: This is exactly what happened in the openssl case (modulo ./debian/patches). Not true. openssl packaging didn't and still does not use clearly identified diff files in debian/patches/. Uh... that's why Manoj said modulo ./debian/patches Indeed, this is already the recommendation: use pristine upstream, unless they have added non-dfsg materials, or something, and _all_ debian changes live in the diff.gz. A large number of packages do not follow that simple rule, but patching the orig.tar.gz instead. Which packages are these, and why aren't there bugs filed about this? Don Armstrong -- Ban cryptography! Yes. Let's also ban pencils, pens and paper, since criminals can use them to draw plans of the joint they are casing or even, god forbid, create one time pads to pass uncrackable codes to each other. Ban open spaces since criminals could use them to converse with each other out of earshot of the police. Let's ban flags since they could be used to pass secret messages in semaphore. In fact let's just ban all forms of verbal and non-verbal communication -- let's see those criminals make plans now! http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008 15:49:25 -0700, Russ Allbery [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: Create a submission branch. There are two audiences for your work; one is downstream (which includes the integration branch for Debian), the other is upstream, one audience does not like rebases, the other thrives on it. See http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 for http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 details http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 on http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 this http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4 scheme. Oh, huh. Both rebase *and* merge. I didn't even think of that. That would work, although it does... well, not double, but at least increase the work for any branch that also has a submission branch, since any upstream merge conflicts have to be resolved on both branches. Or is there some way to reuse the resolution work done with one of those branches when rebasing/merging the other? You can mostly automate this, with proper naming. (I suppose I should blog about this). See, my topic branches are called topic--foo, and there is a corresponding submission--foo branch. Whenever you commit to the topic--foo branch, arrange to cherry pick that commit to the submission--foo branch. When you merge upstream into topic--foo branch, you also rebase submission--foo branch. Sure, you might at times have to resolve the same changes in both branches, but doing it one after the other, you can just copy the affected files into the stash, or something, and just pull them out after -- so one set of cp/cp back per file, and this is also not a major amount of work. I still need to write more general scaffold scripts, but this is working out rather well. manoj -- Computers will not be perfected until they can compute how much more than the estimate the job will cost. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alioth and SSH: restored
Roland Mas [EMAIL PROTECTED] writes: - Keys submitted through the web interface are now filtered, and only RSA keys end up in your authorized_keys file. Don't even try putting DSA keys in your authorized_keys2 file, the use of that file has been disabled (and it'll be deleted anyway). The text of URL:https://alioth.debian.org/account/editsshkeys.php still reads: To generate a public key, run the program 'ssh-keygen' (you can use both protocol 1 or 2). The public key will be placed at '~/.ssh/identity.pub' (protocole 1) and '~/.ssh/id_dsa.pub' or '~/.ssh/id_rsa.pub' (protocole 2). Read the ssh documentation for further information on sharing keys. Please update this page to match the set of acceptable key types as per the announcement. -- \ My interest is in the future, as I am going to spend the rest | `\ of my life there. -- Charles F. Kettering | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 16 May 2008 15:25:11 -0700, Russ Allbery [EMAIL PROTECTED] said: Raphael Hertzog [EMAIL PROTECTED] writes: But don't get me wrong, I'm not opposed to using VCS for package maintainance (I do it!), I just think that we haven't found the perfect workflow yet. In fact, despite being one of the big quilt advocates in the last round of this discussion, I am at this point pretty much sold on using Git due to its merges and branch support and have started to switch my packages over. However, the one thing discussed on this thread is still the thing I don't know how to do easily in Git. I have each logical change on its own branch, so I can trivially generate patches to feed to upstream with git diff upstream..bug/foo, but I don't know how to maintain a detailed description and status other than keeping a separate file with that information somewhere independent of the branch, or some special file included in the branch. My solution is to git rebase -i the submit branch, and make sure that the first commit has a full commentary on the patch series to follow. Then for submit_branch in .git/refs/heads/submit--*; do branch=$(basename $submit_branch) test -d debian/topics/$branch/ || mkdir -p debian/topics/$branch git format-patch -p --src-prefix=old --dst-prefix=new -n -k -s \ --thread --ignore-if-in-upstream --cover-letter \ -o debian/topics/$branch/ master..$branch done I am not yet sure I like the --cover-letter bit, though. manoj -- I don't know if it's what you want, but it's what you get. :-) Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extensive patching
On Fri, May 16, 2008 at 11:26:01AM -0700, Don Armstrong wrote: On Fri, 16 May 2008, Martin Uecker wrote: Requiring distro specific changes feels wrong anyway. Software should be coupled by standardized interfaces. But I might be naive here. What are the distro specific changes we are talking about? It'd be great[0] if we never had to do distribution specific changes.[1] However, considering the amount of software which is not LSB compliant, FHS compliant, policy compliant, ships internal libraries, has upstreams who don't understand API and ABIs, has slow release cycles, has insane upstreams, or otherwise includes bugs which need to be fixed, that'll only rarely be the case for some very simple packages. [...] 1: One could argue that if you can't come up with a relatively large list of distribution specific changes that need to be made yourself, you've not done the research to make useful suggestions for radically altering how Debian actually does development. Knowing the problem comes before the knowing answer. Because LBS, FHS, APIs and ABIs, slow release cycles, insane upstreams and bugs are Debian specific issues? I don't think so. signature.asc Description: Digital signature
Re: How to handle Debian patches
Le Fri, May 16, 2008 at 09:18:56PM +0200, Agustin Martin a écrit : On Fri, May 16, 2008 at 05:54:32PM +0200, Raphael Hertzog wrote: Add to this that each patch should have some standardized header on top stating: - a description of the patch and its purpose , including pointers to relevant discussions, if any. The idea is that anyone reviewing the patch get easy access to as much relevant info as possible, either if it is at a bug report or elsewhere. Other idea: when the package is produced through a workflow that uses /debian/patches, shipping them in /usr/share/doc/package/patches. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote: That would work, although it does... well, not double, but at least increase the work for any branch that also has a submission branch, since any upstream merge conflicts have to be resolved on both branches. Or is there some way to reuse the resolution work done with one of those branches when rebasing/merging the other? Check 'man git-rerere'. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Quoting Raphael Hertzog ([EMAIL PROTECTED]): On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? I follow this discussion from quite far (because most of the times it goes over my head particularly when dealing with VCS stuff), but I see Raphaël's proposal to be quite similar to what we do for samba: - have a debian/patches directory - add pseudo headers to those patches with stuff like: Goal: Prepare the sources to better respect FHS New configurable paths are introduced in fhs-newpaths.patch This patch associates files with the new paths This part is debated with upstream Fixes: #49011 Status wrt upstream: Meant to be forwarded upstream (a good rationale about FHS is probably recommended) Note: Use dedicated directories for: - discardable cache data (/var/cache/samba): browse.dat, printers.tbd, printer.tdb - non discardable state data: all TDB files that may need to be backed up - shared data (/usr/share/samba): codepage stuff This patch needs work to be cleaner wrt people who want to run multiple instances of samba The patch *must* be reviewed after every new upstream release. FAILURE TO DO SO MAY RESULT IN DATA LOSS FOR OUR USERS! export QUILT_PATCHES=debian/patches quilt push fhs.patch grep -r lock_path source/ | grep -vE \ '((brlock|connections|gencache|locking|messages|notify|sessionid|unexpected|wins)\.tdb|namelist.debug|lang_)|char \*lock_path|WINBINDD_PRIV_SOCKET_SUBDIR' - This will get you the list of any new, unexpected references to lock_path. The files mentioned above are the known good uses of lock_path; everything else needs to be investigated. - If the file name occurs elsewhere in the fhs.patch, update the patch to fix these new references to the same place (either cache_path or state_path) - If the file is a tdb file, and the code that opens it uses TDB_CLEAR_IF_FIRST, lock_path is correct; just update the query above with the new filename, no other changes are needed. - Otherwise, if this is the first use of the file, you must determine where the file belongs -- i.e., whether it's persistent data, a cache, or runtime-only data. Consult upstream if necessary. - Repeat these steps for lp_lockdir(), which is less common but still used in the code. grep -r lp_lockdir source/ | grep -vE \ '%s/smb_(tmp_)*krb5|source/(lib/util|param/loadparm|dynconfig|utils/testparm)\.c|WINBINDD_PRIV_SOCKET_SUBDIR|(directory_exist|mkdir)\(lp_lockdir\(\),|koplock\.%d|%s/sync\.%d' Index: samba-3.2.0pre3/source/lib/util.c === --- samba-3.2.0pre3.orig/source/lib/util.c +++ samba-3.2.0pre3/source/lib/util.c .../... As one sees, we have 4 pseudo-headers: Goal: describe what the package is meant to do Fixes: what Debian bug it fixes Status wrt upstream: reported or not ? Sometimes mentions Debian specific for cases where there is no point in applying it to pristine upstream (for instance when we patch manpages to say In Debian, blahblah Notes: more information (in this specific case, how to refresh this patch which is tricky) So far, this has proven very useful for the duty we have to forward such patches to upstream. Several of these patches are marked as forwarded upstream as Bug # signature.asc Description: Digital signature
Accepted bouml 4.3.3-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 15 May 2008 21:35:24 +0200 Source: bouml Binary: bouml bouml-plugouts-src Architecture: source all amd64 Version: 4.3.3-1 Distribution: unstable Urgency: low Maintainer: Thomas Girard [EMAIL PROTECTED] Changed-By: Thomas Girard [EMAIL PROTECTED] Description: bouml - UML2 tool box to specify and generate code bouml-plugouts-src - UML2 tool box to specify and generate code (plugouts sources) Closes: 481219 Changes: bouml (4.3.3-1) unstable; urgency=low . * New upstream release. Closes: #481219. * Use quilt make fragment. * Do not blindly apply patches in clean: target. Checksums-Sha1: df080a56c3ebb2fbc0a8b4d852ea1f74af31cf2d 1145 bouml_4.3.3-1.dsc 4560ce76bdbb711c300e12a8646a07c7de7b2491 4604091 bouml_4.3.3.orig.tar.gz 856d3f3f774c63098813716517d3a389658522bb 12995 bouml_4.3.3-1.diff.gz a347cd303cf6fe1ed351920464004810263d522a 2136122 bouml-plugouts-src_4.3.3-1_all.deb a502c613f5155a18552d0efa2bf2e2492cab25bb 4727354 bouml_4.3.3-1_amd64.deb Checksums-Sha256: a8ae03894cf677b0d1e8b6d120752106517267ffabf0f0011c54232dce7f848d 1145 bouml_4.3.3-1.dsc 9b7f6f92831f62761bb3f4cabe8a226b95a4b8ae6b49ecf2cbacb9e8fde9dabd 4604091 bouml_4.3.3.orig.tar.gz 3e018a7b5c7a66bc5bccf86225911f871f43cae8fc2710e807719b838e5ee541 12995 bouml_4.3.3-1.diff.gz 6276d8bc65af59f7779440fe1cf4fa86e542c6845ce80da02aa9d12b927fbabb 2136122 bouml-plugouts-src_4.3.3-1_all.deb 8132086104edaebda4609514b43f5c1da78817c0d53bc08291d51a1846d5eac6 4727354 bouml_4.3.3-1_amd64.deb Files: 9c74e961765638d103bcbaaf774e2795 1145 devel optional bouml_4.3.3-1.dsc 96ce9ae9ced102f3293ea75ced1aed3f 4604091 devel optional bouml_4.3.3.orig.tar.gz 8d8bf9f3b79a0f3e121c818d41d7bb73 12995 devel optional bouml_4.3.3-1.diff.gz f756a75a067556e098ab41bb069b5b27 2136122 devel optional bouml-plugouts-src_4.3.3-1_all.deb 0d911c4aadaa1fa46aea733992393621 4727354 devel optional bouml_4.3.3-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILRmmz2LXlDjmjg4RAkkPAJ495A03x9hiJVW3HErrg4AxrjgGeACfRpPa XWJnP/f7/9eBkqJmlN5rJLM= =ggzH -END PGP SIGNATURE- Accepted: bouml-plugouts-src_4.3.3-1_all.deb to pool/main/b/bouml/bouml-plugouts-src_4.3.3-1_all.deb bouml_4.3.3-1.diff.gz to pool/main/b/bouml/bouml_4.3.3-1.diff.gz bouml_4.3.3-1.dsc to pool/main/b/bouml/bouml_4.3.3-1.dsc bouml_4.3.3-1_amd64.deb to pool/main/b/bouml/bouml_4.3.3-1_amd64.deb bouml_4.3.3.orig.tar.gz to pool/main/b/bouml/bouml_4.3.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ttf-arphic-uming 0.2.20080216.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 10:17:34 +0800
Source: ttf-arphic-uming
Binary: ttf-arphic-uming
Architecture: source all
Version: 0.2.20080216.1-1
Distribution: unstable
Urgency: low
Maintainer: Arne Goetje [EMAIL PROTECTED]
Changed-By: Arne Goetje [EMAIL PROTECTED]
Description:
ttf-arphic-uming - AR PL UMing Chinese Unicode TrueType font collection
Mingti sty
Closes: 423720 425024 436531 442612 457417 457420
Changes:
ttf-arphic-uming (0.2.20080216.1-1) unstable; urgency=low
.
* new upstream release
* fixed a typo in debian/prerm (LP: #194129)
* debian/control: changed Architecture from 'any' to 'all' (LP: #194168)
* fixed typo in package description (Closes: #442612)
* corrected homepage URL in control and changelog (Closes: #423720, #436531)
* added Homepage field in debian/control
* use bzip2 compression
* bumped up the Standards version to 3.7.3
* updated package description in debian/control
* purge debconf entries and removed template and translations, as they are
no longer needed.
* use cdbs to build package
* remove Provides: ttf-arphic-bsmi00lp and ttf-arphic-gbsn00lp entries
Copied from FONTLOG:
* Bug fix: 45 Big5 PUA glyphs and 4 HKSCS PUA glyphs have not been assigned
codepoints -- FIXED.
* Bug fix: the bitmap glyphs got lost due to a fontforge bug. -- FIXED
* Remaining issue: some glyph splines in the unencoded section got lost
when building the ttc file. -- INVESTIGATING
* resized all glyphs back to an em-size of 1024 like they were originally.
This also fixed the bug, that the glyphs and lines were too high.
The previous em-size was 2098, while it should have been 2048.
* completely reworked all Latin based glyphs (thanks to Maurizio M. Gavioli)
* changed the Latin, Greek and Cyrillic based glyphs back to Monospace
* added 1553 glyphs and references
* compile font as TrueType Collection (TTC):
contains 4 font flavors (CN, HK, TW, TW MBE) which map to different glyph
styles. Currently this is only a proof of concept with only 2 codepoints
(U+4EE4 and U+9AA8) between CN, HK and TW flavors and 13 different glyphs
between the TW and TW MBE flavors. All other glyphs are exactly the same
in all flavors.
* debugged a lot of glyphs which had intersecting splines.
* moved all glyphs from the PUA areas into unencoded space and only map
those to the BMP PUA where it's necessary for roundtrip compatibility
(i.e. the HKSCS PUA references only appear in the HK flavor, Big5
references in HK, TW and TW MBE, and the GB18030-2000 references in the
CN flavor.
* added all outstanding PUA references for HKSCS to be compatible back to
HKSCS in ISO 10646-1:1993
* Name change: from AR PL ShanHeiSun Uni (MBE) to
AR PL UMing {CN|HK|TW|TW MBE}.
For backwards compatibility alias entries are defined to map
AR PL ShanHeiSun Uni to AR PL UMing HK and AR PL ShanHeiSun Uni MBE
to AR PL UMing TW MBE.
* split the fontconfig configuration file into 6 (LP: #175972) (Closes:
#457420, #457417) :
* 25-ttf-arphic-uming-render: fixes globaladvance and sets the font to be
dual-width
* 25-ttf-arphic-uming-bitmaps: enables embedded bitmaps
* 35-ttf-arphic-uming-aliases: alias entries for
AR PL ShanHeiSun Uni (MBE)
* 41-ttf-arphic-uming.conf: binds font to Serif, Sans and Monospace
* 64-ttf-arphic-uming.conf: alias settings for Serif, Sans and Monospace
(Closes: #425024)
* 90-ttf-arphic-uming-embolden.conf: emboldens the font
* Changed the font information to advertise itself as Light style. (LP:
#57578)
Checksums-Sha1:
d30a5544b6c25c3ff110a7563140574bb64ea8d6 1158
ttf-arphic-uming_0.2.20080216.1-1.dsc
d6b11cc84142364c66d17a0f02fdffbc1b98cedf 10684442
ttf-arphic-uming_0.2.20080216.1.orig.tar.gz
90657edb4b24ce049e5cf2e5fb8110e6d42cc2ba 9991
ttf-arphic-uming_0.2.20080216.1-1.diff.gz
ab991c359c628f26ddd4eef297c284e40f7ae491 9678054
ttf-arphic-uming_0.2.20080216.1-1_all.deb
Checksums-Sha256:
5d3b34573e3b2e5fa3f4337c2241a8d216c4a0e91ea10ca012ef8971e700f0d8 1158
ttf-arphic-uming_0.2.20080216.1-1.dsc
8038a6db9e832456d5da5559aff8d15130243be1091bf24f3243503a6f1bda98 10684442
ttf-arphic-uming_0.2.20080216.1.orig.tar.gz
2db9cc5f7a9a10956a3347e1e737ff98af250fa321d6d2e3755d5f6f8a8cf946 9991
ttf-arphic-uming_0.2.20080216.1-1.diff.gz
061289160a7d8c8a5e8c473d1f1e328dd03f4a01671c820c51fe5791cd6187d3 9678054
ttf-arphic-uming_0.2.20080216.1-1_all.deb
Files:
ed3d44bc4cfdd6bfbaf349e645f0991b 1158 x11 optional
ttf-arphic-uming_0.2.20080216.1-1.dsc
d219fcaf953f3eb1889399955a00379f 10684442 x11 optional
ttf-arphic-uming_0.2.20080216.1.orig.tar.gz
b23a8094f7b96817be5d8b89a4fd9244 9991 x11 optional
ttf-arphic-uming_0.2.20080216.1-1.diff.gz
ff5e9134d27bf35907365b6d48a09ed8 9678054 x11 optional
ttf-arphic-uming_0.2.20080216.1-1_all.deb
-BEGIN
Accepted latencytop 0.4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 16 May 2008 08:23:03 +0200 Source: latencytop Binary: latencytop Architecture: source i386 Version: 0.4 Distribution: unstable Urgency: low Maintainer: Giacomo Catenazzi [EMAIL PROTECTED] Changed-By: Giacomo Catenazzi [EMAIL PROTECTED] Description: latencytop - A tool for developers to visualize system latencies Closes: 476769 Changes: latencytop (0.4) unstable; urgency=low . * New upstream version (added block trace) * add options and keybinding to manpage (Closes: #476769) Checksums-Sha1: a8c0d87b5244b0a1c945e5ebc7cb92277ac8039f 1020 latencytop_0.4.dsc 4526ed5d86bc341a8abdb7fe17313f993c4d9f15 9606 latencytop_0.4.orig.tar.gz ba7c15e81c0a34412ab682908631a82a8b65d8cf 3442 latencytop_0.4.diff.gz 614a2fecc6b57d07552e79e928b95cd8255b6915 14216 latencytop_0.4_i386.deb Checksums-Sha256: cd520ee8ba384999d77a1f629c48d01e4df563280e2226ed037a8aa790e9b48d 1020 latencytop_0.4.dsc 4c5bb829390f266f6ba4430b725a4210d7e71d96168731dfd790c0f945c317b8 9606 latencytop_0.4.orig.tar.gz 5052486ab080b3147e259aa7be4ba7f0cafef6f1d4d1975afdfa63df54c1b742 3442 latencytop_0.4.diff.gz 8492de37dc7c0184886ec8ce4538c5f3173ad3c1f9df344c327d0f6ade1220cf 14216 latencytop_0.4_i386.deb Files: e0c7d48f7446bacc65e70c6f7941ecf6 1020 utils extra latencytop_0.4.dsc ad8d107699608b024d697c941371bb37 9606 utils extra latencytop_0.4.orig.tar.gz bae634cd9b73d6cbd6a5a41af25a90c9 3442 utils extra latencytop_0.4.diff.gz a1e450f15ed62e6ffef3d898f19e1db4 14216 utils extra latencytop_0.4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILSjl+ZNUJLHfmlcRAkBzAJ9Q4wZatkDfL4DxcRbXJDzPknTp7wCffXCG MK7lHtCCkjPOxmpfslXAY0U= =EyZF -END PGP SIGNATURE- Accepted: latencytop_0.4.diff.gz to pool/main/l/latencytop/latencytop_0.4.diff.gz latencytop_0.4.dsc to pool/main/l/latencytop/latencytop_0.4.dsc latencytop_0.4.orig.tar.gz to pool/main/l/latencytop/latencytop_0.4.orig.tar.gz latencytop_0.4_i386.deb to pool/main/l/latencytop/latencytop_0.4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ttf-arphic-ukai 0.2.20080216.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 15 May 2008 10:25:35 +0800
Source: ttf-arphic-ukai
Binary: ttf-arphic-ukai
Architecture: source all
Version: 0.2.20080216.1-1
Distribution: unstable
Urgency: low
Maintainer: Arne Goetje [EMAIL PROTECTED]
Changed-By: Arne Goetje [EMAIL PROTECTED]
Description:
ttf-arphic-ukai - AR PL UKai Chinese Unicode TrueType font collection Kaiti
style
Closes: 435180 436530 442606 451974
Changes:
ttf-arphic-ukai (0.2.20080216.1-1) unstable; urgency=low
.
* New upstream release
* fixed a typo in debian/prerm (LP: #194128)
* debian/control: changed Architecture fro 'any' to 'all' (LP: #194168)
* fixed typo in package description (Closes: #442606)
* corrected homepage URL in control and changelog (Closes: #436530)
* added Homepage field to debian/control
* use bzip2 compression
* bumped up the Standards version to 3.7.3
* updated package description in debian/control
* purge debconf entries and removed template and translations, as they are
no longer needed. (Closes: #435180)
* use cdbs to build package
* remove Provides: ttf-arphic-gkai00mp and ttf-arphic-kai00mp entries
(Closes: #451974)
Copied from FONTLOG:
* Bug fix: 45 Big5 PUA glyphs and 4 HKSCS PUA glyphs have not been assigned
codepoints -- FIXED.
* resized all glyphs back to an em-size of 1024 like they were originally.
This also fixed the bug, that the glyphs and lines were too high.
The previous em-size was 2098, while it should have been 2048.
* completely reworked all Latin based glyphs (thanks to Maurizio M. Gavioli)
* changed the Latin, Greek and Cyrillic based glyphs back to Monospace
* added 1214 glyphs and references
* compile font as TrueType Collection (TTC):
contains 4 font flavors (CN, HK, TW, TW MBE) which map to different glyph
styles. Currently this is only a proof of concept with only 2 codepoints
(U+4EE4 and U+9AA8) between CN, HK and TW flavors and 13 different glyphs
between the TW and TW MBE flavors. All other glyphs are exactly the same
in all flavors.
* debugged a lot of glyphs which had intersecting splines. However, this
process has not been finished yet.
* moved all glyphs from the PUA areas into unencoded space and only map
those to the BMP PUA where it's necessary for roundtrip compatibility
(i.e. the HKSCS PUA references only appear in the HK flavor, Big5
references in HK, TW and TW MBE, and the GB18030-2000 references in the
CN flavor.
* added all outstanding PUA references for HKSCS to be compatible back to
HKSCS in ISO 10646-1:1993
* Name change: from AR PL ZenKai Uni (MBE) to AR PL UKai {CN|HK|TW|TW MBE}.
For backwards compatibility alias entries are defined to map
AR PL ZenKai Uni to AR PL UKai HK and AR PL ZenKai Uni MBE to
AR PL UKai TW MBE.
* split the fontconfig configuration file into 5:
* 25-ttf-arphic-ukai-render: fixes globaladvance and sets the font to be
dual-width
* 35-ttf-arphic-ukai-aliases: alias entries for AR PL ZenKai Uni (MBE)
* 41-ttf-arphic-ukai.conf: alias settings for Sans
* 75-ttf-arphic-ukai-select: puts AR PL UKai * into 'rejectfont', so
that the fonts don't get automatically chosen by fontconfig.
* 90-ttf-arphic-ukai-embolden.conf: emboldens the font
Checksums-Sha1:
d61263675de532f070cbbd7abef26ce327ce2434 1150
ttf-arphic-ukai_0.2.20080216.1-1.dsc
70f9489e7e15241c13d7eb6496a38736b49024e6 10336387
ttf-arphic-ukai_0.2.20080216.1.orig.tar.gz
e5e190b05155624b0b1c424ebb4d0773eb240e79 9751
ttf-arphic-ukai_0.2.20080216.1-1.diff.gz
18c98e01eea7139a45057621342bfab485399eae 9677496
ttf-arphic-ukai_0.2.20080216.1-1_all.deb
Checksums-Sha256:
3b535c50ce5746e730ca458351a1d366d8bcc3efdfcdaf3f2cb2b4d769b69a42 1150
ttf-arphic-ukai_0.2.20080216.1-1.dsc
0ea93b3efdd3bb71026bc545479e34ce14263a9faa20e1ac124bcf7315d19f4a 10336387
ttf-arphic-ukai_0.2.20080216.1.orig.tar.gz
aadaff7591736e2701008ffb91242ffc538bc5b4eeded22f01fb7d7b74f0ce2e 9751
ttf-arphic-ukai_0.2.20080216.1-1.diff.gz
f46e983174a66d8fc8fe1ee54400452f1f29c9ba7c80d57a13dd5ac0a74ac39f 9677496
ttf-arphic-ukai_0.2.20080216.1-1_all.deb
Files:
a85da67b2cc57a58d5caafad9b184994 1150 x11 optional
ttf-arphic-ukai_0.2.20080216.1-1.dsc
4d3beb55db000bfedd18c9c7d6e631d8 10336387 x11 optional
ttf-arphic-ukai_0.2.20080216.1.orig.tar.gz
8e08775eafec779e3c35da3c1be060f1 9751 x11 optional
ttf-arphic-ukai_0.2.20080216.1-1.diff.gz
7e5a1a48bf2612ba1f9a1227301e0aaf 9677496 x11 optional
ttf-arphic-ukai_0.2.20080216.1-1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFILRvB1OXtrMAUPS0RAh+LAJ0ZrwNrZBljqTpP57KF7OS/lmnQvgCgoi3G
AHZxfJtUIZ1InIS/h0mdliA=
=KnjL
-END PGP SIGNATURE-
Accepted:
ttf-arphic-ukai_0.2.20080216.1-1.diff.gz
to pool/main/t/ttf-arphic-ukai/ttf-arphic-ukai_0.2.20080216.1-1.diff.gz
ttf-arphic-ukai_0.2.20080216.1-1.dsc
to
Accepted ecryptfs-utils 45-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 08:22:00 +0200 Source: ecryptfs-utils Binary: ecryptfs-utils libecryptfs0 libecryptfs-dev Architecture: source i386 Version: 45-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: ecryptfs-utils - ecryptfs cryptographic filesystem (utilities) libecryptfs-dev - ecryptfs cryptographic filesystem (development) libecryptfs0 - ecryptfs cryptographic filesystem (library) Changes: ecryptfs-utils (45-1) unstable; urgency=low . * Merging upstream version 45. Checksums-Sha1: 879014ee5278168f8f3a619162512b2405e27259 1388 ecryptfs-utils_45-1.dsc af1209e15310711e317389b080d8c0fa572b15a8 1115566 ecryptfs-utils_45.orig.tar.gz 63733865a048743977f11cb75c143e4de6ddaf7b 3702 ecryptfs-utils_45-1.diff.gz 26a68f582c406662488a7178b884b915d3594cf3 347848 ecryptfs-utils_45-1_i386.deb 842faa9ef03cbc122a3c00f57a3a51fa06b6c06f 59882 libecryptfs0_45-1_i386.deb 563e766ec69ef7130f6667d14f41f20dd92fc3b4 43132 libecryptfs-dev_45-1_i386.deb Checksums-Sha256: 976fcffdb2bf9696ed3366e41ebd79f264c58e32f2478f009fe5fa2d20b68dbc 1388 ecryptfs-utils_45-1.dsc 2c4ebd490b6f47603bfe502f1abb75e27109f816c840a9a0b32a96f8ad88f8f9 1115566 ecryptfs-utils_45.orig.tar.gz fa04f0c94cba98dcdd68678f1ce9ddfdf51b26ce6c9613382dd05d2578bd47c5 3702 ecryptfs-utils_45-1.diff.gz ff53bf84e58d577ac80965b5b1af4cc712f51af7fce7730dfebd98bdfdc50550 347848 ecryptfs-utils_45-1_i386.deb 751eff6dea05a467c7326d878defab554399365547792c4f5bc345036602b2ae 59882 libecryptfs0_45-1_i386.deb 0b7711365f241349db8d24405e17aa691db2c5845e6a60780410ec2ea71e0ec0 43132 libecryptfs-dev_45-1_i386.deb Files: f31e4963108f40387bd82fad3d87105f 1388 misc optional ecryptfs-utils_45-1.dsc 69ed60cae78d74df7a1ce22881ee3a3e 1115566 misc optional ecryptfs-utils_45.orig.tar.gz fa639bff54baf91a5e107b73029f76e2 3702 misc optional ecryptfs-utils_45-1.diff.gz b33073dd48b6db6acba68a6ec06d22bf 347848 misc optional ecryptfs-utils_45-1_i386.deb 9c23b34f2c0ba8eaf373395afd9d1f8c 59882 libs optional libecryptfs0_45-1_i386.deb e8c8afe8c8a1ef4a9d69fb4c9a260c5e 43132 libdevel optional libecryptfs-dev_45-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILSiz+C5cwEsrK54RAhmGAKDTc0aJCWzf9SdRRZDadALBZvyGBQCgn9Y2 7A55LVhhSfAcT+BmZMLLmtM= =03hr -END PGP SIGNATURE- Accepted: ecryptfs-utils_45-1.diff.gz to pool/main/e/ecryptfs-utils/ecryptfs-utils_45-1.diff.gz ecryptfs-utils_45-1.dsc to pool/main/e/ecryptfs-utils/ecryptfs-utils_45-1.dsc ecryptfs-utils_45-1_i386.deb to pool/main/e/ecryptfs-utils/ecryptfs-utils_45-1_i386.deb ecryptfs-utils_45.orig.tar.gz to pool/main/e/ecryptfs-utils/ecryptfs-utils_45.orig.tar.gz libecryptfs-dev_45-1_i386.deb to pool/main/e/ecryptfs-utils/libecryptfs-dev_45-1_i386.deb libecryptfs0_45-1_i386.deb to pool/main/e/ecryptfs-utils/libecryptfs0_45-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octave-image 1.0.6-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 09:45:51 +0200 Source: octave-image Binary: octave-image Architecture: source i386 Version: 1.0.6-2 Distribution: unstable Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Thomas Weber [EMAIL PROTECTED] Description: octave-image - image manipulation for Octave Closes: 481399 Changes: octave-image (1.0.6-2) unstable; urgency=low . * Add OR relationship between graphicsmagick-imagemagick-compat and imagemagick (closes: #481399) Checksums-Sha1: 04c72c91d48ceffec496b63742054362ee8232d1 1437 octave-image_1.0.6-2.dsc a063ae59c8158478242d10881a37946b338139f9 2518 octave-image_1.0.6-2.diff.gz cc7be1a277e28859b1d2e3a1368a9539c62fe68e 324896 octave-image_1.0.6-2_i386.deb Checksums-Sha256: 7e72f494ef51b307eaa51ea87b4b77198c3032eed0829b8abd925a254360d3a4 1437 octave-image_1.0.6-2.dsc b00f416fab39255d277edc9c49f94303217b4523c1fe56e268affe5427b02aaa 2518 octave-image_1.0.6-2.diff.gz 0cbf338a113cbda3fdaffb9f77b5843a010195ce094c808e7b06abd0b0349205 324896 octave-image_1.0.6-2_i386.deb Files: 332bc0afefe6331439dfe1abbca2c9ae 1437 math optional octave-image_1.0.6-2.dsc 558fa2ea4f125ec3a24becece5f03e7d 2518 math optional octave-image_1.0.6-2.diff.gz 7c444e888d441f35b39a0d13d9048e99 324896 math optional octave-image_1.0.6-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILTzzPqD4a3lPnXwRAizSAJ9SsP1UAnPogyB/7OTIJVioEFCPAQCfTKlm QmpjG/5nCcqV3wMYG5kS2q4= =ddux -END PGP SIGNATURE- Accepted: octave-image_1.0.6-2.diff.gz to pool/main/o/octave-image/octave-image_1.0.6-2.diff.gz octave-image_1.0.6-2.dsc to pool/main/o/octave-image/octave-image_1.0.6-2.dsc octave-image_1.0.6-2_i386.deb to pool/main/o/octave-image/octave-image_1.0.6-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pygobject 2.14.1-5 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 15 May 2008 14:56:58 +0200 Source: pygobject Binary: python-gobject python-gobject-dev python-gobject-dbg Architecture: source all i386 Version: 2.14.1-5 Distribution: unstable Urgency: low Maintainer: Josselin Mouette [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: python-gobject - Python bindings for the GObject library python-gobject-dbg - Python bindings for the GObject library (debug extension) python-gobject-dev - Development headers for the GObject Python bindings Changes: pygobject (2.14.1-5) unstable; urgency=low . * New patch, 61_wakeupfd-fix, from the fix to the initial SETWAKEUPFD support in GNOME #481569. Checksums-Sha1: b33759943735ec902c0d34fd734ac9701f77b201 1410 pygobject_2.14.1-5.dsc 259021c3428c3eec51d78cc4d195e56846b290bb 45098 pygobject_2.14.1-5.diff.gz 69e47ff3dd075bd9315ad090ca7c41fe4620f155 52452 python-gobject-dev_2.14.1-5_all.deb 81cb474524daa5e404f27248961d1979e222a21d 157208 python-gobject_2.14.1-5_i386.deb 54e0e6578d428d861b46b581dd2a25f2380d8d8e 632644 python-gobject-dbg_2.14.1-5_i386.deb Checksums-Sha256: 3ba48ff0962297bce7873e48bab4aaf95ec5310940919e98cc59253cc222a331 1410 pygobject_2.14.1-5.dsc b446d0a5a4b80723f5615a3189464b9976a5e4830fa21ca9bcc4f105f0a7647a 45098 pygobject_2.14.1-5.diff.gz 59c3fac57d1bad691095908bd57a9a5e8c364af50f266a777c51862cb93de2a4 52452 python-gobject-dev_2.14.1-5_all.deb 5ab0f9817e89bec25e627cc2c8b8d376dffc7ea0529f6b8d9c9a3a637169c4f8 157208 python-gobject_2.14.1-5_i386.deb 103a98cadc207c1ea949fc7c4293ebbe513ca695de069404b490de554f4dffe6 632644 python-gobject-dbg_2.14.1-5_i386.deb Files: cb5a69d1df9073945013253743afdafe 1410 python optional pygobject_2.14.1-5.dsc 710df96b5f1df3c8c118b04180bd2faf 45098 python optional pygobject_2.14.1-5.diff.gz 4ed4e8f01dca530ce8a257080b3cd2a0 52452 python optional python-gobject-dev_2.14.1-5_all.deb f4966eaa29c527222d114eba194a28ef 157208 python optional python-gobject_2.14.1-5_i386.deb a6dcdb3b80d8a3db443df55098710159 632644 python extra python-gobject-dbg_2.14.1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILDb74VUX8isJIMARAo59AJ9165itkXRu3/YyaA7wOgLAg/oulwCcCuqE qE3/fLxR01YAeaaKxONymXA= =ZvaF -END PGP SIGNATURE- Accepted: pygobject_2.14.1-5.diff.gz to pool/main/p/pygobject/pygobject_2.14.1-5.diff.gz pygobject_2.14.1-5.dsc to pool/main/p/pygobject/pygobject_2.14.1-5.dsc python-gobject-dbg_2.14.1-5_i386.deb to pool/main/p/pygobject/python-gobject-dbg_2.14.1-5_i386.deb python-gobject-dev_2.14.1-5_all.deb to pool/main/p/pygobject/python-gobject-dev_2.14.1-5_all.deb python-gobject_2.14.1-5_i386.deb to pool/main/p/pygobject/python-gobject_2.14.1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted telepathy-gabble 0.7.6-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 12:41:16 +0200 Source: telepathy-gabble Binary: telepathy-gabble telepathy-gabble-dbg Architecture: source amd64 Version: 0.7.6-1 Distribution: unstable Urgency: low Maintainer: Debian Telepathy maintainers [EMAIL PROTECTED] Changed-By: Sjoerd Simons [EMAIL PROTECTED] Description: telepathy-gabble - Jabber/XMPP connection manager telepathy-gabble-dbg - Jabber/XMPP connection manager Changes: telepathy-gabble (0.7.6-1) unstable; urgency=low . * New upstream release * debian/control: Up telepathy-glib build-depend to 0.7.8 * debian/patches/00-no-call-state.diff: + Removed. Not relevant anymore Checksums-Sha1: 2e88ff4f66bfbe51fee7afbe1f85db03490112e6 1600 telepathy-gabble_0.7.6-1.dsc b17ec055e43133b2d6aeacf949e1433f1b513ed6 827316 telepathy-gabble_0.7.6.orig.tar.gz 8ad9477688a8d95ac3c44c4eef958f7a79554ee8 6395 telepathy-gabble_0.7.6-1.diff.gz cd122d7a8b2ea5e927f32f8c48e5939f2438cd3a 361330 telepathy-gabble_0.7.6-1_amd64.deb b87dac7386bdfe26aa6a4040a52b654fa546d7e0 387418 telepathy-gabble-dbg_0.7.6-1_amd64.deb Checksums-Sha256: 930a159038f280acf455354905f650751818567ad1544a9536cece090c3cd6ae 1600 telepathy-gabble_0.7.6-1.dsc 9ce73e484b2f2858d46ffea9893f9823b5de9c7310f7c26b027f73a1c8fde857 827316 telepathy-gabble_0.7.6.orig.tar.gz cfc54df73376334d14b16de05588115b4264737f3fe277ec5a2da52c09a7d9ae 6395 telepathy-gabble_0.7.6-1.diff.gz 5357edc6265f8c91131384e302fb8c0b30c8b608a2ee2cc4405efa91bd850fcb 361330 telepathy-gabble_0.7.6-1_amd64.deb 0c22133c07cffbcd25a8b464009c1f35c3a52feb2c245d9c524bb06138c30abf 387418 telepathy-gabble-dbg_0.7.6-1_amd64.deb Files: 709f445091ed1dfdb6a7a131e797914e 1600 net optional telepathy-gabble_0.7.6-1.dsc 17564dcb79d886d527609c154834c1c7 827316 net optional telepathy-gabble_0.7.6.orig.tar.gz 95510fc42b35176d62752a64c6bd327e 6395 net optional telepathy-gabble_0.7.6-1.diff.gz f0b4f28fad37282058be8330ea1fdf39 361330 net optional telepathy-gabble_0.7.6-1_amd64.deb 3a995c0fc350eab562467d6510d40dd6 387418 net extra telepathy-gabble-dbg_0.7.6-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILWtPgTd+SodosdIRAh5FAKDot+cXf55xzKonP/XsiMNF+f0POwCfTtAl uALtH8u9rGLZZ9YLpmO99WY= =gmAM -END PGP SIGNATURE- Accepted: telepathy-gabble-dbg_0.7.6-1_amd64.deb to pool/main/t/telepathy-gabble/telepathy-gabble-dbg_0.7.6-1_amd64.deb telepathy-gabble_0.7.6-1.diff.gz to pool/main/t/telepathy-gabble/telepathy-gabble_0.7.6-1.diff.gz telepathy-gabble_0.7.6-1.dsc to pool/main/t/telepathy-gabble/telepathy-gabble_0.7.6-1.dsc telepathy-gabble_0.7.6-1_amd64.deb to pool/main/t/telepathy-gabble/telepathy-gabble_0.7.6-1_amd64.deb telepathy-gabble_0.7.6.orig.tar.gz to pool/main/t/telepathy-gabble/telepathy-gabble_0.7.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted idjc 0.7.5-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 11:50:12 +0100 Source: idjc Binary: idjc Architecture: source amd64 Version: 0.7.5-4 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Team [EMAIL PROTECTED] Changed-By: Free Ekanayaka [EMAIL PROTECTED] Description: idjc - graphical shoutcast/icecast client Changes: idjc (0.7.5-4) unstable; urgency=low . * Build against liblame-dev if available or toolame otherwise Checksums-Sha1: 7bbaf21bdd5a01e1742df8db9f254de99309a5e8 1272 idjc_0.7.5-4.dsc b6e5ce625f2088b2471e0f4f759b93fafa99b39e 5238 idjc_0.7.5-4.diff.gz 999ca4ae90041cf8fea35679cbd2b4a0ba14d785 856536 idjc_0.7.5-4_amd64.deb Checksums-Sha256: 4923047afddb432ba2319f9f18e0dc447b0225801b24f792137ab39f63023fec 1272 idjc_0.7.5-4.dsc 01ca93dc631de2b469f9c7b3eda09b4843da2b6d957797567234d7b22698bbcf 5238 idjc_0.7.5-4.diff.gz 0eebc65a5e0abfa5783a904c2feed914f23dcd93ce6aedb6e6ba3d68b761002f 856536 idjc_0.7.5-4_amd64.deb Files: bb40ced454845cacef412b8c6c35198e 1272 sound optional idjc_0.7.5-4.dsc 80254ddb5cd3792ea6fdb560f8f8f750 5238 sound optional idjc_0.7.5-4.diff.gz 0ffdcb326df809e5aeea3248fb073f5a 856536 sound optional idjc_0.7.5-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILWkfcanJGlcVnlkRApODAJ0azwq+j0So3NRF96IbhjbILRIJBACfT4OU UeBIcCnFyVdew9wO8xzxo4k= =6jG2 -END PGP SIGNATURE- Accepted: idjc_0.7.5-4.diff.gz to pool/main/i/idjc/idjc_0.7.5-4.diff.gz idjc_0.7.5-4.dsc to pool/main/i/idjc/idjc_0.7.5-4.dsc idjc_0.7.5-4_amd64.deb to pool/main/i/idjc/idjc_0.7.5-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted emboss 5.0.0-7 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 19:58:37 +0900 Source: emboss Binary: emboss emboss-data emboss-doc emboss-lib libajax5 libajax5-dev libnucleus5 libnucleus5-dev Architecture: source powerpc all Version: 5.0.0-7 Distribution: unstable Urgency: low Maintainer: Debian-Med Packaging Team [EMAIL PROTECTED] Changed-By: Charles Plessy [EMAIL PROTECTED] Description: emboss - The European Molecular Biology Open Software Suite emboss-data - Data files for the EMBOSS package emboss-doc - Documentation for EMBOSS emboss-lib - EMBOSS Libraries libajax5 - EMBOSS library for commands libajax5-dev - Development files for libajax libnucleus5 - EMBOSS library for molecular sequence analysis libnucleus5-dev - Development files for libajax Changes: emboss (5.0.0-7) unstable; urgency=low . * Changed the doc-base section according to the new policy. * Updated my email address. * Updated the contact address in the manpages. Checksums-Sha1: fd9620f25309fffaaeac15e9d46bd64ec7644a92 1507 emboss_5.0.0-7.dsc ce0fe49f38e5417994f9117501eb45e0fd712d58 250072 emboss_5.0.0-7.diff.gz 2c058e9e697e517ab307594a8a1c2fc72e1e49b3 1079388 emboss_5.0.0-7_powerpc.deb 991678e10cc52b0f7bdb73de40354bcd600ef3a0 648800 emboss-data_5.0.0-7_all.deb c3fb9e63fa43b427d5c8ba2070cf905490d89719 4514124 emboss-doc_5.0.0-7_all.deb 88616abf475227384ba16659b521b529adbb2334 455742 emboss-lib_5.0.0-7_powerpc.deb 06382a0288bb5c0a7fb3eeb335ef3f4efe086b7c 737014 libajax5_5.0.0-7_powerpc.deb 4d09700f92bbfe682d1818ae533abc19889da175 927724 libajax5-dev_5.0.0-7_powerpc.deb 6d78cb22b68f8e89f82f180f27487619a880f774 196730 libnucleus5_5.0.0-7_powerpc.deb f951fe1b3ce000a1ca7e6de2723f9a0c08b0 220104 libnucleus5-dev_5.0.0-7_powerpc.deb Checksums-Sha256: 1a1ebac4e88690db77efcd94d968ab2a943304c994d5a067434a5df528a6bfa3 1507 emboss_5.0.0-7.dsc 9d929110a37355cb8f15c9e59e314675288006fd0f2f1fc36cca0d8cf8655a20 250072 emboss_5.0.0-7.diff.gz 190de33aab231bc4c50765673053d170e6a96a623267258a8434e1773b0c1f61 1079388 emboss_5.0.0-7_powerpc.deb 2b3a3f4aca733c9bca3677bd1dbf48f6b07b90a19c1db973764ed113d9577a8c 648800 emboss-data_5.0.0-7_all.deb 46dffc0846e6aaf359bdb22d0347a1dd587673d1276a969dec3058cb917ada44 4514124 emboss-doc_5.0.0-7_all.deb 87979edf26e1f406000ac4b0f2875cc2fe09b069f8658ecab040ae217cfb5a67 455742 emboss-lib_5.0.0-7_powerpc.deb 369fb8b72808ca21e5738d8f96da568bbe28ca4941e62dcdf1f42a1f7296eab1 737014 libajax5_5.0.0-7_powerpc.deb 7b66b29c94fcd9c760e48935ba7e9b701ae9e140c70f16edb4250f47deebe13a 927724 libajax5-dev_5.0.0-7_powerpc.deb d869c47f707f1be0dd7b8dee159aa87ce6cf69c27295b3186e206d09a347e6b8 196730 libnucleus5_5.0.0-7_powerpc.deb 290351a20a132ddc28dab3a45eeebf6854cfacfa97ff938c03aec12e076b8a70 220104 libnucleus5-dev_5.0.0-7_powerpc.deb Files: 30e3506331b57499d020c49ab9215487 1507 science optional emboss_5.0.0-7.dsc 78d7c8a2cd13f76321faf89084e86e6c 250072 science optional emboss_5.0.0-7.diff.gz 1541238512dbfe2c5ef5053f143f623c 1079388 science optional emboss_5.0.0-7_powerpc.deb 094b358e539b266c7cf08cb7f9e24114 648800 science optional emboss-data_5.0.0-7_all.deb a3dd7f7d7e63da77bfb3bc433711bbc9 4514124 doc optional emboss-doc_5.0.0-7_all.deb 250bc5f011ee761cb5b7a15a9afa5acf 455742 libs optional emboss-lib_5.0.0-7_powerpc.deb ac3659beec482e0d53ab87c8d43a85f8 737014 libs optional libajax5_5.0.0-7_powerpc.deb d63319f7e5feb4f0cef4854c4f8cd90f 927724 libdevel optional libajax5-dev_5.0.0-7_powerpc.deb b1d5b963197ead0164f19d755cdea2c9 196730 libs optional libnucleus5_5.0.0-7_powerpc.deb 9f80eb9ca00d3fd21bfdbe5c9870fe41 220104 libdevel optional libnucleus5-dev_5.0.0-7_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILXfOdYl1krr+x/IRAmgZAJ4vG75GT3P3XRIFyBrQVEhLJPy+ugCgg4iZ +/HZCIXLtFnd1hnEQpSVWao= =IbIr -END PGP SIGNATURE- Accepted: emboss-data_5.0.0-7_all.deb to pool/main/e/emboss/emboss-data_5.0.0-7_all.deb emboss-doc_5.0.0-7_all.deb to pool/main/e/emboss/emboss-doc_5.0.0-7_all.deb emboss-lib_5.0.0-7_powerpc.deb to pool/main/e/emboss/emboss-lib_5.0.0-7_powerpc.deb emboss_5.0.0-7.diff.gz to pool/main/e/emboss/emboss_5.0.0-7.diff.gz emboss_5.0.0-7.dsc to pool/main/e/emboss/emboss_5.0.0-7.dsc emboss_5.0.0-7_powerpc.deb to pool/main/e/emboss/emboss_5.0.0-7_powerpc.deb libajax5-dev_5.0.0-7_powerpc.deb to pool/main/e/emboss/libajax5-dev_5.0.0-7_powerpc.deb libajax5_5.0.0-7_powerpc.deb to pool/main/e/emboss/libajax5_5.0.0-7_powerpc.deb libnucleus5-dev_5.0.0-7_powerpc.deb to pool/main/e/emboss/libnucleus5-dev_5.0.0-7_powerpc.deb libnucleus5_5.0.0-7_powerpc.deb to pool/main/e/emboss/libnucleus5_5.0.0-7_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wordnet 1:3.0-10 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 15 May 2008 14:20:57 +0200 Source: wordnet Binary: wordnet wordnet-dev wordnet-base wordnet-sense-index wordnet-grind dict-wn Architecture: source all i386 Version: 1:3.0-10 Distribution: unstable Urgency: high Maintainer: Andreas Tille [EMAIL PROTECTED] Changed-By: Andreas Tille [EMAIL PROTECTED] Description: dict-wn- electronic lexical database of English language for dict wordnet- electronic lexical database of English language wordnet-base - electronic lexical database of English language wordnet-dev - electronic lexical database of English language wordnet-grind - WordNet lexicographer files processor wordnet-sense-index - electronic lexical database of English language Closes: 481186 Changes: wordnet (1:3.0-10) unstable; urgency=high . * Fix CVE-2008-2149: buffer overflows by limiting the length of the string in sprintf format string Closes: #481186 Please note: The WordNet code contains several other occurences of potentially exploitable functions like strcpy()/strcat()/... and so even if there are no known exploits the code needs a full security audit. * Mentioned the potential security issues in README.Debian Checksums-Sha1: 877fca56c3ac4b217cdf55f89c56b14798bfd107 1227 wordnet_3.0-10.dsc ff8507333e165283a960ac769db62fb4e1ba0e16 68038 wordnet_3.0-10.diff.gz e7e671b1abce7422d9aaf6296ad1d9730fefdaee 8759496 wordnet-base_3.0-10_all.deb a82a66c017d26ea50cfad2acbec5886e855ce414 2241376 wordnet-sense-index_3.0-10_all.deb 15c9f9224731f2e3d89caf6e63deda14c2f82204 10893236 dict-wn_3.0-10_all.deb 87570974f02f518e8ebd4c5d7554c270d06c1102 104074 wordnet_3.0-10_i386.deb 9110e4fbf5a30176d3625edcb33f4d808ad666a4 61316 wordnet-dev_3.0-10_i386.deb 15c59c768d15e389f843d1ef5710d2b420afd3ef 40916 wordnet-grind_3.0-10_i386.deb Checksums-Sha256: 3f35eec4645acbf0ed87c9704dd4b27be24d3c6deb9f82974ef6cc462a21919a 1227 wordnet_3.0-10.dsc 3c2f1c1e15f4eb54ec39315e9bf2327d7ca61711baf15d949183ddcece297c9f 68038 wordnet_3.0-10.diff.gz 9bc884b844dd5ea3de93ee3171a7334dc8e2fba9417feabed7277694bd2de1d8 8759496 wordnet-base_3.0-10_all.deb 39e996e1a2ce90f7683e121bd24356051d3f575dd87e2e016d7a95712d26616f 2241376 wordnet-sense-index_3.0-10_all.deb 71634b25150b035bb407d1f97f3ad17ac59c0119a2460774b01d2c23a74e4f45 10893236 dict-wn_3.0-10_all.deb f16458352bf0b1565d0afafc0d7e24805241eb74661a3e4630a5c4b06094bf1a 104074 wordnet_3.0-10_i386.deb 3a9452beb9541f3165dea3dcfe4936a0811804666ac04406d8b0bf4283ce68c6 61316 wordnet-dev_3.0-10_i386.deb 529fd03362227a2095070178e9766104c7e206eaa2d03c6c285359363bb96289 40916 wordnet-grind_3.0-10_i386.deb Files: 10934dc8536f76c16402a05849db7c9e 1227 text optional wordnet_3.0-10.dsc 108ca9c7c738fe7c6a8d63b9757c61d4 68038 text optional wordnet_3.0-10.diff.gz 57a88da8a5e291637a7aafabb8045ea7 8759496 text optional wordnet-base_3.0-10_all.deb 685e2aa8e2adfd5f1ecc26177ca0368e 2241376 text extra wordnet-sense-index_3.0-10_all.deb 8ba0754d8442541279e65971dfd84cd4 10893236 text optional dict-wn_3.0-10_all.deb 3085204765ee84c6a4af4c49fbc9e151 104074 text optional wordnet_3.0-10_i386.deb d12a8a6f02206b0cf2576a892c39bf6c 61316 devel optional wordnet-dev_3.0-10_i386.deb f10c10a5aa4bdaba562ab878b9b735cb 40916 text extra wordnet-grind_3.0-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILYKMYDBbMcCf01oRAmMhAJ9MQsn1aS6VDXip9DrSnx4ZbYFsUgCgjs5Q S9FCFUewXCGKXLmCu1ujLkI= =f7fq -END PGP SIGNATURE- Accepted: dict-wn_3.0-10_all.deb to pool/main/w/wordnet/dict-wn_3.0-10_all.deb wordnet-base_3.0-10_all.deb to pool/main/w/wordnet/wordnet-base_3.0-10_all.deb wordnet-dev_3.0-10_i386.deb to pool/main/w/wordnet/wordnet-dev_3.0-10_i386.deb wordnet-grind_3.0-10_i386.deb to pool/main/w/wordnet/wordnet-grind_3.0-10_i386.deb wordnet-sense-index_3.0-10_all.deb to pool/main/w/wordnet/wordnet-sense-index_3.0-10_all.deb wordnet_3.0-10.diff.gz to pool/main/w/wordnet/wordnet_3.0-10.diff.gz wordnet_3.0-10.dsc to pool/main/w/wordnet/wordnet_3.0-10.dsc wordnet_3.0-10_i386.deb to pool/main/w/wordnet/wordnet_3.0-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pygobject 2.14.1-6 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 14:14:06 +0200 Source: pygobject Binary: python-gobject python-gobject-dev python-gobject-dbg Architecture: source all i386 Version: 2.14.1-6 Distribution: unstable Urgency: low Maintainer: Josselin Mouette [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: python-gobject - Python bindings for the GObject library python-gobject-dbg - Python bindings for the GObject library (debug extension) python-gobject-dev - Development headers for the GObject Python bindings Changes: pygobject (2.14.1-6) unstable; urgency=low . * Update 61_wakeupfd-fix to use more ifdefs for python without the wakeupfd support; see #481457. * Build-dep and dep on python2.5-dev = 2.5.2-5 for wakeupfd support. Checksums-Sha1: f5c8110176bc2853c5a60ed8f65f5d590ae5eb05 1438 pygobject_2.14.1-6.dsc 9d04b9037ad05a5e7a4285a4d7bd3b2548d856bc 45190 pygobject_2.14.1-6.diff.gz 2de72b5ec4f596c78bfc3fb43169e34496ba7414 52550 python-gobject-dev_2.14.1-6_all.deb 70cb7184f84600486575b82c363101c4b6b8d95d 157466 python-gobject_2.14.1-6_i386.deb 68de7ac386b7be4a6dff990ec216493db0241be6 634408 python-gobject-dbg_2.14.1-6_i386.deb Checksums-Sha256: 0479a677d8a0cafbfd93f34f570b561bdf6364fbb676645361b41340176e 1438 pygobject_2.14.1-6.dsc fe4bf04b1eb2326afd9fbdb3a307abc32ab63940393b67152aed89454e9df579 45190 pygobject_2.14.1-6.diff.gz 16e1d32c1b1fcbdf8fae595ffb34f5fd0838396ae0f27de7cf4214131f12079a 52550 python-gobject-dev_2.14.1-6_all.deb d70b780deab1d8f292f22edb0e67e39c062808b5d77258ff4f9770ef897de8b1 157466 python-gobject_2.14.1-6_i386.deb 98b5fa8fd23209db11d1ee965b3a9f9ad3dd209fcced453779e0f5a8bb006375 634408 python-gobject-dbg_2.14.1-6_i386.deb Files: 8f50406267a96cd83ebc614ba9fe5132 1438 python optional pygobject_2.14.1-6.dsc fd6a3c2756c2fca5ee4e42e1086f6e28 45190 python optional pygobject_2.14.1-6.diff.gz f9916bb2e8cf7e68656b3c7d64aa2171 52550 python optional python-gobject-dev_2.14.1-6_all.deb ef3bd5458c774b24ed59e35df4c05337 157466 python optional python-gobject_2.14.1-6_i386.deb 38c974c0df00d7d6b3aae9b866a109a3 634408 python extra python-gobject-dbg_2.14.1-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILX+c4VUX8isJIMARAqLyAJ0QF71otDjN8OjlovrFpTCSoGnqYQCfc0Da uWS7fEsyWlOg+VtE1JC8uYo= =+JNd -END PGP SIGNATURE- Accepted: pygobject_2.14.1-6.diff.gz to pool/main/p/pygobject/pygobject_2.14.1-6.diff.gz pygobject_2.14.1-6.dsc to pool/main/p/pygobject/pygobject_2.14.1-6.dsc python-gobject-dbg_2.14.1-6_i386.deb to pool/main/p/pygobject/python-gobject-dbg_2.14.1-6_i386.deb python-gobject-dev_2.14.1-6_all.deb to pool/main/p/pygobject/python-gobject-dev_2.14.1-6_all.deb python-gobject_2.14.1-6_i386.deb to pool/main/p/pygobject/python-gobject_2.14.1-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libxau 1:1.0.3-3 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 16 May 2008 15:15:13 +0200
Source: libxau
Binary: libxau6 libxau6-dbg libxau-dev
Architecture: source i386
Version: 1:1.0.3-3
Distribution: unstable
Urgency: low
Maintainer: Debian X Strike Force [EMAIL PROTECTED]
Changed-By: Julien Cristau [EMAIL PROTECTED]
Description:
libxau-dev - X11 authorisation library (development headers)
libxau6- X11 authorisation library
libxau6-dbg - X11 authorisation library (debug package)
Changes:
libxau (1:1.0.3-3) unstable; urgency=low
.
* Remove Branden from Uploaders with his permission.
* Add myself to Uploaders.
* Bump Standards-Version to 3.7.3.
* Drop the XS- prefix from Vcs-* control fields.
* libxau6{,-dbg} don't need to depend on x11-common.
* Use ${binary:Version} instead of the deprecated ${Source-Version}.
Checksums-Sha1:
c04b01f55f6212cd0275037757909c97e3d5deda 1215 libxau_1.0.3-3.dsc
c94bff9fe7690018955f63b5f44544d957b2a51c 33965 libxau_1.0.3-3.diff.gz
d575e95dae6882f849271905e6c05dad86e54550 11910 libxau6_1.0.3-3_i386.deb
dbefa1bc6e5ad3d8e08820a7f50952afb0f6ba98 15656 libxau6-dbg_1.0.3-3_i386.deb
9af8bf47b47dcd48619526eeab3aafcee905aae1 15420 libxau-dev_1.0.3-3_i386.deb
Checksums-Sha256:
0371add3df528803e15fe84a5b245fe82bfa531f45abe67e8fc8e2e363dfbfd8 1215
libxau_1.0.3-3.dsc
add83fb20459833349f20386a9fc83162c29947a299b2e3cce3aa13391a615f8 33965
libxau_1.0.3-3.diff.gz
7ce0cd37ff605384cd2e7c7ef1f11944ce3534c108c0d5aaeed469535afd6f0a 11910
libxau6_1.0.3-3_i386.deb
d91e7c977df9a652ab941866651f390697041045d0c58bb44521595fcc31c84e 15656
libxau6-dbg_1.0.3-3_i386.deb
7814e6cf0894d123201777e4d69e3ef30a7f84934dad9a75034a8d46bdb57255 15420
libxau-dev_1.0.3-3_i386.deb
Files:
421c196219819200eba9400b4a526a7f 1215 x11 optional libxau_1.0.3-3.dsc
625f327b31f97b3f7ed559ea8ca35440 33965 x11 optional libxau_1.0.3-3.diff.gz
d937eead7de24f2ba1e1b03a945ffb34 11910 libs optional libxau6_1.0.3-3_i386.deb
60c41da81069dcec48da36f797eb138f 15656 libdevel extra
libxau6-dbg_1.0.3-3_i386.deb
5a89be7eab179d2d78e7d96afe8e8efb 15420 libdevel optional
libxau-dev_1.0.3-3_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFILYnWmEvTgKxfcAwRAh+tAJ4wxqZ8z4dcLjqfQ58Z+F1+jEIT8gCeOU+6
YeFnPg8LKqpE6sV+8KN871w=
=PrnU
-END PGP SIGNATURE-
Accepted:
libxau-dev_1.0.3-3_i386.deb
to pool/main/libx/libxau/libxau-dev_1.0.3-3_i386.deb
libxau6-dbg_1.0.3-3_i386.deb
to pool/main/libx/libxau/libxau6-dbg_1.0.3-3_i386.deb
libxau6_1.0.3-3_i386.deb
to pool/main/libx/libxau/libxau6_1.0.3-3_i386.deb
libxau_1.0.3-3.diff.gz
to pool/main/libx/libxau/libxau_1.0.3-3.diff.gz
libxau_1.0.3-3.dsc
to pool/main/libx/libxau/libxau_1.0.3-3.dsc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted regina-normal 4.5-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 17 May 2008 11:39:33 +1000 Source: regina-normal Binary: regina-normal regina-normal-dev regina-normal-mpi regina-normal-doc Architecture: source all amd64 Version: 4.5-1 Distribution: unstable Urgency: low Maintainer: Ben Burton [EMAIL PROTECTED] Changed-By: Ben Burton [EMAIL PROTECTED] Description: regina-normal - 3-manifold topology software with normal surface support regina-normal-dev - development files for Regina, the 3-manifold topology software regina-normal-doc - API docs for Regina, the 3-manifold topology software regina-normal-mpi - MPI utilities for Regina, the 3-manifold topology software Changes: regina-normal (4.5-1) unstable; urgency=low . * New upstream release. Checksums-Sha1: 9a8bb9254290549b4dd82797d1be81966e248b50 1370 regina-normal_4.5-1.dsc 3cadcb27385ff296c3cc7ce267cc2ab4f7fb49c7 4960138 regina-normal_4.5.orig.tar.gz 1b9047ad851aaf2cfed95a03b10cae6e8d10eee6 10426 regina-normal_4.5-1.diff.gz 3f1d711d4e00092c6780489a6e7db66fdc79dcce 1562152 regina-normal-doc_4.5-1_all.deb efe042017ee0a07fd8b9b764a6f12ea1957ec807 5512832 regina-normal_4.5-1_amd64.deb 84783bfb3ac00305b9a686d5dba9480d3cd3a915 2822404 regina-normal-dev_4.5-1_amd64.deb 5bf515f4b4454b6857dca5e3023eb2392953fe6e 258616 regina-normal-mpi_4.5-1_amd64.deb Checksums-Sha256: 580ce2d9ccf44f4e71bc3b6f7fd523da46a9727c9cd8835767306ae3487484c2 1370 regina-normal_4.5-1.dsc c630acdccff37d11d75c2f106ebe41dd1907ac897f0fd5a62f7cf9cbacd31179 4960138 regina-normal_4.5.orig.tar.gz 1704a9aa8a4c3426b74f97961340953fb2bf8a2b53ddeb723644289e40a16d3b 10426 regina-normal_4.5-1.diff.gz 0c49c4605f12fa5a975068bd144eb983b8006511ac9fd815bdc400fd5f571af3 1562152 regina-normal-doc_4.5-1_all.deb b9350e3e39a3c5610e5aabcd9089b3c6d017a7f9de4951d6a037f1bdd97f9e6d 5512832 regina-normal_4.5-1_amd64.deb 561730909119aef247da55cfc2b46542443550fa3468df2104d7c53e6a37a81a 2822404 regina-normal-dev_4.5-1_amd64.deb 27c3ac3b4f98effb589bdc0d255e477d85ba7686b1263cbfc6538ae880d56144 258616 regina-normal-mpi_4.5-1_amd64.deb Files: 933638b4af527bf807dd4af53dc520eb 1370 math extra regina-normal_4.5-1.dsc d79262b3d14a7f0f1b43b039ed44ded1 4960138 math extra regina-normal_4.5.orig.tar.gz bf28387bb41fa0ee9031f00cce7563e4 10426 math extra regina-normal_4.5-1.diff.gz 7ece4084efeadd211de17375156776ec 1562152 doc extra regina-normal-doc_4.5-1_all.deb da35c88a3e5c33eddb1c04fb64583f90 5512832 math extra regina-normal_4.5-1_amd64.deb d000d51e1fe2ea19733c9ee7f1007455 2822404 libdevel extra regina-normal-dev_4.5-1_amd64.deb f8f0b49ad9b2154d7f0721ce9e69570b 258616 math extra regina-normal-mpi_4.5-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIK0LiMQNuxza4YcERAsfTAJ40Owp/eFzyhAL9LAztiGO1vafVKQCff7qa 6fpAvQHI0xnRuuV0X5sYh4U= =zUK4 -END PGP SIGNATURE- Accepted: regina-normal-dev_4.5-1_amd64.deb to pool/main/r/regina-normal/regina-normal-dev_4.5-1_amd64.deb regina-normal-doc_4.5-1_all.deb to pool/main/r/regina-normal/regina-normal-doc_4.5-1_all.deb regina-normal-mpi_4.5-1_amd64.deb to pool/main/r/regina-normal/regina-normal-mpi_4.5-1_amd64.deb regina-normal_4.5-1.diff.gz to pool/main/r/regina-normal/regina-normal_4.5-1.diff.gz regina-normal_4.5-1.dsc to pool/main/r/regina-normal/regina-normal_4.5-1.dsc regina-normal_4.5-1_amd64.deb to pool/main/r/regina-normal/regina-normal_4.5-1_amd64.deb regina-normal_4.5.orig.tar.gz to pool/main/r/regina-normal/regina-normal_4.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mpdscribble 0.2.12-10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 16 May 2008 15:08:17 +0200 Source: mpdscribble Binary: mpdscribble Architecture: source i386 Version: 0.2.12-10 Distribution: unstable Urgency: low Maintainer: Michal Čihař [EMAIL PROTECTED] Changed-By: Michal Čihař [EMAIL PROTECTED] Description: mpdscribble - Last.fm reporting client for mpd Closes: 481482 Changes: mpdscribble (0.2.12-10) unstable; urgency=low . * Experimental support for HTTP proxy based on patch from upstream bug tracker (Closes: #481482). Checksums-Sha1: b7ea4f53b984df34129ac65dc327fa5e0d46a391 1206 mpdscribble_0.2.12-10.dsc 158d1753d47b5fad636e93966f18bea425e79247 70018 mpdscribble_0.2.12-10.diff.gz 4cd308e29405c255f4c074cf0fe84bf806a6614c 32972 mpdscribble_0.2.12-10_i386.deb Checksums-Sha256: 05e709c214586f4aafd353c9975dcd5f1e1c303c6623ce1df959022a4a499e6f 1206 mpdscribble_0.2.12-10.dsc 14366206c330c91c7235e0e0b87e5e8e7b5db37055fb29f1e07a2ff6b405e82e 70018 mpdscribble_0.2.12-10.diff.gz 3c4c931a3c2d783a853c310a1ffa51750658218b9638b7a8cbbdc609956054cc 32972 mpdscribble_0.2.12-10_i386.deb Files: 3a010649ba19dc30d6de799824dc34b4 1206 sound optional mpdscribble_0.2.12-10.dsc 5d5776209f196a53587a301973926991 70018 sound optional mpdscribble_0.2.12-10.diff.gz a2e222c00948a007ed32ac67a43aaf27 32972 sound optional mpdscribble_0.2.12-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILYlN3DVS6DbnVgQRAmjbAJ421O3iiD6COj7/kL/tZ+6dRY/O/ACeNubY bvv/Dj+gmdbGjKbLhkdcpZ0= =n5eX -END PGP SIGNATURE- Accepted: mpdscribble_0.2.12-10.diff.gz to pool/main/m/mpdscribble/mpdscribble_0.2.12-10.diff.gz mpdscribble_0.2.12-10.dsc to pool/main/m/mpdscribble/mpdscribble_0.2.12-10.dsc mpdscribble_0.2.12-10_i386.deb to pool/main/m/mpdscribble/mpdscribble_0.2.12-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
