Quoting Daniel Baumann (daniel.baum...@progress-technologies.net):
On 08/01/2012 12:29 AM, Philipp Kern wrote:
I don't think that's agreed upon. If anything default options
should be used.
i don't think so, see debconf bofh.
the bottom line is that -9 compresses better than -6, and that
On Wed, Aug 1, 2012 at 04:53:58 +0200, Daniel Baumann wrote:
..please do share your knowledge of the proper way then and help
making debian better (bug report plus patch would be appreciated).
See the --retry option to start-stop-daemon(8).
Cheers,
Julien
signature.asc
Description:
Daniel,
if the git commits don't give any more detail/explanation than the
changelog, then they still don't help. You know changelog entries and
git commit messages can be more than just one line...
On Tue, Jul 31, 2012 at 03:30:10 +0200, Daniel Baumann wrote:
From
[ CCing da-manager@ to make sure they know that you still fail in
maintaining your packages properly ]
Hi,
so yet again you managed to make a mess of open-vm-tools short time
before a release. open-vm-tools is essential for a lot of people,
running thousands of machines running Debian in a
On 07/31/2012 11:07 AM, Bernd Zeimetz wrote:
so yet again you managed to make a mess of open-vm-tools short time
before a release.
i didn't. please read the whole thread carefully, thank you.
+ * Switching to xz compression.
Why?
smaller package size.
Is this really release critical?
On 07/31/2012 02:34 PM, Daniel Baumann wrote:
On 07/31/2012 11:07 AM, Bernd Zeimetz wrote:
so yet again you managed to make a mess of open-vm-tools short time
before a release.
i didn't. please read the whole thread carefully, thank you.
Yes you did, as several people tried to explain to
On 07/31/2012 10:59 AM, Julien Cristau wrote:
This still doesn't explain why the change is necessary, and what was
wrong with the old code. And if it is, which I would be willing to
believe if given some sort of explanation, it seems to be missing a
package dependency on kmod.
for the 'why'
On Tue, Jul 31, 2012 at 14:34:11 +0200, Daniel Baumann wrote:
+ * Adding sleep during restart in initscript.
Why one second?
because it sometimes fails to restart if there's no sleep.
Is it enough?
yes.
Based on what? If the system is under load, what guarantees that it
won't
On Tue, Jul 31, 2012 at 14:34:11 +0200, Daniel Baumann wrote:
+ * Switching to xz compression.
Why?
smaller package size.
Which is particularly important for this package because...? And using
the -9 option (which is recommended against by the xz documentation)
because...?
Cheers,
On 07/31/2012 03:40 PM, Julien Cristau wrote:
Based on what?
tests on my computer.
If the system is under load, what guarantees that it won't take
more time?
as often there are no guarantees, but i tested it under quite some cpu
and IO load, and it worked for me.
regarding testing
On 07/31/2012 03:41 PM, Julien Cristau wrote:
Which is particularly important for this package because...? And using
the -9 option (which is recommended against by the xz documentation)
because...?
i'm definitely not going to re-iterate what all the people said about
using xz compression,
On Tue, Jul 31, 2012 at 03:47:42PM +0200, Daniel Baumann wrote:
On 07/31/2012 03:41 PM, Julien Cristau wrote:
Which is particularly important for this package because...? And using
the -9 option (which is recommended against by the xz documentation)
because...?
i'm definitely not going to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/31/2012 03:45 PM, Daniel Baumann wrote:
On 07/31/2012 03:40 PM, Julien Cristau wrote:
Based on what?
tests on my computer.
As it was already explained to you before the release of Squeeze, this is far
far far away from proper testing for
On 08/01/2012 12:29 AM, Philipp Kern wrote:
I don't think that's agreed upon. If anything default options
should be used.
i don't think so, see debconf bofh.
the bottom line is that -9 compresses better than -6, and that -9 is
not a problem on amd64 and i386, see debconf talk for more
On 08/01/2012 01:42 AM, Bernd Zeimetz wrote:
tests on my computer.
As it was already explained to you before the release of Squeeze, this is far
far far away from proper testing for a package like open-vm-tools. It should
be tested on current (and maybe even older) ESX instalations.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
2:8.8.0+2012.05.21-724730-2 would have migrated in time,
2:8.8.0+2012.05.21-724730-3 fixes the FTBFS of the dkms module.
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
On Mon, Jul 30, 2012 at 18:12:28 +0200, Daniel Baumann wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
2:8.8.0+2012.05.21-724730-2 would have migrated in time,
2:8.8.0+2012.05.21-724730-3 fixes the FTBFS of the dkms
On 07/30/2012 08:08 PM, Julien Cristau wrote:
2:8.8.0+2012.05.21-724730-2 would have migrated in time,
2:8.8.0+2012.05.21-724730-3 fixes the FTBFS of the dkms module.
See the existing requests for clarification of the changes.
i don't understand what you're talking about. let me repeat:
On Mon, Jul 30, 2012 at 21:15:37 +0200, Daniel Baumann wrote:
On 07/30/2012 08:08 PM, Julien Cristau wrote:
2:8.8.0+2012.05.21-724730-2 would have migrated in time,
2:8.8.0+2012.05.21-724730-3 fixes the FTBFS of the dkms module.
See the existing requests for clarification of the
On 07/30/2012 09:18 PM, Julien Cristau wrote:
I don't care that 2:8.8.0+2012.05.21-724730-2 would have
migrated, since it didn't. I'm looking at the diff between
testing and sid.
ok, good to know.
so the rational is then, contra common sense, to not fix RC bugs in
sid before a package has
On Mon, Jul 30, 2012 at 21:25:03 +0200, Daniel Baumann wrote:
On 07/30/2012 09:18 PM, Julien Cristau wrote:
I don't care that 2:8.8.0+2012.05.21-724730-2 would have
migrated, since it didn't. I'm looking at the diff between
testing and sid.
ok, good to know.
so the rational is
On 07/30/2012 09:27 PM, Julien Cristau wrote:
No, the idea is to not make unnecessary changes the day before the
freeze.
there is no unnecessary change in 2:8.8.0+2012.05.21-724730-2.
apart from that: if you don't want people to upload stuff right before
the freeze, then don't announce the
On Mon, Jul 30, 2012 at 21:44:05 +0200, Daniel Baumann wrote:
On 07/30/2012 09:27 PM, Julien Cristau wrote:
No, the idea is to not make unnecessary changes the day before the
freeze.
there is no unnecessary change in 2:8.8.0+2012.05.21-724730-2.
Great, then explaining the changes
On 07/30/2012 09:47 PM, Julien Cristau wrote:
Great, then explaining the changes should be straightforward.
as i've read, other people on debian-release@lists.debian.org did that
already to the full extend.
I don't mind people uploading stuff right before the freeze as long
as they don't mind
On Mon, Jul 30, 2012 at 21:53:45 +0200, Daniel Baumann wrote:
On 07/30/2012 09:47 PM, Julien Cristau wrote:
Great, then explaining the changes should be straightforward.
as i've read, other people on debian-release@lists.debian.org did that
already to the full extend.
And as you've no
On 07/30/2012 10:02 PM, Julien Cristau wrote:
And as you've no doubt read I'm not satisfied with that explanation, so
please try again.
again, i see not where i could add anything else that other people
already said.
Or if you prefer, I can remove the package from
wheezy, that works just as
On Mon, Jul 30, 2012 at 10:07:14PM +0200, Daniel Baumann wrote:
On 07/30/2012 10:02 PM, Julien Cristau wrote:
Or if you prefer, I can remove the package from
wheezy, that works just as well as far as I'm concerned, but I thought
I'd give it a chance.
feel free to do so if you think that
On 07/31/2012 12:44 AM, Neil McGovern wrote:
You failing to either do the work in time for a freeze that has
been advertised more than a year in advance,
i uploaded in time, before the freeze.
and then failing to justify your random uploads
there are no random uploads.
is absolutely, 100%
On 07/31/2012 01:50 AM, Daniel Baumann wrote:
there's nothing i can do about it except asking you to unblock said version,
which i did.
almost.. in addition to what the other people on the thread[0] already
said.. here are the individual git commits as patches attached,
constituting the
29 matches
Mail list logo