[18:25] <pavlushka> zaki: hello
[18:31] <zaki> pavlushka, hi. :)
[18:31] <zaki> how are you?
[18:31] <pavlushka> zaki: I am cold and you?
[18:32] <zaki> ফেন চালাই বসে আছি। :P
[18:32] <pavlushka> lol
[18:33] <zaki> not so much cold here
[18:33] <zaki> what are u doing?
[18:34] <pavlushka> zaki: nothing, just ঘরের মধ্যে মটকা মেরে বসে অাছি এই ঠান্ডায়
[18:36] <zaki> he he
[18:36] <pavlushka> zaki: r youtube e crime petrol dekhi
[18:37] <zaki> I was practicing on packet tracer and watching The Vikings.
[18:37] <zaki> crime petrol!!
[18:38] <pavlushka> zaki: Indian Police (may be crime branch or CBI) are really a thing
[18:39] <pavlushka> zaki: they solved many puzzling cases just following the strings
[18:39] <zaki> no idea on that!
[18:40] <pavlushka> zaki: I meant tiny trace or references by strings
[18:40] <zaki> oh.!


[00:19] <mup> PR snapd#1975 closed: tests: add test benchmark script <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1975>
[01:25] <mup> PR snapd#1578 closed: image: add meta/gadget.yaml infrastructure <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1578>
[01:38] <mup> PR snapd#1953 closed: snap, daemon, store: pass through screenshots from store <Created by robert-ancell> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1953>
[02:02] <mup> PR snapd#2000 closed: snap, daemon, store: pass through screenshots from store <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2000>
[03:56] <mup> PR snapcraft#832 opened: WIP LP: #1627880 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/832>
[04:18] <mup> Bug #1597784 changed: "PermissionError: [Errno 13] Permission denied" executing a snap <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1597784>
[05:59] <lpotter> Mirv: ping
[06:06] <Mirv> lpotter: pong
[06:07] <Mirv> lpotter: I commented on your MP already and merged it, thanks a lot! really happy about getting the locally built qmake into use.
[06:07] <lpotter> I can help with qt-ubuntu snap. I have it building with the local qmake, but it's installing to wonky director
[06:07] <lpotter> directory
[06:08] <lpotter> the build plugin dont recognize $SNAP.
[06:08] <Mirv> lpotter: in what sense? the current snap in the store installs to usr/lib/arch/ (libs) and usr/lib/arch/qt5 (plugins, qml)
[06:09] <Mirv> ah, "NAP" :)
[06:09] <lpotter> :)
[06:09] <Mirv> I wonder if it's needed at all in the config or not
[06:10] <lpotter> it is, as without prefix it tries to use / which is not writable to the snap
[06:11] <lpotter> and I ran into an issue with libpng-dev for some reason
[06:12] <lpotter> and that libicu will cause issues too
[06:14] <Mirv> lpotter: I was building on yakkety. As commented on github, it's libpn12-dev on xenial. Fixed it now.
[06:16] <lpotter> ok, cool
[06:16] <abeato> ogra_, hi, is the pi2-kernel snap available now? ubuntu-image complains as it cannot download it, and I do not see it with "snap find"
[06:26] <dholbach> good morning
[07:11] <dholbach> has anyone of you dealt with node issues like the following already? what's a good way of going about them? "npm ERR! version not found<EMAIL_ADDRESS>[07:31] <mup> PR snapd#2001 opened: overlord/boot: switch to using assertstate.Batch <Created by pedronis> <https://github.com/snapcore/snapd/pull/2001>
[08:09] <mvo> pitti: is it possible to delete the successful test of ppc64el for snapd? I think this successful test was a mistake, i.e. it happend when there was actually no test executed due to a mistake
[08:25] <Son_Goku> zyga: ping: https://github.com/zyga/snapcore-fedora/pull/6
[08:25] <mup> PR zyga/snapcore-fedora#6: Flesh out snapd-glib spec <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/6>
[08:26] <Son_Goku> mvo, why is snapd-xdg-open not under the io.snapcraft.* namespace?
[08:26] <Son_Goku> on the bus
[08:26] <Son_Goku> everything else has moved onto that namespace, so it's weird that this one still retains com.canonical.*
[08:28] <pitti> mvo: how do you mean? There isn't just one pass in http://autopkgtest.ubuntu.com/packages/snapd/yakkety/ppc64el but many, and 2.13+16.10 actually did run tests
[08:29] <mvo> Son_Goku: uh, thank you, that looks like an oversight
[08:29] <Son_Goku> believe it or not, I actually check these things before letting zyga push them into Fedora ;)
[08:30] <mvo> Son_Goku: heh :)
[08:30] <mvo> pitti: sorry, I was wrong, tests did run but they were not really useful "OK: 1 passed, 2 skipped"
[08:31] <mvo> pitti: now we have ~80 tests that are run, 4 fail on ppc64el, I work on skipping or making them pass (our test snaps we uploaded seem to be not fully working on ppc64el)
[08:32] <mvo> Son_Goku: and sorry that I have not got back to your mail :/ life is a bit busy right now due to some looming deadlines
[08:32] <Son_Goku> :(
[08:33] <Son_Goku> well, I was hoping that something could be done before the October sprint, so that I would have something cool to show off, but no worries if not
[08:33] <mvo> Son_Goku: thats going to be tricky but maybe we can get some quality hack time during the sprint
[08:33] <Son_Goku> I hope so
[08:34] <Son_Goku> I've already got that selinux policy module that I need to test to see if it resolves https://github.com/zyga/snapcore-fedora/issues/1
[08:35] <pitti> mvo: so I can mark the currnet version on ppc64el as "ignore failure"
[08:36] <mvo> pitti: please do, I will work on making them work again but until then it owuld be great to ignore-failure them so that they do not block the other arches
[08:36] <pitti> mvo: that won't help much though, as it also regresses on both x86
[08:38] <mvo> pitti: that will be fixed soon, its actually a regression from snpa-confine
[08:39] <mvo> pitti: triggered by snap-confine which is used in the tests, but zyga fixed that so the next upload should fix it
[08:39] <pitti> mvo: ah, good, then we can just retry those; I'll add the ppc hint then
[08:41] <mup> PR snapd#2001 closed: overlord/boot: switch to using assertstate.Batch <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2001>
[08:41] <mvo> pitti: thank you
[08:51] <pitti> zyga: any chance to get the snap-confine SRU in xenial verified?
[08:51] <pitti> (sitting there for 20 days)
[08:51] <pitti> zyga: the next version has already been sitting in unapproved for a week, but is blocked by ^
[09:02] <ogra_> abeato, did you pick the right channel ? (we didnt rellease to stable yet)
[09:03] <abeato> ogra_, yes, I found out that was the issue in the end, thanks
[09:49] <mup> PR snapd#2002 opened: tests: use new spread `debug` feature <Created by mvo5> <https://github.com/snapcore/snapd/pull/2002>
[09:49] <zyga> pitti: I'll check what's going on there, thanks for telling me about it
[09:51] <kalikiana> Hmm stumbled upon this in another context. Could/ do snaps take advantage of ksm (kernel page sharing) to address memory waste? https://www.kernel.org/doc/Documentation/vm/ksm.txt
[09:51] <ogra_> kalikiana, yes
[09:51] <ogra_> (has been discussed multiple times ... i'm not sure about the verdict though)
[09:52] <kalikiana> ogra_: Ah, cool. Would there be any documentation of what features are currently being used? I wouldn't want to stir up the discussion for the nth time if it's already sorted.
[09:52] <ogra_> you have to ask the core team ... mvo or niemeyer would know more
[09:53] <zyga> ogra_: yes?
[09:53] <ogra_> zyga, ?
[09:53] <zyga> kalikiana: reading the document I see that this requires MADV_MERGEABLE
[09:53] <zyga> kalikiana: so only applications explicitly doing that would benefit
[09:54] <ogra_> zyga, isnt that a wrapper thing ? i.e. ubuntu-core-launcher
[09:54] <zyga> kalikiana: so snaps could take advantage of this
[09:54] <zyga> ogra_: no
[09:54] <mup> PR snapd#1921 closed: tests: replace systemd-run with on-the-fly generation of units <Reviewed> <Created by vosst> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1921>
[09:54] <zyga> ogra_: and besides, we cannot do that for the application
[09:55] <zyga> kalikiana: so I think a more balanced answer is that snapd doesn't prevent apps from using ksm
[09:55] <zyga> kalikiana: so if they are written to take advantage of it, they can
[09:55] <ogra_> our kernels have definitely switched it on ...
[09:56] <ogra_> (at least the official ones)
[09:56] <zyga> ogra_: right but applications need to use it, otherwise it does nothing
[09:56] <ogra_> zyga, well, then i dont understand how al the cloud services can make use of it on behzalf of the apps that run in their containers/VMs
[09:57] <ogra_> afaik they a use that on a VM level
[09:57] <zyga> ogra_: with madvise(and MADV_MERGABLE)
[09:57] <kalikiana> zyga: Supposedly qemu can share memory of multiple instances - I wonder how they do it in that general way
[09:57] <zyga> kalikiana: ^^
[09:57] <ogra_> dunno, i dont thionk all debs that are used in ubuntu clouds are patched on the fly :)
[09:58] <zyga> application developers need to explicitly mark private memory pages as mergable
[09:58] <zyga> probably only virtualization tools use this feature
[09:58] <ogra_> afaik the sharing theer works on application level and people are surely not using modified debs
[09:58] <mup> PR snapd#1994 closed: snap: add `snap known --remote` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1994>
[09:59] <ogra_> so the VM must do something here that snapd/ubuntu-core-launcher should be able to do as well
[09:59] <zyga> no
[10:00] <zyga> ogra_: snap-confine lives for a millisecond
[10:00] <zyga> ogra_: and execs an application
[10:00] <zyga> ogra_: the appication must understand what is going on and actually sensibly use madvise
[10:00] <zyga> ogra_: it cannot be blindly enabled
[10:01] <zyga> ogra_: VMs enable that so that that they can share memory across memory-heavy virtualization but we don't pay that price and we cannot enable it in any way
[10:01] <zyga> ogra_: but if there's a snap with VM inside then that snap can use this feature internally
[10:01] <zyga> ogra_: so snapd is not related to ksm in any way, this is application responsibility to use
[10:04] <mup> PR snapd#2003 opened: debian: adjust packaging setup for trusty/deputy systemd <Created by vosst> <https://github.com/snapcore/snapd/pull/2003>
[10:17] <mup> PR snapd#2004 opened: cmd/snap: make the buy tests run again and fix the failures <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2004>
[11:29] <mup> PR snapd#2005 opened: many: introduce a device-init hook, let it optionally configure device registration and the serial-request <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2005>
[11:30] <mup> PR snapd#1865 closed: overlord/devicestate: POC to parametrise serial-request content/sending <Blocked> <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1865>
[12:15] <morphis_> ogra_: at which time is a new OS snap for edge build daily?
[12:16] <ogra_> ogra@lillypilly:~$ crontab -l
[12:16] <ogra_> 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1
[12:16] <ogra_> 0,30 * * * * /home/ogra/public_html/ubuntu-core-builds/generate-core.sh >>/home/ogra/public_html/ubuntu-core-builds/generate.log 2>&1
[12:16] <ogra_> ogra@lillypilly:~$
[12:16] <ogra_> 4:30 UTC
[12:17] <morphis_> thanks
[12:17] <morphis_> ogra_: is this generate-core script available somewhere?
[12:17] <ogra_> morphis_, note though that the store is buggy ... sometimes i get 404s for existing snaps ... which results in them not to have a channel and not being published
[12:18] <morphis_> ok
[12:18] <ogra_> sure, on people.canonical.com ;)
[12:18] <ogra_> (the path is right in there )
[12:18] <ogra_> thats always the latest version ... its a bit out of sync, but it is also in lp:snappy-dev/ubuntu-core
[12:24] <morphis_> ogra_: ok
[12:26] <ogra_> https://code.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk  .... in the cron-scripts dir
[12:34] <ogra_> morphis_, i brought the branch in sync now
[12:36] <ogra_> there is also a README in the cron-scripts dir, describing what you need to prepare when using it yourself
[12:48] <abeato> pstolowski, hi, was wondering how the kmod interface works. If I add a module to an interface, which permissions do I get? can I do modprobe on it?
[12:52] <zyga> abeato: no, you get that module loaded but you cannot load it yourself
[12:52] <zyga> abeato: kmod is not an interface it is a "security backend"
[12:52] <zyga> abeato: interfaces can choose to use it
[12:53] <abeato> zyga, so the module would get loaded when you connect to a plug that requires that, correct?
[12:53] <mup> PR snapd#2006 opened: debian: merge 2.15.2ubuntu1 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/2006>
[12:53] <zyga> abeato: it depends on the design of the interface
[12:54] <jdstrand> abeato: is there a particular use case you have in mind?
[12:54] <jdstrand> zyga: good morning/afternoon zyga :)
[12:54] <jdstrand> and hello abeato :)
[12:54] <zyga> jdstrand: hello
[12:54] <abeato> jdstrand, loading ppp modules
[12:54] <abeato> jdstrand, morning :)
[12:55] <zyga> jdstrand: I'm working on SRU verification, eh, I "love" our fragmented releases
[12:55] <jdstrand> abeato: yep, that was the other one that I thought people would add things to immediately
[12:55] <ogra_> zyga, snappy will fix that :P
[12:55] <jdstrand> zyga: heh. you can spin that another way-- it is motivating to get things right before release :P
[12:55] <mup> PR snapd#1979 closed: assertions: add system-user assertion <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1979>
[12:56] <abeato> jdstrand, zyga just want to load ppp_generic when somebody connects to the ppp interface
[12:56] <zyga> jdstrand: the problem is the release is right but now I'm in some weird partial state that is never tested
[12:56] <pstolowski> abeato, yeah, as zyga says
[12:56] <zyga> ogra_: it was supposed to ;)
[12:56] <ogra_> :)
[12:56] <zyga> ogra_: but not for snappy :-(
[12:57] <zyga> abeato: that's a two-liner then
[12:57] <ogra_> yeah, there was some irony in my sentence ;)
[12:57] <zyga> abeato: or maybe even one liner, depending on syntax
[12:57] <abeato> pstolowski, zyga so this should be just fine, isn't it?: http://paste.ubuntu.com/23242066/
[12:57] <jdstrand> abeato: yeah, take a look at firewall-control. ppp will be the same. you won't need anything special
[12:57] <zyga> ogra_: yeah, I know :/
[12:57] <jdstrand> abeato: specify the modules you want and snapd will handle the rest on interface connect
[12:58] <abeato> alright, thanks
[12:58] <pstolowski> yep
[13:00] <jdstrand> zyga: oh hrmm-- I was hoping the snapd autopkgtest fixes were going to be in place before snap-confine (which is why I suggested that whoever uploads snapd should upload snap-confine)
[13:00] <jdstrand> oh well, there is a bug in the devel release that will get fixed
[13:01] <jdstrand> that's happened on occasion :)
[13:11] <jgdx> after $ sudo snap try prime and prime is removed/changed, I get into a state where I can't remove the snap because: /snap/ubuntu-system-settings/x1: not mounted
[13:12] <jgdx> it make sense, but it's not known to me how to get out of that situation
[13:14] <jgdx> any ideas?
[13:19] <zyga> jdstrand: I'd love to know about that docker workaround
[13:19] <zyga> jdstrand: I see what it does but OMG what is this doing to make the problem go away
[13:20] <jdstrand> zyga: it is arguably a bug in docker. it is looking in mountinfo to find where the cgroup directory is. it finds /tmp/snap.rootfs_... and thinks it is there
[13:20] <jdstrand> zyga: so we let it keep thinking that
[13:21] <jdstrand> zyga: I noticed in looking at mountinfo from inside a snap that we are leaking those mount locations and also all the mounted snaps
[13:22] <jdstrand> zyga: ideally we would have a clean mountinfo and we could remove the workaround
[13:24] <jdstrand> zyga: docker could also update their FindCgroupMountpoint() in runc/libcontainer/cgroups/utils.go, but went with a non-patch approach for now until we decide if there is something we can do (even if it is terribly)
[13:24] <jdstrand> terribly ugly
[13:27] <Guest60909> nick pmp
[13:27] <Guest60909> <-- sry, what an idiot
[13:34] <mup> PR snapd#2007 opened: interfaces: ppp: load needed kernel module <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2007>
[13:36] <zyga> jdstrand: interesting, that explains a lot
[13:36] <zyga> jdstrand: I don't think that obtaining clean mountinfo is possible though
[13:36] <zyga> jdstrand: unless I'm missing something it will always contain the real data, even if we managed to unmount everything in clasic (which we cannot)
[13:37] <sergiusens> zyga the important question is, are you going to target the correct mailing list for the announcement this time ;-)
[13:37] <zyga> sergiusens: for what? :)
[13:38] <zyga> jdstrand: as for SRU we have a more nested problem to solve, I need to talk to pitti about it
[13:38] <zyga> pitti: can you perhaps help me with a little SRU problem
[13:39] <sergiusens> zyga snapd, snap-confine, ubuntu-core
[13:39] <sergiusens> zyga I feel like I am the only one using snapcraft-announce!
[13:39] <zyga> pitti: there's snap-confine 1.0.38-0ubuntu0-something as a pending SRU, I'd like to kill that one and instead upload the one that is currently in the queue here:
[13:39] <zyga> sergiusens: I agree and I really should use it
[13:39] <zyga> pitti: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
[13:40] <zyga> pitti: or perhaps even .42 from yakkety if mvo manages to release snapd today
[13:41] <zyga> pitti: I starte verifying the .38 version but I realized it errnously links to bug https://bugs.launchpad.net/snap-confine/+bug/1597842
[13:41] <mup> Bug #1597842: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Invalid> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1597842>
[13:43] <zyga> pitti: from my POV the version under SRU currently is okay except that it doesn't fix this particular bug; we can probably either mark it as failed, remove the bug and mark it as passing elsewhere or just skip it entirely and go to .41 or .42
[13:43] <zyga> pitti: I want to avoid extra delays so I'd appreciate any insight you may give me
[13:43] <mup> PR snapd#2006 closed: debian: merge 2.15.2ubuntu1 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2006>
[13:49] <mup> PR snapd#2008 opened: overlord/state: prune old empty changes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2008>
[13:50] <zyga> jdstrand: do you have a suggestion on how snap-confine could do something differently to make docker work?
[13:57] <zyga> hmm
[13:58] <pitti> zyga: no problem, I can cancel that SRU if you want, i. e. we remove it from -proposed; does the next upload address the same bugs also?
[13:58] <zyga> pitti: yes, it's a superset
[13:58] <pitti> zyga: if it doesn't fix everything, that's not a problem -- there will always be the next SRU
[13:58] <zyga> pitti: (full upstream releae rather than a cherry-picked one)
[13:59] <pitti> zyga: we just must pull an SRU if it regresses something that worked before
[13:59] <zyga> pitti: hmm
[13:59] <zyga> pitti: that's not the case here
[13:59] <zyga> pitti: the fix in .38-0ubuntusomething is just partial
[13:59] <zyga> pitti: there are no regressions, I just want to find a smooth way to eventually update everyone to .42
[13:59] <pitti> zyga: hm, http://launchpadlibrarian.net/285662383/snap-confine_1.0.38-0ubuntu<IP_ADDRESS>_1.0.41-0ubuntu2~16.04.1.diff.gz removes a metric ton of previous changelogs -- is that a rebase error?
[14:00] <pitti> ah, it's more like a backport
[14:00] <pitti> zyga: well, as you wish -- verify 38 and we release it, or skip it and I review/acept .41 "over" it
[14:00] <zyga> pitti: yes, I think that's more accurate
[14:01] <zyga> pitti: ok, I cna finish the verification, what should I do about bug https://bugs.launchpad.net/snap-confine/+bug/1597842 then? just mark it as verification-done?
[14:01] <mup> Bug #1597842: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Invalid> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1597842>
[14:02] <pitti> zyga: I'd just reopen it and clear the tag after releasing the update (that auto-closes the bug)
[14:02] <zyga> ok
[14:02] <zyga> so I'll reopen and re-verify this with .41 that really fixes it
[14:04] <pitti> zyga: ok; otherwise current SRU is good?
[14:04] <zyga> pitti: let me verify the last two items
[14:04] <morphis_> pitti: thanks a lot for https://launchpad.net/ubuntu/+source/nplan/0.12~16.04 !
[14:05] <pitti> zyga: rihgt, please officially say "works" on some of the bugs
[14:05] <zyga> jdstrand: curious, how did you debug the docker issue, I think that is pretty esoteric :)
[14:05] <zyga> pitti: will do
[14:05] <pitti> morphis_: yw! it needs to grind through the machinery now, and we can hopefully release it in a week
[14:17] <jdstrand> zyga: since we are in our own mount namespace, I would think we could unmount other snaps to close down the info leak (so long as the unmount didn't propogate. I'm not sure how that would work for /tmp/snap.rootfs_*
[14:18] <jdstrand> zyga: I found it by noticing that the docker log entry was complaining about that file not existing. I was assuming it was confused about the mount namespace and that /sys was mounted wrong, but thought I'd check out the low hanging fruit and just take docker at its word about the file it was trying to access not existing
[14:19] <jdstrand> zyga: and that turned out to be the problem
[14:21] <zyga> jdstrand: well, we might (extra complexity for content sharing) but why why would that matter? we'd still see the load of tmpfs entries
[14:22] <jdstrand> zyga: I don't think that would complicate content sharing-- we are still mounting the target in SNAP_DATA
[14:23] <sborovkov> Hello. Just updated my classic image. Now getting this: Sep 27 14:21:34 ubuntu snap[6727]: this GOARM=6 binary. Recompile using GOARM=5.
[14:23] <sborovkov> This snap ran before just fine
[14:23] <sborovkov> Any idea what's going on
[14:23] <jdstrand> zyga: that wouldn't matter for the docker case, you are right. that would only prevent an info leak (leaking all installed snaps) via mountinfo. as it happens there are other leaks there due to accesses in /proc, but we have work items to address that in the medium term
[14:23] <zyga> jdstrand: I can experiment quickly but I doubt that would change anything for docker
[14:23] <zyga> jdstrand: mountinfo requires devmode, it's not readable
[14:24] <jdstrand> zyga: or mount-observe
[14:24] <jdstrand> zyga: I'm not saying it is a world burning problem
[14:24] <zyga> jdstrand: hmm, interesting, yes
[14:25] <jdstrand> just that it is a leak
[14:25] <jdstrand> unfortunately due to noisy denials due to various libraries, I suspect people will specify mount-observe a lo
[14:26] <jdstrand> t
[14:26] <jdstrand> but, like I said, we leak things via /proc. this shouldn't distract for /media or network-namespace or really whatever else is on your plate atm. just wanted to mention it
[14:27] <jdstrand> as for /tmp/snap.rootfs_*, that would be worth looking into I think (at least after a few high prioirty items are off your list), but I'm not sure what to do there
[14:28] <jdstrand> zyga: ^
[14:30] <ralsina> sergiusens: https://github.com/snapcore/snapcraft/pull/813 is ready for a review when you have a spare moment
[14:30] <mup> PR snapcraft#813: "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/813>
[14:30] <zyga> jdstrand: well, yeah, I think this is a tough problem, mouninfo will always tell the truth
[14:31] <sergiusens> ralsina will do, thanks for working on this!
[14:32] <jdstrand> zyga: the good news is there shouldn't be a lot of software that is parsing mountinfo for the reasons that docker is, and we have a workaround for docker (and again, it is arguably a bug in docker)
[14:32] <ralsina> sergiusens: np, ping me for anything you see there.. 1st snapcraft branch so there will surely be something horrible :-)
[14:33] <sergiusens> ralsina nah, all good, I am holding off moving away from docopt until this lands so you don't take a hit
[14:33] <ralsina> wee, kill docopt :-)
[14:34] <jdstrand> mectors: hey, did you get my email regarding bug #1627309 ?
[14:34] <mup> Bug #1627309: bluetooth-control noble.js not working <Snappy:New> <https://launchpad.net/bugs/1627309>
[14:42] <sborovkov>  Hello. After updating classic image I am now getting this for all of my snaps which were working before... Any ideas? : Sep 27 14:21:34 ubuntu snap[6727]: this GOARM=6 binary. Recompile using GOARM=5.
[14:48] <ogra_> sborovkov, was that something cross compiled ?
[14:49]  * ogra_ wonders why anything would use 5 or 6 on ubuntu ... given we only support ARMv7
[14:50] <mup> PR snapd#2009 opened: tests: add firewall-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2009>
[14:50] <sborovkov> ogra_: no
[14:51] <ogra_> so it only howed up ater a snapd upgrade ?
[14:51] <sborovkov> ogra_: I compiled that snap on rpi3 on ubuntu mate. everything worked. Got latest updates. So I guess newer snapd. After that everything stopped working with those errors. And something about not supported floating architecture
[14:51] <ogra_> *showed up after
[14:52] <ogra_> right, looks like napd itself was built for ARMv6 without hardfloat
[14:52] <ogra_> *snapd
[14:52] <ogra_> mvo, zyga ^^^
[14:52] <ogra_> (i dont see such issue on the allo-snap images though)
[14:52] <ogra_> *all-
[14:53] <sborovkov> I am pretty sure someone else had similar issue some time ago. I remember seeing this here. But don't remember when it happened or why.
[14:53] <ogra_> right
[14:55] <mup> Bug #1627692 opened: Error when model file is not in $HOME <Snappy:Confirmed> <Ubuntu Image:Invalid> <https://launchpad.net/bugs/1627692>
[14:56] <mvo> sborovkov, ogra_: I think this is fixed with a updated snap-confine, the aux vector was not passed along and this confused go programs
[14:56] <zyga> jdstrand: hmm
[14:56] <zyga> er
[14:56] <zyga> hmm
[14:56] <zyga> jdstrand: sorry, I didn't notice your name was in the bugger
[14:56] <zyga> buffer
[14:56] <ogra_> mvo, ah, perhaps the snap-confine that is stuck in proposed ?
[14:57] <ogra_> snapd should have a versioned dep if thats the case
[14:57] <sborovkov> ah ok. So I guess I need to use proposed to make sure it works.
[14:58] <zyga> sborovkov: try the ppa perhaps
[14:58] <zyga> sborovkov: or build 1.0.42 from the tarball on github
[14:58] <zyga> sborovkov: packaging is on git.launchpad.net/snap-confine
[15:00] <mvo> ogra_: I think something else broke it, but I don't remember the details
[15:00] <mvo> ogra_: hm, maybe I do
[15:00] <sborovkov> zyga: what ppa should I use?
[15:00] <ogra_> well, if we break everyones RPi classic install regarding snaps after we told everyone to use classic, thats a bad thing
[15:01] <zyga> sborovkov: aww, I never remember, sorry
[15:01] <zyga> sborovkov: can you try the package in yakkety?
[15:02] <sborovkov> zyga: ok. I will try it today/tomorrow. Will tell you if that does not work. (if either of them does not work).
[15:02] <zyga> sborovkov: thanks
[15:09] <jdstrand> zyga: no worries
[15:11] <mup> PR snapd#2010 opened: many: create auth.json for the freshly created user in `snap create-user` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2010>
[15:15] <zyga> jdstrand: can I just mark https://bugs.launchpad.net/snap-confine/+bug/1584456 as verification-done based on the presence of the extra apparmor rule?
[15:15] <mup> Bug #1584456: apparmor denial using ptmx char device <apparmor> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <linux (Ubuntu):Confirmed for tyhicks> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1584456>
[15:16]  * ogra_ puts on an evil grin ...
[15:17] <jdstrand> zyga: yes. you can also say that 'apparmor_parser -QTK /etc/apparmor.d/usr.lib.snapd.snap-confine' returns with no errors and show that it is present in 'sudo aa-status|grep snap-confine'
[15:17] <ogra_> mvo, so where is that script you said you would write if you ever had to touch meta again ? (i see you added xdelta today)
[15:17] <ogra_> :)
[15:17] <jdstrand> zyga: that is sufficient for these policy updates that only allow more access (ie, it can't regress with more access and you demonstrate the policy compiles and is loaded)
[15:18] <jdstrand> zyga: (sufficient when there isn't a simple test case)
[15:19] <jdstrand> zyga: it is nice to prove that it fixes it, but when you don't have the ability to do that, proving it doesn't regress is good enough with policy updates like this
[15:21] <zyga> jdstrand: thank you :)
[15:22] <ogra_> hmm, why does the PPA actually check package versions against proposed ... it tells me nplan and initramfs-tools have newer versions available ...
[15:22]  * ogra_ checks the PPA setup ...
[15:23] <ogra_> no, definitely pointing to -updates ... as it should ... weird
[15:23] <ogra_> cjwatson, is there a bug open for that ? ^^
[15:24]  * ogra_ assumes there is ... i cant be the first one noticing that
[15:28] <cjwatson> ogra_: not sure, probably, various bugs about ancestry not being ideal
[15:28] <ogra_> yeah, k
[15:28] <ogra_> i wont file one then
[15:29] <ogra_> (even though it is a lie, it is a good warning mechanism that i need to take action before it migrates)
[15:32] <ogra_> oh man ... that initramfs-tools in -proposed will make the size explode :/
[15:33] <cjwatson> ogra_: Yeah, that's why it wouldn't be trivial to change.  It would probably need multiple indicators that look slightly different.
[15:34] <zyga> ok, verification done
[15:34] <zyga> pitti: I've verified all the other issues, I will now ask for the SRU in ubuntu-release
[15:35] <ogra_> cyphermox, hmm, looking at http://launchpadlibrarian.net/286301974/initramfs-tools_0.122ubuntu8.1_0.122ubuntu8.2.diff.gz ... how do you actually make sure dhclient is in the initrd ? i dont see a hook anywhere that would copy it in
[15:36] <ogra_> cydizen, oh, ignore me ... i see it in the isc-dhcp package
[15:37] <ogra_> err, sorry cydizen, that was for cyphermox
[15:37] <cyphermox> isc-dhcp has the hook.
[15:37] <ogra_> yeah, just saw it
[15:37] <cyphermox> it only adds 500k
[15:38] <ogra_> thats a lot
[15:38] <cyphermox> no choice.
[15:38] <ogra_> (for an initrd that is only 2.5MB and has no NIC drivers in it at all :) )
[15:38] <ogra_> (like ours)
[15:39] <cyphermox> there isn't a choice --- there are conflicting priorities here, and IPv6 needs isc-dhcp in the initramfs to work.
[15:39] <cyphermox> (that's for MAAS, but it's relevant to any network where you want to "netboot" over ipv6)
[15:39] <ogra_> well, we exclude all modules from the core initrd
[15:39] <ogra_> so it wont affect us at all
[15:40] <ogra_> just the growth will
[15:40] <cyphermox> well you can always explicitly remove the hook
[15:40] <ogra_> indeed ... but ... well ... moar hacks
[15:40] <cyphermox> or I suppose we can come up with an environment parameter to say "no, don't install isc-dhcp"
[15:40] <cyphermox> there's only so much that can be done.
[15:40] <ogra_> yeah, via initramfs.conf
[15:41] <ogra_> our initrd has in general become a horrid thing ...
[15:42] <ogra_> 34MB on my desktop install
[15:42] <cyphermox> heh
[15:42] <cyphermox> 34M is generally not a big deal
[15:42] <ogra_> a few yeqars ago that would have counted as rootfs :P
[15:42] <ogra_> it slows down your boot
[15:42] <zyga> jdstrand: I'm wondering if we can not mount all of / as rslave
[15:42] <ogra_> you need to load it from disk
[15:43] <ogra_> and then wait til the kernel decompressed it (on arches where that happens)
[15:43] <cyphermox> replacing klibc (which is partly why isc-dhcp comes in) is long overdue.
[15:43] <zyga> jdstrand: or do some trick that would let us do make / rslave and then bind mount "vanilla" /media over
[15:43] <ogra_> well, you cant actually replace klibc
[15:43] <ogra_> you only start duplicating more of it with glibc tuff
[15:43] <ogra_> *stuff
[15:44] <cyphermox> of course you can get rid of it, most things already don't use it at all
[15:44] <ogra_> well, once someone re-writes run-init you can
[15:44] <ogra_> but i dont see that happen
[15:44] <cyphermox> ipconfig was the biggest bit, and that's mostly replaced by isc-dhcp, unless you use ancient network boot stuff
[15:45] <cjwatson> run-init could probably just be directly copied somewhere else and relinked against glibc
[15:45] <cjwatson> Maybe with very minor changes
[15:45] <ogra_> i thought thats not possible
[15:45] <cyphermox> cjwatson: indeed.
[15:46]  * ogra_ suggested that years ago and was told so
[15:46] <cjwatson> I think at the time it may not have been worth it because there was a ton of other stuff
[15:46] <ogra_> ah
[15:46] <cjwatson> ipconfig was definitely more of an issue
[15:47] <cyphermox> run-init will be last on my list once I've run through $everythingelse and made sure there weren't packages elsewhere that depend on obscure other bits of klibc
[15:48] <ogra_> well, getting rid of the duplication is surely a good thing ... getting rid of it in favour of massive growth ... not so much though
[15:49] <davidcalle> ogra_: hey, a quick question: I'm looking ant gadget snaps and wondering: is there another possible value than "kernel" for "device-tree-origin" in gadget.yaml?
[15:49] <davidcalle> looking at*
[15:49] <ogra_> looking on my desktop that was originally installed with 3.13.0, the initrd has already grown by 5MB
[15:49] <ogra_> davidcalle, "gadget"
[15:50] <ogra_> davidcalle, but thats the default anyway ... so we dont bother to set "device-tree-origin" in gadgets where the dtb is shipped in the gadget
[15:50] <jdstrand> zyga: tyhicks had thoughts on that. I've forwarded you the info
[15:51] <zyga> thank you
[15:51] <davidcalle> ogra_: thanks!
[15:51] <ogra_> *grown by 5MB between 3.13.0 and 4.4.0
[15:51] <ogra_> davidcalle, np ...
[16:05] <mup> PR snapd#2004 closed: cmd/snap: make the buy tests run again and fix the failures <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2004>
[16:08] <mup> PR snapd#2011 opened: client, cmd: change buy command to match UX document <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2011>
[16:19] <mup> PR snapd#2012 opened: interfaces/builtin: add missing rule to allow run-parts to execute all resolvconf scripts <Created by morphis> <https://github.com/snapcore/snapd/pull/2012>
[16:20] <mup> Bug #1628193 opened: please set TMPDIR=/tmp when launching snaps <Snappy:Triaged> <https://launchpad.net/bugs/1628193>
[16:24] <mup> PR snapd#2013 opened: many: finish `snap set` API <Created by kyrofa> <Conflict> <https://github.com/snapcore/snapd/pull/2013>
[16:29] <zyga> tyhicks: thank you for the investigation wrt /media sharing!
[16:31] <tyhicks> zyga: no problem - I hope it is helpful
[16:39]  * ogra_` feels net-splitted
[17:23] <ogra_> geez ... that net-splittery today is really annoying
[17:25] <om26er> Hi! I am trying to create a local snap for a python script, how can I add source for my script code that is a local directory ?
[17:25] <nacc> om26er: your snapcraft.yaml can copy/dump from local directoriees (source: ., iirc)
[17:25] <nacc> (and as an example)
[17:26] <om26er> nacc, I tried source: /my_path it didn't pick the code from there
[17:26] <ogra_> also make sure to have the python plugin in use ... there is really no guarantee that the core snap has a python interpreter or a ceetain version of it
[17:26] <nacc> ogra_: good point :)
[17:26] <nacc> om26er: can you pastebin your snapcraft.yaml?
[17:27] <om26er> nacc, http://paste.ubuntu.com/23243296/
[17:28] <ogra_> i.e http://paste.ubuntu.com/23243298/ would get you the python2 interpreter (and just that) in your snap
[17:32] <ogra_> ah, i see you are already using it
[17:32] <ogra_> there are various issues in your snapcraft.yaml ...
[17:32] <ogra_> source: /home/om26er/Desktop/source/
[17:32] <ogra_> that should be a relative path from where your snapcraft.yaml lives
[17:32] <ogra_> command: python3 run
[17:32] <ogra_> that would only work if "run" is actually living in a dir in $PATH
[17:32] <ogra_> om26er, /my_path would mean you have actually a dir in / called my_path ... try ./my_path here
[17:32] <ogra_> i.e. relative to your snap dir
[17:32] <nacc> ogra_: i wonder if the relative path requirement should be explicit in the help? the example does say ./..., but absolute paths don't work?
[17:33] <ogra_> not sure, if $SNAP works here ... iirc there was a bug about that
[17:33] <ogra_> absolute paths would be ugly since you need to include the snap name, version etc
[17:33] <ogra_> they *can* work though ... if you put that data in
[17:33]  * nacc might be confused, but thought absolute paths worked with the copy plugin, at least
[17:34] <nacc> not important, regardless :)
[17:34] <ogra_> well, the copy plugin is dead for some obscure reason
[17:34] <nacc> yeah,that's why i said not important
[17:34] <pmcgowan> ogra_, I need help :(
[17:39] <om26er> ogra_, /my_path actually meant my local path i.e. /home/om26er/Desktop/source/
[17:39] <ogra_> right, try a relative one ... starting from where your snapcraft.yaml lives
[17:39] <om26er> ok
[18:22] <mhall119> check it out! http://mhall119.com/2016/09/desktop-app-snap-in-300kb/
[19:03] <mup> PR snapd#2015 opened: asserts: introduce AttributeConstraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/2015>
[19:29] <oparoz_> Is there an interface in the works which would allow snaps to mount NFS and Samba shares?
[19:58] <nhaines> Is snapweb still broken on the RPi2?  :)
[20:00] <jdstrand> nessita: hey, if someone wanted to file a bug against the store's review process, but not the review tools, what project would that be against?
[20:02] <pedronis> jdstrand: I think https://bugs.launchpad.net/software-center-agent
[20:04] <jdstrand> pedronis:
[20:05] <jdstrand> pedronis: thanks
[20:09] <zyga_> tyhicks, jdstrand: https://twitter.com/zygoon/status/780858109950619649
[20:11] <tyhicks> zyga_: that's quite a mount table you have there
[20:13] <zyga_> tyhicks: yep, and the kernel nicely hangs when I ran 'umount -l' later on
[20:13] <zyga_> tyhicks: you know that the kernel dies when the cursor stops blinking :)
[20:15] <tyhicks> :)
[20:15] <zyga_> tyhicks: it's late today and I was supposed to go rinding but I can easily reproduce this with a few syscalls
[20:15] <zyga_> tyhicks: perhaps a bug in the kernel, looks like it is trying to rbind the same thing recursively and happily runs out of memory, I killed the process when I saw 5GB of extra memory allocated in a few seconds
[20:29] <niemeyer> cjwatson: The spread snap doesn't work with qemu yet, sorry :(
[20:30] <niemeyer> cjwatson: It needs to be aware of the hosts file being elsewhere.. we need to address this problem in snappy itself, making it easier for that sort of reusability to occur someohw
[20:31] <cjwatson> niemeyer: aha, right, so I should just build it straight from the github repository or similar?
[20:31] <niemeyer> cjwatson: We're addressing that with lxd and docker by enabling communication with the daemons, but we don't yet have good  support for reusing classic debs generically, as that's basically a deb dependency
[20:32] <cjwatson> (for now)
[20:32] <niemeyer> cjwatson: yeah, go get https://github.com/snapcore/spread/cmd/spread should land a bin on $GOPATH/bin
[20:32] <cjwatson> all right, will give that a try later, ta
[20:32] <niemeyer> cjwatson: Sorry for the trouble
[20:33] <cjwatson> np
[20:49] <mup> PR snapd#2013 closed: many: finish `snap set` API <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/2013>
[20:52] <nessita> jdstrand, http://bugs.launchpad.net/software-center-agent/+filebug :-)
[20:55] <mup> PR snapd#2016 opened: many: rename apply-config hook to config-changing <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2016>
[21:01] <kyrofa> ogra_, are you still around?
[21:43] <mup> Bug #1628289 opened: snapd should depend on squashfuse (for use in containers) <lxd> <Snappy:New> <https://launchpad.net/bugs/1628289>
[22:30] <mup> PR snapd#2002 closed: tests: use new spread `debug` feature <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2002>


[03:00] <gnomefreak> its hard to tell someone something when they are not here
[03:00]  * gnomefreak Mr. Obvious tonight
[03:00] <ddecator> we all have our moments
[03:01] <gnomefreak> :)
[03:01] <ddecator> waiting for micah?
[03:01] <gnomefreak> ddecator: yeah
[03:02] <gnomefreak> well not so much waiting but while im here i wanted to let him know 1.9.3 built but the apps have not
[03:03] <ddecator> heh, i've been waiting for him to. did xr1.9.3 just get a new build? the one this morning kind of broke things
[03:04] <gnomefreak> ddecator: that was the one that was built last i know of. he stayed up fixing it last night but nothing else built behind it
[03:04] <ddecator> too*
[03:04] <ddecator> gnomefreak: ah, gotcha. he noticed it this morning i think
[03:04] <ddecator> FF3.7 isn't working atm because of it :p
[03:04] <gnomefreak> its not?
[03:05] <ddecator> nope, doesn't launch at all, i'm using 3.6 for now
[03:05] <ddecator> micah said the trunk is broken
[03:05] <gnomefreak> ddecator: let me see what i get after latest updates
[03:07] <gnomefreak> 1000      5953 11.6 13.2<PHONE_NUMBER>4 ?        Sl   22:06   0:03 /usr/lib/firefox-3.7a5pre/firefox-3.7  its running just not displaying it sees
[03:07] <gnomefreak> seems
[03:08] <gnomefreak> latest update i noticed was just lucid -> maverick (same versions) without the ~Lucid at the end
[03:08] <ddecator> right, you have to kill it, there is no gui
[03:08] <gnomefreak> him and chriss where working(talking about) it but i wasnt paying attention too closely
[03:09] <ddecator> when was that? i had irssi logged off all afternoon so i might have missed it
[03:10] <gnomefreak> ddecator: ~12hours ago maybe
[03:10] <ddecator> hm, that might be in my logs then, but i dont have time to check atm
[03:11]  * gnomefreak needs to work on xchat tomorrow if i get time. for some reason it wouldnt connect to irc.mozilla.org but did to deabian servers
[03:11] <gnomefreak> debian even
[03:11] <ddecator> i have trouble with mozilla's servers sometimes
[03:13] <gnomefreak> that is good to know now i dont feel like its all my fault but im fairly sure it was a setting i had
[03:15] <ddecator> mozilla's servers disconnect me for now reason probably once a week, haha
[03:18] <gnomefreak> i never really had much of an issue with them but Xchat is just being a pain in the ass since i lost my backups so i have to start working on it again
[03:20] <gnomefreak> ok im going to bed. too much work on too litle sleep
[03:20] <ddecator> haha, alright, cya
[11:16] <Lantizia> Hey is the Yahoo! default thing on a per geographical location basis?  Installed Ubuntu 10.04 several times now and I till get Google as the default.
[11:17] <Lantizia> ah hang on... topic :)
[11:18] <Lantizia> crazy crazy
[11:25] <BUGabundo_remote> wow
[11:25] <BUGabundo_remote> topic is outdated!!!
[11:25] <BUGabundo_remote> asac: time to update it
[11:40] <Lantizia> Is drag and drop of e-mails in thunderbird broken?
[11:41] <Lantizia> hmm just restarted it and now it's fine again
[12:03] <gnomefreak> it was changed back to google
[12:03] <gnomefreak> IIRC
[12:05] <gnomefreak> as for thunderbird using 3.0 drag and drop works here with the daily builds
[12:14] <gnomefreak> BUGabundo_remote: im using chmod to change permissions of a file i have is it 700 or 777? it seems that a+x doesnt work
[13:32] <BUGabundo_remote> gnomefreak: sorry, lost track
[13:32] <BUGabundo_remote> what do you want to do?
[13:32] <gnomefreak> BUGabundo_remote: i think i got it thanks
[13:32] <BUGabundo_remote> np
[13:49]  * asac checks topic
[13:50] <asac> BUGabundo_remote: better?
[13:53] <asac> Lantizia: we moved back to google before lucid relesae
[14:03] <BUGabundo_remote> asac: yes
[15:26] <mdeslaur> chrisccoulson: apple just announced 54 new vulnerabilities in webkit. Add them to the ~22 that are already present in karmic's webkit, and I think we will need to backport 1.2.1 to earlier release instead of 1.1.15.x...
[15:26] <mdeslaur> chrisccoulson: don't shoot the messenger :)
[15:26] <chrisccoulson> mdeslaur, the webkit backport of epiphany needs some work anyway - it sucks compared to the gecko version atm
[15:27] <chrisccoulson> but that's also the case for epiphany i karmic and lucid too
[15:28] <mdeslaur> well, fortunately epiphany in karmic and lucid is in universe
[16:36] <micahg> chrisccoulson: trying to get a test openjdk uploaded now
[16:36] <chrisccoulson> micahg - thanks
[16:37] <chrisccoulson> jdstrand - totem is uploaded to the PPA now
[16:37] <micahg> chrisccoulson: the caveat is maintainer is set for me, if it builds, do you know how to upload w/openjdk team as maintainer?
[16:41] <chrisccoulson> micahg - yeah, i can do that
[16:41] <micahg> chrisccoulson: k
[16:41] <chrisccoulson> what was the issue with setting the openjdk team as the maintainer anyway?
[16:42]  * chrisccoulson thinks it's a shame that PPA uploads don't count towards karma
[16:42] <chrisccoulson> i did nearly 400 uploads yesterday ;)
[16:42] <micahg> chrisccoulson: they do :)
[16:43] <chrisccoulson> oh, maybe i'll get a nice surprise tomorrow then ;)
[17:02] <jdstrand> chrisccoulson: re totem> ack
[18:33] <jdstrand> chrisccoulson: did you notice all the totem builds are ftbfs?
[18:33] <chrisccoulson> jdstrand - yeah, i'm just fixing that now
[18:33] <jdstrand> k
[18:34] <chrisccoulson> its because i changed the xulrunner build-depend to pull in 1.9.2 at the last minute
[18:34] <chrisccoulson> and it's looking in the wrong location for headers (there are no stable and unstable folders anymore)
[20:05] <fta> jdstrand, why no security updates for those?? http://www.adobe.com/support/security/advisories/apsa10-01.html
[20:17] <jdstrand> fta: I am following up with our partner packager. thanks
[20:18] <jdstrand> fta: ok, the eta in the advisory is the 10th and our partner guy said Ubuntu should have packages then too
[20:19] <fta> ok
[20:20] <jdstrand> we will get flashplugin-nonfree out on that day as well
[20:22] <fta> if you can also ask get the workaround for bug 589409 in acroread/maverick, it would be nice
[20:22] <ubot4> Launchpad bug 589409 in acroread (Ubuntu) "acroread corrupted display when using RGBA in gtk (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/589409
[20:22] <fta> jdstrand, ^^
[20:34] <jdstrand> mdeslaur: ^ you interested in that too?
[20:36] <mdeslaur> jdstrand: no, that's only for acrobat...so iamfuzz only
[20:36] <jdstrand> oh, duh
[20:37] <jdstrand> sorry, I misread that
[20:40] <micahg> chrisccoulson: good news...no 3.5.10 release w/out/3.6.4
[20:41] <chrisccoulson> micahg - yeah :)
[21:18] <micahg> chrisccoulson: I have some dependency issues w/openjdk, I'll look into it more tonight
[22:01] <Dimmuxx> How do I change which application is used to open downloaded files when I select to open them in the downloads window?
[22:01] <micahg> Dimmuxx: Edit -> Preferences -> Applications
[22:02] <ddecator> wow, i didn't have a chance to look for that..
[22:02] <micahg> Dimmuxx: should be system defaults by default
[22:02] <Dimmuxx> that's just what it should do with them when I click on a link
[22:03] <ddecator> maybe System > Preferences > Preferred Applications
[22:03] <Dimmuxx> nope
[22:03] <micahg> Dimmuxx: what's the issue?
[22:03] <Dimmuxx> tried all the obvious things
[22:03] <Dimmuxx> I download a mp3 file
[22:03] <Dimmuxx> it shows up in the Downloads window
[22:03] <Dimmuxx> I select open it
[22:03] <Dimmuxx> it opens in totem
[22:04] <Dimmuxx> I have audacious as the player for mp3 files in nautilus
[22:04] <micahg> Dimmuxx: if you open the folder by right clicking the download, and open from the folder, where does it open?
[22:04] <Dimmuxx> audacious of course
[22:04] <Dimmuxx> same thing with movies files
[22:05] <micahg> Dimmuxx: then check the preferences
[22:05] <Dimmuxx> the preferences for mp3 files are Always ask
[22:08] <Dimmuxx> and system > preferences > preferred application are rhythmbox for multimedia files btw so it can't get the info from there
[22:09]  * micahg doesn't know
[22:10] <micahg> Dimmuxx: which version?
[22:10] <Dimmuxx> it seems that google doesn't either :/
[22:10] <Dimmuxx> 3.6.4build6
[22:10] <Dimmuxx> but I don't think that's related
[22:10]  * micahg wonders if it's our build or not
[22:11] <Dimmuxx> I found a thread on the ubuntu forum from 2008 but no solution there either
[22:11] <micahg> Dimmuxx: maybe ask in #firefox on irc.mozilla.org?
[22:12]  * micahg can follow you over there
[22:12] <Dimmuxx> okay
[22:13] <ddecator> ha, i can finally connect to their servers without being disconnected right away..
[22:13] <micahg> Dimmuxx: actually #qa might be better over there
[22:14] <Dimmuxx> too much spam in #firefox?
[22:14] <Dimmuxx> are you sure it's a regression though?
[22:14]  * micahg isn't sure :)
[22:14] <Dimmuxx> since people had the same problem back in 2008
[22:15] <Dimmuxx> or 2009 http://ubuntuforums.org/showthread.php?t=1230227
[22:16] <micahg> Dimmuxx: I was wondering if it's a mime type issue, that bug is well known
[22:16] <Dimmuxx> http://ubuntuforums.org/showthread.php?t=859228
[22:16] <Dimmuxx> I pasted the wrong thread but it might be the same issue too
[22:32] <micahg> Dimmuxx: so, per #qa discussion, tru disabling ubufox, then try from the cli, xdg-open mymp3.mp3
[22:33] <Dimmuxx> xdg-open opens it in audacious
[22:34] <Dimmuxx> disabling the extension didn't work
[22:34] <micahg> Dimmuxx: that's good, I think there's an upstream bug to implement xdg-open...
[22:34] <Dimmuxx> I also tried to have open in audacious2 in the window before saving the file
[22:34] <Dimmuxx> but that didn't work
[22:34] <micahg> Dimmuxx: if you want, you can file a bug on LP and I'll try to find teh upstream
[22:35] <Dimmuxx> I wonder where it gets the information to use totem
[22:36] <Dimmuxx> It must be from somewhere
[22:36] <jdstrand> chrisccoulson: ok, I finally finished https://wiki.ubuntu.com/Testing/Firefox3.6.4Upgrade/SecurityPublication
[22:36] <micahg> Dimmuxx: is it opening in totem outside the browser or inside the browser?
[22:36] <Dimmuxx> outside
[22:36] <chrisccoulson> jdstrand, thanks, i will take a look at that in the morning
[22:36] <jdstrand> chrisccoulson: if you could look that over to make sure we are on the same page, that would be great
[22:36] <jdstrand> chrisccoulson: cool, thanks
[22:37] <Dimmuxx> micahg: It should be easy for you to reproduce
[22:37] <micahg> Dimmuxx: right, just no time right now, can try later
[22:38] <Dimmuxx> heh okay good :)
[22:40] <Dimmuxx> It works in correctly in chromium btw
[22:40] <Dimmuxx> -in
[22:41] <Dimmuxx> heh, I get more reasons to switch to it everyday.
[22:54] <jdstrand> fta: am I remembering correctly that you were/are preparing a 5.0.375.70 update for chromium-browser? (fyi, I just filed bug #591474)
[22:54] <ubot4> Launchpad bug 591474 in chromium-browser (Ubuntu) "5.0.375.70 security update available (affects: 1) (heat: 260)" [High,Confirmed] https://launchpad.net/bugs/591474
[22:54] <jdstrand> that might have been .55 I was thinking of
[23:07] <fta> jdstrand, .55 as we're tracking the stable channel now. http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html
[23:08] <fta> oh, i missed that .70
[23:08] <jdstrand> I think .70 is the new stable...
[23:09] <fta> see that. /me looking at why i missed it
[23:09] <jdstrand> fta: if you are planning a .70, would you mind making a .70 package for lucid and reference bug 591474?
[23:10] <ubot4> Launchpad bug 591474 in chromium-browser (Ubuntu) "5.0.375.70 security update available (affects: 1) (heat: 260)" [High,Confirmed] https://launchpad.net/bugs/591474
[23:10] <fta> sure
[23:10] <jdstrand> fta: thanks, feel free to put it in the same place and ping me and I'll get it uploaded, etc, etc
[23:13] <micahg> chrisccoulson: looks like we might get PGO in FF4 for free :)
[23:14] <fta> jdstrand, i already know it builds & run fine, it's been in the beta channel for ~4days. i just have to document and close the release
[23:14] <chrisccoulson> micahg - cool
[23:14] <micahg> chrisccoulson: will require gcc 4.5 though
[23:14] <micahg> so > maverick
[23:14] <micahg> >= maverick
[23:16] <jdstrand> fta: ack
[23:56]  * asac says hello
[23:56] <asac> 1am ... good time to start working ;)
[23:57]  * ddecator says hello to asac
[23:57] <asac> he ddecator
[23:59]  * BUGabundo waves back


[19:00] <dax> 15.10 dies today, right?
[19:00] <dax> !15.10
[19:00] <dax> i guess stuff needs updating for that
[19:29] <genii> Hasn't gone to old-releases yet
[19:32] <tomaw> they've stopped boucning off the proxy scanner so maybe he gave up
[19:33] <Pici> ty
[19:35] <tomaw> then again...
[20:42] <k1l_> yes 15.10 is dead from today on. but the repos stay alive some weeks.
[20:42] <k1l_> and the LTS upgrade to 16.04 is opened now
[20:42] <Pici> oh?
[20:42] <Pici> I'll give that a shot when I get home
[20:42] <k1l_> https://lists.ubuntu.com/archives/ubuntu-announce/2016-July/000208.html
[20:43] <k1l_> ^ 15.10 going eol today
[20:44] <k1l_> http://changelogs.ubuntu.com/meta-release-lts   there is xenial now, so the lts upgrade works
[20:45] <k1l_> !ltsupgrade
[20:47] <k1l_> !no ltsupgrade is <reply> The automatic LTS upgrade from 14.04 to 16.04 was scheduled when 16.04.1 LTS was released on July 21st, but due to last bug testings it has been opened on July 28th.
[20:47] <Pici> looks like it would have worked here had I not used so many PPAs and other junk
[21:20] <ikonia> so it's officially released now
[21:20] <ikonia> Pici: ahhh PPA's the bag of junk that ruins everyones machine
[21:20]  * valorie torrents all the .1s
[21:20] <ikonia> there needs to be a standard/guideline set for people hosting PPA's
[21:29] <genii> ikonia: This would definitely be an improvement over what we have now, which is a real mess
[21:29] <ikonia> you have to sign up with a check box to say you've read and understand the guidelies
[21:30] <ikonia> there are a few basic guidelines that would make it a lot safer, or clearer to use
[21:30] <ikonia> if you are found to break the guidelines you agree to - you get your repo deleted and you can't post more
[21:36] <genii> I still like the idea from a while ago now to use the launchpad API to give the user some stats about one when they use add-apt-repository
[21:38] <Unit193> What type?  And what guidelines?  People should really just be more careful when they decide to use a PPA, maybe using ppa-purge to back out too...
[21:58] <k1l_> !15.10
[22:00] <k1l_> can someone with regex bot magic make that s/in July/on July 28th/ ?
[22:00] <k1l_> i dont want to break all the variables again :X
[22:00] <dax> !-15.10
[22:00] <dax> !-wily
[22:00] <dax> !wily =~ s/in July/on July 28th/
[22:02] <k1l_> ok, i will try to keep that in mind :)
[22:43] <dax> !-amd
[22:43] <dax> considering making an actual amd factoid :|
[22:49] <Pici> amd is <reply> people used to care about amd's cpus, now they just care about their video cards, which are just ATI's
[22:50] <dax> watch out, you mentioned ati. ati was consumed by eternal glory amd so you should correct your post to glorious amd.


[14:49] <roadmr> hi
[14:49] <cr3> roadmr: hi there!
[17:30] <drizzle> anyone here using mago
[17:30] <drizzle> i am trying to execute the first example ./bin/mago -a gedit
[17:30] <drizzle> and am getting no love
[17:30] <drizzle>   File "/usr/lib/python2.6/socket.py", line 561, in create_connection
[17:30] <drizzle>     raise error, msg
[17:30] <drizzle> socket.error: [Errno 111] Connection refused
[17:31] <drizzle> http://pastebin.com/wUSjScwg
[17:31] <drizzle> anyone have any recs?
[17:40] <jibel> drizzle, hi, which release are you using ? do you have enabled accessibility ? It looks like at-spi-registryd is not running
[17:41] <drizzle> i enabled accessibility
[17:41] <drizzle> let me verify
[17:42] <drizzle> i have enable assistive technologies checked
[17:42] <drizzle> and have rebooted since enabling
[17:42] <drizzle> i am running Ubuntu 10.10
[17:42] <drizzle> with all packages up to date
[17:42] <drizzle> it was a fresh install
[17:44] <jibel> drizzle, hm, don't run as sudo but as normal user. root can't connect to the socket opened by the user.
[17:45] <drizzle> what if i have rootsudo enabled?
[17:45] <drizzle> what use to run it as?
[17:45] <drizzle> user
[17:45] <jibel> drizzle, what do you mean ? Why do you want to run the test as root ?
[17:46] <drizzle> let me retry
[17:46] <drizzle> one sec
[17:47] <drizzle> i thought i had something setup where i am always running as root
[17:47] <drizzle> but my prompt says "daz@daz"
[17:47] <drizzle> my username is daz
[17:47] <jibel> drizzle, it's clearly a bad habit to be always run stuff as root.
[17:48] <drizzle> given the situation how is the mago error resolved
[17:48] <drizzle> i would like to get cracking on this project
[17:48] <jibel> drizzle, just run
[17:49] <jibel> $ ./bin/mago -a gedit
[17:49] <jibel> drizzle, without the sudo
[17:49] <drizzle> just tried
[17:49] <drizzle> i got the same
[17:49] <drizzle> error
[17:49] <drizzle> socket.error: [Errno 111] Connection refused
[17:52] <jibel> drizzle, I tried there, and I get the same error with sudo, but the test runs fine without it. Does the command "id" indicates that you're identified as root (uid=0) ?
[17:53] <drizzle> daz@daz:~/ldtp/mago$ id
[17:53] <drizzle> uid=1000(daz) gid=1000(daz) groups=1000(daz),4(adm),20(dialout),24(cdrom),46(plugdev),111(lpadmin),119(admin),122(sambashare)
[17:53] <jibel> drizzle, looks fine.
[17:55] <drizzle> im going to start crying
[17:56] <jibel> drizzle, when you run without sudo, do you get the exact same error ?
[17:56] <drizzle> yes
[17:56] <drizzle> i have tried both
[18:00] <drizzle> Traceback (most recent call last):
[18:00] <drizzle>   File "<string>", line 1, in <module>
[18:00] <drizzle>   File "/usr/lib/pymodules/python2.6/ldtpd/__init__.py", line 51, in main
[18:00] <drizzle>     pyatspi.setCacheLevel(pyatspi.CACHE_PROPERTIES)
[18:00] <drizzle> that is the top
[18:00] <drizzle> is it something with file permissions maybe?
[18:01] <jibel> drizzle, the problem is "RuntimeError: Could not find or activate registry"
[18:02] <jibel> drizzle, there's probably something wrong with the permissions of the sockets in /tmp/orbit-daz/
[18:02] <jibel> drizzle, sometimes a logout/login may solve problems with the at-spi daemon.
[18:02] <drizzle> alright
[18:02] <drizzle> i will try that
[18:02] <jibel> drizzle, or a complete reboot will clean /tmp
[18:03] <drizzle> i just redownloaded the source
[18:03] <drizzle> bzr branch lp:mago
[18:03] <drizzle> and htis is what i get now
[18:03] <drizzle> Traceback (most recent call last):
[18:03] <drizzle>   File "./bin/mago", line 12, in <module>
[18:03] <drizzle>     from mago.cmd.main import main
[18:03] <drizzle>   File "/home/daz/mago/mago/cmd/main.py", line 10, in <module>
[18:03] <drizzle>     import ldtp
[18:03] <drizzle>   File "/usr/lib/pymodules/python2.6/ldtp/__init__.py", line 257, in <module>
[18:03] <drizzle>     _populateNamespace(globals())
[18:03] <drizzle>   File "/usr/lib/pymodules/python2.6/ldtp/__init__.py", line 60, in _populateNamespace
[18:04] <drizzle> brb
[18:04] <drizzle> going to relogin/out
[18:04] <jibel> drizzle, that's because the ldtpd daemon can't start because it can't connect to the at-spi registry hence the client fails to start.
[18:06] <drizzle> that fixed it
[18:06] <drizzle> i think what happened was when i first ran as root
[18:06] <drizzle> it set some permissoins
[18:06] <drizzle> probably incorrectly
[18:06] <drizzle> and then when i re-downlaoded source
[18:06] <drizzle> and ran as normal things were set right
[18:07] <drizzle> logout and log back in fixed it
[18:07] <drizzle> im wondeirng if it also has something to do with the fact that i use auto-login for ubuntu
[18:07] <drizzle> and actually using the command prompt sets somethign diffently
[18:08] <jibel> drizzle, cool. I think that's because you first run it as sudo, and the permissions on the socket dir were wrong.
[18:08] <drizzle> thank you jibel
[18:08] <drizzle> for the help
[18:08] <drizzle> im pretty stoked
[18:08] <jibel> drizzle, you're welcome. don't hesitate to ask if you have any questions about mago/ldtp.
[18:09] <drizzle> r u leader?
[18:09] <jibel> drizzle, no, I'm just writing tests for mago.
[18:09] <drizzle> who is leader?
[18:09] <drizzle> Ara Pulido?
[18:10] <drizzle> are you staff or volunteer?
[18:10] <jibel> drizzle, staff, I'm maintaining mago too.
[18:12] <drizzle> how long as staff?
[18:14] <drizzle> sry for the interrogation
[19:11] <drizzle> how do you determine which new tests to right?


[00:45] <andresmujica1> bugabundo: http://magazine.redhat.com/2008/10/16/video-fedora-10-connection-sharing/
[00:47] <BUGabundo> andresmujica "Biggest flaw: no built-in support for sharing across Ethernet instead of WiFi."
[00:47] <BUGabundo> (12:44:25 AM) asac: BUGabundo: cant you set metric manually in connection editor?
[00:48] <andresmujica1> read a bit more.
[00:48] <andresmujica1> a colleague here done what you want.
[00:48] <andresmujica1> did
[00:48] <andresmujica1> you must disable automatic connection, then create a new wired interface and share it
[00:49] <BUGabundo> a new wired interface or profile?
[00:50] <andresmujica1> profile i think
[00:50] <BUGabundo> but that's what I did
[00:50] <BUGabundo> I don't run dhcpserver
[00:50] <BUGabundo> so I used a new profile with manual IPs
[00:52] <andresmujica1> no need.
[00:53] <andresmujica1> nop, create a new profile with shared connection in the dropdown menu at the wired tab
[00:53] <andresmujica1> disable the automatic connection for auto eth0
[00:53] <andresmujica1> and then plug the other pc.
[00:53] <andresmujica1> and you're done
[00:53] <andresmujica1> no need for dhcpserver
[00:54] <BUGabundo> andresmujica thanks for the tips, but that was similar to what I did
[00:54] <BUGabundo> and everytime I connected the cable or wifi, NM would default route to it, instead of 3G
[00:54] <andresmujica1> hmmm..
[01:13] <andresmujica1> bugabundo: check this, it's a wifi connection, with a wired shared connection for a different laptop.  I don't have the nokia e71 here to test it with 3g (is from a colleague) but supposedly is exactly the same...
[01:13] <andresmujica1> http://www.seaq.com.co/linux/SharedInternet-wifi-wired.ogv
[01:13] <maco> andresmujica1: he's gone
[01:15] <andresmujica1> ahh ohh. next time then.. :)
[01:22] <dtchen> the problem is that it's all very smooth using iptables + interfaces(5)
[01:22] <dtchen> (i described in multiple times above)
[01:22] <dtchen> s/in/it/
[01:22] <dtchen> if you want a gui, it's not straightforward
[01:23] <maco> dtchen: that was in #ubuntu+1 not above in here
[01:23] <dtchen> maco: "above" doesn't mean in this channel; it means across whatever media
[01:23] <maco> thats not clear
[01:24] <dtchen> e-mail, identi.ca, IRC - everything short of physically speaking with him
[14:48] <BUGabundo> apw: ping
[18:54] <dupondje> 2.6.27-3-generic gave me no errors but 2.6.27-12-generic gives me again: [   40.486403] attempt to access beyond end of device ... (dmraid)
[18:55] <dupondje> any id how to solve ? :s
[20:42] <XDS2010> eqisow ?
[22:09] <andersk> Bug 34376 has been fixed in jaunty, but the patch introduced a minor regression in the download size calculation.
[22:09] <andersk> Should I close it and open a new bug for the fix, or should the priority for this bug just be reduced?
[22:10] <thomasdelbeke> http://paste.ubuntu.com/118604/
[22:10] <thomasdelbeke> Hi
[22:10] <thomasdelbeke> I am experiencing trouble with jaunty
[22:10] <andersk> thomasdelbeke: #ubuntu+1
[22:10] <thomasdelbeke> on an acer aspire
[22:10] <thomasdelbeke> ok
[22:19] <ia> hello. i have a problem with eeepc (901): it doesn't work with external lcd display - hotkey for switching external display unactive and in System->Preferences->Screen Resolution "detect displays" doesn't show external display. I use jaunty with latest updates. Someone have deal with this?
[22:36] <dupondje> Why doesn't apt-get --reinstall install doesn't place the config files back from the package ?
[22:36] <dupondje> if u removed/broke a config file
[22:36] <dupondje> u can't get it back by reinstalling ...
[23:05] <dupondje> https://bugs.launchpad.net/ubuntu/+source/php5/+bug/329053
[23:05] <dupondje> fix :(
[23:17] <geser> dupondje: dpkg assumes that if a configuration file is missing it was done on purpose by the admin and respect it
[23:17] <geser> there is a option to force dpkg to reinstall missing configuration files
[23:17] <dupondje> what is it ?
[23:18] <dupondje> (the option)
[23:18] <geser> --force-confmiss (for dpkg)
[23:19] <geser> but like any other --force-* options you should know what you are doing (at least the description in the manpage)
[23:19] <dupondje> thx !
[23:21] <dupondje> another bug
[23:21] <dupondje> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/329880
[23:24] <IntuitiveNipple> dupondje: I've repled to the bug
[23:24] <IntuitiveNipple> s/repled/replied/
[23:24] <dupondje> thx
[23:24] <dupondje> well seems it worked some time
[23:24] <dupondje> updated to newest kernel
[23:24] <dupondje> and broken again
[23:25] <dupondje> u know what patch it was ?
[23:28] <IntuitiveNipple> The original bug which actually tried to drive the heads to an invalid cylinder has been mitigated, but the system still reports the attempt
[23:28] <IntuitiveNipple> I've added a link to the original bug report now
[23:29] <IntuitiveNipple> My patch was in the partition table reading functions, but that was rejected. Hence you still see those problems where raid devices are scanned before the raid array is constructed
[23:38] <dupondje> lets see if somebody responds
[23:38] <dupondje> https://bugs.launchpad.net/ubuntu/+source/php5/+bug/329053
[23:38] <dupondje> is also a big bug imo :(
[23:39] <dupondje> half of PHP sites broken ...
[23:39] <dupondje> (y)