On Mon, 2007-01-22 at 19:51 -0500, Roberto C. Sanchez wrote:
I disagree. How do I know that r91 was committed two days ago?
This also does not hold for regular, released versions. I don't see why
this should be conveyed in the version number of snapshot packages and
not for regular releases:
В Tue, 23 Jan 2007 18:29:33 +1100, Andrew Donnellan написа:
Could someone who has a ppc system try this version?
It still fails to build:
../voip/stun.cpp:681:7: error: #error Need some way to seed the random number
generator
../voip/stun.cpp:722: warning: unused parameter 'input'
On 1/23/07, Yavor Doganov [EMAIL PROTECTED] wrote:
В Tue, 23 Jan 2007 18:29:33 +1100, Andrew Donnellan написа:
Could someone who has a ppc system try this version?
It still fails to build:
../voip/stun.cpp:681:7: error: #error Need some way to seed the random
number generator
On Tue, 2007-01-23 at 19:46 +1100, Andrew Donnellan wrote:
I'll have a look at the patches that were suggested earlier - I may
apply them upstream as I have access to their repo.
I'm also going to prepare a new version very soon.
Just to let you know - your package looks very good otherwise.
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote:
Why bother with the date? 2.1~svn-r91 seems much more concise and
has the same information, really.
Though you're right that the information is the same, a date is
meaningful in spite of the knowledge of the revision control
On 1/23/07, Thijs Kinkhorst [EMAIL PROTECTED] wrote:
Just to let you know - your package looks very good otherwise.
Thanks :)
I'm going to apply the patch provided by Francesco Pedrini at [0], as
a Debian specific patch until it can be sorted out upstream.
[0]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -=| Andrew Donnellan, 23.01.2007 10:46 |=-
I'll have a look at the patches that were suggested earlier - I may
apply them upstream as I have access to their repo.
I'm also going to prepare a new version very soon.
While there, could you
On 1/23/07, Damyan Ivanov [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -=| Andrew Donnellan, 23.01.2007 10:46 |=-
I'll have a look at the patches that were suggested earlier - I may
apply them upstream as I have access to their repo.
I'm also going to prepare a
On Tue, 23 Jan 2007 09:56:28 +0100
Stefano Zacchiroli [EMAIL PROTECTED] wrote:
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote:
Why bother with the date? 2.1~svn-r91 seems much more concise and
has the same information, really.
Though you're right that the information is
On Tue, 2007-01-23 at 09:56 +0100, Stefano Zacchiroli wrote:
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote:
Why bother with the date? 2.1~svn-r91 seems much more concise and
has the same information, really.
Though you're right that the information is the same, a date is
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
--
Andrew Donnellan
ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)
http://andrewdonnellan.com http://ajdlinux.wordpress.com
[EMAIL
On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote:
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
I think this is a good rule:
If the source is published outside of Debian,
do not make a
On 1/23/07, Thijs Kinkhorst [EMAIL PROTECTED] wrote:
On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote:
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
I think this is a good rule:
If the source is
On Tue, Jan 23, 2007 at 09:17:37AM +0100, Thijs Kinkhorst wrote:
On Mon, 2007-01-22 at 19:51 -0500, Roberto C. Sanchez wrote:
I disagree. How do I know that r91 was committed two days ago?
This also does not hold for regular, released versions. I don't see why
this should be conveyed in
On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote:
As commented elsewhere, normal release numbers do not have any date
component and you've still got the problem that multiple svn commits
are frequently made on the same day. The date, in this context, is just
misleading and would
On Tue, 2007-01-23 at 21:45 +1100, Andrew Donnellan wrote:
In this particular project I am a member of upstream (packager,
proofreader and copywriter for English website) and I want to store my
debian/ directory in upstream's SVN as it makes it much easier for me
to manage snapshots, updates,
On Tue, 23 Jan 2007 21:45:44 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
In this particular project I am a member of upstream (packager,
proofreader and copywriter for English website) and I want to store my
debian/ directory in upstream's SVN as it makes it much easier for me
to manage
On 1/23/07, Thijs Kinkhorst [EMAIL PROTECTED] wrote:
On Tue, 2007-01-23 at 21:45 +1100, Andrew Donnellan wrote:
In this particular project I am a member of upstream (packager,
proofreader and copywriter for English website) and I want to store my
debian/ directory in upstream's SVN as it
On Tue, Jan 23, 2007 at 10:02:05PM +1100, Andrew Donnellan wrote:
So essentially, store debian/ etc in the upstream VCS, but keep it out
of releases and only add the directory when building a Debian package?
Does this mean I should create a snapshot of everything except the
debian files,
Hi Thijs,
thank you very much for your help, with your hints I could resolve most
of these issues:
The changelog says: * Initial release (Closes: #) is the bug
number of your ITP So you probably forgot to replace '' :) See
also the file README.Debian, it still has possible
On 1/23/07, Neil Williams [EMAIL PROTECTED] wrote:
On Tue, 23 Jan 2007 21:45:44 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
In this particular project I am a member of upstream (packager,
proofreader and copywriter for English website) and I want to store my
debian/ directory in
On Tue, 2007-01-23 at 11:52 +0100, Andreas Moll wrote:
I don't think the 'deb-ball-source' dir belongs in a clean source
package.
I guess you are right. Could you tell how to delete it with the
deb-helper tools?
What created that dir originally?
Thijs
signature.asc
Description: This
Dear Charles,
think you for your help:
There is still some polishing work to be done before somebody can
sponsor, however. Thijs has already pointed at some problems, and I
found a few others:
* Your README.Debian does not contain any information. You can safely
delete it if you have
On Tue, 23 Jan 2007 22:02:05 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
So essentially, store debian/ etc in the upstream VCS, but keep it out
of releases and only add the directory when building a Debian package?
Does this mean I should create a snapshot of everything except the
debian
On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote:
As commented elsewhere, normal release numbers do not have any date
component and you've still got the problem that multiple svn commits
are frequently made on the same day. The date, in this context, is just
misleading and would
On Tue, Jan 23, 2007 at 09:01:52PM +1100, Robert Collins wrote:
Also, in the (rare but can occur) event of a svn rollback, r91 is not
necessarily accurate after the fact,whereas a datestamp is.
Uh? Is rollback (in the sense of undoing a commit) possible with SVN
without manually fiddling in the
On Tue, 23 Jan 2007 22:09:28 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Keep the debian/* files in CVS/SVN.
Don't package the debian/* files in the distributed tarball.
When building the packages, you simply download the released tarball as
usual, copy your debian/* files into
On Tue, Jan 23, 2007 at 12:34:08PM +0100, Stefano Zacchiroli wrote:
On Tue, Jan 23, 2007 at 09:01:52PM +1100, Robert Collins wrote:
Also, in the (rare but can occur) event of a svn rollback, r91 is not
necessarily accurate after the fact,whereas a datestamp is.
Uh? Is rollback (in the
also sprach Marc Haber [EMAIL PROTECTED] [2007.01.23.1137 +]:
Uh? Is rollback (in the sense of undoing a commit) possible with SVN
without manually fiddling in the repository at all?
Sure, svn merge.
?
svn merge is like applying a patch and will require a commit, which
will increase
On Tue, Jan 23, 2007 at 12:37:14PM +0100, Marc Haber wrote:
On Tue, Jan 23, 2007 at 12:34:08PM +0100, Stefano Zacchiroli wrote:
On Tue, Jan 23, 2007 at 09:01:52PM +1100, Robert Collins wrote:
Also, in the (rare but can occur) event of a svn rollback, r91 is not
necessarily accurate after
On Tue, 23 Jan 2007 12:31:39 +0100
Stefano Zacchiroli [EMAIL PROTECTED] wrote:
On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote:
As commented elsewhere, normal release numbers do not have any date
component and you've still got the problem that multiple svn commits
are
On Tue, 2007-01-23 at 12:34 +0100, Stefano Zacchiroli wrote:
On Tue, Jan 23, 2007 at 09:01:52PM +1100, Robert Collins wrote:
Also, in the (rare but can occur) event of a svn rollback, r91 is not
necessarily accurate after the fact,whereas a datestamp is.
Uh? Is rollback (in the sense of
On Tue, Jan 23, 2007 at 12:40:21PM +, Neil Williams wrote:
Not true. You cannot reliably ensure that a commit at 11:50:00 -0500 is
actually part of your daily snapshot without specifying your timezone
in the snapshot date, i.e. creating a full UTC timestamp in the version
string. Many
On Wed, Jan 24, 2007 at 12:05:02AM +1100, Robert Collins wrote:
On Tue, 2007-01-23 at 12:34 +0100, Stefano Zacchiroli wrote:
Uh? Is rollback (in the sense of undoing a commit) possible with SVN
without manually fiddling in the repository at all?
If this is *not* the case and you're
Hi,
That is because you have packaged it as a native package, probably by
accident. Make sure that the upstream tarball is correctly named and in
the right place: it should be ballview_1.2.orig.tar.gz. The 'debuild'
command warns if this is not right. Please rebuild it as a non-native
package.
I don't think the 'deb-ball-source' dir belongs in a clean source
package.
I guess you are right. Could you tell how to delete it with the
deb-helper tools?
What created that dir originally?
It is a part of my upstream package, where it can be used to directly
create a binary package from
On Tue, 23 Jan 2007 14:19:24 +0100
Andreas Moll [EMAIL PROTECTED] wrote:
Hi,
That is because you have packaged it as a native package, probably by
accident. Make sure that the upstream tarball is correctly named and in
the right place: it should be ballview_1.2.orig.tar.gz. The 'debuild'
On Tue, 23 Jan 2007 08:28:10 -0500
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
The svn 'r' system is specifically designed to cope with this
inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and
inaccurate 'date' strings. Using a full UTC timestamp is even worse -
far too
also sprach Robert Collins [EMAIL PROTECTED] [2007.01.23.1305 +]:
Other VCS's however, allow rollbacks to occur much more easily ;).
Which is a design deficiency IMHO. But let's not go there. I believe
that discussion has been beaten to death.
--
Please do not send copies of list mail to
Le Tue, Jan 23, 2007 at 11:58:56AM +0100, Andreas Moll a écrit :
* Your package does not build on iMac G5. Even on the 32-bit ppc port,
G5 machines use a ppc64 kernel. Apparently, this confuses your
configuration scripts. For the moment, the Debian buildds for powerpc
are G4s, but
On Tue, Jan 23, 2007 at 01:59:32PM +, Neil Williams wrote:
On Tue, 23 Jan 2007 08:28:10 -0500
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
Right. However, I think we are rapidly approaching overkill in this
discussion. How about this:
* the version string includes the date
I
I suggest we settle this discussion, having clarified the sorting
rules and possibilities, and voiced our preferences. In the end, the
maintainer should do what s/he wants and be prepared to handle the
consequences. As long as there are no epochs needed, it likely won't
matter at all.
--
Please
Andrew Donnellan [EMAIL PROTECTED] wrote:
So for a snapshot of revision 91 between stable version 2.0 and future
version 2.1, would something like:
2.1~20070123svn.r91
be OK?
Ah, so now that we have this '~' allowed by dpkg, we have to use it
everywhere?
You cannot predict the future.
On Tue, 23 Jan 2007 18:08:00 +0100, Florent Rougon [EMAIL PROTECTED] said:
Andrew Donnellan [EMAIL PROTECTED] wrote:
So for a snapshot of revision 91 between stable version 2.0 and
future version 2.1, would something like: 2.1~20070123svn.r91
Ah, so now that we have this '~' allowed by
Dear mentors,
I am looking for a sponsor for my package crotch.
* Package name: crotch
Version : 1.0.1-1
Upstream Author : Chris Amthor [EMAIL PROTECTED]
* URL : http://www.chroam.de/
* License : GPL
Section : games
It builds these binary packages:
Neil Williams [EMAIL PROTECTED] writes:
On Tue, 23 Jan 2007 08:28:10 -0500
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
The svn 'r' system is specifically designed to cope with this
inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and
inaccurate 'date' strings. Using a full
On Tuesday 23 January 2007 12:37, Thijs Kinkhorst wrote:
On Tue, 2007-01-23 at 21:34 +1100, Andrew Donnellan wrote:
What exactly are the advantages and disadvantages of making a
Debian-native package, and is there any real policy or practice?
Hello,
I think this is a good rule:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2007.01.23.1738 +]:
You cannot predict the future. It might me that next version is not
2.1 as you expected, but, e.g., 3.0. Why not base your version
number on things you *know* for sure: that the last released version
was 2.0?
Hi Chris!
On 1/23/07, Chris Amthor [EMAIL PROTECTED] wrote:
I am looking for a sponsor for my package crotch.
If you look up the definition of crotch
(http://dict.die.net/crotch/), you come up with the fact that is not a
nice word, and it can be considered offensive by a group of people.
On Tue, 23 Jan 2007 16:22:59 -0300
Margarita Manterola [EMAIL PROTECTED] wrote:
Hi Chris!
On 1/23/07, Chris Amthor [EMAIL PROTECTED] wrote:
I am looking for a sponsor for my package crotch.
If you look up the definition of crotch
(http://dict.die.net/crotch/), you come up with the fact
On 1/23/07, George Danchev [EMAIL PROTECTED] wrote:
Right. Another disadvantage of making it a native package is that the
orig.tar.gz (imagine monsters here, ... OpenOffice.org comes to mind ;-) has
to be uploaded every time you change something in the package, even if this
is a change specific
Dear mentors,
I am looking for a sponsor for my package super-smack.
* Package name: super-smack
Version : 1.3-1
Upstream Author : Tony Bourke [EMAIL PROTECTED]
* URL : http://vegan.net/tony/supersmack
* License : GPL
Section : utils
It builds
On Tue, Jan 23, 2007 at 06:42:13PM +0100, Chris Amthor wrote:
Dear mentors,
I am looking for a sponsor for my package crotch.
* Package name: crotch
Version : 1.0.1-1
Upstream Author : Chris Amthor [EMAIL PROTECTED]
* URL : http://www.chroam.de/
* License
Manoj Srivastava [EMAIL PROTECTED] wrote:
Ah, so now that we have this '~' allowed by dpkg, we have to use it
everywhere?
No, but we should use it in situations for which is was
specifically designed for, no?
Precisely. And it was *not* designed for CVS/SVN/whatever RCS snapshots.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Plessy wrote:
I was kindly pointed out on -devel that the Debian menu system can
handle translations in its files.
No, it cannot. Not only that, but there also is no clear idea on HOW and
WHAT exactly it should do. There are simply way too
On 1/24/07, martin f krafft [EMAIL PROTECTED] wrote:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2007.01.23.1738 +]:
You cannot predict the future. It might me that next version is not
2.1 as you expected, but, e.g., 3.0. Why not base your version
number on things you *know* for
On 1/23/07, Neil Williams [EMAIL PROTECTED] wrote:
On Tue, 23 Jan 2007 22:09:28 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Keep the debian/* files in CVS/SVN.
Don't package the debian/* files in the distributed tarball.
When building the packages, you simply download the released
Upstream's response to #361376 is to recommend the dropping of
liferea-gtkhtml from 64bit arches. How does one go about that?
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
Zenophobia: the irrational fear of convergent sequences.
signature.asc
On Tue, 23 Jan 2007 16:36:20 -0600
Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote:
Upstream's response to #361376 is to recommend the dropping of
liferea-gtkhtml from 64bit arches. How does one go about that?
My reading of the bug report is that one component of the package is
not going to
On Wed, 24 Jan 2007 08:45:50 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Hmm. Can't you use 'make dist' to create a tarball that is at least
close to what will actually be released? 'make dist' will not include
debian/ UNLESS you have made the mistake of putting debian/ in
EXTRA_DIST
On Tue, Jan 23, 2007 at 04:36:20PM -0600, Luis Rodrigo Gallardo Cruz wrote:
Upstream's response to #361376 is to recommend the dropping of
liferea-gtkhtml from 64bit arches. How does one go about that?
Change the Architecture: field for liferea-gtkhtml in debian/control to list
the 32-bit
On 1/24/07, Neil Williams [EMAIL PROTECTED] wrote:
On Wed, 24 Jan 2007 08:45:50 +1100
Andrew Donnellan [EMAIL PROTECTED] wrote:
Hmm. Can't you use 'make dist' to create a tarball that is at least
close to what will actually be released? 'make dist' will not include
debian/ UNLESS you have
Florent Rougon [EMAIL PROTECTED] writes:
Sorry, not at all. Besides what Martin explained, using 2.1 in your
version number without knowing for sure that 2.1 is going to be the next
release is ugly, even if it were harmless (which is not the case).
Better use something you do know: if this
Andrew Donnellan [EMAIL PROTECTED] writes:
So essentially, store debian/ etc in the upstream VCS, but keep it out
of releases and only add the directory when building a Debian package?
Does this mean I should create a snapshot of everything except the
debian files, then copy the debian files
[Summary for -release: Is removing liferea-gtkhtml too disruptive for etch?]
On Tue, Jan 23, 2007 at 03:04:29PM -0800, Steve Langasek wrote:
On Tue, Jan 23, 2007 at 04:36:20PM -0600, Luis Rodrigo Gallardo Cruz wrote:
Upstream's response to #361376 is to recommend the dropping of
Hi Luis,
On Tue, Jan 23, 2007 at 06:15:15PM -0600, Luis Rodrigo Gallardo Cruz wrote:
Yes, Lars has stated his intention to completely remove this rendering
engine.
To do so, I'd assume the right way to go would be to turn -gtkhtml
into a dummy package that pulls -xulrunner in.
In that
66 matches
Mail list logo
