[00:36] <slangasek> bdmurray: ok; cosmic rays really is my best guess on that one then
[02:06] <mhall119> anybody know who or what maintains this list? http://people.ubuntu.com/patches/
[03:19] <Bluefoxicy> RAOF: this is so .... very strange.
[03:19] <Bluefoxicy> Thunderbird hasn't bloated under hoard
[03:19] <Bluefoxicy> I mean
[03:19] <Bluefoxicy> Iit's running with 339MB, instead of 1.8GB which is where it got all the time while I kept restarting it.
[03:20] <Bluefoxicy> after a day or so.
[03:42] <Bluefoxicy> uh, guys?
[03:43]  * RAOF was just googling hoard.
[03:43] <Bluefoxicy> How in the heck is there a package in Main that DEPENDS ON A PACKAGE IN UNIVERSE?
[03:43] <micahg> Bluefoxicy: shouldn't be, example please?
[03:43] <Bluefoxicy> actually let me upgrade it to make sure
[03:44] <Bluefoxicy> but my currently installed version in Precise shows gnome-session-fallback as universe
[03:44] <Bluefoxicy> gnome-session is in main and depends on it
[03:44] <micahg> not in precise
[03:45] <micahg> the depends doesn't exist I mean
[03:45] <ajmitch> it's in Suggests
[03:45] <Bluefoxicy> ah
[03:45] <Bluefoxicy> that explains ... most of it.
[03:45] <Bluefoxicy> I was looking in Synaptic at the "Dependents" for gnome-session-fallback
[03:46] <ajmitch> yeah, that likely looks at Suggests as well
[03:46] <Bluefoxicy> which said that gnome-session depends on it, rather than suggests it
[03:46] <ajmitch> 'reverse-depends gnome-session-fallback' is probably a bit more accurate
[03:47] <micahg> apt-cache show gnome-session works also :)
[03:48] <Bluefoxicy> RAOF:  man-db update in dpkg --configure seems to segfault with hoard though, be wary if you go playing with it.
[03:48] <Bluefoxicy> More basically though I don't trust the behavior I'm getting.  The default allocator cannot be this bad, I'm doing something wrong somewhere.
[03:49] <Bluefoxicy> ajmitch:  it says "Dependency of" in that dialog in Synaptic, maybe it should say "Suggested by" or "Recommended by" depending on if the package suggests/recommends (or is that the same thing?  I forget)
[05:51] <pitti> Good morning
[05:51] <micahg> hi pitti, could you please mark this proposal as merged or WIP (it's been released) https://code.launchpad.net/~jtaylor/ubuntu/oneiric/inspircd/CVE-2012-1836/+merge/102037
[05:53] <pitti> micahg: sure, done
[05:53] <micahg> thanks
[06:56] <kmc> i'm trying to build a PPA but it fails because Ubuntu's default stack-protector flags conflict with our own (more aggressive) stack-protector flags
[06:56] <kmc> i tried "export DEB_BUILD_HARDENING_STACKPROTECTOR=0" in debian/rules but it seems to have no effect
[06:56] <kmc> here is the PPA, the failure is on Precise: https://code.launchpad.net/~keithw/+recipe/mosh-daily
[07:00] <dholbach> good morning
[07:09] <kees> kmc: it's the order of flags in the build.
[07:09] <kees> g++ -DHAVE_CONFIG_H -I. -I../..  -I./../util  -D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra -pedantic -Wno-long-long -Weffc++ -fno-strict-overflow -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fPIE -fno-default-inline -pipe -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -c -o terminaldispatcher.o terminaldispatcher.cc
[07:09] <kees> you want -fstack-protector-all to go at the end, iiuc
[07:11] <kees> kmc: but if you're building with dh, you can turn it off with "export DEB_BUILD_MAINT_OPTIONS = hardening=-stackprotector"
[07:12] <kees> kmc: DEB_BUILD_HARDENING_STACKPROTECTOR=0 is for the older wrapper
[07:13] <kmc> okay, i will try DEB_BUILD_MAINT_OPTIONS, thanks!
[07:14] <kees> kmc: btw, I think --param ssp-buffer-size=1 has no affect when using -fstack-protector-all (since the char array sizes aren't checked)
[07:15] <kmc> okay
[07:17] <dupondje> http://archive.canonical.com needs some more bw it seems :) its dying
[07:25] <dupondje> When exactly are packages accepted into -proposed (for oneiric)
[07:26] <StevenK> When an SRU team member does it, or prods an archive admin to do so.
[07:26] <dupondje> ok :) cause apt needs to get in to make people can upgrade to precise without problems :)
[07:26] <micahg> StevenK: did you see yada is no more?
[07:28] <doko> rickspencer3, are all these multiarch assignments still targeted fot the lts?
[07:28] <StevenK> micahg: \o/
[07:28] <rickspencer3> doko, hi
[07:28] <rickspencer3> doko, I didn't target those, no
[07:28] <doko> ok, good to know :)
[07:28] <rickspencer3> doko, I dropped slangasek a note about it
[07:28] <StevenK> micahg: I think someone else told me it had been removed a few weeks/months ago
[07:28] <rickspencer3> it was just a heads up
[07:29] <rickspencer3> would have been nice to get those bug reports a bit earlier in the cycle
[07:29] <micahg> StevenK: I think it was removed from Debian ~1 mo ago
[07:32] <jibel> cjwatson, how can he have custom apt sources and ppa enabled during an installation ? From syslog apt.spideroak.com and ppa.launchpad.net are set.
[07:35] <dholbach> hyperair, hey - how are you doing? are you still planning to fix bug 980300?
[07:36] <hyperair> dholbach: hey. i'm a little held up due to exams, but yeah i plan to fix that as soon as mono gets unbroken in unstable so i can upload a mono-upnp fix together with it.
[07:37] <dholbach> hyperair, then all the best with the exams
[07:37] <hyperair> thanks =)
[07:46] <robert_ancell> @pilot out
[08:14] <brendand> anyone know what could be the cause behind 'unable to read python frame information' when trying to debug a python application with gdb?
[08:15] <brendand> i have python-dbg installed and ran python with -d
[08:47] <kmc> kees: we had to add "-include /usr/share/dpkg/buildflags.mk" after the DEB_BUILD_MAINT_OPTIONS line, but with that it works.  thanks for your help!
[09:11] <apw> cjwatson, we are using -proposed a bit in precise to avoid people getting messed up, however as an upgrader who had -proposed enabled by default before update, i still do after which i think defeats the idea slightly
[09:12] <apw> cjwatson, i wonder if we need to be turning it off when one updates across the stable/devel boundary
[09:12] <cjwatson> mhall119: nobody maintains that list; it's a set of patches generated in the very early days of Ubuntu, which continues to be published to avoid breaking links, but which is no longer added to
[09:12] <cjwatson> jibel: dunno, perhaps preseeding?
[09:12] <kmc> f/part
[09:12] <kmc> whoops sorry
[09:13] <cjwatson> apw: *shrug* personally I think people who've opted into proposed updates have opted in :)
[09:14] <apw> cjwatson, :)
[09:15] <Laney> well, the release upgrader could disable proposed when upgrading to a devel release
[09:17] <cjwatson> Clearly it technically could; it's not clear those are the right semantics
[09:17] <cjwatson> Longer-term we're intending to use -proposed in development releases as something similar to Debian unstable, and that's certainly something that many technically-minded users and developers run directly
[09:18] <cjwatson> Also if we removed -proposed only pre-release that would mean testing pre-release and post-release would have different effects, which is often a questionable thing to do - and it would lose the information that somebody's opted into post-release proposed updates
[09:20] <diwic> pitti, I'm trying to trace down a crash in jackd2, but I'm having troubles getting debug symbols - the library, libjackserver.so.0.1.0, is in package jackd2 but there is no jackd2-dbgsym on ddebs.ubuntu.com. Any ideas?
[09:21] <Laney> I don't know what the plans are, but it seems like currently pre-release it's used mainly to avoid skew which isn't something that people need to have in their sources.list.
[09:21] <Laney> If it's used for packages that we want people to run then it is indeed different.
[09:23] <cjwatson> There'll be skew in the exact same way post-release
[09:23] <cjwatson> So if people have trouble dealing with that, it's a wash either way
[09:24] <didrocks> could someone reject https://code.launchpad.net/~arashbm/ubuntu/precise/compizconfig-settings-manager/add_quicklist/+merge/94462 please?
[09:24] <cjwatson> We've certainly discussed having things for people to test in -proposed pre-release; we've not been doing so much thus far because our tools for managing -proposed currently suck
[09:25] <didrocks> same story for https://code.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot/+merge/100539
[09:28] <didrocks> and same for https://code.launchpad.net/~nathwill/ubuntu/precise/unity/lp-972247/+merge/100927
[09:28] <didrocks> dholbach: compiz/unity ones done ^
[09:32] <Laney> Of course the skew issues aren't solved post-release, but there is a point to -proposed then: to test fixes. If it's just used for skew avoidance pre-release then there is no point running it and it's just pain for no gain.
[09:33] <Laney> I do look forward to using it more for testing, though.
[09:37] <pitti> diwic: we often lose ddebs due to various problems with the hack that ddebs.u.c. is
[09:37] <pitti> diwic: if it was built less than 7 days ago, I can rescue them, otherwise they are lost, I'm afraid :/
[09:37] <diwic> pitti, but that means that if I build it locally it would make ddebs?
[09:37] <pitti> diwic: if you install pkg-create-dbgsym, yes
[09:38] <pitti> you just won't be able to process other people's core dumps with those
[09:38] <diwic> pitti, thanks, will try that.
[09:38] <diwic> pitti, it's fairly reproducible here (for once...!)
[09:38] <pitti> diwic: but if you can reproduce the bug, it's probably easier to just do a DEB_BUILD_OPTIONS=nostrip,noopt build
[09:38] <pitti> which will also give you the non-optimized variant and thus an easier to debug one
[09:39] <diwic> pitti, hum, unless the noopt changes things around that causes the sigsegv not to happen
[09:39] <diwic> pitti, thanks for the tip!
[09:40] <pitti> diwic: yes, that often happens unfortunately
[09:40] <pitti> if so, drop the noopt
[09:40] <diwic> jup
[10:02] <hyperair> say, how does sponsoring involving bzr work?
[10:02] <hyperair> after merging, do i push to lp:ubuntu/$pkg?
[10:02] <hyperair> or do i just dput?
[10:02] <Laney> both
[10:02] <hyperair> oh
[10:02] <hyperair> okay
[10:03] <hyperair> doesn't lp:ubuntu/stuff get auto-updated anyway?
[10:03] <hyperair> and should i tag it?
[10:03] <Laney> if you don't push then the importer will push to the branch, but that will obviously not be the 'proper' changes you made
[10:03] <hyperair> i see
[10:03] <hyperair> and what about tagging?
[10:04] <hyperair> does the importer handle the tagging, or do i?
[10:04] <Laney> i think you do it, with bzr mark-uploaded
[10:04] <Laney> but not sure about that
[10:06] <jelmer> hyperair, Laney: if you push the revision contents, you should do the tagging
[10:06] <Laney> jelmer: I thought I head something about mark-uploaded being handled by some other part of the process these days, but I'm too far out of the loop to know anything. :(
[10:07] <hyperair> jelmer: okay. does mark-uploaded do anything special or does it just tag?
[10:07] <jelmer> hyperair: it just tags - "bzr tag" (no arguments) has the same effect
[10:07] <Laney> aha, that is probably what I heard
[10:07] <jelmer> Laney: if you leave the creation of the revision to the importer and don't push yourself, then the importer will also take care of the tagging
[10:08] <hyperair> jelmer: okay, thanks. i'm using git-bzr-ng
[10:08] <hyperair> it at least makes bzr bearable to use
[10:08] <Laney> is it transparent wrt branches?
[10:09] <jelmer> hyperair: note that git doesn't handle some characters in tag names, not sure how that interacts with git-bzr-ng
[10:10] <hyperair> jelmer: ah right, i forgot about that. well this one doesn't have ~ so i guess it's fine.
[10:10] <hyperair> Laney: yeah it is
[10:10] <Laney> nice
[10:10] <hyperair> Laney: except it doesn't have the git-buildpackage format
[10:11] <Laney> how do you do that then?
[10:12] <hyperair> Laney: well, if you have tarballs lying around, you can use it without an upstream branch and without pristine-tar.
[10:12] <hyperair> Laney: and if it's a native package, it works fine anyway
[10:13] <Laney> maybe git-bzr-ng could learn how to expose pristine-tar. the upstream branch isn't necessary
[10:14] <hyperair> Laney: did bzr ever have pristine-tar?
[10:14] <Laney> it does, but I don't know how it works.
[10:14] <hyperair> hmm really
[10:15] <Laney> I think you can have extra data associated with a revision, which is where they store the pristine-tar data
[10:15] <hyperair> well either way i don't plan to do very serious work over bzr. just a couple of random commits/merges. just today i had to wrestle with incompatible bzr repository formats
[10:16] <hyperair> stupid thing.
[10:16] <Laney> https://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/view/head:/upstream/pristinetar.py
[10:18] <jelmer> hyperair: huh?
[10:19] <hyperair> jelmer: ?
[10:19] <jelmer> hyperair: everything should be in the same format these days, and has been for a long time
[11:03] <hyperair> hmm is /var/crash supposed to be world-writable?
[11:03] <hyperair> it looks like ubuntu-bug tries to write the .upload into /var/crash and fails
[11:12] <greyback> barry: ping
[11:18] <dpm> hi mvo, quick question, do you know if it's possible to get a shell script to check whether a command exists, and if it doesn't, get it to call command-not-found to get the usual message with a note about in which package it can be found and the apt-get install line?
[11:18] <pitti> dpm: check whether a command exists:
[11:19] <pitti> if type mycommand >/dev/null 2>&1; then ...
[11:19] <pitti> dpm: in the else branch you can then echo the hint
[11:20] <dpm> thanks pitti, but I was wondering if I could get command-not-found to guess the package where the command is and print the hint for me
[11:20] <cjwatson> /usr/lib/command-not-found mycommand
[11:20] <cjwatson> modulo all the import noise which seems like a bug
[11:20] <dpm> ah, let me try that, thanks!
[11:24] <dpm> although that does not give me information about the package, and it tells me the command is not found, when in fact it is installed:
[11:24] <dpm> http://pastebin.ubuntu.com/933828/
[11:24] <dpm> I was thinking more along the lines of (after reinstalling the package):
[11:24] <dpm> http://pastebin.ubuntu.com/933829/
[11:25] <dpm> which basically says that the command is not present, but that it can be installed from the given package
[11:26] <dpm> I get this output by running the command on the terminal
[11:26] <cjwatson> no no, you do the type test and then fall back to c-n-f
[11:27] <cjwatson> of course you'd need to depend on command-not-found for this since it's not installed in minimal environments
[11:31] <dpm> cjwatson, as in 'if type po4a >/dev/null 2>&1; then /usr/lib/command-not-found po4a; fi'? (sorry, I'm not good at shell programming)
[11:31] <seb128> dpm, what problem do you try to solve?
[11:33] <dpm> seb128, ah, it's for a script to translate the Ubuntu Code of Conduct. It requires po4a to be run, and I simply wanted to add a check to see whether it is installed, and if not, output a message showing how it can be installed, in a similar way you see when you type a command on the terminal that's not installed in the system
[11:33] <cjwatson> dpm: 'if ! type po4a ...' but yes
[11:33] <cjwatson> also possibly an exit or break or whatever in there depending on context
[11:34] <dpm> cjwatson, ah cool, yes, that works, and I'll just need to add an exit, thanks!
[11:34]  * cjwatson fixes the ImportWarning noise from cnf
[11:35] <cjwatson> scan.data needs an update anyway ...
[11:57] <mvo> cjwatson: thanks a bunch for your fix
[12:13] <cjwatson> slangasek,dupondje: this apt oneiric-proposed upload - there was a previous oneiric-proposed upload (0.8.16~exp5ubuntu13.1) from me which fixed a different set of upgrade bugs; it was superseded by a security upload but I didn't notice at the time.  Could we perhaps merge that back in?  If we're going to be going to the effort of doing full suites of upgrade testing, I think it would be worth testing this at the same time
[12:22] <ogra_> ogra@horus:~$ dpkg -L libgcc1|grep copy
[12:22] <ogra_> ogra@horus:~$ LANG=C dpkg -S /usr/share/doc/libgcc1/copyright
[12:22] <ogra_> dpkg-query: no path found matching pattern /usr/share/doc/libgcc1/copyright.
[12:22] <ogra_> ogra@horus:~$
[12:22] <ogra_> hmm
[12:22] <ogra_> so where does that copyright file come from ?
[12:22] <ogra_> (/usr/share/doc/libgcc1/copyright exists but doesnt seem to be shipped in the package)
[12:24] <ogra_> hmm, the same goes for vim-tiny
[12:25] <ogra_> (and apparently a few other packages)
[12:29] <cjwatson> lrwxrwxrwx 1 root root 12 Jun  7  2011 /usr/share/doc/libgcc1 -> gcc-4.6-base
[12:29] <ogra_> ah, i was searching the link
[12:29] <cjwatson> $ dpkg -S /usr/share/doc/gcc-4.6-base/copyright
[12:29] <cjwatson> gcc-4.6-base: /usr/share/doc/gcc-4.6-base/copyright
[12:29] <ogra_> but not that high up
[12:29] <ogra_> thanks
[12:32] <dupondje> cjwatson: so 0.8.16~exp5ubuntu13.2 does not contain 0.8.16~exp5ubuntu13.1 ?
[12:32] <cjwatson> no, as documented in its changelog
[12:33] <dupondje> hmz I'll check
[12:33] <saidinesh5> hey guys .. i need to get a GPLed software that we wrote packaged...  (and eventually pushed to Ubuntu software center) .. so should we have to do the packaging ourselves? or can we request someone else to do the packaging magic?
[12:37] <cjwatson> depends whether you can get somebody interested :)
[12:39] <saidinesh5> cjwatson: are you interested? :P
[12:40] <cjwatson> you really don't want to be relying on me, I have no time
[12:40] <saidinesh5> Ah :/
[12:41]  * saidinesh5 finds the debian packaging process quite intimidating...
[12:41] <cjwatson> mvo: any thoughts on my comments on bug 938116?
[12:41] <cjwatson> I should probably make some kind of concerted effort to reproduce that
[12:43] <cjwatson> mvo: notwithstanding my comments about update-manager maybe being fixed, it does look as though software-center needs changes to create a new cache; it only seems to reload the backend, not the cache, if I'm reading it correctly
[12:45] <seb128> pitti, do you know if the "no hibernate by default" and "how to re-enable" it is documented somewhere? should it be in the release notes?
[12:45] <seb128> pitti, I'm looking for a pointer to give on a bug report about "hibernate is missing from the gnome-session ui"
[12:49] <mvo> cjwatson: let me look at this
[12:50] <mvo> cjwatson: I think you are right, I should do the store.clear() before the initCache to ensure that there is nothing in the clear that plays with the no-longer-valid references to the old mmap
[12:51] <pitti> seb128: right, I'll add it to the release notes
[12:51] <seb128> pitti, danke
[12:51] <pitti> seb128: no other documentation aside from bug 812394
[12:52] <cjwatson> mvo: well, in update-manager there definitely isn't anything like that now (I think) because of the clearing_store thing
[12:54] <mvo> cjwatson: http://paste.ubuntu.com/933923/ this should help and probably makes the self.clearing_store obsolete
[12:54] <dupondje> cjwatson: https://launchpadlibrarian.net/102332070/apt3.debdiff
[12:55] <cjwatson> mvo: right (though might as well leave it in for now)
[12:56] <cjwatson> dupondje: looks good to me (from memory)
[12:57] <cjwatson> dupondje: shall I reject the one in the queue then?
[12:57] <dupondje> well its preferred to directly upload the one with your patches included also I guess
[12:57] <dupondje> so fine for me :)
[12:57] <mvo> cjwatson: I commited that now
[12:58] <cjwatson> mvo: OK, awesome - can your team deal with the s-c case?
[12:58] <dupondje> slangasek: should just upload the new one then ^^
[12:58] <cjwatson> mvo: I'll see if I can reproduce the crash with an older version of u-m, to see if this is more than guesswork
[12:58] <cjwatson> dupondje: done
[12:58] <cjwatson> (rejected, I mean)
[12:58] <dupondje> thx
[13:00] <mvo> cjwatson: will do
[13:12] <ahasenack> hi guys, who could upload landscape-client for lucid, natty and oneiric? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= is the lucid one
[13:13] <ahasenack> -proposed, of course
[13:17] <mvo> cjwatson: just fyi, the cache reopen in s-c is done async in the "transaction-finished" signal, so that could be covered as well
[13:21] <ahasenack> greyback|lunch: ping, got you a backtrace for #936560
[13:21] <mvo> Mirv: hey, I fixed the ddtp import stuff today I think so hopefully by tomorrow LP has merged the updated strings
[13:21] <greyback> ahasenack: magic, can you pastebin please?
[13:21] <ahasenack> greyback: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/936560/+attachment/3083556/+files/stacktrace.txt works?
[13:21] <greyback> ahasenack: is there *anything* you notice that causes this crash?
[13:22] <greyback> ahasenack: it's driving us nuts
[13:22] <ahasenack> greyback: since this was running for a few hours already and without a crash, I started "exercising" unity-2d
[13:22] <ahasenack> greyback: so I changed background (not related), fired up some apps via the pannel, maximized and minimized them, and did a lot of exposès
[13:22] <ahasenack> greyback: eventually it crashed in a few minutes after I started doing that
[13:23] <ahasenack> greyback: but nothing specific I could put my finger on
[13:23] <ahasenack> greyback: and seems like I'm still missing some -dbg packages
[13:23] <greyback> ahasenack: interesting, I see the onActiveWorkspaceChanged signal again. I might have fix for that
[13:23] <ahasenack> I only have libqt4-dbg, libqt4-script-dbg and unity-2d-dbg
[13:24] <greyback> but that's again a different bt from the original one, which depended on QDeclarativeFlickable
[13:24] <ahasenack> greyback: also, i remember that a notification came up while I was in exposè
[13:24] <ahasenack> but the crash wasn't right at that moment
[13:24] <greyback> ahasenack: ok, thanks very much for that
[13:25] <greyback> ahasenack: I'll ping you if I need anything more
[13:25] <ahasenack> greyback: ok, I'll leave it running in gdb again
[13:25] <greyback> ahasenack: thanks
[13:26] <ahasenack> greyback: any other -dbg package I should/could install before?
[13:26] <ahasenack> greyback: hm, some apps appear to have died as a result of that crash, but maybe it was a coincidence. chromium and pidgin
[13:26] <greyback> ahasenack: I don't think it's necessary, I do think it's our bug
[13:27] <ahasenack> ok
[13:50] <Mirv> mvo: woohoo, great!
[13:51] <mvo> Mirv: yeah, lets hope there are not more issues hidding, but there is definitely progress :)
[13:52] <Mirv> mvo: let's see, yes :) then when they hit the archives, will they be visible on precise-changes? (they used to for some older releases at least)
[13:52] <mvo> Mirv: yes, should be
[13:52] <Mirv> mvo: ok
[13:54] <barry> greyback: pong
[13:54] <mvo> cjwatson: do you have anything else pending for update-manager? or bdmurray? if not I can upload
[13:54] <greyback> barry: hey, I wanted to ask you how the Alt key is behaving for you with Unity2D
[13:54] <barry> greyback: with the ppa version or stock version?
[13:55] <greyback> barry: 5.10 or later (so about the last 2 weeks)
[13:56] <barry> greyback: not so good unfortunately.  i tried it last week after a dist-upgrade and it still gets invoked too often.  however, i think it's been narrowed down to the vm environment.  i'll try it again right now on both a vm and native
[13:56] <greyback> barry: appreciated
[14:03] <tsdgeos> ahasenack: if i give you a small patch file for one of the unity2d files can you check if it fixes the crash you're experimenting?
[14:04] <ahasenack> tsdgeos: more or less, since I don't have a specific way to trigger it, it just eventually happens. So if it doesn't happen for one or two days, it might have helped
[14:04] <tsdgeos> well
[14:04] <tsdgeos> it triggers more for you than for us
[14:04] <ahasenack> :)
[14:05] <tsdgeos> so i think it's worth trying
[14:05] <ahasenack> sure
[14:05] <tsdgeos> ahasenack: can you download https://pastebin.canonical.com/64404/
[14:05] <tsdgeos> put it on a file
[14:05] <tsdgeos> and then go to /usr/share/unity-2d/shell/launcher
[14:06] <tsdgeos> sudo patch -p0 < /path/to/that/file
[14:06] <ahasenack> ok
[14:07] <tsdgeos> ahasenack: actually, can you get https://pastebin.canonical.com/64405/
[14:07] <tsdgeos> it adds a logging line
[14:07] <tsdgeos> so if you see it
[14:07] <tsdgeos> means that something that we are not accounting for happened
[14:08] <ahasenack> ok
[14:08] <tsdgeos> great :-)
[14:08] <tsdgeos> thanks
[14:15] <barry> greyback: okay, i've done a bit of testing on both systems, after a dist-upgrade and reboot.  i have some feedback (and managed to crash u2d in the meantime :)
[14:17] <barry> greyback: on the native install, alt is less prone to accidentally invoke the hud, although i've noticed a few questionable invokes while doing normal stuff in emacs.  i would need a longer session on that box to know if it's a persistent problem, so i'll try to spend a bit more time hacking on that machine today
[14:18] <barry> greyback: on the vm install, the alt is still unusable.  i suspect that this has something to do with the way fusion is forwarding key events to the guest os.  note that i'm using fusion 4.1.2 which is the latest release.
[14:18] <Ali> Hello :D
[14:19] <barry> greyback: so, on the vm box, i rebound HUD to Alt R and then did a bunch of tapping and holding to see what happened.  bug 984012 is one fo the things that happened. ;)  one of the things that *didn't* happen though is that the HUD didn't come up
[14:20] <barry> thank you ubottu, it's a private bug
[14:20] <Ali> Can anyone please tell which chapters should I study from "Operating System Concepts" if I want to understand ubuntu's source?
[14:21] <maco> Ali: thatll help you understand *linux*'s source
[14:21] <maco> Ali: Operating System Concepts is about kernels
[14:21] <maco> though iirc, it
[14:21] <maco> 's written from a solaris perspective
[14:21] <Ali> I see.
[14:21] <maco> i was asked to help update the next version to have a linux perspective, but... my kernel-fu not up for it :P
[14:21] <barry> greyback: eot :)
[14:23] <Ali> Is there anything in that book that I need to know before I (try to) jump into ubuntu dev :D
[14:24] <Ali> Summers are coming up. I don't want to work on meaningless self-projects :( pls help
[14:24] <maco> Ali: depends what you want to develop on... kernel hacking? read the book and get good with C.  desktop applications? check out the docs for GTK (if you want to work on ubuntu desktop apps) or Qt (if you want to work on Kubuntu desktop apps), which are usually used with C or C++ respectively, but they both have Python bindings as well
[14:25] <maco> Unity is written in C I think, but Unity-2d is Qt/C++ iirc
[14:25] <seb128> mdke, hey, there?
[14:25] <maco> I find PyGTK and PyQt to be very nice libraries to work with
[14:25] <Ali> Okay. thank you :)
[14:26] <Riddell> maco: several of ubuntu desktop apps are Qt now (and Unity isn't gtk at all as far as I know)
[14:26] <Ali> I'll look into PyQt. I worked with Qt under windows a couple of months back.
[14:26] <maco> Riddell:  i thought unity was plain ol' C, just GLib etc.
[14:27] <maco> though, it's a Compiz plugin, so idk what else gets thrown in on top of that base
[14:27] <bdmurray> cjwatson: I found some more recent duplicates of bug 848915
[14:43] <Riddell> maco: nux as well which is a canonical made thing
[14:43] <maco> Riddell: is that the graphics library that the a11y team tends to bump its collective head on?
[14:43] <Riddell> maco: could well be
[14:45] <greyback> barry: sorry was away. Thanks for info. VM case is tricky alright
[14:46] <greyback> barry: I can't see bug 984012
[14:49] <greyback> barry: also to clarify, in VM, with HUD bound to Alt_R, HUD never appeared?
[14:50] <barry> greyback: restart after crash, now it does appear on alt-r
[14:51] <greyback> barry: hmm ok
[14:52] <barry> greyback: let me just look and see if there's anything obviously sensitive in the apport data, and if not, i'll flip it to public
[14:52] <greyback> barry: magic thanks
[14:55] <cjwatson> mvo: oho
[14:55] <cjwatson> mvo: I have nothing else for update-manager, but there was a bug barry was working on
[14:55] <barry> greyback: i flipped it public
[14:55] <cjwatson> bdmurray: damn, things I didn't want to hear ...
[14:56] <barry> cjwatson, mvo: it's bug 873468 but i'm not sure we can come up with anything that brian may will like, and slangasek bumped it down to high anyway.  mvo if you have any thoughts on the bug, could you add a comment?
[14:56] <cjwatson> barry: high is still release-critical
[14:56] <cjwatson> mvo: don't suppose you have any thoughts on 848915, beyond cosmic rays?
[14:56] <greyback> barry: got it, thanks
[14:57] <barry> cjwatson: yep, but slangasek said since it's mostly an upgrade issue he won't worry about it too much for .0
[14:57] <cjwatson> well, ok
[14:57] <barry> (not saying it should be fixed of course)
[14:57] <barry> er, *shouldn't*
[14:58] <barry> cjwatson: i think the change in language is easy.  what i'm less sure about, and what maybe mvo can comment on, is whether we can actually detect if the problem is a slow/faulty mirror or something else
[14:58] <slangasek> dupondje: could you provide that as an incremental patch against the previously uploaded apt 13.3, please?  easier for me to merge that way
[14:58] <mvo> right, well, that one is tricky, if the server suddently starts delievering zero size files, that could be a lot, usually its a overloaded server but it might also be misconfiguration and the like
[14:58] <slangasek> barry: well, I didn't say I wouldn't worry ;)
[14:58] <slangasek> I worry about a lot of things!
[14:59] <barry> slangasek: fair enough ;)
[15:00] <doko> micahg, ScottK, slangasek: see bug 934593, proposing for precise-proposed
[15:01] <doko> slangasek, infinity: now that gcc-4.6 is in precise, I assume it is ok to upload the two linaro regressions fixes to precise-proposed?
[15:01] <slangasek> doko: should be, yes
[15:02] <slangasek> doko: 934593 for SRU or for -proposed -> -release?
[15:02] <doko> slangasek, both is fine with me
[15:02] <bdmurray> mvo: regarding update-manager I was looking at bug 961719 and the postgresql blacklist entry
[15:03] <barry> mvo: right.  and the problem as i see it in the code at that point is that we really have no indication of the cause of the problem, just that the package isn't downloadable
[15:04] <mvo> bdmurray: aha, nice. did pitti give some input on that too?
[15:04] <slangasek> barry: would it be enough to add in a generic "this may be caused by [...], please try again later" at the end of the message?
[15:05] <mvo> barry: right
[15:05] <barry> slangasek: see my proposed text in this comment: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/873468/comments/19
[15:05] <barry> slangasek: (but a "try again later" is useful)
[15:06] <dupondje> slangasek: need to check that :)
[15:06] <bdmurray> mvo: no pitti did not
[15:11] <mvo> bdmurray: so the current regexp is pretty broad: ^postgresql-.*[0-9]\.[0-9].* - maybe pitti can give some input what should be done about it, I don't know much about postgresql, it appears this package is no longer there, maybe we need something transitional or a less strict regexp
[15:15] <ScottK> doko: Is 934593 really important enough to do during final freeze?
[15:20] <slangasek> cjwatson, jodh: things we do want to hear: all but one of the plymouth crasher bugs have stopped receiving streams of duplicates since the workaround landed :)
[15:20] <stgraber> wow! :)
[15:20] <jodh> slangasek: nice - and we think we've found the real cause of the bug too :)
[15:20] <cjwatson> mvo: I was also wondering what to do with bug 979661, but I suspect that's an apt/oneiric bug
[15:21] <slangasek> jodh: sweet!
[15:21] <cjwatson> slangasek: excellent.  which one hasn't?
[15:22] <jodh> slangasek: ^ he beat me to that question :)
[15:22] <slangasek> cjwatson: bug #733453
[15:23] <cjwatson> right, which has a quite different signature
[15:24] <doko> ScottK, I don't care if it goes into -proposed for a SRU or not. but the upgrade should be safe, including the replaces
[15:25] <ScottK> Why not just do it in "Q"?
[15:26] <ScottK> It's lack is not an RC bug.
[15:26] <doko> precise should have the python2 symlinks
[15:35] <mvo> cjwatson: hm, your comments indicate its a ordering problem?
[15:36] <ScottK> slangasek: I don't object to what doko wants to do, but I haven't reviewed the change. At least since it's going via proposed, it can't break the archive like it did last time.
[15:36] <cjwatson> mvo: it's kind of an intractable horrible thing exacerbated by an ordering problem
[15:37] <cjwatson> mvo: the ordering problem means it pops up for libc6; but in between perl-base being configured and libgtk2-perl and its deps being configured, any debconf prompt would fall back to the dialog frontend and result in this symptom
[15:37] <cjwatson> how likely that actually is in practice, I'm not sure
[15:37] <pitti> mvo: what's the problem with the regexp? it looks correct to me
[15:37]  * pitti looks at the bug
[15:38] <mvo> pitti: its fine, but it matches a package that is no longer in 12.04 afaict
[15:38] <pitti> mvo: that should always be the case
[15:38] <pitti> mvo: the idea is that update-manager does not remove packages like postgresql-8.4 if you upgrade to precise
[15:38] <mvo> cjwatson: right, we should consider moving u-m inside the live env in the longer term :/
[15:39] <mvo> pitti: right, so that is not a bug? but instead the user needs to make a decision here?
[15:40] <pitti> mvo: is bug 873468 actually related to that?
[15:41] <pitti> it doesn't have "postg" anywhere
[15:41] <pitti> mvo: not quite a decision, but he needs to upgrade his databases; there's a debconf note and documentation what to do there
[15:41] <mvo> bdmurray: https://launchpad.net/bugs/961719 seems to be the right link, sorry, too many open irc windows
[15:41] <pitti> we can't do an in-place upgrade from 8.4 to 9.1 during dist-upgrade
[15:41] <pitti> (or any major version indeed)
[15:42] <pitti> so u-m must not remove postgresql-X.Y due to obsolescence
[15:42] <bdmurray> the right bug is actually 905454 now
[15:43] <ScottK> Someone might want to mention to sabdfl that we're running out of time if the tools in Precise are going to know the name of the "Q" release without a bunch of SRUs/backports.
[15:43] <pitti> mvo: oh, that's because of the libperl transition, and it's not co-installable? erk
[15:43] <pitti> ScottK: already did several times..
[15:43] <ScottK> Sigh.  OK.  Thanks.
[15:47] <pitti> mvo: hm, I guess in theory we could reintroduce 8.4 to universe and build it against perl 5.14?
[15:48] <mvo> pitti: I don't know :) I mean, I don't know enough about this topic to have a vaguely good opinion currently  (plus it was a looong day)
[15:49] <pitti> mvo: the main point is that we need a co-installable -8.4, but seems the lucid version isn't installable any more in precise due to libperl5.12 and libperl5.14 conflicting
[15:50] <mvo> pitti: aha, I see
[15:52] <pitti> mvo: do we want apport to report package install failures post-release?
[15:52] <pitti> mvo: I think we used to do that, but now we actually have a choice
[15:52] <pitti> but I think we should leave it on for a while
[15:53] <dupondje> slangasek: ubuntu.dupondje.be/apt_changed.debdiff
[15:56] <mvo> pitti: hm, a good question, I personally don't triage them, so bdmurray is probably a better person to anser this
[15:56] <pitti> bdmurray: ^ any opinion?
[15:57] <bdmurray> pitti: I think it useful to catch the long tail of uninstallable packages
[15:58] <pitti> bdmurray: I agree; so I leave it on for now
[15:58] <pitti> we can still disable it after 12.04.1 or so
[15:58] <bdmurray> okay, that's good to know
[15:59] <bdmurray> pitti: did you see that full /tmp package install failure?  I opened an apport task about it
[16:00] <bdmurray> bug 979928
[16:04] <pitti> bdmurray: I did, yes; I'll fix it soon, and we can probably SRU it
[16:05] <pitti> bdmurray: oh, actually we already check for /tmp/
[16:05] <bdmurray> yes, we added that and I'm wondering why it didn't work out
[16:06] <pitti> bdmurray: hm, 10 MB might not be enough?
[16:06] <pitti> creating an initramfs certainly needs more
[16:23] <pitti> bdmurray, mvo: I followed up in #905454 to explain the situation
[16:31] <SpamapS> pitti: at what point does precise-proposed become SRU's instead of release quarantined packages?
[16:32] <bdmurray> Is there some archive admin who could look at my upload of update-manager in oneiric-proposed?
[16:40] <slangasek> dupondje: thanks!
[16:43] <slangasek> pitti: 905454> if you think it's necessary to reintroduce -8.4, I guess we can do that.  Will you take care of uploading?
[16:44] <slangasek> pitti: what alternatives are there?  Could we not simply release note that the admin needs to dump their dbs before upgrade?
[17:22] <cjwatson> ppisati: any chance of a fix for bug 984180 for precise, so that I don't have to track this down through multiple layers of installer code again? :)
[17:26] <ppisati> cjwatson: ack, will do
[17:27] <cjwatson> thanks
[17:27] <ppisati> cjwatson: but i think it's too late for P
[17:27] <cjwatson> #ubuntu-release doesn't
[17:27] <ppisati> ok then
[17:27] <cjwatson> (I discussed this there first)
[17:27] <ppisati> cjwatson: ack
[17:28] <cjwatson> it makes the default recipe on armhf/omap4 unusable, which may not quite be a showstopper given how arm installation works but it does seem not that far off
[17:41] <pitti> SpamapS: we can basically pick any time we want; we can do that decison per-package even when it's already in -proposed
[17:41] <pitti> SpamapS: my gut feeling is that the cutoff point is around this Friday
[17:42] <pitti> slangasek: we could release note it, but then you'd lose all the machinery that allows you to do a safe and working upgrade; aside from the fact that not everyone reads them, and it's too late after the upgrade
[17:42] <pitti> slangasek: I don't fancy reintroducing 8.4 either, but I don't know how else to do this
[17:43] <slangasek> pitti: well, I'm proposing that we keep the blacklist in place
[17:43] <slangasek> whether we reintroduce 8.4 or not
[17:43] <pitti> slangasek: *nod*
[17:43] <slangasek> and if there are steps users can follow *manually* to dump dbs before upgrade, that's fine
[17:43] <slangasek> if not, well, reintroducing is an option
[17:43] <slangasek> pitti: I've assigned the bug to you to do with as you wish ;)
[17:44] <dupondje> slangasek: you'll upload the new apt ? :)
[17:44] <pitti> slangasek: ok; I think we can keep it in universe, though
[17:44] <slangasek> dupondje: yes - later today
[17:45] <pitti> slangasek: ok, I'll sync it back from Debian then
[17:46]  * pitti unblacklists and wonders how long it takes for syncpackage to see the updated blacklist
[17:46] <pitti> oh, it's in lplib
[17:47] <pitti> ah no, from http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[18:04] <bdmurray> slangasek: do you have an opinion on what should happen with bug 973717?
[18:09] <ppisati> cjwatson: pull req sent to the kernel ml - Ubuntu-3.2.0-1412.16
[18:20] <slangasek> bdmurray: seems like something we ought to fix in update-manager
[18:20] <slangasek> bdmurray: I guess the pre-requisits source needs to be removed again after dist-upgrade by u-m, since it created it?
[18:21] <bdmurray> slangasek: right is that something still doable for P? or should it be release noted?
[18:24] <slangasek> bdmurray: seems like it's doable provided we find the time
[18:25] <slangasek> tagging rls-p-tracking
[18:25] <slangasek> the work to fix that is comparable to the work to write a release note for it, so we should JFDI
[18:26] <mvo> slangasek: if you are not on it already I can give it a stab
[18:27] <slangasek> mvo: that'd be great, thanks :)
[18:28] <slangasek> mvo: there was another bug I had a question for you on yesterday... hmm... I sent you bug mail about it
[18:28]  * slangasek tries to remember now
[18:28] <mvo> slangasek: uhh, a bugnumber would be awsome
[18:28] <slangasek> wouldn't it though ;)
[18:29] <slangasek> bug #982859
[18:29] <slangasek> found it!
[18:29] <slangasek> mvo: ^^
[18:30]  * ogra_ grins seeing the recent debian-arm ML thread ...
[18:30] <mvo> slangasek: thanks, let me have a look
[18:32] <slangasek> mvo: I couldn't work out any way in u-m to hint that we want to give priority to holding back certain packages
[18:34] <mvo> slangasek: oh, let me look at this
[18:34] <mvo> slangasek: but first I need to trigger a test-run of the removal of the backports sources
[18:34] <slangasek> ok :)
[18:49] <mvo> slangasek: eh, why do we have "release-upgrader-libapt-pkg-dev" now in the preRequists? that does not look quite right
[18:49] <slangasek> mvo: I didn't put it there
[18:49]  * mvo looks further
[18:50] <slangasek> bug #969182
[18:50] <mvo> no worries I check it out
[18:50] <mvo> aha, thanks. that looks like it needs a different fix
[19:05] <slangasek> jodh, cjwatson: I particularly love the timeline on bug #969667, which has dupes streaming in for two weeks and stopping exactly when the plymouth upload happened
[19:05] <slangasek> (still chasing down all the possible instances of this bug)
[19:08] <mvo> slangasek: update-manager should be good now, double checking welcome, but I think this is ready to upload
[19:08] <slangasek> mvo: you rock
[19:09] <slangasek> mvo: you can always just upload, someone will double-check in the queue
[19:10] <slangasek> mvo: hmm, "disconnect model and clear store" - I'm pretty sure bdmurray has a bug number for that
[19:12] <slangasek> mvo: yep, all looks good to me.  No verdict on the skype issue yet?
[19:12] <mvo> slangasek: ups, sorry, that slipped my attention while I looked at a pyhton-apt issue
[19:12] <slangasek> no worries
[19:13] <mvo> slangasek: yeah, we can drop it, I just added it as its so popular
[19:13] <slangasek> mvo: is that the best fix here?
[19:13] <mvo> slangasek: the best fix is to upgrade skype :)
[19:13] <slangasek> but you can't do that until you've upgraded dpkg
[19:15] <mvo> slangasek: we *could* add it to the backports if there are no incompatible issues around that
[19:16]  * slangasek gibbers softly
[19:17] <slangasek> mvo: we not only would have to add dpkg to backports, we would also have to configure multiarch before calculating the dist-upgrade
[19:17] <slangasek> mvo: I don't think this sounds like a winning plan :)
[19:21] <mvo> slangasek: well, I think that this is possible and maybe even a good idea, there is some code in u-m for this already that AFAICT is not being used right now but we could enable it
[19:22] <mvo> slangasek: we can talk in more detail tomorrow and/or I can create a test branch for it that might be able to even upgrade skype, I can do a test VM and check I guess
[19:22] <slangasek> mvo: it still strikes me as a big change to make a week and a half before release; all of our lucid->precise upgrade testing so far has been without multiarch enabled
[19:23] <slangasek> mvo: given those options, I would prefer to just drop skype from the blacklist
[19:23] <slangasek> since the user can just reinstall it after upgrade
[19:23] <slangasek> cr3: hi, around?
[19:24] <cr3> slangasek: sure, what's up?
[19:24] <slangasek> cr3: I was wondering, does Ubuntu Friendly also know how much RAM these machines have?
[19:26] <cr3> slangasek: unfortunately not, I've been meaning to add that for a while :(
[19:26] <slangasek> ok
[19:26] <slangasek> no worries :)
[19:27] <mvo> slangasek: I agree, we have a bit of time until lts upgrades are enabled, but I still agree, its risky so not good
[19:27] <cr3> slangasek: the data is there though, so I should eventually be able to mine it and retrofit reports
[19:28] <slangasek> mvo: do you want to axe it from the blacklist, then/
[19:29] <mvo> slangasek: already commited that ;)
[19:29] <slangasek> cheers :)
[19:29] <slangasek> mvo: will you upload today, or would you like me to so you can punch out? :)
[19:30] <mvo> slangasek: I bzr-buildpackage now
[19:30] <slangasek> ok
[19:43] <barry> slangasek, mvo: https://code.launchpad.net/~barry/update-manager/bug-873468/+merge/102378
[19:43] <barry> slangasek: ignore the conflict, if the scanner hasn't yet updated the branch
[19:45] <barry> @pilot in
[19:56] <slangasek> barry: merging that does a number on debian/changelog
[19:56] <slangasek> barry: can you fix that up and resubmit? (0.156.12 has just been uploaded)
[19:56] <barry> slangasek: gah.  the conflict resolved locally, but clearly the mp shows there are still problems.  fixing...
[19:57] <barry> slangasek: i'm just going to revert the changelog entry.  we can always add one when it gets uploaded
[19:58] <slangasek> well, since you can upload it directly, that's fair :)
[19:58] <barry> slangasek: except i suppose i should merge it to trunk first ;)
[19:58] <slangasek> yes please
[19:59] <slangasek> barry: why "packaging information" rather than the original "package information"?
[19:59] <barry> slangasek: that was *your* suggestion! :)
[19:59] <slangasek> I was afraid of that ;)
[19:59] <slangasek> that was a cut'n'waste on my part then
[19:59] <barry> i can change that back though
[19:59] <slangasek> I think the original "package" reads better
[20:00] <barry> agreed
[20:00] <slangasek> Looks ok to me.  You're happy with the wording otherwise?
[20:00] <barry> slangasek: r2382 should do the trick
[20:01] <barry> slangasek: yep
[20:02] <barry> slangasek: if you're good with it, i'll merge to trunk and upload
[20:02] <slangasek> barry: yep, looks good to me
[20:02] <barry> slangasek: thanks!
[20:12]  * barry feels the pain of pre-build.sh
[20:12] <slangasek> :)
[20:14] <barry> and the fact that pre-build.sh requires additional build-deps not expressed in the d/control file ;)
[20:15] <slangasek> yep
[20:16] <barry> getting closer tho :)
[20:25] <barry> slangasek: uploaded
[20:25] <slangasek> woot
[20:25] <slangasek> barry: thanks
[20:25] <barry> np!
[20:37] <slangasek> barry: do you know why tests/data-sources-list-test/sources.list changed?
[20:38] <barry> slangasek: could that be an artifact of pre-build.sh?
[20:38] <slangasek> maybe
[20:38] <slangasek> but it references feisty, which is what's weirding me out :)
[20:38] <barry> slangasek: i see those files are 'unknown' to bzr
[20:38]  * slangasek nods
[20:38] <slangasek> well, accepting
[20:39] <barry> that *is* odd.  i built the source package in a precise chroot because of the btrfs requirement
[20:39] <barry> precise-amd64 to be, er, precise, which i use all the time so i'm fairly sure it's sane
[20:40] <infinity> slangasek: Probably doesn't need to keep cluttering up #is
[20:40] <infinity> adconrad@cthulhu:~$ sudo su -s /bin/sh -c 'echo $PATH' - adconrad
[20:40] <infinity> /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
[20:40] <infinity> adconrad@cthulhu:~$ sudo su -s /bin/sh -c 'echo $PATH' adconrad
[20:40] <infinity> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[20:40] <infinity> slangasek: ^-- It's definitely the '-' versus not.
[20:41] <infinity> slangasek: Maybe su doesn't actually invoke login, but rather tries to mimic it, thus parsing login.defs and being silly about it?
[20:41] <slangasek> maybe, yes
[20:41] <infinity> slangasek: Cause, yeah, a console login is fine.
[20:41] <infinity> slangasek: That said, if we're shipping a default in /etc/environment, shouldn't login.defs match anyway?
[20:42] <slangasek> wouldn't that be something?
[20:42]  * infinity smirks.
[20:42] <slangasek> so there seem to be four different sources for path - two in /etc/login.defs, one in /etc/sudoers, one in /etc/environment :P
[20:43] <infinity> slangasek: Yeahp, and all but one of those match.
[20:43] <infinity> slangasek: So, fixing the fourth would be reasonable, methinks.
[20:44] <infinity> Well, I guess neither one in login.defs matches, cause it thinks root shouldn't play games.
[20:45] <infinity> But we should probably just make both match the Ubuntu worldview.
[20:46] <slangasek> no, root not playing games is certainly by desin
[20:46] <slangasek> design
[20:47] <slangasek> likewise for sudoers' secure_path
[20:48] <infinity> slangasek: Okay, so we just want to update the non-su path in login.defs to match the one in /etc/environment.
[20:48] <infinity> slangasek: And then we have two user paths and two su paths, both matching.
[20:48] <slangasek> for a first pass, yes
[20:48] <infinity> Do we consider this RC?
[20:48] <slangasek> long-term, we should fix whatever's keeping su - from using /etc/environment
[20:48] <slangasek> no
[20:49] <infinity> Alright, so we just get elmo to puppetise that change for all his login.defs? ;)
[20:49] <slangasek> not unless it's new since oneiric?
[20:49] <slangasek> yeah
[20:49] <infinity> It's new since something older.  No idea which older.
[20:49] <infinity> New since lucid would still be a problem, I'd say.
[20:49] <infinity> LTS->LTS and all.
[20:49] <slangasek> that's worth pinning down
[20:49] <slangasek> yes, which would make it important for .1
[20:49] <dupondje> Do we have a some release notes already somewhere ? :)
[20:50] <bdmurray> slangasek: I noticed mov removed my fix for bug 969182.  Do you know if there is a better solution?
[20:50] <infinity> slangasek: New since natty too.  We have natty buildds, and they work.
[20:50] <infinity> slangasek: (All the pandas are natty)
[20:50] <slangasek> bdmurray: he applied another fix
[20:50] <slangasek> bdmurray: (see changelog)
[20:52] <bdmurray> slangasek: I'd seen the changelog just not made the connection between the removal and lines before it ;-)
[20:52] <slangasek> bdmurray: ah :)
[22:22] <bdmurray> slangasek: could you take a look at bug 982140?
[22:53] <sbeattie> bdmurray: bug 983559 should probably go on your radar
[23:00] <slangasek> bdmurray: 982140 - duplicate of the dpkg SRU bug
[23:00] <slangasek> bug #902603
[23:03] <bdmurray> slangasek: it seems to me there could be a search done for those bugs … 'Noting disappearnce' for an :i386 package on a amd64 system.  Does that sound about right?
[23:04] <slangasek> bdmurray: yes, definitely
[23:05] <slangasek> bdmurray: though I think the higher priority is for someone to verify the SRU so we get a fixed dpkg out to protect people from hitting this one
[23:53] <barry> @pilot out
[23:56] <barry> bdmurray: can lp bugs be un-duped? and if so, do you need special permission to do so?
[23:57] <bdmurray> barry: yes, no
[23:58] <barry> bdmurray: i suck.  where is the magic button? ;)
[23:58] <StevenK> "Unmark as duplicate" top right?
[23:59] <barry> StevenK: am i smoking crack?  https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/773823