IRC logs for #baserock for Friday, 2015-02-13

*** nowster has quit IRC00:11
*** paulw has quit IRC00:11
*** flatmush has quit IRC00:11
*** fay_ has quit IRC00:11
*** mauricemoss_ has quit IRC00:11
*** paulw has joined #baserock00:12
*** nowster has joined #baserock00:12
*** fay_ has joined #baserock00:12
*** mauricemoss_ has joined #baserock00:12
*** flatmush has joined #baserock00:13
*** nowster_ has joined #baserock00:21
*** flatmush has quit IRC00:21
*** paulw has quit IRC00:21
*** mauricemoss_ has quit IRC00:21
*** nowster has quit IRC00:21
*** fay_ has quit IRC00:21
*** fay_ has joined #baserock00:21
*** mauricemoss_ has joined #baserock00:21
*** paulw has joined #baserock00:22
*** flatmush has joined #baserock00:22
*** zoli__ has quit IRC00:46
*** zoli__ has joined #baserock00:47
*** zoli__ has quit IRC01:15
*** zoli__ has joined #baserock01:51
*** zoli__ has quit IRC02:14
*** wschaller has joined #baserock03:00
*** wschaller has quit IRC03:16
*** zoli__ has joined #baserock03:18
*** zoli__ has quit IRC03:31
*** zoli__ has joined #baserock03:43
*** zoli__ has quit IRC03:54
*** zoli__ has joined #baserock04:03
*** zoli__ has quit IRC05:59
*** zoli__ has joined #baserock05:59
*** zoli__ has joined #baserock06:16
*** zoli__ has quit IRC06:24
*** zoli__ has joined #baserock07:50
*** sambishop has quit IRC08:11
*** gfinney_ has joined #baserock08:22
paulsherwoodpdar: i ended up arguing strongly that runtime dependencies are already covered by the structure of typical definitions08:35
paulsherwoodi 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 #baserock08:37
paulsherwoodi pushed back strongly on this because the scheme suggested seemed to complicate matters further, where i would like to see things simplified08:38
*** rdale has joined #baserock08:40
paulsherwoodsaying 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 B08:43
paulsherwoodwe'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 B08:46
paulsherwoodthe groupings are definitely useful, but the dependencies are not rigorously established. i'm not sure that making them explicit would actually be of any benefit08:48
*** sambishop has joined #baserock08:55
*** franred has joined #baserock08: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 established08:57
*** mariaderidder has joined #baserock08:58
*** edcragg has joined #baserock08: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, etc09:01
*** CTtpollard has quit IRC09:02
*** bashrc has joined #baserock09: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 anywhere09:11
straycatit 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 sure09:15
*** CTtpollard has joined #baserock09:17
*** tpollard_ has joined #baserock09:17
straycatso it might be more useful to explicitly build-depend on chunks rather than strata, and just use strata for grouping chunks together09:18
jjardonRed in !09:18
franredstraycat, maybe also add the build dependecy in the chunk?09:19
jjardonSeems gst-plugins-good is failing but thats strange as the last commit doest change anything related09:19
*** CTtpollard has quit IRC09:21
straycatfranred, you mean in the chunk morph?09:23
franredstraycat, yes09:23
* straycat nods09:23
*** tpollard_ has quit IRC09:23
*** CTtpollard has joined #baserock09:23
* ratmice__ notes the thing isn't going to work for setuid binaries & sincerely hopes setuid binaries aren't going runtime dependency fancy09:25
straycatI guess putting it in either would work fine, and you don't need to enforce a particular scheme if you let people inline chunk morphs09:25
straycatratmice__, wasn't saying anything about runtime deps in this case?09:26
ratmice__straycat: paul did sometime up a ways09:27
straycatah :)09:27
franredjjardon, it is weird, in does not fail at the same point - so something doggy is happening09: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 outputs09:29
jjardonfranred: i think Its gstreamer-plugins-good-misc what is failing there as well, isn't?09:31
*** tiagogomes_ has joined #baserock09:32
franredjjardon, true... thats true.. but the build does not stop there :/09:33
jjardonI think that's because there are several workers in parallel09:33
*** ssam2 has joined #baserock09:37
*** ChanServ sets mode: +v ssam209:37
*** jonathanmaw has joined #baserock09:37
tlsadoes anyone know why systems/xfce-system.morph depends on strata/genivi.morph ?09:43
tlsaI tried to builf the xfce system, but it failed at09:43
tlsa[Build 218/297] [genivi-common-api-runtime] Running configure-commands09:43
tlsaconfigure: error: cannot find install-sh,, or shtool in "." "./.." "./../.."09:44
tlsanot sure if that means genivi systems also fail to build or not09:44
paulsherwoodtlsa: 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 tim09:44
paulsherwoodafaik genivi systems build ok09:45
paulsherwoodso there will be something odd in the stratum ordering perhaps09:45
tlsaoh, the strata order in the system morph is important?09:46
* tlsa has restarted morph build, after removing the genivi strata09:48
jjardonfranred: do you have any problem building the Weston system in current definitions master? I will check myself later09:49
*** gary_perkins has joined #baserock09:52
ssam2tlsa: stratum order in the system morph isn't important, any order should work09:54
ssam2but there may be some stratum build-deps that are wrong, for the xfce stratum09:54
tlsa[Build 222/284] [gtk+] Running configure-commands09:55
tlsaYou must have automake 1.7.x, 1,10.x, 1.11.x, 1.12.x, 1.13.x or 1.14.x09:55
tlsaso I guess it needs whatever stratum has the autotools before it gets to gtk09:55
ssam2ah, we updated to automake 1.15 recently10:00
ssam2is this gtk+ 2? I think that needs patching to support automake 1.1510:00
ssam2I saw a patch on the gtk mailing list recently10:00
ssam2you might be able to just use autoreconf instead of gtk+'s autogen.sh10:01
*** Krin has joined #baserock10:01
tiagogomes_probably not, autoreconf will call automake at some point10:02
ssam2but it will hopefully not have hardcoded out of date version requirements, unlike the custom autogen.sh10:02
tiagogomes_ah, the requirement is in, not in They it may work10:03
jjardonIs there any way I can set global configure options that will Ba applied to every chunk?10:10
jjardonLike --disable-werror10:11
ssam2jjardon: not right now, no10:14
ssam2well, you could hack Morph to add it to the default configure-commands10:14
*** mdunford has joined #baserock10:20
tiagogomes_Not every configure script supports werror, and some configure scripts will error with unrecognized options10:23
ssam2NB ALL: 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 gone10:33
pedroalvarezthanks ssam2  :)10:34
*** zoli__ has quit IRC10:45
jjardontiagogomes_: ?11:00
jjardonssam2: thanks!11:00
jjardontiagogomes_: if configure doesnt recognize an option it simply ignores it11:00
ssam2not all of them. autoconf-generated configure does11:00
jjardonssam2: not sure about that, jhbuild build with --disable-werror by default and no module is failing in all GNOME11:02
ssam2sure, GNOME modules all use Autoconf11:02
ssam2try Perl's configure script11:02
ssam2or lots of older programs11:02
ssam2well, not that many. But some11:02
tiagogomes_xstatic seems to be a summer festival in UK11:07
pedroalvarezright, mason still failing because of gstreamer-plugins-good11:12
jmalkpersia: thanks for the reply on docs, I'm still learning how and where to contribute :)11:17
jjardonssam2: rigth11:21
ssam2gstreamer-plugins-good is failing because pulseaudio is trying to autodetect its version from Git and is getting it wrong11:22
ssam2`./git-version-gen .` in the commit of pulseaudio we build returns '6.0~8'11:22
ssam2leading to PA_MINOR being defined as '0~8', which breaks the C macros that expect it to be a valid integer11:22
radiofreeinteresting that it's only failing now11:23
ssam2maybe it's due to the Git upgrade11:23
* jjardon hides11:23
ssam2perhaps there's a newer version of git-version-gen in git.git we can import11:23
*** zoli__ has joined #baserock11:27
*** rdale_ has joined #baserock11:35
ssam2I have the same issue with Git 1.9.3 on Fedora, in fact11:37
ssam2I think the problem is that since the v6.0 tag appeared, the 'git describe' output is different11:38
*** rdale has quit IRC11:38
ssam2upgrading 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
ssam2I'll report a bug upstream as well11:38
tlsawhat'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+.morph11:45
tlsabut I don't know whether the .diff file will be availabel where it builds11:45
jjardonssam2: yes, I will mkae a patch if you are not faster11:46
ssam2i've done one11:47
ssam2just testing it11:47
jjardonssam2: +111:47
pedroalvareztlsa: 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
ssam2I already saw a patch sent upstream11:49
ssam2although it was sent to gtk-devel-list instead of bugzilla, which is the wrong place11:49
ssam2there may be one in too11:49
tlsastill open11:50
tlsaand will be looked at before the next release11:50
ssam2fair enough. best create a branch in our delta/gtk+ in the meantime then11:50
tlsaok, what's the beat way to get the gtk+ repo now?  It the morph way that mangles definitions frowned on?11:51
ssam2morph edit is fine if it works for you11:52
rdale_how are gcc triples defined? doesn't 'x86_64-bootstrap-linux-gnu' have four parts?12:03
tlsaif a chunk has no unpetrify-ref, does that mean it defaults to master branch?12:04
tlsaand to make it use a particular branch, I'd add the branch as an unpetrify-ref field?12:05
franredtlsa, 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 sha112:08
tlsaoh, I see12:09
franredtlsa, if the chunk does not have unpetrify-ref you don't know from which branch/tag/ref the SHA1 was taken12:10
tlsayep, that's the case for
tlsanot sure how to work out where that ref is12:12
ssam2rdale_: linux-gnu is one part, effectively12:13
mauricemoss_rdale_, this seems to be the general definition: 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 anything12:14
ssam2e.g. on Fedora the 'vendor' field is 'redhat'12:14
rdale_thanks - yes my problem is with -bootstrap- i think12:14
jjardontlsa: Id upgrade to to latest GTK+2 version + you patch12:14
rdale_i need $ARCH-linux-musl for musl, and it isn't working with bootstap in the middle12:14
ssam2hmm, that's weird12:14
ssam2the 'bootstrap' is basically a trick to make the stage1 and stage2 compilers appear to be crosscompilers12:15
jjardontlsa: then create a branch like baserock/2.24.25+automake115_fix and point the gtk2 stratum there12:15
ssam2the vendor field is 'baserock' in the stage3 (normal) compilers12:16
ssam2hmm. actually it's 'unknown' :(12:16
ssam2it should be 'baserock', I wonder if that's a regression that's crept in12:17
tlsajjardon: OK, wasn't sure if I could do that, or if I should give the branch a presonal namespace12:17
tlsawhat's the process for reviewing changest to delta repos?12:17
ssam2don't. just send a patch to definitions updating the ref12:17
pedroalvareztlsa, jjardon: I prefer to use a personal branch until we decide to use it in definitions.git12:17
ssam2and link to the upstream bug in your cover letter12:18
mauricemoss_rdale_, for testing you can edit the triples here:
tlsapedroalvarez: a personal branch in delta repos, or in definitions?12:18
pedroalvareztlsa: delta repos12:18
pedroalvarezwell, 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 one12:19
tlsapedroalvarez: so baserock/tlsa/foo?12:19
tlsafor branch name12:19
pedroalvareztlsa: 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 repo12:19
tiagogomes_ssam2 why it should be baserock?12:20
pedroalvareztlsa: is tlsa your username in trove? `ssh whoami`12:20
tiagogomes_On fedora is unknown as well12:21
jjardonpedroalvarez: problem with that is then you are reviewing a branch that can be different that the one that gets merged12:22
tlsapedroalvarez: no, I'm not, but I don't like my username on there :)12:22
tlsa('mike' instead of 'michael')12:22
pedroalvarezjjardon: problem with creating non personal branches, how do we identify branches that we are not using in definitions.git?12:23
tlsapedroalvarez: I think there are a lot of dead branches that aren't personal12:23
Kinnisontlsa: users can be renamed by a trove admin if you ask nicely12:23
tlsaKinnison: please can my username be changed :)12:24
ssam2tiagogomes_: because it's the vendor field, that's the point of it12:24
jjardonpedroalvarez: do we need to identify them? merged branches gets removed eventually12:24
Kinnisontlsa: You'd need to ask a trove-admin (and I am not one)12:24
ssam2on fedora: $ gcc -dumpmachine12:24
Kinnisontlsa: pedroalvarez might be, ssam2 I think is, richard_maw is12:25
franredssam2, is this --> enough to describe Xstatic?12:25
pedroalvarezyes, we are :) I can have a look at it. What username do you prefer?12:25
pedroalvareztlsa: ^12:25
Kinnisontlsa: they'll need to do something like: ssh user rename oldname newname12: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
ssam2tiagogomes_: it's not hugely important. but config.guess is lying to you, try `gcc -dumpmachine`12:26
Kinnisontlsa: after it's done, check your group memberships -- the git server should migrate them, but it may get confused if things are complex12:26
pedroalvarezI think that being trove-admin is not enough to do that change12:27
pedroalvarez"FATAL: Not authorized"12:27
Kinnisonpedroalvarez: 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'see12:28
Kinnisonpedroalvarez: that role, on troves, should be the git user on the trove itself, so you'll need someone who can get to that12:29
* Kinnison can't help much more, as he needs to go rest his leg in a way not conducive to typing on a laptop12:29
* Kinnison will be back later though12:29
pedroalvarezKinnison: I hope you get well soon12:29
tlsaKinnison: ok, thanks anyway :)12:30
tlsaon the subject of dead branches, delta/gtk+ has baserock/gnome, baserock/morph, baserock/morph-gtk-2, baserock/morph-gtk-3, baserock/xfce-build12:31
tlsaI'm not sure how to tell which contains the ref used in the gtk+ chunk in gtk2.morph12:32
pedroalvareztlsa: username changed, can you check the output of the `whoami` command to check that you are still in baserock-writers?12:32
tlsaor which are used elsewhere12:32
tlsapedroalvarez: that looks correct, thanks :)12:33
pedroalvareztlsa: 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 them12:33
tlsaoh, in case somone wants to build from an old definitions12:34
pedroalvareztlsa: If we start removing branches we will not be able to build systems of previous releases. And yes, we care about that12:34
* tlsa nods12: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
pedroalvarezI'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
ssam2gfinney_: I find pdb really useful12:52
gfinney_I was thinking that but pdb doesn't exist in my baserock vr.12:53
ssam2it does in mine.12:54
ssam2do you get an error when you 'import pdb' ?12:54
gfinney_Oh. Is there a way of installing it in there?12:54
ssam2it should be built into Python..12:55
radiofree`import pdb` works here as well12:56
paulsherwoodgfinney_: you need to add 'import pdb' to the file you want to establish a break in12:57
gfinney_Ah. Thanks12:58
mauricemoss_I'm getting 'No space left on device' although `df -h` states otherwise and `morph gc` exits with 'Bus error (core dumped)' Is this a btrfs problem?13:26
radiofreedf -h and btrfs don't get on very well13:26
ssam2your /tmp  is full13:26
ssam2maybe that's part of it13:27
mauricemoss_Ah, that makes sense. I was running ./check13:27
radiofree`btrfs fi df /` is more meaningful13:27
mauricemoss_ta radiofree!13:27
jmalkhaving 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
radiofreei'm not sure by "incorporating the devel system into the factory system" though?13:32
radiofreeyou went from build-system (factory) to devel system (mydevelsystem)?13:33
paulsherwoodjmalk: if you mean, establish your new machine as default, you've already done  by upgrading.13:33
jmalkradiofree: yes, by running scripts/, reboot into `devel`, and so now morph.conf, workspace etc. all need re-doing?13:33
paulsherwoodyou could (for example) system-version-manager remove factory13:33
paulsherwoodjmalk: no, your config shoudl be picked up13:34
jmalkhmmm perhaps I've done something wrong or am looking in the wrong place for config then13:34
paulsherwoodwhat arch is this? are you in a vm?13:34
jmalkpaulsherwood: x86_64 running on a vm on openstack13:35
paulsherwoodi believe i've tried that successfully in the past13:35
radiofreejmalk: if your workspace was in /src you can just remount that13:35
jmalkradiofree: ah that sounds promising - it was, and src is no longer visible in `devel`13:36
radiofreeyou might need to redo the morph.conf symlink though13:36
* paulsherwood wonders what's slipped here, though13:36
radiofreewas /src on another partition?13:36
radiofreeif you added it to your fstab it should have been merged as part of the upgrade13:37
radiofreei.e you shouldn't need to remount it13:37
jmalkradiofree: in that case I'd assume I didn't set it up properly on another partition13:37
tiagogomes_jmalk ops :)13:38
jmalkI shall try going back to my original factory machine and do this13:38
radiofreejmalk: it should still be around then, it'll be in the factory subvolume13:38
tiagogomes_jmalk, just to be sure, do you have /dev/sdb ?13:38
radiofreemount -t btrfs -o subvol=systems/default/factory /dev/yourhd /mnt13:38
radiofreeshould be in /mnt/src then13:38
jmalktiagogomes_: sdb does not appear under dev # ls13:39
paulsherwoodjmalk: just rebooting into the old one puts you back there13:39
paulsherwoodyou could system-version-manager set-default factory13:39
jmalkpaulsherwood: yes, thanks13:39
jmalktiagogomes_: 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
jmalktiagogomes_: openstack, and not afaik13:48
*** a1exhughe5 has joined #baserock13:49
tiagogomes_jmalk the command posted by radiofree didn't help?13:52
jmalktiagogomes_: will try it, I got confused by what order I should be trying suggestions in13:53
jmalkI don't know `yourhd` I'm afraid13:55
tiagogomes_jmacs, /dev/sda most likely13:56
jmalktiagogomes_: no sd* at all, mystifyingly13:57
tiagogomes_jmalk wait, on open stack could be /dev/vda13:57
jmalkah yes, there is a vda13:58
jmalkbut attempting radiofree's suggestion fails with "No such file or directory"14:01
pedroalvarezjmalk: I think that the problem here is that /src wasn't a second drive14:01
jmalkpedroalvarez: seems that way14:01
tiagogomes_no, that's not the problem I think14:05
tiagogomes_you should be able to mount the subvolume14:05
jmalkmy attempt at doing so:
tiagogomes_ah, of course14: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 run14:13
jmalktiagogomes_: thanks, that (appended with /mnt) has made /src accessible under /mnt14:15
tiagogomes_the strata/qt4-tools could build-depend on strata/ruby instead of having its own ruby building definitions14:34
*** paulwaters_ has joined #baserock14:42
*** paulw has quit IRC14: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
pedroalvarezDoes anybody have any opinion about this ^14:47
rjekOpenBSD for me.14:49
rjekassuming the nmap one is the thing Debian calls "netcat-traditional"14:50
rjekWhich is broken14:50
pedroalvarezrjek: I found it looking at what netcat was using fedora14:50
franredpedroalvarez, so the options are or ?14:54
pedroalvarezfranred: the former and
rjek(But the Debian repo includes patches to make it work nicely on Linux)14:59
*** a1exhughe5 has quit IRC15:01
*** a1exhughe5 has joined #baserock15:17
tlsaok, I've got another question!15:22
tlsawhen building xfce/xfconf, its tests fail because of some makefile error15:23
tlsathe fix has gone into its master15:23
tlsait seems they've not tagged a release for 3 years15:24
tlsawe currenrly build a branch which seems to be some random point in the history of master, with an xfconf.morph added15:25
tlsaI could make a branch from the commit which actually fixed the problem15:26
tlsaor I could make a branch from the current head15:26
pedroalvareztlsa: does the current branch has anything else? or just the .morph file?15:26
tlsathe history is almost entierly composed of translation (internationalisation) updates15:26
pedroalvareztlsa: if only the .morph file, you can then point to the current head in 'ref'15:27
tlsayeah, so I'll set the ref to the sha1 of the current HEAD15:28
pedroalvareztlsa: yup, and unpetrify-ref: master15:28
tlsapedroalvarez: :)  I was just asking that15:28
pedroalvareztlsa: so playing with xfce eh? sounds fun15:35
tlsait just happened to be the first system I tried to build :)15:36
tlsaseems to have bitrotted a bit15:37
radiofreemaybe we should add something like for a "desktop" environment15:43
radiofreerdale_: does qt5 build for a weston system?15:43
radiofree(using baserock)15:43
tlsaanyone seen "warning _FORTIFY_SOURCE requires compiling with optimization (-O)" before?15:43
tlsaI guess I should try updating to a newer version of the chunk (libxfce4ui)15:44
rdale_radiofree: yes i think the qt 5.3.2 tags should build with weston15:45
radiofreerdale_: i know you can compile qt5 without any X, i was just wondering if that's possible in baserock these daysa15: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 afaik15:49
radiofreepedroalvarez: ooops
radiofreerdale_: i suppose i could just compile qt-wayland afterwards though?15:50
pedroalvarezradiofree: shhh!!15:50
pedroalvarezradiofree: I don't know how I managed to do that..15:51
radiofreepedroalvarez: is it different to system.morph?15:54
radiofreein the temp file it does the network match on Name=en*, so i suppose you don't want system.morph15:55
radiofreeso still +1 :)15:56
pedroalvarezradiofree: yes s/e*/en*/15:56
radiofreeso it's fine to just delete the temp file then15:56
tiagogomes_pedroalvarez obviously, +115:58
pedroalvarezmerged, thanks!16:04
* pedroalvarez is still excited about how work these days16:05
radiofreeactually hawaii-shell needs a load of things from kde16:08
* radiofree moves on16:08
CTtpollardpedroalvarez: 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
jmacsMaths libraries16:18
rdale_ah ok thanks16:18
pedroalvarezCTtpollard: do you think that is important? I think is good to know when someone has joined or left16:22
mwilliams_ctfwiw I agree with pedroalvarez16:22
mwilliams_ctIt'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
jmacsBeing connected to the channel is no guarantee of someone being about, though.16:24
CTtpollardyes both options have plus points, personally I think it would reduce the noise when trying to digest info from it16:24
De|taperhaps a filter on the display of logs16:25
perrylmaybe remove joins/parts if someone has a bad connection, i.e. they join/part multiple times in quick succession?16:26
De|taa 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
pedroalvarezI 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 logs2html16:27
pedroalvarezi may end up adding a search box, but nothing else16:28
pedroalvarez(just because logs2html has this implemented)16:28
straycatpedroalvarez, 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 this16:40
pedroalvarezstraycat: yeah, that error is caused because when connecting through ssh the LANG changes. It works ok if you run that command from the console16:43
*** jonathanmaw has quit IRC17:02
*** CTtpollard has quit IRC17:03
*** jonathanmaw has joined #baserock17:04
radiofreegcc failing to build on my jetson17:07
radiofreedo i need to upgrade the devel image to be able to build it/17:07
*** edcragg has quit IRC17:09
radiofreemaybe updating morph fixed it17:15
*** jonathanmaw has quit IRC17:25
*** edcragg has joined #baserock17:26
radiofreeyep, it did17:31
*** mariaderidder has quit IRC17:33
tiagogomes_mmm powerpc doesn't include the nodejs strata.17:37
tiagogomes_powerpc devel17:37
radiofreetiagogomes_: i don't think it compiles there17:40
tiagogomes_that's what the web says (although there is some fork), it is not compiling on armv8 either17:40
radiofreeproblems with v8?17:41
tiagogomes_it is failing before building v817:42
radiofreewhich bit?17:42
radiofreemaybe try upgrading, at least where v8 is concerned there's "arm64" code that's in master but not in the version we're using17:42
tiagogomes_../deps/openssl/openssl/include/openssl/../../crypto/bn/bn.h:816:43: error: unknown type name 'BN_ULONG'17:43
radiofreealthough the easiest thing to do would be to remove it from the armv8 server17:43
tiagogomes_why is v8 inside nodejs anyway17:43
radiofreebecause javascript17:44
tlsaso the xfce4-system build finally completed, but when starting it17:44
tlsawhen I run startxfce4, it gives sh: xinit: not found17:44
radiofreetiagogomes_: the only thing i can recommend is to upgrade it to the last release17:44
tiagogomes_radiofree yes, but nodejs should depend on v8, instead of having an embedded copy17:45
tiagogomes_radiofree, I tried the last release of nodejs17:45
radiofreetiagogomes_: sure, but looks like it's shipping openssl as well17:45
tlsaso I guess there are other deps missing that the build didn't notice17:45
radiofreetiagogomes_: drop it then, i wouldn't have thought it's essential17:45
radiofreewhat do we use nodejs for in baserock?17:45
tiagogomes_cares           debugger-agent  http_parser     mdb_v8          npm             openssl         uv              v8              zlib17:45
tiagogomes_it has embedded a lot of things17:46
pedroalvareztlsa: it would need X to run (I guess)17:46
tlsayeah, I guess its something missing from the cluster17:46
tlsalooking into it17:46
pedroalvarezradiofree: the import tool needs it to import npm packages17:46
radiofreepedroalvarez: but it's not essential?17:47
tlsai mean missing from the system17:47
pedroalvareztlsa: 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 now17:47
pedroalvarezradiofree: yeah, that's why we release the 'build' system and not the 'devel' system17:48
pedroalvarezbut 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
radiofreetlsa: do you have x-generic and x-common?17:49
radiofreenpm is node package manager right?17:49
radiofreeso you only need nodejs in a devel system if you want to use nodejs, parts of baserock don't depend on it?17:50
tlsaradiofree: yep, the system has both of those17:50
radiofreetlsa: i don't know then, it's been a while since anyone tried it17:51
tlsaanyone know which chunk xinit should come from?17:52
*** Krin has quit IRC17:52
radiofreetlsa: are you building from master?17:52
tlsamaster of definitions17:53
*** tiagogomes_ has quit IRC17:53
radiofreein 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 there17:54
*** bashrc has quit IRC17:54
tlsahah, right17:54
tlsashould we have a separate chunk with the xorg enabled?17:55
tlsanot sure if xfce is supposed to work with wayland17:55
radiofreewell it would be a bit odd running it in weston17:56
radiofreeyou could add another strata/xorg i supposed (copy of x-generic that uses a different xserver morph)17:57
radiofreethen update strata/xfce.morph to use that, and systems/xfce-system17:57
radiofreehowever, x-generic probably doesn't contain enough x dependencies to build x any more
*** CTtpollard has joined #baserock17:58
tlsaradiofree: can we do this:18:01
tlsa       x-common18:01
tlsa         /  \18:01
tlsa    x-xorg  x-wayland18:01
tlsa         \  /18:01
tlsa       x-generic18:01
radiofreethe general idea now is that x-generic is only enough to build xwayland18:02
tlsathen it shouldn't be called x-generic?18:02
radiofreei 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
radiofreeno, i guess it shouldn't18:03
radiofreehowever, i think jjardon actually needs a full x server for gnome....18:03
tlsaok thanks radiofree18:03
radiofreehaving x-xorg and x-wayland makes sense to me18:03
tlsaI shall speek with jjardon on Monday :)18:03
radiofreerename x-generic x-wayland, and create a new x-org18:03
ssam2X11 is needed only for Wacom tablet support in GNOME18:04
tlsayeah, seems the most sensible way18:04
radiofreessam2: so it's optional?18:04
ssam2the maintainer of some lowlevel components clearly loves his Wacom tablet and doesn't make it optional18:04
ssam2but it would be fairly easy to patch it out18:04
*** sambishop has quit IRC18:04
radiofreethis explains why i always have "Wacom tablet" in my gnome settings then18:04
ssam2yeah. it happens to be the maintainer of gnome-settings ;)18:05
*** a1exhughe5 has quit IRC18:10
* radiofree misses cache.baserock.org18:14
radiofreei think my gcc problem from before was because i did rm -rf tmp/ during the actual build18:18
radiofreewhich isn't a good idea18:19
ssam2what's wrong with ?18:30
ssam2 is green !18:30
radiofreessam2: no cache for arm18:30
*** CTtpollard has quit IRC18:31
radiofreem4-tarball failed to build...18:31
* radiofree thinks that's a good time to go home18:31
radiofreesame error18:34
*** gfinney_ has quit IRC18:35
radiofreewell i gather this works on armv818:36
*** gary_perkins has quit IRC18:37
ssam2radiofree: oh yeah.18:42
ssam2once the Moonshot is working ....18:43
* ssam2 -> pub18:43
*** ssam2 has quit IRC18:43
*** edcragg has quit IRC18:49
*** rdale_ has quit IRC19:40
*** zoli__ has quit IRC20:39
*** zoli__ has joined #baserock20:40
*** pacon has joined #baserock20:42
*** zoli__ has quit IRC22:19
*** pacon has quit IRC22:57

Generated by 2.14.0 by Marius Gedminas - find it at!