| *** bwh [~benhutchi@access.ducie-dc1.codethink.co.uk] has joined #baserock | 01:00 | |
| *** bwh [~benhutchi@access.ducie-dc1.codethink.co.uk] has quit [Quit: leaving] | 01:17 | |
| *** bwh [~benhutchi@access.ducie-dc1.codethink.co.uk] has joined #baserock | 01:19 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 02:12 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 02:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:01 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:01 | |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has joined #baserock | 08:30 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:33 | |
| *** einonm [~einonm@81.174.139.2] has quit [Ping timeout: 272 seconds] | 08:56 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:01 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:01 | |
| *** rdale [~quassel@139.Red-83-47-16.dynamicIP.rima-tde.net] has joined #baserock | 09:08 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 09:10 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09:11 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:12 | |
| mike is now known as Guest47455 | 09:12 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:15 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:24 | |
| Mode #baserock +v ssam2 by ChanServ | 09:24 | |
| ssam2 | is anyone aware of any issues in the last Baserock release (14.46) ? | 09:34 |
|---|---|---|
| ssam2 | need to advise someone what the best version is to upgrade to | 09:34 |
| paulsherwood | isn't a new release due nowish for genivi? | 09:36 |
| ssam2 | pedroalvarez was planning on doing a genivi-only release | 09:37 |
| paulsherwood | :/ | 09:37 |
| pedroalvarez | is people still happy when a release cames out? | 09:38 |
| * paulsherwood doesn't understand | 09:38 | |
| pedroalvarez | me? :( | 09:38 |
| paulsherwood | i mean, what's the issue with just doing a release that includes genivi? isn't it mainly just tagging/writing a rleease note now? | 09:39 |
| * paulsherwood guesses theres much more to it that he keeps forgetting | 09:39 | |
| pedroalvarez | there is a couple of things more, but yes, not too complicated | 09:41 |
| pedroalvarez | okay, lets do a baserock 15.02 release! | 09:42 |
| ssam2 | part of the reason I think it's complicated is that releases tend to imply "this is super stable" | 09:42 |
| ssam2 | so I want to double check that everything works before I do one | 09:42 |
| pedroalvarez | exactly | 09:42 |
| ssam2 | automated testing helps with this, but no amount of automated testing is going to make me 100% trust a piece of software | 09:42 |
| paulsherwood | ssam2: agreed | 09:43 |
| pedroalvarez | oh, and another thing that I always forget about: x86_32b. I never get aroun to create a mason for that architecture | 09:49 |
| DavePage_ | With sufficient harness you can test installing your release on some bare metal and running some functional tests on the installed system ;) | 09:50 |
| pedroalvarez | hehe, we have already something implemented to deploy to openstack/kvm and run some tests, which is pretty similiar to what you are suggesting | 09:53 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 10:13 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:14 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:16 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 10:26 | |
| * straycat frowns at busybox wget | 10:37 | |
| jmacs | Why? | 10:38 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:38 | |
| straycat | i was expecting -O - to print the received page to stdout, it doesn't, you also have to add -q for that | 10:38 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 10:59 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:12 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 11:17 | |
| straycat | ssam2, I'm thinking about the case where manual intervention is needed to help the import along, and wondered whether the tool would benefit from an --exclude option to allow the stratum to be generated with the understanding that the user would manually add the chunks they'd specified in --exclude ? I guess the workflow if this option doesn't already exist is to get the user to manually generate the lorry and foreign-deps files and put them into | 11:41 |
| ssam2 | --force-stratum-generation does that I think | 11:42 |
| straycat | cool | 11:42 |
| * straycat really needs to disable meta+shift+q | 11:43 | |
| straycat | that is the 3rd time this week i've accidentally quit xmonad >.> | 11:43 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 12:11 | |
| straycat | neat, the import tool just lorried in the pylint website instead of pylint >.> | 12:11 |
| Zara_ | :D | 12:14 |
| straycat | It's not exactly a bug, since pylint.org is a hg repo too, and the import will lorry from the homepage_url of a python package if it finds that it's cloneable. | 12:16 |
| Zara_ | I'm following the rubygems tutorial to the letter, but getting errors early on. They don't match up closely enough with those in the tutorial for me to be able to follow it anyway (rather than conflicts in the 'rails' stratum, there's nothing in it), so I suspect the tool has changed in ways that affect using the tutorial since I last tried to use the tutorial. | 12:17 |
| Zara_ | http://paste.baserock.org/wihovemuwo | 12:18 |
| rdale | that's just saying it is missing the arel gem | 12:18 |
| rdale | i don't think the rails 5.0 master is ready yet | 12:20 |
| Zara_ | I tried to import the same version of rails specified in the tutorial (4.1.8) | 12:22 |
| rdale | maybe the master has switched to rails 5.0 since the tutorial was written | 12:23 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:25 | |
| Mode #baserock +v ssam2 by ChanServ | 12:25 | |
| Zara_ | (btw, I should make it clear that I'm testing the tutorial rather than the tool itself, although they go together. So I'm expecting errors, just not these ones! :P) | 12:26 |
| rdale | i see - i think we should change the command to get a specific version of rails, such as the last stable 4.x | 12:27 |
| Zara_ | it should already do that, but for some reason it's ignoring the 4.1.8 and trying to get master each time | 12:28 |
| Zara_ | (I'm copying the command verbatim from the tutorial, and Krin got the same errors yesterday, which suggests it's not just my setup) | 12:29 |
| Zara_ | here's the full paste with command-- thought I'd included that last time; sorry! http://paste.baserock.org/isaneholos | 12:33 |
| rdale | i've just tried the same command, and i don't get the error you had. but it does try to get the rails 5.x gems | 12:42 |
| rdale | http://paste.baserock.org/exiqofenuy | 12:44 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 12:44 | |
| rdale | i think rails is a bit complicated to use in a tutorial | 12:44 |
| jjardon | Hi! is it correct to think that system-integration filed is the correct one to run pango-querymodules (for pango) or glib-compile-schemas (for glib)? | 12:45 |
| paulsherwood | doffm: http://vimeo.com/116146678 looks good. have you published your definitions anywhere? | 12:45 |
| Zara_ | rdale: that looks more like the output I'm expecting, though; where/when did you get your version of the import tool? (Yes, I think there should be a quickstart tutorial for more straightforward gems, and a separate in-depth one for rails) | 12:47 |
| rdale | i did a pull from master just before i ran the command | 12:47 |
| rdale | maybe you need to clear everything to do with rails from your definitions dir before trying the tutorial | 12:48 |
| paulsherwood | git clean, git reset --hard HEAD | 12:49 |
| * paulsherwood wonders why the importer has to pollute the definitions dierectory | 12:50 | |
| straycat | Are you referring to the foreign-dependencies files? | 12:50 |
| pedroalvarez | jjardon: is that something that has to be run when then entire system is constructed? | 12:52 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 12:52 | |
| paulsherwood | i think so. i just know that i played with the importer in a branch, then did git reset --hard to where i wanted to be for something else, and things misbehaved because the importer had created lots of files which didn't get removed by reset | 12:52 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:52 | |
| Zara_ | (this is the url on the tutorial git://git.baserock.org/baserock/baserock/import ) | 12:53 |
| pedroalvarez | paulsherwood: `git clean -xdf` is what I use to remove unwanted files | 12:53 |
| jjardon | pedroalvarez: yes, gdk-pixbuf-query-loaders as well | 12:53 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:56 | |
| Mode #baserock +v ssam2 by ChanServ | 12:56 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:04 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:06 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:06 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:07 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:24 | |
| Zara_ | I've cleared everything multiple times now. Still no luck. I might try in a new vm. | 13:27 |
| ssam2 | sorry, I missed a chunk of IRC there. is this still about the import tool? did you try adding the 'print' statement? | 13:31 |
| ssam2 | actually what I said could have been lost altogether | 13:31 |
| ssam2 | did my comment about debugging what's going wrong show up? | 13:31 |
| * SotK doesn't see it | 13:32 | |
| ssam2 | ah | 13:33 |
| ssam2 | <ssam2> might be this line of python in 'app.py' going wrong: | 13:33 |
| ssam2 | <ssam2> goal_version = args[1] if len(args) == 2 else 'master' | 13:33 |
| ssam2 | <ssam2> could you add a 'print goal_version' statement after that in app.py and try again? then we can see if it's ignoring the argument or if things are going wrong further down | 13:33 |
| ssam2 | you'd thinking switching between wired and wireless networks would be a solved problem by now, but apparently not :( | 13:33 |
| Zara_ | yeah, I missed what you said | 13:34 |
| Zara_ | oh, though I think that's in reply to ripsum about something else | 13:34 |
| Zara_ | oh wait no that was something else, sorryyyy | 13:35 |
| Zara_ | buh | 13:35 |
| Zara_ | I'll try that now | 13:37 |
| Zara_ | hm, it says 4.1.8, so that seems right | 13:39 |
| ssam2 | ok, so something else is wrong | 13:39 |
| ssam2 | oh! | 13:40 |
| ssam2 | see the line below it | 13:40 |
| ssam2 | loop = baserockimport.mainloop.ImportLoop( | 13:40 |
| ssam2 | app=self, | 13:40 |
| ssam2 | goal_kind='rubygems', goal_name=args[0], goal_version='master') | 13:40 |
| ssam2 | not sure how that slipped in, but obviously that's the problem :) | 13:40 |
| Zara_ | hahaha | 13:40 |
| ssam2 | do you think you could do a patch to fix this? | 13:40 |
| Zara_ | do I just need to delete "goal_version='master'"? | 13:41 |
| ssam2 | change it to 'goal_version=goal_version' | 13:42 |
| Zara_ | ok, I thought that'd be redundant so I'm glad I checked! | 13:42 |
| ssam2 | it's passing a keyword argument to the ImportLoop.__init__() function | 13:43 |
| ssam2 | if we didn't pass anything there, ImportLoop.__init() would use whatever the default value of the 'goal_version' keyword parameter is | 13:43 |
| ssam2 | (which is probably 'master' :) | 13:44 |
| ssam2 | actually, there's no default, so it'd just throw an exception | 13:44 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:45 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:45 | |
| rdale | i think gem_version = args[1] if len(args) == 2 else 'master', and then passing 'gem_version' is clearer | 13:46 |
| ssam2 | or goal_gem_version ;) | 13:46 |
| Zara_ | (out of curiousity, why doesn't the goal_version=args[1] affect the goal_version value in the loop? is it a python scope differing from js scope thing?) | 13:47 |
| ssam2 | one function can't see local variables from a different function | 13:47 |
| ssam2 | franred: i'm curious if you've tested the Apache SVN import before proposing it for lorrying | 13:48 |
| ssam2 | given it has 1650055 revisions, I wonder if it'll need special treatment | 13:48 |
| ssam2 | we've had problems with huge SVN imports before, I think they can overload git.baserock.org | 13:48 |
| ssam2 | I guess email would have been a better place to say this | 13:49 |
| Zara_ | ssam2: I'm guessing I'm not familiar enough with python; they look like they're in the same function to me) | 13:51 |
| * straycat may have misresolved the conflict | 13:52 | |
| franred | ssam2, no, I haven't tested it | 13:54 |
| ssam2 | franred: ok. I think it'd be safer to use a tarball or an existing git mirror to be honest | 13:54 |
| ssam2 | although I guess if it does cause problems you have the powers to fix them :) | 13:55 |
| ssam2 | so +1 if you want | 13:55 |
| ssam2 | might but at least be nicer to wait til the g.b.o migration is done in case it does screw up g.b.o | 13:55 |
| pedroalvarez | yeah, I'll apreciate if new lorries can wait | 13:56 |
| franred | ssam2, do we have a baserock-clone server where could I test if we have errors trying to lorrying from the svn official repository? | 13:56 |
| ssam2 | franred: I think baserock-clone still exists in our tenency, yeah | 13:56 |
| pedroalvarez | franred: the baserock-clone (aka cache.baserock.org) trove is still running but its performance is really slow | 13:57 |
| ssam2 | I found: git://git.apache.org/httpd.git | 13:57 |
| ssam2 | apparently it's a read-only git mirror | 13:57 |
| ssam2 | I suggest using that since it exists | 13:57 |
| pedroalvarez | yeah, that makes sense. What do you think franred? | 13:58 |
| franred | pedroalvarez, ssam2, it is fine by me, also they have another mirror: https://github.com/apache/httpd | 14:00 |
| pedroalvarez | yeah, I've seen that, but the github one is a mirror of the git.apache.org one | 14:00 |
| franred | yep :) | 14:00 |
| franred | I will -1 my patch and I will try to use from the git repo directly - and when g.b.o finishes to be migrated I will submit another patch | 14:01 |
| franred | ssam2, pedroalvarez ^^^ | 14:01 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 14:03 | |
| pedroalvarez | franred: I'd be ok with a reply to sam's mail with the new lorry. | 14:06 |
| pedroalvarez | ah, but true, you can use the git mirror for now in your development :) | 14:07 |
| franred | yeah, that's what I mean, so I don't disturb your migration ;-) | 14:08 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:08 | |
| pedroalvarez | thanks :) | 14:11 |
| tiagogomes | what is the best way to update GCC? I cloned the GCC repo from git.baserock.org, added a new remote pointing to the GCC upstream; and fetched the master branch from GCC upstream. But I cannot rebase my branch (branched out from build-essential) on top of upstream master, as they don't have common commits. Should I branch out from upstream master instead, and cherry-pick the build-essential commits? | 14:13 |
| Kinnison | The gcc repo on git.baserock.org is a tarball import because upstream gcc is a massive repo which takes too long for lorrying | 14:14 |
| Kinnison | I'd suggest updating the lorry to the new version, and then worry about rebasing from there | 14:14 |
| tiagogomes | Kinnison, rebase will not work, because build-essential commits don't have common commits with master on upstream | 14:15 |
| persia | You may be able to cherry-pick | 14:16 |
| Kinnison | rebase can work with zero common history if wielded correctly; however a new tarball import will maintain common history because of the way lorry imports tarballs | 14:16 |
| tiagogomes | the first commit on build essential is "Tarball conversion", which is not on upstream master | 14:16 |
| Kinnison | 14:14 < Kinnison> The gcc repo on git.baserock.org is a tarball import because upstream gcc is a massive repo which takes too long for lorrying | 14:17 |
| Kinnison | 14:15 < Kinnison> I'd suggest updating the lorry to the new version, and then worry about rebasing from there | 14:17 |
| tiagogomes | I tried a rebase, the operation took more than half an hour and I got lots of merging conflicts | 14:18 |
| Kinnison | Did you first update the lorry for the new gcc and let it do the tarball import? | 14:19 |
| tiagogomes | Kinnison, no, but I don't see how that will solve the problem. I'll send the patch | 14:20 |
| *** rdale_ [~quassel@80.30.107.19] has joined #baserock | 14:32 | |
| *** rdale [~quassel@139.Red-83-47-16.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] | 14:35 | |
| paulsherwood | tiagogomes: https://gcc.gnu.org/wiki/GitMirror ??? | 14:38 |
| paulsherwood | git://gcc.gnu.org/git/gcc.git | 14:39 |
| Kinnison | that git repo is hyooge | 14:39 |
| Kinnison | and slow | 14:39 |
| Kinnison | Hence we went for tarball-import for Baserock | 14:39 |
| persia | By "slow" do you mean "unreasonably large for git to handle" or "a bad pack choice on top"? | 14:39 |
| Kinnison | gcc still maintain an SVN as their primary repo | 14:39 |
| Kinnison | and they are a long-lived GNU project | 14:39 |
| Kinnison | as such, they are git's nemesis in several ways | 14:39 |
| tiagogomes | I tried the repo 3 times, one time it stalled when was downloading for a while, and the another 2 times I think it was the root cause for my freezed machine | 14:40 |
| paulsherwood | ah, i thought that was the svn version you had problems with, tiagogomes | 14:41 |
| paulsherwood | would the github mirror be faster? | 14:43 |
| Kinnison | Not if it's a clone of the same git repo | 14:44 |
| Kinnison | The git mirror generated from the gcc svn is pathologically bad for git | 14:44 |
| paulsherwood | what about git shallow clone? | 14:45 |
| pedroalvarez | The upgrade to a newer gcc is not going to be easy, maybe we could start doing that. | 14:45 |
| straycat | richard_maw, SotK, I mentioned the other day http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-December/010023.html what's the plan? | 14:46 |
| Kinnison | pedroalvarez: I believe tiago is attempting exactly that | 14:46 |
| Kinnison | pedroalvarez: for the project tiago and I are working on, we will need binutils 2.25 and gcc 4.9.2 at minimum | 14:47 |
| richard_maw | straycat: sorry, I don't have time to look at that right now :-( | 14:47 |
| Kinnison | pedroalvarez: fortunately it seems glibc 2.20 is already done :-) | 14:47 |
| * straycat nods | 14:47 | |
| SotK | straycat: I'll take a look, I imagine it will be a +1 still from me :) | 14:47 |
| straycat | thanks | 14:47 |
| pedroalvarez | Kinnison: that means upgrades!! \o/!! | 14:48 |
| pedroalvarez | Kinnison: I started looking at the gcc upgrade, and I crated this branch http://git.baserock.org/cgi-bin/cgit.cgi/delta/gcc-tarball.git/log/?h=baserock/pedroalvarez/4.9.1 | 14:48 |
| pedroalvarez | just to test things before creating heavy lorries | 14:48 |
| Kinnison | updating the tarball lorry shouldn't be heavy per-se | 14:49 |
| * Kinnison worries that 2.25 doesn't appear in the binutils repo on git.baserock.org | 14:49 | |
| pedroalvarez | and I actually would +1 a patch to upgrade it to 4.9.2 | 14:49 |
| tiagogomes | Kinnison, it seems not :'( Do they have a newer repo? | 14:53 |
| Kinnison | tiagogomes: I'm not sure what URL we're lorrying from for binutils -- I gave you a URL which contains 2.25 | 14:53 |
| pedroalvarez | git://sourceware.org/git/binutils.git | 14:55 |
| tiagogomes | yep | 14:55 |
| pedroalvarez | looks like it has changed to: git://sourceware.org/git/binutils-gdb.git | 14:56 |
| paulsherwood | i repeat - what about a shallow clone for gcc instead of tarball? i just did a clone of last 10000 commits in ~ 10 mins, 1GB | 14:57 |
| pedroalvarez | paulsherwood: but.. doesn't that means that we have to change lorry source code? | 14:58 |
| Kinnison | Lorry has no support for shallow clones | 14:58 |
| paulsherwood | ok... but could it? shouldn't it? | 14:59 |
| Kinnison | also I don't know how well they'd interact with morph | 14:59 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:00 | |
| tiagogomes | binutils also takes some time to clone | 15:03 |
| tiagogomes | is it safe to update the URL in a lorry | 15:03 |
| pedroalvarez | it could work, but it doesn't seem to me like the right thing to do. I think of Trove as a mirror of repositories, and if one of them doesn't have all the commits then I don't know if we can still call it "mirror" | 15:03 |
| ssam2 | tiagogomes: updating URL isn't safe, but it is sometimes OK | 15:05 |
| pedroalvarez | in this case, some commits of master of the current mirror in g.b.o are not present in the new repo | 15:06 |
| pedroalvarez | I mean, the commits are present, but the sha1's doesn't match | 15:08 |
| ssam2 | ouch | 15:08 |
| tiagogomes | from the morph PoV, having different SHA1s is the same as not being present | 15:08 |
| tiagogomes | I'll create a new lorry then, but it is ugly to see different versions of a repo in a trove | 15:09 |
| Kinnison | pedroalvarez: forcepushes are sadly common in the outside world, even on master | 15:09 |
| ssam2 | tiagogomes: yes, and we haven't really thought about how to delete dead repos from git.baserock.org either | 15:10 |
| pedroalvarez | Kinnison: even tags from more than a year ago have different sha1 | 15:10 |
| persia | Or how to define "dead repos" for that matter. | 15:10 |
| Kinnison | pedroalvarez: hmm, odd | 15:11 |
| doffm | Could anyone do a quick review of a lorry addition? http://sprunge.us/gZIc | 15:15 |
| straycat | looks ok to me | 15:17 |
| pedroalvarez | WARNING: lorry controller is still disabled | 15:18 |
| ssam2 | oh yeah | 15:19 |
| ssam2 | doffm: +1 anyway | 15:20 |
| doffm | ssam2, straycat: Thanks. | 15:21 |
| doffm | pedroalvarez: What does that mean for getting things lorried? :/ | 15:21 |
| tiagogomes | that they won't :( | 15:21 |
| doffm | I thought as much. | 15:21 |
| tiagogomes | pedroalvarez, any estimate when lc will be up when running again? | 15:22 |
| tiagogomes | s/when/and | 15:22 |
| tiagogomes | thanks for merging the patch ssam2 | 15:23 |
| pedroalvarez | I hope that by 19:00 pm UK time today | 15:23 |
| pedroalvarez | but this migration is a bit heavy and delicate, so I my estimation can be wrong | 15:23 |
| DavePage_ | pedroalvarez: I'll need to reduce DNS TTLs for baserock.org domain names pointing to any IPs that are moving; if the current TTL is >3 hours then they won't have migrated by 19:00 today :) | 15:24 |
| bwh | pedroalvarez: https://github.com/embecosm/git-migrate seems to explain what happened | 15:26 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 15:26 | |
| DavePage_ | pedroalvarez: OK, they're all set to 1h away; I'll lower the TTLs for now, we'll aim to migrate at say 1645? | 15:26 |
| bwh | They've done a full migration from cvs to git which is a bit different from the incremental conversion they were doing previously | 15:27 |
| pedroalvarez | DavePage_: but git.baserock.org TTLs was already reduced, wasn't it? | 15:27 |
| straycat | ssam2, Don't seem to be able to amend local lorry files and continue to import, the tool complains that it differs with the output provided by python.to_lorry | 15:28 |
| DavePage_ | pedroalvarez: Like I say, the highest existing TTL is 1 hour | 15:28 |
| DavePage_ | pedroalvarez: I'm reducing them from 1 hour to 1 minute :) | 15:28 |
| pedroalvarez | bwh: indeed, and that makes a lot of sense | 15:29 |
| pedroalvarez | DavePage_: thanks, I was going to ask you that | 15:29 |
| persia | *which* timeout was reduced? | 15:30 |
| persia | For expiry, waiting the timeout works. For refresh, it is probably good to wait 3* If nxdomain, then the others need adjustment. | 15:31 |
| straycat | ssam2, Is there flag or something I'm missing or is this a bug of sorts? | 15:32 |
| straycat | *a flag | 15:32 |
| pedroalvarez | I'm thinking about the imminent migration of all our baserock.org servers to the new IP addresses, and I think that the migration will be easy if we use the HAProxy for all of them | 15:36 |
| ssam2 | straycat: sounds like a bug ... | 15:39 |
| paulsherwood | +1 for haproxy | 15:39 |
| DavePage_ | But then your haproxy becomes a single point of failure for the entire infrastructure... | 15:39 |
| Kinnison | Drop all of the TTLs to 1 minute | 15:40 |
| * Kinnison uses 1 minute TTLs when migrating services | 15:40 | |
| DavePage_ | Kinnison: Already done | 15:40 |
| DavePage_ is now known as DavePage | 15:40 | |
| Kinnison | Not that anyone even noticed the IP changes when he migrated the baserock.org email and list service :-) | 15:41 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:41 | |
| pedroalvarez | DavePage: do you think that moving them to the haproxy is a bad idea? | 15:43 |
| DavePage | pedroalvarez: I'm not sure what problem it solves, and it does introduce a single point of failure. | 15:44 |
| pedroalvarez | if all the instances where using the haproxy, then we would only have to migrate 1 ip | 15:45 |
| DavePage | Changing one DNS entry instead of changing 10? | 15:46 |
| DavePage | There's not a lot in it TBH | 15:47 |
| DavePage | I mean, it's up to Baserock what Baserock wants to do; I'm not saying it's a bad idea, I'm just saying that there's a slight risk that when the haproxy goes down, all of Baserock goes down. | 15:47 |
| pedroalvarez | alright | 15:48 |
| paulsherwood | baserock could live with that i believe | 15:48 |
| DavePage | It would save a relatively trivial amount of money on public IP addresses from Baserock's hosting provider | 15:49 |
| Kinnison | What value does having the HAProxy give us? | 15:49 |
| * paulsherwood should just shut up | 15:50 | |
| ssam2 | ties us less to floating IPs. in my experience they seem to float away fairly regularly. | 15:50 |
| tiagogomes | echo repo: $(git remote -v | grep "fetch)$" | sed s#ssh://git@#git://# | awk '{ print $2 }' ) | 15:51 |
| tiagogomes | echo commit: $(git rev-parse HEAD) | 15:51 |
| tiagogomes | echo branch: $(git rev-parse --symbolic-full-name --abbrev-ref HEAD) | 15:51 |
| ssam2 | and I don't see why a haproxy instance is any less likely to go down than the git.baserock.org instance | 15:51 |
| ssam2 | or any more likely to go down | 15:51 |
| tiagogomes | that should work for > 90% of the cases | 15:51 |
| ssam2 | if any instance goes down randomly, it sucks | 15:51 |
| * Kinnison does not pretend ot know about the pitfalls of floating IPs so will bow to your superior experience | 15:53 | |
| DavePage | ssam2: I've not had any problems with them floating away - and the point of this migration is to put the project on a faster, better-connected transit network | 15:54 |
| DavePage | I'm tempted to suggest that maintaining the status quo with new IPs is the simplest option; no reason Baserock can't put more of its instances behind haproxy at a later date. | 15:54 |
| ssam2 | I think we should do whatever is simplest, and if changing 10 DNS entries is simple, that's fine | 15:56 |
| pedroalvarez | I'll go with that | 15:56 |
| DavePage | Well, it's simple for pedroalvarez because I'm doing it ;) | 15:56 |
| DavePage | But it's also pretty simple for me ;) | 15:57 |
| pedroalvarez | I think that it doesn't matter if any of the services in DC are down for some minutes | 15:57 |
| pedroalvarez | anybody disagrees? | 15:57 |
| * pedroalvarez takes that as a "no" | 16:01 | |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has quit [Quit: Leaving] | 16:16 | |
| tiagogomes | Can people review my patch to lorry bintutils from the newer repo? I'd like to have this thing lorried tomorrow morning | 16:24 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:34 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 16:34 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 16:34 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:34 | |
| tiagogomes | The are some morph files in binutils repo, are those still need? | 16:36 |
| pedroalvarez | I don't think so | 16:37 |
| tiagogomes | cool, I think that will minimize the delta to just be a commit to disable c++ stuff | 16:39 |
| tiagogomes | Kinnison, are we going to need a c++ compiler? | 16:39 |
| Kinnison | tiagogomes: You can't build a devel system without one | 16:40 |
| Kinnison | so yes | 16:40 |
| pedroalvarez | also, newest gcc needs c++ to compile (afaik) | 16:40 |
| pedroalvarez | ANNOUNCEMENT: some .baserock.org services (all except git.baserock.org) will be down for some minutes starting at 16:45 UK time | 16:42 |
| straycat | ssam2, Oh it looks like it's my fault, I hardcoded the goal-kind in some part of the extensions, so the importers not adding the products field, which is why it can't find the lorry | 16:44 |
| straycat | *importer's | 16:44 |
| *** br_logge1 [~ubuntu@185.43.218.182] has joined #baserock | 16:47 | |
| *** br_logger [~ubuntu@85.199.252.189] has quit [Ping timeout: 244 seconds] | 16:50 | |
| br_logge1 is now known as br_logger | 16:51 | |
| pedroalvarez | ANNOUNCEMENT: .baserock.services are up and running again | 16:54 |
| tiagogomes | ssam2, I am a bit confused by a commit that you have done in bintuils "ef4ff5c Import binutils-2.22 tarball". Do you remember why you imported a tarball? | 16:54 |
| pedroalvarez | s/.services/.org services/ | 16:55 |
| pedroalvarez | some repos are difficult to build from git, and easier from a tarball. I guess he found some problems when building binutils from git and had to import the entire tarball | 16:56 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 16:57 | |
| kejiahu | I installed a baserock on wandboard, but the ethernet link is keeping up/down, could anybody teach me where should I check to figrue the problem? | 16:57 |
| kejiahu | fec 2188000.ethernet eth0: Link is Down | 16:57 |
| kejiahu | fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx | 16:57 |
| radiofree | does it do that continually? | 16:58 |
| kejiahu | yes | 16:58 |
| radiofree | what does it say in ifconfig | 16:58 |
| kejiahu | seems the service was failed | 16:58 |
| kejiahu | ~ # ifconfig | 16:59 |
| kejiahu | eth0 Link encap:Ethernet HWaddr 00:1F:7B:B4:02:60 | 16:59 |
| kejiahu | inet6 addr: fe80::21f:7bff:feb4:260/64 Scope:Link | 16:59 |
| kejiahu | UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 | 16:59 |
| kejiahu | RX packets:6142 errors:0 dropped:76 overruns:0 frame:0 | 16:59 |
| kejiahu | TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 | 16:59 |
| tiagogomes | thanks pedroalvarez | 16:59 |
| kejiahu | collisions:0 txqueuelen:1000 | 16:59 |
| kejiahu | RX bytes:770399 (752.3 KiB) TX bytes:1250 (1.2 KiB) | 16:59 |
| radiofree | kejiahu: paste.baserock.org next time :) | 16:59 |
| radiofree | that's an old baserock release | 16:59 |
| persia | pedroalvarez: Also lorry controller? | 16:59 |
| radiofree | though i don't know why it would keep going up and down like that | 17:00 |
| radiofree | is it stable after you do "udhcpc"? | 17:00 |
| pedroalvarez | persia: no, git.baserock.org is still on maintenance | 17:00 |
| * pedroalvarez hopes he has used the right words | 17:01 | |
| kejiahu | radiofree, yes, it is | 17:01 |
| persia | I would probably have used "under" or "in" rather than "on", but otherwise I think so. | 17:01 |
| kejiahu | ifup@eth0.service loaded failed failed ifup for eth0 | 17:01 |
| radiofree | eeek | 17:02 |
| radiofree | what version of systemd is on there? "systemctl --version" | 17:02 |
| rdale_ | can a 'zip' command be changed to a gzip command, or are the compression schemes/file formats always different? | 17:02 |
| ssam2 | tiagogomes: probably because of the build-essential work | 17:03 |
| kejiahu | ~ # systemctl --version | 17:03 |
| kejiahu | systemd 204 | 17:03 |
| kejiahu | -PAM -LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP -GCRYPT -ACL +XZ | 17:03 |
| ssam2 | tiagogomes: building stuff from git requires a lot more dependencies than building from a tarball | 17:03 |
| radiofree | kejiahu: ok, upgrade to a newer version of baserock | 17:03 |
| radiofree | sadly we don't have a rootfs tarball on the website | 17:03 |
| ssam2 | tiagogomes: so some stuff in Baserock is built from tarballs | 17:03 |
| ssam2 | tiagogomes: including everything in the build-essential stratum | 17:03 |
| radiofree | kejiahu: you can download the jetson image from the site though, and mount that, then copy it over to a sd card | 17:03 |
| radiofree | "mount jetson-devel-whatever-armv7lhf.img /mnt" | 17:04 |
| ssam2 | tiagogomes: I should probably have explained this before when you were talking about importing GCC from git ... we need to use tarballs of GCC too | 17:04 |
| radiofree | "sudo cp /mnt/systems/default/run/* /path/to/your/sdcard" | 17:04 |
| radiofree | "sudo cp -r /mnt/systems/default/run/* /path/to/your/sdcard" even | 17:04 |
| ssam2 | tiagogomes: i just noticed pedro already answered this ;) | 17:04 |
| pedroalvarez | ssam2: but I didn't know that we needed also tarballs for gcc, so useful info anyway | 17:04 |
| persia | rdale_: It depends on the tool, but most "zip" implementations are different than most "gzip" implementations, sufficiently that they do not automatically detect the alternate format. | 17:05 |
| rdale_ | yes, gzip seems to be able to decompress zip, but not compress it as far as i can see | 17:05 |
| tiagogomes | ssam2, so to upgrade binutils, should I extract the tarball on the top of the build-essential branch? | 17:06 |
| ssam2 | tiagogomes: yeah | 17:06 |
| kejiahu | radiofree, thanks | 17:06 |
| ssam2 | tiagogomes: in fact, you should do this: | 17:06 |
| pedroalvarez | looks like the git.baserock.org migration can be done today | 17:06 |
| ssam2 | tiagogomes: 1. git rm -r * && git commit -m 'remove old version' | 17:06 |
| ssam2 | tiagogomes: 2. unpack the tarball, git add .; git commit -m 'add new version' | 17:07 |
| ssam2 | tiagogomes: 3. squash the last two commits together | 17:07 |
| ssam2 | that way, any files that were removed in the new version will be gone | 17:07 |
| pedroalvarez | in this case, makes any sense to lorry the new binutils repo? | 17:07 |
| ssam2 | hmm, probably not :) | 17:08 |
| tiagogomes | ssam2, I see, but I'll loose your patches that are on build essential. The patches to add morphs I guess that are not necessary anymore, but maybe I'll need to replicate the one to "Remove AC_PROG_CXX from LD's configure.in" | 17:10 |
| persia | What does that do? Is there a reason to have it in Baserock, but not upstream? | 17:11 |
| tiagogomes | "This is only needed for a few of the tests, but causes 'configure' to fail if not disabled because during stage 2 of the bootstrap we don't have a C++ compiler available. (Or, worse, the host C++ compiler is available and we get errors later on)." | 17:12 |
| tiagogomes | but pedroalvarez thinks that I need a c++ compiler to build the newer version of GCC, is that right? | 17:13 |
| ssam2 | indeed. the bootstrap will need changing a bit to build GCC 4.8 or 4.9 | 17:13 |
| ssam2 | it might make sense for you to first add 4.9 as a 'stage 4' chunk | 17:14 |
| ssam2 | i.e. build it after 4.7 gets built | 17:14 |
| Kinnison | Nope | 17:14 |
| Kinnison | we need 4.9.2 at stage 1 | 17:14 |
| Kinnison | New architecture :-) | 17:14 |
| ssam2 | that'll be harder though | 17:14 |
| ssam2 | so surely it makes sense to do the easier thing, then the harder thing ? | 17:14 |
| Kinnison | Not as hard as trying to compile for aarch64 with a gcc which doesn't know what that is | 17:15 |
| pedroalvarez | linuxfromscratch.org may help on this | 17:15 |
| *** rjek [~rjek@gateway/shell/pepperfish/x-eqdboqxanhvqrfmm] has joined #baserock | 17:16 | |
| ssam2 | the thing to do is build libstdc++ as its own chunk in stage 2 | 17:18 |
| ssam2 | but I last looked at this 2 years ago, so the details are hazy | 17:18 |
| * tiagogomes sobs | 17:20 | |
| straycat | I also never made python.to_lorry generate a products field, which seems to be needed by the function that searches for lorries :/ | 17:23 |
| straycat | I don't follow why that field is needed, I might have to come back to this later | 17:23 |
| ssam2 | straycat: it's to associate a lorry entry with a 'package' | 17:24 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:24 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:24 | |
| ssam2 | sadly this stuff has been pushed out of my brain by other stuff now, but there was a reason | 17:24 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:24 | |
| straycat | ssam2, I thought that was what the key was for. | 17:24 |
| ssam2 | the thing is, one git repo may contain more than one package | 17:24 |
| ssam2 | e.g. rails.git contains 10 different gems | 17:25 |
| ssam2 | each of those are listed as products | 17:25 |
| straycat | right | 17:25 |
| straycat | I was confused because I only saw products fields used for specifying dependency information, so thought there were no longer any uses for products fields | 17:25 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 17:26 | |
| pedroalvarez | I'm tempted to announce a maintenance window for git.baserock.org | 17:26 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:27 | |
| pedroalvarez | but not sure if people will be happy with me if I announce it 15 minutes before it happens :/ | 17:27 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:27 | |
| DavePage | pedroalvarez: Better than not being happy with you because it wasn't announced at all IMHO | 17:28 |
| DavePage | pedroalvarez: Just mention that you're improving long-term stability and maintenance in the announcement :) | 17:28 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:28 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:28 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:29 | |
| pedroalvarez | ANNOUNCEMENT: git.baserock.org will be down for around 20 minutes, starting at 17:45 UK time. This will improve long-term stability, and it will restart the lorry-controller. | 17:29 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:29 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 17:33 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 17:36 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 17:43 | |
| jjardon | pedroalvarez: Ive just came here because I had problems fetching ;) | 17:48 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:48 | |
| pedroalvarez | jjardon: sorry about the short notice. It will be up soon | 17:48 |
| jjardon | so thanks for the announcement ;) | 17:49 |
| tiagogomes | I was trying to build binutils 2.25, and the build failed. I chrooted and ran `sh -c make`: http://paste.baserock.org/ipoterosaj | 17:51 |
| tiagogomes | any idea why is failing? | 17:51 |
| tiagogomes | at first glance, it seems a binutils issue | 17:51 |
| tiagogomes | bah | 17:56 |
| tiagogomes | main() { return 0; } | 18:01 |
| tiagogomes | main() { return 0; } | 18:01 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:01 | |
| tiagogomes | main() { return 0; } | 18:01 |
| tiagogomes | main() { return 0; } | 18:01 |
| pdar | Hiya, am having some trouble starting a baserock vm in virtual box. I found there was already some troubleshooting help for the error on w.b.o, at http://wiki.baserock.org/common-errors/#index4h2 . After following the suggestions the problem persists, and the .vbox file is returned to the same state. Has anybody else experienced this? | 18:01 |
| pedroalvarez | allright, git.baserock.org has been migrated \o/ | 18:08 |
| pedroalvarez | it looks like it's everything up and running | 18:08 |
| jmacs | pdar: Never seen that one before, sorry | 18:09 |
| kejiahu | pdar, check virtualbox-file-preference-network, is there any host-only network exists? | 18:25 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 18:26 | |
| pdar | kejiahu: thanks, checked, and there are 3 present. | 18:29 |
| kejiahu | pdar, oh, sorry, I though you were asking about the 'Nonexistent host networking interface' issue.. thus my suggestion is uncorrelated... | 18:33 |
| *** Guest47455 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:33 | |
| pdar | kejiahu: ahh, thanks for trying to help though :) | 18:34 |
| kejiahu | :) | 18:34 |
| * pdar gives up till tomorrow | 18:40 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:00 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 20:00 | |
| *** rdale [~quassel@89.Red-79-158-207.staticIP.rima-tde.net] has joined #baserock | 20:19 | |
| *** rdale_ [~quassel@80.30.107.19] has quit [Read error: Connection reset by peer] | 20:19 | |
| *** rdale_ [~quassel@50.Red-2-136-152.dynamicIP.rima-tde.net] has joined #baserock | 20:20 | |
| *** rdale [~quassel@89.Red-79-158-207.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:20 | |
| *** rdale_ [~quassel@50.Red-2-136-152.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:21 | |
| *** rdale [~quassel@14.Red-83-41-19.dynamicIP.rima-tde.net] has joined #baserock | 20:21 | |
| *** rdale_ [~quassel@76.Red-79-157-220.dynamicIP.rima-tde.net] has joined #baserock | 20:24 | |
| *** rdale [~quassel@14.Red-83-41-19.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:24 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 20:28 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:58 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Read error: Connection reset by peer] | 20:58 | |
| straycat | https://www.python.org/dev/peps/pep-0426/#changes-to-project-urls: "In addition to allow arbitrary strings as project URL labels, the new metadata standard also defines a recommend set of four URL labels for a distribution's home page, | 21:29 |
| straycat | documentation, source control and issue tracker." | 21:29 |
| straycat | :) | 21:29 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:35 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 22:55 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 22:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!