[00:07] <slangasek> bryce: bug #1066883 can only be a plymouth bug if there's a regression in lightdm's handling of shutting down plymouth; is there any reason to think that might be the case?
[00:07] <ubottu> Launchpad bug 1066883 in linux (Ubuntu Quantal) "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
[00:08] <bryce> slangasek, feel free to reassign to where you think it belongs
=== SolidLiq is now known as CodeGuru
[03:33] <pitti> Good morning
[03:36] <RAOF> Ho pitti!
[03:36]  * RAOF seems to remember having a question to ask pitti, but not what that question actually was.
=== vibhav is now known as ringtail
[04:33] <joiseystud> anyone know when QQ final will be released?
[04:34] <lifeless> see #ubuntu-release :)
[04:34] <micahg> #ubuntu-release-party would probably be better
[04:34] <pitti> every time someone asks for the precise time, a kitten dies
[04:34] <joiseystud> lol
[04:34] <sarnold> poor kitten
[04:34] <joiseystud> thanks
[04:34] <pitti> sarnold: exactly!
[04:35] <micahg> Thu Oct 18 04:34:51 UTC 2012 on my precise system :P
[04:35] <sarnold> micahg: wow, one of our clocks really skewed, looks like you're fifteen seconds in the past!
[04:38] <ScottK> lifeless: Please don't send them to #ubuntu-release.
[04:59] <lifeless> ScottK: doh, I meant -party. Sorry.
[05:10] <RAOF> pitti: Oh! I've remembered the question I was going to ask - is it possible to influence how the apport retracer munges the bug reports it touches?
[05:42] <pitti> RAOF: not much right now, what are you trying to do?
[05:44] <RAOF> pitti: I was thinking of post-processing the xserver backtraces and pulling out the interesting information - basically the top 4 frames of an xserver backtrace contain no useful information.
[05:45] <pitti> RAOF: apport has a thing called "stack unwinding" which chops off things like the implementation details of g_assert() and g_log_(), to get to the "interesting" part
[05:45] <pitti> RAOF: the trimming you want to do, would you say this applies to all X-ish backtraces, or is that just a special subset?
[05:45] <RAOF> All xserver crashes, I think.
[05:46] <pitti> RAOF: we don't currently have hooks which run on the retracer side, that would be too brittle and also insecure
[05:46] <RAOF> Plus I'd like to pull out the signal that killed X.
[05:46] <pitti> RAOF: the latter sounds like something which should happen on the client side?
[05:46] <pitti> RAOF: ah, I remember that weirdness of X's signal handlers :)
[05:47] <RAOF> Yeah - X catches everything and then abort()s
[05:47] <pitti> RAOF: so perhaps apport on the client side should have some code to set Signal: to the real thing?
[05:47] <pitti> and the stack unwinder should be updated to get rid of X' signal handlers/logging stuff
[05:48] <RAOF> As long as we can get the signal out, yes.
[05:48] <pitti> RAOF: as for the unwinding, the code is at http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L714
[05:48] <pitti> RAOF: and the corresponding tests at http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/test/test_report.py#L1403
[05:49] <pitti> RAOF: if that's all gibberish to you, I propose you file a bug with linking to a few example bugs, and explain what part of the stack trace shoudl be chopped off?
[05:49] <RAOF> I'll have a butcher's.
[05:49] <RAOF> Thanks.
[05:49] <pitti> RAOF: i. e. you tell me how it should look like, then we transform that into test cases, and then hack gen_stacktrace_top() into submission
[05:50] <pitti> RAOF: we actually already have X error handling there, but perhaps it's out of date
[05:51] <RAOF> Yeah, we have _Xerror handling.
[05:52] <lbbef> Hi, I would like to help update the blender package in the universe repo, how do i go about doing that?
[05:56] <SpamapS> lbbef: #ubuntu-motu would be better, since its a universe package. But.. basically you'll want to follow the packaging guide..
[05:56] <SpamapS> lbbef: https://wiki.ubuntu.com/PackagingGuide
[05:57] <SpamapS> lbbef: note that the debian maintainer will likely update to 2.64a soon, and then that will sync/merge into the next release (raring) when auto-syncs start
[06:35] <dholbach> good morning
[06:41] <pitti> jibel: FYI, jhbuild doesn't run xvfb for "make check", only for some test modules (ldtp, dogtail)
[06:41] <pitti> jibel: I'm filing an upstream bug now to discuss whether it should (I think it should)
[06:41] <pitti> jibel: in the meantime, I'll work on a charm fix to run it through xvfb-run by itself, ok?
[06:46] <jibel> pitti, ok.
[07:13] <pitti> lool: bonne anniversaire!
=== smb` is now known as smb
[07:20] <dholbach> lool, bon anniversaire, mon ami! :)
=== jamesh_ is now known as jamesh
[07:26] <didrocks> google betrayed him, right? :)
[07:27] <pitti> didrocks: you mean me or lool?
[07:27] <didrocks> lool ;)
[07:28] <didrocks> that's how I noticed TBH, telling "oh this guy is older…" :p
=== yofel_ is now known as yofel
[07:32] <pitti> but lool's birthday _is_ today, unless he lied in the directory ;)
[07:33] <didrocks> yeah, I meant, he couldn't lied in the directory and in google, there are prooves all over the place! :)
[07:37] <pitti> jibel: https://code.launchpad.net/~pitti/charms/quantal/jhbuild/run-under-xvfb/+merge/130294
[07:37] <pitti> jibel: I will now work on a config option to use jhbuild from git instead of the packaged version, as this is more appropriate and robust
[07:40] <jibel> pitti, ok, thanks. I'll merge your xvfb change ASAP as the charm is under review for charmstore inclusion and it'd be nice to have it.
[07:40] <pitti> jibel: *nod*
[07:57] <pitti> jibel: hm, curious that you didn't stumble over the missing python-dbus package (glib tests fail due to that); I'm going to propose a merge
[08:05] <pitti> jibel: MP sent for this, too
[08:21] <jibel> pitti, I added on the internal instance IIRC, let me check.
[08:22] <lool> pitti, dholbach, didrocks: Thanks all!  :-)
[08:28] <jibel> pitti, actually dbus-python is a dependency of gnome-core but not glib, so the bug is in the moduleset. python-dbus should be built before not after glib
[08:29] <pitti> jibel: ah, so it would work the second time
[08:30] <jibel> pitti, yes, if you build all the packages of gnome-core, if you build only glib and it's dependencies it will fail.
[08:31] <jibel> pitti, since I started by building everything without check to make sure all the build dependencies were met, I didn't notice.
[08:31] <pitti> jibel: ok, then perhaps the MP is moot; I'll file an upstream glib bug with a suggested jhbuild patch
=== tkamppeter_ is now known as tkamppeter
[08:33] <pitti> jibel: oh, juju deploy only uses the bzr committed bits, not the uncommited ones?
[08:33]  * pitti tears down test unit and retries
[08:40] <pitti> jibel: oh, heh, can't
[08:40] <pitti> jibel: dbus-python needs glib and GI to build
[08:41] <pitti> jibel: so it'd be a circular dependency
[08:41] <pitti> so perhaps installing the package would be ok after all
[08:41]  * pitti makes a note in the MP
[08:42] <bkerensa> cyphermox: is there any reason why ipv6 is set to automatic in 12.10 for network-manager? This seems to add anywhere from a few hundred milliseconds to a couple seconds of lag time when connection to networks that do not support IPv6
[08:42] <bkerensa> ?
[08:43] <bkerensa> !s/connection/connecting
=== henrix_ is now known as henrix
[08:45] <jibel> pitti, hm, it is not installed here and the test pass, unless I missed something. I'm rerunning a check of glib
[08:45] <pitti> jibel: presumably it's installed in ~/gnome then?
[08:52] <xnox> ivanka: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-landscape-fde
[08:54] <jibel> pitti, correct, it is installed in ~/gnome/packages
[08:56] <stgraber> bkerensa: ipv6 is enabled by default on Ubuntu because that's the right thing to do as it's getting more and more popular. However NM considers the network as up and running if any of ipv4 or ipv6 is working, so it shouldn't add any delay. If it does, file a bug so cyphermox can take a look.
[08:57] <bkerensa> stgraber: ok
[08:58] <bkerensa> stgraber: my understanding is its actually a known delay http://blogs.gnome.org/desrt/2011/06/14/quick-network-manager-note/
[08:59] <bkerensa> stgraber: there also seems to be a bug in debian for it too
=== sgnb` is now known as sgnb
[09:00] <stgraber> bkerensa: that blog post is pretty old... a lot of IPv6 work happened for 12.04 and 12.10, better talk to cyphermox
[09:00] <bkerensa> stgraber: ok I will ping him
[09:02] <pitti> jibel: there are more loops like that; I think building everything without --check first, and then again with --check is better
[10:23] <develop7> hello all. What is *proper* way to get sources of package from precise with bzr? `bzr branch ubuntu:p/network-manager` says "bzr: ERROR: Not a branch:`,  `bzr branch ubuntu:precise/network-manager` says "bzr: ERROR: Revision {package-import@ubuntu.com-20120316143219-pj6ax8nyf4n504ry} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"."
[10:28] <develop7> should I report a bug?
[10:30] <cjwatson> yes, on launchpad.net/udd
[10:31] <cjwatson> some packages just can't be fetched using bzr - the always-works method to get source for any package is still 'apt-get source PACKAGE-NAME' (or pull-lp-source from ubuntu-dev-tools makes it easy to get any version, if you want source for a version that doesn't match your running system)
[10:33] <tumbleweed> (pull-lp-source is broken today, because it's quantal release day and it doesn't know about raring yet)
[10:34] <Laney> deja vu
[10:38] <develop7> cwatson, got that, thanks
[10:45] <tkamppeter> pitti, can you have a look at bug 1026921? Will CUPS need some improvement here? Or should we simply tell the user to touch the missing file and all is OK?
[10:45] <ubottu> Launchpad bug 1026921 in cups (Ubuntu) "package cups 1.5.3-0ubuntu1 failed to instal/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Invalid] https://launchpad.net/bugs/1026921
[10:45] <pitti> tkamppeter: yeah, that shoudl work, and then sudo apt-get -f install
[10:48] <tkamppeter> pitti, so we simply tell this to the user and close the issue?
[10:48] <pitti> tkamppeter: yes, I think so
[10:52] <develop7> I'm filling a merge request in LP. What is proper branch for merge request to network-manager in quantal? I'm aware it's frozen — I'm hoping my patch is going to hit proposed or something.
[10:52] <develop7> here is branch itself — https://code.launchpad.net/~develop7/network-manager/dnsmasq-conf-dir-cherrypick
[10:54] <tkamppeter> pitti, what I have seen is that if there is something wrong in /etc/cups/cupsd.conf making the CUPS daemon not start this blocks the whole apt-get mechanism. Should we improve on this somehow in R?
[10:54] <develop7> This is cherry-pick from upstream, so there's no need to merge it to lp:network-manager
[10:55] <pitti> tkamppeter: this is how Debian packages behave in general; I don't have a good answer to this, I'm afraid, as the other option is to leave it broken silently
[10:55] <pitti> tkamppeter: if people or programs often mess up cups.conf, then changing the postinst to not fail on failed start might be an option, yes
[10:57] <tkamppeter> pitti, or could the postinst then pop up a debconf like screen telling that the CUPS system could not be started and giving the option to continue or abort the installation?
[10:57] <pitti> nono, please no debconf
[10:58] <cjwatson> develop7: 'apt-cache showsrc network-manager' says lp:~network-manager/network-manager/ubuntu (but if you're filing a merge proposal against that, make sure you branched from that in the first place)
[11:01] <tkamppeter> pitti, OK. debconf is really very complicated to set up and we should reduce its use.
=== MacSlow is now known as MacSlow|lunch
=== cpg is now known as cpg|away
[11:39] <Andy80> hi, is there any know issue with Nvidia GeForce GT 640 graphic card? I've just upgraded my work machine to quantal and even if I'm using the same driver version (304.51), now the maximum resolution is 1024x768 while it was 1680x1050. p.s: on precise I was using the x-swat PPA to have 304.51 of course...
[11:44] <develop7> cjwatson: that branch contains only debian directory. should I convert my branch to debian patch, and request a merge of patch, not source?
[11:45] <cjwatson> develop7: yes
[11:47] <develop7> cjwatson: awesome, thank you
=== _salem is now known as salem_
[12:10] <cyphermox> bkerensa: ipv4 and ipv6 gets done in parallel, there shouldn't actually be a delay caused by ipv6 if you don't have it; maybe file a bug so we can see what's wrong
[12:11] <cyphermox> develop7: we already carry that upstream change in quantal.
[12:11] <develop7> cyphermox: yeah, I've noticed that. whew.
[12:13] <cyphermox> ok ;)
[12:14] <cyphermox> oh, wait, perhaps I'm getting confused by a previous message, you want to SRU that to precise?
[12:16] <develop7> cyphermox: well, that would be perfect, but I don't insist, I'm planning to upgrade anyway
[12:16] <develop7> e.g. upgrade to quantal
[12:17] <cyphermox> develop7: ok
=== MacSlow|lunch is now known as MacSlow
[12:54] <tkamppeter> pitti, seems that there are major problems with the AppArmor stuff in CUPS, see bug 1026921.
[12:54] <ubottu> Launchpad bug 1026921 in cups (Ubuntu) "package cups 1.5.3-0ubuntu1 failed to instal/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Invalid] https://launchpad.net/bugs/1026921
[12:58] <jdstrand> tkamppeter: I think that is overstating it. the main profile is installed in /etc/apparmor.d/usr.sbin.cupsd. the packaging will create /etc/apparmor.d/local/usr.sbin.cupsd. the main profile needs the second. the user doesn't have the second. it isn't clear the touch command was run
[12:58] <jdstrand> the second is also intentionally not a conffile
[13:00] <jdstrand> tkamppeter: if the cups packaging doesn't use dh_apparmor, then the packaging needs to create it
[13:01] <jdstrand> I just did some iso testing yesterday and /etc/apparmor.d/local/usr.sbin.cupsd was created
[13:01] <jdstrand> gotta run
[14:07] <GunnarHj> Riddell: Hi Jonathan! Are you there?
[14:08] <Riddell> GunnarHj: I am
[14:08] <GunnarHj> Ridell: Great! I noticed that Kubuntu quantal is shipped without language-selector-kde. Does it mean that you have replaced language-selector with other code in Kubuntu, and that we may now drop language-selector-kde in the language-selector source package?
[14:10] <Riddell> GunnarHj: might be best to wait until after UDS
[14:10] <Riddell> I replaced it with a patch to the KDE language config tool, but it's a bit limited and doesn't have all the features
[14:10] <Riddell> but going back to language-selector-kde isn't an easy option as we can't do python 3 plugins to kde system settings
[14:11] <pitti> Riddell: well, we've been trying for several releases to get rid of it actually :)
[14:11] <pitti> in favor of moving to the one from gnome-control-center (but that's still not on feature parity)
[14:11] <Riddell> pitti: I know, this was my initial desire to change out, then the python 3 switch stopped a chance of changing back
[14:13] <GunnarHj> Riddell: Really? I got the impression that your current language/locale thing is rather complete. But it's no hurry; it can of course wait til after the UDS.
[14:13] <Riddell> it misses various things like setting up input methods and notifying if you don't have them all installed
[14:14] <GunnarHj> Riddell: Ok, I see.
[14:16] <GunnarHj> pitti: I'm going to write a document for UDS about differences between l-s and the region capplet in g-c-c.
[14:16] <pitti> GunnarHj: ah, that's helpful, thanks!
=== davidcalle_ is now known as davidcalle
[14:47] <doko> hallyn, ping
[14:56] <hallyn> doko: hi
=== dArKd3ViL is now known as dArKd3ViL_
[14:57] <doko> hallyn, was just looking at your sparc cross toolchain packages? are these built for biarch sparc?
[14:58] <hallyn> doko: i was just building for sparc64 (i think) so that the openbios-sparc package could be built from that for sparc32 and sparc64
[14:58] <hallyn> doko: though i'm starting to think i don't need sparc, i only need powerpc
[14:58] <doko> ahh, ok
[14:58] <hallyn> hm, no, i guess we do.
[14:59] <hallyn> doko: building for sparc32 would be a completely separate set of packages with almost identical soruce, iiuc
[15:00] <hallyn> what on earth?  ppa says build failed, but https://launchpadlibrarian.net/119958672/buildlog_ubuntu-quantal-amd64.binutils-sparc-cross_1.86ppa1_BUILDING.txt.gz says it succeeded
[15:00] <doko> hallyn, no my question was if the build is configured with --enable-multilib. But I assume you're not that interested in the packaging like it's done for the linaro arm cross packages
[15:01] <hallyn> doko: oh.  right i just want to be able to use it to build openbios for qemu;  but i did use the arm packages as a base.
[15:02] <hallyn> i don't see enable-multilib in the buildlog
=== elmo__ is now known as elmo
=== Mez_ is now known as Mez
[15:18] <stokachu> infinity: ive got a definition addition for eglibc http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=cf7c9078a5acdbb435498ace92cd81009637a971
[15:18] <stokachu> infinity: is this something you would entertainf or lucid?
[15:19] <stokachu> infinity: a backport for libhugetlbfs exist in lucid https://bugs.launchpad.net/lucid-backports/+bug/1035365
[15:19] <ubottu> Launchpad bug 1035365 in lucid-backports "Please backport libhugetlbfs 2.11-0ubuntu1 (universe) from natty" [Undecided,Fix released]
[15:19] <stokachu> and i believe this patch is whats needed to make this work
[15:20] <micahg> umm, if it didn't work, how did it "run"?
[15:31] <infinity> stokachu: Do I want to know why we care about hugetlb in lucid and why we're not just telling people who need it to upgrade to precise?
[15:39] <stokachu> infinity: lol probably not
[15:40] <stokachu> infinity: however, if you say no (with a possible explanation) it is perfectly acceptable to run with that
[15:41] <stokachu> to me this feels like a feature request whereas lucid is basically in a state of accepting crtical's and other bug fixes
[15:41] <infinity> stokachu: Your explanation there seems like the right one.
[15:41] <infinity> stokachu: That said, we still need to SRU the AVX disabling fix to lucid, so we could dump this in with it.
[15:42] <stokachu> infinity: thats totally your call
[15:42] <infinity> stokachu: I'm not against the change, it's minimal and auditable, just against upload for JUST that.
[15:42] <stokachu> infinity: im currently building eglibc with the patch
[15:43] <stokachu> infinity: ok sounds good -- ill finish the build and have the interested party test it
[15:43] <stokachu> infinity: if all is well ill update the avx sru to include this other bug
[15:44] <infinity> stokachu: That sounds reasonable to me.
[15:44] <stokachu> infinity: cool, ill probably ping you in a couple days once the customer has tested
[15:44] <stokachu> err 'interested party'
[15:44] <stokachu> lol
[15:45] <infinity> stokachu: Shiny.  I'd like us to get those old AVX SRUs out of the way so they stop nagging my TODO.
[15:45] <stokachu> infinity: sweet, thanks man
[15:45] <infinity> stokachu: And the one for lucid is really more just a violent "break AVX" fix, so less effort than precise's "fix it all to behave correctly" thing.
[15:46] <infinity> stokachu: So, should be a bit easier (I hope) for us to verify.
[15:46] <infinity> stokachu: Oh, I'm guessing you guys noticed that the precise one finally landed in updates?
[15:46] <stokachu> infinity: we sure did
[15:46] <stokachu> infinity++
[15:46] <infinity> I should rebuild d-i for precise tomorrow for that.
[15:47] <infinity> Maybe I'll wait for the current round of SRU kernels to land, and kill two birds with one stone.
[15:48] <infinity> And fix the omap netinst bug too.
[15:48] <infinity> So, three birds.
[15:48] <infinity> That's some stone.
[15:49] <Laney> poor birds
[15:49] <infinity> They had it coming.
[15:49]  * micahg thinks the kittens were behind it
[15:50] <astraljava> So infinity was the one who stole the bird out of Xubuntu wallpaper. *grumble*
[15:55] <stokachu> doko: if you got a second could you approve series nominations for bug http://pad.lv/802782
[15:55] <ubottu> Launchpad bug 802782 in network-manager (Ubuntu) "Please add NetworkManager option not to auto-enable new network devices" [Wishlist,Confirmed]
[15:57] <stokachu> babaei: die antwoord?
[15:59] <doko> stokachu, done
[16:00] <stokachu> doko: thanks! :D
[16:07] <stokachu> doko: sorry one more, http://pad.lv/1068199, spoke with infinity on it and going to try and get this included with another SRU approved to go in
[16:07] <ubottu> Launchpad bug 1068199 in eglibc (Ubuntu) "please add support for MAP_HUGETLB in eglibc for Lucid" [Undecided,New]
[16:10] <doko> stokachu, done
[16:10] <stokachu> doko: thanks again
[16:11] <quadrispro> hello everybody
[16:30] <mitya57> Does anybody think we can cherry-pick this lintian commit:
[16:30] <mitya57> http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commitdiff;h=c04b5ad34c;hp=0c7245dcba
[16:31] <micahg> mitya57: why?
[16:31] <ScottK> There's no need.
[16:31] <mitya57> to make lintian not complain about packages using s-v 3.9.4 that are built on quantal
[16:32] <cjwatson> who cares :)
[16:32] <babaei> stokachu: ummm, no?
[16:32] <cjwatson> lintian output is meant to be read intelligently by humans
[16:32] <cjwatson> who can ignore stuff that doesn't matter
[16:33] <stokachu> babaei: saw your id as 'zef' was curious if you knew the south african rap group :)
[16:33] <mitya57> OK, and will we teach it that raring is a valid codename?
[16:33] <babaei> ah. nope.
[16:33] <ScottK> In raring.
[16:34] <ScottK> Once again, one can ignore it.
[16:34] <stokachu> mitya57: in NC we have to euthanized raccoons because they are rabies vectors
[16:34] <mitya57> OK.
[16:34] <micahg> mitya57: I'd be happy to entertain a lintian backport if you're interested in testing the reverse dependencies, but yeah, what everyone else said
[16:35] <micahg> (full backport, not cherry pick)
[16:35] <slangasek> cjwatson: well, the difference between empty and non-empty lintian output has an annoying cost in attention in order to do that ignoring.... but meh, why would anybody be using the quantal lintian for 3.9.4 S-V packages
[16:36] <mitya57> I've anyway filed bug 1068208 (with a patch attached) to get it fixed in raring at least
[16:36] <ubottu> Launchpad bug 1068208 in lintian (Ubuntu) "Needs to know about raring" [Undecided,Triaged] https://launchpad.net/bugs/1068208
[16:36] <micahg> wait, this fix isn't even in Debian yet?  Why would we bother...
[16:36] <ScottK> mitya57: The usual practice is to update in Debian first.
[16:37] <ScottK> slangasek: lintian will whine when you make a source package too, so for those of us that run current and build in sbuild/pbuilder, it'll definitely come up.
[16:37] <mitya57> I don't know why you call it usual (bug 994208 was fixed in Ubuntu first), but I agree anyway
[16:37] <ubottu> Launchpad bug 994208 in clang (Ubuntu) "Needs to know about quantal" [Undecided,In progress] https://launchpad.net/bugs/994208
=== sforshee` is now known as sforshee
[16:38] <slangasek> ScottK: addressed by getting raring open and updating lintian there? :)
[16:38] <ScottK> Certainly.
[16:39] <ScottK> mitya57: Usual for lintian.
[16:39] <stokachu> slangasek: ok i made those requested changes to appmenu-gtk for the build deps
[16:39] <stokachu> slangasek: *hopefully* thats everything /me crosses fingers
[16:39] <cjwatson> slangasek: well, yeah, exactly
[16:40] <cjwatson> and there's always grep
[16:40] <cjwatson> or lintian profiles if you want to overachieve
[16:41] <micahg> stokachu: as mentioned in PM, I have the changes staged in the desktop VCS (my local copy with me changing the build-deps), it's ready for upload if that's ok
[16:41] <stokachu> micahg: sorry i didnt see your PM light up :(
[16:41] <stokachu> micahg: yes please do if thats ok
[16:42] <micahg> stokachu: ok, uploaded
[16:42] <stokachu> micahg: awesome thank you very much for your help
[16:43] <micahg> stokachu: now I can't get the branch up though :(
[16:43]  * micahg blames debcheckout
[16:44] <stokachu> appmenu doesn't like change apparently :)
[16:44] <micahg> stokachu: that was quantal, I'll upload precise a little later
[16:44] <stokachu> sounds good to me
[16:51] <tkamppeter> Are the ISOs linked on http://releases.ubuntu.com/quantal/ already the finals?
[16:56] <ScottK> tkamppeter: #ubuntu-release-party - otherwise wait for the announcement like everyone else :)
=== deryck is now known as deryck[lunch]
=== sarnold_ is now known as sarnold
=== ChanServ changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== directhe` is now known as directhex
[17:19] <mitya57> congrats to everybody!
[17:29] <mapreri> Good work people! :)
=== Ursinha-afk is now known as Ursinha
[17:44] <stokachu> infinity: ok i got that eglibc patch uploaded and sru done: http://pad.lv/1068199
[17:44] <ubottu> Launchpad bug 1068199 in eglibc (Ubuntu Lucid) "please add support for MAP_HUGETLB in eglibc for Lucid" [High,In progress]
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[17:58] <ScottK> pitti: The HISTORY file for postgresql 9.1.6 says, "However, you may need to perform "REINDEX" operations to recover from,  the effects of the data corruption bug described in the first changelog item below." - Does that need some kind of debian/NEWS entry or such to let people know?
=== Ursinha is now known as Ursinha-afk
=== deryck[lunch] is now known as deryck
[18:26] <stokachu> micahg: did the appmenu-gtk for precise go through yet?
[18:27] <micahg> stokachu: no, not yet, I saw the unsubscribe sponsors thing though, it's still on my list
[18:28] <stokachu> micahg: ok cool no worries
[18:35] <nigelb> asac: Your twitter account seems to be sending spam via DM.
[18:35] <nigelb> (FYI)
=== norbi is now known as Guest16930
[19:20] <alexbligh> possibly stupid question: on a normal boot, am I correct (as I believe) that the stuff in /etc/rc.S is not run? I am trying to work out why /etc/init.d/multipath-tools-boot (only run from rcS) needs to modprobe dm-multipath but /etc/init.d/multipath-tools (run from elsewhere) does not.
[19:22] <sarnold> I've got no /etc/rc.S on my system any longer; is it a hold-over from earlier inits that you may have had installed?
[19:22] <slangasek> alexbligh: /etc/rcS.d (assuming the previous path you gave was a typo) is run at boot.
=== rsalveti_ is now known as rsalveti
=== Ursinha-afk is now known as Ursinha
[19:34] <alexbligh> slangasek, hmm, even if one's going multi user? I never knew that.
[19:35] <slangasek> yes
[19:36] <slangasek> historically, it's the directory for scripts that do "put together enough of the system's brain so we can start a runlevel"
[19:41] <alexbligh> slangasek, is it run from upstart these days then?
[19:41] <slangasek> everything is run from upstart these days. :)
[19:47] <bdmurray> slangasek: are you familiar with bug 1066445? I'd like to verify the fix in precise-proposed but the test case didn't work out.
[19:47] <ubottu> Launchpad bug 1066445 in apt (Debian) "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Unknown,New] https://launchpad.net/bugs/1066445
[19:48] <bdmurray> well the alternative one at least
[19:48] <slangasek> bdmurray: yeah, a test case for that is problematic, it basically comes down to hitting a magic cache size with the apt lists
[19:49] <slangasek> bdmurray: you might want to start with the known-buggy version of apt in quantal, reproduce it there, and then downgrade to the precise apt to see if it's still reproducible
=== cpg|away is now known as cpg
=== henrix is now known as henrix_
[20:21] <asac> nigelb: thanks
[20:22] <asac> nigelb: not sure... changed password and removed access to all apps in case that was it
[20:31] <highvoltage> ~/win 11
[21:12] <wmp_> hello, i have problem... on 12.10 i have only one thread on CPU
[21:12] <wmp_> on 12.04 work good
[21:12] <sarnold> wmp_: what's the output of 'uname -a'?
[21:13] <wmp_> 3.5.0-17-generic
[21:13] <wmp_> x86_64
[21:13] <sarnold> no 'SMP'?
[21:13] <wmp_> "inux wmp-AO722 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[21:13] <slangasek> wacky
[21:14] <slangasek> wmp_: please file a bug report against the linux package by running 'ubuntu-bug linux'; this will attach logs (dmesg, etc) that should help the kernel team figure it out
[21:14] <wmp_> amd c-50 processor on acer aspire one 722
[21:16] <wmp_> maybe i shoud use PAE kernel?
[21:17] <ScottK> wmp_: On amd64, -generic is PAE.
[21:17] <ScottK> Actually it's PAE on i386 now too.
[21:17] <slangasek> on amd64, there's no such thing as PAE
[21:18] <ScottK> Right.
[21:18] <slangasek> (since PAE is a kludge to give you paged access to a larger space than is addressable in 32 bits)
[21:18] <wmp_> hmmm, interesting
[21:19] <wmp_> after reboot i go to bios setup
[21:19] <wmp_> exit without save changes
[21:19] <wmp_> and go to rescure mode
[21:19] <wmp_> and from root in rescure i have 2 threads
=== Ursinha is now known as Ursinha-afk
[21:21] <wmp_> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1068340
[21:21] <ubottu> Launchpad bug 1068340 in linux (Ubuntu) "I havent second thread" [Undecided,New]
[21:25] <sarnold> wmp_: "Booting paravirtualized kernel on bare hardware"
[21:26] <sarnold> oh, never mind, I've got that too. :/
[21:26] <wmp_> ? i dont understand
[21:26] <wmp_> ok
[21:26] <wmp_> :)
[21:26] <wmp_> so i go try if in rescur ei have 2 threads
=== cpg is now known as cpg|away
[21:27] <sarnold> "CPU1: Not responding."
[21:39] <wmp_> lol
[21:40] <wmp_> now i have 2 threads
[21:40] <wmp_> and i dont know why
[21:41] <sarnold> wmp_: from your dmesg, "CPU1: Not responding."
[21:41] <wmp_> now i havent this, but before yes
[21:42] <wmp_> and now i installing amd64-microcode
[21:42] <wmp_> sarnold: can i reboot or you want to check some?
[21:42] <sarnold> wmp_: don't mind me, I think your problems are well beyond my abilities  ;(
[21:43] <wmp_> ;(
[21:43] <sarnold> wmp_: I'm just afraid you may have dying hardware
[21:43] <wmp_> sarnold: so why on 12.04 work good? :D
[21:43] <wmp_> ok, reboot
[21:46] <wmp_> and one thread :(
[21:47] <sarnold> wmp_: I don't know why 12.04 would have supported more, but 12.10 doesn't. It _is_ strange..
[21:48] <wmp_> sarnold: now i try with noapic acpi=off
[21:49] <sarnold> wmp_: acpi is required to enumerate hyperthreads
[21:49] <wmp_> sarnold: but on 12.04 i have acpi=off
[21:49] <wmp_> and: http://ubuntuforums.org/showthread.php?t=1740798
[21:50] <sarnold> wmp_: oh, are these real cores?
[21:50] <wmp_> i dont know
[21:50] <wmp_> but maybe yes
[21:51] <wmp_> The number of cores	2
[21:51] <wmp_> yes
[21:51] <wmp_> ok, reboot
[21:55] <slangasek> pitti, cjwatson: hey, I could use some clarification around the GNOME SRU MRE.  The wiki page says "only the core modules and apps"; the TB discussion says "what is released with GNOME in the usual cadence"; either way it's not entirely obvious to me how to figure out if a particular piece of software (e.g., gnome-orca) is or is'nt
[21:57] <stgraber> slangasek: the DMB has a list somewhere, let me dig it out quickly
[21:58] <slangasek> stgraber: oh?  I wouldn't have assumed that the MRE set maps directly to a packageset?
[21:59] <stgraber> slangasek: nope, but we have a packageset that's defined as "take the list of gnome components and ignore those in the desktop packageset", so the same upstream list should qualify as "what is released with GNOME in the usual cadence"
[21:59] <slangasek> stgraber: hmm, ok
[22:00] <slangasek> stgraber: is that list published somewhere, that the MRE wiki page could link to directly?
[22:01] <wmp_> nothing
[22:01] <wmp_> and with noacpid i havent wifi
[22:01] <wmp_> and in dmesg i have: [    0.274307] Brought up 1 CPUs
[22:03] <stgraber> slangasek: we look at http://git.gnome.org/browse/jhbuild/tree/modulesets and look at gnome-apps, gnome-suites-core and gnome-suites-core-deps for the current gnome release in the archive. Those files need a bit of parsing to get the actual components.
[22:04] <stgraber> I vaguely remember someone wanting to write a reasonable parser for that stuff, doesn't look like it happened though and those seem to have grown quite a bit since I last looked at them (was fairly readable back then...)
[22:08] <stgraber> yeah, definitely quite a mess at the moment, you actually have to look at the comments to find the right stuff, for example, for -apps you need to start looking at "<!-- Apps start here -->" as everything before that is just dependencies
[22:09] <cjwatson> bdmurray: possibly tweaking the value of APT::Cache-Start randomly might help ...
[22:10] <cjwatson> (defaults to 24MiB IIRC; note that the man page lies)
=== salem_ is now known as _salem
[22:23] <wmp_> ok, work good after turn off and turn on
[22:23] <wmp_> after reboot i have only one thread
=== lifeless_ is now known as lifeless