| fta | tb3 unpacked is ~421M | 00:00 |
|---|---|---|
| fta | 62M packed | 00:01 |
| directhex | openoffice.org_3.0.0~rc2.orig.tar.gz 325,498.7 kB | 00:04 |
| directhex | openoffice.org_3.0.0~rc2-1.diff.gz 81,851.0 kB | 00:04 |
| directhex | 82 meg diff. | 00:04 |
| asac | ha ;) | 00:04 |
| asac | though i think the diff isnt really a diff ;) | 00:05 |
| asac | its more like a second overlaying upstream tarball + various patch systems patched in the orig ;) | 00:05 |
| asac | in short ... messy thing ;) | 00:06 |
| directhex | yeah, they're welcome to it | 00:07 |
| directhex | all i know is i'm under orders not to break the teeny tiny mono build-dep it has | 00:07 |
| fta | asac, if we don't do something, we'll end up with those 62M tarballs everywhere, even for lightning | 00:07 |
| asac | fta: see ... it can always be worse ;) | 00:07 |
| asac | and people really complain that our embedded tarball layout is difficult | 00:08 |
| asac | ;) | 00:08 |
| asac | fta: i have a plan ;) | 00:09 |
| asac | fta: most likely we will loose more than we win though ;) | 00:10 |
| fta | ? | 00:10 |
| asac | fta: the idea is to put complete hg snapshot into a heavily compressed hg-mozilla-sources-all_all.deb | 00:11 |
| asac | fta: and put a build dependency on that and then checkout the right tag or whatever for firefox/tbird/lightning, etc. :) | 00:11 |
| fta | ok, something like my sdk/build-system.tar.gz | 00:12 |
| asac | quite a scary thought though ;) | 00:12 |
| asac | fta: no. something like mirror/hg.mozilla.org/mozilla-central,comm-central,etc. | 00:12 |
| asac | :) | 00:12 |
| asac | or just | 00:13 |
| fta | i see... | 00:13 |
| asac | fta: no. something like mirror/hg.mozilla.org.tar.lzma | 00:13 |
| asac | but i think thats not really a good idea either :( | 00:13 |
| asac | most likely we just have to accept and try to work for the future | 00:13 |
| fta | the idea is similar, i unpack sdk/build-system.tar.gz at build time in prism & fennec | 00:14 |
| fta | well, a full mirror is ugly | 00:15 |
| asac | right. but this is about a hg checkout during build time ;) ... and the size is in other spheres too ;) | 00:15 |
| asac | fta: you cannot do not a full mirror, because the products have individual tags etc. | 00:15 |
| asac | but well | 00:15 |
| asac | maybe it would be doable, but sounds hard | 00:16 |
| asac | e.g. on every upload for product that is part of the grant-super-source.deb we would have to include exactly those snapshots that are needed by all the versions in the archive ;) | 00:16 |
| asac | and upload that package for each and every release | 00:16 |
| asac | i doubt that this is a win ;) | 00:16 |
| asac | another idea would be to enable hg mirrors in launchbpad and allow builds to get files from launchpad bzr trees ;) | 00:17 |
| asac | but well | 00:17 |
| asac | given that this is all a problem which has to be resolved at some point i am not confident we should do anything | 00:17 |
| fta | the old cvs mozclient way was better | 00:20 |
| fta | maybe i should add that back to our mozclient | 00:21 |
| fta | post co filter | 00:21 |
| fta | as hg is too dumb to let me do it before co | 00:22 |
| asac | how much "unused" garbage do you expect to be in that all-central tarball? | 00:23 |
| asac | *sigh* .. seems i have to wait for another import run of launchpad to grab some recent bug fixes for NM | 00:31 |
| asac | oh no. lp is going down for maintenance :( | 00:48 |
| crimsun | yeah, the timing is spectacular | 00:48 |
| asac | sensible-maintenance | 00:49 |
| asac | [reed]: can you connect to WPA-EAP with wpasupplicant manually? | 00:57 |
| [reed] | asac: I will try later | 02:14 |
| saivann | asac : What is the deadline for ubufox translations? | 05:15 |
| cwillu | ff3.1 beta: is it still crashy? | 07:33 |
| * cwillu figures on getting a more intelligent answer here then elsewhere :p | 07:33 | |
| jtv | asac, ping | 09:06 |
| fta | cwillu, it's not crashing for me | 09:07 |
| fta | asac, nice boost! http://www.sofaraway.org/ubuntu/tmp/karma.png | 09:21 |
| asac | fta: yeah ... i did a hell of bugwork the last days ;) | 09:42 |
| asac | jtv: ^^ | 09:42 |
| jtv | asac: hi, Arne tells me there's a problem with ff translations? | 09:43 |
| asac | jtv: yes. the template was again forgotten | 09:43 |
| asac | jtv: e.g. we are back to 3.0~b1 | 09:43 |
| asac | beta | 09:43 |
| asac | e.g. to the state that was originally released to hardy | 09:43 |
| asac | jtv: in hardy and only firefox-3.0 that is | 09:43 |
| asac | jtv: we should really look into this. appears to be a general issue with security updates somehow | 09:43 |
| jtv | asac: probably because we don't have a date check on XPI files. | 09:44 |
| asac | a date check? | 09:44 |
| jtv | asac: so we can't see when we're getting an outdated file. | 09:44 |
| asac | jtv: why would you get an outdated file? | 09:44 |
| asac | jtv: the one we now get exported is a year old or so ;) | 09:45 |
| asac | the last uploaded was like 3 weeks ago | 09:45 |
| asac | jtv: for me it seems that the security uploads are somehow rejected | 09:45 |
| jtv | asac: when Ubuntu releases a security update, it probably also feeds the upstream translation files back into Rosetta. | 09:45 |
| asac | but that cant be all | 09:45 |
| asac | on top rossetta appears to forget about the last used too | 09:46 |
| jtv | asac: last-used what? | 09:46 |
| asac | e..g before the last security upload we clearly had 3.0.1 in the export | 09:46 |
| asac | but now we have 3.0 again | 09:46 |
| asac | jtv: we dont upload translations from the firefox package (yet) | 09:46 |
| asac | only the template | 09:47 |
| asac | jtv: i can probably fix taht by manually uploading the new template. but i remember that i did that a few month ago too and would love to see that this is actually investigated ;) | 09:48 |
| jtv | asac: going much too fast here... let's make sure I understand the problem first. | 09:48 |
| asac | well investigate == someone has an idea where this might come from and we know what to do to prevent that at somet point | 09:48 |
| asac | jtv: yeah sorry. | 09:48 |
| jtv | You're saying that an outdated template made its way into the Firefox-3 translations in Intrepid? | 09:48 |
| asac | jtv: give me a few minutes. i need to get coffee. then i will probably talk more comprehensible things ;) | 09:48 |
| jtv | Coffee! | 09:49 |
| jtv | That's an idea. | 09:49 |
| asac | jtv: no ... and outdated template that was previously imported came back | 09:49 |
| asac | we imported a new template through security ... and that triggered something that made launchpad fallback to an old template | 09:49 |
| asac | at least for the export en-US.xpi | 09:49 |
| jtv | asac: "no... and"? Or "no... an"? | 09:49 |
| asac | jtv: "no ... an" | 09:50 |
| * asac goes in the kitchen | 09:50 | |
| * jtv takes care of his own coffee | 09:50 | |
| jtv | asac: I have a standup meeting now... will talk later, when my coffee is cold or inside me | 10:00 |
| asac | jtv: hehe | 10:00 |
| asac | jtv: yeah go for it | 10:00 |
| asac | i just noticed that archive is still open so i would like to do a few more uploads until this becomes a real pain | 10:01 |
| asac | jtv: ping me when your meeting is done | 10:02 |
| jtv | asac: ok | 10:03 |
| asac | fta: where is this stat about the total packages uploaded? | 10:11 |
| asac | fta: could you also provide a split graph for the karma? :-P | 10:29 |
| asac | or doesnt lp api offer that yet? | 10:29 |
| asac | https://edge.launchpad.net/~asac/+karma | 10:30 |
| === asac_ is now known as asac | ||
| jtv | asac: I've had coffee. Should I make more? | 11:31 |
| asac | jtv: probably :) | 11:33 |
| asac | wait another sec please ;) | 11:33 |
| asac | jtv: ok seb is gone. lets talk ;) | 11:33 |
| jtv | Hope seb didn't hear that. :-) | 11:33 |
| asac | jtv: let me give a short description of the symptoms (i think maybe thtas not understood) | 11:33 |
| jtv | Yes please! | 11:33 |
| jtv | But slowly, and please give me time to interrupt with annoying questions. | 11:34 |
| asac | jtv: plain and simple: the distribution export we are getting has an old en-US.xpi | 11:34 |
| asac | old == even older than the one that was available in the 9th sep | 11:34 |
| jtv | "the" distribution export being the one for Intrepid? | 11:34 |
| asac | e.g. on 9th sep the en-US.xpi had the version "3.0.1" | 11:35 |
| jtv | And "distribution export" being the language pack? | 11:35 |
| asac | jtv: sorry. this is "hardy" only. | 11:35 |
| jtv | Oh | 11:35 |
| asac | jtv: yeah | 11:35 |
| asac | cont: the current export has the version 3.0 | 11:35 |
| asac | jtv: what happened in between: a security update which uploaded a en-US.xpi with version 3.0.3 | 11:36 |
| asac | dont know if something happened on launchpad side obviously ;) | 11:36 |
| jtv | And you really see the new strings disappearing, right? In which case it's not just the header that's wrong. | 11:36 |
| jtv | Well, _something_ must have happened on the Launchpad side! Templates don't just revert themselves. | 11:36 |
| asac | jtv: no. i dont know about the strings. all i see is that the exported en-US.xpi is old. I cant see more because the install.rdf generated from it doesnt allow the langpacks to be used with our firefox | 11:36 |
| asac | jtv: well. an upload happened from security i guess | 11:37 |
| asac | or maybe it didnt happen | 11:37 |
| asac | jtv: e.g. maybe launchpad is confused because -updates has a package version for which it never received a en-US.xpi upload? | 11:37 |
| asac | jtv: if you think for a moment you might remember that we had this exact issue a while back. i fixed it by manually reuploading the en-US.xpi when i was in canada | 11:38 |
| jtv | asac: the Translations infrastructure isn't even aware of a difference between updates and main or universe or whatever. | 11:38 |
| asac | jtv: yes. but something must make launchpad forget about the last used en-US.xpi | 11:38 |
| asac | jtv: and its only firefox | 11:38 |
| asac | not xulrunner | 11:38 |
| asac | its really strange | 11:38 |
| jtv | Simply uploading an outdated en-US.xpi will do exactly this. | 11:38 |
| asac | jtv: yes. but we dont upload an outdated en-US.xpi | 11:39 |
| jtv | But it might also be possible that the metadata (install.rdf) is simply not updated. | 11:39 |
| asac | jtv: maybe. howver, it doesnt explain why we go backwards by each upload. falling back to some package | 11:39 |
| jtv | Any chance that Soyuz decided to upload an outdated en-US.xpi? | 11:39 |
| asac | no. we dont build such old packages anymore | 11:40 |
| jtv | So the metadata does change? | 11:40 |
| asac | and without a build there will be no upload | 11:40 |
| jtv | I mean, you get a different install.rdf than what you did previously? | 11:40 |
| asac | jtv: what do you mean with meta data? | 11:40 |
| asac | jtv: well. the en-US.xpi exported suddenly is older than what was exported before ... that means that the exported install.rdf moves backwards | 11:41 |
| jtv | So we know that it's not that it's not being updated. | 11:41 |
| asac | while either _nothing_ is imported or the imported install.rdf moves forward | 11:41 |
| asac | jtv: well. i wouldnt say so. maybe nothing gets uploaded | 11:41 |
| asac | jtv: but still the install.rdf moves backwards :/ | 11:42 |
| asac | jdstrand: are you there? | 11:42 |
| jtv | If nothing gets uploaded, there's pretty much no way for Rosetta to find the old install.rdf! | 11:42 |
| asac | jtv: well. dont you have a history or something? | 11:42 |
| asac | jtv: can you look on the servers and see what en-US.xpi you have physically on the filesystem/database? | 11:42 |
| jtv | asac: only the raw files, in the Librarian. But the actual database doesn't keep a history of this. | 11:43 |
| asac | jtv: because if you say that you dont keep the old en-US.xpi, then it probably means it must be something on the soyuz/dak side | 11:43 |
| asac | (which i wouldnt rule out at this point) | 11:43 |
| jtv | Come to think of it... no, once replaced, the old en-US.xpi just disappears from the system. No history at all. | 11:44 |
| asac | jtv: can we find out with which import you got the en-US.xpi that is now exported? | 11:44 |
| jtv | asac: I can try... | 11:44 |
| asac | that would be helpful | 11:44 |
| asac | i would like to identify which package upload that is | 11:44 |
| jtv | asac: looking... this will take a few minutes. | 11:44 |
| asac | and what was special about that | 11:44 |
| asac | which hopefully gives us better indication whats going on | 11:45 |
| jtv | asac: oh, the *package* upload... that's harder. | 11:45 |
| jtv | asac: doable, but some serious effort. | 11:45 |
| asac | jtv: dont you keep logs of what gets uploaded? | 11:45 |
| asac | maybe we could get something out of that ... even if the form might be not-perfect | 11:45 |
| jtv | asac: not in Rosetta, though Soyuz might know. | 11:45 |
| jtv | asac: what happens inside Soyuz is still murky to me. | 11:46 |
| asac | i think nobody knows | 11:46 |
| jtv | :-) | 11:46 |
| asac | especially for security updates its all completely misunderstood | 11:46 |
| asac | its not even "real" soyuz that is used for that. the things get built in hardy-security - which probably doesnt upload a thing to launchpad | 11:46 |
| asac | then it gets pocket-copied to hardy-updates | 11:47 |
| asac | which probably triggers something we have to identify | 11:47 |
| jtv | asac: things get really difficult when it comes to architectures. If you've got one architecture that still builds an outdated version of the package, it's possible that those happen to be the XPIs you get. | 11:47 |
| asac | jtv: hmm. thats a good idea, but i dont think it applies here. the only architecture that is bouncing is hppa | 11:47 |
| asac | and it wouldnt explain why be bumped back to the same version twice now | 11:48 |
| asac | and exactly in sync with our security updates | 11:48 |
| asac | and it doesnt explain why xulrunner doesnt have this issue | 11:48 |
| asac | :/ | 11:48 |
| jtv | asac: well, if that bounce is somehow making Soyuz decide to feed Rosetta the translations for an older version... | 11:48 |
| jtv | asac: the ordering may be arbitrary and depend on something unexpected. | 11:49 |
| jtv | asac: timing, for example, or even something strange involving alphabetical ordering. | 11:49 |
| asac | jtv: as i said. i dont think that hppa applies here. if it really bounces, then it never succeeds and no upload happens | 11:50 |
| asac | jtv: and i just looked. hppa doesnt bounce :/ | 11:50 |
| asac | it fails once and never is retried | 11:50 |
| jtv | so... no architecture has been held back to an older version, for example? | 11:51 |
| asac | jtv: i would love to put this on soyuz, but i think the fact that firefox is affected and xulrunner not, indicatess that something is broken with the state on launchpad side | 11:51 |
| asac | soyuz is less likely to behave different for individual packages | 11:51 |
| jtv | soyuz *is* part of launchpad. | 11:51 |
| asac | jtv: well. rosetta i mean ;) | 11:52 |
| jtv | Anyway... I see 2008-09-26 as the last update date. What happened then? | 11:52 |
| asac | jtv: thats the security update | 11:52 |
| jtv | So looks like that did upload a template. | 11:52 |
| asac | jtv: did you get multiple uploads for those days? | 11:52 |
| asac | or just one on 26th? | 11:53 |
| jtv | No way of knowing. | 11:53 |
| asac | hmm | 11:53 |
| asac | jtv: which time was that? | 11:53 |
| jtv | 13:47:56, which I _guess_ would be UTC | 11:54 |
| asac | jtv: but its 26th? | 11:54 |
| jtv | Yes | 11:54 |
| asac | jtv: how long would the auto approval take for the template? | 11:54 |
| asac | everything happened on 25th for this upload | 11:54 |
| asac | even the hppa build failure | 11:54 |
| asac | let me double check | 11:55 |
| jtv | asac: even on a bad day, hours at most. | 11:55 |
| jtv | asac: after that of course, it'd have to wait for import. | 11:55 |
| jtv | asac: and as you know the importer has been a bit busy recently... | 11:55 |
| jtv | asac: let me see if I can dig up some more information from my procmail logs. | 11:55 |
| asac | so if the upload happened close to midnight it wouldb e possible that it showed up as impported like that? | 11:56 |
| jtv | asac: yeah, I guess. If there were a lot of imports waiting at that point, or it was one of those days when we had problems with the approver... | 11:56 |
| jtv | Let me see if I can find that out. | 11:56 |
| asac | ok | 11:56 |
| jtv | asac: I see a Hardy firefox import on the 24th, and one on the 26th. | 11:59 |
| jtv | asac: Oddly enough, the times don't match. | 11:59 |
| asac | jtv: import == upload? | 12:00 |
| asac | maybe the mail gets sent when its uploaded abnd the other date is when its approved? | 12:00 |
| jtv | asac: could be something like that. | 12:00 |
| jtv | asac: could be that the update date in the database is taken from the upload time. | 12:01 |
| asac | jtv: ok. so there were two uploads for this security update | 12:01 |
| asac | or was there more mail about firefox around that date? | 12:01 |
| jtv | asac: in which case, and assuming the template's date is UTC but the email log is in CEST, the file would have finished importing about 18 minutes after being uploaded. | 12:01 |
| jtv | Not more for this template in Hardy. | 12:02 |
| asac | how do you know that both templates are equal (e.g. 24th + 26th)? | 12:02 |
| asac | is a md5sum sent? | 12:02 |
| asac | (in the 24th mail) | 12:02 |
| jtv | I have no way of knowing whether they would be identical. | 12:02 |
| asac | ok | 12:03 |
| jtv | There were also two matching xulrunner uploads, btw | 12:03 |
| asac | lets wait for jdstrang | 12:03 |
| asac | maybe he can confirm what happened at those dates | 12:03 |
| asac | mostlikely 24th was when the package was built in the security staging area | 12:03 |
| jtv | "jdstrang, where were you on the afternoon of September 26th?" | 12:03 |
| asac | hehe ;) | 12:03 |
| jtv | asac: it may also be important to know that if Soyuz uploaded the same file multiple times in rapid succession (e.g. for different architectures), those would show up as a single upload to Rosetta. | 12:04 |
| asac | jtv: most likely uploads happen only from i386 or something | 12:05 |
| asac | jtv: hmm how do you know that 24th isnt for 3.0.2? | 12:05 |
| asac | 3.0.2 and 3.0.3 have been uploaded with just a few days in between | 12:05 |
| jtv | asac: I don't /think/ the uploads are only i386... There's an open issue with string differences between archs, and so far our answer is "that's your problem." | 12:06 |
| jtv | I don't see any way of figuring out what versions they were. Only template name and distro version. | 12:06 |
| asac | jtv: ok. so you are saying that it must be a upload coming with the old en-US.xpi? | 12:07 |
| asac | i will try to investigate a bit more then | 12:07 |
| asac | and ask pitti et al | 12:07 |
| jtv | asac: that, to me, is definitely the most likely explanation. Anything else, you need to assume weird things. | 12:07 |
| jtv | asac: and remember, if this is an issue, we wouldn't have noticed with gettext files because those are dated. | 12:07 |
| asac | ok. maybe the pocket copy triggers a re-upload of the en-US.xpi that was built regularly in hardy | 12:08 |
| asac | jtv: you should really look into install.rdf and dont allow older versions :( | 12:08 |
| asac | please add that to your feature list ;) | 12:08 |
| asac | or at least require a manual review if the version looks lower | 12:09 |
| jtv | asac: question is: there's no date in install.rdf | 12:09 |
| asac | jtv: no. but a version | 12:10 |
| asac | so you can see that its aold | 12:10 |
| jtv | asac: so we'd have to do some pretty error-prone parsing of strings like "3.0b3" | 12:10 |
| asac | jtv: well. there is a rule for that ;) | 12:10 |
| asac | we should implement it properly | 12:10 |
| asac | or copy the code from firefox ;) | 12:10 |
| jtv | asac: there is a formalized system for comparing version numbers? | 12:10 |
| asac | jtv: yes | 12:10 |
| jtv | asac: and not just an equality comparison? | 12:11 |
| asac | jtv: no ... its a strict ordered set | 12:11 |
| jtv | asac: the other possibility would be to look at file dates, since XPI is zip | 12:11 |
| asac | jtv: yeah. but thats error prone too | 12:11 |
| jtv | asac: strict ordered? I don't know that term... totally ordered maybe? | 12:11 |
| asac | yeah | 12:11 |
| asac | its ordered | 12:11 |
| asac | ;) | 12:11 |
| * jtv thinks back... | 12:12 | |
| asac | jtv: http://developer.mozilla.org/en/Toolkit_version_format | 12:12 |
| jtv | Any two non-equal version numbers X and Y can be ordered as either X < Y or Y < X, but not both? | 12:12 |
| asac | that sounds ok ;) | 12:13 |
| jtv | asac: but this is specific to the package, and package version (ironic circularity there). | 12:13 |
| asac | jtv: what do you mean? | 12:14 |
| asac | strict (or irreflexive) partial order "<" is a binary relation that is irreflexive and transitive, and therefore asymmetric. | 12:14 |
| jtv | asac: it says "as used in Firefox 1.5 (XULRunner 1.8) and later" | 12:14 |
| asac | hehe | 12:14 |
| asac | just what i found ;) | 12:15 |
| asac | jtv: yes. but that is not going to change soon | 12:15 |
| jtv | asac: even for plugins/extensions? | 12:15 |
| asac | and we dont have packages with < 1.5 <1.8 | 12:15 |
| asac | jtv: yes. plugins/extensions have to follow the versioning scheme that xulrunner dictates | 12:15 |
| asac | so extensions that work on > 1.5 must have that versioning | 12:16 |
| jtv | asac: well, I suppose we can always bail out with a warning if we see something different... | 12:16 |
| jtv | asac: of course all our current code assumes that the comparison is based on dates. IIRC it's neatly isolated, but I hope the change wouldn't be too traumatic... | 12:17 |
| asac | jtv: what do you mean "something different"? a version that doesnt match the scheme? yes. then bail out | 12:18 |
| jtv | asac: right | 12:18 |
| asac | jtv: i think we should find the reason for the multiple uploads now | 12:18 |
| asac | or whats going on | 12:18 |
| asac | jtv: the versioning thing is just something that should ladn for the complete xpi support i guess | 12:18 |
| asac | until then its not really "supported" and for broad consumption i guess | 12:19 |
| asac | of course if there is no way to prevent old uploads we have to think | 12:19 |
| asac | and bump priority | 12:19 |
| asac | and until that is fixed remember to upload the template for firefox manually :/ | 12:19 |
| jtv | asac: that's another matter, yes: it takes time to get this sort of change into the codebase. | 12:19 |
| jtv | asac: but if it's this useful, we can do it before export capability. | 12:20 |
| jtv | asac: that work is too large to land as a single branch anyway. | 12:20 |
| asac | jtv: yes. lets define priority after evaluating the root cause here | 12:21 |
| asac | i have to talk to pitti now to get his story ;) | 12:21 |
| jtv | asac: do let me know! | 12:22 |
| asac | but whenever i talk to either you or him, there appears still be a gap nobody knows whats going on | 12:22 |
| asac | maybe infinity ;) | 12:22 |
| asac | celso at least doesnt know how the uploads happen | 12:22 |
| jtv | asac: if any mortal knows about Soyuz, it has to be Celso | 12:23 |
| asac | jtv: yeah. but this upload thing is something hooked in from outside or something else similar scary | 12:25 |
| jtv | asac: the machines have taken over already, and we never noticed | 12:25 |
| asac | lol | 12:25 |
| fta2 | asac, another answer to bug 274187 | 12:34 |
| ubottu | Launchpad bug 274187 in ubuntu "FFe - firefox 3.1 and xulrunner 1.9.1 for intrepid/universe" [Wishlist,New] https://launchpad.net/bugs/274187 | 12:34 |
| asac | ok | 12:39 |
| asac | i closed the bug now | 12:39 |
| asac | fta2: is backports something we can live with? | 12:41 |
| asac | i mean in general | 12:41 |
| asac | hmm | 12:42 |
| fta2 | asac, i don't see the difference, if we don't have time to do it ourselves, i doubt anyone else will do it on our behalf on the long term, in backports or through regular security updates. imho, the "motu cannot maintain this package due to the way it is licensed" argument is bullshit. it's just an excuse to cover that they are not willing to work | 12:51 |
| asac | true | 12:52 |
| asac | i think we should discuss that again for the future | 12:52 |
| fta2 | a bof at uds, maybe | 12:52 |
| asac | this train has left imo. and showing that we are not punching things through helps us in future discussions i hope | 12:52 |
| asac | yeah | 12:53 |
| asac | good idea | 12:53 |
| asac | we should think whats the exact issue to discuss there though | 12:53 |
| asac | we could make it "mozilla" specific | 12:53 |
| asac | most likely giving a presentation on how this all works | 12:53 |
| asac | i think there would be a | 12:54 |
| fta2 | root cause is easy to pinpoint.. not enough active members in your team | 12:54 |
| asac | bunch of interested parties in that | 12:54 |
| fta2 | -your+our | 12:54 |
| asac | thats true. and thats why bridges need to be built | 12:54 |
| asac | the entry barrier is quite high | 12:54 |
| asac | and takes a lot of efforts | 12:55 |
| asac | this together with spooky tales going around in MOTU doesnt really attract anyone :) | 12:55 |
| asac | tales like: "mozilla software is illegal to maintain" | 12:55 |
| asac | 14:28 < pitti> asac: you could also ask jamie and kees to look at the -security upload .changes on jackass and check whether they have translations | 13:29 |
| asac | jdstrand: ^^ | 13:29 |
| asac | thanks | 13:29 |
| jdstrand | asac: sure | 13:31 |
| jdstrand | hold on | 13:31 |
| asac | jdstrand: we are looking for 3.0.3 | 13:32 |
| * jdstrand nods | 13:32 | |
| jdstrand | asac: it looks like it: http://paste.ubuntu.com/58323/ | 13:37 |
| asac | jdstrand: ok thanks | 13:37 |
| asac | jdstrand: do you have a bridge interface? | 14:06 |
| jdstrand | asac: no | 14:07 |
| asac | hmm | 14:07 |
| asac | [reed]: i would like you to test something for the EAP bug ;) | 14:16 |
| nxvl | asac: https://code.edge.launchpad.net/~oem-solutions-group/firefox/firefox-3.0.hardy | 18:30 |
| nxvl | asac: already merged and uploaded | 18:30 |
| sebner | nxvl: ha! good to see you around :) | 18:30 |
| nxvl | still need to add the branching | 18:30 |
| nxvl | sebner: :D | 18:30 |
| sebner | nxvl: how are you? everything fine? | 18:31 |
| nxvl | yes | 18:31 |
| nxvl | with tons of work | 18:31 |
| nxvl | that's why i'm here | 18:31 |
| nxvl | :D | 18:31 |
| sebner | nxvl: what a pitty. I wouldn't want to add more work :P | 18:33 |
| nxvl | but when you have fun at work, you don't feel entirely the charge | 18:35 |
| nxvl | i will take a break now, brb | 18:35 |
| sebner | nxvl: kk, and when you come back I'll give you a nice work ^^ | 18:35 |
| nxvl | :P | 18:38 |
| asac | nxvl: on a first glance it looks ok. the commit message could be improved to give more infos on "what was merged", "from where", and what adaptions were needed | 18:39 |
| asac | nxvl: was the merge "easy"? | 18:39 |
| sebner | nxvl: so your break was 3 minutes? | 18:42 |
| asac | nxvl: hmm i think you replayed on top of the wrong revision | 18:43 |
| asac | so now the maxVersion sed is still not there | 18:43 |
| asac | nxvl: the replay was now done on top of 3.0.1+build1+nobinonly-0ubuntu0.8.04.3 | 18:44 |
| asac | but i think the rules developed was on top of 3.0+nobinonly-0ubuntu0.8.04.1 | 18:44 |
| asac | or something | 18:44 |
| asac | or maybe 3.0.1+build1+nobinonly-0ubuntu0.8.04.1 | 18:45 |
| generalsnus | I need to have some custom firefox profiles for all my users. it works to edit "/usr/lib/firefox-3.0.3/defaults/profile" for new profiles... but what can i do to exsisting profiles? is there some way of forcing new settings on those users? | 21:02 |
| [reed] | asac: ok, what? | 21:03 |
| [reed] | asac: cause 802.1x is broken for both me and a friend of mine here on campus | 21:03 |
| [reed] | both running Ubuntu 8.10 beta latest on our thinkpads | 21:03 |
| fta | sebner, i'm trying my best to stick to DarkRoom, it's difficult :P | 22:38 |
| Starks | hello? | 23:06 |
| [reed] | fta: I like the theme | 23:45 |
| [reed] | reminds me of Angel, specifically Wolfram & Hart | 23:46 |
| [reed] | that evil law firm | 23:46 |
| [reed] | :p | 23:46 |
| fta | [reed], DarkRoom ? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
