[00:50] <kees> jcastro: how do I submit a juju charm to the massive repo of them?
[00:50] <jcastro> http://juju.ubuntu.com/Charms
[00:51] <jcastro> has the steps
[00:51] <jcastro> kees, push to your branch, file bug, attach branch, tag it "new-charm" when you want a review
[00:51] <jcastro> kees, is this for the contest?
[00:54] <kees> jcastro: well, I thought I did all that before, but I figured I'd try it again as long as there was a contest. ;)
[00:54] <jcastro> link me up with the bug # when you have it and I'll pile it on the queue!
[00:55] <jcastro> kees, nice to you have you around rocking it still.
[00:57] <kees> jcastro: thanks!
[00:57] <kees> https://bugs.launchpad.net/charms/+bug/961819 tada
[00:57] <kees> okay, looks like I had just missed that last step then. heh
[01:29] <adam_g> any tips for dealing with test suites in packages that call libraries (python library, in this case) that try accessing things that are off limits on the build system (/dev/log, in this case)
[01:46] <jamesh> adam_g: fixing the test suite not to access things that are off limits?
[01:47] <adam_g> jamesh: its not the test suite, its a library that the test suite requires. suppose there is no fix other than skip those tests
[01:48] <jamesh> adam_g: or provide a fake implementation of the library function
[01:48] <jamesh> or perhaps one of the mock libraries
[02:52] <jhojho> can someone sponsor some attention to this bug. given that it's openssl, it will likely affect quite a few installs and packages. this applies to 64bit installs that do not have processors with AES-NI
[02:52] <jhojho> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/940230
[02:53] <jhojho> it should be easily fixable with compile flags. i.e. do not compile ASM in for the x86_64  build...
[05:52] <pitti> Good morning
[05:53] <scientes> unity-2d in precise use to work and now it doesn't
[05:53] <scientes> at 800x480 on fbdev @ 16 bpp
[05:57] <RAOF> scientes: Can you be more specific than “doesn't work”?
[05:58] <scientes> it crashes at launch
[05:58] <scientes> it takes al long time to time out before apport comes up
[05:58] <scientes> but then its "cant acess memory at XXXXX"
[05:58] <scientes> i tried with guest login too
[05:58] <scientes> and i purged xorg-edgers
[05:59] <scientes> the desktop also gets posted
[05:59] <scientes> *desktop image
[06:03] <scientes> how do i launch unity from the command line?
[06:06] <vibhav> scientes: unity
[06:07] <scientes> unity-2d
[06:08] <scientes> pooh wow, that worked
[06:08] <scientes> maybe its a multi-seat problem
[06:08] <scientes> oh no, its using llvmpipe, and slow as balls
[06:08] <scientes> and horribly corrupt
[06:08] <scientes> how do i run unity-2d from command line?
[06:09] <vibhav> #ubuntu might know
[06:10] <scientes> unity-2d-shell: [FATAL] Settings schema 'com.canonical.Unity2d.Launcher' is not installed
[06:12] <jalcine> balls move quickly when kicked.
[06:12] <jalcine> just saying, hehe
[06:15] <scientes> old version, fixed
[06:28] <alkisg> Hi, I'm using python-distutils-extra, and when I build under Lucid, data_files are missing from POTFILES.in, while under Precise everything is OK. I'm currently using a potfiles-workaround/ dir with symlinks to the files that need translations, but that's too ugly, any better solutions?
[07:08] <hrw> cjwatson: ops, screwed check then
[07:14] <pitti> micahg: what's the state of the lightdm gtk greeter?
[07:15] <alkisg> Hi, I'm using python-distutils-extra, and when I build under Lucid, data_files are missing from POTFILES.in, while under Precise everything is OK. I'm currently using a potfiles-workaround/ dir with symlinks to the files that need translations, but that's too ugly, any better solutions?
[07:46] <dholbach> good morning
[08:18] <cjwatson> hrw: well, I fixed pcmciautils, anyway
[08:21] <hrw> cjwatson: thx
[08:27] <hrw> cjwatson: what would you suggest to do with rest of packages?
[08:27] <hrw> cjwatson: ignore, convert to debhelper?
[08:28] <cjwatson> hrw: not sure :)
[08:28] <cjwatson> it doesn't seem desperately vital that ed doesn't have debug symbols, say
[08:28] <hrw> sure, but would be nice to have one for bzip2 for example
[08:29] <cjwatson> maybe an Ubuntu-specific change to call pkg_create_dbgsym in the appropriate place
[08:29] <cjwatson> I don't think converting packages to debhelper as an Ubuntu delta is a good idea
[08:29] <hrw> like binutils do ;)
[08:29] <hrw> no, sending delta back should be done
[08:29] <cjwatson> it would have to check /CurrentlyBuilding
[08:30] <cjwatson> there are cases where maintaining a delta is the right thing to do
[08:30] <hrw> btw - can package has arch specific dependency? build-dependencies can do that but I am not sure about dependencies
[08:30] <cjwatson> you probably aren't going to make many friends by sending patches that completely change the packaging
[08:30] <hrw> I know
[08:30] <cjwatson> yes, provided that the package is not Architecture: all
[08:30] <hrw> thats the problem
[08:30] <cjwatson> then no
[08:31] <hrw> laptop-detect is shellscript which is arch:any cause on x86 it has one more dependency
[08:31] <cjwatson> that's a legitimate reason to be arch: any
[08:31] <cjwatson> it doesn't just mean "compiled code only"
[08:31] <hrw> I know, just wondered
[08:32] <toabctl> mvo, can you have a look at https://bugs.launchpad.net/apt/+bug/960914 ?
[08:40] <mvo> toabctl: sure, let me check that one
[08:42] <mvo> toabctl: let me follow up in the bugreport I asked a bunch of questions there
[08:42] <mvo> (now)
[08:45] <pitti> hey mvo, good morning
[08:45] <mvo> hey pitti good morning to you as well
[09:01] <pitti> mvo: in bug 950676, do you think it would help to remove libseed0 early with a breaks: or even conflicts:? it seems to be pretty close to the root of the evil
[09:43] <jamespage> StevenK, hey - any change you could accept the zentyal-* binary packages into precise please?
[09:44]  * StevenK reaches for cocobanana.
[09:51] <StevenK> jamespage: I'm a little concerned some of the source packages are 2.3.4 and some are 2.3.3, but they all look good, so I'm accepting them.
[09:51] <jamespage> StevenK, great - upstream release each component separately hence the different minor version numbers...
[09:52] <jamespage> thanks v much
[10:13] <mvo> pitti: sorry, I was deep in a code review, let me check
[10:15] <mvo> pitti: getting rid of libseed0 early would certainly help
[10:15] <mvo> pitti: from what I see in the logs
[10:16] <pitti> mvo: still not sure whether this is a real apt bug, or just bad dependencies
[10:17] <pitti> mvo: ok, I'll try to upload a seed with that conflicts, we'll see how far we'll get
[10:17] <pitti> s/try to//
[10:17] <mvo> I wonder why its installed in the first place
[10:17] <pitti> mvo: some universe package in lucid apparently pulled it in
[10:18] <mvo> pitti: give me some minute to read the log some more
[10:18] <mvo> at least:
[10:18] <mvo> Broken libseed0:i386 Depends on gir1.0-glib-2.0 [ i386 ] < 0.6.8-1 > ( libs ) (>= 0.6.3)
[10:18] <mvo>   Considering gir1.0-glib-2.0:i386 17 as a solution to libseed0:i386 -1
[10:18] <mvo>   Removing libseed0:i386 rather than change gir1.0-glib-2.0:i386
[10:18] <mvo> looks like its doing the right thing
[10:44] <jhojho> openssl-1.0.1 is released.  is it too late to ship for precise?
[10:44] <cjwatson> I was actually pondering that myself
[10:45] <cjwatson> planning to look into it today and do some testing, and get a feature freeze exception request in if it looks good; there are some problems I've not been able to solve otherwise
[10:45] <jhojho> there are numerous improvements. which would be beneficial for a LTS
[10:45] <cjwatson> yeah, I know
[10:45] <jhojho> if you look at it, it would be much appreciated.
[10:45] <cjwatson> I'm not averse to it, it would be better than giant hairy backports
[10:46] <cjwatson> but there is certainly a risk so I need to do due diligence
[10:46] <jhojho> also if you could disable asm for ubuntu x86 64bit build
[10:46] <cjwatson> I'd rather investigate first
[10:46] <jhojho> there's a big regression of using asm vs. C starting with 1.0.0
[10:46] <cjwatson> I'm aware of that bug but I do not propose to agree to any particular solution until I've looked into it myself
[10:47] <jhojho> no worries. i have a bug opened for it. with a bunch of links that should explain.
[10:47] <jhojho> as well as timings.
[10:48] <cjwatson> heh, there's already an FFe open.  I do so love it when non-developers open FFes ;-)
[10:48] <jhojho> i was just hoping to get these all fixed given that precise is LTS and openssl affects so many other packages that perf would be fixed. =)
[10:48] <jhojho> what's the url to that FFe?
[10:49] <mvo> pitti: so what is still depending on the old gir? is it just a incomplete transition?   Considering gir1.0-gtk-2.0:i386 3 as a solution to gir1.2-gtk-2.0:i386 3 shows that there are probably 3 rdepends  (but they might be still on the installed system)
[10:50] <cjwatson> jhojho: it's got no useful information in it yet; I'd rather people didn't pile on it please
[10:50] <mvo> pitti: the log is a bit confusing, nevermind I keep diging
[10:50] <jhojho> i wasnt planning on adding anything to it.
[10:51] <jhojho> just to watch/track.
[10:51] <cjwatson> jhojho: also are you sure that 1.0.1 still has the performance regression on 64-bit?  the thread at http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19836 suggests this shouldn't be so
[10:51] <cjwatson> aside from some slowdown to resist cache timing attacks
[10:51] <mvo> pitti: aha, I think that contributes to the problem that there are no direct gir1.2-gtk-2.0 dependencies, this means apt has a harder time figuring out if the package is important or not
[10:52] <cjwatson> the FFe is bug 958430
[10:52] <mvo> pitti: I think that moving gir1.0-gtk-2.0 from option to extra (and the other gir1.0 stuff) fixes the bug too
[10:53] <dholbach> sladen, do you think you could have a look into the ubuntu-font MP again?
[10:53] <pitti> mvo: we can't, the gir1.0-* packages have gone long ago
[10:53] <jhojho> cjwatson: it's not clear. I'm happy to do some timing tests if a package is built.
[10:54] <jhojho> cjwatson: looking at the changelog, the constant time implementation that I see, is the stuff contributed by google
[10:54] <jhojho> for elliptic curve
[10:54] <jhojho> so not the same thing.
[10:54] <pitti> mvo: "Installing gir1.2-gtk-2.0 as Depends of gir1.2-dbusmenu-gtk-0.4
[10:54] <jhojho> "Specify "enable-ec_nistp_64_gcc_128" on the Configure (or config) command
[10:54] <jhojho>      line to include this in your build of OpenSSL"
[10:55] <jhojho> for 64bit only
[10:56] <jhojho> cjwatson: in that gmane link you posted, the last sentence says "If non-AES-NI
[10:56] <jhojho> performance in FIPS context is important to you, contact
[10:56] <jhojho> opensslfoundation.com."
[10:57] <jhojho> so I'm thinking it's probably not fixed for asm (or considered a priority item). and since using the asm codepath drops off about 50% for aes, it's kind of a big regression.
[10:59] <sladen> dholbach: if it's going up, I'd like it with the ~medium  (as we have different combinations in different PPAs and this means the combinations are clear)
[10:59] <dholbach> sladen, can't you upload it with that change?
[11:00] <dholbach> sladen, we are going to have Beta 2 Freeze today
[11:00] <jhojho> cjwatson: here's what I've found so far.. https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/940230
[11:00] <dholbach> so better get it in quick before
[11:00] <sladen> dholbach: however it is a massive (but minor) kludge that could be done at any point, and so I think this it makes sense to do it at T-5/6 weeks when it's probably possible to get a real fix in that time
[11:00] <therve> hi there!
[11:00] <dholbach> T-5/6 weeks? you mean after the release?
[11:00] <sladen> dholbach: and additionally; if it's happening, I don't want to do it before the wallpapers go up, so I don't lose the CD space
[11:00] <cjwatson> jhojho: I think I'm more worried about non-FIPS context for Ubuntu
[11:01] <sladen> dholbach: release is 5 weeks away
[11:01] <cjwatson> so I disregarded that last sentence
[11:01] <pitti> mvo: do you think a conflicts: libseed0 or breaks: will be better?
[11:01] <mvo> pitti: ohhh
[11:01] <jhojho> cjwatson: i dont need FIPS so i'm fine with that =)
[11:01] <mvo> pitti: I think a conflict will be (slightly) better
[11:01] <pitti> mvo: ok, that's my gut feeling, too
[11:01] <pitti> mvo: "oooh" sounds promising
[11:02] <dholbach> sladen, ok, I don't understand what you're saying, but I'll leave the decision to you - the merge proposal looked like you wanted Florian just to update the version number, which looked like a minor thing to block on
[11:02] <pitti> mvo: will a replaces: help to ease apt's mind?
[11:02] <mvo> pitti: no, sorry, it was about that its gone from the archive :/
[11:02] <mvo> pitti: as the optionl->extra would be a nice fix IMO
[11:02] <pitti> mvo: it was renamed for parallel installability, but now it _is_ the libseed library
[11:02] <sladen> dholbach: that one merge results in 3-4 other uploads needing to go into PPAs so they keep ahead
[11:02] <sladen> dholbach: I'm not keen on doing it
[11:03] <sladen> dholbach: however, if it's done, I'd prefer it being done in the prettiest way
[11:03] <dholbach> ok, I'll leave it to you - shall I mark it as "WIP"?
[11:03] <mvo> pitti: the conflict should be good enough (I think), but a C/R/P will not hurt if its really the same
[11:03] <dholbach> it doesn't seem to make sense to have it in the sponsoring queue
[11:04] <pitti> mvo: "provides:" would be exaggerating, and technically wrong
[11:04] <pitti> mvo: I have C/R now
[11:05] <mvo> ok
[11:05] <mvo> fingers crossed :)
[11:05] <pitti> mvo: uploaded; looking forward to tomorrow's run then
[11:05] <pitti> mvo: danke!
[11:07] <mvo> cool
[11:08] <jhojho> cjwatson: anyways thanks for looking at it as not having to wait another 2 years for TLSv1.1 and TLSv1.2 would be nice.
[11:14] <pitti> infinity: eek, that d-i FTBFS looks unhealthy..
[11:16] <infinity> pitti: Nah, it's fine.
[11:16] <infinity> pitti: Images just grew a bit when nic-firmware.udeb got more stuff added.
[11:16] <pitti> oh, "disk full"
[11:16] <infinity> pitti: Either Colin will fix it while I sleep, or I'll fix it when I wake up.
[11:16] <pitti> ok, thanks
[11:17] <infinity> pitti: Yeah, "disk" being the FAT image, not the buildd's disk. ;)
[11:17] <pitti> right, I just missed that at my first look
[11:19] <cjwatson> it's running through sbuild locally now
[11:41] <hrw> can someone try to rebuild mawk? it fails for me on testing
[11:46] <cjwatson> hrw: works fine here in a precise/i386 sbuild instance
[11:49] <hrw> thx
[11:50] <cjwatson> hrw: do you want the log?
[11:52] <hrw> no, built fine in pbuilder here as well
[11:53] <cjwatson> ok
[13:04] <jhojho> gcc 4.7.0 is out… http://article.gmane.org/gmane.comp.gcc.devel/125441
[13:11] <jenni82> hello. i've got a question on ubuntu audio dev ppa. i'm missing alsa-driver-1.0.25 package for precise x64. does anybody know if this one will be part of the release?
[13:12] <jenni82> right now there seem to be only x86 packages
[13:23] <geser> have you the package name at hand?
[13:25] <cr3> can I express a dependency on a version like this: postgresql (8.4 | 9.1)?
[13:27] <cjwatson> no
[13:27] <cjwatson> the policy manual has a complete syntax for dependencies
[13:28] <cr3> cjwatson: right, I was looking at this page but it wasn't mentionned. I wasn't sure whether it was because it wasn't supported or just wasn't mentionned: http://www.debian.org/doc/debian-policy/ch-relationships.html
[13:30] <cjwatson> anything not there is not supported
[13:30] <jenni82> package should be like this: http://packages.ubuntu.com/en/source/precise/alsa-driver
[13:30] <jenni82> but there seem to be no builds for x64
[13:33] <jenni82> i'm confused
[13:33] <cjwatson> jenni82: all the binary packages in the alsa-driver source package are Architecture: all, so it only needs to be built on one architecture
[13:33] <geser> jenni82: this source package only builds arch:all packages (can be installed on any architecture), so it only needs to get build once (which is done on the i386 buildd)
[13:36] <jenni82> hmm ... but why does "$ cat /proc/asound/version"  deliver Advanced Linux Sound Architecture Driver Version 1.0.24.
[13:37] <cjwatson> That's up to the kernel packages.  In Ubuntu the alsa-driver source package really just delivers configuration
[13:38] <jenni82> i was hoping to get rid of some sound-issues. so this means i have to install 1.0.25 manually?
[13:39] <cjwatson> I don't know whether the kernel team plan to bump to 1.0.25
[13:41] <jenni82> ok. thank you.
[14:53] <pitti> jdstrand, apw: sorry, in bug 947254 I accidentally also copied to -security :/
[14:54] <pitti> but I can't just remove the current package from -security again, as we actually want to keep 2.6.38-13.56 there
[14:55] <pitti> so we'd either need to reupload, and cause yet another update, or do an USN explaining this?
[14:55] <pitti> or find a Launchpad DB hacker to unpublish it?
[14:55] <pitti> cjwatson: ^ if you happen to have a brilliant idea
[14:56] <cjwatson> I suspect you're better off leaving it there, unless it's really bad
[14:57] <pitti> it was regression tested and everything, it's just not a security update
[14:57] <pitti> ... for the first time in months, I guess I got way too used to always copying everything to -security
[14:58] <pitti> saw too late that the "promote-to-security" task was "invalid"
[15:00] <jdstrand> jjohansen: ^
[15:02] <jjohansen> pitti: okay, we can write a USN to explain this
[15:03] <pitti> jjohansen: thanks; and sorry
[15:07] <pitti> ok, I think I got the other umpteen kernels correctly
[15:39] <apw> pitti, i think i'd vote for just leaving it
[15:59] <micahg> pitti: re lightdm-gtk-greeter> I've got one more thing to finish before I finish that, should be ready by 19:00 UTC
[15:59] <pitti> thanks
[16:14] <adam_g> is there an archive admin around who can bump the nova  upload thru https://launchpad.net/ubuntu/precise/+queue ?  the new binary package is just a launch script that was previously packaged with nova-console, plus a manpage and upstart job
[16:14] <bdmurray> pitti: do you recall what checks are done by apport before filing a bug in Launchpad?  I'm looking at bug 960851 from a Zorin OS install
[16:18] <nxvl> seb128: is my desktop on precise supposed to be completely broken?
[16:18] <nxvl> seb128: i log in an i see nothing on unity or gnome3
[16:18] <nxvl> didrocks: or it's your fault?? ^^
[16:19] <didrocks> nxvl: before asking "who's fault it is" you should look at what you did upgrade
[16:19] <didrocks> as there has been no unity upload at all in the official repo, I would doubt of it
[16:20] <nxvl> didrocks: the "fault" think was just a joke, not actually looking for whos fault is, sorry about confussion
[16:20] <nxvl> didrocks: i did an upgrade earlier this week and my desktop is completely gone
[16:20] <didrocks> no worry :)
[16:21] <dholbach> hey nxvl
[16:21] <nxvl> didrocks: is that known or just randomness?
[16:21] <nxvl> dholbach: hi daniel!
[16:21] <didrocks> nxvl: not known from here at least
[16:22] <didrocks> sorry, handling unity release, don't really have time for debugging it
[16:22] <didrocks> look at what you upgrade
[16:22] <didrocks> upgraded*
[16:22] <nxvl> didrocks: funny part, when i get to lightdm i get no icons, just blank squares with red 'x'
[16:22] <didrocks> there has been some new lightdm as well
[16:39] <pkt> Does i18n/keyboard.txt actually have any effect in ubuntu-defaults-builder / ubuntu-defaults-image ?
[16:39] <pkt> The context is that I 'm trying to build a localized image for Greek
[16:40] <pkt> and I noticed that in the resulting image there was no english keyboard :(
[16:41] <pkt> grepping the various scripts I see no reference to keyboard.txt besides verifying it
[16:42] <pkt> fwiw the source of the package is here: https://github.com/ubuntu-gr/ubuntu-defaults-el-gr
[16:47] <pitti> slangasek: are we planning to switch to a tmpfs /tmp/ in 12.10?
[16:52] <cjwatson> depends, you volunteering for the installer work? :-)
[16:52] <pitti> cjwatson: well, there are certainly programs to be fixed
[16:52] <pitti> I can instantly think of Firefox (uses it for downloads)
[16:52] <pitti> and presuambly also some CD burners
[16:53] <pitti> these should use /var/tmp/ for large things
[16:53] <pitti> cjwatson: OOI, what needs fixing in ubiquity? that's not somehing that sprang to my mind
[16:53] <pitti> (just got a question about it)
[16:53] <cjwatson> I think there's a reasonable argument that tmpfs /tmp ought to be selectable in the partitioner rather than mandated
[16:54] <cjwatson> and it may well require adjustment of autopartitioning limits and such
[16:54] <pitti> ah, ok
[16:54] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/server-karmic-tmp-as-tmpfs refers to bug 386554 as a blocker, I haven't checked yet whether that's still current
[16:54] <pitti> so either way, it's not a trivial change for multiple reasons
[16:55] <pitti> I was just curious whether I was missing a spec, or a bug (there's none against mountall)
[16:55] <cjwatson> that was the canonical spec for it, I think, yes
[16:55] <pitti> but I'm fairly sure I read about it on some ML
[16:55] <pitti> or some bug, or other place
[16:55] <pitti> damn memory
[16:55] <pitti> parts of my brain are on tmpfs, too :)
[16:55] <stgraber> pitti: it was mentioned recently on the TB ML IIRC
[16:56] <pitti> ah, perhaps that one, thanks
[17:21] <yofel> mvo: do you have a good suggestion on how to fix bug 944876? Just shifting the mapping is more of a hack than a fix, although s-p-kde would probably need a rewrite anyway at some point
[17:28] <bryceh> @pilot in
[17:28] <pitti> bryceh: enjoy the flight :)
[17:31] <cjwatson> ivoks: patch in bug 961166 - was that tested?  there's a .. vs. ../.. discrepancy, which seems to be due to having backported only half of 8316bd2d9813cbc7b2b8288b6618eec2c2004028
[17:32] <ivoks> cjwatson: let me revisit that
[17:32] <ivoks> cjwatson: ups... my bad, sorry
[17:33] <cjwatson> it might be worth taking the whole of that patch
[17:33] <bryceh> pitti, thanks, actually since we're nigh-frozen, probably just going to tend srus
[17:33] <pitti> bryceh: there might be a couple of universe fixes, too
[17:33] <pitti> but yeah, ther's a fair number of SRUs, too
[17:37] <bryceh> pitti, is universe not included in this freeze?
[17:37] <pitti> bryceh: it is, but it's feature/UI freeze just like main
[17:37] <pitti> but UI is "less" frozen for universe
[17:38] <pitti> the definition even says it doesn't apply to universe
[17:38] <pitti> and of course they are less dangerous usually
[17:42] <bryceh> pitti, ok, thanks.  I still plan to make srus my focus; like you say there's a lot of 'em.
[17:44] <ScottK> pitti: I thought the discussion we had a (few) weeks ago concluded in a general consensus that U/I freeze applied to everything (like FF), but that for unseeded packages that aren't in any docs package they would be trivially approved?
[17:44] <pitti> right, that's why I said "less" frozen
[17:45] <pitti> I haven't checked whether there are any UI breaks in teh sponsoring queue, and whether they have UIFE bugs
[17:47] <slangasek> agateau: are you sure 'libqt4-gui' is the package you meant to ask me for in bug #915801?  Because libqt4-gui:i386 isn't installed (it's not a dep of skype:i386)
[17:48] <agateau> slangasek: ahah, maybe that is the problem
[17:48] <slangasek> really
[17:48] <slangasek> ?
[17:48] <agateau> is your skype package statically linked against qt?
[17:49] <slangasek> well, it's the stock package
[17:49] <slangasek> let's see
[17:49] <slangasek> $ ldd /usr/bin/skype |grep QtGui
[17:49] <slangasek> 	libQtGui.so.4 => /usr/lib/i386-linux-gnu/libQtGui.so.4 (0xf6b07000)
[17:49] <agateau> ah no, I was wrong
[17:49] <agateau> it is libqtgui4
[17:49] <slangasek> ok
[17:49] <agateau> libqt4-gui is a transitional pacakge
[17:49] <agateau> *package
[17:51] <slangasek> ok, versions sent to the bug
[17:54] <pitti> this is really a curious one; sni-qt has worked fine here all the time
[17:54] <pitti> I wonder what the heck is different
[17:54] <pitti> (with skype)
[17:54] <ScottK> pitti: Right, but I think we need to update the definition on the wiki to match that.
[17:56] <slangasek> pitti: yeah, I'd also like to know ;)
[17:57] <slangasek> mvo: hey, do you have any time to talk about bug #876298?
[18:03] <mdeslaur> slangasek: #962378 is making me cry
[18:03] <mdeslaur> bug #962378
[18:05] <slangasek> mdeslaur: that's not a new issue, the circ dep has been there for quite some time IIRC - what's making you cry now?
[18:06] <mdeslaur> slangasek: I'm trying to fix bug #920758
[18:07] <slangasek> and the circ dep is getting in the way of fixing, or in the way of testing the fix?
[18:08] <mdeslaur> hrm, actually...just testing, so I'll work around it for now
[18:08] <slangasek> bdmurray: can we block new reports of bug #929219 please?  launchpad is starting to creak
[18:10] <slangasek> bdmurray: the duplicate signature should check for that __nscd_get_mapping() call in any package, not just chromium-browser or eglibc; I just duped bug #929437 to it, which was reported via gvfs+software-center
[18:11] <slangasek> mdeslaur: right - we may be able to improve handling of the circular dep, but I'd like doko to weigh in and he's out today
[18:12] <mdeslaur> slangasek: ok, thanks
[18:14] <bdmurray> slangasek: nscd_get_mapping only appears in the retraced stacktrace which isn't patternable.  do you have another suggestion?
[18:14] <slangasek> bdmurray: heh, darn
[18:14] <slangasek> bdmurray: gethostbyname2_r() + the eglibc version may be sufficient?
[18:15] <slangasek> bdmurray: yeah, that should be enough to identify it
[18:16] <slangasek> libc6 version >= 2.15~, <= 2.16-0ubuntu6
[18:16] <slangasek> sorry, 2.15-0ubuntu6
[18:38] <jhojho> cjwatson: can you confirm if the perf regression is fixed in 1.0.1?   nehalem, sandy bridge and ivy bridge all have aesni  support
[18:38] <jhojho> so it's not a perf issue on those processors.
[18:39] <jhojho> the regression is on 64bit processors without aesni
[18:49] <pitti> jibel: would it be possible to re-trigger precise-upgrade-lucid-universe ?
[18:49] <pitti> jibel: as long as it fails, it "only" takes 1:45 hours
[18:49] <pitti> jibel: but we got that seed fix today which hopefully helps
[18:49] <pitti> jibel: (seed as in the package, for the libseed0 -> libseed-gtk3-0 transition and the gir1.0 mess)
[18:51] <jibel> pitti, it's in the queue and will start after lucid server. ETA 3min 9sec according to jenkins :)
[18:51] <pitti> jibel: thanks!
[18:52] <slangasek> pitti: what was the fix for seed, OOI?
[18:52] <slangasek> ah, pushing libseed0 out manually, ok
[18:53] <pitti> slangasek: we made libseed-gtk3-0 conflicts/replaces libseed0, to force the removal of libseed0 instead of trying to fulfill its dependencies in precise
[18:53] <pitti> it seems apt did not clean it up by itself
[18:53] <slangasek> yeah... it's a shame to need to do that
[18:53] <slangasek> but certainly quicker than figuring out why apt isn't happy to remove the lib :/
[18:53] <pitti> well, I looked at that apt log for over an hour, and this seems to be the root cause
[18:54] <pitti> I guess if I do that ten times more, I'll write a script to graphvizise apt.log :)
[18:54] <slangasek> yeah, it's the root package cause certainly
[18:55] <slangasek> but the *root* cause is apt keeping an obsolete lib when it should throw it away :)
[18:56] <mvo> slangasek: sure, the bits in comment #22 ?
[18:56] <slangasek> mvo: well, and the merge proposal which I marked you a reviewer on :)
[18:57] <mvo> slangasek: rigth, I was off yesterday and crazy day today, but let me scan over it
[18:59] <cjwatson> jhojho: my results are in the bug
[18:59] <cjwatson> jhojho: based on the assertions I've seen that there was some deliberate slowing down of AES to defeat cache timing attacks, I'm reluctant to assume that slower is necessarily a showstopper here
[19:00] <jhojho> i see the bug report but no actual timings.
[19:00] <pitti> slangasek: yeah, workarounds'r'us
[19:00] <jhojho> cjwatson: that makes no sense as processors with aesni exhibit no slowdown
[19:00] <cjwatson> I posted timings from a Core 2 Duo and a Nehalem to the FFe bug
[19:01] <mvo> slangasek: I will reply in the bug and in the MP
[19:01] <cjwatson> Anyway, I'm not going to change it further before beta 2 at this point unless there's some kind of serious regression from 1.0.0g, so there should be plenty of time to collect data
[19:01] <jhojho> ah I see the timings now. let me go check them out.
[19:02] <cjwatson> I'm afraid I didn't post comparative timings from lucid; I can do that later if necessary
[19:02] <cjwatson> on the "one step at a time" principle I wanted to get 1.0.1 sorted out first
[19:02] <cjwatson> anyway, it's thoroughly pub time now
[19:02] <jhojho> please if you could.
[19:03] <jhojho> there is one thing I would ask for on the amd64 build
[19:03] <jhojho> its the inclusion of the config flag that turns things on for the google contributed elliptic curve code
[19:04] <cjwatson> well, let's talk with the Debian maintainer about that; 1.0.1-2ubuntu1 very significantly reduces the delta against Debian and I'm pretty happy about that
[19:04] <cjwatson> (makes it easier to maintain)
[19:04] <jhojho> for whatever reason, they made things so that you have to explicitly pass that flag.
[19:04] <jhojho> ok
[19:04] <cjwatson> that's "enable-ec_nistp_64_gcc_128"?
[19:05] <jhojho> yes
[19:13] <dobey> actually i guess i should have asked that over here instead…
[19:13] <dobey> hrmm. is apport retracer blocked/disalbed for amd64 bugs?
[19:18] <bdmurray> slangasek: so the bugpatterns are regular expression would 2.15~pre work?
[19:20] <bdmurray> ah no also need one for 2.15-0ubuntu6
[19:21] <slangasek> bdmurray: as a regexp, I'd do '2\.15\(~pre\|-0ubuntu[1-6]\)'
[19:22] <jhojho> cjwatson: it does look like things are a tad faster between 1.0.0 vs 1.0.1
[19:34] <bdmurray> @pilot in
[19:35] <jhojho> cjwatson:  just installed to 1.0.1 and it looks like Lucid is still faster.  here's the pastebin for lucid and precise (2 results, 1.0.0 and 1.0.1)  http://pastebin.com/FG6mfabw
[19:40] <Sarvatt> jhojho: wouldn't that be dependent on the kernel instead?
[19:40] <jhojho> why?
[19:40] <jhojho> this is a userspace test. it has nothing to do with the kernel
[19:41] <Sarvatt> the fact the aes numbers dont change here either make me think its using the kernel aes stuff but i really have no clue
[19:42] <Sarvatt> sha1 rc4 md5 all change drastically
[19:44] <PaoloRotolo> Hi all!
[19:48] <mvo> slangasek: I followed up in the MP
[19:48] <slangasek> mvo: seen, thanks
[20:22] <bdmurray> How does the app-install-data-ubuntu menu-data get generated?
[20:47] <pitti> slangasek: sni-qt> *chuckle*
[20:47] <pitti> slangasek: I'm glad that the mystery is resolved
[20:47] <slangasek> pitti: :/
[20:47] <slangasek> pitti: I feel bad now for wasting people's time
[20:47] <pitti> [ubuntu/precise] lightdm-gtk-greeter 1.1.4-0ubuntu1 (Accepted)
[20:47] <pitti> \o/
[20:47] <slangasek> and am running debsums -s now :P
[20:47] <pitti> thanks micahg and mr_pouit !
[20:54] <infinity> pitti: What, no love for the guy who put all the effort into pressing the "accept" button?
[21:00] <slangasek> infinity: not unless you can prove it was you who pressed it ;)
[21:01] <infinity> slangasek: There's a bug for that. :P
[21:01] <infinity> slangasek: And I can prove I filed it!
[21:10] <Beret> I'm sure someone will pick it up eventually, but if a sponsor is lurking, I could use one for https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/962448
[21:35] <skaet> msg chanserv topic #ubuntu-devel Precise Beta 2 Freeze in Effect.  Archive: pre-release freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurr
[21:35] <skaet> ay, bryceh
[21:35] <bryceh> skaet, yes?
[21:36]  * Daviey paases skaet a / :)
[21:36]  * skaet accepts the / from Daviey 
[21:36] <skaet> :)
[21:36]  * maco wonders if the linebreak indicates it wont all fit in /topic either
[21:36] <bryceh> heh, max topic length?
[21:36] <Daviey> suck it and see.
[21:36]  * maco eyebrow
[21:37] <skaet> it looks ok to me...
[21:37] <bryceh> yeah ok here too
[21:37] <maco> i dont see the topic as having changed...
[21:37] <skaet> topic seem to be longer than the line limit.   interesting.
[21:37] <ScottK> Missing two letters off of the patch pilot's nick here.
[21:39]  * skaet edited out the redundant info about the Archive, Beta 2 Freeze in Effect pretty much summarizes it.
[21:39] <skaet> ScottK,  better?
[21:39] <maco> skaet: wasnt bryceh also supposed to be a patch pilot?
[21:39] <ScottK> I only see bdmurray,
[21:40] <ScottK> Getting there.
[21:40] <Daviey> \o/
[21:40] <ScottK> There we go.
[21:40] <skaet> Thanks Daviey
[21:41] <skaet> sigh...
[21:41] <skaet> bryceh was on the last version i thought... oh well.   sorted now.   Thanks ScottK, maco.  :)
[21:42] <ScottK> You're welcome.
[21:46] <bryceh> having it go over length is probably a sign the topic needs some cleanup ;-)
[23:11] <slangasek> so um, why is libvte suddenly complaining about a missing /etc/termcap?
[23:12] <slangasek> (and as a result, failing to correctly handle PgUp/PgDn and others)
[23:13] <slangasek> gnome-terminal not restarted for 18 days; not sure if it needs restarted, or if trying to restart it is the worst idea ever
[23:19] <infinity> slangasek: I see no such whining from my xfce4-terminals (which also use vte)
[23:19] <infinity> slangasek: I say restart gnome-terminal, and if it all goes south, we'll see you from your console? ;)
[23:38] <bdmurray> @pilot out
[23:39] <bryceh> @pilot out