| liuxg | i have flashed ubuntu core to my SD card for QualComm 410c. I inserted the coard into my system. Can anyone tell me how to let it boot from the SD card instead of the built in android system? thanks | 00:34 |
|---|---|---|
| qwas | What are some disadvantages to using snaps? would there be duplication of dependencies? Say, package X uses Y dependency. package Z uses Y dependency. Both snaps include Y dependency. | 00:48 |
| akash | SamYaple_: python3, and then in ubuntu 16.04 i call python3-pip, and python3-dev | 00:54 |
| liuxg | for qualcomm snapdragon board, without network access, it cannot complete the installation. on the board, it does not have the Ethernet, how can I set up the WLAN network? thanks | 01:28 |
| tzununbekov | Hi all. Is there a way to install and use Snappy Ubuntu 16.04 without having an account on ubuntu.com? | 05:10 |
| liuxg | mvo, ping | 06:28 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1888 opened: interfaces: allow special casing for auto-connect until we have assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1888> | 06:47 |
| mvo | liuxg: pong | 06:51 |
| liuxg | mvo, I just got a snapdragon 410c board. I have flashed the latetst software at http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/. however, I cannot get the netowork up so that I cannot complete the network config. Do you know how to do it? thanks | 06:52 |
| mup | PR snapd#1884 closed: tests: get the gadget name from snap list <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1884> | 06:53 |
| liuxg | mvo, the board only has a WLAN, but it does not have a ethernet interface for use. May I modify some part of the software to get my WLAM working so that I can connect to the device? | 06:54 |
| dholbach | hery hey | 06:55 |
| liuxg | mvo, ogra_, we are going to have a talk at Qualcom event. I am now trying to build some demos for the board :) | 06:56 |
| mvo | liuxg: its a known issue, sorry that I did not write a followup on that to the list. the console-conf software does not yet support wlan, however mwhudson is working on this AFAIK. in the meantime the workaround is a usb network adapter | 06:59 |
| mvo | liuxg: would the usb (lan) network adaper unblock you? we might also get mwhudson to release a early version of the new wlan code. when do you need this? i.e. when is the event? | 07:00 |
| mup | PR snapd#1876 closed: cmd/snap: make "snap find" error nicer <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1876> | 07:01 |
| liuxg | mvo, ok. in that case, we probably need to have a ethernet network adapter for it. good to know the workaround. thanks. I am not sure whether it is good to disable console-conf for development software. to developers, it may be a problem. | 07:02 |
| mup | PR snapd#1889 opened: tests: add yakkety test host <Created by mvo5> <https://github.com/snapcore/snapd/pull/1889> | 07:09 |
| tzununbekov | mvo, hey! Could you help me with Ubuntu Snappy 16.04? Trying to figure out if it is required now to have Ubuntu One account to use Snappy | 07:22 |
| mvo | tzununbekov: this is the case right now, we are working on local users that are created differently, but the current image needs a u1 account that is used to setup your local user. the upside is that this is super convinient, i.e. your ssh keys are on the device, your prefered username and we plan to sync the ssh keys in the future so that key update will be totally transparent | 07:26 |
| tzununbekov | mvo, I see, thanks | 07:28 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| morphis | pitti: ping | 07:57 |
| pitti | morphis: contentless pong :) | 07:57 |
| tvoss | good morning | 07:57 |
| morphis | tvoss, pitti: morning :-) | 07:57 |
| morphis | pitti: have a question about systemd and how it sets up /sys/fs/cgroup | 07:57 |
| pitti | morphis: good morning! | 07:58 |
| morphis | pitti: we're running systemd on a 3.4 based kernel | 07:58 |
| morphis | its kind of unsupported by upstream, but works | 07:58 |
| morphis | it somehow fails to setup /sys/fs/cgroup on its own on startup so we have to workaround via https://paste.ubuntu.com/23168270/ | 07:59 |
| morphis | pitti: from what I read in the source it should actually do this on its owner so I am wondering if there might be some hidden thing I am missing in the picture | 08:00 |
| morphis | pitti: as further context info, this is systemd 229 as it comes in xenial | 08:00 |
| pitti | morphis: hm, I tried a reasonably modern systemd (~ 220 or so) on 3.4, back then this worked well enough | 08:00 |
| morphis | pitti: yeah 219 works like a charm | 08:00 |
| pitti | morphis: ah, is that your /sbin/init wrapper? | 08:00 |
| morphis | yes | 08:01 |
| pitti | it should also mount /proc and /sys etc. on its own | 08:01 |
| morphis | right | 08:01 |
| pitti | well, you need /sys if you manually mount /sys/fs/cgroup of course, but shouldn't need /proc and /dev | 08:01 |
| morphis | if I don't put this wrapper in place it fails with error message like "too many symlinks on /sys/fs/cgroup" | 08:01 |
| pitti | morphis: so, I can't say off the top of my head, do you have dmesg from a boot with init=/lib/systemd/systemd directly? | 08:01 |
| pitti | that should have some error message | 08:01 |
| morphis | yes | 08:02 |
| morphis | pitti: it fails very early: https://paste.ubuntu.com/23168277/ | 08:04 |
| morphis | that are the relevant lines | 08:04 |
| morphis | pitti: this somehow looks like its failing to mount a tmpfs on /sys/fs/cgroup | 08:08 |
| morphis | but it doesn't print out any error message for this | 08:08 |
| pitti | morphis: this might be related to 3.4 not supporting name_to_handle_at() or /proc/<pid>/fdinfo yet? | 08:09 |
| morphis | hm, that could it be | 08:09 |
| pitti | https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c | 08:10 |
| pitti | morphis: these are the helper functions that determine whether a path or a fd is a mount point | 08:10 |
| morphis | then both fallbacks doesn't seem to work here | 08:10 |
| pitti | it normally uses name_to_handle_at() as that's the most robust/fastest, then falls back to fdinfo, then falls back to stat9) | 08:10 |
| pitti | stat() | 08:10 |
| pitti | morphis: maybe wrap it in strace, to get an idea what it does? | 08:11 |
| morphis | yes, will check that | 08:11 |
| morphis | pitti: thanks! | 08:11 |
| pitti | morphis: src/core/mount-setup.c, mount_one() indeed uses path_is_mount_point(), and that matches the error message | 08:12 |
| morphis | yeah | 08:12 |
| akash | hello all im using python3 with pip. the snap creates properly, but when executing the script it says it cant find pip via python in the snap | 08:13 |
| pitti | morphis: are there any actual symlinks involved in that environment? | 08:13 |
| akash | can someone tell me how to inject pip into the snap its self for use? | 08:13 |
| morphis | pitti: no | 08:14 |
| mwhudson | mvo: hey, i guess now beta is done we should feed you a new console-conf release | 09:18 |
| mwhudson | mvo: it has wlan support now :) | 09:18 |
| ogra_ | mwhudson, copy it over ! | 09:21 |
| mwhudson | ogra_: need to upload it first! (am editing changelog now) | 09:21 |
| ogra_ | \o/ | 09:21 |
| mwhudson | woo got my gpg passphrase right first time | 09:24 |
| mwhudson | ogra_: 0.0.16~xenial in https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 09:27 |
| ogra_ | ah, the publisher ... | 09:30 |
| ogra_ | (might take a while) | 09:30 |
| mup | PR snapd#1801 closed: snap: make snap download also download the assertions for the snap <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1801> | 09:30 |
| ogra_ | mvo, i think you need to re-do (xz) the pi3 image, seeme the xz step is corrupt (nothing to notice on the running image, so i guess only the zeroed parts are affected, but it is ugly) | 09:36 |
| ogra_ | *seems | 09:36 |
| mwhudson | ogra_: it published now at last | 10:06 |
| ogra_ | do you have access to copy it to the image PPA ? | 10:07 |
| mwhudson | ogra_: no | 10:08 |
| ogra_ | done ... waiting for the next publisher now :) | 10:11 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 10:11 |
| ogra_ | i'll trigger an ubuntu-core build once it is done | 10:11 |
| mwhudson | zyga: did you get your collab-maint access sorted? | 10:15 |
| bzoltan | ogra_: as a snap app developer how can I know what system library I can expect to be on the core snap? Is there a minimal image I can see what packages the snap core is built from? | 10:28 |
| mvo | ogra_: sure, lets redo it | 10:30 |
| mvo | mwhudson: \o/ for wlan | 10:30 |
| ogra_ | bzoltan, since you shouldnt use anything except libc from the core snap thats a moot question .. beyond that there is bug 1608432 | 10:34 |
| mup | Bug #1608432: snaps with type: os should allow publishing of .manifest files <lp-snappy> <Launchpad itself:In Progress by cjwatson> <launchpad-buildd:In Progress by cjwatson> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432> | 10:34 |
| ogra_ | libc and /bin/sh are the only guaranteed bits in ubuntu-core | 10:35 |
| pstolowski | mvo, hey, you know a lot about systemd & deb packaging - any advice on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1622045 ? adding #DEBHELPER# didn't fix it. removing the symlinks in the postrm script "manually" caused the problem with these units after re-installing the deb | 10:35 |
| mup | Bug #1622045: /etc/systemd/system/multi-user.target.wants/snapd.* symlinks not cleaned up when package is removed/purged <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1622045> | 10:35 |
| pstolowski | mvo, i mean after reainstalling, the units are disabled | 10:35 |
| ogra_ | arent the units conffiles ? | 10:36 |
| ogra_ | you need to use the right tools for them if they are | 10:36 |
| pstolowski | ogra_, there are debian/*.service & debian/*socket files for them if that's your question? | 10:37 |
| mvo | pstolowski: the lack of #debhelper# looks like a bug in itself | 10:37 |
| pstolowski | ogra_, ah, no i don't see any conffiles declared | 10:38 |
| mup | PR snapd#1861 closed: tests: fixes to actually run the spread tests inside autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1861> | 10:40 |
| ogra_ | i think you want the deb-systemd-helper tool in your scripts | 10:40 |
| ogra_ | or dh_systemd_* | 10:41 |
| ogra_ | (afaik both should work) | 10:41 |
| ogra_ | err | 10:41 |
| ogra_ | **and* dh_systemd (in debian/rules) | 10:42 |
| ogra_ | new ubuntu-core building | 10:44 |
| bzoltan | ogra_: thanks, that is clear | 10:47 |
| ogra_ | mvo, two things ... steve said we can drop grub from the amd64 rootfs ... i'll do that today ... and i uploaded https://myapps.developer.ubuntu.com/dev/click-apps/5912/ onn the weekend, could you approve it ? | 11:04 |
| mvo | ogra_: grub-- ? cool, we still need grub-editenv for now, I can write it natively if we want to get rid of it fully | 11:05 |
| mvo | ogra_: and linux-generic-bb +++ ! | 11:06 |
| ogra_ | hah, thanks ... the mail was fast :) | 11:06 |
| ogra_ | (store mail) | 11:06 |
| ogra_ | mvo, yeah, i think it would be preferrable if we handle both bootloaders directly from snapd ... but i'll keep grub-common around for now | 11:07 |
| === ant__ is now known as antdillon | ||
| ogra_ | mwhudson, ubuntu-core done in case you still want to test (i imagine its EOD for you) | 11:09 |
| === bloodearnest_ is now known as bloodearnest | ||
| mvo | ogra_: yeah, SMOP | 11:11 |
| ogra_ | yep | 11:11 |
| TinoGuest | pitti: do you know / have an idea when / why would 'systemd' take over a serial console on the device, so that device, after it boots , doesn't have console (uart gpio's) to log in? virtual consoles show up... any pointers to getty@tty*.service ? I was looking at http://0pointer.de/blog/projects/serial-console.html - but maybe I am missing something else ? | 11:13 |
| zyga | mwhudson: not yet, I'll get it sorted out soon | 11:16 |
| Pharma | Hello everybody | 11:19 |
| Pharma | I have a question about snappy as a user, hope i will get answer here. | 11:20 |
| Pharma | I'm using ubuntu 16.04 and working as a freelancer on upwork.com and i need to track my working hours. About 6 months ago, their app for tracking working hours failed to work on Linux | 11:21 |
| Pharma | The problem is - they need this "libnss3_3.19.2.1-0ubuntu0.14.04.2_amd64.deb" so their app can send info about working hours to their server | 11:22 |
| Pharma | So the question is, can close-sourced programs be packed in snappy too? If yes, can somebody ask/help upwork with snappy for linux users this will be very usefull. thank you guys for your work. | 11:23 |
| ogra_ | indeed you can package closed source apps ... snap doesnt care whats inside | 11:25 |
| Pharma | Cool, so can somebody with @canonical.com e-mail contact upwork team? | 11:25 |
| Pharma | if snappy supports all linux distros they would love to switch i guess | 11:26 |
| ogra_ | do they use some bug tracking system ? you could file an issuue there and ask them to offer a snap ... we'll happily help here if they drop by or ask on the mailing list | 11:26 |
| Pharma | But who i'm to tell them about snappy, they will ignore my mail.. | 11:26 |
| Pharma | i will check this, if yes i will provide link here so ppl can upvote issue. | 11:27 |
| ogra_ | k | 11:27 |
| Pharma | There is only community forum, users need to have account to write there. | 11:29 |
| Pharma | If here are people from canonical, please contact upwork linux team >https://www.upwork.com/about/contact/ drop them a message from @canonical.com domain about snappy package for their app, and how this will help them fix their problems with their app for linux users partners@upwork.com | 11:34 |
| zyga | Pharma: closed source software can be packed in a snap, just as it can be packed in debs | 11:35 |
| Pharma | zyga, thanks, hope somebody from canonical will notice my message and will do something. | 11:36 |
| mup | PR snapd#1890 opened: tests: add spread test for snap create-key/snap sign <Created by mvo5> <https://github.com/snapcore/snapd/pull/1890> | 11:38 |
| mup | PR snapd#1891 opened: doscs: add create-user documentation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1891> | 11:39 |
| pitti | TinoGuest: this is usually controlled with the console= kernel cmdline argument; any consoles specified there will also get a getty and boot messages | 11:41 |
| TinoGuest | pitti: is this happening "automatically"? getting getty. and enabling console ? | 11:42 |
| TinoGuest | kernel cmd line is ok. i can boot non systemd rootfs, and keep using console on the device | 11:43 |
| ogra_ | pitti, seemingly systemd always creates tty1 regardless if we have console= pointing to serial (which is the default on the arm images ... x86 has two console= options | 11:43 |
| TinoGuest | same kernel , same initramfs, cmd line | 11:43 |
| ogra_ | ) | 11:43 |
| pitti | TinoGuest: well, what is the actual problem -- you don't get a console on ttyS1, or an unwanted one on tty1, ..? | 11:44 |
| * ogra_ understood the prob to be the latter | 11:44 | |
| ogra_ | (but i might misunderstand) | 11:44 |
| TinoGuest | pitti: issue is that console stops at some point of systemd initialisation | 11:44 |
| ogra_ | TinoGuest, which one | 11:45 |
| TinoGuest | its actual, serial console on the device. not a virtual console | 11:45 |
| ogra_ | on what arch is that ? | 11:45 |
| ogra_ | on x86 ones this is expected ... | 11:45 |
| pitti | ogra_: right, we statically enable getty on tty1 | 11:45 |
| TinoGuest | btw, virtual console is up.... | 11:45 |
| ogra_ | since we use two console= args there | 11:45 |
| pitti | ogra_: so provide a default if console= is not given, or for containers etc. | 11:45 |
| TinoGuest | arch=armhf | 11:45 |
| ogra_ | so kernel adn bootloader messages go to the first defined console ... subsequent boot messages (userspace) go to the second defined console= | 11:46 |
| TinoGuest | that doc url talks about serial-getty and just getty | 11:46 |
| ogra_ | on armhf we dont really do that | 11:46 |
| TinoGuest | ogra_: "we" means Ubuntu Core or Server or Classic? | 11:48 |
| ogra_ | i.e. the raspeberry pi images only have "console=ttyS0,115200" on their cmdline ... so you wont see boot messages on the screen, but a tty will start there as pitti said above | 11:48 |
| ogra_ | i'm talking only about ubuntu core images here | 11:48 |
| ogra_ | no idea what server or classic do | 11:48 |
| TinoGuest | ogra_: maybe changing kernel cmd line would help | 11:48 |
| ogra_ | no it wont, as pitti said above, there is a static default for tty1 | 11:49 |
| TinoGuest | ogra_: ttyS0 or tty1 - same serial console ? what is ttyHSL0 ? | 11:50 |
| ogra_ | a device name :) | 11:50 |
| ogra_ | the tty name really depends on your hardware | 11:50 |
| === hikiko is now known as hikiko|ln | ||
| ogra_ | i.e. ... dragoboard (arm64) images use console=ttyMSM0,115200n8 ... rppi2/3 images use console=ttyS0,115200 ... | 11:51 |
| ogra_ | whatever your HW normally uses for serial needs to be defined there | 11:52 |
| TinoGuest | ogra_: ok.... i got the impression that systemd somehow supressed serial console and kept virtual console (on the monitor attached) | 11:52 |
| ogra_ | if you defined the right values for the console= option you should have both | 11:52 |
| TinoGuest | ogra_: console= has only one option... this somehow turned into virtual... | 11:53 |
| ogra_ | well, whoever ctreated your gadget snap needs to set the right option there ... based on the actual hardware used | 11:54 |
| pitti | you can specify console= multiple times if you want multiple consoles, the boot output will be multiplexed then | 11:54 |
| TinoGuest | so the difference in "serial-getty@...." and "getty@..." is not relevant for this? | 11:54 |
| pitti | not really; the latter gets auto-activated by logind when you Ctrl+Alt+Fn (VT switching), serial console don't | 11:55 |
| pitti | that's the main difference AFAIK | 11:55 |
| TinoGuest | ogra_: thats why i asked u if u referring to ubuntu core only :-) | 11:55 |
| ogra_ | pitti, nope, it wont be multiplexed ... | 11:55 |
| ogra_ | it will always only go to one | 11:55 |
| ogra_ | if you define two the first is kernel+bootloader, the second is usersapce messages | 11:55 |
| popey | what's the equivalent to "snappy enable-classic" now? | 11:55 |
| ogra_ | popey, sudo snap install classic --devmode --edge | 11:56 |
| ogra_ | popey, sudo classic | 11:56 |
| pitti | ogra_: it does get multiplexed | 11:56 |
| ogra_ | pitti, thats news to me and alll my installs here disagree :) | 11:56 |
| pitti | at least the initial grub, kernel messages etc, until userspace kicks in | 11:57 |
| ogra_ | oh, right | 11:57 |
| ogra_ | initial bootloader stuff might ... | 11:57 |
| popey | sweet, thanks ogra_ | 11:57 |
| ogra_ | kernel messages then go to the first console= though | 11:57 |
| ogra_ | and userspace (initd, systemd boot log etc) go to the second | 11:57 |
| ogra_ | *initrd | 11:57 |
| TinoGuest | pitti: so when userspace kicks in, u still get serial console msgs, and virtual terminal? | 11:58 |
| ogra_ | on that level there is no multiplexing | 11:58 |
| ogra_ | TinoGuest, yes, because tty1 is statically hardcoded | 11:58 |
| ogra_ | so you get a login prompt on both | 11:58 |
| TinoGuest | yes! thats what i want.... hm somehow i lost it.... ok i will look more into rootfs .... | 11:59 |
| pitti | I see the "Starting..." messages on both, too | 12:01 |
| pitti | that is, in installs without "splash" -- plymouth is of course a wholly different story | 12:01 |
| ogra_ | on arm HW ? | 12:02 |
| ogra_ | i wonder if there is an arch specific difference here | 12:02 |
| pitti | no, x86 | 12:02 |
| ogra_ | aha | 12:02 |
| ahayzen_ | Hi, I've managed to get my code snapped by Launchpad, however when it tries to upload to the store it fails with "Click and Snap packages cannot be mixed." | 12:06 |
| ahayzen_ | Now, I already have a click in the store with the old style package name "com.ubuntu.developer.andrew-hayzen.volleyball2d" but the snap is configured to the package name "volleyball2d". | 12:06 |
| ahayzen_ | Is the problem that it thinks these two have the same name? Or is this a different issue? | 12:07 |
| * ogra_ guesses thats a store question | 12:09 | |
| bzoltan | ogra_: will snapcraft pull the recommended/suggested packages too for the packages listed in the stage-packages? | 12:12 |
| ogra_ | bzoltan, nope, it uses --no-install-recommends ... you need to list them | 12:13 |
| ogra_ | also note it doesnt run any maintainer scripts (so alternatives dont get set etc) | 12:14 |
| bzoltan | ogra_: I will not do it :) I like it exactly this way .. skinny and light | 12:14 |
| mup | PR snapd#1892 opened: snap,store: capture newest digest from the store, make it DownloadInfo only <Created by pedronis> <https://github.com/snapcore/snapd/pull/1892> | 12:20 |
| pitti | bzoltan: note the definition of recommends -- "you can remove a recommended package if you know what you are doing" -- i. e. not a good default | 12:27 |
| bzoltan | pitti: Of course | 12:36 |
| bzoltan | pitti: I am working on to make our IDE package ligher and many of its dependencies pull lots of packages as recommendations what we do not really need... but of course heavy testing follows each removal :) | 12:37 |
| ogra_ | mvo, hrm, dropping grub from livecd-rootfs has no effect ... | 12:47 |
| * ogra_ wonders where it comes from now | 12:48 | |
| === hikiko|ln is now known as hikiko | ||
| ogra_ | oh man | 13:03 |
| ogra_ | cjwatson, do you have any hint for me how i can remove a package from a task in an already released release ? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/system-image defines grub binaries which means they get pulled in regardless | 13:04 |
| cjwatson | ogra_: You can't unfortunately - this is why point releases tend to use metapackages | 13:06 |
| === chihchun is now known as chihchun_afk | ||
| cjwatson | It's an awkward deficiency that stems from the way tasks are implemented as fields in the Packages file, combined with the fact that we never republish the release suite after release | 13:07 |
| ogra_ | yeah, i remembered that, i just had hopes there is some secret trick | 13:07 |
| cjwatson | I'm afraid metapackages are the best secret trick I have | 13:08 |
| ogra_ | well, except that we dont have them at all for core | 13:09 |
| ogra_ | that will be quite a set of changed to livecd-rootfs too | 13:09 |
| ogra_ | *changes | 13:09 |
| ogra_ | i wonder if i could push a grub package with ripped out task header to the PPA instead ... but that would forever bind us to the PPA | 13:10 |
| mup | PR snapcraft#793 opened: Unify python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/793> | 13:10 |
| === chihchun_afk is now known as chihchun | ||
| arges | Hi. can somebody triage bug 1621525? I'm wondering how to fix this | 13:17 |
| mup | Bug #1621525: classic environment variables for daemon snaps <Snappy:New> <https://launchpad.net/bugs/1621525> | 13:17 |
| ogra_ | arges, i think thats a duplicate of bug 1584811 | 13:19 |
| mup | Bug #1584811: Support a snapcraft environment keyword <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1584811> | 13:19 |
| arges | ogra_: well i won't know them when I type snapcraft. | 13:20 |
| arges | thing HTTP_PROXY, which may or may not exist | 13:20 |
| arges | think | 13:20 |
| popey | sergiusens: have you seen an issue with snapcraft (or the part) where, during make (make plugin) it copies things to stage but under stage followed by my home directory name.. e.g. i end up with /home/alan/Development/Snappy/foo/stage/home/alan/Development/Snappy/foo/parts/bar/build/... ? | 13:20 |
| popey | sergiusens: I don't understand what's doing that, looks like something is using `pwd` | 13:21 |
| popey | sergiusens: build stage has the dir correctly, seems to fail going build -> stage | 13:22 |
| cjwatson | ogra_: It's indeed not quite trivial but I think it's probably unfortunately what you have to do | 13:29 |
| ogra_ | yeah ... *sniff* | 13:29 |
| ogra_ | so silly that we picked a task at all for 49 packages (of which i'll drop 6 now) | 13:30 |
| ogra_ | cjwatson, oh, i just see there is grub-xen-bin in the list, i think i added it on your request ... is that still needed inside the rootfs ? | 13:31 |
| === SamYaple_ is now known as SamYaple | ||
| ogra_ | (technically all bootloaders moved to the gadget snap now ... ) | 13:32 |
| cjwatson | ogra_: I just wanted it to be available at all; I don't currently understand gadget snaps, so if that's a more appropriate place then fine | 13:34 |
| ogra_ | well, depends how you use it ... if you actually boot an img file the gadget is what you use ... if you'd do something like "kvm --kernel ... --initrd ... --hda ..." that wouldnt use the gadget | 13:39 |
| * ogra_ has no clue about xen :) | 13:39 | |
| cjwatson | ogra_: You normally have a virtualised disk and boot that. | 13:45 |
| ogra_ | ok, then i guess you have a gadget in use | 13:45 |
| cjwatson | ogra_: Except that Xen needs to get at the boot loader somehow; there's a protocol for figuring out the right path inside the guest | 13:46 |
| ogra_ | and that protocol support is provided by the grub-xen-bin package ? | 13:47 |
| cjwatson | ogra_: It sounds closer to a gadget snap, provided that that can cause files to exist under /boot/xen/ | 13:49 |
| ogra_ | oh, yeah ... | 13:49 |
| cjwatson | (in the same way that grub-install does when told to install for a Xen target) | 13:49 |
| ogra_ | though we dont have that mountoint supported atm ... | 13:49 |
| ogra_ | mvo, ^^^ | 13:49 |
| cjwatson | The protocol in question is documented upstream as https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/x86-xenpv-bootloader.markdown;h=ec8854e6589bcc67e7043410a7157bb0bf481347;hb=HEAD | 13:50 |
| cjwatson | (There are older methods as well - I'm ignoring those since they typically involve more manual work) | 13:51 |
| ogra_ | oh what a pain ... | 14:17 |
| mup | PR snapd#1885 closed: tests: add upower-observe spread test <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1885> | 14:18 |
| diddledan | o/ | 14:19 |
| sergiusens | popey what project? or is it one of our demos? Can I see snapcraft.yaml for it? | 14:19 |
| diddledan | snapcraft cleanbuild just failed to access http://start.ubuntu.com/connectivity-check.html with "http.client.RemoteDisconnected: Remote end closed connection without response" | 14:20 |
| popey | sergiusens: trying to repeat it | 14:20 |
| diddledan | I'm wondering if it could be network conflict with docker | 14:20 |
| popey | sergiusens: okay, reproduced it. http://paste.ubuntu.com/23169430/ - it's the ptex part which gets built incorrectly | 14:22 |
| diddledan | my output with additional ifconfig and brctl show as extra info: http://paste.ubuntu.com/23169433/ | 14:23 |
| sergiusens | akash try snapcraft 2.17 (if you can from the master repo). It is in the process of being released. | 14:23 |
| akash | sergiusens: thanks can you point me at where/how to get it for ubuntu 16.04, ill give it a shot | 14:24 |
| sergiusens | akash f you are on 16.04; eiter wait for it to be released and it will show up as an update or git clone https://github.com/snapcore/snapcraft.git and look at the .md files in there | 14:29 |
| zyga | tyhicks: asdasdaasdasda | 14:34 |
| tyhicks | ? | 14:34 |
| mup | PR snapd#1892 closed: snap,store: capture newest digest from the store, make it DownloadInfo only <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1892> | 14:34 |
| zyga | tyhicks: sorry :) | 14:34 |
| zyga | keyboard stuck | 14:34 |
| tyhicks | heh :) | 14:34 |
| zyga | tyhicks: would you mind lookign at https://github.com/snapcore/snap-confine/pull/135 | 14:35 |
| mup | PR snap-confine#135: Add snap-discard-ns <Created by zyga> <https://github.com/snapcore/snap-confine/pull/135> | 14:35 |
| zyga | it's pretty short | 14:35 |
| zyga | tyhicks: and it will unblock another pull request that actually enables this feature | 14:36 |
| zyga | tyhicks: note, unlike snap-confine, snap-discard-ns is not setuid root | 14:36 |
| tyhicks | zyga: looking | 14:37 |
| mup | PR snapd#1893 opened: Remove symlinks for systemd units on apt-get purge <Created by stolowski> <https://github.com/snapcore/snapd/pull/1893> | 14:40 |
| bzoltan | ogra_: is there a way to create multi arch snaps? | 14:52 |
| ogra_ | bzoltan, you dont really want that ... just create one snap per arch with the same name and upload them | 14:52 |
| bzoltan | ogra_: Okey, thanks | 14:53 |
| ogra_ | else you end up with a gigantic thing that shiops cruft you will never use | 14:53 |
| * bzoltan likes poor i386 users | 14:53 | |
| ogra_ | bzoltan, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ... | 14:53 |
| ogra_ | take a look at how we do that for ubuntu-core | 14:53 |
| bzoltan | ogra_: thanks, that is useful! | 14:54 |
| zyga | tyhicks: thanks for the review, currently only snap-confine creates /run/snapd/ | 15:00 |
| tyhicks | zyga: ah, sc_initialize_ns_groups() creates it, doesn't it? | 15:01 |
| zyga | tyhicks: correct | 15:01 |
| tyhicks | zyga: nice - we're all good then | 15:02 |
| tyhicks | zyga: I'll follow up in the PR | 15:02 |
| zyga | tyhicks: thanks :) | 15:02 |
| akash | sergiusens: thank you very much for the pointer that worked!! At least the app seems to have fired up in devmode, ill see if it functions is strict as well. In devmode it fires up on port 8123 just fine. | 15:03 |
| mup | PR snapd#1894 opened: README.md: tweaks to the spread+qemu instructions <Created by chipaca> <https://github.com/snapcore/snapd/pull/1894> | 15:04 |
| diddledan | I have no idea what I did wrong, but I'm getting "error: cannot find signatures with metadata for snap" when installing a snap I've just created | 15:19 |
| mup | PR snapd#1894 closed: README.md: tweaks to the spread+qemu instructions <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1894> | 15:20 |
| sergiusens | popey the readme for ptex mentions this: make prefix=$PWD/install | 15:27 |
| sergiusens | in make-parameters you might want to add prefix=$SNAPCRAFT_PART_INSTALL | 15:27 |
| diddledan | oh we're not allowed to install things we make without telling it we really really really want to install a thing we made (--force-dangerous)... o_O | 15:27 |
| * diddledan pinkyswears that his snap won't be naughty | 15:28 | |
| diddledan | right. so corebird needs some new schemas installed into gsettings or it fails to start. how do I go about telling my snap about these settings? | 15:30 |
| diddledan | ref: (corebird:26868): GLib-GIO-ERROR **: Settings schema 'org.baedert.corebird' is not installed | 15:30 |
| seb128 | diddledan, where is that schemas getting installed in your snap? | 15:32 |
| diddledan | seb128: my point is I don't know how to install the settings, hence why they're not installed | 15:32 |
| popey | sergiusens: will try, thanks | 15:33 |
| seb128 | diddledan, usually the upstream make install does that for you | 15:33 |
| diddledan | seb128: the make install might have put the file at /snap/corebird/current/share/glib-2.0/schemas/org.baedert.corebird.gschema.xml ?? | 15:37 |
| diddledan | otherwise it's not installed at all | 15:38 |
| diddledan | I think this is the file that should be somewhere: https://github.com/baedert/corebird/blob/master/corebird.gresource.xml | 15:38 |
| zyga | tyhicks: this enables namespace sharing https://github.com/snapcore/snap-confine/pull/134/files | 15:39 |
| mup | PR snap-confine#134: Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/134> | 15:39 |
| zyga | tyhicks: there's one thing that jdstrand suggested that I change (use change profile instead of change hat) | 15:39 |
| zyga | tyhicks: I'm worried about interactions between device cgroup and the ns sharing feature though | 15:39 |
| zyga | tyhicks, jdstrand: ^^ your review would be appreciated | 15:40 |
| mhall119 | zyga: what is the system-wide writable directory for a snap? | 15:40 |
| popey | sergiusens: :( still does it even with that set | 15:40 |
| zyga | mhall119: /var/snap/$SNAP_NAME/{common,$SNAP_REVISION} AFAIR | 15:40 |
| zyga | tyhicks: and for you specifically; I could really use some insight into https://github.com/snapcore/snap-confine/pull/133 | 15:41 |
| mup | PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec <Blocked> <Created by zyga> <https://github.com/snapcore/snap-confine/pull/133> | 15:41 |
| mhall119 | zyga: that's $SNAP_DATA right? | 15:41 |
| zyga | mhall119: that's correct | 15:41 |
| seb128 | diddledan, that seems about right, you might hit bug #1590831 if you use prefix=/usr and the desktop launcher it should work | 15:42 |
| mup | Bug #1590831: having prefix='' by default is non standard and confusing <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590831> | 15:42 |
| mhall119 | zyga: I'm getting some permission errors: | 15:43 |
| mhall119 | mhall@mhall-thinkpad:~/projects/Ubuntu/snaps/tomcat/snap$ snap run tomcat | 15:43 |
| mhall119 | cp: cannot create regular file '/var/snap/tomcat/x1/conf/jaspic-providers.xsd': Permission denied | 15:43 |
| mhall119 | cp: cannot create regular file '/var/snap/tomcat/x1/conf/catalina.policy': Permission denied | 15:43 |
| mhall119 | trying to copy files from $SNAP to $SNAP_DATA | 15:43 |
| mhall119 | what's odd is that it creates the 'conf' directory just fine, but as user 'root' and then fails to copy files into it | 15:43 |
| zyga | mhall119: that directory is only designed for stuff that runs as root | 15:44 |
| zyga | mhall119: it's not writable by all users | 15:44 |
| diddledan | seb128: yeah that bug report does look like it might be relevant, thanks | 15:44 |
| zyga | mhall119: to "services" | 15:44 |
| mhall119 | zyga: should webservices like Tomcat use that or use $SNAP_USER_DATA? | 15:44 |
| seb128 | diddledan, yw, comment on it maybe more people hitting the problem is going to convince the snapcraft team that it's an issue | 15:45 |
| mhall119 | it will eventually be running as a daemon | 15:45 |
| mhall119 | also, why does it allow creating a directory but not files? | 15:45 |
| zyga | mhall119: if it's a service it runs as root and it cannot use $SNAP_USER_DATA, it must use $SNAP_DATA | 15:46 |
| zyga | stgraber: FYI: https://github.com/snapcore/snap-confine/pull/134 | 15:46 |
| mup | PR snap-confine#134: Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/134> | 15:46 |
| zyga | stgraber: this enables namespace sharing | 15:46 |
| zyga | stgraber: I hope it lands today | 15:46 |
| sergiusens | popey as soon as I defeat my headache in a mental battle with my nemesis (myself) I will help you | 15:47 |
| tyhicks | zyga: I'll look at the 'unsafe' change breaking tests and jdstrand will look at the PR where the ns sharing functions are put to use | 15:48 |
| zyga | thank you, both of you! | 15:48 |
| zyga | 1.0.41 is super close to release, those are the last two things | 15:48 |
| popey | sergiusens: heh :) No worries. | 15:51 |
| diddledan | seb128: that looks to have been that particular issue. now I'm onto dbus :-) | 15:57 |
| seb128 | great | 15:58 |
| seb128 | what dbus issue do you have? | 15:58 |
| diddledan | GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.99" is not allowed to own the service "org.baedert.corebird" due to AppArmor policy | 15:58 |
| seb128 | that's currently being discussed on the list/being worked on | 16:00 |
| popey | sergiusens: when you're around http://paste.ubuntu.com/23169756/ http://paste.ubuntu.com/23169757/ | 16:00 |
| seb128 | you need to use devmode as a workaround meanwhile | 16:00 |
| diddledan | aha | 16:00 |
| diddledan | is it this thread?: Accessing dbus (KDE Application) (https://lists.ubuntu.com/archives/snapcraft/2016-September/001070.html) | 16:01 |
| sergiusens | popey the Makefile seems like a wrapper for cmake, care to ty cmake instead? | 16:02 |
| popey | sergiusens: yeah, it's a bit messy | 16:02 |
| popey | i *think* i tried that, but will try again | 16:02 |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | popey just tried, it worked fine | 16:04 |
| sergiusens | well, built fine | 16:04 |
| popey | sergiusens: thanks | 16:05 |
| mhall119 | zyga: http://paste.ubuntu.com/23169779/ is the journalctl output after trying to start my daemon snap service | 16:05 |
| mhall119 | any idea why it would be getting a permission denied on accessing it's own files? | 16:06 |
| zyga | mhall119: can you look at apparmor denials please, it looks like the problem is $SNAP/conf | 16:06 |
| * zyga goes to swap GPUs to test without nvidia | 16:07 | |
| seb128 | diddledan, yes | 16:07 |
| kgunn | ok, i feel kinda dumb, i used to login to my ubuntu-core with login ubuntu/pswd ubuntu, i just created an image, and it says that's wrong... | 16:08 |
| kgunn | did something change? | 16:08 |
| seb128 | kgunn, yes, they removed the static user, need to configure it on first boot now | 16:09 |
| kgunn | ta | 16:09 |
| seb128 | kgunn, which means you need a serial access or a screen+keyboard | 16:09 |
| mhall119 | zyga: http://paste.ubuntu.com/23169941/ | 16:13 |
| mhall119 | can I not run the cp command from my snap? | 16:13 |
| zyga | mhall119: looking | 16:14 |
| zyga | mhall119: cp is permitted by the default policy | 16:15 |
| zyga | mhall119: this is a problem: 619:Sep 12 12:12:08 mhall-thinkpad kernel: [1078687.546925] audit: type=1400 audit(1473696728.358:458747): apparmor="DENIED" operation="capable" profile="snap.tomcat.tomcat" pid=18756 comm="run.sh" capability=1 capname="dac_override" | 16:16 |
| mhall119 | zyga: http://paste.ubuntu.com/23169959/ is my snap.yaml http://paste.ubuntu.com/23169799/ is my run.sh | 16:16 |
| zyga | mhall119: as is this 638:Sep 12 12:12:08 mhall-thinkpad kernel: [1078688.048110] audit: type=1400 audit(1473696728.862:458748): apparmor="DENIED" operation="capable" profile="snap.tomcat.tomcat" pid=18769 comm="mkdir" capability=1 capname="dac_override" | 16:16 |
| zyga | mhall119: looks good | 16:17 |
| mhall119 | zyga: note it works when I use $SNAP_USER_DATA but not $SNAP_DATA | 16:17 |
| zyga | mhall119: interesting | 16:18 |
| zyga | mhall119: I think the problem is that snap-confine is not creating $SNAP_DATA, it only creates snap-user-data | 16:18 |
| zyga | er $SNAP_USER_DATA | 16:18 |
| zyga | mhall119: what happens if you manually mkdir -p /var/snap/tomcat/{x1,common} | 16:19 |
| zyga | mhall119: keep using $SNAP_DATA please | 16:19 |
| mhall119 | /var/snap/tomcat/x1/ and /var/snap/tomcat/common/ are both created when I "snap try ./prime" | 16:19 |
| zyga | mhall119: ok | 16:20 |
| zyga | mhall119: do you have any idea why tomcat might want dac_override capability | 16:20 |
| zyga | mhall119: (we're not granting those!) | 16:20 |
| mhall119 | I don't even know what that is | 16:20 |
| zyga | mhall119: and check if you have anything owned by root in $HOME/snap | 16:21 |
| zyga | mhall119: you can ignore file permissions | 16:21 |
| mhall119 | zyga: my user's home? | 16:21 |
| zyga | mhall119: yes | 16:21 |
| mhall119 | one, but it's not tomcat | 16:21 |
| zyga | mhall119: is it /home/$LOGNAME/snap? | 16:21 |
| mhall119 | drwxr-xr-x 3 root root 4.0K Aug 25 16:49 couchbase-beacon | 16:21 |
| zyga | hm | 16:22 |
| mhall119 | $LOGNAME? | 16:22 |
| ogra_ | pitti, so i'm currently switching ubuntu-core from task to metapackage and notice that we still ship systemd-shim in the images ... is that still necessary ? | 16:22 |
| zyga | mhall119: env | 16:22 |
| zyga | mhall119: env | grep LOGNAME | 16:22 |
| mhall119 | ah, yes it is | 16:22 |
| jdstrand | see CAP_DAC_OVERRIDE in 'man 7 capabilities' | 16:22 |
| zyga | mhall119: does it work in devmode? | 16:23 |
| mhall119 | zyga: the cp that is failing is from the run.sh I created, before Tomcat's code is even started | 16:23 |
| jdstrand | you typically see this when a root process is trying to copy files to a user-owned directory that doesn't allow 'other' writes | 16:23 |
| zyga | ah, interesting | 16:23 |
| zyga | mhall119: well, your run.sh should use $SNAP_DATA because it is a service | 16:23 |
| mhall119 | zyga: appears to run with --devmode | 16:23 |
| zyga | mhall119: (in the pastebin above it uses $SNAP_USER_DATA) | 16:24 |
| zyga | mhall119: change that and try again | 16:24 |
| mhall119 | zyga: the current version is http://paste.ubuntu.com/23169984/ which usees ${SNAP_DATA} | 16:24 |
| zyga | mhall119: what happens when you run that version? | 16:24 |
| mhall119 | it runs with --devmode, but doesn't look like it copies the files to $SNAP_DATA | 16:27 |
| zyga | mhall119: can you try without devmode and look at all the denials please | 16:28 |
| mhall119 | zyga: http://paste.ubuntu.com/23170006/ is from syslog without --devmode | 16:29 |
| zyga | I think I know | 16:30 |
| zyga | jdstrand: this probably fails because snap try and the fact that all of the files are owned by the user, not by root | 16:30 |
| zyga | mhall119: can you try to build a real snap, remove the one with try and install the real one without devmode | 16:31 |
| mhall119 | yup, snapping it now | 16:31 |
| zyga | if true this would imply that we need to do some tweaks to try | 16:31 |
| mhall119 | zyga: indeed it works this way, so 'try' is to blame | 16:33 |
| zyga | mhall119: cool, can you please report a bug on snap try and tag it with snapd-interface | 16:34 |
| zyga | mhall119: I don't have a solution in my head but perhaps there are ways to address this | 16:34 |
| mhall119 | zyga: there is still one apparmor denial http://paste.ubuntu.com/23170012/ | 16:34 |
| zyga | jdstrand: we might use a different base template for trymode snaps | 16:34 |
| zyga | mhall119: we don't allow to run /usr/bin/tty | 16:35 |
| zyga | mhall119: please report that as a separate bug | 16:35 |
| mhall119 | ok | 16:35 |
| zyga | mhall119: alternatively bundle tty in your snap | 16:35 |
| jdstrand | mhall119: I'll add /usr/bin/tty | 16:36 |
| jdstrand | I'd really rather not use a different base template if we can at all help it | 16:37 |
| kgunn | just checking, haven't tested, but in latest 16 ubuntu-core, should i still be expected to manually connect autoconnections? | 16:37 |
| jdstrand | that would be confusing for triaging | 16:37 |
| jdstrand | and diagnosing problems | 16:37 |
| jdstrand | snap try should probably copy all the files and chown root:root all of them, just like how snapcraft snap uses -all-root | 16:38 |
| elopio | lool: can we not merge the snapcraft revert yet? In your branch you are building for amd64 only anyway. | 16:41 |
| elopio | if we solve the phantomjs thing, and do the download on pull, we could build in launchpad. | 16:41 |
| lool | elopio: crap I committed that? that's a mistake | 16:41 |
| lool | elopio: I dont want to fight phantomjs for each architecture | 16:41 |
| ogra_ | elopio, FYI, the linux-generic-bbb package is now approved and available in the store in the edge channel | 16:41 |
| elopio | ogra_: \o/ | 16:42 |
| ogra_ | next is gadget :) | 16:42 |
| elopio | I left mine at home, sadly. I will try it on friday. | 16:42 |
| ogra_ | if i ever manage to get done with this switch from task to metapackage in ubuntu-core :/ | 16:42 |
| ogra_ | such a pain ... why did we ever decide to not use metapackages but tasks | 16:42 |
| mup | Bug #1622639 opened: Snap access to /dev/uinput <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1622639> | 16:43 |
| lool | elopio: I've reverted the build.sh arch changes; that was just for local builds | 16:43 |
| lool | elopio: I've pushed a rebased version | 16:44 |
| elopio | lool: please also run go fmt | 16:44 |
| lool | elopio: hmm it's a no-op | 16:45 |
| lool | elopio: ah nevermind | 16:46 |
| elopio | weird, the travis static check is failing. | 16:46 |
| lool | elopio: ok fixed; was just a newline :-( | 16:51 |
| mup | Bug #1622685 opened: snap try fails on user ownership of files in the testing directory <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1622685> | 17:04 |
| mhall119 | woohoo! my tomcat snap is working | 18:18 |
| mhall119 | thanks for all the help zyga | 18:19 |
| kyrofa | mhall119, who's in charge of the snapcraft.io text? | 18:22 |
| kyrofa | And can I log bugs against it? | 18:22 |
| zyga | kyrofa: it's a github project | 18:22 |
| kyrofa | zyga, are bugs handled over there, then? | 18:22 |
| zyga | kyrofa: don't remember which but I'd love to know | 18:22 |
| kyrofa | Yeah okay, back to you mhall119 ;) | 18:23 |
| zyga | mhall119: my pleasure thank you for doing the work :) | 18:23 |
| kyrofa | davidcalle, you might know as well? | 18:23 |
| mhall119 | kyrofa: thibautr_ is I think | 18:26 |
| mhall119 | zyga: is there a way to do one-time setup on install? | 18:27 |
| mhall119 | or a snap | 18:27 |
| mhall119 | s/or/of/ | 18:28 |
| mhall119 | basically I need to copy some files from $SNAP to $SNAP_DATA for tomcat to work, but it only needs to be done once | 18:28 |
| thibautr_ | Zyga bugs you can raise on snapcraft.io itaelf | 18:31 |
| kyrofa | thibautr_, ah, the "report a bug on this site"? | 18:32 |
| thibautr_ | davidcalle can point you to the github repo for the doc otherwise | 18:33 |
| thibautr_ | That's the one | 18:33 |
| thibautr_ | I would if I wasn't on my mobile phone 😁 | 18:33 |
| kyrofa | thibautr_, excellent, thank you! | 18:34 |
| lool | elopio: I pushed a dependencies update | 18:45 |
| zyga | mhall119: not at present | 18:55 |
| lool | elopio: there seems to be another static test error with Init(); I dont have time to look into this tonight | 18:59 |
| lool | elopio: also, coverage is down but that's because I removed a lot of code :-) | 18:59 |
| mhall119 | zyga: ok | 19:00 |
| lool | elopio: keeping in mind the current version doesn't work at all, could we force this in and fix the remaining issues as an update? | 19:00 |
| ogra_ | cprov, hmm, what else beyond grade chnaged in the store recently ... if i try to install ubuntu core from edge (590) i get offered the version from beta (524) ... | 19:00 |
| beowulf | hi, what is the app dev email list address for snappy? | 19:00 |
| ogra_ | there seems to be no way to actually get anything newer than what was released to beta | 19:01 |
| cprov | ogra_: nothing specific, but let me check the publishing history. | 19:01 |
| ogra_ | bug 1621843 seems related | 19:03 |
| mup | Bug #1621843: no way to switch ubuntu-core to --edge on images <Snappy:New> <https://launchpad.net/bugs/1621843> | 19:03 |
| beowulf | can anyone tell me which plug to use for apparmor denials for "trace" http://pastebin.com/4RfBgPkp | 19:03 |
| ogra_ | (i thought it was an image issue ... but i noted that i cant even build any images from edge ... all ubuntu-image gets when setting -c edge is 524) | 19:04 |
| ogra_ | beowulf, snapcraft@lists.snapcraft.io is the ML address | 19:04 |
| beowulf | ogra_: thanks | 19:04 |
| jdstrand | beowulf: trace denial with ps is harmless. seems like you want to use 'system-observe' which will allow ps and silence the denial | 19:05 |
| cprov | ogra_: 590 (amd64) should be published on edge, let me dig a little I have a suspicious (it's not related to new changes, but instead with publishing snaps with huge revisions history) | 19:05 |
| beowulf | jdstrand: thanks | 19:06 |
| ogra_ | cprov, thanks fo checking ! | 19:06 |
| jdstrand | beowulf: seems you also want 'network' | 19:06 |
| jdstrand | based on the resolvconf denial | 19:07 |
| cprov | ogra_: can you please check if amd64 is working now ? | 19:19 |
| ogra_ | trying ... that takes a while though | 19:19 |
| ogra_ | hmm, well, now ubuntu-image exploded ... so i guess something store-side changed :) | 19:21 |
| ogra_ | cprov, sorry, i seem to get something else now but since ubuntu-image as well as ubuntu-device-flash explode now it is hard to tell which version i get ... none of them print it | 19:22 |
| cprov | ogra_: np, amd64 should be ok now, r590. I will debug further .. | 19:23 |
| ogra_ | yeah, sudo snap install ubuntu-core --edge gets me 590 inside an old image now | 19:25 |
| ogra_ | seems to work for amd64 | 19:25 |
| ogra_ | arm64 and armhf still dont though | 19:25 |
| cprov | ogra_: all fixed now. | 19:36 |
| ogra_ | cprov, \o/ | 19:36 |
| ogra_ | i get fresh snaps | 19:36 |
| cprov | ogra_: sorry for the trouble, we will figure out how to prevent this hiccup :-/ | 19:36 |
| ogra_ | cprov, i guess we can close 1621843 then :) | 19:37 |
| cprov | ogra_: no, I will reassign it to sca, it is still a bug | 19:38 |
| ogra_ | ogra@dragonboard:~$ snap list ubuntu-core | 19:38 |
| ogra_ | Name Version Rev Developer Notes | 19:38 |
| ogra_ | ubuntu-core 16.04.1 593 canonical - | 19:38 |
| ogra_ | yay | 19:38 |
| ogra_ | and it seems my hackery didnt break ubuntu-core :) | 19:39 |
| ogra_ | and armhf works too | 19:41 |
| ogra_ | ogra@pi3:~$ snap list ubuntu-core | 19:41 |
| ogra_ | Name Version Rev Developer Notes | 19:41 |
| ogra_ | ubuntu-core 16.04.1 591 canonical - | 19:41 |
| mup | Bug #1621843 changed: no way to switch ubuntu-core to --edge on images <Software Center Agent:Triaged by cprov> <https://launchpad.net/bugs/1621843> | 19:41 |
| mup | PR snapd#1895 opened: store: refactor auth/refresh tests <Created by matiasb> <https://github.com/snapcore/snapd/pull/1895> | 19:41 |
| ogra_ | slangasek, so i dropped grub now ... (and had switch from task to metapackage etc etc ... horrid day, dont ask...) i note that /boot/grub/unicode.pf2 isnt there anymore with dropping of the binaries (along with /boot/grub for which i just uploaded a livecd-rootfs fix ... do you know if thats harmful ? and do we need to ship that fuile in the gadget then ? | 19:43 |
| ogra_ | *and had *to* | 19:43 |
| jdstrand | zyga: hey, does 'retest this please' still work with snapd? | 19:49 |
| pedronis | jdstrand: no, we have only travis now | 19:53 |
| pedronis | that command was for the bot managed stuff | 19:53 |
| jdstrand | I see | 19:53 |
| jdstrand | ok, thanks | 19:53 |
| elopio | lool: I'm grumpy everytime we land something with failing tests. Do we need this out today for some reason? | 19:54 |
| nsg | Hello, started to play with snapcraft a day ago and I just packaged minecraft "just-for-fun" ... what do think, is is a good idea to share it? No software is bundled, it is just a download script. What do think, is a "minecraft-nsg" snap okay? | 19:58 |
| nsg | (bash script that downloads the jar (launcher) and Oracle JDK, on the users computer) | 19:59 |
| kyrofa | nsg, so it's a minecraft installer, not minecraft | 20:00 |
| kyrofa | ? | 20:00 |
| nsg | correct | 20:00 |
| kyrofa | nsg, no downside to sharing, though I'm curious: why not just package minecraft itself? | 20:01 |
| nsg | or, possible a oracle jdk and minecraft installer :) | 20:01 |
| nsg | I do not think we are allowed to distribute the software, or? | 20:01 |
| ogra_ | slangasek, oh, i see where that file comes from (grub-common) ... i added code to livecd-rootfs that copies it in place now ... so ignore the above | 20:01 |
| nsg | I was thinking, consider that oracle likes you to accept the license and that I have worked around that problem to download it with wget ... maybe some type of "do you accept the oracle license dialog" is needed? So the installing user has to agree. | 20:04 |
| kyrofa | nsg, ah, of course | 20:04 |
| kyrofa | nsg, yeah I'm not qualified to answer those questions at all :) | 20:04 |
| kyrofa | Now I see where your original question is coming from | 20:05 |
| kyrofa | In which case my real answer is: no idea :P | 20:05 |
| nsg | hehe | 20:05 |
| === nsg is now known as nsg__ | ||
| === nsg_ is now known as nsg | ||
| elopio | lool: I will land this one: https://github.com/snapcore/snapweb/pull/56 | 20:30 |
| mup | PR snapweb#56: Revert snapcraft <Created by elopio> <https://github.com/snapcore/snapweb/pull/56> | 20:30 |
| elopio | then your diff will be smaller, and I removed one of the tests that were failing for you. | 20:30 |
| jdstrand | zyga: hey, it you're still around, can you discuss the motivation behind https://github.com/snapcore/snapd/pull/1848? | 20:35 |
| mup | PR snapd#1848: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848> | 20:35 |
| jdstrand | zyga: it breaks the ongoing docker PR | 20:36 |
| jdstrand | zyga: see https://github.com/snapcore/snapd/pull/1848#issuecomment-246482819 | 20:36 |
| mup | PR snapd#1848: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848> | 20:36 |
| popey | sergiusens: why can I not do "cleanbuild" _and_ "--no-parallel-build" ? | 20:42 |
| sergiusens | popey that's not supported, probably a bug, but --no-parallel-build is deprecated in favor of a per part switch to disable it | 20:43 |
| popey | oh okay | 20:43 |
| popey | that'll do :) | 20:43 |
| qengho | What's the deal with X fonts from snaps these days? | 20:44 |
| qengho | Including fonts in snap packages seems crazy. | 20:44 |
| qengho | (Not to mention, the MSFT Core Fonts installer package doesn't get to run its postinst downloader, in a staged package.) | 20:45 |
| sergiusens | popey add `disable-parallel: on` to the part that needs parallel disabled | 20:45 |
| popey | ta | 20:45 |
| sergiusens | qengho iirc zyga was working on an interface for that | 20:46 |
| nsg | hum, I'm missing something? ... "sha256sum $SNAP_USER_DATA/my.file" is blocked by apparmor. | 21:05 |
| nsg | ... name="/usr/bin/sha256sum" pid=3910 comm="launch" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 21:05 |
| mwhudson | ogra_: hey, did the wifi stuff work? | 21:10 |
| ogra_ | mwhudson, dunno yet ... the woorld exploded when i trie to remove grub from x86 and found out that we only use tasks ... so i had to port everything to use a metapackage ... still dealing with the fallout here | 21:11 |
| mwhudson | ogra_: no rest for the wicked | 21:12 |
| ogra_ | heh | 21:12 |
| nsg | interesting, md5sum works but sha256sum and sha1sum was blocked by apparmor. | 21:17 |
| jdstrand | nsg: that is just an omission. I've noted it and will get it fixed | 21:18 |
| nsg | ah, thx! | 21:18 |
| jdstrand | I'm seriously surprised that isn't there... | 21:19 |
| nsg | got a little confused there for a while, assumed I did someting wrong :) | 21:19 |
| jdstrand | anyhoo, I'll fix it | 21:19 |
| jdstrand | nsg: in the meantime, you can just include them in your snap | 21:19 |
| nsg | I will use good-old-broken md5 while I wait :) | 21:19 |
| nsg | ah, that's a idea! | 21:19 |
| jdstrand | nsg: I'll make sure it gets committed this week | 21:21 |
| jdstrand | to trunk | 21:21 |
| jdstrand | it'll float into Ubuntu or the distro of your choice some time after that | 21:21 |
| nsg | sounds good, looking forward to that | 21:22 |
| === prince is now known as Guest2309 | ||
| lool | jdstrand: hey I wanted to ask about the kernel_module_control interface; wouldn't that be enough for docker? | 21:40 |
| lool | elopio: your pull request is not enough to get it to start on boot | 21:43 |
| jdstrand | lool: that is an extremely privileged interface. yes, it would work, but we'd want to remove it immediately before GA. note, JamieBennett said in the bug the kernel module backend would be done for GA | 21:44 |
| ogra_ | oh man ! | 21:47 |
| * ogra_ wasted 2/3 of his workday because he didnt notice thet the ubuntu-image he used was the deb version | 21:48 | |
| elopio | lool: I know. But now it will be easier to understand why yours is failing the unit tests | 21:59 |
| ogra_ | cprov, hmm, could you do that magic again ? i'm now stuck at 590 which had a bug despite there being 594 being published | 22:07 |
| cprov | ogra_: sure, one sec | 22:10 |
| cprov | ogra_: fixed | 22:13 |
| * ogra_ hugs cprov | 22:13 | |
| cprov | ogra_: ftr, it's just a matter of scrolling down the revision page and hit 'unpublish' then 'publish'. God, this is embarrassing and has to be fixed asap. | 22:14 |
| ogra_ | cprov, oh, if i know that then thats no issue for me to do that myself ... | 22:15 |
| popey | hm, cleanbuild is barfing with a bizarre error | 22:18 |
| popey | http://paste.ubuntu.com/23171253/ | 22:18 |
| popey | "error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias) | 22:18 |
| popey | found https://github.com/lxc/lxd/issues/2094 from stgraber which indicates the error message *used* to be even more incomprehensible than it is now :) | 22:18 |
| popey | sergiusens: is ^ this a snapcraft bug, not interpreting lxc errors nicely? | 22:19 |
| stgraber | popey: any chance you can have it show you what it passed to "lxc launch"? | 22:19 |
| SamYaple | hey guys. soooo i ran into a pretty funny problem https://github.com/snapcore/snapcraft/pull/793 | 22:19 |
| mup | PR snapcraft#793: Unify python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/793> | 22:19 |
| popey | stgraber: no idea. | 22:20 |
| SamYaple | total coverage has decreased in that commit.... but all the files are 100% converage'd | 22:20 |
| qengho | Ick. I think a system snap broke my pi3. I think it was running pi2 version. Still sad. | 22:20 |
| SamYaple | https://coveralls.io/builds/7852962 | 22:20 |
| SamYaple | look. all the changed files are 100% covered, but te total percentage droped :) | 22:21 |
| popey | stgraber: repeatedly running ps shows me "lxc remote add pro-joey https://images.linuxcontainers.org:8443" | 22:21 |
| qengho | On boot, I got a newfangled green and purple text-based configuration interface, and it doesn't make it past DHCPv4. | 22:22 |
| popey | stgraber: happy to share my IP with you if you can see the other end logs | 22:22 |
| stgraber | popey: well, I could until last week when that was moved to IS infrastructure :) | 22:22 |
| popey | haha | 22:22 |
| popey | bummer | 22:22 |
| ogra_ | qengho, ogt a network cable plugged in ? | 22:24 |
| popey | stgraber: caught it... lxc launch -e chief-lynx:ubuntu/xenial/amd64 snapcraft-firmly-fond-ram | 22:24 |
| ogra_ | qengho, the screen is the new config UI ... now that the ubuntu user is gone ... | 22:24 |
| ogra_ | qengho, flowers go to mwhudson :) | 22:24 |
| popey | stgraber: so it does a remote add then a launch with that name | 22:24 |
| stgraber | popey: hmm, seems to be working fine here though | 22:26 |
| stgraber | popey: so yeah, it seems to be adding a new remote with a random name using images.linuxcontainers.org:8443 and then fetch the ubuntu/xenial/amd64 image from it, but AFAICT this all works fine and that's a valid image name | 22:27 |
| stgraber | popey: does it reliably fail for you? | 22:27 |
| popey | yes | 22:27 |
| popey | was working fine an hour or so ago | 22:27 |
| stgraber | popey: oh, fun, looks like the uk server is busted somehow | 22:28 |
| stgraber | stgraber@dakara:~$ lxc image info uk-images:ubuntu/xenial/amd64 | 22:29 |
| stgraber | error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias) | 22:29 |
| stgraber | stgraber@dakara:~$ lxc image info us-images:ubuntu/xenial/amd64 | 22:29 |
| stgraber | Fingerprint: f18647f5280c3ca50ddec7a112bb4794b6b53f73d05c8c0a63316b77689a4249 | 22:29 |
| popey | \o/ | 22:29 |
| ogra_ | must be because IS wears gloves all day ... they dont leave fingerprints | 22:29 |
| ogra_ | :P | 22:29 |
| popey | stgraber: I do need to file an RT or something? | 22:30 |
| stgraber | popey: ok, so I'm not 100% sure whether it's an actual problem on the IS side or if we just got very unlucky and they somehow rsynced right at the time where the aliases weren't on the disk on my end | 22:30 |
| qengho | ogra_: I did have a cabling problem. My son unplugged the hub. | 22:30 |
| ogra_ | hah | 22:30 |
| qengho | All better now. | 22:30 |
| popey | still reliably failing here | 22:31 |
| * qengho hangs head in shame. | 22:31 | |
| stgraber | popey: so I'm waiting for the next rsync from the UK frontend, then we can re-test, if it's still busted, it'll be an RT, if not, it'll be a bug on my end to reduce the update window even more | 22:31 |
| popey | ok | 22:31 |
| stgraber | popey: yeah, they sync once an hour, let me figure out when exactly | 22:31 |
| qengho | That automatic user generation and ssh keying is BLOWING MY MIND. | 22:32 |
| stgraber | popey: yup, logs on my end does show a lot of rsync errors from that UK server, next sync in 19 minutes, that will hopefully fix things | 22:32 |
| popey | ok | 22:33 |
| popey | thanks stgraber | 22:33 |
| popey | thanks stgraber | 22:35 |
| popey | oops | 22:35 |
| ogra_ | i wonder if there is something in general with the DC | 22:35 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10743027 ... | 22:36 |
| ogra_ | "Syncing the system clock with the buildd NTP service..." | 22:36 |
| ogra_ | since 12 min | 22:36 |
| cjwatson | Other builders have proceeded since then. | 22:37 |
| ogra_ | ah, it moves now | 22:38 |
| stgraber | popey: try now? | 22:56 |
| popey | stgraber: that's better :) | 22:59 |
| popey | thanks | 22:59 |
| stgraber | cool | 22:59 |
| stgraber | will have to see how to further shrink the race window, but it's below 1s already... best would be for the mirrors to be push mirrors instead of them pulling from me | 22:59 |
| popey | I'll leave that with you then :) | 23:02 |
| mup | Bug #1622782 opened: 'snap install' return code unhelpful <canonical-is> <Snappy:New> <https://launchpad.net/bugs/1622782> | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!