On 12-07-19 08:07 AM, Michael Biebl wrote:
>
> It seems it actually does both: during thaw and boot. This is from
> save-kernel-for-hibernate.conf:
>
> # make sure any previous hibernate grub menu item is cleared out
> grub-mkconfig >/boot/grub/grub.cfg
>
> I assume this was done i
On 12-07-18 06:24 PM, Michael Biebl wrote:
> Hi,
Hi Michael,
> I need to be honest and say that I don't like the approach to do this
> via a sysvinit or upstart script which does the copy on each and every
> boot, even when
> a/ the kernel doesn't actually change during runtime because it isn't
>
On 12-07-18 08:40 AM, Michael Biebl wrote:
you are aware you sent a patch for upstart while debian uses sysvinit?
Yes, I am aware of that. I didn't think it would be too much of a
stretch for one to understand what that upstart init script was doing
and how a sysvinit implementation of it w
On 12-07-03 09:07 AM, Michael Biebl wrote:
I think you are underestimating the complexity involved.
That said, I'd be willing to review a detailed proposal or patch.
You have not yet made any comment on my last update including
implementation. I would appreciate knowing why you think it's so
On Tue, 2012-07-03 at 15:07 +0200, Michael Biebl wrote:
>
> I think you are underestimating the complexity involved.
I must be since in a few hours I seem to have come up with a few
modifications (all new files, no patching of existing files necessary)
that achieves the goal.
> That said, I'd be
Yes, indeed, the process Stefan is using is the correct process, IMHO,
and should be formalized.
That is, after booting a given kernel (and it does need to be done
immediately during/after booting so that a same-version upgrade doesn't
replace it), that kernel and it's initrd should be "stashed" a
On 11-09-30 06:29 AM, Josselin Mouette wrote:
>
> This “ideal of perfection” only requires someone to stick his fingers
> out of his ass and actually do the work.
Message #12 offered to do that and in Message 19 you told him not to do
that. I sure got the impression from your tone that there was
On 11-09-30 07:06 AM, Josselin Mouette wrote:
>
> Message #12 offered to update libproxy to 0.4, which would make things
> worse.
Maybe you'd care to explain how. I am running 0.4.7 here on my Ubuntu
system and it works a heck of a lot better than 0.3.1 did. Have you
brought up your issues with
On 37-01--10 02:59 PM, wrote:
> Le jeudi 22 septembre 2011 à 17:59 +0100, Iain Lane a écrit :
>> I've been working recently on upgrading libproxy to 0.47, the latest
>> upstream.
>
> Seriously, don’t do that.
>
> The 0.3 series was already broken, and the 0.4 one is even worse. They
> reimplem
The "correct" solution here is to upgrade libproxy to 0.4.7. The 0.3
release is no longer supported and the upstream resolution for this
exact bug was to upgrade to 0.4. Additionally the upstream developers
reported that they would not be fixing this (or any other) bug in 0.3.x
b.
signature.a
Did/will the patch from message #24 of this bug be applied? It seems to
have right effect here.
Although, it would be nice to use the --bind for tracker connections
too, since don't those connections tell remote peers where to connect to
to get to one's own peer?
signature.asc
Description: This
On Tue, 2008-11-11 at 12:08 -0500, Eric Cooper wrote:
> The fix should be simple.
Is that a hint that I should be able to fix it myself? :-) If so, I'm
afraid not. I've looked at gc.ml but this ocaml language is completely
new and foreign to me. Any chance you can provide a patch? If that was
On Fri, 2007-12-07 at 15:00 -0500, Theodore Tso wrote:
>
> Thanks for calling my attention to this;
NP. It was an itch for us.
> So I just pulled down the the rpc.mountd sources, and I see the problem.
Great.
> So the bug fix is very simple, actually; this should fix things.
>
>
Has any progress been made on this bug? It seems to have stalled after
Marcus sent Ted the information he requested.
Any progress update would be much appreciated.
Thanx,
b.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
14 matches
Mail list logo