[04:56] morning [05:06] Any one tell us, why the "snapcraft pull" command always create "default-jdk and java-open-Jdk" in the "parts/local/install" directory, and also guide us to use oracle-jdk. [05:56] I have a maven project which has source and target versions as JDK 1.8. And I wanted to build a snap app for the same project. As per the doc it looks like snapcraft "will pull a relocatable OpenJDK via the default-jdk Ubuntu package" and since, my project relies on 1.8 building the app fails. Is there a provision through which I can build the project? [06:26] mvo: morning [06:27] mvo: i was experimenting with udev a bit yesterday, just to simulate us dropping new rules file to /etc/udev/rules.d [06:27] when udev reloads the rules and tirggers events, there's a chance bad things will happen [06:28] Good morning [06:28] mborzecki: chance as in randomly? [06:29] zyga: yeah, looks like so [06:29] I wonder if we could run just a fragment of udev rules somehow [06:29] loosing sound, pulseuadio killed, libinput going crazy, disks spinning up [06:30] libinput thing is most annyoing, all the key repeat settings are gone now and cannot restore them, would probably have to restart the session [06:30] (xorg shutting down is probably more annyoing, but so far it didn't happen again) [06:40] hey mborzecki! good morning [06:40] mborzecki: uh, that sounds nasty [06:46] mborzecki: any idea what we can do about it? [06:46] not yet, need to do some digging still [06:47] ta === pstolowski|afk is now known as pstolowski [07:05] heyas! [07:06] hey pstolowski === chihchun_afk is now known as chihchun [07:20] I have a maven project which has source and target versions as JDK 1.8. And I wanted to build a snap app for the same project. As per the doc it looks like snapcraft "will pull a relocatable OpenJDK via the default-jdk Ubuntu package" and since, my project relies on 1.8 building the app fails. Is there a provision through which I can build the project? [07:34] PR snapd#5172 opened: cmd/snap-confine, interfaces/opengl: allow access to glvnd EGL vendor files [07:36] jdstrand: thank you for th update. Yes lets have a quick chat about this. I also think we will have to ship our own docker build (as we will do for etcd if we want to support other architectures). [07:42] hi [07:43] mvo commnted on your json.Number PR [07:51] pstolowski: thank you! [07:53] pstolowski: yeah, this is what I remembered as well. probably a good idea to talk during the standup about the concerns from samuele (aiui we don't use it consistently enough?) [07:54] mvo: it's possible i missed something as your PR shows... [07:54] mvo: just mentioning all this in case we want to re-consider the approach; we need to remember of the original bug that triggered the introducion of json.Number, although hopefully the tests should be good enough to prevent a regression [07:55] pstolowski: yeah, I don't want to go back, just wanted to explore options [07:55] pstolowski: i.e. if there is a strong opinion that we should do something else my PR would be a bit pointless :) [07:56] (but I think there is no such consensus yet) [07:58] mvo: pstolowski: as I said we don't have a strong case to do something else atm, otoh I think we discovered there are some people using client as a library, they might be surprised by Number but who knows, ... it seems something to reconsider if somebody files a bug or when we introduce config schemas [07:59] mvo: btw, I will not be at standup today, I have another meeting (not a recurring one though) [07:59] pedronis: +1 - its a good point that it will be surprising for some people [07:59] pedronis: meeting> thanks, no worries [08:00] i see [08:00] niemeyer: could you please add sil2100 to the standup for the time being? not sure if he should attend every day but he will work with us on core18 [08:01] mvo: pstolowski: at least in mvo's PR the use is documented for Conf [08:01] now [08:02] the only other issue is Attrs in interfaces but not sure is super used [08:03] mvo: I marked #4497 as something you should look at, it also need a 2nd Gustavo's review [08:03] PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it [08:04] pstolowski: btw if you did a review of #5169 we could land it [08:04] PR #5169: snap: fix `snap interface --attrs` output when numbers are used [08:05] our little hill of PRs seems hard to flatten [08:06] yes, merged [08:06] PR snapd#5169 closed: snap: fix `snap interface --attrs` output when numbers are used [08:07] o/ [08:08] pstolowski: thx [08:08] Chipaca: hi [08:09] pedronis: how's things? [08:10] good-ish [08:18] need to go out for a while, bb in 1-2h [08:33] pedronis: am I right in reading that we drop changes after just 1 day? [08:33] i thought it was longer than that [08:34] Chipaca: ready changes, yes [08:36] pedronis: context of my question was https://askubuntu.com/a/1037304/711 [08:57] mvo: I think 5157 and 5158 just needs to get green? there's a couple of PRs marked for you to review [08:59] zyga: are you working on #5081 ? [08:59] PR #5081: interfaces/apparmor: add chopTree [09:04] is there somebody with a PR that needs a review from me? most seems to need Gustavo's input or j-dstrand or rework or are close to merging [09:05] pedronis: Yes though a bit on the back of the queue [09:05] And on holidays today [09:05] ah [09:05] I will apply feedback in the evening [09:05] sorry [09:07] No worries :-) [09:19] hi all, when building with snapcraft cleanbuild the lxc ubuntu image is a xenial one? or is it whatever the host system is? [09:19] xenial [09:20] thanks popey [09:20] np [09:22] mvo: shall we land #5158? [09:22] PR #5158: boot,partition: improve tests/docs around SetNextBoot() [09:26] mborzecki: it looked ok tome [09:26] *to me [09:26] PR snapd#5157 closed: many: improve `snap wait` command [09:29] PR snapd#5158 closed: boot,partition: improve tests/docs around SetNextBoot() [09:44] pedronis: thanks, I get to the reviews now [09:45] PR snapd#5077 closed: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests [09:55] 'k finally got a working snap of timeline [09:55] https://gist.github.com/brunob/1155589f66171992c8661dd8a51d8555 [09:55] have to use this trick https://forum.snapcraft.io/t/add-external-resources-into-final-snap/990/2 [09:55] since the zip of the app doesn't provide a setup.py file [09:56] i was hoping to get it working with a dump of the zip downloaded, but no luck [09:57] cf https://gist.github.com/brunob/1155589f66171992c8661dd8a51d8555/ad3e38dd591969211daf59404c6b3e60495d069e [09:57] if anybody have advices or recommandations on this i'll be glad [10:01] b_b: my advice would be to ask in forum.snapcraft.io [10:02] 'k, thx Chipaca [10:11] PR snapd#5165 closed: tests: fix user mounts test for external systems [10:13] mwhudson: hey, do you build the go snap for ppc64el ? and if not, would it be possible to enable it there? we use it now as part of our autopkgtest suite [10:13] mvo: i do [10:14] mwhudson: hm, I get a "funny" error there https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/ppc64el/s/snapd/20180516_134211_9b965@/log.gz [10:14] mwhudson: "/snap/go/1877/gowrapper: line 3: /snap/go/1877/bin/go: No such file or directory" [10:18] diddledan: have you seen "IsADirectoryError" on corebird before? [10:18] diddledan: https://launchpadlibrarian.net/370632559/buildlog_snap_ubuntu_xenial_amd64_c0aad5cf3f1a1163b9cfe834a79080dc-xenial_BUILDING.txt.gz [10:18] "IsADirectoryError: [Errno 21] Is a directory: '/build/corebird/stage/usr/share/locale'" [10:20] "sorry, new users can posts 2 links only" [10:20] nice... [10:20] yeah the forum is a weird thing [10:21] it's anti-spam protection [10:21] https://forum.snapcraft.io/t/snapcraft-a-prebuilt-python-app-no-setup-py-file/5482 [10:21] is it needed if all the links are nofollow? (are they?) [10:21] just break the url, and post to the forum, give me the link and I'll fix it [10:21] done [10:21] hah, it thinks setup.py is a url :) [10:24] mwhudson: I think I know what is going on /lib64/ldso is not a relative link [10:24] mwhudson: I can fix that in core [10:24] mvo: uhh there were snapcraft bugs in this area but they got fixed i thought... [10:24] * mwhudson is not really here btw [10:25] mwhudson: thank you and sorry for the noise, I think I know what to do do fix this [10:27] mvo: ok :) [10:33] Bug #1771793 opened: Interface for hardware temperature monitoring [10:37] re [10:37] PR core#88 opened: hooks: make /lib64/ld64.so.2 relative to unbreak classic snaps on ppc64el [10:48] the problem was with the 3rd url popey : https://forum.snapcraft.io/t/add-external-resources-into-final-snap/990 [10:48] so i broke it [10:52] popey: b_b: backtick-quote things that it thinks are urls, fwiw [10:57] there is something seriously wrong with Qt 5.10 compatibility due to the newer/different syscalls it uses compared to earlier versions. e.g. `snap install --candidate kde-frameworks-5 && snap install okular && snap run okular` lots of write errors by snapd apparently denying linkat syscalls which are used inside qtemporaryfile which in turn is used for just about config file writing business (e.g. https://github.com/qt/qtbase/blob/ [10:57] fe5edcee602f0ab2912bbdd1a21f4309ed7dbfd6/src/corelib/io/qtemporaryfile.cpp#L466 ) I think this ultimately is also the problem here https://forum.snapcraft.io/t/qt5-kde-integration-in-vlc-snap-is-broken/5465 [10:57] seems fairly major, but I really don't know what to do with this :S [10:58] well, when I say fairly I actually mean: this is preventing any and all KDE snap builds moving forward === chihchun is now known as chihchun_afk [11:01] sitter: raising the issue in a forum topic, with a sampling of the denies, would be a good step towards fixing it [11:02] sitter: we've historically been rather good at fixing these [11:02] is it possible to have run snapcraft across several cores? [11:03] I'll tag jdstrand on that vlc+qt5 one [11:05] eraserpencil: by cores, you mean cpus? [11:05] eraserpencil: (cores is a rather loaded term...) [11:06] same as 'classic' for that matter [11:06] Chipaca: I guess cores, or threads. Not sure of the accurate term. [11:06] eraserpencil: are you doing container builds? [11:07] I thought CPU was the actual physical processor [11:07] nope [11:07] eraserpencil: snapcraft itself shouldn't be cpu-bound, and you should be able to pass any arguments the things inside it need to run in parallel [11:08] eraserpencil: make -j and so on [11:08] yeah [11:13] ahh kk [11:13] i'll give it a try [11:17] sorry, I might need a more detailed hot-to [11:17] how-to* [11:19] https://forum.snapcraft.io/t/qt-5-10-linkat-denials-broken-kde-snaps/5484 about the qt 5.10 issue [11:26] sitter: thanks [11:28] trying to get a minimal gtk theme for my app now [11:29] should i use https://github.com/snapcrafters/gtk-common-themes ? [11:29] or use stage-packages like here https://gitlab.gnome.org/Community/Ubuntu/gnome-software/blob/35d29d0b6188c6b1d60644af30d18f91e773eda2/snap/snapcraft.yaml#L163 [11:31] Chipaca: I was already planning on looking at that === pstolowski is now known as pstolowski|lunch [11:33] jdstrand: hi [11:34] a review for https://github.com/snapcore/core/pull/88 (trivial) would be great [11:34] PR core#88: hooks: make /lib64/ld64.so.2 relative to unbreak classic snaps on ppc64el [11:39] mvo: why does it break with an aboslute path in the symlink? [11:39] mborzecki: the go snap sets the elf interpreter to /snap/core/current/lib/ld64.so.2 [11:40] mborzecki: but that links to a libc6 that is not necessarily available on the system [11:40] mborzecki: eh, to an ld.so [11:40] jdstrand, geez ... stop fixin security holes ... i only updated my packageproxy snap on the weekend for new curl :P [11:41] PR core#88 closed: hooks: make /lib64/ld64.so.2 relative to unbreak classic snaps on ppc64el [11:43] PR snapd#5171 closed: ifacestate: unify reconnect and autoconnect methods [11:52] ogra_: it isn't me, it our awesome security team :) [11:52] cc ratliff ^ :) [11:52] :D [11:52] it is pretty cool seeing those go out :) [11:52] pedronis: hey :) [11:52] yeah, totally ! [11:53] I set up all my little snaps with LP builds so I could get those :) [12:17] heh udev reload && trigger makes x session cry [12:42] mborzecki, yeah, dont do that ... you can limit trigger to certain subsystems [12:42] (forgot what the option ws called ...) [12:44] ogra_: snapd does it currently when a snap is installed and it comes with some udev rules, it's control -R && trigger, i suspect it's when the x session may occasionally die as it happened on me a coulpe of times already [12:44] there's a zoo of filtering options to trigger but we aren't using them [12:45] hm maybe interface should specify a subsystem at least [12:53] Chipaca: do you have an opinion on #5134? [12:53] PR #5134: Shrink image generated with snap prepare [12:53] mvo: let me look [12:54] ah. it's green now? i'll look properly then :-) [12:55] mborzecki, well, snapd should inspect what subsystem the rules are for and only re-trigger that one ... blindly re-running all rules and uevents (which is what trigger does) can dremove and re-add devices ... xorg might simply not expect that [12:55] -d [12:56] mborzecki, it can get really nasty if udev decides to re-init your HDDs [12:56] (because you didnt exclude the block devices) === pstolowski|lunch is now known as pstolowski [12:57] Chipaca: not sure if it is, I merged master and addressed the review from zyga [12:57] Chipaca: but it does lok interessting [12:57] ogra_: hehe, it does trigger the disks to spin up, also yday my sound card went away, pulseaudio died and pcspkr started working instead [12:57] yeah [12:58] well, at least there's something to investigate now [13:02] IMO the question about udev is that it fails -sometimes- [13:02] Why is that? [13:03] zyga: Are you holiday? :) [13:03] on [13:03] Yes [13:03] zyga: Doesn't look like it! [13:03] :P [13:03] Heheh [13:03] Taking a break [13:03] We arrived at 2am [13:03] And woke up early [13:06] PR snapcraft#2140 opened: lp 1768233 workaround for plainbox_provider plugin [13:57] Is a "classic" confinement snap just classic in the sense that it runs unconfined as the user when they load the app or does it also let the package maintainer run scripts as root like a .deb or similar? [14:09] it seems override-build is what i'm looking for [14:10] maybe i should put after: [desktop-gtk2] in a specific part [14:11] cause everytime i clean my snap the build of gtk take so long [14:33] my snap graphics-debug-tools-bboozzoo has been flagged for manual review because i'm not shipping *.desktop files, can someone approve it? [14:34] mborzecki: sure [14:34] heh installing & removing this snap, pcspkr is back :) [14:34] mvo: thanks! [14:35] mborzecki: there you go [14:35] mvo: ta [14:38] Chipaca: do you still have that nvidia laptop? [14:40] PR snapd#5172 closed: cmd/snap-confine, interfaces/opengl: allow access to glvnd EGL vendor files [14:47] PR snapd#5173 opened: snap: some doc comments fixes and additions [15:11] mborzecki: i do [15:11] Chipaca: is it on 18.04? [15:15] Chipaca: your input on #5173 would be appreciated (it's small but interesting, apparently) [15:16] ++ [15:16] PR #5173: snap: some doc comments fixes and additions [15:17] niemeyer: and jdstrand: I've updated the optical-drive write support PR I filed - take a look when you get a break from other things: https://github.com/snapcore/snapd/pull/4369 [15:17] PR #4369: add write permission to optical-drive interface [15:17] yes, I'm looking at it now [15:17] \o/ [15:18] the tests pass locally (unrelated tests elsewhere are broken but the tests on the optical-drive interface pass) [15:22] I can't decide whether I really love golang or whether it is too different for me to understand properly :-p [15:23] jdstrand: heads up! I added a task for click-reviewers-tools for bug 1771840 [15:23] Bug #1771840: snap upload rejected with "refresh-timer" interface attribute [15:24] kyleN: ^^ relevant to you as well [15:24] ack [15:29] roadmr: I'll have something for you a bit later [15:29] yay jdstrand \o/ thanks [15:39] * cachio_ lunch [15:41] pedronis: all the +1's [15:41] pedronis: if you see a message about a '.' at the end, i deleted it; i can't read diff :-) [16:03] jdstrand: looks like I might be dereferencing a pointer somehow - my golang probably sucks :-p `if err := plug.Attr("write", &write); err == nil && write == true {` <-- I think `write` is a nil pointer here [16:04] I can change the `write == true` test to put it inside the block as a nested `if`. That should fix it? [16:05] PR core#38 closed: Add another pi-config option [16:05] PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build [16:06] PR core#38 opened: Add another pi-config option [16:06] PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build === pstolowski is now known as pstolowski|afk [16:44] diddledan: if write were a pointer, it wouldn't compile [16:44] it's ok, jdstrand pointed out a way to eliminate the whole block in the github comments :-) [16:44] heh [17:19] PR snapcraft#2141 opened: jhbuild plugin: allow running as 'root' [17:19] damn that guy, diddledan, he's a nutter [17:20] too many commas [17:20] * diddledan tries again [17:20] damn that guy diddledan, he's a nutter! [20:55] diddledan: thanks for that jhbuild fix! [21:13] PR snapd#5174 opened: interfaces/default,process-control: miscellaneous signal policy fixes === matteo| is now known as matteo [22:54] PR snapd#5175 opened: systemd: mock useFuse() so testsuite passes in container via lxd snap