[00:47] <maco> popey: no
[00:47] <popey> it is good, you may like it
[00:48] <popey> http://twitter.com/#!/thedrwhopodcast http://www.thedoctorwhopodcast.com/
[00:55] <IdleOne> ldunn: poke someone for your + or I banning you for idling
[00:55] <rww> IdleOnery
[00:56] <rww> Ornery? i forget how that word goes
[00:56] <IdleOne> ornery is right
[00:56] <rww> IdleOneiric
[00:56] <IdleOne> what's it to you!
[00:56] <IdleOne> careful I am feeling froggy
[00:57] <ldunn> IdleOne: but who do I poke? :P
[00:57] <IdleOne> poke the IRCC members
[00:58] <IdleOne> you should know this already!
[00:58] <rww> poke IdleOne, because he deserves it
[00:58]  * ldunn pokes rww in the eye
[00:58] <tsimpson> teh powaz will be setup soon-ish
[00:58] <IdleOne> that is one of the pokies
[00:58] <IdleOne> we poke, they tells us soon and we wait
[00:59] <ldunn> tsimpson: Mind +v'ing me? :)
[00:59] <rww> IRCC all forgot the ubuntu-irc-council password is my bet ;P
[00:59] <rww> get IdleOne to do it, he's idle
[00:59] <tsimpson> it's late, so I don't want to go messing with access lists/launchpad teams
[01:00] <IdleOne> code for: tsimpson is drunk a lil' bit
[01:00] <ldunn> danke
[01:00] <tsimpson> just don't /part ;)
[01:00] <IdleOne> haha
[01:01] <LjL> now you gave ldunn an excuse to stay awake 24h ;(
[01:01] <ldunn> LjL: I have a bouncer, silly
[01:01]  * LjL bounces ldunn
[01:02] <ldunn> higher!
[01:02] <rww> ldunn: now you can ask /other people/ to get off the lawn instead!
[01:02]  * rww puts ldunn on the last space shuttle launch
[01:32] <IdleOne> Thank you.
[02:00] <IdleOne> !unity =~ s/GNOME see/GNOME, see/
[02:00] <Logan_> wait, no, that should be a semicolon :3
[02:01] <IdleOne> lol
[02:01] <IdleOne> you serious?
[02:01] <IdleOne> !unity =~ s/GNOME, see/GNOME; see/
[02:01] <Logan_> yes, I'm serious :P
[02:01] <IdleOne> should be applied
[02:01] <Logan_> !unity
[02:01] <Logan_> nope :P
[02:02] <IdleOne> !unity =~ s/GNOME, see/GNOME; see/
[02:03] <Logan_> IdleOne: wait, no, it should be a colon
[02:03] <Logan_> just kidding :D
[02:03] <IdleOne> I was about to make a comment about colons and my foot
[02:03] <IdleOne> :)
[02:03] <Logan_> hah
[02:12] <rww> I made the hacky rww perl hacks of doom support +q and +e as well as +b. Suddenly, the FloodBots are in 2nd place.
[02:12] <rww> (it just tracks +e, doesn't include them on scoreboard)
[02:15] <rww> If there are any #xubuntu ops around, it's currently getting join/quit flooded.
[02:15] <rww> (yay badly-configured clients)
[02:16] <rww> elky ^^
[02:16] <elky> am i?
[02:16] <elky> or just as the irc nick which I don't have the pass for
[02:17] <rww> one sec, I might have a fix anyway
[02:17] <sdhasu> I demand to be banned
[02:17]  * rww banforwards the guy from #ubuntu, imagines that will decrease the Flooding
[02:18] <maco> rww: i was trying to do that but couldnt figure out where to forward
[02:18] <rww> elky: looks like not. Yes, you're a named op in there.
[02:20] <sdhasu> ban me i am desperate
[02:20] <sdhasu> plese ban me
[02:20] <IdleOne> sdhasu: would you like to talk about why you want to be banned?
[02:21] <sdhasu> it will make me high
[02:21] <IdleOne> nhandler: sdhasu is abusing the bot in -kernel and requesting a ban here.
[02:21] <sdhasu> yes ban me =)
[02:23] <nhandler> sdhasu: Why not just leave on your own accord?
[02:24] <sdhasu> ban!
[02:24] <sdhasu> I will wait here all night until tomorrow until i am banned
[02:24] <IdleOne> sdhasu: I suggest you consider this decision for 72hrs. You may change your mind.
[02:25] <rww> hehe
[02:40] <elky> "It will make me high" Is certainly one of the better reasons I've heard...
[02:58] <rww> I lied, I'm cleaning out Floodbot modes after a week now, not waiting until we hit 400. It's a pain when they lose their owner and I have to think.
[08:57] <oCean> hi!
[08:59] <Flannel> Howdy oCean, what can we do for you?
[08:59] <jussi> hi oCean, congrats
[08:59] <oCean> yes, thanks
[08:59] <Flannel> Ah yes.
[08:59] <oCean> :)
[09:00] <Flannel> Sorry oCean, haven't internalized that list yet :)
[09:00] <oCean> ah, ok. No worries
[09:22] <oCean> So, at this point, is there anything i need to learn, to familiarize myself with?
[09:22] <oCean> to promise? :)
[09:33] <Flannel> oCean: Don't panic.
[09:33] <oCean> never
[10:30] <jussi> oCean: yes, the irc guidelines and the operator guidelines are 2 good starting points (although i expect you know the user ones already)
[10:31] <jussi> oCean: https://wiki.ubuntu.com/IRC/IrcTeam/OperatorGuidelines
[10:33] <jussi> for everyone elses pleasure, we will be sorting out mentors soon. If you feel like you could take on one of these poor lost lambs and train them up well, let us know.
[10:36] <bazhang> oCean, hi!
[10:38] <popey> jussi: nice idea
[10:43] <jussi> popey: we have done this in the past, but with the ircc doing the mentoring. Ideally we will have experienced ops taking the burden a bit.
[10:43] <popey> good stuff, lemme know if someone is up for mentoring me.
[11:13] <oCean> bazhang: hey
[11:13] <oCean> jussi: that seems a fine idea
[11:43] <LjL> oCean: hi
[11:44] <Pici> Hiya new ops!
[11:44] <Pici> My tip for new ops: Don't be afraid to ask the rest of us if you're unsure about anything.
[11:45] <LjL> Pici: tell me how 2 ban
[11:46] <Pici> LjL: /msg chanserv op LjL; /mode +b *!*@ubuntu/member/ljl
[11:47] <LjL> Pici: not /cs akick #ubuntu add *!*@ubuntu/member/ljl?
[11:47] <Pici> LjL: If you want to do it the fancy, way, sure.
[13:18] <jussi> LjL: what was the forward about?
[13:18] <LjL> jussi: ice_'s final "fuck you" after insisting with speaking Chinese
[13:18] <jussi> LjL: does the chinese mean that?
[13:19] <bazhang> #ubuntu-hk only has ubuntlog in it
[13:19] <LjL> jussi: no he said that in english :P
[13:19] <Pici> jussi: he said it in english
[13:19] <ikonia> LjL: not the first time for ice either
[13:19] <jussi> oh, I missed that.
[13:19] <jussi> LjL: please make sure you comment on the forward with ubottu :)
[13:20] <LjL> jussi: i already did, don't nanny me :P
[13:20] <Pici> I'm not an op in -women, but it looks like the 'ola bruder' guy is there, someone may want to take a look.
[13:20]  * jussi hugs LjL
[13:20] <LjL> jussi: remember i was always a promoter of comments/@mark ;)
[13:21] <tsimpson> which reminds me, I need to make ubottu recognise our new ops
[13:21] <Pici> @sabdfl
[13:21] <LjL> tsimpson: i'd like factoid editing ability too if that's not a problem
 Greetings #ubuntu. This is the closest freenode has to a hangout for girls
[13:24] <Pici> .
[13:26]  * LjL does the eyeroll
[13:27] <oCean> LjL: hai
[13:33] <tsimpson> LjL: technically you should have had factoid editing already, so I added it
[13:37] <tsimpson> ldunn, oCean, Corey: you lot have what's known as "restricted editing", you can edit factoids, but only in this channel. the restriction only counts while you are probationary (https://wiki.ubuntu.com/IRC/IrcTeam/Probation ), this page gives usage information on the factoid plugin for ubottu: http://ubottu.com/devel/wiki/Plugins#Encyclopedia
[13:40] <LjL> tsimpson, i suspect you locked me out of the bantracker in the process somehow, i @btlogin but i get anonymous user :P
[13:40] <tsimpson> does @btlogin give you any error?
[13:40] <LjL> tsimpson: nope, it gives me a session link
[13:41] <tsimpson> strange, then it should work
[13:41] <LjL> tsimpson: i had to @login first though, maybe because of my new hostmask
[13:42] <LjL> tsimpson: it works now
[13:43] <tsimpson> probably dumb sqlite and locking issues
[14:58] <Pici> maco, I'm not sure if you saw my mention of this earlier, but that fellow in #ubuntu-women is someone who reguarly harrasses ikonia and I.
[15:50] <maco> nope didnt see you say that
[16:05] <ikonia> Pici: he'd also agreed promised to stop
[16:05] <ikonia> hence removing all the bas
[16:05] <ikonia> bans
[16:13] <Pici> ikonia: I didn't know that.
[16:21] <tsimpson> Corey, ldunn, and oCean please make sure to join #ubuntu-ops-team at some point
[18:06] <q_a_z_steve> Can someone unban me in #xubuntu please?
[18:09] <jussi> knome: charlie-tca about?
[18:09] <jussi> q_a_z_steve: what did you do to get banned?
[18:10] <jussi> ahh
[18:10] <jussi> hang on, Ill fix it.
[18:10] <jussi> q_a_z_steve: I assume your connection is fixed?
[18:11] <jussi> q_a_z_steve: ?
[18:13] <q_a_z_steve> I should be good. Looking into more "SendQ" stuff today, not sure what that is. I cut my autojoin in half, will that help?
[18:17] <jussi> q_a_z_steve: Ive removed the ban, pleas check it out some more - might be worthwhile to ask in #freenode also
[18:17] <jussi> (about network related stuff)
[18:17] <q_a_z_steve> Thanks, yeah
[18:17] <q_a_z_steve> I'm out.
[18:31] <Pici> augh
[19:39] <Corey> tsimpson: Ping, when you get a few.
[19:40] <tsimpson> Corey: go ahead
[20:58] <ShadesEdge_> Hello
[20:58] <Pici> hi
[20:58] <ShadesEdge_> Can someone explain me why my nick ShadesEdge is banned from #ubuntu?
[20:58] <LjL> let me look
[20:58] <ShadesEdge_> Someone quoted me there
[20:59] <Pici> LjL: thanks, I'm actually leaving in a few minutes and wouldn't have had time to follow through.
[21:00] <LjL> ShadesEdge_: i don't see a ban. are you able to join at all, and just can't speak, or can't you join?
[21:00] <ShadesEdge_> From my nick ShadesEdge?
[21:00] <LjL> yes
[21:01] <ShadesEdge_> ???
[21:01] <rww> webchat client that /nicked, I'd guess that's why
[21:01] <ShadesEdge_> It said that I was banned
[21:01] <LjL> ShadesEdge_: oh i see
[21:01] <LjL> ShadesEdge_: webchat clients are treated a bit specially
[21:01] <ShadesEdge_> Oh...
[21:01] <ShadesEdge_> Ok
[21:01] <LjL> ShadesEdge_: so you should avoid changing your nickname while on it
[21:02] <ShadesEdge_> I ghosted my nick many times
[21:02] <ShadesEdge_> :S
[21:02] <Pici> (aside, popey and I and a few others are discussing ubuntu-tweak in #ubuntu-comminity-team right now, some people seem to like it)
[21:02] <ShadesEdge_> Thanks alot. Goodbye :0
[21:02] <ShadesEdge_> :)*
[21:03] <LjL> oh lord the power user thing again :|
[21:04] <rww> ^
[22:45] <niko> btw, idoru is in #ubuntu-offtopic, what's your test delay and duration about him ? and also target
[23:24] <topyli> niko: we were supposed to review idoru's performance in #ubuntu last week, but our meeting got cancelled
[23:26] <topyli> i suppose we could review both #ubuntu and -ot in the next one on 11th
[23:26] <topyli> need to talk with the rest of the council


[01:27] <kwwii_> night
[03:41] <lapo> hi
[04:11] <mhb> hello everyone
[05:15] <viper550> Hello, how's everyone this morning?
[05:18] <mhb> viper550: I'm fine this evening, thank you
[06:10] <ag0ny> good evening, morning or day
[06:12] <ag0ny> could someone please tell me or point me in the right direction where i can find information about how to change the color of the clock applet just like themes do it?
[09:50] <ag0ny> can someone tell me what entry in the gtkrc file is for the font color in the gnome-panels?
[09:54] <jimmac> howdy
[09:54] <jimmac> guys, do you know who's responsible for the ubuntuforums.org skin?
[09:55] <ag0ny> sorry, i dont
[10:13] <jimmac> ok, mailed the list instead
[10:13] <jimmac> cheers and take care artsy fellas! :)


[13:50] <LocutusOfBorg> any archive admin to remove fcl/armhf pretty please? this will make kido and tinyxml2 transitions end
[13:51] <LocutusOfBorg> already removed in debian
[17:39] <bdmurray> tjaalton: In your blog post at https://tjaalton.wordpress.com/2016/03/11/no-catalystfglrx-video-driver-in-ubuntu-16-04/ you mention HWE stack and 14.04.  Was it discussed with AMD?
[17:40] <tjaalton> bdmurray: yep
[17:41] <bdmurray> tjaalton: What was / is the plan?
[17:42] <tjaalton> plan of what? there is amdgpu-pro -driver (beta) which folks are free to try. it's not in the archive because the packaging is not open source yet aiui
[17:42] <bdmurray> tjaalton: Currently people with fglrx installed are encountering failures when trying to upgrade to lts-xenial e.g. https://paste.ubuntu.com/23095154/
[17:43] <tjaalton> well it certainly should just remove fglrx
[17:43] <bdmurray> tjaalton: what about "users relying on pro/workstation class features"?
[17:44] <tjaalton> they are either screwed or have to download the "pro" driver manually..
[17:44] <tjaalton> this is all in the release notes
[17:44] <tjaalton> written by alberto I think
[17:47] <bdmurray> slangasek: Do you have an opinion on just removing fglrx for 14.04 users?
[17:47] <slangasek> bdmurray: if they're on the HWE stack, I think that's the right answer
[17:48] <slangasek> maybe with an added warning in the hwe-support output?
[17:48] <bdmurray> slangasek: I was looking through forums or askubuntu and one user was surprised they were on the HWE stack - they had downloaded and installed 14.04.2 or so and didn't know the implications of that.
[17:49] <tjaalton> yeah one option is to fall back on 14.04.1
[17:49] <bdmurray> slangasek: So they'd made no concious choice to be using the HWE stack.
[17:49] <slangasek> sure
[17:49] <slangasek> but I don't think we want update-manager to give them options "upgrade stack or downgrade?"
[17:50] <slangasek> we can add some messaging about how to get onto the trusty stack if that's what they need to be using
[17:50] <slangasek> (maybe just in the wiki page)
[17:52] <bdmurray> slangasek: Okay, so add a warning to hwe-support-status re fglrx tell them to really read the wiki, update the wiki, and upload xserver-xorg-core-lts-xenial w/ breaks on fglrx, fglrx-core, fglrx-updates, and fglrx-updates-core.
[17:54] <slangasek> bdmurray: yes, +1 from me for that
[17:54] <tjaalton> additional breaks?
[17:55] <slangasek> tjaalton: the breaks are needed in order for the resolver to reach the correct solution of removing fglrx, instead of bailing
[17:55] <bdmurray> tjaalton: additional? I don't see any for -lts-xenial and fglrx
[17:55] <tjaalton> okay then
[17:55] <tjaalton> bdmurray: it doesn't provide the driver abi which xserver needs
[17:55] <tjaalton> that alone should make it uninstall
[17:56] <tjaalton> which has worked fine so far for other drivers at least..
[17:56] <slangasek> that's a nice theory ;)
[17:56] <bdmurray> tjaalton: well, it didn't - https://paste.ubuntu.com/23095154/
[17:56] <tjaalton> I saw that
[17:56] <slangasek> it works for the other drivers because there's a newer version that can replace them
[17:57] <tjaalton> no I mean if a driver wasn't rebuilt
[17:57] <slangasek> ok
[17:57] <tjaalton> it'd remove the driver and -all
[17:57] <slangasek> but the other piece is that fglrx has reverse-dependencies
[17:57] <tjaalton> been hit by that a few times..
[17:57] <slangasek> that permutes the weights apt assigns for removal
[17:57] <tjaalton> yeah that's probably it then


[00:17] <Gibby_2> hmm all i did was change the shutdown command to pm-suspend, i couldn't wake it up so i pressed the power button now it complains about the timezone being incorrect but the /etc/timezone file is correct... :(
[01:38] <hednod> I want to convert my mythbuntu system which is currently just a single disk non-raid into a two-disk software (md) raid.  The raid part I have down, i've down it before, but Ubuntus method of managing grub is.. beyond complicated.  How/where do I edit the right files to indicate the new device names?
[01:38] <hednod> I dug around on google first but did not find anything
[02:38] <dumbledore> hey all.. I am trying to connect my mythbuntu computer to the TV.. I have Svideo out on the computer and composite in on the TV. But I am not able to do so. I have my xorg.conf here http://mythbuntu.pastebin.com/YL30rF7K and the Xorg.log here http://mythbuntu.pastebin.com/6K4Hx96A. Could someone please tell me what I am doing wrong? I appreciate the help.
[03:43] <Gibby_2> dumbledore: you get nothing on the tv?
[03:43] <dumbledore> Gibby_2 Nothing .. A blue screen
[03:44] <Gibby_2> TV type/model?
[03:45] <dumbledore> TV is an older JVC.. which has two composite inputs..
[03:51] <dumbledore> Gibby_2: Do you see anything in the logs or the xorg.conf that I should change/add?
[04:03] <Gibby_2> do you have a monitor hooked up also?
[04:04] <dumbledore> no Gibby.. I dont have a monitor hooked on..
[04:04] <Gibby_2> an which OS ubuntu or mythbuntu?
[04:05] <dumbledore> mythbuntu
[04:08] <Gibby_2> what type of Nvidia card?
[04:09] <dumbledore> nvidia GeForce 6150 LE
[04:18] <Gibby_2> dumbledore: try https://help.ubuntu.com/community/NvidiaTVOut
[04:18] <Zinn> [help.ubuntu.com] NvidiaTVOut - Community Ubuntu Documentation
[04:20] <dumbledore> Gibby_2. I will try it.. thanks for the help
[05:37] <Gibby_2> any1 here move their MySQL data files onto a RAM
[18:05] <PatrickDK> gibby, onto a ram?
[18:16] <Gibby_2> yeah, onto ram
[18:17] <Gibby_2> http://www.mythtv.org/wiki/Optimizing_Performance#MySQL_on_a_RAM_Drive
[18:17] <Zinn> [www.mythtv.org] Optimizing Performance - MythTV
[18:19] <PatrickDK> yuk, I dunno about doing it on a ram drive at all, sounds evil
[18:19] <PatrickDK> it's much easier and safer to just make sure that it's always in cache
[22:03] <_Techie_> how difficult is it to setup a myth backend just for sharing a TVtuner card
[22:06] <Gibby_2> share it how?
[22:07] <_Techie_> i want to be able to watch TV on my desktop machine, connected to the network, using a tv tuner card installed in my server machine behind the TV
[22:08] <_Techie_> i would think about doing it using ust my own PC, but this way is far cooler and cheaper to setup
[22:09] <_Techie_> it would also allow my dad to watch tV on his laptop if i wish to allow him
[22:12] <Gibby_2> yep, then you just install/configure the backend and anyplace you want to watch it setup a frontend
[22:13] <_Techie_> is there any really good guide to setting up the backend on ubuntu-server?
[22:13] <_Techie_> i asked ubottu but his mythtv page is a bit out dated
[22:14] <Gibby_2> is the server already installed with ubuntu?
[22:14] <_Techie_> yes
[22:15] <Gibby_2> do this first http://www.mythbuntu.org/existing-ubuntu
[22:22] <karl_> I was wondering if someone could help me/give me a little advice. I just did a brand new install of mythbuntu 10.10 and am trying to configure my HD PVR, but having difficulty.
[22:26] <Gibby_2> karl_; check mythtv-users
[22:28] <karl_> Ok, thanks, I'll check there....I'm new to irc & mythtv...been banging my head against the wall for quite a while now...figured I'd actually try to get help instead of continually struggling.
[22:49] <_Techie_> does anyone know if the myth backend configurator plays nicely with X forwarding
[22:51] <Gibby_2> yes it does, i use it all the time
[22:52] <Gibby_2> it is even better if you use nxserver
[23:08] <biffhero> apt-get update on a lucid box gives me an error, and says I should "run sudo dpkg-reconfigure mythtv-database"  when I do that, I get a dialog screen titled "Configuring mythtv-database", and then an error on my console: "Failed to create or modify database (incorrect admin username/password?)
[23:08] <biffhero> Try:
[23:08] <biffhero> sudo dpkg-reconfigure mythtv-database"
[23:09] <biffhero> this is a 0.23 upgrade within 0.23 to a later 0.23.  My config.xml file looks OK, and when I do "mysql -u ……" with that information, I get into mysql just fine.
[23:30] <biffhero> I thought the problem was that "Name: mythtv/mysql_admin_password" was blank, so I filled it in.  Re-ran the script.  same error.  But now the field is empty again.


[00:15] <cmaloney> Dear mom and dad: thank you for enough piano lessons to be dangerous:
[00:16] <cmaloney> https://www.dropbox.com/s/krwevi12069zs9n/just_enough_to_be_dangerous.ogg?dl=0
[00:17] <cmaloney> (Made with LMMS, an arpeggiator, and a shit-ton of reverb)
[11:43] <tony-smlr> We are goign live soon!  SMLR E193/E194 (5/15/2016) Video: http://youtu.be/EX2AX1Zj8Bo
[13:12] <cmaloney> morning
[13:36] <rick_h_> morning from MN
[13:45] <cmaloney> woo woo
[16:32] <gamerchick02> afternoon. i watched part of the Manchester City game and it was good.
[17:32] <_stink_> gamerchick02: ended in a tie?


 Why?
[07:12] <lordievader> Ubuntu channels have a rather strict bot poilicy don't they?
[07:24] <jink> Goedemorgen, kinders.
[07:31] <ducasse> good morning, everyone
[08:32] <lordievader> Hey ducasse
[08:32] <lordievader> How are you doing?
[08:34] <ducasse> morning lordievader - all good here, thanks. how about you?
[08:34] <lordievader> Doing good here 😁
[08:37] <ducasse> any plans for the day? :)
[08:38] <lordievader> Work, work and work :P
[08:38] <lordievader> You?
[08:41] <ducasse> have a hospital appointment a bit later, other than that i'm just going to do some system maintenance etc here at home
[08:41] <lordievader> Ah, good luck 👍
[08:46] <ducasse> thanks
[11:43] <BluesKaj> Howdy folks
[12:20] <pauljw> hi everyone
[12:22] <BluesKaj> 'Morning pauljw
[12:23] <pauljw> hi BluesKaj :)
[18:01] <lotuspsychje> good evening to all
[18:04] <pauljw> hi lotuspsychje :)
[18:04] <lotuspsychje> hey pauljw how are you today
[18:04] <pauljw> doing fine, you?
[18:04] <lotuspsychje> great finished work and irc chill now :p
[18:04] <pauljw> :D
[18:06] <daftykins> \o
[18:07] <lotuspsychje> hey daftykins
[18:08] <daftykins> pesky old kit playing up :) got a single memory error on a setup i was trying to sell on for cheap, today
[18:08] <lotuspsychje> cool
[18:09] <daftykins> naw it's a bad thing! faulty module
[18:09] <lotuspsychje> daftykins: im gonna get a w10 box with starting up probs
[18:09] <daftykins> oh my
[18:09] <daftykins> i wonder if it'll be like my friends wifes one, where the upgrade to the latest build failed spectacularly
[18:10] <lotuspsychje> not sure what happened, customer said blue screen uefi stuff
[18:11] <daftykins> :) memtest and SMART disk check #1 then :>
[18:12] <lotuspsychje> daftykins: they got pics all over, ill start with backup :p
[18:12] <daftykins> well if you don't look at the SMART data first, copying off could endanger it all!
[18:12] <daftykins> :)
[18:12] <lotuspsychje> true
[18:13] <daftykins> i really do love my local nextcloud setup now, LAN transfer speeds when home for keeping some data synced up, then still available when out and about across the island
[18:13] <lotuspsychje> daftykins: what kind of stuff you having on it?
[18:14] <daftykins> pics i take and share on IRC, some client notes... that sort of thing
[18:14] <daftykins> files i want to share
[18:14] <lotuspsychje> aha movable files
[18:15] <daftykins> stopped using dropbox and moved to this instead
[18:15] <lotuspsychje> !find nextcloud
[18:15] <nacc> it's a snap
[18:15] <nacc> iirc
[18:15] <daftykins> you don't get it from repos ideally
[18:15] <nacc> debian stopped package all that stuff
[18:16] <daftykins> just get a web server & db server on, then unzip from their site into the root and configure the database :)
[18:16] <nacc> also an option
[18:16] <lotuspsychje> nacc: yep :p nextcloud-client    2.3.3+gitab40efe snap
[18:16] <nacc> although i imagine upgrades are tricky, daftykins ?
[18:16] <daftykins> no, single click in the web control panel with a properly configured host
[18:16] <daftykins> zero need for a snap
[18:17] <nacc> nextcloud             12.0.4snap2               nextcloud            -        Nextcloud Server - A safe home for all your data
[18:17] <nacc> lotuspsychje: --^
[18:17] <lotuspsychje> cool
[18:17] <daftykins> for the server side anyway, didn't think of the client portion on Linux :)
[18:17] <nacc> daftykins: ah interesting
[18:18] <lotuspsychje> hey Bashing-om
[18:19] <Bashing-om> lotuspsychje: Hey hey :) ... I be back see what a Tuesday brings .
[18:19] <daftykins> :D
[18:20] <daftykins> nacc: it's kinda like wordpress in that way, although a package existed it was always considered a mistake by anyone with experience of it :>
[18:20] <daftykins> (a mistake to use the package)
[18:20] <nacc> for sure
[18:20]  * nacc had to update that package for 16.04
[18:21] <daftykins> oh dear :D
[18:21] <daftykins> probably better to be removed
[18:31] <lotuspsychje> hey BluesKaj
[18:32] <BluesKaj> hey lotuspsychje
[18:43] <lotuspsychje> Wayland is a display server protocol that can be used instead of X. From Ubuntu 17.10 and higher you can choose the wayland session at gdm login on systems that support it. For more info, see https://wayland.freedesktop.org/
[18:43] <lotuspsychje> how you guys like this?
[18:43] <nacc> !wayland
[18:44] <nacc> lotuspsychje: seems reasoable
[18:44] <lotuspsychje> nacc: its a bit weird to say artful does defualt and bionic not right?
[18:45] <nacc> lotuspsychje: Maybe add a sentence after your second one. "Ubuntu 17.10 uses Wayland by default on systems that support it."
[18:46] <pauljw> It's going to be included with bionic, just not the default, correct?
[18:46] <lotuspsychje> might get too long factoid, and if artful gets eol we wont need that anymore?
[18:46] <lotuspsychje> pauljw: yeah wayland will be installed, choosable
[18:47] <pauljw> :)
[18:47] <nacc> pauljw: correct (recet change)
[18:48] <nacc> lotuspsychje: yeah, you're right
[18:48] <lotuspsychje> nacc: ok lemme request it
[18:54] <lotuspsychje> http://www.itprotoday.com/network-security/linux-monitoring-tool-detects-meltdown-attacks
[20:21] <BluesKaj> just woke up from a nap,  :-) wayland is probly non default on Bionic due to the conservative nature of LTS OSs
[20:22] <lotuspsychje> BluesKaj: yeah i suggested new trigger
[20:23] <BluesKaj> lotuspsychje, right
[20:24] <lotuspsychje> BluesKaj: Wayland is a display server protocol that can be used instead of X. From Ubuntu 17.10 and higher you can choose the wayland session at gdm login on systems that support it. For more info, see https://wayland.freedesktop.org/
[20:24] <lotuspsychje> better?
[20:25] <BluesKaj> nicely done lotuspsychje, yes :-)
[20:25] <lotuspsychje> tnx
[20:26] <BluesKaj> is gdm still default on ubuntu ?
[20:27] <lotuspsychje> BluesKaj: from 17.10 ubuntu-desktop it is
[20:28] <lotuspsychje> or should it be gdm3
[20:28] <BluesKaj> Kubuntu defaults to sddm, so the other flavors use gdm too?
[20:28] <lotuspsychje> didnt test other flavors 17.10 and higher myself
[20:30] <lotuspsychje> BluesKaj: you can choose wayland on sddm?
[20:32] <lotuspsychje> bbl
[23:06] <oerheks> sorry nacc, i could not hold myself in
[23:07] <nacc> oerheks: :)
[23:07] <nacc> sometimes people are just ...
[23:08] <oerheks> "i heard .."
[23:09] <nacc> and if you ask someone for details and they say "no"
[23:09] <nacc> i mentaly put them in /ignore
[23:11] <oerheks> but .. sometimes they are surprisingly neat and say thank you afterwards
[23:11] <oerheks> :-D
[23:11] <oerheks> we never know who we are dealing with
[23:12] <nacc> oerheks: yeah


[09:26] <iD_J> is there a way to see why a suspend might have failed?
[12:42] <iD_J> i need help compiling a kernel
[21:51] <tobidope> can i ask module related questions here? i have a problem with acerhdf
[21:53] <tobidope> ?
[22:33] <matti> tobidope: Best route to take is to open a bug against it.


[02:45] <HowdyDoody> Evening
[05:50] <jackson> o/
[10:31] <rmg51> Morning
[12:02] <HowdyDoody> Morning again
[13:06] <teddy-dbear> Morning peoples
[13:47] <HowdyDoody> How to upgrade from 11.10 to 12.04 with liveCD and all drives in LVM (logical volume mgr) ??
[17:01] <pleia2> HowdyDoody: afaik the livecd installer doesn't support lvm until 12.10
[17:02] <pleia2> (I've never done an upgrade with a CD though)
[17:46] <ChinnoDog> I thought you needed alt CD to do that
[17:58] <waltman> All you Apple haters will enjoy this: http://www.macrumors.com/2013/01/01/apple-promotes-do-not-disturb-in-tv-ad-on-same-day-as-new-years-day-bug-discovered/
[17:58] <waltman> And yes, before you ask, I'm being affected by that. :)
[18:35] <JonathanD> So the mode gets stuck on?
[19:09] <waltman> Something like that, yes. Rebooting doesn't fix it.
[19:10] <waltman> http://www.macrumors.com/2013/01/02/apple-says-do-not-disturb-bug-to-resolve-itself-on-monday-january-7th/ # gee, thanks
[19:11] <JonathanD> So you can't recieve calls?
[19:11] <waltman> hmm...
[19:11] <waltman> Let me try.
[19:12] <waltman> Nope, it goes right to voicemail!
[19:12] <waltman> let's turn that off...
[19:12] <JonathanD> Until the 7th...
[19:22] <JonathanD> waltman: you're able to turn off the feture though?
[19:23] <waltman> nod
[19:23] <JonathanD> Oh, I see, you can turn it off but it does not turn itself off as scheduled.
[19:24] <waltman> The bit about not receiving calls is a bit complex. It will still allow calls from your "Favorites", and also anyone who calls back within 3 minutes.
[19:25] <JonathanD> Apparently date/time is hard.
[19:25] <JonathanD> I'm thinking about coming to plug tonight.
[19:26] <waltman> excellent
[19:29] <waltman> how's your car holding up?
[19:29] <JonathanD> It is very thirsty.
[19:30] <JonathanD> I can make it to the city and back, though.
[19:30] <waltman> Do you now this because of your new monitor thingy?
[19:30] <JonathanD> I think.
[19:30] <JonathanD> It helps.
[19:30] <waltman> s/now/know/
[19:30] <JonathanD> I was thinking of building a water level sensor, though.
[19:30] <JonathanD> Seems like it'd be quite easy.
[20:02] <MutantTurkey> Break is killing me, seriously, i have no responsiblity and therefore nothing to do
[20:07] <waltman> MutantTurkey: You should be studying calculus!
[20:07] <MutantTurkey> I have been reviewing
[20:07] <MutantTurkey> and reading
[20:07] <MutantTurkey> but cmon only so much can be done
[20:08] <waltman> or maybe watching the Sunderland - Liverpool match on ESPN2 :)
[20:45] <MutantTurkey> i have my desktop on all day, id like to seed some good stuiff for people
[20:45] <MutantTurkey> so far I am just seeding a bunch of debian isos


[05:45] <aaschez> Is it safe to have linux-headers-generic, linux-image-generic, linux, linux-headers-generic-pae, linux-headers-image-pae and linux-image installed after having linux-headers-3.0.0-14 generic?
[05:51] <RAOF> aaschez: It is (almost) always safe to have more packages than you need installed.
[05:52] <RAOF> The more vaguely named ones (linux, linux-image-generic, etc) are metapackages; their only point is to ensure that the latest kernel is installed, even if the kernel package name changes (as it does, when you go from linux-image-3.0.0-13-generic to linux-image-3.0.0-14-generic, for example)
[05:54] <aaschez> RAOF: Certain applications require loading and compiling of modules in to running kernel, which package to instll for that?
[05:54] <aaschez> install
[05:55] <RAOF> linux-headers-generic will always depend on the headers for the most recent kernel; this will not necessarily be the kernel that you're *running*, but if you keep linux-headers-generic installed and don't remove older kernel headers you'll have all the headers you need.
[05:56] <aaschez> 'and don't remove older kernel headers ' ..why?
[05:57] <aaschez> As far as I understand I'm running linux-headers-3.0.0-14-generic
[05:57] <RAOF> Well, you can select any of the previous kernels at boot.
[05:57] <RAOF> So if you need to guarantee that any kernel you choose to run has associated headers, you need to keep the old headers around.
[05:58] <RAOF> If, on the other hand, you only ever need to guarantee that module building will succeed against the most recent kernel, you don't need the older header packages.
[05:59] <aaschez> Yes, but I think it safer to have atleast one old running kernel. Could you explain me what headers, image, generic means?
[06:00] <aaschez> s/but/so
[06:03] <RAOF> The image is the kernel itself.  The headers are the stuff required to build out-of-tree modules against that kernel.
[06:03] <aaschez> Ok, so headers are the ones required to build modules?
[06:04] <aaschez> ok
[06:06] <aaschez> Lastly, what is generic and generic-pae ?
[06:10] <aaschez> Thanks a lot RAOF
[06:10] <RAOF> Ah.
[06:11] <RAOF> -generic-pae is a build with PAE (Physical Address Extensions) enabled.
[06:11] <RAOF> It allows a 32bit kernel to address 48 bits of physical memory (ie: more memory than you have).
[06:12] <RAOF> I'm not sure if that's going to remain for Precise; there was talk about always having that enabled, as it only has a small performance impact.
[06:17] <aaschez> Thanks for explaining me the basic terms related to kernel :)
[06:42] <RAOF> aashez: There's no problem with asking basic (relevant) questions; go ahead :)
[06:45] <aashez> RAOF: :) I just restarted after intsalling linux, linux-image-generic and linux-headers-generic packages. There was no error but when I'm trying to build kernel module it gives error
[09:56]  * apw looks miserably out at the world
[10:13]  * jussi hugs apw
[10:13] <smb> jussi now is infected...
[10:14] <jussi> :(
[10:15] <smb> Luckily its "just" a cold ;)
[10:16] <apw> jussi, thanks but i don't recommend breathing near me
[10:16] <jussi> apw: colds arent catchable over the interwebs
[10:17] <jussi> so interwebs hugs are ok :D
[10:17] <apw> heres hoping you are right
[10:35]  * LetoThe2nd suggests gluhwein to cure about everything :)
[10:47] <apw> sounds better than the honey and lemon i am being offered
[10:50] <smb> apw, how about ginger and honey. :)
[10:51] <LetoThe2nd> oO( gluhwein and gluhwein? or rather gluhwein and rum in severe cases )
[10:54] <smb> Gloehwein macht gloecklich... :-P
[11:09] <apw> that sounds rather rude :)
[11:10] <bryceh> apw, only if you're a teetotaler.
[11:12] <apw> hny bryceh ... hows you
[11:13]  * apw tries to imagine self as teetotal ... its not working
[11:14] <bryceh> apw, good good
[11:14] <bryceh> apw, my son and daughter share your cold
[11:14] <bryceh> (I guess)
[11:14] <apw> yay :/, that'll be amusing for you
[11:14] <bryceh> apw, indeed
[11:15] <bryceh> apw, invariably I'll catch it myself the day before the Budapest flight
[11:15] <apw> hense you are awake at this god forsaken time
[11:15] <apw> bryceh, so very true, hopefully it is the same one, so i am at least immune
[11:15] <bryceh> creature of the night I am
[11:15] <apw> that seems to be the lot of fathers the world over
[11:35] <cking> sounds like the Budapest rally will be a "share a cold virus" event
[11:38] <bryceh> cking, :-/
[11:38] <amitk> talking about cold, Helsinki received its first real snowfall for the season. Much better than the wet greyness.
[11:38] <cking> share and enjoy ;-)
[11:39] <ppisati> we should rename Canonical's event after a famous Anthrax album: "Spreading the disease"!
[11:40] <amitk> there is already 'ubuflu' which is a take away gift from the events :)
[11:41] <cking> ubuflu is something also free to share with the family when you get back home
[11:42] <amitk> ...hence sticking to the spirit of ubuntu ;)
[11:43] <cking> apart from the fact we don't get the source code to the cold virus
[11:43] <amitk> cking: the source is available. We just don't know the programming language yet
[11:44]  * cking consideres objdump on a virus...
[12:48] <apw> herton, bjf, ppisati, i have found a build error in maverick/ti-omap4, in the unreleased bit so i want to force the tip to fix it ... any of you playing with it?
[12:48] <bjf> apw, not I
[12:49] <apw> bjf, happy new year ... early for you isn't it ?
[12:49] <herton> apw, no as well
[12:49] <apw> then as ppisati can't be pushing it, i can ;)
[12:49] <bjf> apw, same to you. Yes, woke up at 3, couldn't get back to sleep
[12:49] <apw> bjf, now that sucks and no mistake
[12:52] <apw> herton, bjf, pushed ... was a missing header include in the top-down patches, now fixed
[12:55]  * apw notes he is beign pretty random about who he is wishing new years to, strange ...
[12:55] <apw> happy new years all round
[13:03] <cking> #include <happynewyear.h>
[13:04] <ppisati> apw: not messing with m/omap4
[13:04] <ppisati> apw: *i'm
[13:04] <apw> ppisati, thanks, all updated now
[14:52] <ppisati> back in 20m
[15:41] <apw> ppisati, p/ti-omap4 is now a rebase tree against p/master-next right ?
[15:49]  * ogasawara back in 20
[15:59] <ppisati> apw: yep
[16:00] <apw> ppisati, cool thanks
[16:00] <apw> jsalisbury, we got a top 10 meeting shortly ?
[16:00] <jsalisbury> apw, yes
[16:01] <jsalisbury> apw, 30 minutes
[16:01] <apw> ack
[16:01] <ppisati> isn't it 30min before kernel meeting?
[16:02] <jsalisbury> ppetraki, correct
[16:02] <jsalisbury> And on that note:
[16:02] <jsalisbury> **
[16:02] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:02] <jsalisbury> **
[16:02] <smb> ppisati, I would say 1hr
[16:02] <jsalisbury> sorry ppetraki, I meant ppisati correct.
[16:03] <ppetraki> jsalisbury, happens a lot :), hny
[16:03] <jsalisbury> :)
[16:03] <smb> oh the top ten thing...
[16:09] <brendand> anyone here from the stable team?
[16:09] <herton> brendand, yes
[16:09] <brendand> herton - hi
[16:11] <herton> hi
[16:11] <brendand> herton - we're considering re-testing for oneiric because of the reverted patch. the reversion seems to have fixed what looked like a seperate issue as well, so it seems significant
[16:13] <herton> brendand, yes, re-testing is needed, although it's a small change has considerable impact
[16:15] <bjf[afk]> brendand, can you explain what the "separate issue" is that it fixed ?
[16:16] <brendand> bjf[afk] - this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/907454
[16:16] <ubot2`> Launchpad bug 907454 in linux "[Dell Precision M4500] offlining and then re-onlining CPUs makes the system unresponsive" [Medium,Confirmed]
[16:16] <brendand> we had one other independent confirmation
[16:17] <bjf> brendand, thanks, that is interesting
[16:17] <tgardner> bjf, given that suspend offlines CPUs, I think this is likely the same symptom.
[16:18] <bjf> tgardner: that was what I was thinking as well
[16:21] <brendand> bjf - now my colleague tells me that the system hit by that bug also couldn't resume from S3 so it seems almost certain they're related
[16:23] <bjf> brendand: did they run into the issue as part of cert. testing ?
[16:27] <brendand> bjf - yep, sure did
[16:28] <bjf> brendand: i'm "curious" why it didn't get raised with us (or did it?)
[16:30] <brendand> afair i did mention it here before the holidays
[16:31] <bjf> brendand: thanks
[16:32] <brendand> bjf - the bug also has the regression-update tag. does that not bring it into view for you?
[16:33] <bjf> brendand, no, at this point that tag is on so many bugs it's useless
[16:33] <diwic> ogasawara, just a question, can I really cherry-pick to the precise kernel? I mean, the stuff that currently is in takashi's tree only, not in linus tree, and therefore not in the precise tree, and you cannot cherrypick between different trees, or can you?
[16:35] <ogasawara> diwic: I believe if you fetch takashi's tree you should be able to cherry-pick
[16:35] <diwic> ogasawara, hmm, so I would start with a precise tree and then "git remote add" for takashi's tree?
[16:37] <arges> jsalisbury, whats the link?
[16:37] <jsalisbury> arges, http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_hot_.html
[16:37] <arges> thanks
[16:37] <jsalisbury> arges, Then sort by heat
[16:37] <arges> ok I was looking at the right page then
[16:38] <ogasawara> diwic: you could do that or I think you can just do 'git fetch ...'
[16:38] <diwic> ogasawara, ok, I'll try that. Thanks!
[16:40] <ogasawara> diwic: a lot of times I do "git fetch <repo> <branch>" and then just "git cherry-pick FETCH_HEAD" (assuming the patch I want is at the tip)
[16:50] <jono> hey all
[16:50] <jono> my wireless keeps dropping and dmesg is giving me a stack of [21740.360855] wlan0: deauthenticating from 3c:ea:4f:85:07:d1 by local choice (reason=3)
[16:50] <jono>  errors
[16:51] <jono> it looks like I get that error whenever it disconnects
[16:51] <jono> any idea what the possible cause could be?
[16:52] <apw> jono, does that happen randomly a few times a day ?
[16:52] <jono> apw, yeah
[16:52] <jono> it seems to be happening at least once an hour
[16:52] <apw> what wireless do you have ?
[16:52] <jono> cfg80211
[16:52] <jono> Intel
[16:52] <apw> jono, sounds like what i am seeing, where likely rekeying is being exposed
[16:53] <apw> but no idea as to cause, why are you seeing it all of a sudden?
[16:53] <jono> I saw a few bugs in LP that suggest others are seeing this too
[16:53] <jono> apw, I have seen this ever since I upgraded to 12.04
[16:53] <jono> oddly, it varies between APs I think
[16:53] <jono> see these issues with my AP, but less with my parents
[16:53] <jono> I thought it might be the power saving, but that is off on my machine
[16:54] <apw> jono, yep i'd say there is an ap component.  but rekeying time is AP specific
[16:54] <apw> i started seeing it when i upgraded my AP to WPA
[16:54] <jono> what is rekeying time?
[16:55] <apw> wpa requires rekeying (making up new keys) effectivly a reassociation though it should be transparent
[16:55] <jono> right
[16:55] <jono> so does the AP basically kick me off the AP and then it should automatically create the new key and connect?
[16:56] <apw> jono, i am unsure as to what should happen, the 'error' whcih is reported implies that the local end decided it wanted off the AP
[16:58] <jono> apw, the bug I saw reported was https://bugs.launchpad.net/ubuntu/+source/linux/+bug/548992 and
[16:58] <ubot2`> Launchpad bug 548992 in debian "Wireless connection frequently drops [deauthenticating by local choice (reason=3)]" [Undecided,Confirmed]
[17:08] <brendand> bjf - what's going to happen with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/910894 then? how long is it staying in verification for?
[17:08] <ubot2`> Launchpad bug 910894 in kernel-sru-workflow/verification-testing "linux: 3.0.0-15.25 -proposed tracker" [Undecided,In progress]
[17:11] <arges> jsalisbury, i was wondering why https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250 wasn't high in heat... but I think its because its been updated recently perhaps
[17:11] <ubot2`> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress]
[17:11] <bjf> brendand, good question. I guess I'd like to see it stay in verification this week
[17:12] <jsalisbury> arges, that's a good question.
[17:15] <brendand> bjf - so we'll leave our retesting for next week then i guess
[17:24] <bjf> brendand, i think it would be safe to test this week if you wanted
[17:43] <tgardner> bjf, Greg has added 'Revert "clockevents: Set noop handler in clockevents_exchange_device()' to all of the maintained stable trees beginning with 2.6.32.y
[17:45] <bjf> tgardner: ack, herton, we should revert and respin
[17:58] <bjf> tgardner: only lucid has the bad commit, we'll respin that
[17:58] <tgardner> bjf, right.
[18:06] <jono> apw, is there anything I can do to resolve this wireless dropping issue, it is disrupting my work
[18:06] <jono> know of any workarounds?
[18:06] <tgardner> jono, ethernet
[18:07] <jono> tgardner, I might need to do that
[18:07] <apw> jono, no i have yet to find anything that helps
[18:07] <jono> no worries, thanks for looking into apw
[18:07] <jono> obviously if you want to look at my machine in budapest, that is fine
[18:07] <tgardner> jono, I'm stuck on Maverick on one of my laptops 'cause wireless just goes to hell with a newer kernel
[18:07] <jono> tgardner, yikes
[18:08] <jono> tgardner, you having the same dropouts issues?
[18:08] <apw> jono, i have the same issue on my natty box at home, thats the first time i noticed it, but also the first time i had wpa, which is uspect has always been broke in this way
[18:08] <tgardner> apw, try Maverick with WPA. I think you'll find that works OK
[18:09] <jono> apw, gotcha
[18:10] <apw> tgardner, yeah i had moved forword from M before i moved to wpa, will try that out when i get back to the machine
[18:12] <apw> tgardner, and i am not sure its limited to intel, so i suspect this is either a 80211 stack issue, or an NM issue
[18:13] <tgardner> apw, Johannes Burg has been working on this with arges since before Xmas. dunno what that status is, but I agree that it looks like a stack issue.
[18:14] <arges> tgardner, yea I built a test kernel with Johannes patch to get some debug info. he was looking at the tx/rx aggregation code in the kernel
[18:15] <herton> tgardner, I noticed that smb announced <IP_ADDRESS>+drm33.21 with only the clockevents revert, I'll apply it as a stable update (create-stable-tracker)
[18:15] <arges> tgardner, unfortunately I'm not sure that bug is just *1* issue, it seems like there could be multiple issues at work
[18:16] <tgardner> herton, good, was just gonna ask about that
[18:16] <smb> herton, Yeah, Greg just did the same
[18:16] <tgardner> arges, it seems power saving mode is wadded up in the general symptoms
[18:16] <apw> arges, if you have some test kernels, or patches point me at them and i can try them on my kit
[18:17] <jono> tgardner, yeah I thought it was the power saving issues, but I switched off power saving and the issues are still there
[18:17] <arges> apw, do you have a wifi card that exhibits the issue?
[18:17] <apw> arges, i have two machines at least which show this behaviour in my home yes
[18:17] <tgardner> arges, you can also abuse jono
[18:17] <jono> bring it!
[18:17] <arges> awesome
[18:17] <apw> i think i have three, which are the three i use routinely, so it could be more
[18:18] <arges> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250
[18:18] <ubot2`> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress]
[18:18] <jono> brb, nipping out to get some longer ethernet
[18:18] <smb> herton, I wonder whether in this special case I could wait till tomorrow and then use the current make ec2 topic branch tracking bug created today which I have not touched, yet...
[18:18]  * smb is lazy
[18:18] <arges> apw, jono: #124 has a build with gives us multiple options for disabling n mode in the kernel
[18:18] <herton> smb, yes, just ignore the current tracking bug, the bot will open a new one after the build of new kernel
[18:18] <bjf> smb, i'm ok with that
[18:19] <apw> arges, i don't thnk i have any N capable kit involved
[18:19] <arges> Johannes Berg wanted to know how those various parameters related
[18:19] <arges> apw, oh, which card(s) do you have that would relate to this?
[18:19] <smb> herton, bjf Oh, if the bot creates a new one anyway... I take whatever is latest then
[18:19] <apw> something intel, and something brcm at least
[18:20] <apw> i haven't got the h/w in hand right not, but my constant disconnects is occuring at home
[18:20] <arges> apw, ok this is a different bug than I've been looking at
[18:21] <smb> ogasawara, actually I guess you may be interested to be aware of bug 911204, too. Not sure the change I have in there will be embraced but it seems to help the xen case...
[18:21] <ubot2`> Launchpad bug 911204 in linux "precise ec2 images fail to boot with kernel oops" [Critical,Confirmed] https://launchpad.net/bugs/911204
[18:21] <ogasawara> smb: ack
[18:22] <arges> apw, essentially wifi worked in natty, then stopped working in oneiric. in oneiric if n mode is disabled (11n_disable=1) wireless works again.   the periodic disconnections sounds pretty different
[18:24] <ogasawara> smb: you plan on shooting that upstream?
[18:25] <smb> ogasawara, Yes, sent it already. Though rather to the stable with both from the sob cc'ed. I found that thread more quickly
[18:26] <apw> smb, we shall see what they say i gues
[18:26] <smb> apw, Right, if there is no response I need to shoot wider
[18:27] <ogasawara> smb: I'll apply it as sauce for now and we can follow up later
[18:27] <smb> Just was meant as a note to let you know.
[18:28] <smb> ogasawara, Hmmmm. Maybe I should test on real hw before...
[18:28] <ogasawara> smb: oh, I thought you had tested
[18:28] <smb> Just booted as a xen guest
[18:28] <smb> which failed before...
[18:29] <smb> ogasawara, So let me do the proper testing
[18:29] <ogasawara> smb: ack
[18:33] <tgardner> ogasawara, where did 'fs: limit filesystem stacking depth' come from in Precise ?
[18:33] <ogasawara> tgardner: hrm, don't recall off the top of my head.  just a sec and lemme look.
[18:33] <tgardner> ogasawara, it ain't upstream, so I was kind of curious
[18:34] <ogasawara> tgardner: ah, I think that's part of the overlayfs bits
[18:34] <tgardner> ah
[18:34] <tgardner> ogasawara, perhaps we should have marked those SAUCE or somethinig
[18:35] <ogasawara> tgardner: I think we'd prefixed those with "overlayfs:" or something similar.  I'll get em cleaned up and marked sauce
[18:37] <tgardner> ogasawara, I noticed it whilst reviewing tyhicks statfs reporting patch.
[18:41] <tyhicks> yes, I remember seeing that patch in the overlayfs patchset
[18:42] <tyhicks> tgardner, ogasawara: FWIW, the eCryptfs changes looked good to me
[18:43] <tgardner> tyhicks, is the patch on the mailing list the same as whats in linux-next ?
[18:43] <tyhicks> tgardner: BTW, I've got a working statfs reporting patch with a single code path. I just need a little time to go back and clean some things up.
[18:44] <tyhicks> tgardner: Sorry, are you talking about the eCryptfs patch in the overlayfs patchset or the eCryptfs statfs patch?
[18:44] <tgardner> tyhicks, the statfs patch on the Ubuntu k-team list
[18:45] <tgardner> I was just about to push that one. despite our comments it does work.
[18:45] <tyhicks> tgardner: The statfs patch in linux-next and the Ubuntu k-team list are the same. I'm working on an improved version for the 3.3 merge window.
[18:46] <tyhicks> tgardner: It will incorporate the changes suggested by you and apw
[18:46] <tgardner> tyhicks, ok, then I'll push the one I've got.
[18:46] <tyhicks> sounds good, thanks
[19:16] <tgardner> tyhicks, I'm still getting hate mail about bug #509180. Have you review it recently ?
[19:16] <ubot2`> Launchpad bug 509180 in ecryptfs "ecryptfs sometimes seems to add trailing garbage to encrypted files" [High,Fix released] https://launchpad.net/bugs/509180
[19:27] <tyhicks> tgardner: Yes. A lot of those comments are not helpful, but I looked at a bug yesterday which had helpful steps to reproduce the issue - bug 842647
[19:27] <ubot2`> Launchpad bug 842647 in ecryptfs "[git] file blocks duplicated at the end of the file" [High,In progress] https://launchpad.net/bugs/842647
[19:28] <tyhicks> tgardner: I'm almost done with that patch. It should go upstream by the end of the week.
[19:29] <tgardner> tyhicks, cool. if it looks like the same symptoms, then mark 509180 as a duplicate when you've got a patch ready to go.
[19:29]  * tgardner --> lunchtime errands
[19:35] <apw> tgardner-afk, bah ... we need to fix the 'going to apply' protocol ... we just clashed :)
[19:36] <lamont> I have a few Dell poweredge machines that have recently started seeing ntp step back and forth OTOO .2 seconds... any known fuzziness in the kernel's ntp world?
[19:37] <lamont> (lucid and hardy both, so I'm suspecting that the hardware is just plain getting old)
[19:48] <lamont> just wondering if the ticks/sec there is consistent with other machines, or if said hardware has something special of its own
[20:18]  * herton -> eod
[21:16] <Beanow> Oh wow, accidentally changed status of a bug I had nothing to do with.
[21:16] <Beanow> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
[21:16] <ubot2`> Launchpad bug 904569 in linux "Linux 3.0.0-15 causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Fix released]
[21:17] <Beanow> Anyone in here that can revert Oneiric status to Fix Commited?
[21:18] <bjf> Beanow: done
[21:18] <ohsix> someone that can will see the change and fix it, most likely
[21:18] <Beanow> Thanks and apologies.
[21:19] <Beanow> (How do I even have permission for that?)
[21:30] <Beanow> jsalisbury: just reading back on the first kernel meeting I saw. I'm impressed. Neatly organized.
[21:30] <jsalisbury> Beanow, thanks, glad the notes can help
[21:31] <Beanow> jsalisbury, actually got it in my chat here but pretty much the same thing
[21:32] <Beanow> And yeah they helped. Now I know my suspend problem is going to be fixed quickly. :P
[21:36] <jsalisbury> Beanow, yes, the commit that caused the bug has been identified.


[15:00] <slyon> o/
[15:00] <sil2100> o/
[15:01] <xnox> \o
[15:01] <bdmurray> #startmeeting Weekly Ubuntu Foundations team
[15:01] <meetingology> Meeting started Thu May 28 15:01:11 2020 UTC.  The chair is bdmurray. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:01] <meetingology> Available commands: action commands idea info link nick
[15:01] <juliank> o/
[15:01] <bdmurray> #topic Lightning rounds
[15:01] <rbalint> o/
[15:01] <bdmurray> echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity mwhudson juliank waveform slyon)
[15:02] <bdmurray> mwhudson xnox tdaitx infinity slyon rbalint waveform doko sil2100 juliank bdmurray vorlon
[15:02] <bdmurray> xnox:
[15:02] <xnox> xnox/mwhudson: unpopulated ESP is now always created in ubiquity (TODO sru)
[15:02] <xnox> xnox/mwhudson: picking the right disk in ubiquity should work now too (TODO sru)
[15:02] <xnox> xnox/mwhudson: interactive netboot is now available (TODO sru)
[15:02] <xnox> Fixed up components-missmatches for built-using, i386, community-maas (TODO some reviews outstanding)
[15:02] <xnox> Migrated s390x debian-cd off d-i
[15:02] <xnox> Prepared cd-boot-images package to migrate the other .isos off d-i (Needs NEW review)
[15:02] <xnox> Tajik fonts finally fixed in gfxboot (TODO sru)
[15:02] <xnox> Available for +1 maintenance as a substitute, if one needs it
[15:02] <xnox> done
[15:03] <bdmurray> tdaitx: are you about or bailing water?
[15:03] <bdmurray> okay, how about slyon
[15:04] <slyon> == Distro ==
[15:04] <slyon> - Finally fixed python-httplib2 autopkgtest
[15:04] <slyon>   * included test suite in upstream tarball
[15:04] <slyon>   * prepared 0.18.1-1 release for Debian
[15:04] <slyon>   * use new test suite for autopkgtest, skip failing network tests
[15:04] <slyon> - Learned and setup about Canonistack cloud account
[15:04] <slyon>   * Could be used for reproducible autopkgtests (net/proxy restrictions)
[15:04] <slyon> - Finalized mathjax MIR, bug #1878937
[15:04] <slyon> == Netplan ==
[15:04] <slyon> - Fixed netplan.io documentation, bug #1878631
[15:04] <slyon> - Confirmed bug #1878928 is a duplicate
[15:04] <slyon> - Research and discussed support for VRF devices, bug #1773522
[15:04] <slyon> - Review & merge PR#84: nm: support route attributes and interface globbing
[15:04] <slyon> - Prepared PR#140: itegration tests for interface globbing and NM routing
[15:04] <slyon> - Working on PR#142: OpenVSwitch Bonds
[15:04] <slyon> (done)
[15:04] <bdmurray> rbalint:
[15:04] <rbalint> * +1 maintenance https://lists.ubuntu.com/archives/ubuntu-devel/2020-May/041012.html
[15:04] <rbalint> * proposed-migration: libcatmandu-sru-perl, libyaml-libyaml-perl, etc.
[15:04] <rbalint> * systemd bug fixes
[15:04] <rbalint> * partner work
[15:04] <rbalint> * kodi 18.7 upload via Debian + merge
[15:04] <rbalint> (done)
[15:05] <bdmurray> waveform:
[15:05] <waveform> * Built raspberrypi-userland packages for pi camera support on armhf and arm64 (and performed cursory verification of all utilities); currently working through myriad lintian warnings
[15:05] <waveform> * Verified python-apt SRUs (LP: #1311056), pending autopkgtest re-runs
[15:05] <waveform> * Built flash-kernel with core-20 boot script (for LP: #1871831)
[15:05] <waveform> (done)
[15:05] <bdmurray> doko is out
[15:05] <bdmurray> sil2100:
[15:05] <sil2100> - SRU reviews and releases
[15:05] <sil2100> - Active work with the snapd team on the UC20 beta release
[15:05] <sil2100> - Added handling for dangerous-<channel> image builds for UC20 in livecd-rootfs and cdimage
[15:05] <sil2100>   * Pushed it to the UC20 PPA + merged into LP branches, need SRUing
[15:05] <sil2100>   * Did some cdimage cleanup as well
[15:06] <sil2100> - PR reviews for UC20
[15:06] <sil2100> - Looked into the reasoning for some mkfs.ext4 flags used in snapd
[15:06] <sil2100> - netplan:
[15:06] <sil2100>   * PR reviews
[15:06] <sil2100>   * Looking into helping out with SRUs for a regression fix
[15:06] <sil2100>   * A bit more code reviewing of the NM netplan plugin
[15:06] <sil2100>   * Work on some SR-IOV improvements
[15:06] <sil2100>   * Looking into OVS bridges
[15:06] <sil2100> - Manually tinkering/fixing old 18-pi3 pi-gadget snap to include missing bluetooth slots
[15:06] <sil2100> - Re-merged the ActivationMode PR for systemd networkd, waiting for upstream
[15:06] <sil2100> - Iterated on some core image builds
[15:06] <sil2100> - Looking into tooling for simplestreams generation (for images) - started tinkering one manually
[15:06] <bdmurray> sil2100: what regression fix?
[15:06] <sil2100> - NEW review of nvidia-graphics-drivers-440-server
[15:06] <sil2100> (done)
[15:06] <bdmurray> juliank:
[15:06] <juliank> * performed a clean install of 20.04 on my old x230 -- full disk encrypted ZFS zsys setup (aes-256-gcm encryption) -- and discovered bug 1880564
[15:06] <juliank> * apt commit review
[15:07] <juliank> * released apt 2.1.5 with more solver fixes, still bugs remaining :/
[15:07] <juliank> * fixed a few bugs in apt-solver-kalel to check how it interacts on those bugs
[15:07] <juliank> * finally approved ddstreet's software-properties merge request
[15:07] <juliank> * prodding people
[15:07] <juliank> * email and bug triage
[15:07] <juliank> (done)
[15:07] <bdmurray> bdmurray:
[15:07] <bdmurray> SRU verification of apport bug LP: #1774843
[15:07] <bdmurray> paramiko -proposed migration investigation (missing dir - 960899)
[15:07] <bdmurray> worked with philroche regarding livecd-rootfs SRU
[15:07] <bdmurray> reported subiquity bug LP: #1880244
[15:07] <bdmurray> uploaded imagemagick fixing LP: #1447968
[15:07] <bdmurray> clarified upgrade command differences for 18.04 TLS in release notes
[15:07] <bdmurray> updated auto-upgrade-testing-specifications for focal -> groovy testing
[15:07] <bdmurray> reported update-manager bug LP: #1880996
[15:07] <sil2100> bdmurray: bleh, I regressed a certain case of handling interface renaming while refactoring some code
[15:08] <bdmurray> reported / investigated update-manager bug LP: #1880987
[15:08] <bdmurray> uploaded a fix for LP: #1826213 to groovy, wrote a test case for it too
[15:08] <bdmurray> sent email to ubuntu-devel re block-proposed-<series> and -v for changelogs
[15:08] <sil2100> bdmurray: I'll be assisting in SRUing the fix for that
[15:08] <bdmurray> sil2100: got it, thanks
[15:08] <bdmurray> ✔ done
[15:08] <bdmurray> vorlon:
[15:08] <vorlon>  * out Monday and Tuesday
[15:08] <vorlon>  * Wednesday and Thursday, working on +1 maintenance; more detailed accounting to follow on mailing list
[15:08] <vorlon>   * working on the big gdal/gsl/hdf5/proj/qt transition, mostly down in the weeds on numeric packages and retrying their autopkgtests with the right triggers
[15:08] <vorlon>   * number of packages made uninstallable by the transition reduced from 2k+ to 579 in the past day or so
[15:08] <vorlon>   * h5py should be clear to go soon also
[15:08] <vorlon> (done)
[15:09] <bdmurray> any questions on status?
[15:09] <bdmurray> #topic Release incoming bugs
[15:10] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html#foundations-bugs
[15:10] <bdmurray> sorting by importance (vorlon!)
[15:10] <vorlon> :)
[15:10] <bdmurray> dbus timeout is desktop
[15:11] <bdmurray> bug 1833174 seems to be fixed upstream
[15:11] <bdmurray> seems like a good one to SRU for 20.04
[15:12] <bdmurray> so lets card that one
[15:12] <bdmurray> bug 1870189
[15:13] <vorlon> that's about the behavior of the cpc images, so cpc should pick it up rather than us
[15:13] <bdmurray> okay mclemenceau can you notify them about that bug?
[15:13] <juliank> cpc-welp :D
[15:14] <bdmurray> bug 1873545
[15:14] <bdmurray> rbalint: that has a fix merged?
[15:14] <rbalint> yes
[15:14] <bdmurray> so if its being worked lets target it and remove the tag
[15:15] <bdmurray> What does foundations need to do here?
[15:15] <bdmurray> Upload u-r-u?
[15:15] <rbalint> release the package, yes
[15:15] <rbalint> and probably sru
[15:16] <bdmurray> okay, it'll need a test case and stuff though but desktop can do that
[15:16] <bdmurray> bug 1427600
[15:16] <juliank> i saw this too
[15:17] <sil2100> Wow, that's an old one
[15:17] <bdmurray> let's take and card that
[15:18] <bdmurray> and make users surprised we fixed it
[15:18] <bdmurray> bug 1880197
[15:18] <vorlon> this is marked low and I think that's accurate; notfixing?
[15:19] <bdmurray> okay
[15:19] <xnox> sure
[15:19] <bdmurray> bug 1880259
[15:20] <vorlon> xnox: do we still need this, or is it superseded by your cd-boot-images package work?
[15:22] <vorlon> seems like we should ignore these for now, and next week we will have more information about whether we should do this in grub or use the cd-boot-images package
[15:22] <bdmurray> then bug 1880250
[15:25] <bdmurray> bug 1879496
[15:25] <juliank> Do we really need this in like groovy?
[15:25] <juliank> who upgrades from grub legacy to grub2 in which releases?
[15:26] <vorlon> if we're not going to ever forcibly transition users to grub2 as part of the upgrade, the script needs to stay around
[15:26] <vorlon> otoh it's amazing that the script has apparently been unusable for 4 years and this is the first bug report
[15:26] <vorlon> for literally years
[15:26] <juliank> anyway sounds like an easy thing to do
[15:27] <bdmurray> so let's target and card that too
[15:27] <juliank> +1
[15:27] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html#foundations-bugs
[15:30] <bdmurray> sorting by descending date created
[15:30] <bdmurray> bug 1880853
[15:30] <rbalint> i think we should take that
[15:30] <bdmurray> rbalint: why?
[15:32] <rbalint> it is installed by default on such instances and those can't upgrade
[15:32] <bdmurray> okay, lets fix that then
[15:32] <bdmurray> rbalint: you also tagged bug 1880541
[15:33] <bdmurray> should we target that for 20.04.1?
[15:33] <rbalint> bdmurray, i think so
[15:34] <bdmurray> we already talked about the plymouth bug
[15:35] <bdmurray> bug 1879592
[15:36] <bdmurray> slyon: have you seen this bug report?
[15:36] <slyon> not yet.. just reading it
[15:36] <slyon> not sure why it would work with 'netplan apply' but not on boot... I guess that is worth debugging
[15:37] <ddstreet> slyon that looks like maybe lp #1860926
[15:37] <bdmurray> slyon: if you can ask a quick question and pop it to incomplete lets do that and revisit next week
[15:37] <slyon> bdmurray, will do
[15:39] <bdmurray> I think we can skip the subiquity ones
[15:39] <bdmurray> bug 1876506
[15:40] <bdmurray> I made an attempt to recreate this but it wasn't easy enough for me to do quickly
[15:40] <bdmurray> juliank: it mentions grube-probe...
[15:40] <cjwatson> vorlon: it's not the first bug report, https://bugs.debian.org/943387 was the first bug report :P
[15:41] <vorlon> cjwatson: oh :)
[15:41] <cjwatson> but people have been slack about merging Debian into Ubuntu
[15:41] <juliank> is that related to os-prober or stuff?
[15:41] <vorlon> juliank: ^^ you're TIL
[15:41] <juliank> I removed os-prober from my system because grub was unusable with snapshots with it
[15:41] <bdmurray> I'm glad you fixed it for yourself. ;-)
[15:42] <vorlon> heh
[15:42] <juliank> I do use thin snapshots, though, they don't look different from normal volumes I believe, so it's not possible to ignore them
[15:42] <bdmurray> To be fair I was hacking debian changelog vim syntax highlighting on my local system in the past week.
[15:42] <vorlon> cjwatson: so the script was unusable for 3 years in Debian instead of 4 ;)
[15:43] <vorlon> bdmurray: +1 for carding the lvm snapshot issue
[15:43] <bdmurray> okay, lets move on to -proposed
[15:44] <bdmurray> #topic Team proposed-migration report
[15:44] <vorlon> [LINK] https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses_by_team.html#foundations-bugs
[15:45] <vorlon> numpy seems to have caused a real regression in python-meshio, we're waiting for upstream input; mclemenceau it doesn't look like you've opened an update-excuse bug on this yet?
[15:45] <vorlon> mclemenceau reports that he's bisecting, so still in progress
[15:47] <vorlon> perl is a candidate but tied into the big messy soname transition I'm working on
[15:47] <vorlon> the next 2 are also dependent on perl
[15:47] <vorlon> python-numpy blocking python-tz, who can take this?
[15:47] <rbalint> i take that
[15:47] <vorlon> rbalint: actually, python-tz generally please
[15:47] <vorlon> (3 revdeps w/ autopkgtest regressions)
[15:47] <rbalint> vorlon, i was about to suggest that
[15:48] <vorlon> ta
[15:48] <vorlon> netplan.io blocking network-manager on arm64 - slyon do you want to look at this? (might just require an autopkgtest retrigger, in which case you can ask on #ubuntu-release for us to do that)
[15:48] <slyon> vorlon, yep, that's mine
[15:48] <vorlon> thanks
[15:48] <tdaitx> back
[15:49] <vorlon> golang-defaults is probably a false-positive on autopkgtests since this is a minor package change only; I'll investigate
[15:49] <vorlon> util-linux is a riscv64 build regression
[15:49] <vorlon> anybody keen to debug util-linux build failure in a riscv64 qemu?
[15:50] <xnox> $ rmadison libboost-wave-dev -s groovy
[15:50] <xnox>  libboost-wave-dev | <IP_ADDRESS>ubuntu2 | groovy/universe | i386
[15:50] <xnox>  libboost-wave-dev | <IP_ADDRESS>ubuntu4 | groovy/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[15:50] <xnox> $ rmadison libboost-wave-dev -s groovy
[15:50] <xnox>  libboost-wave-dev | <IP_ADDRESS>ubuntu2 | groovy/universe | i386
[15:50] <xnox>  libboost-wave-dev | <IP_ADDRESS>ubuntu4 | groovy/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[15:50] <xnox> $ rmadison libboost-wave-dev -s groovy
[15:50] <xnox>  libboost-wave-dev | <IP_ADDRESS>ubuntu2 | groovy/universe | i386
[15:50] <xnox>  libboost-wave-dev | <IP_ADDRESS>ubuntu4 | groovy/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[15:50] <xnox> bah
[15:50] <xnox> sorry for spam
[15:51] <vorlon> sounds like the cert team has riscv64 vms as a service
[15:52] <vorlon> bdmurray: this is yours :)
[15:52] <vorlon> python-secretstorage vs python3-jeepney, that's an MIR that was deferred last cycle
[15:52] <vorlon> I'll chase it
[15:53] <vorlon> vim, another riscv64 build regression
[15:53] <vorlon> tdaitx: ^^ do you want to take this one?
[15:53] <vorlon> git blocked on fdroidserver, I'll chase that
[15:54] <tdaitx> vorlon: will do
[15:54] <vorlon> tdaitx: thanks
[15:54] <vorlon> apt-clone blocking make-dfsg: juliank ?
[15:54]  * juliank takes apt-clone, dpkg blocks make-dfsg; and autopkgtest, update-notifier blocks apt
[15:54] <juliank> so yes
[15:54] <vorlon> juliank: does that mean you'll take all the make-dfsg blocks?
[15:55] <juliank> I can try
[15:55] <vorlon> thanks
[15:55] <juliank> I know the others are pyflakes issues, and dpkg a weird make one
[15:55] <vorlon> openjdk-8 blocking xorg-server
[15:55] <vorlon> tdaitx: ^^ maybe you can knock this one out quickly while waiting on riscv64 vim builds :)
[15:55] <tdaitx> wut? let me take a look at that
[15:55] <juliank> (pyflakes issue ~ python2 pyflakes removed, need to use pyflakes3 instead)
[15:55] <vorlon> :)
[15:55] <vorlon> re2 is a candidate but stuck in the big transition
[15:56] <vorlon> libre-engine-re2-perl, also blocked by perl transition
[15:57] <vorlon> ucf vs mercurial on s390x
[15:57] <vorlon> ISTR mercurial/s390x being flaky, so maybe easy
[15:57] <rbalint> i retried
[15:57] <vorlon> ok
[15:57] <vorlon> then rbalint can follow through on the results
[15:57] <rbalint> ok
[15:58] <vorlon> and fonts-dejavu looks like it has dropped the legacy ttf-* names and needs revdeps to transition
[15:58] <vorlon> xnox: can you take this pile of wax?
[15:58] <xnox> ok
[15:58] <vorlon> ta
[15:58] <vorlon> and that's the list
[15:58] <vorlon> bdmurray:
[15:59] <bdmurray> #topic AOB
[15:59] <rbalint> i'll be out tomorrow and on Monday
[16:00] <vorlon> ah yes, worth mentioning that I'm out next week
[16:00] <slyon> i'll be out Monday as well
[16:01] <mclemenceau> o/
[16:01]  * bdmurray waves to mclemenceau
[16:02] <tdaitx> I am taking half-day off (afternoon) today and tomorrow
[16:02] <bdmurray> Okay, I don't want to hear anybody taking time off
[16:02] <bdmurray> #endmeeting
[16:02] <meetingology> Meeting ended Thu May 28 16:02:51 2020 UTC.
[16:02] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-05-28-15.01.moin.txt


[16:53] <ameetp> I have a system bug 611454 that just sits at "loading grub..." and nothing else happens.  Anyone know how to drop into a rescue shell or something to pull some logs?
[16:53] <ubot2> Launchpad bug 611454 in grub2 (Ubuntu) "Acer Aspire One ZA3 751h does not boot GRUB (affects: 1) (heat: 8)" [High,Incomplete] https://launchpad.net/bugs/611454
[17:01] <ev> ameetp: cjwatson will be able to help you a lot better than I can, but is the message exactly "loading grub..."  If memory serves, grub uses that text as somewhat of a progress bar, so if even a single . is missing, that's important.
[17:28] <ameetp> ev:  I will have double check.  But thanks for the feedback
[17:32] <ev> sure thing
[18:12] <CIA-4> ubiquity: superm1 * r4141 ubiquity/ (bin/ubiquity-dm debian/changelog):
[18:12] <CIA-4> ubiquity: If there is at least one framebuffer device, fallback to fbdev rather
[18:12] <CIA-4> ubiquity: than vesa for bulletproof X.
[18:23] <CIA-4> ubiquity: superm1 * r4142 ubiquity/ (bin/ubiquity-dm debian/changelog): Remove extra imports in ubiquity-dm.
[21:01] <shtylman> why are people up in arms about this whole gnome contribution thing?
[21:02] <shtylman> maybe I just don't pay attention but I never got the impression that canonical was trying to make it seem like they are major contributors to gnome
[21:02] <shtylman> I actually saw that gnome was falling behind compared to what ubuntu/canonical was doing... :/
[21:02] <shtylman> but meh.. maybe I don't know the whole story :)
[21:50] <CIA-4> ubiquity: superm1 * r4143 ubiquity/ (bin/ubiquity-dm debian/changelog debian/ubiquity.templates):
[21:50] <CIA-4> ubiquity: Add a new template ubiquity/force_failsafe_graphics intended to force
[21:50] <CIA-4> ubiquity: installation to use vesa or fbdev, but not on the target system. This is
[21:50] <CIA-4> ubiquity: primarily intended for systems where the installation kernel has known
[21:50] <CIA-4> ubiquity: graphics problems, but you are solving them in a post installation step.


[00:02] <powersj> kalx2: are you trying to prevent the image from generating SSH keys automatically?
[00:03] <kalx2> powersj: I still want it to generate the local RSA/DSA/ECDSA/etc keys. I don't want it to take the key provided by EC2 Metdata and add it to the authorized_keys file
[00:04] <kalx2> powersj: Basically, looking to have a hardcoded key in authorized_keys, and just have cloud-init do the RSA/DSA/ECDSA/etc key generation and not touch the authorized_keys file.
[00:04] <kalx2> I assume the SSH module is what's grabbing the key from EC2 metadata and adding it to authorized_keys. However, I can't find any config related to this or to disable it
[00:05] <powersj> there is a disable_ec2_metadata option, but I'm not sure what other impacts that would have.
[00:26] <kalx2> powersj: from the logs, it looks like it grabs a lot of other info from the ec2 datasource like details on storage devices to auto-mount, etc.
[00:27] <powersj> ah that does make sense, probably not something you want to wholesale blow away :)
[00:27] <kalx2> powersj: so not so desirable here., yes : ) This disable SSH key seems like it would be a somewhat common usecase, will try to search more
[00:27] <kalx2> thx for your help though
[00:55] <kalx2> very odd. I don't find anything and the SSH module doc doesn't mention anything about performing this function. Best choice seems to disable the ssh module and take care of the host key generation manually via script