[00:45] !ops [00:45] ops [00:45] !troll [00:45] !staff [00:46] Hmm. [00:46] !ops [00:46] Cytotoxic: please, not again. Its really disruptive you doing this. [00:46] why dosent it work? === nxvl_ is now known as nxvl [00:50] Cytotoxic: ubottu will ignore any request by you until we can trust you not to abuse it [00:51] awww did the baby ubuntu developers filter me from it? [00:51] no, I did [00:51] good for you [00:51] I don't want you to abuse the bot, so I made it so you could not [00:51] since i am a lymphocyte i can adapt to this [00:52] good luck with that [00:52] i will develop antibodys to this filter [00:52] goodbye baby [00:52] also known as "alternative ips", i suppose === asac_ is now known as asac [00:52] or a new registered username [00:53] !OPS [00:53] Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! [00:53] told you i would adapt [00:53] !ops i told you i would adapt [00:53] Error: I am only a bot, please don't think I'm intelligent :) [00:54] thanks [00:54] magic of lymphocytes [00:54] Meow234: its disruptive and wastes peoples time. We would like you to stop. [00:55] Keybuk: they go bye Cytotoxic too [00:55] s/bye/be/ [00:55] same person I think [00:56] Keybuk: and like to do it in #ubuntu-kernel as well, if you're in a banning mood. [00:56] IP should cover him for a while [00:56] Keybuk: yes, same person. [00:56] I'm not an op in #u-k afaik [00:56] comes in every few days [01:16] is there a full moon or something? [01:17] i think there is [01:17] or just more trolls [01:18] $ pom [01:18] The Moon is Full [01:18] fyi === mneptok is now known as weremnep [01:19] aaaaaaOOOOOOOOOOO! === weremnep is now known as mneptok [01:53] * Keybuk wishes that dh_makeshlibs supported debian/$package.shlibs [01:57] hrm, didn't it previously? [01:57] or maybe I just never found a reason to need that, because I never needed more than -V [01:57] right [01:58] but then you need to override -V every damn time [01:58] anyway, .symbols [01:58] and with dh 7, that's annoying ;) [01:58] especially since you need to override -V individually for each library package produced [01:59] don't you have to do *both* .symbols and shlibs? [01:59] if not, why do packages still have shlibs in them at all? [01:59] if you have .symbols, the contents of shlibs are completely irrelevant [02:00] nothing current will look at the shlibs in that case, so it doesn't matter what they contain [02:00] so why have shlibs at all? [02:01] in general? because not all library packages have adopted symbols (nor are we likely to get 100% coverage) [02:01] right, I mean why do you get a shlibs in your package info if you have symbols? [02:01] shouldn't dh_makeshlibs/dpkg-gensymbols only include the symbols file in that case? [02:02] because the dpkg transition is incomplete, and is still generating stuff that's only relevant for compatibility when installing on ancient systems [02:03] 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] so you do have to care about shlibs ;) [02:04] slangasek: I don't think anyone actually understands boost. [02:04] if you're giving the file in your package, it should be at least useful [02:04] second silly question [02:04] how do I unmark a bug as private? :p [02:05] slangasek: I've touched boost recently & haven't uploaded it [02:05] Keybuk: nah, you don't have to care about them, it's a dpkg bug that they're being output :) [02:05] 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] I built it for lucid in my PPA after changing it to use only python 2.6 [02:05] if you have .symbols, there's no reasonable way anyone is going to need the .shlibs [02:05] 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] ajmitch: url? [02:06] slangasek: there's an additional patch needed for python 2.6 compatibility, I've just been slack with getting it into lucid [02:06] ajmitch: ok; howzabout I let you take care of that part, and then I don't have to be TIL anymore? ;) [02:06] slangasek: sure [02:07] (it's making a mess of components-mismatches again, trying to pull in the mpi stack) [02:07] 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] ajmitch: cheers! please pull in the changes from my own 1.40.0-2ubuntu3 in the archive, to drop the mpi bits [02:08] will do [02:08] (uploaded in full knowledge that it would FTBFS due to python, alas) [02:13] slangasek: Are you moving 1.40 into Main? [02:13] ScottK: it's already there by virtue of boost-defaults [02:13] Ah. Cool. [02:14] boost 1.38 going to universe, or being dropped altogether? [02:14] the latter is preferred, I'm sure [02:14] there's only a couple of packages that don't work with 1.40 [02:14] Definitely Universe. Dropping all together is a goal. [02:15] 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] ajmitch: Then they may have to die in the end. [02:15] That'd be cool. [02:16] * ajmitch knows some people who rely on it for their thesis :) [02:17] Motivated assistants .... [02:17] perhaps they'll finish their thesis before security support for jaunty ends ;P [02:17] s/jaunty/karmic/, I guess [02:18] 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] boost stuff is just so much fun though [02:59] james_w: how often do branch imports from debian happen? === micahg1 is now known as micahg [03:49] 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:49] Launchpad bug 311076 in xorg-server "hang on BOGUS LENGTH in write keyboard desc" [Undecided,Fix released] https://launchpad.net/bugs/311076 [03:53] ajmitch: 4 times a day [03:57] james_w: ok, I'll file bugs about the out-of-date branches then :) [03:58] boost1.40 1.40-4 hit squeeze 3-4 days ago & the branch hasn't appeared to update [04:40] 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] https://wiki.ubuntu.com/StephenStalcup [05:01] !ops | MBCR (on #ubuntu-motu) - not feeding the troll directly [05:01] MBCR (on #ubuntu-motu) - not feeding the troll directly: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! [05:02] And #ubuntu-kernel, while you're at it. [05:11] vorian: are you freenode staff or just ops on motu? [05:11] lifeless: i'm staff [05:11] vorian: he's pesting in #launchpad too [05:11] and #ubuntu-kernel [05:12] If you could just kline, that would be great. [05:12] and he's now gone [05:12] thank you very much [05:12] no problemo === richie is now known as Richie [05:51] 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] 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] PhrkOnLsh: I'm not aware of one ;) [06:09] 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] You guys use anaconda? [06:13] no, but Fedora does ;) [06:14] mneptok: wasn't this about first login, rather than install? [06:14] aha. [06:14] ajmitch: yeah. just saying the closest thing *buntu has is already part of existing Anaconda functionality. [06:14] For an idea of what I'm looking for our (messy, thinkbucket) wiki page http://fedoraproject.org/wiki/Fedora-tour [06:15] but thanks everyone :) [06:15] there was the 'about ubuntu' app which I'm not sure what it includes [06:15] Was looking for some ideas on it, but looks like we're on our own ;) [06:15] or that the few people online at the moment are just clueless :) [06:16] I'll try again later, then :) going to sleep [06:16] 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] bah. [06:16] he fled! [06:17] * mneptok 's reputation (obviously) precedes him [06:18] where is the check bulletproof X uses to determine whether or not to go into panic mode? [06:18] jdong: gdm, perhaps? [06:18] 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] *kdm* :) [06:19] it might live there too :P [06:19] claiming the reason it failed is because "cannot find /dev/fb0" [06:19] I can find that line in my old working Xorg.log.*'s [06:19] but it's clearly not fatal [06:21] *starts rm'ing files* [06:21] oh dear [06:22] err after the 4.3.4 kdm ppa updates it works again [06:22] heh the PPA must not incorporate whatever patches enable bulletproof X :) [06:22] so yeah, i'm thinking that the bulletproof X stuff does live in *dm [06:22] I recall gdm updates around karmic release because of it [06:22] indeed even a regular startx shows (EE) cannot open /dev/fb0.... [06:23] but it goes right on to start X perfectly fine [06:23] even with an EE? [06:23] but bulletproof X seems to be interpreting that as X failed. [06:23] indeed. [06:23] surprising, isn't it? [06:23] well it is meant to be a fatal error, from what little I know of X [06:24] http://paste.ubuntu.com/332887/ [06:24] brief snippet [06:24] as you can see, indeed there's an EE on that module but X continues on [06:24] I'm guessing the various fb drivers don't work in vmware? [06:26] *nods [07:11] Good morning [07:17] Mornign pitti! [07:18] pitti: did you manage to get that jockey bug sorted? [07:18] is an SRU allowed to switch the order on depends for a dummy package? [07:19] hi jussi01; "that" jockey bug? [07:19] micahg: depends; what effect does it have? [07:19] pitti: the one I showed you at UDS [07:19] pitti: it's for libsdl1.2debian [07:19] pulseaudio seems to work where alsa doesn [07:19] 't [07:20] jussi01: no, I didn't get to work on jockey so far [07:26] heya pitti [07:49] good morning [08:02] hey mvo === YDdraigGoch is now known as Richie [08:03] doko, mvo: how does https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/223281 look to you? [08:03] Ubuntu bug 223281 in python2.6 "locale._parse_localename fails when localename does not contain encoding information (was: alacarte crashed with ValueError in _parse_localename() )" [Medium,Confirmed] [08:04] hey dholbach! [08:04] morning mvo [08:04] hey ajmitch [08:05] jmarsden: the patch has landed upstream already? in which release will it be included there? [08:06] 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] dholbach: http://bugs.python.org/issue6895 is the original bug I got the patch from. [08:07] jmarsden: the result is that all python scripts explode for certain locales? [08:08] dholbach: All that are locale sensitive (anything using Lib/locale.py ) [08:09] can you put the link to the upstream bug in the ubuntu bug too? [08:10] jmarsden: ^ [08:10] dholbach: It's there in comment #6 already [08:11] ahhh ok, missed it [08:11] all I did was grab the patch, test it fixes the bug, and package it up, basically. [08:11] right === seb128_ is now known as seb128 === seb128 is now known as seb128_ === seb128_ is now known as seb128 === ara_ is now known as ara [09:34] pitti: for some reason I can't get "community-lucid-" blueprints/workitems to be seen by the launchpad-work-items-tracker [09:34] pitti: I guess we're doing something differently compared to the desktop team, but I dunno what it is :) [09:34] dholbach: oh, want me to set up tracking for community-lucid-* on my server? [09:35] dholbach: do you have an URL for an example BP? [09:35] dholbach: https://blueprints.edge.launchpad.net/ubuntu/lucid/+specs?searchtext=community -> has four [09:35] pitti: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-adopt-an-upstream [09:36] right, that's there [09:36] dholbach: let me set it up [09:36] thanks pitti [09:37] I'm just setting the series goal for a few where we didn't do it yet [09:37] MAILTO=daniel.holbach@canonical.com,jono@ubuntu.com ? [09:38] mail for what exactly? :) [09:38] "spec has no work items", "invalid work item state", etc. [09:38] cron spam [09:39] just set it to my mail :) [09:39] it's set up now, but complains about having no WIs [09:39] hmm [09:40] dholbach: did you just target those to lucid like 5 minutes ago? [09:40] some, yes [09:40] haha missed the last cron run? [09:40] no, production always lags behind changes on edge [09:41] ah, works now [09:41] WARNING: community-lucid-application-indicators-outreach has no work items [09:41] dholbach: ^ that's the kind of spam you get [09:41] (four of those ATM) [09:41] dholbach: http://piware.de/workitems/community/lucid/report.html [09:41] the next run should have some meat in it, when production catches up [09:41] pitti: your workitems stuff still screen-scrapes? [09:42] ajmitch: give me a launchpadlib API, and I'll stop :) [09:42] thanks pitti [09:42] 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] ajmitch: oh, mdz was as well AFAIR [09:42] * pitti doesn't like being hudded [09:43] yeah, the bug was assigned to jml, he said he wasn't working on it at the moment [09:45] nice [10:18] Any chance an archive admin could review libcloud some time today? It's been in NEW for over a week. === debfx_ is now known as debfx [10:38] cjwatson: You seem to be the "on duty AA" this morning. ^^ Pretty please? [10:39] mkay [11:05] soren: accepted. (sorry, had to fix our local lintian installation first) [11:06] 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] 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] cjwatson: Oh, and thanks! I really appreciate it. [11:18] soren: done [11:19] * soren hugs cjwatson [11:19] cjwatson: Thank you! === luisbg_afk is now known as luisbg [11:49] The following packages have unmet dependencies: [11:49] libglib2.0-data: Depends: libglib2.0-0 (>= 2.23.0-1ubuntu1) but 2.22.2-0ubuntu1 is installed [11:49] E: Unmet dependencies. Try using -f. [11:49] hrm, is someone taking care of that ? [11:50] (thats from an armel livefs build attempt) [11:51] just looks like a normal arch all/any buildd issue [11:51] hmm [11:51] yes, i would wait a bit ;) [11:51] but glib was uploaded yesterday [11:52] (if you are on 64bit) [11:52] i'm on armel [11:52] even more so there ;) [11:52] and i have no chance to get to reproduce the mksquashfs failure without getting through the package installation [11:52] ogra: failed to biuld on armel ;) [11:52] which effectively means we wont be able to fix it [11:52] https://edge.launchpad.net/ubuntu/+source/glib2.0/2.23.0-1ubuntu1/+build/1374402 [11:53] * ogra checks [11:53] 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] /tmp/cc7twNnB.s: Assembler messages: [11:53] /tmp/cc7twNnB.s:161: Error: selected processor does not support `swp r3,r5,[r4]' [11:53] /tmp/cc7twNnB.s:179: Error: selected processor does not support `swp r3,r5,[r4]' [11:53] 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] geser: still? I thought lamont removed that again [11:53] yes, should be safe [11:54] -Wa,-mimplicit-it=thumb is missing in the rules :/ [11:54] ogra: or toolchain ;) [11:54] doko_: there? [11:54] we wont get it in the toolchain before alphga [11:54] seb128, ^^^ [11:54] seb128, could you add a contidional -Wa,-mimplicit-it=thumb CFLAG for armel to the package ? [11:55] ogra: right, FTBFS on armel [11:55] *conditional [11:55] ogra: is that package specific? [11:55] pitti, no [11:55] pitti: we're going to test it to be extra sure, then unhold it [11:55] then it doesn't belong into glib for sure, but in the default gcc flags? [11:55] ogra, hum... [11:55] its a temporary workaround so we have a chance to make alpha [11:55] pitti, right [11:55] ogra, what pitti said [11:55] pitti, gcc builds to long [11:56] no way for us to make alpha then [11:56] there is a bug open for the toolchain [11:56] ogra: it's faster to reupload a zillion packages than gcc? [11:56] but it wont be fixed pre alpha [11:56] i wouldnt say glib is a zillion packages [11:57] ogra: but you said it affects all packages? [11:57] it only packages that actually have assembler bits in their code [11:57] it should go into rules [11:57] * pitti doesn't know about those build flags, sorry [11:57] right [11:57] ah [11:57] its just a CFLAG in rules [11:57] and maybe a bug filed upstream [11:57] to make assembly thumb2 compliant [11:57] not really, once the toolchain is right it can go again [11:57] hmm, or that, yeah :) [11:58] i will check with dmart [11:58] well, then go ahead :) [11:58] but for now we definitly should put it in glib rules [11:58] I'm trying to get glib in sync with debian [11:58] seb128: ^^ can you upload that? [11:58] also see: https://wiki.ubuntu.com/ARM/Thumb2 [11:58] can you get those changes in debian? [11:58] yeah [11:58] seb128: its really temporary [11:58] asac, we should mail that URL to ubuntu-devel probably [11:58] asac, yes but please upstream or send to debian [11:59] to make sure maintainers make sure their packages are correct [11:59] seb128: we dont have a patch to upstream yet. i take the action to drive that though [11:59] ifneq ($(findstring $(DEB_BUILD_ARCH), sparc alpha),) [11:59] sorry [11:59] ifneq ($(findstring $(DEB_BUILD_ARCH), armel), [11:59] asac, ok, I trust you on that, do whatever you need to get running there [11:59] CFLAGS += ... [11:59] yeah, there [11:59] endif [11:59] ? [11:59] right [11:59] -Wa,-mimplicit-it=thumb [12:00] thats what you want to add [12:00] or -marm ... but that disables thumb2 completely [12:00] when is the first alpha due btw? [12:00] tomorrow [12:00] uh, there wasn't even an announcement [12:01] no, it's next week [12:01] next week, according to the release schedule, not tomorrow [12:01] ah [12:01] December 10th [12:01] pfious [12:01] yeah, i got my schedule wrong [12:01] ogra: ... good to know that you feel overly pressured ;) [12:01] should that be 'nuff time for a proper gcc fix? [12:01] asac, i always do :) [12:01] pitti, doko could tell :) [12:01] I didn't see the announcement either and did some disruptive changes (ie new glib and new gtk) [12:02] but that's all good apparently ;-) [12:02] not sure if doko is on vac though [12:02] let me check [12:02] seb128, well, its A1 anyway .... i.e. all good as long as it boots somehow [12:02] seems not [12:02] ogra, well I was rather concerned about you complaining about installability [12:02] doko_: when do you plan to update the implicit-it default? (or do you plan to not do that at all)? [12:03] ogra, because armel is slow to catch up on gtk builds [12:03] seb128, yeah, sorry ... i was reading my schedule wrong [12:03] don't worry, it's all good ;-) [12:03] ogra: ok. so ok to wait for doko to answer ;)? [12:03] we should mark https://bugs.launchpad.net/bugs/488302 critical or some such [12:03] Ubuntu bug 488302 in gcc-4.4 "Pass -mimplicit-it=thumb to as by default on in lucid armel" [High,Triaged] [12:04] ogra: well. it basically hides things [12:04] also i am not really sure implicit-it will help for the "swp" thing here [12:04] hmm [12:04] but i thought we will enable it anyway by default [12:05] if you actually want to fix all assembler in all packages i doubt we can make lucid *g* [12:05] if it doesnt hide real thumb2 issues then its probably ok [12:05] to enable by default. what would be bad if we hide it and dont get properly optimized code [12:05] indeed [12:05] but i can chcek that with dmart. let me open a bug for the glib build failure like the wiki page says [12:05] so he can take a look [12:06] i think he was the one that suggested to change the defaults [12:06] actually he filed that bug :) [12:06] 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] "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] i think thats the key sentence here [12:07] so it doesnt actually "hide" stuff ... its just another way of applying the optimization as i understand [12:09] bug 491342 [12:09] Launchpad bug 491342 in glib2.0 "assembly fails to build on armel/lucid " [Undecided,New] https://launchpad.net/bugs/491342 [12:09] ogra: right. [12:12] 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] 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] 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] cjwatson: certainly, thanks for the patch! [12:16] 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] 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] waiting for the test to complete ... === xomas is now known as xomas_ === xomas_ is now known as xomas [13:16] * soren boggles [13:17] 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] 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] I glance over at the dist-upgrade, and it seems to have fixed itself while it was /unpacking/ xorg. [13:19] Very, very odd, if you ask me. [13:20] Well, xorg, xserver-xorg, or xserver-xorg-video-all. [13:20] Very, very odd. [13:22] 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] slangasek, hey, any reason you didn't upload your gnome-screensaver merge? === MacSlow is now known as MacSlow|lunch [13:25] slangasek, (just curious on whether that was wanted or if you forgot to dput it) [14:01] jdstrand, hey, I'm not sure I agree with the closing of this evince fileselector issue as wontfix... [14:02] jdstrand, being able to store documents on shared vfat disks is a valid user scenario [14:02] seb128: I agree-- but the user mounted it in a non-FHS directory. we allow access to /mnt and /media [14:03] oh ok, fair enough then ;-) [14:04] seb128: hmm, actually-- I thought it did. seems I mixed up the profile with the firefox one [14:04] seb128: I'll fix that [14:04] jdstrand, thanks [14:04] seb128: non-FHS-- won't fix, FHS, fix [14:04] seb128: thanks for the followup [14:05] right, having mnt and media should be enough [14:05] thank you for looking at those issues ;-) [14:05] seb128: oh np! :) === MacSlow|lunch is now known as MacSlow [14:20] asac, seb128: this is code which should be fixed upstream, it won't work on multi cores. the atomic helpers should be used === jamie is now known as Guest40661 === robbiew-afk is now known as robbiew [14:35] doko_: right. my question was more about an ETA for the implicit-it flag in general [14:37] asac: should be with the next upload [14:37] when is that ;) [14:37] ? [14:37] when the eglibc build is fixed [14:38] ok [14:38] guess i wont get an estimate from you ;) [14:38] no not a specific one :-/ [14:38] about a week, two, a month etc. [15:02] cjwatson: I can't make the weekly meeting today due to conflicts...can you cover it? or should we cancel? [15:02] I can cover it, can you let me know anything I should cover other than the spec approval deadline? [15:08] 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] cjwatson: hmmmm -? [15:09] * mathiaz checks [15:11] cjwatson: I'll draft something up today [15:12] thanks! [15:14]