Bugzilla Bug 156445

Linux 2.6.17 added a new way of hibernating (suspend-to-disk): exposing some
more interface to userspace and then letting the snapshot image control be done
as a user program.

Userspace utilities were developed to use this functionality:
http://suspend.sourceforge.net

I intend to add an ebuild for this very soon: bug #156431

I haven't added support to the initrd generating code, is this still
used/supported? It could be added easily if necessary.

Created an attachment (id=102863) [details]
patch

Created an attachment (id=102918) [details]
ebuild patch

Created an attachment (id=102919) [details]
suspend-0.5-Makefile.patch

Created an attachment (id=102986) [details]
updated genkernel patch

suspend.conf is now copied in gen_initramfs.sh rather than gen_compile.sh. This
prevents it from being cached in the bincache.

OK.  The patch has been added to genkernel's SVN.  The rest will need to be
done in the ebuild when I roll up a new version.

Hi!
Will you consider supporting suspend2 in the same way?
I will create a patch to add sys-apps/suspend2-userui into the initramfs.

File a new bug for new additions, please.

Fixed in 3.4.6

OK.  Per the discussion on bug #156431, I am removing this support from
genkernel until the package is added to the tree.  Because of this, I am
reopening this bug report until newer support can be added.

Which support do you wish we add?
You explicitly said that there is no relation between the ebuild and genkernel.

OK.  This was removed with genkernel-3.4.9_pre2 which is now in the tree.  I
guess we'll revisit this in the 3.5 branch, when I start working on it.

Created an attachment (id=129631) [details]
genkernel-minimal-suspend.patch

Please apply the following so that people can put resume in an overlay and
initramfs will be capable of resuming.

No need to compile anything for this one.

Thanks.

So if I want to use uwsusp with my genkernel initrd (because of lvm2, my swap
is a lvm2 volume) I need to just apply the latest patch to what? genkerel?

wolf31o2: Please apply the minimal support in init script (attachment#129631 [details]),
so people may introduce their own overlay as in suspend2 case.

For people intersting in making uswsusp work (bug#156431):
1. Apply patch for genkernel from attachment#129631 [details] .
2. Do:
mkdir -p /tmp/initramfs-overlay/sbin
cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin
genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever>

Have fun!

[update]

For people intersting in making uswsusp work (bug#156431):
1. Apply patch for genkernel from attachment#129631 [details] [edit] .
2. Do:
mkdir -p /tmp/initramfs-overlay/sbin
mkdir -p /tmp/initramfs-overlay/etc
cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin
cp /etc/suspend.conf /tmp/initramfs-overlay/etc
genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever>

Have fun!

Created an attachment (id=130076) [details]
dev_snapshot.patch

Somehow udev on initrd does not create /dev/snapshot device on my system
(genkernel-3.4.8, amd64) so resume can't do anything. This patch creates
/dev/snapshot if it's missing before running /sbin/resume.

Created an attachment (id=130111) [details]
genkernel-minimal-suspend.patch

Thanks Sergey,
A minor update.

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

Do not add 156431 here.  You do not need genkernel support to add an ebuild to
the tree as genkernel is an independent Gentoo-hosted project which is
independent to the tree.

Thanks

But people cannot use this until you at least add attachment#130111 [details]
Adding the package to the tree will result in unusable package.
So it is dependent.

Please add the minimal patch, so we can drop the dependency.

BTW: The minimal support is identical to suspend2 support which already
supported.

What?

People can compile their own kernel and assemble their own initr{d,amfs}
without genkernel.  There are tons of packages in the tree without support in
genkernel.  What I am trying to explain to you is that genkernel is *not*
blocking your package being added.  I've also made it clear that I'm not going
to revisit this for some time.  I have no intentions on adding your patch to
genkernel for reasons I have stated so many times I am starting to feel blue in
the face.  I am not interested in supporting *any* new code which pulls from
the running system.  

Period.

Now, please stop adding this bug as a blocker to your bug.  Your bug does not
depend on genkernel any more than gentoo-sources does.  You have done your due
diligence by adding a patch here that will allow users of your ebuild to use
this support.  As upstream, I have rejected this patch.  Now, you have two
choices here, you can either add the ebuild and be done with it and I'll add
proper suspend support to the next genkernel in a manner that I think is best,
which includes doing all of the building and such within genkernel, or you can
sit on it for as long as you like.  I will not be adding any support for
suspend until it is in the tree, and that support will be added in the manner
of my choosing.  I am not meaning this to be rude, but genkernel is my package
and I am the one that has to support it.  I'm not going to support code I do
not with to support, so please take this opportunity to revisit your thoughts
on this and understand that whatever pressure that you might think that you are
putting on me as genkernel's upstream is unwarranted and unwanted.

Now, please do not add 156431 to this bug again.  I have no intentions on ever
adding suspend support to genkernel until it is in the tree.  I thought that I
had made this clear before when I said that I wish I had never added it.

Thanks

The patch for minimal support does not pull anyting from the tree!
So the reasons you keep mentioning are not true.
Please add the patch from attachment#130111 [details], as people are waiting for it.

As in the livecd theme cases... I need to do your job in making users happy...
The minimal patch will do nothing for your ego so please add it.

*sigh*

What part of "I am not going to add it" do you not understand?  Trying to
passive-aggressively threaten someone by adding devrel to a *technical
discussion* sure isn't the way to win an upstream to your cause.

I'm sorry, but unless there is some interpersonal issue that I am unaware of
here, Developer Relations has exactly zero authority here.  The closest team
that would preside over this would be the QA team, but refusing to support
something I don't feel like supporting isn't exactly a QA violation.  It is my
right and privilege as the upstream maintainer of genkernel.

Now, I am trying to be as civil as I possible can with you, but you are
starting to upset me with your single-mindedness on this issue.  I have
requested that you stop and you have not.  In case you are wondering, that *is*
a devrel-enforceable charge.  Of course, I think we can work this out like
civil adults without involving Developer Relations, which is why I am removing
them from this bug.  If you insist on bringing them in on a technical issue, I
will be forced to play my hand and file a complaint against you for harassment.

Let me say this one more time.  I am not adding your patch.  Your continued
persistence that I am somehow obligated to do so is bordering on harassment. 
Stop your harassment *now* or I will be forced to take appropriate action.

Thank you.

Created an attachment (id=134504) [details]
genkernel-minimal-suspend.patch

[Update, no need for configuration file]

For people intersting in making uswsusp work with genkernel:

1. Apply this patch.
2. Do:
mkdir -p /tmp/initramfs-overlay/sbin
cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin
genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever>
3. Add resume=<device> at your kernel command-line.

Have fun!

Can we please have attachment#134504 [details] for genkernel-3.4.9?
Thanks.

Prodding like that on the bug just makes us (well, me) want to stick this bug
at the very end of the queue. We're right in the middle of a release cycle, in
addition to having jobs and real lives. You've done your part by creating the
patch. We'll get around to doing our part.

Created an attachment (id=136075) [details]
genkernel-3.4.9_pre9-uswsusp.patch

Rebase.

Why haven't you added this to 3.4.9?
Was it so hard to apply a simple patch?

From comment#28, it seems to be some kind of queue unrelated to technical
priority. I did not bother you (as requested), in order to not get into the end
of this strange queue...

Well... On genkernel-3.4.9 too, users will also won't be able to use uswsusp.

That means that whoever cares about his users ends up in getting comments like
this... And our users not getting a solution.

Great work!

Created an attachment (id=140761) [details]
genkernel-3.4.9-uswsusp.patch

Rebase.

For people intersting in making uswsusp work with genkernel:

1. Apply this patch.
2. Do:
mkdir -p /tmp/initramfs-overlay/sbin
cp /usr/lib/suspend/resume /tmp/initramfs-overlay/sbin
genkernel <whatever> --initramfs-overlay=/tmp/initramfs-overlay <whatever>
3. Add real_resume=<device> at your kernel command-line.

*sigh*

Allow me to explain to you *one more time* why this has not been added.  I am
planning on writing the code for this support in such a manner as to not
require it to pull files from the local filesystem when it is not necessary. 
As such, it was not ready for inclusion in 3.4.9, as 3.4.9 was essentially a
rollup release for things required for releases.  Since we weren't using this
in our releases, it was deferred to a later date.  While I understand that you
do not personally agree with this decision, I *am* upstream for this piece of
software and it is up to me to decide what to do with it.  As such, you really
need to have some patience and wait for me to include this *without* the
attitude.  There is *no reason* for you to act in this way.

As such, consider this my "dev to dev" talk about your continued attitude
problems towards me.  Stop your little personal crusade, now.  I don't care if
I made you upset by not accepting your patches, as is.  That is my prerogative
as the package maintainer.  It also isn't a QA violation to *not* add new code.
 It *could* be a QA violation if I refused to fix broken code, but this is new
support, and doesn't apply, as such.  Please take a step back and think about
your interactions on this bug and think about it as if I were an external
developer of an external piece of software.  Would that upstream even want to
deal with you again after this sort of an attitude?  Of course not...

Since you seem determined to think that the inclusion in non-technical, allow
me to point you to https://bugs.gentoo.org/show_bug.cgi?id=156431#c23 for my
reasoning.  Whether you agree with it or not, it is a technical reason for why
this has not been included.  If you would like to see this included much more
quickly, I ask you to rewrite the patch to build and compile the necessary
binaries within genkernel.  If there are any configuration files required for
this, then the location of the config file should be a variable set in
genkernel.conf, and should likely default to the default location.  If you are
not willing to write this patch, then you will need to wait for me to do so. 
That means you have to wait until it fits into *my* schedule.

I had thought that I had made this perfectly clear, but I guess not.

Also, new feature requests are *always* at the end of the queue.  New feature
requests without patches acceptable to the author are lower priority than
patches that are acceptable.  As such, this is already about as low of a
priority as one can get, but your attitude makes me not want to work on this,
so it *does* lower the priority and it *is* for a non-technical reason, but the
main reason for it not being included is technical.  I'd add this support even
if you were a supreme asshole, so long as the patch was acceptable.  In this
case, the patch is not acceptable, and you're being a jerk about it.

Please try to *at least* have a respectful attitude.  I don't expect you to
respect me or even to like me, but simply to respect that I am the current
maintainer of this software and it is my call what does and doesn't go in and
why.

Thank you

Until a perfect solution will come, you can provide users the same level of
support you already have for suspend2/tuxonice, whose patch you accepted.

The minimal patch does not copy any binaries from local system as you
requested, so I don't see what is wrong with it, it provides temporary
solution, but makes some of Gentoo user happier.

I ignore all personal stuff.

If you want genkernel to be usable, you should rewrite it to be modular.
For example have /usr/share/genkernel/packages.d which have a script for each
package that responsible to compile it... And at /etc/genkernel.conf specify
which packages to compile.

The output of the packages is cpio file that merged into initramfs.

At the initramfs there should be /etc/initramfs.d (or any other) which will
have initramfs init script parts, sorted by a numeric prefix and sourced by
/init. This way every package may add its own functionality into the init
script. There should also be hooks in /init to allow registration of init parts
functionality, for example at startup, after device manager, before root mount,
after root mount etc...

This way we can have app-genkernel/busybox, app-genkernel/uswusp,
app-genkernel/splashutils which places the tarballs and builds script at the
correct locations.

If you do this, people may add whatever they wish into their initramfs in a
proper way.

But until then, adding a new package is a task only you can do to your
satisfaction.

Forgot to mention that as packages builds them selves genkernel should also
install their output to common root, so libraries may be found. For example,
compiling with splashutils or libgcrypt libraries.

(In reply to comment #33)
> If you want genkernel to be usable, you should rewrite it to be modular.

This is exactly our plan with 3.5's release.

Half a year later and genkernel still does not support software suspend -- even
though the solution has been in this bugreport a year.

Could someone please add the patch to genkernel? It's annoying to have to do it
manually every time I upgrade to a new kernel (even though I've made a shell
script which does it).

Alon Bar-Lev has retired for very good reasons (bug 233301 comment 128), Chris
Gianelloni has also retired, so another developer assigned to genkernel suspend
support is desired.

The genkernel package is still being maintained (1) by the same group of
maintainers (2), however the preliminary work is not done on Gentoo
infrastructure. When the new version is ready it will be committed it to the
Gentoo tree.

(1) http://git.wolf31o2.org/gitweb/?p=projs/genkernel.git;a=summary
(2) wolf31o2 - retired Gentoo developer, agaffney - current Gentoo developer,
robbat2 - current Gentoo developer

Correct.  As stated before, these patches are not sufficient for inclusion.  It
doesn't matter how long the patch sits here in Bugzilla, it isn't going to
magically become a candidate for inclusion without being reworked.

(In reply to comment #38)
> Correct.  As stated before, these patches are not sufficient for inclusion.  It
> doesn't matter how long the patch sits here in Bugzilla, it isn't going to
> magically become a candidate for inclusion without being reworked.
> 

Does anybody have any idea who is doing the rework? Its a shame that this
support is still not there in genkernel.