[06:17] <nikolam> micahg, I have trouble using SM on 64bit lucid (bug with dying): It dies too often actually.
[06:18] <micahg> nikolam: yes, I'm not sure what to do as I don't have a quick fix, I need to get a patch upstream and have it approved
[06:19]  * micahg is trying to get openjdk to build before going to sleep, but that doesn't look promising
[08:14] <micahg> asac: friendly reminder for a Endorsement :)
[16:09] <chrisccoulson> hi jdstrand - i got all the extensions updated in jaunty on friday, so feel free to do some testing on jaunty if you like :)
[16:09] <chrisccoulson> i know that mozgest, stumbleupon and imagezoom currently don't work, but i'm fixing those now
[16:11] <jdstrand> chrisccoulson: cool, so now with the exception of those 3 are hardy - lucid ready? what about karmic/openjdk?
[16:11] <jdstrand> chrisccoulson: and hi! :)
[16:12] <chrisccoulson> jdstrand - i don't know if micahg made any progress with openjdk yet - i'll ask him when he's online
[16:14] <[reed]> do I want adobe-flashplugin or flashplayer-installer?
[16:14] <[reed]> they seem to be the same thing yet separate packages?
[16:15] <jdstrand> ultimately they are the same
[16:15] <[reed]> which one would you pick?
[16:15] <[reed]> :)
[16:15] <jdstrand> adobe-flashplugin is in the partner archive and the canonical partner guy works with adobe on it
[16:16] <jdstrand> flashplugin-installer's packaging is different, but is updated to pull down adobe's installer that is in the partner archive
[16:16] <jdstrand> I use adobe-flashplugin on i386 and flashplayer-installer on amd64
[16:17] <jdstrand> the former is only available on i386, and the latter uses nspluginwrapper, which is required to use the i386 plugin on amd64
[16:17]  * jdstrand wishes adobe would finish their amd64 version...
[16:24] <asac> jdstrand: afaik they said they will not finish amd64
[16:24]  * asac spreading rumours
[16:24] <asac> jdstrand: with OOPs we might just get nspluginwrapper for free in firefox anyway
[16:26] <jdstrand> I am not up on it, but I thought the last adobe said is that they were committed to it. though, how long have we heard that?
[16:28] <[reed]> asac: there's a mail to security-group@ from dveditz addressed to you
[16:28] <[reed]> has "Ubuntu" in the subject
[16:29] <asac> [reed]: i saw
[16:29] <asac> will answer next
[16:29] <asac> i am even CCed ;)
[16:30] <asac> [reed]: in short: we didnt apply the patch because the other part needed backporting
[16:30] <gnomefreak> last i heard it will be atleast 1 year before flash 64 will be even close to release, asac it snot a rumor :) or if it is you didnt start it
[16:30] <[reed]> ok, cool
[16:30] <asac> gnomefreak: hehe ... my rumour is: they will never finish it ;)
[16:31] <asac> they just try to calm the mob by having it in beta state
[16:31] <gnomefreak> ah you may still be right :) im looking to see if i have an email address for them
[16:32]  * gnomefreak was hoping to get an email back from the rock station already
[16:34] <gnomefreak> chromium doesnt like to ask or to even save passwords
[16:42] <micahg> chrisccoulson: hi, I have openjdk for karmic, should I copy to transition PPA or do you want to pull from my personal PPA?
[16:42] <chrisccoulson> micahg - awesome. i can just take that from your personal PPA
[16:43] <micahg> chrisccoulson: the only thing not adjusted is the maintainer, it set for me ATM, since I didn't know if we should keep the openjdkteam or not: https://launchpad.net/~micahg/+archive/mozilla-test/+packages
[16:45] <micahg> chrisccoulson: the other thing is that control.in and control aren't in sync, but I figured that might not matter in a backport
[16:46] <micahg> chrisccoulson: actually that last statement wasn't true, but for some reason, in my chroot, it wouldn't set the karmic build deps right when I regenerated the control file
[16:46] <micahg> chrisccoulson: so I manually dropped llvm to 2.6 and dropped oprofile from the build deps
[16:57] <micahg> chrisccoulson: I'm thinking more and more that maybe I need more checks on that symlink for the profile dir for Thunderbird 3
[17:03] <micahg> asac: thank you for the endorsement :)
[17:11] <jdstrand> micahg: did you run the verification test suite on your openjdk packages? I don't have the details, but doko has a testing procedure you could ask about if you haven't already (it's in main, so we need to follow whatever procedures he uses)
[17:11] <jdstrand> chrisccoulson: has upstream reviewed the hardy font configuration patches yet?
[17:11] <micahg> jdstrand: ah, good point, I should do that
[17:12] <jdstrand> micahg: cool, thanks
[17:12]  * micahg wonders if it'll run in a chroot
[17:12]  * jdstrand has no idea -- ask doko
[17:12] <chrisccoulson> micahg - i will take a look at those issues with debian/control shortly if you like
[17:12] <chrisccoulson> jdstrand, not yet. karl said he was going to look at it when he gets some time
[17:12] <chrisccoulson> i will ask him again later
[17:13] <micahg> chrisccoulson: well, the only issue is the maintainer I think, everything else is generated anyways
[17:13] <jdstrand> chrisccoulson: hmmm. I'm not sure what that means. is this going to hold up our publication?
[17:13] <jdstrand> at least 3.6.4 hasn't been released yet...
[17:19] <chrisccoulson> jdstrand - i'm not sure if it should hold up publication (if it comes to that). the fonts aren't that bad with the fixed cairo patch - they just can't be configured in the same way as before
[17:21] <jdstrand> chrisccoulson: ok. sounds good to me. we'll yank it if that is all that is left and it can be added as an SRU or in the next security update if desired
[17:42] <chrisccoulson> jdstrand - ok, no worries. one thing we still need to do is test the old epiphany with xulrunner 1.9.2 installed on the system
[17:42] <chrisccoulson> seeing as we don't have an immediate solution for that just yet
[17:42] <jdstrand> chrisccoulson: I thought 1.9.2 was a new package? won't epiphany-gecko continue to use 1.9.1?
[17:42] <jdstrand> or rather 1.9
[17:44] <micahg> jdstrand: there's a transitional package for epiphany-gecko
[17:45] <jdstrand> right, but we aren't uploading the new epiphany until it is ready
[17:45] <micahg> jdstrand: ah
[17:45] <chrisccoulson> jdstrand - it's not quite as simple as that unfortunately. epiphany will load the newest runtime where the version is between the range passed to GRE_GetGREPathWithProperties
[17:45] <jdstrand> so, the old epiphany should continue to use 1.9, unless 1.9.2 replaces it, which I didn't think it did
[17:46] <chrisccoulson> and i just checked the epiphany source, and it will load 1.9.2
[17:46] <micahg> chrisccoulson: is there a patch in the old epiphany where we can tweak the GRE?
[17:46] <jdstrand> ok. we can test that
[17:46] <chrisccoulson> this is the same issue that broke yelp with 1.9.2 installed on the system ;)
[17:46] <chrisccoulson> micahg - yeah, we will have to do that if it breaks
[17:46] <chrisccoulson> that's what i did with yelp already
[17:47] <jdstrand> sounds like we should expect some breakage. we should be able to do an update for epiphany to not pull in 1.9.2 and then work on epiphany webkit. we'll see
[17:47] <jdstrand> if there is no breakage, that would certainly be nice :)
[17:47] <jdstrand> we could continue to update 1.9.2 until hardy is EOL
[17:47] <chrisccoulson> jdstrand - yeah, we could do that. i'm not sure how we handle the versioning though, as we already have 2.28 in the PPA
[17:48] <jdstrand> (that is probably wishful thinking though)
[17:48] <jdstrand> chrisccoulson: just delete it from the ppa
[17:48] <jdstrand> I think that should work fine
[17:48] <chrisccoulson> jdstrand - it would probably just be safer to patch it only load 1.9 for now, rather than having it spring up some surprises on us later on ;)
[17:48] <jdstrand> we are going to need to seriously clean out that ppa after this anyway
[17:48] <chrisccoulson> yeah, it's got a lot of packages now
[17:49] <jdstrand> (and deleting doesn't really delete it...)
[17:49] <chrisccoulson> yeah, i noticed that when we ran out of space
[17:49] <chrisccoulson> but, there's no chance of that happening again now we have a 1TB limit in the PPA ;)
[17:53] <chrisccoulson> right, i have to disappear for 30 minutes or so to run some errands
[17:53] <chrisccoulson> bbiab
[17:53] <jdstrand> haha
[17:56] <micahg> Repository size:     21.7 GiB        (2.17%)         of 1000.0 GiB
[18:12] <fta> micahg, at some point, ucd was using ~40G with a single package ;)
[18:13] <micahg> fta: that's wild
[18:30] <chrisccoulson> back
[18:30] <chrisccoulson> urgh, i feel absolutely rotten today
[19:10] <ejat> ouch .. 1TB
[19:24] <ddecator> adobe stopped offering their alpha version of 64-bit flash, but they said they would release it in a future version (i saw you guys were talking about that earlier :p)
[19:24] <ddecator> chrisccoulson: hope you feel better soon
[19:34] <chrisccoulson> ddecator, thanks, so do i :)
[19:47] <jdstrand> chrisccoulson: hey, where did beagle 0.3.3-2ubuntu<IP_ADDRESS> go?
[19:51] <jdstrand> chrisccoulson: and ctxextensions 4.3.2010020101-0ubuntu<IP_ADDRESS>
[19:52] <jdstrand> chrisccoulson: did we decide to not update ctxextensions?
[20:00] <jdstrand> chrisccoulson: err... are you sure you want to use an epoch for ctxextensions?
[20:02] <jdstrand> chrisccoulson: only a small handful of people should be affected... imho we should just delete the newer one and have the few people who tested it downgrade manually
[20:02] <jdstrand> chrisccoulson: otherwise karmic-lucid upgrade won't work
[20:53] <gnomefreak> i dont think its Firefox causing the very slow run. I think its Tbird
[20:54] <gnomefreak> it doesnt have to be doing anything, just sitting there online or offline it causes a great lag
[20:56]  * gnomefreak testing
[20:56] <gnomefreak> ok found the problem
[20:57] <fta> jdstrand, is chromium ready to land in updates & security now?
[20:58] <jdstrand> fta: yes, as of a little while ago
[20:58] <jdstrand> fta: let me copy it
[21:03] <fta> thanks
[21:08] <micahg> chrisccoulson: can I send a mail on behalf of the Ubuntu Mozilla Team asking how long support for TB3.0 will be?
[21:22] <gnomefreak> micahg: go for it
[21:23] <gnomefreak> micahg: can you CC me or the mailing list as well.
[21:40] <micahg> chrisccoulson: can I send a mail on behalf of the Ubuntu Mozilla Team asking how long support for TB3.0 will be?
[21:40] <chrisccoulson> micahg - yeah, can do. could you please copy me on that too?
[21:40] <micahg> chrisccoulson: yes
[21:42] <micahg> chrisccoulson: gnomefreak: done with you 2 copied
[21:42] <micahg> chrisccoulson: I'm still trying to figure out how to run the TCK for OpenJDK
[21:43] <gnomefreak> micahg: thanks
[21:43]  * micahg has to get some other work done right now though
[21:44] <gnomefreak> micahg: how long (are we going to bother) pushing updates for FF in Hardy?
[21:44] <micahg> gnomefreak: until EOL we hope
[21:44] <gnomefreak> EOL of desktop?
[21:45] <micahg> gnomefreak: yep, so next April
[21:45] <gnomefreak> thanks i told him to upgrade to Lucid (suggested but i will get this right. :)
[21:45] <nxvl> chrisccoulson: any ETA on FF?
[21:46] <chrisccoulson> nxvl - not yet ;)
[21:46] <chrisccoulson> soon ;)
[21:46] <chrisccoulson> that's all i know really
[21:47] <jdstrand> chrisccoulson: fyi, epiphany absolutely requires an update. 'EphyBrowser initialization failed for...'
[21:47] <nxvl> chrisccoulson: ok, thnx
[21:47] <jdstrand> chrisccoulson: did you see my other questions?
[21:47] <chrisccoulson> jdstrand - interesting. thanks
[21:47] <chrisccoulson> jdstrand, yeah, i think i answered your earlier questions
[21:48] <micahg> chrisccoulson: according to upstream wiki, they should have a better idea later today about when to ship 3.6.4
[21:48] <jdstrand> chrisccoulson: no, I think you missed them. here they are:
[21:48] <jdstrand> 13:47 < jdstrand> chrisccoulson: hey, where did beagle 0.3.3-2ubuntu<IP_ADDRESS> go?
[21:48] <jdstrand> 13:51 < jdstrand> chrisccoulson: and ctxextensions  4.3.2010020101-0ubuntu<IP_ADDRESS>
[21:48] <jdstrand> 13:52 < jdstrand> chrisccoulson: did we decide to not update ctxextensions?
[21:48] <jdstrand> 14:00 < jdstrand> chrisccoulson: err... are you sure you want to use an epoch  for ctxextensions?
[21:48] <jdstrand> 14:02 < jdstrand> chrisccoulson: only a small handful of people should be  affected... imho we should just delete the newer one and have  the few people who tested it downgrade manually
[21:48] <gnomefreak> Debian is keeping xul191
[21:48] <chrisccoulson> jdstrand - yeah, i answered those ;)
[21:49] <jdstrand> chrisccoulson: they didn't hit the channel afaict
[21:49] <micahg> gnomefreak: Debian has their own issues to deal with ;)
[21:49] <chrisccoulson> ah
[21:49] <gnomefreak> yep seems so ;)
[21:49] <chrisccoulson> that might have occurred when i undocked, and i switched from wireless to wired
[21:49] <micahg> gnomefreak: we're jumping to xul193 for maverick +1
[21:49] <jdstrand> chrisccoulson: you had a ping timeout and came back on
[21:49] <gnomefreak> micahg: dropping xul192 at that time?
 jdstrand - beagle and ctxextensions for hardy aren't needed as the current versions aren't needed
[21:49] <chrisccoulson>  and ctxextensions doesn't exist in lucid, which is why i fixed the other problem with an epoch in karmic
[21:49] <chrisccoulson>  i wasn't sure if i could just delete packages from the PPA, after the call for testing has gone out
[21:50] <micahg> gnomefreak: yep, we only plan on supporting one xul release per release
[21:50] <chrisccoulson> i meant to say that the current versions don't work
[21:50] <chrisccoulson> (for beagle and ctxextensions)
[21:50] <jdstrand> chrisccoulson: ok, I'll update the wiki
[21:51] <jdstrand> chrisccoulson: I still encourage removing the epoch. maybe a followup email can go out to those that tested it... I doubt anyone did since I had already commented on it in the tracker
[21:51] <gnomefreak> that sounds like a great idea assuming everything is on same version. ff37 is xul193 tb  is xul192 and ff3.6 is 192 as well, tb im not sure about, i could never keep that straight
[21:51] <chrisccoulson> jdstrand - ok, i can do that
[21:51] <jdstrand> if we ever bring it back, it'll be a problem...
[21:51] <jdstrand> chrisccoulson: thanks
[21:51] <micahg> gnomefreak: by then, we might be at TB32 :)
[21:53]  * gnomefreak not holding breath
[21:58] <micahg> gnomefreak: BTW, xul191 might be EOL before squeeze is released :)
[21:59] <gnomefreak> they still havent released squeeze? i thought they were going to shorten the devel cycles to be shorter
[22:00]  * gnomefreak trying to find the right words for this email, other than bad bad things ;)
[22:00] <micahg> gnomefreak: squeeze isn't even frozen yet, they have a few major transitions in progress, they have to be completed before they can freeze
[22:00] <gnomefreak> so much for the trying to be like us :)\
[22:01] <micahg> gnomefreak: well, one of the transitions is python 2.6 :)
[22:01] <gnomefreak> if we can do it so can they since alot of our core devs are/were Debian devs
[22:02] <micahg> gnomefreak: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-python@lists.debian.org;tag=python2.6
[22:02] <gnomefreak> looking thanks
[22:03] <gnomefreak> thats all the blockers?
[22:04] <micahg> gnomefreak: for that transition :)
[22:04] <gnomefreak> damn
[22:05] <gnomefreak> listening to radio and ali morgan is on from 9-2 what do you call that? a segment or a show?
[22:05] <gnomefreak> im at a loss for words
[22:12]  * gnomefreak found words let hope she doesnt take it the wrong or RIGHT way
[22:14] <gnomefreak> be back smoke
[22:21] <micahg> chrisccoulson: we don't intend to continue supporting hardy after Desktop EOL, right?
[22:26] <chrisccoulson> micahg - i don't think there's anything we need to maintain for the server
[22:27] <micahg> chrisccoulson: k, just wanted to verify before responding on the ML, user was asking about FF updates after desktop EOL
[22:28] <gnomefreak> micahg: yep i CCed the list
[22:28] <chrisccoulson> yeah, we wouldn't update FF after the desktop has gone EOL, but i'm not sure if anything on the server uses xulrunner
[22:28] <gnomefreak> i think i sent it
[22:28] <micahg> gnomefreak: yes, you did
[22:28] <gnomefreak> micahg: thanks
[22:29] <chrisccoulson> jdstrand - i've dropped epiphany from the PPA as well for now. i will upload a version that makes it carry on working after the upgrade later
[22:30] <jdstrand> chrisccoulson: k
[22:31] <micahg> gnomefreak: answered
[22:34] <gnomefreak> micahg: thanks
[22:40] <jdstrand> chrisccoulson: fyi, I gave firegub/karmic a pass after retesting. I think it might have been one of the other extensions that I had installed that was broken and messing it up
[22:40] <jdstrand> chrisccoulson: I don't know that, but that is what I going with :)
[22:40] <jdstrand> chrisccoulson: at any rate, one less bug in the qa tracker
[23:12] <jdstrand> chrisccoulson: fyi, mozilla-noscript is fine now too
[23:12] <jdstrand> chrisccoulson: and ctxextensions is good
[23:12] <jdstrand> chrisccoulson: (those are karmic)
[23:12] <jdstrand> chrisccoulson: and apparmor is fixed
[23:12] <chrisccoulson> jdstrand - cool, that's good
[23:12] <chrisccoulson> thanks for testing
[23:12] <jdstrand> chrisccoulson: so that should leave only openjdk on karmic
[23:13] <micahg> jdstrand: is it worth trying to keep noscript up to date in the security PPA before release, or just SRU the latest after release?
[23:14] <jdstrand> micahg: well, what is in the ppa is working ok. I don't know what you want to SRU, but if it is bugfix only, the SRU later
[23:15] <micahg> jdstrand: well, usually every release or every other release of noscript has security fixes
[23:16] <jdstrand> micahg: if it is security relevant, then it can go in
[23:16] <micahg> jdstrand: well, my question is how much to worry about keeping up to date in the PPA?
[23:17] <jdstrand> micahg: I'm not worried at all. to me, sru is fine
[23:17] <micahg> jdstrand: k, it's in universe also, so I guess it's a little lower in priority
[23:17]  * jdstrand nods
[23:17] <micahg> jdstrand: I'll plan for an SRU next month then
[23:18] <jdstrand> cool, thanks :)


[16:15] <lotuspsychj3> looking good https://discourse.ubuntu.com/t/community-support/33339 aaronprisk[m] !
[16:17] <aaronprisk[m]> Thank you! Do you feel this newer structure addresses your navigation concern?
[16:18] <lotuspsychj3> aaronprisk[m]: its a great starting point for users for sure, i love it
[16:18] <lotuspsychj3> now the last important step to link it to https://ubuntu.com/support/community-support
[16:19] <lotuspsychj3> and we ready to go :p
[16:22] <aaronprisk[m]> Great! Once we have a few more pieces ready on the back-end, we should be able to update the main landing page as well.
[16:22] <aaronprisk[m]> I appreciate you bringing this to my attention, lotuspsychj3.
[16:23] <lotuspsychj3> great tnx aaronprisk[m]


[00:02] <Spass> CET here (Poland), so time to sleep, thanks once more and see you later.
[09:25] <JackFrost> https://mail.xfce.org/pipermail/xfce/2016-December/035391.html Oh I didn't see that.
[12:04] <flocculant> I did
[13:53] <Spass> Is there an easy way to generate my PGP key under Xubuntu? Something like "Passwords and Encryption Keys" tool. I want to sign CoC on Launchpad.
[14:19] <davmor2> Spass: seahorse will do it
[14:21] <Spass> davmor2: Thank you, that's the one.
[14:28] <davmor2> no probs
[21:54] <knome> hey ochosi


[07:53] <jamespage> gnuoy, re bug 1566688
[07:53] <mup> Bug #1566688: Charm installs different l3 package for same openstack release for installs > trusty <neutron-gateway (Juju Charms Collection):Confirmed for gnuoy> <https://launchpad.net/bugs/1566688>
[07:53] <jamespage> thats correct
[07:53] <jamespage> Ubuntu releases after trusty did not have...
[07:56] <jamespage> openswan
[07:56] <jamespage> which was the default vpn option for the vpn-agent until recently
[07:56] <jamespage> strongswan is now supported as well which is in later releases...
[08:00] <gnuoy> jamespage, so it should be http://paste.ubuntu.com/15642553/
[08:00] <gnuoy> ?
[08:00] <jamespage> gnuoy, maybe
[08:00] <jamespage> tbh I took the approach of disabling post trusty as I had not tested with strongswan
[08:00] <jamespage> and we've sinularly failed to get neutron-vpn-agent into main since then as well
[08:01] <gnuoy> ok, I'll go and ponder, thanks
[08:04] <jamespage> gnuoy, is this blocking something?
[08:08] <gnuoy> jamespage, with the new pause/resume code the services that we register against a config have to actually be accurate rather than the scatter gun register loads and don't worry if they don;t exist
[08:09] <gnuoy> so its just fall out from that
[08:09] <gnuoy> I think I just need to update the amulet tests for my pause/resume branch tbh
[08:09] <gnuoy> I have a if-icehouse-or-greater-its-neutron-vpn-agent clause which is obviously now wrong
[08:10] <gnuoy> s/now//
[08:10] <jamespage> gnuoy, yeah - its if_trusty_neutron_vpn
[08:10] <gnuoy> ack
[08:20] <A-Kaser> Hi
[08:49] <jamespage> coreycb, gnuoy: https://review.openstack.org/#/c/302101/
[08:49] <jamespage> follow up for coreycb's keystone ch-resync for 8.1.0 for stable
[09:26] <D4RKS1D3> Morning
[09:27] <D4RKS1D3> Someone has experience launching services in openstack with juju? I receive this error "ERROR instances not found"
[09:30] <webscholar> Hi all
[09:31] <webscholar> I am trying to install juju2 beta3 on ubuntu 14.04 LTS using the ppa:juju/devel but it installs the juju 1.24 version
[09:31] <webscholar> Can any one share the ppa for juju 2 latest version here ?
[09:34] <webscholar> I am following this
[09:34] <webscholar> https://jujucharms.com/docs/devel/getting-started-general
[11:05] <freak_> anyone available ? need help regarding juju quickstart
[11:06] <freak_> getting error:    juju-quickstart: error: invalid version string: 2.0
[11:07] <freak_> i have installed juju 2
[11:07] <freak_> and quickstart version is 1.3.1
[11:28] <rick_h_> freak_: juju-quickstart is deprecated for juju 2.0.
[11:28] <rick_h_> freak_: juju 2.0 does the work that quickstart did
[11:39] <jamespage> gnuoy, https://review.openstack.org/#/c/301761
[11:39] <jamespage> I think that will do the trick, just need test rig time now....
[11:46] <stub> webscholar: Add ppa:juju/devel and ppa:juju/stable, and install the juju2 package
[13:07] <webscholar> is there a way to mention in bootstrap command which node to use as bootstrap ? When I run juju bootstrap <controller-name> my-maas it bootstraps with its own choice
[13:12] <evilnickveitch> webscholar, if you are using MAAS, you can do it with constraints
[13:19] <evilnickveitch> webscholar, see https://jujucharms.com/docs/devel/charms-constraints and:
[13:19] <evilnickveitch> https://jujucharms.com/docs/devel/reference-constraints
[14:26] <jcastro_> tvansteenburgh, https://github.com/juju/docs/issues/692
[14:53] <stub> Does juju-deployer work with juju2? Interested because amulet, and I'm not sure if juju-deployer needs updating or my environment isn't setup the way it wants.
[14:54] <lazyPower> stub tvansteenburgh is working on it.
[14:54] <tvansteenburgh> stub: tip of deployer works on juju2
[14:54] <stub> ta
[14:54] <tvansteenburgh> stub: same for python-jujuclient
[14:55] <stub> I think the juju-deployer issue has saved me tripping over python-jujuclient ;)
[15:49] <jamespage> coreycb, gnuoy, thedac: can one of you do the honours on https://review.openstack.org/#/c/302101
[15:49] <jamespage> +2 review +1 workflow needed
[15:50] <coreycb> jamespage, on it
[15:51] <jamespage> coreycb, ta
[16:09] <tych0> is there a way to set model config globally?
[16:10] <tych0> like if i always want to set image-stream=daily and default-series=xenial for everything?
[16:10] <Spads> when the agent-status message is "run leader-settings-changed hook", is that prescriptive or descriptive?
[16:10] <Spads> like, is that saying what failed, or advising me on how to un-fail it?
[16:12] <marcoceppi> jcastro_: http://paste.ubuntu.com/15654448/
[16:22] <jamespage> gnuoy, urgh
[16:22] <jamespage> so
[16:22] <jamespage> gnuoy, I just hit the nuance of binding a device to dpdk in that it disappears from /sys/class/net/
[16:23] <jamespage> so re-running the same code post binding results in an empty whitelist of pci devices based on resolution by mac address...
[16:25] <gnuoy> jamespage, do the devices appear elsewhere in the /sys tree?
[19:12] <cory_fu> kwmonroe, c0s: How do you feel about my suggestion in the email about all NameNodes sharing a common ssh key?
[19:13] <cory_fu> Does that seem insecure?  I notice that Big Top has an ssh key checked in to the repo, but I assume that will get replaced by a generated one in a deployment, right?
[19:15] <c0s> cory_fu: are you referring to the yesterday's email?
[19:16] <c0s> cory_fu: in Bigtop there are two different places where we use SSH key
[19:16] <c0s> keys
[19:16] <c0s> 1. for ssh fencing (this one is getting generated, I believe)
[19:16] <c0s> 2. for user hdfs ONLY IF a special test-mode is turned on.
[19:17] <c0s> The latter is static, but is only used in a controlled environment for passwordless ssh, because we need it for some low-level HDFS tests (like block recovery, for instance)
[19:17] <c0s> does it make sense?
[19:18] <cory_fu> Yep
[19:18] <c0s> in general, using static key in production is big no-no, of course
[19:18] <cory_fu> So, for fencing, do you think it's insecure for the namenodes to share a (generated) key?
[19:28] <cory_fu> c0s: I ask because it simplifies the key management quite a bit and if the nodes already have passwordless ssh amongst each other, it doesn't seem any less secure for them to use the same ssh key to do it.  Though, it does mean putting the private key in the leader settings, but again, if you access to that, then you already have access to those boxes
[19:28] <c0s> yeah, I agree
[19:29] <c0s> sharing generated key is perhaps ok.
[19:29] <c0s> Ideally, you'd want some sort of PK management system like kerberos ;)
[19:29] <cory_fu> +1
[19:29] <c0s> but it is way too heavy and overly-sensetive
[19:45] <jcastro_> heya evilnickveitch
[19:46] <evilnickveitch> jcastro, hello, having fun?
[19:46] <jcastro_> I don't have perms to do this, but if you want to take every "this page doesn't have navigation for next and back" bugs for the docs and point them all to one, Marco is going to do it
[19:46] <jcastro_> evilnickveitch, it is wonderful to delete large swaths of things we don't need, yes!
[19:47] <evilnickveitch> jcastro, yes, I am looking forward to killing a lot more stuff tomorrow
[19:48] <evilnickveitch> jcastro, to clarify, not EVERY page is going to have next/back?
[19:48] <evilnickveitch> perhaps i need to see the implementation
[19:54] <jcastro_> yeah so like, are we putting something in the footer or ?
[19:54] <jcastro_> marcoceppi, ^
[19:55] <marcoceppi> jcastro_ evilnickveitch each page, that has peers at the same level, will have a forward backward (when applicable). this will be built using the navigation information and embedded at compile time
[19:55] <marcoceppi> evilnickveitch: I'd support a breadcrumb header that we could interprut at build time to say either breadcrumb: true|false and a sane default to drive this functionality
[19:55] <marcoceppi> but it's basically going to be a new mdx plugin
[19:56] <marcoceppi> evilnickveitch: as an example: https://jujucharms.com/docs/devel/developer-getting-started#install-libraries-and-tools
[19:57] <marcoceppi> at the bottom this would have "Designing your charm ->"
[19:57] <marcoceppi> evilnickveitch jcastro_ the following page, Designing your charm, would have "<- Install libraries and tools                   Writing your charm ->"
[19:58] <marcoceppi> althight, that's a terrible example, since those are anchors
[19:58] <marcoceppi> but that's the idea
[19:58] <evilnickveitch> marcoceppi, I see how that works for the developer docs, as a lot of that is a narrative. Not sure it works so well in other parts
[19:59] <evilnickveitch> but yeah, whatever, I will take a look if you do it
[19:59] <marcoceppi> evilnickveitch: so we would have the top of page config "breadcrumb" set to false
[19:59] <marcoceppi> evilnickveitch: and we'd enable it where it made sense
[19:59] <evilnickveitch> ok
[20:03] <evilnickveitch> marcoceppi, actually, thinking about it...
[20:04] <evilnickveitch> marcoceppi, it would probably save some effort if you just used the metadata
[20:04] <marcoceppi> what metadata?
[20:04] <evilnickveitch> to turn on and off
[20:04] <evilnickveitch> marcoceppi, at the top of each doc
[20:04] <evilnickveitch> there is a line or number of lines
[20:04] <evilnickveitch> (mostly to set the title0
[20:05] <evilnickveitch> any key:value there is interpreted as metadata
[20:05] <evilnickveitch> so it doesn't get processed.
[20:05] <evilnickveitch> hang on...
[20:06] <evilnickveitch> marcoceppi, https://pythonhosted.org/Markdown/extensions/meta_data.html
[20:06] <evilnickveitch> at the moment it is used for the page titles, and the todo generator
[20:06] <marcoceppi> evilnickveitch: cool
[20:06] <evilnickveitch> but it would be simple to add Breadcrumb:true or whatever
[20:06] <evilnickveitch> the metadat is already parsed in the build tool
[20:07] <evilnickveitch> i think you get a dict
[20:07] <evilnickveitch> so, yeah
[20:07] <evilnickveitch> try that way first :)
[20:18] <evilnickveitch> marcoceppi, actually, thinking about it even more, you could have Previous and next instead in the metadata, and use the urls as values. It does mean some manual editing to begin with but would be a lot simpler to implement.
[20:19] <evilnickveitch> anyhow, I think I have done enough thinking for one day
[21:06] <tvansteenburgh> dpb1_, fginther: fyi https://code.launchpad.net/~tvansteenburgh/python-jujuclient/juju2-fixes/+merge/291182
[21:55] <dpb1_> tvansteenburgh: looking
[21:56] <dpb1_> tvansteenburgh: you have an error ~2613 it looks lik
[21:56] <dpb1_> like
[21:57] <tvansteenburgh> dpb1_: jeez, htf did that happen
[21:57] <tvansteenburgh> dpb1_: fixing
[21:57] <dpb1_> :)
[21:59] <tvansteenburgh> dpb1_: fixed and pushed
[22:00] <dpb1_> re-merging
[22:06] <dpb1_> looking now
[23:16] <c0s> kwmonroe: if not with jujuresources how else can I can download binaries specified in resources.yaml? Is there any helper code for that?


[10:57] <RikMills> mparillo @DarinMiller would you consider adding to this? https://docs.google.com/document/d/1-3O2HiMDrRQ0Wj7msbNQcduLD7-EvGWHCEdWvu8l2GI/edit#heading=h.s6x48t6bb3zn
 ditto to any other testers
[11:30] <BluesKaj> Hi folks
[11:37] <RikMills> BluesKaj: maybe? https://docs.google.com/document/d/1-3O2HiMDrRQ0Wj7msbNQcduLD7-EvGWHCEdWvu8l2GI/edit#heading=h.s6x48t6bb3zn
[11:39] <mparillo> I am waiting to see if Kubuntu appears on that cancel letter.
[11:40] <RikMills> mparillo: why?
[11:41] <mparillo> Probably best suited for off-topic, but I will be done.
[11:42] <BluesKaj> RikMills, I really don't have much to say except kubuntu 21.04 so far has been the most stable dev OS so far in my testing experience ;-)
[11:43] <BluesKaj> excuse the repitition there
[11:45] <BluesKaj> err repetition
[11:45] <BluesKaj> I'm on my first coffee so....


[08:34] <ara> Hello!
[08:34] <ara> There are more and more systems with hybrid graphics in the market (UMA + discrete)
[08:35] <ara> Are there plans in the installer development to support this (i.e. switching between one or the other during installation time)
[08:35] <ara> ?
[09:57] <cjwatson> ara: on the face of it, it doesn't sound like something an installer should concern itself with; better to keep it simple at installation time, and I don't think users would be surprised by the installer keeping it simple
[10:59] <CIA-14> ubiquity: cjwatson * r4763 trunk/ (3 files in 3 dirs): Recreate .pyc modules excluded from the live filesystem.
[11:00] <cjwatson> now I suppose I have to finish fixing eglibc so that ubiquity can build :-/
[12:26] <cjwatson> ah, the package that actually needed to be updated was langpack-locales, not eglibc
[12:26] <cjwatson> that's nice since it might build in finite time
[12:34] <CIA-14> ubiquity: cjwatson * r4764 trunk/ (d-i/manifest debian/changelog):
[12:34] <CIA-14> ubiquity: Automatic update of included source packages: grub-installer
[12:34] <CIA-14> ubiquity: 1.64ubuntu3, user-setup 1.28ubuntu16.
[12:55] <ScottK> ev: I took a look at the ubiquity powerpc build failure and it seems like some locale change that I don't understand.  It replicates on i386 now, so it's only due to archive skew it only failed powerpc.
[12:55] <ev> lovely
[12:56] <ev> I'll have a look tomorrow (swamped in wubi framework investigation work today)
[12:56] <ScottK> Thanks.
[13:09] <cjwatson> ScottK: that's what I was referring to above ...
[13:10] <ScottK> cjwatson: Oh.  I only skimmed the backscroll.  Missed it.
[13:10] <cjwatson> I uploaded langpack-locales about three-quarters of an hour ago to fix it
[13:10] <ScottK> Cool.
[13:10]  * ScottK goes to look at the diff and maybe learn something.
[13:11] <ScottK> (the maybe is reflective of the odds of me learning, not their being something there to learn)
[13:13] <cjwatson> the changelog is probably the most informative bit ...
[13:56] <CIA-14> ubiquity: cjwatson * r4765 trunk/debian/changelog: releasing version 2.7.10
[16:23] <seb128> hi
[16:23] <cjwatson> ev: speaking of Wubi on #u-m - could you upgrade your build system to grub-pc-bin 1.99-8ubuntu1 and build wubi r220, please?
[16:23] <ev> sure thing
[16:23] <seb128> so ubiquity seems some gconf to gsettings love, do you prefer one bug "port to gconf"
[16:23] <ev> on it now
[16:24] <ev> yes
[16:24] <seb128> or different bugs like "settings migration should migrate gconf datas as well" or "read http proxy key in the wrong database"
[16:24] <seb128> or "unactive automount using a deprecated way"
[16:25] <seb128> "port to gsettings" I meant ;-)
[16:30] <ScottK> Was there any benchmarking done to check if removing the .pyc files has an effect on how fast Ubiquity starts up/installs?
[16:31] <cjwatson> no
[16:31] <ScottK> OK.  Thanks.
[16:31] <cjwatson> I decided not to worry too much about that since (a) the space savings are so large and (b) I suspect that I/O will tend to dominate
[16:32] <ScottK> Makes sense.  I figured it was a have to do kind of change for the space savings.  Just a matter of curiosity.
[16:36] <seb128> cjwatson, any opinion on the bugs filing question?
[16:36] <seb128> or is that an ev's thing?
[16:36] <seb128> I would like to file those
[16:36] <cjwatson> I actually didn't test a live filesystem without the .pyc files directly; I just modified ubiquity not to copy them in the bulk copy pass (since that was a lot quicker)
[16:36] <cjwatson> seb128: whatever ev wants on this is fine by me
[16:37] <ev> I think one giant bug is fine.
[16:37] <ev> as long as it's detailed in what it's requesting
[16:37] <seb128> it's going to be mediumly-small don't worry ;-)
[16:37] <seb128> ev, ok, doing that
[16:37] <seb128> thanks
[16:38] <ev> sure thing
[16:38] <bdmurray> cjwatson: I've quite a few grub2 apport-package bugs regarding '/usr/sbin/grub-probe: error: /boot/grub/device.map:2: No open parenthesis found.'  Is that something already fixed or is there already a master bug for that?
[16:41] <cjwatson> bdmurray: I've not heard of it
[16:41] <cjwatson> could be a local misconfiguration
[16:42] <cjwatson> bug#?
[16:42] <cjwatson> especially one that has an example device.map attached :-)
[16:42] <bdmurray> bug 797065 (I'll have to look harder for a device.map one)
[16:42] <ubot2> Launchpad bug 797065 in grub2 "package linux-image-2.6.32-32-generic 2.6.32-32.62 failed to install/upgrade: post-installation script instalaturik azpiprozesuak 1 errorea eman du irteeran" [Undecided,New] https://launchpad.net/bugs/797065
[16:44] <bdmurray> cjwatson: okay not too hard don't see any attachments named *device*
[16:52] <cjwatson> I've requested it
[16:53] <cjwatson> and I'll modify grub2's apport hook to attach it too
[16:54] <bdmurray> cjwatson: I've some work to do on that anyway so could do it
[16:55] <cjwatson> already done :)
[16:55] <bdmurray> ah, great
[16:55] <cjwatson> in Debian, anyway
[16:56] <cjwatson> will pick it up at the next upload/merge
[16:57] <bdmurray> bug 642290 is rather odd too - its an error regarding /etc/grub.d/README
[16:57] <ubot2> Launchpad bug 642290 in grub2 "package linux-image-2.6.32-24-generic 2.6.32-24.43 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saída de erro 2" [Undecided,New] https://launchpad.net/bugs/642290
[16:57] <cjwatson> bdmurray: incidentally, I notice that even though bug 797065 was apparently initially filed on grub2, grub2's apport hook doesn't seem to have taken effect
[16:57] <ubot2> Launchpad bug 797065 in grub2 "package linux-image-2.6.32-32-generic 2.6.32-32.62 failed to install/upgrade: post-installation script instalaturik azpiprozesuak 1 errorea eman du irteeran" [Undecided,Incomplete] https://launchpad.net/bugs/797065
[16:58] <cjwatson> README> I thought I fixed that upstream ages ago
[16:58] <bdmurray> cjwatson: yes, I see that in the changelog now
[16:58] <cjwatson> huh, perhaps not
[16:58] <cjwatson> oh yes, there it is
[16:59] <bdmurray> cjwatson: there is no grub apport hook in lucid
[16:59] <cjwatson> ah, ok
[16:59] <cjwatson> I'll close out 642290
[16:59] <bdmurray> there are many more like that which I'll take care of
[17:00] <cjwatson> that's odd, it was supposed to have been fixed in lucid
[17:00] <seb128> ev, cjwatson: bug #800760
[17:00] <ubot2> Launchpad bug 800760 in ubiquity "Needs gconf to gsettings updates" [Undecided,New] https://launchpad.net/bugs/800760
[17:01] <cjwatson> perhaps some kind of local weirdness - anyway I gave a workaround
[17:01] <cjwatson> or maybe I got the patch wrwong in lucid somehow
[17:01] <seb128> ev, cjwatson: I've dumped notes on what I found with a grep gconf in the current ubiquity sources, I will update the bug during the cycle if,when desktop side change or if I get other comments
[17:03] <bdmurray> cjwatson: its too bad that at least 642290 doesn't have the grub package version in it
[17:03] <ev> seb128: thanks for the attention to detail on that! Very much appreciated
[17:03] <seb128> ev, yw ;-)
[17:16] <cjwatson> bdmurray: agreed
[17:28] <ev> new wubi is up
[17:32] <bdmurray> cjwatson: it seems to me the fix isn't in grub2 in lucid-updates
[17:32] <bdmurray> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/grub2/lucid-updates/view/head:/util/grub-mkconfig_lib.in#L129
[17:37] <cjwatson> bdmurray: look in debian/patches/972_ignore_grub.d_README.diff
[17:37] <cjwatson> it wasn't upstream at the time lucid was released
[17:37] <cjwatson> ev: thanks
[17:38] <bdmurray> ah, got it
[19:28] <bdmurray> cjwatson: regarding the grub apport hook there is a request to have /etc/default/grub to plymouth bug reports - so I was planning on moving some of the grub hook to apport itself.  Does that seem reasonable?
[21:07] <cjwatson> bdmurray: hmm, maybe have it in both with the same keys - I'd like it to be obvious that the grub one is freestanding to some extent
[21:07] <cjwatson> if that makes sense
[21:25] <bdmurray> cjwatson: I was looking at the _atach_file_filtered function in particular and only that
[22:41] <bdmurray> cjwatson: additionally it looks to me like /etc/default/grub just gets added to the report if it is invalid
[22:51] <cjwatson> how so?
[22:52] <cjwatson> EtcDefaultGrub should be added either way
[22:52] <cjwatson> InvalidGrubScript is a separate thing, largely intended for doing some kind of pre-reporting UI in the future
[22:54] <TheMuso> ev: How far along is the pygobject port? I am just wondering whether I should base my a11y work on that branch.
[22:54] <TheMuso> In the meantime, I'll use trunk
[23:34] <bdmurray> cjwatson:
[23:34] <bdmurray>         if not check_shell_syntax('/etc/default/grub'):
[23:34] <bdmurray>             invalid_grub_script.append('/etc/default/grub')
[23:34] <bdmurray> so its just adding without going through _attach_file_filtered right()?
[23:39] <cjwatson> no, that's preparing the value that goes into InvalidGrubScript, see above
[23:39] <cjwatson> entirely different key
[23:39] <cjwatson> EtcDefaultGrub is added before any of that stuff
[23:46] <bdmurray> I see its adding the string '/etc/default/grub' not the contents
[23:48] <cjwatson> yes, the (future) purpose of InvalidGrubScript is to display UI saying "these files are in an invalid syntax [list] so you probably stuffed it up locally" or some such
[23:48] <cjwatson> for now it's something we can scan bugs for
[23:49] <cjwatson> at least I assume that's the idea, I think jibel wrote it
[23:49] <cjwatson> and it's only in >= natty


[00:07] <wallyworld> babbageclunk: and if you get a chance today, that code review so i can include in dev summary email :-)
[00:08] <babbageclunk> wallyworld: oh sorry, forgot about that! I'll look after this.
[00:08] <wallyworld> no wuckers
[01:00] <hml> wallyworld: ping
[01:01] <wallyworld> hi
[01:01] <hml> wallyworld: do you have a few minutes for an HO?  darn feature tests
[01:01] <hml> :-)
[01:05] <wallyworld_> hml: sorry, computer froze :-(
[01:06] <hml> wallyworld: silly computers.  :-)  do you have time for a HO?  featuretests ...
[01:06] <wallyworld_> yep
[01:06] <hml> wallyworld_: team ho?
[01:08] <wallyworld_> ok
[01:08] <wallyworld_> hml: actually, standup
[02:09]  * babbageclunk goes for a run
[04:43] <babbageclunk> wallyworld_: reviewed, sorry for the delay!
[04:43] <wallyworld_> no worries, thanks for doing it
[05:04] <anastasiamac> axw: tyvm for review \o/
[05:04] <axw> anastasiamac: np, sorry for the delay
[05:05] <anastasiamac> i did not feel like there was - m entertained atm :)
[05:06] <axw> anastasiamac: :)
[05:17] <veebers> Hi all, please ignore any extra check-merge comments on open PRs. Some teething issues moving to a new system (triggered new runs for existing PRs)
[05:19] <babbageclunk> wallyworld_ or axw (or anyone else, but you two seem like you should know): what does the upgradedToVersion key in agent.conf mean? I'm looking at a unit which is in a 2.2.2 model but it has 2.1.0 in the conf file.
[05:20] <axw> babbageclunk: that's the version for which the upgrade steps have run on that agent
[05:20] <wallyworld_> +1
[05:32] <babbageclunk> axw: ok - so if there haven't been any unit-level upgrade steps since 2.1.0 then it won't have changed?
[05:33] <babbageclunk> axw: But I guess no harm in me setting it to 2.2.2 either?
[05:34] <babbageclunk> axw: Also, what's the relationship between apipassword, statepassword and oldpassword?
[05:37] <axw> babbageclunk: hmm I thought it would change it anyway, even if there weren't upgrade steps... seems to me it should do that if it doesn't. there's an upgrade step that should be in 2.2.2 (currently targeted to 2.2), which is to set the environ-version
[05:38] <axw> babbageclunk: statepassword is the mongo password. apipassword is the juju user password (I forget if those two are different...), and oldpassword... I forget
[05:43] <babbageclunk> axw: I'm going to assume they don't need to change between 1.25 and 2.2
[05:43] <babbageclunk> for now at least
[05:44] <axw> babbageclunk: statepassword is only relevant for controllers, so you should just be able to drop that
[05:45] <axw> babbageclunk: apipassword and oldpassword can remain the same
[05:56] <babbageclunk> axw: nice, thanks. It seems the same for stateaddresses too
[05:56] <axw> babbageclunk: yup
[05:57] <babbageclunk> axw: awesome.


[02:16] <Sazpaimon> is there any screen sharing server for ubuntu that works even remotely like windows rdp? (host resolution match, sound support, share same session as host)
[02:23] <bobdobbs> "apt-cache search [name]" will let me see if a package is available. How can see the version numbers of available packages?
[02:26] <Bashing-om> bobdobbs: 'apt show <package> '.
[02:26] <bobdobbs> thanks
[02:29] <circle> i want to install multiple linux version on one sdd  120G, dont want swap or separate home partitions. i dont know what the mount point should be for my boot partition or the format or the size please help for each version of linux i dont need a separate /home
[02:29] <circle> dealing with an old pc that has bios not uefi
[02:30] <circle> assuming i should make a partition table gpt
[02:30] <circle> then five partitions ex4 say for my linux OS (any flags needed?)
[02:31] <Bashing-om> circle: Old bios: --- all that is needed is one partition of about 30 gigs or so. Sharing a /home is not a good idea, Better is a shared data partition.
[02:31] <circle> and then a boot partition and i am totally guessing here that it would be btfs with boot flag ticked in GParted but i dont know size requirements
[02:32] <circle> ty Bashing-om
[02:33] <lotuspsychje> !partitioning | circle
[02:33] <circle> what about the boot partition assuming i make 4x30G partitions ext4 (mount point please?)
[02:33] <Bashing-om> circle: Unless there is an overriding concern ... tried and true -solid- ext4 for the file system.
[02:34] <circle> ty both can you tell me anything about my boot partitions format and size please...
[02:34] <Bashing-om> circle: bios does not need a separate /boot partition. I do multiboot on old hardware .. want to see my partitioning ?
[02:35] <circle> yeah
[02:36] <circle> when ever i install my OS (never manually partition them) there is always some small partition what is that called
[02:36] <circle> reletive to the other partition on the drive with the os and home on it
[02:38] <Endermen1094> it duesn;t want to show up on grub
[02:39] <Bashing-om> circle: with 2 drives active at this time: https://termbin.com/hbdrm ; https://termbin.com/1wpi .
[02:42] <Bashing-om> circle: Present booted system " /dev/sda1        28G  5.0G   21G  20% /" , Only 20% of 5 gigs used for root install. Does not take a lot :(
[02:44] <circle> ty humour me please trying to let it marinate into my brain i see that sdb8 is swap  and would like to know if extened(sdb4) is "shared storage"
[02:44] <Bashing-om> circle: sorry that is 28 gigs devoted to root of which 5 is used .
[02:44] <circle> or are they small versions of linux
[02:45] <circle> at least sdb1 2 3 6 7
[02:48] <circle> thanks for trying im gonna go have a go again without making a boot partition ill make a few 30G partitions and see if it lets me install linux in the past i always get some notice in the gui on desktop installs about no mountpoint
[02:49] <circle> or something that i asssume has to do with mbr/gpt boot partition
[02:49] <Bashing-om> circle: My sdb4 is a "extended" partition and in this partiton it contains the "logical" partitions sdb5,6,7, and 8. Leagacy partitioning only permits a max of 4 primary partitions. To get around this limitation is the creation of that "extended" partiton.
[02:49] <circle> legend that makes sense to me and is handy thank you
[02:50] <Bashing-om> circle: the mount point for root (/) will be whatever the location of the install is. like say sdb3.
[02:51] <circle> so i can just say mount point "/" on the given drive?
[02:52] <circle> my choices populate on a gui splash screen include /, /home....the list carries on
[02:53] <Bashing-om> circle: set that mount point for a given install to a given partition in the installer as the system is installed.
[02:53] <circle> thanks for everything will try my luck now feeling optimistic
[02:53] <circle> ciao
[02:55] <Bashing-om> circle: the option "use as" and in the drop down select '/' if that is what that partiton is to be used for, ext4 file system.
[03:45] <loller_> hi! I have an issue where the headphone component (the mic still works) of a USB headset (EKSA 1000) suddenly stopped working upon upgrading from 20.04 to 20.10
[03:46] <loller_> according to PulseAudio Volume Control sound is flowing to the correct output device (USB Audio Device Analog Stereo) but there is no sound in the headphones
[03:46] <loller_> dear Lord Jesus Christ
[03:47] <loller_> somehow (inadvertently) the hardware control on the headset for the headphone volume had been turned to zero
[03:47] <loller_> that was the issue all along
[03:48] <loller_> so, nevermind, haha
[03:48] <loller_> I guess it probably happened while the headset was packed in a bag and I was flying yesterday
[03:49] <WebChat777> where can someone find introduction material on how to learn ubuntu
[03:49] <WebChat777> I guess it might be nice to install the thing on a usb chip so I can boot the thing up
[03:49] <loller_> yes
[03:49] <loller_> that is a good way to learn
[03:50] <loller_> without committing to installing on your computer
[03:50] <loller_> if you know what you are doing you can also create a separate partition and install Linux there
[03:50] <RerDavies> I upgraded to Ubuntu 21.10, and the upgrade is hung. Stuck at "Installing the Upgrades" (installing new papirus.dtbo)....
[03:50] <loller_> but I would not do that if ur not sure what u are doing
[03:50] <WebChat777> so since I'm new to this thing is there a tutorial on how to install it to a chip I purchased a 32 gig sandisk chip to experiment with
[03:50] <RerDavies> Is there any sensible way to log a bug against this before I scrub the system and do a clean install?
[03:50] <loller_> are u using Windows?
[03:50] <loller_> WebChat777:
[03:51] <WebChat777> that's why I want to do it on a chip because I don't know what i'm doing
[03:51] <WebChat777> windows 10
[03:51] <WebChat777> right now
[03:51] <WebChat777> want to get away from this stuff it keep slowing down and i'm tired of fixing the problems
[03:51] <loller_> you can use Rufus for example: https://rufus.ie/
[03:51] <loller_> to create the bootable USB
[03:51] <WebChat777> rufus
[03:51] <WebChat777> is that software or some dude
[03:52] <loller_> software
[03:52] <WebChat777> opps
[03:52] <loller_> just click the link
[03:52] <WebChat777> cool
[03:52] <WebChat777> is that the link to find it
[03:52] <loller_> yes
[03:52] <WebChat777> https://rufus.ie/
[03:52] <WebChat777> i copied the one up there
[03:52] <WebChat777> call ????
[03:53] <WebChat777> I appreciate your help and have  a question, what is that list of people to the right 1020 it says
[03:54] <WebChat777> this list
[03:54] <WebChat777> AcidMan
[03:54] <WebChat777> abyss
[03:54] <WebChat777> Abrax
[03:54] <WebChat777> ablutor_
[03:54] <WebChat777> ablutor
[03:55] <RerDavies> WebChan777: That's the list of users who have currently joined the channel.
[03:56] <RerDavies> I upgraded to Ubuntu 21.10, and the upgrade is hung. Stuck at "Installing the Upgrades" (installing new papirus.dtbo)....  Is there any sensible way to log a bug or do a postmortem on this? I had a terminal open for a bit, but the system is now completely locked.
[03:56] <WebChat777> i see
[03:57] <WebChat777> i'm checking out that link for rufus it looks interesting
[03:58] <WebChat777> https://www.youtube.com/results?search_query=ubuntu+21+worst
[03:58] <viktor__> Hi all. I got some drives in an mdadm raid which i'd like to recover. Can I just reformat the drives? Or is there some other step I have to take?
[03:59] <WebChat777> I saw some of this stuff interesting maybe best to try linux less than 21
[04:01] <WebChat777> loller_20:51:32 thanks i'm going to try this thing maybe I will be able to find this place again if I get it working on the usb. I'll save this link in a note pad and try and find my way back here, found this by accident.
[04:01] <WebChat777> take care
[04:01] <WebChat777> thanks again
[04:01] <viktor__> WebChat777: there's always a lot of criticism on any new release. especially intermediate ones. try it out or don't
[04:04] <webchat51> Hello. I am trying to fix audio not playing from Firefox on Ubuntu 18.04.  I can't pinpoint exactly when it started, but I have tried restarting alsa, pulseaudio, Firefox, and rebooting the machine.
[04:04] <webchat51> I can play and hear audio from other programs just fine. My next idea was to try reinstalling pulse, and then alsa if that didn't work, but is that going too far?
[04:07] <webchat51> Oh, I also tried playing audio in a Firefox private/incognito window, and with all addons disabled.  The audio still didn't play through the speakers.
[04:20] <alkisg> webchat51: create a new user and try from there. That way you'll see if it's a system issue (e.g. /etc or /usr) or a user issue (i.e. ~/.mozilla)
[04:21] <viktor__> alkisg: is he supposed to have alsa as well as pulse installed?
[04:21] <alkisg> AFAIK yes
[04:22] <rsjw> I added a file to /etc/X11/Xsession.d that I know is being run because I can set environment variables, but whenever I try to write a file like echo "hello" > /home/me/out.txt, no file is created. any idea why not?
[04:26] <webchat51> alkisg I will try that


[07:47]  * apw yawns
[07:49] <RAOF> Time for the bees!
[07:49]  * RAOF will be able to deliver them in person next week.
[07:52] <apw> oh bees yes please
[19:11] <kees> rtg: heads up on a kernel SRU patch: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=754733ee8a82832b6dbd784facbe12dedd303f5e
[19:11] <kees> I'll have mdempsky open a bug and send the patch to the kernel-team list.
[19:15] <systest> how can I track which changes are incorporated in to the latest packages?  specifically, I'm trying to determine if/when an upstream patch gets applied to fix https://lkml.org/lkml/2014/4/1/14
[20:05] <bjf> systest, the "easiest" way is to look at our git repo
[20:08] <bjf> systest, that commit is in the trusty release version
[20:10] <systest> thanks, I'll clone a copy of the repo  just to take a look.  re being in the release version, thanks for looking that up
[20:10] <bjf> np
[20:11] <bjf> systest, in our trusty repo it's : f974c74cfa24b0872009d1cbab78f743c2535570
[20:12] <systest> ty
[21:09] <infinity> install: cannot stat './tmp/generic_netboot/tree/lib/firmware/3.15.0-1-generic/device-tree/apm-mustang.dtb': No such file or directory
[21:10] <infinity> rtg: ^-- Did that move, or get dropped, or...?
[21:33] <rtg> infinity, its still there as far as I can tell. debian.master/rules.d/arm64.mk: dtb_files_generic += apm-mustang.dtb
[21:34] <infinity> The binary packages disagree with you.
[21:34] <rtg> hmm, checking.
[21:36] <infinity> Or, rather, my d-i build disagrees.  Let me have a look at the binary packages.
[21:36] <rtg> firmware/3.15.0-1-generic/device-tree/apm-mustang.dtb
[21:36] <rtg> its in the linux-image package
[21:38] <rtg> infinity, the mustang firmware was never in a udeb. I wonder how dannf actually installs this beast.
[21:39] <infinity> rtg: It's not in the udeb anymore, and it used to be.
[21:39] <infinity> rtg: From trusty: http://paste.ubuntu.com/7490386/
[21:40] <infinity> Though, a bit sketchy that the udeb doesn't contain *all* the same DTs that the linux-image deb contains.
[21:40] <infinity> Must have been some APM-specific hack there.
[21:41] <infinity> rtg: Note that on armhf, the kernel-image udeb appears to have all the DTs.
[21:41] <infinity> rtg: So, this is an arm64-specific oops.
[21:41] <rtg> infinity, dang, you're right. dunno what happened in the transition to utopic. I'll figure it out.
[21:41] <infinity> rtg: Ta.  Whatever armhf does, that seems to be "the right thing to do" for arm64 too.
[21:42] <apw> rtg, well at least after the last upload its not a 'debian/*' issue as they diffed null
[21:42] <rtg> this line disappeared: debian.master/d-i/firmware/kernel-image:device-tree/apm-mustang.dtb ?
[21:43] <infinity> rtg: So, I'd argue the list should probably be expanded, but that's enough to make d-i happy, I think.
[21:43] <infinity> rtg: Since that's all that was shipped in trusty.
[21:44] <infinity> -rw-r--r-- root/root      4669 2014-05-18 19:33 ./lib/firmware/3.15.0-1-generic/device-tree/foundation-v8.dtb
[21:44] <infinity> -rw-r--r-- root/root      7782 2014-05-18 19:33 ./lib/firmware/3.15.0-1-generic/device-tree/rtsm_ve-aemv8a.dtb
[21:44] <infinity> -rw-r--r-- root/root      6985 2014-05-18 19:33 ./lib/firmware/3.15.0-1-generic/device-tree/apm-mustang.dtb
[21:44] <infinity> rtg: Those are the three that are in linux-image.deb, probably makes sense to mirror that to kernel-image.udeb.
[21:44] <infinity> rtg: And maybe to automate keeping them in sync too (I just noticed it's a manual list for armhf too, which seems crazy)
[21:44] <rtg> infinity, yup
[21:44] <infinity> rtg: But a quick turnaround of just the manual fix would do me for now if you'd like to see d-i build and your kernel migrate. :)
[21:45] <rtg> infinity, gimme a bit
[21:53] <hallyn> hm, migration/[0-3] are taking up a combined 90% cpu time
[21:53] <hallyn> though it's probably my punishment for cp'ing a large file on btrfs
[22:06] <infinity> rtg: Let me know when you're uploading, so I can give you sagari for ppc.
[22:13] <rtg> infinity, fire in the hole
[22:14] <infinity> rtg: Ta.  I'm doing a test build of d-i PPC to see if I have more things to yell about, but I think my failure there was just the removal of e500.  I hope. :P
[22:15] <infinity> And look at that, you got sagari without my help.
[22:15] <rtg> luck of the draw
[22:17] <infinity> rtg: Nice commit message. :P
[22:17] <rtg> infinity, keep it sime, don't confuse people
[22:17] <rtg> simple*
[22:17] <infinity> rtg: You could have just shortened that to "WTF?"
[22:18] <rtg> infinity, I think what happened is that APM got added during the trusty dev cycle after the utopic repo was opened and I forgot to forward port all of the mustang build bits.
[22:19] <infinity> Curse rebases and the lack of useful history. :/
[22:19] <infinity> 'git log debian.master/d-i/firmware/kernel-image' is the most useless thing ever.
[22:21] <infinity> Anyhow, I guess that will be building all evening on armhf, so I'll get you a d-i upload late tonight.
[22:22] <rtg> infinity, thanks
[22:22] <infinity> rtg: Had to fix three other arches anyway.


[13:32] <dal_> Having a lot of trouble getting cairo-dock/glx-dock to do what I want to do - I like everything about the quick browser plugin other than that if I click on a directory in it it opens that directory in gwenview (?) and if I click a video file it launches in smplayer. These associations don't line up with my current desktop environment or any other currently installed on my machine and there's no mention of either application in the
[13:32] <dal_> .conf files for the quick browser plugin or cairo-dock as a whole under ~/.config. Is anyone able to give me an idea where cairo-dock might be getting these associations from?
[15:51] <nacc> dal_: wrong channel?
[15:58] <dal_> what's the right one?
[15:58] <dal_> cairo-dock is in the ubuntu repositories, that's where I got it from
[16:00] <powersj> o/
[16:00] <jgrimm> o/
[16:00] <cpaelzer> hiho
[16:00] <cpaelzer> o/
[16:00] <cpaelzer> I think I'm the one that has to pull up the cheat sheet today
[16:00]  * cpaelzer opening KB
[16:00] <powersj> yar
[16:01] <cpaelzer> #startmeeting ubuntu-server-team
[16:01] <meetingology> Meeting started Tue Mar  7 16:01:45 2017 UTC.  The chair is cpaelzer. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <nacc> o/
[16:02] <cpaelzer> ok, seo helle overybody - lets start as usual with
[16:02] <rharper> o/
[16:02] <cpaelzer> #topic Review ACTION points from previous meeting
[16:02] <caribou> \o
[16:02] <rbasak> o/
[16:02] <cpaelzer> first was "ACTION: nacc to ping release team on removing src:postgresql-9.6 and src:php7.1"
[16:02] <cpaelzer> nacc: I know about one of them
[16:02] <cpaelzer> could you elaborate on both?
[16:03] <nacc> both are done
[16:03] <cpaelzer> yay
[16:03] <smoser> o/
[16:03] <nacc> well, the first by migrating postgresql-9.6 in
[16:03] <nacc> so 'done', albeit differently than the action ;)
[16:04] <cpaelzer> ok, so the next one would be powersj
[16:04] <cpaelzer> ACTION: powersj to see about getting the lxd team onto torkoal
[16:04] <powersj> done
[16:04] <cpaelzer> yay#2
[16:04] <powersj> stgraber helped clean things up
[16:04] <cpaelzer> I remember
[16:04] <jgrimm> any idea how it got so borked up?
[16:04] <cpaelzer> powersj: do we already have an understanding how it could happen?
[16:04] <jgrimm> :)
[16:05] <powersj> jumping between versions of lxd and not cleaning everything up
[16:05] <cpaelzer> I happen to know that it can break without that
[16:05] <cpaelzer> but
[16:05] <powersj> true :)
[16:05] <cpaelzer> I'm fine to ait until it happens
[16:05] <cpaelzer> "wait" rather
[16:05] <powersj> and we did see that one failure, and then it went away
[16:05] <cpaelzer> ok, thank you powersj
[16:05] <cpaelzer> for now all are unblocked and the action is done
[16:06] <cpaelzer> number 3: ACTION: rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has
[16:06] <cpaelzer> I did nothing, did anybody start on that?
[16:06] <powersj> nope... sorry
[16:06] <cpaelzer> rbasak: ?
[16:07] <cpaelzer> lets take that as a no and keep the action for next week as well
[16:07] <cpaelzer> #ACTION: rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has
[16:07] <meetingology> ACTION: : rbasak, powersj, cpaelzer to draft mysql triage response page like nginx has
[16:07] <rbasak> I haven't started on it, sorry. Please carry forward.
[16:07] <cpaelzer> #topic Zesty Development
[16:07] <cpaelzer> #link https://wiki.ubuntu.com/ZestyZapus/ReleaseSchedule
[16:08] <cpaelzer> anything general before we go to blueprint and bugs?
[16:08] <jgrimm> i don't have anything
[16:08] <cpaelzer> ... well I have :-)
[16:08] <jgrimm> go for it
[16:08] <cpaelzer> fyi - if you happen to be blocked on ppc based test verification fails based on encryption
[16:08] <cpaelzer> (as I was)
[16:08] <cpaelzer> consider checking if it could be the following bug
[16:09] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670311
[16:09] <cpaelzer> TL;DR various crypto options fail with current 4.10 kernel
[16:09] <cpaelzer> but fix is known and enqueued
[16:09] <jgrimm> interesting. thanks
[16:09] <cpaelzer> so no need to bother the kernel Team more than I already did
[16:10] <cpaelzer> btw kernel Team, pinging smb for later
[16:10] <cpaelzer> #subtopic blueprints
[16:10] <cpaelzer> #https://blueprints.launchpad.net/ubuntu/+spec/servercloud-z-server-core
[16:10] <cpaelzer> #link #https://blueprints.launchpad.net/ubuntu/+spec/servercloud-z-server-core
[16:11] <cpaelzer> I saw some updates there
[16:11] <cpaelzer> #link https://blueprints.launchpad.net/ubuntu/+spec/servercloud-z-server-core
[16:11] <cpaelzer> any of those calls should do :-/
[16:11] <cpaelzer> is there anything big outstanding that one wants to discuss?
[16:11] <rbasak> Remember to keep up the meetingology commentary to save writing minutes later.
[16:11] <cpaelzer> I take this as a no, and will go on
[16:12] <cpaelzer> thanks, true
[16:12] <cpaelzer> #info blueprint looks good, no active major items outstanding
[16:13] <jgrimm> indeed, very happy with how much we got done this cycle. and jumping on it early
[16:13] <cpaelzer> #info cpaelzer gave an FYI on a ppc64el crypto bug in 4.10 that might block dep8 tests
[16:13] <cpaelzer> #subtopic Release Bugs
[16:13] <cpaelzer> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-z-tracking-bug-tasks.html#ubuntu-server
[16:13] <cpaelzer> I can say that I submitted a pack of new versions - DPDK (Stable release), New Qemu (CVE/Log fix), Libvirt (device format, apparmor for virt-manager)
[16:13] <cpaelzer> anything on the list of open issues you want to go into?
[16:14] <cpaelzer> any majore bvugfix uploads to zesty happened last week?
[16:14] <cpaelzer> wow typo-master 2000
[16:15] <cpaelzer> I heard rharper and smoser talk about bug 1670481 yesterday
[16:15] <cpaelzer> which is on that list
[16:15] <cpaelzer> I triaged and started the discussion with IBM
[16:15] <cpaelzer> but I think it might be an SRU deadlock
[16:15] <rharper> cpaelzer: +1
[16:15] <cpaelzer> either it is important enough to be an SRU, but then it changes behaviour and does not qualify
[16:15] <cpaelzer> or not ...
[16:15] <jgrimm> has upstream accepted it?
[16:15] <rharper> I don't think so
[16:15] <cpaelzer> upstream accepted
[16:15] <rharper> it's just a patch at this point
[16:15] <rharper> really?
[16:15] <cpaelzer> it is in 2.9
[16:16]  * rharper goes home
[16:16] <cpaelzer> so we have forward order up to qemu 2.4
[16:16] <jgrimm> ok, i was going to be -1 if it wasn't upstream
[16:16] <cpaelzer> 2.5-2.8 reverse
[16:16] <cpaelzer> and then forward again
[16:16] <rharper> well, let's just say that the churn will hopefully encourage folks to not rely on it
[16:16] <cpaelzer> that for sure
[16:16] <cpaelzer> and I'm ok pulling into zesty (as a pre-2.9)
[16:17] <cpaelzer> but SRU they have to be pretty convincing
[16:17] <cpaelzer> not yet
[16:17] <rharper> right
[16:17] <jgrimm> ack
[16:17] <cpaelzer> #info cpaelzer elaborated on the pro/con of bug 1670481
[16:17] <cpaelzer> #info no other "big issues" on there for now
[16:18] <cpaelzer> #info zesty fix uploads to dpdk, qemu, libvirt last week
[16:18] <jgrimm> was is that lookup failing?
[16:18] <cpaelzer> anything else?
[16:18] <jgrimm> ubottu you are failing us
[16:18] <cpaelzer> jgrimm: sometimes it fails
[16:18] <jgrimm> :)
[16:18] <cpaelzer> #topic Server & Cloud Bugs & SRU/Pending Uploads (caribou)
[16:19] <cpaelzer> caribou: your time
[16:19] <cpaelzer> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server
[16:19] <caribou> Here are the SRU we're looking ata :
[16:19] <caribou> #info STS SRU are pending for :sssd, gtk+3.0, nfs-utils, multipath-tools, sosreport, tftp-hpa
[16:19] <cpaelzer> thanks, I also sponsored a libvirt (trusty) one from STS
[16:20] <cpaelzer> also nacc you might be happy to hear that I tested and finally sponsored that azure fix into xenial
[16:20] <rbasak> I've just been looking at tftp-hpa for you caribou, but I started with wanting a git tree to do diffs and the import is failing. I'm currently in that rabbithole :)
[16:20] <cpaelzer> waiting for the SRU tema
[16:20] <nacc> cpaelzer: ah excellent! Odd_Bloke will be happy :)
[16:20] <Odd_Bloke> \o/
[16:21] <cpaelzer> anything else for caribou or in-Release SRUs ?
[16:21] <caribou> rbasak: good thanks. why don't you diff the src pkg ?
[16:22] <cpaelzer> #info rbasak looking into tftp-hpa currently, but git import is blocked
[16:22] <rbasak> caribou: I can do that, sure. But then I have to fetch things I want to diff against piecemeal. Using git everything is easier :-)
[16:22] <rbasak> If I can't fix it soon, then sure I'll do it by hand.
[16:22] <caribou> rbasak: indeed
[16:22] <cpaelzer> ok, moving on to powersj then
[16:22] <cpaelzer> #topic Weekly Updates & Questions for the QA Team (powersj)
[16:23] <cpaelzer> #link https://jenkins.ubuntu.com/server/
[16:23] <powersj> Debug lots of test failures last week, bit of curtin vmtest development for daily tests, and got test systems back to sane status. All tests were green over the weekend. Trusty ppc64el ISO testing is also now functional.
[16:23] <powersj> If I get access to staging.launchpad.net I want to work on auto landing for curtin and cloud-init. Untill then I have a few jenkins test related items I need to clean up, look into cloud-init to understand more about how setup.py is setup, as well as triage today and some bug work.
[16:23] <powersj> And as of yesterday, we finally have cloud-init ci tests up and running again \o/
[16:23] <cpaelzer> powersj: gz
[16:24] <cpaelzer> powersj: was the debugging to debug the tests or test-env, or into issues they uncovered?
[16:24] <jgrimm> powersj, \o/
[16:24] <powersj> cpaelzer: mix of both, we had the lxd issues, which I filed two bugs against lxd and got fixes for, but also the system getting borked
[16:25] <cpaelzer> ok powersj
[16:25] <powersj> plus downreving lxd found some issues with our curtin vmtest daily job, so had to fix those up withsmoser
[16:25] <cpaelzer> getting better every time
[16:25] <powersj> yes time to go break more stuff then and write more tests ;)
[16:25] <jgrimm> it should also be noted that the ppc64el ISO testing is Not Yet gating.  That is next.
[16:26] <cpaelzer> fyi I also experimented with avocado a bit (qemu testing) but that is unessesarily complex for what you want to do
[16:26] <cpaelzer> so not jumping on it right now
[16:26] <powersj> that was my assessment as well :)
[16:26] <cpaelzer> #info powersj fixed a lot of issues, most tests are green again
[16:27] <cpaelzer> #info cloud-init and curtin tests up and running again
[16:27] <cpaelzer> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee)
[16:27] <smb> Not much to report. The bcache naming should be fixed soonish (or maybe has) there was something cpaelzer had which I forgot about.
[16:27] <rharper> \o.
[16:27] <rharper> smb: thans
[16:27] <cpaelzer> smb: I reported on the ase-xts thing before
[16:27]  * rharper 's keyboard needs a new battery
[16:27] <cpaelzer> Oh that is a good excuse rharper
[16:27] <cpaelzer> mine too
[16:27] <rharper> hehe
[16:27]  * cpaelzer has no keyboards with batteries
[16:28] <smb> cpaelzer, oh that... think I saw other people of the team being aware
[16:28] <cpaelzer> great
[16:28]  * rbasak keeps his keyboard in the same place, and it has a cord :-)
[16:28] <cpaelzer> #info bcache issues fixed soonish (blocked some server related work)
[16:28] <rbasak> This approach does make for a desk covered in cables though :-/
[16:29] <cpaelzer> I can't choke people without - and I want to so do so often
[16:29] <cpaelzer> maybe it is good to be in home office :-P
[16:29] <cpaelzer> anyway, back to business
[16:29] <nacc> dark
[16:30] <cpaelzer> #topic Upcoming Call For Papers
[16:30] <cpaelzer> #link https://lwn.net/Calendar/Monthly/cfp/
[16:30] <cpaelzer> anything else anybody which is worth to be mentioned here?
[16:30] <cpaelzer> #info no CFPs to consider at the moment
[16:30] <cpaelzer> #topic Ubuntu Server Team Events
[16:31] <cpaelzer> nothing scheduled soon I'd know about
[16:31] <jgrimm> ditto
[16:31] <cpaelzer> jgrimm: do we have anything I forget?
[16:31] <cpaelzer> ach you were fast
[16:31] <cpaelzer> ok
[16:31] <jgrimm> :)
[16:31] <cpaelzer> #info no events scheduled
[16:31] <cpaelzer> #topic Open Discussion
[16:31] <cpaelzer> release all you have held back
[16:31] <nacc> i had a thought for something we could do to encourage community participation
[16:31] <nacc> we just crested 400 bugs in the backlog
[16:32] <nacc> i'd like to propose on the ML a monthly bug-squashing day
[16:32] <nacc> on #ubuntu-server, esp. to get community folk who are interested in taking bitesize
[16:32] <cpaelzer> nacc: I think the day would be great
[16:32] <rbasak> That's a great idea.
[16:32] <powersj> +1
[16:32] <nacc> we can walk folks through using the git tree(s), submitting bugs, asking for sponsorship (and we'd have several of us available throughout the day for that )
[16:32] <cpaelzer> nacc: yet we have to consider the usual can of worms to track that to completion
[16:33] <nacc> of course, but I think the benefit might outweigh it -- and i fear we are too afraid of that and now there is no community participation
[16:33] <cpaelzer> we should just plan at least for us to have the time for that post work
[16:33] <nacc> except for filing more and more bugs that we never get to :/
[16:33] <cpaelzer> nacc: oh I'm clearly +1
[16:33] <jgrimm> do you think you want to get people pre-signed up?  or just randomly show up?
[16:34] <nacc> jgrimm: i think unstructured at first. I think people can subscribe to bugs if they want, and can bring them up in the channel.
[16:34] <nacc> jgrimm: my plan in my e-mail was to specifically call out server-next and bitesize as tags
[16:34] <jgrimm> np, we can learn as we go too
[16:34] <nacc> i think they are not well broadcasted currently
[16:34] <nacc> or maybe they were, but it's been a while, etc.
[16:34] <nacc> and the contributions can even just be helping with testing in various enviroments
[16:35] <nacc> which teaches people how to use lxd, kvm, etc.
[16:35] <nacc> (uvtool...)
[16:35] <nacc> i think all of which is beneficial for both our team and our product(s)
[16:35] <jgrimm> so one thing that sort of came up with rbasak is that given where we are at in the cycle.. some valid fixes, we may still want to hold off on until the beginning of next cycle.. so think about what to do with those type of fixes
[16:35] <nacc> right, i'm assuming most people in this context can't upload
[16:35] <jgrimm> ^^ in context to sponsorship day he floated a couple week ago
[16:36] <nacc> but yeah
[16:36] <cpaelzer> #info nacc proposed the idea of a community wide monthly bug-squash day
[16:36] <cpaelzer> ok to go on for today?
[16:36] <nacc> yep
[16:36] <cpaelzer> #topic Announce next meeting date, time and chair
[16:37] <cpaelzer> nacc: will be next weeks chair
[16:37] <cpaelzer> nacc: ok ?
[16:37] <nacc> cpaelzer: ack
[16:37] <cpaelzer> next tuesday is 14th of march
[16:37] <cpaelzer> see you all here then
[16:37] <cpaelzer> #info next chair on 14th march will be nacc
[16:37] <cpaelzer> #endmeeting
[16:37] <meetingology> Meeting ended Tue Mar  7 16:37:51 2017 UTC.
[16:37] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-03-07-16.01.moin.txt
[16:37] <powersj> thanks cpaelzer
[16:37] <nacc> cpaelzer: thanks!
[16:43] <cpaelzer> rbasak: I missed that in the past - what is the command to get fromt he txt log to html log?
[16:43] <cpaelzer> I assume there is a tool or similar to do so
[16:44] <rbasak> cpaelzer: I just tweak the extension. s/moin.txt/html/
[16:45] <cpaelzer> rbasak: thanks
[16:45] <cpaelzer> rbasak: other than the triple action it is good
[16:46] <cpaelzer> rbasak: and we are three people, so that is somewhat fine :-)
[16:46] <rbasak> Yeah it's a bit weird how it handles actions
[16:46] <cpaelzer> I just would have expected some feeback on my action setting
[16:46] <cpaelzer> but it is good
[16:46] <rbasak> It doesn't know who has the action, so lists against all mentioned nicks, which I don't find particularly helpful.


[05:26] <valorie> the beta 2 story is roughed out, acheronuk
[05:26] <valorie> marco has already made https://wiki.kubuntu.org/BionicBeaver/Beta2/Kubuntu
[05:26] <valorie> \o/
[05:26] <valorie> so we should be ready
[05:26] <valorie> I hope
[09:06] <ricktimmis[m]> Excellent, very pleased to see Muon being shipped as standard.
[09:25] <acheronuk> yeah. discover is getting better, but a proper/old style gui package manager is a must IMO
 TBH Discover is an updater which works fine.
[21:33] <valorie> it usually works fine for me in artful
[21:33] <valorie> occasionally gets stuck looking for more updates
 Yeah it's fine so far in bionic.
[21:35] <valorie> good
[21:35] <valorie> I should start up the travel lappy and provision it for testing
[21:35] <valorie> which means doing some backups here first!
[21:49] <tsimonq2> https://lubuntu.me/this-week-in-lubuntu-development-1/


[01:45] <Hydr0p0nX> k
[01:46] <Hydr0p0nX> so i'm getting ready to order a new video card to go with this new build
[01:51] <Hydr0p0nX> nvidia gtx650 or newer should be sufficient for vdpau playback, right?


[16:38] <joh> Hello, I was wondering whether I could get some feedback on some UI improvements I'm planning for Alarm Clock: http://live.gnome.org/AlarmClock/Blueprints/BetterUI
[16:38] <joh> If this is not the right place to ask, please let me know...
[16:51] <mac_v> joh: ayatana is only for notify-osd and stuff , but since its low volume or rather no volume room , anything goes :)
[16:51] <joh> mac_v: Oh ok :)