[00:52] <mup> PR snapcraft#3955 opened: onprem store: support new credentials format <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3955>
[02:12] <mup> PR snapcraft#3953 closed: tests: allow local git submodules <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/3953>
[10:19] <mup> PR snapd#12287 opened: many: add firstboot partition role <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/12287>
[10:28] <ogra> soundwave[m], well, yu need to download/install the core20 snap first ...
[10:59] <mup> PR snapd#12288 opened: many: Homedirs on tmpfs <Created by mardy> <https://github.com/snapcore/snapd/pull/12288>
[11:09] <mup> PR snapd#12091 closed: tests/connected-after-reboot-revert: run also on UC16 <Run nested> <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12091>
[11:50] <mup> PR snapd#12289 opened: cmd/snap-seccomp: fix typo in AF_XDP value <Simple 😃> <Created by mardy> <https://github.com/snapcore/snapd/pull/12289>
[14:18] <mup> PR snapcraft#3951 closed: providers: set environment according to directory inside instances <Created by mr-cal> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3951>
[15:05] <mup> PR snapd#12289 closed: cmd/snap-seccomp: fix typo in AF_XDP value <Simple 😃> <Created by mardy> <Merged by mardy> <https://github.com/snapcore/snapd/pull/12289>
[15:25] <mup> PR snapd#12261 closed: gadget: add unit tests for new install functions for FDE on classic <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12261>
[17:11] <mup> PR snapd#12290 opened: testutil: compare unsorted containers nested in maps <Skip spread> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12290>
[18:43] <mup> PR snapcraft#3955 closed: onprem store: support new credentials format <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3955>


[05:45] <mup> PR operator#1076 opened: fix: non-leaders can only view app secrets <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1076>
[06:34] <mup> Issue operator#1077 opened: Extend ops.log to capture warnings <feature> <Created by tonyandrewmeyer> <https://github.com/canonical/operator/issues/1077>
[08:31] <mup> Issue operator#1078 opened: Actions: Setting stdout, stderr in event.set_results results in failed action <Created by SimonRichardson> <https://github.com/canonical/operator/issues/1078>
[10:38] <mup> Issue operator#1078 closed: Actions: Setting stdout, stderr in event.set_results results in failed action, but doesn't say why <Created by SimonRichardson> <Closed by SimonRichardson> <https://github.com/canonical/operator/issues/1078>
[11:00] <mup> Issue operator#1079 opened: collect_*_status and lifecycle events <Created by PietroPasotti> <https://github.com/canonical/operator/issues/1079>
[11:04] <mup> PR operator#1080 opened: make collect-status a lifecycle event <Created by PietroPasotti> <https://github.com/canonical/operator/pull/1080>
[21:08] <mup> Issue operator#1071 closed: [testing] Non-leader unit can set 'app' secret <bug> <harness> <small item> <Created by juditnovak> <Closed by benhoyt> <https://github.com/canonical/operator/issues/1071>
[21:08] <mup> PR operator#1076 closed: fix: non-leaders can only view app secrets <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1076>
[22:38] <mup> PR operator#1081 opened: chore: update framework tests to pass under Python 3.12 <Created by tonyandrewmeyer> <https://github.com/canonical/operator/pull/1081>
[22:46] <mup> PR operator#1081 closed: chore: update framework tests to pass under Python 3.12 <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1081>
[22:48] <mup> Issue operator#1073 closed: Layer object support for log-forwarding as a field <small item> <ops-next> <Created by Kayra1> <Closed by benhoyt> <https://github.com/canonical/operator/issues/1073>
[22:48] <mup> PR operator#1074 closed: feat: expose the ability to set Pebble log targets <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1074>
[22:58] <mup> Issue operator#1062 closed: [testing] ValueError: Secret owner cannot use refresh=True <harness> <small item> <ops-next> <Created by juditnovak> <Closed by benhoyt> <https://github.com/canonical/operator/issues/1062>
[22:58] <mup> PR operator#1067 closed: feat: secret owners do not auto-peek, and can use refresh <harness> <Created by tonyandrewmeyer> <Merged by benhoyt> <https://github.com/canonical/operator/pull/1067>


[00:40] <liuxg> does anyone know how to use snapweb?
[02:01] <mup> PR snapd#1969 opened: Update HACKING.md <Created by niedbalski> <https://github.com/snapcore/snapd/pull/1969>
[02:24] <mup> Bug #1626359 opened: Cannot authorise quotactl syscall <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1626359>
[03:09] <mup> PR snapd#1970 opened: Adds ptrace capabilities to the system_trace interface <Created by niedbalski> <https://github.com/snapcore/snapd/pull/1970>
[03:31] <tachyons> How do I replicate same error message in snap store in local snap review ?
[03:32] <tachyons> In automated review in store , I got follwing error
[03:32] <tachyons> package contains external symlinks: gems/ruby-2.3.1@global, rubies/default lint-snap-v2_external_symlinks
[03:32] <tachyons>  0 Warnings
[03:32] <tachyons>  31 Passes
[03:32] <tachyons> But this error is not appearing in local when I run snap review
[03:47] <elopio> tachyons: install click-reviewers-tools, and then run click-review
[03:47] <tachyons> elopio: already done , But this error is not coming in my local system
[03:48] <elopio> tachyons: then probably the reviewers tool used in the store is not the same version
[03:49] <elopio> tachyons: I think that error means that in your snap you have a symlink to a path outside.
[03:49] <tachyons> elopio: which version should I try , I tried the version in 16.04 as well as trunk in bzr
[03:49] <elopio> you can ls -l in the prime directory to search for the links.
[03:50] <elopio> tachyons: I don't know what's the right version.
[03:51] <tachyons> elopio: yes there are symlinks , but those are not outside snap package
[03:51] <elopio> tachyons: can you paste the ls -l of those two files?
[03:54] <tachyons> wait
[03:54] <tachyons> total 8
[03:54] <tachyons> lrwxrwxrwx 3 tachyons tachyons   86 Sep 21 21:02 default -> /home/tachyons/projects/snappy-playpen/hello-ruby/parts/ruby/install/rubies/ruby-2.3.1
[03:54] <tachyons> drwxrwxr-x 6 tachyons tachyons 4096 Sep 21 21:03 ruby-2.3.1
[03:55] <tachyons> default is symlinked to ruby-2.3.1
[03:57] <tachyons> elopio: Is that fine ?
[03:59] <elopio> tachyons: I think it should be a relative path, not an absolute one.
[03:59] <elopio> when you mount that snap in a system, it will try to find /home/tachyons.
[04:01] <tachyons> elopio: Means I have to write a script to convert absolute path to relative path in build script?
[04:02] <elopio> tachyons: yes. Some other plugins are probably doing the same, but kyrofa is our link man and he's EOD.
[04:02] <elopio> you can send an email to the list.
[04:03] <tachyons> EOD means?
[04:04] <elopio> end-of-day. He's sleeping.
[04:07] <mup> PR snapd#1971 opened: interfaces/builtin: add rcvfrom for client connected plugs to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1971>
[04:09] <tachyons> elopio: Thanks , https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L120 Is this what you meant ?
[04:10] <tachyons> I don't have much idea about python stuff
[04:11] <elopio> tachyons: more like this, I think: https://github.com/snapcore/snapcraft/blob/97742500ac64d44f9251983a7ac93b128901fdfa/snapcraft/plugins/dump.py#L62
[04:12] <elopio> I don't have much idea of this part of snapcraf.t
[04:15] <tachyons> elopio: Thanks :-) , Let me try
[04:40] <mup> Bug #1598657 changed: No error id for username/password error returned from snapd <Snappy:Fix Released by chipaca> <gnome-software (Ubuntu):Fix Released> <https://launchpad.net/bugs/1598657>
[05:51] <mup> PR snapd#1969 closed: Update HACKING.md <Created by niedbalski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1969>
[06:12] <mup> PR snapd#1972 opened: tests: increase timeout for key generation in create-key test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1972>
[06:37] <dholbach> good morning
[06:55] <zyga> good morning
[08:07] <mvo> ogra_: good news everyone! we have what lookds like a working "loadkeys"
[08:15] <tachyons> elopio: Thanks , it is working for files , but directories are not being copied correctly
[08:15] <tachyons> It shows empty directory instead
[08:18] <mvo> ogra_: total cost is ~3mb it seems, not great, not too terrible either
[08:28] <didrocks> mvo: hey, have you seen fgimenez's issue today? It seems that $HOME isn't anymore $SNAP_USER_DATA, but real $HOME, am I correct?
[08:29] <didrocks> (maybe when people adds the home plug?)
[08:32] <mvo> didrocks: I did not see that, that sounds like a regression
[08:33] <didrocks> mvo: yeah, I guess fgimenez can show you an easy reproducer
[08:33] <didrocks> (desktop-launch is using ~/.something) and ~ is expanded to /home/<user>/
[08:34] <fgimenez> didrocks, mvo yep, is in the test snap used in this in progress branch https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, the commands try to open files on ~/
[08:35] <mvo> fgimenez: is that with master?
[08:35] <didrocks> mvo: I did get the issue on a released snapd version on my side
[08:35] <mvo> didrocks: what version?
[08:36] <didrocks> mvo: ah, sorry, I'm wrong, I still have your ppa version :)
[08:36] <didrocks> snapd   2.14.2~16.04+ppa227-1
[08:36] <didrocks> the one with revert --devmode
[08:36] <mvo> didrocks, fgimenez: https://github.com/snapcore/snapd/blob/master/snap/snapenv/snapenv.go#L91 looks correct, let me add a spread test
[08:37] <didrocks> mvo: so, basically, we have here: command: desktop-launch <something>
[08:37] <didrocks> and desktop-launch is doing cat ~/.something
[08:37] <didrocks> and we can see (with the home slot plugged, don't know without that), that ~ is expanded to /home/user
[08:42] <ogra_> mvo, hmm, thats a lot, but you didnt use the d-i bits, right ? just the normal desktop packages
[08:42] <ogra_> i guess using the bits from the udeb would be a lot less
[08:43] <mvo> ogra_: yeah, just the regular packages
[08:43] <mup> PR snapd#1973 opened: tests: ensure HOME is also set correctly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1973>
[08:44] <mvo> didrocks: -^ for you
[08:45] <didrocks> fgimenez: ^
[08:45] <didrocks> mvo: don't you think we could have some special expansion as the use case is slightly different (~ expansion from a command line application wrapped, but started from another shell?)
[08:46] <fgimenez> mvo, didrocks cool thanks a lot
[08:49] <fgimenez> didrocks, in the previous version of the test snap we were exporting HOME and pointing it to SNAP_USER_DATA in the launcher script https://github.com/snapcore/snapd/commit/358fcd544b059fc864cef93af67e7d1e7c3be40c#diff-e2c74cafe2ea8aff71bac730ee1bf0f9R10, wouldn't that have the same effect as HOME being set up from snapd?
[08:49] <mvo> ogra_: hm, just had a quick look, killing python would be huge if we want to reduce the size
[08:50] <mvo> ogra_: vim.tiny is also 1mb, systemd-analyize, perl
[08:50] <didrocks> fgimenez: yeah, but that's not needed, mvo confirms that HOME should already point to SNAP_USER_DATA
[08:50] <morphis__> mvo, ogra_: did you guys release a new beta OS snap?
[08:50] <didrocks> but as we are using ~ expansion, I really wonder if the mvo's test makes sense
[08:50] <ogra_> morphis__, not that i'm aware
[08:50] <morphis__> mvo, ogra_: saw it changing from 526 to 658
[08:51] <mup> PR snapd#1974 opened: snapd: kmod backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/1974>
[08:51] <ogra_> mvo, killing python would get us 10MB snaps :P
[08:51] <didrocks> zyga: see you are approving, but did you read above? ^
[08:51] <ogra_> (yes, i'm exaggerating ... but it would freee a lot)
[08:51] <mvo> ogra_: I think we can kill libstdc++6 from the image, its only needed by apt afaik
[08:52] <morphis__> ogra_: snap prepare-image --channel beta .. gives me 658 now where edge has 695
[08:52] <mvo> ogra_: hm, no, sorry
[08:52] <mvo> ogra_: silly me, we would still have to include it for classic
[08:52] <ogra_> yeah
[08:53] <mvo> ogra_: /usr/share/local/* might be worth a shot
[08:54] <morphis__> mvo, ogra_: any a snap refresh --beta ubuntu-core on my desktop gives me 660
[08:54] <mvo> morphis__: same architecture?
[08:55] <ogra_> mvo, we purge the lcle package at the end of the build
[08:55] <ogra_> *locale
[08:55] <ogra_> that should only be empty dirs
[08:55] <ogra_> ugh
[08:56] <morphis__> mvo: ah right
[08:56]  * ogra_ shakes fist at maintainer scripts
[08:56] <morphis__> mvo: but that still doesn't explain why the armhf one goes from 526 to 658
[08:56] <ogra_> ogra@bbb:~$ du -hcs /usr/share/locale/
[08:56] <ogra_> 7.2M	/usr/share/locale/
[08:56] <ogra_> woah
[08:57] <morphis__> mvo: can you check in the store what should be the latest for the beta channel?
[08:58]  * ogra_ is just looking
[08:58] <ogra_> 656-661 are in bet
[08:58] <ogra_> a
[08:58] <morphis__> beginning of last week I got 526 and now 658
[08:59] <morphis__> ogra_: you see when they were published?
[09:00] <ogra_> well, i didnt release anything to beta ... regarding the date ... http://people.canonical.com/~ogra/ubuntu-core-builds/ (unless they were mnul builds they will show up theere)
[09:01] <mup> PR snapd#1975 opened: tests: add test benchmark script <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1975>
[09:01] <ogra_> hmm, looks like thery were manual :/
[09:01] <ogra_> but i'd say 19th
[09:01] <ogra_> yeah, the store says "2016-09-19 12:25 - 2 days, 20 hours ago"
[09:01] <morphis__> ogra_: wait, we released an upgrade beta snap after the beta announcement?
[09:02] <ogra_> ask mvo ... he handles the beta releases ... but why wouldnt we
[09:02] <morphis__> ogra_: as it breaks stuff
[09:03] <ogra_> well, thts indeed bad, but there is no reason to not release  beta if it doesnt :)
[09:03] <ogra_> whaat does it break ?
[09:04] <morphis__> ogra_: there is no reason against that but you easily miss that if you nowhere get an announcement for that or so
[09:04] <morphis__> ogra_: however, console-conf seems to be updated and now doesn't work anymore with our manually put in place ifupdown config
[09:05] <morphis__> mwhudson: ping
[09:05] <ogra_> oh ? are you sure ?
[09:05] <ogra_> you mean you define a fixed IP and dont get that IP ?
[09:06] <ogra_> or what does not work ?
[09:06] <ogra_> (note that the device comes up automatically before console-conf ... systemd-networkd default to try DHCP)
[09:06] <ogra_> *defaults
[09:06] <morphis__> ogra_: address assignment works well, the box gets the IP via dhcp and is manged by ifupdwon but console conf still complains that "network cofngiuration failed"
[09:07] <morphis__> it shows the detected IP configuration which ifupdown put in place
[09:07] <morphis__> ogra_: no networkd here,
[09:07] <mvo> morphis__: it breaks stuff?
[09:08] <morphis__> mvo: console-conf has a regression somewhere
[09:09] <mvo> morphis__: right, thats (obviously) bad did you talk to mwhudson about it yet?
[09:09] <morphis__> and actually I was expecting beta to stay the same until we have the next announcement for an updated beta release or so
[09:09] <morphis__> mvo: just ping'ed him
[09:09] <mwhudson> hi
[09:10] <mvo> morphis__: there was an anncounement: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html
[09:10] <morphis__> oh ...
[09:10] <morphis__> my bad then that I missed that .. sorry :-)
[09:11] <mvo> no worries
[09:11] <morphis__> mwhudson: hey!
[09:11] <mwhudson> er is it possible to figure out the console-conf versions in the good and bad versions?
[09:11] <morphis__> mwhudson: let me first explain the problem I see right now
[09:12] <mvo> morphis__: I'm keen to learn more why this makes you concerned. it seems the fact that we spot the regression is a reaosn to release betas more often so that we find the bugs sooner (rather than later). but lets talk after the console-conf issue got debugged
[09:12] <morphis__> mvo: my only conern was because I missed the announcement
[09:12] <morphis__> so releasing to beta more often to fix bugs is fine for me
[09:13] <morphis__> mwhudson: so the problem I have right now is the following:
[09:13] <morphis__> mwhudson: we can't really use networkd here as it just fails badly on our 3.4 kernel
[09:13] <morphis__> mwhudson: to workaround this (its just a proof-of-concept) we put a config file into /etc/network/interfaces.d which configures the ethernet port via dhcp
[09:14] <mwhudson> morphis__: 3.4!!
[09:14] <morphis__> mwhudson: with the previous beta release console-conf was ok with accepting whatever ifupdown assigned to the interface and just let us go through the process
[09:15] <morphis__> mwhudson: now with the second beta release it shows the IP address ifupdown assigned but fails with "Network configuration failed; please verify your settings" when trying to proceed with the wizard
[09:15] <morphis__> mwhudson: yeah, 3.4
[09:16] <mwhudson> morphis__: ok, hm, so i'm not really sure why that would have changed, but i can't remember how old the old beta was
[09:16] <mwhudson> morphis__: can you get at the logs by pulling an sd card or activating a debug shell or something?
[09:16] <morphis__> mwhudson: yes, I am already doing that
[09:17] <mwhudson> morphis__: pastebin /var/log/console-conf/subiquity-debug.log pls
[09:17] <mwhudson> (filename might not be quite right)
[09:18] <morphis__> mwhudson: hm, there is no console-conf log
[09:19] <mwhudson> morphis__: nothing in /var/log/console-conf at all?
[09:19] <morphis__> nothing
[09:19] <mwhudson> special
[09:19] <morphis__> https://paste.ubuntu.com/23215029/
[09:19] <mwhudson> morphis__: initramfs?
[09:19] <morphis__> yeah, can't get into the system otherwise
[09:19] <mwhudson> oh right
[09:20] <morphis__> this is flashed on the internal flash memory
[09:20] <mwhudson> that doesn't look like a system that's booted a snappy image?
[09:20] <mwhudson> does it?
[09:20] <mwhudson> maybe, i can't remember how all this works
[09:21] <morphis__> ah
[09:21] <morphis__> mwhudson: my fault, found the log file
[09:21] <mwhudson> morphis__: isn't it going to be /root/writable/system-data/... or something?
[09:21] <morphis__> https://paste.ubuntu.com/23215037/
[09:22] <morphis__> 09/22 09:10 subiquitycore.utils:130 run_command returning: {'err': 'Error in network definition //etc/netplan/00-snapd-confi
[09:22] <morphis__> g.yaml line 9 column 6: p2p0: No access points defined\n', 'status': 1, 'output': ''}
[09:22] <mwhudson> oh
[09:22] <mwhudson> i've fixed that bug
[09:22] <mwhudson> morphis__: can you try edge ubuntu-core?
[09:22] <morphis__> so console-conf does not put any configuration in place and then netplan fails to apply that
[09:22] <morphis__> mwhudson: sure
[09:23] <mwhudson> i misunderstood a bit what netplan accepted
[09:24] <mup> PR snapd#1944 closed: many: validate refreshes against validation assertions by gating snaps <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1944>
[09:24] <morphis__> mwhudson: ah :-)
[09:24] <morphis__> mwhudson: and another one where I saw a crash of netplan: https://paste.ubuntu.com/23215041/
[09:26] <mwhudson> morphis__: looks like the same thing on first blush
[09:27] <morphis__> mwhudson: see the: AttributeError: 'BackgroundProcess' object has no attribute 'proc'
[09:28] <mwhudson> morphis__: oh, i fixed that too
[09:28] <mwhudson> (without really understanding it :/)
[09:28] <morphis__> great :-)
[09:28] <morphis__> lets see how edge goes
[09:30] <morphis__> mwhudson: ah, works again!
[09:31] <mwhudson> morphis__: hooray, sorry for the bugs
[09:33] <morphis__> mwhudson: no problem :-)
[09:35] <mup> PR snapd#1976 opened: tests: skip some tests on non-amd64 architectures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1976>
[09:36] <morphis__> mvo: is there an easy way how I can programatically determine the OS snap revision in a channel?
[09:37] <morphis__> mvo: or via the snap command
[09:40] <ogra_> only the installed snap version
[09:41] <ogra_> and for the non-manually built snaps you can look up the info at http://people.canonical.com/~ogra/ubuntu-core-builds/
[09:41] <ogra_> (i havent added manifests and changelogs yet ... that a weekend project)
[09:41] <ogra_> *that's
[09:42] <morphis__> :-)
[09:42] <pedronis> morphis__: there's no command for that atm, you can query the store directly though
[09:42] <morphis__> looks like I can abuse snap download --edge ubuntu-core for that
[09:43] <morphis__> pedronis: you have a link to the store API?
[09:43] <ogra_> i think you can also just check for upgradeability ...
[09:43] <pedronis> morphis__: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Details
[09:43] <morphis__> thanks
[09:44] <ogra_> snap refresh --list
[09:44] <ogra_> that shows if there is a newer core
[09:45] <ogra_> "snap refresh --list --beta" actually :)
[09:46] <pedronis> --list doesn't take channels atm
[09:46] <pedronis> I think
[09:47] <ogra_> ogra@bbb:~$ snap refresh --beta --list
[09:47] <ogra_> error: --list does not take mode nor channel flags
[09:47] <ogra_> yeap ... looks like you know the error msg :)
[09:48] <pedronis> morphis__: something like this:  curl -H "X-Ubuntu-Series: 16" -H "X-Ubuntu-Architecture: amd64" https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=edge
[09:48] <ogra_> but if the image is baseed on beta it will show the beta channel snaps i suppose
[09:48] <morphis__> pedronis: thanks!
[09:49] <pedronis> ogra_: yes
[09:49] <pedronis> is just that if things are up-to-date
[09:49] <pedronis> it will just say they are up to date
[09:49] <ogra_> yeah
[09:50] <ogra_> but you could turn off auto-refresh ... and then have a script to check with the above command before you decide to upgrade
[09:51] <ogra_> (and first look up the changelog before you decide upgrdaing wont break your hacked up setup ;) )
[09:52] <ogra_> thats probably better than having it auto-refresh over night and being greeted with a bricked device :)
[10:04] <mup> PR snapd#1972 closed: tests: increase timeout for key generation in create-key test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1972>
[10:14] <pitti> ogra_: did you strace -tt console-conf --help? does python3 --help also take that long?
[10:14] <pitti> ogra_: i. e. is that really just python itself, or something specific to console-conf?
[10:14] <pitti> (some expensive import or what not)
[10:14] <ogra_> pitti, sorry, i had a ton of distracting things today, u'll get to the strase soon
[10:14] <pitti> I cannot imagine that python takes an effing 20 seconds to start -- the hardware can't be *that* slow
[10:15] <ogra_> *i'll get to the strace ...
[10:15] <pitti> ogra_: no hurry, just overheard it on the ML
[10:15] <pitti> it was more like curiosity/disbelief
[10:15] <pitti> I cannot imagine that this can just  be attributed to hw slowness; there must be some bug somewhere
[10:15] <pitti> maybe the RNG hits again :)
[10:16] <ogra_> pitti, it has always been like that on embedded arm if you say python in a channel wheer mebedded people work you get laughed at ... single core arm and python have never gone well together
[10:16]  * pitti saw several long startup delays due to that recently, like bug 1622893
[10:16] <mup> Bug #1622893: NetworkManager takes very long to start, or times out, blocked on RNG <amd64> <apport-bug> <bootspeed> <regression-release> <yakkety> <Auto Package Testing:Fix Released by pitti> <gnutls28 (Ubuntu):Triaged> <network-manager (Ubuntu):New> <https://launchpad.net/bugs/1622893>
[10:17] <pitti> ogra_: well, we've run apport on arm stuff for a long time, and while that's certainly expensive, it didnt take multiple seconds to start..
[10:17] <ogra_> (this is why micropython exists)
[10:18] <ogra_> pitti, we have always disable apport on devices like this ... we use apport on desktop class devices like phones, sure ... but on the old arm images it has always been disabled
[10:18] <ogra_> (we never ran long-running python processes on the arm devboard images)
[10:19] <ogra_> technically what we'd want would be https://micropython.org/ packaged in ubuntu-core ... instead of python3
[10:25] <ppisati> where can i open a bug against ubuntu-image?
[10:25] <ogra_> https://bugs.launchpad.net/ubuntu-image
[10:35] <frederikkunze> Hello, i tried to flash Snappy on a Raspberry 3 but it ended in being stuck in the gpu-check screen of the raspi. I did read that the problem exists since a few month is there any solution for it? I could not find any.
[10:56] <Son_Goku> morning all
[11:04] <mup> PR snapd#1977 opened: interfaces/builtin: add netplan-observe interface <Created by morphis> <https://github.com/snapcore/snapd/pull/1977>
[11:18] <mup> PR snapd#1965 closed: asserts: support for maps in assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1965>
[11:39] <zyga> didrocks: didrocks I'm sorry, was this about $HOME?
[11:49] <ppisati> $ cat pi2-tvoss.model | grep kernel
[11:49] <ppisati> kernel: ubuntu-raspi2-kernel
[11:50] <ppisati> $ sudo /snap/bin/ubuntu-image --extra-snaps ./ubuntu-raspi2-kernel_4.4.0_armhf.snap -c beta -o pi2-tvoss.img pi2-tvoss.model
[11:50] <ppisati> $ unsquashfs -l ubuntu-raspi2-kernel_4.4.0_armhf.snap
[11:50] <ppisati> ...
[11:50] <ppisati> squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep
[11:50] <ppisati> squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep.bin
[11:50] <ppisati> ...
[11:51] <ppisati> notice the version: 4.4.19-xenial_raspi2+
[11:51] <didrocks> zyga: correct
[11:52] <ppisati> $ unsquashfs -l /media/flag/writable/system-data/var/lib/snapd/snaps/ubuntu-raspi2-kernel_x1.snap
[11:52] <ppisati> ...
[11:52] <ppisati> squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.builtin
[11:52] <ppisati> squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.order
[11:52] <ppisati> ...
[11:53] <ppisati> 4.4.16
[11:53] <ppisati> so it's using a different kernel, and not the one i'm passing on the command line
[11:53] <ppisati> can anyone explain why?
[12:01] <Mirv> are you all on Rocket chat too or should I generally use IRC more?
[12:03] <Son_Goku> zyga: ping
[12:04] <Mirv> Mr. Newbie just has stupid questions
[12:07] <zyga> Son_Goku: hello
[12:07] <zyga> Son_Goku: what's up?
[12:07] <Son_Goku> you're alive!!!
[12:07] <Son_Goku> I've not heard from you nearly all month
[12:07] <zyga> Son_Goku: yes, though my back hurts all day lately :/
[12:07] <Son_Goku> :(
[12:07] <Son_Goku> what happened?
[12:08] <zyga> Son_Goku: back? just the way it is, weather, more work
[12:08] <zyga> Son_Goku: test-snapd-tools
[12:08] <zyga> hmm
[12:08] <zyga> https://plus.google.com/+ZygmuntKrynicki/posts/fPj5PaDFbgk
[12:08] <zyga> that's better
[12:08] <zyga> that's why I was quiet for a while
[12:08] <zyga> remember that "small thing I need to do in snap-confine", well that too NaN minutes to do
[12:09] <Son_Goku> jeez
[12:09] <zyga> Son_Goku: I could use a hand with designing one thing
[12:09] <Son_Goku> hm?
[12:10] <zyga> Son_Goku: we'll have to release snapd once again (hopefully today) before this is doable
[12:10] <zyga> Son_Goku: but I could use a hand with /snap migration
[12:10] <Son_Goku> yes
[12:10] <zyga> Son_Goku: I realized that this is more tricky than initially assumed
[12:10] <zyga> Son_Goku: all snap services need to be stopped
[12:10] <zyga> Son_Goku: all units unmounted
[12:10] <Son_Goku> oh dear
[12:10] <zyga> Son_Goku: all units adjusted
[12:10] <zyga> Son_Goku: all units renamed as systemd requires that the file name matches the internal path
[12:10] <Son_Goku> it's essentially the same as doing an offline update
[12:10] <zyga> Son_Goku: totally
[12:11] <zyga> Son_Goku: and it's very explosive, I was just wondering how to even attempt that and test it sensibly
[12:11]  * Son_Goku has flashbacks to UsrMove
[12:11] <zyga> Son_Goku: my current plan is to use VM snapshots
[12:11] <zyga> Son_Goku: and just code this defensively
[12:11] <zyga> Son_Goku: and iterate a while until I feel it's good
[12:11] <Son_Goku> probably an okay idea
[12:11] <zyga> Son_Goku: this is obviously just for COPR
[12:11] <zyga> Son_Goku: but it has to be there first
[12:12] <zyga> Son_Goku: once copr is moved the rest is easy
[12:12] <Son_Goku> well, for copr, it might not be as horrible as you think
[12:12] <zyga> Son_Goku: if you have a VM handy I could use you do do some reviews and test migrations
[12:12] <Son_Goku> you can move everything, and just create a symlink to /snap -> new location
[12:12] <zyga> Son_Goku: ohhhh
[12:12] <zyga> Son_Goku: hmm D:
[12:12] <zyga> well, see, why didn't I think of that :D
[12:12] <Son_Goku> that's what we did for UsrMove
[12:13] <zyga> so still stop-the-world
[12:13] <zyga> do a symlink
[12:13] <Son_Goku> yep
[12:13] <zyga> perhaps rewrite state.json (need to check)
[12:13] <zyga> and bring it up
[12:13]  * zyga ponders
[12:13] <zyga> but how is the symlink useful then?
[12:13] <Son_Goku> and I *think* this can also be conditionalized as a %pretrans that occurs only if older versions of snapd are detected
[12:13] <zyga> apart from, maybe, just $PATH being still valid
[12:13] <zyga> nah, thats irrelevant, I would keep this in COPR forever and stop updating it
[12:14] <Son_Goku> ah
[12:14] <zyga> Son_Goku: all subsequent updates would be in the repo
[12:14] <Son_Goku> right
[12:14] <Son_Goku> so you'd probably still want to apply a migration to all units and whatnot
[12:14] <zyga> yes, I have to
[12:14] <zyga> everything
[12:14] <zyga> actually
[12:14] <zyga> it might be easier to say this
[12:14] <zyga> the migration removes all snaps
[12:14] <zyga> and re-installs them
[12:14] <zyga> keeping data (that could be a hack)
[12:14] <zyga> well, no I still need
[12:14] <zyga> man this is complex
[12:15] <zyga> ...
[12:15] <zyga> lots of moving parts
[12:15] <Son_Goku> no one ever thought this might be a problem, which is extraordinarily surprising, given Ubuntu's upstream?
[12:15] <zyga> ?
[12:16] <zyga> moving stuff around is hard when it is live
[12:16] <Son_Goku> the /snap path is a violation of Debian Policy
[12:16] <zyga> that's why I'd rather not do it but that cat is out of the bag
[12:16] <Son_Goku> so I was surprised that you guys even did it that way to begin with
[12:16] <zyga> well, /magic would be too because that's a new thing. doesn't mean that policy is set in stone :)
[12:16] <Son_Goku> well, it tends to be
[12:17] <zyga> if that were the case /etc would still ship executables
[12:17] <Son_Goku> I've not seen Debian Policy change significantly in the last decade or so
[12:17] <zyga> and we'd be using vms or something
[12:17] <Son_Goku> haha
[12:17] <zyga> well, back to earth, I'll draft a migration script and share it
[12:17] <Son_Goku> right
[12:17] <zyga> I'm coming back to the light, I hope :)
[12:17] <Son_Goku> I hope so too
[12:18] <Son_Goku> we were nearing the "DEADREVIEW" state for all the stuff
[12:18] <zyga> (yesterday, when I had to do some stuff away from home office I obviously had to break all of yakkety)
[12:18] <Son_Goku> :)
[12:21] <Son_Goku> mass rebuilds are good for the soul
[12:37] <mup> PR snapd#1978 opened: interfaces/builtin: network-manager: allow access to netplan conf files <Created by morphis> <https://github.com/snapcore/snapd/pull/1978>
[12:46] <mup> PR snapd#1979 opened: assertions: add system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/1979>
[13:03] <ogra_> ppisati, have you tried -c edge instead ?
[13:32] <sergiusens> Mirv the snapcraft team is on rocket, the snapd team isn't that is why you see kyrofa sometimes on or off
[13:32] <kyrofa> Hahaha
[13:32] <sergiusens> Mirv that said, I am the only snapcraft person dedicating day and night to it ;-)
[13:34] <Mirv> ok :)
[13:50] <ogra_> Mirv, all teams are kind of on IRC though
[13:50] <ogra_> (reply times are sometimes slow since we started fragmenting everything across all possible chat tools though)
[13:59] <Harshil> hello
[13:59] <Harshil> I have a lenovo x201
[13:59] <Harshil> which has a touch screen
[13:59] <Harshil> does ubuntu 16 support touch screen?
[14:01] <ppisati> ogra_: uhm nope
[14:01] <ppisati> ogra_: i'll give it shot
[14:02] <ppisati> ogra_: btw, where does the board dtb resided these days? kernel or gadget snap?
[14:02] <ppisati> *reside
[14:02] <ogra_> ppisati, you can pick ...
[14:03] <ogra_> (and if LP wouldnt 503 on me i could show you an example :P )
[14:04] <Harshil> is there any way i can  use tuch screen on ubuntu?
[14:04] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems$ grep device-tree beagleblack/meta/gadget.yaml
[14:04] <ogra_> device-tree: am335x-boneblack
[14:04] <ogra_> device-tree-origin: kernel
[14:05] <ogra_> ppisati, device-tree-origin: is either kernel or gadget ... with gadget being the default if you dont specify it at all
[14:05] <ogra_> if it is gadget you need to ship it in /dtbs/ inside the gadget
[14:06] <ogra_> Harshil, you mean snappy ? the snappy images do not have support for graphics yet ... and snappy on classic simply uses the input setup from the classic install for which you get support in #ubuntu
[14:15] <morphis__> cyphermox: ping
[14:18] <cyphermox> morphis__: hi
[14:19] <morphis__> cyphermox: I was wondering if there are any patches you did for network-manager to support config files generated from netplan
[14:20] <cyphermox> yeah, they're the few last I ever applied to NM
[14:20] <cyphermox> to be able to read files in /run and /var/lib
[14:20] <morphis__> cyphermox: ah, great
[14:21] <morphis__> cyphermox: so https://git.launchpad.net/network-manager/tree/debian/patches/Read-config-from-run.patch and https://git.launchpad.net/network-manager/tree/debian/patches/Read-system-connections-from-run.patch ?
[14:23] <cyphermox> that looks about right
[14:24] <cyphermox> look through that same upload there may be more patches from pitti that go along with that
[14:25] <morphis__> cyphermox: ok
[14:25] <morphis__> cyphermox: thanks
[14:37] <qengho> Is RPi2+ just impossible right now? My old image didn't survive upgrade, and the 6-Sept images are (I heard) broken.
[14:38] <balloons> jdstrand, ping
[14:38] <ogra_> they shouldnt be ... but nontheless there are sep 19 images :)
[14:38] <ogra_> the sep. 6th images had an issue on the pi3 which is why we withdrew it ... pi2 was faine though
[14:38] <ogra_> *fine
[14:39] <qengho> Oh. My Pi3 won't work, I gues.
[14:40] <oparoz> Can we still whitelist single syscalls in snapcraft.yaml?
[14:40] <ogra_> qengho, that would surprise me ... the sept. 19 images should surely work on all arches we released for
[14:40] <ogra_> (which includes pi3)
[14:41] <balloons> zyga, just poking again about the snap-confine SRU. Did you get stuck trying to make one?
[14:43] <ppisati> uhm
[14:43] <qengho> ogra_: I'm dumb. Where are those images?
[14:43] <ppisati> i'm pretty sure at this point that ubuntu-image caches the --extra-snap that you pass to it
[14:43] <zyga> balloons: it's in progress
[14:43] <zyga> balloons: I broke yakkety but we've learned and a new set of small releases will fix it today
[14:43] <ogra_> qengho, http://cdimage.ubuntu.com/ubuntu-snappy/xenial/current/
[14:43] <ppisati> and if you pass two times two different snap (but with the same)
[14:44] <zyga> balloons: and hopefully eventually reach xenial
[14:44] <balloons> zyga, wonderful to hear!
[14:44] <balloons> zyga, ohh, nothing is in queue for xenial yet?
[14:44] <ppisati> the image will be created using *always* the first snap with that name
[14:44] <balloons> that's where I need it
[14:44] <mup> Bug #1590219 changed: misleading error when the wrong command is passed with a flag <Snappy:Fix Released> <https://launchpad.net/bugs/1590219>
[14:45] <ogra_> ppisati, probably time for a bug
[14:48] <ppisati> ogra_: let me do another test
[14:50] <jdstrand> balloons: hey
[14:50] <balloons> jdstrand, howdy. I'm curious about your current thoughts on https://bugs.launchpad.net/snappy/+bug/1590767.
[14:50] <mup> Bug #1590767: Support snap installed completion scripts <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1590767>
[14:51] <balloons> jdstrand, it's the bash completion question :-) I know you had an idea that maybe it wasn't as crazy as it sounded for snaps
[14:51] <jdstrand> balloons: all my ideas are captured in the bug. I'm not actively working on it
[14:52] <jdstrand> balloons: I think it is probably possible, but it would need to be designed
[14:52] <jdstrand> (not necessarily by me)
[14:55] <ppisati> and while creating an image for rpi2/3, the dtbs aren't copied to the boot directory
[14:55] <ppisati> so the gadget one are kept around
[14:55] <ppisati> ...
[14:57] <balloons> jdstrand, so it still needs design / proof of concept then. Sounds like the proposed idea of a confined helper to feed strings is the most promising then
[14:59] <qengho> jdstrand: in case this was below your attention: "personality" syscall on armhf. https://bugs.launchpad.net/snappy/+bug/1614269
[14:59] <mup> Bug #1614269: tor package on ARMHF crashes on filtered syscall "personality" <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1614269>
[15:00] <qengho> I don't know what the argument to that syscall was, but I don't think we support more discrete filters anyway.
[15:06] <jdstrand> qengho: I saw the bug. I have a feeling that you'd run into other problems, but maybe not. we do support seccomp argument filtering in snap-confine these days, but nothing is using it yet (I plan to change that as soon as I get through other high priority work)
[15:07] <jdstrand> qengho: what happens if you add 'personality' to /var/lib/snapd/seccomp/profiles/snap.tor-middle-relay...
[15:07] <qengho> jdstrand: I whitelist "personality" with "sudo -e" and it works great. No complaints.
[15:08] <jdstrand> qengho: can you mention that in the bug. I suspect it is setting persona to 0xffffffff then
[15:09] <qengho> I will
[15:09] <jdstrand> thanks!
[15:10] <mup> PR snapcraft#820 closed: Fixed bug LP: #1607294 snapcraft search returns results in different order <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/820>
[15:13] <zyga> mvo: how do you feel about https://github.com/snapcore/snapd/pull/1847#pullrequestreview-1151064
[15:13] <SamYaple> hmmm sergiusens bit of an issue with the python plugin
[15:13] <mup> PR snapd#1847: many: discard preserved namespace after removing snap <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
[15:13] <sergiusens> SamYaple what issue?
[15:13] <zyga> mvo: I'd like to land it and do another release as this breaks people
[15:14] <SamYaple> sergiusens: it appears that its not installing some things and im not sure why. just discovered it
[15:14] <SamYaple> sergiusens: in a standard virtualenv on your machine, run `pip install dogpile.cache` youll notice it has more files than installing that in the snap
[15:15] <SamYaple> specifically in the snap 'lib/python2.7/site-packages/dogpile' does not contain an __init__.py
[15:15] <mvo> zyga: I would love to have niemeyer review on this branch too
[15:15] <SamYaple> and that is needed
[15:15] <mvo> zyga: but once its landed we can do a hotfix for yakkety
[15:15] <niemeyer> mvo: Which one is that?
[15:15] <niemeyer> #1847?
[15:15] <mvo> niemeyer: yes
[15:15] <sergiusens> SamYaple what if you `pip install --user dogpile.cache`?
[15:15] <niemeyer> mvo: Looking
[15:16] <balloons> mvo, might you be able to help out on getting a newer snap-confine into xenial? I've been poking zyga, but I don't think he has upload rights
[15:16] <zyga> mvo, niemeyer: understood, thank you
[15:16] <balloons> mvo, specifically the xenial version has the LXD issue which breaks juju, conjure-up, etc
[15:17] <sergiusens> SamYaple and second question since I am mad troubleshooting something else, does the upstream provide that __init__.py?
[15:18] <mvo> balloons: what bit exactly do you need? there is a pending update but its a bit delicate because it requires a new snapd and lock-step updates
[15:18] <SamYaple> sergiusens: indeed it does (as well as other files, __init__.py missing is simply blocking the import)
[15:18] <mhall119> nessita: are you on the Ubuntu rocket.chat ?
[15:18] <SamYaple> sergiusens: i can't --user in a virutalenv. stil ltesting that
[15:18] <balloons> mvo, https://bugs.launchpad.net/snap-confine/+bug/1613845
[15:18] <mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1613845>
[15:19] <nessita> mhall119, I'm not, how can I help you?
[15:19] <balloons> mvo, the PR is linked in there if you wanted to cherry-pick. But I was assuming 1.0.40 (and now 1.0.41) would come back to xenial directly
[15:19] <mhall119> nessita: Mirv had a question there about the new content interface and the store, let me copy it here
[15:19] <sergiusens> SamYaple I am guessing virtualenv does some __init__.py magic (I saw the code for virtualenv, it is full of weird things to help you out)
[15:20] <SamYaple> sergiusens: nah, its there with --user as well
[15:20] <SamYaple> sergiusens: but like i said, there are other missing files too, like api.py
[15:20] <mhall119> is there any recent documentation or examples on the content interface? I tried to add a similar slot configuration to geany-plugins to my package: https://github.com/ubuntu/snappy-playpen/blob/geany/geany-plugins/snapcraft.yaml - but when uploading to store I got "unknown attribute 'content' for interface 'content' (slots) lint-snap-v2_slots_attributes"
[15:20] <SamYaple> specific to dogpile.cache
[15:20] <mhall119> nessita: ^^ that was it
[15:20] <sergiusens> SamYaple hmph, can you log a bug, I will look at it later
[15:21] <SamYaple> sergiusens: sure. im still digging into it
[15:21] <mvo> balloons: right, if we do a new snap-confine we need to also do a new snapd with a branch that is not even in master yet, I'm just saying if this is urgent a cherry-pick might be easier
[15:22] <balloons> mvo, ack, makes sense. I would really appreciate a cherry-pick in that regards. I'm happy to help verify the SRU
[15:23] <mvo> balloons: ok, I will keep that in mind, if the branch lands soon and we can unblock the current snapd sru the full release is probably a better option. but its two *ifs* in there
[15:24] <mvo> pitti: silly question, snapd  2.15.2ubuntu1  is in xenial-proposed since ~21h but I  have not seen a autopkgtest run for it, is that expected? also not in the queue or anything. how is that scheduled?
[15:25] <nessita> mhall119, hum, I don't have the details of each interface, let me see who can help you
[15:25] <nessita> mhall119, the store until runs the click-reviewers-tools
[15:25] <nessita> we don't have the logic of the checks themselves
[15:26] <nessita> jdstrand, hi, would you know what the error that mhall119 printed above means: "unknown attribute 'content' for interface 'content' (slots) lint-snap-v2_slots_attributes"
[15:26] <mhall119> click-reviewers-tools is used against snaps as well?
[15:26] <nessita> mhall119, what app is this, so I look for it in the store?
[15:26] <nessita> mhall119, yers
[15:26] <nessita> yes*
[15:26] <pitti> mvo: ah, we had a ginormous amount of cloud breakage again, I'll just kick it
[15:26] <pitti> (to re-run again)
[15:27] <mhall119> nessita: not sure, Mirv didn't share links to his files
[15:27] <mvo> ta
[15:27] <pitti> mvo: note that it fails in y (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd)
[15:27] <nessita> mhall119, do you know the snap name?
[15:28] <pitti> mvo: (so is stuck in -proposed anyway)
[15:28] <niemeyer> zyga: Btw, if you are in a hurry, revert the changes
[15:28] <niemeyer> zyga: We don't want to rush this in
[15:29] <niemeyer> zyga: You are touching on the foundation of every single snap, and apparently there are issues.. let's take the time to do it right
[15:29] <zyga> niemeyer: ack
[15:30] <mhall119> nessita: I don't, sorry, and Mirv might be gone for the day already
[15:30] <mhall119> I can't find his developer account in the store either
[15:32] <Mirv> mhall119: nessita yes EOD but a quick link https://myapps.developer.ubuntu.com/dev/click-apps/5974/ -> 4 had the failure, in 5 the line is removed (and a new unrelated part added)
[15:32] <Mirv> sorry must go
[15:32] <niemeyer> zyga: review submitte
[15:32] <niemeyer> d
[15:33] <mhall119> thanks Mirv
[15:33] <mvo> pitti: that is fallout from a bad snap-confine version but yeah
[15:33] <nessita> Mirv, checking
[15:33] <mvo> pitti: I'm keen on the autopkgtest output because the upload targets the failures specifically, I'm keen to learn if my fixe(s) are good enough
[15:34] <mhall119> Mirv: looks like rev 5 passed, does that mean you've resolved it, or just reverted the changes from rev 4?
[15:35] <jdstrand> nessita: I do. 'content' isn't an attribute of the content interface per https://github.com/snapcore/snapd/blob/master/docs/interfaces.md. the attributes should be read, write or target
[15:35] <jdstrand> (depending on if slot or plug. in this case it is slot side so should be 'read' or 'write')
[15:37] <mhall119> jdstrand: according to my understanding of the interface, the "content" attribute is needed to make sure the plug and the slot are both talking about the same thing
[15:37] <jdstrand> there is no content attribute based on the docs
[15:37] <jdstrand> let me look at the yaml
[15:38] <jdstrand> jeez this thing is 400M
[15:38]  * jdstrand really wishes that the store showed the snap.yaml...
[15:39]  * jdstrand knows that is planned
[15:39] <mup> Bug #1626617 opened: console-conf does not allow to set up dns for static ip <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1626617>
[15:40] <mhall119> jdstrand: https://github.com/snapcore/snapd/blob/941e06e4f0eaece96e357b561013c8b7363e0068/tests/lib/snaps/content-slot/meta/snap.yaml lists a content parameter
[15:40] <mhall119> maybe it's something planned but not implemented yet
[15:41] <mhall119> https://github.com/snapcore/snapd/blob/941e06e4f0eaece96e357b561013c8b7363e0068/tests/lib/snaps/content-plug/meta/snap.yaml being the plug side
[15:41] <SamYaple> sergiusens: the import problem still exists, however the missing __init__.py is not the problem. the file difference was due to different versions of dogpile.cache
[15:42] <SamYaple> sergiusens: the fact remains that it is still an import problem and i dont know why
[15:43] <oparoz> Do we still need to "connect" something if we whitelist a syscall?
[15:44] <zyga> mhall119: hey, I need to skip the call as I have a conflict on sprint planning
[15:45] <mhall119> zyga: no worries, we had the upstreaming work call earlier, we found some blockers that will get passed on to you or jdstrand but not much
[15:45] <mhall119> jdstrand: who are you waiting for on the dbus interface review?
[15:46] <jdstrand> mhall119: niemeyer
[15:46] <jdstrand> mhall119: as for the content interface, just drop 'content: qt-ubuntu'
[15:47] <mhall119> niemeyer: a number of desktop apps are waiting on the dbus interface, do you know when we'll have that available?
[15:47] <jdstrand> mhall119: I checked the code and there is nothing in it that I can see that would honor the content attribute
[15:47] <mup> PR snapd#1976 closed: tests: skip some tests on non-amd64 architectures <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1976>
[15:48] <mhall119> Mirv: ^^ see jdstrand's fix above, it seems the 'content' parameter isn't used
[15:48] <jdstrand> mhall119: your question to niemeyer isn't phrased quite right
[15:48] <niemeyer> mhall119: After I get over the critical tasks for the impending deadlines
[15:48] <niemeyer> mhall119: I don't know what the status of this is, to be honest.. we discussed that long ago
[15:48] <jdstrand> mhall119: as you know, it was deprioritized for other high prioirty interfaces. that work is done, I came back around to it to get it in reviewable shape this week. now niemeyer and I need to iterate
[15:49] <niemeyer> Ah, nice, so jdstrand is on top o fit
[15:49] <mhall119> jdstrand: thanks, I didn't know it was deprioritized (though I did know other work was above it)
[15:49] <jdstrand> niemeyer: yeah-- we can start iterating again-- but I gave a long answer and I suspect you'll want to give it a careful read and ponder
[15:50] <jdstrand> mhall119: that is what I meant about deprioritized
[15:50] <niemeyer> mhall119: It was not consciously deprioritized.. it was naturally deprioritized because we have way too much to do on not enough time
[15:51] <balloons> should ~/snap/snapname/current exist? I only see ~/snap/snapname/buildnumber
[15:51] <jdstrand> mhall119: again, it is difficult when everything is critical priority-- nothing is. it was behind other stuff. that other stuff is mostly done, but dbus-app got picked up again and we are moving forward as best we can considering the deadlines (as niemeyer indicated)
[15:52] <jdstrand> mhall119: fyi, you are a subscriber to the trello card and I keep it up to date. not sure if those updates are getting filtered
[15:53] <mhall119> jdstrand: I saw the update, but not the detail of who had the next task on it or when it might be done
[15:53] <tachyons> successfully uploaded first ruby snap to store
[15:53] <jdstrand> the next task is in the PR
[15:53] <mup> PR snapd#1980 opened: tests: more debug around the create-key test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1980>
[15:53] <jdstrand> I don't have a timeline since we need to iterate and other deadlines are there
[15:54] <jdstrand> mhall119: note that devmode is still an option to unblock people. I realize that doesn't help with the stable channel.
[15:55] <mhall119> yeah, it also doesn't let them work on building their snap "the right way" until they know what that right way is going to be
[15:55] <mhall119> but I'm glad it's still active and getting near the top of the priority list now
[16:22] <mup> PR snapcraft#821 opened: Make copies of remote parts to avoid ordering issues <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/821>
[16:25] <Guillaume__> hello
[16:26] <Guillaume__> when they say "Try Ubuntu Core running on bare metal x86 devices" does it mean that it can run on any computer ???
[16:28] <ogra_> sure, you can dd the amd64 or i386 image onto a USB stick and should e able to boot it from there
[16:29] <mhall119> as long as the hardware doesn't prevent you from booting a different OS, yes
[16:29] <ogra_> indeed ...
[16:30] <mhall119> sergiusens: can you do 1400 utc tomorrow to talk about cmake/cpack and snaps?
[16:30] <mhall119> should only take 30 minutes
[16:34] <Guillaume__> is there a recommanded hardware or limitation ? for example, does it run on any NUC ?
[16:37] <Guillaume__> on bare metal, is there a recommanded hardware or limitation ? for example, does it run on any NUC ?
[16:38] <Pharaoh_Atem> zyga: so have you figured out the migration step yet?
[16:40] <SamYaple> sergiusens: oh. when did that get added? the problem is we are stripping the pth files
[16:40] <SamYaple> sergiusens: we should absolutely not be doing that
[16:41] <zyga> Pharaoh_Atem: I think so, I need to setup some representative env for testing though and script it all the way
[16:41] <zyga> Pharaoh_Atem: though still working on https://github.com/snapcore/snapd/pull/1847
[16:41] <mup> PR snapd#1847: many: discard preserved namespace after removing snap <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
[16:42] <SamYaple> sergiusens: https://github.com/snapcore/snapcraft/pull/765 tsk tsk tsk it was you!
[16:42] <mup> PR snapcraft#765: Use a recursive iglob for filesets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
[16:47] <jdstrand> niemeyer: hey, is there a way to retrigger travis checks? https://github.com/snapcore/snapd/pull/1968 failed for something unrelated to the PR
[16:47] <mup> PR snapd#1968: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1968>
[16:48] <niemeyer> jdstrand: Yeah, if you click on the "Details" link you'll see the three jobs.. some of them will likely have passed
[16:48] <jdstrand> yes, two of the 3 did
[16:48] <niemeyer> jdstrand: If the spread one failed, please restart just that one by clicking on it first
[16:49] <niemeyer> jdstrand: That sounds like a real failure then.. doubt a restart will make it work
[16:49] <jdstrand> ok, it was the one. it is tests/main/create-key
[16:49] <niemeyer> jdstrand: Please note we have a low tolerance for flakiness.. if there's a test that is failing on and off, we need to fix it or remove it
[16:50] <niemeyer> jdstrand: Ah, yeah, that's exactly this case then :)
[16:50] <jdstrand> 2016/09/21 22:25:37 Failed tasks: 2
[16:50] <jdstrand> - linode:ubuntu-16.04-32:tests/main/create-key
[16:50] <jdstrand> - linode:ubuntu-16.04-64:tests/main/create-key
[16:50] <niemeyer> jdstrand: mvo has been trying to stabilize this one
[16:50] <jdstrand> ok, cool
[16:50] <jdstrand> so if I click it, it might pass
[16:50] <niemeyer> jdstrand: Yeah
[16:50]  * jdstrand notices PR 1980 is being worked on
[16:50] <mectors> How does the serial-port interface work when I want to use a snap that connects to a USB device? Do I add a slot with the usb-x parameters and what do I have to do with snap connect?
[16:51] <niemeyer> mvo: any news on create-key?
[16:52] <jdstrand> niemeyer: I think I'm clicking the wrong thing. if I click 'it' or the big 'x', it just shows me the log
[16:52] <jdstrand> maybe I need to sign in
[16:53] <niemeyer> jdstrand: It's a circular thing, and there's a label next to it at the top
[16:53] <niemeyer> jdstrand: Yes, it needs to know who you are before it allows restarting a jbo
[16:54] <mup> Bug #1626652 opened: ~/snap/<name>/current/ is missing <Snappy:New> <https://launchpad.net/bugs/1626652>
[16:58] <jdstrand> niemeyer: ok, it took a while after I logged in before it should me the 'Restart build' button, but I clicked it. stuff seems to be happening :) thanks!
[16:58] <jdstrand> showed*
[17:02] <niemeyer> jdstrand: np.. again, if you click this thing too often, please let us know.. create-key we're already aware and are working on it
[17:03] <mup> Bug #1626656 opened: something isn't quoting <bold>things</bold> <Snappy:New> <https://launchpad.net/bugs/1626656>
[17:06] <mup> Bug #1626656 changed: something isn't quoting <bold>things</bold> <Snappy:Invalid> <https://launchpad.net/bugs/1626656>
[17:10] <jdstrand> niemeyer: yep. I figure I'd always ask
[17:15] <sergiusens> SamYaple you the content of the .pth be correct in any case?
[17:15] <sergiusens> SamYaple we need some code that would normalize it
[17:17] <modprobe_> Is there an easy way to include packages from a PPA in my snap? I'm trying to package an app which deps Qt 5.7
[17:18] <SamYaple> sergiusens: i dont understand the question
[17:21] <sergiusens> SamYaple hmm, I fail to see why we filter those out now
[17:22] <sergiusens> SamYaple disregard me, I entered firefighting mode since I woke up today :-)
[17:22]  * sergiusens skipped breakfast and lunch, and wondering if a late lunch would be a good idea
[17:25] <SamYaple> sergiusens: ok i responded in the github comment, but im going to submit a patch to remove that filtering and see if anyone complains
[17:25] <SamYaple> i really dont know why its filtered either
[17:27] <sergiusens> SamYaple please do
[17:33] <sergiusens> SamYaple oh, if possible in demos/snaps_tests it would be good to add a py package that maks use of pth files
[17:34]  * qengho has trouble with first startup of published pi3 image. Four CPU fruits on black, timeout to black. Heartbeat light still blinks. numlock key toggles light! and ctrl-alt-delete reboots. Weird.
[17:35] <SamYaple> sergiusens: without digging around, dogpile.cache does. ill see about adding that
[17:35] <qengho> Only weird thing in text before starting kernel is "Unable to read uEnv.txt".
[17:35] <ogra_> slangasek, ok, seems live-build is the bad guy here and removes *.pyc on all our images at build time with the exception of ubuntu-server and ubuntu-cpc ... i wonder why nobody ever sumbled over this
[17:36] <sergiusens> ogra_ slangasek I am so happy it is not snapcraft :-)
[17:37] <SamYaple> sergiusens: demos in the snapcore/snapcraft repo?
[17:37] <ogra_> slangasek, since quantal actually ...
[17:38] <sergiusens> SamYaple yeah, those get built AND their `apps/*/commands` run if specific to under snaps_tests as a real snap
[17:38] <sergiusens> SamYaple which wouldn't be the case if adding an integration test
[17:38] <ogra_> hmm, probably even longer ... cjwatson added the exception for ubuntu-server in quantal
[17:38] <sergiusens> SamYaple if it is too much trouble that's ok
[17:39] <slangasek> ogra_: probably because before now, "not ubuntu-server and not ubuntu-cpc" meant desktop, and the desktop live images were used on x86, and the byte compile penalty wasn't enough there to notice
[17:39] <SamYaple> sergiusens: not to much trouble, just something new. ill look into it right now
[17:40] <ogra_> slangasek, well, but that could explain why armhf has always been slow :) we always insisted to use the official build tools for our images :)
[17:40]  * slangasek chuckles
[17:40] <mup> PR snapcraft#822 opened: Don't filter .pth files in python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/822>
[17:40] <slangasek> ogra_: will you make the change to live-build to fix this, then?
[17:41] <ogra_> slangasek, i'll just add ubuntu-core to the exception code in livecd-rootfs for now
[17:41] <slangasek> ogra_: wfm
[17:41] <sergiusens> ogra_ mind if I reply with a short summary to the list?
[17:41] <qengho> modprobe__: No, there isn't.  Maybe add what you think it should look like in your yaml. https://bugs.launchpad.net/snapcraft/+bug/1604671
[17:41] <mup> Bug #1604671: snapcraft doesn't support arbitrary PPAs or apt sources <Snapcraft:New> <https://launchpad.net/bugs/1604671>
[17:41] <ogra_> but we should probably consider simply ripping out that bit completely
[17:42] <ogra_> slangasek, sure, go ahead, though i first want to see if that actually improves much :)
[17:42] <ogra_> before i make a statement myself
[17:42] <sergiusens> ogra_ oh, people say pyc is needed for this to improve, let's get them those pycs ;-)
[17:43] <ogra_> sergiusens, yeah, there i'm not even a size-nazi  :P
[17:43] <sergiusens> ogra_ riiiiight
[17:44] <sergiusens> ogra_ also, check telegram ;-)
[17:44] <sergiusens> ogra_ there is a treat for you
[17:44] <ogra_> LOL
[17:44] <ogra_> ohmy !
[17:44] <ogra_> thats an oooold pic
[17:44] <sergiusens> snappy fixed it ;-)
[17:45] <ogra_> not yet :)
[17:45] <ogra_> oh man , i look so slim ...
[17:47] <zyga> ogra_: snaps make everything ... compressed ;-)
[17:47] <ogra_>  hahaha
[17:57] <modprobe__> qengho: Thanks, I've done that. :)
[18:01] <mup> PR snapd#1981 opened: tests: add a test for core about device initialization and device registration and auth <Created by pedronis> <https://github.com/snapcore/snapd/pull/1981>
[18:35] <qengho> I'm filing image bugs in snappy/snapd bug tracker. Hope that's okay.
[18:35] <ogra_> well, filing them on the project is desired ...
[18:35] <ogra_> (see topic)
[18:36] <ogra_> dont file them against snapd though ... unless it is actually a snapd prob
[18:44] <mup> PR snapd#1971 closed: interfaces/builtin: add rcvfrom for client connected plugs to mir interface <Created by kgunnfront> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1971>
[19:02] <dobey> ogra_: unless it's a problem in the app itself, isn't it always a snapd problem? i thought that was the whole point of snapd and forcing everything to go through it
[19:03] <ogra_> well, a snappy image consiste of a lot more than snapd .. running a snap on a classic system uses snap-confine, ubuntu-core-launcher etc etc
[19:03] <ogra_> *consists
[19:03] <kyrofa> dobey, if it's image-related though, it could be ubuntu-image or a number of other things
[19:03] <ogra_> and even on classic it can be a lot more
[19:03] <kyrofa> Definitely
[19:04] <kyrofa> There are a lot of pieces associated with snaps beyond just snapd
[19:04] <ogra_> that is why we have the snappy project as catch-all bugtracker ...
[19:10] <mup> PR snapd#1956 closed: many: show snap name before the download progress bar <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1956>
[19:20] <pmcgowan> ogra_, hey, cant get my dragonboard to boot of the sd I made, will it work with a 2GB card?
[19:22] <mup> PR snapcraft#821 closed: Make copies of remote parts to avoid ordering issues <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/821>
[19:30] <ogra_> pmcgowan, i havent tried, but at least the dailies should not be to big for a 2G card
[19:31] <ogra_> (the smallest i have ever tested was 4G)
[19:32] <pmcgowan> ogra_, it errored when it reached the end of the card, when I insert it and boot I get the default android on mmc
[19:33] <pmcgowan> I did change the dip switch to sd
[19:33] <ogra_> pmcgowan, ah, well, the beta images are 3.8G ... they wont fit
[19:33] <pmcgowan> oh
[19:33] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
[19:33] <ogra_> grab one from there
[19:33] <ogra_> thats 300MB
[19:33] <ogra_> (uncompressed)
[19:34] <pmcgowan> great thanks will try it
[19:41] <pmcgowan> ogra_, btw whats the difference in the images besides the size
[19:41] <pmcgowan> or is this just new and improved
[19:43] <mup> PR snapcraft#823 opened: plainbox-provider plugin: rewrite python shebangs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/823>
[19:44] <sergiusens> SamYaple any luck with the test?
[19:45] <ogra_> pmcgowan, mine are untested daily builds from the edge channel (latest stuff and latest breakage) ... the cdimage ones are tested beta images
[19:46] <pmcgowan> ogra_, will beta images get smaller? or do I need to buy a card
[19:46] <ogra_> both ? :)
[19:46] <pmcgowan> heh
[19:46] <ogra_> i'm using ubuntu-image trunk whihc builds images only as big as their content
[19:47] <ogra_> once trunk is released the beta ones will also be small
[19:47] <pmcgowan> got it thanks
[19:49] <mup> PR snapd#1981 closed: tests: add a test for core about device initialization and device registration and auth <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1981>
[19:58] <sergiusens> mhall119 I can do one hour after or one hour before
[20:05] <zyga> jdstrand: hey
[20:06] <zyga> jdstrand: I wrote a small branch for snap-confine that I plan to cherry-pick into the release
[20:06] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/151
[20:06] <mup> PR snap-confine#151: Make snap-discard-ns fail gracefully <Created by zyga> <https://github.com/snapcore/snap-confine/pull/151>
[20:14] <ogra_> slangasek, http://paste.ubuntu.com/23217393/ ... not much improvement
[20:14] <ogra_> (and it wastes 5MB on the image)
[20:14] <slangasek> ogra_: strace itself is doing a lot of I/O, I'd be more interested in 'time console-conf --help' + strace output :)
[20:15] <slangasek> ogra_: is that 5MB of .snap size or within the filesystem?
[20:15] <slangasek> anyway
[20:15] <ogra_> the core snap got 5MB bigger
[20:15] <slangasek> strace output please, so we can see what it's spending time on now that it's *not* spending it on byte compilation
[20:16] <ogra_> (which is = filesystem size in our case)
[20:17] <ogra_> slangasek, http://paste.ubuntu.com/23217404/
[20:17] <slangasek> ta!
[20:17] <ogra_> without strace the time output varies ...
[20:17] <ogra_> between 12 and 5 secs
[20:18] <ogra_> thats is noticeable better ...
[20:18] <ogra_> i'll do a full install run with tomorrows image ... curious how that will turn out now
[20:19] <slangasek> indeed
[20:21] <ogra_> also interesting that it looks for the en_* locales ... the suystem has C.UTF-8 hardcoded
[20:21] <slangasek> huh
[20:22] <slangasek> ogra_: how's the entropy on the bbb?
[20:22] <ogra_> oh ... LANGUAGE is actually unset
[20:22] <slangasek> I notice the getrandom() in there
[20:22] <ogra_> plain SW iirc
[20:24] <ogra_> hmm, probably i'm wrong
[20:24] <ogra_> ogra@bbb:~$ lsmod|grep rng
[20:24] <ogra_> omap_rng               16384  0
[20:24] <slangasek> ogra_: also it looks like we're missing .pyc for subiquity itself, and that will be a packaging bug on our side:      0.001296 stat64("/usr/share/subiquity/subiquitycore/ui/__pycache__", 0xbeecbe10) = -1 ENOENT (No such file or directory) <0.000174>
[20:24] <slangasek> cyphermox, mwhudson: ^^
[20:25] <slangasek> not sure if that's enough files to matter
[20:35]  * ogra_ vanishes into the night
[20:41] <SamYaple> sergiusens: im still going on it, got other work pulling me away at the moment
[20:50] <cyphermox> slangasek: interesting, but I'm not overly surprised, I had all kinds of issues with packaging this
[21:08] <zyga> slangasek: hmm
[21:08] <zyga> slangasek: is that confined?
[21:08] <zyga> slangasek: AFAIR there's a silent deny rule for __pycache__ in apparmor somewhere
[21:08] <zyga> slangasek: (in the base template)
[21:08] <slangasek> zyga: this was a problem of files actually missing from the image
[21:08] <zyga> slangasek: ah, I see
[21:08] <slangasek> and if they're there, no denial
[21:20] <zyga> jdstrand: updated https://github.com/snapcore/snap-confine/pull/151 as requested
[21:20] <mup> PR snap-confine#151: Make snap-discard-ns fail gracefully <Created by zyga> <https://github.com/snapcore/snap-confine/pull/151>
[21:20] <mup> PR snapd#1982 opened: tests: disable broken create-key test <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1982>
[21:28] <mup> PR snapd#1968 closed: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1968>
[21:41] <mwhudson> slangasek: subiquity missing .pycs is not in the same league as missing them for the stdlib, i'd hazard
[21:42] <zyga> woah
[21:42] <zyga> "python slow"
[21:42] <zyga> gentoo level
[22:19] <mwhudson> heh funroll-loops.info seems to have died
[23:23] <mup> PR snapd#1982 closed: tests: disable broken create-key test <Created by niemeyer> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1982>


[04:46] <flocculant> ochosi: mmm - ubiquity started with adwaita http://i.imgur.com/qQpdIKJ.png
[07:10] <flocculant> commented eventually and changed bug to ubiquity
[07:50] <ochosi> flocculant: awesome, thanks!
[07:51] <ochosi> let's hope they care a little about it
[07:51] <ochosi> have you tried with Ambiance as well?
[07:51] <ochosi> (cause if it's broken there too, they'll certainly care more)
[08:04] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: libxfce4ui 4.13.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-libxfce4ui-4-13-1-released-tp48263.html (by Simon Steinbeiss)
[08:26] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-clipman-plugin 1.4.0 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-clipman-plugin-1-4-0-released-tp48266.html (by Simon Steinbeiss)
[08:54] <akxwi-dave> flocculant: ack..... just give me a shout and I'm all yours..
[09:22] <bluesabre> knome, ochosi, flocculant want to ACK https://bugs.launchpad.net/ubuntu/+source/greybird-gtk-theme/+bug/1623855 ?
[09:23] <knome> sure
[09:24] <knome> not in the release team though, so
[09:25] <bluesabre> knome, but you're in docs, right?
[09:25] <knome> yep, and i acked it already
[09:25] <bluesabre> good sir :D
[11:06] <flocculant> bluesabre: acked with both hats on
[11:07] <flocculant> knome: re "not in the release team though, so" yes you are - ochosi shouldn't be seperately I guess (old XPL) council is member of release :)
[11:07] <flocculant> akxwi-dave: might be better if I run it by you on e-mail
[11:09] <flocculant> ochosi: I had checked ambiance unfortunately - as a rule I always check Ubuntu as well as Xubuntu if something ubiquityish is wrong
[11:15] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-settings 4.12.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-settings-4-12-1-released-tp48268.html (by Sean Davis-6)
[11:40] <knome> flocculant, though i don't think council == release team
[13:54] <akxwi-dave> flocculant: KK..
[14:19] <flocculant> knome: didn't say council ==release team - but if xpl was on there then why not council, and if council not why was xpl :p
[14:20] <flocculant> frankly I couldn't care one way or the other though
[14:52] <flocculant> knome: when you've got 30 minutes or so to mull something over :)
[15:00] <flocculant> no rush btw - before zealous zebedee gets to us :D
[15:27] <ochosi> bluesabre: would be great if settings could make it into the final of yakkety and with an SRu go to xenial
[15:44] <flocculant> ochosi: re resize bug - checked other flavours - gnome affected, but I assume that'd be expected
[15:58] <ochosi> flocculant: yeah that's expected. so at least we're not alone blaming ubiquity ;)
[16:34] <flocculant> :)
[16:34] <flocculant> not easy to find anyone gnomeish of late to saddle up for the blame session
[16:47] <ochosi> jbicha maybe?
[16:48] <flocculant> don't know - is he something to do with Ubuntu Gnome - or just happens to do stuff because others are away
[16:49] <flocculant> can't even remember Tim's nick :(
[16:50] <ochosi> knot sure, but i thought he was pretty active in the gnome ubuntu community
[16:52] <krytarik> flocculant: darkxst
[16:55] <flocculant> krytarik: thanks :)
[16:56] <flocculant> ochosi: ok - well if I don't see you letting him know - I will - think you're away on hols aren't you?
[16:57] <flocculant> in the meantime I'll at least flag it on their iso tracker builds
[17:57] <knome> flocculant, could do 15ish now if that's enough
[17:57] <knome> flocculant, otherwise "tomorrow"
[18:17] <flocculant> manana in the good old Spanish way will be fine - really no rush :)
[18:17] <knome> oki
[18:17] <knome> you at work on the daytime?
[18:17] <flocculant> yea tomorrow I am
[18:17] <knome> oki, then let's try to catch up in the evening
[18:18] <knome> just ping - i'm lurking more often than one'd think...
[18:18] <flocculant> I was serious when I said 'before zz' :)
[18:18] <knome> yeah, but better get it done sooner than later anyway
[18:18] <flocculant> yep ok - more or less the same here too lol
[18:18] <knome> re: council/xpl on release, i think we need to rethink that
[18:19] <knome> unless that's what this is about :P
[18:19] <flocculant> right
[18:19] <flocculant> no - this is something completely different than that :)
[18:19] <knome> i mean again, xpl was a single person who had a lot of "decision power"
[18:19] <flocculant> yea
[18:19] <knome> so it made sense that he was a member of the release team
[18:19] <flocculant> right
[18:20] <knome> now the council is much more like an arbiter
[18:20] <flocculant> at a minimum needs qa/tech
[18:20] <knome> yeah
[18:20] <flocculant> the 'can mark ready' thing isn't so much a necessirty ofc as anyone with powers can do that
[18:21] <knome> could be those and one from council - just for any unrealistic but potential veto stuff
[18:21] <flocculant> mmm
[18:21] <knome> but that person shouldn't likely be very active in that team - at least with their council hat on
[18:22] <flocculant> yea
[18:22] <knome> maybe it would make sense that bluesabre served as both technical and council member
[18:22] <knome> he'd then know - as anybody really
[18:22] <knome> - when to be in touch with council
[18:23] <knome> eg. if the situation looks really disastrous
[18:23] <flocculant> yea - except that on release days is kind of pants - cos he's not available usually at those times
[18:23] <knome> mhm
[18:23] <knome> i think i have all mark-powers via the qa tracker dev team
[18:23] <flocculant> I think anyone half tech would know if something was looking disastrous - and could shout at least to delay
[18:23] <knome> yeah, that
[18:24] <flocculant> knome: yea you will have - I can mark anyone's image ready
[18:24] <knome> i guess i have any powers you can ever imagine :P
[18:24] <flocculant> even I'd know if something techish was looking disastrous :)
[18:24] <flocculant> anyway - needs a rethink now I guess - but once more not really a rush there
[18:25] <knome> yep
[18:25] <knome> oh, even council is a member of that team
[18:25] <flocculant> ideally before 13th October is all :D
[18:25] <flocculant> yea
[18:25] <flocculant> cos s/xpl/council :)
[18:25] <knome> yep
[18:25] <knome> but simon is a member individually too
[18:26] <flocculant> yes - not sure why that - maybe some xpl/individual stuff - no idea
[18:26] <flocculant> can you remember how it was when you were xpl?
[18:26] <knome> we didn't have the xpl team then
[18:27] <knome> but if the council/xpl team is a member, then simon doesn't have to be
[18:27] <flocculant> cos as 'not xpl' art team lead in release is odd :)
[18:27] <flocculant> yea - same as bluesabre in release
[18:27] <knome> i think the rationale behind this is that we explicitly wanted to communicate that simon is part of the release team
[18:27] <flocculant> currently it's effectively me/dave and council
[18:27] <knome> yep
[18:28] <knome> i deactivated simon
[18:28] <flocculant> k
[18:28] <knome> now it's more like it likely should be, i think
[18:28] <flocculant> not sure really - the only other non qa/council person logically should be there would be Unit193
[18:29] <knome> does anybody have any reason why the council needs to be a *member* of the bugs team?
[18:29] <flocculant> don't think there's need for Sean to be there perhaps
[18:29] <flocculant> on release
[18:29] <flocculant> does it not own bug team?
[18:30] <knome> well, that explicitly states he's the tech lead
[18:30] <knome> it does, yes
[18:30] <flocculant> ok - that works for me
[18:30] <knome> but it's also a member of the team
[18:30] <knome> which is a bit different
[18:30] <flocculant> then it'll be a member won't it?
[18:30] <knome> nope
[18:30] <knome> i think, weight on the word *think*
[18:30] <flocculant> lose elfy from that team ...
[18:31] <knome> that *members* get the bug mail
[18:31] <knome> owners don't
[18:31] <knome> done
[18:31] <flocculant> mmm
[18:31] <flocculant> trying to remember back
[18:31] <flocculant> ty :)
[18:31] <knome> anyway, as council is the owner, it doesn't "need" to be a member
[18:32] <flocculant> knome: maybe amend council bug mail options ?
[18:32] <flocculant> though given sean is there twice - might screw that up
[18:32] <knome> oh well,
[18:32] <knome> i'll send a mail to the council to see what they think :P
[18:32] <flocculant> :)
[18:33] <knome> and now time to run
[18:33] <knome> ttyl
[18:33] <flocculant> cya
[20:17] <flocculant> Unit193: uefi bug being reported in -release :p
[20:21] <Unit193> Thanks.
[20:21] <flocculant> welcome :)
[20:40] <Unit193> Got a list of those of us on Yak that you can ask to test stuff, btw?
[20:40] <Unit193> Also, that bug means that I haven't tested Core with UEFI (or secure boot) either. :3
[20:40] <flocculant> Unit193: nope - no list
[20:41] <flocculant> I've subbed to that uefi bug now I worked out what I needed to install to make it work :p
[20:41] <Unit193> Oh, could have asked. :3
[20:43] <Unit193> I pull a RPM from OpenSuse's build system (like PPAs, though can build more than just rpms) and extracted the EFI module, placing it in /usr/share/ovmf/.  I really don't remember what it was with the packaged one that prevents secure boot though. :D
[20:43] <flocculant> well yes could have asked - but we don't much talk about testing uefi here :p
[20:44] <Unit193> I, uh, first noticed because of something non-Xubuntu, then went up the line (Non-xubuntu, xubuntu-core, xubuntu-desktop, xenial releases.)
[21:45] -SwissBot:#xubuntu-devel- ::xubuntu-artwork:: [yakkety] r315 Update icons from upstream... (by Simon Steinbeiß)
[22:58] <jbicha> bluesabre: I borrowed your packaging to update Debian: https://tracker.debian.org/pkg/greybird-gtk-theme
[23:12] <Unit193> libxfce4ui 4.13.1-1; xfce4-clipman-plugin 2:1.4.0-1; xfce4-settings 4.12.1-1 uploaded to Debian too.
[23:41] <bluesabre> jbicha, cool, glad to help :)


[04:19] <mfisch> Does bug control have the ability to edit bug comments?  If so, can someone remove this poor guys phone numbers from bug 941215
[04:19] <ubot2`> Launchpad bug 941215 in wubi "permission denied when installing wubi on win7x64 (dup-of: 862003)" [Undecided,New] https://launchpad.net/bugs/941215
[04:19] <ubot2`> Launchpad bug 862003 in wubi "wubi installs successfully but ends in 'permission denied' error due to the presence of a virtual or readonly drive; this only happens running wubi.exe standalone i.e. when installing using the tar.xz preinstalled image" [High,Triaged] https://launchpad.net/bugs/862003
[04:44] <dnivra> just clarifying hggdh's comments: my pastes say that compatible java interpreters and compilers aren't found right?
[04:44] <dnivra> "<hggdh> dnivra_: 'update-alternatives' sets which installed Java is to be used by default. If you do not override by giving out an absolute path to java, the right thing will always be done"
[04:53] <micahg> mfisch: a launchpad admin might be able to do it
[12:20] <krychek> Can this bug be closed: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/206113       ?
[12:20] <ubot2`> Launchpad bug 206113 in wubi "Wubi install cannot create swap space (8.04 Beta) [Regression from alpha 6]" [Medium,Fix released]
[12:21] <Ampelbein> looks like it
[12:25] <krychek> does it need explanation?
[20:31] <jacob> Would someone be able to set the importance of this bug? https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/941229 -- I think High would be appropriate, but correct me if I'm wrong.
[20:31] <ubot2`> Launchpad bug 941229 in gstreamer0.10 "deadlock: GStreamer-WARNING **: wrong STREAM_LOCK count 0" [Undecided,Confirmed]
[20:50] <JanC> jacob: I have seen a similar freeze when seeking within a video, not sure if the videos used mp3 for audio though
[20:58] <jacob> JanC: there's a similar bug (https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/906784, may be a duplicate) that shows it also occurs with video, so it could definitely be related.
[20:58] <ubot2`> Launchpad bug 906784 in webkit "GStreamer-WARNING **: wrong STREAM_LOCK count 0 after changing HTML5 video.src" [Medium,New]
[21:04] <JanC> it was also difficult to reproduce (which might depend on the used codecs and/or containers)
[21:09] <jacob> I've found it was easiest to reproduce using the Fluendo MP3 plugin (versus the MAD one from -ugly)


[16:50] <thorwil> newz2000: hi! the collaborative countdown banner thing will obviously not happen. have a number of other ideas but also currently a demanding job :)
[16:51] <newz2000> I nkow what you mean. The collaborative idea was so good I'm sorry I could not help to get it pulled off
[16:54] <newz2000> I'm a little concerned we're going to get images of a bunch of social koalas meditating in the clouds. :-)
[16:55] <thorwil> hehe
[16:55] <newz2000> But who am I to stifle creativity?
[16:56] <thorwil> newz2000: you're the last i would accuse of that :)
[19:24] <MadsRH> newz2000: Perhaps people are just waiting for the xsplash and wallpaper to land, so they can create banners that will match. Anyway, that's the reason I haven't submitted anything yet. I guess rugby471's banner will land pretty close, but again who knows ;-)


[08:57] <huats> plop plop
[08:58] <huats> oups
[08:58] <huats> sorry (
[08:58] <huats> wrong channel)
[08:58] <huats> morning everyone one !
[08:59] <Keybuk> wow, someone on Planet Ubuntu has actually managed to really offend me, and it's not \sh ;)
[09:10] <Hobbsee> Keybuk: gasp.  What'd you do with the real keybuk?
[10:37] <seb128> lut huats
[10:38] <huats> plop seb128
[10:39] <seb128> jaunty is open if some people feel adventurous and want to start on GNOME 2.25.1 updates ;-)
[10:39] <huats> :)
[10:39] <huats> seb128: I'll take care of some updates ...
[10:39] <huats> next week :)
[10:40] <seb128> anybody has an opinion on using ubuntu-bugs or desktop-bugs to store the list of packages, usual maintainers, etc informations?
[10:40] <seb128> ups
[10:40] <seb128> desktop-bugs or ubuntu-desktop team rather
[10:40] <seb128> one has open access and the other one is restricted
[10:41] <seb128> technically those don't change too often, just when we change series and when somebody wants to work on a specific package and be listed there
[11:52] <slomo> seb128: you can sync gst-plugins-good0.10 from experimental later, i've added the libv4l patch upstream and to the package
[11:55] <seb128> slomo: ok thanks
[12:10] <asac> seb128: sound not working in flash or totem with flash currently is either pulseaudio or libasound-plugins bug afaik
[12:10] <asac> just FYI ;)
[12:10] <seb128> asac: ok, I just know it's not totem$
[12:10] <seb128> asac: where should I reassign those?
[12:10] <asac> seb128: let me gimme something
[12:11] <asac> seb128: crimsun gave me this: https://wiki.ubuntu.com/MozillaTeam/Bugs/FlashAnswers
[12:12] <asac> seb128: then assign to any sound package or even flash (crimsun also tracks flash obviously)
[12:12] <seb128> asac: ok thanks
[12:12] <asac> just wanted to give you and update because i saw you ended up with these bugs too ;)
[12:13] <seb128> right, thank you ;-)
[12:18] <asac> seb128: i think i will ask themuso too to give more content for that answer. so maybe revisit that page if you get such bugs again ;)
[12:20] <seb128> asac: ok
[15:05] <mvo> seb128: when do you expect a new g-t release? is it worth to put <IP_ADDRESS> into jaunty? or should i just wit for 2.25
[15:06] <seb128> mvo: no clue, GNOME 2.25.1 is this week but not a lot of tarballs are rolled so earlier, not enough changes yet, not all the maintainers switched to unstable, etc
[15:06] <seb128> mvo: so yeah likely worth doing the update now
[15:09] <mvo> thanks, will do
[18:32] <gkahla> am i misunderstanding the use of seahorse? I need a secure application to store my passwords in (like KeePassX)
[18:32] <gkahla> i'd like to use something GNOME-native
[18:34] <gkahla> not a support channel - sorry, was multitasking - pax
[18:58] <MacSlow> Does anybody know how to record *spew* a flash-based web-cast?
[19:01] <johanbr> Is it pre-recorded, a la youtube? If so, the Adobe plugin leaves a flash file in /tmp.
[20:08] <don> Since upgrading to 8.10, I have been unable to print to my Minolta 2430DL printer.  It worked fine under 8.05.  My PDF printer works fine.
[21:27] <pochu> I guess we will have webkit in main for jaunty :)
[21:28] <seb128> pochu: it's already there in hardy
[21:28] <seb128> ups, intrepid
[21:31] <pochu> seb128: oh, I didn't notice it
[21:31] <pochu> thanks
[21:31] <seb128> you're welcome


[22:04] <Haris> hello all
[22:05] <Haris> my ubuntu machine says I have 7 security updates. when I run apt-get update; apt-get upgrade it doesn't upgrade anything. Is there a way to see list of these 7 pkgs which can be upgraded ? and how to upgrade them ?


[20:42] <yoasif1> apw: i tried using your test kernel, and i'm still experiencing the same issue i had in previous kernels (kernel BUG at fs/btrfs/extent-tree.c:1833)
[22:15] <apw> yoasif1, then i guess that is not the fix then
[22:16] <apw> yoasif1, implying that .8 is not sufficient to fix it i mean