| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| dholbach | good morning | 06:56 |
|---|---|---|
| fgimenez | good morning | 07:04 |
| emilebosch | mornign sir :D | 07:04 |
| fgimenez | hey 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 opposing | 08:15 |
| ubottu | bug 1490115 in initramfs-tools-ubuntu-core (Ubuntu) "build a fully generic initrd.img without modules" [Undecided,New] https://launchpad.net/bugs/1490115 | 08:15 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | ogra_: 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 |
| zyga | ogra_: NB: the driver is present, just the firmware is not | 08:19 |
| ogra_ | zyga, hmm, not sure, i thought we ship all of linux-firmware in the device tarball | 08:20 |
| ogra_ | oh, wait ... we probably dont in the rpi one | 08:20 |
| zyga | ogra_: :D | 08:21 |
| ogra_ | do you have an example filename of one firmware file ? | 08:21 |
| zyga | ogra_: nice | 08:21 |
| zyga | ogra_: I don't remember (I was using it locally yesterday, let me refresh my memory | 08:21 |
| zyga | ogra_: and side question, is there a way to force snapy to update core snap when it is sideloaded | 08:21 |
| ogra_ | sudo snappy update ubuntu-core ? | 08:22 |
| zyga | it say "no no, sideloaded, go away" in nicer way | 08:22 |
| ogra_ | (you can not really sideload it, can you ? ) | 08:22 |
| zyga | ogra_: I built the image with the same shell command you gave me | 08:22 |
| zyga | ogra_: and that's what I got | 08:22 |
| mvo | ogra_: sure, I have a look. debuging initramfs stuff right now, not exactly fun | 08:23 |
| zyga | ogra_: (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 |
| zyga | ogra_: netcat to a beagle bone black booted from emmc | 08:23 |
| ogra_ | ouch | 08:23 |
| zyga | ogra_: the driver is r8188eu | 08:24 |
| zyga | ogra_: I can give you the exact message I get on rpi2 but I need to get loads of coffee first | 08:25 |
| zyga | ogra_: and I was on 149 and AFAIR we're at 152 now | 08:25 |
| zyga | on rolling | 08:25 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | zyga, heh https://bugs.launchpad.net/raspbian/+bug/1424469 | 08:34 |
| ubottu | Launchpad bug 1424469 in Raspbian "firmware-realtek is missing rtl8188eufw.bin" [Undecided,New] | 08:34 |
| ogra_ | not only ubuntu :) | 08:34 |
| zyga | ogra_: oh, fun :) | 08:34 |
| zyga | ogra_: thanks | 08: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 |
| zyga | ogra_: on lp:snappy? | 08:36 |
| ogra_ | yeah | 08:36 |
| zyga | ogra_: yep | 08:36 |
| zyga | ogra_: thanks a lot | 08:36 |
| ogra_ | we dont have the kernel in the archive yet | 08:36 |
| ogra_ | (else you coudl file it against that) | 08:36 |
| === chihchun_afk is now known as chihchun | ||
| zyga | ogra_: I cannot assign it to you https://bugs.launchpad.net/snappy/+bug/1490436 | 08:38 |
| ubottu | Launchpad bug 1490436 in Snappy "Ship contents of linux-firmware in the device tarball for rpi2" [Undecided,New] | 08:38 |
| zyga | ogra_: even though I can, looking for "ogra" returns nothing in that assignment pop-up | 08:38 |
| zyga | ogra_: weird | 08:38 |
| ogra_ | done | 08:39 |
| === 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 | ||
| mvo | ogra_: 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 do | 10:17 |
| ogra_ | by using initramfs-tools-ubuntu-core ... | 10:17 |
| ogra_ | you wont boot snappy without the scripts from there | 10:18 |
| ogra_ | shipping MODULES=none in a conf.d file from that packge would be enough to not have any modules inside | 10: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/lib | 10:19 |
| mvo | ogra_: aha, ok. I wasn't aware of the phone idea | 10:20 |
| ogra_ | i outlibed that in my last comment | 10:20 |
| ogra_ | *outlined | 10:21 |
| mvo | ogra_: 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 first | 10:22 |
| mvo | before it can go in | 10:22 |
| ogra_ | generally we should just start with MODULES=none ... but i also want to get the initrd generation out of the rootfs build process | 10:22 |
| mvo | ogra_: yes, agreed. the new kernel snap should give us some interessting options here | 10:23 |
| * ogra_ poinnts to bug 1490107 for the last statement | 10:23 | |
| ubottu | bug 1490107 in livecd-rootfs (Ubuntu) "rootfs contains all initramfs dependencies and tools" [Undecided,New] https://launchpad.net/bugs/1490107 | 10: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 |
| mvo | ogra_: 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 convertion | 10:24 |
| ogra_ | i wouldnt do it dynamic at all | 10:24 |
| mvo | ogra_: silly question, so the phone already is using a deb to create the initird? | 10:24 |
| ogra_ | yes | 10:24 |
| mvo | could 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 setup | 10:25 |
| ogra_ | *needs to | 10:25 |
| ogra_ | yes, we could re-use it | 10:25 |
| ogra_ | right away with a few filename and dependency changes in teh package i think | 10:26 |
| === davidcalle_ is now known as davidcalle | ||
| mvo | ogra_: hm, ok. ugly sounds … ugly | 10:27 |
| mvo | :/ | 10:27 |
| ogra_ | yeah, the curse of package buildds :) | 10:28 |
| ogra_ | the package is ubuntu-touch-generic-initrd if you want to take a look | 10:29 |
| * mvo looks | 10:32 | |
| ogra_ | hmm, LP doesnt seems to like this package ... weird | 10:33 |
| mvo | ogra_: hm, not that ugly, I mean, when you described I expected it to be much worse | 10:34 |
| ogra_ | well, ugly enough, but the best way to build it atm | 10:34 |
| * mvo nods | 10:34 | |
| dholbach | is https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 still required? | 10:43 |
| pindonga | hi 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 up | 12:02 |
| pindonga | I don't see anything in the logs | 12:02 |
| pindonga | any 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 anything | 12:04 |
| pindonga | ogra_, the weird thing is that I run the ubuntu-core-launcher cmd manually from the shell and it works fine | 12:04 |
| ogra_ | no apparmo denials or seccomp blocks in the log ? | 12:05 |
| pindonga | no, I've set the snap to unconfined for now to avoid anything related to lock down perms | 12:05 |
| ogra_ | ah | 12:06 |
| * ogra_ isnt sure the unconfined profile applies to seccomp actually | 12:07 | |
| pindonga | ogra_, still nothing in syslog about seccomp though | 12:07 |
| ogra_ | did you check with sc-logresolve ? | 12:07 |
| pindonga | no, but I just run it and nothing is returned | 12:08 |
| pindonga | ogra_, this is what I see when I install the snap: http://paste.ubuntu.com/12237761/ | 12:08 |
| pindonga | after that I run ps and nothing shows up | 12:08 |
| pindonga | ie, the process I'm looking for is not running | 12:09 |
| mvo | pindonga: is this 15.04 or rolling? if rolling we have a nice snappy service status command that hopefully helps debugging | 12:13 |
| pindonga | mvo, it's the raspi2 img, which I think is 15.04 | 12:14 |
| pindonga | mvo, should I switch to rolling? how? | 12:14 |
| mvo | pindonga: its fine, journalctl will also give you all the info hopefully | 12:14 |
| pindonga | mvo, journalct -xe doesn't show anything usefu | 12:15 |
| pindonga | just says Unit ... has begun starting up | 12:15 |
| mvo | pindonga: you need to figure the system unit name by looking into /etc/systemd/system and systemctl status $servicename | 12:15 |
| mvo | pindonga: hm, what does systemctl status give you? if it stops or dies it should be visible there | 12:16 |
| pindonga | http://paste.ubuntu.com/12237805/ | 12:16 |
| pindonga | but ps shows the process is not running | 12:16 |
| ogra_ | GRRR ... so parted on armhf calls the partition table "msdos" while parted on amd64 calls the partition table "mbr" on the same device | 12:17 |
| ogra_ | yay, standards | 12:17 |
| ogra_ | :P | 12:17 |
| mvo | pindonga: hm, what does "systemctl start p910nd_p910nd_0.97" print? | 12:18 |
| pindonga | nothing | 12:18 |
| mvo | pindonga: and systemctl status p910nd_p910nd_0.97 after the start? still nothing? | 12:19 |
| pindonga | mvo, the same as before | 12:20 |
| pindonga | active: Inactive (dead) | 12:20 |
| pindonga | + the log about starting the deamon | 12:20 |
| * mvo scratches head | 12:20 | |
| pindonga | mvo, if I run the cmd as specified in the systemd unit file the process stays up | 12:20 |
| pindonga | ie, SNAP_APP=... TMPDIR=... ... /usr/bin/ubuntu-core-launcher p910nd.sideload p910nd.sideload_p910nd_0.97 /apps/p910nd.sideload/0.97/p910nd | 12:20 |
| pindonga | so this is something related to systemd afaict | 12:21 |
| mvo | pindonga: and journalctl p910nd_p910nd_0.97 has nothing to add I presume? | 12:21 |
| mvo | pindonga: would you mind pushing your snap somewhere? chinstrap or peple.cc or something, then I can have a look maybe | 12:21 |
| pindonga | mvo, the only thing that shows up in journalctl is | 12:22 |
| pindonga | Aug 31 12:18:37 localhost.localdomain systemd[1]: Started p910nd - simple printer daemon. | 12:22 |
| pindonga | Aug 31 12:18:37 localhost.localdomain systemd[1]: Starting p910nd - simple printer daemon... | 12:22 |
| pindonga | mvo, sure | 12:22 |
| mvo | pindonga: hrm, it really should at least print a exit-status if it started it in vain | 12:22 |
| pindonga | mvo, chinstrap.canonical.com:~ricardo/p910nd_0.97_multi.snap | 12:23 |
| rsalveti | fgimenez: welcome back :-) | 12:30 |
| fgimenez | hey rsalveti, thanks! still trying to catch up.. :) | 12:32 |
| rsalveti | yeah :-) | 12:33 |
| sergiusens | ogra_: that's strange, u-d-f used to create them both with 'msdos' before moving to gpt | 12:43 |
| sergiusens | mvo: 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 things | 12:46 |
| ogra_ | (not hard to fix but still weird) | 12:47 |
| pindonga | sergiusens, doesn't add any new data | 12:49 |
| pindonga | :/ | 12:49 |
| mvo | pindonga: looks like "type=forking" is needed, is there a way to start it in no-fork mode maybe? | 12:54 |
| pindonga | mvo yes | 12:56 |
| pindonga | if you run it with -d | 12:56 |
| pindonga | (contrary to what you'd expect :/) | 12:56 |
| mvo | pindonga: please try to add that to the systemd file and that should work then | 12:56 |
| pindonga | although it also prints out debugging info | 12:56 |
| pindonga | mvo, is this something that would be otherwise fixed via seccomp perms? | 12:56 |
| mvo | thats a strict systemd thing | 12:56 |
| === chihchun is now known as chihchun_afk | ||
| pindonga | mvo, ok, running with -d doesn't really work, bc it exists right away | 13:00 |
| pindonga | mvo, but adding Type=forking to the unit file does | 13:00 |
| pindonga | mvo, does this mean I need to provide my own unit file in the snap? | 13:00 |
| pindonga | or can I tell snappy to create it using Type=forking somehow? | 13:00 |
| mvo | pindonga: hm, looks like we need to add a option for snappy then so that you can have type=forking. | 13:08 |
| pindonga | mvo, until then, can I ship my own unit file with the snap somehow? | 13:08 |
| pindonga | mvo, shall I file a bug for this? where? | 13:09 |
| sergiusens | mvo: btw, would be nice to get your opinion on https://code.launchpad.net/~sergiusens/snapcraft/less-source/+merge/269547 | 13:09 |
| pindonga | sergiusens, q about snapcraft... how can I tell snapcraft to crosscompile my snap for armhf ? | 13:14 |
| ogra_ | you cant yet | 13:14 |
| pindonga | so 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 chroot | 13:15 |
| pindonga | ah, k | 13:15 |
| pindonga | any ETA for that one? it means you can't use snapcraft (yet) to build multi-arch snaps iiuic | 13:15 |
| pindonga | (asking just to know, no pressure :)) | 13:16 |
| ogra_ | no, sorry, no idea | 13:16 |
| pindonga | no worries | 13:17 |
| mvo | pindonga: we don't support raw unit files right now, but we should and you are the use-case now :) https://bugs.launchpad.net/snappy | 13:17 |
| pindonga | mvo, I'll file the bug | 13:17 |
| pindonga | thx | 13:17 |
| mvo | sergiusens: on the phone right now, but I have a look | 13:17 |
| pindonga | mvo, https://bugs.launchpad.net/snappy/+bug/1490574 | 13:37 |
| ubottu | Launchpad bug 1490574 in Snappy "add support for raw systemd unit files" [Undecided,New] | 13:37 |
| mvo | thanks pindonga | 13:45 |
| dholbach | not 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 |
| dholbach | or can it just be rejected? | 13:58 |
| dholbach | can somebody take a look at https://code.launchpad.net/~dholbach/snapcraft/start-0.2/+merge/268321 as well? | 13:58 |
| zyga | sergiusens: 'da icons' | 14:28 |
| zyga | sergiusens: I should introduce you to git-lp ;) | 14:29 |
| sergiusens | zyga: no, I don't want to create an engineering process that only I would use ;-) | 14:30 |
| sergiusens | zyga: still waiting for lp integration for git, then it will all be over... | 14:30 |
| zyga | sergiusens: what are you missing? | 14:31 |
| sergiusens | zyga: the API to query MPs for git to be exposed | 14:31 |
| zyga | sergiusens: it's there | 14:31 |
| zyga | sergiusens: we're using it for a few months daily | 14:31 |
| zyga | sergiusens: I wrote a few tools that talk to it | 14:32 |
| zyga | sergiusens: (also in daily use) | 14:32 |
| sergiusens | zyga: really? Then I'm just waiting on elopio :-) | 14:32 |
| zyga | sergiusens: heh, ok, if you want I can tell you some more about it | 14:32 |
| zyga | sergiusens: the UI is a bit iffy but it's all there | 14:32 |
| sergiusens | zyga: and python3-launchpadlib works ootb? | 14:34 |
| zyga | sergiusens: yes | 14:35 |
| zyga | sergiusens: I fixed the only two issues that I found a few months ago | 14:35 |
| zyga | sergiusens: I have a PPA with backports for 14.04+ | 14:35 |
| zyga | sergiusens: ^_^ | 14:35 |
| zyga | sergiusens: I'm really pushing an agenda here | 14:35 |
| zyga | sergiusens: but I'm willing to get stuff done to make it happen | 14:35 |
| ogra_ | ricmm, rsalveti, new resize code uploaded to wily ... | 14:47 |
| ogra_ | (so we can test it in rolling/edge first) | 14:47 |
| rsalveti | ogra_: cool | 14:47 |
| rsalveti | ricmm seems to be off today, but yeah | 14:47 |
| ogra_ | super ugly :( | 14:47 |
| rsalveti | we can use it for further testing | 14:47 |
| rsalveti | yeah, let's hope it works | 14:48 |
| ogra_ | i tested the hell out of it for the last three days | 14:48 |
| ogra_ | it works, but still ... ugly ... | 14:48 |
| rsalveti | right | 14:48 |
| ogra_ | parted doesnt allow non-interactive fixing of the GPT | 14:48 |
| ogra_ | so the only option was to re-create it based on the original data | 14:49 |
| sergiusens | elopio: https://code.launchpad.net/~sergiusens/snapcraft/source-tests/+merge/269649 | 14:59 |
| zyga | sergiusens: quick quiestion, I'm working on env changes | 15:03 |
| zyga | sergiusens: I have some prerequisites | 15:03 |
| zyga | sergiusens: I'd like to change run() not to expand shell globs | 15:04 |
| zyga | sergiusens: and be quote-safe | 15:04 |
| zyga | sergiusens: (and the question is a ack/nack on the concept) | 15:06 |
| fgimenez | elopio, 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 lands | 15:10 |
| elopio | cool. | 15:11 |
| zyga | sergiusens: offtopic: ...........Warning: unable to find "test_relexepath" in the path | 15:14 |
| elopio | plars: we need to collect the serial console output from the board. | 15:14 |
| elopio | is that hard? | 15:14 |
| sergiusens | zyga: yeah, I haven't looked into fixing that, as well as the rogue cp's printed while running the tests | 15:15 |
| plars | elopio: yes, there's nothing even connected to the serial console | 15:15 |
| zyga | sergiusens: ok | 15:15 |
| plars | elopio: can't you just grab syslog at the end of your run? | 15:15 |
| zyga | sergiusens: I think I have a working strategy for env transition | 15:15 |
| zyga | sergiusens: I'll show you the code in a sec | 15:15 |
| sergiusens | zyga: and wrt env changes, just propose something if it is not much work to get the discussion moving forward | 15:16 |
| elopio | plars: the problem is with the reboots. The ssh is killed, and if it fails to reboot we won't know what happened. | 15:16 |
| zyga | sergiusens: yep | 15:17 |
| plars | elopio: 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 lab | 15:17 |
| zyga | I'm trying not to break everything while cleaning it up | 15:17 |
| zyga | that's where all the hard parts are | 15:17 |
| plars | elopio: would likely take some custom connectors as well | 15:17 |
| elopio | plars: where should I file feature requests for you? | 15:18 |
| plars | elopio: 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 aware | 15:18 |
| plars | elopio: 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 |
| ubottu | bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/1490608 | 15:21 |
| zyga | down to only one failing test | 15:24 |
| elopio | plars: chris who? | 15:26 |
| plars | elopio: wayne | 15:26 |
| elopio | plars: we have some bugs in failover reboot, yes. | 15:28 |
| fgimenez | elopio, for the cloud instances nova console-log INSTANCE_ID | 15:28 |
| elopio | and 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 |
| elopio | fgimenez: :o thanks! | 15:29 |
| fgimenez | nice evening everyone o/ | 16:04 |
| kyrofa | sergiusens, ping | 17:17 |
| kyrofa | sergiusens, unping | 17:20 |
| sergiusens | kyrofa: do you expect me to operate in fifo or lifo? | 17:26 |
| sergiusens | :-) | 17:26 |
| kyrofa | sergiusens, :P | 17:30 |
| kyrofa | sergiusens, does ubuntu-core-launcher come from the ubuntu-core snap? | 17:45 |
| sergiusens | kyrofa: it comes from the 'ubuntu-core' snap alright (even if it isn't a snap today ;-) ) | 17:46 |
| kyrofa | sergiusens, is it a .deb? | 17:46 |
| sergiusens | kyrofa: https://launchpad.net/ubuntu-core-launcher/trunk | 17:46 |
| sergiusens | kyrofa: yes | 17:46 |
| kyrofa | sergiusens, that's what I was looking for! Thank you :) | 17:47 |
| sergiusens | np | 17:48 |
| Seshu | @rsalveti: I added my local project to snapcraft.yaml and did 'snapcraft stage' | 18:34 |
| nothal | Seshu: No such command! | 18:34 |
| Seshu | nothal: What? | 18:35 |
| Seshu | rsalveti: I added my local project to snapcraft.yaml and did 'snapcraft stage', it stops saying "no rule to make install" | 18:36 |
| Seshu | rsalveti: do I have to add install rules into my makefile? | 18:52 |
| Seshu | rsalveti: I already get the .deb files from my treditional build...how do I do snapcraft? | 19:10 |
| ted | Seshu, This might be helpful: https://developer.ubuntu.com/en/snappy/snapcraft/ | 19:17 |
| ted | Seshu, Not as much the rules, as a definition on how to pull together your package. | 19:17 |
| Seshu | Thanks ted. I'm following the link and the examples. | 19:21 |
| Seshu | My 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 |
| Seshu | The 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 |
| ted | Seshu, It's not that flexible right now, as it can only pull from the version of the archive on your current machine. | 19:31 |
| ted | Seshu, We do want to make it more flexible, but the deb stuff needs to grow some. | 19:31 |
| ted | Seshu, You might be more effective using one of the autotools/cmake/python-project/etc. types to build your package. | 19:32 |
| Seshu | ok ted. | 19:38 |
| Seshu | What do I do if I get "parts libcurl3 and libnm-glib4 have the following files in common:" on snapcraft with plugin: ubuntu | 21:35 |
| ted | Seshu, 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 |
| Seshu | Hi 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: ubuntu | 21:58 |
| Seshu | This is how I'm having now... | 21:58 |
| Seshu | I tried giving libmosquittopp1: libcairo2: libnm-glib4: libjsoncpp0: libcurl3: plugin: ubuntu | 21:59 |
| Seshu | It throws error | 21:59 |
| ted | Seshu: deps:\n\tplugin: ubuntu\n\tpackages: [libmosquittopp1, libcairo2] | 21:59 |
| Seshu | Oh! okay. | 22:00 |
| Seshu | Let me try that... | 22:00 |
| Seshu | Perfect! that resolved... :) | 22:03 |
| Seshu | Thanks much! | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!