popeykyrofa: 2.35 deb worked for now, thanks! :D00:26
=== jamesh_ is now known as jamesh
mupPR 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
MertHi guys02:26
=== Mert is now known as Guest80198
Guest80198Is core_3748 bugged?02:27
Guest80198On manjaro i can't mount core-3748.=02:28
Guest80198if you know the solution, can you email me? d_mert@hotmail.com02:30
Guest80198have a good day02:30
mupIssue 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
mupIssue 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
mupPR 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
letmutxis xfce available through snaps? i tried uappstore but couldn't find it.06:25
mborzeckizyga-ubuntu: morning07:34
mvo_good morning zyga-ubuntu and mborzecki07:41
mborzeckimvo_: hey, you have earned a _ :)07:44
=== mvo_ is now known as mvo
mborzeckiseems like fedora prepare is failing again07:47
zyga-ubuntuyes, consistently so07:48
mvotime for manual again then07:49
mborzeckimvo: will you do it or should i?07:53
mvomborzecki: please go ahead07:54
zyga-ubuntumvo: idea07:55
zyga-ubuntumvo: actually, scratch that idea :/07:55
mvozyga-ubuntu: that was a quick ide07:55
zyga-ubuntuyeah, nothing like talking to oneself to notice something is wrong07:56
* mvo hugs zyga-ubuntu 07:56
mupPR snapd#4474 opened: spread: switch fedora-26-64 back to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4474>07:57
zyga-ubuntumborzecki: bonus points if you collect the log and talk to #linode people on the other IRC network07:59
kalikianagood morning, snappy08:02
mborzeckikalikiana: morning08:06
zyga-ubuntumvo: ok, I finished other prep work and I'm setting up tests on dragon now08:07
mvozyga-ubuntu: ta08:07
zyga-ubuntumvo: all tests or just main?08:11
zyga-ubuntumvo: just to be clear, from release/2.30, run all the tests08:12
mvozyga-ubuntu: yeah, correct08:12
mvozyga-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 certain08:13
mupPR 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
zyga-ubuntuhey o/08:18
zyga-ubuntumvo: 141 tests to go, that's not that many08:24
mvozyga-ubuntu: yeah, but each takes ~1min or so :/08:27
mvozyga-ubuntu: at leat on the pi it takes a couple of hours08:27
letmutxis xfce available through snaps? i tried uappstore but couldn't find it.08:31
mborzeckiand probably 1h just for automake & configure in cmd :)08:33
zyga-ubuntuso far so good, 6th test in progress08:34
zyga-ubuntuhas anyone created a google calendar and tried to add a hangout to it08:36
zyga-ubuntuit seems this option is gone now08:36
pedronismvo: hi, I reviewed #4356  (yesterday got a bit distracted)08:44
mupPR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>08:44
zyga-ubuntumvo: ~~12 tests out of 141, each test really takes minutes08:49
zyga-ubuntuI'll grab a coffee08:49
zyga-ubuntujamesh: around?08:49
jameshzyga-ubuntu: hi08:49
zyga-ubuntujamesh: we'll probably jump into a standup HO as I cannot add HO to the event anymore08:50
zyga-ubuntujamesh: I'll share the link in a moment08:50
mvopedronis: thank you, I have a look as soon as I have some spectre releated stuff under control08:52
zyga-ubuntuniemeyer: we're going to use the standup HO08:58
mborzeckibtw. 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=1611885808:59
mupBug #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
Chipacamborzecki: i guess 10 retries wasn't enough for the fedora thing09:04
Chipaca¯\_(ツ)_/¯ i wanted to push another commit anyway09:04
mvopedronis: thanks, review looks very good09:15
mvoPharaoh_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
Chipacamvo: why am i not making 'snap pack' run validateContainer?09:29
mvoChipaca: indeed, why don't you? as a warning and with an option to disable, right?09:29
pedronisChipaca: indeed :)09:29
mvoChipaca: I mean, it will not make snap pack fail, right?09:29
Chipacamvo: why wouldn't it?09:30
pedroniswe might have some tests that abuse stuff09:30
pedronisbut I don't think it should be just a warning09:30
pedronisit should be error09:30
pedronisor nothing09:30
mvoChipaca: hm, right, it won't even install so … +1 for fail09:30
mvolets see if tests survive this ,)09:31
Chipacamvo: maybe in a separate PR though :-)09:31
mvoagain +109:31
* Chipaca is adding a spread test to 4464 and then hopes to land it09:32
seyeongkimhello, is there a way to install older revision of core snap?09:38
mborzeckihaha so the snap store is returning 418 'I'm a teapot'?09:39
Chipacamborzecki: and does GET give you coffee, as per spec?09:42
mborzeckijust the teapot, the rest is DIY09:43
mupPR 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
pedronissmall PR cleaning up an oddity I noticed recently  ^09:51
Chipacapedronis: a space oddity?09:57
pedronisChipaca: silly you :)10:01
* Chipaca nods10:01
Chipacapedronis: in my defense, i'm learning it on the guitar :-)10:03
pedronisChipaca: it's fine, it would have been funnier if it was indeed a space problem, but alas we use go fmt10:05
pedronisthough there is always shell  and yaml to commit space sins10:06
Chipacapedronis: :-)10:22
zyga-ubuntumvo: we're at 59/141 now10:28
zyga-ubuntumvo: no issues yet10:28
mupPR 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
brunosferChipaca: 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
brunosferChipaca: I want to make a "snap find" to the public API...10:34
mvozyga-ubuntu: great, pi3 is finished here, I'm doing p2 now10:38
zyga-ubuntumvo: cool, I'll let you know when something changes10:38
Chipacabrunosfer: it's a little out of date, but https://github.com/snapcore/snapd/wiki/REST-API might be a good place to start10:38
brunosferChipaca: Thanks!10:39
mborzeckimvo: how long did it take?10:40
* kalikiana taking a break, too much staring at a screen :-/10:51
mvomborzecki: oh, sorry, didn't see the question - pi3 took around 2.5h11:00
Chipacamborzecki: mvo: could one of you mark my #4464 as 'changes requested' please so it doesn't get merged for a bit?11:03
mupPR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>11:03
Chipacai just realised something needs fixing, but i don't want to close it and lose the spread test run11:03
Chipacai'm going to go take a break, bbiab11:04
mborzeckiChipaca: marked11:04
zyga-ubuntuerror: cannot list snaps: cannot list local snaps! cannot find installed snap "classic" at revision 2611:18
zyga-ubuntumvo: that was11:18
zyga-ubuntu2018/01/11 12:14:55 Error executing external:ubuntu-core-16-arm-64:tests/main/listing :11:18
zyga-ubuntumvo: it's still going, 81/141 now11:18
mvozyga-ubuntu: hm, that looks strange, we may need to re-run this one test11:21
mvozyga-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 sometimes11:22
ogramvo, did you notice that your copre snap build failed ?11:22
ograrm: cannot remove '/var/lib/apt/lists/': Is a directory11:22
ograrm: cannot remove '/var/lib/apt/lists/partial': Is a directory11:22
ograE: config/hooks/12-add-foreign-libc6.chroot failed (exit non-zero). You should check for errors.11:22
ograseems your -print 0 re-ordering isnt liked11:24
zyga-ubuntumvo: sure, I can re run11:24
mvoogra: meh, sucks. I have a look11:24
zyga-ubuntumvo: FYI I'm talking with linode operators about fedora issues and I'm using spread 70 to test11:24
mvoogra: slightly strange on my artful this shows the right result. I guess I need to double check on xenial11:25
ograyeah, it really shouldnt do any harm11:26
ogra(but if it does, the manpages and docs removal will have the same issue11:26
mvoogra: yeah, the "funny" part is that i386 build fine11:27
ograwell, then it seems to work with the docs at least11:27
ograother 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-ubuntumvo: fedora uses a random mirror from a redirectory11:29
zyga-ubuntumvo: 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-ubuntumvo: but a bad sequence will probably explain the set of failures we've seen11:30
zyga-ubuntumvo: probably spectre/meltdown result11:30
zyga-ubuntumvo: we can pin to a specific mirror if we want11:30
zyga-ubuntumvo: I'm also asking if linode plans to offer one11:31
zyga-ubuntuwe'll need gustavo to open a ticket11:36
zyga-ubuntuI'll prepare the contents11:36
mvohu? what checksum is that11:36
mvoaha, its just 311:37
zyga-ubuntumvo: https://forum.snapcraft.io/t/issues-with-fedora-mirror/3489 for tracking11:44
zyga-ubuntuSon_Goku: ^11:52
Son_Gokuzyga-ubuntu: what happens when you try to curl the URL from within the Linode system?11:53
zyga-ubuntuSon_Goku: it's random, it works most of the time in a loop11:53
zyga-ubuntuSon_Goku: it jut doesn't _always_ work11:53
zyga-ubuntuSon_Goku: I'll try curl in a sec11:53
zyga-ubuntuSon_Goku: running a test with "dnf install -y -4" now11:53
zyga-ubuntuSon_Goku: over ipv4 only11:53
Son_Gokumetadata fetching is done by a library called librepo11:55
Son_Gokuif there's a bug in mirror selection for metadata fetching, that's where to look11:55
Son_Gokualso, it's not _random_ per se11:56
zyga-ubuntuSon_Goku: did you see https://pastebin.ubuntu.com/26365704/ ?11:56
Son_Gokuthe Fedora MirrorManager returns a list of valid, fast, nearby mirrors based on the location it derives from the initial request11:56
Son_Gokuthose mirrors come from the metalink11:57
zyga-ubuntu*all mirrors tried* sounds bad when it doesn't work11:57
Son_Gokusomething fishy is going on11:57
Son_Gokumakes me think there might be an issue in librepo11:57
Son_Gokubut *shrugs*11:57
Son_Gokubtw, you can look in /var/log/dnf.librepo.log, too11:57
zyga-ubuntuthanks, I'll check11:58
Son_Gokueven when DNF isn't in verbose mode, all the output for metadata fetching is there11:58
mupPR 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 helped12:02
mupPR 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
mupPR 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
mupPR 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
mupPR 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-ubuntumvo: another test failed, I'm at 110/141 now)12:29
pedronisogra: we don't , but  it should get prioritized soon (for value of soon), is a prereq for other work we need to do12:34
ogra_pedronis, ack ... and helps to get rid of some hacks in products too :)12:35
pedronisogra_: topic is here:  https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/143112:35
ogra_yeah, i just found it too :)12:35
pedronisogra_: to be fair it was also conflicting with interface hooks work, but that is getting close to done12:37
matiasbniemeyer, 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
matiasbhappy to schedule a call if that helps too, we need some definition to get that started server-side12:41
zyga-ubuntuPharaoh_Atem: is there any official non-mirror archive I can hit?12:45
sergiusensmatiasb I agree. I am fine with Robert's proposal12:55
matiasbsergiusens, 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
mvozyga-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 hardware12:59
* kalikiana going for lunch in ~1013:22
* kalikiana trying to finish these tedious grammar test cases til then...13:22
zyga-ubuntumvo: https://pastebin.ubuntu.com/26366173/13:32
zyga-ubuntustill running13:32
pedronisChipaca: you could use -ls and -lls together (it gets silly)13:36
Chipacapedronis: yes13:36
brunosferHi guys, does anyone knows how can I change the default path when downloading a snap?13:45
zyga-ubuntumvo: it's done13:46
zyga-ubuntu    - external:ubuntu-core-16-arm-64:tests/main/listing13:46
zyga-ubuntu    - external:ubuntu-core-16-arm-64:tests/main/prepare-image-uboot13:46
zyga-ubuntuthose two failed13:46
zyga-ubuntubrunosfer: when you snap install or when you snap download?13:47
zyga-ubuntubrunosfer: this is not configurable AFAIR13:47
zyga-ubuntubrunosfer: what's the background, what are you trying to, maybe we can do something else13:47
zyga-ubuntumvo: ok, I'll grab some water and let's talk13:50
zyga-ubuntumvo: shall I re-run those two? the failure logs are in the pastebin13:50
mvozyga-ubuntu: this looks not too bad, please re-run the two just for kicks and pastebin the full run13:50
zyga-ubuntumvo: 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 results13:51
Son_Gokuzyga-ubuntu: the main fedora URL is dl.fedoraproject.org13:52
Son_Gokudownload.fedoraproject.org is a redirector for things that don't support mirrorlists or metalinks13:52
brunosferzyga-ubuntu: When I snap download.13:52
mvozyga-ubuntu: thank you13:52
brunosferzyga-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-ubuntuSon_Goku: thanks, that's useful13:53
zyga-ubuntubrunosfer: AFAIR it just downloads to the current directory,13:54
zyga-ubuntuSon_Goku: that's working, I'll run a small loop to see if that stays operational13:57
* pstolowski lunch14:00
mupPR 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
brunosferzyga-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
niemeyermatiasb, sergiusens: Will catch up with that discussion this afternoon..14:10
niemeyermatiasb, sergiusens: We can then have a call if necessary and you are available14:11
matiasbniemeyer, sergiusens, sure, I'm available today/tomorrow, just let me know14:21
pedronisniemeyer: 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 timestamps14:26
niemeyerpedronis: That's easier to reason about, and also makes the seed more even with other behavior.. nice14:27
mborzeckioff to pick up the kids14:31
mupPR snapcraft#1864 opened: debian/control: Add patchelf to Depends: <Created by flexiondotorg> <https://github.com/snapcore/snapcraft/pull/1864>14:46
mupPR 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
Chipacabrunosfer: are you talking about 'snap download'?14:54
zyga-ubuntumvo: same failures14:59
mvozyga-ubuntu: could you flash the image again? the listing one is confusing, I'm checking the prepare-image one now15:00
zyga-ubuntusorry, I fell asleep15:00
zyga-ubuntumvo: sure, working15:04
mvozyga-ubuntu: ta!15:06
mvozyga-ubuntu: both failures are odd, the second less so but the first one very much so15:07
mvozyga-ubuntu: as the first test does not install classic15:07
zyga-ubuntumvo: I just realized I didn't actually flash the image earlier, it was running on edge core/kernel15:07
zyga-ubuntumvo: I need to build an image for it and the copy it over15:07
mvozyga-ubuntu: please use the image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/15:08
mvozyga-ubuntu: thats the image we need to test15:09
zyga-ubuntumvo: sure thing15:09
mvozyga-ubuntu: thank you!15:09
zyga-ubuntusorry for the confusion, I'll hook it up ASAP15:09
mvozyga-ubuntu: sorry that I take up your time :(15:09
zyga-ubuntumvo: no worries :) feels like a good time to use the board once in a while15:10
mupPR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>15:20
mupPR # closed: core#38, core#67, core#69, core#70, core#7115:21
mupPR # closed: core#38, core#67, core#69, core#70, core#7115:24
mupPR # 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
mupsnapd#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#447615:24
kalikianasergiusens: to hangout or not to hangout? which will it be? :-)15:24
mupPR # 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
mupsnapd#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#447615:25
mupPR # 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
mupsnapd#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#447615:27
mupIssue # 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
mupsnapcraft#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
mupsnapcraft#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
mupsnapcraft#1708, snapcraft#1714, snapcraft#1715, snapcraft#1751, snapcraft#1753, snapcraft#1794, snapcraft#1819, snapcraft#182815:28
mupPR # 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#186415:28
zyga-ubuntumvo: github down15:29
zyga-ubuntumvo: I'll get you the results later today, I need a fresh SD card (in ~40 minutes)15:29
kalikianahrm... 503 not allowd on GitHub?! this is weird15:31
kalikianaI guess GitHub is really kinda broken today15:33
mvozyga-ubuntu: ta15:34
mvozyga-ubuntu: yeah github down makes me unhappy15:34
zyga-ubuntumvo: coudn't github be down when I was sleeping15:34
kalikianamvo: it's not completely down. it's more like launchpad on a normal day ;-)15:40
kalikianatry a few more times and it kinda works15:40
zyga-ubuntuI will file a github bug report15:40
zyga-ubuntuthe unicorn could use a few more images15:40
zyga-ubuntuit would make reloading funnier15:40
zyga-ubuntu"see the world they said"15:40
kalikianahaha, I was thinking the same actually15:40
mvokalikiana: haha15:40
mupPR snapd#4477 opened: snapenv: add SNAP_ARCH_TRIPLET <Created by mvo5> <https://github.com/snapcore/snapd/pull/4477>15:42
zyga-ubuntumvo: nice15:43
zyga-ubuntumvo: question15:44
zyga-ubuntumvo: are those values areally "universal"15:44
zyga-ubuntumvo: I was thinking that this should be a function that takes a snap info as argument15:44
kalikianawooot, arch triplet! awesome!15:44
zyga-ubuntumvo: so that we can return the right values for say, debian and fedora15:44
kalikianakyrofa: ^^15:44
zyga-ubuntumvo: if for any reason they actually don't mean the same thing15:44
mvozyga-ubuntu: I was asking Son_Goku earlier about the fedora arch triplets but maybe he missed the message15:45
zyga-ubuntumvo: and at the place where you call it you can easily pass the info15:45
mvozyga-ubuntu: its tricky, in theory these triplets are whatever you tell your compiler they should be15:45
zyga-ubuntumvo: then you can still use $SNAP_ARCH_TRIPLET all the time15:45
zyga-ubuntuand it just matches your base15:45
zyga-ubuntumvo: right exactly that's why I think it should be base-bound15:45
mvozyga-ubuntu: yeah, making them base-bound would probably the best, I need to learn more about the fedora world15:46
zyga-ubuntumvo: it could even be a meta-data on base snap somewhere15:46
zyga-ubuntumvo: but for now it's enough if this is the value we return for base-16 and base-1815:46
zyga-ubuntumvo: I suspect ikey might want to chime in too15:46
mvozyga-ubuntu: +115:47
mvozyga-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-ubuntumvo: not all15:48
zyga-ubuntumvo: solus doesn't AFAIR15:48
zyga-ubuntumvo: I have a swarm of VMs to check if you want to know15:48
* zyga-ubuntu wishes to be exactly as ignorant as mvo ;-) 15:49
mvozyga-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 AFAICT15:50
mvozyga-ubuntu: anyway, not important, please don't let me distract you15:50
Son_Gokumvo: hm?15:56
mvoSon_Goku: you told me at some point fedora is using more detailed architecture defintions - where can I read more about this15:57
Son_Gokuhttps://github.com/rpm-software-management/rpm/blob/master/platform.in + https://github.com/rpm-software-management/rpm/blob/master/rpmrc.in15:57
mvothanks Son_Goku15:58
Son_Gokualso, 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/36015:58
mupPR 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_Gokumvo: in Fedora, we do /usr/<triple> for foreign architectures for cross targets15:59
Son_Gokuand the triple is defined as the triple coming from the compiler (gcc)15:59
mvoSon_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_Gokumostly the same15:59
Son_GokuI think there's some differences w.r.t. ppc64 triples15:59
Son_Gokubut it's been a while15:59
mvoSon_Goku: cool, that sounds very promising16:00
mvoChipaca: thanks for your suggestion I think I call it normalizedGnuTriplet16:00
Son_Gokuyou can actually query this on rpm using 'rpm --target <arch> --eval "%_target_platform"'16:01
Son_Gokunot sure if it triggers the correct mappings w.r.t. isa aliasing, but it gets you close16:02
Chipaca$ rpm --target amd64 --eval "%_target_platform"16:02
Chipacarpm: --target: unknown option16:02
* popey hugs mvo for https://github.com/snapcore/snapd/pull/4477 ( cc kyrofa ^) :D16:05
mupPR #4477: snapenv: add SNAP_ARCH_TRIPLET <Created by mvo5> <https://github.com/snapcore/snapd/pull/4477>16:05
Son_Gokuwhat version of rpm is there?16:05
Son_Goku(it worked on my Fedora 27 system with rpm 4.14, so...)16:05
mvoSon_Goku: what does it output for amd64,i386,armhf,arm64 on rpm (out of curiosity)?16:06
Son_Gokux86_64-redhat-linux-gnu, i386-redhat-linux-gnu (though fedora uses i686-redhat-linux-gnu), <notvalid>, <notvalid>16:07
Son_GokuI suppose I should add an arm64 -> aarch64 alias at some point16:07
* zyga-ubuntu hands mvo his green tea for the evening16:07
Son_Gokuand armhf is not a real thing16:07
Son_Gokufor Fedora, we have armv7hl-redhat-linux-gnu for our 32-bit arm arch16:07
mvoSon_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 ok16:07
ChipacaSon_Goku: I get that on on ubuntu xenial, and 4.13.0-rc1 on fedora 2416:08
mvoSon_Goku: woah, that one is totally different - do you have a 32bit arm with hardware float?16:08
Son_Gokuiirc, debian never defined the vendor field, and it's easy enough to chop out when scanning triple16:08
Son_Gokumvo: yep16:08
Son_Gokuarmv7hl is our hardware float arch16:08
Son_Gokuwe've had armv6hl in the past16:08
Son_Gokuwe bumped to armv7hl about five years ago?16:09
Son_Gokuwe've also had armv5tl for non hfp before16:09
zyga-ubuntumvo: you need to accept info argument16:09
zyga-ubuntumvo: case closed16:09
Son_Gokumvo: rpm doesn't do basearches16:09
Son_Gokuwe 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-L10216:10
mvoSon_Goku: aha, for those we use arm-linux-gnueabihf16:10
Son_Gokumvo: let me check our arm compiler triple16:10
mvoSon_Goku: sounds very much like this has to be base specific16:10
Son_GokuI think the arm-linux-gnueabihf is what our compiler says though16:10
zyga-ubuntuI'm waiting for a fresh SD card (alredy bought, will be here in 15 minutes)16:11
zyga-ubuntuand I fixed the fedora archive thing to point to dl....16:11
mvoSon_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_Gokuno redhat in the triple on the filesystem16:12
mvozyga-ubuntu: you got it delivered directly to you on the same day? nice16:12
mvoSon_Goku: yay16:12
zyga-ubuntumvo: we should get some opensuse poeople16:12
mvoSon_Goku: so I think we the triplets are compatible, thats cool16:12
zyga-ubuntumvo: yes, my wife's office is right next to a shopping centre with electronics store inside ^_^16:12
zyga-ubuntumvo: what would I do without her :-)16:12
Son_Gokurpm can query without vendor by doing `rpm --target <arch> --eval "%{_target_cpu}-%{_vendor}-%{_target_os}"`16:13
Son_Gokurpm 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
mvozyga-ubuntu: hahaha, give her a *hug*16:13
mvoSon_Goku: cool, I think we are good then, thanks for all your input16:14
Son_Gokuno problem16:14
Son_Gokuwe do need a more granular scheme for architectures in snaps itself16:14
Son_Gokubut the on-filesystem thing is way simpler ;)16:14
Son_Gokumvo: looks like our compiler has arm-linux-gnueabi for hf16:15
Son_Gokunot sure why the hf suffix is left off16:15
Son_Gokubut otherwise identical16:15
zyga-ubuntuit's all a big mess16:15
mvoSon_Goku: yeah, thats slightly unfortuante16:15
zyga-ubuntuit'd be 100x better if we asked a homeless guy *consistently* instead of letting a crowd of technical people decide16:16
mvoSon_Goku: but that might indicate actually that the fedora arm is using soft float16:16
ogra_SNAP_ARCH_TRIPLET !!!16:35
ogra_oh i love that !16:35
brunosferChipaca: 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
mvozyga-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 work16:35
Chipacabrunosfer: ah, i was going to say, it always downloads to the current directory16:36
brunosferChipaca: However I intended to use a cleaner solution...16:36
zyga-ubuntumvo: will the kernel emulate that?16:36
zyga-ubuntumvo: note that fedora arm is not widespread popular16:36
mvoogra_: heh, it my most popular branch so far ;)16:36
zyga-ubuntumvo: so maybe it's a temporary issue16:36
brunosferChipaca: Yeah, when zyga told me it would always download to the current directory I did the workaround...16:36
Chipacabrunosfer: i guess nobody has needed this, which is why it doesn't have an --output-dir=<...> option16:36
mvozyga-ubuntu: may well be, its nothing new, we just may need to keep it in the back of our heads16:36
brunosferChipaca: 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 hardfloat16:39
ogra_*as name16:39
mupPR snapd#4478 opened: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4478>16:39
mvoogra_: ah, cool. that explains it16:41
mborzeckiiirc armv7 already supports vfp, that should make the non -m variants hf16:46
kyrofaelopio, alright, had a quick call, but now I'm settled16:47
zyga-ubuntumborzecki: updated16:47
elopiokyrofa: I think I replied to all your comments, but I was left thinking about the metadata.16:48
kyrofaelopio, come up with any brilliant thoughts?16:48
elopiokyrofa: (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
elopioso, 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 too16:49
mborzeckizyga-ubuntu: i'd leave the retries there, but otherwise +116:49
kyrofaelopio, that seems more generic indeed16:50
zyga-ubuntumborzecki: let's see if this passes16:51
kyrofaWas your thought to make it scale better across different metadata extraction methods (beyond appstream)?16:51
zyga-ubuntumborzecki: I think the retries didn't really work16:51
zyga-ubuntumborzecki: and they were there for the precisely same reason I'm hacking this now16:51
elopiokyrofa: well, not to leak the details of the extractor to the metadata object.16:51
kyrofaelopio, yeah, I agree16:51
elopiokyrofa: should I do it before merge, or as a follow up?16:54
kyrofaelopio, let me think for a sec, /me take another look at the PR16:54
kyrofaMan it's hard to think here, I got so used to my quiet office16:55
kyrofaokay elopio what's in the appstream data is stuff like "com.example.test-app.desktop"16:57
elopioyes, a launchable of type desktop-id, is what they call it.16:58
kyrofaelopio, in meta, we assume that the desktop file ends up installed in /usr/share or /usr/local/share16:58
elopiokyrofa: that's what the xdg specification says.16:58
kyrofaIf we do that mapping sooner, you'll need to contend with the fact that your extractor is run multiple times, from different roots16:58
elopioon pull it will probably always fail, because the desktop file won't be on a usr/share dir on the repo16:59
kyrofaIt's run during pull, in src/, and twice in build16:59
elopiobut on build, it will find it most likely16:59
kyrofaYeah that's what I'm driving at-- so far we've extracted actual data, this is the first time we're extracting paths16:59
kyrofaelopio, would it be ridiculous to embed the desktop file in the metadata?17:00
elopiokyrofa: 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
elopiokyrofa: not ridiculous, but not nice. Our snapcraft.yaml takes paths, so the closer we get to that, the better IMO.17:01
kyrofaelopio, I want to be careful about subsequent steps reaching back into preceding steps, it breaks the lifecycle17:01
kyrofaBut I feel like we're making some assumptions that the desktop file is actually installed and available in prime once we do the conversion17:02
elopiokyrofa: isn't that what the desktop keyword assumes too?17:03
* kalikiana wrapping up for the day17:03
kyrofaelopio, fair point17:03
elopiobye kalikiana17:03
kyrofaI'm stuck on the darn meta/gui ones for some reason17:03
elopioThe icon implementation mapped nicely to the icon keyword on snapcraft.yaml. Not so much to the icon.png in snap/gui.17:04
kalikianakyrofa: 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 :-D17:04
mupPR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>17:04
elopioI think that's ok for desktop too.17:04
elopiokyrofa: another alternative would be to run "find", instead of assume that it will be in /usr/share or /usr/local/share17:05
kyrofakalikiana, what is this change? https://github.com/snapcore/snapcraft/pull/1857/files#diff-0f81cfd5e83dc1988a457bf45d0da9e1R10317:06
mupPR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>17:06
elopiothe 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
elopioor dirs, I guess you can have multiple -.17:06
kyrofaelopio, no, let's back up to our metadata17:06
kyrofaIf 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 do17:07
kyrofaelopio, so I like the idea of mapping to paths for appstream earlier17:07
kyrofaAnd 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
elopiokyrofa: 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
kyrofaThen, the appstream extractor can look in /usr/share on its own to convert to a path17:08
kyrofaSo all the appstream specific stuff is in the extractor instead of leaking, like you said17:09
kyrofaelopio, yeah, I say we define the metadata we want to use, and make appstream fit in there17:09
kyrofaelopio, but I also think it can be a follow-up17:09
elopiokyrofa: 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
elopiothen on appstream, we only have to translate desktop_file_id to desktop_file_path_relative_to_xdg17:10
elopiothat would be com.example.test-app.desktop -> com.example.test/app.desktop, easy.17:11
kalikianakyrofa: hmmm did I flip the values? I guess I can check that17:11
kyrofakalikiana, 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
kyrofaelopio, wait, the desktop keyword is a path, is it not?17:13
kalikianakyrofa: I don't see how that sentence can be true. The behavior isn't the same17:13
elopiokyrofa: yes. But I'll let you talk with kalikiana first.17:13
kyrofakalikiana, the on statement works exactly the same way, but instead of using target arch, it now uses the host arch. No?17:14
kalikianakyrofa: consider this example. changing just target to host will not work https://github.com/snapcore/snapcraft/pull/1857/files#diff-0f81cfd5e83dc1988a457bf45d0da9e1R14117:15
mupPR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>17:15
kyrofakalikiana, it's okay, I know you're EOD, I'll clone it and see if I can reproduce what you're talking about17:18
kyrofaelopio, 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-ubuntuhttp://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/ubuntu-core-16-dragonboard.json is 404 but I see the link in the file index17:23
kalikianakyrofa: 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
elopiokyrofa: currently, it accepts a path relative to prime.17:24
elopiowhat I said is to accept a path that's relative to prime, prime/usr/share or prime/usr/local/share17:24
kalikianakyrofa: I hope it's fine now. See ya tomorrow17:24
zyga-ubuntumvo: fresh image flashed, setting up now17:25
zyga-ubuntu(on that fresh card; no less)17:25
kyrofakalikiana, sounds good, thanks!17:25
ogra_why the heck do we put the json files there ....17:25
kyrofaelopio, right, okay same page then17:25
kyrofaelopio, ah, then we could take stuff straight from appstream and put it in there17:25
elopionot straight, but no checking for file existence.17:27
kyrofaelopio, I dunno, it seems unnecessary when the appstream extractor could just use a path relative to prime17:27
kyrofaelopio, that makes the metadata api pretty strict and simple17:27
kyrofaOtherwise 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
kyrofaSeems more complicated than it needs to be to me17:28
elopiokyrofa: 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 exists17:29
zyga-ubuntumvo: the image is broken17:30
elopiokyrofa: is that right? I'm not totally sure we are on the same page :)17:30
kyrofaelopio, bah, this whole desktop thing has no nice solutions :D17:31
kyrofaI just read your responses to my other comments17:31
elopiokyrofa: no, I think it won't be pretty or simple ever :)17:32
elopioit could be a little more consistent.17:33
kyrofaelopio, 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 this17:33
kyrofaelopio, regardless, I think that PR is good17:33
zyga-ubuntumvo: ok, worked on 2nd try - just time server being slow, the UI doesn't wait for time sync17:33
zyga-ubuntumvo: I'm running the listing test now17:33
elopiokyrofa: take your time, and thanks.17:33
kyrofaelopio, I think we can improve it in pieces17:34
kyrofaYou did a great job, of course-- I hope you know that17:34
kyrofaelopio, we actually need to chat about something else, if you wouldn't mind switching gears?17:36
elopiokyrofa: go for it17:37
zyga-ubuntumvo: listing passed, I'll run all tests now17:38
kyrofaelopio, 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 this17:39
zyga-ubuntuChipaca: around?17:39
mupPR #4478: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4478>17:39
Chipacazyga-ubuntu: O17:39
zyga-ubuntuthis passed, I'd like to land it17:39
kyrofaelopio, however, this does not work for docker, which as you're well aware, is what's used in pretty much every CI17:39
kyrofaAnd the snapcraft snap can't be used either, for the same reasons17:39
kyrofaCurrently the only option is for folks to use the deb, which is currently 2.35 for I suspect exactly this reason17:40
zyga-ubuntuthank you!17:40
elopiokyrofa: we can install a newer patchelf on the docker container, can't we?17:40
mupPR 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
kyrofaelopio, however, some folks (cc: popey flexiondotorg) need the newer snapcraft (with ELF patching)17:41
Chipacazyga-ubuntu: 👍17:41
kyrofaelopio, that's where I'm going with this-- how would that best be done?17:41
kyrofaelopio, right now, people are using the daily PPA to get 2.3817:41
kyrofaBut they're still using patchelf 0.8, not 0.917:42
kyrofaelopio, 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
elopiokyrofa: add a patchelf ppa to the docker file, I think.17:42
zyga-ubuntuPharaoh_Atem: fedora re-enabled17:42
kyrofaelopio, oh, is there one?17:42
* kyrofa looks17:42
Pharaoh_Atemzyga-ubuntu: awesome17:42
kyrofaI don't see any17:43
elopiokyrofa: 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-ubuntuPharaoh_Atem: thank you for helping, the dl. URL nailed it17:43
kyrofaelopio, in this case, people _can't_ use our snap17:43
Pharaoh_Atemsounds like the mirrors around the Linode IP block are semi-broken17:43
elopiowe need to SRU 2.39 everywhere17:43
elopiokyrofa: yes, they are using the PPA for the wrong reason. We missed a few SRUs.17:44
roadmrey 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
elopiothe right solution for this, obviously, is to make docker support snaps.17:44
elopioif we can't have that, I'd say SRU 2.39, and update the patchelf PPA.17:45
kyrofaelopio, 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
kyrofaelopio, wait... that's not a PPA, that's the source package, no?17:45
kyrofaelopio, we can't SRU a newer patchelf17:45
elopioahh, right, we would have to make a patchelf PPA17:45
elopiokyrofa: I suppose we could.17:46
popeyor add patchelf to _your_ ppa17:46
cjwatsonan SRU would be helpful for LP anyway, until such time as we're in a position to use the snap17:46
elopiopopey: we don't want people to use our ppa. It's in there only for autopkgtests.17:46
kyrofacjwatson, we definitely want to, just not sure how at the moment17:46
cjwatsonah yes.  have you actually tried the patchelf SRU and had it refused?17:47
cjwatsonmaybe a cherry-pick of just the relevant thing rather than an entire new upstream (if the former i ssmaller)?17:47
elopioI don't know if Sergio tried it, or just decided to avoid it.17:47
kyrofacjwatson, 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 packages17:47
elopiokyrofa: He said we will bundle patchelf in our repo, that would solve everything, rigth?17:48
kyrofaelopio, yeah I remembered that as well17:48
kyrofaI don't even know what language it's written in17:48
kyrofaI assume C or something17:48
elopiokyrofa: https://github.com/NixOS/patchelf17:50
kyrofaelopio, way ahead of you!17:50
kyrofaC++, nice17:50
kyrofaSure would make our build process more involved17:50
elopiopopey: cjwatson: so, Sergio is sick today. But he has a plan ™17:51
popeyI like a man with a plan17:51
elopioI think :) We have multiple options, just need to choose one.17:51
kyrofaWe just need to make sure that, whatever option we choose, it supports docker17:51
geekgonecrazyHey 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 too18:09
zyga-ubuntugeekgonecrazy: hey18:10
zyga-ubuntugeekgonecrazy: the build farm was turned off due to meltdown/spectre18:10
roadmrgeekgonecrazy: see https://forum.snapcraft.io/t/note-build-snapcraft-io-partially-restored-see-below-for-details/348018:10
geekgonecrazyOh.. o.O18:10
zyga-ubuntugeekgonecrazy: it's up now (for amd64) but the queue is long so be patient please18:10
geekgonecrazyDidn't even think about that.  Makes total sense though of course18:11
kyrofaAlright, car is done, back in a few18:13
zyga-ubuntuChipaca: hmm, "snap download --revision=1234 core" should work18:17
zyga-ubuntuChipaca: I get "cannot find snap "core": snap not found"18:17
zyga-ubuntu2018/01/11 19:17:43.890212 retry.go:52: DEBUG: The retry loop for18:17
Chipacazyga-ubuntu: why should it work?18:17
zyga-ubuntuveloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list&revision=3604 finished after 1 retries, elapsed time=479.459782ms, status: 40418:17
zyga-ubuntuChipaca: because I'm a co-owne of core18:18
zyga-ubuntuChipaca: and I'm logged in18:18
Chipacazyga-ubuntu: are you on i386?18:18
zyga-ubuntuusability :-)18:18
Chipacazyga-ubuntu: mvo has a pr up for this18:19
Chipacazyga-ubuntu: but i doubt it addresses revisions :-)18:19
zyga-ubuntuhow can I ask it to get that arch?18:19
Chipacazyga-ubuntu: UBUNTU_STORE_ARCH=potatoes18:20
zyga-ubuntuthank you kindly sir :)18:20
zyga-ubuntuUBUNTU_STORE_ARCH=i386 snap download --revision=3604 core18:21
zyga-ubuntuI didn't get my french fries back18:21
zyga-ubuntu404 again18:21
Chipacazyga-ubuntu: different revision now18:21
Chipacazyga-ubuntu: 3604 is amd6418:22
Chipacazyga-ubuntu: (snapcraft list-revisions)18:22
zyga-ubuntummm, but I was on amd6418:22
Chipacazyga-ubuntu: but you overrode it with UBUNTU_STORE_ARCH18:22
zyga-ubuntuI got 404 regardless18:22
zyga-ubuntuChipaca: i tries without that first18:22
* Chipaca tries18:23
zyga-ubuntuI *tried*18:23
mvozyga-ubuntu: thanks for running the dragonboard tests, happy to hear that listing is green now18:23
zyga-ubuntuman, what's wrong with me18:23
zyga-ubuntumvo: it's churning18:23
mvozyga-ubuntu: keep me updated please, I will read backlog18:23
Chipacazyga-ubuntu: :-/ dunno man18:23
zyga-ubuntuwill do18:23
Chipacazyga-ubuntu: and need to go make dinner18:23
zyga-ubuntukk, thank you18:23
mvoChipaca: "go make dinner\ngo: unknown subcommand "make""18:24
Chipacamvo: :-D18:24
* Chipaca goes18:24
* mvo waves to Chipaca 18:24
zyga-ubuntumvo: can you check if you can download revision 3604 of core please18:33
mvozyga-ubuntu: I most certainly can, why? is it urgent?18:46
roadmrso 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 fine18:51
boxrickGood 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-ubuntuboxrick: hello18:56
zyga-ubuntuboxrick: Pharaoh_Atem here was working on some centos packages AFAIK18:57
boxrickOooh ok18:57
zyga-ubuntuboxrick: I haven't tried centos in a while so I cannot say18:57
zyga-ubuntuboxrick: auto-update can be scheduled but not disabled, we have a good range of options for that now18:58
roadmrboxrick: why do you want to disable auto-update?18:58
zyga-ubuntuboxrick: 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 offering18:58
boxrickThe 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-ubuntuboxrick: 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 out18:59
zyga-ubuntuboxrick: you can do that19:00
boxrickI am happy to look at a bit of extra support, got links to a specific repo?19:00
zyga-ubuntuboxrick: mborzecki here (he's off now) implemented a sophisticated schedule system19:00
zyga-ubuntuboxrick: 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 time19:01
zyga-ubuntuboxrick: and everything in between :)19:01
roadmrnm my problem with snapcraft; I fixed it19:01
zyga-ubuntuboxrick: https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/123919:03
zyga-ubuntuboxrick: I'll EOD soon but stay around and catch us tomorrow EU time19:05
boxrickI will do, will have a play anyway. Cheers for the response. I am UK based anyway19:05
mupPR snapcraft#1864 closed: debian/control: Add patchelf to Depends: <Created by flexiondotorg> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1864>19:30
mupPR 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
kyrofasergiusens, how is the snapcraft docker image have an up-to-date patchelf? Some clients require their own docker image for CI19:37
roadmrwhere are snapd issues tracked/reported? Launchpad or github?19:57
vin-ivaroi you lot, is there any way i can build snap from source/20:00
vin-ivari dont have root access20:00
naccvin-ivar: from source/ of what?20:00
naccvin-ivar: or do you mean snapd ?20:00
vin-ivarsnapd, i mean20:00
naccvin-ivar: even if you could, you'd need someone to install snapd ...20:01
naccvin-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 float20:02
Son_Gokumvo, fedora does not use soft float20:02
Son_GokuI know that for certain20:02
zyga-ubuntuSon_Goku: so, I switched to dl.f.o and .... got update error on my next branch20:03
Son_Gokuzyga-ubuntu: I don't know what to say except Linode has problems20:03
zyga-ubuntuI ran20: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.repo20:04
Son_Gokuyeah, I saw what you changed20:04
Son_Gokuthat looked fine to me20:04
zyga-ubuntuthen + dnf install --refresh -y xdelta curl20:04
zyga-ubuntuError: Failed to synchronize cache for repo 'updates'20:04
zyga-ubuntumaybe I messed up, I'll investigate20:04
zyga-ubuntumaybe missing s//g somewhere20:04
Son_Gokumaybe the folder structure isn't right?20:04
zyga-ubuntuwhich foldr?20:04
Son_Gokuhttp://dl.fedoraproject.org/pub/fedora/linux/releases/ & http://dl.fedoraproject.org/pub/fedora/linux/updates/20:05
zyga-ubuntuSon_Goku: I pushed a small patch on top: https://github.com/snapcore/snapd/pull/4471/commits/09ecc08de5ee98cf72e02d3a4a299a137696933920:05
mupPR #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-ubuntuSon_Goku: and it worked now20:05
zyga-ubuntubut could be random :/20:05
zyga-ubuntuoh, that's silly20:05
zyga-ubuntuI commited and pushed the wrong one20:06
zyga-ubuntuI did dnf --refresh makecache20:06
zyga-ubuntuand commited this :p20:06
zyga-ubuntuI'll push next once this run is over20:06
om26erHow 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
roadmrzyga-ubuntu: sorry to poke again - where are snapd issues tracked/reported? Launchpad or github?20:10
pedronisroadmr: launchpad20:15
roadmrthanks pedronis20:16
zyga-ubuntusnapd or snappy projects20:17
roadmroh why are there two?20:17
zyga-ubuntuhistoric reasons really20:18
zyga-ubuntusnapd is the new one20:18
zyga-ubuntubut snappy is the one people look for sometimes20:18
roadmrok, I'll go there (snapd). Many thanks!20:18
pedronisroadmr: if it's urgent you should alos poke somebody20:19
roadmrpedronis: I don't think it is urgent or critical; nothing is crumbling or on fire20:19
mupPR snapd#4479 opened: spread: maybe dnf needs a refresh? <Created by zyga> <https://github.com/snapcore/snapd/pull/4479>21:31
mupPR 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!