| *** zoli__ has joined #baserock | 06:31 | |
| *** Albert has joined #baserock | 06:41 | |
| *** Albert has quit IRC | 06:52 | |
| *** Albert has joined #baserock | 06:56 | |
| *** Albert has joined #baserock | 06:57 | |
| *** Albert has quit IRC | 07:08 | |
| *** a1exhughe5 has joined #baserock | 07:54 | |
| *** gary_perkins has joined #baserock | 08:01 | |
| *** ssam2 has joined #baserock | 08:47 | |
| *** ChanServ sets mode: +v ssam2 | 08:47 | |
| *** edcragg has joined #baserock | 08:53 | |
| *** franred has joined #baserock | 08:59 | |
| *** marcdunford has joined #baserock | 09:05 | |
| *** mdunford has quit IRC | 09:05 | |
| *** flatmush has joined #baserock | 09:06 | |
| *** wschaller has joined #baserock | 09:13 | |
| *** SotK has joined #baserock | 09:13 | |
| *** Krin has quit IRC | 09:19 | |
| *** Krin has joined #baserock | 09:19 | |
| *** richard_maw has quit IRC | 09:22 | |
| *** richard_maw has joined #baserock | 09:28 | |
| *** ChanServ sets mode: +v richard_maw | 09:28 | |
| ssam2 | tlsa: 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 repos | 09:36 |
|---|---|---|
| ssam2 | I guess you need the source repos either way | 09:36 |
| ssam2 | so it may as well just be generated from the source | 09:36 |
| ssam2 | and that reinforces the idea that builds are not valuable | 09:36 |
| ssam2 | i'm not sure if anyone uses the existing `morph generate-manifest` command: only the GENIVI releases ever used it | 09:37 |
| tlsa | ok | 09:37 |
| ssam2 | from http://wiki.baserock.org/guides/release-process/ looks like it is still part of the GENIVI Release process | 09:37 |
| tlsa | probably shouldn't modify it, if its designed for a specific purpose? | 09:38 |
| ssam2 | if it's designed for a specific purpose, rename it to `generate-genivi-manifest` | 09:38 |
| ssam2 | then we can add a `generate-csv-manifest` command, perhaps | 09:39 |
| ssam2 | when 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 now | 09:40 |
| ssam2 | 'those commands' being 'morph generate-manifest' and 'scripts/licensecheck.sh' | 09:41 |
| tlsa | ok | 09:41 |
| ssam2 | if 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, though | 09:41 |
| tlsa | yeah, or just provide multiple output formatting options in one command | 09:42 |
| ssam2 | yeah | 09:42 |
| ssam2 | the GENIVI manifest output is this by the way: http://download.baserock.org/baserock/genivi-h0.1r2-genivi-baseline-system-x86_64-generic-manifest.txt and http://download.baserock.org/baserock/genivi-h0.1r2-genivi-baseline-system-x86_64-generic-license-manifest.txt | 09:42 |
| tlsa | the patch for license checking in gerrit only checked the COPYING and LICENSE files at the root of the repo | 09:44 |
| ssam2 | right. that'd be misleading, then | 09:44 |
| tlsa | so only one license per chunk | 09:45 |
| ssam2 | most chunks have files which have more than one license, as you can see from the GENIVI example | 09:45 |
| tlsa | mm | 09:45 |
| ssam2 | or rather, each file has one license, but they aren't all the same one | 09:45 |
| ssam2 | so I think we have to list all of the ones that are found | 09:46 |
| tlsa | but they should all be compatible with the project license | 09:46 |
| tlsa | which would be in COPYING | 09:46 |
| ssam2 | I don't have expertise to know whether that's true or not, so I'd prefer to hedge our bets and include them all | 09:47 |
| ssam2 | doesn'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 |
| tlsa | about adding licensecheck.pl to morph, where should it get installed? | 09:50 |
| tlsa | /usr/bin/morph-lisensecheck.pl or something? | 09:51 |
| ssam2 | it could go in the Python module, you can set setup.py to install extra files | 09:51 |
| ssam2 | so it'd live in /usr/lib/python/site-packages/morphlib/ | 09:52 |
| ssam2 | at least then it can't interfere with anything else | 09:52 |
| tlsa | ok | 09:53 |
| *** Albert has joined #baserock | 10:02 | |
| *** Albert has quit IRC | 10:24 | |
| *** Albert has joined #baserock | 10:25 | |
| ratmice__ | an example of things containing incompatibly licensed stuff is GPLv2 code with GFDL documentation | 10:30 |
| Zara | Hi, I'm trying to lorry in some packages listed in the recipes here: | 10:38 |
| Zara | https://github.com/facebook/openbmc/tree/master/meta-facebook/meta-wedge/recipes-wedge | 10:38 |
| Zara | but the source is in the same repo as the recipes. | 10:38 |
| Zara | (eg: https://github.com/facebook/openbmc/tree/master/meta-facebook/meta-wedge/recipes-wedge/fbutils -- the recipe is the .bb, the source is in 'files') | 10:38 |
| Zara | I'm wondering what the best approach is. | 10:38 |
| perryl | i'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 |
| ssam2 | zara: can you just lorry the whole repo ? | 10:50 |
| ssam2 | perryl: i'm not really sure, I think this is first command in Morph to need to output a table of information | 10:52 |
| ssam2 | I think the way I would approach this is: don't format the message in the controller | 10:53 |
| ssam2 | send all the information back as a blob of JSON, and do the formatting in the client/initiator | 10:53 |
| ssam2 | to be honest, the current implementation is good enough, I'd be OK to see that done as a separate patch | 10:54 |
| ssam2 | I also agree with richard that we kind of overloaded the word 'jobs'... didn't really think of it before | 10:55 |
| ssam2 | but 'distbuild-list-build-requests' is quite a mouthful | 10:55 |
| ssam2 | might be OK just adding a comment that the word 'job' has another meaning inside the distbuild code | 10:55 |
| perryl | i 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 |
| ssam2 | nice | 10:55 |
| perryl | but yes, it is a case of how far down do i go to change the names | 10:56 |
| ssam2 | while we're here... it seems like the current version on Gerrit will still list the wrong initiator | 10:58 |
| ssam2 | is that fixed in your next version? | 10:58 |
| perryl | i 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 confusing | 10:59 |
| ssam2 | yeah, makes sense | 10:59 |
| ssam2 | It needs to print job.initiator_connection.initiator_name instead of self.initiator_name, basically | 11:00 |
| Zara | ssam2: 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 component | 11:02 |
| Zara | er, just pretend I wrote a sentence that made sense :) | 11:02 |
| ssam2 | zara: lorry can't really mirror part of a repo, so I think that's the only simple option | 11:05 |
| ssam2 | licenses are only a concern when distributing binaries. I don't think there are many open source licenses around which stop you redistributing source code | 11:05 |
| ssam2 | you can have more than one chunk built from the same git repo | 11:06 |
| Zara | okay, 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 |
| persia | That's a bug, and worth reporting upstream. | 11:17 |
| Zara | (eg: https://github.com/facebook/openbmc/blob/master/meta-facebook/meta-wedge/recipes-wedge/fan-ctrl/fan-ctrl_0.1.bb vs https://github.com/facebook/openbmc/blob/master/meta-facebook/meta-wedge/recipes-wedge/fan-ctrl/fan-ctrl/get_fan_speed.sh ) | 11:17 |
| persia | It can only be fixed by facebook, but they ought be able to fix it. | 11:17 |
| persia | As I understand it, "All rights reserved" ceased to have legal meaning when Nicaragua signed the Berne Convention, but I may be mistaken. | 11:18 |
| Zara | from what I could tell, the recipes are just 'all rights reserved', while the .c, .h, .sh (and so on) files have the full licence | 11:19 |
| Zara | so I wasn't sure if it was meant to be that way or not | 11:19 |
| * Zara doesn't know much about licensing law | 11:19 | |
| nowster | persia: why Nicaragua? | 11:20 |
| persia | nowster: I believe they were the last signatory of the Buenos Aires Convention that became a signatory of the Berne Convention | 11:21 |
| jjardon | I agree with persia that that seems a bug, you cannot have ALL the rights and be GPL at the same time | 11:22 |
| jjardon | https://lists.debian.org/debian-legal/2007/06/msg00252.html | 11:23 |
| Zara | Okay. 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 |
| persia | Zara: They do. That is full licensing information. | 11:30 |
| persia | BUt that means you can't distribute them, either verbatim or modified. | 11:31 |
| persia | So you want *different* licensing on those files. | 11:31 |
| Zara | yeah, sorry, that's what I was getting at | 11:31 |
| persia | You have to ask Facebook. | 11:31 |
| pedroalvarez | hehe, sounds easy | 11:31 |
| persia | In 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 |
| persia | The 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 |
| persia | And to have *different* patches if you need to clean up after multiple copyright holders. | 11:32 |
| perryl | ssam2: good catch on the traceback, i'd forgot to change len(jobs) to len(requests), i've pushed the change | 11:33 |
| persia | Using `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 |
| Zara | well, today has turned out to be more exciting than expected. :) | 11:34 |
| jjardon | unfortunately seems there is only 1 commit in openbmc repo | 11:37 |
| persia | Excellent. That makes the conversaion very easy. | 11:38 |
| persia | Because 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 IRC | 11: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 has | 12:00 |
| Zara | Okay, 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 IRC | 12:08 | |
| *** jonathanmaw has joined #baserock | 12:08 | |
| *** jonathanmaw has quit IRC | 12:11 | |
| persia | Zara: `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 |
| Zara | so, 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 #baserock | 12:40 | |
| persia | I 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 |
| persia | As 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 |
| Zara | it's odd; all their makefiles and recipes are just copyright facebook, while other program files are GPL. | 12:54 |
| Zara | maybe they thought the former didn't need it? | 12:54 |
| persia | Or maybe they are only releasing the code as GPL, and not the recipes. | 12:58 |
| richard_maw | perhaps they don't think that the build instructions contribute towards the derived work, just the code | 12:59 |
| Zara | I 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 |
| persia | I'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 |
| persia | Anyway, best thing is to ask the person who did the commit. They either know, or know who to ask. | 13:05 |
| paulsherwood | ybd-specific help request please... could anyone give me a clue as to why subversion install might fail, after build has succeeded? http://sprunge.us/OPDG | 13:14 |
| nowster | ....cannot find -lsvn_delta-1 | 13:17 |
| nowster | collect2: error: ld returned 1 exit status | 13:17 |
| paulsherwood | nowster: any idea what that means, though? | 13:18 |
| nowster | either the linker's built in path is wrong, or that library hasn't been put in the right place for the linker to find it | 13:19 |
| nowster | ...or ld is looking for stuff in $DESTDIR/usr/lib/ | 13:20 |
| nowster | it smells very much like a buggy script that only half understands DESTDIR | 13:22 |
| paulsherwood | nowster: ok, thanks for the clues | 13:22 |
| nowster | OR... one part of the configure knows about DESTDIR and the other needs telling about it. Perhaps a missing option? | 13:23 |
| paulsherwood | well this works in morph, so it's intriguing :) | 13:24 |
| Zara | persia: ah, they do indeed have different addresses in some of the code. Thanks for the tip. :) | 13:25 |
| Zara | well, not in the *code*, but you know what I mean :P | 13:25 |
| nowster | a bad case of COPYING ? ;-) | 13:26 |
| Zara | nowster: there is COPYING everywhere, yup | 13:26 |
| persia | nowster: Precisely. copying outdated COPYING | 13:27 |
| *** marcdunford has quit IRC | 13:45 | |
| *** zoli__ has quit IRC | 13:50 | |
| *** jonathanmaw has joined #baserock | 13:54 | |
| *** marcdunford has joined #baserock | 13:59 | |
| perryl | ssam2: 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 |
| ssam2 | up to you | 14:01 |
| ssam2 | do another version of 136 if it makes sense I think | 14:01 |
| perryl | i think it may be better as a separate patch if only because i've got a few other tasks to focus on right now | 14:02 |
| ssam2 | fair enough | 14:02 |
| jjardon | ssam2: Maybe of interest: Can we enable/install the reviewnotes in gerrit: it will annotate who +1/+2 the commits in a git note: http://blog.adamspiers.org/2013/10/02/more-uses-for-git-notes/ | 14:21 |
| ssam2 | that sounds useful | 14:21 |
| ssam2 | yeah, I'll look at it tomorrow | 14: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_maw | tiagogomes_: pretty much, though we also like baserock/$VERSION_NAME branches these days | 14:28 |
| richard_maw | and it's more descriptive, since we don't have the morphology in the branch any more | 14:29 |
| richard_maw | if we _can_ just keep the delta to the morphology file it makes it a lot easier to forward-port though | 14: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/morph | 14:30 |
| *** zoli__ has joined #baserock | 14:32 | |
| tiagogomes_ | should we be able to reference patches on the morphology? | 14:32 |
| tiagogomes_ | chunk: foo | 14:32 |
| tiagogomes_ | patches: | 14:32 |
| tiagogomes_ | - patches/fix-this-bug.patch | 14: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 delta | 14:33 |
| tiagogomes_ | maybe supporting applying patches would be better, as long as doen't hinder reproducibility | 14:34 |
| paulsherwood | tiagogomes_: -1 from me | 14:34 |
| ssam2 | seems like the problem only happens for dead projects | 14:34 |
| paulsherwood | we can and should have a git repo of the project, and a branch wih that patch in it | 14:34 |
| ssam2 | if the project is dead, having a delta against upstream isn't really an issue | 14:34 |
| franred | I also prefer to have the delta (branch) so we deal with the patches and it get reflected in a repository | 14:35 |
| persia | If a project is dead, and we need it, we should find others that need it, and collaborate on a new upstream. | 14:39 |
| persia | If 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 |
| persia | If 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 |
| persia | If some Baserock user has a project that needs something *now*, they should carry the patch in their own trove. | 14:42 |
| paulsherwood | +1 | 14:42 |
| jjardon | the fact that you need a trove to put a simple patch in a module is a bit stop over for new contributors | 14:44 |
| paulsherwood | jjardon: you don't... use github? | 14:45 |
| paulsherwood | or whatever git tooling yo already have/ | 14:45 |
| jjardon | paulsherwood: 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/branch | 14:48 |
| jjardon | If you think about it is even more annoying because maybe you already download the repo previously to build it | 14:49 |
| jjardon | For reference, in jhbuild: go to your local git repo -> make the patch in a branch -> change your definitions to point to the new repo/branch | 14:50 |
| pedroalvarez | jjardon: now imagine that the build fails. | 14:51 |
| pedroalvarez | and you want to debug what is going on in another computer | 14:52 |
| ssam2 | jjardon: jhbuild doesn't support distributing builds, which makes it a lot simpler | 14:52 |
| jjardon | pedroalvarez: add "git push" to the previous | 14:53 |
| paulsherwood | jjardon: ok, but then how do you share your work? | 14:54 |
| jjardon | ssam2: fair enough, but I do not think as a casual user I need distributed builds? | 14:55 |
| jjardon | paulsherwood: if I need to share I push my changes | 14:55 |
| ssam2 | jjardon: indeed, but it adds a lot of constraints to what Morph can do | 14:56 |
| paulsherwood | jjardon: yup. sorry i may be missing your point here, i'm multi-tasking | 14:56 |
| jjardon | ssam2: 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 though | 15:02 |
| gary_perkins | Hi, 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_perkins | in particular "delta/ruby-gems/thor" | 15:03 |
| paulsherwood | gary_perkins: on git.baserock.org, or in general on a trove? | 15:04 |
| gary_perkins | in general on a trove | 15:04 |
| franred | jjardon, 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_perkins | From the docs I've seen so far, the permission groups require a particular naming scheme | 15:05 |
| straycat | everyone needs distributed builds | 15:06 |
| jjardon | franred: 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 patch | 15:08 |
| franred | jjardon, we clone it separately to "share" the patch | 15:09 |
| * SotK doesn't think that we should support messing around with the repositories in the local repo cache | 15:09 | |
| SotK | if that is what this idea is suggesting | 15:11 |
| jjardon | franred: mmm, not sure; to make the patch, no matter if I'm going to share or not, I need to clone the repo separately | 15:11 |
| jjardon | franred: or am I missing something? | 15:11 |
| ssam2 | gary_perkins: I think this file is the key: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/trove-setup.git/tree/share/gitano/skel/gitano-admin/rules/other-project.lace?h=sam/fix-init-behind-proxy&id=bd80ed9a1690accd8d5dcb964ce387a27f6b014b | 15:11 |
| ssam2 | rather, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/trove-setup.git/tree/share/gitano/skel/gitano-admin/rules/other-project.lace | 15:12 |
| gary_perkins | ssam2: Great thanks, I'll have a look :) | 15:12 |
| ssam2 | this suggests that anyone with an account on that Trove should be able to push to delta/ | 15:12 |
| ssam2 | but only to branches named $trove_id/xxx | 15:12 |
| ssam2 | if that's not working, I have no idea how to debug it | 15:12 |
| franred | jjardon, 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 change | 15: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 sync | 15:16 |
| * ratmice__ points at gentoo | 15:19 | |
| jjardon | franred: "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 chunk | 15:20 |
| SotK | jjardon: you mean the clone into the local repo cache? | 15:21 |
| jjardon | SotK: yes | 15:23 |
| *** zoli__ has quit IRC | 15:24 | |
| franred | jjardon, 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 |
| franred | s/won't/wouldn't/ | 15:25 |
| SotK | you probably can, except we clone them with --mirror I believe | 15:25 |
| * SotK also wouldn't mess with his cached repos if he expected his build to work | 15:26 | |
| jjardon | franred: 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 |
| franred | jjardon, 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, TBH | 15:29 |
| tiagogomes_ | I still can't push to gerrit, it says that a pushed branch tip is behind its remote | 15:30 |
| ssam2 | I never got to the bottom of why. It's weird that it only happens to you | 15:31 |
| ssam2 | did you try passing --no-thin to `git push` ? | 15:31 |
| ssam2 | that works around a bug caused by a change in the Git protocol, which Gerrit 2.9 doesn't know about | 15:31 |
| gary_perkins | ssam2: 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 consult | 15:31 |
| gary_perkins | the logs... | 15:31 |
| jjardon | franred: 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/master | 15:32 |
| franred | jjardon, I did it I know that it takes a lot of time...but no all the repositories are as big as linux | 15:32 |
| franred | :) | 15:32 |
| tiagogomes_ | but now it failed in another step | 15:32 |
| richard_maw | I just pushed https://gerrit.baserock.org/#/c/236/ 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 defconfig | 15:33 |
| tiagogomes_ | how do I add a change-id to an already existing commit? | 15:33 |
| pedroalvarez | tiagogomes_: if it's only one, git commit --amend | 15:33 |
| richard_maw | tiagogomes_: 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 branch | 15:33 |
| pedroalvarez | that answer is much more complete :) | 15:34 |
| tiagogomes_ | both useful, thanks | 15:35 |
| tiagogomes_ | god dammit, it failed again, grrr | 15:35 |
| jjardon | tiagogomes_: what the error now? | 15:35 |
| tiagogomes_ | the fatal error is that I was being silly | 15:36 |
| pedroalvarez | " fatal: pbkac" ? | 15:37 |
| paulsherwood | :) | 15:38 |
| tiagogomes_ | I just created the commits and already have a merge conflict | 15:38 |
| tiagogomes_ | can I fix it through the web interface? | 15:38 |
| jjardon | richard_maw: mmm, I do not see recent changes in the x86_64_defconfig: http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux-stable.git/log/arch/x86/configs/x86_64_defconfig?h=linux-3.19.y | 15:40 |
| pedroalvarez | tiagogomes_: I think that the merge conflict will be fixed once it's merged the firt patch | 15:40 |
| pedroalvarez | s/firt/first/ | 15:40 |
| tiagogomes_ | pedroalvarez I see | 15:41 |
| jjardon | richard_maw: neither in http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux-stable.git/log/arch/x86/configs/i386_defconfig?h=linux-3.19.y | 15:41 |
| richard_maw | jjardon: the weird thing is that E1000E is enabled in i386, but not x86_64, but it previously was enabled in both | 15: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 comment | 15:47 |
| richard_maw | I usually copy the text and prepend a > to it | 15:47 |
| pedroalvarez | tiagogomes_: there is a button to do that, top right of the comment | 15:48 |
| tiagogomes_ | ¬_¬, so guerrit doesn't support replying to particular comments | 15:48 |
| tiagogomes_ | pedroalvarez, ah, there is indeed, ta | 15:49 |
| jjardon | richard_maw: mmm, for some reason it was not added in x86_64 when added in i386 http://marc.info/?l=linux-kernel&m=133253194805436 | 15:49 |
| jjardon | richard_maw: was it added after and then removed? let me investigate more | 15:49 |
| tiagogomes_ | franred, can you reconsider your -1 as per comments | 15:49 |
| richard_maw | jjardon: IMO we shouldn't rely so much on the contents of defconfigs for things we need | 15:50 |
| jjardon | richard_maw: sure, I was only curious about the regression: seems it never got enabled | 15:51 |
| richard_maw | could 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 |
| franred | tiagogomes_, reconsidered ;-) | 15:52 |
| jjardon | ratmice__: pulling, not pushing. And the steps as well, yes | 15: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 |
| ratmice__ | ahh | 15:53 |
| ssam2 | jjardon: you could clone from Morph's local repo cache (although that's not made easy right now) | 15:55 |
| *** a1exhughe5 has quit IRC | 16:00 | |
| jjardon | ssam2: oh, didn't think about that. That would be probably faster, yes | 16:01 |
| * SotK points out that this is exactly the thing he likes about `morph edit` | 16:02 | |
| * SotK hides | 16:02 | |
| pedroalvarez | morph edit does clone from the local repo cache? | 16:04 |
| paulsherwood | yup | 16:04 |
| * SotK wonders what opinions would be on a command which does the checkout like morph edit but not any of the other magic | 16:08 | |
| ssam2 | i'd be in favour! | 16:09 |
| pedroalvarez | I always try to thing about these new feature in a world without workspaces | 16:09 |
| pedroalvarez | s/feature/features/ | 16:09 |
| jjardon | SotK: seems "morph edit" its an improvement, thanks! | 16:09 |
| jjardon | SotK: 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 |
| SotK | jjardon: yeah, the change of ref and unpetrify ref, plus the weird stuff it does to use the local repo in a build | 16:12 |
| jjardon | SotK: yeah the last thing is the only one I really dont like | 16:12 |
| jjardon | SotK: +1 for the get-repo idea btw: at least for me it will be useful | 16:13 |
| franred | fix ebtables binary path in libvirt: https://gerrit.baserock.org/#/c/239/ | 16:14 |
| 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 |
| pedroalvarez | franred: oh, was that causing problems? | 16:16 |
| franred | pedroalvarez, it fails when libvirt try to use it - not sure if it causes problems but better to fix it | 16:17 |
| paulsherwood | ratmice__: is that a case where gbo doesn't have the upstream? | 16:17 |
| richard_maw | franred: it's not a problem for us, since OpenStack does its own firewall setup | 16:17 |
| paulsherwood | s/firewall setup/everything/ | 16:18 |
| richard_maw | heh, pretty much | 16:18 |
| franred | richard_maw, yeah, but OpenStack also requires ebtables for some kind of magic... | 16:18 |
| richard_maw | franred: yes, but it isn't deterred by it not being in the path that libvirt expected | 16:18 |
| ratmice__ | paulsherwood: gcc-tarball.git | 16:19 |
| franred | richard_maw, true | 16:19 |
| jjardon | If you have some time, can anyone take a look to https://gerrit.baserock.org/#/c/14/ | 16:19 |
| pedroalvarez | franred: but if this is fixing things, why not? | 16:19 |
| paulsherwood | ratmice__: ah, i see. | 16:20 |
| paulsherwood | can anyone remember why we don't have gcc in gbo? | 16:20 |
| ratmice__ | cause it's absurdly large | 16:21 |
| jjardon | paulsherwood: last time I asked it failed to clone | 16:21 |
| paulsherwood | from git? git://gcc.gnu.org/git/gcc.git | 16:21 |
| richard_maw | we have gcc-tarball because the gcc repository is massive, partly because its standard practise is the pathological worst case | 16:21 |
| richard_maw | for git's packing algorithms | 16:21 |
| paulsherwood | presumably we could do something with only a few years' history or something? | 16:21 |
| richard_maw | paulsherwood: yes, even from just fetching their own repository | 16:21 |
| * paulsherwood clutches at straws | 16:22 | |
| franred | pedroalvarez, it does fix the error | 16:22 |
| paulsherwood | git shallow clone, for example? | 16:25 |
| richard_maw | paulsherwood: I don't know if we can specify a fixed-point for the import to start from with that | 16:25 |
| paulsherwood | according to the interweb, shallow clone is better supported in git now | 16:25 |
| richard_maw | paulsherwood: only relative to the current head, which would cause us to have unreproducible imports | 16:25 |
| paulsherwood | oh, really? | 16:25 |
| richard_maw | unless it's drastically changed how it works recently, you get different SHA1s based on where you truncate the history | 16:26 |
| * paulsherwood goes to check | 16:26 | |
| richard_maw | try depth 1 and depth 2, and if we get the same sha1 for the top commit, it's worth looking at further | 16:27 |
| gary_perkins | Can 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 http://paste.baserock.org/wilijolixa Wondering if it's possible to get gitano to be more verbose with it's error logging? | 16:38 |
| paulsherwood | richard_maw: depth 1 gives HEAD 98e661b813cdf06f002c5bd36e428eed71fb029c, which matches https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98e661b813cdf06f002c5bd36e428eed71fb029c | 16:39 |
| paulsherwood | (which is HEAD) | 16:39 |
| * paulsherwood waits patiently for depth 2 | 16:40 | |
| ssam2 | gary_perkins: argh, I don't know | 16:41 |
| ssam2 | Gitano does give spurious warnings in the journal on a working Trove, check the journal on git.baserock.org for example | 16:41 |
| gary_perkins | ssam2: ok | 16:42 |
| ssam2 | in what you pasted, it may actually be that the 'create' command fails because that repo already exists | 16:42 |
| ssam2 | lorry-controller tries to create a repo every time it updates it, rather than checking if it exists and only creating it if it doesn't | 16:42 |
| gary_perkins | ahh I see, thanks | 16:42 |
| paulsherwood | richard_maw: yup, same SHA1 | 16:43 |
| pedroalvarez | I wonder what would happen if you put a commit in the depth 2 repo and try to push to the depth 1 one | 16:43 |
| * pedroalvarez is thinking about possible problems with this and lorry-controller | 16:44 | |
| richard_maw | paulsherwood: 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 history | 16:44 |
| paulsherwood | according to http://blogs.atlassian.com/2014/05/handle-big-repositories-git/ things have improved | 16:45 |
| paulsherwood | we'd need to try it, i expect | 16:45 |
| richard_maw | did you see github's git-lfs thing? It sounds exactly like the kind of integration we did for git-fat with trove | 16:46 |
| paulsherwood | looks cool :) | 16:49 |
| richard_maw | I'm a bit suspicious of them doing their own bespoke storage backend | 16:49 |
| paulsherwood | oh, they do? | 16:50 |
| paulsherwood | no, then | 16:50 |
| robtaylor | can see why the've done that | 16:52 |
| *** Krin has quit IRC | 16:52 | |
| robtaylor | its the sort of https api they can scale easily | 16:53 |
| robtaylor | (as opposed to rsync) | 16:53 |
| robtaylor | also 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_maw | what's the reference implementation written in? | 16:55 |
| * richard_maw didn't have time to check | 16:55 | |
| robtaylor | richard_maw: go :/ | 16:55 |
| robtaylor | https://github.com/github/lfs-test-server | 16:55 |
| * robtaylor does like 'go get' though, despite the languages other 'interesting' features | 16:56 | |
| * richard_maw doesn't like the implications of `go get` | 16:56 | |
| richard_maw | but I prefer go over ruby | 16:56 |
| straycat | gary_perkins, default ruleset doesn't allow creation of repos in delta | 16:56 |
| paulsherwood | yup. gary_perkins should be creating repos somewhere lse, and letting trove put its mirrors of gbo in delta | 16:57 |
| pedroalvarez | I don't think he was trying to do that | 16:58 |
| straycat | no that was lorry wasn't it | 16:59 |
| paulsherwood | nowster: am i right thinking you have a working mips 32le build environment? | 16:59 |
| paulsherwood | (single build or distbuild, no matter) | 16:59 |
| gary_perkins | straycat: paulsherwood: Thanks, rdale just wanted to push to the delta/ruby-gems/thor repo, not actually create any | 17:00 |
| gary_perkins | But as I'm having issues with the project groups not allowing him access, then it seems a wider problem with this trove | 17:00 |
| straycat | gary_perkins, oh, then so long as he's added to <troveprefix>-writers and pushing to <trove-prefix>/gitanousername/foo it should work | 17:00 |
| gary_perkins | straycat: Thanks, I'll try that :) | 17:01 |
| nowster | paulsherwood: yes | 17:02 |
| robtaylor | richard_maw: interesting, do you mean secuirity implications? | 17:02 |
| nowster | paulsherwood: for some values of... | 17:02 |
| *** zoli__ has joined #baserock | 17:02 | |
| gary_perkins | straycat: I've added him to infrastructure-writers but he cannot access ct-trove/infrastructure/definitions :( | 17:03 |
| straycat | gary_perkins, you may need to create those groups if they don't exist | 17:03 |
| ssam2 | does 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 IRC | 17:04 | |
| straycat | ssam2, i think... so | 17:05 |
| gary_perkins | ssam2: no, he needs to push to both, infrastructure/definitions and ruby-gems/thor repos | 17:05 |
| gary_perkins | straycat: yes, the standard project linked groups have been setup | 17:06 |
| straycat | gary_perkins, are you in trove-admin ? | 17:06 |
| gary_perkins | straycat: only in gitano-admin, I need to be in trove-admin too? | 17:07 |
| straycat | oh.. well that's weird, only gitano's meant to be in gitano-admin, but no matter i guess | 17:07 |
| gary_perkins | I'm in as the "trove" user | 17:08 |
| straycat | ahh hrm ok | 17:08 |
| straycat | well 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 clone | 17:09 |
| gary_perkins | straycat: http://paste.baserock.org/okuwatebaj | 17:11 |
| *** wschaller has quit IRC | 17:14 | |
| *** wschaller has joined #baserock | 17:21 | |
| *** wschaller has quit IRC | 17:35 | |
| *** edcragg has quit IRC | 18:06 | |
| straycat | well that's odd | 18:17 |
| * gary_perkins nods | 18:18 | |
| *** gary_perkins has quit IRC | 18:29 | |
| *** rdale has quit IRC | 18:33 | |
| *** zoli__ has quit IRC | 18:55 | |
| *** zoli__ has joined #baserock | 19:03 | |
| *** zoli__ has quit IRC | 19:16 | |
| *** zoli__ has joined #baserock | 20:09 | |
| *** zoli__ has quit IRC | 20:11 | |
| *** zoli__ has joined #baserock | 21:32 | |
| *** zoli__ has quit IRC | 21:48 | |
| *** Albert has quit IRC | 22:09 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!