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