Re: Doubts in Sigar packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010-09-14 18:51, Thiago Franco de Moraes wrote: Hi all, Hi [...] * This library contains a bunch if bindings, one of them is java. These java bindings is compiled using ant. The compilations generates a bunch of .class and .jar files, and there isn't a make install. What is the best way to put those files in the right directories? To use the cp or mv command? And the right directories I think [4] is this /usr/share/java/libsigar-1.7 ? Personally I would recommend using jh_installlibs from javahelper. Thanks to all! PS. We need some help in translations [5] too. [1] - http://support.hyperic.com/display/SIGAR/Home [2] - http://svn.softwarepublico.gov.br/trac/invesalius [3] - http://github.com/hyperic/sigar [4] - http://www.debian.org/doc/packaging-manuals/java-policy/x104.html [5] - http://www.transifex.net/projects/p/invesalius/ By the way, you are very welcome to ask on debian-j...@l.d.o if you have questions on how to handle java related packaging. ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREIAAYFAkyQdZAACgkQVCqoiq1Ylqwh2wCeKVRA3ZdTeT23AXi1wl11WUpk gUMAn3+yvdJkhCzuxPcnEd1Fp95ctqtS =lyJQ -END PGP SIGNATURE- -- 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/4c907590.1030...@thykier.net
Advice on an interesting package
Hey everyone, I'm trying to sort out the packaging of barry-0.17-git snapshots and it's got some undesirable features which is making packaging a pain and I don't really know what the best way to deal with them is. It's got multiple binary packages from the same source package which I get form git. One of the binary packages is opensync-plugin-barry which deps on libopensync0-dev (= 0.22) to build. There is a new binary package called opensync-plugin-barry-4x which deps on libopensync1-dev (= 0.39) to build. The problem is both of these can't be installed at the same time. So the build can never build both of them. There are flags to turn one of them off, but we need to build both. The temporary solution has been that since the directory containing both of these bits of code is fairly separated, I've made a new debian directory and built a new source package just for opensync-plugin-barry-4x. But this kind of gives a bad directory structure: barry/ barry/debian/ barry/opensync-plugin-barry barry/opensync-plugin-barry-4x barry/opensync-plugin-barry-4x/debian Add to that the upstream has a tendency to merge in the debian changes into the trunk and I think he would like to merge in this directory too. I understand that upstream should avoid adding debian to their main code repository, is that right? Thanks for reading, and I hope you can help me with my questions. Best Regards, Martin Owens -- 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/1284536825.28250.20.ca...@delen
Re: reprepro signing.
On Tue, Sep 14, 2010 at 08:42:08PM -0700, Russ Allbery wrote: The conventional way to handle this is to build a Debian package that installs the keyring and runs apt-key add, based off of packages like debian-archive-keyring, and then have all clients install that package. Or drops the key into /etc/apt/trusted.gpg.d, which doesn't require additional handling. -- Jonathan Wiltshire 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: reprepro signing.
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Tue, Sep 14, 2010 at 08:42:08PM -0700, Russ Allbery wrote: The conventional way to handle this is to build a Debian package that installs the keyring and runs apt-key add, based off of packages like debian-archive-keyring, and then have all clients install that package. Or drops the key into /etc/apt/trusted.gpg.d, which doesn't require additional handling. Oh, hey. Look at that. Thanks! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k4mnjtvj@windlord.stanford.edu
Re: reprepro signing.
2010/9/15 Jonathan Wiltshire deb...@jwiltshire.org.uk: On Tue, Sep 14, 2010 at 08:42:08PM -0700, Russ Allbery wrote: The conventional way to handle this is to build a Debian package that installs the keyring and runs apt-key add, based off of packages like debian-archive-keyring, and then have all clients install that package. Or drops the key into /etc/apt/trusted.gpg.d, which doesn't require additional handling. But remember that you will need apt = 0.7.25.1 to use it and even apt = 0.8.0 (or some 0.7.26~exp) if you use it with cds. (i hate code copies…) So if all your clients are = squeeze everything will be fine, otherwise (e.g. lenny) you will need to use apt-key magic… For a bit more background, see #558784. Best regards David Kalnischkies -- 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/aanlktim9bs2gh=tozavrvz0iq1b8wxahte4x+d3nk...@mail.gmail.com
Re: Advice on an interesting package
Hi! Martin Owens docto...@gmail.com writes: Add to that the upstream has a tendency to merge in the debian changes into the trunk and I think he would like to merge in this directory too. I understand that upstream should avoid adding debian to their main code repository, is that right? Well upstreams are encouraged to not include the debian/ stuff in their release tarballs. It might be better to have debian/ in a separat branch but having it in upstream VCS isn't a problem right away. Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? pgp8eXQ3AGT67.pgp Description: PGP signature
Re: Advice on an interesting package
Martin Owens docto...@gmail.com writes: Hey everyone, I'm trying to sort out the packaging of barry-0.17-git snapshots and it's got some undesirable features which is making packaging a pain and I don't really know what the best way to deal with them is. It's got multiple binary packages from the same source package which I get form git. One of the binary packages is opensync-plugin-barry which deps on libopensync0-dev (= 0.22) to build. There is a new binary package called opensync-plugin-barry-4x which deps on libopensync1-dev (= 0.39) to build. The problem is both of these can't be installed at the same time. So the build can never build both of them. There are flags to turn one of them off, but we need to build both. The temporary solution has been that since the directory containing both of these bits of code is fairly separated, I've made a new debian directory and built a new source package just for opensync-plugin-barry-4x. But this kind of gives a bad directory structure: barry/ barry/debian/ barry/opensync-plugin-barry barry/opensync-plugin-barry-4x barry/opensync-plugin-barry-4x/debian Add to that the upstream has a tendency to merge in the debian changes into the trunk and I think he would like to merge in this directory too. I understand that upstream should avoid adding debian to their main code repository, is that right? Thanks for reading, and I hope you can help me with my questions. Best Regards, Martin Owens Do we need both? We have neither in Debian (testing/sid) it seems anyway. Usualy an libopensync1-dev means the libopensync0-dev has become obsolete and libopensync0 gets phased out as packages adapt to the new one. If both are needed then their packagin needs to change to allow both -dev packages to be installed in parallel. MfG Goswin -- 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/8762y7ibod@frosties.localdomain
Re: Advice on an interesting package
Christoph Egger christ...@debian.org writes: Hi! Martin Owens docto...@gmail.com writes: Add to that the upstream has a tendency to merge in the debian changes into the trunk and I think he would like to merge in this directory too. I understand that upstream should avoid adding debian to their main code repository, is that right? Well upstreams are encouraged to not include the debian/ stuff in their release tarballs. It might be better to have debian/ in a separat branch but having it in upstream VCS isn't a problem right away. Regards Christoph I disagree. I think it is perfectly fine for upstream to have a debian dir. Idealy the Debian maintainer should have write permissions to the upstream VCS and fix packaging problems directly there. What is a problem is when upstream has a broken debian dir or one that diverges too much from what debian has. But if upstream keeps the debian in sync and functional that works just fine. MfG Goswin -- 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/87tylrgr7o@frosties.localdomain
Re: Doubts in Sigar packaging
On Wed, 15 Sep 2010 08:21:29 +1000 Matthew Palmer mpal...@debian.org wrote: On Tue, Sep 14, 2010 at 01:51:22PM -0300, Thiago Franco de Moraes wrote: * The Source is in git [3]. I'm not using the last stable version because I wasn't able to compile it. What's the policy to version packages from git? I'm using this way: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d after git is the commit version I'm using. Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. What you need to do is select a monotonically increasing number to work from. I think the most common option is to just take the date of the last commit in the repo and use that, so something like sigar-1.7.0~git20100915. Assuming that you don't want to package two versions from the same day, that should work just fine. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` It can be done in one line with nested $() but I prefer shorter more readable lines. And you can get rid of the %H%M%S if you're not going to do it more than once a day. [1] I wanted to use bzr for this very reason, but SourceForge's version is very old and I couldn't push to it with the version in Debian unstable. -- 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/20100915133139.7a9d7...@toddler
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. Unlike homebrewed versioning schemes, this one can be understood by git without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as 0.8.0-a0, you'd want to make that 0.8.0~a0. This way, 0.8.0-a0-1247-gf38ef2b will become 0.8.0~a0-1247-gf38ef2b and final 0.8 -- just 0.8.0. I recommend against using dates to mark revisions, since there probably will be multiple commits in a single day, so there is no way to tell which exactly version you did package. Meow! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20100915131820.ga31...@angband.pl
Re: Doubts in Sigar packaging
On Wed, 15 Sep 2010 15:18:20 +0200 Adam Borowski kilob...@angband.pl wrote: On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) Thanks, that looks useful. Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as 0.8.0-a0, you'd want to make that 0.8.0~a0. This way, 0.8.0-a0-1247-gf38ef2b will become 0.8.0~a0-1247-gf38ef2b and final 0.8 -- just 0.8.0. Don't upstream version numbers have to be without hyphens so that Debian can easily distinguish the Debian revision from the upstream? Or is it OK, because it takes anything after the last hyphen to be the Debian revision? To make it absolutely clear that the release is newer than any pre-release snapshots I reserve *.0 version numbers for pre-release snapshots and use *.1 for release, so in your example I'd have 0.8.0* for snapshots and then 0.8.1 for release. Then I would use 0.8.1-* until releasing 0.8.2, then 0.9.0* for testing a major new feature to be released in 0.9.1. -- TH * http://www.realh.co.uk -- 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/20100915151222.470d8...@realh.co.uk
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:12:22PM +0100, Tony Houghton wrote: Adam Borowski kilob...@angband.pl wrote: Why won't you just use `git --describe`? [...] Depending on your upstream's versioning scheme you may want to stick a tilde somewhere. For example, if the upstream tagged a branch that is to-be 0.8 as 0.8.0-a0, you'd want to make that 0.8.0~a0. This way, 0.8.0-a0-1247-gf38ef2b will become 0.8.0~a0-1247-gf38ef2b and final 0.8 -- just 0.8.0. Don't upstream version numbers have to be without hyphens so that Debian can easily distinguish the Debian revision from the upstream? Or is it OK, because it takes anything after the last hyphen to be the Debian revision? The latter, Debian revision can not contain hyphens, but the upstream one is allowed to (Policy 5.6.12). To make it absolutely clear that the release is newer than any pre-release snapshots I reserve *.0 version numbers for pre-release snapshots and use *.1 for release, so in your example I'd have 0.8.0* for snapshots and then 0.8.1 for release. Then I would use 0.8.1-* until releasing 0.8.2, then 0.9.0* for testing a major new feature to be released in 0.9.1. Then it's a bit nicer for you -- you don't need to bother with tildes. Most upstreams use versions like 1.0pre23 followed by 1.0, which does not sort properly. The tilde is a hack to deal with such cases. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20100915143021.ga31...@angband.pl
Re: Advice on an interesting package
On Wed, 2010-09-15 at 11:44 +0200, Goswin von Brederlow wrote: Do we need both? We have neither in Debian (testing/sid) it seems anyway. Personally I'd say no, but this is for a ppa/unstable so it probably has different considerations. At the same time, this is a request from upstream. Ubuntu Lucid still has 0.22 and I've packaged my testing ppa with 0.39 to provide that. Usualy an libopensync1-dev means the libopensync0-dev has become obsolete and libopensync0 gets phased out as packages adapt to the new one. Yes, they don't install because they both claim libopensync.so, the newer unstable one probably shouldn't. All other files don't seem to overlap. If both are needed then their packagin needs to change to allow both -dev packages to be installed in parallel. Thoughts on how to do this? Thanks for your answers so far. Martin, -- 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/1284562571.28250.24.ca...@delen
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote:
[...]
I recommend against using dates to mark revisions, since there probably
will be multiple commits in a single day, so there is no way to tell
which exactly version you did package.
[...]
On one project where I'm upstream (not packaged for Debian
currently), I use seconds since the epoch from the last git commit
for a minor versioning component on tarballed development snapshots,
which at least reduces this problem down to multiple commits within
the same second rather than within the same day. On my project,
there's not enough churn to make this a relevant concern for now, I
don't care about human readability, and it's only an extra two
digits more than you need for an ISO 8601 date.
One related concern for some projects, however, is whether releasing
from different, out-of-sync VCS branches could make timestamp-only
version numbers appear to skip backwards under such a scheme. Making
sure your major version numbers are human-assigned is an important
component, obviously. ;)
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
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/20100915165858.ga2...@yuggoth.org
Re: Advice on an interesting package
Martin Owens docto...@gmail.com writes: On Wed, 2010-09-15 at 11:44 +0200, Goswin von Brederlow wrote: Do we need both? We have neither in Debian (testing/sid) it seems anyway. Personally I'd say no, but this is for a ppa/unstable so it probably has different considerations. At the same time, this is a request from upstream. Ubuntu Lucid still has 0.22 and I've packaged my testing ppa with 0.39 to provide that. Usualy an libopensync1-dev means the libopensync0-dev has become obsolete and libopensync0 gets phased out as packages adapt to the new one. Yes, they don't install because they both claim libopensync.so, the newer unstable one probably shouldn't. All other files don't seem to overlap. If both are needed then their packagin needs to change to allow both -dev packages to be installed in parallel. Thoughts on how to do this? Thanks for your answers so far. Martin, I'm afraid not, other than have libopensync1 change the library name so it has libopensync1.so or something. MfG Goswin -- 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/87zkvierx4@frosties.localdomain
Re: Advice on an interesting package
Goswin von Brederlow goswin-...@web.de writes: Christoph Egger christ...@debian.org writes: Well upstreams are encouraged to not include the debian/ stuff in their release tarballs. It might be better to have debian/ in a separat branch but having it in upstream VCS isn't a problem right away. I disagree. I think it is perfectly fine for upstream to have a debian dir. Idealy the Debian maintainer should have write permissions to the upstream VCS and fix packaging problems directly there. What is a problem is when upstream has a broken debian dir or one that diverges too much from what debian has. But if upstream keeps the debian in sync and functional that works just fine. This is very difficult to do. Speaking as an upstream who is also a Debian Developer, even I don't include the debian directory in upstream releases. I tried that model for a while and found all sorts of serious problems with it, such as needing to do a new release whenever anything changes about the debian directory in order to bring things back into sync. One ends up with divergent content for the debian directory anyway and the debian directory included with the upstream release is often not useful. And this is all to very little benefit for the end user, who can as easily run apt-get source if they want to build the Debian package somewhere else as use the debian directory in the upstream release. So while this sounds like an okay idea, in practice it doesn't work. So I agree with Christoph. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ocbyu1as@windlord.stanford.edu
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. You cannot use hashes in your version strings, because you can't assume that the later version is going to sort after the earlier version. If tag-commitcount isn't sufficiently unique, you're stuffed. Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~tagname as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. Unlike homebrewed versioning schemes, this one can be understood by git without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. For Debian packaging, this is irrelevant. I recommend against using dates to mark revisions, since there probably will be multiple commits in a single day, so there is no way to tell which exactly version you did package. If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. - Matt -- 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/20100916052231.ge...@hezmatt.org
