[00:02] <SpamapS> oh I just love test suites that assume code will never survive past 2010
[00:03] <SpamapS> this is the second time I've seen such nonsense
[00:04] <SpamapS> especially when they've made a release as recent as 2008
[00:04] <StevenK> SpamapS: We had a bug in the LP testsuite that used to assume a blueprint created in 2011 was in the future.
[00:05] <SpamapS> in the yeaar two thousaaaaaannndd
[00:05] <StevenK> I had successfully not thought about that song for years until you said that.
[00:08] <SpamapS> http://www.youtube.com/watch?v=LQRmkoBpi28
[01:12] <BenC> My lp-bug mojo is a little rusty….how do I link a bug to a Debian bug?
[01:13] <ajmitch> 'also affects distribution', select debian & paste the debbugs url in, iirc
[01:14] <BenC> Thanks, just figured it out :)
[01:15] <lifeless> or just past the url into a comment
[01:16] <ajmitch> lifeless: that adds the debian task automatically?
[01:17] <lifeless> it adds a watch automatically, which is the key thing
[02:54] <ScottK> SpamapS: Thanks for fixing mysql-5.5 sufficiently that I'm not required to care anymore.
[02:55] <infinity> ScottK: Thanks for fixing cython, and congrats on cleverly avoiding TILM by puppeting Ben. :P
[02:55] <ScottK> I actually managed to not do any work on it at all.
[02:55] <ScottK> Major victory.
[02:55] <ScottK> Mission accomplished by whining.
[02:56] <infinity> ScottK: Ahh, he misattributed the patch.  I'm sure jtaylor is crushed.
[02:56] <ScottK> I didn't get get the barry card.  He was going to look at it tomorrow, but now he doesn't have to.
[02:56] <ScottK> Yeah.
[02:56] <ScottK> I mentioned it in the bug.
[02:56] <infinity> All that hard work changing four lines. ;)
[02:56] <ScottK> The work avoided by not being TIL is potentially infinite.
[02:57] <infinity> Heh.
[02:57] <micahg> and I already had all that except for cython-dbg in debian/rules
[02:57] <ScottK> jtaylor should be happy though.  Now he can apply guilt on BenC when he wants a core-dev endorsement.
[02:58] <infinity> Ben's immune to guilt.
[02:58] <infinity> He does respond well to nicotine and cartoons, however.
[02:58] <BenC> and jaeger
[02:59] <BenC> Combinations of the three in creative ways are welcome
[02:59] <infinity> Heh.
[02:59] <infinity> BenC: You really need to come hang out at some conferency gathering soon.  Haven't seen you in ages.
[03:00] <BenC> infinity: I tried to get to quantal UDS but it didn't work out. I am 94.7% sure I will make UDS-R though
[03:01] <ScottK> I hope the hold it in some place cool enough that I'll feel like it's worth wanting to go.
[03:01] <ScottK> I mean Oakland?
[03:01] <broder> i liked that it was close
[03:02] <broder> but yeah, meh
[03:02]  * BenC is still hoping for the cow-pasture-uds
[03:02] <BenC> Will give BoF a new meaning
[03:03]  * micahg wonders what interesting locations there are
[03:04] <StevenK> I'd say Sydney, but infinity would stab me.
[03:04] <infinity> We've been.
[03:04] <StevenK> Only once. UDS has been in *Florida* more than that.
[03:05] <infinity> It's also hideously expensive to do anything other than Europe or North America.
[03:05] <infinity> StevenK: Yeah, and Florida was a mistake every time. :P
[03:05] <ScottK> Boston was nice.
[03:05] <StevenK> Florida was slightly better than Dallas.
[03:06] <infinity> UDU (Sydney) was actually pretty good.  The hotel was fun, etc.  But that was back when the distro team was 15 people.
[03:06] <ScottK> Yes.
[03:06] <infinity> Cool little venues like that don't work anymore. :(
[03:06] <infinity> And Sydney's large conference venues are just as soulless as anyone's.
[03:06] <ajmitch> but they're closer for some of us
[03:06] <infinity> Not many of us. :P
[03:06] <ScottK> Chicago would be fun for a US location.
[03:06] <micahg> \o/
[03:07] <StevenK> ScottK: I'd like to see Chicago, actually.
[03:07] <infinity> If it didn't come right back around to the "hideously expensive" point, I'd vote for Manhattan.
[03:07] <micahg> infinity: they managed DebConf there somehow
[03:07] <infinity> micahg: Yeah, but DebConf doesn't mind begging universities for lecture halls.
[03:07] <infinity> micahg: We annex entire conference centers.
[03:08] <ScottK> Precisely.
[03:08] <infinity> micahg: Those don't come cheaply.
[03:08] <ScottK> Except in Florida.  There they are so huge we only get a little piece of one.
[03:08] <infinity> ScottK: Heh.
[03:08] <ScottK> I've never been to Warsaw.  How would that be?
[03:08] <infinity> Bleak.
[03:09] <infinity> Culturally awesome, love the people, the music, the food.  But man, the architecture makes me want to stab myself repeatedly.
[03:09] <ScottK> Are you arguing for or against?
[03:09] <infinity> I'm not sure. ;)
[03:10] <ScottK> That's just good street theater for some.
[03:10] <infinity> I actually pretty much never say no to former Eastern Block sorts of locations.
[03:11] <infinity> Cheap beer, fun people, an inexplicable obsession with doilies.
[03:12] <micahg> awesome, powerpc is doing better than i386 with build failures (not depwaits)
[03:16] <vibhav> good morning
[03:19] <vibhav> http://consumerist.com/2012/06/newegg-installing-linux-on-your-computer-is-basically-the-same-as-breaking-it.html
[03:34] <vibhav> geser: you there?
[03:59] <pitti> Good morning
[03:59] <pitti> barry: yes, foomatic-db-compressed-ppds py3 is in the archive; I keep my WIs as "in progress" until they are really in ubuntu
[04:00] <pitti> cjwatson: u-d-common> my new code is py3 compatible, but the old nvidia-common bits are not; tseliot is on that (he ported python-xkit, which is a dependency)
[04:07] <pitti> barry: apport got binNEWed, so the py3 version is in quantal now
[06:50] <geser> vibhav: yes, I'm now here
[07:01] <pitti> cjwatson: further porting u-d-common is yet another case of "blocked by aptdaemon"
[07:01] <pitti> once we get that in, we can port apturl, language-selector, u-d-common, software-properties, etc.
[07:02] <ScottK> I got slightly lost trying to figure out why dnspython is in Main and if any python3 porting was blocked on it.  I just uploaded dnspython3 to Debian.  If lack of that is blocking anything, please let me know and I'll do a direct upload to Ubuntu too.
[07:05] <dholbach>  good morning
[07:09] <cjwatson> pitti: Yeah, it's the nvidia bits that matter here.
[07:10] <cjwatson> pitti: aptdaemon is, I hear, very close
[07:10] <pitti> yes, it's by and large working in trunk
[07:11] <pitti> the new apt is through binNEW now, I thought that was a prerequisite
[07:11] <cjwatson> Yes
[07:11] <pitti> python-apt is the next and last step, AFAIR
[07:14] <mvo> @pilot out: mvo
[07:14] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[07:14] <mvo> @pilot out
[07:15] <cjwatson> pitti: python-apt went into -proposed along with apt
[07:15] <cjwatson> I think that's in quantal now too, though I haven't upgraded yet today
[07:15] <pitti> ah
[07:15] <pitti> yes, it is
[07:17] <cjwatson> And if we don't get update-manager in today I'll be slightly annoyed :)
[07:18] <cjwatson> soooooo close
[07:23] <pitti> cjwatson: do you know if anyone already discussed extending DEP-8 to add a source package header? (like "XS-Has-Tests: true"); if not, I'll do that now
[07:24] <pitti> once that's in the standard, we could make dpkg-source add that header automatically
[07:24] <pitti> but at least add it manually for the time being, to drop the hardcoded list from jenkins
[07:26] <cjwatson> pitti: We talked about it and I was going to propose it, but I don't think I actually did formally (I may have spoken to Ian about it informally); if you'd like to bring it up on wherever the discussion list for DEP-8 is, feel free
[07:27] <pitti> cjwatson: ok, doing; I was going to mail the three drivers on http://dep.debian.net/deps/dep8/, CC'ing debian-devel@ (not sure if the latter is appropriate)
[07:29] <cjwatson> pitti: Should be
[07:58] <seb128> bdmurray, slangasek, SpamapS, RAOF: could we some precise SRUs through today or tomorrow? the queue has around 30 items, some waiting for 3 weeks...
[08:00] <tkamppeter> seb128, pitti is really missing in the SRU team.
[08:00] <seb128> tkamppeter, hey, yes he is ;-)
[08:04] <RAOF> Is updating the bug description with a reasonably simple template *really* that much to ask for SRUs?
[08:17] <tkamppeter> seb128, I have talked to the people you were trying to talk to here on #ubuntu-release. I got mainly quick help from cjwatson, but also from slangasek.
[08:18] <seb128> RAOF, I share the sentiment, though some people already things that having to provide a debdiff is work they shouldn't need to do, especially some upstream would like to be able to point to a patch and have us to take it...
[08:19] <seb128> tkamppeter, thanks, I know they are all busy and I'm not especially blocked on one SRU, I mostly wanted to point that we are accumulating backlog
[08:43] <vibhav> geser: Are you still here?
[09:13] <geser> vibhav: yes
[09:17] <seb128> yofel_, Riddell, ScottK: hey, is somebody looking at the calligra armhf,armel ftbfs in quantal?
[09:18] <seb128> yofel_, Riddell, ScottK: asking because it's showing up on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[09:18] <xnox> emacs24 for quantal?!
[09:18]  * xnox uses emacs a lot, and has been using ~weekly emacs24 snapshots. I haven't done emacs24 packaging before myself
[09:18] <Riddell> seb128: it's somewhere on the list of things to be done yes
[09:19] <seb128> Riddell, somewhere high or somewhere low? ;-)
[09:19] <Laney> xnox: see if Rob is planning to do it?
[09:19] <Laney> it would make me happy too
[09:20] <Riddell> seb128: high enough that it'll get done but not this week
[09:22] <seb128> Riddell, ok, thanks
[09:22] <xnox> Laney: which Rob? =)
[09:23] <Laney> the maintainer :P
[09:23] <cjwatson> Browning, I should imagine
[09:23] <Laney> that's the badger
[09:23] <xnox> what's his irc nickname?
[09:24] <Laney> laney@raleigh> finger rlb@db.debian.org | grep IRC                                                                         ~
[09:25] <Laney> IRC nickname: rlb
[09:41] <RAOF> seb128: Incidentally, ubuntu-sru had a meeting this morning about how to get into a position where there isn't a backlog; expect to see things improve ;)
[09:42] <pitti> RAOF: do you want to do something similar to the "archive admin of the day" roster?
[09:43] <RAOF> That was one of the outcomes, yeah.
[09:45] <seb128> RAOF, great ;-)
[09:52] <cjwatson> Riddell: Speaking of calligra, there's a calligra-transitional package pending autosync which fails to sync because:
[09:52] <cjwatson> calligra-transitional_1 is trying to override modified binary koffice-l10n-ca_2.3.2-0ubuntu1.  OK (y/N)?
[09:52] <cjwatson> Riddell: What should be done about that?
[09:52] <Riddell> hmm
[09:55] <Riddell> cjwatson: ignore it for now until I get a chance to look at it properly
[10:13] <Sweetshark> jibel: hey, I am getting spammed by the jenkins bot. awesome!
[10:13] <jibel> Sweetshark, only when it fails :)
[10:13] <Sweetshark> jibel: this is really neat.
[10:15] <jibel> Sweetshark, latest build it with gcc 4.6 and no dependency issue on mysql.
[10:16] <Sweetshark> jibel: Ive seen this failure on the ppa too. most curious: the test seem to succeed completely, yet ./debian/rules seems to think there is an error. Maybe something going wrong with the returncode-foo.
[10:17] <Sweetshark> ah, no. this one has an error.
[10:17]  * Sweetshark checks.
[10:18] <Sweetshark> jibel: is gdb installed on that machine?
[10:19] <jibel> Sweetshark, yes
[10:19] <Sweetshark> jibel: good
[10:20] <jibel> let me know if there is a specific setup for gdb. I'm not familiar with it.
[10:21] <Sweetshark> jibel: it should be good. usually no specific setup needed.
[10:22] <Sweetshark> jibel: am I supposed to open the link at the top of the mail? just asking because it times out here ...
[10:23] <jibel> Sweetshark, ah, here is the link with the public address https://jenkins.qa.ubuntu.com/job/quantal-pkg-libreoffice/ARCH=amd64,label=albali/33/
[10:24] <Sweetshark> jibel: thx ;)
[10:35] <ev> pitti: any objections to an apport release? That core pipe brokenness appears to be pretty bad: https://errors.ubuntu.com/api/most-common-problems/Ubuntu%2012.10/today
[10:36] <pitti> ev: I just did an upstream 2.2.2 release and are prepping a quantal upload (test suite running ATM)
[10:36] <ev> pitti: awesome, thanks!
[10:36] <pitti> ev: I didn't notice it in the previous upload as the test suite runs with the system /usr/share/apport/apport for the crashes *duh*
[10:37] <pitti> so, no actual crashes today :)
[10:37] <ev> heh
[10:38] <pitti> I also fixed some other bugs (just G+'ed about one), now the tests shoudl all succeed again
[10:38] <pitti> if it wasn't for xvfb segfaulting, that is :) (but works fine with APPORT_TEST_NOXVFB=1)
[10:45] <ev> it turns out that missing counts for today might be some brokenness in the counters, as jodh helpfully points out that we don't have anything for 11.10 either
[10:45] <ev> I'll investigate after the python3 porting sprint
[10:47] <Laney> do upgrade failures get submitted to errors.u.c too?
[11:03] <hallino1> Evening!
[11:04] <hallino1> I've got a small problem when i write debuild binary.. -> http://paste.ubuntu.com/1038740/
[11:04] <ev> Laney: it's planned, but nothing currently implemented
[11:04] <hallino1> I'm new with packaging.. Anyone can help me please?
[11:04] <Laney> ev: ok, thanks
[11:05] <ev> Laney: which incidentally is why mpt came up with the error tracker name. Application crashes, package install failures, application hangs, debconf prompts, etc.
[11:47] <mpt> ev, have you seen <http://askubuntu.com/questions/135540/what-is-the-whoopsie-process-and-can-i-remove-it>?
[11:48] <cjwatson> A friend of mine has been objecting to the name every chance he gets
[11:48] <cjwatson> It seems to freak him out
[11:49] <cjwatson> Supplying a man page would probably have soothed him since I think that was the first thing he reached for
[11:50] <StevenK> cjwatson: Why, is he Frank Spencer? :-P
[11:51] <cjwatson> Er, no
[11:51] <cjwatson> (Long time since I saw that)
[11:52] <StevenK> cjwatson: I had to go and look it up because I couldn't remember the name of the actor or the character.
[11:59]  * xnox likes the comment "No, just apt-get rid of it."
[12:14] <vibhav> geser: REALLLY SORRY for being AFK, Since you were the last guy to touch dracut in ubuntu, are you comfortable with me preaparing a merge for it?
[12:18] <geser> vibhav: sure, feel free to take it
[12:20] <vibhav> thanks!
[12:20] <vibhav> geser: By the way, why did you add docbook-xsl to Build-Depends ?
[12:22] <vibhav> oh wait, its already added in debian
[12:23]  * vibhav files a syncrequest
[12:24] <geser> vibhav: the unmodified package FTBFS: https://launchpad.net/ubuntu/+source/dracut/018+32+geb6e141-1/+build/3469665
[12:26] <vibhav> geser: Since dookbook-xsl was added to Build Depends in Sid, I have filed a sync request: https://bugs.launchpad.net/bugs/1012641
[12:33] <ev> mpt: I had not. I did manage to get this one in yesterday though: http://askubuntu.com/questions/140379/how-can-i-track-a-bug-that-caused-a-crash-and-was-reported-via-apport-whoopsie/149455#149455
[12:33] <vibhav> doko: ping
[12:34] <mdeslaur> @pilot in
[12:44] <barry> hi pitti fantastic, thanks
[12:50] <ev> mpt: replied: http://askubuntu.com/questions/135540/what-is-the-whoopsie-process-and-can-i-remove-it/150332#150332
[13:02] <vibhav> cyphermox: ping
[13:08] <herton> @pilot in
[13:09] <vibhav> wow
[13:11] <mpt> ev, Nanne has a point: What's the way to turn it off on the server?
[13:13] <stokachu> To disable it on Ubuntu Server, edit the /etc/default/whoopsie file and change report_crashes= tofalse, then run sudo stop whoopsie.
[13:13] <Laney> It'd be nice if there were a manpage explaining such things
[13:14] <stokachu> or maybe just added to readme for package
[13:15] <pitti> lamont: do you happen to plan to update util-linux to the latest upstream version by any chance?
[13:15] <pitti> lamont: I just tried for an hour to fix wipefs, but the vfat fix is not backportable at all, and my own attempt of quickfixing it in 2.20.1 went badly
[13:19] <ev> Laney: you're more than welcome to write one :)
[13:19] <vibhav> herton: are you busy?
[13:19] <Laney> ev: I would if I knew what to write :P
[13:20] <herton> vibhav, hello, what's up?
[13:20] <ev> Joking aside, there is an outstanding bug report for it. I've had more pressing problems to solve.
[13:21] <vibhav> herton: If you are not occupied , could you have a look at https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1012666 ?
[13:22] <herton> vibhav, hi, I can't, I can look only at kernel bugs for now
[13:22] <herton> vibhav, may be mdeslaur can help you
[13:22] <vibhav> mdeslaur: If you are not occupied , could you have a look at https://bugs.launchpad.net/ubuntu/+source/libisofs/+bug/1012666 ?
[13:23] <lamont> pitti: I should do that
[13:23] <mdeslaur> vibhav: sure, I have a couple of things queued up, but I'll take a look after them
[13:23] <mdeslaur> vibhav: i'll get to it in about an hour
[13:23] <lamont> pitti: I think time would be better spent on getting the latest version there, rather than just pulling over fixes one at a time
[13:24] <lamont> I'll see how this weekend does for getting that and nmap happier
[13:24] <pitti> lamont: yes, I've come to the same conclusion
[13:24] <pitti> lamont: it just doesn't seem easier; it doesn't have split-out patches, so wading through the monolithic diff seems to be a bit of a challenge
[13:24] <pitti> lamont: do you have a magic way of updating that?
[13:25] <ogra_> pitti, is bug 1007826 an issue on the apport side or is that the way the function was called ? i''m currently porting xdiagnose to py3 and get similar output in the testsuite
[13:26] <ogra_> (if its the way the function is called i'll happily fix it)
[13:26] <pitti> ogra_: right, I sent a warning about this to planet and u-devel@
[13:26] <pitti> ogra_: https://www.piware.de/2012/05/apport-api-users-watch-your-data-types-python-3-porting/
[13:26] <ogra_> ah
[13:26]  * ogra_ goes reading
[13:26] <ogra_> uuuh !
[13:26] <ogra_> "Dieser Verbindung wird nicht vertraut"
[13:27] <ogra_> :)
[13:28] <mvo> barry: is xapian a target for the py3 porting sprint too ? I think its the last missing dependency for software-center :)
[13:30] <smoser> anyone know... lp:debian/sid/euca2ools is out of date. i'm not accustomed to that happening for debian, but usually only after i've screwed something up in the lp:ubuntu branch.
[13:31] <smoser> how can i get my local branch of lp:debian/sid/euca2ools updated? is there an easy way to suck in the debian package?
[13:31]  * smoser is embarrased. after typing bzr import-<tab> he sees "import-dsc"
[13:36] <mterry> mvo, does update-manager not use code reviews?  Should I just be committing directly?
[13:38] <mvo> mterry: it does, its just that the set of reviewers is really tiny and that the py3 sprint is also going on at the same time
[13:38] <mvo> mterry: I'm sorry that its a bit of a hassle right now
[13:38] <mvo> mterry: I think its ok if you go wild and take it over for now
[13:39] <mterry> mvo, no it's fine.  I wasn't complaining, just curious
[13:39]  * mvo nods
[13:39] <mterry> mvo, I didn't see it on https://wiki.ubuntu.com/UbuntuEngineering/12.04/UpstreamDevelopment/ProjectTracking either
[13:40] <mterry> mvo, not sure why that URL is dated for 12.04.  Presumably it's an ongoing list
[13:40] <mterry> rickspencer3, ^ ?
[13:40] <rickspencer3> hi mterry
[13:41] <xnox> does anyone have a snippet for quiltrc to correctly choose between series / series.ubuntu based on dpkg-vendor?
[13:41] <mterry> rickspencer3, does that ProjectTracking page have a non-12.04-specific URL somewhere?
[13:41] <rickspencer3> mterry, I dunno
[13:42] <rickspencer3> I'm not actually familiar with it ;)
[13:42] <mterry> rickspencer3, wait what?  i thought that was your baby
[13:42] <barry> mvo: it's on the list, but i don't think anyone's attacked it yet.  i'll ping the team
[13:42] <rickspencer3> mterry, well, I guess it was at one point, yeah
[13:43] <rickspencer3> but babies grow up and leave home
[13:43] <mterry> rickspencer3, this one refuses to leave the warm embrace of 12.04
[13:43] <mvo> barry: awsome
[13:43] <seb128> mterry, who can blame it? the lts rocks ;-)
[13:44] <mvo> mterry: hrm, its indeed missing there
[13:44] <pitti> tseliot: hey Alberto
[13:45] <pitti> tseliot: want me to review https://github.com/tseliot/ubuntu-drivers-common/pull/3 ?
[13:45] <pitti> tseliot: or do you want to?
[13:45] <pitti> tseliot: it looks mostly good to me, I just don't particularly like the "from __future .. absolute import" stuff
[13:46] <mterry> mvo, well anyway, I'll leave the branches as is instead of cowboying them in.  No rush really
[13:49] <vibhav> dholbach: ping
[13:49] <tseliot> pitti: feel free to approve the merge request. I feel the same way about the absolute import stuff but it's for backwards comaptibility
[13:49] <dholbach> vibhav, pong
[13:49] <pitti> tseliot: I mean, I'd rather change it to "import Quirks.quirkreader" or so
[13:50] <tseliot> pitti: ah, sure, that would definitely look better
[13:52] <vibhav> dholbach: If you have any free time could you please write your testamonial on https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ?
[13:53] <vibhav> testimonial*
[13:53] <dholbach> vibhav, I bookmarked it - I'm currently in the middle of 5 other things :)
[13:53] <vibhav> thanks!
[13:53] <vibhav> jamespage: You there?
[13:53] <jamespage> vibhav, I am
[13:54] <jibel> pitti, crash files are now deleted before adt-run runs and saved as artifacts after
[13:54] <jibel> pitti, for apport there are 2 crash files
[13:54] <jibel> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-apport/15/ARCH=amd64,label=albali/artifact/results/
[13:54] <pitti> jibel: thanks
[13:54] <pitti> jibel: oh, did it run now for 2.2.2?
[13:54] <pitti> jibel: ah, that's for 2.2.1 apparently
[13:54] <vibhav> jamespage: Can I prepare a sync for gettext from Debian Sid? (Since you were the last person to touch it in ubuntu)
[13:55] <vibhav> s/sync/merge/
[13:55] <pitti> jibel: ah, no, looks like yet another problem; I'll trawl through that, thanks!
[13:56] <jibel> pitti, run 15 tested 2.2.2, isn't it ?
[13:56] <pitti> right
[13:56] <mpt> ev, I saw your previous answer via <http://www.reddit.com/r/Ubuntu/comments/uwf19/awesome_explanation_on_how_the_ubuntu_crash/>
[13:59] <jamespage> vibhav, be my guest!
[13:59] <jamespage> (and thanks for asking :-))
[14:01] <vibhav> thanks!
[14:05] <pitti> xnox: OOI, how did you test u-d-common?
[14:05] <pitti> xnox: I'm currently running: PYTHONPATH=.:~/upstream/aptdaemon python3 tests/run
[14:05] <smb> pitti, doko, While trying to fix up something which gcc-4.7 is more picky about, I noticed that running the same package compile with precise will invoke gcc with some additional options which look a bit like hardening (-fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security). In quantal those are not there. Just wondered whether that is expected...
[14:06] <pitti> xnox: aside from the PackageKit failures I also get some errors from the quirk reader
[14:06] <xnox> pitti: hmm I will look
[14:06] <xnox> pitti: i was running tests with $ python3 -m unittest discover
[14:06] <xnox> with extra flags
[14:07] <xnox> pitti: why are tests files *not* called tests/test_*.py ?
[14:07] <pitti> xnox: no particular reason, I guess; tests/run doesn't care
[14:07] <xnox> pitti: it looks like tests/run has been modified to filter out settings.py and other stuff
[14:08] <pitti> xnox: also, with your merge the tests now fail
[14:08]  * xnox generally doesn't like tests/run scripts. It should IMHO just work with unittest discover runner
[14:08] <pitti>   File "/home/martin/ubuntu/ubuntu-drivers-common/tests/ubuntu_drivers.py", line 29, in <module>
[14:08] <pitti>     from . import fakesysfs
[14:08] <pitti> ValueError: Attempted relative import in non-package
[14:08] <xnox> awesome
[14:08] <xnox> that is fail
[14:08]  * pitti sees to fixing this
[14:13] <infinity> pitti: Were you planning on adding those new symbols to Debian's cups at some point soon, or should we just fix it in Ubuntu to get it off our radar?
[14:13] <pitti> infinity: it's already fixed in Debian's bzr
[14:13] <pitti> infinity: I have another RC bug I need to fix, then I wanted to do another upload
[14:14] <infinity> pitti: Ahh, kay.
[14:15] <pitti> xnox: pushed two fixes to trunk which should be better again; tests now work again with py2, and the imports should be fine for py3 as well (PYTHONPATH=. python3 ./quirks-handler)
[14:15] <xnox> pitti: thank you. I will check them out.
[14:16] <pitti> xnox: I also pushed a fallback for packagekit.enums, but that's again blocked on aptdaemon (just tested against upstream trunk, can't change the Depends: yet)
[14:17] <xnox> pitti: yeap, I'm about to upload python3-packagekit to branch / ppa for testing
[14:17]  * xnox building in pbuilder
[14:17] <pitti> xnox: anything wrong with glatzor's PPA?
[14:18] <xnox> pitti: what's glatzor's PPA?
[14:18] <infinity> rsalveti: Do you know anything about the gles/glew sadness that's causing build failures?
[14:18] <pitti> xnox: https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035297.html
[14:18] <pitti> xnox: he already provided test packages
[14:18] <infinity> rsalveti: (See callibra in quantal, grep the log for 'conflicting declaration')
[14:20] <xnox> pitti: that doesn't have packagekit, or does it?
[14:20] <xnox> pitti: there was more work done on the aptdaemon
[14:20] <xnox> after the ppa
[14:20] <pitti> xnox: no, I doubt that packagekit has been ported already
[14:20] <pitti> xnox: argh; ignore me
[14:20] <pitti> xnox: I got confused
[14:20] <xnox> pitti: it has been upstream. well the python-packagekit
[14:21] <xnox> not all the helper scripts
[14:21] <pitti> xnox: u-d-common falls back to aptdaemon.pkenum for now (as that is already available in aptdaemon, but we haven't had a python3-packagekit so far)
[14:21] <xnox> pitti: you will in a second =)
[14:27] <mterry> tremolux, if software-center says to check the logs because it can't submit a review, where do I look?
[14:28] <tremolux> heyy mterry!! it's here: ~/.cache/software-center/software-center.log
[14:29] <tremolux> that message is pretty useless :/
[14:29] <rsalveti> infinity: nops, let me check
[14:30] <mterry> tremolux, thanks!
[14:30] <tremolux> mterry: yw, thank you too!
[14:31] <tremolux> mterry: there is an open bug on this, may be the same, let me find it
[14:32] <tremolux> mterry: bug 778070
[14:32] <infinity> rsalveti: Maybe we just need a new mesa to go with glew1.7?  I dunno.  I haven't looked into it deeply, and I suspect no one else has yet either, cause it only (so far) affects ARM.
[14:32] <tremolux> mterry: server-side fix in-progress
[14:33] <rsalveti> there was some important changes for gles support at glew1.7 afaik, so need to make sure it's all properly enabled I guess
[14:33] <mterry> tremolux, I have the same trace as comment #8, but not sure that's what that bug was originally about
[14:33] <mterry> tremolux, but if the server-side fix will get #8, I'm good
[14:34] <rsalveti> infinity: why are we still building for armel?
[14:35] <tremolux> mterry: right, the original probably described something that has long since been fixed (server churn, client churn) but the bug not updated/noticed, and the current problem seems to be as described in #8, and that is the one being fixed
[14:36] <tremolux> mterry: #8 is the one that people are hitting now, and it seems recent (and it revived the bug)
[14:37] <mterry> tremolux, cool
[14:37]  * mterry looks forward to reviewing again
[14:39] <infinity> rsalveti: It's complicated.
[14:39] <rsalveti> infinity: :-)
[14:40] <tremolux> mterry: :D reviews ftw!!
[14:45] <barry> kenvandine: ping
[14:47] <kenvandine> barry, pong
[14:48] <barry> kenvandine: hi, how are you today?  i wanted to chat a bit about the py3 port of whatever parts of gwibber are going to be on the 12.10 desktop image.  when i last looked, it was gwibber and gwibber-service.  what's the current status of the code, and any py3 porting work you're aware of?
[14:49] <barry> kenvandine: foundations team is sprinting on py3 support and i figured since i'd previously looked at this, i'd take another look at it today
[14:49] <kenvandine> i haven't done anything yet, was hoping for a solution for libpeas
[14:49] <kenvandine> barry, has anything been figured out there?
[14:50] <barry> kenvandine: ah libpeas.  i don't think so, but i will look into that today
[14:50] <kenvandine> we want to switch to using libpeas for handling the service plugins
[14:50] <kenvandine> instead of the hacky stuff we have now
[14:50] <kenvandine> but libpeas and py3 was a ???
[14:51] <kenvandine> switching to libpeas would simplify the port to py3 if that worked with py3
[14:51] <mterry> kenvandine, libpeas has gir support
[14:51] <barry> kenvandine: so gwibber doesn't currently use libpeas?
[14:51] <kenvandine> barry, no
[14:51] <dobey> mterry: it does, but that's mostly irrelevant
[14:51] <kenvandine> mterry, yeah but not py3 yet
[14:52] <dobey> mterry: the python loader only uses the python2 runtime
[14:52] <mterry> kenvandine, ah, internally it only supports py2 plugins?  bummer
[14:52] <dobey> it should be easy to fix though
[14:52] <dobey> it just needs a py3 loader, and code to avoid loading both the py2 and py3 loaders (which are shared objects in libpeas itself)
[14:54] <vibhav> jamespage: done : https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1012705
[14:55] <barry> dobey, kenvandine, mterry: so, it sounds like it's more useful for me to look into libpeas right now
[14:55]  * kenvandine hugs barry
[14:56] <henrix> infinity: hi! could you please copy the precise kernel pkgs into -updates? (bug #1003534)
[14:56] <dobey> barry: right. and it's required to fix a lot of other things as well (rhythmbox, gedit, etc)
[14:56] <infinity> henrix: Yeahp.  Are armadaxp and ti-omap4 also ready, or just linux/lbm/meta?
[14:56] <barry> dobey: ack.  i'll put it next on my list
[14:57] <henrix> infinity: they should be ready, but not sure. let me check...
[14:57] <infinity> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1004555
[14:57] <infinity> ti-omap4 looks ready
[14:58] <infinity> henrix: armadaxp lacks a tracking bug, https://bugs.launchpad.net/eilt/+bug/1006217 is as close as it gets.
[14:58] <henrix> infinity: yeah, ti is ok but not armadaxp
[14:59] <infinity> henrix: Can you get those folks to do tracking bugs in the future?  I find them wildly useful for the rather complex kernel SRU workflow.
[14:59] <xnox> pitti: so while aptdaemon is in progress there is now bug 1012703 which needs/review sponsor
[14:59] <infinity> henrix: (For this one, though, I'm happy to let it slide, if someone can just verify the kernel is sane
[14:59] <infinity> )
[14:59] <xnox> infinity: =))) way to go for me to break your )
[14:59] <henrix> infinity: sure, give me 1 minute to figure out what's going on
[14:59] <infinity> xnox: Hrmph.
[15:06] <henrix> infinity: it looks like armadaxp *does* have a tracking bug: #1004556
[15:09] <infinity> henrix: But not mentioned in the changelog?  Argh.
[15:10] <henrix> infinity: hmm... interesting. still trying to figure out what's going on with armadaxp...
[15:10] <infinity> henrix: I'm guessing no one told janimo about the tracking bug. :P
[15:10] <infinity> henrix: Hence, he didn't include it in the changelog.
[15:10] <henrix> infinity: that's a possibility :)
[15:11] <henrix> infinity: anyway, thanks for the heads up. i'll go sort that out
[15:11] <infinity> henrix: Cool.  linux (et al) and ti-omap4 (and meta) are done.
[15:12] <henrix> infinity: great, thanks
[15:12] <infinity> henrix: To be clear, I don't want anyone doing anything silly like re-uploading aramdaxp and restarting the verification process, just to fix the changelog. :P
[15:13] <infinity> henrix: Just some followup to the bug that *is* in the changelog (and a mention of the tracking bug in that same bug log, so we can go dot our Is and cross our Ts) would be fine.
[15:13] <henrix> infinity: ack, thanks
[16:08] <henrix> infinity: i still see the "promote-to-updates" task as 'confirmed'. any idea why?
[16:09] <henrix> infinity: (btw, the issues with armadaxp are being sorted out)
[16:16] <infinity> henrix: D'oh.  Because LP timed out when I was updating the bug and i didn't notice. :)
[16:17] <infinity> henrix: Fixed.
[16:17] <henrix> infinity: heh cool! :)
[16:17] <henrix> infinity: thanks
[16:18] <mdeslaur> @pilot out
[16:19]  * dholbach hugs mdeslaur
[16:19]  * mdeslaur hugs dholbach back
[16:21] <SpamapS> seb128: we're going to start doing a daily rotation, and today is my day. I'll spend a few hours doing SRU's, not tow orry. :)
[16:21] <seb128> SpamapS, taht's great news, thanks!
[16:22] <SpamapS> seb128: btw thanks for clearing up the gnome MRE :)
[16:23] <seb128> SpamapS, no worry, it's going to make my life easier as well ;-)
[16:48] <BenC>  // Define if compatibility should be provided for -mlong-double-64.
[16:48] <BenC> #define _GLIBCXX_LONG_DOUBLE_COMPAT 1
[16:48] <BenC> doko: How important is that on powerpc?
[16:50] <BenC> doko: like will it break c++ ABI if it gets disabled
[16:53] <BenC> doko: if it just break backward compatibility pre-2006, then I'd like to vote to disable it on powerpc
[16:54] <BenC> It's marked "GLIBCXX_ABI Deprecated"
[17:06] <infinity> BenC: Is it causing you issues?
[17:06] <BenC> infinity: it's the cause of most build failures for things like gdc, aspectc++, and a few other things
[17:06] <BenC> if I #undef that one line, all those things compile and are happy
[17:07] <BenC> fixes about half a dozen FTBFS and countless dep-waits
[17:07] <infinity> BenC: That's... Odd.  It shouldn't, on its own, be causing any problems, really.
[17:07] <BenC> infinity: it's not…it's the "inline namespace" that gets exposed because of it
[17:07] <infinity> BenC: Unless those packages are also passing -mlong-double-64
[17:08] <BenC> ...c++config.h:336: error: invalid declaration near token `namespace'
[17:08] <BenC> That "invalid" is "inline" and it's in the block of code used to get the -mlong-double-64 compatibility
[17:09] <BenC> I realize it's not really invalid, and that c++config.h isn't really broken, but all of these things build on x86 because it doesn't have this define, and I can't fix it anywhere else but in c++config.h
[17:09] <infinity> Well, we've probably been long-double-128 by default for over half a decade, but it might be worth sorting out how to scan the archive to make sure that dropping compat doesn't break anything.
[17:10] <BenC> It's the default for alpha, powerpc, sparc and s390 for this compatibility
[17:12] <BenC> At the very least, I'd like to modify c++config.h so that it can be disabled with a -D or similar
[17:21] <BenC> infinity: This was easier than I thought…adding -mlong-double-64 to these problematic program's CFLAGS might be the more unobtrusive fix
[17:22] <infinity> BenC: Oh.  As in, they're breaking when building with the default mld128, but work with 64?
[17:23] <infinity> BenC: That's kinda special.  But a simple enough fix.
[17:23] <BenC> infinity: right, but only because it avoids the "inline namespace" verbiage, but I'm happy with that
[17:23] <infinity> BenC: And one that will fail in very obvious ways if the backward compat ever goes away, so it's not like you're introducing scary.
[17:24] <BenC> Yeah, and considering these things never really built well on powerpc to begin with, one that won't break existing usage
[17:37] <slangasek> pitti: hi, who manages http://changelogs.ubuntu.com/?  It seems we're not getting updates, is this a known issue?
[17:37] <seb128> slangasek, somebody mentions it was a disk out of space issue with a RT filed
[17:37] <slangasek> ah, ok
[17:38] <seb128> slangasek, <mvo>	mdeslaur: yes, changelogs.ubuntu.com has a full disk
[17:38] <seb128> slangasek, that was on june 6, maybe you can help the rt to get moving? ;-)
[17:38] <slangasek> seb128: sure, as soon as I find the RT :)
[17:39] <seb128> slangasek, msged to you
[17:40] <slangasek> seb128: ta
[17:49] <mterry> barry, for a package that delivers the DistUpgrade module, should it's name be python-DistUpgrade, python-distupgrade, or python-dist-upgrade?
[17:50] <mterry> ahem, "its" not "it's"
[17:52] <ScottK> python-distupgrade.
[17:52] <ScottK> No case in package names.
[17:52] <mterry> ScottK, yar I figured case would be bad.  OK, thanks!
[17:53]  * ScottK wonders if he missed the memo about International Talk Like A Pirate Day?
[17:53] <mterry> ScottK, I'm just stuck :)
[18:01] <SpamapS> hmm.. thats weird
[18:01] <SpamapS> juju was synced from Debian even though it already had a -0ubuntuX version
[18:01]  * barry concurs
[18:01] <SpamapS> 0.5+bzr538-0ubuntu1
[18:02] <SpamapS> should have blocked the sync, no?
[18:02] <ogra_> did debian have a -1 version by chance ?
[18:02] <SpamapS> 0.5+bzr539-1 was synced
[18:02] <ogra_> yeah, -1 > -0ubuntu1
[18:02] <SpamapS> but the existence of an ubuntu version should have stopped that
[18:03] <lifeless> why ?
[18:03] <SpamapS> Because that should require a merge
[18:03] <lifeless> not if the debian changelog contains 0ubuntu1 in it.
[18:03] <SpamapS> wha?
[18:03] <lifeless> [caveat, I haven't checked the code]
[18:03] <SpamapS> we just blindly throw away Ubuntu delta?
[18:03] <lifeless> but there is a merge graph
[18:04] <SpamapS> it hasn't happened with mysql-5.5
[18:04] <lifeless> SpamapS: is there a delta in this case?
[18:04] <SpamapS> which was at 5.5.22-0ubuntu1 when Debian got 5.5.24+dfsg-1
[18:04] <SpamapS> lifeless: yes, though its fairly innocuous and unimportant
[18:05] <SpamapS> I was planning on syncing them actually
[18:05] <SpamapS> so its possible somebody decided to just do it
[18:05] <ogra_> well, theoretically if the debian package contains the version thats current in ubuntu one should be able to assume that the code is contained
[18:05] <ogra_> so there theoretically cant be a delta
[18:06] <SpamapS> ogra_: it was my understanding that *any* -XubuntuX would force a manual merge or sync
[18:06] <SpamapS> This must have been a manual sync
[18:06] <debfx> it is a manual sync: https://lists.ubuntu.com/archives/quantal-changes/2012-June/002527.html
[18:06] <SpamapS> Actually it was, quantal-changes says Jeremy Bicha
[18:07] <ogra_> well, why would you merge it if the changelog says it is already merged ?
[18:07] <SpamapS> ogra_: the changelog does not say it is already merged
[18:07] <ogra_> i thought the changelog caontained the -0ubuntu1 version in the debian package
[18:08] <SpamapS> I'm guessing Jeremy just looked at the diff and realized it was fine (which it seemingly is) and just synced
[18:08] <SpamapS> ogra_: no definitely not
[18:08] <BenC> infinity: is there a better way to get a rebuild of a package (for the sake of it using a newer library) other than uploading a changelog-only source?
[18:08] <ogra_> ah, then i misread
[18:08] <ScottK> BenC: No.
[18:08] <SpamapS> the debian package has but one entry in the changelog.. for the 0.5+bzr539-1 .. since it was NEW'd only yesterday
[18:09] <ogra_> ah
[18:09] <SpamapS> I had intended to sync it myself.. *after* testing it :-P
[18:09] <ogra_> yeah, that shouldnt autosync indeed
[18:09] <SpamapS> Hopefully our daily package builds still work.
[18:09]  * SpamapS tries the recipes now
[18:09] <ScottK> But it didn't autosync.  jbicha sync'ed it.
[18:09] <cjwatson> mterry: Remind me of the new dist-upgrade branch?  I guess I have a ton of patches to sync over.
[18:09] <ScottK> (AIUI)
[18:10] <SpamapS> ScottK: right, it was just an eager syncer. ;)
[18:10] <cjwatson> mterry: I was kind of hoping to do an update-manager upload before trying to split out the upgrader, though, because I'm tantalisingly close to having it py3-ready.
[18:10] <cjwatson> lifeless: Autosyncing is purely based on whether the version number contains the "ubuntu" substring.  -0ubuntu1 isn't special.
[18:11] <mterry> cjwatson, I've been working on integrating your new patches
[18:11] <SpamapS> ok, n/m.. nothing to see here. :)
[18:11] <mterry> cjwatson, I know, I didn't realize all this python3 stuff would happen before my branch got merged
[18:11] <cjwatson> mterry: The reason I'm reluctant is that I just finished doing a full test matrix this morning
[18:12] <mterry> cjwatson, U-M side is https://code.launchpad.net/~mterry/update-manager/split-release-upgrader
[18:12] <cjwatson> And I kind of don't want to do that all again tonight
[18:12] <mterry> cjwatson, new package is https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split
[18:12] <cjwatson> Can we leave it until after the first update-manager py3 upload?
[18:13] <mterry> cjwatson, we can sure.  I'm in no rush
[18:13] <cjwatson> That shouldn't make it any more difficult.
[18:13] <cjwatson> And then I get to be a bit more stepwise about things
[18:14] <lifeless> cjwatson: thanks
[18:15] <cjwatson> mterry: Any reason that branch isn't just in lp:ubuntu-release-upgrader?
[18:15] <cjwatson> Oh, pending merege
[18:15] <cjwatson> *merge
[18:15] <mterry> cjwatson, yar, so it can be reviewed
[18:16]  * ScottK imagines mterry with an eye patch again.
[18:16] <cjwatson> mterry: Since lp:ubuntu-release-upgrader is currently just a copy of lp:update-manager, rather than cherry-picking patches, it would make more sense to pull the lot into lp:ubuntu-release-upgrader first
[18:17] <cjwatson> That preserves history better as well
[18:17] <cjwatson> Maybe if we start that from 1:0.163 once it's uploaded
[18:17] <tgm4883> ev, can I bug you for a sec regarding errors.ubuntu.com
[18:17]  * slangasek waits for mterry to start teaching command-not-found about avast-get and avast-cache
[18:17] <mterry> cjwatson, hm?  how am I losing history?  if it's all in lp:u-r-u, you don't get a nice LP review, right?
[18:18] <cjwatson> mterry: Why would I care?  Everything in lp:update-manager since then is either trivial or has already been reviewed.
[18:18] <cjwatson> mterry: lp:u-r-u -> current tip of lp:update-manager is a pure fast-forward merge (in git terms).
[18:18] <cjwatson> So we should do that first rather than cherry-picking a bunch of stuff that's textually identical but that now has a load of new commits.
[18:19] <mterry> cjwatson, right, and I just synced them again.  But to be able to review my split...
[18:19] <cjwatson> Your branch is a mixture of stuff you've done and stuff I've done
[18:19] <cjwatson> AFAICS
[18:19] <cjwatson> Either that or we duplicated things by coincidence; I'm only going by the web diff
[18:20] <mterry> cjwatson, ah, well if you refresh you'll just seem my stuff.  I just re-sync'd lp:u-r-u from lp:u-m
[18:20] <cjwatson> Ah, r2457 is an actual bzr merge
[18:20] <cjwatson> So I guess that's OK, but it would still be easier to review if we just pulled lp:u-r-u from lp:u-m first
[18:20] <mterry> cjwatson, right.  It's just a branch.  I'm doing this goofy stuff because LP can't support merge reviews across products
[18:21] <cjwatson> Then the review would be of your split, not of your split + nearly everything since 1:0.161
[18:21] <mterry> cjwatson, it will still just be my split.  Because lp:u-r-u is up-to-date
[18:21] <ev> tgm4883: what's up?
[18:21] <cjwatson> Oh.  It wasn't ten minutes ago when I looked!
[18:21] <cjwatson> I swear
[18:21] <mterry> cjwatson, right I know.  But I tried to tell you that I just re-synced a moment ago
[18:22] <cjwatson> Ah - understood now, sorry, I thought you meant the merge in your split branch
[18:22] <tgm4883> ev, I'm bugging slangasek about it (regarding adding logs to be gathered), and it appears it's just not possible yet
[18:22] <mterry> cjwatson, well that too.  :)
[18:22] <ev> tgm4883: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-bucketing-improvements
[18:22] <cjwatson> Talking at cross-purposes.  Sorry.
[18:23] <tgm4883> ev, thanks, I'll subscribe to that
[18:24] <mterry> cjwatson, but anyway, back on topic, keep doing your awesome python3 stuff and don't worry about my branch.  :)
[18:24] <mterry> I'll re-merge after your release
[18:25] <kees> smb`: quantal has the disabled the forced flag exports in the build. however, those particular flags are already enabled by default. the only difference might be the presence/absence of the -O level
[18:41] <smoser> is there a proper way to reference a bug in a debian/changelog that does not make it magically 'fix-released' ?
[18:41] <smoser> i'm wanting to point to a bug in debian/changelog as reason for ubuntu delta
[18:41] <smoser> ie, its already fixed but i dont want every subsequent upload to think "oh, that bug is fixed now" (or maybe it would just not do that because of fix-released)
[18:42] <ScottK> Leave out the # and it won't trip the regex.
[18:44] <seb128> smoser, if the bug is already closed in launchpad further uploads should not create any activity on the bug
[18:44] <smoser> ok. thanks seb128 ScottK . i guess i'll just leave it proper (LP: #XXXX) style and since they're fix-released it should be ok.
[18:48] <BenC> infinity: Is it correct that the buildd's run "debian/rules build" as opposed to "debian/rules build-arch"?
[18:49] <BenC> infinity: Mainly because I've seen several build failures where override_dh_auto_build-indep is being called for things like doxygen, which is in build-dep-indep, so it isn't installed
[19:08] <cjwatson> smoser: I generally use "LP #nnnnnn" for such things.
[19:15] <infinity> BenC: They call dpkg-buildpackage -B (which does build, then binary-arch)
[19:21] <soren> smoser: What cjwatson said. It's the general pattern people use for that. To specifically answer your question, though, the regex in question is applied by dpkg-parsechangelog on your machine when you "dpkg-buildpacakge -S". It finds the closed bugs and adds a Launchpad-Bugs-Fixed field to your .changes file. That's what Launchpad uses to close bugs.
[19:22] <soren> smoser: So, you could remove that field from your .changes, re-sign it, and upload, and you woulnd't trigger anything in Launchpad.
[19:22] <soren> smoser: ...but since the bugs are already closed, it'll be a no-op anyway.
[19:31] <smoser> ah. thanks.
[19:31] <seb128> soren, mdz, kees, cjwatson: do you read the techboard list? is there anything I need to get replies from tb members on the SRU emails? only pitti and mark replied so far
[19:32] <seb128> the meeting this week seems to have not been happening as well ... should I try to add an agenda item for the next meeting?
[19:32] <Laney> I also saw that the TB meeting didn't happen, and someone said that there was nothing on the agenda. Somehow those topics from the mailing list probably should have made it there, probably?
[19:32] <seb128> Laney, ;-)
[19:32] <Laney> :P
[19:32] <seb128> the techboard seems not very functional atm :-(
[19:33] <Laney> stgraber: ^ too
[19:36] <kees> seb128: reading now...
[19:40] <cjwatson> seb128: oh, yeah, sorry about that - I've replied now
[19:40] <seb128> kees, don't take it wrong, but are you subscribed to the list? important issues getting ignored over weeks by most tb members don't seem a good situation, I'm wondering what went wrong there
[19:40] <seb128> cjwatson, thanks
[19:41] <kees> seb128: I don't have a good habit of reading the list.
[19:41] <kees> seb128: I'll re-arrange my filters to help
[19:41] <seb128> kees, was that the wrong way to raise those issues?
[19:41] <seb128> kees, I really though those items would get on the next week agenda if not addressed on the list
[19:42] <kees> seb128: normally if you want something discussed at the meeting, it needs to get added to the wiki page by the interested party.
[19:42] <seb128> kees, cjwatson: as an outsider the experience is pretty disappointing to see the list ignored and the meeting to go "no topic, no need to have a meeting"
[19:43] <seb128> kees, ok, thanks, I will do that for the next meeting in 2 weeks if those issues are still stalled
[19:44] <cjwatson> One of the standing items on our agenda is to review the list, so it's an oversight if that didn't happen
[19:44] <cjwatson> Unfortunately due to the foundations sprint this week I missed this week's meeting
[19:59] <tjaalton> are there 12.04.1 installer builds available yet?
[20:00] <seb128> cjwatson, kees: thanks for the replies ;-)
[20:04] <kees> seb128: np. I'll get future stuff into my inbox directly now. :)
[20:05] <seb128> kees, great ;-)
[20:05] <cjwatson> It does go into my inbox already, but so does way too much other stuff :-(
[20:16] <Laney> can someone moderate seb128's mail that kees replied to?
[20:18] <seb128> SpamapS, RAOF, bdmurray, slangasek (i.e SRU team): https://lists.ubuntu.com/archives/technical-board/2012-June/001300.html
[20:26] <stgraber> tjaalton: we have daily builds on cdimage.ubuntu.com/precise
[20:27] <tjaalton> stgraber: I only see the release image there
[20:28] <tjaalton> oh wait
[20:29] <tjaalton> wrong dir, got it now
[20:29] <tjaalton> thanks
[20:30] <tjaalton> stgraber: do these have packages from -proposed as well, or just -updates?
[20:31] <stgraber> just -updates AFAIK
[20:33] <stgraber> tjaalton: a quick grep in the cdimage branches seems to confirm that we have updates enabled but not proposed
[20:35] <tjaalton> stgraber: ok
[20:37] <tjaalton> there should be a new kernel in -updates soon.. need to get that tested to see if it fixes some nasty display bugs
[20:41] <infinity> BenC: Gah.
[20:41] <infinity> BenC: Don't use -Nubuntu1 versioning for rebuilds.
[20:42] <BenC> infinity: Ah, what should I use in the future?
[20:42] <infinity> BenC: Should be -Nbuild1
[20:42] <jtaylor> doko: is there much point in keeping this diff: http://launchpadlibrarian.net/86710012/mpich2_1.4.1-1build1_1.4.1-1ubuntu1.diff.gz
[20:42] <BenC> Ok, thanks
[20:42] <jtaylor> doko: blcr is broken since natty anyway
[20:42] <infinity> BenC: I just noticed because my build1 upload of libextractor was rejected because your ubuntu1 got there first. ;)
[20:43] <infinity> BenC: But this means now that we need to manually watch for Debian revisions to those uploads and sync, since we don't sync over *ubuntu* versions.
[20:44] <micahg> BenC: dch -R for rebuilds
[20:45] <slangasek> kees: so you seem to have given us a bootstrapping problem for MREs. ;)
[20:46] <BenC> infinity: sorry about that
[20:46] <BenC> micahg: thanks
[20:46] <infinity> BenC: I'll get over it some day. :)
[20:47] <slangasek> dpkg-checkbuilddeps: Unmet build dependencies: xvfb
[20:47] <slangasek> hmm, echan
[20:47] <kees> slangasek: MREs were never supposed to skip SRU quality controls.
[20:48] <kees> slangasek: they were created to avoid busy-work for the SRU team when there was a historical precedent (and sufficient checks in place to assure future quality) such that the SRU team didn't have to bother reviewing a given package.
[20:48] <slangasek> kees: that's not my understanding of what's been proposed here
[20:49] <slangasek> also, it's very hard to establish a historical precedent of successful SRUs following the existing SRU policy for these things because the scale of review involved in actually doing it by the book is too onerous
[20:50] <kees> slangasek: hence my suggestion that perhaps the SRU process needs to be adjusted.
[20:50] <slangasek> in the specific case of libreoffice, we do have a history of successful point release updates... natty, oneiric, precise all have point-release SRUs
[20:50] <infinity> I review pretty much everything I accept, except for mozilla.org and libreoffice, and even those, I give a cursory glance.
[20:50] <slangasek> are these not sufficient?
[20:51] <kees> slangasek: ah, I either missed that, or it wasn't mentioned in the request.
[20:51] <verwilst> kees, ping
[20:51] <kees> slangasek: I think it may help to have an SRU team member speak up on behalf of MRE requests in the future, actually.
[20:51] <kees> verwilst: pong
[20:51] <verwilst> oh :)
[20:52] <verwilst> kees, i would like to monitoring-default-off.patch :)
[20:52] <verwilst> uh "talk to you about"
[20:52] <slangasek> kees: so you think that it should be a judgement call of the SRU team to decide whether we should rely on upstream regression testing as sufficient verification for an SRU?
[20:52] <kees> verwilst: yeah, seems to have caused problems for ivoks too
[20:53] <verwilst> kees, the "activation/monitoring=0 is incompatible with clustered Volume Group "test": Skipping." i presume
[20:53] <slangasek> kees: right, perhaps it didn't get mentioned... anyway, libO does have a bit of precedence here
[20:53] <kees> slangasek: I think that if it makes sense for that package and Ubuntu, yes. I think there are 3 distinct situations: "single fix SRU", "upstream point release SRU", and "MRE"
[20:53] <verwilst> it's not an issue on centos though, and no dmeventd running there
[20:54] <kees> slangasek: and I can see how that latter two seem similar.
[20:54] <micahg> slangasek: kees: there was also a failed SRU in oneiric for LibreOffice for which there is no plan to fix it, I would hope that if an MRE is granted, it's made clear that regressions do need to be addressed
[20:54] <micahg> it's in -proposed, so it's not that big of a deal to drop I guess
[20:54] <kees> slangasek: but the MRE, IMO, was designed more for blessing a package so it doesn't have to the SRU team doing extensive examinations.
[20:56] <slangasek> kees: where is category 2 defined?
[20:57] <kees> slangasek: it isn't -- it's what you've just described, and what is being discussed here.
[20:57] <slangasek> ah
[20:57] <kees> slangasek: there appears to be a need for "there are so many changes here, SRU team must depend on upstream to declare it okay"
[20:57] <infinity> slangasek: I think kees is implying that the middle category goes through the same level of review and rigor, while we let the latter "slide".
[20:57] <slangasek> https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases is what we currently have AIUI
[20:58]  * kees re-reads https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[21:01] <kees> hrm, yeah, I guess the "history of successful SRUs" isn't in there at all.
[21:02] <verwilst> kees, i guess i'm interrupting? :)
[21:02] <kees> verwilst: I'm actually reading the history of this patch now to refresh my mind...
[21:02] <verwilst> oh, sweet :)
[21:02] <kees> verwilst: the problem appears to be that we cannot have a requirement that dmeventd be running.
[21:03] <kees> verwilst: the problem ivoks ran into seems to be that the patch accidentally makes it so you can _never_ talk to dmeventd. :P
[21:03] <kees> verwilst: so, I think, solving that is what's needed here.
[21:03] <kees> verwilst: does that match what you're seeing?
[21:04] <verwilst> euh
[21:04] <verwilst> dmeventd isnt running on my precise either
[21:04] <verwilst> but vgchange --monitor y works
[21:05] <kees> weird
[21:07] <verwilst> if /etc/lvm/lvm.conf has monitoring=0 by default for example, shouldnt that stop lvm from talking to the mythical dmeventd as well?
[21:07] <verwilst> because now it seems to ignore that setting
[21:07] <herton> @pilot out
[21:08] <verwilst> it also breaks the init script when using clustering, since i had to add --monitor y after every vgchange myself there
[21:08] <kees> verwilst: right, the bug appears to be ignoring that config item.
[21:09] <kees> verwilst: we need to be able to run the lvm commands without /etc/lvm/lvm.conf (in very minimal environments), so the binary default needs to stay off, but the config should be respected.
[21:09] <verwilst> kees, makes sense
[21:09] <verwilst> but that sounds like quite some custom coding inside lvm
[21:10] <verwilst> can't your minimal env have an empty lvm.conf? :D
[21:11] <kees> verwilst: it can, but it shouldn't need to, is my point. right now, the bug is that the config value isn't being respected. that's the distinct bug here, IMO.
[21:11] <verwilst> true
[21:16] <verwilst> kees, what would be the best way to proceed?
[21:16] <verwilst> since this bug is blocking my environment, i'm more than willing to help out :)
[21:20] <kees> verwilst: is https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368 the same situation?
[21:20] <kees> verwilst: I think ivoks has been looking at it, but trying to adjust the patch to do the right thing with regard to config settings is the next step
[21:21] <kees> verwilst: so if that's the right bug, subscribe to it, and check with ivoks or SpamapS
[21:21] <kees> verwilst: otherwise, open a new bug and ping SpamapS :)
[21:21] <kees> verwilst: though strictly speaking, it's really slangasek's problem ultimately, so maybe check with xnox. :)
[21:22] <xnox> hello people
[21:22]  * xnox reading backlog
[21:22] <kees> xnox: I know you're working on mdadm, but this is in lvm2. not sure if that's under your umbrella or not.
[21:23] <kees> xnox: basically, the lvm2 commands aren't reading a config setting correctly, due to a patch I wrote to change things.
[21:23] <kees> in a pinch, I can try to work on it, but I have no idea how soon that'll be.
[21:24] <slangasek> lvm2 is, but so far the cluster stuff has been the server team's department
[21:25] <kees> slangasek: it's on the fence, really, since the patch was there for udeb-ish situations, which isn't the server team's problem, etc.
[21:26] <slangasek> yes it is ;)
[21:26] <slangasek> rather, let's say it's a shared responsibility
[21:26] <verwilst> i think that's the correct situation kees
[21:26] <slangasek> scrollback is long; is there a bug ref?
[21:27] <kees> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368
[21:27] <verwilst> i even made 2 useless comments at the bottom ( hey, it was very late.. :P )
[21:29] <kees> slangasek, verwilst: I've tried to summarize the requirements in a comment there now
[21:29] <xnox> kees: slangasek: I am happy to look at that at some point. Seems to be a valid bug.
[21:29] <lepagee_> Hi, I am trying to package something for launchpad, but I get "rmdir: failed to remove `obj-i686-linux-gnu': No such file or directory" on out build system. When I copy the debian dir in my project, it work fine. We use a custom build script, http://pastebin.com/5vzSVJGE Any idea what is wrong with it?
[21:30]  * verwilst cheers for xnox, kees and slangasek!
[21:30] <xnox> kees: slangasek: about the SRU of micro point release. I want to SRU e2fsprogs micro-release, and SRM mdadm micro-release, which I will be discussing with 12.04.1 release team meeting tomorrow.
[21:31] <xnox> as those fix serious bugs, and they are purely bugfix releases.
[21:31]  * xnox goes to subscribe
[21:31] <slangasek> xnox, kees: it shouldn't be too high up the todo list for foundations... I'd really rather someone (e.g. ivoks) who's actually using clustered LVM2 tell us what's needed
[21:31] <kees> xnox: seems like an easy one for the SRU team to +1
[21:31] <kees> slangasek: yeah, agreed
[21:32] <xnox> kees: I am still to prepare a reports.
[21:32] <xnox> kees: I'm hoping to bump btrfs-tools with a ~2year update as an SRU, that one might be a bit tricky, but I have a case for that as well.
[21:33] <xnox> lepagee_: rm -rf your friend? clean runs before build, so you should assume that everything might be clean already. Run clean twice locally and make sure it is fine.
[21:33] <slangasek> backport please
[21:34] <xnox> slangasek: and what shall I do with bugs that precise kernel is out-of-sync with btrfs-progs, and machines fail to boot because of that?
[21:34] <slangasek> xnox: it doesn't meet SRU policy to bump btrfs-tools, no matter how un-featureful the current version is; so please use precise-backports
[21:34] <slangasek> really?
[21:34] <xnox> slangasek: =)))))
[21:35] <xnox> slangasek: althought, it's fixables with symlinking btrfs.fsck to /bin/true as a minimal SRU, or removing it at all =)
[21:35] <xnox> in precise
[21:35] <slangasek> why do they need to be in sync at all?  it's not like btrfs.fsck does anything :P
[21:35]  * xnox you didn't hear that ;-)
[21:35] <slangasek> sigh
[21:35] <xnox> slangasek: 'your filesystem has features not supported by this version of btrfs. exit 1'
[21:35] <xnox> because for some bizaer reason they do?!
[21:36] <verwilst> maybe the udeb scripts can use --ignoremonitoring?
[21:36] <lepagee_> xnox: The script does a git checkout, this should clean everything, the problem is probably elsewhere
[21:36] <xnox> slangasek: now it actually does something vague on the useful side of the fence
[21:37] <slangasek> xnox: if users set pass to 0 in /etc/fstab, does the problem go away?
[21:37] <xnox> slangasek: will test tomorrow now that I have 4x1TB drives to play around with stuff =)
[21:38] <slangasek> xnox: because frankly I like that option much better... less work for you, and less risk of giving users the accidental impression that btrfs is something well-supported in the world (let alone in precise)
[21:39] <xnox> slangasek: well have you seen ubuntu-planet http://www.jorgecastro.org/2012/06/04/playing-with-btrfs/ ?
[21:40] <slangasek> xnox: heh
[21:41] <slangasek> xnox: don't listen to that guy, he builds all his code with -fruit-rollups
[21:41] <xnox> slangasek: both old and newer btrfs.fsck get killed with OOM on 1TB drives. latter version gets kill later than the former.
[21:43] <slangasek> xnox: you're really not selling me on the value of an SRU here ;)
[21:44] <xnox> slangasek: ok, I will settle for btrfs-tools backport ;-)
[21:44] <micahg> xnox: only 3 rdeps, so should be easy enough
[21:44] <micahg> and one of those is a meta package, so 2
[21:45] <Laney> micahg: while we're on backports, I think some of Yolanda's stuff got ready
[21:45] <Laney> fancy taking a look? …
[21:46] <micahg> Laney: how are you uploading the stuff without ubuntu diff with the broken backportpackage script?
[21:46] <Laney> broken?
[21:46] <micahg> Laney: I can a bit a later, I have to get some stuff done today :)
[21:46] <Laney> I'm running out of bzr if that makes a difference
[21:46] <micahg> bug 1007042
[21:47] <Laney> oh, probably because I have DEBEMAIL=iain@orangesquash.org.uk when building backports usually
[21:48] <verwilst> xnox, if you need help testing, a shoulder to cry on, etc about the lvm bug, let me know! :)
[21:49] <xnox> verwilst: noted.
[21:49] <micahg> Laney: that's one solution I suppose :), but I like to have my Ubuntu address in debian/changelog
[21:50] <hallyn> does the following mean anything to anyone?
[21:50] <hallyn> objcopy:debian/qemu-kvm/usr/bin/stKSZjR6: cannot create debug link section `debian/qemu-kvm-dbg/usr/lib/debug//usr/bin/qemu-x86_64': Invalid operation
[21:50] <xnox> Laney: yoanda doing progress. Good, need to catch up on that.
[21:51] <Laney> deps are getting there
[21:52] <Laney> is the actual package nearly ready to be sponsored?
[21:52] <xnox> Laney: not sure =) I have been busy looking for a house to live in. Otherwise I will be homeless on the 4th of July =)
[21:53] <Laney> an interesting form of independence
[21:53] <xnox> Laney: last time I spoke with yolanda, I gave a guide on plenty things to do.
[21:53] <micahg> Laney: I guess no one will freak if I use a different address for a few backports
[21:53] <xnox> tell me about it =)
[21:54] <xnox> micahg: nope =) we know where to find you?
[21:54] <Laney> micahg: A reasonable solution would be to unset DEBEMAIL when building the source package in backportpackage
[21:54] <micahg> Laney: nope, then user@host is used :)
[21:54] <Laney> used for what?
[21:54] <micahg> it just needs to be unset for the debuild part
[21:54] <Laney> the changelog is already generated then
[21:54] <Laney> yes
[21:54] <Laney> building the source package
[21:54] <micahg> ah, that's what you meant :)
[21:55] <micahg> yes, I thought I suggested that
[21:55] <xnox> micahg: btw I'm having two thunderbird icons in quantal right now: a normal unity one with the badge & ugly pixelated bamf one for each window
[21:55] <micahg> xnox: as chrisccoulson :)
[21:55] <micahg> *ask
[21:55] <xnox> chrisccoulson: ^^^ see my last message to micahg
[21:55]  * xnox should really look on launchpad for a bug....
[21:55]  * micahg thought he saw a report for that as well
[21:56]  * xnox is tempted to finally port all of my email identities to gnus-alias and move away from thunderbird, because of that bug =)
[21:57] <chrisccoulson> xnox, yes, there is already a bug on launchpad for that
[21:58] <xnox> chrisccoulson: do you have a bug # or a search keyword?
[21:58]  * xnox wants to subscribe to it
[22:01] <xnox> bug 1012158
[22:01] <xnox> found it!
[22:24] <Laney> micahg: proposed a branch. Maybe give it a go when you process your next backport?
[22:25] <micahg> Laney: ok
[22:35] <micahg> stgraber: did that newt get away from you?
[22:36] <stgraber> micahg: I know
[22:36] <stgraber> micahg: I was just mentioning it in another channel
[22:36] <stgraber> micahg: I need to teach dput to allow the target to be given as the last arg :)
[22:36] <micahg> heh
[22:36] <stgraber> anyway, it's ~ppa1 just because I wanted to make sure it builds on the buildd before uploading, the package itself is archive-ready
[22:38] <stgraber> micahg: btw, you're really low latency today ;) I really just had time to see it go wrong in my shell, complain about dput in #pyjam, then saw your hilight :)
[22:38] <micahg> stgraber: just happened to be looking there I guess :)
[22:48] <cjwatson> Laney: techboard mail> done
[22:49] <Laney> tidy
[22:55] <doko> jtaylor, well, get the patch into debian
[23:13] <ScottK> doko: Speaking of getting things into Debian ... how about python2.7/3.2 updates?
[23:34] <Bluefoxicy> so
[23:34] <Bluefoxicy> I have an idea to derive a C library from {BSD|GNU} awk that supplies a handful of functions to:
[23:35] <Bluefoxicy> 1) initialize an 'awk' object from a string containing an awk script (including copying the script to its own memory space--compiling it to bytecode etc)
[23:36] <Bluefoxicy> 2)  Allow the calling of awk as if it were continuously executing against a stream by passing char* strings acting as lines (or multiple lines) of a stream
[23:36] <Bluefoxicy> 3)  Check the status of awk (did it terminate, i.e. by eof or exit command)
[23:36] <Bluefoxicy> 4)  Destroy the awk object
[23:36] <Bluefoxicy> This is all mainly irrelevant here except for one detail
[23:36] <Bluefoxicy> I'm sure nobody wants to maintain a package for something called 'libcawk' so what should I call this thing?
[23:38] <JontheEchidna> there does exist a "libkok" (though not in Ubuntu) http://maemo.org/packages/view/libkok/ :P
[23:39] <ScottK> libobjawk
[23:49] <Bluefoxicy> heh
[23:49] <Bluefoxicy> ScottK has the best one I think
[23:50] <Bluefoxicy> it even has the advantage that, at a glance, it's not clear what in the hell the name is supposed to mean or how you're supposed to read it :P
[23:52] <ScottK> I came up with libkibi for bdrung too.