[02:05] <thomi> fginther: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1259334/comments/1
[02:05] <thomi> let me know if you need anything else.
[07:20] <didrocks> hey cjwatson_, did you confirm bug #1259253 is due to click? if that's the case, are you going to work on a fix so that we can promote an image again?
[07:21] <didrocks> seems indeed, we need a fixed user id for click
[07:51] <popey> didrocks: on irc he said he didn't want to go down the path of fixed UIDs but instead have a hook
[07:51] <popey> let me find it
[07:52] <didrocks> popey: hey! ah ok, I think seeing how people want to see a new promoted image, an ETA will be necessary
[07:52] <popey> didrocks: http://irclogs.ubuntu.com/2013/12/09/%23ubuntu-ci-eng.html#t17:43
[07:52] <popey> ya
[07:54] <Mirv> I wonder if the time from "built" in PPA to becoming published could be shortened. I've an example here of a package finished building 17 minutes ago and still shown in LP as not published.
[07:55] <didrocks> cjwatson_: popey: do you know if reverting would help? Doesn't seem in the code (in fact, this issue is there for a long time I guess), but just checking as I guess this question will be asked to me
[07:58] <popey> Good question didrocks but I don't know what piece of the toolchain caused it to juggle the UIDs.
[08:28] <sil2100> didrocks: https://code.launchpad.net/~sil2100/url-dispatcher/direct_releases/+merge/198343 <- to fix the url-dispatcher changelog
[08:28] <sil2100> didrocks: I also cherry-picked the arch change, was that correct?
[08:28] <sil2100> I mean, correct to cherry-pick it?
[08:28] <didrocks> sil2100: oh, I didn't push push that branch? I though I did
[08:28] <didrocks> sil2100: no, just cherry-pick the changelog
[08:29] <didrocks> sil2100: as per discussion here yesterday, we don't need the arch change
[08:29] <sil2100> Ok, so I'll remove the arch switch
[08:29] <didrocks> thanks!
[08:29] <didrocks> sil2100: then, feel free to push directly
[10:32] <cjwatson_> didrocks: reverting wouldn't help
[10:32] <cjwatson_> didrocks: it's not *due* to click, but click is probably the best place for a fix
[10:32] <cjwatson_> didrocks: and yes, I'm going to work on a fix
[10:33] <didrocks> yeah, what I thought, thanks cjwatson
[11:02] <cjwatson> grump, this is an unhelpful time for my grouper to apparently have trouble charging enough off USB
[11:03] <cjwatson> the emulator doesn't have system-images yet, does it?
[11:12] <xnox> cjwatson: i think we started generating them, but there is no system image upgrade yet.
[11:13] <xnox> cjwatson: in the past jodh did get remote access to a phone. and (reboot recovery / reboot) should work....
[11:15] <jodh> xnox, cjwatson: yeah, thanks to rsalveti.
[11:25] <cjwatson> I should be able to manage
[11:26] <cjwatson> (it seems to be charging off mains OK-ish)
[11:26] <cjwatson> and worst case I can fake something up in the emulator
[11:54] <didrocks> cjwatson: if you need help/testing, I can try on my phone if you have a list of things do try
[12:55] <cjwatson> didrocks: I think http://paste.ubuntu.com/6550937/ should do it - but I should be able to test this in the emulator, I think
[12:58] <didrocks> cjwatson: oh, you are forced to chown the path when starting click, there is no hook at the boot level to keep the uid stable (not fixed, but stable for a given installation)?
[12:58] <cjwatson> even if there were it would still be a change from previous images
[12:58] <cjwatson> the clickpkg user is created with adduser --system as part of the system image
[12:59] <cjwatson> so boot level is too late - the problem is the image has changed
[13:00] <popey> I can test this if someone tells me what I need to do ☻
[13:00] <cjwatson> thanks but not ready yet
[13:00] <didrocks> yeah, not sure if in the long term (not possible for that one), but we should have a file stored across upgrade with user <-> uid (same for groups) and reapply it
[13:00] <cjwatson> well, there's no point storing it across upgrade
[13:00] <cjwatson> like I say, the users are created on the image builder
[13:00] <popey> ok, feel free to ping if/when there's something to test
[13:00]  * popey gets lunch
[13:01] <didrocks> yeah, I get your point
[13:02] <cjwatson> it's only a problem for dynamic system users that'll have files created in userdata, which is hopefully not many
[13:02] <cjwatson> and yeah, this is kind of an unfortunate hack, but at least it's simple
[14:01] <fginther> morning
[14:02] <fginther> sil2100, meeting?
[14:04] <sil2100> fginther: ouch! Though it's next week?
[14:04] <sil2100> Joining
[14:04] <fginther> sil2100, just an update on progress/issues
[14:34] <cjwatson> could I have a landing slot for ask 217 please?
[14:35] <sil2100> Damn, almost burnt my kitchen down
[14:36] <sil2100> Another good reason why I shouldn't cook
[14:36] <sil2100> That's why I'm eating out most of the time as well
[14:37] <cjwatson> (fairly urgently if possible, as I'm told this is a promotion blocker)
[14:38] <sil2100> Let me take a look between bites - I'll add it now
[14:38] <sil2100> didrocks: ^
[14:39] <didrocks> cjwatson: sure, please just do
[14:39] <cjwatson> ok, thanks, uploading
[14:39] <didrocks> (no really need to ask for any promotion blocker)
[14:39] <didrocks> thanks cjwatson :)
[14:40] <sil2100> cjwatson: thanks for the fix! \o/
[14:41] <didrocks> ok, I'll exercise now I guess (only time I can find)
[14:42] <didrocks> time for migrating from proposed to the archive, lool, do you mind kicking up an image build once click is in the release pocket?
[14:42] <didrocks> hey lool btw :)
[14:43] <lool> sure
[14:43] <lool> hey!  :-)
[14:43] <didrocks> thanks!
[14:43] <lool> 0.4.13 I assume
[14:43] <didrocks> lool: correct! :)
[14:44] <didrocks> plars: so we'll need q-jenkins up and operational (if not already) in ~1h30 and all your karma to get image #57 be THE one :)
[14:44] <plars> didrocks: yep, it's ready to go
[14:44] <didrocks> great ;)
[14:45] <lool> cjwatson: ah!  I remember raising this case to stgraber just before vUDS as something we should check in image builds
[14:45] <lool> (UIDs changing across image builds)
[14:46] <lool> I guess we could make it system-image's problem to some extent, albeit scanning all filesystems is a bit tricky; or we could have some special UID remapping thing
[14:46] <cjwatson> I'm not expecting it to be a desperately common thing
[14:47] <cjwatson> so while it's a bit kludgy, it doesn't seem terrible to handle it user-by-user
[14:47] <lool> cjwatson: did we review potential issues with usbmux and dnsmasq uids changing?
[14:47] <cjwatson> trade-off between complexity required to handle it case-by-case and complexity required to be really clever
[14:48] <lool> cjwatson: it's probably fairly easy to fail the image build if etc/passwd changes without a review of the new one as a stop gap to detect the most likely case?
[14:48] <cjwatson> not really because that requires the image builder having a record of the previous image build
[14:48] <lool> we could have that in the image config
[14:48] <lool> expected-passwd-file
[14:49] <cjwatson> which requires somebody keeping track of it, hence more image build failures - I'm not sure it's worth it?
[14:49] <lool> well how will we prevent this from happening in the future?
[14:49] <cjwatson> I don't think this is going to be a common thing
[14:49] <lool> this seems to be a case where just the installation order changed, not even the list of packages
[14:49] <cjwatson> files in userdata with ownership that isn't just an ordinary user are going to be really rare
[14:50] <cjwatson> I don't want to add any complexity for dealing with it until we've seen multiple cases, frankly
[14:50] <lool> cjwatson: but it could be any private files created by daemons etc.
[14:50] <lool> like /var/lib/xyz that we mapped to /userdata
[14:51] <cjwatson> like I say, if we see multiple real (not hypothetical) cases ...
[14:51] <sil2100> fginther: hello! Could you re-paste me the bzr branch again for the docs?
[14:51] <cjwatson> usbmux is used in a udev rule, so won't be persistent across boots
[14:52] <sil2100> fginther: it seems I closed the window that I written it in on
[14:52] <fginther> sil2100, one moment
[14:53] <cjwatson> I think dnsmasq is only actually used by the dnsmasq package which isn't on touch images - it's just created in dnsmasq-base to simplify the maintainer's life
[14:55] <lool> ok
[15:16] <cjwatson> lool: click 0.4.13 is in the archive now per rmadison
[15:16] <cjwatson> in the release pocket, that is
[15:27] <lool> yup, kicking a build
[15:27] <lool> building
[15:33] <fginther> sil2100, lp:ubuntu-ci-services-itself
[16:06] <rsalveti> didrocks: how are we today, can I push ofono & hybris? :-)
[16:07] <rsalveti> it's not even in landing plan yet :-(
[16:07] <rsalveti> added yesterday to the landing asks
[16:09] <lool> didrocks: cdimage image build finished; system-image might still be running
[16:14] <tsdgeos> guys, any idea what's wrong in https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1382/console ?
[16:14] <tsdgeos> seems that it's not getting an ip address?
[16:15] <sil2100> rsalveti: hi! I think we still didn't promote an image, sadly we discovered a big blocker in click that slowed us down
[16:16] <sil2100> rsalveti: a fix is in and released already, but I guess didrocks won't want to land anything new until this is not finally published
[16:17] <rsalveti> sil2100: right, that's fine
[16:17] <rsalveti> hopefully the next image will be the promoted one :-)
[16:27] <popey> rsalveti: as i understood it nothing was going into the image until we're all green
[16:38] <didrocks> rsalveti: I really hope it will be THE one, yeah ;)
[16:38] <didrocks> need to have tests + dogfooding results first
[16:41] <popey> didrocks: when we expecting it?
[16:42] <popey> guess you're waiting on click first?
[16:43] <popey> oh, 57 is built
[16:44] <didrocks> popey: yeah, it's there, waiting on test results now :)
[16:44] <popey> i just reset mine to read-only and realised I now have 57
[16:47] <rsalveti> let me flash 57 :-)
[16:48] <popey> http://popey.com/~alan/phablet/device-2013-12-10-164830.png
[16:48] <popey> the font in the address bar looks odd
[16:49] <popey> kalikiana_: is the font deliberately compressed like that?
[16:51] <kalikiana_> what do you mean by compressed? if this is about font sizing Kaleo is probably the one to ask
[16:52] <popey> the font seems squished compared to previous releases
[16:54] <popey> Kaleo: is this font change intentional? http://popey.com/~alan/phablet/device-2013-12-10-164830.png vs http://popey.com/~alan/phablet/device-2013-12-10-165306.png
[17:19] <popey> didrocks: all green for me aside from location, but just because that takes *ages* to get a lock, so hanging my phone out the window now
[17:20] <didrocks> popey: don't catch a cold!
[17:20] <didrocks> popey: you even tried calling?
[17:20] <popey> yes
[17:20] <popey> both directions
[17:20] <didrocks> (even if I doubt anyone is using a phone like that)
[17:20] <didrocks> \o/
[17:20] <popey> see the https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ai33BkOcORLLdE4xLTFtSE80ZkpITXZ3aV85cWtPX2c&usp=drive_web#gid=0
[17:20] <popey> its all accurate
[17:20] <robru> cyphermox, kenvandine: so for lp:cordova-cli, the deban/copyright file was generated by a script I wrote that searches for and parses package.json files to figure out the copyright. It's not perfect, so some copyright clauses in the file are actually missing. But most of them are good.
[17:21] <didrocks> popey: ah, you are the mako line!
[17:21] <didrocks> :)
[17:21] <popey> ya
[17:21] <cyphermox> ah, that answers my question on #ubuntu-desktop then :)
[17:22] <robru> cyphermox, i didn't use the tool you suggested, I wrote a 10-line python script to scan & report every license it could find
[17:22] <robru> cyphermox, it solved the lintian warning about duplicate fields
[17:23] <robru> kenvandine, cyphermox: http://bazaar.launchpad.net/~cordova-ubuntu/cordova-cli/trunk/view/head:/debian/copyright#L13 but now there's some 'blank' license clauses like this oen
[17:24] <cyphermox> robru: the big problem I have with it is that I'm not sure if it correctly parses as you expect it, as per DEP-5
[17:24] <cyphermox> Multiple Files paragraphs are allowed. The last paragraph that matches a particular file applies to it.
[17:24] <cyphermox> ^ in that sense, some paths match twice or more :/
[17:26] <cyphermox> robru: what license do you expect the blanks to mean? Public domain?
[17:26] <robru> cyphermox, unknown. I expect them to mean "you must manually investigate what license this is, because it could not be programmatically determined"
[17:26] <cyphermox> ok, so stuff that still needs to be done
[17:26] <cyphermox> alright :)
[17:27] <robru> cyphermox, kenvandine: https://gist.github.com/robru/7894514 this is the script I used to generate this file, so you can see it looks for the 'license' key inside package.json, and failing that it tries some heuristics on a 'LICENSE' file in the same directory as package.json, but it doesn't always work out
[17:28] <robru> cyphermox, kenvandine: so there are 744 lines in debian/copyright (not counting license texts), so I say we just split it up into 248-line chunks and each focus on a separate area
[17:29] <kenvandine> wow... what a beast!
[17:29] <robru> kenvandine, you can do lines 0-248, cyphermox you can do 248-496, and then I'll do the rest
[17:29] <kenvandine> ok
[17:29] <robru> kenvandine, it's the node.js way! :-/
[17:30] <cyphermox> robru: how did you deal with the jshint licensing problem? evil json license?
[17:30] <robru> cyphermox, haven't looked at it yet. not very familiar with that issue.
[17:30] <cyphermox> ok
[17:30] <cyphermox> that was the lintian warning cordova-cli source: license-problem-json-evil node_modules/cordova/node_modules/jshint/src/stable/jshint.js
[17:31] <cyphermox> I'll look into it, seems like it's part of my lines too :)
[17:31] <cyphermox> I'll need to search through debian-devel to get background info on it
[17:31] <robru> oh, the 'do no evil' clause. fuck, that clause itself is evil.
[17:43] <kenvandine> wow, there is no sign of any sanity in this source
[17:45] <robru> kenvandine, nope! but what you're seeing is how the npm tool installs modules, so this is the officially sanctioned node.js way of doing business.
[17:46] <robru> kenvandine, cyphermox: shit, I actually found one that doesn't have a license. What do we do with this?
[17:47] <kenvandine> strip it out?
[17:47] <kenvandine> i found one that has no source... it's just a package.json file
[17:48] <kenvandine> bundlerecurs
[17:48] <cyphermox> hehe
[17:49] <cyphermox> robru: do you see a license file anywhere? or license info in the files?
[17:49] <cyphermox> robru: otherwise you'll need to look online to see if there's any way you can figure out what license it really should be... and if it can't be found, it will need to be removed
[17:49] <kenvandine> one i found no reference for a license, but when i went to the url linked in the json file, there had been a license file added in master :)
[17:50] <robru> kenvandine, so it turns out a lot of them are actually dummy no-op packages that are part of the npm test suite. I would just delete all the stanzas that match files under */npm/test/*, assume they're licensed the same as npm.
[17:50] <kenvandine> i've now found 2 that have nothing really
[17:50] <kenvandine> they are in disabled dirs
[17:50] <cyphermox> assuming you find the same files/project online with a license then you'd likely need to update to use those files rather than the ones you already have, since the licensing may have changed due to changes in the file
[17:50] <robru> kenvandine, yeah, I found at least 10 like that, just delete the stanza
[17:50] <kenvandine> they are under npm/test/disabled/
[17:50] <kenvandine> ok
[17:51] <robru> cyphermox, yeah, for range-parser, I did 'grep -iR copy' and 'grep -iR licen', it came up with nothing. no mention of licensing in the readme, or in any source files
[17:52] <cyphermox> robru: ok, I'll take a look too just in case, but it probably will have to be removed
[17:52] <cyphermox> robru: btw I haven't started with my lines just yet, will soon though
[17:52] <robru> cyphermox, oh yeah, upstream git seems to mention MIT license
[17:52] <cyphermox> I'm trying to finish testing an update of ModemManager first
[17:52] <cyphermox> any email in the project file or something?
[17:53] <cyphermox> we could also email the author to find out for sure
[17:54] <cyphermox> I hope the new MM makes the remainder of my non-working modems work :)
[17:56] <robru> cyphermox, https://github.com/visionmedia/node-range-parser#license here we go, yeah MIT
[17:56] <robru> cyphermox, kenvandine: ok I did my section and pushed to trunk already.
[17:57] <kenvandine> robru files: */cli/* is ambiguous
[17:57] <kenvandine> it's under jshint and ripple-emulator
[17:57] <kenvandine> different source
[17:58] <robru> kenvandine, hrm. I guess split it into two stanzas, one saying */jshint/*/cli/* etc?
[17:58] <kenvandine> and there is a */ripple-emulator/* and */jshint/* already
[17:58] <robru> kenvandine, oh, in that case just drop */cli/* then, assuming it's licensed the same as the parents?
[17:58] <kenvandine> ah, the license/copyright matches for ripple-emulator
[17:58] <kenvandine> so i guess i just need to make this jshint/cli
[17:59] <robru> kenvandine, yeah, the key there is that the jshint one is jshint/node_modules/cli, which means that cli is a different module that jshint depends on. The other ones are like npm/doc/cli, it's part of the npm package.
[18:04] <robru> kenvandine, how were you checking for ambiguity?
[18:04] <robru> (I've just been trying to find licensed for ones that were missing, I wasn't confirming the ones that were already listed)
[18:05] <kenvandine> find . -type d -name FOO
[18:05] <kenvandine> and looking in the sources of all the results
[18:05] <cyphermox> right
[18:08] <kenvandine> found one where the author isn't the in the copyright of the actual source, someone else is
[18:08] <robru> kenvandine, awesome.
[18:08] <cyphermox> robru: didn't you expect this for js stuff?
[18:09] <cyphermox> it's typically stuff that people don't think will get reused and don't bother licensing until much later
[18:09] <robru> cyphermox, well, I dunno, somebody at some point decided to bet the entire company on this so I was expecting it was going to be a little bit more professional.
[18:10] <cyphermox> ahah :)
[18:10] <cyphermox> isn't cordova backed by this large company too?
[18:11] <cyphermox> or was it something else you showed me related to cordova?
[18:12] <robru> cyphermox, well it started out as Adobe PhoneGap, but I guess Adobe dropped it? It's just 'Apache Cordova' now.
[18:12] <kenvandine> adobe
[18:12] <cyphermox> robru: also, you should know the desktop team motto:  "Nor rain, nor sleet, nor poorly licensed, humongous monstrosity projects will stop this software engineering from doing his job"
[18:12] <cyphermox> ;)
[18:12] <robru> cyphermox, haha. it's not stopping me! it's just a huge mess
[18:13] <cyphermox> I agree
[18:13] <robru> cyphermox, I guess certain release team members will faint when they see this ;-)
[18:13] <cyphermox> but we'll get though it :)
[18:13] <cyphermox> yeah
[18:13] <cyphermox> or run screaming
[18:13] <robru> cyphermox, i mean, the package upload is going to be one thing, but the MIR is going to be the very definition of Fun.
[18:13] <cyphermox> ahahha
[18:13] <cyphermox> you want to MIR this too?
[18:14] <cyphermox> :D
[18:14] <robru> cyphermox, yeah, of course! it's part of the convergence strategy! this is like the core runtime for cross-platform phone apps, it has to be part of the system by default and it has to be part of the desktop too ;-)
[18:15]  * cyphermox doesn't know if he should cry or laugh, opts to LOL for a while
[18:15] <robru> cyphermox, maybe the MIR can wait for next cycle...
[18:16] <robru> cyphermox, personally my feeling is that we should not bother MIR'ing phone stuff into the desktop. we should just get the phone images to the point where they can run on desktops nicely, and then just drop the entire desktop seed entirely. MIR'ing everything seems like a ton of extra paperwork for nothing.
[18:17] <cyphermox> well, there's an usefulness to it
[18:17] <cyphermox> it also serves to assess we can support that stuff for a while without too much loss of sanity, and not too high a body count
[18:18] <robru> cyphermox, oh, actually, i just realized: this is just the developer tool, not the runtime. so this part doesn't need to be MIR'd. and I guess the runtime doesn't need to be MIR'd either because the official plan is to just to have each click package vendor it's own runtime.
[18:19]  * robru breathes a huge sigh of relief
[18:20] <cyphermox> guess it's just slightly less horrible that way
[18:20] <kenvandine> yikes... "*/examples/* matches tons
[18:21] <robru> kenvandine, oops. Probably most of those match parent packages?
[18:22] <robru> kenvandine, "find -type d -path '*node_modules/examples*'" matches none, so I guess just delete that stanza
[18:22] <kenvandine> whew
[18:22] <robru> kenvandine, in fact, maybe I should strip those from the packages...
[18:24] <cyphermox> what do you mean?
[18:25] <cyphermox> oh, the examples
[18:25] <cyphermox> yeah, esp if that reduces the binary size by a bunch, it could be a win
[18:27] <robru> cyphermox, yeah, just checking what the size reduction is
[18:29] <robru> cyphermox, mmm, negligible (on the order of kb's). 'du -cha' reports the size as '11M' with or without the examples.
[18:29] <cyphermox> boo
[18:34] <kenvandine> the copyright policy says public-domain isn't subject to copyright
[18:34] <kenvandine> but Copyright is a required field
[18:35] <kenvandine> i guess i just put public-domain there too
[18:36] <robru> kenvandine, which is public domain?
[18:36] <kenvandine> cycle
[18:37] <robru> kenvandine, does that package excplicitly say public domain? because that's different than if it says nothing.
[18:38] <kenvandine> the source does
[18:38] <cyphermox> yeah we just write public-domain in that case
[18:38] <cyphermox> http://dep.debian.net/deps/dep5/
[18:41] <kenvandine> robru, actually online it says public domain
[18:41] <kenvandine> but the version from npm doesn't
[18:41] <kenvandine> otherwise the source seems the same
[18:43] <kenvandine> lp:~ken-vandine/cordova-cli/licenses
[18:43] <kenvandine> robru, ^^
[18:43] <kenvandine> robru, i left one as FIXME
[18:43] <kenvandine> i couldn't find anything
[18:45] <robru> kenvandine, whoa, 1986? for real?
[18:45] <kenvandine> yup
[18:45] <kenvandine> :)
[18:45] <kenvandine> and 1989
[18:45] <robru> kenvandine, impressive to have written javascript back then...
[18:46] <cyphermox> javascript didn't exist back then
[18:48] <cyphermox> that's pretty cool still :)
[18:49] <robru> kenvandine, merged, thanks. just waiting on yours, cyphermox. I'm out for breakfast, brb
[18:49] <cyphermox> robru: ack
[19:24] <robru> cyphermox, kenvandine: back
[19:28] <cjwatson> so did that last image work out to be promotable?
[19:29] <cjwatson> everything sounded good earlier but it's not in trusty yet
[19:29] <popey> cjwatson: tests still running
[19:30] <popey> looks good but not 100% http://ci.ubuntu.com/smokeng/trusty/touch/
[19:30] <popey> (yet)
[19:32] <cjwatson> improvement over 32?
[19:34] <popey> yes, absolutely
[19:34] <popey> 88/85% vs 97/93%
[19:34] <cjwatson> right, but most images since 32 have been numerically better
[19:35] <cjwatson> so I guess we aren't just doing a ratchet?
[19:36] <cjwatson> and more failures than 56
[19:43] <popey> i suspect the failures are dodgy tests which sometimes fail, sometimes  pass
[19:43] <popey> so we have to re-run them
[19:54] <robru> cyphermox, have you started the copyright work yet? if you're busy with other things maybe I'll just do it.
[19:55] <cyphermox> working on it as we speak
[19:55] <cyphermox> just being thorough
[20:00] <robru> cyphermox, ok no worries.
[20:00] <robru> cyphermox, thanks
[20:01] <cyphermox> I'm still concerned by the structure, though
[20:02] <cyphermox> like, the stanzas in debian/copyright although machine-readable, they're not machine-checkable, I think
[20:03] <cyphermox> because in theory the last match for a file is what applies, I think it's possibly wrong
[20:03] <cyphermox> but so far the data is correct though
[20:03] <robru> cyphermox, I'm not sure what you mean. What change would be necessary to fix it?
[20:04] <robru> cyphermox, the intention was that the stanzas should match loosely, because npm vendors in the same projects multiple times.
[20:04] <cyphermox> rewriting to not just list */$project/* but rather possibly listing each of the instances of the project in subdirectories together
[20:04] <cyphermox> yeah
[20:04] <cyphermox> I understand the intention, it's correct
[20:05] <cyphermox> I just want to check that it will pass review so we don't do this insanity twice :)
[20:05] <robru> cyphermox, the problem with using absolute paths is that it's possible it might change at any given time.
[20:05] <cyphermox> yeah
[20:05] <cyphermox> the repetition of the same package and versions is pretty insane
[20:06] <cyphermox> I wish there was a better way to handle this, but there isn't really one besides removing everything, and reorganizing everything in a flat directory tree with the version numbers and symlinking the hell out of it
[20:06] <cyphermox> that's assuming even that there were no changes in the files in node_modules for some projects
[20:07] <robru> cyphermox, my understanding is that the reason all the modules are duplicated is because different versions are being depended upon.
[20:07] <robru> cyphermox, although if there was an automated way for checking duplicated modules and de-duplicating them, I would be all for reducing it.
[20:08] <cyphermox> yeah
[20:08] <cyphermox> it doesn't exist yet
[20:08] <cyphermox> though it's possible for all the projects that have a project.json
[20:08] <cyphermox> but let's get this to work in the first place. I'm about halfway done I think
[20:08] <robru> cyphermox, my understanding of the node.js module loader is that it just progressively looks further and further up the path, so eg if you had node_modules/foo and node_modules/bar/node_modules/foo that were the same, you could just delete the second one, and it would all still work because it would find the first one instead.
[20:09] <robru> cyphermox, well it does "work" in the sense that you can install it, and /usr/bin/cordova runs as expected.
[20:09] <cyphermox> not sure
[20:09] <cyphermox> the versions might differ
[20:10] <robru> cyphermox, yeah, that's what I mean. if it turned out that the versions were the same, you could just delete the one with the deeper path, and whatever was depending on it would seamlessly find the higher-up one.
[20:12] <robru> cyphermox, not sure how we'd check that though. we'd have to scan the whole thing to create a list of every possible node module, and then we'd have to iterate over every pair of same-named modules, and then diff them, and if there was any difference we'd have to preserve them.
[20:13] <cyphermox> yeah
[20:14] <cyphermox> that's why I mentioned reorganizing in a new structure with version numbers and symlinking to the right one where it's used
[20:14] <robru> cyphermox, god, what a nightmare.
[20:14] <cyphermox> that way "deeper" paths would still get the right version with less duplication
[20:14] <cyphermox> and yeah, also why I say let's just make it work for now ;)
[20:14] <cyphermox> as is, I mean
[20:15] <robru> cyphermox, looks like 334 total node modules, 135 unique ones.
[20:15] <robru> cyphermox, (the previous numbers I PM'd you were based on package.json files which it turns out has a lot of false positives due to testsuites. these numbers are based on 'folders under node_modules', much more accurate)
[20:18] <robru> cyphermox, interesting! so just as a random check, it does look like plist module is duplicated bit-for-bit identically.
[20:18] <robru> cyphermox, I think I will write a short script for identifying duplicates and eliminating them, see if it works
[20:20] <cyphermox> ok
[20:27] <cyphermox> so, how useful is jshint to cordova again ? :)
[20:31] <robru> cyphermox, no idea. something brings it in.
[20:32] <robru> cyphermox, I just tried using cordova with the duplicated plist removed, and it seems to be working. you could try deleting jshint and then try to use cordova and see if it breaks (build your own package locally)
[20:32] <robru> cyphermox, i'll send you the instructions for running cordova
[20:32] <cyphermox> thanks
[20:33] <cyphermox> I still need to look some more into it (will as soon as I finish the rest) but it really does look to me like it absolutely cannot be shipped
[20:34] <robru> cyphermox, well... can't be shipped in debian, right? surely we can get away with it?
[20:41] <robru> cyphermox, ok, instructions setn
[20:57] <cyphermox> robru: nope
[20:57] <cyphermox> if it can't be shipped in Debian it can't be in main or universe
[20:57] <cyphermox> that does still leave restricted/multiverse, *maybe* but I don't know the details about those
[21:01] <robru> cyphermox, alright
[21:02] <cyphermox> seems like there maybe is a reimplementation of jsmin in libv8
[21:02] <cyphermox> so I'm assuming there's possibly a way to reimplement jshint in a way that is alright
[21:02] <robru> cyphermox, so I was just able to identify 41 cases of two node modules being *identical*, i think that's a strong case for adding deduplication.
[21:03] <cyphermox> I recon a license "I don't care" means public-domain.
[21:03] <cyphermox> ok
[21:08] <robru> cyphermox, http://paste.ubuntu.com/6553190/ ;-)
[21:09] <cyphermox> version numbers?
[21:09] <robru> cyphermox, those pairs were identified by running 'diff -rq' on them, which means they are bit-for-bit *identical* across all files in all subdirectories.
[21:10] <cyphermox> ok
[21:11] <cyphermox> then it would be good if your script could also extract the version number from package.json
[21:11] <cyphermox> because within these "pairs" you're likely to have pairs of the same project name but different version numbers
[21:11] <cyphermox> at least, I manually identified 7 or so copies of one of the projects in my list
[21:12] <cyphermox> 2 of which where one version, and others were 2 other versions
[21:12] <robru> cyphermox, right. that's why I run 'diff -rq'. it confirms that they are completely identical, right down to every typo in every comment. there are *no possible differences*
[21:13] <cyphermox> yes
[21:13] <cyphermox> the version numbers are still important, otherwise you still won't be able to differentiate things. or it would just be ad-hoc replace where you can
[21:13] <cyphermox> that wouldn't be much cooler, it would still make it a lot of manual work for you
[21:14] <robru> cyphermox, i don't understand what you're even talking about. the version numbers are defined within package.json, and package.json is *in the directory*, which is *confirmed to be identical*
[21:14] <robru> cyphermox, they can't possible be different versions because that would show up in the diff
[21:14] <cyphermox> yes
[21:14] <cyphermox> hold on, I'll grab an example
[21:18] <cyphermox> so inherits looks like a pretty good example
[21:19] <cyphermox> your script has identified a bunch of duplicates
[21:19] <cyphermox> within these groups, it would still be good to know the version number so for once you can know that those are all duplicates of the same version
[21:20] <cyphermox> but then it becomes even more useful if you want to take this one step further and factor out any further duplication: take the other copies of different versions of inherits out in the same way
[21:20] <cyphermox> so I'm just suggesting things here -- you're the maintainer so you get the last word ;)
[21:21] <cyphermox> I'm thinking a structure parallel to cordova/node_modules that has <nodule>/<version> and symlinking that to wherever that nodule is being used
[21:22] <cyphermox> that way you know for sure that you only have one copy of each nodule and version, and just add a symlink in the right location if project XYZ suddently grows a dependency on ABC
[21:27] <robru> cyphermox, hmmm, ok. I like the idea of flattening the heirarchy, that does simplify a lot of the logic of trying to navigate this web of duplicate-pairs
[21:28] <cyphermox> still, it's going to be painful to do it the first time anyway
[21:28] <cyphermox> and I'm not sure how well it would be seen to do too much frankensteining of a project
[21:28] <robru> cyphermox, well, I'll just write a script that does it. in fact, the script I have for finding dupes is already halfway there, since it builds a dict of the locations of all nodules. ;-)
[21:28] <cyphermox> unless cordova is already just about nothing and you pulled everything else manually
[21:29] <cyphermox> in which case I am amazed that you did, and sad for you ;)
[21:29] <robru> cyphermox, the branch as it appears is almost entirely pristine; it's a dump of exactly how npm installs the nodules. the only 'work' i did can be seen under debian/ (particularly debian/rules, which shows exactly how node_modules directory is created)
[21:31] <robru> cyphermox, ok, I'm gonna do this heirarchy flatting thing, it's the only sane way to handle deduplication I see. but first I'm gonna break for lunch. can you MP your copyright fixes for now?
[21:31] <cyphermox> once I'm done yeah
[21:31] <cyphermox> sorry it's taking me forever
[21:31] <robru> cyphermox, haha, no worries.
[21:31] <cyphermox> before you do deduplication let's discuss this in #ubuntu-release?
[21:32] <cyphermox> just to not start it if they think we shouldn't bother, discuss options, etc.
[21:32] <robru> cyphermox, well I can't see the release team preferring a package that contains two of every vendored module...
[21:34] <cyphermox> hehe
[21:34] <cyphermox> me neither, but maybe symlinks aren't great either :)
[21:52] <robru> cyphermox, so I haven't created the symlinks yet, but here's what the flat list looks like with version numbers: http://paste.ubuntu.com/6553399/
[21:54] <robru> cyphermox, it's depressing how many have 3 or 4 different versions
[21:54] <cyphermox> yeah
[21:54] <robru> cyphermox, "yes, we need at least 4 different versions of the library that parses version numbers"
[21:55] <robru> (semver)
[22:25] <cyphermox> robru, check out the homepage link for ./node_modules/plugman/node_modules/npm/test/packages/npm-test-platform/package.json
[22:26] <robru> cyphermox, wow, how relevant and informative!
[22:26] <cyphermox> or you know, any other of the npm tests :)
[22:26] <cyphermox> npm-test-private is really informative too
[22:29] <cyphermox> (my feeling about cordova in general)
[22:30] <robru> cyphermox, is it wrong that I like Rick Astley? I always watch the whole video whenever somebody rickrolls me.
[22:30] <cyphermox> hahaa
[22:30] <robru> I love the dancing bartender. he's so funny! the first shot of him, he's not sure he likes Rick. Kinda gives a questioning snarl. But then he starts doing backflips!!
[22:54] <cyphermox> robru: https://code.launchpad.net/~mathieu-tl/cordova-cli/copyright/+merge/198475
[22:54] <robru> cyphermox, thanks!
[22:55] <cyphermox> and now I'm going offline to have dinner
[22:55] <cyphermox> bbl