=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
dholbachgood morning06:56
fgimenezgood morning07:04
emileboschmornign sir :D07:04
fgimenezhey emilebosch :)07:05
=== chihchun_afk is now known as chihchun
ogra_mvo, mind taking a look at bug 1490115 ? i wonder if i'm on the wrong path having steve so strongly opposing08:15
ubottubug 1490115 in initramfs-tools-ubuntu-core (Ubuntu) "build a fully generic initrd.img without modules" [Undecided,New] https://launchpad.net/bugs/149011508:15
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
zygaogra_: good morning, I tried a random wifi adapter I had with rpi2, it didn't work because of missing firmware. The same adapter obviously works on regular ubuntu. What is the selection criteria for the firmware we ship?08:19
zygaogra_: NB: the driver is present, just the firmware is not08:19
ogra_zyga, hmm, not sure, i thought we ship all of linux-firmware in the device tarball08:20
ogra_oh, wait ... we probably dont in the rpi one08:20
zygaogra_: :D08:21
ogra_do you have an example filename of one firmware file ?08:21
zygaogra_: nice08:21
zygaogra_: I don't remember (I was using it locally yesterday, let me refresh my memory08:21
zygaogra_: and side question, is there a way to force snapy to update core snap when it is sideloaded08:21
ogra_sudo snappy update ubuntu-core ?08:22
zygait say "no no, sideloaded, go away" in nicer way08:22
ogra_(you can not really sideload it, can you ? )08:22
zygaogra_: I built the image with the same shell command you gave me08:22
zygaogra_: and that's what I got08:22
mvoogra_: sure, I have a look. debuging initramfs stuff right now, not exactly fun08:23
zygaogra_: (and don't ask me how I copied it to an sd card when all the readers I could find were not working)08:23
zygaogra_: netcat to a beagle bone black booted from emmc08:23
zygaogra_: the driver is r8188eu08:24
zygaogra_: I can give you the exact message I get on rpi2 but I need to get loads of coffee first08:25
zygaogra_: and I was on 149 and AFAIR we're at 152 now08:25
zygaon rolling08:25
=== chihchun is now known as chihchun_afk
ogra_zyga, heh https://bugs.launchpad.net/raspbian/+bug/142446908:34
ubottuLaunchpad bug 1424469 in Raspbian "firmware-realtek is missing rtl8188eufw.bin" [Undecided,New]08:34
ogra_not only ubuntu :)08:34
zygaogra_: oh, fun :)08:34
zygaogra_: thanks08:34
ogra_zyga, can you file a snappy bug pointing out that we need to ship the content of linux-firmware in the device tarball ?08:35
ogra_(and assign it to me for fixing it in 15.04.3)08:36
zygaogra_: on lp:snappy?08:36
zygaogra_: yep08:36
zygaogra_: thanks a lot08:36
ogra_we dont have the kernel in the archive yet08:36
ogra_(else you coudl file it against that)08:36
=== chihchun_afk is now known as chihchun
zygaogra_: I cannot assign it to you https://bugs.launchpad.net/snappy/+bug/149043608:38
ubottuLaunchpad bug 1490436 in Snappy "Ship contents of linux-firmware in the device tarball for rpi2" [Undecided,New]08:38
zygaogra_: even though I can, looking for "ogra" returns nothing in that assignment pop-up08:38
zygaogra_: weird08:38
=== chihchun is now known as chihchun_afk
=== erkules_ is now known as erkules
=== chihchun_afk is now known as chihchun
=== vrruiz_ is now known as rvr
mvoogra_: so I looked at the bugreport and wonder if we simply can build our own initramfs thats radically different from the distro one?10:05
ogra_mvo, we already do10:17
ogra_by using initramfs-tools-ubuntu-core ...10:17
ogra_you wont boot snappy without the scripts from there10:18
ogra_shipping MODULES=none in a conf.d file from that packge would be enough to not have any modules inside10:18
ogra_but what i also want it a similar setup to the one we use on the phone where we build the initrd binary in a package ... so that you can just pull the package and grab initrd.img from /usr/lib10:19
mvoogra_: aha, ok. I wasn't aware of the phone idea10:20
ogra_i outlibed that in my last comment10:20
mvoogra_: looks like I was not reading this part carefully enough then :P I know quite a bit now about the ubuntu-core-roofs now (more than I want!). I managed to make it boot though with the new kenrel/os decoupling, still a lot of ugly stuff left that I need to fix first10:22
mvobefore it can go in10:22
ogra_generally we should just start with MODULES=none ... but i also want to get the initrd generation out of the rootfs build process10:22
mvoogra_: yes, agreed. the new kernel snap should give us some interessting options here10:23
* ogra_ poinnts to bug 1490107 for the last statement10:23
ubottubug 1490107 in livecd-rootfs (Ubuntu) "rootfs contains all initramfs dependencies and tools" [Undecided,New] https://launchpad.net/bugs/149010710:23
ogra_having a binary initrd ready made in a .deb would save us from a lot of hackery to fix this bug :)10:24
mvoogra_: i.e. we will need something that takes a kernel and makes a snap out of it. that might be a good sstarting point to rethink how we crate the initramfs, we could build it as part of this convertion10:24
ogra_i wouldnt do it dynamic at all10:24
mvoogra_: silly question, so the phone already is using a deb to create the initird?10:24
mvocould we simply re-use this for us too? or are you concerned about duplication?10:25
ogra_its a rather ugly buuld process since we do it on a package builder ... so it need sto jump through some fakeroot/fakechroot setup10:25
ogra_*needs to10:25
ogra_yes, we could re-use it10:25
ogra_right away with a few filename and dependency changes in teh package i think10:26
=== davidcalle_ is now known as davidcalle
mvoogra_: hm, ok. ugly sounds … ugly10:27
ogra_yeah, the curse of package buildds :)10:28
ogra_the package is ubuntu-touch-generic-initrd if you want to take a look10:29
* mvo looks10:32
ogra_hmm, LP doesnt seems to like this package ... weird10:33
mvoogra_: hm, not that ugly, I mean, when you described I expected it to be much worse10:34
ogra_well, ugly enough, but the best way to build it atm10:34
* mvo nods10:34
dholbachis https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 still required?10:43
pindongahi all... I've been making some progress with my snap package, however I'm now having issues with the service not starting properly. When I run systemctl start the logs say the service is starting but nothing happens ; however when I manually execute the command specified in the systemd unit file (including env vars etc) the daemon starts correctly and stays up12:02
pindongaI don't see anything in the logs12:02
pindongaany ideas how i can debug and find out what's going on?12:02
ogra_hmm if ubuntu-core-launcher has issues running it it usually writes to syslog ... weird that you dont see anything12:04
pindongaogra_, the weird thing is that I run the ubuntu-core-launcher cmd manually from the shell and it works fine12:04
ogra_no apparmo denials or seccomp blocks in the log ?12:05
pindongano, I've set the snap to unconfined for now to avoid anything related to lock down perms12:05
* ogra_ isnt sure the unconfined profile applies to seccomp actually12:07
pindongaogra_, still nothing in syslog about seccomp though12:07
ogra_did you check with sc-logresolve ?12:07
pindongano, but I just run it and nothing is returned12:08
pindongaogra_, this is what I see when I install the snap: http://paste.ubuntu.com/12237761/12:08
pindongaafter that I run ps and nothing shows up12:08
pindongaie, the process I'm looking for is not running12:09
mvopindonga: is this 15.04 or rolling? if rolling we have a nice snappy service status command that hopefully helps debugging12:13
pindongamvo, it's the raspi2 img, which I think is 15.0412:14
pindongamvo, should I switch to rolling? how?12:14
mvopindonga: its fine, journalctl will also give you all the info hopefully12:14
pindongamvo, journalct -xe doesn't show anything usefu12:15
pindongajust says Unit ... has begun starting up12:15
mvopindonga: you need to figure the system unit name by looking into /etc/systemd/system and systemctl status $servicename12:15
mvopindonga: hm, what does systemctl status give you? if it stops or dies it should be visible there12:16
pindongabut ps shows the process is not running12:16
ogra_GRRR ... so parted on armhf calls the partition table "msdos" while parted on amd64 calls the partition table "mbr" on the same device12:17
ogra_yay, standards12:17
mvopindonga: hm, what does "systemctl start p910nd_p910nd_0.97" print?12:18
mvopindonga: and systemctl status p910nd_p910nd_0.97 after the start? still nothing?12:19
pindongamvo, the same as before12:20
pindongaactive: Inactive (dead)12:20
pindonga+ the log about starting the deamon12:20
* mvo scratches head12:20
pindongamvo, if I run the cmd as specified in the systemd unit file the process stays up12:20
pindongaie, SNAP_APP=... TMPDIR=... ... /usr/bin/ubuntu-core-launcher p910nd.sideload p910nd.sideload_p910nd_0.97 /apps/p910nd.sideload/0.97/p910nd12:20
pindongaso this is something related to systemd afaict12:21
mvopindonga: and journalctl p910nd_p910nd_0.97 has nothing to add I presume?12:21
mvopindonga: would you mind pushing your snap somewhere? chinstrap or peple.cc or something, then I can have a look maybe12:21
pindongamvo, the only thing that shows up in journalctl is12:22
pindongaAug 31 12:18:37 localhost.localdomain systemd[1]: Started p910nd - simple printer daemon.12:22
pindongaAug 31 12:18:37 localhost.localdomain systemd[1]: Starting p910nd - simple printer daemon...12:22
pindongamvo, sure12:22
mvopindonga: hrm, it really should at least print a exit-status if it started it in vain12:22
pindongamvo, chinstrap.canonical.com:~ricardo/p910nd_0.97_multi.snap12:23
rsalvetifgimenez: welcome back :-)12:30
fgimenezhey rsalveti, thanks! still trying to catch up.. :)12:32
rsalvetiyeah :-)12:33
sergiusensogra_: that's strange, u-d-f used to create them both with 'msdos' before moving to gpt12:43
sergiusensmvo: pindonga just in case 'sudo journalctl -u p910nd_p910nd_0.97.service'12:43
ogra_sergiusens, well, thats a USB kesy carrying my writable part, it was created with the "disks" tool from the desktop ... it is just weird that parted on different arches seems to output different things12:46
ogra_(not hard to fix but still weird)12:47
pindongasergiusens, doesn't add any new data12:49
mvopindonga: looks like "type=forking" is needed, is there a way to start it in no-fork mode maybe?12:54
pindongamvo yes12:56
pindongaif you run it with -d12:56
pindonga(contrary to what you'd expect :/)12:56
mvopindonga: please try to add that to the systemd file and that should work then12:56
pindongaalthough it also prints out debugging info12:56
pindongamvo, is this something that would be otherwise fixed via seccomp perms?12:56
mvothats a strict systemd thing12:56
=== chihchun is now known as chihchun_afk
pindongamvo, ok, running with -d doesn't really work, bc it exists right away13:00
pindongamvo, but adding Type=forking to the unit file does13:00
pindongamvo, does this mean I need to provide my own unit file in the snap?13:00
pindongaor can I tell snappy to create it using Type=forking somehow?13:00
mvopindonga: hm, looks like we need to add a option for snappy then so that you can have type=forking.13:08
pindongamvo, until then, can I ship my own unit file with the snap somehow?13:08
pindongamvo, shall I file a bug for this? where?13:09
sergiusensmvo: btw, would be nice to get your opinion on https://code.launchpad.net/~sergiusens/snapcraft/less-source/+merge/26954713:09
pindongasergiusens, q about snapcraft... how can I tell snapcraft to crosscompile my snap for armhf ?13:14
ogra_you cant yet13:14
pindongaso I still need to manually build my snaps for arm?13:14
ogra_(planned feature indeed)13:14
ogra_you need to run your snapcraft on arm or in an armhf chroot13:15
pindongaah, k13:15
pindongaany ETA for that one? it means you can't use snapcraft (yet) to build multi-arch snaps iiuic13:15
pindonga(asking just to know, no pressure :))13:16
ogra_no, sorry, no idea13:16
pindongano worries13:17
mvopindonga: we don't support raw unit files right now, but we should and you are the use-case now :) https://bugs.launchpad.net/snappy13:17
pindongamvo, I'll file the bug13:17
mvosergiusens: on the phone right now, but I have a look13:17
pindongamvo, https://bugs.launchpad.net/snappy/+bug/149057413:37
ubottuLaunchpad bug 1490574 in Snappy "add support for raw systemd unit files" [Undecided,New]13:37
mvothanks pindonga13:45
dholbachnot sure if folks saw the message earlier, but is https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 still required?13:58
dholbachor can it just be rejected?13:58
dholbachcan somebody take a look at https://code.launchpad.net/~dholbach/snapcraft/start-0.2/+merge/268321 as well?13:58
zygasergiusens: 'da icons'14:28
zygasergiusens: I should introduce you to git-lp ;)14:29
sergiusenszyga: no, I don't want to create an engineering process that only I would use ;-)14:30
sergiusenszyga: still waiting for lp integration for git, then it will all be over...14:30
zygasergiusens: what are you missing?14:31
sergiusenszyga: the API to query MPs for git to be exposed14:31
zygasergiusens: it's there14:31
zygasergiusens: we're using it for a few months daily14:31
zygasergiusens: I wrote a few tools that talk to it14:32
zygasergiusens: (also in daily use)14:32
sergiusenszyga: really? Then I'm just waiting on elopio :-)14:32
zygasergiusens: heh, ok, if you want I can tell you some more about it14:32
zygasergiusens: the UI is a bit iffy but it's all there14:32
sergiusenszyga: and python3-launchpadlib works ootb?14:34
zygasergiusens: yes14:35
zygasergiusens: I fixed the only two issues that I found a few months ago14:35
zygasergiusens: I have a PPA with backports for 14.04+14:35
zygasergiusens: ^_^14:35
zygasergiusens: I'm really pushing an agenda here14:35
zygasergiusens: but I'm willing to get stuff done to make it happen14:35
ogra_ricmm, rsalveti, new resize code uploaded to wily ...14:47
ogra_(so we can test it in rolling/edge first)14:47
rsalvetiogra_: cool14:47
rsalvetiricmm seems to be off today, but yeah14:47
ogra_super ugly :(14:47
rsalvetiwe can use it for further testing14:47
rsalvetiyeah, let's hope it works14:48
ogra_i tested the hell out of it for the last three days14:48
ogra_it works, but still ... ugly ...14:48
ogra_parted doesnt allow non-interactive fixing of the GPT14:48
ogra_so the only option was to re-create it based on the original data14:49
sergiusenselopio: https://code.launchpad.net/~sergiusens/snapcraft/source-tests/+merge/26964914:59
zygasergiusens: quick quiestion, I'm working on env changes15:03
zygasergiusens: I have some prerequisites15:03
zygasergiusens: I'd like to change run() not to expand shell globs15:04
zygasergiusens: and be quote-safe15:04
zygasergiusens: (and the question is a ack/nack on the concept)15:06
fgimenezelopio, before i forget, i proposed a mp for the ssh timeout thing https://code.launchpad.net/~fgimenez/snappy/extended-ssh-timeout/+merge/269631 wip until autopkgtest lands15:10
zygasergiusens: offtopic: ...........Warning: unable to find "test_relexepath" in the path15:14
elopioplars: we need to collect the serial console output from the board.15:14
elopiois that hard?15:14
sergiusenszyga: yeah, I haven't looked into fixing that, as well as the rogue cp's printed while running the tests15:15
plarselopio: yes, there's nothing even connected to the serial console15:15
zygasergiusens: ok15:15
plarselopio: can't you just grab syslog at the end of your run?15:15
zygasergiusens: I think I have a working strategy for env transition15:15
zygasergiusens: I'll show you the code in a sec15:15
sergiusenszyga: and wrt env changes, just propose something if it is not much work to get the discussion moving forward15:16
elopioplars: the problem is with the reboots. The ssh is killed, and if it fails to reboot we won't know what happened.15:16
zygasergiusens: yep15:17
plarselopio: it will likely take some effort given the nature of these boards, and the fact that I don't think we have any kind of serial console server in the lab15:17
zygaI'm trying not to break everything while cleaning it up15:17
zygathat's where all the hard parts are15:17
plarselopio: would likely take some custom connectors as well15:17
elopioplars: where should I file feature requests for you?15:18
plarselopio: do something for me please: send an email to me, chris, and ara about the problem, I'll make sure we get a story created for it, but that way they are aware15:18
plarselopio: is reboot failing right now? and isn't reproducing outside of the automation a better option for debugging when things go wrong anyway?15:19
ogra_mvo, bug 1490608 (probably cjwatson is interested)15:21
ubottubug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/149060815:21
zygadown to only one failing test15:24
elopioplars: chris who?15:26
plarselopio: wayne15:26
elopioplars: we have some bugs in failover reboot, yes.15:28
fgimenezelopio, for the cloud instances nova console-log INSTANCE_ID15:28
elopioand we can reproduce outside. But if it fails in the lab, without the log we won't know if it was a known bug or something knew.15:28
elopiofgimenez: :o thanks!15:29
fgimeneznice evening everyone o/16:04
kyrofasergiusens, ping17:17
kyrofasergiusens, unping17:20
sergiusenskyrofa: do you expect me to operate in fifo or lifo?17:26
kyrofasergiusens, :P17:30
kyrofasergiusens, does ubuntu-core-launcher come from the ubuntu-core snap?17:45
sergiusenskyrofa: it comes from the 'ubuntu-core' snap alright (even if it isn't a snap today ;-) )17:46
kyrofasergiusens, is it a .deb?17:46
sergiusenskyrofa: https://launchpad.net/ubuntu-core-launcher/trunk17:46
sergiusenskyrofa: yes17:46
kyrofasergiusens, that's what I was looking for! Thank you :)17:47
Seshu@rsalveti: I added my local project to snapcraft.yaml and did 'snapcraft stage'18:34
nothalSeshu: No such command!18:34
Seshunothal: What?18:35
Seshursalveti: I added my local project to snapcraft.yaml and did 'snapcraft stage', it stops saying "no rule to make install"18:36
Seshursalveti: do I have to add install rules into my makefile?18:52
Seshursalveti: I already get the .deb files from my treditional build...how do I do snapcraft?19:10
tedSeshu, This might be helpful: https://developer.ubuntu.com/en/snappy/snapcraft/19:17
tedSeshu, Not as much the rules, as a definition on how to pull together your package.19:17
SeshuThanks ted. I'm following the link and the examples.19:21
SeshuMy build system bundles into .deb packages. I'm trying to see if I can start snapcraft from using the .deb files already built on my local build system...19:22
SeshuThe closest example I found is wget...I see it pulls the deb package into stage/build directory and continues to create snap...I'm trying to if that pull step could be a copy .deb from my local build directory and continue.19:24
tedSeshu, It's not that flexible right now, as it can only pull from the version of the archive on your current machine.19:31
tedSeshu, We do want to make it more flexible, but the deb stuff needs to grow some.19:31
tedSeshu, You might be more effective using one of the autotools/cmake/python-project/etc. types to build your package.19:32
Seshuok ted.19:38
SeshuWhat do I do if I get "parts libcurl3 and libnm-glib4 have the following files in common:" on snapcraft with plugin: ubuntu21:35
tedSeshu, I think you'll probably have one instance if the ubuntu plugin, with all the packages listed for it. That way it can share dependencies.21:54
SeshuHi ted. how to I specifiy package list?21:58
Seshu    libmosquittopp1:         plugin: ubuntu     libcairo2:         plugin: ubuntu     libnm-glib4:         plugin: ubuntu     libjsoncpp0:         plugin: ubuntu     libcurl3:         plugin: ubuntu21:58
SeshuThis is how I'm having now...21:58
SeshuI tried giving     libmosquittopp1:    libcairo2:        libnm-glib4:     libjsoncpp0:      libcurl3:         plugin: ubuntu21:59
SeshuIt throws error21:59
tedSeshu: deps:\n\tplugin: ubuntu\n\tpackages: [libmosquittopp1, libcairo2]21:59
SeshuOh! okay.22:00
SeshuLet me try that...22:00
SeshuPerfect! that resolved... :)22:03
SeshuThanks much!22:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!