*** locallycompact [~lc@253.175.125.91.dyn.plus.net] has joined #baserock | 00:29 | |
*** locallycompact [~lc@253.175.125.91.dyn.plus.net] has quit [Ping timeout: 264 seconds] | 02:13 | |
*** locallycompact [~lc@227.62.199.146.dyn.plus.net] has joined #baserock | 02:22 | |
*** rdale_ [~quassel@226.Red-79-144-227.dynamicIP.rima-tde.net] has joined #baserock | 03:30 | |
*** rdale [~quassel@100.Red-88-21-209.staticIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 03:34 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:18 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 07:44 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 07:48 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:48 | |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 07:59 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 08:15 | |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:34 | |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 08:38 | |
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:03 | |
*** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:21 | |
mike is now known as Guest93730 | 09:21 | |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:22 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:29 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:37 | |
Mode #baserock +v ssam2 by ChanServ | 09:37 | |
bashrc_ | the instructions for upgrading to a devel image seem rather unhelpful. I get "morph: not found" http://wiki.baserock.org/quick-start/#index7h2 | 09:51 |
---|---|---|
persia | bashrc_: Where are you running the command? | 09:52 |
bashrc_ | morph branch | 09:52 |
bashrc_ | or if I just run morph --version | 09:52 |
SotK | bashrc_: What does `which morph` say? | 09:53 |
bashrc_ | nothing | 09:53 |
persia | Right. From which environment are you running `morph branch ...`? | 09:53 |
SotK | where did you get this system from? | 09:53 |
bashrc_ | not sure. It's an openstack baserock VM created by terry last week | 09:54 |
SotK | OK, can you paste the contents of /baserock/deployment.meta somewhere please? | 09:54 |
bashrc_ | http://0bin.net/paste/v9HmLWx29Jpwxtvv#fK88ljm6MfcbgLu+r9K6Wru4S6AXvIJ23CGWxXln8FS | 09:56 |
SotK | hm, it looks like that was a base system, which doesn't contain morph | 09:58 |
persia | bashrc_: Probably best to download a new "build" system from download.baserock.org, and start from there. | 09:58 |
SotK | there should be a file /baserock/base-system-x86_32-generic-rootfs.meta which lists what was included in the system, if you paste that I'll confirm that its the base system :) | 10:00 |
SotK | but yeah, downloading the build system from download.baserock.org is your best bet to get working | 10:00 |
bashrc_ | http://0bin.net/paste/Kw3awWKuz6QWoINP#mcqEow6rg6g4j0UwMD50cpdrikfDlzXjhhBI+M7j2hd | 10:02 |
persia | bashrc_: Indeed, that doesn't contain morph-utils, so no morph. | 10:04 |
bashrc_ | ok. I've no idea how to create openstack images. Will have to find out | 10:05 |
* SotK notices we can't upgrade the base system either, since it doesn't have rsync | 10:05 | |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:07 | |
*** locallycompact [~lc@227.62.199.146.dyn.plus.net] has quit [Ping timeout: 256 seconds] | 10:08 | |
*** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:10 | |
pedroalvarez | Hi tiagogomes_, I've seen some failures in our CI that I think are related to the latest toolchain upgrade. Can you take a quick look to the failure and see if it's something trivial to fix? http://mason-x86-64.baserock.org/log/211274e454abf6b55e92ba227ae925b1db228041--2015-01-27%2010:21:35.log | 10:28 |
*** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 10:28 | |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:28 | |
tiagogomes_ | pedroalvarez I didn't test weston-system-x86_64-generic.morph. It seems that json-c-misc needs to be configured with --no-werror | 10:30 |
pedroalvarez | tiagogomes_: do you have time to make a patch for that? | 10:31 |
radiofree | this makes persia sad | 10:31 |
persia | ? | 10:32 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 10:32 | |
pedroalvarez | radiofree: hehe, mason in red make all of us sad | 10:32 |
radiofree | persia: working around build failures by disabling -Werror | 10:33 |
tiagogomes_ | radiofree newer gcc, more warnings it finds | 10:34 |
tiagogomes_ | pedroalvarez, sure | 10:34 |
persia | Indeed. This is the lazy way to do it. | 10:34 |
persia | tiagogomes_: Yes, but they should be fixed, and patches sent to the offending projects. | 10:35 |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 10:40 | |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:40 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:40 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 10:41 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:45 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:46 | |
pedroalvarez | I think here it's explained how to fix that warning. https://gcc.gnu.org/gcc-4.9/porting_to.html | 10:47 |
straycat | pedroalvarez, what is http://git.baserock.org/cgi-bin/cgit.cgi/delta/pbr.git/commit/?h=baserock/morph&id=510ee9e9dcb94c5884c215fa3535a1f77f3d2a51 for? | 10:48 |
pedroalvarez | straycat: I didn't know about pbr when I did this patch. It was to avoid using pbr and use setuptools | 10:49 |
pedroalvarez | straycat: that is going to be fixed as part of the current work of openstack integration | 10:50 |
pedroalvarez | straycat: wait, this is pbr? I thought it was a openstack client, sorry | 10:50 |
pedroalvarez | does pbr require pbr to be installed? | 10:51 |
straycat | doesn't seem to | 10:52 |
straycat | we should try and build from a tag if we can | 10:52 |
SotK | I think I found that commit to be unneeded when doing the zuul stuff | 10:52 |
straycat | i'm not sure pbr from that commit is functioning | 10:53 |
straycat | i mean your setup.py doesn't add the entry points or anything | 10:53 |
SotK | straycat: it wasn't working properly from that commit for me :) | 10:53 |
* straycat nods | 10:54 | |
* pedroalvarez did that commit more than a year ago | 10:55 | |
* straycat nods | 10:56 | |
straycat | no big deal, just wasn't sure if it had a purpose or not | 10:57 |
straycat | i'll try building it from a tag instead | 10:58 |
nowster | hi all... doing native-bootstrap and failing at the python-setuptools with missing _ctypes module. | 11:11 |
ssam2 | that's weird, seems that your build of cpython has missed out the _ctypes module from its build | 11:14 |
ssam2 | is this on a non-standard architecture? | 11:14 |
nowster | mips64 | 11:14 |
ssam2 | right. checking the configure and build logs for cpython for any weirdness would be my first point of call | 11:14 |
ssam2 | that's a little awkward right now, I think there are instructions somewhere | 11:14 |
nowster | ok. Not sure if the build process kept them. | 11:14 |
ssam2 | i'll try to find them, but I'm in the middle of something else first | 11:14 |
ssam2 | it kept them in /src/cache/artifacts with a funny name | 11:15 |
nowster | ta | 11:15 |
nowster | in native-bootstrap, there's no /src/cache | 11:15 |
ssam2 | oh yeah | 11:16 |
ssam2 | this is the 'second phase' of a cross-bootstrap, right? | 11:16 |
nowster | yep | 11:16 |
nowster | I have a _ctypes_failed.so | 11:17 |
ssam2 | where? | 11:18 |
nowster | -rwxr-xr-x 1 root root 567030 Jan 27 03:24 /usr/lib/python2.7/lib-dynload/_ctypes_failed.so | 11:18 |
nowster | -rwxr-xr-x 1 root root 98894 Jan 27 03:15 /usr/lib/python2.7/lib-dynload/_ctypes_test.so | 11:18 |
*** wdutch [~yourname@access.ducie-dc1.codethink.co.uk] has joined #baserock | 11:18 | |
ssam2 | heh, right | 11:18 |
ssam2 | ok, during the native part of a cross-bootstrap it doesn't keep build logs | 11:19 |
ssam2 | I guess what you need to do is run a build of cpython manually in the same environment | 11:19 |
nowster | hmm | 11:19 |
nowster | I wonder if I rename _ctypes_failed.so to _ctypes.so... it'll just work... | 11:20 |
straycat | pedroalvarez, i missed the firest line of the original script that imports util from pbr, i expect it can be bootstrapped | 11:21 |
straycat | though | 11:21 |
nowster | I also have a weirdness: | 11:21 |
nowster | ldconfig: /usr/lib64/libstdc++.so.6.0.16-gdb.py is not an ELF file - it has the wrong magic bytes at the start. | 11:21 |
ssam2 | hmm | 11:22 |
ssam2 | is that file Python source code, as the .py extension suggests> | 11:22 |
ssam2 | ? | 11:22 |
nowster | yes | 11:22 |
ssam2 | right. I'd guess that's another weird thing in the build of Cpython | 11:22 |
nowster | I'm going to attempt to rebuild cpython | 11:22 |
ssam2 | you may well be the first to build cpython on mips64 :) | 11:23 |
nowster | eek!!! | 11:23 |
nowster | One small step for a mips. | 11:23 |
straycat | okay if i move pbr into python-tools and we make openstack depend on python-tools? | 11:25 |
ssam2 | franred was talking about having a python-core stratum for common python deps | 11:26 |
ssam2 | to me, 'tools' is more like 'developer utils that aren't necessarily needed' while 'core' is 'stuff you actually can't do without' | 11:26 |
ssam2 | so by this metric, 'pip' belongs in 'tools' while 'pbr' belongs in 'core' | 11:27 |
straycat | well you'd think that | 11:27 |
straycat | but pbr depend on pip :p | 11:27 |
ssam2 | hah | 11:27 |
straycat | so we'd want to move pip into core too | 11:27 |
ssam2 | franred is about to land a huge patch series for OpenStack, so check with him | 11:27 |
* straycat nods | 11:27 | |
straycat | franred, penny for your thoughts? | 11:28 |
ratmice__ | libstdc++...-gdb.py is a pretty printer that comes with gcc, that gdb loads | 11:28 |
*** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:31 | |
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 11:32 | |
petefoth_ is now known as petefoth | 11:32 | |
ratmice__ | not sure why its in lib64 though, will have to check out the defaults... | 11:33 |
tiagogomes_ | great, json-c does't not support --disable-werror | 11:35 |
tiagogomes_ | what installs libstdc++...-gdb.py? cpython? | 11:36 |
ratmice__ | tiagogomes_: gcc does, see gcc bug #41816 | 11:38 |
franred | ssam2, straycat, pbr depends on pip, I agree, I would say that both in core because they are part of the python install process | 11:39 |
franred | or one of them | 11:39 |
straycat | franred, do the changes you're about to land add a python-core stratum that contains pip then? | 11:39 |
straycat | *pip & pbr | 11:39 |
nowster | Caught the bugger! | 11:40 |
nowster | *** WARNING: renaming "_ctypes" since importing it failed: build/lib.linux-mips64-2.7/_ctypes.so: undefined symbol: ffi_call_N32 | 11:40 |
tiagogomes_ | oh, In expericence with gcc, it just installs to different places depending on the arch. Gcc also doen't honor `--with-libdir`. I suggest configure the linker to look at /lib32 | 11:40 |
franred | straycat, no, I have pip and pbr in strata/openstack-common.morph so for me is independent... when I will merge this I need to do changes anyway so go ahead to create the core stratum if you can | 11:40 |
straycat | cool, okay will do then | 11:41 |
nowster | This might also be relevant: | 11:41 |
nowster | /cpython.inst/cpython.build/Modules/_ctypes/libffi/src/mips/ffi.c: In function 'ffi_closure_mips_inner_O32': | 11:41 |
nowster | /cpython.inst/cpython.build/Modules/_ctypes/libffi/src/mips/ffi.c: In function 'ffi_closure_mips_inner_N32': | 11:41 |
nowster | /cpython.inst/cpython.build/Modules/_ctypes/libffi/src/mips/ffi.c:960:63: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] | 11:41 |
nowster | Looks like it might not have a mips64 variant. | 11:42 |
ssam2 | nowster: yeah, I guess you have an embedded version of libffi there too :( | 11:44 |
ssam2 | libffi is reasonably widely used, so there might be support in the latest upstream version already... | 11:44 |
nowster | this seems a bit dodgy | 11:48 |
nowster | # if (_MIPS_SIM==_ABIN32 && defined(_ABIN32)) || (_MIPS_SIM==_ABI64 && defined( | 11:48 |
nowster | _ABI64)) | 11:48 |
nowster | # define FFI_MIPS_N32 | 11:48 |
nowster | Hmm. That's in upstream. | 11:48 |
pedroalvarez | tiagogomes_: can you try to fix the warning instead of --disable-werror? | 11:55 |
nowster | the oddity is in fficonfig.py (generated) | 11:56 |
tiagogomes_ | pedroalvarez I'd rather not, it is a dangerous path. I see myself fixing a warning, and then having to fix another one, and then another one... | 11:59 |
Kinnison | 8rich | 12:01 |
Kinnison | bleh, networking | 12:01 |
bashrc_ | looks like you have to build a system before deploying it :) | 12:07 |
bashrc_ | so how do you build a cluster? | 12:08 |
ssam2 | `morph build` each individual system that you need | 12:09 |
ssam2 | it'd be cool if `morph build` could build a whole cluster, but nobody's implemented that yet | 12:09 |
bashrc_ | going on http://wiki.baserock.org/devel-with/#index6h2 | 12:10 |
bashrc_ | so in that example I'd need to build systems/base-system-x86_64-generic.morph first? | 12:10 |
ssam2 | yes | 12:10 |
nowster | OK... think I have a fix, but it's not nice. | 12:16 |
nowster | cpython's fficonfig.py.in compiles o32.S which is OK for 32bit, but 64bit uses the functions from n32.S instead. Change the o to an n and it works. | 12:17 |
ssam2 | doesn't *sound* right... :) | 12:20 |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:21 | |
*** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 12:21 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 13:24 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:24 | |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 13:31 | |
*** ratmice__ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 264 seconds] | 13:36 | |
*** ratmice__ [bosshog@nightfall.forlorn.net] has joined #baserock | 13:36 | |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:48 | |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Read error: Connection reset by peer] | 13:54 | |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 13:56 | |
mauricemoss_ | I cant' make sense of this error (stage2-fake-bash) http://paste.baserock.org/isanicoyuz why is a fake bash needed? | 14:01 |
persia | mauricemoss_: Some stuff depends on having bash, but doesn't actually need bash. fakebash works around this. | 14:03 |
persia | Unfortunately, I can't remember the detail of the discussion: `git blame` might help. | 14:03 |
paulsherwood | kejiahu: hi - pls could you explain why you are seeking commit access to g.b.o? i'm not against it in principle, just interested | 14:04 |
kejiahu | paulsherwood, as I need to update make and gawk to support aarch64 for the moonshot on BR project | 14:05 |
persia | kejiahu: You don't need commit for that: that sort of change needs review anyway. Just send the patches to the list for review. | 14:06 |
mauricemoss_ | persia, ta | 14:07 |
mauricemoss_ | pedroalvarez, git blame point to you :-) it's weird complaining about line 3, where there are only two lines in the script. | 14:08 |
persia | mauricemoss_: Looking at the specific error, I wonder if you have a working sh. Try running the nexec line in a chroot in the failed build environment. | 14:08 |
mauricemoss_ | s/point/points | 14:08 |
persia | mauricemoss_: Rather than a person: what is the commit message for that commit? | 14:08 |
persia | Similarly, the date can tell you where to look in the ML archives to find the discussion | 14:09 |
pedroalvarez | mauricemoss_: we found an issue, and we fixed it in this commit: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?id=f125f46535729b6d439478d1317b6192d570bc3f | 14:10 |
pedroalvarez | I think it's related. Can you check if your definitions have this patch? | 14:10 |
pedroalvarez | It's exactly the same error that Daniel had a while ago. So this patch should also fix yours | 14:11 |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Read error: Connection reset by peer] | 14:11 | |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 14:12 | |
mauricemoss_ | ah, no this patch is missing. | 14:12 |
* mauricemoss_ plans to worker closer at upstream | 14:13 | |
paulsherwood | yay! :) | 14:13 |
nowster | OK... *adding* n32.S to the configuration works too (in addition to o32.S) | 14:14 |
mauricemoss_ | :) | 14:14 |
ssam2 | nowster: does http://bugs.python.org/issue1292 give you any useful info ? | 14:16 |
nowster | Incidentally native-bootstrap completed on this target. :) | 14:16 |
ssam2 | sweet! | 14:16 |
radiofree | tiagogomes: have you tried upgrading json-c? | 14:18 |
kejiahu | persia, sorry, may be a stupid question, is 'get commit access' and 'to be in the writer group' the same thing? I don't need to merge my change to master myself, but now it seems I can't push my branch to git, and tiago is waiting for the updated chunk to be test on moonshot | 14:18 |
radiofree | https://github.com/json-c/json-c/commit/32eddd66f510fb13ef61d4ecab5296bcb771f111 is in 0.11 | 14:18 |
persia | kejiahu: They are the same thing. Most folk tend to use other git hosts for stuff that isn't ready. | 14:19 |
persia | Some folk use git.baserock.org, but that is expected to go away with the new patch tracking plans. | 14:19 |
kejiahu | persia, ok, thanks | 14:21 |
tiagogomes | radiofree no, that would be more work. Updating GCC was already a big effort | 14:24 |
radiofree | tiagogomes: changing the ref to 97ef11033a39d85752d2fb262f2aae5712504fb2 is too much work? | 14:25 |
radiofree | rather odd time to have a public meetup, 9am on a workday? | 14:39 |
persia | For me, the strange thing is it being one day instead of 3-5: most of these sorts of things I attend start at 8am or 9am in whatever is the local timezone. | 14:41 |
rjek | I find it touching that FOSDEM's opening talk is till at 0930. After all these years. | 14:42 |
rjek | Most people are still in bed after the traditional Friday night beer tasting. | 14:42 |
radiofree | persia: well for a conference it's fine, you book time off for that, i just think a one day thing like this would have been more accessible if it were on a sunday or something | 14:48 |
persia | Or even a Monday or Friday. Thursday is a particularly difficult day for folk who need to travel. | 14:49 |
ssam2 | depends if your interest in Baserock stems from work or not, really | 14:50 |
persia | That said, choosing weekend days is tricky: spending Sunday in Manchester means taking Monday and Tuesday off if returning to Japan. Similarly, taking Saturday in Manchester means taking Thursday and Friday off if starting in California. | 14:51 |
persia | ssam2: Even if the interest stems from work, it means losing workdays *on both sides* to visit. | 14:51 |
ssam2 | true, my employer only gives 2 days total for a conference | 14:52 |
persia | Any conference? That's hard. Lots of them last 3-5 days. | 14:52 |
tiagogomes | radiofree, I'll reply in the email | 14:52 |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 15:15 | |
nowster | bootstrapping again... as native-bootstrap uses busybox init, it wants an /etc/init.d/ but bootstrap doesn't make one. | 15:22 |
nowster | init started: BusyBox v1.21.0.git (2015-01-27 00:27:55 UTC) | 15:22 |
nowster | starting pid 97, tty '': '/etc/init.d/rcS' | 15:22 |
nowster | can't run '/etc/init.d/rcS': No such file or directory | 15:22 |
Kinnison | use init=/tools/bin/sh | 15:25 |
Kinnison | don't expect the bootstrap tarball to be a bootable system per-se | 15:25 |
nowster | ah | 15:25 |
nowster | right-oh | 15:25 |
persia | Is that something that it is sane to fix? Bootstrapping seems like something that ought be easy. | 15:27 |
Kinnison | No it's not sane or sensible | 15:28 |
straycat | i do love virtenv | 15:29 |
Kinnison | the bootstrap tarball is a midstate during morph's normal bootstrap phases, with a shell script added to mediate what morph would normally do | 15:29 |
Kinnison | I don't see how we should make that any less scary | 15:29 |
Kinnison | it's a scary step | 15:29 |
persia | Perhaps it just needs better documentation? | 15:30 |
Kinnison | enhancing http://wiki.baserock.org/guides/how-to-cross-bootstrap/ to indicate that init=/tools/bin/sh or similar may be necessary wouldn't be too hard | 15:31 |
* Kinnison suggests nowster do so, based on what he discovers as he goes | 15:31 | |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:31 | |
persia | Indeed. That sounds like the best solution. | 15:31 |
ssam2 | yes, running the intermediate bootstrap tarball with init=/tools/bin/sh was always the intention | 15:33 |
ssam2 | seems that installing the 'lvm2 activation generator' systemd generator in my system has rendered it totally useless. | 15:41 |
ssam2 | systemd hangs for ten minutes, then turns the computer off again | 15:42 |
pedroalvarez | Is that actually to boot the bootstrap tarball? | 15:42 |
ssam2 | pedroalvarez: yes, boot the bootstrap tarball with init=/tools/bin/sh (or wherever 'sh' lives in the tarball, I don't remember off hand) | 15:42 |
tiagogomes | what about Pedro's patch to improve the cross-bootstrap plugin? Was it forgotten? | 15:57 |
ssam2 | tiagogomes: that patch doesn't affect booting the intermediate bootstrap system at all | 15:59 |
ssam2 | it's about how the `morph cross-bootstrap` command itself works | 15:59 |
tiagogomes | ssam2 it doesn't but it makes it easy to create the tarball | 15:59 |
ssam2 | it's awaiting a second +1, anyway. whether it's been forgotten or not, I can't answer :) | 16:00 |
*** zoli__ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Remote host closed the connection] | 16:30 | |
perryl | i'm currently working in a baserock chroot running morph distbuild on a distbuild system and having a little trouble...i know there is an issue where certain versions of morph break cause the distbuild to crash. | 16:49 |
perryl | i'm using git bisect to narrow down to which commits crash but after bisecting, running morph distbuild gives me an error saying that morph must be built and deployed within the system branch checkout. | 16:49 |
perryl | does anyone have any ideas on what is causing this and/or how to avoid it? | 16:49 |
ssam2 | perryl: remember that `morph distbuild` expects to be run from a system branch checkout | 16:53 |
ssam2 | if you run it from /src/morph it won't know what branch you are trying to build, because it works that out based on your current directory | 16:53 |
perryl | ssam2: yep, i've just realised i was in morph instead of definitions | 16:54 |
perryl | it's working fine now | 16:54 |
ssam2 | you can avoid this faff using the `distbuild-morphology` command | 16:54 |
ssam2 | cool :) | 16:54 |
pedroalvarez | tiagogomes: I need to rework it now that the behaviour of `build` and `deploy` have changed a bit | 16:54 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 17:11 | |
pedroalvarez | jjardon: re - pulseaudio 5.99.3. I was pondering the upgrade to 5.0 for now to fix the error. What do you think? | 17:18 |
jjardon | pedroalvarez: 5.0 is a bit old and 5.99.3 is stable enough (they meant to release 6.0 before christmas and master is frozen, only patches to fix major problems are eccepted at the moment). So Id go for 5.99.3 | 17:21 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:24 | |
bashrc_ | ecdsa-sha2-nistp256 ? I thought nist-anything was mud | 17:24 |
Kinnison | generally thought of as attacked | 17:26 |
Kinnison | unfortunately it's also necessary for interoperability with a lot of things | 17:26 |
bashrc_ | ugh | 17:26 |
bashrc_ | (or argh64) | 17:27 |
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:29 | |
tiagogomes | ssam2, I tried to create an account on GCC's bug tracker to report the bug that you ask me to, but it didn't work. I also tried to send a message to overseers@gcc.gnu.org, but the delivery failed | 17:38 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:40 | |
ssam2 | tiagogomes: their bug tracker is broken ???? | 17:43 |
ssam2 | maybe I gave you the wrong URL? I've definitely reported bugs for GCC before... | 17:43 |
ssam2 | oh well, not much we can do for now | 17:44 |
tiagogomes | ssam2, I was using this one: https://gcc.gnu.org/bugzilla/createaccount.cgi?login=asqw22%40gmail.com&token=1422376678-AQ3nIZA1jjjjBT9phJVnOmRESNe2q_NuBZ5FMyB9j5w | 17:44 |
ssam2 | that's very worrying if GCC don't have a working bug tracker though! | 17:44 |
Kinnison | Not unusual | 17:45 |
Kinnison | bug trackers are the least well managed of project resources in general | 17:45 |
Kinnison | if the bts is down, noone can annoy you with bugs while you work | 17:45 |
persia | Maybe just post something to the gcc mailing list? | 17:45 |
ratmice__ | actually sourceware.org (where gcc is hosted) has been slow since last week, its likely just a timeout because of that | 17:46 |
tiagogomes | the IRC channel when I tried looked "read-only" as well. So I couldn't ask any question | 17:47 |
jjardon | Hi! Ive just read about the baserock meetup, cool! :) Any reason to not do it on a weekend instead a workday? | 17:47 |
ssam2 | jjardon: several :) | 17:48 |
jjardon | or at least not in the middle of the week... | 17:48 |
paulsherwood | in general, no. this time, it's primarily to align with diaries for some specific attendees | 17:48 |
radiofree | will future ones be help over the weekend? | 17:50 |
radiofree | of at least after 5 | 17:50 |
paulsherwood | i'd be happy if they were | 17:50 |
persia | Or at least against a weekend? | 17:50 |
radiofree | s/of/or | 17:50 |
paulsherwood | and in future we should hope to give more notice | 17:51 |
* Kinnison is sure the community can generate its own meetings which aren't sponsored by Codethink if it so chooses too :-) | 17:51 | |
paulsherwood | that too | 17:51 |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:54 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 17:56 | |
*** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:59 | |
pedroalvarez | I wonder if anybody knows how to test that pulseaudio is working.. | 18:00 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:00 | |
paulsherwood | flatmush: ^^ | 18:00 |
flatmush | pulseaudio is never working | 18:01 |
paulsherwood | heh | 18:01 |
flatmush | pedroalvarez: You can cat /dev/urandom | pacat | 18:01 |
flatmush | don't wear headphones while doing that or you'll get a nasty shock | 18:01 |
flatmush | it should cause incredibly loud whitenoise to be played on the default sink | 18:01 |
pedroalvarez | flatmush: now i wonder if I can do that in a VM as well | 18:01 |
flatmush | I don't see why not, as long as the VM audio is correctly setup | 18:02 |
flatmush | determining if the VM audio is correctly setup might be more difficult though | 18:02 |
flatmush | you can first use aplay to determine if alsa is working | 18:02 |
*** Guest93730 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:02 | |
flatmush | since pulse is a layer above alsa | 18:02 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:03 | |
pedroalvarez | flatmush: right, thanks! | 18:04 |
pedroalvarez | giving it a try | 18:04 |
pedroalvarez | Looks like enabling CONFIG_KVM_INTEL in the kernel enables KVM in this machine :) | 18:06 |
paulsherwood | pedroalvarez: it's obvious, now you mention it :_) | 18:06 |
pedroalvarez | sometimes somthing obvious has loads of non-obvious things hidden | 18:07 |
pedroalvarez | I have to test it a bit more though | 18:08 |
franred | pedroalvarez, does enable the kernel or the userspace too? | 18:11 |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 18:12 | |
pedroalvarez | kvm was already enabled, but not for this processor. I think that the current qemu version installed also supports kvm virtualization, so hopefully I don't have to do anything else. | 18:15 |
pedroalvarez | testing it know | 18:15 |
pedroalvarez | s/know/now | 18:15 |
franred | pedroalvarez, cool | 18:17 |
pedroalvarez | kvm works | 18:20 |
persia | \o/ | 18:20 |
ssam2 | tiagogomes: I just got a 'confirm account creation' mail from GCC bugzilla | 18:21 |
persia | Does it make sense to enable CONFIG_KVM_* : I notice entries for many other processors in upstream config. | 18:21 |
ssam2 | tiagogomes: so seems they are just a bit delayed | 18:21 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 18:22 | |
franred | persia, I imagine that every KVM_* in its bsp | 18:24 |
franred | and depending if we want to enable KVM in all of them | 18:24 |
pedroalvarez | yeah.. I had to enable a couple of things more only for this machine to work... and I don't thnk they belong to the generic bsp | 18:26 |
pedroalvarez | but KVM_*.. I don't know :/ | 18:26 |
*** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:27 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:28 | |
*** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 18:32 | |
persia | I don't know the right set, but if we want a single x86_64 BSP, we should probably have CONFIG_KVM_AMD at a minimum | 18:34 |
persia | It would also be cool to support KVM for ARM, but there are a lot of CONFIG_KVM_ARM_* options, and I don't know what they all do. | 18:35 |
pedroalvarez | Hm.. no sound at all with this pulseaudio | 18:43 |
pedroalvarez | Not saying that it doesn't work. | 18:44 |
persia | Does ALSA work? | 18:45 |
persia | e.g. `aplay < /dev/urandom` should render unpleasant noise | 18:45 |
pedroalvarez | aplay only complains when I do that | 18:47 |
persia | How does it complain? On my laptop, it generates noise. | 18:47 |
pedroalvarez | http://paste.baserock.org/igojiqerul | 18:49 |
persia | How about `aplay -l`? | 18:51 |
pedroalvarez | heh, no soudcards found... | 18:52 |
* pedroalvarez changes the soundcard type in its VM and reboots the machine | 18:52 | |
persia | Do you have CONFIG_SND_ | 18:52 |
persia | ? | 18:52 |
pedroalvarez | persia: there are some enabled enabled and some not | 18:53 |
persia | Ah, good. So you're part way there. Fiddle with which are enabled and which are advertised by the VM until `aplay -l` reports it can find something. | 18:54 |
persia | `aplay < /dev/urandom` should then generate noise. | 18:54 |
pedroalvarez | :) | 18:55 |
persia | And then you can try `pacat < /dev/urandom` to see if pulse is working | 18:55 |
persia | Note that there are many layers to this stack :) | 18:55 |
pedroalvarez | I'll send a patch to fix the build of json-c + pulseaudio for now. | 18:59 |
pedroalvarez | I have to look into alsa too | 18:59 |
pedroalvarez | I mean, get working alsa | 19:00 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 19:06 | |
*** rdale_ [~quassel@226.Red-79-144-227.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 19:09 | |
*** persia [quassel@ubuntu/member/persia] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] | 20:04 | |
*** persia [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 20:04 | |
*** persia [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 20:04 | |
*** persia [quassel@ubuntu/member/persia] has joined #baserock | 20:04 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 20:09 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:13 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 20:29 | |
* persia wishes again for a better IRC client that could manage netsplits in a user-invisible fashion | 20:34 | |
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 20:35 | |
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 20:44 | |
*** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Ping timeout: 245 seconds] | 22:29 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 23:23 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!