[00:03] <micahg> SpamapS: need something approved?
[00:06] <SpamapS> micahg: not urgently
[00:06] <micahg> there are quite a few items that need attention, I'm happy to push something through so it's available for 12.04.1 though
[00:07] <SpamapS> micahg: no its not for 12.04.1 .. just some stuff to make things better for juju users.
[00:08] <micahg> well, it obviously wouldn't be in the point release, but I'm saying to have it available when LTS users upgrade
[00:08] <micahg> anyways, feel free to file the requests, poke if they're not addressed within a reasonable amount of time
[00:12] <SpamapS> https://bugs.launchpad.net/ubuntu/precise/+source/txaws/+bug/945176
[00:12] <SpamapS> micahg: testing is all done, it should be in good shape
[00:14] <micahg> SpamapS: ok, looks good, in the future, it might be easier to use the requestbackport script so that you can clearly mark things as tested
[00:16] <SpamapS> micahg: sure, this was a case where I already had a bug report that is really a feature request so just felt it was easier to open a task
[00:23] <micahg> SpamapS: one quick question, did you test build juju against the backported txaws?
[00:23] <SpamapS> micahg: thats the last thing I uploaded
[00:23] <SpamapS> https://launchpadlibrarian.net/112145340/buildlog-juju-precise-backported-txaws.txt
[00:24] <micahg> SpamapS: ah, sorry, indeed, BTW, are you full AA enough to accept (it's sitting in unapproved)
[00:24] <SpamapS> micahg: I've never been officially blessed for full AA work, so I'll let it be. But thanks!
[02:56] <ScottK> Looks like someone else got it.
[03:30] <slangasek> hallyn: ping
[04:07] <hallyn> slangasek: hey
[04:16] <hallyn> good night
[05:09] <slangasek> hallyn: bah, sorry I missed you
[05:11] <slangasek> hallyn: this was regarding /dev/console being a symlink to /dev/lxc/console... when you say /dev/lxc/console is a bind mount from devpts, you mean the (major,minor) will be those of a pty (136,n) rather than (5,1)?
[05:12] <slangasek> stgraber: ^^ if you're around and know the answer :)
[12:15] <sveinse> building protobuf (2.4.1-1ubuntu2) from precise  failed when I run dpkg-buildpackage -b -uc -us. I got "Makefile.am:84: Libtool library used but `LIBTOOL' is undefined" when make check-local is run
[12:29] <Sweetshark> bug 1017125 just got a lot more sexy title ...
[12:31] <Sweetshark> ^^ are you maintaining a C++ package? fearzorz this bug!
[13:05] <stgraber> slangasek: that's correct, /dev/lxc/console is a pty (136, n)
[13:20] <stgraber> @pilot out
[13:34] <ogra_> NCommander, did you ever fix the broken flash-kernel upload to -proposed where you broke my changelog entry by omitting -v ? or do i need to dig up my bug and close it by hand now ?
[13:45] <zyga> doko, ping
[13:47] <hallyn> slangasek: right.  So neither /dev/console nor /dev/lxc/console will be (5,1), unfortunately
[13:53] <stokachu> hi, could i get some multi-arch clarification wrt libgnomevfs2-bin and whether Multi-Arch: foreign or Multi-Arch: same is the correct syntax? https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258
[14:08] <jamespage> infinity, nudge re bug 1028038
[14:08] <jamespage> any eta on when you might get to it?
[14:09] <stokachu> apw: pinGGG
[14:13] <seb128>  $ fakeroot dbus-launch dbus-monitor
[14:13] <seb128>  Failed to open connection to session bus: Did not receive a reply.
[14:13] <seb128>   
[14:13] <seb128>  does anyone know how to workaround that?
[14:14] <apw> seb128, hi
[14:15] <seb128> apw, hey
[14:15] <apw> seb128, bah got all distracted, wanted someone else, soz
[14:15] <apw> stokachu, hi
[14:15] <seb128> no worry ;-)
[14:16] <stokachu> apw: hey there.. wrt to https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Basics, i set a squid-deb-proxy but will it be used in chroots that weren't built with the proxy prepended?
[14:17] <apw> stokachu, you either need to use http_proxy= when you build it or do the equivalent of installing squid-deb-proxy-client within it
[14:17] <stokachu> apw: gotcha
[14:21] <doko> zyga, pong
[14:22] <zyga> doko, https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1026723
[14:23] <zyga> doko, would you mind weighting in on that issue?
[14:23] <zyga> doko, I've pinged barry about it a while ago and he sent me to you
[14:23] <jodh> hallyn: I've just tested with lxc and Upstart attempts to mount /dev due to /dev/console, but it's non-fatal. Are there any options for handling this aside from an extra check to see if /dev/console exists with major 136?
[14:30] <jamespage> stokachu, you should be able todo that pretty easily - if you drop this - http://paste.ubuntu.com/1134352/
[14:30] <jamespage> into /etc/apt/apt.conf.d in the source schroot it will use squid-deb-proxy locally
[14:32] <stokachu> jamespage: ah awesome, thanks!
[14:33] <jamespage> stokachu, note you can also use the --debootstrap-proxy= argument to mk-sbuild to specify a proxy
[14:33] <hallyn> jodh: well, a devices namespace :)  which would map 5,1 in containet to 136,X on host
[14:34] <hallyn> jodh: if it's non-fatal, that's great.  actually that might be bc apparmor refsued the mount
[14:34] <hallyn> so a container with lxc.aa_profile = unconfined might mess up
[14:35] <hallyn> jodh: what is the exact requirement?  You want devtmpfs mounted if any core device is messed up?  It just seems draconian and system-D ish right now
[14:35] <hallyn> oh, also i guess a boot argument (nodevtmpfs) could work
[14:35] <jodh> hallyn: this all started when we added job logging; that requires /dev/pts and /dev/ptmx.
[14:35] <jodh> hallyn: no problem, until users started to boot without an initramfs ;)
[14:35] <hallyn> jodh: so /dev/console could just be ignored?
[14:36] <hallyn> jodh: also, have you checked that /dev/ptmx as a file bind-mounted from /dev/pts/ptmx works? a nd as a symlink?
[14:36] <hallyn> bc those are all valid.  i don't think you were using lstat
[14:39] <jodh> hallyn: as slangasek noted, we're trying to avoid this bug fix blossoming into a monster. However, we are attempting to ensure a minimally sane environment in the initramfs-less case.
[14:40] <hallyn> jodh: how does 'nodevtmpfs' upstart cmdline option sound?
[14:40] <hallyn> or, it could check for the established 'container=' env variable
[14:45] <jodh> hallyn: I guess a new cmdline option would make sense - could you raise a bug on this please?
[14:49] <hallyn> jodh: i'll just wait to see if it breaks when it hits the archive?  :)
[14:49] <hallyn> you say it worked for you, so mayb ei'm making noise over nothing
[15:01] <hallyn> jodh: then again i'll raise a bug now
[15:02] <hallyn> slangasek: I have a qemu-linaro package in ppa:serge-hallyn/virt which is built to enable virtfs (for 9pfs) in kvm-spice.  If/when you get a chance could you take a look and see if you're ok with it for quantal?
[15:10] <slangasek> jodh: if /dev/console isn't guaranteed to have that major,minor in a container, we should back out the checks except for pts/ptmx.
[15:11] <hallyn> jodh: bug 1034023
[15:11] <jodh> slangasek: ok.
[15:11] <hallyn> slangasek: /dev/tty doesn't (afaik) ever get messed with
[15:11] <jodh> hallyn: thanks
[15:11] <hallyn> but yeah if that gets backed out we don't need new options :)
[15:11] <hallyn> thanks, ttyl
[15:12] <slangasek> hallyn: I have a bunch of work to do on qemu-linaro, which I'm going to try to get done this week
[15:16] <jodh> slangasek/hallyn: what about the mknods? remove the mknod(/dev/console) for lxc and keep the rest?
[15:16] <slangasek> jodh: yep
[15:18] <hallyn> slangasek: ok, my patch is tiny so trivially portable.  I jsut wanted to test-build it to make sure it sufficed.  thanks
[15:23] <jodh> slangasek/hallyn: https://code.launchpad.net/~jamesodhunt/upstart/bug-980917-the-bug-that-would-not-die/+merge/118579
[15:24] <jodh> ubottu: fail! ;)
[15:49] <tkamppeter> Someone know how one generates the Release and Release.gpg files in a deb package archive?
[15:55] <TJ-> tkamppeter: I was reading about this earlier. apt-ftparchive release
[15:55] <TJ-> tkamppeter: I found it here: http://wiki.debian.org/SecureApt#Setting_up_a_secure_apt_repository
[16:02] <seb128> Riddell, hi, can you update the lightdm packaging vcs with the diff of your update?
[16:03] <seb128> Riddell, there was a change pending upload there as well, any reason you didn't include it?
[16:03] <Riddell> seb128: mm sorry, I didn't notice it had a vcs branch, that was silly of me
[16:03] <seb128> Riddell, no worry, thanks for fixing it ;-)
[16:06] <tkamppeter> TJ, thank you very much.
[16:17] <ev> mpt: how should errors with individual reports be handled in the multiple reports dialog?
[16:17] <mpt> ev, you mean the process names, stacktraces etc?
[16:18] <ev> mpt: for example: "this problem report is damaged and cannot be processed", "the report belongs to a package that is not installed", or the generic "an error occurred while attempting to process this problem report"
[16:18] <mpt> oh, errors in the reports themselves
[16:19] <ev> yes
[16:19] <mpt> ev, so after you click either "Show Details" or "Continue", whoopsie discovers that sending the report will not be useful. Right?
[16:20] <ev> yes
[16:20] <ev> exactly at that point
[16:21] <mpt> ev, do you still want to send "something happened, but we don't know what" to the server for accounting purposes?
[16:21] <mpt> e.g. to measure the percentage of malformed reports over time
[16:22] <ev> you know what, I'm just going to walk around this desk
[16:37] <mpt> (Summary of desk conversation: we'll explain that the crash report was unreadable inside the details pane itself.)
[16:39] <mpt> ev, https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=89&rev1=88
[16:39] <infinity> tjaalton: What's the status of the xserver transition in -proposed?
[16:40] <ev> mpt: excellent, thanks
[16:42] <ev> mpt: if there's only one report and it's corrupted, should that "send an error report" checkbox disappear?
[16:42] <tjaalton> infinity: there'll be a fixed nvidia upload tomorrow, then maybe xserver 1.13rc3 and another round of quick tests
[16:43] <infinity> tjaalton: Alright.  Are all the drivers (including universe ones) transitioned?
[16:44] <mpt> ev, I don't think so, because (a) that would shrink the alert possibly several seconds after you last clicked anything, and (b) you may eventually be sending as much as you know anyway
[16:44] <ev> good points
[16:44] <ev> thanks
[16:45] <tjaalton> infinity: well, all the ones that xserver-video-all depends on it. I'll file an archive removal request for the rest, and check if there are others missing (like virtualbox..)
[16:46] <infinity> tjaalton: I don't see the ARM-specific ones there...
[16:47] <infinity> tjaalton: omap, msm-whateveritis, for instance.
[16:47] <tjaalton> infinity: ahh, duh
[16:48] <tjaalton> infinity: hmm actually, they probably need changes for the new abi, but I've no idea where to look for them
[16:49]  * infinity sees at least:
[16:49] <infinity> xserver-xorg-video-msm
[16:49] <infinity> xserver-xorg-video-omap
[16:49] <infinity> xserver-xorg-video-omap3
[16:49] <infinity> xserver-xorg-video-omapfb
[16:49] <infinity> For binary packages depending on xorg-video-abi-12
[16:50] <infinity> tjaalton: http://paste.ubuntu.com/1134575/
[16:50] <infinity> tjaalton: ^-- Might prove helpful?
[16:51] <tjaalton> infinity: maybe, if I knew how to read it :)
[16:51] <tjaalton> I know which ones to get rid of
[16:52] <tjaalton> ok
[16:52] <infinity> tjaalton: Those are just strict binary dependencies on the old ABI on each arch and in each component.
[16:52] <tjaalton> yeah
[16:52] <infinity> (-ivtv in multiverse seems to be another one I don't see in proposed)
[16:52] <infinity> Unless that's on the list of removals.
[16:57] <tjaalton> infinity: yeah, good point.. I do remember there being some issues with forgetting some of the drivers, so will be careful this time :)
[16:57] <blitzkrieg3> cyphermox: ping
[17:45] <ogra_> http://de.archive.ubuntu.com/ubuntu/pool/main/f/flash-kernel/flash-kernel_3.0~rc.4ubuntu15.dsc  416  Requested Range Not Satisfiable [IP: 141.30.13.10 80]
[17:45] <ogra_> wow
[17:57] <cyphermox> blitzkrieg3: pong.
[17:57] <cyphermox> sorry, I was out to lunch
[18:01] <blitzkrieg3> cyphermox: no problem at all
[18:02] <blitzkrieg3> cyphermox: I was wondering what our options are with the wpa enterprise bug
[18:02] <blitzkrieg3> bug 969343
[18:03] <jocarter> jono: so how is it that the next UDS is 4 days?
[18:03] <blitzkrieg3> cyphermox: I understand why you don't want to change the library in an LTS, but it seems like you can make it work if you disable the TICKET functionality in openssl
[18:04] <cyphermox> blitzkrieg3: I've had a lot of trouble verifying that
[18:04] <blitzkrieg3> hmm, so you've been testing with enterprise wireless and everything works?
[18:04] <cyphermox> that said, I can give it a shot this afternoon again, just means I need to change locations
[18:04] <cyphermox> blitzkrieg3: yeah, with my university network
[18:05] <blitzkrieg3> cyphermox: okay, that changes things
[18:05] <cyphermox> it was WPA-PEAP, with MSCHAPv2
[18:05] <blitzkrieg3> maybe we can get the same device that the OEM is using and verify
[18:05] <cyphermox> yeah
[18:05] <blitzkrieg3> I don't doubt that it's a problem with the device, not with ubuntu, but either way it looks like a regression from a user point of view
[18:05] <cyphermox> that might help, but I suspect it won't change a think, the encryption shouldn't be hardware-specific, since it's done in openssl
[18:06] <cyphermox> yup
[18:06] <blitzkrieg3> sounds like the hardware doesn't work well with new features, maybe it fails to account for stuff it doesn't know about
[18:06] <blitzkrieg3> cyphermox: I'll talk to the guy experiencing the issue, thanks for your help
[18:07] <cyphermox> but it's wifi hardware -- it doesn't need to know about encryption, just about pushing packets over the air and scanning
[18:08] <blitzkrieg3> so it's should be the software behind the AP that doesn't work?
[18:08] <cyphermox> blitzkrieg3: it's more likely to be an issue with the hardware used as an AP / the authentication server, which possibly uses a very different, very old version of SSL
[18:08] <cyphermox> yes
[18:09] <blitzkrieg3> got it, well we'll have to get those details then
[18:09] <cyphermox> that's been seen before -- I'm not against fixing it with changing the way wpasupplicant speaks to openssl, but I can't test this, so I'd rather not change things blindly
[18:09] <cyphermox> cool
[18:09] <blitzkrieg3> cyphermox: of course, I'll get all the info/HW we need to reproduce it in house
[18:10] <cyphermox> blitzkrieg3: great
[18:42] <kalxas> hi all
[18:42] <kalxas> I am trying to customize a xubuntu iso based on this https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations
[18:43] <kalxas> I was able to rebuild the initrd.lz file
[18:44] <kalxas> so that I have username and password set for the live session user
[18:44] <kalxas> but I am not succeeding in changing the background image
[18:45] <kalxas> can please someone give a hint on that?
[19:27] <stgraber> superm1: ping
[19:27] <superm1> hi stgraber
[19:28] <stgraber> superm1: you probably noticed that slangasek rejected your mythtv upload. He commented in bug 1029522 about it. Would be good if you could fix and re-upload soonish so we can have it in the point release.
[19:29] <superm1> stgraber: ah okay sure
[19:29] <slangasek> superm1: oh, you are around, just not on #-release - sorry, was lookin' for ya :)
[20:12] <mterry> zul, this is a pile of MIRs!  :-/
[20:12] <zul> mterry: sorry yeah i know
[20:12] <zul> mterry: on the good side most should be trivial :)
[20:13] <mterry> zul, haven't been bad so far
[20:13] <zul> mterry: all the new packages have been done with MIR in mind to make your life easier at least
[20:13] <mterry> zul, it's not relevant for these MIRs, but I notice you using debhelper 8 mode, instead of 9.  9's benefits are mostly cflags and multiarch related, so python doesn't care, but still.  Latest and greatest!
[20:14] <zul> mterry: yeah ill have a look again
[20:14] <mterry> zul, no reason to change unless you happen to be in the packages already.  Just something I noted, in case you missed compat mode 9 coming out  :)
[20:15] <zul> mterry: yeah thanks
[20:31] <slangasek> mterry, dupondje: have you seen the user comments in bug #1000356 that the bug isn't fixed?
[20:31] <slangasek> mterry, dupondje: unless there's something else I've overlooked, I believe this SRU should be removed from precise-proposed
[20:33] <mterry> slangasek, fair enough.  users certainly suggest it's not fixed
[20:33] <slangasek> mterry: yep.  libfreedp1 is the right binary package they need to upgrade for the fix, right?
[20:33] <slangasek> libfreerdp1
[20:36] <mterry> slangasek, I'm actually not sure off the top in which of the freerdp packages the fixed code lives.  But the same source package as libfreerdp1 yes
[20:37] <slangasek> mterry: well, I'm trying to pin it down to a binary package because there was some ambiguity on the part of the tester wrt which binaries they tested
[20:37] <mterry> slangasek, ok, let me see
[20:37] <slangasek> remmina-plugin-rdp only depends on libfreerdp1, so in the absence of other information to the contrary...
[20:38] <mterry> slangasek, yeah that's the package
[20:38] <slangasek> ok
[20:38] <slangasek> verification-failed, then
[20:38] <slangasek> too bad the test case requires windows :P
[20:50] <dupondje> hmz, highlight didn't work
[20:51] <dupondje> anyway slangasek
[20:51] <dupondje> it seems indeed its not completely fixed yet indeed. But the feedback is more then yes/no
[20:51] <dupondje> remmina 1024x768 -> rdesktop 1024x768 - seems to work fine now
[20:51] <dupondje> remmina 1024x768 -> rdesktop 800x600 - seems to work fine too
[20:52] <dupondje> in comment #12
[20:52] <dupondje> so it seems to fix some cases, but not all
[21:07] <slangasek> dupondje: oh, somehow I overlooked that.  Do you want to follow up to the bug pointing this out, and set the tag to verification-done instead?
[21:11] <dupondje> slangasek: done
[21:11] <slangasek> cheers
[21:12] <dupondje> still freerdp should release a new version :( tons of things fixed/improved, but no new release yet
[21:37] <anveo> Is this the correct channel for help with packaging?
[21:38] <ScottK> anveo: There are several possibilities depending on exactly what you're after.  This is one of them.
[21:39] <anveo> Well I'm trying to package the latest version of monit and put it in my ppa (which I just created) and I'm a little confused about the version string I'm supposed to use
[21:39] <anveo> I'm basically just taking the package which has been created for quantal, and making it work in lucid
[21:40] <ScottK> anveo: The best channel for that is #ubuntu-packaging.
[21:40] <anveo> oh, perfect. Thanks!
[22:12] <bdrung> here's a partial sponsors queue: http://people.ubuntu.com/~bdrung/sponsoring/
[22:13] <bdrung> (the sponsors queue is hit by bug #1031764)
[23:09] <stgraber> mterry: just saw your comment on the watch file in ltsp-docs, it's indeed quite pointless when we're in sync with Debian, though in the past it was quite useful for all the other LTSP packages
[23:10] <mterry> stgraber, yar, I figured it was for backporting ubuntu updates and such
[23:10] <stgraber> mterry: LTSP doesn't do real "upstream" releases, instead whenever a distro wants a tarball, they tag it upstream. So the only place where you can find an "upstream" tarball is in the distros.
[23:10] <mterry> stgraber, just not a construction I've seen before  :)
[23:10] <stgraber> mterry: that's why we typically watch the Debian and Fedora package archive in Ubuntu and the Ubuntu and Fedora archive in Debian
[23:11] <stgraber> so uscan can try to see if there's a newer tarball "somewhere"
[23:17] <mterry> zul, is there a missing MIR for python-quantumclient
[23:17] <mterry> ?
[23:18] <zul> mterry: im thinking python-cliff ill get to it tonight
[23:24] <mterry> zul, I'll pre-review it after python-clif
[23:29] <zul> mterry: k
[23:48] <mterry> zul, ah, I found the quantumclient MIR bug.  I just didn't see that didrocks had already commented on it
[23:49] <zul> mterry: ah k
[23:50] <ikepanhc> @pilot in