| popey | kyrofa: 2.35 deb worked for now, thanks! :D | 00:26 |
|---|---|---|
| === jamesh_ is now known as jamesh | ||
| mup | PR snapcraft#1862 closed: zip: support extracting non-unix zip files <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1862> | 00:56 |
| Mert | Hi guys | 02:26 |
| === Mert is now known as Guest80198 | ||
| Guest80198 | Is core_3748 bugged? | 02:27 |
| Guest80198 | On manjaro i can't mount core-3748.= | 02:28 |
| Guest80198 | if you know the solution, can you email me? d_mert@hotmail.com | 02:30 |
| Guest80198 | have a good day | 02:30 |
| mup | Issue snapcraft#1668 closed: Bring in newer ld-linux and glibc libraries <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1668> | 02:56 |
| mup | Issue snapcraft#1669 closed: patchelf with ld-linux from the future <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1669> | 02:56 |
| mup | PR snapcraft#1850 closed: pluginhandler: patch and handle elf files on glibc mismatch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1850> | 02:56 |
| mborzecki | morning | 05:58 |
| letmutx | is xfce available through snaps? i tried uappstore but couldn't find it. | 06:25 |
| zyga-ubuntu | re | 07:24 |
| mborzecki | zyga-ubuntu: morning | 07:34 |
| mvo_ | good morning zyga-ubuntu and mborzecki | 07:41 |
| mborzecki | mvo_: hey, you have earned a _ :) | 07:44 |
| === mvo_ is now known as mvo | ||
| mborzecki | seems like fedora prepare is failing again | 07:47 |
| zyga-ubuntu | yes, consistently so | 07:48 |
| mvo | :( | 07:49 |
| mvo | time for manual again then | 07:49 |
| mborzecki | mvo: will you do it or should i? | 07:53 |
| mvo | mborzecki: please go ahead | 07:54 |
| mborzecki | ok | 07:54 |
| mvo | ta | 07:54 |
| zyga-ubuntu | mvo: idea | 07:55 |
| zyga-ubuntu | mvo: actually, scratch that idea :/ | 07:55 |
| mvo | zyga-ubuntu: that was a quick ide | 07:55 |
| mvo | a | 07:55 |
| zyga-ubuntu | yeah, nothing like talking to oneself to notice something is wrong | 07:56 |
| mvo | :) | 07:56 |
| * mvo hugs zyga-ubuntu | 07:56 | |
| mup | PR snapd#4474 opened: spread: switch fedora-26-64 back to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4474> | 07:57 |
| zyga-ubuntu | mborzecki: bonus points if you collect the log and talk to #linode people on the other IRC network | 07:59 |
| zyga-ubuntu | (OFTC) | 07:59 |
| kalikiana | good morning, snappy | 08:02 |
| mborzecki | kalikiana: morning | 08:06 |
| zyga-ubuntu | mvo: ok, I finished other prep work and I'm setting up tests on dragon now | 08:07 |
| mvo | zyga-ubuntu: ta | 08:07 |
| zyga-ubuntu | mvo: all tests or just main? | 08:11 |
| zyga-ubuntu | mvo: just to be clear, from release/2.30, run all the tests | 08:12 |
| mvo | zyga-ubuntu: yeah, correct | 08:12 |
| zyga-ubuntu | started | 08:12 |
| mvo | zyga-ubuntu: some failures are know, iirc security-device-cgroups-serial-port fails because there is not the right serial port on some boards. cachio would know for certain | 08:13 |
| mup | PR snapd#4469 closed: tests: add hard-coded fully expired macaroons to run related tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4469> | 08:18 |
| pstolowski | mornings! | 08:18 |
| zyga-ubuntu | hey o/ | 08:18 |
| zyga-ubuntu | mvo: 141 tests to go, that's not that many | 08:24 |
| mvo | zyga-ubuntu: yeah, but each takes ~1min or so :/ | 08:27 |
| mvo | zyga-ubuntu: at leat on the pi it takes a couple of hours | 08:27 |
| letmutx | is xfce available through snaps? i tried uappstore but couldn't find it. | 08:31 |
| mborzecki | and probably 1h just for automake & configure in cmd :) | 08:33 |
| zyga-ubuntu | so far so good, 6th test in progress | 08:34 |
| zyga-ubuntu | hmm | 08:36 |
| zyga-ubuntu | has anyone created a google calendar and tried to add a hangout to it | 08:36 |
| zyga-ubuntu | it seems this option is gone now | 08:36 |
| pedronis | mvo: hi, I reviewed #4356 (yesterday got a bit distracted) | 08:44 |
| mup | PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356> | 08:44 |
| zyga-ubuntu | mvo: ~~12 tests out of 141, each test really takes minutes | 08:49 |
| zyga-ubuntu | I'll grab a coffee | 08:49 |
| zyga-ubuntu | jamesh: around? | 08:49 |
| jamesh | zyga-ubuntu: hi | 08:49 |
| zyga-ubuntu | jamesh: we'll probably jump into a standup HO as I cannot add HO to the event anymore | 08:50 |
| zyga-ubuntu | jamesh: I'll share the link in a moment | 08:50 |
| mvo | pedronis: thank you, I have a look as soon as I have some spectre releated stuff under control | 08:52 |
| zyga-ubuntu | niemeyer: we're going to use the standup HO | 08:58 |
| mborzecki | btw. feel sorry for the kernel team: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742323 it's on HN: https://news.ycombinator.com/item?id=16118858 | 08:59 |
| mup | Bug #1742323: Meltdown Update Kernel doesnt boot <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Confirmed for jsalisbury> <linux (Ubuntu Xenial):Confirmed for jsalisbury> <https://launchpad.net/bugs/1742323> | 08:59 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | mborzecki: i guess 10 retries wasn't enough for the fedora thing | 09:04 |
| Chipaca | ¯\_(ツ)_/¯ i wanted to push another commit anyway | 09:04 |
| mvo | pedronis: thanks, review looks very good | 09:15 |
| mvo | Pharaoh_Atem: hey, a while ago you mentioned fedora using a more fine grained architecture description. can you point me somewhere where I can learn more about this? | 09:16 |
| Chipaca | mvo: why am i not making 'snap pack' run validateContainer? | 09:29 |
| mvo | Chipaca: indeed, why don't you? as a warning and with an option to disable, right? | 09:29 |
| pedronis | Chipaca: indeed :) | 09:29 |
| mvo | Chipaca: I mean, it will not make snap pack fail, right? | 09:29 |
| Chipaca | mvo: why wouldn't it? | 09:30 |
| pedronis | we might have some tests that abuse stuff | 09:30 |
| Chipaca | *shocked* | 09:30 |
| pedronis | but I don't think it should be just a warning | 09:30 |
| pedronis | it should be error | 09:30 |
| pedronis | or nothing | 09:30 |
| mvo | Chipaca: hm, right, it won't even install so … +1 for fail | 09:30 |
| mvo | lets see if tests survive this ,) | 09:31 |
| Chipaca | mvo: maybe in a separate PR though :-) | 09:31 |
| mvo | again +1 | 09:31 |
| * Chipaca is adding a spread test to 4464 and then hopes to land it | 09:32 | |
| seyeongkim | hello, is there a way to install older revision of core snap? | 09:38 |
| mborzecki | haha so the snap store is returning 418 'I'm a teapot'? | 09:39 |
| Chipaca | mborzecki: and does GET give you coffee, as per spec? | 09:42 |
| mborzecki | just the teapot, the rest is DIY | 09:43 |
| mup | PR snapd#4475 opened: overlord/snapstate: for Enable's tasks refer to the first task with snap-setup, do not duplicate <Created by pedronis> <https://github.com/snapcore/snapd/pull/4475> | 09:50 |
| pedronis | small PR cleaning up an oddity I noticed recently ^ | 09:51 |
| Chipaca | pedronis: a space oddity? | 09:57 |
| pedronis | Chipaca: silly you :) | 10:01 |
| * Chipaca nods | 10:01 | |
| Chipaca | pedronis: in my defense, i'm learning it on the guitar :-) | 10:03 |
| pedronis | Chipaca: it's fine, it would have been funnier if it was indeed a space problem, but alas we use go fmt | 10:05 |
| pedronis | though there is always shell and yaml to commit space sins | 10:06 |
| Chipaca | pedronis: :-) | 10:22 |
| zyga-ubuntu | re | 10:27 |
| zyga-ubuntu | mvo: we're at 59/141 now | 10:28 |
| zyga-ubuntu | mvo: no issues yet | 10:28 |
| mup | PR snapd#4474 closed: spread: switch fedora-26-64 back to manual <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4474> | 10:29 |
| brunosfer | Chipaca: could you tell me how can I make curl requests to the snapcraft API the same way you told me on the localhost? | 10:33 |
| brunosfer | Chipaca: I want to make a "snap find" to the public API... | 10:34 |
| mvo | zyga-ubuntu: great, pi3 is finished here, I'm doing p2 now | 10:38 |
| zyga-ubuntu | mvo: cool, I'll let you know when something changes | 10:38 |
| Chipaca | brunosfer: it's a little out of date, but https://github.com/snapcore/snapd/wiki/REST-API might be a good place to start | 10:38 |
| brunosfer | Chipaca: Thanks! | 10:39 |
| mborzecki | mvo: how long did it take? | 10:40 |
| * kalikiana taking a break, too much staring at a screen :-/ | 10:51 | |
| mvo | mborzecki: oh, sorry, didn't see the question - pi3 took around 2.5h | 11:00 |
| Chipaca | mborzecki: mvo: could one of you mark my #4464 as 'changes requested' please so it doesn't get merged for a bit? | 11:03 |
| mup | PR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464> | 11:03 |
| Chipaca | i just realised something needs fixing, but i don't want to close it and lose the spread test run | 11:03 |
| Chipaca | i'm going to go take a break, bbiab | 11:04 |
| mborzecki | Chipaca: marked | 11:04 |
| Chipaca | thanks | 11:05 |
| zyga-ubuntu | error: cannot list snaps: cannot list local snaps! cannot find installed snap "classic" at revision 26 | 11:18 |
| zyga-ubuntu | mvo: that was | 11:18 |
| zyga-ubuntu | 2018/01/11 12:14:55 Error executing external:ubuntu-core-16-arm-64:tests/main/listing : | 11:18 |
| zyga-ubuntu | mvo: it's still going, 81/141 now | 11:18 |
| mvo | zyga-ubuntu: hm, that looks strange, we may need to re-run this one test | 11:21 |
| mvo | zyga-ubuntu: cachio told me the board tests are not always 100% reliable, we don't run them often enough :/ he apparently has to re-run them sometimes | 11:22 |
| ogra | mvo, did you notice that your copre snap build failed ? | 11:22 |
| ogra | rm: cannot remove '/var/lib/apt/lists/': Is a directory | 11:22 |
| ogra | rm: cannot remove '/var/lib/apt/lists/partial': Is a directory | 11:22 |
| ogra | E: config/hooks/12-add-foreign-libc6.chroot failed (exit non-zero). You should check for errors. | 11:22 |
| ogra | seems your -print 0 re-ordering isnt liked | 11:24 |
| zyga-ubuntu | mvo: sure, I can re run | 11:24 |
| mvo | ogra: meh, sucks. I have a look | 11:24 |
| zyga-ubuntu | mvo: FYI I'm talking with linode operators about fedora issues and I'm using spread 70 to test | 11:24 |
| mvo | ogra: slightly strange on my artful this shows the right result. I guess I need to double check on xenial | 11:25 |
| ogra | yeah, it really shouldnt do any harm | 11:26 |
| ogra | (but if it does, the manpages and docs removal will have the same issue | 11:26 |
| ogra | ) | 11:26 |
| mvo | ogra: yeah, the "funny" part is that i386 build fine | 11:27 |
| ogra | heh | 11:27 |
| ogra | well, then it seems to work with the docs at least | 11:27 |
| ogra | other topic ... do we have auto-connecting of interfaces from the gadget already ... and do we have it documented somewhere) | 11:28 |
| * ogra bets pedronis would know such stuff ^^ | 11:29 | |
| zyga-ubuntu | mvo: fedora uses a random mirror from a redirectory | 11:29 |
| zyga-ubuntu | *redirector | 11:29 |
| zyga-ubuntu | mvo: I'm running a test that shows what's going on, I already saw some mirrors not responding (and being switched over to another one) | 11:30 |
| zyga-ubuntu | mvo: but a bad sequence will probably explain the set of failures we've seen | 11:30 |
| zyga-ubuntu | mvo: probably spectre/meltdown result | 11:30 |
| zyga-ubuntu | mvo: we can pin to a specific mirror if we want | 11:30 |
| zyga-ubuntu | mvo: I'm also asking if linode plans to offer one | 11:31 |
| mvo | ta | 11:32 |
| zyga-ubuntu | https://pastebin.ubuntu.com/26365704/ | 11:36 |
| zyga-ubuntu | we'll need gustavo to open a ticket | 11:36 |
| zyga-ubuntu | I'll prepare the contents | 11:36 |
| mvo | hu? what checksum is that | 11:36 |
| mvo | aha, its just 3 | 11:37 |
| zyga-ubuntu | mvo: https://forum.snapcraft.io/t/issues-with-fedora-mirror/3489 for tracking | 11:44 |
| zyga-ubuntu | Son_Goku: ^ | 11:52 |
| Son_Goku | zyga-ubuntu: what happens when you try to curl the URL from within the Linode system? | 11:53 |
| zyga-ubuntu | Son_Goku: it's random, it works most of the time in a loop | 11:53 |
| zyga-ubuntu | Son_Goku: it jut doesn't _always_ work | 11:53 |
| zyga-ubuntu | Son_Goku: I'll try curl in a sec | 11:53 |
| zyga-ubuntu | Son_Goku: running a test with "dnf install -y -4" now | 11:53 |
| zyga-ubuntu | Son_Goku: over ipv4 only | 11:53 |
| Son_Goku | ah | 11:53 |
| Son_Goku | metadata fetching is done by a library called librepo | 11:55 |
| Son_Goku | https://github.com/rpm-software-management/librepo | 11:55 |
| Son_Goku | if there's a bug in mirror selection for metadata fetching, that's where to look | 11:55 |
| Son_Goku | also, it's not _random_ per se | 11:56 |
| zyga-ubuntu | Son_Goku: did you see https://pastebin.ubuntu.com/26365704/ ? | 11:56 |
| Son_Goku | the Fedora MirrorManager returns a list of valid, fast, nearby mirrors based on the location it derives from the initial request | 11:56 |
| Son_Goku | yeah | 11:56 |
| Son_Goku | those mirrors come from the metalink | 11:57 |
| zyga-ubuntu | *all mirrors tried* sounds bad when it doesn't work | 11:57 |
| Son_Goku | something fishy is going on | 11:57 |
| Son_Goku | makes me think there might be an issue in librepo | 11:57 |
| Son_Goku | but *shrugs* | 11:57 |
| Son_Goku | btw, you can look in /var/log/dnf.librepo.log, too | 11:57 |
| zyga-ubuntu | thanks, I'll check | 11:58 |
| Son_Goku | even when DNF isn't in verbose mode, all the output for metadata fetching is there | 11:58 |
| mup | PR core#72 opened: live-build: fix order of -print0 in find <Created by mvo5> <https://github.com/snapcore/core/pull/72> | 12:02 |
| zyga-ubuntu | -4 seems to have helped | 12:02 |
| mup | PR snapd#4475 closed: overlord/snapstate: for Enable's tasks refer to the first task with snap-setup, do not duplicate <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4475> | 12:02 |
| mup | PR snapd#4382 closed: cmd/snap: show header/footer when `snap find` is used without arguments <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4382> | 12:04 |
| mup | PR snapd#4423 closed: snap: provide more meaningful errors for installMany and friends <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4423> | 12:04 |
| mup | PR snapd#4476 opened: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476> | 12:10 |
| zyga-ubuntu | mvo: another test failed, I'm at 110/141 now) | 12:29 |
| pedronis | ogra: we don't , but it should get prioritized soon (for value of soon), is a prereq for other work we need to do | 12:34 |
| ogra_ | pedronis, ack ... and helps to get rid of some hacks in products too :) | 12:35 |
| pedronis | ogra_: topic is here: https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 | 12:35 |
| ogra_ | yeah, i just found it too :) | 12:35 |
| pedronis | ogra_: to be fair it was also conflicting with interface hooks work, but that is getting close to done | 12:37 |
| matiasb | niemeyer, sergiusens, o/ for when you get a few minutes, it would be great if we can agree on the field name/format for the appstream id in snap.yaml (https://forum.snapcraft.io/t/support-for-appstream-id/2327/) | 12:41 |
| matiasb | happy to schedule a call if that helps too, we need some definition to get that started server-side | 12:41 |
| zyga-ubuntu | Pharaoh_Atem: is there any official non-mirror archive I can hit? | 12:45 |
| sergiusens | matiasb I agree. I am fine with Robert's proposal | 12:55 |
| matiasb | sergiusens, that would be having an optional 'appstreeam_id' field, per app entry, right? the extractors would handle setting that value? or would it be a manual thing? (just curious) | 12:59 |
| mvo | zyga-ubuntu: ok, if you could pastebin the full run that would be great. some failures (bluetooth for example) or "ok" as the device just does not have the hardware | 12:59 |
| * kalikiana going for lunch in ~10 | 13:22 | |
| * kalikiana trying to finish these tedious grammar test cases til then... | 13:22 | |
| zyga-ubuntu | mvo: https://pastebin.ubuntu.com/26366173/ | 13:32 |
| zyga-ubuntu | still running | 13:32 |
| pedronis | Chipaca: you could use -ls and -lls together (it gets silly) | 13:36 |
| Chipaca | pedronis: yes | 13:36 |
| brunosfer | Hi guys, does anyone knows how can I change the default path when downloading a snap? | 13:45 |
| zyga-ubuntu | mvo: it's done | 13:46 |
| zyga-ubuntu | - external:ubuntu-core-16-arm-64:tests/main/listing | 13:46 |
| zyga-ubuntu | - external:ubuntu-core-16-arm-64:tests/main/prepare-image-uboot | 13:46 |
| zyga-ubuntu | those two failed | 13:46 |
| zyga-ubuntu | brunosfer: when you snap install or when you snap download? | 13:47 |
| zyga-ubuntu | brunosfer: this is not configurable AFAIR | 13:47 |
| zyga-ubuntu | brunosfer: what's the background, what are you trying to, maybe we can do something else | 13:47 |
| zyga-ubuntu | mvo: ok, I'll grab some water and let's talk | 13:50 |
| zyga-ubuntu | mvo: shall I re-run those two? the failure logs are in the pastebin | 13:50 |
| mvo | zyga-ubuntu: this looks not too bad, please re-run the two just for kicks and pastebin the full run | 13:50 |
| zyga-ubuntu | mvo: sure, full run (1st try) is here now: https://pastebin.ubuntu.com/26366247/ -- i'll start the two tests and get back to you with results | 13:51 |
| Son_Goku | zyga-ubuntu: the main fedora URL is dl.fedoraproject.org | 13:52 |
| Son_Goku | download.fedoraproject.org is a redirector for things that don't support mirrorlists or metalinks | 13:52 |
| brunosfer | zyga-ubuntu: When I snap download. | 13:52 |
| mvo | zyga-ubuntu: thank you | 13:52 |
| brunosfer | zyga-ubuntu: The problem is that I want to run a cmd line downloading a snap and I want to save it in a specific directory rather than a default one. | 13:53 |
| zyga-ubuntu | Son_Goku: thanks, that's useful | 13:53 |
| zyga-ubuntu | brunosfer: AFAIR it just downloads to the current directory, | 13:54 |
| zyga-ubuntu | Son_Goku: that's working, I'll run a small loop to see if that stays operational | 13:57 |
| * pstolowski lunch | 14:00 | |
| mup | PR core#72 closed: live-build: fix order of -print0 in find <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/72> | 14:04 |
| brunosfer | zyga-ubuntu: I think it downloads for some environment default value to home, because even when I make the "cd" command before it just keeps downloading to the home folder. | 14:09 |
| niemeyer | matiasb, sergiusens: Will catch up with that discussion this afternoon.. | 14:10 |
| niemeyer | matiasb, sergiusens: We can then have a call if necessary and you are available | 14:11 |
| matiasb | niemeyer, sergiusens, sure, I'm available today/tomorrow, just let me know | 14:21 |
| pedronis | niemeyer: I was thinking, if we use these just as defaults we consume them at clear points (install, or seed), so I don't think we need to keep track of timestamps | 14:26 |
| niemeyer | pedronis: That's easier to reason about, and also makes the seed more even with other behavior.. nice | 14:27 |
| mborzecki | off to pick up the kids | 14:31 |
| kalikiana | re | 14:42 |
| mup | PR snapcraft#1864 opened: debian/control: Add patchelf to Depends: <Created by flexiondotorg> <https://github.com/snapcore/snapcraft/pull/1864> | 14:46 |
| mup | PR snapd#4441 closed: snap: add usage hints in `snap download` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4441> | 14:53 |
| Chipaca | brunosfer: are you talking about 'snap download'? | 14:54 |
| zyga-ubuntu | mvo: same failures | 14:59 |
| elopio | hello. | 15:00 |
| mvo | zyga-ubuntu: could you flash the image again? the listing one is confusing, I'm checking the prepare-image one now | 15:00 |
| zyga-ubuntu | sorry, I fell asleep | 15:00 |
| zyga-ubuntu | mvo: sure, working | 15:04 |
| mvo | zyga-ubuntu: ta! | 15:06 |
| mvo | zyga-ubuntu: both failures are odd, the second less so but the first one very much so | 15:07 |
| mvo | zyga-ubuntu: as the first test does not install classic | 15:07 |
| zyga-ubuntu | mvo: I just realized I didn't actually flash the image earlier, it was running on edge core/kernel | 15:07 |
| zyga-ubuntu | mvo: I need to build an image for it and the copy it over | 15:07 |
| mvo | zyga-ubuntu: please use the image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/ | 15:08 |
| mvo | zyga-ubuntu: thats the image we need to test | 15:09 |
| zyga-ubuntu | mvo: sure thing | 15:09 |
| mvo | zyga-ubuntu: thank you! | 15:09 |
| zyga-ubuntu | sorry for the confusion, I'll hook it up ASAP | 15:09 |
| mvo | zyga-ubuntu: sorry that I take up your time :( | 15:09 |
| zyga-ubuntu | mvo: no worries :) feels like a good time to use the board once in a while | 15:10 |
| mup | PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 15:20 |
| mup | PR # closed: core#38, core#67, core#69, core#70, core#71 | 15:21 |
| mup | PR # closed: core#38, core#67, core#69, core#70, core#71 | 15:24 |
| mup | PR # closed: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4326, snapd#4329, snapd#4336, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357, snapd#4358, snapd#4365, snapd#4369, snapd#4380, | 15:24 |
| mup | snapd#4387, snapd#4399, snapd#4401, snapd#4416, snapd#4418, snapd#4419, snapd#4424, snapd#4425, snapd#4440, snapd#4443, snapd#4448, snapd#4449, snapd#4459, snapd#4464, snapd#4471, snapd#4472, snapd#4473, snapd#4476 | 15:24 |
| kalikiana | sergiusens: to hangout or not to hangout? which will it be? :-) | 15:24 |
| mup | PR # opened: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4326, snapd#4329, snapd#4336, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357, snapd#4358, snapd#4365, snapd#4369, snapd#4380, | 15:25 |
| mup | snapd#4387, snapd#4399, snapd#4401, snapd#4416, snapd#4418, snapd#4419, snapd#4424, snapd#4425, snapd#4440, snapd#4443, snapd#4448, snapd#4449, snapd#4459, snapd#4464, snapd#4471, snapd#4472, snapd#4473, snapd#4476 | 15:25 |
| mup | PR # closed: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4326, snapd#4329, snapd#4336, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357, snapd#4358, snapd#4365, snapd#4369, snapd#4380, | 15:27 |
| mup | snapd#4387, snapd#4399, snapd#4401, snapd#4416, snapd#4418, snapd#4419, snapd#4424, snapd#4425, snapd#4440, snapd#4443, snapd#4448, snapd#4449, snapd#4459, snapd#4464, snapd#4471, snapd#4472, snapd#4473, snapd#4476 | 15:27 |
| mup | Issue # closed: snapcraft#100, snapcraft#1438, snapcraft#1440, snapcraft#1441, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1455, snapcraft#1456, snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1463, snapcraft#1465, snapcraft#1467, snapcraft#1468, | 15:28 |
| mup | snapcraft#1469, snapcraft#1476, snapcraft#1477, snapcraft#1502, snapcraft#1658, snapcraft#1659, snapcraft#1660, snapcraft#1665, snapcraft#1670, snapcraft#1671, snapcraft#1672, snapcraft#1673, snapcraft#1674, snapcraft#1675, snapcraft#1676, snapcraft#1677, snapcraft#1678, snapcraft#1679, | 15:28 |
| mup | snapcraft#1680, snapcraft#1681, snapcraft#1682, snapcraft#1683, snapcraft#1684, snapcraft#1685, snapcraft#1688, snapcraft#1689, snapcraft#1690, snapcraft#1691, snapcraft#1692, snapcraft#1696, snapcraft#1697, snapcraft#1701, snapcraft#1704, snapcraft#1705, snapcraft#1706, snapcraft#1707, | 15:28 |
| mup | snapcraft#1708, snapcraft#1714, snapcraft#1715, snapcraft#1751, snapcraft#1753, snapcraft#1794, snapcraft#1819, snapcraft#1828 | 15:28 |
| mup | PR # closed: snapcraft#1564, snapcraft#1617, snapcraft#1649, snapcraft#1720, snapcraft#1746, snapcraft#1769, snapcraft#1800, snapcraft#1836, snapcraft#1844, snapcraft#1846, snapcraft#1852, snapcraft#1853, snapcraft#1855, snapcraft#1857, snapcraft#1864 | 15:28 |
| zyga-ubuntu | mvo: github down | 15:29 |
| zyga-ubuntu | mvo: I'll get you the results later today, I need a fresh SD card (in ~40 minutes) | 15:29 |
| kalikiana | hrm... 503 not allowd on GitHub?! this is weird | 15:31 |
| kalikiana | I guess GitHub is really kinda broken today | 15:33 |
| mvo | zyga-ubuntu: ta | 15:34 |
| mvo | zyga-ubuntu: yeah github down makes me unhappy | 15:34 |
| zyga-ubuntu | mvo: coudn't github be down when I was sleeping | 15:34 |
| zyga-ubuntu | couldn't* | 15:34 |
| kalikiana | mvo: it's not completely down. it's more like launchpad on a normal day ;-) | 15:40 |
| kalikiana | try a few more times and it kinda works | 15:40 |
| zyga-ubuntu | I will file a github bug report | 15:40 |
| zyga-ubuntu | the unicorn could use a few more images | 15:40 |
| zyga-ubuntu | it would make reloading funnier | 15:40 |
| zyga-ubuntu | "see the world they said" | 15:40 |
| kalikiana | haha, I was thinking the same actually | 15:40 |
| mvo | kalikiana: haha | 15:40 |
| mup | PR snapd#4477 opened: snapenv: add SNAP_ARCH_TRIPLET <Created by mvo5> <https://github.com/snapcore/snapd/pull/4477> | 15:42 |
| zyga-ubuntu | mvo: nice | 15:43 |
| zyga-ubuntu | mvo: question | 15:44 |
| zyga-ubuntu | mvo: are those values areally "universal" | 15:44 |
| zyga-ubuntu | mvo: I was thinking that this should be a function that takes a snap info as argument | 15:44 |
| kalikiana | wooot, arch triplet! awesome! | 15:44 |
| zyga-ubuntu | mvo: so that we can return the right values for say, debian and fedora | 15:44 |
| kalikiana | kyrofa: ^^ | 15:44 |
| zyga-ubuntu | mvo: if for any reason they actually don't mean the same thing | 15:44 |
| mvo | zyga-ubuntu: I was asking Son_Goku earlier about the fedora arch triplets but maybe he missed the message | 15:45 |
| zyga-ubuntu | mvo: and at the place where you call it you can easily pass the info | 15:45 |
| mvo | zyga-ubuntu: its tricky, in theory these triplets are whatever you tell your compiler they should be | 15:45 |
| zyga-ubuntu | mvo: then you can still use $SNAP_ARCH_TRIPLET all the time | 15:45 |
| zyga-ubuntu | and it just matches your base | 15:45 |
| zyga-ubuntu | mvo: right exactly that's why I think it should be base-bound | 15:45 |
| mvo | zyga-ubuntu: yeah, making them base-bound would probably the best, I need to learn more about the fedora world | 15:46 |
| zyga-ubuntu | mvo: it could even be a meta-data on base snap somewhere | 15:46 |
| zyga-ubuntu | mvo: but for now it's enough if this is the value we return for base-16 and base-18 | 15:46 |
| zyga-ubuntu | mvo: I suspect ikey might want to chime in too | 15:46 |
| mvo | zyga-ubuntu: +1 | 15:47 |
| mvo | zyga-ubuntu: yeah, getting input on this from more distros would be great, I wonder if they use /usr/lib/$arch at all (we only added this for multi-arch support for dpkg/apt) | 15:48 |
| * mvo is so ignorant :( | 15:48 | |
| zyga-ubuntu | mvo: not all | 15:48 |
| zyga-ubuntu | mvo: solus doesn't AFAIR | 15:48 |
| zyga-ubuntu | mvo: I have a swarm of VMs to check if you want to know | 15:48 |
| * zyga-ubuntu wishes to be exactly as ignorant as mvo ;-) | 15:49 | |
| mvo | zyga-ubuntu: I just checked with rpmfind.net and it seems like fedora uses /usr/lib/*.so which is interessting. so they really won't need SNAP_ARCH_TRIPLET anyway AFAICT | 15:50 |
| mvo | zyga-ubuntu: anyway, not important, please don't let me distract you | 15:50 |
| Son_Goku | mvo: hm? | 15:56 |
| mvo | Son_Goku: you told me at some point fedora is using more detailed architecture defintions - where can I read more about this | 15:57 |
| Son_Goku | https://github.com/rpm-software-management/rpm/blob/master/platform.in + https://github.com/rpm-software-management/rpm/blob/master/rpmrc.in | 15:57 |
| mvo | thanks Son_Goku | 15:58 |
| Son_Goku | also, insofar as debian-style multiarch deps, I've also got a PR proposed for rpm to support those fully: https://github.com/rpm-software-management/rpm/pull/360 | 15:58 |
| mup | PR rpm-software-management/rpm#360: elfdeps: Add full multiarch deps support <Created by Conan-Kudo> <https://github.com/rpm-software-management/rpm/pull/360> | 15:58 |
| Son_Goku | mvo: in Fedora, we do /usr/<triple> for foreign architectures for cross targets | 15:59 |
| Son_Goku | and the triple is defined as the triple coming from the compiler (gcc) | 15:59 |
| mvo | Son_Goku: sweet - will it be the same triple as the ones that debian/ubuntu uses (which are really just noramlized gnu ones)? | 15:59 |
| Son_Goku | mostly the same | 15:59 |
| Son_Goku | I think there's some differences w.r.t. ppc64 triples | 15:59 |
| Son_Goku | but it's been a while | 15:59 |
| mvo | Son_Goku: cool, that sounds very promising | 16:00 |
| mvo | Chipaca: thanks for your suggestion I think I call it normalizedGnuTriplet | 16:00 |
| Son_Goku | you can actually query this on rpm using 'rpm --target <arch> --eval "%_target_platform"' | 16:01 |
| Son_Goku | not sure if it triggers the correct mappings w.r.t. isa aliasing, but it gets you close | 16:02 |
| Chipaca | $ rpm --target amd64 --eval "%_target_platform" | 16:02 |
| Chipaca | rpm: --target: unknown option | 16:02 |
| Son_Goku | :) | 16:05 |
| * popey hugs mvo for https://github.com/snapcore/snapd/pull/4477 ( cc kyrofa ^) :D | 16:05 | |
| mup | PR #4477: snapenv: add SNAP_ARCH_TRIPLET <Created by mvo5> <https://github.com/snapcore/snapd/pull/4477> | 16:05 |
| Son_Goku | what version of rpm is there? | 16:05 |
| Son_Goku | (it worked on my Fedora 27 system with rpm 4.14, so...) | 16:05 |
| mvo | Son_Goku: what does it output for amd64,i386,armhf,arm64 on rpm (out of curiosity)? | 16:06 |
| Son_Goku | x86_64-redhat-linux-gnu, i386-redhat-linux-gnu (though fedora uses i686-redhat-linux-gnu), <notvalid>, <notvalid> | 16:07 |
| Son_Goku | I suppose I should add an arm64 -> aarch64 alias at some point | 16:07 |
| * zyga-ubuntu hands mvo his green tea for the evening | 16:07 | |
| Son_Goku | and armhf is not a real thing | 16:07 |
| Son_Goku | for Fedora, we have armv7hl-redhat-linux-gnu for our 32-bit arm arch | 16:07 |
| mvo | Son_Goku: hm, its using the vendor so they are not quite the same but close, we use x86_64-linux-gnu and i386-linux-gnu but I think thats ok | 16:07 |
| Chipaca | Son_Goku: I get that on 4.12.0.1 on ubuntu xenial, and 4.13.0-rc1 on fedora 24 | 16:08 |
| mvo | Son_Goku: woah, that one is totally different - do you have a 32bit arm with hardware float? | 16:08 |
| Son_Goku | iirc, debian never defined the vendor field, and it's easy enough to chop out when scanning triple | 16:08 |
| Son_Goku | mvo: yep | 16:08 |
| Son_Goku | armv7hl is our hardware float arch | 16:08 |
| Son_Goku | we've had armv6hl in the past | 16:08 |
| Son_Goku | we bumped to armv7hl about five years ago? | 16:09 |
| Son_Goku | we've also had armv5tl for non hfp before | 16:09 |
| zyga-ubuntu | mvo: you need to accept info argument | 16:09 |
| zyga-ubuntu | mvo: case closed | 16:09 |
| Son_Goku | mvo: rpm doesn't do basearches | 16:09 |
| Son_Goku | we have a map of those in DNF because we use it to organize our repos in Fedora: https://github.com/rpm-software-management/dnf/blob/master/dnf/rpm/__init__.py#L76-L102 | 16:10 |
| mvo | Son_Goku: aha, for those we use arm-linux-gnueabihf | 16:10 |
| Son_Goku | mvo: let me check our arm compiler triple | 16:10 |
| mvo | Son_Goku: sounds very much like this has to be base specific | 16:10 |
| Son_Goku | I think the arm-linux-gnueabihf is what our compiler says though | 16:10 |
| zyga-ubuntu | I'm waiting for a fresh SD card (alredy bought, will be here in 15 minutes) | 16:11 |
| zyga-ubuntu | and I fixed the fedora archive thing to point to dl.... | 16:11 |
| mvo | Son_Goku: that would be fantastic - does the compile include "redhat" in x86_64-linux-gnu ? or is that just for the rpms? | 16:11 |
| Son_Goku | no redhat in the triple on the filesystem | 16:12 |
| mvo | zyga-ubuntu: you got it delivered directly to you on the same day? nice | 16:12 |
| mvo | Son_Goku: yay | 16:12 |
| zyga-ubuntu | mvo: we should get some opensuse poeople | 16:12 |
| mvo | Son_Goku: so I think we the triplets are compatible, thats cool | 16:12 |
| zyga-ubuntu | mvo: yes, my wife's office is right next to a shopping centre with electronics store inside ^_^ | 16:12 |
| zyga-ubuntu | mvo: what would I do without her :-) | 16:12 |
| Son_Goku | rpm can query without vendor by doing `rpm --target <arch> --eval "%{_target_cpu}-%{_vendor}-%{_target_os}"` | 16:13 |
| Son_Goku | grr | 16:13 |
| Son_Goku | rpm can query without vendor by doing `rpm --target <arch> --eval "%{_target_cpu}-%{_target_os}"` | 16:13 |
| Son_Goku | %_target_platform is defined as "%{_target_cpu}-%{_vendor}-%{_target_os}" | 16:13 |
| mvo | zyga-ubuntu: hahaha, give her a *hug* | 16:13 |
| mvo | Son_Goku: cool, I think we are good then, thanks for all your input | 16:14 |
| Son_Goku | no problem | 16:14 |
| Son_Goku | we do need a more granular scheme for architectures in snaps itself | 16:14 |
| Son_Goku | but the on-filesystem thing is way simpler ;) | 16:14 |
| Son_Goku | mvo: looks like our compiler has arm-linux-gnueabi for hf | 16:15 |
| Son_Goku | not sure why the hf suffix is left off | 16:15 |
| Son_Goku | but otherwise identical | 16:15 |
| zyga-ubuntu | it's all a big mess | 16:15 |
| mvo | Son_Goku: yeah, thats slightly unfortuante | 16:15 |
| zyga-ubuntu | it'd be 100x better if we asked a homeless guy *consistently* instead of letting a crowd of technical people decide | 16:16 |
| mvo | Son_Goku: but that might indicate actually that the fedora arm is using soft float | 16:16 |
| ogra_ | SNAP_ARCH_TRIPLET !!! | 16:35 |
| ogra_ | oh i love that ! | 16:35 |
| brunosfer | Chipaca: Yes I was talking about download. I solved the problem by sending an output cmd using go "cd /home/user/myfolder && snap download snapname" | 16:35 |
| mvo | zyga-ubuntu: thinking about what Neal said, this might indicate a bigger problem, at least with arm. if fedora uses soft-float and we use hard-float we might actually ship arm snaps build on ubuntu with hard-float to fedora software-float device that will not work | 16:35 |
| Chipaca | brunosfer: ah, i was going to say, it always downloads to the current directory | 16:36 |
| brunosfer | Chipaca: However I intended to use a cleaner solution... | 16:36 |
| zyga-ubuntu | mvo: will the kernel emulate that? | 16:36 |
| zyga-ubuntu | mvo: note that fedora arm is not widespread popular | 16:36 |
| mvo | ogra_: heh, it my most popular branch so far ;) | 16:36 |
| zyga-ubuntu | mvo: so maybe it's a temporary issue | 16:36 |
| brunosfer | Chipaca: Yeah, when zyga told me it would always download to the current directory I did the workaround... | 16:36 |
| Chipaca | brunosfer: i guess nobody has needed this, which is why it doesn't have an --output-dir=<...> option | 16:36 |
| mvo | zyga-ubuntu: may well be, its nothing new, we just may need to keep it in the back of our heads | 16:36 |
| zyga-ubuntu | ack | 16:37 |
| brunosfer | Chipaca: Yeah, It would be a nice to have ;) | 16:37 |
| ogra_ | mvo, feaodra "arm" is equivalent to armel i think ... while they use "armhfp" a name for v7 and that should be hardfloat | 16:39 |
| ogra_ | *as name | 16:39 |
| mup | PR snapd#4478 opened: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4478> | 16:39 |
| mvo | ogra_: ah, cool. that explains it | 16:41 |
| mborzecki | iirc armv7 already supports vfp, that should make the non -m variants hf | 16:46 |
| kyrofa | elopio, alright, had a quick call, but now I'm settled | 16:47 |
| zyga-ubuntu | mborzecki: updated | 16:47 |
| elopio | kyrofa: I think I replied to all your comments, but I was left thinking about the metadata. | 16:48 |
| kyrofa | elopio, come up with any brilliant thoughts? | 16:48 |
| elopio | kyrofa: (maybe you thought about this before but) what if we move the map from desktop_file_id to desktop_file_path earlier, rigth after the id is read from the xml? | 16:49 |
| elopio | so, what we will have in the metadata object are paths. If there are other types of sources, they have to convert their representation to paths too | 16:49 |
| mborzecki | zyga-ubuntu: i'd leave the retries there, but otherwise +1 | 16:49 |
| kyrofa | elopio, that seems more generic indeed | 16:50 |
| zyga-ubuntu | mborzecki: let's see if this passes | 16:51 |
| kyrofa | Was your thought to make it scale better across different metadata extraction methods (beyond appstream)? | 16:51 |
| zyga-ubuntu | mborzecki: I think the retries didn't really work | 16:51 |
| zyga-ubuntu | mborzecki: and they were there for the precisely same reason I'm hacking this now | 16:51 |
| elopio | kyrofa: well, not to leak the details of the extractor to the metadata object. | 16:51 |
| kyrofa | elopio, yeah, I agree | 16:51 |
| elopio | kyrofa: should I do it before merge, or as a follow up? | 16:54 |
| kyrofa | elopio, let me think for a sec, /me take another look at the PR | 16:54 |
| kyrofa | Man it's hard to think here, I got so used to my quiet office | 16:55 |
| kyrofa | okay elopio what's in the appstream data is stuff like "com.example.test-app.desktop" | 16:57 |
| elopio | yes, a launchable of type desktop-id, is what they call it. | 16:58 |
| kyrofa | elopio, in meta, we assume that the desktop file ends up installed in /usr/share or /usr/local/share | 16:58 |
| elopio | kyrofa: that's what the xdg specification says. | 16:58 |
| kyrofa | If we do that mapping sooner, you'll need to contend with the fact that your extractor is run multiple times, from different roots | 16:58 |
| elopio | on pull it will probably always fail, because the desktop file won't be on a usr/share dir on the repo | 16:59 |
| kyrofa | It's run during pull, in src/, and twice in build | 16:59 |
| elopio | but on build, it will find it most likely | 16:59 |
| kyrofa | Yeah that's what I'm driving at-- so far we've extracted actual data, this is the first time we're extracting paths | 16:59 |
| kyrofa | elopio, would it be ridiculous to embed the desktop file in the metadata? | 17:00 |
| elopio | kyrofa: an alternative would be to blindly build the two paths. Do not check if it exists, add the two possible locations, and leave the check to meta. | 17:00 |
| elopio | kyrofa: not ridiculous, but not nice. Our snapcraft.yaml takes paths, so the closer we get to that, the better IMO. | 17:01 |
| kyrofa | elopio, I want to be careful about subsequent steps reaching back into preceding steps, it breaks the lifecycle | 17:01 |
| kyrofa | But I feel like we're making some assumptions that the desktop file is actually installed and available in prime once we do the conversion | 17:02 |
| elopio | kyrofa: isn't that what the desktop keyword assumes too? | 17:03 |
| * kalikiana wrapping up for the day | 17:03 | |
| kyrofa | elopio, fair point | 17:03 |
| kyrofa | Yes | 17:03 |
| elopio | bye kalikiana | 17:03 |
| kyrofa | I'm stuck on the darn meta/gui ones for some reason | 17:03 |
| elopio | The icon implementation mapped nicely to the icon keyword on snapcraft.yaml. Not so much to the icon.png in snap/gui. | 17:04 |
| kalikiana | kyrofa: btw would be awesome if you could feast your eyes on https://github.com/snapcore/snapcraft/pull/1857#discussion_r160959367 and hopefully we're on the same page now. these tests are really tedious to go through :-D | 17:04 |
| mup | PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857> | 17:04 |
| elopio | I think that's ok for desktop too. | 17:04 |
| elopio | kyrofa: another alternative would be to run "find", instead of assume that it will be in /usr/share or /usr/local/share | 17:05 |
| kyrofa | kalikiana, what is this change? https://github.com/snapcore/snapcraft/pull/1857/files#diff-0f81cfd5e83dc1988a457bf45d0da9e1R103 | 17:06 |
| mup | PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857> | 17:06 |
| elopio | the problem here though is the crazy handling of - by desktop_file_id. They are turned into /, for some reason, so now to find the name we have to check also the parent dir. | 17:06 |
| elopio | or dirs, I guess you can have multiple -. | 17:06 |
| kyrofa | elopio, no, let's back up to our metadata | 17:06 |
| kyrofa | If we leave it as-is, no extraction method will ever be able to say "here's my desktop file." It'll have to put it in a predictable place (like /usr/share) and return an ID, which I think not everything will do | 17:07 |
| kyrofa | elopio, so I like the idea of mapping to paths for appstream earlier | 17:07 |
| kyrofa | And then assuming they're in prime once we're creating the snap.yaml seems the best we can do (of course, we can check and bail if necessary) | 17:08 |
| elopio | kyrofa: well, my idea was not to force the extractors to use desktop_file_id, but to add another attribute on metadata. But, I also like the idea of making appstream fit in the general case. | 17:08 |
| kyrofa | Then, the appstream extractor can look in /usr/share on its own to convert to a path | 17:08 |
| kyrofa | So all the appstream specific stuff is in the extractor instead of leaking, like you said | 17:09 |
| kyrofa | elopio, yeah, I say we define the metadata we want to use, and make appstream fit in there | 17:09 |
| kyrofa | elopio, but I also think it can be a follow-up | 17:09 |
| elopio | kyrofa: here's a thought. What if we extend the prime desktop step, to first search for whatever is in the desktop keyword. Then prepend usr/share and check again, and then prepend usr/local/share, and make a last check. | 17:09 |
| elopio | then on appstream, we only have to translate desktop_file_id to desktop_file_path_relative_to_xdg | 17:10 |
| elopio | that would be com.example.test-app.desktop -> com.example.test/app.desktop, easy. | 17:11 |
| kalikiana | kyrofa: hmmm did I flip the values? I guess I can check that | 17:11 |
| kyrofa | kalikiana, there should be no reason to change the tests other than making them change the host arch instead of the target arch (thank you for that) | 17:12 |
| kyrofa | elopio, wait, the desktop keyword is a path, is it not? | 17:13 |
| kalikiana | kyrofa: I don't see how that sentence can be true. The behavior isn't the same | 17:13 |
| elopio | kyrofa: yes. But I'll let you talk with kalikiana first. | 17:13 |
| kyrofa | kalikiana, the on statement works exactly the same way, but instead of using target arch, it now uses the host arch. No? | 17:14 |
| kalikiana | kyrofa: consider this example. changing just target to host will not work https://github.com/snapcore/snapcraft/pull/1857/files#diff-0f81cfd5e83dc1988a457bf45d0da9e1R141 | 17:15 |
| mup | PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857> | 17:15 |
| kyrofa | Why? | 17:15 |
| kyrofa | kalikiana, it's okay, I know you're EOD, I'll clone it and see if I can reproduce what you're talking about | 17:18 |
| kyrofa | elopio, anyway, the desktop key doesn't accept just a file name-- it doesn't search directories. Right? | 17:20 |
| kyrofa | (honest question, this is a feature with which I'm not terribly familiar, but I don't see that in the code) | 17:21 |
| zyga-ubuntu | hmm | 17:22 |
| zyga-ubuntu | http://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/ubuntu-core-16-dragonboard.json is 404 but I see the link in the file index | 17:23 |
| kalikiana | kyrofa: I found two more that I apparently reversed unnecessarily... I guess I've been staring at these for too long to notice those. | 17:24 |
| elopio | kyrofa: currently, it accepts a path relative to prime. | 17:24 |
| elopio | what I said is to accept a path that's relative to prime, prime/usr/share or prime/usr/local/share | 17:24 |
| kalikiana | kyrofa: I hope it's fine now. See ya tomorrow | 17:24 |
| zyga-ubuntu | mvo: fresh image flashed, setting up now | 17:25 |
| zyga-ubuntu | (on that fresh card; no less) | 17:25 |
| kyrofa | kalikiana, sounds good, thanks! | 17:25 |
| ogra_ | why the heck do we put the json files there .... | 17:25 |
| kyrofa | elopio, right, okay same page then | 17:25 |
| kyrofa | elopio, ah, then we could take stuff straight from appstream and put it in there | 17:25 |
| kyrofa | Hmmmmmm | 17:26 |
| elopio | not straight, but no checking for file existence. | 17:27 |
| kyrofa | elopio, I dunno, it seems unnecessary when the appstream extractor could just use a path relative to prime | 17:27 |
| kyrofa | elopio, that makes the metadata api pretty strict and simple | 17:27 |
| kyrofa | Otherwise we'd need to document "this needs to be a path either relative to prime, relative to prime/usr/share, or prime/usr/local/share" | 17:28 |
| kyrofa | Seems more complicated than it needs to be to me | 17:28 |
| elopio | kyrofa: so, if we have this in appstream: com.example.test-app.desktop, we will add to the metadata object desktop_file_paths = ['usr/local/share/com.example.test/app.desktop', 'usr/share/com.example.test/app.desktop'], and it's the task of the prime step to find if one of the exists | 17:29 |
| zyga-ubuntu | mvo: the image is broken | 17:30 |
| elopio | kyrofa: is that right? I'm not totally sure we are on the same page :) | 17:30 |
| kyrofa | elopio, bah, this whole desktop thing has no nice solutions :D | 17:31 |
| kyrofa | I just read your responses to my other comments | 17:31 |
| elopio | kyrofa: no, I think it won't be pretty or simple ever :) | 17:32 |
| elopio | it could be a little more consistent. | 17:33 |
| kyrofa | elopio, let's pause this conversation. I want to think through this and write something down. I'll share it with you in a few. There must be a way that my eyes don't twitch when I see this | 17:33 |
| kyrofa | elopio, regardless, I think that PR is good | 17:33 |
| zyga-ubuntu | mvo: ok, worked on 2nd try - just time server being slow, the UI doesn't wait for time sync | 17:33 |
| zyga-ubuntu | mvo: I'm running the listing test now | 17:33 |
| elopio | kyrofa: take your time, and thanks. | 17:33 |
| kyrofa | elopio, I think we can improve it in pieces | 17:34 |
| kyrofa | You did a great job, of course-- I hope you know that | 17:34 |
| elopio | <3 | 17:34 |
| kyrofa | elopio, we actually need to chat about something else, if you wouldn't mind switching gears? | 17:36 |
| elopio | kyrofa: go for it | 17:37 |
| zyga-ubuntu | mvo: listing passed, I'll run all tests now | 17:38 |
| kyrofa | elopio, 2.38 requires patchelf 0.9, but 0.8 is the one in xenial. We dynamically add a build-snap in some cases to work around this | 17:39 |
| zyga-ubuntu | Chipaca: around? | 17:39 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4478 | 17:39 |
| mup | PR #4478: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4478> | 17:39 |
| Chipaca | zyga-ubuntu: O | 17:39 |
| zyga-ubuntu | this passed, I'd like to land it | 17:39 |
| kyrofa | elopio, however, this does not work for docker, which as you're well aware, is what's used in pretty much every CI | 17:39 |
| kyrofa | And the snapcraft snap can't be used either, for the same reasons | 17:39 |
| kyrofa | Currently the only option is for folks to use the deb, which is currently 2.35 for I suspect exactly this reason | 17:40 |
| zyga-ubuntu | thank you! | 17:40 |
| elopio | kyrofa: we can install a newer patchelf on the docker container, can't we? | 17:40 |
| mup | PR snapd#4478 closed: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4478> | 17:41 |
| kyrofa | elopio, however, some folks (cc: popey flexiondotorg) need the newer snapcraft (with ELF patching) | 17:41 |
| Chipaca | zyga-ubuntu: 👍 | 17:41 |
| kyrofa | elopio, that's where I'm going with this-- how would that best be done? | 17:41 |
| kyrofa | elopio, right now, people are using the daily PPA to get 2.38 | 17:41 |
| kyrofa | But they're still using patchelf 0.8, not 0.9 | 17:42 |
| kyrofa | elopio, would it be terrible to get 0.9 into our PPA to support those people while we figure out how we're going to actually get our deb back into xenial? | 17:42 |
| elopio | kyrofa: add a patchelf ppa to the docker file, I think. | 17:42 |
| zyga-ubuntu | Pharaoh_Atem: fedora re-enabled | 17:42 |
| kyrofa | elopio, oh, is there one? | 17:42 |
| * kyrofa looks | 17:42 | |
| Pharaoh_Atem | zyga-ubuntu: awesome | 17:42 |
| kyrofa | I don't see any | 17:43 |
| elopio | kyrofa: https://launchpad.net/ubuntu/+source/patchelf It would need an update for xenial. But I would prefer to use that one than to use ours, we are trying to move people from our ppa to the snap. | 17:43 |
| zyga-ubuntu | Pharaoh_Atem: thank you for helping, the dl. URL nailed it | 17:43 |
| kyrofa | elopio, in this case, people _can't_ use our snap | 17:43 |
| Pharaoh_Atem | sounds like the mirrors around the Linode IP block are semi-broken | 17:43 |
| elopio | we need to SRU 2.39 everywhere | 17:43 |
| popey | +1 | 17:44 |
| elopio | kyrofa: yes, they are using the PPA for the wrong reason. We missed a few SRUs. | 17:44 |
| roadmr | ey folks! I'm trying to build a snap on an lxc container, I get this when running snapcraft: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmpgmot5awf', 'npm', '--cache-min=Infinity', 'install']' died with <Signals.SIGSEGV: 11>. | 17:44 |
| elopio | the right solution for this, obviously, is to make docker support snaps. | 17:44 |
| elopio | if we can't have that, I'd say SRU 2.39, and update the patchelf PPA. | 17:45 |
| kyrofa | elopio, how do you anticipate that we'll SRU 2.39 in such a way that ELF patching will work in docker (i.e. no build-snaps)? | 17:45 |
| kyrofa | elopio, wait... that's not a PPA, that's the source package, no? | 17:45 |
| kyrofa | elopio, we can't SRU a newer patchelf | 17:45 |
| elopio | ahh, right, we would have to make a patchelf PPA | 17:45 |
| elopio | kyrofa: I suppose we could. | 17:46 |
| popey | or add patchelf to _your_ ppa | 17:46 |
| cjwatson | an SRU would be helpful for LP anyway, until such time as we're in a position to use the snap | 17:46 |
| elopio | popey: we don't want people to use our ppa. It's in there only for autopkgtests. | 17:46 |
| kyrofa | cjwatson, we definitely want to, just not sure how at the moment | 17:46 |
| cjwatson | ah yes. have you actually tried the patchelf SRU and had it refused? | 17:47 |
| cjwatson | maybe a cherry-pick of just the relevant thing rather than an entire new upstream (if the former i ssmaller)? | 17:47 |
| elopio | I don't know if Sergio tried it, or just decided to avoid it. | 17:47 |
| kyrofa | cjwatson, I don't think so, I just assumed it didn't fit into what SRUs were for. We have an exception for snapcraft, but not other packages | 17:47 |
| elopio | kyrofa: He said we will bundle patchelf in our repo, that would solve everything, rigth? | 17:48 |
| kyrofa | elopio, yeah I remembered that as well | 17:48 |
| kyrofa | I don't even know what language it's written in | 17:48 |
| kyrofa | I assume C or something | 17:48 |
| elopio | kyrofa: https://github.com/NixOS/patchelf | 17:50 |
| kyrofa | elopio, way ahead of you! | 17:50 |
| kyrofa | C++, nice | 17:50 |
| kyrofa | Sure would make our build process more involved | 17:50 |
| elopio | popey: cjwatson: so, Sergio is sick today. But he has a plan ™ | 17:51 |
| popey | I like a man with a plan | 17:51 |
| elopio | I think :) We have multiple options, just need to choose one. | 17:51 |
| kyrofa | We just need to make sure that, whatever option we choose, it supports docker | 17:51 |
| geekgonecrazy | Hey guys, maybe the wrong group to ask. Any idea whats up with the launchpad builders? Had builds queued up about 24 hours ago, and they still say 10 hours. I requested new builds thinking those were stuck, and they say 10 hours too | 18:09 |
| zyga-ubuntu | geekgonecrazy: hey | 18:10 |
| zyga-ubuntu | geekgonecrazy: the build farm was turned off due to meltdown/spectre | 18:10 |
| roadmr | geekgonecrazy: see https://forum.snapcraft.io/t/note-build-snapcraft-io-partially-restored-see-below-for-details/3480 | 18:10 |
| geekgonecrazy | Oh.. o.O | 18:10 |
| zyga-ubuntu | geekgonecrazy: it's up now (for amd64) but the queue is long so be patient please | 18:10 |
| geekgonecrazy | Didn't even think about that. Makes total sense though of course | 18:11 |
| kyrofa | Alright, car is done, back in a few | 18:13 |
| zyga-ubuntu | Chipaca: hmm, "snap download --revision=1234 core" should work | 18:17 |
| zyga-ubuntu | Chipaca: I get "cannot find snap "core": snap not found" | 18:17 |
| zyga-ubuntu | 2018/01/11 19:17:43.890212 retry.go:52: DEBUG: The retry loop for | 18:17 |
| zyga-ubuntu | https://api.snapcraft.io/api/v1/snaps/details/core?channel=&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Clicense%2Cbase%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cde | 18:17 |
| Chipaca | zyga-ubuntu: why should it work? | 18:17 |
| zyga-ubuntu | veloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list&revision=3604 finished after 1 retries, elapsed time=479.459782ms, status: 404 | 18:17 |
| zyga-ubuntu | Chipaca: because I'm a co-owne of core | 18:18 |
| zyga-ubuntu | Chipaca: and I'm logged in | 18:18 |
| Chipaca | zyga-ubuntu: are you on i386? | 18:18 |
| zyga-ubuntu | ah | 18:18 |
| zyga-ubuntu | usability :-) | 18:18 |
| Chipaca | zyga-ubuntu: mvo has a pr up for this | 18:19 |
| Chipaca | zyga-ubuntu: but i doubt it addresses revisions :-) | 18:19 |
| zyga-ubuntu | how can I ask it to get that arch? | 18:19 |
| Chipaca | zyga-ubuntu: UBUNTU_STORE_ARCH=potatoes | 18:20 |
| zyga-ubuntu | thank you kindly sir :) | 18:20 |
| zyga-ubuntu | UBUNTU_STORE_ARCH=i386 snap download --revision=3604 core | 18:21 |
| zyga-ubuntu | I didn't get my french fries back | 18:21 |
| zyga-ubuntu | 404 again | 18:21 |
| Chipaca | zyga-ubuntu: different revision now | 18:21 |
| Chipaca | zyga-ubuntu: 3604 is amd64 | 18:22 |
| Chipaca | zyga-ubuntu: (snapcraft list-revisions) | 18:22 |
| zyga-ubuntu | mmm, but I was on amd64 | 18:22 |
| Chipaca | zyga-ubuntu: but you overrode it with UBUNTU_STORE_ARCH | 18:22 |
| zyga-ubuntu | I got 404 regardless | 18:22 |
| zyga-ubuntu | Chipaca: i tries without that first | 18:22 |
| * Chipaca tries | 18:23 | |
| zyga-ubuntu | I *tried* | 18:23 |
| mvo | zyga-ubuntu: thanks for running the dragonboard tests, happy to hear that listing is green now | 18:23 |
| zyga-ubuntu | man, what's wrong with me | 18:23 |
| zyga-ubuntu | mvo: it's churning | 18:23 |
| mvo | zyga-ubuntu: keep me updated please, I will read backlog | 18:23 |
| zyga-ubuntu | 33/141 | 18:23 |
| Chipaca | zyga-ubuntu: :-/ dunno man | 18:23 |
| zyga-ubuntu | will do | 18:23 |
| Chipaca | zyga-ubuntu: and need to go make dinner | 18:23 |
| zyga-ubuntu | kk, thank you | 18:23 |
| mvo | Chipaca: "go make dinner\ngo: unknown subcommand "make"" | 18:24 |
| Chipaca | mvo: :-D | 18:24 |
| * Chipaca goes | 18:24 | |
| * mvo waves to Chipaca | 18:24 | |
| zyga-ubuntu | mvo: can you check if you can download revision 3604 of core please | 18:33 |
| mvo | zyga-ubuntu: I most certainly can, why? is it urgent? | 18:46 |
| roadmr | so folks... why does npm when run by snapcraft SIGSEGV on me? I've downloaded and tested the version of npm/node that snapcraft downloads and it works fine | 18:51 |
| boxrick | Good afternoon folks, I have yet to try Snap but I have noticed it and would like to get started. Hows CentOS support looking these days? And is there any ways to disable autoupdate? Is there any way of easily going about mirroring snap packages? | 18:54 |
| zyga-ubuntu | boxrick: hello | 18:56 |
| zyga-ubuntu | boxrick: Pharaoh_Atem here was working on some centos packages AFAIK | 18:57 |
| boxrick | Oooh ok | 18:57 |
| zyga-ubuntu | boxrick: I haven't tried centos in a while so I cannot say | 18:57 |
| zyga-ubuntu | boxrick: auto-update can be scheduled but not disabled, we have a good range of options for that now | 18:58 |
| roadmr | boxrick: why do you want to disable auto-update? | 18:58 |
| zyga-ubuntu | boxrick: mirroring is not currently possible but snaps are provided by a CDN so there should be no need for that (yet); we have options for on-site deployments where you get locally cached snaps through a store proxy but AFAIK this is a commercial offering | 18:58 |
| boxrick | The usual sysadmin reason, I have a server. I want controlled manual updates when I am in the office early in the week for example. | 18:59 |
| zyga-ubuntu | boxrick: if you are interested in centos support we could work with you to have those packages ready, if you are willing to help Pharaoh_Atem and try things out | 18:59 |
| zyga-ubuntu | boxrick: you can do that | 19:00 |
| boxrick | I am happy to look at a bit of extra support, got links to a specific repo? | 19:00 |
| zyga-ubuntu | boxrick: mborzecki here (he's off now) implemented a sophisticated schedule system | 19:00 |
| zyga-ubuntu | boxrick: you can have updates go, say, in a window on monday, on the first week of the month and then on 3rd week on thursday at some time | 19:01 |
| zyga-ubuntu | boxrick: and everything in between :) | 19:01 |
| roadmr | nm my problem with snapcraft; I fixed it | 19:01 |
| zyga-ubuntu | boxrick: https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239 | 19:03 |
| boxrick | Cheers | 19:04 |
| zyga-ubuntu | boxrick: I'll EOD soon but stay around and catch us tomorrow EU time | 19:05 |
| boxrick | I will do, will have a play anyway. Cheers for the response. I am UK based anyway | 19:05 |
| zyga-ubuntu | great | 19:05 |
| mup | PR snapcraft#1864 closed: debian/control: Add patchelf to Depends: <Created by flexiondotorg> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1864> | 19:30 |
| mup | PR snapcraft#1855 closed: storeapi: add docstrings for _snap_index_client.py <codein> <Created by konrad11901> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1855> | 19:36 |
| kyrofa | sergiusens, how is the snapcraft docker image have an up-to-date patchelf? Some clients require their own docker image for CI | 19:37 |
| roadmr | where are snapd issues tracked/reported? Launchpad or github? | 19:57 |
| vin-ivar | oi you lot, is there any way i can build snap from source/ | 20:00 |
| vin-ivar | i dont have root access | 20:00 |
| nacc | vin-ivar: from source/ of what? | 20:00 |
| nacc | vin-ivar: or do you mean snapd ? | 20:00 |
| vin-ivar | snapd, i mean | 20:00 |
| vin-ivar | yeah | 20:01 |
| nacc | vin-ivar: even if you could, you'd need someone to install snapd ... | 20:01 |
| nacc | vin-ivar: what OS are you on? | 20:01 |
| Son_Goku | [11:16:43 AM] <mvo>Son_Goku: but that might indicate actually that the fedora arm is using soft float | 20:02 |
| Son_Goku | mvo, fedora does not use soft float | 20:02 |
| Son_Goku | I know that for certain | 20:02 |
| vin-ivar | gentoo | 20:03 |
| zyga-ubuntu | Son_Goku: so, I switched to dl.f.o and .... got update error on my next branch | 20:03 |
| Son_Goku | zyga-ubuntu: I don't know what to say except Linode has problems | 20:03 |
| zyga-ubuntu | I ran | 20:04 |
| zyga-ubuntu | + sed -i -s -E -e 's@^#?baseurl=http://download.fedoraproject.org/@baseurl=http://dl.fedoraproject.org/@g' -e 's@^metalink=@#metalink@g' /etc/yum.repos.d/fedora-cisco-openh264.repo /etc/yum.repos.d/fedora-updates-testing.repo /etc/yum.repos.d/fedora-updates.repo /etc/yum.repos.d/fedora.repo | 20:04 |
| Son_Goku | yeah, I saw what you changed | 20:04 |
| Son_Goku | that looked fine to me | 20:04 |
| zyga-ubuntu | then + dnf install --refresh -y xdelta curl | 20:04 |
| zyga-ubuntu | Error: Failed to synchronize cache for repo 'updates' | 20:04 |
| zyga-ubuntu | maybe I messed up, I'll investigate | 20:04 |
| zyga-ubuntu | maybe missing s//g somewhere | 20:04 |
| Son_Goku | maybe the folder structure isn't right? | 20:04 |
| zyga-ubuntu | which foldr? | 20:04 |
| Son_Goku | http://dl.fedoraproject.org/pub/fedora/linux/releases/ & http://dl.fedoraproject.org/pub/fedora/linux/updates/ | 20:05 |
| zyga-ubuntu | Son_Goku: I pushed a small patch on top: https://github.com/snapcore/snapd/pull/4471/commits/09ecc08de5ee98cf72e02d3a4a299a1376969339 | 20:05 |
| mup | PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471> | 20:05 |
| zyga-ubuntu | Son_Goku: and it worked now | 20:05 |
| zyga-ubuntu | but could be random :/ | 20:05 |
| zyga-ubuntu | oh, that's silly | 20:05 |
| zyga-ubuntu | I commited and pushed the wrong one | 20:06 |
| zyga-ubuntu | I did dnf --refresh makecache | 20:06 |
| zyga-ubuntu | and commited this :p | 20:06 |
| zyga-ubuntu | I'll push next once this run is over | 20:06 |
| om26er | How can I check the delta between different versions of a snap build by build.snapcraft ? I have a snap that seems to re-download each time I refresh (amd64). | 20:09 |
| roadmr | zyga-ubuntu: sorry to poke again - where are snapd issues tracked/reported? Launchpad or github? | 20:10 |
| pedronis | roadmr: launchpad | 20:15 |
| roadmr | thanks pedronis | 20:16 |
| zyga-ubuntu | indeed | 20:17 |
| zyga-ubuntu | snapd or snappy projects | 20:17 |
| roadmr | oh why are there two? | 20:17 |
| zyga-ubuntu | historic reasons really | 20:18 |
| zyga-ubuntu | snapd is the new one | 20:18 |
| zyga-ubuntu | but snappy is the one people look for sometimes | 20:18 |
| roadmr | ok, I'll go there (snapd). Many thanks! | 20:18 |
| pedronis | roadmr: if it's urgent you should alos poke somebody | 20:19 |
| roadmr | pedronis: I don't think it is urgent or critical; nothing is crumbling or on fire | 20:19 |
| mup | PR snapd#4479 opened: spread: maybe dnf needs a refresh? <Created by zyga> <https://github.com/snapcore/snapd/pull/4479> | 21:31 |
| mup | PR snapcraft#1857 closed: grammar: make on statement work with host arch <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1857> | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!