[00:35] <len-dt> ailo, where is your list of USB devices known to work?
[00:37] <len-dt> Both the ART devices seem to work as intended. They are both USB 1.1, so stereo, 44100/48000 at 16bit.
[00:49] <len-dt> ailo, looking at the specs I would say all 4 of the ART USB IF would work, but I have only tried the ART USB Dual Tube PRE and the ART USB Dual Pre Project Series. SO I know they both work for sure. Plug and go.
[00:50] <len-dt> ailo, I bought the dual tube and have found that even on my netbook, I can get good solid -p 64 service out of it with no xruns at all.
[00:53] <len-dt> ScottL, I hope you read the logs :-) The blue print works for me ok.
[00:54] <len-dt> Scott, the changing settings on the fly is done. The gui to set up what those changes are is not :-)
[00:56] <len-dt> ailo, Scott, others,  I am thinking that turning off cron, anacron and atd in record/tweak/performance mode is the way to go.
[01:00] <len-dt> My reasoning is this: even though, on any good(modern?) system it should not matter, because of it's intermittentcy, it would be very hard to track down. However, it can be turned on and off by installing/removing three files, so maybe it doesn't matter if it is configurable. In fact it may be easiest to just rename the files.
[04:59] <astraljava> Ooh, blueprints!
[05:00] <astraljava> Sorry guys, I crashed last night. Hopefully it'll mean I'll have more efficient bug fixing hours ahead. :)
[08:19] <ailo> len-dt: I regard fully supported those that function within their specs. So, if they are specified to work at 96kHz/24bits, that is what you need to be able to get
[08:19] <ailo> Are you saying your ART tube is a usb 1.1 device only?
[13:35] <len-dt> ailo, yes, the ART devices are USB 1.1, The USB is 16 bit and the spdif is 24 bit using two different ADCs
[13:37] <len-dt> They do have some USB2 devices, but they are many more pennies.
[13:49] <ailo> len-dt: Then it is a fully supported usb 1.1 device, which most usb2 devices are able to operate at also
[13:50] <ailo> So, for usb 1.1 operation, the list may be quite long
[13:50] <ailo> But not for usb 2
[13:50] <len-dt> ailo, Ya. I am looking at the moe expecive ones manual just now.
[13:55] <len-dt> ailo,  The voice channel has 24bit up to 192k USB and follows USB2 spec (no extra drivers for mac/win)
[14:01] <len-dt> their USB mic, which is USB2, Calls itself Linux compatible. However ailo, it does not have much info on how.
[14:04] <len-dt> It does bring to light one of the downfalls of USB mic. The package list says "3 meter USB cable ". It reminds me that is about the max length it should be.
[14:04] <len-dt> 3 meters for a USB cable is already long.
[14:06] <len-dt> I'm off.
[14:07] <knome> the "linux-compatible" part probably means that it works if you write the drivers yourself. :)
[14:09] <len-dt> knome, I think it means if you plug it into a linux system audio will get in... the question is will it be anything more than 16 bit at 44.1/48k
[14:09] <knome> :)
[14:09] <len-dt> The unit is too many pennies for me to buy and try out..
[21:13]  * Len-nb is thinking out loud
[21:14] <Len-nb> ailo, since I am using runlevels to determine modes of operation, there are some things that need to be taken care of.
[21:16] <Len-nb> The first thing is that a user can from the boot command line have the system boot directly into "Audio mode" (or video mode should such a thing come into being)
[21:16] <Len-nb> Also, a user while in "audio mode" may log out and back in without changing the mode.
[21:17] <Len-nb> This can be either a feature or a bug. I would prefer to call it a feature.
[21:18] <Len-nb> I might even go so far as to try to have the system boot to whatever mode it was in at shutdown.
[21:21] <Len-nb> However that would take away the option for the user to determine a mode at boot time.
[21:22] <Len-nb> Anyway, that takes care of system side things (anything requiring root perm)
[21:23] <ailo> I've been working on the web site today
[21:23] <Len-nb> userland things like pulse on or not would have to be set at login time depending on what the runlevel is.
[21:23] <Len-nb> ailo, how has that gone?
[21:23] <Len-nb> is that wiki or US web site?
[21:23] <ailo> Pretty well. I'm slimming it down, and trying to get it ready for publishing asap
[21:24] <ailo> ubuntustudio.org, which is worked at https://staging.ubuntustudio.org
[21:24] <Len-nb> Good, that is the one thing really missing.
[21:24] <ailo> Right now I'm working on the feature tour
[21:25] <Len-nb> I have to run, kids to take to the dentist... so I am gone a few hours.
[21:25] <ailo> ok. I'll be going to sleep in a moment. Catch you later
[21:25] <Len-nb> I'll take a look when I get back
[21:37] <ailo> Right now it would just be nice to finish up the feature tour. Try to keep it simple, and attractive looking
[21:38] <ailo> After that, and making sure all the text is correct and up to date, it just needs to be published
[21:38] <ailo> A more thorough documentation, hosted at the main site can be published for next release
[23:32] <len-dt> ailo, on https://staging.ubuntustudio.org/tour/ubuntu-studio/, you have "Ubuntu Studio is Linux-based" it should be "Ubuntu Studio is a Linux-based"
[23:32] <len-dt> ailo, I'm assuming you want me to be picky ;-)
[23:34] <len-dt> One paragraph down, second sentence "Ubuntu Studio free" should be "Ubuntu Studio is free"
[23:35] <len-dt> next page: https://staging.ubuntustudio.org/tour/audio/, under Jack, "eve" should be "even"
[23:36] <ailo> len-dt: I haven't done any text editing on those pages yet
[23:37] <len-dt> Did you want comments on spelling then?
[23:37] <ailo> I'm not really finished with much yet
[23:37] <ailo> The downloads page is mostly done
[23:38] <ailo> I've just started adding some pics to the feature tour thing
[23:38] <ailo> That will take most time I think
[23:39] <ailo> The links on the download page don't work yet. I'll fix that
[23:39] <ailo> For next release, I'll want to move installation instructions to a doc page
[23:39] <ailo> For now, I think it's fine as it is, given there isn't any strangeness with the wording etc
[23:45] <ailo> Ok, I better go to sleep now. I estimate it will take me another couple of weeks to finish my efforts for the web site and the wiki, so testing will come after that for me. So, perhaps in two weeks time


[09:12] <brobostigon> morning boys and girls.
[09:17] <zmoylan-pixi> mutter mutter sugarpuffs mutter
[09:22] <brobostigon> is that gnome-shell mutated?
[09:40] <zmoylan-pixi> mutter toast no marmalade
[17:46] <daftykins> Rammstein breakfast edition?
[18:56] <zmoylan-pixi> another data leak for the rich and shameless... http://www.bbc.co.uk/news/uk-41876942
[18:57] <zmoylan-pixi> the queen will have to have a good long talk with herself for avoiding her own customs and excise


[09:12] <BroMac> Hi guys. Is the screen resolution can affect the use of a network link?
[09:13] <BroMac> more transfer?
[09:24] <BroMac> Helllooooo?? :))))
[09:54] <BroMac> Who can help me??
[09:55] <BroMac> Is the screen resolution can affect the use of a network link?
[10:25] <BroMac> HELLLO ;]
[10:46] <BroMac> who can help me with optimal resolution of monitor?
[11:07] <BroMac> who can help me with optimal resolution of monitor?
[11:07] <BroMac> who can help me with optimal resolution of monitor?
[11:07] <BroMac> who can help me with optimal resolution of monitor?
[11:07] <BroMac> who can help me with optimal resolution of monitor?
[11:07] <BroMac> who can help me with optimal resolution of monitor?
[11:07] <BroMac> ;]
[11:07] <jussi> BroMac: no one if you spam like that
[11:07] <jussi> !repeat
[11:08] <BroMac> I'm sorry
[11:08] <jussi> BroMac: tell exactly the issue you hae, then someone might say they can help
[11:08] <jussi> !gq
[11:09] <BroMac> but I have a question with thin client on edubuntu
[11:09] <jussi> BroMac: yes, so ask the quesrtion, and lets see if we can answer it! :D
[11:10] <BroMac> so ok
[11:10] <jussi> BroMac: mind, many of the people who can answer your questions wont wake up for an hour or 2.


[01:59] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 763 @ https://fridge.ubuntu.com/2022/11/28/ubuntu-weekly-newsletter-issue-763/ (by guiverc)
[11:02] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: VMware to open source: what do you need to consider? @ https://ubuntu.com//blog/vmware-to-open-source-what-do-you-need-to-consider
[13:12] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Application migration: best practices for success @ https://ubuntu.com//blog/application-migration-best-practices-for-success


[00:05] <ogra_> slangasek, so i discovered a quite bad bug with multiarch and am pondering what to file it against ...
[00:05] <xnox> stgraber: do we have wallpapers contest selected?!
[00:05] <ogra_> if you enable any ports arch apt-get update chockes (rightly) on security.ubuntu.com ...
[00:06] <stgraber> xnox: no idea
[00:06] <xnox> ogra_: yes. noticed that as well. hardly new news, one should limit arches on security.
[00:07] <xnox> stgraber: i'll poke seb128 tomorrow.
[00:07] <xnox> bdrung: kk.
[00:07] <xnox> good night all =)
[00:08] <ogra_> xnox, one ?
[00:08] <ogra_> xnox, i used dpkg --add-foreign-arch or some such ...
[00:08] <ogra_> and afterwards apt-get update was broken
[00:09] <ogra_> if we provide that level of automation, the automation should work :)
[00:50] <cjwatson> jamespage,zul: looks like python-babel needs an MIR?
[00:51] <cjwatson> Or else the dep needs to go - can't quite make it out from the diff
[00:53] <zul> cjwatson:  yeah will get to it tomorrow
[00:57] <cjwatson> Ta
[01:45] <ini> are any contributers free for a 5 minute conversation? i'm working on a paper about open source, and would love to hear from a developer
[05:22] <ikepanhc> @pilot in
[05:39] <pitti> Good morning
[05:40] <RAOF> pitti: Yo!
[05:44] <elky> Either apport just sent me to the page for a non-existent bug or to a bug locked for security. Is it supposed to do that? Known issue?
[05:45] <elky> I suspect the former, because incrementing/decrementing the number isn't bringing up any visible bugs.
[05:46] <StevenK> What's the number?
[05:47] <elky> 1142546
[05:47] <elky> doesn't seem to be anything within a range either side of it.
[05:48] <elky> either that, or a few dozen security bugs landed at once.
[05:49] <StevenK> It's private
[05:50] <elky> apport should probably check that...
[05:50] <StevenK> There's an open apport bug about it
[05:50] <elky> heh
[05:50] <StevenK> IIRC
[05:51] <elky> private too, i assume :P
[05:51] <StevenK> I don't think so, but I can't recall the number.
[05:52] <elky> Probably for the best, we'd risk overdosing on irony.
[05:53] <StevenK> elky: People keep blaming LP for this, but I don't think it's an LP problem.
[05:53] <elky> StevenK, for what, the apport not checking that value in the api response or whatever?
[05:54] <StevenK> I'm not sure how apport decides it's already reported as <private bug>
[06:02] <ScottK> Maybe apport has too many privileges on LP.  If it couldn't see the private bugs, it would never dupe against them ...
[06:06] <pitti> there is https://launchpad.net/~apport which owns all private crash bugs until they get retraced and the core dumps removed
[06:07] <pitti> then ~ubuntu-crashes are subscribed to them
[06:07] <StevenK> ScottK: And then you have tonnes of dupes.
[06:07] <StevenK> But we sort of do already
[07:47] <dholbach> good morning
[07:48] <dholbach> Quintasan, happy birthday! :)
[08:50] <mmrazik> cjwatson: morning
[08:51] <mmrazik> cjwatson: did nuclearbob follow up with you yesterday regarding the installing issues?
[08:52] <ikepanhc> @pilot out
[08:55] <seb128> gema_, hey, did you guys notice any issue with raring daily installs recently? mmrazik was looking at why jenkins/utah is failing to run on the unity setup and think it's a platform issue and that you guys probably ran into it as well?
[08:55] <mmrazik> gema_: nuclearbob was looking into that yesterday
[09:07] <gema_> seb128, mmrazik I had a problem installin yesterday but not sure if it is related
[09:07] <gema_> mmrazik: do you have a bug numbeR?
[09:08] <mmrazik> seb128, gema_: I'm just reporting a bug. Will paste the # in a minute here
[09:08] <gema_> mmrazik: ack
[09:09] <gema_> mmrazik: nuclearbob was investigating a problem with bootspeed testing that we had over the weekend as well, not sure if it is the same, though
[09:09] <mmrazik> it most likely is
[09:10] <gema_> mmrazik: ack, it doesn't look solved to me, he attempted to run bootspeed 6 times yesterday
[09:13] <gema_> with 0 success
[09:15] <mmrazik> gema_, seb128, cjwatson: Here is a bug with the issue: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1157065
[09:15] <mmrazik> I hope all the logs are there
[09:15] <mmrazik> if not, let me know
[09:17] <zyga> utlemming: ping
[09:17] <seb128> mmrazik, thanks a lot, I think it has the debug logs needed, let's wait for cjwatson
[09:17] <mmrazik> seb128: I just don't see anything obvious there :-/
[09:18] <mmrazik> hope cjwatson will see more
[09:18] <OdyX> pitti,tkamppeter: Damn, cups 1.6.2 is out, time for a big^2 merge; I'll likely have 'some' time to work on it this week and will start in a different branch (so that master stays buildable at all times)
[09:21] <gema_> mmrazik: thanks a lot
[09:22] <zyga> utlemming: vagrant got 7 new releases, we are still at 1.0.3 which refuses to start on raring with virtualbox 4.2, current vagrant upstream is 1.1.2, do you think we can work on getting FFE and get that package updated?
[09:22] <mpt> ev, did you hear any more from m4n1sh after helping him with the activity-log-manager integration?
[09:23] <ev> mpt: not yet
[09:23] <ev> we exchanged a couple of emails
[09:23] <ev> but I haven't heard anything since
[09:24] <mpt> hmmm
[09:24] <mpt> that's unfortunate
[09:29] <ev> mpt: he did say he felt it unlikely to get done in time for FF
[09:35] <OdyX> win 25
[10:32] <pitti> slangasek: I took the liberty to retarget https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration to s-series and milestone ubuntu-13.05 to reflect the declined FFE
[10:33] <tkamppeter> OdyX, pitti, we can go ahead of getting CUPS 1.6.2 into Ubuntu, seb128 is OK with it as the new release is bugfix-only.
[10:35] <OdyX> tkamppeter: I pushed master-1.6.2 to the git repository, now it needs patches review, refresh and drops, I'll do that later today, if you don't beat me to it.
[10:36] <tkamppeter> OdyX, great, if it gets tready today there is plenty of time that it gets tested in the Ubuntu environment. Please tell me when you are ready and I will sync it into Raring.
[11:16] <mmrazik|lunch> gema_: regarding the pre-seed stuff and lp:1157065 -- there is an utah-related question I can't answer. Can somebody look there?
[11:17] <cjwatson> Yeah, it looks to me as if the preseed file is simply not being applied
[11:18] <cjwatson> You're preseeding some questions successfully, but as far as I can see only because they're listed directly on the kernel command line (which doesn't scale) rather than relying on the preseed file for them
[11:22] <ogra_> oh, i didnt chgeck the cmdline ...
[11:22] <ogra_> *check
[11:27] <xnox> cjwatson: using that preseed and seeding it with url, still the keyboard page, where i had to manually click continue. watching the slideshow now.
[11:27] <xnox> (debian-installer/locale did work before, I'll test that with nexus7 as well, before filing a bug)
[11:31] <gema_> mmrazik|lunch: we'll have a look
[11:43] <cjwatson> xnox: the keyboard is being preseeded on the kernel command line, not in the preseed file
[11:43] <cjwatson> (in this case)
[11:46] <xnox> cjwatson: is it one of those that must be presseded before ubiquity (e.g. on the command line) anyone, i'd think many people would notice quickly if keyboard was getting people stuck.
[11:46] <xnox> s/anyone/anyway/
[11:51] <mdeslaur> @pilot in
[11:52] <cjwatson> xnox: the command line vs. preseed file distinction is only relevant to d-i, not to ubiquity
[11:53] <xnox> ok.
[11:53] <cjwatson> xnox: with ubiquity, *everything* is preseeded before ubiquity anyway, because ubiquity doesn't process preseed files - that's casper's job
[11:58] <mpt> Any geolocation experts in the house? I'm trying to write a caption to explain the effect of turning off GPS on Ubuntu Phone
[11:58] <xnox> mpt: considering we yet to have GPS capable framework in the OS, currently turning gps on/off makes no difference =)
[11:59] <ogra_> but you can talk about it in the UI :)
[11:59] <seb128> mpt, you can maybe try #ubuntu-touch if nobody on -devel has an opinion
[11:59] <ogra_> yeah
[11:59] <mpt> As I understand it, geolocation with GPS + Wi-Fi is excellent, GPS only is pretty good, Wi-Fi only is patchy, and with neither is down to the country level. Is that right?
[11:59] <ogra_> #ubuntu-touch would likely be better
[12:00] <seb128> xnox, speaking about geoclue, is this bug about hongkong not being in the ubuntu geoname db still on your list? we got a similar one that singapore is missing as well
[12:00] <xnox> mpt: there is also 3G network signal tower location based detection, if one is provided by your operator. That is usually "bundled" into GPS chip though.
[12:01] <xnox> seb128: yes, I was pondering about it. We used to have a bug of having too many duplicates, now I'm thinking we remove way too many. I'll add some unit tests.
[12:01] <seb128> ok
[12:03] <cjwatson> I don't think it's necessarily true that "with neither [it's] down to the country level" - it depends on the quality of the geoip database in use
[12:05] <xnox> mpt: yeah, with virgin media cable broadband it's down to roughly first part of the post-code at times.
[12:05] <xnox> for example.
[12:05]  * cjwatson tries to remember how to get geoname-lookup.ubuntu.com to actually give him an answer
[12:06] <xnox> cjwatson: http://geoname-lookup.ubuntu.com/?query=Kong
[12:06] <cjwatson> xnox: no, I mean for my IP
[12:06] <cjwatson> But anyway with the maxmind database installed there it's often at at least city level.  I suspect quality varies
[12:07] <cjwatson> Ah, what I actually meant was http://geoip.ubuntu.com/lookup
[12:08] <cjwatson> That claims I'm in London, so it's obviously not all the way there yet ...
[12:08] <cjwatson> Pretty sure I've seen it do better
[12:08] <mlankhorst> well there should probably at least be some validation the country is correct..
[12:12] <mpt> thanks xnox, cjwatson
[12:14] <xnox> mpt: http://geoip.ubuntu.com/lookup for me is just two digits away on the first part of the zipcode.
[12:15] <mpt> Thinks I'm in Bexley
[12:19] <cjwatson> zipcode?  American :P
[12:20] <ogra_> my zipcode is backwards ...
[12:20] <ogra_> (05 instead of 50)
[12:21] <ogra_> ah, wait, no, its the region code
[12:21] <ogra_> it doesnt actually show a zip code
[12:23] <cjwatson> Putting "ZipPostalCode" in the DTD for an allegedly geographically-agnostic service was a pretty bad design :)
[12:24] <cjwatson> (ZIP -> Zone Improvement Plan, a term used specifically by the US Postal Service)
[12:24] <ogra_> but at least it has improvement in the name :)
[12:35] <seb128> gema_, did you found anyone to answer the utah question in that bug? (would be good to see that fixed, it's blocking unity changes to land for some days)
[12:50] <gema_> seb128: I am waiting for nuclearbob to go online to ask him
[12:51] <nuclearbob> gema: ask me wt?
[12:51] <seb128> gema_, hum, k
[12:51] <gema_> nuclearbob: can you read the history on this channel
[12:51] <cjwatson> nuclearbob: question from me in bug 1157065, specifically
[12:51] <nuclearbob> gema: looks like seb128 was asking about a bug, do either of you have the bug number?
[12:52] <nuclearbob> cjwatson, thanks
[12:53] <nuclearbob> cjwatson seb128: do you want me to answer in the channel or respond to the bug?
[12:53] <cjwatson> bug, I guess
[12:53] <nuclearbob> thanks, doign that now
[12:53] <seb128> whatever works for cjwatson
[12:53] <seb128> thanks
[12:58] <gema_> nuclearbob: any chance we've changed something that may have broken the preseeding code?
[12:58] <nuclearbob> gema: we haven't updated the code on magners-orchestra yet, and the problem occurred before I even branched the testing code there
[12:58] <cjwatson> I followed up again.  I wonder if the new busybox might be implicated
[12:59] <cjwatson> Has this been broken perhaps for about four or five days?
[13:00] <seb128> cjwatson, we noticed yesterday the issues for the first time, but nobody is watching during the w.e
[13:00] <gema_> nuclearbob: ack
[13:08] <cjwatson> I'm grabbing a current image to see if I can tell whether casper-set-selections is just generally broken
[13:13] <zyga> utlemming: ping
[13:23] <zyga> mpt: do you think that clicking on the trash / rubbish bin icon should "focus" that icon in the launcher?
[13:23] <zyga> mpt: right now it opens nautilus which to me, feels wrong/confusing
[13:24] <cjwatson> casper-set-selections doesn't seem obviously broken
[13:24] <seb128> zyga, what do you mean "focus the icon"?
[13:25] <seb128> zyga, which is opening the "rubbish bin" location wrong when clicking on the corresponding icon?
[13:25] <zyga> seb128: show the triangle on the left side
[13:25] <zyga> seb128: start with an empty desktop
[13:25] <zyga> seb128: click on the trash can
[13:26] <zyga> seb128: you get nautilus, which is one of the fist few icons (counting from top)
[13:26] <zyga> seb128: I would have expected the tash window to be "active/focused" (correct me on the right term) and the nautilus icon remained as is
[13:26] <cjwatson> nuclearbob: another information request in that bug
[13:27] <zyga> cr3: hey! :)
[13:27] <seb128> zyga, known issue, same with device icons (usb sticks, cds, ...)
[13:27] <zyga> seb128: ah, thanks
[13:27] <seb128> zyga, it comes down to the fact that all those are nautilus views and the matching is not smart enough to make the difference
[13:27] <zyga> seb128: I just realized it and wondered if there should be a bug on that or not
[13:28] <seb128> trevinho from the unity team has been working on improving that
[13:28] <zyga> seb128: yeah, I realize that it's probably that :) I was thinking about the design aka how-it-should-work
[13:28] <seb128> like with the current version it will open locations only one
[13:28] <nuclearbob> cjwatson: I'll try to recreate that with that option on.  I'm seeing the same error on debian-installer based images as well, if that makes a difference
[13:28] <seb128> where it used to open new views every time you clicked
[13:28] <cjwatson> nuclearbob: Possibly.  What would help is a way to reproduce this outside of utah
[13:29] <cjwatson> Or at least locally without a big lab setup
[13:30] <nuclearbob> cjwatson: so far I can't even consistenly recreate it in utah, but I'm working on both.  as I've looked at it, we do set DEBCONF_DEBUG=developer on all server installs, but not desktop.  I'm trying to run with that on desktop now
[13:30] <cjwatson> Commonality with d-i would not conflict with the hypothesis that it's a busybox regression, but that's still a wild guess hypothesis
[13:30] <nuclearbob> okay
[13:31] <nuclearbob> I haven't had any luck recreating it on a vm so far, unfortunately, I'm still working on that
[13:31] <OdyX> tkamppeter: lol; no ipp14 is shipped in cups 1.6.1, at all.
[13:31] <OdyX> spotted that with unrelated lintian warnings
[13:32] <cr3> zyga: hi there, any updates on adopting subunit?
[13:33] <zyga> cr3: no, we're deep in SRU stuff, trying to get stuff to work enough to switch SRU process to plainbox
[13:34] <zyga> cr3: I was talking about the way we submit data to certification website but we don't expect any changes in that area until after we get all of plainbox + gui done
[13:34] <cjwatson> nuclearbob: FWIW d-i is usually easier for me to debug
[13:35] <cjwatson> nuclearbob: so if you can reproduce it there, especially if any more reliably, then we should start with that
[13:35] <nuclearbob> cjwatson: I can get it to show up more easily on d-i, I just don't know how to get the logs out then.  If you have access to the lab vpn, I can get you a system where it's failing
[13:35] <nuclearbob> cjwatson: I'm still trying to setup a recreate outside of the lab as well
[13:35] <cjwatson> nuclearbob: boot with serial console and the logs should come out there?
[13:36] <cjwatson> nuclearbob: can you link me to the directions for setting up the lab VPN so I can compare them against what bits of network I have?
[13:36] <cjwatson> I use VPNs so rarely that I honestly can't remember
[13:37] <cr3> zyga: when do you think plainbox will finally replace checkbox?
[13:37] <nuclearbob> cjwatson: we don't have anything attached to the serial port on most of these machines, but there's one I can try
[13:37] <nuclearbob> cjwatson: I'll see if I can find the lab vpn info
[13:38] <zyga> cr3: never, checkbox will stay as a project name and something people use, it will just use plainbox for everything not specific to checkbox itself
[13:38] <zyga> cr3: as for when it will be rolled out in any form
[13:39] <zyga> cr3: the SRU process is still using checkbox but we're doing a test SRU on one machine with plainbox, so far it does nothing but we're plugging the pieces, we basically have everything needed, it's just not plugged into that command
[13:39] <zyga> cr3: once that works and we iron out any bugs we'll look at what's the next step
[13:39] <cr3> zyga: very exciting!
[13:39] <zyga> cr3: probably GUI and then full replacement
[13:39] <zyga> cr3: I wrote a proposal for new job description format that hopefully plugs one issue with current jobs, would you like to have a look at that?
[13:40] <zyga> cr3: http://jobbox.readthedocs.org/en/latest/jobspec.html#jobbox-job-definition the interesting parts that matter are around parse-job-pattern
[13:40] <zyga> cr3: the rest is not essential, just 'cleanup'
[13:41] <zyga> http://jobbox.readthedocs.org/en/latest/jobspec.html#parse-job-pattern this is a better link
[13:41] <zyga> cr3: the idea is to be able to discover dependencies across local jobs
[13:42] <zyga> cr3: by creating 'maybe' jobs that _might_ be generated by a particular local job
[13:43] <zyga> cr3: so I could run for example "bandwith_test_wlan0" (hypothetical example) and have plainbox discover the dependencies to discover and run that job
[13:43] <cr3> zyga: I don't have enough brain to allocate to understand what parse-job-pattern does, I'm starting to swap
[13:43] <zyga> cr3: hehe, sorry to try to drag you into this parse-job-pattern is just a way to tell plainbox that a particular local job can only generate jobs that match some specified pattern
[13:44] <zyga> cr3: so that "bandwith_test_wlan0" job would come from "bandwith_tests" local job (all examples so far) that has parse-job-pattern equal to "bandwith_test_{interface}"
[13:45] <zyga> cr3: so any job that is not know to the core, that matches any of the local job patterns can be traced via that possible route to a local job, where we can already discover dependencies needed to run it
[13:52] <cr3> zyga: oh, that's nice indeed. thanks for the explanation!
[14:13] <mpt> zyga, I think that as long as the Launcher includes either the Trash or Web apps, and especially if it shows both,  it shouldn't try to highlight the focused app at all.
[14:14] <mpt> (And double-especially if it ever gets the ability to hold other folders and bookmarks.)
[14:14] <zyga> mpt: I wasn't clear, it's not just focus
[14:15] <zyga> mpt: it's the triangle that shows the app is running (correct me on how that is called)
[14:15] <zyga> mpt: unlike webapps, the trash is never 'active' in that sense
[14:15] <zyga> mpt: having both the trash and nautilus having triangle as with webapps would be a good consistent compromise probably
[14:15] <zyga> mpt: (actually focus is entirely not related to that, I just used the wrong term earlier)
[14:18] <mpt> zyga, I don't care about that. It was included as an issue in past Unity usability tests -- difficulty in telling which applications were running -- and I thought, "why is that even a problem?"
[14:18] <zyga> mpt: I'm not sure what that means, I'm trying to figure out if that's a problem according to you and if so, should there be a bug about that
[14:20] <zyga> mpt: if you mean that the function of the triangle is not relevant and that it will go away entirely then that's probably fine
[14:23] <mpt> zyga, I think you're confusing me with someone involved in the design of Unity. :-)
[14:23] <zyga> mpt: re-reading your first statement it makes the launcher act as a bar with buttons that each "do something to show the application", in that context it is accurate and especially with more mobile-like application lifecycle it's wrong to try to show the state of any application as we're building an ilusion that apps always work
[14:24] <zyga> mpt: sorry, you seem like a go-to person for questions regarding design issues, if you know who should I be talking to instead please redirect me
[14:25] <mpt> zyga, try #ubuntu-design perhaps
[14:25] <zyga> thanks
[14:25] <xnox> zyga: or #ubuntu-touch and #ubuntu-unity
[14:26] <zyga> I'll try -desing and -unity
[14:26] <ogra_> nuclearbob, does your casper script actually do more than just copying the preseed to / ? (might probably make sense to attch it too)
[14:26] <ogra_> *attach
[14:26] <nuclearbob> ogra_ yeah, it copies some other files we use in the success_command.  I'll attach it to the bug
[14:26] <ogra_> nuclearbob, but it doesnt have any code to apply the preseed ?
[14:27] <cjwatson> Not necessary anyway
[14:27] <cjwatson> casper applies it itself
[14:27] <cjwatson> As long as it's called /preseed.cfg in the initramfs, which AFAICS it is
[14:27] <ogra_> i'm not sure there is anything doing that by default
[14:27] <ogra_> ah k
[14:28] <nuclearbob> cjwatson and ogra_: during my testing, having it in the initramfs wasn't enough, I had to get it into the live fs for it to work.  I may have been doing something else wrong, but at this point, we copy it from the initramfs to the livefs with a casper-bottom script I'm about to uploda to the bug
[14:28] <cjwatson> I wish you'd reported that ...
[14:28] <cjwatson> Because it is meant to work
[14:28] <nuclearbob> sorry about that, at the time I was mostly assuming that all the process problems were my fault
[14:29] <nuclearbob> we also copy an rsyslog configuration file in that script, I'll upload it as well
[14:30] <cjwatson> In fact I'm really not sure whether copying the preseed achieves anything at all, although it's perhaps useful documentation
[15:01] <slangasek> pitti: retargeted> sounds good, thanks
[15:08] <tkamppeter> OdyX, you need to conserve the ipp14 patch. I have added ipp14 as Mike is refusing to fix certain regressions which came in with CUPS 1.5.x as he made the ipp backend more IPP-conforming. For the few people with these problems I have made avaialable the ipp backend of the old CUPS 1.4.x as ipp14.
[15:14] <mitya57> fginther: is there any reason why you didn't propose a merge for your branch lp:~fginther/+junk/python-coverage-fix-1109090 ?
[15:14] <mitya57> I've just run into the same issue
[15:22] <mitya57> fginther: nevermind, this is an issue in Debian patch so should be fixed there, not by adding a new patch. I'll now do this.
[15:22] <fginther> mitya57, sorry.  I was refresshing my memory
[15:23] <mitya57> will have a MP in 5 minutes
[15:23] <fginther> mitya57, yes, that sounds right. I realized it wasn't the right fix and never got around to doing it correctly
[15:23] <fginther> mitya57, I'll review
[15:29] <mitya57> fginther: https://code.launchpad.net/~mitya57/ubuntu/raring/python-coverage/lp1109090/+merge/154123
[15:29] <OdyX> tkamppeter_: build in progress, will push to Debian experimental 'soon'
[15:32] <fginther> mitya57, approved
[15:32] <mitya57> fginther: thanks!
[15:33] <mpt> katie, bug 1084979
[15:34] <slangasek> jodh`: daily upstart build failure on armhf that I don't understand: https://launchpad.net/~canonical-foundations/+archive/upstart-daily/+build/4381411
[15:34] <slangasek> jodh`: has this been ongoing, or is it new?
[15:34] <jodh`> slangasek: I think this might be the issue xnox has seen?
[15:35] <slangasek> jodh`: I don't know :)
[15:35] <jodh`> slangasek: I'll see if I can recreate...
[15:36] <xnox> jodh`: yes, that's what i have been seeing.
[15:37] <xnox> slangasek: we exhaust inotify watches in some parts of the test-suite, but if system makes one watch free, then the part of the tesuite that is running in "no inotify available" can fail as suddently inotify became available and e.g. jobs got automatically reloaded instead of manual reloading.
[15:38] <xnox> jodh`: make -C init -j4 check : is the quickest way to reproduce. Assuming you have multiple core machine.
[15:39] <OdyX> tkamppeter_: cups 1.6.2-1 uploaded to Debian experimental
[15:39] <slangasek> xnox: ugh, we're *exhausting* inotify?  This sounds like it could be a problem at runtime too, especially with user sessions
[15:41] <mdeslaur> @pilot out
[15:41] <xnox> slangasek: on purpose hitting the limit, to see what happens when there are no inotify watches left.
[15:42] <slangasek> ah, well then
[15:42] <xnox> otherwise it is quite large per user, and unlimited system wide.
[15:43] <xnox> slangasek: well the limit is max # of open file descriptors per process.
[15:45] <jodh`> xnox: well, the magic number happens to correspond to the same value on the buildds; we should really query that rlimit :)
[15:59] <jono> didrocks, hey, I noticed that most of these scopes in the PPA don't seem to display in the dash results
[15:59] <jono> is that normal?
[16:00] <didrocks> jono: the server is sending fake scope recommendations
[16:00] <didrocks> jono: so it's always starting the same
[16:00] <didrocks> the ETA to get it fixed is in 2 days IIRC
[16:01] <jono> didrocks, ahhh cool
[16:01] <jono> didrocks, it seems there is also an issue with queries happening after every keystroke
[16:02] <didrocks> jono: please opens bugs and tag them 100scopes
[16:02] <didrocks> jono: https://bugs.launchpad.net/unity/+bugs?field.tag=100scopes
[16:03] <jono> didrocks, will do now
[16:03] <didrocks> thanks :)
[16:06] <jono> didrocks, https://bugs.launchpad.net/unity/+bug/1157263
[16:09] <didrocks> jono: thanks!
[16:56] <tkamppeter> OdyX, thanks for updating CUPS on Debian, I am now waiting for Debian's build servers so that I can sync the new package.
[17:02] <ogra_> tkamppeter, oh since i saw you asking on the ML ... http://www.heise.de/open/artikel/Dells-Ubuntu-Ultrabook-im-Test-1823594.html there is a dell XPS review
[17:02] <tkamppeter> ogra_, thanks, will look ...
[17:04] <awe_> seb128, ping
[17:04] <seb128> awe_, hey
[17:04] <awe_> looking at the bt indicator I just reviewed https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1123115
[17:05] <awe_> and https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1116292
[17:05] <cjwatson> tkamppeter: FWIW you don't need to wait for Debian buildds to sync a package, only for the source package to be published in the archive and (shortly afterwards) noticed by the cron job in Launchpad that imports it into launchpad.net/debian/+source/<package name>
[17:05] <awe_> doesn't "Breaks/Replaces" cause gnome-bluetooth to not be installed?
[17:06] <awe_> and if so, doesn't that break support for "Setup New Device"?
[17:06] <seb128> awe_, no, it does "Breaks: gnome-bluetooth (<< 3.6.1-0ubuntu2)" which force a newer version to be installed
[17:06] <seb128> awe_, newer version = one without our indicator patch
[17:07] <awe_> ah OK
[17:07] <awe_> sorry I misunderstood
[17:07] <seb128> no worry ;-)
[17:07] <seb128> we still use gnome-bluetooth
[17:07] <seb128> that's what has the wizard ui
[17:07] <awe_> I missed the << part
[17:08] <awe_> looks like indicator-bluetooth is missing "sendto" though
[17:08] <seb128> awe_, you mean?
[17:08] <seb128> I've a "send files" entry in the submenu for my phone
[17:09] <awe_> wow, I'm batting 0 for 2
[17:10] <awe_> I really haven't worked with vala all that much, and it looks like "sendto" and "wizard" are handled differently
[17:10] <seb128> what do you call "sendto"? sending files to a device ?
[17:11] <seb128> and yes, it's possible things are different
[17:11] <seb128> I think robert_ancell tried to follow mpt's spec
[17:11] <awe_> correct
[17:11] <seb128> where the previous one was maybe not 100% conform to the spec
[17:11] <awe_> the wizard is launched via Process.spawn_command_line_async()
[17:12] <awe_> whereas as send_to is invoked via GnomeBluetooth.send_to_address()
[17:12] <seb128> is that an issue?
[17:12] <awe_> that's what threw me
[17:12] <awe_> I was just trying to confirm that these were both supported
[17:12] <awe_> also, they may need to be re-implemented for touch
[17:12] <BenC> cjwatson: where do I update the initrd on the server ISOs so I can include an IDE driver in it (for QEmu)?
[17:13] <awe_> seb128, just trying to ensure we have all of our work items in line for BT UI
[17:13] <seb128> awe_, yeah, I'm sure tweaks will be needed
[17:13] <seb128> awe_, I doubt we will want to keep the gtk wizard on touch anyway
[17:13] <seb128> so those parts will need to be reimplemented
[17:13] <awe_> right, and same for send-to
[17:13] <awe_> however neither of those are being tracked atm
[17:14] <cjwatson> BenC: those initramfses are built by debian-installer, but the change you probably actually need to make is to add the module to one of the udebs generated by the linux-ppc source package
[17:14] <awe_> maybe I'll add pending TODO items in the BT spec, and we can move them if needed
[17:14] <awe_> s/maybe//
[17:14] <seb128> awe_, yes, please do
[17:14] <awe_> k
[17:14] <awe_> thanks
[17:14] <seb128> awe_, yw, thanks for looking into those details
[17:14] <BenC> cjwatson: I suspect it is, but I need it to be in the initrd else it can't find the cdrom
[17:14] <awe_> seb128, np
[17:15] <seb128> awe_, we probably need to add "port the indicator to the new libindicator api/gmenumodel" as well
[17:15] <seb128> that one was not available so robert_ancell did the work using the current apis
[17:15] <awe_> larsgk, already has that covered
[17:15] <cjwatson> BenC: debian-installer already includes pata-modules in the cdrom initrd for powerpc
[17:15] <seb128> awe_, larsu you mean? ;-)
[17:15] <cjwatson> BenC: so just add it to pata-modules and it'll be picked up at the next debian-installer rebuild (which are frequent)
[17:15] <awe_> oops, yea
[17:15] <seb128> awe_, good
[17:16] <BenC> cjwatson: Ah, ok, thanks
[17:16] <roaksoax> slangasek: howdy!! where you able to review MAAS (maas, maas-provision)?
[17:38] <seb128> gema_, hey again, do you know if that utah issue is likely to be fixed today at this point? still blocking unity...
[17:44] <seb128> hum
[17:44] <seb128> so we didn't have any langpack update this cycle
[17:44] <seb128> is anyone looking at this? I would usually ping dpm but he's on holidays this week
[17:49] <pitti> for the record, we need Launchpad translation exports
[17:50] <seb128> pitti, is that purely launchpad issue? do you know if there is a ticket?
[17:50] <pitti> no, I don't
[17:50] <pitti> TBH I didn't deal with translations much this cycle, except asking dpm for exports a month ago or os
[17:50] <pitti> "so"
[17:52] <seb128> pitti, ok, thanks, trying to ping on the launchpad side (dpm is out, will have to wait next week otherwise)
[17:53] <xnox> seb128: speaking of which, it was in my todo to run the archive export & update app-install-data, let me start that now.
[17:54] <seb128> xnox, thanks, don't forget to fix geonames' db as well :p
[17:54]  * seb128 hides from xnox
[17:55] <slangasek> roaksoax: sorry, I failed at it on Friday - but I'm looking now
[17:55]  * xnox ponders how strange is it to look up instructions on how to do stuff...... in my own sent mail folder.
[18:09] <seb128> gema_, ?
[18:17] <lunitik> I noticed in Raring that gksu is no longer used to authenticate in the GUI, what is used instead?
[18:19] <seb128> pkexec in most places
[18:20] <lunitik> seb128: Makes sense, actually, thank you... and also thanks for all your great work still with Ubuntu/Gnome  :)
[18:21] <seb128> lunitik, yw, thanks for the nice comment ;-)
[18:27] <slangasek> roaksoax: this doesn't look right: +Pre-Depends: ${misc:Pre-Depends}, ${misc:Depends}
[18:27] <slangasek> roaksoax: pretty sure you want ${misc:Depends} in the Depends field
[18:38] <roaksoax> slangasek: ok cool. I'll update that
[18:42] <gema_> seb128: you need to talk to nuclearbob or doanac`
[18:42] <gema_> nuclearbob: ^^
[18:42] <seb128> gema_, k, I though you were tracking the issue/making sure things don't get stalled in your team
[18:42] <seb128> which they seem to be...
[18:43] <gema_> seb128: they are working on it, and they are in US time, I have all the confidence they are doing their best
[18:43] <gema_> seb128: I will have an email tomorrow morning with status whenever I get to work
[18:43] <seb128> gema_, thanks
[18:43] <nuclearbob> gema, seb128, are we still talking about the install issue?
[18:43] <seb128> yes
[18:43] <seb128> that's blocking unity tests for several days
[18:44] <seb128> so it's blocking any update to land as well
[18:44] <nuclearbob> an environment variable in jenkins changed, and we don't know why.  We've configured utah to ignore that environment variable while we figure out why it changed, and our tests are now working
[18:44] <nuclearbob> our attempt to rerun the autopilot tests seemed to work as well
[18:44] <seb128> oh ok, would have been good to update the bug saying that
[18:45] <doanac`> seb128: we just figured this out over lunch
[18:45] <nuclearbob> seb128: sorry abou tthat, good point.  I was hoping to have a more definitive answer than "something went wrong and we don't know why" but I'll post info about the workaround
[18:45] <doanac`> still can't say why jenkins has changed
[18:45] <seb128> things should be in shape enough for unity's tests to be retried on jenkins then?
[18:45] <slangasek> roaksoax: not SRU-critical, since misc:Depends is empty in this case
[18:46] <doanac`> seb128: yes.
[18:46] <seb128> doanac`, thanks, we are giving a retry to unity's stack
[18:46] <roaksoax> slangasek: ack!
[18:47] <doanac`> seb128: we've run this successfully as a test: http://<IP_ADDRESS>:8080/view/autopilot/job/ps-unity-autopilot-release-testing/122/
[18:47] <doanac`> nuclearbob: to double-check - we do still have the conf.d fix deployed, correct?
[18:47] <nuclearbob> doanac: correct
[18:47] <seb128> doanac`, ok, great, cyphermox is going to give a retry to http://<IP_ADDRESS>:8080/job/ps-unity-autopilot-release-testing/
[18:48] <seb128> oh, seems there is one running
[18:48] <seb128> cyphermox, ^
[18:49] <cyphermox> yup, just noticed
[18:54] <nuclearbob> cyphermox seb128: the job was started while we were testing the current deployed workaround, and thus not affected by the workaround.  I'm retrying it now that the workaround is in place
[18:54] <seb128> ok, thanks
[18:55] <slangasek> roaksoax: checking my IRC logs, I see that I wrote: however, looking at the package that's in raring, the /other/ Conflicts (on maas (<= ...) and maas-region-controller (<= ...)) should almost certainly be Breaks rather than Conflicts, since they're paired with Replaces
[18:55] <slangasek> roaksoax: I think this definitely should be fixed for the SRU, maas-region-controller shouldn't Conflicts: the old version of maas
[18:56] <slangasek> roaksoax: even if it doesn't cause any known issues, it's the wrong package relationship to use
[18:57] <roaksoax> slangasek: ok. I'll fix that and re-upload
[18:58] <cjwatson> It will at least cause suboptimal upgrade ordering
[18:58] <cjwatson> Which can turn into total upgrade failure when you least expect it, so indeed best to avoid
[18:58] <slangasek> roaksoax: ok.  The same applies to the Conflicts added on the python-maas-provisioningserver package; anywhere that you use Replaces: $pkg (<= $ver) + Conflicts: $pkg (<= $ver), you should be using Breaks instead of Conflicts
[18:58] <slangasek> and python-maas-client
[18:58] <slangasek> ... etc
[18:58] <cjwatson> You should probably also be using << first-version-with-new-layout rather than <= last-version-with-old-layout
[18:59] <cjwatson> It's friendlier to anyone producing modified versions of your packages
[19:03] <roaksoax> slangasek: yeah i'll update all of those
[19:03] <slangasek> roaksoax: not relevant to the SRU, but "BSD" and "MIT" in debian/copyright are both ambiguous; per http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/, these should be listed as BSD-3-clause and Expat
[19:03] <cjwatson> gema_: I have some fine-details-of-jenkins questions regarding better integration of smoke testing with cdimage, but it's probably a bit complex for IRC; whom would it be best for me to mail?
[19:08] <roaksoax> slangasek: thanks for the review! I'll address all of these and upload a new package.
[19:19] <slangasek> roaksoax: is there an authoritative Vcs branch for the maas package?  It's not listed in debian/control; I see a number of things in the maintainer scripts that I think should be cleaned up but shouldn't block the SRU, so I'd rather raise a MP
[19:21] <roaksoax> slangasek: there's various branches. Raring has its own, quantal has its own, and precise has its own (which is basically quantal + precise specific changes)
[19:21] <slangasek> roaksoax: well, the raring one is where I would start :)
[19:21] <slangasek> roaksoax: where would I find it?
[19:22] <roaksoax> slangasek: lp:~maas-maintainers/maas/packaging, lp:~maas-maintainers/maas/packaging.quantal, lp:~maas-maintainers/maas/packaging.precise.sru
[19:23] <slangasek> roaksoax: ta
[19:50] <roaksoax> slangasek: could you please rebase your MP? There was another branch that needed to land first, which will conflict with debian/changelog
[19:50] <slangasek> roaksoax: you guys don't fix changelog conflicts on the merge side?
[19:50] <slangasek> I can fix it up, sure
[19:52] <roaksoax> slangasek: no i don't think so, since its the bot that actually lands the MP's
[19:52] <slangasek> ah
[19:53] <slangasek> roaksoax: done
[19:53] <roaksoax> slangasek: awesome thanks!!
[19:59] <slangasek> roaksoax: whoops, just spotted a typo in the branc
[19:59] <slangasek> h
[20:00] <roaksoax> slangasek: hehe no worries, it wasn't landed :)
[20:00] <slangasek> roaksoax: fixed and repushed
[20:27] <stgraber> xnox: I just updated https://wiki.ubuntu.com/ImageBasedUpgrades/Mobile to include what I discussed with lool last week. I'll likely be doing a few more edits soon but it at least better covers the current state of things.
[20:46] <ogra_> stgraber, geez, that became a gigantic wikipage over time
[20:47] <stgraber> ogra_: could have been worse, I removed a few paragraphs in the update I did earlier today (and added a bunch more obviously ;))
[20:48] <ogra_> well, it reflects the complexity of the task :)
[21:52] <bdrung_> if raring is support for 9 month, raring will eol before quantal. how to upgrade from quantal once raring is eol? will upgrading directly from quantal to raring+1 supported?
[21:55] <cjwatson> bdrung_: yes, that will be a necessity
[21:55] <cjwatson> (and is a good idea anyway!)
[21:56] <cjwatson> the whole business of not supporting direct upgrades from N+1 to N+3/N+4 while expecting to be able to support direct upgrades from N to N+4 was always total madness
[21:56] <cjwatson> we only did it that way in the beginning because we didn't have anything resembling an upgrade autotest setup and so it was too hard to QA
[21:57] <cjwatson> but times have changed and supporting more flexible combinations will make it *easier* to get LTS-to-LTS upgrades working reliably in a timely fashion
[21:58] <bdrung_> cjwatson: thanks. upgrades beyond LTS are not intended, are they?
[21:58] <ScottK> No.
[21:58] <bdmurray> xnox: is there any progress on bug 915626?
[21:59] <cjwatson> I don't think it's necessary to go that far, and it may not be practical due to Debian tending to drop support for upgrades beyond single Debian releases in at least some cases
[21:59] <cjwatson> (lots of maintainers do keep support for longer, but you only need one complex thing not to be supported and it can become a real tangle)
[22:00] <bdrung_> i am asking because it affects if transitional package can be dropped after a LTS
[22:01] <ScottK> Fortunately you've got a while before you need to worry about that.
[22:01] <seb128> I think having the LTS as "forced upgrade point" makes sense
[22:02] <ScottK> Agreed.
[22:05] <cjwatson> Yep.  I think we have fairly widespread agreement on that.
[22:05] <cjwatson> I don't object to developers keeping upgrade support for longer, of course, but it seems a step too far to demand it
[22:06] <cjwatson> Skip-upgrades in Debian are reportedly not awful if you know what you're doing, but come with roadblocks.
[22:07] <geofft> I skip-upgraded my desktop from Natty to Quantal via apt-get a few months ago. I was slightly surprised it worked.
[22:08] <geofft> But I haven't had any trouble with it.
[22:08] <geofft> So I guess that's a testament to good packaging quality in everything!
[22:09] <seb128> well, the issue is not so much quality than "how long to carry packaging tweaks to support upgrades"
[22:09] <seb128> we usually tend to drop delta after a lts, especially if Debian already dropped it and we carry that in an ubuntu specific way
[22:24] <cjwatson> Yeah, lots of those tweaks make upgrades easier / more automatic but their removal doesn't make it impossible
[22:24] <cjwatson> Hence things like geofft's experience
[22:25] <geofft> I think I had to do a bit of dependency-fighting, but it mostly just worked out.
[22:25] <geofft> I wouldn't recommend it to someone not literate in reading other people's packages, though. :)
[23:22] <robert_ancell> Laney, could you have a look at bug 1157475? Basically the same request as the Shotwell FFE
[23:48] <xnox> bdmurray: nope. I gave up on it, and later slangasek said that bindings potentially generate it unfortunately for us when we didn't ask them to do so. A bit of a rabbit hole.
[23:49] <xnox> stgraber: awesome, I'll go through that tomorrow.
[23:51] <slangasek> xnox: "generate it when we didn't ask them to" - the segfault?
[23:52] <xnox> yes.
[23:52] <slangasek> ok
[23:52] <xnox> slangasek: how would you say that sentence?
[23:52] <slangasek> was not sure under what circumstances we would ask a program to generate a segfault ;)
[23:52] <slangasek> xnox: it's a perfectly good sentence ;)
[23:54] <slangasek> roaksoax: fwiw I'm concerned about maas-region-controller.config; I have no idea what the set_question() function is meant to do, but I'm reasonably certain that the second if [] block does not work as intended
[23:55] <slangasek> roaksoax: $RET is only set by db_get or db_metaget; you're not calling either of those here, so "$RET" != false


[05:33] <mup> PR snapcraft#1760 opened: tests: move the catkin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1760>
[06:06] <mborzecki> good morning
[06:55] <mborzecki> it's not possible to REBOOT in prepare in spread?
[06:56] <zyga-ubuntu> good morning
[06:56] <mborzecki> zyga-ubuntu: hey
[06:56] <zyga-ubuntu> I'm not working today, just doing some tax follow up
[06:57] <zyga-ubuntu> REBOOT is defined in spread as a bit of shell, I haven't tried it in prepare
[06:57] <mborzecki> i'm trying to upgrade arch in prepare && REBOOT, but got REBOOT: command not found instead
[06:58] <zyga-ubuntu> mborzecki: then it probably isnt
[06:58] <zyga-ubuntu> look at spread source code, it probably does something in sync with the host
[06:59] <mborzecki> zyga-ubuntu: thanks
[07:38] <mborzecki> omg i know, it's the refactor :) sorry zyga-ubuntu
[07:55] <kalikiana> o/
[08:12] <zyga-ubuntu> mvo: do you know what might make snapd-notify and the classic-ubuntu-core-transition both fail
[08:12] <zyga-ubuntu> mvo: on my system snapd-notify fails reliably
[08:20] <niemeyer> Morning all
[08:24] <mvo> hey zyga-ubuntu
[08:25] <mvo> zyga-ubuntu: I'm not sure why this fails, can you pastebin the error
[08:25] <mvo> hey niemeyer ! good morning
[08:26] <pstolowski> morning!
[08:27] <mup> PR snapd#4290 closed: snapstate: move autorefresh code into autoRefresh helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4290>
[08:28] <niemeyer> Yos
[08:29] <niemeyer> I could swear it was Thursday.. I lost a day this week
[08:30] <zyga> mvo: http://pastebin.ubuntu.com/26032995/
[08:32] <mborzecki> niemeyer: morning
[08:32] <mborzecki> you're up early
[08:32] <mvo> zyga: hm, strange. can you get into a debug shell?
[08:33] <zyga-ubuntu> I'm in one
[08:33] <mvo> zyga-ubuntu: xcould you please pastebin "journalctl -u snapd"
[08:33] <mvo> zyga-ubuntu: is this a regular ubuntu system?
[08:33] <zyga-ubuntu> mvo: yes, 16.04
[08:33] <zyga-ubuntu> mvo: the pastebin above has the entire journal, there's nothing more
[08:34] <mvo> zyga-ubuntu: aha, no SNAPD_DEBUG=1 maybe?
[08:34] <zyga-ubuntu> no, but I can add that and re-run
[08:35] <mvo> zyga-ubuntu: that is the culprit, the message is only printed on debug
[08:35] <mvo> zyga-ubuntu: probably the smae for the other test
[08:40] <zyga-ubuntu> hmm, how to inject snapd debug
[08:40] <mborzecki> /etc/environment ?
[08:40] <mborzecki> or whatever you use in ubuntu
[08:41] <zyga-ubuntu> right but in this test we just look at syslog
[08:41] <zyga-ubuntu> and I don't want to inject it everywhere
[08:41]  * ikey just kills snapd and manually invokes it these days
[08:41] <ikey>  sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 SNAP_CONFINE_DEBUG=1 /usr/lib64/snapd/snapd   does the job for me
[08:41] <mvo> zyga-ubuntu: you could add a file to /etc/systemd/system/snapd.service.d/debug.conf or something
[08:42] <mvo> zyga-ubuntu: just for this test, the restart. but why do you not want global debug enabled? its often very useful when inspecting why tests fail, no?
[08:42] <Guest13703> hello all will my dell edge gateway support any sim
[08:43]  * ikey blinks
[08:43] <zyga-ubuntu> yeah, actualy
[08:44] <mborzecki> zyga-ubuntu: btw. weren't you supposed to be taking a day off today? :)
[08:45] <zyga-ubuntu> yes, just waiting for the traffic to go away :)
[08:45] <zyga-ubuntu> I was eating breakfast and doing some taxes
[08:45] <ikey> man knows how to start the day
[08:45] <ikey> xD
[08:45] <zyga-ubuntu> but you know, that debug machine is so tempting
[08:45]  * mvo hugs zyga-ubuntu
[08:46] <mvo>  /nick zyga-ubuntu -> zyga-debugger
[08:46]  * ikey gets back to staring at prime numbers with contempt
[08:59] <mup> PR snapd#4252 closed: store: fix download caching and add integration test <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4252>
[09:00] <mborzecki> uhh i have a feeling that linode boots arch images with their kernel regarless of what's int the image
[09:08] <mup> PR snapd#4259 closed: snapd: fix handling of undo in the taskrunner <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4259>
[09:11] <mvo> hey pedronis, good morning. I'm just looking at 4292 and wonder if you think the right behavior is that the UserID is whoever installed it (and we keep it to that user) or whoever "touched it last"?
[09:14] <pedronis> mvo: the latter has a better chance of making sure we are using workin creds, the former feels nice
[09:16] <pedronis> another approach is to use for refresh the creds of the installer, not the refresher, which then would make no difference
[09:16] <mvo> pedronis: yeah, I currently went with the former but I'm sitting on the fence
[09:16] <pedronis> I mean doing that even if the refresh is manual
[09:16] <mvo> pedronis: oh, interessting
[09:17] <pedronis> we would still take the refresher though if UserID is currently 0
[09:17] <mvo> right
[09:18] <mvo> pedronis: I think that sounds good, so it would be a) keep userID of installer b) on refresh, take userID from snapstate (regardless of who refreshes)?
[09:18] <pedronis> yes, except if UserID is currently 0
[09:19] <pedronis> so that we have a way out of the current situation
[09:19] <mvo> pedronis: indeed, I like that
[09:20] <pedronis> in practice for a system with one user it should create too many confusing situations
[09:20] <pedronis> *it shouldn't
[09:20] <mvo> pedronis: :)
[09:20] <mvo> pedronis: yeah, I will go with this, I update the PR with the snapstate recording and then will look into configure task handlign first, then into auto-refresh with auth
[09:21] <mvo> pedronis: thanks (as always) for your input!
[09:21] <pedronis> np
[09:24] <pedronis> mvo: btw given  that we are working in this area, it might make sense to capture somehow that a snap is paid (like we capture it's private atm)
[09:31] <zyga-ubuntu> mvo: so, I actuall _had_ SNAPD_DEBUG=1 set, that's what local.conf does
[09:31] <zyga-ubuntu> mvo: yet the logs are exactly the same as before
[09:32] <zyga-ubuntu> anyway, that's for next week
[09:32] <zyga-ubuntu> ttyl
[09:36] <Guest13703> hi can i use any sim module in ubuntu
[09:36] <Guest13703> And where can i get the settings
[09:37] <Guest13703> I am trying to install it on dell edge gateway
[09:42] <mborzecki> mvo: are we particularly tied to calling adduser in osutil/user.go?
[09:44] <mvo> mborzecki: I think not, what do you need to use for arch?
[09:44] <mborzecki> useradd ..
[09:44] <mvo> ok
[09:44] <ikey> think i broke snap
[09:44] <mvo> mborzecki: i think thats fine, however please note that the user adding stuff is mostly for core systems
[09:45] <mvo> mborzecki: which are ubuntu currently so it should not be urgent to change this (or do you have a different use case?)
[09:45] <mborzecki> mvo: great point, i'll disable the test then :)
[09:45] <ikey> https://hastebin.com/xibuyorobu.pl <- even after unsetting them all as reviewable i cant make the newest one reviewable..
[09:45] <ikey> on the plus side my snapcraft segfault is gone
[09:46] <ikey> `Ready to release!
[09:46] <ikey> Revision 7 of 'linux-steam-integration' created.
[09:46] <ikey> `
[09:46] <mborzecki> mvo: btw. the unit tests are only ran on debian and ubuntu, is this intentional?
[09:46] <mvo> ikey: autsch, sorry for that, that probably needs jdstrand but he is iirc not around today
[09:46] <ikey> yeah no worries
[09:46] <mvo> mborzecki: not intentional, I vaguely remember I enabled them everywhere at some point :/
[09:46] <ikey> just managed to make the dashboard fart so i thought id headsup y'all
[09:47] <mvo> ikey: maybe the store people can help
[09:47] <ikey> ta
[09:48] <ikey> hm, found some missing libs with abireport
[09:48] <ikey> *fixes*
[09:54] <ikey> niemeyer, this is what i meant about the abireport stuff btw, highlighted missing libraries from the root: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs
[09:54]  * ikey is fixing ^^
[09:54] <ikey> and the abi_symbols file is 5.23MB :p
[09:54] <mvo> ikey: hm, I don't see anything in the review queue, so it does look like somehting in the store is wonky, nessita can probably help with your https://hastebin.com/xibuyorobu.pl store issue, but she is in a .ar timezone
[09:55] <ikey> ok - gonna get another image uploaded first before i chase it further tbh
[09:55] <ikey> stabilise the ABI
[10:09] <niemeyer> ikey: Nice, that's exactly what we need I think
[10:10] <niemeyer> ikey: For the base-reviewing tasks
[10:10] <ikey> yeah
[10:10] <niemeyer> ikey: Probably also binaries that were removed, for similar reasons
[10:10] <ikey> warning 5MB: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_symbols
[10:10] <ikey> yeah ive just done the same, and ripped some systemd binaries out of the rootfs
[10:11] <ikey> it doesnt do c++filt mutations - they wouldn't let you know that ABI changed
[10:11] <ikey> just API really
[10:11] <ikey> besides nobody really cares *what* the symbols are as such, just that "oh crap I lost 4000 symbols on this change"
[10:12] <niemeyer> ikey: Right, spot on
[10:13] <ikey> fwiw we do this at the packaging level too, its great for an early warning that somethings amiss or pain is due ^^
[10:59] <jamesh> ikey: if you want more certainty about ABI changes, check out Abigail: https://sourceware.org/libabigail/
[10:59] <ikey> seen it, overkill :D
[10:59] <ikey> tis why i built abireport in the first place
[10:59] <ikey> its a high level overview basically
[10:59] <ikey> https://github.com/clearlinux/abireport
[11:00] <ikey> we can quickly track changes like so: https://dev.solus-project.com/R545:81e86e35ad503ce3df7387a3b9b6f17671a06b1a
[11:00] <ikey> all part of the build process
[11:00] <jamesh> on a previous project we used abi-compliance-checker, but it is slow and hard to configure
[11:01] <jamesh> ikey: there's so many ABI changes that won't show up in the symbol table though
[11:01] <ikey> sure - but it requires being a sensible distro dev
[11:01] <ikey> the vast majority of ABI-you-should-care-about will show up
[11:02] <ikey> sonames, linker versions and actual symbols
[11:02] <ikey> its more similar to nm -g --dynamic --defined-only
[11:02] <ikey> saved my backside more times than i care to count
[11:03] <ikey> the abi_used_libs{,32} files come from DT_NEEDED cruft
[11:03] <ikey> as solus forces -as-needed at the toolchain level (via binutils)
[11:03] <ikey> i.e. not via cflags
[11:03] <jamesh> so does Ubuntu, IIRC
[11:03] <ikey> ah handy
[11:04] <ikey> it causes some problems for janky build systems that have link order incorrect
[11:04] <ikey> but we can unset LD_AS_NEEDED in environment to workaround it
[11:04] <ikey> btw nice work on the startup times for desktop snaps :D
[11:04] <jamesh> well, the package build infrastructure.  It doesn't change the behaviour of the tools you install on Ubuntu
[11:04] <ikey> right, our build  stuff (ypkg) sets LD_AS_NEEDED in the environment
[11:04] <ikey> which triggers the change in binutils to force the behaviour
[11:05] <ikey> default user environment doesnt trigger it
[11:05] <ikey> so in the package.yml we'd just do: unset LD_AS_NEEDED
[11:06] <ikey> example: https://github.com/solus-project/runtime-snaps/blob/master/support_packages/mesa/package.yml#L48
[11:08] <mborzecki> pstolowski: thanks for the review :)
[11:16] <mup> PR snapd#4293 opened: snapstate: store if a snap is a payed snap in the sideinfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4293>
[11:18] <ikey> surely we mean Paid?
[11:18] <ikey> >_>
[11:22] <Chipaca> ikey: yes
[11:23] <Chipaca> ikey: English is hard
[11:23] <ikey> cool - i just didnt know if i was misreading :p
[11:24] <Chipaca> ikey: maybe it's a typo and we're working on snaps reaching plaid speed
[11:25] <ikey> aha
[11:25] <pedronis> mvo: thanks, I can pick up that PR after lunch, there's also a couple of places in store that can use that flag I think
[11:26] <pstolowski> mborzecki, np, still reviewing
[11:27] <mborzecki> any idea what might be the reason for 'stateengine.go:98: state ensure error: devicemgr: cannot find account (testrootorg)' ?
[11:31]  * sergiusens waves good morning
[11:49] <mvo> pedronis: sounds good, thank you
[11:49] <mvo> mborzecki: this error indicates the testrootorg account was not added in some test. where do you see that?
[11:50] <mborzecki> mvo: when running linode:arch-2017.07.01:tests/main/classic-custom-device-reg
[11:51] <mvo> mborzecki: is this snapd compiled with the "testkeys" option?
[11:52] <mvo> mborzecki: build tag for go is: "withtestkeys"
[11:53] <mborzecki> hmm that would explain it, the package is built without any additional tags passed to go
[11:53] <mvo> mborzecki: yeah, but I think you still found a bug :)
[11:53] <mvo> mborzecki: usually we ahve a if [ trusted keys ] guard for tests that need it
[11:54] <mborzecki> can't tell, i'm randomly jumping around asserts/database.go and overlord/assertstate :)
[11:55] <mvo> mborzecki: it seems like our code could be smarter that sets TRUST_TEST_KEYS
[11:55] <mvo> mborzecki: anyway, the error itself should go away if you build it with this flag
[11:55] <nessita> mvo, ikey checking
[11:55] <mborzecki> mvo: i think it's on me, the package that's built for arch does not have this tag set
[11:55] <mvo> mborzecki: (obviously this is only for testing)
[11:55] <mborzecki> i see now that the rpm built during tests sets this
[11:55] <ikey> checking what on the who now
[11:56] <mvo> mborzecki: cool, good luck
[11:56] <ikey> *squirrel*
[12:02] <nessita> mvo, ikey I moved revision 6 to manual review and then as reviewer I ran the automated checks agains, there is one failure
[12:02] <nessita> "
[12:02] <nessita> (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag
[12:02] <nessita> "
[12:03] <ikey> yeah that one i know about :D
[12:03] <Chipaca> ikey: mborzecki: fyi the static checks caught the payed vs paid thing
[12:03] <nessita> the revision 7 review should start soon
[12:03] <ikey> i wouldnt bother nessita honestly
[12:03] <pedronis> Chipaca: I'm taking up that PR
[12:03] <ikey> im building revision 8
[12:03] <ikey> to fix one last issue with the runtime
[12:03] <ikey> then that'll be my final runtime for jdstrand to sign off on
[12:03] <Chipaca> "one last issue" <- lol
[12:03] <ikey> lol
[12:03] <ikey> it was missing libkmod
[12:03] <nessita> ikey, well but until revision 7 is reviewed, revision 8 will not be -- you can reject revision 7 yourself
[12:04] <ikey> sure but none of them will pass review right now anyway :D
[12:04] <ikey> they're all base
[12:04] <ikey> autoreject
[12:04] <nessita> ikey, kk
[12:04] <ikey> thanks though - i just wanted to unclog whatever it was i busted earlier xD
[12:05] <ikey> well im also compiling mesa + glibc again so it might take a small while before this snap is done.. >_>
[12:05]  * ikey adds weekend TODO about having caching for this process
[12:49] <mborzecki> we're setting LANG=C.UTF-8 in environment for the tests, would switching to LANG=C and probably LC_ALL=C be a big issue?
[12:51] <mup> PR snapd#4294 opened: Mount with x-gdu.hide option <Created by azzar1> <https://github.com/snapcore/snapd/pull/4294>
[12:53] <mup> PR snapcraft#1761 opened: lxd: ContainerConnectionError on failed launch/ start <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1761>
[12:54] <Chipaca> mborzecki: in what distro?
[12:54] <Chipaca> afaik c.utf-8 is a debianism
[12:54] <Chipaca> althouh i think redhat picked that up as well; not sure
[12:55] <mvo> mborzecki: we mostly use C.UTF-8 to avoid python3 exploding all over the place if it is not in a utf-8 locale (at least iirc)
[12:55] <pedronis> mvo: Chipaca: I updated the paid PR
[12:55] <mvo> pedronis: \o/
[12:58] <mborzecki> hm arch
[12:58] <mborzecki> yeah, it doesn't like C.UTF-8 at all
[12:59] <ikey> C.UTF-8 is non-standard
[12:59] <mborzecki> i've added an override LC_ALL=C in the test to workaround this
[12:59] <mborzecki> this will have to do probably :)
[13:00] <ikey> failing that, en_US.utf8
[13:11] <cjwatson> while C.UTF-8 is non-standard, it might be worth generating it with localedef if it isn't there, because there's no standard way to get a UTF-8 locale and the tests probably do need one
[13:11] <mup> PR snapd#4295 opened: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4295>
[13:11] <cjwatson> I forget the exact invocation of localedef you need but it's not hard
[13:17] <Chipaca> there's an example at the end of locale(1) that'll probably get you most of the way there
[13:18] <ikey> hm snapcraft is being rather communicative
[13:18] <ogra_> it likes you !
[13:18] <ikey> https://ibin.co/3iOpZnKAHMIs.png <- is there an expectation that i have xdelta installed?
[13:19] <ogra_> if oyu want to save bandwith you want xdelta
[13:19] <ogra_> well xdelta3
[13:20] <ikey> sure but im wondering if this needs to be in the snapcraft snap
[13:20] <ikey> because there are a lot of xdeltas
[13:20] <ogra_> sounds reasonable that it ships it, yeah
[13:20] <ikey> i mean im happy to install ofc - just wondering about the intricacies of it
[13:20] <ikey> i like that i get the feedback in the terminal now
[13:21] <ikey> and i will reluctantly admit that its handy to select revisions for promotion from the cli
[13:23] <cjwatson> Chipaca: that's close to what I was thinking of, yes.  In fact the specific invocation for C.UTF-8 should be in the Debian glibc packaging
[13:23] <cjwatson> debian/rules.d/build.mk:108:        I18NPATH=$(CURDIR)/localedata GCONV_PATH=$(DEB_BUILDDIR)/iconvdata localedef --quiet -c -f UTF-8 -i C $(CURDIR)/build-tree/C.UTF-8 ; \
[13:23] <cjwatson> should be able to drop I18NPATH and GCONV_PATH from that
[13:25] <cjwatson> right, so looks like localedef --quiet -c -f UTF-8 -i C ./C.UTF-8 would work, and then point LOCPATH to that
[13:37] <mborzecki> cjwatson: thanks for the tips, that's something that could probably be applied to arch at disto level
[13:38] <cjwatson> Could just be done globally - no reason for that to be distro-specific I think
[13:38] <cjwatson> I mean, Debian-derived distros have a C.UTF-8, but you can generate another local version of it harmlessly
[13:41] <cachio> pedronis, the issue about gpg is that the dir "/root/.snap/gnupg/private-keys-v1.d" is missing
[13:41] <pedronis> cachio: mmh
[13:41] <pedronis> cachio: I need to dig, I have seen that dir sometimes, but I don't know why it's there/created
[13:41] <cachio> pedronis, I created this and the snap create-key started working
[13:42] <pedronis> it's probably a really bug
[13:42] <pedronis> *real bug
[13:42] <pedronis> not a serious one but annoying
[13:42] <cachio> pedronis, but, the first time it works
[13:43] <cachio> I execute snap-create-key test alone and it pass
[13:43] <cachio> but if I use -repeat 2 the secont execution fails
[13:44] <pedronis> mmh, no, I was confused
[13:44] <pedronis> this is from gpg itself
[13:45] <pedronis> or something else
[13:45] <pedronis> I'm confused
[13:47] <cachio> pedronis, I am gonna run again and see it this fir exists the first time
[13:48] <pedronis> cachio: there's some explanation about that dir here:  https://www.gnupg.org/faq/whats-new-in-2.1.html  , see  Removal of the secret keyring
[13:49] <pedronis> cachio: do we cleanup  ~/.snap/gnupg  between tests?
[13:51] <cachio> pedronis, I think so
[13:52] <cachio> pedronis, checking
[13:53] <pedronis> in reset_classic we do:  rm -rf /root/.snap/gnupg
[13:54] <cachio> yes
[13:57] <cprov> elopio: would you be familiar with the test failures in https://travis-ci.org/snapcore/snapcraft/jobs/306445933 ?  locally it is passing, would you know how to reproduce it in xenial ?
[14:09] <mup> PR snapd#4296 opened: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4296>
[14:12] <mup> PR snapd#4108 closed: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4108>
[14:15] <niemeyer> Lunch, biab
[14:18] <cachio> pedronis, I pushed the fix
[14:18] <cachio> pedronis, thanks for helping
[14:21] <pedronis> cachio: ah
[14:21] <sergiusens> ikey it is in the snapcraft snap (xdelta3), you just found a bug that's all :-)
[14:22] <ikey> ah gotcha
[14:23] <pedronis> cachio: wondering if we shouldn't stop/restart the agent instead ?
[14:23]  * kalikiana food
[14:27] <cachio> pedronis, testing that
[14:27] <cachio> pedronis, the change works
[14:30] <cachio> pedronis, In sid the agent is creating that dir in case it does not exist any more
[14:30] <cachio> pedronis, I supose they fixed after v 2.1.18
[14:30] <cachio> pedronis, I'll take a look to che changelog
[14:47] <cachio> niemeyer, fedora 26 passed
[14:47] <niemeyer> cachio: \o/
[14:47] <cachio> niemeyer, should I add this as manual execution?
[14:47] <niemeyer> cachio: Any reason not to do automatic, other than the extra worker?
[14:48] <cachio> niemeyer, no, just the workers needed
[14:48] <niemeyer> Son_Goku: Any ideas here?
[14:48] <cachio> niemeyer, then we will have fedora 27
[14:48] <Son_Goku> niemeyer: eh?
[14:48] <cachio> and rawhide
[14:48] <Son_Goku> ideas for what?
[14:49] <niemeyer> Son_Goku: Value of running tests on Fedora 26 at all times.. we'll be working on 27 and rawhide next
[14:49] <Son_Goku> well, 26 is a currently supported stable release for a year
[14:49] <Son_Goku> but if you'd rather only support 27 and rawhide, that's fine
[14:49] <Son_Goku> let's just not be in a position where we're stuck on an old version for too long
[14:49] <niemeyer> Son_Goku: Any stats on user base?  Do we have a significant percentage of users there still?
[14:50] <Son_Goku> no idea
[14:50] <Son_Goku> Fedora doesn't collect stats
[14:50] <niemeyer> Son_Goku: Well, I'm sure file servers have logs
[14:50] <Son_Goku> in the mirror network, probably
[14:50] <Son_Goku> but the best way to figure this out would be the store side logs
[14:51] <niemeyer> Son_Goku: Good point
[14:51] <Son_Goku> each snapd version is encoded with their package release version
[14:51] <Son_Goku> which has the .fcXX suffix encoded
[14:52] <niemeyer> cachio: Ok, I suggest enabling 27 and rawhide first, and let's talk to the store team to see if we can figure out any hints of demand
[14:52] <Son_Goku> so snapd 2.29.4 from Fedora 26 will say its version is 2.29.4-2.fc26
[14:52] <niemeyer> cachio: We can keep manual meanwhile
[14:52] <cachio> niemeyer, sure
[14:52] <niemeyer> Son_Goku: Thanks for the details
[14:52] <Son_Goku> np
[14:53] <cachio> niemeyer, I'll continue with fedora 27
[14:53] <ikey> got at least 12 solus users with snapd
[14:53] <Son_Goku> incidentally, I encode this data in the snapd version because from time to time, I do patches/backports that differ from you guys
[14:53] <Son_Goku> makes it easier to identify where a breakage might happen (if it ever does)
[14:53] <niemeyer> ikey: It's a good start! :)
[14:54] <ikey> :D
[14:54] <Son_Goku> there's *probably* more than 12 Fedora users :P
[14:54] <ikey> nah
[14:54] <ikey> never heard of it
[14:54] <ikey> >_>
[14:55] <mborzecki> Son_Goku: idk I stopped using it ~3 months ago :)
[14:55] <Son_Goku> ...
[14:55] <ikey> :O
[14:55] <ikey> niemeyer, happy: https://github.com/solus-project/runtime-snaps/blob/master/abi/abi_used_libs
[14:55] <ikey> is empty ^_^
[14:55]  * Son_Goku collapses in glum agony
[14:56] <mborzecki> yeah, got lazy at some point, didn't want to go through another upgrade and installed tumbleweed just for the lulz
[14:56] <ikey> when i move to implementing apparmor confinement (post snapd stable release and store inclusion of both edges) - then ill need to move stuff like theme assets from runtime to the lsi snap itself
[14:56] <ikey> mborzecki, they still got their sysvinit-on-top-of-systemd thing going on?
[14:57] <Son_Goku> ikey: btw, are there any changes of yours left that aren't part of snapd 2.29.4?
[14:57] <ikey> that i dont know
[14:57] <Son_Goku> I may want to cherry-pick those into Fedora snapd
[14:57] <mborzecki> maybe, can't tell, it was awkward, everything seemed broken, spent the last 3 months or so fighting with policykit as it kept asking me for root (yeah root) password to authorize any operation
[14:58] <ikey> i dont think i have pending PRs
[14:58] <Son_Goku> mborzecki: with snapd?
[14:58] <Son_Goku> on Fedora?
[14:58] <ikey> mborzecki, ah that reminds me i need to upstream my polkit patches this weekend..
[14:58] <ikey> in solus we removed JS from polkit
[14:58] <ikey> >_>
[14:58] <Son_Goku> mborzecki: I literally just fixed that last week
[14:58] <niemeyer> cachio: I'm seeing errors being reported about fedora-25 in travis
[14:58] <niemeyer> cachio: In unrelated PRs
[14:58] <niemeyer>   Status code: 502 for https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64
[14:59] <ikey> this is our polkit policy definition :P https://dev.solus-project.com/source/gvfs/browse/master/files/org.gtk.vfs.file-operations.keyrules
[14:59] <niemeyer> cachio: Known?
[14:59] <niemeyer> Son_Goku: ^
[14:59] <Son_Goku> niemeyer: that's the Linode mirror being broken
[14:59] <mborzecki> Son_Goku: if it's any consolation, my wife, who's got nothing to do with IT whatsoever is runnig the latest fedora on her laptop  and prefers it to any other distro i had installed her before
[14:59] <ikey> Son_Goku, i dont see any open PRs from me on github
[14:59] <niemeyer> Son_Goku: ;(
[15:00] <ikey> so my nvidia work is in
[15:00] <Son_Goku> I believe Linode has a mirror override for their IP block (Fedora MirrorManager lets you register private and public mirrors in that manner) and their mirror is awful
[15:00] <ikey> we might want to flesh out desktop-helpers to support the new system though?
[15:00] <Son_Goku> niemeyer: I have a similar override in place for my workplace for its local mirror
[15:00] <ikey> for vulkan + biarch nvidia..
[15:00] <Son_Goku> ikey: right
[15:01] <Son_Goku> but RADV and Intel Vulkan should work, right?
[15:01] <ikey> wait i just said 'we'
[15:01] <ikey> y'all done stockholmed me
[15:01] <Son_Goku> :P
[15:01] <ikey> Son_Goku, as long as they're present
[15:01] <ikey> and accessible in some fashion
[15:01] <ikey> f.e. solus-runtime-gaming ships a full weight mesa with the vulkan drivers
[15:01] <Son_Goku> hmm
[15:01] <ikey> and can use the "host" vulkan for nvidia support
[15:02] <ikey> but it requires the icd loader inside the snap runtime or snap itself
[15:02] <ikey> i.e. libvulkan.so.1
[15:02] <ikey> i suspect we've got some apparmor confinement nightmares to work out there
[15:02] <ikey> but lsi is a good place to debug that
[15:02] <ikey> as its a meaty runtime
[15:02] <Son_Goku> uh oh
[15:02] <Son_Goku> I fucked up
[15:02] <ikey> onoes
[15:03] <Son_Goku> oh wait
[15:03] <Son_Goku> panic averted
[15:03] <Son_Goku> snapd-selinux is there
[15:03] <ikey> yeah tell that to golang
[15:03] <ikey> >_>
[15:03] <Son_Goku> hahah
[15:03] <ikey> and now im making programming jokes
[15:03] <Son_Goku> for a minute there, I thought I might have accidentally not built it
[15:03]  * ikey is taking himself out tonight
[15:03] <ikey> like, out to a pub
[15:03] <ikey> not gonna mobhit myself as i have dinner
[15:03] <Son_Goku> haha
[15:04] <ikey> can't even begin to work out the logistics for having myself still surprised by the event *and* having meaningful last words..
[15:05] <Son_Goku> haha
[15:06] <Son_Goku> be drunk when you order your hit?
[15:07] <ikey> ah that could do it
[15:07] <ikey> so taking myself out will actually take me out
[15:07] <ikey> i do love the beauty of that
[15:07] <cachio> niemeyer, taking a look
[15:07] <mup> PR snapd#4297 opened: Adding fedora-26 image to snapd spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4297>
[15:08] <Chipaca> ikey: is that some sort of extrovert kalsarikännit?
[15:09]  * ikey googles this word
[15:09] <ikey> oh
[15:09] <ikey> hm
[15:09] <ikey> lol. i guess?
[15:09] <ikey> just.. with the pants
[15:09] <ikey> well i mean i cant make promises on that count but its the intent anyway
[15:15] <kalikiana> apparently there's even an emoji for that
[15:20] <elopio> kyrofa: hey, we can remove the shared ros demo now, right? I see we have almost the same code in snapcraft/tests/integration/snaps/catkin-shared-ros
[15:20] <elopio> the thing we are missing seems to be a test that installs and executes that snap.
[15:21] <niemeyer> cachio_lunch: Sorry, I forgot we had fedora *25* tests running automatically.. I suggest moving those to manual, and running 26 instead
[15:23] <sergiusens> kalikiana hey, did you see the bug I logged yesterday? It is quite critical to a good experience
[15:25] <kalikiana> sergiusens: You mean bug 1734145? I haven't checked it yet. But I'm going to take a look in a moment and see what's going on there
[15:25] <mup> Bug #1734145: snapcraft clean <part-name> destroys everything when using containers <Snapcraft:Triaged by kalikiana> <https://launchpad.net/bugs/1734145>
[15:25] <mborzecki> ok guys, i'm done for today, enjoy your weekend
[15:31] <zyga-ubuntu> hey guys
[15:31] <zyga-ubuntu> not working feels refreshing for a change
[15:31] <zyga-ubuntu> mid day I was no longer thinking about solving work problems
[15:32] <zyga-ubuntu> I hope you all had a fantastic day and I will happily see you next week :)
[15:33] <Son_Goku> bye :)
[15:33] <zyga-ubuntu> hey Son_Goku
[15:33] <Son_Goku> zyga-ubuntu: hey
[15:33] <zyga-ubuntu> enjoy your weekend :)
[15:33] <Son_Goku> I will!
[15:33] <Son_Goku> zyga-ubuntu: test the fedora snapd packages :)
[15:33] <zyga-ubuntu> I bought a pair of gloves today
[15:34] <zyga-ubuntu> poland is so cold so quickly
[15:34] <zyga-ubuntu> it's not even sub-zero yet
[15:34] <Son_Goku> heh
[15:34] <zyga-ubuntu> Son_Goku: ok, I recently installed F27
[15:34] <Son_Goku> it's already getting to subzero here
[15:34] <zyga-ubuntu> Son_Goku: here too but it's not like that daily and all the time (yet)
[15:34] <Son_Goku> also, if you want to have some fun, we have mir packages in Fedora 26 and 27 testing
[15:34] <Son_Goku> zyga-ubuntu: every day after 6pm, it's subzero
[15:34] <zyga-ubuntu> ok so poland is still warmer
[15:34] <zyga-ubuntu> man, I'm complaining too much :D
[15:38] <mup> PR snapd#4295 closed: tests/main/manpages: set LC_ALL=C as man may complain if the locale is unset or unsupported <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4295>
[15:40] <niemeyer> Good news: compression on spread works
[15:41] <niemeyer> Bad news: it doesn't seem to improve timing much
[15:41] <niemeyer> https://travis-ci.org/snapcore/snapd/builds/306754148
[15:41] <niemeyer> This one was run entirely with compression on with server=>client
[15:56] <sergiusens> kyrofa mind looking at my latest PR?
[15:56] <kalikiana> sergiusens: I confirmed the bug. I need to investigate why the unit test didn't fail.
[15:56] <kalikiana> elopio: maybe you could help me here find out what is wrong?
[15:57] <kalikiana> the checks *look* right...
[15:57] <elopio> kalikiana: which bug?
[15:58] <kalikiana> elopio: bug 1734145 - https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/unit/commands/test_clean.py#L178
[15:58] <mup> Bug #1734145: snapcraft clean <part-name> destroys everything when using containers <Snapcraft:In Progress by kalikiana> <https://launchpad.net/bugs/1734145>
[15:59] <kalikiana> elopio: I have an idea what's wrong with the code. But the test passing puzzles me
[16:01] <elopio> kalikiana: to check what's in the call args, just change it to assertEqual and give it a try.
[16:01] <cachio> niemeyer, sure
[16:01] <kalikiana> elopio: nothing is in the call args
[16:01] <kalikiana> elopio: which *would* mean all is fine, no bug
[16:02] <elopio> that would be a better check, instead of NotEquals, check that there are no calls.
[16:02] <kalikiana> I'm saying there are none
[16:02] <elopio> but why it is passing despite the bug, I don't know. The mock might be wrong.
[16:03] <kalikiana> oh.... I just realized why
[16:03] <kalikiana> the test doesn't set fake_lxd.status
[16:04] <kalikiana> so fake_lxd has no container which would be deleted...
[16:05] <mup> PR snapd#4298 opened: many: remove configure-snapd task again and handle internally <Created by mvo5> <https://github.com/snapcore/snapd/pull/4298>
[16:06] <mup> PR snapd#4296 closed: packaging/arch: pre-create snapd directories when packaging <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4296>
[16:08] <kalikiana> elopio: if you see the test, can you tell me what you expected it to do? without looking at the fixture source
[16:09] <mvo> pedronis: not urgent but early sniff test on 4298 would be appreciated
[16:10] <elopio> kalikiana: to check that the container was not deleted when a part is passed as an argument.
[16:16] <mup> PR snapd#4265 closed: New debian-sid-64 and debian-9-64 images for testing <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4265>
[16:19] <zyga-ubuntu> we have < 25 PRs, that's very refreshing
[16:21] <mup> PR snapd#4293 closed: snapstate,store: store if a snap is a paid snap in the sideinfo <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4293>
[16:28] <kyrofa> sergiusens, yeah, making it through a few older ones, on my way up
[16:32] <kyrofa> sergiusens, could use your thoughts on snapcraft#1746
[16:32] <mup> PR snapcraft#1746: cli: add version command <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746>
[16:32] <kalikiana> elopio: that is correct. I'm thinking if it's also clear what fake_lxd provides - without .status - 'Stopped' it doesn't do what you expect. Maybe a method like .creater_container('foo')? I think the property assignments aren't good enough
[16:32] <kalikiana> Neither of us saw that it was wrong
[16:39] <elopio> kalikiana it's clear when you call status. It's not clear when you forget it. The joy of mocks...
[16:39]  * elopio relocates
[16:39]  * zyga-ubuntu wonders why snap-run-link performs reset.sh in its prepare state?
[16:39] <zyga-ubuntu> prepare *step*
[16:40] <zyga-ubuntu> then installs core from beta
[16:40] <zyga-ubuntu> feels totally bogus
[16:40] <zyga-ubuntu> there, patched locally not to do this
[16:40] <zyga-ubuntu> let's see what's next
[16:41] <kalikiana> elopio: Yeah.... it's difficult to avoid that kind of thing...
[17:03] <mup> PR snapcraft#1762 opened: lxd: delete container only if parts is empty <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1762>
[17:04] <kalikiana> sergiusens: the tmp_dir fix is here snapcraft#1742
[17:04] <mup> PR snapcraft#1742: lxd: always remove tmp_dir after execution <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1742>
[17:10] <Son_Goku> cachio: we can probably drop fedora-25 entirely
[17:10] <Son_Goku> as it's EOL is in December
[17:10] <Son_Goku> I certainly don't plan to make new updates for Fedora 25 past 2.29.x
[17:13] <ikey> heads up, brave browser lacks japanese font support: https://dev.solus-project.com/T5080
[17:13] <ikey> we're gonna have them forward to snapcraft forum
[17:13] <ikey> fully confined snap, nothing we can do our side
[17:16] <elopio> kalikiana you could make the fake smarter. If lxc start is called, update the internal status.
[17:16] <zyga-ubuntu> ikey: you can!
[17:16] <zyga-ubuntu> ikey: we have host font support now
[17:16] <zyga-ubuntu> ikey: fonts from /usr/share/fonts are ahred
[17:16] <zyga-ubuntu> *shared
[17:16] <ikey> ah gdi
[17:16] <ikey> lol
[17:16] <ikey> literally just closed it xD
[17:16] <kalikiana> elopio: that's what it already does! the properties are only used to eg. fake an existing container
[17:17] <ikey> is this upcoming or in release?
[17:17] <ikey> and if its in git i can backport to solus snapd for this guy
[17:18] <cachio> Son_Goku, ok
[17:18] <zyga-ubuntu> ikey: I think it's released now, it's a part of one of the interfaces
[17:18] <zyga-ubuntu> ikey: I forgot, look for "fonts" in interfaces/builtin
[17:18] <zyga-ubuntu> ikey: it should just work now
[17:18] <cachio> Son_Goku, It is gonna be manual after 26 is added
[17:18] <Son_Goku> cool
[17:18] <ikey> nothing in 'snap interfaces' listing here
[17:18] <zyga-ubuntu> ikey: no no, I mean "grep the code luke"
[17:19] <ikey> oh XD
[17:19] <zyga-ubuntu> btw
[17:19] <zyga-ubuntu> do you know anything that shows network usage
[17:19] <zyga-ubuntu> akin to "time"
[17:19] <ikey> ehm not off the top of me head
[17:19] <ikey> netstat is a bit meh
[17:20] <zyga-ubuntu> I read about the new BPF based tools on LWN
[17:20] <zyga-ubuntu> I need to try those
[17:21] <ikey> vnstat but i dont think it has the granularity
[17:21] <ikey> its more system wide
[17:21] <ikey> vs this thingy is using that much
[17:21] <zyga-ubuntu> there was something that tracks TCP
[17:23] <mup> PR snapd#4297 closed: Adding fedora-26 image to snapd spread.yaml <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4297>
[17:24] <elopio> kalikiana then maybe don't fake an existing container, always set up the fake from scratch.
[17:24]  * kalikiana hopping on a tram now
[17:25] <kalikiana> elopio: I'm not sure what you mean. I am setting up the fake here
[17:27] <kalikiana> I guess we should brainstorm the fakes at some point and see if we can improve it
[17:44] <cachio> niemeyer, fedora 27 ready in the <IP_ADDRESS>
[17:49] <kyrofa> Dude, patchelf is kind of awesome
[17:51] <niemeyer> cachio: Sweet
[17:51] <niemeyer> cachio: Which spread is that?
[17:51] <niemeyer> Which machine is that, I mean
[17:54] <cachio> niemeyer, dont know which spread
[17:54] <cachio> it is the fedora-27-x86_64
[17:54] <niemeyer> cachio: I need to know the machine number..
[17:54] <niemeyer> Spread-N
[17:55] <cachio> I don'thave it
[17:56] <cachio> I just saved the ips long time ago
[17:56] <cachio> let me check in the irc logs
[17:57] <niemeyer> cachio: Your own messages say this is Spread45
[17:57] <niemeyer> cachio: Your own messages say this is Spread-45
[17:57] <niemeyer> Looking into it
[17:58] <niemeyer> cachio: ... and I'm being silly, sorry. The main machine table does list the public IP address. I just never used/noticed it there.
[17:59] <cachio> niemeyer, :)
[18:00] <Chipaca> zyga-ubuntu: i didn't understand your comment about x-snapd
[18:00] <niemeyer> I always go to the configuration tab, and it woudn't be fun to scan 80 machines for the IP address.. that's why I was asking for it
[18:00] <zyga-ubuntu> Chipaca: look at entry.go
[18:01] <zyga-ubuntu> Chipaca: there are functions there
[18:01] <Chipaca> zyga-ubuntu: yes
[18:01] <zyga-ubuntu> Chipaca: I was referring to the fact you made that const, I wonder why
[18:01] <Chipaca> zyga-ubuntu: the things i made consts aren't used as variables afaict
[18:01] <zyga-ubuntu> yeo
[18:01] <zyga-ubuntu> yep
[18:02] <zyga-ubuntu> Chipaca: anyway, that's fine :)
[18:02] <zyga-ubuntu> I was just curious
[18:02] <Chipaca> zyga-ubuntu: the reason i made the change is laziness
[18:02] <Chipaca> that's all
[18:03] <Chipaca> zyga-ubuntu: otherwise i'dd have to import sys and make uid and gid be sys.UserID(0) and sys.GroupID(0)
[18:03] <Chipaca> zyga-ubuntu: "but Chipaca", you say, "being lazy isn't a good reason for doing that"
[18:03] <Chipaca> zyga-ubuntu: and you might be right :-)
[18:04] <ikey> id say laziness makes the world go round, but ideally the world would keep itself turning and report issues to itself
[18:04] <zyga-ubuntu> haha,  no, it's fine :)
[18:04] <zyga-ubuntu> YAGNI
[18:04] <zyga-ubuntu> if I need it, I'll change it
[18:04] <Chipaca> zyga-ubuntu: TBH i was very close to just inlining the constants
[18:07] <Chipaca> ikey: with you on that
[18:07] <ikey> ^^
[18:07] <Chipaca> also: it's 1807 on a friday
[18:07] <ikey> in the US? :P
[18:07] <ikey> or we talking hours
[18:07]  * ikey runs
[18:07] <Chipaca> i'm off to bathe smelly boys and make smelly pizza
[18:07] <Chipaca> o/
[18:08] <ikey> \o
[18:08]  * ikey contemplates The Going Out
[18:08] <Chipaca> ikey: The Great Goingoutening of 2017
[18:08] <ikey> mm
[18:11] <niemeyer> cachio: You've got an image.. machine is back up in case you need it
[18:11] <cachio> niemeyer, great, I'll test it
[18:11] <niemeyer> and I'm taking a break
[18:11] <cachio> sure, in 20 minutes fedora 28 will be ready
[18:11] <niemeyer> A good weekend for those reaching their EOD
[18:13] <mup> Bug #1734213 changed: Python scripts named pip* filtered out of snaps <Snapcraft:New> <https://launchpad.net/bugs/1734213>
[18:15] <mup> PR snapcraft#1763 opened: Make the pip filtering in the Python plugin more fine-grained <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1763>
[18:28] <cachio> niemeyer, fedora 28 ready on <IP_ADDRESS>
[18:28] <cachio> fedora-rawhide-64
[18:29] <zyga-ubuntu> cachio: note that rawhide is not 28
[18:29] <zyga-ubuntu> cachio: it will stay as rawhide forever
[18:30] <zyga-ubuntu> cachio: f28 didn't branch yet
[18:31] <cachio> zyga-ubuntu, ah, ok
[18:42] <sergiusens> kyrofa elopio thanks for the reviews, question, does that failing test pass for you guys when running locally?
[18:42] <zyga-ubuntu> 30 / 166
[18:43] <zyga-ubuntu> slow but predictable progress
[18:43] <kyrofa> sergiusens, I didn't run that particular test locally, but I tested with binaries from the archive and it worked
[18:43] <kyrofa> I'll run it in a minute
[18:43] <sergiusens> kyrofa right, that is what I did; I am considering there to be an issue with the testbed
[18:44] <kyrofa> sergiusens, wonder if it's not properly changing to classic
[18:44] <sergiusens> kyrofa it works fine locally, so I assume it does
[18:45] <kyrofa> Weird. I don't know what it could be, then
[19:37] <elopio> sergiusens: I can try in an hour, after the ubuntu on air.
[19:37] <elopio> kyrofa and anybody else who wants to join: https://hangouts.google.com/hangouts/_/urbvfds645aehgjqxmbuxjpuzme
[19:43] <zyga-ubuntu> 41 tests passed and counting :)
[19:49] <sergiusens> elopio kyrofa having SNAPCRAFT_CONTAINER_BUILDS set and running the tests has very weird hidden side effects
[19:50] <elopio> zyga-ubuntu: we are doing a thing live ^ I know  you like thouse :)
[19:50] <elopio> sergiusens: oh, maybe we should clean all the env vars on setup.
[19:50] <zyga-ubuntu> elopio: I'm in my pyjama already and kind of scruffy looking
[19:51] <zyga-ubuntu> elopio: is it weekly as before
[19:51] <zyga-ubuntu> elopio: I can join next week, today I'm not in shape
[19:55] <elopio> zyga-ubuntu: it's monthly for now. You can always wear a mask
[19:56] <kyrofa> zyga-ubuntu, dang, don't join, you sound like an open-source hacker. We don't want those
[19:57] <zyga-ubuntu> kyrofa: achievement unlocked :D
[19:58] <kyrofa> :P
[19:58] <zyga-ubuntu> kyrofa: I'm in my undies, running tests, playing a game and chatting on 3 computers
[19:58] <kyrofa> You only get the achievement if you're also eating something
[19:59] <zyga-ubuntu> well
[19:59] <kyrofa> Hot pockets, preferably
[19:59] <zyga-ubuntu> unlocked :D
[19:59] <zyga-ubuntu> "serek waniliowy"
[19:59] <zyga-ubuntu> google if you want to see
[19:59] <zyga-ubuntu> but
[19:59] <zyga-ubuntu> drinking pure water out of my "rostopic pub 2016" glass
[20:14] <niemeyer> cachio: fedora-28-64 is ready
[20:21] <cachio> niemeyer, the name is fedora-rawhide-64
[20:21] <cachio> could you please rename the image?
[21:18] <elopio> relocating again...
[22:04] <sergiusens> elopio kyrofa my branch is ready for another look
[22:04] <sergiusens> elopio I would appreciate if you could look into that test failure
[22:07] <mup> PR snapcraft#1764 opened: snapcraft.yaml: use gcc to detect triplet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1764>
[22:14] <kyrofa> sergiusens, that one is pretty critical ^, and easy to review
[22:23] <sergiusens> kyrofa sure, I'll trade you ;-)
[22:23] <kyrofa> So not equivalent :P
[22:23] <kyrofa> But okay
[22:34] <kyrofa> sergiusens, question. Why did you decide on using a sitecustomize.py versus .pth files?
[22:48] <kyrofa> sergiusens, few doc suggestions left, but it looks quite nice
[22:49] <sergiusens> kyrofa I'll fix those docs
[22:50] <sergiusens> kyrofa .pth are not dynamic between part's install, stage and the actual snap
[22:50] <kyrofa> sergiusens, excellent, that's what I was hoping
[22:50] <sergiusens> kyrofa why are you asking I wonder :-)
[23:06] <Son_Goku> woo