| *** nowster has quit IRC | 00:11 | |
| *** paulw has quit IRC | 00:11 | |
| *** flatmush has quit IRC | 00:11 | |
| *** fay_ has quit IRC | 00:11 | |
| *** mauricemoss_ has quit IRC | 00:11 | |
| *** paulw has joined #baserock | 00:12 | |
| *** nowster has joined #baserock | 00:12 | |
| *** fay_ has joined #baserock | 00:12 | |
| *** mauricemoss_ has joined #baserock | 00:12 | |
| *** flatmush has joined #baserock | 00:13 | |
| *** nowster_ has joined #baserock | 00:21 | |
| *** flatmush has quit IRC | 00:21 | |
| *** paulw has quit IRC | 00:21 | |
| *** mauricemoss_ has quit IRC | 00:21 | |
| *** nowster has quit IRC | 00:21 | |
| *** fay_ has quit IRC | 00:21 | |
| *** fay_ has joined #baserock | 00:21 | |
| *** mauricemoss_ has joined #baserock | 00:21 | |
| *** paulw has joined #baserock | 00:22 | |
| *** flatmush has joined #baserock | 00:22 | |
| *** zoli__ has quit IRC | 00:46 | |
| *** zoli__ has joined #baserock | 00:47 | |
| *** zoli__ has quit IRC | 01:15 | |
| *** zoli__ has joined #baserock | 01:51 | |
| *** zoli__ has quit IRC | 02:14 | |
| *** wschaller has joined #baserock | 03:00 | |
| *** wschaller has quit IRC | 03:16 | |
| *** zoli__ has joined #baserock | 03:18 | |
| *** zoli__ has quit IRC | 03:31 | |
| *** zoli__ has joined #baserock | 03:43 | |
| *** zoli__ has quit IRC | 03:54 | |
| *** zoli__ has joined #baserock | 04:03 | |
| *** zoli__ has quit IRC | 05:59 | |
| *** zoli__ has joined #baserock | 05:59 | |
| *** zoli__ has joined #baserock | 06:16 | |
| *** zoli__ has quit IRC | 06:24 | |
| *** zoli__ has joined #baserock | 07:50 | |
| *** sambishop has quit IRC | 08:11 | |
| *** gfinney_ has joined #baserock | 08:22 | |
| paulsherwood | pdar: i ended up arguing strongly that runtime dependencies are already covered by the structure of typical definitions | 08:35 |
|---|---|---|
| paulsherwood | i may not be entirely correct. however - would you expect that for jrandom-python component, say, runtime-depends: would be a list of loads of stuff in bsp, core, foundation, pythontools? | 08:36 |
| *** CTtpollard has joined #baserock | 08:37 | |
| paulsherwood | i pushed back strongly on this because the scheme suggested seemed to complicate matters further, where i would like to see things simplified | 08:38 |
| *** rdale has joined #baserock | 08:40 | |
| paulsherwood | saying one group of components (say stratum A) build-depends on another (say B) is a shorthand anyway. we have not established that each component of A depends on all components of B | 08:43 |
| paulsherwood | we've just grouped together some things which may have interdependencies (B) where we think that they 'should go together', and then for another group of components (A) which also 'should go together', we expect that most of them require some or most of B | 08:46 |
| paulsherwood | the groupings are definitely useful, but the dependencies are not rigorously established. i'm not sure that making them explicit would actually be of any benefit | 08:48 |
| *** sambishop has joined #baserock | 08:55 | |
| *** franred has joined #baserock | 08:57 | |
| ratmice__ | i'm of the opinion that actual dependencies cannot actually increase complexity, they are merely a reflection actual complexity, but yeah agree about not being rigorously established | 08:57 |
| *** mariaderidder has joined #baserock | 08:58 | |
| *** edcragg has joined #baserock | 08:59 | |
| ratmice__ | for c-style runtime dependencies there is some stuff that could be done to bootstrap from a general dependency groupings via a testsuite, but not so sure what to do about interpreted languages, etc | 09:01 |
| *** CTtpollard has quit IRC | 09:02 | |
| *** bashrc has joined #baserock | 09:08 | |
| ratmice__ | SamB of debian was talking about something that would work for this last week or so, not sure if it has a project page anywhere | 09:11 |
| straycat | it would be useful if the structure encoded the dependencies explicitly though, all we can say currently is "we expect that most of them require some or most of B", for instance when moving stuff out of tools into devtools I had no way of knowing whether something somewhere else in the system depended on the chunks I was moving out, I could be fairly those chunks didn't have dependants but I cannot tell from definitions. | 09:14 |
| straycat | *fairly sure | 09:15 |
| *** CTtpollard has joined #baserock | 09:17 | |
| *** tpollard_ has joined #baserock | 09:17 | |
| straycat | so it might be more useful to explicitly build-depend on chunks rather than strata, and just use strata for grouping chunks together | 09:18 |
| jjardon | Red in http://mason-x86-64.baserock.org/ ! | 09:18 |
| franred | straycat, maybe also add the build dependecy in the chunk? | 09:19 |
| franred | s/dependency/dependencies/ | 09:19 |
| jjardon | Seems gst-plugins-good is failing but thats strange as the last commit doest change anything related | 09:19 |
| *** CTtpollard has quit IRC | 09:21 | |
| straycat | franred, you mean in the chunk morph? | 09:23 |
| franred | straycat, yes | 09:23 |
| * straycat nods | 09:23 | |
| *** tpollard_ has quit IRC | 09:23 | |
| *** CTtpollard has joined #baserock | 09:23 | |
| * ratmice__ notes the thing isn't going to work for setuid binaries & sincerely hopes setuid binaries aren't going runtime dependency fancy | 09:25 | |
| straycat | I guess putting it in either would work fine, and you don't need to enforce a particular scheme if you let people inline chunk morphs | 09:25 |
| straycat | ratmice__, wasn't saying anything about runtime deps in this case? | 09:26 |
| ratmice__ | straycat: paul did sometime up a ways | 09:27 |
| straycat | ah :) | 09:27 |
| franred | jjardon, it is weird, in http://mason-x86-64.baserock.org/log/6635005165471c36f8a2e61dbbd626133815a333--2015-02-12%2021:47:22.log does not fail at the same point - so something doggy is happening | 09:28 |
| CTtpollard | heh | 09:28 |
| ratmice__ | anyhow it wouldn't be that hard to throw together (like 2 or 3 functions), if the tooling is in place to make use of the information it outputs | 09:29 |
| jjardon | franred: i think Its gstreamer-plugins-good-misc what is failing there as well, isn't? | 09:31 |
| *** tiagogomes_ has joined #baserock | 09:32 | |
| franred | jjardon, true... thats true.. but the build does not stop there :/ | 09:33 |
| jjardon | I think that's because there are several workers in parallel | 09:33 |
| *** ssam2 has joined #baserock | 09:37 | |
| *** ChanServ sets mode: +v ssam2 | 09:37 | |
| *** jonathanmaw has joined #baserock | 09:37 | |
| tlsa | does anyone know why systems/xfce-system.morph depends on strata/genivi.morph ? | 09:43 |
| tlsa | I tried to builf the xfce system, but it failed at | 09:43 |
| tlsa | [Build 218/297] [genivi-common-api-runtime] Running configure-commands | 09:43 |
| tlsa | with | 09:43 |
| tlsa | configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.." | 09:44 |
| tlsa | not sure if that means genivi systems also fail to build or not | 09:44 |
| paulsherwood | tlsa: it should not depend on genivi, remove it for xfce system to see what happens please. i think we haven't touched xfce system in a long tim | 09:44 |
| paulsherwood | e | 09:44 |
| tlsa | ok | 09:45 |
| paulsherwood | afaik genivi systems build ok | 09:45 |
| paulsherwood | so there will be something odd in the stratum ordering perhaps | 09:45 |
| tlsa | oh, the strata order in the system morph is important? | 09:46 |
| * tlsa has restarted morph build, after removing the genivi strata | 09:48 | |
| jjardon | franred: do you have any problem building the Weston system in current definitions master? I will check myself later | 09:49 |
| *** gary_perkins has joined #baserock | 09:52 | |
| ssam2 | tlsa: stratum order in the system morph isn't important, any order should work | 09:54 |
| ssam2 | but there may be some stratum build-deps that are wrong, for the xfce stratum | 09:54 |
| tlsa | ok | 09:54 |
| tlsa | [Build 222/284] [gtk+] Running configure-commands | 09:55 |
| tlsa | ... | 09:55 |
| tlsa | You must have automake 1.7.x, 1,10.x, 1.11.x, 1.12.x, 1.13.x or 1.14.x | 09:55 |
| tlsa | so I guess it needs whatever stratum has the autotools before it gets to gtk | 09:55 |
| ssam2 | ah, we updated to automake 1.15 recently | 10:00 |
| ssam2 | is this gtk+ 2? I think that needs patching to support automake 1.15 | 10:00 |
| ssam2 | I saw a patch on the gtk mailing list recently | 10:00 |
| ssam2 | you might be able to just use autoreconf instead of gtk+'s autogen.sh | 10:01 |
| *** Krin has joined #baserock | 10:01 | |
| tiagogomes_ | probably not, autoreconf will call automake at some point | 10:02 |
| ssam2 | but it will hopefully not have hardcoded out of date version requirements, unlike the custom autogen.sh | 10:02 |
| tiagogomes_ | ah, the requirement is in autogen.sh, not in configure.ac. They it may work | 10:03 |
| jjardon | Is there any way I can set global configure options that will Ba applied to every chunk? | 10:10 |
| jjardon | Like --disable-werror | 10:11 |
| ssam2 | jjardon: not right now, no | 10:14 |
| ssam2 | well, you could hack Morph to add it to the default configure-commands | 10:14 |
| *** mdunford has joined #baserock | 10:20 | |
| tiagogomes_ | Not every configure script supports werror, and some configure scripts will error with unrecognized options | 10:23 |
| ssam2 | NB ALL: http://mason-x86-64.baserock.org/ was redeployed from master of definitions. There should be no noticeable changes, except it'll be red for a bit while it rebuilds stuff, and the history is gone | 10:33 |
| pedroalvarez | thanks ssam2 :) | 10:34 |
| *** zoli__ has quit IRC | 10:45 | |
| jjardon | tiagogomes_: ? | 11:00 |
| jjardon | ssam2: thanks! | 11:00 |
| jjardon | tiagogomes_: if configure doesnt recognize an option it simply ignores it | 11:00 |
| ssam2 | not all of them. autoconf-generated configure does | 11:00 |
| jjardon | ssam2: not sure about that, jhbuild build with --disable-werror by default and no module is failing in all GNOME | 11:02 |
| ssam2 | sure, GNOME modules all use Autoconf | 11:02 |
| ssam2 | try Perl's configure script | 11:02 |
| ssam2 | or lots of older programs | 11:02 |
| ssam2 | well, not that many. But some | 11:02 |
| tiagogomes_ | xstatic seems to be a summer festival in UK | 11:07 |
| franred | hahaha | 11:11 |
| pedroalvarez | right, mason still failing because of gstreamer-plugins-good | 11:12 |
| jmalk | persia: thanks for the reply on docs, I'm still learning how and where to contribute :) | 11:17 |
| jjardon | ssam2: rigth | 11:21 |
| ssam2 | gstreamer-plugins-good is failing because pulseaudio is trying to autodetect its version from Git and is getting it wrong | 11:22 |
| ssam2 | `./git-version-gen .` in the commit of pulseaudio we build returns '6.0~8' | 11:22 |
| ssam2 | leading to PA_MINOR being defined as '0~8', which breaks the C macros that expect it to be a valid integer | 11:22 |
| ssam2 | magic! | 11:22 |
| radiofree | interesting that it's only failing now | 11:23 |
| ssam2 | maybe it's due to the Git upgrade | 11:23 |
| * jjardon hides | 11:23 | |
| ssam2 | perhaps there's a newer version of git-version-gen in git.git we can import | 11:23 |
| *** zoli__ has joined #baserock | 11:27 | |
| *** rdale_ has joined #baserock | 11:35 | |
| ssam2 | I have the same issue with Git 1.9.3 on Fedora, in fact | 11:37 |
| ssam2 | I think the problem is that since the v6.0 tag appeared, the 'git describe' output is different | 11:38 |
| *** rdale has quit IRC | 11:38 | |
| ssam2 | upgrading to v6.0 fixes the issue and I really don't want to try and fix their magic shell script, should I just update to 6.0 ? | 11:38 |
| ssam2 | I'll report a bug upstream as well | 11:38 |
| tlsa | what's the correct way to apply a patch to fix a build now? I have put a gtk+-support-automake-1.15.diff into strata/gtk2/, and intended to apply it with patch in the exiting gtk+.morph | 11:45 |
| tlsa | but I don't know whether the .diff file will be availabel where it builds | 11:45 |
| jjardon | ssam2: yes, I will mkae a patch if you are not faster | 11:46 |
| ssam2 | i've done one | 11:47 |
| ssam2 | just testing it | 11:47 |
| jjardon | ssam2: +1 | 11:47 |
| tlsa | s/exiting/existing/ | 11:47 |
| pedroalvarez | tlsa: nope, the diff file is not going to be present at build time. You may want to send the patch to gtk+ upstream, and in the meantime propose a definitions.git patch to change the gtk+ ref to point to a branch with your patch included. | 11:49 |
| ssam2 | I already saw a patch sent upstream | 11:49 |
| ssam2 | although it was sent to gtk-devel-list instead of bugzilla, which is the wrong place | 11:49 |
| ssam2 | there may be one in bugzilla.gnome.org too | 11:49 |
| tlsa | https://bugzilla.gnome.org/show_bug.cgi?id=743544 | 11:50 |
| tlsa | still open | 11:50 |
| tlsa | and will be looked at before the next release | 11:50 |
| ssam2 | fair enough. best create a branch in our delta/gtk+ in the meantime then | 11:50 |
| tlsa | ok, what's the beat way to get the gtk+ repo now? It the morph way that mangles definitions frowned on? | 11:51 |
| tlsa | *Is | 11:51 |
| ssam2 | morph edit is fine if it works for you | 11:52 |
| tlsa | ok | 11:54 |
| rdale_ | how are gcc triples defined? doesn't 'x86_64-bootstrap-linux-gnu' have four parts? | 12:03 |
| tlsa | if a chunk has no unpetrify-ref, does that mean it defaults to master branch? | 12:04 |
| tlsa | and to make it use a particular branch, I'd add the branch as an unpetrify-ref field? | 12:05 |
| franred | tlsa, unpetrify-ref is just a documentation field - it does nothing when build but it is nice to have it to know from where is the sha1 | 12:08 |
| tlsa | oh, I see | 12:09 |
| franred | tlsa, if the chunk does not have unpetrify-ref you don't know from which branch/tag/ref the SHA1 was taken | 12:10 |
| tlsa | yep, that's the case for http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/gtk2.morph | 12:12 |
| tlsa | not sure how to work out where that ref is | 12:12 |
| ssam2 | rdale_: linux-gnu is one part, effectively | 12:13 |
| mauricemoss_ | rdale_, this seems to be the general definition: https://wiki.debian.org/Multiarch/Tuples I didn't run into problems with baserock adding *-bootstrap-* | 12:13 |
| ssam2 | 'bootstrap' there is the vendor (2nd) field, so we changed it rather than adding anything | 12:14 |
| ssam2 | e.g. on Fedora the 'vendor' field is 'redhat' | 12:14 |
| rdale_ | thanks - yes my problem is with -bootstrap- i think | 12:14 |
| jjardon | tlsa: Id upgrade to to latest GTK+2 version + you patch | 12:14 |
| rdale_ | i need $ARCH-linux-musl for musl, and it isn't working with bootstap in the middle | 12:14 |
| ssam2 | hmm, that's weird | 12:14 |
| ssam2 | the 'bootstrap' is basically a trick to make the stage1 and stage2 compilers appear to be crosscompilers | 12:15 |
| jjardon | tlsa: then create a branch like baserock/2.24.25+automake115_fix and point the gtk2 stratum there | 12:15 |
| ssam2 | the vendor field is 'baserock' in the stage3 (normal) compilers | 12:16 |
| ssam2 | hmm. actually it's 'unknown' :( | 12:16 |
| ssam2 | it should be 'baserock', I wonder if that's a regression that's crept in | 12:17 |
| tlsa | jjardon: OK, wasn't sure if I could do that, or if I should give the branch a presonal namespace | 12:17 |
| tlsa | what's the process for reviewing changest to delta repos? | 12:17 |
| ssam2 | don't. just send a patch to definitions updating the ref | 12:17 |
| tlsa | ok | 12:17 |
| pedroalvarez | tlsa, jjardon: I prefer to use a personal branch until we decide to use it in definitions.git | 12:17 |
| ssam2 | and link to the upstream bug in your cover letter | 12:18 |
| mauricemoss_ | rdale_, for testing you can edit the triples here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/buildenvironment.py#n130 | 12:18 |
| tlsa | pedroalvarez: a personal branch in delta repos, or in definitions? | 12:18 |
| pedroalvarez | tlsa: delta repos | 12:18 |
| pedroalvarez | well, everywhere :) | 12:18 |
| rdale_ | mauricemoss_: yes, i saw that - i'm just setting a new env variable called $MUSL_TARGET_STAGE1 and ignoring the built in one | 12:19 |
| tlsa | pedroalvarez: so baserock/tlsa/foo? | 12:19 |
| tlsa | for branch name | 12:19 |
| pedroalvarez | tlsa: and once we decide to merge your definitions patch to point to the patched gtk, we can create the non personal branch in the gtk repo | 12:19 |
| tiagogomes_ | ssam2 why it should be baserock? | 12:20 |
| pedroalvarez | tlsa: is tlsa your username in trove? `ssh git@git.baserock.org whoami` | 12:20 |
| tiagogomes_ | On fedora is unknown as well | 12:21 |
| jjardon | pedroalvarez: problem with that is then you are reviewing a branch that can be different that the one that gets merged | 12:22 |
| tlsa | pedroalvarez: no, I'm not, but I don't like my username on there :) | 12:22 |
| tlsa | ('mike' instead of 'michael') | 12:22 |
| pedroalvarez | jjardon: problem with creating non personal branches, how do we identify branches that we are not using in definitions.git? | 12:23 |
| tlsa | pedroalvarez: I think there are a lot of dead branches that aren't personal | 12:23 |
| Kinnison | tlsa: users can be renamed by a trove admin if you ask nicely | 12:23 |
| tlsa | Kinnison: please can my username be changed :) | 12:24 |
| ssam2 | tiagogomes_: because it's the vendor field, that's the point of it | 12:24 |
| jjardon | pedroalvarez: do we need to identify them? merged branches gets removed eventually | 12:24 |
| Kinnison | tlsa: You'd need to ask a trove-admin (and I am not one) | 12:24 |
| ssam2 | on fedora: $ gcc -dumpmachine | 12:24 |
| ssam2 | x86_64-redhat-linux | 12:24 |
| tlsa | heh | 12:24 |
| Kinnison | tlsa: pedroalvarez might be, ssam2 I think is, richard_maw is | 12:25 |
| franred | ssam2, is this --> http://paste.baserock.org/yipejasore enough to describe Xstatic? | 12:25 |
| pedroalvarez | yes, we are :) I can have a look at it. What username do you prefer? | 12:25 |
| pedroalvarez | tlsa: ^ | 12:25 |
| Kinnison | tlsa: they'll need to do something like: ssh git@git.baserock.org user rename oldname newname | 12:25 |
| tlsa | tlsa | 12:25 |
| tiagogomes_ | ssam2 I think that most of the times the vendor field is not used. On my Fedora machine config.guess tells me that is 'unknown' | 12:26 |
| ssam2 | tiagogomes_: it's not hugely important. but config.guess is lying to you, try `gcc -dumpmachine` | 12:26 |
| Kinnison | tlsa: after it's done, check your group memberships -- the git server should migrate them, but it may get confused if things are complex | 12:26 |
| tlsa | ok | 12:27 |
| pedroalvarez | I think that being trove-admin is not enough to do that change | 12:27 |
| pedroalvarez | "FATAL: Not authorized" | 12:27 |
| Kinnison | pedroalvarez: Hm, it's possible that you may need to be the gitano-admin role then, it is a tad risky if any projects have local rules which use usernames y'see | 12:28 |
| Kinnison | pedroalvarez: that role, on troves, should be the git user on the trove itself, so you'll need someone who can get to that | 12:29 |
| * Kinnison can't help much more, as he needs to go rest his leg in a way not conducive to typing on a laptop | 12:29 | |
| * Kinnison will be back later though | 12:29 | |
| pedroalvarez | Kinnison: I hope you get well soon | 12:29 |
| tlsa | Kinnison: ok, thanks anyway :) | 12:30 |
| tlsa | on the subject of dead branches, delta/gtk+ has baserock/gnome, baserock/morph, baserock/morph-gtk-2, baserock/morph-gtk-3, baserock/xfce-build | 12:31 |
| tlsa | I'm not sure how to tell which contains the ref used in the gtk+ chunk in gtk2.morph | 12:32 |
| pedroalvarez | tlsa: username changed, can you check the output of the `whoami` command to check that you are still in baserock-writers? | 12:32 |
| tlsa | or which are used elsewhere | 12:32 |
| tlsa | pedroalvarez: that looks correct, thanks :) | 12:33 |
| pedroalvarez | tlsa: some of those branches have been used in definitions a while ago. Maybe they are now dead, but that doesn't mean we can remove them | 12:33 |
| tlsa | oh, in case somone wants to build from an old definitions | 12:34 |
| pedroalvarez | tlsa: If we start removing branches we will not be able to build systems of previous releases. And yes, we care about that | 12:34 |
| * tlsa nods | 12:34 | |
| pedroalvarez | exactly | 12:34 |
| gfinney_ | Question: When developing Python on a Baserock VR, what tools to people tend to use for debugging (beyond print statements)? | 12:38 |
| gfinney_ | 'do', no 'to' | 12:39 |
| pedroalvarez | I'd like to integrate a newer version of netcat in baserock, but I don't know which one: seems to be a bsd implementation and a nmap one.. Not sure which one we prefer :/ | 12:39 |
| ssam2 | gfinney_: I find pdb really useful | 12:52 |
| gfinney_ | I was thinking that but pdb doesn't exist in my baserock vr. | 12:53 |
| ssam2 | it does in mine. | 12:54 |
| ssam2 | do you get an error when you 'import pdb' ? | 12:54 |
| gfinney_ | Oh. Is there a way of installing it in there? | 12:54 |
| ssam2 | it should be built into Python.. | 12:55 |
| radiofree | `import pdb` works here as well | 12:56 |
| paulsherwood | gfinney_: you need to add 'import pdb' to the file you want to establish a break in | 12:57 |
| gfinney_ | Ah. Thanks | 12:58 |
| mauricemoss_ | I'm getting 'No space left on device' although `df -h` states otherwise http://paste.baserock.org/neqerikuxe and `morph gc` exits with 'Bus error (core dumped)' Is this a btrfs problem? | 13:26 |
| radiofree | df -h and btrfs don't get on very well | 13:26 |
| ssam2 | your /tmp is full | 13:26 |
| ssam2 | maybe that's part of it | 13:27 |
| mauricemoss_ | Ah, that makes sense. I was running ./check | 13:27 |
| radiofree | `btrfs fi df /` is more meaningful | 13:27 |
| mauricemoss_ | ta radiofree! | 13:27 |
| jmalk | having upgraded to a devel machine, do I then need to configure and update morph, or is there a way of incorporating the devel system into the factory system where that is already done? | 13:31 |
| radiofree | http://wiki.baserock.org/using-latest-morph/ | 13:32 |
| radiofree | i'm not sure by "incorporating the devel system into the factory system" though? | 13:32 |
| radiofree | you went from build-system (factory) to devel system (mydevelsystem)? | 13:33 |
| paulsherwood | jmalk: if you mean, establish your new machine as default, you've already done by upgrading. | 13:33 |
| jmalk | radiofree: yes, by running scripts/cycle.sh, reboot into `devel`, and so now morph.conf, workspace etc. all need re-doing? | 13:33 |
| paulsherwood | you could (for example) system-version-manager remove factory | 13:33 |
| paulsherwood | jmalk: no, your config shoudl be picked up | 13:34 |
| jmalk | hmmm perhaps I've done something wrong or am looking in the wrong place for config then | 13:34 |
| paulsherwood | interesting | 13:34 |
| paulsherwood | what arch is this? are you in a vm? | 13:34 |
| jmalk | paulsherwood: x86_64 running on a vm on openstack | 13:35 |
| paulsherwood | i believe i've tried that successfully in the past | 13:35 |
| radiofree | jmalk: if your workspace was in /src you can just remount that | 13:35 |
| jmalk | radiofree: ah that sounds promising - it was, and src is no longer visible in `devel` | 13:36 |
| radiofree | you might need to redo the morph.conf symlink though | 13:36 |
| * paulsherwood wonders what's slipped here, though | 13:36 | |
| radiofree | was /src on another partition? | 13:36 |
| radiofree | if you added it to your fstab it should have been merged as part of the upgrade | 13:37 |
| radiofree | i.e you shouldn't need to remount it | 13:37 |
| jmalk | radiofree: in that case I'd assume I didn't set it up properly on another partition | 13:37 |
| tiagogomes_ | jmalk ops :) | 13:38 |
| jmalk | I shall try going back to my original factory machine and http://wiki.baserock.org/quick-start/#index3h2 do this | 13:38 |
| radiofree | jmalk: it should still be around then, it'll be in the factory subvolume | 13:38 |
| tiagogomes_ | jmalk, just to be sure, do you have /dev/sdb ? | 13:38 |
| radiofree | mount -t btrfs -o subvol=systems/default/factory /dev/yourhd /mnt | 13:38 |
| radiofree | should be in /mnt/src then | 13:38 |
| jmalk | tiagogomes_: sdb does not appear under dev # ls | 13:39 |
| paulsherwood | jmalk: just rebooting into the old one puts you back there | 13:39 |
| paulsherwood | you could system-version-manager set-default factory | 13:39 |
| jmalk | paulsherwood: yes, thanks | 13:39 |
| jmalk | tiagogomes_: given that I don't have /dev/sdb would you recommend adding that drive before working on the rest of this problem? | 13:46 |
| tiagogomes_ | jmalk, I am not entirely sure what the problem is. Are you using vbox, libvirt or openstack? Do you have another image that you can attach to the VM? | 13:47 |
| jmalk | tiagogomes_: openstack, and not afaik | 13:48 |
| *** a1exhughe5 has joined #baserock | 13:49 | |
| tiagogomes_ | jmalk the command posted by radiofree didn't help? | 13:52 |
| jmalk | tiagogomes_: will try it, I got confused by what order I should be trying suggestions in | 13:53 |
| jmalk | I don't know `yourhd` I'm afraid | 13:55 |
| tiagogomes_ | jmacs, /dev/sda most likely | 13:56 |
| jmalk | tiagogomes_: no sd* at all, mystifyingly | 13:57 |
| jmalk | tiagogomes_: http://paste.baserock.org/udatoneqoz | 13:57 |
| tiagogomes_ | jmalk wait, on open stack could be /dev/vda | 13:57 |
| jmalk | ah yes, there is a vda | 13:58 |
| jmalk | but attempting radiofree's suggestion fails with "No such file or directory" | 14:01 |
| pedroalvarez | jmalk: I think that the problem here is that /src wasn't a second drive | 14:01 |
| jmalk | pedroalvarez: seems that way | 14:01 |
| tiagogomes_ | no, that's not the problem I think | 14:05 |
| tiagogomes_ | you should be able to mount the subvolume | 14:05 |
| jmalk | my attempt at doing so: http://paste.baserock.org/buxawisabo | 14:06 |
| tiagogomes_ | ah, of course | 14:08 |
| tiagogomes_ | jmalk, `mount -t btrfs -o subvol=systems/factory/run /dev/vda` | 14:11 |
| tiagogomes_ | the default system doesn't have a factory sobvolume, only orig and run | 14:13 |
| jmalk | tiagogomes_: thanks, that (appended with /mnt) has made /src accessible under /mnt | 14:15 |
| tiagogomes_ | the strata/qt4-tools could build-depend on strata/ruby instead of having its own ruby building definitions | 14:34 |
| rdale_ | yes | 14:34 |
| *** paulwaters_ has joined #baserock | 14:42 | |
| *** paulw has quit IRC | 14:43 | |
| pedroalvarez | <pedroalvarez> I'd like to integrate a newer version of netcat in baserock, but I don't know which one: seems to be a bsd implementation and a nmap one.. Not sure which one we prefer :/ | 14:47 |
| pedroalvarez | Does anybody have any opinion about this ^ | 14:47 |
| rjek | OpenBSD for me. | 14:49 |
| rjek | assuming the nmap one is the thing Debian calls "netcat-traditional" | 14:50 |
| rjek | Which is broken | 14:50 |
| pedroalvarez | rjek: I found it looking at what netcat was using fedora | 14:50 |
| franred | pedroalvarez, so the options are http://nmap.org/ncat or http://netcat.sourceforge.net/ ? | 14:54 |
| pedroalvarez | franred: the former and http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/nc.1?query=nc | 14:55 |
| rjek | git://anonscm.debian.org/collab-maint/netcat-openbsd.git | 14:59 |
| rjek | Upstream: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/ | 14:59 |
| rjek | (But the Debian repo includes patches to make it work nicely on Linux) | 14:59 |
| *** a1exhughe5 has quit IRC | 15:01 | |
| *** a1exhughe5 has joined #baserock | 15:17 | |
| tlsa | ok, I've got another question! | 15:22 |
| tlsa | when building xfce/xfconf, its tests fail because of some makefile error | 15:23 |
| tlsa | the fix has gone into its master | 15:23 |
| tlsa | it seems they've not tagged a release for 3 years | 15:24 |
| tlsa | we currenrly build a branch which seems to be some random point in the history of master, with an xfconf.morph added | 15:25 |
| tlsa | I could make a branch from the commit which actually fixed the problem | 15:26 |
| tlsa | or I could make a branch from the current head | 15:26 |
| pedroalvarez | tlsa: does the current branch has anything else? or just the .morph file? | 15:26 |
| tlsa | the history is almost entierly composed of translation (internationalisation) updates | 15:26 |
| tlsa | pedroalvarez: http://git.baserock.org/cgi-bin/cgit.cgi/delta/xfce/xfconf.git/log/?h=baserock/morph | 15:27 |
| pedroalvarez | tlsa: if only the .morph file, you can then point to the current head in 'ref' | 15:27 |
| tlsa | right | 15:27 |
| tlsa | yeah, so I'll set the ref to the sha1 of the current HEAD | 15:28 |
| pedroalvarez | tlsa: yup, and unpetrify-ref: master | 15:28 |
| tlsa | pedroalvarez: :) I was just asking that | 15:28 |
| pedroalvarez | tlsa: so playing with xfce eh? sounds fun | 15:35 |
| tlsa | it just happened to be the first system I tried to build :) | 15:36 |
| tlsa | seems to have bitrotted a bit | 15:37 |
| radiofree | maybe we should add something like https://github.com/hawaii-desktop/hawaii-shell for a "desktop" environment | 15:43 |
| radiofree | rdale_: does qt5 build for a weston system? | 15:43 |
| radiofree | (using baserock) | 15:43 |
| tlsa | anyone seen "warning _FORTIFY_SOURCE requires compiling with optimization (-O)" before? | 15:43 |
| tlsa | I guess I should try updating to a newer version of the chunk (libxfce4ui) | 15:44 |
| pedroalvarez | :) | 15:44 |
| rdale_ | radiofree: yes i think the qt 5.3.2 tags should build with weston | 15:45 |
| radiofree | rdale_: i know you can compile qt5 without any X, i was just wondering if that's possible in baserock these daysa | 15:45 |
| radiofree | s/daysa/days | 15:45 |
| rdale_ | currently qt5 can be build with a minimal xwayland if you use jjardon's baserock/jjardon/xcb-util branch. but support for full featured xserver or wayland isn't in defintions afaik | 15:49 |
| radiofree | pedroalvarez: ooops http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/strata/foundation/systemd.morph~ | 15:49 |
| radiofree | rdale_: i suppose i could just compile qt-wayland afterwards though? | 15:50 |
| pedroalvarez | radiofree: shhh!! | 15:50 |
| pedroalvarez | radiofree: I don't know how I managed to do that.. | 15:51 |
| pedroalvarez | http://paste.baserock.org/iletozujuz | 15:54 |
| radiofree | +1 | 15:54 |
| radiofree | pedroalvarez: is it different to system.morph? | 15:54 |
| radiofree | in the temp file it does the network match on Name=en*, so i suppose you don't want system.morph | 15:55 |
| radiofree | so still +1 :) | 15:56 |
| pedroalvarez | radiofree: yes s/e*/en*/ | 15:56 |
| radiofree | so it's fine to just delete the temp file then | 15:56 |
| tiagogomes_ | pedroalvarez obviously, +1 | 15:58 |
| pedroalvarez | merged, thanks! | 16:04 |
| * pedroalvarez is still excited about how http://irclogs.baserock.org/ work these days | 16:05 | |
| Zara | ooh! | 16:06 |
| radiofree | actually hawaii-shell needs a load of things from kde | 16:08 |
| * radiofree moves on | 16:08 | |
| CTtpollard | pedroalvarez: can you get it to ignore joins/leaves ? | 16:11 |
| rdale_ | what are gmp, mpfr and mpc that gcc sometimes needs to build? | 16:16 |
| jmacs | Maths libraries | 16:18 |
| rdale_ | ah ok thanks | 16:18 |
| pedroalvarez | CTtpollard: do you think that is important? I think is good to know when someone has joined or left | 16:22 |
| mwilliams_ct | fwiw I agree with pedroalvarez | 16:22 |
| mwilliams_ct | It's useful to know who's about (eg to see if somebody who might have given a useful answer was about at a certain time) | 16:23 |
| jmacs | Being connected to the channel is no guarantee of someone being about, though. | 16:24 |
| CTtpollard | yes both options have plus points, personally I think it would reduce the noise when trying to digest info from it | 16:24 |
| De|ta | perhaps a filter on the display of logs | 16:25 |
| perryl | maybe remove joins/parts if someone has a bad connection, i.e. they join/part multiple times in quick succession? | 16:26 |
| De|ta | a log should log everything in the channel, if someone viewing the log doesn't want to see all the information then they (or their log viewer) should filter out what they don't want to see. | 16:27 |
| pedroalvarez | I didn't want to make it more complex. Currently is just a supybot logging, and a systemd unit running every 5 minutes to generate the htmls using logs2html | 16:27 |
| pedroalvarez | i may end up adding a search box, but nothing else | 16:28 |
| pedroalvarez | (just because logs2html has this implemented) | 16:28 |
| straycat | pedroalvarez, nova.conf seems to be set to use neutron as the network api, running neutron gives me an 'unsupported locale setting' error, i can set LC_ALL=C before I run though, just wanted to flag this | 16:40 |
| pedroalvarez | straycat: yeah, that error is caused because when connecting through ssh the LANG changes. It works ok if you run that command from the console | 16:43 |
| *** jonathanmaw has quit IRC | 17:02 | |
| *** CTtpollard has quit IRC | 17:03 | |
| *** jonathanmaw has joined #baserock | 17:04 | |
| radiofree | gcc failing to build on my jetson | 17:07 |
| radiofree | do i need to upgrade the devel image to be able to build it/ | 17:07 |
| radiofree | http://fpaste.org/185292/38472861/ | 17:08 |
| *** edcragg has quit IRC | 17:09 | |
| radiofree | maybe updating morph fixed it | 17:15 |
| *** jonathanmaw has quit IRC | 17:25 | |
| *** edcragg has joined #baserock | 17:26 | |
| radiofree | yep, it did | 17:31 |
| *** mariaderidder has quit IRC | 17:33 | |
| tiagogomes_ | mmm powerpc doesn't include the nodejs strata. | 17:37 |
| tiagogomes_ | powerpc devel | 17:37 |
| radiofree | tiagogomes_: i don't think it compiles there | 17:40 |
| tiagogomes_ | that's what the web says (although there is some fork), it is not compiling on armv8 either | 17:40 |
| radiofree | problems with v8? | 17:41 |
| tiagogomes_ | it is failing before building v8 | 17:42 |
| radiofree | which bit? | 17:42 |
| radiofree | maybe try upgrading, at least where v8 is concerned there's "arm64" code that's in master but not in the version we're using | 17:42 |
| tiagogomes_ | ../deps/openssl/openssl/include/openssl/../../crypto/bn/bn.h:816:43: error: unknown type name 'BN_ULONG' | 17:43 |
| radiofree | although the easiest thing to do would be to remove it from the armv8 server | 17:43 |
| tiagogomes_ | why is v8 inside nodejs anyway | 17:43 |
| radiofree | because javascript | 17:44 |
| tlsa | so the xfce4-system build finally completed, but when starting it | 17:44 |
| tlsa | when I run startxfce4, it gives sh: xinit: not found | 17:44 |
| radiofree | tiagogomes_: the only thing i can recommend is to upgrade it to the last release | 17:44 |
| tiagogomes_ | radiofree yes, but nodejs should depend on v8, instead of having an embedded copy | 17:45 |
| tiagogomes_ | radiofree, I tried the last release of nodejs | 17:45 |
| radiofree | tiagogomes_: sure, but looks like it's shipping openssl as well | 17:45 |
| tlsa | so I guess there are other deps missing that the build didn't notice | 17:45 |
| radiofree | tiagogomes_: drop it then, i wouldn't have thought it's essential | 17:45 |
| radiofree | what do we use nodejs for in baserock? | 17:45 |
| tiagogomes_ | cares debugger-agent http_parser mdb_v8 npm openssl uv v8 zlib | 17:45 |
| tiagogomes_ | it has embedded a lot of things | 17:46 |
| pedroalvarez | tlsa: it would need X to run (I guess) | 17:46 |
| tlsa | yeah, I guess its something missing from the cluster | 17:46 |
| tlsa | looking into it | 17:46 |
| pedroalvarez | radiofree: the import tool needs it to import npm packages | 17:46 |
| radiofree | pedroalvarez: but it's not essential? | 17:47 |
| tlsa | i mean missing from the system | 17:47 |
| pedroalvarez | tlsa: there have been a lot of canges to the graphic stack, moving the systems from X to Wayland, so many things can be wrong with that system now | 17:47 |
| pedroalvarez | radiofree: yeah, that's why we release the 'build' system and not the 'devel' system | 17:48 |
| pedroalvarez | but in the devel systems we want to have nodejs to be able to use all the baserock dev tools (like the import tool in this case) | 17:49 |
| radiofree | tlsa: do you have x-generic and x-common? | 17:49 |
| radiofree | npm is node package manager right? | 17:49 |
| radiofree | so you only need nodejs in a devel system if you want to use nodejs, parts of baserock don't depend on it? | 17:50 |
| tlsa | radiofree: yep, the system has both of those | 17:50 |
| radiofree | tlsa: i don't know then, it's been a while since anyone tried it | 17:51 |
| tlsa | anyone know which chunk xinit should come from? | 17:52 |
| *** Krin has quit IRC | 17:52 | |
| radiofree | tlsa: are you building from master? | 17:52 |
| tlsa | yes | 17:53 |
| tlsa | master of definitions | 17:53 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/x-generic/xserver.morph | 17:53 |
| *** tiagogomes_ has quit IRC | 17:53 | |
| radiofree | in our brave new wayland only world we seem to be building just enough of x for xwayland to work... | 17:53 |
| radiofree | ` --disable-xorg `, so i guess you don't actually have an xserver there | 17:54 |
| *** bashrc has quit IRC | 17:54 | |
| tlsa | hah, right | 17:54 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/strata/x-generic/xserver.morph?id=cb82ada6372a55273275c124ca11048f46bd811c | 17:54 |
| tlsa | should we have a separate chunk with the xorg enabled? | 17:55 |
| tlsa | not sure if xfce is supposed to work with wayland | 17:55 |
| radiofree | well it would be a bit odd running it in weston | 17:56 |
| radiofree | you could add another strata/xorg i supposed (copy of x-generic that uses a different xserver morph) | 17:57 |
| radiofree | then update strata/xfce.morph to use that, and systems/xfce-system | 17:57 |
| radiofree | however, x-generic probably doesn't contain enough x dependencies to build x any more http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/strata/x-generic.morph?id=f46ab53b310fae1d43a5ea6b959dfcb001931545 | 17:58 |
| *** CTtpollard has joined #baserock | 17:58 | |
| tlsa | radiofree: can we do this: | 18:01 |
| tlsa | x-common | 18:01 |
| tlsa | / \ | 18:01 |
| tlsa | x-xorg x-wayland | 18:01 |
| tlsa | \ / | 18:01 |
| tlsa | x-generic | 18:01 |
| tlsa | ? | 18:01 |
| straycat | :D | 18:01 |
| straycat | ♥ | 18:01 |
| tlsa | :) | 18:02 |
| radiofree | the general idea now is that x-generic is only enough to build xwayland | 18:02 |
| tlsa | then it shouldn't be called x-generic? | 18:02 |
| radiofree | i don't think we can do what you want in baserock (i.e x-generic with a 'wayland' use flag uses x-wayland + wayland only config options for xserver) | 18:03 |
| radiofree | no, i guess it shouldn't | 18:03 |
| radiofree | however, i think jjardon actually needs a full x server for gnome.... | 18:03 |
| tlsa | ok thanks radiofree | 18:03 |
| radiofree | having x-xorg and x-wayland makes sense to me | 18:03 |
| tlsa | I shall speek with jjardon on Monday :) | 18:03 |
| radiofree | rename x-generic x-wayland, and create a new x-org | 18:03 |
| ssam2 | X11 is needed only for Wacom tablet support in GNOME | 18:04 |
| radiofree | lovely | 18:04 |
| tlsa | yeah, seems the most sensible way | 18:04 |
| radiofree | ssam2: so it's optional? | 18:04 |
| ssam2 | the maintainer of some lowlevel components clearly loves his Wacom tablet and doesn't make it optional | 18:04 |
| ssam2 | but it would be fairly easy to patch it out | 18:04 |
| *** sambishop has quit IRC | 18:04 | |
| radiofree | this explains why i always have "Wacom tablet" in my gnome settings then | 18:04 |
| ssam2 | yeah. it happens to be the maintainer of gnome-settings ;) | 18:05 |
| *** a1exhughe5 has quit IRC | 18:10 | |
| * radiofree misses cache.baserock.org | 18:14 | |
| radiofree | i think my gcc problem from before was because i did rm -rf tmp/ during the actual build | 18:18 |
| radiofree | which isn't a good idea | 18:19 |
| ssam2 | what's wrong with cache.baserock.org ? | 18:30 |
| ssam2 | http://mason-x86-64.baserock.org/ is green ! | 18:30 |
| radiofree | ssam2: no cache for arm | 18:30 |
| *** CTtpollard has quit IRC | 18:31 | |
| radiofree | m4-tarball failed to build... | 18:31 |
| * radiofree thinks that's a good time to go home | 18:31 | |
| radiofree | http://fpaste.org/185324/42385235/ | 18:32 |
| radiofree | same error | 18:34 |
| radiofree | http://fpaste.org/185325/42385254/ | 18:35 |
| *** gfinney_ has quit IRC | 18:35 | |
| radiofree | well i gather this works on armv8 | 18:36 |
| *** gary_perkins has quit IRC | 18:37 | |
| ssam2 | radiofree: oh yeah. | 18:42 |
| ssam2 | once the Moonshot is working .... | 18:43 |
| * ssam2 -> pub | 18:43 | |
| *** ssam2 has quit IRC | 18:43 | |
| *** edcragg has quit IRC | 18:49 | |
| *** rdale_ has quit IRC | 19:40 | |
| *** zoli__ has quit IRC | 20:39 | |
| *** zoli__ has joined #baserock | 20:40 | |
| *** pacon has joined #baserock | 20:42 | |
| *** zoli__ has quit IRC | 22:19 | |
| *** pacon has quit IRC | 22:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!