[01:46] <ScottK> infinity: Should probably drop the GLES stuff that's different from Debian too.  More stuff would build.
[01:55] <infinity> ScottK: We're not dropping it for armhf, so we may as well make it work for both.
[01:55] <infinity> ScottK: I'm not sure "having stuff build but be really slow because it uses software rendering" is a net win for anyone except people who like FTBFS counts low.
[01:56] <ScottK> Most of the stuff that doesn't build now can't realistically be made to do so.
[01:57] <ScottK> (with GLES)
[01:57] <infinity> Where there's a will, there's a way.  Maybe you can talk Linaro into it. ;)
[01:57] <infinity> (Still, I think my "it builds, but it's useless" point stands)
[01:59] <ScottK> Could be.
[02:08]  * DebolazW makes another brave attempt at getting indicator-messages to install.
[04:36] <pitti> Good morning
[04:36] <ajmitch> morning pitti
[04:36] <pitti> apw: oh, _this_; yes, this looks wrong, I'll have a look whehre it takes the data from
[04:37] <pitti> hey ajmitch, how are you?
[04:37] <ajmitch> I'm good, how are you? :)
[04:37] <pitti> quite fine, thanks!
[04:37] <DebolazW> Moin.
[04:38]  * ajmitch is looking forward to UDS again, except for the flights :)
[04:38]  * DebolazW made his indicator-messages work like he wanted to. :)
[04:39] <mwhudson> pff, it's only about 12 hours to the left coast
[04:39] <ajmitch> mwhudson: still long enough to be a bit annoying
[04:47] <pitti> apw: indeed, it takes the mtime of /var/log/dist-upgrade/main.log
[04:47] <pitti> apw: so if you use apt-get instead of update-manager, that won't be seen
[06:23] <DebolazW> Hmm, I want to publish an alternate version of an ubuntu package through a ppa. Should the version number of the package be bumped, or kept as is?
[06:24] <pitti> DebolazW: bump it, so that people can actually tell which version they have
[06:25] <micahg> DebolazW: usually done with +foo (to give some hint of what you're adding), also, this will be superseded by almost any upload which reminds you to rebase against the new version
[06:25] <DebolazW> So if the version is 0.6.0, I should make it 0.6.0+myfeature ?
[06:26] <micahg> yep, then if you need to rebuild or modify yours, you can do 0.60+myfeature1 and such
[06:26] <micahg> DebolazW: oops, not quite right
[06:27] <micahg> that would be if it's 0.6.0 in ubuntu itself as opposed to 0.6.0-0ubuntu1 or similar
[06:28] <DebolazW> The whole package is: indicator-messages_0.6.0-0ubuntu1
[06:28] <micahg> yeah, so you want 0.6.0-0ubuntu1+myfeature (#ubuntu-packaging is good for questions like this in the future)
[06:28] <DebolazW> Noted.
[06:29]  * DebolazW is finally getting around to fixing the one thing he finds incredibly annoying about Unity, the lack of good notifications of messages.
[06:30] <micahg> DebolazW: I assume you've tried upstreaming the feature?
[06:31] <micahg> that's a decent candidate for a backport if you get it into quantal
[06:31] <DebolazW> That's going to be step 2. Step 1 is making something useful I can take advantage of on my own systems (And anyone who might need it)
[06:31] <micahg> sounds good and good luck!
[06:32] <DebolazW> The current message indicator behavior seems like a deliberate design choice though, so I don't think my changes will be accepted just like that.
[06:33] <DebolazW> So this is mostly to cater for my own needs, with the added benefit of helping anyone who might want the change (Including upstream)
[06:33] <micahg> well, it might be worth having a conversation first, that might possibly allow creating something fitting the design decisions and your needs as well
[06:45] <dholbach> good morning
[07:31] <apw> pitti, ahh so they likely upgraded to precise using update manager, then changed sources and dist-upgrade'd and now we have mixed messages... makes sense
[07:31] <pitti> apw: indeed
[07:32] <apw> pitti, thanks for looking into it, at least we know how
[07:58] <xnox> Good Morning! =)
[08:28] <diwic> pitti, don't know if you have a terrible amount of critical bugs on your hands right now, if not, feel free to fix bug 993810
[08:31] <pitti> diwic: marked as dupe of bug 359810, thanks!
[08:32] <diwic> pitti, hmm, that sounds terribly old. This must have been fixed and then regressed?
[08:32] <pitti> no, it never worked
[08:32] <pitti> apport-collect (or apport in general) has never really been designed to work with source packages
[08:33] <pitti> users see binary packages mostly, and we cannot actually collect a lot of info about source packages
[08:35]  * diwic boots into oneiric to check
[08:39] <diwic> pitti, in oneiric, I get the message "No packages found matching alsa-driver.", but no stack trace, and relevant information is correctly attached.
[08:39] <diwic> pitti, from what I can tell, it's an oneiric -> precise regression.
[08:40] <pitti> ah, I see; so in oneiric it would not really collect any alsa-driver info either, as that package does not exist; but indeed it should not segfault
[08:40]  * pitti undupes then
[08:40] <pitti> diwic: I'll look at it, thanks!
[08:40] <diwic> pitti, it does collect the relevant info and attaches it to the bug report correctly.
[08:41] <pitti> I guess it can collect the parts from /usr/share/apport/package-hooks/source_alsa-driver.py
[08:41] <pitti> which are presumably the most interesting for you
[08:41] <pitti> it should not be able to determine the package version, modified files, etc.
[08:42] <diwic> pitti, hmm, you might be correct in that, e g, it seems like "Dependencies" are not collected
[08:42] <pitti> so that part is #359810
[08:42] <tjaalton> uh, nice when an early dependency fails to install and then apport files dozens of bugs against the xorg packages :P
[08:49]  * smb is a bit unhappy with his printing results...
[09:39] <doko_> infinity, how did your eglibc build did end up?
[10:27] <doko> pitti, does pygobject assume that _ctypes is built as an extension?
[10:31] <pitti> doko: no, not as such -- it does not link to it or anything
[10:31] <pitti> git grep ctypes -> empty
[10:31] <pitti> it uses libffi
[10:31] <pitti> well, libgirepository uses libffi, pygobject uses libgirepository
[10:32] <pitti> I'm still looking for a variation of the Setup.local file to make it work
[10:32] <pitti> but haven't found one so far
[10:33] <pitti> this bug drives me mad, I spent half a week on this thingy; at least I'm happy that I finally found the one line which triggers it, but it's still unclear why it segfaults
[10:33] <pitti> it tries to call the generated C wrapper for the python callback and SIGILLs
[10:34] <pitti> what that has to do with the ctypes module is beyond me; the only connection that I see is that both gi and ctypes use libffi
[10:34] <pitti> so perhaps something goes wrong with the linking
[10:34] <doko> pitti, I see that the python binary is statically linked against libffi
[10:34] <doko> so you end up with two copies of libffi
[10:34] <pitti> right, and ssl, etc.
[10:35] <pitti> my local build doesn't link against libffi
[10:35] <doko> no, ssl is not statically linked
[10:35] <pitti> ldd /usr/bin/python3.2 -> libssl and libffi
[10:35] <pitti> perhaps we have a different idea about "static"
[10:36] <pitti> i. e. it's linked dynamically, but the ctypes module is built into the python binary in our packages apparently
[10:36] <pitti> and it works as soon as I change "extension" to "builtin" to make it a separate ctypes.so extension
[10:36] <pitti> (that sounds backwards, isn't it?)
[10:36] <doko> #_ctypes _ctypes/_ctypes.c _ctypes/callbacks.c _ctypes/callproc.c _ctypes/stgdict.c _ctypes/cfield.c _ctypes/malloc_closure.c -Wl,-Bstatic -lffi -Wl,-Bdynamic
[10:37] <pitti> want me to try that?
[10:37] <doko> no, that's from debian/patches/setup-modules.diff
[10:37] <pitti> oh, that's not in Setup.local then
[10:38] <pitti> doko: I don't apply patches in my upstream build
[10:38] <pitti> anyway, playing with that in my "minimal diff from upstream" tree
[10:39] <pitti> fg
[10:39] <pitti> doko: so, just -lffi or wrapping that in -Bstatic doesn't make a difference
[10:41] <pitti> it works (ldd python proves it), but crashes either way
[10:44] <pitti> doko: is it generally bad to have a library both statically linked as well as dynamically opened in the same process, or is that specific to libffi?
[10:45] <doko> pitti, it's bad. I'll look at it, but for now, I can't see the static linkage from the build log
[10:58] <pitti> doko: ah, /usr/bin/python2.7 does not link to libffi, seems python 2.7 ships ctypes as a module
[10:58] <pitti> /usr/lib/python2.7/lib-dynload/_ctypes.so
[10:59] <doko> right
[11:12] <doko> pitti, I think we can build it as an extension again. however it would be nice to know if the issue comes up again if you load both the _ctypes and gobject extensions
[11:53] <dupondje> cjwatson: MoM on its summer vacation?
[11:53] <cjwatson> dupondje: hardware problems, as I said on -devel
[11:53] <cjwatson> it's being looked at but it's UDS season which keeps sysadmins busys
[11:53] <cjwatson> *busy
[11:53] <pitti> re
[11:54] <pitti> doko: I'm testing that now
[11:54] <dupondje> ah ok :)
[11:54] <dupondje> no problem! :)
[11:54] <dupondje> If you need an additional sysadmin ... ;)
[11:56] <cjwatson> I guess the employment page is --> that way
[11:58] <pitti> doko: I can import both gi.repository and ctypes, and both work
[11:58]  * pitti sends that to the bug repor
[11:58] <dupondje> Office based - London UK ... to far :)
[11:58] <doko> pitti: uploaded to -proposed
[12:00] <pitti> doko: oh, wow, thanks!
[12:00] <pitti> doko: I noticed that this drops some symbols, at least with my quick and native approach; could that cause some abi breakage somewhere?
[12:04] <doko> pitti: no, I don't think so. that should only be symbols from libffi
[12:22] <mdeslaur> so...what's everyone using instead of MoM for now?
[12:22] <mdeslaur> also, unstable or testing?
[12:24] <pitti> mdeslaur: http://people.ubuntuwire.com/~lucas/merges.html
[12:25] <pitti> the only thing I really need is a list of packages I need to merge
[12:25] <mdeslaur> pitti: ah! cool, thanks
[12:25] <Laney> we only just fixed that to show quantal. may take a couple of hours to reflect current reality.
[12:25] <lucas> I'm surprised this still works, but cool
[12:25] <pitti> yes, apparently it does
[12:59] <pitti> doko: https://launchpadlibrarian.net/104064419/buildlog_ubuntu-precise-amd64.python3.2_3.2.3-0ubuntu2_FAILEDTOBUILD.txt.gz > that was my question about the abi break -- libpython would not have the PyC* stuff any more with an external module
[12:59] <amourphious> Can you please tell me from where can i get code for keyboard layout settings in Ubuntu
[12:59] <pitti> doko: but there are not too many rdepends of libpython3.2, I'm happy to test them
[13:00] <dobey> amourphious: xkeyboard-config
[13:01] <amourphious> dobey: can you tell me the repo to be cloned
[13:02] <dobey> amourphious: if you want upstream it's probably on freedesktop.org somewhere
[13:03] <cjwatson> amourphious: git://git.freedesktop.org/git/xkeyboard-config
[13:05] <amourphious> cjwatson: thanx
[13:05] <amourphious> dobey: thx
[13:11] <amourphious> cjwatson: well the repo i just got consist of geometry symbol and other things while i need code for generating layouts as it is done in system settings
[13:15] <cjwatson> amourphious: -> dobey, all I was doing was giving you the git URL, I don't know the layout of desktop code here
[13:18] <amourphious> dobey:  i need code for generating layouts as it is done in system settings any idea from where can i get it
[13:20] <dobey> read the code for whatever does that
[13:20] <dobey> i don't know where it is exactly
[13:21] <amourphious> dobey:not even about system settings code
[13:23] <dobey> the upstream for the control center is gnome-control-center
[13:23] <dobey> perhaps you should be asking these questions in #gnome on gimpnet irc instead
[13:33] <xnox> how do I tell `dpkg-source' to consider that I'm on 'debian' and not on ubuntu?
[13:34] <tumbleweed> xnox: DEB_VENDOR=Debian
[13:34] <xnox> tumbleweed: thanks.
[13:41] <doko> pitti, ahh, ok. I'll mark these as optional
[13:41] <pitti> doko: if you do a new upload, can you please build the source with -v3.2.3-0ubuntu1 to include the previous changelog?
[13:41] <doko> sure
[13:48] <angeloc> hi guys, can anyone help me with bug 993867?
[13:49] <angeloc> I already filed a merge proposal and looking for sponsorship
[13:49] <xnox> ev: ^
[13:50] <xnox> angeloc: ev is patch piloting right now ;-)
[13:50] <ev> whoops!
[13:50]  * xnox your welcome!
[13:50] <Laney> angeloc: You've done everything you need to (at least for now). As it is on http://reports.qa.ubuntu.com/reports/sponsoring/ somebody will get to it soon :-)
[13:50] <ev> I'm not supposed to be :)
[13:50] <ev> @pilot out
[13:50] <ev> I'd love to help, but I'm massively swamped today
[13:50] <xnox> ev: how long have you been "piloting" =)
[13:51] <ev> xnox: about a week, apparently :)
[13:51] <xnox> way to go at boosting your stats ;-)
[13:52] <angeloc> ev: wow, is that list is filed in realtime when a user submits a branch? Cool!
[13:52] <xnox> angeloc: +/- real time =)
[13:52] <angeloc> ev: realtime, I filed the bug this morning!
[13:53] <xnox> ubottu: please ping pilots every hour when they are "piloting"
[13:53]  * xnox =(
[13:53] <DebolazW> Hmm, I have implemented blinking behavior in indicator-messages, but if I wanted to make this mechanism configurable, what would be the appropriate way of letting the user set the configuration? gconf?
[13:54] <angeloc> ev:it's very interesting to know that your contribution is in queue and you will have a slot in the feature!
[13:54] <angeloc> ev: for some projects i had to ping massively some developers ...
[13:58] <dholbach> Ubuntu Development session (at Ubuntu Open Week) starting in 2 minutes in #ubuntu-classroom
[13:58] <stgraber> xnox: sponsored your nagios-nrpe merge (with one minor additional change), I'll take care of sruing the fix to all releases
[13:58] <xnox> DebolazW: see topic. I think #ubuntu-app-devel people might help you more.
[13:59] <xnox> stgraber: =) thanks ;-)
[13:59] <DebolazW> Well, I already saw the topic and felt that it wasn't an obvious app question and hence something that could be asked here, but thanks.
[14:02] <xnox> stgraber: thanks. I didn't check diff against --old debian branch. As long as it is useless diff ;-) anyway our delta should go to debian anyway & get the package in sync.
[14:02]  * xnox notes down to check all possible debdiffs.
[14:04] <stgraber> xnox: yeah, that xxx file was introduced by a merge done by doko a while ago (or so bzr blame told me ;)). With the hardening changes in Debian I'm not sure how much of that delta is still relevant, and any still relevant part indeed should make it to Debian so we can just sync it.
[14:05] <xnox> stgraber: we need to fix all stable releases anyway ;-)
[14:06] <stgraber> xnox: yeah, doing that now, should just take a few minutes to get the SRUs pushed, the diff is simple to re-apply
[14:07] <xnox> stgraber: I can help testing
[14:07]  * xnox still should have access to a few nagios/nrpe monitoring sites on various releases
[14:07] <stgraber> xnox: cool, that'll be useful. I think at this time I only have hardy, lucid and precise on my network that I can help testing with
[14:07] <xnox> although not sure we need to do any testing apart from service restart ;-)
[14:08] <stgraber> installing the package should be enough as it'll restart the service
[14:17] <xnox> http://people.ubuntuwire.com/~lucas/merges.html updated itself with more recent data now
[14:41] <ogra_> infinity, do you remember what model your ac100 was ?
[14:41]  * ogra_ sees weird hangs on one device here but has no issues on the other ... 
[14:46] <stgraber> cjohnston: I noticed Edubuntu was a bit of a mess on the summit site because we had duplicate blueprints. I now untargeted them for UDS and marked them superseded by the one we really want a session for. Is that enough or does it require manual removing too?
[14:47] <cjwatson> jamespage: hm, I fakesynced your jenkins-commons-jelly upload from Debian as it came up in the auto-sync run, but it failed with a Maven artifact resolution error: https://launchpadlibrarian.net/104075490/buildlog_ubuntu-quantal-i386.jenkins-commons-jelly_1.1-jenkins-20110627-2fakesync1_FAILEDTOBUILD.txt.gz
[14:47] <cjwatson> I know you love those
[14:48] <jamespage> cjwatson, yeah - I saw - I need to fixup tomcat6 to make that work again - doing so at the moment - however the bzr branch is out of date for ubuntu....
[14:48] <cjohnston> stgraber: manual... can you send me the links to the ones that need to be deleted please
[14:49] <stgraber> cjohnston: sure, I actually spotted some more, I'll pm you the list
[14:49] <cjohnston> ty
[14:49] <cjwatson> jamespage: fun
[15:01] <doko> pitti, python3.2 reuploaded, sorry for the delay
[15:09] <pitti> doko: thanks; still waiting for the diff, will accept then
[15:12] <doko> pitti: and please accept gnat-4.6 for -proposed as well (bug 994045)
[15:13] <pitti> *nod
[15:49] <infinity> doko: Ended up the same as the buildd build, which isn't shocking.  But I'm vaguely stumped as to why.
[15:50] <infinity> ogra_: My ac100 is a 10Z
[15:50] <ogra_> infinity, mind to try the binary driver from my p.c.c dir ?
[15:51] <infinity> ogra_: In a bit, sure.  Still waiting for the caffeine to kick in this morning. ;)
[15:51] <ogra_> heh, yeah, no hurry
[15:52] <ogra_> we're not sure if its a HW difference, an install difference or if the kernel is just outdated
[15:52] <ogra_> theoreticaly the driver should work
[15:52] <infinity> Theoretically?  I don't like where this is going. :P
[15:53] <ogra_> i have one system built on top of an ubuntu-core tarball ... running lubuntu ... thats the super crashy one
[15:53] <ogra_> another model with ubuntu-desktop installed from beta and upgraded to final runs relatively fine (also crashes but only after hours, not minutes)
[15:54] <ogra_> HW (CPU/GPU) wise there seems to be no difference on first sight
[15:57] <infinity> ogra_: Well, let me upgrade mine to final and then have a try.
[15:57] <ogra_> is yours a std install or as well manually built from scratch ?
[15:58] <ogra_> (i remember you did something like that in the past)
[15:59] <infinity> It's a normal install by now.  The from-scratch one is long gone.
[15:59] <ogra_> k
[16:01] <infinity> 566 packages to upgrade, though.  Might just be faster to re-image.
[16:01] <ogra_> heh
[16:02] <prodigy> hello can anyone help me with the brightness control
[16:02] <prodigy> on ubuntu 12.04
[16:03] <slangasek> cjohnston: hi, ev noticed that https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-metrics is accepted for uds-q but not showing up on the schedule - can you help me figure out what's going on there?
[16:03] <infinity> ogra_: Yeah, I think I'll just re-image the machine and get back to you. :P
[16:03] <ogra_> k, no hurry
[16:04] <ogra_> just testing (or trying to) a 3.1 kernel
[16:05] <ogra_> sqadly that seems to be built with CONFIG_COMMIT_SUICIDE enabled :/
[16:06] <ogra_> *sadly
[16:10] <cjohnston> slangasek: ahh.. one of the problems with the blueprint method... The definition is wrong.. It needs to be new, discussion or drafting I believe.
[16:11] <slangasek> cjohnston: right, sigh - fixing
[16:15] <ev> cjohnston, slangasek: cheers
[16:21] <stgraber> tjaalton: hey there, can you look at intel-vaapi-driver in Debian? My multi-arch change has been done in Debian now and they've moved to the new upstream so I think it's safe to sync but would prefer have you confirm that your patch is now fully covered by the new upstream in Debian
[16:21] <infinity> doko: Was it a soft versus softfp oops?
[16:22] <tjaalton> stgraber: sure
[16:22] <doko> infinity, the eglibc thing? both builds should be configured for soft
[16:23] <infinity> doko: Was just wondering, due to your multilib mangling in gcc-4.6
[16:24] <jamespage> doko, is openjdk-7 on arm for quantal now functional?
[16:24] <jamespage> looking at https://launchpadlibrarian.net/103810944/buildlog_ubuntu-quantal-armel.antlr_2.7.7%2Bdfsg-4_FAILEDTOBUILD.txt.gz
[16:25] <infinity> jamespage: It should be once the one from precise-proposed is copied forward (which hasn't happened yet).
[16:25] <jamespage> infinity, right-oh - good
[16:26] <infinity> jamespage: (doing so now)
[16:27] <jamespage> infinity, ta
[16:34] <tjaalton> stgraber: yeah, it's syncable. checking not helped by the debian maintainers not using upstream git history :)
[16:35] <stgraber> tjaalton: ok, syncing then
[16:35] <tjaalton> hum, I mean using git-import-orig instead of the upstream repo. thanks
[16:40] <cjohnston> slangasek: another foundations BP thats setup wrong: http://summit.ubuntu.com/uds-q/meeting/20604/packageselection-foundations-n-event-based-initramfs/
[16:41] <infinity> ogra_: Holy crap, after reinstalling, sound came out of my speakers!
[16:41] <infinity> ogra_: (Yes, this is a first)
[16:41] <ogra_> haha
[16:41] <ogra_> yeah, i added a ucm profile
[16:42] <doko> ogra_, ac100?
[16:43] <ogra_> yep
[16:43] <ogra_> just fiddling with 3.1 and the new armhf bonary driver here
[16:43] <ogra_> *binary
[16:43] <ogra_> compiz runs fine with it ... but sadly all unity UI elements are competely transparent
[16:44] <ogra_> (read panel, dash and launcher)
[16:44] <infinity> ogra_: "bonary" sounds about right.
[16:44] <cjohnston> /31/26
[16:44] <ogra_> haha
[16:57] <slangasek> cjohnston: that blueprint has been renamed, how do we delete it out?
[16:58] <cjohnston> slangasek: when they get renamed/deleted you have to get an admin to delete if from summit
[16:59] <slangasek> cjohnston: dear admin, please delete :-)
[17:00] <cjohnston> :-(
[17:04] <infinity> ogra_: So, what sort of success/fail am I looking for here? :P
[17:04] <cjohnston> slangasek: the problem is that we have created instructions, and like the one above, or 13 others that I find in the first 50 have been setup wrong, either being named wrong, or having a setting wrong or something... so someone has to fix each one of these that are setup wrong, or people have to deal with the fact that they are wrong (and at times, as earlier today they just dont show up)
[17:04] <infinity> ogra_: The driver "works", brings up lightdm (missing some elements, some flickering in and out), logging in seems to be less successful.
[17:04] <ogra_> infinity, use it for a while and see if it hangs hard at some point
[17:05] <ogra_> loggin in to the 3D session will fail without the compiz from proposed
[17:05] <infinity> ogra_: Using it might be difficult, after logging in, I seem to have a mouse pointer and a wallpaper, and not much else.
[17:05] <infinity> ogra_: Oh, now you tell me.
[17:05] <ogra_> and even then you end up with transparent unity
[17:05] <ogra_> so just go with 2d
[17:05] <ogra_> what i want to know is if it hangs hard on your system too or not
[17:06]  * ogra_ reboots into another kernel test
[17:07] <xnox> Laney: I made a typo in the boost tracker. can you please merge lp:~dmitrij.ledkov/ubuntu-transition-tracker/dima.
[17:07]  * xnox s/libbost/libboost/
[17:08] <Laney> doh
[17:08] <xnox> =)
[17:08] <slangasek> cjohnston: to be frank, the constraint that the blueprint has to be in the correct definition state is makework - if we've targeted a blueprint to a sprint but forgotten to reset the definition state (which is easy to do or a blueprint that's being carried over/resurrected from a previous cycle), it should still be scheduled/schedulable
[17:08] <slangasek> cjohnston: if we didn't want it on the schedule, we wouldn't target it to the sprint
[17:09] <Laney> done
[17:09] <xnox> thanks ;-)
[17:09] <cjohnston> the definition state works by default, its when its changed that it breaks... how do you suggest though that we figure out what track a blueprint is for?
[17:09] <slangasek> that, I can't say :/
[17:10] <slangasek> as for "by default", that definitely doesn't apply in the case of carried-over blueprints
[17:10] <xnox> Laney: why is it +junk branch? and not part of the project? And which branch should I target 'filter by seedss' support?
[17:10] <slangasek> cjohnston: are there misnamed blueprints that I could help review and fix for you?
[17:11] <cjohnston> and thats one of the flaws of the current way.. the 13 that I mentioned above were named wrong... so thats 13 metings that dont have tracks
[17:11]  * slangasek nods
[17:11] <Laney> xnox: the version deployed is an old one
[17:11] <Laney> hopefully we will upgrade to lp:ubuntu-transition-tracker soon, so target that
[17:11] <xnox> Laney: ok.
[17:11] <Laney> you could also usefully merge it with the vcs-import of the upstream branch if you want
[17:11] <xnox> will use that locally
[17:11] <cjohnston> slangasek: tbh, it would be LESS work at this point to manually change the tracks in summit.. but that requires someone with time to do that and to know what they should be
[17:12] <cjwatson> Laney: can we sit together at UDS and sort that out?  I keep forgetting to arrange that deployment
[17:12] <Laney> cjwatson: sounds like a reasonable thing to do, yes.
[17:12] <cjohnston> slangasek: I don't know how the LP API works, but if the ability existed to create a meeting in Summit and then press a button to create a blueprint in LP would that work?
[17:12] <slangasek> cjohnston: well, the one thing I see right off the bat when looking at https://blueprints.launchpad.net/sprints/uds-q are 'topic' blueprints, which almost certainly aren't meant to be sessions
[17:12] <cjwatson> and I think each time I've tried I run into some problem that would probably be trivial to sort out if you were there
[17:13] <cjohnston> slangasek: correct.. but people are setting them to uds-q and approving them
[17:13] <cjohnston> they need to be accepted for the cycle, but not approved for the sprint
[17:13] <cjohnston> :-(
[17:13] <Laney> xnox: what are you proposing to do for this seed support stuff?
[17:14] <slangasek> cjohnston: our workflow in foundations is entirely driven through the LP side... we would still need a way to nominate an existing blueprint for a sprint, and I'd rather not have two ways to do it (one in LP and one in Summit) as that's likely to cause more confusion rather than less...
[17:14] <cjwatson> cjohnston: I don't believe there is any LP API method to register specifications right now
[17:15] <cjwatson> cjohnston: you (or somebody) would have to extend LP for that
[17:15] <xnox> Laney: 1) get dump of seeds/package mappings in json from ubuntuwire/launchpad. 2) add second set of checkboxes with sets & ticks will filter same way as good/bad/unknown. 3) profit
[17:15] <cjwatson> cjohnston: there's the Launchpad development clinic at UDS ... :-)
[17:15] <cjohnston> slangasek: remove the blueprint import from Launchpad to Summit... Create a meeting in Summit and mark whatever blueprint(s) you want it to be associated with the meeting.. remove the "nominate for a sprint" process
[17:16] <cjohnston> cjwatson: if there is a clinic on creating more hours in the day then there may be a chance.. lol
[17:16] <cjohnston> ;-)
[17:16] <cjohnston> thats well beyond my time abilities
[17:16] <Laney> xnox: you might want to talk to mehdi @ Debian about how if something like this could usefully be done upstream
[17:16] <Laney> s/how //
[17:16] <cjohnston> but at the same time, I don't want to keep fixing 20+ blueprints every UDS because of errors
[17:17] <xnox> Laney: but packagesets are specific to ubuntu =/   well debian has tasks/tags
[17:17] <slangasek> vanhoof: hi, do you actually mean for this blueprint to have a session at UDS?  This looks like a topic tracking BP to me so probably wouldn't have a session, but I'm not sure: https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-kernel-hwe-essential
[17:17] <Laney> yes, but it's just parsing a json file and filtering based on that isn't it?
[17:17] <slangasek> vanhoof: basically it doesn't show up as part of a track at all right now, but is on the schedule; if you want a session it should be renamed to 'hardware-q-*', if you don't want a session we should remove it from uds-q
[17:18] <xnox> Laney: well I was thinking to inject id's seed-ubuntu seed-ubuntu-live etc in the rows. same as it is currently done. Such that the html page is stand-alonish as it is now.
[17:18] <cjohnston> which then means I have to delete it from Summit.. either way :-(
[17:19] <slangasek> cjohnston: do you understand my position that the 'definition' constraint is wrong and should be dropped?  Would you like a bug report?
[17:19] <xnox> Laney: i'll experiment & think about it more. before proposing something.
[17:19] <Laney> xnox: OK, I just think there's something more general that could be done here.
[17:20] <Laney> I feel slightly uneasy about this too; historically we haven't had divisions like this when dealing with transitions. All packages are equal.
[17:20] <Laney> Perhaps I need to think about this more though.
[17:20] <cjohnston> slangasek: I get that, and I'm not against it as long as we can do it.. a bug and someone to do the code would be the prefered way ;-)  but there are still plenty of other issues to fix that is only addressed by removing the LP requirement
[17:20] <slangasek> sure, I understand
[17:28] <akgraner> doko ping - would you have about 5 mins for me to discuss possible interview about the toolchain?
[17:30] <ogra_> hmpf, so my 3.1 ac100 kernel hardlocks on boot ... but if i boot with break=bottom and then simply ctrl-d out of the initrd shell to move on with booting, all is fine and the system starts
[17:31]  * ogra_ wonders where the race lives
[17:32] <stgraber> cjohnston: can you remove https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-release-management from the summit site too?
[17:32] <stgraber> cjohnston: I see someone already un-marked it for uds-q on the blueprint (possibly skaet)
[17:32] <slangasek> me
[17:34] <cjohnston> done
[17:36] <ogra_> hmm, must be plymouth or udev since it seems to break in init-bottom
[18:05] <stgraber> slangasek: I'm having a look at the resolvconf merge (mentioning it as I'm touched-it-last in precise but you are for precise-proposed)
[18:13] <slangasek> stgraber: ok - will you please pull in the changes from precise-proposed, then?  I had planned to do a pocket-copy
[18:13] <slangasek> stgraber: actually, I could do that now if that's preferable
[18:14] <stgraber> slangasek: I was planning on a udd merge of lp:debian/sid/resolvconf into ubuntu:precise-proposed/resolvconf so I'll have your change in there
[18:15] <stgraber> (and then push to ubuntu:resolvconf obviously)
[18:15] <slangasek> ok
[18:16] <slangasek> I could pre-emptively push precise-proposed to ubuntu:resolvconf
[18:19] <stgraber> hmm, precise-proposed/resolvconf doesn't exist?... that's a bit annoying
[18:20] <stgraber> slangasek: right, precise-proposed/resolvconf doesn't seem to exist (yet?) for some reason. I'll just import the .dcs locally into ubuntu:resolvconf before the merge
[18:21] <slangasek> stgraber: nah, just let me push it up to the branch
[18:22] <slangasek> stgraber: ubuntu:resolvconf updated
[18:23] <stgraber> slangasek: thanks
[18:42] <ChrisTownsend> Hi, an updated gwibber-service-sohu package by kenvandine to fix https://bugs.launchpad.net/ubuntu/+source/gwibber/+bug/959757 was uploaded on 2012-04-26, but the package was rejected.  Who would know why it was rejected?
[18:45] <seb128> bdmurray, hey
[18:45] <seb128> bdmurray, I undupped bug #989819, not sure why you marked dup of "useradd: cannot lock /etc/passwd"
[18:48] <infinity> seb128: Maybe it was an ironic example of bad duplicate matching? ;)
[18:48] <seb128> infinity, could be ;-)
[18:50] <infinity> ogra_: Well, I still haven't crashed my ac100, but this video driver's pretty lousy as doing simple things like "drawing boxes", so I'm not sure how much longer I can suffer testing it. :P
[18:51] <ogra_> hehm, stop it then
[18:53] <ogra_> (or try to find a UI with lots of circles, boxes arent the strenght of this driver indeed)
[18:55] <infinity> Oh, actually, it seems to be able to draw boxes, it's filling them with colour that fails miserably.
[18:55] <infinity> Dearest nvidia, welcome to 1990.
[18:56] <smoser> cjwatson, per daviey, looking to try to d-i preseed a squashfs install... can you point me at where to start ?
[19:09] <bdmurray> seb128: somebody else had marked it as a dupe of bug 988995 which is about useradd and the one I moved to duplicates of 523896
[19:50] <lifeless> bdmurray: hi ?
[19:52] <bdmurray> lifeless: hello
[19:52] <lifeless> bdmurray: did you see my mail about your bug scripts ?
[19:53] <lifeless> bdmurray: I don't seem to have a reply, and I don't want you guys to have a horrid surprise when the schema change goes live...
[20:12] <stgraber> cjohnston: is there some way for you to force foundations-q-containers-demo to be on Monday/Tuesday or at least ensure it's before servercloud-q-lxc?
[20:42] <slangasek> stgraber: track leads can do that; please pester me rather than cjohnston for such changes
[20:43] <stgraber> slangasek: oh, good to know. I used to be able to do that stuff but apparently I lost all my rights with the new instance...
[20:44] <melodie> hello
[20:45] <stgraber> slangasek: so would be great if you could move foundations-q-containers-demo to some time on Monday or Tuesday where it's not too busy at the moment (though I'm guessing that'll all change next time the scheduler runs anyway)
[20:46] <melodie> is there a tool to make a package in a few simple steps, or is the only way what is described here ?
[20:46] <melodie> http://translate.google.fr/translate?sl=fr&tl=en&js=n&prev=_t&hl=fr&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fdoc.ubuntu-fr.org%2Ftutoriel%2Fcreer_un_paquet&act=url
[20:47] <slangasek> stgraber: done
[20:47] <melodie> I arrived about at the middle of the page and it seems very long to me. I would like to learn and have this one package to try on, which does not exist at debian/ubuntu :
[20:47] <melodie> http://code.google.com/p/mimarchlinux/wiki/OpenBoxMenu
[20:47] <slangasek> melodie: http://wiki.debian.org/IntroDebianPackaging
[20:48] <stgraber> slangasek: thanks
[20:48] <melodie> slangasek, thank you !
[20:59] <xnox> slangasek++
[21:19] <cjohnston> stgraber: slangasek when something is manually scheduled it will not move again
[21:19] <slangasek> yep, I know
[21:20] <cjohnston> ok.. stgraber then. :-)
[21:20] <slangasek> but we don't have any other way to enforce "this before that" constraints
[21:20] <cjohnston> correct..
[21:20] <cjohnston> He said it would probably change when the scheduler ran again... was letting him know it wouldnt
[21:20] <slangasek> ah, yes
[21:22] <stgraber> cjohnston: I know it won't be moved, I was saying that the "pick a quiet spot" part of my request wouldn't last for long with the auto-scheduler as other session will likely move to that spot at some point
[21:22] <cjohnston> ahh
[21:50] <cjwatson> smoser: you're probably best off starting with the live-installer source packages, perhaps in combination with Debian live CDs (live.debian.net) as a reference implementation
[22:02] <smoser> cjwatson, thanks.
[22:02] <adam_g> trying to prep an SRU for the first time without sponsorship. do i need to only push to the -proposed branch and let someone from SRU team upload to -proposed? or am i to upload the source package as well? docs seem a bit lacking here
[22:02] <smoser> you upload to -proposed, adam_g
[22:02] <smoser> i wouldn't bother pushing to the branch
[22:02] <smoser> let the importer handle that.
[22:03] <roaksoax> adam_g: yeah, upload to -proposed, and subscribe to ubuntu-sru
[22:03] <adam_g> smoser: so just dput the *_source.changes, and getting it to the correct pocket is handled on the server side?
[22:03] <smoser> assuming you've done the debian/changelog correct
[22:03] <adam_g> yeah
[22:03] <smoser> (ie, that should say precise-propsed
[22:03] <smoser> and make sure your version number is correct
[22:03] <smoser> roaksoax, will review if you want to give him a diff
[22:03] <smoser> :)
[22:13] <DoctorPepper> hi guys!!