=== smb` is now known as smb
=== yofel_ is now known as yofel
=== stefano is now known as Guest75762
[12:09] <henrix> rtg: have you reached my email about the build failures?
[12:21] <rtg> henrix, just responded
[12:22] <henrix> rtg: ack, thanks. i'll check the 3 git trees in a minute
[12:25] <henrix> rtg: ok, they look fine. thanks
=== amitk is now known as amitk-afk
[13:04] <ogra_> rtg, i belibe that kexec hack stuff is for making the kernel work as second stage kernel for some android kexec boot kernel, i think the guy tries to achieve dual boot (without taking into account that the userspace isnt capable of supporting it and the next kernel upgrade will overwrite the kexec loader)
[13:04] <ogra_> *belive
[13:06] <rtg> ogra_, perhaps you should respond thusly on the mailing list.
[13:06] <ogra_> well, lets see what the submitter says
[13:07] <ogra_> i'm not thrilled by having to carry an extra patch for a feature we dont support
[13:07] <rtg> nor am I, hence my questioning of the intent for his patches
[13:09] <ogra_> the only proper way of dual booting i see is to use the recovery partition for the ubuntu bootimg and properly adjust flash-kernel for that, sadly nobody wants to work on that and poeple coming up witgh dual boot stuff come up with something insane like that one ... 
[13:09] <ogra_> well, shrug
[13:17] <herton> rtg, I got a problem with missing firmware when testing the 3.5 stable candidate. The issue is the firmware got removed from linux-firmware, because of being already on our linux-image packages. Not sure if this warrants some change or not for mainline kernels...
[13:17] <rtg> herton, which one?
[13:17] <herton> some firmware was missing for bnx2 on "gonzo" (our lab):
[13:17] <herton> W: Possible missing firmware /lib/firmware/bnx2/bnx2-mips-09-6.2.1b.fw for module bnx2
[13:17] <herton> W: Possible missing firmware /lib/firmware/bnx2/bnx2-mips-06-6.2.3.fw for module bnx2
[13:17] <herton> rtg ^
[13:18] <herton> in my case the missing one was bnx2-mips-09-6.2.1b.fw
[13:18] <rtg> herton, did one of the stable patches update the firmware version ?
[13:18] <herton> rtg, nope, kernel doesn't carry this firmware
[13:18] <apw> herton, but our kernel for Q does ?
[13:18] <herton> apw, yes
[13:18] <apw> commit ?
[13:19] <rtg> apw, herton: its a PXE boot essential file
[13:19] <herton> apw, 23bae1788f8c6f216f0261adb6260f57debbf419
[13:19] <apw> rtg, makes sense, does that mean we have a sauce patch pulling it into the kernle
[13:19] <rtg> apw, likely. I'll have to check
[13:20] <herton> rtg, yeah, I thought it could be the case, so didn't bother very much
[13:20] <herton> but just reporting
[13:20] <pgraner> apw, rtg: any idea about this? http://paste.ubuntu.com/1394421/   hint look around line 1233
[13:20] <rtg> herton, this is vanille 3.5 stable ?
[13:20] <rtg> vanilla*
[13:20] <apw> rtg, seems to be a firware update patch in fact
[13:21] <herton> rtg, yep, we noticed it on the lab because the machine didn't came up (not network), when testing my 3.5 stable update
[13:21] <herton> *no
[13:21] <herton> the dell one which uses bnx2
[13:21] <rtg> herton, this is _our_ quantal kernel then ? WHat changed, or did it never work ?
[13:21] <apw> pgraner, looks like we lost the pcie bus ...
[13:22] <rtg> pgraner, looks kind of bad
[13:22] <pgraner> apw, not quite the drives are still online just readonly
[13:22] <herton> rtg, no, it's not the quantal kernel, it is a stock 3.5 kernel, with my stable update on top (3.5.7.1
[13:22] <pgraner> apw, its a storage cab with 4x 3 TB drives
[13:22] <rtg> herton, ok, that makes sense. there is a reason we carry bnx2 (and bnx2x) in the kernel package.
[13:22] <pgraner> apw, and it suddenly flipped to ro
[13:23] <pgraner> apw, digging around I found that, at the end of the dmesg you'll see where ext4 flipps em
[13:23] <rtg> pgraner, consistent after power cycle?
[13:23] <pgraner> rtg, after alot of disk I/O  i.e. moving/deleting files
[13:24] <pgraner> rtg, its the 2nd time its done it to me
[13:24] <rtg> pgraner, this is sort of what happened on tyler, e.g., going RO after lots of disk errors.
[13:24] <sjanc_> hi,  would you consider enabling CONFIG_NFC_LLCP in ubuntu kernel 3.7 ?
[13:24] <rtg> pgraner, wiggle some cables ?
[13:25] <apw> pgraner, that seems to show a bunch or recovered error on the pci bus i think, then it stops and times out
[13:25] <rtg> sjanc_, email it to the kteam list
[13:25] <pgraner> rtg, I'm going to boot single and fsck the drives and see if the issues go away, if not I guess I'll upgrade to Precise and see how it goes
[13:25] <sjanc_> rtg: ok
[13:26] <rtg> pgraner, this is your everyday RAID set, right ?
[13:26] <pgraner> rtg, yea, it gets pounded heavy, is a md raid0 set
[13:26] <rtg> pgraner, since its external I'd have a close look at cabling
[13:26] <herton> rtg, ok, just wanted to confirm that (needed on main kernel due to pxe). I know that also linux-firmware was stripped to save space, and the firmware needed was removed from it. It makes testing not possible on the machine on the lab needing it, since we don't carry anymore the firmware also on linux-firmware. But I can live with one machine not being able to do testing for mainline/stock kernels.
[13:26] <pgraner> rtg, ack
[13:27] <rtg> herton, ack
[13:41] <rtg> ogra_, well, there you have it: https://lists.ubuntu.com/archives/kernel-team/2012-November/023407.html
[13:41] <ogra_> yeah
[13:41]  * ogra_ is already looking at the xda thread
[13:42] <ogra_> "So what does the MultiROM does?
[13:42] <ogra_> It acts as the boot manager, it manages status of device - what ROM is currently in /data, which boot.img is actually in boot partition. It changes android *.rc files so that they do not mount /system, /data and /cache by themselves."
[13:42] <ogra_> oh my, i guess they would try to do the same in ubuntu then too
[13:43] <rtg> ogra_, I assume we'd only do this for raring ? the kernel and user space mods I mean.
[13:43] <ogra_> its a 14.04 thing
[13:43]  * henrix_ -> late lunch
[13:43] <ogra_> but i'm not sure we'll stay with nexus7 for 13.10
[13:44] <rtg> ogra_, you mean _after_ 13.10, right ?
[13:44] <ogra_> essentially i would like to leave the images alive as long as we're not short on image builder resources even beyond 14.04
[13:44] <ogra_> rtg, nope, i mean *for* :)
[13:45] <ogra_> we might switch to another device for 13.10 
[13:45] <rtg> ogra_, um, I thought we were committed  to N7 for at _least_ 13.10, but now I realize I'm think 13.04.
[13:45] <rtg> ok, I get it
[13:45] <ogra_> we will release 13.04 for the nexus
[13:46] <rtg> minor dislexia
[13:46] <ogra_> we might switch to new hw after that
[13:46] <rtg> agreed
[13:47] <rtg> ogra_, so the user space hacks to support dual boot will take a bit of work ?
[13:47] <ogra_> surely a change in how flash-kernel handles kernel updates
[13:47] <ogra_> (or initrd)
[13:48] <ogra_> in any case i wouldnt go for that kexec method since it changes userspace from initrd apparently and if they do that on android i would expect that this will have to happen on ubuntu too
[13:49] <ogra_> "2. Multi-booting ubuntu
[13:49] <ogra_> This is a bit different. First, ubuntu's boot.img is flashed and device is rebooted. Then, I have to move all folders in /data except "media" somewhere else, and move Ubuntu's root into /data. This is very dangerous and hacky, but I cannot just mount -o bind the ubuntu folder, because it has it's own init and would remount it again."
[13:49] <ogra_> lovely
[13:49] <rtg> egads
[13:50] <ogra_> so lets just skip upstart altogether :P
[13:50] <rtg> :)
[13:51] <rtg> ogra_, I might be inclined to carry the kernel patch if it is truly benign, but not until after I get janimo's review. I don't think the user space mods will ever make it.
[13:51] <ogra_> yeah
[13:52] <ogra_> adding kexec support surely isnt bad if it doesnt influence any nrmal features
[13:54] <janimo> rtg, ogra-cb I blame Pan for not sending out my email yesterday as an answer to that patch
[13:54] <janimo> it was not a review, more like, 'does it depend on user space patches, and why should this be a nexus7 only patch as opposed to other-ARM too or Ubuntu SAUCE"
[13:55] <ogra_> well, it seems to heavily depend on userspace changes according to the forum
[13:56] <ogra_> (to use it)
[13:56] <janimo> ogra_, right that's why I asked
[13:56] <janimo> but my mail is not sent out
[13:56] <ogra_> but as long as it not breaks anything 
[13:57] <ogra_> (when not using it i mean)
[13:57] <janimo> it's not the asm that looks intimidating, but I don't know the details of very early boot to know what this could endanger
[13:57] <janimo> but still it looks just fine
[13:57] <janimo> small non-intrusive
[14:06] <rtg> janimo, shall I expect to see your email  response soon ?
[14:08] <janimo> rtg, yes, I'll resend it
[14:17] <apw> rtg, could it be caught in the approval queue ?
[14:18] <janimo> apw, if it's the mail you're asking it is likely on my side. I switched to Pan to read newsgroups months ago, but only now had to send one
[14:18] <rtg> apw, it wasn't there first thing. I'll check again.
[14:19] <janimo> it briefly popped up some errorish msg which I ignored then but apparently the mail is gone 
[14:19] <rtg> apw, nope, only one email in the moderator queue
=== amitk-afk is now known as amitk
[15:30]  * ppisati goes out for a bit
[16:07] <joaquin> Hello everyone! I have an issue with my Laptop when I use Ubuntu, it gets too hot!
[16:08] <joaquin> I think it's a Kernel issue, but I don't know where to ask, here? or to the Kernel developers?
[16:08] <apw> joaquin, have you filed a bug with all the details?
[16:08] <apw> and how hot is "too"
[16:09] <joaquin> There is a bug a launchpad https://bugs.launchpad.net/ubuntu/+source/linux/+bug/763477 but the bug at bugzila.kernel.org is closed due to inactivity
[16:09] <ubot2> Launchpad bug 763477 in linux (Ubuntu) "lenovo y560 overheat. no /proc/acpi/fan" [Undecided,Confirmed]
[16:09] <apw> seems to be open to me
[16:10] <joaquin> apw, at launchpad is open, but at bugzilla.kernel.org is closed
[16:11] <apw> joaquin, so the fan interface not appearing does not mean much as the bios is responsible for contorlling it anyhow
[16:11] <apw> joaquin, just how hot does the machine get
[16:11] <rtg> apw, Fetching omap(armhf)...extracting linux-image...GCC: (Ubuntu/Linaro 4.7.2-11ubuntu1) 4.7.2...done.
[16:11] <rtg> Fetching generic(amd64)...extracting linux-image linux-image-extra...GCC: (Ubuntu/Linaro 4.7.2-12ubuntu1) 4.7.2...done.
[16:11] <rtg> Fetching generic(i386)...extracting linux-image linux-image-extra...GCC: (Ubuntu/Linaro 4.7.2-12ubuntu1) 4.7.2...done.
[16:11] <rtg> WARNING: inconsistant compiler versions detected
[16:12] <joaquin> the fun work at full speed all the time, it reaced 78-80 C degrees
[16:12] <rtg> apw, did we just straddle a compiler change ?
[16:12] <apw> rtg, oh well, its during devel and not a milestone so ... *shrug*
[16:12] <apw> looks like it indeed -11 -> -12
[16:13] <apw> joaquin, so with the fan at full it overheats ... so the bios is controlling the fan
[16:13] <apw> vanhoof, have we had a lenovo y560 pass through our hands at all ?
[16:14] <joaquin> apw, what does it mean that the bios is controlling the fun?
[16:14] <apw> janimo, on which release/kernel version does this behaviour exhibit and which (if any) was it ok
[16:15] <apw> joaquin, normally linux has no controll over fans, if the fans are changing then the bios is doing something, it is seeing the heat and increasing fan speed to compensate
[16:16] <joaquin> apw, OK, but the reason it's getting to hot, could it be a Kernel issue?
[16:17] <apw> janimo, well it could be possible, we could be upsetting something in the bios during initialisation
[16:17] <herton> apw, I think you can commit that fakeroot fix to mainline-build-one
[16:17] <apw> joaquin, then again it cuold just be a bios bug, and windows never could drive the machine hard enough to trigger the issue
[16:17] <apw> herton, did i not ?
[16:17] <herton> apw, not yet :)
[16:19] <apw> herton, done
[16:20] <herton> apw, pulled it's here now, thanks
[16:20] <joaquin> OK, so what can I do?
[16:21] <apw> joaquin, well we need to try and eliminate some things.  if the machine has windows on you could see if windows has the same issue
[16:22] <apw> if so its BIOS and we can do little
[16:22] <apw> joaquin, if it used to work on an older Ubuntu, working out the latest one it was ok on/first one it is not ok on would help
[16:22] <apw> joaquin, as we have had lenovos where the heatpipes have dried up and the issue was h/w just age
[16:24] <joaquin> apw, with windows it works fine, no problem at all
[16:25] <apw> janimo, and what temperature does it go up to if you run it hard
[16:25] <apw> (in windows)
[16:25] <apw> and what temperature when idle
[16:25] <apw> and the same for ubuntu, and you still have not told me which release you are running even
[16:25] <joaquin> Sorry, Ubuntu 12.10 64bits
[16:26] <apw> have you run any older Ubuntu's on this machine
[16:26]  * apw orders up some teeth to save the effort of pulling them
[16:27] <joaquin> apw, no, I only used ubuntu 12.10
[16:27] <apw> jsalisbury, yo ... i think i have a candidate for a 'rough bisect' for you :)
[16:28] <joaquin> apw, in responde to a previous question, with some games Windows also ges hot, but I do not know the temperature, cos I never meassured
[16:28] <jsalisbury> apw, cool, I like it rough
[16:28] <jsalisbury> apw, bisects that is ;-)
[16:28] <apw> jsalisbury, joaquin here could do with testing out like a P kernel or somethign to see if it this heat problem is new
[16:29] <apw> joaquin, so is this "getting hot" when the machine is idle in Ubuntu or only when busy
[16:29] <joaquin> apw, iddle
[16:30] <apw> jsalisbury, might you be able to help joaquin test an older kernel for me
[16:32] <cking> apw, that lenovo has Nvidia graphics, I suspect that's why it's getting hot
[16:32] <joaquin> cking, apw, no NVIDIA, it's an older model with ATI RADEON
[16:33] <jsalisbury> joaquin, are you the original reporter of bug 763477 ?
[16:33] <ubot2> Launchpad bug 763477 in linux (Ubuntu) "lenovo y560 overheat. no /proc/acpi/fan" [Undecided,Confirmed] https://launchpad.net/bugs/763477
[16:33] <joaquin> jsalisbury, no
[16:34] <apw> cking, ahh could indeed be the GPU not being clocked well .. sigh
[16:34] <jsalisbury> joaquin, ok.  It's probably best for you to open a new bug, so we have all your hardware details
[16:34] <sforshee> the open source radeon driver is pretty terrible at power management, so it would likely contribute
[16:35] <jsalisbury> joaquin, that bug could have similar symptoms, but be completely different if you have different hardware
[16:35] <jsalisbury> joaquin, if you open a new bug, I can work through this with you in the bug, that way no information is lost and others can search for it.
[16:36] <joaquin> jsalisbury, OK, I'll open a new bug tonight (I'm at work right now)
[16:36] <cking> hrm, that bug lists VGA compatible controller [0300]: nVidia Corporation GT216 [GeForce GT 240M] [10de:0a34] (rev a2) (prog-if 00 [VGA controller])
[16:36] <jsalisbury> joaquin, great.  I review all the new bugs, so I'll keep an eye out for it. 
[16:36] <joaquin> GREAT thanks!
[16:38] <jsalisbury> joaquin, np
[16:41] <apw> joaquin, use 'ubuntu-bug linux' from a terminal window to make sure we get all the basic info
[16:41] <apw> cking, yeah hense a new bug is appropriate
[16:43] <joaquin> apw, that command will create a new bug at launchpad?
[16:43] <apw> joaquin, yep thats the one
[16:44] <apw> and attack lots of nice h/w info etc
[16:44] <joaquin> apw, OK, great, I like the simplicity
[18:13]  * ppisati -> gym
[18:14]  * rtg skulks off for lunch...
=== kamal2 is now known as kamal
[18:38] <bjf> rtg, bug 1084192 while testing your rc7 kernel
[18:38] <ubot2> Launchpad bug 1084192 in linux (Ubuntu) "[regression] symlink and hardlink restrictions default to off" [Undecided,New] https://launchpad.net/bugs/1084192
=== henrix_ is now known as henrix
[18:49]  * henrix -> EOD
[18:50] <rtg> bjf, ack
[18:50] <rtg> I think that was a SAUCE patch that got dropped
[18:54] <jsalisbury> rtg, bjf, I added that bug to the hot list.
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[19:12] <rtg> kees, so I've reverted 561ec64ae67ef25cac8d72bb9c4bfc955edfd415 in Raring in order to address bug #1084192. Are you good with that ?
[19:12] <ubot2> Launchpad bug 1084192 in linux (Ubuntu Raring) "[regression] symlink and hardlink restrictions default to off" [High,In progress] https://launchpad.net/bugs/1084192
[19:17] <kees> rtg: yup! it's exactly the right solution. I hate that we'll have to carry that forever, but I lost a hated battle with linus over it.
[19:17] <sbeattie> rtg: that's excellent.
[19:17] <kees> rtg: I tried to get CONFIGs for it :(
[19:18] <rtg> kees, yeah, I followed that thread, then went on vacation and kind of forgot about it.
[19:18] <kees> I'm pondering introducing a system upstream for kernel builders to be able to set the defaults for the entire sysctl tree at build-time.
[19:18] <mdeslaur> kees: oh! nice!
[19:18] <kees> it'd let us remove all kinds of CONFIGs and satisfy my desires for these kinds of things being definable at build time
[19:18] <sbeattie> ooh. that would be groovy.
[19:19] <rtg> kees, it would certainly reduce the crust we carry in procps.
[19:19] <kees> I have no earthly clue how to actually get it done yet, but it's been bouncing around in my head
[19:19] <rtg> cruft*
[19:19] <kees> rtg: well, procps serves a few purposes -- the main things is for people with stock kernels to get the same important behaviors as an ubuntu kernel where possible.
[19:20] <kees> (and also serves as documentation for many of these settings too)
[19:20] <rtg> kees, I'd have fixed this in procps, but I also have to think about the LTS backport kernels. I'm too lazy to SRU Precise procps.
[19:20] <kees> I actually feel that one of the critical times to have link restrictions available is at early boot.
[19:21] <kees> (i.e. it should be fixed in both places)
[19:22] <rtg> kees, Linus does pint out that "if you have security problems due to link attacks during your early boot sequence, you have bigger problems"
[19:22] <rtg> point*
[19:27] <kees> rtg: I disagree strongly with that, especially when looking at some android vulnerabilities.
[19:27] <kees> rtg: he's a security absolutist, so can't handle the concept of layered security. why risk it, if it's trivially solvable, imo.
[19:28] <rtg> kees, well, I was thinking about procps in the initrd. How could anything get in front of that ?
[19:29] <rtg> obviously taht only applies if you actually _have_ an initrd
[19:29] <kees> procps doesn't run in initrd and yeah, that too
[19:30] <rtg> well anyway, its solved the Ubuntu way for now :)
[19:31] <sbeattie> \o/
[19:32] <rtg> sbeattie, do you think this is important enough to upload soon? otherwise we likely won't until the next -rc (or final).
[19:32] <sbeattie> rtg: it can wait, that's fine.
[19:32] <rtg> sbeattie, ack
[19:35]  * rtg slinks off to get some book learning on IPv6
=== rtg is now known as rtg-afk
=== henrix is now known as henrix_
=== lifeless_ is now known as lifeless
[21:39] <infinity> hggdh: Daily ping, re: backlogged armadaxp verification.
[21:42] <infinity> hggdh: At this point, maybe we'd be better off skipping the current round and bringing in the next set to proposed?
[21:42] <infinity> hggdh: Since the ones in the PPA cover a CVE...
[22:11] <hggdh> infinity: I am currently running (what I hope to be) the first real armada test
[22:11] <hggdh> infinity: so your daily ping came on time :-)
[22:12] <hggdh> infinity: now the only thing I do not know is how long it will take. May be from one to 6 hours per run
[22:15] <infinity> hggdh: Alright.  I'll hold off overwriting those kernels a bit longer, then.
[22:16] <infinity> hggdh: Just want to get all the flavours caught up, and those two are from the last cadence.
[22:17] <hggdh> infinity: I know. Sorry for the delay
[22:37] <hggdh> infinity: I have a problem on the armada. I have quantal-proposed enabled, and apt-get dist-upgrade does not find the kernel version 3.5.0-1605.7, only 3.5.0-1604.6
[22:38] <infinity> hggdh: That was sort of my point...
[22:38] <infinity> hggdh: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068573
[22:38] <ubot2> Launchpad bug 1068573 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1604.6 -proposed tracker" [Medium,In progress]
[22:38] <infinity> hggdh: That's for 3.5.0-1604.6, 3.5.0-1605.7 is still in the PPA because the previous one never got verified/released.
[22:39] <infinity> hggdh: So, should we just skip the two old ones and push forward with the PPA ones?
[22:40] <hggdh> infinity: ah, this bug is not showing in the kernel SRU workflow
[22:40] <hggdh> bjf: ^
[22:40] <infinity> It shows in http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html
[22:40] <hggdh> but not in http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[22:41] <infinity> And for the out-of-date precise kernel:
[22:41] <infinity> https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068733
[22:41] <ubot2> Launchpad bug 1068733 in linux-armadaxp (Ubuntu Precise) "linux-armadaxp: 3.2.0-1610.15 -proposed tracker" [Undecided,In progress]
[22:41] <bjf> hggdh, ack
[22:42] <infinity> hggdh: Oh, the bug there is that ike/jani inverted the precise/quantal bugs by accident, so they're under the wrong heading in your report.
[22:42] <hggdh> actually, it does appear in the workflow, but it seems quantal and precise are mixed
[22:42] <hggdh> heh
[22:42] <infinity> bjf: Not your bug, really.
[22:42] <bjf> infinity, hggdh lets just drop armadaxp support and that would solve this "problem"
[22:43] <infinity> :P
[22:43] <hggdh> bjf: now that I finally got it (almost) in shape? ;-)
[22:43] <infinity> If we drop x86 support, we'd solve a lot more of our problems.
[22:43] <bjf> infinity, hggdh we probably own 96% of all the armadaxp boards in existance
[22:43] <bjf> infinity, but then i'd be out of a job and that would make my wife "sad"
[22:44] <infinity> bjf: Yeah, but on the bright side, no more tax returns.
[22:44] <hggdh> there is that
[22:44] <bjf> infinity, i didn't say I wouldn't be happy
[22:44] <hggdh> infinity, bjf: well, it is running the correct kernel, then, let's wait a bit and see how it fares
[22:45] <infinity> hggdh: Fancy.  Do you get two machines to do precise and quantal in parallel, or did they only trust you with one? :)
[22:46] <hggdh> infinity: I am absolutely untrusted, so there is only one in the lab
[22:49] <hggdh> infinity: OTOH, I just gave you some kernels to promote (pandas andx86)
[22:51] <infinity> hggdh: The oneiric ones?  Or more still?
[22:51]  * infinity is doing oneiric right now.
[22:54] <hggdh> infinity: pandas -- oneiric, precise and quantal; x86 -- lucid, LTS-oneiric, and precise 
[22:54] <infinity> The flavour ones won't get copied until master is ready.
[22:54] <hggdh> ack
[22:54] <infinity> (But glad they're tested anyway)
[22:56] <infinity> Oh, and x86/precise still needs cert testing.  But that's not your thing. :)
[22:56] <hggdh> infinity: sorry, both oneiric and lts-oneiric are done
[22:57] <infinity> hggdh: Yeah, they're already copied. :)
[22:57] <hggdh> heh