*** jjardon [sid723@gateway/web/irccloud.com/x-hfsyycfifdyunias] has joined #baserock | 00:06 | |
*** DavePage_ [~dpage@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:06 | |
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 00:09 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 00:09 | |
*** DavePage [~dpage@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 264 seconds] | 00:09 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:11 | |
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:11 | |
*** cosm [~Unknown@host86-190-190-73.range86-190.btcentralplus.com] has quit [Ping timeout: 244 seconds] | 00:15 | |
*** cosm [~Unknown@host81-147-169-75.range81-147.btcentralplus.com] has joined #baserock | 00:28 | |
*** jjardon [sid723@gateway/web/irccloud.com/x-hfsyycfifdyunias] has quit [Ping timeout: 244 seconds] | 00:33 | |
*** jjardon [sid723@gateway/web/irccloud.com/x-hbwbsjmcgjwswtqa] has joined #baserock | 00:43 | |
*** persia_ [quassel@ubuntu/member/persia] has quit [Quit: No Ping reply in 180 seconds.] | 01:13 | |
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 01:13 | |
*** cosm [~Unknown@host81-147-169-75.range81-147.btcentralplus.com] has quit [Ping timeout: 255 seconds] | 03:18 | |
*** tinsulpop [~kadams@cpe-024-088-245-034.nc.res.rr.com] has joined #baserock | 03:34 | |
tinsulpop | hopefully not a dumb question: any known issues with http://git.baserock.org? | 03:52 |
---|---|---|
tinsulpop | git.baserock.org seems either down or unreachable. | 03:55 |
radiofree | tinsulpop: yep I think it's down | 04:19 |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 04:28 | |
*** mariaderidder [~maria@213.16.35.194] has joined #baserock | 07:08 | |
*** ssam2 [~ssam2@213.16.35.194] has joined #baserock | 07:33 | |
Mode #baserock +v ssam2 by ChanServ | 07:33 | |
petefoth | tinsulpop: still down sadly due to an incodent at the hosting company | 07:39 |
ssam2 | I believe this is the issue: http://status.datacentred.io/pages/incident/53e53a3caf49cecb5f00014e/54b4dd4a22de98fe5e0001bb | 07:48 |
perryl | i'm guessing no news on exactly when everything will be back up and running again? | 07:48 |
*** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:01 | |
mike is now known as Guest87865 | 08:01 | |
petefoth | perryl: good guess! | 08:01 |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:30 | |
DavePage_ is now known as DavePage | 08:38 | |
*** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:51 | |
*** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 08:55 | |
*** a1exhughe5 [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:55 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:05 | |
* paulsherwood hopes that perryl and others have access to local troves in the meantime | 09:21 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:23 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:35 | |
pedroalvarez | Hi guys! I'm restoring a backup of g.b.o. I think that the quickest way to do it is: Disable lorry controller and restore just the gits. So when the real g.b.o is back we only have to sync gits | 09:43 |
persia | Seems reasonable. Do we believe there are commits not in the backup? | 09:44 |
Kinnison | that's certainly a reasonable way to get started | 09:44 |
Kinnison | persia: the backup is, I believe, from a time after most basrockers will have ceased work for the day | 09:45 |
Kinnison | so *hopefully* not | 09:45 |
pedroalvarez | indeed, hopefully :( | 09:45 |
straycat | I imagine most people keep copies of repos they work with locally, so they can push any commits that aren't at the remote | 09:45 |
persia | Kinnison: My concern was for the potential for commits that may have happened between the backup time and the outage start. I don't know the times in enough detail, so perhaps your answer answers that as well. | 09:46 |
persia | Anyway, if we don't expect any commits since backup, then I think it makes sense to turn on lorry controller in the restored location: while it increases sync load, it isn't likely to break anything, and restores complete operation. | 09:46 |
Kinnison | I guess it depends on whether pedro is restoring somewhere he expects to be able to take the load of lorrying too :_) | 09:48 |
Kinnison | pedroalvarez: Either way, restore the git repos first because then people can start working | 09:48 |
pedroalvarez | that's true - so I'll restore git, then start the git-daemon and change the DNS. Then restore lorry data, and enable the lorry controller. | 09:48 |
persia | That sounds like an excellent plan. | 09:49 |
pedroalvarez | Kinnison: yeah, it's in its old location, so it will be able to lorry :) | 09:49 |
Kinnison | pedroalvarez: sounds good | 09:49 |
pedroalvarez | ANNOUNCEMENT: git services of git.baserock.org will be back in few minutes. Lorry-controller will be disabled until its data is restored. | 10:03 |
DavePage | woop woop | 10:04 |
paulsherwood | including dns? | 10:05 |
pedroalvarez | yup! | 10:06 |
* DavePage will change IPs when pedroalvarez tells me to | 10:06 | |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:07 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 10:07 | |
pedroalvarez | ANNOUNCEMENT: git services of git.baserock.org are up and running. | 10:21 |
jmacs | woohoo | 10:22 |
persia | \o/ | 10:22 |
franred | pedroalvarez, should I expect to pull ssh://git@git.baserock.org/baserock/local-config/lorries.git without error? | 10:29 |
franred | pedroalvarez, http://paste.baserock.org/dikefukihi | 10:30 |
pedroalvarez | erm.. you should, let me check if something is wrong | 10:30 |
pedroalvarez | this is odd | 10:32 |
pedroalvarez | I confirm that I can't clone using ssh | 10:33 |
pedroalvarez | problem spotted | 10:34 |
pedroalvarez | fixing | 10:34 |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 10:44 | |
*** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:44 | |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:44 | |
pedroalvarez | franred: Is it wokring now? | 10:51 |
franred | pedroalvarez, yes | 10:52 |
franred | is g.b.o.fully operational? can we pull, push, add lorry files, etc? | 10:52 |
pedroalvarez | franred: No, lorry controller is still disabled, that will take some hours to restore. Git services are restored though, so you can pull/push | 10:54 |
franred | pedroalvarez, cheers for the info | 10:56 |
straycat | Zara_, Alright with you if I put the import tool guides into a single directory? | 11:00 |
Zara_ | within the guides directory? yes, but the old rubygems tutorial url needs to point to a redirect or something | 11:01 |
Zara_ | meant to do this yesterday, forgot | 11:01 |
* straycat nods | 11:01 | |
Zara_ | cool :) | 11:02 |
petefoth | Zara_: what / where is the latest version of your 'Import Tool' tutorial? | 11:03 |
Zara_ | petefoth: http://wiki.baserock.org/guides/import-tool/ | 11:03 |
petefoth | Zara_: ta! | 11:04 |
straycat | done! broken links for all! | 11:11 |
straycat | will fix | 11:11 |
Zara_ | cool, most don't probably don't matter but the rubygems tutorial link has been around for a while and people might have it bookmarked | 11:12 |
Zara_ | *most probably don't | 11:13 |
straycat | Oh heh, no I meant I forgot to replace import-tool- with import-tool/ in all the guides >.> anyhow fixed now <.< | 11:18 |
Zara_ | oh, right. :P okay, I can stick something up on the old rubygems page now, if you want | 11:19 |
paulsherwood | franred: what's with this pcre2 thing? | 11:19 |
franred | paulsherwood, it is the new version of pcre, perl compatible regular expresions | 11:20 |
paulsherwood | so upstream has decided to have a new repo for future? | 11:20 |
paulsherwood | leaving the old one? | 11:20 |
franred | paulsherwood, that is what they say in their webpage http://www.pcre.org/ | 11:21 |
paulsherwood | ok, great. | 11:21 |
paulsherwood | i've +2 on list | 11:22 |
franred | paulsherwood, cheers | 11:22 |
straycat | Zara_, stick what where? :3 | 11:23 |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 11:23 | |
pedroalvarez | I wonder if we move lorry files out of the lorries folder, lorry-controller will stop lorrying it or also remove the repo? | 11:24 |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:24 | |
Zara_ | straycat: a page with a redirect message on where the rubygems tutorial used to be | 11:24 |
straycat | oh, you could just link directly | 11:24 |
Zara_ | ? | 11:25 |
Zara_ | How would I do that? | 11:25 |
pedroalvarez | but a page with a redirect link is better so the user knows that the current page will disappear | 11:25 |
straycat | actually yes ignore me | 11:25 |
Zara_ | okay, I'll get on it :) | 11:26 |
Zara_ | message up | 11:31 |
pedroalvarez | ANNOUNCEMENT: All the services of git.baserock.org have been restored. Now it is fully operational. | 11:34 |
Kinnison | excellent, thanks pedroalvarez | 11:35 |
straycat | woohoo | 11:35 |
Zara_ | :D | 11:35 |
paulsherwood | ) | 11:35 |
DavePage | pedroalvarez: Should I change the DNS of lorry.baserock.org ? | 11:35 |
paulsherwood | :) | 11:35 |
pedroalvarez | DavePage: yes, but of trove.baserock.org please :) | 11:36 |
DavePage | Bah sorry | 11:36 |
DavePage | OK, setting trove.baserock.org to 5.9.125.66 | 11:36 |
pedroalvarez | franred: http://git.baserock.org/cgi-bin/cgit.cgi/delta/pcre2.git/ lorried :) | 11:37 |
franred | pedroalvarez, cheers | 11:37 |
pedroalvarez | wasn't me, was lorry-controller itself :) | 11:38 |
* straycat wonders how people would feel about increasing the width of the preformatted text box on wbo | 11:39 | |
straycat | http://wiki.baserock.org/guides/import-tool/pypi/ here be scrollbars | 11:39 |
Kinnison | the issue is that the style is to have a narrow column for the page | 11:40 |
straycat | but we have long paths :( | 11:40 |
Kinnison | this is to reduce strain because apparently people read shorter lines more easily | 11:40 |
* straycat nods | 11:40 | |
straycat | it's true | 11:40 |
Kinnison | use judicious insertion of backslashes and newlines in sample shell :-) | 11:40 |
straycat | i guess a newline between the path and the command might be ok | 11:42 |
bashrc | when trying to cross-bootstrap I'm getting the error: ERROR: Couldn't find morphology: strata/build-essential/stage2-linux-api-headers.morph | 11:42 |
bashrc | see http://wiki.baserock.org/x86_64_to_x86_32 | 11:43 |
Zara_ | straycat: yay! :) I can go through it and fix links and things, if you want (eg: info on installing and updating the tool (and other generic things) is now on the import tool quickstart page). There's also now a section on the 'could not find refs' error on the import tool troubleshooting page, so that error can probably be extracted from the pkg-specific tutorials. | 11:45 |
straycat | Zara_, that guide's not finished | 11:47 |
Zara_ | okay, I'll leave it alone for now. :) | 11:47 |
pedroalvarez | bashrc: when did that error happened? before or after g.b.o was restored? | 11:48 |
Zara_ | (I read 'here be scrollbars' as 'here's a guide! shame about the scrollbars.' :P) | 11:48 |
jmacs | ssam2: Can you remind me why the x-fields (like x-build-dependencies-rubygems) were in the chef morph files and why they need to be removed? I need something to put in the commit log. | 11:49 |
bashrc | pedroalvare: after | 11:49 |
tlsa | straycat: http://paste.baserock.org/daperiwaxi <-- that would make it use the full width of the window, but as Kinnison said, its prob. best to avoid long lines | 11:49 |
pedroalvarez | bashrc: hmm.. odd then | 11:49 |
Kinnison | tlsa: oddly, I have a similar set of rules set in my user-css for the baserock wiki | 11:49 |
tlsa | :) | 11:50 |
Kinnison | tlsa: because I find artificial width-restriction on sites to be massively irritating | 11:50 |
straycat | i'm now less sure about dropping backslashes everywhere | 11:50 |
Kinnison | why? | 11:50 |
straycat | i don't know, most tutorials i've read seem to manage to convey preformatted stuff without resorting to that | 11:51 |
Zara_ | I personally don't like backslashes b/c it then means that if I use the command in a terminal (copied into a textfile first, jic!), I can't just press 'up' if I want to repeat the command. Though that might just be me not knowing how to get around it. | 11:52 |
Kinnison | Erm you should be able to | 11:52 |
straycat | https://wiki.debian.org/Exim debian wiki seem to have wider preformatted text boxes | 11:52 |
Kinnison | shells are supposed to combine backslashed stuff | 11:52 |
tlsa | the other thing is wiki.baserock.org is useing a very lart font size for preformatted text | 11:52 |
tlsa | *large | 11:52 |
straycat | tlsa, good point | 11:53 |
Kinnison | getting rid of the extra left padding/margin? and reducing the font size would be a good step to not needing backslashing | 11:53 |
straycat | if we could tweak wbo to be a bit more like debian wiki, that might work? | 11:53 |
Zara_ | Kinnison: I find that pressing 'up' only gives me one line at a time. the command is combined when first used, though. | 11:54 |
Kinnison | Zara_: Hmm, might be a failing in the particular shell you are using | 11:54 |
jmacs | Same here Zara_. Backslashed commands are a real pain to copy and paste | 11:54 |
* Kinnison hugs zsh which makes them easy and comfortable | 11:55 | |
* Kinnison should really sort out zsh in devel systems | 11:55 | |
Zara_ | Kinnison: yeah, I think I use the baserock default shell (I don't remember changing anything). | 11:55 |
jmacs | Kinnison: The wiki pages have to work for real users | 11:55 |
jmacs | Which means gnome-terminal and bash | 11:55 |
Kinnison | jmacs: I can make zsh the default for baserock devel systems, and I already use gnome-terminal :-) | 11:56 |
* Kinnison appreciates he is a strange isolated case :) | 11:56 | |
jmacs | But you're not just pasting into baserock | 11:56 |
Zara_ | (though I do run it from my terminal, which is bash) | 11:56 |
tlsa | straycat: pushed a change which reduces the font size for pre | 11:56 |
straycat | tlsa, cool | 11:57 |
Kinnison | bash seems to fold backslashed pasted commands into single lines for history | 11:57 |
Kinnison | (just tested) | 11:57 |
Kinnison | so busybox ash is probably the issue here | 11:57 |
straycat | tlsa, would you be against setting the width to auto? | 11:57 |
straycat | i'm guessing that's what debian wiki is doing? | 11:57 |
tlsa | yeah, the only issue is that my previous paste for that is a quick fix. It needs various margins tweaking to make it look properly balanced without the max-width | 11:58 |
straycat | ahh | 11:59 |
jmacs | Kinnison: If you want to run a command as-is, pasting a backslashed command works. But bash will only let you edit the last physical line pasted - so if you want to change anything before that, you're stuck | 11:59 |
jmacs | You can't even add a # at the start of the line to put it into the command history | 11:59 |
Kinnison | I see | 12:00 |
Kinnison | that's a failing in bash's readline usage then :-( | 12:00 |
persia | Your bash differs from mine. | 12:00 |
Kinnison | however this is moot since straycat is sorting the formatting instead :-) | 12:01 |
straycat | I changed my mind, debian wiki and nix os wiki seem to use auto rather than fixed width | 12:02 |
straycat | so I think we should too | 12:02 |
Zara_ | ooi, why does this sometimes happen when I try to edit the wiki from the page itself: "Error: OpenID failure: time_bad_sig: Return_to signature is not valid." ? It seems erratic; some days it works fine, and other days I can only use git clone if I want to edit (irritating for just fixing a typo or formatting). | 12:08 |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 12:10 | |
* SotK runs the morph test suite a few times, then discovers a huge number of scripts/git-daemon-wrap processes left over | 12:10 | |
straycat | SotK, Possibly, I've not seen that before | 12:16 |
pedroalvarez | SotK: oh! I've seen that once | 12:22 |
SotK | I suspect its caused by some yarns not doing `FINALLY the git server is shut down` | 12:23 |
jmacs | Why is ant lorried (a) in a file called "java.lorry" and (b) to a repository called "java/ant" ? | 12:26 |
straycat | I guess presumably because ant is typically used for java stuff? | 12:26 |
persia | a) is probably because someone tried to do all the java stuff at once, and b) because of a) | 12:26 |
SotK | I'd imagine the idea was for java.lorry to contain lorries of various java programs (like python-packages.lorry) | 12:27 |
SotK | (I'm assuming ant is written in java here) | 12:27 |
radiofree | is there a mirror for gbo? | 12:27 |
jmacs | SotK: Nope | 12:27 |
SotK | jmacs: well in that case, I have no idea and agree it seems misleading | 12:27 |
jmacs | SotK: Sorry, ant is written in javas | 12:28 |
jmacs | java | 12:28 |
jmacs | But we don't put other programs in hierarchies based on their programming language | 12:28 |
persia | radiofree: Not specifically. I think cache.baserock.org has a 2-hour out-of-date mirror most of the time (may not work right now). | 12:28 |
persia | radiofree: Most folk who want one tend to run a local trove. | 12:29 |
jmacs | I'm trying to figure out if I should put chef repos into some sort of hierarchy. There seems to be a lot of hierarchy in lorries at the moment, but I can't figure out the reasoning behind it | 12:32 |
pedroalvarez | it will be difficult to understand the reasoning... :/ | 12:32 |
jmacs | As another example, there's "gitano/luacov", although I can easily imagine luacov being used by things other than gitano | 12:33 |
pedroalvarez | it depends on who has created/reviewed the lorries | 12:33 |
persia | The practice seems to often be to put bundles of stuff into a single lorry, possibly with namespacing if the creator thinks it relevant. | 12:37 |
persia | There seems to be little effort on the part of reviewers to verify more than whether it works. | 12:37 |
persia | I'm not sure this is the best way to do it, but it is how we seem to have been doing it, so probably a safe procedure to follow. | 12:38 |
ssam2 | jmacs: it was a way for the import tool to store extra metadata about the projects/packages that the .morph files represented | 12:42 |
ssam2 | jmacs: but we later moved that info into separate .foreign-dependencies files | 12:42 |
jmacs | ssam2: Thanks! | 12:48 |
Zara_ | hm, trying to use cycle.sh and baserock is hanging at the 'deciding on task order' step. Is this connected to the g.b.o outage, and do I need to change some settings? | 12:54 |
pedroalvarez | ssam2: I spotted an error the other day regarding upgrading a trove. I guess you are intersted now that you are upgrading a trove. | 12:55 |
pedroalvarez | ssam2: there is a bug in systemd (fixed in the commit 0ffce503cd6e5a5ff5ba5cd1cc23684cfb8bb9e3) that makes `systemctl enable` not usable for template units. This is a critical bug for deploying/upgrading a trove, since the lorry-controller-minions won't be enabled. | 12:57 |
pedroalvarez | I didn't have time to add this commit to baserock and check if that fixes the issue | 12:58 |
ssam2 | pedroalvarez: ok. upgrading to 14.46 has gone fine | 12:59 |
ssam2 | but i'll make sure nobody upgrades to master / 15.02 (which they can't here anyway right now) | 12:59 |
ssam2 | please note the issue, might be able to fix in a while | 13:00 |
pedroalvarez | upgrades from 14.46 to master should be fine, since the units are now enabled :) | 13:00 |
ssam2 | ah, cool | 13:00 |
*** ssam2 [~ssam2@213.16.35.194] has quit [Remote host closed the connection] | 13:01 | |
straycat | I think I'm almost happy with http://wiki.baserock.org/guides/import-tool/pypi/ now, I doubt anyone has to try it out, but if you notice any mistakes or have any suggestions let me know | 13:12 |
pedroalvarez | straycat: I'll give it a go to import a couple of python packages, although I think they don't have dependencies :) | 13:14 |
straycat | cool, still worth trying it out in case i've missed something | 13:15 |
SotK | Zara_: if you are still having problems, try adding --verbose to the "morph build" line in cycle.sh | 13:20 |
Zara_ | SotK: thanks. It seems to be hanging here: | 13:24 |
Zara_ | 2015-01-14 13:23:23 [Build 156/163] [nodejs-devel] stratum nodejs-devel is cached at /src/cache/artifacts/4ef57d547fe233cf087cb587644b2627844aabc7efcb9fbe10034ea284bbdf33.stratum.nodejs-devel | 13:24 |
jmacs | Zara_: Does your /src/morph.conf have "artifact-cache-server = http://cache.baserock.org:8080/" in it? | 13:25 |
Zara_ | jmacs: unless it's the default, probably not; I'll check now | 13:25 |
jmacs | And does anyone know if cache.baserock.org is working? (It wasn't yesterday) | 13:26 |
Zara_ | jmacs: it does have that in it, yes | 13:26 |
SotK | I doubt it, its hosted in the same place as g.b.o was | 13:26 |
jmacs | Zara_: Comment it out, see if that helps | 13:27 |
Zara_ | cool, thanks :) | 13:27 |
bashrc | trying to run cycle.sh perhaps this would better be called upgrade.sh and have something like a manpage | 13:59 |
Zara_ | hahaha, I put the '--verbose' flag on the command line, before I found out it had to go in the cycle.sh file, so I just discovered that I accidentally created a system called '--verbose', which I don't know how to remove (b/c the 'system-version-manager remove' command reads its name as a flag). I assume I need to escape the -- somehow... | 14:14 |
rjek | Zara_: rm -- --verbose | 14:17 |
persia | bashrc: cycle.sh was written specifically to handle the case of bouncing in and out of a development environment trying things. If you're looking for an upgrade, you may be perfectly satisfied with `morph upgrade`. | 14:17 |
DavePage | -- is GNUese for "don't treat anything after me as an option" | 14:17 |
* persia wonders if system-version-manager happens to interpret it that way | 14:18 | |
pedroalvarez | hehe, I don't think so | 14:18 |
pedroalvarez | system-version-manager remove '-- --verbose' ? | 14:19 |
bwh | DavePage: It is not GNUese, it is understood by the Unix standard getopt() function too | 14:19 |
paulsherwood | bashrc: have you seen http://wiki.baserock.org/guides/build-deploy-cycle/ ? | 14:19 |
bwh | DavePage: not that all standard commands on Unix-like systems consistently use it | 14:20 |
persia | paulsherwood: Why `git reset --hard ${BRANCH}` as opposed to `git checkout ${BRANCH}`? | 14:20 |
bashrc | morph upgrade doesn't appear to be a recognised subcommand | 14:21 |
paulsherwood | persia: because it keeps us in the branch that morph understands. git checkout puts us somewhere else | 14:21 |
persia | Ah. For folk who don't use `morph edit`, that isn't important :) | 14:22 |
bashrc | cycle.sh runs into "Insufficient space on disk" | 14:22 |
persia | bashrc: Apologies: I thought that patch had landed: try `morph deploy --upgrade` | 14:22 |
paulsherwood | bashrc: how many things in system-version-manager list ? | 14:23 |
bashrc | persia: ERROR: Too few arguments to deploy command | 14:23 |
persia | bashrc: You'd need to supply other bits, like the cluster argument, and the cluster variables. | 14:23 |
persia | Still, `morph help deploy` should talk about --upgrade. | 14:24 |
* SotK has a `morph upgrade` command, so its in master | 14:24 | |
paulsherwood | bashrc: please update to a more recent morph. upgrade is a valid command | 14:24 |
* paulsherwood wonders when bashrc created his br machine | 14:24 | |
persia | Zara_: If your attempts to remove the '--verbose' system with system-version-manager come to naught, it can also be done manually (if you boot a different system) by playing with btrfs, but perhaps best to avoid that if you can. | 14:25 |
pedroalvarez | bashrc: clusters/upgrade-devel.morph has some useful info | 14:25 |
paulsherwood | but in any case, if cycle.sh can't find enough space, neither will morph deploy | 14:25 |
persia | Yes: this is a different class of issue. | 14:27 |
franred | jmacs, I've reviewed you lorry patch, please read my review before merging your patch | 14:27 |
jmacs | Will do (after standup) | 14:28 |
Zara_ | pedroalvarez' suggestion worked, thanks. :) | 14:29 |
pedroalvarez | \o/ | 14:30 |
Zara_ | (yes, persia, playing around with btrfs would have been more trouble than it was worth in this case :) ) | 14:30 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:36 | |
tiagogomes | Is it intentional that non-zero exit status in install-commands are ignored and morph doesn't abort the operation? | 14:47 |
* persia hopes not | 14:51 | |
straycat | tiagogomes, no | 14:58 |
straycat | I think we could perhaps use a guide on lorrying | 15:00 |
straycat | if we don't already have one that is | 15:00 |
bashrc | paulsherwood: created on monday | 15:00 |
SotK | bashrc: what is the output of `morph --version`? | 15:01 |
bashrc | e8adedb8f3f27d9212caf277b8e8f7c6792a20c2 | 15:01 |
SotK | that explains why you don't have `morph upgrade`, that commit is from July | 15:02 |
SotK | how did you create this machine? | 15:02 |
bashrc | heh | 15:03 |
bashrc | Gary created it | 15:03 |
*** ssam2 [~ssam2@213.16.35.194] has joined #baserock | 15:09 | |
Mode #baserock +v ssam2 by ChanServ | 15:09 | |
jmacs | Given the comments on my recent lorry patch I think it'd be good to try running lorry myself to test it. How long does it take to set up a new lorry from scratch? | 15:26 |
Kinnison | To just run lorry to check its behaviour is fairly easy, run the lorry command with the lorry file you wrote as input and give it a working area. I believe you can instruct it to not care about pushing so you only need test the 'receive' side of things | 15:27 |
Kinnison | lorry --help should tell you wha tthe commandline arguments are | 15:27 |
franred | jmacs, I think you can lorry files from inside your devel machine | 15:27 |
paulsherwood | jmacs: should be possible to run lorry --help | 15:28 |
locallycompact | There seems to be several things wrong with the qt5 system from master. | 15:28 |
paulsherwood | locallycompact: yes there are | 15:29 |
rdale_ | what are the problems with qt5? | 15:30 |
locallycompact | First this dependency: http://pastebin.com/Qy6SiCxG | 15:30 |
locallycompact | and next this, which I don't understand http://pastebin.com/5kDyk8Tc | 15:30 |
jmacs | No "lorry" on my development system. Is it part of devel-system by default? | 15:31 |
straycat | yes | 15:32 |
straycat | but only recently | 15:32 |
pedroalvarez | it was included in the 14.46 devel systems I believe | 15:32 |
straycat | iirc it was only added for the import tool | 15:32 |
pedroalvarez | note: the systems downloaded from download.baserock.org are NOT devel systems | 15:32 |
rdale_ | locallycompact: i did know about the luajit problem with enlightenment, but hadn't got round to fixing it because the enlightenment stratum doesn't build with the baserock systemd version. but qt5 itself is ok afaik | 15:33 |
franred | locallycompact, ERROR: Cannot find remote git repository: ../../qt-labs/qbs.git <-- it is expecting a repository in this path | 15:33 |
straycat | why did we stop releasing devel systems? | 15:33 |
pedroalvarez | straycat: see c6057851915e40132e6524d5b6500e422c5dc639 in definitions.git | 15:35 |
jmacs | Right... that'll be another few hours to set up a lorry then | 15:35 |
straycat | pedroalvarez, kinda busy i'll look later | 15:36 |
paulsherwood | jmacs: shouldn't be? | 15:36 |
paulsherwood | jmacs: actually i have a machine could run this on, if you like? | 15:37 |
jmacs | paulsherwood: I know the current patch doesn't work (see franred's comment) so it needs adjusting first | 15:37 |
paulsherwood | ok | 15:38 |
Kinnison | pedroalvarez: when you did the most recent release of Baserock, did you produce x86_64 chroot system tarballs too? | 15:41 |
straycat | pedroalvarez, ahh i see | 15:41 |
straycat | thanks | 15:41 |
pedroalvarez | Kinnison: everything in clusters/release.morph | 15:41 |
Kinnison | pedroalvarez: cool | 15:41 |
pedroalvarez | so yes | 15:41 |
Kinnison | thank you | 15:41 |
Kinnison | and the checksums on the website are right? | 15:41 |
pedroalvarez | they should be | 15:42 |
Kinnison | yay | 15:42 |
Kinnison | thank you | 15:42 |
pedroalvarez | :) | 15:42 |
pedroalvarez | you are welcome | 15:42 |
jmacs | Should there be a baserock-15.02 tag for definitions? | 15:43 |
pedroalvarez | jmacs: yeah | 15:43 |
pedroalvarez | I forgot that | 15:44 |
pedroalvarez | tagged, and sorry | 15:48 |
jmacs | No problem | 15:50 |
jmacs | I'm just going to update the wiki | 15:50 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:55 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:56 | |
straycat | just double checking, everything's back to normal with gbo now, so I'm okay to merge stuff? | 15:57 |
pedroalvarez | yup | 15:58 |
straycat | cool | 15:58 |
straycat | ssam2, if you get a moment to check out the patch i sent the other day, it's pretty trivial and would be good to merge cause the docs depend on it | 15:59 |
ssam2 | sorry, won't have time til next week | 16:03 |
ssam2 | possibly on fri | 16:03 |
*** Guest87865 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:05 | |
tiagogomes | His ssam2, I am trying to understand a comment of yours in stage2-gcc.morph of definitions. You wrote that we can't use CPPFLAFS to set the sysroot as GCC compiles stuff for the build machine as well. Do you know which stuff is compiling for the build machine or why is trying to do so? | 16:06 |
ssam2 | i don't know right now, sorry | 16:06 |
ssam2 | am on a customer site trying to fix a fairly bad bug in distbuild | 16:07 |
tiagogomes | ok, no problem | 16:08 |
pedroalvarez | let us know if you need help Sam | 16:08 |
straycat | ssam2, oh :( what's the bug, out of interest? | 16:09 |
ssam2 | will send patch | 16:11 |
straycat | ok cool | 16:12 |
lachlanmackenzie | A quick question, when I deploy to Virtualbox directly if VBoxManage can't create a disk image for some reason what should be the morph behaviour? | 16:17 |
rjek | What's the state of Baserock upgrades atm, are we still dependent on btrfs? | 16:19 |
paulsherwood | rjek: our default approach is btrfs yes | 16:20 |
rjek | paulsherwood: Thanks | 16:20 |
paulsherwood | i'm not sure that we actually *need* it to be btrfs, though... straycat ??? | 16:23 |
jmacs | lachlanmackenzie: I know what it will do; morph deploy will exit with an error. Whether that's what it *should* do, I don't know | 16:23 |
straycat | paulsherwood, Do we not rely on subvolumes for upgrades? | 16:25 |
persia | paulsherwood: system-version-manager depends on btrfs: it would need an alternate update mechanism, or patches to system-version-manager. | 16:25 |
lachlanmackenzie | jmacs: Hmm, not quite the behaviour that I'm getting at the moment. | 16:25 |
paulsherwood | lachlanmackenzie: iirc it will clean up before exiting | 16:26 |
*** ssam2 [~ssam2@213.16.35.194] has quit [Quit: Leaving] | 16:51 | |
*** a1exhughe5 [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:56 | |
*** mariaderidder [~maria@213.16.35.194] has quit [Quit: Ex-Chat] | 16:57 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:21 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 17:22 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 17:22 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:22 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:22 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:22 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 17:23 | |
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:01 | |
*** tinsulpop [~kadams@cpe-024-088-245-034.nc.res.rr.com] has quit [Ping timeout: 256 seconds] | 18:15 | |
*** tinsulpop [~kadams@173.227.255.72] has joined #baserock | 18:15 | |
*** tinsulpop [~kadams@173.227.255.72] has quit [Client Quit] | 18:15 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 18:19 | |
straycat | I wonder whether it'd be worth adding a bit of code to fake up the current behaviour we have in the docs, so that they don't break if/when package date changes | 18:24 |
straycat | *data | 18:24 |
straycat | a bit like a demo version i guess | 18:24 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:25 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:25 | |
straycat | probably not worth the effort i guess | 18:26 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:26 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:26 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:26 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:26 | |
persia | Better to fix the docs | 18:26 |
* straycat nods | 18:27 | |
persia | (probably easier too) | 18:27 |
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:58 | |
paulsherwood | http://mason-x86-64.baserock.org - is that current? | 19:05 |
persia | I would expect that to be unreliable, unless the infrastructure if different than I understand. | 19:11 |
persia | master seems to be at 623c58c627f3d7d57eb7a6051b858ccbd8772a2b , so the run is behind. | 19:12 |
persia | Hmm, only two: the trove-setup change, and the baserock-import change. | 19:14 |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:21 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:22 | |
*** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 19:29 | |
* paulsherwood is guessing that the job to actually check for updates is not running | 19:29 | |
*** br_logger [~ubuntu@185.43.218.176] has joined #baserock | 19:34 | |
pedroalvarez | It may be running but it depends on cache.b.o | 19:34 |
pedroalvarez | Oh hey br_logger! You are back | 19:35 |
*** br_logger [~ubuntu@185.43.218.176] has quit [Ping timeout: 265 seconds] | 19:42 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 19:49 | |
paulsherwood | cache.baserock.org seems to be alive too? | 19:59 |
persia | br_logger just dropped, so I suspect that we're seeing intermittent services, rather than full restoration yet. | 20:15 |
paulsherwood | yup | 20:20 |
*** rdale [~quassel@166.Red-88-8-218.dynamicIP.rima-tde.net] has joined #baserock | 20:55 | |
*** rdale_ [~quassel@11.Red-81-34-96.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] | 20:58 | |
*** rdale_ [~quassel@40.Red-83-47-20.dynamicIP.rima-tde.net] has joined #baserock | 21:10 | |
*** rdale [~quassel@166.Red-88-8-218.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds] | 21:13 | |
*** locallycompact [~lc@253.175.125.91.dyn.plus.net] has joined #baserock | 21:43 | |
*** rdale_ [~quassel@40.Red-83-47-20.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 21:52 | |
*** locallycompact [~lc@253.175.125.91.dyn.plus.net] has quit [Ping timeout: 245 seconds] | 23:37 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!