[04:11] <pitti> Good morning
[04:12] <nigelb> Morning!
[04:12] <pitti> mdeslaur, infinity: I can replicate the postgresql test suite failure on scheat
[04:12] <pitti> mdeslaur: do you still need some builds?
[04:16] <ajmitch> morning pitti
[06:02] <pitti> debfx: can you please reupload kde4libs with -v4:4.7.1-0ubuntu3 to include the previous -proposed changelog?
[06:12] <didrocks> good morning
[06:50] <ejat> pitti : u here ?
[06:51] <pitti> ejat: hello
[06:51] <ejat> pitti : just wanna check with u pgsql 9.1 package in lucid ..
[06:52] <ejat> doesnt have conf folder in /etc
[06:53] <ejat> just have /etc/postgresql-common not /etc/postgresql/9.1/main
[06:53]  * ejat we should i check? or should i reinstall ? 
[06:54] <ejat> where*
[06:55] <pitti> ejat: the /etc/ bits are not shipped in the .deb
[06:56] <pitti> ejat: if you install postgresql-9.1 from scratch, it will create a 9.1/main cluster through the postinst
[06:56] <pitti> ejat: but not on upgrade or if you already have some configuration bits there
[06:56]  * ejat fresh install lucid .. 
[06:56] <pitti> ejat: please have a look at /usr/share/doc/postgresql-9.1/README.Debian.gz
[06:57] <ejat> so need manual do the /etc ?
[06:57] <pitti> ejat: no, you shouldn't for a fresh install
[06:57] <ejat> but in natty it ship in the .deb right ?
[06:57] <pitti> no
[06:57] <pitti> we haven't shipped it in the .deb since sarge, and never ever in Ubuntu
[06:58] <ejat> owh ..
[06:58] <pitti> ejat: perhaps you can do
[06:58] <pitti> sudo apt-get purge postgresql-9.1
[06:58] <pitti> sudo apt-get install postgresql-9.1
[06:58] <pitti> capture the whole output
[06:58] <ejat> ok .. /me trying …
[06:58] <pitti> and put that inot a bug report?
[07:06] <ejat> ok .. thank pitti  .. its work after purge n reinstall …
[07:07] <ejat> just wondering y that could be happen?
[07:08] <pitti> the most likely cause is that there were some files left in /etc/postgresql/ from previous installations
[07:08] <dholbach> good morning
[07:13] <cousin_luigi> hello
[07:13]  * cousin_luigi has just a simple question: is gnome-session-fallback gnome3 based?
[07:24] <didrocks> cousin_luigi: yes, it's the gnome3 one
[07:24] <cousin_luigi> didrocks: gnome3 people are telling me it's unity-based
[07:25] <didrocks> cousin_luigi: they are wrong then, it's pure usptream one, we even didn't add indicators by default
[07:25] <ogra_> else it would be called unity-session-fallback, or ubuntu-session-fallback :)
[07:25] <cousin_luigi> didrocks: http://i.imgur.com/SWwLI.jpg <- it's this one
[07:25] <cousin_luigi> ogra_: I guessed as much:)
[07:25] <cousin_luigi> didrocks: may I quote you on that?
[07:26] <didrocks> cousin_luigi: sure, for the above bar though, it's a bug in appmenu-gtk, you need to remove appmenu-gtk to workaround it
[07:27] <didrocks> but then, you have the gnome-session-fallback experience
[07:27] <cousin_luigi> didrocks: appmenu-gtk, got it
[07:27] <cousin_luigi> didrocks: that's what I actually crave:)
[07:27] <didrocks> cousin_luigi: ok, without a screenshot, wasn't obvious ;-)
[07:34] <cousin_luigi> didrocks: Ok, removing both appmenu-gtk and appmenu-gtk3 did the trick. Do you think that glitch will be solved in 11.10 final?
[07:35] <didrocks> cousin_luigi: no, it's too late for finale, maybe in a SRU, better that you ping Cimi and tedg on #ayatana
[07:35] <cousin_luigi> didrocks: SRU?
[07:35] <didrocks> cousin_luigi: stable release update
[07:35] <cousin_luigi> ah ok
[07:35] <cousin_luigi> will do
[07:36] <didrocks> thanks :)
[07:38] <cousin_luigi> ok, I'm happy with my new desktop
[07:38] <cousin_luigi> thanks everyone
[07:38] <cousin_luigi> bbl
[08:34] <tgardner> pitti, sconklin was complaining to me last night that a bunch of kernel packages got copied to universe. 'rmadison -S linux|grep universe' shows some stuff that absolutely should be in main (like all i386/amd64 packages at least)
[09:03] <tumbleweed> broder: Worked out why my backports udd queries weren't getting verly far. Lany: Backports uploads don't appear to be imported. I'm guessing they don't hit -changes?
[09:07] <Laney> not sure
[09:08] <Laney> there were some manual ones lately
[09:08] <Laney> have a look at hardy-changes and see if you can see nginx
[09:08] <Laney> it might just be that no-change ones aren't announced, like syncs
[09:10] <Laney> seems not, file a soyuz bug?
[09:12] <tumbleweed> Laney: http://paste.ubuntu.com/707228/ yeah, I guess so. Obviously having -backports in ubuntu_sources is preferable, but this would be nice too
[09:13] <Laney> i think it would be nice to have both
[09:16] <tumbleweed> grumble, can't get to lp (ZA's international connectivity is pretty screwed right now, the big, cheap, undersea cable is down). I'll do it later...
[09:17] <Laney> in the meantime udd can be improved to pull from all pockets
[09:39] <debfx> pitti: ok, I have reuploaded kde4libs
[09:46] <tumbleweed> Laney: found bug 59443
[09:47] <Laney> weird
[09:48] <tumbleweed> basically they are currently purposely /dev/nulled
[09:48] <rye> may i draw some attention to the upgrade process - in case the upgrade from natty to oneiric is done via wifi, the whole process whill signal about the error since networkmanager disconnects wifi during upgrade (why?), and flashplugin fails to install due to missing network connection. This was filed as bug #859373 but I experienced this yesterday while upgrading my netbook
[09:48] <Laney> another fix is to make it use lplib instead of the mboxes
[09:49] <tumbleweed> Laney: if there's a way to do that efficiently...
[09:49] <Laney> but that is a pain because lp doesn't expose launchpad-bugs-fixed/closes so you have to parse the changelog yourself
[09:49] <tumbleweed> that too
[09:50] <tumbleweed> although, you can get at the changes file from the lp api
[09:50] <tumbleweed> (if there is one)
[09:50] <Laney> doesn't always exist
[10:03] <mvo> rye: hrm, this is a tricky one, let me have a look
[10:04] <rye> mvo, yeah, i was not able to reconnect to wifi, i am now writing a usb key to re-test this
[10:04] <pitti> sconklin: linux binaries in universe> ah, the LP randomness again :/ fixing..
[10:04] <pitti> debfx: thanks
[10:05] <pitti> sconklin: hm, which ones in particular? the hardy flavors have always been in universe; should linux-image-2.6.32-21-preempt be in main?
[10:09] <rye> mvo, basically there are 2 issues - 1 - wireless network drops during upgrade, 2 - flash player is unable to download and user finds installation to be interrupted. Outdated packages removal step is not run.
[10:10] <tkamppeter> pitti, can you have a look at bug 653132? The one where the original poster does not answer any more.
[10:15] <mvo> rye: thanks, it would be nice to know if NM always drops the connection and if it comes back once NM (or dbus even?)  is in "configured" state again
[10:15] <rye> mvo, this does not happen on wired connections though
[10:20] <mvo> rye: I see in the log that network-manager-pptp is used, did you use that as well?
[10:21] <rye> mmm is it ok that http://releases.ubuntu.com/ point to mirror.anl.gov? :)
[10:21] <rye> mvo, no, in my case it was a regular wifi connection with no vpn
[10:26] <cjwatson> rye: yes, over IPv6
[10:31] <debfx> pitti: could you please reject kde-runtime, I forgot to include the bug number in the changelog
[10:33] <infinity> debfx: Done.
[10:33] <debfx> thanks
[10:33] <infinity> pitti: I already fixed the kernel-in-universe thing, it was just waiting on the publisher to agree.
[10:34] <infinity> pitti: In fact, it seems to be fixed now.
[10:40] <pitti> ah, thanks
[10:59] <pitti> tkamppeter: still on my list (but I shouldn't be a bottleneck here, anyone can test this0
[11:47] <mdeslaur> pitti: hi! No, I got all the remaining builds switched to the old builders yesterday, so I'm good to release. We do need to get this sorted out before the next release though.
[11:54] <infinity> pitti: Do you have plans to debug the portgres issue on scheat?  If and when we ditch all the babbages, we kinda need psql to build/work.
[12:07] <pitti> infinity: yes, that's on my list
[12:21] <rye> mvo, if you are here - just started update to oneiric, nm applet has lost connection to NetworkManager
[12:21] <rye> mvo, any logs i can provide?
[12:22] <rye> mvo, nm-tool: WARNING **: _nm_object_get_property: Error getting 'WimaxHardwareEnabled' for /org/freedesktop/NetworkManager: (9) Property "WimaxHardwareEnabled" of interface "org.freedesktop.NetworkManager" isn't exported (or may not exist)
[12:22] <mvo> rye: cyphermox is probably interessted in this as well, so NM lost connection at what point? can you see if the network-manager package is currently being upgraded? or maybe dbus itself?
[12:22] <rye> i guess I need to file a separate bug
[12:23] <mvo> rye: do you use Wimax at all? I wonder if its a gconf -> gsettings migration issue?
[12:24] <rye> mvo, no i don't use wimax at all
[12:24] <rye> mvo, .xsession-errors are full of nm-applet-related messages
[12:24] <rye> but i can't pastebin :-/
[12:24] <mvo> rye: could you add them to the bugreport please? (once you get the network back)
[12:25] <rye> mvo, sure
[12:25] <mvo> ta
[12:27] <rye> mvo, hm, I see that NetworkManager pid is still 417 which may suggest it is the old one
[12:29] <rye> mvo ooh. NetworkManager[417]: <warn> error requesting auth for org.freedesktop.NetworkManager.use-user-connections: (0) GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.NetworkManager.use-user-connections is not registered
[12:30] <mvo> rye: that sounds like its the culprit!
[12:31] <rye> mvo, once nm gets this it shuts down the network connection :-/
[12:31] <smoser> is anyone able to run virtualbox on oneiric ?
[12:31] <rye> mvo, happens during install libnm-gtk-common
[12:31] <mvo> rye: do you mind if I paste some of this into the report?
[12:32] <rye> mvo, sure, i can create a new bug, i suppose if i restart NM i will get the network back
[12:32] <rye> mvo, the installation is supposed to keep networking, right? or we never promised that?
[12:33] <mvo> rye: cyphermox is probably a good person to look into a fix for this, but I think we should try to keep the network up as hard as we can
[12:33] <soren> smoser: I had the GUI up a couple of days ago. Didn't run any VMs, though.
[12:33] <mvo> rye: stuff like mscorefontsinstaller also need network to continue
[12:33] <soren> smoser: Is that a useful answer at all?
[12:33] <mvo> rye: plus there might be people doing remote upgrades
[12:33] <smoser> soren, not really. http://paste.ubuntu.com/707304/
[12:34] <rye> mvo, oooops... and things like landscape
[12:34] <rye> ok, got wired connection, going to pastebin everything
[12:34] <soren> smoser: Gimme a sec.
[12:35] <rye> .xsession-errors: http://pasteubuntu.com/707306/
[12:36] <rye> syslog: http://paste.ubuntu.com/707307/
[12:37] <rye> and dpkg.log: http://paste.ubuntu.com/707309/
[12:37] <rye> mvo, ^
[12:38] <mvo> rye: thanks a bunch, I wonder what package org.freedesktop.NetworkManager.use-user-connections is part of, maybe its enough to ensure its registed early enough
[12:40] <rye> well, i suppose not many people would want to remotely upgrade on wifi
[12:41] <rye> mvo, is there any place we can put this to errata or warning. Having people booooing the installer that upgrades and says "sorry, failed" w/o being able to direct them to a written word is something I'd like to avoid :)
[12:46] <mvo> rye: we can put the problem that NM may loose network connection during the upgrade and that makes flashplugin-downloader fail  into the release notes, skaet is currently preparing them for the final announcement afaik. I would absolutely want to fix this at the NM level if at all possible
[12:47] <rye> mvo, wireless only
[12:47] <rye> mvo, and, probably if vpn is used then it is also affected, the only way upgrade can finish properly is wired/direct
[12:50] <mvo> thanks rye, do you think you could write up a sentence or two for https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#Known_issues ?
[12:50] <rye> mvo, so the question is - should I file a new bug, detailing the network loss and make the flashplayer download failure a duplicate?
[12:51] <mvo> rye: I think we can keep the flasplugin one, I added a network-manager bugtask for it
[12:51] <rye> mvo, ok
[12:51] <mvo> rye: but if you prefer to create a fresh one, thats fine for me as well, it just sounds like unneeded work :)
[12:51] <soren> smoser: It totally crashed and took X with it when I tried to run anything.
[12:51] <smoser> soren, haha. you fell for my trap :)
[12:52] <rye> mvo, i forgot we can add bug tasks
[12:52] <smoser> nah... it doesn't start for me.
[12:52] <soren> Lucky.
[12:52] <smoser> refuses to start a vm.
[12:55] <smoser> soren, well, for me, i opened bug 873330
[12:58] <rye> mvo, I don't have access to edit that :(, "If you are using wireless connection during the upgrade, the network manager may disconnect the network resulting in some packages being incompletely installed. Please use wired connection (LP:859373)."
[13:16] <cyphermox> rye: mvo: looking at backlog now, what about network?
[13:16] <cyphermox> rye: is it still about your issue while upgrading?
[13:18] <dholbach> yeeeeeeehaw!
[13:18] <rye> cyphermox, it is now more than flashplayer, basically in case machine is using wireless network it will drop it during upgrade leading to package manager complaining that the install finished, but there were failures
[13:18] <mvo> cyphermox: check https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/859373/comments/7
[13:18] <rye> and yeah, CONGRATULATIONS on the release!
[13:19] <cyphermox> shouldn't be dropping while downloading stuff (or any time for that matter)
[13:19] <rye> cyphermox, no, it gets dropped when it upgrades nm stuff
[13:19] <pedro_> congrats all :-)
[13:19] <rye> cyphermox, i suppose VPN, Wireless and 3G connections are going to be disconnected, wired works
[13:20] <cyphermox> rye: which also shouldn't be happening; we don't even restart nm when we upgrade, precisely to avoid such issues
[13:20] <OdyX> Congratulations pals !
[13:20] <rye> cyphermox, i reproduced it twice, unfortunately
[13:20] <cyphermox> rye: oh, I believe you
[13:20] <cyphermox> rye: I'm just trying to think of what case would warrant this to fail
[13:20] <rye> cyphermox, you can see the logs and it looks like PolicyKit blocks something
[13:20] <cyphermox> I'll re-install natty on my system and give it another shot
[13:20] <cyphermox> yeah
[13:21] <rye> cyphermox, nm notices that and faints, bringing user's network down
[13:21] <cyphermox> rye: makes sense
[13:22] <cyphermox> rye: but why this bit in policykit fails doesn't
[13:22] <cyphermox> I'm rebooting my desk laptop now to try and reproduce this
[13:25] <pitti> is precise open for upload yet?
[13:25] <pitti> (SCNR)
[13:25] <pitti> congrats everyone!
[13:27] <OdyX> pitti: nah nah nah, first help me refactor the printing stack. /me hidz.
[13:27] <pitti> heh
[13:31] <siretart> congratulations!
[13:31] <akgraner> Thanks y'all!  :-)  Loving the new release :-)
[13:31] <ogra_> AN IT LOVE YOU !!!
[13:31] <ogra_> *loves
[13:31] <ogra_> geezy, my typing ...
[13:32] <ogra_> infinity, so where can i download the precise armhf images now ?
[13:32] <ogra_> *g*
[13:35] <sladen> just updated and rebooted.  Can't get past GDM now
[13:35] <sladen> X died and takes me back to GDM after a few seconds
[13:35] <sladen> can't get LightDM to come up at all
[13:35] <sladen> bryceh: ring any bells?
[13:59] <sladen> bryceh: ah, full / partition
[14:20] <cyphermox> rye: ok, I understand the issue now
[14:24] <rye> cyphermox, yeah, and cleanup process does not finish, to a casual user it looks like the upgrade failed
[14:24] <cyphermox> rye: does it?
[14:24] <cyphermox> is it completed at that point?
[14:26] <rye> cyphermox, yes, basically the system is in usable state, but the dialogs are all telling about incomplete upgrade. I don't know what post-insall routines are running after upgrade though. After reboot the network is working
[14:26] <cyphermox> ok
[14:28] <cyphermox> the issue is that we no longer ship the use-user-connections policy and at that point NM isn't yet restarted so it hasn't migrated configs
[15:01] <mvo> cyphermox: could we continue shipping this policy as a workound for the bug?
[15:02] <cyphermox> mvo: that's exactly what I'm working on now, I just want to test to make sure it fixes the issue before the system is rebooted after upgrade
[15:02] <cyphermox> mvo: I've already sent a text for a release note entry to skaet
[15:03] <mvo> cyphermox: thanks, you rock :)
[15:04] <cyphermox> mvo: not enough yet :)
[15:23] <Riddell> mvo: btrfs causing upgrade breakage? bug 873411
[15:25] <mvo> Riddell: meh, apparently :/
[15:25] <mvo> Riddell: I ask for more info
[15:27] <cyphermox> mvo: you responsible for the (I'll say new because I never noticed that before) large upgrade overview window that opens? Here I just can't click "Ask me later": it doesn't react
[15:28] <mvo> cyphermox: anything in ~/.xsession-errors when you do that?
[15:28] <cyphermox> I'll check in a second; maybe it's also just missing updates since I only just installed natty on that system
[15:30] <cyphermox> mvo: http://paste.ubuntu.com/707399/
[15:31] <mvo> thanks cyphermox
[15:36] <slangasek> stgraber: ping
[15:37] <mvo> cyphermox: fyi https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/873424
[15:38] <stgraber> slangasek: pong
[15:38] <cyphermox> ah, fun
[15:38] <doko> pitti, uploads should be possible, will land in unapproved for precise
[15:39] <slangasek> stgraber: hi there!  release is out, time to get to work on the next one right? :)
[15:39] <pitti> doko: oh, wow! was really more of a mock question, but great; I'll upload cdbs/debhelper
[15:39] <stgraber> slangasek: sure :)
[15:39] <slangasek> stgraber: I've been playing a bit more with this ubiquity-dm/plymouth bug in the background over here
[15:39] <ogra_> slangasek, wheer are the images, i want to test !
[15:40] <stgraber> slangasek: is it still broken?
[15:40] <pitti> heh, the second doko mentioned it, https://launchpad.net/ubuntu/precise/+queue?queue_state=1 got filled with 5 more packages :)
[15:41] <slangasek> stgraber: so what I've found by capturing that process list is that neither ubiquity-dm *nor* the X server has actually exited when expected... I think there may be two parts to this issue. 1) instead of server.terminate() like you used in the signal handler, we're calling kill_if_exists(server.pid, signal.SIGTERM) before calling reboot... I don't know if that's supposed to do the same thing, but it doesn't seem to actually work?  2) the
[15:41] <slangasek> ... signal handler doesn't actually exit ;)
[15:41] <cjwatson> please don't go accepting uploads yet though
[15:41] <cjwatson> (-> archive admins)
[15:42] <slangasek> stgraber: but it's slow to iterate because we only hit the 'reboot' call in ubiquity-dm at the end of an install... if you can suggest a way to short-circuit this, that would speed up the debugging
[15:42] <cyphermox> mvo: if I may add something, the release notes button also doesn't really send one to the release notes page, but rather to a wiki-syntax document on archive.u.c which contains the same text as the check-new-rellease-gtk presents; I'll open the bug report
[15:43] <stgraber> slangasek: oh right, having a sys.exit(0) in there sounds useful :)
[15:45] <stgraber> slangasek: in theory, the current kill_if_exists should be equivalent to .terminate() (wasn't quite sure of the reason behind that function as terminate()'s behaviour is identical)
[15:45] <stgraber> slangasek: having the .wait() shouldn't make much difference either...
[15:47] <slangasek> shouldn't it?  does .terminate() already wait?
[15:48] <cjwatson> don't underestimate the possibility that I might not have known about a library function when I wrote something
[15:48] <stgraber> no, my understanding is that terminate() doesn't wait, it just sends SIGTERM if the process still exists
[15:48] <stgraber> cjwatson: it's a >= 2.6 feature, that probably explains it
[15:50] <cjwatson> ah, yes, could be
[15:54] <stgraber> slangasek: could it be that SIGTERM isn't enough for X to die?
[16:02] <stgraber> slangasek: ok, quick test shows that X dies on SIGTERM, so that's not the problem (at least in a VM). Not sure why X is still running then
[16:08] <jbicha> is there a chance that we could use xz by default for Precise packages?
[16:09] <seb128> jbicha, define by default?
[16:09] <seb128> jbicha, you can use .xz, soyuz handle it fine
[16:09] <cjwatson> jbicha: no
[16:09] <jbicha> well we use bz2 now right? and xz is just opt-in
[16:09] <seb128> jbicha, i.e GNOME will likely use .xz
[16:09] <cjwatson> such a change would be inappropriate in an LTS cycle
[16:09] <seb128> Debian is already switching to it
[16:09] <cjwatson> you are welcome to do it in individual packages
[16:10] <jbicha> cjwatson: do you know of any specific breakage it would cause?
[16:10] <seb128> Debian -> Debian pkg-gnome
[16:10] <cjwatson> jbicha: that is not the relevant standard
[16:10] <cjwatson> and yes actually I do
[16:10] <cjwatson> it would break debootstrap
[16:10] <cjwatson> even if we fixed that it would render debootstrap non-portable
[16:10] <seb128> just curious, but what do we call "default" there?
[16:10] <jbicha> ok, just thought I'd ask those who knew instead of proposing it to a mailing list
[16:11] <cjwatson> jbicha: there was a discussion on debian-devel not that long ago
[16:11] <cjwatson> seb128: dpkg's default
[16:11] <seb128> oh ok, I was on orig uploads, ignore me ;-)
[16:11] <jbicha> I should probably subscribe to that list too
[16:11] <cjwatson> welcome to do it in individual packages> as long as they aren't part of the base system, that is
[16:12] <jbicha> I believe Fedora does it for their RPMs and there are always questions about how we can squeeze out a little more space on the CDs
[16:12] <cjwatson> mostly we care about the desktop CD now and .deb compression is mostly irrelevant there.
[16:12] <cjwatson> and xz-ing the squashfs makes it non-rsyncable which is a huge QA pain.
[16:12] <jbicha> cjwatson: by base system you mean the low-level plumbing? I set ubuntu-docs to xz for instance
[16:13] <slangasek> stgraber: SIGTERM> sure, anything's possible.. I don't think I'll test that one on my running X server, however ;)
[16:13] <cjwatson> jbicha: base system == anything installed by debootstrap
[16:13] <cjwatson> ubuntu-docs is not that
[16:13] <jbicha> ok, thanks for answering :)
[16:14] <slangasek> stgraber: I think what would help most is if someone could give me a way to short-circuit ubiquity - e.g., causing it so clicking on the 'install' button causes an immediate sys.exit(0) so I don't have to go through the tedious install-to-disk process
[16:15] <slangasek> stgraber: btw, what I have also noticed is that as soon as the ubiquity job enters state 'stopping' (i.e., before the process is even signalled), this unblocks kdm - which means that in the normal shutdown case we absolutely have to make sure we kill the X server *before* calling reboot
[16:15] <dobey> is precise archive up already such that we can upload to it?
[16:15] <cjwatson> dobey: you can upload, it'll be a while before it's acceptedthough
[16:16] <slangasek> (from what I see, kdm also changes to target 'stop' at the same time so it doesn't spawn another X server or anything, but it *does* cause plymouth to start immediately thereafter)
[16:16] <dobey> cjwatson: ah ok. just started seeing precise packages on launchpad /ubuntu/+source/foo pages. :)
[16:16] <tkamppeter> pitti, bug 653132 isverified by larsu.
[16:17] <cjwatson> dobey: mostly copies as a result of initialisation
[16:17] <pitti> tkamppeter: ah, great
[16:18] <dobey> cjwatson: yeah. was just checking to see if our oneiric SRUs made it to -updates yet and saw it so wondered if was usable yet. :)
[16:18] <cjwatson> it isns't
[16:18] <dobey> yep, thanks
[16:25] <pitti> dobey: btw, in the first couple of days we'll just copy SRUs to both oneiric-updates and precise
[16:25] <pitti> so no need to worry about the "needs fix in dev release first" part
[16:27] <dobey> pitti: not worried about that really. just curious, as We want to make a consistent release plan for u1 :)
[16:30] <tkamppeter> pitti, could you already pass the fixes of bug 653132 and bug 860691 to -updates as for CUPS the next SRU is already queued and for system-config-printer I am already preparing a new one. Thanks.
[16:32] <pitti> tkamppeter: can do some tomorrow morning, I'm running out for today
[16:33] <tkamppeter> pitti, OK, then tomorrow morning.
[16:33] <slangasek> cjwatson: how long do I have to wait before I delete ia32-libs from precise? ;)
[16:34] <cjwatson> slangasek: you can do it now
[16:34] <slangasek> whooo
[16:36] <infinity> slangasek: What do we plan to do about lucid->precise migration for people with ia32-libs installed?
[16:36] <slangasek> oh, spoilsport
[16:37] <infinity> I know.
[16:37] <infinity> I hate me too.
[16:37] <slangasek> ok, then I can immediately convert it into an empty package depending on ia32-libs-multiarch, have ia32-libs-multiarch depend on all the libs currently included, and just let it be uninstallable until they're all converted?
[16:38] <infinity> That sounds vaguely reasonable.
[16:38] <slangasek> infinity: don't you have a gzip bug to catch :-P
[16:38] <infinity> I thought that was your baby.
[16:38] <slangasek> oh btw, what's the verdict on plymouth hating everyone you work with?
[16:38] <infinity> Also, I have parties to attend and such.
[16:38] <slangasek> :-)
[16:38] <infinity> To be fair, it hates people I don't work with as well.
[16:39] <infinity> And I couldn't find a magical combination of anything that could give David both a console and X.  I'm less convinced that it's your problem, and more convinced that it's just kernel+nvidia = ha ha ha for consoles right now.
[16:39] <infinity> I'll make sure he files bugs, though.
[16:39] <slangasek> ok
[16:39] <slangasek> kernel+nvidia is working perfectly fine here for me
[16:39] <infinity> I'd love to know how.
[16:40] <slangasek> so it's either specific to the card, or specific to the exact nvidia driver package he has installed
[16:40] <infinity> Though his system could be uniquely special.
[16:40] <slangasek> (is he using nvidia-current, or one of the legacy ones?)
[16:40] <infinity> current.
[16:40] <slangasek> how about Daviey's issue?  I haven't seen a bug for that either
[16:40] <slangasek> Daviey: you owe me a bug for your plymouth problems :)
[16:40] <infinity> I didn't really look at his.  I'll ask him to file a bug too.
[16:41] <infinity> I don't work for Daviey, he can deal with his own crap. :P
[16:41]  * Daviey perks up
[16:42] <slangasek> Daviey: infinity claims that plymouth doesn't give you love on your system; I don't believe such claims until I see the bug reports :)
[16:42] <Daviey> slangasek: I don't have plymouth problems, i have "my boot experience sucks" problems.
[16:42] <slangasek> oh
[16:42] <slangasek> what is your boot experience?
[16:43] <Daviey> slangasek: >4 mins to lightdm.. with nothing to look at.. i want some plymouth prettyness,.
[16:43] <Daviey> I also have no tty's.
[16:43] <slangasek> oh, really
[16:43] <slangasek> I'd ask you to send me a boot chart, but I remember how that went last time
[16:43] <Daviey> They are there.. ie, if i login blind, i can restart processes.
[16:43] <slangasek> right
[16:44] <slangasek> please 'ubuntu-bug plymouth' me
[16:44] <Daviey> for soley no theme on boot?
[16:44] <slangasek> yes
[16:45] <slangasek> frankly I'll probably wind up triaging it off somewhere else, but I know the plymouth apport hooks give me the info I need in order to do that :)
[16:48] <Daviey> slangasek: bug 873475
[16:49]  * Daviey wonders if slangasek will shout at him for his grub config
[16:49] <slangasek> Daviey: we shall see! :)
[17:09] <slangasek> Daviey: cool, you have the same issue as davidm
[17:29] <slangasek> Daviey: entirely unrelated, but you might want to clean out /etc/udev/rules.d/86-hpmud-*: your boot.log is full of udev noise due to deprecated syntax
[17:30] <slangasek> Daviey: I can confidently say that this is Not My Fault, as you're using uvesafb ;)
[17:45] <dobey> hrmm
[17:46] <dobey> what is the .pc/ directory and having patches applied within the bzr branch for a package nonsense for?
[17:47] <chrisccoulson> heh, that's the main reason i hate full source branches
[17:48] <dobey> chrisccoulson: the u1 packages don't do this
[17:48] <dobey> afaik
[17:48] <SpamapS> some do, some don't
[17:48] <slangasek> cjwatson: what causes gfxterm to be set by default in grub2?  I can't work out where it comes from
[17:48] <SpamapS> its madness, IMO
[17:49] <dobey> SpamapS: can we make it so that none do?
[17:49] <slangasek> cjwatson: ah, n/m, just found it... what alternatives are there, though?
[17:50] <SpamapS> dobey: I believe it just depends on the source package settings
[17:50] <dobey> masochism=True?
[17:51] <slangasek> cjwatson: ignore that question too ;)
[17:51] <SpamapS> dobey: debian/source/local-options you can put 'unapply-patches'
[17:52] <SpamapS> dobey: there are severely differing points of view on this.. some like that the changes are bzr-managed for annotate/bisect/etc.
[17:52] <dobey> SpamapS: it's a debuild thing rather than a bzr-builddeb thing?
[17:53] <SpamapS> well bzr-builddeb just calls the same things as debuild.. so.. yes
[17:53] <SpamapS> dobey: I find it maddening done either way... and prefer unapplied.. but I've learned to just deal. :p
[17:54] <dobey> well there's nothing in debian/ to indicate it should be this way.
[17:54] <dobey> it is beyond maddening
[17:55] <SpamapS> I believe its just the default for dpkg-source to apply them
[17:55] <SpamapS> so the importers do it
[17:56] <dobey> weird
[17:57] <dobey> ah, so it seems to be
[17:57] <dobey> :(
[17:58] <dobey> makes it like 10x more work to say, replace a patch with a slightly different one
[17:59] <broder> on the flip side, it forces you to make sure the patch applies properly
[18:00] <dobey> how so?
[18:00] <dobey> not any more than debuild -S does, no?
[18:10] <qwertologe> hello! i  developed a new ripper and search for someone who is able to package it and bring it into ubuntu... anybody here?
[18:13] <highvoltage> qwertologe: hi! someone on #ubuntu-packaging will be able to poing you in the right direction.
[18:14] <highvoltage> qwertologe: it may be a bit quiet in there today though, today was release day so many people are taking some well deserved rest
[18:14] <qwertologe> thanks a lot!
[18:15] <highvoltage> you're welcome
[18:15] <highvoltage> oops, s/poing/point/
[18:17] <broder> dobey: so, are you complaining about source format 3.0 (quilt) or udd's handling of it? for the latter, it always seemed reasonable to me that the udd branch match what you get if you apt-got source'd the package, so given that, the patches *should* be applied
[18:18] <broder> i'm more ambivalent about 3.0 (quilt) applying patches by default
[18:19] <slangasek> the problem is that 3.0 (quilt) is a real pain to map into VCSes
[18:19] <slangasek> in that it actually has to be mapped, and no one's doing this yet, including udd
[18:20] <broder> yeah, that's a reasonable point
[18:22] <dobey> broder: udd.
[18:22] <dobey> apt-get source applies patches by default?
[18:23] <broder> for 3.0, yes
[18:23] <dobey> ugh
[18:24] <dobey> broder: then We are complaining about both
[18:26] <slangasek> dobey: apt-get source applies patches by default if you declare in debian/source/format that you want a 3.0 (quilt) source packages.
[18:26] <slangasek> -s
[18:26] <slangasek> if you don't do that, then they're not applied by default
[18:27] <slangasek> now, the trend and the preference in Debian policy is for having patches applied by default, so that if you want to do things like archive-wide code inspection you don't have to guess what magic target name in debian/rules applies patches
[18:27] <slangasek> but as long as there are impedence mismatches like this one, it's reasonable to continue using quilt by hand in debian/rules
[18:28] <broder> i'd also argue that it lowers the barrier to entry for new contributors at the cost of making more advanced manipulations a bit more difficult
[18:33] <dobey> broder: not trying to do advanced manipulation. simply want to make a change, generate a patch, and throw it in debian/patches. but instead, the process is now significantly more difficult.
[18:33] <broder> dobey: really? i think it's quite easy
[18:33] <broder> (a) grab the branch
[18:33] <broder> (b) patch the source
[18:34] <broder> (c) run bzr bd -S
[18:34] <dobey> broder: it's easy if you don't mind having insane patch complexity
[18:34] <broder> (d) quilt rename -P debian-changes-crap my-awesome-patch
[18:34] <broder> (e) run bzr bd -S again
[18:34] <slangasek> hum?  bzr bd -S runs in a copy of the tree
[18:34] <slangasek> so it doesn't spit out the patch for you
[18:35] <broder> oh, true - fine, debuild -S :)
[18:35] <dobey> bzr diff -p 1 > debian/patches/42_blah_blah.patch
[18:35] <dobey> bzr revert
[18:35] <dobey> bzr add
[18:35] <dobey> but that's not the problem
[18:36] <dobey> the problem is that having patches applied in-tree, encourages inter-patch dependencies, which is bad.
[18:38] <dobey> the more patches you have, the more problematic it is
[19:25] <bdmurray> slangasek: I'm writing a bug pattern for bug 873397 to prevent further reporting of it
[19:25] <bdmurray> its just due to load on archive.canonical.com
[19:27] <slangasek> bdmurray: ah, ok
[19:27] <slangasek> for p, we should make sure ubiquity fails gracefully
[19:32] <bdmurray> slangasek: could bug 870643 be related to that one?
[19:33] <slangasek> bdmurray: that doesn't look like an archive-side load issue, just a client-side DNS issue
[19:56] <jtaylor> hi, can this propsal be denied, it was already merged into -proposed https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/79330
[19:56] <jtaylor> see https://launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=
[19:56] <jtaylor> thx
[19:57] <rye> slangasek, bug in network manager
[19:57] <rye> slangasek, bug #859373
[19:57] <rye> bdmurray, re: bug #870643
[20:00] <bdmurray> rye: so the string to look for is "NetworkManager.use-user-connections is not registered"
[20:01] <rye> bdmurray, yes, but it is in syslog/.xsession-errors
[20:01] <bdmurray> oh well that's lame
[20:02] <slangasek> so, er, upgrading libnm breaks the running session?
[20:02] <rye> bdmurray, otoh this may not be the case
[20:03] <rye> slangasek, yes, confirmed twice during upgrade, wifi definitely dies, i wonder whether dns settings on wired connection are going away too :(
[20:03] <slangasek> I guess cyphermox just tried it
[20:03] <james_w> jtaylor, done
[20:03] <jtaylor> thx
[20:04] <rye> bdmurray, wait, i may be too fast with this - the apport was able to send the report, right, so that may not be the same
[20:04] <rye> looking at the duplicates
[20:06] <rye> bdmurray, hm, maybe that's a real DNS issue in these cases
[20:08] <rye> but it is a bit suspicious that network fails at the end of installation from livecd, ok, i withdraw my comment, sorry
[20:10] <dobey> rye, slangasek, bdmurray: there was some weird network issue a minute ago. "apt-get update" gave errors about archive.canonical.com lists here. subsequent apt-get update worked fine though, and apt-get upgrade just worked fine (and still have network)
[20:10] <dobey> rye: the archive.canonical.com was probably real network issue :)
[20:10] <bdmurray> right archive.canonical.com is suffering some load issues
[20:11] <rye> dobey, but DNS... is archive.canonical.com the nameserver for itself :) ?
[20:12] <dobey> rye: no idea. dig thinks local server is DNS for everything here. :)
[20:26] <sladen> Laney: I seem to have failed to get to the London party.  Still around in Nottingham?
[21:59] <SpamapS> pitti: when you're back around.. I see an upload for cups today, but 1.5.0-8ubuntu1 was uploaded 4 days ago.. are we doing a mass release of verified things into oneiric-updates before the 7 day wait period, or do we just treat these SRU's as "business as usual" ?
[22:08] <RPG-Master> Does anyone here work on BleachBit?
[22:09] <RPG-Master> I've created a new icon for them and I have no idea how to suggest it/give it to them.
[22:21] <sladen> RPG-Master: I don't work at Bleachbit.  But if you file it against  http://launchpad.net/ubuntu-branding/+filebug  with a bit more context I can follow it up and see if I can make contact
[22:23] <RPG-Master> sladen: Is their some way I should do that on BleachBit's Launchpad? Or do matters of icons best go through ubuntu-branding?
[22:23] <RPG-Master> This is really my first time contributing to anything.
[22:37] <sladen> RPG-Master: they don't have to.  But at the moment I don't have background information to direct you to a more specific place, and at this stage I'd like to get it in the bug tracker so that it doesn't get lost
[22:38] <sladen> RPG-Master: if you file the bug, and attach your icon, along with other information about what it should replace then we can look into it
[22:38] <RPG-Master> sladen:  OK, I will. Thanks for the help. :)
[22:55] <slangasek> SpamapS: I would not recommend skipping the 7-day waiting period except for OMGkittens issues... if anything, doing so would make it harder to trace regressions to SRUs, coming on the heels of the release
[22:58] <Laney> sladen: Been at the beer festival, will be there again on Saturday...
[23:14] <SpamapS> slangasek: ok.. I couldn't remember if we did that for "0-day" SRU's or not.
[23:39] <RPG-Master> sladen: Here's my bug: https://bugs.launchpad.net/ubuntu-branding/+bug/873750