| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 00:16 | |
| *** burper [~burper@modemcable082.140-131-66.mc.videotron.ca] has joined #baserock | 02:52 | |
| *** burper [~burper@modemcable082.140-131-66.mc.videotron.ca] has quit [] | 02:52 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 05:38 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Quit: Coffee time's over, it's probably Beer O Clock.] | 07:18 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 07:59 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 252 seconds] | 08:00 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 08:06 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:07 | |
| *** mariaderidder [~maria@213.16.35.194] has joined #baserock | 08:14 | |
| *** ssam2 [~ssam2@213.16.35.194] has joined #baserock | 08:16 | |
| Mode #baserock +v ssam2 by ChanServ | 08:16 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:24 | |
| *** a1exhughe5 [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:41 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 08:55 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 08:57 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:08 | |
| *** rdale [~quassel@40.Red-83-47-20.dynamicIP.rima-tde.net] has joined #baserock | 09:14 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:15 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 09:17 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 09:17 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09:17 | |
| ssam2 | I created a baserock-14.46 tag in morph.git | 09:34 |
|---|---|---|
| ssam2 | was trying to upgrade the version of Morph on a distbuild network to master, then back to baserock-14.46 | 09:35 |
| ssam2 | and didn't want to type out the SHA1 | 09:35 |
| persia | Didn't you have to type the SHA to create the tag? | 09:37 |
| * persia rather wishes morph had proper versioning, independent of definitions | 09:38 | |
| persia | Having them linked only invites us to make more changes that cause following master to be hard. | 09:38 |
| ssam2 | 'following master' of what ? | 09:40 |
| ssam2 | i'd be ok separating Morph version from Baserock version | 09:40 |
| persia | master of anything in Baserock, really. | 09:41 |
| ssam2 | I had to type the sha1 to create the tag, but i didn't have to type the sha1 while showing my colleagues how to use the 'update distbuild network to a new morph version quickly' thingy i made for them | 09:42 |
| Kinnison | If we refer to all the software in baserock as 'the universe' then we can all follow the masters of the universe | 09:42 |
| ssam2 | which was the goal | 09:42 |
| persia | Essentially, when things are linked, we are more likely to make changes in multiple baserock components that depend upon each other without a clean transition model. | 09:42 |
| ssam2 | yes. but I think part of the goal of Baserock initially was to avoid having to extra work maintaining every possible combination of different components | 09:42 |
| ssam2 | *having to do | 09:42 |
| persia | ssam2: In a you-can't-tag-it-like-that model, I'd do that by precreating a patch with the sha change, and committing it or stashing it, as a means to move back and forth between states. | 09:43 |
| ssam2 | persia: sorry, you've lost me | 09:43 |
| persia | Kinnison: Please, no. MOTU was fun when I did it, but the name caused lots of issues, and I don't think it belongs anywhere else. | 09:43 |
| Kinnison | persia: bah, you ruin all my fun :-) | 09:44 |
| persia | ssam2: In the event that I wanted to pre-type the SHA for a demo, I'd make the change, and use git to track the two different copies, either with a commit, which I could uncommit, or with `git stash`. | 09:44 |
| ssam2 | my colleagues do not like typing sha1s, ever | 09:45 |
| persia | And the goal of not having to maintain every combination confuses me. The main value I see to Baserock is that I *can* maintain more different combinations than if I use a distro. | 09:45 |
| persia | ssam2: Then perhaps they need the tool to update definitions with the current SHA of the current repo that I've been talking about for the past 10 months, just like I do. Expecting someone else to type their sha and create a tag isn't scalable. | 09:46 |
| ssam2 | i may well write said tool for them :) | 09:46 |
| persia | That would be lovely :) | 09:46 |
| ssam2 | but we're not using definitions here, we're using this: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/distbuild/ansible?h=sam/distbuild-ansible | 09:47 |
| ssam2 | because building and deploying a system to 7 distbuild notes is way too slow for testing a change to morph | 09:47 |
| ssam2 | *nodes | 09:47 |
| ssam2 | and fixing that 'properly' is not currently in scope | 09:48 |
| persia | Ugh. That's frustrating. My sympathies. | 09:48 |
| ssam2 | ansible is working pretty well for the job , though :) | 09:48 |
| persia | Yes, but doing it that way rather removes most of the benefits of using Baserock. | 09:49 |
| *** locallycompact [~lc@253.175.125.91.dyn.plus.net] has joined #baserock | 09:51 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:56 | |
| *** br_logger [~ubuntu@185.43.218.176] has joined #baserock | 09:58 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:13 | |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:26 | |
| * straycat shakes paws at .gitignore | 10:30 | |
| straycat | (forced me to read things instead of randomly grepping) | 10:31 |
| Kinnison | ? | 10:32 |
| straycat | the config.mk was in the .gitignore and i didn't notice the include for it | 10:32 |
| straycat | so I couldn't see where this thing got defined | 10:33 |
| Kinnison | aah | 10:33 |
| Kinnison | straycat: git config --global alias ggrep 'git grep --untracked --no-exclude-standard' | 10:34 |
| Kinnison | maybe useful | 10:34 |
| straycat | oh cool thank you | 10:35 |
| Kinnison | might need a dot between alias and ggrep | 10:36 |
| straycat | oh I added it to the .gitconfig myself, except i named it g rather ggrep :p | 10:38 |
| straycat | so now it's g g <pattern> , which is nice for me :3 | 10:38 |
| *** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:47 | |
| *** a1exhughe5 [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 10:51 | |
| *** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 11:32 | |
| jmacs | Trying to self deploy, get this: mkdir: can't create directory '/tmp/tmp.IMjFeB/systems/15.02': File exists | 11:48 |
| jmacs | It feels familiar but I don't have anything in my logs about it | 11:48 |
| straycat | that's weird, what are you deploying to? | 11:49 |
| pedroalvarez | jmacs: are you already in 15.02? | 11:49 |
| jmacs | No, this is an old VM, I'm trying to upgrade to 15.02 | 11:50 |
| pedroalvarez | `system-version-manager list` should give you some info | 11:50 |
| jmacs | Ok, 15.02 is there, but not running or default | 11:50 |
| jmacs | factory (running) (default) | 11:50 |
| jmacs | 15.02 | 11:50 |
| jmacs | I'll try 15.02a | 11:50 |
| pedroalvarez | yes | 11:50 |
| pedroalvarez | you can also try `system-version-manager remove 15.02` | 11:51 |
| pedroalvarez | remove or delete, not sure | 11:51 |
| *** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:52 | |
| ssam2 | new import tool docs look really good, thanks straycat and zara | 11:53 |
| ssam2 | we should probably update the README files in the Git repo to link to the wiki, and remove any content that's duplicated in the READMEs | 11:53 |
| ssam2 | it's nice to have the info in both places, but i imagine it'll just go out of date in whichever one we don't use | 11:53 |
| Zara_ | :D Thanks, ssam2! Yeah, agree on the README duplication issue; as long as there's a link I'm happy. | 11:54 |
| Zara_ | (can confirm that the system-version-manager command is 'remove') | 11:55 |
| petefoth | ssam2: Zara_: there will also need to be a back-reference from the wiki saying "if you move or remove this page, pleas eupdated the links in xxx/yyy/README" otherwide we end up with *broken* links in the README | 11:55 |
| Zara_ | Agreed. :) | 11:58 |
| ssam2 | i'm hoping we don't feel the need to rearrange the wiki on a weekly basis | 11:58 |
| ssam2 | although i don't disagree it'd be good to have such a text in the wiki somewhere | 11:59 |
| Zara_ | heh, yeah, I've tried to organise it in a way that should avoid us having to rearrange things | 12:00 |
| Zara_ | maybe that'd be good to have as a general point on the 'editing the wiki' section | 12:01 |
| petefoth | Zara_: indeed, but as well as the general case (e.g 'if you are editing the wiki, please consider / check whether links in code or README files need to be updated or removed') we should alos flag *specific case we know about (IMHO) | 12:03 |
| Zara_ | petefoth: I think it's a good idea, as long as we're careful, since links *to* the READMEs could also go out of date-- generating *more* broken links! (I think broken links look bad, but are at least easily discovered if a tool is heavily used (compared to out-of-date info, which might take a while to spot).) | 12:10 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 12:12 | |
| petefoth | Zara_: I agree with all of that. Documentation needs time and effort allocated to maintenenance in exactly the same way as code, tests and other software artifacts. At times it can be just as hard to fdo right | 12:12 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:13 | |
| Zara_ | petefoth: Yeah, personally I think that good documentation is key to attracting a bigger community, but then you tend to need the numbers (or time) to generate the docs in the first place. | 12:17 |
| petefoth | Zara_: and you need people who are interested in making (specifying, designing, implementing, verifying and maintaining) the docs, when they could be writing code | 12:20 |
| petefoth | Also, not everyone agrees on the importance of docs] | 12:20 |
| Zara_ | yes to all of that. :) I do documenting as stress-relief, because I find it easier. | 12:21 |
| DavePage | Documentation is great for scalability, certainly. Also to reduce latency in getting up to speed with something you've not encountered before, or for a while - means you can context switch faster. | 12:23 |
| Zara_ | I partly view it as an indication of whether or not there's an active community of people who will help if I get stuck. Maybe that's unfair, but I tend to go in assuming that at some point I'll get a weird bug, and I want to be able to fix it as quickly as possible. | 12:27 |
| DavePage | *nods* | 12:27 |
| DavePage | Although some projects just have good IRC instead | 12:27 |
| Zara_ | yeah, that's why I think I'm being a bit unfair | 12:28 |
| DavePage | I dunno. It shows good long-term attitudes to write stuff down in a way that means people don't have to ask questions. | 12:28 |
| DavePage | But I can't get my head around the exim docs for example, they're a great reference but a rubbish tutorial, and #exim is very helpful | 12:29 |
| jmacs | Gah, destroyed another baserock VM by trying to rm -rf /tmp/tmp.rcqEvJ/ | 12:30 |
| Zara_ | DavePage: yeah, I think both are important. I love it when you can just search the wording of an error online, though, and get an instant solution. | 12:32 |
| DavePage | Yep | 12:32 |
| jmacs | Not sure if that's an argument for documentation or IRC | 12:32 |
| DavePage | jmacs: Both have their uses; on the whole good documentation is great for common problems, and IRC is good for debugging more complex ones. | 12:33 |
| DavePage | Commonly used software with poor documentation is a bad sign, and one way to get your software more commonly used is to improve its documentation. | 12:33 |
| jmacs | I meant being able to search for a specific error. Usually that turns up forum posts or IRC logs for me. | 12:33 |
| DavePage | #include <daves_rant_about_quicktransit_installer.txt> | 12:34 |
| petefoth | jmacs: do many projects have irc logs that are searchable by new users? | 12:35 |
| jmacs | petefoth: Yes, in that Google indexes them | 12:35 |
| petefoth | jmacs: so how would I search google for logs of #baserock? | 12:36 |
| jmacs | Type the error message into google | 12:36 |
| *** mariaderidder [~maria@213.16.35.194] has quit [Ping timeout: 245 seconds] | 12:38 | |
| persia | Does google spider irclogs.baserock.org? | 12:41 |
| jmacs | If that site were up it probably would | 12:41 |
| persia | It does, but it doesn't cache them | 12:46 |
| *** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 13:05 | |
| *** mariaderidder [~maria@213.16.35.194] has joined #baserock | 13:13 | |
| jmacs | Is cache.baserock.org back up? It looks like it :) | 13:19 |
| DavePage | Things are startign to reappear but I wouldn't rely on that until we get the all-clear from DataCentred | 13:23 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 13:26 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:36 | |
| pedroalvarez | hey straycat, I like your Autodefrag /var patch | 13:54 |
| pedroalvarez | Does that mean that journalctl will be faster if merged? | 13:55 |
| straycat | should be | 13:57 |
| richard_maw | the next version of systemd will set the journal files as nocow | 14:00 |
| richard_maw | so they won't fragment as easily | 14:00 |
| DavePage | Moo | 14:00 |
| pedroalvarez | noMoo | 14:00 |
| rjek | nomoo | 14:00 |
| rjek | snap | 14:00 |
| * straycat mews | 14:00 | |
| *** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:04 | |
| Zara_ | I missed the mention of 'nocow' and was very confused. | 14:05 |
| *** mariaderidder [~maria@213.16.35.194] has quit [Ping timeout: 272 seconds] | 14:10 | |
| DavePage | 14:06:33 <+statusbot> Status update: Recovery of the storage cluster has now been completed successfully. Storage API endpoints have now been re-enabled. We are currently working to bring the Compute on Demand storage connectivity back online, and performing a number of health and performance checks to ensure everything is behaving as expected. We will be monitoring both the Compute on Demand and Storage on Demand clusters for ... | 14:13 |
| DavePage | ... the next hour to ensure everything is stable, at which point the Compute on Demand endpoints will be re-enabled and the issue resolved. Please bear with us for this final hour whilst we perform the necessary health checks. | 14:13 |
| petefoth | 'final hour' is an unfortunate turn of phrase! | 14:14 |
| *** locallycompact [~lc@253.175.125.91.dyn.plus.net] has quit [Remote host closed the connection] | 14:15 | |
| DavePage | It's the final countdown! | 14:15 |
| pedroalvarez | tinoniiiiiinoo | 14:15 |
| DavePage | My earworm work here is done :) | 14:15 |
| persia | DavePage: Thanks for the update | 14:15 |
| pedroalvarez | so, after this incident I've been thinking about how can avoid this in the future | 14:16 |
| pedroalvarez | does anybody have ideas? | 14:16 |
| jmacs | Sounds like we need two troves on different hosting providers | 14:17 |
| persia | I think we need to think about different solutions for different services. | 14:17 |
| pedroalvarez | persia: indeed | 14:18 |
| persia | For cache.baserock.org, a simple CDN would be good. I don't think we need an expensive one: just two differently hosted locations, some rsync, and a DNS server that returns one-of-a-set, rather than always the same value. | 14:18 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 14:18 | |
| persia | For irclogs, I think we should run two bots in two different DCs, and use some merge-processing algorithm to have a single set of logs, subject to the same sort of CDN as cache. | 14:18 |
| persia | For distbuild, I think we're stuck on a DC, but if we have the cluster defintions somewhere accessible, we ought be able to redeploy in reasonable time. | 14:19 |
| jmacs | I don't think irclogs are important enough to need that level of complication | 14:19 |
| persia | We talked about git.baserock.org before: there seems to be no good solution for multimaster git, so perhaps just mirroring somewhere public. | 14:19 |
| richard_maw | it might help if we can get rid of the ref resolving bit of the git cache servers, I've heard suggestion that we could use the remote git repositories directly | 14:20 |
| persia | richard_maw: Doesn't that make us more dependent on shared infrastructure? | 14:20 |
| persia | To be clear, by "cache", I meant artifact cache | 14:20 |
| richard_maw | I was trying to be clear that I meant the other bit of the cache service, but I appear to have failed there. The cache servers serve both artifacts, and you can request a handful of git commands on repositories they have locally | 14:21 |
| richard_maw | cache.baserock.org has the git service turned off AIUI | 14:21 |
| richard_maw | bit git.baserock.org also has the cache service so it can do the git operations | 14:22 |
| richard_maw | I'm not sure where shared infrastructure comes in | 14:22 |
| persia | Ah, right, but I thought git.baserock.org didn't have any artifacts | 14:22 |
| richard_maw | we used to put release artifacts on there, but no, we don't use the artifact cache operation of git.baserock.org much these days, since cache.baserock.org gets populated by distbuild and CI | 14:23 |
| persia | My confusion: by using remotes directly, rather than cached, I thought you meant not using the local caches in a development system. | 14:23 |
| richard_maw | ah, yeah, I didn't mean that | 14:23 |
| persia | Then my comment is irrelevant and misleading :) | 14:24 |
| richard_maw | I heard you could do `git cat-file` on remotes, using a subset of the git transfer protocol, which would prevent us needing to have the git cache server as a proxy for running the cat-file commands | 14:25 |
| *** locallycompact [~lc@253.175.125.91.dyn.plus.net] has joined #baserock | 14:25 | |
| persia | Do we expect that would speed operations? | 14:26 |
| richard_maw | not especially, but it's one less service we need to horizontally scale | 14:26 |
| persia | That is an excellent argument for the change :) | 14:29 |
| persia | Does anyone know how much manual configuration Mason requires? Is it as easy to deploy as distbuild workers? | 14:29 |
| pedroalvarez | persia: needs some, I've been thinking on creatin a branch now that mason is changing to keep this version somewhere to be deployable without manual configuration. | 14:31 |
| pedroalvarez | my plan is to do the same for all the servers in DC | 14:31 |
| persia | Makes sense, and the branch can be rebased against master when things are upgraded in the infrastructure. | 14:32 |
| pedroalvarez | yup | 14:32 |
| *** mariaderidder [~maria@213.16.35.194] has joined #baserock | 14:32 | |
| persia | Also allows putting detailed cluster definitions in place, only missing credentials, whether they are especially interesting as reference clusters or not. | 14:33 |
| pedroalvarez | we are actually doing these things in a fork of definitions: https://github.com/ssssam/test-baserock-infrastructure | 14:33 |
| persia | I'm not sure I like the "test" in that name, but it seems the right direction. I hope once it proves itself it can be renamed as with many of the other tests you guys have done. | 14:35 |
| pedroalvarez | it started being a test, I guess | 14:36 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 14:43 | |
| Zara_ | hi, pedroalvarez, now I'm no longer doing documentation I've gone back to looking at the nodejs stratum patch-- could you explain what the problem is with using 'npm build'? I don't know why this is a problem, so I don't know what I need to change it to. | 14:50 |
| *** br_logger [~ubuntu@185.43.218.176] has quit [Ping timeout: 264 seconds] | 14:54 | |
| *** br_logger [~ubuntu@185.43.218.176] has joined #baserock | 14:56 | |
| jmacs | Lorrying a CVS repository takes a long time | 15:03 |
| Kinnison | Sadly it takes a lot of work to reconstitute commits across a CVS repo | 15:03 |
| pedroalvarez | hi Zara_! so, normally, when building and installing something in baserock, we compile the sources, to generate the artifacts needed, and then we only install these artifacts, so we avoid the installation of the source code. | 15:04 |
| jmacs | I bet. I remember working off a CVS repository. | 15:05 |
| pedroalvarez | In your node-npm chunk you are installing all the sources, and then "compiling" there to get the artifacts needed. So your install is also going to install things not needed | 15:06 |
| Zara_ | ah, is this just an issue for the node-npm chunk? I realised that chunk may not be necessary, since npm is currently installed with nodejs in any baserock system with nodejs installed. Afaik, 'npm build' and 'npm install' don't do any compiling, since compiles at run time-- but I may just be confused. https://developers.google.com/v8/design#mach_code | 15:17 |
| Zara_ | /s/since compiles/since nodejs compiles | 15:17 |
| pedroalvarez | Yeah, I shoultn't have used "compile" | 15:18 |
| pedroalvarez | Zara_: this is also for the npm-util chunk. IIRC you are using the same install commands | 15:19 |
| Zara_ | ah, I meant because npm itself has some non-nodejs parts, but the other things shouldn't have | 15:21 |
| Zara_ | (so I thought there might be some compiling involved there) | 15:23 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 15:23 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:24 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:27 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth] | 15:45 | |
| Zara_ | okay, I'm just confused by all this. In a case where things aren't being compiled prior to running, I don't understand what a needed artifact would be, other than the source code. At present the patch installs the source code. The patch isn't necessary, so maybe it'd be better to leave it to someone who understands this all better (possibly a future me :P). | 15:58 |
| persia | Zara_: Ignore "compilation". | 15:59 |
| persia | Rather, consider that you start with something optimised for development and you end with something optimised for deployment. | 15:59 |
| persia | We'll call the former "source" and the latter "artifact" | 15:59 |
| persia | In the case of interpreted languages, these are closely related, although perhaps the file arrangement is a bit different. | 16:00 |
| persia | In the specific case of Javascript, it is common to compact the "source" to generate the "artifact" by reducing the length of variable names, concatenating files, removing whitespace, etc. | 16:00 |
| persia | Even if that isn't done, some files may be useful for delivery that are not useful for development, and vice versa. | 16:01 |
| persia | So when "installing", one should avoid copying some things (like a README file written for a developer audience), and perhaps autogenerate others (like a working configuration). | 16:01 |
| persia | Does it make more sense in that context? | 16:01 |
| Zara_ | I think so, but I don't think npm installs things that way, at any rate; as far as I can tell it just moves the source from the github repo to specific folders on a user's system. So I doubt I could achieve the above by using builtin npm commands, and if someone wants npm packages, then (I'd have thought) they'd probably want them to install as expected. | 16:06 |
| Zara_ | I don't know how I'd differentiate the useful stuff from the not-useful stuff | 16:06 |
| *** mariaderidder [~maria@213.16.35.194] has quit [Quit: Ex-Chat] | 16:07 | |
| persia | Makes sense, actually, because the advantage of "compiling" Javascript is about browser memory usage, bandwidth, and consumer router cache sizes. | 16:08 |
| persia | So for server side, where one has server memory, one can just use the source. | 16:08 |
| DavePage | There's also in-browser JavaScript compilation but that's not relevant to this analogy | 16:09 |
| persia | I'd be happier if the npm community differentiated which files were code and which were irrelevant in their package description format, but I'm willing to believe that they fail to do so. | 16:09 |
| persia | DavePage: Or in engine generally: e.g. node, but yes, irrelevant. | 16:10 |
| * rjek win 29 | 16:10 | |
| * rjek is paulsherwood :( | 16:10 | |
| Zara_ | persia: yeah, flicking through a nodejs package.json file, it looks like there's nothing to do that differentiation | 16:11 |
| Zara_ | though then again, there's 'bin' field I just spotted containing the .js file | 16:12 |
| Zara_ | but the package has other .js files that aren't included in the description there | 16:13 |
| persia | Does it work if you only copy that file? | 16:13 |
| *** ssam2 [~ssam2@213.16.35.194] has quit [Remote host closed the connection] | 16:13 | |
| persia | I don't know enough about the format, but that could be an entry point, or it could be a combined file. | 16:14 |
| Zara_ | It 'requires' those things in lib, which aren't listed in the json | 16:15 |
| Zara_ | so I suspect it wouldn't work | 16:15 |
| Zara_ | (the other .js files are in lib, sorry; I wrote that in a confusing way) | 16:15 |
| persia | No worries: you were clear. | 16:16 |
| persia | It sounds like the description specification isn't sufficient to describe the set of files that are needed at runtime. | 16:16 |
| * Zara_ nodes | 16:16 | |
| Zara_ | nods, haha | 16:16 |
| Zara_ | that matches my understanding | 16:16 |
| persia | You should push against the spec and ask upstream to confirm this: if it is the case, then copy everything (and explain why in your patch thread), if it is not the case, you'll learn enough in the process to do it the other way. | 16:17 |
| Zara_ | (well I suppose the spec does describe them, but only because it has fields for the repo, etc, which would include *all* the files) | 16:18 |
| persia | Perhaps the key verb is "differentiate" rather than "describe" :) | 16:19 |
| Zara_ | heh | 16:19 |
| pedroalvarez | Good news: looks like cache.baserock.org can be used again :) | 16:20 |
| jmacs | Running this: lorry --verbose --pull-only openssh.lorry | 16:21 |
| jmacs | I get Warning: Permanently added 'anoncvs.mindrot.org,130.102.96.3' (ECDSA) to the list of known hosts. | 16:21 |
| jmacs | Permission denied (publickey). | 16:21 |
| pedroalvarez | jmacs: are you using a ssh url? | 16:21 |
| pedroalvarez | well, I guess is not git, I don't know if that is also aplicable to other VCS | 16:22 |
| Kinnison | your lorry URI probably needs something like :pserver: in it | 16:23 |
| jmacs | It's the default openssh.lorry | 16:23 |
| jmacs | "url": "anoncvs@anoncvs.mindrot.org:/cvs" | 16:23 |
| Kinnison | odd | 16:23 |
| jmacs | It looks to have lorried successfully on git.baserock.org | 16:23 |
| persia | Are there lorry logs that could describe how that worked? | 16:24 |
| Zara_ | (thanks, persia, that was really helpful and it clarified a lot.:)) | 16:24 |
| persia | Zara_: Good luck. | 16:24 |
| jmacs | openssh.lorry isn't really my problem, but I thought I'd try it as I'm unable to get my own CVS lorry of libpopt to work | 16:28 |
| jmacs | I get a different error for that: http://pastebin.com/0P2068Qi | 16:28 |
| persia | jmacs: Does it work if you run the listed `git cvsimport` command directly? How about if you use cvs directly? | 16:29 |
| straycat | that url doesn't look valid? | 16:30 |
| jmacs | I have cvs cloned that repository, although not on my baserock machine | 16:30 |
| jmacs | I will try a git cvsimport | 16:30 |
| Zara_ | ah, I think the npm issue has been brought up already: https://github.com/npm/npm/issues/5264 | 16:30 |
| persia | My thought is that git might provide a more useful error message, because it seems that lorry is just whining that git doesn't work. | 16:30 |
| straycat | "url": ":pserver:anonymous@rpm5.org:/cvs", there's no protocol there, and it's not an ssh url? | 16:31 |
| jmacs | straycat: Look at libtiff.lorry if you have lorries to hand | 16:32 |
| jmacs | I pretty much copied the other CVS examples | 16:32 |
| jmacs | It says "url": ":pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot" | 16:32 |
| persia | Zara_: Yep. I'd suggest chasing the conversation, and if you can't find a result any other way, asking the originator where they believe consensus ended. It may be that the conversation is still ongoing (so you have justification for your current position in your patch series and a todo), or was resolved in a way not clear from the github issue. | 16:32 |
| straycat | jmacs, huh, okay then | 16:33 |
| jmacs | Heh, tried something else and got "AuthReply: I HATE YOU" :c | 16:34 |
| straycat | ha | 16:34 |
| Zara_ | Reading to the end of that thread, it's been added to the feature request list, and isaacs seems to have accepted that there's enough demand that it should be done at some point (it's listed under 'bikeshedding'). I suspect that the nodejs/iojs fork may have complicated some things upstream. | 16:34 |
| persia | Right. If there isn't already a good patch, submitting one, along with some forks with the relevant fixes for some of the major consumers may be a way to get the conversation restarted | 16:37 |
| persia | If there are patches, you might chase the splitting communities to find out which would be willing to fix this as part of the differentiation (as one of them surely exists to "better serve the needs of modern users", either being the fork, or being the original project with the fork being the conservatives). | 16:37 |
| persia | jmacs: Triple extra points for finding the easter egg! :) | 16:38 |
| bwh | Not quite as good as 'You don't exist, go away!' | 16:41 |
| persia | Zara_: Reading more threads of that discussion, there are some mentions of "build.js": what is this? Is this the normal way to get from source to artifact? | 16:42 |
| Zara_ | build.js is within npm, here https://github.com/npm/npm/tree/master/lib . 'npm install' calls it | 16:46 |
| Zara_ | but npm install does extra stuff, which is why we've been using 'npm build' in the import tool | 16:47 |
| *** a1ex [~Alex@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:51 | |
| persia | Hrm. Right. | 16:55 |
| persia | I'm not sure I understand in detail, but I no longer believe it relevant to the differentiation previously discussed. | 16:56 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:59 | |
| Zara_ | I'll have a look around and research it further. I think I'll be busy with other things next week, but I should be able to make some notes for someone else (or me in the future), so it can be chased up. | 17:01 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:06 | |
| jmacs | git cvsimport of libpopt worked correctly (outside baserock) :( | 17:07 |
| persia | And it breaks inside the devel environment? | 17:14 |
| persia | (raw vs. through lorry) | 17:14 |
| rdale | i have a pile of git repos for gems that i want to add to ruby-gems.lorry, but they aren't in a sort of order, and they may be duplicates of existing repos - is there any easy way of doing a sorted merge? | 17:15 |
| jmacs | I'll find that out in time - it takes a very long time to run a cvs import. | 17:15 |
| *** locallycompact [~lc@253.175.125.91.dyn.plus.net] has quit [Read error: Connection reset by peer] | 17:18 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:27 | |
| paulsherwood | pedroalvarez: i've done the genivi table dance | 17:36 |
| pedroalvarez | paulsherwood: I really appreciate it thanks! | 17:36 |
| paulsherwood | i have a script which does the hard work :) | 17:37 |
| pedroalvarez | paulsherwood: I have the idea of creating fork of definitions for genivi. So we can start putting gpl3 chunks in baserock whenever we want without worrying about it. What do you think? | 17:39 |
| jmacs | git cvsimport of libpopt succeeded on baserock outside lorry. | 17:42 |
| * straycat isn't quite sure why a change to vim requires a rebuild of half the system | 17:42 | |
| persia | jmacs: Excellent. That means that http://pastebin.com/0P2068Qi is purely a lorry error. | 17:42 |
| straycat | Maybe we can move it higher? | 17:43 |
| persia | straycat: Please. | 17:43 |
| persia | jmacs: What locale do you have when it worked? | 17:43 |
| jmacs | Good question | 17:44 |
| jmacs | Nothing set except LANG=en_GB.UTF-8 | 17:44 |
| jmacs | You get the perl warning: Setting locale failed. | 17:45 |
| persia | Which appears to also be set in the error situation. | 17:45 |
| jmacs | But it succeeds. | 17:45 |
| straycat | I guess a dev-tools stratum might make sense: devel system tools that don't have dependants | 17:47 |
| persia | Annoyingly error 128 just means "git failed to close cleanly", but is supposed to have another message explaining the actual problem. | 17:47 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:04 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:12 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:12 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:14 | |
| jmacs | Now lorry works libpopt. | 18:30 |
| jmacs | No idea what changed there. | 18:30 |
| persia | Very odd indeed | 18:34 |
| persia | Maybe a server-side timeout? | 18:34 |
| pedroalvarez | straycat: what about dev-tools being the current tools stratum and make nothing depend on tools? | 18:37 |
| persia | Needs some thought about morph | 18:38 |
| persia | Because different morph can cause things to build differently, and morph is in tools. | 18:38 |
| persia | But I like that idea for all non-morph tools. | 18:38 |
| pedroalvarez | Morph was moved to morph-utils, iirc | 18:41 |
| straycat | pedroalvarez, not sure, sounds like more work | 18:43 |
| paulsherwood | pedroalvarez: the fork sounds like more work too? | 18:44 |
| persia | Why so it was. | 18:44 |
| persia | paulsherwood: In prior discussion, the alternative was to have two copies of many things (from build-essential up) in definitions.git master. | 18:45 |
| * paulsherwood prefers less work | 18:46 | |
| persia | Measuring the work difference between merging changes between two git repos and between two files in a single git repo is mostly a matter of taste | 18:48 |
| paulsherwood | *measuring* work differences seems largely impossible | 18:50 |
| persia | Fair point: rather that in my observation of watching people merge changes, it seems that the amount of effort expended is unlreated to whether they use patchutils or VCS tools, and more closely related to their comfort with one or the other solution. | 18:52 |
| persia | There is some variation in effort depending on the nature of the merge, but the vast majority of merges fall into roughly the same bucket of work effort. | 18:53 |
| paulsherwood | less work if we can find a way to have one soln, rather than 2 | 18:53 |
| persia | From what I understand, the main issue is readline: lots of low-level stuff wants to be built with GPL readline for a GPL system, and non-GPL readline for a non-GPL system. | 18:55 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 19:22 | |
| paulsherwood | right. when we discussed this originally, my understanding was that readline was inherently a developer thing? so shouldn't be on target builds? | 19:28 |
| paulsherwood | (at all?) | 19:28 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:32 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:32 | |
| persia | It depends on what you are building. Nearly anything that has a text-based terminal-like interface uses readline. | 19:37 |
| persia | bash doesn't work properly without it. | 19:37 |
| persia | Lots of frameworks rely on it to provide higher-level text interaction features. | 19:38 |
| persia | For example. Qt prefers to have it present. | 19:38 |
| persia | So while it is possible to construct a system that has no need for readline, it requires making some specialised choices that are inappropriate for many users. | 19:39 |
| persia | If all one wants to do is provide a GUI shell and an app container, where apps have a restricted API, then non-readline is sensible, and many non-GPL targets go in this direction. | 19:39 |
| persia | If one wants to build a more general-purpose system, or anything with a command line-like interface (e.g. the chat feature on many online games), one wants readline. | 19:40 |
| persia | And, for the most part, the users of general-purpose systems are less GPL-averse, so this is not an issue. | 19:41 |
| persia | Unfortunately, Baserock, not being a distro, but rather a distro toolkit, ends up trying to have both. | 19:41 |
| persia | This can be done by forking definitions into GPL-OK and no-GPL, or by forking the files in definitions in the same way. | 19:41 |
| persia | For extra benefit, the non-GPL systems can migrate to libedit or libtecla, which are likely to evolve more usefully than the old readline. | 19:43 |
| *** rdale_ [~quassel@118.Red-193-153-89.dynamicIP.rima-tde.net] has joined #baserock | 19:48 | |
| *** rdale [~quassel@40.Red-83-47-20.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 19:48 | |
| *** rdale [~quassel@11.Red-2-138-206.dynamicIP.rima-tde.net] has joined #baserock | 19:51 | |
| *** rdale_ [~quassel@118.Red-193-153-89.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 19:51 | |
| *** rdale [~quassel@11.Red-2-138-206.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 19:52 | |
| *** rdale [~quassel@2.138.188.122] has joined #baserock | 19:57 | |
| *** rdale_ [~quassel@88.14.146.190] has joined #baserock | 20:01 | |
| *** rdale_ [~quassel@88.14.146.190] has quit [Read error: Connection reset by peer] | 20:04 | |
| *** rdale [~quassel@2.138.188.122] has quit [Ping timeout: 240 seconds] | 20:04 | |
| *** rdale [~quassel@255.Red-83-47-18.dynamicIP.rima-tde.net] has joined #baserock | 20:07 | |
| *** rdale_ [~quassel@91.Red-83-49-216.dynamicIP.rima-tde.net] has joined #baserock | 20:10 | |
| *** rdale [~quassel@255.Red-83-47-18.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:10 | |
| *** rdale [~quassel@116.Red-83-61-40.dynamicIP.rima-tde.net] has joined #baserock | 20:14 | |
| *** rdale__ [~quassel@239.Red-88-8-219.dynamicIP.rima-tde.net] has joined #baserock | 20:16 | |
| *** rdale_ [~quassel@91.Red-83-49-216.dynamicIP.rima-tde.net] has quit [Ping timeout: 272 seconds] | 20:18 | |
| *** rdale__ [~quassel@239.Red-88-8-219.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:18 | |
| *** rdale [~quassel@116.Red-83-61-40.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 20:19 | |
| *** rdale [~quassel@121.Red-83-35-60.dynamicIP.rima-tde.net] has joined #baserock | 20:20 | |
| *** rdale_ [~quassel@97.Red-81-38-117.dynamicIP.rima-tde.net] has joined #baserock | 20:22 | |
| *** rdale [~quassel@121.Red-83-35-60.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 20:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:54 | |
| *** rdale [~quassel@219.Red-83-61-47.dynamicIP.rima-tde.net] has joined #baserock | 21:10 | |
| *** rdale_ [~quassel@97.Red-81-38-117.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 21:11 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 21:31 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 21:31 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 22:43 | |
| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has quit [No Ping reply in 180 seconds.] | 22:48 | |
| *** pedroalvarez_ [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has joined #baserock | 22:49 | |
| Mode #baserock +nt by rajaniemi.freenode.net | 22:49 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Disconnected by services] | 22:50 | |
| genii_ is now known as genii | 22:50 | |
| *** richard_1aw [~richard_m@xvm-21-133.ghst.net] has joined #baserock | 22:51 | |
| *** 64MABRGQB [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 22:53 | |
| *** rjek_ [~rjek@gateway/shell/pepperfish/session] has joined #baserock | 22:54 | |
| *** rjek_ [~rjek@gateway/shell/pepperfish/session] has quit [Changing host] | 22:54 | |
| *** rjek_ [~rjek@gateway/shell/pepperfish/x-pujmdhljfwpubiiz] has joined #baserock | 22:54 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Quit: Coffee time's over, it's probably Beer O Clock.] | 22:54 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 22:55 | |
| *** jmalk [~joshmalki@access.ducie-dc1.codethink.co.uk] has joined #baserock | 22:55 | |
| *** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:00 | |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:00 | |
| *** SotK_ [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 276 seconds] | 23:00 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 276 seconds] | 23:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:01 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:01 | |
| *** robtaylor [~robtaylor@xvm-124-143.dc2.ghst.net] has quit [Ping timeout: 272 seconds] | 23:01 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 272 seconds] | 23:01 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has quit [Ping timeout: 272 seconds] | 23:01 | |
| *** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 272 seconds] | 23:01 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 23:01 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:02 | |
| *** perryl_ [~laurenper@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 264 seconds] | 23:02 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 23:02 | |
| *** doffm [~mdoff@23.226.235.108] has quit [Ping timeout: 264 seconds] | 23:02 | |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:03 | |
| rdale is now known as 17WAAXXVR | 23:04 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:04 | |
| *** rdale [~quassel@219.Red-83-61-47.dynamicIP.rima-tde.net] has joined #baserock | 23:04 | |
| Mode #baserock +v richard_maw by ChanServ | 23:04 | |
| *** straycat [~straycat@fez.tardis.ed.ac.uk] has joined #baserock | 23:05 | |
| *** petefoth1 [~petefothe@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:05 | |
| *** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 23:05 | |
| *** persia [quassel@ubuntu/member/persia] has joined #baserock | 23:05 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 23:05 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:06 | |
| *** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:06 | |
| *** juergbi` [~juerg@vserver.paldo.org] has joined #baserock | 23:07 | |
| *** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:07 | |
| *** JPohlmann [~jannis@m65s13.vlinux.de] has joined #baserock | 23:08 | |
| *** JPohlmann [~jannis@m65s13.vlinux.de] has quit [Changing host] | 23:08 | |
| *** JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #baserock | 23:08 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 23:12 | |
| *** richard_maw [~richard_m@xvm-21-133.ghst.net] has joined #baserock | 23:12 | |
| *** dabukalam [~quassel@ec2-54-69-244-150.us-west-2.compute.amazonaws.com] has joined #baserock | 23:12 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:12 | |
| *** kejiahu [~kejiahu@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:12 | |
| *** ratmice__ [bosshog@nightfall.forlorn.net] has joined #baserock | 23:12 | |
| *** perryl [~laurenper@access.ducie-dc1.codethink.co.uk] has joined #baserock | 23:12 | |
| *** doffm [~mdoff@23.226.235.108] has joined #baserock | 23:12 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 23:13 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 23:14 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 23:14 | |
| *** robtaylor [~robtaylor@xvm-124-143.dc2.ghst.net] has joined #baserock | 23:14 | |
| *** rjek_ [~rjek@gateway/shell/pepperfish/session] has quit [Changing host] | 23:29 | |
| *** rjek_ [~rjek@gateway/shell/pepperfish/x-cbtroxypvinilxdo] has joined #baserock | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!