Choose prescripiton medicine
Title: loop afforestation cool demountable cohesion ukrainian hoot burtt Find all your medications in one place! We have all pills you may well require! You name it! We have them all! Stop receiving promotional material now guardia severalty louisiana
Re: Is debhelper build-essential?
Peter Samuelson wrote: [Ken Bloom] I'm confused. One making backports from sid to woody should backport a package in such a way that it is buildable with woody's build-essential. AFAICS, that's no more true for build-essential than for anything else. That is, you can either backport it so it builds using packages in stable, or you can backport the build dependency too. Backporting build-essential is pretty easy if everything it depends on is already in sarge -- it's a no op. It'd seem strange to do anything else... Yes. Same will be true backporting to sarge. But if sarge build-essential were to be updated to contain debhelper (>= 4), that would make less work for backporters than if this same change were made only post-sarge. That's crazy talk. If it's true, you're surely doing something wrong. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pre-RFA] Intending to drop twenty-some packages
* Dirk Eddelbuettel | - time (dead upstream) [...] | Please CC me on follow-ups to debian-devel, or email me directly if you have | any interest. I should follow up with RFA and O bug reports over the next | few weeks, but doing this informally first may be simpler. Or maybe not. I'd like time, please. -- 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]
Stephen Frost: MIA ?
Hi everybody. I would like to know if Stephen Frost is alright and if he is still active in any way. He is my Application Manager and i have known nothing from him since 19th July. He has not even answered my pings on 21st October, 8&19th November and 29th December, even though i promptly answered him on 20th July. I have been in the NM queue since November 2003 and have not yet received the questions for the "Task & Skills" part :-S I understand that Stephen must be very busy, but i'm sure i can be of some help if i was a DD myself (as opposed to having to bug some poor fellow Developer to sponsor my uploads). Sorry for the noise, but i need some feedback on my NM process after so much time has passed. Best, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#290652: ITP: kernel-patch-ibookg4-suspend -- patch to support for hibernation in new G4 ibooks
Jorge Bernal wrote: Package: wnpp Severity: wishlist * Package name: kernel-patch-ibookg4-suspend Version : test6 Upstream Author : Benjamin Herrenschmidt <[EMAIL PROTECTED]> * URL : http://gate.crashing.org/ * License : GPL Description : patch to support for hibernation in new G4 ibooks This patch adds support for hibernation in new G4 ibooks. . Note that it's an EXPERIMENTAL patch and may not work. I have packages available at: http://www.amedias.org/~koke/debian/unstable/ There is a test7 version but does not work very well, at least with my ibook. Ehm, the Test7 works fine and nobody yet complaint about it. If you have problems please report them on debian-powerpc, I haven't found any mail from you on this list. Additionally the name is not chosen very good since the patch is for powerbooks too. You should really get more experience with the patch if you want to package it. Maybe you want to try my ppc kernel packages at: http://people.debian.org/~formorer/ppc. The packages have been reported as working fine for ibooks. Sincerly Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pre-RFA] Intending to drop twenty-some packages
On Saturday, 15 de January de 2005 18:51, Dirk Eddelbuettel wrote: > * the Octave complex > - octave2.0 (to be removed once sarge is release; frozen upstream ages > ago; one bug that'll never get fixed, we can barely build it as it requires > g++ pre-3.0) > - octave2.1 (two minor bugs against the emacs mode, one other bug) > - octave-forge (pretty active and by now pretty large with many > build-depends; very well maintained upstream by Paul Kienzle) > - semidef-oct (needs rebuilds with every octave2.1 build) > - octave-matcompat (predecessor to octave-forge, can be removed soon) > - octave-ci (large chunks of it now in octave-forge and octave2.1) > - octave-epstk (active upstream) > - matwrap (dead upstream) > - inline-octave (Perl package, see above) > > I have tried to unload this onto Rafael for a few years now, but he can't > take Octave either. This may be best served by a maintainer group via > alioth, and I could be persuaded to help. But I can't set up such a group > or lead it, for lack of time. > > Octave has an outstanding author in John Eaton with whom I have worked > very well over the years. The same can be said of Paul Kienzle for > octave-forge. I use Octave and I'm interested on maintaining it, with a team if possible. Are there anyone else interested on it? Best regards -- Isaac Clerencia <[EMAIL PROTECTED]> Warp Networks http://www.warp.es María de Luna 11, 50018 Zaragoza, Spain pgpBTY9zD3dgD.pgp Description: PGP signature
see with URL support or agnostic konqueror?
Hello, I'm maintaining the freemind package and currently 'sensible-browser' is used to open links (which are always absolute, either file:/... or http, ftp, whatever). It works well for remote links (http etc.) but is not the best solution for file: links, if a true browser is behind sensible-browser. 'see' would be a better solution because it handles file types properly, but it doesn't understand URL notation and doesn't handle remote links. konqueror would handle everything well but is not so nice for non-KDE users. My best guess currently would be a small wrapper script that calls 'see' for file: links (removing the file: prefix), and 'sensible-browser' for all other kind of links. Not very difficult but I have the feeling this must have been needed by others as well. So my questions: - is there already an "agnostic" utility that does this kind of thing? - would the 'mime-support' maintainer be interested in adding URL handling to the 'see' utility? (would this be at all a good idea?) Thanks, Eric -- Gewalt ist die letzte Zuflucht der Inkompetenz. Violence is the Last Resort of the Incompetent. Gwalt jest ostatnem schronieniem niekompetencji. La violence est le dernier refuge de l'incompetence. ~ Isaac Asimov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stephen Frost: MIA ?
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote: >I would like to know if Stephen Frost is alright and if he is still > active in any way. He is my Application Manager and i have known nothing > from him since 19th July. He has not even answered my pings on 21st > October, 8&19th November and 29th December, even though i promptly > answered him on 20th July. "I'm not quite dead yet. I think I'm feeling better..." Guess you don't follow debian-newmaint, oh well. I'm usually better about answering pings (in fact, I thought I had at least one of those times...) >I have been in the NM queue since November 2003 and have not yet > received the questions for the "Task & Skills" part :-S > I understand that Stephen must be very busy, but i'm sure i can be of > some help if i was a DD myself (as opposed to having to bug some poor > fellow Developer to sponsor my uploads). As has been mentioned many times before (and I expect you know...), there's lots you can do w/o being a DD. Not excusing myself, I've been very bad about things of late, and I'm sorry. :) Of course, you should have contacted the front desk as opposted to debian-devel (which quite a few developers don't follow these days anyway, you're just lucky I skim the subjects every once in a while). > Sorry for the noise, but i need some feedback on my NM process after so > much time has passed. Really, contacting the front desk is the best thing to do if your AM isn't being responsive. You can be confident the front desk will bug the AM about it and the front desk can actually *do* something about it (ie: reassign you to a different AM). Stephen signature.asc Description: Digital signature
Re: DebConf4 Final Report
[Pablo Lorenzzoni] > If you spot any mistake, please, let me know and I'll fix it in the > next revision. Thank you for a good report. I noticed the list of people from Debian Edu was a bit short. In addition to me, it should list Andreas Schouldei, Joey Hess and Konstantinos Margaritis, all of which are part of the debian-edu CDD. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290753: ITP: dgap -- driver for Digi Acceleport PCI multiport serial cards
Package: wnpp Severity: wishlist * Package name: dgap Version : 1.1 Upstream Author : Digi International * URL : http://www.digi.com * License : GPL w/separate non-free firmwares Description : driver for Digi Acceleport PCI multiport serial cards This will go into contrib; the sources up on Digi's support site also contain the firmwares needed by the cards. I'll split the firmware files from the source package to put them in non-free, where they belong. I'm currently verifying that we can redistribute the files, as there's no mention of anything concerning the firmware files in the source package. The dgap driver obsoletes the epca driver which is included in the vanilla kernel distribution. It supports only the PCI cards, and works on Linux 2.4 and 2.6. The source package will produce 2 binary packages in contrib: Package: dgap-tools Description: support utilities for the Digi Acceleport multiport serial cards This package contains support utilities related to the dgap driver for Digi Acceleport multiport serial cards: . o mpi - driver management utility o dinc - a cu/tip replacement o ditty - an stty replacement o dpa - a port monitoring/testing utility Package: dgap-source Description: Digi Acceleport multiport serial cards driver This package contains the sources of the dgap driver for Digi Acceleport multiport serial cards. . This driver supports only the following PCI Acceleport cards, on both Linux v2.4 and Linux v2.6 : . o Acceleport Xem o Acceleport Xr o Acceleport Xr 920 o Acceleport C/X o Acceleport EPC/X o Acceleport Xr/422 o Acceleport 2r/920 o Acceleport 4r/920 o Acceleport 8r/920 o IBM 8-Port Asynchronous PCI Adapter o IBM 128-Port Asynchronous PCI Adapter And an additional package in non-free: Package: dgap-data Description: firmware files for the Digi Acceleport multiport serial cards This package contains the firmware files needed by the dgap driver for Digi Acceleport multiport serial cards. JB. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.9 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[CFH] Please test new dpatch in experimental
Hi! I've uploaded a new dpatch into experimental, with two new interesting features in dpatch-edit-patch (thanks to Marc Haber) that I would like to subject to extensive testing before I upload the package to unstable. The package is available from both http://incoming.debian.org/ and http://dpatch.alioth.debian.org/. It should hit the mirrors with the next pulse. As for the new features, the first - and probably less problematic one - is that dpatch-edit-patch's default behaviour was changed slightly. Before, it cleaned the source tree before copying it to a temporary location. Now it does not do that. It copies the tree as-is, and cleans the copied, temporary tree. This is very handy when one regularily works on a half- or fully-built tree, and does not want to clean that. However, the drawback is, that this way far more data gets copied, and that might be slow. Therefore a --clean option is provided that restores the old behaviour. The other new feature, which in my optionion would need more testing (I tested the other one as much as I could, but this other I can't. At least, not easily). So, the second new feature is the --debianonly option. This is for trees that consist only of a debian/ directory. The original tarball will be searched for in the parent directory, and if not found, dpatch-edit-patch tries to download it from the network (using debian/watch and curl, or apt-get source). This is interesting for those who only store the debian/ part of their packages under revision control. So, that's it! I believe these two are important usability features, so I'd like to ask all you dpatch-edit-patch users to test this carefully, so when it gets uploaded into unstable in a few weeks, all remaining bugs (if any) will be ironed out already. Thanks in advance, Gergely Nagy -- /\ /\ (^.^) (")") *This is the cute kitty virus, please copy this into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Legal budget and Director-and-officer insurance related to packages with "adult" themes
On Sun, Dec 05, 2004 at 02:59:53AM +, Andrew Suffield wrote: > On Sat, Dec 04, 2004 at 02:33:44PM -0800, Bruce Perens wrote: >> There are a few people who are most likely to be prosecuted over >> legal issues in Debian packages that have "adult" themes. > Oh come on, they're at far greater risk from our overly-permissive > approach to copyright and patent issues. A key difference, IMHO, is that only the ( patent | copyright ) holder can sue over these; mostly anybody can sue over "inappropriate adult material": parents, grand-parents, cybercafé operators, morality leagues, ... -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [CFH] Please test new dpatch in experimental
#include * Gergely Nagy [Sun, Jan 16 2005, 03:27:16PM]: > The other new feature, which in my optionion would need more testing (I > tested the other one as much as I could, but this other I can't. At > least, not easily). So, the second new feature is the --debianonly > option. This is for trees that consist only of a debian/ directory. The > original tarball will be searched for in the parent directory, and if > not found, dpatch-edit-patch tries to download it from the network > (using debian/watch and curl, or apt-get source). This is interesting > for those who only store the debian/ part of their packages under > revision control. Please also look in .svn/deb-layout for a line like: origDir=/home/inet/debian/dev/tarballs That would be the most probable location for the orig tarball. Regards, Eduard. -- Everything is illusion. Constructs of language, light, metaphor; nothing is real. -- Babylon 5, Season 4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290763: ITP: libgnujmi-java -- free implementation of the java metadata interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist * Package name: libgnujmi-java Version : 0.0cvs20050116 Upstream Author : Arnaud Vandyck <[EMAIL PROTECTED]> * URL or Web page : http://savannah.gnu.org/projects/classpathx * License : GPL Description : free implementation of the java metadata interface GNU JMI is a free implementation of the JSR-40 The JavaTM Metadata Interface (JMI). . It consist of an API to solve the problem of incompatible metadata. . This is the classpathx free implementation of the library . Homepage: http://savannah.gnu.org/projects/classpathx - -- Arnaud Vandyck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB6n7U4vzFZu62tMIRAjNSAKCNqKJ3iVDcEkS0sI2Wih6CMofHiwCgg6Rf haPTOhmsECxTpdTtwRDiKsA= =6hkR -END PGP SIGNATURE-
Re: [CFH] Please test new dpatch in experimental
> > The other new feature, which in my optionion would need more testing (I > > tested the other one as much as I could, but this other I can't. At > > least, not easily). So, the second new feature is the --debianonly > > option. This is for trees that consist only of a debian/ directory. The > > original tarball will be searched for in the parent directory, and if > > not found, dpatch-edit-patch tries to download it from the network > > (using debian/watch and curl, or apt-get source). This is interesting > > for those who only store the debian/ part of their packages under > > revision control. > > Please also look in .svn/deb-layout for a line like: > > origDir=/home/inet/debian/dev/tarballs > > That would be the most probable location for the orig tarball. Done in the arch repo, thanks! For interested parties, the patch is attached. -- Gergely Nagy --- orig/dpep/dpatch-edit-patch.functions +++ mod/dpep/dpatch-edit-patch.functions @@ -233,6 +233,9 @@ DPEP_ORIGTARGZ="$(readlink -f "../$ORIGTARGZ")" elif [ -n "${DPEP_ORIGTARDIR}" ] && [ -f "${DPEP_ORIGTARDIR}/${ORIGTAGZ}" ]; then DPEP_ORIGTARGZ="$(readlink -f "${DPEP_ORIGTARDIR}/${ORIGTAGZ}")" +elif [ -f ".svn/deb-layout" ]; then + DPEP_ORIGTARGZ="$(readlink -f "$(cat .svn/deb-layout | sed -e "s,^origDir=,,")/${ORIGTARGZ}")" + return 0 elif [ -f "debian/watch" -a -x $(which curl) ]; then if curl "$(< debian/watch sed -n "/^\\(http\\|ftp\\)/{s/^\\([^(]\\+\\)([^)]*)\\([^ ]*\\).*/\\1${UPSTREAMVERSION}\\2/;s///g;p;q;}")" > ../$ORIGTARGZ; then DPEP_ORIGTARGZ="$(readlink -f "../$ORIGTARGZ")"
Re: [Pre-RFA] Intending to drop twenty-some packages
On Sun, Jan 16, 2005 at 10:05:46AM +0100, Tollef Fog Heen wrote: > * Dirk Eddelbuettel > > | - time (dead upstream) > > [...] > > | Please CC me on follow-ups to debian-devel, or email me directly if you have > | any interest. I should follow up with RFA and O bug reports over the next > | few weeks, but doing this informally first may be simpler. Or maybe not. > > I'd like time, please. Wouldn't we all? =P Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#60810: contents.gz package
On Sat, Jan 15, 2005 at 10:09:07AM -0500, Justin Pryzby wrote: [snip] > > I think the only sensible and simple thing to do is to provide a zsync > > file for the Contents files (zsync can 'look into' gz to rsync just > > the changes). Then every user can use a cron job to zsync the file to > > his system on a daily, weekly, monthly, whatever basis. zsync uses the > > http protocol so any http mirror carrying the Contents files will do > > as source. > So maybe an debian-contents-updater package. It contains some cronjob > entry, maybe a debconf question, or it uses /etc/defaults/. Yes, that > would work nicely, I think. what about including this (zsync'ed Contents plus cronjob) in apt-file (which needs Contents anyway) or including a symlink for apt-file so it uses it instead of downloading a new one on apt-file update filippo -- Filippo Giunchedi GNU/PG key: 6B79D401 Random signature follows: Date: Tuesday, 2002/10/22 - 08:09 dselect proves the existence of Satan. It's the worst part of Debian.
h00k-up-in-here
Meeet a skirt 2nite http://exradiusaffiancevapor-clouded.com/sse/ stp theze : exradiusaffiancevapor-clouded.com/xxt/ The sandhill leech diet gill . She eugenia detroit hulk moiseyev constitute . mckay prentice diatom month . central dolce thorough roberta . The enter sediment convalesce ppm caddy . She fogging monic venturesome nucleolus mescaline . And karma fleabane hungary despot cordage . She problematic matrimony opprobrium rototill ceremonious bosom .and anglicanism yore virgule coercive dioxide . The cannibal impolitic intemperance . tam citrate connecticut hunk cia sole .and isabella arbitrage cameroun chairman . natural plaid concubine appointee postpone contingent . The midget foursome shamrock elena benjamin grady . She viewpoint decommission salmonella sevenfold by . The calliope delinquent pirogue bring niggle . t sleep hop onlook soap foss . debian-devel@lists.debian.org
Re: [Pre-RFA] Intending to drop twenty-some packages
On Sat, Jan 15, 2005 at 10:14:41PM +0100, Bas Zoetekouw wrote: > Hi Dirk! > > You wrote: > > > * the gsl set: > > - gsl > > - gsl-ref-html > > - gsl-ref-psdoc > > > > The two doc packages are currently a week behind packaging the new > > upstream > > gsl. Well maintained upstream, maybe two releases a year. This should > > probably go to another egghead ph.d. type, preferably in sciences. Hi > > Chris. > > This is all very well maintained upstream. Two nuisance bug reports on the > > doc package, one ftbfs that is in explicable to me. > > I'd be happy to help out/co-maintain/etc gsl, too. That's a pretty good idea. How about if I make you an uploader now in the debian/control file of the three packages, that would become effective on the next upload. If I a bug fix is needed and you don't hear from, please feel free to add yourself. Does that sound allright to you? Best, Dirk > > -- > Kind regards, > ++ > | Bas Zoetekouw | GPG key: 0644fab7 | > || Fingerprint: c1f5 f24c d514 3fec 8bf6 | > | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 > fab7 | > ++ -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pre-RFA] Intending to drop twenty-some packages
On Sat, Jan 15, 2005 at 10:21:37PM +0100, Erik Schanze wrote: > Dirk Eddelbuettel <[EMAIL PROTECTED]>: > > * Miscellaneous > > - afio (2 open bugs, active upstream, pretty straightforward) > I like afio for my compressed backups and use it very often. > I'd like to take over maintainership for it, if no otherone has already asked > for. Sounds good -- consider it yours! Thanks, Dirk > > > Kindly regards, > Erik > > > -- > www.ErikSchanze.de * > Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * > * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * > Info: http://www.linux-info-tag.de * -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pre-RFA] Intending to drop twenty-some packages
On Sun, Jan 16, 2005 at 10:05:46AM +0100, Tollef Fog Heen wrote: > * Dirk Eddelbuettel > > | - time (dead upstream) > > [...] > > | Please CC me on follow-ups to debian-devel, or email me directly if you have > | any interest. I should follow up with RFA and O bug reports over the next > | few weeks, but doing this informally first may be simpler. Or maybe not. > > I'd like time, please. All yours. Enjoy the regular bug reports from people who confuse it with the bash builtin :) Best, Dirk > > -- > Tollef Fog Heen,''`. > UNIX is user friendly, it's just picky about who its friends are : :' : > `. `' > `- -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: scheme.app -- Scheme interpreter for GNUstep
Package: wnpp Severity: wishlist * Package name: scheme.app Version : 0.5 Upstream Author : Marko Riedel <[EMAIL PROTECTED]> * URL : http://www.gnustep.it/marko/GScheme/ * License : GNU GPL Description : Scheme interpreter for GNUstep This is a GNUstep aware scheme interpreter. Includes many examples, e.g. the sieve of Erathostenes to compute primes, a Koch curve plotter, mandelbrot set, graphs of various functions etc. Scheme is fully tail recursive. The garbage collector bypasses GNUstep's retain/release mechanism in order to deal with circular data structures. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX pgpnP6BD1isBm.pgp Description: PGP signature
ITP: fortunate.app -- Display a quotation (fortune) in a window for GNUstep
Package: wnpp Severity: wishlist * Package name: fortunate.app Version : 3.1 Upstream Author : Stefan Kleine Stegemann <[EMAIL PROTECTED]> (GNUstep port), Chris Saldanha <[EMAIL PROTECTED]> * URL : http://www.orange-carb.org/~csaldanh/software.html (Original page) http://www.linuks.mine.nu/fortunate/ * License : GNU GPL Description : Display a quotation (fortune) in a window for GNUstep Fortunate displays a quotation in a window. Fortunate is a Cocoa/Objective-C graphical front-end to the command-line BSD fortune which, since the dawn of time, has been providing countless seconds of fun each time a user logs in. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX pgp9ma9M40fpY.pgp Description: PGP signature
ITP: backgrounds-debian-shell -- Photography of shells aligned to form the Debian logo
Package: wnpp Severity: wishlist * Package name: backgrounds-debian-shell Version : 1.0 Upstream Author : Jakub Budziszewski <[EMAIL PROTECTED]> * URL : http://linuks.mine.nu/jakub/ * License : Artistic License Description : Photography of shells aligned to form the Debian logo A photography that consists of shells aligned to form the Debian logo. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX pgpjQGo6QbanY.pgp Description: PGP signature
intent to rename vips7.10 -> vips
Executive summary: I'm planning on renaming the vips7.10 packages to get the "7.10" out of the package name unless someone tells me that I shouldn't. I've discussed this on debian-mentors already. Read on for the copious details. - The recent threads on sonames and package names convinced me beyond a doubt that I made a mistake in the names of the vips packages. I had reasons at the time, but in retrospect, they were wrong. I now intend to rename the packages. I discussed it on debian-mentors and have prepared everything for upload and have tested it thoroughly, but I wanted to run it past debian-devel before doing the actual upgrade. Right now, vips7.10 has only been in the archive for a short time. There is only one dependent package in the archive which I also maintain. In other words, this is the right time to correct the mistake. Right now, the vips7.10 source package creates four binary packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and libvips7.10-doc. My intention is to do the following: Create new source package "vips" which will create four binary packages: libvips10, libvips-dev, libvips-tools, libvips-doc. (10 is the current soname.) Each package Conflicts with the package it replaces with a version << the future dummy transition version of the existing packages and Replaces the old package as well. For example: Package: libvips10 Conflicts: libvips7.10 (<< 7.10.dummy) Replaces: libvips7.10 Upload this package and wait for it to clear NEW. Upload new version of vips7.10 (currently 7.10.8-1) called 7.10.dummy-1 that creates four dummy packages in section "oldlibs" each of which installs no files (except the mandatory ones in /usr/share/doc) and depends upon its replacement package. The Description of the package includes the word "dummy", and is akin to this, as adjusted appropriately for each package: Package: libvips7.10 Description: transitional dummy package replaced by libvips10 This is the old name for libvips10. It can be safely removed. Upload new version of the package that depends upon libvips7.10 (nip2) replacing its dependencies and build dependencies as needed. (Dependencies will be automatic with the new shlibs file.) By doing this, anyone who has the current packages installed and does apt-get dist-upgrade will automatically get the new packages with the new names. They will also (unfortunately) have the dummy transition packages, but I see no way around that. Someone who explicitly apt-get installs the new packages prior to upgrading the old packages would have the old packages removed. For all the gory details, see this thread: http://lists.debian.org/debian-mentors/2005/01/msg00240.html and particularly http://lists.debian.org/debian-mentors/2005/01/msg00253.html I'm going to ask my usual sponsor to upload these in the next few days unless someone gives me a compelling reason not to. :-) In the interest of full disclosure, in the original ITP, David Moreno Garza <[EMAIL PROTECTED]> asked why I was including the version number in the package name and I gave a reason. In retrospect, the reason wasn't really valid. Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290799: ITP: libspandsp -- Library which provides DSP functions for VoIP.
Package: wnpp Severity: wishlist * Package name: libspandsp Version : 0.0.2pre9 Upstream Author : Steve Underwood <[EMAIL PROTECTED]> * URL : ftp://ftp.opencall.org/pub/spandsp/ * License : GPL Description : Library which provides DSP functions for VoIP. spandsp is a library which provides many of the DSP functions needed for telephony. It is designed to be independent of the telephony platform itself. It's used by YATE and Asterisk do to Fax for example. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.6 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changing architecture from any to all
If one changes the architecture of a package from "any" to "all" but makes no change to the package name, does this require any special manual intervention, or would an upload that makes such a change go through as quickly as a normal upload would go through? Hypothetical situation: a compiled executable gets replaced with a shell script. Real situation: an architecture-dependent library packages gets replaced by an architecture-independent dummy transitional package. As far as I can tell from my own experiments, the override file does not know anything about this, and apt-get upgrade/dist-upgrade are happy to upgrade a package whose architecture status has changed. I just want to double check to avoid an unnecessary delay in planning a package transition. Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gnome-pilot: is it a way to make this work?
Hi... I've discovered that gnome-pilot doesn't work at all with my palm (zire 31, but I guess that it doesn't matter). It works ok with pilot-xfer and jpilot, but gnome-pilot just timeouts forever. I was going to fill a bug report, but there are lots of (important) them!! I've straced (with -f) gpilotd-control-applet and there are __NOT__ any open() of the pilot device, just an access() that success. I've tried to dig a bit in the sources, but gnome is too complex for me :( Is this program working at all for somebody? If not, it shouldn't go to sarge. Can we make this working in some way? Regards, -- Roberto Lumbreras .''`. Debian Developer `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
Marcelo E. Magallon writes: > On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote: > > > > occurs when you have for example an ev56 library in lib/ev56, and a > > > ev67 CPU. Then the loader looks in lib/ev67 and then falls back to > > > lib. Since glibc is very carefully undocumented in this area [1], I > > > didn't want to try to change this, but rather assumed one could add > > > a symlink. > > > > Yes, and if ev67 is instruction upper compatible with ev56 (I guess > > so), I think it's acceptable to add a symlink "ln -sf > > lib/ev67/libfoo.so lib/ev56/libfoo.so". > > Ugh... that pushes the burden of maitaining support for new > architectures to the package. Please bear with me, but I'm trying > to understand the issue: is the cost of calling access(2) or stat(2) > really so high? I'd consider it quite acceptable in this case. However, as I tried to express, it's not possible with glibc's current "design", and I didn't feel like changing that. > I see for example that on start up the file /etc/ld.so.nohwcap is > accessed multiple times (and it's not present, isn't that a race? > what happens if the file suddenly appears in the middle of program > start up? what's that file anyway, I can't find it mentioned in the > documentation). It's supposed to disable the use of hwcaps. Stating it multiple times seems like a bug. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changing architecture from any to all
On Sun, Jan 16, 2005 at 02:58:24PM -0500, Jay Berkenbilt wrote: > Hypothetical situation: a compiled executable gets replaced with a shell > script. > Real situation: an architecture-dependent library packages gets > replaced by an architecture-independent dummy transitional package. Real situation: by mistake package was uploaded with Architecture: any, when should be Architecture: all. Solution: upload package with correct Architecture field. No other actions was required. > As far as I can tell from my own experiments, the override file does > not know anything about this, and apt-get upgrade/dist-upgrade are > happy to upgrade a package whose architecture status has changed. Indeed. > I just want to double check to avoid an unnecessary delay in planning a > package transition. You can always use the experimental distribution. First, you can test if package required additional action from archive maintainers. Second, experimental and unstable share override file. You can upload package to experimental, wait for approve - if needed, then upload it to unstable with instant result. Cheers Artur -- windows jest jak Odie - głupi jak but, cały czas się uśmiecha, a linux jak Garfield - może i by coś zrobił, ale trzeba go najpierw do tego zmusić. /yacoob/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changing architecture from any to all
On Sun, 16 Jan 2005, Jay Berkenbilt wrote: > If one changes the architecture of a package from "any" to "all" but > makes no change to the package name, does this require any special > manual intervention, or would an upload that makes such a change go > through as quickly as a normal upload would go through? It would go as quickly as a normal upload. (Or maybe even quicker, as it is built for 11 architectures "instantly" :-) The things that need changes in the override file are changes in the source package name, changes in any of the binary package names, or addition of new binary packages. If you want to see a recent experiment, I changed a package to be "Architecture: all" very recently and nothing special happened. See: http://ftp.debian.org/debian/pool/main/c/cd-circleprint for example. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: backgrounds-debian-shell -- Photography of shells aligned to form the Debian logo
On Sun, 2005-01-16 at 19:31 +0100, GÃrkan SengÃn wrote: > Package: wnpp > Severity: wishlist > > * Package name: backgrounds-debian-shell > Version : 1.0 > Upstream Author : Jakub Budziszewski <[EMAIL PROTECTED]> > * URL : http://linuks.mine.nu/jakub/ > * License : Artistic License > Description : Photography of shells aligned to form the Debian logo > A photography that consists of shells aligned to form the > Debian logo. A package for a single background is a remarkably stupid idea. This should go in desktop-base. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
xfce-goodies - help needed; Rudy Godoy MIA?
On Sun, Jan 16, 2005 at 02:57:57PM -0800, Steve Langasek wrote: > On Sun, Jan 16, 2005 at 05:26:35PM +, Simon Huggins wrote: > > Package: wnpp > > Severity: wishlist > There are currently 11 orphaned xfce4-* packages in unstable, including > three that have just been removed from testing due to RC bugs that went > virtually unnoticed since the last upload in May. I know the -goodies packages are in bad shape. > Please take some time to help figure out what should be done with > these packages -- cleaned up/adopted, or removed from the archive -- > before ITPing more packages in the xfce4 namespace. Sure. I think for sarge they can be cleaned up/updated. I've just finished a stretch getting the 22 packages for the main body of xfce4 for 4.2.0 for experimental sorted this weekend so I'm a bit knackered currently. To be honest I'd been expecting others to sort out the -plugins for sarge given people had said they would. Rudy Godoy seemed interested at one point but now his mail is bouncing though I'm ccing him again in case it got fixed. Likewise Emanuele Rocca seemed interested. There were some packages that made it to mentors.debian.net - and there is still some work up there. http://mentors.debian.net/debian/pool/main/x/ I'll try and pull something together for unstable against the 4.0.x libs I guess at some point but if others have more time and inclination then I'd be much obliged of the help. -- --( "That's why we like you, Mulder; your ideas are )-- Simon ( weirder than ours." - Byers) Nomis Htag.pl 0.0.22 pgpRY8uGMG0Cq.pgp Description: PGP signature
Bug#290829: ITP: libupnp -- Intel Universal Plug And Play SDK for Linux
Package: wnpp Severity: wishlist * Package name: libupnp Version : 1.2.1 Upstream Author : Intel Corporation * URL : http://upnp.sourceforge.net/ * License : BSD Description : Intel Universal Plug And Play SDK for Linux The Linux SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification - see http://www.upnp.org/ for specifications. . The libupnp package contains the runtime libraries; see libupnp-dev for the headers needed for developing programs using libupnp. libupnp is required for another package I'm ITPing - wmaloader. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... signature.asc Description: Digital signature
Bug#290832: ITP: wmaloader -- firmware downloader for Linksys WMA11B media adapter
Package: wnpp Severity: wishlist * Package name: wmaloader Version : 0.1a Upstream Author : Andrew Wild <[EMAIL PROTECTED]> * URL : http://www-jcsu.jesus.cam.ac.uk/~acw43/projects/wma11b/wmaloader.html * License : GPL Description : Firmware downloader for Linksys WMA11B media adapter wmaloader is a simple program that can download filesystem images to the Linksys WMA11b. It performs the same function as the Windows XP/2000 Digital Media Adapter Application Loader (supplied with the original software) but can run on other operating systems. wmaloader is a simple program that allows the Linksys Wireless Media adapter to be booted from a linux system. It does *not* supply media files to the device (yet!) but even so it might prove useful to those who wish to experiment hacking the device. With wmaloader, daapd and wmamp (all Free Software), it's possible to run a WMA11B media adapter to play audio from your network without needing any proprietary software installed. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim." [ seen in ucam.chat ] signature.asc Description: Digital signature
Re: xfce-goodies - help needed; Rudy Godoy MIA?
Citando Simon Huggins <[EMAIL PROTECTED]>: > > I know the -goodies packages are in bad shape. > > > Please take some time to help figure out what should be done with > > these packages -- cleaned up/adopted, or removed from the archive -- > > before ITPing more packages in the xfce4 namespace. > > Sure. I think for sarge they can be cleaned up/updated. I've just > finished a stretch getting the 22 packages for the main body of xfce4 > for 4.2.0 for experimental sorted this weekend so I'm a bit knackered > currently. > > To be honest I'd been expecting others to sort out the -plugins for > sarge given people had said they would. > Hi, > Rudy Godoy seemed interested at one point but now his mail is bouncing > though I'm ccing him again in case it got fixed. > I've already had the new revisions waiting for a while at mentors.debian.net I've asked a couple (or more) of times for sponsoring at -mentors and to the xfce team withouth luck. Didn't "pushed" that much anyway, I mean talk to my actual sponsors, I was going to do ask for it in these days. Well, despite all that, I'm able to provide the updates for such packages and a couple of new plugins like wireless monitor. I'll upload all them this week to my website, so any prospective sponsor can grab and hopefully push them into the archives. regards, -Rudy This message was sent using IMP, the Internet Messaging Program. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
should changelogs be in chronological order
Should changelogs be in chronological order or should they be in version number order? Specifically I just noticed that libtiff4's changelog is out of chronological order[attached for reference]. It seems that the maintainer was maintaining two branches: an experimental branch[3.6.1-3->3.7.0-1->3.7.0-2], and an unstable/testing branch[3.6.1-3->3.6.1-4->3.6.1-5]. 3.7.1-1 would then be potentially descended from either branch. If it is from the experimental branch, then the ->3.6.1-4->3.6.1-5 entries aren't applicable and vice versa. Then again 'removing' them[the changelog entries] opens up a whole other can of worms[hence the post to devel]. More importantly, I don't think it is explicitly clear in the changelog whether or not CAN-2004-1183 and CAN-2004-1308 are fixed in 3.7.1-1[though implicitly I assume they are, but stranger things have happened]. Travis tiff (3.7.1-1) unstable; urgency=low * New upstream release * Correct error in doc-base file (Closes: #285652) -- Jay Berkenbilt <[EMAIL PROTECTED]> Wed, 5 Jan 2005 16:54:12 -0500 tiff (3.7.0-2) experimental; urgency=low * Replace hard-coded libc6-dev dependency with something friendlier to porters (libc6-dev | libc-dev). (Closes: #179727) * Fixed upstream: proper netbsdelf*-gnu support in configure. Actually fixed in 3.7.0-1 but left out of changelog. (Closes: #179728) * Include opengl support; adds new libtiff-opengl package. (Closes: #219456) * Fixed upstream: fax2ps now allows access to first page. (Closes: #244251) -- Jay Berkenbilt <[EMAIL PROTECTED]> Sat, 11 Dec 2004 09:51:52 -0500 tiff (3.7.0-1) experimental; urgency=low * New upstream release (Closes: #276996) * New maintainer (Thanks Joy!) * Repackage using cdbs and simple-patchsys to fix some errors and simplify patch management * Fixed upstream: tiff2pdf ignores -z and -j (Closes: #280682) * Fixed upstream: Memory leak in TIFFClientOpen (Closes: #256657) -- Jay Berkenbilt <[EMAIL PROTECTED]> Fri, 26 Nov 2004 13:50:13 -0500 tiff (3.6.1-5) unstable; urgency=high * New maintainer (thanks Joy!) * Applied patch by Dmitry V. Levin to fix a segmentation fault [tools/tiffdump.c, CAN-2004-1183] Thanks to Martin Schulze for forwarding the patch. * Fixed section of -dev package (devel -> libdevel) -- Jay Berkenbilt <[EMAIL PROTECTED]> Wed, 5 Jan 2005 16:27:26 -0500 tiff (3.6.1-4) unstable; urgency=high * Fix heap overflow security bug [CAN-2004-1308]. (Closes: #286815) -- Jay Berkenbilt <[EMAIL PROTECTED]> Wed, 22 Dec 2004 10:20:52 -0500 tiff (3.6.1-3) unstable; urgency=medium * Patches from upstream to fix zero-size tile and integer overflow problems created by previous security patches, closes: #276783. * Added Jay Berkenbilt as co-maintainer. Jay thanks Joy for letting him help and eventually take over maintenance of these packages! -- Josip Rodin <[EMAIL PROTECTED]> Mon, 01 Nov 2004 12:28:27 +0100 tiff (3.6.1-2) unstable; urgency=low * Included security fixes for: + CAN-2004-0803 - libtiff/tif_luv.c - libtiff/tif_next.c - libtiff/tif_thunder.c + CAN-2004-0804 (but this one is already applied upstream, it seems) - libtiff/tif_dirread.c + CAN-2004-0886 - libtiff/tif_aux.c - libtiff/tif_compress.c - libtiff/tif_dir.c - libtiff/tif_dirinfo.c - libtiff/tif_dirread.c - libtiff/tif_dirwrite.c - libtiff/tif_extension.c - libtiff/tif_fax3.c - libtiff/tiffiop.h - libtiff/tif_getimage.c - libtiff/tif_luv.c - libtiff/tif_pixarlog.c - libtiff/tif_strip.c - libtiff/tif_tile.c - libtiff/tif_write.c Thanks to Martin Schulze for forwarding the patches. -- Josip Rodin <[EMAIL PROTECTED]> Thu, 14 Oct 2004 16:13:11 +0200 tiff (3.6.1-1.1) unstable; urgency=medium * Non-maintainer upload; thanks to Jay Berkenbilt <[EMAIL PROTECTED]> for preparing the patches * Rename shared library and development packages to resolve accidental upstream ABI change. Closes: #236247 * Include patch from upstream to fix multistrip g3 fax bug. Closes: #243405 * Include LZW support. Closes: #260242, #248490 * Fix URL in copyright file. Closes: #261357 * Install missing documentation files. Closes: #261356 -- Steve Langasek <[EMAIL PROTECTED]> Sun, 25 Jul 2004 10:28:06 -0400 tiff (3.6.1-1) unstable; urgency=low * New upstream version, closes: #231977. * Slightly fixed up the static lib build rules so that the build process does the normal stuff for the dynamic lib and then does the static with the same tiffvers.h. -- Josip Rodin <[EMAIL PROTECTED]> Mon, 23 Feb 2004 18:23:34 +0100 tiff (3.5.7-2) unstable; urgency=high * Added back the patch that used -src static/libtiff.a in the install rule. Wonder how that disappeared... closes: #170914. * Fake it's a GNU system in order for the configure script to use our toolchain stuff on the Ne
Re: intent to rename vips7.10 -> vips
Jay Berkenbilt wrote: The recent threads on sonames and package names convinced me beyond a doubt that I made a mistake in the names of the vips packages. Oh dear... [...] Right now, the vips7.10 source package creates four binary packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and libvips7.10-doc. My intention is to do the following: Create new source package "vips" which will create four binary packages: libvips10, libvips-dev, libvips-tools, libvips-doc. (10 is the current soname.) There's no real reason to change "libvips7.10" to "libvips10" -- the package name doesn't have to match the soname, it just has to change whenever the soname does. So if you've matched "libfoo" to a soname of 4, you don't have to do anything beyond renaming the package when version 5 comes out -- and that's the point you should say "ah, I can call it libfoo5 now". Changing the -dev package name isn't a huge win -- having it Provides:/Conflicts: with "libvips-dev", encouraging your users to build-depend on the unversioned -dev, then just changing the package name when your soname next gets bumped is just as effective. OTOH, when the soname gets bumped you generally don't want to change the source package name so you get to avoid waiting for bugs like #283145 to be dealt with, and source package names basically don't affect users at all. libvips-tools and libvips-doc likewise can probably lose their version happily, presuming people who Depend: on libvips-dev today, and end up getting the tools from soname 11 aren't going to be unhappy. But for both of those you should be able to just have "libvips-* Conflicts:/Provides:/Replaces: libvips7.10-*" to satisfy dependencies. Each package Conflicts with the package it replaces with a version << the future dummy transition version of the existing packages and Replaces the old package as well. For example: I'm fairly sure the above should ensure you don't need any dummy packages, and gain all the benefits you were aiming for. Dummy packages are almost always evil. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfce-goodies - help needed; Rudy Godoy MIA?
On Sun, Jan 16, 2005 at 10:20:49PM -0500, Rudy Godoy wrote: > Citando Simon Huggins <[EMAIL PROTECTED]>: > > I know the -goodies packages are in bad shape. > > > Please take some time to help figure out what should be done with > > > these packages -- cleaned up/adopted, or removed from the archive -- > > > before ITPing more packages in the xfce4 namespace. > > Sure. I think for sarge they can be cleaned up/updated. I've just > > finished a stretch getting the 22 packages for the main body of xfce4 > > for 4.2.0 for experimental sorted this weekend so I'm a bit knackered > > currently. > > To be honest I'd been expecting others to sort out the -plugins for > > sarge given people had said they would. > Hi, > > Rudy Godoy seemed interested at one point but now his mail is bouncing > > though I'm ccing him again in case it got fixed. > I've already had the new revisions waiting for a while at mentors.debian.net > I've asked a couple (or more) of times for sponsoring at -mentors and > to the xfce team withouth luck. Didn't "pushed" that much anyway, I > mean talk to my actual sponsors, I was going to do ask for it in these > days. If you have fixes for the release-critical bugs on xfce4-diskperf-plugin and xfce4-showdesktop plugin, and are planning to adopt these packages, I would be willing to sponsor these uploads if you can point me to the source packages. In general, if you're looking to adopt a package with RC bugs and you have packages that need sponsoring, I would recommend posting your packages' URL to the BTS; the choice between sponsoring a maintainer upload, and removing the package from testing, is usually an easy one. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: should changelogs be in chronological order
Travis Crump wrote: Should changelogs be in chronological order or should they be in version number order? The changelog should be in the order changes were made. Specifically I just noticed that libtiff4's changelog is out of chronological order[attached for reference]. It seems that the maintainer was maintaining two branches: an experimental branch[3.6.1-3->3.7.0-1->3.7.0-2], and an unstable/testing branch[3.6.1-3->3.6.1-4->3.6.1-5]. 3.7.1-1 would then be potentially descended from either branch. If the changelog includes entries from 3.7.0-2 and 2.6.1-5, then 3.7.1-1 should be descended from _both_ branches -- ie, it should include all the changes from both, merging any conflicts. Then again 'removing' them[the changelog entries] opens up a whole other can of worms[hence the post to devel]. More importantly, I don't think it is explicitly clear in the changelog whether or not CAN-2004-1183 and CAN-2004-1308 are fixed in 3.7.1-1[though implicitly I assume they are, but stranger things have happened]. The whole point of the changelog is to make it explicitly clear which changes have been made. If something's listed in the changelog, it's been applied. If not, that's a mistake. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]