[02:50] <c_smith> where would I put a theme to install it System-wide? it's a neither an Icon theme nor a cursor theme
[02:51] <c_smith> /usr/share/themes, right?
[05:37] <parin> darkxst: Hi. I tried printing g_getenv("DISPLAY") and both the displayconfig code and mutter recognize :0.0
[05:39] <parin> there is no backtrace. GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()); gave an assertion error that it wasn't fed a valid display. Changing it to XOpenDisplay() removed that error but the program crashes with a segfault in meta_monitor_manager_xrandr_read_current()
[07:06] <Uallas> Good Morning
[11:05] <darkxst> parin, hi
[11:08] <darkxst> parin, can you send a patch with your changes (or push it to github and I will take a look)
[11:42] <parin> darkxst: okay
[11:55] <darkxst> parin, and as soon as you get a seg fault you should be firing up gdb and getting a backtrace ;)
[12:54] <parin> darkxst: I've pushed the changes to https://github.com/parinporecha/mutter-compiz/tree/gnome-3-10
[12:54] <parin> darkxst: I do know where the segfault occurs
[12:55] <parin> it's all due to the null display we're getting from gdk_display_get_default
[12:57] <darkxst> maybe you need Xopendisplay there as well?
[12:57] <parin> when I replace it with XOpenDisplay (is the replacement okay ?), we don't get null, but I get this error - X Error of failed request:  BadName (named color or font does not exist)
[12:58] <darkxst> I don't think you can just replace it!
[12:58] <darkxst> you may need both
[12:59] <parin> both, how ?
[13:02] <darkxst> hmm no I was thinking of XopenScreen i suppose
[13:03] <parin> darkxst: I think we're using gdk_display_get_default in a wrong way
[13:03] <parin> in the mutter code, I replaced meta_get_display()->xdisplay with GDK_DISPLAY_XDISPLAY (gdk_display_get_default ());, and it's giving the same error
[13:05] <darkxst> possibly there is some initialization missing?
[13:05] <parin> meta_get_display() calls the same function GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()) in ui.c But, yes there maybe some initialization missing. I'm looking into it
[13:08] <darkxst> parin, whats with all the whitespace cleanups?
[13:09] <parin> some problem with Geany
[13:09] <darkxst> change editor then, it bloats the patches
[13:10] <parin> darkxst: okay, I'll see that it doesn't happen again
[13:13] <darkxst> also I don't really need to see your debug statements ;0
[13:13] <darkxst> ^ that is what gdb is for anyway
[13:43] <parin> darkxst: i was wrong. mutter does get the display from gdk_display_get_default (). Doesn't matter when it's called. The same line when replaced in our displayconfig code, it doesn't work. GdkDisplay doesn't have any function to set default display or something also. I'll ask this on gnome-shell mailing list, see if I get anywhere
[13:45] <darkxst> ok, I'm off for the night, will have a look at it in the morning
[23:21] <roasted> hello friends
[23:22] <roasted> by chance has anybody ever done an in-place upgrade of say 13.04 >> 13.10 while having PPAs installed to bring in the newest Gnome?
[23:31] <darkxst> don't do it
[23:31] <darkxst> ppa-purge PPA's, upgrade, then re-install PPA's
[23:33] <roasted> ah, alright
[23:34] <roasted> I was hoping for a clean break from 13.04 to 13.10, but ppa-purge is a small price to pay I suppose.
[23:36] <darkxst> PPA's are disabled (not purged) when you run an upgrade, from there any packaging changes from the ppa that are not in 13.10 will just confuse the do-release-upgrade
[23:37] <roasted> ah, that's the part I mixed up then.
[23:37] <roasted> purge vs simply disabled.
[23:38] <roasted> so I'd effectively bring 13.04 down to 3.6 before the upgrade then.
[23:38] <darkxst> yeh
[23:39] <roasted> are you the only core dev at this point darkxst?
[23:39] <darkxst> ricotz as well
[23:39] <darkxst> hey I gotta run
[23:39] <roasted> take it easy!


[03:43] <kabo> hi
[03:43] <kabo> is there any workaround to get snaps to run in wayland?
[03:43] <kabo> I'm on Debian Bullseye with Gnome 3.38
[03:44] <kabo> I found a comment here which suggested setting DISPLAY env variable, but didn't work for me
[03:44] <kabo> https://bugzilla.redhat.com/show_bug.cgi?id=1883621#c5
[10:39] <ogra> kabo, https://forum.snapcraft.io/t/apps-wont-run-and-crash-on-gnome-wayland/20322
[22:49] <kabo> ogra: thanks, I'll take that as a "no" :)


[00:55] <smoser> nacc, here.
[05:29] <cpaelzer> good morning
[07:32] <webnar_> @ppetraki Hi
[07:33] <webnar_> the Raid still works without issues
[07:34] <webnar_> So indeed it looks like a bug in Ubuntu server 16.04
[07:41] <joy-ict> Hi there :-) I'm looking for some help with setting up a forwarding dns
[07:41] <joy-ict> I want to use Moodle and Suitecrm outside the office. But the only things i can run outside now are SSH and Webmin
[12:13] <coreycb> jamespage: when you get a moment can you promote newton-staging to newton-proposed?
[13:39] <aaronr> cpaelzer: happy to help further with the proposed verification of https://bugs.launchpad.net/ubuntu/+source/nagios3/+bug/1686768 when it gets to that stage. i'll continue to monitor the bug, and will check in here to find out what i need to do when the time comes
[14:06] <DammitJim> have you guys disabled SMBv1 on all your linux systems?
[14:06] <DammitJim> someone just came to me telling me we need to disable it on all of our Linux systems because of the wanna Crypto vulnerability
[14:06] <DammitJim> how true is this? or where should I go to get the truth?
[14:07] <azidhaka> i don't think samba is vulnerable
[14:09] <DammitJim> dammit... it's so hard to find answers to these questions from a reliable source
[14:09] <DammitJim> azidhaka, nothing against you. I appreciate that at least you replied
[14:10] <DammitJim> but I need something to backup my answers so that the company doesn't send me to update all my linux machines
[14:10] <DammitJim> I have other projects that need to get done and I don't know that this is a real critical problem at this time
[14:11] <dpb1> DammitJim: did they point you to a CVE?
[14:12] <DammitJim> no, this is more of an: I read a blog and they said you need to disable SMBv1
[14:12] <DammitJim> now, since they have posed the question, I have to show that it's not necessary
[14:12] <DammitJim> does that make sense?
[14:13] <teward> DammitJim: does https://www.cyberciti.biz/faq/how-to-configure-samba-to-use-smbv2-and-disable-smbv1-on-linux-or-unix/ help?
[14:13] <DammitJim> teward, actually I think that's the article they read
[14:13] <teward> DammitJim: ultimately CIFS / SMB will default to trying version 2.0 or 3.0 and fall back to 1.0 iirc.  That said, if you have older servers (Win 2k3) or servers which aren't new enough to support SMBv2 then, that's out of the scope of what you can do
[14:14] <teward> DammitJim: that's... not an article, that's a how-to
[14:14] <teward> and that only applies to Samba servers
[14:14] <DammitJim> but I don't know who told this guy that he needs to disable SMBv1 because of wanna crypto
[14:14] <teward> not Samba clients on Linux devices
[14:14] <DammitJim> make sense?
[14:14] <azidhaka> DammitJim: the samba vulnerabilites are listed here: https://www.cvedetails.com/vulnerability-list/vendor_id-102/Samba.html
[14:14] <teward> DammitJim: because SMBv1 *is* ancient and vulnerable and should be disabled except for absolutely critical legacy support of things
[14:15] <DammitJim> again, I am just trying to figure out if I need to disable SMBv1 because of wanna crypto or because of it being OLD and vulnerable in general
[14:15] <DammitJim> does that make sense?
[14:15] <teward> DammitJim: stop saying "does that make sense"
[14:15] <teward> it's irritating
[14:15] <teward> yes, it does make sense.  you should disable for BOTH reasons
[14:15] <DammitJim> because if it is because of wanna crypto, I have to drop everything and disable SMBv1 on all my servers right now (test first)
[14:15] <teward> and patch all Windows 7 systems.
[14:15] <azidhaka> DammitJim: if you have old clients which require smbv1, do not disable it
[14:15] <teward> windows 7 / 8 / xp systems *
[14:15] <DammitJim> but if it is just because of it being old and vulnerable, I can table that and deteremine where it falls in my schedule of things
[14:16] <azidhaka> DammitJim: i wouldn't unless it vulnerable
[14:16] <DammitJim> yeah, windows server/workstations patching is in progress
[14:16] <DammitJim> teward, I'll stop saying "does that make sense"
[14:16] <DammitJim> ;)
[14:16] <teward> DammitJim: unless your LInux systems are running Wine, then, you shouldn't disable SMBv1 unless it's absolutely necessary to disable it.
[14:16] <teward> WannaCrypt won't hurt your Linux boxes unless you've got Wine, and unless your SMB servers are internet facing directly I'd be a little less concerned
[14:16] <DammitJim> ok, so it seems the consensus is that disabling SMBv1 doesn't have much to do with WannaCrypt
[14:17] <azidhaka> DammitJim: in linux
[14:17] <teward> ^ that
[14:17] <teward> DammitJim: in Windows it's a different story
[14:17] <DammitJim> thanks azidhaka ... in linux
[14:17] <DammitJim> right
[14:17] <DammitJim> ok, thanks! I'll tell the group that asked me this question that the how to they found makes it sound like wannacrypt and SMBv1 are related but in reality they aren't
[14:17] <teward> well
[14:17] <DammitJim> thanks guys!
[14:18] <teward> DammitJim: that's not entirely accurate either
[14:18] <DammitJim> uh oh
[14:18] <azidhaka> DammitJim: SMBv1 was vulnerable in Windows, is not vulnerable in Linux
[14:19] <azidhaka> DammitJim: disable it or patch all your windowses and leave the linuxes alone :)
[14:19] <teward> azidhaka: The question is two-fold.
[14:19] <teward> erm
[14:19] <teward> DammitJim: ^
[14:19] <teward> Question 1: Is SMBv1 vulnerable in Linux?  Question 2: Is SMBv1 vulnerable to WannaCrypt in Windows?
[14:19] <teward> And Question 3: Is SMBv1 vulnerable to WannaCrypt in Linux
[14:20] <DammitJim> yes, I am trying to address question 3
[14:20] <teward> Answer to #1: No, not really.  Answer to #2: Absolutely, patch all windows systems and disable SMBv1 on the client systems
[14:20] <teward> Answer to #3: Not really.  Just don't run Wine on linux systems.
[14:20] <DammitJim> it's all in the context of: Do I need to disable SMBv1 on all my linux systems because of wanna cry
[14:20] <DammitJim> and the answer is NO
[14:21] <DammitJim> thank you!
[14:21] <teward> DammitJim: read https://askubuntu.com/questions/914623/what-is-the-wanna-cry-ransomwares-possible-impact-on-linux-users
[14:21] <DammitJim> oh, also know that we don't use wine
[14:21] <DammitJim> we drink it ;)
[14:21] <teward> ultimately you have your answer.  So long as you patch your Windows systems and servers and install the security updates regularly
[14:22] <teward> because there's other nasties that get patched regularly you need to patch against :p
[14:22] <DammitJim> yeah, I am trying to get our group on a schedule for patching different o/s in a regular basis
[14:22] <DammitJim> I got interrogated about: do you read all the release updates at all times to know if we need to patch our systems?
[14:22] <DammitJim> if someone can tell me how one can do that, please let me know!
[14:22] <teward> unattended-upgrades for Linux systems, exclude the Linux packages, set to run daily, don't force reboot
[14:23] <teward> email a given email address on the network when completed.
[14:23] <teward> unattended-upgrades is what keeps the mail server and a few other servers at the one workplace i work with up to date with security updates
[14:23] <teward> we patch the rest for bugs monthly
[14:24] <Ussat> teward, if you use unattended, I assume you test first, on a test system....
[14:26] <teward> On six systems, yes.
[14:26] <teward> THat said, the only things that we really just need patched are the kernel and a few other things, we disable all other updates.  Security-only, and those go through some pretty thorough tests, as I understand those security releases/updates.
[14:26] <teward> sarnold: ^ cc
[14:26] <teward> the only other thing we'd worry about is nginx, but that's usually patched within a day of me seeing a patch heh
[14:27] <teward> since I help the security team sometimes with that :)
[14:34] <DammitJim> teward, how do you test that the updates aren't breaking something?
[14:37] <teward> i have a test environment running the same services as production does, and a test suite that tests functionality every day an hour after updates complete.  If nothing fails, that doesn't issue a "Don'tUpdate" notice to the production systems
[14:37] <teward> lots of custom code
[15:24] <nacc> smoser: do you think it's reasonable (UX) to have `git ubuntu add-remote` only work with an explicit directory or from the current directory? (then we can derive, e.g., the srcpkg and such)
[15:37] <smoser> nacc, that seems fine to me.
[15:37] <smoser> add-remote user ?
[15:37] <smoser> you mean
[15:37] <nacc> smoser: yeah
[15:37] <smoser> git-ubuntu add-remote <thing>
[15:37] <nacc> smoser: so you'd only need to add the lp-user you want to add the remote of
[15:38] <nacc> smoser: we'd figure out everything else
[15:38] <smoser> i was thinkign <thing> could be a full remote, but then it takes a name too
[15:38] <smoser> i think its sane.
[15:38] <nacc> smoser: oh true, it could be -- although, imo, adding a remote with a full url is a better task for `git` itself :)
[15:38] <smoser> git ubuntu add-remote <user> [name-if-different]
[15:39] <smoser> but i think it should be remote-add
[15:39] <smoser> right ?
[15:39] <smoser> as that is gwhat it is to git
[15:39] <smoser> git remote add <name> <url>
[15:39] <nacc> smoser: hrm, true
[15:40] <smoser> git ubuntu remote-add <user> [url]
[15:40] <smoser> that follows pretty easily dont you think ?
[15:40] <smoser> if you give it url, it just calls git add remote
[15:41] <smoser> except fdor the case where you dont want your name the same as the user i guess.
[15:41] <smoser> :-(
[15:41] <nacc> smoser: yeah, but then i need to check the input for a url
[15:41] <nacc> smoser: your 'name' meaning the remote's name?
[15:41] <smoser> well, you need both remote name and user
[15:41] <smoser> right ?
[15:41] <nacc> right, we curently make them the same
[15:41] <nacc> we can take a remote-name as an optional parameter
[15:42] <nacc> or a flag, even
[15:42] <smoser> i think its probably reasonable to want to change the name
[15:42] <smoser> (ie, for that ~ubuntu user)
[15:42] <smoser> git ubuntu remote-add [--remote-name=name] user [url]
[15:42] <nacc> smoser: oh good point , i usually change racb to robie :)
[15:42] <nacc> smoser: yep
[15:42] <smoser>  remote name is user by default
[15:42] <nacc> smoser: thanks! that's good!
[15:43] <smoser>  if url is provided, then it just goes onto git remote add
[15:43] <nacc> smoser: yep
[15:43] <nacc> smoser: cool, thanks!
[15:43] <smoser> switfching location
[17:33] <sarnold> DammitJim: we publish USNs to https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce and https://www.ubuntu.com/usn/ -- and we're trying to get the hang of https://twitter.com/ubuntu_sec but no promises there
[17:48] <DammitJim> thanks sarnold!
[17:48] <DammitJim> sarnold, this is different than lists.ubuntu.com mailing lists, right?
[17:48] <mason> azidhaka: That's on lists.ubuntu.com.
[17:49] <mason> DammitJim: *
[17:49] <mason> Not sure how tab pulled up azidhaka.
[17:49] <DammitJim> I say that because I had forgotten that I have some kind of account and get the email every first of the month telling me what my password is LOL
[17:51] <sarnold> "gee thanks mailman"
[17:51] <sarnold> hehe
[17:51] <DammitJim> what I mean, though is that the link you posted seems to be a separate subscription?
[17:52] <DammitJim> or can I just add that subscription to my account?
[17:52] <sarnold> 'separate' to what? there's a billion lists hosted there..
[17:53] <DammitJim> meaning... if I go to my Membership configuration page
[17:53] <sarnold> iirc there's a button in one of the mailman fields for allowing you to turn off the monthly password reminders 'globally', but they're for the most part all independent from each other
[17:53] <DammitJim> I don't see an option to get security subscriptions ? I'm blind
[17:53] <DammitJim> and you are right, there is an option to NOT get your password
[17:54] <DammitJim> oh, interesting... so I guess my account is just for the ubuntu-us-fl mailing list
[17:54] <DammitJim> nothing to do with getting security announcements....
[17:55] <DammitJim> man, patching is a neverending story, isn't it?
[17:56] <mason> DammitJim: You can just subscribe to the security list. It's a plain vanilla Mailman.
[17:56] <mason> I subscribed, and it yelled at me because I was already subscribed.
[17:57] <DammitJim> LOL
[17:57] <DammitJim> I"m going to shut up now
[17:57] <sarnold> DammitJim: never-ending.. you have no idea.
[17:57] <DammitJim> :D
[17:58] <mason> Patching makes my cold heart warm.
[17:58] <sarnold> DammitJim: it's insanely demoralizing to have new issues reported against a packaage just when you're about to release updates for it for older issues..
[17:58] <DammitJim> hahaha... I don't have a problem patching a system
[17:58] <DammitJim> I have a problem testing all the systems after the patch
[17:58] <mason> True, doing things right is a beast.
[17:59] <DammitJim> I don't know why, but the company where I work wants all applications that we use on that server tested in a sandbox before the patch
[17:59] <mason> Containers will save us.
[17:59] <mason> heh
[17:59] <DammitJim> mason, I'd like to think that ;)
[17:59] <mason> Do you do dev → qa → prod and the sandbox is one of the first two?
[17:59] <DammitJim> sandbox is kinda like dev
[17:59] <mason> I'm a fan of organized promotion. That said, I don't do it for my home set-up, and I'm not an admin any more, so I've grown lax.
[18:00] <DammitJim> we've moved away from the dev being managed by my team and dev is more what the developers maintain, which is kinda nice
[18:00] <DammitJim> what do you do now, mason ?
[18:00] <mason> DammitJim: Technical Account Manager
[18:00] <DammitJim> I'm starting to get tired of the admin role
[18:01] <DammitJim> but heck, I have a job, so I shouldn't complain
[18:01] <mason> Being a TAM's like being an admin, but more use of soft skills, and issues don't follow me into evenings and weekends.
[18:01] <mason> Yar.
[18:01] <DammitJim> LOL
[18:01] <DammitJim> that's 1 of them... it gets in the way of my family life...
[18:02] <mason> Before I became a TAM, I was an admin, and right before I took the offer for my current job, I had an on-call week where I got four hours of sleep, once, during my on-call week. That was the peak of sleep, and most sleep periods were much shorter. Made it easy to accept the offer.
[18:02] <sarnold> DammitJim: definitely if you can put together enough of your environment in a VM or something, it can save some hassles. we do our best but mistakes happen, and, like you, it's quite difficult to test everything.
[18:02] <DammitJim> anyways, thanks for the info. I'm trying to assign someone in my team to review the security updates on a daily/weekly basis so we know if we need to accelerate patching for a system
[18:03] <mason> DammitJim: The list will be useful, and you probably already use something like apticron.
[18:03] <mason> ...or something centralized that does that.
[18:03] <DammitJim> sarnold, man, thanks for speaking from the heart. I know you guys are doing your best and I don't have anything about patches. it's just that sometimes developers and even admins make mistakes in putting configs where they shouldn't be and then an update (that needs to really fix something) changes how something works and then the developed app no longer works
[18:04] <mason> DammitJim: Do you use Ansible or Puppet or similar?
[18:04] <DammitJim> the hard part about the list is really understanding the impact or severity to determine if we need to go through the patching cycle
[18:04] <DammitJim> I use salt, so with that respect, things can be fixed quickly
[18:04] <mason> The whole cfengine-inspired trusted repository with admins only accessing the repo through version control is hugely good.
[18:05] <mason> kk
[18:05] <DammitJim> but that's not the problem... the problem is time spent testing and guess who ends up having to test? the support team
[18:05] <DammitJim> and letting the customers know that there will be an outage
[18:06] <DammitJim> I'll be honest in saying that in other companies, I patched w/o testing and this wasn't as much of an issue... out of patching hundreds of times, we probably only had an issue once
[18:06] <mason> Redundancy can help with outages, especially if your platform is using a stable API and you're just fixing bugs.
[18:06] <DammitJim> yeah!
[18:07] <DammitJim> do you guys have someone on your team that reads the security releases on a daily basis?
[18:07] <DammitJim> how do you determine if the patch needs to be applied ASAP?
[18:07] <DammitJim> I wanna say for Ubuntu servers, I patch every quarter *cringes*
[18:08] <mason> In admin teams I've been on, I tend to do that regardless of any formal activity. Varies a lot formally.
[18:08] <DammitJim> yeah, very subjective, right?
[18:09] <sarnold> DammitJim: we don't really judge -severity- since that can vary wildly from site to site. we do prioritize the order in which we work through the CVEs; here's the criteria we use http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/README#L191
[18:09] <mason> Oh, you mean sarnold and the Canonical security team. Sorry for the noise. Heh.
[18:10] <DammitJim> no, I meant exactly what sarnold just said... for my company, how do I determine the severity of the security problem for which a fix has been released
[18:10] <sarnold> DammitJim: most of us do take most weekends :)
[18:10] <DammitJim> I'd drive myself nuts learning every single issue and understanding how it impacts me
[18:10] <sarnold> but tracking CVEs is almost a full-time position for us
[18:11] <mason> Gods, just reading the security-lists is a ton of work, let alone parsing for applicability.
[18:11] <DammitJim> right... that's my challenge, but it's a good one and one that needs to be dealt with
[18:12] <DammitJim> this week when this whole thing about WannaCry came out
[18:12] <DammitJim> I didn't know what to say about patching when I was asked about it
[18:12] <DammitJim> why haven't you guys patched the Windows servers?
[18:13] <DammitJim> well, we are in a 3 month cycle and we haven't gotten around to it since we patched back in March
[18:13] <DammitJim> oh, you need to patch them... sure, that's the plan
[18:13] <DammitJim> I'm digressing.... I'm going to stop
[18:13] <DammitJim> I hope you guys have a great Friday, though!
[18:15] <mason> DammitJim: You too!
[18:23] <DammitJim> I'm not going anywhere, just trying to keep the channel on-topic ;)
[18:56] <nacc> rbasak: i assume you're not around?


 Not seeming all that different
[00:04] <bazhang> yep. that was my first reaction, they were both active
[00:04] <elky> ah
[00:04] <bazhang> the original "lolcat" makes zero sense
[00:09] <bazhang> ugh
[04:07] <rww> niko: you're about to get a bunch of highlights
[04:07] <rww> everyone else: floodbot bans older than a week old are getting cleaned out in a few minutes
[04:07] <Madpilot> in #u?
[04:08] <rww> ja
[04:08] <Madpilot> moderately quiet there, so not a bad time to do it.
[04:10] <rww> done
[04:14] <rww> fyi, unless someone comes up with a better plan, this is going to be a weekly occurance from now on. Floodbots have a lot of bans, and nobody reviews them, so...
[04:15] <Madpilot> until we get some way to auto-expire bans, sounds like a plan.
[04:16] <rww> throwing eir in there and autoexpiring them would be <3
[04:16] <Madpilot> I'd love to be able to set, say, a 48hr or 7 day or whatever auto-expire on a ban
[04:17] <rww> ditto. I know we're all about the "come in -ops and have talking time before removal" here, but 90% of the bans I set get removed because I don't want to be the king of the banlist and the users probably aren't coming back, not because the users drop by here.
[04:18] <tonyyarusso> rww: +abillion from me.
[04:18] <tonyyarusso> autoexpiry would make me very happy.
[04:19] <tonyyarusso> rww: I'd like to be able to say "Assume my bans are for 24 hours unless instructed otherwise."
[04:19] <tonyyarusso> Whether "instructed otherwise" means shorter or longer.
[04:20] <tonyyarusso> It'd be awesome if each operator could define their own default as well, since some people ban for smaller things, but remove them sooner, while others only bother banning for extremes, that then deserve long periods.
[04:21] <Madpilot> that'd be useful
[04:22] <Madpilot> ...and my banlist has it's second-ever occupant. root-tard or whatever it calls itself just attempted PM spam.
[04:22] <rww> (btw, if anyone isn't subscribed to the IRCC agenda page, this is a topic for their next meeting)
[04:23] <rww> Madpilot: yeah, known troll, banned from all the core channels by IRC Council.
[04:23] <rww> Madpilot: current resident of the club
[04:24] <Madpilot> yeah, I recognized the nick from mailing list discussion. How soon can we get Freenode to shut them down, anyway?
[04:24] <Madpilot> running a channel dedicated solely to trolling another namespace's ops has to violate Freenode's ToS in some way? I hope?
[04:25] <tonyyarusso> I think the only way for *us* to do anything about it would be if Canonical's legal department got involved, but I'd concur with the amazement that Freenode hasn't decided to boot them all on their own.
[04:43] <Madpilot> http://freenode.net/policy.shtml
[04:45] <Madpilot> specifically, http://freenode.net/policy.shtml#offtopic "These channels should not be used as platforms for flaming and trolling."
[04:45] <Madpilot> further, "You may not register such a channel on freenode without accepting these policies."
[04:47] <Madpilot> and in another section, further down, "We expect all members of the community to treat other community members with respect and reserve the right to terminate anyones access to our services should they be found to be in breach of policy. "
[04:47] <Madpilot> So, yeah.
[04:47] <Madpilot> Dear Freenode, please follow your own policies and do the obvious.
[05:10] <bazhang> codereaper, hi
[05:23] <bazhang> nothing via bansearch that I can see
[05:48] <bazhang> CptUnderpants, hello
[06:06] <CptUnderpants> hi
[06:06] <CptUnderpants> sorrt
[06:06] <CptUnderpants> sorry
[06:06] <bazhang> np
[06:07] <CptUnderpants> do you handel techianl issues
[06:08] <bazhang> #ubuntu for that. this is for channel issues
[06:08] <CptUnderpants> sorry bout this
[06:08] <bazhang> no worries
[06:29] <rww> Madpilot: 7% of lines in #ubuntu-offtopic are AtomicSpark O_O
[06:29] <Madpilot> rww, over what time period?
[06:29] <rww> since Jan 1st
[06:29] <Madpilot> Lord Dog
[06:29] <Madpilot> dude's going to get RSI just from -offtopic
[06:30] <rww> ( http://rww.name/pisg/ubuntu-offtopic-lines.html )
[06:30] <rww> nah.  He'll get bored eventually and be quieter for a few months :\
[06:32] <Madpilot> 65,000 words for AtomicSpark, and the next highest wordcount was 39,000? am I reading that Big Numbers section right?
[06:32] <rww> yes
[06:32] <rww> I note that he also has almost twice as many lines as the second highest person
[06:33] <tonyyarusso> yeah..........
[06:33] <rww> which... I would care more if he spent the whole time talking about flashlights.
[06:34]  * Madpilot notes that certain ops are kind of in those proverbial glass houses when it comes to odd stats in -offtopic... :)
[06:35] <rww> I ran the numbers. If I don't talk in -ot until around May, I'll be out of the top 25 :<
[06:35] <Madpilot> best of luck with that
[06:36] <Madpilot> of course, it's your stats app. "tweaks" could be applied...
[06:36] <tonyyarusso> If we assume that AtomicSpark spends 8 hours sleeping, eating, and otherwise indisposed, he has spoken a line in -ot every 5 waking minutes of the year so far.
[06:36] <rww> Madpilot: that would be unethical :(
[06:37] <Madpilot> we could mute you until May sometime, then :)
[06:38] <rww> Madpilot: I did consider that, yes ;)
[06:38] <Madpilot> actually, would +q stick to an op? +b doesn't, afaik
[06:38] <rww> +q and +b don't stick if you're currently opped in the channel, and +b can be defeated with /msg chanserv invite
[06:38] <rww> but if I were addicted enough to need +q'ing, I'd just remove the +q :P
[06:39] <Madpilot> well, yes. hmm.
[06:40] <rww> also, if talking too much in a channel is bad, +qing me in here would seem to be smarter >.> <.< >.<
[06:41] <Madpilot> TZ is GMT/Zulu on your stats page, I take it?
[06:41] <rww> yes
[06:48] <Madpilot> rww, your #ubuntu stats page is trying to claim there isn't a /topic there...
[06:50] <rww> Madpilot: the topic hasn't been set since before Jan 1st.
[06:50] <rww> was last set in December
[06:50] <Madpilot> ah, so.
[06:51] <Madpilot> your stats scraper only notices topics when they change, then
[06:51] <rww> yup
[06:59] <Madpilot> I see a few of our trolls get their 15 seconds of fame... mostly in the "potty mouth" category...
[07:11] <elky> I clearly don't talk enough rubbish.
[07:11] <elky> The damned bot has more lines than me!
[07:13] <tonyyarusso> elky: indeed - you should rubbish mre.
[07:13] <tonyyarusso> *more
[07:21] <rww> ubottu: tell AtomicSpark about enter
[07:21] <tonyyarusso> ubottu: tell AtomicSpark about getting a hobby
[07:32] <Madpilot> tonyyarusso, the trouble is he thinks he has one...
[07:35] <rww> the hobby is us :(
[12:42] <bazhang> sniffle seems less than helpful
[16:03] <bazhang> cdbs, you may be confusing apt with aptitude
[16:03] <cdbs> bazhang: I am not
[16:03] <cdbs> bazhang: check out the man page, please
[16:03] <bazhang> he's on 8.04
[16:03] <bazhang> no need
[16:05] <cdbs> bazhang: I hope I was clear
[16:05] <cdbs> bazhang: the manpage clearly states the difference between apt-get upgrade and apt-get install
[16:05] <bazhang> nope
[16:05] <cdbs> bazhang: Look at it PLEASE!
[16:05] <bazhang> 8.04 does not have that version
[16:06] <cdbs> bazhang: he's using 10.04, not 8.04
[16:07] <cdbs> okay, I g2g, bye
 Oh I'm wrong I'm in 8.04 server
 Any ideas about how can I get apt-get 0.8.1 running
[16:10] <bazhang>  info apt hardy
 apt (source: apt): Advanced front-end for dpkg. In component main, is important. Version 0.7.9ubuntu17.2 (hardy), package size 1612 kB, installed size 5200 kB
[17:44] <bazhang> ikonia, actually most torrent client support magnet links such as transmission
[17:44] <ikonia> really, documetnation must be old, does ktorrent support it ?
[17:44] <bazhang> not sure, not used it in ages
[17:45] <ikonia> it does from ktorrent 4
[17:45] <bazhang> http://ktorrent.org/wiki/index.php/FAQ#Does_KTorrent_support_magnet_links.3F yep since 4.0
[17:45] <bazhang> heh
[18:18] <ikonia> @mark #ubuntu UBXUER use of bad language and a real name of "Fucking Jew Face"
[23:55] <bazhang> is it wrong to wonder what laptop he was going to toss?


[01:29] <lifeless> StevenK: auditor has no buildout now ?
[02:33] <nigelb> I just discovered an old branch I was working on , on this laptop.
[02:33] <nigelb> I wonder if I can finish it. Hrm.
[02:35] <StevenK> lifeless: auditor itself is not buildout enabled, no.
[02:37] <StevenK> lifeless: Actually, what do you mean 'now'? auditor never had buildout.
[03:30] <LPCIBot> Project devel build #1099: STILL FAILING in 1 min 23 sec: https://lpci.wedontsleep.org/job/devel/1099/
[03:34] <LPCIBot> Yippie, build fixed!
[03:34] <LPCIBot> Project devel build #1100: FIXED in 3 min 26 sec: https://lpci.wedontsleep.org/job/devel/1100/
[03:35] <StevenK> Jenkins, you lying scoundrel
[03:37] <rick_h_> never trust it :P
[03:42] <StevenK> rick_h_: Hmph.
[03:44] <StevenK> Right, build 1101 is off and looking good, so time for some DEHR
[04:50] <lifeless> StevenK: I assumed it would
[04:50] <lifeless> StevenK: as its what we use for deploys
[04:50] <StevenK> lifeless: No, that's production-auditor
[05:07] <lifeless> wgrant: you were doing something about       263 /    0  POFile:+translate
[05:07] <lifeless>  were you not ?
[05:07] <LPCIBot> Project devel build #1101: FAILURE in 1 hr 29 min: https://lpci.wedontsleep.org/job/devel/1101/
[05:09] <wgrant> lifeless: It's a terrible page in general, it's not just the query that I was looking at. But I eventually established that we probably can't optimise that query significantly without changing to something sensible like FTI, rather than substring matching.
[05:10] <wgrant> (but that has obvious problems, given all the languages)
[05:13] <lifeless> bllllar, pypi login is very odd
[05:13] <lifeless> it had basic creds
[05:13] <lifeless> so knew who I was
[05:13] <lifeless> but wasn't showing my logged in
[05:13] <lifeless> s/my/me/
[05:13] <lifeless> click on 'login' and it changed to logged in.
[05:14] <lifeless> ahhaha
[05:14] <lifeless> http://pypi.python.org/pypi/Ojota/0.4.2
[05:14] <lifeless> ' License: LICENSE.txt '
[05:15] <lifeless> I am filled with confidence
[05:20] <lifeless> linear operation dispatch
[05:20] <lifeless> sigh, they need mentoring.
[05:29] <lifeless> bah, codus interruptus. I will try to get back to this later.
[05:55] <StevenK> Neat, concurrency 4 is 30 minutes quicker.
[05:56] <StevenK> lifeless: https://lpci.wedontsleep.org/job/devel/lastBuild/ has your build artifacts
[06:48] <tumbleweed> wgrant: https://code.launchpad.net/~stefanor/launchpad/packageset-destructor/+merge/127167 dropped the export_operation_as. Care to land it?
[06:49] <wgrant> tumbleweed: Sure
[06:49] <wgrant> Thanks
[06:49] <tumbleweed> btw, that export_operation_as was there because I saw it in some other places. Should they be cleaned up?
[06:50] <wgrant> Hm, which other places? export_destructor_operation has only been around for a couple of years, so some may have been incorrectly ported.
[06:50] <tumbleweed> ack-grep says lib/lp/blueprints/interfaces/specificationbranch.py lib/lp/registry/interfaces/milestone.py
[06:50] <tumbleweed> oh, and lib/lp/registry/interfaces/productrelease.py
[06:51] <wgrant> Hmm
[06:51] <wgrant> Those are possibly relevant to old versions of the API
[06:55] <wgrant> tumbleweed: Can you set a commit message?
[06:56] <tumbleweed> wgrant: done
[06:59] <wgrant> tumbleweed: Thanks. That's landed.
[07:02] <tumbleweed> thank you :)
[07:43] <adeuring> good mmorning
[07:55] <lifeless> ok
[07:55] <lifeless> so why does django test discovery not look in submodules
[07:55] <czajkowski> adeuring: ello ello
[08:03] <StevenK> lifeless: Can haz another peek at jenkins?
[08:23] <wgrant> tumbleweed: The destructor change is through buildbot, and should be in the next production deployment.
[08:28] <tumbleweed> yup, got an e-mail, thanks
[08:33] <lifeless> StevenK: remind me tomorrow, its late and i've been kicking django basics around
[13:31] <deryck> adeuring, abentley -- hey, having trouble connecting to the hangout.  still trying to get in...
[13:31] <abentley> deryck: ack.
[14:42] <sinzui> My house is full of plague. I an not getting our of jim-jams today
[14:44]  * czajkowski passes a hot whiskey to sinzui
[14:44] <sinzui> I please no
[14:44] <sinzui> I don't think it will stay down
[14:45] <sinzui> I am trying not to ingest
[14:45] <czajkowski> sinzui: any reason why a person cant sign the CoC with a subkey not their primary key ?
[14:45] <sinzui> czajkowski, very good reasons
[14:46] <czajkowski> mind telling them to the chat in -lp please :)
[14:46] <czajkowski> *chap
[14:46] <sinzui> czajkowski, Last week we downgraded gpg on several of our servers because an unneeded security fix for dpkg was applied.
[14:46] <czajkowski> sinzui: https://bugs.launchpad.net/launchpad/+bug/1053568/comments/4  <-- that
[14:46] <_mup_> Bug #1053568: PPA uploads signed with subkeys silently fail <gpg> <soyuz-upload> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/1053568 >
[14:46] <sinzui> czajkowski, We downgraded the machines we knew of.
[14:47] <sinzui> czajkowski, right
[14:47] <czajkowski> ah so I was right
[14:47] <sinzui> if the problem returned, we need to ask if webops applied the security fix again...out machines were not affected by the issue
[14:48] <cjwatson> security fix to gnupg, wasn't it, not dpkg?
[14:48] <cjwatson> https://launchpad.net/ubuntu/+source/gnupg/1.4.10-2ubuntu1.1
[14:50] <sinzui> cjwatson, yes
[15:27] <deryck> abentley, adeuring -- do you guys expect any db patches this week, beyond my patch for Product.information_type?
[15:28] <adeuring> deryck: can't think of any right now
[15:28] <deryck> adeuring, ack, thanks
[15:29] <abentley> deryck, adeuring: Are we going to need to extend AccessArtifact to support Products?
[15:29] <adeuring> abentley, deryck: can't we use simply policy grants?
[15:30] <deryck> yeah, I was under the impression from adeuring that this was a little simpler for products and didn't require AccessArtifact.
[15:30] <abentley> adeuring: Yes, I think that makes sense.
[15:31] <adeuring> after all, policy grangts already give access to branches, bugs, specs, so its "natural" to extend this to give access to the pillar/product itself
[15:45] <deryck> adeuring, but no new db patches needed, though, right?
[15:45] <adeuring> deryck: right, i think we don't need any.
[15:46] <deryck> awesome.
[15:46] <deryck> trying to coordinate since webops are sprinting.
[17:20] <cjohnston> deryck[lunch]: ping when you get back
[18:05] <deryck> hi cjohnston. have a call now, but I can ping after that.
[18:33] <cjohnston> ok deryck
[19:00] <deryck> cjohnston, hey. Free now.  What's up?
[19:01] <cjohnston> deryck: I want to make sure I understand.. So as Summit is not authenticated, it will not see any private BPs that are proposed to the UDS sprint?
[19:02] <deryck> cjohnston, correct.
[19:03] <cjohnston> Ok.. so your comments confuse me a little.. If Summit doesn't have the ability to see it, is there a reason for the ability for a BP to be proposed to a sprint to exist?
[19:04] <cjohnston> otherwise it still seems like a confusing UI as I propose my blueprint to a UDS sprint, I assume that more than likely the people who approve blueprints for the sprint can't see the blueprint to approve it for the sprint, even if they can, Summit can't see the blueprint to create the (private) meeting
[19:06] <cjohnston> So either the functionality needs to be extended to work correctly, or removed from private BPs, IMO
[19:06] <deryck> cjohnston, what do you call "correctly?"  What needs to happen to be correct?
[19:07] <cjohnston> Where if a blueprint is proposed to a sprint, a 'sprint manager' can approve the blueprint for the sprint, and Summit sees the approved blueprint and creates a (private) meeting for the blueprint
[19:09] <cjohnston> Otherwise it doesn't perform as expected
[19:09] <cjohnston> by the user, based on how other blueprints perform
[19:10] <deryck> The point about the sprint manager not being able to see it is a good point.  I'm not sure its a bug or not yet.  I need to think through that case.
[19:10] <cjohnston> but even still, if the sprint manager could see it, Summit couldnt
[19:10] <deryck> As for summit, that's different.  it's an add-on bit to launchpad.  so I don't think we want to automatically trust anonymous bots.
[19:11] <deryck> ah, ok, I guess I don't understand how summit gets access.
[19:11] <deryck> I thought it was anonymous API script, based on what you said earlier.
[19:12] <cjohnston> 1 sec... trying to find the link
[19:13] <cjohnston> https://launchpad.net/sprints/uds-r/+temp-meeting-export
[19:14] <deryck> cjohnston, ok, so I think it's good to chat and work out any kinks here, but I don't think this anything we're going to change on our end before UDS….
[19:14] <deryck> cjohnston, the people who will be bitten by this are a small group....
[19:15] <cjohnston> well.. the new stuff is only in beta currently correct?
[19:15] <deryck> cjohnston, only people who are both lp beta testers and have commercial subscriptions for lp…..
[19:15] <cjohnston> oddly enough I actually fall into it.. hehe
[19:15] <deryck> fair point :)
[19:16] <cjohnston> but yes.. it is a small group, and for this UDS I think we are ok.. but I'd like to have it correct before we start the planning for the next UDS when all of this is live
[19:16] <deryck> cjohnston, so people who do fall in that, need to be careful about using private blueprints linked to UDS.
[19:16] <cjohnston> so somehow we would have to get that info out to them
[19:17] <deryck> as to the larger point, everything private in lp works the way blueprints do now.  If it's proprietary, then no one gets access accept those people explicitly given access.  I don't think we should change this.
[19:17] <deryck> maybe that means that proprietary blueprints shouldn't be able to be linked to a sprint.
[19:17] <deryck> I'm not sure agree, but its a fair point to argue.
[19:17] <cjohnston> That's my thought.. or that if they are, then everything else needs to be changed to accomidate the fact that they can link it
[19:18] <cjohnston> otherwise it gets stuck in some foriegn world
[19:18] <deryck> well, no, it's private.  As they the word "private" implies. :)
[19:19] <cjohnston> correct.. its private.. but they propose it to a sprint, but it never makes it onto the schedule
[19:19] <cjohnston> thats where the problem as I see it lies
[19:19] <deryck> are sprints proposed, or just purely linked to the sprint object?
[19:20] <deryck> I assumed it was a straight link, but if it is an proposed relationship that can never be approved or rejected, then yes, that's a clear bug.
[19:20] <cjohnston> I don't understand the question? A sprint itself is created, and a BP is proposed against a sprint
[19:22] <deryck> ok, so I just checked.  You get the link on your blueprint, but it's not listed without approval.
[19:23] <deryck> so you have kind of an unofficial link to a sprint
[19:24] <cjohnston> so how would it get approved
[19:24] <deryck> it wouldn't.  but why is that bad if it's a private object?
[19:25] <cjohnston> then it shouldn't be able to be proposed.. what is the point of proposing a blueprint to a sprint if you cant get the blueprint approved for the sprint?
[19:26] <deryck> I don't know.  It's hypothetical, sure.  I don't know that anyone wants this relationship.  But I imagine someone *could* be working on something private while at UDS, and like the link to the sprint to see to establish the relationship, i.e. as a point of navigation to the sprint for other stuff.
[19:26] <deryck> I don't know this, I'm just speculating.
[19:26] <deryck> But without talking to people who might use this, we can never know.
[19:28] <cjohnston> I guess to me, I would rather that if the feature not work the same as it works for everything else, it shouldn't exist. I am not opposed to making it possible to propose a private bp, get it approved (somehow?), we want to make summit authenticate anyway, so then we could create a private meeting (a feature that already exists in Summit) based upon a private blueprint
[19:28] <deryck> if people's expectations are that proposing would open this to approval, but not reveal the object otherwise, we could make that possible.
[19:29] <deryck> Though personally, I don't know that an approved, but hidden blueprint, is anymore valuable that an unapproved and hidden one.
[19:29] <deryck> but sure, if this was tied into the functionality to great private meetings that would be nice.
[19:29] <cjohnston> approved would allow (as long as Summit can get the info that it needs) for the blueprint to make it on the meeting schedule
[19:29] <cjohnston> as a private meeting
[19:29] <deryck> right.  which is a fair point.
[19:30] <deryck> but we don't have capacity to do all that extra work.
[19:30] <deryck> someone else will need to build on what we've done.
[19:30] <deryck> I'm not sure it's so broken that we need to remove the ability to link to the sprint at this point, but I'm open for arguments, obviously.
[19:30] <cjohnston> then IMO, it's a bug currently that you can propose a private blueprint to a sprint but not allow it to get on the schedule.
[19:31] <cjohnston> how hard would it be to add if bp=private hide sprint stuff
[19:32] <deryck> cjohnston, not that hard, but it is some work, and I'm not convinced we need to do it.  let's just see what happens at this UDS.
[19:34] <cjohnston> I'm not sure that this UDS is a good test as, as you said, its beta and required to be a member of one of these projects
[19:43] <lifeless> flacoste: hi; can we push the meeting back a bit ?
[19:45] <lifeless> deryck: cjohnston: I don't think being linked is a bug per se: the lack of reciprocal disclosure is (the rule is, if you link something private with something less private, the private thing becomes visible to the same degree)
[19:46] <cjohnston> so then it would become a publicly viewable blueprint?
[19:46] <lifeless> deryck: cjohnston: But for proprietary we want to prevent people making such links outside the things that the project owner controls, so that bug #2.
[19:46] <lifeless> deryck: cjohnston: as for summit, +temp-meeting-export should DIAF and be replaced by an API call, and the API call can be authenticated by the bot, just have the summit bot be granted access to the relevant private project blueprints/bugs through access policy grants.
[19:47] <deryck> this is what I was thinking, when I thought it was a bot.  just grant access to the bot for the blueprints you want scheduled.
[19:47] <cjohnston> lifeless: we aren't against that.. does the API stuff already exist to do that?
[19:48] <lifeless> cjohnston: you wouldn't want the spider approach the current API has for this
[19:48] <lifeless> cjohnston: you'd want to literally port the meeting export code to a single API call (e.g. sprint.export())
[19:48] <lifeless> deryck: yeah, +1.
[19:49] <deryck> lifeless, also, I'm not sure that I agree with the rile that the thing should gain the visibility of the thing linked, but if we've been consistent with that, I'll abide by the rule. :)
[19:49] <lifeless> The thing that will bite you though, is the idea of linking proprietary blueprints to public sprints either needs to violate the rule for interaction of objects, or needs to disclose the existence of the blueprint and the project.
[19:49] <deryck> right
[19:50] <lifeless> deryck: we're trying to be consistent with it, because it makes reasoning about UI and behaviour a /lot/ easier.
[19:50] <lifeless> deryck: for all that it raises issues, it would have avoided disasters too - like the public/private bug dupe one.
[19:50] <cjohnston> if everything was authed, summit could gather the info, and keep the info private in Summit, if the ability existed in LP, though it sounds like it doesnt
[19:51] <lifeless> the sort of thing that this rule solves is:
[19:51] <lifeless>  - invisible actions
[19:51] <lifeless>  - spying
[19:51] <lifeless>  - inexplicable failures (e.g. timeslot X is used. Not its not! yes it is!)
[19:51] <deryck> I don't disagree it solves all those issues.  But it's also very easy to leak private data.  And I'm not sure which is worse.
[19:52] <deryck> but I know we've had all these discussions before.  I'm not trying to dredge them back up.
[19:52] <deryck> not we == lifeless/deryck but we == lp devs.
[19:52] <lifeless> yeah :)
[19:52] <flacoste> lifeless: i need to head off in a little less than 1h, maybe we would be better to postone to later in the week then?
[19:54] <lifeless> flacoste: ok, tomorrow?
[19:54] <lifeless> flacoste: or your wed, can't do later than that, on leave.
[19:54] <flacoste> lifeless: yeah, let's do wed after the TL call
[19:55] <lifeless> hokaydokay
[20:57] <cjwatson> wgrant: Do you think https://bugs.launchpad.net/launchpad/+bug/3456 is still an issue?  (The bug title is outdated; read at least comment #1.)
[20:57] <_mup_> Bug #3456: queue doctest removes security proxies <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/3456 >
[20:58] <cjwatson> I thought it was acceptable that the uploader was zopeless, though perhaps I'm wrong.
[21:22] <wgrant> cjwatson: Not worth having a bug for
[22:09] <StevenK> lifeless: https://lpci.wedontsleep.org/job/devel/lastFailedBuild/ hint hint
[22:14] <lifeless> grrr at your cert
[22:15] <StevenK> Yeah, sorry, I should fix that.
[22:37] <lifeless> StevenK: its got crud in it:
[22:37] <lifeless> successful: lp.services.scripts.tests.test_cronscript_enabled.TestCronscriptEnabled.test_enabled_cronscript
[22:37] <lifeless> teskill: 186: No such process
[22:37] <lifeless> Stopping lxc
[22:37] <lifeless> t: lp.codehosting.vfs.tests.test_branchfs.TestLaunchpadTransportAsync.test_rmdir
[22:37] <lifeless> see how test: lp.codehosting.vfs.tests.test_branchfs.TestLaunchpadTransportAsync.test_rmdir
[22:37] <lifeless> and kill: 186: No such process\nStopping lxc
[22:37] <lifeless> are intermingled
[22:38] <StevenK> lifeless: Hmm, maybe I need to redirect stderr away?
[22:38] <sinzui> wgrant, StevenK, wallyworld: can you see http://blog.launchpad.net/?p=3742&preview=true
[22:38] <lifeless> StevenK: stderr /must/ be a separate fd, is it shared with stdout atm ?
[22:38] <StevenK> lifeless: At the moment, I'm not redirecting them at all
[22:42] <lifeless> StevenK: can i see the config ?
[22:44] <StevenK> lifeless: Jenkins config, builder config? Which?
[22:45] <lifeless>  yes
[22:45] <lifeless> the jenkins project config
[22:45] <lifeless> to start with
[22:45] <lifeless> brb
[22:49] <StevenK> lifeless: You should have access to configure the project on jenkins
[23:11] <StevenK> wgrant: My test in the LP branch passes with the new lazr.restful hacked in.
[23:12] <lifeless> StevenK: I don't have a login ?
[23:13] <StevenK> lifeless: Login via SSO
[23:13] <StevenK> That should work
[23:15] <wgrant> StevenK: Great
[23:15] <lifeless> StevenK: did you just change to concurrency=1 ?
[23:15] <StevenK> Yes, wgrant's suggestion.
[23:17] <lifeless> ok, so sudo /usr/local/bin/lp-setup-lxc-test lptests
[23:17] <lifeless> is buggy
[23:17] <lifeless> bbs, C need sme
[23:18] <StevenK> lifeless: That is based on the example shipped in lpsetup. I can pastebin it if you wish
[23:24] <StevenK> wgrant, wallyworld: https://code.launchpad.net/~stevenk/lazr.restful/dict-unmarshaller-none/+merge/126615
[23:29] <StevenK> wgrant: Do you think the test I've added is valuable?
[23:31] <wgrant> StevenK: Hm
[23:31] <wgrant> StevenK: Don't we care mostly about marshalling?
[23:31] <wgrant> Unmarshalling might be useful too, but it's less important here.
[23:31] <wgrant> The bug you're trying to fix just cares about marshalling.
[23:32] <StevenK> No, the bug I'm fixing is about unmarshalling
[23:32] <StevenK> It gets None and tries to unmarshall that as a dict
[23:33] <StevenK> wgrant: And sorry, I meant the LP test, not the lazr.restful test.
[23:33] <wgrant> Ah, in the etag, right
[23:33] <wgrant> StevenK: Does that test fail without the lazr.restful upgrade?
[23:34] <wgrant> It doesn't look like it'll exercise the ETag path.
[23:34] <wgrant> Because it's unconditional.
[23:41] <StevenK> wgrant: http://pastebin.ubuntu.com/1255044/
[23:42] <wgrant> Ah, so it does a conditional anyway, great.
[23:45]  * wallyworld sighs, another hard lockup :-(
[23:45] <StevenK> wgrant: So it's fine?
[23:46] <wgrant> StevenK: yes
[23:47] <StevenK> wgrant: Can you approve the lazr.restful MP then so I can land it?
[23:48] <StevenK> wgrant: If you think the test I've added to LP adds value, I can leave it in, or I can just bump versions.cfg and move on.
[23:55] <wgrant> StevenK: Does marshalling None as a dict work?
[23:57] <StevenK> wgrant: Obviously, due to the lazr.restful test
[23:57] <wgrant> StevenK: That tests *un*marshalling.
[23:58] <StevenK> Yeah, I should learn to read at some point.
[23:58] <StevenK> Let me check.
[23:59] <StevenK>     >>> print dict_marshaller.marshall_from_json_data(None)
[23:59] <StevenK>     None
[23:59] <StevenK> There's an existing test


[14:25] <smartboyhw> What meetings are here today? The calendar's changed to pm. s, so I now were confused.
[15:58] <jamespage> o/
[15:59] <hallyn> \o
[16:00]  * hallyn waits for a few more waves before starting
[16:01] <adam_g> o/
[16:01] <jimbaker> hi everyone
[16:01] <hallyn> good morning :)
[16:01] <hallyn> ooh we have utlemming too
[16:01] <hallyn> all right then i'll start
[16:01] <hallyn> #startmeeting
[16:01] <meetingology> Meeting started Tue Aug  7 16:01:55 2012 UTC.  The chair is hallyn. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:02] <hallyn> #topic Review ACTION points from previous meeting
[16:02] <hallyn> none
[16:02] <hallyn> #topic Quantal Development
[16:02] <hallyn> jamespage: over to you :)
[16:02] <jamespage> ta
[16:02] <jamespage> http://status.ubuntu.com/ubuntu-quantal/ubuntu-server.html
[16:02] <jamespage> #link http://status.ubuntu.com/ubuntu-quantal/ubuntu-server.html
[16:02] <hallyn> #link http://status.ubuntu.com/ubuntu-quantal/ubuntu-server.html
[16:03] <hallyn> hm
[16:03] <jamespage> I had a review earlier today - a few to focus in on
[16:03] <jamespage> utlemming,
[16:03] <jamespage> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-cloud-images
[16:03] <jamespage> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-awstools
[16:03] <jamespage> just a checkin to make sure you are comfortable/on track with those two
[16:04] <utlemming> yeah, one of the first, the motu's don'
[16:04] <jamespage> smoser, utlemming:
[16:04] <jamespage> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-cloud-init-utils
[16:04] <utlemming> want everything in debian, and there is a freeze in place
[16:05] <jamespage> utlemming, I'm sure kamal can get some new packages into unstable for you :-)
[16:05] <utlemming> on the cloud-image roundtable, that should be okay
[16:05] <smoser> jamespage, well, they're clearly behind and i'm sure some things will be postponed.
[16:06] <jamespage> Ursinha:
[16:06] <jamespage> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-bug-triage-review
[16:06] <jamespage> we still need to catchup on that one - are you going to have some time for report updates etc?
[16:07] <jamespage> m_3, jimbaker:
[16:07] <jamespage> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-charm-unit-tests
[16:07] <jamespage> lots of stuff in progress - all OK?
[16:07] <jimbaker> jamespage, yes, we should be getting this connected up this week
[16:07] <Ursinha> jamespage, I've been working on reports, I need to catch up with you later
[16:07] <jamespage> jimbaker, great!
[16:08] <jamespage> Ursinha, fantastic
[16:08] <jamespage> sounds like things are moving along
[16:08] <jimbaker> i have the first goaround in terms of running manually with a nice DSL in bash
[16:08] <jimbaker> then hook up to m_3's charmtester charm
[16:08] <jamespage> remember feature freeze is on the 23 august (~2 weeks) - so any new stuff targetting main ideally needs to be in archive by then
[16:09] <jamespage> otherwise you have to beg for feature freeze exceptions....
[16:09] <jimbaker> jamespage, that's been my fate in the past on the juju project :)
[16:09] <jimbaker> but time to squeeze it all in!
[16:09] <jamespage> \o/ - great
[16:10] <jamespage> so keep on updating blueprints as you complete stuff - helps keep overall track on progress
[16:10] <jamespage> so - http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html
[16:10] <jamespage> #link http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html
[16:10] <jamespage> hallyn, bot does not like me for some reason
[16:10] <jimbaker> jamespage, cool, m_3 and i were discussing this very stuff yesterday re blueprint updating
[16:10] <hallyn> jamespage: link didn't work for me either
[16:11] <hallyn> #LINK http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html
[16:11] <hallyn> [LINK] http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html

[16:11] <jamespage> OK - so zul and adam_g have a few bugs in quantum and horizon in hand
[16:11] <zul> to say the least
[16:11] <hallyn> uh, MIR for netcf is not on the list
[16:11] <jamespage> we still need a volunteer to look at bug 844995
[16:12] <jamespage> any takers?
[16:13] <jamespage> (I'll sponsor it if someone wanted to have a first stab at some packaging updates...)
[16:13] <jamespage> hallyn, netcf - I'll need to subscribe ubuntu-server to the package for bugs - then it will appear
[16:13] <jamespage> looks like we have *alot* of MIR's in flight
[16:13] <hallyn> jamespage: great, thanks
[16:14] <jamespage> hallyn, done
[16:14] <hallyn> \o/  we'll wnat that anyway
[16:15] <jamespage> if you are raising MIR's please can you set a priority on the bug reports; at a minimum it helps prioritize focus for the MIR team
[16:15] <jamespage> should probably reflect the priority of the associated blueprint - remember you can link bugs to blueprints as well so they can be tracked on status.ubuntu.com
[16:16] <jamespage> any other quantal dev stuff anyone wants to raise?
[16:17] <hallyn> (i'll wait until smb's section :)
[16:17] <jamespage> hallyn, I think thats me done then
[16:17] <hallyn> thanks!
[16:17]  * smb shudders
[16:17] <hallyn> #topic 12.04.1 Development (jamespage & smoser)
[16:17] <hallyn> uh, and straight back to you? :)
[16:17] <jamespage> unless smoser wants the spot :-)
[16:17] <hallyn> smoser: \o
[16:17] <smoser> hey
[16:18] <smoser> so. basically the target for 12.04.1 is thursday
[16:18] <rbasak> o/
[16:18] <smoser> if you're not going to have something in by then, then you should really consider it not in for 12.04.1 and retarget anything to -updates.
[16:18] <smoser> thats my general comment
[16:18] <hallyn> and http://people.canonical.com/~jamespage/server-sru/precise-sru.html is the definitive list?
[16:18] <jamespage> yeah - thats a good source
[16:19]  * jamespage must get the integrated somewhere more formal
[16:19] <smoser> do you have anything specific, jamespage ?
[16:19] <jamespage> we need to nudge walinuxagent forwards but aside from that I think we are in an OK place
[16:21] <hallyn> moving along then,
[16:21] <hallyn> #topic Ubuntu Server Team Events
[16:21] <hallyn> i assume quite a few people going to plumber's and associated events?
[16:22] <hallyn> or not :)
[16:22] <hallyn> any other events to mention?
[16:22] <hallyn> moving along,
[16:22] <hallyn> #topic Weekly Updates & Questions for the QA Team (hggdh)
[16:22] <hallyn> hey hggdh
[16:23] <smoser> hallyn, are you going to plumbers?
[16:23] <hallyn> smoser: i am not :(
[16:23]  * smb is
[16:24] <hallyn> no hggdh , moving along
[16:24] <hallyn> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:24] <hallyn> hey smb
[16:24] <smb> hey hallyn
[16:24] <smb> So wassup?
[16:24] <jimbaker> i am presenting juju at 3 separate events around boulder in the next 3 months: boulder lug, big data meetup (focused on zookeeper and how we use it, along w/ hadoop, etc), and the national center for atmospheric research
[16:24] <hallyn> my q was on bug 1031090
[16:24] <smb> Not much to bring up specifically. The failure to load the kvm intel module is in progress. The upstream discussion is/was mostly on how/where to fix it (the right way). But rather will need to go into precise.
[16:24] <hallyn> is the fix for that known, or are you just saying "when someone whips up a fix we'll take it"?
[16:25] <hallyn> but precise is on 3.2 i thought?
[16:25]  * smb notes he was about to say something about tit
[16:25] <smb> hallyn, Right, the problem is that loading the modules checks a msr for a feature which any real cpu would have
[16:25] <hallyn> (jimbaker is a travelin' fool)
[16:25] <hallyn> smb: right but i thought one comment said it was introduced in 3.3
[16:25] <smb> but the older kvm modules did not set it for the nested case
[16:26] <smb> hallyn, Introduced yes as in adding the support for that feature
[16:26] <smb> but upstream thinks rather than handling the non-presence (which should not happen) in newer coder
[16:26] <smb> *code
[16:26] <hallyn> ah
[16:26] <smb> the old code should add it
[16:27] <smb> And I think 3.2 is about the only kernel that supports nesting and misses it
[16:27] <hallyn> we were never at war with eurasia, and that bug was never there
[16:27] <smb> Could be wrong though, then it needs backport to before
[16:28] <hallyn> smb: if we were to add itot the old code, is it simple to do?  should we just do it to hit 12.04.1?
[16:28] <hallyn> eh, let's discuss in -server after the meeting?
[16:28] <smb> hallyn, ok, it would be simplish (hopefully safe)
[16:28] <hallyn> great, thanks
[16:28] <smb> hallyn, but yeah, lets move this on
[16:28] <hallyn> any other questions for smb?
[16:29] <hallyn> from smb? :)
[16:29] <smb> nothing mmore
[16:29] <hallyn> thanks smb.  moving on,
[16:29] <hallyn> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:29] <rbasak> Nothing to report. Any questions for me?
[16:30] <jimbaker> rbasak, i assume good outcome of the java mtg i missed when i was on vac?
[16:30] <rbasak> Yeah I think so
[16:30]  * rbasak tries to remember
[16:30] <rbasak> I think jamespage was more involved in that than I was
[16:30] <jamespage> jimbaker, ok-ish
[16:31] <jimbaker> no worries, i *might* have some insight on any java issues
[16:31] <jamespage> still no java 7 JVM implementation - soon!
[16:32] <hallyn> moving on?
[16:32] <jimbaker> so there are good results posted on the openjdk for java 7 on arm. anyway, i'll need to get onto arm hw soon enough for the testing doing w/ m_3
[16:32] <jimbaker> so look then too
[16:33] <hallyn> any bounds on 'soon enough'?
[16:34] <jamespage> hallyn, not really - it has focus upstream but the invoke-dynamic stuff is proving complex to implement
[16:34] <hallyn> ok
[16:34] <hallyn> #topic Open Discussion
[16:35] <jamespage> I have one for next week - I invited gema from the QA team to come and give us an overview of whats happing in QA this cycle
[16:35] <hallyn> cool
[16:35] <jamespage> specifically the new testing framework (UTAH) and how we can get more involved with test cases etc...
[16:36] <hallyn> yup, i still need to do that for lxc testcases
[16:36] <hallyn> (this might nudge me along)
[16:36] <hallyn> anything else?
[16:36] <hallyn> going twice,
[16:36] <hallyn> #topic Announce next meeting date and time
[16:37] <hallyn> Tuesday Aug 14, same time as always
[16:37] <hallyn> thanks everyone
[16:37] <hallyn> #endmeeting
[16:37] <meetingology> Meeting ended Tue Aug  7 16:37:24 2012 UTC.
[16:37] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-07-16.01.moin.txt
[16:37] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-07-16.01.html
[16:37] <jamespage> thanks hallyn
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Aug  7 17:00:11 2012 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Quantal
[17:00] <ppisati> o/
[17:00] <henrix> o/
[17:00] <kamal> o/
[17:00] <herton> o/
[17:00] <sforshee> o/
[17:00] <smb> \o
[17:00] <apw> o/
[17:01] <ogasawara> o/
[17:01] <sconklin> \o
[17:01] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:01] <ppisati> Q/omap4: porting of tilt-3.4 [1] on top of Q 3.5 master continues.
[17:01] <ppisati> The resulting kernel is available here: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-quantal.git;a=shortlog;h=refs/heads/ti-omap4-tilt-34-on-35
[17:01] <ppisati> The entire patchset is available at http://people.canonical.com/~ppisati/ti-omap4-tilt-34-on-35/tilt-3.4/
[17:01] <ppisati> The "done" directory contains the patches i already ported(1054), "skipped" contains the patches left for later evaluation(29) and "already" contains the patches found upstream(59) - so far 1142 out of 1708 patches were handled, work is progressing nicely.
[17:01] <ppisati> [1]: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-3.4
[17:01] <ppisati> ..
[17:01] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:02] <ogasawara> ogra_: ^^ just fyi, see ppisati's status
[17:02] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:02]  * ogra_ hugs ppisati
[17:02] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team-ubuntu-12.10-beta-1.html
[17:02] <ogra_> (and ogasawara )
[17:02] <ogasawara> || apw         || hardware-q-kernel-config-review || 3 work item  ||
[17:02] <ogasawara> ||             || hardware-q-kernel-delta-review  || 4 work items ||
[17:02] <ogasawara> ||             || hardware-q-kernel-misc          || 1 work item  ||
[17:02] <ogasawara> ||             || hardware-q-kernel-versions-and-flavors || 1 work item ||
[17:02] <ogasawara> ||             || desktop-q-clean-old-kernels     || 1 work item ||
[17:02] <ogasawara> || bjf         || hardware-q-kernel-misc          || 1 work item  ||
[17:02] <ogasawara> || cking       || hardware-q-kernel-misc          || 1 work item  ||
[17:02] <ogasawara> || ogasawara   || hardware-q-kernel-misc          || 4 work items ||
[17:02] <ogasawara> || tgardner    || hardware-q-kernel-misc          || 1 work item  ||
[17:02] <ogasawara> If your name is in the above table, please review your Beta-1 work items.
[17:02] <ogasawara> ..
[17:03] <jsalisbury> [TOPIC] Status: Quantal Development Kernel (ogasawara)
[17:03] <ogasawara> We've recently uploaded the 3.5.0-8.8 Quantal kernel to the release
[17:03] <ogasawara> pocket. This upload includes misc bug fixes, upstream feature enablement
[17:03] <ogasawara> for Intel HW, and a sync of AUFS (even though we plan to keep it
[17:03] <ogasawara> disabled atm).  This was also uploaded to the q-lts-backport [1] PPA to
[17:03] <ogasawara> help facilitate testing of the 12.10 kernel in 12.04.  We welcome anyone
[17:03] <ogasawara> to please install, test, and let us know your feedback.
[17:03] <ogasawara> [1] https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[17:03] <ogasawara> Important upcoming dates:
[17:03] <ogasawara>  * Thurs Aug 30 - Beta 1 (~3 weeks)
[17:03] <ogasawara> ..
[17:03] <jsalisbury> [TOPIC] Status: CVE's (sconklin)
[17:03] <sconklin> == 2012-08-07 (weekly) ==
[17:03] <sconklin> Currently we have 96 CVEs on our radar, with one CVE retired this week.
[17:03] <sconklin> See the CVE matrix for the current list:
[17:03] <sconklin> [LINK] http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:03] <sconklin> Overall the backlog has decreased slightly this week:
[17:03] <sconklin> [LINK] http://people.canonical.com/~kernel/status/cve-metrics.txt
[17:03] <sconklin> [LINK] http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt
[17:03] <sconklin> ..
[17:04] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Precise/Oneiric/Natty/Lucid/Hardy (bjf/herton/henrix)
[17:04] <henrix> Here is the status for the main kernels, until today (August 07):
[17:04] <henrix>
[17:04] <henrix>  * Hardy - Nothing in this cycle
[17:04] <henrix>  * Lucid - In Testing; 2 CVEs; (16 commits)
[17:04] <henrix>  * Natty - In Testing; 3 CVEs; (6 commits)
[17:04] <henrix>  * Oneiric - In Testing; 2 CVEs; 2 upstream stable release(s); (101 commits)
[17:04] <henrix>  * Precise - In Testing; 3 CVEs; 3 upstream stable release(s); (212 commits)
[17:04] <henrix>
[17:04] <henrix> Current opened tracking bugs details:
[17:04] <henrix>  * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:04] <henrix>
[17:04] <henrix> For SRUs, SRU report is a good source of information:
[17:04] <henrix>  * http://people.canonical.com/~kernel/reports/sru-report.html
[17:04] <henrix>
[17:04] <henrix> Future stable cadence cycles:
[17:04] <henrix>  * https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock
[17:04] <henrix>
[17:04] <henrix> The week of Sept. 6 is the week the last Natty kernel will be built.
[17:04] <henrix> ..
[17:05] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:05] <jsalisbury> Thanks everyone
[17:05] <jsalisbury> #endmeeting
[17:05] <meetingology> Meeting ended Tue Aug  7 17:05:25 2012 UTC.
[17:05] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-07-17.00.moin.txt
[17:05] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-08-07-17.00.html
[17:05] <kamal> thanks jsalisbury


[00:37] <David_Hedlund> The security entries in sources.list:
[00:37] <David_Hedlund> Ubuntu 23.04: deb http://archive.ubuntu.com/ubuntu lunar-security main restricted.
[00:37] <David_Hedlund> While Ubuntu 20.04, 22.04, 22.10: deb http://security.ubuntu.com/ubuntu <$VERSION_CODENAME> main restricted
[00:37] <David_Hedlund> http://security.ubuntu.com/ubuntu is a mirror of http://archive.ubuntu.com/ubuntu. So can I use "deb http://security.ubuntu.com/ubuntu <$VERSION_CODENAME> main restricted" for Ubuntu 20.04, 22.04, 22.10?
[00:39] <David_Hedlund> I meant: Can I replace "http://security.ubuntu.com/ubuntu" with http://archive.ubuntu.com/ubuntu" for Ubuntu 20.04, 22.04, 22.10?
[05:27] <David_Hedlund> How can I find out the earliest Ubuntu version that ubuntu-mate-core can be installed on?
[06:37] <David_Hedlund> Do you know how to purge ubuntu-mate but keep ubuntu-mate-core? sarnold
[06:44] <David_Hedlund> sarnold: This didn't work: sudo apt-mark hold ubuntu-desktop-minimal && sudo apt-get -y purge ubuntu-desktop && sudo apt-mark unhold ubuntu-desktop-minimal && apt autoremove
[06:44] <David_Hedlund> ubuntu-mate depends on ubuntu-mate-core so it should be possible to keep its packages instead of reinstalling it.


[13:01] <RedSoxFan07> Has anyone here been experiencing an issue where you log in and your panels don't show up until you switch in and out of the CLI (Ctrl+Alt+F2, Ctrl-Alt-F7)?
[13:12] <brainwash> RedSoxFan07: everything else is functional?
[13:12] <RedSoxFan07> brainwash: Yup.
[13:13] <brainwash> there could be something logged in .xsession-errors
[13:13] <RedSoxFan07> brainwash: Okay, cool. I'll check it out.
[13:13] <brainwash> is this a multi monitor setup?
[13:14] <RedSoxFan07> brainwash: Actually, no. I normally would, but I haven't done that with this system.
[13:14] <brainwash> ah ok
[13:14] <brainwash> multi monitor may have been the reason for why it fails
[13:21] <RedSoxFan07> brainwash: Oh, okay. I've just got one monitor hooked up to my GT 1030 via DVI.
[13:31] <RedSoxFan07> (xfce4-session:1878): xfce4-session-WARNING **: 08:36:44.930: xfsm_manager_load_session: Something wrong with /home/joshua/.cache/sessions/xfce4-session-joshua-OptiPlex-3020:0, Does it exist? Permissions issue?
[13:31] <RedSoxFan07> (xfwm4:1889): xfwm4-WARNING **: 08:36:45.661: Error waiting on vblank with DRI: Invalid argument
[13:32] <RedSoxFan07> (wrapper-2.0:1993): Gtk-WARNING **: 08:36:50.645: Negative content width -3 (allocation 1, extents 2x2) while allocating gadget (node button, owner GtkToggleButton)
[13:32] <RedSoxFan07> (xfce4-session:1878): xfce4-session-WARNING **: 08:38:01.348: ICE connection 0x562765496a00 rejected
[13:32] <RedSoxFan07> Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
[13:33] <RedSoxFan07> (Telegram:2431): libappindicator-CRITICAL **: app_indicator_set_icon_full: assertion 'IS_APP_INDICATOR (self)' failed
[13:33] <RedSoxFan07> propsReply "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.76\" (uid=1000 pid=2431 comm=\"Telegram -- \" label=\"snap.telegram-desktop.telegram-desktop (enforce)\") interface=\"org.freedesktop.DBus.Properties\" member=\"GetAll\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=804 comm=\"/usr/sbin/NetworkManager --no-daemon \"
[13:33] <RedSoxFan07> label=\"unconfined\")"
[13:33] <RedSoxFan07> nmReply "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.76\" (uid=1000 pid=2431 comm=\"Telegram -- \" label=\"snap.telegram-desktop.telegram-desktop (enforce)\") interface=\"org.freedesktop.NetworkManager\" member=\"GetDevices\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=804 comm=\"/usr/sbin/NetworkManager --no-daemon \"
[13:33] <RedSoxFan07> label=\"unconfined\")"
[13:33] <RedSoxFan07> "Object path cannot be empty"
[13:34] <brainwash> RedSoxFan07: please read the channel topic