Re: -dev library package naming
also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.06.15.0151 +0200]: > The library package guide should tell you to use > > libspf-1.0-0 Note that the question was about the -dev package naming, which is not really explained in your excellent FAQ. PS: also, will you ever incorporate the shell script snippet by Steve Langasek I sent you, which determines the package name given the library file? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/IT d- s: a-- C++() UL+++() P+ L E--- W- N+ o-- K !w O- M- V PS+(+++) PE(--) Y+ PGP++ t- 5 !X R- !tv b+(++) DI--(+) D++(+++) G+ e> h* r+>++ y+>+(++) --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: -dev library package naming
On 15.06.2005, at 01:51, Junichi Uekawa wrote: The library package guide should tell you to use If it doesn't, that's an error in the guide; but I would also first check the SONAME of the library. Exactly, but I do not recall that it mentions the name of the corresponding dev package, but I did not look it up again. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFD/RFS: gtk+extra-2.0 -- A useful set of widgets for GTK+ 2.0
Hello, This is an discussion request for Gtk+Extra 2.0 (Bug #313614). A RFS will follow, after fixing last issues. > Package: wnpp > Severity: wishlist > > > * Package name: gtk+extra-2.0 > Version : 2.0.0 > Upstream Author : Adrian E. Feiguin > * URL : http://gtkextra.sourceforge.net > * License : LGPL > Description : A useful set of widgets for GTK+ 2.0 > > GtkExtra-2.0 is a useful set of widgets for creating GUI's for the Xwindows > system using GTK+ 2.0. Shared libraries for GtkExtra-2.0 include the > follwoing widgtes: [..] First I am interested in feedback regarding the quality of this package and possible problems. 2 Linda warnings left, but IMHO the second warning about the missing libs-entry in .shlibs file is false. The first is dedicated to the packaging process following README.Debian in the autotools-dev package. Two problems, which need to be fixed: (1) The documentation provided with the source is outdated. For the moment I added a documentation package, but of course it can be also removed. Hopefully documentation will be updated in next upstream package. (2) I forgot to add dpatch to Build-Depends. Do you find more issues or do have further comments, suggestions, critics? Packages are available at http://debian.wgdd.de/debian/ Sources: http://debian.wgdd.de/debian/dists/unstable/main/source/devel/ Binaries: http://debian.wgdd.de/debian/dists/unstable/main/binary-i386/libdevel/libgtkextra2.0-dev_2.0.0-0dl0_i386.deb http://debian.wgdd.de/debian/dists/unstable/main/binary-i386/libs/libgtkextra2.0-0_2.0.0-0dl0_i386.deb http://debian.wgdd.de/debian/dists/unstable/main/binary-all/doc/libgtkextra2.0-doc_2.0.0-0dl0_all.deb Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFD/RFS: gtk+extra-2.0 -- A useful set of widgets for GTK+ 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Leidert <[EMAIL PROTECTED]> writes: > Hello, > > This is an discussion request for Gtk+Extra 2.0 (Bug #313614). A RFS > will follow, after fixing last issues. > First I am interested in feedback regarding the quality of this package > and possible problems. 2 Linda warnings left, but IMHO the second > warning about the missing libs-entry in .shlibs file is false. The first > is dedicated to the packaging process following README.Debian in the > autotools-dev package. Major gripe: you build-confict and build-depend upon autoconf and automake. There should not be *any* need to run these and build time. If you do alter Makefile.ams or configure.ac, run the autotools on your system, and have the changes included in the .diff.gz, which makes the build deterministic on all systems, and makes the build much more simple and reliable. Your package also fails to autobuild. Please check the build dependencies (dpatch missing?) and test building with sbuild and/or pbuilder. Here's the build log: Automatic build of gtk+extra-2.0_2.0.0-0dl0 on hardknott by sbuild/powerpc 1.7 Build started at 20050615-1934 ** gtk+extra-2.0_2.0.0-0dl0.dsc exists in cwd ** Using build dependencies supplied by package: Build-Depends: debhelper (>= 4.0.0), autoconf, automake1.7, autotools-dev, gawk, libtool, pkg-config (>= 0.9.0), libgtk2.0-dev, libglib2.0-dev Build-Conflicts: autoconf2.53, automake1.4 Checking for already installed source dependencies... debhelper: missing autoconf: missing automake1.7: missing autotools-dev: missing gawk: missing libtool: missing pkg-config: missing libgtk2.0-dev: missing libglib2.0-dev: missing autoconf2.53: already deinstalled automake1.4: already deinstalled Checking for source dependency conflicts... /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install debhelper autoconf automake1.7 autotools-dev gawk libtool pkg-config libgtk2.0-dev libglib2.0-dev Reading Package Lists... Building Dependency Tree... The following extra packages will be installed: debconf-utils defoma file fontconfig gettext gettext-base html2text intltool-debian libatk1.0-0 libatk1.0-dev libexpat1 libexpat1-dev libfontconfig1 libfontconfig1-dev libfreetype6 libfreetype6-dev libglib2.0-0 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libjpeg62 libmagic1 libnewt0.51 libpango1.0-0 libpango1.0-common libpango1.0-dev libpng12-0 libpopt0 libtiff4 libx11-6 libx11-dev libxcursor1 libxext-dev libxext6 libxft-dev libxft2 libxi-dev libxi6 libxrandr2 libxrender-dev libxrender1 libxv-dev libxv1 m4 po-debconf render-dev ttf-bitstream-vera ucf whiptail x-dev xfree86-common xlibs-data xlibs-static-dev zlib1g-dev Suggested packages: autoconf2.13 autobook autoconf-archive gnu-standards dh-make defoma-doc psfontmgr x-ttcidfont-conf dfontmgr cvs gettext-doc libglib2.0-doc libgtk2.0-doc ttf-kochi-gothic ttf-kochi-mincho ttf-thryomanes ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp ttf-arphic-gkai00mp ttf-arphic-bkai00mp libpango1.0-doc libtool-doc g77 fortran77-compiler gcj libgnome-dev x-window-system-core x-window-system xspecs Recommended packages: libft-perl curl wget lynx libatk1.0-data libglib2.0-data hicolor-icon-theme libltdl3-dev libmail-sendmail-perl libcompress-zlib-perl The following NEW packages will be installed: autoconf automake1.7 autotools-dev debconf-utils debhelper defoma file fontconfig gawk gettext gettext-base html2text intltool-debian libatk1.0-0 libatk1.0-dev libexpat1 libexpat1-dev libfontconfig1 libfontconfig1-dev libfreetype6 libfreetype6-dev libglib2.0-0 libglib2.0-dev libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libgtk2.0-dev libjpeg62 libmagic1 libnewt0.51 libpango1.0-0 libpango1.0-common libpango1.0-dev libpng12-0 libpopt0 libtiff4 libtool libx11-6 libx11-dev libxcursor1 libxext-dev libxext6 libxft-dev libxft2 libxi-dev libxi6 libxrandr2 libxrender-dev libxrender1 libxv-dev libxv1 m4 pkg-config po-debconf render-dev ttf-bitstream-vera ucf whiptail x-dev xfree86-common xlibs-data xlibs-static-dev zlib1g-dev 0 upgraded, 63 newly installed, 0 to remove and 6 not upgraded. Need to get 391kB/26.2MB of archives. After unpacking 86.0MB of additional disk space will be used. Get:1 http://ftp.uk.debian.org unstable/main automake1.7 1.7.9-7 [391kB] Preconfiguring packages ... Fetched 391kB in 6s (59.1kB/s) Selecting previously deselected package gawk. (Reading database ... 7995 files and directories currently installed.) Unpacking gawk (from .../gawk_1%3a3.1.4-2_powerpc.deb) ... Selecting previously deselected package gettext-base. Unpacking gettext-base (from .../gettext-base_0.14.5-1_powerpc.deb) ... Selecting previously deselected package libpopt0. Unpacking libpopt0 (from .../libpopt0_1.7-5_powerpc.deb) ... Selecting previously deselected package libnewt0.51. Unpack
Re: namespace conflict != package Conflict?
On Wed, 15 Jun 2005, Anthony Towns wrote: Steve Greenland wrote: On 12-Jun-05, 02:27 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: You need to convince either git or GNU Interactive Tools to change its name upstream then. Since git is the newcomer and its name is already taken (by a GNU project no less!) perhaps you could start there. The existence of the GNU Interactive Tools was noticed when Linus picked the name 'git'. The discussion then noted that this previous use of the name was more-or-less dead upstream, and not widely used. The upstream name isn't going to change. There are probably already more users of GIT-the-VCS than GIT-the-tools. So if you rename git for Debian, we are very likely going to to be incompatible. Uh, so why hasn't the option of renaming (or just dropping) GNU Interactive Tools been discussed? Policy might require us to not have two packages installing different functionality under the same command name, but it doesn't require us to adopt "first come, first served". It was mentioned (on the Mentors list anyways) but didn't seem to garner much support as a first-pass solution... I chaulk it up to the collective just knowing that "first come, first served" is about a fair a rule-of-thumb as we can have in this situation. GNU Interactive Tools hasn't seen an upstream update at all since 2001, and looking at the diffs since .18, doesn't seem to have had any significant changes since 1999. The Debian updates seem mostly to be updating the build system, rather than user-visible changes. GIT is flexible, not too bloated, not lacking anything significant or obvious, and has been that way for awhile (the command line and tools haven't changed, why should GIT)... iow, it is mature - why should that be held against it? Popcon says: #nameinst vote old recent no-files cogito7010 159 0 git 95196610 0 which aiui means that 10 of 11 cogito installers use it regularly, while 19 of 85 git installers do; the "59 recent" presumably screws the stats up a bit much. See what happens when you upload your packages? Another thing which is likely to mess up popcon based comparisons is the widely different usage patterns. GIT is a sh TUI, git-for-cogito is essentially a function call; I typically fire up GIT soon after logging in and it is useful for days-to-weeks on a single "use", by its nature git-for-cogito will see many more instances of "use" even if it is only being useful for a day. [then again, I may completely misunderstand what popcon generates ] Personally, I think the best solution is to leave the filesystem level error (two /usr/bin/git's) intact in the uninstalled Debian (the .debs) and present the sysadmin with the most reasonable options for resolving it when they select the affected packages. Ya, I know what that would involve to do "poperly", so I'm not suggesting it be done right now or just for this instance of the problem. Anyways, I'm confident the collective DD's will eventually do the right thing. In the short term, I'm glad the precedent which would be set by discarding a name/path with a long and useful history is seen as worthy of argument. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFD/RFS: gtk+extra-2.0 -- A useful set of widgets for GTK+ 2.0
Am Mittwoch, den 15.06.2005, 20:28 +0100 schrieb Roger Leigh: > Daniel Leidert <[EMAIL PROTECTED]> writes: > > > This is an discussion request for Gtk+Extra 2.0 (Bug #313614). A RFS > > will follow, after fixing last issues. > > > First I am interested in feedback regarding the quality of this package > > and possible problems. 2 Linda warnings left, but IMHO the second > > warning about the missing libs-entry in .shlibs file is false. The first > > is dedicated to the packaging process following README.Debian in the > > autotools-dev package. > > Major gripe: you build-confict and build-depend upon autoconf and > automake. There should not be *any* need to run these and build time. I do not agree in general to this statement. I normally prefer updated build-systems. And the only way to guarantee this automatically is to run these tools during packaging process (IMHO). [..] > Your package also fails to autobuild. Please check the build > dependencies (dpatch missing?) Yes, I wrote that dpatch is missing in Build-Depends. Please refer to my original mail. > and test building with sbuild and/or > pbuilder. There are no build-problems after adding dpatch to build-depends. Thanks for your feedback, Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFD/RFS: gtk+extra-2.0 -- A useful set of widgets for GTK+ 2.0
On 15.06.2005, at 21:28, Roger Leigh wrote: Major gripe: you build-confict and build-depend upon autoconf and automake. There should not be *any* need to run these and build time. If you do alter Makefile.ams or configure.ac, run the autotools on your system, and have the changes included in the .diff.gz, which makes the build deterministic on all systems, and makes the build much more simple and reliable. What makes a dependency on a more or less specified version of the Autotools turning the whole build into something non-deterministic? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cogito no longer conflicts with git or cgvg
The upstream folks are planning to split cogito and git into two separate packages. I requested (and they seemed to agree) that they change the package name from git to something else before then. Hopefully they'll see the light and try to play nice with the rest of the world. Hmm... It looks to me like git is already a seperate package. http://www.kernel.org/pub/software/scm/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev library package naming
Hi, > > The library package guide should tell you to use > > > > libspf-1.0-0 > > Note that the question was about the -dev package naming, which is > not really explained in your excellent FAQ. > > PS: also, will you ever incorporate the shell script snippet by > Steve Langasek I sent you, which determines the package name given > the library file? I've already included it; but discovered that it was not in the section under naming shared libraries, so I shuffled it around. It should look (slightly) better now. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
