[00:05] <ochosi> bluesabre: ok, merged and fixed some things
[00:05] <bluesabre> oh hey ochosi
[00:05] <ochosi> now i gotta get some rest though :)
[00:06] <bluesabre> ochosi: so, should I wait until tomorrow before packaging that?
[00:08] <ochosi> bluesabre: not sure i'll get to more updates very soon
[00:08] <ochosi> the rest of the week is rather busy
[00:09] <knome> ochosi, could you try to get to the media manager *at latest* next week?
[00:09] <knome> ochosi, i'm planning to publish it in week 13, which is the week next to next week
[00:09] <bluesabre> ochosi: I'll wait until tomorrow to be safe
[00:10] <bluesabre> knome: wp contest ready?
[00:10] <knome> bluesabre, hur dur
[00:10] <knome> trying to get some time tomorrow to do that...
[00:10] <knome> ochosi, anything specific on the icons that you think need more attention btw?
[00:10] <bluesabre> knome: :D
[00:11] <ochosi> knome: i guess more symlink checking and looking into the bigger discreptancies
[00:11] <ochosi> it's not too bad
[00:11] <ochosi> i guess now the best way is just using/testing it
[00:11] <knome> right
[00:11] <ochosi> and then we can fix the ones that hurt the most
[00:12] <ochosi> but yeah, as i said, shouldn't be bad at all
[00:12] <ochosi> (awesome, i already receive bugreports for greybird not working with gtk3.19)
[00:12] <knome> (:
[00:14] <ochosi> knome: i'll try, can't promise though
[00:14] <ochosi> now i need some sleep
[00:14] <ochosi> night everyone!
[00:14] <knome> sigh :P
[00:14] <knome> nighty
[00:14] <bluesabre> night ochosi
[01:03] <bluesabre> knome: if you want to be extra nudgey tomorrow, https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1555046 :)
[01:03] <knome> mhm
[01:10] <bluesabre> knome: so, this is more of a wontfix, what should I mark it? [xubuntu-dev] Remove xfce4-volumed from the seed: TODO
[01:14] <knome> drop it
[01:14] <knome> unless you want to change it to something that is more like investigating the options
[01:16] <bluesabre> dropping
[01:16] <bluesabre> :)
[01:23] <knome> time to go to bed
[01:23] <knome> have a nice evening and ttyl
[01:26] <bluesabre> nighty knome
[07:33] <flocculant> Unit193: don't know if you expect the zsyncs to work - but they don't :)
[07:34] <Unit193> Eh?
[07:35] <Unit193> zsync http://unit193.net/xubuntu/core/pending/xubuntu-16.04-core-amd64.iso.zsync  ?
[07:45] <flocculant> yup both failed here
[07:46] <flocculant> could not read control file from URL https://unit193.net/xubuntu/core/pending/xubuntu-16.04-core-i386.iso.zsync
[07:46] <flocculant> anyway - that's not too much of an issue
[07:46] <flocculant> the installer crashed (64bit) - says it's going to do it's thing to report it - doesn't
[07:47] <flocculant> there was a window with some python fail lines in it - which appeared to all be ubiquity things - too early in the morning to do more than 'meh' and reboot :)
[07:48] <flocculant> didn't run apport properly
[07:52] <Unit193> flocculant: OK, thanks for checking.  And yeah that's expected with https, zsync doesn't know how to do https.
[07:53] <flocculant> aah cool
[07:55] <flocculant> Unit193: when I'm back later and awake I'll have another go and see what information I can grab
[13:09] <flocculant> Unit193: colour me stupid ... but why doesn't your image have ubiquity?
[13:11] <flocculant> knome: did you push the slideshow change? re ready to go list that is
[13:11] <flocculant> and we just need that dealt with to update it?
[13:26] <flocculant> bluesabre: so I noticed this ... livesession > breeze icons, once installed > elementary
[13:26] <flocculant> lying
[13:26] <flocculant> installed > galaxy
[13:27] <flocculant> listed in Options as the Automatic choice
[13:28] <flocculant> updated bug 1548647
[17:42] <flocculant> Unit193: couldn't do much in the livesession - have sent you logs from after the installer crashed
[17:53] <flocculant> tried 32 bit on the offchance - note tried :)
[18:55] <Unit193> flocculant: Bah, OK.  Thanks.
[18:55] <Unit193> printing-scanning.xml:157: element xref: validity error : Syntax of value for attribute linkend of xref is not valid
[18:55] <Unit193> printing-scanning.xml:157: element xref: validity error : IDREF attribute linkend references an unknown ID "Impressão em rede"
[18:55] <Unit193> Document pt/index.xml does not validate
[18:57] <knome> flocculant, yes, i pushed the change so it looks as it should now
[18:58] <knome> flocculant, and we just need an upload to get it right
[18:59] <kryten> Unit193: Thanks.  slickymaster: Such a fail there, LOL - https://translations.launchpad.net/xubuntu-docs/xenial/+pots/user-docs/pt/86/+translate
[18:59] <flocculant> knome: okey doke - thought that was the case - just checking :)
[19:00] <knome> yep, np
[19:02] <flocculant> well - that and booting the image prompted me to try and remember and failing :D
[19:02] <flocculant> Unit193: yep - not sure what's going on there - obviously apport doesn't fire
[19:02] <Unit193> flocculant: Crashes on startup?
[19:03] <Unit193> Looks like locale problem, which is why I wouldn't see it.
[19:03] <flocculant> Unit193: from memory it copies files - then as soon as the next bit starts - crash
[19:04] <flocculant> Unit193: ok - so if I set to US it would run?
[19:04] <flocculant> happy to test that
[19:11] <Unit193> Seeing if I can get it to do it.
[19:11] <flocculant> ok
[19:11] <flocculant> shout if you want me to try anything - only takes a few minutes
[19:16] <Unit193> Well, while this is running, if you have an ISO of the desktop handy and could boot into live and run  locale -a  that'd likely be handy, but only if you can do so without trouble.
[19:16] <flocculant> enough in a vm?
[19:16] <Unit193> Yes.
[19:16] <flocculant> k
[19:17] <Unit193> And  cat /etc/default/locale ?
[19:19] <flocculant> http://i.imgur.com/R31V6L7.png
[19:19] <Unit193> Right, that's what I saw.  Figuring that's not the same on the desktop images.
[19:20] <flocculant> 2 secs
[19:23] <flocculant> excuse font size on the desktop image - small to get it all in http://i.imgur.com/Zc3F6Z6.png
[19:24] <knome> readable..
[19:35] <Unit193> That is awesome http://u193.ga/c/qd2i
[19:36] <flocculant> After the problem report has been sent, please fill out the form in the automatically opened web browser is good - no browser, nothing opened :p
[19:37] <flocculant> oh - in a vm I get the ubi-language failed dooby
[19:38] <Unit193> I don't think that's really important, was a bit surprised /etc/default/locale had en_US on desktop though, would have expected either more generic or en_GB.
[19:40] <flocculant> Unit193: the normal live stuff always defaults to US for some reason
[19:40] <flocculant> always has iirc
[19:42] <Unit193> Installed firefox, re-running.
[19:51] <Unit193> Well this is going well..
[21:46] <bluesabre> flocculant: probably related to the changes that were pushed for fontconfig and pending for pango
[21:48] <bluesabre> or maybe not
[21:48] <bluesabre> folks just commenting on bugs to comment, it seems
[21:48] <bluesabre> :)
[22:10] <ochosi> bluesabre: ok, so no more icon changes from my side
[22:10] <ochosi> already pushed the delta upstream, where it was warmly received :)
[22:11] <bluesabre> ochosi: great!
[22:12] <bluesabre> ochosi: if you want to update lp:xubuntu-artwork as well, I'll def. package it tonight
[22:13] <bluesabre> (I'll have to file the UIFe for it as well, but that's no biggie)
[22:18] <ochosi> bluesabre: already on it
[22:19] <bluesabre> ochosi: you da man
[22:19] <knome> ...huh
[22:19] <bluesabre> hey knome
[22:19] <bluesabre> having fun?
[22:20] <knome> watching football
[22:20] <ochosi> knome: lucky you, i don't receive a channel that shows one of the CL games...
[22:20] <bluesabre> woo
[22:21] <ochosi> bluesabre: committed pushed and done
[22:21] <knome> atletico madrid - psv einhoven
[22:21] <bluesabre> ochosi: thanks
[22:21] <ochosi> well, thank you!
[22:21] <knome> 2nd leg, 0-0 aggregate, now on penalties
[22:28] <ochosi> ok, gotta get some sleep
[22:28] <ochosi> night everyone
[22:31] <slickymaster> I see no need in keeping it, knome
[22:32] <slickymaster> since we already have the contributor docs with all the info
[22:32] <slickymaster> and the w.x.o
[22:33] <knome> keeping what?
[22:33] <knome> :P
[22:34] <slickymaster> https://wiki.ubuntu.com/Xubuntu/Documentation
[22:34] <slickymaster> sorry
[22:34] <knome> it's moved already though
[22:34] <slickymaster> yeah, I know
[22:35] <slickymaster> but I thought you'd like my feedback in the channel
[22:35] <knome> if you want, you can drop the page
[22:35] <slickymaster> bureaucracy
[22:35] <slickymaster> will do it later
[22:35] <knome> but then please redirect the w.u.c page to some other location
[22:35] <slickymaster> want to review flocculant's MP, firts
[22:36] <slickymaster> * first
[22:54] <bluesabre> knome, slickymaster, going to make a UIFe bug for the new mime icons when I get back home. Should just need a single ack
[22:54] <knome> yes
[22:54] <knome> bluesabre, docs is fine with that.
[22:54] <knome> xubuntu and ubuntu, if it matters.
[22:58] <slickymaster> go ahead bluesabre
[22:59] <bluesabre> Probably needs to be on the bug, or maybe not
[22:59] <knome> tell me when the bugis done
[22:59] <bluesabre> Or I can just upload and ask questions later
[22:59] <slickymaster> that won't be a problem bluesabre, ;)
[22:59] <bluesabre> knome, will do. Out for dinner now, bbabl
[23:00] <knome> bon appetit
[23:00] <slickymaster> enjoy bluesabre
[23:35] <bluesabre> back
[23:35] <Unit193> Front.
[23:38] <bluesabre> Side
[23:56] <bluesabre> knome, slickymaster: https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1557803
[23:57] <knome> done
[23:57] <slickymaster> thanks bluesabre, knome
[23:58] <bluesabre> knome: danke
[23:58] <knome> bitte


[11:49] <jelmer> allenap: :-)
[12:26] <jelmer> allenap: When you're done reviewing your lunch options, any chance I can add two more branches to your queue?
[13:40] <bac> hi sinzui
[13:40] <sinzui> hi bac
[13:40] <bac> sinzui: could you have a look at the diff i just pasted to https://code.edge.launchpad.net/~bac/launchpad/bugjam-579502/+merge/44302
[13:40] <bac> i'd like to send this off to ec2 soon
[13:46] <sinzui> bac: I see you changed  _known_viewers() to ensure that owner have access
[13:46] <bac> sinzui: yes, i wanted your feedback specifically on that approach.
[13:46] <sinzui> bac: I see it always returns a set, but the doc string says dict
[13:46] <bac> it seemed the least intrusive
[13:47] <sinzui> I think we should fix the doc string
[13:47] <bac> good catch!
[13:47] <sinzui> bac: will that be the same spot to add drivers, and bug supervisors?
[13:48] <bac> sinzui: with some careful review I think it might.
[13:49] <sinzui> I think I will look at that method in january
[13:50] <sinzui> bac; you are aware that the owner can only assign teams he is a member of to the bug supervisor role?
[13:51] <bac> sinzui: i am but i don't see how that relates.  what am i missing?
[13:52] <sinzui> Every believes the owner can private bugs. But that is not true since he can leave the team, he could change the team, but that new team will not be subscribed to the bugs...
[13:52] <sinzui> Your change makes Lp work as users expect...even Canonical employees
[13:56] <bac> ah, a subtly i missed
[13:56] <bac> er subtlety
[13:58] <bac> sinzui: so, landable?
[13:58] <sinzui> yes please
[14:08] <allenap> jelmer: Certainly :)
[15:13] <leonardr> allenap, jcsackett, i have an launchpadlib branch coming up that's oversize, but mostly due to method renames
[15:14] <allenap> leonardr: Okay, I can take a look at that.
[15:15] <leonardr> will let you know once i write mp
[15:53] <jcsackett> bac: can you follow up on https://code.launchpad.net/~jelmer/launchpad/693757-py2.7-compat/+merge/44566 for me?
[15:53] <bac> jcsackett: sure
[15:53] <jcsackett> thanks.
[16:17] <leonardr> allenap: https://code.launchpad.net/~leonardr/launchpadlib/separate-login-for-cronjob/+merge/44592
[16:19] <allenap> leonardr: It says there's a conflict in src/launchpadlib/tests/test_launchpad.py
[16:24] <henninge> jcsackett: Hi! I have to leave now but it would be great if you could look at my MP. It's fairly straight forward UI stuff.
[16:24] <jcsackett> henninge: i can look at the code portion, but i'm not a ui reviewer.
[16:24] <henninge> jcsackett: that's fine
[16:25] <henninge> https://code.launchpad.net/~henninge/launchpad/devel-bugjamming-2/+merge/44590
[16:25] <henninge> thank you!
[16:25] <jcsackett> henninge: no problem.
[16:42] <leonardr> allenap: hmmm, i just updated, let me check
[16:42] <leonardr> ah, i updated but didn't merge
[16:56] <allenap> leonardr: Cheers.
[16:56] <leonardr> allenap: should be fixed now
[17:35] <jcsackett> bac: can you follow up on https://code.launchpad.net/~henninge/launchpad/devel-bugjamming-2/+merge/44590 for me, when you get a chance?
[17:35] <bac> jcsackett: ok
[17:35] <jcsackett> thanks.
[17:48] <bac> jcsackett: done
[17:52] <jcsackett> bac, thanks. :-)
[17:52] <jcsackett> although, on the MP, i see that sinzui is still doing reviews, so perhaps i can stop bothering you and pester him.
[19:18] <jcsackett> sidnei: it works better to get reviewers attention if you leave a message in the room with the MPs and put your name in the queue than just throwing the MPS in the queue in the channel info.
[19:22] <jcsackett> i've got to run out to lunch, i'll be back here for reviews in a bit.
[19:48] <sidnei> jcsackett, i  couldn't remember which way it was, thanks!
[21:19] <jcsackett> bac: i've done sidnei's first MP: https://code.launchpad.net/~sidnei/lazr-js/static-resource-prefix/+merge/44271. can you follow up?


[00:00] <biobunsai> happy bacon back at ya
[00:11] <SamuraiAlba> How is it going?
[00:43] <InHisName1> mouth watering for a nice BLT, SamuraiAlba
[00:59] <waltman> SamuraiAlba: did you see today's xkcd?
[01:48] <SamuraiAlba> no y?
[01:49] <SamuraiAlba> ROFL just saw
[01:49] <SamuraiAlba> !!!
[01:49] <SamuraiAlba> LOL
[01:53] <waltman> no y?
[02:34] <SamuraiAlba> I saw it.  it rocked
[05:04] <uBUXUBu> i wasborn in pa
[09:58] <JonathanD> Morning.
[10:29] <rmg51> morning JonathanD
[10:30] <JonathanD> hey
[10:31] <rmg51> yo
[10:32] <rmg51> off to do my shopping
[11:15] <waltman> morning
[14:26] <rmg51> I'll probably regret doing this, but it looks like it's time to upgrade this laptop to 12.04
[14:26] <rmg51> talk to the bear
[15:34] <teddy-dbear> wow, only 20 hours left for the upgrade =-O
[15:46] <teddy-dbear> time flies when your doing an upgrade
[15:46] <teddy-dbear> only 9 hours left
[17:59] <SamuraiAlba> Good bacon to all!
[18:01] <teddy-dbear> o/
[18:03] <SamuraiAlba> How is you?
[18:05] <teddy-dbear> I'm just hanging around watch a laptop upgrade to 12.04
[18:07] <InHisName1> Glad you have such a thrilling day, teddy-dbear
[18:08] <teddy-dbear> :P
[18:15] <InHisName1> ubuntu should have a small window with a game to piddle around with to keep one occupied during upgrade, heh teddy-dbear
[18:15] <InHisName1> Maybe a honey-pot game, maybe ?
[18:16] <teddy-dbear> or just watch a movie
[18:22] <InHisName1> Can you get movies on your Dick Tracy police watch?
[18:25] <teddy-dbear> don't have a Dick Tracy police watch
[18:26] <teddy-dbear> but you can buy me one if you want
[18:29] <SamuraiAlba> I am about to NUKE Windows on the "halftop" (missing screen, bezel, hinges, etc)
[18:30] <SamuraiAlba> Just gonna XBMC it :)
[18:30] <SamuraiAlba> XBMCBUNTU
[18:30] <SamuraiAlba> I have to RDP into 20 PCs today LOL
[18:31] <SamuraiAlba> first...   It's nice for the convienience
[22:49] <SamuraiAlba> www.sweissman.com
[22:49] <SamuraiAlba> I'll jusst leave that there...
[22:49] <SamuraiAlba> and pray no one vomits..


[00:31] <batibot31> Hi guys anyone has a tablet windows and used ubuntu for os?
[10:39] <raph_ael> hello, what is the future for ubuntu for phones now ?
[10:40] <daker> raph_ael: https://plus.google.com/+MarkShuttleworthCanonical/posts/7LYubpaHUHH
[10:42] <k1l> there is ubports.com , unity8.org and even MIR will still be used by canonical for some IoT devices.
[11:24] <talonz> k1l, arnt both ubports and yunit planning to move from mir to wayland ?
[11:24] <k1l> its not set yet. but they might do that in the long run.
[11:27] <talonz> sooner the better imo
[11:56] <k1l> i dont know. canonical is known for making good code and mir looks like it  fits the needs. on the other hand wayland is not that perfect like we all wish it would be.
[11:57] <k1l> so having a working MIR solution until wayland gets better, sounds like a reasonable plan to me.
[11:58] <ogra_> well, there is a working mir solution right now :)
[11:58] <ogra_> just dont let it break
[11:58] <ogra_> and mir isnt dead either ... there will always be a mir-kiosk snap
[11:59] <ogra_> for which the basic code will be maintained ... the only thing you  would have to carry forward yourself is the libhybris bits
[12:00] <ogra_> i guess it really depends with what you want to go forward ... mir only on phones would surely work just fine ... i fear the desktop side of things will start to bit-rot though
[12:01] <ogra_> getting unity8 onto wayland will likely be close to a re-write
[12:04] <k1l> yes, sounds like that
[12:09] <raph_ael> daker: thanks
[12:11] <raph_ael> isn't jolia using wayland for their phones ?
[12:11] <ogra_> yup, they are
[12:12]  * k1l wonders how long jolla can take that road.
[12:12] <raph_ael> daker: interesting post but a bit vague
[12:13] <raph_ael> k1l: they don't have much choice :)
[12:14] <k1l> raph_ael: i mean from the financial perspective. even way bigger players struggled like hp with webOS or MS with their windowsphone. even samsung doesnt really want to ship tizen and sticks to android.
[12:15] <raph_ael> k1l: oh, it seems that Russia decided to make Jolia the official os for the administration phones
[12:15] <ogra_> well, just keeping the status quo should be hard for either ubuntu phone or jolla ...
[12:15] <raph_ael> or something like that
[12:15] <ogra_> *should not
[12:16] <raph_ael> I had almost all the dead phone OS, it seems I'm an indication for future dead projects :) (had a webos, openmoko, firefox os, and ubuntu phone)
[12:16] <ogra_> you will have to adjust bits here and there if anything changes with newer versions of dependencies ... but thats it
[12:17] <ogra_> so theoretically there is nothing blocking ubuntu phoes to persist ... you wont see any innovations though
[12:17] <k1l> ogra_: when was the last time you heard some selling guy say: we dont need innovations, just keep it stable :)
[12:18] <ogra_> but imho the OS is in a good enough condition to just keep it as is (and fix bugs eher and there) ... at least for enthusiasts thats enough
[12:19] <ogra_> well, i dont see a future for it as android replacement for the masses ... but for the crowd using an ubuntu phone today and for porting to more devices without massively changing it, it will be good enough
[12:21] <k1l> yeah
[12:25] <raph_ael> sounds a bit like a dead end
[12:27] <ogra_> surely nothing for forever ... but for a start you need to forus on the infrastructure more than on the OS itself ...
[12:27] <ogra_> you need a store (and preferably import all the apps from the canonical one), system-image server (which ubports already has) etc
[12:28] <ogra_> so i doubt the manpower to change the OS itself exists atm
[12:28] <ogra_> *focus
[12:43] <raph_ael> ogra_: if Canonical stops supporting it, it seems like a too huge task
[12:44] <ogra_> really depends what kind of community forms around it
[12:44] <ogra_> the point is to keep it alive long enough to see if thats actually happening
[12:49] <raph_ael> sure
[13:32] <tsdgeos> was a pleasure working for Canonical! /me waves
[13:41] <Flohack> Hi there! I am looking for verterok
[13:48] <dobey> i don't think he usually idles in here
[13:52] <Flohack> Ok thx
[14:10] <javier4> abeato: Good morning. :) Still no phone service here. I noticed that in mtk.c you managed the SUSPEND_REGISTRATION inside  .mtk_enable callback of the driver itself. While in mtk2 you suggested me to look at voicecall as an example, where all the stuff is managed inside voicecall atom's .probe through delayed_register though. Are you sure even registration
[14:10] <javier4> resuming can be issued the same way?
[23:48] <friendlyfool> hello
[23:48] <friendlyfool> hi


[10:05] <czajkowski> aloha
[10:06] <slashtom> morning
[10:06] <czajkowski> slashtom: hows you ?
[10:07] <slashtom> grand, how's the form?
[10:17] <czajkowski> great
[10:17] <czajkowski> love it
[10:17] <czajkowski> :D
[10:21] <slashtom> a step up from limerick? ;)
[10:23] <czajkowski> yeah
[10:23] <czajkowski> pretty interesting so far
[10:23] <czajkowski> still getting to grips what I'll be doing
[19:46] <airurando> evening all
[19:47] <airurando> tdr112: ping
[19:48] <czajkowski> aloha
[19:49] <airurando> czajkowski: hi there
[19:49] <czajkowski> airurando: hows things with you and the family
[19:49] <airurando> glad to see you are settling in across the pond :)
[19:49] <airurando> all good here
[19:50] <airurando> 2 weeks and 2 days till disneyland paris
[19:50] <czajkowski> awww fantastic
[19:50] <airurando> trying to catch tdr112 to see if he's OK for the open source in business thing tomorrow evening
[19:51]  * airurando is wondering if extra hands are needed
[19:52] <czajkowski> ahh
[19:52] <czajkowski> gutted am missing it
[19:52] <czajkowski> you going ?
[19:52] <airurando> not sure
[19:52] <airurando> If tdr112 could use an extra pair of hands I'd be happy to go
[21:04] <czajkowski> http://pad.ubuntu-ie.org/Punditry
[21:04] <czajkowski> anyone can add content to it
[21:04] <czajkowski> it's to  give some feedback t pc live magazine
[21:30] <ShaneM> czajkowski: How's the new job going? :)
[21:30] <czajkowski> great thanks
[21:31] <ShaneM> Great!
[21:31] <ShaneM> I saw on identi.ca your living with a deb person, what're the chances!
[21:32] <czajkowski> I know
[21:32] <czajkowski> :)
[21:33] <ShaneM> Hey did anyone head to the MeeGo con in Dublin today?
[21:33] <ShaneM> I was meant to go, but alas my funds are too low.
[21:37] <ebel> czajkowski: did you just look for "geek friendly accomodation"? :P
[21:37] <czajkowski> no
[21:37] <czajkowski> anyone want to help me out with http://pad.ubuntu-ie.org/Punditry
[21:37] <czajkowski> need to have it done by tomorrow
[21:37] <czajkowski> jot in any ideas
[21:37] <czajkowski> am pooed
[21:38] <czajkowski> pooped
[21:43] <ShaneM> I can try and help.
[21:44] <czajkowski> thanks
[21:45] <czajkowski> early mornings are making for a long day
[21:45] <ShaneM> Heh yeah
[21:54] <ShaneM> Hope what I've put there helps a little.
[21:55] <czajkowski> thanks
[21:55] <ShaneM> You can already see what i've written right? I don't need to save or anything?
[21:55] <ShaneM> Sorry, haven't used this before.
[21:56] <ShaneM> http://torrentfreak.com/irish-government-wants-file-sharing-compromise-or-legislation-will-follow-101115/ Don't really like the sound of this article.
[22:03] <ShaneM> Did google effectively kill etherpad and put the code into google docs? :(
[22:03] <popey> no
[22:03] <popey> etherpad is open source
[22:03] <popey> you can run your own etherpad instance
[22:04] <popey> ta-da! http://pad.ubuntu-uk.org/ :D
[22:04] <ShaneM> popey: Yeah but the further development is dead?
[22:07] <popey> no
[22:09] <ShaneM> Oh ok.
[22:09] <ShaneM> My bad.
[22:10] <popey> :)
[22:24] <czajkowski> ShaneM: I can see when you're writing stuff yuo
[22:25] <ShaneM> czajkowski: Cool. I've never used etherpad before :)
[22:26] <czajkowski> it's handy and you cna use it by just going to pad.ubuntu-ie.org and creating them
[22:26] <czajkowski> handy for note taking
[22:26] <ShaneM> Awesome :)
[22:26] <czajkowski> yup


[00:02] <mup> PR snapcraft#2291 closed: meta: put environment into runner instead of app wrapper <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2291>
[05:12] <mborzecki> morning
[05:50] <zyga> o/
[05:50] <zyga> I’m feeling somewhat better.
[05:51] <luk3yx> Hello
[05:55] <zyga> Hey
[05:56] <zyga> The store is fully operational again, great!
[06:01] <mborzecki> zyga: hey
[06:21] <mup> PR snapd#5805 closed: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5805>
[06:21]  * zyga is happy to land that
[06:25] <mup> PR snapd#5864 closed: make sure hostnamectl can be used on core too <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5864>
[06:38] <mup> PR snapd#5857 closed: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
[06:39] <mup> PR snapd#5840 closed: interfaces/apparmor, interfaces/builtin: tweaks for parallel snap installs <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5840>
[06:51] <mvo> 5571 should be an easy win (just needs a second review)
[06:54] <mborzecki> mvo: 5571 appears to be merged, did you mean another pr?
[06:54] <mborzecki> 5771 maybe?
[06:54] <mvo> mborzecki: yes, sorry
[06:54] <mvo> clearly more tea is needed :)
[07:04] <pstolowski> Morning
[07:06] <mup> PR snapd#5771 closed: selftest: add test to ensure selftest.checks is up-to-date  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5771>
[07:06] <zyga> mvo: trespassing fix is merged, shall I propose a PR to take layouts out of beta?
[07:07] <zyga> mvo: full disclaimer, I'm investigating a bug that is related to propagation settings
[07:07] <zyga> so perhaps not yet but then again, it would help a lot of people with simple layouts already
[07:08] <mvo> zyga: let do it
[07:08] <mvo> zyga: and we can wait with the merge until you finished your investigation
[07:08] <zyga> ok
[07:08] <mvo> zyga: but this way spread can run etc
[07:20] <mborzecki> nice to see the diff in #5596 so short, nearly all i had in the integration branch is now in
[07:21] <mup> PR #5596: [WIP] Parallel installs integration <Blocked> <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
[07:22] <mvo> mborzecki: hm, this looks like the integration PR juts contains some more tests, so time to merge those too?
[07:23] <mborzecki> mvo: i'll push those separately along with couple enhancements to other tests
[07:24] <mvo> mborzecki: cool
[07:24] <mborzecki> but first coffee
[07:35] <mup> PR snapcraft#2300 opened: [WIP] plugins: remove implicit source <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2300>
[07:41] <mup> PR snapd#5866 opened: tests: remove unneeded cleanup from layout tests <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5866>
[07:43] <mup> PR snapd#5867 opened: many: enable layouts by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5867>
[07:46] <zyga> mvo: ^ done
[07:51] <mvo> zyga: ta
[08:02] <mvo> zyga: hm, curious, why switching the default instead of juts removing the option entirely?
[08:02] <mvo> zyga: I mean, whats the use-case, someone who feels uncomfortable with layout should still be able to disable them?
[08:02] <luk3yx> If I make my snap private, will existing users continue getting updates?
[08:02] <luk3yx> And can people still install it by snap name?
[08:03] <luk3yx> (I want a semi-private snap so people download the "official" snap instead)
[08:03] <kyrofa> zyga, mvo do you guys have any thoughts on this? https://forum.snapcraft.io/t/snaps-are-broken-in-bionic-lxd-container/7339
[08:03] <mup> PR snapd#5868 opened: tests/main/snap-env: extend to cover parallel installations of snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5868>
[08:07] <mvo> kyrofa: can you please try the switch core to "edge"?
[08:08] <mvo> kyrofa: we fixed this recently but its not in beta yet, hopefully by EOD though
[08:09] <kyrofa> mvo, will do, thanks
[08:13] <zyga> re
[08:14] <zyga> kyrofa: replied
[08:15] <ackk> hi, I'm getting the following error running snapcraft: ImportError: /snap/snapcraft/2022/lib/python3.5/site-packages/nacl/_sodium.abi3.so: undefined symbol: crypto_pwhash_argon2id_opslimit_moderate
[08:16] <zyga> kyrofa: or how your new neighbours might have said if they spoke broken Spanish like I do: yo ha añadido una respuesta
[08:17] <kyrofa> akk interesting, we've started getting that as well
[08:17] <kyrofa> But it doesn't seem consistent-- you?
[08:17] <zyga> Chipaca: heey
[08:17] <zyga> around?
[08:18] <Chipaca> zyga: (y)
[08:18] <kyrofa> Urgh... why can't I cancel spread...
[08:18] <zyga> Chipaca: I'd like to add a tweak to yams loader for snap.yaml to indicate an error if "layouts" (plural) is used over the singular correct form
[08:18] <zyga> Chipaca: I was thinking of a simple new entry to deserialise with the different name
[08:19] <zyga> Chipaca: but if you have a better idea I'm all ears
[08:19] <Chipaca> kyrofa: you can, it just takes a bit
[08:19] <Chipaca> kyrofa: it delays because it shuts down the remotes, which can take a while to respond
[08:20] <Chipaca> kyrofa: you can also ctrl-backslash, and then use the .spread* to clean up
[08:21] <Chipaca> zyga: I wonder if there's a way to throw an error on anything unparsed
[08:21] <zyga> Chipaca: mmm, that may be future-proof nasty
[08:21] <zyga> I'd rather not
[08:21] <kyrofa> Chipaca, ah, ctrl-backslash will do it!
[08:23] <Chipaca> kyrofa: usually you can then tell spread itself to clean up using e.g. spread -reuse-pid=<the appropriate number from inspecting .spread*> -discard
[08:23] <Chipaca> kyrofa: spread itself will also tell you what the right argument for -reuse-pid is in its log, if it's still in your scrollback
[08:23] <Chipaca> zyga: good point
[08:24] <kyrofa> Chipaca, just --reuse --discard seems to work
[08:25] <zyga> Chipaca: but we could _warn_ about it
[08:25] <zyga> (wink wink)
[08:25] <Chipaca> zyga: if only we had something like that
[08:25] <zyga> right
[08:25]  * Chipaca gets back to writing stuff on the forum
[08:26] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5869
[08:26] <mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[08:27] <mup> PR snapd#5869 opened: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[08:27] <Chipaca> zyga: what about: TypeLouts errorCatcher
[08:27] <Chipaca> zyga: and then, type errorCatcher struct{}
[08:27] <zyga> errorCatcher?
[08:27] <zyga> ah
[08:27] <Chipaca> zyga: and then, func (errorCatcher) UnmarshalYAML(...)
[08:27] <zyga> and fail on deserialise?
[08:27] <zyga> :D
[08:27] <zyga> yeah
[08:27] <zyga> ++
[08:27] <zyga> I'll do that, great idea
[08:28] <zyga> but...
[08:28] <zyga> how to tweak the error message then?
[08:28] <Chipaca> hmmmm
[08:28] <zyga> no < > to specialise
[08:28] <zyga> still
[08:28] <zyga> I could use a generic type
[08:28] <Chipaca> zyga: make it a layoutsErrorCatcher for now, we can worry about making it generic later
[08:29] <zyga> and subtype it
[08:29] <zyga> yes
[08:29] <zyga> +1
[08:32] <zyga> Chipaca: actually, we can use the struct tags for that
[08:32] <Chipaca> zyga: we can?
[08:32] <Chipaca> zyga: i thought that'd be visible one step up
[08:33] <zyga> Chipaca: TypoLayouts errorCatcher `yaml:"layouts,omitempty",hint:"yada yada"`
[08:33] <zyga> something like that?
[08:33] <Chipaca> zyga: does the errorCatcher deserialiser "see" that hint?
[08:33] <zyga> not sure yte
[08:33] <zyga> looking at this part now
[08:34] <pedronis> #5833 needs a 2nd review
[08:34] <mup> PR #5833: asserts,interfaces/policy: add support for on-store/on-brand/on-model plug/slot rule constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5833>
[08:41] <jamesh> If errorCatcher is implementing yaml.Marshaler, I doubt it would have access to the tag
[08:42] <zyga> yeah, that's what I see so far
[08:42] <zyga> I'm still looking for _a_ way
[08:42] <jamesh> it'd have a pointer to the struct member passed as the receiver, but no way of knowing that it is a member of the struct
[08:42] <jamesh> making the struct itself implement yaml.Marshaler on the other hand might do the trick
[08:43] <zyga> but then we're back to square one with explicit checking per-field like I do nwo
[08:43] <zyga> *now
[08:44] <zyga> it _feels_ like schema
[08:44] <mup> PR snapd#5813 closed: image: warn on missing default-providers <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5813>
[08:44] <zyga> so maybe the simple fix I did now is OK before we have schema support
[08:44] <Chipaca> niemeyer: mvo: how much do we still care about old local revisions? I'm talking about local revisions from before we went negative for local
[08:45] <Chipaca> that is, revisions above 100000
[08:45] <Chipaca> we have tests for them, but I suspect we don't really support them any more outside of those tests
[08:50] <mup> PR snapd#5870 opened: tests/main/parallel-install-services: add spread test for snaps with services <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5870>
[08:59] <niemeyer> Chipaca: My only concern is people using these after installing an old image
[08:59] <zyga> Chipaca: I abandon this idea now,
[09:00] <Chipaca> niemeyer: ack
[09:19]  * zyga -> coffee and snack
[09:26] <Chipaca> mvo: what should I tag warnings as? 2.36?
[09:29] <mvo> Chipaca: yes
[09:29] <mvo> Chipaca: what is missing there?
[09:29] <mvo> Chipaca: I kind of hope to do 2.36 later today
[09:30] <Chipaca> mvo: https://forum.snapcraft.io/t/warnings/7599
[09:30] <Chipaca> mvo: that :-)
[09:30] <Chipaca> degville: https://forum.snapcraft.io/t/warnings/7599
[09:31] <Chipaca> degville: let me know if you can't edit that and want to
[09:31] <Chipaca> (i know you want to :-p)
[09:31] <zyga> Chipaca: how do you feel about adding a warning that warnings are added to everyone refreshing from old snapd? :)
[09:31] <zyga> (and then we remove it in the next release)
[09:32] <Chipaca> zyga: before answering I need to know how many other bad ideas you've had today
[09:32] <zyga> Chipaca: ... I need to re-think the idea to get up in the morning
[09:32] <Chipaca> zyga: I liked at the sprint where you'd announce "this is bad idea #N++"
[09:33] <zyga> :D
[09:33]  * zyga is now being honest
[09:33] <Chipaca> zyga: my main problem with your idea here is that it'd be the _only_ warning the user'd see
[09:33] <zyga> oh
[09:33] <zyga> in that case it'd be futile
[09:33] <Chipaca> zyga: because warnings are there, but nothing uses them as yet
[09:33] <Chipaca> that's 2.37 material
[09:33] <zyga> any low hanging fruit?
[09:34] <zyga> in that case I'd postpone the idea to 2.37
[09:34] <Chipaca> zyga: egrep -ir '(todo|xxx).*warn'
[09:34] <Chipaca> zyga: and, my secondary problem with your idea is that if we need to do that, then we failed to make them obvious and discoverable and subtle and non-intrusive
[09:35] <zyga> warning: your snapd has updated to x.yz, featuring new functionality and bug fixes
[09:35] <zyga> but that's not a warning
[09:36] <Chipaca> zyga: and it'll train the user to ignore them
[09:36] <zyga> mmm, perhaps but that would be a nice touch
[09:36] <Chipaca> so, yeah, -1
[09:36] <zyga> "snapd is getting better while you are to looking"
[09:37] <pedronis> please rate snapd
[09:37] <zyga> mmm, those are way more annoying
[09:37] <mup> PR snapd#5871 opened: snapstate: only report errors if there is an actual error  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5871>
[09:37] <zyga> because they are like beggars asking for a coin, here it's more of a "what's new"
[09:38] <pedronis> anyway lots of our users will not see warnings unless gnome-software learns about them
[09:38] <zyga> yeah, that's true
[09:38] <zyga> it'd be more welcome if any app could do it
[09:38] <zyga> well, back to propagation
[09:38] <pedronis> the app can do it inside themselves
[09:39] <zyga> yeah but if all apps could do it in a standardised way through gnome-software it would be nice
[09:39] <pedronis> maybe, maybe not
[09:39] <pedronis> everything already wants to speak to me
[09:40] <Chipaca> pedronis: that's because you're famous
[09:42] <mup> PR snapd#5872 opened: tests/main/parallel-install-local: rename from *-sideload, extend to run snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5872>
[09:43] <zyga> today Alice in wonderland would have to agree to a privacy policy, EULA and limited warranty before falling down the rabbit hole
[09:50] <diddledan> she wouldn't read them thoroughly, though, or at all, and therefore be violated without her knowing
[09:52] <mup> PR snapd#5866 closed: tests: remove unneeded cleanup from layout tests <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5866>
[09:53] <zyga> thanks!
[10:09] <mup> PR snapd#5873 opened: tests/main/parallel-install-store: run installed snap <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5873>
[10:13] <joc> is there any particular reason why core18 edge hasnt seen an update for about 3 weeks now?
[10:14] <diddledan> joc: is there a problem with what's there now?
[10:14] <joc> was hoping for at least a build with ping back as per https://forum.snapcraft.io/t/core18-included-binaries/7191/14
[10:17] <zyga> joc: yes
[10:18] <zyga> joc: it's because when it is stable we cannot break it
[10:18] <zyga> so that decision was postponed
[10:18] <zyga> joc: I _believe_ this is now the decision of the foundation team though
[10:18] <zyga> mvo: ^
[10:18] <joc> zyga: makes sense for stable channel but was looking at edge
[10:19] <zyga> oh, I missed that, sorry
[10:19] <zyga> in that case I don't know
[10:19] <joc> maybe the transfer to foundations is the reason for the hiatus
[10:31] <mup> Bug #1771793 changed: Interface for hardware temperature monitoring <Snappy:Invalid> <https://launchpad.net/bugs/1771793>
[10:31] <diddledan> mup is slow, I changed that bug 4 minutes ago! :-p
[10:31] <mup> Bug #4: Importing finished po doesn't change progressbar <iso-testing> <lp-translations> <Launchpad itself:Fix Released by carlos> <Ubuntu:Invalid> <https://launchpad.net/bugs/4>
[10:31] <diddledan> haha
[10:32] <diddledan> silly bot
[10:32] <zyga> when the machines rebel mup will remember you said that ;)
[10:33] <diddledan> I, for one, welcome our shiny metal overlords
[10:34] <diddledan> https://memegenerator.net/img/instances/27465850/kiss-my-shiny-metal-ass.jpg
[10:35] <zyga> https://imgflip.com/i/2iu79t
[10:41] <diddledan> nice!
[10:46] <Son_Goku> haha
[10:46] <Son_Goku> ah bender and morpheus
[10:48] <mborzecki> cachio has set up centos images, 2018-09-27 12:47:06 Sending project content to google:centos-7-64 (sep271046-416264)...
[10:50] <mvo> joc: ping is back but the core18 snap is held up in manual review because of this, sil2100 is working on fixing this AIUI
[10:51] <ackk> hi, question about the nodejs plugin: shouldn't it run "yarn install" (with node-package-manager: yarn) automatically during the build phase?
[10:52] <diddledan> ackk: I don't think yarn support works right now
[10:53] <ackk> diddledan, looking at https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/nodejs.py#L178 it seems it does
[10:53] <ackk> diddledan, I mean by setting node-package-manager to yarn I do get yarn installed, but it doesn't really install stuff from the yarn.lock file automatically
[10:53] <diddledan> yes, that's what I'm referring to. it's broken.
[10:54] <ackk> ah, I see
[10:54] <ackk> diddledan, fwiw https://paste.ubuntu.com/p/tYJPk9bt6K/ worked for me
[10:57] <kyrofa> diddledan, akk can one of you please log a bug about that?
[10:58] <ackk> diddledan, maybe you have a bit more context for the bug ^ ?
[10:59] <diddledan> I haven't really dug into it. I meant to, but then forgot :-)
[11:04] <diddledan> https://bugs.launchpad.net/snapcraft/+bug/1794727
[11:04] <mup> Bug #1794727: node plugin doesn't run yarn install during build <Snapcraft:New> <https://launchpad.net/bugs/1794727>
[11:07] <rbasak> snapcraft edge channel broken? beta works. edge failure: https://paste.ubuntu.com/p/GW4gWH4nrC/
[11:07] <rbasak> kyrofa, sergiusens: ^
[11:09] <rbasak> edge 2022; beta 1871
[11:09] <diddledan> rbasak: kyrofa is working on it
[11:10] <kyrofa> rbasak, thank you for letting us know, very nice to have folks testing edge :)
[11:11] <kyrofa> All over it
[11:11] <rbasak> Great, thanks :)
[11:12] <mborzecki> Chipaca: warnings aren't pushed by anything yet, are they?
[11:17]  * zyga needs to take the dog for a walk
[11:19] <diddledan> zyga: going dogging, eh? ;-p
[11:20] <diddledan> I really should take myself for a walk occasionally ;-D
[11:20] <diddledan> <-- lazy
[11:26] <Chipaca> mborzecki: correct; sudo http snapd:///v2/debug action=add-warning message="hello world"
[11:28] <jdstrand> mborzecki: hi! fyi, was looking at pt 5594 and noticed something. see https://github.com/snapcore/snapd/pull/5594/files#r220886654
[11:28] <mup> PR #5594: snap/snapenv: add snap instance specific variables <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5594>
[11:28] <mborzecki> jdstrand: looking
[11:30] <jdstrand> # bind mount *not* used here (see 'parallel installs', above)
[11:30] <mborzecki> jdstrand: this was fixed later on in https://github.com/snapcore/snapd/pull/5735 which came as a result of discussion in #5713 (parallel installs mount mappings)
[11:30] <jdstrand> owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/                  r,
[11:30] <mup> PR #5735: snap/snapenv: drop some instance specific variables, use instance-specific ones for user locations <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5735>
[11:30] <mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
[11:30] <jdstrand> owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/**                mrkix,
[11:31] <mborzecki> jdstrand: so $HOME is instance specific path now, same as $SNAP_USER_DATA
[11:32] <jdstrand> ok, I see that in that pr. thanks!
[11:33] <mborzecki> jdstrand: thank you for being so thorough
[11:33] <jdstrand> mborzecki: it sounds like there isn't anything left for me with this feature?
[11:34] <mborzecki> jdstrand: not at the moment, i'll ping you if i end up doing any tweaks to the interfaces
[11:34] <jdstrand> mborzecki: ok, thanks! I bet you're pretty happy to see this coming to a close :)
[11:34] <mborzecki> jdstrand: and thanks for the reviews again :)
[11:34] <jdstrand> np :)
[11:35] <mborzecki> Chipaca: aargh, need http unix sockets extension
[11:35] <Chipaca> mborzecki: snap install http dude
[11:36] <mborzecki> publisher: John Lenton (chipaca), nice!
[11:36] <Chipaca> :-)
[11:36] <Chipaca> mborzecki: that's why it understands snapd:/// at all :-)
[11:37] <Chipaca> mborzecki: also how it's able to use snapd-control :D
[11:39] <mborzecki> Chipaca: yay, works now
[11:39] <ogra> pedronis, is it normal that i dont get a snap id here ? https://paste.ubuntu.com/p/ZNcjS2P53M/
[11:39] <mborzecki> Chipaca: any plan on where do we start springking warnings first?
[11:39] <Chipaca> mborzecki: also relevant, there's a unshow-all-warnings debug action
[11:40] <ogra> (i'm trying to pre-connect some interfaces from gadget.yaml but if the system doesnt see an id i can not really do that)
[11:40] <Chipaca> mborzecki: egrep -ir '(todo|xxx).*warn'
[11:49] <Chipaca> mvo: how're you feeling about dotfiles for 2.36?
[11:50] <zyga> diddledan: adopting a dog helped with my step count average :)
[11:50] <diddledan> :-)
[11:52] <ogra> hmm
[11:52] <ogra> Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 1
[11:52] <ogra> is there any chance to find out *why* it actually failed ?
[11:52] <ogra> i can manually mount the device (and it properly carries an auto-import.assertion file)
[11:53] <ogra> journalctl sadly does only print that one line ... and snap changes doesnt mention it either
[11:54] <ogra> (it is a vfat formatted usb stick)
[11:55] <Chipaca> ogra: dmesg might have more info
[11:55] <ogra> doesnt
[11:55] <Chipaca> ogra: that command is run via an udev rule
[11:55] <ogra> manually running the program helps a bit (tells me the user already exists, which is indeed true because i manually created it after the import failed)
[11:55] <Chipaca> ogra: snapd-autoimport.rules (or 66-snapd-autoimport.rules)
[11:55] <ogra> Chright, might help to connect stderr to stdout here
[11:56] <ogra> Chipaca, ^^
[11:56] <ogra> haha
[11:57]  * Chright ~> lunch-making
[11:58] <mborzecki> off to pick up the kids
[12:02] <Chipaca> niemeyer: do you want to review #5856, or should I merge it? (it has two +1s already)
[12:02] <mup> PR #5856: cmd/snap: tame the help zoo <Created by chipaca> <https://github.com/snapcore/snapd/pull/5856>
[12:03]  * Chipaca ~> really lunch
[12:07] <ogra> is there a valid way to find the name of the model from a hook without using snapd-control ?
[12:09] <niemeyer> Chipaca: If it follows what we discussed, +1
[12:10] <mup> PR snapd#5874 opened: Adding missing permission to create /run/wpa_supplicant directory <Created by kubiko> <https://github.com/snapcore/snapd/pull/5874>
[12:20] <mup> PR snapd#5875 opened: Avahi interface update <Created by kubiko> <https://github.com/snapcore/snapd/pull/5875>
[12:24] <Chipaca> niemeyer: there's a change, with a new Admin section that has version, warnings, okay, and get, set and wait (meaning the old Config section went away)
[12:25] <niemeyer> Chipaca: Hmm
[12:25] <niemeyer> Chipaca: Sounds a bit awkward at first sight
[12:25] <niemeyer> Chipaca: The whole of "snap foo" is admin
[12:25] <pedronis> ogra: looks like is locally installed
[12:25] <niemeyer> Chipaca: and get/set/wait seem unrelated to the rest
[12:25] <pedronis> in which case I think that's the current behavior
[12:26] <ogra> pedronis, indeed it is, i'm trying to develop as bunch of default connections for the interfaces
[12:26] <ogra> (trying to test them before uploading indeed)
[12:26] <ogra> ah, thats pretty unfortunate
[12:26] <pedronis> ogra: we don't print a snap id for local snaps (even if there's a corresponding store one)
[12:26] <ogra> i thought it would still pull the id from the store
[12:27] <pedronis> that output is actually a bit confusing
[12:27] <ogra> well, it results in the connections to not happening
[12:27] <pedronis> yes, connections are only for store snaps
[12:28] <pedronis> given they are snap id based
[12:28] <ogra> yeah, thats a bit bad for developing ...
[12:28] <ogra> would be nice if we could use some kind of fake id or some such ... i imaging other developers also would like to test their changes before pushing them to the store
[12:28] <ogra> *imagine
[12:29] <Chipaca> niemeyer: thing is, what we discussed didn't include warnings, so those need adding somewhere; i tried to iterate on this at the sprint but we were never not busy with other stuff :-)
[12:29] <Chipaca> niemeyer: so I thought the second best thing would be to iterate in a PR
[12:30] <niemeyer> Chipaca: Sure, and that's what we're doing here too I guess..
[12:30] <pedronis> ogra: you can always push first as private snap
[12:30] <Chipaca> niemeyer: dunno, I'm having lunch, not iterating
[12:30] <pedronis> ubuntu-image gets annoying but possible
[12:31] <ogra> pedronis, sure, i can also push just to edge and leave it there but preferably i'd like to test locally first
[12:31] <niemeyer> Chipaca: Well, you're iterating on lunch.. agile style? :)
[12:31] <ogra> anyway, i'll get around ... but it would be great to improve in that area
[12:32] <Chipaca> niemeyer: not enough beer for this to be XP, so maybe it's scrum?
[12:41] <mvo> Chipaca: dotfiles> I want it in but we can pull it into ~pre2 or ~rc1. it also need a proper name
[12:44] <Chipaca> I think dotfiles is fine
[12:46] <mvo> Chipaca: even better, less churn :)
[12:46] <diddledan> has anyone tried calling a classic snap command from a process that is itself also a classic snap? does it work?
[12:47] <mvo> Chipaca: I think it needs an ack from jamie, I addressed a bunch of things but I'm not sure if its all to his satisfaction
[12:47] <diddledan> as in crossing the boundary between two classic snaps
[12:47] <Chipaca> mvo: there's even a quora article about dotfiles
[12:47] <Chipaca> mvo: I'm not sure if that's an argument for or against, but it's there
[12:48] <mborzecki> re
[12:50] <pedronis> mvo: are you thinking of cutting 2.36 ?
[12:52] <mvo> pedronis: I was thinking after the meeting - anything pending on your side that should be in that is not milestoned?
[12:53] <pedronis> mvo: yes, 4 PRs,  they should get to reviewable today or early tomorrow
[12:58] <mvo> pedronis: ok
[12:59] <mvo> pedronis: is it about the brand store work?
[12:59] <pedronis> mvo: yes
[12:59]  * mvo nods
[13:00]  * zyga tries to join the standup ...
[13:00] <popey> This is a fun error message...
[13:01] <niemeyer> I'll be a couple of minutes late
[13:01] <popey> https://www.irccloud.com/pastebin/0ofGh1tb/
[13:01] <popey> (kodi isn't even installed)
[13:01] <popey> Maybe it should say "snap "kodi" isn't installed" or something?
[13:03] <popey> (you can easily reproduce this with "snap connect foo:bar"
[13:03] <popey> )
[13:03] <zyga> popey: I'll fix that, thanks!
[13:03] <popey> np
[13:04] <ogra> geez, just install kodi
[13:04] <popey> kodi 18.0b2-Leia installed
[13:04] <popey> ok!
[13:04] <ogra> :D
[13:04] <ogra> we have a leia snap ?!?!?
[13:04] <popey> *I* do
[13:04] <ogra> for armhf by chance ?
[13:04] <diddledan> ok. the problem I'm encountering is specific to vscode then - it cannot launch the dotnet sdk cli which is in a separate classic snap - I've tried to do a reduced testcase but couldn't get that to fail, so something is screwey with the vscode snap
[13:05] <popey> ogra: not yet
[13:05] <diddledan> silly thing, though, is that using the inbuilt command line in vscode can launch the sdk cli
[13:05] <ogra> popey, well, once you do ... i'd be a happy tester
[13:05] <popey> bet you will
[13:05] <ogra> UbuntuCoreElec !!!
[13:06] <mup> PR snapcraft#2295 closed: tests: use SNAPCRAFT_PACKAGE_TYPE everywhere <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2295>
[13:06] <mup> PR snapcraft#2296 closed: part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2296>
[13:06] <mup> PR snapcraft#2297 closed: [legacy] part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2297>
[13:06] <mup> PR snapd#5862 closed: cmd: fix C formatting <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5862>
[13:21] <mup> PR snapcraft#2301 opened: tests: move most tests to spread and reorder travis.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2301>
[13:50] <Chipaca> degville: I did the change in 'snap whoami' fwiw (as well as the new Other (miscelanea) category)
[13:51] <degville> Chipaca: thanks! Sad I can no longer use my printer though.
[13:51] <Chipaca> degville: just pipe it to "lp" and it'll work
[13:51] <degville> ahaha!
[13:52] <Chipaca> degville: I don't know if the unicode characters will work though, it might set it to banner mode and print you out of a home
[13:59] <mvo> sil2100: who in foundations might know about translations ? I wonder who can approvehttps://translations.launchpad.net/snapd/trunk/+imports
[13:59] <mvo> sil2100: https://translations.launchpad.net/snapd/trunk/+imports
[13:59] <mvo> sil2100: someone with special powers needs to approve this one and I'm trying to find who that someone is :)
[14:01] <Chipaca> degville: AIUI Miscellanea was a countable miscellany. Ignoring the typo, did I get that wrong?
[14:01] <Chipaca> that is, they're synonyms, but miscellanea are countable and miscellany might not be
[14:02] <Chipaca> but, maybe it's archaic
[14:02] <Chipaca> :) you tell me
[14:02] <diddledan> mvo: https://upload.wikimedia.org/wikipedia/en/thumb/e/eb/SupermanRoss.png/250px-SupermanRoss.png
[14:02] <mvo> diddledan: I'm looking for that dude!
[14:02] <diddledan> all the powers
[14:02] <mvo> diddledan: in the old days it was dpm or danilo but I don't know about the present days :/
[14:03] <sil2100> mvo: this is the part of translations that I have no power over! I think Gunnar is responsible for this now
[14:03] <mvo> I will just pester random people until I find out more
[14:03] <sil2100> mvo: let me poke him through e-mail, he'll at least know
[14:03] <mvo> sil2100: nevermind
[14:04] <mvo> sil2100: I got some help now from colin and hopefully thats enough I will keep in mind that gunnar is the guy
[14:04] <mvo> sil2100: thanks!
[14:08] <mup> PR snapd#5876 opened: selftest: rename selftest.Run() to sanity.Check() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5876>
[14:12] <Chipaca> mvo: do we do tarballs of releases on github?
[14:13] <Chipaca> waaait, is this something github does automagically
[14:13]  * Chipaca prods it
[14:14] <zyga> Chipaca: yes we do
[14:14] <zyga> we produce three dedicated tarballs
[14:14] <Chipaca> yep, https://github.com/snapcore/snapd/releases
[14:14] <Chipaca> looking at that now
[14:16] <Chipaca> zyga: i can haz darwin in lab?
[14:16] <zyga> mmm
[14:16] <zyga> sure
[14:16] <Chipaca> zyga: taw
[14:16] <Chipaca> zyga: I can't even get to the lab, right now
[14:16] <Chipaca> not sure why
[14:17] <zyga> Chipaca: I turned it off (fan noise)
[14:17] <zyga> Chipaca: note, it's updated to Mojave and home-brew is out
[14:17] <zyga> so you need to re-do it
[14:17] <Chipaca> ok
[14:17] <zyga> when I looked at brew it suggested that I don't use sudo though
[14:17] <zyga> so maybe something new?
[14:17] <Chipaca> zyga: not use sudo, and instead what?
[14:17] <zyga> brew
[14:17] <zyga> I mean
[14:17] <zyga> whatever you need :)
[14:17] <mvo> Chipaca: why do you ask?
[14:18] <Chipaca> mvo: because our brew formula currently is only a head formula, and I'd like to make it do releases instead
[14:18] <Chipaca> so you can 'brew install snap' (as opposed to the current 'brew install --HEAD snap')
[14:18] <Chipaca> s/as opposed/in addition/
[14:19] <mvo> Chipaca: aha, nice
[14:20] <diddledan> is that a brew formula for linuxbrew or homebrew (macOS) or both? if it's targeting homebrew in some way, how's that work??!
[14:21] <Chipaca> diddledan: both
[14:22] <Chipaca> although the linuxbrew one is incidental, the objective is homebrew
[14:22] <Chipaca> diddledan: snap, the command, works on darwin
[14:22] <Chipaca> diddledan: snapd does not
[14:22] <sergiusens> diddledan: the same way it works for snapcraft on mac
[14:22] <sergiusens> oh, ic, the how does that work is related to snapd
[14:22] <diddledan> I figured snap would be useless without a snapd to control
[14:23] <sergiusens> diddledan: we want the snap command avail since it is what holds the license field validation logic
[14:28] <Chipaca> diddledan: the only thing stopping snapd from working via remote control is nasty humans
[14:28] <Chipaca> (i.e., auth)
[14:28] <diddledan> bah. filthy scum
[14:29] <Chipaca> ikr
[14:29] <Chipaca> zyga: your network is slow today :-(
[14:30] <zyga> oh?
[14:30] <zyga> not me
[14:30] <zyga> maybe $family or weather
[14:30] <Chipaca> zyga: taking *minutes* to download the go 1.11 bottle
[14:30] <Chipaca> :)
[14:30] <diddledan> try changing the tyres
[14:32] <zyga> bad mirror?
[14:32] <zyga> where are you fetching from?
[14:33] <zyga> I see almost no traffic
[14:34] <ogra> probably there is a detour sign outside your viallge
[14:35] <ogra> *village
[14:42] <Chipaca> dang, 2.35.2 did not build on darwin yet.
[14:43] <Chipaca> mvo: how is the .vendor. tarball built? i'd like to test it with master
[14:44] <Chipaca> that is, i need a tarball for a stable brew build, but the latest snapd_2.35.2.vendor.tar.xz doesn't cut it :-)
[14:45] <mup> PR snapcraft#2290 closed: pluginhandler: update build should overwrite organize <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2290>
[14:50] <Chipaca> mvo: also: can we make those tarballs come pre-generated? ie without needing mkversion etc?
[14:54] <kyrofa> sergiusens, yeah, pip is doing something weird here
[14:55] <kyrofa> pip install pymacaroons==0.9.2 actually does the right thing
[14:55] <kyrofa> But using the requirements.txt seems to be getting 0.9.0
[14:55] <kyrofa> It's interesting because pip freeze shows 0.9.2, then I actually look at it and its __init__ shows 0.9.0
[14:57] <pedronis> fun, if I add an empty TearDownTest to one of the suites in snapstate some unrelated tests fail :/
[15:06] <zyga> Chipaca: look at release-tools
[15:06] <zyga> Chipaca: there's a script for it
[15:08]  * Chipaca looks around for a Neal
[15:09] <mup> PR snapcraft#2280 closed: Use the better snapcraft.io/account URL <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2280>
[15:25] <zyga> Pharaoh_Atem: ^
[15:26]  * Pharaoh_Atem pops in
[15:26] <Pharaoh_Atem> what?
[15:26] <zyga> Chipaca: ^
[15:26]  * zyga runs
[15:26] <Chipaca> heh
[15:26] <Chipaca> Pharaoh_Atem: hola
[15:26] <Pharaoh_Atem> aloha!
[15:26] <Pharaoh_Atem> I'm confused, what's going on here?
[15:26] <Chipaca> Pharaoh_Atem: is the tarball (as in https://github.com/snapcore/snapd/releases) used as part of the rpm build at any point?
[15:27] <Pharaoh_Atem> yes
[15:27] <Chipaca> Pharaoh_Atem: do you need to hoop through jumps to get the version?
[15:27] <Pharaoh_Atem> nope, I set the version in the spec, and propagate it down to everything
[15:27] <Chipaca> Pharaoh_Atem: I mean, the mkversion.sh script
[15:27] <Chipaca> Pharaoh_Atem: you don't use it /  do things differently?
[15:27] <Pharaoh_Atem> I use it
[15:28] <Pharaoh_Atem> ./mkversion.sh %version-%release
[15:28] <Pharaoh_Atem> that's in the spec file for every snapd package derived from my packaging
[15:28] <Chipaca> ahhh
[15:28] <Chipaca> fair enough
[15:28] <Chipaca> Pharaoh_Atem: ok
[15:28] <Chipaca> Pharaoh_Atem: thanks
[15:28] <Pharaoh_Atem> no problem
[15:28] <Chipaca> I might just do that on darwin as well, then
[15:28] <Chipaca> if I can figure out the equivalent in brewish
[15:28] <Pharaoh_Atem> https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec#_403-404
[15:29] <Pharaoh_Atem> brew has a version variable
[15:29] <Chipaca> I was going to do a bunch of work to make mkversion itself figure it out but this is easier
[15:29] <Chipaca> Pharaoh_Atem: and a revision! :-)
[15:29] <Pharaoh_Atem> hold on, I did this recently when I packaged rpm for homebrew
[15:29] <Chipaca> ooohh
[15:30] <Chipaca> Pharaoh_Atem: https://formulae.brew.sh/formula/rpm ?
[15:30] <Pharaoh_Atem> yeah
[15:30] <Pharaoh_Atem> I rewrote that formula
[15:30] <Pharaoh_Atem> I think #{VERSION} is defined?
[15:30] <Chipaca> ah
[15:30] <Pharaoh_Atem> I know it does some introspecting from the tarball name
[15:31] <Chipaca> lowercase, at  least, works
[15:31] <Chipaca> ie #{version}
[15:31] <Pharaoh_Atem> cool
[15:31] <Chipaca> yep
[15:31] <Pharaoh_Atem> yeah, ruby is weird
[15:31] <Chipaca> thanks!
[15:31] <Pharaoh_Atem> no problem ;)
[15:32] <ogra> niemeyer, mvo, zyga https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603 any thoughts here would be appreciated
[15:32] <Pharaoh_Atem> most things tend to behave like rpm spec files :D
[15:32] <Pharaoh_Atem> ogra: shit
[15:32] <Pharaoh_Atem> that explains the bugs I'm getting in Fedora
[15:32] <Pharaoh_Atem> our nsswitch.conf is getting blown away and breaking things
[15:32] <zyga> ogra: hmm
[15:33] <zyga> ogra: yeah, tough choice
[15:33] <zyga> maybe it should be writable?
[15:33] <zyga> and snap might manage that somehow
[15:33] <Pharaoh_Atem> https://bugzilla.redhat.com/show_bug.cgi?id=1596753
[15:33] <Pharaoh_Atem> zyga, ogra ^
[15:34] <zyga> Pharaoh_Atem: we should not be mounting anything on the host
[15:34] <zyga> unless the code is broken
[15:34] <zyga> but then all hell would break lose
[15:34] <Pharaoh_Atem> maybe it is, just not on Ubuntu :(
[15:34] <zyga> we test it on fedora dozens of times a day
[15:34] <Pharaoh_Atem> this is not the only file that we're having problems with caused by snapd
[15:35] <ogra> Pharaoh_Atem, heh
[15:35] <zyga> Pharaoh_Atem: can you see weird mounts on your snap running system?
[15:35] <zyga> if not then we are not doing that (or you are not using any snaps)
[15:35] <Pharaoh_Atem> zyga: I'll check in a bit, when I can get to my snap dev environment
[15:35] <zyga> ok
[15:35] <Pharaoh_Atem> I've removed snapd and snaps from my main workstation because it kept breaking things
[15:35] <zyga>  /o\
[15:36] <Pharaoh_Atem> I had no choice, I can't have a broken workstation at work
[15:36] <Pharaoh_Atem> I had snapd on here for a while to play around with base snaps and building fedora based layered snaps
[15:37] <ogra> Pharaoh_Atem, i'D appreciate a comment on the thread indeed :)
[15:42] <Pharaoh_Atem> ogra: commented: https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603/2
[15:43] <Pharaoh_Atem> zyga, ogra, the really challenging problem is that I have no idea what is causing this
[15:44] <Pharaoh_Atem> the best I can guess is that something is doing a read+writeback and because we can't operate in strict confinement, it actually hits the filesystem and breaks things
[15:46] <ogra> Pharaoh_Atem, thanks !
[16:02] <mvo> Chipaca: I will merge 5865 now but if my question inline is valid please do a followup (if not even better :)
[16:03] <Chipaca> what was 5865?
[16:03]  * Chipaca looks
[16:03] <mvo> Chipaca: the translation comments
[16:03] <Chipaca> mvo: aww
[16:03] <Chipaca> mvo: 5856 was the one i wanted in :-)
[16:03] <mup> PR snapd#5865 closed: cmd/snap: add a bunch of TRANSLATORS notes (and a little more i18n) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5865>
[16:03] <Chipaca> so close
[16:03] <Chipaca> mvo: :-) tahnks
[16:04] <mvo> Chipaca: heh, the --help one has a +1 from me already
[16:04] <Chipaca> mvo: grah, you're right about them not being the same
[16:04] <Chipaca> drat it
[16:04] <mvo> Chipaca: but if degville gives a +1 too …
[16:04] <mvo> Chipaca: no worries
[16:04] <mvo> Chipaca: just do a followup and all is good
[16:04] <Chipaca> okk
[16:05] <mvo> Chipaca: ta!
[16:05] <mvo> Chipaca: uh and 5856 has a conflict now :/
[16:05] <Chipaca> mvo: tests for 5856 haven't started yet, otherwise it's gtg imo
[16:05] <Chipaca> of _course_ it does
[16:05] <Chipaca> :-)
[16:05] <mvo> Chipaca: the help one only had a single +1 so far, no? /me double checks
[16:06] <mvo> Chipaca: aha, silly me, two +1, one from degville  earlier. so yeah, ready once tests are happy :)
[16:06] <degville> :)
[16:06] <Chipaca> and conflcits
[16:07] <Chipaca> mvo: how easy is it for you to build a fake tarball (like the ones in https://github.com/snapcore/snapd/releases)?
[16:07] <mup> PR snapd#5873 closed: tests/main/parallel-install-store: run installed snap <Parallel installs> <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5873>
[16:07] <Chipaca> mvo: I tried doing it starting from dpkg-buildpackage of the git checkout and got into trouble :-)
[16:08] <mvo> Chipaca: the release ones? trivial: "gbp buildpackage -S" and ./release-tools/repack-tarball ../build-area/*.tar.xz
[16:08] <mvo> Chipaca: do you want one?
[16:08] <Chipaca> mvo: of ~master, I could use one to test brew stable build, yes
[16:08] <Chipaca> mvo: I can point it at any url (and then switch it back to github when that's done)
[16:09] <Chipaca> mvo: OTOH, I can also wait for the actual tarball
[16:09] <Chipaca> it's not going to land before that
[16:10] <mvo> Chipaca: building one for you now
[16:12] <mvo> Chipaca: try http://people.canonical.com/~mvo/.chipaca/
[16:12] <Chipaca> mvo: <3
[16:14]  * zyga is starving
[16:15] <Chipaca> woooooo, that worked :-D
[16:15] <Chipaca> mvo: thanks again
[16:39] <mup> PR snapcraft#2040 closed: lifecycle: always prime dependencies <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>
[16:50] <mvo> Chipaca: \o/ great to hear that it works :)
[16:56] <rbasak> kyrofa: on the subject of testing edge, I'm looking to land a git-ubuntu regression fix and our CI is failing because our CI is using snapcraft from edge. I'm reluctant to switch it to use beta because then I wouldn't be testing edge, which is useful :)
[16:56] <rbasak> Not sure what I want exactly. I thought I'd mention the situation.
[16:57] <kyrofa> rbasak, yeah, tough situation. I think we've figured out the fix, if it helps
[17:03] <mup> PR snapd#5856 closed: cmd/snap: tame the help zoo <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5856>
[17:06] <Chipaca> mvo: weee
[17:06] <mvo> Chipaca: !!!
[17:06]  * mvo hugs Chipaca
[17:06] <Chipaca> and go-flags master is working again :-D
[17:07] <mvo> zyga: 5870 looks like you almost gave a +1
[17:07] <Chipaca> some of our tests broke because now it's better :-)
[17:07] <mvo> Chipaca: haha
[17:07] <Chipaca> one of the fixes was that before it left space for all options, even if some of them were hidden
[17:07] <mvo> Chipaca: the update will be a small burden on debian as they will also need to update the package
[17:07] <Chipaca> you can see that in 'snap help prefer' for ex
[17:08] <mvo> Chipaca: cool, thanks for fixing this!
[17:08] <Chipaca> this assumes all the tests are ok, now, of course :-)
[17:08] <Chipaca> grmbl
[17:10] <mup> PR snapd#5583 closed: cmd/snapd,daemon,overlord: without snaps, stop and wait for socket <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5583>
[17:18] <Chipaca> zyga: i'm done with the lab, thanks
[17:22] <mup> PR snapcraft#2302 opened: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2302>
[17:22] <mup> PR snapcraft#2303 opened: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2303>
[17:51] <zyga> mvo: looking at 5870
[17:52] <Chipaca> so, we were using a bug in go-flags :-(
[17:52] <Chipaca> sad trombone
[17:52] <zyga> Chipaca: oh?
[17:52] <zyga> Chipaca: cool, what did you find?
[17:52] <Chipaca> we use PassAfterNonOption
[17:52] <Chipaca> but only really use it in 'snap run'
[17:52] <zyga> Chipaca: is it the time when we roll our own?
[17:53] <Chipaca> nah
[17:53] <zyga> or do we have a way to fix it
[17:53] <Chipaca> bah, I think this is fixable
[17:53] <Chipaca> in a few ways
[17:53] <Chipaca> but the basic thing is: PassAfterNonOption means "be strict POSIXly"
[17:53] <Chipaca> there was a bug in go-flags where it didn't actually do its job
[17:53] <Chipaca> so you could have "snap install foo --classic" mean the same as "snap install --classic foo"
[17:54] <Chipaca> which is explicitly not what PassAfterNonOption should do: with PassAfterNonOption, the first --classic is no longer an option
[17:54] <Chipaca> it's an argument, and is passed to the command's Execute as such
[17:54] <Chipaca> but of course we want "snap run http --help" to have that help reach http
[17:54] <Chipaca> so
[17:55] <Chipaca> easy fix: require everybody using snap run directly to do "snap run -- http --help
[17:55] <Chipaca> "
[17:56] <Chipaca> hacky fix: peek at os.Args, and rewrite it to add a -- for 'snap run'
[17:56] <Chipaca> the first one is trivial, only really affects tests on our end
[17:56] <Chipaca> snapped apps continue to work, because we'd add the -- ourselves
[17:56] <Chipaca> only people we'd be breaking are those that use 'snap run' with arguments
[17:56] <Chipaca> but … that's probably some people
[17:57] <Chipaca> so, leaning towards the hacky don't-break-people one
[18:07] <sergiusens> Chipaca: the joys of wanting to mix strict arg parsing with friendly arg parsing :-)
[18:23] <zyga> Chipaca: still hear?
[18:23] <zyga> here
[18:23] <Chipaca> yes
[18:23] <zyga> I have a branch with the Mk** helpers moved
[18:23] <zyga> it's a bit big
[18:24] <zyga> wanna see?
[18:34] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5877 I opened for RFC
[18:34] <mup> PR #5877: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
[18:34] <mup> PR snapd#5877 opened: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
[18:34] <Chipaca> zyga: hmmm
[18:34] <Chipaca> zyga: are you all hyped up, or are you wrapping up your day?
[18:34] <zyga> more of a task switching
[18:34] <zyga> this was a distraction today
[18:34] <zyga> I'm working on something more involved
[18:35] <zyga> also upset about MBP - still not fixed
[18:35] <zyga> and apparently service people broke the screen /o\
[18:35] <zyga> at this rate I'll get crumbs next week
[18:35] <zyga> iCrumbs
[18:35] <zyga> it was such a nice machine
[18:36] <Chipaca> zyga: official service?
[18:36] <zyga> not real apple but authorised services
[18:36] <zyga> I'm sure they will fix it
[18:36] <zyga> (or just give me a brand new unit)
[18:36] <zyga> but ... what the hell happened
[18:37] <zyga> maybe I should just not think more about it
[18:37] <zyga> and just wait patiently
[18:37] <zyga> and not get more gray
[18:37] <zyga> next time I'll open it in the store
[18:37] <zyga> and just ask for a different unit
[18:38] <zyga> and let them turn gr{a,e}y
[18:38] <zyga> which is it?
[18:38] <zyga> anyway
[18:39] <Chipaca> zyga: depends on where you're standing when you say it
[18:40] <Chipaca> anyway, it's 19:40, I need to make dinner
[18:40] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/5877 landing would make me happy
[18:40] <mup> PR #5877: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
[18:40] <zyga> and I can then go and rest
[18:40] <zyga> you're right, EOD time
[18:40] <Chipaca> and instead I'm knee deep in making our thing work with the new go-flags
[18:40] <Chipaca> zyga: I'll look at that last one after dinner, k?
[18:40] <zyga> er
[18:40] <zyga> no no wrong branch
[18:40] <zyga> but sure
[18:40] <Chipaca> well, leave the one you want me to look at
[18:41] <Chipaca> if it's too big, i'll punt
[18:41] <zyga> meant https://github.com/snapcore/snapd/pull/5869
[18:41] <mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
[18:41] <Chipaca> otherwise i'll sleep at 3am again
[18:41] <zyga> :-)
[18:41] <Chipaca> ttfn
[18:41] <zyga> ttyl
[19:07] <JohK> hi
[19:07] <JohK> how do I get snap apps to work when my home is symlinked to a different drive?
[19:07] <gQuigs> is there something obvious I'm doing wrong here: https://pastebin.ubuntu.com/p/jgMBPYSYBz/   following workaround from forum - https://forum.snapcraft.io/t/importerror-no-module-named-six/1002/3
[19:12] <JohK> I get similar errors to what users report when their home is on a nfs mount
[19:12] <JohK> i.e. for pycharm or spotify
[19:15] <ogra> JohK, stop using a symlink and use a bind mount instead
[19:15] <zyga> JohK: hey, as ogra said you must use a bind mount instead
[19:16] <zyga> or just mount your home directory to /home/$LOGNAME
[19:18] <JohK> I use this setup for 15 years...
[19:18] <JohK> ogra: Really? I use this setup for 15 years...
[19:20] <JohK> ogra: why is not having a symlink a requirement for snap to work?
[19:21] <JohK> well I guess Im not using snapd then, thx
[19:57] <zyga> because symlinks and real directories are not the same, have fun with your setup for the next 15 years
[20:00] <mup> PR snapd#5878 opened: overlord/ifacestate: make sure to pass in the Model assertion when enforcing policies <Created by pedronis> <https://github.com/snapcore/snapd/pull/5878>
[20:05] <Chipaca> zyga: chill
[20:21] <Chipaca> zyga: you there?
[20:23] <zyga> yes
[20:24] <Chipaca> zyga: comment on your pr
[20:24] <Chipaca> zyga: and a suggestion coming up in diff form
[20:24] <zyga> on 5877?
[20:24] <Chipaca> zyga: https://pastebin.ubuntu.com/p/V2NbGY6GPp/
[20:24] <Chipaca> 5869
[20:25] <zyga> ah
[20:25] <zyga> did you see what the error looks like if you try that?
[20:25] <Chipaca> zyga: yes
[20:25] <zyga> it's less sublime, talking about unmarshaling and such
[20:25] <zyga> AFAIR, it was less pretty than now
[20:25] <Chipaca> 1 sec
[20:26] <Chipaca> $ snap pack . ..
[20:26] <Chipaca> error: cannot pack ".": cannot parse snap.yaml: cannot use "layouts" (plural), please use singular "layout" instead
[20:26] <zyga> we _can_ parse snap.yaml
[20:26] <zyga> we just don't like what we found
[20:26] <zyga> and without the extra change?
[20:26] <Chipaca> zyga: without which extra change?
[20:26] <zyga> I mean, without your suggestion
[20:27] <Chipaca> zyga: it's in the comment: error: cannot pack ".": cannot use "layouts" (plural), please use singular "layout" instead
[20:27] <zyga> hmm
[20:27] <Chipaca> quite
[20:27] <Chipaca> and this is with pack, where you know at least that you're building this
[20:28] <zyga> I was thinking about making a error type and returning it instead
[20:28] <zyga> and tweaking the error reception in the client
[20:28] <Chipaca> imagine getting «cannot install "foo": cannot use "layouts"»
[20:28] <zyga> but I think it's too late for that today, I was about to hit the bed
[20:28] <zyga> but I'll try both tomorrow
[20:28] <Chipaca> zyga: ?
[20:28] <zyga> and see if the error looks nice in all cases (I was thinking of "snap try" mostly)
[20:28] <Chipaca> zyga: there is no client/server for 'snap pack'
[20:29] <zyga> you can make a snap with older version and install it
[20:29] <zyga> that's what I meant, sorry for not being clear
[20:30] <zyga> I'll continue tomorrow :)
[20:30] <Chipaca> ok
[20:30] <Chipaca> zyga: g'night
[20:30] <Chipaca> i'm off as well
[20:54] <mup> PR snapd#5879 opened: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>
[21:27] <sergiusens> stgraber: hey there, everytime my lxd snap updates (just did recently) my container(s) die(s); from what I recollect this should not be the case so wondering if there is a way to monitor what is going on
[21:28] <stgraber> sergiusens: what channel?
[21:28] <stgraber> sergiusens: journalctl -u snap.lxd.daemon -u 500
[21:28] <sergiusens> stgraber: latest/stable is where I saw it just now
[21:31] <sergiusens> stgraber: exit with 137
[21:31] <sergiusens> stgraber: for context https://pastebin.ubuntu.com/p/8qc6VHhNsW/
[21:33] <stgraber> sergiusens: "dmesg" output?
[21:37] <sergiusens> stgraber: maybe this https://pastebin.ubuntu.com/p/wH2WCMFjsD/ ?
[21:37] <sergiusens> stgraber: I can hand over the full output if you want too
[21:38] <stgraber> sergiusens: nah, unrelated, full output please
[21:38] <stgraber> sergiusens: also, the journalctl didn't show you anything more than what you pasted? that was way shorted than 500 lines
[21:39] <sergiusens> there's more in the journal, I'll send over
[21:40] <sergiusens> stgraber: full journal https://pastebin.canonical.com/p/39DRDZBXtm/
[21:41] <sergiusens> to any other person, sorry for the private link, but I haven't checked if this leaks any sensitive data 🙂
[21:42] <stgraber> sergiusens: full dmesg?
[21:42] <stgraber> sergiusens: ah and "snap version" too please?
[21:43] <sergiusens> stgraber: https://pastebin.canonical.com/p/CMxrySp2cB/
[21:44] <sergiusens> stgraber: http://paste.ubuntu.com/p/Q3Y5mjjj54/
[21:44] <stgraber> sergiusens: "snap changes" output?
[21:46] <sergiusens> stgraber: I think you want this specific change http://paste.ubuntu.com/p/mRqcZrcPyv/
[21:46] <sergiusens> an autorefresh change that is
[21:46] <sergiusens> hmm, let me see if I can get those out in english client side
[21:47] <sergiusens> meh, no
[21:49] <sergiusens> """Detener los servicios del snap "lxd"""" translates to """Stopping services from the snap "lxd""""
[21:50] <stgraber> oh, that's actually very interesting
[21:50] <stgraber> well, maybe not
[21:51] <stgraber> can you show me cat /proc/$(pgrep daemon.start)/environ | tr '\0' '\n'?
[21:51] <sergiusens> right, it doesn't say exactly if it will ignore the stop or not after going in
[21:51] <stgraber> well, no, it not being in english is the interesting part :)
[21:51] <stgraber> because we parse that in our stop code
[21:52] <stgraber> but the environment of the stop code should be such that it's in english
[21:53] <sergiusens> stgraber: my locale at installation time is spanish https://pastebin.canonical.com/p/zsw3RDXCtP/
[21:53] <stgraber> crap, I didn't expect systemd to respect it :)
[21:53] <sergiusens> this is why we don't do translations for these things :-P
[21:53] <stgraber> sergiusens: LANG=C.UTF-8 snap changes
[21:54] <sergiusens> stgraber: tried that already :-)
[21:54] <sergiusens> stgraber: so it means the changes are generated by snapd, they are also ephemeral, so I suppose that restarting snapd will kill the changes
[21:55] <stgraber> snapd stores them as a string in the user's language?
[21:55] <sergiusens> I am not sure about that, I hope not; but I do suppose that snapd returns output to the snap command already in the set lang
[21:56] <stgraber> oh, so the daemon is returning translated strings then, great...
[21:57] <sergiusens> yes, it seems so
[21:57] <sergiusens> it wouldn't be that bad if the client could tell it the language it wanted those strings in
[21:58] <sergiusens> but alas, that does not seem to be the case
[21:59] <stgraber> do you know if there's some new way for us to figure out if we're dealing with a unit restart due to refresh vs unit restart due to host shutdown?
[22:00] <sergiusens> stgraber: given the timestamps, this is certainly a refresh; change 19 which I pasted is from auto-refresh
[22:01] <sergiusens> I was actually doing something else when I saw the container go away
[22:01] <stgraber> sergiusens: yeah, I'm sure that's the problem, I'm just looking for ways to fix it which don't involve me hardcoding strings for every language we may get back from snapd :)
[22:04] <stgraber> sergiusens: curl --unix-socket /run/snapd.socket snapd/v2/snaps/lxd -s | jq .result.status
[22:04] <stgraber> sergiusens: is this in english?
[22:08] <sergiusens> fwiw https://forum.snapcraft.io/t/snap-snapd-language/7607
[22:09] <sergiusens> stgraber: yes, that is in English
[22:09] <sergiusens> returned "active"
[22:09] <stgraber> sergiusens: unfortunately that won't quite be enough as it won't tell me if the snap is being removed, poking at the /changes API instead now
[22:10] <sergiusens> ok, I will have to commute back home right now, but I can get back to this in a bit, just leave me anything required to check
[22:13] <stgraber> sergiusens: curl --unix-socket /run/snapd.socket snapd/v2/changes?select=all\&for=lxd -s | jq -r ".result | .[] | .kind"
[22:14] <stgraber> I think that will be our way out of this problem, much more reliable than parsing snap changes
[22:57] <stgraber> sergiusens: wrote a new query tool that pokes the API directly, building a new snap with that, will test tomorrow (in Europe now, so a bit late here)


[00:04] <serenity> hi
[00:05] <serenity> i own this device http://www.linuxtv.org/wiki/index.php/Medion_MD95700_%28DVB-T%29 loaded all modules mentioned there, but i get to tv. Possible faults?
[00:06] <serenity> *no
[02:18] <Egghead> is there an easy way to restart mythfrontend after it crashes out to the desktop?
[02:19] <TelnetManta> did you try killing it?
[02:19] <TelnetManta> sudo killall mythbackend
[02:19] <TelnetManta> if you're not sure its running try sudo ps -ax | grep mythfrontend
[02:19] <TelnetManta> oops, sudo killall mythfrontend :-)
[02:20] <tgm4883_laptop> Egghead, you could kinda start it from the command line
[02:20] <Egghead> ummm, i want to restart mythfrontend, automatically after it crashes
[02:20] <TelnetManta> oh LOL
[02:20] <TelnetManta> I tried
[02:20] <Egghead> tgm, i tried that with shh, but it barks about no xorg
[02:21] <tgm4883_laptop> Egghead, you could restart gdm
[02:21] <Egghead> its gtting to be a pain to vnc into it all the time :)
[02:21] <Egghead> tgm, ahhh havent tried that :)
[02:21] <tgm4883_laptop> thats what I do
[02:22] <Egghead> no script i can run?
[02:22] <tgm4883_laptop> well use to
[02:22] <tgm4883_laptop> I haven't had it crash since I changed to hardy
[02:22] <Egghead> or maybe link a remote key inlirc
[02:23] <Egghead> hehe, ive have more problems since upgrading
[02:25] <Egghead> tgm thanks for the input :)
[02:35] <ubuntu> howdie folks
[02:37] <SavageOne> I'm in a live cd environment just trying to connect to my mythtv as a frontend
[02:37] <SavageOne> my mythtv backend/frontend combo works fine
[02:37] <SavageOne> but I am hitting test connection and I'm not getting anywhere
[02:37] <SavageOne> I believe I chose a password for mythtv mysql database but I've tried all my passwords and got nothing
[02:38] <SavageOne> is there maybe a default password for mythtv mysql db?
[03:51] <waterfoul> hi!
[03:52] <waterfoul> any 1 here?
[03:52] <waterfoul> hello?
[04:03] <waterfoul> any 1 home?
[05:01] <hti_pro> so i installed mythtv-database on an existing mythtv slave backend with the intention of changing it to a master backend.  Now how do I get the credentials for backend setup
[12:33] <rwn_> hello, everyone speacks german?
[12:49] <DaveMorris> rwn_: I'll see if I can get someone for you
[12:49] <laga> hallo
[12:50] <DaveMorris> laga: it was at 12:34 so his prob afk atm
[12:50] <laga> ah
[12:50] <DaveMorris> 12:34 BST that is
[12:51] <rwn_> ok dave thx
[12:52] <DaveMorris> rwn_: laga is german
[12:52] <rwn_> mein mythbuntu läuft seit dem update von gestern nicht mehr
[12:52] <rwn_> ah ja stimmt
[12:52] <rwn_> laga kannst du mir kurz helfen ?
[12:53] <laga> keine ahung. kommt drauf an was das problem ist
[12:53] <rwn_> seit dem update von gestern läuft mythbuntu nicht mehr
[12:53] <rwn_> desktop kommt autostart auch
[12:54] <rwn_> dann sehe ich nur noch die Uhrzeit
[12:54] <rwn_> keinerlei auswahl mehr möglich im frontend
[12:54] <rwn_> das frontend ist auch nicht schwarz sondern blau wie immer
[12:55] <laga> rwn_: beende das frontend und öffne ein terminal, dann starte "mythfrontend -O ThemePainter=qt". geht das?
[12:55] <rwn_> moment mach ich mal
[12:56] <rwn_> nein geht auch nicht
[12:57] <laga> rwn_: mythfrontend --reset?
[12:58] <rwn_> habe ich gemacht
[12:59] <laga> funktioniert's?
[12:59] <rwn_> der reset ja
[12:59] <rwn_> soll ich noch mal starten
[12:59] <laga> das frontend? ja
[13:01] <rwn_> ja jetzt geht es
[13:01] <laga> cool
[13:01] <rwn_> komplett anderes themes
[13:02] <laga> ja, evtl ist das thema kaputt oder so? was für ein update war das denn? welche version von mythbuntu?
[13:02] <rwn_> danke erst mal werd mal weiter sehen
[13:02] <rwn_> das letzte von gestern morgen
[13:02] <laga> rwn_: sind irgendwelche partitionen voll?
[13:02] <laga> rwn_: und welche version..
[13:03] <rwn_> glaube ich nicht sind 500GB drin
[13:03] <rwn_> habe aber noch andere probs, denke aber das wird sich richten
[13:03] <laga> glauben ist nicht wissen :)
[13:03] <rwn_> kernel 14 und 15 starten nicht
[13:03] <laga> ah, hardy.
[13:03] <rwn_> bin mit dem 12er unterwegs
[13:04] <rwn_> ja hardy
[13:04] <rwn_> sorry hatte ich vergessen
[14:52] <user1>  iam using tv card Philips Semiconductors SAA7130 Video Broadcast De                              coder (rev 01) . i cant make it work. any help?
[15:17] <hti_pro> anyone using hardy with mythtv
[15:18] <user1> hti_pro:  you are using hardy beta?
[15:18] <hti_pro> yep
[15:18] <hti_pro> wondering if anyone had any issues
[15:18] <user1> hti_pro:  is it going fine?
[15:19] <user1> hti_pro:  did you have any issues. crashes or bugs?
[15:19] <hti_pro> only one problem so far, may not be a hardy thing thouh
[15:19] <user1> hti_pro:  what prob?
[15:19] <hti_pro> I am tryin to convert a slave backend to be the new master backend
[15:19] <hti_pro> ran apt-get install mythtv-database and it didn't give me the credentials
[15:20] <hti_pro> I think I have it now, had to dig into the ever-so-confusing mysql manual though
[15:21] <hti_pro> any one in here have any issues with the libata dma bug
[15:24] <hti_pro> oh come to find out it put the credentials in the mysql.txt file and didn't tell me bout it.  On 0.20 it at least told me it did this
[15:26] <hti_pro> this is the fourth time I reinstalled the mythtv-database package and this is the only time that it actually modified this file
[15:29] <hti_pro> ok my esc key is not working to exit the frontend
[15:30] <hti_pro> any ideas, checked the setup page and esc key is enabled
[15:31] <hti_pro> this channel is kindof dead isnt it
[18:50] <frank23> I upgraded to mythtv 0.21 in gutsy. the OSD now seems flickery and more pixelated? any ideas why that is?
[18:53] <hugolp> frank23:  I had the same problem
[18:54] <hugolp> it happens if you use a kind of deinterlacer filter
[18:54] <hugolp> change the deinterlacer system and it will go
[18:54] <frank23> hugolp: is that in playback?
[19:00] <frank23> hugolp: I set the playback profile to "slim" instead of "CPU+" and it fixed it
[20:08] <hugolp> frank23:  yes, that changes the deintercalcing mode
[20:59] <craig_> hello
[20:59] <craig_> anyone know about a dhcp3 bug on MCC?
[21:00] <tgm4883_laptop> no
[21:00] <craig_> just done a freah install and MCC always crashes with a dhcp3 error
[21:00] <tgm4883_laptop> can you post the error?
[21:01] <tgm4883_laptop> 7.10 or 8.04?
[21:01] <craig_> ConfigParser.NoOptionError: No option 'dhcp3-server' in section: 'mythbuntu'
[21:01] <craig_> 8.04
[21:02] <craig_> laga mentioned it in the forums
[21:02] <craig_> but he also said it was fixed
[21:02] <tgm4883_laptop> did you apt-get update and apt-get upgrade
[21:02] <craig_> yep
[21:02] <tgm4883_laptop> hmm
[21:04] <craig_> i did change my sources to my local ones....perhaps that made a diff?
[21:04] <craig_> changeing them back to the original ones
[21:05] <craig_> hmm, my repo must be behind
[21:05] <craig_> 25 to update
[21:06] <craig_> pure slow tho! ahhh
[21:41] <famicom_> Hold down an arbitrary button.
[21:41] <famicom_> what the hell does that mean
[21:45] <zubwolf> hi there hi there, i'm using mythbuntu and would like to know if there is a possibility to use iptv as in UDP/multicast streams from an iptv provider?
[21:54] <directhex> famicom_, it means "any button, it really doesn't matter"
[22:07] <rhpot1991> famicom_: running irrecord it seems
[22:07] <famicom_> yeah
[22:08] <famicom_> trying to get some vague remote to work
[22:08] <rhpot1991> as long as sudo cat /dev/lirc0 can see it, it should work then
[22:08] <rhpot1991> will get garbage on your screen the
[22:08] <rhpot1991> then
[22:11] <famicom_> well
[22:11] <famicom_> right now i need to replace 1 single button
[22:11] <rhpot1991> I've had funny results editing a config
[22:12] <rhpot1991> where sometimes it worked and sometimes it didn't
[22:12] <rhpot1991> but creating a new config always worked
[22:14] <famicom_> yeah i know
[22:14] <famicom_> but i gotta redo the entire fucking config just because a single fucking button is fux0red
[22:17] <rhpot1991> you can try to just modify it first, I found modifying configs as long as I wasn't adding new buttons was ok
[22:17] <rhpot1991> but adding new buttons sometimes seemed to throw things off, not always
[22:17] <rhpot1991> also watch the language
[22:18] <famicom_> well compare           Volume_Up                0x10
[22:18] <famicom_>           Volume_Down              0x11
[22:18] <famicom_> to           Volume_Up                0x0E2410
[22:18] <famicom_>           Volume_Down              0x0F2411
[22:19] <famicom_> humm, this should be right
[22:22] <famicom_> goddammit
[23:50] <tgm4883_laptop> !language | famicom_
[23:50] <ubotu> famicom_: Please watch your language and topic to help keep this channel family friendly.
[23:57] <LeChacal> can i use parts of mythbuntu on a normal ubuntu install if i want to just watch and record some shows, not use it as a dedicated DVR (or what ever the right term is)? and if i can, can some one help with some more specific questions i have, my guess is that they have been asked a million times but some of what i have read on line is confusing and i want clarification. thank you in advance.


[15:59] <mdeslaur> \o
[15:59] <pitti> o/
[16:00] <slangasek> oh; my clock on the desk is off, indicator madness
[16:01] <pitti> I haven't heard from infinity in a while, I guess he won't join today
[16:01] <slangasek> he's sent me his regrets privately
[16:01] <slangasek> #startmeeting
[16:01] <meetingology> Meeting started Tue Sep 29 16:01:39 2015 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: action commands idea info link nick
[16:01] <slangasek> [TOPIC] Apologies
[16:02] <slangasek> Adam Conrad sends his regrets
[16:02] <mdeslaur> slacker
[16:02] <mdeslaur> ;)
[16:02] <slangasek> is everyone else here?
[16:02] <pitti> stgraber isn't yet
[16:02] <pitti> and kees
[16:03] <slangasek> so just the three of us, in fact
[16:03] <pitti> let's overthrow the world!
[16:03] <slangasek> [TOPIC] Action review
[16:03] <slangasek> * ACTION: slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
[16:04] <slangasek> carried over, but getting close to the top of my todo list
[16:04] <slangasek> (I almost did it before this meeting, but this meeting snuck up faster than expected ;)
[16:04] <slangasek> * ACTION: pitti to update SRU policy amendment proposals and gather feedback
[16:04] <pitti> sent two weeks ago; kees sent +1, I haven't heard feedback from Adam
[16:05] <pitti> he said "if you don't hear from me by next meeting, consider it a silent agreement"
[16:05] <slangasek> ok
[16:06] <slangasek> I did raise the concern about whether we're going to see an increase in volume of requests for this kind of thing
[16:07] <slangasek> you said you considered that an "abuse", but to me it looks like a natural outcome of people acting according to the letter of the policy in good faith
[16:07] <slangasek> but I don't think we need to block on this
[16:07] <slangasek> * ACTION: infinity to review pitti's SRU policy amendments and +1/-1 on-list
[16:07] <slangasek> this one is superseded by events, I think?
[16:07] <pitti> if this results in backporting 5 new features every week, it's collectively too much noise/potential instability IMHO
[16:08] <pitti> i. e. if we can't keep up with verifying/reviewing any more
[16:08] <pitti> where "we" == SRU team
[16:08] <pitti> but I think this is a problem which we should address if/when we get it
[16:08] <pitti> in principle the same could happen for bug fixes
[16:08] <kees> \o
[16:08] <kees> sorry I'm late!
[16:08] <pitti> and in some cases there are SRUs which are over the top
[16:08] <pitti> hey kees!
[16:09] <pitti> but by and large it seems manageable
[16:09] <slangasek> stgraber, kees: hi there!
[16:09] <pitti> slangasek: superseded by events> according to what he told me, yes
[16:09] <slangasek> ok
[16:09] <pitti> and we can adjust it further, after all
[16:09] <slangasek> [TOPIC] Mailing list archive
[16:09] <stgraber> hello, sorry for being late
[16:09] <pitti> so should we go ahead with the SRU policy amendments?
[16:10] <slangasek> looks like the discussion was all about SRU policy this month, so that's fine
[16:10] <slangasek> [TOPIC] Community bugs
[16:10] <slangasek> [LINK] https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
[16:10] <slangasek> empty
[16:11] <slangasek> [TOPIC] Select a chair for the next meeting
[16:11] <slangasek> I believe the rotation is stgraber, with infinity as backup
[16:11] <slangasek> ?
[16:11] <pitti> right
[16:11] <stgraber> I think so yeah, note that I'll be at a sprint at the time though
[16:11] <stgraber> hopefully I won't be double-booked
[16:12] <slangasek> [INFO] Next meeting 2015-10-13, 17:00 London time. chair is stgraber, backup chair is infinity
[16:12] <slangasek> (hopefully that's right)
[16:12] <mdeslaur> I'll be on holiday, so I won't be attending
[16:13] <slangasek> [TOPIC] AOB
[16:13] <slangasek> anything else today?
[16:13] <kees> nothing from me
[16:13] <mdeslaur> nothing from me
[16:13] <pitti> do we need to vote on the SRU policy again, or do we have enough votes on teh ML?
[16:14] <pitti> I got +1 from everyone but Adam now, I think
[16:14] <slangasek> I think it's been ratified on the list
[16:14] <pitti> ack
[16:14] <pitti> so I'll update the policy and send it to u-d-a@
[16:15] <slangasek> [ACTION] pitti to update SRU policy wiki page and announce on u-d-a
[16:15] <meetingology> ACTION: pitti to update SRU policy wiki page and announce on u-d-a
[16:15] <slangasek> yay, a new action ;)
[16:15] <slangasek> #endmeeting
[16:15] <meetingology> Meeting ended Tue Sep 29 16:15:34 2015 UTC.
[16:15] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-09-29-16.01.moin.txt
[16:15] <pitti> lose 2, win 1 :)
[16:15] <slangasek> thanks, everyone!
[16:15] <pitti> thanks everyone
[16:15]  * pitti waves from Budapest
[16:16] <mdeslaur> thanks!
[16:17] <kees> cya!
[16:35] <pitti> slangasek: done/sent