Re: RFS: cppcheck, new upstream version 1.27
On Tuesday 30 December 2008 23:27:28 Reijo Tomperi wrote: Hi and Happy New Year to all, http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.27-2.dsc Uploaded. Thanks for your contribution. P.S. I'm still not ready yet with my(our) list of findings/wishlists around cppcheck itself, but I'm progressing slowly during the holidays and will send it to you soon. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: advise needed for library packaging
* Paul Wise p...@debian.org [081229 01:01]: I would suggest adding a .symbols file for the new ABI so you can detect ABI breakage in newer upstream versions. s/so you can detect/so dpkg-gensymbols can warn in case of some easy to detect / Before someone thinks that a symbols file suffices to check for ABI breakage After all it can only check the most notorious ones, manual work is still needed to be sure... Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: krypt
Hello again and have/make a happy new year with an early Lenny release. On Wednesday 31 December 2008, Boyd Stephen Smith Jr. wrote: At least mention somewhere that one have to be subscribed to debian-mentors to get a reply. It's on http://www.debian.org/MailingLists/ which should be read before using the mailing lists. We can't really enforce that. All we can do it provide TFM, we can't make people R it. Got it. I've never visited that page and I believe that others may be in that position too. I suggest that you change the mentors.debian.net maintainers guidelines. It currently says: You will be shown an RFS (request-for-sponsorship) template that you can send to the debian-mentors mailing list to draw attention to your package. I believe that it should either suggest to request a CC or even better to point to the code of conduct: http://www.debian.org/MailingLists/#codeofconduct I suggest something like this: You will be shown an RFS (request-for-sponsorship) template that you can send to the debian-mentors mailing list to draw attention to your package. Please read the code of conduct (http://www.debian.org/MailingLists/#codeofconduct) for debian mailing-lists first. Note that you should request to be CC'ed if you are not subscribed to the list As for the 'krypt' package, the kde-pkg list suggested that it should not be packaged for reasons related to lenny freeze and the KDE3-KDE4 transition, so ignore this request. I'll send it to the original author to include the package in his web page. p.s. CC me in any replies. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian etch - Rebuilding a package from source.
On Wed, Dec 31, 2008 at 11:16:46PM EST, Boyd Stephen Smith Jr. wrote:
On Wednesday 2008 December 31 18:45:26 Chris Jones wrote:
What I have done so far is pretty much what is described in the above:
. apt-get source ..
. build-dep ..
. debuild ..
. dpkg -i ..
I'll go ahead and disagree with the others, slightly. This is fine
for packages you are only going to use yourself, or only install on a
system with the same packages installed as your current system. It
also dirties your system with the Build-Depends of the package.
_It_ _will_ _work_ and the packages that come out will be completely
valid. However, making a pbuilder(cowbuilder) environment will make
sure your packages build from source cleanly, and only depend on
packages available from a specific flavor of debian (Etch/stable,
Lenny/unstable, Sid/unstable).
Yes, I also saw pbuilder/cowbuilder mentioned in several places.
I also ran into dh-make and dpkg-buildpackage, and though I did not go
into details in my initial post, the existence of such a variety of
tools is the main reason I posted here.
I did look for a document that would attempt to put the different tools
into perspective and I was not that surprised to come up empty-handed
since it would be a rare individual indeed who has used all of them and
would be able to recommend one best adapted to your needs.
It will also isolate the build process into a chroot, so that you
won't inadvertently forget to list a Build-Depend that you just happen
to have installed and won't have Build-Depends installed on your
running system (which I think is good).
Sounds like a very useful feature but then since debian-live also builds
its target in a chroot, I'm beginning to wonder whether it provides some
way to integrate custom deb's that I have overlooked.
If packaging is just a means to an end, skip the pbuilder for now.
However, if you want to make high-quality package that might be
accepted into Debian, a pbuilder environment is a must.
What would the tradeoff be? Is it a matter of a steeper learning curve?
Does it require more resources such as disk-space?
One problem, though, is that since the build is pretty much
automated, I'm not sure how I could add --xxx configure options that
override the defaults. In particular after reading the man page I
wasn't able to find an option that would let me achieve this.
As with others, I'll just point you at the debian/rules file. That's
the starting point for the build process, so it will normally be your
starting point. Depending on the package, there may also be a file
describing the build process and how to modify/maintain it. If so,
read that along-side the debian/rules file.
Thanks, I would probably have missed that.
Trying to modify the build process without reading and understanding
(at some level) the debian/rules file is similar to trying to modify
the build process of a project that uses a plain Makefile without
reading that.
Another concern is what kind of naming standard I should/could adopt
for my custom .debs so that they integrate smoothly with the apt
packaging system. In other words.. in a way that will be easy to
manage over time and not interfere with possible future apt-get
actions, such as upgrades to a new release etc.
As other have mentioned, using a different version instead of a
different name will allow clean upgrades. The normal way to do this
is ${debian_version}yourname0 for the first private version, then
increment the number at the end for each subsequent private version
based on the same Debian version. E.g. 1.2-2 - 1.2-2yourname0.
If you'd prefer your package *not* be upgraded when there is a new
Debian version, but *be* upgraded when there is a new upstream version
you could use ${upstream_version}+yourname0-${debian_suffix}, e.g.
1.2-2 - 1.2+yourname0-2.
Not to mention that at some point or other there may be cases where I
need different versions of my custom packages.
In both cases you can use holds or apt_preferences(5) to prefer your
version over the newer version.
If you'd prefer your package to not be upgraded at all, you should
rename the package and then have your package Provides the old package
name. This may not work seemlessly if there are versioned Depends of
the old package name, but should work well, especially if you continue
to follow the Debian conventions for package versioning, e.g. by using
one of the previous two paragraphs to guide your version numbers.
IIRC, devscripts has a script/program to compare version numbers if
you aren't sure which one the newer/greater than another.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Thanks for all the details.
CJ
--
To UNSUBSCRIBE, email to
Re: RFS: krypt
On Thursday 01 January 2009, Stefanos Harhalakis v...@v13.gr wrote about 'Re: RFS: krypt': Hello again and have/make a happy new year with an early Lenny release. On Wednesday 31 December 2008, Boyd Stephen Smith Jr. wrote: At least mention somewhere that one have to be subscribed to debian-mentors to get a reply. It's on http://www.debian.org/MailingLists/ which should be read before using the mailing lists. We can't really enforce that. All we can do it provide TFM, we can't make people R it. Got it. I've never visited that page and I believe that others may be in that position too. I suggest that you change the mentors.debian.net maintainers guidelines. It currently says: You will be shown an RFS (request-for-sponsorship) template that you can send to the debian-mentors mailing list to draw attention to your package. I believe that it should either suggest to request a CC or even better to point to the code of conduct: http://www.debian.org/MailingLists/#codeofconduct I suggest something like this: You will be shown an RFS (request-for-sponsorship) template that you can send to the debian-mentors mailing list to draw attention to your package. Please read the code of conduct (http://www.debian.org/MailingLists/#codeofconduct) for debian mailing-lists first. Note that you should request to be CC'ed if you are not subscribed to the list I think that's a great change. Could you file a bug (wishlist priority) with that information so it doesn't get lost in email land. I think the most appropriate pseudo package is www.debian.org, but I'm not sure *exactly* how mentors.d.n fits into the project so you might email supp...@mentors.debian.net first. Alternative prose might be: You will be shown a RFS (request for sponsorship) tempalte that you can send to the debian-mentors mailing list to draw attention to your package. You should request to be CC'd on replies, as CCing is not normally done per the Code of Conduct (http://www.debian.org/MailingLists/#codeofconduct) for Debian mailing lists. Alternatively, we might just modify the template to include the text: Please CC me on replies, as I am not subscribed to the list. and actual subscribers will clearly see the incorrect statement of fact and remove the line. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: Debian etch - Rebuilding a package from source.
On Thursday 01 January 2009, Chris Jones cjns1...@gmail.com wrote about 'Re: Debian etch - Rebuilding a package from source.': On Wed, Dec 31, 2008 at 11:16:46PM EST, Boyd Stephen Smith Jr. wrote: On Wednesday 2008 December 31 18:45:26 Chris Jones wrote: What I have done so far is pretty much what is described in the above: . apt-get source .. You might also look at apt-src. . build-dep .. . debuild .. . dpkg -i .. I go ahead and maintain a local apt repository (using apt-ftparchive) and then use aptitude to install, but dpkg -i is fine. I'll go ahead and disagree with the others, slightly. This is fine for packages you are only going to use yourself, or only install on a system with the same packages installed as your current system. _It_ _will_ _work_ and the packages that come out will be completely valid. However, making a pbuilder(cowbuilder) environment will make sure your packages build from source cleanly, and only depend on packages available from a specific flavor of debian (Etch/stable, Lenny/unstable, Sid/unstable). Yes, I also saw pbuilder/cowbuilder mentioned in several places. I also ran into dh-make and dpkg-buildpackage, and though I did not go into details in my initial post, the existence of such a variety of tools is the main reason I posted here. For me, debuild was easier than dpkg-buildpackage and I've never used dh-make. Heck, the first time I built a debian package from source I used make -f debian/rules binary because I hadn't read any documentation and was just poking around. pbuilder/cowbuilder are mainly a system for managing the chroots and use dpkg-buildpackage for building. pbuilder also comes with debuild-pbuilder that uses debuild for building instead of dpkg-buildpackage. debuild-pbuilder is my current tool of choice. It will also isolate the build process into a chroot, Sounds like a very useful feature but then since debian-live also builds its target in a chroot, I'm beginning to wonder whether it provides some way to integrate custom deb's that I have overlooked. That may be the case. I do not currently have any experience with debian-live, so I couldn't usefully comment. If packaging is just a means to an end, skip the pbuilder for now. However, if you want to make high-quality package that might be accepted into Debian, a pbuilder environment is a must. What would the tradeoff be? Is it a matter of a steeper learning curve? Does it require more resources such as disk-space? Yes, a bit steeper, mainly just because you'll be adding yet another tool to your toolbox. Yes, you'll need enough persistent disk-space for a base Debian system that will reside (possibly compressed) in /var/cache/pbuilder. During the build, the chroot will grow as it will be uncompressed, if compressed, and download and install all the Build-Depends and of course there is the build process itself. You'll need enough disk space for this processes, but after the build is complete most of this disk space will be reclaimed. What is not reclaimed is the downloaded package files which will be put into /var/cache/pbuilder/aptcache so that later pbuilder invocations will not have to re-download those packages. I currently have 3 2-month old pbuilder chroots (Etch/Lenny/Sid) and du -sh /var/cache/pbuilder reports 793M. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
