**** BEGIN LOGGING AT Wed Jan 04 03:00:02 2017 Jan 04 12:12:17 hello all Jan 04 12:12:39 i wann check that our qemuarm-64 machine support graphics? Jan 04 12:12:54 will sato image come up on that machine? Jan 04 13:06:53 hmmm did i miss something, there is no longer a master branch for meta-openembedded? http://git.openembedded.org/meta-openembedded/refs/heads Jan 04 13:09:15 hmm Jan 04 13:09:33 nrossi, that would make no sense Jan 04 13:10:04 Crofton|work: maybe the server content is missing? Jan 04 13:10:09 github appears to have one Jan 04 13:10:14 via web interface Jan 04 13:11:01 Crofton|work: yep but newest commit on github is from Nov last year. Jan 04 13:11:25 JaMa, tends to batch things and subject to long builds Jan 04 13:11:34 and was hopefully off over holiay Jan 04 13:11:49 no master-next Jan 04 13:11:57 also fetching from the git.openembedded.org with ls-remote shows no ref. And a clean clone gives 'warning: remote HEAD refers to nonexistent ref, unable to checkout.' Jan 04 13:12:06 hmmm Jan 04 13:12:28 need to ping ka6sox also, but he is hopefully asleep Jan 04 13:12:47 he did some server work over the holiday period Jan 04 13:13:52 Crofton|work: it's all in git, just cgit is broken Jan 04 13:14:15 well at least it was few hours ago Jan 04 13:14:15 JaMa: but the ref is missing :| Jan 04 13:14:24 I was pushing some changes 2-3 hours ago Jan 04 13:15:11 possibly that git hook for updating patchwork went crazy Jan 04 13:15:46 hmm right it got removed today Jan 04 13:15:49 OE @ ~/meta-openembedded $ git remote prune origin Jan 04 13:15:49 Pruning origin Jan 04 13:15:49 URL: git://git.openembedded.org/meta-openembedded Jan 04 13:15:49 * [pruned] origin/master Jan 04 13:15:49 * [pruned] origin/master-next Jan 04 13:15:51 refs/remotes/origin/HEAD has become dangling! Jan 04 13:16:16 OE @ ~/meta-openembedded $ git push origin master Jan 04 13:16:16 Everything up-to-date Jan 04 13:19:46 I've re-opened https://bugzilla.yoctoproject.org/show_bug.cgi?id=10762 Jan 04 13:21:01 and last change from Nov on github also looks wrong, last in git before my today's push was from CommitDate: Sat Dec 17 10:57:42 2016 -0500 Jan 04 13:21:14 thanks jackmitch_work Jan 04 13:21:17 er JaMa Jan 04 13:21:30 but maybe you were looking on author date which is Nov 30 Jan 04 13:25:09 JaMa: ah ok, i was just looking at the github UI which hides commit date Jan 04 13:40:29 interesting the same happened in -contrib repository which probably doesn't have this hook Jan 04 13:40:33 e.g. http://git.openembedded.org/meta-openembedded-contrib/log/?h=jansa/master Jan 04 14:38:50 I'm guessing I'm not the only one seeing this fail this morning... Jan 04 14:38:56 Updating layer meta-openembedded Jan 04 14:38:56 Your configuration specifies to merge with the ref 'refs/heads/master' Jan 04 14:38:56 from the remote, but no such ref was fetched. Jan 04 14:38:56 git pull in layer meta-openembedded failed. Giving up. Jan 04 14:41:08 it's already been mentioned a couple of hours ago Jan 04 14:45:26 also... apache2 in meta-oe is failing. If someone could add httpd-2.4.23.tar.bz2 to the mirror that would be great. Jan 04 14:49:24 another recipe using the wrong URL i guess? Jan 04 14:51:26 rburton: a new version came out so it's in archive now instead of in the normal location Jan 04 14:51:33 yeah Jan 04 14:51:37 that's what i mean by wrong url Jan 04 14:51:57 proper fix is probably change to the new version but in the mean time may as well mirror it Jan 04 14:52:26 proper fix is to fix the URL, then work on an upgrrade that's been tested Jan 04 14:53:21 rburton: I'll double check no one has sent a patch and send one then Jan 04 14:53:46 relevant changes to oe-core: bitbake.conf: change APACHE_MIRROR to point at archive.apache.org Jan 04 14:54:17 ah ok Jan 04 14:54:20 so the default mirror list contains archive.apache.org so it should be falling back to that anyway, so maybe your distro is overriding that Jan 04 14:54:51 don't think so. I'll look at that. I think the mirror location is wrong. Jan 04 14:55:37 oh the mirror list was extended in december so maybe you don't have that commit? Jan 04 14:55:54 I'm using morty, so if it's only in master probably so Jan 04 14:56:55 * georgem checks Jan 04 14:59:20 odd; I thought the discussion on the list came out with appending to the MIRROR as violating the principle of least surprise... Jan 04 15:06:10 IMO the recipe itself should handle its own mirrors, unless the url is used by many recipes, which shouldn't be the case for apache Jan 04 15:06:12 morning all Jan 04 15:09:08 morning kergoth Jan 04 15:10:39 I joined after this discussion started but as paulg points out fray followed up to the MIRRORS suggestion in the thread on my apache2 RR Jan 04 15:11:01 we discussed this suggestion and it was nixed Jan 04 15:12:07 my RR was superceded by a proper apache2 uprev RR Jan 04 15:12:33 I don't really see how using a mirror violates anything, that's exactly the sort of thing mirrors are intended for, but whatever. Jan 04 15:13:14 kergoth, I think the gripe was that papering over the fact that apache was as old as dirt was not a good thing. Jan 04 15:13:38 paulg: I'm not arguing it shouldn't be updated, only that having the recipe break every time upstream bumps it is pointless. Jan 04 15:13:46 fortunately someone did the update. Jan 04 15:14:28 this wasn't just a version bump, it was a "push old crap off a cliff" flag day by the apache folks. Jan 04 15:14:39 something is messed up. the apache mirrors show up in the list but it's never attempting to use them. debugging it... Jan 04 15:16:20 I suppose for branches which are 'maintenance' having things continue to work when upstream moves them around makes some sense Jan 04 15:16:49 I would still think that if upstream moves something to an archive it shows that folks should use something newer Jan 04 15:17:13 especially for a pkg like apache2 which is the subject of many attack vectors Jan 04 15:19:27 if we're monitoring CVEs and using the update check system, we'd know that already, regardless of whether the fetch succeeds or fails, and for more than just one recipe. Jan 04 15:21:45 CVEs? I thought that was all Chicken Little stuff. Jan 04 15:21:47 * paulg runs. Jan 04 15:21:51 ha Jan 04 15:22:03 hah Jan 04 15:22:35 kergoth: anyways, /me is no expert and tends to keep out of these types of discussions Jan 04 15:23:03 input and thoughts are always welcome, even so-called experts aren't infallible :) Jan 04 15:23:12 I was just working to revive meta-cloud-services and was surprised to find that apache2 was broken Jan 04 15:23:39 it is fixed/in the process of being fixed, so I can move on to other fun Jan 04 15:36:08 AFAICT mirrors.bbclass is totally screwed up. downloads.yoctoproject.org and sources.openembedded.org are the only mirrors ever attempted because they are the only ones with a pattern specified (example: https?$://.*/.*) Jan 04 15:36:23 aah Jan 04 15:36:24 not sure what you mean by that Jan 04 15:36:37 you don't need to specify every url component to set a mirror Jan 04 15:37:21 kergoth: I'm looking at the logs right now. It only ever tries those two. If I add https?$://.*/.* in front of anything else then it will try those too. Jan 04 15:38:21 again, no idea what you're talking about. you don't have to use a pattern to do a search/replace Jan 04 15:38:40 it looks for what's on the left, and replaces it with what's on the right, after splitting both urls and doing so comopnent-by-component Jan 04 15:38:54 if it doesn't find what's on thel eft, obviously it's not going to replace anything Jan 04 15:39:39 kergoth: do you have a log.do_fetch that attempts anything else in mirrors.bbclass? if so I'd like to see it Jan 04 15:40:06 maybe something else is broken in my setup. *shrug* Jan 04 15:42:59 i use the mirrors mechanism with straight search/replace of strings on a regular basis, both with sstate and regular downloads, both with premirrors and mirrors. don't have a test case handy, since you're talking about MIRRORS, which are only tried if both premirrors and the SRC_URI failed Jan 04 15:44:45 * kergoth clones a fresh setup, forces premirrors to mirrors, empties mirrors, isolates DL_DIR, and tries fetching apache2 Jan 04 15:44:46 kergoth: The URL for apache2 in meta-openembedded is broken. Try that if you want to test it. Jan 04 15:46:49 kergoth: I'm using bitbake 1.32, if it works for you let me know which version of bitbake you're using and I'll try it again with that. Jan 04 15:55:19 georgem: bitbake.conf sets APACHE_MIRROR to archive.apache.org. meta-webserver's apache2 recipe doesn't obey APACHE_MIRROR. so the replacement of ${APACHE_MIRROR} in MIRRORS does nothing. if you force APACHE_MIRROR to the same host used by the recipe, then the replacement happens, and the fetch succeeds. MIRRORS works exactly the way it's supposed to, just the recipe had a bug. Jan 04 15:56:43 verified this behavior locally Jan 04 15:57:49 kergoth: okay, that makes sense. thanks Jan 04 15:58:47 np Jan 04 15:59:18 as i said earlier, it's a search/replace. if it doesnt' find what's on the left, it doesn't replace with what's on the right. in this case it didn't find the search pattern, since it didn't exist in the url Jan 04 15:59:40 the only real gotcha with mirrors handling is the fact that the pattern is isolated to the url component, which isn't intuitive, but is powerful Jan 04 16:00:04 i.e. http://.* won't replace the whole path, only the 'host' component,since it splits the url and replaces component by component Jan 04 16:00:21 hence the common usage of .*/.* Jan 04 16:01:22 so if the recipe had obeyed APACHE_MIRROR, the fetch failure would never have occurred :) might want to propose fixing that in addition to the version bump Jan 04 16:01:26 * kergoth gets more coffee Jan 04 16:13:30 Anyway, good to know exactly how that works and that recipes should use the _MIRROR variables when available. Jan 04 16:16:07 When master branch of meta-openembedded comes back online I'll make/send a patch to change apache2 to use APACHE_MIRROR. Jan 04 18:14:28 JaMa, what is broken about cgit? **** ENDING LOGGING AT Thu Jan 05 03:00:00 2017