User1: hello
User2: good morning
User3: good morning
User4: good morning
User3: mvo, hey hey
User3: can you kick off a build of https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily?
User3: why is it not set to automatic?
User3: or daily
User3: or whatever the setting is
User5: User3 sure, let me check why its not automatic
User3: <3
User5: fixed and triggered a new build
User3: mvo, https://code.launchpad.net/~dholbach/snapcraft/build-deps-syntax/+merge/269853
 * mvo hugs dholbach
User6: ppisati, mind to take a look at bug 1491094 ?
User7: bug 1491094 in linux (Ubuntu) "wifi USB dongle fails to work with musb-hdrc error" [Undecided,Incomplete] https://launchpad.net/bugs/1491094
User3: mvo, once it's merged we can try to build the branch again ;-)
User8: User6 BBB? or rpi2?
User8: User6 i guess the first
User3: mvo, merged
User6: ppisati, yeah ...
User6: ppisati, sadly rick seems to be back on US timezone, so it might take a bit to get a full syslog
User8: User6 do you know if he receive just a single warning or more than one?
User9: *yawn*
User9: mo'in people
User6: ppisati, i had him re-plug it a few times and he said thats all that is printed in syslo
User6: g
User8: User6 so just a single warning, i guess
User6: as i understand it it should use the rt2800usb ... but seems the kernel doesnt even get that far
User6: (we also tried plugging with the module manually loaded which according to rick made no difference at all ... )
User8: and on a x6 box, it worked, right?
User8: testing on a vivid kernel would be awesome
User6: i thinnk so ...
User8: *x86
User8: let me add some comments to the lp bug
User6: cool, thanks
User8: this thing
User8: "Product: Ð"
User8: this is particularli scary
User6: thats minicom i bet
User6: (getting the actual syslog would likely help a lot)
User6: ppisati, there is another bug where your input might help ... bug 1489412
User7: bug 1489412 in Snappy "RPi2: connection not realiable" [Undecided,New] https://launchpad.net/bugs/1489412
User6: i'm notz really sure what to do with it ... turning off turbo mode on the NIC seems to help a little, but doesnt make the issue go away
User8: User6 so, about the smsc9xx there
User8: User6 i spinned a new kernel with min_free = 32k
User8: and i rebased on the latest 3.19 stable
User8: User6 but i didn't update the meta yet
User6: ah, cool, i'll make sure to pull that in for 15.04.3
User8: User6 when is the release?
User6: my script doesnt use the meta, it just pulls the newest binary kernel from your PPA
User6: not sure
User6: mvo, do we have some schedule for 15.04.3 ?
User6: or ETA
User5: User6 I'm not aware of one
User6: ppisati, so the debian way then :) when its ready
User8: :(
User8: i would like to have some testing before we mass deploy
User8: you know...
User6: (which means if you want something specifically, we can hold it back for that)
User6: well, we can indeed ask for testing and haven people use the 15.04 edge channel
User8: about the first bug, i have a match for that usb vendor/product id on a 4.2 wily kernel:
User8: drivers/net/wireless/mediatek/mt7601u/usb.c:    { USB_DEVICE(0x148f, 0x7601) },
User8: but i don't have that match on 3.19
User8: and
User8: Documentation/usb/hotplug.txt:    USB_DEVICE (vendorId, productId)
User6: ah
User3: https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864
User3: hey rsalveti, I was playing around with snapcraft a bit more - do you think I should triage the list of open bugs right now and tag the ones which have to do with first user experience or something, so we can have all of them in one list? if yes, which name should we use?
User3: mvo, ^ too
User3: https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864 is a quick fix I could do myself :)
User10: Snappy Ubuntu Core on Banana Pi BPI-M2 http://forum.banana-pi.org/t/snappy-ubuntu-core-on-banana-pi-bpi-m2/432
User6: guest42315, nice !
User9: User11 script -qfc
User11: User9 heh, nice trick! do you know how much overhead that has?
User9: User11 about 23
User9: maybe 24
User11: I mean per line/read/block
User11: (what's that unit?)
User9: User11 sorry, i was being mean. I have no idea of overhead, but I don't think it's much. It does create a file.
User11: script -qfc "sh -c 'sleep 30 & echo payload'" /dev/null |cat
User11: even that works
User11: but this unifies stdout and stderr, doesn't it?
User9: hm, probably
User9: is that bad?
User11: ah yes, it does
User11: I need to keep them separate/intact, yes
User11: but it's a nice trick anyway for other use cases, much simpler than using redirection and tail -f
User11: and having to clean up tail
User11: so thanks for the trick!
User9: User11 and if you take it deeper?
User9: User11 e.g. script -qfc '1>stdout 2>stderr commands here'
User11: I played around with exec, redirections, fifos, bash's <(command) all morning; it's ridiculously difficult
User11: User9 yeah, and then tail -f them both; that's what autopkgtest does on the "outside", as that only needs to be set up once per test
User11: but once for every single command is heavier (and also it's brittle as hell), so I was hoping there was something simpler
User9: ah, you probably also want -e, to get the exit code of the process
User11: it took me two months or so to get that "background tail -f" robust enough, and it's still far from perfect
User9: User11 are you ssh'ing in, or how are you running these things?
User11: User9 depends on the backend; "schroot", "lxc-attach", "ssh", or via a socket for Qemu's case (serial console)
User9: uff
User9: User11 for ssh, a simple -t works
User9: ie ssh -t yadda yadda
User9: User11 what you want is to have a tty
User11: right, with PTYs there's no problem
User9: User11 but it's simple enough, i think, in C
User9: User11 so maybe you need to write a little C :)
User11: yeah, in C it wouldn't be a problem at all
User11: just that I can't assume that I'm able to compile anything on the target
User9: then write C :)
User11: my testbed could be a read-only phone or snappy without even a compiler
User9: User11 it's standard library C; you can cross-compile it without breaking a sweat
User11: User9 well, setting that up (lots of C code and making autopkgtest depend on lots of cross compilers and dynamically shoveling binaries to the testbed) sounds a lot harder than my ugly 15 lines of "kill leftover processes" shell hack :/
User9: arm-linux-gnueabihf-gcc-4.9 -Wall -o blah blah.c && scp/put/cp/whatevs && etc
User11: maybe perl
User11: perl-base is still essential
User9: User11 I'd expect you to say that two months ago, before spending two months on tail :)
User6: pitti, store the PIDs in a file and loop over it with kill when the parent dies  ?
User6: via a trap cleanup command ...
User9: User11 perl works, also, i think
User11: anyway, quite a number of people have answered, and I found some related discussions on various forums
User11: so at least I'm now reasonably sure that I wasn't missing something obvious
User9: User6 you'd have to strace -f to grab all the clones & forks
User6: Chipaca, well, or just start everything through a wrapper function
User9: User11 "try" from libio-pty-perl's examples is probably a good place to start
User9: anyway. to lunch.
User6: ogra@anubis:~/datengrab/images/snappy$ sudo ubuntu-device-flash core --channel edge --device device-pi2-0.16.tar.xz --oem pi2.canonical --developer-mode --install webdm -o kvm-rolling.img rolling
User6: [sudo] password for ogra:
User6: WARNING: this option should only be used to build azure images
User6: Determining oem configuration
User6: great ...
User6: now if it could tell me *WHICH* option "this option" is :P
User6: ah, obviously --device ...
User12: debug output is overrated
User6: heh
User13: hey, is there an easy way to change the channel that my bbb is on?
User13: I think I'd like to get daily updates on it
User6: rickspencer3, no idea if that works ... but try system-image-cli --switch (with a lot of -vvv to increase verbosity)
 * rickspencer3 tries
User6: i guess switching channels will become easier as soon as we dropped system-image
User13: ogra_, does it not need an argument for the channel to switch to?
User6: sure, like on the phone
User6: (up to you want you want to switch to)
User13: ogra_, so, I want to switch to 15.04 edge, is there somewhere that shows me how to formulate that argument?
User6: ubuntu-core/15.04/edge ...
User6: note that this channel is on manual though
User6: only gets builds if we upload changes to the PPA or before a release
User13: manual is good for edge, I think
User13: ogra_, oh, is there a better channel if I want to test latest bug fixes, etc...?
User9: fwiw, channel switching is Not Supported
User6: wily ... ubuntu-core/rolling/edge ... that has daily builds but also the highest chance of breaking
User6: Chipaca, i think it worked for me last time on RPi ... but cant roll back or some such
User13: ogra_, so, the argument is ubuntu-core/rolling/edge ?
User6: yes
User9: i'm not saying it won't work; i'm saying if it works, huzzah, but if it breaks oh well :)
User6: yeah
User13: and it will get automatically update each day, and maybe break a lot?
User6: i dont remember what was broken on my RPi test ... but iirc it initially worked ... and either didnt upgrade or didnt roll back anymore
User13: I guess I can just get another sd card and put a more stable version on it :)
User6: yeah
User13: looks like it is trying to upgrade it :)
User13: [systemimage] Sep 02 12:35:29 2015 (1239) Upgrade path is 155 :)
User13: (note the ":)" is mine
User6: well, we should add more smileys to log output :)
User6: you could then also indicate error severity through them ;)
User6: :/ <- bad ... :( <- severely bad ... X( <- totally dead
User13: ogra_, that would be brilliant
User13: or just emojis
User13: says it is rebooting, I'll take that as a good sign
User6: well, UTF8 is often broken in serial terminal apps :)
User6: but yeah, emojis would rock
User13: emoticons it is, let's get the spec started ;)
User13: well, it didn't reboot itself
 * rickspencer3 reboots, braces for impact
User13: ogra_, so, it rebooted and my led blinking snap started!
User13: I take that as a good sign
User13: is there a way for me to confirm that I am now on the channel that I wanted to be on?
User6: rickspencer3, sudo snappy list -v
User6: abd system-image-cli -i
User13: ubuntu-core 2015-07-29 4       ubuntu*
User13: ubuntu-core 2015-09-02 155     ubuntu
User6: seems it didnt switch
User13: oh?
User13: oh well, I guess I'll just set up a new sd card with the right channel later
User6: * indicates the active one
User13: at least it didn't hose my board
User6: you can force the swtich ... one sec
User6: fw_printenv |grep ^snappy_ab
User6: what does that print ?
User13: (BeagleBoneBlack)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab
User13: Cannot access MTD device /boot/uboot/uboot.env: No such file or directory
User6: oh
User6: hmm, you said this install is old ..
User6: seems it is really old :)
User13: ogra_, if this is going to become a yak shaving exercise, I suggest that we call channel switching "unsupported" and I can flash a new sd card at my leisure
User6: we *do* call it unsupported ;)
User13: well, right, that's my point ;)
User6: but you are running into issues with an ancient bootloader setup
User13: ok, sounds like a reflash is in order anyway, then
User6: it wouldnt even switch on normal upgrade i fear
User6: yeah
User13: are there any docs on how I would use use snappy config?
User6: well, it isnt very user friendly yet
User13: I want to write a snap where you can define the gpio pin to use after installing the snap
User6: you need to create a yaml file and pipe it into the command
User13: ogra_, so, I could write go code that takes an argument in a form post
User13: uses that to write a yaml file
User6: i think sergiusens had some demo code for that
User6: piping from a here doc
User13: then pipes that yaml file in snappy config?
User6: oh, if you want to do it on image level you should be able to define it in the package.yaml of a custom oem snap
User13: ogra_, no, I want to do it on the snap level
User13: i.e. the snap is in the store
User6: (where you would also define your app snap as a requirement)
User13: then it can be configured to use the specified gpio pins
User6: ah, right, yeah , then you need to create a yaml file and run snappy config manually after install
User13: so the end user will have to edit the yaml file on the board and run the command
User13: ouch
User6: nah, it will be more userfriendly
User6: but this is the status quo
User6: we have to many other construction areas atm ... config is only very basic yet
User13: ok, I'll look at sergiusens code when he wakes up if he can point me to it :)
User14: User13 I don't have any code
User13: oh
User13: lol
 * sergiusens has been awake for 3 hours already
User14: User6 rickspencer3 you can also do snappy install [snap] [config]
User13: sergiusens, I meant "wake up" in a totally figurative way :)
User13: sergiusens, is there documentation that I can use anywhere?
User6: ah, thats new to me
User14: User6 it's in the --help (snappy install --help)
User13: so, my idea for the snap is that when the board is ready to be connected to over ssh, it blinks a led
User6: sergiusens, yeah i tried "snappy help" :P
User6: (no, i'm lying indeed)
User13: is there a way that a snap could easily tell if ssh is ready?
User13: i.e. from Go code?
User14: User13 so you indeed want a config to configure where that LED is
User13: sergiusens, yeah
User14: User13 you would need special permissions to check it at the service level
User14: User13 the thing you can do today is poll the port and wait for the ssh signature
User13: there are 2 things I don't know: 1. how to determine if ssh is running, 2. how to allow the developer to config the gpio pin
User13: sergiusens, I can't do that with just the normal network permissions?
User13: seems like I could do a loop and just ping it over localhost?
User14: User13 yes, we don't have any security in place for fine grained networking :-/
User13: sergiusens, yes I can do that, or yes I can't do that?
User14: User13 ping over localhost or over the main interface
User9: User6 User13 cdparanoia has emoticons for status output
User14: User13 yes you can!
User13: ok, that sounds easy enough
User9: :-)  Normal operation, low/no jitter
User9: :-|  Normal operation, considerable jitter
User9: :-/  Read drift
User9: :-P  Unreported loss of streaming in atomic read operation
User9: 8-|  Finding read problems at same point during reread; hard to correct
User9: :-0  SCSI/ATAPI transport error
User9: :-(  Scratch detected
User9: ;-(  Gave up trying to perform a correction
User9: 8-X  Aborted read due to known, uncorrectable error
User9: :^D  Finished extracting
User6: hah
User14: User9 that reminds me of mac system 7
User9: c.Check(logs, DeepEquals, []map[string]interface{}{{"a": 1}, {"a": 2}})
User9: ... obtained []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}}
User9: ... expected []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}}
 * Chipaca goes looking for somebody to wap over the head
User15: Alexander -- this is Viktor from Screenly. Sorry, forgot your nick, but please just wanted to join the channel and say hi.
User9: asac: ^
User15: Thanks :)
User15: Oh and i see mectors is hanging out here too :)
User16: mvip of course
User15: :)
User13: o/ mvip
User15: Need to brush up on my bitchx skills. Haven't spent much time on IRC in the last decade :)
User17: Hello there. I need some help that I can't find yet on Google. How do I add to may #cloud-config DOCKER_OPTIONS :/ does anyone use it?
User17: Is it possible to write to /var/lib/apps/docker/91.69.162.6/etc/docker.conf via cloud-config?
User15: Are there any examples out there of running X11 apps in snaps?
User15: User17 isn't /var residing on /, which is mounter r/o?
User17: you are right, it is read only
User18: User2 There is a rumor that you're working (and close to completing) pip support for snapcraft. Is it true?
User15: bartkusedvinas i'm by no mean a Snappy expert, but my guess is that it's mounted as r/o on boot. As such, you can not modify that file (unless you hackishly re-mount it *inside* cloudinit)
User18: User17 Snaps themselves have a configuration interface, which the docker framework should use. I'm not sure if it is though.
User17: User15 sounds right... tho, i bet that those who are using docker want to add DOCKER_OPTIONS='-H tcp://91.69.162.6:4243'
User17: however i can't find what is the right approch to do so
User6: bartkusedvinas, the shipped cloud-init is only used for bringing up the system ...
User6: not for tinkering with snaps
User18: User15 I think that deb2snap was used to make some Xapps run, but I can't think of an example.
User18: User15 Is there are particular one you're trying to run? Many have Mir backends available as well.
User6: bartkusedvinas, well, you are likely not using docker standalone ... but run something in it
User6: bartkusedvinas, for that something you would create a snap that uses the docker framework
User6: and in that snap you would set such options
User15: User18 Well, yeah, have some things in mind, but was just curious if there were any examples out there. `deb2snap` seems somewhat hackish.
User18: User15 It is :-)
User15: User18 :)
User15: Just out of curiousity, how's Docker configured on Snappy. Is it run on the host, or is it running within a snap?
User15: Because I saw a Docker snap when I was playing with it on the RasPi
User18: User15 I wrote up an examle using Qt/QML, but that is with the Mir backend: http://gould.cx/ted/blog/Creating_a_QML_snap_with_Snapcraft
User6: bartkusedvinas, i guess kickinz1|afk could help (if he werent afk) he maintains the docker framework snap and also the owncloud snap that uses it
User15: User18 Oh cool. Thanks.
User19: mvip docker is a framework snap
User15: kickinz1 ah ok
User15: still getting used to the Snappy lingo
User6: ha, speaking of the devil :)
User17: thanks. i want to try snappy as alternative to coreos
User17: with coreos i had the following cloud-config which would open access to docker https://gist.github.com/edvinasbartkus/8ed0e61a7c7980c087f1
User17: so I would be able to use deploy tools to deploy to coreos docker's my containers
User6: yeah, this is the stuff you would do in a start script of the snap i talked about
User17: i see
User6: http://paste.ubuntu.com/12253305/ i.e. this is the start script used by the owncloud snap
User6: i assume you would have something similar in a coreos-docker.snap
User15: kickinz1 so if Docker is a Snappy framework, i then presume it is running on the host and then snappy is responsible for communicating with Docker, right?
User19: mvip, yes, docker is running on the host, there are some specific apparmor profile management.
User17: I was expecting to find some easy recipie like this https://gist.github.com/edvinasbartkus/a99dd8bf12f717c7c6f5 :))
User15: kickinz1 got it. Thanks.
User17: @orgra_ thanks for the hint to the script. will try to improvise my way ;)
User20: User17 No such command!
User19: mvip, but for now you can connect directly to docker-daemon, be aware, that if you want to do some docker build, docker load/save, you need to have your files in $HOME/apps/docker.$VERSION/
User17: @nothal yeah, i am  aware :) i was expecting just to have such easy solution :P
User20: User17 No such command!
User19: $HOME/apps/docker/$VERSION/
User6: bartkusedvinas, well, i'm pretty sure such an easy setup is possible too ...
User15: kickinz1 got it.
User6: bartkusedvinas, the point in snappy is that you are completely confined ... so you would never modify any of the system setup of docker but ship your own
User9: User11 question for you sir
User9: User11 what should "journalctl -q -u something-that-does-not-exist" print, given the -q?
User17: @ogra_ thanks
User20: User17 No such command!
User6: you should leave out the  @ :)
User17: oh :) sorry for being newby
User17: and even spelling like a newbie :))
User11: User9 you mean wrt. the -- No entries --? -q is documented as "Suppresses any warning messages regarding inaccessible system journals when run as a normal user.", but I see how one would want to shut up that message too :)
User6: no worries ...
User6: usually the ubuntu bots dont use @ but ! ... nothal is special in this channel
User9: User11 the "No journal files were found." was more the thing i was expecting it to suppress
User9: as it stands -o json outputs json except when it doesn't
User9: making it somewhat annoying :)
User11: User9 I don't get that
User11: $ journalctl -q -u something-that-does-not-exist
User11: -- No entries --
User11: $
User9: $ journalctl -q -u potato
User9: No journal files were found.
User9: -- No entries --
User3: sergiusens, is there a switch for snapcraft to force-rebuild everything? or how do you normally use it? (rm -rf parts stage snap; snapcraft)?
User11: User9 but this should be fixed anyway -- "-- no entries --" is quite useless for json output/parsing too
User2: User18 hehe
User2: User18 yes, let's talk
User2: User18 I'm working on this hard
User2: User18 and I'd love to have an accomplice
User18: User2 Do you have a branch pushed?
User2: User18 no, I got into a few blockers, if you want we can sync and talk about that but I'm packed with meetings now
User2: User18 we could invite you to a meeting in 25 minutes (monthly catch up on snappy)
User2: User18 that could help as wel
User2: well
User18: User2 Uhm, okay. I'm not looking for more meetings ;-)
 * ogra_ notes down ... ted ... looking for more meetings ...
User18: Heh, thanks ogra_
User6: :)
User2: lol
User2: User18 so let's just talk here
User2: User18 tell me about your approach
User2: User18 and I'll tell you what I did and what I got stuck on
User18: User2 I was looking at adding a field to the python projects for adding a requirements.txt
User18: User2 Grab it, install it, party on. â my approach :-)
User2: User18 mmm
User2: User18 have you run into the numerous issues in python3app implementation today
User2: User18 it's pretty much all wrong now
User2: User18 it bleeds the python stuff from the system into the snap stage area
User18: Not sure what python3app is? python3-project ?
User2: yep
User2: I never remember if it's -project or -application
User2: but yes
User2: e.g. you pip install requirements and it ignores stuff you have locally installed
User18: Ah, I don't have anything from pip locally installed :-)
User2: not from pip
User2: from the system
User2: I have patched that heavily
User18: So it needs to restrict its search path. Sounds like an envvar?
User2: User18 more than that
User2: User18 you really need to run the python from the stage area
User2: User18 there's no clean way to do it otherwise
User2: User18 and you essentially need to do what virtualenv does to be correct
User18: Sure, but that's handled by setting up the path correctly.
User2: User18 then there are some interesting issues related to that but that's
User2: User18 path? yeah
User2: User18 well
User2: User18 no, just running the right python explicitly
User18: Eh, okay. That can work too.
User2: User18 anyway, it's clear that you just run the right python with the right extra PYTHONHOME helpers and perhaps python -S (so that site is not imported)
User2: User18 then you get empty python and pip install works
User2: User18 I ran into some other issues though
User2: User18 and that's where I'm stuck now (though just stuck with ENOTIME)
User18: User2 K, do you have a branch somewhere that I can look at?
User14: User3 I'm rm'ing, but I do want to at least add a 'clean' statement
User2: User18 I have it locally but it's all teribble as I was trying to figure out how to upstream it
User2: User18 let me show you the diff in a sec
User2: (really stuck in meetings)
User3: sergiusens, it looks like it's necessary to remove the sideloaded package in a snappy system as well when using snappy-remote and not updating the version number
User3: so I can't just build a new snap and snappy-remote it again
User14: User3 oh, Chipaca fixed that, for rolling at least
User3: <3
User3: I love you guys
User6: sergiusens, oh ? including apparmor profile updating ?
User6: (i thinnk that didnt work in the past)
User2: User18 can you tell me more about what test projects you are trying to bundle with pip?
User14: User6 dholbach the version is basically ignored and hashed, sideloading has no upgrade paths in any case, so it is all fine
User6: ah, cool
User6: in the past even for locally sideloaded snaps the apparmor profile wasnt updated when i didnt bump the version
User9: User6 the version in the file is ignored for sideloaded
User6: Chipaca, yup. got that now
User9: User6 it's a base62 hex string of the timestamp in ns
User9: base 50, not base 62, sorry
User9: anyway
User9: it's an apparently random string of a-yA-Y
User9: such that something installed later always compares as newer
User9: as long as your clock isn't completely full of it, that is :)
User9: this means rollback still works as expected
 * sergiusens reboots to enable VT on this laptop
User18: User2 Looking more at the feature genericly. I don't have a specific project I need to package.
User18: User2 To have something to play with I was looking at Jasper, but it's a huge thing to get working, but provides a nice example.
User2: User18 I think it would be healthy to set up some projects as canaries, that you can build "complex" stuff
User2: User18 thanks, I'll have a look at that
User2: User18 as a sanity check, add checkbox-ng to that list, it's very important for an ongoing project we're doing
User2: User18 one thing I think needs more help is building C extensions
User2: User18 the requirements file needs to be coupled with a list of debian packages you need on the outside to build your stuff
User2: User18 stanity check for that is lxml2
User18: User2 How does PIP express those dependencies?
User2: User18 it doesn't at all :D
User2: User18 but it's very very important
User2: User18 without this you won't get important things (requests)
User2: User18 and it's sad but that's what it is
User18: Guess we'll have to take those on a case by case basis. But it means having to parse the file by ourselves :-/
User6: hmm, funny ... why does the rolling initrd on my Pi not attempt to resize at all
User6: oh
User6: probably because i should update to the new initrd in the device tarball :P
User6: super irritating that /usr/share/initramfs-tools/scripts/local-premount/resize exists in my rootfs :P
User6: (but not in the binary initrd)
User21: User4 sorry, I stayed in bed a little later today.
User4: elopio, np! :) we can move our meeting a bit later
User21: User4 thanks for the subunit reviews. I'll make the changes.
User4: elopio, ok thanks, when you have time take a look at https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176
User3: tedg, do you know what's up with https://bugs.launchpad.net/snapcraft/+bug/1491301?
User7: Launchpad bug 1491301 in Snapcraft "qmldemo example doesn't work" [Undecided,New]
User21: User14 or somebody, do you know how to make something like a prerequisite branch in git?
User21: User4 on it. I pushed the two subunit branches.
User14: User21 I'd ask the lp guys, cjwatson maybe knows
User21: I'll wait for them.
User18: User3 Hmm, no. I'll blame sergiusens ;-)
User18: Let me brendacook@example.net.
User21: User4 wow, nice catch on that branch. Now I understand the mess.
User21: User5 sorry, my suggestion on https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 was wrong. I'm testing Federico's proposal now.
User3: thanks tedg
User3: another example is broken as well: https://bugs.launchpad.net/snapcraft/+bug/1491303
User7: Launchpad bug 1491303 in Snapcraft "tomcat-maven-webapp example doesn't work" [Undecided,New]
User5: User21 no problem
User21: ev: about my request for git, if we want to save the master configuration in a repository, we will need to run git on the master.
User21: it's run by the plugin, so we don't need to access the shell manually. But it's not useful in this case to install git in a slave.
User4: elopio, thx maybe we could try to refactor things there
User21: User4 I think it's clear. The mess is because the behaviour is different in uboot, but your new comments make that ok.
User5: User14 I plan to look into u-d-f tomorrow for bigger rootfs, I would also like to increase /boot while at it to something like 256mb, what do you think? we no longer need system-a,b
User14: User5 sounds good, you can also look at my branches in lp:~snappy and reuse those if you want (there's uflash and an import of mostly everything into lp:snappy)
User5: User6 if you have some you could have a look at https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new/+merge/269945 at some point, just to see if there is anything obviously wrong (except for the fixmes :)
User5: User14 oh, do you think that should be the way forward? to use uflash instead of u-d-f?
User14: User5 I do, I really do; it will be easier to separate old world order from the new world order
User14: User5 http://blog.sergiusens.org/posts/Recovering-Ubuntu-Core/
User14: User5 would need some polishing, but that's where I left things before the Lex sprint
User14: User5 I did some general snappy cleanup there (moving away from helpers) so it is not all that easy to follow; but if you want, I can get these branches up to speed with the latest trunk
User6: mvo, hmm ... dont you create a bunch of loops there ?
User5: User14 ok, I check tomorrow
User5: User6 probably, not sure that can be avoided
User5: User6 because the os is on /writable
User6: mvo, the rootfs snap should not live in the writable partition
User6: yeah
User6: thats a prob
User6: how would i do a factory reset ? wiping writable would wipe everything
User6: the rootfs should be a readonly img in /boot
User6: or better in system-boot
User5: User6 thats what we will do with the recovery, there will be a os/kernel in /boot to always go back to
User6: in fact i'd even say the rootfs should be a readonly img in system-boot/a or b
User6: mvo, yeah, but still that mount loop of bind mounting stuff on top of itself isnt good
User5: User6 we also have this mandate to stay within two partitons
User6: mvo, yes, readonly bits should stay in system-boot
User6: so you end up with system-boot and writable
User5: User6 if we put the entire os into system-boot we need a much bigger partition and it can no longer be vfat
User6: oh ?
User5: (at least until we also move to squash/ext.img)
User6: the readonly img is biger than 1G ??
User6: *bigger
 * ogra_ cant imagine that
User6: it should be a few 100 M
User6: if at all
User5: the core is ~90Mb and a kernel ~120Mb
User6: yeah, thats far from the 2G limit for vfat
User5: and we want to keep at least two each, so we need ~500mb
User6: right, still plenty of space
User5: right, but it also means we need to move to squashfs in one step
User5: we can unpack on vfat
User6: why would you unpack ?
User5: because right now the kernel and the os are regular snaps and snaps are unpacked (currently) until we move to squashfs
User5: we will get there, but not right now
User6: well make it unpack a single img file then
User6: you want to loop mount that anyway
User6: no matter what the format is
User6: i dont think the loop you create currently is safe at all
User5: that could be a way, yes. I would prefer to keep snaps the same, this is what I dislike about the approach
User5: User6 unsafe in what way?
User6: dunno, i have to think about it but it makes me twitch heavily
User5: User6 ok
User6: i did something similar for the first iteration opf the phone and stgraber pointed out a lot of flaws with that
 * ogra_ will have to dig up that conversation
User22: ah, you might be
User5: User6 that would be nice, I obviously do not want unsafe stuff, but I also want to understand whats unsafe about it
User5: User6 I can ask him directly too if thats helpful (but after dinner)
User6: yeah
User6: probably even better having him take a look at the code
User5: great, I will ask him
User6: it makes me twitch heavily :)
User5: thanks for the feedback!
User5: well, we will get to the squashfs eventually :) it will all be good. and to the recovery and all the other missing bits
User6: (even though i did something similar with the loop mounted img files on the phone )
User5: but yeah, if its not safe, its not safe and we need to skip the step
User6: i dont see a need for squashfs here
User6: its a nice extra but not really necessary
User6: the img files can even be ext2
User5: User6 well, s/squashfs/binary-images/
User6: (and probably should, for speed)
User5: User23 so if you have a moment at some point, a quick look at https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new/+merge/269945 would be cool and how horrible (or not) the approach is
 * mvo gets dinner
User6: mvo, one thing that comes immediately to mind is that i can indeed edit content in /writable/system-data/os/ubuntu-core.sideload/${snappy_os}/*  at any time, it isnt actually readonly only the bind mount on top is
User6: so i have always full write access to the original files
User23: commented
 * ogra_ commented too 
 * tedg thought some of these nicks weren't LP bots, apparently was wrong.
User14: User5 still around?
User5: User14 yes, but almost ready for eod
User14: User24 did you log a bug about the forking issue in the systemd unit?
User24: yep
User14: User24 can I have the number? I can't find it :/
User24: looking
 * sergiusens sucks at bug searching in lp
 * pindonga thanks firefox for remembering seen urls
User24: https://bugs.launchpad.net/snappy/+bug/1490574
User7: Launchpad bug 1490574 in Snappy "add support for raw systemd unit files" [Critical,Triaged]
User14: User24 ah, the title was ignored by my eyes :-) I thought we just wanted to support forking processes
User24: sergiusens, we probably do
User24: it's just I didn't enough it when I filed the bug :)
User24: s/enough/know/
User14: User18 btw https://code.launchpad.net/~sergiusens/snapcraft/ubuntu-core/+merge/269938 feel free to slaughter it ;-)
snappy
Ubuntu IRC