[01:34] <lifeless> http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/
[01:34] <lifeless> cjwatson: ^
[01:34] <mwhudson> i.e. it was NSA wot did it?
[01:35] <lifeless> something like
[01:35] <mwhudson> i like the first comment:
[01:35] <mwhudson> It is going to be both funny and sad if it turns out this thing was written by some 15 year old in his parent's basement.
[02:38] <cjwatson> I wonder how well the maths behind that will transfer to the SHA family :-/
[02:40] <wgrant> cjwatson: SHA-1 perhaps, but isn't SHA-2 fairly different?
[02:44] <wgrant> But I guess if it's an entirely novel form of the attack it may have some relevance.
[02:44] <cjwatson> They're similar enough for the multicollisions approach to still apply.
[02:45] <cjwatson> All the current hash families aside maybe from some elliptic curve ones have roughly the same general shape.
[02:46] <cjwatson> Which isn't to say that it wouldn't be quite a bit more world-class maths to transfer it ...
[02:46] <wgrant> Indeed.
[02:48] <cjwatson> My general takeaway from hash developments over the last ~10 years is that every deployed system needs a structure for moving to new hashes, anyway.
[02:48] <cjwatson> So meh :-)
[02:49] <cjwatson> Pretty surprised Microsoft is still vulnerable to MD5-based attacks, though.
[02:49] <cody-somerville> I'm curious.  AFAIU, even though it's been discovered how to crack md5 it still takes a little while plus why would you need the crypto breakthrough in the malware yourself? Wouldn't you just use the math to create the fake cert then you use that to sign stuff?
[02:50] <mwhudson> i was wondering that
[02:51] <mwhudson> i think that the deduction that a new approach was used by looking at the way the form the colliding data has
[02:51] <mwhudson> reading between the lines of http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware
[02:51] <mwhudson> so there's not a novel md5 collision generating algorithm in flame
[02:52] <cjwatson> Ah, it's only Terminal Server that's still MD5y
[02:52] <wgrant> The collision code isn't in flame.
[02:53] <wgrant> They were just able to determine it was novel from the cert it uses.
[02:53] <wgrant> The known attacks are fairly distinctive :)
[04:10] <wgrant> wallyworld: Thanks for cleaning that up.
[04:11] <wallyworld> had to be done
[04:46] <cjwatson> wgrant: Have you had a chance to look at my queue-api branch?
[05:02] <wgrant> cjwatson: A little. Have you considered the performance impact of the additional exported properties on PackageUpload?
[05:02] <wgrant> Unless they're preloaded they will likely make it impossible to call getPackageUploads
[05:17] <lifeless> cjwatson: I want to talk to you about deb deltas
[05:18] <lifeless> cjwatson: are you up for a while, or is your circadian rhythm not ?
[05:22] <cjwatson> wgrant: I haven't.  Advice welcome
[05:22] <cjwatson> lifeless: Meh - I'm kind of here but mostly in a "hacking until my brain lets me go back to sleep" kind of way
[05:22] <cjwatson> So maybe now isn't the ideal time for deep thought
[05:23] <lifeless> cjwatson: ok, ping me when we cross paths and you're up for deep though
[05:23] <lifeless> t
[05:23] <cjwatson> lifeless: OK - can you send me an e-mail reminder?
[05:23] <lifeless> yes, when I'm not quite so crook
[05:23] <cjwatson> (Then at least it can get lost in the depths of my inbox as well as the depths of my brain ...)
[05:23]  * cjwatson nods
[05:25] <StevenK> lifeless: You have the entire weekend to be sick now :-P
[05:27] <StevenK> lifeless: Do you know anything about stub's GIN work?
[05:27] <cjwatson> wgrant: Is DecoratedResultSet(query, pre_iter_hook=...) the mechanism for this?
[05:28] <cjwatson> I find storm a little difficult to navigate unassisted.
[05:28] <StevenK> Welcome to the club
[05:28] <bigjools> it's not the most pleasant code
[05:28] <StevenK> Everytime I get a traceback in the depths of Storm, I tend to yell for help
[05:28] <wgrant> cjwatson: Yeah.
[05:29] <wgrant> Note that DRS is one of our layers on top of Storm.
[05:29] <wgrant> Storm rejected it.
[05:29] <wgrant> StevenK: What about GIN?
[05:30] <StevenK> wgrant: DB r11636 is up next -- [r=stub][bug=306201][incr] Switch BugTaskFlat.fti index from GiST to GIN
[05:31] <StevenK> But then DB r11640 says --- [r=stub][bug=1007333] pgstattuple doesn't support GIN indexes, so don't do that
[05:31] <wgrant> StevenK: Bah, I typoed the deployment request
[05:31] <wgrant> Should be 11639
[05:31]  * wgrant fixes.
[05:31] <StevenK> wgrant: Haha, what did you have?
[05:31] <wgrant> 11640
[05:32] <StevenK> WCPGW
[05:32] <wgrant> Nothing at all, since I believe 11640's was probably applied live.
[05:32] <wgrant> But I'm not sure.
[05:32] <wgrant> Part of 11636 was as well, but not all.
[05:33] <StevenK> We can probably check that and make db-stable's deployment report a bit happier?
[05:33]  * StevenK stabs wallyworld.
[05:34] <StevenK> Just when I want him, he buggers off.
[05:48] <StevenK> wallyworld_, wgrant: Test fixes for branch-subscribe-aag and checking that the reviewer isn't an open team for private branches: http://pastebin.ubuntu.com/1029885/
[05:49]  * wallyworld_ looks
[05:54] <wallyworld_> StevenK: test_open_reviewer_private_branch, i'd like to see test_closed_team_reviewer_private_branch also even thoug the functionality is implicitly tested elsewhere, it would be good to have the two matching tests for this together
[05:54] <wallyworld_> StevenK: also, add a comment to _acceptable_to_give_visibility
[05:54] <lifeless> wgrant: I don't know that DRS was ever offered to storm
[05:55] <wgrant> http://comments.gmane.org/gmane.comp.python.storm/1319
[05:57] <lifeless> oh right
[05:57] <lifeless> so yes, I remember, and disagree with them :)
[05:59] <StevenK> wallyworld_: http://pastebin.ubuntu.com/1029896/ should address both comments.
[06:00] <wallyworld_> StevenK: thanks, looks good
[06:18] <wallyworld_> StevenK: i have to go to soccer - i can +1 your mp when i get back
[06:37] <cjwatson> wgrant: Well, http://paste.ubuntu.com/1029949/ demonstrates the problem, but adding more load_referencing/load_related doesn't seem to reduce the query count that the test complains about, so I must be doing something wrong ...
[06:38] <StevenK> wallyworld_: It already was, I've tossed it to ec2
[06:40] <cjwatson> (The test output is http://paste.ubuntu.com/1029951/, which does look like a moderately plausible set of queries that might be happening here)
[06:40] <wgrant> cjwatson: Those load_relateds should be sufficient (Reference columns look up by primary key, so if an object is already in Storms cache it won't cause a DB query), but the load_referencing things aren't, since the problematic properties issue queries directly or use a ReferenceSet or SQLMultipleJoin, none of which can be cached in Storm currently.
[06:40] <wgrant> So you need to use @cachedproperty
[06:41] <wgrant> And populate the property cache explicitly with the result of load_referencing
[06:41] <wgrant> And then sob.
[06:41] <wgrant> cjwatson: eg. search for load_referencing in lib/lp/registry/vocabularies.py
[06:42] <cjwatson> ... I think I need sleep, then caffeine, then food, then beer, *then* to attack this
[06:42] <cjwatson> But thanks, that's exactly the kind of reference I was looking for
[06:43] <wgrant> Heh
[06:50] <wgrant> cjwatson: PersonSet._getPrecachedPersons may also be of interest.
[06:51] <wgrant> cjwatson: It's one of the earlier cases of this, so it's a bit terrible but roughly a sort of correct idea.
[07:04] <jam> Hey all, I'm getting a timeout trying to submit a merge proposal: The following errors were encountered: Timeout error, please try again in a few minutes.
[07:04] <jam> is there a downtime I'm unaware of?
[07:04] <wgrant> jam: No, that's a bug.
[07:05] <wgrant> What's the OOPS ID?
[07:05] <jam> wgrant: no oops
[07:05] <wgrant> (perhaps check the AJAX log in the top right corner.
[07:05] <jam> just failure
[07:05] <wgrant> There is an OOPS
[07:05] <jam> and it just succeeded :(
[07:05] <wgrant> It might just not be shown.
[07:05] <jam> I reproduced it 3 times, but yeah, no log of the oops for me to go check.
[07:05] <jam> I'll try back, but I think that will wipe ajax stuff
[07:06] <jam> yeah
[07:50] <adeuring> good morning
[07:52] <jtv> Hi adeuring
[07:52] <adeuring> hi jtv
[09:00] <stub> Test fix mode due to  lp.services.job.tests.test_celeryjob.TestRunMissingJobs.test_find_missing_ready on db-devel
[09:02] <stub> Pretty certain it is spurious - no sampledata landings in the timeframe and test passed on devel
[09:45]  * jml feels dumb for not running tests on db-rename-archive-commercial-to-suppress last night
[09:45] <jml> hmm. last build failed. looks like a network error.
[09:46] <jml> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/2028/steps/shell_5/logs/stdio
[09:56] <gmb> adeuring, Do you have time to review https://code.launchpad.net/~gmb/launchpad/bug-1009712/+merge/109315 ?
[09:56] <adeuring> gmb: sure
[09:56] <gmb> Thanks
[10:02] <adeuring> gmb: the feature retlaed changes look good. but what is test_noise supposed to do?
[10:03] <gmb> adeuring, Wups, that wasn't meant to be there. I'll remove it.
[10:03] <adeuring> gmb: ok, then r=me
[10:06] <gmb> Danke.
[10:20] <jml> grr.
[10:20] <jml> database patches aren't hard, but iterating on them is a pain.
[10:37] <stub> Is the estimated time before a build completes based on all builds, or successful builds?
[10:40] <wgrant> stub: Successful
[10:46] <rick_h> rvba: oops sorry, thought you guys were using 3.5 for some reason.
[11:00] <czajkowski> rick_h: you're up early
[11:03] <rick_h> naw, this is pretty normal for me
[11:04] <rick_h> just normally quiet reading email and MP stuff for the first bit :)
[11:10] <rvba> rick_h: no worries.  Thanks for the review.
[11:23] <jml> may I have another db patch number please?
[11:23] <jml> https://code.launchpad.net/~jml/launchpad/remove-archive-commercial/+merge/109332 is an easy MP, btw.
[11:24] <lifeless_> jml: you can self allocate these days
[11:25] <jml> lifeless_: I'm not in ~launchpad
[11:25] <jml> lifeless_: so I don't have write access to the branch in which patch numbers are allocated.
[11:25] <stub> jml: Gimme a short comment for the log
[11:25] <jml> stub: "Add column to Distribution controlling who can create private PPAs"
[11:26] <stub> jml: 2209-22-1
[11:26] <jml> stub: thanks.
[11:27] <ev> are there any plans to support OAuth 1.0a in launchpadlib? Specifically, oauth_callback.
[11:29] <jml> ev: not that I know of.
[11:30] <ev> jml: cheers
[12:03] <jml> db patch up for review: https://code.launchpad.net/~jml/launchpad/db-distro-level-ppa-privacy/+merge/109336
[12:03] <jml> lifeless_: if you're still kibbitzing, you might be interested in that.
[12:05] <StevenK> jml: You want stub for that
[12:05] <jml> StevenK: sure. but lifeless has been involved in implementation discussions, and might want to be sure that I'm doing what we agreed on, rather than what I think we agreed on
[12:14] <wgrant> jml: You want to talk to sinzui.
[12:14] <wgrant> jml: That DB patch is probably incorrect.
[12:14] <jml> wgrant: I thought I had.
[12:14] <jml> anyway.
[12:14] <jml> wgrant: I'll talk to him again.
[12:14] <wgrant> It's not really anything to do with the distro.
[12:15] <jml> it is now :)
[12:15] <wgrant> How?
[12:16] <wgrant> We generally grant private PPAs to people with commercial subscriptions.
[12:16] <wgrant> Not because they are vaguely related to some distro.
[12:16] <wgrant> It's not a security-sensitive option.
[12:17] <wgrant> So it makes little sense to have it as a distro-delegated operation.
[12:18] <wgrant> Similar to the way we now let anybody with a commercial subscription create a private team.
[12:18] <wgrant> Which implicitly has private PPAs.
[12:19] <jml> Grr.
[12:20] <jml> a) lifeless said "make a new celebrity". I don't know how it became "add a column" in my notes.
[12:21] <jml> b) I emailed launchpad-dev about this 5 weeks ago. No one replied.
[12:23] <wgrant> jml: The thread about the technical bits of protecting it differently in the Zope security model?
[12:24] <wgrant> I don't recall a thread about how it should be modelled.
[12:26] <jml> wgrant: right, the one titled "permissions for creating private objects"
[12:27] <jml> (there was also the email to stakeholders in Jan asking if there'd be "any problems with a PPA having, say, 100,000 subscribers?", but that's a different badger)
[12:27] <jml> sinzui: are you around?
[12:31] <wgrant> jml: Well, that thread didn't go near deciding who can do it. It was around the probably impossible problem of doing it cleanly in the Zope security model.
[12:31] <wgrant> I suspect nobody replied because anybody with an opinion already knows it's hopeless.
[12:32] <jml> wgrant: it opened describing our planned approach. if it was incorrect, that was the time to tell us so.
[12:32] <wgrant> Oh
[12:33] <wgrant> Indeed, the second paragraph of the first email mentions the celebrity approach.
[12:33] <wgrant> Missed it among the other 20 paragraphs of hopeless Zopeness :)
[12:33] <wgrant> Sorry.
[12:33] <wgrant> So, a celebrity is a lightweight and potentially sensible approach for now.
[12:33] <wgrant> A DB column is not.
[12:33] <jml> I put it first (just after what we're trying to achieve) because it was most important (after what we're trying to achieve)
[12:33] <wgrant> But sinzui is Lord of Entitlement.
[12:35] <jml> and is apparently not around.
[12:35] <wgrant> It's not quite 9am for him yet.
[12:35]  * czajkowski peers at wgrant how are you still awake !
[12:36] <wgrant> I'm waiting to talk to a US user who is making several million API requests a day.
[12:37] <czajkowski> wgrant: ah lovely that reminds me
[12:38] <jml> sinzui: I'm getting some food. ping me when you're around and want to talk about creating private PPAs.
[14:22] <cjwatson> wgrant: queue-api: I've converted some of the expensive properties into methods, and arranged to preload everything else.  I think that should address your performance concerns.
[14:23] <cjwatson> (Where "everything else" was just the referencing PackageUpload{Source,Build,Custom} objects.)
[15:09] <jml> sinzui: ping
[15:09] <sinzui> hi jml
[15:09] <jml> sinzui: hi
[15:10] <jml> sinzui: I'd like to change LP so I can create private PPAs without being in commercial_admin
[15:11] <jml> sinzui: consensus from other LP devs is that I should create a new celebrity team that includes everyone who is allowed to do this.
[15:11] <sinzui> jml: Yes, I think that meets your needs.
[15:12] <jml> sinzui: ok. is this in line with other entitlement / privacy work going on?
[15:13] <sinzui> jml: its orthogonal. for entitlement...I think any user/team that maintains a project  with a  commercial subscription can create a p3a.
[15:13] <sinzui> I do not think your rules to maintain the system should be connection to user entitlement
[15:13] <jml> sinzui: well, then why bother making a celebrity team? why don't I just query to see if they maintain a project with a commercial subscription?
[15:14] <jml> sinzui: in fact, why don't I just assume that if they have a private team they can make private PPAs?
[15:14] <sinzui> jml: private teams can only have p3as. maybe I misunderstand you
[15:15] <jml> hmm. thinking...
[15:15] <sinzui> jml: but your statements are true. both will work
[15:16] <sinzui> We do not dismantle private teams when subscriptions expire
[15:16]  * sinzui has no idea to handle that case
[15:16] <jml> sinzui: so, AIUI, currently if you're creating a PPA under a private team you also need to have launchpad.Commercial to make it private.
[15:16] <jml> sinzui: which is silly, I think.
[15:16] <sinzui> oh, jml, there is a method, maybe on personset that will tell you of the user has commercial privs
[15:17] <jml> sinzui: sorry, I shouldn't have said launchpad.Commercial, I should have said "in commercial admin"
[15:17] <sinzui> jml. I hope not...that would be a bug. private teams can not have public ppas
[15:17] <jml> sinzui: well I think it's just that you're not allowed to create any PPA. Let me check
[15:18] <sinzui> that too would be a bug. Any team can have a ppa, private teams are p3a. public teams may only have p3a when someone intervenes.
[15:19] <jml> ok.
[15:19] <jml> I think it is a bug (validatePPA doesn't bother checking the privacy status of the owning team, it just checks admin & commercial_admin)
[15:20] <jml> sinzui: so now we need some way to say who is allowed to create private PPAs on public teams
[15:20] <jml> sinzui: and I guess that can be a celebrity
[15:20] <jml> sinzui: but if there's already some mechanism in Launchpad saying "they've paid for super-powers" then I'd rather use that.
[15:20] <jml> anyway
[15:20] <sinzui> ah, I agree
[15:21] <sinzui> if the user paid for privs, he should see the checkbox or API to make the archive private
[15:21]  * sinzui is still hunting for the method that checks if the user have paid for privs
[15:23] <jml> sinzui: of course, this sort of assumes commercial is all-or-nothing.
[15:23] <jml> sinzui: I guess that's an OK assumption.
[15:23] <sinzui> jml: please assume that
[15:23] <sinzui> we want this very simple for users and us to understand
[15:23] <sinzui> if you find a contradiction, we need to fix it
[15:29] <jml> sinzui: ok, thanks. let me know if you find that API
[15:29] <sinzui> jml, person.checkAllowVisibility() is checks if the user has permission to make things private. It is used to know when to show users the the team visibility field. It would also apply to p3as
[15:34] <jml> sinzui: thanks.
[15:54] <jml> sinzui: please verify: https://code.launchpad.net/~jml/launchpad/db-distro-level-ppa-privacy/+merge/109336/comments/234987
[15:56] <sinzui> jml that is correct with one subtle point you might find in the code...I think we mean users = team admin in some cases.
[15:56] <sinzui> user ~= team admins
[15:56] <sinzui> I do not think team members can create ppas
[15:57] <jml> sinzui: I think they can.
[15:58] <jml> hmm.
[15:58] <jml> maybe not.
[15:59]  * jml can't seem to log in to staging.
[16:09] <jml> sinzui: qastaging uses a different db to prod, right?
[16:10] <sinzui> jml: yes, and it is months older :(
[16:10] <jml> sinzui: you can create PPAs over the API without being a team admin.
[16:10] <jml> sinzui: but not in the UI
[16:10] <sinzui> I think that contradicts ui
[16:10] <sinzui> yep
[16:11] <sinzui> That is a bug, but I do not know how disruptive it is to fix
[16:11] <jml> lbyl bites again.
[16:12] <sinzui> I do not think there is a bug about this. I image it would only exist if teams felt that team privs were being abused
[16:14] <jml> well, it's something we might fix as a follow up, or as a drive-by, but we'll preserve the existing behaviour all things being equal
[16:14] <sinzui> jml: I agree. I would not fix this without an audit of the db
[16:14] <jml> sinzui: how come?
[16:15] <sinzui> Canonical and other commercial users may be taking advantage of this bug.
[16:18] <sinzui> jml: I don't this I could audit this case. We do not know who created the archive. So I think this issue requires a conversation with PES and openstack
[16:19] <jml> sinzui: fair enough.
[16:20] <ev> Before I go too far down the rabbit hole, what's the suggested approach for logging into Launchpad with existing OAuth credentials from a web client?
[16:20] <ev> Should I use Launchpad.login_with and a CredentialStore subclass that provides the already obtained oauth_token and oauth_token_secret?
[16:20] <ev> the existing documentation creates a Launchpad() object from the default constructor with now-missing arguments (https://help.launchpad.net/API/launchpadlib)
[16:21] <ev> err rather: https://help.launchpad.net/API/launchpadlib#Authenticated_access_for_website_integration
[16:25] <sinzui> ev: I am not very familiar with the OAuth code, but I write a lot of API scripts. I think the subclass approach is right so that scripts can be adapted or be written support multiple stores
[16:26] <ev> sinzui: multiple stores? This is only ever going to use cookies. Or have I misread?
[16:26] <ev> back in a bit, it's toasting the new office time
[16:26] <sinzui> ev, As a tester, I would like to switch which cookies I am using.
[16:47] <nigelb> rick_h: Hey, you around?
[16:47] <rick_h> nigelb: sure, what's up?
[16:48] <nigelb> rick_h: Hey, when you worked on SA, what did you guys do for db migration?
[16:48] <rick_h> we used sqlalchemy-migate but I
[16:48] <rick_h> 've got on my todo to port my app over to alembic
[16:48] <nigelb> ah
[16:48] <rick_h> and squash down the migations/etc
[16:50] <nigelb> rick_h: thanks! I look up both of them :)
[16:51] <rick_h> nigelb: yea, definitely suggest alembic, it's done by the SA author so it'll be kept in sync/etc much better
[16:51] <rick_h> nigelb: and he looked at django's south so should be a bit 'learned' from the competition
[16:51] <nigelb> heh
[16:58] <bdmurray> sinzui: so I tried testing via bin/test -vvc --layer=YUI per your suggestion and I keep getting tests timing out
[16:58] <sinzui> That is odd. The tests run in a few minutes for me
[16:58] <sinzui> maybe you are missing dep
[16:58] <rick_h> bdmurray: what's the exact error? It might be that you didn't run the build steps or failed to setup
[16:59] <rick_h> bdmurray: try manually running make jsbuild
[16:59] <bdmurray> AssertionError: JS timed out
[16:59] <sinzui> ah, right, the build files need to be on the filesystem
[16:59] <rick_h> right
[16:59] <ev> sinzui: ah, good point. Thanks for the tips!
[17:01] <sinzui> bdmurray, you can test any YUI module in your browser: xdg-open lib/lp/app/javascript/tests/test_lp_links.html
[17:01] <sinzui> if your browser cannot run the test, the tree was not build right
[17:02] <bdmurray> okay thanks, make jsbuild seems to have helped
[17:02] <rick_h> awesome
[21:17] <lifeless> http://www.infoq.com/presentations/Storm
[21:23] <jelmer> 'morning lifeless
[21:36] <lifeless> hi jelmer


[06:02] <Bashing-om>  R&R time; g nite
[06:22] <lotuspsychje> morning fellas
[06:43] <ducasse> gute morgen everybody!
[06:45] <ObrienDave> hasty banana to you ;P
[06:45] <ducasse> :)
[07:06] <lotuspsychje> bbl guys working time
[07:06] <lotuspsychje> hi and bye :p
[08:19] <lordievader> Good morning.
[08:21] <ducasse> \o lordievader
[08:21] <lordievader> Hey ducasse
[08:21] <lordievader> How are you doing?
[08:21] <ducasse> good thanks, and you?
[08:25] <lordievader> Doing okay, got music and coffee :)
[08:26] <ducasse> music and tea here, so much the same :)
[08:28] <lordievader> ;)
[12:04] <BluesKaj> Hi folks


[15:59] <asac> sorry ... got lost in an ad-hoc trip to denmark :/
[15:59] <asac> Ubulette: there?
[15:59] <Ubulette> asac, yes
[15:59] <Ubulette> asac, hi, how are you ?
[16:00] <asac> well ... first i thought ... damn no internet
[16:00] <Ubulette> i'm fighting with prism on revu :)
[16:00] <asac> but now i don't want to get back at all :)
[16:00] <asac> got used just doing nothing ;)
[16:00] <Ubulette> lol
[16:00] <asac> fun is i have to work all night now because ffox will be out tomorrow :(
[16:00] <asac> and i think my sponsor backlog is pretty big as well
[16:01] <asac> prism? any serious issues?
[16:01] <Ubulette> yep
[16:01] <Ubulette> no
[16:01] <asac> good
[16:01] <asac> so gnomefreak is gone?
[16:01] <asac> what happened?
[16:01] <asac> last thing i see is that he complained about doing unrecognized work
[16:02] <Ubulette> he burst in flames once again and disappeared without giving me a chance to clarify.
[16:02] <Ubulette> while there was nothing new at all
[16:03] <Ubulette> i was just explaining stuff to bluekuja for sm1
[16:03] <Ubulette> result is that bluekuja is gone too
[16:03] <asac> huh?
[16:03] <Ubulette> and sm1 is still stuck
[16:03] <Ubulette> maybe he got scared. I have no idea
[16:03] <bluekuja> Ubulette, no
[16:03] <asac> ok ... didn't i sign it of in launchpad?
[16:03] <bluekuja> I just told you it's the weekend
[16:04] <bluekuja> It's the first time I touch my pc since friday
[16:04] <asac> i confirmed something ... ah right xulrunner 1.8 ... was that uploaded?
[16:04] <asac> bluekuja: hey :)
[16:04] <bluekuja> asac: heya alex! :)
[16:04] <bluekuja> asac, first P&P answered
[16:04] <bluekuja> asac, it was....nice!
[16:04] <asac> bluekuja: cool!
[16:04] <Ubulette> asac, yep, my merge for xul 1.8 has been sponsored in a blink
[16:04] <asac> good
[16:05] <bluekuja> asac, I've seen you aren't an AM now
[16:05] <bluekuja> decided to stop?
[16:05] <bluekuja> :)
[16:05] <bluekuja> Ubulette, gnomefreak was a little less angry
 i cant see real good the drops they gave me i found out im allergic to. Ubulette you cant add nobinonly to gutsy and you cant change iceape -> seamonkey in gutsy, why did you do iceape at all since i already did it and pushed it to review? ONLY security fixes can be put into stable rlease unless it is oked by a SRU and nobinonly doesnt fit within that AFAIK
 Ubulette: if my package isnt good enough for gutsy than tell me and ill fix it but I REALLY FUCKING HATE DOING WORK FOR NO REASON! ill be back some other time
[16:06] <bluekuja> * gnomefreak è uscito ("Lost terminal")
[16:06] <asac> bluekuja: well i think they understood that i currently don't have much time :)(
[16:06] <bluekuja> asac, lol
[16:06] <bluekuja> asac, yeah^^
[16:06] <bluekuja> asac, that's the backlog from john
[16:07] <asac> bluekuja: yes
[16:07] <asac> i saw that
[16:07] <bluekuja> asac, any idea on how we can move on?
[16:07] <asac> on what?
[16:07] <bluekuja> on seamonkey
[16:08] <bluekuja> I've seen a package waiting for sponsorship in the queue
[16:08] <armin76> asac: you doing anything about xulrunner-1.9, or fx-3.0?
[16:08] <bluekuja> about iceape
[16:08] <bluekuja> and maybe john was complaining about that
[16:08] <bluekuja> asac, anyway PPA security issue got fixed finally
[16:08] <bluekuja> asac, e.g changes files signed by keys in the keyring for the main archive
[16:08] <Ubulette> armin76, i have updated both for ~b1, ready for review
[16:09] <asac> bluekuja: seamonkey to hardy ... iceape to gutsy
[16:09] <Ubulette> asac, yes, i thought it was clear for everyone
[16:09] <bluekuja> asac, yes, but why john was complaining about that?
[16:09] <armin76> Ubulette: you have a link where i could see it?
[16:09] <asac> bluekuja: no idea ... i think he was pissed of because his package didn't get sponsored.
[16:09] <bluekuja> ah damn
[16:10] <Ubulette> armin76, either the corresponding brz branches or my ppa.
[16:10] <armin76> rofl
[16:10] <Ubulette> I haven't tried to push that to motu/revu because we usually review those here
[16:11] <armin76> Ubulette: i'm not an ubuntu user, so i don't have any idea what you're talking about :P
[16:11] <asac> yes we will upload beta directly
[16:11] <asac> armin76: so what is your question about?
[16:11] <Ubulette> armin76, hmm, so why do you aks here ? it's an ubuntu channel
[16:11] <armin76> :D
[16:12] <armin76> just looking what you guys did
[16:12] <armin76> and to say that it doesn't compile on alpha or ia64
[16:12] <Ubulette> oh, you're gentoo
[16:12] <bluekuja> armin76, gentoo doesnt rock
[16:12] <bluekuja> armin76, migrate to Ubuntu please
[16:12] <bluekuja> :)
[16:13] <armin76> bluekuja: no, thanks, ubuntu doesn't have support for alpha hppa sparc ia64, which are the archs i use :P
[16:13] <bluekuja> armin76, huh?
[16:14] <bluekuja> armin76, Ubuntu support them as well
[16:14] <armin76> since when?
[16:15] <armin76> packages.ubuntu.com only show amd64 i386 and ppc
[16:15] <bluekuja> armin76, check exaile package for instance
[16:15] <bluekuja> armin76, https://edge.launchpad.net/ubuntu/+source/exaile/<IP_ADDRESS>-0ubuntu1
[16:15] <bluekuja> armin76, check the builds
[16:17] <armin76> alpha is missing :P
[16:17] <asac> armin76: how does it fail?
[16:17] <bluekuja> armin76, yes, but anyway migrate
[16:17] <bluekuja> :)
[16:18] <armin76> asac: fails to compile, it detects the arch and so, but fails
[16:18] <armin76> different errors, though
[16:19] <armin76> asac: http://launchpadlibrarian.net/10370744/buildlog_ubuntu-hardy-ia64.xulrunner-1.9_1.9%7Eb1%7Erc3%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz <- f. ex :)
[16:19] <asac> yeah not updated xpt
[16:20] <asac> don't think that there is a fix yet
[16:23] <armin76> do you think there will be? :P
[16:25] <Ubulette> armin76, I don't have access to an ia64 box so it's difficult for me to fix. patches are welcome
[16:25] <asac> usually someone interested in that architecture has to come up with a fix
[16:28] <Ubulette> asac, for prism: "There is a build-dependency on unzip. but all packages are architecture independent: this probably should be a build-depends-indep: "
[16:28] <Ubulette> I have to move unzip to build-depends-indep ??
[16:30] <asac> Ubulette: no its ok to have it in depends
[16:30] <asac> the build-depends-indep are ment for specific depends to build only the binary indep
[16:30] <Ubulette> i know but that's a comment i got in REVU..
[16:31] <asac> i think its neglectable
[16:31] <asac> do you have a link to revu?
[16:31] <Ubulette> http://revu.tauware.de/details.py?package=prism
[16:31] <Ubulette> i'm commenting right now
[16:33] <Ubulette> what's wrong with my manpage.. it was right before.. hmm
[16:40] <asac> most comments are valid
[16:40] <Ubulette> no
[16:41] <asac> i wouldn't mind some though
[16:41] <Ubulette> 10) Please put prism-google-docs in Section: doc
[16:41] <Ubulette> lol
[16:41] <asac> yeah
[16:41] <Ubulette> that's lintian non sense
[16:41] <asac> reviewers faith
[16:41] <Ubulette> 11) prism is architecture: all, but ships data in /usr/lib (please use /usr/share)
[16:41] <Ubulette> i did move chrome but I can't move the whole thing
[16:42] <asac> which files are install in pkglibdir?
[16:42] <Ubulette> well, maybe I can
[16:42] <asac> i wouldn't bother linking components
[16:42] <asac> (javascript ones)
[16:42] <asac> configs + chromes
[16:43] <asac> though configs are not a big problem either
[16:43] <Ubulette> well, as a whole, he's damn picky, none of our packages here respect any of those
[16:44] <asac> yeah
[16:44] <asac> i don't think that he can't live with some
[16:44] <asac> he just wants to point out everything
[16:44] <asac> while some are neglectable
[16:45] <asac> 8 + 9 should be fixed
[16:45] <Ubulette> I think it was good before. I'll check, maybe a last minute regression
[16:46] <Ubulette> same for my manpage
[16:46] <asac> 1, 4, 6, 14, 15(maybe), 17,
[16:46] <asac> those i think are fixworthy too
[16:46] <asac> the others are nice-to-have
[16:46] <Ubulette> 1 and 5 are debian stuff, too new for ubuntu
[16:46] <asac> for mpl you should include MPL in docs
[16:47] <asac> Ubulette: no vcs headers are needed
[16:47] <asac> so 1 is important
[16:47] <asac> X-Vcs-Bzr: bzrurl
[16:47] <Ubulette> no
[16:47] <Ubulette> I have that one
[16:47] <asac> he?
[16:47] <asac> ah
[16:47] <Ubulette> he wants Vcs-Bzr
[16:47] <asac> now i see
[16:47] <asac> yes
[16:47] <asac> you are right
[16:47] <Ubulette> http://lists.debian.org/debian-devel-announce/2007/11/msg00006.html
[16:48] <Ubulette> how come was I supposed to know ?
[16:53] <asac> i don't think so
[16:56] <Ubulette> asac, bluekuja; so, what about seamonkey ?
[16:58] <bluekuja> Ubulette, whatever is fine for asac is fine for me as well
[17:03] <Ubulette> asac, asac_ ^^
[17:07] <asac_> got reconnected
 asac, bluekuja; so, what about seamonkey ?
 Ubulette, whatever is fine for asac is fine for me as well
[17:10] <Ubulette> asac_ ^^
[17:15] <asac> Ubulette: can you reiterate the problem with sm?
[17:15] <asac> are there things that bluekuja wants to see improved?
[17:16] <Ubulette> we've just discussed the wording of the dummy packages. I reused the debian one, he wanted a different one
[17:16] <Ubulette> that's it
[17:17] <Ubulette> i just said it's minor and it could wait the next version
[17:18] <bluekuja> asac, actually dummy packages should have a specific description
[17:18] <bluekuja> asac, and not a default one as far as they are empty
[17:19] <asac> usually dummy packages read like: this is a transional package bla bla bla ... you can safely remove it once the package bla bla bla is installed
[17:20] <bluekuja> exactly
[17:21] <Ubulette> so tell debian
[17:21] <Ubulette> file a bug there ;)
[17:21] <Ubulette> well, if you really want to, i can fix it in this version
[17:22] <asac> i don't mind ... for the new transitional packages (e.g. iceape -> seamonkey) the wording should be right imo ... for mozilla -> iceape ... i have no opinion
[17:23] <asac> bluekuja: is that all?
[17:23] <asac> or anything else that needs to be fixed/checked before upload?
[17:23] <bluekuja> asac, I need to build it on hardy
[17:23] <bluekuja> asac, lintian was complaining about long-desc
[17:23] <bluekuja> but it's just minor
[17:23] <asac> yes
[17:24] <bluekuja> also for  postinst-has-useless-call-to-ldconfig
[17:24] <bluekuja> but I don't see why it reports that
[17:24] <bluekuja> asac: I need to build that on hardy, checking final files dirs
[17:25] <bluekuja> and then testing it
[17:25] <bluekuja> a bit
[17:25] <bluekuja> and then should be ready
[17:40] <Ubulette> asac, please review ff3 / xul from the .dev branches
[17:41] <Ubulette> btw, both tarballs contain the same thing as rc3
[18:03] <asac> Ubulette: i have bug 156187 for mozilla_five_home ... what was your bug number?
[18:03] <ubotu> Launchpad bug 156187 in firefox "core dump with application compied by firefox-dev under gutsy" [Medium,Incomplete] https://launchpad.net/bugs/156187
[18:09] <Ubulette> bug 157126
[18:09] <ubotu> Launchpad bug 157126 in mozilla-firefox "FF2 without default mozilla-five-home" [Undecided,New] https://launchpad.net/bugs/157126
[18:12] <Ubulette> asac, ^^
[18:13] <asac> Ubulette: ok
[18:13] <Ubulette> asac, that was an ff2 bug only.
[18:14] <Ubulette> a
[18:16] <asac> yes
[18:47] <Ubulette> asac, i'm done with the 18 changes for prism. what should I do, repost an updated package with the exact same version or bump ?
[18:49] <asac> Ubulette: hmm ... i think you have to bump the version otherwise revu will choke on it
[18:50] <asac> but not sure
[18:50] <asac> ask persia
[18:52] <asac> Ubulette: so you said that the bits are the same for xul and ffox rc3 -> beta1 ?
[18:52] <asac> (the origs)
[19:01] <Ubulette> yes
[19:03] <asac> Ubulette: so you didn't upload anything? i can just reuse the origs?=
[19:10] <Ubulette> asac, I didn't upload anything but I did fetch new tarballs using mozclient, so dirnames/filenames are ok
[19:10] <Ubulette> asac, oh, i've pushed those to my ppa
[19:13] <asac> ok
[19:27] <asac> debian has now nspr 4.7.0~1.9b1
[19:27] <asac> or is that in experimental?
[19:28] <Ubulette> no idea
[19:29] <asac> yeah its in unstable
[19:29] <asac> bluekuja: did your upload get sponsored?
[19:29] <asac> bluekuja: to debian?
[19:30] <asac> bluekuja: would like to reupload and see if anything got fixed
[19:30] <asac> ;)
[19:30] <bluekuja> asac, diff-ext upload?
[19:30] <bluekuja> or cgmail?
[19:30] <asac> no idea ... whatever failed because of my key
[19:30] <asac> yes cgmail it was
[19:30] <bluekuja> yep, it's already in...but I'm fixing a FTBFS on some archs for diff-ext
[19:30] <bluekuja> so you can test your key again
[19:30] <bluekuja> :)
[19:31] <bluekuja> asac, do you have an amd64 box?
[19:31] <asac> yes
[19:31] <bluekuja> asac, actually I cannot build that on PPA
[19:31] <asac> he?
[19:31] <bluekuja> it builds fine there
[19:31] <asac> what do you mean?
[19:31] <bluekuja> but fails on debian builds machines
[19:31] <asac> ah
[19:31] <Ubulette> asac, is that something similar to our package or completely unrelated ?
[19:31] <asac> i have a sid chroot
[19:32] <asac> Ubulette: we have a sync
[19:32] <asac> atm
[19:32] <Ubulette> ?
[19:32] <bluekuja> asac, it would be great if you can test the package before and after the fix
[19:32] <asac> Ubulette: e.g. unless we do something we will always get exactly the debian version auto-synched
[19:32] <bluekuja> asac, in the sid chroot as far as it FTBFS only
[19:32] <asac> Ubulette: https://edge.launchpad.net/ubuntu/+source/nspr/
[19:32] <bluekuja> and it's not a program issue
[19:32] <asac> look at -- Ubuntu Archive Auto-Sync <<EMAIL_ADDRESS> Tue,  23 Oct 2007 17:59:35 +0100
[19:33] <asac> bluekuja: give me branches :-P
[19:33] <bluekuja> asac, can I give you a dgettable url?
[19:33] <Ubulette> asac, I'd prefer to keep ours. it's quiltified and now uses our nobinonly
[19:33] <asac> what happend to your branches?
[19:34] <bluekuja> asac, nothing, they are updated
[19:34] <bluekuja> :)
[19:34] <bluekuja> and unstable got the latest revision
[19:34] <bluekuja> dgettable url for the fixed package
[19:34] <bluekuja> want to see if it fixes the issue before pushing it
[19:34] <bluekuja> let me grab the branches url
[19:35] <asac> Ubulette: yes. maybe mike would accept the quiltification ... is the diff minimal? so we can send it to him?
[19:35] <bluekuja> asac, https://code.edge.launchpad.net/~bluekuja/diff-ext/debian.source
[19:35] <bluekuja> and
[19:35] <asac> bluekuja: the upstream branch has diverged
[19:35] <bluekuja> mmm...are you sure about that?
[19:35] <bluekuja> I merged
[19:36] <bluekuja> the changes
[19:36] <Ubulette> asac, i've kept the changes minimal because you wanted to convince mike to use quilt remember ? but I haven't checked debian in a long while so I don't know
[19:36] <bluekuja> asac, actually you can just branch out the debian.source branch
[19:36] <bluekuja> and get the tarball from upstream
[19:36] <bluekuja> I grab you the link
[19:36] <bluekuja> so you bzr bd --merge
[19:36] <bluekuja> and that's all
[19:36] <Ubulette> asac, yet i know that nss b1 is not enough to do sm2 / xul trunk
[19:37] <asac> bluekuja: ok so your branches are still a mess :)
[19:37] <asac> just give me the dgettable url
[19:37] <asac> or all three urls
[19:37] <bluekuja> asac, ok, but I don't know why you get them as diverged
[19:37] <bluekuja> I'm *sure* I merged the changes back
[19:37] <bluekuja> strange then
[19:37] <asac> bluekuja: no idea ... you did different thing in your upstream branch ... e.g. you patched it et al
[19:38] <asac> bluekuja: merged back? upstream branches never need to be merged ... just updated
[19:38] <bluekuja> no, I mean debian.source
[19:38] <bluekuja> got merged
[19:39] <asac> bluekuja: anyway ... just give me orig.diff.gzand dsc thing
[19:39] <bluekuja> yep
[19:39] <asac> bluekuja: fix your upstream branch at some point :)
[19:39] <bluekuja> I will
[19:39] <bluekuja> I'll have to check stuff there again
[19:39] <asac> or only maintain debian/ directory + patchsystem
[19:39] <asac> makes things easier i guess
[19:41] <bluekuja> yep, as Ubulette does
[19:41] <bluekuja> it's better
[19:41] <bluekuja> ^^
[19:41] <bluekuja> asac, http://incoming.ibluepaper.com/diff-ext_0.2.3-3~ppa1.dsc
[19:42] <bluekuja> asac, this *should* FTBFS at some point
[19:42] <bluekuja> asac, going to eat in the meantime
[19:42] <bluekuja> don't worry about versioning ~ppa1.dsc
[19:42] <bluekuja> it's just a test
[19:42] <bluekuja> ;)
[19:49] <Ubulette> i've posted my comments and the updated package on revu. no idea what's next.
[19:50] <asac> Ubulette: let him confirm it
[19:50] <asac> he will from what i know
[19:50] <Ubulette> asac, persia complained about the length of changelog. what should I do ?
[19:50] <asac> then it gets sponsored
[19:50] <Ubulette> read my answer: http://revu.tauware.de/details.py?package=prism
[19:50] <asac> Ubulette: ping him on iRC and say that you fixed all those bugs, but not those ones et al.
[19:51] <Ubulette> i discussed with him earlier today
[19:51] <Ubulette> [16:17] <persia> Ubulette: some comments added to start.  There's likely more, but I'm to bed, and there's enough there for another revision.
[19:51] <Ubulette> don't know what TZ he's in so i'll wait
[19:52] <asac> Ubulette: did you reupload?
[19:52] <Ubulette> yes
[19:52] <asac> Ubulette: ok then fine
[19:52] <Ubulette> read #12
[19:53] <asac> yeah ... i don't think its a problem
[19:54] <asac> if he gets too anal, i can comment as well ... but let him go ahead ... i think once you went through all this he will like you more than before and he has a strong council involvement.
[19:54] <Ubulette> lol
[20:00] <Ubulette> asac, for xul post 1.9b1 (and sm2 trunk), we need nss at least NSS_3_12_ALPHA_2B which is ahead of 1.9b1 so the debian one is no good for us
[20:01] <Ubulette> we can do a real 3.12.0~a2b
[20:01] <bluekuja> asac, back
[20:01] <asac> this upload will be still without system-nss
[20:01] <bluekuja> asac, did it FTBFS?
[20:01] <asac> Ubulette: lets try to target new system nss for b2
[20:01] <asac> maybe before
[20:02] <Ubulette> asac, sure (b1)
[20:02] <asac> i have to write the roadmap for xul migration tomorrow
[20:02] <Ubulette> i've faced the problem within my ppa. 3.12.0~a2b < 3.12.0~cvs :(
[20:02] <asac> i will include it in that document
[20:02] <asac> what is a2b?
[20:03] <Ubulette> NSS_3_12_ALPHA_2B
[20:03] <Ubulette> current req in 1.9b2pre
[20:03] <Ubulette> mozilla bug 403680
[20:03] <ubotu> Mozilla bug 403680 in Libraries "CERT_PKIXVerifyCert fails if CRLs are missing" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=403680
[20:03] <asac> well its still cvs so lets name it ~cvs+a2b :)
[20:04] <asac> bluekuja: nope ... haven't even grabbed it :)
[20:04] <bluekuja> asac, lol
[20:04] <bluekuja> asac, I'll go for a showa then
[20:04] <bluekuja> :P
[20:04] <Ubulette> and btw, i've moved the addons in xul b1
[20:04] <bluekuja> bbl
[20:07] <asac> Ubulette: yes i saw that t... thanks
[20:07] <asac> i planned that as yet-another-last-minute change this morning ;)
[20:08] <asac> do we have a global plugins dir as well now?
[20:08] <asac> for xul?
[20:08] <Ubulette> yes
[20:08] <Ubulette> asac, http://paste.ubuntu.com/2224/
[20:09] <asac> fine
[20:09] <asac> Ubulette: ok ... i plan to have all main plugins migrated to xul 1.9 by alpha 3
[20:09] <asac> so at best starting before alpha 2
[20:10] <Ubulette> i still preserved /usr/lib/firefox-3.0/plugins for b1 as we need to figure out what could be shared or not
[20:11] <asac> Ubulette: why don't we have /usr/lib/firefox-addons/ ?
[20:11] <asac> any reason?
[20:11] <asac> or just by evolution?
[20:11] <Ubulette> none. ff3 is not shipping any plugin at the moment
[20:12] <Ubulette> all i have in there is links i've done myself a long time ago
[20:12] <asac> Ubulette: hmm ... i just wonder why we still have the unversioned directory?
[20:12] <asac> for ffox
[20:12] <Ubulette> we did it intentionally remember ?
[20:13] <asac> did we?
[20:13] <asac> i think we did ... just wonder if the reason is still valid ;)
[20:14] <Ubulette> -installdir     = $(libdir)/$(MOZ_APP_NAME)-$(MOZ_APP_VERSION)
[20:14] <Ubulette> +installdir     = $(libdir)/$(MOZ_APP_NAME)
[20:14] <Ubulette> the plugin dir is one reason
[20:14] <asac> yes i think thats from the time when i started the package based on what i had in 2.x
[20:14] <asac> but now that we have started to host extenssions/ plugins for xul in some other dir, we could do the same for ffox i guess
[20:15] <Ubulette> bzr blame firefox-fsh
[20:15] <Ubulette> oops
[20:15] <asac> Ubulette: i am sure thats my hack
[20:15] <Ubulette> 39  asac@jw | -installdir       = $(libdir)/$(MOZ_APP_NAME)-$(MOZ_APP_VERSION)
[20:15] <Ubulette> 44  fta+lau | +installdir       = $(libdir)/$(MOZ_APP_NAME)
[20:15] <Ubulette> nope :)
[20:15] <asac> hmm ... i had the -instaldir ;)
[20:15] <asac> so it probably is pretty similar ;)
[20:16] <asac> i think i had firefox-3.0 hardcoded
[20:16] <asac> or something :)
[20:16] <Ubulette> it's easy to revert.
[20:16] <Ubulette> well maybe not
[20:16] <asac> yeah ... we have to fix the extensions + plugins dir i think
[20:17] <Ubulette> worse.
[20:17] <Ubulette> the usr/lib vs usr/share
[20:17] <Ubulette> and the gnome split
[20:18] <Ubulette> easy with hardcoded paths, not so easy with dynamic paths
[20:18] <Ubulette> in xul, we don't do usr/share
[20:18] <asac> Ubulette: wildcards in .install doesn't work?
[20:19] <asac> and then using wildcards in rules fo dh_link?
[20:19] <asac> like we did in xul?
[20:19] <armin76> Mozilla/5.0 (X11; U; Linux ia64; en-US; rv:1.9b1) Gecko/2007112520 Firefox/3.0b1
[20:19]  * armin76 throws stuff at asac
[20:19] <asac> armin76: well done
[20:19] <asac> you patch or did you find any?
[20:19] <armin76> mine
[20:20] <asac> armin76: you can decide: either submit it upstream and let us include the patch from there or let us include first and if all works out well submit upstream
[20:21] <armin76> you pay :P
[20:23] <Ubulette> asac, I can revert the path but do we really want that in b1 or post b1 ?
[20:23] <asac> bluekuja: sid chroot still upgrading ... takes ages i guzess
[20:24] <asac> Ubulette: hmm ... i would prefer to have the final paths in ffox 3 so we can start to migrate things right away
[20:24] <asac> (not yet sure how to proceed with gutsy though)
[20:24] <asac> Ubulette: if its too much work we can update after b1 release
[20:24] <asac> e.g. do another upload in a week or so
[20:25] <Ubulette> let me try to see the impact
[20:25] <Ubulette> in the meantime, feel free to review my changes in xul since rc3
[20:26] <Ubulette> i'm sure you'll find some last minute thing ;)
[20:26] <asac> from what i saw it look good ... yeah :)
[20:26] <asac> anyway, still working on security builds
[20:27] <asac> but last build should finish soon ... then i have to QA them and upload
[20:27] <asac> but i can spin xul and ffox 3 while QAing i guess
[20:28] <Ubulette> i've waited for you before closing changelog, that's the only thing left i could think of.
[20:30] <Ubulette> asac, we'll have to think about the langpacks soon. who did the ff2 ones ?
[20:32] <armin76> asac: i'll give you the patch when i fix it, i want to clean it up first :)
[20:33] <bluekuja> asac, back
[20:34] <bluekuja> asac, if you can't make it for today, I might go to watch tv
[20:34] <bluekuja> :)
[20:36]  * Ubulette is sitting on seamonkey
[20:37] <bluekuja> Ubulette, at the end everything is fine for asac about sm?
[20:37] <Ubulette> you told him you'll check so he didn't
[20:38] <Ubulette> asac, right ?
[20:38] <bluekuja> k, fine
[20:40] <asac> Ubulette: we got them from debian ... then i updated them
[20:40] <asac> Ubulette: we need someone to take over mass langpacks + mass extension packaging ;)
[20:40] <asac> Ubulette: i hoped for jazzva or mertiki ;)
[20:41] <bluekuja> asac, where is mertiki?
[20:41] <bluekuja> I don't see him since weeks
[20:41] <asac> Ubulette: spell checking works right, right?
[20:41] <asac> bluekuja: no idea :)
[20:41] <bluekuja> aww :/
[20:41] <asac> when was jazzva last seen?
[20:41] <Ubulette> asac, yes. i'm using it all the time :)
[20:41] <bluekuja> !seen mertiki
[20:41] <ubotu> Sorry, I don't know anything about seen mertiki - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[20:41] <bluekuja> damn
[20:43] <bluekuja> Ubulette, do you know a working !seen command for ubotu?
[20:43] <Ubulette> no sorry
[20:43] <asac> Ubulette: actually i think that the langpacks will be produced by translations.launchpad.net
[20:43] <asac> from what i know .xpis now work
[20:43] <asac> no idea what is produced in the end though
[20:43] <armin76> ubotu: seen mertiki
[20:43] <ubotu> Sorry, I don't know anything about seen mertiki - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[20:44] <Ubulette> Oct 17 05:28:29 *       mertiki has quit (Client Quit)
[20:44] <Ubulette> last time here
[20:44] <asac> yeah
[20:44] <asac> Ubulette: i think the translation team will regularly import all langpacks
[20:44] <asac> and then export something for us
[20:44] <asac> e.g. import .xpis from upstream ... then export whatever format ;)
[20:45] <asac> i think the translations guy who took the lead for xpis is on honeymoon for the rest of the year unfortunately
[20:45] <Ubulette> upstream already has those langpacks (since b1)
[20:45] <asac> yes they have ... but we will be the new lead for ffox translations :)
[20:45] <Ubulette> hmm
[20:45] <asac> well ... actually the langpacks often where not complete
[20:46] <asac> so we will add the content missing
[20:46] <asac> in the end i hope to push the work of packaging to those guys from launchpad :)
[20:46] <asac> no idea if it works though
[20:46] <asac> i will add it to the roadmap document i have to write
[20:47] <asac> extensions + langpacks + plugins :)
[20:47] <asac> for extensions i would like to tap the community to pick the most important ones
[20:47] <asac> like ... the top 50 extensions get into main ;)
[20:50] <Ubulette> usr/lib/firefox-addons/plugins  .. hmm. looks weird
[20:50] <Ubulette> as extensions go to usr/lib/xulrunner-addons/extensions
[20:50] <asac> why?
[20:50] <asac> Ubulette: well ... the advice is: ship extensions that are of general nature (e.g. applicable for more than just firefox) in xulrunner addons
[20:50] <Ubulette> meaning there's no usr/lib/firefox-addons/extensions
[20:51] <asac> the firefox only ones in firefox-addons
[20:51] <asac> we should have that
[20:51] <asac> oh ... now i remember :)
[20:51] <Ubulette> but so far, the code only uses 1 dir
[20:51] <asac> right ... thats what i wanted to fix ... which is what i just remembered ;)
[20:53]  * asac hates ever growing TODO lists
[20:53] <asac> btw, i managed to port yelp and devhelp
[20:53] <asac> so there is just the epiphany beast left i guess
[20:54] <asac> (in main)
[20:54] <Ubulette> what about python ?
[20:54] <asac> thats done as well
[20:54] <asac> its just url-classifier breakage that persists
[20:54] <Ubulette> i still have those ugly warnings from xul1.9
[20:54] <asac> i have a problem that i blame onto url-classifier in devhelp too: the .css file is not applied
[20:55] <Ubulette> and I need to recheck miro once you land your python fix
[20:55] <asac> so it looks a bit funny ... but the gecko embed part is good apparently
[20:55] <asac> Ubulette: yes. i would like url-classifier fixed before i can send xul to main
[20:55] <asac> then the official porting would start
[20:59] <asac> hmm ... i think we have to look into openoffice
[20:59] <asac> or at least assist the maintainer ... afaik it has a build-depend on firefox or xulrunner
[21:00] <asac> painful i guess
[21:00] <Ubulette> do we really need to split ff3 in usr/lib and usr/share ?? it's a pain in the **
[21:01] <Ubulette> or can we do like xul ?
[21:01] <Ubulette> just ship like upstream
[21:02] <asac> well its 2.5M of 11M ... so its a good proportion for ffox 3
[21:02] <Ubulette> so ?
[21:04] <asac> i am not sure ... if the package is indep .. there isn't much use of share thing i guess
[21:04] <asac> but thats just me
[21:04] <asac> s/package is indep/package isn't indep/
[21:04] <Ubulette> it's not. there are still some .so
[21:04] <asac> other people appear to find it more important though
[21:04] <asac> in chrome?
[21:05] <asac> for me there isn't an .so in chrome/ for xul
[21:05] <asac> but i am not sure if all .jars are arch indep
[21:05] <Ubulette> components
[21:05] <asac> yeah ... i just talk about chrome
[21:06] <Ubulette> tmp/usr/lib/firefox-3.0-3.0b1/components/libnkgnomevfs.so
[21:06] <asac> Ubulette: i don't claim that ffox 3.0 is indep
[21:06] <asac> i just say that i don't see benefit out of putting things into /usr/share if those are shipped from an arch dependent .deb
[21:07] <asac> but then ... i have not idea how people that share /usr/share across archs actually manage their packages so they stay in sync
[21:07] <Ubulette> good. same for me. and it's less error prone
[21:07] <asac> but maybe you know :)
[21:08] <asac> Ubulette: be double sure that the upgrade path is correct :)
[21:08] <asac> if you go for pkglib only
[21:09] <Ubulette> i've managed a huge network with 7 unix vendors a longtime ago and that kind of split was important, here, I'm not aware of a single case of usr/share really shared
[21:15] <Ubulette> searchplugins could be moved too
[21:15] <Ubulette> that makes sense
[21:16] <Ubulette> usr/share/firefox-addons/searchplugins  ?
[21:24] <Ubulette> hmmm. in fact, there's no plugins dir at all in debian/tmp. only in xul. good.
[21:28] <asac> Ubulette: if use/share wasn't shared, then why did it matter except for archive size?
[21:28] <asac> yes
[21:28] <asac> (for searchplugins to -addons)
[21:32] <Ubulette> asac, yesterday, i noticed that ff2008 is reporting a lot of corrupted jpg in wikipedia while ff3 is perfectly fine with the same pages
[21:32] <asac> Ubulette: you have an example page?
[21:33] <asac> .10 will come tomorrow i hope
[21:34] <Ubulette> hmm. i can't reproduce.
[21:34] <Ubulette> oh i see
[21:35] <Ubulette> ff2 was started from google earth, maybe ld_library_path is tweaked and pointed to another libjpeg
[21:39] <Ubulette> bingo. /usr/lib/libjpeg.so.62.0.0 vs /usr/lib/googleearth/libjpeg.so.62
[21:41] <asac> yeah
[21:41] <asac> i wonder why people complain about google toolbar being broken with guty ffox
[21:41] <asac> it works for me
[21:42] <asac> oh it really loops
[21:42] <asac> apparently not default-five-home
[21:43] <Ubulette> ?
[21:44] <asac> great google toolbar ships its .js file without linebreaks
[21:47] <Ubulette> lol
[21:48] <asac> how innovative ;)
[21:48] <Ubulette> obfuscation
[21:54] <asac> http://groups.google.com/group/FFToolbar-Group-Bugs/browse_thread/thread/d32b039cb2f92ff5/169b421268351699?lnk=gst&q=
[21:58] <asac> {try{var dir=Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("ProfD",
[21:59] <asac> Components.interfaces.nsIFile);dir.append("extensions");dir.append("staged-xpis");dir.append("{3112ca9c-de6d-4884-a869-9855de68056c}");if(dir.exists()){dir.remove(true)}}catch(e){}
[21:59] <asac> what are they doing?
[22:00] <asac> hmmm thats in doXPIInstall ... guess thats just for seamonkey
[22:03] <Ubulette> hmm, remove ~/.mozilla/ff/extensions/staged-xpis/{3112ca9c-de6d-4884-a869-9855de68056c} if it exists ?
[22:06] <asac> i think its seamonkey only ... e.g. no-extension manager
[22:06] <asac> well they ship libgoogletoolbar.so
[22:06] <asac> which expects libnspr4.so
[22:06] <asac> maybe thats a problem?
[22:08] <Ubulette> you're talking about ff2 right ?
[22:08] <asac> yes
[22:08] <asac> does it work in 3?
[22:13] <Ubulette> i'm not using it
[22:32] <Ubulette> i think i'm done with ff3..
[23:26] <Ubulette> asac, ok, pushed and tested
[23:27] <Ubulette> well, tested, then pushed :)
[23:36] <armin76> Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:1.9b1) Gecko/2007112521 Firefox/3.0b1
[23:36] <armin76> plop :D
[23:38] <Ubulette> good for you


[06:52] <dholbach> good morning
[15:52] <dholbach> ajmitch, wendar: is qreator getting into extras already?
[15:53] <dholbach> highvoltage, stgraber: ^
[15:53] <stgraber> no idea (sorry, not much time for ARB stuff lately) :)
[16:24] <highvoltage> dh<tab>


[12:10] <znf> still no 'updated' mini.iso with 24.04 https://cdimages.ubuntu.com/ubuntu-mini-iso/daily-live/current/
[12:12] <znf> https://i.imgur.com/3rQfGQg.png
[12:12] <znf> and 23.10 is tagged as LTS lol