[00:15] <fta> -rw-r--r-- 1 fta fta 196405039 2009-06-04 02:25 chromium-browser_3.0.184.0~svn20090604r17576.orig.tar.gz
[00:15] <fta> -rw-r--r-- 1 fta fta 219102612 2009-06-11 19:07 chromium-browser_3.0.189.0~svn20090611r18169.orig.tar.gz
[00:16] <fta> +12% in 1 week! grrr
[00:16] <BUGabundo> fta: enjoyed that dent from me !!?
[00:16] <BUGabundo> ahahaha
[00:16] <BUGabundo> can't you make those get slimmer instead?
[00:16] <fta> which one? i can't read everything you write
[00:16] <BUGabundo> I'm fat enough! don't need more height !!! eheh
[00:16] <BUGabundo> http://identi.ca/notice/5204204
[00:17] <fta> -rw-r--r-- 1 fta fta 381135135 2009-05-30 19:08 chromium-browser_3.0.183.0~svn20090530r17289.orig.tar.gz
[00:17] <fta> i already trimmed it a lot
[00:17] <fta> but it's growing again
[00:18] <fta> -rw-r--r-- 1 fta fta 305833390 2009-03-04 20:06 chromium-browser_2.0.168.0~svn20090304r10900.orig.tar.gz
[06:29] <alexbodn> hello friends. i wish to build the new lp packages for xulrunner-1.9.[12]. where should i download the upstream sources?
[07:26] <ripps> fta: ping?
[09:13] <ripps> fta still not around?
[10:23] <fta> asac, *sigh* http://www.sofaraway.org/ubuntu/tmp/chromium-tarball.png
[10:23] <fta> ripps, hi
[10:24] <BUGabundo> bons dias!
[10:25] <ripps> fta: yo, I've got a couple issues and questions about ppabot
[10:25] <BUGabundo> fta: it just keeps growing
[10:25] <fta> alexbodn, what do you mean? apt-get source xulrunner-1.9.1? or the upstream vcs?
[10:26] <asac> fta: hi
[10:26] <asac> so ia32 is broken
[10:26] <asac> it kills flash
[10:26] <asac> chromium works though
[10:26] <fta> asac, hm
[10:26] <asac> but its not the modules
[10:26] <asac> i tried removing gail (which is the only one added)
[10:27] <BUGabundo> ahhh that's why I have no sound on flash again
[10:27] <fta> BUGabundo, no
[10:27] <BUGabundo> no ?
[10:27] <BUGabundo> ohh
[10:27] <asac> its only in ftas staging thing
[10:27] <fta> BUGabundo, you're not using my staging ppa, are you?
[10:27] <asac> and it breaks flash completely ;)
[10:27] <asac> e.g. no flash at all
[10:27] <asac> not just sound
[10:27] <ripps> daily.sh seems to keep dying after pulling the source, and then it won't upload. I have to do it manually using update-pkg and sync-ppa, one package at a time. Even when I delete all the $package.head.* it still gives me trouble. Is there something I'm doing wrong?
[10:28] <ripps> The manual method updates the orig.tar.gz, but it won't copy my debian/ changes to the other distro ppas.
[10:29] <BUGabundo> fta: who knows. I'm everywhere
[10:29] <fta> ripps, update-pkg creates the orig tarball, sync merges your debian/ and pushes
[10:29] <fta> ripps, please paste me what you see
[10:29] <fta> (i should really improve logging)
[10:29] <ripps> but sync is merging the ppa's it, keeps giving me an error about the branches have diverged, merge than pull
[10:30] <ripps> *sync isn't
[10:31] <asac> oh dear ... i dont feel good. not sure what kind of flu is it, but it aint good
[10:32] <BUGabundo> asac: hope not A flu!
[10:32] <BUGabundo> don't join the other 28k
[10:32] <fta> asac, got that last week-end. sore throat and fever. feeling better now
[10:33] <asac> i am not sure what it is
[10:33] <asac> but i feel really bad
[10:34] <fta> ripps, diverges in d/control and d/changelog are ok, the bot deals with that
[10:34] <ripps> fta: but than why is quitting out after it gets one of those
[10:35] <fta> it should say something before quitting. please show me :)
[10:36] <ripps> fta: http://pastebin.com/f55b817e4
[10:37] <fta> hm, bzr is not good at reporting either.
[10:38] <fta> i think i know. you trashed your .ppa branches locally right?
[10:38] <ripps> fta: yes
[10:38] <fta> you should never do that as the main .ppa is on lp. (not the .ppa.dist)
[10:38] <ripps> Tried starting fresh
[10:39] <ripps> I've never setup a launchpad .ppa
[10:39] <ripps> Do I need to do that?
[10:40] <fta> i mean a branch called something.ppa
[10:40] <ripps> It said that the ppa field was optional, and it just pulls the debian packaging from the lp
[10:40] <fta> or .daily in my examples
[10:40] <fta> look at your code page on lp
[10:41] <fta> the same account as in you dput target
[10:41] <fta> youR
[10:43] <ripps> ohhhh, I didn't check there, becuase my debian comes from the gmpc-trunk repo, while I've been dputting to my personal staging ppa under my account.
[10:44] <ripps> I didn't realize it created code repos under the owner of the ppa
[10:45] <fta> iirc, you can add --fix to update-pkgs just once
[10:46] <fta> it will push to lp with --overwrite, which is what you need
[10:47] <ripps> fta: do I have to do that everytime I update my debian packaging on the gmpc-trunk repos?
[10:47] <fta> http://bazaar.launchpad.net/~fta/%2Bjunk/ppa-scripts/annotate/head%3A/README#L13
[10:47] <fta> no
[10:47] <fta> if you never trash your branches, you should never have to do anything
[10:48] <ripps> fta: I only started deleting them because I couldn't get them to update with new versions
[10:49] <fta> you must not uncommit either after the bot saw an update
[10:49] <ripps> Okay, ok, this was probably my bad
[10:49] <ripps> I have another issue: patching
[10:50] <fta> ?
[10:51] <ripps> I maintain backports of a single package, but some distros have different packages which require a patch to work with a different package, is there some way I can implement a method to patch only for a particlur distro (such as karmic) but not the other distros?
[10:53] <fta> hmm.. in the mozilla packages, we do that in d/rules with some tests. we can't do conditional patching directly with quilt/dpatch
[10:54] <fta> there's nothing the bot can do here. it's more about the way buildd works
[10:54] <ripps> Hmm... I'll have to take a look at them
[10:54] <ripps> Okay, another one
[10:56] <ripps> At the current time, since I use git branches I need to append the version string with a date to make update properly (git hashes don't follow an incremental manner) so is there some way for the bot to detect that package is identical to one I uploaded yesterday? It seems dumb to upload and build a package everyday that only sees updates every other week
[10:57] <ripps> but I still allow me to do manual updates in case I fix something in the debian packaging
[10:58] <fta> get the date from upstream
[10:58] <fta> don't use localtime
[10:58] <BUGabundo> fta: what was that all about?!?
[10:59] <ripps> you mean pull the date from git log?
[10:59] <ripps> ... I hadn't considered that, thanks
[10:59] <fta> ripps, yes
[10:59] <fta> ripps, http://paste.ubuntu.com/193333/
[10:59]  * ripps is going to need to update all his packaging repos now
[11:00] <fta> :)
[11:00] <fta> BUGabundo, sub-minute gwibber
[11:03] <fta> 	REV=`git log --pretty=format:%cd~%h --date=short -1 | tr -d -` ; \
[11:03] <fta> 	VERS=`perl -pe 's/,/,\n/g' api/raw.json | grep '"version":' | cut -d\" -f4 | sed -e 's/\([0-9\.]*\)/\1\~/'` ; \
[11:03] <fta> 	VERSION=$$VERS~git$$REV
[11:03] <fta> gives me 3.0.0~b1~git20090514~a32353b
[11:03] <fta> that's yui3
[11:04] <BUGabundo> fta: ahh that is crazy! I was talking about communication integraded!
[11:07] <ripps> fta: your method seems much cleaner than mine...
[11:08] <ripps> :\
[11:15] <asac> cool. this is ffox 3.5 thing is really going to be final soon i have the feeling ;)
[11:18] <andrew_sayers> asac: we talked yesterday about disabling the screensaver when Flash is on.  I'm almost done with a C app that disables it when npviewer.bin is fullscreen, without interacting with FF at all.  Where would be the best place to aim such a workaround?
[11:20] <BUGabundo> andrew_sayers: can you fix other players too ?!
[11:20] <BUGabundo> eheh
[11:20] <andrew_sayers> Other players?
[11:20] <BUGabundo> getting tired of totem allowing power manager to DIM the LCD
[11:20] <BUGabundo> andrew_sayers: joking! another bug
[11:20] <asac> andrew_sayers: good question. maybe nspluginwrapper itself?
[11:21] <andrew_sayers> BUGabundo: Ah, okay.  I've just come from fixing Kaffeine, so for a moment I thought you were reading my mind :)
[11:21] <andrew_sayers> asac: Fair enough.  Who do I talk to about that?
[11:22] <asac> andrew_sayers: for ubuntu you can talk to us. Jazzva has kind of the hat on for nspluginwrapper.
[11:22] <andrew_sayers> asac: and are you interested in getting the previous patch going, to try and detect non-fullscreen video?
[11:22] <asac> if you think its something that should go upstream, we can try to submit it for you
[11:22] <fta> jcastro, chromium now has minimize/maximize/close when the system bar & borders are off :)
[11:22] <asac> andrew_sayers: i have the feeling that the previous patch will be kind of flaky
[11:22] <fta> +buttons
[11:23] <asac> andrew_sayers: so i am interested, just wonder if it can be done in a stable fashion
[11:24] <andrew_sayers> asac: can you qualify "flaky"?  Do you mean that the heuristic it's using is inaccurate, or that the implementation is immature?
[11:25] <asac> andrew_sayers: flaky in the sense that the implementation will be hard to become mature
[11:25] <asac> most likely because the heurisitic is hard to get right
[11:25] <asac> but then. i have to check the latest code to understand more on this ;)
[11:25] <andrew_sayers> Yeah, agreed.  Do you know whether Flash disables the Windows screensaver for non-fullscreen videos?
[11:26] <asac> andrew_sayers: how about this: we get a nspluginwrapper thing into the package and when this works i can try to find some adobe contact and bug them about their plans for fullscreen + screensaver
[11:26] <asac> andrew_sayers: i dont think flash disables any screensaver atm
[11:26] <asac> (but could be wrong)
[11:27] <asac> andrew_sayers: how is that npviewer code run? is that a daemon running in user session or what?
[11:27] <andrew_sayers> I'll go and have a look at Windows later.  Good plan though, I'll be back once I've figured out how to get DBus working in C.
[11:27] <asac> andrew_sayers: ah cool. so this is a dbus activated service?
[11:28] <andrew_sayers> Ah, no.  It would continuously poll X, looking for instances of npviewer.bin with fullscreen properties, then send a DBus message to inhibit the screensaver.
[11:28] <asac> andrew_sayers: if you want to use gobject its simple. if you dont, check out the gdbus lib available on moblin ... it gives you gmainloop integration without the gobject overhead (so plain glib)
[11:29] <asac> hmm. gdbus is currently nto available as a git tree anymore
[11:29] <asac> too bad ;)
[11:29] <asac> its in connman though if you want to take a look. we will make a top level package out of it soon
[11:29] <andrew_sayers> I've got a glib example I'm working from, it's just the avalanche of new things that's slowing me down :)
[11:29] <asac> http://git.kernel.org/?p=network/connman/connman-gnome.git;a=summary
[11:29] <asac> andrew_sayers: yeah. but the glib example probably uses glib-dbus
[11:30] <asac> and _that_ is using GObject stuff
[11:30] <asac> gdbus is more light wait ;)
[11:30] <andrew_sayers> Ah, right.  Good thing I came here first then :)
[11:30] <asac> anyway. if you just want something to send a call, go whatever you find first ;)
[11:30] <asac> andrew_sayers: its not a general problem. just that some (including me), doesnt like to use GObject unless i develop an app that needs GObject
[11:31] <andrew_sayers> Yeah, agreed.
[11:31] <asac> http://git.kernel.org/?p=network/connman/connman.git;a=summary
[11:31] <asac> sorry the other was the wrong one
[11:32] <asac> if you want to use that you can just copy the files to your own tree for now
[11:32] <asac> http://git.kernel.org/?p=network/connman/connman.git;a=tree;f=gdbus;h=7f2feded81c57833cbea6a8a8610a221ac2f960c;hb=master
[11:32] <asac> we will make a lib from it asap
[11:33] <andrew_sayers> Okay, so I'll have a go with gdbus, and get back to you in a bit.
[11:36] <BUGabundo> did I read "continuously poll X" ??
[11:37] <andrew_sayers> BUGabundo: More precisely, examine the properties of every X window every (say) 30 seconds.
[11:38] <BUGabundo> andrew_sayers: ever run $ powertop ?
[11:38] <BUGabundo> want me to kill you next?
[11:38] <BUGabundo> polling is bad!
[11:38] <BUGabundo> listen on status change is good
[11:39] <andrew_sayers> How do I do that, for X properties?
[11:39] <fta> gnome 317982
[11:39] <fta> gnome 324114
[11:39] <fta> gnome 331019
[11:40] <fta> hmm
[11:40] <BUGabundo> fta: what's all of that?
[11:41] <BUGabundo> andrew_sayers: don't ask me... I don't even code!
[11:41] <BUGabundo> I just bash stuff I think its bad, and file bugs on stuff that doesn't work
[11:41] <fta> BUGabundo, some rhythmbox bugs
[11:41] <BUGabundo> talking of bugs....
[11:41] <fta> BUGabundo, you should code, you would dent less then ;)
[11:42] <BUGabundo> asac: I never managed to file that bug on NM opening the 3G assintant when there's an account For All users
[11:42] <BUGabundo> fta: ahahahahahahahaha
[11:42] <BUGabundo> the day I start to code, I'll double Linux code lines !
[11:42]  * BUGabundo now that deservs a dent
[11:44] <micahg> asac: they seemed to fix a lot of bugs in the FF3.0.11 release
[11:45] <fta> *sigh* rhythmbox seems alive to me: http://mail.gnome.org/archives/rhythmbox-devel/2009-May/msg00089.html
[11:45] <BUGabundo> it was never dead!
[11:45] <BUGabundo> just in coma
[11:48] <fta> BUGabundo, please don't use that: http://mail.gnome.org/archives/rhythmbox-devel/2009-May/msg00038.html   :)
[11:51] <asac> BUGabundo: there is a bug open for that
[11:51] <asac> i dont know the number though
[11:52] <BUGabundo> asac: for what?
[11:52] <micahg> asac: is it worth going through the 67 or so bugs fixed in 3.0.11 and seeing if we have corresponding issues in LP?
[11:53] <fta> asac, mozilla 497807
[11:53] <asac> BUGabundo: for 3g wizard opening eve if there is a system connection
[11:53] <BUGabundo> ahh great
[11:55] <BUGabundo> fta: * Last.fm submission protocol v1.2 (including the 'now playing' feature)
[11:55] <BUGabundo> err that's dead too...
[11:56] <asac> fta: not sure whats up with him ;)
[11:57]  * micahg whistles off in the corner
[11:57] <asac> micahg: if you can look through those 67 bugs that would be cool
[11:58] <asac> but i think most issues are not filed inlaunchpad
[11:58] <micahg> My guess is quite a few are w/out upstream labeled
[11:58] <micahg> if you don't think it's worthwhile, work on normal bugs
[11:58] <micahg> one bug thing I noticed was the bookmarks fix
[11:59] <micahg> I think we have a few bugs for that unconfirmed
[11:59] <asac> micahg: yeah. so you can definitly do that
[11:59] <asac> micahg: set them to fix committed
[11:59] <asac> we will release .11 today
[11:59] <micahg> ok, I'll try this weekend
[11:59]  * micahg needs sleep now :)
[11:59] <micahg> is this prime time for Europe?
[12:00] <BUGabundo> !date
[12:00] <BUGabundo> Fri Jun 12 12:01:02 WEST 2009
[12:01] <BUGabundo> humm now that I notice. its almost lunch time. and I did nothing today, other then filling a few bugs
[12:01] <BUGabundo> damn
[12:02] <micahg> oh, I found this weird color bug for ati x86_64 systems
[12:03] <BUGabundo> eheh
[12:03] <BUGabundo> the one from yesterday?
[12:03] <micahg> yeah
[12:04] <BUGabundo> can I set Ctrl-Q to not close Firefox?
[12:04] <micahg> mozilla bug 490537 if anyone's interested
[12:05] <BUGabundo> I keep hitting both ctrl-w  and ctrl-q
[12:05] <micahg> i'm off to bed
[12:08] <BUGabundo> http://xkcd.com/596/
[12:10] <ripps> fta: I have a package called gmpc-plugins that contains 20+ individual repos most git, one is hg. I want to use method so that the package will only update when one of the repos changes, otherwise It'll build 20+ plugins everyday, pointlessly
[12:11] <fta> hmm, tricky
[12:11] <fta> manually, how would you check that?
[12:12] <fta> ..that an update is needed
[12:15] <ripps> fta: in the past I've used a method of running a script that would compile a changelog based on the date the package was last created and what changes have occured in each repo.
[12:16] <ripps> I might be able to adapt that script to check if any changes have occured, if the script doesn't create any output, then no update
[12:17] <ripps> fta: can you create functions in rules files?
[12:19] <fta> ripps, yes, sort of. you can use "call", but it's not trivial. it's often easier to just run an external script
[12:19] <fta> ripps, http://www.gnu.org/software/make/manual/make.html#Call-Function
[12:20] <fta> you probably want an external script here
[12:22] <fta> but if you do your get-orig-source well, with a good cache, you should not need that at all. the bot could just update the branches from your cache, pack, and detect the filename is the same so no need to push anything
[12:22] <fta> (assuming the packaging branch is the same too)
[12:23] <fta> ripps, ^^
[12:24] <fta> ripps, do you poll random snapshots for all those branches, or do you have a master branch pointing to specific revisions of each branch?
[12:25] <fta> -poll+pull
[12:30] <asac> too bad kaze crashes after xul 1.9.1 respin
[12:30] <asac> kazehakase it is
[12:30] <asac> anyway ... lunch now
[12:33] <ripps> fta: http://pastebin.com/f3f347531
[12:35] <fta> i see
[12:37] <fta> the problem with that is there's no way to replay it. i mean, if i re-run get-orig-source to recreate the tarball, i'll probably end-up with a different thing.
[12:42] <fta> would make sense to group all those branches in a common branch, and use that branch for the tarball, so you have just one version & rev id
[12:51] <ripps> fta: how do you mean?
[12:54] <fta> ripps, you create an empty dir/branch, pull all your branches in there, commit, and teach your get-orig to pack that. the next day, your get-orig updates all the branches inside, commit, if there's something new, you have a new revision for the bot to use, otherwise, the bot will just pack and realize there's nothing new.
[12:55] <ripps> fta: right now, I have my script need to fetch the repos stored in code branch.
[12:56] <fta> your problem is that you need a unique rev-id to avoid unnecessary updates
[12:56] <ripps> fta: I think I already implemented that. My gmpc-plugins branch contains none of the git/hg repos. It only has the autogen.sh, configure.ac, makefile.am, and fetch.sh. fetch.sh is what pulls all of the repos locally.
[12:57] <ripps> so... branch from gmpc-plugins, fetch, than push to gmpc-plugins.fetch?
[12:57] <fta> if you already have that, it's easy. you may want to export it somewhere, so others could use ut
[12:59] <ripps> I think I get it, because bzr commit will only allow a commit if there's changes, so the gmpc-plugins.fetch will be the one I store the rev id, and it'll only update when packages have actually been changed
[12:59] <ripps> Then I just use bzr$REV
[13:00] <fta> yes, i would do that in bzr. empty branch at the start with .git & .hg in bzrignore, the clone/pull/update/whatever the sub branches, bzr commit. done
[13:01] <fta> -the+then
[13:02] <ripps> so... the whole get-changes script I made, I don't need it :\
[13:02] <fta> lol
[13:05] <ripps> put '*/.git' and '*/.hg' in .bzrignore, correct?
[13:15] <asac> just .git
[13:15] <fta> yep, something like that, so you're not committing that to bzr (and getting false positives)
[13:15] <asac> i think
[13:15] <asac> you can use bzr ignore path/to/file/to/ignore
[13:15] <asac> that will auto add stuff
[13:16] <fta> asac, ready to experiment yourself with the bot? :)
[13:16] <asac> nope ... i am most in the sick bay ;)
[13:17] <asac> just waiting for a call i have in 1h to exit computer
[13:17] <asac> not yet sure how i can speak there given that i cannot even breath
[13:17] <asac> but i will really soon
[13:17] <asac> ffox sec update also has to go out today
[13:18] <asac> and next week the 1.8 branch together with tbird i would think
[13:20]  * asac sycs mails to laptop
[13:24] <fta> asac, please remember to sign the gpg keys someday
[13:24] <BUGabundo> ahaha
[13:24] <fta> only got about 15 out of 40
[13:26] <asac> fta: i definitly will.
[13:26] <asac> fta: i guess some also sent their sigs to key servers and not through mail
[13:26] <asac> fta: rnu gpg --recv-keys YOURID
[13:27] <asac> to grab them in case they did that
[13:28]  * asac movinng to different room without sun
[13:28] <fta> iirc, the tool sends emails by default, or emails + push
[13:45] <asac> fta: yes. but not everybody is using caff
[13:48] <fta> asac, how do i see my own web of trust?
[13:49] <asac> fta: signatures?
[13:49] <asac> fta: gpg --list-sigs fta@ubuntu
[13:49] <asac> (or KEYID)
[13:51] <asac> there was a website where you could see your connections
[13:51] <asac> cant find it right now
[15:04] <ripps> fta: in gmpc-plugins, when I do a commit without changes, the error bzr throws causes the daily.sh script to exit. How can I prevent this?
[15:10] <fta> ripps, where is that commit? get-orig?
[15:11] <ripps> yes
[15:11] <ripps> I fixed it by adding || and an echo after it
[15:12] <fta> yep, bzr commit || test $? = 1  or something like that
[15:14] <ripps> actually, it seems just adding || causes the script to negate the error
[15:19] <ripps> well, it's my bedtime, I'll see how the packages built when i wake up
[15:40] <asac> fta: wotsap - OpenPGP Web of Trust analyzer and pathfinder
[15:54] <fta> asac, i'm filing a bug in evolution. could you tell me if you understand it: http://paste.ubuntu.com/194414/ ?
[16:01] <BUGabundo> you lost me in there
[16:01] <BUGabundo> what's wrong exaclty ?
[16:01] <BUGabundo> 554 5.7.1 <first.last@corporate.com>: Sender address rejected: domain use is reserved  ?
[16:03] <fta> yes
[16:03] <fta> it rejects the email
[16:08] <asac> fta: yes. not sure though whats the right behaviour ;)
[16:08] <asac> but file it upstream and see
[16:08] <asac> you can also ask on #evolution on irc.gimp.org i guess
[16:08] <asac> does tbird have the same problem?
[16:08] <fta> yes
[16:10] <fta> gnome 585577
[16:26] <fta> asac, wotsap doesn't even know my key
[16:27] <asac> fta: did you ever send your key to keyservers?
[16:27] <asac> gpg --send-keys YOURKEYID
[16:28] <fta> i sure did, several times, long ago and today
[16:28] <fta> http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&search=0xB6EE20E8
[16:28] <fta> but it looks empty compared to, say: http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&search=0xEF584970
[16:30] <asac> fta: yeah. so if you didnt push your key after you added the sigs then thats normal
[16:30] <asac> probably takes a few days
[16:31] <fta> i did, to subkeys.pgp.net
[16:33] <asac> yes.
[16:33] <asac> will take a bit tilll it goes to mit from there etc
[16:35] <asac> fta: http://subkeys.pgp.net:11371/pks/lookup?op=vindex&fingerprint=on&search=0x68E7CD1DB6EE20E8
[16:35] <fta> oh, better, thanks
[16:50] <fta> asac, FIREFOX_3_5rc1_RELEASE
[16:51] <fta> time to revert the branding
[17:31] <asac> fta: i would prefer to not switch branding until we make it the default .... which hopefully happens before alpha3 or shorly after
[17:31] <asac> but lets discuss this later. i have to go to dinner now
[17:32] <sebner> asac: I'm wondering that the progress of TB3 is :)
[18:30] <fta> asac, are you sure your flash crashes were caused by my ia32-libs?
[18:38] <fta> BUGabundo, wanna do a kick test? :)
[18:40] <BUGabundo> eheh
[18:40] <BUGabundo> not now
[18:40] <BUGabundo> leaving right now
[18:40] <BUGabundo> ping me tomorrow
[18:46] <asac> fta: yes. downgrading cured it
[18:47] <fta> ok
[18:52] <asac> not sure how to track down what caused this though
[19:31] <andrew_sayers> asac: I'm finally done with the meat of this C implementation.  If you're still about, I'd like to ask your opinion about licensing, code style, and how/where to upload it.
[19:34] <asac> andrew_sayers: if its nspluginwrapper specific code, preferably use the same license they are using (or something compatible). for code-style same answer, see what they are doing.
[19:35] <asac> sebner: i wonder too ;) ... i will gently ask again (next week?)
[19:36] <sebner> asac: ehehe! :)
[19:36] <andrew_sayers> asac: you mentioned talking to the Adobe guys about getting it Flash to actually work.  I've put the screensaver bits into a (trivial) file of its own.  If I put it under some permissive license, would it make that conversation easier?
[19:37] <andrew_sayers> "Here's a bit of C, call it when you like."
[19:38] <asac> andrew_sayers: it might help, but i think its unlikely; its more about getting them think about it and prioritze
[19:41] <andrew_sayers> Fair enough - nspluginwrapper seems like the natural place to put it, although it would basically need to be a process (or at least a thread) of its own.
[19:43] <andrew_sayers> How about I file a bug report against nspluginwrapper, with a patch including the new code?
[19:44] <asac> Jazzva: there?
[19:45] <asac> andrew_sayers: lets see if Jazzva is there ;)
[19:45] <andrew_sayers> Sure :)
[19:45] <asac> andrew_sayers: in general i would prefer that you prepare a bzr branch and ask for merging. just need Jazzva to tell us whats the current state of our branches ;)
[19:46] <andrew_sayers> In the mean time, last question: I ended up using the raw dbus code (not gdbus or glib-dbus), but I could only get it to work linking against dbus-glib-1.  Am I missing something?
[19:46] <asac> andrew_sayers: if you only used raw dbus code then there is something wrong
[19:46] <asac> you should be able to lnk against just dbus
[19:47] <asac> dbus-1
[19:47] <asac> most likely you used gobject ;)
[19:48] <andrew_sayers> No, just forgot the -1 :)
[19:48] <asac> andrew_sayers: hehe. pkg-config --list-all | grep dbus
[19:48] <asac> ;)
[19:49]  * andrew_sayers adds this to the pile of things he learnt today
[19:58] <asac> andrew_sayers: https://code.edge.launchpad.net/~ubuntu-dev/nspluginwrapper/ubuntu
[19:59] <andrew_sayers> Ah, great.
[20:00] <andrew_sayers> If Jazzva doesn't get back to us, I'll put in a merge request when I've got it all tidy (should be by the end of the night).
[20:00] <asac> you can just do bzr lp:nspluginwrapper
[20:00] <asac> err bzr branch lp:nspluginwrapper
[20:00] <asac> ;)
[20:14] <Jazzva> asac: here, but busy with school :(... lp:nspluginwrapper is currently the latest nspluginwrapper we have in
[20:16] <asac> Jazzva: thanks. good luck with getting school done ;)
[20:17] <Jazzva> yeah... two more exams to go in this month... the next one is tomorrow morning, so hopefully I'll have more time after that :). the exam after that one is in few weeks, and easy.
[20:18] <Jazzva> asac: if you need anything about nspluginwrapper, just ask, I'll look at chat notifications from time to time...
[20:18] <asac> exam on sat?
[20:18] <asac> thats brave ;)
[20:18] <asac> good luck for that!
[20:18] <Jazzva> but not the worst... exam on sunday at 8am... had two of those. scary time :)
[20:19] <Jazzva> good luck with work here :). i'm back to multicast and the rest of that network-y stuff...
[21:40] <BUGabundo> asac: did the Font changes landed today on hardy?
[21:40] <BUGabundo> my system fonts is alllllll messed up!
[21:41] <asac> BUGabundo: font changes? hardy? no clue ;)
[21:42] <BUGabundo> very strange
[21:42] <BUGabundo> *everything* is bigger
[21:42] <BUGabundo> just like during jaunty cycle
[21:42] <BUGabundo> when we removed the 96DPIs
[21:44] <asac> BUGabundo: yes, but hardy? i doubt it
[21:45] <BUGabundo> grr
[21:45] <BUGabundo> karmic asac!!!!
[21:46] <andrew_sayers> asac: this is probably a newbie question, but what do I need to install to clear a "undefined reference to `__stack_chk_fail@GLIBC_2.4'" error compiling nspluginwrapper on 64-bit?
[21:47] <andrew_sayers> (And several similar messages)
[21:50] <asac> andrew_sayers: did you try to build the branch just using "debuild -b" ?
[21:51] <BUGabundo> asac: any ideas?
[21:51] <BUGabundo> karmic koala!! LOLO hardy what was i thinking
[21:51] <asac> 22:40 < BUGabundo> asac: did the Font changes landed today on hardy?
[21:51] <asac> yeah ;)
[21:51] <BUGabundo> I know I know
[21:51] <BUGabundo> you should know better too
[21:52] <asac> BUGabundo: no. but maybe they loosened the 96dpi thing again?
[21:52] <BUGabundo> read past the obvj«ious typo
[21:52] <asac> BUGabundo: what updates did you get today?
[21:52] <BUGabundo> let me /var/log/apt
[21:52] <asac> BUGabundo: thats why i was confused ;)
[21:53] <andrew_sayers> asac: Yeah, same result.  Actually, there's no reason why I need to compile my code in 32-bit mode...
[21:53]  * andrew_sayers gets back to ugly hacks
[21:54] <asac> andrew_sayers: we build nspluginwrapper on both: 32bit and 64bit
[21:54] <asac> e.g. you can also use it on 32bit systems
[21:54] <asac> so i guess you should just use the host arch
[21:59] <asac> andrew_sayers: so if i just do bzr branch lp:nspluginwrapper and run debuild -b in it, it works. the __stack_chk_fail thing is some security stack protection feature. if thats an issue you usually do something wrong ;)
[22:00] <asac> andrew_sayers: heh. so you are right ;)
[22:00] <asac> Jazzva: nspluginwrapper actually fails to build
[22:00] <asac> Jazzva: guess karmic regression because of gcc 4.4
[22:01] <andrew_sayers> asac: Have you got the following packages installed: gcc-multilib g++-multilib libc6-dev-i386 ?
[22:01] <andrew_sayers> asac: I had to hunt them down and install them by hand.  Wouldn't build before that.
[22:01] <asac> well, i have all build deps installed ;)
[22:02] <asac> yeah. they are installed
[22:03] <BUGabundo> asac: try really really hard to pastebin this
[22:03] <andrew_sayers> That's weird.  What error are you getting?  I was only getting problems with the extra stuff I've added.
[22:03] <BUGabundo> and 2 sites are failing to accept 200KiBs of text
[22:03] <BUGabundo> :((((
[22:03] <andrew_sayers> (Which might have cleared by now)
[22:03] <asac> andrew_sayers: well. the error you asked above ;)
[22:03] <asac> andrew_sayers: http://paste.ubuntu.com/194625/
[22:04] <asac> __stack_chk_fail
[22:04] <asac> ;)
[22:04] <andrew_sayers> Ah yeah, with supc++, which I sorted... somehow...
[22:04] <asac> you remember?
[22:05] <Jazzva> asac: huh... i have no idea why :)... IIRC I compiled 1.3.0 correctly over here (which still isn't yet in Ubuntu)
[22:05] <Jazzva> *which isn't in karmic yet
[22:05] <asac> Jazzva: did you build on karmic?
[22:05] <Jazzva> asac: yes
[22:05] <asac> odd
[22:05] <Jazzva> that's what I'm currently running...
[22:05] <Jazzva> lemme do another build, just to be sure
[22:06] <asac> let me try gcc-4.3
[22:06] <andrew_sayers> asac: I'm using 4.3.3, so that could be it.
[22:08] <Jazzva> asac: it built correctly again...
[22:08] <asac> yes. 4.3.3
[22:08] <asac> works
[22:09] <asac> but gcc fails
[22:10] <Jazzva> asac: I have gcc-4.3 also installed... that might be the reason why it's compiling correctly
[22:11] <Jazzva> and now I removed it, and it still builds nicely...
[22:12] <andrew_sayers> Jazzva: is your computer 32 bit, by any chance?
[22:12] <Jazzva> andrew_sayers: it's 64-bit, but with 32-bit Ubuntu installed on it
[22:12] <Jazzva> (so, I guess that means it's like 32-bit :))
[22:19] <asac> andrew_sayers: so this build failure is only happening with gcc 4.4 on amd64
[22:19] <asac> nspwrapper ships something like this: http://paste.ubuntu.com/194635/
[22:20] <andrew_sayers> asac: the failure you're looking at, yes.  My error was different in its full context, and is now (seemingly) resolved.
[22:20] <BUGabundo> asac: http://dl.getdropbox.com/u/112892/f.txt
[22:20] <BUGabundo> grr couldn't sent it to any pastebin so put it on my dropbox
[22:20] <BUGabundo> uploading now
[22:39] <asac> andrew_sayers: ok getting rid of the lsb-build cruft helps
[22:39] <asac> need to do a clean patch
[22:39] <asac> for now use gcc-4.3
[22:40] <andrew_sayers> asac: I'm using Jaunty, so that's all I've got :)
[22:40] <asac> yeah. so you are lucky ;)
[22:40] <asac> fta: so do we have a ia32 -dev package for gtk?
[22:40] <andrew_sayers> Unless there's anything else, I'm planning to upload this branch and head off to bed.
[22:41] <asac> ah there is ia32-libs-dev
[22:41] <asac> checking that
[22:41] <andrew_sayers> I've got this to compile, I'll test it tomorrow and upload after Jazzva's exam :)
[22:41] <fta> asac, should not be needed
[22:41] <asac> fta: so ia32libs has all the sos?
[22:41] <asac> ok
[22:42] <fta> asac, ia32-libs provides all the links now that i fixed it (hopefully for good)
[22:42] <fta> you still need the regular -dev packages for the headers
[22:47] <asac> yeah
[22:48] <andrew_sayers> Okay, the code's at https://code.launchpad.net/~andrew-bugs-launchpad-net/nspluginwrapper/flashsaver - hopefully you'll see a merge request tomorrow, once I've finished debugging.
[22:48] <andrew_sayers> In the mean time, thanks for the help and goodnight :)
[22:55] <fta> hm, ~rc1 > ~hg... can't do that then
[22:55] <fta> always the same story when reaching RCs..
[23:02] <BUGabundo> fta: some one doesn't know their math
[23:02] <BUGabundo> www.macno.org/denticator.php?user=bugabundo Based on last 1000 dents posted in the last 1 days daily  average is 1000 but excluding days without dents, the average is 500
[23:02] <fta> lol
[23:03] <BUGabundo> how can I not have dents on the single day it countS?
[23:20] <asac> Jazzva: commited fix to lp:nspluginwrapper (i think its a fix ;))
[23:24] <Jazzva> thanks :)
[23:25] <asac> Jazzva: does nspluginwrapper work on 32bit with ftas ia32libs?
[23:25] <asac> hmm guess you dont have those ;)
[23:25] <asac> stupid question actually ;)
[23:25] <asac> ia32libs on 32bit ;)
[23:29] <asac> so no. doesnt help :/
[23:30] <Jazzva> what doesn't help?
[23:30] <asac> unrelated.
[23:30] <asac> nspluginwrapper doesnt work with updated ia32libs package
[23:30] <asac> now that we found that there were issues with the lsb-build duplication stuff i thought maybe the fix for that might have cured it as well
[23:30] <asac> but its still broken
[23:33] <Jazzva> huh... I'm sorry I can't help right now :/. I'll try tomorrow (if I don't collapse from the lack of sleep). good luck with that :)
[23:33] <asac> all fine ;)
[23:43] <micahg> asac: can I PM you?
[23:43] <asac> micahg: not good for public ;)?
[23:43] <BUGabundo> ah??!
[23:43] <micahg> yeah
[23:44] <asac> micahg: if thats the case then go ahead ;)
[23:44] <BUGabundo> since when do we have secrets !!?
[23:44] <BUGabundo> ehehe
[23:44] <BUGabundo> now I'm curious!
[23:46]  * micahg doesn't want to embarass others
[23:47] <BUGabundo> hahah
[23:47] <BUGabundo> PVT me too... I want to know
[23:47] <BUGabundo> lol
[23:47] <BUGabundo> did asac leave his zipper open ?
[23:47] <BUGabundo> LOLOL
[23:53] <micahg> if FF 3.0  just bug fixes and security updates at this point?
[23:53] <micahg> *is
[23:53] <BUGabundo> yes
[23:53] <BUGabundo> on pre-karmic
[23:54] <asac> micahg: ffox 3.0 is now getting in even more frozen state
[23:54] <asac> really just high importance bugs and security issues are going in
[23:55] <micahg> ok, so if a package has a bug in ff3.0 and ff3.5 should I add 3.5 to it?
[23:56] <asac> micahg: i am not sure if we really want to do a mass addition of 3.5
[23:56] <asac> micahg: at least not if there is no chance of upstreaming a bug
[23:56] <asac> so dont do that for bugs that are not ready for upstreaming
[23:56] <asac> we did that for 3.0 ... and we will get enough bugs soon enough
[23:56] <micahg> ah, ok
[23:56] <micahg> what if it's upstream already?
[23:58] <asac> micahg: if its upstream already its good to verify if its still 3.5 and if something changes, comment on upstream bug
[23:58] <micahg> what about if it's just still present?
[23:59] <asac> micahg: add 3.5 target
[23:59] <asac> if upstream bug doesnt have much acitivity you can drop a line that this was confirmed to be still in firefox-3.5
[23:59] <micahg> ok, but do I need to comment upstream?
[23:59] <micahg> ok
[23:59] <micahg> :)
[23:59] <asac> but if the bug is actively worked on upstream you dont need to do that