[01:23] <c3rb3rus5> when is 8.04 slated to be released?
[01:23] <c3rb3rus5> nm.. 21 days it seems
[01:31] <ahave_> does anyone here use a homer run hdtv box?
[01:31] <ahave_> home*
[01:31] <c3rb3rus5> at the risk of sounding like i know nothing at all: if i install the 8.04 beta now, will i be able to update to the full version when that is released w/o reinstalling?
[01:31] <foxxbuntu> ahave_ yes
[01:32] <foxxbuntu> c3rb3rus5, yes
[01:32] <c3rb3rus5> sweet
[01:32] <ahave_> foxxbuntu, was it difficult to configure with mythtv? do you know of a link to set the system up?
[01:33] <foxxbuntu> ahave_ its easier than setting up most tuners
[01:33] <ahave_> oh?
[01:34] <ahave_> i read somewhere that i should upgrade it first
[01:34] <foxxbuntu> yep, Mythbuntu has the config util enabled by default so in mythtv-setup you can just select HDHR and create a capture device for each tuner on the HDHR, then you can scan for channels with it
[01:34] <foxxbuntu> ahave_, if you havent I would suggest it just for stability
[01:35] <foxxbuntu> heres how to upgrade it
[01:36] <foxxbuntu> cd /usr/src
[01:36] <foxxbuntu> wget http://download.silicondust.com/hdhomerun/hdhomerun_firmware_20080305.bin
[01:37] <foxxbuntu> hdhomerun_config discover
[01:37] <foxxbuntu> that will give you the ID of your HDHR
[01:37] <foxxbuntu> then:
[01:37] <foxxbuntu> hdhomerun_config <id> upgrade ./hdhomerun_firmware_20080305.bin
[01:38] <foxxbuntu> thats all there is to it ahave_
[01:39] <ahave_> ok
[01:42] <ahave> hmm
[01:43] <ahave> if i have 2 linksys routers chained together, would i have to do anything special to get the second router to see the internet?
[01:43] <ahave> static IPs?
[01:43] <foxxbuntu> what?
[01:44] <ahave> i have 2 routers on my network, i had to add an extra one to have enouth ethernet ports
[01:44] <foxxbuntu> I assume your just trying to use the switch on the seoncd?
[01:44] <ahave> yes
[01:44] <ahave> do i need to set it to 'switch only' mode?
[01:44] <foxxbuntu> you need to turn off NAT
[01:44] <c3rb3rus5> yea
[01:44] <foxxbuntu> er, switch only is what you need
[01:45] <ahave> well, is that considered router?
[01:45] <ahave> instead of gateway?
[01:45] <c3rb3rus5> the main ubuntu channel is like a flood of people
[01:45] <foxxbuntu> ahave, no, just a switch
[01:47] <ahave> foxxbuntu, ok. i am just having trouble finding that option in the linksys admin menu
[01:47] <c3rb3rus5> ahave: what model
[01:48] <ahave> wrt54g
[01:48] <c3rb3rus5> ahave: you should just be able to disable the dhcp server and that will put it into switch mode....  i might be mistaken
[01:49] <ahave> so instead of dhcp i should select what?
[01:49] <ahave> static IP?
[01:50] <c3rb3rus5> there is an option on the main page to disable the dhcp server on one....  i know i set this up before, i'm trying to refresh my memory
[01:52] <ahave> yes. i have disabled the dhcp server. but do i need to change the 'internet connection type' to something else other that DHCP?
[01:55] <c3rb3rus5> ahave: i honestly don't remember
[01:55] <c3rb3rus5> ahave: i would say yes.... is it working as it should now?
[01:56] <ahave> nope
[01:56] <c3rb3rus5> hrm
[01:56] <ahave> i feel like i need to set the IP to something different
[01:56] <ahave> like <IP_ADDRESS>
[01:57] <ahave> so that it will be its own network
[01:58] <c3rb3rus5> how do you have the routers connected right now
[02:00] <ahave> internet<->cablemodem<->wrt54G#1<->wrt54g#2(into 'internet port')
[02:01] <c3rb3rus5> so so #1's WAN port is plugged into the modem, #2's WAN port is plugged into the ethernet ports of #1?
[02:01] <ahave> yes
[02:03] <c3rb3rus5> did you try setting it (#2) to a router instead of a gateway under advanced routing?
[02:06] <ahave> not with DHCP disabled
[02:07] <c3rb3rus5> the 2 routers are not set to the same IP address are they?
[02:07] <ahave> now i have made a much of things.. i chanaged the IP of the router and lost connection to it. so i did a hard restart and now it is acting very odd
[02:08] <c3rb3rus5> hows it acting odd?
[02:08] <ahave> as in i can not obtain an IP from it
[02:09] <c3rb3rus5> are you behine router 1 or 2?
[02:10] <ahave> i am using a laptop to connect to the internet right now through router 1
[02:10] <c3rb3rus5> the easiest way to get this to work is to disable the dhcp server on #2, and plug one of #2's ethernet ports into one of #1's eethernet ports
[02:10] <ahave> my mythtv box is under 2
[02:10] <c3rb3rus5> that should make use of the switch functionality of #2
[02:10] <ahave> oh
[02:10] <ahave> i have never heard of that
[02:11] <ahave> so do not plug in the ethernet of router1 into 'internet' of router2?
[02:11] <ahave> but instead plug the wire into one of the 4 output ports?
[02:13] <ahave> WOW. that worked
[02:13] <ahave> i have never heard of that before
[02:13] <ahave> sweet
[02:14] <ahave> thank you very much
[02:18] <c3rb3rus5> ahave: no prob
[02:19] <c3rb3rus5> the other way would be to use advanced routing settings with the way you had it set up.. i'm honestly not too sure how to set them up in practice
[02:25] <foxxbuntu> c3rb3rus5, the issue is with the firmware linksys provides you can't turn off NAT properly so you end up double natting, this causes a packaet failure between the devices
[02:30] <c3rb3rus5> yea?
[02:31] <c3rb3rus5> i remember setting it up once...
[02:31] <c3rb3rus5> on second thought i might have been using a different model they made
[02:31] <c3rb3rus5> and that same model failing shortly after
[02:31] <c3rb3rus5> :-/
[02:31] <c3rb3rus5> it was older
[02:32] <c3rb3rus5> i have been meaning to put openwrt on my wrt54g for a while now, never got around to it
[02:34] <c3rb3rus5> anyone here use virtualboxat all?
[02:43] <ahave> so now that i have the backend setup for HDhomerun, how can i select HD channels when watching liveTV?
[02:44] <foxxbuntu> ahave, did you scan for, and add the HD channels?
[02:44] <ahave> i was not able to find the HD tuner on the scan from source list
[02:47] <ahave> hmm, wait. i am scanning on the tunner now
[05:17] <guardoftheguards> Hey. Having problems setting up a Hauppauge PVR-350's video out.
[05:17] <guardoftheguards> I checked out this tutorial (https://help.ubuntu.com/community/MythTV_Gutsy_hardware_pvr-350_TV-out), but it's not working for me still.
[05:18] <guardoftheguards> I'm able to cat video to the device, but X won't start into it, seemingly ignoring my xorg.conf, and videos launched from the myth frontend result in initialization errors.
[05:21] <guardoftheguards> Anyone have that problem?
[08:58] <xukun> hi all. when I watch dvd with mythbuntu then I get two vertical lines and the movie is not full screen. If I play the same movie with player or vlc then its fullscreen
[09:00] <xukun> is there some kind of settings that I need to change in mythubuntu?
[09:17] <|DuReX|> hello, I got a new tv card, Hauppauge HVR-1300, seems like its getting seen perfectly in ubuntu dmesg output :http://pastebin.com/m61491e91  but I'm getting errors and can't use it :(
[10:20] <Tuv0k> W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/hardy-security/Release  Unable to find expected entry  web/binary-i386/Packages in Meta-index file (malformed Release file?)
[12:48] <|DuReX|> nboody awake ? :(
[12:56] <directhex|work> the hvr1300 is highly experiemntal
[12:56] <directhex|work> you probably want linuxtv hg
[12:57] <|DuReX|> doesn't work there neither :(
[13:00] <|DuReX|> there are tons of websites where people say it works perfectly
[13:00] <|DuReX|> but I can't get it working
[13:00] <|DuReX|> it gets seen perfectly etc
[13:00] <|DuReX|> but just error :(
[13:00] <|DuReX|> http://pastebin.com/m61491e91
[13:00] <|DuReX|> the dmesg
[13:02] <directhex|work> you're trying to use the mpeg encoder?
[13:02] <directhex|work> or the digital part?
[13:03] <|DuReX|> trying to get DVB-T working
[13:04] <|DuReX|> it gives those messages @ boot
[13:04] <|DuReX|> when I didn't even try to access the card
[13:05] <directhex|work> those messages look related to the mpeg encoder
[13:05] <directhex|work> cx88 is the digital-related chip
[13:08] <TelnetManta> do you guys support mythbuntu or ubuntu with myth installed from the repos?
[13:08] <directhex|work> TelnetManta, same difference
[13:08] <TelnetManta> about to build a new backend and wondered which I should install
[13:09] <TelnetManta> isnt mythbuntu an iso all in itself? myth already installed I mean.
[13:09] <directhex|work> yes
[13:09] <TelnetManta> ah, there we go, I found it :)
[13:10] <directhex|work> but all the packages in mythbuntu are in ubuntu's repositories
[13:10] <TelnetManta> I need to get the source code to apply some patches. guess I need to learn how to do that. I've always installed myth from source.
[14:15] <dergringo> hi
[14:15] <dergringo> Is this a goob board for a HTPC? http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=550
[14:15] <dergringo> what do you think
[14:16] <directhex|work> via? the default answer is no
[14:16] <directhex|work> i shall now look at the url. i may laugh at you
[14:16] <directhex|work> epia. HAHAHAHAHAHAHAHAHAHAHAHA
[14:16] <dergringo> ?
[14:17] <directhex|work> c7 is bullshit & chips. it can't do htpc in standard def, let alone high def
[14:17] <|DuReX|> i installed latest linuxtv hg, but i'm getting: http://pastebin.com/m10375cf4
[14:17] <|DuReX|> any id's ?
[14:17] <dergringo> directhex|work: So what mini ITX boards do you recommend?
[14:18] <directhex|work> give http://www.hexus.net/content/item.php?item=11976 a read to see how screaming fast epia is
[14:18] <directhex|work> dergringo, a mac mini's generally the best of breed for small form factor
[14:19] <directhex|work> |DuReX|, your module's crashed. talk to the linuxtv people about it
[14:21] <dergringo> directhex|work: It may be the best in some cases. But I need at least 3 hotswappable 3.5 HD slots. So I think this one would fit my benefits: http://www.mini-itx.com/store/?c=42
[14:21] <dergringo> Now I am looking for a board
[14:22] <dergringo> The one you linked is a pico-ITX board. And it is something really different that I am talking about
[14:22] <directhex|work> dergringo, my professional opinion, backed with experience, is that epia *cannot cope* with modern demands. 1ghz c7 is 1ghz c7 - still a million miles from what media needs
[14:23] <directhex|work> talk to any former epia owner in here, e.g. justinh, and you'll hear the same thing
[14:23] <directhex|work> what's a better choice? *anything else*
[14:23] <directhex|work> any board that isn't powered by an IDT WInChip is a reasonable choice
[14:24] <directhex|work> the intel D201GLY2, for example, with its screaming fast 1.2ghz celeron, will obliterate any hardware via has to offer, several times over
[14:25] <directhex|work> jetway, commell, anhd a few others will do "real" cpus on mini-itx form factor (if you want to pay for them)
[14:25] <directhex|work> i think aopen do too. i'd need to check
[14:26] <dergringo> Cool. Thanks. I tought VIA does a good job. Well I'll have a look at the others too.
[14:26] <directhex|work> via do a terrible job
[14:27] <directhex|work> look at it this way - a c7 running at 1ghz is 3x slower than an athlon64 running at 1ghz
[14:27] <dergringo> I just do not want to spend a lot of money, since I need raid disks and so. Else it's getting too expensive
[14:28] <directhex|work> if you want a NAS box, buy an off-the-shelf NAS box. if you want a media box, save up more money. a penny spent on epia is wasted money
[14:29] <directhex|work> aopen's range seems comprehensive - socket m, socket p, socket am2
[14:30] <dergringo> I don't want a off-the-shelf NAS. I need customized encryption using a USB token. I want full control over the system.
[14:32] <dergringo> is it possible to install linux on a aopen system?
[14:33] <directhex|work> why wouldn't it be?
[14:33] <dergringo>  	The IR / Remote Control of AOpen accessory is not supported under Windows XP and Windows XP MCE.
[14:33] <dergringo> so is it supported on linux?
[14:34] <directhex|work> which board is that?
[14:34] <dergringo> This is a full featured system: http://minipc.aopen.com/Global/spec.htm
[14:35] <directhex|work> the mac-mini-sized-and-shaped-but-slower-and-more-expensive mini aopen pc?
[14:36] <dergringo> lol
[14:36] <dergringo> exactly
[14:36] <directhex|work> supported in lirc cvs
[14:37] <Kevin`> that's probably better then my current mythtv system, but it's also brand new and mine is years old =p
[14:38] <dergringo> So you recomment these boards? http://www.aopen.de/Products.aspx?id=52
[14:39] <directhex|work> recommend is such a strong word. those are 2 possibilities worth considering, sure. like i said, anything not winchip-powered is worth a look
[14:39] <directhex|work> and a few people in here use aopen small form factor boards with intel cpus
[14:40] <dergringo> Serial ATA II Connector x 2    :(
[14:40] <dergringo> all of them
[14:41] <Kevin`> can those cases even fit more then 2 drives?
[14:43] <dergringo> Kevin`: http://www.mini-itx.com/store/?c=42  Can fit 6
[15:04] <dergringo> mhhh maybe I should just stick in a
[15:04] <dergringo> controller
[16:08] <fer_luck> howdy all
[16:08] <fer_luck> someone compiled the saa7134_alsa module for beta 8.04?
[16:13] <fer_luck> ?
[18:17] <keescook> say, has anyone checked if mythtvfs-fuse work with the current mythtv in hardy?  I really should check that.  :P
[19:00] <dergringo> directhex|work: http://www.tweaktown.com/reviews/1308/1/page_1_introduction/index.html
[19:01] <dergringo> That does sound very good
[20:37] <EvilGuru> dergringo: Strange lack of firewire...
[20:41] <EvilGuru> I can understand the lack of optical audio out and DVI


[03:59] <pleia2> putting together the "other stuff" in the newsletter now, hopefully my blog post will lure in some more summary-writing volunteers
[04:01] <zkriesse_> pleia2: need more writers eh?
[04:02] <pleia2> zkriesse_: yeah, need people to write article summaries on https://docs.google.com/Doc?docid=0AdKZelXU8Y2LZGNrcHRkYmhfODlkODNxNnRnZA&hl=en&pli=1
[04:02] <pleia2> a bunch are done, just need a few more
[04:03] <holstein> i should have some time in the AM
[04:03] <pleia2> thanks holstein :)
[04:03] <holstein> but, i dont want to be the only one writing them
[04:03]  * pleia2 nods
[04:03] <pleia2> I'll work on some after I finish populating the other stuff
[04:03] <holstein> ill try and recruit as well :)
[04:04] <holstein> folks can do it that are *not* on the irc
[04:04] <holstein> its just a bit challenging to know when they are working on them
[04:04] <holstein> when i was grabbing articles, i just went ahead and summarized them as i went
[04:05] <holstein> that would be ideal
[04:05] <holstein> assuming its not just you grabbing a bunch at once
[04:05] <pleia2> when I'm grabbing links I'm just doing my regular rss reading, stopping to do summaries wouldn't work for me
[04:06] <holstein> yeah.. not ideal
[04:06] <holstein> we'll get some more help
[04:08] <pleia2> oh nice, you can actually log into the wiki in a timely manner these days
[04:08]  * pleia2 hadn't logged in on this computer since before the upgrade
[04:08] <holstein> thats great
[04:09] <holstein> its usually slooooow
[04:24] <pleia2> nhandler: do you remember where you got "unconfirmed" bugs number? it's way higher when you pulled it than in any other issues lately
[04:25] <pleia2> I think the rest of us had just been using "new" for that
[04:54] <pleia2> ok, I wrote some summaries and moved several sections over to the wiki
[05:08] <pleia2> and now everything with completed summaries is moved over, just need 8 or so more summaries
[07:40] <NRWlion> hi there
[10:05] <alourie> hello
[10:06] <alourie> where is the place for volunteers gathering? :-) ....
[10:07] <MooDoo> alourie, volunteering for what? ubuntu news?
[10:22] <alourie> MooDoo: yes... pleia2 is the address I believe :-)
[10:23] <MooDoo> alourie, yeah just ping her and she'll get back to you, it's 3:25 am where she is right now :)
[10:24] <alourie> right
[10:25] <alourie> pleia2: ping ^^
[10:25] <MooDoo> just a case of leaving yourself in the channel i guess unless anyone else can help, i'm sure if they are reading this they will speak up :)
[10:36] <NRWlion> hey alourie
[10:40] <alourie> NRWlion: hi
[10:40] <alourie> MooDoo: that's OK, I'm leaving it on
[10:43] <alourie> and I know that there are a lot of knowledgeable people around here...
[10:44] <MooDoo> :)
[10:44] <alourie> I'm expecting this to be resolved quite fast :-)
[10:44]  * NRWlion reports for service
[10:44] <MooDoo> alourie, i just said that in case there was anyone else around that could give you advice as pleia2 is assleep :)
[10:45] <NRWlion> alourie: how are we able to help out?
[10:46] <alourie> NRWlion: excellent :-)
[10:46] <alourie> NRWlion: she sent a callout for help
[10:46] <alourie> regarding links summaries
[10:46] <NRWlion> alourie: indeed we could use help
[10:46] <alourie> so I think I can do that (as I did it for awhile, circa half a year ago, just before we stopped_
[10:46] <alourie> )
[10:47] <NRWlion> alourie: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/EditingPolicies/SuggestedHowToEdit << have a read here
[10:48] <NRWlion> this is our checklist for each issue
[10:48] <NRWlion> :D
[10:48] <alourie> NRWlion: oh, it's ordered now :-), I've read it when it was much messier
[10:49] <alourie> it's nicer this way, really
[10:49] <NRWlion> alourie ok any other question?
[10:50] <NRWlion> pleia is doing an awesome job
[10:50] <NRWlion> :D
[10:50] <alourie> indeed
[10:51] <alourie> NRWlion: well, she wanted volunteers for the "In The Press" summaries, I guess
[10:53] <alourie> so I'd like to get back to doing that
[10:53] <alourie> so, do I need to work this out with Liz?
[10:53] <alourie> pleia2 I mean
[10:55]  * NRWlion knows who Liz is ;)
[10:55]  * alourie is just not sure he can call her Liz :-)
[10:56] <MooDoo> call her what you like she's not here to defend herself....*EVIL CACKLE* [yeah i know her] :)
[10:56] <alourie> excellent
[11:00] <alourie> so I'll wait for her then
[12:39] <NRWlion> hi cheri
[15:11] <nhandler> pleia2: Yeah, I thought it was a bit strange. I think the comment for that section said to use the number of 'new' bugs
[16:01] <pleia2> yeah, new is what should be used, and that's been hovering around 49k
[16:11] <nhandler> pleia2: Ah, I see what happened. I was logged in to launchpad at the time, and I can see more bugs. If I'm not logged in, I get a number similar to what we have had in the past
[16:11]  * nhandler goes to update the non summary sections
[16:12] <nhandler> Or did you do them already?
[16:12] <pleia2> yeah, I did them
[16:13]  * nhandler hugs pleia2
[16:13] <pleia2> ok, for new bugs we can just do "since last issue"
[16:13] <nhandler> That works.
[16:45] <pleia2> 4 people emailed to help \o/
[16:45] <pleia2> still need those 8 summaries on https://docs.google.com/Doc?docid=0AdKZelXU8Y2LZGNrcHRkYmhfODlkODNxNnRnZA&hl=en&pli=1
[16:53] <pleia2> ok, once we get the rest of these summaries we will have it in an editable state, should be good to release this evening
[16:54]  * pleia2 > work
[17:17] <pleia2> akgraner got us the link for what sites we should browse for news :) https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/LinkSuggestions
[17:19] <pleia2> added to HowToEdit document
[17:21] <pleia2> I'll review the suggested new template this week and see about transitioning to it (I'm manually doing some edits to the current template, which feels silly
[17:28] <holstein> pleia2: well... i cant say its done, but i can say im done ;)
[17:28] <holstein> bbl...
[17:28] <pleia2> thanks holstein!
[17:59] <pleia2> oops, forgot to add dev team meetings
[18:07] <pleia2> ok, we're ready for editors! https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue223
[18:08] <pleia2> our credits are looking sparse, was there anyone else last week helping out?
[18:08] <pleia2> alourie: if you're looking for something to help with, review is a nice place to start :) make sure all links work, check grammar and foramtting
[18:09]  * pleia2 work &
[18:18] <pleia2> hey Gareth!
[18:18] <Gareth> pleia2: howdy :)
[18:18] <pleia2> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue223 is what we're reviewing :)
[18:18]  * Gareth looks
[18:21] <Gareth> In the "Get ready for Ubuntu Developer Week" section, "sometimes of presentations" doesnt sound right to me.  Seems like it should be "sometimes as presentations"
[18:23] <pleia2> yeah
[18:27] <Gareth> pleia2: went through the rest, couldn't find any issues.  Looks good.
[18:28] <pleia2> thanks :)
[18:28] <Gareth> np
[20:36] <pleia2> anyone else available to proof? we also need to do the quick, tedious work of confirming that all the links work


[00:13] <maco> anyone know how locobot_3 works?
[00:14] <maco> its "help" thing just says "help <plugin> <command>" but doesnt list the plugins available
[00:14] <maco> or maybe doesnt have any plugins?
[00:19] <m4v> maco: it probably only uses supyboy's plugin for loggin, which doesn't have any comands
[00:19] <maco> whats teh point of a bot that doesnt DO anything?
[00:20] <m4v> isn't just there for logging?
[00:20]  * pleia2 pats ubot4
[00:21] <m4v> maco: it logs the channel, that's the only purpose of the locobots
[00:21] <maco> where do these logs go?
[00:21] <maco> weve had one in the dc channel for ages but never have seen any sign of the existence of logs
[00:21] <m4v> maco: http://logs.ubuntu-eu.org/free
[00:23] <maco> thanks
[00:23] <maco> so umm if we wanted to borrow MootBot for a meeting at some point... how would we do that?
[00:23] <pleia2> asking in is still the process #ubuntu-scribes afaik
[00:24] <pleia2> https://wiki.ubuntu.com/ScribesTeam/MootBot
[00:24] <pleia2> wow, those words got all mixed up
[00:24] <pleia2> asking in #ubuntu-scribes is still the process afaik
[00:24] <pleia2> there we go! bad paste
[00:24] <maco> pleia2: thanks lyz
[10:55] <drubin> Hi do I speak to about getting the loco-log bot back in our channel #ubuntu-za?
[10:55] <drubin> s/do/who do/
[10:57] <DJones> drubin: reading https://help.ubuntu.com/community/InternetRelayChat#LogBots, that says to email<EMAIL_ADDRESS>for LoCoBot
[10:57] <DJones> Sorry<EMAIL_ADDRESS>[11:01] <DJones> or has it just fallen off irc
[11:17] <DJones> Just looking, locobot_3-5 & 1 are online, but locobot_2 is missing, from memory, thats the one that is normally in -uk.  There's no logs since 9:28 on 30th Jan
[11:19] <jussi01> Srill probably best to drop them an email imho.
[11:20] <DJones> cheers, I'll drop them an email
[11:43] <drubin> DJones: Thanks.
[16:54] <drubin> DJones: Thanks your email must have done it, All fixed now. :)
[17:41] <niko> drubin: another solution is probably to query zed
[17:43] <drubin> niko: It is fixed now though but I will keep it in mind for future thanks.
[20:32] <erUSUL> !intelhda
[21:03] <erUSUL> !wubi
[21:23] <bazhang> erUSUL, plustax may be  a troll
[21:25] <erUSUL> any reason to think that?
[21:26] <bazhang> seriously trolling in -ot and the odd few answers in #u when he entered
[21:26] <bazhang> 'cant use the terminal' etc
[21:35] <erUSUL> bazhang: well he stoped answering me ...
[22:55] <JayCool> ikonia: Are you there?
[22:55] <ikonia> yes ?
[22:56] <JayCool> Hey im sorry about everything man.
[22:56] <ikonia> ok
[22:56] <JayCool> what do i have to do to not be hated by you anymore ?
[22:56] <ikonia> does that include telling lies in #ubuntu-ops and behaving like a child 5 minutes ago ?
[22:57] <JayCool> sure
[22:57] <ikonia> just cheking your admiting to that now
[22:57] <JayCool> yeas
[22:57] <ikonia> you're not hated, you're just not allowed in the channels due to your behaviour/attitude and ban doding
[22:58] <ikonia> if you wish to join #ubuntu-ops to discuss your ban that is the correct place


[01:35] <The_LoudSpeaker> Hii folks. anyone around? We, at #lubuntu-devel, have a little problem. Can you help? The new login button on xscreensaver page doesn't work. A workaround is to install a gdmflexiserver executable into path which should point to 'dm-tool switch-to-greeter'. But it looks like dm-tool is provided only with lightdm and we are using sddm. How have you guys overcome this? Any leads are appreciated.
[01:35] <The_LoudSpeaker> TIA!
[02:42] <The_LoudSpeaker> ^ RikMills:
[08:03] <RikMills> The_LoudSpeaker: we don't use xscreensaver for years! plasma has its own lockscreen and that is it
[08:42] <The_LoudSpeaker> Oh. I see.
[08:42] <The_LoudSpeaker> Thanks! RikMills:
[10:36] <vip> hi ho
[10:41] <RikMills> morning
[12:11] <BluesKaj> HI folks


[17:17] <phillw> flexiondotorg: once you have caught up, please give me a ping re:ppc testing and an offer of a backup facility
[17:18] <flexiondotorg> phillw, I'll be testing Ubuntu MATE PowerPC tomorrow.
[17:19] <phillw> flexiondotorg: would you give the lubuntu ones a try... just for to see how badly broken they are. In theory, as it is same core - they *should* behave :)
[17:21] <phillw> flexiondotorg: also there is a server area hosts isos / backups etc for teams. If you need only ~100 GB space there is room on that server for ISO's and any backups your team may want to place on there.
[17:22] <flexiondotorg> phillw, Thanks for the offer.
[17:28] <phillw> some use it, it takes a couple of minutes to set up.
[17:41] <phillw> flexiondotorg: for ISO's http://phillw.net/isos/ is a good mirror to suggest if you do not expect too many seeders. It can handle 100 Mb/s on the back bone and has a slight claim to fame that one of release team asked for the link on release day about a zero day bug owing to the fact cdimage was struggling... it and cdimage average 10Mb/s transfers, so I've got a guess as to who provides canonical internet :P
[17:49] <phillw> wxl: bug 1484785
[17:50] <phillw> it is not in progress, however you may like to point tsimonq2 into bug territory for having it reported correctly as being in progress.
[22:58] <phillw> wxl: any reason for the global respin?


[00:07] <Bashing-om> daftykins: Amazing creatures of habit that we are . We managed to survive - @ 12 hours they had the distributuion system patched . The fix still pending .
[00:08] <daftykins> :D
[00:08] <daftykins> that's rapid
[00:08] <daftykins> i was always a bit puzzled by US infrastructure being overhead
[00:10] <Bashing-om> From the looks of it I had expected several days to get service restored . Was sure relieved - and pleasanly surprised - when the modem lit up !
[00:12] <daftykins> i'll bet!
[00:12] <daftykins> when i lived in England, keeping the strange hours i did, i used to be muchly dismayed when the service would often go down at 1am and i'd have a forced early bedtime :)
[00:14] <Bashing-om> When you can do nothing else, sleep !
[00:26] <daftykins> :D
[01:40] <OerHeks> some issues i don't understand, is ti me?
[01:40] <OerHeks> *it
[01:44] <daftykins> users are weird
[01:45] <OerHeks> autologin, no pass on screensaver, and one is almost free.
[01:46] <daftykins> :D
[01:46] <daftykins> free to break it all!
[09:34] <lordievader> Good morning
[13:44] <lotuspsychje> hey cfhowlett, seen your artpage, nice!
[13:44] <cfhowlett> :)  thanks.  we actually have more submissions than the main ubuntu art showcase contest
[13:45] <lotuspsychje> lol
[14:37] <BluesKaj> Hiyas all


[00:08] <gsilvapt> kyrofa, about the command, the only way I can make them match is if I explicitly set the string to be "snapcraft, version xxx" in both commands. Is that okay?
[00:09] <kyrofa> gsilvapt, I'd leave the Click one `prog`
[00:09] <gsilvapt> kyrofa, sounds okay to me but the problem is that when you run the tests it does not print snapcraft. Instead it prints run, version xxx
[00:10] <gsilvapt> Maybe that is related with the tests, I do not know
[00:10] <kyrofa> gsilvapt, oh that's unfortunate indeed
[00:10] <kyrofa> gsilvapt, yeah, hardcode it then
[00:10] <gsilvapt> Ok, I will do that, verify again the tests and submit the changes
[00:10] <gsilvapt> kyrofa, thank you!
[00:50] <mup> Issue snapcraft#1666 closed: Refactor to support elf patching <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1666>
[00:50] <mup> PR snapcraft#1744 closed: elf: conversion from libraries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1744>
[01:50] <mup> PR snapcraft#1725 closed: tests: share the cache in ros tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1725>
[05:56] <mborzecki> morning guys
[06:31] <mup> PR snapd#4264 closed: tests: force delete when tests are restore to avoid suite failure <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4264>
[06:39] <mup> PR snapd#4240 closed: spread.yaml: increase workers for opensuse to 3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4240>
[06:53] <mup> PR snapd#4266 opened: snapstate: add new refresh-hints helper and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4266>
[07:01] <zyga-ubuntu> good morning
[07:02] <mvo> hey zyga-ubuntu , good morning
[07:11] <zyga-ubuntu> :-)
[07:11] <zyga-ubuntu> I'm still in non-{wayland,x} text mode
[07:12] <zyga-ubuntu> using another computer for code reviews
[07:12] <zyga-ubuntu> this is particularly refreshin
[07:12] <zyga-ubuntu> lots of free memory and full-screen, single focus applications
[07:13] <mvo> zyga-ubuntu: haha, nice
[07:23] <zyga-ubuntu> I spent some time yesterday trying to untangle our prepare/restore code
[07:23] <zyga-ubuntu> if not permanantly then at least enough to get good measurements of what is changing
[07:23] <zyga-ubuntu> and I must say that code is complex and confusing
[07:24] <zyga-ubuntu> not just in the actions taken but in their placement and justification
[07:24] <zyga-ubuntu> (or lack or thereof)
[07:24] <mvo> zyga-ubuntu: yeah, its all over the place
[07:25] <zyga-ubuntu> I'll keep at it as it needs to be in proper shape to detect tests that change too much
[07:40] <mup> PR snapd#4267 opened: snapstate: move catalogRefresh into its own helper  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4267>
[07:46]  * kalikiana o/
[07:46] <zyga-ubuntu> mvo: review on 4266
[07:48] <mvo> zyga-ubuntu: ta
[07:50] <zyga-ubuntu> I marked it as changes requested but just midlly so, we can merge this quickly
[07:59] <mvo> zyga-ubuntu: thanks, the can-auto-refresh question is interessting as it raises a bigger questions
[08:01] <mvo> pedronis: do you think the new refresh-hints code should also consult "CanAutoRefresh", or should we do the refresh-hints even if the device is still bootstraping? I guess we want to honor CanAutoRefresh but I want to double check. I also think you are right about RefreshOptions:RefreshNop, I think we want this, I will followup on this
[08:03] <mvo> zyga-ubuntu: thanks again for the quick review :)
[08:03] <zyga-ubuntu> :-)
[08:26] <pedronis> mvo: yes, I think we want to consult CanAutoRefresh  (otherwise will just consider partial information or don't have a device session yet)
[08:28] <mvo> pedronis: +1 - thank you
[08:56]  * zyga-ubuntu tries something mergable instead
[09:00] <zyga-ubuntu> mvo: trivial merge on 4268
[09:00] <mup> PR snapd#4268 opened: spread.yaml: move prepare-each closer to restore-each <Created by zyga> <https://github.com/snapcore/snapd/pull/4268>
[09:11] <mup> PR snapd#4269 opened: timeutil: new refresh timer parser <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4269>
[09:13] <mup> PR snapd#4270 opened: timeutil: remove support to parse weekday schedules <Created by mvo5> <https://github.com/snapcore/snapd/pull/4270>
[09:16] <mvo> mborzecki: heh, looks like we need to solve conflicts here ;) either way is fine with me, I can wait for your merge or you can review mine and merge into yours (or wait until master is in)
[09:16] <mvo> mborzecki: should be very simple in any case
[09:17] <mborzecki> mvo: yup, i'm wiring a comment on gh
[09:18] <mborzecki> i'm actually using some of the pieces that you remove :)
[09:18] <mvo> mborzecki: yeah, happy to revert those bits
[09:19] <mvo> mborzecki: the key of the PR (I can make it smaller) is that the weekday parsing in v1 is not supported in snapstate so its dead code and caused one confusion in the validation already
[09:21] <mborzecki> hmm ok, i mean it's not a big problem, if it gets merged before 4269, i'll just bring back the missing pieces
[09:22] <mvo> mborzecki: no worries, I can do that now to make your life easier, its the weekday part of the struct and the weekdayMap that you need, right?
[09:23] <mborzecki> but i'm guessing 4269 will be a longer review, so I wouldn't want to block you
[09:23] <mvo> mborzecki: yeah, let me rework my PR (was not aware of yours) so that the impact for you is minimal
[09:24] <mborzecki> mvo: only if you have time for this, otherwise i can fix this myself in my PR
[09:25] <mborzecki> mvo: would appreciate you taking a look at 4269 BTW :)
[09:26] <mvo> mborzecki: re-added the weekday/weekday map now. I check the other one out once I finished my current PR. I glanced over it and it looked good from a very brief look
[09:34] <mborzecki> mvo: thanks
[09:49] <zyga-ubuntu> hmm
[09:50] <zyga-ubuntu> so, what does ${GOPATH%%:*} expand to?
[09:50] <zyga-ubuntu> because as far as I can see, to nothing at all
[09:51] <zyga-ubuntu> %% will strip the longest suffix of "*" which is everything
[09:51] <jamesh> it'll strip the suffix of ":*" -- not "*"
[09:52] <jamesh> so effectively remove everything including and after the first colon
[09:53] <zyga-ubuntu> are you sure?
[09:53] <zyga-ubuntu> ah
[09:53] <zyga-ubuntu> right, I made a typo in my tests
[09:53] <zyga-ubuntu> thanks!
[09:55] <zyga-ubuntu> :-)
[09:56] <zyga-ubuntu> mvo: can you please force-merge 4268
[09:57] <zyga-ubuntu> I could try again and waste an hour but I think the situation is riddiculus enough not to do that
[09:57] <zyga-ubuntu> and the error is clearly some store flue on refresh deltas
[09:59] <mup> PR snapd#4268 closed: spread.yaml: move prepare-each closer to restore-each <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4268>
[10:00] <zyga-ubuntu> thanks!
[10:01] <zyga-ubuntu> mvo: another quick PR to look at 4271
[10:01] <mvo> yw
[10:02] <mup> PR snapd#4271 opened: spread.yaml: fix shellcheck issues and trivial refactor <Created by zyga> <https://github.com/snapcore/snapd/pull/4271>
[10:17] <zyga-ubuntu> mborzecki: errors in your schedule PR
[10:18] <zyga-ubuntu> mborzecki: real unit tests failures in overlord/snapstate
[10:18] <mborzecki> zyga-ubuntu: thx, on it
[10:18] <zyga-ubuntu> mvo: btw, I'm on FF57 now (actually on nightly so 59) and I can use umatrix
[10:18] <zyga-ubuntu> mvo: try again, maybe your extension was fixed now
[10:19] <zyga-ubuntu> mvo: ff 59 with umatrix is the fastest browser on any system I used
[10:19] <zyga-ubuntu> (umatrix cutting the number of crap javascript from ads and tracking)
[10:22] <mvo> zyga-ubuntu: I have a bunch that I missed, but things are mostly good again. umatrix, cookie auto-delete, noscript are my essential ones, I also have a custom one that I need to port in time (based on the passhash extension)
[10:22] <mborzecki> mvo: things are fast again!
[10:23] <mup> PR snapd#4272 opened: snapstate: ensure RefreshSchedule() gives accurate results <Created by mvo5> <https://github.com/snapcore/snapd/pull/4272>
[10:25] <pedronis> mvo: ^  the description  there has "git push ..." in the middle, could you fix it
[10:25] <mvo> pedronis: autsch, sorry for that
[10:25] <pedronis> not sure if it lost bits or just need the bit removed
[10:27] <mvo> pedronis: apparently a wrongly focused window, the original commit message is correct
[10:27] <mvo> pedronis: most of the PRs this morning are based on what we talked about yesterday, I they capture your suggestions, they should make 4161 simpler
[10:33] <zyga-ubuntu> mvo: review on 4272
[10:33] <zyga-ubuntu> mborzecki: do you think 4269 can be split?
[10:34] <zyga-ubuntu> mborzecki: I'm often doing small reviews while waiting for local spread run to finish but 1K PR is not in that class
[10:34] <mborzecki> for sure i can put the first 2 patches in a separate pr
[10:34] <zyga-ubuntu> mborzecki: thank you, I'll gadly review that
[10:39] <mup> PR snapd#4273 opened: timeutil: introduce helpers for weekdays and TimeOfDay <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4273>
[10:39] <mborzecki> zyga-ubuntu: ^^
[10:41] <zyga-ubuntu> thanks
[10:43] <Chipaca> mborzecki: doesn't that TimeOfDay Add method mess up on DST change?
[10:43] <Chipaca> 11pm + 6h isn't always 5am
[10:43] <zyga-ubuntu> Chipaca: I commented on a similar aspect
[10:44] <zyga-ubuntu> mborzecki: commented
[10:44] <mborzecki> hmm not sure you can do anythign about this TimeOfDay as it's not aware of actual date
[10:45] <zyga-ubuntu> mborzecki: yeah, it depends on how it is used
[10:47] <Chipaca> zyga-ubuntu: i think we can ignore leap seconds though -- we're explicitly not supporting them as a valid time
[10:47] <zyga-ubuntu> Chipaca: +1
[10:47] <mup> PR snapd#4271 closed: spread.yaml: fix shellcheck issues and trivial refactor <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4271>
[10:47] <mborzecki> imo, it's the same way as time.Time.Add() is not aware of DST only until you do presentation
[10:48] <Chipaca> mborzecki: it all depends on how this is then used, though
[10:50] <zyga-ubuntu> Chipaca: trivial 4274
[10:50] <mup> PR snapd#4274 opened: spread.yaml: bump delta ref to 2.29 <Created by zyga> <https://github.com/snapcore/snapd/pull/4274>
[10:51] <Chipaca> that's a review size i can _do_
[10:51]  * Chipaca in pain and on pain meds -- not a good combo
[10:54] <pedronis> Chipaca: :(
[10:54] <Chipaca> pedronis: ¯\_(ツ)_/¯
[10:55] <mup> PR snapd#4275 opened: spread.yaml,tests: move most of project-wide prepare/restore to separate file <Created by zyga> <https://github.com/snapcore/snapd/pull/4275>
[10:55] <zyga-ubuntu> Chipaca: take care, I'm sorry for your pain :|
[10:55] <zyga-ubuntu> another small refactor for spread.yaml ^
[10:55] <zyga-ubuntu> 10% executed locally so I assume it's okay, rest will show up in real testing
[10:56] <Chipaca> zyga-ubuntu: this one is to work with your changes to spread?
[10:56] <zyga-ubuntu> Chipaca: this is all preparation work, I made so many changes trying to untangle and understand this it was impossible to review
[10:56] <zyga-ubuntu> Chipaca: I can propose the spread PR for reference
[10:56] <zyga-ubuntu> Chipaca: the problem is we don't really prepare/restore cleanly
[10:57] <zyga-ubuntu> Chipaca: and I will hopefully changed that by EOD, without introducing any extre time costs
[10:57] <zyga-ubuntu> Chipaca: have a look at spread#47 please
[10:57] <mup> PR spread#47: Add support for project-wide measure-each stanza <Created by zyga> <https://github.com/snapcore/spread/pull/47>
[10:57] <kalikiana> zyga-ubuntu: I'm getting this again :-( ` open /var/lib/snapd/hostfs/home/cris/snap/lxd/common/snapcraft9xy6a3v1/core_3440.assert: no such file or directory [...] subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/cris/snap/lxd/common/snapcraft9clif0ke/snapcraft_x1.snap', 'helga:snapcraft-multipass/run/snapcraft_x1.snap']' returned non-zero exit status 1.`
[10:58] <zyga-ubuntu> kalikiana: which of the files is missing? any denials?
[10:59] <zyga-ubuntu> Chipaca: in my approach the measure-each code ensures that files on / (and just that filesystem) and outside of /tmp don't change, mount table doesn't change, packages don't change and sysctl doesn't change
[10:59] <zyga-ubuntu> Chipaca: but it changes all the time as prepare/restore is a bit wonky and I need to clean it up before addressing some real problems
[11:01] <mup> PR snapd#4253 closed: task tunner: extended task runner test <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4253>
[11:01] <kalikiana> zyga-ubuntu: not that I can see...
[11:02] <kalikiana> I'm trying again with `snappy-debug scanlog` open
[11:02] <kalikiana> zyga-ubuntu: this is btw snapcraft as a snap, with lxd from apt
[11:02] <zyga-ubuntu> mvo: approved 4272
[11:02] <mvo> zyga-ubuntu: ta
[11:02] <zyga-ubuntu> kalikiana: too many errors recently
[11:02] <zyga-ubuntu> kalikiana: I have LXD issues to address b
[11:03] <zyga-ubuntu> kalikiana: but our integration test suite is so unreliable I took a dive into it
[11:03] <mvo> zyga-ubuntu: thanks again for this review, that made things a lot better (checkRefreshSchedle was pretty terrible)
[11:03] <kalikiana> zyga-ubuntu: is there anything that changed in lxd recently? I'm quite sure snapcraft changed nothing
[11:03] <zyga-ubuntu> kalikiana: I don't know, sorry :/
[11:04] <mvo> kalikiana: there was a new stable lxd recently I think, but that is really all I know
[11:04] <mvo> stable channel lxd snap to be precise
[11:04] <mup> PR snapcraft#1750 closed: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1750>
[11:05] <mvo> kalikiana: yesterday to be precise. and also a new cnadidate a bit later
[11:05] <kalikiana> mvo: I guess I'll try if the snap suffers from the same issue - what I find super puzzling is that hostfs is in the path at all, and considering it's empty in the host that would easily explain why lxd can't access it
[11:07] <mup> PR snapcraft#1643 closed: tests: run daily autopkgtest in travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1643>
[11:08] <zyga-ubuntu> mborzecki: approved 4273
[11:08] <mborzecki> ta
[11:09] <mup> PR snapd#4267 closed: snapstate: move catalogRefresh into its own helper  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4267>
[11:09] <zyga-ubuntu> mvo: trivial comment on 4266 (from pedronis, not me), +2 otherwise and ready to land
[11:10] <zyga-ubuntu> mvo: thank you for updating 4262 :)
[11:11] <zyga-ubuntu> Chipaca: do you feel like reviewing 4254 from mvo (it's about SNAP_DID_REEXEC)
[11:11] <zyga-ubuntu> ?
[11:11] <mup> PR snapd#4256 closed: snap-confine: add workaround for snap-confine on 4.13/upstream <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4256>
[11:11] <mup> PR snapd#4262 closed: store: do not log the http body for catalog updates <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4262>
[11:11]  * Chipaca looks
[11:17] <zyga-ubuntu> mvo: we still ship a configure hook in core, is the plan to remove that entirely and switch to internally-handled configuration?
[11:27] <pedronis> zyga-ubuntu: the plan is to remove it, we still have more work to do to fix 2.30 to make that possible
[11:27] <pedronis> though
[11:27] <zyga-ubuntu> pedronis: I see
[11:28] <pedronis> https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774
[11:28] <zyga-ubuntu> pedronis: I just noticed we do something odd in prepare code
[11:28] <zyga-ubuntu> we enable refresh on external spread backends
[11:28] <zyga-ubuntu> but only if the configure hook exists
[11:31] <kalikiana> zyga-ubuntu: concerning denials: none, I'm only seeing unrelated ones eg. Telegram now
[11:31] <kalikiana> which makes sense if all it does is read an empty folder
[11:34] <zyga-ubuntu> kalikiana: is this locally or in some CI system?
[11:34] <zyga-ubuntu> kalikiana: do you have any changes on the system that is affected?
[11:35] <kalikiana> zyga-ubuntu: all local, xenial with backports
[11:41] <zyga-ubuntu> mborzecki: is 4270 safe to merge now?
[11:42] <mborzecki> zyga-ubuntu: yes
[11:42] <zyga-ubuntu> mvo: trivial comment on 4252
[11:42] <zyga-ubuntu> mvo: and more comments on 4272
[11:42] <mup> PR snapd#4270 closed: timeutil: remove support to parse weekday schedules <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4270>
[11:43] <zyga-ubuntu> 4263 needs a 2nd review
[11:43] <mup> PR snapd#4254 closed: cmd, errtracker: get rid of SNAP_DID_REEXEC environment <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4254>
[11:44] <zyga-ubuntu> mborzecki: can you finish your review o 4109, it's small and has been lingering for too long
[11:44] <mup> PR snapd#4171 closed: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4171>
[11:46] <zyga-ubuntu> mborzecki: conflicts in 4273
[11:49] <pstolowski> mborzecki, .. and in 4269
[11:51] <niemeyer> cjwatson: Aww.. no more gimme?
[11:52] <niemeyer> Hellos!
[11:52] <cjwatson> niemeyer: thank you for the music
[11:53] <jamesh> zyga-ubuntu: hi.  I was wondering if you have any ideas about how to write a spread test for my user-mounts PR.  I haven't included any interface that add user mounts at this stage, so I'm not sure where to start
[11:56] <mborzecki> pushed an update to 4273, 4269 will be fixed later as currently it will conflict with 4273
[11:59] <zyga-ubuntu> jamesh: I think it should be a part of the desktop interface (right?)
[12:00] <zyga-ubuntu> jamesh: alternatively just use a test snap, install it, hack the profile and run update-ns
[12:00] <zyga-ubuntu> jamesh: (and, more importantly, hack the profile, discard the ns and run snap-confine again so that it sets up things)
[12:00] <jamesh> zyga-ubuntu: the desktop innnterface will use it for portals eventually, but that isn't part of the PR
[12:00] <zyga-ubuntu> jamesh: look at the advanced content interface test for inspiration
[12:01] <jamesh> zyga-ubuntu: also, what's the most convenient way to run a single spread test locally?
[12:01] <zyga-ubuntu> jamesh: look at tests/main/interfaces-content-mkdir-writable
[12:01] <zyga-ubuntu> jamesh: the qemu backend, you can iterate very quickly (ish)
[12:01] <zyga-ubuntu> jamesh: I'm running it all the time
[12:01] <zyga-ubuntu> jamesh: I pushed images to spread.zygoon.pl/images
[12:02] <zyga-ubuntu> jamesh: so pick one and look at spread docs on how to use
[12:02] <zyga-ubuntu> jamesh: (just put to ~/spread/qemu)
[12:02] <jamesh> thanks
[12:02] <zyga-ubuntu> jamesh: then SPREAD_DEBUG_EACH=0 spread qemu:ubuntu-16.04-64:tests/main/
[12:02] <zyga-ubuntu> jamesh: then SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/
[12:02] <zyga-ubuntu> (2nd line is better)
[12:03] <zyga-ubuntu> jamesh: the desire for the spread test is to see that this really really works with confinment and what not
[12:03] <zyga-ubuntu> jamesh: and weird kernels and other unexpected stuff
[12:04] <zyga-ubuntu> mvo: small typo in 4266
[12:04] <zyga-ubuntu> mvo: small tweak needed in 4252
[12:05]  * zyga-ubuntu is trying to get the PR page list down to one
[12:06] <pedronis> #4158 needs a 2nd review
[12:06] <mup> PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/4158>
[12:07] <zyga-ubuntu> looking
[12:07] <jamesh> zyga-ubuntu: okay.  fwiw, the unit tests in the PR are all passing now: it looks like the run yesterday hit some problem trying to talk to the VMs
[12:07] <zyga-ubuntu> jamesh: yeah, our perpetual problem of not having a batch system
[12:16] <cachio> mvo, hey
[12:16] <cachio> mvo, looking at the issue with "Job for snapd.service canceled"
[12:17] <cachio> mvo, any idea how to deal with it?
[12:17] <cachio> mvo, retrying in case of error could be a solution?
[12:27] <zyga-ubuntu> pstolowski: review on 4158
[12:27] <zyga-ubuntu> hmm, so MATCH is in the top-level spread context, this is a problem if we want to use it in scripts :/
[12:28] <mup> PR snapd#4274 closed: spread.yaml: bump delta ref to 2.29 <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4274>
[12:29] <zyga-ubuntu> hello niemeyer :)
[12:29] <zyga-ubuntu> thank!
[12:29] <zyga-ubuntu> thanks* :)
[12:29] <niemeyer> zyga-ubuntu: Hey!
[12:29] <niemeyer> zyga-ubuntu: Man, I found your brother last night
[12:30] <niemeyer> zyga-ubuntu: https://www.youtube.com/watch?v=cHjf-YmIBCs
[12:30] <zyga-ubuntu> niemeyer: oh?
[12:31] <zyga-ubuntu> hahaha
[12:31] <zyga-ubuntu> yeah, actually he even sounds similar in some way
[12:31] <zyga-ubuntu> I hit the case where spread tarball changes while we are making it, hmmm,
[12:31] <pedronis> that is a fun one :(
[12:32] <zyga-ubuntu> maybe once I'm done with refactoring/untangling it will become evident
[12:32] <zyga-ubuntu> I bet something is not done right somewhere
[12:32] <zyga-ubuntu> service lingers or something like that
[12:33] <niemeyer> zyga-ubuntu: Yeah, the voice tone, the looks, and even the shirt!
[12:33] <zyga-ubuntu> niemeyer: surreal a bit :)
[12:33] <niemeyer> :P
[12:33] <zyga-ubuntu> niemeyer: my accent is better though (haha, maybe)
[12:35] <niemeyer> zyga-ubuntu: Well, not better, but less german :-)
[12:36] <niemeyer> (I don't see accents as bad in general.. just means we speak another language too)
[12:39] <Son_Goku> accents don't necessarily imply another language
[12:39] <zyga-ubuntu> oh god yes
[12:39] <zyga-ubuntu> I watched a review of a game recently
[12:39] <zyga-ubuntu> and geez
[12:39] <zyga-ubuntu> this guy was unberable
[12:39] <Son_Goku> IMO, they tell a story of the person's origin and history
[12:40] <zyga-ubuntu> somewhere from US presumably but _MAN_
[12:40] <Son_Goku> I've intentionally smoothed out the accent and speech style I grew up with, because it can confuse people
[12:41] <Son_Goku> and even then, I don't have all of it out of my speech
[12:41] <zyga-ubuntu> ok, I'm done watching my weird mirror :)
[12:43] <kalikiana> Son_Goku: you're like Jack Barrowman :-D
[12:43] <kalikiana> although arguably his original accent is worse
[12:43] <Son_Goku> well, I'm not *quite* so flamboyant
[12:43] <Son_Goku> but yes
[12:43] <kalikiana> haha, yeah
[12:44] <Son_Goku> well, for the first half of my childhood was spent in Indiana (US Midwest) and the second half was in Mississippi (US South), so I have bits of both in my speech
[12:46] <zyga-ubuntu> afk, see you at the call
[12:48] <mvo> zyga-ubuntu: the plan is to not ship the configure hook in core, yes
[12:50] <mvo> cachio: hey, thanks for chasing the "job canceled" issue, I have no good answer, a retry is certainly not a bad idea, maybe this gives us even a better idea what exactly is causing this
[12:51] <mvo> zyga-ubuntu: thanks also for the reviews, I chase the open points now :)
[12:52] <cachio> mvo, I'll try it
[12:52] <zyga-ubuntu> mvo: thank you! :)
[12:58]  * kalikiana coffee break
[13:00] <Chipaca> mvo: should we ask systemd peeps about that?
[13:00] <zyga-ubuntu> I'll be late 2 min
[13:04] <zyga-ubuntu> hmm
[13:04] <zyga-ubuntu> some issues joining
[13:05] <zyga-ubuntu> hmm :/
[13:17] <mvo> Chipaca: its only on 14.04 and on our crufty backport
[13:38] <Chipaca> mwhudson: is the plan to have go 1.10 in B?
[13:44] <zyga-ubuntu> Chipaca: are you rejoining?
[13:48] <zyga-ubuntu> ok, I'll break for lunch and I'll push forward in a moment :)
[14:02] <Chipaca> zyga-ubuntu: question for you i think: why do osutil.Find[UG]id return a uint64?
[14:04] <zyga-ubuntu> Chipaca: I believe that is what the golang 1.9 code we borrowed did do
[14:04] <zyga-ubuntu> Chipaca: and we just ran along
[14:05] <Chipaca> hmm
[14:05]  * Chipaca looks
[14:05] <zyga-ubuntu> offtopic, 3C and rain, I really don't envy commuters
[14:05] <Chipaca> zyga-ubuntu: golang uses strings for uids and gids
[14:05] <Chipaca> zyga-ubuntu: in the os/user package
[14:05] <Chipaca> elsewhere it uses uint32's
[14:05] <Chipaca> (hilariously)
[14:06] <zyga-ubuntu> Chipaca: then I don't remember, I think there were two layers of this?
[14:06] <zyga-ubuntu> Chipaca: or maybe as simple and naive as what parseint returns
[14:07] <zyga-ubuntu> *uint
[14:08] <Chipaca> zyga-ubuntu: also: those functions return a 0 on error, which can be bad
[14:08] <Chipaca> but i don't know if i want to fix the in this pr
[14:08] <Chipaca> hmm
[14:17] <cachio> ogra_, hey
[14:18] <cachio> ogra_, https://paste.ubuntu.com/26020272/
[14:18] <cachio> the timexone in ubuntu core is n/a by defaulty
[14:18] <cachio> ogra_, is it a known issue?
[14:20] <Chipaca> zyga-ubuntu, mvo: in snap-seccomp/main.go's findGid we check a regexp, and then call osutil.FindGid which checks a regexp
[14:20] <Chipaca> zyga-ubuntu, mvo: those regexps differ
[14:20] <Chipaca> zyga-ubuntu, mvo: quoth the raven, "WAT"
[14:20] <Chipaca> zyga-ubuntu, mvo: ignore me, i got that wrong
[14:22] <ogra_> cachio, not that i'm aware ... file it ...
[14:22] <cachio> ogra_, ok tx
[14:22] <ogra_> cachio, is that x86 or arm ?
[14:23] <ogra_> (on arm the fixrtc script checks for n/a and sets it properly, on x86 we do not use the fixrtc script afaik)
[14:23] <zyga-ubuntu> mvo: the one with weirder features is probably correct
[14:23] <zyga-ubuntu> er
[14:23] <zyga-ubuntu> Chipaca: ^
[14:23] <zyga-ubuntu> Chipaca: can you paste them here please?
[14:24] <cachio> ogra_, all of them
[14:24] <cachio> ogra_, in the pi3 also
[14:24] <Chipaca> zyga-ubuntu: sorry, i got confused, but let me show you how
[14:25] <ogra_> cachio, ah, well ... we should set it to UTC as default at build time i guess
[14:25] <Chipaca> zyga-ubuntu: in snap-seccomp main: group must match "^[a-z][-a-z0-9_]*$"
[14:26] <zyga-ubuntu> that is probably incorrect (just too restrictive)
[14:28] <Chipaca> zyga-ubuntu: in snap-update-ns entry: x-snapd.gid must match "(^[0-9]+$)|(^[a-z_][a-z0-9_-]*[$]?$)"
[14:28] <zyga-ubuntu> this one is correct but also matches numbers (as just direct group i)
[14:29] <zyga-ubuntu> so if you want to take one, take the latter one and remove the number part
[14:29] <zyga-ubuntu> Chipaca: the 2nd one is correct, I looked at the spec and, weirdly enough, that's what valid names are
[14:31] <Chipaca> zyga-ubuntu: group names can end in $ but otherwise have no $ in them?
[14:31] <Chipaca> what does that $ mean? (i presume it's special somehow)
[14:31] <Chipaca> (i'm not changing that regexp in this round)
[14:31] <Chipaca> (next one? sure)
[14:32] <cachio> ogra_, it is set to UTC but the description is n/a
[14:32] <zyga-ubuntu> yes
[14:32] <cachio> Time zone: n/a (UTC, +0000)
[14:33] <zyga-ubuntu> Chipaca: it's special, it means
[14:33] <zyga-ubuntu> ...
[14:33] <zyga-ubuntu> man I should have commented that somewhere
[14:33] <ogra_> cachio, yes, i see that ... but if you set it manually the description says UTC as well
[14:33] <ogra_> Time zone: UTC (UTC, +0000)
[14:33] <Chipaca> zyga-ubuntu: yeah :-) a "where does this regexp come from" would be good
[14:33] <cachio> ogra_, yes
[14:33] <zyga-ubuntu> Chipaca: it should be in the git log
[14:33]  * zyga-ubuntu looks
[14:33] <ogra_> so we need to find how to set it like this during build and apply that
[14:34] <ogra_> cachio, can you check if /etc/timezone says n/a on an image that exposes the issue ?
[14:34] <zyga-ubuntu> Chipaca: man, I suck :/
[14:35] <ogra_> (i missed to check it before setting it ... )
[14:35] <zyga-ubuntu> Chipaca: probably in the PR then
[14:35] <zyga-ubuntu> Chipaca: I remember an URL with all the things explained
[14:35] <cachio> ogra_, Etc/UTC
[14:35] <ogra_> interesting
[14:35] <ogra_> it doesnt say Etc here
[14:35] <ogra_> ogra@pi3:~$ cat /etc/timezone
[14:35] <ogra_> UTC
[14:36] <cachio> I have an old image
[14:36] <cachio> let me check in a new one
[14:36] <ogra_> cachio, aha... setting it to Etc/UTC results in:
[14:36] <ogra_> Time zone: n/a (UTC, +0000)
[14:36] <ogra_> dropping the Etc/ fixes it
[14:36] <cachio> hehe
[14:37] <cachio> ogra_, checking in a new image for pi3
[14:37] <cachio> 1 minute
[14:38] <kalikiana> kyrofa: ping
[14:38] <mup> PR snapcraft#1754 opened: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1754>
[14:38] <Chipaca> cachio: ogra_: Etc/ is a directory in tzdata
[14:38] <ogra_> Chipaca, tell that to systemd-timedated
[14:38] <ogra_> :)
[14:39] <ogra_> seems it expects not a path but a TZ name in /etc/timezone
[14:40] <ogra_> hmm, or not
[14:40] <ogra_> ogra@pi3:~$ cat /etc/timezone
[14:40] <ogra_> Europe/Berlin
[14:40] <ogra_> that works correctly
[14:40] <ogra_> only Etc/ doesnt
[14:40] <ogra_> i mean ... it shows the correct TZ (UTC) in brackets ...
[14:41] <ogra_> but n/a as description
[14:41] <Chipaca> ogra_: what does list-timezones give you?
[14:41] <ogra_> though ... perhaps the test should not use the description at all
[14:41] <ogra_> and instead look inside the brackets where the actual TZ name sits
[14:41] <Chipaca> ogra_: timedatectl list-timezones | grep -i etc
[14:42] <ogra_> nothing
[14:42] <ogra_> ogra@pi3:~$ sudo timedatectl list-timezones|grep -i utc
[14:42] <ogra_> UTC
[14:42] <Chipaca> so there you go
[14:42] <ogra_> ogra@pi3:~$ sudo timedatectl list-timezones|grep -i etc
[14:42] <ogra_> ogra@pi3:~$
[14:42] <ogra_> well, but thats technically correct
[14:42] <Chipaca> ogra_: and what happens if you try to set the timezone to something known-bad, e.g. "potato"
[14:42] <kalikiana> sergiusens: ping
[14:43] <mup> Bug #1733881 opened: timezone set to n/a on ubuntu core <Snappy:New> <https://launchpad.net/bugs/1733881>
[14:43] <ogra_> ogra@pi3:~$ sudo timedatectl |grep Time
[14:43] <ogra_>        Time zone: n/a (UTC, +0000)
[14:43] <ogra_> ogra@pi3:~$ cat /etc/timezone
[14:43] <ogra_> Etc/UTC
[14:43] <sergiusens> kalikiana just speak up
[14:43] <ogra_> Chipaca, it complains
[14:43] <Chipaca> ogra_: where did the Etc/UTC come from?
[14:43] <ogra_> Chipaca, my theor is that the test should really look inside the brackets
[14:44] <ogra_> Chipaca, a default
[14:44] <ppisati> $ ./runtests.sh static
[14:44] <ppisati> ./runtests.sh: line 49: mypy: command not found
[14:44] <ppisati> sergiusens: ^
[14:44] <ppisati> elopio: ^
[14:44] <ppisati> kyrofa: ^
[14:44] <ogra_> Chipaca, i think thats the default tzdata ships
[14:44] <ppisati> from origin/master at the time of this writing
[14:44] <sergiusens> ppisati pip install -r requirements-devel.txt
[14:44] <Chipaca> ogra_: maybe tzdata and timedatectl conflict?
[14:44] <ogra_> might be
[14:45] <ogra_> but there is no way to omit tzdata
[14:45] <ogra_> it is super essential
[14:45] <ppisati> sergiusens: ta
[14:45] <ogra_> we'd have to completely change debootstrap and the archive setup for the package (not making it essential)
[14:46] <kalikiana> sergiusens: do you know this code? I'm getting a failure in https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources/_local.py#L51 which uses https://github.com/snapcore/snapcraft/blob/master/snapcraft/file_utils.py#L86
[14:46] <Chipaca> ogra_: are you writing /etc/timezone, or /etc/localtime?
[14:46] <niemeyer> cachio: Getting an error on master while trying to run the snap-info spread test:
[14:46] <ogra_> Chipaca, only timezone ...
[14:46] <niemeyer> + apt install -y '/home/gopath/snapd_*.deb'
[14:47] <Chipaca> ogra_: might be relevant: #1554806
[14:47] <mup> Bug #1554806: Change of behavior: "dpkg-reconfigure -f noninteractive" unconditionally overwrites /etc/timezone now <tzdata (Ubuntu):Confirmed> <https://launchpad.net/bugs/1554806>
[14:47] <niemeyer> cachio: That's bogus indeed.. the quoting kills the wildcard
[14:47] <kalikiana> sergiusens: For some reason in the context of LXD on a remote machine and sshfs+sftp, it's not resolving symlinks
[14:47] <niemeyer> cachio: Curious that it's not being an issue?
[14:48] <sergiusens> kalikiana most likely related to the underlying filesystem, you might need to quirk it
[14:48] <cachio> niemeyer, mmmm, I'll fix it
[14:48] <ogra_> Chipaca, well ... more an issue with writable symlinking ...
[14:48] <ogra_> ogra@pi3:~$ ls -l /etc/localtime
[14:48] <ogra_> lrwxrwxrwx 1 root root 23 Nov 22 05:24 /etc/localtime -> /etc/writable/localtime
[14:48] <ogra_> ogra@pi3:~$ ls -l /etc/writable/localtime
[14:48] <ogra_> lrwxrwxrwx 1 root root 33 Nov 22 15:39 /etc/writable/localtime -> /usr/share/zoneinfo/Europe/Berlin
[14:48] <ogra_> ogra@pi3:~$
[14:48] <kalikiana> sergiusens: I noticed link_or_copy.follow_symlinks defaults to False, but shutil copytree is called with symlinks=True - that struck me as odd, but I also don't really know the code
[14:48] <cachio> niemeyer, just 1 min after I finish the fedora 27
[14:48] <ogra_> we have this multi staged symlinks there that always caused some issues
[14:48] <niemeyer> cachio: Thanks.. I really wonder how that's not affecting other runs
[14:48] <ogra_> to fix atomic writing ...
[14:49] <kalikiana> sergiusens: I exhausted sshfs' options more or less... it has 3 link-related options, none of which make that code path work
[14:49] <kalikiana> sergiusens: where I just want to understand why it breaks in the first place
[14:50] <kalikiana> if I manually poke the files in the container, all is fine
[14:50] <sergiusens> kalikiana we've had symlink issues when the underlying fs was hfs, what does, 'poke the files in the container' mean? Through python APIs?
[14:51] <Chipaca> ogra_: timedatectl will always print UTC when timezone is unset / unknown / bogus
[14:52] <ogra_> Chipaca, well, it works correct if the "Etc/" is dropped from /etc/timezone
[14:52] <ogra_> i.e. if the tz entry matches what list-timezones provides
[14:52] <ogra_> the easiest would simply be to put UTC into /etc/timezone at build time
[14:53] <kalikiana> sergiusens: I mean doing `ls -la` or `cat` on the files that give me "[Errno 2] No such file or directory" in Python
[14:53] <ogra_> but OTOH i still think the test is wrong to match the description and not the TZ
[14:53] <sergiusens> kalikiana broken symlinks do that in python
[14:53] <ogra_> it should look between the brackets, not at the descriptive name
[14:54] <ogra_> i.e.
[14:54] <ogra_> Time zone: Europe/Berlin (CET, +0100)
[14:54] <ogra_> you want to match CET here, not "Europe/Berlin"
[14:55] <ogra_> (since this will also be what date uses for example ... the rest is just nice to have but not technically relevant)
[14:55] <kalikiana> sergiusens: right, except I can access the very same files from the container through sshfs via ls and cat
[14:55] <kalikiana> I might be overlooking something here
[14:55] <kalikiana> sergiusens: if it's relevant, it's all relative links
[14:57] <sergiusens> kalikiana break the code in pieces by writing small implementations or activate the debugger (pdb)
[15:02] <kalikiana> yeah, that's what I'll do now, just wanted to query if there were any obvious gotcha's with the current code
[15:02] <kalikiana> thanks
[15:06] <niemeyer> I honestly don't understand.. it consistently fails every single time for me.. how come we don't have broken tests in travis
[15:08] <Chipaca> niemeyer: what fails for you?
[15:09] <niemeyer> Chipaca: + apt install -y '/home/gopath/snapd_*.deb'
[15:09] <niemeyer> Chipaca: This can't possibly work.. the quoting kills the wildcard
[15:10] <cjwatson> It probably turns into a regex interpreted by apt, so might work if it's actually called snapd.deb?
[15:10] <cjwatson> https://travis-ci.org/snapcore/snapcraft/jobs/305836865 doesn't obviously seem to be my problem (this is for https://github.com/snapcore/snapcraft/pull/1754, which doesn't change anything in that area) - known breakage?
[15:10] <mup> PR snapcraft#1754: nodejs plugin: pass proxy configuration to yarn <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1754>
[15:12] <Chipaca> niemeyer: where is that command coming from?
[15:12] <Chipaca> niemeyer: (grep doesn't find it here)
[15:13] <mvo> Chipaca: what command?
[15:13] <Chipaca> mvo: the apt install -y '...'
[15:14] <cjwatson> so set -x output is a bit misleading here
[15:14] <cg_> hey everyone. i'm new to snapcraft and trying to wrap my head around what are probably some simple concepts. right now, the issue is that i have two dependencies, currently defined as parts, and one needs to know the path of the other, or at least a path to some files that need to be shared so it can build.
[15:14] <cjwatson> tests/lib/prepare.sh:        distro_install_local_package "$GOHOME"/snapd_*.deb
[15:14] <cg_> could anyone help me figure this out?
[15:14] <niemeyer> Chipaca: Must be distro_install_build_snapd
[15:14] <cjwatson> it then gets quoted when distro_install_local_package calls   apt install $flags "$@"
[15:14] <Chipaca> cjwatson: niemeyer: but distro_install_local_package "$GOHOME"/snapd_*.deb <- the * isn't quoted
[15:14] <cjwatson> and set -x renders that as single-quotes, but that doesn't mean it was called that way
[15:14] <Chipaca> ah
[15:14] <cjwatson> the problem is that snapd_*.deb didn't exist so the glob didn't expand
[15:15] <cjwatson> and something didn't pick that up as a failure earlier when it would have been 90% less confusing
[15:15] <cjwatson> (or, yes, possibly from distro_install_build_snapd as the caller; same either way)
[15:16] <niemeyer> cjwatson: Yeah, that must be it
[15:16] <niemeyer> Either it's failing, or the prepare is just bogus and is not doing what it should
[15:17] <niemeyer> The only thing I'm doing special here is to try to run a single test instead of the whole suite
[15:17] <niemeyer> linode:ubuntu-16.04-64:tests/main/snap-info
[15:17] <mup> PR snapcraft#1749 closed:  tests: add a script to run autopkgtests in the ppa  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1749>
[15:23]  * zyga-ubuntu is done with the kids and returns to work
[15:24] <mvo> zyga-ubuntu: hm, the debian-sid tests are slightly strange, it fails with "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks", I think I try to ssh into one
[15:26] <zyga-ubuntu> mvo: looks like snap-confine is built without apparmor
[15:26] <zyga-ubuntu> mvo: we may need to change the dpkg vendor test (remove it) in debian/rules
[15:27] <zyga-ubuntu> mvo: hmmm, actually
[15:27] <zyga-ubuntu> mvo: that probably makes no sense
[15:28] <mvo> zyga-ubuntu: I thought I had done that already
[15:29] <zyga-ubuntu> mvo: yeah, worth looking into for sure
[15:29]  * zyga-ubuntu listens to "not your kind people" today
[15:36] <mup> PR snapd#4263 closed: overlord/devicestate:  best effort to go to early full retries for registration on the like of DNS no host <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4263>
[15:38] <gsilva> kyrofa:  have you seen the PR? It failed for some reason but I can't tell why
[15:38] <gsilva> Hello all, by the way
[15:38] <mup> PR snapd#4109 closed: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4109>
[15:42] <zyga-ubuntu> pedronis: posted question on 4260
[15:43] <cg_> Anyone available to help with what I'm gonna guess are some pretty basic questions?
[15:44] <zyga-ubuntu> cg_: just ask your questions please, we'll do our best
[15:45] <cg_> Yeah, tried that before but didn't want to just keep spamming...
[15:46] <cg_> Alright, so I'm building a ROS project. It has two dependencies that I've been installing outside of ROS: our ethercat kernel modules and a library that provides an interface to ethercat.
[15:46] <pedronis> zyga-ubuntu: that's auto-import, not the store,  not sure what those files are though
[15:46] <pedronis> left overs?
[15:47] <zyga-ubuntu> cg_: are you working on a classic or a core device? (classic = with typical package manager + snapd on the side; core = with just snapd)
[15:47] <pedronis> I would need to dig more
[15:47] <zyga-ubuntu> pedronis: aha
[15:47] <zyga-ubuntu> pedronis: my measurement code can capture that
[15:47] <zyga-ubuntu> pedronis: thanks for looking
[15:47] <zyga-ubuntu> pedronis: I'll untangle the restore code and will be able to find those (hopefully) quickly
[15:47] <zyga-ubuntu> cg_: btw, kyrofa here is a ros expert
[15:47] <zyga-ubuntu> cg_: for kernel modules on core device you will need your own kernel + gadget snap
[15:48] <kyrofa> kalikiana, pong
[15:48] <cg_> zyga-ubuntu: i'm working with classic right now, hoping to move to core
[15:48] <zyga-ubuntu> cg_: we may need a snapd interface for the ethercat but I don't know what this, just speculating so far
[15:48] <zyga-ubuntu> cg_: ok
[15:48] <zyga-ubuntu> cg_: that's fine, it's a well-defined move for this kind of thing
[15:50] <cg_> zyga-ubuntu: so before i even start dealing with the kernel nonsense, i'm trying to get my head around what feels like some real Snapcraft 101 crap. I need to provide the paths to different dependencies so they can install correctly. The interface that helps us communicate with our ethercat driver needs to know the path to the ethercat library, and then ROS needs to know the path to the interface.
[15:51] <kalikiana> kyrofa: Hey. Was wondering about file_utils.py / _local.py if you happend to know about its custom handling of symlinks. I'm doing some testing atm why the code would say "file not found" when ls and friends are happy with the files
[15:51] <cg_> zyga-ubuntu: In my manual install world, I'd just clone my repos into ~/, build from there, point to ~/EtherCAT_Master or whatever
[15:51] <zyga-ubuntu> cg_: path as in runtime path or build time?
[15:52] <kyrofa> kalikiana, I am familiar with it, could you give me more details?
[15:52] <zyga-ubuntu> cg_: suggestion: unless you absolutely must, try to snap hello world code first to see what you get and how it is built
[15:52] <cg_> zyga-ubuntu: I'm gonna need both. Totally hung up at build time right now.
[15:52] <zyga-ubuntu> cg_: and then how it operates (both are differnt)
[15:52] <zyga-ubuntu> cg_: I know ... little about ros (/me looks at ROS topic mug from roscon) but build time should be handled by snapcraft
[15:53] <cg_> zyga-ubuntu: these aren't ROS dependencies, as far as it is concerned. they're just C libraries that we reference, ROS has no idea what to do with them.
[15:53] <zyga-ubuntu> cg_: if not kyrofa or sergiusens can help you and make fixes to snapcraft; you can also ask on the forum (forum.snapcraft.io) or talk in rocket.ubuntu.com (snapcrafters hang out there routinely)
[15:53] <zyga-ubuntu> cg_: I'm mostly focused on runtime side of snapd
[15:54] <cg_> zyga-ubuntu: The ROS aspect of this really doesn't matter. If I install these dependencies manually, my ROS part builds happily, everything works great. I'm just trying to cut out the manual steps.
[15:54] <cg_> zyga-ubuntu: But yeah, right now, I'm hung up on building
[15:54] <zyga-ubuntu> cg_: are those things packaged in some way?
[15:55] <zyga-ubuntu> cg_: snapcraft has a concept of "build packages"
[15:55] <zyga-ubuntu> cg_: (with the usual meaning)
[15:56] <cg_> zyga-ubuntu: They are, but it feels sorta... hacky. Ignoring what they're actually called, Dependency 2 has the path to Dependency 1 hard-coded. I can feed it a path, I'm just lost RE: what that path should be in snapcraft world. Make sense?
[15:57] <mvo> Chipaca: hm, hm, all the except tests are failing in debian-sid. I have a look in a bit
[15:58] <Chipaca> mvo: expect*?
[15:58] <cg_> zyga-ubuntu: Normally, I can just point it at the repo that I've cloned to my home folder. With snapcraft handling it and each dependency broken into separate parts, I'm unsure of how to tell Dependency 2 how to find Dependency 1. It doesn't feel like a healthy practice but I'm unsure of how Snapcraft would prefer me to approach it.
[15:59] <kyrofa> Hey there cg_, are we talking about https://forum.snapcraft.io/t/part-referencing-other-part/2929/3 ?
[15:59] <mvo> Chipaca: eh, yes
[15:59] <Chipaca> mvo: :)
[15:59] <cg_> kyrofa: Hello! Yessir
[15:59] <mvo> Chipaca: anyway, just wanted to let you know, I need to take a break now
[15:59] <Chipaca> mvo: np
[16:00] <kalikiana> kyrofa: so this is with a LXD container and files served via sshfs/sftp, which means smylinks might work differently; the error I'm getting is at https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources/_local.py#L51 which uses https://github.com/snapcore/snapcraft/blob/master/snapcraft/file_utils.py#L86  -- it's giving me a shutil.Error with a list of files and [Errno 2] No such file or directory in the end
[16:00] <kalikiana> - all the given symlinks resolve  fine with ls or cat in a shell in the container, just the specific snapcraft code doesn't work
[16:00] <kyrofa> cg_, I asked a question there for you
[16:00] <cg_> kyrofa: Thanks, on it
[16:02] <zyga-ubuntu> 2PRs short of one page
[16:02] <zyga-ubuntu> some just wait for tests
[16:02] <zyga-ubuntu> mvo: can you please look at 4140
[16:02] <zyga-ubuntu> mvo: it's green and has +1 from me
[16:02] <zyga-ubuntu> mvo: with a quick look we can get down to 26 PRs
[16:02] <mup> PR snapd#4184 closed: tests: adding new test for uhid interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4184>
[16:03] <pedronis> Chipaca: anyway firt pass at that issue is probably remembering who did what,  unless the store apis change radically
[16:04] <Chipaca> pedronis: … which issue?
[16:04]  * Chipaca is lost
[16:04] <pedronis> Chipaca: us sending no auth with auto refreshes
[16:05] <Chipaca> pedronis: ah
[16:06] <zyga-ubuntu> pstolowski: 4218 needs a 2nd look from you
[16:07] <pstolowski> zyga-ubuntu, ok, looking
[16:07] <pedronis> mvo: do we run autopkgtest daily?
[16:17] <pstolowski> cachio, I think you forgot to push your changes to #4218
[16:17] <mup> PR #4218: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218>
[16:18] <cachio> pstolowski, almost pushed
[16:18] <cachio> 1 min please
[16:18] <pstolowski> cachio, sure, np
[16:20] <zyga-ubuntu> cachio: comment son 4078
[16:21] <cachio> pstolowski, push donedone
[16:24] <pstolowski> ok
[16:26] <cachio> zyga-ubuntu, done
[16:26] <cachio> zyga-ubuntu, wait
[16:26] <cachio> zyga-ubuntu, now :)
[16:27] <mup> PR snapd#4273 closed: timeutil: introduce helpers for weekdays and TimeOfDay <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4273>
[16:27] <zyga-ubuntu> cachio: thank you!
[16:27] <zyga-ubuntu> cachio: I'm really curious what that about
[16:27] <cachio> zyga-ubuntu, yaw
[16:27] <cachio> zyga-ubuntu, yes, it is really weird, but I could reproduce it even manually
[16:28] <zyga-ubuntu> cachio: do you know if any snaps were installed after reboto?
[16:28] <zyga-ubuntu> *reboot
[16:29] <cachio> no, I just reproduces the test but manually
[16:29] <cachio> just to make sure the test was working properlyu
[16:29] <zyga-ubuntu> interesting
[16:29] <zyga-ubuntu> well, we'll keep digging
[16:30]  * ikey grins in advance of teaching niemeyer that rolling can be stable
[16:31] <mup> PR snapd#4275 closed: spread.yaml,tests: move most of project-wide prepare/restore to separate file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4275>
[16:31] <pstolowski> niemeyer, pedronis updated 4259 with new test
[16:31] <zyga-ubuntu> Chipaca: if around, could you do 4276
[16:32] <mup> PR snapd#4276 opened: tests: document and slightly refactor prepare/restore code <Created by zyga> <https://github.com/snapcore/snapd/pull/4276>
[16:32] <zyga-ubuntu> cachio: can you also look please, there's one XXX thre I don't fully understand and I suspect you know
[16:32] <Chipaca> zyga-ubuntu: ◯
[16:33] <sergiusens> zyga-ubuntu we do not use rocket anymore
[16:33] <zyga-ubuntu> Chipaca: emoji don't show up in linux console
[16:33] <zyga-ubuntu> sergiusens: oh, I didn't know thanks for sharing that
[16:33] <zyga-ubuntu> I wish forum and rocket could merge shomehow
[16:33] <zyga-ubuntu> but IRC is just so darn immortal
[16:33] <niemeyer> ikey: I literally said "anyone publishing such snaps needs to understand and agree to preserve a stable API", to which you responded "that’s not gonna happen"
[16:33] <Chipaca> zyga-ubuntu: 💩
[16:33] <niemeyer> ikey: I never even touched the word "rolling"
[16:33] <ikey> woah woah
[16:33] <ikey> back up a bit there sham
[16:33] <ikey> im poking fun
[16:34] <ikey> didnt realise there was a bear on the end of it
[16:34] <ikey> the way you worded it was "frozen forever"
[16:34] <ikey> and thats not gonna happen
[16:34] <ikey> stable yes, locked, no
[16:34] <ikey> distinction. :]
[16:34] <niemeyer> ikey: I also didn't say "locked" either :-)
[16:34] <niemeyer> ikey: Or "frozen"
[16:35] <ikey> sure - i was replying to my interpretation based on the facts provided to me by you. notice i still agreed to a call as it was clear not all facts are present on both sides ;)
[16:35] <niemeyer> ikey: We just need it stable.. which means existing functionality cannot be removed or broken
[16:35] <zyga-ubuntu> ikey: where there's honey, there's bear ;-)
[16:35] <niemeyer> Including both APIs and ABIs
[16:35]  * zyga-ubuntu just makes up proverbs
[16:35] <ikey> ABIs *can* be changed
[16:35] <ikey> This is rolling, by design they need to
[16:36] <ikey> And this isn't a derivable snap, it exists purely to satisfy LSI :P
[16:36] <niemeyer> Sure.. then it can't be a base snap
[16:36] <ikey> well then ill fuck off and build a flatpak
[16:36] <ikey> cya
[16:36] <niemeyer> ikey: That's why a hangout is probably better :)
[16:37] <ikey> at this point niemeyer you insult me after having kept me waiting over a week with this tiresome review only to tell me what can and cant be in a base snap
[16:37] <ikey> without understanding the fundamentals of the situation
[16:37] <ikey> seriously i dont need snaps as much as snaps need external verification and technical acceptance
[16:37] <ikey> i dont need the politics and stress of it
[16:38] <kalikiana> sergiusens: did you see my email?
[16:39] <niemeyer> ikey: I'd still prefer to have this conversation on a hangout.. the few sentences I wrote aren't really personal at all.. I'm politely trying to explain the issues we're trying to address, and looking for help
[16:40] <ikey> as am - i cant word too good because im trying to stick a boot on at the same time
[16:40] <ikey> laces are hard
[16:40] <ikey> and fwiw im not personally insulted - there are levels :p
[16:40] <ikey> but im not against a phone call
[16:40] <niemeyer> ikey: https://hangouts.google.com/call/PwzjjN4oHDxFeAyGDiJ_AAEE
[16:40] <ikey> yeah gizza sec genuinely fighting with a boot here
[16:41] <sergiusens> kalikiana the one I replied to?
[16:41] <niemeyer> Will grab a cuppa coffee meanwhile... HO still open
[16:42] <mup> PR snapd#4266 closed: snapstate: add new refresh-hints helper and use it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4266>
[16:42] <niemeyer> If anyone else closely involved with base snaps wants to join, that's welcome too
[16:42] <niemeyer> mvo, jdstrand ^
[16:43] <kalikiana> sergiusens: I don't see a reply... not on my phone either, in case this was tb being broken
[16:45] <zyga-ubuntu> cachio: you have comments on 4227
[16:45] <zyga-ubuntu> cachio: looks like super simple ones
[16:46] <cachio> zyga-ubuntu, ok, finishing fedora resizing
[16:46] <zyga-ubuntu> cachio: thank you
[16:47] <sergiusens> kalikiana check your spam and filters (look in AllMail)
[16:47] <kalikiana> sergiusens: I don't have any spam filters, this is good old canonical imap
[16:51] <ikey> o-o
[16:51] <ikey> call closed
[16:53] <zyga-ubuntu> ikey: what happened?
[16:54] <ikey> fixed ^^
[17:02] <sergiusens> kyrofa elopio can you join me on a hangout right now?
[17:02] <kyrofa> sergiusens, sure
[17:03] <sergiusens> kyrofa use the weekly
[17:04] <kyrofa> sergiusens, I'm there
[17:04] <elopio> sergiusens: on my way
[17:20] <zyga-ubuntu> 14.04 has something very very wrong
[17:20] <zyga-ubuntu> snapd starts randomly when it is supposed to be down
[17:20] <zyga-ubuntu> cannot wait to find the culprit
[17:25] <pedronis> that is interesting
[17:28] <cachio> niemeyer, I dont see dsingle cuotes use to install any package
[17:29] <cachio> niemeyer, while I try to see why the snap-info test failedf
[17:29] <cachio> niemeyer, do you have any log?
[17:41]  * zyga-ubuntu breaks for some rest, will return to push more branches
[17:50] <zyga-ubuntu> so, why is main never failing
[17:50] <zyga-ubuntu> I'm running main all the time, almost, for the past two days
[17:50] <zyga-ubuntu> could it be that one of the "lesserly interesting" tests in other suites is messing things up
[17:51] <zyga-ubuntu> mvo: question, could we get a different entry in travis, one for running main and one for running all the things but main
[17:51] <zyga-ubuntu> mvo: we'd use more machines but they would also run much more quickly
[17:51] <zyga-ubuntu> mvo: and I suspect a pattern would emerge
[17:51] <zyga-ubuntu> mvo: (maybe even run suites independently from each other)
[17:51] <zyga-ubuntu> mvo: (like one status per suite)
[17:52] <zyga-ubuntu> mvo: this could have 3 advantages: restarts would be per suite, we'd get data about relative rate of random errors in each suite
[17:52] <zyga-ubuntu> mvo: and we could perhaps lower the number of workers
[17:52] <zyga-ubuntu> (or keep workers and get super-fast results)
[17:53] <zyga-ubuntu> if main is working on my "consumer" home network it should not fail any less on the fancy datacenter speedy network and CPUs
[17:54] <zyga-ubuntu> and meanwhile, I'll see what I get if I run other suites
[17:54] <zyga-ubuntu> I'd be really upset if it was like upgrade/basic killing our time by leaving junk
[17:58] <mup> PR snapd#4272 closed: snapstate: ensure RefreshSchedule() gives accurate results <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4272>
[17:58] <mup> PR snapd#4277 opened: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4277>
[17:58] <Chipaca> 12 37 files changed, 741 insertions(+), 309 deletions(-)
[17:59] <Chipaca> s/^12//
[17:59] <Chipaca> :-/
[17:59] <Chipaca> anyway, EOD for me
[17:59] <zyga-ubuntu> Chipaca: hohoho
[17:59] <zyga-ubuntu> Chipaca: oooh
[17:59] <zyga-ubuntu> Chipaca: please please please
[17:59] <Chipaca> zyga-ubuntu: wut
[17:59] <zyga-ubuntu> Chipaca: 4276
[17:59] <zyga-ubuntu> Chipaca: just a look
[17:59]  * Chipaca justs a look
[18:00] <zyga-ubuntu> Chipaca: per commit diff is easier to read
[18:03] <Chipaca> zyga-ubuntu: nice
[18:04] <Chipaca> zyga-ubuntu: http://gph.is/QUEGv3
[18:04]  * zyga-ubuntu types the URL on another computer
[18:05] <zyga-ubuntu> LOL
[18:06] <zyga-ubuntu> Chipaca: thanks, enjoy your evening
[18:11] <zyga-ubuntu> Chipaca: should we retry 504s from the store?
[18:11] <zyga-ubuntu> snap install --channel=beta core
[18:11] <zyga-ubuntu> that just failed with received an unexpected http response code (504)
[18:16] <ikey> zyga-ubuntu, qemu-static arm64 for /bin/sh - go!
[18:16] <ikey> definitely the most evil idea ive had all year.
[18:17] <zyga-ubuntu> ikey: heh, that might actually work pretty well
[18:17] <zyga-ubuntu> *for some definition
[18:17] <ikey> XD
[18:17] <zyga-ubuntu> single threaded
[18:17] <zyga-ubuntu> and ... static
[18:17] <ikey> lol
[18:17] <zyga-ubuntu> (insert meme with dog and "LOL", "so static", "enterprise", "runs on RHEL6"
[18:18] <ikey> yeah but if its not running on btrfs..
[18:18] <zyga-ubuntu> oh, why?
[18:18] <ikey> idk you said lol and enterprise
[18:18] <ikey> felt relevant
[18:18] <zyga-ubuntu> ikey: RHEL defines enterprise as RHEL and they define btrfs as xfs (or something)
[18:18] <zyga-ubuntu> ;-)
[18:19] <zyga-ubuntu> I like the "runs on RHEL6" as a meme thing
[18:19] <ikey> lol
[18:19]  * ikey used to live by reiserfs
[18:19] <ikey> emphasis on used to
[18:22] <niemeyer> cachio_afk: There's some other bug
[18:23] <niemeyer> cachio_afk: You should be able to reproduce it by just running spread to run this one task: linode:ubuntu-16.04-64:tests/main/snap-info
[18:23] <niemeyer> cachio_afk: The bogus command line, as cjwatson mentioned, is just a side effect of snapd not being properly built
[18:23] <niemeyer> cachio_afk: The question is why it wasn't properly built
[18:25] <niemeyer> Taking a break.. back later to finish the images
[18:26] <zyga-ubuntu> niemeyer: o/
[18:26] <zyga-ubuntu> niemeyer: we're on one page now ^_^
[18:32] <ikey> https://github.com/solus-project/runtime-snaps/commit/f91097d47fc1fce231110c87c2469a3f74df0a37 <- better.
[18:35]  * zyga-ubuntu -> shopping
[19:51] <zyga-ubuntu> jdstrand: hey
[19:51] <zyga-ubuntu> jdstrand: not much updates today, I'm getting tea and I'll iterate on both interesting PRs
[19:51] <zyga-ubuntu> jdstrand: I'm pushing towards finding why test suite is so unreliable
[20:36] <niemeyer> cachio: We've got multiple issues in our suite apparently
[20:38] <niemeyer> cachio: One of them is prepare-project.sh seems to be missing set -e, which means it's not stopping on errors
[20:38] <cachio> niemeyer, let me see
[20:38] <niemeyer> The build procedure is also for some reason not building _build/snap, which is depended upon for building the man pages
[20:39] <niemeyer> That's the error that makes the snapd_*.deb not be generated
[20:41] <niemeyer> cachio: I got this sort of error by just trying to run the task mentioned above
[20:41] <niemeyer> cachio: Possibly means I have a dirty tree.. I'll try again with a clean tree, but we should at least ensure all our scripts have -e so they fail on problems
[20:42] <cachio> niemeyer, ok, I jast reviewed the log and "set -e" was not removed from prepare-project
[20:42] <cachio> niemeyer, at least during the last 6 months
[20:43] <niemeyer> cachio: Well, does that matter? :)
[20:43] <cachio> niemeyer, we should add it
[20:43] <niemeyer> Yeah
[20:43] <niemeyer> cachio: We can also take the chance to grep quickly and see if there are others missing
[20:44] <cachio> niemeyer, doing that
[20:45] <cachio> niemeyer, most of the scripts on tests/lib dont have "set -e"
[20:46] <niemeyer> cachio: Some of them are used as libraries, so that's less of an issue I *think*
[20:46] <niemeyer> cachio: Won't hurt to have it, though
[20:47] <cachio> niemeyer, agree
[20:47] <cachio> I'll create a PR with that
[20:47] <niemeyer> cachio: Thanks
[20:47] <cachio> niemeyer, by the way, snapd-vendor is being sync
[20:47] <niemeyer> cachio: Looking into Spread-46 now
[20:47] <cachio> niemeyer, ok, I am testing debian-9
[20:48] <cachio> I'll push the changes once there are not errors anymore
[20:54] <niemeyer> cachio: Spread-46 has *grown* since we last tried
[20:54] <niemeyer> cachio: It's now at 2.2GB
[20:54] <cachio> I removed about 200 MB
[20:54] <niemeyer> Did you try the zero trick?
[20:55] <cachio> yes
[20:55] <niemeyer> (after that)
[20:55] <cachio> yes
[20:55] <cachio> the last think I did
[20:55] <cachio> let me check again
[20:56] <niemeyer> Well.. something curious is happening.. it's now larger
[20:56] <niemeyer> cachio: I'm booting it back up.. should take a few seconds
[21:06] <cachio> niemeyer, I could remove some locales that are using more than 100MB
[21:11] <cachio> niemeyer, not sure if it could affect anything
[21:13] <niemeyer> cachio: It's certainly less wasted space in the image
[21:13] <niemeyer> cachio: But it still doesn't explain why removing data made the image larger
[21:13] <niemeyer> cachio: Something else must have happened there
[21:13] <niemeyer> cachio: Does it have auto-update on, maybe?
[21:15] <cachio> niemeyer, it just updates repo metadata
[21:15] <cachio> I could disable it but not sure if then it could cause any issue
[21:16] <cachio> niemeyer, well it is alreasy disabled
[21:21] <cachio> niemeyer, could you try again to build the image?
[21:21] <niemeyer> cachio: Sure, trying it now
[21:22] <cachio> niemeyer, the only thing that it missing is to remove the locales
[21:25] <niemeyer> cachio: It's back at 1.7GB
[21:25] <niemeyer> cachio: 1.76, to be more precise
[21:25] <niemeyer> cachio: What did you do there?
[21:26] <cachio> cleaned up again dnf and removed 1 pkg and the zyga magic
[21:26] <zyga-ubuntu> try e4defrag
[21:26] <zyga-ubuntu> that may clear extra blocks for zero
[21:26] <zyga-ubuntu> (zero after)
[21:27] <cachio> ok
[21:27] <cachio> niemeyer, could you please start the vm?
[21:28] <niemeyer> It's coming up
[21:43] <cachio> niemeyer, could you please try againdf
[21:43] <niemeyer> cachio: On it
[21:43] <cachio> 1gb of data used
[21:44] <cachio> locales removed
[21:46] <niemeyer> cachio: 1.6G image
[21:49] <cachio> niemeyer, how do you create the image? it is a linode api?
[21:50] <niemeyer> cachio: Using the console.. I don't think there's an API yet
[21:51] <niemeyer> cachio: copy the disk, shutdown the machine, attempt to shrink the disk
[21:51] <niemeyer> cachio: trash it, start over
[21:52] <cachio> the shrink is not so powerfull :)
[22:02] <niemeyer> cachio: It's just resize2fs
[22:04] <niemeyer> cachio: We can try e4defrag
[22:05] <cachio> I already did in the vm
[22:05] <cachio> niemeyer, not sure if you can do it from the console
[22:05] <niemeyer> cachio: Oh
[22:05] <niemeyer> cachio: Ok.. so really have no idea about why it's not getting down to more reasonable sizes
[22:06] <cachio> disk usage is less than 1.1 GB
[22:06] <cachio> niemeyer, I checked that at the end
[22:07] <niemeyer> cachio: Well, that's logical size
[22:07] <niemeyer> cachio: Image is block size
[22:07] <niemeyer> cachio: A 1 byte file still takes one block
[22:08] <niemeyer> Sort of.. file system pages vs. blocks..
[22:08] <gsilvapt> kyrofa, since you are around, could you please have a look PR 1746? The build failed but I don't think it is entirely related with poor software quality
[22:08] <mup> PR #1746: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1746>
[22:09] <niemeyer> cachio: Can we take more data out of it?
[22:09] <kyrofa> gsilvapt, will do, working on something else at the moment but I'll take a look when I can
[22:09] <gsilvapt> kyrofa, of course, take your time! :-)
[22:10] <cachio> niemeyer, if you want I could create a new image from scratch
[22:10] <cachio> install deps and see the size
[22:13] <niemeyer> cachio: Sounds good.. another approach would be doing what I suggested yesterday, listing packages ordered by size and taking low hanging fruits out
[22:13] <niemeyer> cachio: Whatever you prefer
[22:14] <cachio> niemeyer, I already did that
[22:14] <cachio> I cleand 200MB doing this
[22:14] <cachio> cleaned
[22:14] <niemeyer> cachio: Yeah, so more of it? :)
[22:15] <cachio> niemeyer, well, the problem is that the bigger ones seem to be needed, I can make another try
[22:15] <cachio> and remove more pkgs
[22:17] <niemeyer> cachio: That's what I did when I got our images down to 600MB, but again any approach you prefer is fine by me
[22:18] <cachio> niemeyer, ok, I'll try it tomorrow morning
[22:18] <niemeyer> cachio: Thanks again
[22:21] <cachio> zyga-ubuntu, https://travis-ci.org/snapcore/snapd/builds/305892636#L1473
[22:22] <cachio> zyga-ubuntu, there it is the info for the "no interfaces found" issue
[22:30] <zyga-ubuntu> cachio: I'll check it out tomorrow, I'm sleeping here almost :)
[22:30] <cachio> zyga-ubuntu, sure, just I wanted to leave you a message for tomorrow
[22:31] <cachio> zyga-ubuntu, enjoy your dreams :)
[22:39] <sergiusens> kyrofa elopio kalikiana https://insights.ubuntu.com/2017/11/22/announcing-snapcraft-2-35/


[00:28] <spaok> anyone know how to curl against MAAS's oauth?
[01:34] <pmatulis> what do you mean?
[01:52] <spaok> pmatulis: instead of using python or ruby, using curl to make the oauth request to MAAS, kinda like this https://labs.hybris.com/2012/06/18/trying-out-oauth2-via-curl/
[01:57] <pmatulis> i don't know
[05:36] <RODOLFO> HI PLEASE  I NEED A LITTLE HELP BUT I DONT SPEAK ENGLISH ONLY A LITTLE BET
[09:41] <mup> Bug #1635493 changed: A wishlist to be able to destroy root filesystem after release <MAAS:Invalid> <https://launchpad.net/bugs/1635493>
[10:47] <junaidali> thanks roaksoax
[14:42] <mup> Bug #1646133 opened: [Device discovery] Show Last seen relevant to now <ui> <MAAS:New> <https://launchpad.net/bugs/1646133>
[16:18] <mup> Bug #1646160 opened: [2.1] Device discovery UI does not have a loading state <ui> <MAAS:In Progress by ricgard> <https://launchpad.net/bugs/1646160>
[16:18] <mup> Bug #1646162 opened: [2.1] Sticky header has been removed <ui> <MAAS:In Progress by ricgard> <https://launchpad.net/bugs/1646162>
[16:18] <mup> Bug #1646163 opened: [2.1] Icon need to be improved <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1646163>
[20:51] <BloqueNegro> hi all together :(
[20:52] <BloqueNegro> i tried setting up a test environment for openstack today, however, i failed already with maas
[20:52] <BloqueNegro> set up 3 nodes on esxi, all in one net, installed maas from a server info like here: http://maas.io/docs/en/installconfig-server-iso
[20:53] <BloqueNegro> then booted my other hosts which found the maas dhcp and booted
[20:54] <BloqueNegro> however, then i tried to add the power settings (with VMWare as BMC) and just got 'No rack controllers can access the BMC of node: amused-lemur'
[20:55] <BloqueNegro> the exact same data was working with maas 1.9 on 14.04, however there we ran into ssl issues later deploying landscape. and since the destination setup will work with 16.04 we need to get maas 2 running anyway
[20:55] <BloqueNegro> anybody got an idea what is causing that kind of trouble?
[21:08] <mup> Bug #1281758 opened: re-installing maas-region-controller fails <docteam> <MAAS:Expired> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1281758>
[23:42] <gottaloveit> looking for help please.  noob to maas, but not to linux and everything else.  i can't get nodes to commission.  and things like the "backdoor" user in the image, touching a file '/tmp/block-poweroff' like the docs say to prevent the scripts from auto powering down the node, just do not work at all.  its really frustrating.  does anyone have a quick checklist of things to look for that are easily overlooked?


[12:04] <lmanul> And thanks for the link :)
[01:42] <mgalvin> BenC: https://launchpad.net/bugs/28660 ... just a heads up i am in front of this machine now so let me know if there is anything you think I should try out
[01:47] <BenC> the problem with dmasound workaround, I'm at a loss for right now
[01:53] <lamont-away> BenC: since /etc/elilo.conf exists, the kernel postinst stops and asks if it should do that.   It needs to quit asking.
[02:03] <BenC> lamont: it's that way for any loader that has to be run afterwards
[02:03] <BenC> ia64 needs silent_loader=Yes in /etc/kernel-img.conf
[02:05] <lamont-away> oh, is that all?
[02:06] <lamont-away> which just means we need to change the creation of same...
[02:06] <lamont-away> or better yet, change the default :0)
[02:12] <BenC> right
[02:25] <BenC> lamont__: Confirmed, I set silent_loader in /etc/kernel-img.conf and installing the kernel didn't prompt me, it just ran elilo without interaction
[02:25] <lamont__> nice.
[02:25] <lamont__> so how do we change the default kernel-img.conf?
[02:26] <lamont__> BenC: actually, it'd be nice if breezy updates didn't prompt either... that kinda means changing the default to yes, doesn't it?
[02:30] <sn9> BenC: apparently the sound problems in the dapper kernel aren't limited to snd-powermac
[02:30] <BenC> emu10k is a seperate issue
[02:30] <BenC> and also fixed
[02:31] <sn9> damned|nb is having a similar problem with snd-hda-intel
[02:31] <BenC> lamont: not sure if changing the default is right
[02:31] <BenC> would affect lilo users
[02:31] <BenC> sn9: similar to what, powermac?
[02:32] <sn9> here's the dmesg line he pasted:
[02:32] <sn9> [17:17:39]  <damned|nb> [   20.840586]  HDA Intel: probe of 0000:00:1b.0 failed with error -16
[02:39] <lamont__> BenC: similar to what we did for mkinitramfs vs mkinitrd....  if arch==ia64, then set the default
[02:40] <lamont__> my $silent_loader   = '';
[02:40] <lamont__> $silent_loader='Yes' if ($arch eq "ia64");
[03:22] <zul> heylo
[04:06] <bubbalwz> BenC: after i laod the modules, you told me to run dmesg; dmesg isn't available from busybox
[04:06] <bubbalwz> as soon as i exit busy box i get a kernel panic
[04:11] <BenC> cat /proc/kmsg
[06:22] <mxpxpod> BenC: ping
[06:29] <mxpxpod> BenC: ping?
[07:06] <bubbalwz> BenC: k, looks like it loads according to kmsg
[07:06] <bubbalwz> megaraid detected; 1 logical drive
[07:06] <bubbalwz> scsi0: LSI Logic MegaRAID
[07:06] <bubbalwz> scsi device sda: 390590464
[07:07] <bubbalwz>  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
[07:13] <bubbalwz>  /proc/megaraid is there, config looks good