Package: pm-utils
Version: 1.3.0-2
Severity: normal
Tags: patch
Hi there!
Today I upgraded my system and it happened that the kernel was upgraded
as well, from /var/log/dpkg.log:
2010-09-16 09:28:54 upgrade linux-image-2.6.32-5-amd64 2.6.32-21 2.6.32-22
And now pm-hibernate does not want to suspend anymore, because from
/var/log/pm-suspend.log (implemented to solve #457515):
Thu Sep 16 18:17:29 CEST 2010: Running hooks for hibernate.
/usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate:kernel \
update inhibits hibernate (/var/run/do-not-hibernate present)
Returned exit code 1.
However, I am running another kernel (2.6.34-1-amd64), thus pm-hibernate
should work anyway. Indeed, removing /var/run/do-not-hibernate and
hibernating did not cause any issue (FYI, I am now at the third
hibernation/thawing cycle after the issue above).
The following patch should solve this issue, tested locally while both
upgrading the running kernel and a not-running one:
--8<---------------cut here---------------start------------->8---
--- a/kernel/postinst.d/pm-utils
+++ b/kernel/postinst.d/pm-utils
@@ -2,4 +2,11 @@
# Let programs know not to hibernate if the kernel that would be used for
# resume-from-hibernate is likely to differ from the currently running kernel.
-touch /var/run/do-not-hibernate
+
+# this fix bug #NNNNNN
+KERNEL_RUNNING=`uname -r`
+KERNEL_UPGRADING="$1"
+
+if [ "$KERNEL_RUNNING" = "$KERNEL_UPGRADING" ]; then
+ touch /var/run/do-not-hibernate
+fi
--8<---------------cut here---------------end--------------->8---
Thx, bye,
Gismo / Luca
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pm-utils depends on:
ii kbd 1.15.2-1 Linux console font and keytable ut
ii powermgmt-base 1.31 Common utils and configs for power
Versions of packages pm-utils recommends:
ii procps 1:3.2.8-9 /proc file system utilities
pn radeontool <none> (no description available)
pn vbetool <none> (no description available)
Versions of packages pm-utils suggests:
ii cpufrequtils 007-1 utilities to deal with the cpufreq
pn uswsusp <none> (no description available)
-- no debconf information
Acknowledgement sent
to Stefan Monnier <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 13 Oct 2010 02:39:03 GMT) (full text, mbox, link).
Subject: Re: uncoditionally prevent hibernation after any kernel upgrade
Date: Tue, 12 Oct 2010 22:23:28 -0400
Package: pm-utils
Severity: normal
Actually, preventing hibernation is not the right solution.
The right solution is to make sure hibernation works even when a new version
of the running kernel is installed. I do that by hand in my system
by copying the vmlinuz and initrd files in /etc/rc.local to a safe
place which I can select from the GRUB menu.
Stefan
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (10, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.36-rc6-686 (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pm-utils depends on:
ii kbd 1.15.2-1 Linux console font and keytable ut
ii powermgmt-base 1.31 Common utils and configs for power
Versions of packages pm-utils recommends:
ii hal 0.5.14-3 Hardware Abstraction Layer
pn radeontool <none> (no description available)
ii uswsusp 0.7-1.2 tools to use userspace software su
pn vbetool <none> (no description available)
Versions of packages pm-utils suggests:
ii cpufrequtils 007-1 utilities to deal with the cpufreq
-- no debconf information
Acknowledgement sent
to Michael Biebl <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 13 Oct 2010 06:51:07 GMT) (full text, mbox, link).
On 13.10.2010 04:23, Stefan Monnier wrote:
> Package: pm-utils
> Severity: normal
>
> Actually, preventing hibernation is not the right solution.
> The right solution is to make sure hibernation works even when a new version
> of the running kernel is installed. I do that by hand in my system
> by copying the vmlinuz and initrd files in /etc/rc.local to a safe
> place which I can select from the GRUB menu.
>
And how do you suggest we detect such local modifications?
Imho it is better to err on the safe side.
Not being able to hibernate, even if possible, is a nuisance. Losing data
because of a failing resume/thaw is not.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Acknowledgement sent
to Stefan Monnier <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 13 Oct 2010 12:09:05 GMT) (full text, mbox, link).
Subject: Re: Bug#597199: uncoditionally prevent hibernation after any kernel upgrade
Date: Wed, 13 Oct 2010 08:07:03 -0400
>> Actually, preventing hibernation is not the right solution.
>> The right solution is to make sure hibernation works even when a new version
>> of the running kernel is installed. I do that by hand in my system
>> by copying the vmlinuz and initrd files in /etc/rc.local to a safe
>> place which I can select from the GRUB menu.
> And how do you suggest we detect such local modifications?
I don't suggest you detect them, I suggest "you" (or some other part of
Debian) set them up.
Stefan
Acknowledgement sent
to "Brian J. Murrell" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
Your message did not contain a Subject field. They are recommended and
useful because the title of a $gBug is determined using this field.
Please remember to include a Subject field in your messages in future.
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" as the
kernel to thaw into.
Then the hibernation process should modify grub to add a "thaw from
hibernate" option that boots the stashed kernel/initrd in addition to
the other existing kernel options. The thaw option should probably be
default though.
In fact, writing up a package to plug all of that into the
boot/hibernate/thaw process shouldn't be terribly difficult I think.
Acknowledgement sent
to Michael Biebl <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Tue, 03 Jul 2012 13:09:11 GMT) (full text, mbox, link).
On 03.07.2012 14:50, Brian J. Murrell wrote:
> 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" as the
> kernel to thaw into.
>
> Then the hibernation process should modify grub to add a "thaw from
> hibernate" option that boots the stashed kernel/initrd in addition to
> the other existing kernel options. The thaw option should probably be
> default though.
>
> In fact, writing up a package to plug all of that into the
> boot/hibernate/thaw process shouldn't be terribly difficult I think.
I think you are underestimating the complexity involved.
That said, I'd be willing to review a detailed proposal or patch.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Acknowledgement sent
to "Brian J. Murrell" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Tue, 03 Jul 2012 19:42:03 GMT) (full text, mbox, link).
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 willing to review a detailed proposal or patch.
I have yet to debianize these additional files into a formal package,
but perhaps we can start with a review of the files. Big fat disclaimer
though... these are based on a Ubuntu Precise system so perhaps your
mileage might vary.
The attachments are:
/etc/init/save-kernel-for-hibernate.conf
/etc/grub.d/08_linux_thaw
/etc/pm/sleep.d/20_update-grub
Again, maybe there are some glaring holes in this implementation, but it
really is the fruit of just a couple of hours of work and testing and it
works, quite wonderfully here. It was even tested as working to resume
from hibernate after a kernel update was installed and resumed again,
after the new kernel was fresh booted and hibernated.
Cheers,
b.
Acknowledgement sent
to Michael Biebl <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 18 Jul 2012 12:45:03 GMT) (full text, mbox, link).
On 18.07.2012 14:36, Brian J. Murrell wrote:
> 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
> complicated when I was able to achieve a result with so few changes.
you are aware you sent a patch for upstart while debian uses sysvinit?
I stopped right there and didn't look any further
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Acknowledgement sent
to "Brian J. Murrell" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 18 Jul 2012 12:48:04 GMT) (full text, mbox, link).
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
complicated when I was able to achieve a result with so few changes.
Cheers,
b.
Acknowledgement sent
to "Brian J. Murrell" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 18 Jul 2012 13:21:03 GMT) (full text, mbox, link).
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 would work considering I was
only putting forth a proof-of-concept to try to understand why you think
this task is so complicated.
Shall I resubmit this all after converting that upstart script into a
sysvinit script for you?
> I stopped right there and didn't look any further
And didn't even bother to respond as such? Instead you just leave a
contributor wondering? Is this really the way to foster a healthy open
source community of contributors?
Why do you have to be like that? Seriously. Is the rest of the work in
my proof of concept so tainted just because there is a (IMHO, very
simple to understand) upstart script in it and not a sysvinit script?
Seriously though. Why do you have to be like that?
Acknowledgement sent
to Michael Biebl <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Wed, 18 Jul 2012 22:27:03 GMT) (full text, mbox, link).
Hi,
On 18.07.2012 15:18, Brian J. Murrell wrote:
> On 12-07-18 08:40 AM, Michael Biebl wrote:
>> I stopped right there and didn't look any further
>
> And didn't even bother to respond as such?
You submitted the patch just two weeks ago. At that point wheezy was
already frozen. This means this feature will most likely not be accepted
by the release team, so it wasn't a pressing issue for me and I simply
didn't look at it back then.
Instead you just leave a
> contributor wondering?
I just had a look at it today, when you pinged me again. Remember, I'm
doing Debian in my spare time also and I'm (co-)maintainer of over two
hundred packages, so I get a lot of bug reports and review requests. I
can't answer each and every bug report right away and sometimes I'm just
really short in my reply because I simply lack the time.
> Seriously though. Why do you have to be like that?
We are all in the same boat, trying to make Debian and the open source
world better. There is no need to make this personal
Anyway back to a more technical level:
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
upddated
b/ the user doesn't actually use hibernation
Also, running grub-mkconfig on every boot is is a very costly operation
which can take several seconds.
pm-utils is basically installed on every laptop and desktop system. On
stable, the kernel practically never changes. Also, hibernation is a
rather rarely used feature compared to suspend. So we slow down the boot
process unnecessarily for almost everyone.
Running the grub update on *every* hibernation is wrong, too. Most of
the time the kernel will not have changed in between so this is slowing
down hibernate unnecessarily, which should be as fast as possible.
What happens to those grub entries after a reboot? It seems to me they
are left there as stale hibernate entries. Stale entries are cleared
during boot, so we will have those entries at least for one boot cycle,
right?
I also don't see any error handling anywhere, in case /boot was not
writable/big enough to create the stashed kernel. This can happen if you
have a separate /boot partition which is small or mounted ro.
08_linux_thaw looks like it could be painful to maintain, it looks
rather complex and contains stuff like kexec. Is everything there really
necessary? Is that a copy of /etc/grub.d/10_linux which has been
extended by you?
It has stuff like /etc/linuxmint/info in there which make me curious
where it comes from as it generates warnings on my Debian system.
I'm not a grub expert, so I'm a bit wary about having to maintain such a
file.
To sum up: I'm not happy about the general approach to do this kernel
stashing during boot and running grub update at boot and before
hibernation and the implementation has its flaws, too.
You might look into the /etc/kernel/ hooks, which are run whenever a
kernel is upgraded. Maybe it allows to do the kernel stashing in a much
cleaner way.
I would also very much prefer, if the grub specific hook is moved into
grub proper. grub already contains the hooks for xen kernels or the
recovery mode. So adding boot entries for such stashed hibernate kernel
might fit in there, too.
I've CCed Colin. Maybe he can comment on this.
Colin, the relevant files are attached to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597199#35
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Acknowledgement sent
to "Brian J. Murrell" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Thu, 19 Jul 2012 10:54:03 GMT) (full text, mbox, link).
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
> upddated
> b/ the user doesn't actually use hibernation
OK. That's a fair assessment. TBH, I was not entirely happy with the
approach but wanted to put something out there to try to solicit comment
and more importantly, ideas.
> Also, running grub-mkconfig on every boot is is a very costly operation
> which can take several seconds.
Right. Agreed. And now that I have had some time to read your entire
critique and reflect, probably that belongs in the actual
resuming-from-hibernate code path.
> Running the grub update on *every* hibernation is wrong, too.
It can probably gated with some logic to see if the grub config is newer
than stashed kernel to avoid it every time. I will look into that.
> What happens to those grub entries after a reboot? It seems to me they
> are left there as stale hibernate entries.
No. They are cleaned out by the "resume|thaw" code path in
/etc/pm/sleep.d/20_update-grub.
> Stale entries are cleared
> during boot,
No, during thaw (i.e. return from hibernation).
> so we will have those entries at least for one boot cycle,
> right?
No, per above.
> I also don't see any error handling anywhere, in case /boot was not
> writable/big enough to create the stashed kernel. This can happen if you
> have a separate /boot partition which is small or mounted ro.
Yes. This was just proof-of-concept to solicit critique on the
approach. Of course a final implementation would have to have error
handling.
> 08_linux_thaw looks like it could be painful to maintain, it looks
> rather complex and contains stuff like kexec. Is everything there really
> necessary? Is that a copy of /etc/grub.d/10_linux which has been
> extended by you?
Yes, it is a copy of /etc/grub.d/10_linux modified to handle the "Resume
from Hibernation" grub entry. I debated simply adding that handling to
the 10_linux hook or maintaining the spirit of grub.d's modularity.
Obviously I chose the latter. I'm certainly not against the former, it
just means more red-tape in the form of trying to get a modification
into grub as well as pm-utils, co-ordinated.
TBH, I'm not entirely optimistic that grub will take such a modification
since it has reliance on the bits also being in pm-utils, tying the
dependency of the two packages more tightly together.
> It has stuff like /etc/linuxmint/info in there which make me curious
> where it comes from as it generates warnings on my Debian system.
> I'm not a grub expert, so I'm a bit wary about having to maintain such a
> file.
Yeah, that is just an artifact of the fact that my system is a Linux
Mint system. Of course, if the work were applied to Debian, such a
thing would not be in that file. Additionally, the duplication of
"linux_entry()" in that file begs for some abstraction and/or sharing of
that function amongst hooks. But again, my submission was just a PoC
for comment.
> To sum up: I'm not happy about the general approach to do this kernel
> stashing during boot and running grub update at boot and before
> hibernation and the implementation has its flaws, too.
Well, I can agree with getting that stuff out of the boot path given
your idea below, but if it's not in the boot path, it pretty much has to
be in the hibernate path. Not having it in both the boot path and not
in the hibernate path is pretty much like wanting your cake and eating
it too.
> You might look into the /etc/kernel/ hooks, which are run whenever a
> kernel is upgraded. Maybe it allows to do the kernel stashing in a much
> cleaner way.
Yes, this is a good idea. I tend to forget that there is a hook system
called during kernel upgrades and indeed, it would be a better place to
stash the running kernel.
> I would also very much prefer, if the grub specific hook is moved into
> grub proper. grub already contains the hooks for xen kernels or the
> recovery mode.
Yes. The recovery mode is handled by 10_linux for the kernels that are
handled by 10_linux but xen kernels are handled by their own hook in
20_linux_xen, just like my own 08_linux_thaw, and is very much a
duplication+modification of 10_linux, again just like my own
08_linux_thaw. IOW, if xen kernel handling is the model to follow, then
my 08_linux_thaw very much follows the model.
Let me take a moment now to thank you very much for the critique. It
was exactly what I was looking for. Thank-you. With any luck I will
find the time to try to rework my implementation.
Cheers,
b.
Acknowledgement sent
to Michael Biebl <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Thu, 19 Jul 2012 12:09:03 GMT) (full text, mbox, link).
On 19.07.2012 12:51, Brian J. Murrell wrote:
> On 12-07-18 06:24 PM, Michael Biebl wrote:
>> What happens to those grub entries after a reboot? It seems to me they
>> are left there as stale hibernate entries.
>
> No. They are cleaned out by the "resume|thaw" code path in
> /etc/pm/sleep.d/20_update-grub.
Ok,
>> Stale entries are cleared
>> during boot,
>
> No, during thaw (i.e. return from hibernation).
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 in case of a failed thaw?
>> I would also very much prefer, if the grub specific hook is moved into
>> grub proper. grub already contains the hooks for xen kernels or the
>> recovery mode.
>
> Yes. The recovery mode is handled by 10_linux for the kernels that are
> handled by 10_linux but xen kernels are handled by their own hook in
> 20_linux_xen, just like my own 08_linux_thaw, and is very much a
Right, but 20_linux_xen is shipped and maintained by the grub maintainers.
While we are talking about grub, there is something which has been
bugging me for quite a while:
Consider you have different operating systems or multiple kernels
installed on your machine. After a hibernate, grub should not show the
full menu which lets you select an alternative kernel / system, but
immediately load the kernel which as used for hibernation.
If you have a shared partition between different systems and you boot
into the wrong one, i.e. not the one which was used for hibernation, you
risk data loss otherwise
So if we are going to mangle the grub entries anyway, maybe we can fix
this issue while at it.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Acknowledgement sent
to "Brian J. Murrell" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Thu, 19 Jul 2012 12:57:06 GMT) (full text, mbox, link).
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 in case of a failed thaw?
Indeed. I had a failed thaw just yesterday in fact. That's one reason
we do have to update grub in the boot path, unfortunately. Now,
granted, it could be a little smarter and only run that if a
resume-from-hibernate entry is found in the grub file, then it only
slows down boots from failed thaws, which should hopefully be next to
never -- although my failed thaw yesterday proves it's not never at all.
> Right, but 20_linux_xen is shipped and maintained by the grub maintainers.
Well, I don't really care one way or the other who ships and maintains
it. I'm not entirely optimistic about them accepting it since it
depends on how pm-utils does it's kernel stashing and needs to maintain
parity with that. I suppose we could have both pm-utils and grub look
in an /etc/default file about where kernels are stashed, etc.
But yeah, if the grub maintainers accept that functionality, I have no
problem with it being in grub.
> While we are talking about grub, there is something which has been
> bugging me for quite a while:
> Consider you have different operating systems or multiple kernels
> installed on your machine. After a hibernate, grub should not show the
> full menu which lets you select an alternative kernel / system, but
> immediately load the kernel which as used for hibernation.
Yes, indeed. I actually tried to add a new top-level menu in my own
grub when I was experimenting with all of this, so that the top level
showed only the "resume from hibernate" option plus one other option
"Boot a new kernel" which was a sub-menu that was just the usual
top-level menu of your various kernels and other operating systems.
Multiple levels of sub-menus didn't seem to work though, despite the
grub folks saying they should, IIRC.
> If you have a shared partition between different systems and you boot
> into the wrong one, i.e. not the one which was used for hibernation, you
> risk data loss otherwise
Do you mean one root filesystem that is used by multiple grub entries
for example? And you hibernate while booted on that shared root but
then boot a new/fresh system on it after hibernating on it?
I could see how that could be a problem. So then perhaps after a
hibernate there is no "boot other system" option at all and the only
option is to resume? In such a case, I guess we don't even need a menu.
Grub should just boot the hibernation kernel without any pause or menu.
> So if we are going to mangle the grub entries anyway, maybe we can fix
> this issue while at it.
OK.
Cheers,
b.
Acknowledgement sent
to Mateusz Jończyk <[email protected]>:
Extra info received and forwarded to list. Copy sent to Tim Dijkstra <[email protected]>.
(Tue, 19 Aug 2014 12:45:06 GMT) (full text, mbox, link).
Subject: Re: pm-utils: uncoditionally prevent hibernation after any kernel
upgrade
Date: Tue, 19 Aug 2014 13:57:39 +0200
We could just do:
- at boot time:
1) rm /boot/vmlinuz-running /boot/initrd-running
2) get BOOT_IMAGE from /proc/cmdline
3) ln /boot/vmlinuz-running $BOOT_IMAGE
4) do the above for the initrd as well
- these hard symlinks should prevent dpkg from modifying the old kernel image
- when hibernating:
1) grub-editenv set HIBERNATED=true
- at thaw and shutdown:
1) grub-editenv unset HIBERNATED
- in Grub:
- detect if HIBERNATED=true and in this case boot the hibernated image
Greetings,
Mateusz Jończyk
Reply sent
to Debian FTP Masters <[email protected]>:
You have taken responsibility.
(Thu, 21 Dec 2023 18:00:44 GMT) (full text, mbox, link).
Notification sent
to Luca Capello <[email protected]>:
Bug acknowledged by developer.
(Thu, 21 Dec 2023 18:00:44 GMT) (full text, mbox, link).
Subject: Bug#1058701: Removed package(s) from unstable
Date: Thu, 21 Dec 2023 17:56:09 +0000
Version: 1.4.1-19+rm
Dear submitter,
as the package pm-utils has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/1058701
The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.
Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.