[03:10] <skunk> did you guys see the new Macbook pro??
[03:32] <ScottK> jtaylor: If you dh_python2 cython, I'll sponsor it.
[04:13] <pitti> arges: can you please forward that upstream?
[04:14] <pitti> arges: it built fine with python3 in quantal, do you have the error?
[04:14] <pitti> arges: I mean what did you do to get that error?
[04:14] <vibhav> debfx: ping
[04:15] <pitti> arges: ah, ignore me
[04:15] <pitti> arges: yes, I'll apply it in Debian, and update my merge proposal for upstream
[04:30] <vibhav> Why was the version of debhelper in build-depends of libqaculate was lowered in 0.9.7-6ubuntu1 ?
[04:32] <vibhav> debfx: ^
[04:32] <micahg> vibhav: did you ask before looking at the merge? (and that doesn't look like the right name)
[04:32] <micahg> oh, I see the package now
[04:33] <vibhav> Actualyy I have not started the merge now
[04:33] <vibhav> But it is likely that we will not drop this change
[04:34] <vibhav> micahg: For now I am not dropping the change
[04:35] <micahg> vibhav: yes, but before you start working on a merge, you should ask the person who touched it last if they're working on it or if you can take it so as not to duplicate work
[04:36] <micahg> and debfx is usually pretty up to date with his merges
[04:39] <vibhav> I had sent him an email a while ago
[04:44]  * SpamapS finally comes back to bug 986892 .. weeks later than he'd have liked
[04:46] <infinity> pitti: Heh.  Good morning. :P
[04:46] <infinity> pitti: (I love watching the "wait, how the, what, oh, you're right, yeah" ping responses first thing in the morning)
[04:47] <pitti> infinity: I didn't see the pyppd FTBFS mail for some reason, and it builds fine locally
[04:47] <pitti> so I indeed was a bit confused
[04:47] <micahg> pitti: you don't get FTBFS mail for Debian syncs ATM
[04:47] <pitti> oh! that'd explain it
[04:49] <micahg> pitti: fails in my quantal schroot
[04:50] <pitti> yes, I can replicate it
[04:50] <pitti> building with LANG=C
[04:50] <pitti> open() in text mode defaults to the system encoding when decoding files
[04:50] <pitti> that's something I still need to get used to in py3
[04:50] <pitti> already fixed in git
[04:51] <pitti> upstream answered in the MP with another bug, I'll fix that as well and reupload to Debian/sync
[04:51] <infinity> I really need to get around to doing the lp-build thing I planned to do that would take a .dsc and jam it through a local "as close to lp-buildd as you can get" environment.
[04:51] <infinity> So people can stop guessing.
[04:51] <micahg> pitti: one's +synchronised-packages page is an easy way to watch for those failures (from Debian syncs)
[04:51] <StevenK> infinity: Including buildd-manager? :-P
[04:51] <pitti> the thing that's hardest for me to replicate are apport's test failures in the package tests, though
[04:51] <infinity> StevenK: No. :P
[04:52] <pitti> i. e. the buildds do have a defaultroute (i. e. pretend to have network), but in a very limited/strange way
[04:52] <infinity> StevenK: buildd-manager may break all sorts of things, but it doesn't affect builds, thankfully.
[04:53] <infinity> pitti: They have a network, but are firewalled from hitting anything outside their subnet and, more entertainingly (and this is the one that messes people up), they have DNS, but it only resolves to the local network.
[04:53] <infinity> pitti: Could easily replicate the entire setup in an lxc container.
[04:54] <pitti> yeah, I'm trying to think of a way how a test can detect whether it's running in such an environment
[04:54] <pitti> ATM the tests skip if there is no defaultroute
[04:55] <infinity> pitti: Just try to resolve some well-known address?
[04:55] <infinity> pitti: Unless you're writing testcases for a DNS resolver, I guess. :P
[04:56] <pitti> infinity: so I could check if ddebs.ubuntu.com resolves, instead of checking for a default route
[04:56] <pitti> or better, in addition to
[04:56]  * micahg would suggest something that might not go away in the future...
[04:56] <infinity> pitti: Yeah.  Or keep it intentionally very external (and very unlikely to fail) like, said, www.google.com
[04:56] <infinity> s/said/say/
[04:56] <pitti> well, I only actually use archive.u.c. and ddebs.u.c. in the tests
[04:57] <pitti> so I guess I should test for those
[04:57] <infinity> I think "www.google.com doesn't resolve, you probably don't have external DNS resolution" is a test trigger that's likely to be five-nines accurate.
[04:57] <pitti> *nod*, thanks
[05:19] <vibhav> Could anybody have a look at https://bugs.launchpad.net/ubuntu/+source/libqalculate/+bug/1011937 ?
[05:20] <micahg> vibhav: you should really talk to the kubuntu folk about that merge
[05:21] <micahg> I see at least 2 things that could be dropped depending on their needs
[05:22] <infinity> The libqalculate4 replaces is no longer needed.
[05:22] <micahg> infinity: if they're backporting to precise, it might be good to keep
[05:22] <micahg> hence why I said "depending on their needs"
[05:22] <infinity> I suppose there's that possibility, yeah.
[05:26] <micahg> and SONAME versioned libs really shouldn't be breaking each other, but that's for another time I guess
[05:27] <SpamapS> hrm
[05:27] <SpamapS> http://paste.ubuntu.com/1036655/
[05:27] <SpamapS> mysql-server-5.1 is "replaced" by mysql-server-5.5 ...
[05:27] <SpamapS> but those 5_1 files are not in mysql-server-5.5 ..
[05:27] <SpamapS> so how do I kill those and trigger dpkg's "ok its actually been replaced, purge all" ?
[05:28] <SpamapS> do I stub those into 5.5?
[05:28] <SpamapS> is this what dpkg-maintscript-helper does? :-/
[05:28]  * SpamapS is confused and out of time. :-P
[05:28] <SpamapS> I guess so since really those conffiles have just been renamed
[05:30] <infinity> SpamapS: Replaces overwrites files, it doesn't replace packages.
[05:31] <SpamapS> infinity: right, I understand that..
[05:32] <infinity> SpamapS: If you want to purge the package, purge it. :P
[05:32] <SpamapS> infinity: but when all the files have been overwritten, the old one is purged
[05:32] <infinity> There's nothing to "trigger".
[05:32] <infinity> You have it in a removed state, that's all.
[05:32] <infinity> Sure, when a package no longer has conffiles, remove==purge.
[05:32] <SpamapS> infinity: thats what happens to anybody who dist-upgrade's from oneiric/lucid to precise with mysql-server installed.. they have a removed but not purged mysql-server-5.1
[05:32] <infinity> But, you could also just purge.
[05:33] <infinity> SpamapS: (This is why I dist-upgrade with --purge...)
[05:33] <SpamapS> caused only by those files :-P
[05:33] <SpamapS> ok, so .. just "fahgedaboudit" :)
[05:33] <SpamapS> I can do that
[05:34]  * infinity nods.
[05:34] <SpamapS> this bug is going to be a bear
[05:35] <SpamapS> have to update debhelper in lucid and oneiric..
[05:35] <SpamapS> then nochange rebuild update mysql 5.1 in those
[05:35] <micahg> hrm, doesn't purging mysql have bad side effects?
[05:35] <SpamapS> micahg: only if you've told it to delete /var/lib/mysql
[05:35] <SpamapS> which .. is interesting actually
[05:35] <SpamapS> since we've transferred ownership of that dir
[05:36] <SpamapS> the postrm should not touch it
[05:36] <infinity> But it sure will.
[05:36]  * SpamapS does not want to look at that scenario right now
[05:36] <infinity> This isn't exactly a new bug, though.
[05:36]  * SpamapS should get sleep before losing sleep over that
[05:36] <infinity> It's been like this since the 4.x packaging.
[05:37] <infinity> And I don't recall any complaints that people upgraded, purged the old, and had an oops.
[05:37] <infinity> So, they're either smart enough to pick the right Debconf options, or too embarrassed to complain about it when they didn't.
[05:38] <SpamapS> infinity: seems like it would be easy enough to have each package "claim" the dir on postinst and only purge it if you are the one who claimed it.
[05:39] <infinity> SpamapS: A bit hard to do retroactively.
[05:39] <infinity> SpamapS: But perhaps not a terrible idea in the future.
[05:40] <SpamapS> oh even more fun.. no dh_apparmor in lucid.. so I have to fix it in mysql-dfsg-5.1 directly :p
[05:41] <infinity> What's the bug?
[05:41] <infinity> And how was "updating debhelper" a sane solution?
[05:41] <SpamapS> infinity: dh_apparmor creates a postrm that will remove the "local" files in the event that another package has replaced its conffiles
[05:41] <SpamapS> bug 986892
[05:42] <SpamapS> infinity: the fix is simple. If the main conffile still exists on purge, that means another package has claimed it.. so leave the files in place.
[05:44] <SpamapS> this is the bug of a thousand tasks
[05:45] <infinity> SpamapS: Oh, that's just special.
[05:46] <SpamapS> I'm pretty sure its got quite a few duplicates actually
[05:46] <SpamapS> probably from people doing dist-upgrade --purge
[05:46]  * infinity wonders if any other multi-versions-claiming-apparmor-profiles issues exist.
[05:46] <infinity> psql, perhaps.
[05:46] <SpamapS> since the purge method shouldn't be called otherwise
[05:47] <infinity> SpamapS: Well, you can also manually purge, post-upgrade.  Which I tend to do, both for tidiness and bughunting.
[05:47] <SpamapS> yeah
[05:47] <SpamapS> the dupes we're getting are all package install errors from 5.5
[05:47] <infinity> (After a do-release-upgrade, I'll 'dpkg -l | grep ^rc' and go to town)
[05:47] <SpamapS> because it fails to start.. because apparmor is all forked up
[05:49]  * infinity should probably sleep.
[05:49] <infinity> SpamapS: I take back my knee-jerk "fixing debhelper isn't sane" reaction.  That's a pretty icky bug.
[05:50] <infinity> SpamapS: Hopefully, the exposure is low (as in, hopefully, packages taking over each others' apparmor profiles is a rarity)
[05:51] <SpamapS> infinity: I believe it is a rarity
[05:51] <SpamapS> infinity: but worth fixing nonetheless
[05:51] <SpamapS> in an SRU I mean
[05:51] <infinity> The DHCP rename could have had the same effect.
[05:52] <micahg> SpamapS: sbeattie is doing an apparmor SRU, you should talk to him
[05:52] <SpamapS> micahg: will do
[05:52]  * micahg taps his foot waiting for the launchpad diff
[05:52] <SpamapS> I think actually I don't need to SRU apparmor
[05:52] <SpamapS> dh_apparmor was only moved into apparmor in precise
[05:53] <infinity> SpamapS: Could be more, but off the to of my head, I'd suggest having a quick look at versioned psql packages, and dhcp3*->isc-dhcp*
[05:53] <micahg> umm, aren't we talking about precise?
[05:53] <SpamapS> micahg: yes but the problem lies in mysql 5.1 .. from << precise
[05:53] <infinity> SpamapS: The problem's also in 5.5 in precise.
[05:53] <infinity> SpamapS: At least, it will be there, once there's a >> 5.5 in a later release. :P
[05:53] <SpamapS> its there.. true we will need that whenever 5.6 arrives, which should definitely be before 14.04 :)
[05:54] <infinity> So, fix it in precise now, before you forget about it. ;)
[05:55] <micahg> SpamapS: I assume you used the VCS for apparmor?
[05:55] <SpamapS> micahg: I did tho I refrained from pushing since all the other commits were done by the package importer ;)
[05:55] <SpamapS> have not touched precise's apparmor hyyet
[05:55] <micahg> SpamapS: umm, what does Vcs-Bzr show for you on apparmor?
[05:56] <SpamapS> wait
[05:56] <SpamapS> its not ubuntu:apparmor ?
[05:56] <SpamapS> WTF
[05:56] <micahg> UDD is not everything
[05:56] <SpamapS> fail
[05:56] <SpamapS> I never check Vcs-*
[05:56] <SpamapS> thery're wrong 99% of the time
[05:56] <micahg> SpamapS: that's a big fail, especially for stuff in main
[05:56] <pitti> 99% must be a gross overstatement
[05:57] <pitti> all ubuntu-desktop Vcs-Bzr: are right
[05:57] <infinity> They're generally correct in main.
[05:57] <pitti> well, most of the time
[05:57] <micahg> as should be the Mozilla stuff
[05:57] <SpamapS> when's the last time I touched ubuntu desktop ?
[05:57] <infinity> Generally.
[05:57] <SpamapS> :P
[05:57] <pitti> Debian's Vcs-Git: are not correct for Ubuntu, of course
[05:57] <pitti> but Vcs-Bzr: on LP is almost always correct
[05:57] <SpamapS> we basically do not use them in server stuff at all
[05:57] <micahg> pitti: well, except for the stuff in ubuntu maintained in Debian :)
[05:58] <SpamapS> but the big fail there..
[05:58] <pitti> micahg: yeah, I wish we had a standard flag that says "don't change this in Ubuntu, talk to $NAME instead"
[05:58] <SpamapS> is that you can *change* the official lp:ubuntu/... to point at it
[05:58] <SpamapS> Why aren't people using lp:ubuntu/* ?
[05:58] <micahg> pitti:  if $VCS ~ /ubuntu/ then edit here :)
[05:59] <SpamapS> this is just maddening
[05:59] <pitti> SpamapS: fully agree on the maddening part
[05:59]  * SpamapS isn't sure whether to feel annoyed or guitly
[06:00] <pitti> there is no one true way
[06:00] <SpamapS> but I ask, *why*
[06:00] <SpamapS> I suspect mistrust of the package importer
[06:01] <infinity> It's not hard to mistrust it.
[06:01] <infinity> It's not done much to earn mine.
[06:01] <SpamapS> it has ruined my branches enough times that I am a-feared of it
[06:01] <pitti> UDD is making things ridiculously complicated and error prone, and a lot of branches are out of date
[06:01] <SpamapS> I've struggled pretty hard to keep branches up to date for the server stuff
[06:02] <pitti> which is why so many people rather use the good old debian/ only custom branches with e. g. bzr-builddeb
[06:02] <SpamapS> meh ok
[06:02] <infinity> pitti: Say, did you have any plans to fix the .symbols files for cups on arm*?
[06:02] <infinity> pitti: It's been FTBFS for weeks.
[06:02] <pitti> infinity: apw looked at it last week, but I guess he stopped in the middle or so
[06:03]  * pitti really tries to detach himself from the printing stuff, but that is very sticky
[06:03] <pitti> currently fixing pyppd..
[06:04] <pitti> infinity: it's also completely mysterious to me; but I guess I'll just add this new weird symbol as optional and stop worrying about it
[06:05] <infinity> pitti: Welcome to C++ symbols?
[06:05] <pitti> infinity: it's not just that; it built fine on Debian's arm
[06:05] <infinity> pitti: 4.7
[06:05] <infinity> pitti: Was Debian's still 4.6?  Same version of QT?
[06:06] <pitti> so 4.7 on arm on Ubuntu is special somehow
[06:06] <pitti> infinity: haven't checked that; sid has been on 4.7 for quite some time, though; Qt might have been different
[06:07] <infinity> pitti: I see gcc/g++ 4.6 in the build logs for your cups uploads in sid.
[06:07] <SpamapS> infinity: good news, it appears MySQL 5.5.25 works fine with gcc 4.7
[06:07] <SpamapS> infinity: so I think we can drop the build-dep on 4.5 this week
[06:07] <infinity> pitti: Unless sbuild is lying, which it might be.
[06:08] <infinity> SpamapS: \o/
[06:08] <infinity> SpamapS: We dropped the 4.5 build-dep for u-boot too.
[06:08] <infinity> SpamapS: Shame we couldn't do it in precise, but oh well.
[06:08] <SpamapS> stubborn people unwilling to fix their code will probably thank us for that
[06:10] <micahg> pitti: gcc on arm in Debian is 4.6 still
[06:11] <pitti> micahg: ah, how helpfully inconsistent; optional symbols it is then :)
[06:11] <micahg> pitti: well, I think doko pushed the envelope as far as he could with the freeze looming :)
[06:27] <SpamapS> hm ok well digging through apt-file searches, I think mysql is the only versioned package that owns an apparmor profile
[07:05] <dholbach> good morning
[07:13] <apw> pitti, ahh yess i have that cups fix in a branch, i came to pass it to you and you were offline (gasp) and i forgot about it!
[07:15] <apw> pitti, this branch is the cups fix i was proposing, dispite the base that launchpad _thinks_ its against it i actually based on yur bzr.debian.org branch: https://code.launchpad.net/~apw/debian/sid/cups/trunk-fix-armel-ftbs
[07:18] <pitti> apw: ah, thanks!
[07:18] <apw> pitti, i hope that was evidence of you having a vacation :)
[07:18] <pitti> apw: yeah, I took Thu/Fri off, and for four days I rather disconnected IRC
[07:19] <apw> pitti, that is probabally the first time i have seen you offline in 4 years, about time
[07:19] <pitti> heh
[07:19] <pitti> apw: I did disconnect myself over summer and christmas holidays
[07:19] <apw> pitti, well all grow up eventually :)
[07:20] <apw> pitti, if you have comments etc just yell and i can change and retest
[07:21] <skunk> hi all. Question: Will 12.04 improve on performance?
[07:23] <skunk> you know as updates come in over the months?
[07:23] <apw> skunk, that is a really hard question to answer, cirtainly for me it is not slower than what we had before
[07:24] <skunk> apw: i wish I could say the same thing, 10.04 was alot faster in boot then 12.04
[07:24] <skunk> I know i am comparing an old os to a new though
[07:26] <apw> skunk, there may have been some regression there, more likely any regression of that nature will get fixed in later releases, but if its a lot it may be worth investigating, bootchart is a tool to profile boots which if you have the old and new to compare may help understand whether its something easily fixable
[07:27] <pitti> apw: thank you! merged with dropping the -1 suffixes from the .symbol
[07:30] <skunk> okay apw. one last question. I might sound like a noob.. but i really want some clarification
[07:31] <skunk> if we optimized ubuntu to work really fast on HDD, would it automatically make thing faster if runnign on SSDs??
[07:31] <skunk> make it faster***
[07:31] <apw> skunk, not necessarily.  ureadahead for instance detects which you have and changes behaviour based on the disk type, because each has different optimal access patterns
[07:32] <skunk> and of course readahead can be used on both SSDs and HDDS
[07:32] <skunk> eh?
[07:33] <apw> yes readahead is used on both types, how it does its readahead is modified
[07:34] <skunk> okay makes sense.. sorry for my typos btw. its the middle of the night here in Canada
[07:43] <skunk> apw, this might be a stupid question
[07:43] <skunk> How do u set up readahead? Ive been using linux for years and I always read about it here and there..
[07:43] <apw> it is setup by default on ubuntu
[07:44] <skunk> oh so theres nothing I could do right now?? Readahead is running??
[07:44] <apw> skunk, should be indeed
[07:45] <skunk> apw, thanks.
[08:18] <vibhav> mterry: ping
[08:40] <dholbach> ajmitch, happy birthday! :)
[08:50] <ajmitch> heh, thanks
[08:52] <mvo> @pilot in
[08:56]  * dholbach hugs mvo
[09:00] <vibhav> yay!
[09:19] <vibhav> dholbach: Done: https://bugs.launchpad.net/ubuntu/+source/predict/+bug/1012006
[09:24] <iulian> dholbach: Where did you know that from? You're not spying on him, are you? :)
[09:24] <iulian> ajmitch: Happy birthday! Having a party? Free food, free booze? Can I join?
[09:27] <dholbach> iulian, facebook :)
[09:27] <iulian> Ah, that does make sense now. :)
[09:28] <dholbach> vibhav, I'm a bit busy with some other things right now - can you subscribe ubuntu-sponsors?
[09:53] <vibhav> mvo: Are you busy?
[09:58] <mvo> vibhav: medium busy :) what can I do for you?
[09:58] <xnox> mvo: pushed lp:~dmitrij.ledkov/apt-btrfs-snapshot/py3 addressing your merge review comments
[09:59] <mvo> xnox: very nice, thanks
[09:59] <xnox> mvo: it now works with python-mock 0.7 ;-) checked in precise pbuilder
[10:06] <mvo> xnox: very nice, looks great, merged
[10:06] <xnox> mvo: \0/
[10:06] <xnox> =)
[10:07] <xnox> mvo: do a release / upload to quantal?
[10:07] <mvo> xnox: yes, I can do that now
[10:07] <xnox> mvo: \\0//^2
[10:09] <mvo> :)
[10:19] <nigelb> soren: Happy Birthday! \o/
[10:35] <soren> nigelb: Thanks :)
[10:42] <xnox> mvo: it FTBFS... *sigh*
[10:46] <mvo> :(
[10:53] <cjwatson> mvo: Your update-manager r2457 only seems to solve the problem in one site out of several affected - what do you think of http://paste.ubuntu.com/1036971/ ?  Works at least back to python-apt 0.7.93.1, which is already within our dependency range
[10:55] <mvo> cjwatson: looks good but I think we should add super() in the DistUpgradeView*.py stuff as well
[10:55] <mvo> cjwatson: you are right, my fix only touched update-manager itself
[10:56] <mvo> cjwatson: otherwise it looks good
[10:56] <nigelb> Daviey: around?
[10:56]  * mvo is away for some minutes to get lunch
[10:56]  * nigelb leaves a message for Daviey in PM.
[10:57] <cjwatson> Oh, I see that OpProgress uses the percent=None pattern, so I should follow that I guess
[10:57] <cjwatson> Seemed kind of an odd approach to me but whatever
[11:01] <Daviey> nigelb: o/
[11:02] <nigelb> Daviey: left you a PM!
[11:03] <cjwatson> mvo: So maybe http://paste.ubuntu.com/1036990/ ?
[11:04] <cjwatson> mvo: Er, sorry, http://paste.ubuntu.com/1036991/
[11:14] <dholbach> soren, happy birthday! :)
[11:18] <xnox> mvo: pushed a branch to fix FTBFS
[11:31] <soren> dholbach: Thanks! :)
[11:42] <mvo> cjwatson: thanks, that looks great
[11:42] <mvo> xnox: ta, let me merge
[11:50] <cjwatson> mvo: ta, committed in r2460
[12:00] <vibhav> mvo: Sorry for being AFK, If you are not busy, could you please have a look at https://bugs.launchpad.net/bugs/1012006 ?
[12:04] <vibhav> "The fact that it's actually pretty social, and I get to call people names, is just a bonus." -- Linus Torvalds
[12:05] <vibhav> whoa, wrong channel :(
[12:07] <Riddell> vibhav: voila (on qalculate), thanks for helping ubuntu
[12:09] <vibhav> Riddell: You uploaded it?
[12:09] <Riddell> vibhav: yes
[12:09] <vibhav> thanks man
[12:10] <vibhav> Riddell: You dropped the Breaks/Replace and the debhelper version diff?
[12:10] <Riddell> vibhav: yep
[12:10] <vibhav> So, the only changes were in the debian/rules right?
[12:10] <Riddell> vibhav: yep
[12:11] <vibhav> cool
[12:11]  * vibhav hugs Riddell 
[12:11] <Riddell> mmm
[12:16] <mvo> vibhav: sure, I check it out
[12:16] <vibhav> thanks!
[12:20] <dholbach> can an archive admin review ubuntu-packaging-guide and pkgme please (new)? :)
[12:28] <vibhav> dholbach: You are an archive admin, right?
[12:28] <dholbach> no
[12:28] <vibhav> I thought you were one
[12:29] <dholbach> no, I don't have that particular set of keys :)
[12:32]  * vibhav hugs mvo
[12:41] <vibhav> cjwatson: You were the last guy to touch libept in Ubuntu, Could I preapre a merge for it or do you want to do it?
[12:42] <doko> Sweetshark, for issue 1007616, did you try to build on amd64 as well?
[12:43] <cjwatson> vibhav: I would prefer to leave it to mvo or to whoever's dealing with the apt merge.
[12:43] <vibhav> apt merge?
[12:43] <cjwatson> Yes.
[12:43] <vibhav> What is that?
[12:43] <cjwatson> The merge of apt.
[12:44] <vibhav> ah, got it
[12:44] <xnox> apt the next generation DVCS
[12:44] <cjwatson> apt tends to change its ABI on significant version changes and require packages to be rebuilt against it; libept is one of those packages, so might as well do that at the same time.
[12:44] <vibhav> fine, Ill see for another package
[12:45] <cjwatson> The Ubuntu delta to libept can be discarded rather than merged when the time comes.
[12:46] <vibhav> cjwatson: What about libedit?
[12:46] <cjwatson> vibhav: I would prefer that you didn't take any of my merges.
[12:46] <cjwatson> I'm able to cope with them.
[12:47] <vibhav> fine
[12:47] <cjwatson> Thanks all the same
[12:49] <cjwatson> (Synced libedit now.)
[12:49] <xnox> jdstrand: what apport version will be released with quantal?
[12:50] <xnox> i have made a python2/3 bilingual merge proposal to lp:apparmor
[12:50] <pitti> xnox: I really don't know yet
[12:50] <xnox> but I now noticed the the /2.8 and /2.7 branches, with quantal having 2.7
[12:50] <pitti> apport versioning is pretty much up to my mood
[12:50] <pitti> oh, ITYM apport -> apparmor?
[12:50] <xnox> yes
[12:51] <xnox> above lines should be apparmor =)
[12:51] <ogra_> what ? they arent the same ?
[12:51] <xnox> pitti: sorry for confusion
[12:51] <ogra_> :P
[12:51] <pitti> xnox: np :)
[12:51] <xnox> jdstrand: what *apparmor* version will be released with quantal? =)
[12:51] <ogra_> both are for iOS, right ? since they start with the name "app"
[12:51] <ogra_> :P
[12:52] <xnox> ogra_: now you are confusing apparmor with iArmor and iApport
[12:52] <pitti> nah, can't; apport actually tells you what's going on :)
[12:52] <ogra_> oh, indeed :)
[12:53] <vibhav> infinity: You there?
[12:55] <ScottK> I think infinity is getting his beauty sleep.
[12:58] <vibhav> When one becomes a Contributing Developer, he becomes an Ubuntu Member too, right?
[12:59] <Laney> that is, in fact, the point of contributing developer
[13:01] <xnox> vibhav: yes.
[13:11] <SpamapS> infinity: spoke too soon.. still segfaulting on i386 w/ gcc 4.7 :(
[13:13] <Sweetshark> doko: yes, but that buildd failed due to running out of fs space IIRC, so I canceled it ...
[13:16] <nemo> Hey, how would I find out if Ubuntu has picked up https://bugzilla.gnome.org/show_bug.cgi?id=673749 ?
[13:16] <nemo> 'cause those notification daemon crashes in 12.04 are driving us all nuts
[13:16] <nemo> I've been googling launchpad, but not found anything yet
[13:17] <Sweetshark> hmm, anyone recently tweaked around libmysqlclient-dev? it seemed to have installed just fine on i386, but failed to install on amd64 with "libmysqlclient-dev : Depends: libmysqlclient18 (= 5.5.25-0ubuntu1) but it is not going to be installed" ?
[13:17] <jibel> doko, I did too. It builds on amd64.
[13:18] <jibel> then make check failed with a java segfaults and a DisposedException but that's another story
[13:18] <Sweetshark> hohum, mysql 5.5-0ubuntu1 is just 6 hours old ...
[13:19] <cjwatson> It failed to build on i386.
[13:19] <cjwatson> That'll have meant that any Architecture: all packages are out of sync.
[13:20] <cjwatson> Hopefully SpamapS will have notice; he got mailed.
[13:20] <cjwatson> *noticed
[13:20] <doko> jibel, that is LO?
[13:20] <jibel> doko, yes
[13:20] <SpamapS> indeed I think we'll have to continue to build it w/ gcc 4.5 until it can be figured out
[13:20] <Laney> he just said a few lines above :-)
[13:20] <cjwatson> Yeah, I didn't have context for what was segfaulting
[13:20] <SpamapS> indeed I got the build failure and I believe its an old upstream bug unfortunately
[13:21] <SpamapS> Not one we can keep dodging .. I wonder if we can patch this
[13:21] <SpamapS> upstream seems pretty uninterested in addressing it :-/
[13:27] <SpamapS> http://bugs.mysql.com/bug.php?id=61509
[13:27] <SpamapS> Thats the issue btw.. upstream seems to think it was resolved but I think not. :-/
[13:34] <SpamapS> hm, no, its this issue http://bugs.mysql.com/bug.php?id=65432
[13:45]  * ScottK glares at SpamapS.
[13:45] <ScottK> (mysql just caused my soprano upload to FTBFS on !i386)
[13:50] <SpamapS> ScottK: working on it
[13:50] <SpamapS> looks pretty nasty
[13:50] <ScottK> Thanks.
[13:51] <SpamapS> I may have to disable some tests just to get the archive back in order
[13:53] <ScottK> That would certainly solve my problem.  The soprano build doesn't actually use mysql, I just need it installable so  librdf0-dev is installable.
[13:54] <SpamapS> yeah libmysqlclient-dev is currently the wrong version because i386 failed
[13:54] <SpamapS> I think I'll disable those tests.. I have Norvald Ryeng from Oracle helping me with the upstream issue.. but thats not going to be solved in a short time period
[13:54]  * SpamapS opens critical bug first
[14:27] <SpamapS> ScottK: test rebuild has commenced, time for breakfast. ;)
[14:28] <ScottK> Excellent.
[14:31] <xnox> mvo: did you have a chance to look at https://code.launchpad.net/~ev/apt-clone/python3/+merge/109672 ?
[14:31] <slangasek> mvo: hi, which "our own code" do you think might still need porting to the python-apt 0.8 api?
[14:38] <mvo> slangasek: some bits and piece in the quirks code of the release upgrader code I could imagine, I think we are well covered by now but double checking is a good idea
[14:39] <cjwatson> I'm fairly sure I've got most of it
[14:39] <cjwatson> I went over the output of /usr/share/python-apt/migrate-0.8.py with a fine tooth-comb
[14:39] <cjwatson> (Wait, that must be "fine-tooth comb".  Doesn't make a lot of sense hyphenated the other way.)
[14:39] <mvo> xnox: not yet, can have a look now
[14:40] <mvo> cjwatson: aha, excellent!
[14:40] <cjwatson> mvo: update-manager itself is runnable with python3 now, although the upgrader will need some more work
[14:41] <mvo> cjwatson: yeah, I managed to get the text frontend of the release upgrade to a certain point, but there were some oddities around some of the input handling and I did not looked further
[14:42] <cjwatson> Input handling?
[14:45] <cjwatson> mvo: I'm about to rearrange the gettext stuff in an attempt to make it not nightmarish to port to py3 :)
[14:46] <slangasek> tooth combing is a lost art
[14:46] <slangasek> mvo, cjwatson: cool, sounds like I can just pull the Debian python-apt in then
[14:54] <ogra_> bryceh, hey, so during our foundationd py3 porting sprint i ported xdiagnose, i can fire it up from a terminal and get a nice gtk window, is there anything else i could test to make sure the py3 porting didnt break it ?
[14:54] <ogra_> *foundations
[15:05] <barry> pitti: hi.  did i see that you completed the port of foomatic-db-compressed-ppds?  has it been uploaded?  (i want to turn that row of the spreadsheet green)
[15:10] <roaksoax> does anyone have any experience packaging javascript?
[15:20] <xnox> roaksoax: there is js policy, generally the package should be names libjs-yetanotherjquery and ship stuff in the /usr/share/libjs/yetanotherjquery
[15:20] <xnox> or something like that
[15:20] <xnox> roaksoax: look at the, e.g. jquery-* packages? =)
[15:20] <roaksoax> xnox: yeah I already saw that, though I have a depereusttons when it comes tto versioning
[15:21] <xnox> roaksoax: 1-1, is always good =)
[15:21] <xnox> roaksoax: next upload into debian 2-1
[15:21] <roaksoax> xnox: lol... didn't mean that
[15:21] <xnox> works like a charm ;)
[15:21] <xnox> roaksoax: my dictionary didn't parse depereusttons by the way
[15:22] <roaksoax> xnox: I mean as in "XYZ needs to access the patch in a way like js/js-version/build/"
[15:22] <roaksoax> xnox: however it installs as in: "js/*.js"
[15:22]  * xnox hides
[15:22] <roaksoax> s/patch/path
[15:22] <roaksoax> xnox: hehe :)
[15:27] <infinity> SpamapS: So, MySQL?
[15:27] <slangasek> crunchy and good with drop tables
[15:28] <infinity> SpamapS: I figured you'd have uploaded a quick compiler revert by now or something. :P
[15:30] <ScottK> infinity: About an hour ago: [10:27:04] <SpamapS> ScottK: test rebuild has commenced, time for breakfast. ;)
[15:30] <infinity> Bah.  People and their breakfast.
[16:16] <micahg> SpamapS: how about gcc-4.6 for mysql?  gcc-4.5 was about to drop out of main and I was going to get rid of it (obviously if 4.6 doesn't work, that's fine too)
[16:19] <bryceh> ogra_, sweet.  if the gui comes up that covers a lot of the code.  one other thing to test would be the test suite - ./run-tests.  That'll verify the apport hooks generate bug reports and so on.
[16:22] <SpamapS> micahg: I'll try that if Oracle can't figure it out, but they've agreed to look at it now that we can reproduce
[16:23] <SpamapS> re-running the test suite *again* ugh
[16:23] <doko> chrisccoulson, replied to the c++ compat issues. can nux/unity built in c++98 mode?
[16:23] <chrisccoulson> doko, thanks
[16:23] <doko> SpamapS, I think it did fail with 4.6 as well
[16:24] <chrisccoulson> doko, unity / nux isn't really my call, but i think they're already using C++11 features
[16:24] <doko> chrisccoulson, this will be a pain in the ass to fix for all packages :-/
[16:24] <SpamapS> It appears to be something with the hand-optimized yassl code
[16:24] <chrisccoulson> yeah, i can imagine
[16:24] <SpamapS> I wonder if we can just switch i386 to use the "portable" version and let gcc optimize it
[16:26] <doko> yeah, that would be nice
[16:26] <cjwatson> pitti: Do you know the status of ubuntu-drivers-common for Python 3?  It seems to be kind of halfway there
[16:29] <doko> SpamapS, http://pkgs.fedoraproject.org/gitweb/?p=mysql.git "Fix several strcpy calls to check destination size" sounds suspicious, however I don't know which of these patches are in Debian or upstream
[16:29] <vibhav> mterry: ping
[16:30] <mterry> vibhav, hi
[16:32] <SpamapS> doko: fedora doesn't use the bundled SSL of MySQL IIRC.. they link to openssl.. so theyw on't be affected by this
[16:32] <doko> SpamapS, and why don't we do this?
[16:33] <doko> Sweetshark, I see you build LO in c++11 mode as well. Don't do that ...
[16:33] <SpamapS> doko: I've not looked at it very closely. In the past it caused issues with the test suite.
[16:34] <vibhav> mterry: AFAIK, you were the last guy to touch bcov in Ubuntu. Since Debian has released a new version, Are you comfortable with me preparing a merge?
[16:34] <vibhav> Or Do you want to do it?
[16:34] <SpamapS> doko: If we can't resolve this issue it might be an option, but not one I want to choose lightly.
[16:35] <mterry> vibhav, I wasn't planning on getting to it soon, so if you're game, that'd be swelL!
[16:35] <vibhav> sure, thanks
[16:37] <seb128> hum, my system is using 3G of memory according to top but I closed almost everything running and top sorting show no big users
[16:37] <seb128> does anyone know how to figure what's going on?
[16:38] <seb128> that seems to happen regularly after I build gtk or glib on my precise system, the box gets really slow at everything it's doing as well
[16:38] <seb128> I'm wondering if that's a kernel issue but I'm unsure what infos would be useful
[16:40] <vibhav> seb128: Have you checked the processes via the system monitor?
[16:41] <seb128> vibhav, it's not different from top
[16:41] <vibhav> ah
[16:41] <vibhav> what kernel?
[16:42] <vibhav> the one in the repos or a custom compiled
[16:43] <seb128> vibhav, stock precise from the archive with SRus applied
[16:47] <vibhav> do you have an old kernel installed, try that too
[16:48] <vibhav> mterry: Done: https://bugs.launchpad.net/ubuntu/+source/bcov/+bug/1012238
[16:51] <hippiehacker> cjwatson: are you around? I'm looking for some clarification around the 12.04 image build process, https://answers.launchpad.net/ubuntu/+source/live-build/+question/200206
[16:53] <ogra_> bryceh, ah, awesome, thanks, seems i still have some more work to do :)
[16:53]  * ogra_ got two tracebacks during the tests
[16:53] <bryceh> ogra_, I'm happy to lend a hand if needed
[16:54] <ogra_> ah, i'll get along i think, but a review in the end would be nice indeed :)
[16:54] <bryceh> ogra_, ok great
[16:57] <Sweetshark> doko: could you elaborate? I guess upstream wants to go to c++11 ASAP anyway ...
[16:57] <cjwatson> hippiehacker: answered briefly; I'm in a sprint until Wednesday so not a lot of time
[17:00] <hippiehacker> cjwatson: thanks again
[17:03] <SpamapS> ugh.. disable the tests that fail one time.. and a few intermittent failures start showing up
[17:15] <doko> chrisccoulson, cnd: woult it be possible to construct a test case for the std:list issue, like the one from the referenced GCC report?
[17:16] <cnd> doko, what do you mean?
[17:23] <SpamapS> ugh I'm trying like 6 different things to fix this silly i386 issue
[17:23] <SpamapS> patching out the Pentium Optimizations.. building with gcc 4.6 ..
[17:23] <SpamapS> building with 4.5 ..
[17:24] <infinity> SpamapS: Building with 4.5 doesn't "fix" it? :/
[17:24] <SpamapS> infinity: takes an hour to figure that out even on good hardware :-P
[17:24] <SpamapS> and I'm out of good CPU's .. now u sing EC2 instances ;)
[17:25] <infinity> SpamapS: Wait, we're using a bundled openssl?
[17:25] <SpamapS> no
[17:25] <SpamapS> bundled yassl
[17:26] <SpamapS> which is what almost all mysql users use
[17:26] <infinity> Well, a bundled something SSL. :P
[17:26] <SpamapS> yeah
[17:26] <SpamapS> I will also try an openssl linked build
[17:26] <SpamapS> but I hate diverging from upstream :P
[17:28] <infinity> I'm fond of the archive being installable. ;)
[17:29] <ogra_> boring :P
[17:33] <SpamapS> ok, gcc 4.6 still shows the problem
[17:35] <SpamapS> so does patching out the hand optimized taocrypt stuff
[17:35]  * SpamapS gets his gdb on
[17:41] <jtaylor> why does a foreign glib-dev pull in a foreign python?
[17:42] <jtaylor> via recommends, kind of dangerous as it conflicts with native python and breaks your system when not aborted
[17:43] <SpamapS> damn, gcc 4.5 does fix it :-/
[17:43] <slangasek> jtaylor: why don't you have Install-Recommends disabled in your development environment? :)
[17:45] <jtaylor> well I'm familiar with the issue, but many others aren't
[17:45] <jtaylor> unfortunately glib is at the bottom of many dependency chains
[17:46] <jtaylor> bug 1012229 for a recent example, if seen others stumbling over that too
[17:47] <slangasek> right, well, I don't see at a glance what's pulling in python... but the right answer isn't to remove valid Recommends
[17:47] <jtaylor> apt-cache depends glib2.0-dev | grep python
[17:48] <jtaylor> oh you meant what in glib needs it
[17:48] <jtaylor> would it make sense to make python m-a foreign?
[17:49] <cjwatson> It's the canonical case where that's difficult.
[17:49] <slangasek> absolutely not
[17:49] <cjwatson> Quite literally - it's in the spec.
[17:49] <cjwatson> Hey, we can start deploying M-A: allowed in Depends now though, can't we?
[17:50] <cjwatson> Modulo stuff like germinate maybe.
[17:50] <cjwatson> :any, I mean.
[17:50] <cjwatson> (For those unfamiliar: we couldn't use the full syntax in precise, because it would have broken upgrades from lucid.)
[17:50] <slangasek> ooh yes
[17:51] <cjwatson> Patch to germinate welcome ;-)
[17:51] <cjwatson> At least to make it ignore it and follow down the same arch.  Bonus points if you can figure out how to make it work with lucid's python-apt for Launchpad, which is what I got stuck on last time I tried.
[17:51] <cjwatson> Although maybe that doesn't matter too much./
[18:00] <infinity> SpamapS: If gcc-4.5 "fixes" it, can we get that uploaded ASAP?
[18:00] <SpamapS> infinity: yes I'm just verifying that it doesn't break anything else
[18:00] <infinity> It can't possibly make things worse than they are now. ;)
[18:00] <SpamapS> build shoudl be done in 15m
[18:04] <SpamapS> infinity: btw, the reason we don't link mysqld to openssl is that Debian believes it is not allowed.
[18:04] <SpamapS> I don't know why fedora/rh think it is.
[18:05] <micahg> did they get permission?
[18:07] <infinity> SpamapS: I thought MySQL has an openssl exception in the license...
[18:07]  * infinity might be misremembering.
[18:08] <xnox> infinity: community edition or the proprietary one....?
[18:08] <infinity> xnox: Community.
[18:09] <SpamapS> IIRC the problem isn't mysql not wanting openssl, but openssl not granting MySQL an exception
[18:09] <infinity> We used to maintain a libmysqlclient fork specifically for this reason, I thought.  So one could link OpenSSL and one not, for GPL applications that needed libmysqlclient but couldn't link openssl.  But.  I'm getting old.  I could actually be entirely forgetting why we did all that.
[18:09] <infinity> SpamapS: openssl doesn't have to grant exceptions, only the other way.
[18:10] <infinity> SpamapS: It's the openssl license that violates the GPL without a linking exception.
[18:10] <infinity> But, maybe someone decided it was all just not worth the hassle.
[18:10] <infinity> And using another SSL implementation doesn't bug me all that much, it's just irksome that it's embedded.
[18:10] <micahg> http://dev.mysql.com/doc/refman/5.5/en/secure-using-ssl.html seems to imply that mysql wants to allow linking against openssl
[18:11] <SpamapS> Yeah, I was given the impression that openssl's license made that a no-no
[18:11] <infinity> micahg: It could just be that the Debian MySQL maintainers gave up with the transitive issue (GPL applications linking libmysqlclient, linking openssl)
[18:11] <SpamapS> but mysql's exception does allow linking with openssl
[18:11] <SpamapS> http://bugs.mysql.com/bug.php?id=8249
[18:12] <SpamapS> infinity: RIGHT that is likely it.
[18:12] <SpamapS> double ugh
[18:12] <infinity> SpamapS: I do so love when people link bugs with my name in the log.  It's nostalgic.
[18:13] <SpamapS> ok so there is a giant mass of inline assembly in yaSSL that gcc 4.6 and later seem to not like
[18:13] <micahg> wait, so based on that bug, why doesn't Debian just use openssl?
[18:14] <SpamapS> micahg: transitive?
[18:14] <micahg> hrm, I guess I"ll have to read the 8 year old thread about it
[18:15] <infinity> micahg: MySQL allowing an exception to link is fine, right up until you link another GPL application to libmysqlclient, then that application ALSO needs an exception.
[18:15] <micahg> ah, right
[18:16] <infinity> Which, actually, isn't that bug at all.
[18:16]  * SpamapS tries building with TAOCRYPT_DISABLE_X86ASM defined
[18:16] <infinity> The bug SpamapS was referencing was when they changed the library from LGPL to GPL, thus cutting off non-GPL applications from linking, and they had to give an exception for that.
[18:17] <infinity> (Which made no sense, IMO, given that the end result of the GPL+linking exception more or less turned it into the LPGL, in practice)
[18:17] <infinity> But whatever.
[18:17] <infinity> Licenses are hard.
[18:17] <mdeslaur> we should just stop upgrading gcc, life would be so much simpler :)
[18:18] <infinity> SpamapS: Upload something using gcc-4.5, then keep hunting the problem? :P
[18:18] <infinity> Or I can...
[18:19] <infinity> But since you tested... And presumably have sources.
[18:19] <SpamapS> infinity: I'm waiting for my 4.5 test build to finish, not waiting on my other solutions
[18:19] <infinity> Ahh.  I thought you implied up there that it worked.
[18:20] <SpamapS> The tests that failed before did not this time
[18:20] <SpamapS> but they are run with several different arguments..
[18:20] <SpamapS> and I want to make sure nothing else broke so I can upload and then go take a nap ;)
[18:26] <SpamapS> ok tests passed
[18:26]  * SpamapS prepares to upload
[18:29] <SpamapS> ok, uploaded
[18:38]  * infinity scores up mysql-5.5...
[18:48] <davidcalle> ev, hi, I see you are taking care of the videos lens py3 port, I was waiting for libdee to be fixed on py3 to do it. Thanks ! :)
[18:56] <utlemming> packaging question: if a package needs relies on a kernel module being loaded on boot, is the proper way to put the module in /etc/modules?
[18:57] <BenC> utlemming: Check qemu-kvm package for how to makes sure to load the correct kvm module
[18:57] <utlemming> BenC: thank you kindly :)
[18:57] <BenC> utlemming: You should not touch /etc/modules for sure (packages can't modify conffiles of another package)
[18:58] <BenC> utlemming: No problem…hint, qemu-kvm uses an init script, so it loads the modules at boot
[18:59] <utlemming> that's what I figured....I'm pulling the code now
[19:05] <SpamapS> infinity: TAOCRYPT_DISABLE_X86ASM seems to solve the problem with gcc 4.7
[19:07] <infinity> SpamapS: At a pretty unfortunate performance loss, I'd assume.
[19:07] <hallyn> hi - any chance i coudl get someone to take a peek at bug 1010069 ?
[19:08] <infinity> If only we had an asm-tuned SSL library that we knew worked...
[19:09] <SpamapS> infinity: yeah, I reckon 2x actually.. doing some further tests now :-/
[19:09] <infinity> hallyn: *raise brow*
[19:09] <infinity> hallyn: That would be broken on precise too, then.  Unless kvm didn't need those defines in precise?
[19:09] <hallyn> it is
[19:09] <hallyn> in precise we worked aroudn it by manually defining it
[19:09] <SpamapS> Ugh, try 4x slower.. :(
[19:09] <hallyn> i'd like to stop doing that :)
[19:10] <infinity> hallyn: If we knew about it in precise, why didn't someone tell me then? :P
[19:10] <infinity> hallyn: Anyhow, will look into it.
[19:10] <hallyn> infinity: I didn't understand the cause of th eproblem then
[19:10] <infinity> SpamapS: Not shocking.
[19:11] <SpamapS> so has some kind of convention changed in 4.6/4.7 that requires asm writers to adapt?
[19:11] <hallyn> infinity: I did raise it a few times, think I brought it up in ubuntu-kernel, and there was another bug oepned
[19:13] <infinity> SpamapS: I'd say not that I know of, but I guess obviously yes. :P
[19:13] <infinity> SpamapS: (Or, rather, something got more strict, and bad inline breaks, I assume)
[19:13] <infinity> hallyn: Alright.  Well, thanks for hunting it down.  I'll probably add this to my pending SRU as well as fixing it in Q.
[19:14] <hallyn> infinity: thanks!
[19:23] <ScottK> barry: Any chance you'd have time to convert cython from python-support to dh_python2?  Cython's in Main now, so it needs doing.
[19:24] <barry> ScottK: possibly, but not today.  can you open a bug on it and assign it to me.
[19:25] <ScottK> Will do.   Thanks.
[19:26] <barry> ScottK: np
[19:27] <ScottK> Done.
[19:45] <tkamppeter> Anyone expert about apt-get and package repositories? In bug 995111, comment #18, why does cups 1.5.3-0ubuntu2~ppa3 not get installed? What does the user have to do here?
[19:48] <slangasek> tkamppeter: that looks like they have apt pinning in place on their system (/etc/apt/preferences) which forces the ppa version to not be considered a candidate
[19:51] <tkamppeter> slangasek, thanks, can you comment on the bug telling the user how to proceed? Thanks.
[22:33] <BenC> Anyone know if python-support is planned for main inclusion?
[22:33] <BenC> Seeing as cython depends on it
[22:33] <micahg> BenC: barry has a bug for it, it's not meant to be in main
[22:33] <doko> BenC, no, please use dh_python2
[22:34] <micahg> BenC: and thanks for all the powerpc fixes :)
[22:34] <BenC> I'm just trying to fix some build failures for packages that depend on cython, and python-support is the reason it's uninstallable for build-deps
[22:34] <BenC> micahg: no problem
[22:34] <barry> jtaylor: submitted a debdiff on bug 1012331 but i won't be able to do anything about it today.  if someone wants to beat me to it...
[22:34] <BenC> What's the proper fix here?
[22:34] <BenC> Ah
[22:35] <BenC> barry: I'm on it...
[22:35] <micahg> ah, I forgot the -dbg package when I tried it :)
[22:35] <barry> BenC: awesome, thanks
[22:42] <skunk> how do you modify default window dimensions?
[23:15] <killown> how can I deal with this issue https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/973610 since I need install ubuntu 12.04 and nouveau driver don't let me do that
[23:16] <killown> it would at least fallback to vga mode...