[01:04] <mup> PR snapd#4516 closed: spread: setup machine creation on Linode <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
[06:09] <mborzecki> morning
[06:37] <mborzecki> linode:ubuntu-14.04-64:tests/main/snap-service is failing accross diferent PRs, looking into it
[07:04] <mborzecki> well, seems that the test is passing when run manually
[07:19] <zyga-ubuntu> o/
[07:19] <zyga-ubuntu> good morning
[07:26] <mborzecki> zyga-ubuntu: hey, morning
[07:27] <zyga-ubuntu> hey :)
[07:27] <zyga-ubuntu> I just made some warm coffee
[07:27] <zyga-ubuntu> we may have some unusual work to do today
[07:27] <zyga-ubuntu> is mvo around already?
[07:27] <zyga-ubuntu> hey chihchun
[07:27]  * zyga-ubuntu did a nice walk last evening, 5K in the dark and cold of winter
[07:28] <zyga-ubuntu> I didn't anticipate that I could get to so unpopulted areas of warsaw this quickly
[07:35] <zyga-ubuntu> good morning mvo
[07:39] <zyga-ubuntu> mvo: I replied to the thread with jamie now
[07:40] <mvo> hey zyga-ubuntu
[07:40] <mvo> zyga-ubuntu: thank you, checking
[07:40] <mborzecki> mvo: morning
[07:40] <mborzecki> mvo: morning
[07:41] <mborzecki> pff
[07:41] <mborzecki> wrong window :P
[07:42] <mvo> mborzecki: good morning!
[07:50] <mup> PR snapd#4528 opened: cmd/snap: improve `snap aliases` output when no aliases are defined <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4528>
[08:00] <kalikiana> snappy morning
[08:01] <mborzecki> kalikiana: morning
[08:03] <pstolowski> good morning!
[08:03] <mborzecki> pstolowski: morning
[08:49] <zyga-ubuntu>     - linode:ubuntu-14.04-64:tests/main/snap-service fails recently
[08:50] <mup> PR snapd#4512 closed: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4512>
[10:08] <mborzecki> zyga-ubuntu: tried running it separately a coupe of times, but all runs were successful
[10:10] <zyga-ubuntu> mborzecki: it probably needs to be ran in sequence with other tests, using the same random seed
[10:20] <ackk> sergiusens, is https://github.com/snapcore/snapcraft/pull/1617 good for merging?
[10:20] <mup> PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
[10:39] <mborzecki> zyga-ubuntu: reproduced test-snap-service problem
[10:39] <zyga-ubuntu> mborzecki: what do you see?
[10:41] <mborzecki> an ancient systemd :)
[10:42] <mborzecki> zyga-ubuntu: calling reload does nothing, or iow, nothing is logged in the journal
[10:44] <zyga-ubuntu> uh
[10:44] <zyga-ubuntu> 14.04
[10:45] <mborzecki> zyga-ubuntu:   Process: 18961 ExecReload=/usr/bin/snap run --command=reload test-snapd-service (code=exited, status=0/SUCCESS)
[10:45] <mborzecki> and the service is active/running
[10:45] <mborzecki> just that there is no log
[10:49] <mborzecki> same thing after restarting the service
[10:50] <mborzecki> btw. the *.service file looks fine
[10:50] <zyga-ubuntu> any reason it would regress
[10:50] <mborzecki> i'll try something more direct, like kill -HUP $MAINPID and setup a trap in the main process
[10:50] <zyga-ubuntu> it does work sometimes
[10:55] <mborzecki> zyga-ubuntu: https://paste.ubuntu.com/26450449/ seems to work
[10:57] <mborzecki> zyga-ubuntu: https://paste.ubuntu.com/26450461/ notice how there's no long from the reload command
[10:58] <zyga-ubuntu> mborzecki: so was it just a race?
[10:59] <mborzecki> idk why journal is not capturing the reload command output
[11:03] <mborzecki> i'll open a PR and we'll see if this is enough of a fix or not
[11:03] <zyga-ubuntu> thank you
[11:10] <mup> PR snapd#4526 closed: tests: new spread test for gpg-public-keys interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4526>
[11:10] <mup> PR snapd#4529 opened: tests/lib/snaps/test-snapd-service: refactor service reload <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4529>
[11:13] <zyga-ubuntu> hmm
[11:20] <adriens> hi there. I have a problem installing lxd with snap, not sure if the problem is from snap itself or the lxd package
[11:20] <adriens> snap list lxd gives: lxd   2.21     5447  canonical  -
[11:21] <adriens> $which lxd   /snap/bin/lxd
[11:21] <adriens> but $ lxd init
[11:21] <adriens> lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory
[11:24] <adriens> the command "snap run hello"  runs fine, but this app may not need shared libs
[11:29] <adriens> so I just installed chromium and it runs ok, so I guess the problem is within the lxd 'package'
[11:31] <pstolowski> mvo, hey, can #4063 land?
[11:31] <mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
[11:32] <ikey> is jdstrand back?
[11:32] <zyga-ubuntu> ikey: yes, he is
[11:33] <mvo> pstolowski: yeah, I think so, we need to set it to manual: true and cachio needs to integrate it with the spread-daily
[11:33] <ikey> awesome ty
[11:33] <ikey> Can we get some attention on this topic then please? :) https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457
[11:34] <pstolowski> mvo, i see, so i cannot click 'merge' just yet right?
[11:34] <zyga-ubuntu> ikey: I think jamie has some backlog of topics to cover but I'm sure he will look at this as well
[11:34] <ikey> awesome, ty
[11:34] <ikey> basically i just need some basic gotchas so i can get some traction on it
[11:35] <ikey> this whole steam snap thing has been dragging on a really long time now ^^
[11:36] <mvo> pstolowski: better not yet, we need to coordinate with cachio
[11:36] <pstolowski> k
[11:42] <mup> Bug #1667829 changed: console-conf v0.0.5 crashes if no config needed <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1667829>
[12:00] <mup> Bug #1650096 changed: 'snap list' does not show devmode property after disable and re-enable a snap <Snappy:Fix Released> <https://launchpad.net/bugs/1650096>
[12:00] <mup> Bug #1666873 changed: Snap icon is not visible when called from terminal but it does when called from dash <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1666873>
[12:07] <Saviq> niemeyer: hey, when around, things went wrong somehow this morning: https://travis-ci.org/MirServer/mir/jobs/332706784
[12:07] <niemeyer> Saviq: Heya
[12:07] <Saviq> looking at https://travis-ci.org/snapcore/snapd/builds/332735121 - linode is having trouble
[12:08] <niemeyer> Saviq: Checking
[12:10] <niemeyer> Saviq: I think this is an issue on my end actually
[12:11] <Saviq> or that :)
[12:11] <niemeyer> Saviq: Well.. sort of.. the error on the snapd branch does not match the first one, and is a problem on Linode itself
[12:12] <Saviq> yeah they are different
[12:13] <niemeyer> Saviq: I'll look into this
[12:14] <Saviq> tx
[12:16]  * Chipaca returns from the dead
[12:17] <Chipaca> niemeyer: o/
[12:18] <niemeyer> Chipaca: Heya
[12:18] <Chipaca> niemeyer: when can we chat about snapshots?
[12:19] <Chipaca> or when can i read what you've written, if it's written :-)
[12:19] <niemeyer> Chipaca: I want to unblock you, so we can do that now if you have a moment.. I haven't read your forum post yet with all the spreadness yesterday, sorry, but we can catch up live
[12:19] <Chipaca> sure, let me get my earphones
[12:22] <Chipaca> niemeyer: standup h/o?
[12:22] <niemeyer> Chipaca: Yeah, there already
[12:45] <mup> PR snapd#4529 closed: tests/lib/snaps/test-snapd-service: refactor service reload <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4529>
[12:48] <sergiusens> Chipaca how was the highway "from" hell? :-P
[13:01] <Chipaca> sergiusens: rocky
[13:01] <Chipaca> sergiusens: also rolly
[13:03] <Chipaca> niemeyer: forum post updated, give it a once over in case i got it wrong
[13:17] <kalikiana> o/ sergiusens
[13:18]  * kalikiana going to have lunch in ~10
[13:19] <jdstrand> ikey: hey, I am. I've got a todo to respond to your forum post
[13:22] <kenvandine> kalikiana, sergiusens:  when will cleanbuild support building on a bionic base? There's a lxc image available at ubuntu-daily:18.04 already and we have the base-18 snap
[13:23] <ogra_> jdstrand, hey, i was just asked by a customer if we have a hdparm snap (indeed we dont) ... packaging it is less than a 20 lines snapcraft.yaml, but i cant really find an interface that would allow me to not run it in devmode ... do you have any idea ?
[13:24] <jdstrand> ogra_: I'd have to see the denials
[13:24] <ogra_> (devmode works fine as a mometary workaround ... but i fear the audit logging might actually falsify the measuring data)
[13:25] <jdstrand> I presume /dev/[sv]d* and friends
[13:25] <ogra_> jdstrand, this is what i get in devmode on my laptop https://paste.ubuntu.com/26451245/
[13:25] <ogra_> (nvme disk ... )
[13:26] <jdstrand> right nvme
[13:26] <jdstrand> anyway, that would need a new interface. it would obviously be massively powerful
[13:26] <ogra_> not sure why it touches all these loop devices
[13:27] <jdstrand> it is probably deciding that it doesn't need to look at them

[13:27] <jdstrand> I've seen that before with something
[13:27] <ogra_> (this was just hdparm -tT ... i bet there will be a lot other switches needed for the gazillion of options hdparm has)
[13:28] <ogra_> yeah, would be probably a bit over-powered ... raw-blockdevice-access or some such ..
[13:29] <jdstrand> ogra_: I suspect it would be a subset of the udisks2 slot policy
[13:29] <ogra_> ah
[13:29] <ogra_> only a subset ?
[13:29] <jdstrand> well, yeah. it doesn't have a dbus service
[13:29] <jdstrand> probably something like:
[13:29] <jdstrand> /run/udev/data/b[0-9]*:[0-9]* r,
[13:29] <ogra_> oh, udisks2 only comes from the snap ... not inside core
[13:29] <jdstrand> /sys/devices/**/block/** r,
[13:30] <ogra_> i see
[13:30] <jdstrand> /dev/sd* r,
[13:30] <jdstrand> /dev/mmcblk* r,
[13:30] <jdstrand> /dev/vd* r,
[13:30] <jdstrand> (and nvme*)
[13:30] <ogra_> yeah
[13:30] <jdstrand> probably a couple a capabilities
[13:31] <ogra_> thx
[13:31] <jdstrand> then the udev rule to tag all block devices
[13:31] <ogra_> (i might just keep it devmode for now ... after all that works for the moment ... sounds like a bigger project to add such an interface)
[13:32] <jdstrand> anyway, happy to review if you send something up. if you need me to do it, it will be a while (though let me know so I can capture this conversation)
[13:33] <ogra_> yeah
[13:34] <brunosfer> kyrofa: I'm dealing with the Go environment and setting my workspace correctly. However in my Go files I have functions that execute commands to the console such as `sudo snap install name.snap` the problem is that I need sudo privileges and when I do `sudo snapcraft` the Go env paths disappear.
[13:38] <willcooke_> mvo, do you know who can approve membership of the canonical-snapcraft email list?  kenvandine has been pending for a couple of weeks now
[13:42] <zyga-ubuntu> jdstrand: hello
[13:42] <jdstrand> zyga-ubuntu: fyi, https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/56 (not sure you can see comments to merged PRs-- istr people have that issue)
[13:42] <jdstrand> zyga-ubuntu: hey
[13:43] <zyga-ubuntu> jdstrand: I did, I responded to them (though let me recheck)
[13:43] <zyga-ubuntu> jdstrand: if you want I can just disable the whole user/mode part for now
[13:45] <mborzecki> mvo: looks like the license field should be avaialble in the client, but we're just not showing it
[13:46] <jdstrand> zyga-ubuntu: responed via the forum
[13:46] <zyga-ubuntu> jdstrand: I'll do that quickly
[13:47] <zyga-ubuntu> jdstrand: btw, for 4329, do you think this is close to landing?
[13:47] <zyga-ubuntu> mvo will release 2.31 today
[13:48] <jdstrand> zyga-ubuntu: I'm still going through email which includes the responses to my reviews, but my feeling yesterday was, yes, 4329 is close
[13:49] <zyga-ubuntu> OK, I'll get to layouts now
[13:49] <jdstrand> I'm also surprised that 2.31 will be released today. I had a pile of policy updates... :\
[13:49] <mvo> mborzecki: yeah, it seems we also do not store it locally, i.e. when doing "snap info local-snap" the info seems to get lost
[13:50] <jdstrand> ETOOMANYHIGHPRIORITYITEMS
[13:50] <Son_Goku> EPANIC
[13:50] <jdstrand> losing a week to the sprint didn't help either
[13:50] <mborzecki> EAGAIN :)
[13:50] <zyga-ubuntu> mvo: ^^
[13:50] <zyga-ubuntu> mvo: maybe postpone 2.31 for some time?
[13:50] <jdstrand> mvo: hey, willcooke_ mentioned that xdg-settings needed to be in 2.31
[13:51] <brunosfer> Hey guys, can tell me how can I specify in the snapcraft.yaml a package in goland that I created and I need it to go to the GOROOT path into the pkg folder as a *.a lib?
[13:51] <jdstrand> mvo: I reviewed it yesterday and its close. not through email yet (so don't know if you addressed things), but wanted to touch base since 2.31 is imminent on xdg-seettings going into 2.31
[13:58] <mvo> jdstrand: *must* is a strong word
[13:58] <mvo> jdstrand: I have a meeting now but lets chat after that
[13:58] <mvo> jdstrand: there is always 2.32 but yeah, there is some stuff I would love to have in 2.31
[13:58] <mvo> jdstrand: the trouble is that statement is always true however long one waits ;)
[13:59] <jdstrand> mvo: I don't think I said 'must' :)
[13:59] <jdstrand> mvo: sure, willcooke contacted me and said it was critical
[13:59] <mvo> jdstrand: for policy updates I can certainly include it in 2.31~rc2 for example
[13:59] <mvo> jdstrand: today would be ~rc1
[14:01] <mup> PR snapd#4530 opened: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <https://github.com/snapcore/snapd/pull/4530>
[14:02] <jdstrand> mvo: I think I can get a PR up today/tomorrow at the latest. if it doesn't make it, well, it doesn't make it
[14:03] <jdstrand> mvo: I'll look at 4530 today
[14:03] <jdstrand> err
[14:03] <jdstrand> zyga-ubuntu: ^
[14:04] <zyga-ubuntu> jdstrand: thank you
[14:06] <mup> PR snapcraft#1617 closed: Add options to configure applications socket activation <Created by albertodonato> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1617>
[14:10] <jdstrand> zyga-ubuntu: I accidentally approved 4329. please see https://github.com/snapcore/snapd/pull/4329#discussion_r163555093 for the last remaining item
[14:10] <mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
[14:10] <zyga-ubuntu> jdstrand: ack
[14:11] <ogra_> niemeyer, mvo, pedronis has there been any progress at https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 (we'd need it for some customer images)
[14:11] <sergiusens> kyrofa fwiw, `pkg.name not in package_names` is what makes adding libc6 as a stage-packages entry work
[14:30] <kalikiana> re
[14:36] <brunosfer> Does anyone can help me out with a doubt? In the snapcraft.yaml in a part I have `stage-packages: [libbluetooth-dev, bluez]` and I get the error `apt.cache.FetchFailedException: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22`
[14:37] <brunosfer> On Ubuntu Core Raspberry Pi 3 amrhf it works. On Ubuntu core amd64 it doesn't work...
[14:50] <Chipaca> brunosfer: are you running as root or anything like that?
[14:59] <mup> PR snapd#4531 opened: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
[15:00] <Chipaca> niemeyer: did you get a chance to review the updated text about snapshots?
[15:02] <zyga-ubuntu> mborzecki: reviewed
[15:02] <brunosfer> Chipaca: Yes, I do have to run sudo.
[15:02] <Chipaca> brunosfer: why?
[15:03] <brunosfer> Chipaca: Because installing a downloaded snap requires sudo.
[15:03] <Chipaca> brunosfer: no it doesn't
[15:03] <brunosfer> Chipaca: Let me recheck again...
[15:04] <Chipaca> brunosfer: if you're a developer, you can log in (snap login), and then snapd can see your private snaps
[15:05] <Chipaca> brunosfer: if you haven't logged in, it should prompt you for your password to confirm the operation, but not require sudo
[15:05] <Chipaca> brunosfer: sorry, i meant, you can login, in which case it won't ask you for anything, and as a plus it'll see your private snaps
[15:06] <brunosfer> Chipaca: I think we are talking about different things. Let me explain better.
[15:08] <brunosfer> Chipaca: The problem occurres in a ubuntu desktop with the snapcraft tool installed.
[15:09] <mborzecki> zyga-ubuntu: thanks, posted some example output also
[15:09] <zyga-ubuntu> mborzecki: got that, looks good
[15:10] <brunosfer> Chipaca: I have a golang file in my code that executes the cmd line `sudo snap install name.snap` and when I run the snapcraft to build the snap it throws me the error I mentioned before.
[15:10] <mcphail> zyga-ubuntu: saw your forum post about licence files. I'm still very confused about this. Most snaps will have multiple parts and muliple stage-packages, and may have many different licences. Is a single licence field appropriate?
[15:11] <Chipaca> brunosfer: for what it's worth, the "drop privileges" thing is a warning, not an error
[15:11] <zyga-ubuntu> mcphail: yes, the license field is a SPDX expression that can have many many licenses in one thing
[15:11] <Chipaca> brunosfer: but, why do you have a file in your code that does that?
[15:11] <zyga-ubuntu> mcphail: so you can see that an app uses, say, "MIT and LGPL-2"
[15:11] <Chipaca> brunosfer: (the W: before the message means 'warning')
[15:12] <Chipaca> brunosfer: and, the message is from apt, not from snap
[15:12] <mcphail> zyga-ubuntu: so do we dump multiple licences in the meta/LICENSE file?
[15:13] <zyga-ubuntu> mcphail: no, unless those are standard
[15:13] <zyga-ubuntu> mcphail: if you have that MIT and LGPL-2 example you don't need the license text for that
[15:13] <zyga-ubuntu> mcphail: the license text would only apply if you really have a custom license
[15:13] <Chipaca> mcphail: spdx license expressions allow multiple licenses
[15:13] <zyga-ubuntu> mcphail: all licenses known to SPDX are covered by the existing system
[15:13] <Chipaca> you can do license algebra! license matrixes! license eigenvectors!
[15:14]  * Chipaca runs away
[15:15] <Chipaca> mcphail: https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf
[15:16] <mcphail> ok. cheers chaps. However, all MIT licenses (for example) are bespoke to the individual packages and are supposed to be distributed with the copyright line unmodified. How do we cope with that?
[15:17] <mcphail> "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software"
[15:17] <Chipaca> mcphail: you ship the license, just not in meta/
[15:18] <mcphail> Hmm. OK. So there's inevitable duplication there between adding it to the metadata format and shipping the actual licence?
[15:18] <Chipaca> mcphail: or you ship it as meta/LICENSE (was that the file in meta/ we settled on? not sure), but also include license: MIT in the .yaml so the license itself is ignored by the business logic
[15:19] <Pharaoh_Atem> same goes for BSD licenses
[15:20] <Pharaoh_Atem> especially since BSD licenses get kinda weird
[15:20] <mcphail> heh
[15:23] <niemeyer> Chipaca: I had a chance to have lunch! :)
[15:23] <Chipaca> niemeyer: :-)
[15:23] <Chipaca> niemeyer: basically my question is whether the 'just one file' applies to all snaps in a snapshot, or if i should make them per-snap
[15:24] <niemeyer> I'm reading it now
[15:40] <mup> Issue snapcraft#1688 closed: Documentation for advanced grammar for sources <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1688>
[15:46] <Chipaca> niemeyer: poke
[15:47] <niemeyer> Chipaca: Sorry, still working on it (mid other things, appologies)
[15:48] <niemeyer> apologies even
[15:48] <Chipaca> yeah i know things a busy for you right :-)
[15:57] <niemeyer> Chipaca: Sent some initial comments there
[15:58] <zyga-ubuntu> hmm
[15:58] <zyga-ubuntu> tests are not happy
[15:59] <Chipaca> niemeyer: from your comment about the snapshot filename I understand your answer to my question is to have a single snap per snapshot
[15:59] <zyga-ubuntu> seems tests just terminate machines in random places
[15:59] <zyga-ubuntu> niemeyer: ^ perhaps related to new spread allocation
[16:00] <zyga-ubuntu> sample log: https://api.travis-ci.org/v3/job/332828272/log.txt
[16:00]  * kalikiana wishes that one day Google fixes hangout links in notifications to use the right account
[16:00] <niemeyer> Chipaca: That seems slightly more expectable and perhaps nicer to work with
[16:00] <niemeyer> Chipaca: Note we can still draw a line across multiple snapshots by sharing some information
[16:01] <niemeyer> zyga-ubuntu: Looking
[16:01] <niemeyer> zyga-ubuntu: Do you have the URL for the build?
[16:01] <niemeyer> THese files are pretty ugly to look at while raw
[16:01] <zyga-ubuntu> niemeyer: sure https://github.com/snapcore/snapd/pull/4530
[16:01] <mup> PR #4530: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <https://github.com/snapcore/snapd/pull/4530>
[16:02] <zyga-ubuntu> or https://travis-ci.org/snapcore/snapd/builds/332828271?utm_source=github_status&utm_medium=notification
[16:02] <niemeyer> zyga-ubuntu: Okay, and what sholud I look for other than 50 thousand lines?
[16:02] <zyga-ubuntu> niemeyer: look at 1st few error, it seems that the logs are just cut in random places
[16:02] <zyga-ubuntu> niemeyer: as if those machines got axed
[16:03] <zyga-ubuntu> hmm hold on, is that the right build
[16:03] <zyga-ubuntu> sorry, rechecking, too many tabs open
[16:04] <zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification <- here
[16:05] <zyga-ubuntu> we seem to die when installing packges in the first few errors
[16:05] <zyga-ubuntu> not sure what to make of that really
[16:06] <niemeyer> zyga-ubuntu: Yeah, that may be conflicts and two different systems trying to allocate the same machine.. I need to fix that today
[16:06] <niemeyer> zyga-ubuntu: Just restart for now please
[16:06] <zyga-ubuntu> thank you
[16:13] <zyga-ubuntu> niemeyer: is there anything blocking 4471 left?
[16:13] <niemeyer> zyga-ubuntu: I'll have to look at it to be able to ttell
[16:14] <mup> PR snapd#4532 opened: store: use the "publisher" when populating the "publisher" field  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4532>
[16:14] <zyga-ubuntu> ack
[16:20] <mvo> Chipaca: quick question about developer/publisher - should we expose both via the rest api?
[16:21] <mvo> Chipaca: context is that I'm looking at this right now for g-s (minimal fix is in 4532) but it looks like there is a bit more to make this nice
[16:21] <Chipaca> mvo: I fear I'm lacking context
[16:21] <Chipaca> heh
[16:21] <mvo> Chipaca: sorry, so right now it seems in our code we are not super clear when publisher and when developer is used
[16:21] <Chipaca> sergiusens: could you copy mvo on the email about ^ you sent me today?
[16:22] <Chipaca> sergiusens: looks like he's aching to fix the issue :D
[16:22] <mvo> Chipaca: and I wonder if should untangle this properly and always have those two everywhere (rest api, snap.Info etc)
[16:26] <mborzecki> `snap info` output has to be valid yaml
[16:26] <mborzecki> intersting
[16:26] <Chipaca> mborzecki: there's a bunch of TODOs on that still though
[16:26] <Chipaca> mborzecki: but, yes, ideally yes
[16:31] <mborzecki> hmm the core snap does not have the license set?
[16:39] <mvo> mborzecki: it might be that its local and therefore the license get lost
[16:39] <mvo> mborzecki: its labeled in the store as "other open source"
[16:43] <kyrofa> sergiusens, I meant to ask: what priority would you like me to give the load_plugin work? I've still got a chunk of docs to write
[16:43] <kyrofa> sergiusens, shall we create an issue for it and put it on the next milestone?
[16:43] <sergiusens> kyrofa something to do on Friday maybe or when you are on a creative block
[16:43] <sergiusens> kyrofa an issue sounds like a good plan
[16:44] <sergiusens> Chipaca ack
[16:44] <mborzecki> mvo: that's likely it
[16:44] <kyrofa> sergiusens, good call, those happen. I'll make an issue for it
[16:44] <mvo> mborzecki: yeah, I think we just need to store it locally, its store metadata
[16:46] <mborzecki> mvo: looks like a followup PR on #4531
[16:46] <mup> PR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
[16:46] <cachio> mvo, 2.31 is comming today?
[16:46] <mup> Issue snapcraft#1882 opened: Toast load_plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1882>
[16:52] <mvo> cachio: I'm waiting for some PRs to get green
[16:52] <mvo> mborzecki: +1
[16:57] <cachio> mvo, ok, tx
[17:02] <ogra_> if i have an "architectures: [ all ]" snap that is installed on a system and eventually add a binary to that snap (which forces me to change to "architectures: [ foo ]" ... will that snap be upgraded on my syystem ?
[17:02] <ogra_> or would my user have to remove/install manually ?
[17:06]  * ogra_ files https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675
[17:11]  * kalikiana wrapping up for the day
[17:12] <om26er> popey: are you around ?
[17:15] <popey> Ya
[17:16] <om26er> popey: https://github.com/snapcrafters/sublime-text/pull/5
[17:16] <mup> PR snapcrafters/sublime-text#5: Snapcraft yaml cleanup <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/5>
[17:16] <om26er> After that I think we should move that to stable. It has been working perfectly fine.
[17:16] <mup> PR snapd#4533 opened: errtracker: include detected virtualisation <Created by mvo5> <https://github.com/snapcore/snapd/pull/4533>
[17:19] <kyrofa> nacc, did Laney ever get back to you about autopkgtests? I didn't see anything
[17:20] <popey> om26er: i dont think that architectures stanza does what you think it does
[17:20] <popey> om26er: certainly won't stop build from trying to make an i386 snap
[17:31] <om26er> popey: oh, do you know a way to do that ?
[17:32] <om26er> I always thought that would limit the architectures my snap will build on
[17:40] <nacc> kyrofa: nor I
[17:40] <nacc> kyrofa: i'll ping again
[17:44] <popey> om26er: sadly not.
[17:44] <acknack> been pouring over docs and web posts but in hours haven't found an answer to a question:
[17:45] <acknack> what sets the number of revisions kept for a snap?
[17:45] <popey> om26er: https://github.com/canonical-websites/build.snapcraft.io/issues/556
[17:45] <acknack> what or where?
[17:45] <kyrofa> acknack, I believe it's hard-coded in snapd
[17:45] <acknack> ouch.
[17:45] <popey> yeah, i believe so
[17:45] <kyrofa> acknack, why, are you wanting to change it?
[17:45] <kyrofa> (and if so, why?)
[17:45] <acknack> it's apparently > 2
[17:45] <kyrofa> Yeah, it's three
[17:46] <acknack> and i can only go back one revision by the cli?
[17:46] <nacc> kyrofa: looks like it might get re-enabled tmrw
[17:46] <kyrofa> No, you can revert multiple times, or revert to a specific revision
[17:47] <kyrofa> nacc, ah, excellent, thank you :)
[17:47] <nacc> kyrofa: yw
[17:47] <acknack> okay.  being able to revert more than one didn't make an impression during my research
[17:48] <acknack> i can specify a revision to remove. would you believe i was thinking the number of revisions would be configurable not hardcoded because of the VMS filesystem?
[17:51] <kyrofa> acknack, if that's a feature you believe would be helpful, by all means feel free to request it
[17:51] <acknack> specify a specific* revision to manually* remove
[17:51] <acknack> i can see a dev wanting a few revisions around. i was hoping to be tidy and set it to 2.
[17:51] <acknack> the apps are small enough but core is sizable
[17:54] <acknack> k. thanks. i'll have a look at the code.  is there an existing external config file for snapd?
[17:55] <acknack> otherwise, i'm thinking a cli param and a tweak to the systemd stuff which fires up snapd
[17:56] <acknack> "per snap" rev limit would be lovely but overkill, i think, yes?
[17:58] <Chipaca> in an ideal world you could say "call this bit of business logic to decide"
[17:58] <Chipaca> but... no :-)
[18:00]  * Chipaca ~> dinner
[18:01] <acknack> VMS filesystem (and later implementions in other OSes) has a root dir rev limit which is inherited and ability to set per file rev limit. just fyi.
[18:02] <acknack> external config file exists for snapd? yes/no?
[18:35] <acknack> hmm. yes, '42' is the Great Answer.  overlord provides a hook for setting upper rev limit?
[18:36] <mup> PR snapd#4528 closed: cmd/snap: improve `snap aliases` output when no aliases are defined <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4528>
[18:48]  * zyga-ubuntu cooked dinner for the first time in weeks
[18:48] <zyga-ubuntu> ttyl :)
[18:54] <acknack> okay. i surrender. not able to grasp the thread of snapd execution and locate the decision point where 3 revisions are retained when a refresh installs a new revision.
[18:56] <niemeyer> How's travis going folks?
[18:56] <niemeyer> Any issue signs?
[18:58] <niemeyer> I see some good data:
[18:58] <niemeyer> https://usercontent.irccloud-cdn.com/file/N6NEPIKG/image.png
[19:04] <kyrofa> cprov, do you have any docs on what the various ACLs mean?
[19:17] <cachio> ogra_, there?
[19:17] <ogra_> semi :)
[19:18] <ogra_> (but yes)
[19:18] <cachio> ogra_, I have some problems in a test to read from /dev/gpiomem
[19:18] <ogra_> is the interface connected ?
[19:18] <ogra_> iirc thats a brandnew interface
[19:18] <cachio> yes
[19:19] <cachio> even it fails if I do dd if=/devgpiomem
[19:19] <cachio> from the console in the pi2
[19:19] <cachio> and pi3
[19:19] <ogra_> becaue you miss a slash ? :)
[19:20] <ogra_> the device is root owned and 0600 mode ... your script needs to run as root
[19:20] <cachio> the command I run is "dd if=/dev/gpiomem of=/dev/null bs=1024 count=1"
[19:20] <kyrofa> Yeah, would be nice to _not_ need root
[19:20] <ogra_> totally
[19:20] <ogra_> just saying what i see over here :)
[19:21] <ogra_> cachio, does your command run as root ?
[19:21] <cachio> ogra_, this is the output https://paste.ubuntu.com/26453618/
[19:21] <ogra_> ah, it does
[19:21] <ogra_> hmm
[19:21] <kyrofa> ogra_, yeah you're definitely right: https://forum.snapcraft.io/t/raspberry-pi-gpio-as-a-user/3188/2
[19:22] <ogra_> i see the same here ... looks like the device itself blocks
[19:22] <ogra_> ogra@stream:~$ sudo cat /dev/gpiomem
[19:22] <ogra_> cat: /dev/gpiomem: Invalid argument
[19:23] <kyrofa> How odd
[19:23] <cachio> I see the same error running from the snap with the interface connected
[19:24] <ogra_> yeah, its the device for sure
[19:25] <cachio> ogra_, this is executing from the snap
[19:25] <cachio> https://paste.ubuntu.com/26453644/
[19:26] <cachio> If I run the snap using sudo I get the same error "dd: error reading '/dev/gpiomem': Invalid argument"
[19:28] <ogra_> yeah, nothing to do with the snap or the test
[19:29] <ogra_> cachio, thats not a stable image, is it ?
[19:29] <ogra_> (stable doesnt have *any* proper gpio support ... that was only added later)
[19:29] <cachio> ogra_, no, beta image using core from edge
[19:30] <ogra_> but not an edge gadget
[19:30] <ogra_> https://paste.ubuntu.com/26453668/
[19:30] <ogra_> see that
[19:31] <ogra_> i suspect you cant just dump gpiomem without having any gpios exported at all
[19:31] <cachio> ogra_, no, I build the images with ubuntu-image for beta validation
[19:32] <ogra_> and to export gpios you will need at least a gadget with gpio slots
[19:32] <ogra_> which are still only in edge
[19:32] <cachio> ogra_, ok, bad news
[19:32] <cachio> ogra_, is it any way to force it?
[19:32] <cachio> at least to test the interface
[19:32] <ogra_> use an edge gadget
[19:34] <ogra_> note though that i'm not sure thats the actual issue
[19:34] <mup> PR snapd#4524 closed: cmd: remove unused execArg0/execEnv  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4524>
[19:34] <mup> PR snapd#4530 closed: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4530>
[19:35] <zyga-ubuntu> woooot :)
[19:35] <mup> PR snapd#4329 closed:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4329>
[19:36] <cachio> ogra_, ok
[19:37] <cachio> ogra_, I'll continue with another test while I figure out how to make it work
[19:37] <acknack> guess nobody wants to say which source file has the "max 3 revisions retained" decision point. np
[19:37] <acknack> ciao
[19:37] <cachio> ogra_, thaks for the support
[19:37] <zyga-ubuntu> jdstrand: only one PR from my pile left, the rest I have (behind 4471) are just tests
[19:37] <ogra_> cachio, good luck ... i'm also only guessing ...
[19:38] <jdstrand> zyga-ubuntu: cool, and that is inline with my trello card :)
[19:39] <zyga-ubuntu> jdstrand: FYI, I have full unit tests and spread tests for 4471
[19:39] <zyga-ubuntu> jdstrand: I can push those if needed, they are just super long
[19:39] <zyga-ubuntu> and I wanted to show this non-test change doesn't break tests
[19:39] <zyga-ubuntu> and that future just-test changes don't touch functionality
[19:40] <zyga-ubuntu> and that spread tests for both old and new things pass perfectly fine
[19:40] <zyga-ubuntu> all of that is ready and waiting but it makes this into a ~2K review
[19:40] <jdstrand> I'll leave that to your discretion
[19:40] <jdstrand> but glad to hear there are a bunch of tests ready to go
[19:40] <zyga-ubuntu> I think this way is just easier to land
[19:40] <zyga-ubuntu> sure, it's fully tested
[19:41] <zyga-ubuntu> I closed the initial PR because nobody would look at the full lot :)
[19:41] <jdstrand> heh
[19:44] <ogra_> cachio, it might actually be that you need to use mmap or some such to actually access gpiomem
[19:44] <ogra_> and that direct dd'ing wont work at all
[19:45]  * zyga-ubuntu has terrible headahe and wants to EOD now
[19:45] <ogra_> (like you can not directly access /dev/mem)
[19:46] <zyga-ubuntu> (you need to access /dev/mem via /dev/pointer)
[19:46]  * zyga-ubuntu states that was a terrible joke and EODs
[19:47]  * ogra_ ...  zyga-ubuntu > /dev/bed
[19:50] <zyga-ubuntu> tar zyga -f /dev/bed
[19:50] <cachio> ogra_, ok
[19:50] <cachio> that makes sense
[19:52] <zyga-ubuntu> niemeyer: linode broke again
[19:52] <zyga-ubuntu> https://api.travis-ci.org/v3/job/332769269/log.txt
[19:52] <zyga-ubuntu> (very short log)
[19:52] <ogra_> i guess a small c program with a simple "fd = open ("/dev/gpiomem", O_RDWR | O_SYNC | O_CLOEXEC)" might actually work too for the test
[19:52] <zyga-ubuntu> via https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification
[19:54] <mup> Bug #1745214 opened: snapd retains fixed number of snap revisions <Snappy:New> <https://launchpad.net/bugs/1745214>
[20:00] <sergiusens> kyrofa how do I debug a hook?
[20:00] <zyga-ubuntu> for the sake of keeping track, it was all full of 2018-01-24 19:38:47 Cannot allocate linode:fedora-27-64: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout
[20:00] <zyga-ubuntu> I restarted the job now
[20:01] <kyrofa> sergiusens, make it fail and print
[20:01] <kyrofa> sergiusens, otherwise snapd swallows its stdout/stderr
[20:01] <sergiusens> kyrofa just printing enough is good? What if it is a segfault?
[20:01] <kyrofa> sergiusens, note that you can also do `snap run --hook`
[20:02] <sergiusens> kyrofa `snap run --hook` only works it is installed :-)
[20:02] <kyrofa> Ouch, that's a bit more difficult :P
[20:02] <kyrofa> sergiusens, oh, is it an install hook?
[20:02] <sergiusens> kyrofa yeah
[20:02] <sergiusens> kyrofa wait, it is a `configure` hook, but it is triggered on install
[20:03] <kyrofa> Yeah, same effect I suppose
[20:03] <kyrofa> sergiusens, try making it a command instead
[20:03] <kyrofa> Would that work?
[20:03] <sergiusens> kyrofa yeah, I was thinking about that, it probably should, let me double check
[20:04] <kyrofa> It would be cool if snapd grew some sort of `snap install --debug` mode that just printed everything from the hooks
[20:04] <kyrofa> `snap set --debug` as well
[20:10] <ogra_> cachio, there is the devmem2 untility that allows reading of registers from /dev/mem ... if you hack that up to instead open /dev/gpiomem that might work ... https://free-electrons.com/pub/mirror/
[20:10] <ogra_> here is also some general background https://elinux.org/EBC_Exercise_11b_gpio_via_mmap
[20:11] <ogra_> (not pi specific though)
[20:11] <cachio> ogra_, awesome, thanks
[20:11] <sergiusens> kyrofa found the culprit, you will smirk
[20:11] <kyrofa> sergiusens, haha, what?
[20:12] <sergiusens> kyrofa that said, snapcraft#1881 should be ready
[20:12] <mup> PR snapcraft#1881: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>
[20:17] <mup> PR snapd#4534 opened: release: 2.31~rc1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4534>
[20:20] <ogra_> cachio, and sisne i couldnt resist ... https://paste.ubuntu.com/26453965/
[20:20] <ogra_> *since
[20:20] <cachio> ogra_, heheh
[20:20] <ogra_> (classic)ogra@stream:~$ ./gpiotest.sh
[20:20] <ogra_> Memory mapped at address 0x76f79000.
[20:20] <ogra_> Value at address 0x3F200000 (0x76f79000): 0x21200924
[20:20] <ogra_> but i cheated using classic ;)
[20:21] <ogra_> that should be enough to prove that the interface lets you access the device
[20:21] <cachio> ogra_, hehe, let me try it on pi3
[20:22] <ogra_> i simply gepped the addess gpiomem uses from the boot log as you can see ....
[20:22] <ogra_> and tell devmem2 to simply print the content
[20:22] <mup> PR snapcraft#1883 opened: Revert "meta: create XDG_RUNTIME_DIR in wrappers. (#1818)" <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1883>
[20:23] <sergiusens> kyrofa ^ we shouldn't be doing generic workarounds ;-)
[20:24] <kyrofa> sergiusens, hahaha
[20:24]  * kyrofa smirks
[20:25] <sergiusens> kyrofa it is a bit more complex than that, we really need to get rid of `LD_LIBRARY_PATH` and friends
[20:25] <kyrofa> sergiusens, yeah, we're well on our way there I think with the readelf stuff
[20:25] <sergiusens> we end up using mkdir from `core` with libc6 from a future release
[20:26] <kyrofa>  /patchelf
[20:26] <kyrofa> Oh brutal
[20:26] <sergiusens> kyrofa yeah, we just need to be brave enough to enable it for everything ;-)
[20:26] <jamesb192> pythonpath
[20:26] <kyrofa> Yeah I'll admit that's a terrifying proposition
[20:27] <kyrofa> We should do a feature branch and do a call for testing on it alone
[20:27] <kyrofa> But if it worked... dude
[20:27] <sergiusens> it will work
[20:27] <ogra_> you could instead work on something easy and fix https://forum.snapcraft.io/t/avoiding-installation-of-build-dependencies/3665/3
[20:27] <ogra_> :P
[20:27] <sergiusens> I just need tyhicks to find the time to look closely at patchelf and verify it will not be a problem long term
[20:29] <kyrofa> ogra_, no comment
[20:30]  * ogra_ grins
[20:30] <sergiusens> ogra_ that is actually easy to fix; it is hard to test though
[20:31] <ogra_> sergiusens, well, the inability of dpkg and apt to re-locate install paths was the reason for clicks to exist initially :)
[20:31] <ogra_> IIRC
[20:31] <ogra_> (and thus snaps in the end)
[20:31] <sergiusens> kyrofa elopio are we good with snapcraft#1879
[20:31] <mup> PR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
[20:31]  * ogra_ just waits to see fakechroot integrated into snapcraft :)
[20:31] <kyrofa> sergiusens, I was hoping elopio would respond to my questions
[20:32] <sergiusens> ogra_ if `which go` returns something, we use that, if not we check if a build-snaps entry for go exists and if not we default to installing the build-packages entry of go
[20:32] <sergiusens> elopio answer the questions please :-) Also, the doc ;-)
[20:33] <ogra_> sergiusens, well, if i dont have go in "build-packages" but like ... 300 libs ?
[20:33] <ogra_> how do you avoid installing them on the host ... and still are aboe to build your target
[20:33] <ogra_> *able
[20:34] <sergiusens> ogra_ once you want reproduceability you should worry on how you get `go`; it could also be staged through a part (which we already support but  install anyways)
[20:34] <ogra_> well, the request is to avoid installing build deps on the host machine
[20:34]  * sergiusens goes back to manager work and fills in some forms for the rest of the day and tomorrow
[20:50] <zyga-ubuntu> niemeyer: 4471 is green, just saying :)
[20:51] <mvo> cachio: 2.31~rc1 should be available in ~1h or so in edge, not sure if I will still be up then to promote it to beta, if not, freel free to do so yourself!
[20:52] <cachio> mvo, sure, thanks
[20:52] <niemeyer> zyga-ubuntu: I need to break something then!
[20:52] <niemeyer> ;P
[20:52] <om26er> flexiondotorg: Hi! Please merge https://github.com/snapcrafters/sublime-text/pull/6 as well.
[20:52] <mup> PR snapcrafters/sublime-text#6: Change app name to subl <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/6>
[20:52] <mvo> cachio: great, thank you! keen to see/hear how the tests go, especially on the boards :)
[20:53] <zyga-ubuntu> niemeyer: :D
[20:53] <mvo> cachio: but no worries, if its late for you already this can wait until tomorrow
[20:53] <cachio> mvo, I'll start today
[20:53] <mvo> cachio: \o/
[20:53] <cachio> mvo, let's see how it goes
[20:54] <mvo> thanks cachio, I will check mail tomorrow morning then with anticipation :)
[20:54]  * mvo waves and calls it a day
[20:54] <om26er> popey: regarding the 'architectures' stanza, it seems once I removed i386 from sublime' yaml, its only amd64 in dashboard.snapcraft.io -- so it is indeed working.
[21:45] <zyga-ubuntu> om26er, flexiondotorg: commented on sublime-text PR
[21:48] <om26er> zyga-ubuntu: I like that suggestion, will make changes to the packaging tomorrow. Can you share a sample app that uses tracks ?
[21:48] <om26er> well maybe I'll look at LXD' packaging.
[22:02] <zyga-ubuntu> om26er: lxd is one, noise][1 can suggest some as well, probably better than I can
[22:05] <kyrofa> om26er, nextcloud as well
[22:06] <zyga-ubuntu> om26er: note that you need to request tracks to be made server side
[22:06] <zyga-ubuntu> om26er: and I don't remember how this works but I think the 3 track should be default
[22:07] <kyrofa> The default is always `latest`, which is not a pointer, but a track unto itself
[22:07] <zyga-ubuntu> aha
[22:07] <kyrofa> Thus if you want the 3 track and latest track to look the same, you must release to both
[22:07] <zyga-ubuntu> kyrofa: how would you map sublime-text-2 (legacy) and sublime-text-3 into tracks?
[22:07] <zyga-ubuntu> I see
[22:07] <zyga-ubuntu> hmm
[22:07] <zyga-ubuntu> maybe a 2 track is better
[22:07] <zyga-ubuntu> and a latest track for 3
[22:07] <kyrofa> I'd create 2 and use latest for 3
[22:07] <zyga-ubuntu> the versions will convey the rest
[22:07] <zyga-ubuntu> om26er: ^ I agree
[22:08] <om26er> yeah that sounds a fine suggestion.
[22:08] <kyrofa> Then once there's a four you can create a 3 for people who don't want to upgrade
[22:08] <zyga-ubuntu> om26er: and I'd _love_ to use that
[22:08] <zyga-ubuntu> as a paying sublime user :)
[22:08] <kyrofa> However, if people stay on latest, they _will_ upgrade to four if they don't see that you released a 3 track. So you can maintain a standalone 3 track that mirrors the latest track if you want people to install from 3/stable knowing that they'll never update to 4
[22:09] <zyga-ubuntu> kyrofa: I think 4 is faaar away
[22:09] <kyrofa> (too much work in my opinion)
[22:09] <kyrofa> Yeah, it's more about supporting a specific user intent: "I never want 4, just 3" and "Yeah give me the latest thing, oh it's 3, nice"
[22:10] <zyga-ubuntu> kyrofa: btw, do you use sublime text?
[22:10] <kyrofa> Man, I barely started using atom from gedit. I'm so far behind on the editor curve
[22:11] <zyga-ubuntu> kyrofa: try it
[22:11] <om26er> so will we need to get the snap renamed or register sublime-text as new ?
[22:11] <zyga-ubuntu> it's awesome IMO
[22:11] <zyga-ubuntu> it's like atom lost 90% of its weigth
[22:11] <zyga-ubuntu> om26er: ... no idea
[22:11] <zyga-ubuntu> om26er: probably new snap is better now
[22:11] <zyga-ubuntu> and have store side kill the current one
[22:12] <kyrofa> Haha, I'm that far down the curve for a reason: I don't like change very much. I get a setup that pleases me and I use it until it no longer does or something convinces me there's a feature that I must have elsewhere
[22:12] <zyga-ubuntu> kyrofa: sublime + agola color theme (I love green variant)
[22:12] <zyga-ubuntu> kyrofa: don't look then
[22:12] <zyga-ubuntu> kyrofa: if you will look you won't stay on atom
[22:12] <zyga-ubuntu> ;-)
[22:12] <kyrofa> ;)
[22:12] <zyga-ubuntu> kyrofa: sl is an order of magnitude faster and less memory hungry than atom
[22:13] <kyrofa> Will it crash X every other time like atom and chrome do?
[22:13] <kyrofa> (does it use electron is I guess what I'm asking)
[22:13] <zyga-ubuntu> no?
[22:13] <zyga-ubuntu> it never crashed on me
[22:13] <zyga-ubuntu> no
[22:13] <zyga-ubuntu> it's not an electron app
[22:13] <zyga-ubuntu> it's really native and fantastically speedy
[22:13] <zyga-ubuntu> it also auto saves its buffers if you kill your session like I sometimes do so you don't loose any work
[22:13] <om26er> its a GTK app
[22:14] <zyga-ubuntu> yes, gtk though just for the "gimme window" really
[22:16] <zyga-ubuntu> kyrofa: it uses python for plugins
[22:16] <zyga-ubuntu> kyrofa: it has nice simple syntax extension system
[22:16] <zyga-ubuntu> kyrofa: it has it's own place for plugins/extensions (package control)
[22:16] <kyrofa> Hmm, it sounds quite nice indeed
[22:16] <zyga-ubuntu> kyrofa: it can take any python plugins you write
[22:16] <zyga-ubuntu> kyrofa: I switched from vim
[22:16] <zyga-ubuntu> and that says something
[22:16] <zyga-ubuntu> it's really fricking awesome IMO
[22:17] <zyga-ubuntu> kyrofa: and it has docs which I found surprising for most software doesn't have any
[22:26] <mup> PR snapd#4535 opened: interfaces: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4535>
[22:28] <zyga-ubuntu> jdstrand: I'll get it in for ~rc2
[22:31] <cachio> ogra_, it works https://paste.ubuntu.com/26454638/
[22:31] <cachio> it is on pi3
[22:31] <cachio> without classic
[22:32] <jdstrand> zyga-ubuntu: thanks! that one is against master. I'm preparing a PR for 2.31 now
[22:33] <diddledan> new one: https://paste.ubuntu.com/26454647/
[22:33] <diddledan> specifically: Failed to run: /snap/lxd/current/bin/lxd forkmount 30519 /dev/.lxd-mounts/lxdmount_729321534 /root/build_gnome-terminal: Failed mounting /dev/.lxd-mounts/lxdmount_729321534 onto /root/build_gnome-terminal: Invalid argument
[22:34] <diddledan> looks like the lxd snap was refreshed 2 hours ago. possibly it didn't happen cleanly?
[22:35] <diddledan> refreshed by my system:
[22:35] <diddledan> https://www.irccloud.com/pastebin/JdJDT9OU/
[22:39] <zyga-ubuntu> jdstrand: +1
[22:41] <zyga-ubuntu> niemeyer: we have issues with https://github.com/snapcore/snapd/pull/4534 - I restarted it a few times already
[22:41] <mup> PR #4534: release: 2.31~rc1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4534>
[22:41] <niemeyer> zyga-ubuntu: What's happening there?
[22:41] <zyga-ubuntu> niemeyer: this time it aborted all 1620 tasks
[22:41] <zyga-ubuntu> niemeyer: everything:
[22:41] <zyga-ubuntu> 2018-01-24 22:27:11 Cannot allocate linode:debian-9-64: cannot find public IP for linode:debian-9-64 (Spread-5448035)
[22:42] <zyga-ubuntu> 2018-01-24 22:31:06 Cannot allocate linode:debian-9-64: cannot allocate disk linode:debian-9-64 (Spread-5448015): cannot get job details for linode:debian-9-64 (Spread-5448015): empty result
[22:42] <niemeyer> zyga-ubuntu: I'm fixing that one as we speak
[22:42] <niemeyer> zyga-ubuntu: It's still a consequence of the early issue today
[22:42] <zyga-ubuntu> excellent, thank you!
[22:42] <zyga-ubuntu> ack
[22:42] <niemeyer> zyga-ubuntu: Should be ready in a few minutes
[22:44] <diddledan> ok, snap.lxd.daemon.service is failed. already running but failed. restarting thru systemd caused lxd to complain it was already running - systemd thought it wasn't. needed to manually kill lxd processes and then restart the systemd service again
[22:45] <diddledan> working find now
[22:45] <diddledan> fine*
[22:49] <mup> PR snapd#4536 opened: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4536>
[22:49] <jdstrand> zyga-ubuntu: fyi, https://github.com/snapcore/snapd/pull/4536
[22:49] <mup> PR #4536: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4536>
[22:49] <jdstrand> oh heh
[22:50] <jdstrand> zyga-ubuntu: I milestoned that one for 2.31.
[22:53] <zyga-ubuntu> ack
[22:53] <zyga-ubuntu> jdstrand: do you have anything else for https://github.com/snapcore/snapd/pull/4471 ?
[22:53] <mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[22:53] <jdstrand> zyga-ubuntu: no
[22:54] <zyga-ubuntu> ready to approve?
[22:54] <jdstrand> well, it had 3 approvals already. I didn't study all the code bits. if you want me to comment/approve on what I did look at, I can
[22:56] <niemeyer> zyga-ubuntu: Alright, please give it another shot
[22:56] <niemeyer> zyga-ubuntu: The issue was that when these errors happened in the morning, Linode allocated something completely bogus
[22:56] <zyga-ubuntu> jdstrand: I'd love that
[22:56] <zyga-ubuntu> niemeyer: trying
[22:56] <niemeyer> zyga-ubuntu: We had about 90 machines that had no IP even
[22:56] <zyga-ubuntu> uuhh
[22:56] <zyga-ubuntu> cloud is hard
[22:56] <zyga-ubuntu> is linode an openstack or a custom thing?
[22:56] <niemeyer> Software is hard, I suppose :)
[22:57] <niemeyer> Custom thing.. predates OpenStack by.. 20 years? :)
[22:57] <zyga-ubuntu> I spawned one run
[22:57] <zyga-ubuntu> ooh, that explains a lot
[22:57] <zyga-ubuntu> well, I applaud them for running so long :)
[22:57] <niemeyer> Yeah
[22:57] <zyga-ubuntu> though it feels like other clouds are more mature API wise
[22:57] <niemeyer> zyga-ubuntu: I see healthy machines spawning
[22:58] <zyga-ubuntu> niemeyer: some runs of older spread are still in flight
[22:58] <zyga-ubuntu> niemeyer: so they can affect the new runs
[22:58] <niemeyer> zyga-ubuntu: Yeah, this running bill thing is relatively new for them.. the usual business back then was a fixed low monthly price
[22:58] <zyga-ubuntu> but this will stop in ~~30 minutes or so
[22:58] <niemeyer> 23ish, I hope
[22:58] <zyga-ubuntu> yeah, I imagine, lots of "just replace my physical server" customers
[22:59] <zyga-ubuntu> niemeyer: is there any chance you can approve 4471 now? it's my last PR and the blocker for more goodies
[23:00]  * zyga-ubuntu always feels weird when he notices irssi "Day changed" notifications
[23:00] <niemeyer> No, sorry.. my family is having dinner and I'm still here getting tests running smoothly
[23:00] <niemeyer> I need to step out ASAP
[23:00] <zyga-ubuntu> k
[23:01] <niemeyer> If things go well I'll be back in business tomorrow
[23:01] <zyga-ubuntu> enjoy your evening, see you tomorrow!
[23:01] <niemeyer> zyga-ubuntu: Thanks, have a good night you too
[23:01] <niemeyer> zyga-ubuntu: It looks like they all allocated just fine now.. fingers crossed
[23:01] <zyga-ubuntu> yeah, looks good
[23:02] <zyga-ubuntu> I'm looking at "follow" log
[23:02] <zyga-ubuntu> 2018-01-24 23:02:31 Cannot allocate linode:debian-9-64: server linode:debian-9-64 (Spread-5460254) concurrently allocated, giving up on it
[23:02] <zyga-ubuntu> I'll wait till all the other runs shut down and retry if this fails
[23:47] <mup> PR snapd#4326 closed: interfaces/builtin: blacklist zigbee dongle <Decaying> <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4326>
[23:49] <mup> PR snapd#4536 closed: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4536>
[23:50] <zyga-ubuntu> jdstrand: I'm about to EOD but my last request would to enqueue 3963 as I'm inclined to merge and interate upon that whenever you give the green light
[23:51] <zyga-ubuntu> jdstrand: as layouts move to policy topics and I have enough branches to keep reviews busy I was thinking I would look at per-user mounts
[23:51] <cprov> kyrofa: https://dashboard.staging.snapcraft.io/docs/api/macaroon.html#post--dev-api-acl- but it doesn't go in detail each acl. Can you please file a bug in lp:snapstore requesting it ? we will extend the docs.


[04:03] <greg-g> Wait, no dinosaurs allowed? What did they ever do to you?!
[07:09] <bittin> Hello, anyone know if there are a Ubuntu One Client that works for Debian
[08:05] <rtgz> No, the usage of symlinks for "Shared With Me" is evil. If an emblem is applied to some file, then all symlinks of that file will have this emblem. That's ok. The issue is that we cannot apply an emblem to the file that was not handled by Nautilus to us through NautilusFileInfo...
[11:19] <madadam> Hi! Is it possible to add different folders to sync with ubuntuone from the client? Is it possible connect to ubuntu one server via ftp?
[11:24] <aquarius> madadam, it's not yet possible to make different folders sync with Ubuntu One, but it will be for the Ubuntu 10.04 release; we're working on that right now.
[11:29] <madadam> aquarius ok
[11:30] <madadam> but wouldn't be it easier to use ftp^?
[11:34] <aquarius> I don't know if we've looked at ftp in detail. We've thought about other ways of accessing your data, other than through the Ubuntu One client and through the web (for example, webdav), but that's not planned for Lucid. We'd certainly like to do it in the future, though
[13:36] <alecu> hello!
[13:41] <aquarius> hi alecu!
[13:42] <alecu> hi aquarius!
[13:42] <alecu> aquarius, I'm supposed to meet statik around here
[13:42] <aquarius> alecu, he'll be around, but he may not be in yet; not sure what time it is where he is, but I think it's pretty early :)
[13:43] <alecu> aquarius, thanks!
[14:17] <statik> hi alecu
[14:17] <alecu> oh, hi statik!
[14:18] <alecu> I was just about to email you.
[14:42] <urbanape> morning, folks
[14:46] <verterok> hi alecu
[15:00] <urbanape> awooooga
[15:00] <CardinalFang> Desktop+ MEETING BEGINS.  Say 'me' to claim a slice of the stand-up meeting, then take your turn by saying DONE/TODO/BLOCKED.
[15:00] <urbanape> me
[15:00] <jblount> me
[15:00] <CardinalFang> me
[15:01] <vds> me
[15:01] <aquarius> me
[15:02] <rodrigo_> me
[15:02] <teknico> me
[15:03] <urbanape> shall we start?
[15:03] <dobey> me
[15:03] <urbanape> DONE: Submitted the lazr-js-trunk branch, but it failed. I'm not authorised. *sniff*. Created a branch to fix #354174.
[15:03] <urbanape> TODO: Get lazr-js-trunk branch landed, get new-folder-inline-edit branch reviewed and landed, get fix-lp-354174 done and proposed. Listen to more The Bird and the Bee.
[15:03] <urbanape> BLOCK: None
[15:03] <urbanape> jblount, HAMMERTIME
[15:03] <jblount> DONE: Reviewed a branch, learned about email stuff in django needlessly,
[15:03] <jblount> TODO: Review day! Sort MT's web ui issue list into bugs, HR stuff
[15:03] <jblount> BLOCKED: Nope
[15:03] <jblount> CardinalFang: YOU! <insert CardinalFang's ringtone>
[15:04] <CardinalFang> DONE: Added rev attribute on Record type.
[15:04] <CardinalFang> TODO: Make update for desktopcouch to fix pid/port race; it happens more than I thought.  Release d-c 0.6.
[15:04] <CardinalFang> BLOCKED: Visit doctor in 30 min.
[15:04] <CardinalFang> vds, go
[15:04] <vds> DONE: planning and code review, checking sync
[15:04] <vds> TODO: 30 free plans #403941 already started
[15:04] <vds> BLOCKED: nope
[15:04] <vds> aquarius: go go go!
[15:04] <aquarius> ⚀ DONE: work out how music store stuff all fits together
[15:04] <aquarius> ⚁ TODO: make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, some more music store architecture planning; step-by-step guide to what happens during contact sync; write "pipe" to transfer data between two HTTP connections with twisted 9.0; write lazr-js branch; be frustrated with lack of progress
[15:05] <aquarius> ⚂ BLOCKED: music partner
[15:05] <aquarius> rodrigo, rodrigo, no-one like rodrigo
[15:05] <vds> rodrigo_:
[15:05] <rodrigo_> • DONE: XML<->HTML fixes. Face and review duty. Added missing support for regular expressions to evolution-couchdb. Copied latest stable packages from beta PPA to Stable PPA (should we use that?). Packaged evolution-couchdb with patch for regular expressions in beta PPA. More contacts picker work
[15:05] <rodrigo_> • TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine? Look at Canola
[15:05] <rodrigo_> • BLOCKED: no
[15:06] <rodrigo_> teknico: go
[15:06] <teknico> DONE: discussed contact conflicts with thisfred and aquarius, discussed nested contact categories with many people, work on fixing timestamps for Funambol with vds (#399200)
[15:06] <teknico> TODO: finish fixing timestamps for Funambol with thisfred and vds (#399200), finish disabling free phone sync after 30 days (#403941)
[15:06] <teknico> BLOCK: none
[15:06] <teknico> next: dobey
[15:06] <dobey> ☺ DONE: Client backports and verification,
[15:06] <dobey> ☹ TODO: Planning, Infrastructure needs notes, 1.0.3 client release, SRU packages
[15:06] <dobey> ☹ BLCK: None.
[15:06] <dobey> anyone else? Chipaca ?
[15:06] <teknico> aquarius, can't sing underscores? ;-)
[15:06] <Chipaca> me!
[15:06] <rodrigo_> aquarius: you missed the magic work, yeah, which is '_'
[15:06] <aquarius> bah
[15:07] <aquarius> sheer laziness on my part :P
[15:07] <Chipaca> umm... DONE: planning. TODO: planning. BLOCKED: planning.  ;-P
[15:08] <Chipaca> dobey: planning planning planning, planning planning planning. Planning, planning planning planning.
[15:08] <urbanape> It's like he's trying to communicate with us.
[15:08]  * dobey gives Chipaca a scooby snack
[15:09]  * CardinalFang tries to scan it like "Buffalo buffalo...".
[15:09] <Chipaca> CardinalFang: I was trying for "chicken chicken chicken", myself
[15:10] <Chipaca> CardinalFang: as in http://www.youtube.com/watch?v=yL_-1d9OSdk
[15:10] <CardinalFang> Chipaca, mine as in http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo
[15:13] <Chipaca> heh, neat
[15:31] <dobey> clearly, part of the planning needs to allocate time for reading wikipedia entries, and watching youtube videos
[15:32] <statik> "user research"
[15:34] <urbanape> Hmm, standing desk is okay, but I really dig my POÄNG
[15:35] <urbanape> I hate that I can't add a bug from just about anywhere on launchpad.
[15:37] <urbanape> Guess I'll just make some bookmarks.
[15:50] <statik> hi Chipaca, got a minute?
[16:04] <urbanape> rmcbride: any idea if I can/should resubmit my branch to pqm yet?
[16:05] <rmcbride> urbanape: waiting on the RT to get fulfilled
[16:05] <urbanape> k, no rush, just wondering which of my browser tabs I should keep around.
[17:18] <mattgriffin> jj_galvez: so you're running ff 3.5.5 and you're having trouble getting your laptop to connect/register to ubuntuone. It's not on your account list and when you hit the connect button on the applet nothing happens. right?
[17:18] <jj_galvez> mattgriffin: correct
[17:19] <mattgriffin> jj_galvez: ubuntu 9.04, 9.10, or 10.04?
[17:19] <jj_galvez> mattgriffin: 9.10
[17:20] <mattgriffin> jj_galvez: open Applications > Accessories > Passwords & Encryption Keys please
[17:20] <jj_galvez> mattgriffin: opened
[17:20] <mattgriffin> jj_galvez: is there an entry under the "Passwords" tab for "UbuntuOne token..."?
[17:22] <jj_galvez> mattgriffin: no only passwords:login and opening that does not show ubuntuone either
[17:22] <mattgriffin> jj_galvez: ok. 1 min. brb.
[17:29] <mattgriffin> jj_galvez: are you behind a proxy server on your network?
[17:30] <jj_galvez> no proxy, but I am behind a NAT on a private network (standard DSL setup) and my desktop is currently connected to ubuntuone
[17:30] <mattgriffin> jj_galvez: and your desktop is on the same network as your laptop?
[17:30] <jj_galvez> mattgriffin: yes
[17:31] <mattgriffin> jj_galvez: have you altered any of the applet preferences like up/down speed?
[17:32] <jj_galvez> mattgriffin: only to have the icon show all the time
[17:34] <Chipaca> jj_galvez: hi
[17:34] <jj_galvez> Chipaca: Hi
[17:34] <Chipaca> jj_galvez: I'm afraid I missed some of the backlog
[17:34] <Chipaca> jj_galvez: can you do apt-cache policy ubuntuone-client, and copy the output of that into http://pastebin.ubuntu.com, and then paste the url in here?
[17:35] <jj_galvez> Chipaca: sure
[17:35] <Chipaca> (a procedure I will henceforth call "pastebinning" :) )
[17:36] <jj_galvez> here is my pastebin: http://pastebin.ubuntu.com/339363/
[17:38] <Chipaca> jj_galvez: OK, that's correct. One thing to note is that you have the jaunty ppa enabled still, you probbably want to disable that (via system -> admin -> software sources)
[17:39] <jj_galvez> Chipaca: got it, doing that right now
[17:39] <Chipaca> jj_galvez: ok, so, meanwhile: you do have the applet running?
[17:40] <jj_galvez> Chipaca: yes its running and showing a red x
[17:40] <Chipaca> jj_galvez: and when you click on it, it lists "connect", right?
[17:41] <Chipaca> in the dropdown that appears on left click I mean
[17:41] <jj_galvez> Chipaca: yes there is a connect option
[17:41] <Chipaca> jj_galvez: and what happens when you click that?
[17:42] <jj_galvez> Chipaca: nothing that I can tell
[17:42] <Chipaca> jj_galvez: ok
[17:42] <Chipaca> jj_galvez: please open a terminal (applications -> accessories -> terminal)
[17:43] <jj_galvez> Chipaca: opened
[17:43] <Chipaca> d'oh, you know that, for the apt-cache thing :)
[17:43] <jj_galvez> Chipaca: ok
[17:43] <Chipaca> jj_galvez: ok, do: killall ubuntuone-client-applet ubuntuone-syncdaemon
[17:43] <jj_galvez> Chipaca: all dead
[17:44] <Chipaca> jj_galvez: ok, now do: u1sync --authorize
[17:45] <Chipaca> jj_galvez: oh, wait, maybe that's not needed. Hold on.
[17:46] <Chipaca> jj_galvez: but just in case: that opened a browser window, right? after asking you about the keyring?
[17:46] <jj_galvez> Chipaca: nope it's giving me an error and hanging, I'ii pastebin the error
[17:47] <Chipaca> jj_galvez: ok
[17:47] <jj_galvez> Chipaca: http://pastebin.ubuntu.com/339370/
[17:47] <Chipaca> jj_galvez: you don't use networkmanager
[17:48] <jj_galvez> Chipaca: I'm using wicd, on both my desktop and labtop
[17:48] <mattgriffin> jj_galvez: but ubuntu one works on your desktop, right?
[17:48] <jj_galvez> mattgriffin: correct, working fine on the desktop
[17:49] <Chipaca> jj_galvez: unfortunately right now we have a dependency on network manager
[17:49] <rtgz> dobey, I am afraid the fastest thing with $most_favorite_bug is to treat 'Shared With Me' as a special case for directory (you probably hate me by now :) )
[17:49] <rtgz> jj_galvez, you might be running a PPA version on the desktop that has such dependency fixed, you might need to start using ubuntuone PPA for laptop as well
[17:50] <Chipaca> we fixed that dependency?
[17:50] <rtgz> Chipaca, yup
[17:50] <Chipaca> rtgz: by being explicit about it, or what?
[17:50] <rtgz> Chipaca, it continues to work when NM service is unreachable
[17:50] <Chipaca> ah, but that's syncdaemon
[17:50] <Chipaca> hmm
[17:51] <rtgz> Chipaca, the fix is in PPA only, syncdaemon was OK with missing NM, but OAuth part was not fixed in karmic release.
[17:51] <Chipaca> sweet, I didn't know we'd gotten round to it
[17:52] <Chipaca> jj_galvez: sudo add-apt-repository ppa:ubuntuone/beta should do it (note that that is the beta ppa, which is bleedingedger - but you were using it in jaunty anyway)
[17:53] <dobey> Chipaca: there was a bug in oauthdesktop stuff too
[17:53] <dobey> Chipaca: i fixed it right before UDS actually
[17:53] <dobey> rtgz: i'm preparing a stable release right now, which also has that fix
[17:53] <rmcbride> well it's bleeding edge-ish. Packages do get the once over in the nightly PPA before I put them in beta
[17:54] <rmcbride> oh cool
[17:54] <dobey> should be available in SRU probably in the first few days next week
[17:54] <jj_galvez> Chipaca: rtgz : ok I am going to try the update now, update manager wants to do a kernel update as well so It will take a few minutes, I'll come back and let you all know how it goes
[17:54] <dobey> i wouldn't generally recommend people to use the beta PPA
[17:54] <rtgz> dobey, have you browsed my nautilus-extension branch?
[17:54] <Chipaca> dobey: I don't in general :)
[17:55] <dobey> rtgz: skimmed quickly
[17:55] <dobey> rtgz: but i've been busy backporting stuff and working on getting stable release and SRU done
[17:55] <dobey> and will be done with that shortly
[17:56] <rtgz> dobey, okay, is the new code already available, just to make sure that something that is fixed in my branch (there are minor fixes, but still worth including) don't get posponet till next SRU...
[17:56] <dobey> rtgz: we can do another SRU next week
[17:57] <dobey> rtgz: there are several major/critical fixes we need to get out for karmic asap
[17:57] <rtgz> This Christmas: On Ubuntu Channels: SRU week!
[18:19] <Chipaca> 此QQ版本不支持超级群 啊! 郁闷!
[18:19] <Chipaca> I'm not sure what that means, but it sounds serious
[18:19] <Chipaca> (from a bug re ubuntuone)
[18:20] <dobey> i think it means you need to practice your japanese
[18:21] <Chipaca> I've stopped with the languages for a while
[18:50] <dobey> yay
[18:50] <dobey> 1.0.3 tarball done and on the lp page
[18:50] <dobey> now to do the packaging for SRUs
[18:52] <Chipaca> dobey: how comes the spec for tarmac work?
[18:52] <dobey> Chipaca: was waiting to do it after i get the SRUs uploaded, since that's more important
[18:53] <Chipaca> dobey: ok
[18:53] <dobey> Chipaca: but on that note, it looks like rockstar has one of the major things done already
[18:53] <Chipaca> \o/ woo.
[19:13] <jimjimovich> I can't get ubuntu one client to connect anymore, any ideas?
[19:27] <jcastro> dobey: is there a fix for u1 asking the keyring to ask me for a password on every log in?
[19:28] <dobey> jcastro: do you use automatic login?
[19:28] <jcastro> yep
[19:28] <jj_galvez> mattgriffin-afk: Chipaca: rtgz: Thank you all for you help with ubuntuone, after updating to the beta ppa version of ubuntuone my laptop connected and registered and I can now sync correctly :)
[19:28] <dobey> jcastro: change your keyring password to be blank, or don't do automatic login
[19:28] <jcastro> :-/
[19:28] <Chipaca> jj_galvez: awesome
[19:29] <dobey> jcastro: there's nothing we can do in ubuntu one, outside of not using the keyring to store credentials, which is a generally bad idea
[19:29] <Chipaca> jj_galvez: as per dobey's suggestion wrt the beta ppa, unless you're really confortable with it breaking every so often I'd say disable the ppa as soon as the version in ubuntu catches up
[19:30] <dobey> the "version in ubuntu" won't catch up with the beta PPA until lucid :)
[19:30] <Chipaca> jcastro: you could have ubuntuone not start :)
[19:30] <Chipaca> dobey: ppa is still 1.1x vs 1.0x?
[19:30] <jj_galvez> Chipaca: sounds like a good idea, maybe I'll just disable the ppa and pin it for a while
[19:30] <dobey> Chipaca: yes, nightlies/beta are from trunk
[19:31] <dobey> Chipaca: but the stable PPA will be useful for people to add
[19:31] <dobey> Chipaca: by people there i mean karmic/jaunty users
[19:31] <Chipaca> dobey: is that ppa:ubuntuone/stable ?
[19:31] <dobey> Chipaca: yep
[19:32] <Chipaca> dobey: and does that right now have the same fixes as /beta?
[19:32] <dobey> not right now, no
[19:32] <Chipaca> dobey: soon?
[19:32] <dobey> but it will have the new stable releases soon
[19:33] <Chipaca> jj_galvez: so... as per dobey's recommendation as I read it now, remove the /beta ppa, add the /stable one, and as soon as a new version of stable lands, downgrade manually
[19:34] <Chipaca> j_galvez: that would be something along the lines of apt-get install {python-ubuntuone-client,ubuntuone-client{,-gnome,-tools}}=1.0.somethingsomethingsomething (as per the output of apt-cache policy)
[19:35] <jj_galvez> Chipaca: ok so what is the PPA for the stable branch?
[19:35] <dobey> and python-ubuntuone-storageprotocol=1.0.1
[19:35] <dobey> jj_galvez: ppa:ubuntuone/stable
[19:36] <dobey> jj_galvez: you can just edit the current entr{y,ies} and replace /beta with /stable
[19:36]  * Chipaca hugs the ppa:<project>/<ppa name> thing
[19:36] <dobey> s/project/person or team/
[19:36] <Chipaca> dobey: yeah, that
[19:37] <jj_galvez> Chipaca: dobey: Ok so just to make sure I've got it right, disable the beta ppa and enable the stable one, When the new version of u1 lands in the stable branch downgrade to that one, which will be a 1.0x version -- is that correct?
[19:38] <Chipaca> jj_galvez: correct
[19:38] <jj_galvez> Chipaca: got it thanks I'll do that now
[20:20] <jcastro> dobey: is there a bug for autologin and apps someplace that you happen to know about? I notice u1 isn't the only one
[20:20] <jcastro> I'd like to follow along
[20:24] <dobey> jcastro: the keyring thing?
[20:24] <jcastro> it seems that when autologin is enabled nm spams me too
[20:24] <dobey> jcastro: i don't know if there is one filed against keyring or gdm, but gdm is probably the place for it
[20:24] <jcastro> ah ok
[20:24] <jcastro> ta
[20:25] <dobey> jcastro: yes, because autologin doesn't use the password, so it can't unlock your keyring
[20:25] <statik> join #terminator
[20:25] <dobey> jcastro: autologin is insecure. so you might as well just make your keyring insecure too :)
[20:26] <jcastro> yeah, I just don't need the keyring is all, it's my house, if the guy is already in my basement I'm already doomed.
[20:26] <dobey> right
[20:26] <dobey> so just change they keyring password to blank
[20:27] <dobey> and then it will work
[20:27] <jcastro> yeah
[20:27] <jcastro> so I go in there and delete in seahorse
[20:27] <jcastro> but then it prompts me anyway
[20:27] <jcastro> I'll mess with it
[20:27] <dobey> did you delete the keyring, or change the password?
[20:27] <jcastro> deleted it so it would prompt me for a new one
[20:28] <dobey> you might have to log out, delete the file on disk, and then log in
[20:28] <statik> if you open passwords and encryption keys, go to the passwords tab, right click on login, it lets you change the password
[20:28] <statik> i've gotten that to work with autologin before
[20:29] <jcastro> omg, that did it
[20:29] <jcastro> thank you!
[20:31] <dobey> yeah, that should work too
[20:31] <dobey> but deleting in seahorse might be problematic :)
[21:24] <CardinalFang> statik, I have a release/LP question for you.  I think there's a bug in Karmic desktopcouch that is worth fixing.  I've gone back to the rev for karmic and added a commit, and pushed that branch to launchpad.  How should I make that a new tip to work from?  Is that a new "series"?
[21:25]  * statik looks at launchpad
[21:25] <CardinalFang> statik, So far, there is only "trunk" series for d-c.
[21:26] <statik> CardinalFang: dobey would know for sure since he's done it for ubuntuone-client. I think yes, you would fork off a series from the 0.5 release that was in karmic
[21:26] <statik> so you have a place to release 0.5.1 from
[21:26] <dobey> yeah
[21:26] <dobey> branch from the stable revision
[21:27] <dobey> and make a new series in launchpad
[21:27] <dobey> and push the branch to lp:~ubuntuone-control-tower/desktopcouch/stable-0-5
[21:27] <dobey> (and call the series stable-0-5)
[21:27] <dobey> and then link the branch to the series in the lp ui
[21:28] <dobey> i typed all that for nothign!
[21:29] <dobey> CardinalXiminez_: a pox upon your ISP!
[21:29] <dobey> nice
[21:38] <CardinalXiminez_> Sorry, dobey.  What?
[21:39] <dobey> 16:26 < dobey> branch from the stable revision
[21:39] <dobey> 16:27 < dobey> and make a new series in launchpad
[21:39] <dobey> 16:27 < dobey> and push the branch to  lp:~ubuntuone-control-tower/desktopcouch/stable-0-5
[21:39] <dobey> 16:27 < dobey> (and call the series stable-0-5)
[21:39] <dobey> 16:27 < dobey> and then link the branch to the series in the lp ui
[21:40] <CardinalFang> dobey, rawk.  Thanks.
[22:15] <CardinalFang> thisfred, this is my conservative change to karmic's package.  Please eyeball it for me.
[22:15] <CardinalFang> http://bazaar.launchpad.net/~cmiller/desktopcouch/karmic/revision/96
[22:18] <thisfred> CardinalFang: I see nothing wrong with that
[22:19] <CardinalFang> thisfred, thanks.
[22:20] <thisfred> np
[22:21] <CardinalFang> Alright, I have a stable series with signed release tarballs for 0.5.1 and a new 0.6 release with signed tarballs.  I'll harass james_w about new lucid and updating karmic on Moon-day.
[22:21] <CardinalFang> G'night, all.


[01:19] <ianorlin> Replop: for the command line there is smbclient but I personally don't use samba
[01:20] <ianorlin> the -i option would work for the ip adress
[01:24] <holstein> !info gigolo
[01:25] <holstein> Replop: you can add gigolo, which is a nice GUI tool for mounting network shares
[01:32] <Replop> I tried smb4k but didn't got any share mounted.
[01:32] <Replop> trying gigolo now
[01:33] <holstein> Replop: the trick is, you need to mount the share somewhere, or use samba
[01:33] <holstein> !samba
[01:52] <Replop> oh neat
[01:52] <Replop> trying to mount the share lead to headaches , smb4k didn't work as well as advertised , but gigolo did it in 3 clics
[01:54] <holstein> right.. its a nice GUI tool
[01:55] <holstein> for many network shares.. ssh, samba.. ftp.. sftp.. handy
[02:02] <Replop> it showed only one share , the one the file browser had already mounted by not made accessible to terminal
[02:03] <holstein> Replop: you can cd to the location you tell gigolo to mount to..
[02:03] <holstein> or, manually mount
[02:03] <Replop> can't cd smb://host/share
[02:03] <holstein> you cant just "willy nilly" cd to "smb://someip/where-ever"
[02:03] <holstein> Replop: correct
[02:03] <holstein> Replop: you *mount* the share.. then, cd to the mount point
[02:03] <Replop> yeah.
[02:04] <Replop> PCManFM , the default file manager , mount shares to strange places
[02:04] <Replop> in the depths of /run
[02:05] <holstein> Replop: mount where you like, friend
[02:05] <holstein> !mount
[02:05] <holstein> !samba
[02:05] <holstein> Replop: the problem is not where things are mounting..if you want to mount them elsewhere, do so. the issue is that you are not cd-ing to the mounted location
[02:08] <Replop> mounting stuff could be a one clic process
[02:08] <holstein> Replop: sure.. feel free and file a wishlist bug, if you like
[02:08] <holstein> !bug
[02:09] <holstein> Replop: ideally, windows could integrate a tool into the windows operating system to make it easier. or just automatically work
[02:09] <Replop> windows ?
[02:09] <holstein> Replop: i use gigolo, and it seems to work pretty easily, considering, the windows shares never promised i could access them from anything but windows
[02:09] <holstein> Replop: samba
[02:09] <holstein> !samba
[02:10] <holstein> ^ note the "windows" share
[02:10] <Replop> noted
[02:11] <holstein> otherwise, there are many ways to mount network shares in native filesystems that you may find "easier".. though, typically with convinience comes the compromise in security
[02:11] <Replop> well, those shares are actually on a nas running some flavor of linux and using cifs, so I presume I could have done that without samba at all, but this did seem the easiest
[02:12] <Replop> gigolo works great :)
[02:14] <holstein> also, main ubuntu may have tools that automatically try and integrate with windows shares like that "out of the box"
[02:19] <Replop> possibly. but that is an older machine and the main ubuntu distrib was a bit slow
[02:20] <holstein> Replop: sure.. these integrated tools that make it easy, such as providing a method for you to just 'click and mount shares' can be heavier
[02:20] <holstein> Replop: those arguably advanced "nice-ities" are not usually in the ligher distros
[02:21] <holstein> its usually a compromise, though.. between functionality and lightness
[02:21] <Replop> for now, I'm starting from a light base and adding as needed, hoping to don't go too far
[02:21] <Replop> for now, that's ok
[02:27] <Replop> good night
[06:43] <mojo706> since lxle seems to be dead
[06:43] <mojo706> can I get help with booting options when net booting
[06:44] <mojo706> I meant the #lxle channel
[06:44] <mojo706> is there a way when netbooting I could set it not to use the graphical installer?
[06:48] <Unit193> As a rule, we don't support derivatives in here.
[06:55] <mojo706> ok tell me how you would do that in lubuntu
[06:56] <mojo706> Unit193, I will use the same when booting lxle
[06:56] <mojo706> please
[06:59] <Unit193> Sounds like what I said.  And don't add 'ubiquity' to the boot options, by default it boots into a live env, not the installer.
[07:03] <mojo706> so telling me how to add boot options on lubuntu is supporting lxle? how
[07:04] <mojo706> btw its a net install
[07:05] <Unit193> So, not netbooting, but using the mini.iso?  That doesn't have a "graphical" installer exactly, but an ncurses one.
[07:08] <mojo706> no I am net booting
[07:09] <mojo706> I have a PXE server
[07:09] <mojo706> but it gets stuck when trying to load the gui
[07:09] <mojo706> I dont know why
[07:11] <mojo706> Unit193, can you help?
[12:13] <switchtehbeat> how do I change power settings in lubuntu on a laptop/netbook?
[12:13] <switchtehbeat> the screen brightness won't go down for some reason :/
[12:33] <switchtehbeat> anyone?
[12:56] <switchtehbeat> google helped me sort it :)
[13:56] <phillw> switchtehbeat: hi, it's always worth checking on https://help.ubuntu.com/community/Lubuntu/Documentation/FAQ if a solution is not there and you find, please do add it so others can more quickly solve thee issue that you had.
[13:57] <phillw> we can tidy up an entry, just get the instructions on there :)
[16:41] <mhlds> cant find steam in lubuntu software center :s
[16:43] <testdr> mhlds: maybe you try "synaptic" and search for steam
[16:47] <genii> You might need to add multiverse
[17:09] <mhlds> genii how do i do that?
[17:14] <genii> https://help.ubuntu.com/community/Repositories/Ubuntu#Adding_Ubuntu_Software_Repositories
[17:15] <mhlds> thx :)
[17:16] <mhlds> btw. is it any programs like powerdvd to linux? i want to play bluray iso files with the menus and all that
[17:17] <genii> BluRay is problemmatic under linux, unfortunately
[17:17] <mhlds> i see :\
[19:41] <Gatis> Why openbox-themes package was taken away from Ubuntu 14.04 repository?
[19:42] <Unit193> Gatis: https://packages.qa.debian.org/o/openbox-themes/news/20140217T130038Z.html
[19:44] <Gatis> bugs>
[19:44] <Gatis> ?
[19:44] <Gatis> I want to download it how to do it?
[19:48] <Gatis> how to add it to repo
[19:49] <wxl> !info openbox-themes
[19:49] <wxl> !info openbox-themes saucy
[19:49] <wxl> oh fooey
[19:49] <Unit193> wxl: Precise, man, it's old.
[19:49] <wxl> !info openbox-themes precise
[19:49] <wxl> quite old indeed
[19:52] <wxl> well there was a new maintainer in 1.0.2. so that might have been the problem :)
[19:52] <Gatis> So
[19:52] <Gatis> What now?
[19:52] <Unit193> The mail kind of said it, dead upstream.
[19:52] <wxl> oh i didn't see said mail
[19:52] <Gatis> so i shouldn't install it?
[19:53] <wxl> suffice it to say, Gatis, no one is maintaining it. like not for ubuntu. not for debian. not for ANYONE ANYWHERE.
[19:53] <wxl> perhaps a better way to put it is that you CAN'T install it
[19:53] <Gatis> but why would you need to maintain themes?
[19:53] <Gatis> that's pitty
[19:53] <wxl> you could try to track down an old version and install it from source, but you're on your own
[19:53] <genii> It will eat your children and houseplants if you do
[19:53] <wxl> Gatis: because the software the themes run on changes
[19:53] <Gatis> genii, fool
[19:53] <wxl> oh now be nice Gatis
[19:54] <Gatis> wxl, you be nice
[19:54] <Gatis> all of you
[19:54] <genii> I guess i could have not been so snarky.
[19:55] <wxl> genii: i laughed at your obviously not serious comment
[19:55] <Unit193> https://github.com/mulberry?tab=repositories has a couple.