=== 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 | ||
clobrano | Hi all | 10:04 |
---|---|---|
ogra_ | hey clobrano | 10:04 |
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:07 |
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:08 |
ogra_ | (thouht often enough a udev rule is enough to tell the kernel to load a specific driver) | 10:09 |
clobrano | ogra_: unfortunately this is necessary for our project | 10:10 |
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:11 |
zyga | ogra_: hmm, no lspci/lsusb on snappy? | 10:15 |
clobrano | ogra_: well, the documentation for armhf could be a good starting point | 10:16 |
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:17 |
zyga | ogra_: and remember all the enums ;) | 10:21 |
ogra_ | indeed, from the top of their head :) | 10:21 |
asac | anyone around who knows snapcraft? | 11:27 |
asac | ted: ogra_: ? | 11:27 |
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:28 |
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:31 |
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:32 |
asac | hmm. shouldn the make plugin allow to allow specific mark targets that are not make; make install? | 11:33 |
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:35 |
lool | asac: so your goal is what again? | 11:36 |
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:37 |
lool | asac: if you don't want to pull anything, just say source: . | 11:38 |
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:42 |
asac | lool: its like repo sync that gets all the real source | 11:43 |
=== chihchun_afk is now known as chihchun | ||
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:44 |
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:45 |
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:48 |
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:49 |
asac | so write a post-pull plugin that you can add through an option in parts to any plugin | 11:50 |
=== shadeslayer_ is now known as shadeslayer | ||
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:50 |
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 ... | 11:51 |
ogra_ | mvo, is there a bzr tree for initramfs-tools-ubuntu-core ? | 12:36 |
* ogra_ cant seem to find one | 12:37 | |
mvo | ogra_: just https://code.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core | 12:38 |
mvo | ogra_: but freel free to setup one | 12:38 |
ogra_ | ah | 12:39 |
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:48 |
biezpal | ogra_, I believe you can help us :) | 12:54 |
ogra_ | biezpal, i guess jdstrand is better in that ... | 12:55 |
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:56 |
biezpal | ogra_, ok, thanks | 12:58 |
biezpal | jdstrand, could you advise something? | 12:58 |
jdstrand | hey, reading | 13:03 |
jdstrand | biezpal: I'd need to look at the snap. is it in the store? how are you invoking it? | 13:04 |
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:11 |
cwayne | heya, whats the easiest way to resize my snappy kvm image so that i can install larger snaps? | 13:27 |
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:33 | |
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:36 |
ogra_ | Chipaca, sorry, was dragged away for a moment ... as far as i can judge that code it looks fine :) | 13:51 |
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:52 |
Chipaca | ogra_: snappy is just under obj-yadda/bin/ | 13:53 |
Chipaca | ogra_: http://pastebin.ubuntu.com/12118266/ is what i got when running find in debian/rules | 13:54 |
ogra_ | Chipaca, ack ... approving then | 13:56 |
ogra_ | done | 13:56 |
* Chipaca gefingercrossen | 13:57 | |
ogra_ | haha | 13:57 |
ogra_ | Chipaca, hmm, same error it seems | 14:25 |
ogra_ | can't load package: package launchpad.net/snappy/i18n/xgettext-go | 14:25 |
Chipaca | ogra_: i see a successful build on amd64 | 14:26 |
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:27 |
Chipaca | armhf worked too | 14:31 |
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 | 14:32 |
=== chihchun is now known as chihchun_afk | ||
=== ogra_` is now known as ogra_ | ||
=== dholbach_ is now known as dholbach | ||
jdstrand | stgraber: fyi in case you missed it, I commented on the lxd snap in the store. please see the review comments | 15:44 |
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:48 |
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:50 |
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:51 |
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:53 |
ogra_ | longsleep, whats scary about it ? | 15:54 |
* ogra_ fids it crystal clear ;) | 15:54 | |
ogra_ | *finds | 15:55 |
longsleep | ogra_: :D | 15:55 |
longsleep | well i guess i thind multiple sed tr cut pipes scary in general | 15:55 |
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:56 |
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:57 |
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:58 |
ogra_ | longsleep, it returns the device node for the partition | 15:59 |
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:00 |
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:01 |
ogra_ | hos does that help me getting rid of the p ? | 16:02 |
ogra_ | *how | 16:02 |
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:04 |
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:05 |
longsleep | ogra_: the name should not matter when you traverse through sys | 16:06 |
ogra_ | hmm | 16:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
longsleep | you are still one level too deep | 16:12 |
ogra_ | yes, but that actually allows to go up | 16:12 |
ogra_ | i doubt it will be much less code than the case statement (which is way to big anyway, the *) stuff is superfluous ) | 16:13 |
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:14 |
ogra_ | well, i guess i'll re-use some of your resize-snappy lines :) | 16:17 |
ogra_ | looks indeed a bit saner :) | 16:18 |
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:19 |
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:20 |
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:21 |
=== alexabreu is now known as alex-abreu | ||
Chipaca | ogra_: you poked at an image build? | 16:30 |
ogra_ | Chipaca, eeek, sorry !! | 16:30 |
* 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:31 |
Chipaca | ogra_: well, we can't go handing out golden stars just like that now, can we? | 16:33 |
longsleep | I am going to FrOSCon on the weekend, someone of you folks going too? | 16:35 |
longsleep | there is a snappy and an ubuntu phone talk on saturday | 16:36 |
ogra_ | longsleep, i think thats svij's talk :) | 17:49 |
svij | ogra_: longsleep: yep | 18:19 |
* davmor2 notices ogra_ is now listed on Santa Naughty list, Man that Chipaca has friends in high places | 18:25 | |
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 | 18:26 |
=== sarnold is now known as sarnold_ | ||
Chipaca | davmor2: Mikaela: i was *wondering* why i got everybody's sudo alert mail | 21:56 |
Chipaca | it all makes sense now | 21:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!