Bugzilla Bug 156431

work in progress...
ebuild is working, need to integrate the resuming into genkernel initramfs
generation

Created an attachment (id=102855) [details]
suspend-0.5.ebuild

Created an attachment (id=102856) [details]
suspend-0.5-build.patch

bug #156431 has a genkernel patch which makes the whole thing rather easy:

# emerge suspend
configure resume in /etc/suspend.conf
enable CONFIG_SOFTWARE_SUSPEND in kernel
# genkernel [...] --suspend all
reboot into new kernel
# s2disk

power on, system resumes to last point

mobile herd: anyone interested in co-maintaining this? I expect it will get
popular over time...

Hi,
What are the kernel requirements for this to work?
I built it by hand....

Thank you.

see comment #3

Thank you for thje reply, but...
I can't find the CONFIG_SOFTWARE_SUSPEND option in "menuconfig".

Type /SOFTWARE_SUSPEND<enter> in menuconfig and ensure you have satisfied all
dependencies

It turns out that we aren't going to use this at work just yet and I don't have
time to maintain it in my own time. Hopefully someone else will continue my
work so far and get this in portage.

I'd love to have it on the tree. I've installed the ebuild and (after
discovering that fglrx and fb wouldn't go along well) I got my Thinkpad T60 to
suspend and resume, both to memory and disk. Much easier than suspend2, which
still was giving me headaches when resuming.

I had to add the option -j1 to the line with "emake" to get it compiled on two
of my systems (P4 2.6 GHz and Core2Duo). See Bug #179493

I have expanded a bit on this with two files; new ebuild and a script to
generate initrd-images. Will post them shortly.

Ebuild changes:
 - Replaced header (easytag?)
 - Added ~x86 keyword
 - Added short instructions to pkg_postinst() (elog)
 - Added installation of create-resume-initrd.sh (should be in files/)

create-resume-initrd.sh:
 - Not the script that is bundled with suspend-0.5, but it does the same.
Resume device and image size is read from /etc/suspend.conf instead of user
input.

I'm new to ebuilds, so I'm wondering:
 1: Is there a way to check in the ebuild what CONFIG_s the kernel was compiled
with? That way I could get rid of a few elogs.
 2: Could someone make sure I didn't do something silly in the ebuild? I hope I
did things the right way.

PS: I don't use genkernel, and I don't know if things should be handled
differently with it. Any input on that?

Created an attachment (id=123896) [details]
Ebuild with added keyword, elogs and script (next attachment) installation.

Created an attachment (id=123897) [details]
Script for resume-initrd generation.

I will be able to maintain this.
I've fixed liblzf build, I am waiting for upstream to ack.

Created an attachment (id=124984) [details]
suspend-0.5.ebuild

olechrt: I am sorry, but don't like the long logs. You should look at the
README to know what to do.

Created an attachment (id=124985) [details]
suspend-0.5-build.patch

Created an attachment (id=124988) [details]
suspend-0.5.ebuild

Created an attachment (id=124989) [details]
liblzf-2.1_beta1.ebuild

For now, I've put the fixed tarball at:
http://dev.gentoo.org/~alonbl/liblzf-2.1_beta1.tar.bz2

Please check it out.

liblzf upstream is very rude!
I won't maintain his library.

>I hope so, in another way. Get to your senses and *learn* to get rid of your
>wrong assumptions. Your proposals are techniccally unsound. Hating *me* for
>your deficiencies is pointless. I am just the messenger.
>
>And I do regret having wasted my time with you. Certainly "those other"
>distros have more capable maintainers that actually listen to technical
>suggestions.
>
>*PLONK*

Update:
I've worked with upstream in order to make this package more distribution
friendly package.
1. Use lzo and not lzf.
2. Use autoconf/automake.
3. Support fbsplash.
4. Many more cleanups.

Soon the new release with (1), (4) is released.

Then genkernel will need to be updated.

This is much easier to maintain.

dsd: At bug#156445 you compiled the uswsusp as part of genkernel, I wish to
modify it to use existing files and just copy resume into initramfs (much like
splashutils), is there any reason why this should be avoided?

Yes.  I no longer accept features that require files from the built system and
am moving towards having everything use internal builds only.  The reason for
this is for cross-compiling reasons, where taking from the local disk is a
*really* bad idea.

But how do you sync version/features/configuration required to exists both in
root filesystem and initramfs?

s2disk/s2both exists on root filesystem and resume exists on initramfs.
They both needs to be synced (same version, same features [USE])

Also there is an issue of configuration, /etc/suspend.conf needs also to be
synced up between these environments.

BTW: Cross compile does not actually work (bug#190327).

I am well aware of what does and does not work in genkernel, thank you.  I am
also working to fix these problems, so I am not going to introduce anything new
which doesn't meet with my goals.  Remember that genkernel is a "Gentoo Hosted
Project" which means it should be usable by *anyone* running Linux.  There is
far too much "Gentoo only" code in there that needs to be modified into a more
widely available usage, which I am trying to do.  It is just happening slowly.

Please replay to me questions at comment#24:

But how do you sync version/features/configuration required to exists both in
root filesystem and initramfs?

s2disk/s2both exists on root filesystem and resume exists on initramfs.
They both needs to be synced (same version, same features [USE])

Also there is an issue of configuration, /etc/suspend.conf needs also to be
synced up between these environments.

AS you said, genkernel should be available for all users... And the suspend
package put the initramfs binary at /usr/lib/suspend/resume so it may be copied
to initramfs at later time.

I will be glad to read of a better solution, but mind that
${ROOT}/usr/sbin/s2disk, ${ROOT}/usr/sbin/s2ram and
${ROOT}/usr/lib/suspend/resume shares version, compression, libraries, splash
etc...

I don't see how this conflict with your goals, as the same applied to every
component like this one which needs to be split between initramfs and root.
splashtutils and suspend are a good example.

(In reply to comment #26)
> Please replay to me questions at comment#24:
> 
> But how do you sync version/features/configuration required to exists both in
> root filesystem and initramfs?

I haven't even thought about it.

> s2disk/s2both exists on root filesystem and resume exists on initramfs.
> They both needs to be synced (same version, same features [USE])

That's nice.  It still isn't going to come from the host system.  I am not
going to rely on any of the following:

make.conf
/var/db entries
anything in /etc/portage
binaries on the system for inclusion into initramfs

> Also there is an issue of configuration, /etc/suspend.conf needs also to be
> synced up between these environments.

This is simple to resolve.  You setup genkernel.conf to point to the location
for your suspend.conf file and give a sensible default file.  This means you
aren't *relying* on anything from the host system, as the configuration can
come from anywhere.

> AS you said, genkernel should be available for all users... And the suspend
> package put the initramfs binary at /usr/lib/suspend/resume so it may be copied
> to initramfs at later time.

...and?

> I will be glad to read of a better solution, but mind that
> ${ROOT}/usr/sbin/s2disk, ${ROOT}/usr/sbin/s2ram and
> ${ROOT}/usr/lib/suspend/resume shares version, compression, libraries, splash
> etc...

We typically don't follow that philosophy with genkernel.  The design of
genkernel is to create a usable kernel for as many people as possible.  What
this means is we'll compile with pretty much every option enabled by default.

> I don't see how this conflict with your goals, as the same applied to every
> component like this one which needs to be split between initramfs and root.
> splashtutils and suspend are a good example.

OK.  Let me put it simply.  If it requires copying some binary from the host
system doing the build, it fails my requirements.  Lots of current code will
need to be revamped for this.  As I said, it'll happen over time.  Anyway,
enough of that.  It doesn't really belong here, so I'll quit filling all your
boxes with bugspam.

(In reply to comment #27)
> > s2disk/s2both exists on root filesystem and resume exists on initramfs.
> > They both needs to be synced (same version, same features [USE])
> 
> That's nice.  It still isn't going to come from the host system.  I am not
> going to rely on any of the following:
> 
> make.conf
> /var/db entries
> anything in /etc/portage
> binaries on the system for inclusion into initramfs
> 
> > Also there is an issue of configuration, /etc/suspend.conf needs also to be
> > synced up between these environments.
> 
> This is simple to resolve.  You setup genkernel.conf to point to the location
> for your suspend.conf file and give a sensible default file.  This means you
> aren't *relying* on anything from the host system, as the configuration can
> come from anywhere.

So why can't I point to /usr/lib/suspend/resume as well?
It can point to anything...

> We typically don't follow that philosophy with genkernel.  The design of
> genkernel is to create a usable kernel for as many people as possible.  What
> this means is we'll compile with pretty much every option enabled by default.

Which option?
suspend can be used with many options: compression, encryption, bootsplash,
splashy, fbsplash and more.
Which one will you enable and which you disable?
How do you choose these?

Will you recompile all dependencies in genkernel?
So why don't you also compile the libc?

> OK.  Let me put it simply.  If it requires copying some binary from the host
> system doing the build, it fails my requirements.  Lots of current code will
> need to be revamped for this.  As I said, it'll happen over time.  Anyway,
> enough of that.  It doesn't really belong here, so I'll quit filling all your
> boxes with bugspam.

This is not bugspam, people are waiting for this package, and until I
understand how we support version sync and advanced features such as
compression and fbspalsh sync with the root components we will not be able to
provide this to our users.

I think that the users in the CC are interested in what we have to say
regarding this.

---

Maybe we can remove the compilation of suspend from current genkernel
implementation and make genkernel support several overlays, so packages like
splashutils and suspend may provide their overlays in predefined location so
user can include them at build process?

This may ease your decision to support this, as genkernel it-self does not
directly depended on external binaries.

(In reply to comment #28)
> So why can't I point to /usr/lib/suspend/resume as well?
> It can point to anything...

You can do whatever you want.  I'll do what I feel is best in genkernel.  Deal?

> Which option?
> suspend can be used with many options: compression, encryption, bootsplash,
> splashy, fbsplash and more.
> Which one will you enable and which you disable?
> How do you choose these?

Wow.  I guess I really do need to spell it out.  I would enable them all by
default.

> Will you recompile all dependencies in genkernel?
> So why don't you also compile the libc?

Are you trying to be dense or do you really just not understand what I am
trying to accomplish?

> This is not bugspam, people are waiting for this package, and until I

No.  It definitely *is* bug spam.  Adding an ebuild has nothing to do with the
genkernel support.  However, since you're so concerned, I'm just going to rip
out the current support that is in genkernel for the next release so you can
get this into the tree without having to concern yourself with how I plan on
supporting it in my package.

> understand how we support version sync and advanced features such as
> compression and fbspalsh sync with the root components we will not be able to
> provide this to our users.
> 
> I think that the users in the CC are interested in what we have to say
> regarding this.

Well, I am not interested in repeating myself over and over again, so I'm
removing myself/genkernel from CC.  I have already said everything that I think
needs to be said from my end.  I didn't realize this was going to turn into the
Spanish Inquisition when Daniel first came up with it.  I'm sorry that I jumped
the gun and added support for this to genkernel when I did.

I can't merge suspend-0.5. I have liblzf installed (the beta ebuild):

 * Applying suspend-0.5-build.patch ...                                  [ ok ]
>>> Done src_unpack
>>> Starting src_compile
make -j2 CONFIG_COMPRESS=1 SUSPEND_DIR=/sbin CONFIG_UDEV=1
CC=i686-pc-linux-gnu-gcc
i686-pc-linux-gnu-gcc -O2 -Wall -c vt.c -o vt.o
i686-pc-linux-gnu-gcc -O2 -Wall -DHAVE_INTTYPES_H -DHAVE_STDINT_H -c md5.c -o
md5.o
i686-pc-linux-gnu-gcc -O2 -Wall -DHAVE_INTTYPES_H -DHAVE_STDINT_H
-I/usr/local/include -DCONFIG_COMPRESS -c encrypt.c -o encrypt.o
i686-pc-linux-gnu-gcc -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c
config.c -o config.o
i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c
bootsplash.c -o bootsplash.o
i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c
splashy_funcs.c -o splashy_funcs.o
i686-pc-linux-gnu-gcc -O2 -Wall -c vbetool/lrmi.c -o vbetool/lrmi.o
i686-pc-linux-gnu-gcc -O2 -Wall -c vbetool/x86-common.c -o vbetool/x86-common.o
i686-pc-linux-gnu-gcc -O2 -Wall -DS2RAM -c vbetool/vbetool.c -o
vbetool/vbetool.o
i686-pc-linux-gnu-gcc -O2 -Wall -DS2RAM -c radeontool.c -o radeontool.o
i686-pc-linux-gnu-gcc -O2 -Wall -DS2RAM -c dmidecode.c -o dmidecode.o
i686-pc-linux-gnu-gcc swap-offset.c -o swap-offset
i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS -c
splash.c -o splash.o
i686-pc-linux-gnu-gcc -O2 -Wall -g s2ram.c vt.o vbetool/lrmi.o
vbetool/x86-common.o vbetool/vbetool.o radeontool.o dmidecode.o -lpci -o s2ram
i686-pc-linux-gnu-gcc -g -O2 -Wall -I/usr/local/include -DCONFIG_COMPRESS vt.o
md5.o encrypt.o config.o suspend.c -o s2disk splash.o bootsplash.o 
-L/usr/local/lib -llzf
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpci.a(names.o): In function
`pci_load_name_list':
names.c:(.text+0x527): undefined reference to `gzopen'
names.c:(.text+0x5b9): undefined reference to `gzgets'
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpci.a(names.o): In function
`.L154':
names.c:(.text+0x6bb): undefined reference to `gzclose'
names.c:(.text+0x6d8): undefined reference to `gzeof'
names.c:(.text+0x75c): undefined reference to `gzclose'
names.c:(.text+0xb0d): undefined reference to `gzopen'
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpci.a(names.o): In function
`.L155':
names.c:(.text+0xc7d): undefined reference to `gzerror'
names.c:(.text+0xc9f): undefined reference to `gzclose'
collect2: ld returned 1 exit status
make: *** [s2ram] Error 1
make: *** Waiting for unfinished jobs....

Cyrill Helg: Please wait for the next release (soon).

(In reply to comment #30)
> I can't merge suspend-0.5. I have liblzf installed (the beta ebuild):

Well, you can if you re-emerge pciutils without the stupid zlib use flag...

Created an attachment (id=129971) [details]
suspend-0.7.ebuild

New ebuild, with autoconf patch for the next release (Will make it easier for
me to help and get some feedback before next release).

Created an attachment (id=129972) [details]
suspend-0.7-autoconf.patch

genkernel users: Please refer to bug#156445, I've places some instructions of
how to use the overlay in order to make it work.

why does the ebuild depend on dev-libs/libx86?
the only ebuild[0] i found is named sys-libs/libx86.

is the fbsplash use flag commented out because of a missing splashy/libsplashy
ebuild? if not, can you provide a link to one?


[0]
http://viewvc.tuxfamily.org/svn_picoverlay_ebuilds/trunk/sys-libs/libx86/?pathrev=86

FWIW, fbsplash != splashy.

Created an attachment (id=130866) [details]
libx86-0.99.ebuild

dev-libs/libx86

(In reply to comment #36)
> why does the ebuild depend on dev-libs/libx86?
> the only ebuild[0] i found is named sys-libs/libx86.

Attached.

> is the fbsplash use flag commented out because of a missing splashy/libsplashy
> ebuild? if not, can you provide a link to one?

After upstream merge the fbsplash I will post an update.

(In reply to comment #37)
> FWIW, fbsplash != splashy.

afair uswsusp currently only supports splashy


(In reply to comment #39)
> (In reply to comment #36)
> > why does the ebuild depend on dev-libs/libx86?
> > the only ebuild[0] i found is named sys-libs/libx86.
> 
> Attached.
> 
> > is the fbsplash use flag commented out because of a missing splashy/libsplashy
> > ebuild? if not, can you provide a link to one?
> 
> After upstream merge the fbsplash I will post an update.
> 


Good news! (:

Created an attachment (id=130871) [details]
libx86-0.99.ebuild

This dev-libs/libx86 should also work for amd64, can anyone test?

Created an attachment (id=130872) [details]
libx86-0.99-build.patch

Added to tree with fbsplash support, I will resync this when upstream makes
some progress.
genkernel users will have to patch genkernel in order to work with this
package, see bug#156445.

*** Bug 128468 has been marked as a duplicate of this bug. ***