[02:17] <ScottK> lifeless: Will do.
[02:21] <ScottK> lifeless: https://answers.launchpad.net/launchpad/+question/200735
[02:22] <lifeless> thanks
[04:09] <SpamapS> how long after a package is accepted in Debian unstable must I wait before running syncpackage?
[04:09] <infinity> "A while".
[04:09] <infinity> I don't recall how often the syncy stuff runs.  Plus, it obviously can't run until after dinstall.
[04:10]  * SpamapS resolves to just wait till morning
[04:19] <lifeless> 'published'
[04:30] <larsduesing> good morning
[04:48] <pitti> Good morning
[04:49] <pitti> ev: the "upgrade after process start" is also fixed in -proposed, BTW; currently waiting for verification
[04:50] <pitti> slangasek: RT 52633> ok, thanks; I'll kill another arch or so then
[07:01] <dholbach> good morning
[07:10] <pitti> hey dholbach, wie gehts?
[07:12] <dholbach> hey pitti
[07:12] <dholbach> sehr gut - wie gehts dir?
[07:14] <pitti> dholbach: prima, danke!
[07:15] <pitti> a bit tired, we went to bed rather late (we watched the game in a Biergarten :) )
[07:15] <dholbach> ah nice :)
[07:15] <dholbach> I'm a bit tired as well - I only had about an hour's sleep on Sat→Sun
[07:15] <dholbach> but life's good :)
[09:17] <cjwatson> larsduesing: soyuz> I don't think you'd learn desperately much by doing that, compared to the effort involved; I do a good deal of archive infrastructure work and even I've never felt the need for a local soyuz instance (as opposed to running bits of soyuz via the LP test suite when making changes)
[09:25] <Laney> When I first wanted to do some LP development I tried to get Soyuz working too, but it's pretty nontrivial so now I also just tend to rely on the testsuite.
[09:34] <Riddell> pitti: are you the language pack expert?
[09:37] <pitti> Riddell: I guess I am
[09:37] <Riddell> pitti: where's the magic script to make them?  I want to change it so the kde ones are simple meta packages
[09:38] <pitti> Riddell: it's in https://code.launchpad.net/~ubuntu-langpack/langpack-o-matic/main
[09:54] <gema> cyphermox: can you guys have a look at bug 983583 ?
[09:55] <gema> cyphermox: the QA team cannot really use network manager to connect to our VPN because it is a pain atm
[10:09] <toabctl> bilal, about bug #1012505: are the dbus patches sent upstream? i can not find any mail on the dbus list about upstart integration for dbus.
[10:13] <brendand> does anyone know an option for pexpect in python3?
[10:13] <brendand> is there any conversion happening or an alternative?
[10:15] <xnox> brendand: "Pexpect-U is unicode-aware, and compatible with Python 3 (using distribute to run 2to3 during setup). It requires Python 2.6 or above."
[10:15] <xnox> http://pypi.python.org/pypi/pexpect-u
[10:15] <brendand> xnox, is there an ubuntu package?
[10:16] <xnox> brendand: no, but since it's pure python you could use pypi-install
[10:16] <xnox> which should make a package for you
[10:21] <toabctl> pitti, are there any reasons why ubuntu does not send the dbus patches upstream? there is already some code for systemd upstream, but nothing for dbus. i ask because i want to use dbus-test_runner on debian but the package needs a patched dbus version.
[10:21] <toabctl> nothing for upstart, i mean.
[10:21] <pitti> toabctl: the only patches I'm aware of that are not sent upstream are the ones for upstart activation
[10:22] <toabctl> pitti, yes. that's the question why theses patches are not send upstream.
[10:22] <pitti> I actually dropped them from my 1.5 merge in https://launchpad.net/~pitti/+archive/ppa/+packages
[10:22] <pitti> toabctl: I don't know; these are rather old, we don't use them, and I didn't feel like porting them
[10:22] <pitti> dbus 1.5 causes some trouble with the indicators, so it wasn't uploaded yet
[10:23] <toabctl> pitti, so ubuntu should also work with a upstream dbus version without theses patches?
[10:24] <toabctl> pitti, then maybe comment https://bugs.launchpad.net/dbus-test-runner/+bug/1012505/comments/2 is wrong?
[10:24] <pitti> yes, absolutely
[10:25] <pitti> toabctl: I followed up there
[10:26] <pitti> so we are down to two simple config change patches
[10:29] <toabctl> pitti, ok. thanks
[10:38] <larsduesing> cjwatson: Ok - thanks :)
[10:50] <seb128> SpamapS, slangasek, bdmurray, RAOF: the SRU queue is still around 25 items, some being there for 3 weeks, is there anything we can do to help that moving?
[11:12] <RAOF> seb128: When I last went through the queue the bottom items were all waiting on information/comment/action from the uploader; I'll do a sweep tomorrow and I'll reject those things waiting more than a two weeks for uploader action.
[11:13] <RAOF> If the uploader provides what we're after we can always fish the package out of the rejected queue.
[11:20] <seb128> RAOF, ok, thanks
[11:21] <seb128> RAOF, lo-menubar has a rational on why we need the new version, it's basically "it would be as much diff to backport the fix only" and the package is just broken atm and in universe so the update can only be a win
[11:53] <Laney> xnox: howdy, did you hear anything about emacs24?
[11:53] <xnox> Laney: I didn't get around about enquiring =(
[11:54]  * xnox it's at the bottom of my todo list
[11:55] <xnox> Laney: I'm using ppa:cassou/emacs and am generally happy about it. Apart from bamf/unity dash integration which I fixed up locally.
[11:55] <xnox> but that's emacs-snapshot and it will move on quickly =(
[11:57] <vibhav> How Do I configure dch and requestsync to use emacs?
[11:58] <jelmer> vibhav: they should just use the EDITOR or VISUAL environment variables I think
[11:59] <vibhav> lemme see
[11:59] <vibhav> mdeslaur: ping
[11:59] <mdeslaur> vibhav: yes?
[12:01] <vibhav> mdeslaur: Firstly, thanks for sponsoring my uploads
[12:01] <mdeslaur> vibhav: yw
[12:01] <vibhav> Also, I am applying for universe-contributors, could you write an endorsement at https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ?
[12:02] <mdeslaur> vibhav: remind me which uploads I sponsored for you?
[12:03] <mdeslaur> vibhav: ah, I see them on your page, never mind
[12:13] <xnox> vibhav: if you remove newlines between the table lines, it will render as one table, instead of a table per line.
[12:15] <vibhav> xnox: thanks!
[12:25] <vibhav> mdeslaur: done?
[12:26] <mdeslaur> vibhav: I don't have time to do that now...I'll get to it eventually, when are you applying?
[12:26] <vibhav> 2nd July
[12:27] <mdeslaur> vibhav: I'm not sure I've sponsored enough to actually write an endorsement in any case
[12:27] <mdeslaur> vibhav: one was a trivial merge, and the other was a SRU that I had to correct a number of things in the debdiff...not exactly enough material for me to form an opinion on your work
[12:40] <xnox> jodh: I'm plowing through eventbased initramfs specs/etherpads/braindups since like forever. I have currently fleshed out https://wiki.ubuntu.com/Initramfs with slightly more uptodate info (stealing from eventbased spec previously written ;-) )
[12:40] <xnox> please check it out =)
[12:41] <jodh> xnox: will do, thanks.
[12:48] <pitti> @pilot in
[12:48]  * vibhav hugs pitti
[13:03] <pitti> cyphermox: handing the network-manager task in bug 1013171 to you, as I cannot push to the Vcs-Bzr: (that ought to be fixed, perhaps?)
[13:03] <pitti> cyphermox: it's got a patch
[13:14] <cyphermox> pitti: ok, thanks!
[13:15] <vibhav> pitti: are you busy?
[13:15] <pitti> I'm always busy :)
[13:16] <vibhav> pitti: If you get some free time, could  you have a look at https://bugs.launchpad.net/ubuntu/+source/fische/+bug/1014637 ?
[13:16] <pitti> vibhav: yes, I can do that; I'm on patch pilot shift, after all
[13:16] <pitti> I just finished sponsoring #1013171, so going to the next one now
[13:18] <pitti> vibhav: has it actually been confirmed that this patch is still needed?
[13:18] <pitti> vibhav: if so, it would be good to send to upstream/Debian
[13:18] <vibhav> yeah
[13:18] <pitti> otherwise we'll carry such stupid patches forever
[13:19]  * vibhav nods
[13:19] <pitti> vibhav: so, how about I sync fische first, and if it fails on armel still, we apply this?
[13:19] <vibhav> sure!
[13:21] <vibhav> pitti: You are going to do that in a PPA, right?
[13:21] <pitti> no, I synced it into quantal
[13:21] <pitti> we don't have publicly accessible arm PPAs
[13:22] <vibhav> ah fine
[13:27] <pitti> vibhav: followed up to bug 1014317; do you know how to submit a Debian bug?
[13:27] <vibhav> yup
[13:27] <vibhav> lemme do that
[13:31] <pitti> vibhav: fische built fine
[13:32] <pitti> vibhav: your qof merge says "for a first build", but quof is already built on armhf; so this looks obsolete as well?
[13:32] <pitti> same story, /me syncs first
[13:37] <vibhav> pitti: SO Ill set the fische merge request to invalid?
[13:37] <pitti> I already closed it
[13:38] <arges> doko__, hello. i was told you would be the person to ask about armel compilation problems?
[13:46] <vibhav> Any idea why debuild -S -sa fails in rbot with http://paste.ubuntu.com/1047313/ ?
[13:46] <pitti> vibhav: looks like a missing build dep on some ruby tools
[13:47] <vibhav> Well, I did build-dep rbot
[13:47] <vibhav> Looks like thats not enough
[13:48] <geser> you need gem2deb
[13:48] <geser> (and it should be listed in Build-Depends)
[13:48] <vibhav> I was going to say that
[13:49]  * vibhav does that
[13:51] <vibhav> then , as per me logic, rbot should FTBFS in debian sid too
[13:53] <jamespage> infinity, OK if I steal the hsqldb merge from you? it has a Java 7 fix and I need to update it for the tomcat7 transition as well....
[13:54] <vibhav> jamespage: You busy?
[13:55] <xnox> jamespage: i'd think infinity is still asleep =)))) am I sure he wouldn't mind ;-)
[13:55]  * pitti notes that "are you busy" is a trick question which you should avoid; just ask your actual question
[13:55] <jamespage> vibhav, yes :-)
[13:56] <jamespage> vibhav, hey - wassup - missed your ping yesterday
[13:57] <vibhav> jamespage: Well, If you get some free time, could you add an endorsement on https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ?
[13:57] <jamespage> vibhav, on my TODO list already
[13:57] <vibhav> thanks!
[13:57] <vibhav> pitti: thanks for sponsoring
[14:00] <jamespage> xnox, I'm sure he won't - but its good etiquette to ask first!
[14:00] <xnox> ;-)
[14:04] <pitti> vibhav: btw, merges need a justification why the current delta is still applicable; it would be easier if you could do that research before spending your (and also your sponsor's) time on merges which can just be syncs
[14:06] <arges> cyphermox, hey have a question about nm. pad.lv/872824 is a bug about strongswan vpn not being compatible with NM. I see some patches on this bug, and am wondering what approach would make sense in getting this functionality working. thanks
[14:06] <vibhav> pitti: sure, thanks for the info though
[14:07] <cyphermox> arges: it would take extensive porting of the strongswan plugin to the new API; IIRC
[14:08] <cyphermox> I'll look at the patches again
[14:08] <arges> cyphermox, ok thanks. yea i'd like to know what the approach is
[14:23] <doko> arges, anything more specific?
[14:30] <seb128> pitti, bug #984944, I can't verify it still
[14:30] <seb128> pitti, doing the package update steps I get a
[14:30] <seb128>   File "/usr/lib/python2.7/dist-packages/apport/report.py", line 439, in add_proc_info
[14:30] <seb128>     assert os.path.exists(self['ExecutablePath'])
[14:30] <seb128> in the log
[14:31] <apw> pitti, are we expecting a cups to sync through or should be we be patching it in ubuntu ?
[14:36] <arges> doko, yes. looking at the build for witty: https://launchpad.net/ubuntu/+source/witty/3.2.1-2/+build/3572681
[14:36] <arges> seems to build fine on other archs + armhf, didn't know if this was a known issue, or I should follow through with a bug
[14:40] <apw> infinity, a few for review in http://people.canonical.com/~apw/plusone/
[14:40] <pitti> xnox: you can certainly continue to use UDD for merges if it works for you; I was just pointing out that in general debdiffs are faster on the sponsor side, but I'll deal with UDD :)
[14:40] <Chipzz> xnox: concerning https://wiki.ubuntu.com/Initramfs : "All these files are collected in a temporary directory and then they are cpio archived and then gunziped." -> I think you mean gzipped instead of gunzipped there
[14:41] <pitti> seb128: hmm, I only tested it in quantal; I'll need to have a closer look at this then, in a precise environment
[14:41] <pitti> apw: we generally keep cups in sync; there's another (two) RC bugs I'd like to fix in Debian before an upload, if only I'd ever get to it
[14:41] <seb128> pitti, ok, no hurry but I can't confirm the fix, feel free to grab me if you need debug infos
[14:42] <xnox> pitti: ok. to be honest doing $ bzr diff -rtag:1.0-1 > merge.debdiff && open lp bug && attach is easy enough. And is comparable to $ bzr push lp:~/ubuntu/quantal/package/merge && bzr lp-propose-merge
[14:42] <xnox> pitti: one spams branches/merge proposals; the other spams bug reports
[14:43] <Chipzz> xnox: also you have some typo's: "calls run-init to run the real init in yoru reall roofs kept in /root."
[14:43] <xnox> pitti: I'm up for coredev this evening, so maybe soon I will be on the sponsorship side fighting with UDD ;-)
[14:43] <pitti> xnox: if it works for you, great; I just find that UDD forces me to spend a rather inordinate amount of time fiddling with patches and rejectinos
[14:43] <xnox> pitti: =((( sad times
[14:44] <xnox> Chipzz: I didn't write any of it =)))) I refactored it out of out-of-date spec. And this type of information was more suitable on the Initramfs page
[14:44] <xnox> Chipzz: fixes welcome =)))))
[14:44] <Chipzz> xnox: ah kk, nm then :)
[14:45] <xnox> Chipzz: nm = nanometer?
[14:45]  * xnox is confused
[14:45] <Chipzz> xnox: don't think I have an account to edit that
[14:45] <Chipzz> xnox: nm = nevermind
[14:47] <xnox> Chipzz: if you don't have an account, I will pick up your questions above and factor them in. It only needs a launchpad account to login?!
[14:47] <Chipzz> ah k I have a lp account
[14:47] <Chipzz> wasn't sure what was needed for it
[14:48] <Chipzz> xnox: hrrrm, but it says "Immutable Page"
[14:48] <Chipzz> wouldn't that restrict things mortals like me can do?
[14:49] <cjwatson> That sounds like you're not actually logged into the wiki
[14:49]  * xnox is a mere mortal with a lp account
[14:49] <Chipzz> cjwatson: prolly. trying to remember credentials :)
[14:50] <Chipzz> found it
[14:58] <kelemengabor> pitti: ping, got a few minutes for language pack updating?
[14:58] <kelemengabor> http://irclogs.ubuntu.com/2012/06/15/%23ubuntu-devel.html#t14:27
[14:58] <pitti> kelemengabor: I have a meeting in 1 minute, sorry
[14:58] <kelemengabor> okay, maybe later :)
[14:59] <pitti> kelemengabor: you need copying PPA -> -proposed?
[14:59] <pitti> kelemengabor: I can do that, yes
[14:59] <smoser> cjwatson, could you comment on bug 1014695? i think i talked to you at UDS about this request, and i think you at least implied you'd be open to it.
[15:00] <kelemengabor> pitti:  yes, thanks in advance
[15:01] <Chipzz> xnox: fixed (including several other typos)
[15:01] <xnox> Chipzz: thank you a lot!
[15:01] <Chipzz> np, 5min work :)
[15:02]  * Chipzz wonders when spell-checking, should technical terms be added to the dictionary, or should it be left alone?
[15:03] <Chipzz> I simply left it alone this time
[15:04] <cjwatson> smoser: I would be open to it as long as it's in a separate source package I don't need to have anything to do with :-)
[15:04] <cjwatson> smoser: With it in a separate source package, there should be no need to gate on me for anything
[15:04] <smoser> hmm... i thought you had implied it'd be ok to be in grub source package.
[15:05] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672104
[15:05] <pitti> kelemengabor: seems there isn't any newer version in the PPA, it still has 0508
[15:06] <cjwatson> smoser: Well, it kind of would, but it's not really connected to it.  I think it would be better to have it separate.
[15:06] <cjwatson> And I don't see why it can't be?
[15:06] <smoser> cjwatson, right. and i was reading the debian bug too.
[15:06] <smoser> cjwatson, the other thing you were going to do for me was just create pv-grub2
[15:06] <smoser> :)
[15:06] <kelemengabor> pitti: argh indeed, the crontab seems to be disabled :(
[15:06] <kelemengabor> precise-updates at 10:00 on Tue: disabled
[15:06] <cjwatson> *I* sure wasn't
[15:06] <infinity> jamespage: I have no attachment to hsqldb, all yours.
[15:06] <cjwatson> I don't even slightly have time
[15:07] <cjwatson> Upstream has done some work on this, whose status I'm not up to date with
[15:07] <pitti> kelemengabor: reenabled
[15:07] <kelemengabor> thanks!
[15:07] <pitti> kelemengabor: so I guess we'll wait a few days for the PPA to update
[15:07] <cjwatson> So if that arrives for free with 2.00, great - but otherwise ...
[15:07] <smoser> cjwatson, i'm just kidding. i did think at one time i thought i had you near thinking "hm... that does sound kind of neat, maybe i'll just stay up all night and do that" (regarding grub-pc)
[15:07] <smoser> er... regarding pv-grub2
[15:07] <cjwatson> Yeah, but infinite work
[15:08] <kelemengabor> pitti: right, sorry for not checking that before
[15:08] <pitti> kelemengabor: no problem
[15:08] <cjwatson> Anyway, if it sucks too badly to have it outside grub, feel free to merge the grub-legacy-ec2 stuff into grub (not grub2) in as noninvasive a way as you can manage
[15:08] <cjwatson> I'd review a patch, but am unlikely to be able to help otherwise, I'm afraid
[15:09] <cjwatson> It *really* doesn't belong in grub2
[15:09] <smoser> cjwatson, i think i
[15:09] <cjwatson> But maybe it could be conditionals in the code in grub (legacy
[15:09] <cjwatson> )
[15:10] <smoser> i think it'd be better outside of grub than inside it.
[15:10] <smoser> so if i'm going to split it out of cloud-init, i think i'd go to new package rather than grub
[15:10] <smoser> but thanks.
[15:11] <jamespage> infinity, marvellous
[15:11]  * jamespage goes to sync it
[15:14] <highvoltage> stgraber: well, if you have some time for this at any point :) https://code.launchpad.net/~jonathan/ubuntu-seeds/edubuntu.quantal/+merge/110841
[15:24] <hallyn> highvoltage: hey, not sure if you're on the lxc-devel m-l, but i'd be interested if you had any opinions on http://sourceforge.net/mailarchive/forum.php?thread_name=20120615221638.GA6236%40sergelap&forum_name=lxc-devel
[15:25] <highvoltage> hallyn: I'm only on lxc-users but stgraber mentioned something about lxc-devel last week and I've been meaning to subscribe
[15:25] <hallyn> highvoltage: :)  i tried to convince people to merge the two lists, but they wouldn't go for it :)
[15:26] <stgraber> highvoltage: looks good, merging. I'll refresh edubuntu-meta a bit later
[15:27] <highvoltage> stgraber: thanks!
[15:41] <barry> kenvandine: so i think the good news is that libpeas *already* supports py3.  e.g. PYTHON=python3 ./configure --enable-python passes all its tests.  i scanned the code and found only very minor issues (which i'll open upstream bugs on) but none of which afaict should affect py3.  i think the tricky part will be building 1.4.0 in ubuntu such that an app can either enable py2 or py3 plugins (but obviously not both)
[15:42] <kenvandine> cool
[15:46] <xnox> barry: since libpeas is compile time, make two python2/3 libpeas dev packages and make them conflict each other. None of the reverse-build-dependencies of libpeas will be able to enable both of them.... unless there is a fallacy in my argument.
[15:46] <xnox> barry: provides, conflicts dance thingy as done for e.g. virtual mta package
[15:47] <barry> xnox: my thinking too
[15:47] <xnox> =)
[15:47] <barry> lunch first :)
[15:49] <infinity> jamespage: Hrm, two things about that sync.  One, you dropped the default-jre-headless dep (maybe that's okay?), and two, the arch line seems to confuse lp-buildd's sbuild.  Not sure if it should or not, that may need investigating and fixing on the buildds.
[15:50] <jamespage> infinity, yeah - I'm looking at that ATM
[15:50] <jamespage> the drop on the dependency is OK
[15:50] <jamespage> but the architecture check in sbuild is doing something cranky
[15:50] <infinity> jamespage: You could "fix" it by just letting that package build on "any" again, but perhaps the current arch list is perfectly legal and we're just not handling it correctly, due to the fact that we've never run into a package that was "all something-not-i386" before. :P
[15:51] <jamespage> infinity, OR I could just drop the bits that are being retained for kfreebsd-*
[15:51] <jamespage> or we could fix sbuild
[15:51] <jamespage> I think its a valid combination
[15:51] <infinity> Dropping those bits would be a quick and simple hack, yeah.
[15:52] <jamespage> that would get me out of jail now
[15:52] <infinity> Filing a bug on launchpad-buildd and assigning it to me for the issue would be nice.
[15:52] <jamespage> infinity, sure - I just tested something locally with sbuild which I think resolves it
[15:52] <infinity> But dropping the freebsd-only package seems like a quick fix.  I don't have the time to fix lp-buildd right now.
[15:52] <jamespage> infinity, ack
[15:52]  * jamespage goes to file a bug
[15:54] <slangasek> SpamapS, pitti: where do we stand wrt nova getting an MRE?  It looks like the upload to oneiric-proposed has still not progressed, and there's another package that's been uploaded to precise-proposed queue
[15:56] <AnAnt> Hello, who should be subscribed to LP #1014705, ubuntu-sponsors or someone else ?
[15:56] <Daviey> slangasek: The original precise one was superseeded by security upload
[15:56] <xnox> barry: you sound like movie the Mask: "But first..."
[15:57] <Daviey> slangasek: which just dropped the proposed package dead in the water
[15:58] <slangasek> seb128: the lo-menubar SRU is not at all clear; comment #11 from pitti on bug #754562 claims that this bug is *invalid* for lo-menubar in precise, and I don't see which bit here is supposed to supersede this.
[15:59] <slangasek> Daviey: which "original" precise one are you referring to?  I don't see that there's ever been a nova SRU accepted for precise
[16:00] <slangasek> Daviey: and the one in the queue is stalled not because of a security update but because it doesn't appear to fit the SRU policy
[16:01] <Daviey> slangasek: we were discussing this in #ubuntu-server about an hr ago.
[16:02] <xnox> jamespage: what's the bug number?
[16:02] <jamespage> xnox, just writing it now
[16:02] <Daviey> slangasek: We are intentionally doing SRU's that don't normally fit the SRU policy
[16:02] <xnox> jamespage: surely the lucid buildds have no clue what kfreebsd-* is what's so ever
[16:02] <Daviey> slangasek: bdmurray has been trying to dig into it.
[16:02] <Daviey> Context: https://lists.ubuntu.com/archives/technical-board/2011-December/001155.html
[16:02] <bdmurray> Daviey: I went through and read more of the tech board emails
[16:03] <slangasek> Daviey: it's because of bdmurray's digging that I'm pinging SpamapS and pitti for the MRE status
[16:03] <bdmurray> Daviey: and it seems like the tech board wants to see a history of successful micro releases being SRU'ed but that is explictily stated anywhere
[16:03] <jamespage> xnox, bug 1014722
[16:03] <slangasek> Daviey: and MREs are part of the SRU policy - I mean that this SRU neither has an MRE nor is verifiable using the more traditional route
[16:03] <Daviey> bdmurray: this is the test candidate to 'see how it goes' to be granted MRE, no?
[16:04] <slangasek> the test candidate was one uploaded to *oneiric*
[16:04] <slangasek> which has stalled 6 months, and now there's another upload to precise
[16:04] <Daviey> slangasek: yes, the test candidate from oneiric is the one that failed due to security superseeding
[16:04] <slangasek> ok
[16:05] <Daviey> which is why we are super keen to get this progressing to minimise the chance of it happening again
[16:06] <xnox> jamespage: commented ;-)
[16:06] <slangasek> Daviey: getting it to progress is going to require having some plan for how the SRU is going to be verified, which is what I'm asking for
[16:07] <slangasek> accepting it into -proposed only to have it stall there because no one will verify it is a waste of everyone's time
[16:07] <Daviey> slangasek: Right.. So.. We are doing unit testing at package build time.. functional testing in the CI lab, and extended validation by putting it into production in a real cloud (canonistack)
[16:08] <Daviey> (canonistack will test the -proposed package, when it lands there)
[16:08] <bdmurray> well it also seems like pitti is for an alternate verification process, one where each bug isn't necessarily verification-done
[16:08] <slangasek> and this testing would be done for any nova SRU, or just the ones for precise because canonistack happens to be running precise?
[16:09] <slangasek> and what should happen with the oneiric nova SRU that's still sitting there?
[16:09] <bdmurray> Daviey: https://lists.ubuntu.com/archives/technical-board/2011-December/001153.html - here chuck says the package won't FTBFS if the testsuite failed
[16:09] <bdmurray> Daviey: has that changed?
[16:10] <zul> bdmurray: yeah its been like that for a while now
[16:10] <Daviey> bdmurray: was that a typo?  they DO ftbfs if unit tests fail, no?
[16:10] <Daviey> zul: ^
[16:10] <zul> they do
[16:11] <Daviey> slangasek: I don't have a good answer for Oneiric.. We can do extended validation ourselves, but not in a proper cloud.
[16:11] <bdmurray> Daviey: not a typo
[16:11] <Daviey> slangasek: We are closely involved with upstream stable tress.. zul and myself are both reviewers.  The idea is to keep upstream ubuntu regression free (which is why we've invested in so much CI)
[16:12]  * Daviey has to go now.. but will be back later.
[16:14] <SpamapS> slangasek: AFAIK, nova has no MRE, and the decision was stalled on "lets try a pretend one" where we don't verify all bugs but show a lot of regression testing.
[16:14]  * SpamapS responds and *then* reads and realizes this is still under discussion
[16:17] <slangasek> Daviey: well, that doesn't sound like you're *committing* to do that validation though?  Either somebody should commit to following through on the oneiric SRU (including updating it for whatever security fixes make the current one invalid), or we should kick it out of -proposed instead of leaving it sitting there
[16:18] <slangasek> Daviey: in any case, if the one currently in -proposed is non-promotable because it's missing security fixes, we should remove that one from -proposed... is that the current state?
[16:20] <zul> slangasek: imho we should kick oneiric out from -proposed
[16:22]  * xnox was under impression that heavy testing is done *before* uploading to -proposed, not after. as suggested above by Daviey "(canonistack will test the -proposed package, when it lands there)"
[16:22]  * vibhav hugs xnox 
[16:23] <vibhav> xnox: thanks for the comment!
[16:23] <slangasek> xnox: we prefer that as much testing as possible happen with the real live package in -proposed, to avoid any mistakes with misbuilt binaries
[16:24] <xnox> slangasek: ok I see your point. Simply other things, e.g. kernel, X-org edgers, KDE have beefy PPAs for pre testing before upload to -proposed.
[16:25] <xnox> slangasek: yet one more unwritten "de-facto" policy
[16:25] <slangasek> xnox: the kernel ppa is a special case, we *copy* those binaries from the ppa into the archive
[16:25] <vibhav> Ampelbein: ping
[16:25] <slangasek> xnox: in cases where we don't do a package copy, I do not consider ppa testing a substitute for SRU testing
[16:26] <SpamapS> xnox: perhaps de-facto, but I think also pretty obvious as to why.
[16:26]  * xnox noted, ok
[16:26] <slangasek> zul, SpamapS: nova removed from oneiric-proposed
[16:26] <slangasek> zul, SpamapS, Daviey: nova removed from oneiric-proposed
[16:27] <zul> slangasek: cool
[16:43] <vibhav> How can I debuild -S -sa msv without installing maven?
[16:43] <vibhav> http://paste.ubuntu.com/1047590/
[16:44] <tumbleweed> vibhav: -nc
[16:44] <vibhav> tumbleweed: thanks!
[16:44] <tumbleweed> but you can only do that when it is already clean
[16:44] <vibhav> yeah, done that
[16:53] <seb128> slangasek, I didn't read the full bug history to be honest so I'm not sure about the old comments, the bottom line is that the precise version segfault when you try to print preview with lo-menubar installed
[16:54] <seb128> slangasek, which is happening to lot of users who read on the internet to install lo-menubar to get menus integrated, hud working, etc
[16:57] <Daviey> xnox: We also have a pre-proposed PPA, where testing happens.
[16:57] <xnox> ok
[16:57] <Daviey> xnox: We also regress test as much as we currently can per-commit, upstream
[17:00] <seb128> slangasek, bdmurray: if you have questions about the lo-menubar can you maybe grab directly kenvandine on IRC to sort them? that might work better than bug pingpong to figure what details you guys need
[17:01] <jml> any idea when emacs24 might hit quantal?
[17:02] <seb128> jml, when it's ready (tm) ;-)
[17:02] <jml> heh
[17:02] <xnox> jml: currently no. there are a lot of emacs users from ubuntu core devs. and we all want it =)
[17:02] <xnox> this reminds me of Laney doing a ping on me this morning to ping emacs maintainer about it.......
[17:03] <Laney> ping me to ping you to ping him
[17:03] <seb128> jml, <xnox> Laney: I'm using ppa:cassou/emacs and am generally happy about it.
[17:03] <mpt> pitti, hi. I have a work item for the installer, "add '3-D graphics' to the installer's third-party software text (ubiquity can detect whether nvidia card is in the system)". But ev just told me he thought the plan is to remove the Nvidia driver from that software bundle. Do you know which is right?
[17:03] <seb128> jml, read earlier on this channel, in case that's of any use to you
[17:04] <jml> seb128: ah yes, thanks.
[17:04]  * barry also wants emacs 24.1 :)
[17:04] <jml> I'll go back to waiting patiently then. I'm not in a rush to use a snapshot.
[17:09] <xnox> mpt: pitti: ev: I think I saw bugs about not being able to install nvidia proprietary driver, while running in Live-CD / during installation. It succeeds only after first boot.
[17:10] <ev> xnox: right, we never installed it in the live cd session
[17:10] <ev> on in the target system
[17:10] <ev> only*
[17:12] <xnox> mpt: ^^ i think you have your answer =)
[17:12] <mpt> xnox, no, the paragraph isn't about the live session
[17:13] <mpt> it's about installing Flash, MP3 codecs, etc on the installed system
[17:13] <xnox> mpt: which will not ever include nvidia drivers
[17:13] <mpt> xnox, how do you know?
[17:14] <xnox> mpt: nvidia drivers where previously comming from the jockey. In the future they will be offered/installed by ubuntu-drivers-common and/or software-centre based on modlines
[17:14] <mpt> xnox, I don't know what a modline is, so I don't know what that has to do with the installer.
[17:14]  * xnox modlines ?! well the hardware graphics card identifier line in packages,
[17:14] <mpt> xnox, by "the installer" I mean Ubiquity
[17:15] <xnox> mpt: Ubiquity currently does not install nvidia. There are no plans to make it do so.
[17:16] <xnox> mpt: nvidia graphics drivers require adding kernel modules and regenerating initramfs, which currently is not possible to do onto the target hard-drive.
[17:16] <mpt> So, I wonder why someone put it as a work item in the session
[17:16] <mpt> [albertomilone] ensure that installing nvidia/fglrx driver package also updates the alternatives symlinks and updates initramfs for the changed blacklists: DONE
[17:17] <mpt> I guess that means Alberto has done the impossible? :-)
[17:17] <xnox> mpt: http://paste.ubuntu.com/1047658/
[17:17] <xnox> mpt: 'installing' != 'ubiquity', installing as in on the machine, not during the installation.
[17:18] <mpt> I see
[17:20] <mpt> Well, that's annoying.
[17:20] <xnox> mpt: the paste lists depends & the packages, which I think are dynamically downloaded and installed from the internetz
[17:21] <xnox> mpt: yes it is annoying. That even if you choose to install updates & restricted stuff during the installation, you still will have to install stuff on the first reboot.
[17:21] <xnox> mpt: but there is little we can currently do about it. Maybe in two-three releases something will change and we will be able to fix that.
[17:21] <mpt> Heh, true, but I meant annoying only for me. :-)
[17:22] <xnox> Oh, I see =))) workitems =))))
[17:23] <xnox> mpt: the text you did for ubiquity is fine. Another text maybe needed for the ubuntu-drivers-common, not sure.
[17:23] <mpt> xnox, it's not fine if it says it might install graphics drivers when it never does.
[17:23]  * xnox hides
[17:29] <mpt> Sorry, didn't mean that to sound anvil-droppy. :-)
[17:32] <xnox> mpt: this got me thinking about this a bit. there is a support to run a post-first-boot-script which we can tell to install the package.
[17:32] <xnox> and if we detected which nvidia drivers to install
[17:32] <xnox> we can make it install automatically without user intervention
[17:32] <xnox> (and pre-download the package during the installation and stick it into (target)/var/cache/apt/archives)
[17:33] <xnox> mpt: this will result in (1) install (2) reboot (3) notification - your system needs a restart to complete upgrades
[17:33] <xnox> =/
[17:35] <mpt> heh
[17:35] <mpt> I guess pitti will tell us tomorrow
[17:35] <mpt> thanks xnox
[17:44] <slangasek> kenvandine: ping re: bug #754562
[17:44] <kenvandine> slangasek, pong
[17:44] <barry> xnox, kenvandine: i don't think it's quite as easy to adjust the packaging to include py3 support in libpeas.  first, it doesn't package up a separate python loader, so you can't just add a python3-foo package.  you end up with /usr/lib/libpeas-1.0/loaders/libpythonloader.so.  so i guess you could just do a second build of just the py3 loader and name it libpython3loader.so and include it in the libpeas-1.0-0 package (w/corresponding
[17:44] <barry> changes for the debug version).
[17:45] <barry> xnox, kenvandine of course it's also cdbs, so ouch :/
[17:45] <barry> xnox, kenvandine or maybe we should just do a binary package split of the python2 and python3 loaders
[17:46] <kenvandine> barry, i think that makes sense
[17:46] <barry> xnox, kenvandine since i don't use libpeas, i don't know what the right thing to do is.  suggestions welcome
[17:46] <kenvandine> i've never used it before... so not much help there
[17:47] <xnox> barry: i don't use libpeas, I use apps that use libpeas. Have you talked to upstream on GIMPNet as to what the best way to support both?
[17:47] <slangasek> kenvandine: hi, can you fill out the bug description with the information required per https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ?  The bug history is very fuzzy, we need authoritative information about what is being fixed here and why.  The bug history shows pitti saying the code isn't even in lo-menubar past natty.
[17:47] <kenvandine> slangasek, i can try... it is a bit fuzzy to me too
[17:47] <kenvandine> it has been merged into upstream LO
[17:47] <kenvandine> but never enabled
[17:48] <kenvandine> the changes in this version is actually from upstream LO
[17:48] <barry> xnox: i haven't.  upstream may not be the most appropriate place though since as far as upstream's concerned, they support py3.  i think it's more a packaging issue, so i think i'll contact the debian maintainer (pkg-gnome-maintainers) and cc debian-python
[17:48] <xnox> barry: two thumbs up
[17:49] <kenvandine> slangasek, as best we can tell the only real fix included in this version is for this bug... the rest was refactoring for upstream
[17:49] <kenvandine> s/upstream/LO
[17:49] <kenvandine> slangasek, however upstream for lo-menubar tried to backport just the fix for this bug and gave up... said it would be just as big of a change and more work than it was worth
[17:50] <slangasek> kenvandine: ok.  when updating the bug, can you include that information, and also comment on why it's safe to take the refactoring changes instead of doing that backport?
[17:50] <kenvandine> sure
[17:52] <slangasek> ta
[17:53] <slangasek> kenvandine: fwiw I've just done a naive test; I can't crash lowriter on amd64 with a page preview, when lo-menubar is installed
[17:54] <slangasek> so the test case definitely needs to cover how to reproduce the original bug...
[17:54] <kenvandine> slangasek, did you click the one on the toolbar?
[17:55] <slangasek> kenvandine: no, but I have now and still nothing
[17:55] <kenvandine> i think you have to do it first
[17:55] <kenvandine> before clicking it in the menu
[17:55] <kenvandine> seb128, right ^^
[17:56] <slangasek> it was a fresh instance when I tested the toolbar
[17:56] <kenvandine> that's what i just wrote in the test case :)
[17:56] <kenvandine> humm
[18:01] <kenvandine> slangasek, i just reproduced it by clicking on page preview first thing
[18:01] <slangasek> on amd64?
[18:01] <kenvandine> hung for a couple seconds and boom
[18:01] <kenvandine> yes
[18:01] <slangasek> how did you launch LO?
[18:02] <kenvandine> move ~/.config/libreoffice out of the way
[18:02] <kenvandine> well
[18:02] <kenvandine> had you upgraded to the newer lo-menubar then downgraded?
[18:03] <kenvandine> for some reason downgrading doesn't work... it stores something for the extension in your profile
[18:03] <slangasek> oh hah, I can't reproduce it because I'm on quantal \o/
[18:03] <kenvandine> ah!
[18:03] <slangasek> ok, so ignore me ;P
[18:04] <kenvandine> there is a problem with downgrading though... i think LO doesn't something evil there
[18:04] <kenvandine> if you downgrade it'll continue to use the newer version
[18:04] <kenvandine> ah... we only have one mterry again.. sounds less productive
[18:05] <mterry> kenvandine, :)
[18:09] <kenvandine> slangasek, bug description updated
[18:10] <slangasek> kenvandine: cheers :)
[18:11] <kenvandine> slangasek, thank you!  this is really our best hope of getting this bug fixed in 12.04 :/
[18:11] <slangasek> understood
[18:25] <slangasek> dobey: your latest upload of ubuntu-sso-client has a hard build-dep on python-support which needs to be dropped
[18:26] <dobey> slangasek: doh, thanks.
[18:27] <slangasek> dobey: looks like there's also a new build-dependency on python-qt4reactor, which is not in main currently... is there a MIR bug open for this?
[18:27] <bdmurray> dobey: cany chance you could look at https://code.launchpad.net/~brian-murray/lptools/bug-dupe-props/+merge/108433
[18:32] <dobey> slangasek: double-doh.
[18:33] <dobey> bdmurray: as soon as i can. been swamped with releases and security fix drama
[18:34] <bdmurray> dobey: it'd be nice if more people than you could or were doing reviews for lptools
[18:35]  * xnox today I learned $ man grep-merges
[18:36] <dobey> bdmurray: like lifeless, jelmfer, or poolie? :)
[18:36] <bdmurray> dobey: or like ubuntu-core-dev
[18:40] <dobey> slangasek: there isn't a MIR; and I suppose there won't be one. So I guess I'll have to not run the tests during build :(
[18:44] <slangasek> dobey: why wouldn't there be an MIR?
[18:45] <slangasek> dobey: I mean, I think as the uploader of the package trying to pull it in, it's up to you to file the MIR bug... which I think you should do before deciding to skip running tests at build time
[18:45] <dobey> slangasek: qt4reactor is not well supported/maintained, and we don't want to take over for upstream on it
[18:46] <slangasek> ah
[18:46] <xnox> dobey: but you should at least use dh_python2 not python-support
[18:46] <slangasek> he knows :)
[18:46] <xnox> =)
[18:46]  * xnox sorry, dobey.
[18:46] <dobey> xnox: yes we already use dh_python2. :)
[18:46] <xnox>   o python-support: python-support
[18:46] <xnox>     [Reverse-Build-Depends: ubuntu-sso-client (MAIN)]
[18:47] <xnox> dobey: spurious build-dependency?
[18:47] <dobey> yes
[18:47] <xnox> =)
[18:47] <xnox> ok
[18:47]  * xnox read scroll back. Me has a facepalm embarrassment moment.
[18:48]  * xnox goes back to reading kindle
[18:48] <dobey> well, the | dep will remain, but the explicit will drop. also working on having the package buildable on all supported versions of ubuntu from a single source. :)
[18:52] <xnox> dobey: why? do you care about hardy?
[18:52] <xnox> oh wait, lucid as well
[18:52] <xnox> hmm
[18:56] <dobey> i don't care about hardy. it's EOL :)
[18:56] <slangasek> not yet it isn't
[18:56] <slangasek> well, the desktop is, so yeah
[18:57] <dobey> well, not for server it isn't.
[18:57] <dobey> but for what i care about, it is :)
[18:59]  * xnox adds google calendar reminder to drop python-support in april 2013 =)
[19:02] <dobey> slangasek: new ubuntu-sso-client uploaded. sorry i fumbled that, and thanks for pointing it out :)
[19:02] <slangasek> dobey: no worries - thanks for the fix :)
[19:03] <xnox> vibhav: meeting ping? =)
[19:12] <hallyn> stupid question perhaps - is 'fakeroot debian/rules clean; debian/rules build' supposed always trigger dh_auto_configure?
[19:13] <infinity> hallyn: If it's a new-skool dh-7-ish package, and doesn't override auto_configure, yes.
[19:13] <hallyn> infinity: well it does define override_auto_configure, but that's really what i meant :)
[19:13] <hallyn> thanks
[19:14] <hallyn> must be doing something else wrong
[19:14] <xnox> hallyn: `dh build --no-act` is your friend
[19:14] <xnox> similarly for clean target
[19:15] <hallyn> xnox: will try it, thanks
[19:15] <xnox> it lists all the targets and in what order they will be called. You may need --with addon bits as well
[19:16] <xnox> that way you can easily troubleshoot dh's behaviour.
[19:16] <xnox> hallyn much better than he CDBS dot graphs of thousands make targets
[19:28] <mattrae> hi, i can't seem to generate debug symbols packages for mysql-server using methods that work for other packages.. anybody able to confirm a way that works?
[19:28] <mattrae> here's some details on what i've tried: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-June/013677.html
[19:29] <mattrae> in the end i just need the debug symbols for a backtrace, so if there are manual steps i can take to apply patches and compile, thats fine too. i don't know enough about packaging yet to know what is safe
[19:32] <xnox> mattrae: i think it is a known problem that mysql-server is missing ddebs
[19:32] <xnox> there was a bug about it or something somewhere
[19:32] <xnox> mattrae: basically the buildsystem unconditionally strips them / builds without them.
[19:33] <xnox> mattrae: pretty sure that someone took an action item on it, as it was picked for the blueprint that ddebs should be generated for every single version of the package, not just the current one
[19:33] <mattrae> xnox: great, yeah maybe i can find that blueprint
[19:35] <mattrae> xnox: would it be simple enough to manually apply patches and compile? just so i can get this backtrace
[19:36] <xnox> mattrae: i don't know.
[19:37] <mattrae> xnox: hmm, i'll see what i can figure out.. thanks for for the information
[19:58] <bdmurray> stgraber: I'm looking at removing the bug pattern for bug 989585.  There is no way to encounter this anymore right?
[19:59] <stgraber> bdmurray: starting with quantal, no. That was just an issue on precise, fixed by an SRU.
[20:00] <xnox> bdmurray: if SRU is installed...
[20:02] <bdmurray> okay so the pattern could be modified to specify version 1.63ubuntu11 of the package
[20:07] <dobey> bdmurray: reviewed your lptools branch. thanks. sorry it took a while.
[20:08] <bdmurray> dobey: thanks
[20:13]  * xnox is core-dev!!!! Whooo-ho =)
[20:13] <dobey> barry: http://pastebin.ubuntu.com/1047991/ <- too bad that's pretty much all it does right now :P
[20:13] <infinity> xnox: That was quick.
[20:14] <infinity> xnox: Please don't break my computer.  Thanks.
[20:14] <xnox> infinity: blame "tumbleweed> +1 [[ it's a faily early core-dev application, but warranted ]]"
[20:14] <xnox> infinity: I'll try, but I can't promise you anything beyond the secrets of the universe.
[20:15] <infinity> xnox: Breaking things is my job.  If you start doing it, I become redundant.  Just sayin'.
[20:15] <xnox> infinity: it *only* took ~5 years
[20:16]  * xnox wonders what my first upload should be
[20:17] <dobey> xnox: it's no fun if it's not linux :P
[20:17] <stgraber> xnox: a broken eglibc is usually a good one if you want to see how quickly we can revoke your upload rights ;)
[20:17] <infinity> stgraber: *glare*
[20:17] <stgraber> dobey: nah, linux is way to easy to work around, grub lets you boot an older kernel, libc is way more fun :)
[20:17]  * xnox was more thinking partman-base with a date check to really screw up an RC iso ;-)
[20:18] <dobey> stgraber: well, you can also upload grub to fix that :P
[20:18]  * infinity wonders if perhaps this core-dev acceptance was a bit too hasty.
[20:18] <infinity> xnox: I'd recommend your first upload be something not broken. :P
[20:18]  * xnox where is my stash of 100 .changes files
[20:19] <xnox> infinity: to be honest I was thinking to finish boost1.49 transition
[20:19] <infinity> xnox: Oh, is it still not done?
[20:19] <xnox> infinity: nope =)
[20:19] <maco> stgraber: you're making me think of a few instances of ubuntu-devel-announce@ that said "DON'T UPGRADE!"
[20:19] <xnox> infinity: I was waiting for upload rights to stop pestering you about it.
[20:19] <infinity> xnox: Slacker.
[20:20]  * xnox =(
[20:20] <maco> and that time a classmate walked in and said "i hope you didnt upgrade today" and i said "no i saw the email in time.... but im guessing you didnt, by that face" "yeah...i had to reinstall"
[20:20] <xnox> I loved the one which complete made your hardware explode, e.g. graphics or network card or something
[20:20] <infinity> xnox: I think you just volunteered to to an aptitude merge.
[20:20] <maco> i think that was hardy... compile flags were changed and everything was ok for about 2 weeks and then libc6....kersplode
[20:20] <xnox> which like completely destroyed hardware rendering it a brick
[20:21] <maco> xnox: the bad intel firmware for the e500 network card?
[20:21] <xnox> infinity: I'm waiting for cjwatson to do it =)
[20:21] <xnox> maco: yeah that one. I was freaked out cause I had a similar but not affected one.
[20:22] <ahasenack> hi, can someone please target this bug for lucid, natty, oneiric and precise? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1004678
[20:22] <ahasenack> O
[20:22] <ahasenack> I'm going to prepare an SRU for those
[20:23] <stgraber> maco: :)
[20:23] <infinity> ahasenack: Sure.
[20:23] <ahasenack> infinity: thanks a lot
[20:27] <tumbleweed> xnox: we offer a 30 day money-back guarantee on your core-dev application, if you break everything
[20:28] <xnox> tumbleweed: fix the web link on your core-dev application, then we'll talk ;-)
[20:28] <tumbleweed> :)
[20:29]  * xnox started the trend with table based applications
[20:29] <xnox> tumbleweed: should that be added to the template?
[20:29] <tumbleweed> naah, but your one was prettier
[20:30] <tumbleweed> the sponsorship miner does table generation
[20:33] <xnox> stgraber: am I ok to forward your LXC reply to ubuntu-distributed-developer mailing list?
[20:33] <stgraber> xnox: sure
[20:35] <xnox> tumbleweed: what sponsorship miner?
[20:36] <tumbleweed> xnox: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
[20:37] <xnox> tumbleweed: it's so slowwwwwww
[20:37] <tumbleweed> blame the ancient samosa.d.o
[20:37] <xnox> tumbleweed: and no syncs, but that's a known bug
[20:38]  * tumbleweed should actually host that on ubuntuwire, now that we have UDD there
[20:38] <xnox> tumbleweed: I think my table css should be added to the template css for inside the page tables
[20:38] <xnox> tumbleweed: I stole it from the Releases page ;-)
[20:39] <tumbleweed> it'll have recent synsc (since lp started recording the sponsor)
[20:43] <xnox> fair enough
[20:43] <cnd> ginn is seeded in ubuntu's desktop image, but we don't plan to support it in quantal and future
[20:43] <cnd> I want to remove it from the desktop seed
[20:44] <xnox> tumbleweed: ## [[CategoryCoreDevApplication]] where you mean to uncomment this?
[20:44] <cnd> is there a process I need to follow, or do I just edit the seed directly?
[20:45] <tumbleweed> xnox: your attention to detail is impressive :)
[20:45] <xnox> tumbleweed: don't thank me, thank OCD
[20:45] <infinity> cnd: If there's some concensus in your team that dropping it is the right thing to do, just edit the seeds and commit.
[20:45] <cnd> infinity, ok, thanks
[20:46] <infinity> cnd: And if you want it gone RIGHT NOW, update ubuntu-meta afterward.  Otherwise, someone will pick it up when they refresh meta later.
[20:46] <cnd> infinity, it can wait
[20:46] <ahasenack> hi, I see that oneiric has had a landscape-client sru already (12.04.3-0ubuntu0.11.10 in oneiric-updates), but the branch lp:ubuntu/oneiric-updates/landscape-client doesn't seem to exist
[20:47] <ahasenack> do I have a typo, or was the update not imported into udd?
[20:47] <infinity> cnd: Note that it's in the edubuntu seeds as well as the ubuntu ones.
[20:47] <infinity> stgraber: ^
[20:47] <cnd> infinity, I'll remove it from there too, but how did you figure that out?
[20:47] <cnd> do you have all the seeds on your computer?
[20:47] <cnd> or is there some tool?
[20:47] <infinity> cnd: apt-cache show ginn.
[20:48] <infinity> cnd: But I do have them all checked out as well.
[20:48] <cnd> infinity, from the Task field?
[20:48] <infinity> cnd: Yeah.
[20:48] <cnd> ok
[20:48] <cnd> thanks
[20:48] <infinity> cnd: There's also "seeded-in-ubuntu" in ubuntu-dev-tools.
[20:49] <infinity> cnd: "seeded-in-ubuntu ginn"
[20:49] <cnd> ahh
[20:50] <stgraber> infinity, cnd: edubuntu-desktop depends on ubuntu-desktop, so that's how it ends up being seeded by edubuntu too. I'm fine with dropping it.
[20:51] <cnd> stgraber, I was just about to ask about that
[20:51] <infinity> stgraber: Ahh, I've never looked at edubuntu's STRUCTURE.
[20:51] <cnd> since I didn't see ginn in the edubuntu seed :)
[20:51] <cnd> infinity, thanks for the help, I think everything is good now :)
[20:52] <cnd> infinity, though this does beg the question: will ginn be automatically demoted from main to universe?
[20:52] <infinity> cnd: Once meta is refreshed, yes.
[20:52] <cnd> ok
[20:52] <cnd> cool
[20:53] <infinity> cnd: If you want it in main, add it to supported.
[20:53] <cnd> nope, we don't want to support it anymore :)
[20:53] <infinity> Check.
[20:53] <infinity> Then yes, it'll automagically drop out once nothing in main depends on it.
[20:53] <infinity> (Which is just ubuntu-desktop)
[20:56] <ScottK> xnox: Congratulations.
[21:00] <xnox> ScottK: thanks a lot
[21:02] <xnox> ScottK: at the meeting we mostly discussed cookies & food transfer protocols and then did a vote
[21:02] <ScottK> yes.  I saw it in my scrollback.
[21:02] <ScottK> Meetings like those as a good sign you were ready to apply.
[21:03] <broder> xnox: yeah, +1 - congrats :)
[21:07]  * xnox OMG my team memberships exploaded. So this is how almost everyone has 50 shades of Xubuntu logo on their homepage
[21:07] <xnox> broder: thanks
[21:16] <xnox> infinity: thanks for ~debiandevelopers approval
[21:17] <malkauns> how do i change the titlebar text vertical offset?
[21:17] <infinity> xnox: Yeah, I really need to clean that up some time.  I only add people who I can easily verify, I think I need to some sort of challenge/response email with the people I don't know and get them to sign the response with their Debian keys or something.
[21:17] <infinity> xnox: Y'know, when I find some mythical "spare time".
[21:17] <tumbleweed> how about just checking if they have a debian-keyring key in their profile?
[21:18] <infinity> tumbleweed: You can upload any old public key to your launchpad profile.
[21:18] <xnox> infinity: I'd think @debian.org on launchpad page is enough, since they had to verify launchpad's challenge response email
[21:18] <infinity> tumbleweed: (If I could verify what key they signed the CoC with, that would work)
[21:18] <tumbleweed> oh, I thought it made you verify it
[21:18] <infinity> tumbleweed: Oh, if it does, that helps.  I haven't changed my key in LP since 2005. :P
[21:18] <xnox> infinity: gpg key upload has challenge response.
[21:19] <xnox> on launchpad that is
[21:19] <infinity> xnox: Kay, good to know.  That'll help me automate probably about half the list.
[21:19] <xnox> infinity: the trickier bit is removing MIA / alumni
[21:20] <infinity> xnox: Well, it's not like the group grants you anything useful.  I just want it to be vaguely accurate and not hand out swirls willy nilly.
[21:20] <xnox> infinity: =)))) the swirls willy nilly master
[21:20] <xnox> infinity: lp-api to the rescue =) for automation
[21:20] <infinity> (It should actually be bottles and swirls, but man, that's hard to represent in a tiny icon)
[21:21] <infinity> The swirl looks bad enough as it is at that size.
[21:21] <xnox> infinity: you and your urges to get everyone drunk.....
[21:21]  * xnox kidding
[21:45] <cjwatson> xnox: oh, well done
[21:48] <xnox> cjwatson: thanks =)
[21:53]  * Laney spots some controversial core-dev apps on the horizon ...
[21:54] <xnox> Laney: don't forget to vote for yourself ;-)
[21:54] <slangasek> xnox: congrats :)
[21:54] <slangasek> Laney: oh?  how's that?
[21:54] <xnox> slangasek: thank you
[21:54] <Laney> slangasek: these "Laney" and "tumbleweed" characters are on the list
[21:54] <slangasek> oh, your own, I see :)
[21:55] <xnox> slangasek: my "quick" (only 5 years) core-dev application triggered Laney & tumbleweed to apply
[21:55]  * slangasek grins
[21:55] <Laney> I heard they were the shady sort
[21:55] <xnox> Laney: 5 years or Laney&tumbleweed's applications
[21:56] <broder> you guys finally are applying!
[21:57] <ajmitch> Laney: can't trust them, I heard
[21:58] <infinity> Laney: The team's full, we'll have to kick out ajmitch to make room for you.
[21:58] <ajmitch> wouldn't surprise me if they did :P
[21:59] <Laney> then who would I trick into doing last minute high risk uploads?
[22:00]  * xnox winks
[22:00] <ajmitch> I think xnox just volunteered?
[22:00] <cjwatson> Oh, I usually go for infinity for that
[22:01] <infinity> I do that all by myself without prompting!
[22:01]  * micahg seems to end up with some of those as well on occastion
[22:02] <infinity> micahg: Yeah, but mine work.
[22:02] <micahg> infinity: good point :)
[22:03]  * infinity runs away to find "lunch" before micahg hunts him down.
[22:03]  * ajmitch should quietly hide from micahg also
[22:04]  * xnox is off to try the UDD way of committing to branch to find out why core-devs complain about it so much. I can't possibly break package import more than it already is, right?
[22:04] <jono> slangasek, hey
[22:04] <jono> slangasek, do you have time for a quick G+ call?
[22:05] <micahg> xnox: yes, you can :)
[22:05]  * micahg thinks casper was the example of that
[22:06] <xnox> also I'm sure infinity told me I get cookies after becoming a core-dev =)
[22:06] <slangasek> jono: sure
[22:06] <jono> thanks slangasek, I will set it up
[22:07] <jono> slangasek, https://plus.google.com/hangouts/_/13aeff6fdafa4ec1dbc1f373306e10f0df4f8a3b?authuser=0&hl=en-US
[22:28]  * SpamapS starts a test build of PHP 5.4.4 for quantal
[22:29] <bkerensa> SpamapS: nice!
[22:29] <SpamapS> sans-suhosin unfortunately.. but still.. time to move forward
[22:29] <bkerensa> SpamapS: You know of any straightforward guides to debian chroot on Ubuntu?
[22:30] <SpamapS> bkerensa: mk-sbuild --architecture foo unstable
[22:30] <infinity> bkerensa: debootstrap --variant=buildd sid sid http://ftp.us.debian.org/debian
[22:30] <bkerensa> ahh
[22:30] <bkerensa> :D
[22:30] <infinity> Or his. :P
[22:30]  * SpamapS hugs mk-sbuild
[22:30] <bkerensa> SpamapS: you rock... I think thats command slangasek gave me a few months back (I need a notebook)
[22:31] <SpamapS> bkerensa: nah, you just need grep :) 574M    irclogs
[22:32] <SpamapS> I think aths like, 9 years of irc logs
[22:32] <infinity> Pfft.  IRC logs are for people whose hosts go down.  I just have unlimited backscroll.
[22:32] <SpamapS> aths .. very close to thats
[22:32] <SpamapS> infinity: uptime, the true measure of an admin's virility
[22:33] <infinity> SpamapS: And how.
[22:33] <infinity> Gather 'round the netcraft kids, let me tell you a story.
[22:33] <infinity> About the good old days, when Linux hosts appeared to always reboot at 437 days.
[22:33] <bkerensa> infinity: Can you search infinite backscroll?
[22:33] <bkerensa> =/
[22:34] <infinity> Err, 497.
[22:34] <infinity> It's been a while.
[22:34] <SpamapS> infinity: and then redhat begat day 438, and then day 1007 begat local kernel exploits, and all was rooted, ahhhhhhmmmeeeenn
[23:07] <bkerensa> SpamapS: E: You must put some 'source' URIs in your sources.list
[23:08] <bkerensa> why would it not put some in itself?
[23:10] <maxb> Why would building a chroot require source?
[23:12] <bkerensa> maxb: this is when I try and apt-get build-dep packagename
[23:13] <maxb> well, do what the error tells you to, then
[23:13] <micahg> bkerensa: yes, you need a source entry to know which build deps to use (or use mk-build-deps -i -r in a debian source dir)
[23:18] <bkerensa> micahg: well the sources.list inside the chroot already have a source entry defined
[23:21] <bkerensa> micahg: my fail for not apt-get update