IRC logs for #baserock for Thursday, 2015-04-09

*** zoli__ has joined #baserock06:31
*** Albert has joined #baserock06:41
*** Albert has quit IRC06:52
*** Albert has joined #baserock06:56
*** Albert has joined #baserock06:57
*** Albert has quit IRC07:08
*** a1exhughe5 has joined #baserock07:54
*** gary_perkins has joined #baserock08:01
*** ssam2 has joined #baserock08:47
*** ChanServ sets mode: +v ssam208:47
*** edcragg has joined #baserock08:53
*** franred has joined #baserock08:59
*** marcdunford has joined #baserock09:05
*** mdunford has quit IRC09:05
*** flatmush has joined #baserock09:06
*** wschaller has joined #baserock09:13
*** SotK has joined #baserock09:13
*** Krin has quit IRC09:19
*** Krin has joined #baserock09:19
*** richard_maw has quit IRC09:22
*** richard_maw has joined #baserock09:28
*** ChanServ sets mode: +v richard_maw09:28
ssam2tlsa: about the `morph generate-manifest` command: i'm not sure if it's better to generate a manifest from the system image or the source repos09:36
ssam2I guess you need the source repos either way09:36
ssam2so it may as well just be generated from the source09:36
ssam2and that reinforces the idea that builds are not valuable09:36
ssam2i'm not sure if anyone uses the existing `morph generate-manifest` command: only the GENIVI releases ever used it09:37
ssam2from looks like it is still part of the GENIVI Release process09:37
tlsaprobably shouldn't modify it, if its designed for a specific purpose?09:38
ssam2if it's designed for a specific purpose, rename it to `generate-genivi-manifest`09:38
ssam2then we can add a `generate-csv-manifest` command, perhaps09:39
ssam2when I've done those releases I've thought that those commands were definitely in need of improvement. But I don't think we have time to rewrite them now09:40
ssam2'those commands' being  'morph generate-manifest'  and 'scripts/'09:41
ssam2if we have a new command that outputs all the info as CSV, it shouldn't be too hard to later write a script that generates suitably formatted output for GENIVI based on that, though09:41
tlsayeah, or just provide multiple output formatting options in one command09:42
ssam2the GENIVI manifest output is this by the way: and
tlsathe patch for license checking in gerrit only checked the COPYING and LICENSE files at the root of the repo09:44
ssam2right. that'd be misleading, then09:44
tlsaso only one license per chunk09:45
ssam2most chunks have files which have more than one license, as you can see from the GENIVI example09:45
ssam2or rather, each file has one license, but they aren't all the same one09:45
ssam2so I think we have to list all of the ones that are found09:46
tlsabut they should all be compatible with the project license09:46
tlsawhich would be in COPYING09:46
ssam2I don't have expertise to know whether that's true or not, so I'd prefer to hedge our bets and include them all09:47
ssam2doesn't need to be nicely formatted, I just don't want to pretend that the license checking is smart, when it is actually just 'grep'09:48
tlsaabout adding to morph, where should it get installed?09:50
tlsa/usr/bin/ or something?09:51
ssam2it could go in the Python module, you can set to install extra files09:51
ssam2so it'd live in /usr/lib/python/site-packages/morphlib/09:52
ssam2at  least then it can't interfere with anything else09:52
*** Albert has joined #baserock10:02
*** Albert has quit IRC10:24
*** Albert has joined #baserock10:25
ratmice__an example of things containing incompatibly licensed stuff is GPLv2 code with GFDL documentation10:30
ZaraHi, I'm trying to lorry in some packages listed in the recipes here:10:38
Zarabut the source is in the same repo as the recipes.10:38
Zara(eg: -- the recipe is the .bb, the source is in 'files')10:38
ZaraI'm wondering what the best approach is.10:38
perryli'm currently trying to fix up final (hopefully) changes to my distbuild-list-jobs branch; approximately how much depth should i go into wrt reformatting the request message output so it's more readable?10:50
ssam2zara: can you just lorry the whole repo ?10:50
ssam2perryl: i'm not really sure, I think this is first command in Morph to need to output a table of information10:52
ssam2I think the way I would approach this is: don't format the message in the controller10:53
ssam2send all the information back as a blob of JSON, and do the formatting in the client/initiator10:53
ssam2to be honest, the current implementation is good enough, I'd be OK to see that done as a separate patch10:54
ssam2I also agree with richard that we kind of overloaded the word 'jobs'... didn't really think of it before10:55
ssam2but 'distbuild-list-build-requests' is quite a mouthful10:55
ssam2might be OK just adding a comment that the word 'job' has another meaning inside the distbuild code10:55
perryli have changed some of the output wording to be more intuitive to what it is, and modified "for job in jobs" to "for build in requests"10:55
perrylbut yes, it is a case of how far down do i go to change the names10:56
ssam2while we're here... it seems like the current version on Gerrit will still list the wrong initiator10:58
ssam2is that fixed in your next version?10:58
perryli don't believe so; i have no way of finding currently the correct initiator. i will try to test on a named distbuild network rather than using the distbuild test harness as the amount of different port values are incredibly confusing10:59
ssam2yeah, makes sense10:59
ssam2It needs to print job.initiator_connection.initiator_name instead of self.initiator_name, basically11:00
Zarassam2: ha, I think that would work. :) there are two potential issues I see: 1. I might have to check a lot of licenses first. 2. I'm worried might cause problems further down the line (if, say, we want to make one chunk per each component).11:02
Zara*it might *one chunk per component11:02
Zaraer, just pretend I wrote a sentence that made sense :)11:02
ssam2zara: lorry can't really mirror part of a repo, so I think that's the only simple option11:05
ssam2licenses are only a concern when distributing binaries. I don't think there are many open source licenses around which stop you redistributing source code11:05
ssam2you can have more than one chunk built from the same git repo11:06
Zaraokay, that seems like the most straightforward way of doing it. (hehe, I got a bit concerned by the 'copyright facebook all rights reserved' stuff all over the place; in some files they also say it's free software, but it varies)11:15
persiaThat's a bug, and worth reporting upstream.11:17
Zara(eg: vs )11:17
persiaIt can only be fixed by facebook, but they ought be able to fix it.11:17
persiaAs I understand it, "All rights reserved" ceased to have legal meaning when Nicaragua signed the Berne Convention, but I may be mistaken.11:18
Zarafrom what I could tell, the recipes are just 'all rights reserved', while the .c, .h, .sh (and so on) files have the full licence11:19
Zaraso I wasn't sure if it was meant to be that way or not11:19
* Zara doesn't know much about licensing law11:19
nowsterpersia: why Nicaragua?11:20
persianowster: I believe they were the last signatory of the Buenos Aires Convention that became a signatory of the Berne Convention11:21
jjardonI agree with persia that that seems a bug, you cannot have ALL the rights and be GPL at the same time11:22
ZaraOkay. What about the .bb files, where there's *just* "Copyright 2014-present Facebook. All Rights Reserved."? Should these also have the full licensing information?11:30
persiaZara: They do.  That is full licensing information.11:30
persiaBUt that means you can't distribute them, either verbatim or modified.11:31
persiaSo you want *different* licensing on those files.11:31
Zarayeah, sorry, that's what I was getting at11:31
persiaYou have to ask Facebook.11:31
pedroalvarezhehe, sounds easy11:31
persiaIn previous licensing discussions, I've had best success in reviewing an entire repo, and then sending a report to the copyright holders with a patch that would fix it the way I wanted.11:31
persiaThe key is to be *very* clear that you are not asking upstream to apply the patch, but are asking *Facebook* to apply the patch.11:32
persiaAnd to have *different* patches if you need to clean up after multiple copyright holders.11:32
perrylssam2: good catch on the traceback, i'd forgot to change len(jobs) to len(requests), i've pushed the change11:33
persiaUsing `git blame` can help here, because you can get the email addresses of the people who asserted the copyright in the first place, so you know who to email.11:33
Zarawell, today has turned out to be more exciting than expected. :)11:34
jjardonunfortunately seems there is only 1 commit in openbmc repo11:37
persiaExcellent.  That makes the conversaion very easy.11:38
persiaBecause it is the person who published it in public that is the right contact to fix the issues, and there are no other parties with an interest in preserving the current code.11:39
* persia remembers a long-standing problem with a project that was open-source for ~5 years before anyone noticed that it had conflicting licensing requirements. The conflicts were never resolved, because some of the core maintainers asserted that one could have "GPLv2 or later" and "non-commercial use only", so everyone who cared about licensing left, and no distros carry the software.11:40
*** wschaller has quit IRC11:44
ratmice__dual licensed chunks seem like a PITA, because there is not only the licenses some chunk is available under, but the licenses which the licensee has12:00
ZaraOkay, I think the things that need changing are in recipes-wedge (the other stuff has no explicit licensing). I'm not sure how to send a patch, since that would seem to require copying their source and uploading the patched version somewhere, which might contravene the licence as it currently stands.12:06
*** jonathanmaw has quit IRC12:08
*** jonathanmaw has joined #baserock12:08
*** jonathanmaw has quit IRC12:11
persiaZara: `git diff` is your friend.  Also, don't use github pull requests for this: email the patch as part of the license change request.12:14
Zaraso, I'd want to remove anything that says 'all rights reserved', and, for places where I'm requesting different licensing, I'd need to add in the GNU licence paragraphs that they're already using in other files in the repo?12:34
*** wschaller has joined #baserock12:40
persiaI don't have enough context to give full advice, but you'd want to suggest they add the relevant preambles for whichever license applies to all licensed content.  For GPL files, that is the few paragraphs described in the "Using the GPL" section of the GPL.12:42
persiaAs long as you are cleaning up licensing, it is best practice to check the address used for the FSF in any GPL licensed code, as it changed a number of years ago, but some people's templates remain unchanged, and there is still code with the old address in the license.12:43
Zarait's odd; all their makefiles and recipes are just copyright facebook, while other program files are GPL.12:54
Zaramaybe they thought the former didn't need it?12:54
persiaOr maybe they are only releasing the code as GPL, and not the recipes.12:58
richard_mawperhaps they don't think that the build instructions contribute towards the derived work, just the code12:59
ZaraI can't see a good reason why they'd license it differently on purpose, while putting it all in a public repo and encouraging pull requests (though there might be something I just don't know about). there's the odd bit of code that doesn't have the GPL, either. I don't think they meant to license it differently, but I guess we'll find out.13:03
persiaI've heard rumours of cases where the build system was specifically not considered to be part of a derived work, which could be precedent, but I don't know that the folk posting the code were operating under the advice of counsel.13:05
persiaAnyway, best thing is to ask the person who did the commit.  They either know, or know who to ask.13:05
paulsherwoodybd-specific help request please... could anyone give me a clue as to why subversion install might fail, after build has succeeded?
nowster....cannot find -lsvn_delta-113:17
nowstercollect2: error: ld returned 1 exit status13:17
paulsherwoodnowster: any idea what that means, though?13:18
nowstereither the linker's built in path is wrong, or that library hasn't been put in the right place for the linker to find it13:19
nowster...or ld is looking for stuff in $DESTDIR/usr/lib/13:20
nowsterit smells very much like a buggy script that only half understands DESTDIR13:22
paulsherwoodnowster: ok, thanks for the clues13:22
nowsterOR... one part of the configure knows about DESTDIR and the other needs telling about it. Perhaps a missing option?13:23
paulsherwoodwell this works in morph, so it's intriguing :)13:24
Zarapersia: ah, they do indeed have different addresses in some of the code. Thanks for the tip. :)13:25
Zarawell, not in the *code*, but you know what I mean :P13:25
nowstera bad case of COPYING ? ;-)13:26
Zaranowster: there is COPYING everywhere, yup13:26
persianowster: Precisely.  copying outdated COPYING13:27
*** marcdunford has quit IRC13:45
*** zoli__ has quit IRC13:50
*** jonathanmaw has joined #baserock13:54
*** marcdunford has joined #baserock13:59
perrylssam2: regarding your comment on patch 136, i agree, that formatting looks a lot better; would that still be better as a separate patch?14:01
ssam2up to you14:01
ssam2do another version of 136 if it makes sense I think14:01
perryli think it may be better as a separate patch if only because i've got a few other tasks to focus on right now14:02
ssam2fair enough14:02
jjardonssam2: Maybe of interest: Can we enable/install the reviewnotes in gerrit: it will annotate who +1/+2 the commits in a git note:
ssam2that sounds useful14:21
ssam2yeah, I'll look at it tomorrow14:21
tiagogomes_can someone remind me what is the process when I need to have a delta against upstream? Create a baserock/morph branch?14:27
richard_mawtiagogomes_: pretty much, though we also like baserock/$VERSION_NAME branches these days14:28
richard_mawand it's more descriptive, since we don't have the morphology in the branch any more14:29
richard_mawif we _can_ just keep the delta to the morphology file it makes it a lot easier to forward-port though14:30
tiagogomes_richard_maw, I like that, because if in the future if there is a new version that requires a delta again, I don't need to force push to baserock/morph, or merge the new version on baserock/morph14:30
*** zoli__ has joined #baserock14:32
tiagogomes_should we be able to reference patches on the morphology?14:32
tiagogomes_chunk: foo14:32
tiagogomes_- patches/fix-this-bug.patch14:32
tiagogomes_there are patches on the Internet that for some reason they don't get merged upstream, causing us to have to create a branch with the delta14:33
tiagogomes_maybe supporting applying patches would be better, as long as doen't hinder reproducibility14:34
paulsherwoodtiagogomes_: -1 from me14:34
ssam2seems like the problem only happens for dead projects14:34
paulsherwoodwe can and should have a git repo of the project, and a branch wih that patch in it14:34
ssam2if the project is dead, having a delta against upstream isn't really an issue14:34
franredI also prefer to have the delta (branch) so we deal with the patches and it get reflected in a repository14:35
persiaIf a project is dead, and we need it, we should find others that need it, and collaborate on a new upstream.14:39
persiaIf a project is living, but annoyingly slow to accept patches (some active projects that everyone uses only do new releases every couple years and don't expose VCS, only tarballs), we can probably similarly find collaborators for an unofficial external patchset.14:40
persiaIf the Baserock project needs something *now*, having a patch in a delta repo doesn't seem bad to me, as long as we have submitted that upstream and put info indicating where to check on upstream status in the delta commit comment.14:41
persiaIf some Baserock user has a project that needs something *now*, they should carry the patch in their own trove.14:42
jjardonthe fact that you need a trove to put a simple patch in a module is a bit stop over for new contributors14:44
paulsherwoodjjardon: you don't... use github?14:45
paulsherwoodor whatever git tooling yo already have/14:45
jjardonpaulsherwood: ok, use case: "oh, I need a patch for this component" -> create a new repo in github -> clone upstream repo there -> clone repo locally to make changes -> make the patch in a branch, push -> change your definitions to point to the new repo/branch14:48
jjardonIf you think about it is even more annoying because maybe you already download the repo previously to build it14:49
jjardonFor reference, in jhbuild: go to your local git repo -> make the patch in a branch -> change your definitions to point to the new repo/branch14:50
pedroalvarezjjardon: now imagine that the build fails.14:51
pedroalvarezand you want to debug what is going on in another computer14:52
ssam2jjardon: jhbuild doesn't support distributing builds, which makes it a lot simpler14:52
jjardonpedroalvarez: add "git push" to the previous14:53
paulsherwoodjjardon: ok, but then how do you share your work?14:54
jjardonssam2: fair enough, but I do not think as a casual user I need distributed builds?14:55
jjardonpaulsherwood: if I need to share I push my changes14:55
ssam2jjardon: indeed, but it adds a lot of constraints to what Morph can do14:56
paulsherwoodjjardon: yup. sorry i may be missing your point here, i'm multi-tasking14:56
jjardonssam2: sure; I only wanted to point that maybe the current workflow for this specific task is not ideal and It can be improved. Maybe telling morph to use the local repo instead trying to pull a new one? Not sure if this is possible/will break things though15:02
gary_perkinsHi, is it possible to give someone write permissions for a repo that doesn't follow the <trove-id>/<project-name>/<repo> naming scheme?15:02
gary_perkinsin particular "delta/ruby-gems/thor"15:03
paulsherwoodgary_perkins: on, or in general on a trove?15:04
gary_perkinsin general on a trove15:04
franredjjardon, if you want to run local changes you can always have your local repository, and point your build to it...for patches to share I think they should be in the repos and also for making the patch you need to clone de repository in any case (no if you are going to apply it...but in general you want to see if apply nicely before use it in any case, though)15:05
gary_perkinsFrom the docs I've seen so far, the permission groups require a particular naming scheme15:05
straycateveryone needs distributed builds15:06
jjardonfranred: thats exactly my point: in jhbuild is already cloned locally, so its as simply to go to the local repo and make the modification. In morph we clone it locally to build, but we have to clone it again separately to do the patch15:08
franredjjardon, we clone it separately to "share" the patch15:09
* SotK doesn't think that we should support messing around with the repositories in the local repo cache15:09
SotKif that is what this idea is suggesting15:11
jjardonfranred: mmm, not sure; to make the patch, no matter if I'm going to share or not, I need to clone the repo separately15:11
jjardonfranred: or am I missing something?15:11
ssam2gary_perkins: I think this file is the key:
gary_perkinsssam2: Great thanks, I'll have a look :)15:12
ssam2this suggests that anyone with an account on that Trove should be able to push to delta/15:12
ssam2but only to branches named $trove_id/xxx15:12
ssam2if that's not working, I have no idea how to debug it15:12
franredjjardon, why? you can clone, pointed to your local repo, tested and then push it, replacing repo: file:///foo.git by repo: upstream:foo - you ref and unpetrify ref shouldn't change15:13
ratmice__I don't see much point in including patches in the morphology rather than the applying it on top of the upstream repo, you'll need to either branch the morph or branch the upstream, because patches are unlikely to work for any variation of the repo they must be then kept in sync15:16
* ratmice__ points at gentoo15:19
jjardonfranred:  "why? you can clone, pointed to your local ..." <- you are saying it: I need to clone again, you can not reuse the clone morph probably did previously to build the chunk15:20
SotKjjardon: you mean the clone into the local repo cache?15:21
jjardonSotK: yes15:23
*** zoli__ has quit IRC15:24
franredjjardon, I won't mess up with that.... but it is a git repo, I imagine you can use it and point to it as file:// too ?15:25
SotKyou probably can, except we clone them with --mirror I believe15:25
* SotK also wouldn't mess with his cached repos if he expected his build to work15:26
jjardonfranred: no, because it can be deleted at any point. It can be used as a quick hack but I wouldnt recommend it as the official "workflow"15:26
franredjjardon, agreed with I wouldn't recommend it as the official workflow - In any case, Im still don't see the hassle in cloning a repository, TBH15:29
tiagogomes_I still can't push to gerrit, it says that a pushed branch tip is behind its remote15:30
ssam2I never got to the bottom of why. It's weird that it only happens to you15:31
ssam2did you try passing --no-thin to `git push` ?15:31
ssam2that works around a bug caused by a change in the Git protocol, which Gerrit 2.9 doesn't know about15:31
gary_perkinsssam2: Thanks, that clears things up a bit. So the reason why rdale cannot push to delta/ruby-gems/thor is then probably the same reason why he doesn't have access to ct-trove/infrastructure/definitions, even though I've setup the permission groups and confirmed he is a member of 'infrastructure-writers'. That reason I've yet to find out. If anyone has any clues I'd be very much appreciate it :) In the meantime, I'll consult15:31
gary_perkinsthe logs...15:31
jjardonfranred: clone the linux linux and you will understand the hassle :)15:31
tiagogomes_ah ok, I need to specify the topic branch, I was only using refs/for/master15:32
franredjjardon, I did it I know that it takes a lot of time...but no all the repositories are as big as linux15:32
tiagogomes_but now it failed in another step15:32
richard_mawI just pushed for review, since when we updated our kernel, we stopped supporting ethernet in one of the machines I was using, because the driver stopped being in the defconfig15:33
tiagogomes_how do I add a change-id to an already existing commit?15:33
pedroalvareztiagogomes_: if it's only one, git commit --amend15:33
richard_mawtiagogomes_: if you have the hook installed, I usually do a git rebase -i and choose reword, but you can `git commit --amend` if it is the latest in your branch15:33
pedroalvarezthat answer is  much more complete :)15:34
tiagogomes_both useful, thanks15:35
tiagogomes_god dammit, it failed again, grrr15:35
jjardontiagogomes_: what the error now?15:35
tiagogomes_the fatal error is that I was being silly15:36
pedroalvarez" fatal: pbkac" ?15:37
tiagogomes_I just created the commits and already have a merge conflict15:38
tiagogomes_can I fix it through the web interface?15:38
jjardonrichard_maw: mmm, I do not see recent changes in the x86_64_defconfig:
pedroalvareztiagogomes_: I think that the merge conflict will be fixed once it's merged the firt patch15:40
tiagogomes_pedroalvarez I see15:41
jjardonrichard_maw: neither in
richard_mawjjardon: the weird thing is that E1000E is enabled in i386, but not x86_64, but it previously was enabled in both15:44
tiagogomes_how do I reply to a comment in gerrit?15:47
tiagogomes_very naive question, but I only see a reply button that adds another comment15:47
richard_mawI usually copy the text and prepend a > to it15:47
pedroalvareztiagogomes_: there is a button to do that, top right of the comment15:48
tiagogomes_¬_¬, so guerrit doesn't support replying to particular comments15:48
tiagogomes_pedroalvarez, ah, there is indeed, ta15:49
jjardonrichard_maw: mmm, for some reason it was not added in x86_64 when added in i386
jjardonrichard_maw: was it added after and then removed? let me investigate more15:49
tiagogomes_franred, can you reconsider your -1 as per comments15:49
richard_mawjjardon: IMO we shouldn't rely so much on the contents of defconfigs for things we need15:50
jjardonrichard_maw: sure, I was only curious about the regression: seems it never got enabled15:51
richard_mawcould it have been E1000E got split out of E1000?15:52
ratmice__jjardon: so is your problem with the upload time in pushing a patched kernel repo? (and the number of steps required to do so)?15:52
franredtiagogomes_, reconsidered ;-)15:52
jjardonratmice__: pulling, not pushing. And the steps as well, yes15:53
ratmice__ask, because isn't there some way we could avoid that (fork it button, add remote to existing clone, upload delta)?15:53
ssam2jjardon: you could clone from Morph's local repo cache (although that's not made easy right now)15:55
*** a1exhughe5 has quit IRC16:00
jjardonssam2: oh, didn't think about that. That would be probably faster, yes16:01
* SotK points out that this is exactly the thing he likes about `morph edit`16:02
* SotK hides16:02
pedroalvarezmorph edit does clone from the local repo cache?16:04
* SotK wonders what opinions would be on a command which does the checkout like morph edit but not any of the other magic16:08
ssam2i'd be in favour!16:09
pedroalvarezI always try to thing about these new feature in a world without workspaces16:09
jjardonSotK: seems "morph edit" its an improvement, thanks!16:09
jjardonSotK: what other magic? ah, the change in the ref in definitions?16:10
SotK`morph get-repo CHUNK [PATH]` to checkout CHUNK into PATH (which can default to the place it would be if morph edit was used)16:11
SotKjjardon: yeah, the change of ref and unpetrify ref, plus the weird stuff it does to use the local repo in a build16:12
jjardonSotK: yeah the last thing is the only one I really dont like16:12
jjardonSotK: +1 for the get-repo idea btw: at least for me it will be useful16:13
franredfix ebtables binary path in libvirt:
ratmice__I'd find it useful as well (except in my case where the upstream repo is imported from tarball, and i track the repo)16:16
pedroalvarezfranred: oh, was that causing problems?16:16
franredpedroalvarez, it fails when libvirt try to use it - not sure if it causes problems but better to fix it16:17
paulsherwoodratmice__: is that a case where gbo doesn't have the upstream?16:17
richard_mawfranred: it's not a problem for us, since OpenStack does its own firewall setup16:17
paulsherwoods/firewall setup/everything/16:18
richard_mawheh, pretty much16:18
franredrichard_maw, yeah, but OpenStack also requires ebtables for some kind of magic...16:18
richard_mawfranred: yes, but it isn't deterred by it not being in the path that libvirt expected16:18
ratmice__paulsherwood: gcc-tarball.git16:19
franredrichard_maw, true16:19
jjardonIf you have some time, can anyone take a look to
pedroalvarezfranred: but if this is fixing things, why not?16:19
paulsherwoodratmice__: ah, i see.16:20
paulsherwoodcan anyone remember why we don't have gcc in gbo?16:20
ratmice__cause it's absurdly large16:21
jjardonpaulsherwood: last time I asked it failed to clone16:21
paulsherwoodfrom git? git://
richard_mawwe have gcc-tarball because the gcc repository is massive, partly because its standard practise is the pathological worst case16:21
richard_mawfor git's packing algorithms16:21
paulsherwoodpresumably we could do something with only a few years' history or something?16:21
richard_mawpaulsherwood: yes, even from just fetching their own repository16:21
* paulsherwood clutches at straws16:22
franredpedroalvarez, it does fix the error16:22
paulsherwoodgit shallow clone, for example?16:25
richard_mawpaulsherwood: I don't know if we can specify a fixed-point for the import to start from with that16:25
paulsherwoodaccording to the interweb, shallow clone is better supported in git now16:25
richard_mawpaulsherwood: only relative to the current head, which would cause us to have unreproducible imports16:25
paulsherwoodoh, really?16:25
richard_mawunless it's drastically changed how it works recently, you get different SHA1s based on where you truncate the history16:26
* paulsherwood goes to check16:26
richard_mawtry depth 1 and depth 2, and if we get the same sha1 for the top commit, it's worth looking at further16:27
gary_perkinsCan anyone help with this? I'm trying to figure out why the permissions groups aren't working on this trove. In doing so I've been looking at the journal. 'gitano' keeps reporting errors, not sure if it's related to my particular issue, but doesn't look too good either Wondering if it's possible to get gitano to be more verbose with it's error logging?16:38
paulsherwoodrichard_maw: depth 1 gives HEAD 98e661b813cdf06f002c5bd36e428eed71fb029c, which matches;a=commit;h=98e661b813cdf06f002c5bd36e428eed71fb029c16:39
paulsherwood(which is HEAD)16:39
* paulsherwood waits patiently for depth 216:40
ssam2gary_perkins: argh, I don't know16:41
ssam2Gitano does give spurious warnings in the journal on a working Trove, check the journal on for example16:41
gary_perkinsssam2: ok16:42
ssam2in what you pasted, it may actually be that the 'create' command fails because that repo already exists16:42
ssam2lorry-controller tries to create a repo every time it updates it, rather than checking if it exists and only creating it if it doesn't16:42
gary_perkinsahh I see, thanks16:42
paulsherwoodrichard_maw: yup, same SHA116:43
pedroalvarezI wonder what would happen if you put a commit in the depth 2 repo and try to push to the depth 1 one16:43
* pedroalvarez is thinking about possible problems with this and lorry-controller16:44
richard_mawpaulsherwood: well, I'm pleased by that development then, but we still need to know if someone pushing a shallow clone as a mirror allows other people to clone the shallow clone, or whether it complains because it doesn't have the history16:44
paulsherwoodaccording to things have improved16:45
paulsherwoodwe'd need to try it, i expect16:45
richard_mawdid you see github's git-lfs thing? It sounds exactly like the kind of integration we did for git-fat with trove16:46
paulsherwoodlooks cool :)16:49
richard_mawI'm a bit suspicious of them doing their own bespoke storage backend16:49
paulsherwoodoh, they do?16:50
paulsherwoodno, then16:50
robtaylorcan see why the've done that16:52
*** Krin has quit IRC16:52
robtaylorits the sort of https api they can scale easily16:53
robtaylor(as opposed to rsync)16:53
robtayloralso to their credit, they're released the reference implementation in advance of github support. but yeah, this is something they'll control.16:54
richard_mawwhat's the reference implementation written in?16:55
* richard_maw didn't have time to check16:55
robtaylorrichard_maw: go :/16:55
* robtaylor does like 'go get' though, despite the languages other 'interesting' features16:56
* richard_maw doesn't like the implications of `go get`16:56
richard_mawbut I prefer go over ruby16:56
straycatgary_perkins, default ruleset doesn't allow creation of repos in delta16:56
paulsherwoodyup. gary_perkins should be creating repos somewhere lse, and letting trove put its mirrors of gbo in delta16:57
pedroalvarezI don't think he was trying to do that16:58
straycatno that was lorry wasn't it16:59
paulsherwoodnowster: am i right thinking you have a working mips 32le build environment?16:59
paulsherwood(single build or distbuild, no matter)16:59
gary_perkinsstraycat: paulsherwood: Thanks, rdale just wanted to push to the delta/ruby-gems/thor repo, not actually create any17:00
gary_perkinsBut as I'm having issues with the project groups not allowing him access, then it seems a wider problem with this trove17:00
straycatgary_perkins, oh, then so long as he's added to <troveprefix>-writers and pushing to <trove-prefix>/gitanousername/foo it should work17:00
gary_perkinsstraycat: Thanks, I'll try that :)17:01
nowsterpaulsherwood: yes17:02
robtaylorrichard_maw: interesting, do you mean secuirity implications?17:02
nowsterpaulsherwood: for some values of...17:02
*** zoli__ has joined #baserock17:02
gary_perkinsstraycat: I've added him to infrastructure-writers but he cannot access ct-trove/infrastructure/definitions :(17:03
straycatgary_perkins, you may need to create those groups if they don't exist17:03
ssam2does he need to be in ct-trove-writers to push to delta/ ?17:04
* straycat assumes that there's an associated infrastructure-readers group that he's also added to?17:04
*** ssam2 has quit IRC17:04
straycatssam2, i think... so17:05
gary_perkinsssam2: no, he needs to push to both, infrastructure/definitions and ruby-gems/thor repos17:05
gary_perkinsstraycat: yes, the standard project linked groups have been setup17:06
straycatgary_perkins, are you in trove-admin ?17:06
gary_perkinsstraycat: only in gitano-admin, I need to be in trove-admin too?17:07
straycatoh.. well that's weird, only gitano's meant to be in gitano-admin, but no matter i guess17:07
gary_perkinsI'm in as the "trove" user17:08
straycatahh hrm ok17:08
straycatwell anyway can you run "ssh git@trove as <rdale's username> whoami" to confirm he's in all the groups? cause i don't see why he shouldn't be able to clone17:09
*** wschaller has quit IRC17:14
*** wschaller has joined #baserock17:21
*** wschaller has quit IRC17:35
*** edcragg has quit IRC18:06
straycatwell that's odd18:17
* gary_perkins nods18:18
*** gary_perkins has quit IRC18:29
*** rdale has quit IRC18:33
*** zoli__ has quit IRC18:55
*** zoli__ has joined #baserock19:03
*** zoli__ has quit IRC19:16
*** zoli__ has joined #baserock20:09
*** zoli__ has quit IRC20:11
*** zoli__ has joined #baserock21:32
*** zoli__ has quit IRC21:48
*** Albert has quit IRC22:09

Generated by 2.15.3 by Marius Gedminas - find it at!