[00:45] <Cytotoxic> !ops
[00:45] <Cytotoxic> ops
[00:45] <Cytotoxic> !troll
[00:45] <Cytotoxic> !staff
[00:46] <jpds> Hmm.
[00:46] <Cytotoxic> !ops
[00:46] <lifeless> Cytotoxic: please, not again. Its really disruptive you doing this.
[00:46] <Cytotoxic> why dosent it work?
[00:50] <tsimpson> Cytotoxic: ubottu will ignore any request by you until we can trust you not to abuse it
[00:51] <Cytotoxic> awww did the baby ubuntu developers filter me from it?
[00:51] <tsimpson> no, I did
[00:51] <Cytotoxic> good for you
[00:51] <tsimpson> I don't want you to abuse the bot, so I made it so you could not
[00:51] <Cytotoxic> since i am a lymphocyte i can adapt to this
[00:52] <tsimpson> good luck with that
[00:52] <Cytotoxic> i will develop antibodys to this filter
[00:52] <Cytotoxic> goodbye baby
[00:52] <LjL> also known as "alternative ips", i suppose
[00:52] <lifeless> or a new registered username
[00:53] <Meow234> !OPS
[00:53] <Meow234> told you i would adapt
[00:53] <Meow234> !ops i told you i would adapt
[00:54] <lifeless> thanks
[00:54] <Meow234> magic of lymphocytes
[00:54] <lifeless> Meow234: its disruptive and wastes peoples time. We would like you to stop.
[00:55] <lifeless> Keybuk: they go bye Cytotoxic too
[00:55] <lifeless> s/bye/be/
[00:55] <Keybuk> same person I think
[00:56] <lifeless> Keybuk: and like to do it in #ubuntu-kernel as well, if you're in a banning mood.
[00:56] <Keybuk> IP should cover him for a while
[00:56] <lifeless> Keybuk: yes, same person.
[00:56] <Keybuk> I'm not an op in #u-k afaik
[00:56] <lifeless> comes in every few days
[01:16] <mneptok> is there a full moon or something?
[01:17] <zul> i think there is
[01:17] <zul> or just more trolls
[01:18] <slangasek> $ pom
[01:18] <slangasek> The Moon is Full
[01:18] <slangasek> fyi
[01:19] <weremnep> aaaaaaOOOOOOOOOOO!
[01:53]  * Keybuk wishes that dh_makeshlibs supported debian/$package.shlibs
[01:57] <slangasek> hrm, didn't it previously?
[01:57] <slangasek> or maybe I just never found a reason to need that, because I never needed more than -V
[01:57] <Keybuk> right
[01:58] <Keybuk> but then you need to override -V every damn time
[01:58] <slangasek> anyway, .symbols
[01:58] <Keybuk> and with dh 7, that's annoying ;)
[01:58] <Keybuk> especially since you need to override -V individually for each library package produced
[01:59] <Keybuk> don't you have to do *both* .symbols and shlibs?
[01:59] <Keybuk> if not, why do packages still have shlibs in them at all?
[01:59] <slangasek> if you have .symbols, the contents of shlibs are completely irrelevant
[02:00] <slangasek> nothing current will look at the shlibs in that case, so it doesn't matter what they contain
[02:00] <Keybuk> so why have shlibs at all?
[02:01] <slangasek> in general?  because not all library packages have adopted symbols (nor are we likely to get 100% coverage)
[02:01] <Keybuk> right, I mean why do you get a shlibs in your package info if you have symbols?
[02:01] <Keybuk> shouldn't dh_makeshlibs/dpkg-gensymbols only include the symbols file in that case?
[02:02] <slangasek> because the dpkg transition is incomplete, and is still generating stuff that's only relevant for compatibility when installing on ancient systems
[02:03] <slangasek> ScottK: do you understand boost?  I'm unable to figure out why it's failing to find python 2.6 headers (after further patching it to not try to build for python2.5, given that 2.5 isn't pulled in by python-all-dev)
[02:04] <Keybuk> so you do have to care about shlibs ;)
[02:04] <ScottK> slangasek: I don't think anyone actually understands boost.
[02:04] <Keybuk> if you're giving the file in your package, it should be at least useful
[02:04] <Keybuk> second silly question
[02:04] <Keybuk> how do I unmark a bug as private? :p
[02:05] <ajmitch> slangasek: I've touched boost recently & haven't uploaded it
[02:05] <slangasek> Keybuk: nah, you don't have to care about them, it's a dpkg bug that they're being output :)
[02:05] <ScottK> There's an icon on the page, I think near the upper right, that gives you no earthly clue it's the right one, IIRC
[02:05] <ajmitch> I built it for lucid in my PPA after changing it to use only python 2.6
[02:05] <slangasek> if you have .symbols, there's no reasonable way anyone is going to need the .shlibs
[02:05] <ScottK> slangasek: I've patched it for new Python versions before, but if ajmitch already got it working, I'd say use his.  If not, I'll have a look.
[02:05] <slangasek> ajmitch: url?
[02:06] <ajmitch> slangasek: there's an additional patch needed for python 2.6 compatibility, I've just been slack with getting it into lucid
[02:06] <slangasek> ajmitch: ok; howzabout I let you take care of that part, and then I don't have to be TIL anymore? ;)
[02:06] <ajmitch> slangasek: sure
[02:07] <slangasek> (it's making a mess of components-mismatches again, trying to pull in the mpi stack)
[02:07] <ajmitch> https://edge.launchpad.net/~ajmitch/+archive/ppa/+files/boost1.40_1.40.0-2ubuntu3.dsc was what I had, I'll update it for the latest merge
[02:08] <slangasek> ajmitch: cheers!  please pull in the changes from my own 1.40.0-2ubuntu3 in the archive, to drop the mpi bits
[02:08] <ajmitch> will do
[02:08] <slangasek> (uploaded in full knowledge that it would FTBFS due to python, alas)
[02:13] <ScottK> slangasek: Are you moving 1.40 into Main?
[02:13] <slangasek> ScottK: it's already there by virtue of boost-defaults
[02:13] <ScottK> Ah. Cool.
[02:14] <ajmitch> boost 1.38 going to universe, or being dropped altogether?
[02:14] <slangasek> the latter is preferred, I'm sure
[02:14] <ajmitch> there's only a couple of packages that don't work with 1.40
[02:14] <ScottK> Definitely Universe.  Dropping all together is a goal.
[02:15] <ajmitch> one of them (python-visual) I haven't seen a fix for yet, but I might try & find out on the upstream mailing list about it
[02:15] <ScottK> ajmitch: Then they may have to die in the end.
[02:15] <ScottK> That'd be cool.
[02:16]  * ajmitch knows some people who rely on it for their thesis :)
[02:17] <ScottK> Motivated assistants ....
[02:17] <slangasek> perhaps they'll finish their thesis before security support for jaunty ends ;P
[02:17] <slangasek> s/jaunty/karmic/, I guess
[02:18] <ajmitch> yeah, karmic is in need of a SRU for boost 1.38 to handle it, which will need to be looked at soon
[02:18] <ajmitch> boost stuff is just so much fun though
[02:59] <ajmitch> james_w: how often do branch imports from debian happen?
[03:49] <ebroder> bryce: Is it worth my time to try and pull an SRU together for bug #311076? We apparently triggered it here on Jaunty today
[03:53] <james_w> ajmitch: 4 times a day
[03:57] <ajmitch> james_w: ok, I'll file bugs about the out-of-date branches then :)
[03:58] <ajmitch> boost1.40 1.40-4 hit squeeze 3-4 days ago & the branch hasn't appeared to update
[04:40] <vorian> hello all, I was wondering if you all would be willing and able to give a testimonial on my wiki page for my run for the IRC council
[04:40] <vorian> https://wiki.ubuntu.com/StephenStalcup
[05:01] <lifeless> !ops | MBCR (on #ubuntu-motu) - not feeding the troll directly
[05:02] <RAOF> And #ubuntu-kernel, while you're at it.
[05:11] <lifeless> vorian: are you freenode staff or just ops on motu?
[05:11] <vorian> lifeless: i'm staff
[05:11] <lifeless> vorian: he's pesting in #launchpad too
[05:11] <lifeless> and #ubuntu-kernel
[05:12] <lifeless> If you could just kline, that would be great.
[05:12] <vorian> and he's now gone
[05:12] <lifeless> thank you very much
[05:12] <vorian> no problemo
[05:51] <PhrkOnLsh> hello everyone. I'm a Fedora developer, and a few of us have recently started on a project to create a sort of "Welcome to Fedora" application that would launch when the user first logs in and gives a tour of desktop and list features, how to get help, etc. Along the lines of Windows' Welcome to Windows application. Does any buntu have such a similar application?
[06:02]  * PhrkOnLsh idles, good night
[06:05] <james_w> maxb: so apparently gina uses UTC_NOW as the date_created of the records it creates, so that's not the reason we are dropping these Debian uploads
[06:06] <lifeless> PhrkOnLsh: I'm not aware of one ;)
[06:09] <mneptok> PhrkOnLsh: as of Karmic the installer does the "show some helpful messages during the install process" thingy, but IIRC Anaconda already does that.
[06:13] <PhrkOnLsh> You guys use anaconda?
[06:13] <mneptok> no, but Fedora does ;)
[06:14] <ajmitch> mneptok: wasn't this about first login, rather than install?
[06:14] <PhrkOnLsh> aha.
[06:14] <mneptok> ajmitch: yeah. just saying the closest thing *buntu has is already part of existing Anaconda functionality.
[06:14] <PhrkOnLsh> For an idea of what I'm looking for our (messy, thinkbucket) wiki page http://fedoraproject.org/wiki/Fedora-tour
[06:15] <PhrkOnLsh> but thanks everyone :)
[06:15] <ajmitch> there was the 'about ubuntu' app which I'm not sure what it includes
[06:15] <PhrkOnLsh> Was looking for some ideas on it, but looks like we're on our own ;)
[06:15] <ajmitch> or that the few people online at the moment are just clueless :)
[06:16] <PhrkOnLsh> I'll try again later, then :) going to sleep
[06:16] <mneptok> PhrkOnLsh: personally, i'd ditch "Fedora Tour" and go with something like "GNOME Tour" and "KDE Tour." then you get far more eyes and interest, and the solution can be implemented in multiple distros.
[06:16] <mneptok> bah.
[06:16] <ajmitch> he fled!
[06:17]  * mneptok 's reputation (obviously) precedes him
[06:18] <jdong> where is the check bulletproof X uses to determine whether or not to go into panic mode?
[06:18] <ajmitch> jdong: gdm, perhaps?
[06:18] <jdong> on my VMWare Karmic workstation after applying the bulletproof X related updates,  it always drops into bulletproof X recovery mode when starting kdm
[06:19] <jdong> *kdm* :)
[06:19] <ajmitch> it might live there too :P
[06:19] <jdong> claiming the reason it failed is because "cannot find /dev/fb0"
[06:19] <jdong> I can find that line in my old working Xorg.log.*'s
[06:19] <jdong> but it's clearly not fatal
[06:21] <jdong> *starts rm'ing files*
[06:21] <ajmitch> oh dear
[06:22] <jdong> err after the 4.3.4 kdm ppa updates it works again
[06:22] <jdong> heh the PPA must not incorporate whatever patches enable bulletproof X :)
[06:22] <ajmitch> so yeah, i'm thinking that the bulletproof X stuff does live in *dm
[06:22] <ajmitch> I recall gdm updates around karmic release because of it
[06:22] <jdong> indeed even a regular startx shows (EE) cannot open /dev/fb0....
[06:23] <jdong> but it goes right on to start X perfectly fine
[06:23] <ajmitch> even with an EE?
[06:23] <jdong> but bulletproof X seems to be interpreting that as X failed.
[06:23] <jdong> indeed.
[06:23] <jdong> surprising, isn't it?
[06:23] <ajmitch> well it is meant to be a fatal error, from what little I know of X
[06:24] <jdong> http://paste.ubuntu.com/332887/
[06:24] <jdong> brief snippet
[06:24] <jdong> as you can see, indeed there's an EE on that module but X continues on
[06:24] <ajmitch> I'm guessing the various fb drivers don't work in vmware?
[06:26] <jdong> *nods
[07:11] <pitti> Good morning
[07:17] <jussi01> Mornign pitti!
[07:18] <jussi01> pitti: did you manage to get that jockey bug sorted?
[07:18] <micahg>  is an SRU allowed to switch the order on depends for a dummy package?
[07:19] <pitti> hi jussi01; "that" jockey bug?
[07:19] <pitti> micahg: depends; what effect does it have?
[07:19] <jussi01> pitti: the one I showed you at UDS
[07:19] <micahg> pitti: it's for libsdl1.2debian
[07:19] <micahg> pulseaudio seems to work where alsa doesn
[07:19] <micahg> 't
[07:20] <pitti> jussi01: no, I didn't get to work on jockey so far
[07:26] <bryce_> heya pitti
[07:49] <dholbach> good morning
[08:02] <dholbach> hey mvo
[08:03] <dholbach> doko, mvo: how does https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/223281 look to you?
[08:04] <mvo> hey dholbach!
[08:04] <ajmitch> morning mvo
[08:04] <mvo> hey ajmitch
[08:05] <dholbach> jmarsden: the patch has landed upstream already? in which release will it be included there?
[08:06] <jmarsden> It is in their bugtracker for 3.0, I don't think it landed yet.  The patch creator suggested I might open a bug upstream against 2.6 and see if upstream will incorporate it that way.
[08:07] <jmarsden> dholbach: http://bugs.python.org/issue6895 is the original bug I got the patch from.
[08:07] <dholbach> jmarsden: the result is that all python scripts explode for certain locales?
[08:08] <jmarsden> dholbach: All that are locale sensitive (anything using Lib/locale.py )
[08:09] <dholbach> can you put the link to the upstream bug in the ubuntu bug too?
[08:10] <dholbach> jmarsden: ^
[08:10] <jmarsden> dholbach: It's there in comment #6 already
[08:11] <dholbach> ahhh ok, missed it
[08:11] <jmarsden> all I did was grab the patch, test it fixes the bug, and package it up, basically.
[08:11] <dholbach> right
[09:34] <dholbach> pitti: for some reason I can't get "community-lucid-" blueprints/workitems to be seen by the launchpad-work-items-tracker
[09:34] <dholbach> pitti: I guess we're doing something differently compared to the desktop team, but I dunno what it is :)
[09:34] <pitti> dholbach: oh, want me to set up tracking for community-lucid-* on my server?
[09:35] <pitti> dholbach: do you have an URL for an example BP?
[09:35] <pitti> dholbach: https://blueprints.edge.launchpad.net/ubuntu/lucid/+specs?searchtext=community -> has four
[09:35] <dholbach> pitti: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-adopt-an-upstream
[09:36] <pitti> right, that's there
[09:36] <pitti> dholbach: let me set it up
[09:36] <dholbach> thanks pitti
[09:37] <dholbach> I'm just setting the series goal for a few where we didn't do it yet
[09:37] <pitti> MAILTO=daniel.holbach@canonical.com,jono@ubuntu.com ?
[09:38] <dholbach> mail for what exactly? :)
[09:38] <pitti> "spec has no work items", "invalid work item state", etc.
[09:38] <pitti> cron spam
[09:39] <dholbach> just set it to my mail :)
[09:39] <pitti> it's set up now, but complains about having no WIs
[09:39] <pitti> hmm
[09:40] <pitti> dholbach: did you just target those to lucid like 5 minutes ago?
[09:40] <dholbach> some, yes
[09:40] <maco> haha missed the last cron run?
[09:40] <pitti> no, production always lags behind changes on edge
[09:41] <pitti> ah, works now
[09:41] <pitti> WARNING: community-lucid-application-indicators-outreach has no work items
[09:41] <pitti> dholbach: ^ that's the kind of spam you get
[09:41] <pitti> (four of those ATM)
[09:41] <pitti> dholbach: http://piware.de/workitems/community/lucid/report.html
[09:41] <pitti> the next run should have some meat in it, when production catches up
[09:41] <ajmitch> pitti: your workitems stuff still screen-scrapes?
[09:42] <pitti> ajmitch: give me a launchpadlib API, and I'll stop :)
[09:42] <dholbach> thanks pitti
[09:42] <ajmitch> pitti: yeah, I was working on that the other day in fact, after seeing your scraping ;)
[09:42]  * pitti huds dholbach
[09:42]  * dholbach huds pitti back
[09:42] <pitti> ajmitch: oh, mdz was as well AFAIR
[09:42]  * pitti doesn't like being hudded
[09:43] <ajmitch> yeah, the bug was assigned to jml, he said he wasn't working on it at the moment
[09:45] <pitti> nice
[10:18] <soren> Any chance an archive admin could review libcloud some time today? It's been in NEW for over a week.
[10:38] <soren> cjwatson: You seem to be the "on duty AA" this morning. ^^ Pretty please?
[10:39] <cjwatson> mkay
[11:05] <cjwatson> soren: accepted. (sorry, had to fix our local lintian installation first)
[11:06] <geser> argh, someone an idea why the buildd didn't upgrade pkg-create-dbgsym? http://launchpadlibrarian.net/36328245/buildlog_ubuntu-lucid-i386.pion-net_2.2.2%2Bdfsg-2_FAILEDTOBUILD.txt.gz
[11:14] <soren> cjwatson: Lovely. It's already in binary NEW, if you're up for it..
[11:15]  * soren still gets excited about soyuz building stuff so quickly
[11:15] <soren> cjwatson: Oh, and thanks! I really appreciate it.
[11:18] <cjwatson> soren: done
[11:19]  * soren hugs cjwatson 
[11:19] <soren> cjwatson: Thank you!
[11:49] <ogra> The following packages have unmet dependencies:
[11:49] <ogra>   libglib2.0-data: Depends: libglib2.0-0 (>= 2.23.0-1ubuntu1) but 2.22.2-0ubuntu1 is installed
[11:49] <ogra> E: Unmet dependencies. Try using -f.
[11:49] <ogra> hrm, is someone taking care of that ?
[11:50] <ogra> (thats from an armel livefs build attempt)
[11:51] <pitti> just looks like a normal arch all/any buildd issue
[11:51] <ogra> hmm
[11:51] <asac> yes, i would wait a bit ;)
[11:51] <ogra> but glib was uploaded yesterday
[11:52] <asac> (if you are on 64bit)
[11:52] <ogra> i'm on armel
[11:52] <asac> even more so there ;)
[11:52] <ogra> and i have no chance to get to reproduce the mksquashfs failure without getting through the package installation
[11:52] <asac> ogra: failed to biuld on armel ;)
[11:52] <ogra> which effectively means we wont be able to fix it
[11:52] <asac> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.23.0-1ubuntu1/+build/1374402
[11:53]  * ogra checks
[11:53] <asac> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/build/buildd/glib2.0-2.23.0/glib -I.. -I/build/buildd/glib2.0-2.23.0 -DG_LOG_DOMAIN=\"GLib\" -DG_ENABLE_DEBUG -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -DG_DISABLE_SINGLE_INCLUDES -pthread -g -O2 -Wall -g -O2 -MT gatomic.lo -MD -MP -MF .deps/gatomic.Tpo -c /build/buildd/glib2.0-2.23.0/glib/gatomic.c  -fPIC -DPIC -o .libs/gatomic.o
[11:53] <asac> /tmp/cc7twNnB.s: Assembler messages:
[11:53] <asac> /tmp/cc7twNnB.s:161: Error: selected processor does not support `swp r3,r5,[r4]'
[11:53] <asac> /tmp/cc7twNnB.s:179: Error: selected processor does not support `swp r3,r5,[r4]'
[11:53] <geser> pitti: do you know if it's safe to let pkg-create-dbgsym upgrade again on the buildds? it's on hold because of a problem with 0.32
[11:53] <pitti> geser: still? I thought lamont removed that again
[11:53] <pitti> yes, should be safe
[11:54] <ogra> -Wa,-mimplicit-it=thumb is missing in the rules :/
[11:54] <asac> ogra: or toolchain ;)
[11:54] <asac> doko_: there?
[11:54] <ogra> we wont get it in the toolchain before alphga
[11:54] <ogra> seb128, ^^^
[11:54] <ogra> seb128, could you add a contidional -Wa,-mimplicit-it=thumb CFLAG for armel to the package ?
[11:55] <pitti> ogra: right, FTBFS on armel
[11:55] <ogra> *conditional
[11:55] <pitti> ogra: is that package specific?
[11:55] <ogra> pitti, no
[11:55] <lamont> pitti: we're going to test it to be extra sure, then unhold it
[11:55] <pitti> then it doesn't belong into glib for sure, but in the default gcc flags?
[11:55] <seb128> ogra, hum...
[11:55] <ogra> its a temporary workaround so we have a chance to make alpha
[11:55] <ogra> pitti, right
[11:55] <seb128> ogra, what pitti said
[11:55] <ogra> pitti, gcc builds to long
[11:56] <ogra> no way for us to make alpha then
[11:56] <ogra> there is a bug open for the toolchain
[11:56] <pitti> ogra: it's faster to reupload a zillion packages than gcc?
[11:56] <ogra> but it wont be fixed pre alpha
[11:56] <ogra> i wouldnt say glib is a zillion packages
[11:57] <pitti> ogra: but you said it affects all packages?
[11:57] <ogra> it only packages that actually have assembler bits in their code
[11:57] <asac> it should go into rules
[11:57]  * pitti doesn't know about those build flags, sorry
[11:57] <ogra> right
[11:57] <pitti> ah
[11:57] <ogra> its just a CFLAG in rules
[11:57] <asac> and maybe a bug filed upstream
[11:57] <asac> to make assembly thumb2 compliant
[11:57] <ogra> not really, once the toolchain is right it can go again
[11:57] <ogra> hmm, or that, yeah :)
[11:58] <asac> i will check with dmart
[11:58] <pitti> well, then go ahead :)
[11:58] <asac> but for now we definitly should put it in glib rules
[11:58] <seb128> I'm trying to get glib in sync with debian
[11:58] <asac> seb128: ^^ can you upload that?
[11:58] <asac> also see: https://wiki.ubuntu.com/ARM/Thumb2
[11:58] <seb128> can you get those changes in debian?
[11:58] <ogra> yeah
[11:58] <asac> seb128: its really temporary
[11:58] <ogra> asac, we should mail that URL to ubuntu-devel probably
[11:58] <seb128> asac, yes but please upstream or send to debian
[11:59] <ogra> to make sure maintainers make sure their packages are correct
[11:59] <asac> seb128: we dont have a patch to upstream yet. i take the action to drive that though
[11:59] <pitti> ifneq ($(findstring $(DEB_BUILD_ARCH), sparc alpha),)
[11:59] <pitti> sorry
[11:59] <pitti> ifneq ($(findstring $(DEB_BUILD_ARCH), armel),
[11:59] <seb128> asac, ok, I trust you on that, do whatever you need to get running there
[11:59] <pitti> CFLAGS += ...
[11:59] <ogra> yeah, there
[11:59] <pitti> endif
[11:59] <pitti> ?
[11:59] <ogra> right
[11:59] <ogra> -Wa,-mimplicit-it=thumb
[12:00] <ogra> thats what you want to add
[12:00] <ogra> or -marm ... but that disables thumb2 completely
[12:00] <seb128> when is the first alpha due btw?
[12:00] <ogra> tomorrow
[12:00] <pitti> uh, there wasn't even an announcement
[12:01] <pitti> no, it's next week
[12:01] <cjwatson> next week, according to the release schedule, not tomorrow
[12:01] <ogra> ah
[12:01] <pitti> December 10th
[12:01] <seb128> pfious
[12:01] <ogra> yeah, i got my schedule wrong
[12:01] <asac> ogra: ... good to know that you feel overly pressured ;)
[12:01] <pitti> should that be 'nuff time for a proper gcc fix?
[12:01] <ogra> asac, i always do :)
[12:01] <ogra> pitti, doko could tell :)
[12:01] <seb128> I didn't see the announcement either and did some disruptive changes (ie new glib and new gtk)
[12:02] <seb128> but that's all good apparently ;-)
[12:02] <asac> not sure if doko is on vac though
[12:02] <asac> let me check
[12:02] <ogra> seb128, well, its A1 anyway .... i.e. all good as long as it boots somehow
[12:02] <asac> seems not
[12:02] <seb128> ogra, well I was rather concerned about you complaining about installability
[12:02] <asac> doko_: when do you plan to update the implicit-it default? (or do you plan to not do that at all)?
[12:03] <seb128> ogra, because armel is slow to catch up on gtk builds
[12:03] <ogra> seb128, yeah, sorry ... i was reading my schedule wrong
[12:03] <seb128> don't worry, it's all good ;-)
[12:03] <asac> ogra: ok. so ok to wait for doko to answer ;)?
[12:03] <ogra> we should mark https://bugs.launchpad.net/bugs/488302 critical or some such
[12:04] <asac> ogra: well. it basically hides things
[12:04] <asac> also i am not really sure implicit-it will help for the "swp" thing here
[12:04] <ogra> hmm
[12:04] <ogra> but i thought we will enable it anyway by default
[12:05] <ogra> if you actually want to fix all assembler in all packages i doubt we can make lucid *g*
[12:05] <asac> if it doesnt hide real thumb2 issues then its probably ok
[12:05] <asac> to enable by default. what would be bad if we hide it and dont get properly optimized code
[12:05] <ogra> indeed
[12:05] <asac> but i can chcek that with dmart. let me open a bug for the glib build failure like the wiki page says
[12:05] <asac> so he can take a look
[12:06] <ogra> i think he was the one that suggested to change the defaults
[12:06] <ogra> actually he filed that bug :)
[12:06] <asac> yes. i think its good for default as it does not disable/convert instructions. which is why i think it wouldnt really help here
[12:07] <ogra> "will allow most traditional ARM syntax inline assembler in C/C++ source to be assmbled in Thumb-2, and will not impact other code"
[12:07] <ogra> i think thats the key sentence here
[12:07] <ogra> so it doesnt actually "hide" stuff ... its just another way of applying the optimization as i understand
[12:09] <asac> bug 491342
[12:09] <asac> ogra: right.
[12:12] <cjwatson> mvo: I don't know if you remember, but in your auto-update branch of ubiquity from years back (now merged), you removed the local fork of updateInterface on the grounds that you'd merged its changes into python-apt proper
[12:13] <cjwatson> mvo: unfortunately it turns out you missed a bit :) could we get a fix into python-apt today, rather than reintroducing the fork to ubiquity? I think that would be preferable really
[12:13] <cjwatson> mvo: it's a fix to handle non-blocking fds properly - I'll get you a patch as soon as I've tested it
[12:13] <mvo> cjwatson: certainly, thanks for the patch!
[12:16] <cjwatson> mvo: I think it's http://paste.ubuntu.com/333072/ - want me to just commit it directly to the core-dev branch, or something else?
[12:17] <mvo> cjwatson: commiting is fine, but I can also merge it if that is the final patch. i will also apply it to the debian branch
[12:19] <cjwatson> waiting for the test to complete ...
[13:16]  * soren boggles
[13:17] <soren> I had a bunch of rendering artifacts after having suspended/resumed my laptop.  They had been there for hours (possibly days, I forget when I last rebooted).
[13:17] <soren> I'm in the middle of a dist-upgrade in the background, and suddenly all the artifacts disappear, and everything looks perfect again.
[13:19] <soren> I glance over at the dist-upgrade, and it seems to have fixed itself while it was /unpacking/ xorg.
[13:19] <soren> Very, very odd, if you ask me.
[13:20] <soren> Well, xorg, xserver-xorg, or xserver-xorg-video-all.
[13:20] <soren> Very, very odd.
[13:22] <hakaishi> Hi folks, I'd like to debianize a qt-project. The problem I have is, that I don't know how to customize the .pro-file. I'd like to copy the binary into /usr/share/... . I tried DESTDIR but this throws an error (permission denied) while making the .deb. Hence I tried BIN.path += [...] and BIN.file += [...], but as the file isn't compiled yet, it won't do. What shall I do?
[13:24] <seb128> slangasek, hey, any reason you didn't upload your gnome-screensaver merge?
[13:25] <seb128> slangasek, (just curious on whether that was wanted or if you forgot to dput it)
[14:01] <seb128> jdstrand, hey, I'm not sure I agree with the closing of this evince fileselector issue as wontfix...
[14:02] <seb128> jdstrand, being able to store documents on shared vfat disks is a valid user scenario
[14:02] <jdstrand> seb128: I agree-- but the user mounted it in a non-FHS directory. we allow access to /mnt and /media
[14:03] <seb128> oh ok, fair enough then ;-)
[14:04] <jdstrand> seb128: hmm, actually-- I thought it did. seems I mixed up the profile with the firefox one
[14:04] <jdstrand> seb128: I'll fix that
[14:04] <seb128> jdstrand, thanks
[14:04] <jdstrand> seb128: non-FHS-- won't fix, FHS, fix
[14:04] <jdstrand> seb128: thanks for the followup
[14:05] <seb128> right, having mnt and media should be enough
[14:05] <seb128> thank you for looking at those issues ;-)
[14:05] <jdstrand> seb128: oh np! :)
[14:20] <doko_> asac, seb128: this is code which should be fixed upstream, it won't work on multi cores. the atomic helpers should be used
[14:35] <asac> doko_: right. my question was more about an ETA for the implicit-it flag in general
[14:37] <doko_> asac: should be with the next upload
[14:37] <asac> when is that ;)
[14:37] <asac> ?
[14:37] <doko_> when the eglibc build is fixed
[14:38] <asac> ok
[14:38] <asac> guess i wont get an estimate from you ;)
[14:38] <doko_> no not a specific one :-/
[14:38] <asac> about a week, two, a month etc.
[15:02] <robbiew> cjwatson: I can't make the weekly meeting today due to conflicts...can you cover it? or should we cancel?
[15:02] <cjwatson> I can cover it, can you let me know anything I should cover other than the spec approval deadline?
[15:08] <cjwatson> mathiaz: you're currently listed as drafter on foundations-lucid-puppet-installer. Is that correct? Are you going to have a draft ready for the spec approval deadline tomorrow?
[15:09] <mathiaz> cjwatson: hmmmm -?
[15:09]  * mathiaz checks
[15:11] <mathiaz> cjwatson: I'll draft something up today
[15:12] <cjwatson> thanks!
[15:14] <cjwatson> mvo: patch committed, I'll go ahead and upload now
[15:14] <cjwatson> er, actually, I say that ...
[15:14] <cjwatson> *actually* committed now
[15:16] <mvo> thanks!
[15:25] <ion> keybuk: Ok, posted bug #491389 and a merge request.
[17:08] <smoser> wiki is dead?
[17:08] <smoser> nope
[17:19] <lamont> ogra: setarch vs arm - if you want to give me details on what the different personalities should be, and all that, I can see about pushing that upstream... OTOH, that may involve tweaking the kernel, maybe?
[17:20] <ogra> lamont, i think lool had some patch in mind already
[17:21] <lamont> woot!
[17:21] <lamont> I'm happy to push it after signing off
[17:33] <lool> lamont: I only checked out the source code quickly
[17:34] <lool> lamont: What I had in mind as the best option for the situation at hand was to add a --force flag to allow (trying) to set any uname
[17:34] <kirkland> Keybuk: syntax highlighting for vim would be really nice :-) :-)
[17:34] <kirkland> Keybuk: for upstart scripts
[17:35] <lool> lamont: Otherwise, we could allow armv7 -> armv6 -> armv5 kind of transitions only, and change the default in qemu
[17:35] <slangasek> bryce_: is it known/expected in lucid that input devices connected after X has started aren't detected? :)
[17:35] <lamont> lool: well.... we should at the very least make setarch believe in the various kernel-supported personalities provided on armel
[17:36] <lamont> that much of a patch is simple to push upstream
[17:36] <slangasek> bryce_: n/m, apparently it works if hal is running :-P
[17:36] <lool> lamont: Oh absolutely
[17:37] <lamont> slangasek: I have another machine where, after the upgrade to karmic, no console kit love.  it's quite possible that the issue also existed on jaunty, since my daughter's long complaint has been that thumbdrives don't work on her computer....
[17:37] <lamont> but I can't for the life of me remember how I tracked down and fixed it last time
[17:37] <slangasek> lamont: hum?  is that in response to my comment about input devices?
[17:38] <lamont> lool: I'm not sure that forcing arbitrary uname returns is something I believe to be a good thing
[17:38] <lamont> slangasek: well, your comment got me thinking
[17:38] <lamont> and you know all, so I figured you were a good target. :-p
[17:39] <lool> lamont: So {PER_LINUX32, "armv7l", NULL}, and the like, one per arch should do it; I dont have a definitive list though, perhaps the kernel does
[17:39] <slangasek> lamont: consolekit WFM and millions of others out of the box, I haven't had any reason to know anything about it :)
[17:39] <lamont> lool: OTOH, adding more personalities to the kernel, and teaching qemu about them?  sounds like a win
[17:39] <lamont> slangasek: well, ISTR the last time I fixed it by reinstalling the machine.
[17:39] <lool> lamont: Not sure what you mean on the kernel side?
[17:40] <lamont> as in cruft from edgy-days?  something  in there hates on the console kit
[17:40] <lool> lamont: Are you using startx?
[17:40] <lamont> lool: if there are more personalities we want from the kernel, I mean
[17:40] <lamont> lool: gdm
[17:40] <slangasek> lamont: right, I'm entirely free of edgy cruft too :)
[17:41] <lamont> mind you, this is also the box that has been faceplanting about once every 20-30 hours since I upgraded it to karmic... not sure if that's related
[17:41] <lool> lamont: Actually you just made me realize that patching setarch was completely useless here
[17:41] <lool> lamont: setarch asks the kernel to set the personality; but qemu intercepts uname calls to always return the emulated uname
[17:41] <lamont> lool: PROGRESS! :(
[17:42] <lamont> lool: ergo, qemu uname interception needs more smarts
[17:42] <lool> So even if we make setarch allow fixing up armv5 to v7l or vice-versa, it wont help qemu-arm
[17:42] <lool> lamont: Agreed
[17:42] <lamont> but we should fix setarch, too.
[17:42] <lamont> if only "because we can"
[17:42] <lool> Tss I hate you, not only you make me realize that my own idea was wrong, but you manage to double the work in fixing this stuff!   ;-)
[17:43] <lamont> OTOH, if qemu thinks it's running v5, it should at least log that it executed a v7 instr - the fact that the qemu-v5 implementation of that unsupported instruction happens to have the same results as the actual v7 instr? that's OK.  not logging it and having someone run that code on a v5 box?  kinda rudxe
[17:44] <lamont> s/xe$/e/
[17:46] <lool> lamont: TBH I feel Qemu should actually emulate only the instruction set it's told to emulate and return that; it can SIGILL when emulating a full system, it should just do the same when running in syscall emulation mode
[17:51] <lamont> oh agreed most certainly
[17:54] <ogra> lool, well, that still leaves the question how we set the default for qemu-arm
[17:55] <ogra> if we hardcode v7 people wont be able to run anything but lucid binaries
[17:56] <lool> As I said, qemu should allow setting what's it's emulating
[17:56] <ogra> if we dont, wheer does it know from what to use ?
[17:56] <lool> You can run v5 binaries on armv7 hosts
[17:56] <ogra> oh, right
[17:56]  * ogra slaps forehead ... i was thinking in the wrong direction
[18:01] <lool> lamont: bah now that I've checked the kernel code, I see how it would need implementation of personalities for all this stuff
[18:02] <lool> I thought it was taking the string as input, but it's PER_LINUX or PER_LINUX32 so no support for armv*
[18:03] <lamont> heh. ok
[18:04] <lool> probably nobody cares supporting older arms as personalities
[18:04] <lamont> well then.. just fix qemu to say 'armel7v' :-p
[18:05] <lool> armv7l ?
[18:07] <lamont> lool: whatevah
[19:12] <kklimonda> Keybuk: ping?
[19:13] <cody-somerville> pitti, Curious. Why is the launchpad registry team a member of ubuntu-sru?
[19:16] <slangasek> kklimonda: I understand that he's out sick today
[19:16] <kklimonda> slangasek: thanks
[19:20] <micahg> nixternal: I think that LP can merge teams, it's just not available to normal users
[19:35] <kirkland> Keybuk: slangasek: hiya ... couple of upstart questions for you guys
[19:37] <kirkland> Keybuk: slangasek: we're trying to support a couple of functions that the deprecated eucalyptus initscripts used to support ... namely "cleanrestart", "cleanstart", "cleanstop"
[19:37] <kirkland> Keybuk: slangasek: these simply need to rm -f some /var/lib/eucalyptus/[stuff]
[19:38] <kirkland> Keybuk: slangasek: i think when we discussed this previously, we were told to pass a variable to the upstart script
[19:38] <kirkland> Keybuk: slangasek: something like "sudo restart eucalyptus CLEAN=1"
[19:40] <kirkland> Keybuk: slangasek: did we understand that advice correctly?
[19:46] <slangasek> ScottK: who should be assigned to the work items listed on https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries ?
[19:47] <slangasek> kirkland: (takes a moment to get over the horror at needing such an option) yes, that looks like a sensible way to do it
[19:48] <kirkland> slangasek: is the syntax correct, "sudo restart eucalyptus CLEAN=1" ?
[19:49] <kirkland> slangasek: ie, putting the CLEAN=1 as an argument?
[19:49] <kirkland> slangasek: or is it expected that CLEAN=1 be defined in the environment calling it?  <--- seems nasty
[19:49] <slangasek> kirkland: as an argument
[19:49] <kirkland> slangasek: hmm, okay; that's what i'm doing;  will need to troubleshoot some more
[19:50] <slangasek> kirkland: can I see the job?
[19:50] <kirkland> slangasek: sure ... there are multiple levels, though
[19:50] <kirkland> slangasek: i'll start you at the top
[19:51] <kirkland> slangasek: sudo restart eucalyptus CLEAN=1"
[19:51] <kirkland> slangasek: whoops ...
[19:51] <kirkland> slangasek: http://pastebin.com/f60592b90
[19:51] <kirkland> slangasek: lines 26 and 27 are my debug
[19:52] <kirkland> slangasek: annoyingly, they're not executing at all
[19:52] <kirkland> slangasek: on "sudo restart eucalyptus"
[19:53] <slangasek> kirkland: did you force a reload after editing the script?
[19:53] <slangasek> s/script/job/
[19:53] <kirkland> slangasek: umm ... i edited the script and just "sudo restart eucalyptus" ... is there more i need to do?
[19:54] <slangasek> yes, 'sudo initctl reload-configuration', I believe
[19:54] <kirkland> slangasek: hrm
[19:54] <soren> That's the thing with upstart..
[19:54] <slangasek> "restart" restarts the current job with the existing job config
[19:54] <soren> When you edit a job, it thinks it's a new job.
[19:54] <slangasek> i.e., the already loaded in-memory job config
[19:54] <soren> So restart will restart the one that's already running with the definition it had when it was started.
[19:55] <kirkland> slangasek: okay, now i've done your initctl, and restarted; same behavior, no /tmp/env
[19:55] <slangasek> kirkland: ok, then that just means I was mistaken :)  Do a stop && start, then try the restart
[19:56] <kirkland> slangasek: aha
[19:56]  * kirkland notes something non-intuitive about this particular quirk of upstart
[19:56] <slangasek> kirkland: is that doing the trick, or is $CLEAN missing from the env?
[19:57] <kirkland> slangasek: now my changes to the upstart script are registered and executing
[19:57] <kirkland> slangasek: let me go hack on it some more, now that I know how to test my fudging
[19:57] <slangasek> kirkland: does the test show that $CLEAN is getting set?
[19:58] <kirkland> slangasek: yessir!
[19:58] <slangasek> ok, cool
[19:58] <zul> cjwatson: mind if I merge openssh?
[20:01] <ScottK> slangasek: It'll be wgrant and myself working on it in the near term.
[20:09] <cjwatson> zul: I'd rather I did it if you don't mind
[20:09] <zul> cjwatson:no problem
[20:10] <cjwatson> (must get the Debian history converted to bzr)
[20:23] <soren> jdstrand: Is this perhaps a karmic chroot that was upgraded to Lucid?
[20:24] <jdstrand> soren: possibly, but I don't think so...
[20:24] <soren> I'm just puzzled how one would have a lucid chroot without libnih-dbus1 in it.
[20:25] <cjwatson> zul: uploaded
[20:25] <zul> cjwatson: thanks
[20:25] <soren> ..unless it's an upgrade from a version of Ubuntu where libnih-dbus1 was not Priority: required.
[20:26] <jdstrand> I can recreate it-- I remember I created it shortly after lucid opened
[20:26] <jdstrand> maybe that required business wasn't there when I created it
[20:26] <soren> Perhaps.
[20:26]  * jdstrand goes to recreate it
[20:26] <soren> libnih didn't come into existence as a separate souce package until a week ago, at least.
[20:27] <cjwatson> Priority: required isn't enough to cause anything except debootstrap to autoinstall it, of course
[20:27] <jdstrand> oh, well, I created the schroot much earlier than that
[20:28] <cjwatson> now, mountall pre-depending on it *is* enough
[20:28] <jdstrand> soren: well, the libnih-dbus thing might be a red herring... I just mentioned it cause that was a difference in the builds
[20:28] <soren> jdstrand: Gotcha.
[20:29] <jdstrand> soren: also, I just remembered, my debmirror script has been dying lately, so the lucid chroot is certainly out of date
[20:29] <jdstrand> (I fixed that today)
[20:30] <blackxored> how can I unregister a branch from launchpad? I have two packaging branches on bzr which I don't longer maintain since I switched to git
[20:30]  * jdstrand waits to rebuild his chroot
[20:30] <cjwatson> blackxored: there should be a delete button in the UI for the branch, looking like a trashcan icon
[20:31] <cjwatson> ScottK,ogra: FYI -Wa,-mimplicit-it=thumb makes no difference to the qt4-x11 failure.
[20:31] <cjwatson> the error is on a QT_MMAP call ...
[20:32] <blackxored> cjwatson, inside the brash on the sidebar, yes, thanks
[20:32] <blackxored> does launchpad provide any kind of git integration?
[20:32] <cjwatson> no. this is intentional, part of the point of bzr is to be able to interoperate well with other systems
[20:33] <cjwatson> you can ask Launchpad to *import* git branches into bzr
[20:33] <blackxored> cjwatson, how can I do that, and that automatically fetch my changes?
[20:34] <cjwatson> blackxored: https://help.launchpad.net/VcsImports
[20:35] <blackxored> cjwatson, thanks, it is ok to let launchpad import my branches for debian packages, right?
[20:35] <blackxored> or it is overkill?
[20:36] <cjwatson> you can ask it to import whatever you like
[20:36] <cjwatson> (BTW this is probably more appropriate in #launchpad ...)
[20:36] <blackxored> cjwatson, thanks
[20:37] <LaserJock> right now Launchpad only imports git master branches
[20:38] <cjwatson> yes, although that at least stands a reasonable chance of getting fixed soonish
[20:39] <LaserJock> sounds like it, would make it much more useful for packaging
[21:45]  * maxb reads the help of bzr merge-upstream
[21:45]  * maxb is confused
[21:45] <FishEatFish>  hello, i have probleme with dh_make, it can't create debian/ in my sources folder !! can anybody help me please ?
[21:45] <maxb> Sure - but not here, #ubuntu-motu
[22:02] <jcole> is there a way for gcc to compile a 32bit app on a 32bit kernel so it cat access more than 4gb? the server has 32gb of ram
[22:05] <FishEatFish> maxb : thank you i'll go there
[22:16] <kirkland> cjwatson: sorry to bug you again about the daily builds ....
[22:16] <kirkland> cjwatson: i'm wondering if it makes sense for cdimage to trash the previous completed ISO build, if the current ones are failing
[22:18] <kirkland> cjwatson: it would be nice if the "current" symlinks continued to point to the last good build, -> http://cdimage.ubuntu.com/ubuntu-server/daily/current/
[22:22] <superm1> kirkland, how would cdimage know it's a bad build?  it's not the one testing them
[22:24] <kirkland> superm1: hrm, i don't know the inner workings ... i'm just suggesting that whatever is reaping the old builds and updating the symlinks *not* do so if the incoming "current" is missing any *.iso
[22:26] <superm1> kirkland, oh by failed build you mean failed build, not failed build
[22:26] <kirkland> superm1: that's a confusing sentence
[22:26] <superm1> er i forgot emphasis there, you mean "failed to build", not the "build fails to install"
[22:26] <kirkland> superm1: right, of course
[22:26] <kirkland> superm1: notice that http://cdimage.ubuntu.com/ubuntu-server/daily/current/ is empty
[22:27] <kirkland> superm1: as is http://cdimage.ubuntu.com/ubuntu-server/daily/20091202/
[22:27] <kirkland> superm1: as well as http://cdimage.ubuntu.com/ubuntu-server/daily/20091201/
[22:27] <kirkland> superm1: fortunately, I happened to have had testdrive cache an ISO from 2009-11-27 for me :-)
[22:32] <slangasek> kirkland: hmm, I suspect the symlink was updated because the source ISO build succeeded
[22:32] <slangasek> so the build as a whole was a "success", I guess
[22:32] <kirkland> slangasek: that's, um, cute :-)
[22:33] <slangasek> seems sensible to ignore source ISOs for this, though I'm not sure offhand how deep the surgery will be
[22:43] <cjwatson> kirkland: it's not trivial, multiple different pieces involved. The reason I've never bothered to fix it is that if the dailies are failing for many days in a row then we ought to be fixing that anyway
[22:44] <kirkland> cjwatson: okay, thanks
[22:46] <fagan> maco: hehe I tried kubuntu because I had a problem with gnome and it refused to connect to my network
[23:08] <pitti> cody-somerville: hm, no idea I'm afraid