| mup | PR snapcraft#968 closed: sources: refactor subversion source into module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/968> | 01:05 |
|---|---|---|
| mup | PR snapcraft#977 opened: Prefer in-snap libraries to system libraries <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/977> | 01:14 |
| mup | PR snapcraft#978 opened: Updated cmake uplugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/978> | 01:32 |
| mup | PR snapcraft#979 opened: Updated waf plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/979> | 01:32 |
| mup | Bug #1650091 opened: console-conf and getty hang if password is not set and press many enters <Snappy:New> <https://launchpad.net/bugs/1650091> | 03:09 |
| mup | Bug #1650096 opened: 'snap list' does not show devmode property after disable and re-enable a snap <Snappy:New> <https://launchpad.net/bugs/1650096> | 03:36 |
| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest52303 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2480 closed: many: prepare landing on trusty <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2480> | 07:24 |
| mup | PR snapd#2474 closed: Revert "interfaces: add new boot-config interface" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2474> | 07:37 |
| === jamespag` is now known as jamespage | ||
| dholbach | hey hey | 08:04 |
| mup | PR snapd#2488 opened: interaces: add new boot-config interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2488> | 08:07 |
| stub | Can I hand back a snap store name I was granted? Someone else is handling the snap. | 08:35 |
| stub | Or maybe I can just ignore it, since it will be obvious since I've pushed nothing to that namespace | 08:35 |
| mup | Issue snapd#2489 opened: Can't run binary installed via a snap package <Created by mlcdf> <https://github.com/snapcore/snapd/issue/2489> | 08:36 |
| kalikiana_ | mup: Why did you announce that bug? It's a dead link... | 08:39 |
| mup | kalikiana_: In-com-pre-hen-si-ble-ness. | 08:39 |
| kalikiana_ | mup: Bug link is broken | 08:39 |
| mup | kalikiana_: Roses are red, violets are blue, and I don't understand what you just said. | 08:39 |
| kalikiana_ | Pffffft | 08:39 |
| mup | Bug #1650187 opened: Can't run any snap application on Mint 18 <Snappy:New> <https://launchpad.net/bugs/1650187> | 09:17 |
| mup | Issue snapd#2489 closed: Can't run any snap application <Created by mlcdf> <Closed by mlcdf> <https://github.com/snapcore/snapd/issue/2489> | 09:19 |
| mup | PR snapd#2485 closed: overlord: apply auto-aliases information from the snap-declaration on install or refresh <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2485> | 09:27 |
| stub | Looks like charms using the Snap layer need to be rebuilt for Snappy 2.17, due to the backwards incompatible change of 'ubuntu-core:slotname' to just ':slotname' | 09:38 |
| stub | What time frame are we looking at for backports to trusty? | 09:39 |
| kalikiana_ | stub: Shouldn't both be valid? Or is it documented to be breaking? | 09:40 |
| stub | I don't know if it is documented. ubuntu-core:foo is no longer valid. I don't know when :foo started being valid. | 09:41 |
| kalikiana_ | The test cases in snapd still use ubuntu-core: | 09:41 |
| stub | Huh. That isn't what I'm seeing here. | 09:42 |
| stub | root@ip-172-31-3-170:/var/log/juju# snap connect rocketchat-server:network ubuntu-core:network | 09:42 |
| stub | error: cannot perform the following tasks: | 09:42 |
| stub | - Connect rocketchat-server:network to ubuntu-core:network (snap "ubuntu-core" has no slot named "network") | 09:42 |
| stub | root@ip-172-31-3-170:/var/log/juju# snap connect rocketchat-server:network :network | 09:42 |
| stub | (the last works) Or is there a typo in there I can't see? | 09:43 |
| seb128 | hey there | 09:43 |
| seb128 | does anyone know if remote parts can point to a branch | 09:44 |
| seb128 | git repo one | 09:44 |
| kalikiana_ | stub: Normally network autoconnects... are you sure you need to do that at all? | 09:44 |
| stub | seb128: yes, I think you specify the branch name in a separate yaml field | 09:44 |
| stub | kalikiana_: This is just my test case. I know it is not actually needed. | 09:45 |
| stub | (I need a smaller test snap in my test charm) | 09:46 |
| seb128 | stub, like "origin-branch: something"? | 09:46 |
| seb128 | stub, on https://wiki.ubuntu.com/snapcraft/parts | 09:46 |
| stub | seb128: yes, but I don't recall exactly what it is or where it is documented | 09:48 |
| seb128 | stub, k, thanks anyway, I'm going to try to figure it out | 09:49 |
| stub | seb128: snapcraft/internal/sources.py | 09:50 |
| stub | source-type: git | 09:50 |
| stub | source-branch: <name> | 09:50 |
| kalikiana_ | stub: For me, using another snap as an example, both of these work: "snap connect arangodb3:network ubuntu-core:network" and "snap connect arangodb3:network :network" | 09:50 |
| stub | kalikiana_: Can you confirm you have 2.17 ? | 09:50 |
| stub | Maybe it is fixed in 2.18 | 09:51 |
| seb128 | stub, that's what is used in snapcraft.yaml but doesn't match the syntax used on https://wiki.ubuntu.com/snapcraft/parts which uses e.g "origin" or "origin-type" | 09:51 |
| kalikiana_ | stub: I just updated to the latest master and it still works fine | 09:55 |
| stub | kalikiana_: ok, I'll assume user error or fixed after 2.17 for now. There are not enough charms using the layer yet to be a major problem. | 09:56 |
| kalikiana_ | stub: What if you used core: instead of ubuntu-core:? | 10:04 |
| kalikiana_ | As the snap was renamed at one point, that could explain the error | 10:05 |
| kalikiana_ | If that's the case it might make sense to explicitly handle that case in the code - currently it doesn't | 10:06 |
| mup | PR snapd#2490 opened: many: implement "snap un/alias --auto" using snapstate.ResetAliases <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2490> | 10:16 |
| mup | PR snapd#2410 closed: store: retry resumed downloads on sha3 error <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2410> | 10:19 |
| mup | PR snapd#2483 closed: store: use mocked retry strategy to make store tests faster <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2483> | 10:29 |
| stub | kalikiana_: Oh, you are correct. core:network works | 10:35 |
| mup | Bug #1650207 opened: original lsb-release file should be preserved for classic mode <Snappy:New> <https://launchpad.net/bugs/1650207> | 10:36 |
| stub | kalikiana_: At least under 2.17. core: fails under 2.16 :) | 10:37 |
| kalikiana_ | stub: Yeah. As I said, the snap was renamed. You can see it in "snap list" | 10:38 |
| kalikiana_ | If you don't use a name, snap connect will pick one | 10:38 |
| kalikiana_ | So if this affects several existing setups, it may make sense to alias ubuntu-core to core | 10:39 |
| mup | PR snapd#2486 closed: tests: fix tests on 17.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2486> | 10:40 |
| kalikiana_ | Or, if updating all existing cases is good enough, use :foo everywhere and it'll just work | 10:40 |
| stub | I could detect the snappy version and rewrite ubuntu-core to core as appropriate (or vice versa) | 10:40 |
| kalikiana_ | stub: It's literally about which snap is installed, the version of the tooling is irrelevant | 10:41 |
| stub | :foo doesn't work under 2.16 | 10:41 |
| stub | I would need to detect the version, using ubuntu-core:foo under 2.16 or earlier or :foo under 2.17 or later. Or just wait for 2.17 to get backported to trusty. | 10:42 |
| kalikiana_ | Hmm I can't find it in the changelog unfortunately | 10:43 |
| stub | I'm going to ignore it for now. I don't think it affects anything live, and a minor glitch to stuff in development (which is targetted at Xenial, so 2.17), and the only thing I'm aware of that will need to support both doesn't use slots (canonical-livepatch) | 10:45 |
| stub | well, doesn't need to specify its slots since they autoconnect | 10:45 |
| jacekn | ISTR there is a way to get shell inside snap confinement for troubleshooting purposes but I can't find any docs. Anybody knowns how to do it? | 11:08 |
| tsdgeos | jacekn: run --shell ¿ | 11:11 |
| tsdgeos | i.e. snap run --shell mySnap | 11:11 |
| jacekn | tsdgeos: aha that's it! | 11:12 |
| tsdgeos | glad to be of service :) | 11:13 |
| jacekn | right so next question will be how to bump number of open files, it's tricky because my snap is a deaemon so it uses autogenerated systemd unit file | 11:14 |
| bull | hi guys i need help building snap package of my application which i wrote using qt57 installed in my /opt/qt57 now i dont wana use qt57 part cause it download whole qt57 source and then compile it and then fail at middle | 11:47 |
| bull | my question is , can i use the system's (/opt/qt57) qmake to build source and build snap package | 11:47 |
| bull | launchpad also gives up with my project cause it through errors while compiling qt code :D | 11:50 |
| mup | PR snapcraft#980 opened: Add optional "source-checksum" property <Created by pachulo> <https://github.com/snapcore/snapcraft/pull/980> | 11:51 |
| bull | i used qt5.7 cause it has a working qwebengine api :D | 11:53 |
| stub | kalikiana_: There is no syntax that works with both 2.16 and 2.17. If I use core instead of ubuntu-core: it fails under 2.16 | 11:59 |
| mup | PR snapcraft#959 closed: cli: make plugins be an alias of list-plugins <Created by tsdgeos> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/959> | 12:00 |
| mup | PR snapcraft#970 closed: sources: refactor zip source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/970> | 12:00 |
| stub | kalikiana_: (whoops.... backscroll fail) | 12:00 |
| mup | PR snapcraft#976 closed: demos: do not force arch for the tomcat demo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/976> | 12:03 |
| mup_ | PR snapd#2491 opened: debian: use a packaging branch for 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2491> | 12:06 |
| === arosales_ is now known as arosales | ||
| === mup_ is now known as mup | ||
| mup | PR snapd#2492 opened: cmd/snap: remove currency switch following UX review <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2492> | 12:13 |
| mup | PR snapcraft#981 opened: Support download and validate on branded stores <Created by cprov> <https://github.com/snapcore/snapcraft/pull/981> | 12:33 |
| seb128 | kyrofa, hey, do you know if remote parts can specify a git branch to use? | 12:41 |
| seb128 | sergiusens, ^ | 12:43 |
| ogra_ | ppisati, i need an updated kernel snap in edge to have it pick up some initrd changes, what was your exact naming scheme you use for the beta/candidate builds so i can make the edge bzr branch match that ? | 12:46 |
| ogra_ | err | 12:47 |
| ogra_ | s/naming scheme/versioning scheme/ (indeed) | 12:47 |
| madprops | ok here's another question i have | 13:02 |
| madprops | regarding autoupdates | 13:02 |
| madprops | if my internet is not very good and im in the middle of an online game or downloading something important | 13:03 |
| madprops | i wouldn't like some program updates hindering my bandwidth | 13:03 |
| madprops | i would rather update when I want | 13:03 |
| madprops | i even disabled auto updates in my android phone | 13:03 |
| ogra_ | madprops, it is managed by a systemd time that you can turn off but you should really not forget to update regulary then :) especially if you use snaps from the edge channel that can change frequently | 13:05 |
| ogra_ | snapd.refresh.timer is the system unity | 13:05 |
| abeato | ogra_, quick question, I understand that whenever a new core/kernel gets installed, uboot.env gets rebuilt with the right values for snap_core and snap_kernel, correct? | 13:06 |
| ogra_ | not re-build, jzust these vars get updated | 13:06 |
| abeato | ogra_, well, modified :) | 13:07 |
| ogra_ | yeah | 13:07 |
| ogra_ | abeato, snapd does that through uboot.go, you can check the values with fw_printenv | 13:08 |
| abeato | ogra_, ah, good to know, thanks | 13:09 |
| bull | hi guys i need help building snap package of my application which i wrote using qt57 installed in my /opt/qt57 now i dont wana use qt57 part cause it download whole qt57 source and then compile it and then fail at middle | 13:25 |
| bull | my question is , can i use the system's (/opt/qt57) qmake to build source and build snap package | 13:25 |
| bull | launchpad also gives up with my project cause it through errors while compiling qt code :D | 13:25 |
| bull | ogra_, | 13:25 |
| ogra_ | bull, you can probably create a snapcraft part for it and use this during the build of your app ... | 13:39 |
| ogra_ | or perhaps you could use ubuntu-app-platform ... i'm not actually sure which Qt version that ships | 13:41 |
| bull | ogra_, that does not include qt57 | 13:43 |
| bull | ogra_, can i use my system's qt57 ?? | 13:43 |
| ogra_ | ah, well, then you likely need to create a part | 13:43 |
| bull | ogra_, i have no idea how to do that , i have installed qt57 from ppa | 13:43 |
| ogra_ | well yopu would have to include it in your snap | 13:44 |
| bull | i want its qmake build my source in snapcraft and turn my code to snap :( | 13:44 |
| ogra_ | or create a part that pulls it from the PPA and instalkls it in the snapcraft build env | 13:44 |
| bull | ogra i can include everything by staging but idk how to call opt/qt57/bin/qmake | 13:44 |
| ogra_ | heh, i dont know either ... perhaps with a make plugin as wrapper or some such ... | 13:45 |
| bull | ogra_, i dont know how o do it man :( i been struggling from 3 days :( | 13:45 |
| ogra_ | you shoudl ask someone with some more Qt experience ... i did never really get past QML | 13:46 |
| bull | i used remote qt57 which downloaded more then 2gb of qt src and chromium src dataand failed twice as it cant build correctly | 13:46 |
| ogra_ | perhaps the guys in #ubuntu-app-devel could be of help | 13:46 |
| bull | ogra_, let me ask them thanks man | 13:46 |
| ogra_ | bull, also https://github.com/snapcore/snapcraft/pull/566 seems to be the snapcraft qmake plugin .. you might need to use it and override some bits to make your bzuild use a custom qmake (not sure about that though) | 13:48 |
| mup | PR snapcraft#566: Add qmake plugin <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/566> | 13:48 |
| bull | i uploaded my other application to store check them here https://uappexplorer.com/apps?q=author%3Akeshavbhatt&type=all_types&sort=-points | 13:51 |
| bull | ogra_, am looking into it thanks | 13:51 |
| pihole | kyrofa: thanks for your help the other day; I got it working. Now I'm stuck trying to get a config file deployed for the DNS server, which I have traditionally used a shell script to modify some of the values. Is there any way to do this via a custom plugin? | 13:57 |
| jdstrand | niemeyer: hi! https://github.com/snapcore/snapd/pull/1613 still has you as 'requesting changes' in github so no one can merge it. would you mind 'approving changes' and merging it? | 14:01 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 14:01 |
| liuxg | sergiusens, recently I found a bug on dragonboard. could you please help to take a look at it? thanks. the bug link is at https://bugs.launchpad.net/snapcraft/+bug/1649181 | 14:26 |
| mup | Bug #1649181: 'ascii' codec can't encode character '\u29f8' in position 49: ordinal not in range(128) on ARM 64 platform like dragon board <Snapcraft:New> <https://launchpad.net/bugs/1649181> | 14:26 |
| mup | PR snapd#2493 opened: overlord/snapstate,daemon: implement GET /v2/aliases handling <Created by pedronis> <https://github.com/snapcore/snapd/pull/2493> | 14:26 |
| mup | PR snapd#1613 closed: interfaces/builtin: add dbus interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1613> | 14:27 |
| kalikiana_ | yay, dbus | 14:31 |
| ogra_ | liuxg, wow, something must be really outdated on your side, that has been fixed ages ago iirc | 14:42 |
| ogra_ | liuxg, popey's bug ... bug 1607015 | 14:43 |
| mup | Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1607015> | 14:43 |
| liuxg | ogra_, but it happened now on my board.. I tried to use classic to build a project, and it happened to be like that | 14:43 |
| liuxg | ogra_, it seems that it happens on the arm64 architecture, on 32bit architecture, it does not happen. | 14:44 |
| ogra_ | well, read the bug ... fixed long ago if you use the proper component | 14:44 |
| ogra_ | i'm pretty sure that char isnt usedd anywhere anymore | 14:45 |
| liuxg | ogra_, the same project can be compiled on pi devices. | 14:46 |
| ogra_ | well, no idea then, but i know that the slashes were dropped from all components (or was the char a backslash ? ) | 14:46 |
| ogra_ | when we dropped support for the old desktop-* things | 14:47 |
| liuxg | ogra_, let me try again. it is very consistent. | 14:48 |
| ogra_ | and your snapcraft yaml uses desktop-*, not desktop/* ? | 14:49 |
| ogra_ | (the latter causes the bug and the parts using a slash in the name were all dropped long ago) | 14:50 |
| sergiusens | ogra_ well they are not dropped, just deprecated ;-) | 14:50 |
| ogra_ | sergiusens, dropped from support ;) | 14:50 |
| ogra_ | nobody touched them since | 14:51 |
| sergiusens | and for this very reaon | 14:51 |
| ogra_ | yeah | 14:51 |
| sergiusens | right, that is true | 14:51 |
| ogra_ | if you see it with the dash version, there might indeed be a bug though | 14:51 |
| liuxg | ogra_, sergiusens, this is the result http://paste.ubuntu.com/23633817/ | 14:51 |
| ogra_ | ... somewhere ... | 14:52 |
| ogra_ | now thats a different char | 14:52 |
| ogra_ | '\xae' | 14:52 |
| liuxg | ogra_, sergiusens yeah, yes, they both are reported in the bug | 14:53 |
| ogra_ | liuxg, and you are sure you are not using a part with a slash in the name in your snapcraft yaml ? | 14:53 |
| liuxg | ogra_, I have changed to use "mqtt-paho-python3" instead, but it is the same. | 14:54 |
| ogra_ | you still get complaints about '\u29f8' ? even though you dont have any names with a slash in your snapcraft yaml and have completely cleaned your tree before calling snapcraft ? | 14:59 |
| liuxg | ogra_, I am now trying it again. I remember I did that before. | 15:00 |
| mup | PR snapcraft#982 opened: parser - Use the same version method as 'snapcraft' <Created by josepht> <https://github.com/snapcore/snapcraft/pull/982> | 15:03 |
| liuxg | ogra_, you are right. after changing to "-", it is OK. I remember I changed that last time. | 15:08 |
| tsdgeos_ | what processes the files in /var/lib/snapd/mount ? | 15:11 |
| tsdgeos_ | is it snap-confine ? | 15:11 |
| jdstrand | roadmr: hi! can you do a store sync for r810. that is just a data update, no code changes | 15:14 |
| roadmr | jdstrand: sure! | 15:14 |
| jdstrand | roadmr: thanks! | 15:14 |
| mup | PR snapcraft#983 opened: Updated scons plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/983> | 15:15 |
| shuduo | when i try to register a key for sign a model assertion with "snapcraft register-key" i got error and the msg is "Key registration failed: Failed to save account-key-request assertion for account_id XXXXXX invalid revision: could not add assertion (revision 0 is already the current revision)" | 15:16 |
| shuduo | mvo: any idea ^? | 15:17 |
| mvo | shuduo: I am not sure, sergiusens may know better but it sounds like the key is already registered maybe? | 15:18 |
| ZenHarbinger | Quick question about snapcraft development. I have put forth some PRs, but the autopkgtest is failing for xenial- and yakkety- amd64. Is there a reason why these 2 might fail and the rest pass? | 15:18 |
| bull | guys how can we use local part from / part/plugins dir ?? | 15:20 |
| shuduo | mvo, sergiusens, it failed at first time with msg "Key registration failed: Failed to create account-key assertion for account_id XXXXX assertion refused: could not add assertion (account-key assertion for YYYYY has the same name "default" as existing ID ZZZZ. | 15:21 |
| bull | i mean what we have to put in snapcraft.yaml file to so that snapcraft can recognize that plugin | 15:21 |
| shuduo | but how i can find exist keys from launchpad to manage them? | 15:21 |
| bull | sergiusens, help me please am lost since three days :( | 15:21 |
| bull | popey, hi | 15:23 |
| alex-abreu | mvo, snapd 2.20 is for this week or next week ? | 15:28 |
| abeato | ondra, I have this for the rpi3 gadget: https://github.com/snapcore/pi3-gadget/pull/4 | 15:32 |
| mup | PR pi3-gadget#4: Add support to boot from USB <Created by alfonsosanchezbeato> <https://github.com/snapcore/pi3-gadget/pull/4> | 15:32 |
| abeato | ups | 15:32 |
| abeato | ogra_, ^^ | 15:33 |
| ogra_ | abeato, wont work | 15:33 |
| mvo | alex-abreu: today | 15:33 |
| ogra_ | that needs a specific firmware so we need a separate new gadget | 15:33 |
| abeato | ogra_, well, it does (if you enable first USB booting from raspbian) | 15:33 |
| abeato | ogra_, the firmware works for both cases | 15:33 |
| === chihchun is now known as chihchun_afk | ||
| abeato | I tested that | 15:34 |
| ogra_ | abeato, the prob is really that it is irreversible ... on the pi ... so we need more HW | 15:34 |
| ogra_ | one to test U(SB, one to test SD where we never switch the rom | 15:34 |
| abeato | ogra_, well, give it a try in yours :) | 15:34 |
| ogra_ | i surely wont | 15:34 |
| alex-abreu | mvo, thank you, ... also quickly do you have the rights to give me the commit rights in snapweb github? | 15:34 |
| ogra_ | since i need to still be able to test SD | 15:34 |
| abeato | ogra_, both SD and USB work for me :) | 15:35 |
| mvo | alex-abreu: let me check, I think I don't have the needed privs, only gustavo has. but I will double check | 15:35 |
| alex-abreu | mvo, ok | 15:35 |
| ogra_ | abeato, you mean you can turn it back into an SD obnly device ? | 15:35 |
| ogra_ | afaik thats not possible | 15:35 |
| ogra_ | if you switch to the other path for the ROM there is no way back | 15:36 |
| mvo | alex-abreu: actually jamiebennett and elopio have admin | 15:36 |
| jamieben_ | mvo: that is not enough | 15:36 |
| mvo | oh, ok | 15:36 |
| jamieben_ | mvo: you need to be an organisational admin apparently | 15:36 |
| mvo | alex-abreu: -^ | 15:36 |
| jamieben_ | mvo: the add user stuff if greyed out for me | 15:37 |
| alex-abreu | mvo, oh ... | 15:37 |
| alex-abreu | jamieben_, so who can add users? | 15:37 |
| === jamieben_ is now known as JamieBennett | ||
| JamieBennett | I know niemeyer can | 15:37 |
| abeato | ogra_, don't know, but the PR will not break your rpi, to enable USB you need to do something else | 15:37 |
| alex-abreu | niemeyer, ^ when you see this, ... adding me as committer to snapweb | 15:38 |
| ogra_ | abeato, not the PR, but to test it we need additional HW | 15:39 |
| ogra_ | abeato, we still need to be able to test the default setup without the ROM switcvh | 15:39 |
| abeato | ogra_, you can do that :) I tested with the switch, you can test without it | 15:41 |
| ogra_ | abeato, ah, i see you didnt add the config.txt bit by default | 15:42 |
| abeato | ogra_, correct | 15:42 |
| paperManu | hello there | 15:42 |
| ogra_ | abeato, oh, CONFIG_PREBOOT is clever ! | 15:43 |
| mup | PR snapd#2494 opened: store: send an explicit X-Ubuntu-Classic header to the store <Created by pedronis> <https://github.com/snapcore/snapd/pull/2494> | 15:44 |
| ogra_ | abeato, why is the "enable_uart=1" needed ? isnt that initialized by default anyway ? | 15:45 |
| abeato | ogra_, not with latest firmware, and that caused *lots* of problem until I found the right solution | 15:46 |
| ogra_ | ah | 15:46 |
| abeato | ogra_, https://github.com/RPi-Distro/repo/issues/22 | 15:46 |
| ogra_ | yeah, we're a bit behind with the firmware files ... better safe than sorry :P | 15:46 |
| abeato | indeed lol | 15:46 |
| ogra_ | ppisati, would you mind taking a look at https://github.com/snapcore/pi3-gadget/pull/4 as well ? | 15:47 |
| mup | PR pi3-gadget#4: Add support to boot from USB <Created by alfonsosanchezbeato> <https://github.com/snapcore/pi3-gadget/pull/4> | 15:47 |
| ogra_ | ppisati, looks all fine from my POV ... but i'd like a second pair of eyes | 15:47 |
| bull | help me anyone know how to use local parts/plugin in snapcraft ?? | 15:48 |
| bull | ogra_, :( | 15:48 |
| shuduo | sergiusens, ping | 16:01 |
| * ogra_ wonders if ppisati ignores #snappy today :P | 16:05 | |
| ppisati | ogra_: nope, just juggling some stuff | 16:06 |
| ogra_ | ah, k, you were so quiet :) | 16:06 |
| ppisati | ogra_: the days before PTO are always the best... | 16:06 |
| ogra_ | go on juggling then ;) | 16:06 |
| mup | PR snapcraft#984 opened: parser - Make output better <Created by josepht> <https://github.com/snapcore/snapcraft/pull/984> | 16:09 |
| ppisati | ogra_: looks good too | 16:10 |
| ogra_ | ppisati, thx ... also see my former ping about the edge kernel | 16:10 |
| ogra_ | (no hurry though ... but i'd like it in edge before the weekend ... tomorrow is fione too) | 16:10 |
| ppisati | ogra_: this is the tip of the snapcraft.yaml ATM | 16:12 |
| ppisati | ogra_: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc | 16:12 |
| ppisati | ogra_: kernelversion-abi-uploadnum | 16:13 |
| ogra_ | ppisati, ah, so not different from what we have now | 16:13 |
| ogra_ | good, thanks | 16:14 |
| mup | PR snapcraft#890 closed: cli: implementing '[list-]registered' command <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/890> | 16:18 |
| ogra_ | slangasek, hmm, wheer are the actual snap builds for the gadgets now ? i merged some code for pi3 but no snap shows up in the store ... i find https://launchpad.net/snap-pi3 but there seems to be no related snap buuild anywhere | 16:46 |
| ogra_ | bah | 16:47 |
| slangasek | ogra_: we discussed that this was moving to github; where are you merging this code to? | 16:47 |
| ogra_ | and after 20min searching /me finds the "show snap packages" link at the very bottom of the page above | 16:47 |
| ogra_ | slangasek, on github :) | 16:48 |
| slangasek | so e.g. https://github.com/snapcore/pi3-gadget | 16:48 |
| ogra_ | right | 16:48 |
| ogra_ | it just didnt get picked up by any auto-build yet | 16:48 |
| slangasek | ok | 16:48 |
| ogra_ | and https://code.launchpad.net/~canonical-foundations/snap-pi3/+git/github-mirror/+ref/master doesnt seem to have the last merge | 16:48 |
| ogra_ | oh | 16:49 |
| slangasek | ogra_: so you have merged an update that takes a *different* set of undocumented blobs into the pi3 snap? where is the source for the build that's being used? | 16:49 |
| ogra_ | https://code.launchpad.net/~canonical-foundations/snap-pi3/+git/github-mirror ... only runs every 5h | 16:49 |
| ogra_ | slangasek, theer is no source for the blobs obviously ... for the uboot side this merge adds instructions with pointers to the source in the README.md | 16:50 |
| seb128 | is it possible to connect a locally built snap to the content interface from a snap from another provider (canonical) coming from the store? | 16:50 |
| seb128 | kyrofa, ^ hey, do you know? | 16:50 |
| kyrofa | seb128, I _think_ so | 16:52 |
| kyrofa | seb128, but that stuff changes fast | 16:52 |
| ogra_ | slangasek, we can indeed note that the blobs come from https://github.com/raspberrypi/firmware but we still wont get the source | 16:52 |
| slangasek | ogra_: pointers> ok | 16:52 |
| kyrofa | seb128, last I heard, it won't automatically connect since they aren't from the same publisher but you can still connect them | 16:52 |
| slangasek | ogra_: sure; I meant specifically the uboot blob here :P | 16:52 |
| kyrofa | seb128, unless the base assertion denies it, that should work | 16:53 |
| seb128 | kyrofa, I wonder if I'm doing something stupid or using the wrong syntax, it gives me a "(cannot connect plug to slot "gnome318-runtime" from snap "gnome318-udt", no such slot)" | 16:53 |
| kyrofa | seb128, pastebin snap interfaces for me? | 16:53 |
| ogra_ | slangasek, switching to plain-from-soource builds for uboot is on my TODO for early jan. the current blob comes from abeato's disk following the README instructions | 16:55 |
| slangasek | ogra_: er, we should discuss this; as I've said before the uboot builds should come from the archive | 16:56 |
| pihole | I `dump` some config files with my snap, but I need to modify some values in those files. I typically do this via a shell script running some `sed` commands. Is there a way to run a script after the snap is installed, or do I need to make a custom plugin to do something like this. | 16:56 |
| slangasek | ogra_: so that we can use the same uboot source for classic and snappy images via ubuntu-image | 16:56 |
| ogra_ | slangasek, that was my plan (discussing it first with you and ppisati) | 16:56 |
| slangasek | ok | 16:56 |
| ogra_ | we need an extra patch and thus extra binaries | 16:57 |
| ogra_ | but you know that already :) | 16:57 |
| ondra | abeato did you talk to penk? he's been also trying to boot from USB | 16:59 |
| kgunn | JamieBennett: is this still the most "up to date" img for downloading? | 16:59 |
| kgunn | http://releases.ubuntu.com/ubuntu-core/16/ | 16:59 |
| ogra_ | ondra, should work with the next gadget from edge | 16:59 |
| kgunn | ....i know the proposed channel is being updated...just wondering if someone is just starting fresh...is that the most recent img to get | 16:59 |
| JamieBennett | kgunn: yes, no new images yet | 16:59 |
| kgunn | thanks | 17:00 |
| ondra | ogra_ one you blow USB boot fuse, you can still boot from sdcard | 17:00 |
| ogra_ | ondra, yes, but you use differenmt ROM code ... | 17:00 |
| ogra_ | ondra, rto test the original path you still need a pi that hasnt been changed | 17:01 |
| abeato | ondra, I saw his post, was a nice way to get started :). But we wanted to remove completely the SD card, with the merges you changed that is possible now | 17:01 |
| abeato | *you merged | 17:01 |
| abeato | changes you merged | 17:01 |
| abeato | lol | 17:01 |
| ondra | abeato cool | 17:02 |
| mup | PR snapcraft#985 opened: Better message for missing snapcraft.yaml in origins <Created by josepht> <https://github.com/snapcore/snapcraft/pull/985> | 17:06 |
| kyrofa | kgunn, got a sec? | 17:07 |
| mup | PR snapcraft#960 closed: pluginhandler: install scriptlet support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/960> | 17:12 |
| mup | PR snapcraft#977 closed: Prefer in-snap libraries to system libraries <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/977> | 17:12 |
| kgunn | kyrofa: whats up | 17:13 |
| kyrofa | kgunn, bug #1639831 . You're saying that on the prime step, those libs are being sucked from the system. Is that right? | 17:14 |
| mup | Bug #1639831: filter unwanted pkgs in snap creation when relying on content interface <Snapcraft:Incomplete> <https://launchpad.net/bugs/1639831> | 17:14 |
| niemeyer | alex-abreu: What's your GH nick? | 17:15 |
| alex-abreu | niemeyer, AlexandreAbreu | 17:17 |
| niemeyer | alex-abreu: Cheers | 17:17 |
| kyrofa | kgunn, i.e. what elopio recommended there isn't a solution? | 17:17 |
| niemeyer | JamieBennett: Yeah, not to the add to the team, but the problem is that most people are not even in the organization of course | 17:18 |
| niemeyer | Their model works best when the whole org is part of GH, which doesn't sound so typical actually | 17:18 |
| niemeyer | alex-abreu: You've been invited into the team | 17:19 |
| alex-abreu | niemeyer, thx | 17:19 |
| kgunn | kyrofa: right, so when AlbertA was verifying mir-kiosk work, we noticed the GL drivers still being sucked in....which can be misleading/confusing | 17:20 |
| kgunn | i think AlbertA did manually verify he was using the GL from the system.... | 17:20 |
| kyrofa | kgunn, because that stuff should be coming from content sharing, indeed | 17:20 |
| stub | I need to transfer a snap name to upstream. Do I revoke my own access, or does someone here need to handle it? | 17:21 |
| kgunn | kyrofa: well in the case of GL drivers...it's actually a core i/f | 17:21 |
| kgunn | iirc | 17:21 |
| kyrofa | kgunn, so snapcraft, in the prime step, craws the prime dir pulling in libraries that resolve on the system | 17:21 |
| kyrofa | In the case of content sharing, you specifically don't want to do that (at least for the libs within the shared snap) | 17:21 |
| kyrofa | kgunn, unfortunately we don't really have a way of knowing what's contained within the shared snap | 17:22 |
| kyrofa | kgunn, would you favor the ability to disable that crawling completely? | 17:22 |
| kgunn | thinking | 17:24 |
| mup | PR snapcraft#986 opened: Clean up snapcraft-parser help <Created by josepht> <https://github.com/snapcore/snapcraft/pull/986> | 17:24 |
| mup | PR snapd#2487 closed: overlord/snapstate: implement snapstate.ResetAliases <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2487> | 17:24 |
| kgunn | kyrofa: i wouldn't think disabling crawling completely would be good... | 17:26 |
| kgunn | but not sure what the right answer would be | 17:26 |
| kyrofa | kgunn, yeah it's not ideal, but I'm not sure there's a better option | 17:26 |
| kgunn | wonder if it's as easy as listing someplace what you want excluded | 17:26 |
| kgunn | and if you exclude it, it prevents any deps below it from being satisfied | 17:27 |
| kyrofa | kgunn, that's doable, but would be a pain to maintain. Hmm | 17:27 |
| kyrofa | kgunn, okay, I'll bring it up at standup today, see if there are some better ideas | 17:27 |
| kyrofa | kgunn, but consider that bug un-incompleted | 17:28 |
| kgunn | yeah...i mean in our case, we just kept tripping over the gl driver being there...so it was a very specific thing | 17:28 |
| kgunn | i just figure it will likely trip up others as things get broken into multiple snaps (system wise) more and more | 17:29 |
| kyrofa | Definitely | 17:29 |
| stub | I'm going to revoke my access to the name with a comment. Hopefully that is the right thing to do, and upstream can then claim it. | 17:30 |
| mup | PR snapd#2494 closed: store: send an explicit X-Ubuntu-Classic header to the store <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2494> | 17:33 |
| mup | PR snapcraft#987 opened: pluginhandler: prepare scriptlet support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/987> | 17:39 |
| sergiusens | kyrofa kgunn ideally the SDK for whatever content sharing thing would come from a tarball you can use as a part, then snapcraft is smart enough to know what not to crawl in | 17:40 |
| sergiusens | the fact that you have a content shared snap you want to use but provide the "SDK" from some other means allows for skewing and also ties you to building on a certain release | 17:40 |
| sergiusens | given that the mechanism now is `build-packages` for everything | 17:41 |
| sergiusens | since the content interface is loosly coupled we cannot do much about this | 17:41 |
| kyrofa | sergiusens, yeah that would work, it wouldn't pull libs that were staged | 17:42 |
| sergiusens | personally I believe the strategy for the SDK to use a "platform snap" needs some tuning | 17:42 |
| kyrofa | sergiusens, how would you approach that? | 17:42 |
| sergiusens | kyrofa create a snap with just -dev stage-packages maybe | 17:50 |
| sergiusens | not sure, need to sit down and experiment I guess | 17:50 |
| kyrofa | i.e. less of a platform, more of just an SDK? | 17:50 |
| seb128 | kyrofa, sergiusens, you shouldn't rely only on the smart behaviour, while playing with my demo snap I used a trivial snapcraft.yaml with the dump plugin copying a binary from my system | 17:52 |
| seb128 | that should be possible for hackers to do | 17:52 |
| seb128 | without having to pull in a sdk just to trick snapcraft in doing what the user wants | 17:53 |
| kyrofa | seb128, yeah, we're just talking through how content sharing would best be done in snapcraft, while still being able to take advantage of snapcraft's smarts. An option to disable the crawling is still something we're talking about | 17:58 |
| seb128 | good | 17:58 |
| kyrofa | Because just an all-or-nothing isn't ideal, either | 17:58 |
| seb128 | right, it's not ideal | 17:59 |
| seb128 | but it gives a way to get things to work | 17:59 |
| seb128 | where there is none today | 17:59 |
| kyrofa | Indeed, it gives power users power | 17:59 |
| kyrofa | And that's not exactly true-- if you could stage a tarball of shared content, snapcraft wouldn't pull those libs from elsewhere | 18:00 |
| kyrofa | seb128, how do you "build against" a shared snap? | 18:01 |
| seb128 | currently for gtk I'm using the xenial debs for building the framework snap | 18:02 |
| kyrofa | And then when building clients for it, using the xenial debs again? | 18:02 |
| seb128 | so "use xenial desktop" is the recommendation for building | 18:02 |
| seb128 | like use snapcraft on a xenial install | 18:02 |
| seb128 | but the plan for next step is probably to pull the -dev packages | 18:03 |
| seb128 | and exclude them from the snap | 18:03 |
| seb128 | but create a tar from the stage | 18:03 |
| seb128 | and upload that as a remote part somewhere | 18:03 |
| kyrofa | Yeah, then build against that | 18:04 |
| seb128 | right | 18:04 |
| kyrofa | That's what we were thinking, too. And snapcraft wouldn't pull those libs from the system, in that case | 18:04 |
| seb128 | right | 18:04 |
| kyrofa | (snapcraft would work with that today) | 18:05 |
| kyrofa | And that wouldn't be tricking snapcraft into doing what the user wants, it would be the user doing things the right way (building against what's contained in the snap) | 18:09 |
| seb128 | indeed | 18:10 |
| mup | PR snapcraft#977 opened: Prefer in-snap libraries to system libraries <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/977> | 18:12 |
| cachio | jdstrand, I saw the dbus branch has been merged | 18:33 |
| jdstrand | cachio: it has :) | 18:33 |
| cachio | jdstrand, is it gonna to be ready in edge tomorrow? | 18:33 |
| jdstrand | cachio: it is in master slated for 2.20. I don't know the status of when 2.20 will be available. JamieBennett, can you answer? | 18:34 |
| jdstrand | JamieBennett: and hi! :) | 18:34 |
| JamieBennett | jdstrand: cachio: We are hoping to release tonight, last minute changes but in the next few hours, fingers-crossed | 18:34 |
| cachio | JamieBennett, jdstrand nice, I'll try tomorrow in that case | 18:35 |
| === petevg_afk is now known as petevg | ||
| niemeyer | jdstrand: Do you happen to know what the status of snapd#2417 is? You've reviewed it a couple of days ago, and some changes got applied, but it's not clear if it's ready or not | 19:07 |
| mup | PR snapd#2417: interfaces/builtin: add uhid interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2417> | 19:07 |
| jdstrand | niemeyer: it is on my list to re-re-review today :) | 19:09 |
| jdstrand | there's three. this, unity-pim and download manager | 19:10 |
| mup | PR snapd#2465 closed: snap: show apps in `snap info` <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2465> | 19:16 |
| niemeyer | jdstrand: Ack, thanks | 19:20 |
| mup | PR snapd#2495 opened: Add Priced status to go client definitions <Created by AlexandreAbreu> <https://github.com/snapcore/snapd/pull/2495> | 19:31 |
| mup | PR snapd#2419 closed: store: retry downloads on io.Copy errors and sha3 checksum errors <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2419> | 19:47 |
| mup | PR snapd#2491 closed: debian: use a packaging branch for 14.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2491> | 20:02 |
| elfgoh_ | Anybody knows the roadmap for BBB support? | 20:09 |
| mup | PR snapd#2490 closed: many: implement "snap alias --reset" using snapstate.ResetAliases <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2490> | 20:33 |
| mup | PR snapcraft#988 opened: pluginhandler: build scriptlet support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/988> | 20:39 |
| tsutsu | is there a way to avoid a hard restart of a daemon during a snap update? for example, to get nginx's SIGUSR2 graceful upgrade semantics, or erlang's hot-code-upgrade relup semantics? | 21:23 |
| kyrofa | tsutsu, have you played with the stop-command for the daemons? | 21:26 |
| kyrofa | I'm not sure how it's implemented, but may be a path to explore | 21:27 |
| mup | PR snapd#2496 opened: release: version 2.20 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2496> | 21:28 |
| mfeatherston | I have just ubuntu core installed on an arm system and I'm trying to make it run any graphical demo. What provides X11 in this case? | 21:33 |
| kyrofa | mfeatherston, you probably want the mir server stuff kgunn has been working on | 21:33 |
| mfeatherston | I'd be up for trying that, but is X11 still possible for now? I have a resistive touchscreen, I'm not sure how/if mir supports the calibration for that. | 21:35 |
| kyrofa | mfeatherston, not that I know of anyway | 21:36 |
| kgunn | mfeatherston: what resistive touchscreen do you have? | 21:37 |
| kgunn | as for calibration.... we should ask camako | 21:37 |
| mfeatherston | I ported support for our board here: | 21:37 |
| mfeatherston | https://www.embeddedarm.com/products/TS-TPC-8390-4900 | 21:37 |
| kgunn | who might point to someone else on the mir team | 21:37 |
| mfeatherston | This is a ads7846 touch controller | 21:37 |
| mfeatherston | Worst case if it can read the ABS stuff I can hardcode the calibration in the kernel for a demo | 21:38 |
| kgunn | yeah, mfeatherston, would love for you to give the mir-snaps stuff a shot | 21:38 |
| mfeatherston | how can I install that? | 21:39 |
| kgunn | you've got a link to the wiki? | 21:39 |
| kgunn | oh...lemme get it | 21:39 |
| kgunn | https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ | 21:39 |
| kgunn | mfeatherston: assuming you're kinda familiar and have your core up and running...just follow the "Quick Start" bits | 21:39 |
| mfeatherston | Cool, I'll give this a try. Thanks! | 21:40 |
| kgunn | mfeatherston: and definitely ping me if you run into issues... | 21:41 |
| kgunn | mfeatherston: if you hit issues you think are purely gfx/input...feel free to ping in #ubuntu-mir | 21:41 |
| kgunn | and others in there can be helpful | 21:41 |
| mup | Bug #1650389 opened: Installing snapd on 14.04.5 desktop downgrades xorg et al. <14.04> <Snappy:New> <https://launchpad.net/bugs/1650389> | 21:52 |
| mfeatherston | kgunn: after installing mir-kiosk it failed with "cannot bind-mount the mount namespace file /proc/2422/ns/mnt -> mir-kiosk.mnt. errmsg: Permission denied". It's possible I missed a kernel config option this would need, but namespace support is present | 21:58 |
| mfeatherston | ahh, he just left | 21:58 |
| flexiondotorg | kyrofa, Do you remember that issue I mentioned last week regarding source-type:deb not correctly creating symlinks in debs? | 23:06 |
| kyrofa | flexiondotorg, indeed, and I have a fix for it, but ran into packaging issues from pip | 23:07 |
| flexiondotorg | Ooh. | 23:07 |
| kyrofa | flexiondotorg, it's a known issue in python3-apt, but python3-deb (which works better) has some installation issues when using pip. I need to investigate | 23:07 |
| flexiondotorg | I'm talking to a popular music streaming service tomorrow. | 23:07 |
| flexiondotorg | I've got a snap | 23:07 |
| flexiondotorg | kyrofa, Do you have a branch with those changes? | 23:08 |
| kyrofa | flexiondotorg, if you're willing to run out of a branch, I've got a fix for you | 23:08 |
| kyrofa | Yep, one sec | 23:08 |
| flexiondotorg | I'm prepared to take a look now :-) | 23:08 |
| flexiondotorg | I've got two significant ISVs where this would be good to fix. | 23:08 |
| kyrofa | flexiondotorg, thanks for the reminder. I'll see if I can't dig into this a bit tonight | 23:09 |
| flexiondotorg | Well, I've got sometime now. | 23:09 |
| flexiondotorg | To take a peek. | 23:09 |
| kyrofa | flexiondotorg, here's the PR with branch attached: https://github.com/snapcore/snapcraft/pull/941 | 23:10 |
| mup | PR snapcraft#941: Support symlinks within deb sources <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/941> | 23:10 |
| kyrofa | If you take a look at the tests you'll see what I mean | 23:10 |
| mup | PR snapcraft#989 opened: Add support for disabling system library migration <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/989> | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!