Damyan Ivanov wrote:
-=| Charlie, 17.07.2007 00:04 |=-
Ondrej Certik wrote:
uploads it to the NEW queue with a version 0.6.0-1, but it
waits
there
for a month, but I need updates of my package now, so I create
versions 0.6.0-1oc1, 0.6.0-1oc2, ..., and when the package hits
unstable, I
Ondrej, Charlie,
You can also ask for sponsor for -2, even while -1 is in NEW. This won't
disturb the package for sure. The first version in unstable would
simply be -2. For example, see console-setup having two versions in NEW[1].
[1] http://ftp-master.debian.org/new.html
This feature is
-=| Charlie, 17.07.2007 09:45 |=-
I have a problem that I'm not sure
how to fix. The package I have in NEW is 3.3.3.2-1 I had to remove
some window support files (.dll and .exe) from the orig.tar.gz and
reading through the debian manuals I noticed that the package should
have been
On Sun, Jul 15, 2007 at 03:02:55PM +0200, martin f krafft
wrote:
also sprach Bart Martens [EMAIL PROTECTED]
[2007.07.15.1241 +0200]:
When the .orig.tar.gz needs repackaging, then this
happens:
1.0~rfs.2-1~rfs.1 1.0~rfs.3-1~rfs.1
This should not need to happen. The orig.tar.gz
I have not read this thread, only the initial message. So sorry if what
I propose has already been said.
If you want different debian revisions per mentor upload, I think the
most reasonable think to do so is to have the mentoree upload:
package_1.2.3-4~sp1 (sp == sponsor)
On Sun, Jul 15, 2007 at 09:37:39PM +0200, Christoph Haas [EMAIL PROTECTED]
wrote:
As I outlined in the mentors.debian.net thread I'm a great fan of not
having different uploads with the same revision number. So I'd even like
to enforce that uploads to mentors.debian.net with the same revision
also sprach Neil Williams [EMAIL PROTECTED] [2007.07.15.1819 +0200]:
Martin - my only problem with this collapsing of the changes is that
debian/changelog would need to be edited by the sponsor to achieve this
without causing yet another rebuild and upload to mentors.d.n cycle.
This, I don't
On Mon, 16 Jul 2007 19:28:09 +0200
martin f krafft [EMAIL PROTECTED] wrote:
Anyway, we're not here to agree on one procedure, are we — because
we likely never will.
True. :-)
You gave your new policies and I added my 2¢
in the form of showing you how I do things. Or would like to do
them.
There is also another point that I think wasn't yet mentioned - I, as
a non DD, create packages mainly because I myself want them, because
it is very comfortable. However, with a new package, it takes usually
a month or two, until it hits the unstable (many days to find a
sponsor and fix all
Ondrej Certik wrote:
There is also another point that
I think wasn't yet mentioned - I, as
a non DD, create packages mainly because I myself want them,
because
it is very comfortable. However, with a new package, it takes
usually
a month or two, until it hits the unstable (many days to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -=| Charlie, 17.07.2007 00:04 |=-
Ondrej Certik wrote:
uploads it to the NEW queue with a version 0.6.0-1, but it waits there
for a month, but I need updates of my package now, so I create
versions 0.6.0-1oc1, 0.6.0-1oc2, ..., and when the
I think it is about time that I changed the way I handle one element of
my sponsoring: I think that trying to retain the same Debian version
during the entire sponsorship process is prone to error and teaches bad
habits. In future, I think it is easier for everyone if every change
during
also sprach Neil Williams [EMAIL PROTECTED] [2007.07.15.1133 +0200]:
I think it is about time that I changed the way I handle one element of
my sponsoring: I think that trying to retain the same Debian version
during the entire sponsorship process is prone to error and teaches bad
habits. In
On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote:
I think it is easier for everyone if every change
during sponsorship gets a new Debian version, so if you need me to
sponsor packages, each upload to mentors.debian.net must use a new
Debian version.
That makes debian/changelog written
On Sun, 2007-07-15 at 11:45 +0200, martin f krafft wrote:
I make use of
the new ~ character in version strings. Even more my own packages,
I'll release
1.0-1~unreleased.1
1.0-1~unreleased.2
1.0-1~unreleased.3
until it's final and I can release 1.0-1, for which I merge the
On Sun, 15 Jul 2007 12:23:48 +0200
Bart Martens [EMAIL PROTECTED] wrote:
On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote:
I think it is easier for everyone if every change
during sponsorship gets a new Debian version, so if you need me to
sponsor packages, each upload to
Hi,
On Sunday 15 July 2007, Bart Martens wrote:
Or is this over the top? Maybe it needlessly complicates things for
newbie packagers...
Non-DD's are also welcome to comment !
a good approach in my opinion, it's:
1.0-1~rfs.1
1.0-1~rfs.2
1.0-1 version and revision for
On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote:
On Sun, 15 Jul 2007 12:23:48 +0200
Bart Martens [EMAIL PROTECTED] wrote:
On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote:
I think it is easier for everyone if every change
during sponsorship gets a new Debian version, so if
Hi,
IMHO it's a good idea to follow the requirements of ftp-master, it's a
good practice that get used the new devoloppers to made the things in
the right way, I understand the issues of this in the changelogs, but I
think it's funny to see after many years the mistakes made attempting to
made my
Bart Martens wrote:
On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote:
On Sun, 15 Jul 2007 12:23:48 +0200
Bart Martens [EMAIL PROTECTED] wrote:
On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote:
I think it is easier for everyone if every change
during sponsorship
Bart Martens wrote:
It's not a huge problem, but it's not so nice to have all beginners
mistakes logged forever for the whole world to see.
Speaking as someone in NM, that is an important point.
I don't use mentors for my uploads, I either use my own web space or a
system put in place by my
On Sunday 15 July 2007, Bart Martens wrote:
On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote:
--cut--
Something like this ?
packagename (0.1.0-8) unstable; urgency=low
* Updated debian/watch to recognize both .tar.gz and .tar.bz2,
now revealing the real latest upstream release.
also sprach Bart Martens [EMAIL PROTECTED] [2007.07.15.1241 +0200]:
When the .orig.tar.gz needs repackaging, then this happens:
1.0~rfs.2-1~rfs.1
1.0~rfs.3-1~rfs.1
This should not need to happen. The orig.tar.gz should hardly ever
be repacked.
--
Please do not send copies of list
also sprach Colin Tuckley [EMAIL PROTECTED] [2007.07.15.1501 +0200]:
1) I don't want my failed attempts seen forever.
2) it's a lot of unneeded and irrelevant information. (it's about the
packaging *attempt* not about the packaging).
You may have missed my point about merging the
martin f krafft wrote:
You may have missed my point about merging the changelog entries
when preparing the final version. Until then, having changelog
entries for mentee changes is rather helpful to the sponsor,
I think.
No, I saw it and assumed that is what would happen in the case where
On Sun, 2007-07-15 at 16:47 +0300, George Danchev wrote:
On Sunday 15 July 2007, Bart Martens wrote:
On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote:
--cut--
Something like this ?
packagename (0.1.0-8) unstable; urgency=low
* Updated debian/watch to recognize both .tar.gz
also sprach Colin Tuckley [EMAIL PROTECTED] [2007.07.15.1618 +0200]:
No, I saw it and assumed that is what would happen in the case
where the uploads use ~r1 etc and the final upload to Debian by
the sponsor deleted the extra part of the revision.
It's having all the changelog entries for
On Sunday 15 July 2007, martin f krafft wrote:
also sprach Colin Tuckley [EMAIL PROTECTED] [2007.07.15.1618 +0200]:
No, I saw it and assumed that is what would happen in the case
where the uploads use ~r1 etc and the final upload to Debian by
the sponsor deleted the extra part of the
Yes, exactly. Each packaging attempt gets a separate changelog entry
and when it's final, you merge them all, effectively erasing the
history.
If I understand you correctly you mean a progress as follows:
=== Day 1 ===
Day 1 is probably a bit confusing here. A new revision every
On Sun, 15 Jul 2007 18:32:23 +0300
On Sunday 15 July 2007, martin f krafft wrote:
Yes, exactly. Each packaging attempt gets a separate changelog entry
and when it's final, you merge them all, effectively erasing the
history.
Martin - my only problem with this collapsing of the changes is
On Sun, Jul 15, 2007 at 12:23:48PM +0200, Bart Martens wrote:
On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote:
I think it is easier for everyone if every change
during sponsorship gets a new Debian version, so if you need me to
sponsor packages, each upload to mentors.debian.net must
On Sun, Jul 15, 2007 at 12:41:16PM +0200, Bart Martens wrote:
On Sun, 2007-07-15 at 11:45 +0200, martin f krafft wrote:
I make use of
the new ~ character in version strings. Even more my own packages,
I'll release
1.0-1~unreleased.1
1.0-1~unreleased.2
1.0-1~unreleased.3
32 matches
Mail list logo
