[00:16] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kstars build #48: STILL UNSTABLE in 1 hr 8 min: https://kci.pangea.pub/job/artful_stable_kstars/48/
[00:29] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_kstars build #47: STILL UNSTABLE in 1 hr 21 min: https://kci.pangea.pub/job/zesty_stable_kstars/47/
[00:42] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_kalzium build #25: STILL UNSTABLE in 1 hr 34 min: https://kci.pangea.pub/job/zesty_stable_kalzium/25/
[01:08] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kalzium build #70: STILL UNSTABLE in 25 min: https://kci.pangea.pub/job/artful_unstable_kalzium/70/
[01:19] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_ark build #78: STILL UNSTABLE in 25 min: https://kci.pangea.pub/job/artful_unstable_ark/78/
[01:48] -kubuntu-ci:#kubuntu-devel- Project artful_stable_ark build #67: STILL UNSTABLE in 39 min: https://kci.pangea.pub/job/artful_stable_ark/67/
[01:58] <ahoneybun> clivejo: anything needs testing in artful other then ktorrent?
[01:58] <ahoneybun> acheronuk: ^
[02:14] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_dragon build #60: FAILURE in 2 min 36 sec: https://kci.pangea.pub/job/zesty_stable_dragon/60/
[02:21] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kstars build #61: STILL UNSTABLE in 33 min: https://kci.pangea.pub/job/xenial_stable_kstars/61/
[02:23] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_ark build #224: STILL UNSTABLE in 22 min: https://kci.pangea.pub/job/zesty_unstable_ark/224/
[02:24] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kalzium build #175: STILL UNSTABLE in 22 min: https://kci.pangea.pub/job/zesty_unstable_kalzium/175/
[02:32] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_elisa build #73: STILL UNSTABLE in 28 min: https://kci.pangea.pub/job/zesty_unstable_elisa/73/
[02:33] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ark build #542: STILL UNSTABLE in 18 min: https://kci.pangea.pub/job/xenial_unstable_ark/542/
[02:33] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kile build #74: STILL UNSTABLE in 20 min: https://kci.pangea.pub/job/zesty_unstable_kile/74/
[02:42] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kile build #73: STILL UNSTABLE in 23 min: https://kci.pangea.pub/job/xenial_unstable_kile/73/
[02:49] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_calligra build #172: FAILURE in 1 hr 1 min: https://kci.pangea.pub/job/xenial_unstable_calligra/172/
[02:53] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_cantor build #56: STILL UNSTABLE in 19 min: https://kci.pangea.pub/job/zesty_stable_cantor/56/
[02:56] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kalzium build #238: STILL UNSTABLE in 32 min: https://kci.pangea.pub/job/xenial_unstable_kalzium/238/
[02:59] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kmailtransport build #256: STILL FAILING in 3 min 42 sec: https://kci.pangea.pub/job/xenial_unstable_kmailtransport/256/
[02:59] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmailtransport build #65: STILL FAILING in 3 min 55 sec: https://kci.pangea.pub/job/artful_unstable_kmailtransport/65/
[03:03] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_krita build #194: FAILURE in 1 hr 1 min: https://kci.pangea.pub/job/xenial_unstable_krita/194/
[03:08] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmailtransport build #66: STILL FAILING in 3 min 43 sec: https://kci.pangea.pub/job/artful_unstable_kmailtransport/66/
[03:08] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_ksmtp build #3: FAILURE in 13 min: https://kci.pangea.pub/job/zesty_unstable_ksmtp/3/
[03:08] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kile build #69: STILL UNSTABLE in 25 min: https://kci.pangea.pub/job/artful_unstable_kile/69/
[03:09] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kmailtransport build #257: STILL FAILING in 5 min 15 sec: https://kci.pangea.pub/job/xenial_unstable_kmailtransport/257/
[03:16] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[03:16] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_dragon build #61: FIXED in 21 min: https://kci.pangea.pub/job/zesty_stable_dragon/61/
[03:17] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_krita build #218: FAILURE in 1 hr 1 min: https://kci.pangea.pub/job/zesty_unstable_krita/218/
[03:19] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_cantor build #336: STILL UNSTABLE in 23 min: https://kci.pangea.pub/job/xenial_unstable_cantor/336/
[03:19] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ksmtp build #4: FAILURE in 24 min: https://kci.pangea.pub/job/xenial_unstable_ksmtp/4/
[03:19] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_ksmtp build #4: FAILURE in 24 min: https://kci.pangea.pub/job/artful_unstable_ksmtp/4/
[03:23] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kmailtransport build #202: FAILURE in 3 min 46 sec: https://kci.pangea.pub/job/zesty_unstable_kmailtransport/202/
[03:28] <ahoneybun> cyphermox: how was your vacation?
[03:31] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kmailtransport build #203: STILL FAILING in 2 min 39 sec: https://kci.pangea.pub/job/zesty_unstable_kmailtransport/203/
[03:31] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_ksmtp build #4: STILL FAILING in 17 min: https://kci.pangea.pub/job/zesty_unstable_ksmtp/4/
[03:31] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kaddressbook build #57: FAILURE in 30 sec: https://kci.pangea.pub/job/xenial_stable_kaddressbook/57/
[03:42] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_ksmtp build #5: STILL FAILING in 17 min: https://kci.pangea.pub/job/artful_unstable_ksmtp/5/
[03:42] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ksmtp build #5: STILL FAILING in 17 min: https://kci.pangea.pub/job/xenial_unstable_ksmtp/5/
[03:51] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[03:51] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kaddressbook build #58: FIXED in 14 min: https://kci.pangea.pub/job/xenial_stable_kaddressbook/58/
[03:56] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #53: FAILURE in 5 min 54 sec: https://kci.pangea.pub/job/artful_stable_kmail/53/
[03:57] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_calligra build #173: STILL FAILING in 1 hr 1 min: https://kci.pangea.pub/job/xenial_unstable_calligra/173/
[04:08] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #54: STILL FAILING in 7 min 1 sec: https://kci.pangea.pub/job/artful_stable_kmail/54/
[04:28] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #100: FAILURE in 6 min 1 sec: https://kci.pangea.pub/job/artful_unstable_kmail/100/
[04:31] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[04:31] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_krita build #219: FIXED in 1 hr 9 min: https://kci.pangea.pub/job/zesty_unstable_krita/219/
[04:31] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[04:31] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_krita build #195: FIXED in 1 hr 22 min: https://kci.pangea.pub/job/xenial_unstable_krita/195/
[04:38] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #101: STILL FAILING in 5 min 45 sec: https://kci.pangea.pub/job/artful_unstable_kmail/101/
[04:43] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_calligra build #16: FAILURE in 1 hr 1 min: https://kci.pangea.pub/job/zesty_stable_calligra/16/
[05:49] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_calligra build #17: STILL FAILING in 1 hr 1 min: https://kci.pangea.pub/job/zesty_stable_calligra/17/
 https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1706859
 https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1706861
[06:36] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_phonon build #61: STILL UNSTABLE in 21 min: https://kci.pangea.pub/job/artful_unstable_phonon/61/
[07:26] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kparts build #155: FAILURE in 15 min: https://kci.pangea.pub/job/zesty_unstable_kparts/155/
[07:27] <doko> hi, please could somebody look at https://launchpad.net/ubuntu/+source/perlkde/4:4.14.2-0ubuntu5 ?
[07:28] <doko> perlkde is not in Debian, and wasn't updated from upstream (there seems to be one newer release in 2013). or should the package just be removed?
[07:40] <acheronuk> doko: looking....
[07:40] <doko> acheronuk: or fix the test failure =)
[07:44] <acheronuk> doko: perlkde and  smokekde are on a list I made some time ago of things I thought were safe to remove
[07:44] <doko> acheronuk: could you file a bug report for that and subscribe ubuntu-archive?
[07:45] <acheronuk> doko: yep. will do that a little later once I'm done with some iso testing
[07:45] <doko> ta
[07:47] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kparts build #156: STILL FAILING in 15 min: https://kci.pangea.pub/job/zesty_unstable_kparts/156/
[08:05] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #55: STILL FAILING in 7 min 31 sec: https://kci.pangea.pub/job/artful_stable_kmail/55/
[08:17] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #56: STILL FAILING in 6 min 28 sec: https://kci.pangea.pub/job/artful_stable_kmail/56/
[08:23] <acheronuk> doko: bug #1706878
[08:32] <doko> acheronuk: thanks, removed
[09:20] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #102: STILL FAILING in 5 min 52 sec: https://kci.pangea.pub/job/artful_unstable_kmail/102/
[09:30] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #103: ABORTED in 5 min 10 sec: https://kci.pangea.pub/job/artful_unstable_kmail/103/
[09:50] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kparts build #377: FAILURE in 20 min: https://kci.pangea.pub/job/xenial_unstable_kparts/377/
[09:50] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kparts build #27: FAILURE in 19 min: https://kci.pangea.pub/job/artful_unstable_kparts/27/
[10:08] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kparts build #378: STILL FAILING in 12 min: https://kci.pangea.pub/job/xenial_unstable_kparts/378/
[10:08] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kparts build #28: STILL FAILING in 12 min: https://kci.pangea.pub/job/artful_unstable_kparts/28/
[10:09] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1671: SUCCESS in 1 min 1 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1671/
[10:09] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1671: SUCCESS in 1 min 9 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1671/
[10:12] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1671: SUCCESS in 3 min 46 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1671/
[10:12] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-02 build #1671: SUCCESS in 4 min 11 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-02/1671/
[10:17] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmailtransport build #67: STILL FAILING in 4 min 45 sec: https://kci.pangea.pub/job/artful_unstable_kmailtransport/67/
[10:25] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmailtransport build #68: STILL FAILING in 2 min 34 sec: https://kci.pangea.pub/job/artful_unstable_kmailtransport/68/
[10:31] <acheronuk> santa_: ping
[10:32] <acheronuk> had at least one build fail in KCI apps due to new cmake 3.9 landing. you think it worthwhile to do a rebuild of apps in staging?
[10:33] <acheronuk> rebuilt kmail which failed on stable/unstable, and 17.04.3 build seemed to be ok. so not sure if much will be affected
[10:44] <acheronuk> ..
[10:44] <acheronuk> helpful: https://wiki.ubuntu.com/ArtfulAardvark/Alpha2/Kubuntu
[10:45] <acheronuk> 500 Internal Server Error
[10:46] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[10:46] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kmailtransport build #204: FIXED in 17 min: https://kci.pangea.pub/job/zesty_unstable_kmailtransport/204/
[10:47] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[10:47] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kmailtransport build #258: FIXED in 18 min: https://kci.pangea.pub/job/xenial_unstable_kmailtransport/258/
[11:14] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_ksmtp build #6: NOW UNSTABLE in 22 min: https://kci.pangea.pub/job/artful_unstable_ksmtp/6/
[11:15] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ksmtp build #6: NOW UNSTABLE in 23 min: https://kci.pangea.pub/job/xenial_unstable_ksmtp/6/
[11:15] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_ksmtp build #5: NOW UNSTABLE in 23 min: https://kci.pangea.pub/job/zesty_unstable_ksmtp/5/
[11:25] <ahoneybun> lots of bug reports ac
[11:25] <ahoneybun> acheronuk:
[11:26] <acheronuk> seems the day for them!
[11:26] <ahoneybun> is it the day?
[11:27] <acheronuk> alpha2 and some removal of cruft from the archive, so seems so
[11:27] <ahoneybun> don't know who will fix that button thing on the slideshow
[11:28] <acheronuk> ahoneybun: I tried changing it one like the other flavours use back when you were doing changes. It then worked in my test
[11:29] <ahoneybun> getting it merged is another thing
[11:29] <acheronuk> so..... if I can remember what I did, I can maybe sort that
[11:29] <ahoneybun> greyback: maybe you can help with that?
[11:30]  * greyback reading up
[11:30] <acheronuk> ahoneybun: any progress with updating the slides again?
[11:30] <ahoneybun> acheronuk: nope
[11:30] <ahoneybun> not even the other ubiquity was built with my change
[11:30] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[11:30] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmailtransport build #69: FIXED in 31 min: https://kci.pangea.pub/job/artful_unstable_kmailtransport/69/
[11:31] <ahoneybun> greyback: let me get the repots
[11:31] <ahoneybun> *reports
[11:31] <greyback> ahoneybun: ta
[11:31] <acheronuk> ahoneybun: well, I'm sure we can get something sorted
[11:31] <acheronuk> it can't be left as it is
[11:32] <ahoneybun> nope it's broken in it's state
[11:32] <ahoneybun> greyback: https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful/+merge/326115
[11:33] <ahoneybun> seems to be a new build of ubiquity
[11:34] <ahoneybun> acheronuk: did you see a change in the sidebar color?
[11:34] <acheronuk> yep. very dark grey or black now
[11:34] <ahoneybun> so that's fixed
[11:35] <ahoneybun> acheronuk: more readable?
[11:35] <greyback> ahoneybun: how can I help? Get that reviewed/landed? Or are you having problems with the slides themselves?
[11:35] <ahoneybun> greyback: getting it reviewed
[11:35] <ahoneybun> I know tho conflicts need to be looked at
[11:35] <ahoneybun> not sure what;s up
[11:36] <greyback> ahoneybun: probably just LP getting confused. I'll get it looked at
[11:36] <ahoneybun> and I know the .html files give some issue about <div> but it passes all the html tests
[11:36] <ahoneybun> I know cyphermox knows how it works
[11:37] <acheronuk> he ^^^^^^^ has been away on vacation and is only just back, so may be easier now
[11:37] <ahoneybun> acheronuk: yea I know
[11:37] <ahoneybun> I asked about his vacation yesterday
[11:37] <ahoneybun> but some help is always a good thing
[11:38] <acheronuk> ahoneybun: http://i.imgur.com/kLdappy.png
[11:38] <ahoneybun> mm I think it's a bit better
[11:38] <ahoneybun> sidebar that is
[11:39] <ahoneybun> could use a different logo mayb
[11:39] <acheronuk> that seems a bit lighter blue than our standard one
[11:39] <ahoneybun> I think it was to go with the lighter dark
[11:40] <ahoneybun> acheronuk: got a 16.04 vm if you need landing tests
[11:41] <acheronuk> ahoneybun: I have nothing new for 16.04 at the moment
[11:41] <ahoneybun> acheronuk: alrightly
[11:41] <ahoneybun> ktorrent works well
[11:41] <ahoneybun> downloaded a few iso and seeding
[11:41] <acheronuk> :)
[11:41] <ahoneybun> no crashes
[11:42] <ahoneybun> good stuff
[11:42] <acheronuk> hopefully I can persuade it's -devs to do a new release before feature freeze. though if after should not be too much bother for a FFE I think
[11:42] <ahoneybun> mm we don't have a kubuntu wallpaper package
[11:42] <acheronuk> nope
[11:43] <ahoneybun> maybe greyback could help get that in
[11:43] <ahoneybun> not to put it all on him lol
[11:43] <acheronuk> it could be added as a package to kubuntu-settings if really problematic
[11:43] <ahoneybun> well it does apply only to us
[11:45] <acheronuk> we can try for a separate one 1st. should be simple and no real reason for it to casue a problem getting it in, as long as someone can do the upload
[11:45] <acheronuk> *initial upload
[11:47] <ahoneybun> right
[11:50] <BluesKaj> Hi all
[11:51] <ahoneybun> hey BluesKaj
[11:51] <BluesKaj> Hi  ahoneybun
[11:54] <acheronuk> ahoneybun: are all those wallpapers wanted just single size?
[11:56] <ahoneybun> there's different sizes but would try to find one similar size to upload
[11:56] <ahoneybun> only will be 10 once I get a way to vote
[11:58] <acheronuk> ahoneybun: I really meant do you want some different sizes and aspect ratio for each one? or just go with the best choice for each?
[11:58] <ahoneybun> ummm I was going to pick the largest size and go with that
[11:59] <acheronuk> ok. that makes it even simpler
[12:01] <acheronuk> just that plasma desktop supports multiple sizes for the same wallpaper, so it can choose the best fit for your display
[12:01] <acheronuk> eg: https://packages.ubuntu.com/artful/all/plasma-workspace-wallpapers/filelist
[12:02] <ahoneybun> ahh
[12:02] <acheronuk> but one size fita all is ok if that's what we want
[12:02] <acheronuk> *fits all
[12:06] <greyback> ahoneybun: I've left some comments: https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful/+merge/326115/comments/859613
[12:06] <greyback> something wierd has happened to your branch, I'm unable to merge it with nasty conflicts
 Let me fix my computer
 Think I over loaded chrome lol
[12:08] <ahoneybun> there we go
[12:10] <ahoneybun> greyback: thanks I'll try to start from a clean base
[12:10] <ahoneybun> and use bzr to remove file other then deleting them
[12:11] <greyback> ahoneybun: thanks. Yes "bzr rm" is good to use here
[12:12] <ahoneybun> I'll also fix those issues
[12:13] <ahoneybun> acheronuk: does the export and import feature of latte-dock work for you on git?
[12:13] <ahoneybun> bzr checkout on my current setup?
[12:13] <ahoneybun> greyback: ^
[12:14] <acheronuk> ahoneybun: not tried it yet
[12:15] <greyback> ahoneybun: I typically do: lp:ubiquity-slideshow-ubuntu (as my trunk), then bzr branch ubiquity-slideshow-ubuntu <branch-name>
[12:15] <greyback> and then do the work in <branch-name>
[12:15] <ahoneybun> as someone with 3 monitors now (laptop screen include) it's nice
[12:15] <ahoneybun> trunk?
[12:15] <ahoneybun> then I'm using LP wrong
[12:15] <ahoneybun> I clone the main dev and make changes then push to my trunk
[12:16] <greyback> ahoneybun: yep, and that will work. But bzr isn't great at rebasing changes from the "main dev" as you call it
[12:17] <greyback> so if my branch and trunk diverge, I cd into the trunk, pull, and then switch into my branch and "bzr pull <path/to/trunk>"
[12:18] <ahoneybun> I'm not sure this checkout in bzr from the one in git
[12:18] <greyback> it's the workflow I've found most reliable to avoid confusing bzr when merging
[12:18] <greyback> heh, I didn't realize bzr had a  "checkout"
[12:18] <ahoneybun> then what is this checkout?
[12:19] <ahoneybun> "clean checkout"
[12:21] <acheronuk> ahoneybun: are thsoe my latte-dock ppa builds, or are you doing your own?
[12:22] <greyback> ahoneybun: well I learned something new: https://stackoverflow.com/questions/2980999/is-there-a-difference-between-bzr-clone-bzr-branch-and-bzr-checkout#2981019
[12:27] <greyback> totally different workflow
[12:30] <ahoneybun> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[12:30] <ahoneybun> and this is why we use git and not crappy bzr
[12:31] <ahoneybun> so the conflicts are that the files don't exist
[12:43] <ahoneybun> greyback: https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful2/+merge/328168
[12:43] <ahoneybun> "All changes applied successfully. "
[12:44]  * ahoneybun gets food
[12:55]  * ahoneybun is back
[13:07] <ahoneybun> lovely my plugable stopped working...
 (Photo, 1280x960) https://irc-attachments.kde.org/fKkmhaBP/file_2983.jpg
 @acheronuk
 very weird
[14:00] <acheronuk> new apt doesn't like multiple lines for the same source
 kdevelop-pg-qt (the parser generator) version 2.1.0 was just released.
[14:43] <acheronuk> santa_: I just patched kde4libs to build with cmake 3.9
[14:43] <acheronuk> grrr https://bugs.kde.org/show_bug.cgi?id=382703
[14:44] <acheronuk> digikam ^^^
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1672: SUCCESS in 1 min 0 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1672/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1672: SUCCESS in 1 min 4 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1672/
[14:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1672: SUCCESS in 3 min 46 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1672/
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-02 build #1672: SUCCESS in 4 min 5 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-02/1672/
[17:47] <ahoneybun> cyphermox: I'm not sure what to do with that
[17:48] <ahoneybun> I hate bzr for this confusing way it does things
[17:52] <ahoneybun> how do I fix the conflicts then? the files don't exist to use bzr rm
[17:55] <tsimonq2> I hate every time I have to work with a project that only uses Bazaar because it's so awful to use.
[18:14] <ahoneybun> god it's soooo slow too
[18:14] <tsimonq2> It is
[18:14] <ahoneybun> it's been cloning for a few mins
[18:26] <wxl> i got word from tsimonq2 that he got word from valorie that we're ready to go and i was asked to push the button. anyone got complaints?
[18:27] <ahoneybun> for ?
[18:27] <tsimonq2> ahoneybun: Alpha 2...
[18:27] <wxl> the images
[18:27] <ahoneybun> tsimonq2: how would I know what he is talking about without context?
[18:28] <ahoneybun> wxl: I don't think so
[18:28] <tsimonq2> ahoneybun: The fact that today is Alpha 2 day...
[18:28] <ahoneybun> tsimonq2: could not have looked at my calendar
[18:28] <wxl> just double checking
[18:31] <marco-parillo> No complaints from me. I noticed somebody replicated the OEM install problem.
[18:32] <tsimonq2> And to be honest, while it is an issue, who's going to be doing an OEM install on Alpha 2 of a non-LTS release?
[18:33] <marco-parillo> Agreed. If it was not a stop-ship for 17.04, how can it be for an alpha?  I ran out of time and Wi-Fi on my laptop
 Otherwise I'll do it in Barcelona
[18:36] <clivejo> they looking for a snowflake
[18:37] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Artful Alpha 2] has been marked as ready
[18:37] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop i386 [Artful Alpha 2] has been marked as ready
 I'm not sure the mountains and desert of Colorado are ready for Clive
 Or Clive ready for them
[18:54] <acheronuk> I tried OEM, and it crashed and burned on both isos
[18:55] <acheronuk> but I agree, not a how stopper for alpha2
[18:59] <clivejo> valoriez: what?!
[18:59] <clivejo> why would I go to Colorado when I have all this beautiful rain at home?
[19:00] <tsimonq2> lol
 See?
[19:14] <ahoneybun> mm slideshow is broken now
[19:14] <ahoneybun> well more broken
[19:49] <ahoneybun> fixed
[20:01] <ahoneybun> acheronuk: working on the buttons btw
 (Photo, 780x517) https://irc-attachments.kde.org/Qg0wWu1j/file_2991.jpg
 @acheronuk
 I am TRIGGERED where is the Oxford comma? :P
 you are always triggered
[20:24] <wxl> word
 True :P
[20:25] <wxl> word, word and word.
[20:25] <wxl> and word.
[20:25] <wxl> not
[20:25] <wxl> , and word.
[20:27] <tsimonq2> wxl: S
[20:27] <tsimonq2> wxl: T
[20:27] <tsimonq2> wxl: A
[20:27] <tsimonq2> wxl: H
[20:27] <tsimonq2> wxl: P
[20:27] <tsimonq2> :P
[20:27] <wxl> no, thank and you.
[20:28] <wxl> ^^ i admit, THAT looks weird.
[20:28] <wxl> but i do likes apples, oranges and grapes.
[20:28] <wxl> and that doesn't look weird.
[20:29] <ahoneybun> is it bad that I don't know the oxford comma?
[20:29] <tsimonq2> ahoneybun: Yes,
[20:29] <wxl> while you're on the whole pedantic trip
[20:30] <ahoneybun> oh well
[20:30] <wxl> you may be surprised to know that the rule for a/an is NOT a before consonants, an before vowels
[20:30] <wxl> at least not ALL Of the time
[20:31] <ahoneybun> and cloning ubiquity slideshow again
 (Photo, 236x274) https://irc-attachments.kde.org/xDgbiR1E/file_2993.jpg
[21:20] <genii> oooo a delivery from Washington
 @tsimonq2
 (Document) https://irc-attachments.kde.org/vhqXuoxG/file_2995.mp4
[21:22] <genii> valorie: You have nice handwriting :)
[21:22] <clivejo> she is currently in the air
[21:23] <clivejo> to Barcelona
[21:23] <clivejo> are they stickers?
[21:23] <genii> The stickers she sent arrived just now, yes
[21:23] <genii> They'll get distributed at the 17.10 release party
[21:25] <clivejo> :)
[21:28] <tsimonq2> clivejo, acheronuk: Do you guys object to me doing a KCI rebuild against GCC 7 so we can get fixes for any failures ahead of time (it'll be happening in the archive on August 3rd)
[21:28] <tsimonq2> Or should I not? :)
[21:29] <clivejo> Id do it in a PPA
[21:29] <tsimonq2> Well it's already in a PPA
[21:29] <tsimonq2> It would just be adding a build dep on the PPA that'll be landed in a week
[21:29] <tsimonq2> Help fix any failures (and the inevitable symbols problems!) when it does land
 I mean, that's just my reasoning
[23:06] -kubuntu-ci:#kubuntu-devel- Project mgmt_merger build #917: SUCCESS in 6 min 36 sec: https://kci.pangea.pub/job/mgmt_merger/917/
[23:14] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kdev-python build #50: STILL FAILING in 6 min 36 sec: https://kci.pangea.pub/job/xenial_stable_kdev-python/50/
[23:25] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_dolphin build #59: FAILURE in 17 min: https://kci.pangea.pub/job/zesty_stable_dolphin/59/
[23:34] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_gcompris build #12: STILL FAILING in 27 min: https://kci.pangea.pub/job/xenial_unstable_gcompris/12/
[23:48] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_kalzium build #26: STILL UNSTABLE in 40 min: https://kci.pangea.pub/job/zesty_stable_kalzium/26/
[23:50] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kstars build #284: STILL UNSTABLE in 42 min: https://kci.pangea.pub/job/zesty_unstable_kstars/284/
[23:50] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_elisa build #68: STILL UNSTABLE in 43 min: https://kci.pangea.pub/job/xenial_unstable_elisa/68/


[03:43] <jbailey> doko!
[03:43] <jbailey> doko: Do you need anything else from me on that patch?
[03:44] <doko> no, it's uploaded
[03:50] <jbailey> Cool.


[01:03] <bjsnider> how do you write the control file so that x264-102 forces out x264-xxx where xxx is less than 102?
[01:05] <bjsnider> would Depends: libx264-102 (<< ${binary:Version}) do it?
[01:05] <bjsnider> i mean conflicts, not depends
[09:22] <jcristau> bjsnider: normally you don't do that.
[11:33] <toabctl> i have a bamboo fun cth 661 which is not recognized with ubuntu maverick.
[11:34] <toabctl> when i plugin, syslog says: Jul 21 12:34:19 zitrone kernel: [ 2009.316083] usb 3-1: new full speed USB device using uhci_hcd and address 5
[11:35] <toabctl> i loaded the wacom kernel module (modprobe wacom). $ lsmod |grep wacom
[11:35] <toabctl> wacom                  26204  0
[11:35] <toabctl> any ideas?
[11:43] <tjaalton> is it a real wacom brand device, or an oem one?
[11:57] <tjaalton> ah, so it's a pen&touch model, no support for it yet then
[12:59] <bigon> In dmesg I get "You have old & broken userspace please consider updating mesa" under maverick, is that know or should I open a bug?
[13:26] <jcristau> bigon: it's known
[13:39] <bigon> I've just opened a bug :x
[13:40] <RAOF> Anyone running Lucid on i386 with an intel GPU?
[13:41] <RAOF> I'd like to check that https://edge.launchpad.net/~raof/+archive/aubergine/+packages works before pointing everyone with broken i855 at it for testing.
[15:01] <ScottK> RAOF: I've got an i865 machine that is currently working not too bad.  As long as there's a clear path back to the current packages, I can test that.
[15:02] <RAOF> Excellent.
[15:02] <ScottK> RAOF: The xorg-server change we discussed is uploaded too.
[15:02] <RAOF> I noticed.  Thanks.
[15:02] <RAOF> So, the path back would be either (a) manually downgrade xserver-xorg-video-intel & libdrm*, or (b) use ppa-purge to do that automatically.
[15:04] <ScottK> OK.  How urgent is this?
[15:04] <ScottK> Is this aimed at 10.04.1?
[15:04] <RAOF> It's not.
[15:05] <RAOF> It won't hit 10.04.1; it's too big a change (basically grafting a whole new driver into -intel)
[15:05] <RAOF> But it needs testing so that I can push for it to be merged to -intel mainline, so that it can work in Maverick.
[15:16] <ScottK> OK.  So if I don't get to it until Friday, it's not critical?
[15:16] <ScottK> I'm glad you aren't pushing it for 10.04.1.
[15:21] <RAOF> It's not critical.
[15:23] <ScottK> OK.  I'll try to carve out some time then.
[15:23] <RAOF> Whenever you've got a lazy hour.
[15:23] <RAOF> Thanks.
[17:04] <kees> RAOF: turned out to be a bug in the recent debian merge.  the ubuntu udev rules was subtly more correct than the debian one.
[17:05] <RAOF> kees: GAH!  I stared at that merge.
[17:05] <RAOF> (At the time, not just now)
[17:05] <jcristau> what's wrong with our udev rules? :)
[17:05] <kees> RAOF: heh, me too.  I looked at the old udev rules and was all "oh, these are the same"  :P
[17:06] <kees> jcristau: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589847
[17:06] <ubot4> Debian bug 589847 in xf86-input-wacom "internal serial wacom devices ignored" [Normal,Open]
[17:06] <RAOF> We might as well also grab the new 0.10.7 release.
[17:06] <jcristau> oh, wacom.
[17:06] <kees> jcristau: heh
[17:06] <jcristau> not my fault then \o/
[17:06] <RAOF> Yah.  One of the annoying non-xsfbs X packages :/
[17:08] <RAOF> Is there a release schedule for mesa somewhere?
[17:08] <jcristau> not that i know of
[17:09] <RAOF> Apart from “quarterly”.
[17:47] <Sarvatt> RAOF: can ya bring up the modular agp problem at the sprint if you get a chance? :)
[17:47] <RAOF> Sarvatt: Yes!
[17:48] <RAOF> I've already got vga16fb handled.
[17:48] <Sarvatt> just in time for the switch away from vga16fb to vesafb huh? :)
[17:48] <RAOF> No - currently vga16fb *and* veasafb is loading.
[17:49] <Sarvatt> blacklisting vga16fb isthe first thing i do on all of my machines so i didn't notice :)
[17:50] <RAOF> We've dropped the patch which made vga16fb fail to bind if there was already a framebuffer driver.
[17:50] <RAOF> So now there's /dev/fb1 driven by vga16fb waiting for the unwary to trigger it.
[17:50] <Sarvatt> probably should drop the patch making vga16fb load for all vga pci devices too from last december
[17:53] <Sarvatt> darnit, ati stopped building oddly, it failed on amd64 on both maverick and lucid last upload, now this upload it only failed on maverick but on both i386+amd64. http://launchpadlibrarian.net/52240157/buildlog_ubuntu-maverick-i386.xserver-xorg-video-ati_1:6.13.99%2Bgit20100720.593eff29-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[18:08] <RAOF> Sarvatt: Yup, that's what's going to happen - we'll drop the “bind to everything” patch.
[18:27] <Sarvatt> oh bah i forgot to add x11proto-xinerama-dev to xserver-xorg-dev last time i updated it
[19:10] <bryceh> RAOF, how's the sprint going so far?
[21:43] <gtaylor> Hate to ask such a basic question, but does adding the stable ubuntu-x-swat and updating allow you to install Catalsyt 10.6 drivers from Jockey?
[21:44] <gtaylor> Or the command line for that matter. Just not sure what version of the drivers ubuntu-x-swat stable is on.
[23:03] <Sarvatt> yeah catalyst 10.6 is in there, but it'll require running aticonfig --initial after installing it


[00:56] <micahg> ddecator: meeting is about what the team should try to accomplish for Maverick
[00:57] <ddecator> micahg: ok
[00:58] <ddecator> micahg: still insterested in attending though
[01:00] <micahg> ddecator: good :)
[01:01] <ddecator> micahg: ok, wasn't sure if you were trying to say it was something i wouldn't be interested in =p, but i figure i'm working enough with the team to warrant me being there ;)
[01:01] <micahg> ddecator: even if you weren't, you'd still be welcome, part of this is to see what people would like the team to accomplish, not just our own goals
[01:01] <ddecator> micahg: true
[01:07] <micahg> ddecator: good find on the audio bug
[01:07] <micahg> ddecator: I meant video
[01:07]  * micahg should be sleeping at 2am
[01:07] <ddecator> micahg: thanks, it took me some fighting with firebot to find it, haha. did you add it upstream? if you did i can add the watch downstream and mark it triaged
[01:07] <micahg> ddecator: if I can remember how to log in :)
[01:08] <ddecator> micahg: that's helpful =p
[01:08] <ddecator> micahg: btw, jetlagged? haha
[01:08] <micahg> ddecator: nah
[01:08] <micahg> ddecator: do you want to add it to the LP bug?
[01:09] <ddecator> micahg: yah, i can take care of the dowstream stuff
[01:09] <ddecator> downstream*
[01:11] <micahg> ddecator: done
[01:11] <ddecator> micahg: thanks =)
[01:30] <micahg> ddecator: I think that bug should be at least medium since it's a time consuming bug
[01:31] <ddecator> micahg: even though it'd fixed upstream?
[01:31] <ddecator> it's*
[01:31] <micahg> ddecator: yes, importance is based on the bug's impact in Ubuntu, not whether it's fixed
[01:32] <mahfouz> are you at uds right?
[01:32] <ddecator> micahg: alright, i'll adjust it
[01:32] <mahfouz> *right now?
[01:32] <micahg> mahfouz: yes
[01:32] <mahfouz> micahg, ok, so what's the default browser in 10.10? :)
[01:33] <micahg> ddecator: thanks
[01:33] <ddecator> they didn't have that meeting yet, did they?
[01:33] <micahg> mahfouz: come to the session on Thursday at 13:00 UTC
[01:34] <mahfouz> I'll try to tune in by video :)
[01:34] <micahg> mahfouz: k
[01:34]  * micahg is heading to sleep now
[01:34] <ddecator> micahg: medium or should we go for high since it's a functionality issue that affects everyone using the default install?
[01:35] <micahg> ddecator: well, what's estimated impact?  Are a lot of people playing ogg over a slow connection?
[01:35] <ddecator> micahg: no way to know, but i'm guessing not. does effect fast connections too though, just not as much. i'll go for medium since ogg videos aren't very common
[01:36] <micahg> ddecator: it's the backend for HTML5 video in Firefox ;)
[01:36] <ddecator> yah, but not many websites are using it =\
[01:37] <micahg> k, off for real now :)
[01:37] <ddecator> night micahg
[08:51] <micahg> bdrung: ping
[08:51] <bdrung> micahg: pong
[08:52] <micahg> bdrung: is there any way to use install-xpi on karmic with m-devscripts 0.17 or is a later version needed?
[08:53] <bdrung> micahg: you need at least version 0.19
[08:53] <micahg> bdrung: k, thanks
[08:57] <micahg> bdrung: BTW, we have a session at UDS at 15:10 UTC today if you want to attend
[08:58] <bdrung> micahg: i'll try to be there remotely
[08:58] <micahg> bdrung: k, great
[09:06] <BUGabundo_remote> Oh,Oh,Oh,Merry...oops Wrong dressed guy (Pope)
[09:13] <BUGabundo_remote> fta: still broken
[09:31] <BUGabundo_remote> updated http://code.google.com/p/chromium/issues/detail?id=42267
[10:15] <fta> asac, fyi, evan (from chromium) is at UDS, if you'd like to meet him
[10:20] <BUGabundo_remote> eheh
[10:52] <micahg> fta: he's in my session now :)
[10:53] <fta> micahg, good to know he found his way (he knows no one from the ubuntu community beside asac and me)
[10:53] <micahg> fta: I'm sorry, I should have invited you to this session
[10:54] <fta> micahg, no problem, i'm busy anyway
[10:56] <fta> micahg, please tell asac/jcastro that a beta of chromium is out, i will update maverick, but i'm still stuck with lucid (iirc, jorge was supposed to contact the TB)
[10:56] <micahg> fta: k
[10:56] <fta> (a "new" beta)
[10:56] <fta> the 2nd that lucid missed
[10:56] <micahg> fta: ugh
[11:02] <fta> micahg, pm
[11:06] <fta> the app indicator doesn't seem to like gwibber
[14:54] <chrisccoulson> micahg - i've just noticed there is actually a 3-way scheduling conflict for me this afternoon
[14:55] <chrisccoulson> there is also the global menu bar session at 1700
[14:55] <micahg> chrisccoulson: ugh, so what do we do?
[15:10] <gnomefreak> can someone let me know 10 minutes before session so i dont forget?
[15:10] <DASPRiD> sure
[15:10] <DASPRiD> when is session? :)
[15:11] <gnomefreak> DASPRiD: 1500 UTC+2
[15:11] <gnomefreak> opps
[15:11] <gnomefreak> UTC+2
[15:11] <DASPRiD> that was one hour ago
[15:11] <gnomefreak> 49 minutes from now
[15:11] <DASPRiD> hm, sure that is UTC+2?
[15:12] <DASPRiD> UTC+2 = CEST, right?
[15:13] <gnomefreak> not sure. UTC+2 is where UDS is being held. I'm not good with timezones
[15:15] <DASPRiD> apparently :)
[15:15] <micahg> DASPRiD: currently CEST= UTC+2
[15:15] <DASPRiD> anyway, i remind you in 34 minutes
[15:16] <DASPRiD> micahg, so currently it is 16:16 CEST, so 16:16 UTC+2
[15:16] <DASPRiD> when session was at 1500 UTC+2, its over ;)
[15:17] <gnomefreak> it was 1500 UTC time
[15:17] <DASPRiD> heh well you said UTC+2 :P
[15:21] <gnomefreak> i know but hey it sounding fun :)
[15:21] <gnomefreak> sounded
[15:23] <micahg> DASPRiD: right :)
[15:32] <gnomefreak> micahg: do you have the firefox bug about it booting you right out of Ubuntu? I cant find it at all but i will keep looking
[15:32] <micahg> gnomefreak: not a firefox bug...but I think I know which one you mean..
[15:33] <gnomefreak> micahg: its an X bug but i cant find it under X anywhere
[15:33] <micahg> bug 539772
[15:34] <gnomefreak> micahg: thanks
[15:50]  * gnomefreak tries to hurry on email so i can smoke before session
[15:51] <micahg> gnomefreak: you have 20 minutes :)
[15:51] <gnomefreak> oh i thought 9 but 20 is good :)
[15:52] <micahg> 18 if you want to be nit picky
[15:53] <gnomefreak> :)
[15:53] <micahg> :)
[15:53] <gnomefreak> first round of email is done. ill be back in a few
[16:01] <gnomefreak> and another session thursday at 6am
[16:04] <micahg> gnomefreak: which session?
[16:04] <gnomefreak> IRC
[16:04] <gnomefreak> an ops session (renaming channels adding channels ect...
[16:04] <micahg> k
[16:04] <micahg> 6 minutes to session :)
[16:05] <gnomefreak> micahg: thanks im almost there :)
[16:06] <ddecator> i'm in there
[16:06] <ddecator> micahg: is there gonna be a gobby doc?
[16:14] <micahg> ddecator: yes
[16:14] <micahg> session in #ubuntu-uds-ebene
[16:14] <ddecator> yes, i'm already streaming it
[17:14] <gnomefreak> somones gonna hate me :)
[17:14] <micahg> gnomefreak: why?
[17:14] <gnomefreak> micahg: tb addon
[17:14] <micahg> gnomefreak: heh
[17:14] <micahg> gnomefreak: ttyl
[17:14] <gnomefreak> !info funambol
[17:14] <gnomefreak> micahg: have fun
[17:15]  * gnomefreak will test first


[21:32] <jose-phi_> exist a way
[21:32] <jose-phi_> when juju deploy a container
[21:32] <jose-phi_> to setup the network from juju?


[00:40] <valorie> I know what it IS, I just find it bizarre that any traces remain
[11:05] <BluesKaj> Hi folks
[14:02] <genii_> valorie: That weird message when trying to boot Eoan iso image from GRUB https://pastebin.ubuntu.com/p/VhP6NBTHVK/
[20:13] <valorie> genii_: how weird! esp. as it assumes that you can boot into windows
[20:13] <valorie> RikMills: what do you think?
[20:16] <genii_> valorie: Strangely, after I zsynced that image with today's, it boots using the same parameters as the other previous images. But for some reason the Lubuntu daily is giving the exact same symptoms now
[20:17] <genii_> ( got stuck tinkering with that, haven't tested the Xubuntu)
[20:17] <valorie> I picked up from the +1 chan that the latest installer changes are not always making it to the latest ISOs
[20:17] <valorie> yesterday
[20:17] <valorie> not all read up yet today
[20:18] <genii_> Yeah, probably it
[20:21] <genii_> Last visible changes to casper on launchpad I could find were from like 10 years ago, ironically Riddell
[20:24] <valorie> this was ubiquity
[20:24] <valorie> I dunno much about casper


[23:26] <kwwii> if you look closely, you will, unfortunately see that the strokes of some objects at certain sizes don't line up to the object underneath them, which is an error caused by simply scaling the larger sizes down
[23:27] <kwwii> thanks Riddell
[23:27] <kwwii> so on the small sizes the image is made of large, simple shapes and gradients
[23:28] <kwwii> whereas the larger sizes use a texture on the metal part of the floppy
[23:29] <kwwii> does anyone see the problem with the texture in the larger sizes?
[23:29] <Riddell> here is just that icon http://muse.19inch.net/~jr/tmp/icon.tar.gz
[23:30] <kwwii> for whatever reason it is off by 4 pixels in both the x and y coordinates
[23:31] <kwwii> so over-all my point is that drawing pictograms is not drawing pictures...only the very large sizes come close to illustration and illustration is in any case differetn than real artwork
[23:31] <kwwii> it is about artistic design
[23:31] <kwwii> and if you really want to learn how to do it, look at the stuff that is already out there very closely
[23:32] <kwwii> oxygen is about very subtle, realistic surfaces and materials
[23:32] <kwwii> simple gradients everywhere
[23:32] <kwwii> although the outer edges of things tend to be a bit darker
[23:33] <kwwii> which precludes the need to use a line around the icon the define it against the background
[23:33] <kwwii> which increases the realism
[23:33] <kwwii> but really, the small oxygen icons are just as simple as any other theme
[23:33] <kwwii> there is no way around that
[23:33] <kwwii> it is not a matter of design but a matter of physics
[23:34] <kwwii> interestingly enough, with the advance of computer displays the tiny little things they are selling today have really high resolutions so larger icons are needed more than ever
[23:35] <kwwii> funny that...it took a tiny display with high resolution to increase the need to larger sizes icons
[23:35] <kwwii> people always say that I talk to fast when giving a presentation...I get the feeling that I am typing to fast as well
[23:36] <kwwii> any questions?
[23:36] <Riddell> the wrong texture is on the metal slider at the bottom of the floppy disk?
[23:36] <Quintasan> none so far, I'm amazed by the amount of work you have
[23:37] <kwwii> Riddell: yes, let me make a screenshot
[23:37] <Riddell> I see it
[23:37] <Riddell> how long  does it take to make an icon like that?
[23:38] <kwwii> http://sinecera.de/Screenshot.png shows the problem clearly, I think
[23:38] <kwwii> in the old days I would have said that a typical icon takes a day to make
[23:39] <kwwii> some, like arrows and such are so closely related that it takes a few days to hammer out the concept but then you have a lot of icons done quickly
[23:40] <kwwii> whereas some things take time just to create an idea of the metaphor you want to express
[23:40] <kwwii> really, it is about creating visual metaphors which people translate into concrete ideas or actions
[23:40] <kwwii> so they are very important and very hard to do "right"
[23:41] <YenTheFirst> That was going to be my question (and what I originally thought this talk would be about): How do you go about creating a good visual metaphore?
[23:41] <YenTheFirst> *metaphor
[23:41] <kwwii> you can make the most amazing pineapple icon at 16x16 and say it means miscellaneous but people will call you on it for years
[23:42] <Daskreech> Gotta go!
[23:42] <kwwii> YenTheFirst: well, the way we have done it is 1) asked ourselves what kind of styling would be appropriate for this metaphor
[23:42] <Riddell> speaking from experience on the pineapple are we? :)
[23:42] <kwwii> ie is it something slick and sexy or is it something simple and plain
[23:43] <kwwii> then, we created a kind of definition for the different icon types
[23:43] <kwwii> http://www.oxygen-icons.org/?page_id=2 explains the idea
[23:43] <kwwii> although we probably didn't reach all of those goals, we still try to live by the ideas behind them
[23:44] <kwwii> so we look at the material type and how it reacts to light
[23:44] <kwwii> that is very important as the things we make are hyper-realistic at the larger sizes
[23:44] <kwwii> another thing to take into account is the smaller sizes
[23:44] <kwwii> how does it work, scale it down, make a simpler version
[23:45] <kwwii> then go back and change the big version, etc
[23:45] <kwwii> back and forth to some degree
[23:45] <kwwii> so depending on the size, the icon gets more complicated
[23:46] <kwwii> the smaller sizes, although they may seem more challenging or really the things that the new artist could look into first
[23:46] <kwwii> although, if they are really good at illustration then I would suggest simply talking to me directly
[23:46] <kwwii> :)
[23:48] <apachelogger> so
[23:48] <kwwii> so, as the last part of this, I thought that if enough people are intersted in actually discussing something and working out an idea for an icon we could make one
[23:48] <kwwii> I was told that there is a need for an icon for the usb image creator (or such)
[23:49] <Riddell> an icon in ten minutes!
[23:49] <kwwii> exactly, well, at least the basics
[23:49] <kwwii> so it occured to me that people only install an image on a usb key and not disk
[23:50] <kwwii> and as I made the current oxygen usb key icon I figured we could go from there
[23:50] <apachelogger> *nod*
[23:51] <kwwii> so open drive-removable-media-usb-pendrive.svg from scalable/devices
[23:52] <kwwii> ideally we want to say that we are putting kubuntu onto a stick, right?
[23:52] <kwwii> ie. if I am wrong or you have blood pumping through your brains say something :p
[23:52] <Riddell> http://websvn.kde.org/*checkout*/trunk/kdesupport/oxygen-icons/scalable/devices/drive-removable-media-usb-pendrive.svgz
[23:53] <YenTheFirst> my brains are empty and bloodless. :P
[23:53] <Quintasan> kwwii: Kubuntu logo and an arrow comes to my mind
[23:53] <kwwii> so we could remove the oxygen branding - trust me, I know them :p I am sure they will be ok with it - and add a kubuntu logo
[23:54] <kwwii> Quintasan: yes, the logo is good
[23:54] <kwwii> another thing to look at it how the oxygen icons show adding something new
[23:55] <kwwii> if you look around (trust me, I have) it uses a white plus symbol on a green 3d globe thingy
[23:55] <kwwii> not sure if that is what we want for this though
[23:55] <Riddell> http://kubuntu.org/art/kubuntu-feisty-plain.svg  logo
[23:56] <apachelogger> kwwii: could become a bit crowded, right?
[23:56] <kwwii> I think making the purple in the usb stick blue and adding a nice kubuntu logo would be enough...maybe a star or something like that to show the act of creation
[23:56] <kwwii> apachelogger: exactly
[23:56] <kwwii> this icon will mainly be shown at 48x48 I guess
[23:56] <kwwii> Riddell: do you know the details of the icon size?
[23:57] <kwwii> one interesting thing about this icon is that at the time I made it we could not rely on guassian blur support from inkscape so we had to draw the shadow by hand
[23:57] <apachelogger> it's only shown in the kickoff menu and window decoration I suppose
[23:58] <kwwii> apachelogger: hehe, so a large version and a *really* small version
[23:58] <apachelogger> righto
[23:58] <Riddell> kwwii: I don't I'm afraid
[23:58] <kwwii> which is a worst case scenario, really
[23:58] <kwwii> no worries
[23:58] <kwwii> I'll make this icon blue and add a logo to it
[23:59] <Riddell> http://people.ubuntu.com/~jriddell/tmp/kubuntu-usb-creator.png  I am an artist!


[07:15] <alourie> good morning
[16:42] <cjohnston> mornin
[17:00] <duanedesign> o/
[17:00] <duanedesign> that was one big netsplit.
[17:00] <cjohnston> heh
[17:01] <duanedesign> ahh, i see the Global Notice.
[17:33] <akgraner> alourie, thank you for your help with UWN!
[19:00] <alourie> akgraner: sure thing
[19:00] <alourie> I only could do this couple
[19:00] <alourie> the baby is sick, so he's on our hands all day... :-(
[19:04] <alourie> s/the/my


[13:56] <Martyn> Morning .. what is this OMAP printk() patch I keep seeing people talk about on lists related to the beagleboard?


[00:46] <sarnold> is this the right channel for someone who's having trouble getting skype to work?
[02:30] <cjp256> sarnold: what is the problem you are having?
[02:32] <sarnold> cjp256: another user in #ubuntu was having trouble getting skype to work via the snap; he had to run /snap/bin/skype explicitly, and once he did that he had problems with some authentication step within skype
[02:33] <sarnold> cjp256: I asked if this was a good place for user help when he was having trouble figuring out how to even run skype, but another #ubuntu user aimed him towards /snap/bin/skype, which appeared to work
[02:34] <sarnold> I wanted to make sure this was the right place to send him, before sending him here, since it'd exceeded my knowledge ;) but he got far enough to find out that he wasn't going to be able to use the skype snap in the end
[02:34] <sarnold> is this the right place to send people who are having trouble with snap?
[02:35] <cjp256> it depends, naturally :)  but I've been working with the skype snap a lot lately and figured I'd ask.  It can't hurt to ask the question and see where fate takes it... :D
[04:57] <mup> PR snapd#7249 closed: packaging/fedora: build on RHEL8 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7249>
[04:58] <mup> PR snapd#7248 closed: interfaces/mount: discard mount ns on backend Remove <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7248>
[06:01] <pedronis> mvo: hi, so jdstrand first two PRs are in better shape, but they are split a bit strangely so that the first will turn on the feature in a broken state, a full reorg of the PRs is probably too much at this point, my idea is to tweak the first to use a temporary global flag, to keep the feature off while we work through them one by one
[06:12] <pedronis> mvo: sounds reasonable?
[06:21] <mvo> pedronis: yes
[06:21] <mvo> pedronis: thanks, once I finish some org stuff I will jump to the reviews for those
[06:33] <pedronis> mvo: the first one has already 2 +1 I'm tweaking it as we speak though
[06:34] <mvo> pedronis: first one is 7111 ?
[06:35] <pedronis> yes
[06:35] <pedronis> I'll ask you to check my tweaks once pushed
[06:35] <mvo> ta
[07:06] <jamesh> mvo: thanks for calling me up on that lock issue with the session agent PR.  Getting rid of the need not to use defer to release the lock ended up making the code simpler.
[07:08] <mvo> jamesh: nice! thats great to hear. thanks for this. I will have another look in some minutes then :)
[07:17] <pedronis> mmh
[07:36] <pedronis> mvo: can you look at my own commits to 7111
[07:36] <pedronis> that I just pushed
[07:43] <mvo> pedronis: yes
[08:06] <mup> PR snapd#7257 opened: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
[08:10] <mvo> welcome back mup !
[08:10]  * mvo hugs niemeyer
[08:40] <pedronis> mvo: I'll look again at 6404 in a little bit
[08:41] <mvo> pedronis: thanks! I noticed small issues with 7111 (not in your new code, that part looks fine). review should be ready soon
[08:41] <mvo> pedronis: deriveContent is missing a test and also never changes firstRun
[08:41] <Chipaca> hah, i was just about to ask about 6404
[08:43] <Chipaca> i wish github had 'private' tags
[08:43] <Chipaca> ie that i could tag things without everybody seeing them as tagged
[08:48] <Chipaca> jamesh: what's the status of #5822 ?
[08:48] <mup> PR #5822: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
[08:49] <jamesh> Chipaca: blocked on being able to control user daemons over snap install/upgrade/removal
[08:49] <Chipaca> hmmm
[08:49] <jamesh> Chipaca: this is what the user session agent branches I've been working on are intended to solve
[08:49] <Chipaca> zyga: what happened to refresh control? (is that what we were calling it)
[08:55] <pedronis> Chipaca: what's the context for that question?
[08:55] <pedronis> also z-yga is supposed to be off today
[08:58] <Chipaca> pedronis: context of the question was that I thought we'd made progress on it, and that if we had that then refresh of things with user daemons would be a'ight ? dunno
[08:58] <Chipaca> was trying to figure out if/how those two fit together really
[09:00] <pedronis> Chipaca: that is not refresh control,  that's refresh awarere/prevent refreshes while running
[09:00] <Chipaca> yeah that
[09:00] <pedronis> heh, awareness
[09:00] <pedronis> Chipaca: but, there was progress, but daemon have they own rules
[09:00] <Chipaca> too late, it's awarere now
[09:00] <pedronis> their
[09:01] <pedronis> also we cannot really expect the user to be on top of daemons (vs gui apps)
[09:01] <pedronis> so it's related but also orthogonal
[09:01] <pedronis> to the issue of user session services
[09:01] <Chipaca> to me they are separate issues
[09:01] <Chipaca> one is preventing the refresh
[09:01] <mvo> pedronis: I will do the tiny fix in interfaces/seccomp/backend in 7111 because the current running tests are failing (network again it seems) so it seems to be fine to push this small fix (removing firstRun)
[09:02] <Chipaca> the other is notifying the user or the snap about the refresh
[09:02] <pedronis> yes, we know that
[09:02] <Chipaca> there is a rather strong demand from good snap authors for them to be in the pipeline of this
[09:02] <Chipaca> that is
[09:02] <Chipaca> the snap wants to be told there is a refresh there
[09:03] <Chipaca> and for user-mode daemons, same thing could apply? again dunno, but, don't see why we can't start there
[09:03] <Chipaca> anyhow
[09:03] <Chipaca> moving on up the queue
[09:05] <pedronis> Chipaca: that work is discussed, tracked here: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/13
[09:05] <pedronis> fwiw
[09:05] <pedronis> though that needs an update from a couple discussions in toronto
[09:16] <Chipaca> pro tip: don't start on the third page of PRs unless you're immune to getting into a funk
[09:16]  * Chipaca is not immune and needs a break now
[09:17] <pedronis> Chipaca: to be fair atm we should just concetrate on 2.41 marked ones
[09:18]  * ogra plays some jazz to get Chipaca out of the funk
[09:18] <mvo> pedronis: I pushed a tiny patch to 7111, double checking would be appreicated
[09:31] <Aavar> I have (as you may have seen earlier) a problem with launching graphical snaps. I have zyga helping me, but we have not figured it out. If anyone else has something to add it would be appriciated:) https://paste.ubuntu.com/p/MjhDYjt8GR/
[09:33] <Chipaca> Aavar: I did not see. What's the output of 'snap version'?
[09:33] <pedronis> mvo: I'll look in a bit
[09:34] <Aavar> Chipaca, https://paste.ubuntu.com/p/Xv3zqPQCcC/
[09:35] <Chipaca> Aavar: what's special about your installation?
[09:37] <Aavar> Chipaca, hmm... Nothing more than that I have messed with it for about a year... THe last thing I did yesterday was to try to reinstall all the apt-packages on my system.
[09:37] <Aavar> brb, lunch.
[09:37] <Chipaca> Aavar: are you running X?
[09:38] <pedronis> mvo: I was reviewing #7254
[09:38] <mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
[09:42] <pedronis> mvo: you have a change to templage.go that looks wrong
[09:42]  * Chipaca takes a break
[09:59] <Chipaca> hmm, it looks like core 18 is broken?
[09:59] <Chipaca> lots of core18 spread tests failing
[10:01] <Aavar> Chipaca, I am running X yes.
[10:02] <mvo> pedronis: yeah, fixed. silly me
[10:02] <Chipaca> Aavar: can you snap install xbill-xaw?
[10:03] <Aavar> Chipaca, yes, and then run it?
[10:04] <Chipaca> Aavar: yes please, run just 'xbill-xaw'
[10:04] <Aavar> Chipaca, "Error: Can't open display: :0"
[10:04] <Aavar> Chipaca, only that.
[10:04] <diddledan> that's an odd one if you're not in Wayland
[10:05] <Chipaca> Aavar: can you 'snap run -strace xbill-xaw' please
[10:05] <diddledan> --strace, no?
[10:05] <Chipaca> yes
[10:05] <Chipaca> probably
[10:06] <diddledan> double that dash!
[10:06] <Aavar> Chipaca, Got a bunch of errors. Let me paste that.
[10:08] <Aavar> Chipaca, diddledan: https://paste.ubuntu.com/p/zHvtXYcmms/
[10:09] <diddledan> looks like the socket was EACCESS
[10:09] <diddledan> i.e. permission denied for some reason
[10:10] <Chipaca> Aavar: dmesg | grep DENIED ?
[10:10] <ogra> what kind of desktop env and display manager is running there ?
[10:11] <diddledan> random Windows folder name oddity for your bemusement :-) https://usercontent.irccloud-cdn.com/file/8lZTm56c/image.png
[10:11] <Aavar> Chipaca, https://paste.ubuntu.com/p/XpDd8tTJKW/
[10:12] <Chipaca> Aavar: I'm now suspicious of your apparmor
[10:12] <Aavar> Chipaca, are there some way to completely shut down apparmor for testing?
[10:13] <Chipaca> Aavar: when you tried to reinstall all the apt-packages, did you reinstall apparmor?
[10:13] <Chipaca> (it's an apt package with that name)
[10:14] <Aavar> Chipaca, I am not sure, but I guess so. I ran this script that is supposed to reinstall all packages. https://ubuntuforums.org/showthread.php?t=735693
[10:14] <diddledan> and what commands did you use to reinstall all the apt packages - might be you got your system in a wonky state by doing that
[10:14] <Chipaca> 2008
[10:14] <Chipaca> yeah
[10:15] <Aavar> (I know it's a bad idea run scripts from the internett, but I figured it was worth a try as I am stuck anyway...)
[10:15] <Chipaca> Aavar: didn't the "this has been tested on 7.10" alert you to anything?
[10:15] <pedronis> mvo: frequent red, landing things will be hard
[10:16] <Chipaca> diddledan: for pkg in `dpkg --get-selections | awk '{print $1}' | egrep -v '(dpkg|apt|mysql|mythtv)'` ; do apt-get -y --force-yes install --reinstall $pkg ; done
[10:16] <ogra> i wonder what that is supposed to ahieve
[10:16] <ogra> *achieve
[10:17] <Chipaca> ogra: from the forum post above
[10:17] <Aavar> Chipaca, I did read that, and figured that I would reinstall if it broke my system. To be fair, the script seemed to run fine and I am in the same spot now that I was before.
[10:17] <mvo> pedronis: yeah, the next red I will go berzerk and just disable tests
[10:17] <ogra> yes
[10:17] <ogra> i saw that
[10:17] <Chipaca> Aavar: do you have any data in ~/snap that you care about
[10:17] <Aavar> Chipaca, nope.
[10:17] <ogra> still wondering ... it will only replace existing binaries and leave the configs alone
[10:17] <Chipaca> mvo: core 18 seems broken tho
[10:17] <Chipaca> Aavar: sudo apt purge snapd
[10:17] <Chipaca> Aavar: and then sudo apt install snapd
[10:18] <Aavar> Chipaca, btw, I did try to add a new user and it gave me the same result.
[10:18] <Chipaca> Aavar: and then reboot
[10:18] <Aavar> Chipaca, will do. brb
[10:18] <ogra> unlikely to change anything over what has been there ... unless someone actively rm'ed something from the rootfs
[10:18] <mvo> Chipaca: oh no? what exactly
[10:18] <diddledan> mvo: "everything" :-p
[10:18] <diddledan> I troll
[10:18]  * mvo hugs diddledan
[10:19] <ogra> !
[10:19] <diddledan> \o/ huggies!
[10:19] <Chipaca> mvo: https://api.travis-ci.org/v3/job/571891969/log.txt
[10:19] <Chipaca> mvo: i'm trying to figure out what exactly
[10:19] <Chipaca> mvo: bunch of apparently different errors, everything failed to prepare/restore and nothing succeeded afaict
[10:19] <mvo> Chipaca: :( I wonder if an core18 upload borke it
[10:20] <Chipaca> waiting for a debug run of spread to get me a shell now
[10:20] <Chipaca> so i can get more info
[10:20] <Chipaca> but, thought i'd mention it :)
[10:21] <Chipaca> diddledan: wrt that screenshot, if I saw that folder I'd assume it was malware and nuke the installation
[10:23] <diddledan> it looks like the issue in that spread log might be related to coming back online after the reboot?
[10:24] <diddledan> specifically there's several of these: `error: cannot communicate with server: Get http://localhost/v2/connections?select=all: read unix @->/run/snapd.socket: read: connection reset by peer`
[10:25] <diddledan> maybe not after reboot - but after reboot or restart of core after the refresh
[10:26] <Aavar> Chipaca, After reinstall I get this error: https://paste.ubuntu.com/p/S69zyQg8yM/ Do I need to start the daemon?
[10:26] <diddledan> you will need to reinstall the snaps
[10:26] <Chipaca> Aavar: what's 'snap version' now?
[10:27] <diddledan> oh I see you were
[10:27] <diddledan> the daemon should automatically start IIRC
[10:27] <Chipaca> Aavar: maybe snapd was just taking a bit of time starting? what's the output of systemctl status snapd?
[10:27] <diddledan> it's prolly refreshing itself?
[10:28] <Chipaca> either that, or we should send thoughts & prayers
[10:28] <Chipaca> mvo: no debug shell :-(
[10:28] <Chipaca> mvo: EOF of death
[10:28] <Aavar> Chipaca, diddledan: https://paste.ubuntu.com/p/pzcjRqFVZm/ looks like the service is not running properly.
[10:28] <Chipaca> Aavar: yeah gonna need that status thing
[10:28]  * Chipaca prepares a wreath
[10:29] <Aavar> Chipaca, sorry. https://paste.ubuntu.com/p/ZT8dQ35G7Y/
[10:30] <Chipaca> Aavar: you've apparently changed things so services aren't started automatically on install?
[10:30] <Chipaca> Aavar: try sudo systemctl enable --now snapd.\*
[10:30] <Aavar> Chipaca, not on purpose...
[10:30] <Chipaca> i don't remember if * worked for 'enable'
[10:31] <Chipaca> Aavar: I purposely did not say you did it intentionally
[10:31] <Chipaca> :)
[10:31] <Aavar> Chipaca, * didn't work but I'll run it for all the services.
[10:32] <Chipaca> Aavar: k. some won't like being enabled but that's probably ok
[10:32] <Chipaca> (some of them are only for weird systems)
[10:32] <Chipaca> snap.service and snapd.socket should both be enabled
[10:32] <Chipaca> snapd.service*
[10:32]  * Chipaca struggling to type
[10:33] <Aavar> Chipaca, ok, Now i'm installing xbill-xaw again.
[10:34] <Aavar> Chipaca, or should I do something else?
[10:34] <Chipaca> Aavar: hold on
[10:34] <Chipaca> Aavar: what's the status of apparmor.service ?
[10:35] <Aavar> Chipaca, Enabled and running it seems. https://paste.ubuntu.com/p/STBbmj24zN/
[10:37] <Chipaca> Aavar: ok, try xbill again please
[10:38] <Aavar> Chipaca, same :(
[10:38] <Chipaca> Aavar: if you want to figure out why, maybe jdstrand can shed some light on it (later in the day, it's early for him to be around)
[10:39] <Chipaca> Aavar: but at this point I'd say your system is fubar
[10:40] <Chipaca> mvo: do you know why core18 still does not include bash completion? i filed the bug ages ago :-(
[10:42] <Aavar> Chipaca, Ok, I will try jdstrand. But I think you are right the system is destroyed. I mostly tried to fix this to learn, but a reinstall is possible too :)
[10:42] <Aavar> Chipaca, thank you for your help :)
[10:45] <mup> Bug #1840244 opened: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>
[10:46] <Chipaca> mvo: I can't reproduce the weird issues in actual core18, fwiw
[10:53] <popey_> Can someone on the snappy team please update https://launchpad.net/snappy
[10:53] <popey_> (the home page link is broken)
[10:53] <popey_> the first link points to https://launchpad.net/snapd which tells you to go to https://github.com/snapcore/snapd
[10:55] <ijohnson> morning folks
[10:56] <ijohnson> Chipaca: when you get time could you give another pass at my `snap model` PR (#7149) ?
[10:56] <Chipaca> ijohnson: yep
[10:56] <mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
[10:56] <ijohnson> thanks
[10:57] <popey_> niemeyer: ^ I don't have access to modify those pages, would be good to make them less messy
[10:58] <Chipaca> I think I can change those
[10:59] <Chipaca> popey_: better?
[11:00] <diddledan> it's still a click followed by another click to get to the snapd github - seems silly to say "go here for snapd" and then on that page it says "go HERE for snapd"
[11:00] <Chipaca> diddledan: only code is on github
[11:01] <Chipaca> diddledan: bugs are on launchpad
[11:01] <Chipaca> for snapd
[11:02] <popey_> <3 Chipaca thanks
[11:02] <Chipaca> ijohnson: what's the status of #6697 btw?
[11:02] <mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
[11:02] <Chipaca> popey_: that was a quick drive-by but maybe degville can look into making it better at some point :)
[11:02]  * diddledan earworms you all: https://www.youtube.com/watch?v=O5HQ1sZseKg&t=93
[11:02]  * Chipaca steps away quickly
[11:03] <diddledan> I've been earwormed by that too hard
[11:03] <ijohnson> Chipaca: it would be good to get zyga's response, but really I'm waiting for jdstrand to comment as apparently there are some problems with my PR that hitherto have been too numerous to comment about
[11:04] <cachio> mvo, hey, about the go-build test, do you know if any change done lastly could affect it to take more time?
[11:15] <pedronis> mvo: re-reviewed #6403, needs a little bit more work I think
[11:16] <pedronis> sorry #6404
[11:16] <mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
[11:16] <mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[11:17] <pedronis> cachio: we are timing out very often now? do we need more workers?
[11:17] <pedronis> or something else
[11:17] <cachio> pedronis, the time outs are realted to the gobuild test
[11:17] <cachio> at least the last timeouts
[11:18] <cachio> pedronis, I am debugging the test to see the time it takes
[11:20] <cachio> pedronis, based on the logs the problem is related to 18.04, I think it should have the same number of workers than 16.04
[11:22] <cachio> pedronis, https://paste.ubuntu.com/p/V7BqpSvVz4/
[11:25] <pedronis> btw it needs tweaking because now we have a couple of libraries in there
[11:26] <mvo> cachio: I think the archive is slower currently for whatever reason so fetching the debs for the building takes a long time
[11:26] <mvo> pedronis: thanks, thats fine, I move it to 2.42 then
[11:26] <cachio> mvo, pedronis based on logs the last system finishing always is ubuntu 18.04
[11:26] <mup> PR snapd#7258 opened: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>
[11:26] <mvo> cachio: I wonder if we can try to use a in-cloud apt mirror (if there is such a thing)
[11:26] <cachio> mvo, pedronis #7258
[11:26] <mup> PR #7258: tests: adding more spread workers for ubuntu-18.04-64 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7258>
[11:26] <mvo> cachio: aha, ok. I probably need to look again then
[11:27] <mvo> cachio: more works is definitely a good idea
[11:27] <cachio> cachio, it is necesary based on the number of tests we are running on that system
[11:27] <pedronis> cachio: don't think it affects time but  we should replace -name \*.go  with -name main.go in that test
[11:27] <pedronis> it's building lib packages atm
[11:27] <pedronis> for no good reason
[11:28] <cachio> pedronis, ah, ok
[11:28] <cachio> let me make that change
[11:28] <cachio> and measure the test time
[11:28] <pedronis> we should make the change either way
[11:28] <pedronis> it's the conceptual correct thing
[11:29] <pedronis> we are just trying to build our commands
[11:29] <pedronis> which are the entrypoints to everything else
[11:29] <cachio> pedronis, makes sense
[11:30] <cachio> pedronis, thanks
[11:31] <pedronis> mvo: #7131 and #7133 need your reviews, the rest is a bit blocked on the red at this point
[11:31] <mup> PR #7131: overlord/devicestate: detect clashing concurrent (ongoing, just finished) remodels or changes <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7131>
[11:31] <mup> PR #7133: overlord,daemon: adjust startup timeout via EXTEND_TIMEOUT_USEC using an estimate <Created by pedronis> <https://github.com/snapcore/snapd/pull/7133>
[11:48] <mup> PR snapd#7209 closed: firstboot: queue service commands before mark-seeded <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7209>
[11:50] <pedronis> mvo: do we need #7257 for 2.41 ?
[11:50] <mup> PR #7257: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
[12:08] <mup> PR snapd#7111 closed: many: support system-usernames for 'snap_daemon' user <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7111>
[12:48] <pedronis> mvo: ^ landed, I have now merged master into and tweaked #7112
[12:48] <mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
[12:50] <mup> PR snapd#7259 opened: tests: just build snapd commands on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
[12:54] <mvo> pedronis: we need 7257 yes
[12:54] <pedronis> mvo: ok
[12:54] <mvo> pedronis: thanks, looking at 7112 now
[12:55] <pedronis> jdstrand: hi, we landed 7111 after some more work,  I reworked a bit 7112 further now
[12:55] <pedronis> jdstrand: one issue to keep in mind for the future was error message style
[12:57] <pedronis> mvo: I marked it for 2.41 (7257)
[12:57] <mvo> pedronis: thanks
[13:23] <pedronis> jdstrand: btw, we need a review for #7254
[13:23] <mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/7254>
[13:23] <pedronis> it's a bug fix that could go in 2.41
[13:24] <jdstrand> pedronis: ack, I'm fixing up PR 7124 for the recent merge and fixups and will move to that after looking at ijohnson's questions
[13:24] <mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
[13:24] <mup> PR snapcraft#2663 closed: elf: handle invalid elf files <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2663>
[13:28] <mup> PR snapd#7258 closed: tests: adding more spread workers for ubuntu-18.04-64 <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7258>
[13:44] <pedronis> mvo: I marked the gadget update ones for 2.41, but let you do the honor of merging it
[13:48] <mvo> pedronis: thank you!
[13:48] <mup> PR snapcraft#2664 opened: cli/clean: handle exception when cleaning a part with a fresh project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2664>
[13:49] <mup> PR snapd#7253 closed: interfaces: remove BeforePrepareSlot from commonInterface <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7253>
[13:50] <ijohnson> thanks jdstrand
[13:52] <mup> PR snapd#7174 closed: overlord/configstate/configcore: allow setting start_x=1 to enable CSI camera on RPi <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7174>
[13:53] <ijohnson> jdstrand: I re-added that attr for docker-support test so I think that's good to merge
[13:53] <ijohnson> mvo, pedronis, if tests are green can I merge #7010 too? or would you rather wait til after 2.41 is cut and put that for 2.42
[13:53] <mup> PR #7010: interfaces/docker-support: add controls-device-cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
[13:55] <mvo> ijohnson: yes, it has 2 +1
[13:55] <mvo> ijohnson: I can do a final check if you want
[13:56] <ijohnson> mvo: no need, I'm sure you have more important things to look at right now :-)
[13:56] <ijohnson> (unless you want to of course)
[14:01] <pedronis> ijohnson: seems the summary and the description will need updating though? it was using an attribute and doesn't anymore?
[14:19] <jdstrand> ijohnson: oh, daemon notify is not on my plate for today (not 2.41), but will look at netplan apply and docker-support
[14:20] <jdstrand> I netplan apply isn't 2.41 either, but still
[14:26] <pedronis> jdstrand: the spread tests in 7124 will need tweaks because of the changes to the error messages
[14:26] <pedronis> in the previous PRs
[14:40] <jdstrand> pedronis: ack
[14:44] <mvo> what was the in-cloud GCE mirror for apt again? I think someone mentioned it but I misplaced the reference :/
[14:48] <Chipaca> mvo: it depends where in gce you are
[14:48] <Chipaca> e.g. europe-west1.gce.archive.ubuntu.com or us-central1.gce.archive.ubuntu.com
[14:48] <Chipaca> etc
[14:48] <jdstrand> ijohnson: fyi, I responded to your feedback in PR 7214
[14:48] <mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
[14:49] <Chipaca> mvo: maybe gce.clouds.archive.ubuntu.com figures it out? (dunno)
[14:50] <ijohnson> jdstrand that's fine no need to review the daemon notify anytime soon
[14:50] <mvo> Chipaca: thanks, that sounds right
[14:51] <ijohnson> thanks for the docker-support and the netplan apply comment
[14:51] <ijohnson> mvo, it looks like we will need to get one more change to upstream netplan apply D-Bus service file
[14:51] <cyphermox> oh?
[14:51] <mvo> ijtthe AssumeAppArmorLabel=unconfined ?
[14:52] <mvo> ijohnson: -^
[14:52] <ijohnson> oh hey cyphermox didn't realize you were here too
[14:52] <ijohnson> mvo yes
[14:52] <mvo> ijohnson: yeah, I think this is why I'm a bit annoyed, IMNSHO this should be the default
[14:52] <cyphermox> ijohnson: asap please, I'm trying to cut a release atm
[14:52] <jdstrand> mvo: you are not the only one
[14:52] <ijohnson> okay, filing PR right now, it's just a single line change
[14:52]  * jdstrand shakes fist at dbus upstream
[14:53] <jdstrand> cyphermox: fyi, https://github.com/snapcore/snapd/pull/7214#discussion_r314333683
[14:53] <mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
[14:53] <pedronis> jdstrand: I did a first pass at 7124 (haven't looked at the spread tests tough)
[14:53] <pedronis> *though
[14:53] <mvo> jdstrand: heh :) can you point me to a bugreport/PR? at least then I can voice my opinion
[14:53] <jdstrand> pedronis: I'm adjusting spread now
[14:58] <ijohnson> alright verified the fix, cyphermox PR is here: https://github.com/CanonicalLtd/netplan/pull/101
[14:58] <mup> PR CanonicalLtd/netplan#101: io.netplan.Netplan.service.in: add assumed apparmor label <Created by anonymouse64> <https://github.com/CanonicalLtd/netplan/pull/101>
[15:02] <cyphermox> cool
[15:07] <ijohnson> cyphermox: oh sorry my local master was out-of-date do you want me to rebase?
[15:07] <pedronis> jdstrand: let me know if you have questions on my comments
[15:08] <cyphermox> ijohnson: no it's all good
[15:08] <ijohnson> cyphermox ack thanks, sorry for the last minute rush
[15:10] <pedronis> mvo: you added --extra-users support to userdel ?
[15:11] <pedronis> what't the status of that
[15:11] <ijohnson> pedronis: I updated the PR title/description on #7010, lmk if you think it needs to be adjusted more
[15:11] <mup> PR #7010: interfaces/docker-support: set controls-device-cgroup spec <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
[15:12] <mvo> pedronis: I did
[15:12] <pedronis> mvo: ubuntu only though?
[15:12] <mvo> pedronis: its available in both bionic and xenial:https://launchpad.net/ubuntu/+source/shadow/1:4.5-1ubuntu2  andhttps://launchpad.net/ubuntu/+source/shadow/1:4.2-3.1ubuntu5.4
[15:13] <mvo> pedronis: yes, its only useful on core anyway
[15:13] <pedronis> ah, yes
[15:13] <pedronis> jdstrand: ^
[15:17] <mvo> pedronis: 7112 LGTM - do you wanto to do the second review or do we need to find someone else?
[15:18] <mvo> (its also green which is a big plus :)
[15:18] <pedronis> I think  if Chipaca gave it a look it would be better
[15:18] <pedronis> given that I tweaked it quite a bit
[15:18] <Chipaca> i can do that
[15:20] <Chipaca> mvo: so
[15:20] <Chipaca> mvo: us-east1.gce.archive.ubuntu.com
[15:20] <Chipaca> mvo: has a ping of .5ms
[15:20] <Chipaca> mvo: from our spread machines
[15:21] <Chipaca> mvo: that's probably the one we want
[15:21] <pedronis> ijohnson: looks alright, 7010 description. I changed the summary a bit again
[15:21] <mup> PR snapd#7087 closed: overlord/devicestate, tests: use gadget.Update() proper, spread test <Gadget update> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7087>
[15:22] <Chipaca> mvo: gce.cloud.a.u.c is ~24ms away so whatever it is, it isn't the one we want
[15:22] <Chipaca> mvo: (that's worse than a.u.c itself)
[15:22] <jdstrand> pedronis: https://github.com/snapcore/snapd/pull/7124#discussion_r314360718
[15:22] <mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
[15:22] <mvo> Chipaca: nice!
[15:22] <mvo> Chipaca: thanks for figuring this out
[15:23] <mvo> Chipaca: I think this will help a lot if we can update our tests to use the gce mirror when inside gce
[15:23] <ijohnson> pedronis: looks good thanks
[15:23] <jdstrand> pedronis: ack that userdel now supports --extrausers (it didn't when I wrote the initial PR 6681 :)
[15:23] <pedronis> jdstrand: thx, that would be ideal
[15:23] <mup> PR #6681: many: support system-users for 'daemon' user <Complex> <⛔ Blocked> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
[15:23] <pedronis> also much cleaner
[15:23] <Chipaca> mvo: also, cloud-id -l | cut -f2 → us-east1
[15:24] <pedronis> jdstrand: also note my comment about user.Lookup* returning Unknown* vs other errors
[15:24] <jdstrand> mvo: does groupdel suppoer --extrausers?
[15:24] <jdstrand> support*
[15:24] <jdstrand> $ groupdel --extrausers foo
[15:24] <jdstrand> groupdel: unrecognized option '--extrausers'
[15:27] <jdstrand> I need groupdel since we necessarily must use groupadd then useradd since useradd with --user-group chooses something from the range in login.defs
[15:27] <jdstrand> pedronis, mvo: ^
[15:28] <jdstrand> but that could be in a followup PR. I can clean up on classic and add a comment for core
[15:28] <diddledan> I still haven't worked out which I should use to add and remove users - adduser or useradd
[15:28] <diddledan> they're not the same...
[15:28] <jdstrand> diddledan: on a Debian-derived system, adduser
[15:28] <jdstrand> it has a nicer interface
[15:28] <pedronis> jdstrand: yes, can leave a TODO, much easier either way if this is encapsulated, vs in snapstate
[15:28] <jdstrand> but isn't portable
[15:28] <jdstrand> pedronis: I understand
[15:29] <jdstrand> diddledan: if you just want it to always work everywhere all the time, useradd, but you have to be careful with it
[15:29] <mvo> jdstrand: uh, oh. ok - it seems like there is some work to do there then :/
[15:29] <mvo> jdstrand: (groupdel --extrausers)
[15:30]  * jdstrand nods
[15:30] <mvo> jdstrand: this is a blocker, yes?
[15:30] <diddledan> gotcha
[15:30] <jdstrand> mvo: no
[15:30] <jdstrand> mvo: I can cleanup on classic, add a todo for core to cleanup when groupdel --extrausers is available
[15:30] <jdstrand> (see Samuele's comment above ^)
[15:31] <Chipaca> mvo, pedronis, #7112 GTG FWIW
[15:31] <mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
[15:31] <mvo> Chipaca: please merge
[15:31] <Chipaca> too late, pedronis did already :)
[15:32] <pedronis> jdstrand: ^
[15:32] <mup> PR snapd#7112 closed: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7112>
[15:32] <jdstrand> \o/
[15:33] <ijohnson> yay
[15:36] <mup> PR snapcraft#2665 opened: Plugin catkin: disable parallel option <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2665>
[16:14]  * cachio lunch
[16:51] <juliank> Is there a way for me to workaround apparmor denials?
[16:51] <juliank> I'm trying to build a blog post, but the hugo snap confinement is borken
[17:14] <ogra> juliank, what kind of denials ...
[17:14] <juliank> ogra: simply /etc/gitconfig https://github.com/gohugoio/hugo/issues/6226
[17:15] <juliank> I switched it to devmode to be able to proceed, but that's suboptimal :D
[17:15] <ogra> juliank, there is a system-files interface that allows read access to such locations, but you need to file a request on the forum for it
[17:16] <ogra> (if you cant just ship git inside your snap and point the app to the in-snap config which would be the usual way to do this without interfaces)
[17:16] <juliank> I don't think it really needs the gitconfig
[17:17] <juliank> it's like doing git describe HEAD or something
[17:17] <juliank> But I was looking for a more confined local workaround than devmode-ing it
[17:17] <ogra> well, you could hack around it by shipping a git binary that simply links to $SNAP/bin/true or some such ...
[17:18] <ogra> if /etc/gitconfig is unavoidable the system-files interfact is the way to go though
[17:19] <ogra> https://forum.snapcraft.io/t/the-system-files-interface/9358
[17:19] <juliank> I was just hoping to hack in /etc/gitconfig into the local apparmor profile I have running while upstream figures out what to do :)
[17:19] <ogra> oh, you could probably also use a layout
[17:19] <ogra> https://forum.snapcraft.io/t/snap-layouts/7207
[17:20] <ogra> i dont think hacking apparmor profiles is an option out of using an interface
[17:20] <juliank> That's all useful for the people doing the snap
[17:20] <ogra> (you can surely do that locally for yourself but would denied store uploads with that)
[17:20] <juliank> But I'm just using it and want to workaround it :)
[17:21] <ogra> ah, then hacking the profile is indeed an option ... i'll hand you over to jdstrand for that one ;)
[17:22] <ogra> the profile shuld be in /var/lib/snapd/apparmor/profiles/
[17:22] <ogra> but i dont know the runes for re-geneating it properly from the top of my head
[17:23] <juliank> ah I can hack that in and then apparmor_parser -r it
[17:23] <juliank> not a permanent solution, but ok
[17:26] <ogra> yeah, as i said, layouts or system-files or shipping your own gitconfig in the snap and pointing the app to it are the ways
[17:28] <ogra> (i'm actually curious what /etc/gitconfig would be ... i have never seen it on an ubuntu system)
[17:33] <ogra> juliank, btw, you can tell the guys to simply set GIT_CONFIG_NOSYSTEM=true in their app launcher in snapcraft.yaml ;)
[17:34] <ogra> that will avoid looking for a (likely non-existent) systemwide git configuration
[17:34] <mup> PR snapd#7255 closed: store: use track/risk for "channel" name when parsing store details <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7255>
[17:34] <juliank> ogra: good idea
[17:35] <mup> PR snapd#7251 closed: packaging: fix removal of old apparmor profile <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7251>
[17:47] <juliank> ogra: I just did
[18:14] <jdstrand> juliank: if you want to modify a profile locally, you can edit the profile for the command in /var/lib/snapd/apparmor/profiles/snap.... then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap....
[18:15] <jdstrand> juliank: not that snapd while undo your change at various times (after reboot, refresh, etc)
[18:15] <juliank> jdstrand: yes thanks, just the path to the profile was enough already :)
[18:15] <jdstrand> note*
[18:15] <juliank> also *will
[18:15] <juliank> but yes
[18:15] <jdstrand> heh, yes, will* :)
[18:15] <juliank> But as ogra pointed out GIT_CONFIG_NOSYSTEM=true, just setting that when launching hugo works just fine too :)
[18:22] <mup> PR snapd#7260 opened: tests: add a runtime scripts generation to generate scripts to call functions <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7260>
[19:07] <mup> PR snapcraft#2666 opened: tests: move meta testing to its own package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2666>
[19:16] <mup> PR snapcraft#2667 opened: yaml utils: move OctInt from meta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2667>
[19:34]  * ijohnson reboots
[20:29] <mup> PR snapd#7261 opened: [WIP] interfaces/serial-port: support pci bus serial-port with Hotplu… <Hotplug 🔌> <Precious Logs> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7261>
[20:59] <mup> PR snapd#7262 opened: tests: use a different archive based on the spread backend on go-build test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7262>
[21:43] <mup> PR snapcraft#2668 opened: Restore cmake artifacts <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2668>
[22:26] <lifeless> morningish :)
[22:27] <lifeless> so I filed https://bugs.launchpad.net/snappy/+bug/1840244 last night, and I'd like to know how to fix it locally
[22:27] <mup> Bug #1840244: docker snap cannot bind mount ssh sockets correctly <Snappy:New> <https://launchpad.net/bugs/1840244>
[22:28] <lifeless> where fix means 'run those components with the global /tmp rather than their own namespace' - as doing a deep integration seems like a snappy long term project goal, and this ia a regression to be fixed vs upstreams regular delivered packaging as a deb or whatever
[22:33] <lifeless> mwhudson: ^
[22:34] <mwhudson> lifeless: pretty sure all snap things run with private /tmp, not there's a quick fix for that
[22:35] <lifeless> ah; theres some reference to a docker-privilege command, but it doesn't seem to exist, and there's no link to the packaging source anywhere that I can see
[22:35] <lifeless> (on https://snapcraft.io/docker )
[22:38] <lifeless> I guess I'll have to bind mount /tmp to /tmp2 or some such
[22:40] <lifeless> how do you disable automatic snapshots on uininstall
[22:40] <lifeless> I don't want an archive of GBs of docker images
[22:41] <mwhudson> there were some forum posts about that sort of thing, i don't remember the details though
[22:41] <lifeless> found it https://snapcraft.io/docs/snapshots
[22:41] <lifeless> To disable automatic snapshots, set the retention time to no:
[22:41] <lifeless> $ snap set system snapshots.automatic.retention=no
[22:42] <mwhudson> i don't think mounting /tmp at /tmp2 will help, will it? needs to be something that gets propagated into the docker snap's mount namespace (and i don't know what that is off the top of my head)
[22:43] <lifeless> I can make /tmp for everyone else be /tmp2 bind mounted to /tmp if I have to
[22:44] <lifeless> but my current plan is to just stop using snappy