[05:05] <osmosis> i dont understand what this means, http://www.news.com/8301-13580_3-9867657-39.html
[05:17] <osmosis> zul: ping
[05:56] <tjaalton> hmh, resume from hibernate failed, ie. it booted normally and not from the file
[10:45] <cking> xivulon: Hi, I've been looking at your notes for the Wubi issues
[10:46] <xivulon> just added a new one!
[10:46] <xivulon> was waiting for you in fact...
[10:47] <xivulon> let me know if I need to clarify anything
[10:48] <cking> xivulon: I managed to screw up my /home today playing around with this - I was offline for a while sorting my machine out :-(
[10:49] <xivulon> sorry to hear that :(
[10:49] <cking> xivulon: It's all part of the fun :-)
[10:49] <xivulon> You are invited to explain the fun part to my wife...
[10:50] <cking> xivulon: I looked at the notes - the problem is umounting / and then /home - can one actually do this in practice?
[10:50] <cking> xivulon: I was thinking of using pivot_root but I haven't much experience with this, so I am not sure if this a possible way of doing things
[10:50] <xivulon> unmounting is not a problem except that it will be the last thing you can do (without a ramdisk)
[10:51] <xivulon> see my last comment on that
[10:51] <cking> ..but with a ramdisk, one could umount /?
[10:51] <xivulon> I would assume so
[10:51] <xivulon> but I have never tried that
[10:52] <cking> ..me neither. I think we may need some expertise from someone like Colin Watson.
[10:53] <xivulon> eheh...
[10:53] <cking> But I think it will lead to a sane shutdown that will ensure / and /home are flushed and umounted properly
[10:53] <cking> ..otherwise one will always see this kind of corruption of /
[10:54] <cking> if one can do this then the vm dirty hacks are no longer required
[10:54] <xivulon> I'd think that if we could remount /host ro (safely) it would be good enough
[10:55] <xivulon> see my umountroot attachment for that, unfortunately ntfs-3g complains about remounting...
[10:55] <xivulon> cking the vm dirty hacks are still required in case someone hard-reboot
[10:56] <cking> xivulon: yep - true about the hard-reboot - I overlooked that detail.
[10:56] <xivulon> In fact based on user feedback all the problems of fs corruption were due to hard reboots
[10:57] <xivulon> I haven't seen any complaint about fs corruption because of normal reboot
[10:57] <xivulon> I'd guess that remounting root ro + the sysctl hacks is enough in most cases (and maybe some fsck help...)
[10:57] <cking> xivulon: I managed it :-)  I did started removing a huge tree of source and then rebooted - and I got a bit of a mess
[10:58] <xivulon> that is with the sysctl hacks?
[10:59] <xivulon> cking was disconnected
[11:00] <cking> xivulon: what happened there?
[11:00] <cjwatson> there was a netsplit, too
[11:00] <cking> ..a netsplit?
[11:00] <cjwatson> IRC networks consist of many servers, in general, which are connected in a graph; if a pair of servers lose their connection, that's a netsplit
[11:00] <cking> ah.. I am enlightened
[11:00] <cjwatson> which results in the users on the network being effectively partitioned in terms of their ability to talk to each other
[11:01] <xivulon> cking missed replies after my last comment
[11:01] <xivulon> didn't miss cjwatson explanation though :)
[11:01] <cking> xivulon: yep, I kind of missed the last few lines
[11:02] <cjwatson> 10:56 <cjwatson> cking: I think you misunderstand the order of events slightly, though
[11:02] <cjwatson> 10:56 <cjwatson> cking: the NTFS filesystem in question is actually /host, not /home
[11:02] <cjwatson> 10:56 <cjwatson> cking: and Wubi is a little odd here - the way it works is that / is actually a loop-mounted filesystem *on top of* an NTFS filesystem that is then moved to /host
[11:02] <cjwatson> 10:57 <cjwatson> cking: so the filesystems are the other way round from what you'd expect
[11:02] <cjwatson> in case that was missed
[11:02] <cking> thanks
[11:03] <cking> .. I keep on writing /home when I mean /host - it's a constant brain type of mine
[11:03] <cking> ^type^typo.  I need coffee.
[11:03] <xivulon> the crux though is that /host cannot be remounted r/o IMHO
[11:03] <cjwatson> I suspect that you cannot actually unmount / and then expect to be able to unmount /host
[11:03] <cjwatson> because you won't have a reference to /host any more
[11:03] <xivulon> cking did you experience fs corruption when rebooting (rc6.d) and with the sysctl hacks in place?
[11:04] <cjwatson> you'd have to move all the mount points around, and frankly, I do not think that is a viable approach at this point
[11:04] <xivulon> was /host to be corrupted or / and did corruption involve the journal?
[11:04] <cking> xivulon: yep
[11:04] <cjwatson> we need something pretty simple and foolproof, and playing Tetris with your mount points isn't that :)
[11:05] <cking> cjwatson: I'm not sure if there is a solution that is simple and foolproof.
[11:05] <xivulon> not sure if we can try fixing /host (ntfs-3g) remount
[11:06] <cking> xivulon: one could do that - but wasn't there a big risk that  NTFS could get corrupted?
[11:06] <xivulon> that was my understanding from last szaka comment
[11:07] <xivulon> did ask him some more info by mail but he didn't reply
[11:07] <cjwatson> if the NTFS filesystem is never remounted read-only or unmounted (as is the case at the moment, I understand), why does that affect the kernel's ability to writeback changes to the ext3 /?
[11:07] <cjwatson> or rather, what is breaking the kernel's ability to writeback changes?
[11:08] <cking> cjwatson: from the way I see it, we can either force disk writebacks using the vm flush hacks - but this does not necessarily guarantee a fulling sync'd fs.. or..
[11:08] <cjwatson> IIRC the kernel always syncs just before reboot
[11:09] <cking> .. we can fool around with the umounting.  The former may help when systems power down in an uncontrolled way, the latter makes sure the filesystems are coherently umounted at shutdown
[11:10] <cking> cjwatson: true.
[11:10] <xivulon> ...and yet you ended up with a corrupted fs
[11:10] <cking> ..my concern is that the /host is not being properly written back to.
[11:12] <cking> I believe /host is not being umounted which worries me.
[11:12] <xivulon> it certainly is not
[11:12] <xivulon> or you would lose /
[11:12] <xivulon> and hence /sbin/reboot
[11:13] <cjwatson> remounting it read-only ought to be as good as unmounting from the perspective of avoiding corruption, but that's been problematic due to ntfs-3g bugs
[11:14] <xivulon> cking, on a side note, you also suggested using sync mount option on the loopfile, I assume you meant the /host fs
[11:16] <cking> xivulon: yes, if it's possible on ntfs.  The sync is not required on the loop file since it's mounted ro at the shutdown. However, the sync,dirsync and commit=1 could help on power outages I suppose.
[11:17] <xivulon> but isn't host that has to sync automatically? the fact that the loopfile syncs to host does not help if host does not sync to disc, correct?
[11:18] <cking> xivulon: true - yep, it's clear I haven't thought that one through.
[11:20] <cking> xivulon: I suppose the outstanding questions are: can ntfs-3g be fixed in time to enable a ro remount, and if so, can one avoid NTFS corruption?
[11:21] <cking> xivulon: ..also, do the vm dirty tweaks do anything useful in reality?
[11:21] <xivulon> yes, that would be the best avenue, I had that bug open for quite some time...
[11:21] <xivulon> but did not bother too much because had zero bug reports about fs corruption... so far...
[11:22] <cking> xivulon: ..thirdly.. does the ntfs-3g support sync and commit=1 or are these only applicable to ext3?
[11:22] <xivulon> cking I know that in wubi 7.04 we did not have them we had more reports about people having fs corruption after hard reboot
[11:22] <xivulon> that is based on a completely subjective measure
[11:22] <cking> xivulon: ..yes but it's comforting to hear this.
[11:22] <xivulon> might be due to better user education also (added a few faqs)
[11:23] <xivulon> I would not know how to test that in an objective way
[11:23] <xivulon> for ntfs-3g we would need to ask szaka
[11:23] <xivulon> I know nothing about its internals
[11:25] <xivulon> but if you see #186117 that didn't go too far
[11:25] <cking> xivulon: that's the best path to take if he is available.
[11:26] <cking> xivulon: Meanwhile I will google around to see if there are any other ways to make sure the filesystem is flushed other than using the vm dirty hacks,
[11:27] <cking> ..one never knows if there is something better.
[11:30] <xivulon> cjwatson as plan b couldn't we still try to go for /sbin/reboot on ramdisk (but leaving current behaviour whenver that is not strcilt needed)?
[11:35] <cjwatson> it's very risky, you need to copy over any libraries it needs as well; it needs /proc and /dev; and who knows what else you might have to play catch-up with
[11:35] <cjwatson> I have a suspicion changing ntfs-3g would be safer
[11:35] <xivulon> cking still other route might be to ensure that ntfs-3g does actually empy his cache whenever the sync command is issued. I think.
[11:36] <xivulon> if / is ro and synced properly, rebooting should not be too drastic even if /host is rw
[11:36] <cking> xivulon: an extra sync can only help
[11:37] <cking> xivulon: I recall that twiddle with (one of) the vm dirty options may also forces a sync.
[11:37] <xivulon> cking you might want to try to reproduce fs corruption with new initramfs + sysctl + umountroot, as per thread
[11:38] <xivulon> as per bug attachments...
[11:38] <cking> yep. Will do.
[11:38]  * cking need to reboot to try this.. rebooting ..
[11:38] <xivulon> FS corruption of the host is probably far more important than the guest corruption. And for the latter I'd focus on journal loss.
[11:41] <cking> xivulon: NTFS + ntfs-3g's behaviour is not really well know in this scenario. That's my concern. I'd hate too see Wubi users hacked off because their NTFS is screwed up
[11:42] <cking> ..so sync sync sync and then a fixed ntfs-3g mount -o remount may be the best way forward.
[11:43] <cking> ..one can never sync enough.
[11:43] <cking> :-)
[11:43] <xivulon> only confort I can give you is that with almost 1 million downloads all the ntfs corruption claims were due to hard reboots. And I have no evidence that ntfs-3g makes things any worse
[11:43] <cking> 1 million(!!)
[11:43] <xivulon> since you would still risk fs corruption when hard rebooting
[11:46] <xivulon> I discussed that with szaka more than once, and he always asserted that the chances of fs corruption are not made any worse by the use of ntfs-3g
[11:47] <xivulon> yep we are close to a million
[11:48] <xivulon> but of course now that wubi is official, host corruption would make very bad press...
[11:55] <cking> cking: rebooting ..
[12:36] <xivulon> lamont: I did do some basic tests yesterday for #206113 and commented on the bug let me know if you need anything else
[13:30] <lamont> my most recent dist-upgrade (-15.27 et al) killed sound...
[13:35] <amitk> lamont: does it also lead to a long boot time?
[13:35] <lamont> dunno
[13:35] <lamont> I wasn't watching...
[13:35] <lamont> and actually, I think it's related to session management, not to the kernel upgrade...
[13:36] <amitk> lamont: hmm.. how so?
[13:36] <lamont> I think I saw this before, now I just need to remember how I got told to fix it...
[13:40] <lamont> [   54.214217] iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0xf860)
[13:41] <lamont> not seeing where I figured it out before, istr it was simply muted hard somewhere
[13:41]  * lamont afk for about 15 min
[14:12] <lamont> amitk: so I take back what I said... let's blame the kernel for now... debugging ideas?
[14:17] <amitk> lamont: sound-applet reports no mixers?
[14:18] <xivulon> lamont, in case you missed it, did the tests you asked, see comment in 206113
[14:18] <lamont> xivulon: yeah - thanks
[14:18] <xivulon> let me know if you need anything else
[14:18] <lamont> sure
[14:19] <lamont> amitk: bringing the system fully current to now and rebooting (new lrm), and then I think I'll need something more basic in the way of instructions...
[14:19]  * lamont iz sound neub
[14:28] <lamont> amitk: anything I should tweak before I reboot
[14:28] <lamont> ?
[14:28] <lamont> Open Volume Control --> No volume control GStreamer plugins and/or devices found
[14:31] <amitk> lamont: just note if you reboot takes longer than usual
[14:32] <pwnguin> is -16 known to not boot? i cant find a report on it
[14:33] <rtg> pwnguin: on what? -16 is still not widely distributed as meta was just uploaded a few minutes ago.
[14:33] <pwnguin> ah
[14:34] <pwnguin> on my laptop, toshiba tecra m7. -generic
[14:34] <rtg> pwnguin: is this a regression?
[14:34] <pwnguin> yea
[14:34] <pwnguin> on the other hand, i dont have -meta
[14:34] <rtg> from -15 to -16?
[14:34] <pwnguin> yep
[14:34] <pwnguin> im on -15 right now
[14:34] <rtg> pwnguin: meta won't affect the boot.
[14:35] <pwnguin> rtg: i'd feel better about not missing part of the package with meta though
[14:35] <rtg> pwnguin: at what point in the boot process does it stop?
[14:35] <pwnguin> after turning off the graphical boot, hardware detection is the last message
[14:36] <pwnguin> i booted into recovery mode
[14:36] <pwnguin> and
[14:36] <pwnguin> the last two modules giving messages were iwl and cs
[14:36] <amitk> pwnguin, wait for a few minutes
[14:36] <amitk> it should continue booting
[14:36] <lamont> unsurprisingly, that didn't fix either of my issues
[14:36] <amitk> rtg: I see this too, I was woring on Classmate when I hit this
[14:37] <pwnguin> a few minutes?
[14:37] <pwnguin> thats a hell of a timeout ;)
[14:37] <amitk> pwnguin: I am trying to determine if you are seeing the same problem as me ;)
[14:37] <pwnguin> well
[14:37] <pwnguin> lemme reboot it i guess
[14:37] <rtg> amitk: everything since -15 has been custom binary, except for the mmc timeout.
[14:37] <pwnguin> heh
[14:38] <pwnguin> the mmc timeout
[14:38] <pwnguin> interesting; i upgraded because i wanted to test that
[14:38] <amitk> rtg: yeah.. I saw the changelog, and even the mmc timeout was 10ms, not 2 minutes
[14:38] <rtg> better go through the git log and make sure.
[14:38] <smb_tp> It is if it was 2ms before and not 2min
[14:39] <rtg> brb, rebooting after upgrade.
[14:39] <smb_tp> It was just a one liner changing mmc_delay from 2 to 10
[14:39] <pwnguin> its supposed to be ms
[14:39] <pwnguin> it could be seconds
[14:39] <pwnguin> i never found that particular function
[14:40] <smb_tp> It is an inline function in one of the headers
[14:40] <amitk> core.h:static inline void mmc_delay(unsigned int ms)
[14:41] <amitk> pwnguin: can you confirm that the boot contineus after a few minutes? albeit w/o sound
[14:41] <pwnguin> on a related note, the sdhci developer's asked me to retry with MMC_DEBUG
[14:41] <pwnguin> amitk: not yet
[14:41] <pwnguin> give it a minute or so
[14:42] <amitk> pwnguin: just wait a few more please, that'll tell me that it is reproducible behaviour
[14:43] <amitk> pwnguin: What does Alt+F1 show?
[14:43] <pwnguin> doh
[14:43] <pwnguin> nothing much
[14:43] <amitk> F2?
[14:43] <amitk> I forget which one it is
[14:43] <pwnguin> kinit: no resume, doing normal boot
[14:43] <lamont> 8
[14:43] <pwnguin> loading manual drivers
[14:43] <pwnguin> i forgot to set verbose
[14:44] <amitk> pwnguin: care to disable "quiet splash" in the kernel cmdline on the next boot?
[14:44] <pwnguin> indeed
[14:44] <amitk> thanks
[14:45] <amitk> hmm. now to see what changed in lum
[14:45] <lamont> amitk: my boot seems to proceed at normal-ish pace
[14:46] <pwnguin> lets see. theres hda_codec at 30 saying it cant find my audio. iwl at 31 saying there's 11 tunable channels for bg, 13 for a, and several I/O port probes for module cs
[14:46] <amitk> rtg: 607ab6f78fa5d51b4dab72d218455a858c499c6f in lum
[14:47] <pwnguin> if you want logs, im afraid i dont have a serial port =(
[14:47] <amitk> rtg: smb_tp: that commit looks like it will affect every sound driver
[14:47] <rtg> amitk: is that the culprit?
[14:48] <pwnguin> huzah
[14:48] <pwnguin> fail
[14:48] <amitk> rtg: I am going to revert and try on the classmate
[14:49] <rtg> amitk: just rename snd_core to something, then try.
[14:49] <pwnguin> amitk: after 2 minutes of no activity, it wrote some new text
[14:50] <pwnguin> it seems to still be stuck though
[14:50] <amitk> pwnguin: I'll bet it'll boot eventually :)
[14:52] <smb_tp> Hm, might be bad if register all will eventually call register...
[14:52] <pwnguin> heh
[14:52] <pwnguin> well, it doesn't seem to be spinning
[14:52] <amitk> rtg: crap.. just realised soundcore.ko comes from kernel, not ubuntu directory in /lib/modules :)
[14:53] <rtg> amitk: I was just looking to see where that file gets compiled.
[14:54] <amitk> rtg: that seems to improve things a lot
[14:54] <amitk> I'm going to revert the commit if you have no objections
[14:55] <rtg> amitk: can tyou rebuild lum with that patch reverted?
[14:55] <amitk> rtg: yeah.. doing that now
[14:55] <xivulon> cking in your tests did you try mounting /host with sync & co?
[14:55] <rtg> amitk: removing soundcore indicates it is the sound sub-system, but isn't proof positive.
[14:56] <xivulon> would it help to have 1 sec sleep before rebooting?
[14:58] <cking> xivulon: I couldn't see to create any filesystem corruptions whatsoever.
[14:58] <rtg> amitk: I started a new release in LUM
[14:58] <cking> xivulon: what is interesting is looking at /proc/vmstat | grep dirty
[14:59] <amitk> rtg: I've been seeing this since morning, but thought it was due to my usb patch for classmate suspend
[14:59] <cking> ..even with the agressive vm dirty tweaks the data is not getting written back that quickly
[15:00] <cking> ..one can see the writes by doing a bit of an ugly hack:  sudo echo 1 > /proc/sys/vm/block_dump  and looking at dmesg
[15:00] <amitk> pwnguin: you are running -15?
[15:00] <pwnguin> no
[15:01] <pwnguin> -16
[15:01] <amitk> you compiled yourself?
[15:01] <pwnguin> nope =(
[15:01] <cking> xivulon: ..even with the most aggressive vm dirty settings one can observe writes being flushed a few seconds after the initial write...
[15:02] <pwnguin> i noticed -16 in the repos
[15:02] <amitk> rtg: ^^
[15:02] <cking> xivulon: ..which could explain why some users are seeing corruptions even when we are forcing writebacks to occur as soon as possible.
[15:02] <rtg> amitk: I saw that.
[15:02] <cking> xivulon: ..because ASAP is not really that ASAP :-(
[15:02] <xivulon> hmm
[15:02] <rtg> pwnguin: do you also have -16 LUM installed?
[15:03] <xivulon> is that an ntfs-3g / fuse implementation issue?
[15:03] <amitk> I only see -16 LRM, no LUM or kernel
[15:03] <xivulon> cking what is your suggestion based on that?
[15:03] <pwnguin> well my mirror wins i guess
[15:03] <amitk> ohh and I see -16 linux-libc-dev
[15:03] <cking> xivulon: no. I initially thought it was all the layering in the ntfs-3g, fuse, loopback etc.. but one can observe this on a normally mounted filesystem.
[15:04] <smb_tp> amitk: Got that installed already
[15:04] <xivulon> when you say "couldn't see to create any filesystem corruptions whatsoever" do you mean you couldn't create corruptions or that you were simply not testing that
[15:04] <xivulon> so it's a kernel issue...
[15:04] <cking> xivulon: so it appears what the kernel documentation says and what is actually happening differ.
[15:05] <xivulon> not to pleased to hear that
[15:05] <cking> xivulon: as for the corruptions: I hammered the system with loads of creat's and unlinks and forced a reboot and everything was OK...
[15:05] <amitk> smb_tp: no sideeffects?
[15:06] <cking> xivulon: and also I repeated this several times and pulled the plug and got the normal fsck'ing fixes but I did not get any major failures
[15:06] <xivulon> cking that is in line with lack of reports on the matter. was this with the new initramfs / umountroot or in a plain vanilla case?
[15:06] <cking> xivulon: it was using the new scripts from the bug report
[15:07] <smb_tp> amitk: None I noted, but I guess this only affects programs comiled on that host. and I didn't compile any user-space
[15:07] <xivulon> well that is good news
[15:07] <xivulon> for once...
[15:07] <amitk> rebooting now....
[15:07] <cking> xivulon: I left some notes on the bug report so one can see what I mean about the write backs being a little bit too lazy for my liking
[15:08] <xivulon> could it be that the mount options (sync & co) interfere with sysctl?
[15:09] <cking> xivulon: no. when I saw the less than perfect performance I tried it on a vanilla configuration to do a sanity check - i.e. no insane sync,dirsync,commit=1 flags.
[15:09] <xivulon> cking: would you suggest we keep mount options and/or sysctl settings?
[15:10] <cking> ..and I saw the same "problem".  We are probably seeing the pdflush pushing out all it can before it gets rescheduled or something. I need to shove a whole load of debug in to see why it is a little less aggressive than expecyed
[15:11] <xivulon> so I guess you'll need some more time for the tests then we can reassess
[15:11] <xivulon> I would not think though that in the light of what you say the new initrd/umountroot should make much difference
[15:11] <cking> xivulon: well, closer inspection shows that the mount options are ignored by ntfs - so we just fall back to the sysctl's.
[15:11] <xivulon> since /host is still not remounted ro (at least in my tests)
[15:12] <cking> xivulon: agreed
[15:13] <cking> xivulon: I basically need to figure out why pdflush is not being totally true to the vm dirty knobs
[15:13] <amitk> rtg: revert works and sound is back
[15:13] <xivulon> sure, keep in mind that we'll need to do a feature freeze exception for each change, if something is not strictly necesseray (proven to be so) we should skip it
[15:13] <amitk> rtg: I've pushed the revert to lum
[15:13] <xivulon> that applies to initrd, sysctl and umountroot
[15:15] <cking> xivulon: yep. Well I think the real issue is that we want to flush blocks out asap and I need to figure out why the pdflush does not quite match the behaviour as described on the lid
[15:15] <cking> ^on the lid^in the docs^
[15:15] <cking> ..and then I'm a little worried about tinkering with the pdflush daemon this late in a code freeze :-(
[15:16] <cking> ..but it could be something obvious once I've got my head around it.
[15:17] <cking> xivulon: any ideas on anything else we could do?
[15:17] <xivulon> not really
[15:21] <cking> xivulon: OK I investigate pdflush and the vm dirty knobs
[15:22] <cking> s/I/I will/
[15:36] <xivulon> cking, maybe doublecheck whether initramfs/umountroot make any difference
[15:38] <cking> xivulon: I think most productive thing is to see if we can get pdflush to really do aggressive writebacks to limit loopbacke'd fs corruption
[15:39] <cking> xivulon: I hope it is something obvious
[15:40] <xivulon> agree
[15:41] <xivulon> by the way, wouldn't something like that be relevant also for vm?
[15:43] <xivulon> that too is a nested fs and hence subject to the same vulnerabilities
[15:43] <xivulon> I am surprised I am the only one running into this
[15:51] <xivulon> at least for the power-loss part (normal reboot is very different of course)
[16:20] <rtg> amitk: I verified the cx88 revert. it definitely makes a difference.
[16:21] <amitk> rtg: half the patch was mutexes, it had to ;)
[16:21] <rtg> amitk: I looked through it when I applied it. everything looked balanced, _and_ it came from upstream.
[16:22] <amitk> rtg: I guess it needs another part from upstream
[16:23] <rtg> amitk: could be. now I'm f\gonna have to figure out what the real cx88 crash was .
[17:33] <nxvl> i have just updated to -16 kernel and it hangs
[17:34] <rtg> nxvl: LUM is currently percolating with a fix. wait for linux-ubuntu-modules-2.6.24 16.22
[17:34] <nxvl> ok
[17:34] <nxvl> so it was a know issue?
[17:34] <pwnguin> heh
[17:34] <pwnguin> only recently
[17:35] <rtg> nxvl: it became a known issue fairly quickly.
[17:35] <nxvl> yes of course it has no more than one day uploaded
[17:35] <nxvl> but if you already have what you need to fix it
[17:35] <nxvl> i'm ok
[17:35] <pwnguin> 16.22?
[17:35] <rtg> https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-16.22
[17:36] <pwnguin> i have linux-headers at 16.30
[17:36] <pwnguin> is that . not kept in sync?
[17:37] <rtg> pwnguin: The LUM package version is not related to the headers package version (except for the ABI number)
[17:38] <pwnguin> ok
[17:39] <nxvl> so, fix is released and we only need to wait until it reach the mirrors?
[17:39] <rtg> yep
[17:39] <pwnguin> not booting is a fairly high priority bug ;)
[17:40] <pwnguin> espcially when someone like amitk and reproduce it
[17:41] <nxvl> ok thanks!
[17:58] <nxvl> btw
[17:58] <nxvl> i forgot to report something else
[17:58] <nxvl> i hav a lenovo T61
[17:58] <nxvl> with hotplug DVD-rom
[17:59] <nxvl> but when iunplug it the system hangs
[18:40] <mario_limonciell> rtg, i was thinking this morning, could you see to it that LBM is shipped as available on the DVD image to install?
[18:40] <mario_limonciell> in it's pool directory or similar
[18:41] <rtg> mario_limonciell: thats a question for cjwatson
[18:42] <mario_limonciell> okay i'll ask him
[18:52] <crimsun> rtg: are there are traces from the bootup problems (WRT #212960 in l-u-m -16)?
[18:52] <crimsun> amitk: ^
[18:52] <crimsun> are there, sheesh.  can't type.
[18:53] <rtg> crimsun: there don't seem to be. I'm looking at it now. Frank's original patch works, but the one Leann attached does not (it locks up)
[18:53] <rtg> crimsun: I'm trying to decide if it is really the root of the problem.
[18:54] <crimsun> rtg: I don't think it is, after closer inspection.
[18:54] <rtg> crimsun: can there really be that much list activity going on? Or is the use of mutexes just jostling the thread timing.
[18:55] <rtg> crimsun: as far as I can remember, PCI device discovery is single threaded, right?
[19:09] <crimsun> rtg: there shouldn't be much activity, and it is single-threaded IIRC.
[19:15] <rtg> crimsun: that's what I thought. I'm not sure Frank's analysis is correct (about the lists getting corrupted).
[19:17] <pepie34> I can't catch an AP with my AR5008 madwifi card since the two last -14 and -15 kernel
[19:17] <pepie34> still no problem with the -12 kernel and the same userland as the others new
[19:22] <mario_limonciell> hm what is creating the symlink between cpufreq directories on two core systems initially?
[19:22] <mario_limonciell> i had thought it'd be powernowd doing it, but I don't see evidence of that
[19:23] <pepie34> any idea ? for the regression on madwifi
[19:23] <smb_tp> rtg: Hm, I might be stupid but in the report snd_card_register_all is called and later snd_device_new. If thats both in core, how should that work?
[19:24] <pepie34> I should be more precise as it is a AR5XX8 chipset i had to use the madwifi svn and not the module in the restricted package
[19:24] <pepie34> it works fine on feisty/gutsy and hardy since the 2.6.24-12 kernel
[19:29] <rtg> smb_tp: it clearly must work because its not a problem for everyone. I'm still looking at the cx88 driver. However, right now its lunch time.
[19:30] <rtg> pepie34: you are on your own 'cause I haven't pulled the madwifi branch that supports the AR5008. I've been waiting until they make it official.
[19:30] <smb_tp> rtg: Enjoy. I was just thinking of the same codepath with mutexes
[19:38] <pepie34> rtg i just want to warn then that since the -14 the madwifi-svn does not work and you will get all the mac user really angry
[19:50] <lamont> amitk: so will this new kernel make my soundz werk>?
[20:24]  * pwnguin does a zomg sd works again dance
[20:24] <pwnguin> rtg: thanks
[20:49] <infinity> lamont: You don't need sound.
[20:49] <lamont> infinity: do too
[20:50] <infinity> lamont: The kernel team disagrees.
[20:54] <rtg> lamont: we've gone out of our way to wreck only _your_ audio support.
[20:55] <lamont> rtg: I feel so much more productive without the noise-canceling music
[20:56] <rtg> lamont: I thought you had audio once upon a time?
[21:23] <sistpoty> hi, can someone please look at the FFe in bug #185634 and give a comment? thanks!
[21:23] <ubotu> Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed] https://launchpad.net/bugs/185634
[23:56] <tjaalton> is there something in -16 which broke nvidia from loading? bug 215778
[23:56] <ubotu> Launchpad bug 215778 in linux-restricted-modules-2.6.24 "2.6.24-16.30 kernel update - nvidia: module license 'NVIDIA' taints kernel" [Undecided,Confirmed] https://launchpad.net/bugs/215778
[23:57] <tjaalton> lrm debdiff looked good, so it shouldn't be due to the dh_strip fix


[07:53] <dholbach> good morning
[09:30] <oSoMoN> nerochiaro, ping
[09:31] <nerochiaro> oSoMoN: hey
[09:31] <oSoMoN> nerochiaro, hey, I looked into your code, and I can confirm you’re hitting bug #1218971
[09:31] <ubot2> Launchpad bug 1218971 in Autopilot Qt Support "QQuickWindow’s contentItem is not accessible" [Medium,In progress] https://launchpad.net/bugs/1218971
[09:32] <oSoMoN> nerochiaro, the dialog calls show() in Component.onCompleted, which reparents it to the root item
[09:32] <oSoMoN> nerochiaro, so your best bet is to work with mzanetti to get the fix for autopilot-qt merged and released
[09:33] <mzanetti> or even better some of the autopilot devs ;)
[09:33] <mzanetti> ah that one
[09:33] <mzanetti> hmm... I wonder what it didn't merge
[09:33] <oSoMoN> there is already a pending MR, which I tested a while ago and it fixed the bug, so it’s only a matter of figuring out why it doesn’t merge anymore
[09:33] <oSoMoN> mzanetti, I commented on the MR, it fails to compile for some reason
[09:34] <JamesTait> Good morning all; happy Pins and Needles Day! :-D
[09:35] <mzanetti> :D
[09:36] <nerochiaro> oSoMoN: mzanetti: looks like you guys might save my bacon once again ;) anything i can do to help ?
[09:37] <mzanetti> not really at the moment
[10:12] <timppa> Hi! Is it possible to create a text file and save it to a specific location in Ubuntu Touch app?
[10:12] <mzanetti> oSoMoN: nerochiaro: seems xpathselect did a rework of the api and it would require autopilot-qt to adjust most of its code :/
[10:12] <oSoMoN> :/
[10:12] <oSoMoN> mzanetti, how much work would that imply?
[10:12] <nerochiaro> mzanetti: that's also probably why autopilot vis is crashing
[10:12] <nerochiaro> it gave xml errors
[10:13] <mzanetti> timppa: yes it is, as long as the specific location is within the allowed paths from apparmor
[10:13] <oSoMoN> mzanetti, who is the maintainer of autopilot-qt these days?
[10:13] <mzanetti> oSoMoN: hmm... dunno. I just tried to do it, but it doesn't stop spitting more error
[10:13] <mzanetti> s
[10:14] <mzanetti> oSoMoN: well. I was it so far, but yesterday I contacted the autopilot devs and we agree that they pick it up again (given that I'm no QE since quite a while now and unity8 has a tendency to keep me quite busy too)
[10:14] <mzanetti> oSoMoN: I told them about the isse that 1.4 hasn't been released to the ppa yet and I think Thomi is looking into that soon
[10:15] <mzanetti> oSoMoN: which probably would imply getting it's api updated
[10:15] <oSoMoN> mzanetti, makes sense, so I should bug Thomi, right?
[10:15] <mzanetti> oSoMoN: please do
[10:15] <oSoMoN> will do for sure :)
[10:15] <mzanetti> thanks
[10:23] <timppa> mzanetti: Is there any documentation regarding the apparmor?
[10:24] <timppa> mzanetti: Or can I add the paths to .json file myself?
[10:26] <mzanetti> timppa: no, you can't add the paths yourself
[10:26] <mzanetti> timppa: I just googled a bit for the docs but couldn't find anything
[10:26] <mzanetti> timppa: basically it is ~/.config/<appid>/
[10:26] <mzanetti> ~/.cache/appId/
[10:27] <mzanetti> timppa: those 2 for sure. probably some few others too. but I don't recall them
[10:31] <mzanetti> popey: do you know about any apparmor docs related to ubuntu touch?
[10:31] <popey> only on the wiki
[10:31] <popey> https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
[10:31] <mzanetti> popey: I couldn't find anywhere what the allowed paths for applications are
[10:33] <mzanetti> ah. here it is
[10:33] <mzanetti> timppa: Specifically: XDG_CACHE_HOME/<APP_PKGNAME>, XDG_RUNTIME_DIR/confined/<APP_PKGNAME>, XDG_DATA_HOME/<APP_PKGNAME> and XDG_CONFIG_HOME/<APP_PKGNAME>
[10:33] <popey> mzanetti: http://developer.ubuntu.com/apps/qml/cookbook/files-and-storage/
[10:36] <timppa> thanks! I think I'll can get going with those
[10:37] <mzanetti> timppa: if you're using Qt, you can use QStandardPaths to get those
[10:38] <timppa> great!
[11:43] <mzanetti> popey: do you know if there are plans for a real app store app?
[11:44]  * popey points mzanetti at beuno
[11:44] <mzanetti> beuno: already in development?
[11:53] <dholbach> mzanetti, real app store app?
[11:54] <mzanetti> dholbach: well, an app store as an app instead of a scope plugin
[11:54] <dholbach> mzanetti, I don't know of any plans
[11:54] <mzanetti> :/
[11:54] <dholbach> mzanetti, you could bring it up on<EMAIL_ADDRESS>[11:54] <mzanetti> the current solution doesn't scale
[11:54] <dholbach> and maybe explain what kind of functionality you're looking for
[11:55] <mzanetti> also, if I disable searching for remote content in systemsetting I can't install any apps any more
[11:55] <dholbach> is it discovering of apps/categories/etc?
[11:55] <mzanetti> yeah, that too
[11:56] <dholbach> so for discovering of apps/categories/etc there are plans from the design team, but I'm not sure when those things are going to land, thostr_ might be a contact person for that
[11:56] <dholbach> if you think you should be able to disable remote content, but still have apps, or have a better indication of what's happening when you disabled the setting, I'd suggest filing a bug about it
[12:29] <beuno> mzanetti, what do you mean by a real app store app?
[12:29] <beuno> ah
[12:30] <beuno> mzanetti, it will still be a scope
[12:30] <beuno> but scopes will get more interesting in 14.04
[12:30] <mzanetti> beuno: but that still means I have to have online searching enabled in order to install any new app?
[12:33] <beuno> mzanetti, not sure. The apps are online, so that scope needs to reach out to the internet
[15:22] <mhall119> popey: http://www.reddit.com/r/Ubuntu/comments/1rkq6z/ubuntu_evernote_app_sees_first_feature_milestone/
[15:22]  * popey upboats
[15:22] <popey> ta
[15:24] <mhall119> np
[17:05] <mefrio> hi guys....do you know how can I install the QtQuick.Layouts module on Ubuntu 13.10?
[17:07] <t1mp> mefrio: I never tried it (should have a look at it soon). But I like to let you know that we also have Ubuntu.Layouts: http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Layouts/
[17:08] <mefrio> t1mp, I need to use this element: http://qt-project.org/doc/qt-5.1/qtquicklayouts/qml-qtquick-layouts1-gridlayout.html
[17:12] <t1mp> mefrio: ok. sorry, dunno.
[17:12] <mefrio> t1mp, no problem :)
[17:16] <mefrio> https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1251927
[17:16] <ubot2> Launchpad bug 1251927 in ubuntu-touch-meta (Ubuntu) "QtQuick.Dialogs missing" [Undecided,Confirmed]
[17:16] <mefrio> :(
[17:17] <aquarius> mhall119, is there anything at all explaining which cordova APIs are available to touch apps?
[17:27] <mhall119> aquarius: we're still working on that
[17:27] <mhall119> aquarius: unfortunately there's not a lot working right now on non-x86
[17:28] <mhall119> aquarius: join #ubuntu-webapps and talk to dbarth and alex_abreu for the details so far
[17:35] <mzanetti> popey: when you have some time, could you please test if this works for you? lp:~mzanetti/reminders-app/use-ssl
[17:35] <mzanetti> some really weird things happening here and I don't trust my setup any more :D
[17:38] <popey> sure
[17:38] <popey> mzanetti: can i just branch that and use the script?
[17:38] <mzanetti> popey: yeah
[17:38] <popey> k
[17:39] <popey> love that script btw
[17:39] <mzanetti> it's taken from unity8
[17:39] <mzanetti> and has gone through a number of transitions to tailor it better for apps
[17:39] <mzanetti> all of my apps have this in the repo
[17:40] <popey> oh sweet
[17:40] <popey> you should blog about it, other app devs might like it
[17:40] <popey> would also be useful with the emulator ☻
[17:41] <mzanetti> popey: works for me with the emulator
[17:41] <popey> nice
[17:41] <mzanetti> as long as there is no device attached. otherwise it gets confused because it finds 2 devices
[17:41] <mzanetti> but you can select which one you want by exporting ANDROID_SERIAL
[17:41] <mzanetti> to the serial number that "adb devices" gives
[17:46] <mhall119> popey: http://developer.ubuntu.com/2013/11/community-driven-core-apps-convergence/
[17:46] <popey> mzanetti: it barfs when i select user
[17:46] <mzanetti> mhm... which error?
[17:47] <popey> mzanetti: http://paste.ubuntu.com/6485482/
[17:47] <popey> mhall119: Excellent!
[17:47] <mzanetti> popey: thanks
[17:47] <popey> np
[17:48] <popey> mhall119: lets spread that far and wide! :D
[17:49] <mhall119> spreading
[17:50] <nik90> popey,mhall119: Can you create an event in the app developer G+ community for the upcoming design clinic? That will make it much easier to keep track of when it happens
[17:50] <mhall119> nik90: good question, I've never tried
[17:51] <popey> hmm
[17:52] <popey> need a way to add the hangout url
[17:52] <popey> which we run from the ubuntuonair account
[17:52] <popey> messy
[17:52] <popey> we could and then add the url at the moment we go live
[17:52] <mhall119> nik90: https://plus.google.com/events/cr2siiehpk565h37p272b6846f4
[17:52] <nik90> popey: It allows you to create an event out of a hangout, but not sure about adding an url to it
[17:53] <mhall119> popey: I just added ubuntuonair.com as the website
[17:53] <popey> that'll do ☻
[17:55] <nik90> popey: cant you add ubuntuonair account as one of the moderator of the g+ hangout?
[17:55] <nik90> popey: this way that accoutn can plan a hangout event
[17:55] <popey> no
[17:55] <popey> because uoa has a youtube account
[17:55] <popey> it all gets very messy
[17:56] <nik90> okay
[17:59] <mzanetti> popey: hmm... it works here. on the desktop and on the phone... really weird
[17:59] <popey> erk
[17:59] <mzanetti> popey: but it didn't work before. only after I installed libssl0.9.8 and compiled it with that
[18:00] <mzanetti> popey: but the weird thing is that I have removed that again and it still works
[18:44]  * greyback eod
[18:51] <aquarius> mhall119, thanks
[18:53] <mhall119> aquarius: np
[22:56] <WebbyIT> Hi popey :-) Shall you approve this branch for calendar please? Kunal has approved it, and finally also Jenkins! It needs only 'approve' status
[22:56] <WebbyIT> https://code.launchpad.net/~rpadovani/ubuntu-calendar-app/1240152/+merge/193191
[22:57] <popey> WebbyIT: hey
[22:59] <WebbyIT> thanks popey :-)
[23:00] <popey> np


[05:22] <maslen> I'm trying to set up the aflize docker image (https://github.com/d33tah/aflize) , but when I run docker with "docker run -ti d33tah/afl-sid bash", I get an error: "System error: exec format error" . I'm on Ubuntu 16.04. This is my first time using docker, so I apologize for any noob mistakes.
[05:30] <ngaio> I'm seeing severe graphical corruption with Qt programs in xenial
[06:00] <ngaio> for example, bring up the About window in VLC
[09:23] <lordievader> Good morning.
[11:15] <ngaio> would anyone like to assist me in possibly filing a bug about severe graphics corruption with Qt programs in Xenial (assuming no one did already, which would be surprising)?
[12:04] <enyc> ngaio: look up if its' already there in  https://bugs.launchpad.net/  ?? -- i'm not an expert on ubuntu bug reporting tbh
[12:26] <BluesKaj> Hey all
[12:26] <ngaio> BluesKaj, you're a KDE user right?
[12:27] <BluesKaj> ngaio, yes
[12:27] <ngaio> and/or packager
[12:27] <BluesKaj> tester
[12:27] <ngaio> have you seen or heard of severe graphical corruption with Qt programs in xenial?
[12:28] <BluesKaj> no, just the odd freeze
[12:28] <ngaio> e.g. About screen in VLC
[12:28] <ngaio> I get only the title bar of the About window, which is the full screen width, and no content
[12:29] <ngaio> do you see that?
[12:31] <BluesKaj> no, I the about  popout
[12:31] <BluesKaj> get
[12:33] <BluesKaj> http://ibin.co/2WwBqlvq6MYH
[12:33] <BluesKaj> that's what I'm getting
[12:34] <ngaio> hmm okay. I wonder why I'm not. I'm running the standard Unity theme
[12:35] <ngaio> my own PyQt program is severely corrupted and in fact doesn't even display
[12:35] <BluesKaj> I'm on plasma 5.5.4
[12:40] <BluesKaj> ngaio, got python3 ?
[12:40] <lordievader> ngaio: Qt4 or Qt5?
[12:41] <ngaio> python 3.5, Qt 5
[12:42] <lordievader> Does it throw errors in the terminal?
[12:42] <ngaio> yes, I don't recall exactly, but something about gtk widget
[12:43] <ngaio> (i'm dual booting, in 15.10 at the moment)
[12:43] <ngaio> the gtk widget error is surprising considering they're Qt programs
[12:43] <lordievader> Yeah, that is quite odd.
[12:43] <lordievader> Is it possible to pastebin your code?
[12:43] <ngaio> I did a search on the specific error, and found bugs from 2011 relating to Qt 4
[12:44] <ngaio> it's not just my code though - VLC shows the same problem
[12:44] <ngaio> it gives the same error
[12:45] <BluesKaj> how about 15.10 are you on unity there too? ot kde?
[12:45] <BluesKaj> or
[12:45] <ngaio> Unity & KDE on 15.10.... won't install KDE on 16.04 unless / until the bug with SSO is fixed
[12:45] <ngaio> the telepathy bug
[12:46] <BluesKaj> oh, telepathy, ,never use it
[12:48] <lordievader> Wait, you have the problem on both 15.10 and 16.04?
[12:49] <ngaio> lordievader, no, it only shows up in 16.04
[12:50] <ngaio> in 15.10 it works as expected
[12:51] <ngaio> I'll reboot into 16.04 now to get the exact error message on the terminal
[12:53] <ngaio> to answer your question about my code, it's on launchpad as lp:rapid. You can get it with bzr. Don't run the setup.py though, I'm still coding that and in any case some dependencies can only be installed with pip :-D
[12:53] <ngaio> screenshot is here: http://damonlynch.net/rapid/screenshots/beta/20160128rpd.png
[12:54] <ngaio> brb
[12:59] <ngaio> this the the VLC about window I'm seeing: http://ibin.co/2WwJn8jsja84
[13:00] <ngaio> that shows the error messages on the console too
[13:00] <lordievader> Hmm, at first I thought it was a problem with your application, specifically. But if more applications suffer the same fate it would make you think a library is the culprit.
[13:01] <lordievader> !info vlc xenial
[13:01] <ngaio> many Qt applications are totally unusable
[13:02] <lordievader> Haven't run (Kubuntu) Xenial for a while myself, but last time I ran it I didn't notice any problems.
[13:02] <ngaio> what's odd is that VirtualBox seems to work okay
[13:03] <ngaio> at least the main windows and the preferences
[13:03] <ngaio> I dont' dare start an actual VM
[13:04] <lordievader> Why not?
[13:06] <BluesKaj> one thing I did notice is thay 16.04 is much slower to load tje desktop after boot and packages than 14.04, and I'm dual booting both OSs on the same ssd
[13:07]  * BluesKaj opens the blinds to get more light
[13:09] <ngaio> lordievader, because I don't want VirtualBox breaking at the moment when it tries to load another O/S.
[13:11] <maslen> Does docker require an x64 host ?
[13:12] <ngaio> aha! when I run my app with Motif style, it works
[13:12] <ngaio> so it's a Qt theme problem
[13:14] <lordievader> Oehh, would you mind submitting a bug report for that?
[13:14] <ngaio> yes I'm just trying to figure out what the default theme is
[13:15] <BluesKaj> maslen, not to worry 16.04 is multiarch by default
[13:15] <ngaio> lordievader, do you know what package I should file it against?
[13:15] <ngaio> I have no idea what the default Qt theme under Unity is called
[13:16] <BluesKaj> orange and purple :-)
[13:17] <maslen> BluesKaj: What does that mean?
[13:17] <BluesKaj> oh and brown
[13:18] <ngaio> maslen, we're talking about the default theme for Qt programs that are run under the Unity desktop
[13:18] <lordievader> ngaio: I think the theme is called breeze, but I am not sure if that is a seperate package and/or if Unity uses that by default.
[13:18] <maslen> ngaio: And I was asking about docker :)
[13:18] <BluesKaj> docker can run on both 32 and 64bit
[13:19] <BluesKaj> it's been around since kde3
[13:19] <BluesKaj> and gnome
[13:29] <BluesKaj> maslen, are you talking about the container app or the graphical panel ?...there seems to be a duplicate name for 2 differnt applications
[13:31] <BluesKaj> !docker
[13:31] <maslen> the container app. docker.io
[13:32] <k1l> who runs 32bit hosts anyway
[13:33] <BluesKaj> because when I refernced docker in muon this what I got: "Docker is a docking application (WindowMaker dock app) which acts as a system tray for any desktop environment"
[13:35] <BluesKaj> Think the packagers better come up with a new name for the docking app in the DE
[13:38] <maslen> k1l: I've been using x86 because of ASAN : https://github.com/mirrorer/afl/blob/master/docs/notes_for_asan.txt
[13:40] <k1l> maslen: you are aware that this is not a real issue on todays ram sizes? 32bit is going to die slowly. faster than flash, but still slowly. chrome dropped 32bit support. first linux distributions dropping 32bit isos.
[13:40] <ngaio> bug #1545450 is filed
[13:47] <maslen> k1l: I can only allocate so much RAM to my VMs
[14:13] <k1l> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule  doesnt have the schedule for the pointreleases so far
[16:12] <TheOnlyBouncer> good day
[16:12] <TheOnlyBouncer> i have a Lenovo yoga 2-11 which is running the current alpha for 16.04 but i am getting occasional total system freezes. Since i can not do anything, is there a way to debug this to commit a bug report?
[16:12] <TheOnlyBouncer> its running a Intel Pentium N3520 processor
[16:13] <TheOnlyBouncer> and it seem to happen mostly during gpu access
[16:16] <TheOnlyBouncer> i must admit that i did not try another distro or version of ubuntu yet (since i really wanted a 4.4 kernel or newer), but i rather figure out how to debug this :)
[17:23] <penguin42> TheOnlyBouncer: Do you have it connected to a network and can you log in when it fails?
[17:25] <penguin42> TheOnlyBouncer: Also, how dead is it - e.g. does the capslock key still change the state of the capslock LED ?
[18:24] <TheOnlyBouncer> penguin42, nothing reacts anymore, at all, total system freeze (ie. keyboard not reacting etc)
[18:24] <TheOnlyBouncer> otherwise i would have switched to a terminal and did some debugging
[18:25] <TheOnlyBouncer> did not try if i could ssh in it when crashed though
[18:27] <penguin42> TheOnlyBouncer: Worth a try, otherwise, file a bug anyway - probably   ubuntu-bug linux     just after you reboot
[18:33] <TheOnlyBouncer> penguin42, are there any automated logs for crashes that get fetched this way?
[18:33] <TheOnlyBouncer> to be honest, i would rather find out what actually goes wrong so i can hotpatch it
[18:33] <TheOnlyBouncer> i kind of need that system running
[18:34] <penguin42> TheOnlyBouncer: Yeh that can be tricky depending what broke
[18:34] <penguin42> TheOnlyBouncer: I'd start by seeing if you can ssh in, if you can then that makes it a LOT easier to see what's going on
[18:35] <penguin42> TheOnlyBouncer: But check /var/log/syslog and syslog.1 or kernel.log and kern.log.1  to  see if they have anything from the crash, but if it crashes hard it often can't write the logs
[18:36] <TheOnlyBouncer> hmm ok will try, thanks
[18:36] <TheOnlyBouncer> i don't think it is a kernel panic, which makes me happy :P since that would definitely shown anything
[18:37] <penguin42> TheOnlyBouncer: There are some other tricks as well - e.g. if you can get it to fail while it's in text mode console then you might be able to see a crash message - but it's quite hard if it just stops
[20:57] <alkisg_away> Has anyone experienced problems in xenial with services not starting on boot _some_ times?
[20:58] <alkisg> E.g. network-manager, dnsmasq, even lightdm...
[20:58] <alkisg> Maybe one out of 20 boots or so
[20:58]  * alkisg has seen that in 3 different installations so far
[21:11] <lordievader> Haven't noticed it yet. Is this a recent trend?
[21:13] <alkisg> I'm not sure, I've been using xenial on one pc since months, but I only rebooted it once per month or so... the other 3 installations are recent, from 2 to 20 days old, and they all have the issue
[21:13] <lordievader> Hmm, haven't booted my Xenial install in a while. But I can't remember such as issue happening.
[21:15] <alkisg> Thanks, I'll check more and file a bug report on that then :)


[11:44] <cuu> hello all here, I am looking help if anyone has riscv64 build enable?
[11:45] <cuu> I am tring to get a new mesa of os image for riscv portable computer devterm r01
[11:45] <cuu> but I am not Canonical employees or Ubuntu core developers
[11:53] <guruprasad> cuu, riscv64 builds are not enabled for external users at the moment.
[11:56] <cuu> I know that
[11:56] <guruprasad> we cannot enable the builds because of how the build environment is set up and cleaned
[11:57] <cuu> so I wonder if anyone can pull a mesa from https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa
[11:57] <cuu> make a mesa riscv avaiable
[11:57] <cuu> Then I can add your ppa into the os image of devterm , and all the build process is automaticlly,right ?
[11:58] <guruprasad> cuu, I don't think the Launchpad team can help with that.
[11:58] <cuu> why?
[11:58] <cuu> if you have risv64 enabled, a riscv64 build is easy right ?
[11:58] <guruprasad> Because we develop and maintain Launchpad and your request has nothing to do with it?
[11:58] <cuu> oh ~ I see
[11:59] <cuu> sorry for that
[11:59] <cuu> you are right
[11:59] <guruprasad> I will try to find if you can ask for help somewhere regarding this.
[11:59] <cuu> thanks for that
[11:59] <cuu> I am here for personal help,lol
[11:59] <guruprasad> cjwatson, is there someplace that cuu could ask for help with his request?
[12:00] <cuu> and if anyone help me, we can def send a devterm as a gift to you for your help
[12:00] <cjwatson> Not that I know of.
[12:00] <cuu> wow. cjwatson
[12:01] <cjwatson> There are people working on enabling riscv64 in Ubuntu, but I don't know if they have a public forum where they hang out.
[12:01] <cjwatson> I guess you could try on discourse.ubuntu.com?  There are some riscv64 threads there
[12:03] <cjwatson> There's an #ubuntu-riscv, maybe
[12:04] <cuu> yeah there is