Re: RFS: tuxcmd
Dne Tue, 9 Dec 2008 08:00:46 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): Hi On Mon, Dec 08, 2008 at 10:29:15PM +0100, Salvatore Bonaccorso wrote: On Mon, Dec 08, 2008 at 03:06:00PM +0100, Michal Čihař wrote: Dne Sun, 7 Dec 2008 19:25:47 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tuxcmd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd/tuxcmd_0.6.50-1.dsc Why is it only arch: i386 amd64? Also debian/copyright lacks some information: - translation copyrights are not included - also some source files have more than one copyright holders [...] I fix this issues when preparing to upload a new version to check, following the proposal, thanks! The reason I used only arch i386 and amd64, was bit stupid as I was not sure if the package would also build cleanly under the other architectures. See the note of the Author on: https://bugzilla.redhat.com/show_bug.cgi?id=449367 Only a further note on this. tuxcmd uses some parts, which is not available on all architectures. fp-compiler is only available for amd64, arm, i386, powerpc and sparc. How should I handle this correctly? GTK+ 2 units in same way also only for the above archs. Extend arch also for those archs and then try if tuxcmd will compile also under those architectures? If build depends are not available, you don't care. Just make the package arch: all and builders will handle this. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFS: tuxcmd
Hi Dne Mon, 8 Dec 2008 22:29:15 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): Yes I have to rephrase these sentences. The reason about that is the following: upstream ships the base filemanager tuxcmd in a source tarball, and in another tarball some modules (the above claimed, and I should rephrase the description for tuxcmd itself). For the modules I filled an separate ITP (see http://bugs.debian.org/508082). The second I have to repackage the upstream tarball to remove the non free module parts (unrar and libarchive plugin). What's non-free on libarchive? It's already packaged in main. I guess same applies to unrar (there is free unrar, but there is no free rar). Then tuxcmd-modules will extend tuxcmd by these additional modules. This second package tuxcmd-modules I have not yet ready to upload to mentors.debian.net, which then will extend the functionality of tuxcmd if installed. So that is what I ment or wanted to say in the README.Debian, but I should do better. The tuxcmd package contains the base Tux Commander file manager. To extend the functionality using some VFS modules available you need to install the additional package tuxcmd-modules. Should explain the situation better. Since english is not my native language I should also post to the l10n-list, for checking the package description, for having best possible description. Is this a good approach to this? Or do you think it's still better to import also the free modules into the upstream source and repackage the tarball? Just create new package with plugins (if some of them have excessive external dependencies, package them in separate binary modules) and make tuxcmd suggest/recommend tuxcmd-modules. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: RFS: whohas
On Tue, Dec 09, 2008 at 07:37:44PM +0900, Paul Wise wrote: Uploaded. Thanks! In the next upload, please remove the duplicate space in the last paragraph of the description. Will do. Why was your orig.tar.gz not the same as upstream's? Please always use the upstream tarball unless it has been repacked due to DFSG/other issues. I used the upstream tarball instead of the one you uploaded to mentors. Odd, I haven't intentionally touched it. I'll diff them but could it be cruft from git-buildpackage? -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Hi, In article [EMAIL PROTECTED], Neil Williams[EMAIL PROTECTED] wrote: This component is a shared library and therefore a build dependency. If you are going to force a particular version, you should do it in Build-Depends. dpkg-shlibdeps will then work out the rest using any symbols files that may exist.=20 Ah Ok. So I should list the version in Build-depends, and then $(shlibs:Depends) will do the 'right' thing? But you also need to answer Paul's question - why are you doing this? Answered in response to his post. Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Andy Hawkins wrote:
Hi all,
I'm in the process of building my first package. Most of the dependencies
generated by ${shlibs:Depends} are fine for the package, but I need to force
the version of one particular component.
So I've put
Depends: ${shlibs:Depends}, ${misc:Depends}, libflac++6(=1.2.1)
in the 'control' file. This causes Lintian to issue a warning:
package-has-a-duplicate-relation depends: libflac++6, libflac++6 (= 1.2.1)
According to the man dpkg-gencontrol, just place 'libflac++6(=1.2.1)' before
the '${shlibs:Depends}', and dpkg-control with throw away less strong
dependency.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
Ukrainian C++ Developer, Debian APT contributor
signature.asc
Description: OpenPGP digital signature
Re: Listing dependencies with specific versions
On Tue, Dec 9, 2008 at 10:18 PM, Paul Wise [EMAIL PROTECTED] wrote: Please file a bug about this. I forgot to ask you to ask the release team for binNMUs for the packages using those symbols once the shlibs is fixed. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: whohas
On Tue, Dec 9, 2008 at 4:01 PM, Jonathan Wiltshire [EMAIL PROTECTED] wrote: Uploaded to http://mentors.debian.net/debian/pool/main/w/whohas/whohas_0.21-2.dsc Uploaded. In the next upload, please remove the duplicate space in the last paragraph of the description. Why was your orig.tar.gz not the same as upstream's? Please always use the upstream tarball unless it has been repacked due to DFSG/other issues. I used the upstream tarball instead of the one you uploaded to mentors. Please ask upstream to remove the .DS_Store file from their tarballs in future. You might want to prepare a short article for debaday about this tool; it is really useful. Also, please thank upstream for writing it. Please also suggest adding support for freshmeat, the FSF free software directory and debian-unofficial.org. For future uploads, please contact this list or ping me on #debian-mentors and I will upload if I can. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 11:58:29 + (UTC) Andy Hawkins [EMAIL PROTECTED] wrote: I need to force the version of one particular component. Why is that? Because that version of FLAC includes extra functionality that is detected at compile time. Then it is a build-dependency issue - ensure you have specified that version in Build-Depends. If I compile a binary against the newer FLAC libraries, then I suspect that binary will fail to run with the old ones because this functionality isn't present. dpkg-shlibdeps appears to disagree - either the symbols in FLAC are wrong or your suspicion could be wrong. Are you talking about new symbols in the FLAC library or bug fixes in existing functions? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjV0kM3zgJP.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Hi, In article [EMAIL PROTECTED], Neil Williams[EMAIL PROTECTED] wrote: dpkg-shlibdeps appears to disagree - either the symbols in FLAC are wrong or your suspicion could be wrong. Are you talking about new symbols in the FLAC library or bug fixes in existing functions? New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. My app correctly detects this support at compile time. If it is compiled against a version of FLAC before 1.2, it will not embed pictures. If it see a version = 1.2 then it will. What I'm trying to avoid is a packaged compiled against the flac-dev with the picture support in, being installed on a system where the installed libflac is = 1.2 Hope that makes sense? Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 10:02:25 + (UTC)
Andy Hawkins [EMAIL PROTECTED] wrote:
I'm in the process of building my first package. Most of the
dependencies generated by ${shlibs:Depends} are fine for the package,
but I need to force the version of one particular component.
This component is a shared library and therefore a build dependency.
If you are going to force a particular version, you should do it in
Build-Depends.
dpkg-shlibdeps will then work out the rest using any symbols files that
may exist.
But you also need to answer Paul's question - why are you doing this?
If your package needs = 1.2.1 (and there should be spaces in that
string) then it check for that version during the build. IIRC you then
put the string before shlib:Depends -
e.g. for one of my upstream projects (not yet in Debian)
Depends: libestron0 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
That is a different use case - where the Depends is added to an
internal package to ensure that both are upgraded together. (Policy 8.5)
1. Is this an acceptable method of listing the required libraries, or
should I list all of them individually?
No - extra depends on debian/control should be those that are not
calculated by shlib:Depends. You cannot replace shlib:Depends with a
fixed list.
2. If this is acceptable, will having two 'dependencies' make it do
the right thing?
No.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpHeMWYVxPhc.pgp
Description: PGP signature
Re: Listing dependencies with specific versions
Eugene V. Lyubimkin [EMAIL PROTECTED] (09/12/2008):
package-has-a-duplicate-relation depends: libflac++6, libflac++6 (= 1.2.1)
According to the man dpkg-gencontrol, just place 'libflac++6(=1.2.1)'
before the '${shlibs:Depends}', and dpkg-control with throw away less
strong dependency.
Wrong way to go. Fix libflac (as Paul explained) instead.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins [EMAIL PROTECTED] wrote: New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 Please file a bug about this. Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Hi, In article [EMAIL PROTECTED], Paul Wise[EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 7:02 PM, Andy Hawkins [EMAIL PROTECTED] wrote: I need to force the version of one particular component. Why is that? Because that version of FLAC includes extra functionality that is detected at compile time. If I compile a binary against the newer FLAC libraries, then I suspect that binary will fail to run with the old ones because this functionality isn't present. I originally started packaging my application for Debian just so that I could distribute a binary package myself (and obviously a source package should anyone want to build it). However, if it is useful and can be added to the archive proper then so much the better. Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, Dec 9, 2008 at 7:02 PM, Andy Hawkins [EMAIL PROTECTED] wrote: I need to force the version of one particular component. Why is that? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Listing dependencies with specific versions
Hi all,
I'm in the process of building my first package. Most of the dependencies
generated by ${shlibs:Depends} are fine for the package, but I need to force
the version of one particular component.
So I've put
Depends: ${shlibs:Depends}, ${misc:Depends}, libflac++6(=1.2.1)
in the 'control' file. This causes Lintian to issue a warning:
package-has-a-duplicate-relation depends: libflac++6, libflac++6 (= 1.2.1)
The questions I have are:
1. Is this an acceptable method of listing the required libraries, or should
I list all of them individually?
2. If this is acceptable, will having two 'dependencies' make it do the
right thing?
Thanks
Andy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: replaceit
Dear mentors, I am seeking a sponsor for my updated package replaceit (George Danchev kindly sponsored previously). This upload: * fixes bug 506767, and also * migrated into a git repository with public access * makes proper use of debhelper 7. Even if you're unable to sponsor, a review would be appreciated. The dsc file can be found at http://mentors.debian.net/debian/pool/main/r/replaceit/replaceit_1.0.0-4.dsc Thanks in advance, -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Hi, In article [EMAIL PROTECTED], Paul Wise[EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins [EMAIL PROTECTED] wrote: New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 Please file a bug about this. Umm, I'll try. I'm not sure exactly what that bug report should say! Kind of new to all this Debian packaging stuff (as of this time last week I knew nothing about it!). I should add at this point that the package I'm using is one I compiled myself, not an 'official' Debian package. Can't remember whether it came from Debian or whether I compiled up the .debs direct from the FLAC sources. Is that likely to make a difference? Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Andy Hawkins [EMAIL PROTECTED] (09/12/2008): Please file a bug about this. Umm, I'll try. I'm not sure exactly what that bug report should say! Kind of new to all this Debian packaging stuff (as of this time last week I knew nothing about it!). Short version: “Fix your shlibs.” Slightly longer version: “Remember to bump your shlibs whenever symbols get added. Please fix.” People that maintain libraries should be able to cope with the shorter version. If they don't, they probably shouldn't maintain libraries, or should be mentored for that particular matter. I should add at this point that the package I'm using is one I compiled myself, not an 'official' Debian package. Can't remember whether it came from Debian or whether I compiled up the .debs direct from the FLAC sources. In that case, one would be pretty welcome to check one's findings against the packages that are actually in the archive. In this particular case, as pointed out by Paul, the bug is present in the packages shipped by Debian, so let's report it. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 16:51:50 +0100 Cyril Brulebois [EMAIL PROTECTED] wrote: Andy Hawkins [EMAIL PROTECTED] (09/12/2008): Please file a bug about this. Umm, I'll try. I'm not sure exactly what that bug report should say! Kind of new to all this Debian packaging stuff (as of this time last week I knew nothing about it!). Short version: “Fix your shlibs.” Slightly longer version: “Remember to bump your shlibs whenever symbols get added. Please fix.” People that maintain libraries should be able to cope with the shorter version. If they don't, they probably shouldn't maintain libraries, or should be mentored for that particular matter. Cyril, we've had this discussion before - merely adding symbols does NOT require a SONAME bump. Take a look at glib2.0, libgtk+2.0 and libqof1 - symbols are added all the time and all that is needed is a versioned build-depends and a versioned runtime shlib dependency. In that case, one would be pretty welcome to check one's findings against the packages that are actually in the archive. In this particular case, as pointed out by Paul, the bug is present in the packages shipped by Debian, so let's report it. I doubt that - merely adding a new symbol is NOT a bug, let alone release-critical. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp0XBaRKg8ap.pgp Description: PGP signature
Re: Listing dependencies with specific versions
On Wed, Dec 10, 2008 at 1:03 AM, Neil Williams [EMAIL PROTECTED] wrote: Cyril, we've had this discussion before - merely adding symbols does NOT require a SONAME bump. We are not talking about SONAME bumps, but shlib bumps. Take a look at glib2.0, libgtk+2.0 and libqof1 - symbols are added all the time and all that is needed is a versioned build-depends and a versioned runtime shlib dependency. Right. I doubt that - merely adding a new symbol is NOT a bug, let alone release-critical. Right, but not bumping shlibs at the same time is an RC bug AFAIK. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 22:18:01 +0900 Paul Wise [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins [EMAIL PROTECTED] wrote: New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: That is not a bug - the package building against it merely has to require that version. The bug only arises if symbols are removed or function prototypes are changed in existing symbols. http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 Then a new line gets added for a symbol that only occurs in that version. Please file a bug about this. Please don't - it is not a bug. If it was, we'd be on libglib.so.7787.0.0 by now. Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. The fix is only necessary if the symbol has CHANGED - added symbols can be managed perfectly well without a SONAME bump. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpWhViwiRDdZ.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Neil Williams [EMAIL PROTECTED] (09/12/2008): Short version: “Fix your shlibs.” Cyril, we've had this discussion before - merely adding symbols does NOT require a SONAME bump. Neil, read. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams [EMAIL PROTECTED] (09/12/2008): Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: That is not a bug - the package building against it merely has to require that version. That is. The bug only arises if symbols are removed or function prototypes are changed in existing symbols. Wrong. Please file a bug about this. Please don't - it is not a bug. Please do. If it was, we'd be on libglib.so.7787.0.0 by now. You *do* understand the concept of SONAME and shlibs, right? You *do* understand that those are different things, right? Given some RC bugs against some of your packages, I start doubting it. Too bad you're being so vocal on this list, and so self-confident. Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. The fix is only necessary if the symbol has CHANGED - added symbols can be managed perfectly well without a SONAME bump. Again, wrong. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 16:06:46 + Neil Williams [EMAIL PROTECTED] wrote: The bug only arises if symbols are removed or function prototypes are changed in existing symbols. http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 Then a new line gets added for a symbol that only occurs in that version. Please file a bug about this. Please don't - it is not a bug. If it was, we'd be on libglib.so.7787.0.0 by now. See the list here: http://library.gnome.org/devel/glib/unstable/ Index of new symbols in 2.2 Index of new symbols in 2.4 Index of new symbols in 2.6 Index of new symbols in 2.8 Index of new symbols in 2.10 Index of new symbols in 2.12 Index of new symbols in 2.14 Index of new symbols in 2.16 Index of new symbols in 2.18 Index of new symbols in 2.20 Adding a new function (or several hundred new functions) has absolutely ZERO impact on the SONAME as long as the new functions do not overlap existing functions, change existing functions or require any changes elsewhere in the library that remove or modify existing symbols. Cyril, we need to sort this out for that RC bug that doesn't exist but which you raised the severity - adding a new symbol is NOT a bug, as long as it is done properly (as above). It is up to the package using the library to build-depend on the right version and use a strict dependency on that version or later that supercedes the plain dependency. i.e. exactly what I recommended for this package. Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps does the right thing. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpm6SKbxPz7z.pgp Description: PGP signature
Re: Listing dependencies with specific versions
On 2008-12-09, Paul Wise [EMAIL PROTECTED] wrote: I doubt that - merely adding a new symbol is NOT a bug, let alone release-critical. Right, but not bumping shlibs at the same time is an RC bug AFAIK. I agree. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Wed, Dec 10, 2008 at 1:15 AM, Neil Williams [EMAIL PROTECTED] wrote: Cyril, we need to sort this out for that RC bug that doesn't exist but which you raised the severity - adding a new symbol is NOT a bug, as long as it is done properly (as above). It is up to the package using the library to build-depend on the right version and use a strict dependency on that version or later that supercedes the plain dependency. No, it is up to the library package to declare in it's shlibs file that packages using it should depend on at minimum the latest version of the library that added new symbols. Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps does the right thing. Thats a hack. Another workaround for broken shlibs is debian/shlibs.local. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Neil Williams [EMAIL PROTECTED] (09/12/2008): Adding a new function (or several hundred new functions) has absolutely ZERO impact on the SONAME as long as the new functions do not overlap existing functions, change existing functions or require any changes elsewhere in the library that remove or modify existing symbols. And I said ZERO things about the SONAME, would you please learn to read? And yes, Gtk people are good at not breaking the ABI. But that has ZERO things to do with the current topic. Please (re)focus. Cyril, we need to sort this out for that RC bug that doesn't exist but which you raised the severity - adding a new symbol is NOT a bug, as long as it is done properly (as above). It wasn't in your packaging. Again, shlibs. Again, shlibs!=SONAME. Maybe you've got a broken strcmp() implementation? It is up to the package using the library to build-depend on the right version and use a strict dependency on that version or later that supercedes the plain dependency. i.e. exactly what I recommended for this package. Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps does the right thing. What if you read the Policy? Like e.g. 8.6 (more specifically 8.6.3). I thought it was a prerequisite for doing Debian stuff. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Paul Wise [EMAIL PROTECTED] (10/12/2008): Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps does the right thing. Thats a hack. Another workaround for broken shlibs is debian/shlibs.local. A very dirty one. The other being the one recommended by the Policy, but I don't really want mentored people to try and handle this kind of problem this way, especially if mentored by clueless people (I'm not thinking about you, Paul :) you already know that we agree on this topic). Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: replaceit
On Tuesday 09 December 2008 17:27:28 Jonathan Wiltshire wrote: Dear mentors, I am seeking a sponsor for my updated package replaceit (George Danchev kindly sponsored previously). This upload: * fixes bug 506767, and also * migrated into a git repository with public access * makes proper use of debhelper 7. Uploaded and thanks for your work. One minor thing I'm not too concerned about is that diff.gz directly patches the Makefile [1]. In fact the change is so innocent that using a patch system could be considered an overkill, but anyway you could: a) push that change upsteam; or b) do not try to correct the Makefile, but issue the needed commands directly from debian/rules (not very smart idea, since you would lose make's timestamp facility); or c) use topgit as your patch queue manager, see: /usr/share/doc/topgit/HOWTO-tg2quilt.gz; or d) do nothing, and leave it like that as long as the modification remains as a single logic change and fits in a couple of rows. By no means this is intended to bring you any headaches, so apply as you see fit, nothing urgent here. [1] as could be seen at http://patch-tracking.debian.net/package/replaceit /* that is an extremely great resource ! */ or just lsdiff -zx '*/debian/*' diff.gz. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Wed, 10 Dec 2008 01:06:16 +0900 Paul Wise [EMAIL PROTECTED] wrote: On Wed, Dec 10, 2008 at 1:03 AM, Neil Williams [EMAIL PROTECTED] wrote: Cyril, we've had this discussion before - merely adding symbols does NOT require a SONAME bump. We are not talking about SONAME bumps, but shlib bumps. OK, I've had a quite chat with Suno on IRC and cleared up the confusion in my own mind - basically, some maintainers are are not doing something that I do by second nature - managing the shlibdeps when a new symbol is added. I add the details to the symbols file and sort out the shlibs without even thinking of the two as separate. What everyone is thinking of as an shlib bump is something I simply do as part of adding a symbol the proper way. Hence, my original supposition that adding a new symbol properly does not require a SONAME bump - which was correct but not relevant here. I see the division now. Adding a symbol in my mind included the shlib bump as a direct and inevitable consequence. Ah well. I doubt that - merely adding a new symbol is NOT a bug, let alone release-critical. Right, but not bumping shlibs at the same time is an RC bug AFAIK. OK, I've got that now. Sorry for the noise. Maybe this is just because I'm also upstream for my libraries and this sort of thing comes naturally, without even thinking of it as a separate step. I just didn't consider that people would do something as crazy as only do half a change. I'm not afraid of saying I got this bit wrong but I hope it's clearer now. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpUnpUd0djfp.pgp Description: PGP signature
Re: Listing dependencies with specific versions
On Tue, Dec 09, 2008 at 04:06:46PM +, Neil Williams wrote: On Tue, 9 Dec 2008 22:18:01 +0900 Paul Wise [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins [EMAIL PROTECTED] wrote: New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: That is not a bug - the package building against it merely has to require that version. Sure, if the package that is building needs those symbols. But what about other packages that *don't* necessarily need those symbols, but get built against the newer version of the library anyway? Those symbols can end up in the built binary, but unless dpkg-shlibdeps happens to know that symbols have been added, it won't know to version the library dependency and all hell breaks loose. The solution: shlibs files, which list the last package version in which a new symbol was added to the library, so that the packaging system can make sure that that newer version is available to packages that need the extra symbols. The bug only arises if symbols are removed or function prototypes are changed in existing symbols. Not quite. If you remove symbols or change the type of a symbol, you need to bump the SONAME because that's the only piece of information that the dynamic linker has to be able to determine if a *newer* library will or won't work with a particular binary. If you add symbols, you don't need to bump the SONAME because the library is still backwards-compatible -- the SONAME effectively defines a base ABI that will continue to work into the future, and when that no longer applies, *then* the SONAME is bumped. If it was, we'd be on libglib.so.7787.0.0 by now. *cough* /usr/lib/libglib-2.0.so.0.1600.6 Not quite, but close... Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. The fix is only necessary if the symbol has CHANGED - added symbols can be managed perfectly well without a SONAME bump. Yes, you are perfectly correct about this. But we're not referring to a SONAME bump, we're talking about putting correct information in the shlibs file regarding new symbols. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: Airoscript
Dear mentors, I am looking for a sponsor for my package airoscript. * Package name: airoscript Version : 2.0.11-1 Upstream Author : Daouid [EMAIL PROTECTED] * URL : http://airoscript.aircrack-ng.org * License : gpl Section : net It builds these binary packages: airoscript - Nice console interface to aircrack-ng The package appears to be lintian clean. The upload would fix these bugs: 501663 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/airoscript - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/airoscript/airoscript_2.0.11-1.dsc I would be glad if someone uploaded this package for me. Kind regards David Francos Cuartero -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Wed, Dec 10, 2008 at 1:38 AM, Matthew Palmer [EMAIL PROTECTED] wrote: Sure, if the package that is building needs those symbols. But what about other packages that *don't* necessarily need those symbols, but get built against the newer version of the library anyway? Those symbols can end up in the built binary, but unless dpkg-shlibdeps happens to know that symbols have been added, it won't know to version the library dependency and all hell breaks loose. The solution: shlibs files, which list the last package version in which a new symbol was added to the library, so that the packaging system can make sure that that newer version is available to packages that need the extra symbols. These days, shlibs has been obsoleted by the new symbols files stuff (which isn't used in libflac++6 AFAICT), so that for each package will depend on the minimum version of the library that provides all the symbols required by the package. This rocks, helps allow installing stuff from testing on stable, eases upgrades and partial upgrades and helps the release team maintain sanity. I just hope it gets used more in squeeze. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: replaceit
On Tue, Dec 09, 2008 at 06:33:24PM +0200, George Danchev wrote: Uploaded Thanks, that was quick! One minor thing I'm not too concerned about is that diff.gz directly patches the Makefile [1]. In fact the change is so innocent that using a patch system could be considered an overkill, but anyway you could: This was I think the first package I ever wrote and I remember being mislead by the New Maintainer's Guide [1] where source modification is encouraged, so I expect that's where it's come from. I'll patch it properly in due course but I'm not inclined to hurry :-) [1] http://www.debian.org/doc/maint-guide/ch-modify.en.html as could be seen at http://patch-tracking.debian.net/package/replaceit /* that is an extremely great resource ! */ That is very helpful - wish I'd know about that before. Thanks for your sponsorship -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 17:14:05 +0100 Cyril Brulebois [EMAIL PROTECTED] wrote: The bug only arises if symbols are removed or function prototypes are changed in existing symbols. Wrong. You're talking about the shlib, as explained in my other message, I was inadvertently folding the two into one. My mistake. You *do* understand the concept of SONAME and shlibs, right? Yes, but adding symbols properly includes the shlib change and I wasn't thinking of it as a separate step, just a routine part of adding a symbol. Upstream bias. I use symbols instead now and that is a far better system - easier to manage upstream too. You *do* understand that those are different things, right? Given some RC bugs against some of your packages, I start doubting it. Too bad you're being so vocal on this list, and so self-confident. I've apologised for the confusion, I don't mind owning up to errors and misconceptions. The RC bugs in question are not against my own packages, I was merely reviewing the existing bugs to try and get Lenny released. I have no open RC bugs against any of my own 61 packages (and haven't for several months) and none against my sponsored packages either. Since the freeze started, I've made numerous RC fix NMU's, contributed to fixes for many others. If more DD's had been as active, Lenny could well have been released on time (or certainly by now). I don't think a genuine mistake is grounds to disrespect my contribution. Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. Definitely - a possible release goal for Squeeze that one. After all, mole has the basic files available already. The fix is only necessary if the symbol has CHANGED - added symbols can be managed perfectly well without a SONAME bump. Again, wrong. Umm, adding symbols properly does not require a SONAME bump - you've said so yourself. The confusion is what is meant by properly - I considered properly as including the shlibs (or preferably symbols) support, not as a separate task. Dumping new symbols into the library without any packaging support is not a good idea, I've never doubted that. (Just didn't expect others to be neglecting it). Adding symbols means modifying the symbols file - or at least adding symbols properly means that. Modifying the symbols file (the much improved replacement of shlibs) should be part and parcel of the one task of adding a new symbol to the library and is much easier to manage upstream. Adding symbols support to Debian libraries means that this problem becomes much, much more obvious and far, far easier to fix. I think it would be a valuable goal for Squeeze to get symbols support in all libraries in testing. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpYleyNdFII7.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Hi, In article [EMAIL PROTECTED], Andy Hawkins[EMAIL PROTECTED] wrote: Umm, I'll try. I'm not sure exactly what that bug report should say! Kind of new to all this Debian packaging stuff (as of this time last week I knew nothing about it!). Now I'm confused. Is there a bug in the libflac++ stuff or not? The way I see it: 1. If my software is compiled against libflac1.1.x, it won't include picture support, so will work with a version of libflac1.1.x *or* libflac1.2.x 2. If my software is compiled against libflac1.2.x, it *will* include picture support so *won't* work with a version of libflac1.1.x, only libflac2.2.x 3. When I build my package on testing, it compiles and links against libflac1.2.x. So, it includes picture support. *However*, the dependencies for the binary package only say it depends on libflac, no libflac = 1.2.x Can someone confirm / deny my understanding here? As I say, I'm very new to all this. Cheers Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 17:34:15 + (UTC) Andy Hawkins [EMAIL PROTECTED] wrote: Now I'm confused. That's my fault. There is a bug in the shlibs of libflac++ Is there a bug in the libflac++ stuff or not? The way I see it: Yes - just in the shlibs which is much easier to fix. 1. If my software is compiled against libflac1.1.x, it won't include picture support, so will work with a version of libflac1.1.x *or* libflac1.2.x Once libflac++ is fixed, dpkg-shlibdeps will pick up the right version and give you the strict dependency that you need. Until it is fixed, you can work around the bug but that won't protect anyone else building against the library. Your package should not be capable of being built against libflac1.1 because it should check for 1.2 in the configure stage. Your package is what requires symbols from 1.2, your package needs to check for that. Once built, if it is installed alongside 1.1 (despite being built against 1.2), then it will fail because it is looking for symbols that only exist in 1.2 - that is the bug in the library. 2. If my software is compiled against libflac1.2.x, it *will* include picture support so *won't* work with a version of libflac1.1.x, only libflac2.2.x Yes. You need to ensure that it is built against 1.2. 3. When I build my package on testing, it compiles and links against libflac1.2.x. So, it includes picture support. *However*, the dependencies for the binary package only say it depends on libflac, no libflac = 1.2.x Which is the bug in the library that you can work around. Can someone confirm / deny my understanding here? As I say, I'm very new to all this. Sorry to inflict my mistake upon you. It happens to everyone at some point. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpZMcEFozM36.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Hi, In article [EMAIL PROTECTED], Neil Williams[EMAIL PROTECTED] wrote: Can someone confirm / deny my understanding here? As I say, I'm very new to all this. Sorry to inflict my mistake upon you. It happens to everyone at some point. Whoops. It appears the mistake is mine. Picture support was actually added in flac 1.1.3, not 1.2.0 as I thought. Mea culpa. My .deb however doesn't depend on a specific version of libflac, is that because there are no versions prior to this available? Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Listing dependencies with specific versions
Andy Hawkins [EMAIL PROTECTED] (09/12/2008): My .deb however doesn't depend on a specific version of libflac, is that because there are no versions prior to this available? It is because currently, libflac doesn't declare its shlibs properly. Once this is fixed, and once your package has been rebuilt against it, your package's dependencies against libflac will gain a (= $version). Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 18:12:56 + (UTC) Andy Hawkins [EMAIL PROTECTED] wrote: Can someone confirm / deny my understanding here? As I say, I'm very new to all this. Sorry to inflict my mistake upon you. It happens to everyone at some point. Whoops. It appears the mistake is mine. Picture support was actually added in flac 1.1.3, not 1.2.0 as I thought. In which case, the bug would only show if the package was in unstable and then installed on Etch as that has 1.1.2. That would be a problem for a package in Debian as it would risk a failure during a migration from Etch to Lenny but your package has no real chance of getting into Lenny. Mea culpa. (join the club) My .deb however doesn't depend on a specific version of libflac, is that because there are no versions prior to this available? It's because of the bug in flac and because you haven't used the workaround. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp7bRVEtIHj4.pgp Description: PGP signature
Re: Listing dependencies with specific versions
Neil Williams [EMAIL PROTECTED] (09/12/2008):
You're talking about the shlib, as explained in my other message, I
was inadvertently folding the two into one. My mistake.
Finally.
You *do* understand the concept of SONAME and shlibs, right?
Yes, but adding symbols properly includes the shlib change and I
wasn't thinking of it as a separate step, just a routine part of
adding a symbol. Upstream bias.
*shrug*. Knowing the Debian Policy would help compensate that bias. Not
to mention that you aren't advising upstreams here, but Debian
packagers, so I'd even expect good knowledge of the Policy.
I use symbols instead now and that is a far better system - easier to
manage upstream too.
Still, knowing the basics...
The RC bugs in question are not against my own packages, I was merely
reviewing the existing bugs to try and get Lenny released.
Oh, you were adding random noise (buggy severity change, tag addition)
to #50707{1,2}? Then I do recognize my mistake assuming you were the
maintainer.
[Various stats, etc.] I don't think a genuine mistake is grounds to
disrespect my contribution.
As I already stated, what I hate is your repeating you're right (“Cyril,
we've had this discussion before” etc.) when you're being clueless.
Again, wrong.
Umm, adding symbols properly does not require a SONAME bump - you've
said so yourself. The confusion is what is meant by properly - I
considered properly as including the shlibs (or preferably symbols)
support, not as a separate task. Dumping new symbols into the library
without any packaging support is not a good idea, I've never doubted
that. (Just didn't expect others to be neglecting it).
So you claim you're doing your job right (note that I'm not questioning
that), by playing with symbols while you didn't know anything about
shlibs (read it as “confusing them with SONAME”) before some minutes
ago? Impressive.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Listing dependencies with specific versions
On Tue, 9 Dec 2008 20:17:02 +0100 Cyril Brulebois [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED] (09/12/2008): *shrug*. Knowing the Debian Policy would help compensate that bias. I think you've missed my point - the change is done anyway, it's just done as part of an upstream process not as a separate task. I considered adding a symbol as a single task, you (and others) see it as two and I can now see why that happens. It does not mean that the task itself was not being done or that I was unaware of the requirements. I was merely unaware of the division - I saw the entire thing as one, that is all. I didn't recognise that what was being described as shlib bump was something I was already doing. Not to mention that you aren't advising upstreams here, but Debian packagers, so I'd even expect good knowledge of the Policy. I was not and am not unaware of Policy - just that something that I took for granted was actually not being done in other packages. I use symbols instead now and that is a far better system - easier to manage upstream too. Still, knowing the basics... Not true. [Various stats, etc.] I don't think a genuine mistake is grounds to disrespect my contribution. As I already stated, what I hate is your repeating you're right (“Cyril, we've had this discussion before” etc.) when you're being clueless. Making a simple mistake, I apologise for that. Umm, adding symbols properly does not require a SONAME bump - you've said so yourself. The confusion is what is meant by properly - I considered properly as including the shlibs (or preferably symbols) support, not as a separate task. Dumping new symbols into the library without any packaging support is not a good idea, I've never doubted that. (Just didn't expect others to be neglecting it). So you claim you're doing your job right (note that I'm not questioning that), by playing with symbols while you didn't know anything about shlibs (read it as “confusing them with SONAME”) before some minutes ago? Impressive. I know about shlibs, I just didn't identify that for what I thought was one complete step, some packages had only part of the implementation. Anyway, can we move on now? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp97Y6k3tGRe.pgp Description: PGP signature
Re: RFS: tuxcmd
Hi I yust reuploaded package whith improvements done: On Mon, Dec 08, 2008 at 03:06:00PM +0100, Michal Čihař wrote: Dne Sun, 7 Dec 2008 19:25:47 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tuxcmd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd/tuxcmd_0.6.50-1.dsc Why is it only arch: i386 amd64? As you proposed in this subthread I changed the arch again back to any. Also debian/copyright lacks some information: - translation copyrights are not included - also some source files have more than one copyright holders Using http://wiki.debian.org/Proposals/CopyrightFormat might be also a good idea. I followed that, but have still some unsure points abaout that. Example: Files: * Copyright: Copyright 2008, Tomáš Bžatek [EMAIL PROTECTED] License: GPL-2+ On Debian systems the full text of the GNU General Public License can be found in the `/usr/share/common-licenses/GPL' file. Wiki-Proposal states, that for the copyright I should list all including years. Some of the files have different copyright years, so I need to really have for each such file an appropriate Section, even the License and Author is the same? Example: ./UChecksum.pas (Copyright 2004, by Tomas Bzatek), and ./UConfig.pas (Copyright 2008, by Tomas Bzatek). The wiki Proposal states The copyright statement SHOULD include copyright year(s) and the copyright holder's name (revision 413) So I'm still unsure about this point, but fixed the rest of the copyright file (in particular the translations files). Furthermore I tryied to improve the package description, to not confuse the reader about shiping in tuxcmd package the extension VFS modules, and add a note also in README.Debian that those comes with an additional package tuxcmd-modules. The tuxcmd-modules package is still not ready yet. Thanks again for checking and kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi On Tue, Dec 09, 2008 at 10:14:48AM +0100, Michal Čihař wrote: Dne Mon, 8 Dec 2008 22:29:15 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): Yes I have to rephrase these sentences. The reason about that is the following: upstream ships the base filemanager tuxcmd in a source tarball, and in another tarball some modules (the above claimed, and I should rephrase the description for tuxcmd itself). For the modules I filled an separate ITP (see http://bugs.debian.org/508082). The second I have to repackage the upstream tarball to remove the non free module parts (unrar and libarchive plugin). What's non-free on libarchive? It's already packaged in main. I guess same applies to unrar (there is free unrar, but there is no free rar). Ok will work on this. I simply was a bit confused about unrar/unrar/license.txt and some of the statements in libarchive/libarchive-2.5.5/COPYING. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi Dne Tue, 9 Dec 2008 22:16:31 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): I followed that, but have still some unsure points abaout that. Example: Files: * Copyright: Copyright 2008, Tomáš Bžatek [EMAIL PROTECTED] License: GPL-2+ On Debian systems the full text of the GNU General Public License can be found in the `/usr/share/common-licenses/GPL' file. Wiki-Proposal states, that for the copyright I should list all including years. Some of the files have different copyright years, so I need to really have for each such file an appropriate Section, even the License and Author is the same? Example: ./UChecksum.pas (Copyright 2004, by Tomas Bzatek), and ./UConfig.pas (Copyright 2008, by Tomas Bzatek). The wiki Proposal states The copyright statement SHOULD include copyright year(s) and the copyright holder's name (revision 413) So I'm still unsure about this point, but fixed the rest of the copyright file (in particular the translations files). Well, you should list all copyright statements as well in normal copyright file. In this case I'd stick with 2004-2008 (or whatever range matches all files). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
RFS: webcpp
Dear mentors, I am seeking a sponsor for my updated package webcpp (Sandro Tosi kindly sponsored previously). This upload adds the VCS-* fields to debian/control and fixes some minor lintian warnings. The dsc is at http://mentors.debian.net/debian/pool/main/w/webcpp/webcpp_0.8.4-8.dsc If you're unable to sponsor I would still appreciate a review. Thanks in advance -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 Sending of encrypted mail is encouraged signature.asc Description: Digital signature
Re: RFS: webcpp
Jonathan Wiltshire [EMAIL PROTECTED] (09/12/2008): This upload adds the VCS-* fields to debian/control and fixes some minor lintian warnings. Hi, thanks for your attention to details. That doesn't really look like needing an upload right now, though. I'd wait for a bugfix or a new upstream release to push those fixes (get them uploaded) if I were you. Mraw, KiBi. signature.asc Description: Digital signature
TopGit might not be ready yet (was: RFS: replaceit)
also sprach George Danchev [EMAIL PROTECTED] [2008.12.09.1733 +0100]: c) use topgit as your patch queue manager, see: /usr/share/doc/topgit/HOWTO-tg2quilt.gz; or I think TopGit is awesome. Yet, I think TopGit might not be ready for everyone just yet. It still requires a very solid understanding of Git, probably has quite a few bugs in places, and a couple of rough, even sharp edges. Specifically, #505303 and #500656 are the two showstoppers for me which I'd like resolved rather sooner than later. I don't want to discourage use of TopGit and I am happy to support people using it (be prepared for a delayed response). But I think it's important to let people know about the shortcomings at this stage to prevent disappointment. I'd especially love to work with anyone who wants to tackle the two wishlist bugs quoted above. Eternal fame will be yours! :) -- .''`. martin f. krafft [EMAIL PROTECTED] Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the stripes on the highway began to unreel beneath her in a dizzying blur as if all those grains of sand had lost their bearings and were falling all over each other just trying to get out of the way to make room for the next moment, or instant, or tick of the clock -- mc 900 ft jesus (http://www.theendoftheworld.org/900/spider1.shtml) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
