[05:17] <mr_steve> I need to start pretending that I stil exist
[05:21] <Takyoji> :P
[05:21] <mr_steve> It's been a crazy couple weeks. Can't wait for spring break


[01:25] <elky> phunyguy: i made my face hurt with curry. i don't know what's going on right now
[01:29] <phunyguy> lol
[01:29] <phunyguy> that's good stuff.
[05:14] <stevendale> Hi
[05:17] <stevendale> Let me get this straight. I got banned for joining with a different nick, then leaving without saying anything?
[11:38] <bazhang> he just wanted to waste time, have him in PM
[11:39] <k1l> i even provided a pictured howto for the server install with all steps. he wanted to be an issue
[11:45] <Tsterxer> Hi
[11:46] <Tsterxer> Did my ban was justice and the attitude, my attitude to them?
[11:46] <Tsterxer> Prefer not bazhang to involve
[11:46] <Tsterxer> But can read.
[13:06] <k1l> !15.04
[13:06] <k1l> it is the release :)
[13:17] <Pici> !itsawiki
[13:18] <Pici> i mean, a bot
[13:18] <Pici> I'll update it ;)
[13:18] <k1l> !14.10
[13:18] <Pici> I have a system.
[13:19] <k1l> until is figurered the right bot commands someone having more experience is already done :)
[13:27] <Pici> !vvid
[13:27] <Pici> !vivid
[13:27] <Pici> !14.10
[13:28] <k1l> thx Pici
[13:56] <popey> uh
[13:56] <popey> !14.10
[13:56] <popey> s/UBuntu/Ubuntu/ ?
[13:57] <Pici> oops
[13:57] <Pici> !utopic =~ s/UB/Ub/


[02:41] <Sarvatt> is it a known issue that theres no linux-backports-modules for 2.6.32-17 in the archives yet?
[02:59] <MTecknology> Sarvatt: it's in the pocket
[02:59] <MTecknology> so.. it shoulda been there already
[04:25] <JohnFlux> woohoo!  Suspend works now on my machine :-)
[04:25] <JohnFlux>  It didn't work in 9.10  but does in 10.04
[04:25] <JohnFlux> I love you guys! :)
[04:43] <JohnFlux> Why do drivers released by companies have such poor quality?
[04:44] <johanbr> if you're talking about closed-source drivers, it seems like the authors often have a less than perfect understanding of how to interface with the kernel properly
[04:44] <JohnFlux> even GPL'ed drivers
[04:44] <JohnFlux> The released ralink driver doesn't compile because they removed MODULE_LICENSE("GPL") at the last moment
[04:45] <JohnFlux> it contains a serious flaw that lets root the system remotely
[04:45] <johanbr> oh that... yes, ralink is a mess
[04:45] <JohnFlux> It spams the syslog with the message "#"  once for every packet!!
[04:45] <JohnFlux> The email addy bounces
[04:46] <JohnFlux> but I've seen this mess elsewhere
[04:46] <JohnFlux> I worked for a company writing video drivers for SGX
[04:47] <JohnFlux> people keep pushing us to release the code for the driver..  but there's a good reason we don't show anyone it.. :-D
[04:47] <johanbr> right :)
[04:47] <johanbr> I think opensource encourages good programming practices
[04:48] <JohnFlux> we used RCS, and actually sent customer patches as a Word document!
[04:48] <JohnFlux> with instructions to copy and paste the text, then manually fix the smart quotes..
[04:49] <johanbr> yikes :)
[04:49] <JohnFlux> when I left, last year, they were planning to upgrade to CVS
[04:49] <JohnFlux> they still haven't though :-D
[04:50] <johanbr> maybe they got rid of the Word patches at least :)
[04:50] <JohnFlux> no, I tried to at least automate the process..  but no luck
[05:09] <syn-ack> Seriously, *word*?
[05:09] <syn-ack> man, I could understand something like notepad or wordpad but *word*?!!? /me shudders
[05:46] <crimsun> bjf: patch for #303789 sent to stable and upstream
[08:24] <amitk> smb: the d-i patch, shouldn't it say modularise instead of de-modularise?
[08:25] <smb> amitk, Yes Andy should have known better. Thats how those patches are now in the repo. I won't rewrite history
[08:26]  * amitk doubts andy's english skills, he's english after all
[08:26] <smb> (and actually we all failed to spot it in looking at the patches. /me included)
[08:27] <smb> amitk, MY language skill get bad in any language given the time of day is late enough. ;-P
[08:31] <amitk> there has to be a better way to create our d-i modules files automagically - comparing config file changes to d-i changes is painful
[08:36] <amitk> smb: do you know if PATA_SIS == module(pata_sl82c105.ko)?
[08:37] <amitk> I guess I can look at the Kconfig help text
[08:37] <smb> amitk, I created the list from the modules I found on my build system.
[08:37] <smb> There are a few that are different between amd64 and i386 but I hope this catches all
[08:40] <amitk> smb: some discrepancies
[08:40] <amitk> PATA_SIS is enabled in the config, but not in d-i
[08:41] <smb> Ok, I should add that then
[08:42] <amitk> In Sata:
[08:42] <smb> amitk, Hm, pata_sis? I only see sata_sis.ko
[08:43] <amitk> smb: I see a PATA_SIS enabled in debian.master/config/config.common.ubuntu
[08:45] <amitk> sata looks good
[08:46] <smb> amitk, For some reason the PATA_SIS ends up being built in...
[08:46] <smb> amitk, Need to check the lower config files
[08:47] <amitk> smb: you're right, I missed the =y, so yes it is built in
[08:47] <amitk> so according to config, the d-i is correct.
[08:47] <smb> amitk, Though I wonder whether this should also becom =m
[08:47] <amitk> whether or not PATA_SIS should be built-in or not is a separate story
[08:47] <smb> yeah
[08:47] <smb> I make a sticky-note for apw
[08:48] <smb> amitk, I just want that d-i change out and in today as this breaks a good deal of things
[08:51] <amitk> smb: ack away
[08:51] <smb> amitk, Many thanks
[09:08] <JohnFlux_> smb: Hey man
[09:08] <smb> JohnFlux_, mornin
[09:08] <JohnFlux_> smb: I'm going to ask a very stupid question..  what does "Fix Committed" mean ? :-)
[09:09] <JohnFlux_> smb: This means it's now a patch in the ubuntu kernel, right?  But not yet accepted by the staging drivers guys upstream?
[09:09] <smb> JohnFlux_, :) That I put the patch into our git tree. When it gets uploaded and released it will become fix released
[09:09] <smb> The status has nothing to do with upstream. Just internal workflow
[09:12] <JohnFlux_> smb: got ya.  We added 0x0411, 0x015D     but I'm seeing the occasional post about the same thing also being   0x0411, 014F
[09:12] <JohnFlux_> smb: e.g.  http://forums.ncix.com/forums/index.php?mode=showthread&msg_id=2026623&threadid=2026623&forum=105&product_id=37959&msgcount=0&overclockid=0
[09:12] <smb> JohnFlux_, I plan to do an upload late today. So it should become available latest next week. For some things I need other people to do it, so it can get delayed.
[09:13] <JohnFlux_> smb: Should I update  https://help.ubuntu.com/community/HardwareSupportComponentsWirelessNetworkCardsBuffalo   to change the status to working?
[09:13] <smb> JohnFlux_, If there are other IDs, those should get filed as separate bugs. Nothing worse that one bug with plenty of different "oh and this ID too"
[09:14] <smb> JohnFlux_, Maybe wait for the official kernel to be available for that
[09:14] <smb> Just being paranoid. ;-)
[09:15] <JohnFlux_> smb: hum, it seems easier to just add them now and see if we get bug reports about them
[09:15] <smb> JohnFlux_, And again, the official kernel will not contain the ID for that ralink 2070L
[09:15] <JohnFlux_> official ubuntu kernel, or official linus's kernel?
[09:16] <JohnFlux_> oh right, the 2070
[09:16] <JohnFlux_> Hopefully I can get someone else to confirm it works in time
[09:16] <JohnFlux_> but..   what's the harm?
[09:16] <JohnFlux_> we know that this is the driver that should be used
[09:16] <JohnFlux_> we know that it _should_ work
[09:16] <JohnFlux_> and we know that without the change, it certaintly won't work
[09:16] <JohnFlux_> so what's the harm in just adding it?
[09:17] <smb> JohnFlux_, Exactly _should_. I like to be _certain_
[09:17] <JohnFlux_> smb: I can be _certain_ that it won't work without it
[09:17] <JohnFlux_> smb: how's that for certain? :P
[09:17] <smb> JohnFlux_, Not enough to convince me. :-P
[09:18] <JohnFlux_> smb: I don't really get why not :P  Seems a very obvious choice between "certaintly won't work" and "probably should work"
[09:18] <smb> JohnFlux_, But I won't carry a patch that _might_ work. If it _does_ work it should go upstream, but I won't bother Greg with something that maybe works
[09:19] <JohnFlux_> okay
[09:22] <amitk> JohnFlux_: we don't carry "probably works" patches. They has to be verification that it works.
[09:25] <JohnFlux_> is there a way to force a driver to work anyway for a given usb id?
[09:29] <smb> JohnFlux_, I think there is a bind file in sysfs for each driver, which you can echo IDs into...
[09:31] <amitk> JohnFlux_: http://lwn.net/Articles/143397/
[09:32] <amitk> JohnFlux_: apologies, that was for driver binding, this one is for adding a new ID: http://www.ha19.no/usb/
[09:33] <smb> amitk, Good find. I just was about to mention new_id
[09:33] <JohnFlux_> very interesting
[13:16] <JohnFlux_> smb: http://ubuntuforums.org/showthread.php?p=9030092#post9030092   someone said that your kernel doesn't boot for them?
[13:16] <JohnFlux_> smb: they mentioned that they have an eepc though
[13:16] <JohnFlux_> 'mounted root fs can not mount /dev/pts and something else cant mount rootfs'
[13:17] <JohnFlux_> Does this error mean anything to anyone ?
[13:19] <smb> It seems to be unable to find or mount the root file system and another virtual fs. Why is hard to say. Have you tried the kernel I made?
[13:19] <smb> Probably not as you had a working kernel before
[13:21] <JohnFlux_> smb: sorry, this is what someone else said
[13:21] <JohnFlux_> smb: I haven't actually tried your kernel :-)
[13:22] <JohnFlux_> smb: I pasted that error from that link I just gave
[13:22] <smb> But the information is not very detailed. Could be something gone wrong installing. Could be something in the build. But its just the usual build with two more patches
[13:22] <smb> I have seen that. But its hard to tell more
[13:23] <JohnFlux_> smb: might be something related to the EEPC ?
[13:24] <smb> I would doubt it. If they had been running Ubuntu before...
[13:27] <cnd> how do you delete a chroot after you don't need it anymore?
[13:27]  * cnd doesn't need lucid chroot now that I'm running lucid
[13:29] <smb> cnd, You could rm -rf and remove the entry from the config. But I would still keep it as its a better controlled environment
[13:30] <cnd> smb, good point, but not good enough when I need to conserve space :)
[13:31] <cnd> since I do most of my kernel builds on emerald.mills anyways
[13:31] <cnd> well, all my builds really
[13:32] <smb> cnd, How can one be so tight on space. I hardly was able to by a laptop hardrive below 250G nowadays. :-P
[13:32] <smb> cnd, But as said. You can edit /etc/schroot/schroot.conf and remove the lucid entry
[13:33] <smb> and then just remove the directory where you installed the chroot
[13:33] <pmatulis> are there recent kernels (PPA) i can try on 8.04? there is "Using newer kernels on LTS releases" in LP but it says the project is "closed"
[13:33] <smb> cnd, Just make double sure, that nothing has bind mounted /home somewhere in it
[13:33] <cnd> smb: macbook has 120GB, ~80 is used by os x (which I don't really use anymore, but need to keep around), and I have the rest split between main partition and test partition
[13:33] <cnd> smb: good call
[13:34] <smb> pmatulis, I don't think so.
[14:00] <ogasawara> manjo: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507148 - will you be able to test the upstream patches?
[14:00] <ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed]
[14:03] <smb> manjo, Have you tested with the -17 kernel on that?
[14:09] <Keybuk> so tempted to do a companion blog to cking's blog of awesome
[14:10] <Keybuk> "system calls and C library functions you didn't know about"
[14:10] <Keybuk> today I found statfs()
[14:10] <cking> Keybuk, I only blog about obscure stuff so I can google search it later :-)
[14:11] <Keybuk> cking: and as a result, your blog is one of the most useful ones in the known universe ;-)
[14:11] <cking> you're too kind
[14:13] <Keybuk> more particularly, I know this trick
[14:13] <Keybuk> stat("/") => info
[14:13] <Keybuk> stat("/dev") => dev_info
[14:13] <Keybuk> if info.st_dev != dev_info.st_dev:
[14:13] <Keybuk>   then dev is mounted
[14:13] <cnd> smb, so about that acpi patch that upstream isn't biting on, I still think it should go into lucid
[14:13] <Keybuk> better trick, just statfs("/dev") :-)
[14:13] <cnd> smb: http://patchwork.ozlabs.org/patch/47164/
[14:14] <smb> cnd, I think I remember the one about the warning level for those resource conflicts
[14:14] <cnd> smb: yep
[14:14] <smb> cnd, Hasn't mjg59 acked that sort of? No I guess just said it would be ok
[14:15] <cnd> smb: right, he just seemed to agree in principle at the time
[14:15] <cnd> but I'd be happy to have mjg59 ack it (wink wink)
[14:16] <cnd> :)
[14:16] <smb> cnd, If nothing happens, we might go and take it as a sauce patch for now. But I guess I will leave that to the time apw gets back
[14:17] <cnd> smb: ok, just want to make sure it's not left until it becomes too late for inclusion
[14:17] <smb> cnd, No its still clearly visible on our list
[14:18] <cnd> I'm just new to the process, so I figure it's better to be safe than sorry
[14:26] <cking> Keybuk, that's a trick worth documenting
[14:42] <cnd> amitk: what was your methodology for determining which power saving features to put into powersave-policy?
[14:42] <cnd> I'm curious if there's anything else that didn't do much for you, but maybe works well for others?
[14:43] <cnd> overall though, I'm not seeing a huge difference in power consumption with the extra policy scripts
[14:46] <amitk> cnd: the first step was just to make laptop-model-tools redundant. There are a few more script in laptop mode tools that were very hacking and/or too intrusive
[14:46] <amitk> s/hacking/hackish
[14:46] <cnd> amitk: so we've basically taken everything from laptop-mode-tools that seems reasonable?
[14:48] <amitk> cnd, yes IMO. I'll send you an email listing why I didn't pick the others.
[14:48] <cnd> amitk: thanks
[15:08] <ogasawara> JFo: can you add bug 532374 and bug 548513 to our list for monday
[15:08] <ubot3> Malone bug 532374 in linux "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,Confirmed] https://launchpad.net/bugs/532374
[15:08] <ubot3> Malone bug 548513 in linux "Firewire disks not working under 10.04" [Critical,Confirmed] https://launchpad.net/bugs/548513
[15:08] <JFo> ogasawara, will do
[15:09] <smb> cking, Isn't that your pet area nowadays? ^
[15:09] <JFo> ogasawara, done
[15:09] <ogasawara> JFo: thanks. robbiew asked that we get them on our radar.
[15:09] <JFo> no problem
[15:10] <cking> smb, yes jerone asked me to eyeball that when I was on vacation. It's on my ever growing list
[15:11] <JFo> and I just made the list huge
[15:11] <JFo> Kernel Regression Bug Day schedule announced in e-mail
[15:11] <smb> cking, I wonder whether we might be allowed to volunteer you to have a look after that
[15:11] <cking> please do
[15:12] <smb> JFo, ^
[15:12] <JFo> ok, for the bug call on Monday?
[15:12] <pgraner> cnd: you want to save power? Turn of the bling, doing that on my netbook saved almost 2watts
[15:12] <cnd> pgraner: bling?
[15:12] <JFo> smb, that for the firewire one?
[15:12] <pgraner> cnd: bling == compiz
[15:12] <smb> JFo, If its on that list cking would have the best insight I think (no the i7)
[15:13] <pgraner> cnd: putting the gpu into 2d mode makes a big difference
[15:13] <cnd> pgraner: I have a feeling people would get upset if we started flipping compiz on and off every time you plug in and out of ac
[15:13]  * cking notes that disabling video and ssh'ing in helps save power too :-)
[15:13] <pgraner> cnd: yea since now it tends to gather you desktops onto one
[15:14] <pgraner> cking: you're so damn old school
[15:14] <pgraner> cking: X for me is nothing more than a VT arranging utility
[15:14] <cnd> pgraner: do you know how to disable compiz and 3d on demand?
[15:14] <cking> pgraner, I'm happy with a serial console ;-)
[15:14] <cnd> I'd like to try it personally just to see how effective it is
[15:14] <pgraner> cnd: nope, talk to bryceh
[15:14] <pgraner> cnd: or one of the desktop guys
[15:15] <JFo> smb, ok
[15:15] <cnd> compiz for netbook edition seems overkill if I can get 2W back
[15:15] <cnd> since it only uses 10W right now anyways
[15:15] <cking> http://smackerelofopinion.blogspot.com/2009/11/improving-battery-life-on-hp-mini.html is my powersaving hack
[15:15] <cnd> and it should help with flash
[15:16] <cking> and also: http://smackerelofopinion.blogspot.com/2009/06/reducing-wifi-beacon-interval-to-save.html
[15:20] <pgraner> cnd: if your running compiz you can use: metacity --replace  & compiz --replace to switch between them
[15:21] <pgraner> cnd: I'm supposing you want to test it in the scripts?
[15:21] <cnd> pgraner: nope, just running metacity
[15:21] <cnd> pgraner: no, just for personal usage
[15:21] <cnd> and documenation
[15:21] <pgraner> cnd: well thats how you switch inbetween them
[15:22] <cnd> ok
[15:27] <crimsun> amitk: / cnd: hmm, I see (using cnd's pm-utils-powersave-policy 0.4~powersave2) that powerdown is now enabled for all hda when on battery -- that annoying pop will return for non-IDT/Sigmatel codecs
[15:27] <crimsun> that was the reason for the earlier check for the idt module
[15:27] <cnd> crimsun: yeah, Keybuk mentioned it, and I forgot to remove the script in powersave2
[15:27] <crimsun> ah ,ok
[15:28] <cnd> crimsun: unless there's some easy way to check for good codecs in the script?
[15:28] <cnd> though in that case, it should just be on all the time
[15:28] <crimsun> cnd: yes, in the original, I check for the existence of the module dir in /sys
[15:28] <cnd> and besides, this is targetted at M, at which point the popping should be sorted out for all the codecs right?
[15:28] <crimsun> sec, will pull the diff
[15:29] <crimsun> cnd: ah, so it's not for Lucid?
[15:29] <cnd> crimsun: no, it's too late for Lucid
[15:29] <crimsun> ah, then that's no big deal :-)
[15:31] <crimsun> cnd: yeah, just a simple [ -e $CODEC -a -w $PD ] currently (where $CODEC is /sys/module/snd_hda_codec_idt)
[15:32] <cnd> crimsun: so in M, the popping will be fixed for all codecs?
[15:33] <crimsun> cnd: kernel version-dependent, but yes
[15:33] <cnd> crimsun: what do you mean?
[15:34] <crimsun> cnd: well, there's the assumption that 2.6.32-2.6.34 won't be chosen
[15:35] <cnd> crimsun: ok?
[15:35] <crimsun> cnd: so with a sufficiently new kernel, then yes, those symptoms are fixed
[15:35] <cnd> how new are we talking? .34 isn't out yet
[15:36] <cnd> is there some patch waiting in the wings for the .35 merge window?
[15:36] <crimsun> yes, I have updates for the conexant and realtek ones
[15:36] <crimsun> there were a number of realtek ids added since 2.6.32
[15:37] <cnd> ok
[15:37] <cnd> even if M is based on .34, we'd likely take a look at the patches anyways
[15:37] <cnd> especially if it's just a matter of ids at that point
[15:38] <crimsun> ok
[15:40] <cnd> amitk: what about laptop_mode itself?
[15:40] <cnd> doesn't laptop-mode-tools enable that? pm-powersave doesn't yet
[15:46] <marga> Hi!  I'm a Debian person (user, developer, etc), but I'm trying to help an Ubuntu user, that has a 32bit user space Ubuntu installation, with a 64bit processor.  In Debian we have an -amd64 flavor, for 64 bits processors with the i386 userspace.  By looking at the Ubuntu flavors for i386, the one that is 64bits -apparently- is -server... What is special about -server? Can it be used by a 64bit desktop?
[15:49] <amitk> cnd: yeah, that should be enabled too
[16:07] <cnd> amitk: I reread the spec, and laptop_mode shouldn't be enabled by default per Ted T'so due to interactions with ext4
[16:07] <cnd> so we look good there
[16:18] <cnd> amitk: thanks for the writeup!
[16:18] <cnd> helps explain many questions I had
[16:31] <nosse1> Hi. I'm trying to build a kernel for an ARM target. Where can I find a "standard" set of kernel config which represents what ubuntu requires from the kernel?
[16:40] <manjo> ogasawara, on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507148 building and testing the kernel on jdstrand's laptop
[16:40] <ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed]
[16:40] <ogasawara> manjo: cool, thanks
[16:40] <manjo> ogasawara, was busy with several audio bugs ... so results will be after lunch ...
[16:41] <ogasawara> manjo: k thanks, just mainly wanted to know the status for the release meeting
[16:41] <manjo> ogasawara, ah ok...
[16:53] <crimsun> manjo: for #548371, your Mic Boosts are still set at zero
[16:53] <crimsun> (...unless you're just pasting outdated alsa-info output?)
[16:54] <manjo> crimsun, no the last one I posted was with  ubuntu audio dev ppa
[16:55] <crimsun> manjo: I mean that you're running the script when the capture is not occurring
[16:55] <crimsun> same for #528719, BTW
[16:57] <manjo> hmmm so what is that amixer option to boost it ?
[16:57] <manjo> crimsun, ^  ?
[17:11] <crimsun> manjo: (sorry, I'm at a conference currently) for which bug?
[17:12] <manjo> should I do amixer set 'Capture',1 cap
[17:12] <crimsun> manjo: for #528719, it's amixer set 'Mic Boost' 100%,100%
[17:13] <manjo> ok
[17:13] <crimsun> similar for #548371 but you also need 'Front Mic Boost'
[17:17] <manjo> crimsun, after the boost I still get white noise
[17:17] <manjo> crimsun, I hear my voice very very faintly.
[17:19] <crimsun> manjo: for which hw?
[17:19] <manjo> acer
[17:19] <manjo> #528719
[17:22] <manjo> crimsun, on the aspire1
[17:22] <manjo> Simple mixer control 'Mic Boost',0
[17:22] <manjo>   Capabilities: volume penum
[17:22] <manjo>   Playback channels: Front Left - Front Right
[17:22] <manjo>   Capture channels: Front Left - Front Right
[17:22] <manjo>   Limits: 0 - 3
[17:22] <manjo>   Front Left: 3 [100%]
[17:22] <manjo>   Front Right: 0 [0%]
[17:22] <manjo> how do I boost  Front Right: 0 [0%] to 100% ?
[17:22] <crimsun> manjo: err, did you use the syntax above?
[17:23] <manjo> yes
[17:23] <crimsun> huh. Well, just 100%
[17:24] <manjo> ok that made both 100%
[17:24] <crimsun> bah, bug in amixer :-(
[17:25] <manjo> ok tried after setting that.... and again .. white noise with faint recording of the sound
[17:26] <manjo> crimsun, btw the bug is only when using external mic, and does not occur with built in mic
[17:26] <manjo> crimsun, I have used 2 diff mics to make sure its not the mic hw
[17:28] <crimsun> manjo: ok, please update the bug reports, respectively. I'm having a difficult time tracking irc and conference simultaneously, sorry
[17:28] <manjo> crimsun, no problem! will update
[17:28] <crimsun> I should have a free stretch in two hours
[21:19] <cnd> bryceh: I'm looking at bug 544741
[21:19] <ubot3> Malone bug 544741 in linux "[X700] KMS, amd64: Kernel panic while trying to launch system > preferences > appearance" [High,Triaged] https://launchpad.net/bugs/544741
[21:19] <cnd> I saw your email about edid quirks
[21:20] <cnd> actually, let me read the email once again, and I'll get back to you
[22:55] <mozmck> How do I create a new flavour of the lucid kernel?


[15:43] <ion_> keybuk: Have you already proposed your magic sauce to make Upstart handle forks et al. to be merged to Linux? (2.6.31?)
[20:47] <Keybuk> ion_: yes
[20:48] <Keybuk> everything but setsid() is in 2.6.29 I think
[20:48] <Keybuk> hoping that the setsid() notification will be in .31
[21:27] <ion_> keybuk: Cool


[08:37] <FatherTyme> Has anyone attempting netboot installs on Dell PowerEdges here?
[08:37] <FatherTyme> I'm having difficulty getting it to recognize the network interfaces on Dapper for a PE 1950.
[09:07] <robertj> Are the integrated SATA controllers all well behaved throughout the PowerEdge line?
[09:10] <lionel> robertj: which controller ?
[09:10] <lionel> (several are provided with PowerEdge)
[09:12] <FatherTyme> Dapper won't autodetect the SAS one...
[09:12] <FatherTyme> Edgy will...
[09:12] <FatherTyme> PERC5i is great on both.
[09:22] <robertj> FatherTyme: sweet, I need the PERC5i one for a 5 disk RAID 5
[09:27] <robertj> VMWare here I come :)


[07:17] <doko> oSoMoN: is thunderbird supposed to migrate in eoan?
[07:19] <oSoMoN> doko, yes, once I manage to fix the enigmail pcc64el test failures
[07:20] <oSoMoN> doko, I'm on the case
[10:32] <rafaeldtinoco> morning o/
[10:40] <xnox> infinity:  kees: stgraber: vorlon: can i get a response on https://lists.ubuntu.com/archives/technical-board/2019-August/002456.html ? or should I open some bug report and start uploading things referencing it?
[11:01] <juliank> I'm trying to UEFI boot eoan kernels in eoan's qemu, but I get emulation failures
[11:01] <juliank> sudo kvm -boot c -hda fat:rw:/boot/efi -drive file=/dev/nvme0n1p2,format=raw,readonly,if=virtio -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd   -drive if=pflash,format=raw,file=/tmp/M
[11:01] <juliank> Y_VARS.fd
[11:01] <juliank> basically
[11:02] <juliank> qemu fails the emulation with invalid opcode, kvm with emulation failure
[11:03] <juliank> ah, not enough mram for the vm
[11:28] <juliank> yeah, more ram makes it work more
[11:28] <juliank> still aborts after a kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device later on
[11:29] <juliank> oh, but I have a new kernel, I should reboot
[11:40] <juliank> yes, yes, now it works :)
[11:40] <juliank> 5.3 is one of the worst kernels in recent history
[11:41] <juliank> so many bugs
[13:47] <xnox> vorlon:  infinity: why do we ship pool/ on the isos signed by the cdimage key, instead of simply doing "apt install --download-only" during squashfs building? especially since pool/ on subiquity & desktop images are there only for the offline install case and/or optional components, and not for general consumption.
[13:48] <xnox> (classic server iso has a more useful pool/ that is genuenly useful even post-install)
[13:48] <xnox> vorlon:  infinity: with apt install --download-only, image building gets simplier and drops using a GPG key.
[13:49] <xnox> (useful discussion with Chipaca and zygo got me thinking)
[14:38] <vorlon> xnox: historically there was no squashfs at all, so you couldn't do that.  So I don't think anyone's thought deeply about doing apt --download-only into the squashfs
[14:39] <xnox> vorlon:  does it sound crazy, or doable?
[14:40] <vorlon> it doesn't initially sound impossible to me, but it needs more thinking
[14:47] <rbasak> You'd have to be careful about how you call "apt-get update", because the moment you do, offline install will be broken
[14:47] <rbasak> (but that's not a blocker)
[16:08] <infinity> xnox: If you download a bunch of debs into the squashfs, then you need to exclude them in the copy when you install, which complicates the installer.  Not a blocker, but a point.  Personally, though, the location of the repo doesn't matter to me, I still want it signed, cause it's too easy to screw up what you're doing with apt when you mix signed and trusted sources.
[16:09] <infinity> xnox: But they don't need to be signed with the cdimage key to achieve that goal, and my plan when we moved to building ISOs in LP instead of just squashfses was to sign with an ephemeral key generated at build time, and trust that one in the installer.
[16:12] <xnox> infinity:  subiquity is already layered, and the point is that you do want to install those. Most of the time the pool will have like optional things in it needed in the target system, but not installed by default. something like 'zfsutils'
[16:13] <xnox> infinity: and there is no harm in copiying them to target, if they are small enough.
[16:13] <xnox> infinity:  or like we run apt cache clean when done
[16:14] <xnox> infinity:  i'm trying to reduce number of artefacts inside the .iso and things needed for subiqutiy netboot.
[16:14] <infinity> xnox: Uhh, what?
[16:14] <infinity> xnox: None of this is relevant for netboot.
[16:14] <xnox> infinity:  yes and no.
[16:14] <xnox> infinity:  airgapped netboot matters on s390x
[16:14] <infinity> xnox: In the netboot case, anything you'd find on the ISO pool is fetched from the archive.  See the "net" in "netboot".
[16:15] <xnox> infinity:  to be able to complete the install from the iso, whilst netbooting that iso.
[16:15] <infinity> xnox: Airgapped netboot implies a local mirror, dude.
[16:15] <xnox> infinity:  and z has no way to access an ISO normally
[16:15] <infinity> xnox: There's no story for netboot without an apt mirror.
[16:15] <infinity> xnox: Please don't invent one.
[16:15] <xnox> infinity:  well there could be =)
[16:15] <infinity> There never has been.
[16:15] <infinity> Please don't go out of scope.
[16:15] <xnox> infinity:  dude stop. i know it's not a requirement.
[16:16] <infinity> The whole point of "netboot" is a very minimal boot artifact that bootstraps you into doing the rest from an archive mirror.
[16:16] <infinity> It's not just "not a requirement", it's entirely antithetical.
[16:16] <xnox> infinity:  but instead of having: base, installer, modules, pool/, kernel, initrd I am thinking that we could restructure subiquity iso for it to only be: base.squashfs, installer.squashfs, kernel, initrd
[16:16] <infinity> Moving parts of the archive into the netboot to avoid the archive is the opposite of what netboot is for.
[16:17] <xnox> which can complete offline installs, or netboot installs, without needed to have access to cdrom mount which contains base/installer/kernel/initrd
[16:17] <xnox> infinity:  no, the point of netboot is not at all to be minimal =)
[16:17] <xnox> infinity:  the point of netboot that it does network boot. The minimal is not in scope at all.
[16:18] <xnox> infinity:  cause i am downloading in RAM the full 500MB+ iso and booting subiquity off it, in full.
[16:18] <infinity> Yeah, fine.  "minimal". :P
[16:18] <infinity> But also, you're not dowloading the full ISO, just squashy bits.
[16:18] <infinity> So sort of minimal. :P
[16:19] <xnox> and mirroring contents of an iso, and keeping all the pieces matching sounds hard, hence point to an .iso (which is just one file) is  more simple for the user.
[16:19] <xnox> in turns out subiquity is coupled to the contents of just not the squashy bits =/
[16:19] <xnox> and it's too many things to remember to download, hence download .iso is easier, and casper supports that a lot better.
[16:19] <infinity> It's coupled to the pool?  I can't see how or why that would be, since it didn't even HAVE a pool until recently.
[16:20] <xnox> not to the pool per-se, but that there is /cdrom mount with a valid pool
[16:20] <xnox> and that there is different squashfs, called in particular way and moutable
[16:20] <xnox> and other auxiliry files in a specific layout, which keeps on changing from release to release.
[16:20] <xnox> anyway
[16:21] <infinity> I assume mwhudson has been consulted with your plans for his spec?
[16:21] <xnox> that's why i think it's obsurd the amount of things we have in an .iso and if combinding things inside the iso will make things a lot easier to manage / build / mirror / netboot / offline-install
[16:22] <xnox> i'm just doing implementation prototype now, and realising that some of the things we speced out, were a lot more pretier in the spec than in practice.
[16:22] <xnox> anyway.
[16:22] <infinity> Anyhow, I'm very much -1 on "just point to the ISO, who cares if it's twice the size of what we actually need".
[16:22] <xnox> simplifying contents of .iso is a tagent
[16:23] <infinity> People never had problems mirroring the old d-i netboot structures and unpacking them.  I don't see why this needs to suddenly be "hard".
[16:23] <xnox> infinity:  let me get the delta.
[16:23] <infinity> Multiple files isn't a killer.
[16:23] <infinity> Be sure to get the delta on an LTS point release ISO.
[16:23] <xnox> infinity:  they mirrored the one archive.
[16:23] <infinity> Which ships with two kernels, two sets of modules, etc, and you don't need all of that to boot one machine.
[16:24] <xnox> infinity:  d-i runs from an initrd, subiquity is a snap.
[16:24] <infinity> xnox: Yes, they mirrored the archive, and we identified that as a thing we need to figure out for this to work properly.
[16:24] <xnox> infinity:  and like maas does download cloud-image squashfs mounts that, and runs system from there curtin and all that.
[16:24] <infinity> How subiquity is packaged is entirely irrelevant.
[16:25] <infinity> Unless you're proposing snapd in firmware. :P
[16:25] <xnox> well i don't want to create a new artefact at all. I.e. such that an iso has the things one needs to either unpack, or publish, or boot directly.
[16:25] <xnox> *any new*
[16:26] <infinity> Okay, making the ISO "unpackable" seems not terribly difficuly.  But I don't see how that would look a lot different from today's ISO.
[16:28] <infinity> Not that "unpacking an ISO" is really any easier for people than "mirror these bits".
[16:28] <xnox> infinity:  point is that today, when doing network boot, casper doesn't know the layout and the contents of the iso. It blindly mounts all the things it sees, in alphabetical order, and boots it. And pieces inside it have loosely coupled dependencies on the rest of the iso layout.
[16:29] <infinity> You're making that sound a lot worse than it is.
[16:30] <xnox> and i don't feel like encoding in casper filenames to walk/download, or which ones are mandatory, if normal boot path doesn't. Cause we change livecd-rootfs and eventually add code to use new pieces. without touching casper normally.
[16:34] <LocutusOfBorg> jamespage, hello, please src:gnocchi fix on armhf autopkgtests?
[16:34] <LocutusOfBorg> you probably want to add curl to test dependencies
[16:35] <LocutusOfBorg> (assuming curl is available might be not the best idea=
[16:36] <jamespage> yep (although it would be nice in test envs where consistent)
[16:38] <LocutusOfBorg> jamespage, this is true, I can't understand why curl is installed everywhere except armhf, but in any case if you use it directly, a dependency is the best thing to do...
[16:38] <LocutusOfBorg> Laney, ^^ do you happen to know why?
[16:38] <Laney> no, something in cloud images depends on it presumably
[16:39] <jamespage> most likely - its part of the server and cloud-image tasks
[16:39] <jamespage> LocutusOfBorg: anyway fix uploaded
[16:39] <LocutusOfBorg> thanks
[16:44] <xnox> infinity:  like people will not mirror .disk/info and .disk/casper-uuid-generic correctly =) unless you ask for url to the full .iso =)
[16:46] <infinity> xnox: Okay, so if casper doesn't see squishyfses, it tries to grab the ISO from a well-known location (or a preseeded location, if given), mounts, and carries on.
[16:46] <infinity> xnox: That doesn't imply a layout change is necessary either.
[16:47] <xnox> infinity:  yeah. but enqually the current iso listing is, well.... tasteless
[16:48] <xnox> and not as cute as for example maas artefacts. kernel + initrd + filesystem (which is both used for ephemeral boot, provisioninged, and is deployed/layed on disk)
[16:49] <xnox> infinity:  not sure about the well-known location, cause at the moment initrd is coupled to the iso contents. I.e. it must be at least the same kernel abi. And the well known location changes, for a given initrd.
[16:49] <xnox> that's why i kind of want to decouple things more, such that vmlinuz+initrd pair can use/deploy many .isos; i.e. not necessarily the one matching the build that vmlinuz+initrd came out of.
[16:50] <infinity> Then you want kexec.
[16:51] <infinity> Comparing this to maas isn't fair, as their initrd is also the entire "installer", much like d-i.
[16:51] <infinity> We're getting our installer from a massive rootfs that must actually be usefully bootable.
[17:16] <xnox> infinity:  no their initrd is not the intire installer.
[17:17] <xnox> infinity:  their initrd has cloud-config, which they drive ephemerally booted cloud-image squashfs without kernel (the lxd squashfs)
[17:17] <xnox> which talks to maas to run curtin, talk back to maas, and shutdown.
[17:18] <xnox> so their initrd has all the kernel modules + cloud-url / overlayroot stuff
[17:20] <infinity> xnox: Oh, right, they have two rootfses.  Forgot about that bit.
[17:22] <xnox> infinity:  i still have no idea why we ship linux-firmware package on s390x
[17:22] <xnox> is it useful for like mellanox scsi cards? because that's like the only peripheral that could be used on the mainframe
[17:24] <infinity> xnox: Because it's arch:all and a dep of the kernel.  If literally no drivers for s390x reference firmware in it, request the dep be dropped from s390x kernels?
[17:24] <infinity> xnox: (the kernel team should have tooling to discover said deps)
[17:24] <sarnold> mellanox scsi?
[17:26] <xnox> is it scsi
[17:27] <xnox> Mellanox ConnectX®-4 LX adapter as the, IBM 10GbE RoCE Express2, FC# 0412, offers the best cost effective Ethernet adapter solution for 10Gb/s Ethernet speeds
[17:27] <xnox> sarnold:  what is that?
[17:27] <xnox> PCIe not Scsi right?!
[17:27] <xnox> https://blog.mellanox.com/2017/08/mellanox-delivers-connectx-4-lx-ibm-z14/
[17:28] <sarnold> man that's one catchy name
[17:30] <infinity> sforshee: How feasible would it be to conditionalise linux-firmware deps in the kernel build with a build-time scan of objects to decide if they actually have external firmware deps in the first place?
[17:30] <infinity> sforshee: (One could do this scan manually and twiddle deps manually too, but then the world explodes the first time that situation changes for $flavour and no one notices)
[17:31] <xnox> sarnold:  infinity:  so 13% of our subiquity s390x iso is linux-firmware.deb
[17:32] <xnox> probably more than that, cause pieces of it are copied into initrd.ubuntu and hte xecond ubuntu.ikr initrd.
[17:32] <xnox> *the second
[17:32] <infinity> Technically, that would also mean most linux-firmware deps would move from the metapackage (where they live today) to linux-modules-extra-ABI, which actually has the dep in most cases.
[17:33] <infinity> xnox: I'm not sure that's a useful datapoint I care about, since removing it from s390x doesn't help amd64, and s390x is the enviornment least likely to care about the installer being a bit chubby.
[17:33] <infinity> xnox: But from the POV of things being clean, I agree that useless l-f deps shouldn't exist.
[17:33] <xnox> infinity:  currently subiquity requires pool to be there, but i think it can be empty. Pool is 20% of the iso, most of which is the kernel debs, as things are small and tiny below linux-modules-extra.
[17:34] <xnox> infinity:  and currently subiquity would use the .deb from the pool, even if the network is available, if the one over the network is no newer.
[17:34] <infinity> Yes, by design.
[17:34] <infinity> But not ideal for netboot.
[17:35] <xnox> (for example installing daily devel image, one will have to fetch linux.deb into target anyway, so doesn't matter if it comes from the predownloaded .iso or the archive) There is runtime RAM penalty.
[17:35] <infinity> Anyhow, I tihnk "make it netboot" takes first priority, then "figure out how to put it on a diet" might come second.
[17:36] <xnox> so i'm not sure there is a massive difference in downloading a few (less than 10) files that add up to 381 with 80 later (460 total) or 575MB in one go.
[17:36] <infinity> I am somewhat concerned about the RAM usage in general, but I hope that's just me living in the past when computers didn't have gobs of RAM.
[17:37] <xnox> to me, it sounds interesting point that maas deploys useful baremetal machine; they used to have d-i & cloud-image based installer, and use cloud-image based installer and do fetch over the network and boot in ram the cloud-image squashfs.
[17:38] <xnox> realistically, our cloud-image squashfs is small enough to do that, on all but extra-small / small VM sizes in the cloud.
[17:38] <xnox> and all bare-metal servers are larger than S sizes in amazon.
[17:39] <xnox> infinity:  i agree that it should "netboot" as a priority, and optimizations / changes can be iterated on top of htat.
[17:39] <infinity> Holding an ISO in RAM probably throws those calculations off a bit, but point taken that MaaS basically does the same thing, ish, just slightly slimmer.
[17:44] <xnox> infinity:  i am pondering in my head, how i can come up with something that can be a thin/independant overlay that can be put on top of the maas squashfs. Or even if we could just use cloud-image with elaborate config of "talk to snap store, fetch subiquity, and please run it" =)
[17:47] <infinity> I don't think we want to reimplement MAAS here.
[17:47] <infinity> Having two rootfses instead of one isn't really going to help subiquity, when it needs to function with only one for the ISO already.
[17:48] <xnox> infinity:  true
[17:48] <xnox> infinity:  i am also still pondering to have more UI in casper initrd
[17:49] <xnox> infinity:  like "I didn't find cdrom, or drive, and no network was provided", would you like to "ip=dhcp? url=http://releases.ubuntu.com/{release}/ubuntu-server-live.iso"
[17:49] <xnox> infinity:  or like able to type in ip= command, vlan, url from there.
[17:49] <infinity> s/casper/subiquity initramfs hook that ends up in casper initrd/ maybe?
[17:50] <xnox> such that one doesn't need to reboot, if there is console access (remote kvm) and one made a typpo
[17:50] <xnox> yeah
[17:50] <xnox> basically interactise it to be on par with network-console d-i page
[17:50] <infinity> I wouldn't be against such fanciness for v2 (or v0.2 :P)
[17:50] <xnox> (which is what s390x people use today)
[17:51] <infinity> The only problem you have with early interaction is that we won't do keyboard/locale setup until we enter subiquity.
[17:51] <infinity> So it assumes everyone knows how to blindly type on pc101 on their local keyboard.
[17:51] <infinity> s/pc101/us101/
[17:52] <infinity> Unless we can do it so early that we're still getting raw keyboard input.
[17:53] <infinity> Which might be true in early initrd.  I'm not sure how "configured" the linux console is before we do things to it.
[17:53] <infinity> As someone whose chosen keyboard layout happens to also be the accepted default everywhere, I don't usually have to think about this sort of thing.
[17:59] <sforshee> infinity: on the surface it seems feasible to base the linux-firmware dep on scanning objects in the package, I'd have to play with it to see how hairy it works out to be in practice
[18:02] <infinity> sforshee: Yeah, I figure it's not as simple as one sentence on IRC.  But I was also pretty sure you already have tools for scanning module->firmware relationships that you use for d-i udebs, and also just to know if you're missing junk (for HWE, etc).
[18:03] <infinity> sforshee: So turning that into a "if binary package foo needs firmware, it should depend on it, if not, not" would move firmware deps to modules or modules-extra (or sometimes nowhere for some flavours), which feels more "correct".
[18:05] <infinity> sforshee: To get it right, I imagine you'd also have to build-dep on linux-firmware to know what it ships.  And flavours with their own firmware packages would get those in the build-deps too.  Or something.  Maybe.  I dunno.  Also happy to have you file it under Flying Cars, decide it's too much trouble, do a one-time scan of s390x for xnox to decide if you can drop the l-f dep from generic/s390x meta deps, and call it done. :P
[18:06] <sforshee> infinity: firmware required my modules is supposed to be declared in the .modinfo secion, so it's pretty easy to get at. Not all drivers are so straightformward though, e.g. iwlwifi will accept a range of firmware versions but only declares a single version in .modinfo
[18:06] <sforshee> still, one would hope that version is in fact in linux-firmware
[18:09] <infinity> sforshee: I try to pretend iwlwifi doesn't exist, except every three years when it's laptop buying season and I have to begrudgingly admit that theirs works better than everyone else's and buy another one.
[18:09] <sforshee> infinity: must be nice
[18:10] <infinity> Maybe the free ath drivers are finally on par by now, I haven't done side-by-side for a while.
[18:11] <sforshee> yeah me neither, they seemed to be doing pretty good for a while but I'm not sure now
[18:19] <xnox> infinity:  i wonder if we will find that we do compile wifi drivers on s390x even though that's impossible to use
[18:22] <infinity> xnox: I feel like the maintainer of the s390x port should know the answer to that. :)
[18:28] <xnox> infinity:  if only they would rotate me into the kernel team finally
[18:28] <infinity> xnox: You need to be in the kernel team to look at /boot/config*?
[18:29] <xnox> infinity:  nah =) but like digging and optimising it.
[18:29] <infinity> I guess I should stop reading things not produced by my team. ;)
[18:29] <xnox> enotime for that
[18:29]  * xnox checks which version zfcpdump-kernel is at
[18:29] <xnox> https://launchpad.net/ubuntu/+source/zfcpdump-kernel is v4.13
[18:29] <infinity> Pretty sure if we rotated you into the kernel team, bjf would murder you in the first week.
[18:29]  * xnox is happy we shipped it as a full source package
[18:29] <infinity> Likely for the best that you're not. :P
[18:31] <xnox> well i'll move to portland to rotate into the kernel team
[18:31] <infinity> Moving to Portland gets you rotated into management.
[18:32] <sarnold> look if you joined the channel you're going to have to move here
[18:32] <sarnold> don't worry you'll like birkenstocks I swear
[18:33] <infinity> I hear the current administration is very sympathetic to Russians.  No better time to immigrate.
[19:24] <ejat> hi, why gnome-session-bin & gnome-session-common package version in eoan still 3.33.92-1ubuntu1 where gnome-shell already 3.34.0-1ubuntu1?
[19:25] <seb128> ejat, because no-one updated gnome-session yet, but there are no change out of translations in the update ...
[19:26]  * ejat facing re-login issue (cant login)after locking screen / come back from sleep
[19:27] <ejat> how to debug/get the log
[19:27] <ejat> just recently i faced this issue
[19:28] <ejat> using eoan -proposed
[19:47] <ejat> anyone can advise me how to debug/get log can't login after locking screen/ come back from sleep ?
[19:56] <ahasenack> can you switch to a console? ctrl-alt-f2 for example
[20:00]  * gQuigs has found ctrl-alt-f5 the most reliable, with the way gdm/gnome-shells now work..
[20:00] <ejat> ahasenack: yups ... like gQuigs say
[20:33] <mwhudson> infinity, xnox: i'm all for making the ISO layout simpler but it's not going to be hard to get subiquity to not put file:///cdrom in sources.list if it's not there
[20:34] <mwhudson> also my last attempt to simplify casper-helpers broke two other things i had no idea existed so eh


[13:59] <cmaloney> OMC is on http://metalinjectionfm
[13:59] <cmaloney> correction: OMC is on http://metalinjection.fm


[05:24] <Mrokii> schnoodles: I had exactly the same problem. I created a an entry in fstab to solve it. But it's weird that system settings doesn't do that by itself, I think. Apparently its automount-switches don't work.
[05:26] <schnoodles> Thats a bit odd seeing I originally set it up through system settings. Something has gone a bit funky.
[05:27] <schnoodles> I dont really want to be playing around with fstab directly (I know its not daunting) because then I will not be tracking if it is ever fixed.
[05:34] <Mrokii> Understandable.
[05:39] <acheronuk> Mrokii schnoodles: fixing. there is a patch that fixed in 18.04, but which seemingly got missed for the backports
[05:45] <valorie> aha, I was wrong
[05:45] <valorie> thanks, acheronuk
[05:46] <acheronuk> or at least. there is a fix for a very similar sounding bug I backported for 18.04
[05:46] <Mrokii> acheronuk: Thanks for the info.
[05:52] <maku> THIS IS A FREENODE BREAKING NEWS ALERT!!  TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
[05:52] <maku> THIS IS A FREENODE BREAKING NEWS ALERT!!  TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
[05:52] <maku> THIS IS A FREENODE BREAKING NEWS ALERT!!  TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
[05:52] <maku> THIS IS A FREENODE BREAKING NEWS ALERT!!  TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
[05:52] <maku> THIS IS A FREENODE BREAKING NEWS ALERT!!  TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
[06:42] <schnoodles> Awesome thanks acheronuk. I thought it must have only been a new addition.
[07:24] <lordievader> Good morning
[07:37] <qcorvine> hi! all  :)
[07:41] <lordievader> :wave
[07:41] <lordievader> 👋*
[08:29] <BluesKaj> 'Morning folks
[09:07] <acheronuk> Mrokii: assuming it is the bug I think it might be, fix is now in backports ppa. please update
[09:48] <R13ose> Hi
[09:49] <R13ose> I am in busybox after I restart but unsure how to fix this.  Any ideas?
[09:55] <lordievader> R13ose: What does it complain about?
[09:56] <R13ose> I am not sure what the error was
[10:00] <R13ose> lordievader: I used fsck but only sda5 didn't say no file or directory
[10:01] <lordievader> Without any error I can not really make suggestions.
[10:02] <R13ose> Thanks
[10:15] <R13ose> How do I figure out where the root filesystem is?
[10:16] <Mrokii> acheronuk: Thank you again. I think I have backports activated.
[10:29] <R13ose> lordievader: working now
[10:45] <enrico_> hallo bin im falschen Chat. Wo finde ich den Sidution Irc Channel?
[10:46] <lordievader> !de | enrico_
[10:47] <enrico_> Thanks
[13:21] <D0U91E> if I am running the beta when the final comes our I will just be able to "sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade" to get 18.04 final right?
[13:21] <D0U91E> our = out
 yes
[13:32] <D0U91E> HELP!!! LoL :)
[20:16] <benbloom> Hi there. There's tons of stuff online but they all seem out of date. I'm wondering if someone would help me with Chrome in Kubuntu: my system keeps locking up. It's totally frozen (no mouse movement, can't ctrl-alt-F1). It  happens whenever I use resource intensive web apps in chrome esp if I leave them open and let the computer sit. I may have messed with my swap or nice settings sometime ago, but not sure what I did (so long ago
[20:16] <benbloom> ) seems like a memory problem?
[20:55] <Guest49999> hola
[20:55] <Guest49999> es mi primera vez aqui
[20:58] <acheronuk> !es | Guest49999
[21:09] <Guest54899> gue
[21:12] <Guest54899> Guest49999, de donde sos?
[21:18] <Guest13230> fihsakgfh


[00:31] <haunt> !op
[00:35] <dax> haunt: hello
[00:38] <dax> haunt: something we can help you with?
[00:52] <Unit193> He does that.
[01:55] <dax> maybe he is haunting the channel :3
[16:27] <ikonia> if br4 is trying to be clever with guest - he's gone
[16:29] <ikonia> what a shame, I'd have been happy to help him with his selinux issues, it's not everyday you get something unusual / interesting
[19:22] <Pici> :/
[19:25] <hggdh> Empyrium: anything we ca do for you?
[21:05] <dax> sigh, was hoping that'd be fixed or k-lined after months, guess not