[00:23] <serue> anybody here able to tell me where debian/<binary_pkgname>.debhelper.log comes from?
[00:29] <RAOF> serue: The dh tool creates that.
[00:30] <serue> RAOF: can i stop it?  :)
[00:30] <serue> i don't see it in the previous build, and SpamapS didn't want to push a new version bc of it...
[00:31] <serue> (and it seems superfluous)
[00:31] <RAOF> It should be removed by the clean target.  How is it making it into your source packages?
[00:32] <serue> not sure what you mean by how, but after i do 'bzr bd -S -- -sa' and then dpkg-source -x *.dsc on the result, it's there
[00:32] <serue> it is not in my bzr tree
[00:35] <broder> serue: can you pastebin your rules file?
[00:36] <serue> broder: it's http://bazaar.launchpad.net/~serge-hallyn/ubuntu/oneiric/lxc/lxc-0.7.4.2-cleanup-patches/view/head:/debian/rules
[00:38] <broder> serue: don't see anything at first glance that would break cleanup, but there's a dh_lintian, and it gets called by debhelper.mk
[00:38] <broder> it looks for $PACKAGE.lintian-overrides
[00:40] <serue> and if that doesn't exist?
[00:40] <broder> ...then it doesn't do anything? i don't understand what you're asking
[00:41] <serue> just wondering what it's doing :)
[00:41] <broder> anyway, i'm suggesting you could move debian/lxc.overrides to debian/lxc.lintian-overrides and remove the cp call in the rules file
[00:41] <serue> ok thanks, that gives me something to look into
[00:41] <serue> ah
[00:42] <serue> idont' even know where that came from or what it was meant to do :)  i'll try that, thanks
[00:42] <broder> i think i blame autoreconf.mk for the superfluous debhelper.log file
[00:42] <broder> ah - maybe try moving the autoreconf.mk include *above* the debhelper.mk include?
[00:43] <serue> ah yes, that autoreconf.mk include might be new
[00:43] <serue> ok, lemme try
[00:44] <serue> is there a recommended order somewhere?
[00:44]  * broder shrugs
[00:45] <RAOF> That's a CDBS package; why is it calling dh *at all*?
[00:46] <broder> well, that too
[00:46] <RAOF> serue: If you just delete that file does it get regenerated?
[00:46] <broder> RAOF: including autoreconf.mk after debhelper.mk causes it to get appended to the clean step
[00:46] <broder> which means dh_autoreconf_clean will run after dh_clean
[00:46] <broder> and dh_autoreconf_clean generates .debhelper.log files
[00:46] <serue> broder: that worked, thanks!
[00:47] <RAOF> broder: Of course!
[00:47] <serue> as for calling dh at all, i dunno.
[00:47] <broder> i do think you have to call dh_installinit by hand if you want to use multiple --name arguments with cdbs
[00:47] <serue> comes from the debian package
[00:47] <broder> the dh_install calls are almost certainly superfluous, though
[00:48] <serue> oh,
[00:48] <serue> that doesn't work like the override_dh_install rules?
[00:49] <broder> no, with cdbs you change how dh_* work by setting magic variables
[00:49] <broder> usually something like DEB_DH_INSTALL_ARGS
[00:49] <broder> but really, the only way to know is to go rummaging through debhelper.mk
[00:50] <serue> i know i'm confused on dh vs cdbs vs others, so i'll put trying to clean up that rules file on my list
[00:50] <serue> and hoepfully learn a thing or two
[01:12] <serue> broder: thanks again
[05:02] <pitti> Good morning
[06:38] <doko> rsalveti: is it that urgent to apply the -mfloat-abi-soft work arounds?
[06:38] <dholbach> good morning
[06:39] <rsalveti> doko: don't think so, but was done already
[06:39] <rsalveti> doko: I just moved the bug status
[06:39] <doko> ahh, ok
[06:39] <rsalveti> ScottK: ^
[06:40] <rsalveti> package libkdcraw
[06:40] <ScottK> rsalveti: AFAIK only for one of the affected packages.
[06:40] <ScottK> Not the one doko originally filed the bug about.
[06:41] <doko> if it can wait, wait for the compiler fix expected next week
[06:49] <ScottK> Already did the workaround for libdkcraw so we could keep working on getting KDE 4.7 uploaded.
[06:50] <ScottK> I'll rebuild without it once the compiler fix is in.
[08:32] <BigWhale> Right, launchpad down... Thanks for the topic. :)
[08:45] <jml> morning
[08:45] <jml> BigWhale: fwiw, you can also always check http://identi.ca/launchpadstatus or https://twitter.com/#!/launchpadstatus
[08:47] <BigWhale> jml, I'll follow it right away :) Thanks
[09:05] <davmor2> Guys I've notices on my oneiric install the system locks up if I try and alter the volume.  The volume up and down keys don't work and if I use the slider it lock up the system I'm assuming it's known is there any info that would be useful to you?
[09:08] <BigWhale> davmor2, you should open sound settings and set volume there... that's what I do. :)
[09:08] <BigWhale> For now...
[09:09] <davmor2> BigWhale: Thanks
[09:09] <dupondje> missing launchpad :(
[09:09] <dupondje> :P
[09:11] <BigWhale> yeah, me too... I was just about to do some work (which is long overdue) now launchpad killed the mood :/
[09:12] <dupondje> I wanted to fill the sponsor queue a bit more ^^
[09:15] <BigWhale> davmor2, err, the volume keys on my keyboard are working now.
[09:16] <davmor2> BigWhale: mine work in that they send a signal they just don't do anything, Although I haven't done an update this morning so pass
[09:21] <BigWhale> yeah for me it started working after todays update.
[09:22] <dupondje> Launchpad is back !!
[09:22] <dupondje> :D
[09:23] <BigWhale> yay \o/ now every developer will hit bzr pull ... :>
[09:27] <davmor2> and kill LP again
[10:03] <pitti> mthaddon: seems it's still not officially back?
[10:04] <pitti>   Uploading py3cairo_1.10.0-0ubuntu1_source.changes: 2k/3k426 Transfer aborted.
[10:04] <mthaddon> pitti: in what sense?
[10:04] <pitti> during the RO time it failed right away
[10:04] <pitti> now it uploads everything until it comes to the sources.changes, and then aborts
[10:04] <mthaddon> pitti: it should be back - I'll look into it
[10:04] <pitti> also, I'm trying to change the status of bug 802486 and only get timeouts
[10:05] <pitti> ah, only adding a comment seems to work
[10:05] <wgrant> pitti: Bug timeouts we're working on.
[10:05] <pitti> but not opening the expander and clicking "save changes"
[10:05] <wgrant> Testing the fix right now.
[10:06] <pitti> wgrant: reminds me of the performance regression from the last rollout
[10:06] <pitti> wgrant: thanks for the heads-up
[10:06] <wgrant> It is exactly the same thing.
[10:06] <pitti> oh
[10:06] <pitti> it seems the dput actually worked, just got a NEW email
[10:07] <pitti> (two of them, actually)
[10:07] <pitti> mthaddon: ^ so it seems it's just a wrong error message
[10:07] <wgrant> pitti: I think I know what it is.
[10:09] <wgrant> pitti: Could you try the bug change again?
[10:09] <wgrant> Should be fixed now.
[10:09] <pitti> wgrant: works now
[10:09] <pitti> thanks!
[10:09] <dupondje> wgrant: attachments works also
[10:09] <dupondje> :)
[10:09] <wgrant> dupondje, pitti: Great, thanks.
[10:14] <wgrant> pitti: poppy is fixed now too.
[10:17] <pitti> wgrant: rocking, thanks!
[11:02] <maks_> pitti: hey, thanks for the initramfs-tools merge
[11:03] <maks_> added your fix in debian too http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commit;h=780bc4ad484dd2dbe2b3a784f4d245ed43c7bed6
[11:04] <maks_> one thing that you overlooked in the Ubuntu merge is that cjwatson 0.98.8ubuntu3 change is no longer necessary.
[11:04] <maks_> ldconfig is run inside of initramfs *before* cpio invocation.
[11:05] <pitti> maks_: oh, thanks; I thought it doesn't affect Debian, as we changed that part of the code
[11:05] <pitti> maks_: I thought the Debian version installed busybox as bin/sh directly?
[11:05] <MacSlow> seb128, what usually triggers glib-compile-schemas? A packages post-install script?
[11:05] <seb128> MacSlow, right, a dpkg drigger
[11:06] <seb128> MacSlow, i.e any package installing a schemas in the schemas dir will get it for free
[11:06] <pitti> maks_: ah, thanks; I'll revert that then and test it again
[11:06] <MacSlow> seb128, ah... autofoo-macro-magic I guess then
[11:07] <maks_> pitti: well Debian was affected to, so proper motivation to get rid of the symlink mess.
[11:07] <maks_> pitti: rechecking busybox hook.
[11:09] <cjwatson> mvo: thanks for the apt/python-apt uploads; could you upload a new version of the LongDescription backport to your PPA as well?  then I can test that all together
[11:09] <MacSlow> seb128, notify-osd is then nearly fully GSettings-ified
[11:11] <BigWhale> Can someone point me in the direction of gnome, introspection and python documentation?
[11:12] <BigWhale> I'm stuck at the "from gi.introspection import ..." :>
[11:13] <maks_> pitti: thank you, allways getting ln syntax wrong, fixed to match ubuntu behaviour, less diff is better.
[11:16] <seb128> MacSlow, excellent
[11:16] <seb128> MacSlow, was your compile schemas question a packaging one or an upstream makefile one?
[11:17] <MacSlow> seb128, well initially I assumed it needed some work on the packaging side... but it turns out my (upstream) changes to the makefile cover everything already
[11:17] <seb128> MacSlow, right
[11:17] <seb128> MacSlow, I will deal with the packaging, don't worry
[11:17] <MacSlow> seb128, just did a test here and the NotifyOSD keys show up when looking for them with the gsettings commandline-tool
[11:18] <seb128> MacSlow, btw feel free to ping me for review before rolling the tarball if you want
[11:18] <seb128> MacSlow, you probably want a .convert as well to migrate the gconf keys values to the new gsettings ones
[11:18] <MacSlow> seb128, sure... just migrating the code now
[11:18] <MacSlow> seb128, I've created a .gschema.xml file for notify-osd already
[11:19] <seb128> MacSlow, the .convert are trivial, see in /usr/share/GConf/gsettings
[11:20] <seb128> MacSlow, those are text format describing what keys to migrate and where, GNOME runs an utility at session start which will apply those conversion one and flag them done
[11:20] <MacSlow> seb128, I remember having read about something like that in the GConf-to-GSettings migration guide
[11:23] <seb128> MacSlow, right, just pointing it ;-)
[11:24] <MacSlow> seb128, yep... thanks... but I'm all over it :)
[11:26] <seb128> MacSlow, excellent ;-)
[11:28] <mvo> cjwatson: the version in the ppa (0.7.25.3ubuntu9.5+mvo2) should have both the xz and the LongDescripton fix, I will still upload with the new version to ensure that its newer then the -proposed version
[11:29] <cjwatson> mvo: right, that's all I meant; thanks
[11:33] <mvo> cjwatson: thanks. new upload is uploaded in the PPA now
[12:15] <mvo> cjwatson: I also killed of the duplicated compression list in python-apt, it uses the data from apt now instead of duplicating it
[12:16] <cjwatson> mvo: ok, we don't need that for lucid though right?
[12:16] <mvo> cjwatson: for lucid we are fine, I just wanted to kill the duplication as its ugly
[12:17] <mvo> (so that in the future its just one place to add support)
[12:19] <cjwatson> right
[12:27] <jdstrand> @pilot in
[13:39] <debfx> cjwatson: could you please update the kubuntu package set again? a lot of packages are still missing (e.g. libkexiv2, libkipi, marble, ...)
[13:43] <cjwatson> debfx: I've done an auto-update.  http://paste.ubuntu.com/643259/
[13:44] <ScottK> Looks good.
[13:45] <debfx> yep, thanks
[14:04] <jdstrand> didrocks: hey. I uploaded the fix for unity for bug #805938. I could not apply to the Vcs branch because bzr kept crashing on me. I put my debdiff in the bug if you want to apply it to your tree
[14:30] <Riddell> barry: what's the "Version number suggests Ubuntu changes" issue at the bottom of http://people.canonical.com/~dholbach/packaging-guide/html/udd-working.html ?
[14:31] <soren> Riddell: What do you mean?
[14:31] <soren> Riddell: You mean you've never seen that?
[14:32] <Riddell> soren: I have but the guide suggests it's an issue with UDD and can be worked around
[14:32] <Riddell> (as I read it)
[14:33] <soren> Well, it can certainly be worked around.
[14:33] <Riddell> but better to fix it by setting the correct Maintainer address
[14:33] <barry> Riddell: in a meeting...
[14:34] <soren> I see that mentioning it there suggests it's about UDD, but OTOH it's not an uncommon problem to stumble on, so having the solution right there is kind of handy.
[14:35] <micahg> yes, but Riddell's point is valid, the wording makes the workaround more desirable than the proper fix
[14:57] <barry> Riddell: right, it's not a udd thing.  it would really be better in the general packaging part of the guide, but that needs some reorg to get it all consistent
[14:58] <Riddell> barry: ok I'll remove it from there and file a bug to remind myself to add it back elsewhere
[14:58] <barry> Riddell: +1
[14:59] <Riddell> barry: in http://people.canonical.com/~dholbach/packaging-guide/html/udd-uploading.html "Uploading a change made by you" seems to miss the commit step
[14:59] <Riddell> it also does a dput before a tag/push, I'd expect that to be the other way around
[15:00] <barry> Riddell: missing commit, looks like you're right
[15:00] <maco> dear people who have scripts that make graphs and such in their people.ubuntu.com/~you/  -- how are you doing that?
[15:00] <maco> python? php? what's available?
[15:00] <barry> Riddell: order of steps, yes, i think you're right too, but double check w/ jelmer i think there was a discussion about that recently
[15:00] <barry> (Riddell, terse due to meeting ;)
[15:00] <Riddell> barry: thanks, I'll make those changes
[15:01] <Riddell> if jelmer agrees
[15:01] <Riddell> maco: Excel? :)
[15:01] <maco> Riddell: automated ones :P
[15:01] <Laney> we do code review for the packaging guide
[15:01] <Laney> so please push to a branch and do a mp
[15:03] <Riddell> Laney: yes I will (I don't even have commit access)
[15:03] <Laney> Riddell: you do (via ~ubuntu-dev)
[15:04] <Riddell> ooh, I am powerful!
[15:06] <Laney> http://2.bp.blogspot.com/_muBQl8yh4Q0/SzpiCnYTSXI/AAAAAAAAASc/UrqtYFtOOtg/s400/spideyquote.jpg
[15:09] <Cas07> anyone here used debhelper7 and dh-translations with desktop files?
[15:12] <pitti> barry, doko: I'm currently building a python3-gobject package
[15:13] <pitti> barry, doko: the thing that breaks is:
[15:13] <pitti> W: dh_python3:231: renaming _gobject.so to _gobject.cpython-31mu.so
[15:13] <pitti> (and similar renamings for the other extensions)
[15:13] <pitti> barry, doko: why is it -31? I'm building with python 3.2
[15:13] <barry> pitti: only for py3.2?
[15:13] <pitti> if I rename the installed file to _glib.cpython-32mu.so, it works
[15:14] <pitti> barry: well, that's what py3versions says for --supported
[15:14] <pitti> I don't have 3.1 installed
[15:14] <barry> pitti: that sounds like a dh_python3 bug
[15:14] <pitti> I'm building against python3-all-dev and iterate over `py3versions --supported --version`
[15:14] <barry> pitti: well, another question is why _gobject.so doesn't get written as _gobject.cpython-32mu.so in the first place
[15:14] <pitti> right
[15:14] <pitti> for some reason dh_python3 seems to think it's a 3.1 library
[15:15] <pitti> how does it detect the version that it built with in the first place?
[15:15] <pitti> I don't specify any version or so
[15:15] <pitti> just dh_python3 -a
[15:15] <barry> pitti: how is gobject built?  with distutils or outside of that build system?
[15:16] <pitti> barry: distutils plus some extra autotools for other stuff
[15:16] <dupondje> jdstrand: thx for the sync's :)
[15:16] <barry> pitti: py3.2's distutils should dtrt
[15:17] <pitti> $ dh_python3 -v
[15:17] <pitti> D: dh_python3:286: package python3-gobject details = {'compile': True, 'requires.txt': set(), 'shebangs': set(), 'private_dirs': {}, 'ext': {(3, 1)}}
[15:17] <pitti> that (3,1) might have something to do with it?
[15:18] <pitti> I build it with PYTHON=python3.2 ./configure ...
[15:18] <barry> pitti: indeed.  i had a system crash this week so i cannot do any local builds atm to debug further
[15:18] <pitti> hm, I wonder when it calls setup.py in the first place
[15:19] <pitti>     if vers == '3':
[15:19] <pitti>         # assume .so files without tag in /usr/lib/python3/ are build for Python 3.1
[15:19] <pitti>         vers = '31'
[15:19] <pitti> ^ in dh_python3
[15:19] <pitti> so I guess the upstream build system doesn't "tag the extension", whatever that means
[15:19] <barry> pitti: that means adding the 'cpython-32mu' bit
[15:20] <pitti> oh, are upstream build systems supposed to name the libs that way?
[15:20] <pitti> upstream it just comes out as _glib.so
[15:20] <pitti> that's why it is a warning?
[15:21] <barry> pitti: well, they don't *have* to in the sense that python will still import them under the old name, but dh_python3 is apparently not prepared to handle untagged so's for python >= 3.2
[15:21] <pitti> barry: well, something needs to tell dh_python3 which version the library was built with
[15:21] <barry> pitti: but the build system *should* tag the files so they don't collide and we don't have to play stupid symlink games
[15:21] <pitti> right
[15:21] <barry> pitti: which is what dh_python3 is trying so hard to be helpful with ;)
[15:21] <pitti> barry: ok, so it would be better/correct for upstream "make" to build _glib.cpython-32mu.so instead of _glib.so?
[15:22] <barry> pitti: i think dh_python3 shouldn't assume untagged == py3.1
[15:22] <barry> pitti: yep
[15:22] <barry> pitti: but only for python >= 3.2
[15:22] <pitti> barry: ok, thanks! then I'll look into fixing the upstream build system accordingly and then backport the patch
[15:22] <barry> pitti: doko back ported that support so for debuntu, tagged sos works for python 3.1 also, though you don't care :)
[15:23] <barry> pitti: awesome.  i do think a bug report on dh_python3 would be helpful.  it should not assume untagged == py3.1
[15:23] <barry> pitti: could you file that bug (i'm technically still in a meeting :)
[15:23] <pitti> barry: ok
[15:23] <barry> pitti: awesome, thanks
[15:27] <pitti> barry: bug 809951, I hope I included everything
[15:27] <barry> pitti: subscribed
[15:28] <pitti> barry: wow, what I believed to be an hour hack has now become a solid day's work :)
[15:28] <barry> :)
[15:28] <pitti> (had to fix a bunch of other stuff upstream first, and a 6 package multibuild is rather messy)
[15:31] <apw> cjwatson, ok ... finally can get to my own code branches, the casper changes i am proposing for overlayfs are here: https://code.launchpad.net/~apw/ubuntu/oneiric/casper/overlayfs
[15:31] <pitti> barry: is the .cpython-32mu suffix a firm convention, or is there a tool which computes it?
[15:32] <apw> cjwatson, have tested this with both normal kernels and overlayfs enabled ones and it seems to work, you may argue about order of course, ie about preferred union system
[15:32] <barry> pitti: both, in a sense ;)
[15:32] <barry> pitti: http://www.python.org/dev/peps/pep-3149/
[15:34] <pitti> $ python3-dbg -c "import sysconfig; print(sysconfig.get_config_var('SOABI'))"
[15:34] <pitti> cpython-32dmu
[15:34] <pitti> barry: that's what I was lookinf for, I think :)
[15:35] <barry> pitti: yep, and if you run it with python3, you'll see cpython-32mu (no 'd')
[15:36] <pitti> right, checked that
[15:38] <dholbach> UDW (https://wiki.ubuntu.com/UbuntuDeveloperWeek) day 3 starting in 23 minutes in #ubuntu-classroom
[15:56] <mvo> silly(?) question, but livebuild seems to be not working for me, any hints if I use it wrongly? http://paste.ubuntu.com/643344/ (this is on oneiric)
[15:59] <infinity> mvo: Isn't that just the ongoing "debootstrap is broken due to the /run transition" thing?
[16:00] <cjwatson> yup
[16:00] <cjwatson> huh, but you're doing --distribution natty
[16:00] <infinity> Oh, indeed.
[16:00] <mvo> and it seems to be the natty version of libc if I'm not mistaken
[16:00] <cjwatson> check the debootstrap log?
[16:01] <cjwatson> should be /debootstrap/debootstrap.log inside the chroot, probably
[16:02] <mvo> cjwatson: thanks! that was the missing clue :) http://paste.ubuntu.com/643352/ - its my kernel version , iirc this got fixed with the update three digest number.
[16:02]  * mvo updates on this box
[16:04] <pitti> barry: ah, so upstream apparently installs into versioned directories, like /usr/lib/python3.2/
[16:04] <pitti> barry: we'll look into it after the invoke-rewrite branch lands, but until then I just fix it up in debian/rules
[16:04] <cjwatson> mvo: aha, yes, use >= 3.0.0-4
[16:05] <mvo> thanks!
[16:05] <pitti> look, ma! pygi gtk3 working with python3 \o/
[16:06] <pitti> barry: ^ :)
[16:09] <pitti> good night everyone
[16:27] <fishor> hallo all, what version of cheese will be as target for ubuntu 11.10
[16:28] <fishor> ?
[16:28] <fishor> or how can i find it
[16:30] <slangasek> mvo: so you asked if my update-manager math problem was on amd64... does that mean you've seen this before?
[16:32] <bdmurray> pitti: could you review https://code.launchpad.net/~brian-murray/apport/casper-version/+merge/67579 ?
[16:34] <seb128> ev, hey
[16:35] <seb128> ev, do you know if keyboard layouts are set differently if you select "try ubuntu" on the text mode menu from a liveCD compared at if you let it boot and select "try ubuntu" on ubiquity?
[16:35] <seb128> ev, using the second option leads to bug #800561
[16:36] <ev> seb128: you have to select French as a language before the indicator shows you the French keymap
[16:36] <seb128> ev, GNOME somewhat get all english keyboard variant configured
[16:36] <ev> that's by design
[16:36] <ev> every keymap under the sun would be a lot to pack into a menu
[16:36] <seb128> ev, no, you select english (or let it this way) and click "try ubuntu"
[16:36] <seb128> the session you get has a load of english variants
[16:36] <seb128> see the screenshot on the bug
[16:37] <seb128> ev, where the live session if started from the text mode menu has only 1 selected layout
[16:37] <seb128> i.e "english"
[16:37] <ev> right, because they had the english language selected in ubiquity
[16:38] <ev> are you suggesting that it should clear the list of layouts when the user presses "try ubuntu", regardless of their language selection?
[16:38] <seb128> ev, well if you select the english layout on the text menu you get when pressing a key on boot you get only 1 layout
[16:38] <ev> right, that's a different code path
[16:38] <ev> a
[16:38] <seb128> ev, I suggest selecting a locale from the text mode and from unity should lead to a similar result
[16:38] <seb128> either way
[16:39] <mvo> slangasek: I have not seen it before, but we had problems in the past with the data types in the aptdaemon dbus code, I was wondering if it might be releated. the bad news is that we thought we fixed it
[16:39] <seb128> ev, the current ubiquity way leads to an interesting issue that xorg doesn't like have that number of layouts configured so it doesn't let you add a new non english one
[16:39] <slangasek> mvo: ok; will file a bug then
[16:40] <slangasek> mvo: btw, I also just had an aptdaemon crash, filed the report on that
[16:40] <slangasek> dunno if it's related
[16:40] <mvo> slangasek: thanks, that could well be
[16:41] <seb128> ev, i.e bug #640774
[16:42] <seb128> ev, i.e x11 limits you to 4 keyboard groups
[16:42] <seb128> ev, so having that stack of english layout makes it impossible to add a non english layout before clearing the list first
[16:42] <seb128> ev, well, I'm not sure what the right way, I'm just trying to understand why we land with that stack of layouts configured to start
[16:45] <ev> that's fairly arbitrary
[16:45] <ev> 4 keyboard layout groups are enough for anyone? :)
[16:46] <seb128> ups
[16:46] <seb128> gnome bug #640774
[16:46] <seb128> ev, no, "x11 design limitation"
[16:46] <seb128> ev, will be fixed the day we move to !x11 I guess
[16:46] <ev> x11's entire design is a limitation
[16:46] <seb128> right
[16:46] <seb128> well in that case the limitation is coming from x11
[16:47] <ev> right
[16:47] <seb128> I'm not sure what's the best way forward now for that bug though
[16:47] <seb128> is that wanted that picking english gets you all of existant english layout variants as configured?
[16:48] <seb128> could we just pick one and assume users who want other ones can add them using the control center?
[16:49] <ev> seb128: mpt suggested picking the top X layouts for that language
[16:49] <ev> we'd have to build that data into ubiquity/casper
[16:49] <ev> problem is, I'm not sure where we get that data
[16:49] <ev> because, alas, we don't measure these things yet
[16:49] <cjwatson> shouldn't we undo all the work that ubiquity does if you go through to the live session?
[16:49] <cjwatson> it should be as if you never went through ubiquity-m
[16:49] <cjwatson> *ubiquity-dm
[16:50] <ev> bug 810003 for consistency between ubiquity and casper on this
[16:50] <cjwatson> you could pick the top one layout for that language, that being the information that's already built into console-setup
[16:51] <cjwatson> for the time being
[16:51] <ev> hmm
[16:52] <cjwatson> if we can't do the other thing without breaking stuff
[16:53] <seb128> ev, cjwatson: I reassign bug #800561 to ubiquity, is that ok with you? there is not a lot we can do from the ui side with the x11 limitation
[16:53] <seb128> it's also not really practical to have an indicator keymap list going over the screen
[16:54] <ev> seb128: sure, I was just adding these notes in there
[16:54] <seb128> ev, thanks
[16:57] <kirkland> sladen: are there Ubuntu monospace web fonts yet?
[17:00] <sladen> kirkland: in Beta.  Alledgedly the hinting on the Regular was finished a couple for days ago (the Hinting is what is needed to generated bitmaps)
[17:01] <sladen> kirkland: https://launchpad.net/~ubuntu-typeface-interest/+join  if people are interested
[17:04] <zyga> dholbach, hi, where will the developer week take place exacly? #ubuntu-classroom?
[17:04] <ricotz> infinity, hello, are you investigating the build failure of telepathy-glib?
[17:05] <dholbach> zyga, yes
[17:05] <infinity> ricotz: I am, but juggling with a few other things, so if someone beats me to it, they're welcome to. :P
[17:05] <infinity> ricotz: I have a bug filed upstream too, just as a personal reminder to get it fixed.
[17:05] <ricotz> infinity, ok, i will wait then
[17:06] <infinity> https://bugs.freedesktop.org/show_bug.cgi?id=39183
[17:06] <ricotz> thanks
[17:11] <selvakumaran_>  Hey All., i wish to add a change in UI of Update mgr., can i code for that..?
[17:12] <selvakumaran>  Hey All., i wish to add a change in UI of Update mgr., can i code for that..?
[17:12] <smoser> wonder if someone python aware could answer:
[17:12] <smoser> is this expected for some reason:
[17:12] <smoser> $ python -c 'import pkg_resources'
[17:12] <smoser> -c:1: UserWarning: Module paste was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
[17:13] <smoser> (i'm getting that from another module that imports pkg_resources, not just typing that command line for fun)
[17:13] <nigelb> heh
[17:22] <kirkland> sladen: okay, thanks.
[17:24] <infinity> mvo: Is it intentional that update-manager's release upgrade tool lost support for local mirrors?
[17:24] <infinity> Err, and if he were here, he might be able to answer. :P
[17:25] <sladen> kirkland: what are you after inparticular?
[17:25] <kirkland> sladen: i'm giving a class in #ubuntu-classroom in 30 minutes;  i'm doing a live demo/webcast at http://bit.ly/uclass
[17:25] <kirkland> sladen: username/pass = guest/guest
[17:25] <kirkland> sladen: that's an ajaxterm
[17:26] <kirkland> sladen: jcastro mentioned that it would be nice if our ajaxterm package used the ubuntu colors/font
[17:26] <kirkland> sladen: it's pretty easy to hack the css/html
[17:26] <kirkland> sladen: i hacked it a few minutes ago to use the serif font, but without monospace, the terminal looks terrible
[17:27] <sladen> kirkland: bad idea, leave it at 'UbuntuBeta Mono, monospace' at the moment
[17:28] <sladen> kirkland: ah, I was talking to soren about this yesterday too
[17:28] <sladen> kirkland: and looking into possibly patching the SeaBIOS source (soren was assuming it'd be webbrowser-based VNC for openstack in the future)
[17:30] <sladen> kirkland: looks lovely from there, but I have 'UbuntuBeta Mono' installed
[17:30] <kirkland> soren has an interest in ajaxterm?
[17:30] <kirkland> sladen: hmm, not sure i understand your directions
[17:31] <sladen> kirkland: I want Ubuntu Mono to be used whenever an adminstrator is accessing an Ubuntu/Cloud server from a web-interface.  I don't mind what the technology used to do that is
[17:32] <kirkland> sladen: okay
[17:32] <kirkland> sladen: but it's not in the google web fonts yet, right?
[17:33] <sladen> kirkland: no.  Ubuntu Mono isn't finished.  it's currently betaing.  We'll probably release it this mnth
[17:34] <sladen> kirkland: once the engineering is done.  But that's still later than I'd like, so it would be good to get the infrastructure all lined-up for Web/etc
[17:34] <kirkland> sladen: okay, no problem;  so not a candidate for this presentation;  will check back with you later
[17:34] <kirkland> sladen: i'd be glad to see you change the css shipped with ajaxterm, though
[17:34] <sladen> kirkland: not unless people already have installed (about 1,400 people, so it might be worth setting the CSS anyway)
[17:35] <kirkland> sladen: whatever you say, mate
[17:53] <jdstrand> @pilot out
[17:54] <vikapi> i really missed lvm support while installing kubuntu (using kubuntu for the very 1st tie).. will this feature be added in any future release.??
[17:54] <vikapi> *time
[17:59] <slangasek> cjwatson: whee; I just looked in my oneiric dev chroot and find that /lib/init/rw is not a symlink to /var/run like it's supposed to be.  I guess this is because I continuously upgraded, and it's a chroot so init scripts never ran... I wonder if this matters
[17:59] <slangasek> vikapi: lvm support is available when installing kubuntu using the alternate CD image instead of the desktop one
[18:00] <slangasek> vikapi: lvm support for the desktop installer has been on the Would Be Nice list for years, but it requires some dedicated effort to get there so it's never happened; I think the installer folks would heartily welcome community contributors who were willing to work on this
[18:00] <vikapi> slangasek, aha..i should ve known this bfore..alright, wats the difference between alternate and desktop??
[18:00] <vikapi> slangasek, i would love to contribute, but im a very newbie in developement..:)
[18:01] <vikapi> slangasek, and my contribution (if any) wud be so insignificant
[18:01] <slangasek> vikapi: the desktop CD gives you the graphical, X-based installation (plus the try-before-you-buy live desktop environment); the alternate CD boots straight into a fullscreen text interface (specifically, debian-installer)
[18:03] <vikapi> slangasek, ok tats the only difference??anythng else relatd to default packages selectd.. like wat we have for desktop vs server editions??
[18:07] <slangasek> vikapi: no, the packages you get installed at the end are meant to be 100% identical in the default case (though obviously, if you use lvm from the alternate installer, you'll have lvm tools installed at the end that you wouldn't using the desktop CD)
[18:09] <cjwatson> slangasek: I suppose we could deal with that in the mountall run_migrate stuff too
[18:09] <cjwatson> apw: thanks, looks good, I'll merge that
[18:13] <vikapi> slangasek: ok..
[18:16] <smoser> i opened bug 810019 to address my issue above.
[18:16] <slangasek> cjwatson: do we even need to, though?
[18:20] <slangasek> cjwatson: normal case: /lib/init/rw is only used by things coordinating with initscripts itself (for sendsigs); /lib/init/rw is already a symlink to /var/run in Ubuntu, with /var/run becoming bind mounted to /run on upgrade; so there's only one sendsigs list on upgrade of a non-chroot, and it's in the right place
[18:21] <slangasek> continuously-upgraded chroot case: /lib/init/rw is still a directory because the reboot code has never switched it over; but it's a chroot so sendsigs is irrelevant and who cares
[18:22] <slangasek> newly-installed chroot case: /lib/init/rw is a symlink to either /var/run or /run depending on which version it was bootstrapped with, and will stay that way forever, so that's fine both for chroots that will become booted systems after the install finishes, and for chroots that will remain chroots indefinitely
[18:24] <Phr3d13> something is wrong regarding via vt6410 pci raid/ide card, the pci card is detected by the system (ubuntu 11.04) but none of the hard drives show up
[18:25] <Phr3d13> not trying to set up a raid array, just trying to get individual ide drives working
[18:25] <bryceh> slangasek, on https://launchpad.net/ubuntu/+source/wayland seems to be stuck in pending publication; I merged my package with debian's and that resulted in some changes to binary packages, wondering if that is what's got it blocked?  Any ideas on what I need to do to get it unblocked?
[18:26] <slangasek> bryceh: yeah, it's in the binary new queue :/  sec, let me hit it with the mallet
[18:29] <slangasek> bryceh: accepted.  BTW, why are libwayland-client and libwayland-server shipped in a single lib package?  Are they guaranteed to have soname bumps in lockstep?
[18:31] <bryceh> slangasek, should be, yes.
[18:31] <slangasek> fair enough
[18:31] <slangasek> bryceh: in that case, I would suggest adding a lintian override for this, with an explanatory comment to that effect :)
[18:32] <cjwatson> slangasek: OK, you're right, since it becomes irrelevant we can just not care
[18:34] <cjwatson> slangasek: it would only be if there are other things in /lib/init/rw that are actually relevant in a chroot, which I'm having trouble imagining
[18:35] <bryceh> slangasek, ok... I didn't spot an error to this effect when I built the package, what are you seeing?
[18:35] <slangasek> cjwatson: I've just noticed another wrinkle, which is that the /lib/init/rw symlink migration only happened in maverick so will still be a separate directory by the time /etc/init.d/sendsigs runs on first reboot; but I've convinced myself this doesn't require anything more elaborate than what rleigh already has in place (checking both dirs)
[18:35] <slangasek> bryceh: $ lintian wayland_0.1.0~0-1ubuntu1_i386.changes
[18:35] <slangasek> W: libwayland0: package-name-doesnt-match-sonames libwayland-client0 libwayland-server0
[18:35] <slangasek> W: libwayland-dev: binary-without-manpage usr/bin/wayland-scanner
[18:35] <cjwatson> slangasek: yes, ISTR there are already places where we check both dirs anyway for similar reasons
[18:35] <cjwatson> or used to be
[18:35] <slangasek> cjwatson: eh, "in upgrade from LTS" belongs in that sentence somewhere, but you get the idea :)
[18:36] <slangasek> yep
[18:36] <bryceh> slangasek, ah
[18:36] <cjwatson> I filled that in for myself :)
[18:57] <Phr3d13> trying to get a vt6410 pci ide card working on ubuntu 11.04
[19:17]  * Kreative` is away: Away
[19:18] <ion> !away
[19:19] <seb128> bigon, why a no source change upload rather than a retry build on launchpad?
[19:20] <bigon> euh the pkg was already built no?
[19:20] <bigon> d'oh
[19:21] <seb128> bigon, no, it needed a retry
[19:21] <seb128> ok, seems an overlook, it's ok ;-)
[19:31] <soren> kirkland: Sort of.
[19:32] <soren> kirkland: It's used under certain circumstances in OpenStack.
[19:34] <kirkland> soren: neat
[19:47] <slangasek> cjwatson: heh, something has created /run/motd prematurely in my chroot, so that's fun
[19:47] <slangasek> postinst fails to link the dirs
[19:48] <slangasek> courtesy of base-files, of course
[20:24] <bryceh> slangasek, thanks for kicking wayland.  It appears amd64 and armel have gone through, but i386 appears to still be pending.  Do you know what might be blocking it?  https://launchpad.net/ubuntu/+archive/primary/+sourcepub/1817225/+listing-archive-extra
[20:25] <slangasek> bryceh: probably that it landed after I accepted the other two :) accepting now
[20:27] <bryceh> thanks
[20:42] <slangasek> can anyone here tell me if they see a /var/run/run -> /run symlink on their oneiric system?
[20:46] <seb128> slangasek, not there
[20:46] <slangasek> ok
[20:46] <bryceh> slangasek, none here either
[20:47] <slangasek> then I'll consider it a one-off and wait for the screaming :P
[20:47] <bryceh> updated yesterday though; I'll update again
[20:47] <bryceh> (now that I can install wayland on it... yay)
[21:00] <Phr3d13> any driver developers in here? i can't get my vt6410 pci raid/ide card to work, even though it looks 'supported'
[21:07] <Phr3d13> any driver developers in here? i can't get my vt6410 pci raid/ide card to work, even though it looks 'supported'
[21:39] <slangasek> not auto, the other thing
[21:39] <cjwatson> slangasek: /var/run/run> maybe we should use ln -nsf rather than ln -sf for the sake of paranoia
[21:40] <directhex> hm. i wonder why libubuntuone is ignoring a configure flag
[21:40] <slangasek> cjwatson: maybe - but ATM I have bigger concerns, / isn't guaranteed to be mounted rw at the time the /run mounted event fires
[21:40] <cjwatson> oh, ouch, whoops
[21:41] <directhex> oh, moot point, the builders have exploded
[21:41] <cjwatson> I'm not at a proper computer right now - how late is the rw mount?
[21:42] <slangasek> working that out now
[21:42] <slangasek> publisher stopped to buy me some breathing room
[21:42] <bdmurray> Is it just me or would a package installation failure with an Out of memory message in dmesg be suspect?
[21:43] <cjwatson> depends on what the OOM killer killed
[21:43] <ogra_> bdmurray, hmm, i had that too today but i blamed arm and my actual low ram
[21:43] <cjwatson> worth looking a, but doesn't necessarilly invalidate a failure
[21:43] <cjwatson> *at
[21:44] <ogra_> dmesg should have some info :)
[21:44] <cjwatson> you might have had some kind of oom event and then run an upgrade after it had run its course
[21:44] <directhex> hooray oom killer
[21:45] <cjwatson> if the oom killer took out dpkg or something, then yeah, not likely to be a valid bug :)
[21:46] <bdmurray> cjwatson: or something like lzma
[21:46] <cjwatson> yep.  the more general the thing it killed, the more likely you are to have to pair it up with where the terminal log falls over
[21:47] <cjwatson> lzma being killed would probably go with something like "dpkg-deb: short read in buffer copy" or whatever that message is
[21:50] <bdmurray> cjwatson: what the keyboard-configuration post-inst and lzma being killed?
[21:51] <cjwatson> bdmurray: not sure I see an immediate connection there
[21:54] <bdmurray> cjwatson: it calls update-initramfs?
[21:54] <cjwatson> oh yeah
[21:54] <cjwatson> on live media that would involve lzma
[22:20] <slangasek> cjwatson: mounted-var isn't as safe as we thought it was, because some of the things under /var/run are sockets... :)
[22:20] <slangasek> er, wait
[22:20] <slangasek> no, it's just as safe (and unsafe) with sockets as anything else
[23:36] <slangasek> vila, james_w: can you explain why the package importer kicked https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/sysvinit/oneiric-201107132118 aside?
[23:36] <slangasek> vila, james_w: I intend to clobber the UDD branch with the original one, which was there for a reason :)
[23:45] <james_w> slangasek, did you push/merge that branch back to lp:ubuntu/sysvinit?
[23:45] <slangasek> james_w: yes - that was pushed (immediately) before I uploaded the package
[23:46] <slangasek> I've now repushed it with --overwrite
[23:46] <james_w> ok, I'll have to find the old head then to compare
[23:46] <slangasek> ok
[23:46] <james_w> it thought that .bzr-builddeb/default.conf and the script you changed were different in the branch and the upload
[23:47] <slangasek> hmm
[23:47] <slangasek> that's true since I deleted the .bzr-builddeb/default.conf after tagging - but I didn't think that got included in the upload anyway with bzr bd
[23:47] <james_w> I can't tell you how they were different right yet, as I'd just be comparing something with itself
[23:53] <james_w> slangasek, I can't see the revision that you push --overwrote
[23:53] <slangasek> oh?
[23:53] <james_w> well
[23:53] <slangasek> did I get clobbered again? ;)
[23:54] <slangasek> doesn't look like it
[23:54] <james_w> if we're being truthful I can
[23:55] <james_w> just keeping you on your toes
[23:55] <james_w> or not reading properly
[23:55] <james_w> one of the two
[23:55] <slangasek> ;)
[23:57] <james_w> http://paste.ubuntu.com/643614/
[23:57] <james_w> that's -importer's +yours
[23:58] <james_w> but that still doesn't explain it to me
[23:59] <slangasek> infinity: do you have buildd chroot mangling access these days?