IRC logs for #baserock for Tuesday, 2015-06-02

*** seb__ has joined #baserock01:04
*** seb__ has quit IRC02:19
*** rdale_ has joined #baserock02:31
*** rdale has quit IRC02:34
*** seb__ has joined #baserock02:44
*** seb__ has quit IRC03:10
*** seb__ has joined #baserock04:05
*** seb__ has quit IRC04:10
*** zoli__ has joined #baserock04:47
*** zoli___ has joined #baserock05:28
*** zoli__ has quit IRC05:30
*** franred has joined #baserock06:04
*** seb__ has joined #baserock06:05
*** zoli__ has joined #baserock06:34
*** zoli___ has quit IRC06:37
*** zoli__ has quit IRC06:38
*** zoli__ has joined #baserock06:57
*** a1exhughe5 has joined #baserock07:01
*** seb__ has quit IRC07:04
straycatDo we know what's going on with https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/morph+branch:ostree-staging+topic:ostree ?07:13
*** mariaderidder has joined #baserock07:33
*** mike has joined #baserock08:04
*** bashrc_ has joined #baserock08:04
*** mike is now known as Guest4944308:04
KinnisonIt's incomplete and has issues08:11
KinnisonI know richard_maw has been pondering it08:11
*** edcragg has joined #baserock08:12
*** jonathanmaw has joined #baserock08:19
*** Guest49443 has quit IRC08:19
*** Guest49443 has joined #baserock08:32
*** seb__ has joined #baserock08:34
*** gary_perkins has joined #baserock08:43
*** seb__ has quit IRC08:56
richard_mawit's all parked pending moving everything into /usr. We may be able to improperly do it by having a configuration extension merge /bin and /usr/bin etc., and move everything in /etc and /var into /usr/share/factory or /usr/etc08:58
pedroalvarezis that going to be needed for ostree? why?09:17
radiofreejjardon: good news is that the new mesa swrast dri driver works for most things! bad news is if you use a qt5 qml app and set "QT_WAYLAND_DISABLE_WINDOWDECORATION=1" there's a segfault09:18
richard_mawpedroalvarez: it deduplicates all files by hardlinking, so all empty files are the same, so when /etc/machine-id is written all empty files now contain the machine id09:20
SotKI want to send a patch to put all the deployment extensions which currently live in morphlib in definitions, whilst copying their history too. I've done this with `git filter-branch` in a morph checkout to get just the relevant history, then merged the result into definitions.09:22
jjardonradiofree: :( does this happen with the hardware accelerated driver as well?09:22
radiofreenope09:22
KinnisonSotK: sounds complex09:23
radiofreejjardon: the crash is in mesa's swrast driver09:23
SotKI fear that if I try to push this to Gerrit it will either try to create hundreds of changes or not work correctly09:23
KinnisonSotK: is the history valuable?09:23
richard_mawyes09:23
Kinnisoni.e. valuable for being *in* definitions09:23
jjardonradiofree: time to file a bug report?09:23
Kinnisonrather than the add commit saying "look at history from commit X in morph" ?09:23
radiofreejjardon: yeah, i'll try master then submit a bug09:23
SotKit means that git blame will still work without having to go looking in a different repo09:24
radiofreei need to test with a "clean" version of qt5 wayland as well, just to make sure it's not something we've added09:24
richard_mawSotK: IMO we should have a review of your changes to strip away the dependencies, and then push outside the gerrit workflow09:24
SotKrichard_maw: I haven't stripped any dependencies in this branch, just moved everything into one place and rearranged definitions to make it less of a mess09:26
*** mariaderidder has quit IRC09:27
jjardonUh, seems the tarball committed to the branch we are using of binutils-redhat repo doesn't contain the same as the binutils-tarball one09:27
richard_mawSotK: I see. Given a normal review won't work, I'll take a look at your branch directly.09:29
jjardonAnd it actually fails if you try to build from the binutils-tarball repo09:29
SotKrichard_maw: thanks, I'll push it once I've finished tidying it up09:30
paulsher1oodSotK: why not request review old-style, on the mailing list?09:33
richard_mawpaulsher1ood: because patches can't verify that the branch has been filtered appropriately09:34
richard_mawpaulsher1ood: there's no code change yet, so the only thing that is there to be reviewed is that it's been spliced into the history correctly09:34
richard_mawand that is not representable as a patch09:34
* richard_maw assumes the patches to reduce dependencies will be re-applied later via gerrit09:35
SotKindeed09:36
*** mariaderidder has joined #baserock09:39
richard_mawsystemd has officially moved to github now, though AIUI they are currently trying to work out which of the 3 repositories they have is going to be the canonical one09:42
KinnisonHeh09:43
KinnisonWhat was their justification?09:43
KinnisonThey were fed up of having to work when all their friends and colleagues got the day off because github was down?09:43
richard_mawsame as ours, they couldn't keep track of patches on the mailing list09:43
Kinnisonaah09:43
KinnisonSo they're going for pull requests?  Oh well09:43
richard_mawAIUI they are still going to accept patches on the mailing list, but they hope that having pull requests will result in fewer patches on the ML09:44
richard_mawand get some more drive-by patches from people who are better versed in github pull requests than mailing lists09:45
KinnisonFair enough09:45
KinnisonThey're high enough profile that drive-by patching is more plausible09:45
* richard_maw has done a few drive-by patches on the mailing list09:46
richard_mawthey've got 1 repository which was the read-only mirror from freedesktop.org, 1 which was imports of patches submitted to the mailing list and the new 1 which they intended to make the canonical one, but they appear to be looking into repurposing the first one instead09:48
KinnisonThe first makes sense09:50
Kinnisonsince people may already have been pulling from it09:50
richard_mawyep, it's also got the best name: github.com/systemd/systemd.git, the second is github.com/systemd-patches/systemd.git, the third is github.com/systemd-devs/systemd.git09:51
pedroalvarezew... I just added a stratum to the top of a sytem and nothing is happening09:59
pedroalvareznothing new builds09:59
SotKwith --local-changes=include?10:00
pedroalvarezyes10:01
pedroalvarezI wonder Morph also includes files that are not even commited10:01
pedroalvarez(new files)10:01
richard_mawpedroalvarez: it didn't used to10:02
pedroalvarezconfirmed, I'm stupid10:02
pedroalvarezI'm using a sha1 of a component that is already cached10:03
* pedroalvarez changes the sha110:03
*** tpollard_ has quit IRC10:03
pedroalvarezand yes, Morph includes new files in the build10:04
* jonathanmaw remembered a time when there was `morph petrify` what's the recommended way of doing it now?10:08
richard_mawof doing what?10:08
Kinnisonreplacing refs with sha1s presumably10:08
jonathanmawrichard_maw: ^ that10:08
SotKby hand afaik :(10:08
richard_mawI thought someone added a command for modifying definitions10:09
paulsher1oodrichard_maw: ah, ok10:10
jjardonrichard_maw: there is a branch for morph from sam where you can use morph petrify: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/log/?h=sam/petrify-hack10:10
radiofreelifesaver10:11
radiofreealthough that branch is pretty old now?10:11
jjardonlast time I tried it was easy to rebase10:12
* jonathanmaw doesn't have enough floating refs to bother with a hacky old morph. ta, though10:17
paulsher1oodpedroalvarez: fwiw ybd does use uncommitted files10:18
*** tpollard_ has joined #baserock10:18
*** zoli__ has quit IRC10:18
pedroalvarezapparently, Morph too10:18
paulsher1oodif you have the right option set :)10:20
straycatmorph's uncommitted files are committed though, which is useful for distbuilding10:21
paulsher1oodgood point10:21
jjardonmmm, seems our bootstrap process depend on some modifications made together with a gigantic commit here: http://git.baserock.org/cgi-bin/cgit.cgi/delta/binutils-redhat.git/log/?h=baserock/build-essential :(10:24
jjardonIm getting "configure: error: C++ preprocessor "/lib/cpp" fails sanity check" trying to compile stage2-binutils. Does it ring a bell to anyone?10:25
paulsher1oodjjardon: with morph?10:25
* paulsher1ood had that error a lot with ybd initially10:25
jjardonyes, with morph10:26
pedroalvarezew.. I don't understand Morph today10:27
paulsher1oodiirc Kinnison was usually the solution to problems like that :)10:27
pedroalvarezI've just created a stratum, which is a copy of foundation but only with things related to systemd (and systemd itself). I added this stratum to a system, without modifying foundation, and now I'm building things from tools.morph10:28
Kinnisonpedroalvarez: did you fail to change the name: field?10:29
richard_mawdid this system already contain foundation?10:29
* SotK pushes his all-extensions-in-definitions branch: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/?h=baserock/adamcoldrick/all-exts-in-definitions10:30
*** tpollard_ has quit IRC10:32
*** CTtpollard has joined #baserock10:32
* richard_maw is reading the changes10:34
pedroalvarezKinnison, richard_maw: the system has foundation, and also the new sytemd stratum. And I didn't change the name of anything.10:34
paulsher1oodSotK: looks tidy :) would it make any sense to call it deployment rather than extensions?10:34
Kinnisonpedroalvarez: my point is, if you didn't change the name: in your systemd stratum it might be squiffing 'foundation'10:34
richard_mawpedroalvarez: it's likely going insane because systemd indirectly depends on itself10:35
Kinnisonoh if your chunks have the same names it'll be confused yes10:35
pedroalvarezKinnison: Indeed, but I though we were immune to that "bug"10:35
Kinnisonhahaha10:35
pedroalvarezrichard_maw: hm.. no, new systemd stratum doesn't depend on foundation10:35
Kinnisonpedroalvarez: no, we're very vulnerable to it, as is ybd10:36
richard_mawpedroalvarez: ok, differently insane then10:36
Kinnisonbut at least ybd reports it10:36
richard_mawSotK: Is there any way to filter out the merge commits in the right parent of the commit to merge extensions into definitions?10:36
pedroalvarezKinnison, richard_maw: ok, understood. Thanks for clarifying10:37
richard_mawSotK: Otherwise it looks good to me.10:37
jjardonpaulsher1ood: any idea how did you fix it?10:45
paulsher1oodjjardon: cant remember, sorry - but Kinnison is normally expert in this kind of thing? I can try building on ybd if you want to put a branch somewhere?10:47
*** zoli__ has joined #baserock10:47
paulsher1oodSotK: does this need a VERSION update?10:50
* paulsher1ood also notices that README still talks about morphs, but that's a separate issue10:50
pedroalvarezjjardon: have you checked the differences between that version of binutils and the version we are using?10:51
jjardonpaulsher1ood: not sure is a tooling issue, but thanks for trying: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=jjardon/binutils-tarball10:51
jjardonpedroalvarez: yes10:52
pedroalvarezjjardon: are they massive?10:52
jjardonand its quite different10:52
jjardonyep10:52
paulsher1oodjjardon: which target are you building?10:52
jjardonpaulsher1ood: systems/base-system-x86_64-generic.morph10:53
pedroalvarezjjardon: is this relevant? http://git.baserock.org/cgi-bin/cgit.cgi/delta/binutils-redhat.git/commit/?h=baserock/build-essential&id=e727710:54
jjardonpedroalvarez: yes, I think so10:54
jjardonpedroalvarez: actually, I think thats the solution of the problem, thanks! :)10:55
pedroalvarezgreat!10:55
* paulsher1ood stops :)10:56
* straycat isn't sure about having to write 'extensions/type' in the cluster11:00
straycatbut other than that, seems better11:02
jjardonpedroalvarez: thinking twice, we now generate a c++ compiler in stage 1, so maybe that hack is not necessary anymore, let me try one thing11:17
*** pacon has joined #baserock11:29
jjardonwhat build-mode: bootstrap means?11:30
*** lachlanmackenzie has joined #baserock11:34
jjardonmmm, any idea why after this the stage2-binutils build still fail with the same cpp error? http://paste.baserock.org/ahowavuqow in this case stage2-binutils has the same build-deps as stage2-gcc, wich needs a g++ compiler as well11:37
straycatin bootstrap mode the chunk has access to the host's tools11:55
SotKpaulsher1ood: thankfully not, working around needing to do that is why the clusters now say things like "type: extensions/kvm" and systems list configuration extensions simlarly.11:58
jjardonah, ok, thanks straycat11:58
SotKstraycat: I'm not a huge fan either, but other than causing a version increase (and therefore needing a release doing before it can be fixed) there is nothing stopping us patching morph to return to the old look whilst keeping the extensions in a subdir11:59
SotKpaulsher1ood: I think I prefer "extensions" to "deployment", but thats probably because I'm used to thinking of them as "extensions" rather than something more generic and so am happy to change it based on other people's opinions12:00
* straycat nods12:01
SotKrichard_maw: I'm not sure what you mean by that :/12:06
* SotK wonders what paulsher1ood means when he says YBD builds without creating a graph12:13
SotKpaulsher1ood: do you still want YBD to look in $ybd-source-dir/exts for deployment extensions?12:16
*** lachlanmackenzie has quit IRC12:23
* richard_maw suspects YBD does actually use a graph, but that it's virtual rather than explicit12:35
SotKthat is how it appears to me after looking at the code12:36
* straycat wonders how ybd would do loop detection readably without constructing a graph12:37
rjekMark nodes already built?12:51
Kinnisonthat'd imply a graph for there to be nodes12:51
rjekA hash table containing already-built things?12:54
paulsher1oodybd recurses, and doesn't rebuild what's already there12:54
paulsher1ood(notices the artifact)12:55
paulsher1oodhence no graph12:56
rjekHow deep can Python recurse? :)12:57
paulsher1ooddeep enough for all of the current definitions in release.morph, for example12:59
paulsher1ood /win 3612:59
paulsher1oodbah :)12:59
richard_mawThe graph in this case is your call stack then. You're evaluating a graph you didn't explicitly construct, which means you can't reason about it before traversal, which we require to be able to provide a list of steps involved.13:02
* SotK doesn't see how that means there isn't at least a virtual graph there13:02
wdutchto be fair you can call anything a graph, a graph is a collection of things and relationships between things. It's only meaningful if you use graph-like metaphors13:03
paulsher1oodwdutch: thanks :)13:03
paulsher1oodrichard_maw: why do we require a list of steps?13:03
straycat*readably*13:04
* paulsher1ood has not found any requirement requiring reasoning about a graph before traversal so far13:04
* straycat sighs13:04
richard_mawWell for one it provides the counter of build steps you requested way back.13:04
rjekProgres... what richard_maw said13:04
straycatpaulsher1ood, https://gerrit.baserock.org/#/c/219/113:04
rjekAlso you can warn about loops and perhaps other states before you even begin.13:04
paulsher1oodok, that's one13:05
straycatbut anyway, i was only wondering how you'd solve that problem differently13:05
straycatwasn't saying you couldn't solve it differently :)13:05
paulsher1oodiiuc ybd warns about loops.... morph doesn't13:05
straycat14:06  straycat$ paulsher1ood, https://gerrit.baserock.org/#/c/219/113:06
richard_mawmorph does in the cases it understands, but we don't currently put loops in our test suite, so it breaks occasionally13:06
paulsher1oodstraycat: thanks :)13:06
straycatpaulsher1ood, where does ybd do that, just curious13:07
paulsher1oodybd understands, and warns, and from my pov has no graph and no test suite (except that i run it on real data all the time). i know this is philosophically different from others' recommended approach :)13:08
SotKISTM that the graph in YBD is represented in the dict in the Definitions object. The dict contains dicts which represent individual definitions, which have dependencies. The dependencies are a list of keys for the Definitions dict (ie "edges" connecting the "nodes"/individual definition dicts).13:08
paulsher1oodthat may be true13:09
richard_mawis *is* true13:09
straycatpaulsher1ood, i'm literally asking where you do that, cause i couldn't quickly find any warning messages that might indicate loop detection13:09
richard_mawyou *do* have a graph13:09
SotKThis is then traversed recursively when you build.13:09
richard_mawand any claims otherwise are just winding people up at this point13:09
* richard_maw wonders if he can mute himself13:09
paulsher1oodok, i'm wrong then. i'm not trying to wind anyone up. i didn't do comp sci13:09
richard_mawneither did other people here who see it as a graph13:10
pedroalvarezok, this topic is over :)13:11
paulsher1oodthanks :)13:11
richard_mawyes, and it turns out I'm not able to mute myself13:11
paulsher1oodstraycat: i may be wrong about the loop detection, too. i remember hitting examples, and putting code in to deal with it when it happened, but that was a long time ago.13:12
* paulsher1ood gets back to work13:12
straycatit's fine, i'm just sore cause whenever i make patches that involve graphing they never get merged :313:13
straycatbut hey, that's what weekends are for right13:13
straycatin any case we can't merge that cause it's not exactly sane13:13
*** lachlanmackenzie has joined #baserock13:22
* jjardon manages to build a pristine binutils tarball without the c++ hack13:31
paulsher1oodw00t!13:31
jjardonthe patch turns out to be quite simple: http://paste.baserock.org/xitiqoweji13:32
SotKrichard_maw: what did you mean by "filter out the merge commits in the right parent of the commit to merge extensions into definitions" earlier?13:38
richard_mawoh sorry, I forgot to respond to that13:38
richard_mawthere's merge commits like http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/adamcoldrick/all-exts-in-definitions&id=806de84bee5727d86059837ff62a9bf92aa54e8f in your history13:38
richard_mawwhich don't appear to touch or be related in any way to the extensions13:39
SotKoh, I see13:39
SotKindeed they don't, I'm not entirely sure why they ended up not being filtered out... I'll see if I can get rid of them13:39
richard_mawcheers13:40
richard_mawif not, no big loss, so don't waste too much time on it13:40
*** seb__ has joined #baserock13:48
pedroalvarezjjardon: make sure you don't break cross-bootstrap :)13:50
*** pacon has quit IRC13:52
jjardonpedroalvarez: you mean the generation of systems/cross-bootstrap-system-* systems?13:54
pedroalvarezjjardon: yes13:55
jjardonok13:56
jjardonis it ok to run 2 or more "morph build" instances at the same time? Or does morph make any assumption of being the only build process running?13:57
richard_mawit makes assumptions, so concurrent cache access may be an issue, as would any mount namespacey things, though I think I got most of those13:57
SotKrichard_maw: I think this should be better now: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/adamcoldrick/all-exts-in-definitions-v213:58
richard_mawSotK: +2, are you able to push that to the gerrit master yourself or do you need to have someone else do it?13:59
SotKI can push I think13:59
SotK+2 for all 4 commits?13:59
richard_mawyes14:00
SotKthanks :)14:00
* SotK pushes14:00
straycatcool14:00
pedroalvarez"4 commits"14:00
richard_mawpedroalvarez: well, we've already approved all the others elsewhere14:01
pedroalvarez:)14:02
SotKturns out I don't have permissions to push to master on gerrit :314:03
pedroalvarezyou can push to master of g.b.o14:04
SotKok then, I'll do that14:04
straycathang on?14:04
pedroalvarezok, hang on14:04
* SotK hangs14:04
pedroalvarezstraycat: yes?14:04
straycatlast time i pushed to gbo, people asked me not to because it can mess up the replication gerrit does14:04
richard_mawwe're going to push to the gerrit branch, not the g.b.o branch14:04
richard_mawthat should be replicated properly14:05
straycat15:05 +pedroalvarez$ you can push to master of g.b.o14:05
richard_mawgood catch straycat14:05
richard_mawI missed that14:05
richard_mawyes, definitely don't push to g.b.o14:05
pedroalvarez<SotK> turns out I don't have permissions to push to master on gerrit :314:05
* SotK doesn't do that14:05
straycati think we should give SotK perms14:05
* richard_maw agrees but lacks the perms to give SotK perms14:06
straycatpedroalvarez, do you have perms to set perms so SotK can have perms?14:06
* pedroalvarez hms14:06
rjekWe need some sort of graph tracking perm dependancies.14:06
pedroalvarezI have perms to give anyone perms to give perms14:07
straycatcool14:07
richard_mawpedroalvarez: Can I have perms to give SotK perms to push?14:07
ZaraI keep tabbing into channel and thinking you're all talking about your hair.14:07
pedroalvarezbut they are complex, let me have a look14:07
pedroalvarezrichard_maw: you would become part of the baserock-ops team14:07
richard_mawhm, I'll pass then14:08
pedroalvarezSotK: can you try now?14:11
* paulsher1ood is on Moonshot, manages to git clone Linux repo... 1,034,023,424 25.2MB/s in 32s 14:11
pedroalvarezpaulsher1ood: note that you only have 2 vcp and 2G Ram14:12
pedroalvarezs/vcp/vCPUs/14:12
* SotK pushes successfully14:13
SotKthanks pedroalvarez, straycat, richard_maw14:13
pedroalvarezIf we don't want people pushing to g.b.o, can we disable that?14:13
* pedroalvarez reverts the change14:14
SotK+1, I think that was the original plan too?14:14
pedroalvarezI'm interested on the -1's. I'm sure there is someone that doesn't like the idea14:15
jjardonpedroalvarez: you mean all g.b.o? or only the baserock/ namespace14:16
pedroalvarezjjardon: hm.. maybe only master branch of baserock/* projects?14:16
jjardonIm ok with that14:17
Kinnisonthat'd be a pretty simple patch providing it's easy to identify how gerrit pushes14:18
pedroalvarezoh, true, we can't block everyone :)14:20
paulsher1oodi know this is not exactly the right place to ask, but how would i install normal tools (gcc, make, autotools etc) on a vanilla ubuntu?14:26
rdale_apt-get intall build-essential?14:26
paulsher1oodah, ok14:27
paulsher1oodhttp://paste.baserock.org/hisojuvufe14:28
paulsher1ood:(14:28
radiofreepaulsher1ood: apt-get update14:28
radiofreethen do install build-essential14:28
radiofreei think (me doesn't use debian)14:29
* radiofree doesn't use debian14:29
paulsher1oodseems to be working, thanks radiofree !14:29
rjekYou might also want manpages-dev14:33
rjekWhich enragingly is not considered essential :)14:33
pedroalvarezWarning with new systemd 220: http://paste.baserock.org/raw/yogisuvava14:35
wdutchis there any documentation anywhere on morph plugins? I don't see anything in --help, the man page or the wiki but maybe I should be looking for something other than 'plugin'?14:36
mwilliams_ctwdutch: maybe extensions are what you mean?14:36
SotKwdutch: you mean the existing plugins? `morph help $command` should work14:36
wdutchSotK: I'm trying to install firehose but just getting a cliapp error "ERROR: unknown subcommand firehose"14:38
wdutchalthough now I try again I get a different error, time to figure out what I did ...14:38
SotKyou need to set MORPH_PLUGIN_PATH to include the directory containing the firehose plugins I imagine14:39
wdutchit looks like firehose.sh does that14:39
SotKhmm, what was the other error you got?14:40
wdutchERROR: Expected list of firehoses on command line14:40
SotKthat sounds like it found the plugin at least that time :)14:41
bashrc_I think I had similar issues with firehose14:41
* SotK doesn't really know much about how firehose is expected to work14:42
perrylwdutch: you'll need to run one of the YAML files as an argument, they should be in the firehose/examples/ directory14:42
wdutchthanks perryl14:42
straycatwhat's stopping the merge of https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/firehose+branch:master+topic:bmottram/firehose ?14:43
Zarais that info about running firehose in a readme or on the wiki anywhere?14:43
wdutchZara: there are instructions for installation in the README14:43
wdutchat least in some branches14:44
wdutchdoes gerrit provide a way to see merge conflicts? or do I just checkout, merge and see for myself?14:46
perryli was reviewing the README but wanted to test the instructions worked correctly first, and ran out of time14:47
bashrc_wdutch: are you using the perryl branch of firehose? I think there were various problems - especially contextmanager - which were resolved in my patch series14:47
straycatrichard_maw, any reason not to merge https://gerrit.baserock.org/#/c/679/3 if i give it a +1?14:47
wdutchbashrc_: I think I've checkout'd your patch series (or whatever gerrit calls them)14:49
richard_mawstraycat: depends if you feel more strongly about requiring more comments about needing to keep the version numbers up to date14:49
straycatrdale_ suggested checking the version number into the bison repo, i don't see why that's better14:49
bashrc_wdutch: ok, contextmanager should be ok then, but I do remember that being a cause of command not found14:49
bashrc_or "unknown subcommand"14:50
richard_mawthat was because it was accidentally applied to the class14:50
richard_mawbecause it belonged to a function that got removed during a rewrite14:50
jmacsWhat sets the size of /tmp on a baserock linux system?14:50
paulsher1oodwin 1914:50
paulsher1oodgahhhhhh14:51
richard_mawjmacs: systemd sets it to a percentage of your available ram14:51
rdale_straycat: i believe the version number for bison is part of the tarball, so we just need to not remove it when we check the tarball into the lorry repo14:51
richard_mawrdale_: and what happens if we use bison from git?14:51
richard_mawwe should be using things from git rather than their tarballs when possible14:51
radiofreejmacs: if you need a bigger one you can add it to your fstab14:52
jmacsI keep running out of space on /tmp trying to do a morph upgrade; is this a common problem?14:52
jmacsradiofree: I tried adding it to fstab, no effect14:52
rdale_in that case we would need to add the version to the git repo, if we wished to avoid using git at build time in baserock builds as i think we should14:52
radiofreejmacs: try telling systemd not to do it `systemctl mask tmp.mount`14:52
rdale_richard_maw: or we can just create the version file in the bison chunk as my patch does at the moment14:53
straycatadding the version to the git repo seems like an unnecessary delta14:54
* richard_maw wants version-commands14:54
richard_mawshove a bunch of information about the build in the environment and let it write the .gitversion file or equivalent14:55
jmacsRight, adding a tmpfs line to fstab and then mount -o remount /tmp seems to have done it14:55
straycatso what do we prefer, depending on git, or having to hardcode version information in a chunk morph?14:57
richard_mawbut until and unless we have version-commands, adding the version file in pre-configure commands and keeping comments about needing to keep it in sync when the sha1 changes is the least awful approach14:57
jmacsI don't get it, I've got 6GB clear on /tmp now and it's still running out of space14:57
straycatjmacs, might it just be running out of disk space on the rootfs rather than /tmp, i've had that quite a lot14:58
richard_mawstraycat: I'd prefer us to move away from depending on git, as it's technically a reproducibility hole14:58
straycatoh?14:58
richard_mawthere's nothing stopping it doing a `git checkout` to a different branch14:59
richard_mawand we've occasionally been hit with a more minor but more likely issue14:59
richard_mawnamely that `git describe` works on the entire contents of the repository, rather than the current checkout14:59
straycatahh14:59
richard_mawand we only use the sha1 of the current checkout in the cache key15:00
richard_mawit's not completely insane that there would be a component that during ./autogen.sh notices that it's run from a git checkout and checks out the most recent tagged release unless you pass an extra option, to stop people accidentally building the development head instead of a stable version15:01
richard_mawyeah, it's awful, but I can see a chain of events leading to it being an approach that is taken15:01
* straycat nods15:02
straycatrdale_, i'm happy to merge https://gerrit.baserock.org/#/c/679, but will add comments on merge, does this seem okay?15:02
* richard_maw is re-bootstrapping a system after adding strip-commands15:03
richard_mawConditionalised on `version: 5` in the VERSION file too!15:03
rdale_straycat: yes please merge. i not sure if i have much of an opinion about where the version should go, i mainly want core.morph to not include git and curl15:03
straycatwe seem to think leaving it in the chunk morph is the least awful option15:04
rdale_fine with me15:05
richard_mawrdale_: I'd be fine with leaving curl in there. Git being in there is an unfortunate hack because of tools that fetch their version from git.15:05
rdale_ok15:05
rdale_i only know of bison doing that in the core stratum15:06
jmacsstraycat: The error I'm getting is http://paste.baserock.org/zacipobune, looks like /tmp to me15:06
pedroalvarezradiofree: do you know if I should be worried about these warnings? http://paste.baserock.org/xivovegigo15:06
jmacsI have 1GB spare on /15:06
jmacsI'm probably doing something very stupid as I can't think clearly today15:06
radiofreepedroalvarez: no15:07
pedroalvarezok then :)15:07
richard_mawjmacs: the /tmp path is just because it's mounting your root disk on a tempdir15:07
richard_mawjmacs: it will be that / is too small15:07
jmacsOK, I shall fix that then15:08
jmacsI can't see what's going on as it removes the tmp.y9L71cJHme link15:08
pedroalvarezjmacs: that was only a mount point15:09
pedroalvarezjmacs: you can do `mount /dev/sda /mnt` to have the same thing in /mnt15:10
jmacsWhat's only a mount point?15:12
* straycat isn't using workspaces anymore, thanks to sam's patch, it's pretty nice15:13
pedroalvarezwoo15:14
pedroalvarezis it ready?15:14
pedroalvarez/tmp/tmp.y9L71cJHme15:14
straycatwell i haven't been able to find much wrong with it :)15:14
*** bwh has quit IRC15:15
*** petefotheringham has quit IRC15:15
*** petefotheringham has joined #baserock15:15
*** bwh has joined #baserock15:15
pedroalvarezok, systemd v220 worked well in trove & distbuild15:17
pedroalvareztesting now openstack15:17
*** zoli__ has quit IRC15:17
Kinnisoncool15:17
tlsaanyone able to +2 this for merge? https://gerrit.baserock.org/#/c/754/15:18
pedroalvareztlsa: "which can be useful".. does that mean that you don't know yet if you are going to use it or not?15:20
pedroalvarezthe lorry looks ok, but I want to avoid things in g.b.o that aren't needed15:22
pedroalvarezMaintaining them is really painful15:22
straycatrichard_maw, https://gerrit.baserock.org/#/c/679/4 is this fine with you?15:22
tlsato get deterministic builds we need to do things like provide a consistent built hostname and time.  libfaketime is used by gitian for this, and seems to be more than enough for our needs, from my investigations15:24
rdale_did you see the talk at fosdem about reproducible builds?15:25
tlsapedroalvarez: it can be useful for other things too, but I'm not interested in them at the current time.15:25
pedroalvareztlsa: I wonder if you can use "https://github.com/wolfcw/libfaketime.git" in your definitions and wait for the lorry once you have something ready15:26
tlsacan do15:27
straycatcan we abandon https://gerrit.baserock.org/#/c/560/ ?15:27
straycatjjardon, ^15:27
richard_mawtlsa: I'd prefer if we could do something with namespaces, but we can't do time with that even if we could patch our tooling to allow changing the hostname.15:28
jjardonstraycat: why?15:28
tlsanamespaces?15:29
Kinnisonjjardon: because you've done nothing to advance it since May 27th ?15:30
straycatjjardon, cause there's no clear plan to do anything with it15:30
richard_mawtlsa: you can have a different UTS namespace between processes, which lets different processes have a different hostname or domain name.15:30
jjardonKinnison: I did15:30
richard_mawtlsa: so you don't need a LD_PRELOAD to intercept the result of those syscalls15:31
Kinnisonjjardon: You've done nothing visible then15:31
tlsarichard_maw: right15:31
richard_mawtlsa: but there's nothing namespacey to do time fixing in-kernel15:32
tlsamm15:32
tlsaok15:32
jjardonKinnison: I think I replied to the requested questions15:32
Kinnisonyour reply isn't in gerrit15:32
jjardonstraycat: ok, I will abandon and maybe resubmit when I will use it for something. Is this a new policy15:33
pedroalvarezI'd like a policy like that15:33
richard_mawwe could drop all the ostree patches with a policy like that15:33
straycatnot exactly, but it seems logical to request lorries when we know for sure that we want them15:34
tlsaWhat's the pain from maintaining lorries?15:35
richard_mawthat downstream troves also get them15:35
tlsathey might have tiny discs, or something?15:35
jjardonKinnison: they are, please be specific if you want to discuss about something15:35
jjardonstraycat: abandoned15:36
straycatcheers15:36
richard_mawstraycat, rdale_: bison change approved and merged15:41
jjardonmaybe downstream troves should have the capability to choose what repos want to mirror?15:41
rdale_great, thanks15:41
richard_mawjjardon: they do, that doesn't mean we should be offering repositories we don't currently have a use for and may later remove15:42
richard_mawsince then the burden of continuing to update that repository is moved onto the downstream repository15:42
richard_mawand we have no way to notify that this has happened currently15:42
straycatcool thanks richard_maw15:44
jjardonok, understandable15:46
*** a1exhughe5 has quit IRC15:48
jjardonbtw, Im working in a branch to separate glib and gobject-introspection from core. Is this something we want to do? Not sure if someone more replay to rdale_ mail about trying to do a smaller core15:48
rdale_yes, i would prefer them in gnome-core or similar if possible15:49
* paulsher1ood fails to build stage2-glibc on ubuntu moonshot http://paste.baserock.org/ateyezikod15:49
pedroalvarezoh, re - arm64. I wonder if anybody has baserock image around15:50
pedroalvarezfor arm6415:50
richard_mawpaulsher1ood: looks like a bunch of missing header defines. This is partly why we build on Baserock systems, though I'm currently waiting on a build, so I can have a bit of a poke.15:57
*** mariaderidder has quit IRC15:58
*** CTtpollard has quit IRC16:00
paulsher1oodrichard_maw: thanks!16:01
richard_mawpaulsher1ood: That's a bit of a headscratcher. Did we completely land the aarch64 definitions from the port? If it builds with morph then some part of ybd isn't setting up the environment for the build commands to find the sysroot where the headers are located.16:03
richard_mawpaulsher1ood: If it fails with morph too, then the definitions are missing something to make them use the linux-api-headers that were prepared just before the stage2-glibc build.16:03
* richard_maw will have a poke to see what provides those definitions normally16:04
richard_mawI'm assuming it's linux-api-headers at the moment16:04
* richard_maw scratches his head a little at "checking whether the compiler is using the ARM hard-float ABI... no"16:08
paulsher1oodone thing, i'm assuming the target arch is armv8l6416:10
paulsher1ood?16:10
radiofreerichard_maw: i don't think we're compiling for aarch64 HF16:10
radiofreealso there's no guarantee the aarch64 stuff in baserock builds anymore16:10
radiofreethere hasn't been any hardware to test it on16:10
radiofreei'd suggested checking out definitions from when those patches landed and see if they work16:11
rdale_the linux headers for stage2 are quite old, 3.12 iirc16:12
radiofreei believe they have been upgraded16:12
rdale_ah ok16:12
richard_mawthey're on 4.016:12
radiofreehowever i know the upgrade to gcc 5 (now reverted) killed aarch64, so it's entirely possible something else has broken it16:13
richard_mawpaulsher1ood: I'm out of ideas. Those definitions should definitely have come from the linux-api-headers, but I can't see any reason why your build shouldn't be finding them. I'd need to have a proper sit-down in front of a build debugging session to work out why it's not finding the right headers.16:24
paulsher1oodthis could be a ybd-specific issue, of course?16:24
richard_mawpaulsher1ood: You could see if Ubuntu offers a way to download the right kernel headers and see if it's that we depend on the host there.16:24
paulsher1oodrichard_maw: but thanks for trying16:24
paulsher1oodwill do16:24
richard_mawpaulsher1ood: If it fails with morph I would have a higher degree in confidence that there's something wrong with the definitions (I'm not criticising YBD here, I'm just not familiar enough with the code).16:26
paulsher1oodrichard_maw: yup16:26
jjardonrdale_: maybe you can take a look to this when you have some time: https://gerrit.baserock.org/#/c/762/16:47
rdale_jjardon: looks good to me - those two repos must have a version file in them then?16:51
*** CTtpollard has joined #baserock16:53
*** franred has quit IRC16:54
*** bashrc_ has quit IRC17:01
jjardonI think is generated in bootstrap; they compile without problems17:04
rdale_ok, i've just given it a +1 then17:09
*** CTtpollard has quit IRC17:11
*** jonathanmaw has quit IRC17:11
jjardonWhat is the fastest way to see the config.log of some chunk that has been already built?17:15
*** gary_perkins has quit IRC17:34
*** lachlanmackenzie has quit IRC17:53
*** edcragg has quit IRC17:55
*** Guest49443 has quit IRC17:55
*** CTtpollard has joined #baserock18:09
jjardonHi, Im getting a weird error trying to deploy a system: http://paste.baserock.org/susarikiwe Anyone more with the same problem?18:33
jjardonOh, the extensions have been moved18:36
jjardonseems the problems is that essential-files/ has been moved to install-files/essential-files/ . Should I revert that or fix the essential-files extension to look in install-files/essential-files instead essential-files?18:46
*** CTtpollard has quit IRC19:01
jjardonnevermind, seems the install-files ext doesn't pick the INSTALL_FILES environment variable set in install-essential-files20:12
*** seb__ has quit IRC21:33
*** jjardon has quit IRC22:06
*** edcragg has joined #baserock22:07
*** jjardon has joined #baserock22:45
*** edcragg has quit IRC23:22

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!