Re: debsums for maintainer scripts
On Mon, Dec 01, 2003 at 08:24:09PM +0100, Thomas Viehmann wrote: > Michael Ablassmeier wrote: > > IMHO Lintian should also check if "dh_md5sums" is called and > > print at least a warning if this is not the case. > In principle, I argree, but maybe it's better to check for the presence > of an md5sums file than to "force" (haha) people who don't like it to do > this. > Attached is a linda patch that does that. Maybe I'll post a link the > result of the run on my mirror later. What about checking the content of the md5sum file? Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E L'experience, c'est une connerie par jour mais jamais la même.
Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
On Mon, Dec 01, 2003 at 09:11:52PM +0100, Andreas Barth wrote: > > Before mass bug-filling, it would be necessary to make it mandatory > > which unfortunately is not the case right now afaik. > > Severity: wishlist > Where is the problem? Waste of time ? If it's not mandatory, a full coverage will never happen and without full coverage, most avantages of md5sum are lost. In my opinion it's not difficult to add it to packages without it. As soon as it's mandatory, NMU in delayed queue will be justified and I am sure it would not be long to get full coverage. Of course that post-sarge. I don't see why adding a md5dsum_are_mandatory clause to the debian policy would be difficult (what would be a good reason to not add md5sum to a package?). Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E L'experience, c'est une connerie par jour mais jamais la même.
Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
On Mon, Dec 01, 2003 at 07:43:17PM +0100, Michael Ablassmeier wrote: > Unfortunately many Maintainers do not use "dh_md5sums" to ship > an .md5sums File in their Package(s). This makes it harder to > check the already installed Files on a Debian installation. > > I think, at least Packages like "dpkg" or "gnupg" should call > "dh_md5sums". I was wondering, if it would be usefull to make > a mass bug-filling against these Packages. Before, it would be > nice to have a List of Packages (maybe sorted by Maintainer) > which do not call "dh_md5sums". Before mass bug-filling, it would be necessary to make it mandatory which unfortunately is not the case right now afaik. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Cats are intented to teach us that not everything in nature has a function. --Garrison Keillor
Re: scarriest changelog entry ever?
Shame on me. I did it two days ago with equivs and kept it on my HD but for some reason not in my brain. My only consolation is that I did it because of its FTBFS state. Christophe On Wed, Nov 05, 2003 at 01:49:49PM -0500, christophe barbe wrote: > > amiga-fdisk (0.04-7) unstable; urgency=low > > * First version > > -- My Name <[EMAIL PROTECTED]> Mon, 3 Nov 2003 20:06:59 -0500 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Things should be made as simple as possible, but not any simpler. -- Albert Einstein
scarriest changelog entry ever?
amiga-fdisk (0.04-7) unstable; urgency=low * First version -- My Name <[EMAIL PROTECTED]> Mon, 3 Nov 2003 20:06:59 -0500
Re: Source only uploads?
On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > > - Architecture: all packages would not get built
> >
> > Well, we just need an arch: all autobuilder and that's it, or one of the
> > autobuilders building the arch: all stuff.
>
> Feel free to set up one.
I feel like I am missing something here. Could you explain
"Architecture: all packages would not get built"? Is the problem with
binary arch independent packages?
> > The reason why source only uploads (or binary uploads where the binary
> > part is ignored) are good, is that they limit the errors that may be
> > introduced by the DD build environment, which may be a bit more than
> > just sid. Like when you have XFree86 4.3.0 experimental packages
> > installed for example.
>
> The reason why source only uploads are bad, is that they encourage bad
> practice such as people not checking the build. By requiring at least
> one binary package, we ensure the package can at least be built. That's
> a good thing, since it saves time otherwise wasted on packages failing
> to build because the maintainer didn't even bother to test.
>
> I have less problems with the second part of your suggestion ("binary
> uploads where the binary part is ignored"), as long as it's not so
> time-consuming that becomes a problem (which I'm afraid is likely to be
> the case).
"binary uploads where the binary part is ignored" sounds very good. I
don't expect problems related to "time-consuming" since most binary
uploads are for x86 these days and x86 autobuilder cpu time should not
be very hard to find.
> > And if we are going to use experimental more and more, like aj
> > suggested, this is going to be more and more of a problem in the future.
>
> Since experimental isn't autobuilt, I fail to see your point.
It believe he means that dd are more likely to have experimental
packages installed on their systems and thus upload broken binary
packages.
Christophe
--
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
In theory there is no difference between theory and practice. In
practice there is. -- Yogi Berra
Re: bug report #208857 disappeard ?
Sorry for this. Let's say it was Monday. Christophe On Mon, Sep 08, 2003 at 06:26:27PM -0400, Christophe Barbe wrote: > I don't understand why but I am unable to find a bug report I filled 3 > days ago. Can someone explain me what happen? > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=208857 > > See below the ack from bugs.debian.org. I even submitted more info (a > full trace that took me a long time to get). > > Christophe > > -Message suivi- > From: Debian Bug Tracking System <[EMAIL PROTECTED]> > To: christophe barbe <[EMAIL PROTECTED]> > Subject: Bug#208857: Acknowledgement (gimp1.3: Segfault on Layer Mask in > Layer Dialog on PowerPC) > Date: 05 Sep 2003 12:33:06 -0500 > > Thank you for the problem report you have sent regarding Debian. > This is an automatically generated reply, to let you know your message has > been received. It is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Ari Pollak <[EMAIL PROTECTED]> > > If you wish to submit further information on your problem, please send > it to [EMAIL PROTECTED] (and *not* to > [EMAIL PROTECTED]). > > Please do not reply to the address at the top of this message, > unless you wish to report a problem with the Bug-tracking system. > > Debian bug tracking system administrator > (administrator, Debian Bugs database) > -- > Christophe Barbe <[EMAIL PROTECTED]> > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs believe they are human. Cats believe they are God.
bug report #208857 disappeard ?
I don't understand why but I am unable to find a bug report I filled 3 days ago. Can someone explain me what happen? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=208857 See below the ack from bugs.debian.org. I even submitted more info (a full trace that took me a long time to get). Christophe -Message suivi- From: Debian Bug Tracking System <[EMAIL PROTECTED]> To: christophe barbe <[EMAIL PROTECTED]> Subject: Bug#208857: Acknowledgement (gimp1.3: Segfault on Layer Mask in Layer Dialog on PowerPC) Date: 05 Sep 2003 12:33:06 -0500 Thank you for the problem report you have sent regarding Debian. This is an automatically generated reply, to let you know your message has been received. It is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Ari Pollak <[EMAIL PROTECTED]> If you wish to submit further information on your problem, please send it to [EMAIL PROTECTED] (and *not* to [EMAIL PROTECTED]). Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Christophe Barbe <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Accepted gdesklets-data 0.13.1 (all source)
On Tue, Aug 26, 2003 at 04:38:51PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > > Is there something preventing the use of a .orig.tar.gz tarball. It > > would be nice to see a .orig.tar.gz containing only upstream bits and > > the debian stuff in the diff, for review purpose and for bandwith > > saving. > > Again. It's a debian _native_ package, there is no such thing as "upstream" > in native packages. What makes it a native package? Or if you prefer, what prevent it of not being a native package? One of the inconvenient of the 'native' format used for a package made of upstream tarballs is that it makes it difficult to review (and also waste some bandwith). In this particular case, the diff.gz could certainly contains only the debian directory. But I agree that the tarball will be custom made for debian. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E In theory there is no difference between theory and practice. In practice there is. -- Yogi Berra
Re: Accepted gdesklets-data 0.13.1 (all source)
On Tue, Aug 26, 2003 at 02:23:56PM +0200, Sebastien Bacher wrote: > Yes, gdesklets-data is a debian native package (ie: there is no upstream > tarball corresponding to this archive). Thanks for the explaination. > -n version are revision on a same upstream tarball, but in this case we > don't have any .orig.tar.gz Is there something preventing the use of a .orig.tar.gz tarball. It would be nice to see a .orig.tar.gz containing only upstream bits and the debian stuff in the diff, for review purpose and for bandwith saving. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: Accepted gdesklets-data 0.13.1 (all source)
On Mon, Aug 25, 2003 at 08:32:10PM -0400, Sebastien Bacher wrote: > Source: gdesklets-data > Binary: gdesklets-data > Architecture: source all > Version: 0.13.1 > Distribution: unstable > Urgency: low > Maintainer: Sebastien Bacher <[EMAIL PROTECTED]> > Changed-By: Sebastien Bacher <[EMAIL PROTECTED]> > Description: > gdesklets-data - displays and sensors for gdesklets > Closes: 207088 > Changes: > gdesklets-data (0.13.1) unstable; urgency=low > . >* Fixed the wrong directory in README.Debian (Closes: #207088). > Files: > 85b18c208186cbe6a86b48c23e78b9d3 526 x11 optional gdesklets-data_0.13.1.dsc > 5b5c46862fbb651b34ef1c090cbcd776 344185 x11 optional > gdesklets-data_0.13.1.tar.gz > c18e378be01cbdb68d8121b464eada4b 319230 x11 optional > gdesklets-data_0.13.1_all.deb Is it a common practice to use this kind of numbering (without a second part after a dash) for what I presume is a debian-made tarball (multiple upstream tarballs put together). gdesklets-data_0.13.1_all.deb Also (related) why not use a orig.tar.gz file? My understanding is that the difference between 0.13.1 and 0.13, because only the README.Debian has changed, it would have been a good thing to base it on the previous tarball. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E There is no snooze button on a cat who wants breakfast.
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 08:07:56PM +0300, Richard Braakman wrote: > On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote: > > In this case, libexif8 -> libexif9, this is a major soname bump, so should > > have required a new source package. The maintainer was probably derelict in > > this case. > > Uh, no. Changing the binary package name the way we've always > handled soname changes, except with a small number of very popular > libraries. It's a lot less work, and it doesn't require creating a > new package that will be orphaned almost instantly. If it turns out > to be a problem for a particular library, and oldlibs package can > be created for it afterwards, when the need for it has been demonstrated. > > Richard Braakman Amen. -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Cats are intented to teach us that not everything in nature has a function. --Garrison Keillor
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote: > In this case, libexif8 -> libexif9, this is a major soname bump, so should > have required a new source package. The maintainer was probably derelict in > this case. The source package is libexif independently of the soname. Are you suggesting that ALL library packages should come with a new source package for each major soname change? I was not derelict. If you have good arguments to answer yes to the above question, please give them to me. In the mean time I will keep doing it the way I believe makes the more sense and which happens to be a very common practice. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Whether you believe you can, or whether you believe you can't, you're absolutely right. --Henry Ford
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 10:18:37AM +0200, J?r?me Marant wrote: > Usually, you can use apt-cache showpkg libexif8 and send a message to > every maintainer whose package depends on it, asking to rebuild against > the new libexif9. When everyone has rebuilt against the new lib, > then you can ask for the removal of the old library. Read the thread, which is very informative. The first thing you will learn is that packages are removed from the archive automatically. Christophe > > Cheers, > > -- > J?r?me Marant > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs believe they are human. Cats believe they are God.
Re: libraries being removed from the archive
Ok, sorry for being rude in my previous mail. I understand the general problem that you are facing with KDE and will try in the future to announce upcomming soname changes. Concerning the removal, I don't really see the point of not removing older libraries from unstable. Most of the time, rebuilding the package is enough to fix the UNINSTALLABLE problem. My understanding of what you want is some kind of direct upload to testing which is not the intented purpose of unstable. Btw a new libgphoto2 is comming soon ;-) Christophe On Sun, Aug 03, 2003 at 05:16:59PM -0500, Chris Cheney wrote: > On Sun, Aug 03, 2003 at 05:31:37PM -0400, christophe barbe wrote: > > You are kidding right? > > > > I have not removed an old library, I have uploaded a newer upstream with > > a different soname. That's the way it works, a new library is uploaded, > > then packages using it are rebuilt and when they are all ready they > > migrate in testing. > > > > As the gphoto2 maintainer, I don't remember getting mails from you > > announcing an upcoming libusb package with a new soname. Perhaps that's > > because I was waiting for a few months to get a working one for our > > powerpc users. > > > > IMHO we need to make an addition to the policy stating that not being an > > asshole on the mailing-list is welcome. I don't remember sending mails > > to the mailing list when the libusb packaging was broken for a few > > months, but I do remember sending you polite mails. > > > > For you information, some packages using libexif need libexif9. > > I agree that I could (should) have sent a prior notice before uploading it > > (more than a week ago, BEFORE your kdegraphics upload), but that's not > > an excuse to be an asshole. > > > > Christophe > > You aren't the only one that has broken things, many other people > including myself have as well, I most notably with libvorbis ;). However, > this libusb soname change you mention last happened on Feb 27 2002, > which was changed due to a RC bug regarding its naming. (BTW libusb's > soname is odd, which is why I didn't catch it sooner). Also you mention > that libusb was broken for several months, which is true, but it was > only broken on one arch (powerpc). Also, from what I can tell from > looking back at it by the time you determined it wasn't a bug in > gphoto2 you NMU'd it within a week. I don't recall if I was actually > aware of the bug before you NMU'd it. > > Also, I was not stating that libexif9 should not be uploaded, only that > old libraries should not be removed from the archive until they are no > longer used, which apparently was not the case for libexif8. I don't > recall if I stated this earlier but each time I have uploaded KDE in the > past several months it has been broken by library removals within about > a week and recompiling KDE sources is not light work for the buildds. > > Seriously, if we want to ever release sarge we are going to need to stop > making libraries disappear, every time we rebuild something it takes > another 10 days for it to migrate into testing and everything that > depends on it is also pushed back another 10 days. Even if the person > causing the breakage NMU's all the affected packages it still causes > them to wait another 10 days to migrate, and causes unneeded load on > the buildds, possibly with the packages no longer being able to be > built since gcc 3.3 is so anal now. (/me wonders how many RC bugs are > around just for gcc 3.3 related crap) > > BTW - For those wondering Woody was released over a year ago... > > Thanks, > > Chris Cheney > > PS - I apologize for sounding like an asshole, however this general > problem really does need fixing. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Cats seem go on the principle that it never does any harm to ask for what you want. --Joseph Wood Krutch
Re: libraries being removed from the archive
You are kidding right? I have not removed an old library, I have uploaded a newer upstream with a different soname. That's the way it works, a new library is uploaded, then packages using it are rebuilt and when they are all ready they migrate in testing. As the gphoto2 maintainer, I don't remember getting mails from you announcing an upcoming libusb package with a new soname. Perhaps that's because I was waiting for a few months to get a working one for our powerpc users. IMHO we need to make an addition to the policy stating that not being an asshole on the mailing-list is welcome. I don't remember sending mails to the mailing list when the libusb packaging was broken for a few months, but I do remember sending you polite mails. For you information, some packages using libexif need libexif9. I agree that I could (should) have sent a prior notice before uploading it (more than a week ago, BEFORE your kdegraphics upload), but that's not an excuse to be an asshole. Christophe On Sat, Aug 02, 2003 at 09:32:37PM -0500, Chris Cheney wrote: > Today I was reminded of something that causes apps not to migrate into > sarge. When maintainers remove old libraries from the archive! Today > for example libexif8 was removed by Christophe Barbe and replaced by > libexif9. Guess what that does... any package which depends on libexif8 > now becomes... you guessed it... UNINSTALLABLE! Why does this annoy me > in particular, because I just uploaded kdegraphics yesterday which was > built against libexif8. Guess how many hours it takes for the m68k > buildd to rebuild kdegraphics. OVER 38 HOURS! > > IMHO we need to make an addition to policy stating that an old lib can > not be removed from the archive until no other packages still depend on > it. > > Chris Cheney > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E A qui sait comprendre, peu de mots suffisent. (Intelligenti pauca.)
Re: Attn: Mass bug filing: libtool requires updating
On Sun, Jun 29, 2003 at 07:52:57PM +0100, Scott James Remnant wrote: > Version 3.39-1 of the file utility changed the format of the output line > for MIPS shared libraries again. > > Older versions of libtool.m4 use the file utility and a regular > expression to determine if something is a shared library or not. This > regular expression does not match the new file output format. > > Newer versions of libtool instead use a much better checking method, > however the following source packages have not updated (list obtained by > grepping mips and mipsel build logs for the warning). > > gphoto gphoto has been removed from unstable and will not be in the next stable release. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs come when they're called; cats take a message and get back to you later. --Mary Bly
Re: Packages preventing other packages from going into testing (fwd) (fwd)
Looks like your KMail is doing strange things with the In-Reply-To header (using a wrong Message-ID). Your last mail contains: In-Reply-To: <[EMAIL PROTECTED]> In reply to: Message-ID: <[EMAIL PROTECTED]> Ie you break all threads you are replying to. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs come when they're called; cats take a message and get back to you later. --Mary Bly
Re: Only .changes files are readable in NEW/
On Thu, Apr 24, 2003 at 10:00:49PM +0200, Frank Lichtenheld wrote: > When I read http://www.debian.org/legal/cryptoinmain correct, all > Software that contains cryptographic functionality must be registered > before it can legally be distributed. So the ftp-master must check if > a new package contains cryptographic functionality and if it is > already registered. Thanks for the explanation and the link. Sounds like a good reason. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E There is no snooze button on a cat who wants breakfast.
Re: Only .changes files are readable in NEW/
On Thu, Apr 24, 2003 at 02:30:35PM +0200, J?r?me Marant wrote: > Yes, it is normal. The reason is crypto-in-main: they have to be > checked by ftp-masters first. I don't see why they should not be readable by everyone before being checked by ftp-master. I don't said I disapprove that (for what it would worth) but I don't understand the logic. Can someone explain? Thanks, Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Ce que l'on conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément. Nicolas Boileau, L'Art poétique
Only .changes files are readable in NEW/
I wonder why only the .changes files are readable in the NEW queue. Is there a reason for this? Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E There is no snooze button on a cat who wants breakfast.
Bug#170809: ITP: libgphoto2 -- The gphoto2 digital camera library
Package: wnpp Version: unavailable; reported 2002-11-26 Severity: wishlist * Package name: libgphoto2 Version : 2.1.1 Upstream Author : The gphoto2 team * URL : http://www.gphoto.org/ * License : LGPL Description : The gphoto2 digital camera library I am the maintainer of gphoto2. The upstream has splitted gphoto2 in two: libgphoto2: the library gphoto2: the command-line front-end I will follow the upstream and starting with the next release (coming soon) the gphoto2 package will contains only the command-line front-end and the lib will comes from the libgphoto2 source package. Christophe -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux philly 2.4.20-rc1-ben0 #1 Thu Nov 14 22:18:04 EST 2002 ppc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Orphaning xmlto
I am thinking about orphaning xmlto. It's a very useful package but I am not very uptodate with sgml/xsl and I know nearly nothing about TeX (and doesn't want to). So if someone is interested and feels he can do a better job, I would be happy. Most current bugs are fixed in the new upstream but unfortunately I fail to package it (I can provide details). Also debian is STILL missing xml-catalog so I patch the source to point to local .xsl .dtd files to do a best effort (but this is not good because when you want to process a file, this file is likely to contains url too). Let me know, Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Things should be made as simple as possible, but not any simpler. -- Albert Einstein
Re: broken dependencies gphoto2
On Fri, Nov 22, 2002 at 08:05:43AM -0800, Craig Dickson wrote: > There is already a bug filed about this: #170292. The maintainer replies: > > "gphoto2 2.1.0 is not compatible with the new libexif in debian/sid. > gphoto2 2.1.1 will be out soon, the package is ready. > I will upload gphoto2 2.1.1 as soon as possible." > > Craig And in a later mail to the BTS I added an url for the package of the release candidate of the soon to be released 2.1.1. Christophe -- Christophe Barbé <[EMAIL PROTECTED]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E In a cat's eye, all things belong to cats. --English proverb
