IRC logs for #baserock for Friday, 2015-06-19

*** zoli__ has joined #baserock04:52
*** zoli__ has quit IRC06:26
*** zoli__ has joined #baserock06:45
*** zoli__ has quit IRC06:55
*** mariaderidder has joined #baserock07:56
*** zoli__ has joined #baserock08:07
*** zoli__ has quit IRC08:08
*** bashrc has joined #baserock08:15
*** bashrc has quit IRC08:18
*** bashrc has joined #baserock08:18
*** jonathanmaw has joined #baserock08:45
*** ssam2 has joined #baserock08:48
*** ChanServ sets mode: +v ssam208:48
ssam2 fixes a pretty annoying bug in `morph show-build-log`, could anyone give it a quick review?08:55
* SotK will take a look08:56
* franred too08:57
*** edcragg has joined #baserock08:59
SotKUsing setuptools, does anyone know if there is a way to set the commandline options of the egg_info command which is run automatically when you do `python install`?09:00
SotK(without using setup.cfg)09:01
ssam2wow, I have no idea09:01
ssam2YBD seems to break every time I leave it overnight ...09:04
ssam2this is the log output (it's quite long):
*** gary_perkins has joined #baserock09:05
ssam2I'm suspicious about the : 'tar: can't make dir ./usr/lib/terminfo/1: No such file or directory' errors09:06
ssam2especially as they seem to be mixed in with the log output from the post-install commands09:06
*** zoli__ has joined #baserock09:13
KinnisonPossibly ran out of disk?09:15
jmacsLooks like there's a file (non-directory) called /usr/lib/terminfo09:17
*** lachlanmackenzie has joined #baserock09:19
ssam2disks space is fine09:19
ssam2i'll investigate /usr/lib/terminfo, that might be it09:19
ssam2hmm, I can see the same thing happened again with ncurses earlier on09:21
ssam2so I guess it is that artifact. I'm confused how it managed a successful build, inbetween.09:22
ssam2but then, YBD randomises build order09:22
* ssam2 puts this info in
ssam2lrwxrwxrwx    1 root     root            17 Jun 19 09:31 /tmp/artifacttest/usr/lib/terminfo -> ../share/terminfo09:33
ssam2so you were close, jmac.. it's actually a broken symlink09:34
ssam2I guess I introduced this bug by sorting the order that the files are added to the .tar file! that seems a bit crazy, though09:35
ssam2seems wrong that `tar x` depends on the ordering of Python's os.listdir() in order to function.. I must be missing something09:36
*** zoli__ has quit IRC09:40
* ssam2 tries to figure out whether is a solution to this problem09:42
SotKso, babel hasn't seen a new commit in a year, and we already carry a patch against it, so I guess I'll just patch its setup.cfg to not put the date in the version since I can't figure out how to do taht on the command line09:42
paulsher1oodssam2: ironic that make_deterministic_gztar_archive was makign things non-deterministic :-)10:34
ssam2it was making things deterministic, just deterministically broken10:34
paulsher1oodSotK: offer the patch upstream?10:35
franredpaulsher1ood, looks like upstream is also not active - the repository of babel is managed by one unresponsive guy10:38
paulsher1oodfranred: fair enough, so long as we document that we've offered the patch10:38
franredsounds sensible10:39
franredpaulsher1ood, which system are you building?10:45
paulsher1oodbuild-system-x86_64 i believe10:46
paulsher1oodtechnically it's not me... it's concourse, running on a machine setup by drnic at stark and wayne10:47
paulsher1oodi wonder if it's picked up the make_deterministic_gztar_archive fix :)10:48
paulsher1oodconcourse does not support caching yet, hence it's puling in all the repos per run. which would get expensive if this were being done lots of times.10:49
paulsher1oodand it's slow, of course10:50
* ssam2 is slightly worried about getting this guy involved
jjardonpaulsher1ood: thats cool10:53
paulsher1oodjjardon: the coolest thing is that drnic set it up in less than a day, wallclock time. and i'm pretty sure he was working on other stuff at the time :)10:54
paulsher1oodwe need tofigure out the caching of artifacts and repos, but still... it has potential :)10:55
ssam2i deleted the broken ncurses artifact from my artifact cache, but instead of rebuilding it, YBD is exiting with 'cache artifact not found'10:59
ssam2any idea why it doesn't rebuild it?10:59
paulsher1oodssam2: because things that required it already exist, so the recursionbuild  logic doesn't spot the omission11:01
ssam2ah, I see11:01
paulsher1oodit would be nice to fix it, but not at the expense of lots of code and complexity11:02
paulsher1oodssam2: fix is to run ncurses11:02
ssam2ah, I didn't think of that11:03
paulsher1oodneither did i, until a month or so after issues/15 :)11:03
paulsher1oodouch, build 6 failed.11:04
persiassam2: I missed you yesterday, but on the .pyc issue: it appears that PEP 3147 covers similar ground.  PEP 304 also did, but this was withdrawn.  If you don't find someone by general request on #python, you might try contacting one of the PEP 3147 or PEP 304 authors.11:05
ssam2looks useful, thanks!11:06
ssam2SoTK: would you mind sending a patch against master to do ?11:20
ssam2(the HOSTNAME part of it)11:20
SotKssam2: sure11:40
paulsher1oodSotK: is ybd deployment now working? i haven't touched that part of the readme in a while11:49
SotKpaulsher1ood: it was when I last tried it11:50
paulsher1oodSotK: would you mind sending a patch for the readme?11:50
SotKpaulsher1ood: Which part? It still can't choose which systems in a cluster to deploy, change deployment parameters or deploy other architecture stuff as far as I am aware :)11:52
paulsher1oodSotK: if the readme represents the truth, then great. is it still 'a mess' ?11:53
SotKthat depends by what the definition of mess is11:55
SotKits tidier than it was11:55
paulsher1oodfor master definitions, can deployment now be done without morph present?11:58
SotKpaulsher1ood: not yet, the patch to remove the morphlib dependency is still in need of review on the ML11:58
paulsher1oodah, i thought that was inherent in the release you did11:59
* paulsher1ood goes to gerrit11:59
SotKpaulsher1ood: the patch is on baserock-dev rather than gerrit, since it contains merge commits12:00
* SotK apologises if paulsher1ood was going to gerrit for unrelated reasons :)12:00
ssam2Sotk: it has +1 from me12:01
paulsher1oodSotK: i can't find the patch - when did you send it?12:03
paulsher1oodSotK: and you did test it in the meantime?12:05
SotKpaulsher1ood: mostly, I don't remember testing virtualbox-ssh with it12:06
jmacsMorph seems to have some issues running under the version of bash in definitions.12:08
paulsher1oodis this recent/new, jmacs ?12:09
SotKjmacs: what are the issues?12:09
jmacsProbably not12:09
jmacsJust wondered if people knew about any issues - I'll report back when I have some more concrete evidence12:09
paulsher1oodSotK: +112:10
paulsher1oodjmacs: ok, thanks12:10
SotKpaulsher1ood: great, thanks!12:10
* SotK will merge it in a couple of hours unless there are complaints in the mean time12:11
SotKKinnison in particular may be interested12:11
KinnisonI may whatnow?12:30
KinnisonYour explanation sounds plausible, I will not block :)12:30
SotKKinnison: thanks :)12:31
jmacsThat error with morph upgrade inside bash:
jmacsIf anyone else is doing a morph upgrade today, could they try it inside bash?13:09
jmacsCould well be environment variables13:09
* paulsher1ood wonders if this also affects ybd13:10
SotKpaulsher1ood: it probably does, the code which caused the error is also in ybd13:11
SotKjmacs: does it work if you use busybox?13:12
jmacs/bin/sh is busybox13:13
jmacsThat's the default shell, and what I'm using for the first upgrade in that paste13:13
SotKaha, I didn't notice there were two commands :313:14
*** sambishop has quit IRC13:21
*** sambishop has joined #baserock13:35
ssam2jmacs: the reason is it is failing to parse $PS113:47
ssam2jmacs: i've seen this before, it's a stupid bug13:47
jmacsAah, I did have a custom PS1 in .bashrc13:50
SotKI intend to merge the stuff from in about 10 minutes if there are no objections15:07
SotKOK, I guess I need to push the merge to master of Gerrit rather than g.b.o as last time15:27
SotKcan anyone give me the correct permissions to do so (or have them and be willing to merge
paulsher1oodssam2: ^^15:29
ssam2SotK: I think anyone in Mergers group can do that. have you tried?15:31
SotKssam2: it didn't work when I was pushing the branch which moved the exts into definitions, pedroalvarez had to give me some permission iirc15:32
* SotK will try though15:32
ssam2i had a look at building HAProxy in Baserock15:35
ssam2seems that haproxy.git only has the development versions, haproxy-1.5.git has the last stable version15:35
ssam2should I send a patch to lorry haproxy-1.5.git? It seems less than ideal15:35
ssam2eventually we'll have 1.6, 1.7, ...15:35
ssam2the alternative is lorry both repos into our haproxy.git... but that doesn't sound very good either15:35
SotKssam2: is the outcome15:36
ssam2interesting, OK15:37
ssam2as a workaround you can push to and it'll be mirrored, the mirroring is still active.15:37
ssam2but I don't think I intended that to happen in the Gerrit config15:37
SotKok then15:37
SotKthere was a worry about pushing to g.b.o last time because of some issue with the mirroring breaking I think though?15:38
ssam2the problem is that there's a 2 minute window where a merge conflict can occur15:38
ssam2so it's not ideal15:38
ssam2I think the 'exclusiveGroupPermissions = push' line for refs/heads/master might have broken this15:38
ssam2it explicitly says anyone in Mergers group can 'Push' to refs/heads/*15:39
ssam2but Gerrit lets you negate things later on, so it's quite hard to understand the whole ruleset15:39
SotKok then, I'll push to g.b.o and hope no-one presses merge on anything for a couple of minutes :)15:39
* ssam2 decides HAproxy-in-Baserock is too ambitious for this time on a Friday anyway15:40
*** CTtpollard has quit IRC15:54
perrylpaulsher1ood: i've sent a pull request for my automated build/diff check script15:55
* perryl vows to write it in python next time :)15:55
paulsher1oodperryl: :)15:58
*** franred has quit IRC16:05
tiagogomesmeh, there are three projects named snappy, a compressor/decompressor, a video player and Ubuntu's snappy16:06
KinnisonIt's okay, the last one isn't very16:07
Kinnison(snappy that is)16:07
jmacsI think there are about 100 software projects called Rosetta16:07
KinnisonAnd very few of them are interoperable16:07
persiaLet's avoid making fun of other projects.  Remember, this channel is logged, and the logs are gaining google-fu16:25
paulsher1ooddoes anyone have any opinions about me proposing that we lorry ybd ?16:26
paulsher1oodas upstream, i confirm that if ybd starts being lorried, there will be no further push -f incidents (on my watch)16:27
ssam2with the goal of adding it to the 'build' systems ?16:27
paulsher1oodssam2: that's one possibility - i hadn't got that far, tbh16:28
paulsher1oodif folks would like to add it i'd be very happy :)16:28
ssam2ok. I'm not sure what the point of us lorrying it would be otherwise. but it's small so I'm not against lorrying it now16:28
paulsher1oodwell, i'm expecting to start explaining to folks how to use ybd to build baserock systems soonish... it would seem strange if it wasn't on g.b.o16:29
persiaGiven how core the functionality in ybd is to Baserock, I wonder if we ought just fork it, rather than lorrying it.16:29
persiaIf the current maintainers are willing, I suspect we can grant them appropriate permissions in our gerrit.16:30
paulsher1oodif we were adding it to build-systems, there'd be a need for a for example16:30
* persia would rather have two build systems in Baserock than to have an external build system being lorried16:30
ssam2it would be weird to me if ybd became a core part of Baserock to have it maintained with Github's tools instead of ours16:31
paulsher1oodinteresting point, but this needs more clarification16:31
paulsher1oodso first i'm gonna stick with build-system => autotools, cmake etc16:31
paulsher1oodmorph and ybd are both integration tools imo16:32
paulsher1oodssam2: re your point... how do you define 'core part of baserock' ?16:32
persiaThen I want two *integration tools* in Baserock, rather than anyone recommending using some random github software as a means to build Baserock systems.16:32
ssam2paulsher1ood: something where we'd be screwed without it16:33
paulsher1oodssam2: great definition :)16:33
paulsher1oodok, so my problem with gerrit is the friction. i wouldn't want to limit adoption of ybd by hiding it on gbo with changes via gerrit16:34
paulsher1oodpersia: any ideas how to deal with that?16:34
persiaWhat friction?16:35
persiaSomeone reviews, someone else reviews and presses the merge button.16:35
paulsher1oodin practice it seems harder than that16:35
persiaI'm not comfortable with a tool being advocated as useful for Baserock that doesn't have two reviewers.16:35
persiaHow so?16:36
* persia is fairly confident of the workflow16:36
paulsher1oodi expect you are. i'm not.16:36
persiaSome people have drunk the git-flow Kool-Aid, and as a result have issues because gerrit hates merge commits, but since I hate merge commits, I consider the problem to be with the people, not the tool.16:36
paulsher1oodso i'm interested in your forking idea... how would that work?16:36
persiaWe'd fork ybd into gerrit.16:36
persiaAnd ideally upstream would welcome this, so we could all work in gerrit collaboratively.16:37
paulsher1oodand continue to pull from ybd upstream from time to time?16:37
persiaIdeally not: it makes history ugly and causes race conditions.16:37
paulsher1oodybd upstream would welcome collaboration, to be sure16:37
persiaWould upstream be willing to abandon github?16:38
paulsher1oodi confess i'm not 100% settled on github either, but progress has been much faster for me there than on gerrit16:38
paulsher1oodi'd have to think about it... the friction is real. lots more folks are comfortable using github, than gerrit16:39
paulsher1oodthe workflow is easier, but doesn't scale16:40
persiagerrit scales :)16:40
*** jonathanmaw has quit IRC16:40
persiaBut seriously, I'd like to understand this "friction".  In practice, it really seems to be two reviews, and a button push.16:40
paulsher1oodyup. but workflow is harder and ui is not to my taste16:40
persiaAlmost nobody seriously uses the gerrit web UI: it's horrid.  THere are much better tools.16:41
persiaMost of the useful better tools are already in Baserock development systems.16:41
paulsher1oodfriction to adoption, for example - github publishes the readme and other stuff, making it trivial to fork or clone and go16:41
persiagerrit publishes the metadata, making it trivial to clone.16:42
persiaFor most of our projects, we mirror gerrit in gitano, so we have nice g.b.o URLs also.16:42
paulsher1oodi don't like that any *total n00b* would have to figure out anything regardign gerrit if ybd went that way16:42
persiaThen I'm not sure how Baserock could ever consider ybd a component.16:42
persiaUnless Baserock were to decide to move to github, but we had that conversation over a fairly long period about a year ago, and decided on the current model.16:43
paulsher1oodwell, it can consider it like it considers all other upstreams :)16:43
paulsher1oodi'm suggesting delta/ybd not baserock/baserock/ybd16:44
persiayes, but it wouldn't be interesting to collaborate on it, nor include it in any refernece systems, since all meaningful integration system development would have to be in morph, which we know to be reviewed.16:44
*** ssam2 has quit IRC16:44
persiaThere are some really cool ideas in ybd, and I think some of them may cause discussion over the right integration tool.16:44
persiaBut if we have to rely on a third-party source, I don't imagine most of us would find that very exciting.16:45
persiaMostly because of the duplication of work involved in ensuring that our primary tool continues to work.16:45
paulsher1oodi find your perspectivde there surprising. there are many other delta/* things in reference systems16:45
persiaYes, but none of them are core to Baserock.16:45
persia(using ssam2's definition above)16:46
paulsher1oodreally? linux, make, autotools?16:46
persiaWe could use BSD, alternate make implementations, and forgo all of GNU (the major autotools consumer) if we liked.16:46
persiaDoesn't change the core story about reliability, maintainability, etc.16:46
paulsher1oodsame goes for morph and ybd, persia :)16:47
persiaExcept that without morph, we have no build too.16:47
persiaIf we use an external build tool, what is the point of having a separate project?16:47
paulsher1oodybd builds what morph builds :)16:47
persiaIt's a question of identity.16:47
persiaYes, which makes it redundant.16:47
persiaIf ybd is to be considered as a peer (or replacement) for morph, then it is interesting, if the project can control it.16:47
paulsher1oodother outcomes are possible :)16:47
persiaIf it's a third-party tool, then it is hard to depend on it for the core functionality of what Baserock does.16:48
paulsher1oodi disagree, simply because there are so many things that are already depended on, that the project cannot control16:48
persiaOK.  Since my opinion is mostly about the opinion of others, I encourage you to find a way to demonstrate me incorrect :)16:49
paulsher1oodi would say that baserock is not about control, anyway. it's about demonstrating working solutions16:50
persiaWhile I agree, I would say that community identity is about being able to use consensus tooling to achieve goals by modifying software.  Software not part of a project tends to get lower attention or local patches, and differing workflows confuse and irritate.16:51
*** bashrc has quit IRC16:53
paulsher1oodi'd like consensus, for sure. in this i think there's still some way to go, for ybd. but i don't see why it can't be considered useful, and thus lorried alongside (for example) screen, nano, bc etc.16:55
paulsher1ood(althoug obviously thosre projects have longer history and are more popular)16:55
paulsher1oodi should maybe just compare it to some of the more exotic python modules :)16:57
persiaIt isn't about whether it is useful, it is about whether it is a useful target for collaborative development to progress the Baserock project.16:58
jjardonpaulsher1ood: my opinion: lorry it, keep development in github. We will discuss what happen next if it became a core component of baserock16:58
persiaAnd whether it is worth the friction of using a third-party upstream for such a core component.16:58
paulsher1oodpersia: do you accept jjardon's reasoning above?16:58
persiaI don't believe the conversation about it being a core component of Baserock becomes interesting until/unless the issues with hosting it inside the Baserock project are resolved.16:59
* paulsher1ood will send a lorry file, see if it gets approved :)16:59
jjardonpeople has to use/try it before decide, and it makes easier to use it if its lorried and added in some of our reference systems17:01
paulsher1oodthat would be my preference, but persia has clearly raised some counter-arguments17:02
persiaWell, without a I disagree with that from the start, but if it was usefully installable, I could see that argument.17:02
persiaI still don't think it is interesting to discuss whether it makes sense to use ybd in preference to morph as long as ybd upstream wants to be a separate project.17:02
paulsher1oodpersia: i agree with you on that. i was hoping to postpone that discussion until ybd is a little more 'mature'17:03
paulsher1ood(for example, by establishing that upstream doesn't force push any more)17:03
jjardonpersia: agree with that17:04
persiaNote that we can't unlorry anything, by policy, so if we ever wish to adopt ybd as something other than delta, we'd end up with two ybd repos on g.b.o17:04
*** mariaderidder has quit IRC17:04
jjardonthey are in different namespaces, so dont think it would be a problem? I can be wrong though17:05
paulsher1oodpersia: noted. somewhere along the line i started wondering whether there's any real reason for having baserock/baserock/* as a special case at g.b.o ?17:05
paulsher1oodie morph, definitions, lorry controller etc are projects, same as all the delta stuff (from the point of view of what gbo is mostly doing)17:07
rdalei feel we discuss way too much important stuff on irc, rather than the mailing list17:07
paulsher1oodrdale: fair point.17:07
paulsher1oodi'll write this up and get a mail out17:07
rdalethat's a good idea, otherwise we'll keep repeating the same arguments17:08
* persia doesn't like mailing lists much17:08
persiapaulsher1ood: I never understood the point of those namespaces: they predate my involvement in Baserock, and were never to my taste.17:09
persiaBut I think changing them would be conceptually expensive, break all the reference systems, and annoy all users.17:10
jjardonpaulsher1ood: not really. delta/ repos are sumply mirrors, where /baserock/baserock are upstream projects developed by the baserock project17:10
paulsher1oodjjardon: yes, understood. i wondered if the upstream development should be separate from the mirrorign, is all17:12
paulsher1oodbut persia is probably correct that it would cause too much pain17:12
persiaInterestingly, one of the proposed methods to resolve the various feature requests that cause us to have both gerrit and gitano was to have gerrit be upstream for the Baserock projects, and then lorry them into gitano as we lorry anything else.17:13
persiaBut there's the legacy stuff that got in the way of implementing it that way.17:13
jjardonyes, I though that was the plan at some point17:17
paulsher1oodjjardon: did you see my suggestion about settling on /src instead of /home/build by default?17:18
persiajjardon: If you know a way around the legacy pain that requires us to change all the definitions in sync with the git server changes, and somehow propagate this to all downstream troves, and all users, then I think many of us would like to move in that direction.17:19
*** gary_perkins has quit IRC17:28
*** tiagogomes has quit IRC17:35
jjardonpaulsher1ood: yes, sorry I didnt have  time to rework the patch this week17:48
jjardonbut the whole point of the patch was to not use /src17:48
jjardonso ybd will work in any machine without any tweak17:49
* persia prefers the lack of reliance on /src: it always felt wrong17:49
persiaPersonally, I would prefer no hardcoded paths, with a default to /var/cache/ybd/ in /etc/defaults/ybd, but that doesn't work as well for systems that aren't FHS-compliant.17:50
*** lachlanmackenzie has quit IRC17:57
paulsher1oodso the 'reliance on /src' is because that's the baserock default. if ybd defaults to something else, it will re-clone loads of git repos that may be already on the user's dev machine18:33
persiaYou mean because it is the morph default?18:34
persiaExcept it isn't: it's only the config value that the wiki recommends folk put in their morph.conf18:34
persiaybd should similarly default to FHS compliance, and allow the user to specify an alternate location, if they wish.18:35
paulsher1oodright. but for folks who follow the instruction,s that's where they have their stuff18:35
persiaRIght, so for folk who follow the instructions, that ought include a ybd.conf18:35
persiaI prefer /etc/defaults/ybd, but that may just be me.18:35
paulsher1oodybd allows the user to specify - it's called ybd.def though18:35
persiaThen we're all set, except that it breaks by default for new users who didn't read the docs and didn't transition from having read the morph docs, which is undesired behaviour.18:36
paulsher1oodwould ybd.conf be better than ybd.def, for some reason?18:36
persiaMore familiar name,  Leaves the .def namespace more clearly open for definitions18:36
persiaUnless we gave up on the idea of transitioning foo.morph into foo.def at some point.18:36
paulsher1oodthat's still on my list :)18:37
persiaIn that case, I think you really don't want ybd.def.18:37
paulsher1oodso - user  /src if /src already contains /src/cache/gits, else use what's in ybd.conf?18:38
persiaUse /var/cache/ybd/ unless there is somethig in ybd.conf18:38
persiaBecause it really belongs in /var/cache/ybd18:38
persia(or /var/cache/morph)18:38
paulsher1oodeven though user has already cached s88loads in /src/cache/gits?18:39
persiaThe /src/ thing is only because people were runing the tool in qemu-managed VMs, and wanted to have a separate volume for their sources which was reused over several iterations of /18:39
paulsher1oodyup. and i have that use-case, still18:39
persiaWe have no idea whether a pathname "/src/cache/gits/" happens to be compliant with our expectation.18:39
persiaUsers who have such a cache should use it, by configuring the tool18:40
persiaAnd users who have that use case should configure the tool to support the use case.18:40
paulsher1oodthat means more *instructions*, so less easy to just download and go18:40
persiaWhereas, if not otherwise specified, application-specific caches belong in a namespaced subdirectory of /var/cache on linux systems.18:40
persiaFor your specific use case, yes.  For my use case, it makes it easier to use.18:41
* persia wants to run the integration tool on a development laptop without needing to repartition the disk, or add special slow USB drives as additional volumes18:41
paulsher1oodi'll put detection in, so we both get what we want. i think that's possible18:41
persiaI want configuration and default to FHS-complaince.18:41
persiaI'm not sure how I can get what I want with detection.18:41
paulsher1oodwill you have a pre-ecisting /src/cache/gits directory, yet expressly not want to use it?18:42
persiaQuite possibly.18:44
persiaPerhaps I have a backup of a volume that was on a VM I was using for development that I've mounted on my laptop for extracting something.18:45
paulsher1oodwell, i'm sure you'll figure it out :)18:45
persiaHaving that suddently try to update a loopback volume in a backup file rather than using my more recent cache would be annoying.18:45
persiayes, but it shouldn7t be the folk who want to have FHS-complaint systems that have to figure it out.  It ought be the folk that are different because they have specialised use cases.18:46
persiaI'm not saying the specialised use case should be hard to support: I just don't think making ybd less compliant than morph is a sensible feature to add.18:46
paulsher1oodtrouble is jjardon's  proposed solutions is neither FHS nor /src iiuc18:46
persiaThat's only a problem because the way github works, we can't update it without waiting for him.18:47
persiaRight, it's a pull request.  Only folk with access to the original source can update the candidate commits to be landed to ybd.18:48
paulsher1oodi mean he is proposing a differnt default from you and from /src18:48
paulsher1oodi can update the candidate commits, i'm pretty sure18:48
paulsher1oodi just don't know what to update *to*18:49
paulsher1oodseems you and he want different things18:49
persiaHave we solved the problem that it has to be run as root?18:49
persiaIf we have, his solution is better.18:50
persiaIf we haven't, his solution breaks user control over the user's home directory.18:50
paulsher1oodnope. i've been told 'it's a couple of weeks work'18:50
persiaI'll mitigate my comment then, but I do not think it would be good to merge the current candidate before that lands, or at least, I would never want to use it in default mode in a system with non-root users.18:51
persiaAnyway, this is a perfect example of what I consider friction with github.18:56
*** edcragg has quit IRC18:57
persiaThere is no obvious way for me to pull jjardon's change into my local ybd repo in a new branch, edit the commit to do what I want, and publish it back into the ongoing conversation into which his commit was posted.18:57
paulsher1oodgit add remote, git fetch etch?18:58
persiaAnd push where?18:58
paulsher1oodto your own fork?18:58
persiaAnd open a new pull request, for a new conversation?18:58
persiaWhat I want is to land my candidate commit in the *same* conversation, so we can discuss relative merits in one threaded discussion.18:59
persia(which gerrit supports)18:59
paulsher1oodunderstood. could you try it, please? and then add your sha to the existing issues conversation?18:59
* paulsher1ood hasn't tried this, is interested19:00
persiaTry what how?19:00
paulsher1oodmake a fork of jjardon's fork, amend, then cut and paste your new sha1 into a reply in the existing issue thread19:01
paulsher1oodgithub seems to magically make links for shas, i wonder if it will handle this19:01
* persia struggles to find a fetch URL from the pull request discussion19:03
* persia was hoping for easy copy&paste instructions like `git fetch refs/changes/06/906/1 && git cherry-pick FETCH_HEAD`19:06
* paulsher1ood was hoping for whirled peas19:06
persiagrumble.  I can't `git fetch xdg_dirs` directly.  I have to add a remote.19:08
paulsher1oodmaybe this is not worth your time. i agree gh is not perfect, nor is gerrit19:08
persiaThis means a new remote for every developer whose changes I want to review locally.19:08
persiaI don't understand how anyone can accept this UI.19:08
paulsher1oodit doesn't 'scale', that's for sure :)19:09
persiaPerhaps.  I don't use github except as a write-only store, so I'm digging through `git help remote` to try to figure out the next step.19:09
persiaStopping seems very pleasing.19:09
paulsher1oodgit remote add jjardon
paulsher1oodgit fetch jjardon19:09
paulsher1oodstop, then, do more fun things, like whirled peas19:10
persiaHeh, OK.19:11
* paulsher1ood suddenly realises he should have saved his purple shirt for today's meetings :/19:11
persiaWith your commands, I was able to get it, but only by digging through the output of `git branch -r`, which I imagine gets ugly fast for more than a few developers.19:11
persiaHrm.  For github, do I have to do something to authorise a push?19:31
*** edcragg has joined #baserock20:48
*** dabukalam_ is now known as dabukalam21:38
*** dabukalam has joined #baserock21:39
*** edcragg has quit IRC22:04
paulsher1oodare you around? could you send me the spec?22:11
paulsher1oodreq spec that was shown to mips licensees etc22:12
*** SotK has quit IRC22:59
*** SotK has joined #baserock22:59
*** edcragg has joined #baserock23:04
*** edcragg has quit IRC23:46

Generated by 2.15.3 by Marius Gedminas - find it at!