[08:28] <nysosym> hi all :)
[09:44] <nysosym> hi aboe :)
[09:45] <aboe> hi nysosym
[09:45] <aboe> how are you
[09:46] <aboe> troy_s, are you busy??
[09:56] <nysosym> aboe: ohh i feel fine, thx
[09:56] <nysosym> hi andreasn :)
[09:56] <nysosym> and troy_s :)
[09:57] <aboe> hehe, if they are awake...looks like nap time for some people...
[09:57] <andreasn> hi there
[09:58] <nysosym> aboe: hehe no, i have played with some graphics :)
[09:58] <aboe> nysosym, I wanted to ask if the murrine-gtk engine could be included in edgy universe or multiverse repo...I think it makes a good addition to ubuntu-looks engine
[09:58] <aboe> what are you working on??
[10:00] <nysosym> aboe: nothing special, only a little learning with inkcape
[10:00] <aboe> inkscape is a cool program I could never get the hang of it...
[10:02] <nysosym> hmm
[10:02] <Madpilot> aboe, there's an excellent manual written for it
[10:02] <nysosym> i don`t understand that question (?) Can anyone help me :D
[10:02] <nysosym> How many of these emblems are replacements for existing emblems in the Human icon set, and how many are new (in the sense that there is not already an emblem in Human?)
[10:03] <Madpilot> http://tavmjong.free.fr/INKSCAPE/
[10:03] <aboe> I know but graphics isn't my thing...I don't have the patients for it or the skills...me just package stuff
[10:03] <aboe> and build
[10:05] <aboe> he's asking which emblems are being replaced with the human icon set. and which emblem icons are new or added by the human icon set...
[10:05] <aboe> I think...hehehe :)
[10:06] <aboe> Madpilot, that's a very good manual...like the style it's written in
[10:07] <Madpilot> yeah, it's well done
[10:08] <nysosym> aboe: hmm i have made these emblems, to match with the human icon theme. For replace all "old" gnome emblem when human in use.
[10:08] <nysosym> thats would be my answer ^^
[10:08] <aboe> hope that's what the question was about....
[10:09] <aboe> :) hehe :)
[10:10] <nysosym> sure? ^^
[10:13] <aboe> nysosym, I also got a question...about icon-themes? it's about synaptic, Only the refresh icon is themed....?
[10:16] <nysosym> aboe: no, the refresh icon, the properties icon and the apply icon works perfectly here
[10:17] <nysosym> only "mark all" and "search" looks like "old"
[10:17] <aboe> what about update and apply...I'm using the normal tango theme that can be installed with edgy
[10:20] <aboe> did I do something wrong when I installed the theme...or maybe there isn't any tango icons for those yet and that's why it goes back to default gnome...
[10:20] <AnAnt> how do I change the gnome splash screen ?
[10:23] <aboe> nysosym, you're right if I use the human theme the icons in synaptic are changed, but with the tango theme they aren't...
[10:23] <nysosym> :)
[10:24] <aboe> he goodbye everybody got to go to work...bleuh :(
[10:28] <AnAnt> found it : /usr/share/pixmaps/splash/
[11:27] <nysosym> re
[12:26] <fschoep> Hi all
[12:32] <fschoep> Hi lapo
[12:33] <lapo> yo fschoep
[12:34] <fschoep> lapo: How are you doing?
[12:34] <lapo> doing fine, thanks
[12:36] <lapo> fschoep: how is the artwork refresh going?
[12:36] <fschoep> lapo: well, we're working with Mark on creating a new GDM and wallpaper
[12:36] <fschoep> lapo: so far, making good progress
[12:36] <fschoep> lapo: other areas are going well, too - Theme Team work should go in shortly
[12:36] <fschoep> lapo: Human iconset expanded, Firefox themes doing fine
[12:37] <fschoep> lapo: now looking into adding emblems for the Human theme
[12:37] <fschoep> lapo: and lots more :)
[12:37] <fschoep> lapo: sounds, too!
[12:37] <lapo> sounds cool
[12:38] <lapo> apropos sound the logout sound is way too long :-/
[12:38] <mneptok> hopefully we can have that in edgy+1
[12:39] <fschoep> mneptok: have you made a specification already?
[12:40] <mneptok> no, waiting until we have permission to use it, and then trying to convince the author to attend the dev summit to work on it
[12:40] <fschoep> mneptok: I see, I hope all goes well
[12:40] <mneptok> if i can get those 2 things done, i'll have someone else write the spec. i'm kinda buried with other stuff.
[12:41] <fschoep> mneptok: the author doesn't necessarily have to attend the dev summit
[12:41] <fschoep> mneptok: I also think the deadline for sponsorship has passed
[12:41] <mneptok> fschoep: i know, but if he does, *he* can write improvements. two words. "diminished responsibility" ;)
[12:41] <fschoep> mneptok: so he would have to pay for the trip and accomodation :)
[12:42] <mneptok> fschoep: he lives in the SF area. works at Pixar.
[12:42] <fschoep> mneptok: I see, that's relatively close, isn't it?
[12:44] <mneptok> aye
[12:44] <mneptok> ~25 miles or so
[01:39] <nysosym> hi all :)
[01:41] <nysosym> ohh very silent ^^
[01:42] <nysosym> hi fschoep :)
[01:42] <fschoep> Hi nysosym
[01:42] <fschoep> nysosym: working on your emblems now, good things do happen you see :)
[01:43] <nysosym> sure, by problems, i`m here :D
[01:43] <fschoep> nysosym: I've got some comments
[01:44] <fschoep> nysosym: The circle aren't entirely round it seems, they more wide than tall
[01:44] <fschoep> circles*
[01:44] <nysosym> really ? *confused*
[01:44] <fschoep> nysosym: On top of that I noticed the top gloss gradient doesn't run to white (#FFFFFF) but to some light shade of grey, was that intentional?
[01:46] <nysosym> one moment please :)
[01:46] <fschoep> nysosym: sure, take your time
[01:49] <nysosym> To the 1. point i have checked some icons and these have the same height and width (in inkscake checked, only the graphic)
[01:51] <fschoep> nysosym: odd, let me check again :)
[01:52] <nysosym> To the 2. point, yes this is intentional, because the folder icons although didn't have a white gloss, for the emblems i have uses one to match witch the folders. :)
[01:53] <fschoep> nysosym: right
[01:53] <nysosym> :D
[01:53] <fschoep> nysosym: OK, no problem then - I'll work on getting them working first, then we'll discuss details if there are any left
[01:53] <fschoep> nysosym: deal?
[01:54] <nysosym> some of my icons works here very good as emblem (24x24)
[01:54] <nysosym> deal :)
[01:54] <nysosym> mom *make s screenshot*
[01:58] <nysosym> http://www.250kb.de/u/061004/p/c78ec8f5.png
[01:59] <nysosym> i have checked only a few icons and all works good here :)
[01:59] <fschoep> nysosym: looking good, are you sure emblems should be 24x24 and not 32x32? I think the default ones are 32
[01:59] <andreasn> is that a eagle?
[01:59] <nysosym> eagle?
[01:59] <fschoep> andreasn: it's a globe
[01:59] <fschoep> andreasn: ;)
[01:59] <andreasn> oh
[01:59] <nysosym> ^^
[01:59] <andreasn> sorry
[02:00] <nysosym> no problem
[02:00] <andreasn> took a rough guess
[02:00] <fschoep> andreasn: no problem, it's a bit hard to see at 24x24 so that's why I'm proposing 32
[02:00] <andreasn> you need to provide emblems in all sizes
[02:00] <nysosym> fschoep: hmm thats a good point, personally i think 24x24 is a good size (on 1280x1024)
[02:01] <fschoep> andreasn: tell me more
[02:01] <andreasn> fschoep: well, if you use like 4000x3000 (or whatever)
[02:01] <fschoep> andreasn: we have scalable SVGs as well, would that be good?
[02:01] <andreasn> fschoep: the system should be able to use the scalable emblem and blow that up
[02:02] <fschoep> andreasn: right, so we don't prerendered ones?
[02:02] <andreasn> and if you have nautilus set to tiny folders (like 25%) you don't want blurry ones
[02:02] <andreasn> prerender the small sizes, but supply svg as well
[02:02] <andreasn> as prerender is faster
[02:03] <fschoep> andreasn: I see, thanks for the advice - I'm going to try and get them working now, then
[02:06] <andreasn> http://ramnet.se/~nisse/diverse/temp/blurry-emblem.png
[02:06] <andreasn> that emblem is 32x32
[02:06] <nysosym> andreasn: sure, but the original gnome icon theme, has the main part of emblems only in 48x48. I agree with u, but this let me a little bit confused
[02:07] <andreasn> yeah, but in gnome-icon-theme, all icons used to have only one size, and that made the whole system look blurry
[02:07] <andreasn> or, well, not all, but most of them
[02:08] <troy_s> fschoep
[02:08] <fschoep> troy_s: troy_s
[02:08] <andreasn> I'm not 100% sure if nautilus pick the right size all the time though, I've noticed a bunch of bugs here and there when using pixel perfect sets
[02:09] <fschoep> troy_s: speak your mind
[02:11] <fschoep> andreasn: nysosym: I'll try to get the basics working first, we can work on retouching smaller versions later on, right?
[02:12] <nysosym> right :)
[02:13] <andreasn> http://ramnet.se/~nisse/diverse/temp/not-blurred-emblem.png
[02:13] <andreasn> ah, it seems nautilus picks a good size
[02:13] <andreasn> when you have emblems in the right size
[02:13] <fschoep> andreasn: good to hear, I'll make sure to test around with it once we've got everything set
[02:14] <andreasn> sure
[02:14] <fschoep> troy_s: ping ?
[02:14] <troy_s> how you doing fschoep, sorry was checking mail
[02:14] <fschoep> troy_s: fine, thanks. I hope you are well as well
[02:17] <nysosym> wrong button...
[02:18] <nysosym> hmm damn, i must go to work at 3 o`clock and it`s 2:18PM...
[02:18] <nysosym> working on graphics use a lot of time....
[02:23] <nysosym> fschoep: we should use 32x32 scalable
[02:24] <fschoep> nysosym: OK
[02:24] <nysosym> sry for many work :(
[02:28] <nysosym> fschoep: i have testet that nautilus scales svg's very well in every size
[02:28] <fschoep> nysosym: OK, good
[02:28] <fschoep> nysosym: should I just place your SVGs in /scalable then?
[02:28] <nysosym> the only problem should be the performance, but i can`t reproduce any lags on my machine 2600+
[02:28] <nysosym> yes, here all works very well
[02:29] <nysosym> i must go to work now
[02:29] <fschoep> OK, I'll go and try that
[02:29] <nysosym> thx for all :-*
[02:29] <nysosym> bye guys!!
[02:29] <fschoep> nysosym: cu later
[02:29] <fschoep> nysosym: be good :)
[02:29] <nysosym> ever! :D
[03:13] <fschoep> Hey PingunZ
[03:13] <fschoep> PingunZ: don't know if Jonathan already told you, but your GDM should be in quite soon I think
[03:14] <fschoep> I packaged it on Monday
[03:14] <PingunZ> fschoep: What gdm .. do I have to make a gdm ?
[03:14] <PingunZ> Or the one I already made ? :)
[03:14] <fschoep> PingunZ: the Blubuntu one
[03:14] <PingunZ> I already made ?
[03:14] <fschoep> PingunZ: it's probably going into Edgy this week
[03:14] <fschoep> PingunZ: yes
[03:15] <PingunZ> Sooo .. do I need to do something ?
[03:15] <fschoep> PingunZ: no, you already did your part of the work
[03:15] <PingunZ> Exept kiss you cause your incuding it :):D
[03:15] <fschoep> PingunZ: you're welcome ;)
[03:15] <PingunZ> Btw.. sorry for being inactive .. but I don't want to fail on school again ;)
[03:16] <fschoep> PingunZ: don't worry, there is more than Ubuntu
[03:16] <PingunZ> I know :) .. Suse, debian, Gentoo .. :D
[03:16] <fschoep> PingunZ: right
[03:16] <PingunZ> Thanks for including it fschoep :) I really like that
[03:17] <fschoep> PingunZ: no problem, I hope it gets uploaded soon
[03:17] <PingunZ> Btw .. Thanks for making me a moderator too :)
[03:18] <PingunZ> Rofl .. all I do is thanking tou ! :)
[03:18] <fschoep> PingunZ: ;)
[03:18] <PingunZ> How's your appla battery charger going ?
[03:19] <fschoep> PingunZ: good, thanks
[03:19] <fschoep> PingunZ: got a new one the day after calling Apple
[03:20] <PingunZ> That's what they call service .. :)
[03:20] <fschoep> PingunZ: I also ordered an Apple keyboard and mouse so I now use my Macbook as the main computer on my main display
[03:20] <fschoep> I use Linux over X11 ;)
[03:20] <PingunZ> Lemme guess 20" Lcd ? :)
[03:20] <fschoep> PingunZ: that's also the reason why I'm on IRC way more often now :0
[03:20] <PingunZ> Wich is great ;)
[03:21] <fschoep> Yes, I got used to it I think
[03:21] <PingunZ> Woah this rocks .. My work will be in the default install of ubuntu ?  It should be pretty certain it's going to be in there, but the decision is now out of my reach.
[03:22] <PingunZ> Oh ;)
[03:22] <fschoep> PingunZ: I packaged and modified it on Monday and asked Daniel to upload it. He's sitting on it now.
[03:22] <PingunZ> Daniel -> Who ?
[03:23] <fschoep> Daniel Holbach, the funny German guy?
[03:23] <PingunZ> Never heard of .. :)
[03:23] <fschoep> PingunZ: now you have, then
[03:23] <PingunZ> What's his nick
[03:23] <PingunZ> *?
[03:23] <fschoep> dholbach on IRC and Launchpad probably
[03:23] <PingunZ> Never heard of ..
[03:23] <fschoep> https://launchpad.net/people/dholbach
[03:24] <PingunZ> O_o He is like admin of 10 teams ? :D
[03:24] <fschoep> Daniel does a lot of different things yes
[03:25] <fschoep> He's a core-dev so he can work on Ubuntu as a job
[03:25] <PingunZ> Btw .. Have you seen my compiz theme .. its rated #1 on gnome-look :)
[03:25] <PingunZ> http://www.gnome-look.org/content/show.php?content=45690
[03:26] <fschoep> Nice, looks a bit like Vista I think :)
[03:26] <fschoep> You should make the close button a bit bigger ;)
[03:26] <PingunZ> Yes .. I think vista *looks* nice
[03:26] <fschoep> Right, and we've *so* had it with Mac OS X Aqua looks
[03:26] <PingunZ> Yes .. I just used someone else's buttons :)
[03:26] <PingunZ> I know ;)
[03:27] <PingunZ> I'll try to make some .. but its not really my err .. speciality :D
[03:27] <fschoep> I use Mac OS X aqua borders on my install... of Mac OS X
[03:27] <PingunZ> But I'll do my best ;)
[03:28] <PingunZ> fschoep: When can I propose a themeteam for edgy+1  ?
[03:29] <fschoep> PingunZ: probably early next cycle
[03:29] <fschoep> PingunZ: I'm not sure who'll be in my position for Edgy +1
[03:29] <PingunZ> And .. can themeteams also cover Openoffice, gimp, xara splashes ?
[03:29] <PingunZ> fschoep: You're the AiC, does it change every cycle ? :|
[03:29] <fschoep> PingunZ: we're going to need to take a look at that. We considered that for Edgy, but it's already proven to be difficult to deliver four pieces of artwork for Human.
[03:30] <PingunZ> Hmm .. :)
[03:30] <fschoep> PingunZ: Yes, Mark suggested rotating the AiC for each release.
[03:30] <PingunZ> Why is that ?
[03:30] <fschoep> PingunZ: to have multiple people get experience doing so
[03:30] <PingunZ> I think you're doing pretty great :)
[03:31] <fschoep> thank you
[03:31] <PingunZ> If we could vote once .. I'll vote for you ^^
[03:31] <fschoep> hehe, that's nice to hear, but let's not get ahead of ourselves
[03:31] <PingunZ> ;)
[03:31] <fschoep> Mark will explain his plan soon I think
[03:31] <PingunZ> Ok ;)
[03:32] <fschoep> he's already started looking forward for Kubuntu, so Ubuntu'll be next I think
[03:32] <fschoep> Hi Cadet, back again?
[03:34] <fschoep> Hmm, I need to go and get some stuff I ordered for printing, does anyone have urgent matters to discuss right now?
[03:36] <fschoep> Right. I'll let my Macbook fall to sleep and disconnect, then. See you guys in an hour or so.
[06:01] <ppd> hello everyone
[06:08] <PingunZ> hey ppd
[06:08] <ppd> hi PingunZ
[06:15] <PingunZ> troy_s: You there ? I'd like to discuss your GDM :)
[06:47] <Faisal> hi
[07:02] <bersace> troy_s: ping
[07:07] <fschoep> OK, that was just a really long hour.
[07:22] <PingunZ> fschoep: will my name still be in the GDM description ? :)
[07:22] <fschoep> PingunZ: yes
[07:22] <PingunZ> Wohoo :)
[07:22] <PingunZ> Thanks !
[07:22] <fschoep> PingunZ: both your real name and nickname
[07:23] <PingunZ> When will I know if it'll be included in Edgy ?
[07:23] <fschoep> PingunZ: as soon as I know
[07:23] <PingunZ> Rofl :)
[07:23] <fschoep> PingunZ: :)
[07:24] <PingunZ> No ETA ? :D
[07:24] <fschoep> PingunZ: no, sorry
[07:24] <fschoep> brb
[07:25] <PingunZ> ok ;)
[07:29] <fschoep> Right, I really don't know yet what will happen, but of course I am trying my best to push for inclusion and to have them on the CD.
[07:37] <PingunZ> fschoep: Thanks m8 ;) I really like appreceate that ;)
[07:37] <PingunZ> Or however you write that :)
[09:22] <ppd> hi
[09:23] <fschoep> Hi ppd
[09:23] <PingunZ> Hi ppd & fschoep :)
[09:23] <fschoep> Hi PingunZ
[09:24] <ppd> Hi fschoep & PingunZ
[09:24] <PingunZ> With the new beryl compiz
[09:24] <fschoep> PingunZ: can I give you a task :) ?
[09:25] <PingunZ> Yes you can :)
[09:25] <fschoep> PingunZ: OK it's an easy one probably
[09:25] <PingunZ> Ok ;)
[09:25] <fschoep> PingunZ: Did you see Eric's mail to the list on the new orange Human emblems?
[09:25] <PingunZ> Yes
[09:25] <fschoep> PingunZ: I need you to find out how to replace emblems in the Human icon set
[09:25] <fschoep> PingunZ: sounds doable?
[09:26] <fschoep> PingunZ: I'm a bit busy fixing some other bugs so if you can help that'd be awesome
[09:26] <PingunZ> /usr/share/icons/human/emblems/
[09:26] <PingunZ> I don't really get it ..
[09:26] <fschoep> ;)
[09:26] <fschoep> If you place icons in that folder, they don't seem to get updateed
[09:26] <fschoep> updated*
[09:26] <PingunZ> You just extract the emblems into the icons folder
[09:27] <PingunZ> Well refresh your theme in theme manager ;)
[09:27] <fschoep> Really? I had no luck doing so.
[09:27] <PingunZ> That's how I would do it ;)
[09:27] <fschoep> Show me a screenshot you managed to change 'em then :)
[09:27] <PingunZ> Ok :)
[09:27] <fschoep> PingunZ: If you manage to do it, you'll get a cookie :0
[09:27] <PingunZ> Yay ! :D
[09:31] <nysosym> gooood evening :)
[09:32] <PingunZ> fschoep: Cookies ready ?
[09:32] <fschoep> PingunZ: yes, apple cake even
[09:33] <PingunZ> Nice :)
[09:33] <fschoep> Get it - "Apple" cake
[09:33] <fschoep> ;)
[09:33] <PingunZ> ^^
[09:33] <fschoep> nysosym: PingunZ is proving me it's easy to add your emblems
[09:33] <PingunZ> I just did
[09:33] <PingunZ> I'm uploading the screenie :)
[09:33] <PingunZ> http://img518.imageshack.us/img518/7674/screenshotgg6.png
[09:34] <PingunZ> Say I'm 1337 :D
[09:34] <nysosym> ahhh cool :)
[09:34] <nysosym> nice work :)
[09:34] <PingunZ> Ain't my work :)
[09:34] <nysosym> we use the color ones now? :D
[09:34] <PingunZ> I just extracted them into the emblems dir
[09:35] <PingunZ> Dunno
[09:35] <PingunZ> I prefer them :)
[09:35] <fschoep> PingunZ: right?
[09:35] <fschoep> PingunZ: it's that easy?
[09:35] <PingunZ> Yes.
[09:35] <fschoep> PingunZ: I've been trying like mad to get them working
[09:35] <PingunZ> fschoep: I'll guide you trough it :)
[09:35] <PingunZ> *:)
[09:35] <PingunZ> You on gnome/kde/xfce ?
[09:35] <fschoep> GNOME, Vanilla Ubuntu
[09:36] <fschoep> vanilla means "clean"
[09:36] <PingunZ> AltF2 -> gksudo nautilus
[09:36] <PingunZ> I know ;)
[09:36] <fschoep> OK, good :0
[09:36] <fschoep> Can you give me the short story?
[09:36] <PingunZ> There .. copy the emblems.tar.gz into your /usr/share/icons/tango/scalable/emblems/
[09:37] <fschoep> Like put the SVGs in /usr/share/icons/Human/scalable/emblems
[09:37] <PingunZ> and right click -> Extract here :)
[09:37] <fschoep> in Tango?
[09:37] <PingunZ> Yup .
[09:37] <PingunZ> I did it in tango .. I'm a tango-fan
[09:37] <PingunZ> And then just remove the .tar.gz
[09:37] <fschoep> Right.
[09:37] <PingunZ> Worked here :)
[09:38] <fschoep> Can you also get it working for Human :) ?
[09:38] <fschoep> I'd rather not put Human emblems in Tango
[09:38] <PingunZ> Yes ..
[09:38] <PingunZ> Must be same :)
[09:38] <fschoep> Is there a magic rune for updating the list of emblems
[09:38] <PingunZ> fschoep: Are you trying to use the orange or colored ones ?
[09:38] <fschoep> PingunZ: orange
[09:38] <fschoep> PingunZ: I like orange(s) and Apple(s)
[09:38] <PingunZ> Oh .. maybe the tar is corrupt ?
[09:38] <fschoep> ;)
[09:38] <PingunZ> rofl fschoep
[09:38] <fschoep> No I do get the SVGs alright
[09:39] <PingunZ> I'll try to put the oranges into the Human :D
[09:39] <fschoep> OK, go ahead and let me know if it works.
[09:40] <nysosym> hmm this action doesn`t work here
[09:42] <PingunZ> brb need to check something
[09:48] <PingunZ> fschoep: Something wierd is happening with those orange emblems
[09:48] <fschoep> PingunZ: tell me more
[09:48] <PingunZ> The colored ones work .. the orange ones don't
[09:49] <fschoep> PingunZ: right so unpacking the colored ones into emblems works for Human as well, but orange doesn't?
[09:49] <nysosym> i have found a good way, gimme some minutes please :)
[09:49] <PingunZ> nysosym: A good way ?
[09:49] <nysosym> yes, to work with the orange ones
[09:50] <nysosym> gimme some time :)
[09:50] <fschoep> nysosym: I'm looking forward to it
[09:50] <nysosym> i will send frank an new tar.gz :D
[09:50] <fschoep> nysosym: almost peeled out every hair on my head because I couldn't get them working
[09:50] <fschoep> nysosym: j/k ;)
[09:50] <PingunZ> add<EMAIL_ADDRESS>[09:50] <PingunZ> I told you .. the tar was corrupt :)
[09:50] <PingunZ> Do I get a cookie now ?
[09:51] <nysosym> fschoep: stop!!! :D
[09:51] <fschoep> PingunZ: not yet, if it works afterwards, both you and nysosym'll get one
[09:51] <nysosym> PingunZ: not corrubt, but a :D
[09:51] <nysosym> a later
[09:51] <nysosym> i will final my worm :D
[09:52] <PingunZ> Can I set my icons back to tango now ? :)
[09:52] <nysosym> jojo
[09:52] <PingunZ> Hmmm .. tango :)
[09:52] <PingunZ> Sweetest icons ever made !
[09:55] <PingunZ> nysosym: You're the one who made the emblems right ?
[09:56] <nysosym> yes
[09:56] <PingunZ> Oh :)
[09:57] <nysosym> why?
[09:57] <PingunZ> Just wondering ..
[09:57] <nysosym> because?
[09:57] <PingunZ> I was interested ..
[09:58] <PingunZ> In who made the emblems ..
[10:01] <PingunZ> fschoep: If you have any blubuntu-gdm news or other jobs like that to be done .. just mail me .. I'm kinda tired so .. cya ! :)
[10:01] <cbx33> ping fschoep
[10:01] <fschoep> PingunZ: cu
[10:01] <fschoep> cbx33: right man right time
[10:01] <fschoep> PingunZ: will mail you
[10:01] <cbx33> hey dude
[10:01] <PingunZ> Oki fschoep , night all
[10:01] <cbx33> just got in
[10:02] <cbx33> gonna do some sound work today
[10:02] <cbx33> and then if I don;t get it all done tomorrow too
[10:02] <cbx33> fschoep, I was thinking
[10:02] <cbx33> instead of ...
[10:02] <fschoep> cbx33: take your time, it looks like you're out of breath now :)
[10:02] <cbx33> dum da dum ba ba da-dum | dum da dum ba ba da-dum | dum da dum ba ba da-dum | dum dum dum dum
[10:03] <fschoep> OK, weird as it sounds I understand what you are saying
[10:03] <cbx33> dum da dum dum | dum da dum dum | dum da dum dum dum
[10:03] <cbx33> mush shorter
[10:04] <fschoep> That's an option indeed, I was thinking of trying just "dum da dum ba ba da-dum krsshh"
[10:04] <cbx33> wow even shorter
[10:05] <cbx33> our problem lies in where thr sound is initiated
[10:05] <cbx33> but its too late to chagne now
[10:06] <fschoep> what do you mean exactly?
[10:06] <cbx33> for the startup
[10:06] <cbx33> I'm talkign abotu startup
[10:07] <cbx33> the sound needs to start before the gnome splash
[10:07] <cbx33> but the way it currently is means it's played after
[10:07] <cbx33> or starts half way through
[10:07] <cbx33> so instead of....here's a song while your computer loads
[10:07] <cbx33> it's more like here's the sound that your computer has finished loading
[10:07] <fschoep> OK, I see - you're right yeah
[10:07] <cbx33> get me?
[10:08] <cbx33> but it's too late in release to change now
[10:08] <nysosym> fschoep: all works very fine here
[10:08] <nysosym> i have packaged my "Human Folder"
[10:08] <fschoep> cbx33: get it
[10:08] <nysosym> how can i send u these package?
[10:08] <fschoep> nysosym: DCC send?
[10:08] <fschoep> right click on me
[10:08] <nysosym> i will try it
[10:08] <fschoep> I hope
[10:09] <nysosym> works?
[10:09] <fschoep> I accepted it, but it's not really moving
[10:09] <nysosym> hmm okay
[10:09] <nysosym> rapidshare?
[10:09] <fschoep> Fine with me
[10:10] <cbx33> fschoep, where do yo ustand next release?
[10:10] <nysosym> ok
[10:10] <nysosym> mom
[10:11] <fschoep> cbx33: where do I stand?
[10:11] <cbx33> well, me and some other guys are hoping to have an online music sharing session next week
[10:11] <cbx33> to try out some music ideas for edgy +1
[10:11] <fschoep> cbx33: that sounds pretty cool
[10:12] <cbx33> wanna come along?
[10:13] <fschoep> cbx33: if I can make it, sure
[10:15] <cbx33> I'll record the session so I can put it online afterwards
[10:15] <fschoep> cbx33: record, as in "audio"?
[10:16] <cbx33> yes
[10:16] <cbx33> gonna blog about it later
[10:16] <fschoep> So we're going to use VoIP or something?
[10:16] <cbx33> to see who else is interested
[10:16] <cbx33> yup
[10:16] <cbx33> i think wer're goign to try teamspeak
[10:16] <cbx33> unless anyone else has better ideas from my blog post
[10:18] <fschoep> OK, keep me posted on it
[10:18] <fschoep> I'm going to fix some bugs now and try nysosym's emblems, be back in a few minutes
[10:19] <nysosym> :)
[10:20] <cbx33> ok
[10:20] <cbx33> I'm just gonna eat
[10:20] <fschoep> cbx33: OK
[10:21] <sharperguy> is the egdy usplash finished?
[10:22] <fschoep> sharperguy: not yet
[10:22] <sharperguy> ok
[10:23] <sharperguy> will it have messages about whats happening like the previous ones?
[10:23] <fschoep> sharperguy: probably not
[10:23] <sharperguy> ok
[10:24] <sharperguy> its jsut handy to know where things crash
[10:24] <fschoep> sharperguy: use the diagnostic boot option
[10:24] <sharperguy> though it could be totaly different with upstart anyway
[10:24] <sharperguy> yea
[10:24] <fschoep> You can also use ALT+F1 to switch to console
[10:26] <fschoep> nysosym: you put the orange emblems in scalable/emblems and added .icon files, right?
[10:26] <fschoep> nysosym: is there anything else to it?
[10:28] <nysosym> fschoep: no, the icons in scalable are a little bit useless. I have putt, all emblems in 48x48 emblems and it works perfectly ^^
[10:28] <fschoep> nysosym: prerendered ones?
[10:28] <nysosym> i don't understand completely how, but it works ^^
[10:29] <nysosym> fschoep: no, *svgs
[10:29] <fschoep> nysosym: right, so SVGs in 48x48 and .icon files?
[10:29] <nysosym> no .icon files :)
[10:29] <fschoep> OK
[10:29] <nysosym> have a look on it ;)
[10:30] <fschoep> Yes, hold on
[10:30] <nysosym> ahhh
[10:31] <nysosym> remove all svgs in 48x48 and put them in scalable/emblems works although
[10:31] <nysosym> fine :)
[10:31] <nysosym> thats would be a better way
[10:31] <fschoep> But there's also those .icon files which I don't have on vanilla Ubuntu
[10:31] <nysosym> remove all ^^ :D
[10:32] <nysosym> these only for different languages
[10:32] <fschoep> Right
[10:32] <fschoep> All SVGs are in scalable/emblems
[10:32] <fschoep> Now what do I do?
[10:33] <nysosym> delete everything in 48x48/emblems
[10:33] <fschoep> Everything, even the existing desktop emblem?
[10:33] <nysosym> the emblems should work although :D
[10:33] <nysosym> yes
[10:33] <nysosym> everything
[10:33] <fschoep> They don't, do I need to logout?
[10:33] <nysosym> they don`t nedded anymore
[10:34] <fschoep> Still no luck.
[10:34] <fschoep> I unpacked your tarball
[10:34] <fschoep> Copied your scalable/emblems/*.svg to my scalable/emblems
[10:34] <fschoep> Erased 48x48/emblems/*
[10:35] <nysosym> replace alhtough the index.theme with mine, BUT i have found some bugs
[10:35] <fschoep> Oh dear, tell me
[10:36] <nysosym> in my package are some icons in System>Administration like the old gnome ones
[10:37] <nysosym> i will try to delete these bugs
[10:38] <fschoep> I found out how to get the emblems to work
[10:38] <fschoep> But I'm missing a few it seems
[10:39] <fschoep> In the index.theme I removed references to the smaller emblems
[10:39] <nysosym> fschoep: can u send my the vanilla index.theme of human?
[10:39] <nysosym> please :)
[10:39] <fschoep> Sure
[10:40] <fschoep> nysosym: one moment please
[10:40] <nysosym> no problem :)
[10:43] <fschoep> Trying DCC
[10:44] <nysosym> ok :)
[10:44] <fschoep> nysosym: see anything?
[10:44] <nysosym> hmm no :-/
[10:44] <fschoep> E-mailed it to you
[10:44] <nysosym> ok
[10:46] <nysosym> thx :)
[10:47] <nysosym> fschoep: woot, 128x128 i doesn't have these folders :D
[10:48] <fschoep> no
[10:48] <fschoep> scalable does
[10:49] <nysosym> hmm okay, the adminstration menu bug is away
[10:50] <nysosym> a lot of emblems working although, but "stockmail-priority-high" "photos" and "unreadable" make some problems
[10:50] <fschoep> Indeed, I didn't see photos and unreadable
[10:50] <nysosym> strange
[10:58] <nysosym> very strange
[11:02] <nysosym> aaa
[11:03] <nysosym> i have a possible answer for that problem
[11:03] <nysosym> only a "name" failure, renome "emblem-photo.svg" to "emblem-photos.svg"
[11:04] <fschoep> nysosym: right, and the others?
[11:04] <nysosym> "embleam-unread.svg" to "emblem-unreadable.svg
[11:05] <nysosym> but i don`t have an answer for stockmail-priority-high
[11:05] <nysosym> because i don't know how i can make a underlined "m"
[11:05] <fschoep> no problem, maybe we can borrow a symlink from another theme
[11:06] <fschoep> nysosym: I would be very very happy if you could send me a tarball containing all properly named SVGs
[11:06] <nysosym> hmm
[11:06] <nysosym> sure, but i doesn`t have the "stockmail" one
[11:06] <fschoep> what's the naming problem exactly?
[11:07] <nysosym> the name must be "emblem-stock(underlined "m")ail-priority-high.svg"
[11:08] <nysosym> hmm
[11:08] <fschoep> can't you cut-n-paste it from nautilus?
[11:08] <nysosym> no, thats the problem :(
[11:08] <fschoep> ok
[11:08] <fschoep> it should be stock_mail_priority-high.png
[11:08] <fschoep> Just use underscores _
[11:08] <nysosym> *svg ;)
[11:08] <fschoep> right
[11:08] <fschoep> SVG
[11:09] <nysosym> i will try it
[11:09] <nysosym> mom
[11:12] <nysosym> hmm damn, this doesn't work :(((
[11:13] <nysosym> why does the dialog expect these icon?
[11:13] <nysosym> i don't understand this
[11:13] <nysosym> he should only usw, the icons in scalable
[11:13] <nysosym> *use
[11:17] <fschoep> nysosym: can you send me a tarball with the best working version you can produce? I'll work from there.
[11:17] <fschoep> I'm going to log out soon, going to bed.
[11:18] <nysosym> ok
[11:18] <nysosym> a little mom please
[11:20] <nysosym> *fail*
[11:22] <fschoep> nysosym: no problem, just drop me a mail with the stuff you can get working, I'll make sure we get that tested and in Edgy
[11:22] <nysosym> ok
[11:22] <nysosym> please go to sleep no
[11:23] <nysosym> good night
[11:23] <nysosym> cu later :)
[11:24] <nysosym> sending e-mail :)
[11:24] <nysosym> i will go to beed no although
[11:24] <nysosym> good night my friend, and sry for all work that i made.. :-/
[11:25] <fschoep> nysosym: thanks and don't worry - this is my job :)
[11:26] <nysosym> no, i will thank u
[11:26] <nysosym> :)))
[11:26] <nysosym> bye bye
[11:26] <fschoep> goodnight all
[11:26] <fschoep> :)


[02:20] <kgiii> Just to confirm, I have sent in my application to become an official member of the Lubuntu team.
[06:11] <guiverc> kc2bez, score for 1864787 in impish release notes; clean = 1, fail = 2  (and I had another ~like failure on different box that I suspect is/maybe related)
 kgiii I noticed the email in my inbox via the council list. We will get back to you as soon as we can. Thanks for the follow up.
 guiverc I saw the new bug report. I think at this point we can note it as occasional and a bit of an edge case but noteworthy nonetheless.
[08:31] <guiverc> it for sure is edge case ... (both 1945859 & older 1864787).. impacting only a tiny % of users; if not in release notes I could write up on discourse (documentation section) maybe as alternative
 We have had it in the release notes before but I don't mind pointing it at something in discourse to help folks work around. I think that could be helpful.
[08:38] <guiverc> ack..  & that sounds reasonable  (only hestitation being i'm the logical person to write it up..)  will use today's QA test as my walk-thru & see how it looks
 Don't stress over it too much. That is why we have edits ;)
 I think getting it down on "paper" is the important part.
[08:41] <guiverc> the only stress bit would be the title; if stuck it's always just "blah" & I accidently forget to rename it...
 Probably something like "Replace Partition Install Workaround" or something like that.
[08:48] <guiverc> already done - sorry I was saying that mostly as :)
 No problem 👍
[09:15] <guiverc> https://discourse.lubuntu.me/t/calamares-rare-sdfdisk-force-append-dev-sda-errors/2774    (would be better with pics.. I may redo install & use phone to take some pics.. didn't find any in bug reports)
 doing a do-release-upgrade -d from 21.04 to 21.10, the openbox themes are not displayed correctly, just delete the .config / openbox folder and reloading the session works correctly.
 You can also rename the lxqt-rc.xml to rc.xml. That might be a better approach for folks that have customized their Openbox config.
 ok
 perfect, thanks for the info!
 I had planned to add that to the release notes.
 ok, thanks!
 👍
[17:00] <kgiii> @kc2bez I'm in no rush. I figured I'd do this for a year and then see where I'm at. So, I'm not in any rush at this point.


[21:43] <gilbert> paultag: maybe i waited too long? that page is empty??
[21:43]  * gilbert should check irc more often
[21:45] <Unit193> http://debtree.pault.ag/view/mgilbert right? Works here in FF 14.
[21:45] <Unit193> *15
[21:46] <gilbert> perhaps i shouldn't be blocking javascript....grrr
[21:46] <gilbert> paultag: pretty nifty :)


[15:20] <Rabid_Roach> hi guys, is there a missing package which would result in the snaps I install not having alphanumerical characters in them?


[00:25] <fta> something not negative if possible :P
[00:26] <fta> or a nickname without bot in it but suiting the avatar
[00:27] <fta> no rush, i won't do it tonight
[02:59] <ripps> fta: ppacron?
[02:59] <ripps> debcron-bot?
[05:54] <micahg> [reed]: what do I do if I have a stacktrace for TB2 that matches one for FF2 that was resolved WFM
[06:01] <[reed]> what is it? and what bug?
[06:02] <[reed]> do you have STR?
[06:08] <micahg> STR?
[06:08] <micahg> [reed]: ?
[06:09] <gavin> [reed]: ?
[06:09] <micahg> bug 488640 and mozilla 361835
[06:09] <micahg> ugh, let me make that TB bug public
[06:11] <micahg> ok, it's public now
[06:12] <micahg> gavin: here's the Q I asked [reed]: what do I do if I have a stacktrace for TB2 that matches one for FF2 that was resolved WFM
[06:13] <gavin> assume it was fixed? :)
[06:13] <gavin> upgrade to tb3?
[06:13]  * gavin is kidding
[06:13] <gavin> not sure what context you're asking in
[06:14] <micahg> well, can I move to TB and reopen?
[06:14] <micahg> or should I file another bug in TB?
[06:14] <micahg> I started searching crash-stats.mozilla.com for crash reports
[06:14] <micahg> that's how I found it
[06:15] <gavin> well, it's unlikely that the problem would be fixed in tb2 unless it's very serious
[06:15] <gavin> given that 1.8 has been almost entirely abandoned
[06:15] <gavin> (especially now that tb3 is out)
[06:15] <micahg> gavin: ok, I'll ask the user if it's persistent or a one time thing
[06:16] <gavin> you 'd probably want to file a new TB bug, mark it 1.8 only, and reference 361835
[06:16] <gavin> but like I said, odds of it being fixed are near-zero
[06:16] <micahg> gavin: ok, if the you confirms it's recurring, I'll do that
[06:17] <micahg> oops
[06:17] <micahg> if the user *
[06:17] <gavin> ok
[06:17] <micahg> gavin: thanks
[06:19] <gavin> np
[06:22] <micahg> gavin: do you know about other TB stuff?
[06:22] <micahg> or should I go ask TB-devs
[06:24] <micahg> I have another crash that's a private bugzilla bug
[06:25] <gavin> I know about TB stuff generally
[06:25] <gavin> (or even mozilla stuff generally)
[06:25] <micahg> ok, so there's an Ubuntu crash (<IP_ADDRESS>) that matches a windows BT on 3.0b4
[06:25] <gavin> not an expert on tb specific front-end code, though
[06:25] <micahg> but the bugzilla bug is private and I can't see anything
[06:25] <gavin> what's the mozilla bug?
[06:26] <gavin> (I'm in the mozilla security group)
[06:26] <micahg> mozilla 505221
[06:26] <gavin> that bug is fixed in tb3, waiting for approval for tb2.0.0.x
[06:27] <micahg> gavin: would it be appropriate for me to add it as upstream in LP even though the status can't be seen?
[06:27] <micahg> or will it ever be public?
[06:27] <gavin> I can't comment on LP-appropriateness, I have no idea :)
[06:28] <micahg> gavin: can I assume it'll be made public if/when appropriate
[06:28] <gavin> it will be public once the fix is released to 1.8.1 users or that branch is EOLd, presumably
[06:28] <gavin> yes
[06:28] <micahg> or not at all
[06:28] <micahg> ok, I'll put it in, but in LP it won't be public so I guess it won't matter :)
[06:30] <micahg> gavin: how much of the stacktrace should match for crash matches?
[06:31] <micahg> The top 6 function calls match in this case
[06:31] <gavin> there's no hard-and-fast rule
[06:31] <micahg> that's what asac told me :)
[06:31] <gavin> it's possible for bugs to have different causes with the exact same stack trace
[06:32] <gavin> (though uncommon)
[06:32] <micahg> how about in this casE?
[06:33] <gavin> where's the LP stack trace?
[06:33] <micahg> can I subscribe you to the bug?
[06:33] <micahg> what's your LP nick?
[06:34] <gavin> umm, gavin-sharp I think
[06:34] <gavin> or gavin_sharp?
[06:34] <gavin> https://launchpad.net/~gavin-sharp
[06:34] <micahg> bug 487541
[06:36] <gavin> that looks consistent with the bug being fixed in mozilla 505221
[06:36] <micahg> ok gavin, thanks
[06:37] <micahg> gavin: can I ping you if I run into something like this again?>
[06:37] <gavin> sure
[06:37] <micahg> ok, rgeat
[06:38] <micahg> I'm trying to clean up TB bugs in LP before I finish TB3 for Lucid so I can close all the bugs
[06:38] <micahg> gavin: BTW, that bug is fixed in TB3 release or 3.0.1?
[06:40] <gavin> tb3
[06:41] <micahg> ok, great, that's what I marked
[06:44] <micahg> gavin, regarding mozilla 534663, are the keywords stored in the search engine files?
[06:44] <gavin> no
[06:44] <gavin> they're stored in search.sqlite in the profile
[06:45] <gavin> and associated with the plugin using its filename
[06:45] <micahg> gavin: filename or full path?
[06:45] <gavin> filename if in the profile or appdir, full path otherwise
[06:46] <gavin> (in particular, full path for extension-shipped plugins)
[06:46] <gavin> (which AIUI is what ubuntu releases use)
[06:47] <gavin> it's pretty unusual for extension on-disk locations to change
[06:47] <gavin> so the search service doesn't handle that case
[06:51] <micahg> gavin: we actually don't store them directly in the install dir probably for that reason
[06:53] <gavin> for what reason?
[06:54] <micahg> because of the path issues
[06:54] <micahg> we symlink the searchplugins dir in the ff dir
[06:54] <micahg> but they are stored else where
[06:55] <micahg> we store them here: https://bugzilla.mozilla.org/show_bug.cgi?id=534663
[06:55] <micahg> oops
[06:55] <micahg> we store them here: /usr/lib/firefox-addons/searchplugins/en-US/
[06:56] <gavin> I'm not sure what "path issues" you're referring to
[06:56] <gavin> the only issues I'm aware of are a result of _not_ storing them in the appdir
[06:57] <micahg> gavin: the moving paths for ff dir in ubuntu
[06:58] <gavin> oh, I see
[06:58] <gavin> you mean that you've tried to work around 534663 by not storing them in the appdir?
[06:58] <micahg> so, is there anything we can do to make the path show where the plugins actually are which doesn't change
[06:58] <micahg> so it seems
[07:01] <gavin> I guess it depends on the location of the extension more than it does the location of the actual plugin files
[07:01] <gavin> though if you're saying that you just symlink them into the app dir, then that theory isn't valid anymore
[07:02] <micahg> gavin: well, I guess the app looks in the app dir...can we have the path resolve the symlink before storing in the sqlite db?
[07:03] <micahg> so that it stores the actual path?
[07:03] <gavin> the problem is the opposite
[07:03] <gavin> we don't want it to store the actual path (since that changes), but it is being saved
[07:04] <micahg> gavin: in Ubuntu, the actual path doesn't change, but the symlink location does
[07:04] <gavin> oh
[07:04] <micahg> where the symlink resolves is constant
[07:04] <gavin> ok I misunderstood - get it now
[07:04] <gavin> that actually makes more sense
[07:04] <micahg> but it's storing the app dir
[07:04] <gavin> (I couldn't figure out why we'd be resolving the symlink)
[07:05] <gavin> but if it's in the appdir, we should only be storing appdir-relative paths
[07:05] <micahg> brb
[07:05] <gavin> which means that this should get fixed after restarts
[07:06] <gavin> which is consistent with the reports in the original bug
[07:06] <gavin> I just assumed the prolem in the ne w bug persisted after restarts
[07:06]  * gavin 's connection to his irc client is quite laggy for some reason
[07:09] <micahg> gavin: it does
[07:09] <micahg> the problem is after restart the keywords are wiped
[07:09] <gavin> yeah I just saw your comment on the mozilla bug
[07:09] <gavin> clearly I'm not reading these reports closely enough and jumping to conclusions :)
[07:10]  * micahg is good at that too :)
[07:12] <micahg> gavin: so, is there anything I can do to help with that bug?
[07:13] <gavin> not sure offhand
[07:13] <gavin> only scenario I can think of where that would happen is if the search plugin file name changes
[07:14] <micahg> well, the symlink is APP_DIR/distribution/searchplugins -> /usr/lib/firefox-addons/searchplugins
[07:16] <micahg> should I add these comments to the bugzilla bug
[07:21] <gavin> sure
[07:21] <gavin> I'll have to give this some thought and do some testing
[07:21] <micahg> ok, great, I'll watch for any comments and try to give prompt feedback
[07:29] <micahg> ok gavin, thanks for your help tonight, I must go to sleep now
[11:26] <BUGabundo_work> morning
[11:45] <fta> it's everywhere.. http://www.sofaraway.org/ubuntu/tmp/chrome-ad.png
[11:49] <BUGabundo_work> lol
[11:50] <BUGabundo_work> and was that got while using Chrome?
[11:50] <BUGabundo_work> aahah
[12:02] <fta> there're two chrome ads in there, one around the page, and one in the banner to give it as a gift to someone else
[12:04] <asac> gavin: i think this "searchplugin config reset on upgrade bug" is related to the "distribution/..." directory for shipping them (or because we ship them in a lang specific dir)
[12:04] <asac> (if this is what was talked about above)
[12:08] <fta> asac, BUGabundo_work: if you want to contribute: http://identi.ca/conversation/17175657#notice-17190196
[12:10] <asac> fta: i was positive about moving it to 4am ;)
[12:10] <asac> ah ;)
[12:10] <asac> dayfood ;)
[12:11] <asac> date
[12:11] <asac> !time
[12:11] <asac> !now
[12:13] <fta> asac, does dayfood match http://www.sofaraway.org/ubuntu/tmp/ppabot-192-192.png ?
[12:13] <asac> hehe
[12:13] <asac> most likely not
[12:13] <asac> spinman ;)
[12:14] <asac> pushman
[12:14] <asac> lol
[12:14] <asac> looks nice ;)
[12:14] <asac> powerbot
[12:14] <asac> pushbot
[12:14] <asac> no idea ;)
[12:15] <asac> stempify ;)
[12:16] <asac> what is 12:40 pm?
[12:16] <asac> is that midnight or lunchtime?
[12:16] <asac> hmm
[12:16] <asac> guess lunch
[12:19] <fta> so far, i like dabot, debot, botronik, drobotik
[12:20] <fta> asac, http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
[12:20] <fta> 12pm is noon
[12:21] <fta> crazy americans
[12:21] <asac> great. so its ambiguous
[12:21] <asac> like 12 a.m. for US government
[12:21] <asac> otherwise 12 pm ;)
[12:26] <fta> asac, so, how's chromium on arm now?
[12:27] <asac> didnt work the last fays
[12:27] <asac> days
[12:27] <asac> last build still got snaps/sigills in the browser window with the same probs
[12:27] <asac> like an infinite backtrace in abort
[12:28] <asac> seems its badly trashed
[12:28] <fta> hm
[12:29] <fta> how come it works fine in chromeos then?
[12:29] <asac> does chromeos work on arm?
[12:29] <asac> 'armv7': 1, # Optional, for targeting ARMv7.
[12:29] <asac> 'arm_thumb': 1, # Optional, for targetting thumb.  Combine with armv7 to target thumb2.
[12:29] <asac> i think we could try just arm_thumb
[12:29] <asac> and not armv7
[12:30] <asac> but thats just another attempt
[12:30] <asac> unfortunately there is no valgrind etc.
[12:30] <asac> on arm
[12:30] <asac> i wanted to try a cross compiled build like on the arm page
[12:38] <fta> chromeos supports x86 and arm
[12:45] <asac> fta: are all the testbinaries runnable locally if we build with testsuite?
[12:45] <asac> fta: maybe we should do that for once again
[12:45] <asac> and then debug
[12:45] <fta> yes
[12:45] <asac> but please add 'arm_thumb': 1,
[12:45] <asac> 'arm_thumb': 1, # Optional, for targetting thumb.  Combine with armv7 to target thumb2.
[12:45] <asac> if you havent
[12:46] <asac> hmm already in there
[12:47] <asac> fta: do we have debug symbols for the testsuite stuff?
[12:47] <fta> everything is built with -g, so the unstripped binaries (in out/) should be fine
[12:48] <fta> but it's no longer packaged
[12:52] <fta> the last arm build was with GYP_DEFINES="target_arch=arm disable_nacl=1 v8_use_snapshot=false linux_use_tcmalloc=0  armv7=1 arm_thumb=1  no_strict_aliasing=1 gcc_version=44 ..."
[12:53] <asac> fta: no strict aliasing?
[12:54] <asac> why is gcc_version needed?
[12:54] <fta> it's set by gcc_version=44
[12:54] <asac> well. i see that. but why?
[12:54] <asac> http://code.google.com/p/chromium/wiki/LinuxChromiumArm
[12:54] <asac> its not there
[12:54] <fta> well, i can drop no_strict_aliasing=1 now
[12:54] <asac> ah
[12:54] <fta> it was needed for v8
[12:54] <asac> thats what you referred to
[12:54] <fta> but it shouldn't matter for you
[12:55] <asac> and the gcc_version is still needed?
[12:55] <asac> shouldnt gyp detect such things?
[12:55] <asac> yeah
[12:55] <fta> i need to have a fresh look at the gyp rules
[12:55] <asac> just checking what is different
[12:55] <asac> from the arm instructions
[12:55] <asac> personally i think that a) the chromeos arm thing is built from some branch/tag
[12:56] <asac> or b) its a toolchain bug for a native build vs. a cross compiler build
[12:56] <asac> i think a) is more likely as the toolchain is basically the same i guess
[13:05] <fta> ok, so it seems gcc_version is autodetected now, and that it adds -fno-strict-aliasing & -fno-tree-vrp in v8 when set
[13:05] <fta> meaning it's not set globally
[13:05] <fta> i will update the branch accordingly
[13:08] <fta> done
[13:25] <BUGabundo_work> fta: chomobot
[13:26] <fta> it's not dedicated to chrome
[13:26] <fta> -ium
[13:28] <BUGabundo_work> fbot ?
[13:28] <BUGabundo_work> fabbot ?
[13:28] <BUGabundo_work> fabot?
[13:28] <BUGabundo_work> bienbot?
[13:28] <BUGabundo_work> EiffelBuilder?
[13:46] <fta> hm
[13:46] <fta> asac, FIREFOX_3_0_17_BUILD1 & FIREFOX_3_5_7_RELEASE
[13:47] <fta> asac, they too should do continuous releases
[13:47] <asac> fta: yeah. i think its first jan week
[13:47] <asac> and yes. thats more or less what they are already doing
[13:47] <asac> and will move further that way.
[13:47] <asac> however, their branch procedure is more transparent
[13:48] <fta> but moving _RELEASE tags are very confusing
[13:49] <fta> a tag should never move
[14:09] <asac> fta: yeah. thats a prob. but its a "potential" release tag
[14:09] <asac> fta: we use system cairo for chrom?
[14:11] <fta> nope, there's no cairo in there, but skia
[14:12] <asac> kk
[15:35] <BUGabundo_work> http://mashable.com/2009/12/20/firefox-popular-browser/
[15:35] <BUGabundo_work> FF wininng in Europe
[16:43] <micahg> fta: is there a reason why ff search plugins are in APP_DIR/distribution/searchplugins?
[17:09] <asac> micahg: yes. thats where distributors are supposed to ship search plugins (main reason). also iirc its the only place where we can ship localized searchplugins
[17:09] <micahg> ah asac, you're back :)
[17:10] <asac> no ;)
[17:10] <asac> just checking
[17:10] <micahg> ok, asac, well, when will you be back?
[17:11] <asac> BOY
[17:11] <asac> but most likely more active between chris and new y
[17:11] <asac> i am just gone for like 3 days now? ;)
[17:12] <micahg> yeah, ok, I'm going to try to have TB3 up on review before EOY
[17:12] <micahg> REVU I mean
[17:13] <micahg> asac: ok, so I'll check back with you next Monday
[17:13] <asac> micahg: no REVU needed
[17:13] <asac> just let me know when its ready and i upload. we dont even change package names afaik
[17:14] <micahg> asac: ok, I just thought you'd want to look at the changes
[17:14] <micahg> but I guess you can do that in the bzr repo
[17:14] <asac> micahg: can do that on branch
[17:14] <asac> its much easier
[17:14] <asac> yeah
[17:14] <micahg> ok
[17:14] <asac> micahg: maybe not push to the release branch, but to a topic branch
[17:14] <asac> so i can look
[17:14] <asac> try to commit step by step rather than one big chunk
[17:14] <micahg> ok
[17:15] <asac> i think starting with current thunderbird.dev is fine... the ncopy the current tbird 3.0.head there .... and then change step by step back to the non-versioned approach
[17:15] <micahg> ok, I was going to try some of the documentation on merging bzr branches that was created recently
[17:15] <micahg> I'm also trying to clean up TB bugs so we can close a whole lot with this upload
[17:23] <asac> micahg: that would be heroic
[17:24] <micahg> I have 23 bugs targeted aleady
[17:24] <micahg> *already
[17:25] <asac> wow
[17:28] <micahg> they're all fixed upstream :)
[17:30] <asac> yeah. everything else would be odd ;) (like fixed downstream)
[17:31] <BUGabundo_work> fta: wheres chromium? http://www.w3schools.com/browsers/browsers_stats.asp
[17:56] <fta> BUGabundo_work, in Chrome, upstream rejected my patch to expose Chromium (and ubuntu) in the UA
[17:56] <fta> BUGabundo_work, but those stats are weird, no way IE is at 38% and FF at 47%
[17:56] <asac> we should patch it still ;)
[17:57] <asac> we dont want to help contribute to another powerful brand ;)
[17:57] <asac> at least my opinion
[17:58] <fta> asac, debian/patches/chromium_useragent.patch is still in the branch
[17:58] <asac> once folks start to say: "hey, this sucks because its called chromium" then we have failed :)
[17:58] <BUGabundo_work> asac: ahaha
[17:58] <BUGabundo_work> or not working in sites like it happens with minefield
[17:58] <asac> like everyone goes made if you unbrand firefox or ship shiretoko and blame everything on the name
[17:59] <asac> BUGabundo_work: yeah. but atm lots of sites dont recognize chrome
[17:59] <asac> so better not help them ;)
[17:59] <asac> though we are probably not really powerful. but we could ensure that webdesigners that start matching for chrome somehow find out about chromium too
[17:59] <AnAnt> asac: Hello, I was talking to you  3 weeks ago about building libmozjs from xulrunner-1.9.1, and you said that it would be provided when xulrunner goes to universe, I just checked, and I found that xulrunner *IS* in universe
[17:59] <asac> so best practices start to match for both
[17:59] <asac> AnAnt: xulrunner-1.9.1 isnt
[18:00] <asac> the old stuff is in universe
[18:00] <asac> but that doesnt help
[18:01] <AnAnt> asac: oh, you mean xulrunner-1.9.1 at that time then ?
[18:01] <AnAnt> I don't understand why does it have to be in universe
[18:02] <AnAnt> I understand that there is an API/ABI incompatability between xulrunner 1.8 & xulrunner 1.9
[18:02] <asac> i am not sure about that either (which is why i would prefer to not ship libmozjs at all) .... as this assumes we can break stuff in universe
[18:02] <asac> in security updates
[18:03] <fta> http://code.google.com/p/chromium/issues/detail?id=17095
[18:03] <asac> or it assumes we can just not provide security updates for universe stuf
[18:03] <asac> yeah i know about that
[18:04] <asac> AnAnt: do you understand the point? in short: we cannot backport security fixes for js engine. so once a branch goes EOL we have no choice to abandon it
[18:04] <asac> which would mean that all folks using libmozjs would be insecur
[18:04] <asac> e
[18:04] <fta> http://code.google.com/p/chromium/issues/detail?id=27471
[18:04] <asac> if we dont abandon it we need to forwardport everything
[18:04] <asac> if the branch goes EOL
[18:05] <AnAnt> what branch goes EOL ?
[18:05] <AnAnt> 1.8 ?
[18:05] <AnAnt> sorry, I'm lost
[18:06] <asac> all branches go EOL
[18:06] <asac> you have to think about the future
[18:07] <asac> whatever we put in now will be EOL soon
[18:07] <asac> atm only 1.9 is EOL. ... beginning next year 1.9 will be EOL and q bit later 1.9.1
[18:07] <AnAnt> ok
[18:08] <AnAnt> so , what's the problem with that ?
[18:08] <asac> read what i wrote above ;)
[18:08] <asac> 19:04 < asac> AnAnt: do you understand the point? in short: we cannot backport security fixes for js engine. so once a branch goes EOL we have no choice to abandon it
[18:08] <asac> 19:04 < asac> which would mean that all folks using libmozjs would be insecur
[18:09] <BUGabundo_work> EOL End Of Life / Support
[18:09] <AnAnt> ok, if xulrunner-<version> builds libmozjs, so when 1.9 dies, 1.9.1 will build libmozjs, so what's the problem ?
[18:12] <asac> AnAnt: libmozjs for 1.9.1 is not compatible with 1.9 mozjs
[18:12] <asac> so everything that depends on it will break if you just reaplce it
[18:12] <AnAnt> so it will be libmozjs1 libmozjs2,...
[18:13] <asac> yes, if you take that approach you just abandon the old branch
[18:13] <asac> leaving all consumers of the old libmozjs insecure
[18:13] <AnAnt> well, that won't be the only library doing so
[18:14] <asac> no other library we have has loads of CVEs open
[18:14] <asac> in ubuntu we keep libs maintained
[18:14] <asac> with patches backported
[18:14] <asac> and dont do library transitions for stable releases
[18:14] <asac> thats the whole point
[18:14] <asac> but we cannot do that for libmozjs
[18:14] <asac> you are welcome to do some excersized
[18:14] <asac> s
[18:15] <asac> try to backport all missing CVEs from xul 1.9 to xul 1.8
[18:15] <AnAnt> I see, so the problem is that libmozjs has many security issues, that's why you don't want to abandon old libraries, right ?
[18:15] <asac> ubuntu policy mandates to not abadon anything that is in main
[18:16] <AnAnt> aha
[18:16] <asac> for universe its just hearless to do that
[18:16] <AnAnt> ok, I get it now
[18:16] <asac> thats why i said that theoretically we can just abandon stuff in universe
[18:16] <asac> but in practice it would be unfair to do that ... especially if we know up-front that we will end up in this situation
[18:17] <asac> (if things happen unexpectedly its a bit better ethically)
[18:17] <asac> thats basically why we also considered to remove xulrunner alltogether
[18:17] <asac> no xulrunner ... no libs from mozilla
[18:17] <asac> nothing, but their top-notch apps
[18:17] <AnAnt> but there are apps using xulrunner
[18:18] <asac> yes, all those have to die then
[18:18] <asac> its not nice, but its not our decision
[18:19] <asac> i fought for years to get mozilla understand that they bust a huge bunch of folks relying on them, but they clearly dont want that and hence, the only thing i can send out to programmers that use xulrunner or libmozjs
[18:19] <asac> is that they choosed crappy stuff as their base
[18:19] <AnAnt> ok, I have a question, I understand that Debian give high importance to such security issues, yet they don't take that approach you mention
[18:19] <AnAnt> asac: btw, is there another option than libmozjs ?
[18:19] <asac> AnAnt: history is: years ago, there was no security support in debian
[18:20] <asac> AnAnt: then i stepped up, doing backports, extracing zillion of patches for years
[18:20] <asac> noone else did it ever
[18:20] <asac> they will just not provide security support as before
[18:20] <asac> thats my bet
[18:20] <asac> they had some conflicts in the past, but couldnt do it and hence didnt do it
[18:21] <asac> so i think tats where they are heading
[18:21] <asac> we had long discussions with security team
[18:21] <asac> etc.
[18:21] <asac> most likely all xul based apps (incl. libmozjs) cannot go into a stable distribution
[18:21] <asac> e.g. always unstable only
[18:21] <asac> i should actually start that discussion again
[18:21] <AnAnt> asac: btw, is there another option (for developers) than xulrunner & libmozjs ?
[18:21] <asac> no
[18:21] <asac> you can go for webkit
[18:21] <AnAnt> so developers don't have a choice
[18:22] <asac> but even there our security team is strugeling hard
[18:22] <asac> it might be a bit better
[18:22] <AnAnt> I mean, they didn't *choose* crappy stuff
[18:22] <asac> dont argue with me
[18:22] <asac> it breaks my hard more than anyones else
[18:22] <asac> heart
[18:23] <AnAnt> so webkit supports javascript ?
[18:23] <asac> AnAnt: atm they need to go to webkit and hope that its all fine
[18:23] <asac> AnAnt: yes.
[18:23] <asac> but webkit is fresh and i know its similar painful as mozilla to support ... however, they have a bit more stable API for embedding
[18:23] <asac> for js i dont know
[18:23] <asac> v8 (google javascript) has no stable abi/api policy either
[18:24] <AnAnt> ok, I'll talk with upstreams of software I care about about this webkit, thanks
[18:24] <asac> so in short: someone needs to step up and support stuff ... most likely target is couchdb project
[18:24] <asac> which is a well funded project that relies on it
[18:24] <asac> but only way to convince them is to be harder i think
[18:25] <asac> they have the attitude: "it will just resolve on its own"
[18:25] <AnAnt> couchdb ? isn't that a database thing ?
[18:25] <asac> thats a javascript based database ... yes.
[18:25] <asac> you write stored procedures in javascript or something
[18:25] <asac> also it uses json
[18:25] <asac> etc.
[18:25] <asac> its the only app in main that we have that uses mozjs
[18:25] <asac> which causes me to cry every day ;)
[18:25] <asac> that it exists
[18:27] <asac> its a big mess ;)
[18:28] <AnAnt> heard of Simple Ecmascript (SEE) ?
[18:29] <asac> nope ... new?
[18:29] <asac> i think the right approach would be to provide a stable, minimal wrapper lib around mozjs/v8 etc. that is then eagerly maintained accross mozjs/v8 branches
[18:29] <AnAnt> well, elinks supports SEE backend, but I dunno what it is
[18:30] <asac> but someone needs to do that ;)
[18:30] <asac> AnAnt: if you find the upstream source for that i would love to take a look
[18:30] <asac> or even package if there is any
[18:32] <AnAnt> asac: http://www.adaptive-enterprises.com.au/~d/software/see/
[18:34] <asac> 3.0 development status
[18:35] <asac> Only a single active developer
[18:35] <asac> Decreasing year-over-year development activity
[18:35] <gavin> asac: "bust a huge bunch of folks" has a much different cost valuation for us than it does for you, I think
[18:35] <gavin> need to put "huge" is put into context - by far the largest libmozjs userbase is official firefox release users, not users of libmozjs in ubuntu
[18:36] <asac> gavin: yes.
[18:36] <gavin> that's not to say that we should be cavalier about dropping support, either, but it seems like you often seem to dismiss the cost of maintaining these old releases too easily
[18:37] <asac> gavin: i am not saying i dont understand the reasoning.
[18:37] <asac> just saying that the situation is sad
[18:37] <asac> but i see the point "why should you do it"
[18:37] <asac> its just that mozilla as a foundation/charity
[18:37] <asac> might be the single only entity that would listen for the ecosystem
[18:37] <asac> and invest even though it doesnt give a benefit
[18:37] <asac> just "to make the web a better place"
[18:37] <asac> ;M)
[18:38] <gavin> well, I think part of the problem there is that we disagree about what would be the most effective way to "make the web a better place"
[18:38] <asac> yeah
[18:38] <gavin> we have limited resources, and the thinking is that innovating and moving faster is actually more effective than maintaining support
[18:38] <asac> well. it might also be "what is the web"
[18:39] <asac> gavin: yes. its a tradeoff. but the argument is always: "someone else should do the stable maintenance" ... which obviously doesnt work, because the only folks that could do it are employed by mozilla ;)(
[18:39] <asac> gavin: but i also see its unfair to put the burden of being slow/uninnovative
[18:39] <asac> on mozilla ... while others are ok to do what they want
[18:39] <asac> (e.g. v8 namely)
[18:39] <gavin> yeah
[18:40] <asac> its just that you were the only folks being good
[18:40] <asac> (well never as good as it could be;))
[18:40] <asac> but you were the only ones providing that stuff
[18:40] <asac> so thats why folks got pissed.
[18:40] <asac> and now they move to webkit, which doesnt help at all here ;)
[18:42] <AnAnt> asac: sorry again, but what's the problem of webkit ?
[18:42] <gavin> people sometimes do tend to feel entitled to a free lunch :)
[18:42] <asac> gavin: but also, its unfair to say that "we want to freeride when we ask for this"; yes, it sucks that there is innovative stuff we cannot support, but mostly it breaks my heart to go to free software developers and tell them : "sorry, but using mozembed or mozjs is just a no go ... and there is nothing else i can tell you to use, just enjoy your spare time rather than developing"
[18:42] <asac> anyway, i hvae reached the point to accept that
[18:43] <asac> now i just have to somehow get all mozilla consumers out of the archive ;)
[18:43] <asac> AnAnt: webkit has no track record of security
[18:43] <gavin> I guess I don't understand why you have to tell them not to use mozjs
[18:43] <asac> so its like saying: "its not great in europe, lets go to the unknown land"
[18:44] <asac> gavin: no stable ABI/API guarantees - not even on stable branches.
[18:44] <asac> i talked to jorendorff a bit in the past talking about a minimal subset
[18:44] <gavin> it seems to me like you make stability garantees that aren't actually useful in practice
[18:45] <asac> that could be kept stable
[18:45] <asac> gavin: well. if users use libmozjs ... and there is ABI/API breakage in a security update, its not usable
[18:45] <asac> and evne if there is the risk of that
[18:45] <gavin> (or that have a high cost/benefit ratio)
[18:45] <asac> also we have to move t your new approach of rolling major versions
[18:46] <asac> gavin: libs need to provide a stable API ... consider gtk+ busting you every other year
[18:46] <asac> thats a bigger scale of course, but for apps that heavily rely on mozjs api, its probably the same as gtk+ brekaing for you
[18:47] <gavin> yeah, I recognize the value of stable APIs
[18:47] <[reed]> gtk+ does bust us
[18:47] <asac> right. what i was trying to say is if there is not even a minimal subset of mozjs api we know is stable, i can only say to mozjs consumers that they cannot be supported in the distro
[18:47] <[reed]> we've found numerous gtk+ bugs
[18:47] <[reed]> it's ridiculously hard to get them fixed upstream
[18:47] <gavin> but it's not like old versions of libmozjs disappear - they just stop getting frequent updates
[18:47] <asac> [reed]: well. bugs are != ABI/API breakage
[18:48] <gavin> if people are not able to move to new api versions, they always have the ability to stay on the old version, and deal with those issues instead
[18:48] <asac> gavin: they dont get security updates. and with about 30% of CVEs going for js its not supportable
[18:48] <gavin> right, but the security issues couldv ery well be easier to deal with than the compat-switching issues
[18:48] <gavin> (or not worth dealing with at all)
[18:49] <gavin> I don't recall seeing many new vulnerabilities reported against non-mozilla-supported versions of spidermonkey
[18:50] <asac> gavin: where are those "non-mozilla-supported" versions of spidermonkey? ... that was basically what we asked for
[18:50] <asac> and got turned down
[18:50] <asac> we wanted to build mozjs with special flags to just export a minimal API, so apps can at least have some mozjs.
[18:51] <asac> but that didnt even fly for stable branches
[18:51] <asac> maybe its all miscommunication
[18:52] <asac> if there is a solution to that i am eager to adapt that instantly
[18:53] <AnAnt> man, even eclipse uses xulrunner !
[18:54] <asac> yeah
[18:54] <asac> they are doomed
[18:55] <AnAnt> wow !
[18:55] <asac> the other plan (besides the deliberatly making universe insecure) was to remove everything that depends on it in archive
[18:57] <AnAnt> but if you tend to keep mozilla apps without the libs (and I see that those apps depend on xulrunner too), then that means that each app will have a copy of xulrunner with it
[18:57] <asac> which is probably what will happen (because security team and archive admins understand the current situatioN)
[18:57] <asac> AnAnt: yes. thats the only support model feasible
[18:58] <asac> and that also means, that only the most important apps are allowed in
[18:58] <asac> (with an exceptioN)
[18:58] <asac> so basically it blocks all xulrunner apps, but firefox/thunderbird
[18:58] <asac> from entering the archive
[18:58] <AnAnt> you mean the main archive or even universe ?
[18:58] <asac> or just ignore it and deliberaly allow universe users to use hot/insecure stuff
[18:58] <asac> AnAnt: arguably there is no difference from main and universe
[18:59] <asac> users use it
[18:59] <asac> why would you deliberately allow users of universe software to be exploitablke
[18:59] <asac> that causes massive headaches if you know it up-front
[19:00] <asac> personally, i feel really bad about all this, because it felt important for me to strengthen the mozilla ecosystem
[19:00] <asac> but i cannot strengthen it without mozilla wanting it (which was discussed as a somewhat reasonalbe decision for mozilla to not do)
[19:01] <asac> so if i dont vouch for it and security team and archive/release team knowing about it, thing will just die
[19:02] <asac> also ubuntu tries to be a great distribution, but in the end we understand ourselves as a distribution platform
[19:02] <asac> especially for universe etc.
[19:02] <asac> if someone tells us repeatedly thats not appreciated then there is no point pushing in the other direction.
[19:02] <asac> it only causes discussions like this one ;)
[19:03] <asac> in two years, when everyone has accepted that its normal to have no mozembed in the world, then all will be better and chances are even higher that a valid replacement appears
[19:04] <asac> anyway, shit happens. next year will be a better year i hope :)
[19:04] <AnAnt> thanks for the discussion
[19:05] <asac> maybe lets hope that after tracemonkey is fast enough things can change ;)
[19:05] <AnAnt> tracemonkey ?
[19:06] <asac> but i wouldnt wait for it ... developers at least like it more if they dont need to have a stable API
[19:06] <asac> tracemonkey == mozjs with jit
[19:06] <AnAnt> oh, another mozilla product
[19:06] <asac> i think its the same product
[19:06] <AnAnt> ok
[19:07] <asac> its not a product btw ;)
[19:07] <asac> its a secondary/assistive project currently existing to power firefox ... thats why we have these issues
[19:09] <AnAnt> ok, I need to understand something, in case xulrunner gets removed from Ubuntu. An application like eclipse (if it bundles xulrunner with it) will need an exception to get into universe ?
[19:09] <AnAnt> or the exception is for main ?
[19:09] <asac> i think its more likely that eclipse needs to get the parts patched out
[19:09] <asac> that use xulrunner
[19:09] <asac> its really just a minor use case where they use it
[19:09] <AnAnt> ok, eclipse was just an example
[19:10] <asac> but in theory yes
[19:10] <asac> if an app needs xulrunner, it cannot enter the archive until it proofed to be essential
[19:10] <asac> which is a bit hard if its not in the archive of course
[19:10] <asac> but thats how it is ;)
[19:10] <asac> like if firefox would be less popular we could drop it
[19:10] <asac> and would
[19:10] <asac> same for tbird ;)
[19:11] <asac> but thats a bit extreme
[19:11] <asac> basically, as long as we are sure that upstream including xulrunner keeps up with the security fixes, it can stay in
[19:11] <asac> however, thats probably just firefox
[19:11] <asac> and thunderbird maybe
[19:11] <AnAnt> ok
[19:11] <asac> things like songbird etc. did never enter the archive because of that
[19:12] <asac> they cannot keep up and hence users would be zero-dayed
[19:13] <AnAnt> asac: do you know wether Debian would make such a similar decision ?
[19:13] <asac> if i raise this, i am quite sure that security folks will agree and make this happen, yes.
[19:13] <asac> havent started discussing that with them
[19:14] <asac> in the past i was the only guy preventing such a move
[19:14] <asac> e.g. it owuld have happened for etch and lenny if i hadnt promissed that we can do it somehow
[19:15] <asac> but now i cannot promiss that anymore, because upstream model is getting even more aggressive
[19:15] <asac> i will probably also approach redhat and suse about this
[19:15] <AnAnt> asac: thanks again for this discussion
[19:15] <AnAnt> I'll need to run now
[19:15] <asac> no problem. sorry that i cannot give better perspective
[19:16] <AnAnt> asac: no probs
[19:16] <AnAnt> bye
[19:26] <micahg> asac: so if upstream will let us put the searchplugins elsewhere, that's ok?
[19:31] <asac> micahg: not sure
[19:31] <asac> i dont think that will help
[19:31] <asac> whats the problem?
[19:31] <micahg> asac: in upstream builds, they're in APP_DIR/searchplugins
[19:31] <asac> yes, but that doesnt work
[19:31] <micahg> the problem seems to be the way it's stored in the search.slite
[19:31] <asac> for locale specific stuff
[19:31] <micahg> *search.sqlite
[19:31] <asac> yes, i guessed so
[19:32] <asac> i think we need to normalize the path its stored under
[19:32] <micahg> I was going to do some test builds to see if that would help
[19:32] <micahg> asac: well, the plugins are actually stored outside the app_dir as I"m sure you know
[19:32] <asac> micahg: i think it helps, but localization is not working at that place afaict
[19:32] <asac> micahg: so?
[19:32] <asac> its just a link
[19:33] <asac> we have them in APP_DIR/distribution/searchplugins/...
[19:33] <micahg> asac: yeah, but one option might be to resolve the symlink before storing in sqlite
[19:33] <asac> yes, thats what i mean
[19:33] <asac> 20:31 < asac> i think we need to normalize the path its stored under
[19:33] <asac> first run a realpath
[19:33] <asac> then store it
[19:33] <asac> maybe its done for the APP_DIR/searchplugins place atm
[19:33] <micahg> oh, I thought you meant normalize the app_dir path :)
[19:33] <asac> then its a bug for the distribution/searchplugins
[19:33] <asac> no ;)
[19:34] <micahg> ok, so I can try to work with upstream on this then
[19:34] <asac> yes.
[19:35] <asac> most important requirement is a) that its locale sensitive
[19:35] <micahg> asac: would you prefer the realpath solution to moving the search dir?
[19:35] <asac> moving where?
[19:35] <asac> maybe its really a bug even for APP_DIR/searchplugins
[19:35] <micahg> so that it is recognized as [app]/foo.xml
[19:35] <asac> try that out
[19:36] <micahg> ok, I'll try that
[19:36] <asac> you mean APP/searchplugins/foox.mk?
[19:36] <asac> we need locale support
[19:36] <micahg> no, it would be [app]/locale/foo.xml
[19:36] <asac> they dont hvae that in upstream builds; and afair i moved it to distributions/ directory because of that
[19:36] <micahg> upstream [app] is firefox/searchplugins
[19:36] <asac> micahg: APP/searchplugins/locale/foox.mk you mean?
[19:36] <asac> ah
[19:36] <asac> well
[19:36] <micahg> in the sqlite db :)
[19:37] <asac> thats more or less ok, but in the end the distribution directory should work
[19:37] <micahg> ok, gavin wasn't familiar with our dir structure
[19:40] <gavin> simple fix would be to just normalie
[19:40] <micahg> gavin: normalize as in realpath?
[19:41] <gavin> yes
[19:42] <micahg> gavin: ok, should I try to produce a patch?
[19:43] <gavin> sure
[19:43] <gavin> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#2786
[19:43] <gavin> |file| is an nsIFile
[19:43] <gavin> you could check isSymlink() and then use .target, perhaps
[19:43] <gavin> or maybe just call normalize()
[19:44] <gavin> yeah, normalize() seems to realpath()
[19:44] <gavin> http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#530
[19:44] <asac> right. should be simple enough
[19:44] <micahg> gavin: ok,  I'll try tonight :)
[19:44] <asac> thx
[19:46] <asac> i am not sure if isSymlink returns true if any of the ancestors is a symlink. you could also just say "normalize"
[19:46] <asac> if its right its right and if not it shouldnt hurt
[19:47] <asac> micahg: what do you see in search.sqlite atm?
[19:48] <micahg> asac: it shows APP_DIR/distribution/searchplugins/en-US/foo.xml
[19:49] <asac> es, i think the problem is not the follwo symlink, but rather the
[19:49] <asac> isInAppDir test
[19:49] <asac> that should make a substring match
[19:50] <asac> so
[19:50] <asac> well ... just normalize and since the plcae is stable it should be fine
[19:51] <gavin> isInAppDir really should only return true for plugins that are in SrchPlugns (i.e. appdir/searchplugins)
[19:51] <asac> yeah
[19:52] <asac> but wouldnt work with localization either
[19:52] <gavin> otherwise there could be conflicts (since two plugins could have the same file name in appdir/ and appdir/distribution)
[19:52] <asac> but i think that location doesnt support locales
[19:52] <gavin> right, it doesn't
[19:52] <gavin> it could, but there isn't really any reason to given that distribution already exists
[19:52] <gavin> (once we fix this bug anyways)
[19:53] <asac> yes
[19:53] <asac> gavin: though the normalize fix is a bit of a hack ... for us we have a stable realpath for the plugins
[19:53] <asac> but if we would ship it just below the real app dir it wouldnt help
[19:53] <gavin> yeah
[19:53] <asac> so we would need to add something like isBelowDistroDir...
[19:54] <gavin> could do that too I guess
[19:54] <asac> which does a startsWith ... match and then used proper [distrosearchdir]/locale/xxxx
[19:55] <gavin> the problem is that there are a bunch of places that can be in SrchPluginsDL
[19:55] <asac> but then we could just do "isBelowAppDir" in the same way
[19:55] <asac> for everything
[19:55] <gavin> and it's kind of ugly to have to hardcode checks for all of them
[19:56] <gavin> yeah, maybe that would be better
[19:56] <asac> but then the current [app] thing would be required for legacy i guess
[19:56] <asac> otherwise it wouldnt match as [app] = APP/searchplugins
[19:56] <gavin> indeed
[19:56] <asac> hmm
[19:58] <gavin> it wouldn't be too hard to move to using e.g. [appdir] for all things under the appdir, but still use [app] for APP/searchplugins specifically
[19:58] <asac> so not sure. maybe the normalize is the right way to move forward - but it might break other distros that ship their app with a link
[19:58] <asac> yeah
[19:58] <asac> thts what i ment
[19:58] <asac> prefer [app]
[19:58] <asac> if that works
[19:58] <asac> its fine
[19:58] <asac> otherwise try [appdir] on the full path
[19:58] <asac> but the whole code uses leafName ;)
[19:59] <asac> hmm. seems to be just id
[19:59] <asac> that should be managable
[19:59] <gavin> yeah, it just needs to be unique
[19:59] <gavin> (for a given file)
[20:00] <micahg> should I subscribe linux@distro to the bug?
[20:06] <gavin> not sure it's worth spamming everyone watching that? I don't know that this is relevant to any other distros
[20:08] <micahg> gavin: won't it be relavent if we symlink the realpath?
[20:08] <micahg> oops
[20:09] <micahg> realpath the symlink?
[20:09] <gavin> maybe, but I don't know that that's common either
[20:09] <asac> micahg: we shouldnt do that imo.
[20:09] <gavin> yeah, maybe we jsut shouldn't do that
[20:09] <asac> some distros ship their app in a non versioned path
[20:09] <asac> but others do
[20:09] <asac> and i would guess they use a symlink like us
[20:10] <asac> if not distribution ... they symlink searchplugins
[20:10] <asac> so normalize would break
[20:10] <asac> we should go for the appdir approach
[20:10] <asac> hmm
[20:11] <gavin> why do you symlink search plugins, btw?
[20:11] <asac> i think we might get around by normalizing here:
[20:11] <asac> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#2297
[20:11] <asac> e.g. after all the other stuff failed
[20:11] <asac> gavin: because otherwise they are in a versioned directory, so we cannot ship additional plugins from outside
[20:11] <asac> without breaking those on updates
[20:12] <asac> also we (plan to) inject localized plugins now through translations ... which are not build in firefox, so same problem for those
[20:13] <micahg> ok, so should I try to add an [app_dir[ check there?
[20:13] <asac> micahg: yes. add a simliar function: isBelowAppDir ... or something and then dont use leafName for those matching that, but substring
[20:15] <asac> or just normalize after everything has happened in id() ... which is also correct imo
[20:16] <micahg> asac: gavin: does it matter that AppDir isn't being used consistently in the functions?
[20:16] <asac> micahg: yes.
[20:16] <asac> we hvae appsearchdir ... thats the current APP
[20:16] <asac> we would have appdir ... thats the real appdir
[20:16] <micahg> isInAppDir is APP_DIR/searchplugins where isBelowAppDir would be APP_DIR
[20:17] <micahg> asac: how about isInDistroAppDir?
[20:17] <asac> yes ... and for the Below you wouldnt implement a ==, but a startsWith
[20:17] <gavin> isInAppDir is a bit of a misuse of "app dir"
[20:17] <gavin> it's really "app searchplugins dir"
[20:17] <micahg> right, that's what I'm asking about
[20:17] <asac> micahg: ther emight be more dirs etc., so adding checks for each possible location was considered a scalability problem
[20:17] <gavin> you can use appdir.contains(file, true)
[20:17] <asac> thats why i think isBelowAppDir is best we can do to extend this for noce and for all
[20:18] <gavin> but I just thought of something... switching to [appdir] will mean we'll change the IDs of existing plugins
[20:18] <asac> gavin: contains does a recursive search?
[20:18] <gavin> asac: that's the second param
[20:18] <asac> gavin: thats what i said, we should keep app
[20:19] <gavin> asac: not just app, though
[20:19] <asac> and prefer that ... and then go for appdir
[20:19] <asac> if it didnt match
[20:19] <gavin> there are existing plugins that fall back to using the full path as their ID
[20:19] <gavin> if we make them now use [appdir]/path, their ID will change
[20:19] <asac> gavin: hmm. ok. so we need to do appdistrosearch ;)
[20:20] <gavin> I guess we could limit it to that case, yeah
[20:20] <asac> great. but we need recursive search too, because of the locale/common dir in between
[20:20] <micahg> ok, once you two figure it out, please tell me what to try  :)
[20:20] <gavin> but we'd still have that problem for people who were using the distro dir but without the symlnik
[20:20] <asac> gavin: why?
[20:20] <asac> ah
[20:20] <asac> well.
[20:20] <gavin> because we'd still be changing their IDs
[20:21] <gavin> not a big deal in the ubuntu case since that's already happening (due to this bug)
[20:21] <asac> yeah. thats collateral damage ;)
[20:21] <asac> we might want to subscribe linux.bugs to figure if anyone uses distribution dir then ;)
[20:22] <asac> i can ping caillon directly to check redhat
[20:22] <asac> debian doesnt use it for sure.
[20:22] <asac> and wolfr i can ask i guess
[20:23] <asac> asked caillon
[20:23] <asac> lets see if he replies
[20:24] <gavin> not really limited to linux, though
[20:24] <gavin> could be anyone
[20:25] <asac> hmm
[20:25] <asac> so caillon said no.
[20:25] <asac> but you are right
[20:25] <asac> so lets bread a bit further  on this ;)
[20:30] <asac> sucky
[20:30] <asac> distro patch ;)?
[20:30] <asac> hehe
[20:30] <asac> or migration
[20:30] <gavin> normalize() is sounding like a better option now
[20:31] <gavin> only downside is that it's kind of hacky and non-obvious, right?
[20:31] <gavin> less likely to cause compat issues, I think
[20:31] <asac> yes. also as you said it might change id for those that have a symlink but are not affected
[20:32] <asac> atm
[20:32] <asac> personally, i would consider that likelyhood low
[20:32] <gavin> right
[20:32] <asac> where are the ids compared?
[20:32] <asac> is that __id thing something special?
[20:35] <asac> gavin: ?
[20:42] <gavin> asac: they're used to retrieve/store data from the DB
[20:43] <gavin> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/search/nsSearchService.js#3494
[20:43] <asac> hmm. ok. that doesnt give much flexibility to do smart stuff
[21:10] <micahg> fta: I would think throwing the files up to a bzr repo under his user in LP would be easiest
[21:10] <fta> ?
[21:10] <micahg> fta: re the seammonkey email
[21:10] <fta> oh
[21:11] <fta> we already have a sm2 branch
[21:11] <fta> i just orphaned it a while ago
[21:11] <micahg> fta: right, but we can see his changes and take what works
[21:11] <fta> yep, it was not clear to me if he said he had a package or just the control file
[21:12] <micahg> fta: well, I don't think anyone's agreed to do it yet, I have a note for myself If I have time
[21:12] <micahg> fta: would you like me to reply to him?
[21:13] <fta> sure, feel free, i won't
[21:13] <micahg> I'll copy you and asac
[21:20] <micahg> fta: BTW, can you update my address in your addressbook to my ubuntu dot com address?
[21:21] <fta> sure, send me an email with it
[21:21] <fta> nm, jsut got one
[21:21] <micahg> fta: thanks :), otherwise, that stuff can get lost in my bugmail :)
[21:22] <fta> want the bot too?
[21:23] <micahg> hmm, either way on the bot, since I already set up filters for it
[21:56] <BUGabundo> boas o/
[22:02] <asac> hi BUGabundo
[22:02] <BUGabundo> Olá Alexander
[22:02] <BUGabundo> ... the great
[22:02] <micahg> asac: did you ever figure out what I should try w/regard to the search plugin stuff
[22:02] <asac> micahg: can you subscribe stransky at redhat.com and caillon at redhat.com to the distribution bug?
[22:02] <fta> asac, today's chromium is snaping
[22:02] <fta> http://paste.ubuntu.com/344968/
[22:03] <micahg> asac: on bmo?
[22:03] <asac> micahg: yes
[22:03] <asac> fta: sigh
[22:03] <asac> fta: so you dont track the green takgs?
[22:03] <fta> green as in "it builds"
[22:04] <asac> hmm. thought it also includes that the tests run
[22:04] <asac> and dont crash etc.
[22:04] <micahg> asac: dine
[22:04] <micahg> oops
[22:04] <micahg> done
[22:04] <asac> k
[22:04] <asac> micahg: wolfgang rosenauer is the opensuse guy we should subscribe
[22:04] <asac> but i dont know his email in bugzilla atm
[22:04] <asac> only know his nick: wolfr
[22:04] <asac> but he probably is subscribed to a bunch of other linux bugs
[22:05] <asac> especially the kde integration one ;)
[22:05] <micahg> but we don't want to just do linux@distro?
[22:05] <micahg> asac: found it
[22:05] <asac> micahg: definitly subscribe them individually too ...
[22:06] <micahg> asac: I should also add linux@distro?
[22:06] <asac> micahg: not before we propose a solution imo
[22:06] <micahg> do I need to comment when adding them?
[22:07] <asac> hmm ... maybe subscribe it ... and afdter that ask if anyone uses distribution/searchplugins
[22:07] <asac> micahg: yes.
[22:07] <asac> you need to just hit enter if you are in the CC field
[22:07] <asac> or just say commit
[22:07] <micahg> asac: no, I mean do I need to say why I'm subscribing them?
[22:08] <asac> no
[22:09] <asac> subscribe them first
[22:09] <asac> then you can ask the question i mentioned
[22:10] <micahg> asac: done
[22:11] <asac> micahg: in case they have questions or something where i need to provide input let me know. i probably will miss all mail till jan
[22:12] <micahg> asac: ok
[22:12] <micahg> should I just ping you with notes?
[22:12] <asac> yeah
[22:13] <micahg> asac: as long as I have you here, debian source format 3, we probably won't do that till Hardy is EOL on desktop, right?
[22:14] <asac> yeah
[22:15] <asac> our packages need to work everywhere
[22:15] <micahg> asac: also, should I try to bump TB3 to debian standards 3.8.3?
[22:15] <asac> why not ;)
[22:15] <micahg> ok, but any debhelper stuff needs to work on hardy, right?
[22:16] <asac> micahg: did you figure a sensible way to merge the tb 3.head branch onto the tbird.dev one?
[22:16] <asac> micahg: right.
[22:16] <micahg> asac: well, there's some docs on merging branches since that'll be the new way to merge from debian, I was going to try that
[22:16] <asac> i think we should try to keep the approaches for tibrd/xul/ffox simliar
[22:17] <asac> micahg: you can try. but the problem here is that there is no common ancestor
[22:17] <asac> if that doc helps great
[22:17] <micahg> asac: worse possible case, I'll do it by hand, but I don't think that'll be necessary
[22:19] <asac> nah. i think you can do bzr merge -r 0.. /path/to/tbird3.0.head
[22:19] <asac> hopefully
[22:19] <asac> maybe remoivng the files that are not in the tb3 branch first
[23:13] <fta> asac, can't find a commit that could have done this. other option is the strict aliasing thing i changed in the branch
[23:22] <asac> maybe a flash update ;)?
[23:22] <fta> BUGabundo, you're using the chromium hardy builds right?
[23:22] <asac> BUGabundo on hardy?
[23:22] <fta> on debian
[23:22] <asac> ah
[23:22] <asac> lenny or what?
[23:23] <BUGabundo> fta: yep
[23:23] <fta> just want to try that, the gcc44 thing was obviously not used on hardy
[23:23] <BUGabundo> on debian? hardy on unstable
[23:24] <fta> BUGabundo, could you upgrade chromium to the lastest (where you're using the hardy ppa) and try a page with flash
[23:24] <BUGabundo> fta: tomorrow
[23:24] <BUGabundo> at work
[23:24] <BUGabundo> I do daily updates
[23:24] <BUGabundo> ping me then
[23:24] <fta> :(
[23:24] <BUGabundo> at home, I have lucid
[23:25] <fta> too late then, i will revert and rebuild
[23:25] <BUGabundo> okay
[23:25] <fta> 4.0.279.0~svn20091222r35149-0ubuntu1~ucd1~karmic is broken with flash apparently
[23:26] <crimsun> Installed: 4.0.277.0~svn20091219r35045-0ubuntu1~ucd1
[23:27] <fta> 4.0.277.0~svn20091221r35087-0ubuntu1~ucd1~karmic was fine
[23:28] <BUGabundo> fta: I don't have Flash on that chromium :D
[23:28] <fta> but nothing obvious between r35087 & r35149
[23:29] <micahg> fta:  wfm
[23:29] <micahg> 4.0.279.0~svn20091222r35149-0ubuntu1~ucd1~karmic
[23:36] <fta> micahg, a page with flash?
[23:37] <micahg> fta: yep, after a few refreshes, hulu and youtube work
[23:37] <fta> strange, i also tried with a fresh profile
[23:37] <fta> 32 or 64?
[23:38] <micahg> 64 bit
[23:38] <fta> BUGabundo, asac: you?
[23:38] <asac> 32
[23:39] <BUGabundo> fta: ?
[23:39] <BUGabundo> 64bits
[23:39] <fta> so 32 snaps and 64 doesn't?
[23:39] <BUGabundo> flash 64bits
[23:39] <BUGabundo> .so
[23:39] <fta> it's not flash itself, it's the renderer
[23:39]  * micahg is using adobe flash
[23:40] <fta> me too
[23:40] <fta> unfortunately
[23:40] <BUGabundo> fta: just tested youtube
[23:40] <BUGabundo> works ok with up to date chromium
[23:40] <BUGabundo> and what ever flash I have
[23:41] <fta> i can't load www.lemonde.fr for ex
[23:41] <BUGabundo> Shockwave Flash 10.0 r42
[23:41] <BUGabundo> testing
[23:41] <BUGabundo> WFM
[23:41] <BUGabundo> even with flash block
[23:41] <fta> ok so it's a 32bit issue
[23:41] <fta> the revert sounds nicer
[23:43] <micahg> fta: I can't load that site either
[23:43] <micahg> wait, it just worked
[23:43] <fta> it should load, then snap
[23:43] <fta> just that tab
[23:44] <micahg> flash crashed, you want the crash report?
[23:44] <fta> should not be very helpful, is it?
[23:45] <micahg> idk, my guess is no
[23:46] <BUGabundo> fta: still opened and going
[23:48] <micahg> http://www.downloadsquad.com/2009/12/22/opera-10-5s-new-carakan-javascript-engine-is-fast-google-chro/