[21:06] <Kraus> Well, maybe the answer is hiding in this channel. Anyone know of a way to install Glade 3.38.1 ? The Ubuntu depository hasn't updated their apt package since 2018.
[21:07] <Kraus> (Besides Snapcraft)


[05:44] <doko> nacc: are you handling php and the 7.2 transition? if not. please point somebody else to it ... looking at component mismatches proposed: libsodium needs a bug subscriber, dh-php a MIR, argon2 as well
[05:47] <doko> plus xml2
[05:49] <doko> rbalint: flash-kernel merge: mtd-utils probably needs a MIR
[05:51] <doko> jamespage: pycryptodome and pysmi need a MIR (dep of python-pysnmp4, openstack maintained)
[05:53] <doko> juliank: lvm2 merge: thin-provisioning-tools needs a MIR, or recommends dropped to suggests
[05:55] <doko> xnox: libzstd needs a MIR (for new btrfs-progs)
[06:20] <doko> juliank: please see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for cryptsetup (unsatisfiable Depends)
[06:46] <doko> tsimonq2: libindi is stuck in proposed
[06:50] <Unit193> doko: I'd presume you saw Debian #888531 and https://wiki.debian.org/Teams/Ruby/ruby2.5?  (Including the test rebuild results.)
[06:51] <doko> Unit193: and?
[06:52] <Unit193> You expressed interest.  Good then.
[06:58] <doko> Unit193: it's scheduled for demotion
[06:58] <Unit193> Ah, that works too.
[07:10] <doko> ginggs: gazebo ftbfs (unstable as well)
[07:14] <juliank> doko: lvm2 ok, well, britney does not care, so I did not see that. cryptsetup hopefully sorts itself out once argon2 is MIRed and lvm2 is migrated.
[07:15] <doko> juliank: you see that in component mismatches proposed
[07:15] <doko> somebody has to write the argon2 MIR, either foundations, or server
[07:16] <juliank> doko: The argon2 MIR is at security review already :)
[07:16] <doko> ahh, ok. do they know? ubuntu-mir is not subscribed to the bug
[07:17] <juliank> Sure they are
[07:17] <juliank> https://bugs.launchpad.net/ubuntu/+source/argon2/+bug/1746047
[07:17] <juliank> "Notified of all changes MIR approval team"
[07:18] <doko> hmm, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt doesn't show the subscription
[07:18] <juliank> and cyphermox did the review and reassigned to ubuntu-security
[07:18] <juliank> doko: It's older than the MIR I think
[07:20] <juliank> bug is 17:16, mismatches 12:24
[07:20] <doko> looks like it's out-of-date
[07:35] <ginggs> doko: ok, i'll look
[07:40] <juliank> doko: fixed lvm2. (I think it might be worth considering MIRing thin-provisioning-tools given that missing it could make your system unbootable if you use a cache LV, but um, let's worry about that later)
[07:43] <juliank> maybe it should just be made a bit smarter and refuse to generate cache LVs without them installed.
[08:24] <cpaelzer> xnox: we talked about lp 1744328 / debian 888764 - I'm kind of blocked on this, but unless Debian says yes I'd at least have a 2nd opinion to take it as Ubuntu Delta
[08:28] <xnox> doko, tah
[08:35] <tjaalton> cpaelzer: mike won't accept anything that upstream hasn't marked public :/
[08:35] <tjaalton> i've fought things like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855879 for years
[08:36] <tjaalton> which I need for nss-pam which is needed for certmonger to be useful
[08:36] <cpaelzer> thanks for the info tjaalton
[08:36] <tjaalton> even looped in redhat folks
[08:36] <cpaelzer> I'm leaning towards adding that as a delta then, but would be pleased if a few people could ack on it
[08:37] <cpaelzer> I might prepare a proper MP for an Ubuntu Delta on it and add you and xnox to comment there
[08:37]  * cpaelzer is fully reading tjaalton's example bug now ...
[08:38] <tjaalton> was thinking if bringing this up on CTTE would be warranted or not
[08:42] <cpaelzer> sorry tjaalton - abbreviation overload - CTTE ?
[08:42] <tjaalton> debian technical committee
[08:43] <cpaelzer> I like your patch to 855879
[08:44] <cpaelzer> although reading all that makes me feel bad
[08:44] <tjaalton> crickets..
[08:46] <cpaelzer> maybe a combined version that would make the .so's accesible (for cases like mine) and the .a files (as suggested by you) would be the best
[08:59] <xnox> cpaelzer, hm..... surely all you need is a one line to create a symlink in like debian/libfoo.links and that's it, no?
[08:59] <xnox> cpaelzer, and just upload that into ubuntu direct.
[08:59] <cpaelzer> I know what I need :-) I just want to have a few acks on the way I do it :-)
[08:59] <xnox> cpaelzer, (possibly with dh-exec if you need DEB_HOST_MULTIARCH location)
[09:00] <cpaelzer> and after reading into all of tjaalton it might be the time to do a more generic overhaul
[09:00] <cpaelzer> xnox: but I hear you are not opposed to making the libs accessible - that was the important pre-check
[09:00] <cpaelzer> slangasek: pointed me to "talk to xnox on this" - that is what I'm doing :-)
[09:01] <tjaalton> the new pkg for nss-pem can be added later
[09:02] <cpaelzer> tjaalton: ok so you have time to escalate this to Debian and back for nss-pem then?
[09:02] <cpaelzer> ok then I might really only change the .so's being a less invasive change
[09:02] <tjaalton> yes
[09:02] <tjaalton> filed the ITP for nss-pem
[09:02] <tjaalton> see what happens
[09:03] <cpaelzer> thanks, it still was very very sueful to get all that context on this
[09:03] <cpaelzer> useful even
[09:03] <xnox> cpaelzer, i don't think it is a good idea to create a new package, i don't think changing library location is ok, i think symlink is fine to satisfy everything you want, there is no need for new source or binary packages.
[09:04] <cpaelzer> yep, after the last few minutes of discussion here I'm agreeing to that xnox
[09:44] <xnox> tsimonq2, i made a huge mistake of uploading nodejs tweak =/ the amount of autopkgtests is humongous
[09:48] <doko> tsimonq2: does kubuntu care about qdigidoc? https://launchpad.net/ubuntu/+source/qdigidoc/0.4.1-0ubuntu2
[09:48] <doko> that seems to be out-of-date since 2012
[09:50] <doko> cjwatson: are you ok with temoting tickcount?
[09:51] <cjwatson> doko: yes
[09:51] <cjwatson> doko: I have a todo item to remove our use of it entirely (we need a sort of partial replacement, but can't continue using interpreter ticks)
[09:52] <doko> ok, unseeding then
[09:53] <cjwatson> doko: in general it doesn't make sense for python-* to be seeded on Launchpad's behalf any more.  Since ~2009 we've only used a relatively small number of system-packaged Python packages, and mostly use buildout (until end of last year) / pip (now)
[09:54] <cjwatson> doko: python-tickcount was an exception to that, but as I think I mentioned on the bug, if necessary we could keep it in our deployment PPA anyway
[09:59] <doko> ok. I'll just demote, don't remove it yet
[10:03] <xnox> doko, do we have a place to document / record 32-bit only issues that I have to dig/hunt to solve? e.g. I'm currently looking at i386 and i386+armhf only adt failures triggered by openssl upload.
[10:04] <doko> xnox: no, not afaik
[10:04] <doko> besides the i386 float stuff probably
[11:40] <cpaelzer> links/dh-exec doesn't like me :-/
[11:40] <cpaelzer> has someone an example of dh-exec in .links to create multiarch links?
[11:43] <xnox> cpaelzer, is the .links file executable?
[11:43] <xnox> cpaelzer, does it have dh-exec shebang?
[11:44] <xnox> cpaelzer, or can you push your repository somewhere for me to check it?
[11:44] <cpaelzer> it is just me never using it that way - I iterated a bit but it keeps failing with
[11:44] <cpaelzer> dh_link: symlink(nss/libfreebl3.so, debian/libnss3/usr/lib/${DEB_HOST_MULTIARCH}/) failed: No such file or directory
[11:45] <cpaelzer> I'm sure I do something wrong, but without an example to check against it is stupid iterating through trial-and-error
[11:45] <cpaelzer> I'm in a chroot of an sbuild and can tweak it
[11:45] <cpaelzer> atm it is like
[11:46] <cpaelzer> http://paste.ubuntu.com/26488822/
[11:46] <cpaelzer> and files relative to the build are like
[11:46] <cpaelzer> http://paste.ubuntu.com/26488823/
[11:46] <cpaelzer> I (currently) assume it doesn't have the variable exported or something like it
[11:46] <xnox> cpaelzer, there should never be leading '/' in any of these files
[11:46] <xnox> it should be executable
[11:46] <cpaelzer> I tihnk I had all variations of this :-/
[11:46] <xnox> thus something like:
[11:47] <xnox> horum =/
[11:48] <xnox> cpaelzer, and it should be full paths before and after....
[11:48] <cpaelzer> oh that I never tried
[11:48] <cpaelzer> ..
[11:48] <xnox> usr/lib/${DEB_HOST_MULTIARCH}/nss/libfreebl3.so usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so
[11:48] <xnox> i think, yet manual has leading slashes in examples.
[11:48] <cpaelzer> it also is the variable
[11:49] <cpaelzer> only when I drop the var I get to the "is a directory" error
[11:49] <cpaelzer> which is about the filename on the second argument as you just said
[11:49] <xnox> fun
[11:50] <cpaelzer> so "usr/lib/x86_64-linux-gnu/nss/libfreebl3.so usr/lib/x86_64-linux-gnu/libfreebl3.so" works
[11:50] <cpaelzer> now I need to find what I miss to get the variable resolved
[11:50] <cpaelzer> I had $() and ${} and tried on exporting the variable
[11:50] <xnox> include /usr/share/dpkg/default.mk on top of debian/rules?
[11:51] <cpaelzer> have it working now
[11:51] <cpaelzer> interesting
[11:51] <cpaelzer> it was the full path incl file on the second argument
[11:51] <cpaelzer> just when variables are used the error without it is way off
[11:51] <xnox> whoop whoop
[11:51] <cpaelzer> thanks xnox, now all that back into proper packaging for another full try :-)
[11:52] <cpaelzer> xnox++
[11:52] <cpaelzer> (we should have more of you)
[11:54] <doko> ohh no, I can't stand more noise ;p
[12:15] <cpaelzer> xnox: grml - we only made it 75% - it now links to a literal ./debian/libnss3/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so :-)
[12:17] <xnox> cpaelzer, as per $ man dh-exec-subst it says ${DEB_HOST_MULTIARCH} will be substituited....
[12:18] <cpaelzer> yes, but it is not :-/
[12:18] <cpaelzer> mabye it only calls plain dh-links in my case
[12:18] <cpaelzer> that is how it seems to me atm
[12:19] <cjwatson> cpaelzer: what's your debhelper compat level?
[12:19] <cpaelzer> 9
[12:19] <cjwatson> ok, 9 should work
[12:19] <cjwatson> cpaelzer: how about your source format?
[12:19] <cpaelzer> 3.0 (quilt)
[12:20] <cpaelzer> nothing too special on any of that
[12:20] <cjwatson> can I see the source package?
[12:21] <cpaelzer> sure it is essentially pull-lp-source nss + experimenting with debian/libnss3.links as http://paste.ubuntu.com/26488955/
[12:21] <xnox> cpaelzer, you have dh-exec as build-dependency right?
[12:21] <cpaelzer> I've had it
[12:21] <cjwatson> ideally I'd like to see your actual .dsc + extra files
[12:21] <cjwatson> especially the .debian.tar.*
[12:22] <xnox> cpaelzer, scp it to people.canonical.com?
[12:22] <Laney> the file is executable?
[12:22] <cpaelzer> executable - yes
[12:22] <cpaelzer> I'll upload and share a link
[12:29] <cpaelzer> I put all in a tarball at http://people.canonical.com/~paelzer/nss-links-multiarch.tgz
[12:30] <cpaelzer> I realized I had it not executable in the packaging yet (only per chmod in the sbuild chroot)
[12:30] <cpaelzer> so I cahnged that as well and am currently rebuilding
[12:30] <cpaelzer> I'll ping if this (as in the tarball) is still failing me on the rebuild
[12:39] <cpaelzer> nice - it really was the +x permissions before buildpackage
[12:39] <cpaelzer> I'll save all that as big learning experience
[12:39] <cpaelzer> thanks for your patience Laney, cjwatson and xnox
[12:40] <cpaelzer> it now worked (breaking things post dh_link due to that, but worked)
[12:40] <cjwatson> executable in the packaging> yep, that was why I wanted to check the .debian.tar.* :-)
[12:42] <cpaelzer> the follow on fallout is interesting
[12:42] <cpaelzer> dh-exec creates debian/tmp (as th emanpages tells me)
[12:42]  * Laney has been there before
[12:42] <cpaelzer> and until now the d/rules had mkdir debian/tmp (without -p)
[12:42] <Laney> forgetting to commit the mode change and being surprised when it didn't survive gbp buildpackage -S or something like that
[13:21] <jbicha> doko: LP: #1745634 would make it easier for me to try to demote xterm to universe
[13:28] <doko> jbicha: yeah, probably worth doing that
[13:45] <jbicha> doko: cool. Could you unseed it or comment on the bug if you'd prefer I do it?
[13:51] <tjaalton> slangasek: hi, finally wrote a small patch to pam-auth-update to fix https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1192719
[15:00] <doko> xnox: are you undoing my libp11 no-change uploads?
[15:01] <xnox> doko, ..... libp11 was not rebuild against openssl1.1.0 because we don't have that... thus p11 3 abi is a lie.
[15:02] <xnox> doko, we need to redo those uploads, properly, to rebuild that 3 abi, against the right openssl.
[15:05] <doko> yes, seen that now. will you do, or should I?
[15:08] <xnox> doko, either or. as you wish. I was planning to do the unwind.
[15:08] <doko> xnox: ok, please do
[16:19] <nacc> doko: yes
[16:22] <nacc> doko: (re: php7.2)
[16:23] <nacc> doko: i'll be promoting it to main once i get it all fixed up, just like we did 7.1 previously, and removing 7.1 from the archive
[16:24] <doko> ta
[16:24] <doko> nacc: well, write the MIRs first ...
[16:25] <nacc> doko: yep
[16:28] <nacc> doko: to be clear the dh-php one is already resolved, just hasn't been caught up it seems (dh-php is only a suggests)
[17:22] <tsimonq2> doko: I'm aware.
[17:23] <tsimonq2> xnox: nodejs> ack :( thanks for telling me
[17:27] <nacc> doko: afaict, argon2 is not related to php?
[17:27] <tsimonq2> doko: I think at this point if it's KDE 4 or Qt 4 and you can handle rdeps, take it out
[17:53] <tsimonq2> I wonder if Bileto access could be reconsidered now that all PPA arches are unblocked.
[17:53] <tsimonq2> Maybe allow ~ubuntu-dev access or something :)
[17:54] <tsimonq2> I have access to do Qt transitions but I know it would be really useful to use with other Ubuntu Developers (with upload access)
[17:56] <tsimonq2> I might start a discussion on ubuntu-devel unless it's decided here :)
[17:57] <nacc> doko: ok, we've subscribed ubuntu-server to libsodium; is that enough to re-main it, once necessary?
[17:57] <ginggs> doko: gazebo and cyphesis-cpp uploaded, i think tinyxml2 will migrate if you rm openmw:arm64
[18:43] <doko> mwhudson: why is golang-1.8-go still in main?
[18:47] <doko> ginggs: done
[18:49] <ginggs> flexiondotorg: would you add Conflicts: telegram-desktop to your telegram PPA packages please?  It would prevent future bugs like LP: #1740708
[18:49] <ginggs> doko: ta!
[18:49] <flexiondotorg> ginggs: OK
[18:50] <ginggs> flexiondotorg: ta!
[19:53] <slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 7?
[19:53] <mdeslaur> ack
[20:04] <mwhudson> doko: dunno, shouldn't be afaik
[20:16] <juliank> cjwatson: I'm looking at archivepublisher now to see where changes would be needed for valid-until support. It does not seem _that_ difficult. Basically we add the field for all -updates, -security releases; and add the release files to the set that needs updates if it's older than a week.
[20:17] <juliank> (and make validity 2 weeks)
[20:18] <juliank> old releases might be tricky
[20:18] <juliank> not sure
[20:19] <juliank> or, rather then looking at the age of the release file, we open it and check that valid-until does not expire for more than a week
[20:20] <juliank> I guess it needs a flag in the model somewhere that tells it "Valid-Until" is allowed
[20:21] <juliank> well "needs"
[20:50] <juliank> LP takes a while to branch :D
[21:17] <juliank> cjwatson: That is, https://paste.ubuntu.com/26491551/ or https://code.launchpad.net/~juliank/launchpad/valid-until
[21:17] <juliank> I have not run any tests yet...
[21:22] <juliank> update: http://paste.ubuntu.com/26491574/
[21:25] <juliank> forgot initialize...: http://paste.ubuntu.com/26491591/
[21:26] <juliank> now it needs tests and some testing
[21:26] <juliank> but I think the idea is clear.
[21:26] <juliank> ugh, should have posted in #launchpad
[21:27]  * juliank moves to #launchpad-dev
[21:32]  * tsimonq2 is curious about what Valid-Until support means and what the use case would be
[21:40] <cjwatson> juliank: something like that is probably a good start (note that when the bug was just filed it would have been a *lot* harder, because the ability to write just the Release file wasn't really there), but it'll need extensive tests
[21:40] <juliank> yeah
[21:41] <juliank> cjwatson: I also posted in #launchpad-dev now, so we can follow up there if needed :)
[22:18] <slangasek> tsimonq2: if you know that your archive is periodically republished, then including in the signed data that a given archive state is invalid after a given date prevents a silent replay attack
[22:23] <cjwatson> (assuming reasonably synced clocks etc.)
[22:36] <juliank> tsimonq2: To further comment, you can prevent what you could call update starvation. That is, for -updates, currently you can feed apt an old archive state all the time, and it says "oh fine, no updates".
[22:42] <tsimonq2> slangasek: Hm ok, interesting.
[22:42] <tsimonq2> juliank: So then what will apt do in the case of an old archive state?
[22:43] <juliank> tsimonq2: If the archive is not valid anymore it will give you an error if you update
[22:43] <juliank> tsimonq2: You can easily try that yourself in a Debian chroot, just set the clock backward :D
[22:43] <tsimonq2> juliank: heh OK :)
[22:44] <tsimonq2> juliank: What if I just have an outdated archive mirror that's *purposely* set that way for some reason? (obviously not in prod but for testing) Will I be able to override this in sources.list the same sort of way I override untrusted entries?
[22:45] <juliank> tsimonq2: You can set check-valid-until to no
[22:45] <juliank> you can also configure valid-until-{min,max}
[22:46] <juliank> these are in seconds, BTW
[22:46] <tsimonq2> Could you give an example (or a manual I can RTFM on)?
[22:47] <juliank> tsimonq2: It's all documented in sources.list, but no excamples in there I guess
[22:47] <juliank> tsimonq2: in the manpage, that is
[22:47] <juliank> tsimonq2: This feature is over 6 years old already
[22:47] <tsimonq2> juliank: oh hah, TIL
[22:48] <juliank> tsimonq2: Here's the LP bug from 2011: https://bugs.launchpad.net/launchpad/+bug/716535
[22:49] <tsimonq2> juliank: subbed, thanks
[22:50] <Unit193> http://snapshot.debian.org/ also notes the use of check-valid-until.
[22:54] <tsimonq2> Oh, right. Interesting.
[23:03] <juliank> tsimonq2: It's a bit inconvenient in some use cases with historical distros, but it's a huge security improvement IMO
[23:03] <juliank> :D
[23:15] <tsimonq2> :D right


[09:11] <mrevell> Hallo
[11:12] <Laney> could someone very kindly rescore a recipe build? https://code.launchpad.net/~meebey/+archive/smuxi-daily/+recipebuild/123206
[11:51] <wgrant> Laney: Done.
[12:42] <Laney> wgrant: thank you!
[12:44] <czajkowski> aloha
[12:45] <czajkowski> mrevell: you're busy blogging lately, well done :p
[12:45] <mrevell> I am?
[12:46] <mrevell> czajkowski, sinzui and poolie have blogged; I've done little more than status updates. danhg is about to make his first blog post, though :)
[12:46] <mrevell> but thanks czajkowski :)
[12:47] <czajkowski> mrevell: not complainign I like the advance notice of stuff for schedueled maintenance
[12:47] <czajkowski> tis nice
[12:47] <mrevell> ah, I thought we'd always done that :) But yes, glad it's doing the trick.
[15:03] <dpm> hi rvba (or anyone else), could you help me with a question? I'm trying to find out if automatic translation imports will import a template in a branch if the template is a symlink to a .pot file instead of a plain .pot file?
[15:05] <rvba> dpm: Hi, let me try to find the answer to your question.
[15:05] <dpm> thanks :)
[15:07] <Oleg|percona> Hi guys
[15:07] <Oleg|percona> Hi guys
[15:07] <rvba> dpm: I think symlinks are excluded  when the branch is scanned to avoid uploading a file  twice.
[15:07] <Oleg|percona> oleg.tsarev (0) /storage/dev/percona/19557$ bzr branch lp:percona-server/5.1
[15:07] <Oleg|percona> ssh_exchange_identification: Connection closed by remote host
[15:07] <Oleg|percona> I change nothing, I double-check my ssh key on laucnhpad, but all is ok
[15:08] <Oleg|percona> oleg.tsarev (0) /storage/dev/percona/19557$ bzr branch lp:percona-server/5.1
[15:08] <Oleg|percona> ssh_exchange_identification: Connection closed by remote host
[15:08] <Oleg|percona> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[15:08] <Oleg|percona> This is a bug?
[15:08] <rvba> Oleg|percona: this might be a temporary network problem… is the problem reproductible?
[15:09] <Oleg|percona> I have good connection, ping and traceroute wokrs ok
[15:09] <Oleg|percona> But problem reproductible
[15:09] <Oleg|percona> rvba: Ooops
[15:09] <rvba> Let me try on my machine…
[15:09] <rvba> All ok here.
[15:10] <rvba> Oleg|percona: ?
[15:10] <Oleg|percona> oleg.tsarev (0) /storage/dev/percona/19557$ traceroute bazaar.launchpad.net
[15:10] <Oleg|percona> traceroute to bazaar.launchpad.net (<IP_ADDRESS>), 30 hops max, 60 byte packets
[15:10] <Oleg|percona>  1  DD-WRT (<IP_ADDRESS>)  1.205 ms  1.264 ms  1.602 ms
[15:10] <Oleg|percona>  2  <IP_ADDRESS> (<IP_ADDRESS>)  5.076 ms  5.326 ms  6.031 ms
[15:10] <Oleg|percona>  3  <IP_ADDRESS> (<IP_ADDRESS>)  3.296 ms  3.374 ms  3.607 ms
[15:10] <Oleg|percona>  4  prime.lanet (<IP_ADDRESS>)  4.446 ms  5.539 ms  5.524 ms
[15:10] <Oleg|percona>  5  core.la.net.ua (<IP_ADDRESS>)  4.048 ms  4.455 ms  4.706 ms
[15:10] <Oleg|percona>  6  <IP_ADDRESS> (<IP_ADDRESS>)  5.921 ms  3.368 ms  2.437 ms
[15:10] <Oleg|percona>  7  <IP_ADDRESS> (<IP_ADDRESS>)  34.960 ms  35.715 ms  35.692 ms
[15:10] <Oleg|percona>  8  xe-9-1-0.edge4.frankfurt1.level3.net (<IP_ADDRESS>)  35.674 ms  35.648 ms  35.960 ms
[15:10] <Oleg|percona>  9  vlan70.csw2.Frankfurt1.Level3.net (<IP_ADDRESS>)  35.922 ms vlan90.csw4.Frankfurt1.Level3.net (<IP_ADDRESS>)  35.884 ms vlan80.csw3.Frankfurt1.Level3.net (<IP_ADDRESS>)  35.855 ms
[15:10] <Oleg|percona> 10  ae-62-62.ebr2.Frankfurt1.Level3.net (<IP_ADDRESS>)  36.977 ms ae-82-82.ebr2.Frankfurt1.Level3.net (<IP_ADDRESS>)  36.944 ms  36.897 ms
[15:10] <Oleg|percona> 11  ae-22-22.ebr2.London1.Level3.net (<IP_ADDRESS>)  46.037 ms  45.615 ms  45.935 ms
[15:10] <Oleg|percona> 12  vlan103.ebr1.London1.Level3.net (<IP_ADDRESS>)  44.394 ms vlan104.ebr1.London1.Level3.net (<IP_ADDRESS>)  43.402 ms vlan102.ebr1.London1.Level3.net (<IP_ADDRESS>)  43.495 ms
[15:10] <Oleg|percona> 13  ae-3-3.ebr2.London2.Level3.net (<IP_ADDRESS>)  51.545 ms  51.894 ms  51.863 ms
[15:10] <Oleg|percona> 14  ae-2-56.edge4.London2.Level3.net (<IP_ADDRESS>)  44.542 ms ae-2-54.edge4.London2.Level3.net (<IP_ADDRESS>)  45.090 ms ae-2-52.edge4.London2.Level3.net (<IP_ADDRESS>)  45.408 ms
[15:10] <Oleg|percona> 15  * DATAHOP-LTD.edge4.London2.Level3.net (<IP_ADDRESS>)  45.793 ms  45.770 ms
[15:10] <Oleg|percona> 16  eth0.peumo.canonical.com (<IP_ADDRESS>)  45.726 ms  44.252 ms  44.899 ms
[15:10] <Oleg|percona> 17  * * *
[15:10] <Oleg|percona> 18  * * *
[15:10] <Oleg|percona> 19  * * *
[15:10] <Oleg|percona> 20  * * *
[15:10] <Oleg|percona> 21  * * *
[15:10] <Oleg|percona> 22  * * *
[15:10] <Oleg|percona> 23  * * *
[15:10] <Oleg|percona> 24  * * *
[15:10] <Oleg|percona> 25  * * *
[15:10] <Oleg|percona> 26  * * *
[15:10] <Oleg|percona> 27  * * *
[15:11] <Oleg|percona> 28  * * *
[15:11] <Oleg|percona> 29  * * *
[15:11] <Oleg|percona> 30  * * *
[15:11] <Oleg|percona> rvba: Looks like canonical broke the route
[15:11] <Oleg|percona> rvba: Do I right? Network problem on canonical side?
[15:11] <dpm> ok, thanks rvba
[15:13] <rvba> Oleg|percona: Not that I know of… and I can branch your branch without problem.
[15:14] <Oleg|percona> rvba: Can you show me your traceroute to bazaar.launchpad.net?
[15:16] <Oleg|percona> rvba: Hm, now all ok
[15:16] <rvba> Oleg|percona: http://paste.ubuntu.com/745982/
[15:16] <rvba> Oleg|percona: ok, so this was a temporary glitch.
[15:17] <Oleg|percona> rvba: I wait ten minutes before ask, sorry.
[15:17] <rvba> Oleg|percona: no problem man.
[15:17] <Oleg|percona> rvba: Anycase, now all right. Thank you very much!
[15:18] <rvba> Welcome.
[15:44] <graingert> there seems to be an odd bug in the +editpgpkeys page
[15:45] <graingert> when sending a key it claims it will be encrypted with the key sizeR/ID
[15:45] <graingert> however that's my signing key not the encryption key
[15:45] <graingert> I then get a new key encrypted with my encryption subkey
[15:46] <graingert> sorry message*
[15:53] <rvba> graingert: I'm not sure I understand your problem here, do you mind filling a bug with a more precise description of the issue? (https://bugs.launchpad.net/launchpad/+filebug)
[15:53] <graingert> rvba: I submit 4cfcc785e7e9294a84a55160991c1a9f5f6eec4f to the editpgpkeys page
[15:54] <graingert> and get a message saying that I will recieve an encrypted email encrypted with 4096R/5F6EEC4F
[15:54] <rvba> Ok so far.
[15:54] <graingert> when I actually get a message encrypted with 4096R/B6D51144
[15:55] <graingert> because 4096R/5F6EEC4F is sign only
[15:55] <graingert> and  4096R/B6D51144 is my encryption subkey
[15:55] <rvba> Ok, now I get it.
[15:55] <rvba> So, it's worth filling a bug still ;)
[15:58] <graingert> although now I'm getting a worse bug
[15:58] <graingert> http://paste.ubuntu.com/746042/
[15:59] <graingert> is that a crc error on the message
[16:04] <graingert> rvba: https://bugs.launchpad.net/launchpad/+bug/893660
[16:05] <rvba> Thanks for filling a bug graingert!
[16:05] <graingert> np
[16:05] <graingert> any idea about the CRC issue?
[16:06] <graingert> do you get it with that message?
[16:06] <graingert> rvba: ^
[16:06] <rvba> Let me check.
[16:07] <rvba> I get the same message you get graingert.
[16:08] <graingert> okay so launchpad is sending invalid keys
[16:08] <graingert> messages*
[16:08] <graingert> *sigh*
[16:08] <rvba> I think this calls for another bug if you don't mind filling another one.
[16:09] <graingert> it might be because I only have revoked keys in ubuntu's key store
[16:09] <graingert> it may not have picked up the new key
[16:09] <rvba> Did you do that recently?
[16:10] <graingert> yes
[16:10] <graingert> but it should not send invalid messages
[16:10] <graingert> it should check the output to see if the CRC is valid
[16:10] <graingert> I'm now pushing explicitly to ubuntu keyserver
[16:12] <graingert> nope
[16:12] <graingert> still bad
[16:16] <graingert> I'll wait a couple of days
[16:19] <rvba> Good idea, one day should be enough.
[16:47] <_ros_> Hi, I want to know if launchpad has mirrors, at least for the file download and if there is an officia list
[16:58] <cjohnston> How do I add a project to a project group that I am the maintainer of
[16:58] <cjohnston> Not create a new project though, add an already existing project
[17:08] <mansson_> Hi. Is there any launchpadlib example collection anywhere? I'd like to understand how to do a basic search.
[17:28] <jelmer> mansson_: the lptools project has lots of small tools that should be good examples
[17:35] <mansson_> jelmer, thanks.
[17:37] <EvilResistance> who do i bug to remove a project that i own which i want to discontinue?
[17:39] <jelmer> EvilResistance: create a question on the launchpad project https://answers.launchpad.net/launchpad
[17:40] <EvilResistance> bah
[17:40] <EvilResistance> wtf
[17:40] <EvilResistance> glitchy evil computer
[17:40]  * EvilResistance punts his netbook out the window
[17:40] <jelmer> no you didn't, you're still here :)
[17:41] <EvilResistance> jelmer, ZNC ;P
[17:41] <EvilResistance> not even on this system ;P
[18:29] <SpamapS> Hmm, php5 hasn't been package-imported since early in the natty cycle.. http://package-import.ubuntu.com/status/php5.html#2011-10-26 07:51:59.623317 ..
[18:29] <SpamapS> I'm guessing though that this isn't the actual problem..
[18:43] <james_w> SpamapS, I retried it, but it hit another bug that hasn't been root caused yet unfortunately
[18:46] <SpamapS> bzrlib.errors.RevisionNotPresent: Revision<EMAIL_ADDRESS>not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
[18:46] <SpamapS> ?
[18:46] <SpamapS> Thats what I hit when I run it locally
[18:47] <james_w> that's the one
[18:47] <Daviey> SpamapS: bug 888615 ?
[18:48] <james_w> more https://bugs.launchpad.net/udd/+bug/848064
[18:48] <james_w> though it's the same error in both, granted
[18:50] <SpamapS> So..
[18:51] <SpamapS> If I can find that revision and push a branch w/ that rev restored.. the importer might be able to catch up?
[18:53] <james_w> SpamapS, indeed
[18:53] <james_w> I don't know if bzr will fill it in though
[19:08] <det> Is it typical for the build queue to be 17 hours ?
[19:13] <dobey> typical? no
[20:05] <flacoste> det, we are down by 17 builders, they should be back tomorrow
[20:05] <flacoste> a queue builds up whenever this happens
[20:06] <flacoste> some ppa builders are actually "on loan" from hardware enablement
[20:06] <det> Thanks
[20:06] <det> Sucks that this coincides with of this software project :)
[20:07] <det> release of*
[20:47] <jelmer> flacoste: hi
[20:48] <jelmer> flacoste: I'd like to propose a configuration change - but I'm not sure where to do so, and who to discuss it with.
[20:48] <jelmer> urgh, just noticed this isn't #launchpad-dev
[20:50] <flacoste> hi jelmer
[21:07] <Daviey> Hey, i386 PPA buildd's really has an estimated 47 hour queue?
[21:17] <micahg> Daviey: see scrollback from an hour ago
[21:18] <Daviey> micahg: thanks.
[21:18] <Daviey> Really frustrating when we try to use it as a development resource for validation. :)
[22:13] <RainCT> Hey
[22:13] <RainCT> I think I already reported it some time ago, but https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bug/807950 times out all the time here.
[23:24] <Laney> When did Soyuz come into existence?
[23:24] <wgrant> Laney: Ubuntu migrated to it in Feb 2006
[23:24] <Laney> We've written a script to pull down all Ubuntu SPPHs from LP and there is a huge number in 2005-12 — was it then?
[23:24] <Laney> alternatively, what are they? :-)
[23:25] <wgrant> eg.?
[23:25] <Laney> 28568 entries
[23:25] <Laney> was that some kind of preparatory import?
[23:25] <wgrant> Ah, datecreated might be earlier, let me see..
[23:27] <wgrant> It looks like 2005-12-21 was the initial import, and 2006-02-21 was the migration.
[23:28] <Laney> so I should use the SPPH data after that date
[23:28] <wgrant> As part of the migration, all Dapper publications were duplicated for reasons that are to me unknown.
[23:28] <wgrant> Right.
[23:29]  * Laney finds https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-February/000072.html
[23:29] <wgrant> Everything from before 2006-02-21 is imported from dak.
[23:29] <wgrant> Hmm
[23:29] <wgrant> That is interesting.
[23:30] <wgrant> Bah, yes, misread.
[23:38] <tumbleweed> Laney: hrm, when we see 2005-12-21 we could defer to the .changes files
[23:39] <Laney> I think the changesfiles /were/ the canonical source prior to the migration
[23:39] <Laney> so we should just use them up until that date, and the SPPHs thereafter
[23:39] <tumbleweed> even better :)
[23:40] <tumbleweed> although, bug 885541 means we can't see many changes files
[23:40] <wgrant> s/many/some for old security uploads and where people have lied/ but yes.
[23:41] <Laney> mbox ones should be ok though
[23:41] <tumbleweed> ah, actually I think all of those come after that date
[23:41] <wgrant> Right.
[23:41] <tumbleweed> wgrant: turns out it was pretty common for security uploads
[23:41] <wgrant> The imported uploads probably don't have changes file.
[23:41] <wgrant> tumbleweed: Oh yes, almost universal until 2008, I expect.
[23:42]  * tumbleweed sees 569 such uploads
[23:42] <Laney> we could write a script to merge the foo-changes.mbox generated data with the lp stuff
[23:43] <tumbleweed> Laney: we still want lp stuff for breezy and early dapper, for syncs.
[23:43] <Laney> yes, /merge/
[23:45] <mansson_> Hi. Beginner's Question: Why are collections represented by an URL in launchpadlib? I don't get it.  bug.users_affected_collection_link[0].is_team doesn't work. The manual says that I get a person collection. If it is a collection, why cant I index it? What I really want is the importance of a bug, but what is importance an attribute of? It ought to be the list of affected things i.e. a Team - but a Team is a person and p
[23:45] <mansson_> ersons din't have importance ?
[23:46] <wgrant> mansson_: launchpadlib applies a layer of magic on top of the raw API
[23:46] <wgrant> bug.users_affected[0]
[23:46] <wgrant> Drop the _collection_link
[23:46] <wgrant> _collection_link is the link to the collection, not the collection itself.
[23:46] <mansson_> Ah. How ingenious.
[23:47] <wgrant> launchpadlib dereferences foo_collection_link to a collection named 'foo', and bar_link to an object reference named 'bar'.
[23:47] <wgrant> importance is an attribute of bug_task.
[23:48] <wgrant> Bugtasks are the things that are presented in the Affects table on the bug page.
[23:48] <wgrant> They have a target (eg. project, package, or series), status, importance, assignee, milestone
[23:48] <mansson_> Thanks. I think that is all what I needed. Brilliant!
[23:48] <wgrant> You get tasks from bug.bug_tasks


[04:42] <pace_t_zulu> can someone help me find the code responsible for changing screen resolution?
[07:09] <pitti> Good morning
[07:11] <pitti> bryce: can we even be sure that the bug is still the same with 2.6.30 and new libdrm?
[07:11] <pitti> bryce: when I wanted to test the freezes I get on the 945, these new packages change behaviour completely
[07:20] <asac> hi
[07:25] <pitti> hey asac
[08:30]  * pitti hugs seb128
[08:30]  * seb128 hugs pitti
[08:30] <seb128> how are you today?
[08:33] <robert_ancell> seb128: pitti: do you guys have any ideas about bug 322714 and bug 328885.  There seems to be a lot of vague dpkg type bugs in avahi
[08:33] <pitti> seb128: pretty good, and you?
[08:33] <pitti> hey robert_ancell
[08:33] <seb128> hey robert_ancell
[08:33] <robert_ancell> good morning guys
[08:33] <seb128> looking
[08:33] <seb128> pitti: pretty good thanks!
[08:35] <seb128> those seems bugs for mvo
[08:35] <seb128> robert_ancell: the first one seems a local corruption rather than a bug
[08:36] <robert_ancell> seb128: what is the best thing to do with them?  i.e. how should they be marked (I can't see anything avahi specific about them)
[08:36] <seb128> that's a very good question
[08:36] <seb128> I tend to close them or switch them to questions
[08:36] <seb128> which is not really "right" and mvo will not agree with me there
[08:37] <seb128> I tried to argue for getting an "upgrade issues" components
[08:37] <seb128> but other people didn't like the idea
[08:37] <robert_ancell> I want to assign them to "dkpg" or something
[08:37] <seb128> other people being mvo and pitti I think ;-)
[08:37] <seb128> yeah, you can do that too
[08:38] <robert_ancell> (but that feels like passing the buck.  A bit like assigning to the great black hole of compiz)
[08:38] <robert_ancell> so, do you close as "invalid"?
[08:38] <seb128> convert it to a question saying that's a local issue and not a software bug
[08:39] <seb128> that's what I do usually
[08:39] <seb128> or invalid
[08:39] <mvo> robert_ancell: I analyized a bunch of them
[08:39] <mvo> the one: 322714
[08:39] <seb128> question let the possibility that answer tracker guys will give advices to the guy on how to sort the issue
[08:39] <mvo> dpkg complains that its missing a final newline, so I usually ask for the file
[08:39] <mvo> and typically it contains either garbage or a bit flip error
[08:40] <robert_ancell> mvo: hey
[08:40]  * pitti wishes it was easier to see the actual problem in the plethora of logs
[08:40] <mvo> robert_ancell: hi
[08:40] <mvo> pitti: good point
[08:41] <pitti> robert_ancell: I'd set 322714 to incomplete, asking for an fs check and attaching the .list file in question (sounds like corrupted fs or full disk to me)
[08:41] <pitti> seb128: I still stand to this opinion
[08:41] <pitti> generating large amounts of bug spam and then directing it into a black hole where nobody looks doesn't help anyone
[08:41] <seb128> pitti: which one? not having an upgrade issues component?
[08:42] <seb128> pitti: because that one is clearly an avahi bug? *g*
[08:42] <pitti> either we make those reports better, or we stop collecting them
[08:42] <mvo> it should more be a package install/upgrade component
[08:42] <seb128> stop collection them
[08:42] <robert_ancell> ok, but when you get the .list file back what can we do with it?
[08:42] <seb128> I'm that near > < of adding a piece of code which close all of those on GNOME packages
[08:42] <pitti> robert_ancell: see if it's obviously broken/truncated
[08:43] <seb128> I've enough of getting 95% of useless bugs assigned on the wrong component
[08:43] <pitti> seb128: I think ignoring/not collecting them is a valid option
[08:43] <mvo> robert_ancell: it should contain just file names, it will probably contain a bunch of garbage in between. clear sign of either filesystem correuption, memory corruption or (heaven forbit) a bug in dpkg
[08:43] <robert_ancell> pitti: and if it is, all we can say is your system is corrupted, please delete and reinstall that package?
[08:43] <pitti> robert_ancell: I usually ask people to start the rescue system from grub and then start fsck
[08:43] <seb128> reinstalling the package will not solve the corruption issue
[08:43] <mvo> I think not collecting them is not a good option
[08:44] <pitti> mvo: we shouldn't ask people to file those reports if we are just going to ignore them
[08:44] <seb128> we already had this discussion, we will just never agree
[08:44] <pitti> it's raising false expectations and just leads to frustrations like "ubuntu bug reports are never looked at"
[08:44] <robert_ancell> I feel if I was sending in the report a link to a "fixes for dpkg issues" wiki page would make me happy
[08:44] <mvo> I don't want to ignore them either, I do check a lot of them and act.  half of them a bad. but the other half is not
[08:45] <seb128> what can we do to reduce this bad half to be less than that?
[08:45] <pitti> I'd like to see some more specific data collection from them, so that we can sanely auto-duplicate them
[08:45] <mvo> robert_ancell: there is a fsck and fix broken package option in friendly-recover (the menu in the rescue option in grub)
[08:45] <pitti> and then just look at the ones which have several dupes (the real ones)
[08:45] <seb128> pitti: it's hard to autoduplicate random corruption
[08:45] <pitti> seb128: right, those fall into the "ignore because of missing duplicates" part
[08:45] <seb128> robert_ancell has a good point, we should have a stock reply and wiki page about corruption
[08:45] <pitti> but if a package's postinst fails with exit status 99 for 50 people, that's something worth looking at
[08:46] <robert_ancell> mvo: I haven't been in grub for a while now it seems.  Is there a user-friendly wiki page about how to use it?
[08:46] <mvo> I'm fine with collecting them into a special category as long as we keep collecting them
[08:46] <mvo> robert_ancell: I don't iknow (I think its not)
[08:46] <seb128> pitti: when you know what status nn means, 90% of the time it's something crashing but you don't know what, though mvo probably fixed that one now
[08:46] <mvo> I mean, it sounds silly to me that we collect bugs that there are typos in the help widnow of synaptic, but we ignore errors that make package installation impossible at the users machine and say this is not a bug
[08:46] <seb128> ie we get lot of random issues being scrollkeeper-update crashing
[08:47] <pitti> seb128: but if it affects 50 people in our testing community, it's _still_ worth looking at it surely? (even if it is mistitled/misassigned)
[08:47] <mvo> it will attach the dmesg logs now
[08:47] <seb128> mvo: but it's not a bug, it's an installation issue
[08:47] <mvo> right, but it still deserves attention, no?
[08:47] <mvo> and often its bugs
[08:47] <seb128> we already had this discussion
[08:47] <seb128> I agree on that
[08:48] <seb128> I just don't think forcing me to keep those bugs on my component work
[08:48] <mvo> thats ok
[08:48] <seb128> I just close them now because you don't force things over people when that's not something they are responsive for there
[08:48] <pitti> no clue about 328885, this looks indeed like a weird apt/debconf issue
[08:48] <seb128> ie I've no clue what to do about dpkg index corruptions
[08:48] <mvo> so what should we do a) have a discussion (with more people) at uds again b) discuss on the ML c) just move them all to a new category?
[08:48] <seb128> and I don't care enough to keep those on my components
[08:49] <seb128> that would work for me
[08:49] <pitti> seb128: those aren't really the ones worth looking at indeed, which is why I'm eager to get more specific data into the bug reports
[08:49] <seb128> but you and pitti already expressed that you are against reassigning those to an "upgrade issue" place
[08:49] <mvo> yeah, 328885 is one of the useless ones :/
[08:49] <seb128> which means you force them at the wrong place where it will angry the maintainer only and not being worked anyway
[08:50] <pitti> seb128: I didn't say _re_assigning is a bad thing (although I'd prefer "invalid")
[08:50] <pitti> seb128: I'm just against reporting them all against a "package failures" project initially
[08:50] <seb128> pitti: where do we reassign those bugs? ie the avahi one
[08:50] <pitti> since that will just be one honking big mess nobody ever looks at
[08:50] <pitti> seb128: perhaps we misunderstood each other then
[08:50] <seb128> and why wouldn't we have some bugsquad ressource dedicated to triage that component ?
[08:51] <pitti> ^ no reason not to, we just don't have it
[08:51] <seb128> you seem to have the illusion that people actually triage those when they are on random components
[08:51] <seb128> looking at desktop packages bug triagers just ignore those
[08:51] <seb128> because they don't know what to do
[08:51] <pitti> well, I triage them on my pacakges
[08:52] <pitti> but I don't think that everyone does, and that's fine
[08:52] <pitti> seb128: what are you trying to convince me about?
[08:52] <seb128> pitti: that letting them assigned to random component is not efficient
[08:52] <pitti> (and no, I don't think we can tell the community "please go triage those 20.000 bugs against "install-failures", that won't work)
[08:52] <seb128> and that we should have an "upgrade issue" component
[08:53] <pitti> seb128: as I said, I can live with _re_assigning
[08:53] <pitti> just not with apport reporting them all against that component initially
[08:53] <seb128> ok, we started wrongly
[08:53] <seb128> let's restate what the problem is and what we need to do
[08:53] <pitti> if you look at a bug, say "oh crap, NFC", and reassign, that's fine
[08:54] <pitti> but then you looked at it and determined that you didn't see that issue 30 times already, and it's rarian which segfaults for half of the people
[08:54] <seb128> - we need an easy way to move the random corruption bugs out of the way
[08:54] <pitti> "invalid"?
[08:54] <pitti> (or "wontfix")
[08:54] <robert_ancell> re-assigning would make me happy as long as I could attach some sort of clue to the reporter on what they should do
[08:54] <pitti> reassigning to a garbage dump is not ideal, but WFM, too
[08:54] <seb128> ok, so course of action
[08:55] <seb128> - get a stock reply and wiki page for corruption cases
[08:55] <pitti> +1
[08:55] <seb128> and use those to close those bugs
[08:55] <robert_ancell> +1
[08:55] <didrocks> seems a good way to track them (hello o/)
[08:55] <seb128> - improve the information collecting process and auto-duplication
[08:56] <seb128> can we automatically detect and tag in a special file conflicts?
[08:56] <seb128> can we automatically detect and tag in a special way file conflicts?
[08:56] <seb128> those are usually valid and useful bugs
[08:56] <seb128> mvo: ^
[08:56] <pitti> right, and they sound like something we should be able to detect automatically
[08:56] <mvo> I think we can detect it in the error message
[08:57] <pitti> also, I'd really like to avoid filing a package install bug if something in postinst segfaulted, since that should rather create a proper .crash file
[08:57] <mvo> maitnainer script failures is something we can probably detect relatively easily as well
[08:57] <seb128> where do we keep note of those action items?
[08:57] <mvo> that would mean to enable apport again for all upgrades (stable->stable too)?
[08:58] <seb128> ok, so let me take notes
[08:58]  * pitti edits Bugs/Responses
[08:58] <seb128> mvo, pitti, robert_ancell: you agree with closing corruption bugs are invalid?
[08:58] <pitti> seb128: fine for me
[08:59] <seb128> are -> as
[08:59] <mvo> I'm still not comfortable with it, those might be dpkg errors (rare ones). but yeah, its ok with me
[08:59] <seb128> mvo: other option is to get a "upgrade issues" component
[08:59] <asac> what are "corruption" bugs? bad backtraces?
[08:59] <seb128> and reassign those there
[08:59] <robert_ancell> seb128: yes, as long as users get some info on how to save their system (i.e. don't think we're telling them it's not a problem)
[08:59] <seb128> asac: no, dpkg status corrupted for example
[08:59] <asac> oh. yeah
[08:59] <seb128> asac: or weird dpkg errors about new lines, or parsing issues
[08:59] <mvo> seb128: lets call it pkg failures or something, its not limited to upgrades IME
[09:00] <seb128> mvo: works for me
[09:01] <asac> seb128: do we have webkit ephy somewhere?
[09:01] <asac> (recent)
[09:01] <seb128> mvo: do you want a bug about the "would be nice to autotag file conflicts"?
[09:02] <seb128> asac: no but I think there is a ppa and the packaging is in debian pkg-gnome svn
[09:02] <YokoZar> mvo: I've been looking through the code of gnome-app-install and I have a design for how I'd like to extend it to support removing Wine applications.  Mind if I run it by you?
[09:02] <mvo> seb128: yes please
[09:02] <YokoZar> Also good evening ;)
[09:02] <YokoZar> Or morning ;)
[09:03] <asac> seb128: ok. i think i am member of the webkit team in launchpad ... let me check what those folks are doing actually
[09:03] <mvo> YokoZar: good evening
[09:03] <seb128> mvo: where should I open this bug?
[09:03] <seb128> mvo: apt?
[09:04] <mvo> seb128: yes
[09:05] <pitti> seb128, mvo, robert_ancell: first cut at a stock response: https://wiki.ubuntu.com/Bugs/Responses#Package%20installation%20failure
[09:06] <seb128> pitti: looks a good start to me thanks
[09:06] <robert_ancell> pitti looks good
[09:07] <bryce> pitti: I've tested with both 2.6.28 and 2.6.30 and have not noticed a difference in behavior
[09:08] <pitti> bryce: ok, good
[09:10] <robert_ancell> here's another question for everyone:  Bug 361622 requests that avahi provide a firewall rule - this seems crazy to me, if anything the firewall should have a default rule for avahi.  Do others agree?
[09:13] <seb128> mvo: bug #368435
[09:13] <mvo> thanks seb128
[09:14] <seb128> mvo: thank *you* and sorry for ranting again there
[09:14] <seb128> mvo: good that we are moving in a way where everybody is happy about the change though
[09:14] <mvo> seb128: yeah
[09:15] <didrocks> robert_ancell: you can provide in application packages ufw rules, which are activated or not considering the local policy. So, it doesn't sound too crazy for me :-)
[09:15] <robert_ancell> didrocks: thanks, not very familiar with ufw.  Will confirm it then
[09:16] <seb128> robert_ancell: talk to jdstrand on IRC when he's around
[09:16] <seb128> robert_ancell: I think the idea is that packages are shipping their firewall rules, ie when you install avahi that's to get it used and the firewall rule to allow that would be there
[09:17] <didrocks> seb128: exactly. I can handle it. I did for a bunch of packages when jdstrand asked some help for intrepid
[09:17] <robert_ancell> cool, thanks guys
[09:18] <didrocks> seb128: FYI, the desktop team presentation tomorrow at OpenWeek will be largely inspired by your last talk :)
[09:18] <seb128> didrocks: good ;-)
[09:19] <seb128> robert_ancell: you got a reply on this rhythmbox codec bug btw
[09:21] <seb128> robert_ancell: I'm looking the glade upgrade bug
[09:21] <seb128> robert_ancell: no need to nominate bugs for karmic that early in the cycle
[09:21] <robert_ancell> seb128: ok, wasn't sure when to do that.
[09:21] <seb128> you also want to add a debdiff for the update to the bug
[09:21] <robert_ancell> seb128: excellent, the rb response reproduces for me
[09:21] <seb128> gzipped if required
[09:22] <robert_ancell> seb128: I couldn't remember how to make the debdiff...
[09:22] <seb128> it makes review easier since the diff is on the bug
[09:22] <seb128> debdiff *.dsc
[09:22] <robert_ancell> thanks
[09:22] <seb128> in the dir where you have the jaunty version and your update
[09:24] <robert_ancell> seb128: there now
[09:24] <seb128> robert_ancell: thanks
[09:25] <robert_ancell> seb128: should have gzipped it as you said though...
[09:25] <seb128> robert_ancell: do you already have enough work for tomorrow?
[09:26] <robert_ancell> seb128: I have various stuff to do.  If there's something you want me to look at pass it over
[09:26] <seb128> robert_ancell: bug #368252 assigned to you
[09:26] <robert_ancell> (I've never found nothing to do :) )
[09:26] <seb128> robert_ancell: that seems another totem-pl-parser issue
[09:27] <seb128> not a high priority issue, but in case you get bored ;-)
[09:27] <seb128> the user claims that was working in intrepid
[09:40] <didrocks> seb128: do you me to rename jaunty/karmic in my waiting to be sponsored bug (as karmic repos are opened now)?
[09:40] <seb128> didrocks: feel free to do that
[09:41] <seb128> didrocks: I'm still on jaunty and trying to deal with the current bug flood so those uploads will wait
[09:41] <didrocks> seb128: oki, if I can do anything to help, do not hesitate (even if I'm quite busy now until middle of may ;))
[09:41] <pitti> just in case you missed it in -devel: karmic is open, go wild!
[09:42] <seb128> pitti: apparently we have some crack addicts, didrocks is already on it ;-)
[09:42] <didrocks> seb128: :-)
[09:42] <pitti> hehe
[09:42] <pitti> go didrocks!
[09:42]  * seb128 stills dealing with jaunty bugs
[09:42] <didrocks> pitti: just began ^^
[09:43] <pitti> please everyone remember to sub to karmic-changes@
[09:43] <didrocks> pitti: already done this morning :D
[09:43]  * pitti uploads new hal and dk-power
[09:44] <Tm_T> pitti: so you can spam our mailboxes down?
[09:44] <pitti> muhaha
[09:44] <Tm_T> "busted"
[09:44]  * didrocks is setting up a filter right now :)
[09:44] <Tm_T> I revealed your evil plan!
[09:44] <pitti> I have about 20 "fix committed" bugs, I want to clean my +assignedbugs list
[09:45]  * seb128 is always impressed by how early people switch to new crack ;-)
[09:45] <pitti> seb128: I wonder if you would mind if I'd upload the new gnome-power-manager with DK-power support
[09:45] <seb128> I must be the only of to still have a stack of jaunty bugs to get fixed
[09:45] <seb128> pitti: not at all, as said I'm still stucked in jaunty mode there ;-)
[09:46] <seb128> we have some evolution crasher issues
[09:46] <seb128> and lot of desktop bugs coming
[09:46] <pitti> seb128: please don't put too much effort into jaunty SRUs
[09:46] <seb128> feel free to upload anything you want to karmic
[09:46] <seb128> pitti: we got at least 15 people complaining about evolution calendar hanging evo since jaunty
[09:46] <pitti> yeah, I heared about that
[09:46] <pitti> that's indeed an important thing
[09:46] <seb128> pitti: I want to get that fixed, then I can switch to karmic
[09:46] <mvo> pitti: could you nag about about a sru approval for update-manager again? sorry that its such a sru intensive beast
[09:47] <pitti> seb128: I just don't think we should do a lot of work wrt. uploading all the point releases unless they fix something truly critical
[09:47] <pitti> mvo: of course
[09:47] <seb128> pitti: I'm almost done with srus on my list, I don't intend to spend much time on jaunty
[09:47] <mvo> thanks
[09:47] <seb128> pitti: right
[09:47]  * pitti hugs seb128, seems we're on the same page
[09:47] <seb128> pitti: karmic will be busy enough
[09:47]  * seb128 hugs pitti
[09:48] <didrocks> mvo: I add a karmic task to bug #361053 too
[09:49] <mvo> didrocks: ok
[09:49] <seb128> didrocks: don't
[09:49] <didrocks> oupsss
[09:49] <seb128> jaunty-updates are pocket copied to karmic
[09:50] <didrocks> oh, didn't know that :/ It's done until which milestone?
[09:50] <seb128> it's done when the versions are identic
[09:51] <seb128> in jaunty and karmic that is
[09:51] <seb128> it makes sense to have only one upload
[09:51] <pitti> yes, I regularly do that with SRUs
[09:51] <didrocks> ok, sorry, I can't revert the release nomination. I will just put a comment, so...
[09:52] <seb128> didrocks: that's ok, it's a detail
[09:52] <robert_ancell> mvo: here's one you might have an idea about: bug 291484
[09:52] <seb128> didrocks: just no need to create paper work where it's not required
[09:52] <didrocks> seb128: good to know, though :)
[10:09] <robert_ancell> see you all tomorrow
[10:10] <seb128> robert_ancell: good evening, see you tomorrow
[10:59] <pitti> didrocks: your gnome-terminal upload refers to LP: #572414, that doesn't exist
[11:00] <didrocks> pitti: let me check if I just mixed with the corresponding GNOME bug
[11:00]  * didrocks is confused :/
[11:00] <didrocks> pitti: it's bug #331295
[11:00] <didrocks> pitti: do you want I change it?
[11:01] <pitti> this doesn't really match our SRU criteria, and the session fix is quite intrusive
[11:01] <pitti> didrocks: please; also add a real changelog line for it which refers to the bug
[11:01] <pitti> the "new upstream release" one should just close the sponsoring bug
[11:01] <didrocks> pitti: ok, I am quite unconfortable to add lines that are not on NEWS file, but I will :)
[11:02] <didrocks> pitti: do you think the gnome-session handling goes against the SRU criteria.
[11:02] <pitti> I don't think bug 333603 is of any SRU concern
[11:02] <pitti> session saving is _terminally_ broken in current gnome
[11:02] <james_w> heh :-)
[11:03] <pitti> and changing that behaviour in an SRU is not really appropriate IMHO
[11:03] <pitti> I'd upload that to karmic and consider it done
[11:03] <didrocks> pitti: ok, so, we just postpone in a regular update to karmic :)
[11:03] <crevette> hi gentlemen
[11:03] <didrocks> hey james_w ;)
[11:03] <didrocks> and crevette
[11:03] <crevette> sorry for not very active theses days
[11:03] <crevette> :)
[11:03] <crevette> +being
[11:04] <james_w> salut
[11:05] <pitti> didrocks: ok, thanks
[11:09] <pitti> ember: please prepare bugs for SRUs properly (brasero)
[11:09] <pitti> fixing bugs to be SRU compliant is an awful lot of work for me
[11:11] <didrocks> pitti: done. I removed also the release tag in bzr and changed the bug title. Sorry for the extra useless work in candidating it for SRU
[11:11] <pitti> didrocks: n/p; just be very conservative about SRUs
[11:11] <didrocks> pitti: understood
[11:14] <huats> hello everyone !
[11:22] <pitti> mvo: wow, fixing all kinds of random broken universe stuff?
[11:22]  * pitti wishes there was a way to make the upgrade more robust instead of forcing us to do those updates
[11:24] <mvo> pitti: yeah, I was going over the apport-package list and noticed those issues (some pretty simple to fix)
[11:24] <mvo> pitti: and yes, its anoying :/
[11:25] <pitti> mvo: what concerns me is that those aren't really "simple fixes"
[11:25] <pitti> once you do them, you need to feed them to Debian, get them applied, fix them in karmic, etc.
[11:25] <pitti> those aren't just "fire and forget" updates
[11:25] <mvo> pitti: I have some hopes for the aufs based upgrader, but that will still mean that a broken package would prevent the upgrade (it would just be a rollback)
[11:25] <mvo> pitti: right
[11:25] <pitti> and I wouldn't like you to get even more swamped in this stuff
[11:25] <mvo> pitti: yeah, the cost is relatively high :(
[11:26] <pitti> mvo: we don't do auto-upgrade tests with universe?
[11:28] <mvo> pitti: we have code for this, it just takes ages. I did a ugprade with a image of ~15.000 packages installed, dpkg was 500mb real mem
[11:28] <mvo> and reading the file list took ages
[11:28] <mvo> it whole thing lastet a couple of days
[11:29] <mvo> but we definitely should do more for karmic (there is a spec about a ec2 based tester planned)
[11:29] <pitti> I thought u-m already does some tricks to continue the update if there is a single broken package, or by and large ignore file conflicts
[12:03] <mvo> pitti: it does ignore all file conflicts and it will continue on error, but that only help if the error is not too deep down in the dependency chain
[12:05] <mvo> why was the gnome-terminal jaunty-proposed upload rejected?
[12:14] <pitti> wrong bug attribution in changelog, and general unsuitability for SRU
[12:14] <pitti> (I followed up in the bug)
[12:17] <mvo> aha, ok
[12:17] <mvo> I kind of assumed gnome updates where ok, but I'm fine with that
[12:18] <pitti> actually we only had this exception in hardy, we just continued to practice it in intrepid
[12:18] <pitti> and I'm still generally fine with it, but this one was a bit too intrusive for my taste
[12:18] <pitti> point releases should fix bugs, not fundamentally change behaviour
[12:46] <jtholmes> popey, are you on
[12:59] <popey> jtholmes: hi
[13:00] <jtholmes> popey, good day i just discovered last night that you are the screencasts person, nice job btw you and your team
[13:01] <popey> where unfortunately the team has been somewhat dormat for a while
[13:01] <popey> needs reviving
[13:01] <jtholmes> i am having problems downloading and saving any of the screencasts and wondered what i am doing wrong
[13:01] <popey> any in particular?
[13:02] <jtholmes> let me get the  name
[13:02] <jtholmes> lets start with installing ubuntu part 1
[13:02] <popey> they're quite old and could do with updating :)
[13:02] <popey> which is on my todo list
[13:03] <jtholmes> yes but they do server a very useful purpose
[13:03] <jtholmes> I click on the download 1280X720 vorbis... and it plays but will not download any ideas
[13:03] <popey> http://static.screencasts.ubuntu.com/
[13:03] <popey> grab them from there
[13:04] <jtholmes> ah, oh let me try that
[13:04] <popey> http://static.screencasts.ubuntu.com/20070909_installing_ubuntu_part_1_theora_400k_vorbis_1280x720.ogg
[13:04] <popey> thats probably the one you want
[13:05] <jtholmes> good thanks, one more thing have you done a wubi sc
[13:05] <popey> no
[13:05] <jtholmes> ok i will let you get back to your work, thanks
[13:05] <popey> np
[13:10] <jtholmes> popey question pls
[13:10] <popey> fire away
[13:11] <jtholmes> at static...  it still only plays doesnt download what am i doing wrong using FF
[13:11] <popey> right click, save link as
[13:12] <jtholmes> so then the link is saved but how do i then get the contents to my machine
[13:12] <popey> sorry, save target as :)
[13:12] <jtholmes> ok let me try thx
[13:13] <popey> np
[13:15] <jtholmes> save link as is doing it not familiar with that, interesting thanks again i have a situation where i cant go to the inet to get it must have it locally appreciate you help
[13:17] <popey> no problem
[13:52] <seb128> hey rickspencer3
[13:52] <rickspencer3> seb128: nice to see you today
[13:53] <seb128> nice to see you too!
[13:53] <seb128> did you have a good trip back in the us?
[13:53] <rickspencer3> yes
[13:53] <seb128> good ;-)
[13:53] <pitti> hey rickspencer3
[13:53] <rickspencer3> I stopped in Washington D.C. to visit my new nephew
[13:53] <pitti> rickspencer3: enjoyed the long weekend?
[13:53] <rickspencer3> yes
[13:53] <seb128> excellent
[13:53] <rickspencer3> I love D.C. it is a wonderful city
[13:54] <pitti> hah, /me runs 2.6.30rc3, -intel 2.7.0 and UXA now
[13:54] <pitti> let's see where this leads me to
[13:54] <rickspencer3> fortunately, my sister in law clearly did not want company, so had plenty of time to sight see and such
[13:54] <rickspencer3> pitti: thanks for that
[13:54] <rickspencer3> I hope it works
[13:54] <pitti> rickspencer3: I survived the first 5 minutes ;)
[13:54] <pitti> rickspencer3: anyway, quick update on the 965 issue
[13:54] <rickspencer3> I've seen a couple of bugs related to freezes on i945 too :(
[13:55] <seb128> pitti: interesting but bryce_ was trying to get the hang using a virtual setting yesterday
[13:55] <pitti> rickspencer3: meeting on Friday didn't yield anything significant
[13:55] <pitti> seb128: right
[13:55] <seb128> and seems to confirm that it workaround the bug
[13:55] <seb128> at least as said I'm using a virtual setting and never got any issue
[13:55] <pitti> rickspencer3: setting a virtualsize by default sounds like a promising workaround right now
[13:56] <rickspencer3> hmmm
[13:56]  * seb128 notes that I suggested that some weeks ago
[13:56] <rickspencer3> seems hacky to me without knowing the root cause
[13:56] <seb128> rickspencer3: disabling compiz is hacky too ...
[13:56] <rickspencer3> seb128: good point
[13:56] <pitti> if we can do that only on the 965, it's acceptable IMHO
[13:56] <pitti> it's not acceptable to set it as default on all intel chips, of course
[13:56] <seb128> what are the drawback of that?
[13:56] <seb128> it allows to use multiple screen too
[13:56] <pitti> bryce and I had a quick discussion of that, he wanted to prepare a test package and toss that back to upstraem
[13:57] <pitti> seb128: we don't know what it breaks on other chipsets
[13:57] <rickspencer3> are they still trying to pursue the root cause though?
[13:57] <seb128> I meant on 965
[13:57] <pitti> rickspencer3: not really, at least not on stuff which can't be reproduced on 2.7.0/uxa
[13:58] <rickspencer3> so basically exa is a lost cause in their mind, and we need to mitigate until we can get users to uxa?
[13:58] <pitti> right
[13:58] <pitti> so we'll probably end up with keeping a workaround for jaunty
[13:58] <pitti> like setting virtualsize or whatever we come up with
[13:58] <pitti> right now we have no clue _why_ it works
[13:59] <rickspencer3> in a way, we've worked around it now
[13:59] <pitti> (or whether it works for everyone, thus creating the test package)
[13:59] <pitti> unfortuantely, my guess with the pipe underrun patch was wrong
[13:59] <pitti> it was a shot in the dark only, but at least worth trying
[13:59] <rickspencer3> we should discuss whether we should make a change, or just share how to workaround?
[14:00] <pitti> rickspencer3: let's give this some more testing days with a new package with vsize
[14:00] <rickspencer3> I'm a bit uneasy about changing people's xorg.conf now that it's in the wild
[14:00] <rickspencer3> pitti: ack
[14:00] <pitti> rickspencer3: nooo
[14:00] <pitti> rickspencer3: I mean changing the driver to _default_ to vsize 4096 by default on i965
[14:00] <rickspencer3> oh
[14:00] <rickspencer3> ok
[14:00] <pitti> (or 2048, or whatever turns out to be best)
[14:00] <rickspencer3> that makes much more sense
[14:00] <pitti> changing xorg.conf in an update -> impossible
[14:01] <rickspencer3> heh .. update manager just opened :)
[14:01] <rickspencer3> pitti: thanks for driving this
[14:01] <rickspencer3> and helping bryce
[14:02] <pitti> well, I couldn't do a lot, just throw in some ideas and prod some people
[14:02]  * pitti hugs bryce
[14:02] <rickspencer3> It sounds like changing the default virtual size in the driver would make it more robust in any case
[14:02] <pitti> well, we don't know for sure yet, but we have two positive results
[14:02] <pitti> I'd like to see that being confirmed by the other testers
[14:03] <rickspencer3> I agree with seb128 though, it seemed likely from when we were first collecting data about the bug
[14:03] <rickspencer3> I'll be glad to test bryce's patch later today
[14:04] <pitti> rickspencer3: no patch yet, we just talked about it
[14:04] <rickspencer3> I know
[14:04] <pitti> rickspencer3: but you can set VirtualSize manually to test
[14:04] <kenvandine_wk> hey rickspencer3
[14:04] <rickspencer3> kenvandine_wk: hi
[14:04] <rickspencer3> good morning
[14:04] <pitti> I need to go to a doctor appointment now
[14:04] <pitti> I should be back well before the meeting
[14:04] <rickspencer3> pitti: let me know what to do to help
[14:04] <pitti> cu!
[14:04] <rickspencer3> laters! and thanks again
[14:05] <rickspencer3> so much email!
[14:05]  * rickspencer3 gets shovel from shed
[14:05] <seb128> rickspencer3: are you subscribed to bug emails too?
[14:06] <rickspencer3> seb128: I am subscribed to many bugs, yes
[14:06] <rickspencer3> if that's what you mean
[14:06] <seb128> ok, because the week after a new version is always crazy
[14:07] <seb128> I meant rather subscribed to ubuntu components
[14:07] <seb128> ie any source package will generate lot of bugmails this week
[14:08] <rickspencer3> seb128: no, I don't subscribe to components
[14:08] <seb128> ok
[14:08] <rickspencer3> I can only imagine what it's like for you at this point
[14:09]  * kenvandine_wk hugs pitti's mail filters :)
[14:09] <rickspencer3> seb128: are there packages that you think I should be subscribed to? I thought subscribing to the whole ubuntu desktop would be a bit much
[14:10] <seb128> rickspencer3: not really no, I guess you have enough on your plates already and there is no real point for you to read bugs emails now
[14:10] <seb128> ie there is nothing urgent for karmic which just started and jaunty is stable now
[14:11] <rickspencer3> I do review all the change mail for Jaunty
[14:11] <rickspencer3> there is a lot more than I thought there would be
[14:11] <seb128> it's always that busy
[14:12] <seb128> there is quite some bug fixes that we want but where the freeze blocked us
[14:12] <rickspencer3> mm
[14:12] <seb128> so we tend to queue those and upload just after stable
[14:12] <rickspencer3> seems that we are not necessarily the most active team in the proposed changes
[14:12] <seb128> and still so issues not raised before but showing in post stable feedback
[14:13] <seb128> so -> some
[14:13] <rickspencer3> I'm still learning the whole release process, it will be another month until I've had one release under my belt, and that will only be one release :)
[14:14] <seb128> "not the most active team"
[14:14] <rickspencer3> make me grateful to be on a such a great team
[14:14] <seb128> that's good ;-)
[14:14] <seb128> that means that we are not the team with all the bugs ;-)
[14:14] <rickspencer3> heh
[14:15] <seb128> for my part I'm mostly done with jaunty updates
[14:15] <seb128> I usually spend the freeze time
[14:15] <seb128> and the week before +1 opening
[14:15] <seb128> on stable updates and then switch to the new version
[14:15] <seb128> ie karmic just opened today
[14:33]  * rickspencer3 is down to 431 unread emails :'(
[14:37] <Ampelbein> seb128: hi. can you sponsor bug 366723?
[14:37] <seb128> Ampelbein: hi, will do when I start on karmic uploads
[14:37] <Ampelbein> ok
[14:37] <D0pamine> hai all
[14:44] <seb128> mvo: hum, the python-apt api changed?
[14:45] <seb128> mvo: is there an equivalent to sources.Binaries now?
[14:45] <seb128> sources = apt_pkg.GetPkgSrcRecords()
[14:45] <seb128>     sources.Restart()
[14:45] <seb128>     sources.Lookup(package)
[14:45] <seb128>     binaries = sources.Binaries
[14:45] <seb128> mvo: ^ that's what I was doing
[14:47] <mvo> this bit should not have changed in ages, let me check
[14:48] <seb128> mvo:
[14:48] <seb128>     binaries = sources.Binaries
[14:48] <seb128> AttributeError: Binaries
[14:48] <seb128> mvo: is what I get on jaunty
[14:48] <seb128> that was working in intrepid
[14:49] <mvo> seb128: what python-apt version do you run? that seems to work for me
[14:49] <seb128> ii  python-apt                                 0.7.9~exp2ubuntu10                   Python interface to libapt-pkg
[14:50] <seb128> hum
[14:51] <seb128> mvo: ok, that's an error in my code then
[14:51] <mvo> seb128: I tried: http://paste.ubuntu.com/160023/
[14:51] <seb128> mvo: yeah, I've a source package listed in my table which is not in jaunty
[14:51] <seb128> the error is not obvious though
[14:51] <mvo> seb128: yeah, the error sucks
[14:51] <seb128> mvo: sorry for the noise, thanks for looking into it
[14:52] <mvo> Lookup() will return a bool if it was successful or not
[14:52] <mvo> seb128: no problem
[14:52] <mvo> (re: noise :)
[14:52] <seb128> right, I don't check the return code
[14:52] <seb128> will teach me to write quick and ugly code
[14:52] <seb128> that's to list versions of GNOME packages newer in debian
[14:52] <seb128> to now what needs to be merge in karmic
[15:33] <pitti> hello again
[15:33] <pitti> kenvandine_wk: are they useful to you? :-)
[15:34] <kenvandine_wk> pitti: they?
[15:34] <pitti> kenvandine_wk: mail filters
[15:34] <kenvandine_wk> oh
[15:34] <kenvandine_wk> hehe
[15:34] <kenvandine_wk> yeah
[15:34] <kenvandine_wk> very
[15:34] <kenvandine_wk> i recreated them all in evo though
[15:34] <kenvandine_wk> :)
[15:34] <kenvandine_wk> but used the same critiria  you did
[15:35] <kenvandine_wk> would have taken me months to figure out what to do with stuff without your guide :)
[15:35] <kenvandine_wk> of course the launchpad headers rock!
[15:37] <popey> vuntz: do you have a moment to explain what the blocker on http://bugzilla.gnome.org/show_bug.cgi?id=346162 is?
[15:45] <pitti> nice, two of my u1 filed bugs got closed as fixed now, and three more triaged
[15:46] <pitti> . o O { gosh, compiz with uxa/dri2 is FUN! }
[15:46] <tedg> popey: I'm not sure, but if I was to guess I'd guess the issue is XEmbed going across screens, which is how the notification area is implemented.
[15:48] <popey> thanks for the prompt reply tedg, I have a frustrated user in #ubuntu-uk who is willing to do whatever testing is necessary to help move this bug along. He uses 4 screens on two cards and would dearly love this to work. Is there anything he/we can do?
[15:48] <popey> he obviously realises that 4 screens is something that the xorg devs may not have access to
[15:51] <tedg> popey: I don't think so, I think this may be an X limitation.  There is a KDE proposal to change the notification area spec to use DBus instead of XEmbed that will probably hit KDE for 4.3....  but I haven't seen any GNOME folks reply to the thread.
[15:53] <popey> tedg: thats a shame. He tells me that other options such as "stalonetray" (in the repo) works, would that be one that is DBus based then?
[15:53] <vuntz> popey: the blocker on my side is time & difficulties to test
[15:54] <popey> hi vuntz
[15:54] <hggdh> question: having had my first debdiff approved, I found myself receiving about 20 emails from Rosetta complaining about translations. Is this normal?
[15:54] <vuntz> popey: the annoying thing is that it might only be a tiny detail that is wrong :/
[15:54] <seb128> hggdh: yes
[15:54] <seb128> hggdh: rosetta bug
[15:55] <popey> vuntz: would it be worth trying to raise the profile of that bug, to see if any other developers are able to look at it, i.e. have time and equipment?
[15:56] <hggdh> seb128, thanks. So I can filter to trash without any guilt, correct?
[15:56] <seb128> hggdh: yes
[15:56] <hggdh> thanks
[15:56] <seb128> you're welcome
[15:58] <vuntz> popey: what do you mean with "raise the profile"?
[15:59] <popey> well if you dont have the time/equipment to resolve the issue, perhaps someone else might?
[16:00] <vuntz> popey: other developers would fix the bug if they were hitting it
[16:00] <vuntz> (since it's a pretty annoying one, I'd say)
[16:00] <popey> true
[16:00] <vuntz> popey: so I don't quite know what we can do to raise the profile
[16:03] <popey> ok, thanks vuntz / tedg for taking the time to talk to me about it, it's appreciated
[16:13] <rickspencer3> hi Yingying_Zhao
[16:30] <asac> need answer: (a) meeting starts now, (b) meeting starts in 30 min, (c) meeting starts in 1h, (d) none of the above _____
[16:30] <pitti> asac: I pick (c)
[16:30] <pitti> did I win 1M EUR now?
[16:31] <asac> ;)
[16:31] <asac> thx
[16:40] <calc_> hehe
[16:40]  * calc_ hopes his car starts up the next time he tries... had to drive it through water at full acceleration yesterday :(
[16:42] <calc_> i thought i was going to hit my garage door because i had to drive at full accel even into my driveway so i wouldn't stall out my car, was borderline floating :\
[16:43] <mvo> seb128: geh, the code to do the file-overwrite error detection is going to be ugly :/
[16:43] <seb128> mvo: why?
[16:44] <mvo> seb128: dpkg sends a localized error message with %.250s in it
[16:44] <seb128> can we stop translating it? ;-)
[16:44] <mvo> haha
[16:44] <seb128> or do print an extra line only for that purpose?
[16:44] <mvo> that would be a good start ;)
[16:45] <mvo> yeah, best is to have dpkg give better status message, I have some code that should work with the string too, but its really not ideal
[16:45] <mvo> (works, but ugly)
[16:46] <asac> calc_: sounds wet ;)
[16:46] <seb128> mvo: ok
[16:47] <calc_> asac: yea, still raining today as well, but luckily the water has gone down at the moment
[16:47] <calc_> i'm surprised we haven't hit the saturation point again
[16:48] <calc_> hmm lots of warnings to stay away from any river in the area :\
[16:49] <calc_> satellite service appears to be knocked out so i can't see the local weather warnings about flooding :\
[16:55] <calc_> seb128: do you know if there is a bug report about this yet http://ubuntuforums.org/showthread.php?p=7152067 ?
[16:55]  * calc_ just ran into that bug himself trying to watch local news since his sat is down
[16:57] <calc_> shit my wife went to the doctor without a cellphone for me to tell her to come home :\
[16:57] <calc_> apparently all schools are closed, it appears it is very serious
[16:58] <seb128> this post suggests that's not a bug
[16:58] <seb128> it just needs non free codecs not installed by default
[16:58] <calc_> well isn't totem supposed to find them for you?
[16:58] <calc_> it doesn't do that as it did prior to 9.04
[16:59] <calc_> currently it just tells you the protocol support is missing and leaves the user to figure out what to do about it themselves
[17:02] <seb128> totem does the mozilla plugin doesn't
[17:02] <seb128> that's a known issue
[17:03] <calc_> hmm well spawning a full totem from the mozilla plugin still didn't find it for me
[17:04] <calc_> i'll try testing it again on my other system and reporting the bug with an example site to use later today (assuming i don't lose power again)
[17:05] <calc_> 25cm of rain overnight
[17:07] <seb128> could be gnome-codec-install being buggy
[17:07] <seb128> but I don't know about this code
[17:07] <seb128> that's a slomo thing
[17:09] <calc_> ok i'll report it there along with the details once i test it again
[17:13]  * calc_ wonders if he still has internet access
[17:14] <calc_> wow 27s ping response i'm very lagged
[17:20] <mvo> didrocks: so g-t 2.26.1 should go to karmic?
[17:22] <rickspencer3> kenvandine_wk: could you please add notes and links to the wiki regarding U1 before we start?
[17:22]  * pitti tosses some TCP packets to calc
[17:25] <calc> it seems to be mostly working atm
[17:26] <calc> only 3s now
[17:29] <pitti> seb128: can we cowtrade merges? I do gconf for you, you do rarian for me?
[17:29] <bryce> heya rickspencer3, wb!
[17:29] <seb128> pitti: ok
[17:29] <rickspencer3> tx
[17:29] <seb128> pitti: I didn't even notice that you had gconf assigned, I don't use merge.ubuntu.com usually
[17:30] <pitti> seb128: merci; I still pretty much don't have a clue what scrollkeeper/rarian are doing in the first place :/
[17:30] <pitti> seb128: well, you have gconf assigned, but I have rarian
[17:30] <kenvandine_wk> rickspencer3: sure
[17:30] <pitti> because I'm TIL (small dependency fix or so)
[17:30] <seb128> pitti: ok, let's trade then ;-)
[17:30] <calc> meeting?
[17:30] <rickspencer3> meeting time?
[17:30]  * pitti sits down
[17:30] <rickspencer3> heh
[17:31]  * rickspencer3 slaps desk with ruler
[17:31] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-04-28
[17:31] <rickspencer3> unfortunately, I'm still catching up, so not quite as organized as I like to be
[17:31] <pitti> ugh, activity reports are a bit thin
[17:32] <rickspencer3> pitti: right, I haven't had a chance to put them in the wiki yet
[17:32] <pitti> but I saw them fly by in mail
[17:32] <rickspencer3> it's all my fault
[17:32] <pitti> n/p :) *hug*
[17:32] <pitti> rickspencer3: hope you enjoyed the long weekend
[17:32] <rickspencer3> well, I've been working non-stop since like 5:30am, so am not feeling too guilty ;)
[17:32] <rickspencer3> I hope everyone is feeling good about Jaunty
[17:32] <pitti> my clock does not have 5:30 _AM_
[17:32] <rickspencer3> the buzz in the office in London was *very* positive
[17:33] <rickspencer3> Gerry told me "best reviews ever!"
[17:33] <kenvandine_wk> rickspencer3: done
[17:33] <rickspencer3> so, first topic
[17:33] <pitti> a friend of mine is very pleased with it, told me to pass on the "thank you"
[17:33] <rickspencer3> State of Jaunty
[17:33] <pitti> we have tons of SRUs
[17:33] <rickspencer3> general feedback about quality
[17:33] <rickspencer3> ?
[17:33] <rickspencer3> pitti: is that normal?
[17:33] <pitti> but none of them really OMGkittensdie
[17:33] <pitti> rickspencer3: yes, very
[17:33] <seb128> pitti: "tons" .. the normal amount I would say
[17:33] <pitti> a few major upgrade issues
[17:34] <pitti> seb128: we normally have "tons and tons" :)
[17:34] <seb128> ;-)
[17:34] <pitti> and some polish
[17:34] <rickspencer3> lol
[17:34] <pitti> I was pretty liberal in the first few days after jaunty
[17:34] <pitti> but now I'll raise the bar pretty high
[17:34] <pitti> sorry, davmor/mvo :)
[17:35] <rickspencer3> as discussed, I would like to transfer effort to Karmic as rapidly as possible
[17:35] <pitti> we still have a major e-d-s crasher and the 965 issue, otherwise I wouldn't waste too much work on it
[17:35] <rickspencer3> pitti: good
[17:35] <seb128> pitti: e-d-s crasher -> libical waiting for you
[17:35] <seb128> pitti: I turned of the crashing warnings
[17:35] <pitti> seb128: you rock
[17:35] <pitti> hah
[17:35] <rickspencer3> pitti: bug #?
[17:35] <seb128> pitti: which is what fedora does and upstream recommends doing
[17:36] <rickspencer3> for those following along?
[17:36] <pitti> bug 368508
[17:36] <seb128> rickspencer3: e-d-s crasher? look to recent bugs there
[17:36] <pitti> I presume
[17:36] <seb128> there is several bugs which are probably duplicates
[17:36] <pitti> you guys upload faster than I can process SRUs :)
[17:36] <seb128> pitti: yes
[17:36] <bryce> hehe
[17:36] <seb128> pitti: I switched to karmic this afternoon ;-)
[17:36] <seb128> so expect less SRUs from me
[17:37] <pitti> seb128: would be nice if you could dupe some real bug reports to that one, to get some testers subscsribed
[17:37] <seb128> "switched", ie I'm not using it yet
[17:37] <seb128> but I'm working on it
[17:37] <pitti> anyway, no meeting issue
[17:37] <seb128> pitti: will do
[17:37] <pitti> anyone else aware of somethign major which needs fixing in jaunty?
[17:37] <rickspencer3> I feel that we still have this i965 nut to crack, and that as a team we won't really be done with Jaunty until we have compiz working again
[17:37] <pitti> asac: did anything pop up on the nm/ff front?
[17:37] <pitti> bryce: and any other kitten killers besides 965?
[17:38] <bryce> not really
[17:38] <pitti> kenvandine_wk: or major breakage in notify-osd?
[17:38] <bryce> well, lots of X bugs kill kittens
[17:38] <bryce> but none that are on a rampage
[17:38] <pitti> ok, good
[17:38] <pitti> bryce: all will be better with DRI2/UXA, right? :-)
[17:38] <pitti> (famous last words)
[17:38] <kenvandine_wk> pitti: not really
[17:38] <bryce> I've talked to colin king about the performance issue, so we may see some progress there, but that's mainly kernel side stuff
[17:39] <bryce> pitti: yes, we get to exchange all our nasty old bugs
[17:39] <bryce> for fresh new ones
[17:39]  * pitti is running 2.6.30rc3/uxa/dri2/2.7.0 happily
[17:39] <pitti> ok, seems the "jaunty state" topic is done?
[17:39] <rickspencer3> yes
[17:40] <rickspencer3> except ... if you have an i965, or access to one, please be highly responsive to requests for assistance
[17:40] <rickspencer3> kenvandine_wk: U1?
[17:40] <kenvandine_wk> ok
[17:40] <kenvandine_wk> so U1 beta is coming up soon
[17:40] <kenvandine_wk> and I don't think we have had enough testing... so I have been turning up the heat
[17:40] <seb128> what is U1?
[17:40] <pitti> ubuntu one
[17:40] <kenvandine_wk> I even went cold turkey from dropbox
[17:41] <kenvandine_wk> serious dogfooding
[17:41] <seb128> ah ok
[17:41] <kenvandine_wk> there are instructions on the meeting wiki page for setting it up, everyone on the desktop team needs to kick the tires and report bugs
[17:41] <kenvandine_wk> but wait until tomorrow please :)
[17:41] <kenvandine_wk> major bug fixes are landing today as well as ppa changes
[17:42] <kenvandine_wk> thanks, lets help make sure U1 rocks!
[17:42] <rickspencer3> kenvandine_wk: thanks
[17:42] <rickspencer3> all - please note that the U1 team is trying *very* hard to be easy to work with here
[17:43] <rickspencer3> so I ask that we support them in kind by running their bits
[17:43] <rickspencer3> I'll ask kenvandine_wk to set up some kind of test or something that we can all participate in for the next team meeting
[17:43] <rickspencer3> next topic
[17:43] <rickspencer3> Launchpad Team and Kubuntu
[17:43] <rickspencer3> I just wanted to point out that three of the leads are serious Kubuntu fans
[17:44] <rickspencer3> Riddell: ^^^
[17:44] <rickspencer3> I'm trying to get them to join #kubuntu-devel and support the project
[17:44] <rickspencer3> next topic: Launchpad Team and Kubuntu
[17:44] <rickspencer3> oops ... copy paste error ;)
[17:44] <rickspencer3> All Hands
[17:44] <rickspencer3> everyone ready?
[17:45] <pitti> I brought my two hands
[17:45] <Riddell> cool
[17:45] <pitti> still need to prep the talks, though
[17:45] <rickspencer3> anyone else doing a talk?
[17:45]  * rickspencer3 raises hand
[17:45] <calc> i am, need to finish it up still
[17:45] <ArneGoetje> any information in which format the talks should be? I didn't see anything announced
[17:45] <ArneGoetje> me too
[17:45] <pitti> hm, it came through the lists
[17:46] <rickspencer3> ACTION: rickspencer3 to dig up info on all hands talk and resend to desktop team
[17:46] <pitti> I got two "talk approved" mails with some details, you didn't?
[17:46] <bryce> I'm doing a talk but I've not even had a moment to think about UDS :-(
[17:46] <ArneGoetje> I only saw the announcement for the talks, but I haven't seen anything about the preferred file format
[17:46] <rickspencer3> seb128: you're doing one if I recall correctly
[17:46] <seb128> rickspencer3: I got no email
[17:46] <rickspencer3> hmmm
[17:46] <seb128> so I guess my talk didn't get approved
[17:47] <rickspencer3> ACTION: rickspencer3 to check on seb128's talk
[17:47] <kenvandine_wk> seb128: i got a no thanks mail :)
[17:47] <rickspencer3> seb128: I thought I was cc'ed on one for you
[17:47] <seb128> rickspencer3: could have been spammed then
[17:47] <rickspencer3> seb128: ack, I'll check it out asap
[17:47]  * pitti wonders about the spammy topic seb128 will talk about then
[17:47] <seb128> if it got spammed I deleted it
[17:48] <seb128> or "marked as spam" rather
[17:48] <rickspencer3> seb128's topic was about about canning spiced ham, so it may have been diverted
[17:48] <seb128> I've difficulties to keep my boxes spam free at the moment
[17:48] <rickspencer3> ready to talk a little about UDS?
[17:48] <seb128> yes!
[17:48] <kenvandine_wk> i've had my email addy for 2 months now... and get a ton of spam already, can only imagine what seb128 gets
[17:49] <rickspencer3> a key change for Karmic is that we have two rooms
[17:49]  * pitti gets about 5000 a day through SpamAssassin, and about 70.000 per day which are rejected earlier on
[17:49] <calc> the canonical filter seems to catch most of my spam
[17:49] <rickspencer3> also, we are "hosting" Dx and Design in our track
[17:50] <rickspencer3> you may notice that I have added a bunch of blueprint "stubs"
[17:50] <ArneGoetje> mie didn't get approved yet
[17:50] <ArneGoetje> mine
[17:50] <rickspencer3> essentially placeholders that I could use to subscibe folks to and for scheduling
[17:50] <rickspencer3> ArneGoetje: no problems. These initial ones were based on internal partners and other things
[17:51] <ArneGoetje> ok
[17:51] <rickspencer3> folks from the community and Ubuntu engineers, still have time to create blueprints
[17:51] <ArneGoetje> until when?
[17:51] <seb128> do we need to create blueprints or only to suggest topics?
[17:51] <rickspencer3> ideally, you would all get them stubbed out by eow
[17:52] <rickspencer3> seb128: go ahead and create them, I think
[17:52] <rickspencer3> I haven't been through this before, so I thought I would let you all tell me how you want to do it
[17:52] <rickspencer3> I'
[17:52] <rickspencer3> ll create them for you if you want, but it seems more efficient just to let you do it
[17:52] <rickspencer3> pitti: what do you think?
[17:52] <pitti> would be good to have the blueprints created in a week, so that we can still schedule them appropriately
[17:53] <kenvandine_wk> rickspencer3: i have a few i proposed, which don't show up on the list yet... not sure what has to happen there
[17:53] <seb128> right, I was just wondering if we were filtering topics before
[17:53] <pitti> yes, everyone should create their "own", which you are interested in
[17:53] <seb128> to not create blueprint for things which are not scheduled or accepted
[17:53] <pitti> set drafter to you, approver to me, and propose for uds-karmic
[17:53] <seb128> ok
[17:54] <pitti> blueprints need to have a good summary and title
[17:54] <kenvandine_wk> pitti: if i find one that exists already, how can i set myself to drafter?
[17:54] <pitti> no need to create wiki pages yet, although of course having them is nice
[17:54] <pitti> kenvandine_wk: "change people"
[17:54] <pitti> kenvandine_wk: prod me to do it if you can't
[17:54] <kenvandine_wk> ok
[17:54] <kenvandine_wk> i have a couple i can't
[17:54] <pitti> (it's restricted to some group I can't remember)
[17:55] <pitti> or prod rickspencer3, whoever is available
[17:55] <kenvandine_wk> i'll poke you after the meeting
[17:55] <rickspencer3> In terms of title, I would ask that folks also start the name with "desktop"
[17:55] <pitti> so before next meeting, rick and I will go through the karmic proposed ones and approve them
[17:55] <rickspencer3> this makes the list much easier to use, I also have to manage dx and design sessions
[17:55] <pitti> so that we can talk about the list in next week's meeting
[17:56] <kenvandine_wk> can we rename the existing ones?
[17:56] <pitti> right, good to bring that up
[17:56] <kenvandine_wk> or have you guys rename them?
[17:56] <rickspencer3> kenvandine_wk: yes
[17:56] <pitti> please prefix the spec identifiers with desktop-karmic-*
[17:56] <pitti> kenvandine_wk: retitling is easy, I don't know if the identifier can be changed
[17:56] <pitti> anyone should be able to update title/description
[17:57] <kenvandine_wk> i can't for the ones i didn't create
[17:57] <kenvandine_wk> at least the one i tried
[17:57] <pitti> kenvandine_wk: ok, let rickspencer3 or me reassign, then you will be able to
[17:57] <kenvandine_wk> ok
[17:58] <rickspencer3> next topic is easy: Desktop Summit
[17:58] <rickspencer3> let me know if you're going, or want to go
[17:58] <tkamppeter> I will not be there.
[17:58] <rickspencer3> also, Canonical is hosting the welcoming party, so if you're going, make sure you get there in time for that, it should be a blast
[17:58] <bryce> me neither
[17:58] <rickspencer3> :(
[17:58] <calc> rickspencer3: i emailed you last week about it
[17:58] <ArneGoetje> me neither
[17:59] <calc> rickspencer3: i'm interested in going but didn't have time to submit a paper before the deadline
[17:59] <rickspencer3> okay, let me know *off list* if you're going or want to go :)
[17:59] <rickspencer3> calc: ping me later and we can talk
[17:59] <calc> ok
[17:59] <rickspencer3> next: OEM team swapperoo
[17:59] <rickspencer3> reminder that calc will be working with OEM services starting next week!
[17:59] <rickspencer3> and we'll have a new team member as well (Tony, I think)
[18:00] <bryce> have fun calc
[18:00] <calc> bryce: heh :)
[18:00] <bryce> will tony be working on openoffice then, or general desktop stuff?
[18:00] <calc> i get to learn lots of new things and bring back my knowledge to the desktop crew in november :)
[18:00] <rickspencer3> bryce: both
[18:01] <rickspencer3> I think we'll have to basically slow down OOo development (which given the Sun buyout may be prudent anyway) and spread the work around a bit
[18:01] <rickspencer3> also, calc will have some time to help us
[18:01] <calc> the biggest chunk of OOo work is getting bugs properly triaged due to having two upstreams
[18:01] <calc> we are pretty much caught up at the moment but get lots of new bugs every day :)
[18:01] <rickspencer3> calc: We'll miss you, but I think you'll have a great time, and learn tons
[18:02] <rickspencer3> any other business?
[18:02] <calc> yep :)
[18:02] <bryce> oh I have one thing
[18:03] <bryce> I already mentioned it on the ubuntu-devel@ mailing list, but the X team has a PPA set up now with updates for all the major video drivers
[18:03] <pitti> calc: good luck!
[18:03] <bryce> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/
[18:03] <rickspencer3> bryce: notice that Yingying_Zhao has started haning out in #u-d?
[18:03] <bryce> I'm sure everyone here will be on karmic so will be getting these automatically, but please pass word around about this to anyone sticking to Jaunty.
[18:04] <bryce> rickspencer3: no I hadn't
[18:04] <rickspencer3> hi Yingying_Zhao o/
[18:04]  * bryce waves to Yingying_Zhao
[18:04] <pitti> hi Yingying_Zhao, nice to see you here!
[18:04] <bryce> I'm formulating plans for -intel focus work for karmic, but more on that later.
[18:04] <rickspencer3> schweet
[18:04] <bryce> naught else from me.
[18:05] <rickspencer3> meeting adjourned?
[18:05] <calc> oh is Tony from the OEM team swap or a new hire?
[18:06] <pitti> have fun everyone with karmic syncs and new crack!
[18:06] <rickspencer3> calc: swap
[18:06] <pitti> s/syncs/merges/
[18:06] <calc> ok
[18:06] <rickspencer3> thanks all
[18:06] <ArneGoetje> thanks
[18:06] <pitti> thanks all
[18:06] <bryce> calc: iirc tony is the guitarist in the allhands jam
[18:06] <seb128> thanks all
[18:06] <rickspencer3> ArneGoetje: good night :)
[18:07] <calc> bryce: ah
[18:07] <calc> thanks
[18:07] <ArneGoetje> rickspencer3: thanks... soon :)
[18:07] <bryce> thanks all
[18:08] <asac> thx
[18:09]  * calc loves the huge influx of bugs a release causes, heh
[18:09] <bryce> calc: yeah the slope on my curve is steeper than it's ever been
[18:09] <pitti> calc: strange kind of love :)
[18:10] <bryce> http://people.ubuntu.com/~bryce/totals.svg
[18:10] <bryce> looks like a jet taking off
[18:11] <bryce> of course, I've been focusing on like TWO bugs exclusively the past couple weeks, but still...
[18:11] <pitti> everyone's bug mailbox is exploding indeed
[18:11] <pitti> but I think that's mostly due to ever-more people reporting feedback, not necessarily because we get worse
[18:13] <seb128> that's for sure
[18:13] <seb128> desktop bugs are mostly small details
[18:13] <seb128> but there is just of enthousiastic users reporting anything they find
[18:13] <seb128> +lot
[18:14] <calc> bryce: i keep beating mine down but they pop up as quickly as i can squash them
[18:21] <pitti> mvo: still remember why you applied the gconf patch 05_from_vuntz_gconf2-pk-default-path.patch ?
[18:22] <pitti> +    - use xml:merged:/etc/gconf/gconf.xml.defaults as default
[18:22] <pitti> +      location for system settings (thanks to vuntz)
[18:22] <seb128> pitti: because that's the right directory to use on debian or ubuntu
[18:22] <pitti> okay
[18:23] <pitti> seb128: but then, why do we carry a patch which adds /etc/gconf/gconf.xml.system/ and adds a change to debian/default.path to include xml:readonly:/etc/gconf/gconf.xml.system?
[18:23] <pitti> that directory is empty here
[18:24] <seb128> pitti: that's probably a leftover from the time where we didn't have this patch you just listed
[18:24] <pitti> right, I wondered why we have both, we should drop one
[18:24] <pitti> and it looks to me like we could drop gconf.xml.system
[18:24] <seb128> we need to check when we used the wrong directory
[18:24] <seb128> ie did it make to a stable?
[18:24] <seb128> in which case people might have settings there
[18:25] <pitti> seb128: okay, I'll do that then
[18:25] <pitti> seb128: if I find anything, I keep the default.path addition
[18:25] <pitti> it doesn't really hurt anyway
[18:25] <seb128> right
[18:25] <pitti> seb128: thanks for the heads-up
[18:25] <pitti> well, I'll just keep it
[18:25] <seb128> you're welcome
[18:26] <pitti> +# new system defaults mechanism (deprecated, but we need to keep it
[18:26] <pitti> +# for compatiblity with intrepid (8.10) were this was the default
[18:26] <pitti> +# for the system wide gconf settings (via org.gnome.GConf.Defaults)
[18:26] <pitti> ah
[18:32] <pitti> I'm off for the evening, we meet for preparing a friend's wedding
[18:32] <pitti> see you tomorrow!
[18:33] <bryce> cya pitti
[18:35] <seb128> pitti: have fun, see you tomorrow
[18:58] <chrisccoulson> hey seb128 - got any karmic updates for me to do? ;)
[18:59]  * chrisccoulson is liking the thunderstorm outside
[19:34] <seb128> chrisccoulson: hello
[19:34] <seb128> chrisccoulson: yeah, lot of things to do, I need to do a list
[19:34] <seb128> chrisccoulson: do you want to sync gnome-session on debian?
[19:34] <chrisccoulson> seb128 - yeah, i can do that
[19:34] <seb128> sync or merge whatever is required
[19:35] <seb128> chrisccoulson: you can look to merge nautilus too if you want
[19:35] <chrisccoulson> i'll take a look at it
[19:36] <calc> i think was are past the saturation point now it hasn't rained in an hour or so and the water level on the street isn't receding :(
[19:36]  * calc hopes it doesn't rain any more
[19:38] <seb128> chrisccoulson: cool, I will try to make a team todolist tomorrow for other updates and work
[19:38] <chrisccoulson> thanks, that would be useful:)
[19:38] <seb128> chrisccoulson: any package which has not been merged with debian yet is a good candidate to clean
[19:39] <seb128> ie we want to send changes upstream or to debian when it makes sense
[19:39] <seb128> and rebase the version on debian
[20:04] <crevette> heya
[20:04] <crevette> hey huats
[20:04] <crevette> hello seb128
[20:04] <seb128> hi crevette
[20:04] <huats> hello crevette
[20:10] <mahendra> hello
[20:10] <mahendra> i need some help
[20:12] <crevette> seb128: I wonder how you do to not get lost in update between upstream one and debian sync
[20:12] <crevette> :)
[20:12] <mahendra> i just upgraded my ubuntu 8.04 to 8.10. but now there is no title bar to any of the windows.
[20:12] <crevette> it's a kind of sport
[20:13] <mahendra> i tried changing themes but its not working
[20:13] <seb128> crevette: you need to know where to look ;-)
[20:13] <seb128> mahendra: try #ubuntu
[20:13] <mahendra> ok
[20:13] <seb128> mahendra: that channel is a work one not an user question one
[20:13] <mahendra> thanks
[20:13] <seb128> mahendra: and I would recommend using 9.04 it's much better than 8.10
[20:14] <crevette> :)
[20:14] <mahendra> i am going to upgrade to 9.04 but i need to solve this problem first
[20:15] <crevette> seb128: sorry for not bein that active
[20:15] <seb128> crevette: no need to be sorry
[20:15] <crevette> I seriously lack some times :/
[20:15] <crevette> bah, I feel totally inefficient :/
[20:16] <seb128> you have enough to do
[20:17] <crevette> I'll try to get some time later to help you for some packaging :)
[20:18] <seb128> cool
[20:18] <seb128> bbl
[20:19] <crevette> that was quick
[20:19] <seb128> yeah just forgot to write something on an another channel
[20:19] <seb128> bbl for now
[20:19] <crevette> see uou
[21:00] <dobey> vuntz: is that intltool fix sufficiently good for you?
[21:40] <calc> ugh my wife and son are stuck in another part of the city and can't get back due to the flooding :\