[00:26] kyrofa: 2.35 deb worked for now, thanks! :D === jamesh_ is now known as jamesh [00:56] PR snapcraft#1862 closed: zip: support extracting non-unix zip files [02:26] Hi guys === Mert is now known as Guest80198 [02:27] Is core_3748 bugged? [02:28] On manjaro i can't mount core-3748.= [02:30] if you know the solution, can you email me? d_mert@hotmail.com [02:30] have a good day [02:56] Issue snapcraft#1668 closed: Bring in newer ld-linux and glibc libraries [02:56] Issue snapcraft#1669 closed: patchelf with ld-linux from the future [02:56] PR snapcraft#1850 closed: pluginhandler: patch and handle elf files on glibc mismatch [05:58] morning [06:25] is xfce available through snaps? i tried uappstore but couldn't find it. [07:24] re [07:34] zyga-ubuntu: morning [07:41] good morning zyga-ubuntu and mborzecki [07:44] mvo_: hey, you have earned a _ :) === mvo_ is now known as mvo [07:47] seems like fedora prepare is failing again [07:48] yes, consistently so [07:49] :( [07:49] time for manual again then [07:53] mvo: will you do it or should i? [07:54] mborzecki: please go ahead [07:54] ok [07:54] ta [07:55] mvo: idea [07:55] mvo: actually, scratch that idea :/ [07:55] zyga-ubuntu: that was a quick ide [07:55] a [07:56] yeah, nothing like talking to oneself to notice something is wrong [07:56] :) [07:56] * mvo hugs zyga-ubuntu [07:57] PR snapd#4474 opened: spread: switch fedora-26-64 back to manual [07:59] mborzecki: bonus points if you collect the log and talk to #linode people on the other IRC network [07:59] (OFTC) [08:02] good morning, snappy [08:06] kalikiana: morning [08:07] mvo: ok, I finished other prep work and I'm setting up tests on dragon now [08:07] zyga-ubuntu: ta [08:11] mvo: all tests or just main? [08:12] mvo: just to be clear, from release/2.30, run all the tests [08:12] zyga-ubuntu: yeah, correct [08:12] started [08:13] 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:18] PR snapd#4469 closed: tests: add hard-coded fully expired macaroons to run related tests [08:18] mornings! [08:18] hey o/ [08:24] mvo: 141 tests to go, that's not that many [08:27] zyga-ubuntu: yeah, but each takes ~1min or so :/ [08:27] zyga-ubuntu: at leat on the pi it takes a couple of hours [08:31] is xfce available through snaps? i tried uappstore but couldn't find it. [08:33] and probably 1h just for automake & configure in cmd :) [08:34] so far so good, 6th test in progress [08:36] hmm [08:36] has anyone created a google calendar and tried to add a hangout to it [08:36] it seems this option is gone now [08:44] mvo: hi, I reviewed #4356 (yesterday got a bit distracted) [08:44] PR #4356: many: add new `snap refresh --amend ` command [08:49] mvo: ~~12 tests out of 141, each test really takes minutes [08:49] I'll grab a coffee [08:49] jamesh: around? [08:49] zyga-ubuntu: hi [08:50] jamesh: we'll probably jump into a standup HO as I cannot add HO to the event anymore [08:50] jamesh: I'll share the link in a moment [08:52] pedronis: thank you, I have a look as soon as I have some spectre releated stuff under control [08:58] niemeyer: we're going to use the standup HO [08:59] 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] Bug #1742323: Meltdown Update Kernel doesnt boot

=== __chip__ is now known as Chipaca [09:04] mborzecki: i guess 10 retries wasn't enough for the fedora thing [09:04] ¯\_(ツ)_/¯ i wanted to push another commit anyway [09:15] pedronis: thanks, review looks very good [09:16] 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:29] mvo: why am i not making 'snap pack' run validateContainer? [09:29] Chipaca: indeed, why don't you? as a warning and with an option to disable, right? [09:29] Chipaca: indeed :) [09:29] Chipaca: I mean, it will not make snap pack fail, right? [09:30] mvo: why wouldn't it? [09:30] we might have some tests that abuse stuff [09:30] *shocked* [09:30] but I don't think it should be just a warning [09:30] it should be error [09:30] or nothing [09:30] Chipaca: hm, right, it won't even install so … +1 for fail [09:31] lets see if tests survive this ,) [09:31] mvo: maybe in a separate PR though :-) [09:31] again +1 [09:32] * Chipaca is adding a spread test to 4464 and then hopes to land it [09:38] hello, is there a way to install older revision of core snap? [09:39] haha so the snap store is returning 418 'I'm a teapot'? [09:42] mborzecki: and does GET give you coffee, as per spec? [09:43] just the teapot, the rest is DIY [09:50] PR snapd#4475 opened: overlord/snapstate: for Enable's tasks refer to the first task with snap-setup, do not duplicate [09:51] small PR cleaning up an oddity I noticed recently ^ [09:57] pedronis: a space oddity? [10:01] Chipaca: silly you :) [10:01] * Chipaca nods [10:03] pedronis: in my defense, i'm learning it on the guitar :-) [10:05] Chipaca: it's fine, it would have been funnier if it was indeed a space problem, but alas we use go fmt [10:06] though there is always shell and yaml to commit space sins [10:22] pedronis: :-) [10:27] re [10:28] mvo: we're at 59/141 now [10:28] mvo: no issues yet [10:29] PR snapd#4474 closed: spread: switch fedora-26-64 back to manual [10:33] 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:34] Chipaca: I want to make a "snap find" to the public API... [10:38] zyga-ubuntu: great, pi3 is finished here, I'm doing p2 now [10:38] mvo: cool, I'll let you know when something changes [10:38] 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:39] Chipaca: Thanks! [10:40] mvo: how long did it take? [10:51] * kalikiana taking a break, too much staring at a screen :-/ [11:00] mborzecki: oh, sorry, didn't see the question - pi3 took around 2.5h [11:03] mborzecki: mvo: could one of you mark my #4464 as 'changes requested' please so it doesn't get merged for a bit? [11:03] PR #4464: overlord/snapstate: do a minimal sanity check on containers [11:03] i just realised something needs fixing, but i don't want to close it and lose the spread test run [11:04] i'm going to go take a break, bbiab [11:04] Chipaca: marked [11:05] thanks [11:18] error: cannot list snaps: cannot list local snaps! cannot find installed snap "classic" at revision 26 [11:18] mvo: that was [11:18] 2018/01/11 12:14:55 Error executing external:ubuntu-core-16-arm-64:tests/main/listing : [11:18] mvo: it's still going, 81/141 now [11:21] zyga-ubuntu: hm, that looks strange, we may need to re-run this one test [11:22] 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] mvo, did you notice that your copre snap build failed ? [11:22] rm: cannot remove '/var/lib/apt/lists/': Is a directory [11:22] rm: cannot remove '/var/lib/apt/lists/partial': Is a directory [11:22] E: config/hooks/12-add-foreign-libc6.chroot failed (exit non-zero). You should check for errors. [11:24] seems your -print 0 re-ordering isnt liked [11:24] mvo: sure, I can re run [11:24] ogra: meh, sucks. I have a look [11:24] mvo: FYI I'm talking with linode operators about fedora issues and I'm using spread 70 to test [11:25] ogra: slightly strange on my artful this shows the right result. I guess I need to double check on xenial [11:26] yeah, it really shouldnt do any harm [11:26] (but if it does, the manpages and docs removal will have the same issue [11:26] ) [11:27] ogra: yeah, the "funny" part is that i386 build fine [11:27] heh [11:27] well, then it seems to work with the docs at least [11:28] other topic ... do we have auto-connecting of interfaces from the gadget already ... and do we have it documented somewhere) [11:29] * ogra bets pedronis would know such stuff ^^ [11:29] mvo: fedora uses a random mirror from a redirectory [11:29] *redirector [11:30] 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] mvo: but a bad sequence will probably explain the set of failures we've seen [11:30] mvo: probably spectre/meltdown result [11:30] mvo: we can pin to a specific mirror if we want [11:31] mvo: I'm also asking if linode plans to offer one [11:32] ta [11:36] https://pastebin.ubuntu.com/26365704/ [11:36] we'll need gustavo to open a ticket [11:36] I'll prepare the contents [11:36] hu? what checksum is that [11:37] aha, its just 3 [11:44] mvo: https://forum.snapcraft.io/t/issues-with-fedora-mirror/3489 for tracking [11:52] Son_Goku: ^ [11:53] zyga-ubuntu: what happens when you try to curl the URL from within the Linode system? [11:53] Son_Goku: it's random, it works most of the time in a loop [11:53] Son_Goku: it jut doesn't _always_ work [11:53] Son_Goku: I'll try curl in a sec [11:53] Son_Goku: running a test with "dnf install -y -4" now [11:53] Son_Goku: over ipv4 only [11:53] ah [11:55] metadata fetching is done by a library called librepo [11:55] https://github.com/rpm-software-management/librepo [11:55] if there's a bug in mirror selection for metadata fetching, that's where to look [11:56] also, it's not _random_ per se [11:56] Son_Goku: did you see https://pastebin.ubuntu.com/26365704/ ? [11:56] the Fedora MirrorManager returns a list of valid, fast, nearby mirrors based on the location it derives from the initial request [11:56] yeah [11:57] those mirrors come from the metalink [11:57] *all mirrors tried* sounds bad when it doesn't work [11:57] something fishy is going on [11:57] makes me think there might be an issue in librepo [11:57] but *shrugs* [11:57] btw, you can look in /var/log/dnf.librepo.log, too [11:58] thanks, I'll check [11:58] even when DNF isn't in verbose mode, all the output for metadata fetching is there [12:02] PR core#72 opened: live-build: fix order of -print0 in find [12:02] -4 seems to have helped [12:02] PR snapd#4475 closed: overlord/snapstate: for Enable's tasks refer to the first task with snap-setup, do not duplicate [12:04] PR snapd#4382 closed: cmd/snap: show header/footer when `snap find` is used without arguments [12:04] PR snapd#4423 closed: snap: provide more meaningful errors for installMany and friends [12:10] PR snapd#4476 opened: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule [12:29] mvo: another test failed, I'm at 110/141 now) [12:34] 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:35] pedronis, ack ... and helps to get rid of some hacks in products too :) [12:35] ogra_: topic is here: https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 [12:35] yeah, i just found it too :) [12:37] ogra_: to be fair it was also conflicting with interface hooks work, but that is getting close to done [12:41] 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] happy to schedule a call if that helps too, we need some definition to get that started server-side [12:45] Pharaoh_Atem: is there any official non-mirror archive I can hit? [12:55] matiasb I agree. I am fine with Robert's proposal [12:59] 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] 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 [13:22] * kalikiana going for lunch in ~10 [13:22] * kalikiana trying to finish these tedious grammar test cases til then... [13:32] mvo: https://pastebin.ubuntu.com/26366173/ [13:32] still running [13:36] Chipaca: you could use -ls and -lls together (it gets silly) [13:36] pedronis: yes [13:45] Hi guys, does anyone knows how can I change the default path when downloading a snap? [13:46] mvo: it's done [13:46] - external:ubuntu-core-16-arm-64:tests/main/listing [13:46] - external:ubuntu-core-16-arm-64:tests/main/prepare-image-uboot [13:46] those two failed [13:47] brunosfer: when you snap install or when you snap download? [13:47] brunosfer: this is not configurable AFAIR [13:47] brunosfer: what's the background, what are you trying to, maybe we can do something else [13:50] mvo: ok, I'll grab some water and let's talk [13:50] mvo: shall I re-run those two? the failure logs are in the pastebin [13:50] zyga-ubuntu: this looks not too bad, please re-run the two just for kicks and pastebin the full run [13:51] 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:52] zyga-ubuntu: the main fedora URL is dl.fedoraproject.org [13:52] download.fedoraproject.org is a redirector for things that don't support mirrorlists or metalinks [13:52] zyga-ubuntu: When I snap download. [13:52] zyga-ubuntu: thank you [13:53] 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] Son_Goku: thanks, that's useful [13:54] brunosfer: AFAIR it just downloads to the current directory, [13:57] Son_Goku: that's working, I'll run a small loop to see if that stays operational [14:00] * pstolowski lunch [14:04] PR core#72 closed: live-build: fix order of -print0 in find [14:09] 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:10] matiasb, sergiusens: Will catch up with that discussion this afternoon.. [14:11] matiasb, sergiusens: We can then have a call if necessary and you are available [14:21] niemeyer, sergiusens, sure, I'm available today/tomorrow, just let me know [14:26] 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:27] pedronis: That's easier to reason about, and also makes the seed more even with other behavior.. nice [14:31] off to pick up the kids [14:42] re [14:46] PR snapcraft#1864 opened: debian/control: Add patchelf to Depends: [14:53] PR snapd#4441 closed: snap: add usage hints in `snap download` [14:54] brunosfer: are you talking about 'snap download'? [14:59] mvo: same failures [15:00] hello. [15:00] zyga-ubuntu: could you flash the image again? the listing one is confusing, I'm checking the prepare-image one now [15:00] sorry, I fell asleep [15:04] mvo: sure, working [15:06] zyga-ubuntu: ta! [15:07] zyga-ubuntu: both failures are odd, the second less so but the first one very much so [15:07] zyga-ubuntu: as the first test does not install classic [15:07] mvo: I just realized I didn't actually flash the image earlier, it was running on edge core/kernel [15:07] mvo: I need to build an image for it and the copy it over [15:08] zyga-ubuntu: please use the image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/ [15:09] zyga-ubuntu: thats the image we need to test [15:09] mvo: sure thing [15:09] zyga-ubuntu: thank you! [15:09] sorry for the confusion, I'll hook it up ASAP [15:09] zyga-ubuntu: sorry that I take up your time :( [15:10] mvo: no worries :) feels like a good time to use the board once in a while [15:20] PR core-build#11 closed: remove cruft from the writable-paths [15:21] PR # closed: core#38, core#67, core#69, core#70, core#71 [15:24] PR # closed: core#38, core#67, core#69, core#70, core#71 [15:24] 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] 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] sergiusens: to hangout or not to hangout? which will it be? :-) [15:25] 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] 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] 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] 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:28] 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] 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] 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] snapcraft#1708, snapcraft#1714, snapcraft#1715, snapcraft#1751, snapcraft#1753, snapcraft#1794, snapcraft#1819, snapcraft#1828 [15:28] 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:29] mvo: github down [15:29] mvo: I'll get you the results later today, I need a fresh SD card (in ~40 minutes) [15:31] hrm... 503 not allowd on GitHub?! this is weird [15:33] I guess GitHub is really kinda broken today [15:34] zyga-ubuntu: ta [15:34] zyga-ubuntu: yeah github down makes me unhappy [15:34] mvo: coudn't github be down when I was sleeping [15:34] couldn't* [15:40] mvo: it's not completely down. it's more like launchpad on a normal day ;-) [15:40] try a few more times and it kinda works [15:40] I will file a github bug report [15:40] the unicorn could use a few more images [15:40] it would make reloading funnier [15:40] "see the world they said" [15:40] haha, I was thinking the same actually [15:40] kalikiana: haha [15:42] PR snapd#4477 opened: snapenv: add SNAP_ARCH_TRIPLET [15:43] mvo: nice [15:44] mvo: question [15:44] mvo: are those values areally "universal" [15:44] mvo: I was thinking that this should be a function that takes a snap info as argument [15:44] wooot, arch triplet! awesome! [15:44] mvo: so that we can return the right values for say, debian and fedora [15:44] kyrofa: ^^ [15:44] mvo: if for any reason they actually don't mean the same thing [15:45] zyga-ubuntu: I was asking Son_Goku earlier about the fedora arch triplets but maybe he missed the message [15:45] mvo: and at the place where you call it you can easily pass the info [15:45] zyga-ubuntu: its tricky, in theory these triplets are whatever you tell your compiler they should be [15:45] mvo: then you can still use $SNAP_ARCH_TRIPLET all the time [15:45] and it just matches your base [15:45] mvo: right exactly that's why I think it should be base-bound [15:46] zyga-ubuntu: yeah, making them base-bound would probably the best, I need to learn more about the fedora world [15:46] mvo: it could even be a meta-data on base snap somewhere [15:46] mvo: but for now it's enough if this is the value we return for base-16 and base-18 [15:46] mvo: I suspect ikey might want to chime in too [15:47] zyga-ubuntu: +1 [15:48] 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] mvo: not all [15:48] mvo: solus doesn't AFAIR [15:48] mvo: I have a swarm of VMs to check if you want to know [15:49] * zyga-ubuntu wishes to be exactly as ignorant as mvo ;-) [15:50] 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] zyga-ubuntu: anyway, not important, please don't let me distract you [15:56] mvo: hm? [15:57] Son_Goku: you told me at some point fedora is using more detailed architecture defintions - where can I read more about this [15:57] https://github.com/rpm-software-management/rpm/blob/master/platform.in + https://github.com/rpm-software-management/rpm/blob/master/rpmrc.in [15:58] thanks Son_Goku [15:58] 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] PR rpm-software-management/rpm#360: elfdeps: Add full multiarch deps support [15:59] mvo: in Fedora, we do /usr/ for foreign architectures for cross targets [15:59] and the triple is defined as the triple coming from the compiler (gcc) [15:59] 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] mostly the same [15:59] I think there's some differences w.r.t. ppc64 triples [15:59] but it's been a while [16:00] Son_Goku: cool, that sounds very promising [16:00] Chipaca: thanks for your suggestion I think I call it normalizedGnuTriplet [16:01] you can actually query this on rpm using 'rpm --target --eval "%_target_platform"' [16:02] not sure if it triggers the correct mappings w.r.t. isa aliasing, but it gets you close [16:02] $ rpm --target amd64 --eval "%_target_platform" [16:02] rpm: --target: unknown option [16:05] :) [16:05] * popey hugs mvo for https://github.com/snapcore/snapd/pull/4477 ( cc kyrofa ^) :D [16:05] PR #4477: snapenv: add SNAP_ARCH_TRIPLET [16:05] what version of rpm is there? [16:05] (it worked on my Fedora 27 system with rpm 4.14, so...) [16:06] Son_Goku: what does it output for amd64,i386,armhf,arm64 on rpm (out of curiosity)? [16:07] x86_64-redhat-linux-gnu, i386-redhat-linux-gnu (though fedora uses i686-redhat-linux-gnu), , [16:07] 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] and armhf is not a real thing [16:07] for Fedora, we have armv7hl-redhat-linux-gnu for our 32-bit arm arch [16:07] 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:08] Son_Goku: I get that on 4.12.0.1 on ubuntu xenial, and 4.13.0-rc1 on fedora 24 [16:08] Son_Goku: woah, that one is totally different - do you have a 32bit arm with hardware float? [16:08] iirc, debian never defined the vendor field, and it's easy enough to chop out when scanning triple [16:08] mvo: yep [16:08]