Re: How to create the most compatible package
On Wed, Nov 23, 2005 at 01:56:30PM +0100, Bram Neijt wrote: > I'm working on a very simple package which, only has compile time > dependencies. > I'm currently on debian unstable, with g++-4.0 as my main compiler > (it's a C++ program). > > I've succesfully created a package and installed it on another debian > system, however when I go to an Ubuntu system, it seems to needs the > newer libraries (g++-4.0 libraries?) > > So my question is: > How can I create the most compatible package without resorting to source? The most compatible package is a source package. Debian and Ubuntu both have autobuilders to handle creating binary packages with the appropriate toolchain and dependencies. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
On Mon, Dec 19, 2005 at 03:53:22PM +0100, Reinhard Tartler wrote: > I disagree. Soyuz is a reimplementation of the archive software. HCT > addresses the problem of package publishing within Soyuz. In what scope > HCT will support 'collaborative maintenance' is AFAIK quite unclear. HCT is a tool for applying distributed revision control methodology to package maintenance, with a specific emphasis on collaboration, both within a distribution and between distributions. It does not deal with package publishing in Soyuz. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
On Mon, Dec 19, 2005 at 10:25:58AM -0500, Asheesh Laroia wrote: > hct looks very cool and does seem to solve some of the problems that are > considered here. When I read https://wiki.launchpad.canonical.com/HCT , I > get the sense that it's not actually released yet. Is that the case? If > not, how can one start using it? That's correct; it isn't yet ready for general use. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plotdrop - A minimal GNOME frontend to GNUPlot
On Tue, Jan 10, 2006 at 04:03:53PM -0800, Jordan Mantha wrote: > I am looking for somebody to sponsor a new package for me. I recently > packaged it for Ubuntu and it was accepted into the universe repository. > I have now made a Debian sid source package, [...] Is there a reason why the source package needs to be different between Debian and Ubuntu, or can it be shared? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changelog entries - ubuntu?
On Thu, Dec 14, 2006 at 07:13:19AM -0500, Kevin Coyner wrote: > > During a recent upgrade of my Debian Sid box, I noticed the > following changelog entry: > > > f-spot (0.2.2-0ubuntu1) feisty; urgency=low > > * Update to 0.2.2 upstream > > > Perhaps I've already missed a discussion on this. If so, I'd > appreciate a link/pointer so that I can read up. But if not, then > are their guidelines or policy statements somewhere that explain > how and when Ubuntu releases are incorporated into Debian? Information for Debian developers about Ubuntu can be found here: https://wiki.ubuntu.com/UbuntuForDebianDevelopers If there's an appropriate place in the Debian wiki or documentation to link to this, I'd appreciate that. The short answer is that it's up to the individual maintainer how and when they incorporate changes. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Choice between ubuntu or brand new package for Bug#345039
On Fri, Feb 16, 2007 at 09:31:43AM +, David Newgas wrote: > Bug#345039 is an request for > "kzenexplorer" (http://kzenexplorer.sourceforge.net/) to be included in > Debian. It is currently already in Ubuntu > (http://packages.ubuntu.com/kzenexplorer). I created a brand new Debian > package (lintian clean except for lack of a man page) before noticing it > was in Ubuntu. Which is preferred, a new package or using the Ubuntu > one? And if the latter, is it simply done by using the Ubuntu > orig.tar.gz/diff.gz/dsc ? You aren't likely to find any useful conventional wisdom about which to prefer; it will always depend on the individual package. The same applies for any package which you might adopt from a third party. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Choice between ubuntu or brand new package for Bug#345039
On Fri, Mar 02, 2007 at 06:44:31PM +0100, Holger Levsen wrote: > Hi, > > On Tuesday 20 February 2007 20:42, Matt Zimmerman wrote: > > > Debian. It is currently already in Ubuntu > > > (http://packages.ubuntu.com/kzenexplorer). I created a brand new Debian > > > package (lintian clean except for lack of a man page) before noticing it > > > was in Ubuntu. Which is preferred, a new package or using the Ubuntu > > > one? And if the latter, is it simply done by using the Ubuntu > > > orig.tar.gz/diff.gz/dsc ? > > You aren't likely to find any useful conventional wisdom about which to > > prefer; it will always depend on the individual package. The same applies > > for any package which you might adopt from a third party. > > Isn't having the same package in Debian (unstable) and Ubuntu (unstable) the > prefered status? Certainly. However, one can reach that status using either package as a starting point. The right approach is to evaluate both packages, decide on technical grounds which is closer to the ideal, and use that. If the Ubuntu packaging is more mature and complete, it would be best to import that into Debian and begin there. Similarly, if the Ubuntu packaging is rough, the Debian package might make a better starting point. In other words, the question was "should I choose package A or package B?" and the answer is "choose the best package". Of course, in general, it's best to avoid this situation (and any wasted effort) entirely by communicating with the maintainer of an existing package before creating a new one, but it's never too late to make contact and start discussing it. Emailing the Ubuntu developer who created the package is a good beginning. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages newer in Ubuntu than in Debian (reduced false positives)
On Tue, May 01, 2007 at 02:39:27PM +0200, Eric Lavarde wrote: > Hello Bart, > > is there some kind of agreement between Debian and Ubuntu concerning the > distribution part of the version? The scheme is described here: https://wiki.ubuntu.com/UbuntuDevelopment#UbuntuPackages which is linked, along with other pertinent information for Debian developers, from here: https://wiki.ubuntu.com/UbuntuForDebianDevelopers > I ask this because you seem to assume that: > X.Y.Z-K (Debian) << X.Y.Z-L (Ubuntu) If K < L, yes, this is true. > X.Y.Z-K (Debian) << X.Y.Z-KubuntuA (Ubuntu) This should always be true as well. It is sometimes possible that A.B.D-1 is "older" than A.B.C-2ubuntu1 (where Ubuntu has continued to patch an older version due to a freeze), but for purposes of identifying out-of-date packages, the above should be reasonable assumptions. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prompt to install missing software?
On Mon, May 28, 2007 at 01:24:44PM -0400, Simon wrote: > On 5/27/07, John Pye <[EMAIL PROTECTED]> wrote: >> I found the original code in GNOME just pops up a message, see >> check_ntp_support in >> http://cvs.gnome.org/viewcvs/gnome-system-tools/src/time/time-tool.c?rev=1.17&view=markup > > This would mean that the changes are Ubuntu specific, which is > understandable. I wasn't specific enough in my first reply, but I > meant that you should check Ubuntu's source packages: > http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=gnome-system-tools > > I think the first version that had the automatic install functionality > was either Dapper or Edgy. One other thing to watch out for is > whether your users prefer su or sudo ( and gksu or gksudo), I'm not > sure if there's a standardized way to check for this in Debian. What we've settled on in Ubuntu is to use gksu, and allow the preference to be set in /etc/gksu.conf (sudo-mode). That way, it's transparent to applications. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ubuntu keyring?
On Thu, May 19, 2011 at 06:56:38AM -0500, Nathan Handler wrote: > On Mon, Mar 21, 2011 at 1:39 PM, Ansgar Burchardt wrote: > > There is already an open RFP for ubuntu-archive-keyring[1], but nobody > > bothered to package it yet. ubuntu-devel-discuss@l.u.c was CCed twice, > > but there hasn't been a response (tough my mail seems to be lost due to > > mailing list moderation). > > I would be glad to work on packaging the keyring and finding a sponsor > to upload it. There are a few comments on the bug from people who do > not think it belongs in Debian, but I think arguments for having it in > Debian are a bit stronger. I have gone ahead and changed the bug to an > ITP. Great! Thanks for working on this, Nathan. -- - mdz -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110519150353.go7...@alcor.net
Re: RFS agrep
On Thu, Jul 17, 2003 at 02:48:28PM +0200, Luk Claes wrote: > > > There is an agrep package already in Debian: > > > > > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=agrep&searchon=names&subword=1&version=all&release=all > > Of course it is this package. > > > Huh? This package is *not* part of Debian. > > A little bit more information would be appreciated. mizar:[~] apt-cache show agrep G Section Section: non-free/text http://www.debian.org/doc/developers-reference/ch-resources.en.html#s4.6.1 -- - mdz
Re: RFS agrep
On Thu, Jul 17, 2003 at 04:04:46PM +0200, Frank Küster wrote: > Matt Zimmerman <[EMAIL PROTECTED]> schrieb: > > mizar:[~] apt-cache show agrep G Section > > Section: non-free/text > > > > http://www.debian.org/doc/developers-reference/ch-resources.en.html#s4.6.1 > > So what? In the first sentence quoted, "in Debian" is clearly not meant > in that sense. Still a package named agrep is in Debian's non-free > repository, can be installed via the debian-package management tools, > can probably be found on some CD's named "Debian", is covered by the BTS > and so on. This kind of misinformation is exactly why we would be better off without non-free. If you had bothered to do some trivial research, you would already know that non-free would never be on a Debian CD, and that some of the packages in non-free are there exactly because their redistribution is restricted. > So, is this program the same as the one referred to in the subject? It makes no difference to me. -- - mdz
Re: xxx.a.b.c.changes
On Wed, Jul 23, 2003 at 07:10:57AM +0300, Halil Demirezen wrote: > How can i get xxx.a.b.c.changes file from changelog. dpkg-genchanges is the program which does this. However, you should almost never need to call this directly. dpkg-buildpackage does it for you. > By the way, is it true after a fail singfile from > dpkg-buildpackage -rfakeroot, i sign it mauanlly > with gpg --clearsign xxx.a.b.c.dsc No. You should use debsign instead. -- - mdz
Re: about gzip
On Thu, Jul 24, 2003 at 03:09:09PM +0300, Halil Demirezen wrote: > I am using gzip in my debian/rules for zipping > manpage and then i use "cp my_package.1.gz /usr/share/man/man1" > > my first question: is it a true usage to put gzip into rules? > and secondly, should i specify "gzip" as a Build-Depends? I recommend using dh_installman, with a build-depends on debhelper. -- - mdz
Re: Build-Recommends?
On Mon, Jul 28, 2003 at 04:20:06PM +0200, Bas Zoetekouw wrote: > You wrote: > > > Build-Depends: libcurl2-dev | curl | wget > > might serve as a workaround? > > I guees he would need something like > > (Build-Depends: libcurl2-dev) | (Depends: curl | wget) > > which isn't possible. It is possible (check if required parts of libcurl2-dev are installed, and if not, add the dependencies with a substvar), but as has already been pointed out, build-dependencies are there to ensure a consistent build, so this is not a good idea. -- - mdz
Re: Control fields for libraries and programs depending on them
On Tue, Jul 29, 2003 at 08:06:38PM -0400, Neil Roeth wrote: > Suppose there is a package foobar that depends on a library libfoo. AIUI, > whenever the SONAME changes, the library name should change, so I expect > this to evolve as libfoo1, libfoo2, etc. What are the proper control > fields (Depends, Conflicts, Replaces, Provides) for these packages? If I > understand correctly, the idea of having different package names for > libfoo when the SONAME changes is so that libfoo1 and libfoo2 can coexist. > So, does that mean they should not conflict, and that there should be no > Replaces or Provides fields in the libfoo2 refering to libfoo1? Yes. You can find many examples in the packages in the archive. > I am particularly interested in the case where foobar and libfoo1 are > installed, and a new version of foobar is released that depends upon > libfoo2. Should upgrading foobar cause libfoo2 to be installed, but also > leave libfoo1 installed, since some other package might depend upon it? Upgrading foobar will require that libfoo2 be installed; it should not have any direct effect on libfoo1 (though aptitude, for example, will automatically remove libfoo1 if it only existed to satisfy foobar's dependency). -- - mdz
Re: locale files
On Wed, Jul 30, 2003 at 10:23:14PM -0400, Neil Roeth wrote:
> I maintain a package that provides a shared library, libosp3c102. The files
> /usr/share/locale/{ja,fr,de,sv}/LC_MESSAGES/sp.mo are part of the package.
> However, they are also part of the package that provided the older version of
> the same shared library, libosp2. When I try to install libosp3c102 on a
> system that has libosp2 installed, I get an error: "trying to overwrite
> `/usr/share/locale/de/LC_MESSAGES/sp.mo', which is also in package libosp2".
> I found that libgtk2.0-common and libgtk1.2-common versionize the locale
> files, e.g., gtk20.mo and gtk+.mo, respectively. I'm not certain that it was
> done to solve the same problem, but it looks like that would work in my case.
> Is there any reason not to do that?
You should either version the files, or move them into another package.
Versioning would seem to make more sense in the case of gettext data. In
general, a shared library package must not contain any files which would
conflict with a later version of the same library. Different versions of
the same shared library must not conflict with each other, so that the
library can be upgraded smoothly.
--
- mdz
Re: locale files
On Thu, Jul 31, 2003 at 06:57:51AM -0400, Neil Roeth wrote: > > If the message files are identical, another solution would be to create a > > third package with the message files which you depend on in the library > > packages. (The former should of course conflict with older versions > > of the latter.) > > I suppose if the messages packages was large that might be preferable to ship > it separately rather than in each libfoo package This would only be feasible if the message catalog never changed. Presumably, it corresponds to translated strings in the library, which might not be identical in different versions of the library. > , but for my case, it sounds better to include the files in the libfoo > package and version them. With a separate messages package, you end up > with the same issues as libraries, as far as versioning, coexistence, etc. I agree. -- - mdz
Re: building unstable packages with stable
On Thu, Jul 31, 2003 at 08:08:14AM +0200, Geert Stappers wrote: > On Wed, Jul 30, 2003 at 05:39:59PM -0500, Steve Langasek wrote: > > No; and, moreover, you should not be relying on machines not under your > > (or Debian's) control in order to build binary packages that will be > > uploaded to the Debian archive. Sourceforge has certainly been > > compromised in the past, and remains a high profile target; I wouldn't > > want to see it used as a conduit for getting compromised software into > > Debian. > > > > A way to compile unstable on a stable systems is like this: > > Run debootstrap on an unstable system, > make a tarball of it and take it to the stable system > unpack the tarball there and chroot into it. > > If there is interrest for it, I can set such tarballs > for PowerPC and i386 online. Compiling programs for unstable on stable systems is trivial. The important thing is to _test_ them on unstable. -- - mdz
Re: locale files
On Thu, Jul 31, 2003 at 04:34:53PM +0200, Matthias Urlichs wrote: > > This would only be feasible if the message catalog never changed. > > Presumably, it corresponds to translated strings in the library, which > > might not be identical in different versions of the library. > > Personally I don't have a problem with the old library "acquiring" changed > translations from the new one -- the old library will be obsolete anyway, > as soon as all packages which depend on it are recompiled. But presumably you _would_ have a problem with: - the old library trying to look up a string which isn't there anymore in the new library - the new library trying to look up a string which isn't there in the old library -- - mdz
Re: locale files
On Fri, Aug 01, 2003 at 07:30:20AM +0200, Matthias Urlichs wrote: > > But presumably you _would_ have a problem with: > > - the old library trying to look up a string which isn't there anymore in > > the new library > > - the new library trying to look up a string which isn't there in the old > > library > > Of course the message catalog would contain the union of strings > from both libraries, not its intersection. > > I'd think that'd be obvious... Since these things are usually managed by automated tools which scan the source code looking for translatable strings, it would be nontrivial to ensure that nothing was ever deleted from the file. Also, the new version of the library would require a versioned dependency on the package containing the message catalog. I think it is much more straightforward to version it. -- - mdz
Re: Recompiling a package
On Wed, Aug 13, 2003 at 03:42:40PM -0300, Nelson A. de Oliveira wrote: > I was searching for a package and I've found it. But it´s compiled for > Debian stable. I use Debian unstable and I would like to compile it for > my version of Debian. > How can I recompile it? I have those files: > program.diff.gz > program.dsc > program.changes > program.deb > program.orig.tar.gz > > I know how to create Debian packages, but only to create new packages. > Unpacking the .orig.tar.gz only creates the directory of the program, > but without the debian/ directory. What do I have to do? Note: This mailing list is not for support; you want [EMAIL PROTECTED] Programs compiled for Debian stable will, in general, work unmodified on Debian unstable. You should not need to recompile it. -- - mdz
Re: Problems with UTF-8 in changelog
On Fri, Aug 15, 2003 at 01:56:22PM +0200, Frank Küster wrote: > I am trying to have my debian/changelog file in utf-8, as required by > standards-version 3.6.0. However, dpkg-parsechangelog seems not to bee > able to parse that: > [...] > [EMAIL PROTECTED]:~/src/Packages/netenv/netenv-0.94.2$ dpkg-parsechangelog | > grep ^Maint > Maintainer: Frank KÃ?ster <[EMAIL PROTECTED]> dpkg-parsechangelog seems to have parsed it fine. Perhaps your terminal does not support UTF-8? -- - mdz
Re: Problems with UTF-8 in changelog
On Fri, Aug 15, 2003 at 05:41:51PM +0200, Frank Küster wrote: > Matt Zimmerman <[EMAIL PROTECTED]> schrieb: > > dpkg-parsechangelog seems to have parsed it fine. Perhaps your terminal > > does not support UTF-8? > > Hm, I could check this. However, what made me look at the output of > dpkg-parsechangelog was that signing failed because the secret key for > this strange guy (Frank KÃ?ster) couldn't be found... That would probably be because the name on your GPG key is not in UTF-8. You can add a new uid which has the name in UTF-8, or you can use the -k option to specify the key to sign with. > Is the terminal involved at all? Isn't dpkg-buildpackage handing what it > got from dpkg-buildpackge directly to gpg? You didn't mention anything about gpg at all. You pasted the Maintainer field and said that you thought dpkg-parsechangelog had failed to parse the file. -- - mdz
Re: can't install from a local repository
On Fri, Aug 22, 2003 at 09:13:11AM -0700, Eric Winger wrote: > The Packages.gz was created with: (from inside ~/archive/binary) > > apt-ftparchive packages . > /dev/null | gzip > Packages.gz > > The Sources.gz was created with: (from inside ~/archive/binary) > > apt-ftparchive sources . > /dev/null | gzip > Sources.gz > [...] > sources.list singly entry: > > deb file:///home/ewinger/archive binary/ These are incompatible. Either create Packages relative to archive (not binary), or use deb file:///home/ewinger/archive/binary ./ or such -- - mdz
Re: FAQ for debian-mentors
On Thu, Sep 04, 2003 at 05:54:49PM +1000, Matthew Palmer wrote: > OK, having watched the same questions come past regularly, I've finally > bitten the bullet and put a bit of a FAQ together for this list. I'd > appreciate comments and more questions and answers. > > http://people.debian.org/~mpalmer/debian-mentors_FAQ.html Thanks very much! Maybe this should be integrated into the new maintainer's guide, or some other Debian documentation? -- - mdz
Re: [RFS]: digitaldj
On Sun, Sep 14, 2003 at 10:05:07PM +0200, Tim Dijkstra wrote: > I have ITA'd digitaldj already a long time ago. Sadly, I haven't had > time for debian packaging for a while. But lately I have, I also had my key > signed by a DD (2 days ago) so that's also sorted out. > Not being a DD yet, I can't upload it myself, but I have > prepared a package for the newest digitaldj (0.7.3). You can find it at: > > http://www.famdijkstra.org/~tdykstra/debian/ > > I would really appreciate it if someone would take a look at it > and upload it if they think it's good enough. There was an NMU by Martin A. Godisch since the last time the package was uploaded. Your new package erases that upload from the changelog and makes no mention of whether it fixes bug #192352 (which the NMU was made to address) or reintroduces this bug. You should always base a new package on the latest version in the Debian archive. -- - mdz
Re: Bug#210243: ITP: xspringies -- Interactive 2D mass/spring simulation system for X
On Mon, Sep 15, 2003 at 03:21:30PM +0100, Steve Kemp wrote: > #ifndef COMPRESS > -#define COMPRESS "gzip" > -#define UNCOMPRESS "gunzip -c" > +#define COMPRESS "/bin/gzip" > +#define UNCOMPRESS "/bin/gunzip -c" > #endif I've never been a proponent of hardcoding paths to programs. This will immediately make the program non-portable to basically any non-GNU type system, and doesn't provide any significant benefit (/bin is in PATH). -- - mdz
Re: Bug#210243: ITP: xspringies -- Interactive 2D mass/spring simulation system for X
On Mon, Sep 15, 2003 at 03:47:42PM +0100, Steve Kemp wrote: > On Mon, Sep 15, 2003 at 10:45:48AM -0400, Matt Zimmerman wrote: > > > > +#define COMPRESS "/bin/gzip" > > > +#define UNCOMPRESS "/bin/gunzip -c" > > > I've never been a proponent of hardcoding paths to programs. This will > > immediately make the program non-portable to basically any non-GNU type > > system, and doesn't provide any significant benefit (/bin is in PATH). > > I'm not terribly keen on it myself, but I do think that it's safer > than trusting a potentially malicious $PATH setting. $PATH is almost always trusted; the exception is setuid programs which should sanitize PATH. xspringies is not setuid, is it? -- - mdz
Re: Bug#210243: ITP: xspringies -- Interactive 2D mass/spring simulation system for X
On Mon, Sep 15, 2003 at 04:21:39PM +0100, Steve Kemp wrote: > On Mon, Sep 15, 2003 at 11:00:35AM -0400, Matt Zimmerman wrote: > > > $PATH is almost always trusted; the exception is setuid programs which > > should sanitize PATH. xspringies is not setuid, is it? > > It is not setuid/setgid no, but I still think it's best to not trust > the PATH - sure it's not critical, but it's a good think "just in > case". I think I have to disagree here; hardcoding paths does not, in general, improve security. In any case where path is untrusted, the correct solution is to set a sane PATH (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin) and continue to execute commands as normal. This way you are not dependent on programs being installed in a particular location, and if it is necessary for the administrator to change the path, they can do this in one palce. -- - mdz
Re: [RFS]: digitaldj
On Mon, Sep 15, 2003 at 09:55:00PM +0200, Tim Dijkstra wrote: > You can find at: > > http://www.famdijkstra.org/~tdykstra/debian/ Much better, but one more nit: > + Includes fix from last NMU (Closes: #104974) http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-changelog -- - mdz
Re: [RFS]: digitaldj
On Tue, Sep 16, 2003 at 09:32:17AM +0200, Tim Dijkstra wrote: > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > Much better, but one more nit: > > > > > + Includes fix from last NMU (Closes: #104974) > > > > http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-changelog > > Do you mean I should write something like > > > It is an old tradition to acknowledge bugs fixed in non-maintainer > > uploads in the first changelog entry of the proper maintainer upload, > > for instance, in a changelog entry like this: > > > >* Maintainer upload, closes: #42345, #44484, #42444. > > I think you meant something more like this: > > ddj.c: Doesn't assign va_start to lvalue (Closes: #104974) > > Which is in the new package again at the above url. Yes, I was referring to the second paragraph in section 6.3.1 of the developer's reference: > Focus on what was changed---who, how and when are usually less important. > Having said that, remember to politely attribute people who have provided > notable help in making the package (e.g., those who have sent in patches). In this case, it is important to note what actually changed in the package. Personally, I dislike the "maintainer upload, closes:" convention, and prefer to re-summarize the changes so that it is clear which bugs are being acknowledged. Remember that, when you use Closes:, the submitter of the bug only gets a copy of your most recent changelog entry, so they won't see what the NMUer wrote. Also, the fix was not in the last NMU, but in the NMU before that (there were two consecutive NMUs). Anyway, the latest iteration seems fine; I'll upload this a bit later. -- - mdz
Re: [RFS]: digitaldj
On Tue, Sep 16, 2003 at 03:22:03PM +0100, Colin Watson wrote: > On Tue, Sep 16, 2003 at 09:43:16AM -0400, Matt Zimmerman wrote: > > In this case, it is important to note what actually changed in the > > package. Personally, I dislike the "maintainer upload, closes:" > > convention, and prefer to re-summarize the changes so that it is clear > > which bugs are being acknowledged. Remember that, when you use Closes:, > > the submitter of the bug only gets a copy of your most recent changelog > > entry, so they won't see what the NMUer wrote. > > ... unless you use the -v option to dpkg-buildpackage to include the > changelog entries from all the NMUs, which I personally think should be > best practice. I think it's a reasonable practice to only include the changes since the last version in the archive; anything more is redundant. I'd say the real bug is not sending the changes to the submitter when the bug is tagged 'fixed'. -- - mdz
Re: Strange rpath problem
On Sun, Sep 21, 2003 at 03:44:42PM -0400, Stephen Gran wrote: > 6) W: kcdlabel: binary-or-shlib-defines-rpath ./usr/bin/kcdlabel > /usr/X11R6/lib > [...] > It's 6 that bothers me. Is this some odd libtool oddity with X that can > be ignored, or is it something real that I should worry about? I don't > remember seeing it when building previous versions, but lintian has > changed since then as well. Running lintian with the '-i' option, or filtering its output through lintian-info(1) will give more information about the message: $ echo "W: kcdlabel: binary-or-shlib-defines-rpath ./usr/bin/kcdlabel /usr/X11R6/lib" | lintian-info W: kcdlabel: binary-or-shlib-defines-rpath ./usr/bin/kcdlabel /usr/X11R6/lib N: N: The binary or shared library defines the `RPATH'. Usually this is a N: bad thing. Most likely you will find a Makefile with a line like: N: gcc test.o -o test -Wl,--rpath N: or N: gcc test.o -o test -R/usr/local/lib N: Please contact debian-devel@lists.debian.org if you have questions N: about this. N: -- - mdz
Re: Strange rpath problem
On Sun, Sep 21, 2003 at 08:15:37PM -0400, Stephen Gran wrote: > Since it is not, I was wondering if others had seen this before. > Building previous versions of this program (albeit with different > versions of the various tools) did not produce this lintian warning. > In fact this prompted me to go back and look at the last built version: > > [EMAIL PROTECTED]:~$ objdump -x /usr/bin/kcdlabel | grep -i rpath > [EMAIL PROTECTED]:~$ > > So, I didn't change anything, but suddenly I am getting an rpath built > in. Odd. Also, notice that X is the only rpath defined, even though > this program links against all the usual KDE stuff (which means about a > billion libraries used during builds). This is what led me think it > might be an issue with X specifically. Ah, I understand. This is presumably a bug in one of the underlying tools, then. Do you run aclocal/autoconf/automake during the build? If so, any one of the files pulled in by those tools could have changed. You can probably narrow it down by searching through the files they generate to find out where the rpath is coming from. libtool has been known to do this in the past (see #170350, for example) -- - mdz
Re: MIME policy, use of /usr/lib/mime
On Mon, Sep 22, 2003 at 11:50:43AM +0200, Florent Rougon wrote: > MIME support sub-policy at > http://www.debian.org/doc/packaging-manuals/mime-policy/ it seems to me it > is the only place to put these files currently (I noticed > /usr/share/mime-info but it looks gnome-specific). > > linda complains because my package is "Architecture: all" and puts > things in /usr/lib. > > I think it is not impossible, although unlikely, to have packages > register arch-specific MIME entries (think of a viewer written in > assembly for $ARCH...). Therefore, /usr/lib/mime doesn't look totally > wrong to me for some cases at least (a combination of /usr/lib/mime and > /usr/share/mime would be better, probably, but doesn't seem supported > right now). > > So, I would say that given the current status of things, linda should > not report an error for this issue, and I should file a bug report. What > do you think? These files should not be architecture-specific, so mime-support should probably be updated to use /usr/share. I say this without knowing much about how it works. I would recommend raising the issue on debian-devel. > BTW: the file > ftp://ftp.debian.org/debian/doc/package-developer/mime_policy.txt.gz > referenced on > http://www.debian.org/doc/packaging-manuals/mime-policy/ch1.html > does not exist. This should probably be a bug on packaging-manual if the bug is still present in the most recent document. -- - mdz
Re: MIME policy, use of /usr/lib/mime
On Mon, Sep 22, 2003 at 02:39:45PM -0400, Matt Zimmerman wrote: > On Mon, Sep 22, 2003 at 11:50:43AM +0200, Florent Rougon wrote: > > BTW: the file > > ftp://ftp.debian.org/debian/doc/package-developer/mime_policy.txt.gz > > referenced on > > http://www.debian.org/doc/packaging-manuals/mime-policy/ch1.html > > does not exist. > > This should probably be a bug on packaging-manual if the bug is still > present in the most recent document. Er, packaging-manual doesn't exist anymore, of course. mime-policy is part of the policy manual, yes? -- - mdz
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 05:59:43PM +0200, Sven Luther wrote:
> I have some code that was using :
>
> printf (__func__ "Message", ...);
>
> This doesn't build anymore with gcc 3.x, since __func__ is treated as a
> variable, not a string literal.
>
> What would be the best way of working around this ? Replacing all these
> constructs with :
>
> printf ("%sMessage", __func__, ...);
>
> Works, but seems a bit ugly, and there are _lots_ of those lines.
>
> Is there a compiler switch to consider __func__ as string literal or
> something such ?
That behaviour is mandated by ISO C99, so even if it were possible to
override it, the code needs to be fixed.
The gcc-specific __FUNCTION__ and __PRETTY_FUNCTION__ are string literals,
like what is expected here, except in C++, where they act like __func__.
See "(gcc)Function Names". It'd really be best to adapt it to use __func__
properly, since this is a standard which will be honored by other compilers.
--
- mdz
Re: proper way to pack package from multiple sources?
On Tue, Oct 14, 2003 at 11:35:03AM +0200, Magosányi Árpád wrote: > The syslog-ng package consists of two sources: syslog-ng itself, and > libol. > Now the packege is created by unpacking syslog-ng, dropping the libol > tar.gz into the source tree, and adding the debian dir. > It follows that either I build a package which looks like a native > debian package or dpkg-source complains about unrepresentable changes > to source. > I don't want to package libol separately, as it is deprecated: > it is used only by syslog-ng and bwall. The devel version of syslog-ng > does not use it, and bwall's only proxy (ck-gw) made obsolete by the > ZAS authentication method of Zorp. > > Question: what is the proper way to package syslog-ng? Wait for the next release which doesn't require libol, or repackage .orig.tar.gz so that it actually has what you need for building the package. -- - mdz
Re: Splitting a package
On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a command line program and a couple of > front-ends (motif and KDE) for it. This makes neccessary to install > lots of KDE libs even if you're only using the command line program. > > Would all this Depends justify splitting it into the command line > package and the front-ends one? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215502 It is up to you, based on your knowledge of the package and its users, to decide if this makes sense. For example, if the purpose of the CLI is to allow the software to be used without KDE, then it would be sensible to provide it in a separate package to be used with KDE. If it is a program which is meant to be used with the KDE portions, and isn't very useful without them, then it would not make sense. -- - mdz
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 11:51:12PM +0200, Sven Luther wrote:
> On Thu, Oct 16, 2003 at 12:26:42PM -0400, Matt Zimmerman wrote:
> > See "(gcc)Function Names". It'd really be best to adapt it to use __func__
> > properly, since this is a standard which will be honored by other compilers.
>
> What would be the best way to adapt it ? Use the
>
> printf ("%sMessage", __func__, ...);
>
> form ?
Yes.
--
- mdz
Re: library soname changed, now what?
On Mon, Oct 20, 2003 at 02:37:07PM +0200, Robert Lemmen wrote: > - bump the version number a bit and add a respective changelog entry, > then re-upload Yes, as with any other change to your package. > - or ask (where?) to rebuild the source that is already in the archive ? No, see http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s5.9.3 -- - mdz
Re: how to make reportbug verbose?
On Fri, Oct 24, 2003 at 05:30:26PM +0200, Frank Küster wrote: > The funny thing is that I had an informal mail contact with the user and > asked him to make a formal bug report, so that I could see Depends and > all. I had no idea that one could turn this info off, and I fear the > user hasn't, either. Perhaps the user filed the bug report by hand, not using reportbug? -- - mdz
Re: Audio Apps Mini-Policy, v0.1
On Tue, Oct 28, 2003 at 09:43:07PM +1100, Zenaan Harkness wrote:
> This is a follow up to the jackd/ dpkg-statoverride thread, and a
> request for comment on the below. Once informally vetted here, I will
> post to debiam-multimedia.
>
> Input appreciated
> Zen
>
> ---
> Title: Audio Apps Mini Policy
> Authors: Zenaan Harkness
> Version: 0.1
> Date: 2003-10-28
>
> Applicability: Audio apps requiring realtime scheduling (or other root)
> privileges to operate effectively.
>
> Policy:
> Audio applications or applets (ie. executable files) requiring realtime
> privileges should be installed as follows:
> - user = root
> - group = audio
> - permissions
>- SUID root
> - have a debconf question asking to allow/ deny this
> - [debconf question "importance level"??]
- application must _completely_ relinquish root privileges
_immediately_ after obtaining the CAP_SYS_NICE capability
(if you aren't sure, ASK)
I'm actually starting to wonder whether we should have a general facility
for these sorts of things. Having apps be setuid root and expecting them to
behave responsibility is asking for trouble; it would make much more sense
to grant them only the capability that they need. I don't know whether
there is a filesystem extension to grant capabilities to binaries, but we
probably couldn't rely on it anyway. We _could_ implement a setuid root
wrapper which would read a configuration file listing which binaries should
be granted what capabilities, with relative ease.
> Anyone, how does Andreas' comment "We _do_ have an audio-group and users
> who need to have access to /dev/{mixer,snd,dsp,..} should be put in there,
> instead of making the app SGID." apply here - ie. am I confused about the
> use of SUID?
This is something different. For applications which require access to the
sound device, they should have no setid permissions and expect that the user
already has permission to access the device through their group membership.
> Another comment I received, this time about capabilities, was the
> following (there is the JACK (jackd) audio daemon, and "jackstart" program
> to run it): "With jackstart. you can run jackd and it's clients as
> non-root user - only jackstart has to be setuid root, jackd need not.
> This has the advantage that files recorded with a jack client like ardour
> aren't owned by root, for example."
This is a similar idea to the wrapper I described above, though it probably
works quite differently (maybe even specific to jack).
--
- mdz
Re: jackd/ dpkg-statoverride/ "audio" group question(s)
On Tue, Oct 28, 2003 at 09:52:52PM +1100, Zenaan Harkness wrote:
> One method is jackd/ jackstart. jackd runs as root, jackstart starts it,
> and can be run as any user, and uses kernel "capabilities" to give jackd
> the required scheduling priority ("realitime").
Why on earth would a sound server run as root? I hope this is a
misunderstanding, as I'm not familiar with jack. In should either:
- Be started as root, set its scheduling priority, and drop all unneeded
privileges
- Be started as root, gain CAP_SYS_NICE to set its priority later, and drop
all unneeded privileges.
The former being preferable, if it does not need to change its priority
during its lifetime.
> On Mon, 2003-10-27 at 02:04, Stefan Schwandter wrote:
> > > (BTW, Stefan, why does jackstart use "capabilities" (and therefore not
> > > work with my kernel), and jackd I can use --realtime option and it
> > > (seems to) works?)
> >
> > With jackstart. you can run jackd and it's clients as non-root user -
> > only jackstart has to be setuid root, jackd need not. This has the
> > advantage that files recorded with a jack client like ardour aren't
> > owned by root, for example.
>
> Perhaps there is also some third option as underlined above - "use a
> privileged audio device user". Can this be explained to me, is it a
> new option or just one of the above two?
>
> Once this is hashed out, I'm sure the folks on [EMAIL PROTECTED]
> will be appreciative (and our future audio users, such as myself).
This is probably similar to what I said above. If jackd only needs
permissions to access the sound device, it should run as a user (jack or
such) who is a member of the audio group, and NOT as root.
--
- mdz
Re: Audio Apps Mini-Policy, v0.1
On Tue, Oct 28, 2003 at 06:45:08PM +0100, Andreas Metzler wrote: > Perhaps execcap(8) can be used as base for the "general facility"? That sounds useful. For our purposes, though, it would need a setuid wrapper in order to do the other work, and that program could probably just as easily set the capabilities also. -- - mdz
Re: Bug closing with intermediate experimental releases
On Thu, Oct 30, 2003 at 11:14:59PM +0100, Martin Pitt wrote: > Bugs 1,2,3 are tagged with fixed-in-experimental by the uploads of the > betas. When we finally put 1.1 into unstable, are bugs 1,2,3 > automatically closed or do we have to join the changelogs from the beta > releases and the 1.1 so that the bugs are explicitly closed by the > unstable upload? Use the -v option to dpkg-buildpackage when you make the unstable upload, so that the relevant entries end up in the .changes file. > (Please keep me CC'ed, I'm not subscribed) Please use Mail-Followup-To: for this, not Reply-to:. -- - mdz
Re: config.sub and config.guess | .diff.gz bloat
On Thu, Nov 06, 2003 at 11:53:48AM +1100, Zenaan Harkness wrote: > debhelper puts the following into the "clean" rule in debian/rules: dh_make != debhelper. > ifneq "$(wildcard /usr/share/misc/config.sub)" "" > cp -f /usr/share/misc/config.sub config.sub > endif > ifneq "$(wildcard /usr/share/misc/config.guess)" "" > cp -f /usr/share/misc/config.guess config.guess > endif > > Three questions: > - why are these two files copied in? No good reason. > - are they necessary for the build of the program I am packaging? Not unless they were already present. > - they make my .diff.gz file twice their otherwise size; can I delete > that entry from my rules file altogether, or otherwise remove them from > the output? Yes. -- - mdz
Re: Looking for apt-get internals guide
(this is debian-devel material; please followup there) On Thu, Nov 06, 2003 at 04:46:39PM -0500, Stephen Gran wrote: > To do so, I ned to know a little more about apt's guts than I do > currently, I'm afraid, and I was hoping someone could point me to a good > reference guide about how apt calls external programs (like > apt-listchanges) and parsing the syntax that apt calls with and that > sort of thing. > > Hopefully I've been clear enough - I only have a rough roadmap in my > head at this point. Other suggestions for smarter ways of doing this > would be welcome as well. There is an internals guide in the apt source code, but it isn't going to be what you want. The best documentation is example code, and there is plenty of that around. The pipeline data is really pretty much self-explanatory; add a hook pointing to /bin/cat and watch it for a while. But, I don't see why you should need to hook into apt at all in order to do what you want. If the files you change are conffiles, your changes should be preserved, and if they aren't conffiles, you can divert them. -- - mdz
Re: kbirthday - neither linda nor lintian clean
On Tue, Nov 11, 2003 at 03:00:45AM +0100, Eike Sauer wrote: > I packaged kbirthday, a KDE kicker applet that reminds > of birthdays (which it reads from the KDE adressbook). > > I've got one message from lintian and one from linda > - but two different ones. > > linda tells me: > W: kbirthday; Contains shared libraries, but is not in > Section: libs or base. > > Technically, a kicker applet is a shared object. > >From users view, it is a (kicker) application. > So I'd like to have it in section "kde". > Is it ok to disregard this warning? > > lintian tells me: > E: kbirthday: no-shlibs-control-file usr/lib/libkbirthday.so I'm not familiar with kicker, but normally, shared objects like this are "plugins", meant to be used with dlopen(3), and not shared libraries meant to be dynamically linked with executables, and as such should be in a subdirectory of /usr/lib, not in /usr/lib itself. Moving the shared library should resolve both of these warnings, and you do not need a shlibs file. >From section 10.2 of the Debian Policy Manual: Shared object files (often `.so' files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the `/usr/lib' directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped.[2] -- - mdz
Re: Packaging phpLDAPadmin. Newbie's questions.
On Wed, Nov 12, 2003 at 02:07:46PM -0600, David Segonds wrote: > 1. Even though, Architecture was set to 'all' in debian/packages, the > 'changes' file I obtain is tagged with 'i386'. Is this normal? The same > thing happen when I repackage phpmyadmin. Yes, don't worry about it. > 2. There is an INSTALL file in the upstream .tar.gz and I want to copy > it in /usr/share/doc/phpldapadmin but 'lintian -l' is complaining about > it saying that upstream install instructions are useless to the Debian > users installing the package. Can I rename this file as README, as it > contains more information than the traditionnal INSTALL instructions? You could rename it, but it would be better for upstream to rename it if it is not installation instructions. That way, pointers to documentation are consistent between upstream and Debian. You could also ignore lintian. > 3. How far should I go in configuring the package after installation? > Should I prompt the user for the information about the LDAP server > he/she intends to connect to? Should I let the user manually edit the > configuration file. Changing two lines is likely to be enough in most > situations. It is up to you, and depends on what you think would provide the best value for you and your users. -- - mdz
Re: Packaging phpLDAPadmin. Newbie's questions.
On Wed, Nov 12, 2003 at 05:06:59PM -0600, David Segonds wrote: > As a newbie, ignoring lintian advices does not seem the right thing to > do for some reasons. :) > > Which raises another question. How good are lintian advices? > > If lintian developers spent time integrating those warnings, they must > be of some value. It depends on the test. Some tests are inherently less accurate than others. Lintian cannot interpret the contents of a text document named INSTALL; it can only infer the contents from its name. If the contents are correct, lintian is wrong, but then also the file could be incorrectly named. > Do sponsors systematically run lintian before agreeing to upload a > package? Can a lintian warning stop an upload? I run lintian and/or linda on every upload, as do many others. I'm sure there are others who do not. Regardless, it is understood that these tools are not infallible. > Packaging time is also a factor. It is only a few well documented lines > that need to be changed in the configuration file but automatizing the > process may require a lot of work. As a user, I go an twick conffiles > myself. Can I expect this from the "average" user? (if such a thing > exists) You likely know your users better than anyone else; you are one at least. If you're concerned about whether it would take too much time or effort to implement it correctly, try the (much simpler) conffile approach first, and consider adding more involved configuration options in the future if it seems to make sense. -- - mdz
Re: Packaging phpLDAPadmin. Newbie's questions.
On Thu, Nov 13, 2003 at 09:51:22PM -0600, David Segonds wrote: > On Fri, Nov 14, 2003 at 10:46:35AM +1100, Matthew Palmer wrote: > > > What's to heavily modify? I presume the config file is a fairly reasonable > > format, in which case a search 'n replace for 'config_option\s=.*$' to > > 'config_option = ' would appropriately modify the file to suit > > your needs. > > The default config file looks like this: > > =-=-=-= > $i=0 > conf[$i]['host'] = 'foo' /* A comment */ > conf[$i]['port'] = 'bar' /* A comment */ > > $i++ > conf[$i]['host'] = 'whatever1' > conf[$i]['port'] = 'whatever2' > =-=-=-= This is horrific, and should be fixed for the sake of your and your users' sanity. -- - mdz
Re: recommended sid upgrade method
On Tue, Nov 18, 2003 at 09:49:03PM -0500, Neil Roeth wrote: > On Nov 18, Zenaan Harkness ([EMAIL PROTECTED]) wrote: > > I assume that (generally speaking) as DD's (in NM training or otherwise) > > are expected to have a reasonably up to date sid install, whether > > native, chroot, or whatever. > > > > What I'd like to know is, which upgrade command should I use. For > > example, I currently know of, and have used, the following: > > > > 1) apt-get upgrade > > 2) apt-get dist-upgrade > > 3) apt-get dslect-upgrade > > 4) aptitude dist-upgrade > > 5) wajig dist-upgrade > > > > I never read the man pages enough to grok 1), so really always used 2), > > up until a month or two back when I discovered 3), and I've looked with > > interest at the difference in download size between 2) and 3). I guess I > > need to read the man pages to grok the difference there again too. > > Finally, now there is 5), and I wonder which one it corresponds to... 1) Will upgrade as many packages as possible without installing any new packages or removing any installed packages 2) Will uprgade as many packages as possible, attempting to be smart about what to remove and install in order to upgrade installed packages 3) (assuming you mean dselect-upgrade) is intended to be used with dselect, and uses the selection information in the status file. If you aren't using dselect, it probably isn't always what you want. 4) Is mostly equivalent to 2, but gives you much more flexibility by allowing you to make changes to the proposed upgrade before executing it. 5) Is probably equivalent to 2. -- - mdz
Re: Moving a config file
On Thu, Nov 27, 2003 at 04:07:06PM -0500, Stephen Gran wrote: > I have to move a config file, and I am not sure of the best way of > handling it, so I wanted to ask for opinions. > > The problem is that I am currently shipping an /etc/default/$package, > which needs to now become /etc/$package.conf - it's not a shell script, > but more of a hacked together config file. What I want to do is ensure > that any user changes to the old /etc/default/$package file get > seemlessly merged into /etc/$package.conf, but not mess up any user made > up $package.conf Is the file a conffile, or not? If it is a conffile (and if it is shipped in the package, it must be), then move it in preinst (wrapped in appropriate checks, such as package version and file existence), and dpkg will handle the rest. -- - mdz
Re: Moving a config file
On Fri, Dec 05, 2003 at 02:30:46PM -0500, Stephen Gran wrote: > This is the kind of thing I want to do - how do I extract $old_version? > I want to do the move if upgrading from >> 5.4-5, but not after that, so > that I don't keep on doing funky things to users' conffiles. Pointer to > refs would great. Debian Policy Manual (this is the usual place to look for these things), section 6.4. -- - mdz
Re: How to package a database (not program)?
On Tue, Dec 09, 2003 at 11:06:51PM -0800, David Braun wrote: > The data comes from the USDA as a file designed to be imported into a > relational database (such as MySQL). It's really not very useful > otherwise. My question is how do I package this correctly? I want my > package to import it into a database, but I don't want to dictate to the > user which database program to use. Something appropriate might be for > the configure script to ask the user for the name of a SQL server, along > with a user name and a password. I'm not sure this would be sufficient, > though, because as a new student of SQL I'm learning there's no standard > way of creating a database (horror!). So maybe this would mean the > package would have to look for local client drivers of MySQL, > PostgreSQL, etc. Not only that, the data types often vary for different databases, though hopefully your data is simple enough that this isn't a problem. I would simply include the SQL dump under /usr/share and leave it to the user where to import it. It's possible that they will want to create a new database, or import it into an existing one (perhaps even with different table names), or transform it from SQL into something else. -- - mdz
Re: Standards-Version
On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > I am planing to adopt my first package (emelfm, orphaned). So I checked what > needs to be done to equip myself for this task. > > There seems to be one current problems with that package: > The ToDo says the Standards-Version is too old 3.5.2. Should be 3.6.1. > > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody > perhaps know what needs to be done for a simple gtk-program to be moved from > 3.5.2 to 3.6.1? /usr/share/doc/debian-policy/upgrading-checklist.txt.gz -- - mdz
Re: How to package a database (not program)?
On Thu, Dec 11, 2003 at 09:47:45PM -0800, David Braun wrote: > On Thu, 2003-12-11 at 12:42, Matt Zimmerman wrote: > > I would simply include the SQL dump under /usr/share and leave it to the > > user where to import it. It's possible that they will want to create a new > > database, or import it into an existing one (perhaps even with different > > table names), or transform it from SQL into something else. > > Thanks for the advice. Since sending my original message I've > discovered SQLite and think it's the most appropriate database for my > application (and probably for anyone else's application). SQLite stores > its data in a file and doesn't use a server so it simplifies the problem > significantly--all my package has to do is provide the file (under > /usr/share as you suggest). There is value in my providing an SQLite > file instead of what one gets from the USDA because they describe their > tables in a PDF document, and it's nontrivial to type in the table > description for the import process. > > If in the future someone has a need that goes beyond an SQLite file I'll > be happy to package it differently, but I think this should be fine for > now. What if I want to import the data into a MySQL database? Is it trivial to do that from an SQLite data file? If not, I think it would be a good idea to provide the master format as well (SQL? tab-delimited?). -- - mdz
Re: How to deal with sql-database structures on upgrade
On Mon, Dec 15, 2003 at 11:05:12PM +0100, Thorsten Sauter wrote: > > I'm going to adopt cacti[1]. But I have a problems with a clean upgrade > path to the new upstream version. > > Cacti use a mysql database to store the configuration values (including > users/password, graphic options, layouts, ...). The new upstream version > (0.8.x) use a completly new designed database structure then the old > version, which is currently already packed for Debian. > > I have tried to write some postinst scripts to migrate the existing > database into the new one, but I think now this is impossible, because > maybe informations which are needed in the new version are missing in > the old one. Missing information should not be a problem; you can either provide a default, or ask the user with debconf for the correct answer. -- - mdz
Re: ignoring updates to a conffile?
On Sun, Dec 28, 2003 at 05:04:54PM +0100, Andreas Barth wrote: > I want to do the following to a configuration file: Ignore all updates > of the conffile inside the .deb (in other words: just keep what's > installed on the system). At the moment this file is marked as > conffile. If the file stops being a conffile, it _must_ no longer be included in the .deb. To do so would not provide policy-compliant behaviour. > A rather problematic issue is on upgrades from a previous package > where the previous one had it as a conffile. I think about the > following: Just removing this file in the deb, and then do in > postinst: > if [ ! -a file -a -a file.dpkg-old ]; then > mv file.dpkg-old file; > fi > > if [ ! -a file ]; then > cp template file; > fi I think you mean "-f" for most of those "-a". You should not be touching anything ending in .dpkg-*. The copy seems reasonable, but the mv is unnecessary and should be omitted. When the package is upgraded from a version with the conffile to a version without the conffile, the actual config file on the system remains, and should be left in place. -- - mdz
Re: ignoring updates to a conffile?
On Sun, Dec 28, 2003 at 11:02:23PM +0100, Andreas Barth wrote: > * Matt Zimmerman ([EMAIL PROTECTED]) [031228 22:25]: > > I think you mean "-f" for most of those "-a". > > I don't mean "-f", because a symlink is also ok. (But I do perhaps > mean a "-f file -o -h file" or "-r file".) Yes, you do, in fact, mean -f. Try it. > > You should not be touching anything ending in .dpkg-*. The copy seems > > reasonable, but the mv is unnecessary and should be omitted. When the > > package is upgraded from a version with the conffile to a version > > without the conffile, the actual config file on the system remains, and > > should be left in place. > > Ah, ok. I thought that on removing the file from the package, dpkg asks > also to remove the file from the filesystem (and removes it so to > file.dpkg-old). If that is not the case, I can of course omit the first if > ... fi. No, that is not the case. This is trivial to test. -- - mdz
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 11:06:35AM -0500, Jay Berkenbilt wrote: > Now I'm strongly considering making the switch to Debian and am > evaluating moving my whole installation system over to dpkg. dpkg > seems superior to rpm in almost all respects (richer dependencies, > better documentation, more robustness, apt, etc.), but there's one > thing that bothers me. When building an rpm, multiple source files > and multiple patch files can be specified, and arbitrary commands can > be used to extract sources and apply patches. This makes it easy to > build an rpm of a standard package with a handful of separately > maintained patches applied. While multiple patches are certainly advantageous (and are, I believe, intended to be supported in the next version of the Debian source package format), I don't like the idea of arbitrary commands to extract sources and apply patches. I very much prefer being able to unpack and examine the source of a package without trusting the person who created it. There are various systems used in Debian which pack multiple patches into the Debian .diff (see dpatch, cdbs, etc.). > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? > Coming from an rpm perspective, it seems to me that this would make it > much more difficult to manage locally modified versions of packages. I prefer to use CVS (see the cvs-buildpackage package) to maintain local branches of Debian packages. Since CVS doesn't separate patches either, there isn't much lost there. > Lastly, please feel free to correct my terminology if I'm using it > incorrectly. For example, is it correct to say dpkg-based rather than > deb-based? dpkg is a program which operates on Debian packages. "deb" is a common shorthand for the Debian binary package format. -- - mdz
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 08:55:55PM +0100, GCS wrote: > On Tue, Dec 30, 2003 at 05:56:33PM +0100, Thomas Viehmann <[EMAIL PROTECTED]> > wrote: > > It is also not uncommon to make an orig.tar.gz of (possibly multiple) > > upstream tarballs by putting them in a directory and tarring that. > Ofcourse you mean tar+gzip that, as orig is always tar.gz; alhough I > think it's quite unefficient to have upstream source in tar.bz2 in some > dir, and tar.gz it into orig.tar.gz ... Sometimes I feel that it would > be better to utilize source mirrors. I mean Debian ftp servers would > carry the diff.gz+dsc files, but not the package source (orig.tar.gz) - > instead a mirror list for that source should be maintained, and > automagically downloaded by 'apt-get source' from the first available. In addition to unnecessarily complicating what is currently a simple and reliable process, this would violate the licenses of much of the software that Debian distributes. -- - mdz
Re: Python executables inside libraries
On Thu, Oct 21, 2004 at 11:41:09PM +0200, Magnus Therning wrote: > Well, they can't go into /usr/bin, they are part of the library. > However, for some reason upstream decided to put the python equivalent > of a main() in some of the files that make up the library. That's a reasonable thing to do. Just make them non-executable and remove any #! line. They can still be invoked with "python foo.py" if the user wants this. -- - mdz
Re: creating Release files
On Mon, Oct 25, 2004 at 12:30:52AM -0400, Ervin Hearn III wrote: > On Mon, Oct 25, 2004 at 12:11:48AM +0200, Marco Herrn wrote: > > Hi, > > > > where can I find information about the structure of Release files? And > > are there any tools to create them automatically? > > > > Regards > > Marco > > Hi Marco, > > The best resource I've found has been: > > http://www.debian.org/doc/manuals/repository-howto/repository-howto.html#release > > I'm not aware of any utility for creating them, but I haven't looked too hard, > since they are fairly simple text files. > > I hope that helps. That recipe does not account for the MD5 hashes, which will become much more important in the near future when we start using them to authenticate packages with apt. apt-ftparchive generates complete Release files. -- - mdz
Re: packaging ckermit: lots of questions
On Sat, Jan 10, 2004 at 04:45:12PM -0800, Matt Zimmerman wrote:
> On Sat, Jan 10, 2004 at 06:59:33AM +, Ian Beckwith wrote:
>
> > I recently ITA'd ckermit, ("a serial and network communications
> > package"). Packaging the latest version raised lots of (hopefully
> > non-stupid) questions:
>
> Do you realize that ckermit is already packaged in stable/non-free and
> testing/non-free, and has been removed from unstable (I believe for license
> reasons)?
Oops, you said ITA, not ITP.
--
- mdz
Re: packaging ckermit: lots of questions
On Sat, Jan 10, 2004 at 06:59:33AM +, Ian Beckwith wrote:
> I recently ITA'd ckermit, ("a serial and network communications
> package"). Packaging the latest version raised lots of (hopefully
> non-stupid) questions:
Do you realize that ckermit is already packaged in stable/non-free and
testing/non-free, and has been removed from unstable (I believe for license
reasons)?
--
- mdz
Re: data files in /etc?
On Thu, Feb 12, 2004 at 10:47:15PM +0100, Magos?nyi ?rp?d wrote: > There are some files in /etc which are actually data files representing > the state of the system. Like /etc/mtab, /etc/network/ifstate, or > /etc/lvmconf/* (it is not even a text file). > These files are written by programs in occasions one cannot with good > heart call configuration. Isn't it against the policy? mtab is explicitly blessed by the FHS. The other files are there for the same reason that mtab is, which is that they must be on the root filesystem. -- - mdz
Re: RFS: truncate (now it's free, for real!)
On Fri, Mar 05, 2004 at 08:15:54AM +0100, Luca Pasquali wrote: > author put it under GPL, new debs are here: > > http://ketavet.dyndns.org/truncate Is something so trivial worth packaging? It sounds like it doesn't do anything that dd doesn't. If I've misunderstood and this does more, could you try to write a better description? The one that you provided is confusing, and has a number of typographical and grammatical errors. debian-l10n-english can help. Description: truncate a new or existing file to a new, smaller or bigger, size A few of C code to resize a file to a determined byte lenght, you can chuck it, you can get it wider, remember to backup your file, or you may get you favourite pr0n truncated at the best point. -- - mdz
Re: scripts in /usr/share/$package?
On Fri, Mar 05, 2004 at 04:45:20PM +0100, Andreas Metzler wrote: > On Fri, Mar 05, 2004 at 04:24:01PM +0100, Frank K?ster wrote: > > although I've read the policy again, I am not sure whether it is allowed > > to store scripts in /usr/share/$package? In particular, scripts that are > > only meant to be called by postinst (or prerm), never by a user. They > > could go to /usr/lib/$package, but that would mean creating an extra > > directory. Therefore I'd prefer to keep them in /usr/share/$package > > which exists anyway. Is this o.k.? > > > *IMHO* If they are arch-independent (and "scripts" usually are) > /usr/share/$package is correct and /usr/lib/$package would be a bug. That's not entirely accurate; the FHS was rather ambiguous on this point the last time I checked, and it's not necessarily a simple matter of deciding based on architecture dependence. For example, it would be rather silly for a package containing multiple auxiliary programs to divide them up between /usr/lib and /usr/share according to whether they were scripts or binaries, and even sillier to have to move them around between the two if they were rewritten in a different language. -- - mdz
Re: Development packages.
On Mon, Mar 22, 2004 at 08:54:17PM +, Roger Leigh wrote: > I used a statically-linked binary just a few days ago. I needed to > resize an NTFS partition on a newly-delivered system which came with > Windows XP. In the event, I was able to get a statically linked > binary, copy it onto a floppy and run this after booting from a rescue > disk. It should be much simpler and faster to copy the existing binary and its shared library dependencies from a running system than to recompile the program from source. It would probably be larger, so you might need to compress it to fit onto a floppy, but it still seems easier. If you need more than a "quick fix", a rescue CD is the way to go, as others have mentioned. > It's also useful when you want to provide something that "just work" with > no extra dependencies. While proprietary/commercial software was the > biggest user of this, it's also useful for free software. What if Joe > Average would like to run my program which makes use of libstdc++, GTK+ > 2.2 and GNOME 2.4? It's the least hassle way to achieve this. The Debian packaging system is another way to accomplish the same goal (among other things), and I find it preferable to static linking. :-) > On a related note, I'd also be very happy if it was a requirement to > build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip > them. We could provide some mechanism to automatically strip > binaries, surely? We can do better than that. See dh_strip --dbg-package=. -- - mdz
Re: Iuusues when packaging libraries..
On Sun, Apr 04, 2004 at 01:24:59PM +0200, Robert Ribnitz wrote: > I am responsible for the package htdig. Htdig is a full-text indexer for > (local) sites, ie. will generate a full-text (searchable) index of that > site. > The thing is written in C++, and comes with loads of libraries. While > the procedure described in the various manuals (the shlibs system) is > great if you have very few libraries that do not interdepend, it is imo > not a solution for cases like mine (over 30 libraries, that interdepend). > > Hence my mail to this list. I am looking for a solution to package those > libs, if possible without getting warnings like: > > >dpkg-shlibdeps: warning: could not find path for (libraryname-version.so) If the libraries are private (only used by htdig itself), then you can avoid some of this if you can write correct dependencies without the shlibs system. In this case you should also generally move the libraries into a subdirectory of /usr/lib. I can't imagine that it provides 30 separate libraries which would be useful to other programs. See the mozilla package for an example. -- - mdz
Re: Separating packages.
On Mon, Apr 05, 2004 at 09:24:10AM +, n.v.t n.v.t wrote: > Hello all. > > I have simple question which I could not find in the debian policy, maybe > someone could point me out to that section or the right documentation? Or a > explanation would be nice. I'm debianizing a package that I would like to > split up in several parts, the package has a 'backgrounds' directory a > 'icons' directory and a 'examples' directory. How do I handle this? I would > like to create packages like: > > package-backgrounds > package-icons > package-examples > package-name (which contains all of the above) Should I do this as a > meta-package? How do I create a meta-package? Is it really necessary to split it up like this? What is gained by placing the icons and backgrounds in separate packages? If the program isn't useful without this data, then it should be included in the same package with the program, unless (for example) it is very large and could benefit from being moved into an architecture: all package. Even in that case, do the backgrounds and icons need to be separate? -- - mdz
Re: Separating packages.
On Mon, Apr 05, 2004 at 12:57:55PM +, n.v.t n.v.t wrote: > >Why? How big are the components? Would somebdy e.g install package-name > >without package-icons or the other way round? > > It was a example. The person might only want the backgrounds or only the > icons. This alone is not sufficient reason for producing four packages instead of one. This wastes resources in many places (the Debian package list, the dpkg database, etc.). You must consider whether the benefit is worth the cost. Certainly, the user might only want some of the things in the package. But would it hurt him to have all of it? -- - mdz
Re: How to deal with Python script
On Mon, Apr 05, 2004 at 04:12:30PM +0100, Tom Huckstep wrote: > On Mon, Apr 05, 2004 at 03:43:51PM +0200, Frank K?ster wrote: > > > 1. Add a Depends: on Python > > > 2. Remove 'teepeedee-share' from the .deb > > > 3. Put teepeedee-share in a separate package > > > 4. Replace the 'teepeedee-share' with a shell wrapper, which calls the > > > script > > >if Python exists > > [...] > > > I like 4. and it is what I have implemented, but my sponsor is > > > not so keen. > > > > Have you considered adding a "Recommends" or "Suggests"? > > That's a good idea, I'd forgotten to do that. Do you think that will be > enough, or is there something else I should/could do? If you wish, you can modify the script so that if the user attempts to use it and python is not installed (which is rather rare, since python is Priority: standard), it prints a helpful message explaining that python is needed in order to run the program. But I don't think this is really necessary in this case. -- - mdz
Re: Separating packages.
On Tue, Apr 06, 2004 at 11:29:54AM +0300, Fabian Fagerholm wrote: > Of course, with the current version of dpkg, your point is very good and > entirely valid. > > Thinking ahead, wouldn't it be a good idea to fix dpkg and the package > list to support a larger number of packages? The problem with the package list is simply that it is too large. This is a problem for low-bandwidth users and users with small amounts of memory, for example. It also makes package management UIs harder to navigate, produces additional work for tools which must process each binary package, makes package searches less likely to find the right thing... > The number of packages in Debian has been constantly growing, and if I'm > not mistaken, a release of sarge would include somewhere between 1 and > 15000 packages. A presumptive sarge+1 could very well have much more than > 15000 packages. Yes, we have more than enough growth from adding new software; there is no need to compound the problem with unnecessary splits. -- - mdz
Re: package adding users
On Tue, Apr 06, 2004 at 03:45:46PM +0200, Francesco P. Lovergine wrote: > On Tue, Apr 06, 2004 at 09:18:20AM -0400, Erik Bourget wrote: > > What's the best/accepted way to have a package add users to a Debian system? > > I have a daemon that has no need to run as root (but a need to store its own > > datafiles, etc, so nobody is out) and would like to have it run under a user > > account. Gerrit Pape's qmail package does an ugly > > hit-control-c-if-you-don't-want-these-users thing that I don't like. > > Use useradd. Generally you could also use debconf to ask > confirmation/usernames > for that, but it's not mandatory. adduser is the correct tool. See policy 9.2.2. I do not think that useradd follows, e.g., the uid allocation guidelines in that section, and adduser's semantics are more convenient for maintainer scripts as well. -- - mdz
Re: How to flag an upgrade?
On Tue, Apr 06, 2004 at 10:57:27PM +0200, Gianluca Ciarcelluti wrote: > I developed a package under debian. > When I try to install it trough "apt-get update && apt-get upgrade" it > continue to reinstall it instead of display the message > "Sorry, hexedit is already the newest version.". > > I whoud pleasent who can help me to undertand the right way to do it... This means that something in the .deb file doesn't match the Packages file. Perhaps you forgot to update Packages (use apt-ftparchive). -- - mdz
Re: How to flag an upgrade?
On Wed, Apr 07, 2004 at 12:26:57AM +0200, Gianluca Ciarcelluti wrote: > If coul'd help here is my control file: > --- > Source: alga > Section: unknown > Priority: optional > Maintainer: Gianluca Ciarcelluti <[EMAIL PROTECTED]> > Build-Depends: debhelper (>> 3.0.0) > Standards-Version: 3.5.2 > > Package: alga > Architecture: all > Version: 0.9-3 > Description: Applicazione Libera > -- > > and the Packages file: > -- > Package: alga > Section: contrib/web > Mantainer: Gianluca Ciarcelluti <[EMAIL PROTECTED]> > Architecture: all > Version: 0.9-3 > Filename: project/alga/alga_0.9-3_all.deb > Size: 378572 > Description: Applicazione Libera > > > any help is welcome :-) Are you sure these are the right files? The control file (and therefore the .deb) has Section: unknown, while the Packages file has section: contrib/web. Unless you are using an override file, that won't happen. -- - mdz
Re: Separating packages.
On Wed, Apr 07, 2004 at 01:18:11PM +0300, Fabian Fagerholm wrote: > I'm inclined to believe that there are some things that could be done > about this if someone wanted to. Diffs for the package list has been > proposed, and it doesn't take many minutes of thinking to see that it's > actually quite possible to do for a stable release (infrequent changes). > Making the package database efficient for the purposes you describe is > definitely not impossible either, even with a large list of packages. Certainly there are things which could be done to help. I didn't say that the problems were insoluble, but they do exist, and you haven't even begun to consider them all (many different pieces of infrastructure are affected). > From a usability perspective, the technical problems of the package > management system are uninteresting. Presenting the packages in a > well-organized, easily searchable way and letting the user choose what to > install and what not to install is the primary goal. If splitting a > package supports a group of users, and the split doesn't affect the needs > of other groups of users, then I think "the package management system > doesn't scale" is a bad excuse for not making the split. That's the point, though; the split _does_ affect the needs of other groups of users (in many cases, nearly every user of Debian, even if they don't even realize the existence of the package), and the problems are not limited to "[some parts of] the package management system [don't] scale" (though that would be enough for a maintainer to consider). -- - mdz
Re: dh_installinit...
On Mon, May 10, 2004 at 04:20:18PM +0200, Thomas -Balu- Walter wrote: > I'm not sure what would be best practice to avoid those errors, because > the admin might have to configure the video device first anyway (though > the default /dev/video0 is usually a nice guess). > > Have an /etc/default/camsource where the admin has to enable the daemon > setting $START_CAMSOURCE? > The init script could display something like > "Please configure camsource using /etc/camsource.conf and enable it in > /etc/default/camsource if you want to use init to start it." > if not enabled... > > Use --no-start with dh_installinit and stop the daemon manually on > uninstall in prerm? > > Other? Let it fail to start; simply don't allow this to break the postinst. -- - mdz
Re: Secure temporary fifo creation
On Sun, May 16, 2004 at 09:30:10PM -0500, Greg Deitrick wrote: > What is the recommended method for securely creating a temporary named pipe > in > C code? > > Looking at the man pages for various library calls it appears that tmpfile(3) > is probably an acceptable means of creating a temporary file, but this > returns a FILE *. The upstram source I'm packaging needs to make a temporary > fifo. It uses tempnam(3) to get a temporary file name as a char *, and then > mkfifo(3) to make the fifo named pipe from the file name. Is this > sufficiently secure? Should I post this to debian-security? That method has exactly the same risks as taking no precautions at all, since tmpfile(3) deletes the file after opening it. Use mkdtemp(3) followed by mknod(2). -- - mdz
Re: setgid-wrapper
On Wed, May 19, 2004 at 07:53:46AM -0400, James Damour wrote: > In this case, this setgid-wrapper concept would work for *all* Java > applications. I'm still not sure if it will work for shell driven apps > in general, but it sounds reasonable. Security may be a concern, but I > believe that a simple, well written setgid-wrapper program, that only > runs programs listed in its (root-owned) configuration file should be at > least as secure as cron or at. We should be sure to borrow the > configuration update logic from cron or at to make sure that we are > modifying the file in a way that is both secure, and meets Debian > project guidelines. > > Should I take the first crack at writing setguid-wrapper? Should we > pass the concept by Debian Security first? I apparently missed the beginning of this thread; could you explain the problem and your proposed solution? -- - mdz
Re: Virtual packages visavi Real packages
On Thu, May 20, 2004 at 11:05:06AM +0200, Turbo Fredriksson wrote: > The problem is that there's a REAL 'slapd' package on the Debian > GNU/Linux APT archive(s) which seem to override _my_ virtual > package(s). > > I would like to have my packages to override the 'original' one > (they have A LOT newer version). Virtual packages don't exist to override real packages; they satisfy (unversioned) dependencies. If you want your virtual package to be used instead of the concrete one, install it explicitly, and then the real package won't need to be installed to satisfy any dependencies. -- - mdz
Re: PPPoE and Portslave
On Thu, May 20, 2004 at 08:09:43AM -0500, larry wrote: > To Whom it may concern > My Name is Larry Sheetz > I'm a Co owner in a Debian based ISP. > > We are currently deploying wireless systems for our isp and noticed that > there is on debian package that we can find that includes PPPoE in > Portslave. > > Since we are developing this, I thought it would be a great idea to get > with others in the debian community and work with those, if any already > developing such a package. I would be very grateful for any guidance. > you can give. You might want to contact the portslave maintainer as a starting point for your work. -- - mdz
Re: /etc/init.d/ script policy violation?
On Mon, May 24, 2004 at 09:40:52PM -0400, David Krovich wrote: > I have a question. If an /etc/init.d script hangs indefinately while > waiting for user input, is this a violation of Debian policy? > > See BTS #221751 for more information. There is no explicit rule in policy about the interactivity of init scripts (you can check this yourself), but I would consider it to be in very poor taste unless the stability of the system is at stake (e.g., manual fsck). -- - mdz
Re: /etc/init.d/ script policy violation?
On Tue, May 25, 2004 at 11:49:46AM -0400, David Krovich wrote: > One question I have however, is should it be a policy violation if a > script hangs waiting for user input? Perhaps the policy document > should be updated to explicitly deal with this case? So far, it does not seem to have been a problem, but you are welcome to propose it through the normal channels. -- - mdz
Re: /etc/init.d/ script policy violation?
On Tue, May 25, 2004 at 02:19:27PM -0400, David Krovich wrote: > Matt Zimmerman <[EMAIL PROTECTED]> writes: > > > So far, it does not seem to have been a problem, but you are welcome to > > propose it through the normal channels. > > Please forgive my ignorance, but what are the proper channels to use > in regards to discussion/modification of a policy document? > > Post to debian-devel? File a bug against the debian-policy package? > Both? Something else? Again, the answer to your question is found in the policy manual. Since you are in the new-maintainer queue, it is a good idea for you to read over some of the documents which explain what we do here. http://www.debian.org/devel/ -- - mdz
Re: setgid-wrapper
On Tue, Jun 01, 2004 at 11:21:23PM -0400, James Damour wrote: > My understanding of the position of Bob and Mike can be summed up as, "in > general, shell script's can't be made to use setuid/setgid securely". > Basically, the problem comes down that a user can manipulate their PATH to > redefining basic commands that are used by the shell scripts (like "ls") > in order to elevate their privileges. It's not impossible, it's just tricky, and the technique you chose has already been implemented (in sudo). -- - mdz
Re: Someone with access to non-i386 architecture needed.
On Thu, Jun 10, 2004 at 12:11:58AM +0200, Bartosz Fenski aka fEnIo wrote: > I prepared package of imgseek for Debian (it's now in unstable), but > unfortunatelly it fails to build on every non-i386 architecture. > > I tested it with pbuilder on my i386 box, but seems that it's not > enough. It works fine in pbuilder but unfortunatelly it doesn't work at > buildd. > > I don't have access to non-i386 archs (well I have but without Debian), > so I can't make further tests. You can reproduce the problem on i386 with dpkg-buildpackage -B. -- - mdz
Re: One Source with Different Build Dependancies?
On Thu, Jun 24, 2004 at 11:55:43AM -0700, [EMAIL PROTECTED] wrote: > I am packaging source which builds two binary packages; however, each > package has different build dependancies. In fact, the packages' build > dependancies conflict. > > I don't think the dpkg tools have the facility to build one binary but not > the other. Nor do I think one can specify different build dependancies for > two binaries built from the same source. > > Could someone please refer me to any discussion of these issues, and any > solutions? If you provide the concrete example that you're working with, perhaps there is a solution. I would start by asking why the build-dependencies conflict and if that can be resolved, before splitting the source package. -- - mdz
Re: dh_makeshlibs and libfam0c102
On Fri, Jul 02, 2004 at 11:57:38AM -0700, William Ballard wrote: > Notice libfam0c102 isn't coming in with a version dependency. Is there > to make dh_shlibdeps add that in? No. Why do you believe that you need to? -- - mdz
Re: dh_makeshlibs and libfam0c102
On Fri, Jul 02, 2004 at 08:48:39PM -0700, William Ballard wrote: > On Fri, Jul 02, 2004 at 03:25:06PM -0700, Matt Zimmerman wrote: > > On Fri, Jul 02, 2004 at 11:57:38AM -0700, William Ballard wrote: > > > > > Notice libfam0c102 isn't coming in with a version dependency. Is there > > > to make dh_shlibdeps add that in? > > > > No. Why do you believe that you need to? > > I dunno. That question was implicit: is libfam0c102 some "special > thing" which doesn't need a version. Is it different from all the other > packages, which *do* specify a verision. I don't know a thing about it. > > I thought either dh_shlibdeps was doing what it wanted by not writing a > version, as you seem to suggest; or if I was doing something wrong. dh_shlibdeps (via dpkg-shlibdeps) uses information that the library maintainer provided (the shlibs file) to determine the appropriate dependency. This mechanism is documented in the policy manual. -- - mdz
Re: [RF Help and S later] flyspray -- lintian Weird error ...
On Fri, Jul 09, 2004 at 04:00:41AM +0200, Pierre HABOUZIT wrote: > I'm trying to package flyspray. all goes pretty cool atm, except ne > weird error I really don't understand : > > lintian complains about a missing dependency on debconf, whereas I have > one ... and I don't understand what's the problem When asking a question about an error message, it is most helpful to include the error message for reference. -- - mdz
Re: apt doesn't handle properly the depends field or I'm missing something?
On Sat, Jul 24, 2004 at 08:03:51PM +0200, Fabio Tranchitella wrote: > But why nobody has yet taken care about it? There is a patch > which (maybe) fix the bug without any answer from the maintainers. If you are interested in seeing this (minor) bug fixed, helpful actions include: - Applying the patch and testing whether it fixes the problem in all cases that it should - Testing further for the many possible regressions - Sending your findings to the BTS - Testing whether the change requires modifications to other apt frontends, and modifying them appropriately I hope that this answers your question and makes it easier for you to help fix this bug, which is apparently important to you. -- - mdz
Re: security fix dependency
On Thu, Jul 29, 2004 at 11:41:37PM +0200, Laszlo 'GCS' Boszormenyi wrote: > I have a seemingly stupid question. Say I am not a DD yet, and has a > security bug in a package I help maintaining. Upstream fixed it, so the > package is ready, but upstream requires new library version from a > dependency than the current Debian version. Asked the library maintainer > recently to upgrade his package, but no answer yet. As the lib is small, > and it's new upstream version contains only bugfixes, I have packaged > it, based on the original maintainer's package. My questions: > - would it be wise to upload the lib to a delayed queue and note the > maintainer or not? > - how should I change the version numbering? If I use the new upstream > version, then lintian correctly see that as I am not in the Uploaders > field, the packaging is an NMU but with wrong version number... If the package is in stable, you must take specific actions: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security -- - mdz
Re: Build-Conficts: gcc-3.3, and varargs
On Sat, Jul 31, 2004 at 06:02:56PM -0700, Steve Langasek wrote: > On Sat, Jul 31, 2004 at 05:58:53PM -0700, Steve Langasek wrote: > > On Sat, Jul 31, 2004 at 08:39:52PM -0400, Justin Pryzby wrote: > > > I have a package (x11iraf) which conflicts with gcc-3.3. For the whole > > > story see below.. > > > > > gcc includes /usr/bin/gcc which is pretty much a necessity, I think. I > > > need xmkmf to work too. For now I have Build-Depends: gcc-3.2, but what > > > can I do to force it to actually compile with that, instead of gcc-3.3? > > > Invoke make with CC=gcc-3.2. > > > If you build-conflict with gcc-3.3, I highly doubt that the autobuilders > > will do what you want -- you may even leave the autobuilders in a > > completely broken state for any packages which follow you. > > ... but also please note that there has discussion of removing gcc-3.2 > from the archive before sarge's release, so there's no guarantee this > will even fix your problem. And that this is also just hiding the problem, which is that the code uses an ancient interface which is no longer supported. Better to focus on moving it to stdarg.h. -- - mdz
Re: Build-Conficts: gcc-3.3, and varargs
On Sat, Jul 31, 2004 at 08:39:52PM -0400, Justin Pryzby wrote: > The code uses which gcc-3.3 doesn't support. is > the new standard. I've done my best to convert the code, but I can't > solve a crash in the of the functions I had to change. This is the right approach, and your efforts are better spent tracking down and fixing any problems with the conversion than trying to hold onto gcc-3.2. > If I read the code, it seems like there's something funky with the first > variable argument. What I have for now is: > > -Tcl_AppendResult(Tcl_Interp *interp, char *p, va_alist) > +void Tcl_AppendResult(Tcl_Interp *interp, ...) I can't find this particular code in the x11iraf package in Debian (1.2-4). This package seems to contain a complete copy of an ancient version of tcl (7.3). If that is where most of the problems lie, it might be less work to convert it to use tcl 8.3 or 8.4, which are available in Debian and have already been updated to use modern C syntax (being about 10 years newer than 7.3). -- - mdz
Re: Problems with Provides/Replaces/Conflicts
On Thu, Sep 02, 2004 at 02:52:59PM +0200, Frank Küster wrote: > Frank Küster <[EMAIL PROTECTED]> wrote: > > > Does anybody have an idea why apt decides "Holding Back tetex-bin rather > > than change dvipdfm"? > > It seems it's an apt bug; after I put the tetex stuff on hold and > dist-upgrade the rest, it works fine. It looks like tetex-bin obsoletes dvipdfm. It should conflict, provide and replace it. -- - mdz
