[02:55] <RAOF> Woot!  I've got a system that refuses to upgrade to precise due to an inability to configure libtinfo5 for libncurses5.  How do I get do-release-upgrade to dump enough debugging info for someone to work this out?
[03:00] <elmo> RAOF: it tends to dump enough information into /var/log/dist-upgrade/ by default
[03:01] <RAOF> Hah!  There it is.
[03:19] <RAOF> Now available as bug #924079
[04:02] <broder> i wonder if it makes sense to make the series nomination link visible again but make it a link to a wiki page a la +filebug
[04:02] <broder> backports has been seeing a non-zero number of bugs that are really SRUs. one person commented today that they were doing it to raise awareness since they couldn't nominate anymore
[04:02] <broder> i wonder if that's reflective of more of those bugs than we realized
[04:03] <broder> (yes, i realize that redirecting to the wiki link on +filebug sucks and that nobody likes it)
[04:05]  * ScottK wonders what the feedback mechanism was meant to be when the nomination link was removed?
[04:05] <broder> i think it was intended to be #ubuntu-bugs. i'm not sure how people were supposed to discover that
[04:07] <micahg> nominating doesn't necessarily help without someone try drive the patch
[04:08]  * ScottK was going to guess "We're drowing, we can't afford to care".
[04:08] <ScottK> True.
[04:08] <micahg> although, I supposed that the nomination queue could be looked at as a source of things to do if it was used as such
[04:09] <ScottK> If anyone much cared about bugs ...
[04:10] <micahg> we care, but we're drowning
[04:11] <micahg> almost 100k open bugs with >50% new
[04:11]  * micahg is reminded of the need to go through all the Firefox bugs at some point...
[04:12] <ScottK> Right, but what's more important, fixing bugs or pushing new features?
[04:13] <broder> what is it called again, the gnome adhd monkey syndrome? "if i replace the feature, i don't have to fix its bugs!" :)
[04:13] <ScottK> Also a lot of those aren't even actually bugs.  I know a large fraction of the bugs open against postfix in Ubuntu are PEBKAC issues.
[04:13] <ScottK> broder: If it's Gnome, I think you mean remove, not replace.
[04:15] <broder> hmm...on a side note, i should probably get my rear end moving if pre-release backports is going to be ready by feature freeze, huh?
[04:16] <micahg> would be nice this cycle :)
[04:18] <broder> i think i made it as far as breaking the lp test suite last time i looked
[04:19] <ajmitch> broder: you've still got a few days :)
[06:21] <pitti> Good morning
[06:24] <ajmitch> morning pitti
[06:28] <pitti> hey ajmitch, how are you?
[06:29]  * nigelb waves to pitti and ajmitch 
[06:30] <ajmitch> good, how are you?
[06:31] <pitti> quite fine, thanks!
[06:31]  * pitti waves back to nigelb
[06:31] <ajmitch> hi nigelb
[07:27] <tumbleweed> someone please let my ubuntu-devel-announce mail through
[07:40]  * pitti arghs about listadmin being broken now; apparently something changed in our ML archive
[07:43] <pitti> tumbleweed: done
[08:08] <dholbach> good morning
[08:14] <zyga-afk> good morning
[08:14] <zyga-afk> hey dholbach :)
[08:16] <zyga-afk> mvo: :)
[08:21] <mvo> hey zyga-afk
[08:23] <dholbach> heya zyga-afk
[08:24] <geser> does somebody know why the TB mailing list isn't listed on lists.ubuntu.com? Is it on purpose or missed after it changed from private to public?
[08:27] <pitti> geser: I guess the latter; this very much looks like a wiki page
[08:32] <geser> who to bug about it? (assuming the TB list should appear there)
[09:12] <seb128> hey
[09:12] <seb128> doko, did --as-needed stop being enforced or something?
[09:13] <seb128> it seems that on precise builds with a missing -l... don't fail as they should
[09:34] <cjwatson> pitti: IME listadmin still works but falls over some random percentage of the time
[09:38] <pitti> cjwatson: hm, it still works for ubuntu-de@ here, but for techboard it has stopped working a few weeks ago; it only gets over "nothing in queue" now from here
[09:39] <cjwatson> I used it on technical-board@ yesterday
[09:39] <pitti> hm, maybe I'm just unlucky, or it works worse in my mornings
[09:41] <Daviey> cjwatson: I was getting high failure rate
[09:41] <Daviey> I don't think it is the client, but the service timeing out.
[09:43] <Daviey> ie, fetching data for ubuntu-server@lists.ubuntu.com ...
[09:43] <Daviey> Use of uninitialized value in string eq at /usr/bin/listadmin line 832, <FIN> line 57.
[09:43] <Daviey> Use of uninitialized value in string eq at /usr/bin/listadmin line 826, <FIN> line 57.
[09:43] <Daviey> Died at /usr/bin/listadmin line 827, <FIN> line 57.
[09:44] <cjwatson> yeah
[09:45] <Daviey> second attempt worked.
[09:47] <Daviey> and, fetching data for ubuntu-devel@lists.ubuntu.com ...
[09:47] <Daviey> Died at /usr/bin/listadmin line 1310, <FIN> line 2.
[09:49] <doko> seb128, no: COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
[09:49] <doko>  /usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/
[09:49] <doko> ../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. /tmp/ccVTmo51.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o
[09:50] <seb128> doko, is the --no-add-needed normal in there?
[09:50] <doko> yes, but I could remove that one too
[09:50] <doko> it the default for ld 2.22
[09:51] <seb128> doko, ok, thanks
[09:51] <seb128> I wonder why lightdm-gtk-greeter builds without error where it uses libX11 functions without a -lx11
[09:52] <seb128> doko, btw is that normal?
[09:52] <seb128> $ gcc-4.5 -v
[09:52] <seb128> /usr/bin/gcc-4.5: not found (hardened-cc could not find target)
[09:52] <seb128> that breaks builds with i.e CC=gcc-4.5
[09:52] <doko> b-d on gcc-4.5?
[09:52] <seb128> $ gcc-4.5
[09:52] <seb128> /usr/bin/gcc-4.5: not found (hardened-cc could not find target)
[09:52] <seb128> doh
[09:53] <seb128> I wonder why I have the command if gcc-4.5 is not installed
[09:53] <seb128> doko, it's my box, I did gcc-<tab> I didn't notice gcc-4.5 was not installed
[09:53] <doko> you have hardening-wrapper installed
[09:53] <doko> which diverts gcc-4.5
[09:53] <seb128> I though "the binary is there so it must be installed"
[09:53] <seb128> doko, danke ;-)
[10:07] <tumbleweed> doko: I was assuming you'd see bug 915167 before it was noticed on the sponsor queue. It's an old release, but a trivial fix to a not entirely uncommon usecase
[10:11] <doko> tumbleweed, we'll remove python2.6 before release
[10:12] <tumbleweed> doko: that was a natty dh_python2 with a local python2.6 installed problem
[10:22] <tumbleweed> zul: err, looks like your mtx and netifaces merges yesterday don't actually contain anything useful. Sync next time?
[10:27] <doko> cjwatson, apw: what is our policy to ship separately buit kernel modules? I know that we do that for restricted modules, but is this accept for other dkms modules in main?
[10:29] <apw> i am unsure if there is a policy, cirtainly we have had other dkms packages around, there was an iscsi one for some time
[10:30] <doko> apw, looking at the openvswitch package
[10:30] <cjwatson> IIRC it's OK strictly provided that they're dkms
[10:30] <cjwatson> we've removed non-dkms ones in the past because we couldn't maintain them
[10:31] <cjwatson> do look into whether they're going to be kept well up to date though ...
[10:31] <apw> openvswitch is the openstack transport isn't it ?
[10:31] <doko> so this comes with a openvswitch-datapath-source *and* a openvswitch-datapath-dkms binary package
[10:31] <doko> yes
[10:32] <pitti> that looks broken indeed
[10:32] <apw> yeah if its dkms its usually liveable with, and often if it is version tied with userspace having them in the same package is better
[10:32] <pitti> usually, a dkms "binary" package sohuld just ship the source tarball and dkms control script
[10:32] <pitti> but it should be arch: all then
[10:32] <pitti> ah, openvswitch-datapath-dkms is, looked at the wrongone
[10:33] <Daviey> Hmm
[10:34] <doko> so we should stop building openvswitch-datapath-source?
[10:35] <pitti> it looks a little redundant
[10:35] <pitti> but it seems -source would integrate with module-assistant
[10:35] <pitti> whiel -dkms auto-builds with dkms
[10:35] <Daviey> right, what benefit do we get from changing t?
[10:35] <Daviey> it?
[10:35] <pitti> we certainly shouldn't start supporting module-assistant in main
[10:36] <zul> delta with debian
[10:36] <pitti> but I guess we can leave that binary in universe?
[10:36] <Riddell> jdstrand: security team onto this? http://packetstormsecurity.org/files/109230/advisory_sudo.txt
[10:36] <Daviey> doko / pitti: if you want to increase our delta with Debian, are your teams happy to take ownership for it? :)
[10:36] <doko> Daviey, the MIR team doesn't take ownership of anything ;-P
[10:37] <Daviey> heh
[10:37] <pitti> Daviey: err, I wasn't suggesting to change it, just thinking aloud why there are two, and that -source should stay in universe
[10:37] <Daviey> Yeah, really - what i am saying, changing the current package; does it increase the maintainability?
[10:37]  * Daviey feels no
[10:37] <pitti> *nod*
[10:39] <MacSlow> pitti, poing
[10:39] <pitti> hello MacSlow
[10:40] <MacSlow> pitti, just wondering if Oneiric will also get the newer libwnck3 at some point (in regards to your wnck_shutdown branch for notify-osd)
[10:40] <pitti> MacSlow: no, it won't
[10:40] <MacSlow> ok
[10:40] <pitti> MacSlow: but the merge proposal checks the availability during configure
[10:40] <pitti> MacSlow: so it will build fine with older wnck versions
[10:40] <MacSlow> pitti, sure I've seen that
[10:40] <MacSlow> pitti, was just curious
[10:40] <pitti> MacSlow: oh, you want it for testing?
[10:41] <pitti> MacSlow: I can certainly give you an oneiric build if you want one
[10:41] <pitti> it just won't go into oneiric officially
[10:41] <MacSlow> pitti, today I've my notify-osd maintainer hat on again... doing as much as I can on that front atm
[10:41] <pitti> nice!
[11:15] <doko> Riddell, bug #918289, do we consider ttf as a source format?
[11:16] <doko> and I assume the missing sources for the pdf files are a debian rc issue.
[11:17] <Riddell> doko: it's not ideal but yes it can be considered preferred modifiable form
[11:17] <Riddell> doko: yes PDF files should be taken seriously by debian and ubuntu
[11:18] <Riddell> (plenty of fonts only have .ttf files even though it's not really preferred modifiable form, like the ubuntu one)
[11:28] <doko> Daviey, could you have a look at bug #891232, it it's an issue for libvirt?
[11:31] <Daviey> looking doko, thanks
[11:33] <Daviey> doko: Serge Hallyn is the libvirt maintainer for Ubuntu.. If he feels it is, then i'm going to agree with him. :)
[11:34] <Daviey> (he raised the MIR)
[12:37] <doko> Sweetshark, ping on bug #906402
[12:41] <Daviey> doko: a heads up, roaksoax has at least 6 python modules which need to be MIR'd once they've passed NEW.
[12:45] <doko> Daviey, I hope I'm already travelling when these are accepted ;-)
[12:46] <Daviey> Yeee Haaa!
[12:46] <doko> Daviey, zul: opened a runit task for bug #801244
[12:48] <Daviey> thanks doko
[12:50] <soren> Daviey, zul: You guys still care about aoe support? Really?
[12:51] <Daviey> soren: I was waiting for zul to to discuss that. :)
[12:51] <soren> Daviey, zul: Do you still carry the driver?
[12:51] <soren> Daviey: It was removed from Nova months ago.
[12:51] <Daviey> I honestly didn't know.
[12:52] <Daviey> soren: no, we do not
[12:52] <Daviey> infact, i /thought/ we suggested switching?
[12:52] <soren> https://github.com/openstack/nova/commit/eb03d47fecd3bfc24243da29ee01679b334a08fe
[12:53] <seb128> doko, do you have any clue why building launchpad.net/lightdm-gtk-greeter/trunk/1.1.1/+download/lightdm-gtk-greeter-1.1.1.tar.gz on precise doesn't hit those bugs
[12:53] <seb128> https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/898134
[12:53] <Daviey>   * Stop depending on aoetools. iscsi is the default nowadays (and has
[12:53] <Daviey>     been for a while).
[12:53] <Daviey> soren: that was a change you made in natty!
[12:53] <seb128> doko, or https://bugs.launchpad.net/lightdm/+bug/916477 (which seems to happen on the debian toolchain)
[12:53] <soren> Daviey: Go me!
[12:54] <seb128> doko, well on gold on debian, i.e https://launchpadlibrarian.net/91537462/01_fix-configure-dso-linking.patch is required on Debian apparently where the same source builds fine in precise
[12:56] <doko> seb128, is it correct that it tries to link the static lib?
[12:58] <seb128> doko, dunno, that doesn't happen here, but I would think that the first bug (the missing -lx11) would stop the build
[12:59] <seb128> doko, I'm not sure to understand the gio one and why the .a is listed there
[13:01] <seb128> doko, hum, I wonder if the gio issue has something to do with "checking if gcc static flag -static works... no" in the debian build log
[13:03] <doko> seb128, well, have a look at the config.log
[13:03] <doko>   CCLD   liblightdm-gobject-1.la
[13:03] <doko>   GISCAN LightDM-1.gir
[13:03] <doko> seb128, ^^^ could you make this verbose in the build log?
[13:04] <manish> any idea why using --prefix=/usr in distutils starts installing packages in site-packages?
[13:04] <manish> shouldn't it install in dist-packages?
[13:05] <seb128> doko, I will ask details to the debian maintainer (who opened the bug) or try in a pbuilder thanks, I'm still a bit confused that the missing -lx11 doesn't stop the build though
[13:06] <doko> manish, you should not use --prefix=/usr. what do you want to achieve?
[13:07] <manish> right now I am trying to install software-properties
[13:07] <manish> it installs in /usr/local
[13:07] <manish> and does not get picked up properly
[13:07] <manish> when I run it
[13:07] <doko> whwere it belongs to, if you install it on your own
[13:40] <mhall119> ev: ping
[13:53] <jdstrand> Riddell: re sudo> yes. It only affects precise and our hardening measures mitigate it until a merge from Debian
[13:54] <Riddell> jdstrand: I knew we could count on our security team :)
[13:54] <jdstrand> :)
[13:57] <ev> mhall119: pong
[13:57] <mhall119> ev: hi, I'm in need of some help that I was told you can provide
[13:57] <mhall119> I need a list of the "top 50" apps in software center
[13:58] <mhall119> I'm told we don't have download stats, but we do have ratings
[13:58] <mhall119> so I'm thinking those with the most positive ratings
[14:00] <ev> mhall119: alas, I'm not the person who is responsible for the ratings and reviews server
[14:01] <ev> mhall119: mpt says there's already a top rated section.  Just click "more" next to top rated inside software center.
[14:02] <mhall119> mpt: any way I can easily convert that to a list of text, rather than manually writing them down?
[14:02] <mpt> mhall119, kiwinote or one of the other developers in #software-center could probably give it to you as Json, at least
[14:03] <mhall119> thanks mpt
[14:03] <dholbach> mhall119, highvoltage, hggdh, SpamapS, cyphermox: ready for later on? :)
[14:04]  * mhall119 is always ready
[14:04] <mhall119> (but not always prepared)
[14:13] <quadrispro> hi all!
[14:13] <astraljava> Hi Alessio!
[14:14] <hggdh> dholbach: aye
[14:14] <hggdh> and darn!
[14:18] <highvoltage> dholbach: I think so! I have a tomboy note with a bunch of things to say ready. I think it can full up some 25 minutes and then the rest is for questions
[14:18] <dholbach> excellent :)
[14:27] <tgardner> skaet, have you noticed that the screen lock isn't working after a resume? Is this a known bug?
[14:29] <pitti> tgardner: not known here; it still worked two weeks ago, at least
[14:29] <tgardner> pitti, 4 of us k-team dudes have noticed it
[14:30] <pitti> mdeslaur did two recent gnome-screensaver uploads
[14:30] <pitti> the changelog entries look related, anyway
[14:30] <pitti> mdeslaur: does locking after suspend work for you?
[14:31] <mdeslaur> pitti: yes...
[14:31] <mdeslaur> tgardner: what desktop environment are you using?
[14:31] <mdeslaur> tgardner: how are you suspending?
[14:31] <pitti> hm, doesn't seem to lock here
[14:31] <tgardner> mdeslaur, unity on precise
[14:32] <pitti> I tried with "suspend" in the indicator
[14:32] <mdeslaur> tgardner: do you have autologin enabled?
[14:32] <smb> there is another environment than unity...? :-P
[14:32] <tgardner> mdeslaur, nope
[14:32] <pitti> (my computer is closed in the dock, can't try lid right now)
[14:32] <smb> mdeslaur, not here
[14:32] <pgraner> mdeslaur, not here either
[14:32] <apw> mdeslaur, for me its either shut lid or menu ... both do not trigger the saver, and using normal passworded login
[14:33] <mdeslaur> hrm, ok, let me try
[14:33] <mdeslaur> stupid screen locking whack-a-mole
[14:33] <pitti> gnome-screensaver-command -l does work here, though
[14:34] <pitti> so, of course it could also be a regression in gnome-session
[14:34] <smb> pitti, It also locks after time for me
[14:34] <pitti> no, didn't change since December
[14:34]  * pitti checks settings-daemon
[14:35] <mdeslaur> pitti: yes, I changes settings-daemon also
[14:35] <cking> at least s3 resume is quick now ;-)
[14:35] <pitti> ah, could be http://launchpadlibrarian.net/91320909/gnome-settings-daemon_3.2.2-0ubuntu12_3.2.2-0ubuntu13.diff.gz
[14:36] <pitti> that seems fairly devensive, too, though
[14:36] <pitti> defensive
[14:36] <mdeslaur> let me dist-upgrade my test laptop and try to reproduce
[14:42] <doko> jodh, are the upstart build failures on armhf and powerpc real, or temporary?
[14:44] <jodh> doko: may be kernel-related (since as cjwatson observed those platforms have newer kernels). I'd started to investigate but now 100% on bug922754. Will return to that asaic.
[14:45] <doko> thanks
[14:45] <mdeslaur> ARGH, I can reproduce...wth
[14:46] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 14 minutes in #ubuntu-classroom
[14:54] <herton> pitti, hi, can you take a look when possible at copying kernels from bug 922692 to -proposed? I need it to start bugging people to verify SRU bugs this week.
[14:56] <jdstrand> pitti: hi! I'm told you are able to do this: would you mind rejecting https://code.launchpad.net/~l3on/ubuntu/oneiric/usbmuxd/security-919435/+merge/90611 and https://code.launchpad.net/~l3on/ubuntu/natty/usbmuxd/security-919435/+merge/90612?
[14:57] <pitti> jdstrand: done
[14:57] <pitti> herton: can do
[14:57] <jdstrand> pitti: heh, that was fast. Thanks! :)
[14:57] <herton> pitti, thanks
[14:59] <skaet> tgartner, mdeslaur - ack,  is there a bug number?
[15:01] <l3on> jdstrand, I read your reply... thanks, now I see :)
[15:03] <mdeslaur> skaet: not yet, I'll open one in a sec
[15:04] <skaet> mdeslaur, thanks!
[15:05] <pitti> herton: done
[15:07] <mdeslaur> ok, GAH!
[15:10] <mdeslaur> pitti, skaet, smb: ok, found it...uploading a fix in a few minutes
[15:10] <smb> apw, tgardner cking ^ :)
[15:10] <pitti> mdeslaur: cheers!
[15:10] <cking> YAY
[15:11] <smb> mdeslaur, yes, ta
[15:11] <skaet> mdeslaur, :D
[15:11] <mdeslaur> skaet: LP: 924336
[15:11] <skaet> thanks
[15:24] <jdstrand> l3on: thank you! :)
[15:58] <seb128> cjwatson, is that normal that I just got an "[ubuntu/oneiric-updates] evince 3.2.1-0ubuntu2.2 (Accepted)" email?
[15:59] <cjwatson> New normal, yes :-)
[15:59] <cjwatson> You uploaded it, right?
[15:59] <seb128> hum, did launchpad start sending emails on pocket copies?
[15:59] <cjwatson> I changed sru-release to do copies differently
[15:59] <seb128> cjwatson, yes, to proposed some time ago which I got an email for at this time
[16:00] <cjwatson> The old method didn't send mail; this one does - but that wasn't the reason to change, the reason is that this method is asynchronous so shouldn't time out all the time like the old one did
[16:00] <seb128> cjwatson, ok, it confused me for a moment, I was wondering if you reuploaded because I screwed something ;-)
[16:00] <cjwatson> It's a bit annoying that the mail shows up as from me: https://lists.ubuntu.com/archives/oneiric-changes/2012-January/011816.html
[16:00] <seb128> since the emails lists you in the "Signed-By"
[16:00] <cjwatson> But not the end of the world I guess
[16:00] <cjwatson> Yeah, it's like new-style syncs
[16:00] <seb128> cjwatson, ok, that's fine, I just got surprised
[16:01] <cjwatson> signed ~= requested
[16:01] <seb128> cjwatson, maybe it's worth dropping a note about on the list in case others get confused as well
[16:01] <cjwatson> I agree the presentation isn't entirely ideal but I figure people will get used to it :)
[16:01] <cjwatson> mm, could be
[16:01]  * cjwatson adds to todo
[16:01] <seb128> cjwatson, thanks ;-)
[16:02] <cjwatson> I suppose we could do the syncs as the katie user, which would inhibit the mail
[16:02] <cjwatson> I might test that
[16:04] <cjwatson> something like http://paste.ubuntu.com/823985/
[16:05] <seb128> cjwatson, I'm not sure the email is an issue, it tells you that the updated got verified and moved so it can be useful informations, the change of behaviour is just a bit confusing (as any change ;-)
[16:06] <cjwatson> This is true.  The Signed-By is kind of odd though.
[16:17] <doko> zul, just to confirm, you did the packaging for python-keystoneclient, didn't you?
[16:17] <zul> yeah
[16:17] <doko> exactly, not mentioned in debian/copyright. only the upstream apache license is mentioned
[16:18] <doko> so add debian/*
[16:18] <zul> doko: ok ill go fix that then
[16:18] <doko> and the appropriate copyright
[16:18] <doko> thanks
[16:27] <zul> doko: added
[16:29] <smoser> anyone know what it is that creates /dev/loop[0-7]
[16:30] <smoser> it seems that with current precise kernel, we can have up to /dev/loop255
[16:30] <smoser> (previously that required adding 'max_loop=')
[16:31] <highvoltage> smoser: /etc/udev/links.conf
[16:31] <smoser> i dont have such a file
[16:31] <smoser> :)
[16:31] <smoser> maybe udev is responding to CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 (kernel config)
[16:33] <broder> smoser: iirc the loop module does that on its own at load
[16:33] <smoser> its builtin now. so it just must be the kernel adding devices on the initialization of that driver
[16:33] <smoser> and udev responding perhaps ?
[16:33] <broder> why does udev need to respond?
[16:33] <smoser> and the min being setup by that config.
[16:34] <smoser> broder, your suggesting it doesn't have to do anything because of devtmpfs ?
[16:35] <broder> my understanding was that device nodes are generally created by the kernel
[16:35] <smoser> (my knowledge is fuzzy here, but prior to devtmpfs i did not think that was the case)
[16:35] <broder> and then udev is just responsible for figuring out which modules need to be loaded so those modules can go and create the device nodes themselves
[16:37] <smoser> well, prior to devtmpfs, /dev was either a general tmpfs or a "normal(ext3)" filesystem  (or devfs) so the kernel wasn't just creating nodes int he filesystem.
[16:38] <broder> smoser: you can see the loop driver creating the nodes when it initializes: http://lxr.linux.no/linux+v3.2.2/drivers/block/loop.c#L1813
[16:38] <broder> i couldn't tell you how exactly it does it, but it definitely does
[16:47] <pgraner> cjwatson, quick question, have you seen 11.10 server iso issues when booting from USB stick, it boots but won't find the cdrom drive
[16:47] <pgraner> cjwatson, which is a strange since it doesn't have one on this box
[16:48] <cjwatson> pgraner: can I have logs please?
[16:48] <pgraner> cjwatson, sure which ones?
[16:49] <cjwatson> syslog and partman
[16:49] <cjwatson> well actually just syslog for this I guess
[16:49] <pgraner> cjwatson, ack
[16:49] <cjwatson> also does precise work?
[16:53] <pgraner> cjwatson, haven't tried precise yet, I was installing and they planning on testing the upgrade :(
[16:53] <pgraner> cjwatson, ok so I have no network and it won't see USB sticks
[16:54] <cjwatson> well I need some way to see what's going on
[16:54] <pgraner> cjwatson, the error is: cdrom-detect: CD-ROM mount failed: device=/dev/sr0 fstype=iso9660
[16:54] <cjwatson> you could try booting the precise installer and walking through the installer up to that point, you don't have to actually do an install
[16:54] <cjwatson> mm, usually need a screenful of context
[16:55] <pgraner> cjwatson, ok I'll snap a pic
[16:55] <cjwatson> also how did you create the USB stick?
[16:55] <pgraner> cjwatson, dd
[16:55] <cjwatson> ok
[16:56] <cjwatson> from tty2, run 'list-devices maybe-usb-floppy; list-devices usb-partition'
[16:57] <pgraner> cjwatson, both return no output
[16:57] <cjwatson> well that sucks.  does the kernel actually know about any USB devices?
[16:58] <pgraner> cjwatson, its sees the keyboard & mouse
[16:59] <pgraner> cjwatson, not the usbstick
[16:59] <pgraner> cjwatson, email sent with screen shot
[16:59] <cjwatson> try booting a live CD and see what driver it uses for the USB stick
[16:59] <cjwatson> er a live USB stick
[17:00] <cjwatson> the kernel packaging needs to deliver that to the installer in some appropriate udeb
[17:00] <pgraner> cjwatson, ok let me get one downloaded and I'll give it a shot
[17:02] <cjwatson> looking specifically for the ones in usb/host I guess
[17:29] <pgraner> cjwatson, ok booted,  and it looks like the livecd is using xhci-hcd
[17:35] <cjwatson> pgraner: ok, so I think the right answer is to file a kernel bug asking them to add xhci-hcd to the usb-modules udeb (I checked; it isn't there)
[17:36] <pgraner> cjwatson, ack, thanks
[17:55] <vanhoof> pgraner: what did you have going on w/ usb3?
[17:56] <bdmurray> jodh: bug 916507 looks like it is similar to bug 849414
[17:56] <vanhoof> pgraner: been seeing a few machines lately when usb3 is set to "auto" mode in the bios, it'll default to usb2, but when set to "enabled" it'll go usb3
[18:00] <pgraner> vanhoof, the server iso doesn't have xhci in the usb-modules udeb so you can't install off a usb3 port from usb stick
[18:06] <vanhoof> pgraner: ah
[18:07] <vanhoof> pgraner: see if usb3 work for you once installed too
[18:07] <astraljava> stgraber: Hiya, Studio wants to create a similar feature in ubiquity, that edubuntu uses. My problem is that I can't find the original source branch, that stores the ubiquity/plugins/*.py files. If you have time at some point, could you point me to the right tracks, please? Thanks!
[18:07] <vanhoof> pgraner: and if not, see if you have that same bios toggle
[18:07] <vanhoof> pgraner: been coming up in a few new bugs this week
[18:07] <astraljava> Well, Studio as well as Xubuntu.
[18:08] <stgraber> astraljava: the package selection stuff is in edubuntu-live
[18:09] <astraljava> stgraber: lp:ubuntu/edubuntu-live? I was just told that it gets created on upload. So I don't get where the upload gathers the stuff from.
[18:10] <stgraber> astraljava: that's indeed the branch. It's a UDD branch, uploads are automatically commited to it and people with upload rights can also commit changes to it without uploading
[18:11] <astraljava> stgraber: Ok, so how would Studio and Xubuntu get similar branches, then? I see that that branch is owned by Ubuntu branches (team?).
[18:12] <stgraber> astraljava: http://developer.ubuntu.com/packaging/html/udd-intro.html
[18:12] <stgraber> astraljava: for now, just copy the python scripts to your own package, that's the easiest
[18:13] <astraljava> stgraber: Ok, thanks!
[18:17] <pgraner> vanhoof, will do
[18:53] <arges> cyphermox, hello! are you the patch pilot today?
[19:01] <cyphermox> arges: I am
[19:02] <cyphermox> @pilot in
[19:04] <arges> cyphermox, so I think I got almost everything needed for an SRU here: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/828731  . was wondering if you could take a look and see if it looks ok.
[19:09] <cyphermox> arges: alright
[19:10] <arges> cyphermox, thanks
[19:23] <cyphermox> arges: so, comments:
[19:24] <cyphermox> arges: bug 828731 was needing ubuntu-sru subscribed, I added it. I can't upload kexec-tools though, so I'll have to defer to somebody else to sponsor it, but it looks correct (and has apparently already had testing)
[19:25] <cyphermox> arges: however, you're also closing bug 785425 in your changelog, so that one too should have ubuntu-sru subscribed, with an SRU rationale, and targetted to the releases
[19:25] <arges> cyphermox, ok i will check that too. how do I have ubuntu-sru subscribed?
[19:26] <cyphermox> on the lp page, click subscribe someone else and search for ubuntu-sru
[19:26] <arges> ok
[19:36] <jodh> bdmurray: thanks for pointing that one out. I'm pretty sure all these plymouth bugs have a common cause.
[20:13] <Atlantic777> Are ubuntu testing and ubuntu development the same release?
[20:15] <cyphermox> Atlantic777: yes
[20:16] <cyphermox> We're testing a milestone of the development release
[20:16] <Atlantic777> So 12.04 is the newest release I can get?
[20:16] <Atlantic777> actually it's not a release until it's released :D
[20:17] <cyphermox> It is, though you should really only "use" it if you're confortable with things breaking every once in a while
[20:17] <cyphermox> Atlantic777:  unless you want to help with the testing, in which case I'd invite you to join #ubuntu-testing
[20:18] <Atlantic777> cyphermox: I'm interested both in testing and development of new ubuntu stuff...
[20:18] <cyphermox> you're at the right place.
[20:19] <cyphermox> if you want to learn how to do it then visit #ubuntu-classroom, this week it's Ubuntu Developer Week and we show how you can fix things
[20:20] <Atlantic777> I'am already there. :)
[20:21] <cyphermox> sorry, I didn't see ;)
[21:13] <doko> zul, keystoneclient ftbfs
[21:13] <zul> doko: damn it...
[21:14] <zul> doko: ill get to it tonight
[21:14] <doko> zul: disable the argparse check. it's included in python2.7
[21:14] <zul> doko: yeah
[21:35] <simmel> SpamapS: That's kind of why I didn't ask the question during the talk also = )
[21:35] <SpamapS> simmel: CDBS stands alone, without debhelper, though it can help with debhelper rulesets. The key there is, with debhelper 7, thats not necessary
[21:36] <directhex> cdbs /o\
[21:36] <SpamapS> simmel: http://en.wikipedia.org/wiki/Debhelper
[21:36] <SpamapS> simmel: see the 3 line rules file? That is a new thing.. before that, CDBS was the quickest way to be able to have something similar.
[21:39] <SpamapS> simmel: I have to run now, but I'm sure you'll find lots of people who can help here. :)
[21:39]  * simmel gets confused with the debhelper.mk in CDBS and actual debhalper.
[21:39] <simmel> SpamapS: Thanks again.
[21:40] <jtaylor> those small rules usually go by the name dh-7
[21:40] <directhex> dh7 \o/
[21:41] <jtaylor> saying only debhelper is a bit confusing as most of cdbs also calls dh_* stuff
[21:41] <jtaylor> just all hidden in undocumented black magic
[21:42] <slangasek> we should just start calling cdbs 'debhinderer' ;)
[21:42] <simmel> It's not black magic if you know how to use it ; )
[21:44] <simmel> One other reasons that I'm confused is because https://wiki.ubuntu.com/PackagingGuide/Complete mentions CDBS alot and not any mention that it shouldn't be used.
[21:45] <slangasek> yes, not distinguishing between best practices and "things you have to deal with if you're going to be an Ubuntu developer" is a major failing of the documentation
[21:46] <simmel> https://wiki.edubuntu.org/PackagingGuide/Python#The_debhelper_way looks preetty good though.
[21:47] <slangasek> https://wiki.ubuntu.com/PackagingGuide does say to use http://developer.ubuntu.com/packaging/html/ instead
[21:48] <slangasek> we should probably nuke /Complete, at this point
[21:48] <simmel> Oh! Is there a Complete/All-pages version of that? Except Show source?
[21:49] <slangasek> I'm not sure
[21:49] <slangasek> barry: hey, do you know if there's a pdf version of http://developer.ubuntu.com/packaging/html/ ?
[21:49] <simmel> Sorry for beeing lazy here, totally OK to reprimand me, but was debhelper >= 7 available in lucid or earlier or is it a new thing?
[21:50] <jtaylor> its available in lucid
[21:50] <simmel> cool, thanks jtaylor.
[21:50] <barry> slangasek: i don't, but it wouldn't be hard to generate, from the trunk branch (`make pdf` should do it).  i can check, since i'm updating that branch for the new udd stuff as we speak (i have a session tomorrow)
[21:51] <simmel> I will discuss this with my colleagues tomorrow and see if we can't use the new debhelper way. Also, probably should fix our Hudson buildslaves to use sbuilder instead of pbuilder too = )
[21:51] <barry> slangasek: make latexpdf
[21:51] <simmel> barry: Is there a single .html-file available aswell? Or is .txt and .pdf the only single-page versions?
[21:53] <barry> simmel: it's sphinx so there are several options.  bzr branch lp:ubuntu-packaging-guide then run 'make' no options to see what you can generate
[21:53] <simmel> barry: Thanks, I'll check it out tomorrow. Thanks everyone and good night.
[21:55] <poolie> hi barry
[22:18] <barry> poolie: hi
[22:35] <cyphermox> @pilot out
[22:36] <cyphermox> logging off for dinner, I'll be back in a few hours and do more piloting
[23:23] <lamont> ScottK: 2.9.0, eh?
[23:23] <lamont> guess I have something to do later this week
[23:58] <lifeless> barry: can land plox http://bugs.python.org/issue6598