[00:36] <YokoZar> Hey can I get in on the Ubuntu One private beta that's rumored to exist (I read the desktop team minutes ;) )
[00:37] <calc> YokoZar: you'll have to ask kenvandine_wk i think its going to be more widely beta at UDS or something like that, but i'm not certain
[00:37] <YokoZar> I can wait till then I guess
[01:01] <rickspencer3> YokoZar: Still there?
[01:01] <YokoZar> rickspencer3: yeah
[01:01] <rickspencer3> so, I think the Ubuntu 1 team is planning a limited beta around the time of UDS
[01:02] <rickspencer3> but I *think* it starts out invite only
[01:02] <rickspencer3> are you on loco team or Ubuntu?
[01:02] <YokoZar> Then I'll give you a business card at UDS and you can invite me ;)
[01:02] <rickspencer3> sweet
[01:02] <YokoZar> We've met before actually
[01:02] <rickspencer3> oh?
[01:02] <YokoZar> https://launchpad.net/~scottritchie
[01:03] <rickspencer3> Scott!
[01:03] <rickspencer3> hi
[01:03] <rickspencer3> okay, so you'll meet up with those guys at UDS
[01:03] <YokoZar> Will do ;)
[01:03] <rickspencer3> looking forward to seeing you in Barcelona!
[01:03] <rickspencer3> Ole!
[01:03] <YokoZar> I tend to avoid going by Scott in the Ubuntu circles because there's a much more well known Scott, heh
[01:03] <rickspencer3> lol
[01:04] <rickspencer3> well, sometimes it takes me a while to connect irc nicks and real names
[01:04] <rickspencer3> notice my incredibly uncreative nick
[01:04] <YokoZar> Yeah no kidding.  I've given half serious thought to changing my real name to Yoko ;)
[01:32] <kenvandine_wk> hehe... i am kenvandine and i hide behind the kenvandine irc nick... super secret
[02:39] <rickspencer3> robert_ancell: good morning
[02:39] <robert_ancell> rickspencer3: hey rick
[02:40] <rickspencer3> robert_ancell: I just sent the meetings from the team meeting
[02:41] <rickspencer3> you may want to refer to the irc log related to our discussion yesterday about bug workflow
[02:42] <robert_ancell> reading now
[02:49] <robert_ancell> kenvandine_wk: my UI always fails to authenticate - is there anything I can do to debug it?
[02:50] <robert_ancell> rickspencer3: looks like it will be quite a discussion at UDS regarding bugs!
[02:50] <rickspencer3> heh
[02:50] <rickspencer3> too bad seb128 wasn't there, it would have been an even more spirited discussion!
[02:50] <robert_ancell> :)
[02:51] <robert_ancell> kenvandine_wk: s/UI/U1/
[02:52] <robert_ancell> rickspencer3: In Ekiga are you using the SIP proxy voip.canonical.com?
[02:52] <rickspencer3> robert_ancell: nope
[02:52] <rickspencer3> I use ekiga.net (like users would ;) )
[02:53] <rickspencer3> also, I haven't gotten around to setting up the canonical sip :(
[02:53] <robert_ancell> rickspencer3: you go through a router? do you have any port forwarding setup?
[02:53] <rickspencer3> robert_ancell: I do go through a router, but ekiga works with most people
[02:53] <rickspencer3> I mean, it works when I talk to most people
[02:54] <rickspencer3> not sure if port forwarding is set up for it though
[02:54] <rickspencer3> I set it up for some protocols, but don't think I did it for sip
[02:54]  * calc needs a faster computer to build OOo, a 2-way 6-core xeon would be nice :)
[02:54] <robert_ancell> rickspencer3: it will work as long as one has port forwarding or uses a proxy.  I think both of us have neither so it can't make a direct connection (which is why 500@ekiga.net works but dialing users doesn't)
[02:55] <ajmitch> calc: does OOo build in parallel that well?
[02:55] <rickspencer3> hmm
[02:55] <robert_ancell> rickspencer3: this is a documented requirement for Ekiga and there is a bug requesting Ubuntu have a default SIP proxy
[02:55] <rickspencer3> robert_ancell: I don't have time tonight, but perhaps tomorrow
[02:55] <calc> ajmitch: i think up to 10 thread not sure about higher
[02:55] <robert_ancell> rickspencer3: ok, will play around
[02:55] <calc> ajmitch: of course some of the stuff isn't parallelizable like the dh_shlibdeps crud
[02:55] <robert_ancell> rickspencer3: (either way Ekiga does not give enough feedback)
[02:55] <rickspencer3> yeah
[02:55] <ajmitch> calc: as long as you wouldn't have all but 1 core sitting idle :)
[02:55] <rickspencer3> but when it works, it so cool and useful :)
[02:57]  * calc is thinking about buying a core i5 at the end of the year
[02:58] <ajmitch> I'm getting very tempted to replace my main computer, at about 3 years old
[02:58] <calc> all i have currently is a c2d e6300 which is pretty slow for OOo, takes ~ 4hr initial build and 1.5hr for rebuilds
[02:58] <ajmitch> I thought you were dropping OOo soon?
[02:59] <calc> ajmitch: going to 20% time for maintaining it later this week, but still will be working on it
[02:59] <ajmitch> then not wasting any of that 20% will be important
[02:59] <calc> ajmitch: yea, with a single build taking 4hr doing triage while i wait on it is important and hoping it doesn't fail after a few hours also is good
[03:03] <calc> rickspencer3: if we can come up with a good plan for bug handling, wrt UDS etc, once i am back fulltime i should have time for more than just OOo :)
[03:03] <rickspencer3> calc: right
[03:03] <rickspencer3> OR
[03:04] <rickspencer3> have time to really do some cool stuff with OOo
[03:04] <rickspencer3> or both
[03:04] <calc> yea
[03:04] <calc> well time for more than just triaging anyway :)
[03:06] <calc> doing cool stuff with OOo is somewhat complicated by the fact it is a giant monolithic blob of code :-\
[03:07] <calc> but it looks like there are real rumblings inside of Sun finally to do a real split similar to the Novell work instead of just the current branding stuff
[03:08] <calc> the way OOo currently works is a pretty high barrier for developers
[03:09]  * ajmitch has never been tempted to dive in & improve it
[03:12] <calc> ajmitch: its pretty gross ;-\
[03:13] <calc> ajmitch: i had thought about trying to fix up things like getting it FHS compliant but its such an apparent mess (at least that I saw) that I just gave up, it would haven't taken a long time to determine how to fix it and even longer to convince Sun to take the patches
[03:13] <calc> s/haven't/have/
[03:14] <calc> once they eventually get it split up it will probably be easier to fix things like that
[03:14] <ajmitch> hopefully it'll end up with some more community input & development in the long term
[03:15] <calc> ajmitch: yea that is the thinking of what will probably happen now that Sun has been bought by Oracle
[03:16] <calc> would be nice to get it converted over to gettext, if that is actually doable for a cross platform project
[03:16] <calc> but things like that and getting it converted to a real dialog layout format are huge projects
[03:16] <ajmitch> I don't really use OOo much, but it would be nice to not see it die off & stagnate
[03:16] <calc> yea
[03:17] <calc> it seems that things that originally come from closed source have issues converting over to real open source projects
[03:17] <ajmitch> because the development culture grows along with the project
[03:18] <ajmitch> it's not something that is easily added in later
[03:18] <rickspencer3> good night all
[03:18] <calc> yea, and getting the company that released it openly to let go to a community organization is hard too
[03:18] <rickspencer3> robert_ancell: need anything before I shut down?
[03:18] <calc> rickspencer3: goodnight
[03:19] <robert_ancell> rickspencer3: nope, have a good night
[03:19] <rickspencer3> tanks
[06:27] <pitti> Good morning
[06:35] <pitti> bryce: with that recipe, i915 gets probed (and the mode set) about 2/3 into the boot process
[06:35] <pitti> bryce: which is a fairly nasty time, since it will interrupt usplash, etc, and also not look good with plymouth
[06:35] <pitti> bryce: I guess it should be moved into the initramfs, as the first thing it does?
[07:05] <robert_ancell> pitti: hello
[07:05] <robert_ancell> pitti: I have a question about building new debs.  I've made the merge for glade but when I run dpkg-buildpackage it reverts my changes. How do I build it with the changes?
[07:06] <pitti> robert_ancell: what did you change?
[07:07] <robert_ancell> pitti: and the new avahi requires a new libcap-dev package - what is the process to update that?
[07:07] <robert_ancell> pitti: debian/control - added a new conflicts
[07:07] <pitti> aah
[07:07] <pitti> robert_ancell: I bet it uses a debian/control.in
[07:07] <robert_ancell> duh...
[07:07] <pitti> I often stumble over this as well
[07:08] <pitti> robert_ancell: if you need a newer libcap2 source, just update it; however, we have the latest one from Debian in Karmic (2.16-5), isn't that recent enough?
[07:08] <pitti> robert_ancell: if you need a newer version, please package it and ask me to sponsor it
[07:09] <robert_ancell> pitti: why does http://packages.ubuntu.com/karmic/libcap-dev show an older version?
[07:09] <pitti> I guess it takes a while to catch up
[07:09] <pitti> robert_ancell: use rmadison
[07:09] <pitti> rmadison libcap-dev
[07:10] <pitti> or, if you are on karmic, just apt-cache show libcap-dev, but I guess you are on jaunty?
[07:10] <robert_ancell> yup in jaunty
[07:11] <robert_ancell> so, should I try building on jaunty or just propose it for karmic and fix any problems later?
[07:13] <pitti> robert_ancell: generally, all development happens for karmic now (and preferably _on_ karmic as well)
[07:13] <pitti> robert_ancell: you can use a pbuilder or a chroot
[07:14] <pitti> robert_ancell: but if it's just libcap-dev, just download the karmic source and build/install it on your jaunty system
[07:14] <pitti> that's easier
[07:14] <robert_ancell> ok.  Is it safe to upgrade to Karmic yet?
[07:14] <robert_ancell> "safe"
[07:14] <pitti> works for me :)
[07:14] <pitti> I surprisingly little damage
[07:14] <robert_ancell> alright, I think I'll do that then..
[07:15] <pitti> if you dist-upgrade, you should have a look at which packages it wants to remove
[07:15] <pitti> with the current buildd activity, we often have some version skew which sometimes causes packages to be removed
[07:19] <crevette> hello
[07:37] <pitti> robert_ancell: I replied to your compiz bug management mail; please feel free to kick the discussion to u-devel@
[07:37] <pitti> I need to leave for about 2 hours, doctor appointment
[07:37] <robert_ancell> pitti: thanks.  One last question - if there is a control.in should the diff.gz contain the control file?
[08:04] <robert_ancell> seb128: morning
[08:04] <seb128> robert_ancell: hello from london
[08:04] <seb128> how was your day?
[08:05] <robert_ancell> seb128: a steep learning curve... I have the glade package ready. I think I've got the avahi package produced but I'm currently upgrading to Karmic so I can build it easily
[08:06] <seb128> ok, so none of those are syncs now?
[08:06] <seb128> I will try to review those today if they are ready for review
[08:06] <robert_ancell> seb128: no
[08:06] <robert_ancell> I'll do gdm tomorrow
[08:07] <seb128> maybe do the totem* srus if you didn't start on those yet?
[08:08] <robert_ancell> sure, I'll do those now
[08:10] <seb128> don't forget to do some bug triage too, we are lagging behind after jaunty again
[08:10] <seb128> triaging new bugs for a package a day could be a good goal
[08:10] <seb128> for reasonable packages
[08:10] <seb128> ie gnome-games
[08:18] <mvo> seb128: hey seb! had a good flight?
[08:19] <seb128> hello mvo, yes very good
[08:19] <seb128> one hour flight, london public transportation running fine during the week
[08:31] <robert_ancell> seb128: when using quilt and autoreconf is there an easy way to quilt add all the files?
[08:33] <seb128> robert_ancell: find . | xargs quilt add
[08:34] <robert_ancell> :) that's what I did.  Feels a bit hacky though...
[08:34] <mpontillo> morning all; I have a noob question... I'm trying to fix that epiphany user-agent bug, and I've been reading the packaging guides and trying to figure out how to do a substitution string for the target platform version at build time... is that a pointless search? i.e. is the package *always* going to be built on a system with the same /etc/lsb-release info as the target platform?
[08:35] <mpontillo> robert_ancell: careful of .swp files your text editor creates, ctags files, or anything else you might have accidentally put in the directory ;)
[08:35] <chrisccoulson> robert_ancell - you also have to be careful of files that get automatically created by running autoreconf whilst you edit the patch
[08:35] <chrisccoulson> i've fallen in to that trap before and you end up with a diff outside of the /debian directory
[08:35]  * chrisccoulson loves quilt
[08:35] <robert_ancell> yuck.  Easiest solution is to manually edit the patch afterwards?
[08:36] <seb128> I tend to change the rules to comment quilt-patchsys and use cdbs-edit-patch
[08:36] <seb128> one good move would be to make cdbs-edit-patch work on quilt packages
[08:36] <seb128> not using quilt, just the same way it's working for simple patchsys
[08:37] <chrisccoulson> sometimes when i run something that i know might create new files, i just create a copy of the source directory i'm working in, run the command in one (ie, autoreconf), then take a diff of the two folders and use that as the patch
[08:37] <robert_ancell> that would be nice.  Is upstream likely to support changing from quilt if we send them a cdbs patch?
[08:37] <chrisccoulson> seb128's method makes sense though
[08:37] <pitti> re
[08:37] <pitti> hey seb128
[08:37] <pitti> so, that was pleasingly quick
[08:37] <seb128> robert_ancell: "upstream" being debian? no, they switched to quilt
[08:37] <seb128> hello pitti, what was quick?
[08:37] <pitti> robert_ancell: yes, debian/rules will create debian/control from control.in on clean
[08:38] <pitti> seb128: doctor appointment
[08:38] <robert_ancell> seb128: oh
[08:38] <seb128> pitti: everything is ok?
[08:38] <pitti> . o O { oh, wow, KMS, UXA, and compiz running flawlessly }
[08:38] <pitti> seb128: just my weeks-old small hand injury from board breaking, nothing serious
[08:39] <robert_ancell> pitti: I tried deleting control and dpkg-buildpackage failed. So I've left it in
[08:39] <seb128> pitti: ok good
[08:39] <pitti> robert_ancell: just change control.in and run debclean
[08:39] <pitti> that should do
[08:39] <robert_ancell> thx
[08:40] <crevette> hey
[08:40] <crevette> good morning
[08:44] <seb128> lut crevette
[08:44] <pitti> seb128: how's the sprint?
[08:46] <seb128> pitti: just starting for me, they are going through the first 2 days discussions and doing a summary now
[08:52] <didrocks> salut *
[08:53] <pitti> hey didrocks
[08:55] <didrocks> Hi pitti! Are you also at the sprint?
[08:58] <seb128> lut didrocks
[09:02] <didrocks> plop seb128 ;)
[09:17] <robert_ancell> I seem to have $GTKDOC_REBASE missing from a build, anyone know what it is?
[09:19] <seb128> robert_ancell: run the gnome autogen.sh, there is not gtk-doc autocommand
[09:19] <seb128> or copy the change from the previous version
[09:20] <seb128> only configure doesn't apply usually you can force the patch run autoconf and refresh
[09:20] <chrisccoulson> hey seb128 - i saw your comments on the gnome-sesion update. i'll work on those later - sorry i've not done it yet, i've not had a chance yet.
[09:20] <robert_ancell> so  I should ammend the autoreconf patch by running autoconf?
[09:21] <seb128> chrisccoulson: no hurry, I'm at a dxteam sprint for 2 days anyway so I will not have lot of review time
[09:21] <seb128> robert_ancell: if only configure conflicts yes
[09:21] <chrisccoulson> seb128 - that's ok then. it should be done by the time you get back:)
[09:22] <seb128> good ;-)
[09:24] <crevette> hello, for those interested I did a upload request for gnome-bluetooth 2.27.x which it aims to replace bluez-gnome (https://bugs.edge.launchpad.net/bugs/372395)
[09:25] <crevette> if the people who will upload can do some more testing, I'm a little afraid that break something
[09:25] <crevette> hey rodrigo_
[09:26] <rodrigo_> hi
[09:26] <mpontillo> how do I know what's ok vs. not-ok to put in the postinst script? is there a guideline somewhere?
[09:26] <seb128> hello rodrigo_
[09:27] <seb128> mpontillo: the less you put there the better for system upgrade stability
[09:36] <pitti> does "time-admin" work for you guys? when I start it, I get a dialog "your system is unknown, please select your distro"
[09:37] <chrisccoulson> pitti - there's already a related bug report for services-admin i think
[09:37] <chrisccoulson> doesn't this break at the start of every cycle?
[09:37] <pitti> ah, that might be, I'll look into it
[09:38] <chrisccoulson> i'm not sure whether thats a g-s-t, liboobs or s-t-b issue though
[09:38] <chrisccoulson> pitti - bug 371234
[09:38] <pitti> chrisccoulson: thanks
[09:39] <maxb> The selection box lists nothing newer than hardy.... does that mean it's broken in intrepid and jaunty too?
[09:40] <pitti> I don't think so, worked fine there
[09:42] <chrisccoulson> pitti - i started working on a MIR for vala last night. is it a show-stopper that it has no gettext support (bearing in mind that it's primary purpose is converting vala source in to C source+headers, so it's a tool that only developers will use)
[09:42] <pitti> chrisccoulson: I don't think so
[09:42] <pitti> this is a build chain tool
[09:43] <chrisccoulson> pitti - thanks. i'll carry on working on that later then
[09:48] <seb128> pitti: bonus if you do the debian merge, they have a patch to drop the list of known distro thing
[09:48] <pitti> yay, will do that
[09:48] <seb128> thanks
[09:48] <seb128> I'm amazed that so many people are running karmic yet
[09:49] <seb128> several users confirmed this bug
[09:49] <pitti> why?
[09:50] <seb128> because it just opened and still around breakage time
[09:51] <crevette> we want to support ubuntu
[09:51] <seb128> we usually don't get bugs such details so early
[09:51] <pitti> dogfooding FTW :)
[09:51] <mdz> tkamppeter: have you seen bug 39078?  are you aware of any time when there may have been recursive symlinks in /usr/share/ppd?
[09:51] <seb128> usually first month is focussed on making things build and install
[09:51] <crevette> usually is there more breakage in the beginning of the cycle
[09:51] <crevette> from what I recall
[09:52] <seb128> right which is why you don't upgrade so early
[09:52] <seb128> especially that so early bugs on user applications are not really useful
[09:52] <seb128> because that adds paper work for things which will autosettle with merges, etc
[09:53] <robert_ancell> see you guys tomorrow
[09:53] <chrisccoulson> yeah - the other thing that always breaks at the start of every cycke is software-sources, and that was reported straight away and confirmed by lots of people too
[09:53] <seb128> robert_ancell: see you
[10:09] <pitti> seb128: ah, good merge; our remaining changes are patches which are sent upstream, no packaging changes any more
[10:10] <pitti> nice to see Debian pick up PolicyKit
[10:11] <seb128> pitti: good
[10:17] <pitti> seb128: it also finally removes the init script
[10:18] <james_w> pitti: you are reviewing iulian's merge?
[10:18] <pitti> james_w: erm, no? I just did it myself
[10:18] <james_w> oh
[10:19] <james_w> bug 372599 from around an hour ago :-)
[10:19] <pitti> I see no bug on https://bugs.edge.launchpad.net/ubuntu/karmic/+source/system-tools-backends/+bugs
[10:19] <pitti> james_w: oh, polkit, *phew*
[10:19] <james_w> ah, sorry
[10:19] <james_w> you meant they've enabled policykit in s-t-b?
[10:19] <pitti> yes, in Debian
[10:19] <james_w> cool
[10:19] <pitti> so we could drop our delta for that
[10:20] <james_w> sorry for the noise
[10:20] <pitti> james_w: no worries, thanks for bringing it up
[10:23] <tkamppeter> mdz, bug 39078 is a severe upstream bug in CUPS. A tool which searches a directory structure recursively should be aware of link loops.
[10:23] <tkamppeter> mdz, I am currently seartching whether it already got reported to CUPS.
[10:24] <mdz> tkamppeter: I agree, though multiple people have experienced this issue without knowingly creating recursive symlinks, so there's likely a bug somewhere which creates them
[10:38] <tkamppeter> mdz, as there are many sources for PPD files, especially also driver packages from printer manufacturers, CUPS should handle these link loops gracefully. I will report a bug to CUPS.
[10:40] <mdz> tkamppeter: I agree with you, CUPS should handle the loop more gracefully, and reporting the bug to CUPS is a good idea.  However, I also feel that a symlink loop created by an Ubuntu package is a bug in itself.
[10:52] <mnemo> pitti: i would like apport's xorg hook to collect xorg.log, xorg.log.old, lspci -vvnn and dmesg for packages rss-glx and gdm... should I open a wishlist bug against apport for that?
[10:53] <pitti> mnemo: rather against rss-glx and gdm
[10:53] <pitti> package hooks should be shipped in the packages themselves
[10:53] <mnemo> ok
[10:54] <pitti> mnemo: are many gdm bugs really so x.org related?
[10:54] <mnemo> not that many, but it happens
[10:54] <mnemo> should we more conservative with collecting files you think?
[10:55] <mnemo> pitti: is there a good "sample hook" that ships in an app package (in case I want to try adding it myself)?
[10:56] <bryce> I filed a bug against gdm to add an xorg-like apport hook last week
[10:56] <mnemo> ah ok great
[11:03] <pitti> mnemo: just look at the existing ones in /usr/share/apport/package-hooks/
[11:04] <crevette> asac, around?
[11:05] <mnemo> thanks
[11:05] <asac> crevette: yeah. what can i do for/to you ;)?
[11:05] <seb128> crevette: better to just ask your question so he can reply
[11:05] <crevette> asac, hey
[11:06] <crevette> asac, just a question, not sure this is the NM fault, but I shoot, do you know if there is a change in linux kernel 2.6.30 that make me impossible to connecto to my WPA connection with NM ?
[11:06] <crevette> if I switch back the 2.26.28 kernel shipped with jaunty no problem, as expected
[11:07] <asac> crevette: which driver/chipset?
[11:07] <crevette> I have a lenovo laptop with intel chip if it matters
[11:08] <pitti> for the record, WPA/2.6.30rc3 (karmic) works just fine on my 3945
[11:08]  * crevette whould have write its laptop properties somewhere
[11:09] <hyperair> you refer to yourself as it?
[11:10] <asac> crevette: sounds a bit oddd, but i dont want to rule that out
[11:10] <asac> crevette: can you check if you can narrow down when this happened by going through the milestones from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[11:10] <crevette> asac, I didn't tested / troubleshoot intensively, I just test 2.6.30 this morning just before leaving to go to the job
[11:11] <asac> ok. if it persists, check out the mainline vanilla packages
[11:11] <asac> having regression window there would be good i guess
[11:11] <asac> there is rc4 already ffiw
[11:15] <mpt> mvo, hi, njpatel showed me yesterday the bug with update-manager popping up whenever you use apt-get
[11:21] <pitti> seb128: does the new libsoup in karmic fix bug 340785 and bug 313686?
[11:22] <seb128> pitti: yes
[11:23] <pitti> seb128: likewise, bug 362307 and bug 326771?
[11:24] <seb128> pitti: yes
[11:24] <seb128> pitti: dunno about scim but nautilus bugs yes
[11:24] <pitti> seb128: thanks, closed those four
[11:25] <seb128> thanks
[11:25] <seb128> pitti: I don't know about the scim one as said though
[11:25] <seb128> I assume you used the wrong number but meant the other nautilus bug fixed in sru
[11:26] <pitti> seb128: naturally, I meant but 362771, sorry
[11:26] <pitti> tpying is hrad
[11:26] <seb128> don't tell me ;-)
[11:38] <seb128> hum, how do I tell dd to write 6Gb of datas?
[11:42] <crevette> seb128, for kvm ?
[11:42] <crevette> if yes, you can use qemu-disk utilities IIRC
[11:43] <crevette> else you can do a dd if=/dev/zero of=/virtualfs bs=1024 count=<nb in KB>
[11:44] <seb128> crevette: ok thanks, I tried that without the bs option
[11:44] <crevette> seb128, else qemu-img is your friend :)
[12:16] <asac> hmm irc.gnome.org seems busted for me ... i cannot connect anymore ;)
[12:17] <chrisccoulson> asac - i' m connected
[12:21] <asac> yeah. better dont disconnect ;)
[12:31] <mvo> mpt: right, I have a fix in karmic, we can SRU it for jaunty too
[12:31] <mpt> mvo, I think it would be a good idea :-)
[12:32] <mpt> mvo, 1 day for security updates, and the usual delay (e.g. 7 days by default) for non-security, I think
[12:37] <mvo> mpt: ok
[12:38] <mpt> mvo, btw, sorry, I wasn't here on Monday, I forgot it was a public holiday here
[12:38] <mvo> mpt: no problem, its pretty busy here too, I'm doing a one-to-one sprint currently, but we can have the phone call anytime this week you have time
[12:40] <mpt> mvo, I'm in user testing all today, but I can call you tomorrow if that's ok
[12:52] <mvo> sure
[13:10] <asac> i remember that there was a pidgin upstream at last UDS ... he had some experience on online/offline status things; anyone remembers who that was?
[13:23] <Ampelbein> seb128: hi. bug 372168 is ready for review, I think.
[13:41] <seb128> Ampelbein: ok thanks, I'm at a sprint for 2 days so I will probably not review those today or tomorrow
[13:51] <mvo> seb128: hey - do you have some (gnome) packages that I can update with muharem (that are no merges) ?
[13:55] <seb128> mvo: yes
[13:55] <seb128> mvo: easy one?
[13:56] <seb128> mvo: http://download.gnome.org/sources/gnome-themes/2.27/gnome-themes-2.27.1.tar.gz
[13:59] <pitti> mvo, seb128: ^ please noe that this is in bzr
[13:59] <pitti> with bzr-buildpackage
[14:02] <mvo> seb128: excellent, thanks
[14:02] <seb128> mvo: thank to you ;-)
[14:13] <rickspencer3> hi seb128, how is the sprint?
[14:13] <pitti> rickspencer3: good morning
[14:13] <seb128> hey rickspencer3, pretty interesting so far
[14:14] <seb128> some crack ideas though ;-)
[14:14] <rickspencer3> hi pitti
[14:14] <rickspencer3> seb128: :)
[14:14] <seb128> ie people have been suggesting to replace gnome-panel by xfce-panel to win some login seconds
[14:14] <rickspencer3> of course, why not
[14:14] <rickspencer3> ?
[14:14] <pitti> the time to sort out the configuration migration will be better spent fixing gnome-panel
[14:14] <rickspencer3> spend hundreds of development hours replacing something that's going to be replaced by GNOE 3.0 anyway

[14:15] <seb128> hehe
[14:15] <rickspencer3> I suppose the message for us is that log in time is important to them, and we should help with that goal
[14:15] <seb128> right
[14:16] <pitti> rickspencer3: gnome-panel won't go away anytime soon
[14:16] <pitti> we still need it for the cases where we don't have composite
[14:16] <rickspencer3> pitti: well ... the things that make it slow will, right?
[14:16] <pitti> rickspencer3: right, gconf and bonobo
[14:16] <rickspencer3> I thought in GNOME 3.0 they were removing some of the libraries and such that made it start up slow
[14:16] <seb128> the recommendation is to spend some time to investigate what work would be required to improve that
[14:17] <seb128> according to Scott the issue is mainly that gnome-panel is doing a lot of synchronous loading
[14:17] <seb128> ie blocking waiting for applets to load and register
[14:17] <vuntz> this is 100% fixable
[14:17] <rickspencer3> hi vuntz!
[14:17] <seb128> yes, we just need to "budget" ressources for that
[14:17] <vuntz> ah, the whole "waiting for applets before showing" issue
[14:17] <vuntz> a fun one
[14:18] <vuntz> some people would like the panel to show asap and then have some uglyness with applets appearing
[14:18] <pitti> vuntz: that's the case already
[14:18] <vuntz> some other people prefer the panel to show when it's really ready
[14:18] <pitti> right now it seems to be a wild mix in the middle
[14:18] <seb128> vuntz: what would be your recommendation to improve start time in gnome-panel
[14:18] <vuntz> pitti: nope, in 2.26, you should have the second case
[14:18]  * rickspencer3 gets ready to create another blueprint
[14:18] <pitti> vuntz: gpm and n-m appear after the panel appears, for me
[14:19] <vuntz> pitti: they are not applets :-)
[14:19] <pitti> vuntz: <user hat>what's the difference?</user hat>
[14:19] <pitti> it's a little thingy in my panel
[14:19] <vuntz> pitti: well, they are localized in one small place
[14:19] <Keybuk> I stress that I've only done cursory examination of the panel
[14:19] <mnemo> the biggest problem with gnome-panel is that is re-arranges all my launchers in random order every few months... sometimes when I use another resolution and sometimes on package upgrades..
[14:19] <vuntz> pitti: it's not like your whole panel is flashing multiple times during login
[14:19] <Keybuk> other than identifying it as a culprit of slow login time
[14:19] <pitti> vuntz: right; I wasn't complaining, just stating how it looks
[14:20] <vuntz> pitti: oh, sure, and that's a fair point. But I still think it's better now
[14:20] <vuntz> (also, the slide-in animation is now smooth instead of being completely broken)
[14:20] <pitti> (or entirely gone :) )
[14:20] <rickspencer3> hi Keybuk
[14:21] <seb128> vuntz: what would be your recommendation to improve start time in gnome-panel?
[14:21] <vuntz> seb128: recommendation would be to see what's slow, of course ;-)
[14:21] <seb128> right, I'm just asking if you know what is slow
[14:21] <seb128> since you probably know the code better than any of us there
[14:21] <seb128> ie where we should start looking
[14:21] <seb128> if you don't that's fine
[14:21] <seb128> still worth asking ;-)
[14:22] <vuntz> well, it'd be interesting to see if a panel with absolutely no applet is still slow, I guess
[14:22] <vuntz> that would be a first interesting data point
[14:22] <seb128> good point
[14:22] <vuntz> then panel with only in-process applets
[14:22] <vuntz> also impact of the applications menu
[14:22] <vuntz> etc.
[14:23] <seb128> I'll try to do some playing with that
[14:23] <kenvandine_wk> seb128: talk to behdad too
[14:23] <kenvandine_wk> he has spent lots of time profiling the panel
[14:24] <seb128> kenvandine_wk: I don't think he looked at gnome-panel yet, he's looking a gconf apparently
[14:24] <seb128> oh, is that new?
[14:24] <seb128> federico did that some years ago
[14:24] <vuntz> fwiw, I have some small gconf-related panel patches around. And also a gnome-menus performance patch that I need to look at
[14:24] <vuntz> but I doubt they make a real difference
[14:24] <kenvandine_wk> seb128: he did look at the panel
[14:25] <seb128> kenvandine_wk: where did you read about that?
[14:25] <kenvandine_wk> he had some patches that improved panel load time
[14:25] <seb128> when?
[14:25] <kenvandine_wk> i tested the patches for him
[14:25] <vuntz> kenvandine_wk: that was committed quite some time ago
[14:25] <kenvandine_wk> 6 months ago?
[14:25] <kenvandine_wk> yeah
[14:25] <kenvandine_wk> i know
[14:25] <kenvandine_wk> but he looked at it allot
[14:25] <seb128> ok, nothing new, I was just checking
[14:25] <kenvandine_wk> might have ideas where else to look at
[14:25] <seb128> ok
[14:26] <pitti> it's also worth trying in C locale, so that it doesn't read any mo files for translating the menu entries
[14:27] <kenvandine_wk> that would be an interesting comparison
[14:28] <seb128> Keybuk: how do I turn off disk cache?
[14:28] <Keybuk> seb128: flush it?
[14:28] <Keybuk> or turn it off entirely?
[14:29] <seb128> do whatever will give timing similar to cold cache start, ie first run
[14:29] <Keybuk> echo 1 > /proc/sys/vm/drop_caches
[14:29] <seb128> thanks
[14:29] <soren> Keybuk: Not 3?
[14:30] <Keybuk> soren: why 3?
[14:30] <soren> To free pagecache: echo 1 > /proc/sys/vm/drop_caches
[14:30] <soren> To free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches
[14:30] <soren> To free pagecache, dentries and inodes: echo 3 > /proc/sys/vm/drop_caches
[14:30] <Keybuk> ah, yes, 3
[14:50] <seb128> hum, upgrade to karmic is breaking
[14:51] <seb128> working after a retry though
[14:53] <seb128> the libc6 preinst returned an error 1
[14:54] <kenvandine_wk> seb128: humm... i had no errors... but it erased f-spot :)
[14:54]  * kenvandine_wk added it back of course :)
[14:57] <seb128> I'm upgrading a kvm image so I don't really care a lot about it breaking
[14:58] <seb128> I'm not crazy enough to run karmic on my laptop yet :-)
[14:58] <Laney> are there any pending f-spot patches on bugs?
[14:58] <Laney> I'm going to re-sync it to debian
[14:58] <kenvandine_wk> i updated my desktop, laptop is jaunty
[14:59] <seb128> Laney: not that I know about
[14:59] <Laney> ok
[15:00] <seb128> maybe one day it will be in sync
[15:00] <Laney> it's not that far away
[15:00] <seb128> would be nice if upstream was responsive though
[15:01] <Laney> seems like it could do with a new release
[15:01] <seb128> indeed
[15:01] <kenvandine_wk> i don't know how active upstream is right now :/
[15:01] <seb128> they are not responsive to bugs reports for sure
[15:01] <seb128> and don't roll new tarballs
[15:02] <Laney> it still gets commits
[15:02] <seb128> but they seem to do changes, add feature and have a soc project running
[15:05] <mvo> seb128: u-m upgrade is breaking? on what?
[15:05] <seb128> mvo: no, jaunty to karmic upgrade breaking
[15:05] <seb128> mvo:  the libc6 preinst returned an error 1
[15:05] <mvo> seb128: heh :)
[15:06] <seb128> but it worked after a retry
[15:06] <mvo> seb128: ok - did you use u-m to upgrade (just out of curiosity)?
[15:06] <seb128> I first used the dist-upgrader
[15:06] <seb128> but it just closed itself, I though that was because it was done
[15:06] <seb128> then I tried update-manager and got this error
[15:07] <seb128> mvo: davidbarth is wondering if you could do a conf call now
[15:07] <seb128> ie joining the discussion about boot experiment, plymonth etc
[15:07] <davidbarth> mvo: hi, we're sprinting currently in London
[15:07] <davidbarth> mvo: we're going to talk about the boot/login transition with plymouth
[15:08] <mvo> davidbarth: sure, when does the conf call start?
[15:08] <davidbarth> mvo: what we can do is call you; or start the discussion and get in touch with you if we have questions
[15:08] <davidbarth> mvo: i know that it's not always obvious to mix calls and meetings
[15:08] <mvo> davidbarth: calling me sounds good, give me one minute
[15:09] <davidbarth> mvo: but don't want to put you out of the loop
[15:09] <davidbarth> mvo: great, let me know
[15:11] <mvo> davidbarth: ready
[16:10] <asac> mvo: how does dpkg unpack files
[16:10] <asac> does it create .new files and then rename?
[16:11] <mvo> asac: yeah, I need to look into the exact names, but basicly thats it
[16:11] <asac> pitti: can you give back xulrunner-1.9.1 and firefox-3.5 builds? (most failed a few days ago because of libcairo-dev depend not being in main)
[16:11] <pitti> rickspencer3: blueprint priorities updated
[16:11] <asac> mvo: so all files get unpacked with .new first?
[16:11] <asac> are config files special?
[16:12] <pitti> asac: you can do that yourself, but I'll do the favour :)
[16:12] <asac> pitti: well. it will get build score 0
[16:12] <asac> ;)
[16:12] <asac> if i do it
[16:12] <mvo> asac: yes, but I can look up the details after the call I'm in
[16:12] <asac> mvo: ok thanks
[16:12] <pitti> asac: nothing to do for firefox-3.5, it's depwait on sparc and built everywhere else
[16:12] <pitti> asac: oops, sorry, that was jaunty
[16:12] <asac> err
[16:12]  * pitti updates buildd script
[16:12] <asac> yeah
[16:12] <asac> ;)
[16:13] <rickspencer3> pitti: thanks
[16:13] <asac> pitti: i retried manually ffox-3.5 some gave me "cannot be retried"
[16:13] <pitti> asac: right, it's needsbuild
[16:13] <pitti> it didn't fail anywhere
[16:13] <asac> pitti: can you adjust buildscore then
[16:13] <asac> (its a retry)
[16:14] <pitti> asac: done
[16:14] <asac> xulrunner-1.9.1 is more important actually
[16:14] <asac> thx
[16:15] <mvo> asac: why do you need this?
[16:16] <calc> pitti: to get libboost1.37-dev into main do i need to write a MIR or just file a bug?
[16:17] <calc> libboost1.35-dev seems to have issue with gcc 4.4
[16:17] <pitti> calc: just a bug
[16:17] <asac> mvo: dbus issues
[16:17] <calc> ok
[16:17] <pitti> calc: the main issue is to do the transition for all rdepends, since we want to use 1.37 across the board then
[16:17] <asac> mvo: nevermind i ran a strace and i think i saw
[16:17] <asac> .dpkg-new ... ->
[16:17] <asac> rename
[16:18] <rickspencer3> asac: seb128: calc: bryce: ArneGoetje, Riddell, kenvandine_wk if you haven't registered UDS attendance could you do so please?
[16:18] <calc> pitti: well 1.38 is out as well but its not built yet from what i recall
[16:18] <asac> already done
[16:18] <seb128> rickspencer3: I didn't?
[16:18] <seb128> oh "if"
[16:18] <seb128> ok ;-)
[16:18] <rickspencer3> seb128:  asac, sorry, I meant *if* :)
[16:18] <calc> hmm and 1.38 FTBFS it seems atm
[16:18] <seb128> I did this after receiving pitti's email
[16:19] <asac> AOL
[16:25] <calc> pitti: bug 372756
[16:29] <asac> mvo: when you have finished your call, please look at http://paste.ubuntu.com/165526/
[16:30] <asac> what are those .dpkg-new things for the directories for?
[16:30] <mpontillo> asac: regarding bug 332253, I took a stab at it and basically did what you said in the bug comments using a postinst script... but I had lingering doubts about using postinst, and seb128 seconded my unspoken paranoia. ;) is /etc/lsb-release always going to be accurate at build time? if not, what should be the strategy? for maintainability, I don't want to hard code it
[16:30] <asac> mpontillo: lsb-release should be accurate
[16:31] <asac> mpontillo: you need to build depend on lsb-base or something though
[16:31] <asac> let me look at bug ;)
[16:31] <asac> mpontillo: did i suggest to use postinst?
[16:31] <asac> i always ment to use lsb_release during build time ;)
[16:32] <asac> mpontillo: why do you sed the default-prefs.js?
[16:33] <asac> you should just cat the stuff together during build imo
[16:33] <mpontillo> asac: ok. great. then I can basically take that postinst script and put it right into the build process, and make lsb-release (the package that provdes /usr/bin/lsb_release) a build dep. no, you didn't mention when to do the substitution. I only thought postinst might be the way to do it because I wasn't sure there was ever the ability to build a package from the non-target architecture
[16:33] <asac> (unless upstream ships its own stuff in that file)
[16:33] <asac> mpontillo: yeah. maybe i omitted that i ment during build
[16:33] <asac> guess thought it was clear
[16:35] <asac> pitti: is our CK behaviour of making root @console something done by CK upstream? or is that something we did?
[16:35] <mpontillo> asac: it would have been clear if I knew the .deb build process better. I have been trying to come up to speed, but there is a lot of information to absorb
[16:35] <pitti> asac: it started as a d-bus patch of our's, I'm not sure whether they applied it; let me check
[16:35] <asac> pitti: walters asks if we would agree on only making root  @console for gdm sessions and ssh
[16:35] <seb128> mpontillo: if you have questions feel free to ask on the channel
[16:36] <kenvandine_wk> seb128: i did
[16:36] <pitti> asac: seems to be upstream
[16:36] <kenvandine_wk> whoops
[16:36] <kenvandine_wk> rickspencer3: i did :)
[16:36] <asac> pitti: ok. so can i tell walters that we follow upstream decision on whether we make root @console for sudo su?
[16:37] <pitti> asac: if d-bus upstream want to change this, sure
[16:37] <pitti> few programs use at_console testing in their d-bus policy files in the first place
[16:37] <asac> pitti: isnt that a consolekit thing?
[16:37] <pitti> and frankly, I think the work would be better spent on dropping it at all
[16:38] <asac> e.g. creating the /var/run/console/root file if you do sudo su?
[16:38] <pitti> asac: ah, right
[16:38] <asac> pitti: yeah. i am working on convincing NM to use polkit everywhere
[16:38] <mpontillo> asac: the reason I used sed is because that I didn't want to have to modify the upstream default config file. is there a technical reason to use cat instead? seemed a bit more complex to be piecing apart upsteam files, but if that's the accepted practice...?
[16:39] <pitti> asac: right, it's done in /usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck
[16:39] <pitti> asac: I thought d-bus shipped it, but it's shipped in CK
[16:40] <asac> pitti: so is that upstream or ubuntu behaviour?
[16:40] <pitti> that's an ubuntu change
[16:40] <pitti> there is no upstream implementation of "at_console" in d-bus
[16:40] <pitti> so anything that relies on it wouldn't work at all without that CK hook
[16:41] <asac> pitti: i am still referring to the consolekit part ;)
[16:41] <pitti> asac: right, but it's only there because of d-bus' at_console test
[16:41] <pitti> if that would go away, we'd immediately drop /usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck
[16:41] <asac> besides from dbus dont using at_console it seems that distros disagree of when consolekit says that a user is @console
[16:42] <pitti> asac: for CK itself we don't deviate from upstream in that regard
[16:42] <pitti> you'll get a session for each su login
[16:42] <pitti> and that's a correct behaviour IMHO
[16:42] <pitti> (otherwise stuff would break)
[16:42] <asac> pitti: ok thanks
[16:42] <pitti> asac: I thought you'd only be worried about the d-bus policy "at_console" tests, not about CK itself?
[16:43] <pitti> asac: so the problem is not actually in the d-bus policies, but in programs which ask CK directly?
[16:44] <asac> pitti: no ... the problem is dbus, but since it takes that console info from consolekit we wondered on whether that particular behaviour (sudo su -> root @console) is ubuntu specific
[16:44] <seb128> mvo: is there a way to use graphical tools to upgrade from jaunty to karmic?
[16:45] <pitti> asac: no, "su anything" will always get a CK session, that's not ubuntu specific
[16:45] <mpontillo> and seb128, thanks, that's why I'm here (to ask questions), but everyone is usually talking about more important things, so I don't like to butt in with noob questions unless they're well researched first ;)
[16:45] <walters> asac: the CK behavior is standardized, *but* whether root gets @console is OS specific right now
[16:46] <pitti> walters: how so?
[16:46] <walters> pitti: it comes down to the PAM stack no?
[16:46] <pitti> why should root not get a CK session, but every other user should?
[16:47] <pitti> walters: I don't think that CK itself uses PAM
[16:47] <pitti> walters: we just add libpam-consolekit to get CK sessions for VT and ssh logins
[16:48] <pitti> walters: how do you configure it in Fedora?
[16:48] <walters> pitti: well i don't have a strong opinion personally on whether 'su' should create CK sessions, I'm just saying that currently in Fedora the console PAM goo explicitly skips root and Ubuntu/SuSE do not
[16:48] <walters> i'd be open to trying to bring fedora in line here but i
[16:48] <pitti> walters: ah, so it's not at all root specific
[16:48] <pitti> that makes more sense
[16:48] <walters> right
[16:48] <walters> but it'd take some digging as to rationale
[16:49] <pitti> ok, then I misunderstood it
[16:49] <pitti> walters: libpam-ck is pretty nice, so that local VT logins etc. get device ACLs and so on
[16:50] <mvo> seb128: yes, update-manager -d works since yesterday
[16:50] <seb128> mvo: where did I need to get this update-manager? jaunty-updates?
[16:50] <walters> pitti: right i think the behavior is important for GDM, VT, and ssh
[16:51] <walters> pitti: su/sudo just get really weird and horrible
[16:51] <mvo> seb128: the stock update-manager should do - is that not working for you?
[16:52] <seb128> mvo: dunno, I was checking with you before doing a mistake, I've running ubuntu and debian installs in kvm and my laptop disk is being slooow
[16:52] <mvo> :)
[16:52] <mvo> seb128: it should work just fine (I hope) - modulo the errors that are unavoidable at this stage from the package churn
[16:53] <mvo> asac: thanks for the strace log, is there more context?
[16:53] <mvo> asac: e.g.  a bugnumber?
[16:55] <asac> mvo: no ;)
[16:55] <asac> mvo: its not even a bug
[16:55] <asac> mvo: i just showed you wondering about why dpkg does that .dpkg-new business you see in the trace
[16:55] <asac> (in particular for directories)
[16:55] <rickspencer3> bryce: ping
[16:58] <bryce> rickspencer3: yep?
[16:59] <rickspencer3> bryce: would you prefer that I spread the xorg sessions over all days at UDS, or bunch them up over a day or two?
[17:00] <bryce> rickspencer3: bunched up, with two exceptions
[17:00] <bryce> desktop-karmic-xorg-intel-upstreaming-working-session I'd like to be on its own day
[17:01] <bryce> and desktop-karmic-xorg-intel-improve-upstreaming-process should be a day following the workshop
[17:02] <rickspencer3> k
[17:02] <rickspencer3> I'll put those in the small room, figuring it will be easier to focus on doing work in that room
[17:03] <rickspencer3> bryce: so I think Tuesday will kind of be "x day" in the main room, and then Wed/Thur for the other two
[17:04] <bryce> rickspencer3: perfect
[17:06] <pitti> rickspencer3: the "proposed" spec confuse me
[17:06] <rickspencer3> which one?
[17:06] <pitti> they are actually just "proposed" for uds-karmic, but nevertheless appear on the list already
[17:06] <rickspencer3> because I am experiencing a lot of confusion right now
[17:06] <rickspencer3> are they ones that I created?
[17:07] <mvo> asac: its doing it for various reasons, one is to avoid the infamous text-file-busy error if you try to e.g. overwrite a library that is currently mapped, one is to have a rollback mechanism if the package is corrupted half-way through
[17:10] <asac> mvo: yeah. but i dont see that it actually uses those .dpkg-new instances of the system.d directory.
[17:10] <asac> mvo: my question isnt about files, but about the directories
[17:12]  * mvo loooks again, harder
[17:13] <pitti> rickspencer3: I went through the proposed list now and ack'ed 19
[17:13]  * pitti -> dinner
[17:13] <rickspencer3> thanks pitti!
[17:13] <rickspencer3> I'll try to get them scheduled asap
[17:13] <crevette_> pitti, diner is so earlier in germany ?
[17:13]  * crevette_ has not left the job yet
[17:21] <mvo> asac: IIRC - I read the dpkg source about this some time ago - its about dealing with directories that might get replaced with files or vice versa
[17:21] <mvo> asac: but the fact that its doing this dance with rmdir() is a bit myserious, might be just because its no harm doing it
[17:21] <asac> mvo: ah ok.
[17:22] <asac> mvo: thanks. i think thats enough
[17:22] <asac> otherwise we might find a bug and the fix would probably cause lots of regression headaches ;)
[17:22] <asac> so better not look closer
[17:30] <Keybuk> asac: what's the question?
[17:30] <Keybuk> .dpkg-new?
[17:30] <Keybuk> because if you just overwrite an open file, strange things happen
[17:31] <Keybuk> (or errors, if you're lucky)
[17:33] <walters> Keybuk: the not-immediately-obvious part i think was why it was doing an rmdir of foo.dpkg-new files, not why it was doing foo.dpkg-new + rename(foo)
[17:36] <asac> Keybuk: yeah. the question was about "directories"
[17:45] <pitti> crevette_: I usually have dinner at 6 pm when I have Taekwondo in the evening, so that I don't do sport with my belly filled :)
[17:45] <crevette_> ah
[17:46] <seb128> I get dinner after sport ;-)
[17:46] <pitti> seb128: me too :)
[17:46]  * crevette_ doesn't do sport
[17:46] <pitti> dinner I at 18:00, dinner II at 23:00
[17:46] <seb128> pitti: double dinner? ;-)
[17:46] <seb128> get calories, spend those, get new ones
[18:44] <pitti> good night everyone
[18:44] <crevette> bye pitti
[18:49] <awe> night pitti!
[18:51] <rickspencer3> awe: I feel that I may have missed a blueprint for you for Karmic
[18:52] <awe> rickspencer3: i think the plan it for asac and i to create a combined networking-karmic blueprint...
[18:53] <rickspencer3> awe: do you know if it's been submitted?
[18:53] <awe> rickspencer3: no, but i'll check
[18:53] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-network-ui ?
[18:54] <rickspencer3> thanks awe
[18:54] <rickspencer3> we'll get it worked out :)
[18:54] <awe> that's a small subset
[18:54] <rickspencer3> awe: ok
[18:55] <awe> rickspencer3: asac sent me this earlier:  https://wiki.ubuntu.com/DesktopTeam/KarmicNetworking
[18:55] <rickspencer3> awe: right
[18:55] <awe> i'm going to try and add to it, and we've scheduled time to discuss 1st thing tomorrow
[18:55] <rickspencer3> we'll synch with pitti tomorrow
[18:55] <awe> cool
[18:55] <rickspencer3> it's possible that he thinks a UDS session is not required
[18:56] <rickspencer3> thanks
[18:56] <awe> ok, i think we should have one... there's a lot of room for improvement.  ;)
[18:56] <rickspencer3> there are a lot of open slots, so "no stress"
[18:57] <awe> sounds good to me
[19:25] <dobey> mvo, pitti: btw, new apturl solves my issue. thanks!
[19:29] <dobey> hrmm
[19:29] <dobey> what /are/ the criterion for SRU?
[19:38] <mnemo> dobey: https://wiki.ubuntu.com/StableReleaseUpdates#When
[19:39] <dobey> mnemo: thanks
[19:40] <dobey> hmm
[20:15] <mvo> dobey: excellent, thanks
[20:15] <dobey> mvo: thanks for fixing it :)
[20:19] <mpontillo> asac: updated bug 332253 with a new patch - is that more like what you expected?
[21:07] <asac> mpontillo: thats probably ok. sedding is a bit ugly though imo. another idea would be to remove those lines in a patch and just append the new lines using echo 'pref(....)' >> path/to/defaults-pref.js in rules
[21:07] <asac> mpontillo: also helper scripts shouldnt be shipped in top level dir ... at least put it into debian/
[21:12] <mpontillo> asac: thanks for the feedback. I liked the sed solution better since the patch won't break on the off chance that those lines are moved around in the prefs file and lose their context. then again, if someone radically changes the prefs file upstream, the patch will break and we'd know immediately with your idea. I can change the helper script to 'echo' instead.
[21:15] <asac> mpontillo: sed expressions are not really stable
[21:15] <asac> mpontillo: the problem with those is that you won't notice if they fail
[21:16] <asac> e.g. you might end up getting bad syntax in that js file and you wont automatically notice
[21:17] <asac> while patching out calls for attention more reliably. e.g. when the file changes in a way that the patch doesnt apply you probably want to take a look anyway
[21:17] <mpontillo> asac: right, that's what I meant by my "radical upstream changes" comment. it'd be pretty tough for those specific statements to fail, but if for example they changed the names of those prefs, it would. having a patch remove the lines explicitly would catch it.
[21:17] <asac> mpontillo: yes. thats what i suggested
[21:17] <asac> patch to remove those lines
[21:18] <asac> and append them in rules using lsb_release
[21:18] <asac> this will also prevent adding a helper script ;)
[21:18] <hallyn> is there a known issue with gnome-terminal not updating with the nvidia drivers?  by known, I mean, well-understood?
[21:18] <mpontillo> asac: right, and I will make that change. is it safe to do ". /etc/lsb-release" in the rules file? that's why I still thought it'd be nice to encapsulate that functionality in a helper script
[21:19] <asac> mpontillo: why not just do ... echo 'pref("....", "`lsb_release -r`)' >> .../defaults-prefs.js
[21:19] <asac> with a ; ;)
[21:19] <calc> asac: can you process 372756 ?
[21:20] <asac> bug 372756
[21:20] <calc> asac: pitti earlier today said it didn't need a MIR report
[21:20] <asac> i dont have powers to promote ... just to sign off ;)
[21:20] <calc> oh ok
[21:20] <asac> you need to be ubuntu-archive or something to do the actual promotion
[21:21] <calc> oh so just pitti, kees, doko?
[21:22] <mpontillo> asac: lsb_release just gets the info from /etc/lsb-release, which already has the info in a format the shell can understand. if I run lsb_release directly, I have to do some funky echo and cut operations to get the info I need by itself
[21:22] <mpontillo> asac: in other words, it seems cleaner to just do ". /etc/lsb-release" - and if it's safe to do that in 'rules', fine, but if not I'd prefer a helper script
[21:23] <asac> mpontillo: you can do lsb_release -s -r  ... so you dont need "cut"
[21:23] <mpontillo> asac: ah, thanks. missed that argument
[21:24] <mpontillo> will do that then.
[21:36] <asac> calc: kees doesnt have that power either afaik
[21:36] <asac> calc: all archive admins can do that afaik
[21:37] <asac> mpontillo: when you have the patch let me know. i can do the upload if you want
[21:37] <mpontillo> asac: have a patch now, about to rebuild and test. will let you know in a few mins
[21:38] <asac> yeah, no hurry
[21:38] <calc> oh i see
[21:59] <mpontillo> asac: updated bug 332253
[22:00] <pace_t_zulu> asac: you here?
[22:08] <pace_t_zulu> i guess i missed asac... been trying to contact him
[22:10] <mpontillo> I'm sure he'll be back...
[22:11] <asac> pace_t_zulu: about what?
[22:11] <pace_t_zulu> hi asac I was just about to write you an email
[22:11] <pace_t_zulu> asac: i am interested in the chromium project
[22:12] <asac> pace_t_zulu: what parts are you most interested in?
[22:12] <pace_t_zulu> asac: building and documentation
[22:12] <asac> mpontillo: so how does the user agent string look like now? have you checked?
[22:12] <pace_t_zulu> asac: the instructions at https://wiki.ubuntu.com/Chromium/Build are not sufficient
[22:13] <pace_t_zulu> asac: i was maintaining instructions at http://help.ubuntu.com/community/Chromium ... that URL now redirects to https://wiki.ubuntu.com/Chromium/Build
[22:13] <mpontillo> asac: yes, it comes back "Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.0.10) Gecko/20080528 Ubuntu/9.04 (9.04) Epiphany/2.22 Firefox/3.0"
[22:14] <mpontillo> asac: hah, nevermind, guess you caught a bug ;)
[22:14] <asac> mpontillo: two bugs ;)
[22:14] <asac> mpontillo: in brackets there is the codename
[22:14] <asac> and the Epiphany/2.22 has to go most likely
[22:14] <asac> otherwise i would expect some websites to go nuts
[22:15] <asac> however: this means that Epiphany wont be anywhere anymore :)
[22:15] <pace_t_zulu> asac: i would like to contribute to the project...
[22:15] <mpontillo> asac: really? I thought each whitespace-separated "blob" was treated separately
[22:15] <pace_t_zulu> asac: I email Fabien in English
[22:15] <asac> mpontillo: well. i dont know what the standard says. but in practice there are bunch of crappy webapps out there that get it wrong
[22:16] <asac> pace_t_zulu: yeah. so the instructions dont work for the "upstream" way?
[22:16] <pace_t_zulu> asac: when i realized he is French speaking i translated the email and resent it... but i have yet to receive a response
[22:16] <pace_t_zulu> asac: perhaps I am missing something
[22:16] <asac> pace_t_zulu: he is out for a another few weeks i think
[22:17] <pace_t_zulu> asac: i'd like to become a part of the project
[22:17] <asac> pace_t_zulu: yeah so ... besides from keeping the .daily build alive
[22:17] <pace_t_zulu> asac: and i feel like the first step towards that is to be able to successfully build chromium on a stock system
[22:17] <asac> i think one of the major tasks left is to allow more system libs to be used
[22:17] <pace_t_zulu> asac: even perhaps using pbuilder
[22:17] <asac> pace_t_zulu: if thats what you want to do, do it. it cant hurt being able to build chromium ;)
[22:18] <asac> pace_t_zulu: so follow the instructions on the wiki
[22:18] <pace_t_zulu> asac: yes there is a problem with python-tlslite
[22:18] <pace_t_zulu> asac: that package is not available through MOTU
[22:18] <asac> pace_t_zulu: its availble in the chromium-daily ppa
[22:18] <asac> pace_t_zulu: use that to get started
[22:18] <asac> https://edge.launchpad.net/~chromium-daily/+archive/ppa
[22:19] <pace_t_zulu> asac: ok... is there further documentation of the "upstream way" that i should be aware of?
[22:19] <asac> pace_t_zulu: so .... to get started branch the chromium.daily bzr branch (like on the wiki) ... install the build-deps after adding chromium daily to your sources.list
[22:19] <asac> pace_t_zulu: i wouldnt think there is
[22:20] <asac> pace_t_zulu: point is if you want to contribute here, you definitly want to know how to use the packaging branches
[22:20] <pace_t_zulu> asac: should i be looking for a debian chromium group? or is upstream in these case just the chromium project?
[22:20] <asac> pace_t_zulu: because at least half of the work is usually packaging stuff ... supplemented by developing patches to make chromium ready for good packaging
[22:20] <asac> pace_t_zulu: upstream is just chromium
[22:20] <asac> pace_t_zulu: e.g. no debian
[22:20] <mpontillo> asac: for what it's worth, the chromium daily's user agent reports "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/530.9 (KHTML, like Gecko) Chrome/2.0.178.0 Safari/530.9". guess they'll need a similar patch ;)
[22:21] <pace_t_zulu> asac: that is how i want to contribute (getting chromium ready for good packaging)
[22:21] <pace_t_zulu> asac: i'd like to help in any way possible
[22:21] <asac> mpontillo: tweaking user agents is a hard thing to verify what comes out of it ... using an unofficial/unreleased build and copy that might not be the best idea ;)
[22:21] <asac> mpontillo: but well ... we can try in karmic.
[22:22] <asac> pace_t_zulu: yeah. so to get ready, setup your work environment first. get the bzr branches, try the instrcution how to produce a orig.tar.gz
[22:23] <asac> pace_t_zulu: once you feel comfortable that you can handle it, the task would be to look for in source libs that are duplicated and that could be using our system libs
[22:24] <asac> then identify if the version they ship is similar to what we have and if they  have applied any hacks/patches in their source tree
[22:24] <mpontillo> https://developer.mozilla.org/En/User_Agent_Strings_Reference is a good reference - sounds like the current Firefox doesn't even follow their suggestion exactly
[22:24] <pace_t_zulu> asac: thank you for your time... i'd like to be a valuable contributor to the chromium-project... hopefully become a member of the chromium team
[22:26] <pace_t_zulu> asac: I will let you know when I successfully build
[22:26] <pace_t_zulu> asac: thank you for taking the time to answer my questions and point me the right way
[22:26] <asac> no problem
[22:27] <mpontillo> asac: here's what the standard says: http://tools.ietf.org/html/rfc2068#section-14.42
[22:27] <asac> i would suggest to look at the RFCs
[22:28] <asac> mpontillo: yeah. still problem is that standards are only good if they are followed by websites
[22:28] <mpontillo> right. actually this RFC section is the most current: http://tools.ietf.org/html/rfc2616#section-14.43 ... basically it says you can put as many as you like. that's why the mozilla link was also useful
[22:29] <asac> there have been prominent websites in the past that broek because of stupid changes to the agent
[22:29] <asac> as i said ... we can try for epiphany ;)
[22:30] <mpontillo> right, badly coded user agent strings have been a pet peeve of mine for awhile. I had to use the user agent switcher extension to file my taxes with turbotax online ;)
[22:30] <asac> see what i mean ;)?
[22:30] <mpontillo> and this was just with vanilla firefox/linux!
[22:30] <asac> so maybe eliminating epiphany from the user-agent string all together would make sense
[22:30] <asac> would be kind of a tough move
[22:30] <asac> but given that epiphanies market share is probably minor, i am not sure if anyone would really notice ;)
[22:31] <asac> mpontillo: anyway. imo the patch is ok
[22:32] <asac> it uses only prefs that exist in firefox
[22:32] <mpontillo> asac: okay, I have a new one for you (one character change) that fixes that dang comment bug
[22:32] <mpontillo> but I'm sure you could handle that yourself ;)
[22:32] <asac> just remember to subscribe to bugmail and if folks complain that a site doesnt work anymore (because of user-agent) we need to take action i guess
[22:32] <mpontillo> right, I'm subscribed.
[22:33] <asac> mpontillo: check a few popular AJAX sites, like gmail/yahoo new mail interface/hotmail and stuff maybe ... or other sites you know that try to be smart and block users depedning on user-agent string
[22:34] <asac> mpontillo: ok. can you give me the bug id please?
[22:34] <asac> got it
[22:35] <mpontillo> asac: 1 sec, I'll post the new patch if it does what I expect. installing new deb now. it's bug 372756
[22:35] <asac> mpontillo: yeah. remember to use the codename instead of version in brackets
[22:35] <asac> i think thats vendorSub
[22:35] <mpontillo> arg, copy/paste error - bug 332253 - trying to do too many thigns at once
[22:35] <asac> mpontillo: heh. so its vendorComment
[22:36] <asac> mpontillo: so change vendorComment to contain the code name. that matches what we have in firefox default install
[22:36] <asac> mpontillo: and do a full debdiff if you want to be the changelog owner ;)
[22:38] <mpontillo> k - need to go learn how to use debdiff, sorry for any delays, holding a kid on my lap and feeding another kid a sippy cup, limited bandwidth
[22:38] <asac> mpontillo: so do: apt-get source epiphany-browser
[22:38] <asac> create new changelog entry nd apply your patch
[22:38] <asac> then build sources:
[22:38] <asac> debuild -S
[22:38] <asac> for instance
[22:39] <asac> then you can run debdiff *.dsc
[22:40] <asac> mpontillo: to create new changelog entry use "dch -i"
[22:42] <mpontillo> asac: right, so the first thing I did after apt-get source was the dch -i, and I "quilted" my patch in... running the debdiff seems to produce a lot of extra junk I didn't change though. I suppose I need to change the quilt control file to ensure my patch is at the end?
[22:43] <asac> mpontillo: yeah. thats the bad about the some packages. they are not "clean"
[22:43] <mpontillo> (I popped the 99_ ones off the quilt stack before I started my work)
[22:43] <asac> mpontillo: so just do a fresh apt-get source
[22:43] <asac> apply your changes
[22:43] <asac> and dont build binaries
[22:43] <asac> just sources: debuild -S
[22:43] <mpontillo> ah, okay. will do
[22:51] <mpontillo> updated bug 332253, new patch here http://launchpadlibrarian.net/26411305/epiphany_lsb_useragent_debdiff.patch
[22:54] <mpontillo> asac: oh, wait - I signed it with my pgp key as well, do I need to attach a separate file to verify that?
[22:54] <mpontillo> ah, just now saw your email, sorry
[22:57] <asac> mpontillo: why do you want to verify that ?
[22:57] <asac> just need debdiff ;)
[22:58] <mpontillo> asac: okay, wasn't sure what the process was. how does the process work? somehow you need to put that into debian/patches, right?
[23:07] <mpontillo> (...in other words, I'm wondering if I missed a step; i.e. was I supposed to create a patch that included the quilt control file change, and my patch file - not the changes from that patch file?)
[23:08] <asac> mpontillo: well. you need to add the patch that touches code base into debian/patches
[23:08] <asac> the changes you did to rules just go to debian/rules directly
[23:09] <asac> and you also need to change debian/patches/series accordingly
[23:09] <asac> document all in the changelog
[23:09] <asac> and the do a debdiff on that
[23:11] <mpontillo> asac: okay; I need to re-do it then. when you said "apply your changes" I thought you meant "patch -p1 < mypatch-from-debian/patches". sorry - used to working with source control systems, not patches!
[23:12] <asac> mpontillo: sorry for the confusion.
[23:12] <mpontillo> asac: no worries, I don't think it's the easiest process. I'm taking notes. maybe I'll update the wiki to make any instructions clearer
[23:20] <asac> mpontillo: yeah. its a bit unfortunate that you hit a package that doesnt build cleanly ;)
[23:21] <asac> lesson learned ... whenever i want to do a drive-by change to a package i dont know i try to remember to run a debuild -S before doing a test build ... i nthat way i can unpack the clean sources after build ;) ... annoying if you want to do serious works obviously.
[23:21] <rickspencer3> bryce_: holy cow, that was fast!
[23:22] <bryce_> :-)
[23:22] <asac> is bryce_ sprinting :-P?
[23:22] <rickspencer3> bryce_: sortable by chipset and symptom!
[23:22] <rickspencer3> asac: I mentioned a view onto intel bugs to bryce at about 11:30am this morning, figuring we'd work on it over the next few weeks
[23:23] <asac> heh. fast indeed ;)
[23:23] <rickspencer3> and it shows up like magic not even four hours later!
[23:23] <bryce_> hehe
[23:24] <bryce_> well, to be honest this is stuff I've been working on for a while; the tags and chipset stuff was pretty straightforward to add to it
[23:25] <rickspencer3> bryce_: lot more 945 stuff than I was expecting
[23:25] <bryce_> http://www2.bryceharrington.org:8080/X/symptoms_intel.html
[23:25] <rickspencer3> can your server handle the traffic ;)
[23:25] <rickspencer3> maybe you should put some google ads up there :P
[23:25] <bryce_> of course, I've got FIOS ;-)
[23:36] <mpontillo> asac: *sigh*, still wasn't getting the right result, figured out that I had to do "debdiff --control --controlfiles rules *.dsc" or debdiff left out the change to the 'rules' file
[23:37] <asac> mpontillo: for me just doing debdiff *.dsc worked
[23:37] <asac> (always)
[23:37] <asac> no arguments needed
[23:38] <mpontillo> asac: it didn't diff the 'rules' file when I left that out, even though it was in my .dsc and not the original one created from "debuild -S -us -uc" after the fresh "apt-get source"
[23:38] <mpontillo> argh, today is not my day, I accidentally hit "enter" at the wrong time when attaching the new debdiff, so the patch description is garbled
[23:39] <asac> you can delete attachments from bugs;)
[23:39] <mpontillo> can I? I don't see the option to.
[23:40] <mpontillo> in any case, after *way* too much work just to change a simple config file, I think the good patch is indeed here: http://launchpadlibrarian.net/26412707/epiphany_lsb_release_good_debdiff.patch
[23:45] <mpontillo> okay I must need coffee. ;) I take back what I said about the rules file. I think it worked the first time. my apologies.
[23:48] <asac> mpontillo: yeah that looks good ;)
[23:48] <asac> thanks
[23:48] <mpontillo> to summarize the "best practice" here: always run "debuild -S -us -uc" after running "apt-get source <pkg>", change only the control files needed for `what-patch` to do the right thing, do not include control files in the patch in debian/patches, edit the changelog, run "debuild -S" again, then run "debdiff *.dsc".
[23:49] <asac> mpontillo: only nit is that it should be "karmic" not "jaunty". but i can change that
[23:49] <asac> mpontillo: hmm not sure if lp: #... works ... i will change that to LP: #... too
[23:50] <mpontillo> asac: no problem, hopefully my next bug will be faster, now that I kind of know what I'm doing. ;) I had no idea there would be so much to learn... and yeah my dev box is still jaunty, because I don't have a dedicated dev box yet (working on that).
[23:50] <mpontillo> asac: I copied the "lp:" line from later in the changelog
[23:55] <asac> mpontillo: i changed the comment a bit ... and uploaded
[23:57] <mpontillo> asac: cool, thanks! now we sit back and wait for reports of all the web sites with broken user agent parsing... maybe all 3 epiphany users on karmic will find them fast ;)
[23:57] <asac> lol ... more or less yes ;)
[23:58] <asac> mpontillo: just remember to listen to bugs during Beta or RC ;)
[23:58] <asac> but i think webkit might actually end up being the ephy default by then. so lets see
[23:59] <asac> anyway ... out for today. let me know if there are issues with the build or something
[23:59] <mpontillo> thanks for all your help