[08:40] <zyga> good morning
[08:42] <didrocks> hey zyga
[08:49] <noizer> good morning!
[08:57] <zyga> hey :)
[08:57] <zyga> how are you doing
[08:57] <zyga> (zero days since the last terminology change ;)
[08:58] <dholbach> put that in the topic :)
[09:01] <ogra_> capaskillfaces !
[09:01] <zyga> ogra_: now you have to read that backwards
[09:01] <ogra_> heh
[09:02] <ogra_> security imlpementation du jour: "interfaces with reversed plugs, 9,90€ ... kids plate, 6,50€"
[09:03] <zyga> ogra_: uk plugs or us plugs?
[09:03]  * zyga falls screaming into the abyss
[09:03] <ogra_> doesnt matter as long as they are reversed :)
[09:03]  * ogra_ wishes we would actually care for some stability inseatd
[09:04] <zyga> ogra_: nah, this doesn't affect stability in any way
[09:04] <zyga> ogra_: I'm glad we changed it, it was backwards
[09:04] <ogra_> zyga, it occupies dev rtecources
[09:04] <ogra_> *ressources
[09:05] <zyga> ogra_: and saves user resources later on
[09:05] <ogra_> i still cant use classic on arm64 ... i still can install all gadget snaps from froreign arches
[09:05] <ogra_> (on a running system)
[09:05] <zyga> ogra_: well, different resources
[09:05] <ogra_> webdm doesnt really work
[09:05] <ogra_> etc etc
[09:05] <zyga> ogra_: webdm has tons of love lately
[09:05] <ogra_> there are tonms of things that need fixing before release
[09:05] <zyga> ogra_: yeah, I know
[09:06] <ogra_> but we are changing terminology of core features instead
[09:06] <zyga> ogra_: we're all working towards getting there
[09:06] <ogra_> zyga, by 16.10 ?
[09:06] <zyga> ogra_: 16.04!
[09:06] <ogra_> what we have today isnt release worthy yet and still needs liots of work on all levels ...
[09:06] <zyga> ogra_: in reality renames only affected my work
[09:08] <ogra_> zyga, and everyone who has snaps in the store
[09:08] <ogra_> (or who wants to have them in the store for release)
[09:08] <zyga> ogra_: they didn't use interfaces yet, they will but nothing in the store uses them now
[09:09] <ogra_> all my (three yet, because i gave up packaging when there was the announcement) snaps use them with migration-skill
[09:09] <zyga> mmmm, okay, I give you that
[09:10] <ogra_> and i have a few more that i had to re-do from scratch three times ...
[09:10] <ogra_> for me thats fine, but for people that want their stuff in the store for release it is probably not
[09:20] <sergiusens> ogra_, hey, I'm late to the party; my 410c boots android and can't make it boot from the sdcard (using your image on p.c.c); any ideas?
[09:21] <noizer> How can i make from my app a service so I can start and stop it with the rest api?
[09:26] <noizer> zyga
[09:26] <zyga> noizer: you'd have to talk to snapd and use an appropriate request, you'd also need an interface to talk to snapd in the first place (I'm making one)
[09:26] <zyga> noizer: a bit busy now, perhaps it's not all ready yet but that's the idea
[09:28] <noizer> hmmm
[09:29] <zyga> noizer: you want snappy services but I'm not sure if that's on the rest api today
[09:30] <noizer> zyga https://developer.ubuntu.com/en/snappy/guides/rest/
[09:34] <zyga> noizer: always look at docs/rest.md
[09:34] <zyga> noizer: that's the current version
[09:34] <zyga> noizer: this one is probably a few days old
[09:35] <noizer> its the same and there i can see /2.0/snaps/name/services
[09:35] <noizer> https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#20snapsnameservicesname zyga
[09:36] <ogra_> sergiusens, did you set the dip switch to SD boot at the bottom of the board ?
[09:37] <sergiusens> ogra_, no, I searched the manuals/internet for some sort of information about that
[09:37] <ogra_> well, make sure that one switch is set to "on"
[09:37] <ogra_> else it wont even try the Sd
[09:37] <sergiusens> ogra_, oh, now that I turn it upside down it is obvious :-P
[09:39] <sergiusens> ogra_, thanks
[09:39] <ogra_> works ?
[09:40] <sergiusens> ogra_, yeah; well I don't see SElinux anymore and cloud-init instead ;-)
[09:40] <ogra_> good
[09:41] <ogra_> tell me if the upgrade works .... there are newer kernel and os snaps in the store for it
[09:41] <sergiusens> sure, let me setup wifi first
[09:41] <ogra_> yeah
[09:42] <ogra_> one of my cats seems to have had some bad fight tonight, she is pretty injured on one leg, i'll need to go to the vet soon
[09:42] <ogra_> (no idea if/when i can return)
[09:42] <sergiusens> k
[09:42] <sergiusens> good luck with that
[09:43] <ogra_> yeah
[09:44]  * ogra_ hopes for the best ... seems she can still stand up
[09:44] <sergiusens> ogra_, oh, that bad
[09:44] <ogra_> yeah
[09:44] <ogra_> i guess a dog or racoon
[09:51] <noizer> ogra_ do you know how that i can my apps to services. So i can start and stop my services with the REST api
[09:52] <ogra_> i saw the mail discussion
[10:00] <noizer> zyga about the python api does i need to take a fork of ubuntu-core/snappy?
[10:06] <zyga> noizer: no, please start with an empty repo
[10:06] <zyga> noizer: that will make it easier to work with on pypi later
[10:06] <zyga> noizer: for releases / qa
[10:07] <zyga> noizer: start with a simple package that has all the public APIs in the client/ package today (use python conventions rather than go conventions for methods though)
[10:07] <zyga> noizer: and we can fill in the blanks, most of the stuff is really easy, you just have to define the input and output format (data is almost always json)
[10:08] <ysionneau> morning
[10:08] <zyga> o/
[10:09] <ysionneau> stupid question: how would one put a binary (actually a shell script wrapper) in the snap package?
[10:09] <ysionneau> I mean by having this script at the same level as the snapcraft.yaml
[10:09] <ysionneau> and not cloned as a remote part
[10:09] <ysionneau> s/cloned/fetched/
[10:10] <zyga> ysionneau: use a part with source: .
[10:10] <zyga> ysionneau: I use that all the time
[10:10] <noizer> zyga oooh ok. an other question about Services. when is an app a service?
[10:10] <ysionneau> right, I knew this had a simple solution, thanks!!
[10:10] <zyga> ysionneau: e.g. https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml
[10:11] <zyga> noizer: there are no services, the terminology for that is "all things are apps/applications"
[10:11] <zyga> noizer: some applications run in the background
[10:11] <ysionneau> ah so I should do a Makefile which will cp my wrapper in $(DESTDIR) ?
[10:11] <zyga> noizer: an application runs in the background if it has an extra line in the snap.yaml / snapcraft.yaml that says how exactly it runs in the background
[10:11] <ogra_> ysionneau, you can use the copy plugin
[10:11] <ogra_> ysionneau, http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml
[10:11] <zyga> ysionneau: you can, there's also some snapcraft plugin for doing just that but I don't remember, would have to refer to snapcraft source code again
[10:12] <ogra_> ysionneau, (see what it does with the README)
[10:12] <ysionneau> awesome, you guyz rock
[10:12] <zyga> ysionneau: but a trivial makefile with the right targets is more scalable if you don't want to remember :)
[10:12] <zyga> thanks ogra_ :)
[10:12] <ogra_> makfile will indeed work as well :)
[10:12] <zyga> nothing like good old make
[10:12] <ysionneau> yes
[10:12]  * ysionneau likes makefiles
[10:13] <zyga> https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile
[10:13] <zyga> sergiusens: https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile#L3
[10:13] <ysionneau> yep I wa son it
[10:13] <ysionneau> was on*
[10:13] <zyga> sergiusens: small thing I found, snapcraft ignores /usr/local and if your executables are there, it crashes
[10:13] <noizer> zyga why is there then in de REST api some things about services
[10:14] <zyga> noizer: probably legacy
[10:14] <zyga> noizer: we may rename the API
[10:14] <zyga> noizer: for now you can call it a service but most places call it background application already
[10:17] <noizer> zyga oooh ok so if i add something like deamon: simple it will be a background app
[10:20] <zyga> noizer: yes
[10:20] <noizer> zyga ok
[10:20] <zyga> noizer: (we plan to consolidate that naming so expect some changes later today/next week) but yes
[10:21] <noizer> zyga thats no problem it was just confusing xD
[10:23] <zyga> noizer: yep
[10:34] <renat> Hi all! It's Renat from Screenly=)
[10:35] <renat> kyrofa, hi!
[10:35] <renat> I commented in snapcraft's copy plugin pull request.
[10:36] <renat> I think - that if file is absolute symlink - we should copy it as a symlink.
[10:36] <dholbach> renat, might take a bit longer until kyrofa is up
[10:38] <renat> dholbach, thanks. I will visit later today.
[10:59] <zyga> renat: hey
[10:59] <renat> zyga, hi!
[11:01] <noizer> zyga can I uses ports within apps because snapcraft says it was unexpected
[11:02] <zyga> noizer: nope, ports was removed
[11:02] <zyga> noizer: it never really did anything
[11:02] <noizer> heheeh xD
[11:02] <zyga> noizer: so it was either removed now (I didn't check) or it's in the queue for removal
[11:03] <zyga> noizer: just don't use it, nothing changes
[11:03] <noizer> zyga ok how can i say to my background app that he may uses some sockets because there i got a permission error?
[11:04] <zyga> noizer: which socket?
[11:04] <noizer> tcp/ip
[11:04] <noizer> zyga
[11:05] <zyga> noizer: do you want to use the network or create a network service?
[11:05] <zyga> noizer: (do you want to be like apache or connect to apache) in less technical terms
[11:05] <noizer> i needed both
[11:06] <zyga> noizer: ok, you need to use two interfaces for that:
[11:06]  * zyga looks
[11:06] <zyga> noizer: the new names for the interfaces are "network" (you can talk to other things on the network) and "network-bind" (they can talk to you, you can bind to ports, etc)
[11:07] <zyga> noizer: but I think today the only way to use them is to use old-security interface with the names "network-client" and "network-listener"
[11:07] <ogra_> i found network-client more intuitive for the first one
[11:07] <sergiusens> zyga, of all todays, today I can't do irc; prepping for travel here; so a bug or tlaking to kyrofa would be best
[11:07] <ogra_> "network" sounds like "globally all network features"
[11:07] <noizer> zyga does i need to use then slots and ect
[11:07] <zyga> noizer: I'll land a lot of interfaces today, but you still need to use the old-security with the images that are out there
[11:08] <zyga> ogra_: "you want to connect to the network" was the rationale
[11:08] <ogra_> zyga, sure, but the other options all have suffixes
[11:08] <ogra_> so it sounds pretyt global to me
[11:08] <zyga> noizer: you have to use the "slot" but next week that becomes "plug" (you plug old security into your application)
[11:09] <zyga> noizer: https://github.com/ubuntu-core/snappy/pull/580
[11:09] <ogra_> (me shuts up bfore anyone changes any names again)
[11:09] <zyga> noizer: virtues of a development release
[11:09] <zyga> ogra_: I shall name you argo
[11:09] <zyga> ;D
[11:09] <zyga> ogra_: most don't
[11:09] <zyga> ogra_: all the old security bits were modelled after capabilities
[11:10] <zyga> ogra_: and now that each connection has two sides, we can discard half of those in most cases
[11:10] <noizer> dam it is very confusing with all these versions
[11:10] <zyga> ogra_: e.g. mir is just one interface, no mir-client, mir-server
[11:10] <zyga> ogra_: same with docker
[11:10] <zyga> noizer: just wait till monday please
[11:10] <zyga> noizer: it's settling
[11:10] <ogra_> zyga, lol
[11:10] <ogra_> high hopes
[11:10] <zyga> noizer: we'll make the docs all up to date
[11:11] <zyga> ogra_: I actually like this change a lot, much better than having mir-server being provider by ubuntu-core or kernel snaps
[11:11] <zyga> ogra_: it's just one interface, mir
[11:11] <ogra_> (my lol was rather about the "it's settling" )
[11:11] <zyga> ogra_: you have an app that offers mir slot and many apps that plug into that
[11:11] <zyga> ogra_: (oh, it is, really)
[11:11] <ogra_> i belive it when i see it
[11:11] <zyga> ogra_: (we had a three hour meeting yesterday and it was very productive)
[11:11] <zyga> ogra_: very well :)
[11:15] <noizer> zyga will it for now be enough to use this? http://pastebin.com/7sHfGU3Z
[11:16] <zyga> no, "old-security" rather than "migration-skill"
[11:16] <zyga> and also do "network-client"
[11:16] <zyga> (second cap)
[11:16] <zyga> because you need both
[11:16] <zyga> by default snaps are offline
[11:24] <noizer> zyga pfft  {'caps': ['network-listener', 'network-client'], 'type': 'old-security'} is not valid under any of the given schemas
[11:26] <didrocks> noizer: using snapcraft master?
[11:26] <noizer> i think so
[11:26] <noizer> didrocks
[11:26] <didrocks> s/type/interface/
[11:26] <didrocks> (since yesterday late ;))
[11:26] <zyga> noizer: "interface", not "type"
[11:27] <zyga> thanks didrocks :)
[11:27]  * zyga works on adding about a dozen new interfaces to snappy
[11:37] <ogra_> Mar  4 11:35:33 localhost kernel: [  114.926577] audit: type=1400 audit(1457091333.026:13): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=1  capname="dac_override"
[11:37] <ogra_> Mar  4 11:35:33 localhost kernel: [  114.926680] audit: type=1400 audit(1457091333.036:14): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=2  capname="dac_read_search"
[11:37] <ogra_> hmm
[11:37] <ogra_> i guess webdm needs updating :)
[11:40] <ogra_> though this is funny since webdm loads the unconfined profile first
[11:41] <noizer> didrocks zyga uses:
[11:41] <noizer>   listener:
[11:41] <noizer>     interface: old-security
[11:41] <noizer>     caps: [network-listener, network-client]
[11:41] <noizer> like that?
[11:41] <sergiusens> zyga, did the plug<->slot thing make it into edge?
[11:41]  * sergiusens wonders about releasing a supporting snapcraft
[11:42] <zyga> sergiusens: https://trello.com/c/nUsc10Ra/43-swap-plugs-and-slots-around
[11:42] <zyga> sergiusens: https://github.com/ubuntu-core/snappy/pull/580
[11:42] <zyga> sergiusens: needs review, then needs release (I have no idea how that works yet though)
[11:42] <zyga> sergiusens: let's work together on coordinating this today
[11:42] <zyga> sergiusens: I'd like to end the week in a stable state
[11:43] <zyga> noizer: looking
[11:43] <zyga> noizer: yep
[11:43] <zyga> noizer: and refer to "listener" from slots in your snap, tomorrow this just changes to "plugs"
[11:44] <noizer> zyga what will be the syntax?
[11:45] <zyga> noizer: look at existing examples
[11:45] <zyga> noizer: https://github.com/ubuntu-core/snapcraft/blob/master/examples/webchat/snapcraft.yaml
[11:45] <zyga> noizer: tomorrow we just swap slots/plugs around
[11:46] <zyga> noizer: and next week, old-security can be somewhat replaced by native interfaces: [network, network-bind]
[11:47] <zyga> noizer: I'll announce it when it can be used
[11:47] <stevebiscuit> ogra_: this should solve that: ttps://code.launchpad.net/~stevenwilkin/webdm/skill-to-interface-snap-yaml/+merge/287760
[11:47] <zyga> noizer: snapcraft examples are the best way to learn :)
[11:47] <stevebiscuit> s/ttps/https/
[11:47] <ogra_> stevebiscuit, ah, cool
[11:47] <ogra_> i'll just wait
[11:48] <ogra_> oh, crap
[11:48] <ogra_> the generic initrds are gzip compressed
[11:49] <noizer> zyga ok i still got an error but i am using snapcraft 2.3.2 is that not update to date?
[11:49] <zyga> noizer: I'm not sure
[11:50] <zyga> noizer: what did you exactly do and what the error was?
[11:50] <noizer> zyga Issues while validating snapcraft.yaml: Additional properties are not allowed ('slots' was unexpected)
[11:54] <zyga> noizer: o_O not sure, ask sergiusens, maybe your snapcraft is out of date
[11:54] <zyga> noizer: check if you can build the example I linked to
[11:54]  * zyga -> back to hacking
[12:01] <ogra_> oh crap !
[12:01] <ogra_> pitti, so my initrd now ends up with a /lib64 dir
[12:01] <ogra_> with the linker in it
[12:01] <ogra_> which results in non executable binaries
[12:05] <ogra_> yeah, moving the linker to /lib fixes it :(
[12:06] <ogra_> argh
[12:06] <ogra_> except ...
[12:06] <ogra_> Begin: Running /scripts/local-premount ... wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
[12:06] <ogra_> wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
[12:06] <ogra_> damned
[12:07] <sergiusens> zyga, we never landed that
[12:07] <sergiusens> zyga, we are going to land 7 breaking changes in a row, sorry
[12:08] <zyga> sergiusens: 7?
[12:08] <ysionneau> I'm not the only one to fight against dynamic linker issues
[12:10] <ogra_> ysionneau, well, i'm rather fighting fakechroot here
[12:10] <ogra_> bug 1553110
[12:10] <ysionneau> ah ok
[12:11] <pitti> ogra_: /lib64/*ld.so* should/could just be a symlink to /lib
[12:11] <pitti> ogra_: that's at least how it is on amd64
[12:11] <ogra_> pitti, well, indeed it isnt beacuse i hacked the outer script to just have /lib64 ... whats more worrying though is that libudev doesnt end up in the initrd at all now
[12:12] <ogra_> pitti, for the linker there is a hack in mkinitramfs for armhf already that we likely need to copy for arm64
[12:12] <sergiusens> zyga, I was being sarcastic; I was about to release yesterday but with this change cancelled the release completely
[12:12] <ogra_> it had a similar prob
[12:12] <sergiusens> it makes no sense to promote something that is going to be inverted
[12:12] <ogra_> but that doesnt explain the missing libudev
[12:13] <sergiusens> I'd just tell people to use ubuntu-core/stable
[12:13] <sergiusens> ogra_, I am almost there with the logic for this :-)
[12:13] <ogra_> sergiusens, i guess all but arm64 should work
[12:14] <ogra_> pitti, see line 337 ff in /usr/sbin/mkinitramfs
[12:14] <ogra_> not actually lib64 ... but the same issue
[12:14] <sergiusens> ogra_, oh I did see a lib64 in amd64's generic initrd and jumped to conclusions
[12:15] <sergiusens> with an ld symlink too
[12:15] <ogra_> symlink ?
[12:15] <pitti> ogra_: so I guess it'd be best to actually fix fakechroot instead of adding further hacks
[12:15] <ogra_> there shouldnt be one
[12:15] <ogra_> pitti, hmpf
[12:15] <sergiusens> ogra_, $ ls -l lib64/
[12:15] <sergiusens> total 0
[12:15] <sergiusens> lrwxrwxrwx 1 sergiusens sergiusens 34 mar  4 06:46 ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-2.21.so
[12:15] <pitti> amd64 *should* and even *must* have a /lib64
[12:15] <pitti> amd64 vs. arm64 confusion? :-)
[12:15] <ogra_> pitti, i thought colin said it shouldnt
[12:16] <pitti> no, he said we shouldn't proliferate that to other arches like arm64
[12:16] <sergiusens> pitti, nah; I was going by ogra's symptoms, not saying anything is wrong or right
[12:17] <ogra_> pitti, well, not even debootstrap creates lib64 on arm64 atm
[12:17] <pitti> right
[12:17] <pitti> I thought you just created it as workaround for that fakechroot thingy
[12:17] <ogra_> yeah
[12:17] <ogra_> and that works fine ... for everything but wait-for-root
[12:18] <pitti> so maybe create the /lib64 symlink, do the fakechroot bootstrap, and remove it again before building the image?
[12:18] <pitti> s/image/initrd/
[12:18] <ogra_> you mean hacking up update-initramfs ?
[12:18] <pitti> the place where you added it doesn't have code which runs after the initrd build?
[12:18] <zyga> rpi3 arrived
[12:18] <zyga> hmmm
[12:18] <ogra_> no
[12:19] <ogra_> well, it doesnt have code that runs "inside" the initrd
[12:19] <ogra_> thats all left up initramfs-tools hook scripts
[12:19] <ogra_> i'm just modifying the build chroot to have the dir
[12:20] <pitti> ogra_: perhaps try wiht a /lib64 -> /lib symlink?
[12:20] <pitti> instead of a symlink or even a copy *in* /lib64/ ?
[12:23] <ogra_> pitti, will do, but i doubt that will fix the missing libudev
[12:23] <ogra_> i can indeed forcefully copy it in place with a hack-hook or some such
[12:24] <ogra_> still ... not cool :(
[12:26] <noizer> zyga I need to upgrade my snapcraft what is the best way to do that?
[12:28] <zyga> noizer: please wait, we're trying to figure out when to release a compatible set of tools for everyone to use so that no confusions are spread
[12:29] <noizer> ok so i need to do nothing today on that?
[12:29] <zyga> noizer: soon you should have all the bits in master but we need to release them to make sense
[12:30] <noizer> zyga: ok how long does I need to wait for that?
[12:30] <zyga> noizer: most likely on monday, we'll decide
[12:30] <zyga> and announce this
[12:31] <noizer> OK
[12:39] <kyrofa> Good morning
[12:55] <ogra_> pitti, hmm, isnt libudev also a thing that udevd should pull into the initrd
[12:55]  * ogra_ still doesnt get why it is missing ... copying it in manually makes everything work
[12:56] <ogra_> (including the udevd that is in the initrd)
[12:56] <ogra_> oh, wow
[12:56] <ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps$ ldd $(which udevd)|grep udev
[12:56] <ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps$
[12:57] <ogra_> so it isnt linked against the lib at all ... interesting
[13:05] <ogra_> WTF !
[13:05] <ogra_> so libudev isnt in any of the initrds
[13:06]  * ogra_ wonders whats going on here
[13:10] <torbit> Hi folks
[13:12] <torbit>  I am currently trying to ensure that I am working on porting snappy core to a new board.
[13:12] <torbit> I am trying to get it to give me output via the serial console on booting up
[13:12] <torbit> anyone know where I can do that from as I can not see a grub.cfg file in boot->grub
[13:20] <pitti> ogra_: right, udevd isn't meant to link against libudev, it uses an internal (richer, but unstable/non-public) API
[13:20] <ogra_> yeah
[13:20] <ogra_> i still dont get why the lib isnt in any of the inirds
[13:21] <pitti> ogra_: I suppose the only thing that needs libudev in the initrd nomrally is wait-for-root
[13:21] <ogra_> on all arches
[13:21] <ogra_> yeah
[13:21] <pitti> $ lsinitramfs /initrd.img |grep libudev
[13:21] <pitti> lib/x86_64-linux-gnu/libudev.so.1.6.4
[13:21] <ogra_> right
[13:21] <ogra_> it isnt in any that my script built
[13:21] <pitti> ogra_: fakechroot b0rkage?
[13:22] <ogra_> (i'm 100% sure it is in the phone initrds, else they wouldnt boot at akll)
[13:22] <ogra_> the script is the same ... as is the build process
[13:23] <ogra_> i just uploaded a test version with libfakeroot and libfakechroot in the build chroot ... lets see if that changes anything
[13:23] <ogra_> (they will end up inside the initrd though ... which i was wanting to avoid)
[13:23] <pitti> ogra_: uploaded? I thought you have access to an arm64 instance to do local test builds
[13:24] <pitti> (I can give you one if you need)
[13:24] <ogra_> i do, but uploading is faster :)
[13:24] <pitti> well..
[13:25] <torbit1> erm…lost connection..did anyone say anything with regards to my last post
[13:31] <ogra_> ok, adding the t6wo libs didnt change a thing
[13:31] <ogra_> (apart from quietening the build log)
[13:32] <ogra_> pitti, did we ever find out what actually copies wait-for-root ?
[13:32] <ogra_> i cant find a hook for it
[13:33] <ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/share/initramfs-tools/*
[13:33] <ogra_> /usr/share/initramfs-tools/scripts/local:		FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-$ARCHDELAY})
[13:33] <ogra_> /usr/share/initramfs-tools/scripts/local-premount/resume:SWAPTYPE=$(wait-for-root "${resume}" ${RESUMEDELAY:-5})
[13:33] <ogra_> aha
[13:33] <ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/sbin/mkinitramfs
[13:33] <ogra_> copy_exec /usr/lib/initramfs-tools/bin/wait-for-root /sbin
[13:34]  * ogra_ bets if he adds that to some hook it will actually DTRT
[13:34] <pitti> ogra_: I don't think it's in a hook, it should be copied by the i-t core code
[13:34] <pitti> ogra_: right, that
[13:34] <ogra_> yeah, it is hardcoded in /usr/sbin/mkinitramfs
[13:35] <ogra_> let me try making it a hook, just for fun :)
[13:36] <kyrofa> beuno, if I want to ship a device with some custom kernel modules, I make a kernel snap (I assume). I make a snap to utilize those new modules, and upload it to the store. Is there anything preventing someone else (who doesn't have my kernel snap) from installing that snap which then breaks for them?
[13:37] <beuno> kyrofa, hi!
[13:37] <beuno> yes, interfaces!
[13:37] <kyrofa> beuno, ahh, okay
[13:37] <beuno> your kernel would expose interfaces for those special modules
[13:37] <ogra_> would it ?
[13:38] <ogra_> even if the user simply uses snappy config ubuntu-core and force-loads them ?
[13:39] <ogra_> kyrofa, your user would have to actually create an image using u-d-f ... you can load different kernel snaps
[13:39]  * ogra_ tried that already
[13:39] <ogra_> "a snap of this name is already installed"
[13:39] <ogra_> ;)
[13:39] <kyrofa> ogra_, interesting, okay
[13:40] <ogra_> (err: you can *not* load)
[13:42] <ogra_> kyrofa, i dont see where interfaces come into play for modules though, but beuno might know more than I
[13:42] <ogra_> (i mean, beyond the obvious .... accessing devices under /dev)
[13:43] <kyrofa> ogra_, I assume it would be more of a "the current kernel doesn't provide a slot for this interface, so I can't plug into it"
[13:43] <beuno> ogra_, you expose an interface the exposes a funcionality you don't have otherwise
[13:43] <beuno> right
[13:43] <beuno> so you can filter on it, etc
[13:44] <kyrofa> Yeah that makes sense. Even if the interface provided nothing other than the filter
[13:44] <kyrofa> Thanks beuno , ogra_ :)
[13:44] <ogra_> beuno, right, but the module would load regardless, it is only the device access you block
[13:45] <ogra_> (so my in-kernel-keylogger.ko would still work ;) )
[13:45] <beuno> correct
[13:45] <kyrofa> ogra_, right, I was really only wondering if it was possible to upload a snap to the store that requires a custom kernel snap to run
[13:45] <kyrofa> That didn't break for everyone else
[13:49] <beuno> kyrofa, does it sound like a good answer to your problem?
[13:49] <kyrofa> beuno, indeed it does, thank you!
[13:49] <beuno> w00t
[13:58] <ogra_> hmm, nope ... moving wait-for-root to an actual hook doesnt change anything
[13:58] <ogra_> sigh... this is so painful
[13:59] <ogra_> pitti, any idea what to look for in fakechroot to make it actually work ?
[14:00] <pitti> ogra_: not off-hand -- I'd start with stracing "fakechroot ldd" call (with -e trace=file) and see where things go haywire
[14:01] <ogra_> hmm, k
[14:01]  * ogra_ will have to prepare for the vet now ... i'll try that later
[14:07] <ysionneau> zyga ogra_ < about my yesterday dynamic linker issue, now it's fixed. I added some post-processing in my alchemy snapcraft plugin so that it creates wrappers for each detected ELF dynamic executables in installdir
[14:07] <ysionneau> now it does not crash anymore o/
[14:07] <ogra_> yay
[14:07] <ysionneau> I should push my alchemy plugin someday when it's a bit cleaner on my github
[14:07] <ysionneau> so that people could experiment doing cross compilation of snaps
[14:15] <zyga> ysionneau: oh, I wasn't aware of what you were doing
[14:15] <zyga> ysionneau: I think this will open a lot of very nice use cases
[14:17] <zyga> ysionneau: so you're working on what exactly? generic cross compiler support?
[14:19] <ysionneau> I'm adding a plugin for snapcraft to support "alchemy" build system (which is some kind of buildroot/Android-build-system on steroid)
[14:19] <ysionneau> instead of Android.mk it uses atom.mk
[14:19] <ysionneau> https://github.com/parrot-developers/alchemy
[14:20] <zyga> ysionneau: is parrot-developers there referring to perl6 parror vm?
[14:20]  * zyga wonders how that's all interconnected
[14:20] <zyga> parrot*
[14:20] <ysionneau> the interesting fact for snapcraft is that it would allow to generate arm32/64 snaps from your amd64 machine (cross compilation)
[14:20] <ysionneau> nop it's referring to Parrot SA
[14:20] <zyga> ah
[14:20] <ysionneau> a French company
[14:20] <zyga> just ENOGOODFREENAMES
[14:20] <ysionneau> ;)
[14:20] <ogra_> drones !
[14:20] <ysionneau> yep drones :)
[14:21] <ogra_> :D
[14:21] <ysionneau> I'm experimenting with Ubuntu snappy, to see if it would be interesting for us (Parrot) to use it on our drones
[14:21]  * ogra_ would so love to see that
[14:22] <ogra_> i really like your HW
[14:22] <ysionneau> the benefit of adding support for alchemy, on our side, is that all our soft/libraries are using this build system. We made the effort of producing atom.mk files for everything
[14:22] <ysionneau> so it's basically our entry point for anything
[14:22] <dpm> sergiusens, I did the "interfaces" changes to a desktop snap yesterday as instructed by mvo after the ubuntu-core update. Now when running snapcraft to build it, I get "Issues while validating snapcraft.yaml: Additional properties are not allowed ('slot' was unexpected)"
[14:22] <ysionneau> anything other than alchemy is a no-go for us as we are not willing to re-do the job of porting all of stuff to a new build system
[14:23] <dpm> sergiusens, was the snapcraft version that supports interface not yet uploaded?
[14:23] <zyga> dpm: yeah, I think so
[14:23] <zyga> dpm: we'll wait for monday to release a compatible set
[14:24] <zyga> dpm: (snapcraft, snappy, ubuntu-core snap)
[14:24] <ysionneau> 15:22 < ogra_> i really like your HW  < thanks :))
[14:25] <dpm> zyga, ok, thanks. Any reason why the set was not released in sync? If I understood it correctly the ubuntu-core snap was already updated yesterday
[14:35] <kyrofa> sergiusens, no standup today? I know you're trying to get outta here
[14:37]  * ysionneau received his rpi2
[14:39] <zyga> dpm: slot and plugs got swapped
[14:39] <dpm> ah, ok
[14:42] <jdstrand> zyga: yw
[14:53] <zyga> jdstrand: hey
[14:53] <zyga> jdstrand: I asked some question on the telegram, have a look please
[14:53] <zyga> jdstrand: I'm about to start converting over all the interfaces we talked about to native
[15:04] <jdstrand> zyga: ack-- give me a few minutes
[15:05] <zyga> jdstrand: OK
[15:20] <zyga> jdstrand: I'll have the static security snippet support next
[15:20] <zyga> jdstrand: then moving to native interfaces
[15:22] <jdstrand> ok
[15:22]  * jdstrand is looking at tg now
[15:24] <zyga> tg?
[15:24] <zyga> sabdfl: o/
[15:25] <sabdfl> hey zyga
[15:25] <jdstrand> zyga: ok, so while we could support per-app device assignment, the previous agreement was that device assignment is per-snap and that is what the launcher is currently doing (per-snap)
[15:25] <zyga> jdstrand: okay, let's keep that and correct the variable names to accurately reflect that
[15:25] <zyga> jdstrand: is my patch sensible? i can propose it on launchpad
[15:26] <jdstrand> zyga: now, all that is pre-capabilities/skills/interfaces stuff, so if it should be per-app instead of per-snap, we need to change in that part of the code and the launcher
[15:26] <jdstrand> to me it seems sensible to do per-snap assignment
[15:27] <zyga> jdstrand: ok, let's correct the name with my patch then
[15:27] <zyga> jdstrand: I'd rather have it land quickly so next week we can release a working bundle
[15:27] <jdstrand> zyga: your patch is fine in the context of of snappy, but ubuntu-core-launcher needs a corresponding change
[15:28] <zyga> jdstrand: hmm? but my patch was for ubuntu-core-launcher
[15:28] <zyga> jdstrand: I pastebinned a patch for that
[15:28]  * zyga goes to commit and push it for real
[15:28] <jdstrand> oh, heh, I was to tunnel-visioned :)
[15:28] <jdstrand> ok, I think then that snappy needs a corresponding change :)
[15:28] <jdstrand> let me check
[15:29] <zyga> yep
[15:29] <zyga> both need to happen
[15:29] <jdstrand> right, yes
[15:29] <jdstrand> so, ack from me if both sides are done
[15:30] <zyga> jdstrand: https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/288116
[15:30] <zyga> jdstrand: I'll follow up with snappy change
[15:31] <zyga> perhaps /snappy-app-dev could be renamed to something more accurate too but I don't have a good candiate in my head
[15:33] <qengho> Hi hi. The package I want to package in a snap has its own internal seccomp profile, and things conflict. What incantation in snapcraft will make a snap with an unconfined profile?
[15:34] <zyga> qengho: why do you have your own seccomp profile?
[15:34] <zyga> qengho: we're implementing something called "interfaces" if you need non-default security you'll have to work with us to establish an interface that will let your application work
[15:34] <qengho> zyga: I do not, but the upstream software does.
[15:35] <zyga> qengho: for the moment you can use the "old-security" interface and you can use any custom security policy inside
[15:35] <jdstrand> qengho: chromium is going to be interesting here
[15:35] <qengho> :(  "interesting"
[15:35] <zyga> can you explain more how that works?
[15:35] <wesleymason> Soooooo, I have a snapcraft.yaml for an existing py2 project, that assembles, using the python2 plugin..and I have an "apps" section that in theory should link up to the usr/bin/<appname> console_scripts entrypoint generated by setuptools...but, on sideloaded install in a snappy VM, nada (it's there in apps/ etc.), but no command available from the
[15:35] <wesleymason> shell...any ideas?
[15:35] <zyga> can an process constrain itself more while under existing seccomp confinement?
[15:36] <zyga> wesleymason: ls /snaps/bin
[15:36] <zyga> wesleymason: and we only support 16.04 here really given that this is the focus of development
[15:36] <jdstrand> cause they use either a setuid sandbox (which we don't allow setuid in snaps) or a seccomp sandbox (which we disallow changing the seccomp policy in snappy)
[15:36] <zyga> wesleymason: so make sure you use a recent 16.04 image
[15:36] <zyga> jdstrand: mmm
[15:36] <ogra_> phew
[15:36] <zyga> jdstrand: well, I'll leave that to you :)
[15:36]  * ogra_ returns from vet ....
[15:37] <ogra_> no broken bones \o/
[15:37] <wesleymason> zyga: aha, good call, I had followed an out of date doc and grabbed a 15.04 image
[15:37] <ysionneau> something I saw in my qemu test but didn't report, but that I also see in my real-hw rpi2 test : [FAILED] Failed to start Create Volatile Files and Directories.
[15:37]  * wesleymason grabs a xenial image
[15:37] <zyga> wesleymason: yeah, do use 16.04 and latest snapcraft from xenial please
[15:37] <ysionneau> and also [FAILED] Failed to start Run snappy grub-migration.
[15:38] <ogra_> ysionneau, yeah, thats on arm64 too
[15:38] <ysionneau> ok
[15:38] <qengho> jdstrand: I could neuter the internal chromium seccomp sandbox, but that doesn't seem better.
[15:38] <zyga> wesleymason: you can get 16.04 image from https://github.com/zyga/devtools/blob/master/ubuntu-image
[15:38] <ysionneau> I just wanted to be sure you were aware of that :)
[15:38] <jdstrand> qengho: for this second, use something like http://paste.ubuntu.com/15281301/
[15:39] <jdstrand> qengho: but soonish, we'll do what zyga said where you work with us on some interfaces to make that better
[15:39] <qengho> jdstrand: Can I help pull Chromium's weird profile into snappy as a first-class option?
[15:39] <qengho> Cool.
[15:40] <zyga> jdstrand: let's closes https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/288116
[15:40] <jdstrand> yes, but I'm not sure what that option is otoh
[15:40] <zyga> jdstrand: I'll make the other change
[15:40] <jdstrand> in theory with seccomp you can keep going more and more restricted
[15:40] <ogra_> ysionneau, well, filing a bug might still make sense
[15:41] <jdstrand> but we don't allow changing the seccomp policy at all. perhaps we can have an interface that allows changing the seccomp sandbox
[15:41] <jdstrand> have it be restricted to apps we trust, etc
[15:41] <jdstrand> not sure. have to think about that
[15:41] <jdstrand> but chromium isn't alone in this regard. I think vsftpd also would need something like this
[15:42] <jdstrand> alternatively, compile chromium without either sandbox
[15:42] <jdstrand> I'm not sure that is an option
[15:42] <qengho> I'll check.
[15:42] <jdstrand> what's somewhat weird about that is that our sandbox is actually making someone else's sandbox less secure
[15:43] <jdstrand> (ie, the chromium seccomp sandbox allows less than we do, cause it is designed for minimal syscalls, whereas we have a bigger syscall interface to handle general purpose apps)
[15:43] <qengho> jdstrand: Maybe the chromium seccomp profile could be a strict superset of restrictions of plain. An app perhaps can set the profile, but they are all at least as strict as the base.
[15:43] <kyrofa> jdstrand, huh... yeah that is interesting
[15:44] <jdstrand> qengho: that is what I was getting at with a possible interface
[15:44] <kyrofa> jdstrand, if we allowed for a custom seccomp profile, could the review tools verify that the custom one is a subset of the typical?
[15:44] <jdstrand> allow adjusting the sandbox to be more strict
[15:44] <jdstrand> kyrofa: well, sure, but that isn't how the chromium sandbox works
[15:45] <jdstrand> kyrofa: it has a hardcoded list of syscalls in its code (so would say, vsftpd)
[15:45] <qengho> yaml: also-restrict: [ sigblahblah, obscureotherthing, llamas ]
[15:45] <jdstrand> and it only goes into the seccomp sandbox when handling untrusted input
[15:45] <kyrofa> Ah I see
[15:46] <jdstrand> it's an interesting problem. I don't think it is insurmountable
[15:47] <jdstrand> the problem with allowing changing the seccomp sandbox by default is that it might open up an avenue of attack of going seccomp unconfined/etc if there are kernel bugs
[15:47] <jdstrand> we'll see. want to think more
[15:49] <qengho> jdstrand: oh, that yaml is for snap meta/package.yaml, yes?
[15:50] <jdstrand> qengho: is this for 15.04 or 16.04?
[15:50] <qengho> jdstrand: 16.04
[15:50] <jdstrand> meta/snap.yaml
[15:50]  * zyga catches up
[15:50] <jdstrand> it would work with snapcraft too, but we are reversing the order of slots and plugs
[15:51] <zyga> jdstrand: check out https://github.com/ubuntu-core/snappy/pull/583
[15:51] <zyga> jdstrand: this will let us have nice native interfaces
[15:51] <jdstrand> so this time next week, that'll need to be s/slots/plugs/
[15:51]  * jdstrand assumes the changes will land by then
[15:51] <ogra_> unless someone changes his mind :P
[15:52] <qengho> jdstrand: so, for a snapcraft now, is there a way to get that phrase to the meta/snap.yaml ?
[15:52]  * ogra_ lost all trust in naming schemes til rellease day :P
[15:53] <ogra_> skillcapfaces ....
[15:53] <jdstrand> qengho: do this:
[15:53] <jdstrand> snapcraft snap (without the slots stuff)
[15:53] <jdstrand> then go in snap/meta/snap.yaml
[15:53] <jdstrand> add the slots stuff
[15:53] <qengho> Hah.
[15:53] <jdstrand> then do snapcraft snap
[15:54] <qengho> Thanks, jdstrand.
[15:54] <jdstrand> this is only for a few days
[15:54] <zyga> jdstrand: that's landed already
[15:54] <zyga> jdstrand: it's merged :)
[15:54] <jdstrand> zyga: snapcraft has interfaces in the new reversed order?
[15:54] <zyga> jdstrand: I _think_ sergiusens did this already, I was talking about snappy here
[15:55] <jdstrand> ah
[15:55] <jdstrand> qengho: ok, then do s/slots/plugs/ in the yaml snippet I gave
[15:55] <jdstrand> qengho: try it with snapcraft. if it barfs, use the method I suggested
[15:55]  * jdstrand needs to update the review tools now
[15:56] <jdstrand> zyga: regarding the pr, nice explanation
[15:56] <jdstrand> is there a way in git hub to see the complete changes in a pr as opposed to individual commits?
[15:57] <qengho> "barfs" would be a bad filesystem.
[15:57] <ogra_> the opposite of foofs
[15:57] <zyga> jdstrand: yes
[15:57] <zyga> jdstrand: you can see both:
[15:57] <jdstrand> qengho: hehe
[15:57] <zyga> jdstrand: e.g.: https://github.com/ubuntu-core/snappy/pull/578/files
[15:57] <zyga> jdstrand: vs https://github.com/ubuntu-core/snappy/pull/578/commits
[15:58] <zyga> jdstrand: or just use a remote and git locally ;)
[15:58] <jdstrand> I see
[15:58] <jdstrand> thanks
[15:59] <zyga> jdstrand: github has a nice any-to-any diff but I cannot remember how to find it
[16:03] <jdstrand> zyga: what is meta/hooks/plug?
[16:06] <zyga> jdstrand: just a random example
[16:06] <zyga> jdstrand: was supposed to be the plug-side notification hook
[16:07] <zyga> jdstrand: when you plug the plug into a slot, the plug gets to know this
[16:07] <jdstrand> zyga: ok, so that is/will be a documented and supported hook for apps to use
[16:07] <jdstrand> (that's fine)
[16:08] <zyga> jdstrand: yeah, we'll get there, that's the only hook we plan to have for 16.04 AFAIR
[16:08] <zyga> jdstrand: I'll implement it as soon as we're done with working interfaces (in general)
[16:08] <zyga> jdstrand: hook should be easy, pedronis` is working on support for running hooks in the state engine
[16:08] <zyga> jdstrand: so I just plan to wait for that to bake or bake it myself when other tasks run out
[16:09] <jdstrand> only hook wrt interfaces or do you mean config is going away?
[16:09] <zyga> jdstrand: wrt interfaces
[16:09] <zyga> jdstrand: I think config will just hop on the same bandwagon (state engine)
[16:10] <jdstrand> zyga: the waiting, etc is fine. mostly I just wanted to know what it was (remembering the .click/ design flaw)
[16:11] <zyga> jdstrand: since many state engine bits just landed I will have 80% of interface functionality in the next day or so
[16:11] <zyga> jdstrand: as I can just plug it in
[16:11] <jdstrand> zyga: nice!
[16:11] <zyga> jdstrand: I still want to see the ensure loop and at least one complete example but perhaps I'll just have to try it out
[16:12] <zyga> jdstrand: it'd be naive but if we can have interfaces with real security support in the next image I'd be golden :)
[16:12] <jdstrand> yeah, that would be really nice
[16:20]  * zyga -> food
[17:38] <ysionneau> one of the most annoying fact about 16.04 is that ogra_ 's nethack package is not yet ported to the squashfs type snap :') (at least on armhf userspace)
[17:39] <ysionneau> no nethack :(
[17:48] <ogra_> ysionneau, yeah, sorry, the plain nethack works only on arm64 and the ones with -$arch are both for 15.04
[17:49] <ogra_> once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches
[17:59] <netphreak> Hi, guys!
[18:00] <kyrofa> netphreak, hey there
[18:01] <netphreak> Been researching using Ubuntu and Snappy to deploy multiple IOT devices...
[18:01] <kyrofa> Oh yeah?
[18:01] <netphreak> How do i best deploy to a fleet of devices - not knowing their IP's
[18:02] <ogra_> you mean an initial install ?
[18:02] <netphreak> both initial and updates
[18:05] <qengho> netphreak: For initial, you have to have it "in your hands", probably.
[18:05] <qengho> netphreak: It's hard to know, without you saying a lot more.
[18:06] <netphreak> Can one use snappy to pull a snap from a url and install?
[18:09] <netphreak> I've setup a device that's running a preinstalled version of my software - currently it can download an embedded jar and update itself by being invoked from my control server.
[18:11] <netphreak> would like to package a snap with a jdk and deploy this using snappy.
[18:11] <ogra_> snappy has an automatic updater that pulls updates from the store automatically
[18:11] <ogra_> so once you deployed the devices will update themselves automatically
[18:12] <ogra_> you need to do the initial factory flash directly though as qengho said
[18:13] <netphreak> Does the store support private repos?
[18:13] <ogra_> it allows a sub store bound to you, yes
[18:13] <ogra_> (for details talk to beuno )
[18:14] <qengho> netphreak: you mean, for software that is secret to you, or do you want to preserve the namespace?
[18:14] <netphreak> just software that is secret to me..
[18:14] <ogra_> but note that snaps are namespaced anyway, you dont need to actually have a "private" one
[18:15] <netphreak> It's very device specific
[18:16] <netphreak> Any way to control when a device should pull an update?
[18:16] <ogra_> (and snaps are fully binary ... you never upload your source to the store)
[18:17] <ogra_> you can adjust the frequency the system checks for them
[18:17] <netphreak> ok.. and any way to control which version, if multiple exist?
[18:17] <ogra_> beyond that, as soon as your new snap exists in the store it will be pulled
[18:18] <ogra_> by default it would always be the latest ... with the option to roll back to the last if something fails
[18:18] <ogra_> not sure we have something in place to tell a device to hold back a version
[18:19] <ogra_> (i doubt it)
[18:19] <netphreak> ok..
[18:19] <netphreak> currently my admin part keeps a profile of each device - detailing location and which version..
[18:19] <ogra_> are the devices identical ?
[18:20] <netphreak> would like to only provision updates to eg. device located in a specific city at a time.
[18:20] <netphreak> yes, hardware wise they are..
[18:20] <ogra_> well, you could indeed produce different images and different snaps
[18:21] <ogra_> i.e. the devices in city foople all install use the foople.netphreak image that has  bar-foople.netphreak preinstalled
[18:21] <ogra_> one image per city ...
[18:21] <ogra_> one package per city
[18:21] <ogra_> that way you would be able to control them via the store
[18:21] <netphreak> problem is these devices will be installed in over 200 cities..
[18:22] <netphreak> Company expects to be able to sell atlas 10000  year.
[18:22] <netphreak> atleast
[18:23] <ogra_> well, thats quite a headdache in all cases :)
[18:23] <ogra_> the image you woul ddeploy would be identical apart from the snap name ... and you would have to maintain 200 snaps in your store ...
[18:23] <ogra_> potentially many of them being the same one just with a different name
[18:24] <netphreak> yes.. -> pretty inconvenient
[18:25] <ogra_> well, not more or less inconvenient than having to push them to the devices and maitain tables with lists of versions
[18:25] <ogra_> i really think the store people could help you here ... but beuno seems to be off atm
[18:27] <netphreak> all devices when booted sends their profile info to the admin server - where i can do version/location filtering etc.
[18:27] <netphreak> and send configuration changes to a group of devices or one specific.
[18:29] <ogra_> hmm, and they cant send their IP ?
[18:30] <netphreak> most of them will be behind a firewall.
[18:30] <ogra_> ah
[18:30] <ogra_> well, so the polling model is surely the better one
[18:31] <ogra_> and if you can send config changes you also can send commands i guess
[18:31] <ogra_> and trigger the poll ...
[18:32] <netphreak> exactly.
[18:32] <qengho> netphreak: I think you should keep one grand package and differentiate based on the package config. That is, part of a device deciding which part of the single grand package to use depends on the setting you seeded the device with.
[18:36] <netphreak> hmm...
[18:36] <netphreak> so you're telling me it's possible from my device application to instruct snappy to start pulling a snap?
[18:38] <ogra_> definitely
[18:38] <ogra_> snappy has a REST api that you should be able to use to manage snaps
[18:39] <netphreak> now we're talking ;)
[18:39] <netphreak> would it require to install the webdm part?
[18:39] <ogra_> i think the API itself is independent ...
[18:40] <ogra_> Chipaca would know
[18:40] <ogra_> afaik webdm just starts using it actually
[18:41] <netphreak> ok..
[18:41] <netphreak> how is it exposed on the device?
[18:41] <ogra_> throoug a socket afaik (i never used it)
[18:41] <ogra_> *through
[18:42] <zyga> re
[18:42] <ogra_> zyga, !
[18:42] <ogra_> you know about the REST api, right ?
[18:42] <zyga> ogra_: yep
[18:42] <zyga> ogra_: how can I help you?
[18:42] <ogra_> netphreak, zyga is your man then :)
[18:42] <zyga> netphreak: tell me
[18:43] <netphreak> i suppose this rest api is not exposed externally on the device?
[18:43] <zyga> netphreak: it's currently exposed over a unix socket
[18:43] <zyga> netphreak: but AFAIR the plain is to expose it over tcp/ip as well
[18:44] <zyga> netphreak: right no we just rely on local peer credentials for authentication
[18:45] <zyga> netphreak: you can develop an app that talks to current snappy REST api and work with us to expose it on the network
[18:45] <zyga> netphreak: what specifically do you need?
[18:47] <netphreak> Currently my admin server can communicate securely with the device - receive device profile (application version, location etc).
[18:47] <netphreak> And can instruct it to download an update from say AWS S3 repo - as a jar..
[18:47] <netphreak> What i was after was the transactional updates and security of Snaps..
[18:48] <netphreak> So actually my java app on the device could call either the rest api or a snappy command directly
[18:48] <zyga> netphreak: snappy maanges device updates, what you are describing actually happens on the server side
[18:48] <zyga> netphreak: so I believe it is possible as a service you get from canonical
[18:49] <zyga> netphreak: on a given snappy device you can switch between channels like "beta" or "stable"
[18:49] <netphreak> yes.. but i need to control which devices (according to location) are updated when.
[18:49] <netphreak> my admin server handles all received profiles, and can manage and filter (by location and version etc.) which devices to update
[18:50] <zyga> netphreak: I believe this is supported but you'd have to get in touch with someone from product management to discuss details
[18:50] <zyga> netphreak: you can control a device but it's not exactly what you think or are describing
[18:50] <zyga> netphreak: as in, control which versions go where
[18:50] <zyga> netphreak: but that's all server side
[18:51] <zyga> netphreak: I'd suggest you to watch development towards 16.04 and get in touch with canonical sales to get a dedicated contact and understand better how server-side management works
[18:51] <qengho> netphreak: You want to defer updates of snap packages based on criteria the device knows about.
[18:51] <qengho> That was a question.
[18:53] <netphreak> The control part is already handled by our middleware software - i just need to tell Snappy on one or more devices to go pull an update with version x.y.z
[18:55] <netphreak> Eg middleware platform tells device x - go fetch update snap xyz version x.y.z
[18:57] <zyga> netphreak: snappy has specific design on how updates work, who has control over what (os vendor, appX vendor, appY vendor, brand of the device, user)
[18:57] <zyga> netphreak: what we designed may not be what you immediately think about but it's a very powerful system
[18:57] <netphreak> hmm..
[18:57] <zyga> netphreak: I know we're really moving rapidly and not everything is available or documented but as we progress towards 16.04 it will become clear how you can fit your idea into that model
[18:58] <zyga> netphreak: e.g. if I install your app, can I still override your decision
[18:58] <netphreak> Well. no need for that part - as the software is for a very specific IOT device..
[18:58] <zyga> netphreak: right, what I'm saying that we designed something that can handle various cases, not just the one you described
[18:59] <netphreak> Sounds interesting..
[18:59] <zyga> netphreak: but perhaps the manner in which that is acheived is not the same as what you described
[18:59] <netphreak> what's the timeframe for 16.04?
[18:59] <ogra_> 04 2016 ;)
[18:59] <zyga> netphreak: so for now I can only suggest to contact canonical professionally and discuss this more and also to wait towards 16.04 as we publish more documentation and design docs
[18:59] <zyga> netphreak: 16.04 :D
[18:59] <ogra_> (april )
[18:59] <zyga> netphreak: it's nice to have nice date-based releases
[18:59] <netphreak> hehe..
[19:00] <netphreak> I'll get a hold of canonical and get some more info :)
[19:01] <netphreak> And see if it'll fit our schedule..
[19:01] <netphreak> are there any previews available to get a feeling of how it it would work?
[19:01] <zyga> netphreak: it's an exciting and very busy period, I'd suggest to explore aligning on 16.04 and working towards using ubuntu as the core of your product
[19:02] <zyga> netphreak: it's all in the open
[19:02] <zyga> netphreak: you can get "edge" images from https://github.com/zyga/devtools/blob/master/ubuntu-image easily (or get pre-built images from links mvo and others send to the snappy-devel mailing list)
[19:03] <zyga> netphreak: you can check snappy activity on github.com/ubuntu-core/snappy
[19:03] <zyga> netphreak: and we're all here so it's all in the open
[19:03] <ogra_> yeah
[19:03] <netphreak> ok.. will have a look..
[19:03] <ogra_> netphreak, what CPU arch are your devices ?
[19:03] <netphreak> arm
[19:03] <zyga> netphreak: armv7+ or earlier?
[19:03] <ogra_> v7 ?
[19:04] <netphreak> v7
[19:04] <ogra_> cool
[19:05] <netphreak> maybe a Cortex A53 - if needed
[19:09] <ogra_> yeah, that should both be fine
[19:10] <netphreak> Thanks for your time, guys! :)
[19:10] <ogra_> np, if you have more questions, just come around
[19:11] <ogra_> :)
[19:12] <netphreak> will do :)
[19:18] <jdstrand> pindonga: hey, fyi, I just committed change to the review tools for the plugs/slots reversal. this doesn't need to be pulled immediately, but I wanted to alert you to it
[19:19] <jdstrand> pindonga: next week I imagine I am going to ask for another pull request for old-security/caps to native interfaces change that zyga is working on
[19:19] <pindonga> jdstrand, sure
[19:19] <pindonga> let me know and I'll do the pull next week
[19:19] <jdstrand> ok
[19:21] <zyga> jdstrand: ok, 4-way security snippet support has landed
[19:21] <zyga> jdstrand: is there something I could try to convert over as the first thing?
[19:26] <jdstrand> zyga: yes, let me push something
[19:34] <jdstrand> zyga: https://code.launchpad.net/~jdstrand/+junk/snappy-interfaces-security
[19:34] <jdstrand> zyga: look in snap.unpacked
[19:35] <jdstrand> since snapcraft doesn't do interfaces yet, I unpacked a snap that used 'uses', then converted the snap.yaml and moved some things around
[19:35] <jdstrand> zyga: it is not tested to work, but it should give you the idea
[19:38] <zyga> jdstrand: looking
[19:38] <zyga> jdstrand: thanks
[19:38] <zyga> jdstrand: https://trello.com/c/qm0XzFfl/44-switch-udev-security-to-app-level-granularity FYI
[19:39] <zyga> hmm
[19:39] <zyga> jdstrand: I was under the impression that 'network' and 'network-bind' would just become real top-level interfaces, not under old-security
[19:40] <jdstrand> zyga: yes
[19:40] <zyga> jdstrand: ok
[19:40] <jdstrand> zyga: you asked for me to give you something to convert :)
[19:40] <zyga> jdstrand: yeah, like "network"
[19:40] <jdstrand> convert away! :)
[19:40]  * zyga reads
[19:40] <jdstrand> network-client -> network
[19:40] <jdstrand> network-listener -> network-bind
[19:40] <zyga> jdstrand: right I know
[19:41] <zyga> jdstrand: hmm, I was hoping to get the network.go at the end of this exercise
[19:41] <jdstrand> these are different static perms
[19:41] <zyga> jdstrand: that implements "network"
[19:41] <jdstrand> sure
[19:41] <zyga> jdstrand: and after the basics are set up, iterate and convert all of those over
[19:42] <jdstrand> zyga: I gave you a snap that had stuff in that used old-security. what precisely do you want and I'll give it to you
[19:42] <zyga> jdstrand: so to be clear, I don't want to implement old-security now
[19:42] <jdstrand> no, of course not
[19:42] <jdstrand> you used the word 'convert'
[19:42] <zyga> jdstrand: (I can but it's more complex)
[19:42] <zyga> jdstrand: ah, sorry
[19:42] <jdstrand> so I gave you the old system so you could convert
[19:42] <zyga> jdstrand: I'd like to see the bits that go into making "network" tick
[19:42] <zyga> jdstrand: so I can quickly create NetworkInterface{} type that has the same semantics
[19:42] <jdstrand> we want old-security/caps to go away
[19:43] <zyga> jdstrand: we can look at how that looks next week and decide how to proceed with other interfaces
[19:43] <jdstrand> zyga: tell me exactly what you want now and I will give it to you
[19:43] <zyga> jdstrand: ok, one se
[19:43] <zyga> sec*
[19:44] <zyga> jdstrand: given those four methods: https://github.com/ubuntu-core/snappy/blob/master/interfaces/core.go#L81
[19:44] <zyga> jdstrand: (consecutive)
[19:44] <zyga> jdstrand: I'd like to know what security snippets to put inside for "network"
[19:44] <jdstrand> oh
[19:44] <jdstrand> zyga: did you look in the ppa?
[19:44] <zyga> jdstrand: I suspect that it translates to a few syscalls and maybe some AA
[19:44] <zyga> jdstrand: no, which ppa, sorry, maybe I missed a link
[19:45] <jdstrand> I sent it via email yesterday. don't worry, let me point you at a branch
[19:45] <zyga> oh, sorry, I'm not great with catching up on email; thanks
[19:45] <jdstrand> zyga: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/files/head:/data/
[19:46] <jdstrand> zyga: drill down into {apparmor,seccomp}/policygroups/ubuntu-core/16.04/network
[19:46] <zyga> jdstrand: that's exactly what I needed, thank you
[19:46] <zyga> :)
[19:46] <zyga> woot
[19:46] <jdstrand> np, sorry for the confustion
[19:47] <zyga> hehe, sorry, this was a looong day (yesterday too)
[19:47] <jdstrand> zyga: if it helps you, there is an ubuntu-core-security in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages that did all the renames from yesterday (ie, what is in that branch)
[19:47] <jdstrand> but I suspect the branch is enough
[19:48] <zyga> jdstrand: yeah, the branch is enough
[19:48] <zyga> jdstrand: and as a sanity check, the "network" interface will have a slot on the ubuntu-core os snap and all the snaps that want to talk to it will have a plug on their side
[19:48] <jdstrand> zyga: correct
[19:48] <zyga> great
[19:48] <zyga> one moment :)
[20:10] <kyrofa> jdstrand, are the read/write paths new to 16.04? Or did they exist in 15.04 as well?
[20:10] <kyrofa> Looks like the docs have been replaced on developer.ubuntu.com, now I can't remember :P
[20:15] <zyga> (almost done, writing tests)
[20:15] <jdstrand> kyrofa: security-override/read-paths and write-paths were technically available in 15.04, but in a really hard to use way that is not at all like the 16.04 yaml
[20:16] <kyrofa> jdstrand, I don't suppose you know of any examples?
[20:20] <jdstrand> kyrofa: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04
[20:21] <kyrofa> jdstrand, ah ha!
[20:23] <kyrofa> jdstrand, is the policy_group in the override of that example redundant due to the cap of the service?
[20:23] <jdstrand> yes
[20:23] <kyrofa> Or do they need to match up?
[20:23] <kyrofa> Okay
[20:23] <jdstrand> oh wait
[20:23] <jdstrand> I thought you were asking a different question
[20:24] <jdstrand> kyrofa: security-override can only be used by itself on 15.04
[20:24] <kyrofa> Oh wow, I totally missed that there were two services
[20:24] <kyrofa> Ahem
[20:24] <jdstrand> kyrofa: so, any 'caps' you had in your yaml, but in the policy_groups of the json
[20:24] <jdstrand> then remove the caps from the yaml
[20:24] <kyrofa> Gotcha, okay. Yeah, I like 16.04 better, too ;)
[20:24] <jdstrand> yes
[20:25] <kyrofa> Thanks for the pointer!
[20:25] <jdstrand> np
[20:25] <jdstrand> historically, this is because of the click compat stuff and it not getting all moved by 15.04
[20:25] <jdstrand> I did say it was horrible to use :)
[20:26] <kyrofa> Yeah that makes total sense
[20:33] <zyga> jdstrand: ok
[20:33] <zyga> jdstrand: ready?
[20:33] <zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/587
[20:34] <zyga> jdstrand: note that this is the no-shortcuts taken version
[20:34] <zyga> jdstrand: with 2nd one I'll itroduce a simple "base class" like support so all the grotty details will go away
[20:34] <zyga> jdstrand: and 99% of the code will be copy-paste from your bzr branch
[20:34] <kyrofa> jdstrand, FYI typo on that page, overrides has no s
[20:37] <zyga> ogra_: ^^ it's happening
[20:38] <zyga> jdstrand: tell me what you think
[20:38] <zyga> jdstrand: I have to leave in 7 minutes
[20:49] <jdstrand> zyga: 7 minutes is not a lot of time. I looked at it and see how it works
[20:49] <jdstrand> zyga: I look forward to the 99% case next week :)
[20:52] <zyga> jdstrand: cool
[20:52] <zyga> jdstrand: I'm getting off then
[20:52] <zyga> jdstrand: have a nice weekend
[20:53] <zyga> jdstrand: I'll simplify this and send a dozen pull requests your way
[20:53] <jdstrand> zyga: you too! thanks! :)
[21:20] <wililupy> question: Has anyone seen the error: ubuntu-core-launcher unalbe to make /tmp/ private. errmsg: Invalid argument?
[21:21] <wililupy> my snaps that are system services are failing to start and going into a failed state.
[22:21] <ysionneau> 18:49 < ogra_> once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches < ahah I know what you mean =
[22:21] <ysionneau> =)


[00:53] <pleia2> bug 12345
[00:53] <ubot2`> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
[00:54] <pleia2> don't mind me, just prepping for doc session on sunday :)


[10:53] <BenC> If anyone has specific questions regarding bug reports or other issues, the kernel team is always active in #ubuntu-kernel
[10:53] <BenC> well, not _always_, but when we are, that's the place :)
[10:54] <BenC> If you are interested in the kernel team and what we are doing, I strongly recommend subscribing to the<EMAIL_ADDRESS>mailing list and checking out https://wiki.ubuntu.com/KernelTeam
[10:55] <BenC> We've got about 5 more minutes. Any final questions?
 QUESTION: if a bug affect a driver what package is afected? kernel(linux-source-2.6.20) or the source of driver (rt2x00)
[10:55] <BenC> I'm quite surprised the topic of kernel version for gutsy hasn't come up yet :)
[10:56] <BenC> In that case, since the source code for that driver came from linux-source-2.6.20, that's where the bug can be fixed
[10:56] <BenC> It's also very helpful to report the bug upstream, since they are the ones most familiar with the hw
[10:56] <BenC> e.g. the rt2x00 project
 QUESTION: what version of linux will be used in gusty?
[10:56] <BenC> Ah, someone saved the day :)
[10:57] <BenC> It's %99.99 sure to be 2.6.22
 QUESTION: Can we see all the ubuntu team in dresses please?
 QUESTION: Linus or Alan?
[10:58] <PriceChild> uu serious one:
[10:58] <BenC> h4wk0: Prepayment for cross-dressing requests can be sent to my paypal account
 QUESTION: how far branched is the ubuntu linux from linus's mainline?  and how much work needs to be done for each new upstream release?
[10:58] <BenC> Oooh...it's actually branched lot more than I would like...we usually end up pulling in some other git tree like libata-dev#upstream for feisty
[10:59] <BenC> But the Ubuntu patches are very limited
[10:59] <BenC> it's usually not a lot of work since most "new" things we pulled in are already upstream by the time the next cycle starts
 QUESTION: ltspfs  It would be useful to allow a machine with lots of ram to share it over the network with machines which do not have much ram.  LTSP has a feature for providing swap.  Is there any chance we will see this sort of option in install routines to add swap space over the network?
[11:00] <BenC> Looks like we're out of time. Thanks everyone for joining, and enjoy the rest of the week!
[11:00] <PriceChild> oops sorry joebaker
[11:00] <PriceChild> Thankyou very much BenC! :)
[11:00] <BenC> joebaker: please pick up in #ubuntu-kernel
[11:01] <BenC> PriceChild: thanks for handling questions
[11:01] <PriceChild> My pleasure :)
[11:05] <gnomefreak> PriceChild: this is last session today? the bazaar one?
[11:05] <PriceChild> gnomefreak, Yes.
[11:06] <gnomefreak> k
[11:06] <poolie> good morning class
[11:06] <poolie> :-)
[11:06] <gnomefreak> hello poolie
[11:06] <poolie> i'm martin pool, i work on Bazaar at Canonical with jam-laptop
[11:06] <poolie> and some other folks
[11:07] <poolie> Bazaar is a version control system designed to work well for ubuntu developers and to work well with launchpad
[11:07] <poolie> and to be easy to learn and pleasant to use
[11:08] <poolie> 'what is a version control system'?
[11:08] <poolie> well it remembers the changes you have made to a source tree, so that you can go back and see why changes were made
[11:08] <poolie> undo changes
[11:08] <poolie> review incoming work
[11:09] <poolie> merge in someone else's work,
[11:09] <poolie> and publish your changes
[11:10] <jam-laptop> Hi all
[11:10] <poolie> there are many other systems, including cvs, svn, monotone, darcs, git, mercurial
[11:10] <poolie> some of the distinguishing features of bazaar include:
[11:10] <poolie> very good support for windows, mac and linux
[11:11] <poolie> a simple user interface and attention to keeping it friendly
[11:11] <poolie> a good python scripting api
[11:11] <poolie> ability to host branches on any web or ftp or file server without needing to run a special daemon
[11:12] <poolie> and very good handling of refactorings like renaming files or directories
[11:12] <poolie> i'll look at some qns
 QUESTION: so bazaar has been designed to fit ubuntu ? and this is not ubuntu which choosed to because it fitted its need ?
[11:12] <poolie> thanks PriceChild
[11:13] <poolie> ubuntu (well, Canonical) was originally basing our work on Arch, an existing system
[11:13] <poolie> and contributing patches to that
 QUESTIONS What are the pros and cons versus SVN
[11:14] <poolie> it wasn't really going in the direction we thought was best, so we started a new system taking the parts we liked from Arch
[11:14] <poolie> the pros: no need for a central server, can commit and do other work while disconnected,
[11:15] <poolie> much better merge tracking and smarter merging
[11:15] <poolie> cons: mostly that it's a younger system, so somewhat less polished, less tools integration, etc
[11:16] <PriceChild> How does bazaar do without a central server to track everything?
[11:16] <poolie> but we plan to go 1.0 in a few months, and there is some work towards gnome, eclipse and visual studio integration
[11:17] <poolie> in Bazaar, each branch lives at a url, and carries a description of its history, including what has been merged in to it
[11:17] <poolie> when you merge from one branch to another, the system works out what's different between them and what has to be done
[11:17] <poolie> let's try it!
[11:18] <poolie> on ubuntu, apt-get install bzr
[11:18] <poolie> then cd to some suitable directory (like your home)
[11:18] <poolie> and do
[11:18] <poolie> bzr branch http://bazaar.launchpad.net/~mbp/+junk/seminar
[11:19] <poolie> after a little while, this will give you a toy source  tree i made for this project
 QUESTION: So client side bazaar is just a bunch of scripts and server-side it can be only one ftp server?
[11:19] <poolie> awkorama: uh not just "a bunch of scripts" :-), a suite of lovingly hand-crafted python modules :-)
[11:20] <poolie> that give you one program 'bzr' with various commands
[11:20] <poolie> on the server side it can be an ftp, sftp, http, server
[11:20] <poolie> or you can run the bazaar 'smart server' which is somewhat faster, and will become much faster in future releases
 question: why bother to make it work well with mac and windows?
[11:21] <poolie> mc44, good qn
[11:22] <poolie> it's  because many open source projects, even if their core developers only use ubuntu, end up being ported to Windows
[11:22] <poolie> it can be a pain to support windows but if you keep it in mind during the design it's not that bad
 QUESTION: Bazaar works well for Linux and Ubuntu. Does it also work well for other types of software development, i.e. could/should/will it replace CVS/SVN eventually?
[11:23] <poolie> yes, it does
[11:23] <poolie> it's used by a number of people for internal/commercial development
[11:23] <poolie> i would say it's certainly an improvement on cvs, and depending on your situation could well be better than svn
[11:24] <jam-laptop> I would also like to point out that we have the ability to interoperate with an upstream SVN server
[11:24] <jam-laptop> with the bzr-svn plugin
[11:24] <poolie> oh good point
[11:24] <poolie> jam-
[11:24] <jam-laptop> Which allows you to pull changes from SVN, do your commits in bzr, and (if you have commit rights to SVN) lets you merge your changes back
[11:25] <jam-laptop> https://launchpad.net/bzr-svn is the project page
 I only got one file, hello when I branched his URL
[11:25] <poolie> if you ran that command "bzr branch http://bazaar.launchpad.net/~mbp/+junk/seminar" you should have got a directory 'seminar'
[11:26] <poolie> containing one file, 'hello'
[11:26] <poolie> with some text in it
[11:26] <poolie> if you cd to that directory and run 'bzr log'
[11:26] <poolie> then you should see that i created it early this morning
[11:27] <poolie> ddaa points out there is also a hidden directory .bzr which contains our control files
[11:28] <jam-laptop> nansub0111: QUESTION:does the bzr-svn plug-in work the other way as well too? Suppose I use bzr locally for version control, but the public repository is subversion. Thanks
[11:28] <jam-laptop> nansub0111: COMMENT:I should clarify I want to use subversion only for releasing public files
[11:28] <jam-laptop> There is some work to support serving SVN information from a bzr repositor.
[11:28] <jam-laptop> repository
[11:29] <jam-laptop> so people with only an SVN client can still check out your source code
[11:29] <poolie> you can push back into svn from bzr
[11:29] <jam-laptop> I believe the basic "checkout" support is functional, but you cannot commit yet.
[11:29] <poolie> as an alternative approach
[11:29] <poolie> oh maybe not then
[11:29] <jam-laptop> nansub0111: jam-laptop: I ask because i am using googlecode to host a project, but all of my version control is done with bazaar.
[11:29] <jam-laptop> For this setup, bzr-svn would definitely work
[11:29] <jam-laptop> you could do your work locally using bzr
[11:30] <jam-laptop> and then merge/commit back to googlecode's svn repository
[11:30] <jam-laptop> poolie: mc44: QUESTION: sabdfl has talking about the importance of revision control in freedom even other than code. Can bazaar be used for non code applications? what sort of applications do you think it could be useful f
[11:31] <poolie> mc44: you can certainly use it for documentation, web content
[11:31] <poolie> other things that are not code but look a bit more like code
[11:31] <poolie> i agree with mark about the importance of free collaboration on other things
[11:32] <poolie> bazaar at the moment is a bit biased towards "things that look like code"
[11:32] <poolie> eg you cannot comfortably commit very large binary files
[11:32] <poolie> but the real issue in collaborating on, say, graphics or music
[11:32] <poolie> is that it is sometimes hard to merge the changes if two people have modified them
 QUESTION: will pakages be handeld via bzr in future?
[11:33] <poolie> yes, they will
[11:33] <poolie> at the moment some packages are maintained in bazaar trees,
[11:33] <poolie> and there are some tools to help you do this
[11:33] <PriceChild> launchpad is managing some sources in bzr isn't it?
[11:34] <poolie> there is a list of these packages on the ubuntu wiki i believe
[11:34] <poolie> launchpad does a few things with bazaar
[11:34] <poolie> bazaar is the way that launchpad thinks about code, if you like
[11:34] <poolie> firstly, it can host your branches so other people can get them
[11:34] <poolie> like the url i gave above
[11:35] <poolie> and it provides a directory of branches, like
[11:35] <poolie> https://code.launchpad.net/~bzr
[11:35] <poolie> these branches are owned by the 'bzr' group, and any of us can commit to them
[11:36] <poolie> you can see that some of them are linked to bugs
[11:36] <poolie> and if you click through you can also see the code within them
[11:36] <poolie> launchpad also provides a service of automated imports from svn or cvs to bzr
[11:37] <poolie> i need to catch up on qns!
 QUESTION: Is there a tutorial somewhere? What other resources would you recommend to get to know bazaar?
[11:37] <poolie> ucap, there is on bazaar-vcs,org,
[11:37] <poolie> and there are usually people in #bzr on freenode who can help
[11:37] <poolie> or write to<EMAIL_ADDRESS> QUESTION: Is BazaarNG ever going to get small, simple *and* fast as Mercurial? ;-)
[11:38] <poolie> tekNico: yes, we're *very focused* on speed and it's getting faster in every release
[11:38] <poolie> many thanks due to jam-laptop in that area
 for an example of a non-code project using ubuntu: https://code.launchpad.net/spreadubuntu/
[11:39] <PriceChild> I'm keeping a list of qns unanswered so far :)
 QUESTION: Do you use Bazaar while developing Bazaar?
[11:39] <poolie> alienSkull: yes of course,
[11:39] <poolie> like many ubuntu-related projects we do review of new contributions
[11:40] <poolie> when people post new patches to the list, it's caught  by http://bundlebuggy.aaronbentley.com/
[11:40] <poolie> which keeps track of the review comments, and uses bzr to find out when they're merged
[11:40] <poolie> PriceChild: next?
 QUESTION: what is the status of the eclipse plugin ? how stable it is, can i feel confident that it wont crash my precious source code ? :)
[11:41] <poolie> zorglu_: sorry i don't know off hand, i don't use eclipse
[11:41] <poolie> best to ask on the list
[11:41] <jam-laptop> I've followed it a bit
[11:41] <jam-laptop> It is still pretty early on
[11:41] <jam-laptop> Since it uses bzr as the back end
[11:41] <jam-laptop> it won't "crash your precious source code"
[11:41] <jam-laptop> But it may get fussy when you try to use it.
[11:42] <jam-laptop> Since Eclipse needs to be taught how to think like bzr.
[11:42] <PriceChild> dabaR, would like to see the continuation of the demo you were doing poolie.
[11:42] <poolie> ok
[11:43] <poolie> so at least one person now has a copy of my code
[11:43] <poolie> now edit 'hello' in your favourite editor
[11:43] <poolie> add a line of text or two
[11:43] <poolie> save/exit
[11:43] <poolie> and run 'bzr diff'
[11:44] <poolie> and it shows you what you've change
[11:44] <poolie> and 'bzr status' summarizes that
[11:44] <poolie> this should be familiar from cvs or svn
[11:44] <poolie> you can now 'bzr commit'
[11:44] <poolie> this may be surprising - you don't have write access to my branch - but you can do it into your new local branch
[11:45] <poolie> now try 'bzr log' and it should show your change following mine
 QUESTION: how do I see where it got commited to?
[11:45] <poolie> i'll let people catch up...
[11:46] <poolie> that's kind of an interesting question
[11:46] <poolie> it gets committed to whatever branch you're currently in
 QUESTION: How do you tell bazaar to commit to another location like for an example an FTP Server?
[11:47] <poolie> Demon012: you can do this in two ways
[11:47] <poolie> if you want to commit directly there, every time you type commit
[11:47] <poolie> then you should make a branch on the server with bzr init, then from your machine do 'bzr bind ftp://euthaoeuthaoeu'
[11:48] <poolie> but what i'm going to recommend here is
[11:48] <poolie> that you instead push your changes to the server after you've made them
[11:48] <poolie> so you can do 'bzr push URL'
[11:48] <poolie> where URL is an sftp or ftp url
[11:48] <poolie> if you have a launchpad account with ssh keys, you can push there
[11:48] <poolie> with bzr push sftp://bazaar.launchpad.net/~mbp/+junk/seminar
[11:48] <poolie> change 'mbp' to your name
[11:49] <poolie> branches on launchpad need to be associated with a product, here we have "+junk" to say it's not
[11:49] <poolie> next qn?
[11:49] <jam-laptop> nealmcb: QUESTION: I'd like to use bzr to manage changes to configurations in /etc and maybe other places.  The documentation mentions this, but I'd love to see best practices or examples tailored to sysadmin.    And I'd love to be able to host the repository somewhere other than in /etc or / itself.
[11:49] <jam-laptop> That is a more involved situation
[11:50] <jam-laptop> and some people have certainly thought about it a bit
[11:50] <jam-laptop> The #1 solution I've seen, is that you version the tree in another location
[11:50] <jam-laptop> and then use symlinks to point into it.
[11:50] <jam-laptop> This lets you version sub-pieces of /etc in different branches
[11:50] <jam-laptop> and keeps the VCS data separated from the running files
[11:51] <jam-laptop> poolie: dAndy: QUESTION: Is bzr entirely python or is there C mixed in for better performance? What else is being done to improve performance?
[11:51] <poolie> at the moment the main release is all python, but we will likely add C soon,
[11:52] <poolie> actually pyrex, a python-like language that compiles to C
[11:52] <jam-laptop> I think in general we have focused on getting the right algorithm in python
[11:52] <poolie> the main things we're doing on performance atm are doing less io, and doing more efficient network traffic
[11:52] <jam-laptop> It is much easier to switch from a O(N^2) algorithm to an O(logN) one in python
[11:52] <jam-laptop> and once we have that, we can optimize for C/Python speeds
[11:53] <jam-laptop> Rather than trying to make a really fast C O(N^2) algorithm, that will always end up slow
 COMMENT: for the push I had to include my LP username like so "bzr push<EMAIL_ADDRESS>[11:53] <poolie> ranf: ah true, i have the same name on my machine
 QUESTION: is there any web based bazaar clients that can be used to submit changes to a branch? or even to just view the contents revisions to them?
[11:54] <poolie> there is nothing to submit changes atm - that would be good for documentation
[11:54] <poolie> you can use 'loggerhead' to view the contents and revisions
[11:55] <jam-laptop> https://launchpad.net/loggerhead
[11:55] <jam-laptop> which is set up at
 16:48 < rulus> Question: how to get your change to poolie's branch?
[11:55] <poolie> you can get your changes in in several ways:
[11:55] <poolie> if you had write access (which you don't here) then just push in directly
[11:55] <poolie> otherwise, i need to merge it
[11:56] <jam-laptop> An example is: http://codebrowse.launchpad.net/~bzr/bzr/trunk
[11:56] <poolie> you can do 'bzr bundle' to produce a text file you can mail to me
[11:56] <poolie> or you can post the public url (eg http) into -chat, and i'll merge from there
 QUESTION: How important is launchpad for the success of bazaar and/or vice-versa?
[11:57] <poolie> ucap: they're pretty complimentary, and we work closely together
[11:57] <poolie> i think launchpad is exciting because it can have such an integrated view of the code
[11:58] <poolie> and bazaar because launchpad gives you a centralized view that's otherwise missing - helping you find the branches that fix different bugs for example
 QUESTION How about roll back.. is that merge a earlier version and commit as svn or is there a rollback feature
[11:59] <poolie> to revert your working directory, 'bzr revert'
[11:59] <poolie> see also uncommit, and 'bzr revert -r -2' to discard changes from the last two, or 'bzr merge -r -20..-19' to reverse one change
[11:59] <poolie> one minute to live!
[12:00] <jam-laptop> I would also comment that we have "bzr uncommit"
[12:00] <poolie> thanks very much, interesting questions
[12:00] <jam-laptop> in case you want to throw away changes from your branch completely.
[12:00] <jam-laptop> You are all also welcome in #bzr on this server
[12:00] <jam-laptop> Feel free to ask questions there
[12:01] <poolie> thanks jam


[00:03] <ahoneybun> popey: ahoneybun think we can get some sponsorship for a Autism Speaks Walk?
[00:03] <ahoneybun> http://act.autismspeaks.org/site/TR?team_id=53866&fr_id=2791&pg=team
[07:57] <Mister_Q> morning o/
[22:30] <sethj> am I allowed to use the etherpad instance at etherpad.ubuntu.com?
[22:30] <knome> if you aren't blocked technically, yes
[22:31] <sethj> knome, technically?
[22:31] <knome> i mean if you can log in and edit the pad
[22:31] <knome> (and you can if you belong to one of the teams that are allowed to)


[04:32] <Sarvatt> sheesh, people really consider the x.y.0 branches the stable branches for mesa, I'm getting even more worried about xserver in the future :) by the time a branch is considered the stable branch there are 3 branches (like master, 7.8 and mesa_7.7_branch with 7.7.1+)
[15:00] <raggiskula> uhm, hi
[15:01] <raggiskula> I just installed 10.04 and my secondary display is disorted
[15:01] <raggiskula> a bit out of focus, but it looks like this
[15:01] <raggiskula> http://imgur.com/edtfr
[15:02] <raggiskula> I'm using the default drivers
[15:02] <raggiskula> not fglrx
[15:03] <raggiskula> the display was ok while using fglrx but no 3d where my card is unsuported
[17:37] <Bernardo> hi all
[17:37] <Bernardo> I am trying to port Mandriva's patches for the poulsbo driver and xorg 1.7.x, but I am stuck
[17:38] <Bernardo> It seems to work, the psb module is called, drm initialized and loaded without problems, but DRIScreenInit fails to create /dev/dri/*, and then fails
[17:39] <Bernardo> I've loaded the psb and the drm modules with debug enabled, and there is no error in dmesg
[17:39] <Bernardo> anyone can help me?
[22:47] <bjsnider> how would someone install new software on an ubuntu system that doesn't have internet access?
[23:08] <BUGabundo> bjsnider: debs?
[23:08] <BUGabundo> gdeb
[23:17] <bjsnider> nah
[23:17] <bjsnider> there's a whole chain of dependencies


[02:24] <mwhudson> vorlon: found the hdf5 problem
[02:24] <mwhudson>     /* remove trailing ';' from signed headers sequence */
[02:24] <mwhudson>     signed_headers_dest[HDstrlen(signed_headers_dest) - 1] = '\0';
[02:24] <mwhudson> vorlon: it would be Bad(tm) if signed_headers_dest is the empty string here, perhaps
[02:27] <mwhudson> doko, ginggs: do you have a plan for python 3.10 vs autoconf-archive?
[03:48] <mwhudson> icey: does your team take care of wrapt in ubuntu? i have a patch anyway https://paste.ubuntu.com/p/jb9D6JzTmg/
[03:48] <mwhudson> icey: i can upload that tomorrow if you like
[06:18] <ginggs> mwhudson: no plan, as such
[06:18] <ginggs> are you going to upload hdf5?
[06:57] <icey> mwhudson: I don't think so, although I do see that zigo is the uploader in Debian; I'm sad that the upstream patch has a typo though :-P
[07:56] <ginggs> mwhudson: new plan for autoconf-archive -- steal patch from fedora
[09:39] <mwhudson> ginggs: i'll upload hdf5 tomorrow unless you want to do it sooner
[09:39] <mwhudson> icey: ack, there is a new upstream version too but well
[09:39] <mwhudson> one thing at a time i guess
[09:40] <ginggs> mwhudson: do you have it in a PPA?  i could "sponsor" your upload
[09:41] <ginggs> automake-1.16 and autoconf-archive uploaded
[09:41] <mwhudson> ginggs: it's here https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=hdf5&field.status_filter=published&field.series_filter= but you might need to rewrite the changelog and call the patch something other than "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa.patch" ;-p
[09:41] <mwhudson> ginggs: ah yeah pythonmagick should build with the new automake, i think
[09:41] <ginggs> mwhudson: it does, at least locally for me
[09:42]  * mwhudson zzzz
[10:03] <icey> is ` format not a string literal and no format arguments [-Werror=format-security]` a new error on jammy? I'm seeing that working on ensuring Ceph works with OpenSSL 3 ( but want to confirm working build before that even)
[10:20] <LocutusOfBorg> icey, might be a gcc-11 change
[10:20] <LocutusOfBorg> icey, if you only care about openssl 3 changes, better use gcc-10
[10:21] <icey> LocutusOfBorg: well, it'll need to build on Jammy at some point anyway :-P
[10:40] <icey> LocutusOfBorg: is there some magic incantation to use sbuild with Jammy and a specific gcc? or should I just grab an impish chroot?
[11:18] <pi3> Guys, I debianized acme-client of OpenBSD OS: https://github.com/baytuch/acme-client
[12:18] <LocutusOfBorg> icey, I add gcc-10/g++-10 to control file and export CC=gcc-10 export CXX=g++-10 in rules
[12:19] <icey> LocutusOfBorg: thanks, that's what I'm trying now so glad it sounds reasonable :-P
[12:20] <LocutusOfBorg> but yes, fixing gcc-11 build failures is also needed
[15:41] <slyon> ddstreet: hey! May I get your comment on https://code.launchpad.net/~slyon/ubuntu/+source/systemd/+git/systemd/+merge/411528 ? I'm afraid we need to find a different fix for LP: https://bugs.launchpad.net/bugs/1934147 as the current patches regressed in UC18
[19:21] <vorlon> lto1: fatal error: bytecode stream in file '.libs/swigutil_rb.o' generated with LTO version 9.4 instead of the expected 11.2
[19:22] <vorlon> lovely
[19:23] <vorlon> mwhudson: ^^ is that the swig/ruby thing you were mentioning? (subversion/)
[20:27] <mwhudson> vorlon: yes
[23:19] <vorlon> mwhudson: does https://launchpad.net/ubuntu/+source/supertuxkart/1.3+dfsg1-2/+build/22310620 look like it needs a non-default -march incantation, or is this using an instruction it shouldn't be using on armhf?