[10:04] <clobrano> Hi all
[10:04] <ogra_> hey clobrano
[10:07] <clobrano> hi ogra_, a little question, I looked around but I haven't found anything so far: I would need to change something in a driver (e.g. option), like adding a vid/pid pair
[10:07] <clobrano> usually, I would recompile the kernel with this change, is that possible on ubuntu core? Is there another way to do so?
[10:07] <ogra_> clobrano, you mean via a udev rule or dircetly in the driver ?
[10:08] <clobrano> ogra_: directly in the driver
[10:08] <ogra_> for that i fear you have to recompile the kernel,. yes
[10:08] <clobrano> is that still possible for ubuntu core?
[10:09] <ogra_> (thouht often enough a udev rule is enough to tell the kernel to load a specific driver)
[10:10] <clobrano> ogra_: unfortunately this is necessary for our project
[10:11] <ogra_> what device is that ? for armhf we have semi-good documentation for building the device tarball ... i'm not sure we have anything for x86 (where the tarball gets auto-generated by the image build system)
[10:11] <ogra_> you would actually build your own device tarball for what you want to do and use that with ubuntu-device-flash to generate an image
[10:15] <zyga> ogra_: hmm, no lspci/lsusb on snappy?
[10:16] <clobrano> ogra_: well, the documentation for armhf could be a good starting point
[10:17] <ogra_> clobrano, https://developer.ubuntu.com/en/snappy/guides/porting/ see the section about the devcie tarball, hardware.yaml etc
[10:17] <clobrano> ogra_: thanks ;)
[10:17] <ogra_> zyga, real men use /sys directly :P
[10:21] <zyga> ogra_: and remember all the enums ;)
[10:21] <ogra_> indeed, from the top of their head :)
[11:27] <asac> anyone around who knows snapcraft?
[11:27] <asac> ted: ogra_: ?
[11:28] <asac> i need to run a command for building qt5 from source after the checkout
[11:28] <asac> is there a hook feature post-pull or something?
[11:31] <lool> asac: I've been requesting hooks for a while
[11:31] <lool> asac: but instead, just create a make part and use the bits from the qt parts
[11:31] <asac> lool: not sure i understand
[11:32] <asac> i should derive a new plugin?
[11:32] <asac> e.g. on autotools
[11:32] <asac> and then extend the pull code to run a command in srcdir ?
[11:33] <asac> hmm. shouldn the make plugin allow to allow specific mark targets that are not make; make install?
[11:35] <asac> lool: is it possible to have a local part in a snapcraft tree that doesnt pull anything?
[11:35] <asac> e.g. can i make my parts/qt5/ directory and put a makefile in there that then does all it needs ?
[11:35] <asac> guess i am on wrong track
[11:36] <lool> asac: so your goal is what again?
[11:37] <lool> asac: most of the time, you don't need a new plugin
[11:37] <lool> plugins are for recurring cases
[11:37] <lool> asac: we don't have any config in the make plugin; it indeed defaults to make and make install DESTDIR=...
[11:38] <lool> asac: if you don't want to pull anything, just say source: .
[11:42] <asac> lool: qt5 from git... you git clone topath; cd topath; perl init-repository
[11:42] <asac> i dont know how to best run init-repository
[11:43] <asac> lool: its like repo sync that gets all the real source
[11:44] <lool> asac: while you could hack this around with a makefile, if you want the "pull" semantics of snapcraft to map to this different way of pulling, you indeed need a plugin
[11:44] <asac> lool: right. wondered if there could be a post-pull mangling hook
[11:45] <asac> maybe all stages should have pre and post hooks?
[11:45] <asac> guess not very clean
[11:45] <asac> lool: can i write local plugins yet?
[11:45] <asac> or do i best work inside the snapcraft tree to add new plugins?
[11:48] <lool> asac: I personally would like the pre- / post- hooks as I feel it would be useful, however it's not in the spirit
[11:48] <lool> snapcraft documents parts, not actions/tasks
[11:48] <lool> so hooks already feel wrong there
[11:48] <asac> right
[11:48] <lool> and then hooks would potentially make it harder to port snapcraft to non-linux platforms
[11:49] <asac> well i kind of agree on spirit
[11:49] <asac> but i hate the non-reuse feature of deriving from a specialized class
[11:49] <lool> if people start having a bunch of shell scripts running sudo apt-get install foo etc.
[11:49] <asac> so maybe having a plugin system that allows to add reusable things pre-post would be good
[11:50] <asac> so write a post-pull plugin that you can add through an option in parts to any plugin
[11:50] <asac> maybe call it extension :)
[11:50] <asac> for instance
[11:50] <asac> copy
[11:50] <asac> many want that i guess
[11:50] <asac> maybe could go in Base
[11:51] <asac> but if not, its not good for reuse
[11:51] <asac> as it is
[11:51] <asac> assuming there are many useful helper thingies that not all want ...
[12:36] <ogra_> mvo, is there a bzr tree for initramfs-tools-ubuntu-core ?
[12:37]  * ogra_ cant seem to find one
[12:38] <mvo> ogra_: just https://code.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core
[12:38] <mvo> ogra_: but freel free to setup one
[12:39] <ogra_> ah
[12:48] <biezpal> Hey everyone. We're trying to run lxc-start command and getting the following apparmor message in syslog
[12:48] <biezpal> apparmor="DENIED" operation="file_inherit" profile="/usr/bin/ubuntu-core-launcher" name="/dev/null" pid=17552 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[12:48] <biezpal> It seems like apparmor profile for ubuntu-core-launcher is blocking lxc-start command. Our profile for lxc-start is ignored, what we are doing wrong?
[12:54] <biezpal> ogra_, I believe you can help us :)
[12:55] <ogra_> biezpal, i guess jdstrand is better in that ...
[12:56] <ogra_> one thing to keep in mind if you sideload a snap is that the profile is only re-generated if you have a new version number
[12:56] <ogra_> so bump that before installing your snap locally
[12:58] <biezpal> ogra_, ok, thanks
[12:58] <biezpal> jdstrand, could you advise something?
[13:03] <jdstrand> hey, reading
[13:04] <jdstrand> biezpal: I'd need to look at the snap. is it in the store? how are you invoking it?
[13:11] <jdstrand> biezpal: actually, looking at the denial, it is in the launcher. can you adjust '/etc/apparmor.d/usr.bin.ubuntu-core-launcher' to have this before the trailing '}': /dev/null rw,
[13:11] <jdstrand> biezpal: then do: sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
[13:11] <jdstrand> biezpal: then try again
[13:27] <cwayne> heya, whats the easiest way to resize my snappy kvm image so that i can install larger snaps?
[13:33] <ogra_> cwayne, well, add zeros to the end of it, resize the writable partition, resize the filesystem on the writable partition
[13:33] <ogra_> http://paste.ubuntu.com/12117162/
[13:33] <ogra_> :D
[13:33]  * ogra_ is just working on a prototype to do exactly that on first boot
[13:36] <Chipaca> ogra_: https://code.launchpad.net/~chipaca/snappy/manpage-ftbfs/+merge/268330 if you've got a sec?
[13:36] <Chipaca> (not many people with review-ability right now ;) )
[13:51] <ogra_> Chipaca, sorry, was dragged away for a moment ... as far as i can judge that code it looks fine :)
[13:52] <Chipaca> ogra_: evil draginses awayes
[13:52] <ogra_> Chipaca, in line 25 ... are you sure /usr is in $BUILDDIR ?
[13:52] <ogra_> or was /usr/bin/snappy the whole wrong path anyway ?
[13:53] <Chipaca> ogra_: snappy is just under obj-yadda/bin/
[13:54] <Chipaca> ogra_: http://pastebin.ubuntu.com/12118266/ is what i got when running find in debian/rules
[13:56] <ogra_> Chipaca, ack ... approving then
[13:56] <ogra_> done
[13:57]  * Chipaca gefingercrossen
[13:57] <ogra_> haha
[14:25] <ogra_> Chipaca, hmm, same error it seems
[14:25] <ogra_> can't load package: package launchpad.net/snappy/i18n/xgettext-go
[14:26] <Chipaca> ogra_: i see a successful build on amd64
[14:27] <ogra_> ah, then that was i386 only
[14:27] <ogra_> https://launchpadlibrarian.net/214836852/buildlog_ubuntu-wily-i386.ubuntu-snappy_1.5ubuntu1-1%2B632~ubuntu15.10.1_BUILDING.txt.gz
[14:31] <Chipaca> armhf worked too
[14:32] <Chipaca> i say we drop i386 from supported architectures and move on
[14:32] <ogra_> haha
[14:32] <ogra_> tell that to the edison people :P
[15:44] <jdstrand> stgraber: fyi in case you missed it, I commented on the lxd snap in the store. please see the review comments
[15:48] <longsleep> ogra_: did you see my script for the resize: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh - any reason you do not use 'growpart' ?
[15:50] <ogra_> longsleep, what are the deps and does it support any kind of filesystems ?
[15:50] <ogra_> i wanted to use parted since thats our standard tool and gets the most maintainer attention ... but parted has to big deps to ship it inside the initrd
[15:50] <longsleep> ogra_: growpart is on snappy already
[15:51] <DarwinF> I sideloaded an app onto my RPi and whenever I try to start the service I get an error with "... name org.freedesktop.PolicyKit1 not provided..." Is there a way to fix that?
[15:51] <longsleep> ogra_: (its coming with cloud init i think)
[15:53] <ogra_> longsleep, ah, i need it in the initrd ... i'll have to take a look
[15:53] <stgraber> jdstrand: thanks. At a conference this week, will check next week.
[15:53] <longsleep> ogra_: all that cut tr sed stuff from your script looks scary - so maybe growfs can help to avoid that
[15:54] <ogra_> longsleep, whats scary about it ?
[15:54]  * ogra_ fids it crystal clear ;)
[15:55] <ogra_> *finds
[15:55] <longsleep> ogra_: :D
[15:55] <longsleep> well i guess i thind multiple sed tr cut pipes scary in general
[15:56] <ogra_> well, yeah, its a prototype ... normally i'D merge the tr/cut stuff into one sed line :)
[15:56] <ogra_> and it is likely throw away work anyway
[15:56] <longsleep> ogra_: yeah, it is totally valid to use
[15:57] <ogra_> just to get the feature fast ... later it will get re-implemented
[15:57] <longsleep> ogra_: also i took a different approach to find the partition - i was not using findfs instead i use blkid and go through /sys to find all the stuff
[15:58] <ogra_> yeah, findfs is used all across the initrd ...
[15:58] <ogra_> which made me pick it ...
[15:58] <longsleep> right
[15:58] <longsleep> ogra_: though i wonder why do you need the sanitizing code, should it not return good values already?
[15:59] <ogra_> longsleep, it returns the device node for the partition
[16:00] <ogra_> if i use a USB key that will be /dev/sdn1
[16:00] <ogra_> for mmc you have /dev/mmcblknp1
[16:00] <ogra_> so you always get the XpX in mmc nodes ...
[16:01] <longsleep> ogra_: ok, so then i would recommend to use /sys to find whatever else you need, instead to use that case block
[16:01] <longsleep> (starting from /sys/class/block/..)
[16:02] <ogra_> hos does that help me getting rid of the p ?
[16:02] <ogra_> *how
[16:04] <ogra_> i need to get from the return value from findfs to the device name ...
[16:04] <jdstrand> stgraber: sure, np. just wanted to make sure you saw them
[16:04] <jdstrand> stgraber: enjoy :)
[16:04] <longsleep> ogra_: well i dont know but i think whatever findfs returns should have its entry in /sys/class/block/
[16:05] <ogra_> and non mmc'S return the right thing while mmcs do return something with a XpX at the end
[16:05] <longsleep> ogra_: that folder should contain anything else
[16:06] <longsleep> ogra_: the name should not matter when you traverse through sys
[16:06] <ogra_> hmm
[16:07] <longsleep> ogra_: you can find the device name by following the symlink of /sys/class/block/whatever
[16:07] <longsleep> ogra_: then go one level up and read the dev
[16:07] <longsleep> file
[16:07] <longsleep> that will work whatever names the block partitions have
[16:08] <longsleep> eg /sys/class/block/sda1 -> ../../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
[16:08] <longsleep> follow the symlink, then ../dev is the name of the device
[16:08] <ogra_> not in case of mmc :)
[16:09] <longsleep> no?
[16:09] <ogra_> no, the content of dev just püoints back to the partition
[16:09] <longsleep> go one level up
[16:09] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /sys/class/block/mmcblk0p2/dev
[16:09] <ogra_> 179:2
[16:10] <longsleep> yes and then follow that symlink again below /dev/block/179:2
[16:10] <ogra_> /sys/dev/block/179:2/dev is just the same thing
[16:10] <longsleep> right, one more level of links to follow
[16:10] <ogra_> going one level up wont get me mmcblk0
[16:11] <longsleep> when you have 179:2 open the link of /dev/block/179:2
[16:11] <longsleep> will be ../sda or similar
[16:11] <longsleep> then you have it
[16:11] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ readlink /sys/dev/block/179:2
[16:11] <ogra_> ../../devices/platform/mmc-bcm2835.0/mmc_host/mmc0/mmc0:0007/block/mmcblk0/mmcblk0p2
[16:11] <ogra_> ah, i get what you mean
[16:12] <longsleep> you are still one level too deep
[16:12] <ogra_> yes, but that actually allows to go up
[16:13] <ogra_> i doubt it will be much less code than the case statement (which is way to big anyway, the *) stuff is superfluous )
[16:14] <longsleep> it will not be less code, but it will support anything the kernel can come up to. I do not know how many possible partition naming schemes there are
[16:14] <ogra_> yeah, indeed
[16:14] <longsleep> thats why i wanted to use the kernel provided information to find stuff
[16:17] <ogra_> well, i guess i'll re-use some of your resize-snappy lines :)
[16:18] <ogra_> looks indeed a bit saner :)
[16:19] <ogra_> though i still dont think i'll use growpart, that would introduce a hard dep of initramfs-tools-ubuntu-core on cloud-guest-utils
[16:19] <longsleep> ogra_: yeah - if you can get the sfdisk stuff working that should be totally fine
[16:20] <ogra_> (and i need the size checks ahed of running anything ... we only want to grow if it it actually useful)
[16:20] <ogra_> *if it is
[16:20] <longsleep> grofpart just gives you all the gear already and checks if there is something to resize
[16:20] <longsleep> grow*
[16:20] <ogra_> i dont see you running fsck ...
[16:20] <longsleep> yeah growpart has this --fudge parameter which does that check
[16:21] <longsleep> yeah i am not running fsck
[16:21] <longsleep> probably bad :(
[16:21] <ogra_> how do you make resizefs work without it ? by default it should refuse any operation if there isnt a fresh fsck
[16:21] <longsleep> mhm maybe growpart does that
[16:21] <ogra_> yeah
[16:30] <Chipaca> ogra_: you poked at an image build?
[16:30] <ogra_> Chipaca, eeek, sorry !!
[16:31]  * Chipaca scribbles in a little black book, tutting disparagingly
[16:31] <ogra_> Chipaca, running
[16:31] <ogra_> no little star sticker for me today i guess :/
[16:33] <Chipaca> ogra_: well, we can't go handing out golden stars just like that now, can we?
[16:35] <longsleep> I am going to FrOSCon on the weekend, someone of you folks going too?
[16:36] <longsleep> there is a snappy and an ubuntu phone talk on saturday
[17:49] <ogra_> longsleep, i think thats svij's talk :)
[18:19] <svij> ogra_: longsleep: yep
[18:25]  * davmor2 notices ogra_ is now listed on Santa Naughty list, Man that Chipaca has friends in high places
[18:26] <davmor2> hmmmmm wait a minute, you never see Chipaca and Santa in the same room........he writes in a book and.......wait a minute
[18:26] <Mikaela> I thought only sudo without being sudoer resulted to that list
[21:56] <Chipaca> davmor2: Mikaela: i was *wondering* why i got everybody's sudo alert mail
[21:56] <Chipaca> it all makes sense now